SIMPLE WG B. Campbell, Ed. Internet-Draft Expires: January 16, 2005 R. Mahy C. Jennings Cisco Systems, Inc. July 18, 2004 The Message Session Relay Protocol draft-ietf-simple-message-sessions-07.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 16, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes the Message Session Relay Protocol (MSRP), a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when setup via a rendezvous or session setup protocol such as the Session Initiation Protocol (SIP). Campbell, et al. Expires January 16, 2005 [Page 1] Internet-Draft MSRP July 2004 Table of Contents 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction and Background . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 5 4. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1 MSRP Framing and Message Chunking . . . . . . . . . . . . 8 4.2 MSRP Addressing . . . . . . . . . . . . . . . . . . . . . 11 4.3 MSRP Transaction and Report Model . . . . . . . . . . . . 11 4.4 MSRP Connection Model . . . . . . . . . . . . . . . . . . 12 5. MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 15 5.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 16 6. Method-Specific Behavior . . . . . . . . . . . . . . . . . . 16 6.1 Constructing Requests . . . . . . . . . . . . . . . . . . 16 6.1.1 Delivering SEND requests . . . . . . . . . . . . . . . 17 6.1.2 Sending REPORT requests . . . . . . . . . . . . . . . 19 6.1.3 Failure REPORT Generation . . . . . . . . . . . . . . 19 6.2 Constructing Responses . . . . . . . . . . . . . . . . . . 20 6.3 Receiving Requests . . . . . . . . . . . . . . . . . . . . 21 6.3.1 Receiving SEND requests . . . . . . . . . . . . . . . 21 6.3.2 Receiving REPORT requests . . . . . . . . . . . . . . 22 7. Using MSRP with SIP . . . . . . . . . . . . . . . . . . . . 22 7.1 SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . 22 7.1.1 URL Negotiations . . . . . . . . . . . . . . . . . . . 25 7.1.2 Path Attributes with Multiple URLs . . . . . . . . . . 26 7.1.3 Updated SDP Offers . . . . . . . . . . . . . . . . . . 27 7.1.4 Example SDP Exchange . . . . . . . . . . . . . . . . . 27 7.1.5 Connection Negotiation . . . . . . . . . . . . . . . . 28 7.2 MSRP User Experience with SIP . . . . . . . . . . . . . . 28 8. DSN payloads in MSRP REPORT Requests . . . . . . . . . . . . 28 8.1 Per-Message DSN header usage . . . . . . . . . . . . . . . 28 8.2 Per-Recipient DSN header usage . . . . . . . . . . . . . . 29 8.3 original-envelope-id usage . . . . . . . . . . . . . . . . 29 8.4 reporting-mta . . . . . . . . . . . . . . . . . . . . . . 29 8.5 final-recipient . . . . . . . . . . . . . . . . . . . . . 29 8.6 action . . . . . . . . . . . . . . . . . . . . . . . . . . 30 8.7 status . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 30 10. Response Code Descriptions . . . . . . . . . . . . . . . . . 32 10.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.3 403 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.4 415 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.5 426 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.6 481 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.7 506 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Campbell, et al. Expires January 16, 2005 [Page 2] Internet-Draft MSRP July 2004 11.1 Basic IM session . . . . . . . . . . . . . . . . . . . . 33 11.2 Chunked Message . . . . . . . . . . . . . . . . . . . . 36 11.3 System Message . . . . . . . . . . . . . . . . . . . . . 36 11.4 Positive Report . . . . . . . . . . . . . . . . . . . . 37 11.5 Forked IM . . . . . . . . . . . . . . . . . . . . . . . 37 12. Extensibility . . . . . . . . . . . . . . . . . . . . . . . 40 13. CPIM compatibility . . . . . . . . . . . . . . . . . . . . . 40 14. Security Considerations . . . . . . . . . . . . . . . . . . 40 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 42 15.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . 42 15.2 MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . 42 15.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . 43 15.3.1 Accept Types . . . . . . . . . . . . . . . . . . . . 43 15.3.2 Wrapped Types . . . . . . . . . . . . . . . . . . . 43 15.3.3 Path . . . . . . . . . . . . . . . . . . . . . . . . 43 15.4 IANA registration forms for DSN types . . . . . . . . . 43 15.4.1 IANA registration form for address-type . . . . . . 43 15.4.2 IANA registration form for MTA-name-type . . . . . . 44 16. Change History . . . . . . . . . . . . . . . . . . . . . . . 44 16.1 draft-ietf-simple-message-sessions-07 . . . . . . . . . 44 16.2 draft-ietf-simple-message-sessions-06 . . . . . . . . . 44 16.3 draft-ietf-simple-message-sessions-05 . . . . . . . . . 45 16.4 draft-ietf-simple-message-sessions-04 . . . . . . . . . 45 16.5 draft-ietf-simple-message-sessions-03 . . . . . . . . . 45 16.6 draft-ietf-simple-message-sessions-02 . . . . . . . . . 46 16.7 draft-ietf-simple-message-sessions-01 . . . . . . . . . 46 16.8 draft-ietf-simple-message-sessions-00 . . . . . . . . . 47 16.9 draft-campbell-simple-im-sessions-01 . . . . . . . . . . 47 17. Contributors and Acknowledgments . . . . . . . . . . . . . . 47 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 18.1 Normative References . . . . . . . . . . . . . . . . . . . 48 18.2 Informational References . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 50 Intellectual Property and Copyright Statements . . . . . . . 52 Campbell, et al. Expires January 16, 2005 [Page 3] Internet-Draft MSRP July 2004 1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [5]. This document consistently refers to a "message" as a complete unit of MIME or text content. In some cases a message is split and delivered in more than one MSRP request. Each of these portions of the complete message is called a "chunk". 2. Introduction and Background A series of related textual messages between two or more parties can be viewed as part of a session with a definite start and end. This is in contrast to individual messages each sent completely independently. The SIMPLE Working Group describes messaging schemes that only track individual messages as "page-mode" messages, whereas messaging that is part of a "session" with a definite start and end is called session-mode messaging. Page-mode messaging is enabled in SIMPLE via the SIP [4]MESSAGE method [19]. Session-mode messaging has a number of benefits [20] over page-mode messaging however, such as explicit rendezvous, tighter integration with other media types, direct client-to-client operation, and brokered privacy and security. This document defines a session-oriented instant message transport protocol (MSRP), whose sessions can be included in an offer or answer [3] of a session description (for example, SDP [2]). The exchange is carried by some signaling protocol, such as SIP [4]. This allows a communication user agent to offer a messaging session as one of the possible media types in a session. For instance, Alice may want to communicate with Bob. Alice doesn't know at the moment whether Bob has his phone or his IM client handy, but she's willing to use either. She sends an invitation to a session to the address of record she has for Bob, sip:bob@example.com. Her invitation offers both voice and an IM session. The SIP services at example.com forward the invitation to Bob at his currently registered clients. Bob accepts the invitation at his IM client and they begin a threaded chat conversation. This session model allows message sessions to be integrated into advanced communications applications with little to no additional protocol development. For example, during the above chat session, Bob decides Alice really needs to be talking to Carol. Bob can transfer [18] Alice to Carol, introducing them into their own messaging session. Messaging sessions can then be easily integrated Campbell, et al. Expires January 16, 2005 [Page 4] Internet-Draft MSRP July 2004 into call-center and dispatch environments utilizing third-party call control [17] and conferencing [16] applications. 3. Protocol Overview MSRP is a text-based, connection-oriented protocol for exchanging arbitrary (binary) MIME content, especially instant messages. This section is a non-normative overview of how MSRP works and how it is used with SIP. MSRP sessions are typically arranged using SIP the same way a session of audio or video media is setup. One SIP user agent (Alice) sends the other (Bob) a SIP invitation containing an offer session-description which includes a session of MSRP. The receiving SIP user agent can accept the invitation and include an answer session-description which acknowledges the choice of media. Alice's session description contains an MSRP URL that describes where she is willing to receive MSRP requests from Bob, and vice-versa. (Note: Some lines in the examples are removed for clarity and brevity.) Campbell, et al. Expires January 16, 2005 [Page 5] Internet-Draft MSRP July 2004 Alice sends to Bob: INVITE sip:alice@atlanta.example.com SIP/2.0 To: From: ;tag=786 Call-ID: 3413an89KU Content-Type: application/sdp c=IN IP4 10.1.1.1 m=message 9 msrp * a=accept-types:text/plain a=path:msrp://atlanta.example.com:7654/jshA7we;tcp Bob sends to Alice: SIP/2.0 200 OK To: ;tag=087js From: ;tag=786 Call-ID: 3413an89KU Content-Type: application/sdp c=IN IP4 10.2.2.2 m=message 9 msrp * a=accept-types:text/plain a=path:msrp://biloxi.example.com:12763/kjhd37s2s2;tcp Alice sends to Bob: ACK sip:alice@atlanta.example.com SIP/2.0 To: ;tag=087js From: ;tag=786 Call-ID: 3413an89KU MSRP defines two request types, or methods. SEND requests are used to deliver a complete message or a chunk (a portion of a complete message), while REPORT requests report on the status of an earlier SEND request. When Alice receives Bob's answer, she checks to see if she has an existing connection to Bob. If not, she opens a new connection to Bob using the URL he provided in the SDP. Alice then delivers a SEND request to Bob with her initial message, and Bob replies indicating that Alice's request was received successfully. Campbell, et al. Expires January 16, 2005 [Page 6] Internet-Draft MSRP July 2004 MSRP a786hjs2 SEND To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp Message-ID: 87652 Content-Type: text/plain Hey Bob, are you there? -------a786hjs2$ MSRP a786hjs2 200 OK To-Path: msrp://atlanta.example.com:7654/jshA7we;tcp From-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp Message-ID: 87652 -------a786hjs2$ Alice's request begins with the MSRP start line, which contains a transaction identifier that is also used as a final boundary marker. Next she includes the path of URLs to the destination in the To-Path header, and her own URL in the From-Path header. In this typical case there is just one "hop", so there is only one URL in each path header field. She also includes a message ID which she can use to correlate responses and status reports with the original message. Next she puts the actual content. Finally she closes the request with an end line: seven hyphens, the transaction identifier / boundary marker and a "$" to indicate this request contains the end of a complete message. If Alice wants to deliver a very large message, she can split the message into chunks and deliver each chunk in a separate SEND request. The message ID corresponds to the whole message, so the receiver can also use it to reassemble the message and tell which chunks belong with which message. Chunking is described in more detail in Section 4.1. Alice can also specify what type of reporting she would like in response to her request. If Alice requests positive acknowledgements, Bob sends a REPORT request to Alice confirming the delivery of her complete message. This is especially useful if Alice sent a series of SEND request containing chunks of a single message. More on requesting types of reports and errors is described in Section 4.3. Alice and Bob generally choose their MSRP URLs in such a way that is difficult to guess the exact URL. Alice and Bob can reject requests to URLs they are not expecting to service, and can correlate the specific URL with the probable sender. Alice and Bob can also use TLS [1] to provide channel security over this hop. To receive MSRP Campbell, et al. Expires January 16, 2005 [Page 7] Internet-Draft MSRP July 2004 requests over a TLS protected connection, Alice or Bob could advertise URLs with the "msrps" scheme instead of "msrp." This document specifies MSRP behavior only peer-to-peer session, that is, for a single hop. But is designed with the expectation that MSRP can carry URLs for nodes on the far side of gateways or relays. For this reason, a URL with the "msrps" scheme makes no assertion about the security properties of other hops, just the next hop. MSRP URLs are discussed in more detail in Section 5. An adjacent pair of busy MSRP nodes (for example two gateways) can easily have several sessions, and exchange traffic for several simultaneous users. The nodes can use existing connections to carry new traffic with the same destination host, port, transport protocol, and scheme. MSRP nodes can keep track of how many sessions are using a particular connection and close these connections when no sessions have used them for some period of time. Connection management is discussed in more detail in Section 4.4. 4. Key Concepts 4.1 MSRP Framing and Message Chunking Messages sent using MSRP can be very large and can be delivered in several SEND requests, where each SEND request contains one chunk of the overall message. To support this, MSRP uses a boundary based framing mechanism. The header of an MSRP request contains a unique boundary string that is used to indicate the end of the request. Following the boundary string at the end of the body data, there is a flag that indicates whether this is the last chunk of data for this message or whether the message will be continued in a subsequent chunk. There is also a Byte-Range header in the request that indicates the overall position of this chunk inside the complete message. For example, the following snippet of two SEND requests demonstrates a message that contains the text "abcdEFGH" being sent as two chunks. Campbell, et al. Expires January 16, 2005 [Page 8] Internet-Draft MSRP July 2004 MSRP dkei38sd SEND Message-ID: 456 Byte-Range: 1-4/8 Content-Type: "text/plain" abcd -------dkei38sd+ MSRP dkei38ia SEND Message-ID: 456 Byte-Range: 5-8/8 Content-Type: "text/plain" EFGH -------dkei38ia$ The receiver uses the value of the Message-ID header to determine which of multiple chunks belong to the same message. The Message-ID header MUST have the same value for each chunk in the same message, and a sender MUST ensure that the message ID is unique for each of the messages it sends within a particular session. The boundary marker that terminates the body MUST be preceded by a CRLF that is not part of the body and then seven "-" (minus sign) characters. After the boundary marker, there MUST be a flag character that is either a "$" (for the last chunk of the message) or "+" (for chunks other than the last). If the chunk represents the data that forms the end of the message, the flag MUST be a "$", otherwise the flag MUST be a "+". The Byte-Range header value contains a starting value followed by a "-", an ending value followed by a "/", and finally the total length. The starting value indicates the index into the message where the first byte in the current chunk belongs. The index of the first octet in the complete message is ONE, not zero. The ending value indicates the location where the last octet belongs. The body MAY contain less data than is indicated by the end but it MUST NOT contain more octets than indicated. The length indicates the number of octets in the complete message. Both the ending value and length MAY have the value of "*" in some or all of the chunks, to indicate that they are not specified. If no Byte-Range header is present, the SEND request MUST be treated as if there was a Byte-Range header present with a value of "1-*/*". This chunking mechanism allows a sender to interrupt a chunk part way through sending it by writing out the boundary termination and the "+" flag to indicate that the end of this chunk is not the end of the complete message. The ability to interrupt messages allows multiple Campbell, et al. Expires January 16, 2005 [Page 9] Internet-Draft MSRP July 2004 sessions to share a TCP connection, and for large messages to be sent efficiently while not blocking other messages that share the same connection. To insure fairness over a connection, senders MUST NOT send chunks with a body larger than 2048 octets unless they are prepared to interrupt them. A sender can use one of the following two strategies to satisfy this requirement. The sender is STRONGLY RECOMMENDED to send messages larger than 2048 octets using as few chunks as possible, interrupting chunks (at least 2048 octets long) when other traffic is waiting to use the same connection. Alternatively, the sender MAY simply send chunks in 2048 octet increments until the final chunk. Note that the former strategy results in markedly more efficient use of the connection. All MSRP nodes MUST be able to receive chunks of any size from 0 octets to the maximum number of octets they can receive for a complete message. Senders SHOULD NOT break messages into chunks smaller than 2048 octets, except for the final chunk of a complete message. Receivers MUST not assume the chunks will be delivered in order or that they will receive all the chunks with "+" flags before they receive the chunk with the "$" flag. In certain cases of connection failure, it is possible for information to be duplicated. If chunks data is received that overlaps already received data for the same message, the last chunk received takes precedence (even though this may not have been the last chunk transmitted). For example, if bytes 1 to 100 was received and a chunk arrives that contains bytes 50 to 150, this second chunk will overwrite bytes 50 to 100 of the data that had already been received. Although other schemes work, this is the easiest for the receiver and results in consistent behavior between clients. The seven "-" before the boundary are used so that the receiver can search for the value "----", 32 bits at a time to find the probable location of the boundary. This allows most processors to locate the boundaries and copy the memory at the same rate that a normal memory copy could be done. This approach results in a system that is as fast as framing based on specifying the body length in the headers of the request, but also allows for the interruption of messages. The ability to interrupt messages is needed so that TCP connections can be shared. Connection sharing is necessary for "fair" allocation of bandwidth in congestion situations and for allowing MSRP network elements that have a very large number of concurrent connections to different users. Campbell, et al. Expires January 16, 2005 [Page 10] Internet-Draft MSRP July 2004 4.2 MSRP Addressing MSRP entities are addressed using URLs. The MSRP URL schemes are defined in Section 5. The syntax of the To-Path and From-Path headers allow for a list of URLs. This was done to allow the protocol to work with gateways or relays defined in the future, to provide a complete path to the end recipient. When two MSRP nodes communicate directly they need only one URL in the To-Path list and one URL in the From-Path list. 4.3 MSRP Transaction and Report Model A sender sends MSRP requests to a receiver. The receiver MUST quickly accept or reject the request. If the receiver initially accepted the request, it still may then do things that take significant time to succeed or fail. For example, if the receiver is an MSRP to XMPP [29] gateway, it may forward the message over XMPP. The XMPP side may later indicate that the request did not work. At this point, the MSRP receiver may need to indicate that the request did not succeed. There are two important concepts here: first, the hop by hop delivery of the request may succeed or fail; second, the end result of the request may be successfully processed or not. The first type of status is referred to as "transaction status" and may be returned in response to a request. The second type of status is referred to as "request status" and may be returned in a REPORT transaction. The original sender of a request can indicate if they wish to receive reports for requests that fail, and can independently indicate if they wish to receive reports for requests that succeed. A receiver only sends a success REPORT if it knows that the request succeeded, and the sender requested a success report. A receiver only sends a failure REPORT if the request failed and the sender requested failure reports. This document describes the behavior of MSRP endpoints. MSRP relays or gateways are likely to have additional conditions that indicate a failure REPORT should be sent, such as the failure to receive a positive response from the next hop. Two header fields control the sender's desire to receive reports. The header "Report-Success" can have a value of "yes" or "no" and the "Report-Failure" header can have a value of "yes", "no", or "partial". If the value of "Report-Failure" is set to "yes", then the sender of the request runs a timer. If a 200 response to the transaction is not received within 30 seconds from the time the last byte of the Campbell, et al. Expires January 16, 2005 [Page 11] Internet-Draft MSRP July 2004 transaction is sent, the element MUST inform the user that the request probably failed. If the value is set to "partial", then the element sending the transaction does not have to run a timer, but MUST inform the user if receives a non-recoverable error response to the transaction. Similarly if the value of the Report-Success header is "yes", then the receiving node MUST send a "success" REPORT after the request is complete to indicate that the request succeeded. Likewise if the value is "no", it MUST NOT send a success REPORT. A consequence of this is that if an MSRP element receives a request that has the Report-Failure header set to a value of "no", it SHOULD NOT send any responses to this request, because the element sending the request would not do anything with the resulting response. If the value is "partial", it SHOULD NOT send a 200 response to the request, but SHOULD send a non-200 class response if appropriate. If no Report-Success header is present in a SEND request, it MUST be treated the same as a Report-Success header with value of "no". If no Report-Failure header is present, it MUST be treated the same as a Report-Failure header with value of "yes". REPORT requests MUST have the same Message-ID header value as the request they are reporting on. They MAY also have the Byte-Range of the chunk they are reporting on. If an MSRP element receives a REPORT for a Message-ID it does not recognize, it SHOULD silently ignore the REPORT. Report-Success and Report-Failure MUST NOT be present in a REPORT request. MSRP nodes MUST NOT send REPORT requests in response to report requests. MSRP Nodes MUST NOT send MSRP responses to REPORT requests. The combinations of reporting may seem overly complex but they are needed to meet the various scenarios of currently deployed IM systems. Report-Success might be "no" in many public systems to reduce load but is used in some current enterprise systems, such as systems used for securities trading. A Report-Failure value of "no" is useful for sending system messages such as "the system is going down in 5 minutes" without causing a response explosion to the sender. A Report-Failure of "yes" is used by many systems that wish to notify the user if the message failed but some other systems choose to use a value of "partial" to reduce the load on the servers caused by 200 OK responses, but still allow error responses to be sent in many cases. 4.4 MSRP Connection Model When MSRP wishes to send a request to a peer identified by an MSRP Campbell, et al. Expires January 16, 2005 [Page 12] Internet-Draft MSRP July 2004 URL, it first needs a connection, with the appropriate security properties, to the host specified in the URL. If the sender already has such a connection, that is, one associated with the same host, port, and URL scheme, then it SHOULD reuse that connection. When a new MSRP session is created, the convention is that the element that sent the SDP offer MUST immediately issue a SEND request to the answerer. This request MAY have a empty body, or MAY carry content. When a new connection needs to be formed, the element looks at the URL to decide on the type of connection (TLS, TCP, etc.) then connects to the host indicated by the URL, following the URL resolution rules in Section 5.2. For connections using the msrps: scheme, the SubjectAltName in the received certificate MUST match the hostname port of the URL and the certificate MUST be valid, including having a date that is valid and being signed by an acceptable certificate authority. At this point the device that initiated the connection can assume that this connection is with the correct host. If the connection used mutual TLS authentication, and the TLS client presented a valid certificate, then the element accepting the connection can know the identity of the connecting host. When mutual TLS authentication is not used, the listening device MUST wait until it receives a request on the connection to determine the identity of the connecting device. When the first request arrives, it's To-Path header field should contain a URL that the listening element handed out in the SDP for a session. The element that accepted the connection looks up the URL in the received request, and determines which session it matches. If a match exists, the node MUST assume that the host that formed the connection is the host that this URL was given to. If no match exists, the node MUST reject the request with a 481 response. The node MUST also check to make sure the session is not already in use on another connection. If so, it MUST reject the request with a 506 response. If it were legal to have multiple connections associated with the same session, a security problem would exist. If the initial SEND request is not protected, an eavesdropper might learn the URL, and use it to insert messages into the session via a different connection. If a connection fails for any reason, then an MSRP endpoint MUST consider failed any sessions associated with the connection as well. When an endpoint notices such a failure, it SHOULD attempt to re-create any such sessions using a new SDP exchange. If a Campbell, et al. Expires January 16, 2005 [Page 13] Internet-Draft MSRP July 2004 replacement session is successfully created, endpoints MAY attempt to resend any content for which delivery on the original session could not be confirmed. If it does this, the Message-ID values for the resent messages MUST match those used in the initial attempts. If the receiving endpoint receives more than one message with the same Message-ID. It SHOULD assume that the messages are duplicates. It MAY take any action based on that knowledge, but SHOULD NOT present the duplicate messages to the user without warning of the duplicates. In this situation, the endpoint MUST choose Message-ID values so that they are unique in the context of both the original session and the replacement session. When endpoints create a new session in this fashion, the chunks for a given logical message MAY be split across the sessions. However, endpoints SHOULD NOT split chunks between sessions under normal circumstances. If a connection fails, the sender SHOULD attempt to re-setup the URL path using a new offer, for example, in a SIP re-invite or update [13]. It MUST not assume that the new URLs in the SDP will be the same as the old ones. A connection SHOULD not be closed while there are sessions that are using this connection. 5. MSRP URLs An MSRP URL follows a subset of the URL syntax in Appendix A of RFC2396 [11], with a scheme of "msrp" or "msrps": MSRP_urls = msrp-scheme "://" [userinfo "@"] hostport ["/" resource] ";" transport msrp-scheme = "msrp" / "msrps" resource = 1*unreserved transport = "tcp" / token The constructions for "userinfo", "hostport", and "unreserved" are detailed in RFC2396 [11]. URLs designating MSRP over TCP MUST include the "tcp" parameter. If some other transport is used, the "tcp" parameter MUST NOT be present. Since this document only specifies MSRP over TCP, all MSRP URLs herein use the "tcp" parameter. Documents that provide bindings on other transports should define respective parameters for those transports. A MSRP URL with multiple, contradictory transports is invalid, unless some other document specifies meaning for the particular combination of transport parameters. An MSRP URL server part identifies a participant in an MSRP session. Campbell, et al. Expires January 16, 2005 [Page 14] Internet-Draft MSRP July 2004 If the server part contains a numeric IP address, it MUST also contain a port. The resource part identifies a particular session the participant. The absence of the resource part indicates a reference to an MSRP host device, but does not specifically refer to a particular session resource. A scheme of "msrps" indicates the underlying connection MUST be protected with TLS. MSRP has an IANA registered recommended port defined in Section 15.1. This value is not a default, as the URL negotiation process described herein will always include explicit port numbers. However, the URLs SHOULD be configured so that the recommended port is used whenever appropriate. This makes life easier for network administrators who need to manage firewall policy for MSRP. The server part will typically not contain a userinfo component, but MAY do so to indicate a user account for which the session is valid. Note that this is not the same thing as identifying the session itself. If a userinfo component exists, it MUST be constructed only from "unreserved" characters, to avoid a need for escape processing. Escaping MUST NOT be used in an MSRP URL. Furthermore, a userinfo part MUST NOT contain password information. The following is an example of a typical MSRP URL: msrp://host.example.com:8493/asfd34;tcp 5.1 MSRP URL Comparison MSRP URL comparisons MUST be performed according to the following rules: 1. The scheme must match exactly. 2. The host part is compared as case insensitive. 3. If the port exists explicitly in either URL, then it must match exactly. An URL with an explicit port is never equivalent to another with no port specified. 4. The resource part is compared as case sensitive. A URL without a resource part is never equivalent to one that includes a resource part. 5. URLs with different "transport" parameters never match. Two URLs that are identical except for transport are not equivalent. Campbell, et al. Expires January 16, 2005 [Page 15] Internet-Draft MSRP July 2004 6. Userinfo parts are not considered for URL comparison. Path normalization is not relevant for MSRP URLs. Escape normalization is not required, since the relevant parts are limited to unreserved characters. 5.2 Resolving MSRP Host Device An MSRP host device is identified by the server part of an MSRP URL. If the server part contains a numeric IP address and port, they MUST be used as listed. If the server part contains a host name and a port, the connecting device MUST determine a host address by doing an A or AAAA DNS query, and use the port as listed. If a connection attempt fails, the device SHOULD attempt to connect to the addresses returned in any additional A or AAAA records, in the order the records were presented. This process assumes that the connection port is always known prior to resolution. This is always true for the MSRP URL uses described in this document, that is, URLs always created and consumed by automata, rather than by humans. The introduction of relays may create situations where this is not the case. For example, the MSRP URL that a user enters into a client to configure it to use a relay may be intended to be easily remembered and communicated by humans, and therefore is likely to omit the port. Therefore, the relay specification [21] may describe additional steps to resolve the port number. MSRP devices MAY use other methods for discovering other such devices, when appropriate. For example, MSRP endpoints may use other mechanisms to discover relays, which are beyond the scope of this document. 6. Method-Specific Behavior 6.1 Constructing Requests To form a new request, the sender creates a unique transaction identifier and uses this and the method name to create an MSRP request start line. Next, the sender places the target path in a To-Path header, and the sender's URL in a From-Path header. If multiple URLs are present in the To-Path, the leftmost is the first URL visited; the rightmost URL is the last URL visited. The processing then becomes method specific. Additional method-specific Campbell, et al. Expires January 16, 2005 [Page 16] Internet-Draft MSRP July 2004 headers are added as described in the following sections. After any method-specific headers are added, processing continues to handle a body, if present. A body in a Non-SEND request MUST NOT be longer than 2048 octets. If the request has a body, it must contain a Content-Type header field. It may contain other MIME specific headers. The Content-Type header MUST be the last header line. The body MUST be separated from the headers with an extra CRLF. If the request contains a body, the sender MUST check the body to insure that the closing sequence (a CRLF, seven hyphens, and the transaction identifier) is not present in the body. If the closing sequence is present in the body, the sender MUST choose a new transaction identifier that is not present in the body, and add the closing sequence, including the "$" or "+" character, and a final CRLF. Finally, requests which have no body MUST NOT contain a Content-Type header or any other MIME specific header. Bodiless requests MUST contain a closing sequence after the final header. Once a request is ready for delivery, the sender follows the connection management (Section 4.4) rules to forward the request over an existing open connection or create a new connection. 6.1.1 Delivering SEND requests When an endpoint has a message to deliver, it first generates a new unique Message-ID. This ID MUST be unique within the scope of the session. If the message is larger than 2048 octets in length, it either generates an interruptible chunk (which is RECOMMENDED), or it MAY break the complete message into chunks of 2048 octets. It then generates a SEND request for each chunk, following the procedures for constructing requests (Section 6.1). Each chunk MUST contain a Message-ID header field containing the Message-ID. If the sender wishes non-default status reporting, it MUST insert a Report-Failure and/or Report-Success header field with an appropriate value. All chunks of the same message MUST use the same Report-Failure and Report-Success values in their SEND requests. If success reports are requested, the sending device MAY wish to run a timer of some value that makes sense for it's application and take action if a success Report is not received in this time. There is no universal value for this timer. For many IM applications, it may be 2 minutes while for some trading systems it may be under a second. Regardless of whether such a timer is used, if the success report has not been received by the time the session is ended, the device SHOULD Campbell, et al. Expires January 16, 2005 [Page 17] Internet-Draft MSRP July 2004 inform the user. The first chunk of the message SHOULD, and all subsequent chunks MUST include a Byte-Range header field. The range-start field MUST indicate the position of the first byte in the body in the overall message. The range-end field SHOULD indicate the position of the last byte in the body, if known. It MUST take the value of "*" if the position is unknown, or if the request needs to be interruptible. The total field SHOULD contain the total size of the message, if known. The total filed MAY contain a "*" if the total size of the message is not known in advance. All chunks other than the last MUST include a "+" character in the continuation field of the closing line. The final chunk MUST use a "$" character. The sender MUST send all chunks in Byte-Range order. (However,the receiver cannot assume the requests will be delivered in order, as an intervening relay may have changed the order.) If the sender chooses to send a body larger than 2048 octets in a single chunk, the request MUST be constructed so that it can be interrupted. A SEND request is interruptible if it either has no Byte-Range header field, or has such a field with a "*" in the last-byte sub-field. A SEND request is interrupted while a body is in the process of being written to the connection by simply noting how much of the message has already been written to the connection, then writing out the boundary string to end the chunk. It can then be resumed in a another chunk with the same Message-ID and a Byte-Range header range start field containing the position of the first byte after the interruption occurred. SEND requests larger than 2k MUST be interrupted to send pending response or REPORT requests. If multiple SEND requests from different sessions are concurrently being sent over the same connections, the device SHOULD implement some scheme to alternate between them such that each concurrent request gets a chance to send some fair portion of data at regular intervals suitable to the application. The sender MUST NOT assume that a message is received by the peer with the same chunk allocation it was sent with. An intervening relay could possibly break SEND requests into smaller chunks, or aggregate multiple chunks into larger ones. The default disposition of body is "render". If the sender wants different disposition, it MAY insert a Content-Disposition header. Since MSRP is a binary protocol, transfer encoding MUST be "binary". Campbell, et al. Expires January 16, 2005 [Page 18] Internet-Draft MSRP July 2004 6.1.2 Sending REPORT requests REPORT requests are similar to SEND requests, except that report requests MUST NOT include Report-Success or Report-Failure header fields, and MUST contain a Status header field. REPORT requests MUST contain the Message-ID header from the original SEND request. An MSRP endpoint MUST be able to generate success REPORT requests. REPORT requests MAY include a body. If a body is included, it SHOULD be of the DSN MIME type detailed in RFC1894 [8], but MAY be of some other type if the sender of the SEND request indicated support in the "receipt-type" parameter of the respective Report-Success or Report-Failure header field. This parameter contains the alternative MIME type that SHOULD be used for this particular report. A client specifying an alternative 'receipt-type' for an MSRP transaction MUST also be capable of receiving the default format specified in this RFC1894. Use of the DSN MIME format in MSRP is described in Section 8 An endpoint MUST send a success report if it successfully receives a SEND request which contained a Report-Success value of "yes", and either contains a complete message, or contains the last chunk needed to complete the message. This request is sent following the normal procedures (Section 6.1), with a few additional requirements. The endpoint inserts a To-Path header field containing the From-Path value from the original request, and a From-Path header containing the URL identifying itself in the session. The endpoint then inserts a Status header field with a namespace of "000", a short-status of "200" and a relevant Reason phrase, and a Message-ID header field containing the value from the original request. Positive status reports SHOULD NOT include a payload. The endpoint MUST NOT send a success report for a SEND request that either contained no Report-Success header field, or contained such a field with a value of "no". 6.1.3 Failure REPORT Generation If an MSRP endpoint receives a SEND request that it cannot process for some reason, and the Report-Failure header either was not present in the original request, or had a value of "yes", it SHOULD simply send a transaction response with an appropriate error response code. However, there may be situations where the error cannot be determined quickly, such as when the endpoint is a gateway that must wait for a downstream network to indicate an error. In this situation, it MAY Campbell, et al. Expires January 16, 2005 [Page 19] Internet-Draft MSRP July 2004 send a 200 OK response to the request, and then send a failure REPORT request when the error is detected. If the endpoint receives a SEND request with a Report-Failure header field value of "none", then it MUST NOT send a failure REPORT request, and SHOULD NOT send an MSRP response. Construction of failure REPORT requests is identical to that for success reports, except the Status header code and reason fields SHOULD contain appropriate error codes. Any error response code defined in this specification MAY also be used in failure reports. Failure REPORT requests MAY contain a payload, using the DSN MIME type. They MAY contain some other type if allowed by a receipt-type in the Report-Failure header field. If a failure report is sent in response to a SEND request that contained a chunk, it MUST include a Byte-Range header indicating the actual range being reported on. It can take the range-start and total values from the original SEND request, but MUST calculate the range-end field from the actual body data. Endpoints SHOULD NOT send REPORT requests if they have reason to believe the request will not be delivered. For example, they SHOULD NOT send a REPORT request on a session that is no longer valid. This section only describes failure report generation behavior for MSRP endpoints. Relay behavior is beyond the scope of this document, and will be considered in a separate document. We expect failure reports to be more commonly generated by relays than by endpoints. 6.2 Constructing Responses If an MSRP endpoint receives a request that either contains a Report-Failure header value of "yes", or does not contain a Report-Failure header field at all, it MUST immediately generate a response. Likewise, if an MSRP endpoint receives a request that contains a Report-Failure header value of "partial", and the receiver is unable to process the request, it SHOULD immediately generate a response. To construct the response, the endpoint first creates the response start-line, inserting appropriate response code and reason fields. The transaction identifier in the response start line MUST match the transaction identifier from the original request. The endpoint then inserts an appropriate To-Path header field. If the request triggering the response was a SEND request, the To-Path Campbell, et al. Expires January 16, 2005 [Page 20] Internet-Draft MSRP July 2004 header field is formed by copying the last (right-most) URI in the From-Path header field of the request. (Unlike other methods, responses to SEND requests are returned only to the previous hop.) For responses to all other requests, the To-Path header field contains the full path back to the original sender. This full path is generated by taking the list of URLs from the From-Path of the original request, reversing the list, and writing the reversed list into the To-Path of the response. (Legal REPORT requests do not request responses, so this specification doesn't exercise the behavior described above, however we expect that extensions for gateways and relays will need such behavior.) Finally, the endpoint inserts a From-Path header field containing the URL that identifies it in the context of the session, followed by the closing sequence after the last header field. The response MUST be transmitted back on the same connection on which the original request arrived. 6.3 Receiving Requests The receiving endpoint must first check the URL in the To-Path to make sure the request belongs to an existing session. When the request is received, the To-Path will have exactly one URL, which MUST map to an existing session that is associated with the connection on which the request arrived. If this is not true, and the request contained a Report-Failure header value of "no", then the receiver SHOULD quietly ignore the request. If the Report-Failure header is not present, or had any other value, then the receiver MUST return a 481 response. Further request processing by the receiver is method specific. 6.3.1 Receiving SEND requests When the receiving endpoint receives a SEND request, it first determines if it contains a complete message, or a chunk from a larger message. If the request contains no Byte-Range header, or contains one with a range-start value of "1", and the closing line continuation flag has a value of "$", then the request contained the entire message. Otherwise, the receiver looks at the Message-ID value to associate chunks together into the original message. It forms a virtual buffer to receive the message, keeping track of which bytes have been received and which are missing. The receiver takes the data from the request and places it in the appropriate place in the buffer. The receiver MUST determine the actual length of each chunk by inspecting the payload itself; it is possible the body is shorter than the range-end field indicates. This can occur if the sender interrupted a SEND request unexpectedly. It is worth nothing Campbell, et al. Expires January 16, 2005 [Page 21] Internet-Draft MSRP July 2004 that the chunk that has a termination character of "$" defines the total length of the message. What is done with the body is outside the scope of MSRP and largely determined by the MIME type. The body MAY be rendered after the whole message is received or partially rendered as it is being received. If the SEND request contained a Content-Type header field indicating an unsupported MIME type, the receiver SHOULD send a 415 response, if allowed by the Report-Failure header field. All MSRP endpoints MUST be able to receive the multipart/mixed and multipart/alternative MIME types. If the SEND request contained a Report-Success header field with a value of "yes", and the request is either contains the entire message or the last chunk needed to complete a message, the receiver MUST send a success REPORT request back to the sender. 6.3.2 Receiving REPORT requests When an endpoint receives a REPORT request, it may correlate it to the original SEND request using the Message-ID and the Byte-Range, if present. If it requested success reports, then it SHOULD keep enough state about each outstanding sent message so that it can correlate REPORT requests to the original messages. An endpoint that receives a REPORT request containing a Status header with a namespace field of "000", it SHOULD interpret the report in exactly the same way it would interpret an MSRP transaction response with a response code matching the short-code field. It is possible to receive a failure report or a failure transaction response for a chunk that is currently being delivered. In this case the entire message corresponding to that chunk should be aborted. It is possible that an endpoint will receive a REPORT request on a session that is no longer valid. The endpoint's behavior if this happens is a matter of local policy. The endpoint is not required to take any steps to facilitate such late delivery, i.e. it is not expected to keep a connection active in case late REPORTs might arrive. 7. Using MSRP with SIP 7.1 SDP Offer-Answer Exchanges for MSRP Sessions MSRP sessions will typically be initiated using the Session Campbell, et al. Expires January 16, 2005 [Page 22] Internet-Draft MSRP July 2004 Description Protocol (SDP) [2] via the SIP offer-answer mechanism [3]. This document defines a handful of new SDP parameters to setup MSRP sessions. These are detailed below and in the IANA Considerations section. The general format of an SDP media-line is: m= An offered or accepted MSRP media-line MUST have the following value exactly, with the exception that the port field MAY be set to zero. (According to [3], a user agent that wishes to accept an offer, but not a specific media-line MUST set the port number of that media-line to zero (0).) m=message 9 msrp * While MSRP could theoretically carry any media type, "message" is appropriate. For MSRP, the port number is always ignored--the actual port number is provided in an MSRP URL. Instead "9" is used, which is an innocuous value which is assigned to the discard port. The protocol is always "msrp", and the value of the format list is always a single asterisk character ("*"). An MSRP media-line is always accompanied by a mandatory "path" attribute. This attribute contains a space separated list of URLs that must be visited to contact the user agent advertising this session-description. If more than one URL is present, the leftmost URL is the first URL that must be visited to reach the target resource. (The path list can contain multiple URLs to allow for the deployment of gateways or relays in the future.) MSRP implementations which can accept incoming connections will typically only provide a single URL here. MSRP media lines MUST also be accompanied by an "accept-types" attribute. This attribute contains a list of MIME types which are acceptable to the endpoint. A "*" entry in the accept-types attribute indicates that the sender may attempt to send content with media types that have not been explicitly listed. Likewise, an entry with an explicit type and a "*" character as the subtype indicates that the sender may attempt to send content with any subtype of that type. If the receiver receives an MSRP request and is able to process the media type, it does so. If not, it will respond with a 415 response. Note that all explicit entries SHOULD be considered preferred over any non-listed types. Campbell, et al. Expires January 16, 2005 [Page 23] Internet-Draft MSRP July 2004 This feature is needed as, otherwise, the list of formats for rich IM devices may be prohibitively large. The accept-types attribute may include container types, that is, MIME formats that contain other types internally. If compound types are used, the types listed in the accept-types attribute may be used both as the root payload, or may be wrapped in a listed container type. Any container types MUST also be listed in the accept-types attribute. Occasionally an endpoint will need to specify a MIME body type that can only be used if wrapped inside a listed container type. Endpoints MAY specify MIME types that are only allowed when wrapped inside compound types using the "accept-wrapped-types" attribute in an SDP a-line. The semantics for accept-wrapped-types are identical to those of the accept-types attribute, with the exception that the specified types may only be used when wrapped inside containers. Only types listed in the accept-types attribute may be used as the "root" type for the entire body. Since any type listed in accept-types may be used both as a root body, and wrapped in other bodies, format entries from accept-types SHOULD NOT be repeated in this attribute. This approach does not allow for specifying distinct lists of acceptable wrapped types for different types of containers. If an endpoint understands a MIME type in the context of one wrapper, it is assumed to understand it in the context of any other acceptable wrappers, subject to any constraints defined by the wrapper types themselves. The approach of specifying types that are only allowed inside of containers separately from the primary payload types allows an endpoint to force the use of certain wrappers. For example, a CPIM [14] gateway device may require all messages to be wrapped inside message/cpim bodies, but may allow several content types inside the wrapper. If the gateway were to specify the wrapped types in the accept-types attribute, its peer might attempt to use those types without the wrapper. All types listed in either the accept-types or accept-wrapped-types attributes MAY include a max-size parameter, indicating the largest message it is willing to accept of that type. Max-size refers to the complete message, not the size of any one chunk. Senders MUST NOT exceed the max-size limit, if any, when sending messages of any listed type. If a type is listed without the parameter, then no preset size limit exists. Campbell, et al. Expires January 16, 2005 [Page 24] Internet-Draft MSRP July 2004 accept-types = accept-types-label ":" format-list accept-types-label = "accept-types" accept-wrapped-types = wrapped-types-label ":" format-list wrapped-types-label = "accept-wrapped-types" format-list = format-entry *( SP format-entry) format-entry = ctype [SEMI max-size] ctype = (type "/" subtype) / (type "/" "*") / ("*") type = token subtype = token max-size = "max" "=" 1*(DIGIT) 7.1.1 URL Negotiations Each endpoint in an MSRP session is identified by a URL. These URLs are negotiated in the SDP exchange. Each SDP offer or answer MUST contain one or more MSRP URL in a path attribute. This attribute has the following syntax: "a=path:" MSRP_URL *(SP MSRP_URL) where MSRP_URL is an msrp: or msrps: URL as defined in Section 5. MSRP URLs included in an SDP offer or answer MUST include explicit port numbers. An MSRP device uses the URL to determine a host address, port, transport, and protection level when connecting, and to identify the target when sending requests and responses. The offerer and answerer each selects a URL to represent itself, and send it to the peer device in the SDP document. Each device stores the path value received from the peer, and uses that value as the target for requests inside the resulting session. If the path attribute received from the peer contains more than one URL, then the target URL is the rightmost, while the leftmost entry represents the adjacent hop. If only one entry is present, then it is both the peer and adjacent hop URL. The target path is the entire path attribute value received from the peer. The following example shows an SDP offer with a session URL of "msrp://a.example.com:7394/2s93i;tcp" v=0 o=alice 2890844526 2890844527 IN IP4 alice.example.com s= c=IN IP4 alice.example.com m=message 9 msrp * a=accept-types:text/plain Campbell, et al. Expires January 16, 2005 [Page 25] Internet-Draft MSRP July 2004 a=path:msrp://a.example.com:7394/2s93i;tcp The rightmost URI in the path attribute MUST identify the endpoint that generated the SDP document, or some other location where that endpoint wishes to receive requests associated with the session. It MUST be assigned for this particular session, and MUST NOT duplicate any URI in use for any other session in which the endpoint is currently participating. It SHOULD be hard to guess, and protected from eavesdroppers. This is discussed in more detail in Section 14. 7.1.2 Path Attributes with Multiple URLs As mentioned previously, this document describes MSRP for peer-to-peer scenarios, that is, when no relays are used. However, we expect a separate document to describe the use of relays. In order to allow an MSRP device that only implements the core specification to interoperate with devices that use relays, this document must include a few assumptions about how relays work. An endpoint that uses one or more relays will indicate that by putting a URL for each device in the relay chain into the SDP path attribute. The final entry would point to the endpoint itself. The other entries would indicate each proposed relay, in order. The first entry would point to the first relay in the chain; that is, the relay to which the peer device, or a relay operation on its behalf, should connect. Endpoints that do not wish to insert a relay, including those that do not support relays at all, will put exactly one URL into the path attribute. This URL represents both the endpoint for the session, and the connection point. While endpoints that implement only this specification will never introduce a relay, they will need to be able to interoperate with other endpoints that do use relays. Therefore, they MUST be prepared to receive more than one URL in the SDP path attribute. When an endpoint receives more than one URL in a path header, only the first entry is relevant for purposes of resolving the address and port, and establishing the network connection, as it describes the first adjacent hop. If an endpoint puts more than one URL in a path attribute, the final URL in the path (the peer URL) attribute MUST exhibit the uniqueness properties described above. Uniqueness requirements for other entries in the attribute are out of scope for this document. Campbell, et al. Expires January 16, 2005 [Page 26] Internet-Draft MSRP July 2004 7.1.3 Updated SDP Offers MSRP endpoints may sometimes need to send additional SDP exchanges for an existing session. They may need to send periodic exchanges with no change to refresh state in the network, for example, SIP Session Timers. They may need to change some other stream in a session without affecting the MSRP stream, or they may need to change an MSRP stream without affecting some other stream. Either peer may initiate an updated exchange at any time. The endpoint that sends the new offer assumes the role of offerer for all purposes. The answerer MUST respond with a path attribute that represents a valid path to itself at the time of the updated exchange. This new path may be the same as its previous path, but may be different. The new offerer MUST NOT assume that the peer will answer with the same path it used previously. If either party wishes to send an SDP document that changes nothing at all, then it MUST have the same o-line as in the previous exchange. 7.1.4 Example SDP Exchange Endpoint A wishes to invite Endpoint B to a MSRP session. A offers the following session description: v=0 o=usera 2890844526 2890844527 IN IP4 alice.example.com s= c=IN IP4 alice.example.com t=0 0 m=message 9 msrp * a=accept-types: message/cpim text/plain text/html a=path:msrp://alice.example.com:7394/2s93i9;tcp B responds with its own URL: v=0 o=userb 2890844530 2890844532 IN IP4 bob.example.com s= c=IN IP4 bob.example.com t=0 0 m=message 9 msrp * a=accept-types:message/cpim text/plain a=path:msrp://bob.example.com:8493/si438ds;tcp Campbell, et al. Expires January 16, 2005 [Page 27] Internet-Draft MSRP July 2004 7.1.5 Connection Negotiation Previous versions of this document included a mechanism to negotiate the direction for any required TCP connection. The mechanism was loosely based on the COMEDIA [24]work being done in the MMUSIC working group. The primary motivation was to allow MSRP sessions to succeed in situations where the offerer could not accept connections but the answerer could. For example, the offerer might be behind a NAT, while the answerer might have a globally routable address. The SIMPLE working group chose to remove that mechanism from MSRP, as it added a great deal of complexity to connection management. Instead, MSRP now specifies a default connection direction. 7.2 MSRP User Experience with SIP In typical SIP applications, when an endpoint receives an INVITE request, it alerts the user, and waits for user input before responding. This is analogous to the typical telephone user experience, where the callee "answers" the call. In contrast, the typical user experience for instant messaging applications is that the initial received message is immediately displayed to the user, without waiting for the user to "join" the conversation. Therefore, the principle of least surprise would suggest that MSRP endpoints using SIP signaling SHOULD allow a mode where the endpoint quietly accepts the session, and begins displaying messages. SIP INVITE requests may be forked by a SIP proxy, resulting in more than one endpoint receiving the same INVITE. SIP early media [28] techniques can be used to establish a preliminary session with each endpoint, and canceling the INVITE transaction for any endpoints that do not send MSRP traffic after some period of time. 8. DSN payloads in MSRP REPORT Requests The format of a default REPORT request payload format the DSN taken from RFC1894 [8]. Only a minimal subset of fields are relevant for MSRP, as detailed in the remainder of this section. 8.1 Per-Message DSN header usage original-envelope-id: See Section 8.3 reporting-mta: See Section 8.4 dsn-gateway: Not Used Campbell, et al. Expires January 16, 2005 [Page 28] Internet-Draft MSRP July 2004 received-from-mta: Not Used arrival-date: Not Used 8.2 Per-Recipient DSN header usage original-recipient Not Used final-recipient: See Section 8.5 action: See Section 8.6 status: See Section 8.7 remote-mta: Not Used diagnostic-code: Not Used last-attempt-date: Not Used will-retry-until:Not Used 8.3 original-envelope-id usage The 'original-envelope-id' field contains a unique identifier which is used to correlate a DSN report with the originating MSRP transaction. The entity generating the DSN report MUST insert the Message-ID value that appeared in the original MSRP request into the 'original-envelope-id' field. This allows a requesting client to explicitly correlate a REPORT request with the original request. This correlation is implementation specific and makes no requirements on clients to hold state for transactions ID's. Information regarding the original request can be obtained from the DSN MIME type outlined in [8]. 8.4 reporting-mta The 'reporting-mta-field' MUST follow the guidelines set out in RFC 1894[8]. The 'mta-name-type' from RFC1894[8] MUST use the value of 'msrp-name-type', as defined in Section 15.4 of this specification. The 'mta-name' value for this field as specified in RFC1894 [8] MUST equal the MSRP URL representing itself in the context of the session. 8.5 final-recipient The 'final-recipient-field' MUST follow the guidelines set out in RFC 1894[8]. The 'address-type' from RFC1894 [8] MUST use the value of 'msrp-address-type', as defined in Section 15.4 of this Campbell, et al. Expires January 16, 2005 [Page 29] Internet-Draft MSRP July 2004 specification. The 'address-type' value for this field as specified in RFC1894 [8] MUST equal the final value contained in the MSRP 'To-Path' header from the original request. 8.6 action The 'action' field MUST follow the guidelines set out in RFC 1894[8]. An MSRP entity constructing a DSN report MUST use the 'delivered' value for a successful delivery and MUST use the 'failed' value for an unsuccessful delivery. The other values specified for the 'action' field in RFC 1894[8] MAY be used. 8.7 status The 'status' field MUST follow the guidelines set out in RFC 1894[8]. An MSRP entity constructing a DSN report MUST represent the MSRP status code in the correct format detailed in RFC 1894[8] for the 'status' field of a DSN report. An MSRP status code consists of a three digit number while a DSN status is three digits separated by '.'. An example would be: Status: 5.0.0 (unknown permanent failure) When generating this field the first digit of the MSRP status code (working from left to right) MUST be placed in the first part of the 'status' DSN field. The second digit MUST be placed in the second part of the 'status' DSN field. The third digit MUST be placed in the third part of the 'status' DSN field. An example of a DSN 'status' field value would be: An MSRP '200' success response would be mapped to: Status: 2.0.0 (OK) The MSRP reason phrase mapped to a DSN 'status' field MAY be enclosed in parentheses if required. 9. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [6]. msrp-req-or-resp = msrp-request / msrp-response msrp-request = req-start headers [content-stuff] end-line msrp-response = resp-start headers end-line req-start = pMSRP SP transact-id SP method CRLF Campbell, et al. Expires January 16, 2005 [Page 30] Internet-Draft MSRP July 2004 resp-start = pMSRP SP transact-id SP status-code [SP phrase] CRLF phrase = utf8text pMSRP = %4d.53.52.50 ; MSRP in caps transact-id = ident method = mSEND / mREPORT / other-method mSEND = %53.45.4e.44 ; SEND in caps mREPORT = %52.45.50.4f.52.54; REPORT in caps other-method = 1*UPALPHA status-code = 3DIGIT headers = 1*( header CRLF ) header = ( To-Path / From-Path / Message-ID / Report-Success / Report-Failure / Byte-Range / Status / Mime-Header / ext-header ) To-Path = "To-Path:" SP URL *( SP URL ) From-Path = "From-Path:" SP URL *( SP URL ) Message-ID = "Message-ID:" SP ident Report-Success = "Report-Success:" SP ("yes" / "no" ) Report-Failure = "Report-Failure:" SP ("yes" / "no" / "partial" ) Byte-Range = "Byte-Range:" SP range-start "-" range-end "/" total range-start = 1*DIGIT range-end = 1*DIGIT / "*" total = 1*DIGIT / "*" Status = "Status:" SP namespace SP short-status [SP text-reason] ident = alphanum 3*31ident-char ident-char = alphanum / "." / "-" / "+" / "%" / "=" content-stuff = *(Other-Mime-Header CRLF) Content-Type 2CRLF data CRLF Content-Type = "Content-Type:" SP media-type media-type = type "/" subtype *( ";" gen-param ) type = token subtype = token gen-param = pname [ "=" pval ] Campbell, et al. Expires January 16, 2005 [Page 31] Internet-Draft MSRP July 2004 pname = token pval = token / quoted-string token = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE qdtext = SP / HT / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE) BACKSLASH = "\" DQUOTE = %x22 Other-Mime-Header = (Content-ID / Content-Description / Content-Disposition / mime-extension-field); ; Content-ID, and Content-Description are defined in RFC2045. ; Content-Disposition is defined in RFC2183 ; MIME-extension-field indicates additional MIME extension ; headers as described in RFC2045 data = *OCTET end-line = "-------" transact-id continuation-flag CRLF continuation-flag = "+" / "$" ext-header = hname ":" SP hval CRLF hname = alpha *token hval = utf8text utf8text = *(HT / %x20-7E / UTF8-NONASCII) UTF8-NONASCII = %xC0-DF 1UTF8-CONT / %xE0-EF 2UTF8-CONT / %xF0-F7 3UTF8-CONT / %xF8-Fb 4UTF8-CONT / %xFC-FD 5UTF8-CONT UTF8-CONT = %x80-BF 10. Response Code Descriptions This section summarizes the semantics of various response codes that may be used in MSRP transaction responses. These codes may also be used in the Status header in REPORT requests. Campbell, et al. Expires January 16, 2005 [Page 32] Internet-Draft MSRP July 2004 10.1 200 The 200 response code indicates a successful transaction. 10.2 400 A 400 response indicates a request was unintelligible. 10.3 403 The action is not allowed 10.4 415 A 415 response indicates the SEND request contained a MIME content-type that is not understood by the receiver. 10.5 426 A 426 response indicates that the request is only allowed over TLS protected connections. 10.6 481 A 481 response indicates that no session exists for the connection. 10.7 506 A 506 response indicates that a request arrived on a session which is already bound to another network connection. 11. Examples 11.1 Basic IM session This section shows an example flow for the most common scenario. The example assumes SIP is used to transport the SDP exchange. Details of the SIP messages and SIP proxy infrastructure are omitted for the sake of brevity. In the example, assume the offerer is sip:alice@example.com and the answerer is sip:bob@example.com. Campbell, et al. Expires January 16, 2005 [Page 33] Internet-Draft MSRP July 2004 Alice Bob | | | | |(1) (SIP) INVITE | |----------------------->| |(4) (SIP) 200 OK | |<-----------------------| |(5) (SIP) ACK | |----------------------->| |(6) (MSRP) SEND | |----------------------->| |(7) (MSRP) 200 OK | |<-----------------------| |(8) (MSRP) SEND | |<-----------------------| |(9) (MSRP) 200 OK | |----------------------->| |(10) (SIP) BYE | |----------------------->| |(11) (SIP) 200 OK | |<-----------------------| | | | | 1. Alice constructs a local URL of msrp://alicepc.example.com:7777/iau39;tcp . Alice->Bob (SIP): INVITE sip:bob@example.com v=0 o=alice 2890844557 2890844559 IN IP4 alicepc.example.com s= c=IN IP4 alicepc.example.com t=0 0 m=message 9 msrp * a=accept-types:text/plain a=path:msrp://alicepc.example.com:7777/iau39;tcp 2. Bob listens on port 8888, and sends the following response: 3. Bob->Alice (SIP): 200 OK v=0 o=bob 2890844612 2890844616 IN IP4 bob.example.com s= c=IN IP4 bob.example.com t=0 0 m=message 9 msrp * a=accept-types:text/plain Campbell, et al. Expires January 16, 2005 [Page 34] Internet-Draft MSRP July 2004 a=path:msrp://bob.example.com:8888/9di4ea;tcp 4. Alice->Bob (SIP): ACK 5. (Alice opens connection to Bob.) Alice->Bob (MSRP): MSRP d93kswow SEND To-Path:msrp://bob.example.com:8888/9di4ea;tcp From-Path:msrp://alicepc.example.com:7777/iau39;tcp Message-ID: 12339sdqwer Content-Type:text/plain Hi, I'm Alice! -------d93kswow$ 6. Bob->Alice (MSRP): MSRP d93kswow 200 OK To-Path:msrp://bob.example.com:8888/9di4ea;tcp From-Path:msrp://alicepc.example.com:7777/iau39;tcp -------d93kswow$ 7. Bob->Alice (MSRP): MSRP dkei38sd SEND To-Path:msrp://alice.example.com:7777/iau39;tcp From-Path:msrp://bob.example.com:8888/9di4ea;tcp Message-ID: 456 Content-Type:text/plain Hi, Alice! I'm Bob! -------dkei38sd$ 8. Alice->Bob (MSRP): MSRP dkei38sd 200 OK To-Path:msrp://alice.example.com:7777/iau39;tcp From-Path:msrp://bob.example.com:8888/9di4ea;tcp -------dkei38sd$ 9. Alice->Bob (SIP): BYE Alice invalidates local session state. 10. Bob invalidates local state for the session. Bob->Alice (SIP): 200 OK Campbell, et al. Expires January 16, 2005 [Page 35] Internet-Draft MSRP July 2004 11.2 Chunked Message For an example of a chunked message, see the example in Section 4.1. 11.3 System Message Sysadmin->Alice (MSRP): MSRP d93kswow SEND To-Path:msrp://alicepc.example.com:8888/9di4ea;tcp From-Path:msrp://example.com:7777/iau39;tcp Message-ID: 12339sdqwer Report-Failure: no Report-Success: no Content-Type:text/plain The system is going down in 5 minutes -------d93kswow$ Campbell, et al. Expires January 16, 2005 [Page 36] Internet-Draft MSRP July 2004 11.4 Positive Report Alice->Bob (MSRP): MSRP d93kswow SEND To-Path:msrp://bob.example.com:8888/9di4ea;tcp From-Path:msrp://alicepc.example.com:7777/iau39;tcp Message-ID: 12339sdqwer Report-Success: yes Content-Type:text/html

