RFC Errata
Found 3 records.
Status: Verified (1)
RFC 4567, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", July 2006
Source of RFC: mmusic (rai)
Errata ID: 2247
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Riccardo Bernardini
Date Reported: 2010-05-06
Verifier Name: Robert Sparks
Date Verified: 2011-02-07
Section 3.2 says:
key-mgmt-spec = "prot" "=" KMPID ";" ["uri" "=" %22 URI %22 ";"]
It should say:
key-mgmt-spec = "prot" "=" KMPID ";" ["uri" "=" %22 URI %22 ";"] ["data" "=" %22 base64 %22 ";"]
Notes:
There is an inconsistency between the ABNF for key-mgmt-spec on page 6 and the two SETUP examples on top of page 21. In both examples a field data="..." is present in the keymgmt header, but the ABNF on page 6 does not allow for it. The suggested correction solves the inconsistency.
--- From reviewer Dale Worley --
The grammar needs additional work because key-mgmt-spec is not
correctly attached to the original ABNF, and the production provided
does not allow the parameters to appear in any order. In addition,the
terminating CRLF is not shown in the ABNF. A more correct version is:
extension-header =/ KeyMgmt
(Is this the correct nonterminal to extend? RFC 4567 section 3.2 does
not make it clear what sort of header "KeyMgmt" is.)
KeyMgmt = "KeyMgmt" ":" key-mgmt-spec 0*("," key-mgmt-spec) CRLF
key-mgmt-spec = "prot" "=" KMPID 0*(key-mgmt-spec-param)
key-mgmt-spec-param = ";" "uri" "=" %22 URI %22
/ ";" "data" "=" %22 base64 %22
The whole situation is troublesome because the RFC does not make it
clear to what degree the 'prot', 'uri', and 'data' elements are
required to be in a certain order. Given that many headers are copied
from HTTP, the implication is that the first element (that is,
"prot=KMPID") must appear in the first position, but the following
elements ("uri" and "data") may be in any order. But current practice
may have de-facto standardized a different rule. We need some input
from someone who is familiar with current practice.
------
The MMUSIC WG list was polled and the responses were that allowing these parameters to appear in any order was an acceptable technical solution.
Status: Held for Document Update (2)
RFC 4567, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", July 2006
Source of RFC: mmusic (rai)
Errata ID: 56
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Held for Document Update by: Robert Sparks
The abstract says:
General guidelines are also given on how the framework should be used together with SIP and RTSP. The usage with the Multimedia Internet KEYing (MIKEY) key management protocol is also defined.
It should say:
General guidelines are also given on how the framework should be used together with SIP and SAP. The usage with the Multimedia Internet KEYing (MIKEY) key management protocol is also defined.
Notes:
As can be seen from the title and the body of the RFC, and
as has been correctly stated in the first paragraph of the Abstract,
the RFC primarily deals with SDP and RTSP; it "also" considers the use
of the SDP extensions with SIP (Section 4.1.2) and SAP (Section 4.1.3).
Hence, SAP should be mentioned in the second paragraph of the Abstract
instead of RTSP.
Errata ID: 809
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Held for Document Update by: Robert Sparks
(1) [[posted separately.]]
(2) inappropriate text (cut&paste error?)
On page 6, the explanation below the ABNF in Section 3.2 says:
where KMPID is as defined in Section 3 of this memo, "base64" as
defined in [SDPnew], and "URI" as defined in Section 3 of [RFC3986].
It should say:
where KMPID is as defined in Section 3 of this memo and "URI" as
defined in Section 3 of [RFC3986].
Rationale: "base64" does not appear in the ABNF of Section 3.2 !
(3) incomplete sentence
The first paragraph of Section 4.1.1, on page 8, says:
The processing when SDP is used is slightly different according to
the way SDP is transported, and if it uses an offer/answer or
announcement. The processing can be divided into four different
steps:
It should say:
The processing when SDP is used is slightly different according to
the way SDP is transported, and if it uses an offer/answer or
| announcement model. The processing can be divided into four
different steps:
(4) misleading word omission
Within Section 5.4, the explanation at top of page 21,
Each RTSP header is inserted in the SETUP related to the audio and
video separately:
should be clarified to say:
| A key management RTSP header is inserted in the SETUP related to the
audio and video separately:
(5) suspected inconsistency
The last paragraph of Section 7, on page 22, says:
The server will need to be able to know the identity of the client
before creating and sending a MIKEY message. [...]
IMHO, it is not clear how this fits with the text on page 14.
Perhaps, a 3-way handshake with client auth in DESCRIBE could
be considered.
(6) inconsistency between ABNF and IANA registrations
Perhaps, a late change to the ABNF in the body of the RFC has lead
to inconsistencies in the filled out IANA registration templates
as presented in Section 9.1 and 9.3; in particular, the hypothetical
attribute name "key-mgmt-att-field" referred to in fact should be just
"key-mgmt"; "key-mgmt-att-field" is the name of the ABNF production
rule (introduced in Section 3.1) for this literal; in the template
the literal name of the attribute is needed.
Therefore:
In Section 9.1, near the bottom of page 25, change
SDP Attribute Field ("att-field"):
Name: key-mgmt-att-field
to say:
SDP Attribute Field ("att-field"):
Name: key-mgmt
and in Section 9.3, on page 26, change
Purpose: Usage of MIKEY with the key-mgmt-att-field
attribute and the keymgmt RTSP header
to say:
| Purpose: Usage of MIKEY with the key-mgmt SDP attribute
and the keymgmt RTSP header
[ I also have added "SDP" for additional clarification. ]
(7) missing articles
The first paragraph of the Abstract, on page 1 of RFC 4567, says:
This document defines general extensions for Session Description
Protocol (SDP) and Real Time Streaming Protocol (RTSP) to carry
messages, as specified by a key management protocol, in order to
secure the media. [...]
It should say:
| This document defines general extensions for the Session Description
| Protocol (SDP) and the Real Time Streaming Protocol (RTSP) to carry
messages, as specified by a key management protocol, in order to
secure the media. [...]
(8) missing article
Near the top of page 7, the paragraph,
We define one new RTSP status code to report error due to any failure
during the key management processing (Section 4.2):
should say:
| We define one new RTSP status code to report an error due to any
failure during the key management processing (Section 4.2):
(9) missing article
Within Section 4.2, the last bullet on page 15 says:
* Key management responses for the initial establishment of security
parameters for an individual media SHALL only be included in SETUP
for the corresponding media stream.
It should say:
* Key management responses for the initial establishment of security
| parameters for an individual media SHALL only be included in the
SETUP for the corresponding media stream.
(10) typo (singular/plural mismatch)
Within Section 5.2, the explanation of the example, in the lower
half of page 19,
The client checks the validity of the received MIKEY message, and, in
case of successful verification, it accept the message. [...]
should say:
The client checks the validity of the received MIKEY message, and, in
| case of successful verification, it accepts the message. [...]
Notes:
from pending