Subject: [MMUSIC] Fwd: Errata report for erratum 2247 for RFC 4567, "Key Management Extensions for SDP and RTSP"

From: Robert Sparks <[email-masked]>
Date: Mon, 6 Dec 2010 17:04:26 -0600

MMUSIC -

Does anyone with an existing implementation know of any issue with allowing 
key-mgmt-spec-param to appear in any order? If I don't hear objection by Dec 17, 
I will verify this errata (being sure to include Dale's analysis).

RjS

Begin forwarded message:

> From: "Worley, Dale R (Dale)" <[email-masked]>
> Date: October 20, 2010 5:39:55 PM CDT
> To: Robert Sparks <[email-masked]>, "[email-masked]" <[email-masked]>
> Subject: Errata report for erratum 2247 for RFC 4567, "Key Management Extensions for SDP and RTSP"
> 
> ======================================================================
> RFC4567, "Key Management Extensions for Session Description Protocol
> (SDP) and Real Time Streaming Protocol (RTSP)"
> Source of RFC: mmusic (rai)
> 
> Errata ID: 2247
> 
> Status: Reported
> Type: Technical
> 
> Reported By: Riccardo Bernardini
> Date Reported: 2010-05-06
> 
> 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.
> ----------------------------------------------------------------------
> Recommended status:  (correct) Verified (publish)
>                     Needs review by expert
> 
> 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 thefirst 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.
> ======================================================================
> 
> Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 7 Dec 2010 11:14:29 -0500

________________________________________
From: Robert Sparks [[email-masked]]

MMUSIC -

Does anyone with an existing implementation know of any issue with allowing
key-mgmt-spec-param to appear in any order? If I don't hear objection by Dec 17,
I will verify this errata (being sure to include Dale's analysis).
________________________________________

If there is no objection, be sure to append a note saying that you polled for objections and did not receive any.  The reason to do that is that the errata report does not settle this particular issue (from the RFC itself, there is no way to determine the 'correct' fix), but the poll clarifies that "appearing in any order" is a technically acceptable resolution.

Dale