tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4975

 Errata 
Proposed STD
Pages: 63
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: SIMPLE

The Message Session Relay Protocol (MSRP)

Part 1 of 4, p. 1 to 16
None       Next RFC Part

Updated by:    7977


Top       ToC       Page 1 
Network Working Group                                   B. Campbell, Ed.
Request for Comments: 4975                              Estacado Systems
Category: Standards Track                                   R. Mahy, Ed.
                                                             Plantronics
                                                        C. Jennings, Ed.
                                                     Cisco Systems, Inc.
                                                          September 2007


               The Message Session Relay Protocol (MSRP)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document describes the Message Session Relay Protocol, a
   protocol for transmitting a series of related instant messages in the
   context of a session.  Message sessions are treated like any other
   media stream when set up via a rendezvous or session creation
   protocol such as the Session Initiation Protocol.

Top       Page 2 
Table of Contents

   1. Introduction ....................................................4
   2. Conventions .....................................................5
   3. Applicability of MSRP ...........................................5
   4. Protocol Overview ...............................................6
   5. Key Concepts ....................................................9
      5.1. MSRP Framing and Message Chunking ..........................9
      5.2. MSRP Addressing ...........................................10
      5.3. MSRP Transaction and Report Model .........................11
      5.4. MSRP Connection Model .....................................12
   6. MSRP URIs ......................................................14
      6.1. MSRP URI Comparison .......................................15
      6.2. Resolving MSRP Host Device ................................16
   7. Method-Specific Behavior .......................................17
      7.1. Constructing Requests .....................................17
           7.1.1. Sending SEND Requests ..............................18
           7.1.2. Sending REPORT Requests ............................21
           7.1.3. Generating Success Reports .........................22
           7.1.4. Generating Failure Reports .........................23
      7.2. Constructing Responses ....................................24
      7.3. Receiving Requests ........................................25
           7.3.1. Receiving SEND Requests ............................25
           7.3.2. Receiving REPORT Requests ..........................27
   8. Using MSRP with SIP and SDP ....................................27
      8.1. SDP Connection and Media-Lines ............................28
      8.2. URI Negotiations ..........................................29
      8.3. Path Attributes with Multiple URIs ........................30
      8.4. Updated SDP Offers ........................................31
      8.5. Connection Negotiation ....................................31
      8.6. Content Type Negotiation ..................................32
      8.7. Example SDP Exchange ......................................34
      8.8. MSRP User Experience with SIP .............................35
      8.9. SDP Direction Attribute and MSRP ..........................35
   9. Formal Syntax ..................................................36
   10. Response Code Descriptions ....................................38
      10.1. 200 ......................................................38
      10.2. 400 ......................................................38
      10.3. 403 ......................................................38
      10.4. 408 ......................................................39
      10.5. 413 ......................................................39
      10.6. 415 ......................................................39
      10.7. 423 ......................................................39
      10.8. 481 ......................................................39
      10.9. 501 ......................................................39
      10.10. 506 .....................................................40

Top      ToC       Page 3 
   11. Examples ......................................................40
      11.1. Basic IM Session .........................................40
      11.2. Message with XHTML Content ...............................42
      11.3. Chunked Message ..........................................43
      11.4. Chunked Message with Message/CPIM Payload ................43
      11.5. System Message ...........................................44
      11.6. Positive Report ..........................................44
      11.7. Forked IM ................................................45
   12. Extensibility .................................................48
   13. CPIM Compatibility ............................................48
   14. Security Considerations .......................................49
      14.1. Secrecy of the MSRP URI ..................................50
      14.2. Transport Level Protection ...............................50
      14.3. S/MIME ...................................................51
      14.4. Using TLS in Peer-to-Peer Mode ...........................52
      14.5. Other Security Concerns ..................................53
   15. IANA Considerations ...........................................55
      15.1. MSRP Method Names ........................................55
      15.2. MSRP Header Fields .......................................55
      15.3. MSRP Status Codes ........................................56
      15.4. MSRP Port ................................................56
      15.5. URI Schema ...............................................56
           15.5.1. MSRP Scheme .......................................56
           15.5.2. MSRPS Scheme ......................................57
      15.6. SDP Transport Protocol ...................................57
      15.7. SDP Attribute Names ......................................58
           15.7.1. Accept Types ......................................58
           15.7.2. Wrapped Types .....................................58
           15.7.3. Max Size ..........................................58
           15.7.4. Path ..............................................58
   16. Contributors and Acknowledgments ..............................59
   17. References ....................................................59
      17.1. Normative References .....................................59
      17.2. Informative References ...................................60

