[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Outstanding issues on the HDREXT draft
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
At 03:14 PM 2/11/2008 -0800, Dave Singer wrote:
>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]
> >===========================
> >
> >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).
>
>This is Mike Dolan's baby and I'll let him respond.
>
> >
> >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).
>
>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.
>
> >
> >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.
>
>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."
> >
> >Move the examples to follow the rest of the moved text in section 9.1.
>
>But the examples are examples of what the section is about (SDP) not
>what 9.1 is about (IANA considerations).
>
> >
> >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."
>
>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:
> >
> >"Here is the formal declaration ...".
> >
> >Tom Taylor
>
>
>--
>David Singer
>Apple/QuickTime
>_______________________________________________
>Audio/Video Transport Working Group
>avt at ietf.org
>http://www.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
http://www.ietf.org/mailman/listinfo/avt