SIMPLE Working Group                                         B. Campbell
Internet-Draft                                              J. Rosenberg
Expires: November 20, December 29, 2003                                     R. Sparks
                                                             dynamicsoft
                                                              P. Kyzivat
                                                           Cisco Systems
                                                            May 22,
                                                           June 30, 2003

                   Instant Message Sessions in SIMPLE
                 draft-ietf-simple-message-sessions-00
                 draft-ietf-simple-message-sessions-01

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 November 20, December 29, 2003.

Copyright Notice

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

Abstract

   The SIP MESSAGE method is used to send instant messages, where each
   message is independent of any other message. This is often called
   pager-mode messaging, due to the fact that this model is similar to
   that of most two-way pager devices. Another model is called
   session-mode. In session-mode, the instant messages are part of a
   media session that provides ordering, a security context, and other
   functions. This media session is established using a SIP INVITE, just
   as an audio or video session would be established.

   This document describes the Message Session Relay Protocol (MSRP), a
   mechanism for transmitting session-mode messages with minimalist
   relay support. Additionally, this document describes a series of Instant Messages within a
   session. MSRP sessions are managed using the SDP offer/answer model to initiate
   carried by a signaling protocol such sessions. as 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  . . . . . . . . . . . . . . . . . . . . .  5
   5.     SDP Offer-Answer Exchanges for MSRP Sessions.    Architectural Considerations . . . . . . . . . . . . . . . .  8
   5.1   Use of the SDP M-line Relays  . . . . . . . . . . . . . . . . . . . . . . .  8
   5.2    The Direction Attribute   Transferring Large Content . . . . . . . . . . . . . . . . .  9
   5.3    URL Negotiations   Connection Sharing . . . . . . . . . . . . . . . . . . . . .  10
   5.4    Example  9
   6.    SDP Exchange Offer-Answer Exchanges for MSRP Sessions . . . . . . . . 10
   6.1   Use of the SDP M-line  . . . . . . . . . . .  11
   6.     The Message Session Relay Protocol . . . . . . . . 10
   6.2   The Direction Attribute  . . . .  11
   6.1    MSRP URLs . . . . . . . . . . . . . . 11
   6.3   MIME Wrappers  . . . . . . . . . .  11
   6.2    MSRP URL Comparison . . . . . . . . . . . . . 13
   6.4   URL Negotiations . . . . . .  12
   6.3    Resolving MSRP Host Device . . . . . . . . . . . . . . . . 13
   6.3.1  The msrps URL Scheme . . .
   6.5   Example SDP Exchange . . . . . . . . . . . . . . . .  14
   6.4    MSRP messages . . . . 14
   7.    The Message Session Relay Protocol . . . . . . . . . . . . . 15
   7.1   MSRP URLs  . . . . .  14
   6.5    MSRP Transactions . . . . . . . . . . . . . . . . . . . . 15
   6.6
   7.1.1 MSRP Sessions  . . URL Comparison  . . . . . . . . . . . . . . . . . . . . 16
   6.6.1  Initiating an
   7.1.2 Resolving MSRP session Host Device . . . . . . . . . . . . . . . . . 16
   6.6.2  Handling VISIT requests
   7.1.3 The msrps URL Scheme . . . . . . . . . . . . . . . . .  19
   6.6.3  Sending Instant Messages on a Session . . . 17
   7.2   MSRP messages  . . . . . . .  20
   6.6.4  Managing Session State and Connections . . . . . . . . . .  21
   6.7    MSRP Relays . . . . . . 17
   7.3   MSRP Transactions  . . . . . . . . . . . . . . . . .  22
   6.7.1  Establishing Session State at a Relay . . . . 18
   7.4   MSRP Sessions  . . . . . .  22
   6.7.2  Removing Session State from a relay . . . . . . . . . . .  24
   6.7.3  Sending IMs across an MSRP relay . . . . . . 19
   7.4.1 Initiating an MSRP session . . . . . . .  24
   6.7.4  Relay Pairs . . . . . . . . . . 19
   7.4.2 Handling VISIT requests  . . . . . . . . . . . . .  24
   6.8    Session State Expiration . . . . . 23
   7.4.3 Sending Instant Messages on a Session  . . . . . . . . . . . 23
   7.4.4 Ending a Session .  26
   6.9    Digest Authentication . . . . . . . . . . . . . . . . . .  26
   6.9.1  The MD5 Algorithm . . . 24
   7.4.5 Session Inactivity Timer . . . . . . . . . . . . . . . . .  27
   6.10   Method Descriptions . 24
   7.4.6 Managing Session State and Connections . . . . . . . . . . . 25
   7.5   MSRP Relays  . . . . . . .  28
   6.10.1 BIND . . . . . . . . . . . . . . . . . 26
   7.5.1 Establishing Session State at a Relay  . . . . . . . . . .  28
   6.10.2 SEND . 26
   7.5.2 Removing Session State from a relay  . . . . . . . . . . . . 28
   7.5.3 Sending IMs across an MSRP relay . . . . . . . . . . . . . . 28
   6.10.3 VISIT
   7.5.4 Relay Pairs  . . . . . . . . . . . . . . . . . . . . . . . . 28
   7.6   Digest Authentication  . .  29
   6.11   Response Code Descriptions . . . . . . . . . . . . . . . .  29
   6.11.1 200 . 30
   7.6.1 The SHA1 Algorithm . . . . . . . . . . . . . . . . . . . . . 31
   7.7   Method Descriptions  . . . . .  29
   6.11.2 400 . . . . . . . . . . . . . . . 31
   7.7.1 BIND . . . . . . . . . . . .  29
   6.11.3 401 . . . . . . . . . . . . . . . . 31
   7.7.2 SEND . . . . . . . . . . .  29
   6.11.4 403 . . . . . . . . . . . . . . . . . 32
   7.7.3 VISIT  . . . . . . . . . .  30
   6.11.5 415 . . . . . . . . . . . . . . . . . 32
   7.8   Response Code Descriptions . . . . . . . . . .  30
   6.11.6 481 . . . . . . . 32
   7.8.1 200  . . . . . . . . . . . . . . . . . . . .  30
   6.11.7 500 . . . . . . . . 32
   7.8.2 400  . . . . . . . . . . . . . . . . . . .  30
   6.11.8 506 . . . . . . . . . 33
   7.8.3 401  . . . . . . . . . . . . . . . . . .  30
   6.12   Header Field Descriptions . . . . . . . . . . 33
   7.8.4 403  . . . . . .  30
   6.12.1 TR-ID . . . . . . . . . . . . . . . . . . . . . . 33
   7.8.5 415  . . . .  30
   6.12.2 Exp . . . . . . . . . . . . . . . . . . . . . . . . 33
   7.8.6 426  . . .  30
   6.12.3 CAuth . . . . . . . . . . . . . . . . . . . . . . . . . 33
   7.8.7 481  .  31
   6.12.4 SChal . . . . . . . . . . . . . . . . . . . . . . . . . .  32
   6.12.5 Content-Type . 33
   7.8.8 500  . . . . . . . . . . . . . . . . . . . . . .  32
   6.12.6 S-URL . . . . . . 33
   7.8.9 506  . . . . . . . . . . . . . . . . . . . .  32
   7.     Examples . . . . . . . . 33
   7.9   Header Field Descriptions  . . . . . . . . . . . . . . . . .  32
   7.1    No Relay 33
   7.9.1 TR-ID  . . . . . . . . . . . . . . . . . . . . . . . . .  33
   7.2    Single Relay . . 34
   7.9.2 Exp  . . . . . . . . . . . . . . . . . . . . .  34
   7.3    Two Relays . . . . . . . 34
   7.9.3 CAuth  . . . . . . . . . . . . . . . . .  37
   8.     IANA Considerations . . . . . . . . . . 34
   7.9.4 SChal  . . . . . . . . .  40
   9.     Security Considerations . . . . . . . . . . . . . . . . .  40
   9.1    The MSRPS Scheme . 35
   7.9.5 Content-Type . . . . . . . . . . . . . . . . . . . .  40
   9.2    Sensitivity of the Session URL . . . . 36
   7.9.6 S-URL  . . . . . . . . . .  41
   9.3    End to End Protection of IMs . . . . . . . . . . . . . . .  41
   9.4    CPIM compatibility . . 36
   8.    Examples . . . . . . . . . . . . . . . . . .  42
   10.    Changes introduced in
          draft-ietf-simple-message-sessions-00 . . . . . . . . 36
   8.1   No Relay . .  42
   11.    Changes introduced in
          draft-campbell-simple-im-sessions-01 . . . . . . . . . . .  43
   12.    Contributors . . . . . . . . . . . . . 36
   8.2   Single Relay . . . . . . . . . .  43
          Normative References . . . . . . . . . . . . . . 39
   8.3   Two Relays . . . . .  43
          Informational References . . . . . . . . . . . . . . . . .  44
          Authors' Addresses . . . 42
   9.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 46
   9.1   MSRP Port  . . . . . . . . . . . . . . . . . . .  45
          Intellectual Property and Copyright Statements . . . . . . 46

1. Introduction

   The MESSAGE [9] 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 pager-mode messaging, since it follows a model similar to that
   used by many two-way pager devices. Pager-mode messaging makes sense
   for instant message exchanges where a small number of messages occur.

   There are also applications in which it is useful for instant
   messages to be associated together in some way. 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 5) 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
   9.2   MSRP session.

2. Motivation for Session-mode Messaging

   Message sessions offer several advantages over pager-mode messages.
   For message exchanges that include more than a small number of
   message transactions, message sessions offer a way to remove
   messaging load URL Schemes . . . . . . . . . . . . . . . . . . . . . . 46
   9.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
   9.2.2 Character Encoding . . . . . . . . . . . . . . . . . . . . . 46
   9.2.3 Intended Usage . . . . . . . . . . . . . . . . . . . . . . . 47
   9.2.4 Protocols  . . . . . . . . . . . . . . . . . . . . . . . . . 47
   9.2.5 Security Considerations  . . . . . . . . . . . . . . . . . . 47
   9.2.6 Relevant Publications  . . . . . . . . . . . . . . . . . . . 47
   9.3   SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . 47
   9.3.1 Direction  . . . . . . . . . . . . . . . . . . . . . . . . . 47
   9.3.2 Wrapped Types  . . . . . . . . . . . . . . . . . . . . . . . 47
   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 . . . . . . . . . . . . . . . . 49
   10.4  CPIM compatibility . . . . . . . . . . . . . . . . . . . . . 50
   10.5  PKI Considerations . . . . . . . . . . . . . . . . . . . . . 50
   11.   Changes from Previous Draft Versions . . . . . . . . . . . . 50
   11.1  draft-ietf-simple-message-sessions-01  . . . . . . . . . . . 51
   11.2  draft-ietf-simple-message-sessions-00  . . . . . . . . . . . 51
   11.3  draft-campbell-simple-im-sessions-01 . . . . . . . . . . . . 52
   12.   Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52
         Normative References . . . . . . . . . . . . . . . . . . . . 53
         Informational References . . . . . . . . . . . . . . . . . . 53
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 54
         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.

   There are also applications in which it is useful for instant
   messages to be associated together in some way. 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, unless proxies also act as message
   relays.

   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,
   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 intervening SIP proxies. For example, one endpoint to another.

   VISIT: Used by an endpoint to establish a minimal session setup 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 tear-down requires one INVITE/ACK transaction,
      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
   one BYE transaction, must not duplicate the URL used for any other active
   sessions.

   B "visits" A by connecting to A and sending a total of 5 SIP messages. Normal SIP VISIT request routing allows for all but
   containing the initial INVITE transaction to
   bypass any intervening proxies URL that do not specifically request A provided. This associates the connection
   from B with the session. B then responds to be
   in the path for future requests. Session-mode invitation, informing
   A that B has accepted the session. A and B may now exchange messages never cross
   using SEND requests on the SIP proxies themselves, unless proxies also act as message
   relays.

   Each pager mode message involves connection.

   When either party wishes to end the session, it informs the peer
   party with a complete SIP transaction, 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 is,
   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 response. Any pager-mode message exchange SEND request. If this timer expires
   without being reset, the hosting device invalidates the session state
   and terminates all associated connections. Endpoints that
   involves more than 2 or 3 MESSAGE are
   otherwise idle may keep a session active by periodically sending SEND
   requests will generate with no content.

   A slightly more SIP
   requests than complicated case involves a minimal session initiation sequence. Since MESSAGE is
   normally used outside single relay, known about
   in advance by one of a SIP dialog, these requests will typically
   traverse the entire proxy network between parties. The endpoint that has the endpoints.

   Due to network congestion concerns,
   preexisting relationship with the MESSAGE relay uses the BIND method has
   significant limitations in message size, a prohibition against
   overlapping requests, etc. Much of this has been required because of
   perceived limitations to
   establish session state 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,
   so relay. The relay returns a temporary
   URL, that message transactions can be overlapped.

   Message sessions allow greater efficiency for secure message
   exchanges. 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 SIP MESSAGE 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 inherits the S/MIME features
   with an expiration value of
   SIP, allowing zero.

5. Architectural Considerations

   There are a message to be signed and/or encrypted. However, this
   approach requires public key operations for each message. With
   session-mode messaging, number of considerations that, if handled in a session key can be established at reasonable
   fashion, will allow more effective use of the time protocols described in
   this document.

5.1 Use of session initiation. This key can be used to protect each message
   that Relays

   The primary motivation for relay support in MSRP is part to deal with
   situations where, due to issues of network topologies, neither
   endpoint is able to receive an inbound TCP connection from the session. This requires other.
   For example, both endpoints may be behind separate firewalls that
   only symmetric key
   operations allow outbound connections. Relays may also be needed for each subsequent IM, and no additional certificate
   exchanges are required after policy
   enforcement. For example, parts of the initial exchange. The establishment 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 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 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 media
   sessions can equally apply to message sessions. For example,
   conferencing [11], third party call control [12], call transfer [13],
   QoS integration [14], and privacy [15]
   simultaneous TCP connections they can all handle.

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

   Messaging sessions can also reduce

   MSRP supports the overhead in each individual
   message. In pager-mode, use of two relays, where each message needs to include all endpoint has a relay
   acting on its behalf. However, most of the SIP
   headers network topology issues
   mentioned above can work with a single relay, if that are mandated relay is
   reachable by RFC 3261 [2]. However, many of these
   headers both endpoints. Dual relays are not only needed once a context is established for exchanging
   messages. As 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 result, messaging session mechanisms given usage
   scenario can be designed solved with significantly less overhead.

3. Scope a single relay, then a second relay
   SHOULD NOT be used.

   In spite of this Document

   This document describes these recommendations, relays serve a real purpose in
   that the use increase the likelihood 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 arbitrary endpoints being
   able to determine whether talk to one another. Therefore if a
   relay is needed, or for provider deploys MSRP
   endpoints in a network configuration that prevents them from
   receiving TCP connections from arbitrary peers, and does not wish to discover
   explicitly prevent MSRP communication with the presence of relays.

   This document describes outside world, then
   the provider SHOULD provide its endpoints with the use of an MSRP over TCP.
   relay that is reachable from arbitrary peers.

