Re: [AVT] Outstanding issues on the HDREXT draft

[Tom Taylor <tom.taylor at rogers.com>]

Oh, lovely. I missed some of the correspondence in my review. We settled on 
Expert Review. The other changes stand, but the IANA considerations section 
should read as follows:

"IANA SHALL maintain a registry of RTP header extension names. A valid
name SHALL begin with an alphabetic character followed by one or more
alphabetic characters, digits, or the underscore character "_".
Insertion into this registry is under the requirements of "Specification 
Required" as defined in [RFC2434bis].

"The IANA registry SHALL contain four pieces of information: the RTP
header extension name itself, a short descriptive phrase, and the
identity of the specification, and the name of a contact within the organization 
publishing that specification.

"The designated expert shall ensure that the specification meets the following 
requirements in addition to those described in [RFC2434bis]:

- complies with the requirements of RTP and RFCxxxx for
extensions (notably, that the stream is still decodable if the extension
is ignored or not recognized);

- is technically consistent (in itself and with RTP), complete, and
comprehensibile;

- does not duplicate functionality in existing IETF specifications
(including RTP itself), or other extensions already registered;

- contains a security analysis regarding the content of the header extension;

- is generally applicable, for example point to multi-point safe, and
correctly describes limitations if they exist."




Tom Taylor wrote:
> Reviewing the correspondence on the HDREXT draft, and re-reading the 
> draft itself, I identify the following issues and proposed changes:
> 
> 1. The APP bits controversy
> ===========================
> 
> The conclusion was that APP bits are not a good way to go. The general 
> consensus of the AVT community is in favour of explicit rather than 
> opaque conveyance of information.
> 
> Two choices: require Standards Action for each profile that defines APP 
> bits values and IANA registration of the profile identifier that would 
> be used in signalling, or set a fixed value for the entire header. I 
> suggest using the fixed value 0x4121 (complement of 0xBEDE, large enough 
> and arbitrary enough to avoid collision with old header extensions in 
> the wild).
> 
> 2. Inconsistent length specifiers
> =================================
> 
> The 4+4 form disallows zero-length data (section 4.2).  The 8+8 form 
> allows it (section 4.3). It seems inconsistent to expand field sizes and 
> then look for ways to chisel bits away (a remark that also applies to 
> the APP bits). Length should be defined the same way in both forms 
> (i.e., 0 implies one byte of extension data).
> 
> 3. Identification of header extensions
> ======================================
> 
> As Cullen has said repeatedly, URIs are not acceptable as extension 
> identifiers, both because of length considerations and because we are 
> not prepared to allow other organizations to define arbitrary extensions 
> without IETF review. The identifiers must be fixed text values, 
> registered with IANA in accordance with the IANA Considerations section. 
> This implies the following textual changes:
> 
> Section 5: major rewrite.
> ------------------------
> 
> Delete the third and fourth paragraphs, beginning respectively: "Each 
> extension is named by a URI." and "Rationale:". In the next paragraph, 
> change the first sentence as follows:
> 
>  From "An extension URI ..." to "An extension name ...".
> 
> Delete the next two paragraphs, beginning: "For extensions defined in 
> RFCs ..." and "The registration requirements ...". Delete the example 
> identifiers following those paragraphs. Aside from the issue of URI vs. 
> fixed text value, registration requirements and format should be 
> discussed in one place only.
> 
> In the informal ABNF in this section, replace "<URI>"  with "<extName>", 
> and change the explanatory text following this from
> 
> "where <URI> is a URI, as above, ..."
> 
> to
> 
> "where <extName> is an IANA-registered extension name as described in 
> section 9.1, ..."
> 
> Change the examples following the paragraph beginning "The formal BNF 
> syntax ..." to use simple identifiers, i.e.,
> 
> "Example:
> 
>    a=extmap:1 ttime
> 
>    a=extmap:2/sendrecv xmeta short"
> 
> Section 6, examples:
> -------------------
> 
> Delete all occurences of "URI-".
> 
> Section 7, syntax
> -----------------
> 
> Delete the second sentence, beginning "The syntax element 'URI' ...".
> 
> Change the syntax for extensionname from
> 
> "extensionname = URI"
> 
> to
> 
> "extensionname =  ALPHA 0*[ ALPHA / DIGIT / "_" ]
>           ; Case-sensitive"
> 
> I admit I was arbitrary here, and I wouldn't argue with minor tweaks. 
> BTW, the ABNF reference has now changed to RFC 5234.
> 
> Delete the rule "URI".
> 
> IANA Considerations (section 9.1)
> ---------------------------------
> 
> I suggest using the expression "extension name" rather than "identifier" 
> in the section title because "identifier" is used in the signalling 
> sections to refer to the numeric value rather than the text name.
> 
> Replace the entire existing contents of the section with the following:
> 
> "IANA SHALL maintain a registry of RTP header extension names. A valid 
> name SHALL begin with an alphabetic character followed by one or more 
> alphabetic characters, digits, or the underscore character "_". 
> Insertion into this registry is under the requirements of "IETF Review" 
> as defined in [RFC2434bis].
> 
> "The IANA registry SHALL contain three pieces of information: the RTP 
> header extension name itself, a short descriptive phrase, and the 
> identity of the defining RFC."
> 
> Tom Taylor
> 
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
http://www.ietf.org/mailman/listinfo/avt