Working GroupWG B. Campbell (Ed.)Campbell, Ed. Internet-Draft dynamicsoftExpires: November 15, 2004 May 17,January 16, 2005 R. Mahy C. Jennings Cisco Systems, Inc. July 18, 2004 The Message Session Relay Protocol draft-ietf-simple-message-sessions-06draft-ietf-simple-message-sessions-07.txt Status of this Memo This document is an Internet-DraftBy submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and isany of which I become aware will be disclosed, in full conformanceaccordance with all provisions of Section 10 of RFC2026.RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 15, 2004.January 16, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes the Message Session Relay Protocol (MSRP), a mechanismprotocol for transmitting a series of Instant Messages withinrelated instant messages in the context of a session. MSRPMessage sessions are managed using the Session Description Protocol (SDP) offer/answer model carried bytreated like any other media stream when setup via a signalingrendezvous or session setup protocol such as the Session Initiation Protocol (SIP). Table of Contents 1. IntroductionConventions . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation for Session-mode Messaging .Introduction and Background . . . . . . . . . . 4 3. Scope of this Document. . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . 5 4. Protocol Overview. . . . . . . . 5 4. Key Concepts . . . . . . . . . . . . . 6 5. SDP Offer-Answer Exchanges for MSRP Sessions. . . . . . . . 7 5.1 Use of the SDP M-line. . . 8 4.1 MSRP Framing and Message Chunking . . . . . . . . . . . . 8 4.2 MSRP Addressing . . . 7 5.2 The Accept Types Attribute. . . . . . . . . . . . . . . . 7 5.3 MIME Wrappers. . 11 4.3 MSRP Transaction and Report Model . . . . . . . . . . . . 11 4.4 MSRP Connection Model . . . . . . . . 8 5.4 URL Negotiations. . . . . . . . . . 12 5. MSRP URLs . . . . . . . . . . . 9 5.5 Path Attributes with Multiple URLs. . . . . . . . . . . . 10 5.6 Updated SDP Offers. . 14 5.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . 11 5.7 Example SDP Exchange. 15 5.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 16 6. Method-Specific Behavior . . 11 5.8 Connection Negotiation. . . . . . . . . . . . . . . . 16 6.1 Constructing Requests . . 12 6. The Message Session Relay Protocol. . . . . . . . . . . . . 12 6.1 MSRP URLs. . . 16 6.1.1 Delivering SEND requests . . . . . . . . . . . . . . . 17 6.1.2 Sending REPORT requests . . . . . . 12 6.1.1 MSRP URL Comparison. . . . . . . . . 19 6.1.3 Failure REPORT Generation . . . . . . . . 13 6.1.2 Resolving MSRP Host Device. . . . . . 19 6.2 Constructing Responses . . . . . . . . 14 6.2 Connection Direction. . . . . . . . . . 20 6.3 Receiving Requests . . . . . . . . . 14 6.3 MSRP Messages. . . . . . . . . . . 21 6.3.1 Receiving SEND requests . . . . . . . . . . . 15 6.3.1 Message Framing. . . . 21 6.3.2 Receiving REPORT requests . . . . . . . . . . . . . . 22 7. Using MSRP with SIP . 17 6.3.2 Message Examples. . . . . . . . . . . . . . . . . . . 18 6.422 7.1 SDP Offer-Answer Exchanges for MSRP Transactions . .Sessions . . . . . . . 22 7.1.1 URL Negotiations . . . . . . . . . . . 19 6.5 MSRP Sessions . . . .. . . . . . . . 25 7.1.2 Path Attributes with Multiple URLs . . . . . . . . . . 19 6.5.1 Initiating an MSRP session26 7.1.3 Updated SDP Offers . . . . . . . . . . . . . . 19 6.5.2 Handling the initial request. . . . 27 7.1.4 Example SDP Exchange . . . . . . . . . 21 6.5.3 Sending Instant Messages on a Session. . . . . . . . 21 6.5.4 Ending a Session27 7.1.5 Connection Negotiation . . . . . . . . . . . . . . . . 28 7.2 MSRP User Experience with SIP . . . 23 6.5.5 Managing Session State and Connections. . . . . . . . 23 6.6 Delivery Status Notification. . . 28 8. DSN payloads in MSRP REPORT Requests . . . . . . . . . . . . 24 6.6.1 Endpoint28 8.1 Per-Message DSN Request . .header usage . . . . . . . . . . . . . . . 24 6.6.228 8.2 Per-Recipient DSN generation . . . . . . . . . . . . .header usage . . . . . . . 25 6.6.3 Receiving positive DSN. . . . . . . 29 8.3 original-envelope-id usage . . . . . . . . . 26 6.6.4 Receiving negative DSN. . . . . . . 29 8.4 reporting-mta . . . . . . . . . 26 6.6.5 DSN headers in MSRP. . . . . . . . . . . . . 29 8.5 final-recipient . . . . 26 6.7 Message Fragmentation. . . . . . . . . . . . . . . . . 29 8.6 action . 28 6.7.1 MSRP Usage of message/byteranges. . . . . . . . . . . 28 6.8 Method Descriptions. . . . . . . . . . . . . . 30 8.7 status . . . . . 29 6.8.1 SEND. . . . . . . . . . . . . . . . . . . . . 30 9. Formal Syntax . . . . 29 6.8.2 VISIT. . . . . . . . . . . . . . . . . . . 30 10. Response Code Descriptions . . . . . 29 6.8.3 REPORT. . . . . . . . . . . . 32 10.1 200 . . . . . . . . . . . . 30 6.9 Response Code Descriptions. . . . . . . . . . . . . . 33 10.2 400 . . 30 6.9.1 200. . . . . . . . . . . . . . . . . . . . . . . . 33 10.3 403 . 30 6.9.2 400. . . . . . . . . . . . . . . . . . . . . . . . . 30 6.9.333 10.4 415 . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.9.4. 33 10.5 426 . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.9.5. 33 10.6 481 . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.9.6. 33 10.7 506 . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.10 Header Field Descriptions. 33 11. Examples . . . . . . . . . . . . . . 30 6.10.1 TR-ID. . . . . . . . . . . . 33 11.1 Basic IM session . . . . . . . . . . . 31 6.10.2 Message-ID. . . . . . . . . 33 11.2 Chunked Message . . . . . . . . . . . . 31 6.10.3 To-Path. . . . . . . . 36 11.3 System Message . . . . . . . . . . . . . . . 31 6.10.4 From-Path. . . . . . 36 11.4 Positive Report . . . . . . . . . . . . . . . 31 6.10.5 Boundary. . . . . 37 11.5 Forked IM . . . . . . . . . . . . . . . . . 31 6.10.6 Closing. . . . . . 37 12. Extensibility . . . . . . . . . . . . . . . . 31 6.10.7 Content-Type. . . . . . . 40 13. CPIM compatibility . . . . . . . . . . . . . 32 7. Example. . . . . . . . 40 14. Security Considerations . . . . . . . . . . . . . . . . . . 32 8.40 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34 8.142 15.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 34 8.242 15.2 MSRP URL SchemaSchemes . . . . . . . . . . . . . . . . . . . . 42 15.3 SDP Parameters . 34 8.2.1 Syntax. . . . . . . . . . . . . . . . . . . . 43 15.3.1 Accept Types . . . . 34 8.2.2 Character Encoding. . . . . . . . . . . . . . . . 43 15.3.2 Wrapped Types . . 34 8.2.3 Intended Usage. . . . . . . . . . . . . . . . . 43 15.3.3 Path . . . 35 8.2.4 Protocols. . . . . . . . . . . . . . . . . . . . . 43 15.4 IANA registration forms for DSN types . 35 8.2.5 Security Considerations. . . . . . . . 43 15.4.1 IANA registration form for address-type . . . . . . 43 15.4.2 IANA registration form for MTA-name-type . 35 8.2.6 Relevant Publications. . . . . 44 16. Change History . . . . . . . . . . . 35 8.3 SDP Parameters. . . . . . . . . . . . 44 16.1 draft-ietf-simple-message-sessions-07 . . . . . . . . . 44 16.2 draft-ietf-simple-message-sessions-06 . 35 8.3.1 Accept Types. . . . . . . . 44 16.3 draft-ietf-simple-message-sessions-05 . . . . . . . . . 45 16.4 draft-ietf-simple-message-sessions-04 . . . . 35 8.3.2 Wrapped Types. . . . . 45 16.5 draft-ietf-simple-message-sessions-03 . . . . . . . . . 45 16.6 draft-ietf-simple-message-sessions-02 . . . . . . 35 8.3.3 Path . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.4 IANA registration forms for DSN types . . . . . . . . . . 36 8.4.1 IANA registration form for address-type .. . . 46 16.7 draft-ietf-simple-message-sessions-01 . . . 36 8.4.2 IANA registration form for MTA-name-type. . . . . . 46 16.8 draft-ietf-simple-message-sessions-00 . 36 9. Security Considerations. . . . . . . . 47 16.9 draft-campbell-simple-im-sessions-01 . . . . . . . . . . 36 9.1 TLS47 17. Contributors and the MSRPS Scheme . . . . . . . . . . . . . . . . . 36 9.1.1 Sensitivity of Session URLs . . . . . . . . . . . . . 37 9.1.2 End to End Protection of IMs . . . . . . . . . . . . . 38 9.1.3 CPIM compatibility . . . . . . . . . . . . . . . . . . 38 9.1.4 PKI Considerations . . . . . . . . . . . . . . . . . . 38 10. Changes from Previous Draft Versions . . . . . . . . . . . . 39 10.1 draft-ietf-simple-message-sessions-06 . . . . . . . . . 39 10.2 draft-ietf-simple-message-sessions-05 . . . . . . . . . 39 10.3 draft-ietf-simple-message-sessions-04 . . . . . . . . . 40 10.4 draft-ietf-simple-message-sessions-03 . . . . . . . . . 40 10.5 draft-ietf-simple-message-sessions-02 . . . . . . .Acknowledgments . . 40 10.6 draft-ietf-simple-message-sessions-01. . . . . . . . . 41 10.7 draft-ietf-simple-message-sessions-00. . . 47 18. References . . . . . . 41 10.8 draft-campbell-simple-im-sessions-01. . . . . . . . . . 42 11. Contributors. . . . . . . . . 48 18.1 Normative References . . . . . . . . . . . . . . . 42 12. Acknowledgments. . . . 48 18.2 Informational References . . . . . . . . . . . . . . . . . 49 Authors' Addresses . 42 13. References. . . . . . . . . . . . . . . . . . . . 50 Intellectual Property and Copyright Statements . . . . . 42 13.1 Normative References. . . . . . . . . . . . . . . . . . . 42 13.2 Informational References . . . . . . . . . . . . . . . . . 43 Author's Address . . . . . . . . . . . . . . . . . . . . . . 44 Intellectual Property and Copyright Statements . . . . . . . 4552 1. IntroductionConventions 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 messagekey words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and another. There are also applications"OPTIONAL" in which it is useful for instant messagesthis document are to be formally associatedinterpreted as described in a session. For example, a user may wishRFC-2119 . This document consistently refers to joina "message" as a complete unit of MIME or text conference, participate in the conference forcontent. In some period of time, then leave the conference. This usagecases a message is analogous to regular media sessions that are typically initiated, managed,split and terminated using SIP. We commonly refer to this model as session-mode messaging. Onedelivered in more than one MSRP request. Each of the primary purposesthese portions of SIP and SDP (Section 5) isthe managementcomplete message is called a "chunk". 2. Introduction and Background A series of media sessions. Session-mode messagingrelated textual messages between two or more parties can be thought ofviewed as part of a mediasession like any other.with a definite start and end. This documentis in contrast to individual messages each sent completely independently. The SIMPLE Working Group describes the motivations for session-mode messaging, the Message Session Relay Protocol, and the usemessaging schemes that only track individual messages as "page-mode" messages, whereas messaging that is part of a "session" with a definite start and end is called session-mode messaging. Page-mode messaging is enabled in SIMPLE via the SDP offer/answer mechanism for managing MSRP session. 2. Motivation forSIP MESSAGE method . Session-mode Messaging Message sessions offer several advantages over page-mode messages. For message exchanges that include more thanmessaging has a smallnumber of message transactions, message sessions offer a way to removebenefits  over page-mode messaging load from intervening SIP proxies. For example, a minimal session setuphowever, such as explicit rendezvous, tighter integration with other media types, direct client-to-client operation, and tear-down requires one INVITE/ACK transaction,brokered privacy and one BYE transaction, forsecurity. This document defines 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 tosession-oriented instant message transport protocol (MSRP), whose sessions can be included 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 andan offer or answer  of a response. Any page-mode messagesession description (for example, SDP ). The exchange that involves more than 2 MESSAGE requests will generate moreis carried by some signaling protocol, such as SIP requests than. This allows a minimalcommunication user agent to offer a messaging session initiation sequence. Since MESSAGE is normally used outsideas one of a SIP dialog, these requests will typically traverse the entire proxy network betweenthe endpoints. Duepossible media types in a session. For instance, Alice may want to network congestion concerns,communicate with Bob. Alice doesn't know at the MESSAGE methodmoment whether Bob has significant limitations in message size,his phone or his IM client handy, but she's willing to use either. She sends an invitation to a prohibition against overlapping requests, etc. Much of this has been required because of perceived limitations insession to the congestion-avoidance featuresaddress 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 efficiencyrecord she has for secure message exchanges.Bob, sip:email@example.com. Her invitation offers both voice and an IM session. The SIP MESSAGE request inheritsservices at example.com forward the S/MIME features of SIP, allowing a messageinvitation 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 establishedBob at his currently registered clients. Bob accepts the time of session initiation.invitation at his IM client and they begin a threaded chat conversation. This key cansession model allows message sessions to be usedintegrated into advanced communications applications with little to protect each message that is part of the session. This requires only symmetric key operations for each subsequent IM, andno additional certificate exchanges are required after the initial exchange. The establishment ofprotocol development. For example, during the session key can be done using standard techniques that apply to voice and video, in additionabove chat session, Bob decides Alice really needs to instant messaging. Finally, SIP devices can treat message sessions like any other media sessions. Any SIP feature that canbe appliedtalking to other sorts of media sessionsCarol. Bob can equally apply to message sessions. For example, conferencing , third party call control , calltransfer , QoS integration , and privacy can all be appliedAlice to message sessions.Carol, introducing them into their own messaging session. 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 contextthen be easily integrated into call-center and dispatch environments utilizing third-party call control  and conferencing  applications. 3. Protocol Overview MSRP is establisheda text-based, connection-oriented protocol for exchanging arbitrary (binary) MIME content, especially instant messages. As a result, messaging session mechanisms can be designed with significantly less overhead. 3. Scope of this DocumentThis document describes the usesection is a non-normative overview of how MSRP between endpoints. It does not specify the use of intermediaries, nor doesworks and how it prohibit such use. We expect an extension to this specification to defineis used with SIP. MSRP intermediaries and their use. This document describessessions are typically arranged using SIP the usesame way a session of MSRP over TCP. MSRP may be used over other congestion-controlled protocols such as SCTP. However,audio or video media is setup. One SIP user agent (Alice) sends the specific bindings forother such protocols are outside the scope(Bob) a SIP invitation containing an offer session-description which includes a session of this document. 4. Protocol OverviewMSRP. 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. Itreceiving SIP user agent can operate inaccept the presence of many NAT and firewall environments, as it allows participants to positively associate message sessions with specific connections,invitation and does not depend upon connection source address,include an answer session-description which may be obscured by NATs. MSRP usesacknowledges the following primitives: SEND: Used to send message content from one endpoint to another. VISIT: Used by an endpoint to establish achoice of media. Alice's session association to the host endpoint. REPORT Used to carry MSRP message report/receipt information. Assume A isdescription contains an endpointMSRP URL that wishesdescribes where she is willing to establish a message session,receive MSRP requests from Bob, and B isvice-versa. (Note: Some lines in the endpoint invited by A. A invites Bexamples are removed for clarity and brevity.) Alice sends to participate inBob: INVITE sip:firstname.lastname@example.org SIP/2.0 To: <sip:email@example.com> From: <sip:firstname.lastname@example.org>;tag=786 Call-ID: 3413an89KU Content-Type: application/sdp c=IN IP4 10.1.1.1 m=message 9 msrp * a=accept-types:text/plain a=path:msrp://atlanta.example.com:7654/jshA7we;tcp Bob sends to Alice: SIP/2.0 200 OK To: <sip:email@example.com>;tag=087js From: <sip:firstname.lastname@example.org>;tag=786 Call-ID: 3413an89KU Content-Type: application/sdp c=IN IP4 10.2.2.2 m=message 9 msrp * a=accept-types:text/plain a=path:msrp://biloxi.example.com:12763/kjhd37s2s2;tcp Alice sends to Bob: ACK sip:email@example.com SIP/2.0 To: <sip:firstname.lastname@example.org>;tag=087js From: <sip:email@example.com>;tag=786 Call-ID: 3413an89KU MSRP defines two request types, or methods. SEND requests are used to deliver a complete message session by sending a URL. This URL is temporary, and must not duplicate any URL that A has offered for other active sessions. B then responds to the invitation withor a URLchunk (a portion of its own. This informs A that B has accepted the session, and will accept messages at that URL. A connects to B, and sendsa request to establish the session. A and B may now exchange messages using SENDcomplete message), while REPORT requests report on the connection. Each party targets such requests to the peer's URL.status of an earlier SEND request. When either party wishesAlice receives Bob's answer, she checks to end the session, it informs its peer using the appropriate mechanism of the chosen signaling protocol, such assee if she has an existing connection to Bob. If not, she opens a SIP BYE request. The endnew connection to end case looks something likeBob using the following. (Note thatURL he provided in the example showsSDP. Alice then delivers a logical flow only; syntax will come later in this document.) A->B (SDP): offer (msrp://A/123) B->A (SDP): answer(msrp://B/456) A->B (TCP) connect A->B (MSRP):SEND (msrp://B/456) B->A (MSRP): 200 OK B->A (MSRP):request to Bob with her initial message, and Bob replies indicating that Alice's request was received successfully. MSRP a786hjs2 SEND (msrp://A/123) A->B (MSRP):To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp Message-ID: 87652 Content-Type: text/plain Hey Bob, are you there? -------a786hjs2$ MSRP a786hjs2 200 OK 5. SDP Offer-Answer Exchanges for MSRP SessionsTo-Path: msrp://atlanta.example.com:7654/jshA7we;tcp From-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp Message-ID: 87652 -------a786hjs2$ Alice's request begins with the MSRP sessions will typically be initiated usingstart line, which contains a transaction identifier that is also used as a final boundary marker. Next she includes the Session Description Protocol (SDP)  offer-answer mechanism, carried in the Session Initiation Protocol (SIP)  or any other protocol supporting it. 5.1 Usepath of URLs to the SDP M-line The SDP "m"-line takesdestination in the following form: m=<media> <port> <protocol> <format list> For non-RTP media sessions, The media field specifiesTo-Path header, and her own URL in the top level MIME media type forFrom-Path header. In this typical case there is just one "hop", so there is only one URL in each path header field. She also includes a message ID which she can use to correlate responses and status reports with the session. For MSRP sessions,original message. Next she puts the media field MUST haveactual content. Finally she closes the value of "message". The port field is normally not used,request with an end line: seven hyphens, the transaction identifier / boundary marker and MAY be seta "$" to any value chosen byindicate this request contains the endpoint. A port field valueend of zero hasa complete message. If Alice wants to deliver a very large message, she can split the standard SDP meaning. Non-zero values MUST not be repeated in other MSRP m-linesmessage into chunks and deliver each chunk in the same SDP document.a separate SEND request. The protocol field is used onlymessage ID corresponds to designate MSRP. The underlying transport protocol is determined inthe MSRP URL, as described below. Therefore,whole message, so the protocol field MUST takereceiver can also use it to reassemble the value of "msrp". The format list listmessage and tell which chunks belong with which message. Chunking is ignored for MSRP.described in more detail in Section 4.1. Alice can also specify what type of reporting she would like in response to her request. If Alice requests positive acknowledgements, Bob sends a REPORT request to Alice confirming the delivery of her complete message. This is 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 containespecially useful if Alice sent a "*" character,series of SEND request containing chunks of a single message. More on requesting types of reports and nothing else. The port fielderrors is described in the M-lineSection 4.3. Alice and Bob generally choose their MSRP URLs in such a way that is not useddifficult to determineguess the portexact URL. Alice and Bob can reject requests to whichURLs they are not expecting to connect. Rather, the actual port is determined by theservice, and can correlate the MSRPspecific URL (Section 6.1) inwith the path attribute. However,probable sender. Alice and Bob can also use TLS  to provide channel security over this hop. To receive MSRP requests over a port value of zero hasTLS protected connection, Alice or Bob could advertise URLs with the normal SDP meaning. The following example illustrates an m-line"msrps" scheme instead of "msrp." This document specifies MSRP behavior only peer-to-peer session, that is, for a message session, where the endpointsingle hop. But is willing to accept root payloads of message/ cpim, plain text or HTML. The second two types could either be presented asdesigned with the root body, or could be contained within message/cpim bodies. m=message 9999 msrp * 5.2 The Accept Types Attributeexpectation that MSRP can carry any MIME encoded payload. Endpoints specify MIME content types that they are willing to receive inURLs for nodes on the accept types "a"-line attribute. This attribute hasfar side of gateways or relays. For this reason, a URL with the following syntax: accept-types = accept-types-label ":" format-list accept-types-label = "accept-types" format-list = format-entry *( SP format-entry) format-entry = (type "/" subtype) / ("*") type = token subtype = token SDP offers for MSRP sessions MUST include an accept-types attribute. SDP answers MUST also include"msrps" scheme makes no assertion about the attribute, which MUST contain eithersecurity properties of other hops, just the same list asnext hop. MSRP URLs are discussed in more detail in Section 5. An adjacent pair of busy MSRP nodes (for example two gateways) can easily have several sessions, and exchange traffic for several simultaneous users. The nodes can use existing connections to carry new traffic with the offer orsame destination host, port, transport protocol, and scheme. MSRP nodes can keep track of how many sessions are using a subsetparticular connection and close these connections when no sessions have used them for some period of that list. A "*" entrytime. Connection management is discussed in more detail in Section 4.4. 4. Key Concepts 4.1 MSRP Framing and Message Chunking Messages sent using MSRP can be very large and can be delivered in several SEND requests, where each SEND request contains one chunk of the accept-types attribute indicates that the sender may attempt to send messages with media typesoverall message. To support this, MSRP uses a boundary based framing mechanism. The header of an MSRP request contains a unique boundary string that have not been explicitly listed. If the receiveris ableused to processindicate the media type, it does so. If not, it will respond withend of the request. Following the boundary string at the end of the body data, there is a 415. Noteflag that all explicit entries SHOULD be considered preferred over any non-listed types. This featureindicates whether this is needed as, otherwise,the list of formatslast chunk of data for rich IM devices may be prohibitively large. The accept-types attribute may include container types, that is, mime formats that contain other types internally. If compound types are used, the types listed in the accept-types attribute may be used both as the root payload,this message or maywhether the message will be wrappedcontinued in a listed container type. (Note that the container type MUSTsubsequent chunk. There is also be listed in the accept-types attribute.) 5.3 MIME Wrappers The MIME content-typesa Byte-Range header in the accept-types attribute will often include container types; that is, typesrequest that contain other types.indicates the overall position of this chunk inside the complete message. For example, "message/cpim" or "multipart/mixed." Occasionally an endpoint will need to specify a MIME body type that can only be used if wrapped insidethe following snippet of two SEND requests demonstrates a listed container type. Endpoints MAY specify MIME typesmessage that are only allowed to be wrapped inside compound types using the "accept-wrapped-types" attribute in an SDP a-line. This attribute hascontains the following syntax: accept-wrapped-types = wrapped-types-label ":" format-list wrapped-types-label = "accept-wrapped-types" `text "abcdEFGH" being sent as two chunks. MSRP dkei38sd SEND Message-ID: 456 Byte-Range: 1-4/8 Content-Type: "text/plain" abcd -------dkei38sd+ MSRP dkei38ia SEND Message-ID: 456 Byte-Range: 5-8/8 Content-Type: "text/plain" EFGH -------dkei38ia$ The format-list element hasreceiver uses the identical syntax as defined forvalue of the accept-types attribute. The semantics for this attribute are identicalMessage-ID header to thosedetermine which of multiple chunks belong to 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 assame message. The Message-ID header MUST have the "root" typesame value for each chunk in the entire body. Since any type listed in accept-types may be used both as a root body,same message, and wrapped in other bodies, format entries froma sender MUST ensure that the m-line SHOULD NOT be repeated in this attribute. This approach does not allow for specifying distinct lists of acceptable wrapped typesmessage ID is unique for different typeseach of containers. If an endpoint understandsthe messages it sends within a MIME type inparticular session. The boundary marker that terminates the contextbody MUST be preceded by a CRLF that is not part of one wrapper, itthe body and then seven "-" (minus sign) characters. After the boundary marker, there MUST be a flag character that is assumed to understand it ineither a "$" (for the contextlast chunk of anythe message) or "+" (for chunks other acceptable wrappers, subject to any constraints defined bythan the wrapper types themselves. The approach of specifying typeslast). If the chunk represents the data that are only allowed insideforms the end of containers separately fromthe primary payload types allows an endpoint to forcemessage, the use of certain wrappers. For example,flag MUST be a CPIM gateway device may require all messages to"$", otherwise the flag MUST be wrapped inside message/cpim bodies, but may allow several content types insidea "+". The Byte-Range header value contains a starting value followed by a "-", an ending value followed by a "/", and finally the wrapper. Iftotal length. The starting value indicates the gateway were to specifyindex into the wrapped typesmessage where the first byte in the accept-types attribute, its peer could choose to use those types withoutcurrent chunk belongs. The index of the wrapper. 5.4 URL Negotiations Each endpointfirst octet in an MSRP session is identifiedthe complete message is ONE, not zero. The ending value indicates the location where the last octet belongs. The body MAY contain less data than is indicated by a URL. These URLs are negotiated inthe SDP exchange. Each SDP offer or answerend but it MUST NOT contain one ormore MSRP URL in a path attribute. This attribute hasoctets than indicated. The length indicates the following syntax: a=path ":" MSRP_URL *(SP MSRP_URL) where MSRP_URL is an MSRP or MSRPS URL as defined in Section 6.1. MSRP URLs includednumber of octets in an SDP offer or answer MUST include an explicit port number. A device usesthe URL to determine a host address and port when connecting, and to identifycomplete message. Both the target when sending messages. For MSRP sessions,ending value and length MAY have the address fieldvalue of "*" in some or all of the C-line ischunks, to indicate that they are not relevant, and MUST be ignored. The port field inspecified. If no Byte-Range header is present, the M-lineSEND request MUST be ignoredtreated as if non-zero. Zero values have the usual meaning for SDP. A device will further use the URL to determine the transport protocol, and whether to use TLS.there was a Byte-Range header present with a value of "1-*/*". This information is encoded in the URL scheme. Both offerer and answerer store the path values received from the peer. Forchunking mechanism allows a given endpoint,sender to interrupt a chunk part way through sending it by writing out the local URL isboundary termination and the URL"+" flag to indicate that the endpoint put into a SDP path attribute to represent itself. The peer URLend of this chunk is not the URL sent byend of the peercomplete message. The ability to represent itself. If the path attribute received frominterrupt 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 peer contains moresame connection. To insure fairness over a connection, senders MUST NOT send chunks with a body larger than 2048 octets unless they are prepared to interrupt them. A sender can use one URL, thenof the peer URLfollowing two strategies to satisfy this requirement. The sender is STRONGLY RECOMMENDED to send messages larger than 2048 octets using as few chunks as possible, interrupting chunks (at least 2048 octets long) when other traffic is waiting to use the rightmost, whilesame connection. Alternatively, the leftmost entry representssender MAY simply send chunks in 2048 octet increments until the adjacent hop. If only one entry is present, then it is bothfinal chunk. Note that the peer and adjacent URL. The remote path isformer strategy results in markedly more efficient use of the entire path attribute value receivedconnection. All MSRP nodes MUST be able to receive chunks of any size from 0 octets to the peer. The following example shows an SDP offer with a session URLmaximum number 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 * a=accept-types:text/plain a=path:msrp://a.example.com:7394/2s93i The rightmost URI inoctets they can receive for a complete message. Senders SHOULD NOT break messages into chunks smaller than 2048 octets, except for the path attributefinal chunk of a complete message. Receivers MUST identify the endpoint that generatednot assume the SDP document,chunks will be delivered in order or some other location wherethat endpoint wishes tothey will receive messages associatedall the chunks with "+" flags before they receive the session. It MUST MUSTchunk with the "$" flag. In certain cases of connection failure, it is possible for information to be a temporary URL assigned justduplicated. If chunks data is received that overlaps already received data for this particular session, and MUST NOT duplicate any URL in use for any other session in whichthe endpoint is currently participating. Further, it SHOULD be hardsame message, the last chunk received takes precedence (even though this may not have been the last chunk transmitted). For example, if bytes 1 to guess,100 was received and protected from eavesdroppers. Thisa chunk arrives that contains bytes 50 to 150, this second chunk will be discussed in more detail in Section 9. 5.5 Path Attributes with Multiple URLs As mentioned previously,overwrite bytes 50 to 100 of the data that had already been received. Although other schemes work, this document describes MSRPis the easiest for peer-to-peer scenarios, that is, when no relaysthe receiver and results in consistent behavior between clients. The seven "-" before the boundary are used. However, we expectused so that the receiver can search for the value "----", 32 bits at a separate documenttime to describefind the useprobable location of relays inthe near future. In orderboundary. This allows most processors to allow an MSRP device that only implementslocate the core specification to interoperate with devicesboundaries and copy the memory at the same rate that use relays, this document must includea few assumptions about how relays work. An endpoint that uses one or more relays will indicate that by puttingnormal memory copy could be done. This approach results in a URL for each devicesystem that is as fast as framing based on specifying the body length in the relay chain intoheaders of the SDP path attribute. The final entry would point torequest, but also allows for the endpoint itself. The other entries would indicate each proposed relay, in order.interruption of messages. The first entry would pointability to the first relay in the chain;interrupt messages is needed so that is, the relay to which the peer device, or a relay operation on its behalf, should connect. EndpointsTCP connections can be shared. Connection sharing is necessary for "fair" allocation of bandwidth in congestion situations and for allowing MSRP network elements that do not wish to inserthave a relay, including those that do not support relays at all, will put exactly one URL into the path attribute. Thisvery large number of concurrent connections to different users. 4.2 MSRP Addressing MSRP entities are addressed using URLs. The MSRP URL represents both the endpoint forschemes are defined in Section 5. The syntax of the session,To-Path and the connection point. While endpoints that implement only this specification will never introduceFrom-Path headers allow for a relay, they will needlist of URLs. This was done to be ableallow the protocol to interoperatework with other endpoints that do use relays. Therefore, they MUST be prepared to receive more than one URLgateways or relays defined in the SDPfuture, to provide a complete path attribute.to the end recipient. When an endpoint receives more thantwo MSRP nodes communicate directly they need only one URL in a path header, only the first entry is relevant for purposes of resolvingthe address and port,To-Path list and establishing the network connection, as it describes the first adjacent hop. If an endpoint puts more thanone URL in a path attribute, the final URL inthe path (the peer URL) attributeFrom-Path list. 4.3 MSRP Transaction and Report Model A sender sends MSRP requests to a receiver. The receiver MUST exhibitquickly accept or reject the uniqueness properties described above. Uniqueness requirements for other entries inrequest. If the attribute are out of scope for this document. 5.6 Updated SDP Offers To do: Revisit this section based on new connection management rules MSRP endpointsreceiver initially accepted the request, it still may sometimes needthen do things that take significant time to send additional SDP exchanges forsucceed or fail. For example, if the receiver is an existing session. They may need to send periodic exchanges with no changeMSRP to refresh state inXMPP  gateway, it may forward the network, for example, SIP timers. Theymessage over XMPP. The XMPP side may need to change some other stream in a session without affectinglater indicate that the request did not work. At this point, the MSRP stream, or theyreceiver may need to change an MSRP stream without affecting some other stream. If either party wish to send an SDP documentindicate that changes nothing at all, then it MUST havethe same o-line version as inrequest did not succeed. There are two important concepts here: first, the previous exchange. 5.7 Example SDP Exchange Endpoint A wishes to invite Endpoint B to a MSRP session. A offershop by hop delivery of 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 9999 msrp * a=accept-types: message/cpim text/plain text/html a=path:msrp://alice.example.com:7394/2s93i9 B responds with its own URL: v=0 o=userb 2890844530 2890844532 IN IP4 bob.example.com s= c=IN IP4 dontlookhere t=0 0 m=message 9999 msrp * a=accept-types:message/cpim text/plain a=path:msrp://bob.example.com:8493/si438ds A immediately sends some MSRP traffic: Either a VISITrequest (if it has no immediate content to send)may succeed or a SENDfail; second, the end result of the request (if it does have immediate content.) Afterwards, A and Bmay now exchange IMs by executing SEND transactions. 5.8 Connection Negotiation Previous versionsbe successfully processed or not. The first type of this document includedstatus is referred to as "transaction status" and may be returned in response to a mechanismrequest. The second type of status is referred to negotiate the direction for any required TCP connection. The mechanism was loosely based on COMEDIA work being doneas "request status" and may be returned in the MMUSIC working group.a REPORT transaction. The primary motivation wasoriginal sender of a request can indicate if they wish to allow MSRP sessionsreceive reports for requests that fail, and can independently indicate if they wish to succeed in situations where the offerer could not accept connections butreceive reports for requests that succeed. A receiver only sends a success REPORT if it knows that the answerer could. For example,request succeeded, and the offerer might be behindsender requested a NAT, while the answerer might havesuccess report. A receiver only sends a globally routable address. The SIMPLE working group chosefailure REPORT if the request failed and the sender requested failure reports. This document describes the behavior of MSRP endpoints. MSRP relays or gateways are likely to removehave additional conditions that mechanism from MSRP,indicate a failure REPORT should be sent, such as it addedthe failure to receive a great deal of complexitypositive response from the next hop. Two header fields control the sender's desire to connection management. Instead, MSRP now specifies default connection directions. 6. The Message Session Relay Protocolreceive reports. The Message Session Relay Protocol (MSRP) isheader "Report-Success" can have a text based, message oriented protocol forvalue of "yes" or "no" and the transfer"Report-Failure" header can have a value of instant messages in"yes", "no", or "partial". If the contextvalue of a session. MSRP uses"Report-Failure" is set to "yes", then the UTF8 character set. MSRP messages MUST be sent oversender of the request runs a reliable, congestion-controlled, connection-oriented transport protocol. This document specifiestimer. If a 200 response to the use of MSRP over TCP. Other documents may specify bindings for other such protocols. 6.1 MSRP URLs An MSRP URL follows a subset oftransaction is not received within 30 seconds from the URL syntax in Appendix A of RFC2396 , with a schemetime the last byte of "msrp": msrp_url = msrp-scheme "://" [userinfo "@"] hostport ["/" resource] msrp-scheme = "msrp" / "msrps" / "smsrp" / "smsrps" resource = 1*unreserved The constructions for "userinfo", "hostport", and "unreserved" are detailed in RFC2396 . An MSRP URL server part identifies a participant in an MSRP session. Ifthe server part contains a numeric IP address, ittransaction is sent, the element MUST also contain a port. The resource part identifies a particular sessioninform the participant. The absence ofuser that the resource part indicates a referencerequest probably failed. If the value is set to an MSRP host device, but"partial", then the element sending the transaction does not specifically referhave to run a particular session resource. The underlying transport protocol andtimer, but MUST inform the protection level (that is, whether TLS is used) is determined byuser if receives a non-recoverable error response to the URL scheme: msrp MSRP over TCP without TLS. msrps MSRP over TCP with TLS. smsrp MSRP over SCTP without TLS. smsrps MSRP over SCTP with TLS. This document only describestransaction. Similarly if the binding for MSRP over TCP. The schema for SCTP are reserved herein, but binding MSRP to SCTP is out of scope for this document. MSRP has an IANA registered recommended port defined in Section 8.1. Thisvalue of the Report-Success header is not a default, as"yes", then the URL process described herein will always explicitly resolvereceiving node MUST send a port number. However,"success" REPORT after the URLs SHOULD be configured sorequest is complete to indicate that the recommended portrequest succeeded. Likewise if the value is used whenever appropriate. This makes life easier for network administrators who need"no", it MUST NOT send a success REPORT. A consequence of this is that if an MSRP element receives a request that has the Report-Failure header set to manage firewall policy for MSRP. The server part will typically not containa userinfo component, but MAY do sovalue of "no", it SHOULD NOT send any responses to indicatethis request, because the element sending the request would not do anything with the resulting response. If the value is "partial", it SHOULD NOT send a user account for which200 response to the sessionrequest, but SHOULD send a non-200 class response if appropriate. If no Report-Success header is valid. Note that thispresent in a SEND request, it MUST be treated the same as a Report-Success header with value of "no". If no Report-Failure header is notpresent, it MUST be treated the same thingas identifyinga Report-Failure header with value of "yes". REPORT requests MUST have the session itself.same Message-ID header value as the request they are reporting on. They MAY also have the Byte-Range of the chunk they are reporting on. If an MSRP element receives a userinfo component exists,REPORT for a Message-ID it does not recognize, it SHOULD silently ignore the REPORT. Report-Success and Report-Failure MUST NOT be constructed only from "unreserved" characters, to avoidpresent in a need for escape processing. EscapingREPORT request. MSRP nodes MUST NOT be usedsend REPORT requests in anresponse to report requests. MSRP URL. Furthermore, a userinfo partNodes MUST NOT contain password information.send MSRP responses to REPORT requests. The following is an examplecombinations of a typical MSRP URL: msrp://host.example.com:8493/asfd34 6.1.1 MSRP URL Comparison MSRP URL comparisons MUST be performed accordingreporting may seem overly complex but they are needed to meet the following rules: 1. The schema must match exactly. 2. The host part is compared as case insensitive. 3. If the port exists explicitlyvarious scenarios of currently deployed IM systems. Report-Success might be "no" in either URL, then it must match exactly. An URL with an explicit port is never equivalentmany public systems to another with no port specified. 4. The resource partreduce load but is comparedused in some current enterprise systems, such as case insensitive.systems used for securities trading. A URLReport-Failure value of "no" is useful for sending system messages such as "the system is going down in 5 minutes" without causing a resource part is never equivalentresponse explosion to onethe sender. A Report-Failure of "yes" is used by many systems that includeswish to notify the user if the message failed but some other systems choose to use a resource part. 5. Userinfo parts are not considered for URL comparison. Path normalization is not relevant for MSRP URLs. Escape normalization is not required, sincevalue of "partial" to reduce the relevant parts are limitedload on the servers caused by 200 OK responses, but still allow error responses to unreserved characters. 6.1.2 Resolvingbe sent in many cases. 4.4 MSRP Host Device AnConnection Model When MSRP host device iswishes to send a request to a peer identified by the server part ofan MSRP URL, it first needs a connection, with the appropriate security properties, to the host specified in the URL. If the server part containssender already has such a numeric IP address and port, they MUST be used as listed. Ifconnection, that is, one associated with the server part contains a host namesame host, port, and URL scheme, then it SHOULD reuse that connection. When a port,new MSRP session is created, the connecting deviceconvention is that the element that sent the SDP offer MUST determine a host address by doing an A or AAAA DNS query, and useimmediately issue a SEND request to the port as listed. Ifanswerer. This request MAY have a empty body, or MAY carry content. When a new connection attempt fails,needs to be formed, the device SHOULD attemptelement looks at the URL to connectdecide on the type of connection (TLS, TCP, etc.) then connects to the addresses returned in any additional A or AAAA records,host indicated by the URL, following the URL resolution rules in Section 5.2. For connections using the ordermsrps: scheme, the records were presented. This process assumes thatSubjectAltName in the connectionreceived certificate MUST match the hostname port is always known prior to resolution. This is always true forof the MSRPURL uses described in this document,and the certificate MUST be valid, including having a date that is, URLs always createdis valid and consumed by automata, rather thanbeing signed by humans. The introduction of relays may create situations wherean acceptable certificate authority. At this is notpoint the case. For example,device that initiated the MSRP URLconnection can assume that a user enters into athis connection is with the correct host. If the connection used mutual TLS authentication, and the TLS client to configure it to usepresented a relay may be intended to be easily remembered and communicated by humans, and therefore is likely to omitvalid certificate, then the port. Therefore,element accepting the relay specification may describe additional steps to resolveconnection can know the port number. 6.2 Connection Directionidentity of the connecting host. When SIPmutual TLS authentication is used as the signaling protocol,not used, the listening device sending the initialMUST wait until it receives a request on the connection to communicate is responsible for openingdetermine the connection. In most cases,identity of the device sends an offer in an INVITE or UPDATE request, and getsconnecting device. When the first request arrives, it's To-Path header field should contain a responseURL that the listening element handed out in a 2xx or 18x response. In this case,the inviter opensSDP for a session. The element that accepted the connection after receivinglooks up the response. This can be doneURL in parallel to sending an ACK request. Another, less common scenario is whenthe inviter sends an INVITE request with no offer,received request, and determines which session it matches. If a match exists, the invitee sends an offer in the response. In this case,node MUST assume that the inviter openshost that formed the connection after it receivesis the offer. It waits for successful connection prior to sendinghost that this URL was given to. If no match exists, the answer innode MUST reject the SIP ACK request. Open Issue:request with a 481 response. The delayed offernode MUST also check to make sure the session is not likely to workalready in SIP, asuse on another connection. If so, it MUST reject the invitee is almost certainly to propose RTP rather than MSRP. We either need to do more work to specify how an endpoint that supports both handlesrequest with a delayed offer, or remove any reference506 response. If it were legal to this. Other signaling protocols may use other approaches. Unless specific behavior is specified forhave multiple connections associated with the same session, a particular signaling protocol,security problem would exist. If the offererinitial SEND request is always responsible for openingnot protected, an eavesdropper might learn the URL, and use it to insert messages into the session via a different connection. Open Issue: Should we put inIf a hook to allow SDP extensions to be used to determineconnection direction? For example, if COMEDIA evolves to a point where it is workablefails for MSRP, why not allow using it? In all cases, the connectingany reason, then an MSRP endpoint connects to the device and port indicated by the connection URL, using the protocol and protection level specified by the URL scheme. If it determines that it already has a connectionMUST consider failed any sessions associated with the connection as well. When an endpoint notices such a URL that has a matching scheme, host part, and port,failure, it SHOULD reuse that connection rather than openingattempt to re-create any such sessions using a new one. OnceSDP exchange. If a connection has succeeded, or the decisionreplacement session is successfully created, endpoints MAY attempt to reuse a connection has been made,resend any content for which delivery on the connecting deviceoriginal session could not be confirmed. If it does this, the Message-ID values for the resent messages MUST immediately send an MSRP requestmatch those used in the context ofinitial attempts. If the new session. Thisreceiving endpoint receives more than one message allowswith the device acceptingsame Message-ID. It SHOULD assume that the connectionmessages are duplicates. It MAY take any action based on that knowledge, but SHOULD NOT present the duplicate messages to associatethe MSRP session withuser without warning of the connection. This MAY be a SEND request, ifduplicates. In this situation, the device has content to send immediately, or a VISIT request. Open Issue: Weendpoint MUST choose Message-ID values so that they are still discussing whetherunique in the offerer orcontext of both the answerer should be responsibleoriginal session and the replacement session. When endpoints create a new session in this fashion, the chunks for connecting. Either endpointa given logical message MAY tear downbe split across the sessions. However, endpoints SHOULD NOT split chunks between sessions under normal circumstances. If a connection when it no longer has any activefails, the sender SHOULD attempt to re-setup the URL path using a new offer, for example, in a SIP re-invite or proposed sessions associated withupdate . It MUST not assume that the new URLs in the SDP will be the same as the old ones. A connection SHOULD not be closed while there are sessions that are using this connection. 6.35. MSRP MessagesURLs An MSRP messages are either requests or responses. Requests and responses are distinguished from one another by the first line. The first line ofURL follows a Request takes the formsubset of the request-start entry below. Likewise, the first lineURL syntax in Appendix A of RFC2396 , with a response takes the formscheme of response-start. The syntax for an MSRP message is as follows: msrp-message = request-start/response-start *(header CRLF) [CRLF body] Closing request-start = "MSRP" SP Method CRLF response-start = "MSRP" SP Status-Code SP Reason CRLF Method = SEND / VISIT / other-method other-method = 1*(ALPHA) header = Tran-ID / Message-ID/ Session-URL / Content-Types / From-Path / To-Path / Message-Receipt / Receipt-ID / Byte-Range / Boundary Status-Code = 200 ;Success / 400 ;Bad Request / 403 ;Forbidden / 415 ;Unsupported Content Type / 426 ;Upgrade Required / 481 ;No session / 506 ;duplicate session / other-status ; extension codes other-status = 3(NUM) Reason = token ; Human readable text describing status Tran-ID = "Tr-ID" ":" token Message-ID = "Message-ID" ":" token Boundary"msrp" or "msrps": MSRP_urls = "Boundary" ":" 0*65(bchars) bcharsnospace bcharsnospace= DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_" / "," / "-" / "." / "/" / ":" / "=" / "?" bcharsmsrp-scheme "://" [userinfo "@"] hostport ["/" resource] ";" transport msrp-scheme = bcharsnospace"msrp" / " " Closing"msrps" resource = "-------" Boundary Continue-Flag CRLF ; Boundary must match Boundary header field value Continue-Flag1*unreserved transport = "+""tcp" / "$" Content-Type = "Content-Type" ":" media-type media-type = type "/" subtype *( ";" parameter ) type = token subtype =token parameter = attribute "=" value attribute = token value = token | quoted-string To-Path = "To-Path" ":" msrp_url *(SP msrp_url) From-Path = "From-Path" ":" msrp_url *(SP msrp_url) Message-Receipt = "Message-Receipt" ":" message-receipt-spec ( SEMI receipt-type ) message-receipt-spec = "negative" / "none" / "all" receipt-type = "receipt-type" "=" media-type; <media-type> isThe constructions for "userinfo", "hostport", and "unreserved" are detailed in [RFC3261] Byte-Range = "Byte-Range" ":" byte-range-spec byte-range-spec = first-byte "-" last-byte first-byte = 1*DIGIT last-byte = 1*DIGIT Receipt-ID = "Receipt-ID" ":" token All requests and responsesRFC2396 . URLs designating MSRP over TCP MUST contain at least a TR-ID header field. All requests must also contain the To-Path and From-Path, Message-ID, and Boundary header fields, as well asinclude the Closing field. Messages MAY contain"tcp" parameter. If some other fields, dependingtransport is used, the "tcp" parameter MUST NOT be present. Since this document only specifies MSRP over TCP, all MSRP URLs herein use the "tcp" parameter. Documents that provide bindings on other transports should define respective parameters for those transports. A MSRP URL with multiple, contradictory transports is invalid, unless some other document specifies meaning for the method or response code. 6.3.1 Message Framingparticular combination of transport parameters. An MSRP messages are framed usingURL server part identifies a participant in an MSRP session. If the Boundary header field value. The Boundary header fieldserver part contains a boundary string.numeric IP address, it MUST also contain a port. The Closing field contains the same boundary string withresource part identifies a prefixparticular session the participant. The absence of "-------" (seven hyphens) and single character suffix representingthe resource part indicates a continuation flag. The closing field is constructedreference to allow for simple high speed parsing. The use of seven hyphens forces for of theman MSRP host device, but does not specifically refer to be aligned ona 32 bit boundary.particular session resource. A parser can quickly scan forscheme of "msrps" indicates the closing by looking for a 32 bit value equivalent to "----". Once this wordunderlying connection MUST be protected with TLS. MSRP has an IANA registered recommended port defined in Section 15.1. This value is found,not a default, as the scanner can carefully check and see if this isURL negotiation process described herein will always include explicit port numbers. However, the boundary itURLs SHOULD be configured so that the recommended port is lookingused whenever appropriate. This makes life easier for or just some random data.network administrators who need to manage firewall policy for MSRP. The boundary string SHOULD have at least 16 bits of randomness in it. For example,server part will typically not contain a valid boundary would be "Boundary:6ea7" where the 6ea7 wasuserinfo component, but MAY do so to indicate a randomly chosen four digit hexadecimal number. This reducesuser account for which the chance ofsession is valid. Note that this is not the boundary string colliding with content data. The boundary string MUST NOT occur insidesame thing as identifying the bodysession itself. The sender MUST ensure thatIf a collision does not occur. Since the message fragmentation section (Section 6.7) of this document says that large content should be sent in parcels,userinfo component exists, it should alwaysMUST be possible to check for boundary collisions priorconstructed only from "unreserved" characters, to sendingavoid a parcel. Evenneed for escape processing. Escaping MUST NOT be used in the case of streaming content, where the sender does not have allan MSRP URL. Furthermore, a userinfo part MUST NOT contain password information. The following is an example of the content prior to sending the first message, the chunk size shoulda typical MSRP URL: msrp://host.example.com:8493/asfd34;tcp 5.1 MSRP URL Comparison MSRP URL comparisons MUST be small enough so that it is practicalperformed according to check each chunk for collisions priorthe following rules: 1. The scheme must match exactly. 2. The host part is compared as case insensitive. 3. If the port exists explicitly in either URL, then it must match exactly. An URL with an explicit port is never equivalent to sending.another with no port specified. 4. The MSRP boundary strings are distinct and independent from any MIME boundariesresource part is compared as case sensitive. A URL without a resource part is never equivalent to one that may exist in the message body. For example, ifincludes a resource part. 5. URLs with different "transport" parameters never match. Two URLs that are identical except for transport are not equivalent. 6. Userinfo parts are not considered for URL comparison. Path normalization is not relevant for MSRP URLs. Escape normalization is not required, since the bodyrelevant parts are limited to unreserved characters. 5.2 Resolving MSRP Host Device An MSRP host device is identified by the server part of a multipart type,an MSRP URL. If the MIME headers will includeserver part contains a multipart boundary. This multipart boundarynumeric IP address and port, they MUST NOTbe the same stringused inas listed. If the MSRP Boundary header field. The Closing fieldserver part contains both the message boundary stringa host name and a port, the Continuation-Flag. The Continuation-Flag indicates whether the entire content has been sentconnecting device MUST determine a host address by doing an A or not. Normally,AAAA DNS query, and use the flag takesport as listed. If a connection attempt fails, the value of "$" (dollar sign)device SHOULD attempt to indicate that all content has been sent, or "+"connect to indicate that there isthe addresses returned in any additional contentA or AAAA records, in the order the records were presented. This process assumes that has not yet been sent. The term "content"the connection port is always known prior to resolution. This is always true for the MSRP URL uses described in this context means a complete logical instant message, from the perspectivedocument, that is, URLs always created and consumed by automata, rather than by humans. The introduction of relays may create situations where this is not the user. The content could becase. For example, the MSRP URL that a short text message,user enters into a long file transfer, etc. The logical instant message does not necessarily correspond one-to-one withclient to configure it to use a physicalrelay may be intended to be easily remembered and communicated by humans, and therefore is likely to omit the port. Therefore, the relay specification  may describe additional steps to resolve the port number. MSRP message.devices MAY use other methods for discovering other such devices, when appropriate. For example, a video messageMSRP endpoints may be one logical instant message fromuse other mechanisms to discover relays, which are beyond the users' perspective, but it will generally be sent as a seriesscope of parcels. Each parcel would be sent asthis document. 6. Method-Specific Behavior 6.1 Constructing Requests To form a new request, the payload in one physicalsender creates a unique transaction identifier and uses this and the method name to create an MSRP SEND request. Allrequest start line. Next, the requests exceptsender places the final one would contain "+"target path in a To-Path header, and the continuation-flag to indicate thatsender's URL in a From-Path header. If multiple URLs are present in the contentTo-Path, the leftmost is not complete.the first URL visited; the rightmost URL is the last URL visited. The final message would contain "$"processing then becomes method specific. Additional method-specific headers are added as described in the following sections. After any method-specific headers are added, processing continues to indicate that complete content has been sent. The sender MUST NOT includehandle a completion-flag of "+"body, if present. A body in a Non-SEND request MUST NOT be longer than 2048 octets. If the payload MIME type does not support content fragmentation. 6.3.2 Message Examples The following is an example MSRP message sendingrequest has a text payload: MSRP SEND Boundary: dkei38sd To-Path:msrp://alice.atlanta.com:7777/iau39 From-Path:msrp://bob.atlanta.com:8888/9di4ea TR-ID: 456 Message-ID: 456 Content-Type: "text/plain" Hi, Alice! I'm Bob! -------dkei38sd$ The following is an example of an MSRP message containingbody, it must contain a Content-Type header field. It may contain other MIME type that uses an internal boundary (not tospecific headers. The Content-Type header MUST be the last header line. The body MUST be confusedseparated from the headers with an extra CRLF. If the MSRP boundary): MSRP SEND Boundary:a38sdo To-Path:msrp://bob.atlanta.com:8888/9di4ea From-Path:msrp:alice.atlanta.com:7777/iau39 TR-ID: 456 Message-ID: 456 Content-Type: multipart/byteranges;boundary=abcde --abcde Content-Type: image/jpeg Content-range: bytes 0-*/50270 [large jpg file] --abcde-- -------a38sdo$ 6.4 MSRP Transactions An MSRP transaction consists of exactly onerequest and one response. A response matchescontains a transaction ifbody, the following are true: It sharessender MUST check the same TR-ID value. Itbody to insure that the closing sequence (a CRLF, seven hyphens, and the transaction identifier) is received onnot present in the same connection on whichbody. If the request was sent. The To-Path has a single entry, which matchesclosing sequence is present in the response recipient's local URI forbody, the session. Endpointssender MUST select TR-ID header field values in requests sochoose a new transaction identifier that they areis not repeated by the same endpointpresent in scope ofthe 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 frombody, and add 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,closing sequence, including the "$" or after"+" character, and a timeout interval expires withfinal CRLF. Finally, requests which have no response. Endpointsbody MUST treat such timeouts in exactly the same way they would treatNOT contain a 500 response. The timeout interval SHOULD be 30 seconds, butContent-Type header or any other values may be established asMIME specific header. Bodiless requests MUST contain a matter of local policy. 6.5 MSRP Sessions AN MSRP session isclosing sequence after the final header. Once a context in whichrequest is ready for delivery, the sender follows the connection management (Section 4.4) rules to forward the request over an existing open connection or create a series of instant messages are exchanged, usingnew connection. 6.1.1 Delivering SEND requests. A session has two endpoints, identified by MSRP URLs. 6.5.1 Initiating an MSRP sessionrequests When an endpoint wishes to engage a peer inhas a message session, it invites the peerto communicate using an SDP offer, carried over SIP or some other protocol supporting the SDP offer/answer model. Fordeliver, it first generates a new unique Message-ID. This ID MUST be unique within the purposescope of this document, we will refer to the endpoint choosing to initiate communication asthe offerer, andsession. If the peer being invited asmessage is larger than 2048 octets in length, it either generates an interruptible chunk (which is RECOMMENDED), or it MAY break the answerer. Under normal circumstances,complete message into chunks of 2048 octets. It then generates a SEND request for each chunk, following the answererprocedures for constructing requests (Section 6.1). Each chunk MUST be prepared to acceptcontain a connection fromMessage-ID header field containing the offerer. The offerer MUST performMessage-ID. If the following steps: 1. Constructsender wishes non-default status reporting, it MUST insert a MSRP URL to serve as the local URL. 2. ConstructReport-Failure and/or Report-Success header field with an SDP offer as described in Section 5, including the listappropriate value. All chunks of allowed IM payload formats inthe accept-types attribute. The offerer puts its local URL intosame message MUST use the path attribute, as describedsame Report-Failure and Report-Success values in Section 5.4. This URL becomes the offerer's local path. 3. Send the SDP offer using the normal processing for the signaling protocol.their SEND requests. If success reports are requested, the answerer choosessending device MAY wish to participate, it MUST perform the following steps: 1. Store the contentsrun a timer of the offered sdp path attribute as the remote pathsome value that makes sense for he session. 2. Constructit's application and take action if a MSRP URL that resolves to itself. Savesuccess Report is not received in this as the local URLtime. There is no universal value for the session. 3. Listenthis timer. For many IM applications, it may be 2 minutes while for some trading systems it may be under a connection onsecond. Regardless of whether such a timer is used, if the transport, address, and port describedsuccess report has not been received by the local URL. 4. Send a SDP answer viatime the signaling protocol, according tosession is ended, the following rules: 1.device SHOULD inform the user. The C-line is copied unmodified fromfirst chunk of the offer. 2.message SHOULD, and all subsequent chunks MUST include a Byte-Range header field. The accept-types attribute containsrange-start field MUST indicate the SEND payload media types thatposition of the answerer is willing to accept. The accept-types attributefirst byte in the answer MUST be eitherbody in the same as thatoverall message. The range-end field SHOULD indicate the position of the offer, or a subset. 3. The path attribute contains the answerer's local URL. Again, this document assumes that no relays are introduced. If the answerer were to introduce one or more relay, it would add the appropriate URLs to the path attributelast byte in the SDP answer.body, if known. It would not need to listen for a connection, as the first relay in its path would have that honor. When the offerer receives the answer, itMUST perform the following steps: 1. Save the path attribute contents fromtake the SDP answer asvalue of "*" if the remote path. 2. Designateposition is unknown, or if the first entry inrequest needs to be interruptible. The total field SHOULD contain the remote path astotal size of the adjacent-hop URL. 3. Check to seemessage, if known. The total filed MAY contain a connection already exists that is associated with URL that matches"*" if the scheme, host part, and porttotal size of the adjacent-hop URL. If such a connection exists, the device SHOULD reuse it, rathermessage is not known in advance. All chunks other than opening a new connection. 4. If no matching connection exists, attempt to openthe last MUST include a connection to"+" character in the adjacent hop usingcontinuation field of the transport, address, port, and protection mode designated byclosing line. The final chunk MUST use a "$" character. The sender MUST send all chunks in Byte-Range order. (However,the receiver cannot assume the adjacent-hop URL. 5.requests will be delivered in order, as an intervening relay may have changed the order.) If the connection succeeds, or if a connection is reused, immediatelysender chooses to send a MSRP request tobody larger than 2048 octets in a single chunk, the opposite peer. This SHOULDrequest MUST be a visit request, but MAYconstructed so that it can be ainterrupted. A SEND request is interruptible if the endpointit either has legitimate content to send. 6.5.2 Handling the initial request An MSRP device that accepts a network connection will receive an immediate MSRP request from the connecting endpoint. This may be a SENDno Byte-Range header field, or VISIT request. When an endpoint receiveshas such a request, it MUST perform the following procedures: 1. Check if state exists for a sessionfield with a local URL that matches the To-Path header field value of"*" in the VISIT request. If so, and if no previouslast-byte sub-field. A SEND request has been received for that URL on a different connection, then returnis interrupted while a 200 response, and save state associating the first URLbody is in the From-Path header field withprocess of being written to the connection on which the request was received . 2. Ifby simply noting how much of the state exists, and a matching request has occurred on a different connection, return a 506 response and do not change session state in any way. 3. If no matching state exists, return a 481 response, and do not change session state in any way. 6.5.3 Sending Instant Messages on a Session Once a MSRP sessionmessage has already 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 accordingwritten to the following process: 1. Insert a To-Path header field containingconnection, then writing out the pathboundary string to end the opposite endpoint,chunk. It can then be resumed in order from left to right. 2. Inserta From-Pathanother chunk with the same Message-ID and a Byte-Range header range start 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 oneposition 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 offirst byte after the explicitly listed entries, but MAYinterruption occurred. SEND requests larger than 2k MUST be any other arbitrary value. 4. Set the TR-ID and Message-ID header fields to a unique value. The sender MAY set these fieldsinterrupted to send pending response or REPORT requests. If multiple SEND requests from different sessions are concurrently being sent over the same value. 5. Sendconnections, the device SHOULD implement some scheme to alternate between them such that each concurrent request on the connection associated with the session. 6. If a 2xx response code is received, the transaction was successful. 7. Ifgets a 415 response is received, this indicates the recipient is unable or unwillingchance to send some fair portion of data at regular intervals suitable to processthe media type.application. The sender SHOULDMUST NOT attempt to sendassume that particular media type again in the context of this session. 8. If any other response codea message is received, or if the transaction times out, the endpoint SHOULD assumereceived by the session has failed, either tear downpeer with the session,same chunk allocation it was sent with. An intervening relay could possibly break SEND requests into smaller chunks, or attempt to re-establish the session by sending an updated SDP offer proposing a new connection. If a new connectionaggregate multiple chunks into larger ones. The default disposition of body is established,"render". If the endpointsender wants different disposition, it MAY choose to resend the content on the new connection. Open Issue: Do we need to create a duplicate mechanism to suppress duplicate messages wheninsert a new connectionContent-Disposition header. Since MSRP is established in this fashion? mechanism? List consensus seems to indicate we do. We may need to specify that the tr-id space spansa sequence of connections if theybinary protocol, transfer encoding MUST be "binary". 6.1.2 Sending REPORT requests REPORT requests are associated with same stream, and of course, specify what it means for a streamsimilar to span connections. When an endpoint receives aSEND request, it MUST perform the following steps. 1. Checkrequests, except that it has state for a session withreport requests MUST NOT include Report-Success or Report-Failure header fields, and MUST contain a local URL matchingStatus header field. REPORT requests MUST contain the To-Path value.Message-ID header from the original SEND request. An MSRP endpoint MUST be able to generate success REPORT requests. REPORT requests MAY include a body. If no matching session exists, returna 481 response. 2. Determine thatbody is included, it understandsSHOULD be of the mediaDSN MIME type detailed in the body,RFC1894 , but MAY be of some other type if any exists. 3. If it does, return a 200 response and render the message tothe user. The method of rendering is a mattersender of local policy. If the message contained no body at all, the endpoint should quietly ignore it. 4. If it does not understandthe media type, return a 415 response. The endpoint MUST NOT return a 415 response for any media type for which itSEND request indicated support in the SDP exchange. 6.5.4 Ending a Session When either endpoint in an MSRP session wishes to end"receipt-type" parameter of the session, it first signals its intent usingrespective Report-Success or Report-Failure header field. This parameter contains the normal processingalternative MIME type that SHOULD be used for this particular report. A client specifying an alternative 'receipt-type' for an MSRP transaction MUST also be capable of receiving the signaling protocol. For example,default format specified in SIP, it would send a BYE request to the peer. After agreeing to end the session,this RFC1894. Use of the hostDSN MIME format in MSRP is described in Section 8 An endpoint MUST release any resources acquired as partsend a success report if it successfully receives a SEND request which contained a Report-Success value of "yes", and either contains a complete message, or contains the session. Each peer MUST destroy all local state forlast chunk needed to complete the session.message. This involves completely removingrequest is sent following the state entry fornormal procedures (Section 6.1), with a few additional requirements. The endpoint inserts a To-Path header field containing the session and invalidatingFrom-Path value from the session URL. If no other sessions are usingoriginal request, and a From-Path header containing the connection,URL identifying itself in the session. The endpoint that opened it SHOULD tear it down. However,then inserts a Status header field with a namespace of "000", a short-status of "200" and a relevant Reason phrase, and a Message-ID header field containing the passive party MAY tear down an unused connection aftervalue from the original request. Positive status reports SHOULD NOT include a locally configured timeout period. When anpayload. The endpoint chooses to close a session, it may have SEND transactions outstanding. For example, it may haveMUST NOT send SEND requests to which it has not yet receiveda response, or it may have receivedsuccess report for a SEND requestsrequest that to which it has not responded. Onceeither contained no Report-Success header field, or contained such a field with a value of "no". 6.1.3 Failure REPORT Generation If an MSRP endpoint has decided to close the connection,receives a SEND request that it SHOULD waitcannot process for such outstanding transactions to complete. It SHOULD NOT generate any new SEND transactions,some reason, and it MAY choosethe Report-Failure header either was not to respond to any new SEND requests that are received after it decides to closepresent in the session. It SHOULD not respond to any new messages that arrive afteroriginal request, or had a value of "yes", it signals its intent to close the session. WhenSHOULD simply send a transaction response with an appropriate error response code. However, there may be situations where the error cannot be determined quickly, such as when the endpoint is signaled of its peer's intent to closea session, it SHOULD NOT initiate any more SEND requests. It SHOULDgateway that must wait for any outstanding transactions that it initiateda downstream network to complete, andindicate an error. In this situation, it SHOULD attempt respond to any open SEND transactions received prior to being signaled. It is not possibleMAY send a 200 OK response to completely eliminatethe chance ofrequest, and then send a session terminating with incomplete SEND transactions. When this occurs, the endpoint SHOULD clearly inform the user thatfailure REPORT request when the messages may not have been delivered. 6.5.5 Managing Session State and Connections A MSRP sessionerror is represented by state at each endpoint, identified by the local URL and remote path. An active session also has an associated network connection.detected. If the connection fails for any reason, the device MUST invalidate the session state for all sessions using the connection. Once a connection is dropped, any associated session state MUST NOT be reused. If anendpoint wishes to continue to communicate after detecting a connection failure, it MAY initiatereceives a new SDP exchange to negotiateSEND request with a new session URL. Otherwise,Report-Failure header field value of "none", then it MUST NOT send a failure REPORT request, and SHOULD attemptNOT send an MSRP response. Construction of failure REPORT requests is identical to tear downthat for success reports, except the session using the rules of the signaling protocol. It would be nice to allow sessions toStatus header code and reason fields SHOULD contain appropriate error codes. Any error response code defined in this specification MAY also be recovered afterused in failure reports. Failure REPORT requests MAY contain a connection failure, perhapspayload, using the DSN MIME type. They MAY contain some other type if allowed by allowinga receipt-type in the active endpoint to reconnect, and sendReport-Failure header field. If a new VISIT request. However, this approach createsfailure report is sent in response to a race condition between the timeSEND request that contained a chunk, it MUST include a Byte-Range header indicating the hosting device noticesactual range being reported on. It can take the failed connection,range-start and total values from the time that the endpoint tries to recoveroriginal SEND request, but MUST calculate the session. Ifrange-end field from the endpoint attempts to reconnect prioractual body data. Endpoints SHOULD NOT send REPORT requests if they have reason to believe the hosting device noticing the failure, the hosting devicerequest will interpret the recovery attempt as a conflict. The only way around this wouldnot be to force the hosting device to dodelivered. For example, they SHOULD NOT send a liveness checkREPORT request on the original connection, which would createa lot of complexity and overhead that do not seem to be worth the trouble. 6.6 Delivery Status Notification Delivery Status Notification (DSN) provides an extensible MIME content-typesession that is used to convey both positive and negative status of messages in the network.no longer valid. This functionality is extremely usefulsection only describes failure report generation behavior for MSRP sessions that traverse a relay device.endpoints. Relay supportbehavior is considered out ofbeyond the scope forof this specificationdocument, and will be includedconsidered in a separate specification. This section will only cover functionality requireddocument. We expect failure reports to be more commonly generated by non-relay aware endpoints for basic MSRP operation. Anrelays than by endpoints. 6.2 Constructing Responses If an MSRP endpoint receives a request that either contains a Report-Failure header value of "yes", or does not contain a Report-Failure header field at all, it MUST be capableimmediately generate a response. Likewise, if an MSRP endpoint receives a request that contains a Report-Failure header value of performing the DSN operations described in this specification"partial", and the receiver is unable to process the request, it SHOULD supportimmediately generate a response. To construct the response, the DSN MIME type outlined. An MSRPendpoint MAY use an alternative payload for reporting message status usingfirst creates the procedures outlinedresponse start-line, inserting appropriate response code and reason fields. The transaction identifier in this specification. 6.6.1 Endpoint DSN Request Anthe response start line MUST match the transaction identifier from the original request. The endpoint that wishes to be informed of message delivery/failure needs tothen inserts an appropriate To-Path header field. If the request such information. Thistriggering the response was a SEND request, the To-Path header field is achievedformed by including an MSRP Receipt-Request headercopying the last (right-most) URI in the request. TheFrom-Path header can equal onefield of three values: negative: Indicatesthe clientrequest. (Unlike other methods, responses to SEND requests are returned only requires failure delivery report. none: Indicatesto the client requires no delivery reports. all: Indicatesprevious hop.) For responses to all other requests, the client requires both positiveTo-Path header field contains the full path back to the original sender. This full path is generated by taking the list of URLs from the From-Path of the original request, reversing the list, and negative delivery reports. Withinwriting the scopereversed list into the To-Path of the response. (Legal REPORT requests do not request responses, so this specification doesn't exercise the Receipt-Request header is only used in MSRP SEND requests. Future extensions to this specification MAY use the mechanismbehavior described in this document for delivery/failure status notification of other MSRP requests. The default valueabove, however we expect that extensions for this header if not present ingateways and relays will need such behavior.) Finally, the endpoint inserts a request is 'negative'. An example of thisFrom-Path header would be: Message-Receipt: negative The default DSN MIME type is detailedfield containing the URL that identifies it in RFC 1894. It is possible for MSRP endpoints to use a different format if required. This can be achievedthe context of the session, followed by including a 'receipt-type' parameter inthe Message-Receipt header. This parameter containsclosing sequence after the alternative MIME type that SHOULD be used for this particular receipt transaction. A client specifying an alternative 'receipt-type' for an MSRP transactionlast header field. The response MUST alsobe capable oftransmitted back on the same connection on which the original request arrived. 6.3 Receiving Requests The receiving endpoint must first check the default format specifiedURL in this document. This allows intermediaries, such as MSRP relays,the To-Path to generate failure reports when MSRP transaction failure occurs. 6.6.2 DSN generation An MSRP endpoint implementing this specification SHOULD be ablemake sure the request belongs to generate positive delivery status of MSRP requests. On receivingan MSRPexisting session. When the request containing a Message-Receipt header with a value of 'all',is received, the endpointTo-Path will carry out normal MSRP response generation andhave exactly one URL, which MUST generatemap to an MSRP REPORTexisting session that is associated with the connection on which the request usingarrived. If this is not true, and the following procedures: 1. Insertrequest contained a ToReport-Failure header containing the Fromvalue fromof "no", then the receiver SHOULD quietly ignore the originalrequest. 2. Insert a FromIf the Report-Failure header containingis not present, or had any other value, then the To value fromreceiver MUST return a 481 response. Further request processing by the original request. 3. Insertreceiver is method specific. 6.3.1 Receiving SEND requests When the message status payload inreceiving endpoint receives a SEND request, it first determines if it contains a complete message, or a chunk from a larger message. If the bodyrequest contains no Byte-Range header, or contains one with a range-start value of "1", and the request. If the default DSN MIME type from DSN is usedclosing line continuation flag has a value of "$", then the MSRP Content-Type header MUST userequest contained the entire message. Otherwise, the receiver looks at the Message-ID value multipart/report. The relevanceto associate chunks together into the original message. It forms a virtual buffer to receive the message, keeping track of DSN headerswhich bytes have been received and which are missing. The receiver takes the data from the request and places it in MSRP can be foundthe appropriate place in section 7.6.5. An alternative MIME type MAY be used butthe buffer. The receiver MUST be specified indetermine the Content-Type header. Negative DSN generationactual length of each chunk by inspecting the payload itself; it is considered outpossible the body is shorter than the range-end field indicates. This can occur if the sender interrupted a SEND request unexpectedly. It is worth nothing that the chunk that has a termination character of "$" defines the total length of the message. What is done with the body is outside the scope of this document and will be covered in a separate MSRP relay document. 4. Insert a new transaction ID (TR-ID). 5. (Optional) Insert anMSRP Byte-Range header containingand largely determined by the value from 'multipart/byteranges'MIME header Content-range fromtype. The body MAY be rendered after the payload of a chunked message. Itwhole message is possible that an entity downstream may decide to break up an MSRPreceived or partially rendered as it is being received. If the SEND message andrequest contained a Content-Type header field indicating an unsupported MIME type, the receiver SHOULD send it in separate chunks. The originating client would be transparent to this operation but would need to be informed ifa DSN only represents part of415 response, if allowed by the request. 6.6.3 Receiving positive DSN An MSRP endpoint implementing this specification MUST be able to receive positive delivery status of MSRP requests. 6.6.4 Receiving negative DSN AnReport-Failure header field. All MSRP endpoint implementing this specificationendpoints MUST be able to receive negative delivery status of MSRP requests. 6.6.5 DSN headers in MSRP The format of a default DSN report is taken from RFC 1894. Only a minimal subset of fields are used, as detailed inthe remainder of this section. 18.104.22.168 Per-Message DSN header usage original-envelope-id: See Section 22.214.171.124 reporting-mta: See Section 126.96.36.199 dsn-gateway: Not Used received-from-mta: Not Used arrival-date: Not Used 188.8.131.52 Per-Recipient DSNmultipart/mixed and multipart/alternative MIME types. If the SEND request contained a Report-Success header usage original-recipient Not Used final-recipient: See Section 184.108.40.206 action: See Section 220.127.116.11 status: See Section 18.104.22.168 remote-mta: Not Used diagnostic-code: Not Used last-attempt-date: Not Used will-retry-until:Not Used 22.214.171.124 original-envelope-id usage The 'original-envelope-id'field contains a unique identifier which is used to correlate a DSN reportwith the originating MSRP transaction. The entity generating the DSN report MUST insert the Message-IDa value that appeared inof "yes", and the original MSRPrequest intois either contains the 'original-envelope-id' field. This allows a requesting cliententire message or the last chunk needed to explicitly correlatecomplete a message, the receiver MUST send a success REPORT request withback to the original request. This correlation is implementation specific and makes no requirements on clientssender. 6.3.2 Receiving REPORT requests When an endpoint receives a REPORT request, it may correlate it to hold state for transactions ID's. Information regardingthe original SEND request can be obtained fromusing the DSN MIME type outlined in . 126.96.36.199 reporting-mta The 'reporting-mta-field' MUST followMessage-ID and the guidelines set out in RFC 1894. The 'mta-name-type' from RFC1894 MUST useByte-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 value of 'msrp-name-type', as defined in section 9 of this specification. The 'mta-name' value for thisoriginal messages. An endpoint that receives a REPORT request containing a Status header with a namespace field as specified in RFC1894  MUST equal an MSRP URL representing itself. 188.8.131.52 final-recipient The 'final-recipient-field' MUST follow the guidelines set out in RFC 1894. The 'address-type' from RFC1894  MUST use the value of 'msrp-address-type', as defined in section 9of this specification. The 'address-type' value for this field as specified in RFC1894  MUST equal"000", it SHOULD interpret the value containedreport in exactly the same way it would interpret an MSRP 'To' header from the original request being reported on. 184.108.40.206 action The 'action' field MUST followtransaction response with a response code matching the guidelines set out in RFC 1894. An MSRP entity constructingshort-code field. It is possible to receive a DSNfailure report MUST use the 'delivered' valueor a failure transaction response for a successful delivery and MUST usechunk that is currently being delivered. In this case the 'failed' value for an un-successful delivery. The other values specifiedentire message corresponding to that chunk should be aborted. It is possible that an endpoint will receive a REPORT request on a session that is no longer valid. The endpoint's behavior if this happens is a matter of local policy. The endpoint is not required to take any steps to facilitate such late delivery, i.e. it is not expected to keep a connection active in case late REPORTs might arrive. 7. Using MSRP with SIP 7.1 SDP Offer-Answer Exchanges for MSRP Sessions MSRP sessions will typically be initiated using the 'action' fieldSession Description Protocol (SDP)  via the SIP offer-answer mechanism . This document defines a handful of new SDP parameters to setup MSRP sessions. These are detailed below and in RFC 1894 MAY be used. 220.127.116.11 statusthe IANA Considerations section. The 'status' fieldgeneral format of an SDP media-line is: m=<media> <port> <protocol> <format list> An offered or accepted MSRP media-line MUST followhave the guidelinesfollowing value exactly, with the exception that the port field MAY be set out in RFC 1894. An MSRP entity constructingto zero. (According to , a DSN reportuser agent that wishes to accept an offer, but not a specific media-line MUST representset the port number of that media-line to zero (0).) m=message 9 msrp * While MSRP status code incould theoretically carry any media type, "message" is appropriate. For MSRP, the correct format detailedport number is always ignored--the actual port number is provided in RFC 1894 foran MSRP URL. Instead "9" is used, which is an innocuous value which is assigned to the 'status' fielddiscard port. The protocol is always "msrp", and the value of the format list is always a DSN report.single asterisk character ("*"). An MSRP status code consists of a three digit number while a DSN statusmedia-line is three digits separatedalways accompanied by '.'. An example would be: Status: 5.0.0 (unknown permanent failure) When generatinga mandatory "path" attribute. This attribute contains a space separated list of URLs that must be visited to contact the user agent advertising this fieldsession-description. If more than one URL is present, the leftmost URL is the first digit ofURL that must be visited to reach the MSRP status code (working from lefttarget resource. (The path list can contain multiple URLs to right) MUST be placed inallow for the first partdeployment of gateways or relays in the 'status' DSN field. The second digitfuture.) MSRP implementations which can accept incoming connections will typically only provide a single URL here. MSRP media lines MUST also be placed in the second partaccompanied by an "accept-types" attribute. This attribute contains a list of MIME types which are acceptable to the 'status' DSN field. The third digit MUST be placedendpoint. A "*" entry in the third part ofaccept-types attribute indicates that the 'status' DSN field. An example of a DSN 'status' field value would be: An MSRP '200' success response would be mapped to: Status: 2.0.0 (OK) The MSRP reason phrase mappedsender may attempt to a DSN 'status' field MAY be enclosed in parentheses if required. 6.7 Message Fragmentation MSRP devices SHOULD break largesend content into fragments,with media types that have not been explicitly listed. Likewise, an entry with an explicit type and send each fragment ina separate SEND request. A message fragment sent in this way is known"*" character as a "parcel". Large content is defined to be anything larger than 2K bytes. Each parcel is encapsulated usingthe "message/byteranges" MIME type, defined in RFC2616 ,subtype indicates that the sender may attempt to correlate partssend content with any subtype of the message. The definition of large is determined by local policy.that type. If the receiver receives an MSRP endpoints MUST be capable of receivingrequest and processing fragmented messages. Open Issue: Do we wantis able to negotiateprocess the use of message/byteranges likemedia type, it does so. If not, it will respond with a 415 response. Note that all explicit entries SHOULD be considered preferred over any other MIME type? I assume no, as we want to allow relays to fragment messages, and relays are not privy tonon-listed types. This feature is needed as, otherwise, the content-types negotiatedlist of formats for a session. Although relaysrich IM devices may be prohibitively large. The accept-types attribute may include container types, that is, MIME formats that contain other types internally. If compound types are notused, the types listed in scope for this document, we expect that relays willthe accept-types attribute may be able to introduce fragmentation, as wellused both as changethe fragmentation of previously fragmented messages. Therefore, all MSRP endpoints MUSTroot payload, or may be able to receive fragmented messages. 6.7.1 MSRP Usage of message/byteranges The "message/byteranges" type allows multiple rangeswrapped in a single document. However, MSRP deviceslisted container type. Any container types MUST NOT include more than one byte rangealso be listed in a single request. Althoughthe HTTP usage foraccept-types attribute. Occasionally an endpoint will need to specify a document containingMIME body type that can only be used if wrapped inside a single byte range indicates puttinglisted container type. Endpoints MAY specify MIME types that are only allowed when wrapped inside compound types using the "Content-Range" header in a header field, rather than"accept-wrapped-types" attribute in the body itself, "Content-Range" MUST NOT appear asan MSRP header field. Open Issue: How muchSDP a-line. The semantics for accept-wrapped-types are identical to those of the message/byteranges specification should we explain or copy forward? Copying too much obscuresaccept-types attribute, with the factexception that rfc2616 isthe normative definition, but itspecified types may only be helpful to have more context here. Ifused when wrapped inside containers. Only types listed in the MSRP device has a priori knowledge ofaccept-types attribute may be used as the overall content length, it SHOULD put that length into instance-length. The device MAY place"root" type for the entire body. Since any type listed in accept-types may be used both as a "*"root body, and wrapped in instance-length if itother bodies, format entries from accept-types SHOULD NOT be repeated in this attribute. This approach does not have such knowledge. Similarly, if the device has a priori knowledgeallow for specifying distinct lists of the numberacceptable wrapped types for different types of bytes incontainers. If an endpoint understands a byte range, it SHOULD place the last byte positionMIME type in last-byte-pos. Otherwise,the context of one wrapper, it MAY use a "*". If "*"is present, the recipient MUST determine the last-byte-position through normal request framing and body processing. An MSRP device MUST put the initial byte positionassumed to understand it in first-byte-pos. 6.8 Method Descriptions This section summarizesthe purposecontext of each MSRP method. All MSRP messages MUST contain the TR-ID, From-Path, To-Path, and Boundary header fields, as well as a Closing field. Additional requirements exist depending onany other acceptable wrappers, subject to any constraints defined by the individual method. 6.8.1 SENDwrapper types themselves. The SEND method is used by bothapproach of specifying types that are only allowed inside of containers separately from the host and visitor endpointsprimary payload types allows an endpoint to send instantforce 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 endpoint. A SEND request MUST contain a To-Path header field containingmight attempt to use those types without the sender's remote path, a From-Path header field containingwrapper. All types listed in either the sender's local URL, and a Message-ID header field. SEND requests SHOULD containaccept-types or accept-wrapped-types attributes MAY include a MIME body part. The bodymax-size parameter, indicating the largest message it is willing to accept of that type. Max-size refers to the complete message, not the size of any one chunk. Senders MUST beNOT exceed the max-size limit, if any, when sending messages of any listed type. If a mediatype included inis listed without the format listparameter, then no preset size limit exists. accept-types = accept-types-label ":" format-list accept-types-label = "accept-types" accept-wrapped-types = wrapped-types-label ":" format-list wrapped-types-label = "accept-wrapped-types" format-list = format-entry *( SP format-entry) format-entry = ctype [SEMI max-size] ctype = (type "/" subtype) / (type "/" "*") / ("*") type = token subtype = token max-size = "max" "=" 1*(DIGIT) 7.1.1 URL Negotiations Each endpoint in an MSRP session is identified by a URL. These URLs are negotiated in the SDP exchange. If a body is present, the requestEach SDP offer or answer 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 headerone or more MSRP URL in a SEND request.path attribute. This is not included in this version forattribute has the sake of getting the draft out as soonfollowing syntax: "a=path:" MSRP_URL *(SP MSRP_URL) where MSRP_URL is an msrp: or msrps: URL as possible, but will follow soon. 6.8.2 VISIT The visiting endpointdefined in Section 5. MSRP URLs included in an SDP offer or answer MUST include explicit port numbers. An MSRP device uses the VISIT methodURL to associate a network connection with the session state at the listening device. A VISIT request MUST includedetermine a To-Path header including the sender's remote path,host address, port, transport, and protection level when connecting, and a From-Path header field containing the sender's local URL. This purpose can also be served by a SEND request, if the sender has immediate contentto send. Open Issue: There is overlap between SENDidentify the target when sending requests and VISIT as currently defined. We should consider either removing VISIT entirelyresponses. The offerer and just use an empty SEND request, or we should always require VISIT. (This would not apply toanswerer each selects a endpoint connectingURL to its own relay.) 6.8.3 REPORT Report is used by an endpoint or relayrepresent itself, and send it to convey message delivery status 6.9 Response Code Descriptions This section summarizes the various response codes. Except where noted, all responses MUST contain a TR-ID header field matchingthe TR-ID header field ofpeer device in the original request, and To-Path and From-Path headers matching those ofSDP document. Each device stores the original request. 6.9.1 200 The 200 response code indicates a successful transaction. 6.9.2 400 A 400 response indicates a request was unintelligible. 6.9.3 415 A 415 response indicatespath value received from the SEND request contained a MIME content-typepeer, and uses that is not understood byvalue as the receiver. 6.9.4 426 A 426 response indicates thattarget for requests inside the requestresulting session. If the path attribute received from the peer contains more than one URL, then the target URL is the rightmost, while the leftmost entry represents the adjacent hop. If only allowed over TLS protected connections. 6.9.5 481 A 481 response indicates that no session exists forone entry is present, then it is both the connection. 6.9.6 506 A 506 response indicates thatpeer and adjacent hop URL. The target path is the entire path attribute value received from the peer. The following example shows an SDP offer with a VISIT request occurredsession URL of "msrp://a.example.com:7394/2s93i;tcp" v=0 o=alice 2890844526 2890844527 IN IP4 alice.example.com s= c=IN IP4 alice.example.com m=message 9 msrp * a=accept-types:text/plain a=path:msrp://a.example.com:7394/2s93i;tcp The rightmost URI in whichthe To-Path header indicates a localpath attribute MUST identify the endpoint that is alreadygenerated the SDP document, or some other location where that endpoint wishes to receive requests associated with another connection. A 506 responsethe session. It MUST NOTbe returnedassigned for this particular session, and MUST NOT duplicate any URI in response touse for any methodother than VISIT. 6.10 Header Field Descriptions This section summarizessession in which the various header fields.endpoint is currently participating. It SHOULD be hard to guess, and protected from eavesdroppers. This is discussed in more detail in Section 14. 7.1.2 Path Attributes with Multiple URLs As mentioned previously, this document describes MSRP header fields are single valued;for peer-to-peer scenarios, that is, they MUST NOT occur more than once in a particular request or response. 6.10.1 TR-ID The TR-ID header field contains a transaction identifier used to mapwhen no relays are used. However, we expect a responseseparate document to describe 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. 6.10.2 Message-ID The Message-ID header field contains a message identifier used to map a delivery status notificationuse of relays. In order to allow an MSRP device that only implements the corresponding request. TR-ID cannot be used forcore specification to interoperate with devices that use relays, this purpose, as it may change between hops if relays are involved. A Message-ID value MUST be unique among all values used bydocument must include a givenfew assumptions about how relays work. An endpoint insidethat uses one or more relays will indicate that by putting a given session. MSRP elements MUST NOT assume any additional semanticsURL for Message-ID. The Message-ID value MAY beeach device in the same asrelay chain into the original TR-ID value. 6.10.3 To-PathSDP path attribute. The To-Path header field is usedfinal entry would point to indicatethe sender's remote path. All MSRP requests MUST contain a To-Path header field. 6.10.4 From-Pathendpoint itself. The From-Path header field is used toother entries would indicate the sender's local URL. All MSRP requests MUST contain a From-Path header field. 6.10.5 Boundary The Boundary header field contains the boundary string that is used to terminate the message. This string MUST have at least 16 bits of randomness. This string MUST NOT be duplicated anywhere elseeach proposed relay, in the message.order. The Boundary header field is mandatory for all MSRP messages, and SHOULD befirst entry would point to the first header fieldrelay in the message. 6.10.6 Closing The Closing field contains the same boundary stringchain; that was originally listed inis, the Boundary header field, as well asrelay to which the Continuation-Flag field. The Closing field MUST occurpeer device, or a relay operation on its behalf, should connect. Endpoints that do not wish to insert a relay, including those that do not support relays at all, will put exactly one URL into the end of each MSRP message. Ifpath attribute. This URL represents both the message content has been sent completely,endpoint for the Interrupt-Flag field value MUST be ""$ (dollar sign). If there is further content to send as part ofsession, and the "logical" instant message,connection point. While endpoints that implement only this field value MUSTspecification will never introduce a relay, they will need to be "+". (plus sign.) 6.10.7 Content-Type The Content-Type header field is usedable to indicate the MIME media type of the body. Content-Typeinteroperate with other endpoints that do use relays. Therefore, they MUST be present if a body is present. To Do: The work group has agreedprepared to allow the use of any standard MIME header. This is not reflectedreceive more than one URL in this version, but will bethe SDP path attribute. When an endpoint receives more than one URL in a shortly forthcoming one. 7. Example This section shows an example message flow forpath header, only the most common scenario. The example assumes SIPfirst entry is used to transport the SDP exchange. Detailsrelevant for purposes of resolving the SIP messagesaddress and SIP proxy infrastructure are omitted forport, and establishing the sake of brevity. Innetwork connection, as it describes the example, assumefirst adjacent hop. If an endpoint puts more than one URL in a path attribute, the offerer is sip:firstname.lastname@example.org andfinal URL in the path (the peer URL) attribute MUST exhibit the uniqueness properties described above. Uniqueness requirements for other entries in the attribute are out of scope for this document. 7.1.3 Updated SDP Offers MSRP endpoints may sometimes need to send additional SDP exchanges for an existing session. They may need to send periodic exchanges with no change to refresh state in the network, for example, SIP Session Timers. They may need to change some other stream in a session without affecting the MSRP stream, or they may need to change an MSRP stream without affecting some other stream. Either peer may initiate an updated exchange at any time. The endpoint that sends the new offer assumes the role of offerer for all purposes. The answerer MUST respond with a path attribute that represents a valid path to itself at the time of the updated exchange. This new path may be the same as its previous path, but may be different. The new offerer MUST NOT assume that the peer will answer with the same path it used previously. If either party wishes to send an SDP document that changes nothing at all, then it MUST have the same o-line as in the previous exchange. 7.1.4 Example SDP Exchange Endpoint A wishes to invite Endpoint B to a MSRP session. A offers the following session description: v=0 o=usera 2890844526 2890844527 IN IP4 alice.example.com s= c=IN IP4 alice.example.com t=0 0 m=message 9 msrp * a=accept-types: message/cpim text/plain text/html a=path:msrp://alice.example.com:7394/2s93i9;tcp B responds with its own URL: v=0 o=userb 2890844530 2890844532 IN IP4 bob.example.com s= c=IN IP4 bob.example.com t=0 0 m=message 9 msrp * a=accept-types:message/cpim text/plain a=path:msrp://bob.example.com:8493/si438ds;tcp 7.1.5 Connection Negotiation Previous versions of this document included a mechanism to negotiate the direction for any required TCP connection. The mechanism was loosely based on the COMEDIA work being done in the MMUSIC working group. The primary motivation was to allow MSRP sessions to succeed in situations where the offerer could not accept connections but the answerer could. For example, the offerer might be behind a NAT, while the answerer might have a globally routable address. The SIMPLE working group chose to remove that mechanism from MSRP, as it added a great deal of complexity to connection management. Instead, MSRP now specifies a default connection direction. 7.2 MSRP User Experience with SIP In typical SIP applications, when an endpoint receives an INVITE request, it alerts the user, and waits for user input before responding. This is analogous to the typical telephone user experience, where the callee "answers" the call. In contrast, the typical user experience for instant messaging applications is that the initial received message is immediately displayed to the user, without waiting for the user to "join" the conversation. Therefore, the principle of least surprise would suggest that MSRP endpoints using SIP signaling SHOULD allow a mode where the endpoint quietly accepts the session, and begins displaying messages. SIP INVITE requests may be forked by a SIP proxy, resulting in more than one endpoint receiving the same INVITE. SIP early media  techniques can be used to establish a preliminary session with each endpoint, and canceling the INVITE transaction for any endpoints that do not send MSRP traffic after some period of time. 8. DSN payloads in MSRP REPORT Requests The format of a default REPORT request payload format the DSN taken from RFC1894 . Only a minimal subset of fields are relevant for MSRP, as detailed in the remainder of this section. 8.1 Per-Message DSN header usage original-envelope-id: See Section 8.3 reporting-mta: See Section 8.4 dsn-gateway: Not Used received-from-mta: Not Used arrival-date: Not Used 8.2 Per-Recipient DSN header usage original-recipient Not Used final-recipient: See Section 8.5 action: See Section 8.6 status: See Section 8.7 remote-mta: Not Used diagnostic-code: Not Used last-attempt-date: Not Used will-retry-until:Not Used 8.3 original-envelope-id usage The 'original-envelope-id' field contains a unique identifier which is used to correlate a DSN report with the originating MSRP transaction. The entity generating the DSN report MUST insert the Message-ID value that appeared in the original MSRP request into the 'original-envelope-id' field. This allows a requesting client to explicitly correlate a REPORT request with the original request. This correlation is implementation specific and makes no requirements on clients to hold state for transactions ID's. Information regarding the original request can be obtained from the DSN MIME type outlined in . 8.4 reporting-mta The 'reporting-mta-field' MUST follow the guidelines set out in RFC 1894. The 'mta-name-type' from RFC1894 MUST use the value of 'msrp-name-type', as defined in Section 15.4 of this specification. The 'mta-name' value for this field as specified in RFC1894  MUST equal the MSRP URL representing itself in the context of the session. 8.5 final-recipient The 'final-recipient-field' MUST follow the guidelines set out in RFC 1894. The 'address-type' from RFC1894  MUST use the value of 'msrp-address-type', as defined in Section 15.4 of this specification. The 'address-type' value for this field as specified in RFC1894  MUST equal the final value contained in the MSRP 'To-Path' header from the original request. 8.6 action The 'action' field MUST follow the guidelines set out in RFC 1894. An MSRP entity constructing a DSN report MUST use the 'delivered' value for a successful delivery and MUST use the 'failed' value for an unsuccessful delivery. The other values specified for the 'action' field in RFC 1894 MAY be used. 8.7 status The 'status' field MUST follow the guidelines set out in RFC 1894. An MSRP entity constructing a DSN report MUST represent the MSRP status code in the correct format detailed in RFC 1894 for the 'status' field of a DSN report. An MSRP status code consists of a three digit number while a DSN status is three digits separated by '.'. An example would be: Status: 5.0.0 (unknown permanent failure) When generating this field the first digit of the MSRP status code (working from left to right) MUST be placed in the first part of the 'status' DSN field. The second digit MUST be placed in the second part of the 'status' DSN field. The third digit MUST be placed in the third part of the 'status' DSN field. An example of a DSN 'status' field value would be: An MSRP '200' success response would be mapped to: Status: 2.0.0 (OK) The MSRP reason phrase mapped to a DSN 'status' field MAY be enclosed in parentheses if required. 9. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 . 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 phrase] CRLF phrase = utf8text pMSRP = %4d.53.52.50 ; MSRP in caps transact-id = ident method = mSEND / mREPORT / other-method mSEND = %53.45.4e.44 ; SEND in caps mREPORT = %18.104.22.168f.52.54; REPORT in caps other-method = 1*UPALPHA status-code = 3DIGIT headers = 1*( header CRLF ) header = ( To-Path / From-Path / Message-ID / Report-Success / Report-Failure / Byte-Range / Status / Mime-Header / ext-header ) To-Path = "To-Path:" SP URL *( SP URL ) From-Path = "From-Path:" SP URL *( SP URL ) Message-ID = "Message-ID:" SP ident Report-Success = "Report-Success:" SP ("yes" / "no" ) Report-Failure = "Report-Failure:" SP ("yes" / "no" / "partial" ) Byte-Range = "Byte-Range:" SP range-start "-" range-end "/" total range-start = 1*DIGIT range-end = 1*DIGIT / "*" total = 1*DIGIT / "*" Status = "Status:" SP namespace SP short-status [SP text-reason] ident = alphanum 3*31ident-char ident-char = alphanum / "." / "-" / "+" / "%" / "=" content-stuff = *(Other-Mime-Header CRLF) Content-Type 2CRLF data CRLF Content-Type = "Content-Type:" SP media-type media-type = type "/" subtype *( ";" gen-param ) type = token subtype = token gen-param = pname [ "=" pval ] pname = token pval = token / quoted-string token = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE qdtext = SP / HT / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE) BACKSLASH = "\" DQUOTE = %x22 Other-Mime-Header = (Content-ID / Content-Description / Content-Disposition / mime-extension-field); ; Content-ID, and Content-Description are defined in RFC2045. ; Content-Disposition is defined in RFC2183 ; MIME-extension-field indicates additional MIME extension ; headers as described in RFC2045 data = *OCTET end-line = "-------" transact-id continuation-flag CRLF continuation-flag = "+" / "$" ext-header = hname ":" SP hval CRLF hname = alpha *token hval = utf8text utf8text = *(HT / %x20-7E / UTF8-NONASCII) UTF8-NONASCII = %xC0-DF 1UTF8-CONT / %xE0-EF 2UTF8-CONT / %xF0-F7 3UTF8-CONT / %xF8-Fb 4UTF8-CONT / %xFC-FD 5UTF8-CONT UTF8-CONT = %x80-BF 10. Response Code Descriptions This section summarizes the semantics of various response codes that may be used in MSRP transaction responses. These codes may also be used in the Status header in REPORT requests. 10.1 200 The 200 response code indicates a successful transaction. 10.2 400 A 400 response indicates a request was unintelligible. 10.3 403 The action is not allowed 10.4 415 A 415 response indicates the SEND request contained a MIME content-type that is not understood by the receiver. 10.5 426 A 426 response indicates that the request is only allowed over TLS protected connections. 10.6 481 A 481 response indicates that no session exists for the connection. 10.7 506 A 506 response indicates that a request arrived on a session which is already bound to another network connection. 11. Examples 11.1 Basic IM session This section shows an example flow for the most common scenario. The example assumes SIP is used to transport the SDP exchange. Details of the SIP messages and SIP proxy infrastructure are omitted for the sake of brevity. In the example, assume the offerer is sip:email@example.com and the answerer is sip:firstname.lastname@example.org. Alice Bobsip:email@example.com. Alice Bob | | | | |(1) (SIP) INVITE | |----------------------->| |(4) (SIP) 200 OK | |<-----------------------| |(5) (SIP) ACK | |----------------------->| |(6) (MSRP) SEND | |----------------------->| |(7) (MSRP) 200 OK | |<-----------------------| |(8) (MSRP) SEND | |<-----------------------| |(9) (MSRP) 200 OK | |----------------------->| |(10) (SIP) BYE | |----------------------->| |(11) (SIP) 200 OK | |<-----------------------| | | | | 1. Alice constructs a local URL of msrp://alicepc.example.com:7777/iau39;tcp . Alice->Bob (SIP): INVITE sip:firstname.lastname@example.org v=0 o=alice 2890844557 2890844559 IN IP4 alicepc.example.com s= c=IN IP4 alicepc.example.com t=0 0 m=message 9 msrp * a=accept-types:text/plain a=path:msrp://alicepc.example.com:7777/iau39;tcp 2. Bob listens on port 8888, and sends the following response: 3. Bob->Alice (SIP): 200 OK v=0 o=bob 2890844612 2890844616 IN IP4 bob.example.com s= c=IN IP4 bob.example.com t=0 0 m=message 9 msrp * a=accept-types:text/plain a=path:msrp://bob.example.com:8888/9di4ea;tcp 4. Alice->Bob (SIP): ACK 5. (Alice opens connection to Bob.) Alice->Bob (MSRP): MSRP d93kswow SEND To-Path:msrp://bob.example.com:8888/9di4ea;tcp From-Path:msrp://alicepc.example.com:7777/iau39;tcp Message-ID: 12339sdqwer Content-Type:text/plain Hi, I'm Alice! -------d93kswow$ 6. Bob->Alice (MSRP): MSRP d93kswow 200 OK To-Path:msrp://bob.example.com:8888/9di4ea;tcp From-Path:msrp://alicepc.example.com:7777/iau39;tcp -------d93kswow$ 7. Bob->Alice (MSRP): MSRP dkei38sd SEND To-Path:msrp://alice.example.com:7777/iau39;tcp From-Path:msrp://bob.example.com:8888/9di4ea;tcp Message-ID: 456 Content-Type:text/plain Hi, Alice! I'm Bob! -------dkei38sd$ 8. Alice->Bob (MSRP): MSRP dkei38sd 200 OK To-Path:msrp://alice.example.com:7777/iau39;tcp From-Path:msrp://bob.example.com:8888/9di4ea;tcp -------dkei38sd$ 9. Alice->Bob (SIP): BYE Alice invalidates local session state. 10. Bob invalidates local state for the session. Bob->Alice (SIP): 200 OK 11.2 Chunked Message For an example of a chunked message, see the example in Section 4.1. 11.3 System Message Sysadmin->Alice (MSRP): MSRP d93kswow SEND To-Path:msrp://alicepc.example.com:8888/9di4ea;tcp From-Path:msrp://example.com:7777/iau39;tcp Message-ID: 12339sdqwer Report-Failure: no Report-Success: no Content-Type:text/plain The system is going down in 5 minutes -------d93kswow$ 11.4 Positive Report Alice->Bob (MSRP): MSRP d93kswow SEND To-Path:msrp://bob.example.com:8888/9di4ea;tcp From-Path:msrp://alicepc.example.com:7777/iau39;tcp Message-ID: 12339sdqwer Report-Success: yes Content-Type:text/html <html><body> <p>Here is that important link... <a href="www.example.com/foobar">foobar</a> </p> </body></html> -------d93kswow$ Bob->Alice (MSRP): MSRP d93kswow 200 OK To-Path:msrp://alicepc.example.com:7777/iau39;tcp From-Path:msrp://bob.example.com:8888/9di4ea;tcp -------d93kswow$ Bob->Alice (MSRP): MSRP dkei38sd SEND To-Path:msrp://alicepc.example.com:7777/iau39;tcp From-Path:msrp://bob.example.com:8888/9di4ea;tcp Message-ID: 12339sdqwer Status: 000 200 OK -------dkei38sd$ 11.5 Forked IM Traditional IM systems generally do a poor job of handling multiple simultaneous IM clients online for the same person. While some do a better job than many existing systems, handling of multiple clients is fairly crude. This becomes a much more significant issue when always-on mobile devices are available, but when it is desirable to use them only if another IM client is not available. Using SIP makes rendezvous decisions explicit, deterministic, and very flexible; instead "pager-mode" IM systems use implicit implementation-specific decisions which IM clients cannot influence. 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 . As a result, rendezvous policy is managed consistently for each address of record. The following example shows Juliet with several IM clients where she can be reached. Each of these has a unique SIP Contact and MSRP session. The example takes advantage of SIP's capability to "fork" an invitation to several Contacts in parallel, in sequence, or in combination. Juliet has registered from her chamber, the balcony, her PDA, and as a last resort, you can leave a message with her Nurse. Juliet's contacts are listed below. The q-values express relative preference (q=1.0 is the highest preference). We query for a list of Juliet's contacts by sending a REGISTER: REGISTER sip:thecapulets.example.com SIP/2.0 To: Juliet <sip:email@example.com> From: Juliet <sip:firstname.lastname@example.org>;tag=12345 Call-ID: 09887877 CSeq: 772 REGISTER The Response contains her Contacts: SIP/2.0 200 OK To: Juliet <sip:email@example.com> From: Juliet <sip:firstname.lastname@example.org>;tag=12345 Call-ID: 09887877 CSeq: 771 REGISTER Contact: <sip:email@example.com> ;q=0.9;expires=3600 Contact: <sip:firstname.lastname@example.org> ;q=1.0;expires=3600 Contact: <sip:email@example.com>;q=0.4;expires=3600 Contact: <sip:firstname.lastname@example.org>;q=0.1;expires=3600 When Romeo opens his IM program, he selects Juliet and types the message "art thou hither?" (instead of "you there?"). His client sends a SIP invitation to sip:email@example.com. The Proxy there tries first the balcony and the chamber simultaneously. A client is running on both those systems, both of which setup early sessions of MSRP with Romeo's client. The client automatically sends the message over the MSRPS to the two MSPR URIs involved. After a delay of a several seconds with no reply or activity from Juliet, the proxy cancels the invitation at her first two contacts, and forwards the invitation on to Juliet's PDA. Since her father is talking to her about her wedding, she selects "Do Not Disturb" on her PDA, which sends a "Busy Here" response. The proxy then tries the Nurse, who answers and tells Romeo what is going on. Romeo Juliet's Juliet/ Juliet/ Juliet/ Nurse Proxy balcony chamber PDA | | | | | | |--INVITE--->| | |(1) (SIP) INVITE| |----------------------->| |(4) (SIP) 200 OK| |<-----------------------| |(5) (SIP) ACK| |----------------------->| |(6) (MSRP) SEND| |----------------------->| |(7) (MSRP) 200 OK|--INVITE--->| | |<-----------------------| |(8) (MSRP) SEND| |<-----------------------| |(9) (MSRP) 200 OK| |----------------------->| |(10) (SIP) BYE| |----------------------->| |(11) (SIP) 200 OK|<----180----| | |<-----------------------|| | |<----180----| | | 1. Alice constructs a local URL of msrp://alicepc.atlanta.com:7777/iau39 and listens for a connection on TCP port 7777. Alice->Bob (SIP): INVITE sip:firstname.lastname@example.org v=0 o=alice 2890844557 2890844559 IN IP4 host.anywhere.com s= c=IN IP4 fillername t=0 0 m=message 9999 msrp * a=accept-types:text/plain a=path:msrp://alicepc.atlanta.com:7777/iau39 2. 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 * a=accept-types:text/plain a=path:msrp://bob.atlanta.com:8888/9di4ea 3. Alice->Bob (SIP): ACK 4. (Alice opens connection to Bob. This may occur in parallel with the previous step.) Alice->Bob (MSRP): MSRP SEND Boundary: d93kswow To-Path:msrp://bob.atlanta.com:8888/9di4ea From-Path:msrp://alicepc.atlanta.com:7777/iau39 TR-ID: 123 Message-ID: 123 Content-Type: "text/plain" Hi, I'm Alice! -------d93kswow$ 5. Bob->Alice (MSRP): MSRP 200 OK Boundary: 839s9ed To-Path:msrp://bob.atlanta.com:8888/9di4ea From-Path:msrp://alicepc.atlanta.com:7777/iau39 TR-ID: 123 -------839s9ed$ 6. Bob->Alice (MSRP): MSRP SEND Boundary: dkei38sd To-Path:msrp://alice.atlanta.com:7777/iau39 From-Path:msrp://bob.atlanta.com:8888/9di4ea TR-ID: 456 Message-ID: 456 Content-Type: "text/plain" Hi, Alice! I'm Bob! -------dkei38sd$ 7. Alice->Bob (MSRP):| | |---PRACK---------------->| | | | |<----200-----------------| | | | |<===Early MSRP 200 OK Boundary: diw3ids To-Path:msrp://alice.atlanta.com:7777/iau39 From-Path:msrp://bob.atlanta.com:8888/9di4ea TR-ID: 456 -------diw3ids$ 8. Alice->Bob (SIP): BYE Alice invalidates local session state. 9. Bob invalidates local state for the session. Bob->Alice (SIP): 200 OK 8. IANA Considerations 8.1Session==>| art thou hither? | | | | | | | | | |--INVITE---------------->| | | | |<----180-----------------| | | |<----180----| | | | | |---PRACK----------------------------->| | | |<----200------------------------------| | | |<========Early MSRP PortSession==========>| 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 tommorrow.... | 12. Extensibility MSRP uses TCP port XYX,was designed to be determined by IANA after this documentonly minimally extensible. New MSRP Methods, Headers, and status codes can be defined in standards track RFCs. There is approved for publication. Usageno registry of this value is described in Section 6.1 8.2 MSRP URL Schema This document definesheaders, methods, or status codes, since the URL schemanumber of "msrp" "msrps", "smsrp",new elements and "smsrps". 8.2.1 Syntax See Section 6.1. 8.2.2 Character Encoding See Section 6.1. 8.2.3 Intended Usage See Section 6.1. 8.2.4 Protocols The Message Session Relay Protocol (MSRP). 8.2.5 Security Considerations See Section 9. 8.2.6 Relevant Publications RFCXXXX [Notetotal extensions is expected to RFC Editor: Please replace RFCXXXX in the above paragraph with the actualbe very small. MSRP does not contain a version number assignedor any negotiation mechanism to this document. 8.3 SDP Parameters This document registers the following SDP parametersrequire or discover new features. MSRP was designed to use lists of URLs instead of a single URL in the sdp-parameters registry: 8.3.1 Accept Types Attribute-name: accept-types Long-form Attribute Name Acceptable MIME Types Type: Media level Subject to Charset Attribute No PurposeTo-Path and Appropriate Values See Section 5.2. 8.3.2 Wrapped Types Attribute-name: accept-wrapped-types Long-form Attribute Name Acceptable MIME Types Inside Wrappers Type: Media level SubjectFrom-Path headers in anticipation of relay or gateway functionality being added. In addition, msrp: and msrps: URLs can contain parameters which are extensible. 13. CPIM compatibility MSRP sessions may be gatewayed to Charset Attribute No Purposeother CPIM compatible protocols. If this occurs, the gateway MUST maintain session state, and Appropriate Values See Section 5.3. 8.3.3 Path Attribute-name: path Long-form Attribute NameMUST translate between the MSRP URL Path Type: Media level Subject to Charset Attribute No Purposesession semantics and Appropriate Values See Section 5.4. 8.4 IANA registration forms for DSN types 8.4.1 IANA registration form for address-type This document registers a new 'address-type' for use in conjunction with RFC1894. The authors requestCPIM semantics that these valuesdo not include a concept of sessions. Furthermore, when one endpoint of the session is a CPIM gateway, instant messages SHOULD be recordedwrapped in the IANA registry for DSN 'address-type'. Proposed Address name: msrp-address-type Syntax: See Section 6.1 8.4.2 IANA registration form for MTA-name-type This document registers"message/cpim"  bodies. Such a new 'MTA-name-type' for usegateway MUST include "message/cpim" as the first entry in conjunction with RFC1894. The authors requestits SDP accept-types attribute. MSRP endpoints sending instant messages to a peer that these values be recordedhas included 'message/cpim" as the first entry in the IANA registry for DSN 'MTA-name-type'. Proposed Address name: msrp-name-type Syntax: See See Section 6.1 9.accept-types attribute SHOULD encapsulate all instant message bodies in "message/ cpim" wrappers. All MSRP endpoints MUST support the message/cpim type, and SHOULD support the S/MIME features of that format. 14. Security Considerations ThereInstant Messaging systems are used to exchange a numbervariety of security considerationssensitive 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 MSRP, somecommunicating important information. Like many communications systems, the properties of which are mentioned elsewhere in this document. This section discusses those further,Integrity and introduces some new ones. 9.1 TLSConfidentiality of the exchanged information, along with the possibility of Anonymous communications, and knowing you are communicating with the MSRPS Scheme Allcorrect other party are required. MSRP devices must support TLS, with at leastpushes many of the TLS_RSA_WITH_AES_128_CBC_SHA  cipher suite. Other cipher suites MAY be supported.hard problems to SIP when SIP sets up the session, but some of the problems remain. Spam and DoS attacks are also very relevant to IM systems. MSRP does not define a separate TCP portneeds to provide confidentiality and integrity for TLS connections. This means that all MSRP server devices, that is, all devicesthe messages it transfers. It also needs to provide assurances the connected host is the host that listen for TCP connections, MUST be preparedit meant to connect to handle both TLSand plain text connections onthat the same port.connection has not been hijacked. When a device accepts ausing only TCP connection, it MUST watch for the TLS handshake messages to determine ifconnections, MSRP security is fairly weak. If host A is contacting B, B passes its hostname and a particular connection uses TLS.secret to A using SIP. If the first data receivedSIP offer or answer is not part of a startTLS request, the device ceasesor S/MIME  protected, anyone can see this secret. A then connects to watch for the TLS handshake until it readsthe entire message. Onceprovided host name and passes the message has been completely received,secret in the device resumes watching forclear across the start TLS message. Any MSRP device MAY refuse to accept a given request over a non-TLSconnection by returning a 426 response. MSRP devices actingto B. A assumes that it is talking to B based on where it sent the SYN packet and then delivers the secret in plain text across the roleconnections. B assumes it is talking to A because the host on the other end of TCP client MAY perform a TLS handshake at any time, as long asthe request occurs between MSRP messages. The endpoint MUST NOT sendconnection delivered the secret. An attacker that could ACK the SYN packet could insert itself as a start TLS requestman in the middle of an MSRP message. The working group considered only requiringin the endpoint to watch for aconnection. When using TLS handshake atconnections, the beginning ofsecurity is significantly improved. We assume that the session. However,host accepting the endpoint should be able to determine ifconnection has a new message iscertificate from a startwell know certificate authority. Furthermore, we assume that the SIP signaling to set up the session is protected with TLS request or an MSRP request by only reading ahead three bytes. Therefore,(using sips). In this case, when host A contacts host B, the working group chosesecret is passed through a SIP confidential channel to allowA. A connects with TLS to B. B presents a sessionvalid certificate, so A knows it really is connected to switchB. A then delivers the secret provided by B, so that B can verify it is connected to TLSA. In this case, a rogue SIP Proxy can see the secret in mid-stream,the SIP signaling traffic and could potentially insert itself as longa man-in-the-middle. Realistically, using TLS is only feasible when connecting to gateways or relays , as the switch occurs between MRSP messages. There have since been proposalstypes of hosts that we only allow start-tls at connection time. Do weend clients use for sending instant messages are unlikely to have a consensus here one waylong term stable IP address or a stable DNS name that a certificate can bind to. In addition, the cost of server certificates from well known certificate authorities is currently too high for the vast majority of end users to even consider getting one for each client. The only real security for connections without relays is achieved using S/MIME. This does not require the other?actual endpoint to have certificates from a well known certificate authority. The "msrps"Identity  and "smsrps" URI schema indicates that the connection MUST be protectedCertificates  mechanism with TLS. Relay handlingSIP provides S/MIME based delivery of "msrps"a secret between A and "smsrps" are beyondB. No SIP intermediary except the scope of this document. However, any relay specification MUSTexplicitly specify this. MSRP requests for "msrps" URLs MUST be sent over TLS protected connections. If a device receives a request for a "msrps" or "smsrps" URL over an unprotected connection, it MUST rejecttrusted authentication service (one per user) can see the request with a 426 response. 9.1.1 Sensitivity of Session URLssecret. The URLs sent inS/MIME encryption of the SDP offer/answer exchange for a MSRP session arecan also be used by the endpointsSIP to identify each other. If an attacker were ableexchange keying material that can be used in MRSP. The MSRP session can then use S/MIME with this keying material to acquireencrypt and sign messages sent over MSRP. The connection can still be hijacked since the session URL, either by guessing it or by eavesdropping, theresecret is a window of opportunitysent in which the attacker could hijack the session connecting and sending a MSRP requestclear text to the listening device before the legitimate peer. Becauseother end of the TCP connection, but this sensitivity, these URLs SHOULD be constructed in a way to make them difficult to guess,risk is mitigated if all the MSRP content is encrypted and shouldsigned with S/MIME. MSRP can not be sufficiently random so thatused as an amplifier for DoS attacks, but it is unlikely tocan be reused. All mechanismsused to transport these URLs SHOULD be protected from eavesdroppers and man-in-the-middle attacks. Thereforeform a MSRP device MUST support the use of TLS for all MSRP messages. Further, MSRP connections SHOULD actually be protecteddistributed attack to consume TCP connection resource on servers. The attacker, Eve, sends an SIP INVITE with no offer to Alice. Alice returns a 200 with TLS. Further,an offer and Eve returns an answer with the SDP that indicates that her MSRP endpoint MUST be capable of usingaddress is the security featuresaddress of Tom. Since Alice sent the signaling protocol in orderoffer, Alice will initiate a connection to protect the SDP exchange and SHOULD actually use themTom using up resources on all such exchanges. End-to-end protection schemes SHOULD be preferred over hop-by-hop schemes for protection ofTom's server. Given the SDP exchange. 9.1.2 End to End Protectionhuge number 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, integrityIM clients, and authentication of instant messages. Therefore MSRP endpoints MUST supportthe end-to-end encryption and integrity of bodies sent via SEND requests using Secure MIME (S/MIME) . Noterelatively few TCP connections that while each protected body could use separate keying material,most servers support, this is inefficienta fairly straightforward attack. SIP is attempting to address issues in that it requiresdealing with spam. The spam issue is probably best dealt with at the SIP level when an independent public key operation for each message. Endpoints wishingMSRP session is initiated and not at the MSRP level. TLS is used to invoke end-to-end protection of message sessions SHOULD exchange symmetric keys in SDP k-lines,authenticate devices and use secret key encryption onto provide integrity and confidentiality for each MSRP message. When symmetric keys are present inthe SDP, the offer-answer exchangeheaders being transported. MSRP elements MUST be protected from eavesdroppingimplement TLS and tampering usingMUST also implement the appropriate facilitiesTLS ClientExtendedHello extended hello information for server name indication as described in . A TLS cipher-suite of TLS_RSA_WITH_AES_128_CBC_SHA  MUST be supported (other cipher-suites MAY also be supported). Since MSRP carries arbitrary MIME content, it can trivially carry S/ MIME protected messages as well. All MSRP implementations MUST support the signaling protocol. For example,multipart/signed MIME type even if they do not support S/ MIME. Since SIP can carry a session key, S/MIME messages in the signaling protocol is SIP, the SDP exchange MUSTcontext of a session could also be protected using S/MIME. 9.1.3 CPIM compatibilitya key-wrapped shared secret  provided in the session setup. 15. IANA Considerations 15.1 MSRP sessions may be gatewayedPort MSRP uses TCP port XYX, to other CPIM compatible protocols. Ifbe determined by IANA after this occurs,document is approved for publication. Usage of this value is described in Section 5 15.2 MSRP URL Schemes This document defines the gateway MUST maintain session state,URL schemes of "msrp" and MUST translate between"msrps". Syntax See Section 5. Character Encoding See Section 5. Intended Usage See Section 5. Protocols The Message Session Relay Protocol (MSRP). Security Considerations See Section 14. Relevant Publications RFCXXXX [Note to RFC Editor: Please replace RFCXXXX in the above paragraph with the actual number assigned to this document. 15.3 SDP Parameters This document registers the following SDP parameters in the sdp-parameters registry: 15.3.1 Accept Types Attribute-name: accept-types Long-form Attribute Name Acceptable MIME Types Type: Media level Subject to Charset Attribute No Purpose and Appropriate Values See Section 7.1. 15.3.2 Wrapped Types Attribute-name: accept-wrapped-types Long-form Attribute Name Acceptable MIME Types Inside Wrappers Type: Media level Subject to Charset Attribute No Purpose and Appropriate Values See Section 7.1. 15.3.3 Path Attribute-name: path Long-form Attribute Name MSRP session semanticsURL Path Type: Media level Subject to Charset Attribute No Purpose and CPIM semantics that do not include a concept of sessions. Furthermore, when one endpoint of the session isAppropriate Values See Section 7.1.1. 15.4 IANA registration forms for DSN types 15.4.1 IANA registration form for address-type This document registers a CPIM gateway, instant messages SHOULDnew 'address-type' for use in conjunction with RFC1894. The authors request that these values be wrappedrecorded in "message/cpim"  bodies. Such a gateway MUST include "message/cpim" asthe first entry in its SDP accept-types attribute. MSRP endpoints sending instant messages toIANA registry for DSN 'address-type'. Proposed Address name: msrp-address-type Syntax: See Section 5 15.4.2 IANA registration form for MTA-name-type This document registers a peernew 'MTA-name-type' for use in conjunction with RFC1894. The authors request that has included 'message/cpim" as the first entrythese values be recorded in the accept-types attribute SHOULD encapsulate all instant message bodiesIANA registry for DSN 'MTA-name-type'. Proposed Address name: msrp-name-type Syntax: See Section 5 16. Change History 16.1 draft-ietf-simple-message-sessions-07 Significant re-write to attempt to improve readability. Added maximum size parameter in "message/ cpim" wrappers. All MSRP endpoints MUST support the message/cpim type, and SHOULD supportaccept-types Changed the S/MIME features of that format. 9.1.4 PKI Considerations Several aspectsBoundary field to be part of MSRP will benefit from being used inthe context ofstart-line rather than a public key infrastructure. For example,header field. Removed the MSRPS scheme allows,TR-IDheader, 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 needchanged request-response matching to be protected. In SIP,based on the preferred mechanism for this would be S/MIME,Boundary field value. Responses still contain the TR-ID header, which would also benefitmust match the Boundary from a PKI. However, all of these features may be used without PKI. Each endpoint could instead use self signed certificates. This will,the request. Removed transport selection from URL scheme and added the "tcp" parameter. Added description of course, be less convenient than with a PKI, in that there would be no certificate authority to act asthe "simple" mode with no transaction responses, and made mode selection dependent on the reporting level requested for a trusted introducer. Peers would be requiredgive message. Changed the DSN section to exchange certificates priorreflect separate request of success and failure reports. Enhanced REPORT method to securely communicating. Since, at leastbe useful even without a payload. removed SRV usage for the immediate future, any given MSRP implementationURL resolution. This is likelyonly used for relay discovery, and therefore should be moved to communicate with at least some peersthe relay draft. Added discussion about late REPORT handling. Asserted that do not have a PKI available, MSRP implementations SHOULD supportREPORT requests are always sent in simple mode. Removed the use of self-signed certificates, and SHOULD supportdependency on multipart/byteranges for fragmentation. Incorporated the ability to configure lists of trusted certificates. To Do: Add text discussionByte-Range header into the base MSRP header set. Removed the VISIT method. Change to use of TLS certificates in more detail. 10. Changes from Previous Draft Versions This sectionSEND to be deleted priorserve the purpose formerly reserved to publication as an RFC 10.1VISIT. 16.2 draft-ietf-simple-message-sessions-06 Changed To and From header names to To-Path and From-Path. Added more clarification to path handling, and commentary on how it enables relay usage. Changed mechanism for signaling transport and TLS protection into the MSRP URL, rather than the SDP M-Line. Removed length field from start line and added Boundary header field and Closing field. Added recommendation to fragment any content over 2k. Added Rohan's proposal to make offerer connect to answerer. (With open issue for more discussion.) Changed To-Path and From-Path usage in responses to indicate the destination and source of the response, rather than merely copy from the associated request. Updated DSN section. Added text on field usage. Fixed change section--changesTR-ID header from version 05 were erroneously attributed to 04. 10.216.3 draft-ietf-simple-message-sessions-05 Changed the use of session URLs. Instead of a single session URL, each endpoint is identified by a distinct URL. MSRP requests will put the destination URL in a To header, and the sender URL in a From header. Changed the SDP exchange of MSRP URLs to handle the URL for each endpoint. Further, changed the SDP attribute to support a list of URLs in each direction. This may be used with relays to exchange paths, rather than single URLs. MSRP endpoints must be able to intelligently process such a list if received. This document does not, however, describe how to generate such a list. Added section for Delivery Status Notification handling, and added associated entries into the syntax definition. Added content fragmentation section. Removed recommendation to start separate session for large transfers. Corrected some mistakes in the syntax definitions. Added Chris Boulton as a co-author for his contribution of the DSN text. 10.316.4 draft-ietf-simple-message-sessions-04 Removed the direction attribute. Rather than using a comedia styled direction negotiation, we just state that the answerer opens any needed connection. 10.416.5 draft-ietf-simple-message-sessions-03 Removed all specification of relays, and all features specific to the use of relays. The working group has chosen to move relay work into a separate effort, in order to advance the base specification. (The MSRP acronym is unchanged for the sake of convenience.) This included removal of the BIND method, all response codes specific to BIND, Digest Authentication, and the inactivity timeout. 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. 10.516.6 draft-ietf-simple-message-sessions-02 Moved all content type negotiation from the "m"-line format list into "a"-line attributes. Added the accept-types attribute. This is due to the fact that the sdp format-list syntax is not conducive to encoding MIME content types values. Added "other-method" construction to the message syntax to allow for extensible methods. Consolidated all syntax definitions into the same section. Cleaned up ABNF for digest challenge and response syntax. Changed the session inactivity timeout to 12 minutes. Required support for the SHA1 alogorithm.algorithm. Required support for the message/cpim format. Fixed lots of editorial issues. Documented a number of open issues from recent list discussions. 10.616.7 draft-ietf-simple-message-sessions-01 Abstract rewritten. Added architectural considerations section. The m-line format list now only describes the root body part for a request. Contained body part types may be described in the "accept-wrapped-types" a-line attribute. Added a standard dummy value for the m-line port field. Clarified that a zero in this field has normal SDP meaning. Clarified that an endpoint is globally configured as to whether or not to use a relay. There is no relay discovery mechanism intrinsic to MSRP. Changed digest algorithm to SHA1. Added TR-ID and S-URI to the hash for digest authentication. CMS usage replaced with S/MIME. TLS and MSRPSmsrps: 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. 10.716.8 draft-ietf-simple-message-sessions-00 Name changed to reflect status as a work group item. This version no longer supports the use of multiple sessions across a single TCP session. This has several related changes: There is now a single session URI, rather than a separate one for each endpoint. The session URI is not required to be in requests other than BIND and VISIT, as the session can be determined based on the connection on which it arrives. BIND and VISIT now create soft state, eliminating the need for the RELEASE and LEAVE methods. The MSRP URL format was changed to better reflect generic URL standards. URL comparison and resolution rules were added. SRV usage added. Determination of host and visitor roles now uses a direction attribute much like the one used in COMEDIA. Format list negotiation expanded to allow a "prefer these formats but try anything" semantic Clarified handling of direction notification failures. Clarified signaling associated with session failure due to dropped connections. Clarified security related motivations for MSRP. Removed MIKEY dependency for session key exchange. Simple usage of k-lines in SDP, where the SDP exchange is protected end-to-end seems sufficient. 10.816.9 draft-campbell-simple-im-sessions-01 Version 01 is a significant re-write. References to COMEDIA were removed, as it was determined that COMEDIA would not allow connections to be used bidirectional in the presence of NATs. Significantly more discussion of a concrete mechanism has been added to make up for no longer using COMEDIA. Additionally, this draft and draft-campbell-cpimmsg-sessions (which would have also changed drastically) have now been combined into this single draft. 11.17. Contributors and Acknowledgments In addition to the editor, The following people contributed extensive work to this document: Chris BoultonBoulton, Cullen JenningsJennings, Paul KyzivatKyzivat, Rohan MahyMahy, Adam RoachRoach, Jonathan RosenbergRosenberg, Robert Sparks 12. AcknowledgmentsSparks. The following people contributed substantial discussion and feedback to this ongoing effort: Allison MankinMankin, Jon PetersonPeterson, Brian RosenRosen, Dean WillisWillis, Aki NiemiNiemi, Hisham KhartabilKhartabil, Pekka PessiPessi, Orit Levin 13.Levin. 18. References 13.118.1 Normative References  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.  Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.  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, Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.  Atkins, D. and G. Klyne, "Common Presence and Instant Messaging Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in progress), January 2003.  Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996.  Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.  Troost, R., Dorner, S. and J. Vincent, "Instant Messaging / Presence Protocol Requirements",K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2779, February 2000. 2183, August 1997.  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URL):(URI): Generic Syntax", RFC 2396, August 1998.  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003.  Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.  Atkins, D. and G. Klyne, "Common Presence and Instant MessagingMessaging: 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"Advanced Encryption Standard (AES) Ciphersuites for Transport Layer SecuritySecur ity (TLS)", RFC 3268, June 2002.  Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.  Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996.  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 13.218.2 Informational References  Campbell, B. Johnston, A. and J. Rosenberg,O. Levin, "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 FrameworkCall Control - Conferencing for SIP", draft-ietf-sipping-cc-framework-02User Agents", draft-ietf-sipping-cc-conferencing-03 (work in progress), May 2003. February 2004.  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-04draft-ietf-sipping-3pcc-06 (work in progress), June 2003. January 2004.  Sparks, R. and A. Johnston, "Session Initiation Protocol Call Control - Transfer", draft-ietf-sipping-cc-transfer-01draft-ietf-sipping-cc-transfer-02 (work in progress), February 2003.  Camarillo, G., Marshall, W. and J.2004.  Campbell, B., Rosenberg, "Integration of Resource ManagementJ., Schulzrinne, H., Huitema, C. and SessionD. Gurle, "Session Initiation Protocol (SIP)",(SIP) Extension for Instant Messaging", RFC 3312, October3428, December 2002.  Mahy, R., "Benefits and Motivation for Session Mode Instant Messaging", draft-mahy-simple-why-session-mode-00 (work in progress), February 2004.  Mahy, R. and C. Jennings, "Relays for the Message Session Relay Protocol (MSRP)", draft-ietf-simple-msrp-relays-01.txt (work in progress), July 2004.  Peterson, J., "A Privacy MechanismJ. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 3323 , November 2002. draft-ietf-sip-identity-02 (work in progress), May 2004.  Jennings, C. and J. Peterson, "Certificate Management Service for SIP", draft-jennings-sipping-certs-03 (work in progress), May 2004.  Yon, D., "Connection-Oriented Media Transport in SDP", draft-ietf-mmusic-sdp-comedia-05 (work in progress), March 2003.  Peterson, J., "A Common Profile for Instant Messaging (CPIM)", draft-ietf-impp-im-04 (work in progress), August 2003.  Yon, D., "Connection-Oriented Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, December 2001.  Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.  Camarillo, G. and H. Schulzrinne, "Early Media Transportand Ringing Tone Generation in SDP", draft-ietf-mmusic-sdp-comedia-05the Session Initiation Protocol (SIP)", draft-ietf-sipping-early-media-02 (work in progress), March 2003. Author's AddressJune 2004.  Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", draft-ietf-xmpp-im-22 (work in progress), April 2004.  Rosenberg, J., "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", draft-ietf-sip-callee-caps-03 (work in progress), January 2004. Authors' Addresses Ben Campbell dynamicsoft 5100 Tennyson Parkway(editor) EMail: email@example.com Rohan Mahy Cisco Systems, Inc. 5617 Scotts Valley Drive, Suite 1200 Plano, TX 75024200 Scotts Valley, CA 95066 USA EMail: firstname.lastname@example.org Cullen Jennings Cisco Systems, Inc. 170 West Tasman Dr. MS: SJC-21/2 San Jose, CA 95134 USA EMail: email@example.com@cisco.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual propertyIntellectual 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; neithernor does it represent that it has made any independent effort to identify any such rights. Information on the IETF'sprocedures with respect to rights in standards-track and standards-related documentationRFC documents can be found in BCP-11.BCP 78 and BCP 79. Copies of claims of rightsIPR disclosures made available for publicationto 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 implementorsimplementers or users of this specification can be obtained from the IETF Secretariat.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 whichthat may cover technology that may be required to practiceimplement 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 purposeat firstname.lastname@example.org. Disclaimer 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.Validity This document and the information contained herein isare provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMSDISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.