5.2 Transferring Large Content

   MSRP endpoints may be used attempt to send very long messages on 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 other congestion-controlled protocols
   it.

   An analysis of whether it makes sense to do this, rather than sending
   such as SCTP. However, the
   specific bindings for content over FTP, HTTP, or some other such protocols are outside protocol, is beyond
   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 However, implementers should be aware of
   the use impact of one or two relay devices. sending very large messages over MSRP. The primary
   impact is, since 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 sent over TCP, is that any additional
   messages that the following primitives:

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

   VISIT: Used by an endpoint to establish a session association to will be blocked until the
      opposite endpoint, or
   large transfer is complete. This includes responses to a relay that was selected messages sent
   by the opposite
      endpoint.

   BIND: Used peer. Therefore, any SEND transactions initiated by an endpoint to establish a session at a relay, and
      allow the opposite endpoint peer
   are likely to visit that relay.

   The simplest use case for MSRP time out, even though they are received without
   problems.

   Further, there is a session that goes directly
   between endpoints, with no intermediaries involved. Assume A way to abort the sending of a very large message
   before it is an
   endpoint that wishes complete. For the sake of efficiency, the framing
   mechanism in MSRP is very simple. There is no clean way to establish a recover
   framing if the complete message session, and B is not sent.

   These issues can be mitigated greatly if the endpoint invited by A. A invites B to participate in simply
   establishes a message separate session by sending a URL that represents for the session. transfer. This URL is
   temporary, and must not duplicate allows the URL used for
   transfer to be sent without interfering with any instant messages
   being sent on 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 Further, the session. B then responds to endpoint can abort the invitation, informing
   A that B has accepted
   transfer by simply tearing down the transfer session. A and B may now exchange messages
   using SEND requests on the connection.

   When either party Therefore, if a
   peer wishes to end the session, send very large content, it informs the peer
   party with SHOULD establish a SIP BYE request. A terminates the
   dedicated session by
   invalidating associated state, and dropping the connection.

   The end to end case looks something like the following. (Note for 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 purpose.

5.3 Connection Sharing

   The state associated with the session will expire over time, based on
   an expiration time specified in the VISIT request. If the lifetime of
   the session is to exceed that expiration time, the visitor must
   update the expiration with a new VISIT request prior to expiration.

   A slightly more complicated case involves SIMPLE working group spent quite a single relay, known about
   in advance by one bit of effort in the parties. The endpoint that has
   consideration of shared TCP connections. Connection sharing would
   offer value whenever a large number of message sessions cross the
   preexisting relationship with
   same two adjacent devices. This situation is likely to occur in the
   two relay uses the BIND method to
   establish session state model. It may also occur in the relay. 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 relay returns biggest problem is it introduced a temporary
   URL, head-of-line
   blocking problem that identifies the session. spanned sessions. For endpoints A and B, and relay R, example, if two different
   pairs of users had sessions that crossed the flow same shared connection,
   a large message sent on one session would look like block transfer of messages
   on 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 other session. The BIND request contains working group considered this an expiration time much the same as in
   VISIT. If the life
   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 relay-hosted session is great deal of complexity to exceed the
   expiration value in the BIND request, the host endpoint will refresh protocol, so the expiration time with a new BIND request prior
   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 expiration.
   Additionally, when tearing down a session, the host endpoint
   invalidates prohibit shared connections on
   other such protocols. However, such specification is beyond the session state by issuing a BIND request with an
   expiration value scope
   of zero.

5. this document.

6. SDP Offer-Answer Exchanges for MSRP Sessions. Sessions

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

5.1

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 MUST indicate the MIME content-types that the
   endpoint is willing to accept in the payload of SEND requests. If any of the allowed types
   are compound in nature, that is, they allow one or more arbitrary
   MIME body parts to be embedded within them, then the format list MUST
   include the content-types allowed for the embedded parts. If the
   final entry in the format list is a "*", this indicates that the
   endpoint is may be willing to receive other types as well, but the
   types listed explicitly are preferred. The format list in the SDP
   answer MUST be the same as, or a subset of, the list provided in the
   offer.

      A "*" in the format list indicates that the sender may attempt to
      send messages with other 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 in the format list should be considered preferred over any
      non-listed types. This feature is needed as, otherwise, the format
      list for IM devices may be prohibitively large.

      The m-line format list may include MIME wrapper types, that is,
      mime formats that contain other types internally. The types listed
      in the format field can be used both as the root payload, or may
      be contained in container types. (Note that the container type
      must also be listed in the format list.) A list of types that are
      only allowed when wrapped in containers can be communicated in the
      accept-wrapped-types (Section 6.3) attribute.

   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. URL (Section 6.1). 7.1). However, a port value
   of zero has the normal SDP meaning.

   The following example illustrates an m-line for a CPIM message session,
   where the endpoint is willing to accept root payloads of message/
   cpim, plain text or HTML, which may appear at the top level of HTML. The second two types could either be
   presented as the payload, root body, or
   may could be embedded inside a contained within message/cpim body part.
   bodies.

      m=message 49232 9999 msrp/tcp message/cpim text/plain text/html

5.2

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" [sp timeout]
                   both = "both"
                   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 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 MIME Wrappers

   The MIME content-types in the M-line format list will often include
   compound types; that is, types that contain other types. For example,
   "message/cpim" or "multipart/mixed."  Occasionally and 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 the format list
   in the m-line. The semantics for this attribute are identical to
   those of the m-line format list, with the exception that the
   specified types may only be used when wrapped inside containers. The
   container types would be specified on the m-line normally. Since any
   type listed on the m-line may be used both as a root body, or 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 offer. wrapper. If the offer
   contained "both", gateway were to specify the answerer SHOULD select "active", but MAY select
   "passive" if local policy requires it wrapped types in
      the m-line format list, its peer could choose to act as host.

5.3 use those types
      without the wrapper.

6.4 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, 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 6.1. 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
   the MUST be ignored. The port field in the M-line are not relevant, and MUST be ignored.
   ignored if non-zero. Zero values have the normal meeting 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 7394 9999 msrp/tcp 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 the Security
   Considerations section.

5.4 Section 10.

6.5 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 7394 9999 msrp/tcp 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 7394 9999 msrp/tcp 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.

6.

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 reliable, congestion-controlled,
   connection-oriented transport protocols, such as TCP.

6.1

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. There is no default port for MSRP URLs. 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.

      Open Issue: Do we need

   MSRP has an  IANA registered recommended port defined in Section 9.1.
   However, this value should not be considered a default port? Cullen points out it would
      at least default, as the URL
   process described herein will always explicitly resolve a port
   number. However, the URLs SHOULD be useful configured so that the
   recommended port is used whenever appropriate. This makes life easier
   for network administrators who need to manage firewall configuration. 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

6.2

7.1.1 MSRP URL Comparison

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

      The host part is compared as case insensitive.

      If the port exists explicitly in either URL, then it must match
      exactly. Since there is no default port for MSRP, a An URL with an explicit port is never equivalent to
      another with no port specified.

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

      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.

6.3

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.

      Open Issue: We need to carefully consider the rules about A RR
      selection. I am sure there are others who understand this much
      better than I do. Ted pointed us to RFC1794, which if I understand
      correctly indicates that some systems may attempt to load balance
      by controlling the order in which A RRs are presented. Attempts to
      randomize selection by the client could distort device SHOULD attempt to use any such control. 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 be determined
   separately from the resolution process. For example, if the MSRP URL
   was communicated in an SDP offer or answer, the SDP M-line will
   contain the transport protocol. When an MSRP URL is communicated
   outside of SDP, the protocol SHOULD also be communicated. For
   example, a client may be configured to use a particular relay that is
   referenced with an MSRP URL. The client MUST also be told what
   protocol to use. If a device needs to resolve an MSRP URL and does
   not know the protocol, it SHOULD assume TCP.

      Open Issue: Do we need to do an NAPTR query to determine the
      protocol?

6.3.1

7.1.3 The msrps URL Scheme

   The "msrps" URL Scheme indicates that each hop MUST be secured with
   TLS. Otherwise, it is used identically as an MSRP URL, except that a
   MSRPS URL MUST NOT be considered equivalent to an MSRP URL. The MSRPS
   scheme is further discussed in the Security Considerations section.

6.4 Section 10.

7.2 MSRP messages

   MSRP messages are either requests or responses. Requests and
   responses are distinguished from one another by the first line. The
   first line of a Request takes the form of the request-start entry
   below. Likewise, the first line of a response takes the form of
   response-start. The syntax for an MSRP message is as follows:

       msrp-message = request-start/response-start *(header CRLF)
                                  [CRLF body]
       request-start = "MSRP" SP length SP  Method CRLF
       response-start= "MSRP" SP length SP Status-Code SP
                                Reason CRLF
       length = 1*DIGIT  ; the length of the message, exclusive of the start line.
       Method = SEND / BIND / VISIT
       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

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

6.5

7.3 MSRP Transactions

   An MSRP transaction consists of exactly one request and one response.
   A response matches a transaction if it share the same TR-ID value,
   and arrives on the same connection on which the transaction was sent.

   BIND is always hop by hop. VISIT transactions are usually hop-by-hop,
   but may be relayed in situations where the visiting endpoint uses a
   relay.  However, SEND transactions are end to end, end-to-end, meaning that under
   normal circumstances the response is sent by the peer endpoint, even
   if there are intervening relays.

   Endpoints MUST select TR-ID header field values in requests so that
   they are not repeated by the same endpoint in scope of the given
   session. TR-ID values SHOULD be globally unique. The TR-ID space of
   each endpoint is independent of that of its peer. Endpoints MUST NOT
   infer any semantics from the TR-ID header field beyond what is stated
   above. In particular, TR-ID values are not required to follow any
   sequence.

   MSRP Transactions complete when a response is received, or after a
   timeout interval expires with no response. Endpoints MUST treat such
   timeouts in exactly the same way they would treat a 500 response. The
   size of the timeout interval is a matter of local policy.

6.6 policy, with a
   default of 30 seconds after a request has been completely sent.

7.4 MSRP Sessions

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

