Subject: [AVT] Outstanding issues on the HDREXT draft

From: Tom Taylor <[email-masked]>
Date: Mon, 11 Feb 2008 10:43:09 -0500

OK, here's another try. URIs are OK, but I believe specification of their 
construction should be consolidated in the IANA section, since they are directly 
related to registration.

1. The APP bits controversy [NO CHANGE]
===========================

The conclusion was that APP bits are not a good way to go. The general consensus
of the AVT community is in favour of explicit rather than opaque conveyance of
information.

Two choices: require Standards Action for each profile that defines APP bits
values and IANA registration of the profile identifier that would be used in
signalling, or set a fixed value for the entire header. I suggest using the
fixed value 0x4121 (complement of 0xBEDE, large enough and arbitrary enough to
avoid collision with old header extensions in the wild).

2. Inconsistent length specifiers [NO CHANGE]
=================================

The 4+4 form disallows zero-length data (section 4.2).  The 8+8 form allows it
(section 4.3). It seems inconsistent to expand field sizes and then look for
ways to chisel bits away (a remark that also applies to the APP bits). Length
should be defined the same way in both forms (i.e., 0 implies one byte of
extension data).

3. Identification of header extensions [Changed to reflect decision to use URNs]
======================================

As suggested in the covering note, I believe that many of the instructions in 
section 5 really belong in the IANA Considerations section, since they deal with 
matters of specification rather than negotiation.

Section 5 changes:
------------------

Third paragraph: retain the first sentence: "Each extension is named by a URI." 
Move the rest of this paragraph and the next one to section 9.1 (merging text 
suggested below).

Retain the next paragraph, beginning: "An extension URI with the same attributes 
...".

Move the next paragraph, beginning: "For extensions defined in RFCs ...", to 
follow the other text moved to section 9.1.

Move the next one-sentence paragraph, pointing to the IANA Considerations 
section, up to join and follow "Each extension is named by a URI."

Move the examples to follow the rest of the moved text in section 9.1.

After all that, section 5 will read as follows:

5.  SDP Signaling Design

    The indication of the presence of this extension, ... [unchanged]

    A usable mapping MUST use IDs in the valid range, ... [unchanged]

    Each extension is named by a URI. The registration requirements are detailed
    in the IANA Considerations, below.

    An extension URI with the same attributes MUST NOT ... [unchanged]

    The mapping may be provided per media-stream ... [all the rest of the 
section unchanged]

IANA Considerations (section 9.1)
---------------------------------

I suggest the section begin with the following text.

"IANA SHALL maintain a registry of RTP header extension names. Insertion into 
this registry is under the requirements of "Specification Required" as defined 
in [RFC2434bis].

"The IANA registry SHALL contain four pieces of information: the RTP
header extension name itself, a short descriptive phrase, and the
identity of the specification, and the name of a contact within the organization 
publishing that specification."

Then insert the material pulled from section 5. After that, continue with the 
existing material in section 9.1, beginning with:

"Here is the formal declaration ...".

Tom Taylor

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

---

From: Dave Singer <[email-masked]>
Date: Mon, 11 Feb 2008 15:14:24 -0800

At 10:43  -0500 11/02/08, Tom Taylor wrote:
>OK, here's another try. URIs are OK, but I believe specification of 
>their construction should be consolidated in the IANA section, since 
>they are directly related to registration.

OK, this one I can respond to.

>1. The APP bits controversy [NO CHANGE]

This is Mike Dolan's baby and I'll let him respond.

>2. Inconsistent length specifiers [NO CHANGE]

This is also Mike's, but I will say that though the 4-bit has a +1 
design and the 8-bit doesn't need it, the situation is easily 
comprehensible, explained, and implementable.  I think it could be 
argued that the gain is having 0-byte values in 8 bits is worth the 
slight cost in text.

>As suggested in the covering note, I believe that many of the 
>instructions in section 5 really belong in the IANA Considerations 
>section, since they deal with matters of specification rather than 
>negotiation.

OK.  I don't have a technical problem with the changes below, but I 
am worried about clarity.  See below.

>
>Section 5 changes:
>------------------
>
>Third paragraph: retain the first sentence: "Each extension is named 
>by a URI." Move the rest of this paragraph and the next one to 
>section 9.1 (merging text suggested below).

But 9.1 is IANA.  Whether or not the extension is *registered* it 
must be *named* by a URI., and the requirements on that URI are 
independent of INA.    Perhaps this is in the wrong place (it's not 
unique to SDP), but IANA isn't an improvement!

>
>Retain the next paragraph, beginning: "An extension URI with the 
>same attributes ...".
>
>Move the next paragraph, beginning: "For extensions defined in RFCs 
>...", to follow the other text moved to section 9.1.

