Re: [AVT] Open issue on hdrext draft

[Dave Singer <singer at apple.com>]

At 13:43  +0200 4/10/07, Magnus Westerlund wrote:
> Imed.Bouazizi at nokia.com skrev:
> >  Hi,
> >
> >  An RTP gateway (translator/mixer) that for some reason does not
> >  receive/parse the SDP and is then not aware of the mapping between the
> >  RTP header extension and the ID will not be able to process the RTP
> >  packet appropriately. This speaks for IETF agreed registration (option
> >  c).
>
> I think this is an irrelevant comment as any mixer or translator that
> needs to understand the packet content anyway will require to be part of
> the signalling context. Thus, I don't think there is a any benefit at
> all with static mappings.

I agree;  the general question "should RTP packets be comprehensible 
without their signaling context" is outside the scope of this 
discussion (though my sense is that the consensus direction is "no", 
as shown, for example, by the fact that we no longer approve of 
static payload type mappings).

> What we are discussing is what rules applies for the IETF URN space,
> i.e. the header extensions that will look like they are blessed by IETF.
> The current draft version was in fact a) as this specified
> "Specification Required" from RFC 2434:
>
> "      Specification Required - Values and their meaning must be
>            documented in an RFC or other permanent and readily available
>            reference, in sufficient detail so that interoperability
>            between independent implementations is possible."
>
> I think A is fine but would probably prefer this to be b) with explicit
> rule requiring a publicly available specification.

I'm sorry, I may have mis-written something, since I tried to agree 
with you here!  The current intention is that for the IETF URN space, 
a standards-track RFC is required.  And that for IANA registration, 
an IETF URN is required:

"To be registered
   with IANA, the extension MUST use this IETF URN form; to use the IETF
   URN form, the extension MUST be defined in an RFC."

If there is other text that isn't clear, can you tell me what it is?

> Having an expert look
> at any registrations to ensure that they are not totally wacko is in my
> book a good thing.

Me too, no dispute here.

> But at the same time put minimal bar on the
> registrations. Other SDOs should basically be able to send in an email
> with a request containing a reference and things usually go through.

So, you would permit non-IETF URIs in the IANA registry, also, after, 
what 'expert review' and with 'publicly available specification 
required'?

That's fine by me also.

--
David Singer
Apple/QuickTime

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt