RE: [AVT] Open issue on hdrext draft

[<[e-mail]>]

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).
On the other hand, since the space for 1-byte header IDs is very limited
(14 values only), registration might exhaust the space rather quickly.
One possible solution is to introduce registration for 2-byte headers
and leave 1-byte headers for application-specific usage. However, this
has the limitation that you cannot mix registered and
application-specific extensions into a single RTP packet. It also
imposes length limitations on application-specific extensions.

BTW, am I right in the assumption that this I-D still discourages the
usage of RTP header extensions, as is the case in RFC3550? One might ask
why do we need to register some headers that are just for experimental
purposes?

Regards,
Imed


>-----Original Message-----
>From: ext Dave Singer [mailto:[e-mail]] 
>Sent: 04 October, 2007 07:15
>To: Tom Taylor; IETF AVT WG
>Cc: Cullen Jennings; [e-mail]
>Subject: Re: [AVT] Open issue on hdrext draft
>
>I don't know if it helps, but in case it does, it might help 
>if I 'frame' the question and provide some history and 
>rationale for the current state.
>
>See below, after Tom's questions...
>
>
>At 22:02  -0400 3/10/07, Tom Taylor wrote:
>>Before the header extension draft can be approved we have to 
>settle two 
>>or three points that have been raised after the document passed WGLC. 
>>One of them is the view of the Working Group regarding registration 
>>requirements.
>>
>>Is it the Working Group's intention that:
>>
>>(a) any SDO can standardize and register a new RTP header extension 
>>without IETF review or consent; or
>>
>>(b) all RTP header extensions require review and agreement by an IETF 
>>expert before they can be registered; or
>>
>>(c) all RTP header extensions require IETF consensus before 
>they can be 
>>registered.
>>
>>David Singer had a clear view on this question when he wrote the 
>>document in the first place. I should let him speak for himself, but 
>>his basic idea was to encourage registration as an alternative to 
>>hard-to-get-rid-of experimental identifiers, by making registration a 
>>simple process. His preference was thus toward alternative (a).
>>
>>Last time we didn't ask the question in quite these stark terms, and 
>>only Magnus replied. It's hard to read a consensus from that. Would 
>>other people care to comment?
>
>
>The current RTP specification makes provision for header extensions. 
>However, there is no process defined to identify them, or 
>register identifiers.  Indeed, the 16-bit field that might be 
>thought of as a label in the RTP packets is not clearly 
>defined as such, and there is no registration or documentation 
>process defined for it.  This has led some to believe that 
>they can use it as they wish, and others to believe that it is 
>unusable.
>
>The header extension draft
><http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-hdrext-13.txt>
>has been before this group since the latter part of 2005.  It 
>defines a way to pack multiple header extensions into a 
>packet, and defines a way for them to be labelled.  Initial 
>drafts used reverse domain names (kind of like Java), and 
>later ones moved to using URIs for the labelling.
>
>The question has arisen as to what requirements there should 
>be around the documentation and registration of header extensions. 
>Currently the draft says that IANA will provide a registry, 
>but only for IANA-form URNs, and that to use an IANA-form URN, 
>the extension must be defined in a standards-track RFC.  This 
>leaves open, of course, the ability of anyone who can make a 
>URI (URL or URN) to define and use a header extension.
>
>Historically, IETF specs (including those from this WG) have 
>had features or fields defined by 'simple names' that are 
>registered, often with provision for an experimental X- 
>prefix.  I think we've all observed cases where X- names 
>become by common usage, even with the risk of collision and 
>lack of registration that they suffer from.
>
>Clearly, in cases where interop is important, the use of 
>formats or labels for which either the registration or 
>documentation cannot be assured to be found is undesirable, to 
>the point that specifications are usually written to 
>discourage this state.
>
>However, header extensions are defined in RTP (and this is 
>re-inforced by the header extension draft) to be ignorable.  
>It is an absolute requirement that the interoperability of an 
>RTP stream cannot be affected by the presence or absence of an 
>extension (though, of course, its utility might, or it's hard 
>to see what the extension is doing).
>
>This led to the current design and status:  there would be 
>'preferred, vetted' extensions, defined in RFCs, using IANA 
>URN names. But those needing to experiment, or develop an 
>extension for a more restricted environment etc., would be 
>able to use other URIs to label them, without running risk of 
>collision, and without running the risk of an interop problem 
>with systems that were written either without knowledge of 
>that extension, or indeed, without knowledge of this header 
>extension mechanism at all (i.e. using only RFC 3550 or 1889). 
> The author(s) saw this state as preferable to the 'x-' 
>method, in this case.
>
>So, I guess I'd like to know whether there are other 
>considerations that should be taken into account.  Then, here 
>are some more worked-out questions from Tom's various choices:
>
>a) whether the current 'two tier' state, using URIs with an 
>IANA registry for RFC-defined extensions is acceptable;
>
>b.i) whether IANA should be asked to document the mapping from 
>any URI to a publicly available specification;
>
>b.ii) whether, in order to be entered into such a registry, 
>some IETF process such as expert review should be required;
>
>b.iii) whether the 'official' extensions should be considered 
>only those registered at IANA;
>
>b.iv) or whether we should move to a simple name system, with 
>IANA registry only (presumably, explicitly or implicitly with 
>the x- prefix being available);
>
>c) whether the header extension space should be restricted to 
>only those extensions defined in RFCs, requiring IETF 
>consensus for any header extension.
>
>
>As said above, the author(s) felt that, given that the header 
>extension document constrains these extensions to be small and 
>ignorable, that choice (a) provided a reasonable balance and 
>set of options, with the other options being either more 
>restrictive than needed or potentially problematic in other 
>ways.  But there may be other considerations, or other preferences.
>
>I think it would help, if you don't like the current state, 
>you could indicate what considerations lead you to another preference.
>
>--
>David Singer
>Apple/QuickTime
>
>_______________________________________________
>Audio/Video Transport Working Group
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/avt
>

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt