SIMPLE Working Group                                         B. Campbell
Internet-Draft                                              J. Rosenberg
Expires: April 22, July 27, 2004                                         R. Sparks
                                                             dynamicsoft
                                                              P. Kyzivat
                                                           Cisco Systems
                                                        October 23, 2003
                                                        January 27, 2004

                   The Message Session Relay Protocol
                 draft-ietf-simple-message-sessions-02
                 draft-ietf-simple-message-sessions-03

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 22, July 27, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003). (2004). All Rights Reserved.

Abstract

   This document describes the Message Session Relay Protocol (MSRP), a
   mechanism for transmitting a series of Instant Messages within a
   session. MSRP sessions are managed using the Session Description
   Protocol (SDP) offer/answer model carried by a signaling protocol
   such as the Session Initiation Protocol (SIP).

   MSRP supports end-to-end Instant Message Sessions, as well as
   sessions traversing one or two relays.

Table of Contents

   1.     Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.     Motivation for Session-mode Messaging  . . . . . . . . . . .   4
   3.     Scope of this Document . . . . . . . . . . . . . . . . . . .   5
   4.     Protocol Overview  . . . . . . . . . . . . . . . . . . . . .   6
   5.     Architectural Considerations . . . . . . . . . . . . . . . .   7
   5.1   Use of Relays  . . . . . . . . . . . . . . . . . . . . . . .  8
   5.2    Transferring Large Content . . . . . . . . . . . . . . . . .  8
   5.3   Connection Sharing . . . . . . . . . . . . . . . . . . . . .  9   7
   6.     SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . . 10   7
   6.1    Use of the SDP M-line  . . . . . . . . . . . . . . . . . . . 10   8
   6.2    The Direction Attribute  . . . . . . . . . . . . . . . . . . 11   8
   6.3    The Accept Types Attribute . . . . . . . . . . . . . . . . . 12  10
   6.4    MIME Wrappers  . . . . . . . . . . . . . . . . . . . . . . . 13  10
   6.5    URL Negotiations . . . . . . . . . . . . . . . . . . . . . . 13  11
   6.6    Updated SDP Offers . . . . . . . . . . . . . . . . . . . .  12
   6.7    Example SDP Exchange . . . . . . . . . . . . . . . . . . . . 14  13
   7.     The Message Session Relay Protocol . . . . . . . . . . . . . 15  13
   7.1    MSRP URLs  . . . . . . . . . . . . . . . . . . . . . . . . . 15  14
   7.1.1  MSRP URL Comparison  . . . . . . . . . . . . . . . . . . . . 16  14
   7.1.2  Resolving MSRP Host Device . . . . . . . . . . . . . . . . . 16  15
   7.1.3  The msrps URL Scheme . . . . . . . . . . . . . . . . . . . . 17  16
   7.2    MSRP messages  . . . . . . . . . . . . . . . . . . . . . . . 17  16
   7.3    MSRP Transactions  . . . . . . . . . . . . . . . . . . . . . 19  17
   7.4    MSRP Sessions  . . . . . . . . . . . . . . . . . . . . . . . 19  17
   7.4.1  Initiating an MSRP session . . . . . . . . . . . . . . . . . 19  17
   7.4.2  Handling VISIT requests  . . . . . . . . . . . . . . . . . . 23  21
   7.4.3  Sending Instant Messages on a Session  . . . . . . . . . . . 23  21
   7.4.4  Ending a Session . . . . . . . . . . . . . . . . . . . . . . 25  22
   7.4.5  Managing Session Inactivity Timer . . . State and Connections . . . . . . . . . .  23
   7.5    Method Descriptions  . . . . . 26
   7.4.6 Managing Session State and Connections . . . . . . . . . . . 27
   7.5   MSRP Relays . . .  24
   7.5.1  SEND . . . . . . . . . . . . . . . . . . . . . 27
   7.5.1 Establishing Session State at a Relay . . . . . .  24
   7.5.2  VISIT  . . . . . 28
   7.5.2 Removing Session State from a relay . . . . . . . . . . . . 29
   7.5.3 Sending IMs across an MSRP relay . . . . . . . . .  24
   7.6    Response Code Descriptions . . . . . 30
   7.5.4 Relay Pairs . . . . . . . . . . .  24
   7.6.1  200  . . . . . . . . . . . . . 30
   7.5.5 Relay Shutdown . . . . . . . . . . . . . .  24
   7.6.2  400  . . . . . . . . . 31
   7.6   Digest Authentication . . . . . . . . . . . . . . . . . .  25
   7.6.3  415  . 31
   7.6.1 The SHA1 Algorithm . . . . . . . . . . . . . . . . . . . . . 33
   7.7   Method Descriptions . . . . .  25
   7.6.4  426  . . . . . . . . . . . . . . . 33
   7.7.1 BIND . . . . . . . . . . . .  25
   7.6.5  481  . . . . . . . . . . . . . . . . 34
   7.7.2 SEND . . . . . . . . . . .  25
   7.6.6  506  . . . . . . . . . . . . . . . . . 34
   7.7.3 VISIT . . . . . . . . . .  25
   7.7    Header Field Descriptions  . . . . . . . . . . . . . . . .  25
   7.7.1  TR-ID  . 34
   7.8   Response Code Descriptions . . . . . . . . . . . . . . . . . 34
   7.8.1 200 . . . . . . . .  25
   7.7.2  Content-Type . . . . . . . . . . . . . . . . . . . . 35
   7.8.2 400 . . .  25
   7.7.3  S-URL  . . . . . . . . . . . . . . . . . . . . . . . . . 35
   7.8.3 401 .  26
   8.     Example  . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
   7.8.4 403  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
   7.8.5 415  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
   7.8.6 426  . . . . . . . . . . . . . . . . . . . . . . . . .  26
   9.     IANA Considerations  . . . 35
   7.8.7 481 . . . . . . . . . . . . . . . .  28
   9.1    MSRP Port  . . . . . . . . . . . . 35
   7.8.8 500 . . . . . . . . . . . .  28
   9.2    MSRP URL Schemes . . . . . . . . . . . . . . . . 35
   7.8.9 506 . . . . .  28
   9.2.1  Syntax . . . . . . . . . . . . . . . . . . . . . . . 35
   7.9   Header Field Descriptions . . .  28
   9.2.2  Character Encoding . . . . . . . . . . . . . . 36
   7.9.1 TR-ID . . . . . .  28
   9.2.3  Intended Usage . . . . . . . . . . . . . . . . . . . . . 36
   7.9.2 Exp .  28
   9.2.4  Protocols  . . . . . . . . . . . . . . . . . . . . . . . .  28
   9.2.5  Security Considerations  . . . 36
   7.9.3 CAuth . . . . . . . . . . . . . .  29
   9.2.6  Relevant Publications  . . . . . . . . . . . . . 36
   7.9.4 SChal . . . . .  29
   9.3    SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 37
   7.9.5 Content-Type  29
   9.3.1  Direction  . . . . . . . . . . . . . . . . . . . . . . . . 37
   7.9.6 S-URL  29
   9.3.2  Accept Types . . . . . . . . . . . . . . . . . . . . . . .  29
   9.3.3  Wrapped Types  . . . . 37
   8.    Examples . . . . . . . . . . . . . . . . . .  29
   10.    Security Considerations  . . . . . . . . 37
   8.1   No Relay . . . . . . . . .  29
   10.1   TLS and the MSRPS Scheme . . . . . . . . . . . . . . . . . 38
   8.2   Single Relay  30
   10.1.1 Sensitivity of the Session URL . . . . . . . . . . . . . .  30
   10.1.2 End to End Protection of IMs . . . . . . . . . . 40
   8.3   Two Relays . . . . .  31
   10.1.3 CPIM compatibility . . . . . . . . . . . . . . . . . . . . 43
   9.    IANA  31
   10.1.4 PKI Considerations . . . . . . . . . . . . . . . . . . . . 46
   9.1   MSRP Port  . . . . . .  32
   11.    Changes from Previous Draft Versions . . . . . . . . . . .  32
   11.1   draft-ietf-simple-message-sessions-03  . . . . . . . . 46
   9.2   MSRP URL Schemes . .  32
   11.2   draft-ietf-simple-message-sessions-02  . . . . . . . . . .  33
   11.3   draft-ietf-simple-message-sessions-01  . . . . . . . . . . 47
   9.2.1 Syntax  33
   11.4   draft-ietf-simple-message-sessions-00  . . . . . . . . . .  34
   11.5   draft-campbell-simple-im-sessions-01 . . . . . . . . . . .  34
   12.    Contributors . . . . . . 47
   9.2.2 Character Encoding . . . . . . . . . . . . . . . . .  34
          Normative References . . . . 47
   9.2.3 Intended Usage . . . . . . . . . . . . . . .  35
          Informational References . . . . . . . . 47
   9.2.4 Protocols . . . . . . . . .  35
          Authors' Addresses . . . . . . . . . . . . . . . . 47
   9.2.5 Security Considerations . . . .  36
          Intellectual Property and Copyright Statements . . . . . . . . . . . . . . 47
   9.2.6 Relevant Publications  . . . . . . . . . . . . . . . . . . . 47
   9.3   SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . 47
   9.3.1 Direction  . . . . . . . . . . . . . . . . . . . . . . . . . 47
   9.3.2 Accept Types . . . . . . . . . . . . . . . . . . . . . . . . 48
   9.3.3 Wrapped Types  . . . . . . . . . . . . . . . . . . . . . . . 48
   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 48
   10.1  TLS and the MSRPS Scheme . . . . . . . . . . . . . . . . . . 48
   10.2  Sensitivity of the Session URL . . . . . . . . . . . . . . . 49
   10.3  End to End Protection of IMs . . . . . . . . . . . . . . . . 50
   10.4  CPIM compatibility . . . . . . . . . . . . . . . . . . . . . 50
   10.5  PKI Considerations . . . . . . . . . . . . . . . . . . . . . 50
   11.   Changes from Previous Draft Versions . . . . . . . . . . . . 51
   11.1  draft-ietf-simple-message-sessions-02  . . . . . . . . . . . 51
   11.2  draft-ietf-simple-message-sessions-01  . . . . . . . . . . . 51
   11.3  draft-ietf-simple-message-sessions-00  . . . . . . . . . . . 52
   11.4  draft-campbell-simple-im-sessions-01 . . . . . . . . . . . . 52
   12.   Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53
         Normative References . . . . . . . . . . . . . . . . . . . . 53
         Informational References . . . . . . . . . . . . . . . . . . 54
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55
         Intellectual Property and Copyright Statements . . . . . . . 56

1. Introduction

   The MESSAGE [10] extension to SIP [2] allows SIP to be used to
   transmit instant messages. Instant messages sent using the MESSAGE
   method are normally independent of each other. This approach is often
   called page-mode messaging, since it follows a model similar to that
   used by many two-way pager devices. Page-mode messaging makes sense
   for instant message exchanges where a small number of messages occur.
   Endpoints may treat page-mode messages as if they took place in an
   imaginative session, but there is no formal relationship between one
   message and another.

   There are also applications in which it is useful for instant
   messages to be formally associated in a session. For example, a user
   may wish to join a text conference, participate in the conference for
   some period of time, then leave the conference. This usage is
   analogous to regular media sessions that are typically initiated,
   managed, and terminated using SIP. We commonly refer to this model as
   session-mode messaging.

   One of the primary purposes of SIP and SDP (Section 6) is the
   management of media sessions. Session-mode messaging can be thought
   of as a media session like any other.  This document describes the
   motivations for session-mode messaging, the Message Session Relay
   Protocol, and the use of the SDP offer/answer mechanism for managing
   MSRP session.

2. Motivation for Session-mode Messaging

   Message sessions offer several advantages over page-mode messages.
   For message exchanges that include more than a small number of
   message transactions, message sessions offer a way to remove
   messaging load from intervening SIP proxies. For example, a minimal
   session setup and tear-down requires one INVITE/ACK transaction, and
   one BYE transaction, for a total of 5 SIP messages. Normal SIP
   request routing allows for all but the initial INVITE transaction to
   bypass any intervening proxies that do not specifically request to be
   in the path for future requests. Session-mode messages never cross
   the SIP proxies themselves.

   Each page-mode message involves a complete SIP transaction, that is,
   a request and a response. Any page-mode message exchange that
   involves more than 2 MESSAGE requests will generate more SIP requests
   than a minimal session initiation sequence. Since MESSAGE is normally
   used outside of a SIP dialog, these requests will typically traverse
   the entire proxy network between the endpoints.

   Due to network congestion concerns, the MESSAGE method has
   significant limitations in message size, a prohibition against
   overlapping requests, etc. Much of this has been required because of
   perceived limitations in the congestion-avoidance features of SIP
   itself. Work is in progress to mitigate these concerns.

   However, session-mode messages are always sent over  reliable,
   congestion-safe transports. Therefore, there are no restrictions on
   message sizes. There is no requirement to wait for acknowledgement
   before sending another message, so that message transactions can be
   overlapped.

   Message sessions allow greater efficiency for secure message
   exchanges. The SIP MESSAGE request inherits the S/MIME features of
   SIP, allowing a message to be signed and/or encrypted. However, this
   approach requires public key operations for each message. With
   session-mode messaging, a session key can be established at the time
   of session initiation. This key can be used to protect each message
   that is part of the session. This requires only symmetric key
   operations for each subsequent IM, and no additional certificate
   exchanges are required after the initial exchange. The establishment
   of the session key can be done using standard techniques that apply
   to voice and video, in addition to instant messaging.

   Finally, SIP devices can treat message sessions like any other media
   sessions. Any SIP feature that can be applied to other sorts of media
   sessions can equally apply to message sessions. For example,
   conferencing [12], third party call control [13], call transfer [14],
   QoS integration [15], and privacy [16] can all be applied to message
   sessions.

   Messaging sessions can also reduce the overhead in each individual
   message. In page-mode, each message needs to include all of the SIP
   headers that are mandated by RFC 3261 [2]. However, many of these
   headers are not needed once a context is established for exchanging
   messages. As a result, messaging session mechanisms can be designed
   with significantly less overhead.

3. Scope of this Document

   This document describes the use of MSRP between endpoints, or via one
   or two relays, where endpoints have advance knowledge of the relays.
   It does not provide a mechanism for endpoints to determine whether a
   relay is needed, or for endpoints to discover the presence of relays.

   This document describes the use of MSRP over TCP. MSRP may be used
   over other congestion-controlled protocols such as SCTP. However, the
   specific bindings for other such protocols are outside the scope of
   this document.

