[AVT] Outstanding issues on the HDREXT draft

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

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