Summary: Has 3 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
Section 8.2.8: "In the RFC specifications that register new values for SDP "media", "proto", "fmt", "bwtype", "nettype", and "addrtype" parameters, the authors MUST include the following information for IANA to place in the appropriate registry:" It doesn't look like all the fields that are listed after this text actually appear in the registries. For some of these I don't see why the information would be put into the registries (e.g., contact name, contact email address, since those appear in the RFCs themselves). I think this needs to be clarified.
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.
I’d like to escalate Alissa’s point about the k= language in Section 7 (Security Considerations). It looks like the new Section 5.12 removes all of the historical language beyond saying it MUST NOT be used. This approach makes sense to me. However, the language in Section 7 could be read as conflicting with that. Specifically: 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. ... The "k=" line MUST NOT be used, as discussed in Section 5.12. The first sentence makes a strong statement. The first clause of the second sentence makes a more generic MUST NOT statement but the second clause seems to say that is acceptable under certain circumstances. The third sentence reiterates that k= MUST NOT be used. How should this be reconciled? Is the text suggesting that conveying keying materials outside of k= is acceptable over the right kind of channel?
(1) Per the Security Considerations (Section 7) paragraph on “software parsing the session should take a few precautions”, the discussion about software taking action is helpful. I’d also recommend explicitly adding caution about acting on URIs (e.g., the security considerations of [RFC3986]) to this section. (2) Section 6.7. Typo. s/occurence/occurrence/
I'll raise Martin's comment to DISCUSS level: OLD decimal-uchar = DIGIT / POS-DIGIT DIGIT / ("1" 2*(DIGIT)) / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) NEW decimal-uchar = DIGIT / POS-DIGIT DIGIT / ("1" 2(DIGIT)) / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) END Is there a reason NOT to make this change, or was it just overlooked?
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?
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 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?
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.
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.