That assumes (probably correctly) that all extensions defined in RFCs 
will also be registered.  OK.

>
>Move the next one-sentence paragraph, pointing to the IANA 
>Considerations section, up to join and follow "Each extension is 
>named by a URI."
>

But the examples are examples of what the section is about (SDP) not 
what 9.1 is about (IANA considerations).

>    The mapping may be provided per media-stream ... [all the rest of 
>the section unchanged]
>
>
>
>"IANA SHALL maintain a registry of RTP header extension names. 
>Insertion into this registry is under the requirements of 
>"Specification Required" as defined in [RFC2434bis].
>
>identity of the specification, and the name of a contact within the 
>organization publishing that specification."

The following is already in the formal declaration;  by 'name of a 
contact' I assume you mean a person's name.  Is that needed (or even 
desirable)?  People move around awfully fast.

    o  Information required: (a) The desired extension identifier URI,
       and (b) a formal reference to the publicly available
       specification.  For extensions defined in RFCs, the URI is
       recommended to be of the form urn:ietf:params:rtp-hdrext:, and the
       formal reference is the RFC number of the RFC documenting the
       extension.

I certainly have no problem adding a requirement for a short 
descriptive phrase;  good idea.

>
>Then insert the material pulled from section 5. After that, continue 
>with the existing material in section 9.1, beginning with:
>

-- 
David Singer
Apple/QuickTime

---

From: Tom Taylor <[email-masked]>
Date: Mon, 11 Feb 2008 19:28:17 -0500

Trimmed to specific discussion points, see [PTT].

> At 10:43  -0500 11/02/08, Tom Taylor wrote:
...
> argued that the gain is having 0-byte values in 8 bits is worth the 

[PTT] I'm concerned that the inconsistency would be a trap for the unwary 
implementer.
>> 3. Identification of header extensions [Changed to reflect decision 
...
> unique to SDP), but IANA isn't an improvement!

[PTT] I believe this is the heart of a misalignment of intention between you and 
the ADs. I believe their intention is that every extension must be registered. 
Hence the required form of the URI becomes a criterion for successful registration.
>> Retain the next paragraph, beginning: "An extension URI with the 
...
> what 9.1 is about (IANA considerations).

[PTT] The examples I'm talking about are not the ones at the end of the section, 
but these:

    An example (this is only an example), where 'avt-example-metadata' is
    the hypothetical name of a header extension, might be:

    urn:ietf:params:rtp-hdrext:avt-example-metadata

    An example name not from the IETF (this is only an example) might be:

    http://example.com/082005/ext.htm#example-metadata
...

> desirable)?  People move around awfully fast.

[PTT] Good point. What I'm thinking of is actually a contact address. The 
organizations I'm used to dealing with (e.g. ITU-T) generally have invariant 
addresses available.

...

---

From: Michael A Dolan <[email-masked]>
Date: Mon, 11 Feb 2008 16:28:50 -0800

Tom-

I concur with what Dave says below.  To the points he tossed to me....

Regarding the 8+8 design - like the 4+4 design, it stems from an 
existing deployment. So from my perspective, changing it at this 
point needs disclosure of some sound technical flaw. The header value 
is, from a functional point of view, arbitrary and your proposal for 
0x4121 is no less arbitrary than the one chosen (and currently in 
use).  I see no value in changing it, and quite a bit of nuisance if we do.

Regarding the app bits, I believe it is not quite accurate to 
summarize them as a "controversy".  Their existence value is that 
there are logically some kinds of extensions that are booleans and 
therefore there is value in having no actual extensions and using a 
few bits in the "defined_by_profile" for more efficient signaling of 
booleans.  Again, like the 8+8 design overall, these are in use today 
and setting them to a constant would be a problem for those 
implementations. But mostly, I don't see the argument for removing 
them, given their obvious value.

Like Dave, I don't personally see the benefit/argument for harmony in 
the semantics associated with zero length extensions. If you run out 
of boolean app bits, more boolean value extensions can then be 
signaled by the mere presence of the extension.

Regards,

         Mike

---

From: Dave Singer <[email-masked]>
Date: Mon, 11 Feb 2008 16:40:07 -0800

OK, awaiting Mike on the 8+8 questions.

At 19:28  -0500 11/02/08, Tom Taylor wrote:
>>>Section 5 changes:
>>>------------------
>>>
>>>Third paragraph: retain the first sentence: "Each extension is 
>>>named by a URI." Move the rest of this paragraph and the next one 
>>>to section 9.1 (merging text suggested below).
>>
>[PTT] I believe this is the heart of a misalignment of intention 
>between you and the ADs. I believe their intention is that every 
>extension must be registered. Hence the required form of the URI 
>becomes a criterion for successful registration.

