SIMPLE Working Group B. Campbell Internet-Draft J. Rosenberg Expires:
July 27,September 29, 2004 R. Sparks dynamicsoft P. Kyzivat Cisco Systems January 27,March 31, 2004 The Message Session Relay Protocol draft-ietf-simple-message-sessions-03draft-ietf-simple-message-sessions-04 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 27,September 29, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes the Message Session Relay Protocol (MSRP), a mechanism for transmitting a series of Instant Messages within a session. MSRP sessions are managed using the Session Description Protocol (SDP) offer/answer model carried by a signaling protocol such as the Session Initiation Protocol (SIP). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation for Session-mode Messaging . . . . . . . . . . 4 3. Scope of this Document . . . . . . . . . . . . . . . . . . 5 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6 5. Architectural Considerations . . . . . . . . . . . . . . . 7 5.1 Transferring Large Content . . . . . . . . . . . . . . . . 7 6. SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . 7 6.1 Use of the SDP M-line . . . . . . . . . . . . . . . . . . 8 6.2 The DirectionAccept Types Attribute . . . . . . . . . . . . . . . . .8 6.3 The Accept Types Attribute . . . .MIME Wrappers . . . . . . . . . . . . 10 6.4 MIME Wrappers. . . . . . . . . . 9 6.4 URL Negotiations . . . . . . . . . . . . 10 6.5 URL Negotiations. . . . . . . . . 10 6.5 Path Attributes with Multiple URLs . . . . . . . . . . . . 11 6.6 Updated SDP Offers . . . . . . . . . . . . . . . . . . . . 1211 6.7 Example SDP Exchange . . . . . . . . . . . . . . . . . . . 12 6.8 Connection Negotiation . . . . . . . . . . . . . . . . . . 12 6.9 Negotiation of Delivery Status Notifications . . . . . . . 13 7. The Message Session Relay Protocol . . . . . . . . . . . . 13 7.1 MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . 1413 7.1.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 14 7.1.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 1514 7.1.3 The msrps URL Scheme . . . . . . . . . . . . . . . . . . . 1615 7.2 Connection Managment . . . . . . . . . . . . . . . . . . . 15 7.3 MSRP messages . . . . . . . . . . . . . . . . . . . . . . 16 7.315 7.4 MSRP Transactions . . . . . . . . . . . . . . . . . . . . 17 7.416 7.5 MSRP Sessions . . . . . . . . . . . . . . . . . . . . . . 17 184.108.40.206.1 Initiating an MSRP session . . . . . . . . . . . . . . . . 17 220.127.116.11.2 Handling VISIT requests . . . . . . . . . . . . . . . . . 21 7.4.319 7.5.3 Sending Instant Messages on a Session . . . . . . . . . . 21 7.4.419 7.5.4 Ending a Session . . . . . . . . . . . . . . . . . . . . . 22 7.4.520 7.5.5 Managing Session State and Connections . . . . . . . . . . 23 7.521 7.6 Delivery Status Notifications . . . . . . . . . . . . . . 22 7.7 Method Descriptions . . . . . . . . . . . . . . . . . . . 24 7.5.122 7.7.1 SEND . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.5.222 7.7.2 VISIT . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.622 7.8 Response Code Descriptions . . . . . . . . . . . . . . . . 24 7.6.122 7.8.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.6.223 7.8.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.6.323 7.8.3 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.6.423 7.8.4 426 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.6.523 7.8.5 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.6.623 7.8.6 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.723 7.9 Header Field Descriptions . . . . . . . . . . . . . . . . 25 7.7.123 7.9.1 TR-ID . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.7.2 Content-Type23 7.9.2 To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.7.3 S-URL23 7.9.3 From . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.9.4 Content-Type . . . . . . . . . . . . . . . . . . . . 26. . . 24 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . 2624 9. IANA Considerations . . . . . . . . . . . . . . . . . . . 2827 9.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 2827 9.2 MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . . 2827 9.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 2827 9.2.2 Character Encoding . . . . . . . . . . . . . . . . . . . . 2827 9.2.3 Intended Usage . . . . . . . . . . . . . . . . . . . . . . 2827 9.2.4 Protocols . . . . . . . . . . . . . . . . . . . . . . . . 2827 9.2.5 Security Considerations . . . . . . . . . . . . . . . . . 2927 9.2.6 Relevant Publications . . . . . . . . . . . . . . . . . . 2927 9.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 2928 9.3.1 Direction .Accept Types . . . . . . . . . . . . . . . . . . . . . . . 2928 9.3.2 AcceptWrapped Types . . . . . . . . . . . . . . . . . . . . . . . 2928 9.3.3 Wrapped TypesPath . . . . . . . . . . . . . . . . . . . . . . 29. . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . 2928 10.1 TLS and the MSRPS Scheme . . . . . . . . . . . . . . . . . 3028 10.1.1 Sensitivity of the Session URL . . . . . . . . . . . . . . 3029 10.1.2 End to End Protection of IMs . . . . . . . . . . . . . . . 3130 10.1.3 CPIM compatibility . . . . . . . . . . . . . . . . . . . . 3130 10.1.4 PKI Considerations . . . . . . . . . . . . . . . . . . . . 3231 11. Changes from Previous Draft Versions . . . . . . . . . . . 3231 11.1 draft-ietf-simple-message-sessions-03draft-ietf-simple-message-sessions-04 . . . . . . . . . . 3231 11.2 draft-ietf-simple-message-sessions-02draft-ietf-simple-message-sessions-03 . . . . . . . . . . 3332 11.3 draft-ietf-simple-message-sessions-01draft-ietf-simple-message-sessions-02 . . . . . . . . . . 3332 11.4 draft-ietf-simple-message-sessions-00draft-ietf-simple-message-sessions-01 . . . . . . . . . . 3432 11.5 draft-campbell-simple-im-sessions-01draft-ietf-simple-message-sessions-00 . . . . . . . . . . 33 11.6 draft-campbell-simple-im-sessions-01 . 34 12. Contributors. . . . . . . . . . 33 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . 34 Normative References . . . . . . . . . . . . . . . . . . . 3534 Informational References . . . . . . . . . . . . . . . . . 3534 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 3635 Intellectual Property and Copyright Statements . . . . . . 3837 1. Introduction The MESSAGE  extension to SIP  allows SIP to be used to transmit instant messages. Instant messages sent using the MESSAGE method are normally independent of each other. This approach is often called page-mode messaging, since it follows a model similar to that used by many two-way pager devices. Page-mode messaging makes sense for instant message exchanges where a small number of messages occur. Endpoints may treat page-mode messages as if they took place in an imaginative session, but there is no formal relationship between one message and another. There are also applications in which it is useful for instant messages to be formally associated in a session. For example, a user may wish to join a text conference, participate in the conference for some period of time, then leave the conference. This usage is analogous to regular media sessions that are typically initiated, managed, and terminated using SIP. We commonly refer to this model as session-mode messaging. One of the primary purposes of SIP and SDP (Section 6) is the management of media sessions. Session-mode messaging can be thought of as a media session like any other. This document describes the motivations for session-mode messaging, the Message Session Relay Protocol, and the use of the SDP offer/answer mechanism for managing MSRP session. 2. Motivation for Session-mode Messaging Message sessions offer several advantages over page-mode messages. For message exchanges that include more than a small number of message transactions, message sessions offer a way to remove messaging load from intervening SIP proxies. For example, a minimal session setup and tear-down requires one INVITE/ACK transaction, and one BYE transaction, for a total of 5 SIP messages. Normal SIP request routing allows for all but the initial INVITE transaction to bypass any intervening proxies that do not specifically request to be in the path for future requests. Session-mode messages never cross the SIP proxies themselves. Each page-mode message involves a complete SIP transaction, that is, a request and a response. Any page-mode message exchange that involves more than 2 MESSAGE requests will generate more SIP requests than a minimal session initiation sequence. Since MESSAGE is normally used outside of a SIP dialog, these requests will typically traverse the entire proxy network between the endpoints. Due to network congestion concerns, the MESSAGE method has significant limitations in message size, a prohibition against overlapping requests, etc. Much of this has been required because of perceived limitations in the congestion-avoidance features of SIP itself. Work is in progress to mitigate these concerns. However, session-mode messages are always sent over reliable, congestion-safe transports. Therefore, there are no restrictions on message sizes. There is no requirement to wait for acknowledgement before sending another message, so that message transactions can be overlapped. Message sessions allow greater efficiency for secure message exchanges. The SIP MESSAGE request inherits the S/MIME features of SIP, allowing a message to be signed and/or encrypted. However, this approach requires public key operations for each message. With session-mode messaging, a session key can be established at the time of session initiation. This key can be used to protect each message that is part of the session. This requires only symmetric key operations for each subsequent IM, and no additional certificate exchanges are required after the initial exchange. The establishment of the session key can be done using standard techniques that apply to voice and video, in addition to instant messaging. Finally, SIP devices can treat message sessions like any other media sessions. Any SIP feature that can be applied to other sorts of media sessions can equally apply to message sessions. For example, conferencing , third party call control , call transfer , QoS integration , and privacy  can all be applied to message sessions. Messaging sessions can also reduce the overhead in each individual message. In page-mode, each message needs to include all of the SIP headers that are mandated by RFC 3261 . However, many of these headers are not needed once a context is established for exchanging messages. As a result, messaging session mechanisms can be designed with significantly less overhead. 3. Scope of this Document This document describes the use of MSRP between endpoints. It does not specify the use of intermediaries, nor does it prohibit such use. We expect an extension to this specification to define MSRP intermediaries and their use. This document describes the use of MSRP over TCP. MSRP may be used over other congestion-controlled protocols such as SCTP. However, the specific bindings for other such protocols are outside the scope of this document. 4. Protocol Overview The Message Session Relay Protocol (MSRP) provides a mechanism for transporting session-mode messages between endpoints. MSRP uses connection oriented, reliable network transport protocols only. It can operate in the presence of many NAT and firewall environments, as it allows participants to positively associate message sessions with specific connections, and does not depend upon connection source address, which may be obscured by NATs. MSRP uses the following primitives: SEND: Used to send message content from one endpoint to another. VISIT: Used by an endpoint to establish a session association to the host endpoint. Assume A is an endpoint that wishes to establish a message session, and B is the endpoint invited by A. A invites B to participate in a message session by sending a URL that represents the session.URL. This URL is temporary, and must not duplicate theany URL usedthat A has offered for anyother active sessions. B "visits" A by connecting to A and sending a VISIT request containing the URL that A provided. This associates the connection from B with the session. B then responds to the invitation, informinginvitation with a URL of its own. This informs A that B has accepted the session.session, and will accept messages at that URL. A and B may now exchange messages using SEND requests on the connection. Each party targets such requests to the peer's URL. When either party wishes to end the session, it informs its peer withusing the appropriate mechanism of the chosen signaling protocol, such as a SIP BYE request. A terminates the session by invalidating associated state, and dropping the connection.The end to end case looks something like the following. (Note that the example shows a logical flow only; syntax will come later in this document.) A->B (SDP): offer (msrp://A/123) B->A (MSRP): VISIT (msrp://A/123)(msrp://A/123, msrp://B/456) A->B (MSRP): 200 OK B->A (SDP): answer(msrp://A/123)answer(msrp://B/456) A->B (MSRP): SEND (msrp://B/456) B->A (MSRP): 200 OK B->A (MSRP): SEND (msrp://A/123) A->B (MSRP): 200 OK 5. Architectural Considerations There are a number of considerations that, if handled in a reasonable fashion, will allow more effective use of the protocols described in this document. 5.1 Transferring Large Content MSRP endpoints may attempt to send very long messages in a session. For example, most commercial instant messaging systems have a file transfer feature. Since MSRP does not impose message size limits, there is nothing to prevent endpoints from transferring files over it. An analysis of whether it makes sense to do this, rather than sending such content over FTP, HTTP, or some other such protocol, is beyond the scope of this document. However, implementers should be aware of the impact of sending very large messages over MSRP. The primary impact is, since MSRP is sent over TCP, is that any additional messages that the sender wishes to send will be blocked until the large transfer is complete. This includes responses to messages sent by the peer. Therefore, any SEND transactions initiated by the peer are likely to time out, even though they are received without problems. Further, there is no way to abort the sending of a very large message before it is complete. For the sake of efficiency, the framing mechanism in MSRP is very simple. There is no clean way to recover framing if the complete message is not sent. These issues can be mitigated greatly if the endpoint simply establishes a separate session for the transfer. This allows the transfer to be sent without interfering with any instant messages being sent on other sessions. Further, the endpoint can abort the transfer by simply tearing down the transfer session. Therefore, if a peer wishes to send very large content, it SHOULD establish a dedicated session for that purpose. It should also indicate that the dedicated session is send only, so that the receiving endpoint does not attempt to send content back along the same session. 6. SDP Offer-Answer Exchanges for MSRP Sessions MSRP sessions will typically be initiated using the Session Description Protocol (SDP)  offer-answer mechanism, carried in the Session Initiation Protocol (SIP)  or any other protocol supporting it. MSRP borrows the idea of the direction attributes from COMEDIA , but does not depend on that specification.6.1 Use of the SDP M-line The SDP "m"-line takes the following form: m=<media> <port> <protocol> <format list> For non-RTP media sessions, The media field specifies the top level MIME media type for the session. For MSRP sessions, the media field MUST have the value of "message". The port field is normally not used, and MAY be set to any value chosen by the endpoint. A port field value of zero has the standard SDP meaning. Non-zero values MUST not be repeated in other MSRP m-lines in the same SDP document. The proto field MUST designate the message session mechanism and transport protocol, separated by a "/" character. For MSRP, left part of this value MUST be "msrp". For MSRP over TCP, the right part of this field MUST take the value "tcp". For MSRP over other transport protocols, the field value MUST be defined by the specification for that protocol binding. The format list list is ignored for MSRP. This is because MSRP formats are specified as MIME content types, which are not convenient to encode in the SDP format list syntax. Instead, the allowed formats are negotiated using "a"-line attributes. For MSRP sessions, the format list SHOULD contain a "*" character, and nothing else. The port field in the M-line is not used to determine the port to which to connect. Rather, the actual port is determined by the contents ofthe sessionMSRP URL (Section 7.1).7.1) in the path attribute. However, a port value of zero has the normal SDP meaning. The following example illustrates an m-line for a message session, where the endpoint is willing to accept root payloads of message/ cpim, plain text or HTML. The second two types could either be presented as the root body, or could be contained within message/cpim bodies. m=message 9999 msrp/tcp * 6.2 The DirectionAccept Types Attribute SinceMSRP uses connection oriented transport protocols, one goal of the SDP negotiation is to determine which participant initiates the transport connection. The direction attribute advertises whether the offerer or answerer wishes to initiate the connection, wishes the peer endpoint to initiate the connection, or doesn't care. The endpoint that accepts the connection is said to "host" the session, and is known as the hosting endpoint. The endpointcan carry any MIME encoded payload. Endpoints specify MIME content types that initiates the connection is saidthey are willing to "visit" the session, and is known asreceive in the visiting endpoint. The directionaccept types "a"-line attribute. This attribute is included in an SDP a-line, with a value takinghas the following syntax: directionaccept-types = direction-labelaccept-types-label ":" role direction-label = "direction" role = active / passive / both activeformat-list accept-types-label = "active" sp count passive"accept-types" format-list = "passive" sp count bothformat-entry *( SP format-entry) format-entry = "both" sp count [sp timeout] count(type "/" subtype) / ("*") type = 1*DIGIT ; Connection count timeouttoken subtype = 1*DIGIT ; timeout value in seconds The valuestoken SDP offers for MSRP sessions MUST include an accept-types attribute. SDP answers MUST also include the role field are as follows: passive: The endpoint wishes to host the session active: The endpoint wishes the peer to host the session. both: The endpoint is willing to act as either host or visitor. If "both" is selected, it mayattribute, which MUST contain an optional timeout value. This timeout specifies how much timeeither the answerer should wait before giving up on a connection and attempting to take oversame list as host device. Ifin the timeout value is not specified, it defaults to 30 seconds. The SDPoffer for an MSRP session MUST containor a direction attribute, which MAY take anysubset of that list. A "*" entry in the defined values.accept-types attribute indicates that the sender may attempt to send messages with media types that have not been explicitly listed. If the offererreceiver is capable of hostingable to process the session, thenmedia type, it SHOULD select "both". The endpoint SHOULD NOT select "active" unlessdoes so. If not, it cannot host the session under any circumstances. The endpointwill respond with a 415. Note that all explicit entries SHOULD NOT select "passive" unless it has no option but to hostbe considered preferred over any non-listed types. This feature is needed as, otherwise, the session.list of formats for rich IM devices may be prohibitively large. The count is used to determine if a new connection is requiredaccept-types attribute may include container types, that is, mime formats that contain other types internally. If compound types are used, the types listed in future SDP exchanges for a given stream. Forthe initial SDP exchange,accept-types attribute may be used both as the count pamameter MUSTroot payload, or may be set to zero. Endpoints sendingwrapped in a new offer related to an existing stream MUST increment this count fromlisted container type. (Note that the valuecontainer type MUST also be listed in the most recent successful exchange for the stream.accept-types attribute.) 6.3 MIME Wrappers The SDP answer also MUST contain a direction attribute, but its value choices are limited based on the valueMIME content-types in the offer. If the offer contained "active", then the answerer MUST either select "passive" or reject the offer. Likewise, if the offer contained "passive", then the answerer MUST select "active" or reject the offer. If the offer contained "both", the answerer SHOULD select "active", but MAY select "passive" if it is unable to reach the host device,accept-types attribute will often include container types; that is, types that contain other types. For example, "message/cpim" or if local policy requires it to act as host. The answerer MUST set the count parameter"multipart/mixed." Occasionally an endpoint will need to the same value asspecify a MIME body type that in the offer. 6.3 The Accept Types Attribute MSRPcan carry any MIME encoded payload.only be used if wrapped inside a listed container type. Endpoints MAY specify MIME contenttypes that theyare willingonly allowed to receive in the acceptbe wrapped inside compound types "a"-line attribute.using the "accept-wrapped-types" attribute in an SDP a-line. This attribute has the following syntax: accept-typesaccept-wrapped-types = accept-types-labelwrapped-types-label ":" format-list accept-types-labelwrapped-types-label = "accept-types""accept-wrapped-types" ` The format-list = format-entry *( SP format-entry) format-entry = (type "/" subtype) / ("*") type = token subtype = token SDP offerselement has the identical syntax as defined for MSRP sessions MUST include anthe accept-types attribute. SDP answers MUST also includeThe semantics for this attribute are identical to those of the accept-types attribute, which MUST contain either the same list as in the offer or a subset of that list. A "*" entry in the accept-types attribute indicates that the sender may attempt to send messageswith media types that have not been explicitly listed. If the receiver is able to processthe media type, it does so. If not, it will respond with a 415. Noteexception 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 devicesspecified types may only be prohibitively large. Theused when wrapped inside containers. Only types listed in accept-types attributemay include container types, that is, mime formats that contain other types internally. If compound types are used,be used as the types"root" type for the entire body. Since any type listed in theaccept-types attributemay be used both as thea root payload, or may bebody, and wrapped in a listed container type. (Note thatother bodies, format entries from the container type MUST alsom-line SHOULD NOT be listed in the accept-types attribute.) 6.4 MIME Wrappers The MIME content-typesrepeated in the accept-types attribute will often include container types; that is,this attribute. This approach does not allow for specifying distinct lists of acceptable wrapped types that contain other types. For example, "message/cpim" or "multipart/mixed." Occasionallyfor different types of containers. If an endpoint will need to specify a MIME body type that can only be used if wrapped inside a listed container type. Endpoints MAY specify MIME types that are only allowed to be wrapped inside compound types using the "accept-wrapped-types" attribute in an SDP a-line. This attribute has the following syntax: accept-wrapped-types = wrapped-types-label ":" format-list wrapped-types-label = "accept-wrapped-types" ` The format-list element has the identical syntax as defined for the accept-types attribute. The semantics for this attribute are identical to those of the accept-types attribute, with the exception that the specified types may only be used when wrapped inside containers. Only types listed in accept-types may be used as the "root" type for the entire body. Since any type listed in accept-types may be used both as a root body, and wrapped in other bodies, format entries from the m-line 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 understandsunderstands a MIME type in the context of one wrapper, it is assumed to understand it in the context of any other acceptable wrappers, subject to any constraints defined by the wrapper types themselves. The approach of specifying types that are only allowed inside of containers separately from the primary payload types allows an endpoint to force the use of certain wrappers. For example, a CPIM 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 could choose to use those types without the wrapper. 6.56.4 URL Negotiations AnEach endpoint in an MSRP session is identified by an MSRP URL, which is determined by the hosting endpoint, anda URL. These URLs are negotiated in the SDP exchange. AnyEach SDP offer or answer that creates a possibility that the sender will host the session, that is, it contains a direction value of "passive" or "both",MUST contain anone or more MSRP URL in a sessionpath attribute. This attribute has the following syntax: a=session:<MSRP_URL>a=path ":" MSRP_URL *(SP MSRP_URL) where <MSRP_URL>MSRP_URL is an MSRP or MSRPS URL as defined in Section 7.1. The visitoranswerer will use the session URL established by the host bothoffered URL(s) to resolve the host address and port,port when connecting, and to identify the sessiontarget when connecting.sending messages. For MSRP sessions, the address field in the C-line is not relevant, and MUST be ignored. The port field in the M-line MUST be ignored if non-zero. Zero values have the normalusual meaning for SDP. The following example shows an SDP offer withBoth offerer and answerer store the path values received from the peer. For a sessiongiven endpoint, the local URL of "msrp://example.com:7394/2s93i" v=0 o=someuser 2890844526 2890844527 IN IP4 alice.example.com s= c=IN IP4 alice.example.com m=message 9999 msrp/tcp * a=accept-types:text/plain a=direction:both 0 a=session:msrp://example.com:7394/2s93i The sessionis the URL MUST bethat the endpoint put into a temporarypath attribute value to send to its peer. The remote URL assigned just foris the URL received from the peer. If the path attribute received from the peer contains more than one URL, then the remote URL is the first one. The remote path is the entire path attribute value received from the peer. The following example shows an SDP offer with a session URL of "msrp://a.example.com:7394/2s93i" v=0 o=someuser 2890844526 2890844527 IN IP4 alice.example.com s= c=IN IP4 alice.example.com m=message 9999 msrp/tcp * a=accept-types:text/plain a=path:msrp://a.example.com:7394/2s93i The first URI in the path attribute MUST identify the endpoint that generated the SDP document, or some other location where that endpoint wishes to receive messages associated with the session. If the URL identifies the endpoint, it MUST MUST be a temporary URL assigned just for this particular session. Itsession, and MUST NOT duplicate any URL in use for any other session hosted by the endpoint. Further, sincein which the peerendpoint will use the session URL to identify itself when connecting,is currently participating. Further, it SHOULD be hard to guess, and protected from eavesdroppers. This will be discussed in more detail in Section 10. 6.6 Updated SDP Offers6.5 Path Attributes with Multiple URLs As mentioned previously, this document describes MSRP endpoints may sometimes need to send additional SDP exchangesfor an existing session. For example, they may need to negotiate a new connection because of a TCP failure or some other reason. They may need to send periodic exchanges withpeer-to-peer scenarios, that is, when no changerelays are used. However, we expect a separate document to refresh state indescribe the network, for example, SIP timers. They may need to change some other streamuse of relays in a session without affectingthe MSRP stream, or they may neednear future. The path attribute supports lists of URLs in order to changefacilitate that work. For peer-to-peer session, a path attribute will contain exactly one URL, describing an MSRP stream without affecting some other stream. Once MSRP endpoints have completed an intitial negotiation, further exchanges do not change their roles as the active or passive party for that particular stream.endpoint. This means that if the visitor sends a new SDP offer, it MUST remain the visitor, i.e. it MUST offerendpoints that only implement this specification will never send more than one URL in a direction of "active" and itpath attribute, but MUST NOT includebe prepared to receive more than one. When an MSRP URL. Likewise, if the host sends a new offer, it MUST includeendpoint receives more than one URL in a directionpath header, only the first entry is relevant for purposes of "passive"resolving the address and it MUST include a URL. Updated offers MUST NOT include a direction of "both."port, and establishing the network connection. If offering party wishes to establish a new connection asan endpoint puts more than one URL in a result ofpath attribute, final URL in the updated exchange, itpath attribute MUST incrementexhibit the count parameteruniqueness properties described above. Uniqueness requirements for other entries in the directionattribute from thatare out of the most recent successful exchange. If the passive endpoint wishes the the visitor to re-connect, it the included URL MUST be different than the URL from previous offers. Thisscope for this document. 6.6 Updated SDP Offers To do: Revisit this section based on new URL MAY be completely different fromconnection management rules 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 original and MAY even resolvenetwork, for example, SIP timers. They may need to change some other stream in a different location. Ifsession without affecting the active party sends a new offer with an incremented count parameter, the passive party MUST supply a new URL,MSRP stream, or reject the offer. If either party sends a new offer with the same count value as the previous exchange, the session URI MUST NOT change. If this negotiation results in a new session URL, the active party MUST close the existing connection, open a new connection, and send a VISIT request as described below.they may need to change an MSRP stream without affecting some other stream. If either party wish to send an SDP document that changes nothing at all, then it MUST have the same o-line version as in the previous exchange. 6.7 Example SDP Exchange Endpoint A wishes to invite Endpoint B to a MSRP session. A offers the following session description containing the following lines:description: v=0 o=usera 2890844526 2890844527 IN IP4 alice.example.com s= c=IN IP4 alice.example.com t=0 0 m=message 9999 msrp/tcp * a=accept-types: message/cpim text/plain text/html a=direction:both 0 a=session:msrp://alice.example.com:7394/2s93i9a=path:msrp://alice.example.com:7394/2s93i9 Endpoint B chooses to participate in the role of visitor, opens a TCP connection to alice.example.com:7394, and successfullyperforms a VISIT transaction passing the URL of msrp://alice.example.com:7394/ 2s93i9.msrp:// alice.example.com:7394/2s93i9. B indicates that it has accomplished this by answering with: v=0 o=userb 2890844530 2890844532 IN IP4 bob.example.com s= c=IN IP4 dontlookhere t=0 0 m=message 9999 msrp/tcp * a=accept-types:message/cpim text/plain a=direction:active 0a=path:msrp://bob.example.com:8493/si438ds A may now send IMs to B by executing SEND transactions ontransactions. 6.8 Connection Negotiation Previous versions of this document included a mechanism to negotiate the same connectiondirection for any required TCP connection. The mechanism was loosely based on which B sentCOMEDIA work being done in the VISIT request.MMUSIC working group. The primary motivation was to allow MSRP sessions to succeed in situations where the offerer could not accpet 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 for a number of reasons: It added a great deal of complexity to session creation. The work in MSRP had begun to diverge from the work in MMUSIC. There was a lack of successful implementation experience of the COMEDIA work. 6.9 Negotiation of Delivery Status Notifications To Do. 7. The Message Session Relay Protocol The Message Session Relay Protocol (MSRP) is a text based, message oriented protocol for the transfer of instant messages in the context of a session. MSRP uses the UTF8 character set. MSRP messages MUST be sent over a reliable, congestion-controlled, connection-oriented transport protocol. This document specifies the use of MSRP over TCP. Other documents may specify bindings for other such protocols. 7.1 MSRP URLs MSRP sessions are identified by MSRP URLs.An MSRP URL follows a subset of the URL syntax in Appendix A of RFC2396 , with a scheme of "msrp": msrp_url = "msrp" ":" "//" [userinfo] hostport ["/' resource] resource = 1*unreserved The constructions for "userinfo", "hostport", and "unreserved" are detailed in RFC2396 . An MSRP URL server part identifies the hosting device ofa participant in an MSRP session. If the server part contains a numeric IP address, it MUST also contain a port. The resource part identifies a particular session at that host device.the participant. The absence of the resource part indicates a reference to an MSRP host device, but does not specifically refer to a particular session resource. MSRP has an IANA registered recommended port defined in Section 9.1. This value is not a default, as the URL process described herein will always explicitly resolve a port number. However, the URLs SHOULD be configured so that the recommended port is used whenever appropriate. This makes life easier for network administrators who need to manage firewall policy for MSRP. The server part will typically not contain a userinfo component, but MAY do so to indicate a user account for which the session is valid. Note that this is not the same thing as identifying the session itself. If a userinfo component exists, MUST be constructed only from "unreserved" characters, to avoid a need for escape processing. Escaping MUST NOT be used in an MSRP URL. Furthermore, a userinfo part MUST NOT contain password information. The following is an example of a typical MSRP URL: msrp://host.example.com:8493/asfd34 7.1.1 MSRP URL Comparison MSRP URL comparisons MUST be performed according to the following rules: 1. The host part is compared as case insensitive. 2. If the port exists explicitly in either URL, then it must match exactly. An URL with an explicit port is never equivalent to another with no port specified. 3. The resource part is compared as case insensitive. A URL without a resource part is never equivalent to one that includes a resource part. 4. Userinfo parts are not considered for URL comparison. Path normalization is not relevant for MSRP URLs. Escape normalization is not required, since the relevant parts are limited to unreserved characters. 7.1.2 Resolving MSRP Host Device An MSRP host device is identified by the server part of an MSRP URL. If the server part contains a numeric IP address and port, they MUST be used as listed. If the server part contains a host name and a port, the connecting device MUST determine a host address by doing an A or AAAA DNS query, and use the port as listed. If the server part contains a host name but no port, the connecting device MUST perform the following steps: 1. Construct an SRV  query string by prefixing the host name with the service field "_msrp" and the protocol field ("_tcp" for TCP). For example, "_msrp._tcp.host.example.com". 2. Perform a DNS SRV query using this query string. 3. Select a resulting record according to the rules in RFC2782 . Determine the port from the chosen record. 4. If necessary, determine a host device address by performing an A or AAAA query on the host name field in the selected SRV result record. If multiple A or AAAA records are returned, the first entry SHOULD be chosen for the initial connection attempt. This allows any ordering created in the DNS to be preserved. 5. If the 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. If all of these fail, the device SHOULD attempt to use any additional SRV records that may have been returned, following the normal rules for SRV record selection. In most cases, the transport protocol will be determined separately from the resolution process. For example, if the MSRP URL was communicated in an SDP offer or answer, the SDP M-line will contain the transport protocol. When an MSRP URL is communicated outside of SDP, the protocol SHOULD also be communicated. If a device needs to resolve an MSRP URL and does not know the protocol, it SHOULD assume TCP. 7.1.3 The msrps URL Scheme The "msrps" URL Scheme indicates that each hop MUST be secured with TLS. Otherwise, it is used identically as an MSRP URL, except that a MSRPS URL MUST NOT be considered equivalent to an MSRP URL. The MSRPS scheme is further discussed in Section 10. 7.2 Connection Managment When an MSRP messages MSRP messages are either requests or responses. Requestsendpoint receives an SDP offer, and responses are distinguished from one another by the first line. The first line ofintends to accept it, it MUST establish a connection device described by the remote URL, if one does not already exist. If it already has a connection associated with another session for which the peer URL host part matches the host part of the remote URL, it SHOULD use the that connection, instead. Once connected, the answerer MUST send a VISIT request to associate the new session with the connection, prior to sending the SDP answer. Either endpoint MAY tear down a connection when it no longer has any active or proposed sessions associated with the connection. 7.3 MSRP messages MSRP messages are either requests or responses. Requests and responses are distinguished from one another by the first line. The first line of a Request takes the form of the request-start entry below. Likewise, the first line of a response takes the form of response-start. The syntax for an MSRP message is as follows: msrp-message = request-start/response-start *(header CRLF) [CRLF body] request-start = "MSRP" SP length SP Method CRLF response-start = "MSRP" SP length SP Status-Code SP Reason CRLF length = 1*DIGIT ; the length of the message, ; exclusive of the start line. Method = SEND / VISIT / other-method other-method = token header = Transaction-ID / Session-URL / Content-Types Status-Code = 200 ;Success / 400 ;Bad Request / 403 ;Forbidden / 415 ;Unsupported Content Type / 426 ;Upgrade Required / 481 ;No session / 506 ;duplicate session Reason = token ; Human readable text describing status Transaction-ID = "Tr-ID" ":" token Content-Type = "Content-Type" ":" quoted-string Session-URLTo = "To" ":" msrp_url *(SP msrp_url) From = "S-URL""From" ":" msrp_url All requests and responses MUST contain at least a TR-ID header field. All requests must also contain the To and From header fields. Messages MAY contain other fields, depending on the method or response code. 7.37.4 MSRP Transactions An MSRP transaction consists of exactly one request and one response. A response matches a transaction if it share the same TR-ID value, and arrives on the same connection on which the transaction was sent. Endpoints MUST select TR-ID header field values in requests so that they are not repeated by the same endpoint in scope of the given session. TR-ID values SHOULD be globally unique. The TR-ID space of each endpoint is independent of that of its peer. Endpoints MUST NOT infer any semantics from the TR-ID header field beyond what is stated above. In particular, TR-ID values are not required to follow any sequence. MSRP Transactions complete when a response is received, or after a timeout interval expires with no response. Endpoints MUST treat such timeouts in exactly the same way they would treat a 500 response. The timeout interval SHOULD be 30 seconds, but other values may be established as a matter of local policy. 7.47.5 MSRP Sessions AN MSRP session is a context in which a series of instant messages are exchanged, using SEND requests. A session has two endpoints (a host and a visitor). A session isendpoints, identified by anMSRP URL. 7.4.1URLs. 7.5.1 Initiating an MSRP session When an endpoint wishes to engage a peer endpointin a message session, it invites the peer to communicate using an SDP offer, carried over SIP or some other protocol supporting the SDP offer/ answeroffer/answer model. For the purpose of this document, we will refer to the endpoint choosing to initiate communication as the offerer, and the peer being invited as the answerer. The offerer SHOULD volunteer to act as the hosting endpoint if allowed by policy and network topology. The peer that is not the host is designated as the visitor. The offerer MAY request the answerer to act as host if it is prevented from accepting connections by network topology or policy. If the offerer wishes to host the session, it MUST perform the following steps: 1. Construct a session MSRP URL . This URL MUST resolve to the location that the offerer wishes to host the connection. The URL SHOULD be temporary, SHOULD be hard to guess, and MUST not duplicate the URL of any other session currently hosted by the offerer. 2. Listen for a connection from the peer. 3. Construct an SDP offer as described in Section 6, including the list of allowed IM payload formats in the accept-types attribute. The offerer maps the session URL to the session attribute, as described in Section 6.5. 4. Insert a direction attribute. This value SHOULD be "both", indicating that the offerer will allow the answerer to override the offerer's decision to host. If "both" is selected, the offerer SHOULD leave the timeout at the default value (by leaving out the value entirely. However, the offerer MAY select a different timeout if circumstances warrant it. The direction value MAY be "passive" if the offerer is prevented from allowing the answerer override this choice. The direction attribute must also contain the count parameter, which will be set to zero for an initial exchange. 5. Send the SDP offer using the normal processing for the signaling protocol. If the offerer chooses to force the answerer to host the session, it MUST perform the following steps instead: 1. Construct an SDP offer as described above, but with no session attribute. 2. Insert a direction attribute with a value of "active", with an appropriate count parameter value. 3. Send the offer using normal processing for the signaling protocol. When the answerer receives the SDP offer and chooses to participate in the session, it must choose whether to act as the host or the visitor. A direction attribute value of "both" in the offer indicates that the offerer prefers to host, but will allow the answerer to host. In this case the answerer SHOULD act as the visitor, but MAY choose to host. A value of "passive" means the offerer insists upon hosting, in which case the answerer MUST act as visitor or decline the offer. If the answerer chooses to participate as a visitor, it MUST perform the following steps: 1. Determine the host address and port from the session URL, following the procedures in section Section 7.1 2. Connect to the host address and port, using the transport protocol from the M-line. 3. Construct a VISIT request, which MUST contain the following information: 1. An S-URL header field containing the session URL. 2. A TR-ID header field containing a unique transaction ID. 3. A size field containing size of the message subsequent to the start-line. 4. Send the request and wait for a response 5. If the transaction succeeds, send a SDP answer via the signaling protocol, according to the following rules: 1. The C-line is copied unmodified from the offer. 2. The M-Line contains a dummy port value, the protocol field from the original offer, and the accept-types attribute contains the SEND payload media types that the answerer is willing to accept. The accept-types attribute in the answer MUST be either the same as that of the offer, or it MUST be a subset. 3. A direction attribute containing the value "active", and the count value copied from the offer. 6. If the transaction fails, the answerer MAY choose to act as host, if allowed by the direction attribute of the answer. If the answerer is unable or unwilling to host, then it should return an error response as appropriate for the signaling protocol. Some TCP connection failure conditions may ordinarily take some time to notice. For example, if the offerer is unable to open a TCP connection to the host device, this connection attempt may take a fairly large number of seconds to timeout. This length of time will not be acceptable for many call flow scenarios. Therefore, the devices SHOULD limit the time they wait for the TCP connection to a shorter timeout value, whichpurpose of this document, we will defaultrefer to 30 seconds. However,the offerer MAY supply a different time inendpoint choosing to initiate communication as the timeout parameter ofofferer, and the "both" direction value. Ifpeer being invited as the answerer. The offerer suppliesMUST be prepared to accept a value, the answerer SHOULD use that value for the TCPconnection timeout, interpreted as an integer number of seconds. If the answerer chooses to hostfrom the session, itanswerer. The offerer MUST perform the following steps: 1. Construct a new sessionMSRP URL .to serve as the local URL. This MUST be a MSRP or MSRPS URL,URL MUST resolve to the answerer, and MUST not be the same as the session URL inlocation that the offer. The URL SHOULD be temporary, SHOULD be hardofferer wishes to guess, and MUST not duplicate URLs currently identifying any active sessions hosted byhost the answerer.connection. 2. Listen for a connection from the peer. 3. Construct an SDP answeroffer as described in Section 6, mappingincluding the new sessionlist of allowed IM payload formats in the accept-types attribute. The offerer puts its local URL tointo the sessionpath attribute, insert a direction attribute with the value of "passive", and the count value copied fromas described in Section 6.4. This URL becomes the offer.offerer's local path. 4. Send the SDP offer using the normal processing for the signaling protocol. When the offerer receivesIf the SDP answer,answerer chooses to participate, it must determine whoMUST perform the following steps: 1. Parse the first URL from the offered path attribute. We will continuerefer to hostthis URL as the session.remote URL. The full path attribute value will be the answerer's remote path. If the answerpath only contained a direction attribute value of "active",single URL entry, then the offerer MUST continue as host. Ifremote URL and the remote path are identical. 2. Determine if it has any existing connection that is associated with a peer URL host part that matches that of the offer contained "active" or "both"remote URL, and with a transport protocol matching that from the answer contains "passive", then the offerer MUST allow the answerer to host the session.M-line. If one exists, the offerer chooses not to continue as host, it MUST perform the following steps: 1. Release resourcesanswerer SHOULD use it acquired in expectation of hostingfor the session, if any. 2. Determinenew session rather than establishing a new connection. [Open Issue: Should we discuss situations when an endpoint may want to intentially not share a connection?] 3. If no appropriate connection already exists, determine the host address and port from the session URL of the answer,remote URL, following the procedures in section Section 7.1 3. Connect to the host address7.1, and port,connect using the transport protocol from the M-line. 4. Construct a MSRP URL . This URL MUST resolve to the the answerer. This URL becomes the answerer's local URL. 5. Construct a VISIT request, which MUST contain the following information: 1. A S-URLAn To header field containing the sessionremote URL. 2. A From containing the answerer's local URL. 3. A TR-ID header field containing a unique transaction ID. 3.4. A size field containing size of the message subsequent to the start-line. 5.6. Send the request and wait for a response 6.7. If either the connection attempt orthe VISIT transaction fail, acknowledgesucceeds, send a SDP answer via the answer, then initiatesignaling protocol, according to the tear-downfollowing rules: 1. The C-line is copied unmodified from the offer. 2. The M-Line contains a dummy port value, the protocol field from the original offer. 3. The accept-types attribute contains the SEND payload media types that the answerer is willing to accept. The accept-types attribute in the answer MUST be either the same as that of the session usingoffer, or it MUST be a subset. 4. The path attribute contains the signaling protocol. 7.4.2answerer's local URL. 8. If the VISIT transaction fails, the answerer MUST reject the offer. 7.5.2 Handling VISIT requests An MSRP endpoint that is hosting a session will receive a VISIT request from the visiting endpoint. When an endpoint receives a VISIT request, it MUST perform the following procedures: 1. Check if state exists for a session with a local URL that matches the S-URLTo header field value of the VISIT request. If so, and if no visitor connectionprevious VISIT request has been associated with the session,received for that URL, then return a 200 response, and save state designatingassociating the URL in the From header field with the connection on which the request was received as the visitor leg of the session.. 2. If the sessionstate exists, and the visitor connectiona matching VISIT transaction has already been established,occured, return a 506 response and do not change session state in any way. 3. If no matching sessionstate exists, return a 481 request,response, and do not change session state in any way. 18.104.22.168.3 Sending Instant Messages on a Session Once a MSRP session has been established, either endpoint may send instant messages to its peer using the SEND method. When an endpoint wishes to do so, it MUST construct a SEND request according to the following process: 1. Insert a To header field containing the remote path. Note that this is the full remote path, not just the remote URL. 2. Insert a From header field containing the local URL. 3. Insert the message payload in the body, and the media type in the Content-Type header field. The media type MUST match one of the types in the format list negotiated in the SDP exchange. If a "*" was present in the accept-types attribute, then the media type SHOULD match one of the explicitly listed entries, but MAY be any other arbitrary value. 2.4. Set the TR-ID header field to a unique value. 3.5. Send the request on the connection associated with the session. 4.6. If a 2xx response code is received, the transaction was successful. 5.7. If a 415 response is received, this indicates the recipient is unable or unwilling to process the media type. The sender SHOULD NOT attempt to send that particular media type again in the context of this session. 6.8. If any other response code is received, or if the transaction times out, the endpoint SHOULD assume the session has failed, and initiate tear-down,either endingtear down the session, or attempt to re-establish the session by sending an updated SDP offer proposing a new connection. If a new connection is established, the endpoint MAY choose to resend the content on the new connection. Open Issue: Do we need to create a duplicate mechanism to suppress duplicate messages when a new connection is established in this fashion? mechanism? List consensus seems to indicate we do. We may need to specify that the tr-id space spans a sequence of connections if they are associated with same stream, and of course, specify what it means for a stream to span connections. When an endpoint receives a SEND request, it MUST perform the following steps. 1. Check that it has state for a session with a local URL matching the To value. If no matching session exists, return a 481 response. 2. Determine that it understands the media type in the body, if any exists. 2.3. If it does, return a 200 response and render the message to the user. The method of rendering is a matter of local policy. If the message contained no body at all, the endpoint should quietly ingore it. 3.4. If it does not understand the media type, return a 415 response. The endpoint MUST NOT return a 415 response for any media type for which it indicated support in the SDP exchange. 22.214.171.124.4 Ending a Session When either endpoint in an MSRP session wishes to end the session, it first signals its intent using the normal processing for the signaling protocol. For example, in SIP, it would send a BYE request to the peer. After agreeing to end the session, the host endpoint MUST release any resources acquired as part of the session. The hostEach peer MUST destroy all local state for the session. This involves completely removing the state entry for thisthe session and invalidating the session URL. Since these host actions completely destroyIf no other sessions are using the session state atconnection, the hosting device,endpoint that opened it SHOULD tear it down. However, the visitor is not required to take further action beyond cleaning up any local state.passive party MAY tear down an unused connection after a locally configured timeout period. When an endpoint chooses to close a session, it may have SEND transactions outstanding. For example, it may have send SEND requests to which it has not yet received a response, or it may have received SEND requests that to which it has not responded. Once an endpoint has decided to close the connection, it SHOULD wait for such outstanding transactions to complete. It SHOULD NOT generate any new SEND transactions, and it MAY choose not to respond to any new SEND requests that are received after it decides to close the session. It SHOULD not respond to any new messages that arrive after it signals its intent to close the session. When an endpoint is signaled of its peer's intent to close a session, it SHOULD NOT initiate any more SEND requests. It SHOULD wait for any outstanding transactions that it initiated to complete, and it SHOULD attempt respond to any open SEND transactions received prior to being signaled. It is not possible to completely eliminate the chance of a session terminating with incomplete SEND transactions. When this occurs, the endpoint SHOULD clearly inform the user that the messages may not have been delivered. 126.96.36.199.5 Managing Session State and Connections A MSRP session is represented by state at the host device. As mention previously, session state iseach endpoint, identified by an MSRP URL.the local URL and remote path. An active session also has an associated network connection. When session state is destroyed for any reason, the hosting device SHOULD drop the connection.If the connection fails for any reason, the session hosting device MUST invalidate the session state.state for all sessions using the connection. Once a connection is dropped, theany associated session state MUST NOT be reused. If an endpoint wishes to continue to communicate after detecting a connection failure, it MAY initiate a new SDP exchange to negotiate a new session URL. Otherwise, it SHOULD attempt to tear down the session using the rules of the signaling protocol. It would be nice to allow sessions to be recovered after a connection failure, perhaps by allowing the active endpoint to reconnect, and send a new VISIT request. However, this approach creates a race condition between the time that the hosting device notices the failed connection, and the time that the endpoint tries to recover the session. If the endpoint attempts to reconnect prior to the hosting device noticing the failure, the hosting device will interpret the recovery attempt as a conflict. The only way around this would be to force the hosting device to do a liveness check on the original connection, which would create a lot of complexity and overhead that do not seem to be worth the trouble. 7.5Open Issue: Is this still an issue with shared connections? 7.6 Delivery Status Notifications To Do. 7.7 Method Descriptions This section summarizes the purpose of each MSRP method. All MSRP messages MUST contain the TR-IDTR-ID, From, and To header fields. All messages MUST contain a length field in the start line that indicates the overall length of the request, including any body, but not including the start line itself. Additional requirements exist depending on the individual method. 188.8.131.52.1 SEND The SEND method is used by both the host and visitor endpoints to send instant messages to its peer endpoint. A SEND request MUST contain a To header field containing the sender's remote path, and a From header field containing the sender's local URL. SEND requests SHOULD contain a MIME body part. The body MUST be of a media type included in the format list negotiated in the SDP exchange. If a body is present, the request MUST contain a Content-Type header field identifying the media type of the body. To Do: We plan to expand the use of MIME headers to allow any standard MIME header in a SEND request. This is not included in this version for the sake of getting the draft out as soon as possible, but will follow soon. 184.108.40.206.2 VISIT The visiting endpoint uses the VISIT method to associate a network connection with the session state at the hosting device. TheA VISIT request MUST containinclude a S-URLTo header matchingincluding the sessionsender's remote URL, and a From header field containing the sender's local URL. 7.67.8 Response Code Descriptions This section summarizes the various response codes. Except where noted, all responses MUST contain a TR-ID header field matching the TR-ID header field of the associatedoriginal request, and To and From headers matching those of the original request. 220.127.116.11.1 200 The 200 response code indicates a successful transaction. 18.104.22.168.2 400 A 400 response indicates a request was unintelligible. 22.214.171.124.3 415 A 415 response indicates the SEND request contained a MIME content-type that is not understood by the receiver. 126.96.36.199.4 426 A 426 response indicates that the request is only allowed over TLS protected connections. 188.8.131.52.5 481 A 481 response indicates that no session exists for the connection. 184.108.40.206.6 506 A 506 response indicates that a VISIT request occurred in which the S-URLTo header indicates a sessionlocal path that is already associated with another connection. A 506 response MUST NOT be returned in response to any method other than VISIT. 7.77.9 Header Field Descriptions This section summarizes the various header fields. MSRP header fields are single valued; that is, they MUST NOT occur more than once in a particular request or response. 220.127.116.11.1 TR-ID The TR-ID header field contains a transaction identifier used to map a response to the corresponding request. A TR-ID value MUST be unique among all values used by a given endpoint inside a given session. MSRP elements MUST NOT assume any additional semantics for TR-ID. 18.104.22.168.2 To The To header field is used to indicate the sender's remote path. All MSRP requests MUST contain a To header field. 7.9.3 From The From header field is used to indicate the sender's local URL. All MSRP requests MUST contain a From header field. 7.9.4 Content-Type The Content-Type header field is used to indicate the MIME media type of the body. Content-Type MUST be present if a body is present. To Do: The work group has agreed to allow the use of any standard MIME header. This is not reflected in this version, but will be in a shortly forthcoming one. 7.7.3 S-URL The S-URL header field is used to identify the session. The S-URI header field must be included in VISIT requests.8. Example This section shows an example message flow for the most common scenario. The example assumes SIP is used to transport the SDP exchange. Details of the SIP messages and SIP proxy infrastructure are omitted for the sake of brevity. In the example, assume the offerer is sip:email@example.com and the answerer is sip:firstname.lastname@example.org. In any given MSRP message, an "xx" in the length field indicates the actual length of the rest of the message. Alice Bob | | | | |(1) (SIP) INVITE | |----------------------->| |(2) (MSRP) VISIT | |<-----------------------| |(3) (MSRP) 200 OK | |----------------------->| |(4) (SIP) 200 OK | |<-----------------------| |(5) (SIP) ACK | |----------------------->| |(6) (MSRP) SEND | |----------------------->| |(7) (MSRP) 200 OK | |<-----------------------| |(8) (MSRP) SEND | |<-----------------------| |(9) (MSRP) 200 OK | |----------------------->| |(10) (SIP) BYE | |----------------------->| |(11) (SIP) 200 OK | |<-----------------------| | | | | 1. Alice constructs a sessionlocal URL of msrp:// alicepc.atlanta.com:7777/iau39msrp://alicepc.atlanta.com:7777/ iau39 and listens for a connection on TCP port 7777. Alice->Bob (SIP): INVITE sip:email@example.com v=0 o=alice 2890844557 2890844559 IN IP4 host.anywhere.com s= c=IN IP4 fillername t=0 0 m=message 9999 msrp/tcp * a=accept-types:text/plain a=direction:both 0 a=session:msrp://alicepc.atlanta.com:7777/iau39a=path:msrp://alicepc.atlanta.com:7777/iau39 2. Bob opens a TCP connection to alicepc.atlanta.com:7777: Bob->Alice (MSRP): MSRP xx VISIT S-URL:msrp://alicepc.atlanta.com:7777/iau39 Tr-ID: sie09sTo:msrp://alicepc.atlanta.com:7777/iau39 From:msrp://bob.atlanta.com:8888/9di4ea Tr-ID:sie09s 3. Alice->Bob (MSRP): MSRP xx 200 OK Tr-ID: sie09sTo:msrp://alicepc.atlanta.com:7777/iau39 From:msrp://bob.atlanta.com:8888/9di4ea Tr-ID:sie09s 4. Bob->Alice (SIP): 200 OK v=0 o=bob 2890844612 2890844616 IN IP4 host.anywhere.com s= c=IN IP4 ignorefield t=0 0 m=message 9999 msrp/tcp * a=accept-types:text/plain a=direction:active 0a=path:msrp://bob.atlanta.com:8888/9di4ea 5. Alice->Bob (SIP): ACK 6. Alice->Bob (MSRP): MSRP xx SEND To:msrp://bob.atlanta.com:8888/9di4ea From:msrp://alicepc.atlanta.com:7777/iau39 TR-ID: 123 Content-Type: "text/plain" Hi, I'm Alice! 7. Bob->Alice (MSRP): MSRP xx 200 OK To:msrp://bob.atlanta.com:8888/9di4ea From:msrp://alicepc.atlanta.com:7777/iau39 TR-ID: 123 8. Bob->Alice (MSRP): MSRP xx SEND To:msrp://alice.atlanta.com:7777/iau39 From:msrp://bob.atlanta.com:8888/9di4ea TR-ID: 456 Content-Type: "text/plain" Hi, Alice! I'm Bob! 9. Alice->Bob (MSRP): MSRP xx 200 OK To:msrp://alice.atlanta.com:7777/iau39 From:msrp://bob.atlanta.com:8888/9di4ea TR-ID: 456 10. Alice->Bob (SIP): BYE Alice invalidates local session and drops connection.state. 11. Bob invalidates local state for the session. Bob->Alice (SIP): 200 OK 9. IANA Considerations 9.1 MSRP Port MSRP uses TCP port XYX, to be determined by IANA after this document is approved for publication. Usage of this value is described in Section 7.1 9.2 MSRP URL Schemes This document defines the URL schemes of "msrp" and "msrps". 9.2.1 Syntax See Section 7.1. 9.2.2 Character Encoding See Section 7.1. 9.2.3 Intended Usage See Section 7.1. 9.2.4 Protocols The Message Session Relay Protocol (MSRP). 9.2.5 Security Considerations See Section 10. 9.2.6 Relevant Publications RFCXXXX [Note to RFC Editor: Please replace RFCXXXX in the above paragraph with the actual number assigned to this document. 9.3 SDP Parameters This document registers the following SDP parameters in the sdp-parameters registry: 9.3.1 DirectionAccept Types Attribute-name: directionaccept-types Long-form Attribute Name DirectionAcceptable MIME Types Type: Media level Subject to Charset Attribute No Purpose and Appropriate Values See Section 6.2. 9.3.2 AcceptWrapped Types Attribute-name: accept-typesaccept-wrapped-types Long-form Attribute Name Acceptable MIME Types Inside Wrappers Type: Media level Subject to Charset Attribute No Purpose and Appropriate Values See Section 6.3. 9.3.3 Wrapped TypesPath Attribute-name: accept-wrapped-typespath Long-form Attribute Name Acceptable MIME Types Inside WrappersMSRP URL Path Type: Media level Subject to Charset Attribute No Purpose and Appropriate Values See Section 6.4. 10. Security Considerations There are a number of security considerations for MSRP, some of which are mentioned elsewhere in this document. This section discusses those further, and introduces some new ones. 10.1 TLS and the MSRPS Scheme All MSRP devices must support TLS, with at least the TLS_RSA_WITH_AES_128_CBC_SHA  cipher suite. Other cipher suites MAY be supported. MSRP does not define a separate TCP port for TLS connections. This means that all MSRP server devices, that is, all devices that listen for TCP connections, MUST be prepared to handle both TLS and plain text connections on the same port. When a device accepts a TCP connection, it MUST watch for the TLS handshake messages to determine if a particular connection uses TLS. If the first data received is not part of a start TLS request, the device ceases to watch for the TLS handshake until it reads the entire message. Once the message has been completely received, the device resumes watching for the start TLS message. AnAny MSRP device MAY refuse to accept a given request over a non-TLS connection by returning a 426 response. MSRP devices acting in the role of TCP client MAY perform a TLS handshake at any time, as long as the request occurs between MSRP messages. The endpoint MUST NOT send a start TLS request in the middle of an MSRP message. The working group considered only requiring the endpoint to watch for a TLS handshake at the beginning of the session. However, the endpoint should be able to determine if a new message is a start TLS request or an MSRP request by only reading ahead three bytes. Therefore, the working group chose to allow a session to switch to TLS in mid-stream, as long as the switch occurs between MRSP messages. The MSRPS URI scheme indicates that all hops in an MSRP session MUST be protected with TLS. Since this document does not specify the use of intermidiary devices, then MSRPS support is trivially equivilant to TLS support. However, if intermediaries do exist, either as described in an MSRP extension document, or as some sort of proprietary devices, they MUST ensure protection at all hops for an MSRPS URL. A VISIT request for an MSRPS URL MUST be sent over a TLS protected connection. If a hosting device receives a VISIT request for an MSRPS URL over an unprotected connection, it MUST reject the request with a 426 response. 10.1.1 Sensitivity of the Session URL The URL ofsent in the SDP offer for a MSRP session is used by the visiting endpointanswerer to identify itself to the hosting device. If an attacker were able to acquire the session URL, either by guessing it or by eavesdropping, there is a window of opportunity in which the attacker could hijack the session by sending a VISIT request to the host device before the true visiting endpoint. Because of this sensitivity, the session URL SHOULD be constructed in a way to make it difficult to guess, and should be sufficiently random so that it is unlikely to be reused. All mechanisms used to transport the sessionthis URL to the visitor and back to the hostanswerer SHOULD be protected from eavesdroppers and man-in-the-middle attacks. Therefore ana MSRP device MUST support the use of TLS for at least the VISIT request, which by extension indicates the endpoint MUST support the use of TLS for all MSRP messages. Further, MSRP connections SHOULD actually be protected with TLS. Further, an MSRP endpoint MUST be capable of using the security features of the signaling protocol in order to protect the SDP exchange and SHOULD actually use them on all such exchanges. End-to-end protection schemes SHOULD be preferred over hop-by-hop schemes for protection of the SDP exchange. 10.1.2 End to End Protection of IMs Instant messages can contain very sensitive information. As a result, as specified in RFC 2779 , instant messaging protocols need to provide for encryption, integrity and authentication of instant messages. Therefore MSRP endpoints MUST support the end-to-end encryption and integrity of bodies sent via SEND requests using Secure MIME (S/MIME) . Note that while each protected body could use separate keying material, this is inefficient in that it requires an independent public key operation for each message. Endpoints wishing to invoke end-to-end protection of message sessions SHOULD exchange symmetric keys in SDP k-lines, and use secret key encryption on for each MSRP message. When symmetric keys are present in the SDP, the offer-answer exchange MUST be protected from eavesdropping and tampering using the appropriate facilities of the signaling protocol. For example, if the signaling protocol is SIP, the SDP exchange MUST be protected using S/MIME. 10.1.3 CPIM compatibility MSRP sessions may be gatewayed to other CPIM compatible protocols. If this occurs, the gateway MUST maintain session state, and MUST translate between the MSRP session semantics and CPIM semantics that do not include a concept of sessions. Furthermore, when one endpoint of the session is a CPIM gateway, instant messages SHOULD be wrapped in "message/cpim"  bodies. Such a gateway MUST include "message/cpim" as the first entry in its SDP accept-types attribute. MSRP endpoints sending instant messages to a peer that has included 'message/cpim" as the first entry in the accept-types attribute SHOULD encapsulate all instant message bodies in "message/ cpim" wrappers. All MSRP endpoints MUST support the message/cpim type, and SHOULD support the S/MIME features of that format. 10.1.4 PKI Considerations Several aspects of MSRP will benefit from being used in the context of a public key infrastructure. For example, the MSRPS scheme allows, and even encourages, TLS connections between endpoint devices. And while MSRP allows for a symmetric session key to protect all messages in a session, it is most likely that session key itself would be exchanged in a signaling protocol such as SIP. Since that key is extremely sensitive, its exchange would also need to be protected. In SIP, the preferred mechanism for this would be S/MIME, which would also benefit from a PKI. However, all of these features may be used without PKI. Each endpoint could instead use self signed certificates. This will, of course, be less convenient than with a PKI, in that there would be no certificate authority to act as a trusted introducer. Peers would be required to exchange certificates prior to securely communicating. Since, at least for the immediate future, any given MSRP implementation is likely to communicate with at least some peers that do not have a PKI available, MSRP implementations SHOULD support the use of self-signed certificates, and SHOULD support the ability to configure lists of trusted certificates. To Do: Add text discussion the use of TLS certificates in more detail. 11. Changes from Previous Draft Versions This section to be deleted prior to publication as an RFC 11.1 draft-ietf-simple-message-sessions-04 Removed the direction attribute. Rather than using a comedia styled direction negotiation, we just state that the answerer opens any needed connection. Changed the use of session URLs. Instead of a single session URL, each endpoint is identified by a distinct URL. MSRP requests will put the destination URL in a To header, and the sender URL in a From header. Changed the SDP exchange of MSRP URLs to handle the URL for each endpoint. Further, changed the SDP attribute to support a list of URLs in each direction. This may be used with relays to exchange paths, rather than single URLs. MSRP endpoints must be able to intelligently process such a list if received. This document does not, however, describe how to generate such a list. Added skeleton sections for Delivery Status Notification handling and negotiation. 11.2 draft-ietf-simple-message-sessions-03 Removed all specification of relays, and all features specific to the use of relays. The working group has chosen to move relay work into a separate effort, in order to advance the base specification. (The MSRP acronym is unchanged for the sake of convenience.) This included removal of the BIND method, all response codes specific to BIND, Digest Authentication, and the inactivity timeout. Removed text indicating that an endpoint could retry failed requests on the same connection. Rather, the endpoint should consider the connection dead, and either signal a reconnection or end the session. Added text describing subsequent SDP exchanges. Added mandatory "count" parameter to the direction attribute to allow explicit signaling of the need to reconnect. Added text to describe the use of send and receive only indicators in SDP for one-way transfer of large content. Added text requiring unique port field values if multiple M-line's exist. Corrected a number of editorial mistakes. 11.211.3 draft-ietf-simple-message-sessions-02 Moved all content type negotiation from the "m"-line format list into "a"-line attributes. Added the accept-types attribute. This is due to the fact that the sdp format-list syntax is not conducive to encoding MIME content types values. Added "other-method" construction to the message syntax to allow for extensible methods. Consolidated all syntax definitions into the same section. Cleaned up ABNF for digest challenge and response syntax. Changed the session inactivity timeout to 12 minutes. Required support for the SHA1 alogorithm. Required support for the message/cpim format. Fixed lots of editorial issues. Documented a number of open issues from recent list discussions. 11.311.4 draft-ietf-simple-message-sessions-01 Abstract rewritten. Added architectural considerations section. The m-line format list now only describes the root body part for a request. Contained body part types may be described in the "accept-wrapped-types" a-line attribute. Added a standard dummy value for the m-line port field. Clarified that a zero in this field has normal SDP meaning. Clarified that an endpoint is globally configured as to whether or not to use a relay. There is no relay discovery mechanism intrinsic to MSRP. Changed digest algorithm to SHA1. Added TR-ID and S-URI to the hash for digest authentication. CMS usage replaced with S/MIME. TLS and MSRPS usage clarified. Session state timeout is now based on SEND activity, rather than BIND and VISIT refreshes. Default port added. Added sequence diagrams to the example message flows. Added discussion of self-signed certificates in the security considerations section. 11.411.5 draft-ietf-simple-message-sessions-00 Name changed to reflect status as a work group item. This version no longer supports the use of multiple sessions across a single TCP session. This has several related changes: There is now a single session URI, rather than a separate one for each endpoint. The session URI is not required to be in requests other than BIND and VISIT, as the session can be determined based on the connection on which it arrives. BIND and VISIT now create soft state, eliminating the need for the RELEASE and LEAVE methods. The MSRP URL format was changed to better reflect generic URL standards. URL comparison and resolution rules were added. SRV usage added. Determination of host and visitor roles now uses a direction attribute much like the one used in COMEDIA. Format list negotiation expanded to allow a "prefer these formats but try anything" semantic Clarified handling of direction notification failures. Clarified signaling associated with session failure due to dropped connections. Clarified security related motivations for MSRP. Removed MIKEY dependency for session key exchange. Simple usage of k-lines in SDP, where the SDP exchange is protected end-to-end seems sufficient. 11.511.6 draft-campbell-simple-im-sessions-01 Version 01 is a significant re-write. References to COMEDIA were removed, as it was determined that COMEDIA would not allow connections to be used bidirectional in the presence of NATs. Significantly more discussion of a concrete mechanism has been added to make up for no longer using COMEDIA. Additionally, this draft and draft-campbell-cpimmsg-sessions (which would have also changed drastically) have now been combined into this single draft. 12. Contributors The following people contributed substantially to this ongoing effort: Rohan Mahy Allison Mankin Jon Peterson Brian Rosen Dean Willis Adam Roach Cullen Jennings Aki Niemi Hisham Khartabil Pekka Pessi Chris Boulton Normative References  Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.  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.  Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URL): Generic Syntax", RFC 2396, August 1998.  Atkins, D. and G. Klyne, "Common Presence and Instant Messaging Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in progress), January 2003.  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.  Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.  Chown, P., ""Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.  Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. Informational References  Campbell, B. and J. Rosenberg, "Session Initiation Protocol Extension for Instant Messaging", RFC 3428, September 2002.  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.  Mahy, R., Campbell, B., Sparks, R., Rosenberg, J., Petrie, D. and A. Johnston, "A Multi-party Application Framework for SIP", draft-ietf-sipping-cc-framework-02 (work in progress), May 2003.  Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo, "Best Current Practices for Third Party Call Control in the Session Initiation Protocol", draft-ietf-sipping-3pcc-04 (work in progress), June 2003.  Sparks, R. and A. Johnston, "Session Initiation Protocol Call Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in progress), February 2003.  Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.  Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323 , November 2002.  Peterson, J., "A Common Profile for Instant Messaging (CPIM)", draft-ietf-impp-im-04 (work in progress), August 2003.  Yon, D., "Connection-Oriented Media Transport in SDP", draft-ietf-mmusic-sdp-comedia-05 (work in progress), March 2003. Authors' Addresses Ben Campbell dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 EMail: firstname.lastname@example.org Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 EMail: email@example.com Robert Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 EMail: firstname.lastname@example.org Paul Kyzivat Cisco Systems Mail Stop LWL3/12/2 900 Chelmsford St. Lowell, MA 01851 EMail: email@example.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.