SIMPLE WG                                               B. Campbell, Ed.
Internet-Draft                                          Estacado Systems
Expires: August 24, 2005                                    R. Mahy, Ed.
                                                        C. Jennings, Ed.
                                                     Cisco Systems, Inc.
                                                       February 20, 2005

                   The Message Session Relay Protocol

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as

   Internet-Drafts 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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 24, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   This document describes the Message Session Relay Protocol (MSRP), a
   protocol for transmitting a series of related instant messages in the
   context of a session.  Message sessions are treated like any other

Campbell, et al.         Expires August 24, 2005                [Page 1]

Internet-Draft                    MSRP                     February 2005

   media stream when setup via a rendezvous or session setup protocol
   such as the Session Initiation Protocol (SIP).

Table of Contents

   1.   Conventions  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.   Introduction and Background  . . . . . . . . . . . . . . . .   4
   3.   Applicability of MSRP  . . . . . . . . . . . . . . . . . . .   5
   4.   Protocol Overview  . . . . . . . . . . . . . . . . . . . . .   6
   5.   Key Concepts . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.1  MSRP Framing and Message Chunking  . . . . . . . . . . . .   8
     5.2  MSRP Addressing  . . . . . . . . . . . . . . . . . . . . .   9
     5.3  MSRP Transaction and Report Model  . . . . . . . . . . . .  10
     5.4  MSRP Connection Model  . . . . . . . . . . . . . . . . . .  11
   6.   MSRP URLs  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     6.1  MSRP URL Comparison  . . . . . . . . . . . . . . . . . . .  14
     6.2  Resolving MSRP Host Device . . . . . . . . . . . . . . . .  14
   7.   Method-Specific Behavior . . . . . . . . . . . . . . . . . .  15
     7.1  Constructing Requests  . . . . . . . . . . . . . . . . . .  15
       7.1.1  Delivering SEND requests . . . . . . . . . . . . . . .  16
       7.1.2  Sending REPORT requests  . . . . . . . . . . . . . . .  18
       7.1.3  Failure REPORT Generation  . . . . . . . . . . . . . .  19
     7.2  Constructing Responses . . . . . . . . . . . . . . . . . .  20
     7.3  Receiving Requests . . . . . . . . . . . . . . . . . . . .  21
       7.3.1  Receiving SEND requests  . . . . . . . . . . . . . . .  21
       7.3.2  Receiving REPORT requests  . . . . . . . . . . . . . .  22
   8.   Using MSRP with SIP  . . . . . . . . . . . . . . . . . . . .  23
     8.1  SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . .  23
       8.1.1  URL Negotiations . . . . . . . . . . . . . . . . . . .  25
       8.1.2  Path Attributes with Multiple URLs . . . . . . . . . .  26
       8.1.3  SDP Connection and Media Lines . . . . . . . . . . . .  27
       8.1.4  Updated SDP Offers . . . . . . . . . . . . . . . . . .  28
       8.1.5  Example SDP Exchange . . . . . . . . . . . . . . . . .  28
       8.1.6  Connection Negotiation . . . . . . . . . . . . . . . .  29
     8.2  MSRP User Experience with SIP  . . . . . . . . . . . . . .  29
   9.   Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . .  30
   10.  Response Code Descriptions . . . . . . . . . . . . . . . . .  32
     10.1   200  . . . . . . . . . . . . . . . . . . . . . . . . . .  32
     10.2   400  . . . . . . . . . . . . . . . . . . . . . . . . . .  32
     10.3   403  . . . . . . . . . . . . . . . . . . . . . . . . . .  32
     10.4   408  . . . . . . . . . . . . . . . . . . . . . . . . . .  32
     10.5   413  . . . . . . . . . . . . . . . . . . . . . . . . . .  33
     10.6   415  . . . . . . . . . . . . . . . . . . . . . . . . . .  33
     10.7   423  . . . . . . . . . . . . . . . . . . . . . . . . . .  33
     10.8   426  . . . . . . . . . . . . . . . . . . . . . . . . . .  33
     10.9   481  . . . . . . . . . . . . . . . . . . . . . . . . . .  33
     10.10  501  . . . . . . . . . . . . . . . . . . . . . . . . . .  33
     10.11  506  . . . . . . . . . . . . . . . . . . . . . . . . . .  33

Campbell, et al.         Expires August 24, 2005                [Page 2]

Internet-Draft                    MSRP                     February 2005

   11.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  34
     11.1   Basic IM session . . . . . . . . . . . . . . . . . . . .  34
     11.2   Message with XHTML Content . . . . . . . . . . . . . . .  36
     11.3   Chunked Message  . . . . . . . . . . . . . . . . . . . .  36
     11.4   System Message . . . . . . . . . . . . . . . . . . . . .  36
     11.5   Positive Report  . . . . . . . . . . . . . . . . . . . .  37
     11.6   Forked IM  . . . . . . . . . . . . . . . . . . . . . . .  37
   12.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . .  40
   13.  CPIM compatibility . . . . . . . . . . . . . . . . . . . . .  40
   14.  Security Considerations  . . . . . . . . . . . . . . . . . .  41
     14.1   Transport Level Protection . . . . . . . . . . . . . . .  42
     14.2   S/MIME . . . . . . . . . . . . . . . . . . . . . . . . .  43
     14.3   Other Security Concerns  . . . . . . . . . . . . . . . .  44
   15.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  45
     15.1   MSRP Port  . . . . . . . . . . . . . . . . . . . . . . .  45
     15.2   MSRP URL Schemes . . . . . . . . . . . . . . . . . . . .  45
     15.3   SDP Transport Protocol . . . . . . . . . . . . . . . . .  46
     15.4   SDP Attribute Names  . . . . . . . . . . . . . . . . . .  46
       15.4.1   Accept Types . . . . . . . . . . . . . . . . . . . .  46
       15.4.2   Wrapped Types  . . . . . . . . . . . . . . . . . . .  46
       15.4.3   Max Size . . . . . . . . . . . . . . . . . . . . . .  47
       15.4.4   Path . . . . . . . . . . . . . . . . . . . . . . . .  47
   16.  Change History . . . . . . . . . . . . . . . . . . . . . . .  47
     16.1   draft-ietf-simple-message-sessions-10  . . . . . . . . .  47
     16.2   draft-ietf-simple-message-sessions-09  . . . . . . . . .  48
     16.3   draft-ietf-simple-message-sessions-08  . . . . . . . . .  48
     16.4   draft-ietf-simple-message-sessions-07  . . . . . . . . .  49
     16.5   draft-ietf-simple-message-sessions-06  . . . . . . . . .  49
     16.6   draft-ietf-simple-message-sessions-05  . . . . . . . . .  50
     16.7   draft-ietf-simple-message-sessions-04  . . . . . . . . .  50
     16.8   draft-ietf-simple-message-sessions-03  . . . . . . . . .  50
     16.9   draft-ietf-simple-message-sessions-02  . . . . . . . . .  51
     16.10  draft-ietf-simple-message-sessions-01  . . . . . . . . .  51
     16.11  draft-ietf-simple-message-sessions-00  . . . . . . . . .  51
     16.12  draft-campbell-simple-im-sessions-01 . . . . . . . . . .  52
   17.  Contributors and Acknowledgments . . . . . . . . . . . . . .  52
   18.  References . . . . . . . . . . . . . . . . . . . . . . . . .  52
     18.1   Normative References . . . . . . . . . . . . . . . . . .  52
     18.2   Informational References . . . . . . . . . . . . . . . .  53
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  55
        Intellectual Property and Copyright Statements . . . . . . .  56

Campbell, et al.         Expires August 24, 2005                [Page 3]

Internet-Draft                    MSRP                     February 2005

1.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC-2119 [5].

   This document consistently refers to a "message" as a complete unit
   of MIME or text content.  In some cases a message is split and
   delivered in more than one MSRP request.  Each of these portions of
   the complete message is called a "chunk".

2.  Introduction and Background

   A series of related instant messages between two or more parties can
   be viewed as part of a "message session", that is, a conversational
   exchange of messages with a definite beginning and end.  This is in
   contrast to individual messages each sent completely independently.
   The SIMPLE Working Group describes messaging schemes that only track
   individual messages as "page-mode" messages, whereas messaging that
   is part of a "session" with a definite start and end is called
   "session-mode" messaging.

   Page-mode messaging is enabled in SIMPLE via the SIP [4]MESSAGE
   method [18].  Session-mode messaging has a number of benefits [19]
   over page-mode messaging however, such as explicit rendezvous,
   tighter integration with other media types, direct client-to-client
   operation, and brokered privacy and security.

   This document defines a session-oriented instant message transport
   protocol called the Message Session Relay Protocol (MSRP), whose
   sessions can be included in an offer or answer [3] using the Session
   Description Protocol(SDP [2]).  The exchange is carried by some
   signaling protocol, such as the Session Initiation Protocol (SIP
   [4]).  This allows a communication user agent to offer a messaging
   session as one of the possible media types in a session.  For
   instance, Alice may want to communicate with Bob.  Alice doesn't know
   at the moment whether Bob has his phone or his IM client handy, but
   she's willing to use either.  She sends an invitation to a session to
   the address of record she has for Bob,  Her
   invitation offers both voice and an IM session.  The SIP services at forward the invitation to Bob at his currently registered
   clients.  Bob accepts the invitation at his IM client and they begin
   a threaded chat conversation.

   When a user uses an IM URL, other documents define how DNS can be
   used to map this to a particular protocol to establish the session
   such as SIP.  SIP can use an offer answer model to transport the MSRP
   URLs for the media in SDP.  This document defines how the

Campbell, et al.         Expires August 24, 2005                [Page 4]

Internet-Draft                    MSRP                     February 2005

   offer-answer exchange works to establish MSRP connections and how
   messages are sent across the MSRP protocol but it does not deal with
   the issues of mapping an IM URL to a session establishment protocol.

   This session model allows message sessions to be integrated into
   advanced communications applications with little to no additional
   protocol development.  For example, during the above chat session,
   Bob decides Alice really needs to be talking to Carol.  Bob can
   transfer [17] Alice to Carol, introducing them into their own
   messaging session.  Messaging sessions can then be easily integrated
   into call-center and dispatch environments utilizing third-party call
   control [16] and conferencing [15] applications.

3.  Applicability of MSRP

   MSRP is not designed for use as a standalone protocol.  MSRP MUST be
   used only in the context of a rendezvous mechanism meeting the
   following requirements:

      The rendezvous mechanism MUST provide both MSRP URLs associated
      with an MSRP session to each of the participating endpoints.  The
      rendezvous mechanism MUST implement mechanisms to provide these
      URLs securely - they MUST NOT be made available to an untrusted
      third party or be easily discoverable.

      The rendezvous mechanism MUST provide mechanisms for the
      negotiation of any supported MSRP extensions that are not
      backwards compatible.

      The rendezvous mechanism MUST be able to natively transport im:
      URIs or automatically translate im: URIs [24] into the addressing
      identifiers of the rendezvous protocol.

   To use a rendezvous mechanism with MSRP, an RFC must be prepared
   describing how it exchanges MSRP URIs and meets these requirements
   listed here.  This document provides such a description for the use
   of MSRP in the context of SIP and SDP.

   SIP meets these requirements for a rendezvous mechanism.  The MSRP
   URLs are exchanged using SDP in an offer/answer exchange via SIP.
   The exchanged SDP can also be used to negotiate MSRP extensions.
   This SDP can be secured using any of the mechanisms available in SIP,
   including using the sips mechanism to ensure transport security
   across intermediaries and S/MIME for end-to-end protection of the SDP
   entity.  SIP can carry arbitrary URIs (including im: URIs) in the
   Request-URI, and procedures are available to map im: URIs to sip: or
   sips: URIs.  It is expected that initial deployments of MSRP will use
   SIP as its rendezvous mechanism.

Campbell, et al.         Expires August 24, 2005                [Page 5]

Internet-Draft                    MSRP                     February 2005

