[AVT] Outstanding issues on the HDREXT draft

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

OK, here's another try. URIs are OK, but I believe specification of their 
construction should be consolidated in the IANA section, since they are directly 
related to registration.

1. The APP bits controversy [NO CHANGE]
===========================

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 [NO CHANGE]
=================================

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 [Changed to reflect decision to use URNs]
======================================

As suggested in the covering note, I believe that many of the instructions in 
section 5 really belong in the IANA Considerations section, since they deal with 
matters of specification rather than negotiation.

Section 5 changes:
------------------

Third paragraph: retain the first sentence: "Each extension is named by a URI." 
Move the rest of this paragraph and the next one to section 9.1 (merging text 
suggested below).

Retain the next paragraph, beginning: "An extension URI with the same attributes 
...".

Move the next paragraph, beginning: "For extensions defined in RFCs ...", to 
follow the other text moved to section 9.1.

Move the next one-sentence paragraph, pointing to the IANA Considerations 
section, up to join and follow "Each extension is named by a URI."

Move the examples to follow the rest of the moved text in section 9.1.

After all that, section 5 will read as follows:

5.  SDP Signaling Design

    The indication of the presence of this extension, ... [unchanged]

    A usable mapping MUST use IDs in the valid range, ... [unchanged]

    Each extension is named by a URI. The registration requirements are detailed
    in the IANA Considerations, below.

    An extension URI with the same attributes MUST NOT ... [unchanged]

    The mapping may be provided per media-stream ... [all the rest of the 
section unchanged]



IANA Considerations (section 9.1)
---------------------------------

I suggest the section begin with the following text.

"IANA SHALL maintain a registry of RTP header extension names. 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."

Then insert the material pulled from section 5. After that, continue with the 
existing material in section 9.1, beginning with:

"Here is the formal declaration ...".

Tom Taylor

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
http://www.ietf.org/mailman/listinfo/avt