Re: [AVT] Outstanding issues on the HDREXT draft

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

Tom-

Stepping back a bit, I think we need to remember that the RTP spec 
did not (for better or worse) provide a managed header extension 
mechanism.  The proverbial horse was long ago let out of the barn and 
has been running wild in the fields for years. There has been no 
catastrophic interoperability problem. However, a couple folks 
thought it would be helpful to provide some guidance to *reduce* 
collisions and *increase* interoperability.  This ID does that.  It 
does not *eliminate* collisions or *perfect* interoperability. It 
cannot do that. Only a revision to 3550 can do that.

So, "protection of the RTP architecture and avoidance of name 
collision" would have been really good for us to apply to 3550 
initially by providing a managed header extension mechanism. But they 
are a bit harsh to apply to a document that is trying to 
proverbially, build a coral around the horse, not try to put it back 
in the barn years after the fact.

Conformance to this ID will definitely improve things, but I don't 
see how any provision of this ID can be required for RTP 
implementations without a rather significant revision to 3550.

Regards,

         Mike

At 03:04 AM 2/18/2008 -0500, Tom Taylor wrote:
>Below.
>
>Dave Singer wrote:
> > At 22:04  -0500 17/02/08, Tom Taylor wrote:
>...
> >>
> >> 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.
> >
> > An absolute hard line on "if you want to register, then you are subject
> > to review" is appropriate, and the intent is that it's in the draft.  I
> > have no trouble adding  "and if your practice is public or likely to
> > encounter other implementations, then you SHOULD register", as well.
> > That's appropriate.
> >
> >
> >
>[PTT] This is turning the registration process upside down. IANA 
>registration is
>not a privilege to be paid for so much as a tool for achieving specific
>objectives. There are two objectives in this case: protection of the RTP
>architecture and avoidance of name collision. I suspect protection of the
>architecture by coercing a review of specifications is the more 
>important of the
>two.
>_______________________________________________
>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