Subject: Re: [AVT] Outstanding issues on the HDREXT draft

From: Colin Perkins <[email-masked]>
Date: Sun, 10 Feb 2008 17:15:46 +0000

I also thought we'd settled on using URIs in the conference call last  
September.

Colin

On 9 Feb 2008, at 22:17, Tom Taylor wrote:
> Oh, lovely. I missed some of the correspondence in my review. We  
> settled on Expert Review. The other changes stand, but the IANA  
> considerations section should read as follows:
>
> "IANA SHALL maintain a registry of RTP header extension names. A valid
> name SHALL begin with an alphabetic character followed by one or more
> alphabetic characters, digits, or the underscore character "_".
> 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.
>
> "The designated expert shall ensure that the specification meets  
> the following requirements in addition to those described in  
> [RFC2434bis]:
>
> - complies with the requirements of RTP and RFCxxxx for
> extensions (notably, that the stream is still decodable if the  
> extension
> is ignored or not recognized);
>
> - is technically consistent (in itself and with RTP), complete, and
> comprehensibile;
>
> - does not duplicate functionality in existing IETF specifications
> (including RTP itself), or other extensions already registered;
>
> - contains a security analysis regarding the content of the header  
> extension;
>
> - is generally applicable, for example point to multi-point safe, and
> correctly describes limitations if they exist."
>
>
>
>
> Tom Taylor wrote:
>> Reviewing the correspondence on the HDREXT draft, and re-reading  
>> the draft itself, I identify the following issues and proposed  
>> changes:
>> 1. The APP bits controversy
>> ===========================
>> 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
>> =================================
>> 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
>> ======================================
>> As Cullen has said repeatedly, URIs are not acceptable as  
>> extension identifiers, both because of length considerations and  
>> because we are not prepared to allow other organizations to define  
>> arbitrary extensions without IETF review. The identifiers must be  
>> fixed text values, registered with IANA in accordance with the  
>> IANA Considerations section. This implies the following textual  
>> changes:
>> Section 5: major rewrite.
>> ------------------------
>> Delete the third and fourth paragraphs, beginning respectively:  
>> "Each extension is named by a URI." and "Rationale:". In the next  
>> paragraph, change the first sentence as follows:
>>  From "An extension URI ..." to "An extension name ...".
>> Delete the next two paragraphs, beginning: "For extensions defined  
>> in RFCs ..." and "The registration requirements ...". Delete the  
>> example identifiers following those paragraphs. Aside from the  
>> issue of URI vs. fixed text value, registration requirements and  
>> format should be discussed in one place only.
>> In the informal ABNF in this section, replace "<URI>"  with  
>> "<extName>", and change the explanatory text following this from
>> "where <URI> is a URI, as above, ..."
>> to
>> "where <extName> is an IANA-registered extension name as described  
>> in section 9.1, ..."
>> Change the examples following the paragraph beginning "The formal  
>> BNF syntax ..." to use simple identifiers, i.e.,
>> "Example:
>>    a=extmap:1 ttime
>>    a=extmap:2/sendrecv xmeta short"
>> Section 6, examples:
>> -------------------
>> Delete all occurences of "URI-".
>> Section 7, syntax
>> -----------------
>> Delete the second sentence, beginning "The syntax element 'URI' ...".
>> Change the syntax for extensionname from
>> "extensionname = URI"
>> to
>> "extensionname =  ALPHA 0*[ ALPHA / DIGIT / "_" ]
>>           ; Case-sensitive"
>> I admit I was arbitrary here, and I wouldn't argue with minor  
>> tweaks. BTW, the ABNF reference has now changed to RFC 5234.
>> Delete the rule "URI".
>> IANA Considerations (section 9.1)
>> ---------------------------------
>> I suggest using the expression "extension name" rather than  
>> "identifier" in the section title because "identifier" is used in  
>> the signalling sections to refer to the numeric value rather than  
>> the text name.
>> Replace the entire existing contents of the section with the  
>> following:
>> "IANA SHALL maintain a registry of RTP header extension names. A  
>> valid name SHALL begin with an alphabetic character followed by  
>> one or more alphabetic characters, digits, or the underscore  
>> character "_". Insertion into this registry is under the  
>> requirements of "IETF Review" as defined in [RFC2434bis].
>> "The IANA registry SHALL contain three pieces of information: the  
>> RTP header extension name itself, a short descriptive phrase, and  
>> the identity of the defining RFC."
>> Tom Taylor

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

---

From: Tom Taylor <[email-masked]>
Date: Sat, 09 Feb 2008 17:17:07 -0500

Oh, lovely. I missed some of the correspondence in my review. We settled on 
Expert Review. The other changes stand, but the IANA considerations section 
should read as follows:

"IANA SHALL maintain a registry of RTP header extension names. A valid
name SHALL begin with an alphabetic character followed by one or more
alphabetic characters, digits, or the underscore character "_".
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.