6.6.1

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 the SDP offer/
   answer model. For the purpose of this document, we will refer to the
   endpoint choosing to initiate communication as the offerer, and the
   peer being invited as the answerer.

   The offerer SHOULD volunteer to act as the hosting endpoint if
   allowed by policy and network topology. An endpoint is said to host a
   session if one of two conditions are true. The host either directly
   listens for a connection from the peer endpoint, and maintains
   session state itself, or it uses a BIND request to initialize session
   state at a relay that will listen for a connection from the peer. The
   peer that is not the host is designated as the visitor. The offerer
   MAY request the answerer to act as host if it is prevented from
   accepting connections by network topology or policy, and is not able
   to bind to a relay to act on its behalf.

   If the offerer wishes to host the session directly, that is without
   using a relay, it MUST perform the following steps:

   1.  Construct a session MSRP URL . This URL MUST be resolvable to the
       offerer. The URL SHOULD be temporary, SHOULD be hard to guess,
       and MUST not duplicate the URL  of any other session currently
       hosted by the offerer.

   2.  Listen for a connection from the peer.

   3.  Construct an SDP offer as described in Section 5, 6, including the
       list of allowed IM payload formats in the format list. The
       offerer maps the session URL to the session attribute, as
       described in Section 5.3. 6.4.

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

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

   If the offerer chooses to force the answerer to host the session, it
   MUST perform the following steps instead:

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

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

   3.  Send the offer using normal processing for the signaling
       protocol.

   When the answerer receives the SDP offer and chooses to participate
   in the session, it must choose whether of act as the host or the
   visitor. A direction attribute value of "both" in the offer indicates
   that the offerer wishes to host, but will allow the answerer to host,
   in which case the answerer SHOULD act as the visitor, but MAY choose
   to host. A value of "passive" means the offerer insists upon hosting,
   in which case the answerer MUST act as visitor or decline the offer.

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

   1.  Determine the host address and port from the session URL,
       following the procedures in section Section 6.1 7.1

   2.  Connect to the host address and port, using the transport
       protocol from the M-line.

   3.  Construct a VISIT request, which MUST contain the following
       information:

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

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

       3.  An Exp header field containing the expiration time for the
           VISIT request.

       4.  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, set the actual expiration time to
       the value in the Exp header field in the response, and send a SDP answer via the signaling
       protocol, according to the following rules:

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

       2.  The M-Line contains a dummy port value, the protocol field
           from the original offer, and a format list describing the
           SEND payload media types that the answerer is willing to
           accept. The format list in the answer MUST be either the same
           as the format list in the offer, or a subset.

       3.  A direction attribute containing the value "active".

   6.  If the transaction fails, the answerer MAY choose to act as host,
       if allowed by the direction attribute of the answer. If the
       answerer is unable or unwilling to host, then it should return an
       error response as appropriate for the signaling protocol.

   Some TCP connection failure conditions may ordinarily take some time
   to notice. For example, if the offerer is unable to open a TCP
   connection to the host device, this connection attempt may take a
   fairly large number of seconds to timeout. This length of time will
   not be acceptable for many call flow scenarios. Therefore, the
   devices SHOULD limit the time they wait for the TCP connection to a
   shorter timeout value, which will default to 30 seconds. However, the
   offerer MAY supply a different time in the timeout parameter 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 of seconds.

   If the answerer chooses to host the session, it MUST perform the
   following steps:

   1.  Construct a new session URL . This MUST be a MSRP or MSRPS URL,
       MUST resolve to the answerer, and MUST not be the same as the
       session URL in the offer.  The URL SHOULD be temporary, SHOULD be
       hard to guess, and MUST not duplicate URLs currently identifying
       any active sessions hosted by the answerer.

   2.  Listen for a connection from the peer.

   3.  Construct an SDP answer as described in Section 5, 6, mapping the
       new session URL to the session attribute, and inserting a
       direction attribute with the value 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 the session. If the answer contained a direction
   attribute value of "active", the offerer MUST continue as host. If
   the offer contained "active" or "both" and the answer contains
   "passive", then the offerer MUST allow the answerer to host the
   session.

   If the offerer chooses not to continue as host, it MUST perform the
   following steps:

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

   2.  Determine the host address and port from the session URL of the
       answer, following the procedures in section Section 6.1 7.1

   3.  Connect to the host address and port, using the transport
       protocol from the M-line.

   4.  Construct a VISIT request, which MUST contain the following
       information:

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

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

       3.  An Exp header field containing the expiration time for the
           VISIT request.

       4. header field containing a unique transaction ID.

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

   5.  Send the request and wait for a response

   6.  If the transaction succeeds, set the actual expiration time to
       the value in the Exp header field in the response, and
       acknowledge the answer via the signaling protocol. If either the
       connection attempt or the VISIT transaction fail, acknowledge the
       answer, then initiate the tear-down of the session using the
       signaling protocol.

6.6.2

7.4.2 Handling VISIT requests

   An MSRP endpoint that is hosting a session will receive a VISIT
   request from the visiting endpoint. When an endpoint receives a VISIT
   request, it MUST perform the following procedures:

   1.  Check if state exists for a session with a URL that matches the
       S-URL of the VISIT request. If so, and if no visitor connection
       has been associated with the session, determine the expiration
       time according to the procedures in Section 6.8, then return a 200 response,
       and save state designating the connection on which the request
       was received as the visitor leg of the session.

   2.  If the session exists, and the visitor connection has already
       been established, and the request arrived on the existing visitor
       connection,  treat the request as a refresh, as described in
       Section 6.8. If the request arrived on a different connection, 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 any way.

6.6.3

7.4.3 Sending Instant Messages on a Session

   Once a MSRP session has been established, either endpoint may send
   instant messages to its peer using the SEND method. When an endpoint
   wishes to do so, it MUST construct a SEND request according to the
   following process:

   1.  Insert the message payload in the body, and the media type in the
       Content-Type header field. The media type MUST match one of the
       types in the format list negotiated in the SDP exchange. If a "*"
       is present in the format list, 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 to a unique value.

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

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

   5.  If a 5xx response code is received, the transaction failed, but
       may possibly be successful if retried. The endpoint MAY retry the
       request as a new transaction, that is, with a new TR-ID value. If
       the endpoint receives 5xx responses more than some threshold
       number of times in a row, it SHOULD assume the session 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 the recipient is
       unable or unwilling to process the media type. The sender SHOULD
       NOT attempt to send that particular media type again in the
       context of this session.

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

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

   1.  Determine that it understands the media type in the body, if any
       exists.

   2.  If it does, return a 200 response and render the message to the
       user. The method of rendering is a matter of local policy.

   3.  If it does not understand the media type, return a 415 response.

6.6.3.1 Ending a Session

   When either endpoint in an MSRP session wishes to end the session, it
   first signals its intent using the normal processing for the
   signaling protocol. For example, in SIP, it would send a BYE request
   to the peer. After agreeing to end the session, the host endpoint
   MUST release any resources acquired as part of the session. The
   process for this differs depending on whether the session is hosted
   directly by the host, or an 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 an MSRP relay, it MUST send a BIND
   containing an expires value of zero. This request MUST be sent host
   connection established by the original BIND request. This BIND
   request MUST include the session URL in 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 for some reason the
      host fails to destroy session state, the state will be invalidated
      anyway when either matter of local policy.

   3.  If it does not understand the original BIND or VISIT requests expire.

6.6.4 Managing media type, return a 415 response.

7.4.4 Ending a Session State and Connections

   A MSRP session is represented by state at the host device. As mention
   previously, session state is identified by

   When either endpoint in an MSRP URL. An active session also has two associated network connections. The connection
   hosting device and wishes to end the session, it
   first signals its intent using the normal processing for the
   signaling protocol. For example, in SIP, it would send a BYE request
   to the peer. After agreeing to end the session, the host endpoint is known
   MUST release any resources acquired as part of the host connection. session. The connection with the visiting endpoint is the visiting connection.
   Note that when
   process for this differs depending on whether the session state is hosted
   directly by an endpoint, the host connection may not involve a physical network connection;
   rather it is host, or an a logical connection the device maintains with itself.

   When session relay.

   The host MUST destroy local state is destroyed for any reason, the hosting device
   SHOULD drop session. This involves
   completely removing the connection(s).

   If a connection fails state entry for any reason, the this session hosting device MUST
   invalidate the and invalidating
   session state. This is true regardless of whether the
   dropped connection is URL. If the host or visiting connection. Once a
   connection is dropped, the associated session state MUST NOT be
   reused. If the endpoints wish to continue to communicate after a
   connection failure, they must initiate a new session. An endpoint
   detecting a connection failure SHOULD attempt to tear down the
   session using the rules an MSRP relay, it MUST send a BIND
   containing an expires value of the signaling protocol.

      It would be nice to allow sessions to zero. This request MUST be recovered after a sent host
   connection failure, perhaps established by allowing the opposite endpoint to
      reconnect, and send a new VISIT or original BIND request. However, this
      approach creates a race condition between This BIND
   request MUST include the time that session URL in the
      hosting device notices S-URL header field.

      Since these host actions completely destroy the failed connection, and session state at
      the time that hosting device, the endpoint tries visitor is not required to recover the session. take further
      action beyond cleaning up any local state. If for some reason the endpoint
      attempts to reconnect prior
      host fails to destroy session state, the hosting device noticing the
      failure, the hosting device state 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 invalidated
      anyway when the trouble.

6.7 MSRP Relays

