Re: [AVT] Outstanding issues on the HDREXT draft

[Michael A Dolan <md.1 at newtbt.com>]

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.

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.

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