Re: [AVT] Outstanding issues on the HDREXT draft

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

Tom-

I see your point about the scope of the app bits.  The text is indeed 
not at all clear about these "extensions" and their relation to the 
URI signaling on par with the tag/len/value extensions.  I'll propose 
some edits to the ID "soon" to hopefully fix this. My apologies.

To your comments about public specifications, registration, and 
document structure, I think these are broader issues that have 
received notable discussion. There are a number of pros and cons that 
have been weighed to arrive where we are. Is there something specific 
to the app bits in particular that I am not understanding?

Thanks,

         Mike

At 11:12 AM 2/12/2008 -0500, Tom Taylor wrote:
>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