[AVTCORE] Coments on draft-ietf-avtcore-rfc5285-bis-05

[[e-mail] (Dale R. Worley)]

This is rather late, but it seems that the document is still under
active development.

* Technical items:

4.2.  One-Byte Header

The ID value 15 is reserved.  But there is also the invalid case
where the ID field is 0 and the len field is non-zero.  That case
should probably be included in the same exception processing as for ID
value 15.

5.  SDP Signaling Design

   A usable mapping MUST use IDs in the valid range, and each ID in this
   range MUST be used only once for each media (or only once if the
   mappings are session level).

It would be useful to state early in this section that in order to
reduce the complexity of negotiating identifiers, a valid SDP must
not have mapping attributes (extmap) at both the session level and the
media level.  Also, that it is semantically equivalent to have a set
of extmaps at the session level and to have the same set of extmaps
duplicated in each media section.  In particular, if an offer contains
extmaps at the session level and the answerer wishes to modify the
extension mapping for one media stream but not the others, it can move
the extmaps from the session level of the offer to every media section
in the answer, and then modify the extmaps in the desired media
section.

There is some vagueness about the use of extmaps using identifiers
outside the valid range, and the use of duplicate IDs.  At one point,
it seems to be stated that for a session description to be acted upon,
only valid identifiers can be specified, and each can be specified
only once -- but that in an offer/answer situation, the offer can use
duplicate identifiers, and can use identifiers in the extended range,
and the answer then produces SDP that obeys the validity rules.  Then
elsewhere, it is said that the answer can have extmaps in the extended
range.  I think there needs to be a clear summary of the various
combinations that can happen during offer/answer of duplicated
identifiers and identifiers in the extended range, because this sort
of behavior pattern is unusual in SDP.

Also, if an answer uses a different ID for a URI than the offer, do
both the offerer and answerer use the answer's IDs?  The text suggests
so, but that is different from how payload types are used.  In any
case, the rules need to be made very clear.

There's also a question of what URIs may be used and how they are
considered.  The term "absolute URI" seems to be poorly defined, since
RFC 3986 uses "absolute URI" to mean what matches the production
"absolute-URI", but that means a URI without a fragment part.  I think
here we mean "a URI containing a 'path-absolute'", but I don't think
that admits URNs.  (And all existing registered extension names are
URNs.)  So this definition needs to be cleaned up.

I think in reality, these URIs are used as nearly-opaque identifiers;
the exception being that a device that accepts the extension labeled
with a URI will necessarily know what the rules are for testing for
equality with that URI.

But is there any reason to allow URIs that aren't URNs?  (Within URNs,
issues of equality testing, etc., are generally well-specified.)  The
text seems to suggest that the URI can be used to look up the meaning
of the extension in some way other than using the URI to index a
database, but I don't see how that can be made to work in practice.
And once the URIs are indexes, it seems best to limit them to being
URNs.  Then again, XML namespaces are named by URIs, not just URNs.

The meaning of the sendonly, etc. attributes seems to be inadequately
specified.  Given that an extmap attribute can exist at the session
level even when media streams have different direction attributes, it
seems that the only simple rule is that the direction attribute in the
extmap determines which direction(s) the extension may be sent in
theoretically, but because of media directionality, the header will
only be sent in a direction that is within the directionality of the
extmap and also the directionality of the stream.

Similarly to media directionality, the directionality given in an
answer for a particular extmap URI must be a subset of the
directionality given in the offer.

   URIs
   that contain a domain name SHOULD also contain a month-date in the
   form mmyyyy.

There isn't any standardized way to do this.  Should there be some
indicator that the month indication is ad hoc, such as:

   URIs that contain a domain name SHOULD in some manner contain a
   month-date in the form mmyyyy.

--

   If the resource or document defines several extensions,
   then the URI MUST identify the actual extension in use, e.g., using a
   fragment or query identifier (characters after a '#' or '?' in the
   URI).

This text suggests that the URI in some way can be processed to
directly identify a "resource or document".  But there is no general
resolution process for doing that; the method by which the URI
indicates the extension definition is entirely outside this
specification.  In practice, the device contains a small table of URIs
that it recognizes.

Within that conceptual structure, the rule is simply that different
extensions must be identified by different URIs, and as a consequence,
URIs that differ only by fragment or query identifier identify
different extensions.

   When SDP signaling is used for the RTP session, it is the presence of
   the 'extmap' attribute(s) that is diagnostic that this style of
   header extensions is used, not the magic number indicated above.

I *think* this means that the presence of this SDP signaling implies
that all RTP header extensions will be of the type defined here,
regardless of their 16-bit identifiers.  But that's not a useful fact,
because the header extension can't be parsed without first knowing
which variety of extension is it, and that is determined by the
16-bit identifier value.  So I think the best you can do is say

   When SDP signaling is used for the RTP session, if 
   'extmap' attribute(s) are present, all RTP extension headers MUST
   be of one of the two forms specified in this document.

6.  SDP Signaling for support of mixed one byte and two bytes header

For simplicity, it seems that you'd want to allow the positioning of
extmap-allow-mixed (session level vs. media level) to be independent
of the positioning of extmap.  I expect this is intended, but it's
worth stating it explicitly, given the limitations on how extmap
attributes can be placed.

Given that it is envisioned that some systems may not support the
two-byte form (section 4.1.2 paragraph 2), should there be a way to
enforce the use of only the one-byte form?  In particular, this might
be desirable:

    If all of the identifier values in the offer are less than 15,
    then all of the identifier values in the answer MUST be either
    less than 15 or greater than 4095.  If all of the identifier
    values in the answer are less than 15, then the RTP stream MUST
    NOT user the two-byte extension form.

That allows both the offerer and the answerer to force use of the
one-byte form.

7.  Offer/Answer

   Extensions, with their directions, MAY be signaled for an "inactive"
   stream.  It is an error to use an extension direction incompatible
   with the stream direction (e.g., a "sendonly" attribute for a
   "recvonly" stream).

This is unworkable if the extension attribute is at the session level.
E.g., there could be one media stream that is "sendonly" and one that
is "recvonly", which would require all extension attribute directions
to be "inactive".  I think you need to allow the extension attribute
direction specifications to be orthogonal to the medial directions.

   Local identifiers in the valid range inclusive in an offer or answer
   MUST NOT be used more than once per media section (including the
   session-level section).  A session update MAY change the direction
   qualifiers of extensions under use.  A session update MAY add or
   remove extension(s).  Identifiers values in the valid range MUST NOT
   be altered (remapped).

There is a lot here.  The duplicate identifiers are clearly allowed --
that is discussed elsewhere in these comments.  A session update may
change the direction qualifiers, of course, because a session update
is an entirely new negotiation, so that need not be stated.  Similarly
for adding or removing extensions.

But what does the last sentence mean?  There is much discussion of
remapping identifier values in earlier sections.  Does it perhaps mean
that if an identifier value goes into use (by being in the valid range
and in the answer), then a session update offer MAY NOT map it to a
different URI?  This may be a good rule, because it ensures that RTP
extension headers in-flight won't be misinterpreted.  But it might be
better phrased:

   A session update offer or answer may not specify a different URI
   for an identifier that is in currently in use in the session (i.e.,
   that is in the valid range and was specified in the answer that
   describes the session).  (However, an identifier that is currently
   in use can be unmapped in one session update offer/answer cycle and
   then subsequently mapped to a different URI in a later session
   update.)

--

   Either party MAY include extensions in the stream other than those
   negotiated, or those negotiated as "inactive", for example, for the
   benefit of intermediate nodes.  Only extensions that appeared with an
   identifier in the valid range in SDP originated by the sender can be
   sent.

This seems odd.  If the negotiated SDP (the answer) doesn't contain an
extmap or marks it inactive, why should both endpoints be allowed to
send it?  And isn't it the identifier number in the answer that
control (because the answer is allowed to remap the extension types in
the offer)?  I think this needs to be rethought.

8.  BNF Syntax

   (only absolute URIs are permitted here)

If we maintain this restriction, a clear definition or reference for
"absolute URI" needs to be made.