4.  Protocol Overview

   MSRP is a text-based, connection-oriented protocol for exchanging
   arbitrary (binary) MIME content, especially instant messages.  This
   section is a non-normative overview of how MSRP works and how it is
   used with SIP.

   MSRP sessions are typically arranged using SIP the same way a session
   of audio or video media is setup.  One SIP user agent (Alice) sends
   the other (Bob) a SIP invitation containing an offered
   session-description which includes a session of MSRP.  The receiving
   SIP user agent can accept the invitation and include an answer
   session-description which acknowledges the choice of media.  Alice's
   session description contains an MSRP URL that describes where she is
   willing to receive MSRP requests from Bob, and vice-versa.  (Note:
   Some lines in the examples are removed for clarity and brevity.)

       Alice sends to Bob:

   To: <>
   From: <>;tag=786
   Call-ID: 3413an89KU
   Content-Type: application/sdp

   c=IN IP4
   m=message 7654 msrp/tcp *

       Bob sends to Alice:

   SIP/2.0 200 OK
   To: <>;tag=087js
   From: <>;tag=786
   Call-ID: 3413an89KU
   Content-Type: application/sdp

   c=IN IP4
   m=message 12763 msrp/tcp *

       Alice sends to Bob:

   ACK SIP/2.0
   To: <>;tag=087js
   From: <>;tag=786

Campbell, et al.         Expires August 24, 2005                [Page 6]

Internet-Draft                    MSRP                     February 2005

   Call-ID: 3413an89KU

   MSRP defines two request types, or methods.  SEND requests are used
   to deliver a complete message or a chunk (a portion of a complete
   message), while REPORT requests report on the status of an earlier
   SEND request.  When Alice receives Bob's answer, she checks to see if
   she has an existing connection to Bob.  If not, she opens a new
   connection to Bob using the URL he provided in the SDP.  Alice then
   delivers a SEND request to Bob with her initial message, and Bob
   replies indicating that Alice's request was received successfully.

   MSRP a786hjs2 SEND
   To-Path: msrp://;tcp
   From-Path: msrp://;tcp
   Message-ID: 87652
   Byte-Range: 1-25/25
   Content-Type: text/plain

   Hey Bob, are you there?

   MSRP a786hjs2 200 OK
   To-Path: msrp://;tcp
   From-Path: msrp://;tcp
   Message-ID: 87652
   Byte-Range: 1-25/25

   Alice's request begins with the MSRP start line, which contains a
   transaction identifier that is also used as a final boundary marker.
   Next she includes the path of URLs to the destination in the To-Path
   header, and her own URL in the From-Path header.  In this typical
   case there is just one "hop", so there is only one URL in each path
   header field.  She also includes a message ID which she can use to
   correlate responses and status reports with the original message.
   Next she puts the actual content.  Finally she closes the request
   with an end line: seven hyphens, the transaction identifier /
   boundary marker and a "$" to indicate this request contains the end
   of a complete message.

   If Alice wants to deliver a very large message, she can split the
   message into chunks and deliver each chunk in a separate SEND
   request.  The message ID corresponds to the whole message, so the
   receiver can also use it to reassemble the message and tell which
   chunks belong with which message.  Chunking is described in more
   detail in Section 5.1.  The Byte-Range header identifies the portion
   of the message carried in this chunk and the total size of the

Campbell, et al.         Expires August 24, 2005                [Page 7]

Internet-Draft                    MSRP                     February 2005


   Alice can also specify what type of reporting she would like in
   response to her request.  If Alice requests positive acknowledgments,
   Bob sends a REPORT request to Alice confirming the delivery of her
   complete message.  This is especially useful if Alice sent a series
   of SEND request containing chunks of a single message.  More on
   requesting types of reports and errors is described in Section 5.3.

   Alice and Bob generally choose their MSRP URLs in such a way that is
   difficult to guess the exact URL.  Alice and Bob can reject requests
   to URLs they are not expecting to service, and can correlate the
   specific URL with the probable sender.  Alice and Bob can also use
   TLS [1] to provide channel security over this hop.  To receive MSRP
   requests over a TLS protected connection, Alice or Bob could
   advertise URLs with the "msrps" scheme instead of "msrp."

   This document specifies MSRP behavior only for peer-to-peer sessions,
   that is, sessions crossing only a single hop.  However, work to
   specify behavior for MSRP relay devices [20] (referred to herein as
   "relays") is occurring as a separate effort.  MSRP is designed with
   the expectation that MSRP can carry URLs for nodes on the far side of
   such relays.  For this reason, a URL with the "msrps" scheme makes no
   assertion about the security properties of other hops, just the next
   hop.  The user agent knows the URL for each hop, so it can verify
   that each URL has the desired security properties.

   MSRP URLs are discussed in more detail in Section 6.

   An adjacent pair of busy MSRP nodes (for example two relays) can
   easily have several sessions, and exchange traffic for several
   simultaneous users.  The nodes can use existing connections to carry
   new traffic with the same destination host, port, transport protocol,
   and scheme.  MSRP nodes can keep track of how many sessions are using
   a particular connection and close these connections when no sessions
   have used them for some period of time.  Connection management is
   discussed in more detail in Section 5.4.

5.  Key Concepts

5.1  MSRP Framing and Message Chunking

   Messages sent using MSRP can be very large and can be delivered in
   several SEND requests, where each SEND request contains one chunk of
   the overall message.  Long chunks may be interrupted in
   mid-transmission to ensure fairness across shared transport
   connections.  To support this, MSRP uses a boundary based framing
   mechanism.  The start line of an MSRP request contains a unique

Campbell, et al.         Expires August 24, 2005                [Page 8]

Internet-Draft                    MSRP                     February 2005

   boundary string that is used to indicate the end of the request.
   Following the boundary string at the end of the body data, there is a
   flag that indicates whether this is the last chunk of data for this
   message or whether the message will be continued in a subsequent
   chunk.  There is also a Byte-Range header in the request that
   indicates the overall position of this chunk inside the complete

   For example, the following snippet of two SEND requests demonstrates
   a message that contains the text "abcdEFGH" being sent as two chunks.

    MSRP dkei38sd SEND
    Message-ID: 456
    Byte-Range: 1-4/8
    Content-Type: text/plain


    MSRP dkei38ia SEND
    Message-ID: 456
    Byte-Range: 5-8/8
    Content-Type: text/plain


   This chunking mechanism allows a sender to interrupt a chunk part of
   the way through sending it.  The ability to interrupt messages allows
   multiple sessions to share a TCP connection, and for large messages
   to be sent efficiently while not blocking other messages that share
   the same connection.  Any chunk that is larger than 2048 octets MUST
   be interruptible.  While MSRP would be simpler to implement if each
   MSRP session used its own TCP connection, that approach would
   circumvent the congestion avoidance features of TCP.

5.2  MSRP Addressing

   MSRP entities are addressed using URLs.  The MSRP URL schemes are
   defined in Section 6.  The syntax of the To-Path and From-Path
   headers each allow for a list of URLs.  This was done to allow the
   protocol to work with gateways or relays defined in the future, to
   provide a complete path to the end recipient.  When two MSRP nodes
   communicate directly they need only one URL in the To-Path list and
   one URL in the From-Path list.

Campbell, et al.         Expires August 24, 2005                [Page 9]

Internet-Draft                    MSRP                     February 2005

5.3  MSRP Transaction and Report Model

   A sender sends MSRP requests to a receiver.  The receiver MUST
   quickly accept or reject the request.  If the receiver initially
   accepted the request, it still may then do things that take
   significant time to succeed or fail.  For example, if the receiver is
   an MSRP to XMPP [28] gateway, it may forward the message over XMPP.
   The XMPP side may later indicate that the request did not work.  At
   this point, the MSRP receiver may need to indicate that the request
   did not succeed.  There are two important concepts here: first, the
   hop by hop delivery of the request may succeed or fail; second, the
   end result of the request may be successfully processed or not.  The
   first type of status is referred to as "transaction status" and may
   be returned in response to a request.  The second type of status is
   referred to as "request status" and may be returned in a REPORT

   The original sender of a request can indicate if they wish to receive
   reports for requests that fail, and can independently indicate if
   they wish to receive reports for requests that succeed.  A receiver
   only sends a success REPORT if it knows that the request succeeded,
   and the sender requested a success report.  A receiver only sends a
   failure REPORT if the request failed and the sender requested failure

      This document describes the behavior of MSRP endpoints.  MSRP
      relays or gateways are likely to have additional conditions that
      indicate a failure REPORT should be sent, such as the failure to
      receive a positive response from the next hop.

   Two header fields control the sender's desire to receive reports.
   The header "Success-Report" can have a value of "yes" or "no" and the
   "Failure-Report" header can have a value of "yes", "no", or

   The combinations of reporting are needed to meet the various
   scenarios of currently deployed IM systems.  Success-Report might be
   "no" in many public systems to reduce load but is used in some
   current enterprise systems, such as systems used for securities
   trading.  A Failure-Report value of "no" is useful for sending system
   messages such as "the system is going down in 5 minutes" without
   causing a response explosion to the sender.  A Failure-Report of
   "yes" is used by many systems that wish to notify the user if the
   message failed.  A Failure-Report of "partial" is a way to report
   errors except timeouts.  The timeout error reporting requires the
   sending hop to run a timer and that receiving hop to send an
   acknowledgment to stop the timer.  Some systems don't want the
   overhead of doing this so choose not to but still allow error

Campbell, et al.         Expires August 24, 2005               [Page 10]

Internet-Draft                    MSRP                     February 2005

   responses to be sent in many cases and these systems can use

5.4  MSRP Connection Model

   When MSRP wishes to send a request to a peer identified by an MSRP
   URL, it first needs a transport connection, with the appropriate
   security properties, to the host specified in the URL.  If the sender
   already has such a connection, that is, one associated with the same
   host, port, and URL scheme, then it SHOULD reuse that connection.

   When a new MSRP session is created, the offerer MUST act as the
   "active" endpoint, meaning that it is responsible for opening the
   transport connection to the answerer, if a new connection is
   required.  However, this requirement MAY be weakened if standardized
   mechanisms for negotiating the connection direction become available,
   and is implemented by both parties to the connection.

   Likewise, the active endpoint MUST immediately issue a SEND request.
   This initial SEND request MAY have a empty body, or MAY carry

   When an element needs to form a new connection, it looks at the URL
   to decide on the type of connection (TLS, TCP, etc.) then connects to
   the host indicated by the URL, following the URL resolution rules in
   Section 6.2.  Connections using the msrps: scheme MUST use TLS.  The
   SubjectAltName in the received certificate MUST match the hostname
   part of the URL and the certificate MUST be valid, including having a
   date that is valid and being signed by an acceptable certificate
   authority.  At this point the device that initiated the connection
   can assume that this connection is with the correct host.

   If the connection used mutual TLS authentication, and the TLS client
   presented a valid certificate, then the element accepting the
   connection can immediately know the identity of the connecting host.
   When mutual TLS authentication is not used, the listening device MUST
   wait until it receives a request on the connection, at which it
   infers the identity of the connecting device from the associated
   session description.

   When the first request arrives, its To-Path header field should
   contain a URL that the listening element handed out in the SDP for a
   session.  The element that accepted the connection looks up the URL
   in the received request, and determines which session it matches.  If
   a match exists, the node MUST assume that the host that formed the
   connection is the host to which this URL was given.  If no match
   exists, the node MUST reject the request with a 481 response.  The
   node MUST also check to make sure the session is not already in use

Campbell, et al.         Expires August 24, 2005               [Page 11]

Internet-Draft                    MSRP                     February 2005

   on another connection.  If the session is already in use, it MUST
   reject the request with a 506 response.

      If it were legal to have multiple connections associated with the
      same session, a security problem would exist.  If the initial SEND
      request is not protected, an eavesdropper might learn the URL, and
      use it to insert messages into the session via a different

   If a connection fails for any reason, then an MSRP endpoint MUST
   consider any sessions associated with the connection as also having
   failed.  When an endpoint notices such a failure, it MAY attempt to
   re-create any such sessions.  If it chooses to do so, it MUST use new
   SDP exchange, for example, in a SIP re-INVITE or UPDATE [11] request.
   If a replacement session is successfully created, endpoints MAY
   attempt to resend any content for which delivery on the original
   session could not be confirmed.  If it does this, the Message-ID
   values for the resent messages MUST match those used in the initial
   attempts.  If the receiving endpoint receives more than one message
   with the same Message-ID.  It SHOULD assume that the messages are
   duplicates.  It MAY take any action based on that knowledge, but
   SHOULD NOT present the duplicate messages to the user without warning
   of the duplication.

   In this situation, the endpoint MUST ensure that the Message-ID of
   each distinct (i.e.  non-duplicate) message is unique in the context
   of both the original session and the replacement session.

   When endpoints create a new session in this fashion, the chunks for a
   given logical message MAY be split across the sessions.  However,
   endpoints SHOULD NOT split chunks between sessions under non-failure

   If an endpoint attempts to re-create a failed session in this manner,
   it MUST NOT assume that the MSRP URLs in the SDP will be the same as
   the old ones.

   A connection SHOULD not be closed while there are sessions associated
   with it.


   URLs using the MSRP and MSRPS schema are used to identify a session
   of instant messages at a particular MSRP device.  MSRP URLs are
   ephemeral; an MSRP device will generally use a different MSRP URL for
   each distinct session.  An MSRP URL generally has no meaning outside
   of the associated session.

