[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

SIMPLE Working Group                                         B. Campbell
Internet-Draft                                              J. Rosenberg
Expires: April 25, 2003                                        R. Sparks
                                                             dynamicsoft
                                                              P. Kyzivat
                                                           Cisco Systems
                                                        October 25, 2002


                   Instant Message Sessions in SIMPLE
                  draft-campbell-simple-im-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 April 25, 2003.

Copyright Notice

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




Campbell, et al.         Expires April 25, 2003                 [Page 1]


Internet-Draft             SIMPLE IM Sessions               October 2002


   This document describes a The Message Session Relay Protocol (MSRP),
   a mechanism for transmitting session-mode messages with minimal relay
   support. Additionally, this document describes using the SDP offer/
   answer model to initiate such sessions.

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.  . . . . . .   8
   5.1    Use of the SDP M-line  . . . . . . . . . . . . . . . . . .   8
   5.2    URI Negotiations . . . . . . . . . . . . . . . . . . . . .   9
   5.3    Example SDP Exchange . . . . . . . . . . . . . . . . . . .   9
   5.4    Session Hosting  . . . . . . . . . . . . . . . . . . . . .  10
   6.     The Message Session Relay Protocol . . . . . . . . . . . .  11
   6.1    MSRP messages  . . . . . . . . . . . . . . . . . . . . . .  11
   6.2    MSRP Transactions  . . . . . . . . . . . . . . . . . . . .  12
   6.3    MSRP Sessions  . . . . . . . . . . . . . . . . . . . . . .  13
   6.4    Initiating an MSRP session . . . . . . . . . . . . . . . .  13
   6.5    Handling VISIT requests  . . . . . . . . . . . . . . . . .  16
   6.6    Sending Instant Messages on a Session  . . . . . . . . . .  17
   6.6.1  Ending a Session . . . . . . . . . . . . . . . . . . . . .  18
   6.7    Managing Session State and Connections . . . . . . . . . .  18
   6.8    MSRP Relays  . . . . . . . . . . . . . . . . . . . . . . .  19
   6.8.1  Establishing Session State at a Relay  . . . . . . . . . .  19
   6.8.2  Removing Session State from a relay  . . . . . . . . . . .  21
   6.8.3  Sending IMs across an MSRP relay . . . . . . . . . . . . .  21
   6.8.4  Relay Pairs  . . . . . . . . . . . . . . . . . . . . . . .  21
   6.9    Method Descriptions  . . . . . . . . . . . . . . . . . . .  22
   6.9.1  BIND . . . . . . . . . . . . . . . . . . . . . . . . . . .  22
   6.9.2  LEAVE  . . . . . . . . . . . . . . . . . . . . . . . . . .  22
   6.9.3  RELEASE  . . . . . . . . . . . . . . . . . . . . . . . . .  22
   6.9.4  SEND . . . . . . . . . . . . . . . . . . . . . . . . . . .  23
   6.9.5  VISIT  . . . . . . . . . . . . . . . . . . . . . . . . . .  23
   6.10   Response Code Descriptions . . . . . . . . . . . . . . . .  23
   6.10.1 200  . . . . . . . . . . . . . . . . . . . . . . . . . . .  24
   6.10.2 400  . . . . . . . . . . . . . . . . . . . . . . . . . . .  24
   6.10.3 401  . . . . . . . . . . . . . . . . . . . . . . . . . . .  24
   6.10.4 403  . . . . . . . . . . . . . . . . . . . . . . . . . . .  24
   6.10.5 481  . . . . . . . . . . . . . . . . . . . . . . . . . . .  24
   6.10.6 500  . . . . . . . . . . . . . . . . . . . . . . . . . . .  24
   6.10.7 506  . . . . . . . . . . . . . . . . . . . . . . . . . . .  24
   6.11   Header Field Descriptions  . . . . . . . . . . . . . . . .  24
   6.12   T-URI  . . . . . . . . . . . . . . . . . . . . . . . . . .  25
   6.13   TR-ID  . . . . . . . . . . . . . . . . . . . . . . . . . .  25
   6.14   CAuth  . . . . . . . . . . . . . . . . . . . . . . . . . .  25



Campbell, et al.         Expires April 25, 2003                 [Page 2]


Internet-Draft             SIMPLE IM Sessions               October 2002


   6.15   SChal  . . . . . . . . . . . . . . . . . . . . . . . . . .  25
   6.16   Content-Type . . . . . . . . . . . . . . . . . . . . . . .  25
   6.17   L-URI  . . . . . . . . . . . . . . . . . . . . . . . . . .  25
   6.18   R-URI  . . . . . . . . . . . . . . . . . . . . . . . . . .  26
   7.     Examples . . . . . . . . . . . . . . . . . . . . . . . . .  26
   7.1    No Relay . . . . . . . . . . . . . . . . . . . . . . . . .  26
   7.2    Single Relay . . . . . . . . . . . . . . . . . . . . . . .  28
   7.3    Two Relays . . . . . . . . . . . . . . . . . . . . . . . .  31
   8.     Changes introduced in 01 version . . . . . . . . . . . . .  34
   9.     Security Considerations  . . . . . . . . . . . . . . . . .  34
   9.1    Sensitivity of the Remote URI  . . . . . . . . . . . . . .  34
   9.2    End to End Protection of IMs . . . . . . . . . . . . . . .  35
   9.3    CPIM compatibility . . . . . . . . . . . . . . . . . . . .  35
   10.    IANA Considerations  . . . . . . . . . . . . . . . . . . .  35
   11.    Open Issues  . . . . . . . . . . . . . . . . . . . . . . .  36
   12.    Contributors . . . . . . . . . . . . . . . . . . . . . . .  36
          Normative References . . . . . . . . . . . . . . . . . . .  36
          Informational References . . . . . . . . . . . . . . . . .  37
          Authors' Addresses . . . . . . . . . . . . . . . . . . . .  37
          Intellectual Property and Copyright Statements . . . . . .  39































Campbell, et al.         Expires April 25, 2003                 [Page 3]


Internet-Draft             SIMPLE IM Sessions               October 2002


1. Introduction

   The MESSAGE [7] 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 is the management of media
   sessions. Session-mode messaging can be thought of as a media session
   like any other. This document describes a method to use SIP to manage
   message sessions. This document does not propose an actual message
   session mechanism; there may any number of mechanisms that are
   appropriate for different applications and environments.

   This document describes the motivations for session-mode messaging,
   the Message Session Relay Protocol, and the use of the SDP offer/
   answer mechanism for initiating 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 from intervening SIP proxies. For example, a minimal
   session setup and teardown 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 pager mode message involves a complete SIP transaction, that is,
   a request and a response. Any pager-mode message exchange that
   involves more than 2 or 3 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.



Campbell, et al.         Expires April 25, 2003                 [Page 4]


Internet-Draft             SIMPLE IM Sessions               October 2002


   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 a reliable,
   congestion-safe transport. 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, and no additional certificate exchanges are required
   after the initial exchange. The establishment of the session key is
   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 [9], third party call control [10], call transfer [11],
   QoS integration [12], and privacy [13] can all be applied to message
   sessions.

   Messaging sessions can also reduce the overhead in each individual
   message. In pager-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.

4. Protocol Overview

   The Message Session Relay Protocol (MSRP) provides a mechanism for
   transporting session-mode messages between endpoints. MSRP also



Campbell, et al.         Expires April 25, 2003                 [Page 5]


Internet-Draft             SIMPLE IM Sessions               October 2002


   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, and allows
   network connections to be shared across multiple message sessions.
   MSRP 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 actually send message content from one endpoint to
      another.

   VISIT (LEAVE): Used by an endpoint to establish a session association
      to the opposite endpoint, or to a relay that was selected by the
      opposite endpoint. "LEAVE" is used to remove the association.

   BIND(RELEASE): Used by an endpoint to establish a session at a relay,
      and allow the opposite endpoint to visit that relay. "RELEASE" is
      used to remove the session.

   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 B two URIs. The first URI represents a the
   destination to which B should send messages. The second represents a
   identifier that B can use to connect to , or visit, A, and to which A
   will send messages. Both URIs are temporary, and must not duplicate
   the local or remote URIs used in any other active sessions.

   B  "visits" A by connecting to A and sending a VISIT request
   containing the URI that A provided it. This establishes state at A
   that associates the connection from B with the URI.  B  then responds
   to the invitation, informing A that B accepts the URI that A assigned
   to it. A can now send messages to B using the SEND method with B's
   URI as the target. Likewise, B can invoke the SEND method targeting
   A's URI.

   When either party wishes to end the session, it informs the other
   party with a SIP BYE. B may end the message session by sending a
   "LEAVE" request, telling A that B will no longer use the URI. If no
   other sessions were using the network connection, B closes the
   connection. alternately, A can end the session by simply invalidating
   state associating the URIs and connections, and dropping the
   connection if no more sessions are using it.





Campbell, et al.         Expires April 25, 2003                 [Page 6]


Internet-Draft             SIMPLE IM Sessions               October 2002


      This creates a race condition between A and B when closing a
      session. It seems that this does not really cause a problem, in
      that if an attempt to close a session fails because the other
      party closed it first, the desired outcome is still achieved.

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

   A->B (SDP): offer (i-am:a@a, you-be:b@a)

   B->A (MSRP): VISIT (b@a)

   A->B (MSRP): 200 OK

   B->A (SDP): answer(i-am b@a)

   A->B (MSRP): SEND (b@a)

   B->A (MSRP): 200 OK

   B->A (MSRP): SEND (a@a)

   A->B (MSRP): 200 OK

   B->A (MSRP):  LEAVE (b@a)

   A->B (MSRP): 200 OK

   A slightly more complicated case involves a single relay, known about
   in advanced by one of the parties. The endpoint with the pre-existing
   relationship with the relay uses the BIND method to establish session
   state in the relay. The relay returns a pair of temporary URIs, one
   for local use, and one to offer to the remote endpoint. For endpoints
   A and B, and relay R, the flow would look like the following:

   A->R: MSRP: BIND

   R->A: MSRP: 200 OK (local:a@r, remote:z@r)

   A->B (SDP): offer (i-am:a@r, you-be:z@r)

   B->R (MSRP): VISIT (z@r)

   R->B (MSRP): 200 OK






Campbell, et al.         Expires April 25, 2003                 [Page 7]


Internet-Draft             SIMPLE IM Sessions               October 2002


   B->A (SDP): answer(i-am:b@r)

   A->R (MSRP): SEND (z@r)

   R->B (MSRP): SEND (z@r)

   B->R (MSRP): 200 OK

   R->A (MSRP): 200 OK

   B->R (MSRP): SEND (a@r)

   R->A (MSRP): SEND (a@r)

   A->R (MSRP): 200 OK

   R->B (MSRP): 200 OK

   A->R (MSRP): RELEASE(a@r)

   B->R (MSRP): LEAVE(z@r)


5. SDP Offer-Answer Exchanges for MSRP Sessions.

   MSRP sessions will typically be initiated using the Session
   Description Protocol (SDP) [1] offer-answer mechanism, carried in SIP
   [2] or any other protocol supporting it.

5.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 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
   example, "msrp/tcp" for MSRP over TCP,  "msrp/tls" for MSRP over TLS,
   etc. 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 imbedded within them, then
   the format list MUST include the content-types allowed for the
   imbedded parts.




Campbell, et al.         Expires April 25, 2003                 [Page 8]


Internet-Draft             SIMPLE IM Sessions               October 2002


   The following example illustrates an m-line for a CPIM message
   session, where the endpoint is willing to accept payloads of plain
   text or HTML, which may appear at the top level of the payload, or
   may be imbedded inside a message/cpim body part.

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


5.2 URI Negotiations

   MSRP offer/answer negotiations require the transmissions of one or
   two URIs. The first identifies the party sending the offer or answer.
   the second offers a temporary URI for the opposite party to use to
   connect to the sending party, or to a relay operating on behalf of
   the sending party. These URIs are respectively designated as "i-am"
   and "you-be". The i-am URI MUST be present in each SDP offer and
   answer. The you-be URI MUST be present if the party sending the offer
   or answer is proposing that its peer connect to the sending party or
   such a relay, and MUST NOT be present otherwise.

   The URI parameters are represented in SDP as a combination of domain
   part in the c-line address parameter and the user parts in a-line
   attributes. The "msrp:" scheme is implied, and MUST not be present in
   the a-line. For example, the following indicates an i-am URI of
   "msrp:2s93i@example.com" and a you-be URI of "msrp:8djese@example.com

           c=IN IP4 example.com
           m=message 7394 msrp/tcp text/plain
           a=i-am:2s93i
           a=you-be:8djese


      This approach implies that the i-am and you-b URIs will always
      share the same domain part. Is there any scenario where this would
      not be desired?

   Both the i-am and the you-b URIs MUST be temporary URIs assigned just
   for this particular session. They MUST NOT duplicate any URI in use
   in any other session hosted by the endpoint. Further, since the peer
   endpoint may use the you-be URI 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 Consideration
   section.

5.3 Example SDP Exchange

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



Campbell, et al.         Expires April 25, 2003                 [Page 9]


Internet-Draft             SIMPLE IM Sessions               October 2002


           c=IN IP4 alice.example.com
           m=message 7394 msrp/tcp message/cpim text/plain
           a=i-am:2s93i9
           a=you-be:8r90ew

   Endpoint B chooses to participate, opens a TCP connection to
   alice.example.com:7394, and successfully performs a VISIT transaction
   passing the URI of "msrp:8r90ew@alice.example.com". B indicates that
   it has accomplished this by answering with:

           c=IN IP4 alice.example.com
           m=message 7394 msrp/tcp message/cpim text/plain text/html
           a=i-am:8r90ew

   A may now send IMs to B by executing SEND transactions targeted to
   "msrp:8r90ew@alice.example.com", and B may SEND to
   "msrp:2s93i9@alice.example.com"

5.4 Session Hosting

   MSRP requires the use of connection oriented transport protocols.
   Part of the offer answer process involves determining which endpoint
   will "host" the session, that is, which will listen for the network
   connection.  When a relay is involved, the hosting endpoint is the
   one that initializes session state at the relay with a BIND request.
   An endpoint indicates its desire to host a session by including a
   "you-be" URI in its SDP.

   Typically, the offerer will also be the host. If the offerer is in a
   position to accept a connection, or has access to a relay that can
   accept a connection on its behalf, then it SHOULD offer to host the
   session. If the offerer does in fact include a you-be URI, the
   answerer SHOULD accept the offerer's desire to host by visiting the
   URI provided, and, if successful, returning the offered you-be URI in
   the i-am URI of the answer.

   There may be situations where the endpoint inviting a peer to
   participate in an MDRP cannot, or does not wish to, host the
   connection. For example that endpoint may be behind a NAT or firewall
   that prevents inbound connections. In this case, the initiating
   endpoint MAY send an SDP offer with no you-be URI. If the answerer
   receives such an offer, it SHOULD act as session host, and return a
   you-be URI in the answer. Of course, if neither party is able and
   willing to host the session, then they cannot participate in an MSRP
   session.

      This probably requires the offerer to accept the offered you-be
      URI in its ACK. However, we are trying to specify this in terms of



Campbell, et al.         Expires April 25, 2003                [Page 10]


Internet-Draft             SIMPLE IM Sessions               October 2002


      the SDP offer/answer model only, and not depend on SIP's three
      phase INVITE. We could simply have the inviting party not include
      an offer, but in this case the invitee is likely to assume an RTP
      session is desired, unless some other mechanism is invoked to
      communicate the desired session type.

   There may be scenarios where the invitee is required by policy to use
   a particular relay, and by implication, must act as host on all
   session, even if the inviter included the you-be URI in the offer.
   The invitee may decline to accept the inviter's proposal to host by
   returning a different you-be URI, and an i-am URI that does not match
   the you-be URI of the offer. In this situation, the inviter SHOULD
   allow the invitee to host.

   Finally, there may be scenarios where both parties are required by
   policy to use different relays. This is similar to the previous case
   where the invitee overrides the inviter's proposal to host, except
   that the inviter does not return the you-be URI that the invitee
   proposed as its i-am URI in the ACK request. Each endpoint BINDs with
   its relay, and neither performs a VISIT. When one of the endpoints
   attempts a SEND operation, its relay will attempt to connect to the
   peer's relay. This will be described in more detail in the Relay
   Behavior section.

6. The Message Session Relay Protocol

   The Message Session Relay Protocol (MSRP) is a text based, messaging
   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 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:











Campbell, et al.         Expires April 25, 2003                [Page 11]


Internet-Draft             SIMPLE IM Sessions               October 2002


       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
       Method = SEND / BIND / RELEASE / VISIT /LEAVE
       header = Client-Authenticate / Server-Challenge /
                 Transaction-ID / Target-URI/ Content-Type
                Local-URI / Remote-URI
       Status-Code = 200    ;Success
                   / 400    ;Bad Request
                   / 401    ;Authentication Required
                   / 403    ;Forbidden
                   / 481    ;No session
                   / 500    ;Cannot Deliver
                   / 506    ;duplicate session
       Reason = token ; Human readable text describing status
       msrp-uri= msrp HCOLON user "@" domain
       Client-Authenticate = "CAuth" HCOLON username "," nonce
                            "," digest-response
       Server-Challenge = "SChal" HCOLON nonce
       Transaction-ID = "TR-ID" HCOLON token
       Content-Type = "Content-Type" HCOLON quoted-string
       Target-URI = "T-URI" HCOLON msrp-uri
       Local-URI = "L-URI" HCOLON msrp-uri
       Remote-URI = "R-URI" HCOLON msrp-uri


      This syntax is not complete. In particular, we will need more work
      on Server-Challenge and Client-Authenticate header fields.

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

6.2 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 if the T-URI value in the response matches a the URI for the
   endpoint that sent the request.

   BIND and VISIT transactions are always hop by hop. However, SEND
   transactions are end to end, meaning that under normal circumstances
   the response is sent by the peer endpoint, even if there are one or
   more intervening relays.




Campbell, et al.         Expires April 25, 2003                [Page 12]


Internet-Draft             SIMPLE IM Sessions               October 2002


   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. 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.3 MSRP Sessions

   AN MSRP session is a context in which a series of IMs are sent, using
   SEND requests. A session has two endpoints (a host and a visitor) and
   may have one or more relays. A session is identified by the tuple of
   the host and visitor URIs. Note that an endpoint that is involved in
   multiple sessions will likely have completely different URIs in one
   session than in another.

6.4 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 inviter, and the
   peer being invited as the invitee.

   The inviter SHOULD act as host for the session. 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 initialized session state at a
   relay that will listen for a connection from the peer, using a BIND
   request. The peer that is not the host is designated as the visitor.
   The inviter MAY allow the invitee 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 inviter chooses to host the session directly, that is without
   using a relay, it MUST perform the following steps:

   1.  Construct a local and visitor MSRP URI . These MUST share the
       same domain part, which MUST be resolvable to the inviter. The
       user parts MUST be distinct from each other. The user part of
       each URI SHOULD be temporary, SHOULD be hard to guess, and MUST
       not duplicate the any URI used in other active sessions hosted by



Campbell, et al.         Expires April 25, 2003                [Page 13]


Internet-Draft             SIMPLE IM Sessions               October 2002


       the inviter.

   2.  Listen for a connection from the peer.

   3.  Construct an SDP offer as described in Section 5, including the
       list of allowed IM payload formats in the format list. The
       inviter maps the local URI to the i-am attribute, and the visitor
       URI to the you-be attribute, as described in Section 5.2

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

   If the inviter chooses to ask the invitee to host the session, it
   MUST perform the following steps instead:

   1.  Construct a host URI as described above. It does not construct a
       visitor URI. Since the inviter will not accept network
       connections, it is not important that the URI resolve to the
       inviter.

   2.  Construct an SDP offer as described above. The M-line port value
       can be any non-zero value, since it will not actually be used.

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

   When the invitee receives the SDP offer and chooses to participate in
   the session, it must choose whether of act as the host or the
   visitor. A you-be attribute in the offer indicates that the inviter
   wishes to host, in which case the invitee SHOULD act as the visitor.

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

   1.  Connect to the host address and port from the C-line and M-line
       in the SDP offer, using the transport protocol from the M-line.

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

       1.  A T-URI header field containing the visitor URI.

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

       3.  A size field containing the overall size of the message.

   3.  Send the request and wait for a response




Campbell, et al.         Expires April 25, 2003                [Page 14]


Internet-Draft             SIMPLE IM Sessions               October 2002


   4.  If the transaction succeeds, 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 the port from the original offer and
           protocol fields from the original offer, and a format list
           describing the SEND payload media types that the invitee is
           willing to accept.

       3.  No you-be attribute

       4.  A i-am attribute containing the user part of the visitor URI,
           that is, the same value that was in the you-be attribute on
           the offer.

   The invitee MAY choose to attempt to host the session under some
   circumstances. If the SDP offer did not contain a you-be attribute,
   the invitee MUST host the session, otherwise it is not possible to
   participate in the session at all. If the offer did contain a you-be
   attribute, but the attempt to connect to the host failed, the invitee
   MAY attempt to host the session. Otherwise, the invitee MAY attempt
   to take over as host because of a local policy requiring it.

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

   1.  Construct a local and visitor MSRP URI . These MUST share the
       same domain part, which MUST be resolvable to the invitee. The
       user parts MUST be distinct from each other. Both URI SHOULD be
       temporary, SHOULD be hard to guess, and MUST not duplicate URIs
       used in any active sessions hosted by the invitee.

   2.  Listen for a connection from the peer.

   3.  Construct an SDP answer as described in Section 5, including the
       list of allowed IM payload formats in the format list. The
       invitee maps the local URI to the i-am attribute, and the visitor
       URI to the you-be attribute, as described in Section 5.2

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

   When the inviter receives the SDP answer, it must determine who will
   continue to host the session. If the offer contained a you-be
   attribute and the answer did not, the inviter MUST continue host the
   session. If the offer did not contain a you-be attribute, and the
   answer did, then the inviter MUST allow the invitee to host the



Campbell, et al.         Expires April 25, 2003                [Page 15]


Internet-Draft             SIMPLE IM Sessions               October 2002


   session. If both the offer and the answer contained you-be
   attributes, this indicates that the invitee is attempting to become
   host. The inviter SHOULD allow the inviter to continue as host.

   If the inviter chooses to allow the invitee to host the session, it
   MUST send an acknowledgment of the SDP answer. If the inviter chooses
   to host in spite of the invitee's attemt to take over, the
   acknowlegement must repeat the i-am attribute from the original
   offer.

   If the inviter chooses not to host, it must perform the following
   steps:

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

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

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

       1.  A T-URI header field containing the visitor URI from the SDP
           answer.

       2.  A TR-ID header field containing a randomly selected initial
           transaction ID.

       3.  A size field containing the overall size of the message.

   4.  Send the request and wait for a response

   5.  If the VISIT succeeds, 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 request using the signaling protocol.


6.5 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 using a visitor URI that
       matches the T-URI of the VISIT request. If so, and no previous
       VISIT request for that URI has occurred, then return a 200
       response, and save state designating the connection on which the



Campbell, et al.         Expires April 25, 2003                [Page 16]


Internet-Draft             SIMPLE IM Sessions               October 2002


       request was received as the visitor leg of the session.

   2.  If the session exists, but a VISIT request has already been
       received for it, 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 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.  Set the T-URI header field to the peer URI. (If the sender is the
       host, it used the visitor URI, and vice versa.)

   2.  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 in the SDP provided by the peer.

   3.  Set the TR-ID header field to a unique value

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

   5.  If a 200 response code is received, the transaction was
       successful.

   6.  If a 500 response code is received, the transaction failed, but
       may possibly be successful if retried. The endpoint MAY retry the
       request with a new TR-ID header field value. If the endpoint
       receives 500 responses more than a threshold number of times in a
       row, it should assume the session has failed, and initiate
       teardown via the signaling protocol. The threshold value is a
       matter of local policy.

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

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

   1.  Verify that the T-URI header field value matches the local URI
       for an existing session.




Campbell, et al.         Expires April 25, 2003                [Page 17]


Internet-Draft             SIMPLE IM Sessions               October 2002


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

   3.  If it does not match an existing session, return a 481 response.


6.6.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, each endpoint MUST
   release any resources acquired as part of the session. The process
   for this differs depending on whether the endpoint is the host or the
   visitor.

   The host MUST destroy local state for the session. This involves
   completely removing the state entry for this session, invalidating
   both the local and remote URIs. If the host is using an MSRP relay,
   it MUST send a RELEASE request to the relay. It MUST send the RELEASE
   on the same connection used for the BIND. The RELEASE MUST include
   the local URI in the T-URI header field.

   The visitor MUST send a LEAVE request on the same connection on which
   it sent the original VISIT. The LEAVE request MUST include the
   visitor URI in the T-URI header field. The visitor MUST then
   invalidate any local state for the session.

      This approach creates a race condition in that both the RELEASE
      and LEAVE requests cause the session state to be invalidated at
      the host. Whichever of these occurs second will receive a 481
      response. We may wish to consider if both of these methods are
      necessary. Is it sufficient to leave state cleanup entirely to the
      host?


6.7 Managing Session State and Connections

   A MSRP session is represented by state at the host device. As mention
   previously, session state is identified by the tuple formed by the
   local and remote URIs. And active session also has a connection
   associated with each of these URIs. The connection associated with
   the remote URI is known as the visiting connection. The connection
   associated with the local URI is known as the host connection. Note
   that when the session state is hosted directly by an endpoint, the
   host connection may not involve a physical network connection; rather
   it is a logical connection the device maintains with itself.




Campbell, et al.         Expires April 25, 2003                [Page 18]


Internet-Draft             SIMPLE IM Sessions               October 2002


   A given network connection may be associated with more than one
   session. In fact, when the session state is hosted by a relay, it is
   entirely possible for a single connection to be the host connection
   for one session, and the visiting connection for another.

   When session state is destroyed for any reason, the hosting device
   SHOULD check to see if each connection is currently associated with
   any other sessions. If not, the device SHOULD drop the connection.

   If a connection fails for any reason, the 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 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.

6.8 MSRP Relays

6.8.1 Establishing Session State at a Relay

   An endpoint that wishes to host a MSRP session MAY do so by
   initiating session state at a 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
   endpoint. The use of a relay should not be the default case, that is,
   a hosting endpoint that is not prevented from doing so by topology or
   policy SHOULD host the session directly. In order to use a relay, an
   MSRP endpoint MUST have knowledge of that endpoints existence and
   location.

   We previously mentioned how an endpoint wishing to host a MSRP
   session constructs a local and remote URI. When using a relay, the
   endpoint delegates that responsibility to the relay.

   To establish session state at a relay, the endpoint MUST perform the
   following steps:

   1.  Construct a BIND request with a T-URI that refers to the relay.

   2.  Open a network connection to the relay at the relays address and
       the well-known port for MSRP relays, or at another port if so
       configured.

   3.  Send the BIND request on the connection.

   4.  Respond to any authentication request from the relay.

   5.  If the response has a 200 status code, use the URI in the L-URI



Campbell, et al.         Expires April 25, 2003                [Page 19]


Internet-Draft             SIMPLE IM Sessions               October 2002


       header field as the local URI, and the URI in the R-URI header
       field as the remote URI. The endpoint uses these URIs in exactly
       the same manner as it had constructed them itself.

   A MSRP relay listens for connections 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. If authentication succeeds, the
   relay performs the following steps:

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

   2.  If the client is authorized, construct a local and remote MSRP
       URI. The domain part of both URIs MUST be the same, and MUST
       resolve to the relay. The URIs SHOULD be temporary, and hard to
       guess. The URIs MUST not duplicate URIs used in any active
       sessions hosted by the relay. If the relay wishes the visiting
       endpoint to connect over a point other than the MSRP relay
       well-know port, it MAY add the port number to visitor URI.

   3.  Create state for the session. The relay MUST associate the
       connection on which it received the BIND request with the local
       URI.

   4.  Return a 200 response, with the T-URI header field value copied
       from the request, the local URI in the L-URI header field, and
       the remote URI in the R-URI field.

   When an MSRP relay receives a VISIT request, it MUST perform the
   following steps:

   1.  Check the T-URI header field value to see it matches the remote
       URI for an existing session state entry.

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

   3.  If it matches, but a connection has already been associated with
       the remote URI, then return a 506 response and make no state
       changes.

   4.  If it matches, and no connection has been associated with the
       remote URI, then the VISIT succeeds. The relay associates the
       connection on it received the VISIT request with the remote URI
       for the session, and returns a 200 response.






Campbell, et al.         Expires April 25, 2003                [Page 20]


Internet-Draft             SIMPLE IM Sessions               October 2002


6.8.2 Removing Session State from a relay

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

   o  The host performs sends an UNBIND request with a T-URI that
      matches the local-URI associated with the session.

   o  The visitor sends a LEAVE request with a T-URI that matches the
      remote-URI associated with the session.

   o  Either the host or visitor network connection is reset by the
      peer, or fails for any reason.


6.8.3 Sending IMs across an MSRP relay

   Once a session is established at a relay, the host and visitor may
   exchange IMs by sending SEND requests. Under normal circumstances,
   the relay does not respond to SEND requests in any way. If the T-URI
   of the SEND request matches the peer URI for the session, the relay
   MUST forward the request unchanged. Likewise, if the relay receives a
   response, where the T-URI matches the peer URI for the session, it
   MUST forward the request unchanged.

   If the relay receives a SEND request that does not match the opposite
   URI of the session, the relay MUST return a 404 response. If a SEND
   request arrives on a connection that has no associated sessions, the
   relay MUST return a 481 response. Note that this may occur in a
   situation where the relay has removed session state because of a
   failure in the peer connection.

6.8.4 Relay Pairs

   In rare circumstances, two relays may be required in a session. For
   example, two endpoints may exist in separate administrative domains,
   where each domain's policy insist that all sessions must cross that
   domain's relay. In this scenario, each endpoint BINDs with its own
   endpoint, and believes itself to be the session host. Neither
   endpoint sends a VISIT request.

   For a relay to support this scenario, it must implement some special
   behavior under the following circumstances:

   o  A session is in a half-complete state; that is, the relay has
      returned a local and remote URI in a response to a BIND request,
      but has not observed a VISIT request using the remote URI.




Campbell, et al.         Expires April 25, 2003                [Page 21]


Internet-Draft             SIMPLE IM Sessions               October 2002


   o  A SEND request arrives on a connection that is associated with at
      least one such "half complete" sessions, and the T-URI refers to a
      domain for which the relay is not responsible.

   Under these circumstances, the relay SHOULD attempt to open a
   connection with a device responsible for the domain in the T-URI, and
   forward the request. If a connection already exists, it SHOULD reuse
   the connection. Likewise, if a relay receives a SEND request on a
   connection not associated with a session, and the T-URI is associated
   with an existing connection, it SHOULD forward the request on that
   connection. If there is no such associated connection, it SHOULD
   return a 500 response.

      This scenario will often result in two effectively one-way
      connections between a pair of relays. Additionally, if one of the
      relays is behind a NAT, this scenario may fail. We believe this is
      acceptable for the two relay case, which should be fairly rare.


6.9 Method Descriptions

   This section summarizes the purpose of each MSRP method. All MSRP
   requests MUST contain the T-URI and TR-ID header fields. All requests
   MUST contain a length field in the start line that indicates the
   overall length of the request, including any body. Additional
   requirements exist depending on the individual method. Except where
   otherwise noted, all requests are hop by hop.

6.9.1 BIND

   The BIND method is used by a host endpoint to establish session state
   at a relay. BIND requests SHOULD be authenticated. BIND requests MAY
   contain the CAuth header fields.

   A successful response to a BIND request MUST contain the L-URI and
   R-URI header fields.

6.9.2 LEAVE

   The LEAVE method is used by a visiting endpoint to request that the
   host invalidate a session. The T-URI field MUST match that of the
   corresponding VISIT request.

6.9.3 RELEASE

   The RELEASE method is used by a host endpoint to request a relay to
   invalidate a session. The T-URI header field in a RELEASE request
   MUST match the L-URI header field returned in the successful response



Campbell, et al.         Expires April 25, 2003                [Page 22]


Internet-Draft             SIMPLE IM Sessions               October 2002


   to the corresponding BIND request.

6.9.4 SEND

   The SEND method is used by both the host and visitor endpoints to
   send instant messages to its peer endpoint. The T-URI header field
   MUST contain the temporary URI for the peer, that is a message sent
   to the visitor MUST use the visitor URI, and a message sent to the
   host MUST use the host URI. SEND requests SHOULD contain a MIME body
   part. The body MUST be of a media type included in the format list in
   the SDP provided by the peer. If a body is present, the request MUST
   contain a Content-Type header field identifying the media type of the
   body.

      There has been discussion that we could make media type
      identification more efficient by using the numeric index of the
      media type as listed in the SDP format list, rather than the full
      media type. This would have an advantage of space efficiency. The
      editor holds the opinion that the ease of readability more than
      offsets any space inefficiency, and is more in keeping with the
      philosophy that led us to choose a text-based protocol in the
      first place. The editor will, however, yield to any contrary
      consensus on the matter.

   Unlike other methods, SEND requests are end to end in nature. This
   means the request is consumed only by the opposite endpoint. Any
   intervening relays merely forward the request on towards its target.

6.9.5 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. The T-URI header field MUST match the visitor URI
   associated with the session.

      Notice that there is no authentication operation for the VISIT
      request. This is because the visitor URI acts as a shared secret
      between host and the visitor. This puts certain requirements on
      the handling of the visitor URIs that are discussed in Section 9


6.10 Response Code Descriptions

   This section summarizes the various response codes. Except where
   noted, all responses MUST contain the T-URI header field containing
   the URI of the endpoint that is the intended consumer of the
   response. Responses are never consumed by relays.



Campbell, et al.         Expires April 25, 2003                [Page 23]


Internet-Draft             SIMPLE IM Sessions               October 2002


   All responses MUST include the TR-ID header, with a value matching
   that of the corresponding request.

6.10.1 200

   The 200 response code indicates a successful transaction.

6.10.2 400

   A 400 response indicates a request was unintelligible.

6.10.3 401

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

6.10.4 403

   A 403 response indicates the authenticated identity of the user
   attempting a BIND request is not authorized to perform such an
   action. A 403 response SHOULD NOT be used in response to any method
   other than BIND.

6.10.5 481

   A 481 response indicates that no session exists that is associated
   with the connection on which the request arrived, and has a peer URI
   that matches the T-URI of the corresponding request.

6.10.6 500

   A 500 response indicates that a relay was unable to deliver a SEND
   request to the target. A 500 response SHOULD NOT be used except for
   when multiple relays exist in a session, and a relay is unable to
   deliver the request to the next relay. Endpoints SHOULD NOT return
   500 responses. 500 responses MUST NOT be returned in response to any
   method other than SEND.

6.10.7 506

   A 506 response indicates that a VISIT request occurred in which the
   T-URI 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.11 Header Field Descriptions




Campbell, et al.         Expires April 25, 2003                [Page 24]


Internet-Draft             SIMPLE IM Sessions               October 2002


   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 T-URI

   The T-URI Header field indicates the target of a request or a
   response. The semantics of T-URI vary with the method in question.

6.13 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.14 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 MUST NOT be present in a
   request of any method other than BIND.

6.15 SChal

   The SChal header field is used by a relay to carry the challenge in a
   digest authentication attempt. The SCHal header MUST NOT be used in
   any message except for a 401 response.

      The semantics of digest authentication in the context of MSRP are
      not fully defined at the time of this writing. We expect this work
      to be completed in a future version of this document, at which
      time the syntax of CAuth and SChal may change.


6.16 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.17 L-URI

   The L-URI header field is used by a relay to indicate the local URI
   for a session created with a BIND request. The L-URI header field
   MUST be present in a 200 response to a BIND request, and MUST NOT be
   present in any other request or response.





Campbell, et al.         Expires April 25, 2003                [Page 25]


Internet-Draft             SIMPLE IM Sessions               October 2002


6.18 R-URI

   The R-URI header field is used by a relay to indicate the remote URI
   for a session created with a BIND request. The L-URI header field
   MUST be present in a 200 response to a BIND request, and MUST NOT be
   present in any other request or response.

7. 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
   inviter is sip:alice@atlanta.com and the invitee is
   sip:bob@biloxi.com. In any given MSRP message, an "xx" in the length
   field indicates the actual length of the message

7.1 No Relay

   1.   Alice constructs a local uri of msrp:iau39@alicepc.atlanta.com
        and a remote uri of msrp: 9342iw@alicepc.atlanta.com, and
        listens for a connection on TCP port 7777.

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

        c=IN IP4 alicepc.atlanta.com
        m=message 7777 msrp/tls text/plain
        a=i-am:iau39
        a=you-be:9342iw


   3.   Bob->Alice: Open TCP connection to Alicepc.atlanta.com:7777, and
        perform TLS handshake.

   4.   Bob->Alice (MSRP):

        MSRP xx VISIT
        T-URI: 9342iw@alicepc.atlanta.com
        TR-ID: msrp:sie09s


   5.   Alice->Bob (MSRP):

        MSRP xx 200 OK
        T-URI: 9342iw@alicepc.atlanta.com
        TR-ID: sie09s





Campbell, et al.         Expires April 25, 2003                [Page 26]


Internet-Draft             SIMPLE IM Sessions               October 2002


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

        c=IN IP4 alicepc.atlanta.com
        m=message 7777 msrp/tls text/plain
        a=i-am:9324iw


   7.   Alice->Bob (SIP): ACK

   8.   Alice->Bob (MSRP):

        MSRP xx SEND
        T-URI: msrp:9234iw@alicepc.atlanta.com
        TR-ID: 123
        Content-Type: "text/plain"
        Hi, I'm Alice!


   9.   Bob->Alice (MSRP):

        MSRP xx 200 OK
        T-URI: msrp:iau39@alicepc.atlanta.com
        TR-ID: 123


   10.  Bob->Alice (MSRP):

        MSRP xx SEND
        T-URI: msrp:iau39@alicepc.atlanta.com
        TR-ID: 456
        Content-Type: "text/plain"

        Hi, Alice! I'm Bob!


   11.  Alice->Bob (MSRP):

        MSRP xx 200 OK
        T-URI: msrp:9234iw@alicepc.atlanta.com
        TR-ID: 456


   12.  Alice->Bob (SIP): BYE

   13.  Alice invalidates session

   14.  Bob->Alice (MSRP):




Campbell, et al.         Expires April 25, 2003                [Page 27]


Internet-Draft             SIMPLE IM Sessions               October 2002


        MSRP xx LEAVE
        T-URI: msrp:9342iw@alicepc.atlanta.com
        TR-ID: 987


   15.  Alice->Bob (MSRP):

        MSRP xx 481 No Session T-URI: 9342iw@alicepc.atlanta.com
        TR-ID: 987


   16.  Bob invalidates local state for the session.

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


7.2 Single Relay

   This scenario introduces an MSRP relay at relay.atlanta.com.

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

        MSRP xx BIND
        T-URI: msrp:relay.atlanta.com
        TR-ID: 321


   2.   Relay->Alice (MSRP):

        MSRP xx 200 OK
        T-URI: msrp:relay.atlanta.com
        TR-ID: 321
        L-URI: msrp:iau39@relay.atlanta.com
        R-URI: msrp:9342iw@relay.atlanta.com:7777


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

        c=IN IP4 relay.atlanta.com
        m=message 7777 msrp/tls text/plain
        a=i-am:iau39
        a=you-be:9342iw


   4.   Bob->Alice: Open TCP connection to relay.atlanta.com:7777, and
        perform TLS handshake.




Campbell, et al.         Expires April 25, 2003                [Page 28]


Internet-Draft             SIMPLE IM Sessions               October 2002


   5.   Bob->Relay (MSRP):

        MSRP xx VISIT
        T-URI: 9342iw@relay.atlanta.com
        TR-ID: msrp:sie09s


   6.   Relay->Bob (MSRP):

        MSRP xx 200 OK
        T-URI: 9342iw@relay.atlanta.com
        TR-ID: sie09s


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

        c=IN IP4 relay.atlanta.com
        m=message 7777 msrp/tls text/plain
        a=i-am:9324iw


   8.   Alice->Bob (SIP): ACK

   9.   Alice->Relay (MSRP):

        MSRP xx SEND
        T-URI: msrp:9234iw@relay.atlanta.com
        TR-ID: 123
        Content-Type: "text/plain"
        Hi, I'm Alice!


   10.  Relay->Bob (MSRP):

        MSRP xx SEND
        T-URI: msrp:9234iw@relay.atlanta.com
        TR-ID: 123
        Content-Type: "text/plain"
        Hi, I'm Alice!


   11.  Bob->Relay (MSRP):

        MSRP xx 200 OK
        T-URI: msrp:iau39@relay.atlanta.com
        TR-ID: 123





Campbell, et al.         Expires April 25, 2003                [Page 29]


Internet-Draft             SIMPLE IM Sessions               October 2002


   12.  Relay->Alice (MSRP):

        MSRP xx 200 OK
        T-URI: msrp:iau39@relay.atlanta.com
        TR-ID: 123


   13.  Bob->Relay (MSRP):

        MSRP xx SEND
        T-URI: msrp:iau39@relay.atlanta.com
        TR-ID: 456
        Content-Type: "text/plain"

        Hi, Alice! I'm Bob!


   14.  Relay->Alice (MSRP):

        MSRP xx SEND
        T-URI: msrp:iau39@relay.atlanta.com
        TR-ID: 456
        Content-Type: "text/plain"

        Hi, Alice! I'm Bob!


   15.  Alice->relay (MSRP):

        MSRP xx 200 OK
        T-URI: msrp:9234iw@relay.atlanta.com
        TR-ID: 456


   16.  Relay->Bob (MSRP):

        MSRP xx 200 OK
        T-URI: msrp:9234iw@relay.atlanta.com
        TR-ID: 456


   17.  Alice->Bob (SIP): BYE

   18.  Alice->Relay (MSRP):

        MSRP xx RELEASE T-URI: msrp:iau39@relay.atlanta.com
        TR-ID: 42




Campbell, et al.         Expires April 25, 2003                [Page 30]


Internet-Draft             SIMPLE IM Sessions               October 2002


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

        MSRP xx 200 OK
        T-URI: msrp:iau39@relay.atlanta.com
        TR-ID: 42


   20.  Bob->Relay (MSRP):

        MSRP xx LEAVE
        T-URI: msrp:9342iw@relay.atlanta.com
        TR-ID: 987


   21.  Alice->Bob (MSRP):

        MSRP xx 481 No Session T-URI: msrp:9342iw@relay.atlanta.com
        TR-ID: 987


   22.  Bob invalidates local state for the session.

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


7.3 Two Relays

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

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

        MSRP xx BIND
        T-URI: msrp:relay.atlanta.com
        TR-ID: 321


   2.   AtlantaRelay->Alice (MSRP):

        MSRP xx 200 OK
        T-URI: msrp:relay.atlanta.com
        TR-ID: 321
        L-URI: msrp:iau39@relay.atlanta.com
        R-URI: msrp:9342iw@relay.atlanta.com:7777


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



Campbell, et al.         Expires April 25, 2003                [Page 31]


        c=IN IP4 relay.atlanta.com
        m=message 7777 msrp/tls text/plain
        a=i-am:iau39
        a=you-be:9342iw


   4.   Bob determines that, due to local policy, he must host the
        session through his own proxy.

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

        MSRP xx BIND
        T-URI: msrp:relay.biloxi.com
        TR-ID: 934


   6.   BiloxiRelay->Bob(MSRP):

        MSRP xx 200 OK
        T-URI: msrp:relay.biloxi.com
        TR-ID: 934
        L-URI: msrp:oeksd@relay.biloxi.com
        R-URI: msrp:kdowsw@relay.biloxi.com:7777


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

        c=IN IP4 relay.biloxi.com
        m=message 8910 msrp/tls text/plain
        a=i-am:oeksd
        a=you-be: kdowsw


   8.   Alice sees that Bob has requested to host instead. However,
        local policy requires her to insist on using the atlanta relay.

   9.   Alice->Bob (SIP): ACK

        c=IN IP4 relay.atlanta.com
        m=message 7777 msrp/tls text/plain
        a=i-am:iau39


   10.  Alice->AtlantaRelay (MSRP):

        MSRP xx SEND
        T-URI: msrp:oeksd@relay.biloxi.com
        TR-ID: 123
        Content-Type: "text/plain"



Campbell, et al.         Expires April 25, 2003                [Page 32]


Internet-Draft             SIMPLE IM Sessions               October 2002


        Hi, I'm Alice!


   11.  AtlantaRelay recognizes it has received a SEND request targeted
        to a foreign domain. AtlantaRelay does a DNS resolution to find
        the relay at relay.biloxi.com, opens a connection to the well
        know port, and forwards the request.

   12.  BiloxiRelay->Bob (MSRP):

        MSRP xx SEND
        T-URI: msrp:oeksd@relay.biloxi.com
        TR-ID: 123
        Content-Type: "text/plain"
        Hi, I'm Alice!


   13.  Bob->BiloxiRelay (MSRP):

        MSRP xx 200 OK
        T-URI: msrp:iau39@relay.atlanta.com
        TR-ID: 123


   14.  BiloxiRelay recognizes it has received a response targeted to a
        foreign domain. BiloxiRelay does a DNS resolution to find the
        relay at relay.atlanta.com, opens a connection to the well know
        port, and forwards the request. Note that BiloxiDomain cannot
        positively determine that it already has a connection _from_
        relay.atlanta.com, as a NAT may obscure the source address on
        the original connection.

   15.  AtlantaRelay->Alice (MSRP):

        MSRP xx 200 OK
        T-URI: msrp:iau39@relay.atlanta.com
        TR-ID: 123


   16.
        Alice->Bob (SIP): BYE

   17.
        Alice->AtlantaRelay (MSRP):

        MSRP xx RELEASE T-URI: msrp:iau39@relay.atlanta.com
        TR-ID: 42




Campbell, et al.         Expires April 25, 2003                [Page 33]


Internet-Draft             SIMPLE IM Sessions               October 2002


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

        MSRP xx 200 OK
        T-URI: msrp:iau39@relay.atlanta.com
        TR-ID: 42


   19.  Bob->BiloxiRelay (MSRP):

        MSRP xx RELEASE
        T-URI: msrp:oeksd@relay.biloxi.com
        TR-ID: 938


   20.  BiloxiRelay->Bob (MSRP):  (relay invalidates session state)

        MSRP xx 200 OK
        T-URI: msrp:oeksd@relay.biloxi.com
        TR-ID: 42


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

   22.  After a locally configured timeout period with no activity,
        AtlantaRelay and BiloxiRelay are free to drop their respective
        connections to each other.


8. Changes introduced in 01 version

   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.

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

9.1 Sensitivity of the Remote URI

   The remote URI of a MSRP session is used by the visiting endpoint to
   identify itself to the hosting device, regardless of whether the



Campbell, et al.         Expires April 25, 2003                [Page 34]


Internet-Draft             SIMPLE IM Sessions               October 2002


   session is directly hosted by the host endpoint, or is hosted by a
   relay. If an attacker were able to aquire the remote-URI, either by
   guessing it or by evedropping, 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 remote URI 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
   remote URI to the visitor and back to the host MUST be protected from
   eavesdroppers and man-in-the-middle attacks. This includes the VISIT
   request itself, as well as SDP exchange mechanism.

   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-to-hop schemes for protection of the SDP exchange.

9.2 End to End Protection of IMs

   Instant messages can contain very sensitive information. As a result,
   as specified in RFC 2779 [4], 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 the
   session key generation mechanism described in MIKEY [5].

9.3 CPIM compatibility

   MSRP sessions may be gatewayed to other CPIM [14]compatible
   protocols. If this occurs, the gateway MUST maintain session state,
   and MUST translate between the MSRP session semantics and CPIM
   semantics that do not include a concept of sessions. Furthermore,
   when one endpoint of the session is a CPIM gateway, instant messages
   SHOULD be wrapped in "message/cpim" [6] 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. IANA Considerations

   MSRP will likely require the IANA registration of an well-known port
   for MSRP relays. Additionally, we may have to register the "i-am" and



Campbell, et al.         Expires April 25, 2003                [Page 35]


Internet-Draft             SIMPLE IM Sessions               October 2002


   "you-be" attributes of the MSRP SDP exchange.

11. Open Issues

   This specification is far from complete, particularly in the areas of
   error handling and security considerations. If the working group
   chooses to fully specify MSRP, additional work is required in those
   areas.

   Further specification of the MSRP URI scheme will also be required.
   For example, this version does not describe URI comparison rules, or
   rules for resolving a URI using the DNS. The concept of an "msrps"
   URI scheme that required the use of TLS on all hops was discussed in
   the design team. This concept is not documented in this version, as
   it is not fully enough developed to include. Such a scheme is likely
   to appear in a future version of this document.

12. Contributors

   The following people contributed substantially to this ongoing
   effort:

                                Rohan Mahy
                                Allison Mankin
                                Jon Peterson
                                Brian Rosen
                                Dean Willis

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]  Campbell, B., "Instant Message Sessions using the CPIM Message
        Format.", draft-campbell-simple-cpimmsg-sessions-00.txt (work in
        progress), October 2002.

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

   [5]  Arkko, J., "MIKEY: Multimedia Internet KEYing",
        draft-ietf-msec-mikey-04 (work in progress), August 2002.

   [6]  Atkins, D. and G. Klyne, "Common Presence and Instant Messaging



