[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Outstanding issues on the HDREXT draft
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
avt at ietf.org
http://www.ietf.org/mailman/listinfo/avt