Campbell, et al.         Expires August 24, 2005               [Page 12]

Internet-Draft                    MSRP                     February 2005

   An MSRP URL follows a subset of the URL syntax in Appendix A of
   RFC2396bis [9], with a scheme of "msrp" or "msrps".  The syntax is
   described in Section 9.

   The constructions for "userinfo",  and "unreserved" are detailed in
   RFC2396bis [9].  In order to allow IPV6 addressing, the construction
   for hostport is that used for SIP in RFC3261.  URLs designating MSRP
   over TCP MUST include the "tcp" transport parameter.

      Since this document only specifies MSRP over TCP, all MSRP URLs
      herein use the "tcp" transport parameter.  Documents that provide
      bindings on other transports should define respective parameters
      for those transports.

   An MSRP URL hostport field identifies a participant in a particular
   MSRP session.  If the hostport contains a numeric IP address, it MUST
   also contain a port.  The session-id part identifies a particular
   session of the participant.  The absence of the session-id part
   indicates a reference to an MSRP host device, but does not
   specifically refer to a particular session.

   A scheme of "msrps" indicates the underlying connection MUST be
   protected with TLS.

   MSRP has an IANA registered recommended port defined in Section 15.1.
   This value is not a default, as the URL negotiation process described
   herein will always include explicit port numbers.  However, the URLs
   SHOULD be configured so that the recommended port is used whenever
   appropriate.  This makes life easier for network administrators who
   need to manage firewall policy for MSRP.

   The server part will typically not contain a userinfo component, but
   MAY do so to indicate a user account for which the session is valid.
   Note that this is not the same thing as identifying the session
   itself.  If a userinfo component exists, it MUST be constructed only
   from "unreserved" characters, to avoid a need for escape processing.
   Escaping MUST NOT be used in an MSRP URL.  Furthermore, a userinfo
   part MUST NOT contain password information.

      The limitation of userinfo to unreserved characters is an
      additional restriction to the userinfo definition in RFC2396bis.
      That version allows reserved characters.  The additional
      restriction is to avoid the need for escaping.

   The following is an example of a typical MSRP URL:


Campbell, et al.         Expires August 24, 2005               [Page 13]

Internet-Draft                    MSRP                     February 2005

6.1  MSRP URL Comparison

   MSRP URL comparisons MUST be performed according to the following

   1.  The scheme must match.  Scheme comparison is case insensitive.

   2.  If the hostpart contains an explicit IP address, and/or port,
       these are compared for address and port equivalency.  Otherwise,
       hostpart is compared as a case insensitive character string.

   3.  If the port exists explicitly in either URL, then it must match
       exactly.  An URL with an explicit port is never equivalent to
       another with no port specified.

   4.  The session-id part is compared as case sensitive.  A URL without
       a session-id part is never equivalent to one that includes one.

   5.  URLs with different "transport" parameters never match.  Two URLs
       that are identical except for transport are not equivalent.  The
       transport parameter is case-insensitive.

   6.  Userinfo parts are not considered for URL comparison.

   Path normalization is not relevant for MSRP URLs.  Escape
   normalization is not required due to character restrictions in the
   formal syntax.

6.2  Resolving MSRP Host Device

   An MSRP host device is identified by the server part of an MSRP URL.

   If the server part contains a numeric IP address and port, they MUST
   be used as listed.

   If the server part contains a host name and a port, the connecting
   device MUST determine a host address by doing an A or AAAA DNS query,
   and use the port as listed.

   If a connection attempt fails, the device SHOULD attempt to connect
   to the addresses returned in any additional A or AAAA records, in the
   order the records were presented.

      This process assumes that the connection port is always known
      prior to resolution.  This is always true for the MSRP URL uses
      described in this document, that is, URLs exchanged in the SDP
      offer and answer.  The introduction of relays may create
      situations where this is not the case.  For example, the MSRP URL

Campbell, et al.         Expires August 24, 2005               [Page 14]

Internet-Draft                    MSRP                     February 2005

      that a user enters into a client to configure it to use a relay
      may be intended to be easily remembered and communicated by
      humans, and therefore is likely to omit the port.  Therefore, the
      relay specification [20] may describe additional steps to resolve
      the port number.

   MSRP devices MAY use other methods for discovering other such
   devices, when appropriate.  For example, MSRP endpoints may use other
   mechanisms to discover relays, which are beyond the scope of this

7.  Method-Specific Behavior

7.1  Constructing Requests

   To form a new request, the sender creates a unique transaction
   identifier and uses this and the method name to create an MSRP
   request start line.  Next, the sender places the target path in a
   To-Path header, and the sender's URL in a From-Path header.  If
   multiple URLs are present in the To-Path, the leftmost is the first
   URL visited; the rightmost URL is the last URL visited.  The
   processing then becomes method specific.  Additional method-specific
   headers are added as described in the following sections.

   After any method-specific headers are added, processing continues to
   handle a body, if present.  A body in a Non-SEND request MUST NOT be
   longer than 2048 octets.  If the request has a body, it must contain
   a Content-Type header field.  It may contain other MIME specific
   headers.  The Content-Type header MUST be the last header line.  The
   body MUST be separated from the headers with an extra CRLF.  Note
   that, if no body is present, no blank line will be present between
   the headers and the boundary marker below.

   The boundary marker that terminates the body MUST be preceded by a
   CRLF that is not part of the body and then seven "-" (minus sign)
   characters.  After the boundary marker, there MUST be a flag
   character.  If the chunk represents the data that forms the end of
   the complete message, the flag value MUST be a "$".  If sender is
   abandoning an incomplete message, and intends to send no further
   chunks in that message, it MUST be a "#".  Otherwise it MUST be a

   If the request contains a body, the sender MUST ensure that the
   closing sequence (a CRLF, seven hyphens, and the transaction
   identifier) is not present in the body.  If the closing sequence is
   present in the body, the sender MUST choose a new transaction
   identifier that is not present in the body, and add the closing
   sequence, including the "$", "#", or "+" character, and a final CRLF.

Campbell, et al.         Expires August 24, 2005               [Page 15]

Internet-Draft                    MSRP                     February 2005

   Some implementations may choose to implement this such that if they
   find the closing sequence in the body of the message they are
   sending, simply interrupting the message at that point and starting a
   new transaction with a different transaction identifier to carry the
   rest of the body.  Other implementation may choose to scan the data
   an ensure that the body does not contain the transaction identifier
   before they start sending the transaction.

   Finally, requests which have no body MUST NOT contain a Content-Type
   header or any other MIME specific header.  Requests without bodies
   MUST contain a closing sequence after the final header.

   Once a request is ready for delivery, the sender follows the
   connection management (Section 5.4) rules to forward the request over
   an existing open connection or create a new connection.

7.1.1  Delivering SEND requests

   When an endpoint has a message to deliver, it first generates a new
   unique Message-ID.  This ID MUST be unique within the scope of the
   session.  If necessary, it breaks the message into chunks.  It then
   generates a SEND request for each chunk, following the procedures for
   constructing requests (Section 7.1).

   Each chunk MUST contain a Message-ID header field containing the
   Message-ID.  If the sender wishes non-default status reporting, it
   MUST insert a Failure-Report and/or Success-Report header field with
   an appropriate value.  All chunks of the same message MUST use the
   same Failure-Report and Success-Report values in their SEND requests.

   If success reports are requested, i.e.  the value of the
   Success-Report header is "yes", the sending device MAY wish to run a
   timer of some value that makes sense for its application and take
   action if a success Report is not received in this time.  There is no
   universal value for this timer.  For many IM applications, it may be
   2 minutes while for some trading systems it may be under a second.
   Regardless of whether such a timer is used, if the success report has
   not been received by the time the session is ended, the device SHOULD
   inform the user.

   If the value of "Failure-Report" is set to "yes", then the sender of
   the request runs a timer.  If a 200 response to the transaction is
   not received within 30 seconds from the time the last byte of the
   transaction is sent, the element MUST inform the user that the
   request probably failed.  If the value is set to "partial", then the
   element sending the transaction does not have to run a timer, but
   MUST inform the user if receives a non-recoverable error response to
   the transaction.

Campbell, et al.         Expires August 24, 2005               [Page 16]