The BNF allows five-digit identifiers, whereas the text allows
identifiers only up to 4351.  I see that the intention is that the
range may be increased later, but I would think four digit numbers
would suffice.

9.  Security Considerations

   Extensions usage is negotiated using [RFC3264] so integrity
   protection and end-to-end authentication MUST be used.

This seems remarkably strict, since roughly nobody uses end-to-end
integrity/authentication in SIP.

* Editorial items:

Abstract

   The document obsoletes RFC5285

s/The/This/

Add a final full stop.

1.  Introduction

   both one byte and two bytes header

I think the standard usage is "two byte" when that phrase is being
used as a modifier.

4.1.  General

   The value defined for an RTP extension
   (defined below for the one-byte and two-byte header forms) is ...

This is awkwardly phrased; what is "the value defined for an
extension".  Unfortunately, RFC 3550 didn't give a proper name to the
field in question.  I suggest copying the wording in the introduction,
which was clearer:

   The 16-bit identifiers for the two forms of RTP extension defined
   here are only architectural constants (e.g., for use by network
   analyzers); it is the out-of-band negotiation/definition (e.g., in
   SDP) that is the definitive indication that this header extension
   is present.

4.1.1.  transmission considertions

s/considertions/considerations/

actually,

s/transmission considertions/Transmission Considerations/

4.1.2.  Header Extension type consideration

s/type consideration/Type Consideration/

Perhaps change "one-byte form" and "two-byte form" to "one-byte
format" and "two-byte format"?  The latter read better to me.

   Each RTP packet with an RTP header extension following
   this specification will indicate if it contains one or two byte
   header extensions through the use of the "defined by profile" field.

Better, "...though the value of the...".

   Transmitters SHOULD NOT use the two-byte form when all extensions are
   small enough for the one-byte header form.

You should probably add, "... when all extension use IDs less than 15 and
the extension data is small enough ...".  That makes it correct, and
makes it clearer why negotiating an ID over 14 signals an intention to
use the two-byte form.

   Transmitters that intend
   to send the two-byte form SHOULD use IDs above 14 if they want to let
   the Receivers know that they intend to use two-byte form ...

Better to say "... SHOULD negotiate the use of IDs above 14 to let ...".

4.3.  Two-Byte Header

   For the purposes of signaling, this field is treated
   as a special extension value assigned to the local identifier 256.

This is awkwardly phrased, since this isn't a signaling datum.  I
assume you mean

   This field is treated as the data field of the extension assigned
   to the local identifier 256.  (Of course, an extension assigned
   identifier 256 must define the interpretation of four-bit values.)

--

   Note that there is one ID space for both one-byte
   and two-byte form this means that the lower values (1-14) can be used
   in the 4-bit ID field in the one-byte header format as well.

The clauses don't join together correctly.  Perhaps:

   Note that there is one ID space for both one-byte
   and two-byte forms.  This means that the lower values (1-14) can be used
   in the 4-bit ID field in the one-byte format with the same meanings.

5.  SDP Signaling Design

   An extension URI with the same attributes MUST NOT appear more than

It would be clearer if you phrased this:

   There must not be multiple identifier definitions applying to
   one stream with the same extension URI and extension-attributes.

(Then s/<extensionattributes>/<extension-attributes>/ in the BNF.)

   ... can appear
   differently parameterized for the same stream.

s/differently parameterized/with different extension-attributes/

   In addition, as noted above,
   the IDs used MUST be unique for each stream type for a given media,
   or for the session for session-level declarations.

It is not clear what this means.  As noted above, the same extended ID can be
used multiple times in an offer.  And what a "stream type" is is not
defined.

   Each local identifier potentially used in the stream is mapped to a
   string using an attribute of the form:

What does "is mapped to a string" mean?  Does it mean "is mapped to an
extension identified by a URI"?

   is an integer in the valid range inclusive (0
   is reserved for padding in both forms, and 15 is reserved in the one-
   byte header form, as noted above)

The phrase "valid range inclusive" is used in several places and is
unclear.  I think "valid range" is what is intended.

