Re: [AVT] Outstanding issues on the HDREXT draft

[Dave Singer <singer at apple.com>]

At 10:43  -0500 11/02/08, Tom Taylor wrote:
>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.

OK, this one I can respond to.

>
>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).

This is Mike Dolan's baby and I'll let him respond.

>
>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).

This is also Mike's, but I will say that though the 4-bit has a +1 
design and the 8-bit doesn't need it, the situation is easily 
comprehensible, explained, and implementable.  I think it could be 
argued that the gain is having 0-byte values in 8 bits is worth the 
slight cost in text.

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

OK.  I don't have a technical problem with the changes below, but I 
am worried about clarity.  See below.

>
>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).

But 9.1 is IANA.  Whether or not the extension is *registered* it 
must be *named* by a URI., and the requirements on that URI are 
independent of INA.    Perhaps this is in the wrong place (it's not 
unique to SDP), but IANA isn't an improvement!

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

That assumes (probably correctly) that all extensions defined in RFCs 
will also be registered.  OK.

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

But the examples are examples of what the section is about (SDP) not 
what 9.1 is about (IANA considerations).

>
>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."

The following is already in the formal declaration;  by 'name of a 
contact' I assume you mean a person's name.  Is that needed (or even 
desirable)?  People move around awfully fast.

    o  Information required: (a) The desired extension identifier URI,
       and (b) a formal reference to the publicly available
       specification.  For extensions defined in RFCs, the URI is
       recommended to be of the form urn:ietf:params:rtp-hdrext:, and the
       formal reference is the RFC number of the RFC documenting the
       extension.

I certainly have no problem adding a requirement for a short 
descriptive phrase;  good idea.

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


-- 
David Singer
Apple/QuickTime
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
http://www.ietf.org/mailman/listinfo/avt