Internet-Draft                    MSRP                     February 2005

   If no Success-Report header is present in a SEND request, it MUST be
   treated the same as a Success-Report header with value of "no".  If
   no Failure-Report header is present, it MUST be treated the same as a
   Failure-Report header with value of "yes".  REPORT requests MUST have
   the same Message-ID header value as the request they are reporting
   on.  They MAY also have the Byte-Range of the chunk they are
   reporting on.  If an MSRP endpoint receives a REPORT for a Message-ID
   it does not recognize, it SHOULD silently ignore the REPORT.

   Success-Report and Failure-Report MUST NOT be present for any method
   other than SEND.  MSRP nodes MUST NOT send REPORT requests in
   response to report requests.  MSRP Nodes MUST NOT send MSRP responses
   to REPORT requests.

   The Byte-Range header value contains a starting value (range-start)
   followed by a "-", an ending value (range-end) followed by a "/", and
   finally the total length.  The first octet in the message has a
   position of one, rather than a zero.

   The first chunk of the message SHOULD, and all subsequent chunks MUST
   include a Byte-Range header field.  The range-start field MUST
   indicate the position of the first byte in the body in the overall
   message (for the first chunk this field will have a value of one).
   The range-end field SHOULD indicate the position of the last byte in
   the body, if known.  It MUST take the value of "*" if the position is
   unknown, or if the request needs to be interruptible.  The total
   field SHOULD contain the total size of the message, if known.  The
   total field MAY contain a "*" if the total size of the message is not
   known in advance.  The sender MUST send all chunks in Byte-Range
   order.  (However, the receiver cannot assume the requests will be
   delivered in order, as intervening relays may have changed the

   To ensure fairness over a connection, senders MUST NOT send chunks
   with a body larger than 2048 octets unless they are prepared to
   interrupt them (meaning that any chunk with a body of greater than
   2048 octets will have a "*" character in the range-end field).  A
   sender can use one of the following two strategies to satisfy this
   requirement.  The sender is STRONGLY RECOMMENDED to send messages
   larger than 2048 octets using as few chunks as possible, interrupting
   chunks (at least 2048 octets long) only when other traffic is waiting
   to use the same connection.  Alternatively, the sender MAY simply
   send chunks in 2048 octet increments until the final chunk.  Note
   that the former strategy results in markedly more efficient use of
   the connection.  All MSRP nodes MUST be able to receive chunks of any
   size from zero octets to the maximum number of octets they can
   receive for a complete message.  Senders SHOULD NOT break messages
   into chunks smaller than 2048 octets, except for the final chunk of a

Campbell, et al.         Expires August 24, 2005               [Page 17]

Internet-Draft                    MSRP                     February 2005

   complete message.

   A SEND request is interrupted while a body is in the process of being
   written to the connection by simply noting how much of the message
   has already been written to the connection, then writing out the
   boundary string to end the chunk.  It can then be resumed in a
   another chunk with the same Message-ID and a Byte-Range header range
   start field containing the position of the first byte after the
   interruption occurred.

   SEND requests larger than 2048 octets MUST be interrupted to send
   pending responses or REPORT requests.  If multiple SEND requests from
   different sessions are concurrently being sent over the same
   connection, the device SHOULD implement some scheme to alternate
   between them such that each concurrent request gets a chance to send
   some fair portion of data at regular intervals suitable to the

   The sender MUST NOT assume that a message is received by the peer
   with the same chunk allocation with which it was sent.  An
   intervening relay could possibly break SEND requests into smaller
   chunks, or aggregate multiple chunks into larger ones.

   The default disposition of bodies is "render".  If the sender wants
   different disposition, it MAY insert a Content-Disposition header.
   Since MSRP is a binary protocol, transfer encoding is always
   "binary", and transfer-encoding paramaters MUST NOT be present.

7.1.2  Sending REPORT requests

   REPORT requests are similar to SEND requests, except that report
   requests MUST NOT include Success-Report or Failure-Report header
   fields, and MUST contain a Status header field.  REPORT requests MUST
   contain the Message-ID header from the original SEND request.

   If an MSRP element receives a REPORT for a Message-ID it does not
   recognize, it SHOULD silently ignore the REPORT.

   An MSRP endpoint MUST be able to generate success REPORT requests.

   REPORT requests will normally not include a body, as the REPORT
   request header fields can carry sufficient information in most cases.
   However, REPORT requests MAY include a body containing additional
   information about the status of the associated SEND request.  Such a
   body is informational only, and the sender of the REPORT request
   SHOULD NOT assume that the recipient pays any attention to the body.
   Since REPORT requests are not interruptible, the size of such a body
   MUST NOT exceed 2048 octets.

Campbell, et al.         Expires August 24, 2005               [Page 18]

Internet-Draft                    MSRP                     February 2005

   An endpoint MUST send a success report if it successfully receives a
   SEND request which contained a Success-Report value of "yes" and
   either contains a complete message, or contains the last chunk needed
   to complete the message.  This request is sent following the normal
   procedures (Section 7.1), with a few additional requirements.

   The endpoint inserts a To-Path header field containing the From-Path
   value from the original request, and a From-Path header containing
   the URL identifying itself in the session.  The endpoint then inserts
   a Status header field with a namespace of "000", a short-status of
   "200" and a relevant Reason phrase, and a Message-ID header field
   containing the value from the original request.

      The namespace field denotes the context the short-status field.
      The namespace value of "000" means the short-status should be
      interpreted in the same way as the matching MSRP transaction
      response code.  If a future specification uses the short-status
      field for some other purpose, it MUST define a new namespace field

   The endpoint MUST NOT send a success report for a SEND request that
   either contained no Success-Report header field, or contained such a
   field with a value of "no".  That is, if no Success-Report header
   field is present, it is treated identically to one with a value of

7.1.3  Failure REPORT Generation

   If an MSRP endpoint receives a SEND request that it cannot process
   for some reason, and the Failure-Report header either was not present
   in the original request, or had a value of "yes", it SHOULD simply
   include the appropriate error code in the transaction response.
   However, there may be situations where the error cannot be determined
   quickly, such as when the endpoint is a gateway that must wait for a
   downstream network to indicate an error.  In this situation, it MAY
   send a 200 OK response to the request, and then send a failure REPORT
   request when the error is detected.

   If the endpoint receives a SEND request with a Failure-Report header
   field value of "no", then it MUST NOT send a failure REPORT request,
   and MUST NOT send a transaction response.  If the value is "partial",
   it MUST NOT send a 200 transaction response to the request, but
   SHOULD send an appropriate non-200 class response if a failure

   As stated above, if no Failure-Report header is present, it MUST be
   treated the same as a Failure-Report header with value of "yes".

Campbell, et al.         Expires August 24, 2005               [Page 19]

Internet-Draft                    MSRP                     February 2005

   Construction of failure REPORT requests is identical to that for
   success reports, except the Status header code and reason fields MUST
   contain appropriate error codes.  Any error response code defined in
   this specification MAY also be used in failure reports.

   If a failure report is sent in response to a SEND request that
   contained a chunk, it MUST include a Byte-Range header indicating the
   actual range being reported on.  It can take the range-start and
   total values from the original SEND request, but MUST calculate the
   range-end field from the actual body data.

   Endpoints SHOULD NOT send REPORT requests if they have reason to
   believe the request will not be delivered.  For example, they SHOULD
   NOT send a REPORT request on a session that is no longer valid.

      This section only describes failure report generation behavior for
      MSRP endpoints.  Relay behavior is beyond the scope of this
      document, and will be considered in a separate document.  We
      expect failure reports to be more commonly generated by relays
      than by endpoints.

7.2  Constructing Responses

   If an MSRP endpoint receives a request that either contains a
   Failure-Report header value of "yes", or does not contain a
   Failure-Report header field at all, it MUST immediately generate a
   response.  Likewise, if an MSRP endpoint receives a request that
   contains a Failure-Report header value of "partial", and the receiver
   is unable to process the request, it SHOULD immediately generate a

   To construct the response, the endpoint first creates the response
   start-line, inserting appropriate response code and reason fields.
   The transaction identifier in the response start line MUST match the
   transaction identifier from the original request.

   The endpoint then inserts an appropriate To-Path header field.  If
   the request triggering the response was a SEND request, the To-Path
   header field is formed by copying the last (right-most) URL in the
   From-Path header field of the request.  (Responses to SEND requests
   are returned only to the previous hop.)  For responses to all other
   request methods, the To-Path header field contains the full path back
   to the original sender.  This full path is generated by taking the
   list of URLs from the From-Path of the original request, reversing
   the list, and writing the reversed list into the To-Path of the
   response.  (Legal REPORT requests do not request responses, so this
   specification doesn't exercise the behavior described above, however
   we expect that extensions for gateways and relays will need such

Campbell, et al.         Expires August 24, 2005               [Page 20]

Internet-Draft                    MSRP                     February 2005


   Finally, the endpoint inserts a From-Path header field containing the
   URL that identifies it in the context of the session, followed by the
   closing sequence after the last header field.  The response MUST be
   transmitted back on the same connection on which the original request

7.3  Receiving Requests

   The receiving endpoint must first check the URL in the To-Path to
   make sure the request belongs to an existing session.  When the
   request is received, the To-Path will have exactly one URL, which
   MUST map to an existing session that is associated with the
   connection on which the request arrived.  If this is not true then
   the receiver MUST generate an 481 error and ignore the request.  Note
   that if the Failure-Report header had a value of "no", then no error
   report would be sent.

   Further request processing by the receiver is method specific.

7.3.1  Receiving SEND requests

   When the receiving endpoint receives a SEND request, it first
   determines if it contains a complete message, or a chunk from a
   larger message.  If the request contains no Byte-Range header, or
   contains one with a range-start value of "1", and the closing line
   continuation flag has a value of "$", then the request contained the
   entire message.  Otherwise, the receiver looks at the Message-ID
   value to associate chunks together into the original message.  It
   forms a virtual buffer to receive the message, keeping track of which
   bytes have been received and which are missing.  The receiver takes
   the data from the request and places it in the appropriate place in
   the buffer.  The receiver SHOULD determine the actual length of each
   chunk by inspecting the payload itself; it is possible the body is
   shorter than the range-end field indicates.  This can occur if the
   sender interrupted a SEND request unexpectedly.  It is worth nothing
   that the chunk that has a termination character of "$" defines the
   total length of the message.

      It is technically illegal for the sender to prematurely interrupt
      a request that had anything other "*" in the last-byte position of
      the Byte-Range header.  But having the receiver calculate a chunk
      length based on actual content adds resilience in the face of
      sender errors.  Since this should never happen with compliant
      senders, this only has a SHOULD strength.

   Receivers MUST not assume the chunks will be delivered in order or

Campbell, et al.         Expires August 24, 2005               [Page 21]

Internet-Draft                    MSRP                     February 2005

   that they will receive all the chunks with "+" flags before they
   receive the chunk with the "$" flag.  In certain cases of connection
   failure, it is possible for information to be duplicated.  If chunk
   data is received that overlaps already received data for the same
   message, the last chunk received takes precedence (even though this
   may not have been the last chunk transmitted).  For example, if bytes
   1 to 100 was received and a chunk arrives that contains bytes 50 to
   150, this second chunk will overwrite bytes 50 to 100 of the data
   that had already been received.  Although other schemes work, this is
   the easiest for the receiver and results in consistent behavior
   between clients.

   The seven "-" before the boundary are used so that the receiver can
   search for the value "----", 32 bits at a time to find the probable
   location of the boundary.  This allows most processors to locate the
   boundaries and copy the memory at the same rate that a normal memory
   copy could be done.  This approach results in a system that is as
   fast as framing based on specifying the body length in the headers of
   the request, but also allows for the interruption of messages.

   What is done with the body is outside the scope of MSRP and largely
   determined by the MIME Content-Type and Content-Disposition.  The
   body MAY be rendered after the whole message is received or partially
   rendered as it is being received.

   If the SEND request contained a Content-Type header field indicating
   an unsupported MIME type, the receiver MUST generate a failure report
   with a 415 error code.  Note that this failure report will not be
   sent if the Report-Failure header contains a value of "no".  All MSRP
   endpoints MUST be able to receive the multipart/mixed and
   multipart/alternative MIME types.

   If the Success-Report header was set to "yes", then when a complete
   message has been received, the receiver MUST send a success REPORT
   with a byte range covering the whole message.  If the Success-Report
   header is not set to "no", then the receiver MAY generate incremental
   success REPORTs as the chunks are received.  These can be sent
   periodically and cover all the bytes that have been received so far
   or they can be sent after a chunk arrives and cover just the part
   from that chunk.

7.3.2  Receiving REPORT requests

   When an endpoint receives a REPORT request, it correlates it to the
   original SEND request using the Message-ID and the Byte-Range, if
   present.  If it requested success reports, then it SHOULD keep enough
   state about each outstanding sent message so that it can correlate
   REPORT requests to the original messages.

Campbell, et al.         Expires August 24, 2005               [Page 22]

Internet-Draft                    MSRP                     February 2005

   An endpoint that receives a REPORT request containing a Status header
   with a namespace field of "000", MUST interpret the report in exactly
   the same way it would interpret an MSRP transaction response with a
   response code matching the short-code field.

   It is possible to receive a failure report or a failure transaction
   response for a chunk that is currently being delivered.  In this case
   the entire message corresponding to that chunk should be aborted, by
   including the "#" character in the continuation field of the closing

   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

   When a device that sent a SEND request receives a failure REPORT
   indicating that a particular byte range was not received, it MUST
   treat the session as failed.  If it wishes to recover,  it MUST first
   re-negotiate the URLs at the signaling level then resend that range
   of bytes of the message on the resulting new session.

   MSRP Modes MUST NOT send a MSRP REPORT in responses to REPORT

8.  Using MSRP with SIP

8.1  SDP Offer-Answer Exchanges for MSRP Sessions

   MSRP sessions will typically be initiated using the Session
   Description Protocol (SDP) [2] 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 the IANA Considerations

   An MSRP media-line in the session description is always accompanied
   by a mandatory "path" attribute.  This attribute contains a space
   separated list of URLs that must be visited to contact the user agent
   advertising this session-description.  If more than one URL is
   present, the leftmost URL is the first URL that must be visited to
   reach the target resource.  (The path list can contain multiple URLs
   to allow for the deployment of gateways or relays in the future.)
   MSRP implementations which can accept incoming connections will
   typically only provide a single URL here.

Campbell, et al.         Expires August 24, 2005               [Page 23]

Internet-Draft                    MSRP                     February 2005

   An MSRP medialine MUST also be accompanied by an "accept-types"
   attribute.  This attribute contains a list of MIME types which are
   acceptable to the endpoint.

   A "*" entry in the accept-types attribute indicates that the sender
   may attempt to send content with media types that have not been
   explicitly listed.  Likewise, an entry with an explicit type and a
   "*" character as the subtype indicates that the sender may attempt to
   send content with any subtype of that type.  If the receiver receives
   an MSRP request and is able to process the media type, it does so.
   If not, it will respond with a 415 response.  Note that all explicit
   entries SHOULD be considered preferred over any non-listed types.
   This feature is needed as, otherwise, the list of formats for rich IM
   devices may be prohibitively large.

   The accept-types attribute may include container types, that is, MIME
   formats that contain other types internally.  If compound types are
   used, the types listed in the accept-types attribute may be used both
   as the root payload, or may be wrapped in a listed container type.
   Any container types MUST also be listed in the accept-types

   Occasionally an endpoint will need to specify a MIME body type that
   can only be used if wrapped inside a listed container type.

   Endpoints MAY specify MIME types that are only allowed when wrapped
   inside compound types using the "accept-wrapped-types" attribute in
   an SDP a-line.

   The semantics for accept-wrapped-types are identical to those of the
   accept-types attribute, with the exception that the specified types
   may only be used when wrapped inside containers.  Only types listed
   in the accept-types attribute may be used as the "root" type for the
   entire body.  Since any type listed in accept-types may be used both
   as a root body, and wrapped in other bodies, format entries from
   accept-types SHOULD NOT be repeated in this attribute.

   This approach does not allow for specifying distinct lists of
   acceptable wrapped types for different types of containers.  If an
   endpoint understands a MIME type in the context of one wrapper, it is
   assumed to understand it in the context of any other acceptable
   wrappers, subject to any constraints defined by the wrapper types

      The approach of specifying types that are only allowed inside of
      containers separately from the primary payload types allows an
      endpoint to force the use of certain wrappers.  For example, a
      CPIM [12] gateway device may require all messages to be wrapped

Campbell, et al.         Expires August 24, 2005               [Page 24]

Internet-Draft                    MSRP                     February 2005

      inside message/cpim bodies, but may allow several content types
      inside the wrapper.  If the gateway were to specify the wrapped
      types in the accept-types attribute, its peer might attempt to use
      those types without the wrapper.

   If the recipient of an offer does not understand any of the payload
   types indicated in the offered SDP, it SHOULD indicate that using the
   appropriate mechanism of the rendezvous protocol.  For example, in
   SIP, it SHOULD return a SIP 488 response.

   An endpoint MAY indicate the maximum size message they wish to
   receive using the max-size a-line attribute.  Max-size refers to the
   complete message in octets, not the size of any one chunk.  Senders
   SHOULD NOT exceed the max-size limit for any message sent in the
   resulting session.  However, the receiver should consider max-size
   value as a hint.

   The formal syntax for these attributes are as follows:

           accept-types = accept-types-label ":" format-list
           accept-types-label = "accept-types"
           accept-wrapped-types = wrapped-types-label ":" format-list
           wrapped-types-label = "accept-wrapped-types"
           format-list = format-entry *( SP format-entry)
           format-entry = (type "/" subtype) / (type "/" "*") / ("*")
           type = token
           subtype = token

           max-size = max-size-label ":" max-size-value
           max-size-label = "max-size"
           max-size-value = 1*(DIGIT) ;max size in octets

8.1.1  URL Negotiations

   Each endpoint in an MSRP session is identified by a URL.  These URLs
   are negotiated in the SDP exchange.  Each SDP offer or answer MUST
   contain one or more MSRP URL in a path attribute.  This attribute has
   the following syntax:

   "a=path:" MSRP-URL *(SP MSRP-URL)

   where MSRP-URL is an msrp: or msrps: URL as defined in Section 6.
   MSRP URLs included in an SDP offer or answer MUST include explicit
   port numbers.

   An MSRP device uses the URL to determine a host address, port,
   transport, and protection level when connecting, and to identify the

Campbell, et al.         Expires August 24, 2005               [Page 25]

Internet-Draft                    MSRP                     February 2005

   target when sending requests and responses.

   The offerer and answerer each selects a URL to represent itself, and
   send it to the peer device in the SDP document.  Each device stores
   the path value received from the peer, and uses that value as the
   target for requests inside the resulting session.  If the path
   attribute received from the peer contains more than one URL, then the
   target URL is the rightmost, while the leftmost entry represents the
   adjacent hop.  If only one entry is present, then it is both the peer
   and adjacent hop URL.  The target path is the entire path attribute
   value received from the peer.

   The following example shows an SDP offer with a session URL of

    o=alice 2890844526 2890844527 IN IP4
    c=IN IP4
    m=message 7394 msrp/tcp *

   The rightmost URL in the path attribute MUST identify the endpoint
   that generated the SDP document, or some other location where that
   endpoint wishes to receive requests associated with the session.  It
   MUST be assigned for this particular session, and MUST NOT duplicate
   any URL in use for any other session in which the endpoint is
   currently participating.  It SHOULD be hard to guess, and protected
   from eavesdroppers.  This is discussed in more detail in Section 14.

8.1.2  Path Attributes with Multiple URLs

   As mentioned previously, this document describes MSRP for
   peer-to-peer scenarios, that is, when no relays are used.  However,
   we expect a separate document to describe the use of relays.  In
   order to allow an MSRP device that only implements the core
   specification to interoperate with devices that use relays, this
   document must include a few assumptions about how relays work.

   An endpoint that uses one or more relays will indicate that by
   putting a URL for each device in the relay chain into the SDP path
   attribute.  The final entry would point to the endpoint itself.  The
   other entries would indicate each proposed relay, in order.  The
   first entry would point to the first relay in the chain from the
   perspective of the peer; that is, the relay to which the peer device,
   or a relay operating on its behalf, should connect.

Campbell, et al.         Expires August 24, 2005               [Page 26]

Internet-Draft                    MSRP                     February 2005

   Endpoints that do not wish to insert a relay, including those that do
   not support relays at all, will put exactly one URL into the path
   attribute.  This URL represents both the endpoint for the session,
   and the connection point.

   Even though endpoints that implement only this specification will
   never introduce a relay, they need to be able to interoperate with
   other endpoints that do use relays.  Therefore, they MUST be prepared
   to receive more than one URL in the SDP path attribute.  When an
   endpoint receives more than one URL in a path header, only the first
   entry is relevant for purposes of resolving the address and port, and
   establishing the network connection, as it describes the first
   adjacent hop.

   If an endpoint puts more than one URL in a path attribute, the final
   URL in the path (the peer URL) attribute MUST exhibit the uniqueness
   properties described above.  Uniqueness requirements for other
   entries in the attribute are out of scope for this document.

8.1.3  SDP Connection and Media Lines

   The format of an SDP connection-line takes the following format:

   c=<network type> <address type> <connection address>

   The network type and address type fields are used as normal for SDP.
   The connection address field MUST be set to the IP address or fully
   qualified domain name from MSRP URL identifying the endpoint in its
   PATH attribute.

   The general format of an SDP media-line is:

   m=<media> <port> <protocol> <format list>

   An offered or accepted media-line for MSRP over TCP MUST include a
   protocol field value of "msrp/tcp".  The media field value MUST be
   "message".  The format list field MUST be set to "*".

   The port field value MUST match the port value used in the endpoint's
   MSRP URL in the PATH attribute, except that, as described in [3], a
   user agent that wishes to accept an offer, but not a specific
   media-line MUST set the port number of that media-line to zero (0) in
   the response.) Since MSRP allows multiple sessions to share the same
   TCP connection, multiple m-lines in a single SDP document may share
   the same port field value; MSRP devices MUST NOT assume any
   particular relationship between m-lines on the sole basis that they
   have matching port field values.

Campbell, et al.         Expires August 24, 2005               [Page 27]

Internet-Draft                    MSRP                     February 2005

      MSRP devices do not use the c-line address field, or the m-line
      port and format list fields to determine where to connect.
      Rather, they use the attributes defined in this specification.
      The connection information is copied to the c-line and m-line for
      purposes of backwards compatibility with conventional SDP usages.
      While MSRP could theoretically carry any media type, "message" is

8.1.4  Updated SDP Offers

   MSRP endpoints may sometimes need to send additional SDP exchanges
   for an existing session.  They may need to send periodic exchanges
   with no change to refresh state in the network, for example, SIP
   Session Timers.  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

8.1.5  Example SDP Exchange

   Endpoint A wishes to invite Endpoint B to a MSRP session.  A offers
   the following session description:

    o=usera 2890844526 2890844527 IN IP4
    c=IN IP4
    t=0 0
    m=message 7394 msrp/tcp *
    a=accept-types: message/cpim text/plain text/html

   B responds with its own URL:

Campbell, et al.         Expires August 24, 2005               [Page 28]

Internet-Draft                    MSRP                     February 2005

    o=userb 2890844530 2890844532 IN IP4
    c=IN IP4
    t=0 0
    m=message 8493 msrp/tcp *
    a=accept-types:message/cpim text/plain

8.1.6  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 [23] 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.  Namely,
   the party that sent the original offer

8.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

   SIP INVITE requests may be forked by a SIP proxy, resulting in more
   than one endpoint receiving the same INVITE.  SIP early media [27]
   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.

Campbell, et al.         Expires August 24, 2005               [Page 29]

Internet-Draft                    MSRP                     February 2005

9.  Formal Syntax

   MSRP is a text protocol that uses the UTF-8 [14] transformation

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC-2234 [6].

   msrp-req-or-resp = msrp-request / msrp-response
   msrp-request = req-start headers [content-stuff] end-line
   msrp-response = resp-start headers end-line

   req-start  = pMSRP SP transact-id SP method CRLF
   resp-start = pMSRP SP transact-id SP status-code [SP phrase] CRLF
   phrase = utf8text

   pMSRP = %x4D.53.52.50 ; MSRP in caps
   transact-id = ident
   method = mSEND / mREPORT / other-method
   mSEND = %x53.45.4e.44 ; SEND in caps
   mREPORT = %x52.45.50.4f.52.54; REPORT in caps

   other-method = 1*UPALPHA
   status-code = 3DIGIT ; any code defined in this document
                        ; or an extension document

   MSRP-URL = msrp-scheme "://" [userinfo "@"] hostport
              ["/" session-id] ";" transport
                        ; userinfo as defined in RFC2396, except
                        ; limited to unreserved.
                        ; hostport as defined in RFC3261
                        ; [Todo: update with RFC number for 2396bis]

   msrp-scheme = "msrp" / "msrps"
   session-id = 1*( unreserved / "+" / "=" / "/" )
                        ; unreserved as defined in RFC2396
   transport = "tcp" / ALPHANUM

   headers = To-Path CRLF From-Path CRLF 1*( header CRLF )

   header =   Message-ID
    / Success-Report
    / Failure-Report
    / Byte-Range
    / Status
    / ext-header

Campbell, et al.         Expires August 24, 2005               [Page 30]

Internet-Draft                    MSRP                     February 2005

   To-Path = "To-Path:" SP MSRP-URL *( SP MSRP-URL )
   From-Path = "From-Path:" SP MSRP-URL *( SP MSRP-URL )
   Message-ID = "Message-ID:" SP ident
   Success-Report = "Success-Report:" SP ("yes" / "no" )
   Failure-Report = "Failure-Report:" SP ("yes" / "no" / "partial" )
   Byte-Range = "Byte-Range:" SP range-start "-" range-end "/" total
   range-start = 1*DIGIT
   range-end   = 1*DIGIT / "*"
   total       = 1*DIGIT / "*"

   Status = "Status:" SP namespace SP status-code [SP text-reason]
   namespace = "000"
   text-reason = utf8text

   ident = alphanum  3*31ident-char
   ident-char = alphanum / "." / "-" / "+" / "%" / "="

   content-stuff = *(Other-Mime-Header CRLF)
                   Content-Type 2CRLF data CRLF

   Content-Type = "Content-Type:" SP media-type
   media-type = type "/" subtype *( ";" gen-param )
   type = token
   subtype = token

   gen-param = pname [ "=" pval ]
   pname = token
   pval  = token / quoted-string

   token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E
              / %x30-39 / %x41-5A / %x5E-7E)
              ; token is compared case-insensitive

   quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE
   qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E
               / UTF8-NONASCII
   BACKSLASH = "\"
   UPALPHA  = %x41-5A

   Other-Mime-Header = (Content-ID
    / Content-Description
    / Content-Disposition
    / mime-extension-field);

