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

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 20 Oct 2010 18:39:55 -0400

======================================================================
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