4. Protocol Overview

   The Message Session Relay Protocol (MSRP) provides a mechanism for
   transporting session-mode messages between endpoints. MSRP also
   contains primitives to allow the use of one or two relay devices.
   MSRP uses connection oriented, reliable network transport protocols
   only. It is intrinsically NAT and firewall friendly, as it allows
   participants to positively associate message sessions with specific
   connections, and does not depend upon connection source address,
   which may be obscured by NATs.

   MSRP uses the following primitives:

   SEND: Used to send message content from one endpoint to another.

   VISIT: Used by an endpoint to establish a session association to the
      opposite endpoint, or to a relay that was selected by the opposite
      endpoint.

   BIND: Used by an endpoint to establish a session at a relay, and
      allow the opposite endpoint to visit that relay.

   The simplest use case for MSRP is a session that goes directly
   between endpoints, with no intermediaries involved. Assume A is an
   endpoint that wishes to establish a message session, and B is the
   endpoint invited by A. A invites B to participate in a message
   session by sending a URL that represents the session. This URL is
   temporary, and must not duplicate the URL used for any other active
   sessions.

   B "visits" A by connecting to A and sending a VISIT request
   containing the URL that A provided. This associates the connection
   from B with the session. B then responds to the invitation, informing
   A that B has accepted the session. A and B may now exchange messages
   using SEND requests on the connection.

   When either party wishes to end the session, it informs the peer
   party with a SIP BYE request. A terminates the session by
   invalidating associated state, and dropping the connection.

   The end to end case looks something like the following. (Note that
   the example shows a logical flow only; syntax will come later in this
   document.)

   A->B (SDP): offer (msrp://A/123)
   B->A (MSRP): VISIT (msrp://A/123)
   A->B (MSRP): 200 OK
   B->A (SDP): answer(msrp://A/123)
   A->B (MSRP): SEND
   B->A (MSRP): 200 OK
   B->A (MSRP): SEND
   A->B (MSRP): 200 OK

   The session state has an associated inactivity timer. This timer is
   initialized when a successful VISIT request occurs, and is reset each
   time either endpoint sends a SEND request. If this timer expires
   without being reset, the hosting device invalidates the session state
   and terminates all associated connections. Endpoints that are
   otherwise idle may keep a session active by periodically sending SEND
   requests with no content.

   A slightly more complicated case involves a single relay, known about
   in advance by one of the parties. The endpoint that has the
   preexisting relationship with the relay uses the BIND method to
   establish session state in the relay. The relay returns a temporary
   URL, that identifies the session. For endpoints A and B, and relay R,
   the flow would look like the following:

   A->R: MSRP: BIND(msrp://r)
   R->A: MSRP: 200 OK (msrp://r/4uye)
   A->B (SDP): offer (msrp://r/4uye)
   B->R (MSRP): VISIT (msrp://r/4uye)
   R->B (MSRP): 200 OK
   B->A (SDP): answer(msrp://r/4uye)
   A->R (MSRP): SEND
   R->B (MSRP): SEND
   B->R (MSRP): 200 OK
   R->A (MSRP): 200 OK
   B->R (MSRP): SEND
   R->A (MSRP): SEND
   A->R (MSRP): 200 OK
   R->B (MSRP): 200 OK

   The BIND request contains an expiration time. If a successful VISIT
   request does not occur prior to the expiration, the relay will
   destroy the session. Additionally, when tearing down a session, the
   host endpoint invalidates the session state by issuing a BIND request
   with an expiration value of zero.

5. Architectural Considerations

   There are a number of considerations that, if handled in a reasonable
   fashion, will allow more effective use of the protocols described in
   this document.

5.1 Use of Relays

   The primary motivation for relay support in MSRP is to deal with
   situations where, due to issues of network topologies, neither
   endpoint is able to receive an inbound TCP connection from the other.
   For example, both endpoints may be behind separate firewalls that
   only allow outbound connections. Relays may also be needed for policy
   enforcement. For example, parts of the financial industry require the
   logging of all communication.

   However, the use of such relays has a significant impact on the
   scalability of MSRP. Each relay will require two TCP connections for
   each session in use, as well as memory for local session state
   storage. Most general purpose platforms on which one might implement
   MSRP relays will have relatively low limits on the number of
   simultaneous TCP connections they can handle.

   Therefore relays SHOULD NOT be used indiscriminately. In the absence
   of strong reasons to use relays, MSRP endpoints SHOULD be configured
   to set up point-to-point sessions.

   MSRP supports the use of two relays, where each endpoint has a relay
   acting on its behalf. However, most of the network topology issues
   mentioned above can work with a single relay, if that relay is
   reachable by both endpoints. Dual relays are only needed for cases of
   very strict firewall policy, such as when only specific hosts are
   allowed to connect to the outside world; or situations requiring
   strict policy enforcement at both endpoint domains. If a given usage
   scenario can be solved with a single relay, then a second relay
   SHOULD NOT be used.

   In spite of these recommendations, relays serve a real purpose in
   that they increase the likelihood of two arbitrary endpoints being
   able to talk to one another. Therefore if a provider deploys MSRP
   endpoints in a network configuration that prevents them from
   receiving TCP connections from arbitrary peers, and does not wish to
   explicitly prevent MSRP communication with the outside world, then
   the provider SHOULD provide its endpoints with the use of an MSRP
   relay that is reachable from arbitrary peers.

5.2 Transferring Large Content

   MSRP endpoints may attempt to send very long messages in a session.
   For example, most commercial instant messaging systems have a file
   transfer feature. Since MSRP does not impose message size limits,
   there is nothing to prevent endpoints from transferring files over
   it.

   An analysis of whether it makes sense to do this, rather than sending
   such content over FTP, HTTP, or some other such protocol, is beyond
   the scope of this document. However, implementers should be aware of
   the impact of sending very large messages over MSRP. The primary
   impact is, since MSRP is sent over TCP, is that any additional
   messages that the sender wishes to send will be blocked until the
   large transfer is complete. This includes responses to messages sent
   by the peer. Therefore, any SEND transactions initiated by the peer
   are likely to time out, even though they are received without
   problems.

   Further, there is no way to abort the sending of a very large message
   before it is complete. For the sake of efficiency, the framing
   mechanism in MSRP is very simple. There is no clean way to recover
   framing if the complete message is not sent.

   These issues can be mitigated greatly if the endpoint simply
   establishes a separate session for the transfer. This allows the
   transfer to be sent without interfering with any instant messages
   being sent on other sessions. Further, the endpoint can abort the
   transfer by simply tearing down the transfer session. Therefore, if a
   peer wishes to send very large content, it SHOULD establish a
   dedicated session for that purpose.

      Open Issue: Do we need a mechanism to communicate the purpose of
      the session? It has been mentioned that the peer may not realize
      the purpose of the session, and start using it for normal
      messaging. Also, there has been discussion that we need a stronger
      mechanism to avoid transaction timeouts caused by long requests.

5.3 Connection Sharing

   The SIMPLE working group spent quite a bit of effort in the
   consideration of shared TCP connections. Connection sharing would
   offer value whenever a large number of message sessions cross the
   same two adjacent devices. This situation is likely to occur in the
   two relay model. It may also occur in the point-to-point model if the
   endpoints are multiuser devices, as is likely with web-hosted
   messaging services.

   Unfortunately, such connection sharing in TCP created significant
   problems. The biggest problem is it introduced a head-of-line
   blocking problem that spanned sessions. For example, if two different
   pairs of users had sessions that crossed the same shared connection,
   a large message sent on one session would block transfer of messages
   on the other session. The working group considered this an
   unacceptable property of shared connections. One possible solution
   was to put limits on message size, and possibly add mechanisms to
   allow breaking messages into many chunks. However, these solutions
   promised to add a great deal of complexity to the protocol, so the
   work group chose not to go that route.

   It may be possible to relax this requirement using other transport
   protocols, such as SCTP. The lack of connection sharing in this
   document should not be construed to prohibit shared connections on
   other such protocols. However, such specification is beyond the scope
   of this document.

6. SDP Offer-Answer Exchanges for MSRP Sessions

   MSRP sessions will typically be initiated using the Session
   Description Protocol (SDP) [1] offer-answer mechanism, carried in the
   Session Initiation Protocol (SIP) [2] or any other protocol
   supporting it. MSRP borrows the idea of the direction attributes from
   COMEDIA [18], but does not depend on that specification.

6.1 Use of the SDP M-line

   The SDP "m"-line takes the following form:

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

   For non-RTP media sessions, The media field specifies the top level
   MIME media type for the session. For MSRP sessions, the media field
   MUST have the value of "message". The port field is normally not
   used, and SHOULD be set to 9999. An exception is when the port field
   value is set to zero, according to normal SDP usage.

   The proto field MUST designate the message session mechanism and
   transport protocol, separated by a "/" character. For MSRP, left part
   of this value MUST be "msrp". For MSRP over TCP, the right part of
   this field MUST take the value "tcp". For MSRP over other transport
   protocols, the field value MUST be defined by the specification for
   that protocol binding.

   The format list list is ignored for MSRP. This is because MSRP
   formats are specified as MIME content types, which are not convenient
   to encode in the SDP format list syntax. Instead, the allowed formats
   are negotiated using "a"-line attributes. For MSRP sessions, the
   format list SHOULD contain a "*" character, and nothing else.

   The port field in the M-line is not normally used to determine the
   port to which to connect. Rather, the actual port is determined by
   the contents of the session URL (Section 7.1). However, a port value
   of zero has the normal SDP meaning.

   The following example illustrates an m-line for a message session,
   where the endpoint is willing to accept root payloads of message/
   cpim, plain text or HTML. The second two types could either be
   presented as the root body, or could be contained within message/cpim
   bodies.

      m=message 9999 msrp/tcp *

6.2 The Direction Attribute

   Since MSRP uses connection oriented transport protocols, one goal of
   the SDP negotiation is to determine which participant initiates the
   transport connection. The direction attribute advertises whether the
   offerer or answerer wishes to initiate the connection, wishes the
   peer endpoint to initiate the connection, or doesn't care.

   The endpoint that accepts the connection, or has a relay accept the
   connection on its behalf, is said to "host" the session, and is known
   as the hosting endpoint. The endpoint that initiates the connection
   is said to "visit" the session, and is known as the visiting
   endpoint.

   The direction attribute is included in an SDP a-line, with a value
   taking the following syntax:

               direction       = direction-label ":" role
               direction-label = "direction"
               role            = active / passive / both
               active          = "active"
               passive         = "passive"
               both            = "both" [sp timeout]
               timeout         = 1*DIGIT ; timeout value in seconds

   The values for the role field are as follows:

   passive: The endpoint wishes to host the session

   active: The endpoint wishes the peer to host the session.

   both: The endpoint is willing to act as either host or visitor. If
      "both" is selected, it may contain an optional timeout value. This
      timeout specifies how much time the answerer should wait before
      giving up on a connection and attempting to take over as host
      device.  If the timeout value is not specified, it defaults to 30
      seconds.

   The SDP offer for an MSRP session MUST contain a direction attribute,
   which MAY take any of the defined values. If the offerer is capable
   of hosting the session, or can arrange for a relay to host the
   session on its behalf, then it SHOULD select "both". The endpoint
   SHOULD NOT select "active" unless it cannot host the session under
   any circumstances. The endpoint SHOULD NOT select "passive" unless it
   has no option but to host the session.

   The SDP answer also MUST contain a direction attribute, but its value
   choices are limited based on the value in the offer. If the offer
   contained "active", then the answerer MUST either select "passive" or
   reject the offer. Likewise, if the offer contained  "passive", then
   the answerer MUST select "active" or reject the offer. If the offer
   contained "both", the answerer SHOULD select "active", but MAY select
   "passive" if it is unable to reach the host device, or if local
   policy requires it to act as host.

6.3 The Accept Types Attribute

   MSRP can carry any MIME encoded payload. Endpoints specify MIME
   content types that they are willing to receive in the accept types
   "a"-line attribute. This attribute has the following syntax:

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

   SDP offers for MSRP sessions MUST include an accept-types attribute.
   SDP answers MUST also include the attribute, which MUST contain
   either the same list as in the offer or a subset of that list.

   A "*" entry in the accept-types attribute indicates that the sender
   may attempt to send messages with media types that have not been
   explicitly listed. If the receiver is able to process the media type,
   it does so. If not, it will respond with a 415. 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.
   (Note that the container type MUST also be listed in the accept-types
   attribute.)

6.4 MIME Wrappers

   The MIME content-types in the accept-types attribute will often
   include container types; that is, types that contain other types. For
   example, "message/cpim" or "multipart/mixed."  Occasionally an
   endpoint will need to specify a MIME body type that can only be used
   if wrapped inside a listed container type.

   Endpoints MAY specify MIME types that are only allowed to be wrapped
   inside compound types using the "accept-wrapped-types" attribute in
   an SDP a-line. This attribute has the following syntax:

               accept-wrapped-types = wrapped-types-label ":" format-list
               wrapped-types-label  = "accept-wrapped-types"

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

   This approach does not allow for specifying distinct lists of
   acceptable wrapped types for different types of containers. If an
   endpoint 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
   themselves.

      The approach of specifying types that are only allowed inside of
      containers separately from the primary payload types allows an
      endpoint to force the use of certain wrappers. For example, a CPIM
      gateway device may require all messages to be wrapped inside
      message/cpim bodies, but may allow several content types inside
      the wrapper. If the gateway were to specify the wrapped types in
      the accept-types attribute, its peer could choose to use those
      types without the wrapper.

6.5 URL Negotiations

   An MSRP session is identified by an MSRP URL, which is determined by
   the hosting endpoint, and negotiated in the SDP exchange. Any SDP
   offer or answer that creates a possibility that the sender will host
   the session, that is, it contains a direction value of "passive" or
   "both",  MUST contain an MSRP URL in a session attribute. This
   attribute has the following syntax:

   a=session:<MSRP_URL>

   where <MSRP_URL> is an MSRP or MSRPS URL as defined in Section 7.1.

   The visitor will use the session URL established by the host both to
   resolve the host address and port, and to identify the session when
   connecting. For MSRP sessions, the address field in the C-line is not
   relevant, and MUST be ignored. The port field in the M-line MUST be
   ignored if non-zero. Zero values have the normal meaning for SDP.

   The following example shows an SDP offer with a session URL of
   "msrp://example.com:7394/2s93i"

           c=IN IP4 useless.host.name
           m=message 9999 msrp/tcp *
           a=accept-types:text/plain
           a=direction:both
           a=session:msrp://example.com:7394/2s93i

   The session URL MUST be a temporary URL assigned just for this
   particular session. It MUST NOT duplicate any URL in use for any
   other session hosted by the endpoint or relay. Further, since the
   peer endpoint will use the session URL to identify itself when
   connecting, it SHOULD be hard to guess, and protected from
   eavesdroppers. This will be discussed in more detail in Section 10.

6.6 Example SDP Exchange

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

     c=IN IP4 alice.example.com
     m=message 9999 msrp/tcp *
     a=accept-types: message/cpim text/plain text/html
     a=direction:both
     a=session:msrp://alice.example.com:7394/2s93i9

   Endpoint B chooses to participate in the role of visitor, opens a TCP
   connection to alice.example.com:7394, and successfully performs a
   VISIT transaction passing the URL of msrp://alice.example.com:7394/
   2s93i9. B indicates that it has accomplished this by answering with:

     c=IN IP4 dontlookhere
     m=message 9999 msrp/tcp *
     a=accept-types:message/cpim text/plain
     a=direction:active

   A may now send IMs to B by executing SEND transactions on the same
   connection on which B sent the VISIT request.

7. The Message Session Relay Protocol

   The Message Session Relay Protocol (MSRP) is a text based, message
   oriented protocol for the transfer of instant messages in the context
   of a session. MSRP uses the UTF8 character set.

   MSRP messages MUST be sent over a reliable, congestion-controlled,
   connection-oriented transport protocol. This document specifies the
   use of MSRP over TCP. Other documents may specify bindings for other
   such protocols.

7.1 MSRP URLs

   MSRP sessions are identified by MSRP URLs. An MSRP URL follows a
   subset of the URL syntax in Appendix A of RFC2396 [4], with a scheme
   of "msrp":

      msrp_url = "msrp" ":" "//" [userinfo] hostport ["/' resource]
      resource = 1*unreserved

   The constructions for "userinfo", "hostport", and "unreserved" are
   detailed in RFC2396 [4].

   An MSRP URL server part identifies the hosting device of an MSRP
   session. If the server part contains a numeric IP address, it MUST
   also contain a port. The resource part identifies a particular
   session at that host device. The absence of the resource part
   indicates a reference to an MSRP host device, but does not
   specifically refer to a particular session resource.

   MSRP has an  IANA registered recommended port defined in Section 9.1.
   This value SHOULD NOT be considered a default, as the URL process
   described herein will always explicitly resolve a port number.
   However, the URLs SHOULD be configured so that the recommended port
   is used whenever appropriate. This makes life easier for network
   administrators who need to manage firewall policy for MSRP.

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

   The following is an example of a typical MSRP URL:

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

7.1.1 MSRP URL Comparison

   MSRP URL comparisons MUST be performed according to the following
   rules:

   1.  The host part is compared as case insensitive.

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

   3.  The resource part is compared as case insensitive. A URL without
       a resource part is never equivalent to one that includes a
       resource part.

   4.  Userinfo parts are not considered for URL comparison.

   Path normalization is not relevant for MSRP URLs. Escape
   normalization is not required, since the relevant parts are limited
   to unreserved characters.

7.1.2 Resolving MSRP Host Device

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

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

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

   If the server part contains a host name but no port, the connecting
   device MUST perform the following steps:

   1.  Construct an SRV [6] query  string by prefixing the host name
       with the service field "_msrp" and the protocol field ("_tcp" for
       TCP). For example, "_msrp._tcp.host.example.com".

   2.  Perform a DNS SRV query using this query string.

   3.  Select a resulting record according to the rules in RFC2782 [6].
       Determine the port from the chosen record.

   4.  If necessary, determine a host device address by performing an A
       or AAAA query on the host name field in the selected SRV result
       record. If multiple A or AAAA records are returned, the first
       entry SHOULD be chosen for the initial connection attempt. This
       allows any ordering created in the DNS to be preserved.

   5.  If the connection attempt fails, the device SHOULD attempt to
       connect to the addresses returned in any additional A or AAAA
       records, in the order the records were presented. If all of these
       fail, the device SHOULD attempt to use any additional SRV records
       that may have been returned, following the normal rules for SRV
       record selection.

   Note that in most cases, the transport protocol will  38

1. Introduction

   The MESSAGE [10] extension to SIP [2] allows SIP to be determined
   separately from the resolution process. For example, if the MSRP URL
   was communicated in an SDP offer or answer, the SDP M-line will
   contain used to
   transmit instant messages. Instant messages sent using the transport protocol. When an MSRP URL is communicated
   outside MESSAGE
   method are normally independent of SDP, the protocol SHOULD also be communicated. For
   example, a client may be configured to use a particular relay that each other. This approach is
   referenced with an MSRP URL. The client MUST also be told what
   protocol to use. If often
   called page-mode messaging, since it follows a device needs model similar to resolve an MSRP URL and does
   not know the protocol, it SHOULD assume TCP.

7.1.3 The msrps URL Scheme

   The "msrps" URL Scheme indicates that each hop MUST be secured with
   TLS. Otherwise, it is
   used identically as an MSRP URL, except that by many two-way pager devices. Page-mode messaging makes sense
   for instant message exchanges where a
   MSRPS URL MUST NOT be considered equivalent to an MSRP URL. The MSRPS
   scheme is further discussed in Section 10.

7.2 MSRP small number of messages

   MSRP occur.
   Endpoints may treat page-mode messages are either requests or responses. Requests as if they took place in an
   imaginative session, but there is no formal relationship between one
   message and
   responses another.

   There are distinguished from one another by the first line. The
   first line of also applications in which it is useful for instant
   messages to be formally associated in a Request takes the form of the request-start entry
   below. Likewise, the first line of session. For example, a response takes user
   may wish to join a text conference, participate in the form of
   response-start. The syntax conference for an MSRP message is as follows:

       msrp-message   = request-start/response-start *(header CRLF)
                                  [CRLF body]
       request-start  = "MSRP" SP length SP  Method CRLF
       response-start = "MSRP" SP length SP Status-Code SP
                                Reason CRLF

       length       = 1*DIGIT  ; the length
   some period of time, then leave the message,
                               ;  exclusive conference. This usage is
   analogous to regular media sessions that are typically initiated,
   managed, and terminated using SIP. We commonly refer to this model as
   session-mode messaging.

   One of the start line.
       Method       = SEND / BIND / VISIT / other-method
       other-method = token
       header       = Client-Authenticate / Server-Challenge /
                      Transaction-ID / Session-URL/ Content-Type / Expires
       Status-Code  = 200    ;Success
                    / 400    ;Bad Request
                    / 401    ;Authentication Required
                    / 403    ;Forbidden
                    / 415    ;Unsupported Content Type
                    / 426    ;Upgrade Required
                    / 481    ;No session
                    / 500    ;Cannot Deliver
                    / 506    ;duplicate session

       Reason              = token ; Human readable text describing status
       Client-Authenticate = "CAuth" ":" credentials
       Server-Challenge    = "SChal" ":" challenge
       Transaction-ID      = "Tr-ID" ":" token
       Content-Type        = "Content-Type" ":" quoted-string
       Session-URL         = "S-URL" ":" msrp_url
       Expires             = "Exp"":" delta-seconds
       delta-seconds       = 1*DIGIT ; Integer number of seconds

       challenge           = digest-scheme SP digest-challenge *("," digest-challenge)
       digest-scheme       = "Digest"
       digest-challenge    = nonce / algorithm / auth-param
       nonce               = "nonce" "=" nonce-value
       nonce-value         = quoted-string
       algorithm           = "algorithm" "=" ( "SHA1" / token )

       credentials         = "Digest" digest-response *("," digest-response)
       digest-response     = username / nonce / response / algorithm /
                             auth-param
       username            = "username" "=" username-value
       username-value      = quoted-string
       response            = "response" "=" request-digest
       request-digest      = <"> 40LHEX <">
       LHEX                =  "0" / "1" / "2" / "3" /
                              "4" / "5" / "6" / "7" /
                              "8" / "9" / "a" / "b" /
                              "c" / "d" / "e" / "f"

   All requests and responses MUST contain at least primary purposes of SIP and SDP (Section 6) is the
   management of media sessions. Session-mode messaging can be thought
   of as a TR-ID header
   field. Messages MAY contain other fields, depending on media session like any other.  This document describes the method or
   response code.

7.3 MSRP Transactions

   An
   motivations for session-mode messaging, the Message Session Relay
   Protocol, and the use of the SDP offer/answer mechanism for managing
   MSRP transaction consists session.

2. Motivation for Session-mode Messaging

   Message sessions offer several advantages over page-mode messages.
   For message exchanges that include more than a small number of exactly
   message transactions, message sessions offer a way to remove
   messaging load from intervening SIP proxies. For example, a minimal
   session setup and tear-down requires one request INVITE/ACK transaction, and
   one response.
   A response matches BYE transaction, for a total of 5 SIP messages. Normal SIP
   request routing allows for all but the initial INVITE transaction if it share to
   bypass any intervening proxies that do not specifically request to be
   in the same TR-ID value, path for future requests. Session-mode messages never cross
   the SIP proxies themselves.

   Each page-mode message involves a complete SIP transaction, that is,
   a request and arrives on a response. Any page-mode message exchange that
   involves more than 2 MESSAGE requests will generate more SIP requests
   than a minimal session initiation sequence. Since MESSAGE is normally
   used outside of a SIP dialog, these requests will typically traverse
   the same connection on which entire proxy network between the endpoints.

   Due to network congestion concerns, the MESSAGE method has
   significant limitations in message size, a prohibition against
   overlapping requests, etc. Much of this has been required because of
   perceived limitations in the transaction was sent.

   BIND congestion-avoidance features of SIP
   itself. Work is in progress to mitigate these concerns.

   However, session-mode messages are always hop by hop. VISIT transactions sent over  reliable,
   congestion-safe transports. Therefore, there are usually hop-by-hop,
   but may no restrictions on
   message sizes. There is no requirement to wait for acknowledgement
   before sending another message, so that message transactions can be relayed in situations where
   overlapped.

   Message sessions allow greater efficiency for secure message
   exchanges. The SIP MESSAGE request inherits the visiting endpoint uses S/MIME features of
   SIP, allowing a
   relay. message to be signed and/or encrypted. However, SEND transactions are end-to-end, meaning that under
   normal circumstances this
   approach requires public key operations for each message. With
   session-mode messaging, a session key can be established at the response time
   of session initiation. This key can be used to protect each message
   that is sent by part of the peer endpoint, even
   if there session. This requires only symmetric key
   operations for each subsequent IM, and no additional certificate
   exchanges are intervening relays.

   Endpoints MUST select TR-ID header field values required after the initial exchange. The establishment
   of the session key can be done using standard techniques that apply
   to voice and video, in requests so addition to instant messaging.

   Finally, SIP devices can treat message sessions like any other media
   sessions. Any SIP feature that
   they are not repeated by can be applied to other sorts of media
   sessions can equally apply to message sessions. For example,
   conferencing [12], third party call control [13], call transfer [14],
   QoS integration [15], and privacy [16] can all be applied to message
   sessions.

   Messaging sessions can also reduce the same endpoint overhead in scope of the given
   session. TR-ID values SHOULD be globally unique. The TR-ID space of each endpoint is independent individual
   message. In page-mode, each message needs to include all of the SIP
   headers that are mandated by RFC 3261 [2]. However, many of its peer. Endpoints MUST NOT
   infer any semantics from the TR-ID header field beyond what is stated
   above. In particular, TR-ID values these
   headers are not required to follow any
   sequence.

   MSRP Transactions complete when needed once a response context is received, or after a
   timeout interval expires with no response. Endpoints MUST treat such
   timeouts in exactly the same way they would treat a 500 response. The
   timeout interval SHOULD be 30 seconds, but other values may be established as for exchanging
   messages. As a matter of local policy.

7.4 MSRP Sessions

   AN MSRP result, messaging session is a context in which a series mechanisms can be designed
   with significantly less overhead.

3. Scope of instant messages
   are exchanged, using SEND requests. A session has two endpoints (a
   host and a visitor) and may have one or two relays. A session is
   identified by an MSRP URL.

7.4.1 Initiating an MSRP session

   When an endpoint wishes to engage a peer endpoint in a message
   session, it invites the peer to communicate using an SDP offer,
   carried over SIP or some other protocol supporting this Document

   This document describes the SDP offer/
   answer model. For use of MSRP between endpoints. It does
   not specify the purpose use of this document, we will refer intermediaries, nor does it prohibit such use.
   We expect an extension to the
   endpoint choosing this specification to initiate communication as the offerer, define MSRP
   intermediaries and their use.

   This document describes the
   peer being invited use of MSRP over TCP. MSRP may be used
   over other congestion-controlled protocols such as SCTP. However, the answerer.

   The offerer SHOULD volunteer to act as
   specific bindings for other such protocols are outside the hosting endpoint if
   allowed by policy and network topology. An endpoint is said to host a
   session if one scope of two conditions are true.
   this document.

4. Protocol Overview

   The host either directly
   listens for Message Session Relay Protocol (MSRP) provides a mechanism for
   transporting session-mode messages between endpoints. MSRP uses
   connection from oriented, reliable network transport protocols only. It
   can operate in the peer endpoint, presence of many NAT and maintains
   session state itself, or firewall environments, as
   it uses a BIND request allows participants to initialize session
   state at a relay that will listen for a connection from the peer. The
   peer that is positively associate message sessions with
   specific connections, and does not depend upon connection source
   address, which may be obscured by NATs.

   MSRP uses the host is designated as the visitor. The offerer
   MAY request the answerer following primitives:

   SEND: Used to act as host if it is prevented send message content from
   accepting connections by network topology or policy, and is not able one endpoint to bind another.

   VISIT: Used by an endpoint to establish a relay session association to act on its behalf.

   If the offerer wishes to
      host the session directly, that endpoint.

   Assume A is without
   using an endpoint that wishes to establish a relay, it MUST perform message session,
   and B is the following steps:

   1.  Construct endpoint invited by A. A invites B to participate in a
   message session MSRP URL . This by sending a URL MUST be resolvable to that represents the
       offerer. The session. This
   URL SHOULD be is temporary, SHOULD be hard to guess, and MUST must not duplicate the URL  of used for any other session currently
       hosted
   active sessions.

   B "visits" A by the offerer.

   2.  Listen for connecting to A and sending a connection from the peer.

   3.  Construct an SDP offer as described in Section 6, including the
       list of allowed IM payload formats in the accept-types attribute.
       The offerer maps VISIT request
   containing the session URL to the session attribute, as
       described in Section 6.5.

   4.  Insert a direction attribute. This value SHOULD be "both",
       indicating that A provided. This associates the offerer will allow the answerer to override
       the offerer's decision to host. If "both" is selected, the
       offerer SHOULD leave the timeout at the default value (by leaving
       out the value entirely. However, the offerer MAY select a
       different timeout if circumstances warrant it. The direction
       value MAY be "passive" if the offerer is prevented connection
   from allowing
       the answerer override this choice.

   5.  Send the SDP offer using the normal processing for the signaling
       protocol.

   If the offerer chooses to force B with the answerer session. B then responds to host the session, it
   MUST perform the following steps instead:

   1.  Construct an SDP offer as described above, but with no session
       attribute.

   2.  Insert a direction attribute with a value of "active".

   3.  Send invitation, informing
   A that B has accepted the offer session. A and B may now exchange messages
   using normal processing for SEND requests on the signaling
       protocol. connection.

   When the answerer receives the SDP offer and chooses either party wishes to participate
   in end the session, it must choose whether to act as the host or the
   visitor. informs its peer with
   a SIP BYE request. A direction attribute value of "both" in the offer indicates
   that terminates the offerer prefers to host, but will allow session by invalidating
   associated state, and dropping the answerer connection.

   The end to
   host.  In this end case looks something like the answerer SHOULD act as following. (Note that
   the visitor, but MAY
   choose to host. A value example shows a logical flow only; syntax will come later in this
   document.)

   A->B (SDP): offer (msrp://A/123)
   B->A (MSRP): VISIT (msrp://A/123)
   A->B (MSRP): 200 OK
   B->A (SDP): answer(msrp://A/123)
   A->B (MSRP): SEND
   B->A (MSRP): 200 OK
   B->A (MSRP): SEND
   A->B (MSRP): 200 OK

5. Architectural Considerations

   There are a number of "passive" means the offerer insists upon
   hosting, considerations that, if handled in which case the answerer MUST act as visitor or decline
   the offer.

   If the answerer chooses to participate as a visitor, it MUST perform
   the following steps:

   1.  Determine the host address and port from the session URL,
       following reasonable
   fashion, will allow more effective use of the procedures protocols described in section Section 7.1

   2.  Connect
   this document.

5.1 Transferring Large Content

   MSRP endpoints may attempt to the host address and port, using the transport
       protocol from the M-line.

   3.  Construct send very long messages in a VISIT request, which MUST contain the following
       information:

       1.  An S-URL header field containing the session URL.

       2.  A TR-ID header field containing session.
   For example, most commercial instant messaging systems have a unique transaction ID.

       3.  A size field containing file
   transfer feature. Since MSRP does not impose message size limits,
   there is nothing to prevent endpoints from transferring files over
   it.

   An analysis of the message subsequent whether it makes sense to the
           start-line.

   4.  Send the request and wait for a response

   5.  If the transaction succeeds, send a SDP answer via the signaling do this, rather than sending
   such content over FTP, HTTP, or some other such protocol, according to the following rules:

       1.  The C-line is  copied unmodified from beyond
   the offer.

       2.  The M-Line contains a dummy port value, scope of this document. However, implementers should be aware of
   the protocol field
           from impact of sending very large messages over MSRP. The primary
   impact is, since MSRP is sent over TCP, is that any additional
   messages that the original offer, and sender wishes to send will be blocked until the accept-types attribute
           contains
   large transfer is complete. This includes responses to messages sent
   by the peer. Therefore, any SEND payload media types that transactions initiated by the answerer peer
   are likely to time out, even though they are received without
   problems.

   Further, there is
           willing no way to accept. The accept-types attribute in abort the answer
           MUST be either sending of a very large message
   before it is complete. For the same as that sake of efficiency, the offer, or it MUST framing
   mechanism in MSRP is very simple. There is no clean way to recover
   framing if the complete message is not sent.

   These issues can be a
           subset.

       3.  A direction attribute containing mitigated greatly if the value "active".

   6.  If endpoint simply
   establishes a separate session for the transaction fails, transfer. This allows the answerer MAY choose
   transfer to act as host,
       if allowed by be sent without interfering with any instant messages
   being sent on other sessions. Further, the direction attribute of endpoint can abort the answer. If
   transfer by simply tearing down the
       answerer is unable or unwilling transfer session. Therefore, if a
   peer wishes to host, then send very large content, it should return an
       error response as appropriate SHOULD establish a
   dedicated session for that purpose. It should also indicate that the signaling protocol.

   Some TCP connection failure conditions may ordinarily take some time
   to notice. For example, if the offerer
   dedicated session is unable to open a TCP
   connection to send only, so that the host device, this connection receiving endpoint does
   not attempt may take a
   fairly large number of seconds to timeout. This length of time will
   not be acceptable for many call flow scenarios. Therefore, the
   devices SHOULD limit send content back along the time they wait same session.

6. SDP Offer-Answer Exchanges for the TCP connection to a
   shorter timeout value, which MSRP Sessions

   MSRP sessions will default to 30 seconds. However, typically be initiated using the
   offerer MAY supply a different time Session
   Description Protocol (SDP) [1] offer-answer mechanism, carried in the timeout parameter
   Session Initiation Protocol (SIP) [2] or any other protocol
   supporting it. MSRP borrows the idea of the
   "both" direction value. If the offerer supplies a value, the answerer
   SHOULD use that value for the TCP connection timeout, interpreted as
   an integer number attributes from
   COMEDIA [18], but does not depend on that specification.

6.1 Use of seconds.

   If the answerer chooses to host the session, it MUST perform SDP M-line

   The SDP "m"-line takes the following steps:

   1.  Construct a new session URL . This MUST be a MSRP or MSRPS URL,
       MUST resolve to form:

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

   For non-RTP media sessions, The media field specifies the answerer, and MUST not be top level
   MIME media type for the same as session. For MSRP sessions, the
       session URL in media field
   MUST have the offer. value of "message". The URL SHOULD be temporary, SHOULD port field is normally not
   used, and MAY be
       hard set to guess, and MUST not duplicate URLs currently identifying any active sessions hosted value chosen by the answerer.

   2.  Listen for a connection from endpoint. A port
   field value of zero has the peer.

   3.  Construct an standard SDP answer as described meaning. Non-zero values
   MUST not be repeated in other MSRP m-lines in Section 6, mapping the
       new session URL to same SDP document.

   The proto field MUST designate the message session attribute, mechanism and inserting
   transport protocol, separated by a
       direction attribute with the value "/" character. For MSRP, left part
   of "passive".

   4.  Send the SDP offer using the normal processing for the signaling
       protocol.

   When the offerer receives the SDP answer, it must determine who will
   continue to host this value MUST be "msrp". For MSRP over TCP, the session. If right part of
   this field MUST take the answer contained a direction
   attribute value of "active", "tcp". For MSRP over other transport
   protocols, the offerer field value MUST continue be defined by the specification for
   that protocol binding.

   The format list list is ignored for MSRP. This is because MSRP
   formats are specified as host. If
   the offer contained "active" or "both" and the answer contains
   "passive", then MIME content types, which are not convenient
   to encode in the offerer MUST allow SDP format list syntax. Instead, the answerer to host allowed formats
   are negotiated using "a"-line attributes. For MSRP sessions, the
   session.

   If
   format list SHOULD contain a "*" character, and nothing else.

   The port field in the offerer chooses M-line is not used to continue as host, it MUST perform the
   following steps:

   1.  Release resources it acquired in expectation of hosting determine the
       session, if any.

   2.  Determine port to
   which to connect. Rather, the host address and actual port from is determined by the
   contents of the session URL (Section 7.1). However, a port value of
   zero has the
       answer, normal SDP meaning.

   The following example illustrates an m-line for a message session,
   where the procedures in section Section 7.1

   3.  Connect endpoint is willing to accept root payloads of message/
   cpim, plain text or HTML. The second two types could either be
   presented as the host address and port, using the root body, or could be contained within message/cpim
   bodies.

      m=message 9999 msrp/tcp *

6.2 The Direction Attribute

   Since MSRP uses connection oriented transport
       protocol from protocols, one goal of
   the M-line.

   4.  Construct a VISIT request, SDP negotiation is to determine which MUST contain participant initiates the following
       information:

       1.  A S-URL header field containing
   transport connection. The direction attribute advertises whether the session URL.

       2.  A TR-ID header field containing a unique transaction ID.

       3.  A size field containing size of
   offerer or answerer wishes to initiate the connection, wishes the message subsequent
   peer endpoint to initiate the
           start-line.

   5.  Send connection, or doesn't care.

   The endpoint that accepts the request connection is said to "host" the
   session, and wait for a response

   6.  If is known as the transaction succeeds, set hosting endpoint. The endpoint that
   initiates the actual expiration time connection is said to "visit" the session, and is known
   as the visiting endpoint.

   The direction attribute is included in an SDP a-line, with a value
   taking the following syntax:

               direction       = direction-label ":" role
               direction-label = "direction"
               role            = active / passive / both
               active          = "active" sp count
               passive         = "passive" sp count
               both            = "both" sp count [sp timeout]
               count	           = 1*DIGIT ; Connection count
               timeout         = 1*DIGIT ; timeout value in seconds

   The values for the Exp header role field in are as follows:

   passive: The endpoint wishes to host the response, and
       acknowledge session

   active: The endpoint wishes the answer via peer to host the signaling protocol. If session.

   both: The endpoint is willing to act as either the
       connection attempt host or the VISIT transaction fail, acknowledge the
       answer, then initiate the tear-down of the session using the
       signaling protocol.

7.4.2 Handling VISIT requests

   An MSRP endpoint that visitor. If
      "both" is hosting a session will receive a VISIT
   request from the visiting endpoint. When selected, it may contain an endpoint receives optional timeout value. This
      timeout specifies how much time the answerer should wait before
      giving up on a VISIT
   request, it MUST perform connection and attempting to take over as host
      device.  If the following procedures:

   1.  Check if state exists timeout value is not specified, it defaults to 30
      seconds.

   The SDP offer for a an MSRP session with MUST contain a URL that matches the
       S-URL direction attribute,
   which MAY take any of the VISIT request. defined values. If so, and if no visitor connection
       has been associated with the session, then return a 200 response,
       and save state designating the connection on which the request
       was received as the visitor leg offerer is capable
   of hosting the session.

   2.  If the session exists, and session, then it SHOULD select "both". The endpoint
   SHOULD NOT select "active" unless it cannot host the visitor connection has already
       been established, return a 506 response and do not change session
       state in any way.

   3.  If no matching session exists, return a 481 request, and do not
       change session state in under
   any way.

7.4.3 Sending Instant Messages on a Session

   Once a MSRP session has been established, either circumstances. The endpoint may send
   instant messages SHOULD NOT select "passive" unless it
   has no option but to its peer using host the SEND method. When an endpoint
   wishes session.

   The count is used to do so, it MUST construct determine if a SEND request according to the
   following process:

   1.  Insert the message payload new connection is required in
   future SDP exchanges for a given stream. For the body, and the media type in initial SDP
   exchange, the
       Content-Type header field. The media type count pamameter MUST match one of be set to zero. Endpoints sending
   a new offer related to an existing stream MUST increment this count
   from the
       types value in the format list negotiated in most recent successful exchange for the stream.

   The SDP exchange. If answer also MUST contain a "*"
       was present direction attribute, but its value
   choices are limited based on the value in the accept-types attribute, then offer. If the media type
       SHOULD match one of offer
   contained "active", then the explicitly listed entries, but MAY be any
       other arbitrary value.

   2.  Set answerer MUST either select "passive" or
   reject the TR-ID header field to a unique value.

   3.  Send offer. Likewise, if the request on offer contained  "passive", then
   the connection associated with answerer MUST select "active" or reject the session.

   4. offer. If a 2xx response code is received, the transaction was
       successful.

   5.  If a 5xx response code is received, offer
   contained "both", the transaction failed, answerer SHOULD select "active", but
       other transactions may still succeed in MAY select
   "passive" if it is unable to reach the future. host device, or if local
   policy requires it to act as host. The endpoint
       MAY attempt answerer MUST set the count
   parameter to send the message content again in a new request, same value as that is, with a new TR-ID value. If in the endpoint receives 5xx
       responses more than some threshold number of times offer.

6.3 The Accept Types Attribute

   MSRP can carry any MIME encoded payload. Endpoints specify MIME
   content types that they are willing to receive in a row, it
       SHOULD assume the session accept types
   "a"-line attribute. This attribute has failed, and initiate tear-down via the signaling protocol. The threshold value is a matter of local
       policy.

   6.  If a 415 response is received, this indicates following syntax:

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

   SDP offers for MSRP sessions MUST include an accept-types attribute.
   SDP answers MUST also include the attribute, which MUST contain
   either the recipient is
       unable same list as in the offer or unwilling to process a subset of that list.

   A "*" entry in the accept-types attribute indicates that the media type. The sender SHOULD
       NOT
   may attempt to send that particular messages with media type again in the
       context of this session.

   7.  If any other response code is received, the endpoint SHOULD
       assume the session has failed, and initiate tear-down.

      Normally transaction timeouts are treated the same as transactions
      that receive 5xx responses But, unlike transactions that fail
      explicitly, requests types that have not been timed out may in fact have
      been delivered to the peer endpoint, and even presented to the
      user. Attempting to resend such messages may result in the peer
      user seeing duplicate messages. Therefore a client implementation
      should take such action carefully, and should clearly indicate
   explicitly listed. If the
      situation receiver is able to process the user.

      Open Issue: Do we need to create a duplicate suppression
      mechanism? media type,
   it does so. If retries were sent with with the TR-ID, then the
      recipient could recognize a duplicate message if not, it occurs in the
      same session.

   When an endpoint receives will respond with a SEND request, it MUST perform the
   following steps.

   1.  Determine 415. Note that it understands the media type in the body, if all
   explicit entries SHOULD be considered preferred over any
       exists.

   2.  If it does, return a 200 response and render the message to the
       user. The method of rendering non-listed
   types. This feature is a matter needed as, otherwise, the list of local policy.

   3. 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 it does not understand compound types are
   used, the media type, return a 415 response.

7.4.4 Ending a Session

   When either endpoint types listed in an MSRP session wishes to end the session, it
   first signals its intent using the normal processing for accept-types attribute may be used both
   as the
   signaling protocol. For example, root payload, or may be wrapped in SIP, it would send a BYE request
   to the peer. After agreeing to end the session, listed container type.
   (Note that the host endpoint container type MUST release any resources acquired as part of also be listed in the session. accept-types
   attribute.)

6.4 MIME Wrappers

   The
   process for this differs depending on whether the session is hosted
   directly by MIME content-types in the host, accept-types attribute will often
   include container types; that is, types that contain other types. For
   example, "message/cpim" or by a relay.

   The host MUST destroy local state for the session. This involves
   completely removing the state entry for this session and invalidating
   session URL. If the host is using "multipart/mixed."  Occasionally an MSRP relay, it MUST send
   endpoint will need to specify a BIND
   containing an expires value of zero. This request MUST MIME body type that can only be sent on the
   host connection established by the original BIND request. This BIND
   request MUST include used
   if wrapped inside a listed container type.

   Endpoints MAY specify MIME types that are only allowed to be wrapped
   inside compound types using the session URL "accept-wrapped-types" attribute in
   an SDP a-line. This attribute has the S-URL header field.

      Since these host actions completely destroy the session state at
      the hosting device, the visitor is not required to take further
      action beyond cleaning up any local state. If following syntax:

               accept-wrapped-types = wrapped-types-label ":" format-list
               wrapped-types-label  = "accept-wrapped-types"
   	`

   The format-list element has the identical syntax as defined for some reason the
      host fails
   accept-types attribute. The semantics for this attribute are
   identical to destroy session state, those of the state will accept-types attribute, with the exception
   that the specified types may only be invalidated
      anyway used when the inactivity timer expires.

   When an endpoint chooses to close a session, it wrapped inside
   containers. Only types listed in accept-types may have SEND
   transactions outstanding. For example, it be used as the
   "root" type for the entire body. Since any type listed in
   accept-types may have send SEND requests
   to which it has not yet received be used both as a response, or it may have received
   SEND requests that to which it has root body, and wrapped in other
   bodies, format entries from the m-line SHOULD NOT be repeated in this
   attribute.

   This approach does not responded. Once allow for specifying distinct lists of
   acceptable wrapped types for different types of containers. If an
   endpoint
   has decided to close understands a MIME type in the connection, context of one wrapper, it SHOULD wait for such
   outstanding transactions is
   assumed to complete. It SHOULD NOT generate any new
   SEND transactions, and understand it MAY choose not to respond in the context of any other acceptable
   wrappers, subject to any new SEND
   requests constraints defined by the wrapper types
   themselves.

      The approach of specifying types that are received after it decides only allowed inside of
      containers separately from the primary payload types allows an
      endpoint to force the use of certain wrappers. For example, a CPIM
      gateway device may require all messages to close be wrapped inside
      message/cpim bodies, but may allow several content types inside
      the session. It
   SHOULD not respond wrapper. If the gateway were to any new messages that arrive after it signals specify the wrapped types in
      the accept-types attribute, its intent peer could choose to close use those
      types without the session.

   When wrapper.

6.5 URL Negotiations

   An MSRP session is identified by an endpoint MSRP URL, which is signaled of its peer's intent to close determined by
   the hosting endpoint, and negotiated in the SDP exchange. Any SDP
   offer or answer that creates a possibility that the sender will host
   the session,
   it SHOULD NOT initiate any more SEND requests. It SHOULD wait for any
   outstanding transactions that is, it initiated to complete, and it SHOULD
   attempt respond to any open SEND transactions received prior to being
   signaled.

   It is not possible to completely eliminate the chance contains a direction value of "passive" or
   "both",  MUST contain an MSRP URL in a session
   terminating with incomplete SEND transactions. When this occurs, attribute. This
   attribute has the following syntax:

   a=session:<MSRP_URL>

   where <MSRP_URL> is an
   endpoint SHOULD clearly inform MSRP or MSRPS URL as defined in Section 7.1.

   The visitor will use the user that session URL established by the messages mat not
   have been delivered.

7.4.5 Session Inactivity Timer

   State associated with host both to
   resolve the host address and port, and to identify the session when
   connecting. For MSRP sessions, either at the host endpoint, or
   a hosting or visiting relay, address field in the C-line is soft-state; that is, it expires over
   time not
   relevant, and MUST be ignored. The port field in the M-line MUST be
   ignored if no message activity occurs. Each such device maintains a pair
   of inactivity timer, each with non-zero. Zero values have the normal meaning for SDP.

   The following example shows an initial value of 12 minutes. One SDP offer with a session URL of
   these timers is
   "msrp://example.com:7394/2s93i"

           v=0
           o=someuser 2890844526 2890844527 IN IP4 alice.example.com
           s=
           c=IN IP4 alice.example.com
           m=message 9999 msrp/tcp *
           a=accept-types:text/plain
           a=direction:both 0
           a=session:msrp://example.com:7394/2s93i

   The session URL MUST be a temporary URL assigned just for each this
   particular session. It MUST NOT duplicate any URL in use for any
   other session hosted by the endpoint.

      All devices Further, since the peer
   endpoint will use the same, predetermined timer expiration value.
      While there might session URL to identify itself when connecting,
   it SHOULD be some utility hard to guess, and protected from eavesdroppers. This
   will be discussed in negotiating this timer on a
      per device basis, such negotiation would add more detail in Section 10.

6.6 Updated SDP Offers

   MSRP endpoints may sometimes need to send additional SDP exchanges
   for an existing session. For example, they may need to negotiate a great deal
   new connection because of
      complexity a TCP failure or some other reason. They
   may need to MSRP.  The choice of 12 minutes is somewhat
      arbitrary, but is intended send periodic exchanges with no change to balance refresh state
   in the bandwidth overhead
      against how quickly network, for example, SIP timers. They may need to change some
   other stream in a relay can shed stale sessions. Since host session without affecting the MSRP stream, or they
   may need to change an MSRP stream without affecting some other
   stream.

   Once MSRP endpoints will normally explicitly destroy sessions, stale
      sessions should only occur under failure conditions.

      Open Issue: In have completed an intitial negotiation, further
   exchanges do not change their roles as the 2 relay use case, active or passive party
   for that particular stream. This means that if the visitor does not
      explicitly remove state from the visiting relay. Rather, sends a
   new SDP offer, it MUST remain the
      visiting relay must infer that visitor, i.e. it MUST offer a session has been removed when
   direction of "active" and it MUST NOT include an MSRP URL. Likewise,
   if the host device closes the connection, or when the inactivity timer
      expires.

   When a hosting device or visiting relay returns a successful response
   to sends a VISIT request, new offer, it MUST initialize both timers. The device include a direction of
   "passive" and it MUST
   reset include a timer anytime the associated endpoint sends URL. Updated offers MUST NOT include
   a SEND request. direction of "both."

   If either timer expires without being reset, offering party wishes to establish a new connection as a result of
   the device updated exchange,  it MUST
   invalidate the session, using normal procedures depending on increment the
   device's role count parameter in the session.

   Each endpoint MUST keep a similar timer, which it initializes when
   the session is created
   direction attribute from its perspective. For that of the host endpoint,
   this is when it receives a successful response to a BIND request. For
   a visiting endpoint, this is when it sees a most recent successful response to a
   VISIT request. Each endpoint resets its timer whenever it sends a
   SEND request. exchange.
   If an endpoint inactivity timer approaches expiration,
   and the passive endpoint wishes to continue participating in the session, the visitor to re-connect, it the
   included URL MUST send a SEND request. be different than the URL from previous offers.
   This request new URL MAY be sent without a body if
   there is no user data completely different from the original and MAY
   even resolve to send. Endpoints a different location. If the active party sends a new
   offer with an incremented count parameter, the passive party MUST select
   supply a new URL, or reject the offer. If either party sends a new
   offer with the timer same count value
   so that there is sufficient time for as the SEND request to traverse to previous exchange, the opposite endpoint. session
   URI MUST NOT change.

   If this negotiation results in a new session URL, the endpoint waits to active party
   MUST close the last moment,
   there is existing connection, open a new connection, and send a danger
   VISIT request as described below.

   If either party wish to send an SDP document that changes nothing at
   all, then it will not be received by all relevant
   devices MUST have the same o-line version as in time the previous
   exchange.

6.7 Example SDP Exchange

   Endpoint A wishes to invite Endpoint B to prevent session destruction.

      Open Issue: There has been list discussion suggesting we should
      have a separate KEEPALIVE method for this purpose, rather than
      using SEND requests.

7.4.6 Managing Session State and Connections

   A MSRP session is represented by state at session. A offers
   the host device. As mention
   previously, session state is identified by an MSRP URL. An active following session also has two associated network connections. The connection
   between the hosting device and description containing the host endpoint is known as following lines:

     v=0
     o=usera 2890844526 2890844527 IN IP4 alice.example.com
     s=
     c=IN IP4 alice.example.com
     t=0 0
     m=message 9999 msrp/tcp *
     a=accept-types: message/cpim text/plain text/html
     a=direction:both 0
     a=session:msrp://alice.example.com:7394/2s93i9

   Endpoint B chooses to participate in the host
   connection. The role of visitor, opens a TCP
   connection with the visiting endpoint is to alice.example.com:7394, and successfully performs a
   VISIT transaction passing the visiting
   connection.  Note URL of msrp://alice.example.com:7394/
   2s93i9. B indicates that when the session state is hosted directly it has accomplished this by answering with:

     v=0
     o=userb 2890844530 2890844532 IN IP4 bob.example.com
     s=
     c=IN IP4 dontlookhere
     t=0 0
     m=message 9999 msrp/tcp *
     a=accept-types:message/cpim text/plain
     a=direction:active 0

   A may now send IMs to B by
   an endpoint, executing SEND transactions on the host connection may not involve a physical network
   connection; rather it is a logical same
   connection on which B sent the device maintains
   with itself.

   When session state VISIT request.

7. The Message Session Relay Protocol

   The Message Session Relay Protocol (MSRP) is destroyed a text based, message
   oriented protocol for any reason, the hosting device
   SHOULD drop transfer of instant messages in the connection(s).

   If context
   of a connection fails for any reason, session. MSRP uses the session hosting device UTF8 character set.

   MSRP messages MUST
   invalidate the session state. be sent over a reliable, congestion-controlled,
   connection-oriented transport protocol. This is true regardless of whether document specifies the
   dropped connection is
   use of MSRP over TCP. Other documents may specify bindings for other
   such protocols.

7.1 MSRP URLs

   MSRP sessions are identified by MSRP URLs. An MSRP URL follows a
   subset of the host or visiting connection. Once URL syntax in Appendix A of RFC2396 [4], with a
   connection is dropped, scheme
   of "msrp":

      msrp_url = "msrp" ":" "//" [userinfo] hostport ["/' resource]
      resource = 1*unreserved

   The constructions for "userinfo", "hostport", and "unreserved" are
   detailed in RFC2396 [4].

   An MSRP URL server part identifies the associated session state MUST NOT be
   reused. hosting device of an MSRP
   session. If the endpoints wish to continue to communicate after server part contains a
   connection failure, they must initiate numeric IP address, it MUST
   also contain a new session. An endpoint
   detecting port. The resource part identifies a connection failure SHOULD attempt to tear down the particular
   session using the rules at that host device. The absence of the signaling protocol.

      It would be nice resource part
   indicates a reference to allow sessions an MSRP host device, but does not
   specifically refer to be recovered after a
      connection failure, perhaps by allowing particular session resource.

   MSRP has an  IANA registered recommended port defined in Section 9.1.
   This value is not a default, as the opposite endpoint to
      reconnect, and send URL process described herein will
   always explicitly resolve a new VISIT or BIND request. port number. However, this
      approach creates a race condition between the time URLs SHOULD be
   configured so that the
      hosting device notices the failed connection, and 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 time session is valid.
   Note that this is not the endpoint tries to recover same thing as identifying the session. session
   itself. If the endpoint
      attempts to reconnect prior a userinfo component exists, MUST be constructed only from
   "unreserved" characters, to the hosting device noticing the
      failure, the hosting device will interpret the recovery attempt as avoid a conflict. need for escape processing.
   Escaping MUST NOT be used in an MSRP URL. Furthermore, a userinfo
   part MUST NOT contain password information.

   The only way around this would following is an example of a typical MSRP URL:

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

7.1.1 MSRP URL Comparison

   MSRP URL comparisons MUST be performed according to force the hosting
      device following
   rules:

   1.  The host part is compared as case insensitive.

   2.  If the port exists explicitly in either URL, then it must match
       exactly. An URL with an explicit port is never equivalent to do a liveness check on the original connection, which
      would create
       another with no port specified.

   3.  The resource part is compared as case insensitive. A URL without
       a lot of complexity and overhead that do not seem resource part is never equivalent to
      be worth the trouble.

7.5 MSRP Relays

   MSRP supports the use of message relays. This specification describes
   the use of one or two relays. While more than two relays that includes a
       resource part.

   4.  Userinfo parts are not
   forbidden by MSRP, a solution considered for an arbitary number of relays URL comparison.

   Path normalization is
   beyond not relevant for MSRP URLs. Escape
   normalization is not required, since the scope of this document.

7.5.1 Establishing Session State at a Relay

   An endpoint that wishes relevant parts are limited
   to host a MSRP session MAY do so by
   initiating session state at a unreserved characters.

7.1.2 Resolving MSRP relay, rather than hosting
   directly. Host Device

   An endpoint may wish to do this because network topology or
   local policy prevents a peer from connecting directly to MSRP host device is identified by the
   endpoint. The use server part of an MSRP URL.

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

   If the default case, that is, server part contains a hosting endpoint that is not prevented from doing so by topology or
   policy SHOULD host the session directly. In order to use a relay, an
   MSRP endpoint MUST have knowledge of that relay's existence name and
   location.

   We previously mentioned how an endpoint wishing to host a MSRP
   session constructs port, the session URL. When using connecting
   device MUST determine a relay, host address by doing an A or AAAA DNS query,
   and use the endpoint
   delegates that responsibility to port as listed.

   If the relay.

   To establish session state at server part contains a relay, host name but no port, the endpoint connecting
   device MUST perform the following steps:

   1.  Open a network connection to the relay at the relays address and
       port. Normally, this information will be resolved from  Construct an MSRP
       URL representing the relay, although SRV [6] query  string by prefixing the relay MAY be configured host name
       with an explicit address the service field "_msrp" and port, rather than a URL. the protocol field ("_tcp" for
       TCP). For example, "_msrp._tcp.host.example.com".

   2.  Construct a BIND request with  Perform a S-URL that refers to the relay. DNS SRV query using this query string.

   3.  Set the Exp header field to  Select a desired value.

   4.  Send resulting record according to the BIND request on rules in RFC2782 [6].
       Determine the connection.

   5.  Respond to any authentication request port from the relay.

   6. chosen record.

   4.  If the response has necessary, determine a 2xx status code, use the URL in the S-URL
       header field as the session URL. The endpoint uses this URL in
       exactly the same manner as it had constructed it itself.
       Additionally, accept the expires value in the response as
       pre-visit expiration time. host device address by performing an A MSRP relay listens for connections at all times. When it receives a
   BIND request, it SHOULD authenticate the request, either using
   digest-authentication, TLS authentication,
       or some other
   authentication mechanism. If authentication succeeds, the relay
   performs AAAA query on the following steps:

   1.  Verify host name field in the client is authorized to BIND to this relay. If not,
       return a 403 response and make no state change.

   2. selected SRV result
       record. If multiple A or AAAA records are returned, the client is authorized, construct a session MSRP URL. The
       URL MUST resolve to the relay. It first
       entry SHOULD be temporary, and hard
       to guess. It MUST not duplicate chosen for the initial connection attempt. This
       allows any URL used ordering created in any active
       sessions hosted by the relay. DNS to be preserved.

   5.  If the relay wishes connection attempt fails, the visiting
       endpoint device SHOULD attempt to
       connect over a port other than the MSRP relay
       well-know port, it MUST explicitly add the port number to visitor
       URL.

   3.  Establish the pre-visit expiration time for the session according
       to Section 7.4.5.

   4.  Create state for addresses returned in any additional A or AAAA
       records, in the session. The relay MUST associate order the
       connection on which records were presented. If all of these
       fail, the BIND request arrived as device SHOULD attempt to use any additional SRV records
       that may have been returned, following the host
       connection normal rules for SRV
       record selection.

   In most cases, the session.

   5.  Return a 200 response, with transport protocol will be determined separately
   from the session resolution process. For example, if the MSRP URL was
   communicated in an SDP offer or answer, the S-URL header
       field, and the pre-visit session expiration time in SDP M-line will contain
   the Exp
       header field. transport protocol. When an MSRP relay receives URL is communicated outside of
   SDP, the protocol SHOULD also be communicated. If a VISIT request, device needs to
   resolve an MSRP URL and does not know the protocol, it SHOULD assume
   TCP.

7.1.3 The msrps URL Scheme

   The "msrps" URL Scheme indicates that each hop MUST perform the
   following steps:

   1.  Check the S-URL header field value be secured with
   TLS. Otherwise, it is used identically as an MSRP URL, except that a
   MSRPS URL MUST NOT be considered equivalent to see it matches the URL for an existing session state entry.

   2.  If not, return a 481 response MSRP URL. The MSRPS
   scheme is further discussed in Section 10.

7.2 MSRP messages

   MSRP messages are either requests or responses. Requests and make no state changes

   3.  If it matches, but
   responses are distinguished from one another connection has already been associated
       with by the session URL, return first line. The
   first line of a 506 response and make no state
       changes. If Request takes the session has been previously associated with this
       connection, treat form of the request as a refresh.

   4.  If it matches, and no visiting connection has been previously
       associated with request-start entry
   below. Likewise, the session, then first line of a response takes the VISIT succeeds. form of
   response-start. The relay
       assigns the connection on which it received the VISIT request syntax for an MSRP message is as follows:

       msrp-message   = request-start/response-start *(header CRLF)
                                  [CRLF body]
       request-start  = "MSRP" SP length SP  Method CRLF
       response-start = "MSRP" SP length SP Status-Code SP
                                Reason CRLF

       length       = 1*DIGIT  ; the visiting connection for length of the session, and returns a message,
                               ;  exclusive of the start line.
       Method       = SEND / VISIT / other-method
       other-method = token
       header       = Transaction-ID / Session-URL / Content-Types
       Status-Code  = 200
       response.

7.5.2 Removing Session State from    ;Success
                    / 400    ;Bad Request
                    / 403    ;Forbidden
                    / 415    ;Unsupported Content Type
                    / 426    ;Upgrade Required
                    / 481    ;No session
                    / 506    ;duplicate session

       Reason              = token ; Human readable text describing status
       Transaction-ID      = "Tr-ID" ":" token
       Content-Type        = "Content-Type" ":" quoted-string
       Session-URL         = "S-URL" ":" msrp_url

   All requests and responses MUST contain at least a relay TR-ID header
   field. Messages MAY contain other fields, depending on the method or
   response code.

7.3 MSRP Transactions

   An MSRP relay SHOULD remove state for a session when any transaction consists of the
   following conditions occur:

   o  The session inactivity timer expires.

   o  The pre-visit timer expires before a VISIT request has occurred.

   o  The host sends a BIND refresh exactly one request matching with an expiration
      value of zero.

   o  Either the host or visitor network connection fails for any
      reason.

7.5.3 Sending IMs across an MSRP relay

   Once a session is established at a relay, the host and visitor may
   exchange IMs by sending SEND requests. Under normal circumstances,
   the relay does not respond to SEND requests in any way. Rather, the
   relay MUST  forward the request to the peer connection unchanged.
   Likewise, if the relay receives a one response.
   A response matches a transaction if it MUST forward the
   request unchanged on share the peer connection.

   If a SEND request same TR-ID value,
   and arrives on a the same connection that is not associated with
   a session, on which the relay transaction was sent.

   Endpoints MUST return a 481 response.

7.5.4 Relay Pairs

   In rare circumstances, two relays may be required in a session. For
   example, two endpoints may exist select TR-ID header field values in separate administrative domains,
   where each domain's policy insist that all sessions must cross requests so that
   domain's relay. A relay operating on behalf of
   they are not repeated by the visiting same endpoint
   is known as a visiting relay. An MSRP relay MAY be capable in scope of acting
   as a visiting relay.

      This document does not describe a mechanism for an endpoint to
      discover that it needs to use a visiting relay. We assume that an the given
   session. TR-ID values SHOULD be globally unique. The TR-ID space of
   each endpoint is globally configured to use or not use such a relay,
      and does not make this decision on a session-by-session basis.
      This, independent of course, does that of its peer. Endpoints MUST NOT
   infer any semantics from the TR-ID header field beyond what is stated
   above. In particular, TR-ID values are not preclude using some other mechanism required to
      make such follow any
   sequence.

   MSRP Transactions complete when a decision.

   In response is received, or after a two relay scenario,
   timeout interval expires with no response. Endpoints MUST treat such
   timeouts in exactly the visitor connects to same way they would treat a relay operating on
   its behalf, rather than connecting directly to the hosting device. 500 response. The visitor sends a VISIT request
   timeout interval SHOULD be 30 seconds, but other values may be
   established as it would if it had connected
   directly to the hosting device. The visiting relay then connects to
   the hosting device and performs a VISIT request on behalf matter of the
   visitor.

   When a relay that local policy.

7.4 MSRP Sessions

   AN MSRP session is capable of acting as a visiting relay receives context in which a
   VISIT request, it MUST check to see if the S-URL series of the request
   matches instant messages
   are exchanged, using SEND requests. A session has two endpoints (a
   host and a domain that the relay hosts. If the URL matches, then the
   visitor visitor). A session is not requesting the relay act as identified by an MSRP URL.

7.4.1 Initiating an MSRP session

   When an endpoint wishes to engage a visiting relay, and peer endpoint in a message
   session, it
   SHOULD operate normally. If the URL does not match, then the relay
   SHOULD perform the following steps:

   1.  The relay SHOULD authenticate invites the VISIT request, peer to communicate using digest
       authentication an SDP offer,
   carried over SIP or some other mechanism.

   2.  Determine that protocol supporting the SDP offer/
   answer model. For the purpose of this document, we will refer to the visiting
   endpoint is authorized choosing to use this
       device initiate communication as a visiting relay. If not, return a 403 response the offerer, and
       drop the connection.

   3.  Attempt to open a connection
   peer being invited as the answerer.

   The offerer SHOULD volunteer to act as the hosting device, determining
       the address endpoint if
   allowed by policy and port from network topology. The peer that is not the S-URL exactly as if it were a
       visiting endpoint connecting directly. If this connection host
   is
       successful, continue with designated as the remaining steps. Otherwise, return
       a 500 response.

   4.  Create local state to associate visitor. The offerer MAY request the connection answerer to the
   act as host device
       with if it is prevented from accepting connections by network
   topology or policy.

   If the connection offerer wishes to host the visiting device.

   5.  Relay session, it MUST perform the VISIT request unchanged
   following steps:

   1.  Construct a session MSRP URL . This URL MUST resolve to the hosting device.

   6.  Relay
       location that the response offerer wishes to host the VISIT request unchanged connection. The URL
       SHOULD be temporary, SHOULD be hard to guess, and MUST not
       duplicate the visiting
       endpoint.

   7.  Relay all subsequent requests arriving on one URL  of any other session currently hosted by the associated
       connections to the peer connection.

   If either associated connection fails
       offerer.

   2.  Listen for any reason, a connection from the peer.

   3.  Construct an SDP offer as described in Section 6, including the
       list of allowed IM payload formats in the accept-types attribute.
       The offerer maps the visiting
   relay MUST invalidate session URL to the session state, and MUST drop attribute, as
       described in Section 6.5.

   4.  Insert a direction attribute. This value SHOULD be "both",
       indicating that the peer
   connection.

7.5.5 Relay Shutdown

   Relay administrators offerer will occasionally need to take MSRP relays out
   of service. A relay implementation SHOULD allow a graceful shutdown
   that minimizes the occurrence of "lost", or timed out, messages. When
   a relay effects a graceful shutdown, it SHOULD refuse all new
   connection attempts, and refuse all MSRP requests, returning 481
   responses. In order answerer to allow any open transactions a high chance of
   completion, override
       the relay offerer's decision to host. If "both" is selected, the
       offerer SHOULD wait at least one transaction leave the timeout
   period (normally 30 seconds) between at the time it starts refusing
   requests and default value (by leaving
       out the time it closes existing connections and shuts down.

      Open Issue: We have discussed that an endpoint implementation may
      attempt to establish a new session (perhaps using value entirely. However, the offerer MAY select a
       different
      relay) with its peer. Do we wish to specify anything at all about
      such behavior?

7.6 Digest Authentication

   MSRP relays may use timeout if circumstances warrant it. The direction
       value MAY be "passive" if the digest authentication scheme to authenticate
   users. MSRP digest authentication offerer is a simplified version of HTTP
   digest authentication [19], but prevented from allowing
       the answerer override this specification does not
   normatively depend on that document. MSRP digest authentication does
   not support choice. The direction attribute must
       also contain the concept of a protection domain, nor does it support
   integrity protection. Since a user of a relay is expected count parameter, which will be set to have
   credentials zero for that particular relay, it does not support
       an initial exchange.

   5.  Send the realm
   concept. Finally, since digest authentication is only expected SDP offer using the normal processing for the initial BIND or VISIT request, MSRP does not support HTTP digest
   optimizations such as MD5-sess and preemptive credential loading by signaling
       protocol.

   If the client.

   Typically, a hosting user that uses offerer chooses to force the answerer to host the session, it
   MUST perform the following steps instead:

   1.  Construct an SDP offer as described above, but with no session
       attribute.

   2.  Insert a relay will have direction attribute with a preexisting
   relationship value of "active", with that relay. This relationship SHOULD include
   authentication credentials. An MSRP relay SHOULD authenticate initial
   BIND requests.

   It is less likely that the visiting user will have an account at
       appropriate count parameter value.

   3.  Send the
   hosting relay, so offer using normal processing for the signaling
       protocol.

   When the answerer receives the SDP offer and chooses to participate
   in most cases the authentication of VISIT requests
   is not useful. However a relay MAY authenticate initial VISIT
   requests. A visiting relay SHOULD authenticate initial VISIT
   requests, as session, it is much more likely must choose whether to share credentials with act as the
   visiting user.

      There has been some discussion host or the
   visitor. A direction attribute value of "both" in the offer indicates
   that a hosting relay SHOULD also
      authenticate VISIT requests. However, it the offerer prefers to host, but will be  common for
      visiting users allow the answerer to have no preexisting relationship with
   host.  In this case the host
      relay. Using authentication here would require answerer SHOULD act as the host endpoint visitor, but MAY
   choose to send temporary credentials host. A value of "passive" means the offerer insists upon
   hosting, in which case the SDP exchange, perhaps answerer MUST act as part
      of visitor or decline
   the session URL. However, these temporary credentials would
      necessarily be transferred via offer.

   If the same channels answerer chooses to participate as a visitor, it MUST perform
   the session
      URL itself. If following steps:

   1.  Determine the credentials are sufficiently protected in
      transfer, then so is host address and port from the session URL. Further, since URL,
       following the session
      URL is intended for a one time use, and is expected to be hard procedures in section Section 7.1

   2.  Connect to
      guess, that URL itself should be sufficient for this purpose. Any
      situation where this is not adequate can be covered by the use of the MSRPS scheme.

   MSRP relays MUST NOT request authentication for any method other than
   BIND host address and VISIT.

   If a relay wishes to authenticate a request port, using digest
   authentication, it MAY challenge the request by responding with transport
       protocol from the M-line.

   3.  Construct a
   401 response, VISIT request, which MUST include a SChal contain the following
       information:

       1.  An S-URL header field.

   If an endpoint wishes to respond to a digest authentication challenge
   received in a 401 response, it MAY do so by sending a new VISIT or
   BIND request, identical to field containing the previous request, but with a CAuth session URL.

       2.  A TR-ID header field containing a unique transaction ID.

       3.  A size field containing size of the message subsequent to the
           start-line.

   4.  Send the request and wait for a response

   5.  If the transaction succeeds, send a SDP answer via the signaling
       protocol, according to the challenge.

7.6.1 The SHA1 Algorithm following rules:

       1.  The only digest authentication algorithm defined in this
   specification is SHA1. [9] Other algorithms can be added as
   extensions. SHA1 C-line is  copied unmodified from the default algorithm if no algorithm directive offer.

       2.  The M-Line contains a dummy port value, the protocol field
           from the original offer, and the accept-types attribute
           contains the SEND payload media types that the answerer is present
           willing to accept. The accept-types attribute in the challenge. All MSRP devices answer
           MUST support SHA1.

      Open Issue: Do we need to specify how to offer more than one
      algorithm in a challenge? Do we need multiple algorithms possible
      for a particular challenge, or should we follow be either the HTTP digest
      approach of multiple challenges. It has been suggested same as that SHA1 of the offer, or it MUST always be offered, to ensure that a
           subset.

       3.  A direction attribute containing the client value "active", and server will
      have at least one common algorithm.

   The SHA1 digest is defined as follows:

   Let KD(secret, data) denote the string obtained by  performing the
   digest algorithm to
           count value copied from the data "data" with offer.

   6.  If the secret "secret". Let
   H(data) denote transaction fails, the string obtained answerer MAY choose to act as host,
       if allowed by performing the checksum
   algorithm on direction attribute of the data "data". answer. If the
       answerer is unable or unwilling to host, then it should return an
       error response as appropriate for the signaling protocol.

   Some TCP connection failure conditions may ordinarily take some time
   to notice. For example, if the "SHA1" algorithm, H(data) = SHA1(data), and KD(secret,data) =
   H(concat(secret, ":", data)

   Section 7.2 describes offerer is unable to open a TCP
   connection to the syntax host device, this connection attempt may take a
   fairly large number of seconds to timeout. This length of time will
   not be acceptable for many call flow scenarios. Therefore, the
   devices SHOULD limit the time they wait for the request-digest value in TCP connection to a
   CAuth header as 40 digits
   shorter timeout value, which will default to 30 seconds. However, the
   offerer MAY supply a different time in lower case hexadecimal notation. The
   actual structure the timeout parameter of the field is defined as follows. Note
   "both" direction value. If the offerer supplies a value, the answerer
   SHOULD use that
   unq(quoted-string) denotes the value of the string with for the quotes
   removed.

       request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > <">
       A1             = unq(username-value) ":" shared-secret ; "unq" denotes removal TCP connection timeout, interpreted as
   an integer number of quotes
       A2             = concat(Method,TR-ID,S-URI)

   When seconds.

   If the relay receives a CAuth header, answerer chooses to host the session, it SHOULD check its validity
   by looking up MUST perform the shared secret,
   following steps:

   1.  Construct a new session URL . This MUST be a MSRP or H(A1), performing MSRPS URL,
       MUST resolve to the answerer, and MUST not be the same digest
   operation as performed by the client, and comparing
       session URL in the results offer.  The URL SHOULD be temporary, SHOULD be
       hard to
   the request-digest value.

7.7 Method Descriptions

   This section summarizes the purpose of each MSRP method. All MSRP
   messages guess, and MUST contain not duplicate URLs currently identifying
       any active sessions hosted by the TR-ID header fields. All messages MUST
   contain answerer.

   2.  Listen for a length field connection from the peer.

   3.  Construct an SDP answer as described in Section 6, mapping the start line that indicates
       new session URL to the overall
   length session attribute, insert a direction
       attribute with the value of "passive", and the request, including any body, but not including count value copied
       from the
   start line itself. Additional requirements exist depending on offer.

   4.  Send the
   individual method. Except where otherwise noted, all requests are hop
   by hop.

7.7.1 BIND

   The BIND method is used by a host endpoint SDP offer using the normal processing for the signaling
       protocol.

   When the offerer receives the SDP answer, it must determine who will
   continue to establish or refresh
   session state at a hosting relay. BIND requests SHOULD be
   authenticated. BIND requests MUST contain host the S-URL and  Exp header
   fields and MAY contain session. If the CAuth header fields.

   A successful response to answer contained a BIND request direction
   attribute value of "active", the offerer MUST contain continue as host. If
   the S-URL offer contained "active" or "both" and
   Exp header fields.

7.7.2 SEND

   The SEND method is used by both the host and visitor endpoints to
   send instant messages to its peer endpoint. SEND requests SHOULD
   contain a MIME body part. The body answer contains
   "passive", then the offerer MUST be of a media type included
   in allow the format list negotiated in answerer to host the SDP exchange.
   session.

   If a body is
   present, the request offerer chooses not to continue as host, it MUST contain a Content-Type header field
   identifying the media type of perform the body.

   Unlike other methods, SEND requests are end to end
   following steps:

   1.  Release resources it acquired in nature. This
   means expectation of hosting the request is consumed only by
       session, if any.

   2.  Determine the opposite endpoint. Under
   normal conditions, any intervening relays merely forward host address and port from the request
   on towards session URL of the peer endpoint.

7.7.3 VISIT

   The visiting endpoint uses
       answer, following the VISIT method procedures in section Section 7.1

   3.  Connect to associate a network
   connection with the session state at host address and port, using the hosting device, which could
   be either transport
       protocol from the host endpoint or M-line.

   4.  Construct a relay operating on behalf of the
   host endpoint. The request VISIT request, which MUST contain a the following
       information:

       1.  A S-URL header matching field containing the session URL.

      There is normally no authentication operation for

       2.  A TR-ID header field containing a unique transaction ID.

       3.  A size field containing size of the message subsequent to the VISIT
      request. This is because
           start-line.

   5.  Send the session URL acts as a shared secret
      between host request and wait for a response

   6.  If either the visitor. This puts certain requirements on connection attempt or the handling VISIT transaction fail,
       acknowledge the answer, then initiate the tear-down of the
       session URLs using the signaling protocol.

7.4.2 Handling VISIT requests

   An MSRP endpoint that are discussed in Section 10.
      However, if a visiting relay is used, it SHOULD authenticate hosting a session will receive a VISIT
      requests.

7.8 Response Code Descriptions

   This section summarizes
   request from the various response codes. Except where
   noted, all responses visiting endpoint. When an endpoint receives a VISIT
   request, it MUST contain perform the following procedures:

   1.  Check if state exists for a TR-ID header field matching session with a URL that matches the
   TR-ID header field
       S-URL of the associated VISIT request. Responses are never
   consumed by relays.

7.8.1 200

   The 200 response code indicates a successful transaction.

7.8.2 400

   A 400 response indicates a request was unintelligible.

7.8.3 401

   A 401 response indicates authentication is required. 401 responses
   MUST NOT be used in response to any method other than BIND If so, and VISIT.
   A 401 response MUST contain a SChal header field.

7.8.4 403

   A 403 response indicates if no visitor connection
       has been associated with the user is not authorized to perform session, then return a 200 response,
       and save state designating the
   action.

7.8.5 415

   A 415 response indicates connection on which the SEND request contained a MIME
   content-type that is not understood by
       was received as the receiver.

7.8.6 426

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

7.8.7 481

   A 481 session.

   2.  If the session exists, and the visitor connection has already
       been established, return a 506 response indicates that and do not change session
       state in any way.

   3.  If no matching session exists for the connection.

7.8.8 500

   A 500 response indicates that exists, return a relay was unable to deliver 481 request, and do not
       change session state in any way.

7.4.3 Sending Instant Messages on a request Session

   Once a MSRP session has been established, either endpoint may send
   instant messages to its peer using the target.

7.8.9 506

   A 506 response indicates that SEND method. When an endpoint
   wishes to do so, it MUST construct a VISIT SEND request occurred according to the
   following process:

   1.  Insert the message payload in which the
   S-URL indicates a session that is already associated with another
   connection. A 506 response MUST NOT be returned body, and the media type in response to any
   method other than VISIT.

7.9 Header Field Descriptions

   This section summarizes the various header fields. MSRP
       Content-Type header fields
   are single valued; that is, they field. The media type MUST NOT occur more than once match one of the
       types in the format list negotiated in the SDP exchange. If a
   particular request or response.

7.9.1 TR-ID

   The "*"
       was present in the accept-types attribute, then the media type
       SHOULD match one of the explicitly listed entries, but MAY be any
       other arbitrary value.

   2.  Set the TR-ID header field contains a transaction identifier used to map a response to the corresponding request. A TR-ID value MUST be unique
   among all values used by a given endpoint inside a given session.
   MSRP elements MUST NOT assume any additional semantics for TR-ID.

7.9.2 Exp

   The Exp header field specifies when value.

   3.  Send the state request on the connection associated with the session.

   4.  If a BIND
   request will expire, if no successful VISIT request has been
   received. The value 2xx response code is specified as an integer number of seconds from
   the time received, the request transaction was
       successful.

   5.  If a 415 response is received. BIND requests MUST contain received, this
   header field. Furthermore, successful responses to BIND requests MUST
   also contain the Exp header.

   The maximum value for indicates the Exp header field recipient is (2**32)-1 seconds.

   Exp has no meaning if it occurs in MSRP messages other than BIND
   requests, and responses
       unable or unwilling to those requests. MSRP compliant devices process the media type. The sender SHOULD
       NOT use Exp in other requests or responses, unless attempt to send that usage
   is defined particular media type again in an extension to the
       context of this specification.

7.9.3 CAuth

   The CAuth header field session.

   6.  If any other response code is used received, or if the transaction
       times out, the endpoint SHOULD assume the session has failed, and
       initiate tear-down, either ending the session, or by sending an
       updated SDP offer proposing a host new connection. If a new connection
       is established, the endpoint MAY choose to offer digest
   authentication credentials resend the content on
       the new connection.

      Open Issue: Do we need to create a duplicate mechanism to suppress
      duplicate messages when a relay, new connection is established in response this
      fashion? mechanism? List consensus seems to indicate we do. We may
      need to specify that the tr-id space spans a digest
   authentication challenge. CAuth SHOULD NOT be present sequence of
      connections if they are associated with same stream, and of
      course, specify what it means for a stream to span connections.

   When an endpoint receives a SEND request, it MUST perform the
   following steps.

   1.  Determine that it understands the media type in a request of the body, if any method other than BIND
       exists.

   2.  If it does, return a 200 response and VISIT.

   The syntax of render the CAuth credentials is described in Section 7.2 message to the
       user. The meaning method of each value rendering is as follows:

   username: The user's account name.

   nonce: The nonce value copied from the challenge.

   response: A 32 hex digit string that proves user knowledge a matter of local policy. If the
      shared secret.

   algorithm: The algorithm value copied from the challenge.

   auth-param: Additional parameters for
       message contained no body at all, the sake of extensibility.

7.9.4 SChal

   The SChal header field is used by a relay to carry endpoint should quietly
       ingore it.

   3.  If it does not understand the challenge in a
   digest authentication attempt. Exactly one SChal header field MUST
   exist in media type, return a 401 415 response.
       The SChal header endpoint MUST NOT be used in any
   message except for return a 401 response. The syntax 415 response for the SChal challenge
   is described any media type
       for which it indicated support in Section 7.2

   The meaning of each value is as follows:

   digest scheme: A token to identify the particular authentication
      scheme. Since SDP exchange.

7.4.4 Ending a Session

   When either endpoint in an MSRP only supports digest, this value MUST be set session wishes to
      "Digest"

   nonce: A server-specified string, which end the relay SHOULD uniquely
      generate each time session, it sends a 401 response. This string SHOULD
      take the form of base64 or hexadecimal data, to avoid the presence
      of a double-quote character, which is not allowed.

   algorithm: A token indicating the algorithms to be used to generate
   first signals its intent using the digest and checksum. This directive exists normal processing for the sake of
      extensibility; the only value defined by this document is "SHA1".
      Absence of this directive indicates a value of "SHA1".

7.9.5 Content-Type

   The Content-Type header field is used
   signaling protocol. For example, in SIP, it would send a BYE request
   to indicate the MIME media type
   of the body. Content-Type MUST be present if a body is present.

      Open Issue: We may need peer. After agreeing to clean up our MIME usage. This includes
      better defining end the Content-Type usage possibly moving
      content-type into session, the body, indicating MIME version, etc.

7.9.6 S-URL

   The S-URL header field is used to identify host endpoint
   MUST release any resources acquired as part of the session.

   The S-URI
   header field host MUST be present in a BIND request, a successful response
   to a BIND request, or a VISIT request.

8. Examples

   This section shows some example message flows destroy local state for various common
   scenarios. The examples assume SIP is used to transport the SDP
   exchange. Details of session. This involves
   completely removing the SIP messages and SIP proxy infrastructure
   are omitted state entry for this session and invalidating
   session URL.

      Since these host actions completely destroy the sake of brevity. In the examples, assume session state at
      the
   offerer is sip:alice@atlanta.com and hosting device, the answerer visitor is
   sip:bob@biloxi.com. In not required to take further
      action beyond cleaning up any given MSRP message, local state.

   When an "xx" in endpoint chooses to close a session, it may have SEND
   transactions outstanding. For example, it may have send SEND requests
   to which it has not yet received a response, or it may have received
   SEND requests that to which it has not responded. Once an endpoint
   has decided to close the length
   field indicates connection, it SHOULD wait for such
   outstanding transactions to complete. It SHOULD NOT generate any new
   SEND transactions, and it MAY choose not to respond to any new SEND
   requests that are received after it decides to close the actual length of session. It
   SHOULD not respond to any new messages that arrive after it signals
   its intent to close the rest session.

   When an endpoint is signaled of the message.

8.1 No Relay

   In this scenario, the session goes directly between endpoints with no
   MSRP relays involved.

           Alice                     Bob
             |                        |
             |                        |
             |(1) (SIP) INVITE        |
             |----------------------->|
             |(2) (MSRP) VISIT        |
             |<-----------------------|
             |(3) (MSRP) 200 OK       |
             |----------------------->|
             |(4) (SIP) 200 OK        |
             |<-----------------------|
             |(5) (SIP) ACK           |
             |----------------------->|
             |(6) (MSRP) SEND         |
             |----------------------->|
             |(7) (MSRP) 200 OK       |
             |<-----------------------|
             |(8) (MSRP) SEND         |
             |<-----------------------|
             |(9) (MSRP) 200 OK       |
             |----------------------->|
             |(10) (SIP) BYE          |
             |----------------------->|
             |(11) (SIP) 200 OK       |
             |<-----------------------|
             |                        |
             |                        |

   1.   Alice constructs its peer's intent to close a session URL of msrp://
        alicepc.atlanta.com:7777/iau39 and listens session,
   it SHOULD NOT initiate any more SEND requests. It SHOULD wait for a connection on
        TCP port 7777.

        Alice->Bob (SIP): INVITE sip:bob@biloxi.com

        c=IN IP4 fillername
        m=message 9999 msrp/tcp *
        a=accept-types:text/plain
        a=direction:both
        a=session:msrp://alicepc.atlanta.com:7777/iau39

   2.   Bob opens a TCP connection any
   outstanding transactions that it initiated to alicepc.atlanta.com:7777:

        Bob->Alice (MSRP):

        MSRP xx VISIT
        S-URL:msrp://alicepc.atlanta.com:7777/iau39
        Tr-ID: sie09s

   3.   Alice->Bob (MSRP):

        MSRP xx 200 OK
        Tr-ID: sie09s
        Exp:300

   4.   Bob->Alice (SIP): 200 OK

        c=IN IP4 ignorefield
        m=message 9999 msrp/tcp *
        a=accept-types:text/plain
        a=direction:active

   5.   Alice->Bob (SIP): ACK
   6.   Alice->Bob (MSRP):

        MSRP xx complete, and it SHOULD
   attempt respond to any open SEND
        TR-ID: 123
        Content-Type: "text/plain"
        Hi, I'm Alice!

   7.   Bob->Alice (MSRP):

        MSRP xx 200 OK
        TR-ID: 123

   8.   Bob->Alice (MSRP):

        MSRP xx transactions received prior to being
   signaled.

   It is not possible to completely eliminate the chance of a session
   terminating with incomplete SEND
        TR-ID: 456
        Content-Type: "text/plain"

        Hi, Alice! I'm Bob!

   9.   Alice->Bob (MSRP): transactions. When this occurs, the
   endpoint SHOULD clearly inform the user that the messages may not
   have been delivered.

7.4.5 Managing Session State and Connections

   A MSRP xx 200 OK
        TR-ID: 456
   10.  Alice->Bob (SIP): BYE

        Alice invalidates session and drops connection.

   11.  Bob invalidates local is represented by state for at the session.

        Bob->Alice (SIP): 200 OK

8.2 Single Relay

   This scenario introduces host device. As mention
   previously, session state is identified by an MSRP relay at relay.atlanta.com.

           Alice                    Relay                     Bob
             |                        |                        |
             |                        |                        |
             |(1) (MSRP) BIND         |                        |
             |----------------------->|                        |
             |(2) (MSRP) 200 OK       |                        |
             |<-----------------------|                        |
             |(3) (SIP) INVITE        |                        |
             |------------------------------------------------>|
             |                        |(4) (MSRP) VISIT        |
             |                        |<-----------------------|
             |                        |(5) (MSRP) 200 OK       |
             |                        |----------------------->|
             |(6) (SIP) 200 OK        |                        |
             |<------------------------------------------------|
             |(7) (SIP) ACK           |                        |
             |------------------------------------------------>|
             |(8) (MSRP) SEND         |                        |
             |----------------------->|                        |
             |                        |(9) (MSRP) SEND         |
             |                        |----------------------->|
             |                        |(10) (MSRP) 200 OK      |
             |                        |<-----------------------|
             |(11) (MSRP) 200 OK      |                        |
             |<-----------------------|                        |
             |                        |(12) (MSRP) SEND        |
             |                        |<-----------------------|
             |(13) (MSRP) SEND        |                        |
             |<-----------------------|                        |
             |(14) (MSRP) 200 OK      |                        |
             |----------------------->|                        |
             |                        |(15) (MSRP) 200 OK      |
             |                        |----------------------->|
             |(16) (SIP) BYE          |                        |
             |------------------------------------------------>|
             |(17) (MSRP) BIND        |                        |
             |----------------------->|                        |
             |(18) (MSRP) 200 OK      |                        |
             |<-----------------------|                        |
             |(19) (SIP) 200 OK       |                        |
             |<------------------------------------------------|
             |                        |                        |
             |                        |                        |

   1.   Alice->Relay (MSRP): Alice opens URL. An active
   session also has an associated network connection.

   When session state is destroyed for any reason, the hosting device
   SHOULD drop the connection.

   If the connection fails for any reason, the session hosting device
   MUST invalidate the session state. Once a connection is dropped, the
   associated session state MUST NOT be reused. If an endpoint wishes to
   continue to communicate after detecting a connection failure, it MAY
   initiate a new SDP exchange to negotiate a new session URL.
   Otherwise, it SHOULD attempt to tear down the relay, and
        sends session using the following:

        MSRP xx BIND
        S-URL:msrp://relay.atlanta.com
        TR-ID: 321
        Exp:600

   2.   Relay->Alice (MSRP):

        MSRP xx 200 OK
        TR-ID: 321
        S-URL: msrp://relay.atlanta.com:7777/iau39
        Exp:300

   3.   Alice->Bob (SIP): INVITE sip:bob@biloxi.com

        c=IN IP4 dummyvalue
        m=message 9999 msrp/tcp *
        a=accept-types:text/plain
        a=direction:passive
        a=session:msrp://relay.atlanta.com:7777/iau39

   4.   Bob->Alice: Open rules
   of the signaling protocol.

      It would be nice to allow sessions to be recovered after a
      connection failure, perhaps by allowing the active endpoint to relay.atlanta.com:7777.

        Bob->Relay (MSRP):

        MSRP xx
      reconnect, and send a new VISIT
        S-URL:msrp://relay.atlanta.com:7777/iau39
        TR-ID: sie09s

   5.   Relay->Bob (MSRP):

        MSRP xx 200 OK
        TR-ID: sie09s
        Exp:300

   6.   Bob->Alice (SIP): 200 OK

        c=IN IP4 nobodybutuschickens
        m=message 9999 msrp/tcp *
        a=accept-types:text/plain
        a=direction:active

   7.   Alice->Bob (SIP): ACK
   8.   Alice->Relay (MSRP): request. However, this approach
      creates a race condition between the time that the hosting device
      notices the failed connection, and the time that the endpoint
      tries to recover the session. If the endpoint attempts to
      reconnect prior to the hosting device noticing the failure, the
      hosting device will interpret the recovery attempt as a conflict.
      The only way around this would be to force the hosting device to
      do a liveness check on the original connection, which would create
      a lot of complexity and overhead that do not seem to be worth the
      trouble.

7.5 Method Descriptions

   This section summarizes the purpose of each MSRP xx SEND
        TR-ID: 123
        Content-Type: "text/plain"
        Hi, I'm Alice!

   9.   Relay->Bob (MSRP): method. All MSRP xx
   messages MUST contain the TR-ID header fields. All messages MUST
   contain a length field in the start line that indicates the overall
   length of the request, including any body, but not including the
   start line itself. Additional requirements exist depending on the
   individual method.

7.5.1 SEND
        TR-ID: 123
        Content-Type: "text/plain"
        Hi, I'm Alice!

   10.  Bob->Relay (MSRP):

        MSRP xx 200 OK
        TR-ID: 123

   11.  Relay->Alice (MSRP):

        MSRP xx 200 OK
        TR-ID: 123

   12.  Bob->Relay (MSRP):

        MSRP xx

   The SEND
        TR-ID: 456
        Content-Type:"text/plain"

        Hi, Alice! I'm Bob!

   13.  Relay->Alice (MSRP):

        MSRP xx method is used by both the host and visitor endpoints to
   send instant messages to its peer endpoint. SEND
        TR-ID: 456
        Content-Type: "text/plain"

        Hi, Alice! I'm Bob!

   14.  Alice->relay (MSRP):

        MSRP xx requests SHOULD
   contain a MIME body part. The body MUST be of a media type included
   in the format list negotiated in the SDP exchange. If a body is
   present, the request MUST contain a Content-Type header field
   identifying the media type of the body.

      To Do: We plan to expand the use of MIME headers to allow any
      standard MIME header in a SEND request. This is not included in
      this version for the sake of getting the draft out as soon as
      possible, but will follow soon.

7.5.2 VISIT

   The visiting endpoint uses the VISIT method to associate a network
   connection with the session state at the hosting device. The request
   MUST contain a S-URL header matching the session URL.

7.6 Response Code Descriptions

   This section summarizes the various response codes. Except where
   noted, all responses MUST contain a TR-ID header field matching the
   TR-ID header field of the associated request.

7.6.1 200 OK
        TR-ID: 456
   15.  Relay->Bob (MSRP):

        MSRP xx

   The 200 OK
        TR-ID: 456

   16.  Alice->Bob (SIP): BYE

   17.  Alice->Relay (MSRP):

        MSRP xx  BIND
        S-URL: msrp://relay.atlanta.com:7777/iau39
        TR-ID: 42
        Exp:0

   18.  Relay->Alice (MSRP): Relay invalidates response code indicates a successful transaction.

7.6.2 400

   A 400 response indicates a request was unintelligible.

7.6.3 415

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

7.6.4 426

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

7.6.5 481

   A 481 response indicates that no session state. exists for the connection.

7.6.6 506

   A 506 response indicates that a VISIT request occurred in which the
   S-URL indicates a session that is already associated with another
   connection. A 506 response MUST NOT be returned in response to any
   method other than VISIT.

7.7 Header Field Descriptions

   This section summarizes the various header fields. MSRP xx 200 OK
        TR-ID: 42
        Exp:0

   19.  Bob invalidates local state header fields
   are single valued; that is, they MUST NOT occur more than once in a
   particular request or response.

7.7.1 TR-ID

   The TR-ID header field contains a transaction identifier used to map
   a response to the corresponding request. A TR-ID value MUST be unique
   among all values used by a given endpoint inside a given session.
   MSRP elements MUST NOT assume any additional semantics for TR-ID.

7.7.2 Content-Type

   The Content-Type header field is used to indicate the MIME media type
   of the body. Content-Type MUST be present if a body is present.

      To Do: The work group has agreed to allow the use of any standard
      MIME header. This is not reflected in this version, but will be in
      a shortly forthcoming one.

7.7.3 S-URL

   The S-URL header field is used to identify the session.

        Bob->Alice (SIP): 200 OK

8.3 Two Relays

   In this scenario, both Alice The S-URI
   header field must be included in VISIT requests.

8. Example

   This section shows an example message flow for the most common
   scenario. The example assumes SIP is used to transport the SDP
   exchange. Details of the SIP messages and Bob SIP proxy infrastructure
   are each required by local
   policy to route all sessions through a different local relay. omitted for the sake of brevity. In the example, assume the
   offerer is sip:alice@atlanta.com and the answerer is
   sip:bob@biloxi.com. In any given MSRP message, an "xx" in the length
   field indicates the actual length of the rest of the message.

           Alice      AtlantaRelay    BiloxiRelay                     Bob
             |                        |
             |                        |
             |              |              |              |
             |(1) (MSRP) BIND              |              |
             |------------->|              |              |
             |(2) (MSRP) 200 OK            |              |
             |<-------------|              |              |
             |(3) (SIP) INVITE        |              |
             |------------------------------------------->|
             |              |              |(4) (MSRP) VISIT
             |              |              |<-------------|
             |              |(5)
             |----------------------->|
             |(2) (MSRP) VISIT        |
             |              |<-------------|              |
             |              |(6) (MSRP) 200 OK            |
             |              |------------->|              |
             |              |              |(7)
             |<-----------------------|
             |(3) (MSRP) 200 OK       |              |              |------------->|
             |(8)
             |----------------------->|
             |(4) (SIP) 200 OK        |              |
             |<-------------------------------------------|
             |(9)
             |<-----------------------|
             |(5) (SIP) ACK           |              |              |
             |------------------------------------------->|
             |(10) (MSRP) SEND             |              |
             |------------->|              |              |
             |              |(11) (MSRP) SEND             |
             |              |------------->|              |
             |              |              |(12)
             |----------------------->|
             |(6) (MSRP) SEND         |              |              |------------->|
             |              |              |(13) (MSRP) 200 OK
             |              |              |<-------------|
             |              |(14)
             |----------------------->|
             |(7) (MSRP) 200 OK       |
             |              |<-------------|              |
             |(15)
             |<-----------------------|
             |(8) (MSRP) SEND         |              |
             |<-------------|              |              |
             |(16) (SIP) BYE|              |              |
             |------------------------------------------->|
             |(17) (MSRP) BIND             |              |
             |------------->|              |              |
             |(18)
             |<-----------------------|
             |(9) (MSRP) 200 OK       |
             |----------------------->|
             |(10) (SIP) BYE          |
             |<-------------|              |              |
             |(19)
             |----------------------->|
             |(11) (SIP) 200 OK       |              |
             |<-------------------------------------------|
             |              |              |              |
             |<-----------------------|
             |                        |
             |                        |

   1.   Alice->AtlantaRelay (MSRP):   Alice opens constructs a session URL of msrp://
        alicepc.atlanta.com:7777/iau39 and listens for a connection to her
        relay, and sends the following:

        MSRP xx BIND
        S-URL: msrp://relay.atlanta.com
        TR-ID: 321
        Exp:600

   2.   AtlantaRelay->Alice (MSRP):

        MSRP xx 200 OK
        TR-ID: 321
        S-URL: msrp://relay.atlanta.com:7777/iau39
        Exp:600

   3. on
        TCP port 7777.

        Alice->Bob (SIP): INVITE sip:bob@biloxi.com
        v=0
        o=alice 2890844557 2890844559 IN IP4 host.anywhere.com
        s=
        c=IN IP4 blahblahblah fillername
        t=0 0
        m=message 9999 msrp/tcp *
        a=accept-types:text/plain
        a=session:msrp://relay.atlanta.com:7777/iau39
        a=direction:passive
   4.   Bob determines that, due to local policy, he must connect
        through his own relay.

        Bob->BiloxiRelay (MSRP):
        a=direction:both 0
        a=session:msrp://alicepc.atlanta.com:7777/iau39

   2.   Bob opens a TCP connection to his relay,
        and sends the following:

        MSRP xx VISIT
        S-URL: msrp://relay.atlanta.com:7777/iau39
        TR-ID: 934

   5.   BiloxiRelay->AtlantaRelay alicepc.atlanta.com:7777:

        Bob->Alice (MSRP): BiloxiRelay resolves the URL,
        opens a connection to relay.atlanta.com:7777, and sends the
        following:

        MSRP xx VISIT
        S-URL: msrp://relay.atlanta.com:7777/iau39
        TR-ID: 934

   6.   AtlantaRelay->BiloxiRelay(MSRP):

        MSRP xx 200 OK
        TR-ID: 934

   7.   BiloxiRelay->Bob(MSRP):
        S-URL:msrp://alicepc.atlanta.com:7777/iau39
        Tr-ID: sie09s

   3.   Alice->Bob (MSRP):

        MSRP xx 200 OK
        TR-ID: 934

   8.
        Tr-ID: sie09s

   4.   Bob->Alice (SIP): 200 OK

        v=0
        o=bob 2890844612 2890844616 IN IP4 host.anywhere.com
        s=
        c=IN IP4 stuff ignorefield
        t=0 0
        m=message 9999 msrp/tcp *
        a=accept-types:text/plain
        a=direction: active

   9.
        a=direction:active 0

   5.   Alice->Bob (SIP): ACK

   10.  Alice->AtlantaRelay

   6.   Alice->Bob (MSRP):

        MSRP xx SEND
        TR-ID: 123
        Content-Type: "text/plain"
        Hi, I'm Alice!

   11.  AtlantaRelay ->BiloxiRelay

   7.   Bob->Alice (MSRP):

        MSRP xx SEND 200 OK
        TR-ID: 123
        Content-Type: "text/plain"
        Hi, I'm Alice!

   12.  BiloxiRelay->Bob

   8.   Bob->Alice (MSRP):

        MSRP xx SEND
        TR-ID: 123 456
        Content-Type: "text/plain"

        Hi, I'm Alice!

   13.  Bob->BiloxiRelay (MSRP):

        MSRP xx 200 OK
        TR-ID: 123

   14.  BiloxiRelay->AtlantaRelay (MSRP):

        MSRP xx 200 OK
        TR-ID: 123

   15.  AtlantaRelay->Alice I'm Bob!

   9.   Alice->Bob (MSRP):

        MSRP xx 200 OK
        TR-ID: 123

   16. 456

   10.  Alice->Bob (SIP): BYE

   17.  Alice->AtlantaRelay (MSRP):

        MSRP xx BIND
        S-URL: msrp://relay.atlanta.com:7777/iau39
        TR-ID: 42
        Exp:0

   18.  Relay->Alice (MSRP): Relay

        Alice invalidates session state.

        MSRP xx 200 OK
        TR-ID: 42
        Exp:0

   19. and drops connection.

   11.  Bob invalidates local state for the session.

        Bob->Alice (SIP): 200 OK

9. IANA Considerations

9.1 MSRP Port

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

9.2 MSRP URL Schemes

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

9.2.1 Syntax

   See Section 7.1.

9.2.2 Character Encoding

   See Section 7.1.

9.2.3 Intended Usage

   See Section 7.1.

9.2.4 Protocols

   The Message Session Relay Protocol (MSRP).

9.2.5 Security Considerations

   See Section 10.

9.2.6 Relevant Publications

   RFCXXXX

   [Note to RFC Editor: Please replace RFCXXXX in the above paragraph
   with the actual number assigned to this document.

9.3 SDP Parameters

   This document registers the following SDP parameters in the
   sdp-parameters registry:

9.3.1 Direction

   Attribute-name:  direction
   Long-form Attribute Name Direction
   Type: Media level
   Subject to Charset Attribute No
   Purpose and Appropriate Values See Section 6.2.

9.3.2 Accept Types

   Attribute-name:  accept-types
   Long-form Attribute Name Acceptable MIME Types
   Type: Media level
   Subject to Charset Attribute No
   Purpose and Appropriate Values See Section 6.3.

9.3.3 Wrapped Types

   Attribute-name:  accept-wrapped-types
   Long-form Attribute Name Acceptable MIME Types Inside Wrappers
   Type: Media level
   Subject to Charset Attribute No
   Purpose and Appropriate Values See Section 6.4.

10. Security Considerations

   There are a number of security considerations for MSRP, some of which
   are mentioned elsewhere in this document. This section discusses
   those further, and introduces some new ones.

      Open Issue: There have been suggestions that we need more here
      covering the multiple authentication possibilities, MITM attack
      possibility on digest if not over TLS, and possible bid-down
      attacks on the digest algorithm selection.

10.1 TLS and the MSRPS Scheme

   All MSRP devices must support TLS, with at least the
   TLS_RSA_WITH_AES_128_CBC_SHA [8] cipher suite. Other cipher suites
   MAY be supported.

   MSRP does not define a separate TCP port for TLS connections. This
   means that all MSRP server devices, that is, all devices that listen
   for TCP connections, MUST be prepared to handle both TLS and plain
   text connections on the same port. When a device accepts a TCP
   connection, it MUST watch for the TLS handshake messages to determine
   if a particular connection uses TLS. If the first data received is
   not part of a start TLS request, the device ceases to watch for the
   TLS handshake until it reads the entire message. Once the message has
   been completely received, the device resumes watching for the start
   TLS message.

   An MSRP device MAY refuse to accept a given request over a non-TLS
   connection by returning a 426 response.

   MSRP devices acting in the role of TCP client MAY perform a TLS
   handshake at any time, as long as the request occurs between MSRP
   messages. The endpoint MUST NOT send a start TLS request in the
   middle of an MSRP message.

      The working group considered only requiring the endpoint to watch
      for a TLS handshake at the beginning of the session. However, the
      endpoint should be able to determine if a new message is a start
      TLS request or an MSRP request by only reading ahead three bytes.
      Therefore, the working group chose to allow a session to switch to
      TLS in mid-stream, as long as the switch occurs between MRSP
      messages.

   The MSRPS URI scheme indicates that all hops in an MSRP session MUST
   be protected with TLS. Ensuring this implies some additional rules. A
   relay MUST return an MSRPS URL to a BIND request if the request
   arrived over TLS and included a MSRPS URI in the S-URI header field.
   The relay MAY return an MSRPS URI to any BIND request that arrives
   over TLS, but MUST NOT return an MSRP URI to a BIND request that does
   not arrive over TLS. If a relay receives a BIND request with an MSRPS
   S-URI, over a non-TLS connection, it session MUST reject the request
   be protected with a
   426 response. A relay may insist on always using TLS. Since this document does not specify the use
   of intermidiary devices, then MSRPS by returning a
   426 support is trivially equivilant
   to any bind received over TLS support. However, if intermediaries do exist, either as
   described in an MSRP extension document, or as sort of proprietary
   devices, they MUST ensure protection at all hops for an unprotected connection, and always
   returning MSRPS URLs to BIND requests over protected connections. URL.

   A VISIT request for an MSRPS URL MUST be sent over a TLS protected
   connection. If a visiting relay hosting device receives a VISIT request for an MSRPS
   URL over an unprotected connection, it MUST reject the request with a
   426 response.

10.2

10.1.1 Sensitivity of the Session URL

   The URL of a MSRP session is used by the visiting endpoint to
   identify itself to the hosting device, regardless of whether the
   session is directly hosted by the host endpoint, or is hosted by a
   relay. device. If an attacker were able to
   acquire the session URL, either by guessing it or by eavesdropping,
   there is a window of opportunity in which the attacker could hijack
   the session by sending a VISIT request to the host device before the
   true visiting endpoint. Because of this sensitivity, the session URL
   SHOULD be constructed in a way to make it difficult to guess, and
   should be sufficiently random so that it is unlikely to be reused.
   All mechanisms used to transport the session URL to the visitor and
   back to the host SHOULD be protected from eavesdroppers and
   man-in-the-middle attacks.

   Therefore an MSRP device MUST support the use of TLS for at least the
   VISIT request, which by extension indicates the endpoint MUST support
   the use of TLS for all MSRP messages. Further, MSRP connections
   SHOULD actually be protected with TLS. Further, an MSRP endpoint MUST
   be capable of using the security features of the signaling protocol
   in order to protect the SDP exchange and SHOULD actually use them on
   all such exchanges. End-to-end protection schemes SHOULD be preferred
   over hop-by-hop schemes for protection of the SDP exchange.

10.3

10.1.2 End to End Protection of IMs

   Instant messages can contain very sensitive information. As a result,
   as specified in RFC 2779 [3], instant messaging protocols need to
   provide for encryption, integrity and authentication of instant
   messages. Therefore MSRP endpoints MUST support the end-to-end
   encryption and integrity of bodies sent via SEND requests using
   Secure MIME (S/MIME) [7].

   Note that while each protected body could use separate keying
   material, this is inefficient in that it requires an independent
   public key operation for each message. Endpoints wishing to invoke
   end-to-end protection of message sessions SHOULD exchange symmetric
   keys in SDP k-lines, and use secret key encryption on for each MSRP
   message. When symmetric keys are present in the SDP, the offer-answer
   exchange MUST be protected from eavesdropping and tampering using the
   appropriate facilities of the signaling protocol. For example, if the
   signaling protocol is SIP, the SDP exchange MUST be protected using
   S/MIME.

10.4

10.1.3 CPIM compatibility

   MSRP sessions may be gatewayed to other CPIM [17]compatible
   protocols. If this occurs, the gateway MUST maintain session state,
   and MUST translate between the MSRP session semantics and CPIM
   semantics that do not include a concept of sessions. Furthermore,
   when one endpoint of the session is a CPIM gateway, instant messages
   SHOULD be wrapped in "message/cpim" [5] bodies. Such a gateway MUST
   include "message/cpim" as the first entry in its SDP accept-types
   attribute. MSRP endpoints sending instant messages to a peer that has
   included 'message/cpim" as the first entry in the accept-types
   attribute SHOULD encapsulate all instant message bodies in "message/
   cpim" wrappers. All MSRP endpoints MUST support the message/cpim
   type, and SHOULD support the S/MIME features of that format.

10.5

10.1.4 PKI Considerations

   Several aspects of MSRP will benefit from being used in the context
   of a public key infrastructure. For example, the MSRPS scheme allows,
   and even encourages, TLS connections between endpoint devices.  And
   while MSRP allows for a symmetric session key to protect all messages
   in a session, it is most likely that session key itself would be
   exchanged in a signaling protocol such as SIP. Since that key is
   extremely sensitive, its exchange would also need to be protected. In
   SIP, the preferred mechanism for this would be S/MIME, which would
   also benefit from a PKI.

   However, all of these features may be used without PKI. Each endpoint
   could instead use self signed certificates. This will, of course, be
   less convenient than with a PKI, in that there would be no
   certificate authority to act as a trusted introducer. Peers would be
   required to exchange certificates prior to securely communicating.

   Since, at least for the immediate future, any given MSRP
   implementation is likely to communicate with at least some peers that
   do not have a PKI available, MSRP implementations SHOULD support the
   use of self-signed certificates, and SHOULD support the ability to
   configure lists of trusted certificates.

      To Do: Add text discussion the use of TLS certificates in more
      detail.

11. Changes from Previous Draft Versions

   This section to be deleted prior to publication as an RFC

11.1 draft-ietf-simple-message-sessions-03

      Removed all specification of relays, and all features specific to
      the use of relays. The working group has chosen to move relay work
      into a separate effort, in order to advance the base
      specification. (The MSRP acronym is unchanged for the sake of
      convenience.) This included removal of the BIND method, all
      response codes specific to BIND, Digest Authentication, and the
      inactivity timeout.

      Removed text indicating that an endpoint could retry failed
      requests on the same connection. Rather, the endpoint should
      consider the connection dead, and either signal a reconnection or
      end the session.
      Added text describing subsequent SDP exchanges. Added mandatory
      "count" parameter to the direction attribute to allow explicit
      signaling of the need to reconnect.
      Added text to describe the use of send and receive only indicators
      in SDP for one-way transfer of large content.
      Added text requiring unique port field values if multiple M-line's
      exist.
      Corrected a number of editorial mistakes.

11.2 draft-ietf-simple-message-sessions-02

      Moved all content type negotiation from the "m"-line format list
      into "a"-line attributes. Added the accept-types attribute. This
      is due to the fact that the sdp format-list syntax is not
      conducive to encoding MIME content types values.
      Added "other-method" construction to the message syntax to allow
      for extensible methods.
      Consolidated all syntax definitions into the same section. Cleaned
      up ABNF for digest challenge and response syntax.
      Changed the session inactivity timeout to 12 minutes.
      Required support for the SHA1 alogorithm.
      Required support for the message/cpim format.
      Fixed lots of editorial issues.
      Documented a number of open issues from recent list discussions.

11.2

11.3 draft-ietf-simple-message-sessions-01

      Abstract rewritten.
      Added architectural considerations section.
      The m-line format list now only describes the root body part for a
      request. Contained body part types may be described in the
      "accept-wrapped-types" a-line attribute.
      Added a standard dummy value for the m-line port field. Clarified
      that a zero in this field has normal SDP meaning.
      Clarified that an endpoint is globally configured as to whether or
      not to use a relay. There is no relay discovery mechanism
      intrinsic to MSRP.
      Changed digest algorithm to SHA1. Added TR-ID and S-URI to the
      hash for digest authentication.
      CMS usage replaced with S/MIME.
      TLS and MSRPS usage clarified.
      Session state timeout is now based on SEND activity, rather than
      BIND and VISIT refreshes.

      Default port added.
      Added sequence diagrams to the example message flows.
      Added discussion of self-signed certificates in the security
      considerations section.

11.3

11.4 draft-ietf-simple-message-sessions-00

      Name changed to reflect status as a work group item.
      This version no longer supports the use of multiple sessions
      across a single TCP session. This has several related changes:
      There is now a single session URI, rather than a separate one for
      each endpoint. The session URI is not required to be in requests
      other than BIND and VISIT, as the session can be determined based
      on the connection on which it arrives.
      BIND and VISIT now create soft state, eliminating the need for the
      RELEASE and LEAVE methods.
      The MSRP URL format was changed to better reflect generic URL
      standards. URL comparison and resolution rules were added. SRV
      usage added.
      Determination of host and visitor roles now uses a direction
      attribute much like the one used in COMEDIA.
      Format list negotiation expanded to allow a "prefer these formats
      but try anything" semantic
      Clarified handling of direction notification failures.
      Clarified signaling associated with session failure due to dropped
      connections.
      Clarified security related motivations for MSRP.
      Removed MIKEY dependency for session key exchange. Simple usage of
      k-lines in SDP, where the SDP exchange is protected end-to-end
      seems sufficient.

11.4

11.5 draft-campbell-simple-im-sessions-01

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

12. Contributors

   The following people contributed substantially to this ongoing
   effort:

   Rohan Mahy
   Allison Mankin
   Jon Peterson
   Brian Rosen
   Dean Willis
   Adam Roach
   Cullen Jennings
   Aki Niemi
   Hisham Khartabil
   Pekka Pessi
   Chris Boulton

Normative References

   [1]  Handley, M. and V. Jacobson, "SDP: Session Description
        Protocol", RFC 2327, April 1998.

   [2]  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.

   [3]  Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
        Presence Protocol Requirements", RFC 2779, February 2000.

   [4]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifiers (URL): Generic Syntax", RFC 2396, August 1998.

   [5]  Atkins, D. and G. Klyne, "Common Presence and Instant Messaging
        Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in
        progress), January 2003.

   [6]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
        specifying the location of services (DNS SRV)", RFC 2782,
        February 2000.

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

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

   [9]  Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
        (SHA1)", RFC 3174, September 2001.

Informational References

   [10]  Campbell, B. and J. Rosenberg, "Session Initiation Protocol
         Extension for Instant Messaging", RFC 3428, September 2002.

   [11]  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
         "RTP: A Transport Protocol for Real-Time Applications", RFC
         1889, January 1996.

   [12]  Mahy, R., Campbell, B., Sparks, R., Rosenberg, J., Petrie, D.
         and A. Johnston, "A Multi-party Application Framework for SIP",
         draft-ietf-sipping-cc-framework-02 (work in progress), May
         2003.

   [13]  Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo,
         "Best Current Practices for Third Party Call Control in the
         Session Initiation Protocol", draft-ietf-sipping-3pcc-04 (work
         in progress), June 2003.

   [14]  Sparks, R. and A. Johnston, "Session Initiation Protocol Call
         Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in
         progress), February 2003.

   [15]  Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of
         Resource Management and Session Initiation Protocol (SIP)", RFC
         3312, October 2002.

   [16]  Peterson, J., "A Privacy Mechanism for the Session Initiation
         Protocol (SIP)", RFC 3323 , November 2002.

   [17]  Peterson, J., "A Common Profile for Instant Messaging (CPIM)",
         draft-ietf-impp-im-04 (work in progress), August 2003.

   [18]  Yon, D., "Connection-Oriented Media Transport in SDP",
         draft-ietf-mmusic-sdp-comedia-05 (work in progress), March
         2003.

   [19]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
         Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
         Basic and Digest Access Authentication", RFC 2617, June 1999.

Authors' Addresses

   Ben Campbell
   dynamicsoft
   5100 Tennyson Parkway
   Suite 1200
   Plano, TX  75024

   EMail: bcampbell@dynamicsoft.com
   Jonathan Rosenberg
   dynamicsoft
   600 Lanidex Plaza
   Parsippany, NJ  07054

   EMail: jdrosen@dynamicsoft.com

   Robert Sparks
   dynamicsoft
   5100 Tennyson Parkway
   Suite 1200
   Plano, TX  75024

   EMail: rsparks@dynamicsoft.com

   Paul Kyzivat
   Cisco Systems
   Mail Stop LWL3/12/2
   900 Chelmsford St.
   Lowell, MA  01851

   EMail: pkyzivat@cisco.com

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

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

Full Copyright Statement

   Copyright (C) The Internet Society (2003). (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgment

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