Re: [AVT] Open issue on hdrext draft

[Dave Singer <singer at apple.com>]

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
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt