SDP: Session Description Protocol
draft-ietf-mmusic-rfc4566bis-37

Thanks for addressing my DISCUSS and COMMENTs.

I don't have anything to add (the other IESG evals have covered everything I wanted to say) other than to repeat the thanks for Section 10, and also to thank Zitao for the OpsDir review.

Thank you all for the work put into this document. I appreciate the section 10 about the differences with RFC 4566.

== COMMENTS ==

-- Section 5 (and others) --

Any reason why using an IPv4 examples rather than an IPv6 one? After all, we are in 2019...

-- Section 5.2 --

Rather than using the relatively vague " compressed textual representation of an IP version 6 address of the machine", please refer to RFC 5952.

-- Section 5.7 (and possibly others) --

Is there any reason not to follow RFC 5952 and use lowercase for all IPv6 addresses in this document ?

== NITS ==

-- Section 3.3 --

Using "World Wide Web (WWW)" seems old fashioned to me but no problem ;-)

-- Section 4.5 --

Suggestion to add reference to the ISO character sets.


-- Section 5 --

When using IPv4 unicast addresses, please use the example ones.

Thank you for a well written document. Below are mostly nits, but I think they will help first time implementors.

In Section 1:

electronic mail using the MIME   extensions [RFC5322]

This needs another reference for MIME. E.g. RFC 2045.

In 3.1 “media types” need a Normative reference.

In 4.1:

 Some media types may   redefine this behavior, but this is NOT RECOMMENDED since it   
 complicates implementations (including middleboxes that must parse   the addresses to open
 Network Address Translation (NAT) or firewall   pinholes).

Can you give an example of such redefinition?

In 4.3: the first mention of URI needs a Normative Reference.

In 4.5: ISO 8859-1 needs a reference.

In 5.3:

   The "s=" line MUST NOT be empty and SHOULD contain ISO 10646
   characters (but see also the "a=charset" attribute)

Does this mean that it is affected by a=charset?
Why SHOULD?
The text is 5.4 is better, if the intention is the same.

In 5.5:

“WWW clients“

URIs are used by many types of clients. Suggest dropping “WWW”.

In 6.10:

   Note that a character set specified MUST still prohibit the use of
   bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR).

This doesn’t actually say what you intended. None of the common charsets prohibit these bytes. I think you meant that when using such charsets, these characters MUST NOT be used in values.

In 6.11:

   The "sdplang" attribute value must be a single [RFC5646] language tag
   in the US-ASCII subset of UTF-8

Is “fr-ca” allowed here?
Can you point to a specific ABNF in RFC 5646?
Also, “in the US-ASCII subset of UTF-8“ is either redundant or confusing, as language tags are always in U-ASCII.

In 8.1:

  Encoding considerations:         SDP files are primarily UTF-8 format text

This is not correct use of this field. I think you should say “8bit” or “binary” here.

In 8.2.2:

   Registrations MUST reference an RFC describing the protocol.
   Such an RFC MAY be Experimental or Informational, although it is
   preferable that it be Standards Track.

I just want to confirm that an Independent Stream RFC is allowed here?

Thank you for addressing my DISCUSS. Original COMMENT is below.

-----

Section 5.1: 

Since both this document and RFC 4566 specify version 0 and this version makes semantic and syntactic changes, does that mean the protocol versioning is non-functional? Or if not, what kinds of changes would require a new version number?

Section 7:

"Use of the "k=" line poses a significant security risk, since it
   conveys session encryption keys in the clear.  SDP MUST NOT be used
   to convey keying material, unless it can be guaranteed that the
   channel over which the SDP is delivered is both private and
   authenticated.  Moreover, the "k=" line provides no way to indicate
   or negotiate cryptographic key algorithms.  As it provides for only a
   single symmetric key, rather than separate keys for confidentiality
   and integrity, its utility is severely limited.  The "k=" line MUST
   NOT be used, as discussed in Section 5.12."

It's odd to me that this text was retained from RFC 4566 as-is, except for the last sentence. I would have expected this to lead with something like 'Use of the "k=" line is obsolete due to security risk.' And then perhaps some of the rest of the text could remain by way of explanation why it was obsoleted.

Section 8.2.8:

"IANA may refer any registration to the IESG for review, and may
   request revisions to be made before a registration will be made."

This is trivially true and would be better left out, using RFC 8126 as the definitive guidance instead.

Thanks for fixing the minor ABNF issue!

I reviewed the diff from RFC 4566 but didn't make it quite all the way
through the full document itself.  What I did find in that partial read
suggests that a full read-through by the authors may find some lingering
stale language or minor internal inconsistencies.

Another broad topic (with more comments throughout) is that an early and
clear discussion of time representation may be helpful, and arguably
does not need to refer to NTP time at all.  (This is especially so when
we refer to "NTP time format" and RFC 5905, which lists three
formats, none of which have a straightforward translation to numeric
strings without fraction part.)

Section 4

                                   SDP is primarily intended for use in
   an internetwork, although it is sufficiently general that it can
   describe multimedia conferences in other network environments.  [...]

nit(?): this verbiage ("internetwork") feels quite dated.

Section 4.1

                                                    Some media types may
   redefine this behavior, but this is NOT RECOMMENDED since it
   complicates implementations (including middleboxes that must parse
   the addresses to open Network Address Translation (NAT) or firewall
   pinholes).

(Similarly for "firewall pinholes".)

Section 4.3

The usual security considerations about (potentially) referencing remote
content would seem to apply.  Perhaps a RFC 3986 reference (or more)
would be appropriate.

Section 4.6

Perhaps we should mention here that this categorization mechanism is
deprecated/obsolete?

Section 5

   An SDP description is entirely textual.  SDP field names and
   attribute names use only the US-ASCII subset of UTF-8 [RFC3629], but
   textual fields and attribute values MAY use the full ISO 10646
   character set in UTF-8 encoding, or some other character set defined
   by the "a=charset:" attribute.  [...]

nit: here (and in Section 4.4 just above) may be the only times we
include the colon when discussing an "a=" attribute; consistency would
seem to suggest removing the colons.

                                  However, since SDP may be used in
   environments where the maximum permissible size of a session
   description is limited, the encoding is deliberately compact.  Also,
   since descriptions may be transported via very unreliable means or
   damaged by an intermediate caching server, the encoding was designed
   with strict order and formatting rules so that most errors would
   result in malformed session descriptions that could be detected
   easily and discarded.  This also allows rapid discarding of encrypted
   session descriptions for which a receiver does not have the correct
   key.

I don't really see why the "rapid discarding" property follows from the
compactness of the encoding, when the correct key for the encrypted
description is not known.

Section 5.x

It's interesting to note that while the SDP attributes (Sections 6.x)
got ABNF constructions for their values, the type descriptions here
are still presented in a somewhat informal syntax (that, e.g., relies on
implicitly stating that fields are whitespace-separated).

Section 5.2

   <sess-id>  is a numeric string such that the tuple of <username>,
      <sess-id>, <nettype>, <addrtype>, and <unicast-address> forms a
      globally unique identifier for the session.  The method of <sess-
      id> allocation is up to the creating tool, but it has been
      suggested that a Network Time Protocol (NTP) format timestamp be
      used to ensure uniqueness [RFC5905].

(et seq) There is not a single "NTP format timestamp"; RFC 5905 provides
three different formats.  If any of the three is fine, that should be
stated, and if a single distinguished one is preferred, that should also
be stated.
Furthermore, the three formats all include multiple fields and not a
rule for presenting them as a "numeric string" as described here, which
on the face of it seems to exclude fractions.  ("numeric string" does
not seem to be specifically defined by this document.)

Section 5.3

   The "s=" line MUST NOT be empty and SHOULD contain ISO 10646
   characters (but see also the "a=charset" attribute).  [...]

Is this perhaps intended to be "SHOULD only contain"?
(Similarly in following subsections.)

Section 5.9

   The first and second sub-fields of the time-field give the start and
   stop times, respectively, for the session.  These values are the
   decimal representation of Network Time Protocol (NTP) time values in
   seconds since 1900 [RFC5905].  To convert these values to UNIX time
   (UTC), subtract decimal 2208988800.

Looking at the time formats listed in RFC 5905, one perhaps wonders if
the values used by SDP are more appropriately described informally as
just "seconds since the Unix epoch" without specific reference to NTP
(both here and elsewhere in the document).

   NTP timestamps are elsewhere represented by 64-bit values, which wrap
   sometime in the year 2036.  [...]

I don't understand what this is referring to.  Is this perhaps the "32
bits of seconds and 32 bits of fraction" format, which suffers from the
y2038 (note '8', not '6') problem?

Section 6.2

Perhaps "this was to assist" would be more fitting, given the obsolete
nature of a=keywds.

Section 6.9

   This specifies the type of the multimedia conference.  Suggested
   values are "broadcast", "meeting", "moderated", "test", and "H332".

nit: I don't think these are "suggested" values; they are the only ones
allowed by the ABNF.

   "recvonly" should be the default for "type:broadcast" sessions,
   "type:meeting" should imply "sendrecv", and "type:moderated" should
   indicate the use of a floor control tool and that the media tools are
   started so as to mute new sites joining the multimedia conference.

There seems to be redundancy here with the "SHOULD" in Section 6.7 about
"sendrecv" being the default for non-broadcast non-H322 sessions.

Section 6.11

Is it intentional to lose the language about "order of importance" of
multiple languages?

Hi,

I'm not an ABNF expert but it seems to me the errata 1795 (https://www.rfc-editor.org/errata/eid1795) was correct, but the proposed change has not been incorporated in the document.
I've rapidly searched for a discussion on this errata but could not find any. There might be a reason for not applying the change and in that case, sorry to raise that again, but in case this was an oversight then it might be worth capturing this now.