We can certainly say that every extension SHOULD be registered; it's 
clearly desirable.  We cannot, however, force  it, can we?  The spec. 
is external, the usage is external;  we have no leverage at all. 
What is the 'or else'?   Should I insert such a statement?  There are 
clearly periods of time when even an extension that will be 
registered, has not yet been, but may be in experimental use (indeed, 
I suggest that people trying things out before they're finalized is 
actually desirable).

Notwithstanding that, perhaps we need a section on the requirements 
of the label, for clarity independent of both the SDP and the IANA 
sections?

>>But the examples are examples of what the section is about (SDP) 
>>not what 9.1 is about (IANA considerations).
>
>[PTT] The examples I'm talking about are not the ones at the end of 
>the section, but these:
>

ah, these would also be ideal in a section on the label itself.

>>contact' I assume you mean a person's name.  Is that needed (or 
>>even desirable)?  People move around awfully fast.
>
>[PTT] Good point. What I'm thinking of is actually a contact 
>address. The organizations I'm used to dealing with (e.g. ITU-T) 
>generally have invariant addresses available.

Organizational contact information, sure.  No probs.
-- 
David Singer
Apple/QuickTime
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www.ietf.org/mailman/listinfo/avt

---

From: Tom Taylor <[email-masked]>
Date: Mon, 11 Feb 2008 20:44:33 -0500

Responses marked [PTT].

> use).  I see no value in changing it, and quite a bit of nuisance if we do.
[PTT] Agreed, I was arbitrary. I was only worried that 0x1000 is so obvious that 
someone may have used it.

> them, given their obvious value.

[PTT] OK, so you choose the option that creates a profile registry. The whole 
point here is to create interoperable standards, and you can't do that with 
secret bits.
> signaled by the mere presence of the extension.
[PTT] Again, think of the poor implementer trying to debug his or her software, 
having overlooked the inconsistency between the two specifications. 'Foolish 
consistency is the hobgoblin of small minds', but I don't think insisting on 
consistency is foolish here.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www.ietf.org/mailman/listinfo/avt

---

From: Tom Taylor <[email-masked]>
Date: Mon, 11 Feb 2008 20:49:16 -0500

Inline with [PTT2]

