diff options
Diffstat (limited to 'doc/rfc/rfc4975.txt')
| -rw-r--r-- | doc/rfc/rfc4975.txt | 3531 |
1 files changed, 3531 insertions, 0 deletions
diff --git a/doc/rfc/rfc4975.txt b/doc/rfc/rfc4975.txt new file mode 100644 index 0000000..20a5800 --- /dev/null +++ b/doc/rfc/rfc4975.txt @@ -0,0 +1,3531 @@ + + + + + + +Network Working Group B. Campbell, Ed. +Request for Comments: 4975 Estacado Systems +Category: Standards Track R. Mahy, Ed. + Plantronics + C. Jennings, Ed. + Cisco Systems, Inc. + September 2007 + + + The Message Session Relay Protocol (MSRP) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document describes the Message Session Relay Protocol, 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 set up via a rendezvous or session creation + protocol such as the Session Initiation Protocol. + + + + + + + + + + + + + + + + + + + + + + + + + +Campbell, et al. Standards Track [Page 1] + +RFC 4975 MSRP September 2007 + + +Table of Contents + + 1. Introduction ....................................................4 + 2. Conventions .....................................................5 + 3. Applicability of MSRP ...........................................5 + 4. Protocol Overview ...............................................6 + 5. Key Concepts ....................................................9 + 5.1. MSRP Framing and Message Chunking ..........................9 + 5.2. MSRP Addressing ...........................................10 + 5.3. MSRP Transaction and Report Model .........................11 + 5.4. MSRP Connection Model .....................................12 + 6. MSRP URIs ......................................................14 + 6.1. MSRP URI Comparison .......................................15 + 6.2. Resolving MSRP Host Device ................................16 + 7. Method-Specific Behavior .......................................17 + 7.1. Constructing Requests .....................................17 + 7.1.1. Sending SEND Requests ..............................18 + 7.1.2. Sending REPORT Requests ............................21 + 7.1.3. Generating Success Reports .........................22 + 7.1.4. Generating Failure Reports .........................23 + 7.2. Constructing Responses ....................................24 + 7.3. Receiving Requests ........................................25 + 7.3.1. Receiving SEND Requests ............................25 + 7.3.2. Receiving REPORT Requests ..........................27 + 8. Using MSRP with SIP and SDP ....................................27 + 8.1. SDP Connection and Media-Lines ............................28 + 8.2. URI Negotiations ..........................................29 + 8.3. Path Attributes with Multiple URIs ........................30 + 8.4. Updated SDP Offers ........................................31 + 8.5. Connection Negotiation ....................................31 + 8.6. Content Type Negotiation ..................................32 + 8.7. Example SDP Exchange ......................................34 + 8.8. MSRP User Experience with SIP .............................35 + 8.9. SDP Direction Attribute and MSRP ..........................35 + 9. Formal Syntax ..................................................36 + 10. Response Code Descriptions ....................................38 + 10.1. 200 ......................................................38 + 10.2. 400 ......................................................38 + 10.3. 403 ......................................................38 + 10.4. 408 ......................................................39 + 10.5. 413 ......................................................39 + 10.6. 415 ......................................................39 + 10.7. 423 ......................................................39 + 10.8. 481 ......................................................39 + 10.9. 501 ......................................................39 + 10.10. 506 .....................................................40 + + + + + +Campbell, et al. Standards Track [Page 2] + +RFC 4975 MSRP September 2007 + + + 11. Examples ......................................................40 + 11.1. Basic IM Session .........................................40 + 11.2. Message with XHTML Content ...............................42 + 11.3. Chunked Message ..........................................43 + 11.4. Chunked Message with Message/CPIM Payload ................43 + 11.5. System Message ...........................................44 + 11.6. Positive Report ..........................................44 + 11.7. Forked IM ................................................45 + 12. Extensibility .................................................48 + 13. CPIM Compatibility ............................................48 + 14. Security Considerations .......................................49 + 14.1. Secrecy of the MSRP URI ..................................50 + 14.2. Transport Level Protection ...............................50 + 14.3. S/MIME ...................................................51 + 14.4. Using TLS in Peer-to-Peer Mode ...........................52 + 14.5. Other Security Concerns ..................................53 + 15. IANA Considerations ...........................................55 + 15.1. MSRP Method Names ........................................55 + 15.2. MSRP Header Fields .......................................55 + 15.3. MSRP Status Codes ........................................56 + 15.4. MSRP Port ................................................56 + 15.5. URI Schema ...............................................56 + 15.5.1. MSRP Scheme .......................................56 + 15.5.2. MSRPS Scheme ......................................57 + 15.6. SDP Transport Protocol ...................................57 + 15.7. SDP Attribute Names ......................................58 + 15.7.1. Accept Types ......................................58 + 15.7.2. Wrapped Types .....................................58 + 15.7.3. Max Size ..........................................58 + 15.7.4. Path ..............................................58 + 16. Contributors and Acknowledgments ..............................59 + 17. References ....................................................59 + 17.1. Normative References .....................................59 + 17.2. Informative References ...................................60 + + + + + + + + + + + + + + + + + +Campbell, et al. Standards Track [Page 3] + +RFC 4975 MSRP September 2007 + + +1. Introduction + + A series of related instant messages between two or more parties can + be viewed as part of a "message session", that is, a conversational + exchange of messages with a definite beginning and end. This is in + contrast to individual messages each sent independently. Messaging + schemes that track only individual messages can be described as + "page-mode" messaging, 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 SIP via the SIP [4] MESSAGE method + [22]. Session-mode messaging has a number of benefits 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 called the Message Session Relay Protocol (MSRP), whose + sessions can be negotiated with an offer or answer [3] using the + Session Description Protocol (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. + + When a user uses an Instant Messaging (IM) URL, RFC 3861 [32] defines + how DNS can be used to map this to a particular protocol to establish + the session such as SIP. SIP can use an offer/answer model to + transport the MSRP URIs for the media in SDP. This document defines + how the offer/answer exchange works to establish MSRP connections and + how messages are sent across the MSRP, but it does not deal with the + issues of mapping an IM URL to a session establishment protocol. + + 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 [21] Alice to Carol, introducing them into their own + messaging session. Messaging sessions can then be easily integrated + into call-center and dispatch environments using third-party call + control [20] and conferencing [19] applications. + + + +Campbell, et al. Standards Track [Page 4] + +RFC 4975 MSRP September 2007 + + + This document specifies MSRP behavior only for peer-to-peer sessions, + that is, sessions crossing only a single hop. MSRP relay devices + [23] (referred to herein as "relays") are specified in a separate + document. An endpoint that implements this specification, but not + the relay specification, will be unable to introduce relays into the + message path, but will still be able to interoperate with peers that + do use relays. + +2. 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". + +3. Applicability of MSRP + + MSRP is not designed for use as a standalone protocol. MSRP MUST be + used only in the context of a rendezvous mechanism meeting the + following requirements: + + o The rendezvous mechanism MUST provide both MSRP URIs associated + with an MSRP session to each of the participating endpoints. The + rendezvous mechanism MUST implement mechanisms to protect the + confidentiality of these URIs -- they MUST NOT be made available + to an untrusted third party or be easily discoverable. + + o The rendezvous mechanism MUST provide mechanisms for the + negotiation of any supported MSRP extensions that are not + backwards compatible. + + o The rendezvous mechanism MUST be able to natively transport im: + URIs or automatically translate im: URIs [27] into the addressing + identifiers of the rendezvous protocol. + + To use a rendezvous mechanism with MSRP, an RFC MUST be prepared that + describes how it exchanges MSRP URIs and meets these requirements + listed here. This document provides such a description for the use + of MSRP in the context of SIP and SDP. + + SIP meets these requirements for a rendezvous mechanism. The MSRP + URIs are exchanged using SDP in an offer/answer exchange via SIP. + + + + + +Campbell, et al. Standards Track [Page 5] + +RFC 4975 MSRP September 2007 + + + The exchanged SDP can also be used to negotiate MSRP extensions. + This SDP can be secured using any of the mechanisms available in SIP, + including using the sips mechanism to ensure transport security + across intermediaries and Secure/Multipurpose Internet Mail + Extensions (S/MIME) for end-to-end protection of the SDP body. SIP + can carry arbitrary URIs (including im: URIs) in the Request-URI, and + procedures are available to map im: URIs to sip: or sips: URIs. It + is expected that initial deployments of MSRP will use SIP as its + rendezvous mechanism. + +4. Protocol Overview + + MSRP is a text-based, connection-oriented protocol for exchanging + arbitrary (binary) MIME [8] 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 set up. One SIP user agent (Alice) sends + the other (Bob) a SIP invitation containing an offered session- + description that includes a session of MSRP. The receiving SIP user + agent can accept the invitation and include an answer session- + description that acknowledges the choice of media. Alice's session + description contains an MSRP URI 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.) + + Alice sends to Bob: + + INVITE sip:bob@biloxi.example.com SIP/2.0 + To: <sip:bob@biloxi.example.com> + From: <sip:alice@atlanta.example.com>;tag=786 + Call-ID: 3413an89KU + Content-Type: application/sdp + + c=IN IP4 atlanta.example.com + m=message 7654 TCP/MSRP * + a=accept-types:text/plain + a=path:msrp://atlanta.example.com:7654/jshA7weztas;tcp + + + + + + + + + + + + +Campbell, et al. Standards Track [Page 6] + +RFC 4975 MSRP September 2007 + + + Bob sends to Alice: + + SIP/2.0 200 OK + To: <sip:bob@biloxi.example.com>;tag=087js + From: <sip:alice@atlanta.example.com>;tag=786 + Call-ID: 3413an89KU + Content-Type: application/sdp + + c=IN IP4 biloxi.example.com + m=message 12763 TCP/MSRP * + a=accept-types:text/plain + a=path:msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp + + Alice sends to Bob: + + ACK sip:bob@biloxi SIP/2.0 + To: <sip:bob@biloxi.example.com>;tag=087js + From: <sip:alice@atlanta.example.com>;tag=786 + Call-ID: 3413an89KU + + Figure 1: Session Setup + + 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 a previously + sent message, or a range of bytes inside a message. 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 URI 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. Standards Track [Page 7] + +RFC 4975 MSRP September 2007 + + + MSRP a786hjs2 SEND + To-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp + From-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp + Message-ID: 87652491 + Byte-Range: 1-25/25 + Content-Type: text/plain + + Hey Bob, are you there? + -------a786hjs2$ + + MSRP a786hjs2 200 OK + To-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp + From-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp + -------a786hjs2$ + + Figure 2: Example MSRP Exchange + + Alice's request begins with the MSRP start line, which contains a + transaction identifier that is also used for request framing. Next + she includes the path of URIs to the destination in the To-Path + header field, and her own URI in the From-Path header field. In this + typical case, there is just one "hop", so there is only one URI in + each path header field. She also includes a message ID, which she + can use to correlate status reports with the original message. Next + she puts the actual content. Finally, she closes the request with an + end-line of seven hyphens, the transaction identifier, and a "$" to + indicate that 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 5.1. The Byte-Range header field identifies the + portion of the message carried in this chunk and the total size of + the message. + + Alice can also specify what type of reporting she would like in + response to her request. If Alice requests positive acknowledgments, + 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 requests containing chunks of a single message. More on + requesting types of reports and errors is described in Section 5.3. + + Alice and Bob choose their MSRP URIs in such a way that it is + difficult to guess the exact URI. Alice and Bob can reject requests + to URIs they are not expecting to service and can correlate the + specific URI with the probable sender. Alice and Bob can also use + + + +Campbell, et al. Standards Track [Page 8] + +RFC 4975 MSRP September 2007 + + + TLS [1] to provide channel security over this hop. To receive MSRP + requests over a TLS protected connection, Alice or Bob could + advertise URIs with the "msrps" scheme instead of "msrp". + + MSRP is designed with the expectation that MSRP can carry URIs for + nodes on the far side of relays. For this reason, a URI with the + "msrps" scheme makes no assertion about the security properties of + other hops, just the next hop. The user agent knows the URI for each + hop, so it can verify that each URI has the desired security + properties. + + MSRP URIs are discussed in more detail in Section 6. + + An adjacent pair of busy MSRP nodes (for example, two relays) 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 5.4. + +5. Key Concepts + +5.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. Long chunks may be interrupted in mid- + transmission to ensure fairness across shared transport connections. + To support this, MSRP uses a boundary-based framing mechanism. The + start line of an MSRP request contains a unique identifier that is + also used to indicate the end of the request. Included at the end of + the end-line, 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 + field 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. Standards Track [Page 9] + +RFC 4975 MSRP September 2007 + + + MSRP dkei38sd SEND + Message-ID: 4564dpWd + Byte-Range: 1-*/8 + Content-Type: text/plain + + abcd + -------dkei38sd+ + + MSRP dkei38ia SEND + Message-ID: 4564dpWd + Byte-Range: 5-8/8 + Content-Type: text/plain + + EFGH + -------dkei38ia$ + + Figure 3: Breaking a Message into Chunks + + This chunking mechanism allows a sender to interrupt a chunk part of + the way through sending it. The ability to interrupt messages allows + multiple sessions to share a TCP connection, and for large messages + to be sent efficiently while not blocking other messages that share + the same connection, or even the same MSRP session. Any chunk that + is larger than 2048 octets MUST be interruptible. While MSRP would + be simpler to implement if each MSRP session used its own TCP + connection, there are compelling reasons to conserve connections. + For example, the TCP peer may be a relay device that connects to many + other peers. Such a device will scale better if each peer does not + create a large number of connections. (Note that in the above + example, the initial chunk was interruptible for the sake of example, + even though its size is well below the limit for which + interruptibility would be required.) + + The chunking mechanism only applies to the SEND method, as it is the + only method used to transfer message content. + +5.2. MSRP Addressing + + MSRP entities are addressed using URIs. The MSRP URI schemes are + defined in Section 6. The syntax of the To-Path and From-Path header + fields each allows for a list of URIs. This was done to allow the + protocol to work with relays, which are defined in a separate + document, to provide a complete path to the end recipient. When two + MSRP nodes communicate directly, they need only one URI in the To- + Path list and one URI in the From-Path list. + + + + + + +Campbell, et al. Standards Track [Page 10] + +RFC 4975 MSRP September 2007 + + +5.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 Extensible Messaging and Presence Protocol (XMPP) [30] + 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 or may not be successfully processed. 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 + "delivery 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 was + successfully delivered, and the sender requested a success report. A + receiver only sends a failure REPORT if the request failed to be + delivered and the sender requested failure reports. + + This document describes the behavior of MSRP endpoints. MSRP + relays will introduce 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 Success-Report header field can have a value of "yes" or "no" and + the Failure-Report header field can have a value of "yes", "no", or + "partial". + + The combinations of reporting are needed to meet the various + scenarios of currently deployed IM systems. Success-Report might be + "no" in many public systems to reduce load, but might be "yes" in + certain enterprise systems, such as systems used for securities + trading. A Failure-Report 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 Failure-Report of + "yes" is used by many systems that wish to notify the user if the + message failed. A Failure-Report of "partial" is a way to report + errors other than timeouts. Timeout error reporting requires the + sending hop to run a timer and the receiving hop to send an + + + + + +Campbell, et al. Standards Track [Page 11] + +RFC 4975 MSRP September 2007 + + + acknowledgment to stop the timer. Some systems don't want the + overhead of doing this. "Partial" allows them to choose not to do + so, but still allows error responses to be sent in many cases. + + The term "partial" denotes that the hop-by-hop acknowledgment + mechanism that would be required with a Failure-Report value of + "yes" is not invoked. Thus, each device uses only "part" of the + set of error detection tools available to them. This allows a + compromise between no reporting of failures at all, and reporting + every possible failure. For example, with "partial", a sending + device does not have to keep transaction state around waiting for + a positive acknowledgment. But it still allows devices to report + other types of errors. The receiving device could still report a + policy violation such as an unacceptable content-type, or an ICMP + error trying to connect to a downstream device. + +5.4. MSRP Connection Model + + When an MSRP endpoint wishes to send a request to a peer identified + by an MSRP URI, it first needs a transport connection, with the + appropriate security properties, to the host specified in the URI. + If the sender already has such a connection, that is, one associated + with the same host, port, and URI scheme, then it SHOULD reuse that + connection. + + When a new MSRP session is created, the initiating endpoint MUST act + as the "active" endpoint, meaning that it is responsible for opening + the transport connection to the answerer, if a new connection is + required. However, this requirement MAY be weakened if standardized + mechanisms for negotiating the connection direction become available + and are implemented by both parties to the connection. + + Likewise, the active endpoint MUST immediately issue a SEND request. + This initial SEND request MAY have a body if the sender has content + to send, or it MAY have no body at all. + + The first SEND request serves to bind a connection to an MSRP + session from the perspective of the passive endpoint. If the + connection is not authenticated with TLS, and the active endpoint + did not send an immediate request, the passive endpoint would have + no way to determine who had connected, and would not be able to + safely send any requests towards the active party until after the + active party sends its first request. + + When an element needs to form a new connection, it looks at the URI + to decide on the type of connection (TLS, TCP, etc.) then connects to + the host indicated by the URI, following the URI resolution rules in + Section 6.2. Connections using the "msrps" scheme MUST use TLS. The + + + +Campbell, et al. Standards Track [Page 12] + +RFC 4975 MSRP September 2007 + + + SubjectAltName in the received certificate MUST match the hostname + part of the URI and the certificate MUST be valid according to RFC + 3280 [16], including having a date that is valid and being signed by + an acceptable certification authority. At this point, the device + that initiated the connection can assume that this connection is with + the correct host. + + The rules on certificate name matching and CA signing MAY be relaxed + when using TLS peer-to-peer. In this case, a mechanism to ensure + that the peer used a correct certificate MUST be used. See Section + 14.4 for details. + + If the connection used mutual TLS authentication, and the TLS client + presented a valid certificate, then the element accepting the + connection can verify the identity of the connecting device by + comparing the hostname part of the target URI in the SDP provided by + the peer device against the SubjectAltName in the client certificate. + + When mutual TLS authentication is not used, the listening device MUST + wait until it receives a request on the connection, at which time it + infers the identity of the connecting device from the associated + session description. + + When the first request arrives, its To-Path header field should + contain a URI that the listening element provided in the SDP for a + session. The element that accepted the connection looks up the URI + 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 to which this URI was given. 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 the session is already in use, 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 URI, 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 any sessions associated with the connection as also having + failed. When either endpoint notices such a failure, it MAY attempt + to re-create any such sessions. If it chooses to do so, it MUST use + a new SDP exchange, for example, in a SIP re-INVITE. If a + 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 + + + +Campbell, et al. Standards Track [Page 13] + +RFC 4975 MSRP September 2007 + + + 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. The + specific action that an endpoint takes when it receives a duplicate + message is a matter of local policy, except that it SHOULD NOT + present the duplicate messages to the user without warning of the + duplication. Note that acknowledgments as needed based on the + Failure-Report and Success-Report settings are still necessary even + for requests containing duplicate content. + + 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 non-failure + circumstances. + + If an endpoint attempts to re-create a failed session in this manner, + it MUST NOT assume that the MSRP URIs in the SDP will be the same as + the old ones. + + A connection SHOULD NOT be closed while there are sessions associated + with it. + +6. MSRP URIs + + URIs using the "msrp" and "msrps" schemes are used to identify a + session of instant messages at a particular MSRP device, as well as + to identify an MSRP relay in general. This document describes the + former usage; the latter usage is described in the MSRP relay + specification [23]. MSRP URIs that identify sessions are ephemeral; + an MSRP device will use a different MSRP URI for each distinct + session. An MSRP URI that identifies a session has no meaning + outside the scope of that session. + + An MSRP URI follows a subset of the URI syntax in Appendix A of RFC + 3986 [10], with a scheme of "msrp" or "msrps". The syntax is + described in Section 9. + + MSRP URIs are primarily expected to be generated and exchanged + between systems, and are not intended for "human consumption". + Therefore, they are encoded entirely in US-ASCII. + + The constructions for "authority", "userinfo", and "unreserved" are + detailed in RFC 3986 [10]. URIs designating MSRP over TCP MUST + include the "tcp" transport parameter. + + + + + + + +Campbell, et al. Standards Track [Page 14] + +RFC 4975 MSRP September 2007 + + + Since this document only specifies MSRP over TCP, all MSRP URIs + herein use the "tcp" transport parameter. Documents that provide + bindings on other transports should define respective parameters + for those transports. + + The MSRP URI authority field identifies a participant in a particular + MSRP session. If the authority field contains a numeric IP address, + it MUST also contain a port. The session-id part identifies a + particular session of the participant. The absence of the session-id + part indicates a reference to an MSRP host device, but does not refer + to a particular session at that device. A particular value of + session-id is only meaningful in the context of the associated + authority; thus, the authority component can be thought of as + identifying the "authority" governing a namespace for the session-id. + + A scheme of "msrps" indicates that the underlying connection MUST be + protected with TLS. + + MSRP has an IANA-registered recommended port defined in Section 15.4. + This value is not a default, as the URI negotiation process described + herein will always include explicit port numbers. However, the URIs + 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 authority component 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. A userinfo part MUST NOT contain + password information. + + The following is an example of a typical MSRP URI: + + msrp://host.example.com:8493/asfd34;tcp + +6.1. MSRP URI Comparison + + In the context of the MSRP protocol, MSRP URI comparisons MUST be + performed according to the following rules: + + 1. The scheme MUST match. Scheme comparison is case insensitive. + + 2. If the authority component contains an explicit IP address and/or + port, these are compared for address and port equivalence. + Percent-encoding normalization [10] applies; that is, if any + percent-encoded nonreserved characters exist in the authority + component, they must be decoded prior to comparison. Userinfo + + + + +Campbell, et al. Standards Track [Page 15] + +RFC 4975 MSRP September 2007 + + + parts are not considered for URI comparison. Otherwise, the + authority component is compared as a case-insensitive character + string. + + 3. If the port exists explicitly in either URI, then it MUST match + exactly. A URI with an explicit port is never equivalent to + another with no port specified. + + 4. The session-id part is compared as case sensitive. A URI without + a session-id part is never equivalent to one that includes one. + + 5. URIs with different "transport" parameters never match. Two URIs + that are identical except for transport are not equivalent. The + transport parameter is case insensitive. + + Path normalization [10] is not relevant for MSRP URIs. + +6.2. Resolving MSRP Host Device + + An MSRP host device is identified by the authority component of an + MSRP URI. + + If the authority component contains a numeric IP address and port, + they MUST be used as listed. + + If the authority component 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 URI uses + described in this document, that is, URIs exchanged in the SDP + offer and answer. The introduction of relays creates situations + where this is not the case. For example, when a user configures + her client to use a relay, it is desirable that the relay's MSRP + URI is easy to remember and communicate to humans. Often this + type of MSRP will omit the port number. Therefore, the relay + specification [23] describes 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. + + + +Campbell, et al. Standards Track [Page 16] + +RFC 4975 MSRP September 2007 + + +7. Method-Specific Behavior + +7.1. Constructing Requests + + To form a new request, the sender creates a transaction identifier + and uses this and the method name to create an MSRP request start + line. The transaction identifier MUST NOT collide with that of other + transactions that exist at the same time. Therefore, it MUST contain + at least 64 bits of randomness. + + Next, the sender places the target path in a To-Path header field, + and the sender's URI in a From-Path header field. If multiple URIs + are present in the To-Path, the leftmost is the first URI visited; + the rightmost URI is the last URI visited. The processing then + becomes method specific. Additional method-specific header fields + are added as described in the following sections. + + After any method-specific header fields are added, processing + continues to handle a body, if present. If the request has a body, + it MUST contain a Content-Type header field. It may contain other + MIME-specific header fields. The Content-Type header field MUST be + the last field in the message header section. The body MUST be + separated from the header fields with an extra CRLF. + + Non-SEND requests are not intended to carry message content, and are + therefore not interruptible. Non-SEND request bodies MUST NOT be + larger than 10240 octets. + + Although this document does not discuss any particular usage of + bodies in non-SEND requests, they may be useful in the future for + carrying security or identity information, information about a + message in progress, etc. The 10K size limit was chosen to be + large enough for most of such applications, but small enough to + avoid the fairness issues caused by sending arbitrarily large + content in non-interruptible method bodies. + + A request with no body MUST NOT include a Content-Type or any other + MIME-specific header fields. A request without a body MUST contain + an end-line after the final header field. No extra CRLF will be + present between the header section and the end-line. + + Requests with no bodies are useful when a client wishes to send + "traffic", but does not wish to send content to be rendered to the + peer user. For example, the active endpoint sends a SEND request + immediately upon establishing a connection. If it has nothing to + say at the moment, it can send a request with no body. Bodiless + requests may also be used in certain applications to keep Network + Address Translation (NAT) bindings alive, etc. + + + +Campbell, et al. Standards Track [Page 17] + +RFC 4975 MSRP September 2007 + + + Bodiless requests are distinct from requests with empty bodies. A + request with an empty body will have a Content-Type header field + value and will generally be rendered to the recipient according to + the rules for that type. + + The end-line that terminates the request MUST be composed of seven + "-" (minus sign) characters, the transaction ID as used in the start + line, and a flag character. If a body is present, the end-line MUST + be preceded by a CRLF that is not part of the body. If the chunk + represents the data that forms the end of the complete message, the + flag value MUST be a "$". If the sender is aborting an incomplete + message, and intends to send no further chunks in that message, the + flag MUST be a "#". Otherwise, the flag MUST be a "+". + + If the request contains a body, the sender MUST ensure that the end- + line (seven hyphens, the transaction identifier, and a continuation + flag) is not present in the body. If the end-line is present in the + body, the sender MUST choose a new transaction identifier that is not + present in the body, and add a CRLF if needed, and the end-line, + including the "$", "#", or "+" character. + + Some implementations may choose to scan for the closing sequence as + they send the body, and if it is encountered, simply interrupt the + chunk at that point and start a new transaction with a different + transaction identifier to carry the rest of the body. Other + implementations may choose to scan the data and ensure that the body + does not contain the transaction identifier before they start sending + the transaction. + + Once a request is ready for delivery, the sender follows the + connection management (Section 5.4) rules to forward the request over + an existing open connection or create a new connection. + +7.1.1. Sending SEND Requests + + When an endpoint has a message to deliver, it first generates a new + Message-ID. The value MUST be highly unlikely to be repeated by + another endpoint instance, or by the same instance in the future. If + necessary, the endpoint breaks the message into chunks. It then + generates a SEND request for each chunk, following the procedures for + constructing requests (Section 7.1). + + The Message-ID header field provides a unique message identifier + that refers to a particular version of a particular message. The + term "Message" in this context refers to a unit of content that + the sender wishes to convey to the recipient. While such a + message may be broken into chunks, the Message-ID refers to the + entire message, not a chunk of the message. + + + +Campbell, et al. Standards Track [Page 18] + +RFC 4975 MSRP September 2007 + + + The uniqueness of the message identifier is ensured by the host + that generates it. This message identifier is intended to be + machine readable and not necessarily meaningful to humans. A + message identifier pertains to exactly one version of a particular + message; subsequent revisions to the message each receive new + message identifiers. Endpoints can ensure sufficient uniqueness + in any number of ways, the selection of which is an implementation + choice. For example, an endpoint could concatenate an instance + identifier such as a MAC address, its idea of the number of + seconds since the epoch, a process ID, and a monotonically + increasing 16-bit integer, all base-64 encoded. Alternately, an + endpoint without an on-board clock could simply use a 64-bit + random number. + + Each chunk of a message MUST contain a Message-ID header field + containing the Message-ID. If the sender wishes non-default status + reporting, it MUST insert a Failure-Report and/or Success-Report + header field with an appropriate value. All chunks of the same + message MUST use the same Failure-Report and Success-Report values in + their SEND requests. + + If success reports are requested, i.e., the value of the Success- + Report header field is "yes", the sending device MAY wish to run a + timer of some value that makes sense for its 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 + inform the user. + + If the value of "Failure-Report" 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 + transaction is sent, or submitted to the operating system for + sending, 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 it receives a non-recoverable error response to the + transaction. Regardless of the Failure-Report value, there is no + requirement to wait for a response prior to sending the next request. + + The treatment of timers for success reports and failure reports is + intentionally inconsistent. An explicit timeout value makes sense + for failure reports since such reports will usually refer to a + message "chunk" that is acknowledged on a hop-by-hop basis. This + + + + + +Campbell, et al. Standards Track [Page 19] + +RFC 4975 MSRP September 2007 + + + is not the case for success reports, which are end-to-end and may + refer to the entire message content, which can be arbitrarily + large. + + If no Success-Report header field is present in a SEND request, it + MUST be treated the same as a Success-Report header field with a + value of "no". If no Failure-Report header field is present, it MUST + be treated the same as a Failure-Report header field with a value of + "yes". If an MSRP endpoint receives a REPORT for a Message-ID it + does not recognize, it SHOULD silently ignore the REPORT. + + The Byte-Range header field value contains a starting value (range- + start) followed by a "-", an ending value (range-end) followed by a + "/", and finally the total length. The first octet in the message + has a position of one, rather than a zero. + + 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 (for the first chunk this field will have a value of one). + 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 field MAY contain a "*" if the total size of the message is not + known in advance. The sender MUST send all chunks in Byte-Range + order. (However, the receiver cannot assume that the requests will + be delivered in order, as intervening relays may have changed the + order.) + + There are some circumstances where an endpoint may choose to send an + empty SEND request. For the sake of consistency, a Byte-Range header + field referring to nonexistent or zero-length content MUST still have + a range-start value of 1. For example, "1-0/0". + + To ensure fairness over a connection, senders MUST NOT send chunks + with a body larger than 2048 octets unless they are prepared to + interrupt them (meaning that any chunk with a body of greater than + 2048 octets will have a "*" character in the range-end field). 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) only 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 zero octets to the maximum number of octets they can + + + +Campbell, et al. Standards Track [Page 20] + +RFC 4975 MSRP September 2007 + + + 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. + + 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 end- + line to end the chunk. It can then be resumed in a another chunk + with the same Message-ID and a Byte-Range header field range start + field containing the position of the first byte after the + interruption occurred. + + SEND requests larger than 2048 octets MUST be interrupted if the + sender needs to send pending responses or REPORT requests. If + multiple SEND requests from different sessions are concurrently being + sent over the same connection, 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 with which it was sent. An + intervening relay could possibly break SEND requests into smaller + chunks, or aggregate multiple chunks into larger ones. + + The default disposition of messages is to be rendered to the user. + If the sender wants a different disposition, it MAY insert a Content- + Disposition [9] header field. Values MAY include any from RFC 2183 + [9] or the IANA registry it defines. Since MSRP can carry unencoded + binary payloads, transfer encoding is always "binary", and transfer- + encoding parameters MUST NOT be present. + +7.1.2. Sending REPORT Requests + + REPORT requests are similar to SEND requests, except that report + requests MUST NOT include Success-Report or Failure-Report header + fields, and MUST contain a Status header field. REPORT requests MUST + contain the Message-ID header field from the original SEND request. + + If an MSRP element receives a REPORT for a Message-ID it does not + recognize, it SHOULD silently ignore the REPORT. + + An MSRP endpoint MUST be able to generate success REPORT requests. + + REPORT requests will normally not include a body, as the REPORT + request header fields can carry sufficient information in most cases. + However, REPORT requests MAY include a body containing additional + information about the status of the associated SEND request. Such a + + + +Campbell, et al. Standards Track [Page 21] + +RFC 4975 MSRP September 2007 + + + body is informational only, and the sender of the REPORT request + SHOULD NOT assume that the recipient pays any attention to the body. + REPORT requests are not interruptible. + + Success-Report and Failure-Report header fields MUST NOT be present + in REPORT requests. MSRP nodes MUST NOT send REPORT requests in + response to REPORT requests. MSRP nodes MUST NOT send MSRP responses + to REPORT requests. + + 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 for a session that is no longer valid. + +7.1.3. Generating Success Reports + + When an endpoint receives a message in one or more chunks that + contain a Success-Report value of "yes", it MUST send a success + report or reports covering all bytes that are received successfully. + The success reports are sent in the form of REPORT requests, + following the normal procedures (Section 7.1), with a few additional + requirements. + + The receiver MAY wait until it receives the last chunk of a message, + and send a success report that covers the complete message. + Alternately, it MAY generate incremental success REPORTs as the + chunks are received. These can be sent periodically and cover all + the bytes that have been received so far, or they can be sent after a + chunk arrives and cover just the part from that chunk. + + It is helpful to think of a success REPORT as reporting on a + particular range of bytes, rather than on a particular chunk sent + by a client. The sending client cannot depend on the Byte-Range + header field in a given success report matching that of a + particular SEND request. For example, an intervening MSRP relay + may break chunks into smaller chunks, or aggregate multiple chunks + into larger ones. A side effect of this is, even if no relay is + used, the receiving client may report on byte ranges that do not + exactly match those in the original chunks sent by the sender. It + can wait until all bytes in a message are received and report on + the whole, it can report as it receives each chunk, or it can + report on any other received range. Reporting on ranges smaller + than the entire message contents allows certain improved user + experiences for the sender. For example, a sending client could + display incremental status information showing which ranges of + bytes have been acknowledged by the receiver. However, the choice + on whether to report incrementally is entirely up to the receiving + client. There is no mechanism for the sender to assert its desire + to receive incremental reports or not. Since the presence of a + + + +Campbell, et al. Standards Track [Page 22] + +RFC 4975 MSRP September 2007 + + + relay can cause the receiver to see a very different chunk + allocation than the sender, such a mechanism would be of + questionable value. + + When generating a REPORT request, the endpoint inserts a To-Path + header field containing the From-Path value from the original + request, and a From-Path header field containing the URI identifying + itself in the session. The endpoint then inserts a Status header + field with a namespace of "000", a status-code of "200", and an + implementation-defined comment phrase. It also inserts a Message-ID + header field containing the value from the original request. + + The namespace field denotes the context of the status-code field. + The namespace value of "000" means the status-code should be + interpreted in the same way as the matching MSRP transaction + response code. If a future specification uses the status-code + field for some other purpose, it MUST define a new namespace field + value. + + The endpoint MUST NOT send a success report for a SEND request that + either contained no Success-Report header field or contained such a + field with a value of "no". That is, if no Success-Report header + field is present, it is treated identically to one with a value of + "no". + +7.1.4. Generating Failure Reports + + If an MSRP endpoint receives a SEND request that it cannot process + for some reason, and the Failure-Report header field either was not + present in the original request or had a value of "yes", it SHOULD + simply include the appropriate error code in the transaction + response. However, there may be situations where the error cannot be + determined quickly, such as when the endpoint is a gateway that waits + for a downstream network to indicate an error. In this situation, it + MAY 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 Failure-Report header + field value of "no", then it MUST NOT send a failure REPORT request, + and MUST NOT send a transaction response. If the value is "partial", + it MUST NOT send a 200 transaction response to the request, but + SHOULD send an appropriate non-200 class response if a failure + occurs. + + As stated above, if no Failure-Report header field is present, it + MUST be treated the same as a Failure-Report header field with a + value of "yes". + + + + +Campbell, et al. Standards Track [Page 23] + +RFC 4975 MSRP September 2007 + + + Construction of failure REPORT requests is identical to that for + success REPORT requests, except the Status header field code field + MUST contain the appropriate error code. Any error response code + defined in this specification MAY also be used in failure reports. + + If a failure REPORT request is sent in response to a SEND request + that contained a chunk, it MUST include a Byte-Range header field + 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. + + 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 [23]. We + expect failure reports to be more commonly generated by relays + than by endpoints. + +7.2. Constructing Responses + + If an MSRP endpoint receives a request that either contains a + Failure-Report header field value of "yes" or does not contain a + Failure-Report header field at all, it MUST immediately generate a + response. Likewise, if an MSRP endpoint receives a request that + contains a Failure-Report header field 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 the appropriate response code and optionally a + comment. 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 + header field is formed by copying the first (leftmost) URI in the + From-Path header field of the request. (Responses to SEND requests + are returned only to the previous hop.) For responses to all other + request methods, the To-Path header field contains the full path back + to the original sender. This full path is generated by copying the + list of URIs from the From-Path of the original request 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 + URI that identifies it in the context of the session, followed by the + end-line after the last header field. Since a response is never + + + +Campbell, et al. Standards Track [Page 24] + +RFC 4975 MSRP September 2007 + + + chunked, the continuation flag in the end-line will always contain a + dollar sign ("$"). The response MUST be transmitted back on the same + connection on which the original request arrived. + +7.3. Receiving Requests + + The receiving endpoint MUST first check the URI 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 URI, which + MUST map to an existing session that is associated with the + connection on which the request arrived. If this is not true, then + the receiver MUST generate a 481 error and ignore the request. Note + that if the Failure-Report header field had a value of "no", then no + error report would be sent. + + Further request processing by the receiver is method specific. + +7.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 field, 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. The + receiver 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 SHOULD 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 noting that the chunk that has a termination character of + "$" defines the total length of the message. + + It is technically illegal for the sender to prematurely interrupt + a request that had anything other than "*" in the last-byte + position of the Byte-Range header field. But having the receiver + calculate a chunk length based on actual content adds resilience + in the face of sender errors. Since this should never happen with + compliant senders, this only has a "SHOULD" strength. + + Receivers MUST not assume that 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 chunk + data is received that overlaps already received data for the same + + + +Campbell, et al. Standards Track [Page 25] + +RFC 4975 MSRP September 2007 + + + message, the last chunk received SHOULD take precedence (even though + this may not have been the last chunk transmitted). For example, if + bytes 1 to 100 were 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. + + There are situations in which the receiver may not be able to give + precedence to the last chunk received when chunks overlap. For + example, the recipient might incrementally render chunks as they + arrive. If a new chunk arrives that overlaps with a previously + rendered chunk, it would be too late to "take back" any + conflicting data from the first chunk. Therefore, the requirement + to give precedence to the most recent chunk is specified at a + "SHOULD" strength. This requirement is not intended to disallow + applications where this behavior does not make sense. + + The seven "-" in the end-line are used so that the receiver can + search for the value "----", 32 bits at a time to find the probable + location of the end-line. 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 header + fields of the request, but also allows for the interruption of + messages. + + What is done with the body is outside the scope of MSRP and largely + determined by the MIME Content-Type and Content-Disposition. 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 media-type, and the Failure-Report value is not "no", + the receiver MUST generate a response with a status code of 415. All + MSRP endpoints MUST be able to receive the multipart/mixed [15] and + multipart/alternative [15] media-types. + + If the Success-Report header field was set to "yes", the receiver + must construct and send one or more success reports, as described in + Section 7.1.3. + + + + + + + + + + +Campbell, et al. Standards Track [Page 26] + +RFC 4975 MSRP September 2007 + + +7.3.2. Receiving REPORT Requests + + When an endpoint receives a REPORT request, it correlates the report + 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 + field with a namespace field of "000" MUST interpret the report in + exactly the same way it would interpret an MSRP transaction response + with a response code matching the status-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, by including the "#" character in the continuation field of + the end-line. + + 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. + + When an endpoint that sent a SEND request receives a failure REPORT + indicating that a particular byte range was not received, it MUST + treat the session as failed. If it wishes to recover, it MUST first + re-negotiate the URIs at the signaling level then resend that range + of bytes of the message on the resulting new session. + + MSRP nodes MUST NOT send MSRP REPORT requests in response to other + REPORT requests. + +8. Using MSRP with SIP and SDP + + MSRP sessions will typically be initiated using the Session + Description Protocol (SDP) [2] via the SIP offer/answer mechanism + [3]. + + This document defines a handful of new SDP parameters to set up MSRP + sessions. These are detailed below and in the IANA Considerations + section. + + An MSRP media-line (that is, a media-line proposing MSRP) in the + session description is accompanied by a mandatory "path" attribute. + This attribute contains a space-separated list of URIs to be visited + + + +Campbell, et al. Standards Track [Page 27] + +RFC 4975 MSRP September 2007 + + + to contact the user agent advertising this session description. If + more than one URI is present, the leftmost URI is the first URI to be + visited to reach the target resource. (The path list can contain + multiple URIs to allow for the deployment of gateways or relays in + the future.) MSRP implementations that can accept incoming + connections without the need for relays will typically only provide a + single URI here. + + An MSRP media line is also accompanied by an "accept-types" + attribute, and optionally an "accept-wrapped-types" attribute. These + attributes are used to specify the media-types that are acceptable to + the endpoint. + +8.1. SDP Connection and Media-Lines + + An SDP connection-line takes the following format: + + c=<network type> <address type> <connection address> + + Figure 4: Standard SDP Connection Line + + The network type and address type fields are used as normal for SDP. + The connection address field MUST be set to the IP address or fully + qualified domain name from the MSRP URI identifying the endpoint in + its path attribute. + + The general format of an SDP media-line is: + + m=<media> <port> <protocol> <format list> + + Figure 5: Standard SDP Media Line + + An offered or accepted media-line for MSRP over TCP MUST include a + protocol field value of "TCP/MSRP", or "TCP/TLS/MSRP" for TLS. The + media field value MUST be "message". The format list field MUST be + set to "*". + + The port field value MUST match the port value used in the endpoint's + MSRP URI in the path attribute, except that, as described in [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) in the + response. Since MSRP allows multiple sessions to share the same TCP + connection, multiple m-lines in a single SDP document may share the + same port field value; MSRP devices MUST NOT assume any particular + relationship between m-lines on the sole basis that they have + matching port field values. + + + + + +Campbell, et al. Standards Track [Page 28] + +RFC 4975 MSRP September 2007 + + + MSRP devices do not use the c-line address field, or the m-line + port and format list fields to determine where to connect. + Rather, they use the attributes defined in this specification. + The connection information is copied to the c-line and m-line for + purposes of backwards compatibility with conventional SDP usages. + While MSRP could theoretically carry any media-type, "message" is + appropriate. + +8.2. URI Negotiations + + Each endpoint in an MSRP session is identified by a URI. These URIs + are negotiated in the SDP exchange. Each SDP offer or answer that + proposes MSRP MUST contain a "path" attribute containing one or more + MSRP URIs. The path attribute is used in an SDP a-line, and has the + following syntax: + + path = path-label ":" path-list + path-label = "path" + path-list= MSRP-URI *(SP MSRP-URI) + + Figure 6: Path Attribute + + where MSRP-URI is an "msrp" or "msrps" URI as defined in Section 6. + MSRP URIs included in an SDP offer or answer MUST include explicit + port numbers. + + An MSRP device uses the URI 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 URI to represent itself and + sends that URI to its peer in the SDP document. Each peer stores the + path value received from the other 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 URI, then the + target URI 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 URI. The target path is the entire path attribute + value received from the peer. + + The following example shows an SDP offer with a session URI of + "msrp://alice.example.com:7394/2s93i9ek2a;tcp" + + + + + + + + + +Campbell, et al. Standards Track [Page 29] + +RFC 4975 MSRP September 2007 + + + v=0 + o=alice 2890844526 2890844527 IN IP4 alice.example.com + s= - + c=IN IP4 alice.example.com + t=0 0 + m=message 7394 TCP/MSRP * + a=accept-types:text/plain + a=path:msrp://alice.example.com:7394/2s93i9ek2a;tcp + + Figure 7: Example SDP with Path Attribute + + 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. + +8.3. Path Attributes with Multiple URIs + + As mentioned previously, this document describes MSRP for peer-to- + peer scenarios, that is, when no relays are used. The use of relays + is described in a separate document [23]. 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 URI for each device in the relay chain into the SDP path + attribute. The final entry will point to the endpoint itself. The + other entries will indicate each proposed relay, in order. The first + entry will point to the first relay in the chain from the perspective + of the peer, that is, the relay to which the peer device, or a relay + operating 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 URI into the path + attribute. This URI represents both the endpoint for the session and + the connection point. + + Even though endpoints that implement only this specification will + never introduce a relay, they need to be able to interoperate with + other endpoints that do use relays. Therefore, they MUST be prepared + to receive more than one URI in the SDP path attribute. When an + endpoint receives more than one URI in a path attribute, only the + + + + + +Campbell, et al. Standards Track [Page 30] + +RFC 4975 MSRP September 2007 + + + 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 URI in a path attribute, the final + URI in the path attribute (the peer URI) identifies the session, and + MUST not duplicate the URI of any other session in which the endpoint + is currently participating. Uniqueness requirements for other + entries in the path attribute are out of scope for this document. + +8.4. 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 or the SIP UPDATE [24] request. 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 use the same o-line as in the previous exchange. + +8.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 Connection-Oriented Media (COMEDIA) [26] work + done by 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. The + party that sent the original offer is responsible for connecting to + its peer. + + + + +Campbell, et al. Standards Track [Page 31] + +RFC 4975 MSRP September 2007 + + +8.6. Content Type Negotiation + + An SDP media-line proposing MSRP MUST be accompanied by an accept- + types attribute. + + An entry of "*" 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. This feature is needed as, otherwise, the list of formats for + rich IM devices may be prohibitively large. + + This specification requires the support of certain data formats. + Mandatory formats MUST be signaled like any other, either explicitly + or by the use of a "*". + + 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 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 media-type that + can only be used if wrapped inside a listed container type. + + Endpoints MAY specify media-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 container types listed in the + accept-types attribute. 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 both used 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 media-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. + + + +Campbell, et al. Standards Track [Page 32] + +RFC 4975 MSRP September 2007 + + + 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 + Common Presence and Instant Messaging (CPIM) [12] 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. + + If the recipient of an offer does not understand any of the payload + types indicated in the offered SDP, it SHOULD indicate that using the + appropriate mechanism of the rendezvous protocol. For example, in + SIP, it SHOULD return a SIP 488 response. + + An MSRP endpoint MUST NOT send content of a type not signaled by the + peer in either an accept-types or an accept-wrapped-types attribute. + Furthermore, it MUST NOT send a top-level (i.e., not wrapped) MIME + document of a type not signaled in the accept-types attribute. In + either case, the signaling could be explicit, or implicit through the + use of the "*" character. + + An endpoint MAY indicate the maximum size message it wishes to + receive using the max-size a-line attribute. Max-size refers to the + complete message in octets, not the size of any one chunk. Senders + SHOULD NOT exceed the max-size limit for any message sent in the + resulting session. However, the receiver should consider max-size + value as a hint. + + Media format entries may include parameters. The interpretation of + such parameters varies between media-types. For the purposes of + media-type negotiation, a format-entry with one or more parameters is + assumed to match the same format-entry with no parameters. + + + + + + + + + + + + + + + + + + +Campbell, et al. Standards Track [Page 33] + +RFC 4975 MSRP September 2007 + + + The formal syntax for these attributes is as follows: + + 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 = ( ( (type "/" subtype) + / (type "/" "*") ) + *( ";" type-param ) ) + / ("*") + + type = token + subtype = token + type-param = parm-attribute "=" parm-value + parm-attribute = token + parm-value = token / quoted-string + + max-size = max-size-label ":" max-size-value + max-size-label = "max-size" + max-size-value = 1*(DIGIT) ; max size in octets + + Figure 8: Attribute Syntax + +8.7. Example SDP Exchange + + Endpoint A wishes to invite Endpoint B to an 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 7394 TCP/MSRP * + a=accept-types:message/cpim text/plain text/html + a=path:msrp://alice.example.com:7394/2s93i93idj;tcp + + Figure 9: SDP from Endpoint A + + + + + + + + + + + + +Campbell, et al. Standards Track [Page 34] + +RFC 4975 MSRP September 2007 + + + B responds with its own URI: + + v=0 + o=userb 2890844530 2890844532 IN IP4 bob.example.com + s= - + c=IN IP4 bob.example.com + t=0 0 + m=message 8493 TCP/MSRP * + a=accept-types:message/cpim text/plain + a=path:msrp://bob.example.com:8493/si438dsaodes;tcp + + Figure 10: SDP from Endpoint B + +8.8. 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. + + This guideline may not make sense for all situations, such as for + mixed-media applications, where both MSRP and audio sessions are + offered in the same INVITE. In general, good application design + should take precedence. + + SIP INVITE requests may be forked by a SIP proxy, resulting in more + than one endpoint receiving the same INVITE. SIP early media [29] + techniques can be used to establish a preliminary session with each + endpoint so the initial message(s) are displayed on each endpoint, + and canceling the INVITE transaction for any endpoints that do not + send MSRP traffic after some period of time, so that they cease + receiving MSRP traffic from the inviter. + +8.9. SDP Direction Attribute and MSRP + + SDP defines a number of attributes that modify the direction of media + flows. These are the "sendonly", "recvonly", "inactive", and + "sendrecv" attributes. + + + + + +Campbell, et al. Standards Track [Page 35] + +RFC 4975 MSRP September 2007 + + + If a "sendonly" or "recvonly" attribute modifies an MSRP media + description line, the attribute indicates the direction of MSRP SEND + requests that contain regular message payloads. Unless otherwise + specified, these attributes do not affect the direction of other + types of requests, such as REPORT. SEND requests that contain some + kind of control or reporting protocol rather than regular message + payload (e.g., Instant Message Delivery Notification (IMDN) reports) + should be generated according to the protocol rules as if no + direction attribute were present. + +9. Formal Syntax + + MSRP is a text protocol that uses the UTF-8 [14] transformation + format. + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) as described in RFC 4234 [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 + resp-start = pMSRP SP transact-id SP status-code [SP comment] CRLF + comment = utf8text + + pMSRP = %x4D.53.52.50 ; MSRP in caps + transact-id = ident + method = mSEND / mREPORT / other-method + mSEND = %x53.45.4e.44 ; SEND in caps + mREPORT = %x52.45.50.4f.52.54; REPORT in caps + + other-method = 1*UPALPHA + status-code = 3DIGIT ; any code defined in this document + ; or an extension document + + MSRP-URI = msrp-scheme "://" authority + ["/" session-id] ";" transport *( ";" URI-parameter) + ; authority as defined in RFC3986 + + msrp-scheme = "msrp" / "msrps" + session-id = 1*( unreserved / "+" / "=" / "/" ) + ; unreserved as defined in RFC3986 + transport = "tcp" / 1*ALPHANUM + URI-parameter = token ["=" token] + + headers = To-Path CRLF From-Path CRLF 1*( header CRLF ) + + + + +Campbell, et al. Standards Track [Page 36] + +RFC 4975 MSRP September 2007 + + + header = Message-ID + / Success-Report + / Failure-Report + / Byte-Range + / Status + / ext-header + + To-Path = "To-Path:" SP MSRP-URI *( SP MSRP-URI ) + From-Path = "From-Path:" SP MSRP-URI *( SP MSRP-URI ) + Message-ID = "Message-ID:" SP ident + Success-Report = "Success-Report:" SP ("yes" / "no" ) + Failure-Report = "Failure-Report:" 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 status-code [SP comment] + namespace = 3(DIGIT); "000" for all codes defined in this document. + + 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 ] + pname = token + pval = token / quoted-string + + token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E + / %x30-39 / %x41-5A / %x5E-7E) + ; token is compared case-insensitive + + quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE + qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E + / UTF8-NONASCII + qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE) + BACKSLASH = "\" + UPALPHA = %x41-5A + ALPHANUM = ALPHA / DIGIT + + + + + +Campbell, et al. Standards Track [Page 37] + +RFC 4975 MSRP September 2007 + + + 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 + ; header fields 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 = *(HTAB / %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 + + Figure 11: MSRP ABNF + +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 field in REPORT requests. + +10.1. 200 + + The 200 response code indicates a successful transaction. + +10.2. 400 + + A 400 response indicates that a request was unintelligible. The + sender may retry the request after correcting the error. + +10.3. 403 + + A 403 response indicates that the attempted action is not allowed. + The sender should not try the request again. + + + +Campbell, et al. Standards Track [Page 38] + +RFC 4975 MSRP September 2007 + + +10.4. 408 + + A 408 response indicates that a downstream transaction did not + complete in the allotted time. It is never sent by any elements + described in this specification. However, 408 is used in the MSRP + relay extension; therefore, MSRP endpoints may receive it. An + endpoint MUST treat a 408 response in the same manner as it would + treat a local timeout. + +10.5. 413 + + A 413 response indicates that the receiver wishes the sender to stop + sending the particular message. Typically, a 413 is sent in response + to a chunk of an undesired message. + + If a message sender receives a 413 in a response, or in a REPORT + request, it MUST NOT send any further chunks in the message, that is, + any further chunks with the same Message-ID value. If the sender + receives the 413 while in the process of sending a chunk, and the + chunk is interruptible, the sender MUST interrupt it. + +10.6. 415 + + A 415 response indicates that the SEND request contained a media type + that is not understood by the receiver. The sender should not send + any further messages with the same content-type for the duration of + the session. + +10.7. 423 + + A 423 response indicates that one of the requested parameters is out + of bounds. It is used by the relay extensions to this document. + +10.8. 481 + + A 481 response indicates that the indicated session does not exist. + The sender should terminate the session. + +10.9. 501 + + A 501 response indicates that the recipient does not understand the + request method. + + The 501 response code exists to allow some degree of method + extensibility. It is not intended as a license to ignore methods + defined in this document; rather, it is a mechanism to report lack + of support of extension methods. + + + + +Campbell, et al. Standards Track [Page 39] + +RFC 4975 MSRP September 2007 + + +10.10. 506 + + A 506 response indicates that a request arrived on a session that is + already bound to another network connection. The sender should cease + sending messages for that session on this 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 that the offerer is + sip:alice@example.com and the answerer is sip:bob@example.com. + + Alice Bob + | | + | | + |(1) (SIP) INVITE | + |----------------------->| + |(2) (SIP) 200 OK | + |<-----------------------| + |(3) (SIP) ACK | + |----------------------->| + |(4) (MSRP) SEND | + |----------------------->| + |(5) (MSRP) 200 OK | + |<-----------------------| + |(6) (MSRP) SEND | + |<-----------------------| + |(7) (MSRP) 200 OK | + |----------------------->| + |(8) (SIP) BYE | + |----------------------->| + |(9) (SIP) 200 OK | + |<-----------------------| + | | + | | + + Figure 12: Basic IM Session Example + + + + + + + + + + +Campbell, et al. Standards Track [Page 40] + +RFC 4975 MSRP September 2007 + + + 1. Alice constructs a local URI of + msrp://alicepc.example.com:7777/iau39soe2843z;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 7777 TCP/MSRP * + a=accept-types:text/plain + a=path:msrp://alicepc.example.com:7777/iau39soe2843z;tcp + + 2. Bob listens on port 8888, and sends the following response: + + 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 8888 TCP/MSRP * + a=accept-types:text/plain + a=path:msrp://bob.example.com:8888/9di4eae923wzd;tcp + + 3. Alice->Bob (SIP): ACK sip:bob@example.com + + 4. (Alice opens connection to Bob.) Alice->Bob (MSRP): + + MSRP d93kswow SEND + To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp + From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp + Message-ID: 12339sdqwer + Byte-Range: 1-16/16 + Content-Type: text/plain + + Hi, I'm Alice! + -------d93kswow$ + + 5. Bob->Alice (MSRP): + + MSRP d93kswow 200 OK + To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp + From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp + -------d93kswow$ + + + + +Campbell, et al. Standards Track [Page 41] + +RFC 4975 MSRP September 2007 + + + 6. Bob->Alice (MSRP): + + MSRP dkei38sd SEND + To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp + From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp + Message-ID: 456s9wlk3 + Byte-Range: 1-21/21 + Content-Type: text/plain + + Hi, Alice! I'm Bob! + -------dkei38sd$ + + 7. Alice->Bob (MSRP): + + MSRP dkei38sd 200 OK + To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp + From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp + -------dkei38sd$ + + 8. Alice->Bob (SIP): BYE sip:bob@example.com + + Alice invalidates local session state. + + 9. Bob invalidates local state for the session. + + Bob->Alice (SIP): 200 OK + +11.2. Message with XHTML Content + + MSRP dsdfoe38sd SEND + To-Path: msrp://alice.example.com:7777/iau39soe2843z;tcp + From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp + Message-ID: 456so39s + Byte-Range: 1-374/374 + Content-Type: application/xhtml+xml + + + + + + + + + + + + + + + + +Campbell, et al. Standards Track [Page 42] + +RFC 4975 MSRP September 2007 + + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE html + PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "_http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd_"> + <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> + <head> + <title>FY2005 Results</title> + </head> + <body> + <p>See the results at <a + href="http://example.org/">example.org</a>.</p> + </body> + </html> + -------dsdfoe38sd$ + + Figure 13: Example Message with XHTML + +11.3. Chunked Message + + For an example of a chunked message, see the example in Section 5.1. + +11.4. Chunked Message with Message/CPIM Payload + + This example shows a chunked message containing a CPIM message that + wraps a text/plain payload. It is worth noting that MSRP considers + the complete CPIM message before chunking the message; thus, the CPIM + headers are included in only the first chunk. The MSRP Content-Type + and Byte-Range headers, present in both chunks, refer to the whole + CPIM message. + + MSRP d93kswow SEND + To-Path: msrp://bobpc.example.com:8888/9di4eae923wzd;tcp + From-Path: msrp://alicepc.example.com:7654/iau39soe2843z;tcp + Message-ID: 12339sdqwer + Byte-Range: 1-137/148 + Content-Type: message/cpim + + To: Bob <sip:bob@example.com> + From: Alice <sip:alice@example.com> + DateTime: 2006-05-15T15:02:31-03:00 + Content-Type: text/plain + + ABCD + -------d93kswow+ + + Figure 14: First Chunk + + + + + +Campbell, et al. Standards Track [Page 43] + +RFC 4975 MSRP September 2007 + + + Alice sends the second and last chunk. + + MSRP op2nc9a SEND + To-Path: msrp://bobpc.example.com:8888/9di4eae923wzd;tcp + From-Path: msrp://alicepc.example.com:7654/iau39soe2843z;tcp + Message-ID: 12339sdqwer + Byte-Range: 138-148/148 + Content-Type: message/cpim + + 1234567890 + -------op2nc9a$ + + Figure 15: Second Chunk + +11.5. System Message + + Sysadmin->Alice (MSRP): + + MSRP d93kswow SEND + To-Path: msrp://alicepc.example.com:8888/9di4eae923wzd;tcp + From-Path: msrp://example.com:7777/iau39soe2843z;tcp + Message-ID: 12339sdqwer + Byte-Range: 1-38/38 + Failure-Report: no + Success-Report: no + Content-Type: text/plain + + This conference will end in 5 minutes + -------d93kswow$ + +11.6. Positive Report + + Alice->Bob (MSRP): + + MSRP d93kswow SEND + To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp + From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp + Message-ID: 12339sdqwer + Byte-Range: 1-106/106 + Success-Report: yes + Failure-Report: no + Content-Type: text/html + + + + + + + + + +Campbell, et al. Standards Track [Page 44] + +RFC 4975 MSRP September 2007 + + + <html><body> + <p>Here is that important link... + <a href="http://www.example.com/foobar">foobar</a> + </p> + </body></html> + -------d93kswow$ + + Figure 16: Initial SEND Request + + Bob->Alice (MSRP): + + MSRP dkei38sd REPORT + To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp + From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp + Message-ID: 12339sdqwer + Byte-Range: 1-106/106 + Status: 000 200 OK + -------dkei38sd$ + + Figure 17: Success Report + +11.7. 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 it is desirable to use + them only if another IM client is not available. + + Using SIP makes rendezvous decisions explicit, deterministic, and + very flexible. In contrast, "page-mode" IM systems use implicit + implementation-specific decisions that IM clients cannot influence. + 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 [31]. 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). + + + + + +Campbell, et al. Standards Track [Page 45] + +RFC 4975 MSRP September 2007 + + + 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 each of those systems, both of which set up + early sessions of MSRP with Romeo's client. The client automatically + sends the message over MSRP to the two MSRP 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 + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Campbell, et al. Standards Track [Page 46] + +RFC 4975 MSRP September 2007 + + + 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================================>| + | | | | | | + | Hi Romeo, Juliet is | + | with her father now | + | can I take a message?| + | | + | Tell her to go to confession tomorrow.... | + + Figure 18: Forking Example + + + +Campbell, et al. Standards Track [Page 47] + +RFC 4975 MSRP September 2007 + + +12. Extensibility + + MSRP was designed to be only minimally extensible. New MSRP methods, + header fields, and status codes can be defined in standards-track + RFCs. MSRP does not contain a version number or any negotiation + mechanism to require or discover new features. If an extension is + specified in the future that requires negotiation, the specification + will need to describe how the extension is to be negotiated in the + encapsulating signaling protocol. If a non-interoperable update or + extension occurs in the future, it will be treated as a new protocol, + and MUST describe how its use will be signaled. + + In order to allow extension header fields without breaking + interoperability, if an MSRP device receives a request or response + containing a header field that it does not understand, it MUST ignore + the header field and process the request or response as if the header + field was not present. If an MSRP device receives a request with an + unknown method, it MUST return a 501 response. + + MSRP was designed to use lists of URIs instead of a single URI in the + To-Path and From-Path header fields in anticipation of relay or + gateway functionality being added. In addition, "msrp" and "msrps" + URIs can contain parameters that are extensible. + +13. CPIM Compatibility + + MSRP sessions may go to a gateway to other Common Profile for Instant + Messaging (CPIM) [27] compatible protocols. If this occurs, the + gateway MUST maintain session state, and MUST translate between the + MSRP session semantics and CPIM semantics, which 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" [12] 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[7] features of that format. + + If a message is to be wrapped in a message/cpim envelope, the + wrapping MUST be done prior to breaking the message into chunks, if + needed. + + + + + + + + +Campbell, et al. Standards Track [Page 48] + +RFC 4975 MSRP September 2007 + + + All MSRP endpoints MUST recognize the From, To, DateTime, and Require + header fields as defined in RFC 3862. Such applications SHOULD + recognize the CC header field, and MAY recognize the Subject header + field. Any MSRP application that recognizes any message/cpim header + field MUST understand the NS (name space) header field. + + All message/cpim body parts sent by an MSRP endpoint MUST include the + From and To header fields. If the message/cpim body part is + protected using S/MIME, then it MUST also include the DateTime header + field. + + The NS, To, and CC header fields may occur multiple times. Other + header fields defined in RFC 3862 MUST NOT occur more than once in a + given message/cpim body part in an MSRP message. The Require header + field MAY include multiple values. The NS header field MAY occur + zero or more times, depending on how many name spaces are being + referenced. + + Extension header fields MAY occur more than once, depending on the + definition of such header fields. + + Using message/cpim envelopes is also useful if an MSRP device + wishes to send a message on behalf of some other identity. The + device may add a message/cpim envelope with the appropriate From + header field value. + +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. IM systems need + to provide the properties of integrity and confidentiality for the + exchanged information, and the knowledge that you are communicating + with the correct party, and they need to allow the possibility of + anonymous communication. MSRP pushes many of the hard problems to + SIP when SIP sets up the session, but some of the problems remain. + Spam and Denial of Service (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 that the connected + host is the host that it meant to connect to and that the connection + has not been hijacked. + + + + + + +Campbell, et al. Standards Track [Page 49] + +RFC 4975 MSRP September 2007 + + +14.1. Secrecy of the MSRP URI + + When an endpoint sends an MSRP URI to its peer in a rendezvous + protocol, that URI is effectively a secret shared between the peers. + If an attacker learns or guesses the URI prior to the completion of + session setup, it may be able to impersonate one of the peers. + + Assuming the URI exchange in the rendezvous protocol is sufficiently + protected, it is critical that the URI remain difficult to "guess" + via brute force methods. Most components of the URI, such as the + scheme and the authority components, are common knowledge. The + secrecy is entirely provided by the session-id component. + + Therefore, when an MSRP device generates an MSRP URI to be used in + the initiation of an MSRP session, the session-id component MUST + contain at least 80 bits of randomness. + +14.2. Transport Level Protection + + When using only TCP connections, MSRP security is fairly weak. If + host A is contacting host B, B passes its hostname and a secret to A + using a rendezvous protocol. Although MSRP requires the use of a + rendezvous protocol with the ability to protect this exchange, there + is no guarantee that the protection will be used all the time. If + such protection is not used, anyone can see this secret. Host A then + connects to the provided hostname and passes the secret in the clear + across the connection to B. Host 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. Host 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-known certification authority. Furthermore, we assume + that the signaling to set up the session is protected by the + rendezvous protocol. In this case, when host A contacts host B, the + secret is passed through a 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 with certificates from well-known + certification authorities is difficult for peer-to-peer connections, + as the types of hosts that end clients use for sending instant + + + +Campbell, et al. Standards Track [Page 50] + +RFC 4975 MSRP September 2007 + + + messages are unlikely to have long-term stable IP addresses or DNS + names that the certificates can bind to. In addition, the cost of + server certificates from well-known certification authorities is + currently expensive enough to discourage their use for each client. + Using TLS in a peer-to-peer mode without well-known certificates is + discussed in Section 14.4. + + TLS becomes much more practical when some form of relay is + introduced. Clients can then form TLS connections to relays, which + are much more likely to have TLS certificates. While this + specification does not address such relays, they are described by a + companion document [23]. That document makes extensive use of TLS to + protect traffic between clients and relays, and between one relay and + another. + + TLS is used to authenticate devices and to provide integrity and + confidentiality for the header fields being transported. MSRP + elements MUST implement TLS and MUST also implement the TLS + ClientExtendedHello extended hello information for server name + indication as described in [11]. A TLS cipher-suite of + TLS_RSA_WITH_AES_128_CBC_SHA [13] MUST be supported (other cipher- + suites MAY also be supported). + +14.3. S/MIME + + The only strong security for non-TLS connections is achieved using + S/MIME. + + Since MSRP carries arbitrary MIME content, it can trivially carry + S/MIME protected messages as well. All MSRP implementations MUST + support the multipart/signed media-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 [28] provided in the session setup. MSRP can carry + unencoded binary payloads. Therefore, MIME bodies MUST be + transferred with a transfer encoding of binary. If a message is both + signed and encrypted, it SHOULD be signed first, then encrypted. If + S/MIME is supported, SHA-1, SHA-256, RSA, and AES-128 MUST be + supported. For RSA, implementations MUST support key sizes of at + least 1024 bits and SHOULD support key sizes of 2048 bits or more. + + This does not actually require the endpoint to have certificates from + a well-known certification authority. When MSRP is used with SIP, + the Identity [17] and Certificates [25] mechanisms provide 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 exchange keying material that can be used in MSRP. + + + +Campbell, et al. Standards Track [Page 51] + +RFC 4975 MSRP September 2007 + + + The MSRP session can then use S/MIME with this keying material to + sign and encrypt 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 the consequences are mitigated if all the + MSRP content is signed and encrypted with S/MIME. Although out of + scope for this document, the SIP negotiation of an MSRP session can + negotiate symmetric keying material to be used with S/MIME for + integrity and privacy. + +14.4. Using TLS in Peer-to-Peer Mode + + TLS can be used with a self-signed certificate as long as there is a + mechanism for both sides to ascertain that the other side used the + correct certificate. When used with SDP and SIP, the correct + certificate can be verified by passing a fingerprint of the + certificate in the SDP and ensuring that the SDP has suitable + integrity protection. When SIP is used to transport the SDP, the + integrity can be provided by the SIP Identity mechanism [17]. The + rest of this section describes the details of this approach. + + If self-signed certificates are used, the content of the + subjectAltName attribute inside the certificate MAY use the URI of + the user. In SIP, this URI of the user is the User's Address of + Record (AOR). This is useful for debugging purposes only and is not + required to bind the certificate to one of the communication + endpoints. Unlike normal TLS operations in this protocol, when doing + peer-to-peer TLS, the subjectAltName is not an important component of + the certificate verification. If the endpoint is also able to make + anonymous sessions, a distinct, unique certificate MUST be used for + this purpose. For a client that works with multiple users, each user + SHOULD have its own certificate. Because the generation of + public/private key pairs is relatively expensive, endpoints are not + required to generate certificates for each session. + + A certificate fingerprint is the output of a one-way hash function + computed over the Distinguished Encoding Rules (DER) form of the + certificate. The endpoint MUST use the certificate fingerprint + attribute as specified in [18] and MUST include this in the SDP. The + certificate presented during the TLS handshake needs to match the + fingerprint exchanged via the SDP, and if the fingerprint does not + match the hashed certificate then the endpoint MUST tear down the + media session immediately. + + When using SIP, the integrity of the fingerprint can be ensured + through the SIP Identity mechanism [17]. When a client wishes to use + SIP to set up a secure MSRP session with another endpoint, it sends + an SDP offer in a SIP message to the other endpoint. This offer + includes, as part of the SDP payload, the fingerprint of the + + + +Campbell, et al. Standards Track [Page 52] + +RFC 4975 MSRP September 2007 + + + certificate that the endpoint wants to use. The SIP message + containing the offer is sent to the offerer's SIP proxy, which will + add an Identity header according to the procedures outlined in [17]. + When the far endpoint receives the SIP message, it can verify the + identity of the sender using the Identity header. Since the Identity + header is a digital signature across several SIP headers, in addition + to the body or bodies of the SIP message, the receiver can also be + certain that the message has not been tampered with after the digital + signature was added to the SIP message. + + An example of SDP with a fingerprint attribute is shown in the + following figure. Note the fingerprint is shown spread over two + lines due to formatting consideration but should all be on one line. + + c=IN IP4 atlanta.example.com + m=message 7654 TCP/TLS/MSRP * + a=accept-types:text/plain + a=path:msrps://atlanta.example.com:7654/jshA7weso3ks;tcp + a=fingerprint:SHA-1 \ + 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB + + Figure 19: SDP with Fingerprint Attribute + +14.5. Other Security Concerns + + MSRP cannot be used as an amplifier for DoS attacks, but it can be + used to form a distributed attack to consume TCP connection resources + on servers. The attacker, Mallory, sends a SIP INVITE with no offer + to Alice. Alice returns a 200 with an offer and Mallory returns an + answer with SDP indicating that his 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. + + If a sender chooses to employ S/MIME to protect a message, all S/MIME + operations apply to the complete message, prior to any breaking of + the message into chunks. + + The signaling will have set up the session to or from some specific + URIs that will often have "im:" or "sip:" URI schemes. When the + signaling has been set up to a specific end user, and S/MIME is + implemented, then the client needs to verify that the name in the + SubjectAltName of the certificate contains an entry that matches the + + + +Campbell, et al. Standards Track [Page 53] + +RFC 4975 MSRP September 2007 + + + URI that was used for the other end in the signaling. There are some + cases, such as IM conferencing, where the S/MIME certificate name and + the signaled identity will not match. In these cases, the client + should ensure that the user is informed that the message came from + the user identified in the certificate and does not assume that the + message came from the party they signaled. + + In some cases, a sending device may need to attribute a message to + some other identity, and may use different identities for different + messages in the same session. For example, a conference server may + send messages on behalf of multiple users on the same session. + Rather than add additional header fields to MSRP for this purpose, + MSRP relies on the message/cpim format for this purpose. The sender + may envelop such a message in a message/cpim body, and place the + actual sender identity in the From field. The trustworthiness of + such an attribution is affected by the security properties of the + session in the same way that the trustworthiness of the identity of + the actual peer is affected, with the additional issue of determining + whether the recipient trusts the sender to assert the identity. + + This approach can result in nesting of message/cpim envelopes. For + example, a message originates from a CPIM gateway, and is then + forwarded by a conference server onto a new session. Both the + gateway and the conference server introduce envelopes. In this case, + the recipient client SHOULD indicate the chain of identity assertions + to the user, rather than allow the user to assume that either the + gateway or the conference server originated the message. + + It is possible that a recipient might receive messages that are + attributed to the same sender via different MSRP sessions. For + example, Alice might be in a conversation with Bob via an MSRP + session over a TLS protected channel. Alice might then receive a + different message from Bob over a different session, perhaps with a + conference server that asserts Bob's identity in a message/cpim + envelope signed by the server. + + MSRP does not prohibit multiple simultaneous sessions between the + same pair of identities. Nor does it prohibit an endpoint sending a + message on behalf of another identity, such as may be the case for a + conference server. The recipient's endpoint should determine its + level of trust of the authenticity of the sender independently for + each session. The fact that an endpoint trusts the authenticity of + the sender on any given session should not affect the level of trust + it assigns for apparently the same sender on a different session. + + + + + + + +Campbell, et al. Standards Track [Page 54] + +RFC 4975 MSRP September 2007 + + + When MSRP clients form or acquire a certificate, they SHOULD ensure + that the subjectAltName has a GeneralName entry of type + uniformResourceIdentifier for each URI corresponding to this client + and should always include an "im:" URI. It is fine if the + certificate contains other URIs such as "sip:" or "xmpp:" URIs. + + MSRP implementors should be aware of a potential attack on MSRP + devices that involves placing very large values in the byte-range + header field, potentially causing the device to allocate very large + memory buffers to hold the message. Implementations SHOULD apply + some degree of sanity checking on byte-range values before allocating + such buffers. + +15. IANA Considerations + + This specification instructs IANA to create a new registry for MSRP + parameters. The MSRP Parameter registry is a container for sub- + registries. This section further introduces sub-registries for MSRP + method names, status codes, and header field names. + + Additionally, Section 15.4 through Section 15.7 register new + parameters in existing IANA registries. + +15.1. MSRP Method Names + + This specification establishes the Methods sub-registry under MSRP + Parameters and initiates its population as follows. New parameters + in this sub-registry must be published in an RFC (either as an IETF + submission or RFC Editor submission). + + SEND - [RFC4975] + REPORT - [RFC4975] + + The following information MUST be provided in an RFC publication in + order to register a new MSRP method: + + o The method name. + o The RFC number in which the method is registered. + +15.2. MSRP Header Fields + + This specification establishes the header field-Field sub-registry + under MSRP Parameters. New parameters in this sub-registry must be + published in an RFC (either as an IETF submission or RFC Editor + submission). Its initial population is defined as follows: + + + + + + +Campbell, et al. Standards Track [Page 55] + +RFC 4975 MSRP September 2007 + + + To-Path - [RFC4975] + From-Path - [RFC4975] + Message-ID - [RFC4975] + Success-Report - [RFC4975] + Failure-Report - [RFC4975] + Byte-Range - [RFC4975] + Status - [RFC4975] + + The following information MUST be provided in an RFC publication in + order to register a new MSRP header field: + + o The header field name. + o The RFC number in which the method is registered. + +15.3. MSRP Status Codes + + This specification establishes the Status-Code sub-registry under + MSRP Parameters. New parameters in this sub-registry must be + published in an RFC (either as an IETF submission or RFC Editor + submission). Its initial population is defined in Section 10. It + takes the following format: + + Code [RFC Number] + + The following information MUST be provided in an RFC publication in + order to register a new MSRP status code: + + o The status code number. + o The RFC number in which the method is registered. + +15.4. MSRP Port + + MSRP uses TCP port 2855, from the "registered" port range. Usage of + this value is described in Section 6. + +15.5. URI Schema + + This document requests permanent registration the URI schemes of + "msrp" and "msrps". + +15.5.1. MSRP Scheme + + URI Scheme Name: "msrp" + URI Scheme Syntax: See the ABNF construction for "MSRP-URI" in + Section 9 of RFC 4975. + URI Scheme Semantics: See Section 6 of RFC 4975. + Encoding Considerations: See Section 6 of RFC 4975. + + + + +Campbell, et al. Standards Track [Page 56] + +RFC 4975 MSRP September 2007 + + + Applications/Protocols that use this URI Scheme: The Message Session + Relay Protocol (MSRP). + Interoperability Considerations: MSRP URIs are expected to be used + only by implementations of MSRP. No additional interoperability + issues are expected. + Security Considerations: See Section 14.1 of RFC 4975 for specific + security considerations for MSRP URIs, and Section 14 of RFC 4975 + for security considerations for MSRP in general. + Contact: Ben Campbell (ben@estacado.net). + Author/Change Controller: This is a permanent registration request. + Change control does not apply. + +15.5.2. MSRPS Scheme + + URI Scheme Name: "msrps" + URI Scheme Syntax: See the ABNF construction for "MSRP-URI" in + Section 9 of RFC 4975. + URI Scheme Semantics: See Section 6 of RFC 4975. + Encoding Considerations: See Section 6 of RFC 4975. + Applications/Protocols that use this URI Scheme: The Message Session + Relay Protocol (MSRP). + Interoperability Considerations: MSRP URIs are expected to be used + only by implementations of MSRP. No additional interoperability + issues are expected. + Security Considerations: See Section 14.1 of RFC 4975 for specific + security considerations for MSRP URIs, and Section 14 of RFC 4975 + for security considerations for MSRP in general. + Contact: Ben Campbell (ben@estacado.net). + Author/Change Controller: This is a permanent registration request. + Change control does not apply. + +15.6. SDP Transport Protocol + + MSRP defines the new SDP protocol field values "TCP/MSRP" and "TCP/ + TLS/MSRP", which should be registered in the sdp-parameters registry + under "proto". This first value indicates the MSRP protocol when TCP + is used as an underlying transport. The second indicates that TLS + over TCP is used. + + Specifications defining new protocol values must define the rules for + the associated media format namespace. The "TCP/MSRP" and "TCP/TLS/ + MSRP" protocol values allow only one value in the format field (fmt), + which is a single occurrence of "*". Actual format determination is + made using the "accept-types" and "accept-wrapped-types" attributes. + + + + + + + +Campbell, et al. Standards Track [Page 57] + +RFC 4975 MSRP September 2007 + + +15.7. SDP Attribute Names + + This document registers the following SDP attribute parameter names + in the sdp-parameters registry. These names are to be used in the + SDP att-name field. + +15.7.1. Accept Types + + Contact Information: Ben Campbell (ben@estacado.net) + Attribute-name: accept-types + Long-form Attribute Name: Acceptable media types + Type: Media level + Subject to Charset Attribute: No + Purpose and Appropriate Values: The "accept-types" attribute + contains a list of media types that the endpoint is willing to + receive. It may contain zero or more registered media-types, or + "*" in a space-delimited string. + +15.7.2. Wrapped Types + + Contact Information: Ben Campbell (ben@estacado.net) + Attribute-name: accept-wrapped-types + Long-form Attribute Name: Acceptable media types Inside Wrappers + Type: Media level + Subject to Charset Attribute: No + Purpose and Appropriate Values: The "accept-wrapped-types" attribute + contains a list of media types that the endpoint is willing to + receive in an MSRP message with multipart content, but may not be + used as the outermost type of the message. It may contain zero or + more registered media-types, or "*" in a space-delimited string. + +15.7.3. Max Size + + Contact Information: Ben Campbell (ben@estacado.net) + Attribute-name: max-size + Long-form Attribute Name: Maximum message size + Type: Media level + Subject to Charset Attribute: No + Purpose and Appropriate Values: The "max-size" attribute indicates + the largest message an endpoint wishes to accept. It may take any + whole numeric value, specified in octets. + +15.7.4. Path + + Contact Information: Ben Campbell (ben@estacado.net) + Attribute-name: path + Long-form Attribute Name: MSRP URI Path + Type: Media level + + + +Campbell, et al. Standards Track [Page 58] + +RFC 4975 MSRP September 2007 + + + Subject to Charset Attribute: No + Purpose and Appropriate Values: The "path" attribute indicates a + series of MSRP devices that must be visited by messages sent in + the session, including the final endpoint. The attribute contains + one or more MSRP URIs, delimited by the space character. + +16. Contributors and Acknowledgments + + In addition to the editors, the following people contributed + extensive work to this document: Chris Boulton, Paul Kyzivat, Orit + Levin, Hans Persson, Adam Roach, Jonathan Rosenberg, and Robert + Sparks. + + The following people contributed substantial discussion and feedback + to this ongoing effort: Eric Burger, Allison Mankin, Jon Peterson, + Brian Rosen, Dean Willis, Aki Niemi, Hisham Khartabil, Pekka Pessi, + Miguel Garcia, Peter Ridler, Sam Hartman, and Jean Mahoney. + +17. References + +17.1. Normative References + + [1] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) + Protocol Version 1.1", RFC 4346, April 2006. + + [2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, July 2006. + + [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 4234, October 2005. + + [7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions + (S/MIME) Version 3.1 Message Specification", RFC 3851, July + 2004. + + [8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message Bodies", + RFC 2045, November 1996. + + + +Campbell, et al. Standards Track [Page 59] + +RFC 4975 MSRP September 2007 + + + [9] Troost, R., Dorner, S., and K. Moore, "Communicating + Presentation Information in Internet Messages: The Content- + Disposition Header Field", RFC 2183, August 1997. + + [10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, + January 2005. + + [11] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and + T. Wright, "Transport Layer Security (TLS) Extensions", RFC + 4366, April 2006. + + [12] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging + (CPIM): Message Format", RFC 3862, August 2004. + + [13] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for + Transport Layer Security (TLS)", RFC 3268, June 2002. + + [14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD + 63, RFC 3629, November 2003. + + [15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, November + 1996. + + [16] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 + Public Key Infrastructure Certificate and Certificate + Revocation List (CRL) Profile", RFC 3280, April 2002. + + [17] Peterson, J. and C. Jennings, "Enhancements for Authenticated + Identity Management in the Session Initiation Protocol (SIP)", + RFC 4474, August 2006. + + [18] Lennox, J., "Connection-Oriented Media Transport over the + Transport Layer Security (TLS) Protocol in the Session + Description Protocol (SDP)", RFC 4572, July 2006. + +17.2. Informative References + + [19] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) + Call Control - Conferencing for User Agents", BCP 119, RFC + 4579, August 2006. + + [20] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, + "Best Current Practices for Third Party Call Control (3pcc) in + the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April + 2004. + + + + +Campbell, et al. Standards Track [Page 60] + +RFC 4975 MSRP September 2007 + + + [21] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation + Protocol Call Control - Transfer", Work in Progress, October + 2006. + + [22] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and + D. Gurle, "Session Initiation Protocol (SIP) Extension for + Instant Messaging", RFC 3428, December 2002. + + [23] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the + Message Session Relay Protocol (MSRP)", RFC 4976, September + 2007. + + [24] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE + Method", RFC 3311, October 2002. + + [25] Jennings, C., Peterson, J., and J. Fischl, "Certificate + Management Service for SIP", Work in Progress, July 2007. + + [26] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the + Session Description Protocol (SDP)", RFC 4145, September 2005. + + [27] Peterson, J., "Common Profile for Instant Messaging (CPIM)", + RFC 3860, August 2004. + + [28] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, + December 2001. + + [29] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone + Generation in the Session Initiation Protocol (SIP)", RFC 3960, + December 2004. + + [30] Saint-Andre, P., "Extensible Messaging and Presence Protocol + (XMPP): Instant Messaging and Presence", RFC 3921, October + 2004. + + [31] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating + User Agent Capabilities in the Session Initiation Protocol + (SIP)", RFC 3840, August 2004. + + [32] Peterson, J., "Address Resolution for Instant Messaging and + Presence", RFC 3861, August 2004. + + + + + + + + + + +Campbell, et al. Standards Track [Page 61] + +RFC 4975 MSRP September 2007 + + +Authors' Addresses + + Ben Campbell (editor) + Estacado Systems + 17210 Campbell Road + Suite 250 + Dallas, TX 75252 + USA + + EMail: ben@estacado.net + + + Rohan Mahy (editor) + Plantronics + 345 Encincal Street + Santa Cruz, CA 95060 + USA + + EMail: rohan@ekabal.com + + + Cullen Jennings (editor) + Cisco Systems, Inc. + 170 West Tasman Dr. + MS: SJC-21/2 + San Jose, CA 95134 + USA + + Phone: +1 408 421-9990 + EMail: fluffy@cisco.com + + + + + + + + + + + + + + + + + + + + + +Campbell, et al. Standards Track [Page 62] + +RFC 4975 MSRP September 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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. + + 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, THE IETF TRUST 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. + +Intellectual Property + + 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. + + + + + + + + + + + + +Campbell, et al. Standards Track [Page 63] + |