Here is that important link... foobar

-------d93kswow$ Bob->Alice (MSRP): MSRP d93kswow 200 OK To-Path:msrp://alicepc.example.com:7777/iau39;tcp From-Path:msrp://bob.example.com:8888/9di4ea;tcp -------d93kswow$ Bob->Alice (MSRP): MSRP dkei38sd SEND To-Path:msrp://alicepc.example.com:7777/iau39;tcp From-Path:msrp://bob.example.com:8888/9di4ea;tcp Message-ID: 12339sdqwer Status: 000 200 OK -------dkei38sd$ 11.5 Forked IM Traditional IM systems generally do a poor job of handling multiple simultaneous IM clients online for the same person. While some do a better job than many existing systems, handling of multiple clients is fairly crude. This becomes a much more significant issue when always-on mobile devices are available, but when it is desirable to use them only if another IM client is not available. Using SIP makes rendezvous decisions explicit, deterministic, and very flexible; instead "pager-mode" IM systems use implicit implementation-specific decisions which IM clients cannot influence. Campbell, et al. Expires January 16, 2005 [Page 37] Internet-Draft MSRP July 2004 With SIP session mode messaging rendezvous decisions can be under control of the client in a predictable, interoperable way for any host that implements callee capabilities [30]. As a result, rendezvous policy is managed consistently for each address of record. The following example shows Juliet with several IM clients where she can be reached. Each of these has a unique SIP Contact and MSRP session. The example takes advantage of SIP's capability to "fork" an invitation to several Contacts in parallel, in sequence, or in combination. Juliet has registered from her chamber, the balcony, her PDA, and as a last resort, you can leave a message with her Nurse. Juliet's contacts are listed below. The q-values express relative preference (q=1.0 is the highest preference). We query for a list of Juliet's contacts by sending a REGISTER: REGISTER sip:thecapulets.example.com SIP/2.0 To: Juliet From: Juliet ;tag=12345 Call-ID: 09887877 CSeq: 772 REGISTER The Response contains her Contacts: SIP/2.0 200 OK To: Juliet From: Juliet ;tag=12345 Call-ID: 09887877 CSeq: 771 REGISTER Contact: ;q=0.9;expires=3600 Contact: ;q=1.0;expires=3600 Contact: ;q=0.4;expires=3600 Contact: ;q=0.1;expires=3600 When Romeo opens his IM program, he selects Juliet and types the message "art thou hither?" (instead of "you there?"). His client sends a SIP invitation to sip:juliet@thecapulets.example.com. The Proxy there tries first the balcony and the chamber simultaneously. A client is running on both those systems, both of which setup early sessions of MSRP with Romeo's client. The client automatically sends the message over the MSRPS to the two MSPR URIs involved. After a delay of a several seconds with no reply or activity from Juliet, the proxy cancels the invitation at her first two contacts, and forwards the invitation on to Juliet's PDA. Since her father is talking to Campbell, et al. Expires January 16, 2005 [Page 38] Internet-Draft MSRP July 2004 her about her wedding, she selects "Do Not Disturb" on her PDA, which sends a "Busy Here" response. The proxy then tries the Nurse, who answers and tells Romeo what is going on. Romeo Juliet's Juliet/ Juliet/ Juliet/ Nurse Proxy balcony chamber PDA | | | | | | |--INVITE--->| | | | | | |--INVITE--->| | | | | |<----180----| | | | |<----180----| | | | | |---PRACK---------------->| | | | |<----200-----------------| | | | |<===Early MSRP Session==>| art thou hither? | | | | | | | | | |--INVITE---------------->| | | | |<----180-----------------| | | |<----180----| | | | | |---PRACK----------------------------->| | | |<----200------------------------------| | | |<========Early MSRP Session==========>| art thou hither? | | | | | | | | | | | | | | | .... Time Passes .... | | | | | | | | | | | | | | | | |--CANCEL--->| | | | | |<---200-----| | | | | |<---487-----| | | | | |----ACK---->| | | | | |--CANCEL---------------->| | | | |<---200------------------| | | | |<---487------------------| | | | |----ACK----------------->| | | | |--INVITE---------------------------->| romeo wants | | | | | to IM w/ you | |<---486 Busy Here--------------------| | | |----ACK----------------------------->| | | | | | | | | |--INVITE---------------------------------------->| | |<---200 OK---------------------------------------| |<--200 OK---| | | | | |---ACK------------------------------------------------------->| |<================MSRP Session================================>| | | | | | | Campbell, et al. Expires January 16, 2005 [Page 39] Internet-Draft MSRP July 2004 | Hi Romeo, Juliet is | | with her father now | | can i take a message?| | | | Tell her to go to confession tommorrow.... | 12. Extensibility MSRP was designed to be only minimally extensible. New MSRP Methods, Headers, and status codes can be defined in standards track RFCs. There is no registry of headers, methods, or status codes, since the number of new elements and total extensions is expected to be very small. MSRP does not contain a version number or any negotiation mechanism to require or discover new features. MSRP was designed to use lists of URLs instead of a single URL in the To-Path and From-Path headers in anticipation of relay or gateway functionality being added. In addition, msrp: and msrps: URLs can contain parameters which are extensible. 13. CPIM compatibility MSRP sessions may be gatewayed to other CPIM [25]compatible protocols. If this occurs, the gateway MUST maintain session state, and MUST translate between the MSRP session semantics and CPIM semantics that do not include a concept of sessions. Furthermore, when one endpoint of the session is a CPIM gateway, instant messages SHOULD be wrapped in "message/cpim" [7] bodies. Such a gateway MUST include "message/cpim" as the first entry in its SDP accept-types attribute. MSRP endpoints sending instant messages to a peer that has included 'message/cpim" as the first entry in the accept-types attribute SHOULD encapsulate all instant message bodies in "message/ cpim" wrappers. All MSRP endpoints MUST support the message/cpim type, and SHOULD support the S/MIME features of that format. 14. Security Considerations Instant Messaging systems are used to exchange a variety of sensitive information ranging from personal conversations, to corporate confidential information, to account numbers and other financial trading information. IM is used by individuals, corporations, and governments for communicating important information. Like many communications systems, the properties of Integrity and Confidentiality of the exchanged information, along with the possibility of Anonymous communications, and knowing you are communicating with the correct other party are required. MSRP pushes Campbell, et al. Expires January 16, 2005 [Page 40] Internet-Draft MSRP July 2004 many of the hard problems to SIP when SIP sets up the session, but some of the problems remain. Spam and DoS attacks are also very relevant to IM systems. MSRP needs to provide confidentiality and integrity for the messages it transfers. It also needs to provide assurances the connected host is the host that it meant to connect to and that the connection has not been hijacked. When using only TCP connections, MSRP security is fairly weak. If host A is contacting B, B passes its hostname and a secret to A using SIP. If the SIP offer or answer is not TLS or S/MIME [27] protected, anyone can see this secret. A then connects to the provided host name and passes the secret in the clear across the connection to B. A assumes that it is talking to B based on where it sent the SYN packet and then delivers the secret in plain text across the connections. B assumes it is talking to A because the host on the other end of the connection delivered the secret. An attacker that could ACK the SYN packet could insert itself as a man in the middle in the connection. When using TLS connections, the security is significantly improved. We assume that the host accepting the connection has a certificate from a well know certificate authority. Furthermore, we assume that the SIP signaling to set up the session is protected with TLS (using sips). In this case, when host A contacts host B, the secret is passed through a SIP confidential channel to A. A connects with TLS to B. B presents a valid certificate, so A knows it really is connected to B. A then delivers the secret provided by B, so that B can verify it is connected to A. In this case, a rogue SIP Proxy can see the secret in the SIP signaling traffic and could potentially insert itself as a man-in-the-middle. Realistically, using TLS is only feasible when connecting to gateways or relays , as the types of hosts that end clients use for sending instant messages are unlikely to have a long term stable IP address or a stable DNS name that a certificate can bind to. In addition, the cost of server certificates from well known certificate authorities is currently too high for the vast majority of end users to even consider getting one for each client. The only real security for connections without relays is achieved using S/MIME. This does not require the actual endpoint to have certificates from a well known certificate authority. The Identity [22] and Certificates [23] mechanism with SIP provides S/MIME based delivery of a secret between A and B. No SIP intermediary except the explicitly trusted authentication service (one per user) can see the secret. The S/MIME encryption of the SDP can also be used by SIP to Campbell, et al. Expires January 16, 2005 [Page 41] Internet-Draft MSRP July 2004 exchange keying material that can be used in MRSP. The MSRP session can then use S/MIME with this keying material to encrypt and sign messages sent over MSRP. The connection can still be hijacked since the secret is sent in clear text to the other end of the TCP connection, but this risk is mitigated if all the MSRP content is encrypted and signed with S/MIME. MSRP can not be used as an amplifier for DoS attacks, but it can be used to form a distributed attack to consume TCP connection resource on servers. The attacker, Eve, sends an SIP INVITE with no offer to Alice. Alice returns a 200 with an offer and Eve returns an answer with the SDP that indicates that her MSRP address is the address of Tom. Since Alice sent the offer, Alice will initiate a connection to Tom using up resources on Tom's server. Given the huge number of IM clients, and the relatively few TCP connections that most servers support, this is a fairly straightforward attack. SIP is attempting to address issues in dealing with spam. The spam issue is probably best dealt with at the SIP level when an MSRP session is initiated and not at the MSRP level. TLS is used to authenticate devices and to provide integrity and confidentiality for the headers being transported. MSRP elements MUST implement TLS and MUST also implement the TLS ClientExtendedHello extended hello information for server name indication as described in [12]. A TLS cipher-suite of TLS_RSA_WITH_AES_128_CBC_SHA [15] MUST be supported (other cipher-suites MAY also be supported). Since MSRP carries arbitrary MIME content, it can trivially carry S/ MIME protected messages as well. All MSRP implementations MUST support the multipart/signed MIME type even if they do not support S/ MIME. Since SIP can carry a session key, S/MIME messages in the context of a session could also be protected using a key-wrapped shared secret [26] provided in the session setup. 15. IANA Considerations 15.1 MSRP Port MSRP uses TCP port XYX, to be determined by IANA after this document is approved for publication. Usage of this value is described in Section 5 15.2 MSRP URL Schemes This document defines the URL schemes of "msrp" and "msrps". Campbell, et al. Expires January 16, 2005 [Page 42] Internet-Draft MSRP July 2004 Syntax See Section 5. Character Encoding See Section 5. Intended Usage See Section 5. Protocols The Message Session Relay Protocol (MSRP). Security Considerations See Section 14. Relevant Publications RFCXXXX [Note to RFC Editor: Please replace RFCXXXX in the above paragraph with the actual number assigned to this document. 15.3 SDP Parameters This document registers the following SDP parameters in the sdp-parameters registry: 15.3.1 Accept Types Attribute-name: accept-types Long-form Attribute Name Acceptable MIME Types Type: Media level Subject to Charset Attribute No Purpose and Appropriate Values See Section 7.1. 15.3.2 Wrapped Types Attribute-name: accept-wrapped-types Long-form Attribute Name Acceptable MIME Types Inside Wrappers Type: Media level Subject to Charset Attribute No Purpose and Appropriate Values See Section 7.1. 15.3.3 Path Attribute-name: path Long-form Attribute Name MSRP URL Path Type: Media level Subject to Charset Attribute No Purpose and Appropriate Values See Section 7.1.1. 15.4 IANA registration forms for DSN types 15.4.1 IANA registration form for address-type This document registers a new 'address-type' for use in conjunction with RFC1894[8]. The authors request that these values be recorded in the IANA registry for DSN 'address-type'. Proposed Address name: msrp-address-type Campbell, et al. Expires January 16, 2005 [Page 43] Internet-Draft MSRP July 2004 Syntax: See Section 5 15.4.2 IANA registration form for MTA-name-type This document registers a new 'MTA-name-type' for use in conjunction with RFC1894[8]. The authors request that these values be recorded in the IANA registry for DSN 'MTA-name-type'. Proposed Address name: msrp-name-type Syntax: See Section 5 16. Change History 16.1 draft-ietf-simple-message-sessions-07 Significant re-write to attempt to improve readability. Added maximum size parameter in accept-types Changed the Boundary field to be part of the start-line rather than a header field. Removed the TR-IDheader, and changed request-response matching to be based on the Boundary field value. Responses still contain the TR-ID header, which must match the Boundary from the request. Removed transport selection from URL scheme and added the "tcp" parameter. Added description of the "simple" mode with no transaction responses, and made mode selection dependent on the reporting level requested for a give message. Changed the DSN section to reflect separate request of success and failure reports. Enhanced REPORT method to be useful even without a payload. removed SRV usage for URL resolution. This is only used for relay discovery, and therefore should be moved to the relay draft. Added discussion about late REPORT handling. Asserted that REPORT requests are always sent in simple mode. Removed the dependency on multipart/byteranges for fragmentation. Incorporated the Byte-Range header into the base MSRP header set. Removed the VISIT method. Change to use SEND to serve the purpose formerly reserved to VISIT. 16.2 draft-ietf-simple-message-sessions-06 Changed To and From header names to To-Path and From-Path. Added more clarification to path handling, and commentary on how it enables relay usage. Changed mechanism for signaling transport and TLS protection into the MSRP URL, rather than the SDP M-Line. Campbell, et al. Expires January 16, 2005 [Page 44] Internet-Draft MSRP July 2004 Removed length field from start line and added Boundary header field and Closing field. Added recommendation to fragment any content over 2k. Added Rohan's proposal to make offerer connect to answerer. (With open issue for more discussion.) Changed To-Path and From-Path usage in responses to indicate the destination and source of the response, rather than merely copy from the associated request. Updated DSN section. Added text on field usage. Fixed change TR-ID header from version 05 were erroneously attributed to 04. 16.3 draft-ietf-simple-message-sessions-05 Changed the use of session URLs. Instead of a single session URL, each endpoint is identified by a distinct URL. MSRP requests will put the destination URL in a To header, and the sender URL in a From header. Changed the SDP exchange of MSRP URLs to handle the URL for each endpoint. Further, changed the SDP attribute to support a list of URLs in each direction. This may be used with relays to exchange paths, rather than single URLs. MSRP endpoints must be able to intelligently process such a list if received. This document does not, however, describe how to generate such a list. Added section for Delivery Status Notification handling, and added associated entries into the syntax definition. Added content fragmentation section. Removed recommendation to start separate session for large transfers. Corrected some mistakes in the syntax definitions. Added Chris Boulton as a co-author for his contribution of the DSN text. 16.4 draft-ietf-simple-message-sessions-04 Removed the direction attribute. Rather than using a comedia styled direction negotiation, we just state that the answerer opens any needed connection. 16.5 draft-ietf-simple-message-sessions-03 Removed all specification of relays, and all features specific to the use of relays. The working group has chosen to move relay work into a separate effort, in order to advance the base specification. (The MSRP acronym is unchanged for the sake of convenience.) This included removal of the BIND method, all response codes specific to BIND, Digest Authentication, and the inactivity timeout. Campbell, et al. Expires January 16, 2005 [Page 45] Internet-Draft MSRP July 2004 Removed text indicating that an endpoint could retry failed requests on the same connection. Rather, the endpoint should consider the connection dead, and either signal a reconnection or end the session. Added text describing subsequent SDP exchanges. Added mandatory "count" parameter to the direction attribute to allow explicit signaling of the need to reconnect. Added text to describe the use of send and receive only indicators in SDP for one-way transfer of large content. Added text requiring unique port field values if multiple M-line's exist. Corrected a number of editorial mistakes. 16.6 draft-ietf-simple-message-sessions-02 Moved all content type negotiation from the "m"-line format list into "a"-line attributes. Added the accept-types attribute. This is due to the fact that the sdp format-list syntax is not conducive to encoding MIME content types values. Added "other-method" construction to the message syntax to allow for extensible methods. Consolidated all syntax definitions into the same section. Cleaned up ABNF for digest challenge and response syntax. Changed the session inactivity timeout to 12 minutes. Required support for the SHA1 algorithm. Required support for the message/cpim format. Fixed lots of editorial issues. Documented a number of open issues from recent list discussions. 16.7 draft-ietf-simple-message-sessions-01 Abstract rewritten. Added architectural considerations section. The m-line format list now only describes the root body part for a request. Contained body part types may be described in the "accept-wrapped-types" a-line attribute. Added a standard dummy value for the m-line port field. Clarified that a zero in this field has normal SDP meaning. Clarified that an endpoint is globally configured as to whether or not to use a relay. There is no relay discovery mechanism intrinsic to MSRP. Changed digest algorithm to SHA1. Added TR-ID and S-URI to the hash for digest authentication. CMS usage replaced with S/MIME. TLS and msrps: usage clarified. Session state timeout is now based on SEND activity, rather than BIND and VISIT refreshes. Campbell, et al. Expires January 16, 2005 [Page 46] Internet-Draft MSRP July 2004 Default port added. Added sequence diagrams to the example message flows. Added discussion of self-signed certificates in the security considerations section. 16.8 draft-ietf-simple-message-sessions-00 Name changed to reflect status as a work group item. This version no longer supports the use of multiple sessions across a single TCP session. This has several related changes: There is now a single session URI, rather than a separate one for each endpoint. The session URI is not required to be in requests other than BIND and VISIT, as the session can be determined based on the connection on which it arrives. BIND and VISIT now create soft state, eliminating the need for the RELEASE and LEAVE methods. The MSRP URL format was changed to better reflect generic URL standards. URL comparison and resolution rules were added. SRV usage added. Determination of host and visitor roles now uses a direction attribute much like the one used in COMEDIA. Format list negotiation expanded to allow a "prefer these formats but try anything" semantic Clarified handling of direction notification failures. Clarified signaling associated with session failure due to dropped connections. Clarified security related motivations for MSRP. Removed MIKEY dependency for session key exchange. Simple usage of k-lines in SDP, where the SDP exchange is protected end-to-end seems sufficient. 16.9 draft-campbell-simple-im-sessions-01 Version 01 is a significant re-write. References to COMEDIA were removed, as it was determined that COMEDIA would not allow connections to be used bidirectional in the presence of NATs. Significantly more discussion of a concrete mechanism has been added to make up for no longer using COMEDIA. Additionally, this draft and draft-campbell-cpimmsg-sessions (which would have also changed drastically) have now been combined into this single draft. 17. Contributors and Acknowledgments In addition to the editor, The following people contributed extensive work to this document: Chris Boulton, Cullen Jennings, Paul Kyzivat, Rohan Mahy, Adam Roach, Jonathan Rosenberg, Robert Sparks. The following people contributed substantial discussion and feedback Campbell, et al. Expires January 16, 2005 [Page 47] Internet-Draft MSRP July 2004 to this ongoing effort: Allison Mankin, Jon Peterson, Brian Rosen, Dean Willis, Aki Niemi, Hisham Khartabil, Pekka Pessi, Orit Levin. 18. References 18.1 Normative References [1] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [7] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in progress), January 2003. [8] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996. [9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [10] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. [11] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [12] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003. Campbell, et al. Expires January 16, 2005 [Page 48] Internet-Draft MSRP July 2004 [13] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [14] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in progress), January 2003. [15] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Secur ity (TLS)", RFC 3268, June 2002. 18.2 Informational References [16] Johnston, A. and O. Levin, "Session Initiation Protocol Call Control - Conferencing for User Agents", draft-ietf-sipping-cc-conferencing-03 (work in progress), February 2004. [17] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo, "Best Current Practices for Third Party Call Control in the Session Initiation Protocol", draft-ietf-sipping-3pcc-06 (work in progress), January 2004. [18] Sparks, R. and A. Johnston, "Session Initiation Protocol Call Control - Transfer", draft-ietf-sipping-cc-transfer-02 (work in progress), February 2004. [19] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [20] Mahy, R., "Benefits and Motivation for Session Mode Instant Messaging", draft-mahy-simple-why-session-mode-00 (work in progress), February 2004. [21] Mahy, R. and C. Jennings, "Relays for the Message Session Relay Protocol (MSRP)", draft-ietf-simple-msrp-relays-01.txt (work in progress), July 2004. [22] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-02 (work in progress), May 2004. [23] Jennings, C. and J. Peterson, "Certificate Management Service for SIP", draft-jennings-sipping-certs-03 (work in progress), May 2004. [24] Yon, D., "Connection-Oriented Media Transport in SDP", draft-ietf-mmusic-sdp-comedia-05 (work in progress), March Campbell, et al. Expires January 16, 2005 [Page 49] Internet-Draft MSRP July 2004 2003. [25] Peterson, J., "A Common Profile for Instant Messaging (CPIM)", draft-ietf-impp-im-04 (work in progress), August 2003. [26] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, December 2001. [27] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [28] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", draft-ietf-sipping-early-media-02 (work in progress), June 2004. [29] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", draft-ietf-xmpp-im-22 (work in progress), April 2004. [30] Rosenberg, J., "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", draft-ietf-sip-callee-caps-03 (work in progress), January 2004. Authors' Addresses Ben Campbell (editor) EMail: ben@nostrum.com Rohan Mahy Cisco Systems, Inc. 5617 Scotts Valley Drive, Suite 200 Scotts Valley, CA 95066 USA EMail: rohan@cisco.com Campbell, et al. Expires January 16, 2005 [Page 50] Internet-Draft MSRP July 2004 Cullen Jennings Cisco Systems, Inc. 170 West Tasman Dr. MS: SJC-21/2 San Jose, CA 95134 USA EMail: fluffy@cisco.com Campbell, et al. Expires January 16, 2005 [Page 51] Internet-Draft MSRP July 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Campbell, et al. Expires January 16, 2005 [Page 52]