Re: [AVT] Outstanding issues on the HDREXT draft

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

Trimmed to specific discussion points, see [PTT].

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

[PTT] I'm concerned that the inconsistency would be a trap for the unwary 
implementer.
> 
>> 3. Identification of header extensions [Changed to reflect decision 
>> to use URNs]
>> ======================================
>>
...
> 
>> 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!

[PTT] I believe this is the heart of a misalignment of intention between you and 
the ADs. I believe their intention is that every extension must be registered. 
Hence the required form of the URI becomes a criterion for successful registration.
> 
>> Retain the next paragraph, beginning: "An extension URI with the 
>> same attributes ...".
>>
...
>>
>> 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).

[PTT] The examples I'm talking about are not the ones at the end of the section, 
but these:

    An example (this is only an example), where 'avt-example-metadata' is
    the hypothetical name of a header extension, might be:

    urn:ietf:params:rtp-hdrext:avt-example-metadata

    An example name not from the IETF (this is only an example) might be:

    http://example.com/082005/ext.htm#example-metadata
...

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

[PTT] Good point. What I'm thinking of is actually a contact address. The 
organizations I'm used to dealing with (e.g. ITU-T) generally have invariant 
addresses available.

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