Re: [AVT] Outstanding issues on the HDREXT draft

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

The basic point is that the IETF insists that the standards it creates should 
result in interoperable implementations. Thus the standards address not only 
implementation issues, but also process issues that have to be resolved to 
achieve this result.

Having taken this hard line, I will note that some IANA registries also provide 
for a private namespace in addition to the public one. The intent is to allow 
for vendor-specific implementations, but other SDOs have sometimes taken 
advantage of this feature to modify IETF protocols without going through IETF 
process. The Diameter protocol is an example in many respects. Note, however, 
that the process is not totally uncontrolled -- there is still an IANA registry, 
even though no publicly available specification is necessarily required.

So the question we have to resolve here is the degree to which the IETF wishes 
to track (in the first instance) and review the specification of RTP header 
extensions.

Dave Singer wrote:
> 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.
> 
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
http://www.ietf.org/mailman/listinfo/avt