Dave Singer wrote:
> clearly desirable.  We cannot, however, force  it, can we?  The spec. is 
> external, the usage is external;  we have no leverage at all. What is 
> the 'or else'?   Should I insert such a statement?  There are clearly 
> periods of time when even an extension that will be registered, has not 
> yet been, but may be in experimental use (indeed, I suggest that people 
> trying things out before they're finalized is actually desirable).
> 
[PTT2] There is the oft-quoted statement: "We are not the protocol police." 
However, it is our job to define interoperable standards. If someone chooses to 
ignore the standard, that's their problem. Experiments should be run in a closed 
environment, to prevent collisions.

> Notwithstanding that, perhaps we need a section on the requirements of 
> the label, for clarity independent of both the SDP and the IANA sections?
> 
[PTT2] Not really -- once you've said the syntax is a URI, you've said 
everything a parser needs. Hence all the rest has to do with registration.
...
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www.ietf.org/mailman/listinfo/avt

---

From: Michael A Dolan <[email-masked]>
Date: Tue, 12 Feb 2008 07:38:22 -0800

Tom-

The app bits are no more "secret bits" than the extensions. They are 
scoped by the URI that scopes the extensions. If this is not clear, 
then we need to clarify the text.

As to consistency of the length field, it would be highly unlikely 
that any given system would use both 4+4 and 8+8. The designer will 
choose the one that best suits the needs and use it throughout.  I 
believe the text is clear in both cases about the meaning of the 
length field. If the same implementation were expected to do both 
concurrently, then I would see your point.

Regards,

         Mike

At 08:44 PM 2/11/2008 -0500, Tom Taylor wrote:
>>point needs disclosure of some sound technical flaw. The header 
>>value is, from a functional point of view, arbitrary and your 
>>proposal for 0x4121 is no less arbitrary than the one chosen (and 
>>currently in use).  I see no value in changing it, and quite a bit 
>>of nuisance if we do.
>[PTT] Agreed, I was arbitrary. I was only worried that 0x1000 is so 
>obvious that someone may have used it.
>
>>few bits in the "defined_by_profile" for more efficient signaling 
>>of booleans.  Again, like the 8+8 design overall, these are in use 
>>today and setting them to a constant would be a problem for those 
>[PTT] OK, so you choose the option that creates a profile registry. 
>The whole point here is to create interoperable standards, and you 
>can't do that with secret bits.
>>Like Dave, I don't personally see the benefit/argument for harmony 
>>in the semantics associated with zero length extensions. If you run 
>>out of boolean app bits, more boolean value extensions can then be 
>[PTT] Again, think of the poor implementer trying to debug his or 
>her software, having overlooked the inconsistency between the two 
>specifications. 'Foolish consistency is the hobgoblin of small 
>minds', but I don't think insisting on consistency is foolish here.

---

From: Tom Taylor <[email-masked]>
Date: Tue, 12 Feb 2008 11:12:26 -0500

Inline, marked with [PTT].

> then we need to clarify the text.
[PTT] The problem is that the AAAA bits are not associated with a specific 
extension, but the URI is. The word "profile" is rightly used here to mean a 
profile for the usage of the header extension mechanism. To make this work, you 
have to:

- provide a means to signal which profile you are using
- provide a publicly available specification of the profile
- register the profile identifier that is used in the signalling.

All this is missing from the existing text.

... or on reflection, do you mean to say that an extension may be specified as a 
Boolean extension using APPbit x (x from 0 to 3)? If so, that text is definitely 
missing. I also don't see why this wouldn't also apply to the 4+4 mechanism -- 
we don't really need the full 0xBEDE.

> concurrently, then I would see your point.

[PTT] You're making a rather good case here for documenting these as separate RFCs!

---

From: Michael A Dolan <[email-masked]>
Date: Tue, 12 Feb 2008 14:16:12 -0800

Tom-

I see your point about the scope of the app bits.  The text is indeed 
not at all clear about these "extensions" and their relation to the 
URI signaling on par with the tag/len/value extensions.  I'll propose 
some edits to the ID "soon" to hopefully fix this. My apologies.

To your comments about public specifications, registration, and 
document structure, I think these are broader issues that have 
received notable discussion. There are a number of pros and cons that 
have been weighed to arrive where we are. Is there something specific 
to the app bits in particular that I am not understanding?

Thanks,

         Mike

At 11:12 AM 2/12/2008 -0500, Tom Taylor wrote:
>>The app bits are no more "secret bits" than the extensions. They 
>>are scoped by the URI that scopes the extensions. If this is not 
>>clear, then we need to clarify the text.
>[PTT] The problem is that the AAAA bits are not associated with a 
>specific extension, but the URI is. The word "profile" is rightly 
>used here to mean a profile for the usage of the header extension 
>mechanism. To make this work, you have to:
>
>... or on reflection, do you mean to say that an extension may be 
>specified as a Boolean extension using APPbit x (x from 0 to 3)? If 
>so, that text is definitely missing. I also don't see why this 
>wouldn't also apply to the 4+4 mechanism -- we don't really need the 
>full 0xBEDE.
>
>>>>currently in use).  I see no value in changing it, and quite a 
>>>>bit of nuisance if we do.
>>>[PTT] Agreed, I was arbitrary. I was only worried that 0x1000 is 
>>>so obvious that someone may have used it.
>>>
>>>>there are logically some kinds of extensions that are booleans 
>>>>and therefore there is value in having no actual extensions and 
>>>>using a few bits in the "defined_by_profile" for more efficient 
>>>>signaling of booleans.  Again, like the 8+8 design overall, these 
>>>>are in use today and setting them to a constant would be a 
>>>>problem for those implementations. But mostly, I don't see the 
>>>>argument for removing them, given their obvious value.
>>>[PTT] OK, so you choose the option that creates a profile 
>>>registry. The whole point here is to create interoperable 
>>>standards, and you can't do that with secret bits.
>>>>Like Dave, I don't personally see the benefit/argument for 
>>>>harmony in the semantics associated with zero length extensions. 
>>>>If you run out of boolean app bits, more boolean value extensions 
>>>>can then be signaled by the mere presence of the extension.

---

From: Dave Singer <[email-masked]>
Date: Mon, 18 Feb 2008 11:38:21 +0900

At 20:49  -0500 11/02/08, Tom Taylor wrote:
>>>>>named by a URI." Move the rest of this paragraph and the next 
>>>>>one to section 9.1 (merging text suggested below).
>>>>
>>>>independent of INA.    Perhaps this is in the wrong place (it's 
>>>>not unique to SDP), but IANA isn't an improvement!
>>>
>>We can certainly say that every extension SHOULD be registered; 
>>it's clearly desirable.  We cannot, however, force  it, can we? 
>>The spec. is external, the usage is external;  we have no leverage 
>>at all. What is the 'or else'?   Should I insert such a statement? 
>>There are clearly periods of time when even an extension that will 
>>be registered, has not yet been, but may be in experimental use 
>>(indeed, I suggest that people trying things out before they're 
>>finalized is actually desirable).
>>
>[PTT2] There is the oft-quoted statement: "We are not the protocol 
>police." However, it is our job to define interoperable standards. 
>If someone chooses to ignore the standard, that's their problem. 
>Experiments should be run in a closed environment, to prevent 
>collisions.