6.7.1 Establishing inactivity timer expires.

7.4.5 Session Inactivity Timer

   State at a Relay

   An endpoint that wishes to host a associated with MSRP session MAY do so by
   initiating session state sessions, either at the host endpoint, or
   a MSRP relay, rather than hosting
   directly. An endpoint may wish to do this because network topology or
   local policy prevents visiting relay, is soft-state; that is, it expires over
   time if no message activity occurs. Each such device maintains a peer from connecting directly to the pair
   of inactivity timer, each with an initial value of 1 minute. One of
   these timers is assigned for each endpoint. The

      All devices use of a relay should not be the default case, that is, same, predetermined timer expiration value.
      While there might be some utility in negotiating this timer on a
      per device basis, such negotiation would add a great deal of
      complexity to MSRP.

   When a hosting endpoint that is not prevented from doing so by topology device or
   policy SHOULD host the session directly. In order to use visiting relay returns a relay, an
   MSRP endpoint MUST have knowledge of that relay's existence and
   location..

   We previously mentioned how an endpoint wishing successful response
   to host a MSRP
   session constructs session URL. When using VISIT request, it MUST initialize both timers. The device MUST
   reset a relay, timer anytime the associated endpoint
   delegates that responsibility to the relay.

   To establish session state at sends a relay, SEND request.
   If either timer expires without being reset, the endpoint device MUST perform the
   following steps:

   1.  Open a network connection to
   invalidate the relay at session, using normal procedures depending on the relays address and
   device's role in the well-known port for MSRP relays, or at another port if so
       configured.

   2.  Construct a BIND request with session.

   Each endpoint MUST keep a S-URL that refers to similar timer, which it initializes when
   the relay.

   3.  Set session is created from its perspective. For the Expire header field host endpoint,
   this is when it receives a successful response to a desired value.

   4.  Send the BIND request on the connection.

   5.  Respond to any authentication request from the relay.

   6.  If the request. For
   a visiting endpoint, this is when it sees a successful response has to a 2xx status code, use the URL in the S-URL
       header field as
   VISIT request. Each endpoint resets its timer whenever it sends a
   SEND request.  If an endpoint inactivity timer approaches expiration,
   and the session URL. The endpoint uses this URL wishes to continue participating in
       exactly the same manner as it had constructed session, it itself.
       Additionally, accept
   MUST send a SEND request. This request MAY be sent without a body if
   there is no user data to send. Endpoints MUST select the expires timer value in the response as session
       expiration time.

   A MSRP relay listens
   so that there is sufficient time for connections the SEND request to traverse to its well-known port 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. opposite endpoint. If authentication succeeds, the
   relay performs the following steps:

   1.  Verify endpoint waits to the client last moment,
   there is authorized to BIND to this relay. If not,
       return a 403 response danger that it will not be received by all relevant
   devices in time to prevent session destruction.

7.4.6 Managing Session State and make no Connections

   A MSRP session is represented by state change.

   2.  If at the client is authorized, construct a host device. As mention
   previously, session state is identified by an MSRP URL. An active
   session also has two associated network connections. The
       URL MUST resolve to the relay. It SHOULD be temporary, connection
   hosting device and hard
       to guess. It MUST not duplicate URL used in any active sessions
       hosted by the relay. If host endpoint is known as the relay wishes host connection.
   The connection with the visiting endpoint to
       connect over a point other than is the MSRP relay well-know port, it
       MUST explicitly add visiting connection.
   Note that when the port number to visitor URL.

   3.  Establish session state is hosted directly by an endpoint,
   the expiration time for host connection may not involve a physical network connection;
   rather it is a logical connection the device maintains with itself.

   When session according to
       section Section 6.8.

   4.  Create state is destroyed for any reason, the session. The relay MUST associate hosting device
   SHOULD drop the connection(s).

   If a connection on which fails for any reason, the BIND request arrived as session hosting device MUST
   invalidate the session state. This is true regardless of whether the
   dropped connection is the host or visiting connection. Once a
   connection for is dropped, the associated session state MUST NOT be
   reused. If the endpoints wish to continue to communicate after a
   connection failure, they must initiate a new session.

   5.  Return An endpoint
   detecting a 200 response, with connection failure SHOULD attempt to tear down the
   session URL in using the S-URL header
       field, and rules of the session expiration time in signaling protocol.

      It would be nice to allow sessions to be recovered after a
      connection failure, perhaps by allowing the Exp header field..

   When an MSRP relay receives opposite endpoint to
      reconnect, and send a new VISIT request, it MUST perform or BIND request. However, this
      approach creates a race condition between the
   following steps:

   1.  Check time that the S-URL header field value to see it matches
      hosting device notices the URL for
       an existing session state entry.

   2.  If not, return a 481 response failed connection, and make no state changes

   3.  If it matches, but another connection has already been associated
       with the session URL, return a 506 response and make no state
       changes. If time that
      the session has been previously associated with this
       connection, treate endpoint tries to recover the request as a refresh.

   4. session. If it matches, and no visiting connection has been previously
       associated with the session, then endpoint
      attempts to reconnect prior to the VISIT succeeds. The relay
       assigns hosting device noticing the connection on which it received
      failure, the VISIT request hosting device will interpret the recovery attempt as
      a conflict. The only way around this would be to force the visiting connection for hosting
      device to do a liveness check on the session, and returns original connection, which
      would create a 200
       response. The visit expiration time is established as described
       in Section 6.8 lot of complexity and returned in overhead that do not seem to
      be worth the response.

6.7.2 Removing trouble.

7.5 MSRP Relays

7.5.1 Establishing Session State from at a relay Relay

   An endpoint that wishes to host a MSRP relay SHOULD remove session MAY do so by
   initiating session state for at a session when any of MSRP relay, rather than hosting
   directly. An endpoint may wish to do this because network topology or
   local policy prevents a peer from connecting directly to the
   following conditions occur:

   o
   endpoint. The expiration time for either use of a relay should not be the BIND or VISIT is reached
      without default case, that is,
   a respective refresh request.

   o  The hosting endpoint that is not prevented from doing so by topology or
   policy SHOULD host sends the session directly. In order to use a BIND refresh request matching with relay, an expiration
      value
   MSRP endpoint MUST have knowledge of zero.

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

6.7.3 Sending IMs across that relay's existence and
   location..

   We previously mentioned how an endpoint wishing to host a MSRP relay

   Once
   session constructs session URL. When using a relay, the endpoint
   delegates that responsibility to the relay.

   To establish session is established state at a relay, the host and visitor may
   exchange IMs by sending SEND requests. Under normal circumstances, endpoint MUST perform the relay does not respond
   following steps:

   1.  Open a network connection to SEND requests in any way. Rather, the relay MUST  forward at the relays address and
       port. Normally, this information will be resolved from an MSRP
       URL representing the relay, although the relay MAY be configured
       with an explicit address and port, rather than a URL.

   2.  Construct a BIND request with a S-URL that refers to the peer connection unchanged.
   Likewise, if relay.

   3.  Set the relay receives Expire header field to a response it MUST forward desired value.

   4.  Send the BIND request unchanged on the peer connection.

   If a SEND

   5.  Respond to any authentication request arrives on from the relay.

   6.  If the response has a connection that is not associated with 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.

   A MSRP relay listens for connections at all times. When it receives a session,
   BIND request, it SHOULD authenticate the request, either using
   digest-authentication, TLS authentication, or some other
   authentication mechanism. If authentication succeeds, the relay MUST
   performs the following steps:

   1.  Verify the client is authorized to BIND to this relay. If not,
       return a 481 response.

6.7.4 Relay Pairs

   In rare circumstances, two relays may be required in 403 response and make no state change.

   2.  If the client is authorized, construct a session. For
   example, two endpoints may exist session MSRP URL. The
       URL MUST resolve to the relay. It SHOULD be temporary, and hard
       to guess. It MUST not duplicate URL used in separate administrative domains,
   where each domain's policy insist that all any active sessions must cross that
   domain's
       hosted by the relay. A If the relay operating on behalf of wishes the visiting endpoint
   is known as to
       connect over a visiting relay. An point other than the MSRP relay MAY be capable of acting
   as a visiting relay.

   In a two relay scenario, well-know port, it
       MUST explicitly add the port number to visitor connects URL.

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

   4.  Create state for the session. The relay operating MUST associate the
       connection on
   its behalf, rather than connecting directly to which the hosting device.
   The visitor sends a VISIT BIND request arrived as it would if it had connected
   directly to the hosting device. The visiting relay then connect to host
       connection for the hosting device and performs session.

   5.  Return a VISIT request on behalf of 200 response, with the
   visitor. session URL in the S-URL header
       field, and the pre-visit session expiration time in the Exp
       header field.

   When a relay that is capable of acting as a visiting an MSRP relay receives a VISIT request, it MUST check to see if perform the S-URL of
   following steps:

   1.  Check the request S-URL header field value to see it matches the URL for
       an existing session state entry.

   2.  If not, return a domain that 481 response and make no state changes

   3.  If it matches, but another connection has already been associated
       with the relay hosts. session URL, return a 506 response and make no state
       changes. If the URL matches, then the
   visitor is not requesting session has been previously associated with this
       connection, treat the relay act request as a visiting relay, and it
   SHOULD operate normally. refresh.

   4.  If it matches, and no visiting connection has been previously
       associated with the URL does not match, session, then the relay
   SHOULD perform the following steps:

   1. VISIT succeeds. The relay SHOULD authenticate
       assigns the VISIT request, using digest
       authentication or some other mechanism.

   2.  Determine that connection on which it received the visiting endpoint is authorized to use this
       device VISIT request as a visiting relay. If not, return a 403 response and
       drop
       the connection.

   3.  Attempt to open a visiting connection to the hosting device, determining for the address session, and port returns a 200
       response.