Top      ToC       Page 4 
1.  Introduction

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

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

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

   When a user uses an Instant Messaging (IM) URL, RFC 3861 [32] defines
   how DNS can be used to map this to a particular protocol to establish
   the session such as SIP.  SIP can use an offer/answer model to
   transport the MSRP URIs for the media in SDP.  This document defines
   how the offer/answer exchange works to establish MSRP connections and
   how messages are sent across the MSRP, but it does not deal with the
   issues of mapping an IM URL to a session establishment protocol.

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

Top      ToC       Page 5 
   This document specifies MSRP behavior only for peer-to-peer sessions,
   that is, sessions crossing only a single hop.  MSRP relay devices
   [23] (referred to herein as "relays") are specified in a separate
   document.  An endpoint that implements this specification, but not
   the relay specification, will be unable to introduce relays into the
   message path, but will still be able to interoperate with peers that
   do use relays.

2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [5].

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

3.  Applicability of MSRP

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

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

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

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

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

   SIP meets these requirements for a rendezvous mechanism.  The MSRP
   URIs are exchanged using SDP in an offer/answer exchange via SIP.

Top      ToC       Page 6 
   The exchanged SDP can also be used to negotiate MSRP extensions.
   This SDP can be secured using any of the mechanisms available in SIP,
   including using the sips mechanism to ensure transport security
   across intermediaries and Secure/Multipurpose Internet Mail
   Extensions (S/MIME) for end-to-end protection of the SDP body.  SIP
   can carry arbitrary URIs (including im: URIs) in the Request-URI, and
   procedures are available to map im: URIs to sip: or sips: URIs.  It
   is expected that initial deployments of MSRP will use SIP as its
   rendezvous mechanism.

4.  Protocol Overview

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

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

       Alice sends to Bob:

   INVITE sip:bob@biloxi.example.com SIP/2.0
   To: <sip:bob@biloxi.example.com>
   From: <sip:alice@atlanta.example.com>;tag=786
   Call-ID: 3413an89KU
   Content-Type: application/sdp

   c=IN IP4 atlanta.example.com
   m=message 7654 TCP/MSRP *
   a=accept-types:text/plain
   a=path:msrp://atlanta.example.com:7654/jshA7weztas;tcp

Top      ToC       Page 7 
       Bob sends to Alice:

   SIP/2.0 200 OK
   To: <sip:bob@biloxi.example.com>;tag=087js
   From: <sip:alice@atlanta.example.com>;tag=786
   Call-ID: 3413an89KU
   Content-Type: application/sdp

   c=IN IP4 biloxi.example.com
   m=message 12763 TCP/MSRP *
   a=accept-types:text/plain
   a=path:msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp

       Alice sends to Bob:

   ACK sip:bob@biloxi SIP/2.0
   To: <sip:bob@biloxi.example.com>;tag=087js
   From: <sip:alice@atlanta.example.com>;tag=786
   Call-ID: 3413an89KU

                          Figure 1: Session Setup

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

Top      ToC       Page 8 
   MSRP a786hjs2 SEND
   To-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
   From-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
   Message-ID: 87652491
   Byte-Range: 1-25/25
   Content-Type: text/plain

   Hey Bob, are you there?
   -------a786hjs2$

   MSRP a786hjs2 200 OK
   To-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
   From-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
   -------a786hjs2$

                      Figure 2: Example MSRP Exchange

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

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

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

   Alice and Bob choose their MSRP URIs in such a way that it is
   difficult to guess the exact URI.  Alice and Bob can reject requests
   to URIs they are not expecting to service and can correlate the
   specific URI with the probable sender.  Alice and Bob can also use

Top      ToC       Page 9 
   TLS [1] to provide channel security over this hop.  To receive MSRP
   requests over a TLS protected connection, Alice or Bob could
   advertise URIs with the "msrps" scheme instead of "msrp".

   MSRP is designed with the expectation that MSRP can carry URIs for
   nodes on the far side of relays.  For this reason, a URI with the
   "msrps" scheme makes no assertion about the security properties of
   other hops, just the next hop.  The user agent knows the URI for each
   hop, so it can verify that each URI has the desired security
   properties.

   MSRP URIs are discussed in more detail in Section 6.

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

5.  Key Concepts

