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

From: [email-masked] (Dale R. Worley)
Date: Wed, 01 Feb 2017 21:46:45 -0500

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]

---

From: Roni Even <[email-masked]>
Date: Mon, 13 Feb 2017 13:37:46 +0000

Dale,
Thanks for the detailed review. 
Inline
Roni

> -----Original Message-----
> From: Dale R. Worley [mailto:[email-masked]]
> Sent: יום ה 02 פברואר 2017 04:47
> To: [email-masked]
> Cc: Roni Even; [email-masked]
> Subject: Coments on draft-ietf-avtcore-rfc5285-bis-05
> 
> 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.
[Roni Even]It says that ID=0 MUST not be used value =0 is padding (both ID and len field) so you are asking for text about what to do if there is  header with 0 in the ID part but some value in the len part. I assume that good policy will be the same as for ID 15 but any error behavior can be expected (ignore all header extension ,treat like padding ...) since this case is not discussed in RFC5285.
> 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.
[Roni Even] this appears later in the 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
[Roni Even] I think that section 7 (offer answer) clarifies that ids from the unusable space are used for mutually exclusive offers. It is an offer answer since it does not make sense to use unusable IDs for descriptive SDP.  as for comparing to sdp offer answer I am not sure that it is a good idea because SDP and offer answer is not very good in offering alternatives.

> 
> 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.
[Roni Even] according to rfc3264 for sendonly and sendrecv the answerer payload type number is used.
> 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
[Roni Even] For extensions defined in RFC URN must be used. As for the case for other URIs, it is there from RFC5285 and I do not think it is good to change the text since we do not know if there are usages.
> 
> 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.
> 
> 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.
[Roni Even] OK, this is understood from the text since you do not send header extensions but adds them to an RTP packet. So I not sure that anyone will think to send RTP header extension to a unidirectional send stream. Yet it may be an interesting case when you support sending the same SDES item in both RTCP, which is  in RFC7941. I assume that in that case only RTCP will be used. 
> 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
> There isn't any standardized way to do this.  Should there be some indicator
> that the month indication is ad hoc, such as:
> 
[Roni Even] I think that this is too late, for RFC URNs are used for any other usages we do not have information to mandate anything
> 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.
> 
> 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
> 

> 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), 
[Roni Even] where does it say it?
should there be a way to enforce the use of
> only the one-byte form?  In particular, this might be desirable:
> 
> That allows both the offerer and the answerer to force use of the one-byte
> form.
[Roni Even] why do we need to force one-byte extension only. 

> 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.
[Roni Even] This will be a change from RC5285, I assume that in your example you must use media level extmap, I think that this is what the text say.
> There is a lot here.  The duplicate identifiers are clearly allowed 
[Roni Even] only in the unusable range. This is not contradictory to the above sentence that talks about valid range
-- 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.

> 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:
> 
[Roni Even] it is probably not may not but must not and this is what the text say about remapping
> 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
> 
> 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.
> 
[Roni Even] I will try to address them in the new revision
> I think the standard usage is "two byte" when that phrase is being used as a
> modifier.
> 
> 4.1.  General
> 
> 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:
> 
> Perhaps change "one-byte form" and "two-byte form" to "one-byte format"
> and "two-byte format"?  The latter read better to me.
> 
> 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
> This is awkwardly phrased, since this isn't a signaling datum.  I assume you
> mean
> 
> 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.
> 
> 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
> 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.
> 
> section.  Indeed, it *is* in the IANA considerations.  Why is it duplicated
> here?
> 
> There are extra spaces in the various occurrences of "a=extmap-allow-
> mixed", which triggers poor line breaks in the current draft.
> 
> behavior?  I think you want to replace this paragraph and the following two
> paragraphs with something like
> 
> 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.
>

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 13 Feb 2017 17:50:35 +0000

> [Roni Even] OK, this is understood from the text since you do not send header extensions but adds them to an RTP packet. So I not sure that anyone will think to send RTP header extension to a unidi…

The convention is to use URLs for proprietary / non-standardized header extensions, and this is existing practice in the wild.  For example, Chrome’s JSEP negotiates http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time.

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 13 Feb 2017 13:35:39 -0500

Thanks for looking at my comments and doing what you can with them.  I
suppose overall, I wish that 5285 was a lot clearer, and in particular,
that it put in one place all the rules that relate offers and answers.
But that would require a complete editorial overhaul.

However, there is are a couple of point that could be addressed.  In
section 4.1.2 paragraph 2, it says

   Since it is expected that (a) the number of extensions in
   any given RTP session is small and (b) the extensions themselves are
   small, the one-byte header form is preferred and MUST be supported by
   all receivers.

This says that all receivers must support the one-byte format.  But I
can't find a similar statement that all receivers must support the
two-byte format, so it seems that support for that format is optional.
And if that's true, it means that a device that can receive only the
one-byte format needs a way to force the sender to only send the
one-byte format.

Another point is:

> > should probably be included in the same exception processing as for
> > ID value 15.
>
> > [Roni Even] It says that ID=0 MUST not be used value =0 is padding
> > (both ID and len field) so you are asking for text about what to do
> > if there is  header with 0 in the ID part but some value in the len
> > part. I assume that good policy will be the same as for ID 15 but
> > any error behavior can be expected (ignore all header extension
> > ,treat like padding ...) since this case is not discussed in
> > RFC5285.

My thinking is that if the draft is careful to specify the processing of
the invalid case of ID=15 in the one-byte format, then it would
similarly make sense for the draft to specify the processing of the
invalid case ID=0,len>0.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 14 Feb 2017 13:09:09 -0500

Jonathan Lennox <[email-masked]> writes:
> The convention is to use URLs for proprietary / non-standardized
> header extensions, and this is existing practice in the wild.  For
> example, Chrome's JSEP negotiates
> http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time.

Yeah, I suppose so.  People use URLs all the time for XML namespaces.
And yet, they could use URNs just as easily (since object-id URNs are
free).

Dale

---

From: Roni Even <[email-masked]>
Date: Wed, 15 Feb 2017 10:34:04 +0000

Dale,
If extmap-allow-mixed is declared it means support for both one-byte and two-byte. Without it  there is no way to signal support for just one-byte (or declare support for two-byte) in RFC5285 . It can be assumed based when the  IDs used in the offer are with IDs 1-14, still it  does not say that in this case only 1-byte are supported. Since this is the text in RFC5285, I am not sure if we can change without agreement from the WG.
Roni

> Sent: יום ב 13 פברואר 2017 20:36
> To: Roni Even
> Cc: [email-masked]; [email-masked]
> Subject: Re: Coments on draft-ietf-avtcore-rfc5285-bis-05
> 
> suppose overall, I wish that 5285 was a lot clearer, and in particular, that it put
> in one place all the rules that relate offers and answers.
> However, there is are a couple of point that could be addressed.  In section
> 4.1.2 paragraph 2, it says
> 
> This says that all receivers must support the one-byte format.  But I can't find
> a similar statement that all receivers must support the two-byte format, so it
> seems that support for that format is optional.
> And if that's true, it means that a device that can receive only the one-byte
> format needs a way to force the sender to only send the one-byte format.
> 
> Another point is:
> 
> > > 4.2.  One-Byte Header
> > >
> My thinking is that if the draft is careful to specify the processing of the
> invalid case of ID=15 in the one-byte format, then it would similarly make
> sense for the draft to specify the processing of the invalid case ID=0,len>0.
> 
> Dale