7.5.2 Removing Session State from the S-URL exactly as if it were a
       visiting endpoint connecting directly. If this connection is
       successful, continue with relay

   An MSRP relay SHOULD remove state for a session when any of the remaining steps. Otherwise, return
   following conditions occur:

   o  The session inactivity timer expires.

   o  The pre-visit timer expires before a 500 response.

   4.  Create local state to associate VISIT request has occurred.

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

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

7.5.3 Sending IMs across an MSRP relay

   Once a session is established at a relay, the host device
       with and visitor may
   exchange IMs by sending SEND requests. Under normal circumstances,
   the connection relay does not respond to SEND requests in any way. Rather, the
   relay MUST  forward the visiting device.

   5.  Relay the VISIT request unchanged to the hosting device.

   6.  Relay peer connection unchanged.
   Likewise, if the relay receives a response to it MUST forward the VISIT
   request unchanged to on the visiting
       endpoint. peer connection.

   If the response a SEND request arrives on a connection that is not associated with
   a 200, set the expiration time for
       the local session state to the value in the Exp header in session, the relay MUST return a 481 response.

   7.

7.5.4 Relay all subsequent arriving on one of the associated
       connections to the peer connection.

   The preceding steps result Pairs

   In rare circumstances, two relays may be required in local session state a session. For
   example, two endpoints may exist in separate administrative domains,
   where each domain's policy insist that expires based all sessions must cross that
   domain's relay. A relay operating on the expiration time negotiated between behalf of the visiting endpoint and
   the hosting device. The
   is known as a visiting relay. An MSRP relay MAY be capable of acting
   as a visiting relay.

      This document does not describe a mechanism for an endpoint will send VISIT requests on
   the same connection from time to time
      discover that it needs to refresh the session state
   expiration time. A use a visiting relay MUST refresh the local expiration
   time based relay. We assume that an
      endpoint is globally configured to use or not use such a relay,
      and does not make this decision on the Exp header field value in a successful response session-by-session basis.
      This, of course, does not preclude using some other mechanism to
      make such a VISIT request. If decision.

   In a two relay scenario, the visitor connects to a relay operating on
   its behalf, rather than connecting directly to the local expiration time passes without hosting device.
   The visitor sends a
   refresh, the visiting relay SHOULD invalidate the session state and
   SHOULD drop the associated connections.

   If either associated connection fails for any reason, VISIT request as it would if it had connected
   directly to the hosting device. The visiting relay SHOULD invalidate then connects to
   the session state, hosting device and SHOULD drop the peer
   connection.

6.8 Session State Expiration

   State associated with MSRP sessions, either at performs a VISIT request on behalf of the host endpoint or
   visitor.

   When a
   host relay, is soft-state; relay that is, it expires over time unless
   refreshed. The expiration time is determined by the Expires header
   field in VISIT and BIND requests. All capable of acting as a visiting relay receives a
   VISIT and BIND requests request, it MUST
   contain an Expires header field. This field is defined as an integer
   number check to see if the S-URL of seconds from the time request
   matches a domain that the request relay hosts. If the URL matches, then the
   visitor is received.

   When a hosting device (endpoint or relay) creates session state due
   to not requesting the relay act as a successful VISIT request, visiting relay, and it
   SHOULD accept operate normally. If the Expires value
   from URL does not match, then the request, although it MAY choose a smaller value. It MUST NOT
   choose a larger value. relay
   SHOULD perform the following steps:

   1.  The device MUST communicate relay SHOULD authenticate the actual chosen
   value back to VISIT request, using digest
       authentication or some other mechanism.

   2.  Determine that the opposite visiting endpoint by placing the value in an
   expires header field in the response.

   Likewise, when is authorized to use this
       device as a relay creates session state due visiting relay. If not, return a 403 response and
       drop the connection.

   3.  Attempt to open a successful BIND
   request, it SHOULD accept connection to the expires value hosting device, determining
       the address and port from the request,
   although S-URL exactly as if it MAY choose were a smaller value. It MUST NOT choose
       visiting endpoint connecting directly. If this connection is
       successful, continue with the remaining steps. Otherwise, return
       a larger
   value. The device MUST communicate 500 response.

   4.  Create local state to associate the actual chosen value back connection to the opposite endpoint by placing host device
       with the value in an Expires header field
   in connection to the response.

   A visiting relay does not normally respond to a VISIT request.
   Rather, it relays device.

   5.  Relay the VISIT request unchanged to the hosting device, and relays device.

   6.  Relay the
   resulting response back to the VISIT request unchanged to the visiting
       endpoint. This prevents it
   from being able

   7.  Relay all subsequent arriving on one of the associated
       connections to negotiate the expiration time in peer connection.

   If either associated connection fails for any reason, the same way as
   hosting devices. Therefore, a visiting
   relay MUST determine session
   expiration time from invalidate the Exp header field in any 200 response
   returned by session state, and MUST drop the hosting device.

6.9 peer
   connection.

7.6 Digest Authentication

   MSRP relays may use the digest authentication scheme to authenticate
   users. MSRP digest authentication is a simplified version of HTTP
   digest authentication [18], [19], but this specification does not
   normatively depend on that document. MSRP digest authentication does
   not support the concept of a protection domain, nor does it support
   integrity protection. Since a user of a relay is expected to have
   credentials for that particular relay, it does not support the realm
   concept. Finally, since digest authentication is only expected for
   the initial BIND or VISIT request, MSRP does not support HTTP digest
   optimizations such as MD5-sess and preemptive credential loading by
   the client.

   Typically, a hosting user that uses a relay will have a preexisting
   relationship 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 the
   hosting relay, so in many 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 it is much more likely to share credentials with the
   visiting user.

      There has been some discussion that a hosting relay SHOULD also
      authenticate VISIT requests. However, it will be very  common for
      visiting users to have no preexisting relationship with the host
      relay. Using authentication here would require the host endpoint
      to send temporary credentials in the SDP exchange, perhaps as part
      of the session URL. However, these temporary credentials would
      necessarily be transferred via the same channels as the session
      URL itself. If the credentials are sufficiently protected in
      transfer, then so is the session URL. Further, since the session
      URL is intended for a one time use, and is expected to be hard to
      guess, that URL itself may 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 and VISIT.

   If a relay wishes to authenticate a request using digest
   authentication, it MAY challenge the request by responding with a
   401 response, which MUST include a SChal 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 the previous request, but with a CAuth
   header field containing the response to the challenge.

6.9.1

