Subject: [AVT] Open issue on hdrext draft

From: Tom Taylor <[email-masked]>
Date: Wed, 03 Oct 2007 22:02:36 -0400

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?

Tom Taylor

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

---

From: Dave Singer <[email-masked]>
Date: Wed, 3 Oct 2007 21:14:33 -0700

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.
>
>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

---

From: <[email-masked]>
Date: Thu, 4 Oct 2007 12:32:00 +0300

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:[email-masked]] 
>Sent: 04 October, 2007 07:15
>To: Tom Taylor; IETF AVT WG
>Cc: Cullen Jennings; [email-masked]
>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.
>
>>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.
>>
>>(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.
>>
>>hard-to-get-rid-of experimental identifiers, by making registration a 
>>simple process. His preference was thus toward alternative (a).
>>
>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.
>
>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.
>
>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).
>
>'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.
>
>
>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
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 04 Oct 2007 13:43:49 +0200

> packet appropriately. This speaks for IETF agreed registration (option

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.

> imposes length limitations on application-specific extensions.

Exactly. There is also an implementation issue with increased complexity
to allow multiple mechanisms.

> why do we need to register some headers that are just for experimental

Well, read the draft, or even David's mail properly. For experimentation
or proprietary extensions you only need a unique URI, any unique URI
representing your extension will do.

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. Having an expert look
at any registrations to ensure that they are not totally wacko is in my
book a good thing. 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.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Dave Singer <[email-masked]>
Date: Thu, 4 Oct 2007 08:48:23 -0700

>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).

>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
>book a good thing.

Me too, no dispute here.

>But at the same time put minimal bar on the

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 04 Oct 2007 18:47:46 +0200

Dave Singer skrev:
> 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

In section 9.1 of draft-ietf-avt-rtp-hdrext-13:

   The rtp-hdrext namespace under urn:ietf:params: needs to be created
   for management, referenced to RFCxxxx.  Additions in this namespace
   shall be made on the basis of "Specification Required".

Which indicates that you can add new entires only requiring a
specification which is actually a contradiction to what is written in
Section 5:

   For extensions defined in RFCs, the URI used SHOULD be a URN starting
   "urn:ietf:params:rtp-hdrext:" and followed by a registered,
   descriptive name.  These URNs are managed by IANA.  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.

So I think you need to use the Standards Action level in 9.1 to match
the section 5 text.

> what 'expert review' and with 'publicly available specification required'?
> 
> That's fine by me also.
> 

I think we can allow people to use the public IANA registry for header
extensions as long as there is a reasonable and publicly available.

Thus I would use Expert Review and some requirements on what the Expert
is allowed to approve. Where the primary is: Open publicly available
Specification. But there is likely that some more should be written.

Cheers

Magnus Westerlund

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 4 Oct 2007 20:17:06 -0700

On Oct 4, 2007, at 8:48 AM, Dave Singer wrote:

> 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).

Agree we should keep that questions as a sperate one (and I think we  
will easily get to an answer on it)

---

From: David R Oran <[email-masked]>
Date: Fri, 5 Oct 2007 15:38:27 -0400

On Oct 3, 2007, at 10:02 PM, Tom Taylor wrote:

> 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?
>
I would be happy with (a) or (b) with a mild preference for (b)  
because lack of any review often leads to duplication - essentially  
identical extensions with arbitrarily different syntax, and the  
consequent lost opportunities for interoperabiity.

Dave Oran.

---

From: Tom Taylor <[email-masked]>
Date: Tue, 23 Oct 2007 10:02:36 -0400

This was the last word on the topic, quite a while ago. I think we have 
agreement on Expert Review and a publicly available specification. One of the 
criteria for the expert would be to prevent excessive duplication of 
functionality. What else?

---

From: Dave Singer <[email-masked]>
Date: Wed, 24 Oct 2007 16:27:01 +0800

At 10:02  -0400 23/10/07, Tom Taylor wrote:
>This was the last word on the topic, quite a while ago. I think we 
>have agreement on Expert Review and a publicly available 
>specification. One of the criteria for the expert would be to 
>prevent excessive duplication of functionality. What else?

complies with the requirements of RTP and the hdrext specification, 
for extensions (notably, that the stream is still decodable if the 
extension is ignored or not recognized)

technical consistency (in itself and with RTP), completeness, and 
comprehensibility

does not duplicate functionality in existing IETF specifications 
(including RTP itself), or other extensions already registered

anything else?

-- 
David Singer
Apple/QuickTime

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 25 Oct 2007 11:25:57 +0200

Dave Singer skrev:
>> specification. One of the criteria for the expert would be to prevent
>> excessive duplication of functionality. What else?
> 
> complies with the requirements of RTP and the hdrext specification, for
> extensions (notably, that the stream is still decodable if the extension
> is ignored or not recognized)
> 

Contains a security analysis regarding the content of the header extension.

That it is general applicable, for example point to multi-point safe and
correctly describes limitations if they exist.

Cheers

Magnus Westerlund