Document: draft-ietf-mmusic-sdp-new-25.txt Reviewer: Spencer Dawkins [spencer@mcsr-labs.org] Review Date: Tuesday 11/29/2005 1:33 PM CST Telechat Date: Thursday 12/01/2005 Summary: This specification is very close to ready for publication as Proposed Standard. Jon asked that we have mercy on this specification, but I found it very readable and clear in most cases. I have some suggested edits (see below) and tried to propose text in most cases. The biggest single nit I noticed was an emphasis on SAP as "commonly"/"frequently" used to distribute SDP - this seemed to "age" the specification. BTW, idnits 1.82 reports "No nits found."Spencer Review: ------- 1. Introduction This memo updates RFC 2327 [6] in the light of implementation experience, and adds a small number of new features. Section 10 outlines the changes introduced in this memo. Spencer - (1) doesn't this specification actually replace 2327? and 3266? (2) I'm not sure what our current practice is, but I don't mind seeing information like this in the Abstract, as well as in the Introduction. 3. Examples of SDP Usage 3.1 Multicast Session Announcement One protocol commonly used to implement such a distributed directory is the Session Announcement Protocol, SAP [14]. SDP provides the recommended session description format for such session announcements. Spencer - I understand the historical context here, but I'm not sure "commonly" is a good description, given the current state of multicast distribution in today's internet. I may simply be reacting with slight suprise that SAP is described before SIP and RTSP - today's implementors and users are much more likely to use SDP in these contexts, I think. 3.4 Email and the World Wide Web Note that announcements of multicast sessions made only via email or the World Wide Web (WWW) do not have the property that the receiver of a session announcement can necessarily receive the session because the multicast sessions may be restricted in scope, and access to the WWW server or reception of email is possible outside this scope. Session announcements made using SAP do not suffer this mismatch. Spencer - sigh. I'd strike the last sentence (see previous comments). 4. Requirements and Recommendations The purpose of SDP is to convey information about media streams in multimedia sessions to allow the recipients of a session description to participate in the session. SDP is primarily intended for use in an internetwork, although it is sufficiently general that it can describe conferences in other network environments. Media streams can be many-to-many. The times during which the session is active need not be continuous. Spencer - the last sentence of this paragraph wasn't clear to me. "Sessions may have start and stop times, so media streams need not be continuous"? 4.1 Media and Transport Information The semantics of this address and port depend on the media and transport protocol defined. By default, this SHOULD be the remote address and remote port to which data is sent. Some media types MAY redefine this behaviour, but this is NOT RECOMMENDED. Spencer - This MAY seems like an emphasis MAY, not a 2119 MAY. Is it possible to add a phrase that says "NOT RECOMMENDED because ...", so that other protocol designers understand your concerns about this behaviour? 4.2 Timing Information This timing information is globally consistent, irrespective of local time zone or daylight saving time. Spencer - later in the specification, you explain that timing information is measured as NTP standard seconds since 1900. It might be nice to include that explanation here. 4.3 Private Sessions It is possible to create both public sessions and private sessions. SDP itself does not distinguish between these: private sessions are typically conveyed by encrypting the session description during distribution. The details of how encryption is performed are dependent on the mechanism used to convey SDP: mechanisms are currently defined for SDP transported using SAP [14] and SIP [15], others may be defined in future. Spencer - are the colons after these and after SDP really semi-colons? (Or have I tripped over British English usage; if so, my apologies!) 4.5 Categorisation When many session descriptions are being distributed by SAP, or any other advertisement mechanism, it may be desirable to filter session announcements that are of interest from those that are not. SDP supports a categorisation mechanism for sessions that is capable of being automated. Spencer - could you add a forward pointer to this mechanism here? I think it's just "(See Section 6)" 5. SDP Specification Text fields such as the session name and information are octet strings which may contain any octet with the exceptions of 0x00 (Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The sequence CRLF (0x0d0a) is used to end a record, although parsers SHOULD be tolerant and also accept records terminated with a single newline character. If the "a=charset" attribute is not present, these octet strings MUST be interpreted as containing ISO-10646 characters in UTF-8 encoding (the presence of the "a=charset" attribute MAY force some fields to be interpreted differently). Spencer - again, this MAY seems emphatic, not 2119. 5.2 Origin ("o=") is the address of the machine from which the session was created. For an address type of IP4, this is either the fully-qualified domain name of the machine, or the dotted- decimal representation of the IP version 4 address of the machine. For an address type of IP6, this is either the fully-qualified domain name of the machine, or the compressed textual representation of the IP version 6 address of the machine. For both IP4 and IP6, the fully-qualified domain name is the form that SHOULD be given unless this is unavailable, in which case the globally unique address MAY be substituted. A local IP address MUST NOT be used in any context where the SDP description might leave the scope in which the address is meaningful. Spencer - sigh. And since applications may use SDP descriptions in referrals across addressing domains, it's not obvious how this MUST NOT actually applies. Could it be a bit more explicit? "be included in an application-level referral that might leave the scope"? For privacy reasons, it is sometimes desirable to obfuscate the username and IP address of the session originator. If this is a concern, an arbitrary and private MAY be chosen to populate the "o=" field, provided these are selected in a manner that does not affect the global uniqueness of the field. Spencer - does this actually get used in the wild? If so, fine, but I'm wondering about sending SDP that one might, or might not, be able to believe... it would be a late specification change, but using something like private@example.com (after RFC 2606) would be more obviously private... (and I note that the SIP working group has just noticed that "anonymous" is an English-language string, and is also trying to figure out how THEY say "anonymous" in an international Internet, so please don't think I'm picking on SDP here :-) 5.9 Timing ("t=") Permanent sessions may be shown to the user as never being active unless there are associated repeat times which state precisely when the session will be active. In general, permanent sessions SHOULD NOT be created for any session expected to have a duration of less than 2 months, and should be discouraged for sessions expected to have a duration of less than 6 months. Spencer - I'm having 2119 problems here - how is "SHOULD NOT" different from "discouraged from"? 5.10 Repeat Times ("r=") To make description more compact, times may also be given in units of days, hours or minutes. The syntax for these is a number immediately followed by a single case-sensitive character. Fractional units are not allowed - a smaller unit should be used instead. The following unit specification characters are allowed: d - days (86400 seconds) h - hours (3600 seconds) m - minutes (60 seconds) s - seconds (allowed for completeness but NOT RECOMMENDED) Spencer - I am guessing that you are saying "NOT RECOMMENDED because the default is in seconds anyway", but I'm having to guess why "NOT RECOMMENDED". 5.12 Encryption Keys ("k=") k=uri: A Universal Resource Identifier is included in the key field. The URI refers to the data containing the key, and may require additional authentication before the key can be returned. When a request is made to the given URI, the reply should specify the encoding for the key. The URI is often a secure HTTP URI, although this is not required. Spencer - Do you really mean "secure HTTP" (ftp://ftp.rfc-editor.org/in-notes/rfc2660.txt), or do you mean SSL/TLS-protected HTTP ("https:")? The key field MUST NOT be used unless it can be guaranteed that the SDP is conveyed over a secure and trusted channel. An example of such a channel might be SDP embedded inside an S/MIME message or a TLS-protected HTTP session. It is important to ensure that the secure channel is with the party that is authorised to join the session, not an intermediary: if a caching proxy server is used, it is important to ensure that the proxy is either trusted or unable to access the SDP. Definition of appropriate security measures is beyond the scope of this specification, and should be defined by the users of SDP. Spencer - the last sentence of this paragraph seems confused between protocol security and operational security policy ... 5.14 Media Descriptions ("m=") 3. If two media sessions have the same transport address, they SHOULD operate under the same RTP profile. The sessions MAY use two different RTP profiles only if those profiles are specifically designed to be compatible. Spencer - is there any registry of what's compatible, or is this something that users just have to figure out? 6. SDP Attributes The following attributes are defined. Since application writers may add new attributes as they are required, this list is not exhaustive. Registration procedures for new attributes are defined in Section 8.2.4. a=cat: This attribute gives the dot-separated hierarchical category of the session. This is to enable a receiver to filter unwanted sessions by category. It is a session-level attribute, and is not dependent on charset. a=keywds: Like the cat attribute, this is to assist identifying wanted sessions at the receiver. This allows a receiver to select interesting session based on keywords describing the purpose of the session. It is a session-level attribute. It is a charset dependent attribute, meaning that its value should be interpreted in the charset specified for the session description if one is specified, or by default in ISO 10646/UTF-8. Spencer - I am guessing that there is no registry of allowed values for cat and keywds(the sender can use any character string, and receivers will figure out what the values are and whether they are interested intuitively), but I am guessing. Whether I guessed right or not, it might be nice to say this explicitly. 7. Security Considerations SDP is frequently used with the Session Initiation Protocol [15] using the offer/answer model [17] to agree parameters for unicast sessions. When used in this manner, the security considerations of those protocols apply. Spencer - s/agree/agree on/ SDP is a session description format that describes multimedia sessions. A session description SHOULD NOT be trusted unless it has been obtained by an authenticated transport protocol from a trusted source. Many different transport protocols may be used to distribute session description, and the nature of the authentication will differ from transport to transport. Spencer - I'm not sure what "trusted" means here - if I got an SDP description using unauthenticated RTSP, I would probably USE it (if the session was interesting), and isn't that the kind of "trust" relationship one has with a session description? Is the point something like "SHOULD NOT be trusted beyond the trust relationship a host has for the transport protocol used to deliver the session description. Many different ..."? The second paragraph down gives good guidance, I'm just trying to be consistent here and two paragraphs down. One transport that will frequently be used to distribute session descriptions is the Session Announcement Protocol (SAP). SAP provides both encryption and authentication mechanisms but due to the nature of session announcements it is likely that there are many occasions where the originator of a session announcement cannot be authenticated because they are previously unknown to the receiver of the announcement and because no common public key infrastructure is available. Spencer - SAP used "frequently" in 2006 (by the time this specification is announced)... Session descriptions may be parsed at intermediate systems such as firewalls for the purposes of opening a hole in the firewall to allow participation in multimedia sessions. This SHOULD NOT be done unless the SDP is conveyed in a manner that allows proper authentication and authorization checks to ensure that firewall holes are only opened in accordance with applicable security policy. SDP by itself does not include sufficient information to enable these checks: they depend on the encapsulating protocol (e.g. SIP or RTSP). Spencer - sigh... The Internet must have been really nice, ten years ago... :-( but anyway - we don't normally give standards-track guidance for firewall operation, do we? I thought BEHAVE had them explicitly out of scope...