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

[Roni Even <[e-mail]>]

Dale,
Thanks for the detailed review. 
Inline
Roni

> -----Original Message-----
> From: Dale R. Worley [mailto:[e-mail]]
> Sent: יום ה 02 פברואר 2017 04:47
> To: [e-mail]
> Cc: Roni Even; [e-mail]
> 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.
> 
> 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.
[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
> of behavior pattern is unusual in SDP.
[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.
> 
> 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.
[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.
> 
> 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.
[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
>    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.
[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
> 
> --
> 
>    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), 
[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:
> 
>     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.
[Roni Even] why do we need to force one-byte extension only. 

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

> 
> 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.)
[Roni Even] it is probably not may not but must not and this is what the text say about remapping
> 
> --
> 
>    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:
[Roni Even] I will try to address them in the new revision
> 
> 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]