Campbell, et al.         Expires April 25, 2003                [Page 36]


Internet-Draft             SIMPLE IM Sessions               October 2002


        Message Format", draft-ietf-impp-cpim-msgfmt-06 (work in
        progress), February 2001.

Informational References

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

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

   [9]   Rosenberg, J. and H. Schulzrinne, "Models for Multi Party
         Conferencing in SIP", draft-ietf-sipping-conferencing-models-01
         (work in progress), July 2002.

   [10]  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-02 (work
         in progress), June 2002.

   [11]  Sparks, R., "SIP Call Control - Transfer",
         draft-ietf-sip-cc-transfer-05 (work in progress), July 2001.

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

   [13]  Peterson, J., "A Privacy Mechanism for the Session Initiation
         Protocol (SIP)", draft-peterson-sip-privacy-longterm-00 (work
         in progress), March 2002.

   [14]  Crocker, D., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne,
         G., Rose, M., Rosenberg, J., Sparks, R., Sugano, H. and J.
         Peterson, "A Common Profile for Instant Messaging (CPIM)",
         draft-ietf-impp-cpim-03 (work in progress), August 2002.


Authors' Addresses

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

   EMail: bcampbell@dynamicsoft.com




Campbell, et al.         Expires April 25, 2003                [Page 37]


Internet-Draft             SIMPLE IM Sessions               October 2002


   Jonathan Rosenberg
   dynamicsoft
   72 Eagle Rock Avenue
   First Floor
   East Hanover, NJ  07936

   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: pkzivat@cisco.com


























Campbell, et al.         Expires April 25, 2003                [Page 38]


Internet-Draft             SIMPLE IM Sessions               October 2002


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 (2002). 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



Campbell, et al.         Expires April 25, 2003                [Page 39]


Internet-Draft             SIMPLE IM Sessions               October 2002


   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.











































Campbell, et al.         Expires April 25, 2003                [Page 40]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/