Re: [AVT] Outstanding issues on the HDREXT draft

[Dave Singer <singer at apple.com>]

At 20:49  -0500 11/02/08, Tom Taylor wrote:
>>At 19:28  -0500 11/02/08, Tom Taylor wrote:
>>>>>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.
>>
>>We can certainly say that every extension SHOULD be registered; 
>>it's clearly desirable.  We cannot, however, force  it, can we? 
>>The spec. is external, the usage is external;  we have no leverage 
>>at all. What is the 'or else'?   Should I insert such a statement? 
>>There are clearly periods of time when even an extension that will 
>>be registered, has not yet been, but may be in experimental use 
>>(indeed, I suggest that people trying things out before they're 
>>finalized is actually desirable).
>>
>[PTT2] There is the oft-quoted statement: "We are not the protocol 
>police." However, it is our job to define interoperable standards. 
>If someone chooses to ignore the standard, that's their problem. 
>Experiments should be run in a closed environment, to prevent 
>collisions.

I disagree on several grounds.

a) experiments and interoperability can and should be run between 
multiple recipients;  we learn something when people show trials with 
internet drafts, before the RFC is published

b) I believe -- and most standards bodies insist -- that normative 
requirements in specs be used *only for testable aspects of 
implementations*. That is, for example, one would change a MUST to a 
SHOULD for something that said that a string must be a true 
description of the content of an image  -- it's not testable. 
Likewise here, you're asking for a must for something that is nothing 
to do with implementations;  I think (and most standards bodies 
think) it's inappropriate.

-- 
David Singer
Apple/QuickTime
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
http://www.ietf.org/mailman/listinfo/avt