Campbell, et al.         Expires August 24, 2005               [Page 31]

Internet-Draft                    MSRP                     February 2005

       ; 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 = *(HTAB / %x20-7E / UTF8-NONASCII)

                 / %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  408

   A 408 response indicates that a downstream transaction did not
   complete in the alloted time.  It is never sent by any elements
   described in this specification.  However, 408 is used in the MSRP

Campbell, et al.         Expires August 24, 2005               [Page 32]

Internet-Draft                    MSRP                     February 2005

   Relay extension; therefore MSRP endpoints may receive it.  An
   endpoint MUST treat a 408 response in the same manner as it would
   treat a local timeout.

10.5  413

   A 413 response indicates that the receiver wishes the sender to stop
   sending the particular message.  Typically, a 413 is sent in response
   to a chunk of an undesired message.

   If a message sender receives a 413 in a response, or in a REPORT
   request, it MUST NOT send any further chunks in the message, that is,
   any further chunks with the same Message-ID value.  If the sender
   receives the 413 while in the process of sending a chunk, and the
   chunk is interruptible, the sender MUST abort sending the chunk.

10.6  415

   A 415 response indicates the SEND request contained a MIME
   content-type that is not understood by the receiver.

10.7  423

   A 423 response indicates that one of the requested parameters is out
   of bounds.  It is used by the relay extensions to this document.