"The designated expert shall ensure that the specification meets the following 
requirements in addition to those described in [RFC2434bis]:

- complies with the requirements of RTP and RFCxxxx 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;

Tom Taylor wrote:
> Reviewing the correspondence on the HDREXT draft, and re-reading the 
> draft itself, I identify the following issues and proposed changes:
> 
> 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).
> 
> 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).
> 
> As Cullen has said repeatedly, URIs are not acceptable as extension 
> identifiers, both because of length considerations and because we are 
> not prepared to allow other organizations to define arbitrary extensions 
> without IETF review. The identifiers must be fixed text values, 
> registered with IANA in accordance with the IANA Considerations section. 
> This implies the following textual changes:
> 
> Delete the third and fourth paragraphs, beginning respectively: "Each 
> extension is named by a URI." and "Rationale:". In the next paragraph, 
> change the first sentence as follows:
> 
> Delete the next two paragraphs, beginning: "For extensions defined in 
> RFCs ..." and "The registration requirements ...". Delete the example 
> identifiers following those paragraphs. Aside from the issue of URI vs. 
> fixed text value, registration requirements and format should be 
> discussed in one place only.
> 
> In the informal ABNF in this section, replace "<URI>"  with "<extName>", 
> and change the explanatory text following this from
> 
> "where <extName> is an IANA-registered extension name as described in 
> section 9.1, ..."
> 
> Change the examples following the paragraph beginning "The formal BNF 
> syntax ..." to use simple identifiers, i.e.,
> 
> "Example:
> 
>    a=extmap:1 ttime
> 
> I admit I was arbitrary here, and I wouldn't argue with minor tweaks. 
> BTW, the ABNF reference has now changed to RFC 5234.
> 
> Delete the rule "URI".
> 
> I suggest using the expression "extension name" rather than "identifier" 
> in the section title because "identifier" is used in the signalling 
> sections to refer to the numeric value rather than the text name.
> 
> Replace the entire existing contents of the section with the following:
> 
> Insertion into this registry is under the requirements of "IETF Review" 
> as defined in [RFC2434bis].
> 
> "The IANA registry SHALL contain three pieces of information: the RTP 
> identity of the defining RFC."
> 
> Tom Taylor
>

---

From: Tom Taylor <[email-masked]>
Date: Sat, 09 Feb 2008 17:01:51 -0500

Reviewing the correspondence on the HDREXT draft, and re-reading the draft 
itself, I identify the following issues and proposed changes:

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

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

As Cullen has said repeatedly, URIs are not acceptable as extension identifiers, 
both because of length considerations and because we are not prepared to allow 
other organizations to define arbitrary extensions without IETF review. The 
identifiers must be fixed text values, registered with IANA in accordance with 
the IANA Considerations section. This implies the following textual changes:

Delete the third and fourth paragraphs, beginning respectively: "Each extension 
is named by a URI." and "Rationale:". In the next paragraph, change the first 
sentence as follows:

Delete the next two paragraphs, beginning: "For extensions defined in RFCs ..." 
and "The registration requirements ...". Delete the example identifiers 
following those paragraphs. Aside from the issue of URI vs. fixed text value, 
registration requirements and format should be discussed in one place only.

In the informal ABNF in this section, replace "<URI>"  with "<extName>", and 
change the explanatory text following this from

to

"where <extName> is an IANA-registered extension name as described in section 
9.1, ..."

Change the examples following the paragraph beginning "The formal BNF syntax 
..." to use simple identifiers, i.e.,

"Example:

    a=extmap:1 ttime

Section 6, examples:
-------------------

Section 7, syntax
-----------------

"extensionname = URI"

to

I admit I was arbitrary here, and I wouldn't argue with minor tweaks. BTW, the 
ABNF reference has now changed to RFC 5234.

Delete the rule "URI".

I suggest using the expression "extension name" rather than "identifier" in the 
section title because "identifier" is used in the signalling sections to refer 
to the numeric value rather than the text name.

"IANA SHALL maintain a registry of RTP header extension names. A valid name 
SHALL begin with an alphabetic character followed by one or more alphabetic 
characters, digits, or the underscore character "_". Insertion into this 
registry is under the requirements of "IETF Review" as defined in [RFC2434bis].

"The IANA registry SHALL contain three pieces of information: the RTP header 
extension name itself, a short descriptive phrase, and the identity of the 
defining RFC."

Tom Taylor

---

From: Tom Taylor <[email-masked]>
Date: Sun, 10 Feb 2008 17:20:25 -0500

OK, I'll re-do my proposals.

>> considerations section should read as follows:
...

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 18 Feb 2008 10:26:10 -0800

> I also thought we'd settled on using URIs in the conference call last

I got to admit I can no longer remember what we agreed on but I had  
some vague memory it was if we could use things that were not in an  
IANA registry, then we agreed we needed the URN but if it was all in  
IANA then I don't think we had agreement on why a URN would be needed.