5.1.  MSRP Framing and Message Chunking

   Messages sent using MSRP can be very large and can be delivered in
   several SEND requests, where each SEND request contains one chunk of
   the overall message.  Long chunks may be interrupted in mid-
   transmission to ensure fairness across shared transport connections.
   To support this, MSRP uses a boundary-based framing mechanism.  The
   start line of an MSRP request contains a unique identifier that is
   also used to indicate the end of the request.  Included at the end of
   the end-line, there is a flag that indicates whether this is the last
   chunk of data for this message or whether the message will be
   continued in a subsequent chunk.  There is also a Byte-Range header
   field in the request that indicates the overall position of this
   chunk inside the complete message.

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

Top      ToC       Page 10 
    MSRP dkei38sd SEND
    Message-ID: 4564dpWd
    Byte-Range: 1-*/8
    Content-Type: text/plain

    abcd
    -------dkei38sd+

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

    EFGH
    -------dkei38ia$

                  Figure 3: Breaking a Message into Chunks

   This chunking mechanism allows a sender to interrupt a chunk part of
   the way through sending it.  The ability to interrupt messages allows
   multiple sessions to share a TCP connection, and for large messages
   to be sent efficiently while not blocking other messages that share
   the same connection, or even the same MSRP session.  Any chunk that
   is larger than 2048 octets MUST be interruptible.  While MSRP would
   be simpler to implement if each MSRP session used its own TCP
   connection, there are compelling reasons to conserve connections.
   For example, the TCP peer may be a relay device that connects to many
   other peers.  Such a device will scale better if each peer does not
   create a large number of connections.  (Note that in the above
   example, the initial chunk was interruptible for the sake of example,
   even though its size is well below the limit for which
   interruptibility would be required.)

   The chunking mechanism only applies to the SEND method, as it is the
   only method used to transfer message content.

5.2.  MSRP Addressing

   MSRP entities are addressed using URIs.  The MSRP URI schemes are
   defined in Section 6.  The syntax of the To-Path and From-Path header
   fields each allows for a list of URIs.  This was done to allow the
   protocol to work with relays, which are defined in a separate
   document, to provide a complete path to the end recipient.  When two
   MSRP nodes communicate directly, they need only one URI in the To-
   Path list and one URI in the From-Path list.

Top      ToC       Page 11 
5.3.  MSRP Transaction and Report Model

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

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

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

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

   The combinations of reporting are needed to meet the various
   scenarios of currently deployed IM systems.  Success-Report might be
   "no" in many public systems to reduce load, but might be "yes" in
   certain enterprise systems, such as systems used for securities
   trading.  A Failure-Report value of "no" is useful for sending system
   messages such as "the system is going down in 5 minutes" without
   causing a response explosion to the sender.  A Failure-Report of
   "yes" is used by many systems that wish to notify the user if the
   message failed.  A Failure-Report of "partial" is a way to report
   errors other than timeouts.  Timeout error reporting requires the
   sending hop to run a timer and the receiving hop to send an

Top      ToC       Page 12 
   acknowledgment to stop the timer.  Some systems don't want the
   overhead of doing this.  "Partial" allows them to choose not to do
   so, but still allows error responses to be sent in many cases.

      The term "partial" denotes that the hop-by-hop acknowledgment
      mechanism that would be required with a Failure-Report value of
      "yes" is not invoked.  Thus, each device uses only "part" of the
      set of error detection tools available to them.  This allows a
      compromise between no reporting of failures at all, and reporting
      every possible failure.  For example, with "partial", a sending
      device does not have to keep transaction state around waiting for
      a positive acknowledgment.  But it still allows devices to report
      other types of errors.  The receiving device could still report a
      policy violation such as an unacceptable content-type, or an ICMP
      error trying to connect to a downstream device.

5.4.  MSRP Connection Model

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

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

   Likewise, the active endpoint MUST immediately issue a SEND request.
   This initial SEND request MAY have a body if the sender has content
   to send, or it MAY have no body at all.

      The first SEND request serves to bind a connection to an MSRP
      session from the perspective of the passive endpoint.  If the
      connection is not authenticated with TLS, and the active endpoint
      did not send an immediate request, the passive endpoint would have
      no way to determine who had connected, and would not be able to
      safely send any requests towards the active party until after the
      active party sends its first request.

   When an element needs to form a new connection, it looks at the URI
   to decide on the type of connection (TLS, TCP, etc.) then connects to
   the host indicated by the URI, following the URI resolution rules in
   Section 6.2.  Connections using the "msrps" scheme MUST use TLS.  The