7.6.1 The MD5 SHA1 Algorithm

   The only digest authentication algorithm defined in this
   specification is MD5. [8] SHA1. [9] Other algorithms can be added as
   extensions. MD5 SHA1 is the default algorithm if no algorithm directive
   is present in the challenge.

   The MD5 algorithm SHA1 digest is defined as follows:

   Let KD(secret, data) denote the string obtained by  performing the
   digest algorithm to the data "data" with the secret "secret". Let
   H(data) denote the string obtained by performing the checksum
   algorithm on the data "data".

   For the "MD5" "SHA1" algorithm, H(data) = MD5(data), SHA1(data), and KD(secret,data) =
   H(concat(secret, ":", data)

   The request-digest value in a CAuth header field takes the following
   format. Note that unq(quoted-string) denotes the value of the string
   with the quotes removed.

         request-digest  = <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > <">
         A1 = unq(username-value) ":" shared-secret
         A2 = Method concat(Method,TR-ID,S-URI)

   When the relay receives a CAuth header, it SHOULD check its validity
   by looking up the shared secret, or H(A1), performing the same digest
   operation as performed by the client, and comparing the results to
   the request-digest value.

6.10

7.7 Method Descriptions

   This section summarizes the purpose of each MSRP method. All MSRP
   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. Except where otherwise noted, all requests are hop
   by hop.

6.10.1

7.7.1 BIND

   The BIND method is used by a host endpoint to establish or refresh
   session state at a hosting relay. BIND requests SHOULD be
   authenticated. BIND requests MUST contain the S-URL and  Exp header
   fields and MAY contain the CAuth header fields.

   A successful response to a BIND request MUST contain the S-URL and
   Exp header fields.

6.10.2

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

   Unlike other methods, SEND requests are end to end in nature. This
   means the request is consumed only by the opposite endpoint. Under
   normal conditions, any intervening relays merely forward the request
   on towards the peer endpoint.

6.10.3

7.7.3 VISIT

   The visiting endpoint uses the VISIT method to associate a network
   connection with the session state at the hosting device, which could
   be either the host endpoint or a relay operating on behalf of the
   host endpoint. VISIT is also used to refresh the expiration time for
   the visiting connection. The request MUST contain a S-URL header
   matching the session URL. A VISIT request MUST contain the Expires
   header field.

   Successful responses to a VISIT endpoint. The request MUST contain a S-URL header matching the Expires
   header.
   session URL.

      There is normally no authentication operation for the VISIT
      request. This is because the session URL acts as a shared secret
      between host and the visitor. This puts certain requirements on
      the handling of the session URLs that are discussed in Section 9. 10.
      However, if a visiting relay is used, it SHOULD authenticate
      initial VISIT requests, and MAY authenticate subsequent VISIT
      refresh
      requests.

6.11

7.8 Response Code Descriptions

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

6.11.1

7.8.1 200

   The 200 response code indicates a successful transaction.

6.11.2

7.8.2 400

   A 400 response indicates a request was unintelligible.

6.11.3

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 and VISIT.
   A 401 response MUST contain a SChal header field.

6.11.4

7.8.4 403

   A 403 response indicates the user is not authorized to perform the
   action.

6.11.5

7.8.5 415

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

6.11.6

7.8.6 426

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

      Open Issue: Do we need to make 426 extensible to support other
      types of protection?

7.8.7 481

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

6.11.7

7.8.8 500

   A 500 response indicates that a relay was unable to deliver a SEND
   request to the target.

6.11.8

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

6.12

7.9 Header Field Descriptions

   This section summarizes the various header fields. MSRP header fields
   are single valued; that is, they MUST NOT occur more than once in a
   particular request or response.

6.12.1

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

6.12.2

7.9.2 Exp

   The Exp header field specifies when the state associated with a BIND
   or VISIT
   request will expire. expire, if no successful VISIT request has been
   received.. The value is specified as an integer number of seconds
   from the time the request is received. BIND and
   VISIT requests MUST contain
   this header field. Furthermore, successful responses to BIND or VISIT requests must
   MUST also contain the Exp header.

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

   Exp has no meaning if it occurs in MSRP messages other than BIND and
   VISIT
   requests, and responses to those requests. MSRP compliant devices
   SHOULD NOT use Exp in other requests or responses, unless that usage
   is defined in an extension to this specification.

6.12.3

7.9.3 CAuth

   The CAuth header field is used by a host endpoint to respond to offer
   digest authentication credentials to a relay, usually in response to
   a digest authentication challenge. CAuth SHOULD NOT be present in a
   request of any method other than BIND and VISIT.

   The CAuth credentials adhere to the following syntax:

          credentials = "Digest" digest-response
          digest-response = 1#( username | nonce |
                                       response | [ algorithm ] |
                                      [auth-param] )

          username = "username" "=" username-value
          username-value   = quoted-string
          response = "response" "=" request-digest
          request-digest = <"> 32LHEX <">
          LHEX =  "0" | "1" | "2" | "3" |
                       "4" | "5" | "6" | "7" |
                       "8" | "9" | "a" | "b" |
                       "c" | "d" | "e" | "f"
   The meaning of each value 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 of the
      shared secret.

   algorithm: The algorithm value copied from the challenge.

   auth-param: Additional parameters for the sake of extensibility.

6.12.4

7.9.4 SChal

   The SChal header field is used by a relay to carry the challenge in a
   digest authentication attempt. Exactly one SChal header field MUST
   exist in a 401 response. The SChal header MUST NOT be used in any
   message except for a 401 response. The SChal header field value is
   made up of a challenge according to the following syntax:

          challenge= digest-scheme SP digest-challenge

         digest-scheme = "Digest"
         digest-challenge  = 1#( nonce | [ algorithm ] |
                                        [auth-param] )
         nonce = "nonce" "=" nonce-value
         nonce-value = quoted-string
         algorithm = "algorithm" "=" ( "MD5" "SHA1" | token )

   The meaning of each value is as follows:

   digest scheme: A token to identify the particular authentication
      scheme. For digest, the value MUST be "Digest." This token is
      present for the sake of extensibility.

   nonce: A server-specified string, which the relay SHOULD uniquely
      generate each time 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
      the digest and checksum. This directive exists for the sake of
      extensibility; the only value defined by this document is "MD5".
      absence "SHA1".
      Absence of this directive indicates a value of "MD5."

6.12.5 "SHA1".

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

6.12.6

7.9.6 S-URL

   The S-URL header field is used to identify the session. The S-URI
   header field MUST be present in a BIND request, a successful response
   to a BIND request, or a VISIT request.

7.

8. Examples

   This section shows some example message flows for various common
   scenarios. The examples assume SIP is used to transport the SDP
   exchange. Details of the SIP messages and SIP proxy infrastructure
   are omitted for the sake of brevity. In the examples, 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.

7.1

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 a session URL of msrp://alicepc.atlanta.com/
        iau39 and listens for a connection on TCP port 7777.

   2.

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

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

   3.   Bob->Alice: Open

   2.   Bob opens a TCP connection to alicepc.atlanta.com:7777.

   4. alicepc.atlanta.com:7777:

        Bob->Alice (MSRP):

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

   5.
   3.   Alice->Bob (MSRP):

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

   6.

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

        c=IN IP4 ignorefield
        m=message 7777 9999 msrp/tcp text/plain
        a=direction:active

   7.

   5.   Alice->Bob (SIP): ACK

   8.

   6.   Alice->Bob (MSRP):

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

   9.

   7.   Bob->Alice (MSRP):

        MSRP xx 200 OK
        TR-ID: 123

   10.

   8.   Bob->Alice (MSRP):

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

        Hi, Alice! I'm Bob!

   11.

   9.   Alice->Bob (MSRP):

        MSRP xx 200 OK
        TR-ID: 456

   12.  Alice->Bob (SIP):
        TR-ID: 456

   10.  Alice->Bob (SIP): BYE

        Alice invalidates session and drops connection.

   11.  Bob invalidates local state for the session.

        Bob->Alice (SIP): 200 OK

8.2 Single Relay

   This scenario introduces 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

   13.  Alice invalidates session and drops connection.

   14.  Bob invalidates local state for the session.

   15.  Bob->Alice (SIP):          |                        |
             |------------------------------------------------>|
             |(17) (MSRP) BIND        |                        |
             |----------------------->|                        |
             |(18) (MSRP) 200 OK

7.2 Single Relay

   This scenario introduces an MSRP relay at relay.atlanta.com.      |                        |
             |<-----------------------|                        |
             |(19) (SIP) 200 OK       |                        |
             |<------------------------------------------------|
             |                        |                        |
             |                        |                        |

   1.   Alice->Relay (MSRP): Alice opens a connection to the relay, and
        sends the following:

        MSRP xx BIND
        S-URL: msrp://relay.atlanta.com
        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 7777 9999 msrp/tcp text/plain
        a=direction:passive
        a=session:msrp://relay.atlanta.com:7777/iau39

   4.   Bob->Alice: Open connection to relay.atlanta.com:7777.

   5.

        Bob->Relay (MSRP):

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

   6.

   5.   Relay->Bob (MSRP):

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

   7.

   6.   Bob->Alice (SIP): 200 OK
        c=IN IP4 nobodybutchickens nobodybutuschickens
        m=message 7777 9999 msrp/tcp text/plain
        a=direction:active

   8.

   7.   Alice->Bob (SIP): ACK

   9.

   8.   Alice->Relay (MSRP):

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

   9.   Relay->Bob (MSRP):

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

   11.

   10.  Bob->Relay (MSRP):

        MSRP xx 200 OK
        TR-ID: 123

   12.

   11.  Relay->Alice (MSRP):

        MSRP xx 200 OK
        TR-ID: 123

   13.

   12.  Bob->Relay (MSRP):

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

        Hi, Alice! I'm Bob!

   14.

   13.  Relay->Alice (MSRP):

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

        Hi, Alice! I'm Bob!

   15.

   14.  Alice->relay (MSRP):

        MSRP xx 200 OK
        TR-ID: 456

   16.

   15.  Relay->Bob (MSRP):

        MSRP xx 200 OK
        TR-ID: 456
   17.

   16.  Alice->Bob (SIP): BYE

   18.

   17.  Alice->Relay (MSRP):

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

   19.

   18.  Relay->Alice (MSRP): (relay Relay invalidates session state) state.

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

   20.

   19.  Bob invalidates local state for the session.

   21.

        Bob->Alice (SIP): 200 OK