There's no particular reason to partially describe the valid range
here, as it has already been explained.  And the text about 15 is
irrelevant, as ID 15 can validly be used in two-byte headers.

   <direction> is one of
   "sendonly", "recvonly", "sendrecv", or "inactive" (without the
   quotes) with relation to the device being configured.

Within the context of the above proposal that the extmap direction
value is orthogonal to stream direction attribute, it should be noted
here that "sendrecv" is the default value.

6.  SDP Signaling for support of mixed one byte and two bytes header

   The formal definition of this attribute is:

      Name: extmap-allow-mixed

I would expect this formal definition to be in the IANA considerations
section.  Indeed, it *is* in the IANA considerations.  Why is it
duplicated here?

   When doing SDP Offer/Answer [RFC3264] an offering client that wishes
   to use both one and two bytes extensions MUST include the attribute
   "a= extmap-allow-mixed " in the SDP offer.  If "a= extmap-allow-mixed
   " is present in the offer SDP, the answerer that supports this mode
   and wishes to use it SHALL include the "a=extmap-allow-mixed "
   attribute in the answer.

There are extra spaces in the various occurrences of
"a=extmap-allow-mixed", which triggers poor line breaks in the current
draft.

   In cases the answer has been excluded,

I think s/the answer/where the attribute/.

   In cases the answer has been excluded,
   neither clients SHALL use mixed one bytes and two bytes extensions in
   the same RTP stream but MAY use one-byte or two-bytes form (see
   section 4.1.2).

I think you want to clarify this as

   In cases where the attribute has been excluded,
   both clients SHALL NOT use mixed one bytes and two bytes extensions in
   the same RTP stream.  But they MAY use either the one-byte or two-byte
   form exclusively.

7.  Offer/Answer

   If an offer or answer contains session-level mappings (and hence no
   media-level mappings), and different behavior is desired for each
   stream, then the entire set of extension map declarations MAY be
   moved into the media-level section(s) of the SDP.  (Note that this
   specification does not permit mixing global and local declarations,
   to make identifier management easier.)

Above I propose hoisting this to an earlier position in the document.

   If an extension map is offered as "sendrecv", explicitly or
   implicitly, and asymmetric behavior is desired, the SDP MAY be
   modified to modify or add direction qualifiers for that extension.

What does this mean?  Do you mean if *the answerer* desires asymmetric
behavior?  I think you want to replace this paragraph and the
following two paragraphs with something like

   If the answerer desires to not use an extension in a direction
   which the extmap attribute in the offer allows, it can change the
   direction attribute in the extmap attribute to a more restrictive
   value.  I.e., "sendrecv" can be replaced with another value, and
   "sendonly" and "recvonly" can be replaced with "inactive".  If the
   answerer does not understand the extension or does not desire to
   use it, it should remove the extmap attribute in the answer (in
   preference to changing its direction to "inactive").

--

   If a party wishes to offer mutually exclusive alternatives, then
   multiple extensions with the same identifier in the (unusable) range
   4096-4351 MAY be offered; the answerer SHOULD select at most one of
   the offered extensions with the same identifier, and remap it to a
   free identifier in the valid range, for that extension to be usable.

I've discussed this above, but additionally, "(unusable) range" is
peculiar.  There needs to be a term for the range 4096 to 4351.  I
think I've used the term "extended range" above.

   It is always allowed to place the offered identifier value "as is" in
   the SDP answer (for example, due to lack of a free identifier value
   in the valid range).  Extensions with an identifier outside the valid
   range MUST NOT, of course, be used.  If needed, the offerer or
   answerer can update the session to make space for such an extension.

I think this would be clearer as

   An answerer may copy an extmap for an identifier in the extended
   range into the answer to indicate to the offerer that it supports
   that extension.  Of course, such an extension cannot be used, since
   there is no way to specify them in an extension header.  If needed,
   the offerer or answerer can update the session to assign a valid
   identifier to that extension URI.

11.  Changes from RFC5285

   The support for this case is negotiated
   using a new SDP attribute "extmap-allowed-mixed" specified in this
   document.

s/extmap-allowed-mixed/extmap-allow-mixed/

[END]