Top      ToC       Page 13 
   SubjectAltName in the received certificate MUST match the hostname
   part of the URI and the certificate MUST be valid according to RFC
   3280 [16], including having a date that is valid and being signed by
   an acceptable certification authority.  At this point, the device
   that initiated the connection can assume that this connection is with
   the correct host.

   The rules on certificate name matching and CA signing MAY be relaxed
   when using TLS peer-to-peer.  In this case, a mechanism to ensure
   that the peer used a correct certificate MUST be used.  See Section
   14.4 for details.

   If the connection used mutual TLS authentication, and the TLS client
   presented a valid certificate, then the element accepting the
   connection can verify the identity of the connecting device by
   comparing the hostname part of the target URI in the SDP provided by
   the peer device against the SubjectAltName in the client certificate.

   When mutual TLS authentication is not used, the listening device MUST
   wait until it receives a request on the connection, at which time it
   infers the identity of the connecting device from the associated
   session description.

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

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

   If a connection fails for any reason, then an MSRP endpoint MUST
   consider any sessions associated with the connection as also having
   failed.  When either endpoint notices such a failure, it MAY attempt
   to re-create any such sessions.  If it chooses to do so, it MUST use
   a new SDP exchange, for example, in a SIP re-INVITE.  If a
   replacement session is successfully created, endpoints MAY attempt to
   resend any content for which delivery on the original session could
   not be confirmed.  If it does this, the Message-ID values for the

Top      ToC       Page 14 
   resent messages MUST match those used in the initial attempts.  If
   the receiving endpoint receives more than one message with the same
   Message-ID, it SHOULD assume that the messages are duplicates.  The
   specific action that an endpoint takes when it receives a duplicate
   message is a matter of local policy, except that it SHOULD NOT
   present the duplicate messages to the user without warning of the
   duplication.  Note that acknowledgments as needed based on the
   Failure-Report and Success-Report settings are still necessary even
   for requests containing duplicate content.

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

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

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

6.  MSRP URIs

   URIs using the "msrp" and "msrps" schemes are used to identify a
   session of instant messages at a particular MSRP device, as well as
   to identify an MSRP relay in general.  This document describes the
   former usage; the latter usage is described in the MSRP relay
   specification [23].  MSRP URIs that identify sessions are ephemeral;
   an MSRP device will use a different MSRP URI for each distinct
   session.  An MSRP URI that identifies a session has no meaning
   outside the scope of that session.

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

   MSRP URIs are primarily expected to be generated and exchanged
   between systems, and are not intended for "human consumption".
   Therefore, they are encoded entirely in US-ASCII.

   The constructions for "authority", "userinfo", and "unreserved" are
   detailed in RFC 3986 [10].  URIs designating MSRP over TCP MUST
   include the "tcp" transport parameter.

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

   The MSRP URI authority field identifies a participant in a particular
   MSRP session.  If the authority field contains a numeric IP address,
   it MUST also contain a port.  The session-id part identifies a
   particular session of the participant.  The absence of the session-id
   part indicates a reference to an MSRP host device, but does not refer
   to a particular session at that device.  A particular value of
   session-id is only meaningful in the context of the associated
   authority; thus, the authority component can be thought of as
   identifying the "authority" governing a namespace for the session-id.

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

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

   The authority component will typically not contain a userinfo
   component, but MAY do so to indicate a user account for which the
   session is valid.  Note that this is not the same thing as
   identifying the session itself.  A userinfo part MUST NOT contain
   password information.

   The following is an example of a typical MSRP URI:

      msrp://host.example.com:8493/asfd34;tcp

6.1.  MSRP URI Comparison

   In the context of the MSRP protocol, MSRP URI comparisons MUST be
   performed according to the following rules:

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

   2.  If the authority component contains an explicit IP address and/or
       port, these are compared for address and port equivalence.
       Percent-encoding normalization [10] applies; that is, if any
       percent-encoded nonreserved characters exist in the authority
       component, they must be decoded prior to comparison.  Userinfo

Top      ToC       Page 16 
       parts are not considered for URI comparison.  Otherwise, the
       authority component is compared as a case-insensitive character
       string.

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

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

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

   Path normalization [10] is not relevant for MSRP URIs.

6.2.  Resolving MSRP Host Device

   An MSRP host device is identified by the authority component of an
   MSRP URI.

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

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

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

      This process assumes that the connection port is always known
      prior to resolution.  This is always true for the MSRP URI uses
      described in this document, that is, URIs exchanged in the SDP
      offer and answer.  The introduction of relays creates situations
      where this is not the case.  For example, when a user configures
      her client to use a relay, it is desirable that the relay's MSRP
      URI is easy to remember and communicate to humans.  Often this
      type of MSRP will omit the port number.  Therefore, the relay
      specification [23] describes additional steps to resolve the port
      number.

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


Next RFC Part