7.3

8.3 Two Relays

   In this scenario, both Alice and Bob are each required by local
   policy to route all sessions through a different local relay.

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

   1.   Alice->AtlantaRelay (MSRP): Alice opens a connection to the 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.   Alice->Bob (SIP): INVITE sip:bob@biloxi.com

        c=IN IP4 blahblahblah
        m=message 7777 9999 msrp/tcp 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 proxy.

   5. relay.

        Bob->BiloxiRelay (MSRP): Bob opens a connection to his relay,
        and sends the following:

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

   6.

   5.   BiloxiRelay->AtlantaRelay (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
        Exp:600

   7.

   6.   AtlantaRelay->BiloxiRelay(MSRP):

        MSRP xx 200 OK
        TR-ID: 934
        Exp:600

   8.

   7.   BiloxiRelay->Bob(MSRP):

        MSRP xx 200 OK
        TR-ID: 934
        Exp:600

   9.

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

        c=IN IP4 stuff
        m=message 7777 9999 msrp/tcp text/plain
        a=direction: active

   10.

   9.   Alice->Bob (SIP): ACK
   11.

   10.  Alice->AtlantaRelay (MSRP):

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

   12.

   11.  AtlantaRelay ->BiloxiRelay (MSRP):

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

   13.

   12.  BiloxiRelay->Bob (MSRP):

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

   14.

   13.  Bob->BiloxiRelay (MSRP):

        MSRP xx 200 OK
        TR-ID: 123

   15.

   14.  BiloxiRelay->AtlantaRelay (MSRP):

        MSRP xx 200 OK
        TR-ID: 123

   16.
   15.  AtlantaRelay->Alice (MSRP):

        MSRP xx 200 OK
        TR-ID: 123

   17.

   16.  Alice->Bob (SIP): BYE

   18.

   17.  Alice->AtlantaRelay (MSRP):

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

   19.  Relay->Alice (MSRP): (relay invalidates session state) xx BIND
        S-URL: msrp://relay.atlanta.com:7777/iau39
        TR-ID: 42
        Exp:0

   18.  Relay->Alice (MSRP): Relay invalidates session state.

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

   19.  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 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.3.

10. Security Considerations

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

10.1 TLS and the MSRPS Scheme

   All MSRP devices must support TLS, with at least the
   TLS_RSA_WITH_AES_128_CBC_SHA [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 TLS handshake request, the device ceases to watch for
   the TLS handshake and begins normal MSRP processing.

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

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

8. IANA Considerations

   To Do.

      Do we need device MAY refuse to register URL schemes accept a given request over a non-TLS
   connection by returning a 426 response, after which it MUST either
   immediately close the connection, or SDP a-line attributes?

9. Security Considerations

   There are begin watching for a number TLS
   handshake request as it would if it had just accepted a connection.

   MSRP devices acting in the role of security considerations TCP client MAY perform a TLS
   handshake either immediately upon connection, or immediately after
   receiving a 426 response. They MUST NOT attempt to upgrade to TLS at
   any other time.

      Allowing clients to upgrade at any time would require the server
      device to check every single request to determine if it is an MSRP
      request or a TLS handshake request. The specified approach only
      requires this check on the initial data received on a connection,
      or on data received immediately after a 426 response. In both
      cases, the receiver will have to peek ahead in the received data
      stream to look for MSRP, some the TLS, then read again from the start once
      the presence or absence of which
   are mentioned elsewhere in this document. This section discusses
   those further, and introduces some new ones.

9.1 The MSRPS Scheme TLS has been determined.

   The MSRPS URI scheme indicates that all hops in an MSRP session MUST
   be protected with TLS. Ensuring this implies some additional rules. An
   MSRP A
   relay MUST NOT return an MSRPS URL to a BIND request if the request
   arrived over TLS and included a MSRPS URI in the S-URL S-URI header field in
   a response 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 unless the that does
   not arrive over TLS. If a relay receives a BIND request itself was
   received with an MSRPS
   S-URI, over a TLS non-TLS connection, it MUST reject the request with a
   426 response. A relay may insist on always using MSRPS by returning a
   426 to any bind received over an unprotected connection, and always
   returning MSRPS URLs to BIND requests over protected session. connections.

   A VISIT request for an MSRPS URL MUST be sent over a TLS protected
   connection. If a visiting relay receives a VISIT request for an MSRPS URL, the connection to the
   hosting device MUST also be protected.

      There has been controversy on whether an MSRPS scheme is really
      needed, since there is a small limit to the total number of hops
      in an MSRP session. However, a mechanism is required to inform the
      visitor to use TLS in the first place. We could have used an SDP
      a-line attribute for this. However, there also needs to be a
      mechanism for a hosting relay to tell the host endpoint to request
      the visitor use TLS. The MSRPS scheme seems to best fit all of
      these requirements.

      Open Issue: There is also some controversy
   URL over how TLS should be
      used with MSRP. The changes in this draft version make it possible
      for relays to act as tunnels, where the TLS handshake is
      end-to-end. This is much the same way that TLS is handled by HTTPS
      proxies. However, this usage requires at least one endpoint to
      have a TLS server certificate, which may not be likely. Another
      approach is to make TLS usage hop-by-hop. When at least one relay
      is used, only the relays would need server certificates. Even if
      we support end-to-end TLS, we may still need a way to specify
      hop-by-hop TLS, because since end-to-end TLS would delay the TLS
      handshake until _after_ an unprotected connection, it MUST reject the BIND and VISIT requests, these
      requests would not be protected.

9.2 request with a
   426 response.

10.2 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. If an attacker were able to acquire 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.

9.3

10.3 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 CMS
   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.

      Open Issue: This subsection needs very close scrutiny for accuracy
      and security. In particular, do we need to say more about using
      secret key operations in CMS?

9.4

10.4 CPIM compatibility

   MSRP sessions may be gatewayed to other CPIM [16]compatible [17]compatible
   protocols. If this occurs, the gateway MUST maintain session state,
   and MUST translate between the MSRP session semantics and CPIM
   semantics 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 format list.
   MSRP endpoints sending instant messages to a peer that has included
   'message/cpim" as the first entry in the format list SHOULD
   encapsulate all instant message bodies in "message/cpim" wrappers.
   All MSRP endpoints SHOULD support the S/MIME features of that format.

10.5 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 include have a concept PKI available, MSRP implementations SHOULD support the
   use of sessions. Furthermore,
   when one endpoint self-signed certificates, and SHOULD support the ability to
   configure lists of trusted certificates.

11. Changes from Previous Draft Versions
   This section to be deleted prior to publication as an RFC

11.1 draft-ietf-simple-message-sessions-01

      Abstract rewritten.

      Added architectural considerations section.

      The m-line format list now only describes the session is root body part for a CPIM gateway, instant messages
   SHOULD
      request. Contained body part types may be wrapped described in "message/cpim" [5] bodies. Such the
      "accept-wrapped-types" a-line attribute.

      Added a gateway MUST
   include "message/cpim" as standard dummy value for the first entry m-line port field. Clarified
      that a zero in its this field has normal SDP format list.
   MSRP endpoints sending instant messages to a peer meaning.

      Clarified that has included
   'message/cpim" 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 first entry in
      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 format list SHOULD
   encapsulate all instant example message bodies in "message/cpim" wrappers.
   All MSRP endpoints SHOULD support the S/MIME features flows.

      Added discussion of that format.

10. Changes introduced self-signed certificates in the security
      considerations section.

11.2 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. Changes introduced in

11.3 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 bidirectionally 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

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]  Housley, R., "Cryptographic  Ramsdell, B., "S/MIME Version 3 Message Syntax (CMS)", Specification", RFC 3369,
        August 2002.
        2633, June 1999.

   [8]  Rivest, R., "The MD5 Message-Digest Algorithm",  Chown, P., ""Advanced Encryption Standard (AES) Ciphersuites for
        Transport Layer Security (TLS)", RFC 1321, April
        1992. 3268, June 2002.

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

Informational References

   [9]

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

   [10]

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

   [11]

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

   [12]

   [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-03 (work
         in progress), March 2003.

   [13]

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

   [14]

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

   [15]

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

   [16]

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

   [17]

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

   [18]

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

Acknowledgement

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