Re: [AVT] Outstanding issues on the HDREXT draft

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

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