Re: [AVT] Outstanding issues on the HDREXT draft

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

Inline, marked with [PTT].

Michael A Dolan wrote:
> Tom-
> 
> The app bits are no more "secret bits" than the extensions. They are 
> scoped by the URI that scopes the extensions. If this is not clear, 
> then we need to clarify the text.
> 
[PTT] The problem is that the AAAA bits are not associated with a specific 
extension, but the URI is. The word "profile" is rightly used here to mean a 
profile for the usage of the header extension mechanism. To make this work, you 
have to:

- provide a means to signal which profile you are using
- provide a publicly available specification of the profile
- register the profile identifier that is used in the signalling.

All this is missing from the existing text.

... or on reflection, do you mean to say that an extension may be specified as a 
Boolean extension using APPbit x (x from 0 to 3)? If so, that text is definitely 
missing. I also don't see why this wouldn't also apply to the 4+4 mechanism -- 
we don't really need the full 0xBEDE.

> As to consistency of the length field, it would be highly unlikely 
> that any given system would use both 4+4 and 8+8. The designer will 
> choose the one that best suits the needs and use it throughout.  I 
> believe the text is clear in both cases about the meaning of the 
> length field. If the same implementation were expected to do both 
> concurrently, then I would see your point.

[PTT] You're making a rather good case here for documenting these as separate RFCs!

> 
> Regards,
> 
>          Mike
> 
> At 08:44 PM 2/11/2008 -0500, Tom Taylor wrote:
>> Responses marked [PTT].
>>
>> Michael A Dolan wrote:
>>> Tom-
>>> I concur with what Dave says below.  To the points he tossed to me....
>>> Regarding the 8+8 design - like the 4+4 design, it stems from an 
>>> existing deployment. So from my perspective, changing it at this 
>>> point needs disclosure of some sound technical flaw. The header 
>>> value is, from a functional point of view, arbitrary and your 
>>> proposal for 0x4121 is no less arbitrary than the one chosen (and 
>>> currently in use).  I see no value in changing it, and quite a bit 
>>> of nuisance if we do.
>> [PTT] Agreed, I was arbitrary. I was only worried that 0x1000 is so 
>> obvious that someone may have used it.
>>
>>> Regarding the app bits, I believe it is not quite accurate to 
>>> summarize them as a "controversy".  Their existence value is that 
>>> there are logically some kinds of extensions that are booleans and 
>>> therefore there is value in having no actual extensions and using a 
>>> few bits in the "defined_by_profile" for more efficient signaling 
>>> of booleans.  Again, like the 8+8 design overall, these are in use 
>>> today and setting them to a constant would be a problem for those 
>>> implementations. But mostly, I don't see the argument for removing 
>>> them, given their obvious value.
>> [PTT] OK, so you choose the option that creates a profile registry. 
>> The whole point here is to create interoperable standards, and you 
>> can't do that with secret bits.
>>> Like Dave, I don't personally see the benefit/argument for harmony 
>>> in the semantics associated with zero length extensions. If you run 
>>> out of boolean app bits, more boolean value extensions can then be 
>>> signaled by the mere presence of the extension.
>> [PTT] Again, think of the poor implementer trying to debug his or 
>> her software, having overlooked the inconsistency between the two 
>> specifications. 'Foolish consistency is the hobgoblin of small 
>> minds', but I don't think insisting on consistency is foolish here.
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> http://www.ietf.org/mailman/listinfo/avt
> 
> 
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
http://www.ietf.org/mailman/listinfo/avt