10.8  426

   A 426 response indicates that the request is only allowed over TLS
   protected connections.

10.9  481

   A 481 response indicates that the indicated session does not exist.

10.10  501

   A 501 response indicates that the recipient does not understand the
   request method.

      The 501 response code exists to allow some degree of method
      extensibility.  It is not intended as a license to ignore methods
      defined in this document; rather it is a mechanism to report lack
      of support of extension methods.

10.11  506

   A 506 response indicates that a request arrived on a session which is

Campbell, et al.         Expires August 24, 2005               [Page 33]

Internet-Draft                    MSRP                     February 2005

   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 and the answerer is

           Alice                     Bob
             |                        |
             |                        |
             |(1) (SIP) INVITE        |
             |(2) (SIP) 200 OK        |
             |(3) (SIP) ACK           |
             |(4) (MSRP) SEND         |
             |(5) (MSRP) 200 OK       |
             |(6) (MSRP) SEND         |
             |(7) (MSRP) 200 OK       |
             |(8) (SIP) BYE           |
             |(9) (SIP) 200 OK        |
             |                        |
             |                        |

   1.  Alice constructs a local URL of
       msrp://;tcp .

       Alice->Bob (SIP): INVITE

       o=alice 2890844557 2890844559 IN IP4
       c=IN IP4
       t=0 0
       m=message 7777 msrp/tcp *

Campbell, et al.         Expires August 24, 2005               [Page 34]

Internet-Draft                    MSRP                     February 2005


   2.  Bob listens on port 8888, and sends the following response:

       Bob->Alice (SIP): 200 OK

       o=bob 2890844612 2890844616 IN IP4
       c=IN IP4
       t=0 0
       m=message 8888 msrp/tcp *

   3.  Alice->Bob (SIP): ACK

   4.  (Alice opens connection to Bob.) Alice->Bob (MSRP):

       MSRP d93kswow SEND
       Message-ID: 12339sdqwer
       Content-Type: text/plain

       Hi, I'm Alice!

   5.  Bob->Alice (MSRP):

       MSRP d93kswow 200 OK

   6.  Bob->Alice (MSRP):

       MSRP dkei38sd SEND
       Message-ID: 456
       Content-Type: text/plain

       Hi, Alice! I'm Bob!

   7.  Alice->Bob (MSRP):

Campbell, et al.         Expires August 24, 2005               [Page 35]

Internet-Draft                    MSRP                     February 2005

       MSRP dkei38sd 200 OK

   8.  Alice->Bob (SIP): BYE

       Alice invalidates local session state.

   9.  Bob invalidates local state for the session.

       Bob->Alice (SIP): 200 OK

11.2  Message with XHTML Content

   MSRP dsdfoe38sd SEND
   Message-ID: 456

   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE html
   PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   <html xmlns="" xml:lang="en" lang="en">
       <title>FY2005 Results</title>
      <p>See the results at<a

11.3  Chunked Message

   For an example of a chunked message, see the example in Section 5.1.

11.4  System Message

   Sysadmin->Alice (MSRP):

   MSRP d93kswow SEND
   Message-ID: 12339sdqwer

Campbell, et al.         Expires August 24, 2005               [Page 36]

Internet-Draft                    MSRP                     February 2005

   Failure-Report: no
   Success-Report: no
   Content-Type: text/plain

   This conference will end in 5 minutes

11.5  Positive Report

   Alice->Bob (MSRP):

   MSRP d93kswow SEND
   Message-ID: 12339sdqwer
   Success-Report: yes
   Content-Type: text/html

   <p>Here is that important link...
   <a href="">foobar</a>

   Bob->Alice (MSRP):

   MSRP d93kswow 200 OK

   Bob->Alice (MSRP):

   MSRP dkei38sd REPORT
   Message-ID: 12339sdqwer
   Status: 000 200 OK

11.6  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

Campbell, et al.         Expires August 24, 2005               [Page 37]

Internet-Draft                    MSRP                     February 2005

   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 [29].  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).

      The example uses REGISTER to learn of Juliet's registered
      contacts.  This does not constitute an endorsement of that
      approach; it is used here to avoid cluttering the example with too
      many SIP details.  A more realistic application would be the use a
      SIP proxy or redirect server for this purpose.

   We query for a list of Juliet's contacts by sending a REGISTER:

   To: Juliet <>
   From: Juliet <>;tag=12345
   Call-ID: 09887877
   CSeq: 772 REGISTER

   The Response contains her Contacts:

   SIP/2.0 200 OK
   To: Juliet <>
   From: Juliet <>;tag=12345
   Call-ID: 09887877
   CSeq: 772 REGISTER
   Contact: <>
   Contact: <>
   Contact: <>;q=0.4;expires=3600

Campbell, et al.         Expires August 24, 2005               [Page 38]

Internet-Draft                    MSRP                     February 2005

   Contact: <>;q=0.1;expires=3600

   When Romeo opens his IM program, he selects Juliet and types the
   message "art thou hither?" (instead of "you there?").  His client
   sends a SIP invitation to  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 MSRP URIs involved.  After a
   delay of a several seconds with no reply or activity from Juliet, the
   proxy cancels the invitation at her first two contacts, and forwards
   the invitation on to Juliet's PDA.  Since her father is talking to
   her about her wedding, she selects "Do Not Disturb" on her PDA, which
   sends a "Busy Here" response.  The proxy then tries the Nurse, who
   answers and tells Romeo what is going on.

    Romeo       Juliet's     Juliet/      Juliet/      Juliet/     Nurse
                 Proxy       balcony      chamber       PDA

      |            |            |            |           |           |
      |--INVITE--->|            |            |           |           |
      |            |--INVITE--->|            |           |           |
      |            |<----180----|            |           |           |
      |<----180----|            |            |           |           |
      |---PRACK---------------->|            |           |           |
      |<----200-----------------|            |           |           |
      |<===Early MSRP Session==>| art thou hither?       |           |
      |            |            |            |           |           |
      |            |--INVITE---------------->|           |           |
      |            |<----180-----------------|           |           |
      |<----180----|            |            |           |           |
      |---PRACK----------------------------->|           |           |
      |<----200------------------------------|           |           |
      |<========Early MSRP Session==========>| art thou hither?      |
      |            |            |            |           |           |
      |            |            |            |           |           |
      |            | .... Time Passes ....   |           |           |
      |            |            |            |           |           |
      |            |            |            |           |           |
      |            |--CANCEL--->|            |           |           |
      |            |<---200-----|            |           |           |
      |            |<---487-----|            |           |           |
      |            |----ACK---->|            |           |           |
      |            |--CANCEL---------------->|           |           |
      |            |<---200------------------|           |           |
      |            |<---487------------------|           |           |
      |            |----ACK----------------->|           |           |

Campbell, et al.         Expires August 24, 2005               [Page 39]

Internet-Draft                    MSRP                     February 2005

      |            |--INVITE---------------------------->|  romeo wants
      |            |            |            |           |  to IM w/ you
      |            |<---486 Busy Here--------------------|           |
      |            |----ACK----------------------------->|           |
      |            |            |            |           |           |
      |            |--INVITE---------------------------------------->|
      |            |<---200 OK---------------------------------------|
      |<--200 OK---|            |            |           |           |
      |<================MSRP Session================================>|
      |            |            |            |           |           |
      |                                         Hi Romeo, Juliet is  |
      |                                         with her father now  |
      |                                         can i take a message?|
      |                                                              |
      |  Tell her to go to confession tomorrow....                  |

12.  Extensibility

   MSRP was designed to be only minimally extensible.  New MSRP Methods,
   Headers, and status codes can be defined in standards track RFCs.
   There is no registry of headers, methods, or status codes, since the
   number of new elements and total extensions is expected to be very
   small.  MSRP does not contain a version number or any negotiation
   mechanism to require or discover new features.  If a
   non-interoperable update or extension occurs in the future, it will
   be treated as a new protocol, and must describe how its use will be

   In order to allow extension header fields without breaking
   interoperability, if an MSRP device receives a request or response
   containing a header field that it does not understand, it MUST ignore
   the header field and process the request or response as if the header
   field was not present.  If an MSRP device receives a request with an
   unknown method, it MUST return a 501 response.

   MSRP was designed to use lists of URLs instead of a single URL in the
   To-Path and From-Path headers in anticipation of relay or gateway
   functionality being added.  In addition, msrp: and msrps: URLs can
   contain parameters which are extensible.

13.  CPIM compatibility

   MSRP sessions may go to a gateway to other CPIM [24] compatible
   protocols.  If this occurs, the gateway MUST maintain session state,
   and MUST translate between the MSRP session semantics and CPIM

Campbell, et al.         Expires August 24, 2005               [Page 40]

Internet-Draft                    MSRP                     February 2005

   semantics,  which do not include a concept of sessions.  Furthermore,
   when one endpoint of the session is a CPIM gateway, instant messages
   SHOULD be wrapped in "message/cpim" [12] bodies.  Such a gateway MUST
   include "message/cpim" as the first entry in its SDP accept-types
   attribute.  MSRP endpoints sending instant messages to a peer that
   has included 'message/cpim" as the first entry in the accept-types
   attribute SHOULD encapsulate all instant message bodies in
   "message/cpim" wrappers.  All MSRP endpoints MUST support the
   message/cpim type, and SHOULD support the S/MIME features of that

   If a message is to be wrapped in a message/cpim envelope, the
   wrapping MUST be done prior to breaking the message into chunks, if

   All MSRP endpoints MUST recognize the From, To, DateTime, and Require
   headers as defined in RFC3862.  Such applications SHOULD recognize
   the CC header, and MAY recognize the Subject header.  Any MSRP
   application that recognizes any message/cpim header MUST understand
   the NS (name space) header.

   All message/cpim body parts sent by an MSRP endpoint MUST include the
   From and To headers.  If the message/cpim body part is protected
   using S/MIME, then it MUST also include the DateTime header.

   The NS, To, and CC headers may occur multiple times.  Other headers
   defined in RFC3862 MUST NOT occur more than once in a given
   message/cpim body part in an MSRP message.  The Require header MAY
   include multiple values.  The NS header MAY occur zero or more times,
   depending on how many name spaces are being referenced.

   Extension headers MAY occur more than once, depending on the
   definition of such headers.

      Using message/cpim envelopes are also useful if an MSRP device
      wishes to send a message on behalf of some other identity.  The
      device may add a message/cpim envelope with the appropriate From
      header value.

14.  Security Considerations

   Instant Messaging systems are used to exchange a variety of sensitive
   information ranging from personal conversations, to corporate
   confidential information, to account numbers and other financial
   trading information.  IM is used by individuals, corporations, and
   governments for communicating important information.  Like many
   communications systems, the properties of Integrity and
   Confidentiality of the exchanged information, along with the

Campbell, et al.         Expires August 24, 2005               [Page 41]

Internet-Draft                    MSRP                     February 2005

   possibility of Anonymous communications, and knowing you are
   communicating with the correct other party are required.  MSRP pushes
   many of the hard problems to SIP when SIP sets up the session, but
   some of the problems remain.  Spam and DoS attacks are also very
   relevant to IM systems.

   MSRP needs to provide confidentiality and integrity for the messages
   it transfers.  It also needs to provide assurances the connected host
   is the host that it meant to connect to and that the connection has
   not been hijacked.

14.1  Transport Level Protection

   When using only TCP connections, MSRP security is fairly weak.  If
   host A is contacting B, B passes its hostname and a secret to A using
   a rendezvous protocol.  Although MSRP requires the use of a
   rendezvous protocol with the ability to protect this exchange, there
   is no guarantee that the protection will be used all the time.  If
   such protection is not used, anyone can see this secret.  A then
   connects to the provided host name and passes the secret in the clear
   across the connection to B.  A assumes that it is talking to B based
   on where it sent the SYN packet and then delivers the secret in plain
   text across the connections.  B assumes it is talking to A because
   the host on the other end of the connection delivered the secret.  An
   attacker that could ACK the SYN packet could insert itself as a man
   in the middle in the connection.

   When using TLS connections, the security is significantly improved.
   We assume that the host accepting the connection has a certificate
   from a well know certificate authority.  Furthermore, we assume that
   the signaling to set up the session is protected by the rendezvous
   protocol.  In this case, when host A contacts host B, the secret is
   passed through a confidential channel to A.  A connects with TLS to
   B.  B presents a valid certificate, so A knows it really is connected
   to B.  A then delivers the secret provided by B, so that B can verify
   it is connected to A.  In this case, a rogue SIP Proxy can see the
   secret in the SIP signaling traffic and could potentially insert
   itself as a man-in-the-middle.

   Realistically, using TLS is difficult for peer to peer connections,
   as the types of hosts that end clients use for sending instant
   messages are unlikely to have long term stable IP addresses or DNS
   names that certificate can bind to.  In addition, the cost of server
   certificates from well known certificate authorities is currently
   expensive enough to discourage their use for each client.  While not
   in scope for this document, using TLS with a DH profile is possible.

   TLS becomes much more practical when some form of relay is

Campbell, et al.         Expires August 24, 2005               [Page 42]

Internet-Draft                    MSRP                     February 2005

   introduced.  Clients can then form TLS connections to relays, which
   are much more likely to have TLS certificates.  While this
   specification does not address such relays, they are described by a
   companion document [20].  That document makes extensive use of TLS to
   protect traffic between clients and relays, and between one relay and

   TLS is used to authenticate devices and to provide integrity and
   confidentiality for the headers being transported.  MSRP elements
   MUST implement TLS and MUST also implement the TLS
   ClientExtendedHello extended hello information for server name
   indication as described in [10].  A TLS cipher-suite of
   TLS_RSA_WITH_AES_128_CBC_SHA [13] MUST be supported (other
   cipher-suites MAY also be supported).

14.2  S/MIME

   The only strong security for non-TLS connections is achieved using

   Since MSRP carries arbitrary MIME content, it can trivially carry
   S/MIME protected messages as well.  All MSRP implementations MUST
   support the multipart/signed MIME type even if they do not support
   S/MIME.  Since SIP can carry a session key, S/MIME messages in the
   context of a session could also be protected using a key-wrapped
   shared secret [25] provided in the session setup.  MSRP is a binary
   protocol and MIME bodies MUST be transfered with a transfer encoding
   of binary.  If a message is both signed and encrypted, it SHOULD be
   signed first, then encrypted.  If S/MIME is supported, SHA-1, RSA,
   and AES-128 MUST be supported.

   This does not actually require the endpoint to have certificates from
   a well known certificate authority.  When MSRP is used with SIP, the
   Identity [21] and Certificates [22] mechanism provides S/MIME based
   delivery of a secret between A and B.  No SIP intermediary except the
   explicitly trusted authentication service (one per user) can see the
   secret.  The S/MIME encryption of the SDP can also be used by SIP to
   exchange keying material that can be used in MRSP.  The MSRP session
   can then use S/MIME with this keying material to encrypt and sign
   messages sent over MSRP.  The connection can still be hijacked since
   the secret is sent in clear text to the other end of the TCP
   connection, but the consequences are mitigated if all the MSRP
   content is encrypted and signed with S/MIME.  It is out of scope for
   this document but there is nothing stopping the SIP negotiation of
   MSRP session from negotiating symmetric keying material that is used
   with S/MIME for integrity and privacy.

Campbell, et al.         Expires August 24, 2005               [Page 43]

Internet-Draft                    MSRP                     February 2005

14.3  Other Security Concerns

   MSRP can not be used as an amplifier for DoS attacks, but it can be
   used to form a distributed attack to consume TCP connection resource
   on servers.  The attacker, Eve, sends a SIP INVITE with no offer to
   Alice.  Alice returns a 200 with an offer and Eve returns an answer
   with the SDP that indicates that her MSRP address is the address of
   Tom.  Since Alice sent the offer, Alice will initiate a connection to
   Tom using up resources on Tom's server.  Given the huge number of IM
   clients, and the relatively few TCP connections that most servers
   support, this is a fairly straightforward attack.

   SIP is attempting to address issues in dealing with spam.  The spam
   issue is probably best dealt with at the SIP level when an MSRP
   session is initiated and not at the MSRP level.

   If a sender chooses to employ S/MIME to protect a message, all S/MIME
   operations MUST occur prior to breaking the message into chunks, if

   The signaling will have set up the session to or from some specific
   URLs that will often have "im:" or "sip:" URI schemes.  When the
   signaling has been set up to a specific end users, and S/MIME is
   implemented, then the client needs to verify that the name in the
   SubjectAltName of the certificate contains an entry that matches the
   URI that was used for the other end in the signaling.  There are some
   cases, such as IM conferencing, where the S/MIME certificate name and
   the signaled identity will not match.  In these cases the client
   should ensure that the user is informed that the message came from
   the user identified in the certificate and does not assume that the
   message came from the party they signaled.

   In some cases, a sending device may need to attribute a message to
   some other identity, and may use different identities for different
   messages in the same session.  For example, a conference server may
   send messages on behalf of multiple users on the same session.
   Rather than add additional headers to MSRP for this purpose, MSRP
   relies on the message/cpim format for this purpose.  The sender may
   envelope such a message in a message/cpim body, and place the actual
   sender identity in the From field.  The trustworthiness of such an
   attribution is affected by the security properties of the session in
   the same way that the trustworthiness of the identity of the actual
   peer is affected, with the additional issue of determining whether
   the recipient trusts the sender to assert the identity.

   This approach can result in nesting of message/cpim envelopes.  For
   example, a message originates from a CPIM gateway, and is then
   forwarded by a conference server onto a new session.  Both the

Campbell, et al.         Expires August 24, 2005               [Page 44]

Internet-Draft                    MSRP                     February 2005

   gateway and the conference server introduce envelopes.  In this case,
   the recipient client SHOULD indicate the chain of identity assertions
   to the user, rather than allow the user to assume that either the
   gateway or the conference server originated the message.

   It is possible that a recipient might receive messages that are
   attributed to the same sender via different MSRP sessions.  For
   example, Alice might be in a conversation with Bob via an MSRP
   session over a TLS protected channel.  Alice might then receive a
   different message from Bob over a different session, perhaps with a
   conference server that asserts Bob's identity in a message/cpim
   envelope signed by the server.

   MSRP does not prohibit multiple simultaneous sessions between the
   same pair of identities.  Nor does it prohibit an endpoint sending a
   message on behalf of another identity, such as may be the case for a
   conference server.  The recipient's endpoint should determine its
   level of trust of the authenticity of the sender independently for
   each session.  The fact that an endpoint trusts the authenticity of
   the sender on any given session should not affect the level of trust
   it assigns for apparently the same sender on a different session.

   When MSRP clients form or acquire a certificate, they SHOULD ensure
   that the subjectAltName has a GeneralName entry of type
   uniformResourceIdentifier for each URL corresponding to this client
   and should always include an "im:" URI.  It is fine if the
   certificate contains other URIs such as an "sip:" or "xmpp:" URIs.

   MSRP implementors should be aware of a potential attack on MSRP
   devices that involves placing very large values in the byte-range
   header field, potentially causing the device to allocate very large
   memory buffers to hold the message.  Implementations SHOULD apply
   some degree of sanity checking on byte-range values before allocating
   such buffers.

15.  IANA Considerations

15.1  MSRP Port

   MSRP uses TCP port XYX, to be determined by IANA after this document
   is approved for publication.  Usage of this value is described in
   Section 6

15.2  MSRP URL Schemes

   This document defines the URL schemes of "msrp" and "msrps".

Campbell, et al.         Expires August 24, 2005               [Page 45]

Internet-Draft                    MSRP                     February 2005

   Syntax: See Section 6.
   Character Encoding: See Section 6.
   Intended Usage: See Section 6.
   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 Transport Protocol

   MSRP defines the a new SDP protocol field value "msrp/tcp", which
   should be registered in the sdp-parameters registry under "proto".
   This value indicates the MSRP protocol when TCP is used as an
   underlying transport.

   Specifications defining new protocol values must define the rules for
   the associated media format namespace.  The "msrp/tcp" protocol value
   allows only one value in the format field (fmt), which is a single
   occurrence of "*".  Actual format determination is made using the
   "accept-types" and "accept-wrapped-types" attributes.

15.4  SDP Attribute Names

   This document registers the following SDP attribute parameter names
   in the sdp-parameters registry.  These names are to be used in the
   SDP att-name field.

15.4.1  Accept Types

   Contact Information: Ben Campbell (
   Attribute-name:  accept-types
   Long-form Attribute Name: Acceptable MIME Types
   Type: Media level
   Subject to Charset Attribute: No
   Purpose and Appropriate Values: The "accept-types" attribute contains
      a list of MIME content-types that the endpoint is willing to
      receive.  It may contain zero or more registered MIME types, or
      "*" in a space delimited string.

15.4.2  Wrapped Types

   Contact Information: Ben Campbell (
   Attribute-name:  accept-wrapped-types
   Long-form Attribute Name: Acceptable MIME Types Inside Wrappers

Campbell, et al.         Expires August 24, 2005               [Page 46]

Internet-Draft                    MSRP                     February 2005

   Type: Media level
   Subject to Charset Attribute: No
   Purpose and Appropriate Values: The "accept-wrapped-types" attribute
      contains a list of MIME content-types that the endpoint is willing
      to receive in an MSRP message with multipart content, but may not
      be used as the outermost type of the message.  It may contain zero
      or more registered MIME types, or "*" in a space delimited string.

15.4.3  Max Size

   Contact Information: Ben Campbell (
   Attribute-name:  max-size
   Long-form Attribute Name: Maximum message size.
   Type: Media level
   Subject to Charset Attribute: No
   Purpose and Appropriate Values: The "max-size" attribute indicates
      the largest message an endpoint wishes to accept.  It may take any
      numeric value, specified in octets.

15.4.4  Path

   Contact Information: Ben Campbell (
   Attribute-name:  path
   Long-form Attribute Name: MSRP URL Path
   Type: Media level
   Subject to Charset Attribute: No
   Purpose and Appropriate Values: The "path" attribute indicates a
      series of MSRP devices that must be visited by messages sent in
      the session, including the final endpoint.  The attribute contains
      one or more MSRP URIs, delimited by the space character.

16.  Change History

16.1  draft-ietf-simple-message-sessions-10

      Changed SDP m-line protocol field to "msrp/tcp".  Added
      requirement to copy the MSRP address and port from the path to the
      c and m lines as a courtesy to legacy SDP devices.  The path
      attribute is still used as previousl specificed.
      Changed SDP reference to point to SDP-New draft.
      Relaxed the URL session-id syntax to allow (unreserved / "+" / "="
      / "/" ), to make it easier to embed base64 encoded information.
      Updated example in overview to have Byte-Range header.
      Added 413 response code.
      Changed report-failure and report-success to failure-report and
      success-report, respectively.  Change made to increase parsing

Campbell, et al.         Expires August 24, 2005               [Page 47]

Internet-Draft                    MSRP                     February 2005

      Refined the iana registration section.
      Added registration of "msrp" as an sdp proto field value in iana
      Moved 408 and 423 from relays document to this draft.
      Expanded security considerations to include more discussion of the
      difficulties of peer-to-peer TLS, and how relays can help make
      that better.

16.2  draft-ietf-simple-message-sessions-09

   o  Updated retransmission when receiving a failure report.
   o  Added applicability statement.
   o  Added CPIM application considerations.
   o  Added language to security considerations about receiving messages
      from the same sender over different sessions.
   o  Added 501 response code.
   o  Various scrubbing of the ABNF
   o  Change resource construction name to session-id in MSRP syntax.
   o  Added language to define the purpose of msrp URLs.
   o  Change RFC2396 reference to 2396bis
   o  Clarify that max-size is in octets.
   o  Clarify that userinfo is restricted to unreserved characters,
      which is an additional restriction over the RFC2396 version.
   o  Consolidated the ABNF for the MSRP URL into the formal syntax
   o  Clarified that if an MSRP endpoint receives and SDP offer and does
      not understand any of the media types, it SHOULD return a SIP 488
      response, or whatever is appropriate for the rendezvous protocol.
   o  Added more text around using message/cpim for identity

16.3  draft-ietf-simple-message-sessions-08

   o  Removed DSN section.  Removed statements that an error report
      SHOULD contain a body.  REPORT requests may now contain
      informational bodies no larger than 2K, but the recipient is free
      to ignore them.
   o  Added the "#" value for the continuation-flag to indicate the last
      chunk of an abandoned message.
   o  Added direction that s/mime and cpim envelops must be applied
      before chunking.
   o  Added direction to set the last-byte field in byte-range to "*" if
      there is any chance of interrupting a SEND request.
   o  Changed to refer to entire message, instead of a particular MIME
   o  Added requirement for the use of UTF-8, and reference to RFC3629
   o  Added requirement to ignore unknown headers.

Campbell, et al.         Expires August 24, 2005               [Page 48]

Internet-Draft                    MSRP                     February 2005

   o  Several ABNF fixes
   o  Removed redundant material between normative sections.
   o  Numerous editorial fixes.

16.4  draft-ietf-simple-message-sessions-07

   o  Significant re-write to attempt to improve readability.
   o  Added maximum size parameter in accept-types
   o  Changed the Boundary field to be part of the start-line rather
      than a header field.
   o  Removed the TR-ID header, and changed request-response matching to
      be based on the Boundary field value.  Responses still contain the
      TR-ID header, which must match the Boundary from the request.
   o  Removed transport selection from URL scheme and added the "tcp"
   o  Added description of the "simple" mode with no transaction
      responses, and made mode selection dependent on the reporting
      level requested for a give message.
   o  Changed the DSN section to reflect separate request of success and
      failure reports.  Enhanced REPORT method to be useful even without
      a payload.
   o  removed SRV usage for URL resolution.  This is only used for relay
      discovery, and therefore should be moved to the relay draft.
   o  Added discussion about late REPORT handling.  Asserted that REPORT
      requests are always sent in simple mode.
   o  Removed the dependency on multipart/byteranges for fragmentation.
      Incorporated the Byte-Range header into the base MSRP header set.
   o  Removed the VISIT method.  Change to use SEND to serve the purpose
      formerly reserved to VISIT.

16.5  draft-ietf-simple-message-sessions-06

   o  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.
   o  Changed mechanism for signaling transport and TLS protection into
      the MSRP URL, rather than the SDP M-Line.
   o  Removed length field from start line and added Boundary header
      field and Closing field.
   o  Added recommendation to fragment any content over 2k.
   o  Added Rohan's proposal to make offerer connect to answerer.  (With
      open issue for more discussion.)
   o  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.
   o  Updated DSN section.  Added text on field usage.
   o  Fixed change TR-ID header from version 05 were erroneously
      attributed to 04.

Campbell, et al.         Expires August 24, 2005               [Page 49]

Internet-Draft                    MSRP                     February 2005

16.6  draft-ietf-simple-message-sessions-05

   o  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.
   o  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.
   o  Added section for Delivery Status Notification handling, and added
      associated entries into the syntax definition.
   o  Added content fragmentation section.
   o  Removed recommendation to start separate session for large
   o  Corrected some mistakes in the syntax definitions.
   o  Added Chris Boulton as a co-author for his contribution of the DSN

16.7  draft-ietf-simple-message-sessions-04

   o  Removed the direction attribute.  Rather than using a comedia
      styled direction negotiation, we just state that the answerer
      opens any needed connection.

16.8  draft-ietf-simple-message-sessions-03

   o  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.
   o  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.
   o  Added text describing subsequent SDP exchanges.  Added mandatory
      "count" parameter to the direction attribute to allow explicit
      signaling of the need to reconnect.
   o  Added text to describe the use of send and receive only indicators
      in SDP for one-way transfer of large content.
   o  Added text requiring unique port field values if multiple M-line's

Campbell, et al.         Expires August 24, 2005               [Page 50]

Internet-Draft                    MSRP                     February 2005

   o  Corrected a number of editorial mistakes.

16.9  draft-ietf-simple-message-sessions-02

   o  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.
   o  Added "other-method" construction to the message syntax to allow
      for extensible methods.
   o  Consolidated all syntax definitions into the same section.
      Cleaned up ABNF for digest challenge and response syntax.
   o  Changed the session inactivity timeout to 12 minutes.
   o  Required support for the SHA1 algorithm.
   o  Required support for the message/cpim format.
   o  Fixed lots of editorial issues.
   o  Documented a number of open issues from recent list discussions.

16.10  draft-ietf-simple-message-sessions-01

   o  Abstract rewritten.
   o  Added architectural considerations section.
   o  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.
   o  Added a standard dummy value for the m-line port field.  Clarified
      that a zero in this field has normal SDP meaning.
   o  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.
   o  Changed digest algorithm to SHA1.  Added TR-ID and S-URI to the
      hash for digest authentication.
   o  CMS usage replaced with S/MIME.
   o  TLS and msrps: usage clarified.
   o  Session state timeout is now based on SEND activity, rather than
      BIND and VISIT refreshes.
   o  Default port added.
   o  Added sequence diagrams to the example message flows.
   o  Added discussion of self-signed certificates in the security
      considerations section.

16.11  draft-ietf-simple-message-sessions-00

   o  Name changed to reflect status as a work group item.
   o  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 URL, rather than a separate one for
      each endpoint.  The session URL is not required to be in requests

Campbell, et al.         Expires August 24, 2005               [Page 51]

Internet-Draft                    MSRP                     February 2005

      other than BIND and VISIT, as the session can be determined based
      on the connection on which it arrives.
   o  BIND and VISIT now create soft state, eliminating the need for the
      RELEASE and LEAVE methods.
   o  The MSRP URL format was changed to better reflect generic URL
      standards.  URL comparison and resolution rules were added.  SRV
      usage added.
   o  Determination of host and visitor roles now uses a direction
      attribute much like the one used in COMEDIA.
   o  Format list negotiation expanded to allow a "prefer these formats
      but try anything" semantic
   o  Clarified handling of direction notification failures.
   o  Clarified signaling associated with session failure due to dropped
   o  Clarified security related motivations for MSRP.
   o  Removed MIKEY dependency for session key exchange.  Simple usage
      of k-lines in SDP, where the SDP exchange is protected end-to-end
      seems sufficient.

16.12  draft-campbell-simple-im-sessions-01

   Version 01 is a significant re-write.  References to COMEDIA were
   removed, as it was determined that COMEDIA would not allow
   connections to be used bidirectional in the presence of NATs.
   Significantly more discussion of a concrete mechanism has been added
   to make up for no longer using COMEDIA.  Additionally, this draft and
   draft-campbell-cpimmsg-sessions (which would have also changed
   drastically) have now been combined into this single draft.

17.  Contributors and Acknowledgments

   In addition to the editors, The following people contributed
   extensive work to this document: Chris Boulton, Paul Kyzivat, Orit
   Levin, Adam Roach, Jonathan Rosenberg, and Robert Sparks.

   The following people contributed substantial discussion and feedback
   to this ongoing effort: Eric Burger, Allison Mankin, Jon Peterson,
   Brian Rosen, Dean Willis, Aki Niemi, Hisham Khartabil, Pekka Pessi,
   Miguel Garcia, Peter Ridler, and Sam Hartman.

18.  References

18.1  Normative References

   [1]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
         RFC 2246, January 1999.

   [2]   Handley, M., Jacobson, V. and C. Perkins, "SDP: Session

Campbell, et al.         Expires August 24, 2005               [Page 52]

Internet-Draft                    MSRP                     February 2005

         Description Protocol",
         Internet-Draft draft-ietf-mmusic-sdp-new-23, December 2004.

   [3]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         Session Description Protocol (SDP)", RFC 3264, June 2002.

   [4]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [5]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [6]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 2234, November 1997.

   [7]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part One: Format of Internet Message Bodies",
         RFC 2045, November 1996.

   [8]   Troost, R., Dorner, S. and K. Moore, "Communicating
         Presentation Information in Internet Messages: The
         Content-Disposition Header Field", RFC 2183, August 1997.

   [9]   Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax",
         internet-draft draft-fielding-uri-rfc2396bis-07, September

   [10]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and
         T. Wright, "Transport Layer Security (TLS) Extensions",
         RFC 3546, June 2003.

   [11]  Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
         Method", RFC 3311, October 2002.

   [12]  Klyne, G. and D. Atkins, "Common Presence and Instant Messaging
         (CPIM): Message Format", RFC 3862, August 2004.

   [13]  Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
         Transport Layer Secur ity (TLS)", RFC 3268, June 2002.

   [14]  Yergeau, F., "UTF-8, a transformation format of ISO 10646",
         RFC 3629, November 2003.

18.2  Informational References

   [15]  Johnston, A. and O. Levin, "Session Initiation Protocol Call

Campbell, et al.         Expires August 24, 2005               [Page 53]

Internet-Draft                    MSRP                     February 2005

         Control - Conferencing for User Agents",
         Internet-Draft draft-ietf-sipping-cc-conferencing-05, October

   [16]  Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo,
         "Best Current Practices for Third Party Call Control in the
         Session  Initiation Protocol", rfc 3725, April 2004.

   [17]  Sparks, R. and A. Johnston, "Session Initiation Protocol Call
         Control - Transfer",
         Internet-Draft draft-ietf-sipping-cc-transfer-03, October 2004.

   [18]  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and
         D. Gurle, "Session Initiation Protocol (SIP) Extension for
         Instant Messaging", RFC 3428, December 2002.

   [19]  Mahy, R., "Benefits and Motivation for Session Mode Instant
         Internet-Draft draft-mahy-simple-why-session-mode-01, February

   [20]  Jennings, C. and R. Mahy, "Relay Extensions for Message
         Sessions Relay Protocol (MSRP)",
         Internet-Draft draft-ietf-simple-msrp-relays-03, February 2005.

   [21]  Peterson, J. and C. Jennings, "Enhancements for Authenticated
         Identity Management in the Session Initiation  Protocol (SIP)",
         Internet-Draft draft-ietf-sip-identity-03 , September 2004.

   [22]  Jennings, C. and J. Peterson, "Certificate Management Service
         for SIP", Internet-Draft draft-ietf-sipping-certs-00, October

   [23]  Yon, D., "Connection-Oriented Media Transport in SDP",
         Internet-Draft draft-ietf-mmusic-sdp-comedia-09, September

   [24]  Peterson, J., "A Common Profile for Instant Messaging (CPIM)",
         rfc 3860, August 2004.

   [25]  Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217,
         December 2001.

   [26]  Ramsdell, B., "S/MIME Version 3 Message Specification",
         RFC 2633, June 1999.

   [27]  Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone
         Generation in the Session Initiation Protocol (SIP)",

Campbell, et al.         Expires August 24, 2005               [Page 54]

Internet-Draft                    MSRP                     February 2005

         Internet-Draft draft-ietf-sipping-early-media-02, June 2004.

   [28]  Saint-Andre, P., "Extensible Messaging and Presence Protocol
         (XMPP): Instant Messaging and  Presence", rfc 3921, October

   [29]  Rosenberg, J., "Indicating User Agent Capabilities in the
         Session Initiation Protocol  (SIP)", rfc 3840, August 2004.

Authors' Addresses

   Ben Campbell (editor)
   Estacado Systems


   Rohan Mahy (editor)
   110 Nortech Parkway
   San Jose, CA  95134


   Cullen Jennings (editor)
   Cisco Systems, Inc.
   170 West Tasman Dr.
   MS: SJC-21/2
   San Jose, CA  95134

   Phone: +1 408 421-9990

Campbell, et al.         Expires August 24, 2005               [Page 55]

Internet-Draft                    MSRP                     February 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Campbell, et al.         Expires August 24, 2005               [Page 56]