I disagree on several grounds.

a) experiments and interoperability can and should be run between 
multiple recipients;  we learn something when people show trials with 
internet drafts, before the RFC is published

b) I believe -- and most standards bodies insist -- that normative 
requirements in specs be used *only for testable aspects of 
implementations*. That is, for example, one would change a MUST to a 
SHOULD for something that said that a string must be a true 
description of the content of an image  -- it's not testable. 
Likewise here, you're asking for a must for something that is nothing 
to do with implementations;  I think (and most standards bodies 
think) it's inappropriate.

---

From: Tom Taylor <[email-masked]>
Date: Sun, 17 Feb 2008 22:04:46 -0500

The basic point is that the IETF insists that the standards it creates should 
result in interoperable implementations. Thus the standards address not only 
implementation issues, but also process issues that have to be resolved to 
achieve this result.

Having taken this hard line, I will note that some IANA registries also provide 
for a private namespace in addition to the public one. The intent is to allow 
for vendor-specific implementations, but other SDOs have sometimes taken 
advantage of this feature to modify IETF protocols without going through IETF 
process. The Diameter protocol is an example in many respects. Note, however, 
that the process is not totally uncontrolled -- there is still an IANA registry, 
even though no publicly available specification is necessarily required.

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.

Dave Singer wrote:
>>> is external, the usage is external;  we have no leverage at all. What 
>>> is the 'or else'?   Should I insert such a statement? There are 
>> police." However, it is our job to define interoperable standards. If 
>> someone chooses to ignore the standard, that's their problem. 
>> Experiments should be run in a closed environment, to prevent collisions.
> 
> SHOULD for something that said that a string must be a true description 
> of the content of an image  -- it's not testable. Likewise here, you're 
> asking for a must for something that is nothing to do with 
> implementations;  I think (and most standards bodies think) it's 
> inappropriate.
>

---

From: Dave Singer <[email-masked]>
Date: Mon, 18 Feb 2008 16:21:56 +0900

At 22:04  -0500 17/02/08, Tom Taylor wrote:
>The basic point is that the IETF insists that the standards it 
>creates should result in interoperable implementations. Thus the 
>standards address not only implementation issues, but also process 
>issues that have to be resolved to achieve this result.
>
>Having taken this hard line, I will note that some IANA registries 
>also provide for a private namespace in addition to the public one. 
>The intent is to allow for vendor-specific implementations, but 
>other SDOs have sometimes taken advantage of this feature to modify 
>IETF protocols without going through IETF process. The Diameter 
>protocol is an example in many respects. Note, however, that the 
>process is not totally uncontrolled -- there is still an IANA 
>registry, even though no publicly available specification is 
>necessarily required.

I don't know Diameter, sorry.

But there are lots of places in IETF specs where X- names are 
allowed, and they are unregistered and *also subject to collision*. 
One of the points of using URIs was to sharply reduce the risk of 
collision, if properly used, even if they are not registered.

I mean, we have unregistered collision-sensitive payload names, for 
example.  The payload is probably the whole point of the RTP 
protocol, whereas header extensions are *defined* to be ignorable...

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

---

From: Tom Taylor <[email-masked]>
Date: Mon, 18 Feb 2008 03:04:38 -0500

Below.

...
> 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
[email-masked]
http://www.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Mon, 18 Feb 2008 13:25:26 +0000

On 18 Feb 2008, at 08:04, Tom Taylor wrote:
>> subject
> [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.

The community has been using unregistered RTP header extensions for  
over a decade now, without any significant issues. I'm less concerned  
about protecting the RTP architecture in this case, than I am about  
improving documentation, and avoiding namespace collisions.

Colin (not as chair)

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Feb 2008 10:41:35 +0100

Hi sorry for being late into this discussion.

> Hence the required form of the URI becomes a criterion for successful registration.

Tom, I thought we all had agreement on the following. Specification is 
required if one registers it with IANA. It is allowed to use 
private/propreiatry extensions as long as they are idnentified by a 
unique URI.

I hope you haven't lumped me into the "ADs" category in this case. 
Because in this regard I am only a contributor.

Cheers

Magnus Westerlund

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