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

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 RFC 4975

SIMPLE Working Group                                   B. Campbell (Ed.)
Internet-Draft                                               dynamicsoft
Expires: November 15, 2004                                  May 17, 2004


                   The Message Session Relay Protocol
                 draft-ietf-simple-message-sessions-06

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 15, 2004.

Copyright Notice

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

Abstract

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










Campbell (Ed.)         Expires November 15, 2004                [Page 1]

Internet-Draft                    MSRP                          May 2004


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.   Motivation for Session-mode Messaging  . . . . . . . . . . .   4
   3.   Scope of this Document . . . . . . . . . . . . . . . . . . .   5
   4.   Protocol Overview  . . . . . . . . . . . . . . . . . . . . .   6
   5.   SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . .   7
     5.1  Use of the SDP M-line  . . . . . . . . . . . . . . . . . .   7
     5.2  The Accept Types Attribute . . . . . . . . . . . . . . . .   7
     5.3  MIME Wrappers  . . . . . . . . . . . . . . . . . . . . . .   8
     5.4  URL Negotiations . . . . . . . . . . . . . . . . . . . . .   9
     5.5  Path Attributes with Multiple URLs . . . . . . . . . . . .  10
     5.6  Updated SDP Offers . . . . . . . . . . . . . . . . . . . .  11
     5.7  Example SDP Exchange . . . . . . . . . . . . . . . . . . .  11
     5.8  Connection Negotiation . . . . . . . . . . . . . . . . . .  12
   6.   The Message Session Relay Protocol . . . . . . . . . . . . .  12
     6.1  MSRP URLs  . . . . . . . . . . . . . . . . . . . . . . . .  12
       6.1.1  MSRP URL Comparison  . . . . . . . . . . . . . . . . .  13
       6.1.2  Resolving MSRP Host Device . . . . . . . . . . . . . .  14
     6.2  Connection Direction . . . . . . . . . . . . . . . . . . .  14
     6.3  MSRP Messages  . . . . . . . . . . . . . . . . . . . . . .  15
       6.3.1  Message Framing  . . . . . . . . . . . . . . . . . . .  17
       6.3.2  Message Examples . . . . . . . . . . . . . . . . . . .  18
     6.4  MSRP Transactions  . . . . . . . . . . . . . . . . . . . .  19
     6.5  MSRP Sessions  . . . . . . . . . . . . . . . . . . . . . .  19
       6.5.1  Initiating an MSRP session . . . . . . . . . . . . . .  19
       6.5.2  Handling the initial request . . . . . . . . . . . . .  21
       6.5.3  Sending Instant Messages on a Session  . . . . . . . .  21
       6.5.4  Ending a Session . . . . . . . . . . . . . . . . . . .  23
       6.5.5  Managing Session State and Connections . . . . . . . .  23
     6.6  Delivery Status Notification . . . . . . . . . . . . . . .  24
       6.6.1  Endpoint DSN Request . . . . . . . . . . . . . . . . .  24
       6.6.2  DSN generation . . . . . . . . . . . . . . . . . . . .  25
       6.6.3  Receiving positive DSN . . . . . . . . . . . . . . . .  26
       6.6.4  Receiving negative DSN . . . . . . . . . . . . . . . .  26
       6.6.5  DSN headers in MSRP  . . . . . . . . . . . . . . . . .  26
     6.7  Message Fragmentation  . . . . . . . . . . . . . . . . . .  28
       6.7.1  MSRP Usage of message/byteranges . . . . . . . . . . .  28
     6.8  Method Descriptions  . . . . . . . . . . . . . . . . . . .  29
       6.8.1  SEND . . . . . . . . . . . . . . . . . . . . . . . . .  29
       6.8.2  VISIT  . . . . . . . . . . . . . . . . . . . . . . . .  29
       6.8.3  REPORT . . . . . . . . . . . . . . . . . . . . . . . .  30
     6.9  Response Code Descriptions . . . . . . . . . . . . . . . .  30
       6.9.1  200  . . . . . . . . . . . . . . . . . . . . . . . . .  30
       6.9.2  400  . . . . . . . . . . . . . . . . . . . . . . . . .  30
       6.9.3  415  . . . . . . . . . . . . . . . . . . . . . . . . .  30
       6.9.4  426  . . . . . . . . . . . . . . . . . . . . . . . . .  30
       6.9.5  481  . . . . . . . . . . . . . . . . . . . . . . . . .  30



Campbell (Ed.)         Expires November 15, 2004                [Page 2]

Internet-Draft                    MSRP                          May 2004


       6.9.6  506  . . . . . . . . . . . . . . . . . . . . . . . . .  30
     6.10   Header Field Descriptions  . . . . . . . . . . . . . . .  30
       6.10.1   TR-ID  . . . . . . . . . . . . . . . . . . . . . . .  31
       6.10.2   Message-ID . . . . . . . . . . . . . . . . . . . . .  31
       6.10.3   To-Path  . . . . . . . . . . . . . . . . . . . . . .  31
       6.10.4   From-Path  . . . . . . . . . . . . . . . . . . . . .  31
       6.10.5   Boundary . . . . . . . . . . . . . . . . . . . . . .  31
       6.10.6   Closing  . . . . . . . . . . . . . . . . . . . . . .  31
       6.10.7   Content-Type . . . . . . . . . . . . . . . . . . . .  32
   7.   Example  . . . . . . . . . . . . . . . . . . . . . . . . . .  32
   8.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  34
     8.1  MSRP Port  . . . . . . . . . . . . . . . . . . . . . . . .  34
     8.2  MSRP URL Schema  . . . . . . . . . . . . . . . . . . . . .  34
       8.2.1  Syntax . . . . . . . . . . . . . . . . . . . . . . . .  34
       8.2.2  Character Encoding . . . . . . . . . . . . . . . . . .  34
       8.2.3  Intended Usage . . . . . . . . . . . . . . . . . . . .  35
       8.2.4  Protocols  . . . . . . . . . . . . . . . . . . . . . .  35
       8.2.5  Security Considerations  . . . . . . . . . . . . . . .  35
       8.2.6  Relevant Publications  . . . . . . . . . . . . . . . .  35
     8.3  SDP Parameters . . . . . . . . . . . . . . . . . . . . . .  35
       8.3.1  Accept Types . . . . . . . . . . . . . . . . . . . . .  35
       8.3.2  Wrapped Types  . . . . . . . . . . . . . . . . . . . .  35
       8.3.3  Path . . . . . . . . . . . . . . . . . . . . . . . . .  35
     8.4  IANA registration forms for DSN types  . . . . . . . . . .  36
       8.4.1  IANA registration form for address-type  . . . . . . .  36
       8.4.2  IANA registration form for MTA-name-type . . . . . . .  36
   9.   Security Considerations  . . . . . . . . . . . . . . . . . .  36
     9.1  TLS and the MSRPS Scheme . . . . . . . . . . . . . . . . .  36
       9.1.1  Sensitivity of Session URLs  . . . . . . . . . . . . .  37
       9.1.2  End to End Protection of IMs . . . . . . . . . . . . .  38
       9.1.3  CPIM compatibility . . . . . . . . . . . . . . . . . .  38
       9.1.4  PKI Considerations . . . . . . . . . . . . . . . . . .  38
   10.  Changes from Previous Draft Versions . . . . . . . . . . . .  39
     10.1   draft-ietf-simple-message-sessions-06  . . . . . . . . .  39
     10.2   draft-ietf-simple-message-sessions-05  . . . . . . . . .  39
     10.3   draft-ietf-simple-message-sessions-04  . . . . . . . . .  40
     10.4   draft-ietf-simple-message-sessions-03  . . . . . . . . .  40
     10.5   draft-ietf-simple-message-sessions-02  . . . . . . . . .  40
     10.6   draft-ietf-simple-message-sessions-01  . . . . . . . . .  41
     10.7   draft-ietf-simple-message-sessions-00  . . . . . . . . .  41
     10.8   draft-campbell-simple-im-sessions-01 . . . . . . . . . .  42
   11.  Contributors . . . . . . . . . . . . . . . . . . . . . . . .  42
   12.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  42
   13.  References . . . . . . . . . . . . . . . . . . . . . . . . .  42
   13.1   Normative References . . . . . . . . . . . . . . . . . . .  42
   13.2   Informational References . . . . . . . . . . . . . . . . .  43
        Author's Address . . . . . . . . . . . . . . . . . . . . . .  44
        Intellectual Property and Copyright Statements . . . . . . .  45



Campbell (Ed.)         Expires November 15, 2004                [Page 3]

Internet-Draft                    MSRP                          May 2004


1.  Introduction

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

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

   One of the primary purposes of SIP and SDP (Section 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
   MSRP session.

2.  Motivation for Session-mode Messaging

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

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

   Due to network congestion concerns, the MESSAGE method has



Campbell (Ed.)         Expires November 15, 2004                [Page 4]

Internet-Draft                    MSRP                          May 2004


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

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

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

   Finally, SIP devices can treat message sessions like any other media
   sessions.  Any SIP feature that can be applied to other sorts of
   media sessions can equally apply to message sessions.  For example,
   conferencing [14], third party call control [15], call transfer [16],
   QoS integration [17], and privacy [18] 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.  It does
   not specify the use of intermediaries, nor does it prohibit such use.
   We expect an extension to this specification to define MSRP
   intermediaries and their use.

   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.



Campbell (Ed.)         Expires November 15, 2004                [Page 5]

Internet-Draft                    MSRP                          May 2004


4.  Protocol Overview

   The Message Session Relay Protocol (MSRP) provides a mechanism for
   transporting session-mode messages between endpoints.  MSRP uses
   connection oriented, reliable network transport protocols only.  It
   can operate in the presence of many NAT and firewall environments, as
   it allows participants to positively associate message sessions with
   specific connections, and does not depend upon connection source
   address, which may be obscured by NATs.

   MSRP uses the following primitives:

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

   VISIT: Used by an endpoint to establish a session association to the
      host endpoint.

   REPORT Used to carry MSRP message report/receipt information.

   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.  This URL is temporary, and must
   not duplicate any URL that A has offered for other active sessions.

   B then responds to the invitation with a URL of its own.  This
   informs A that B has accepted the session, and will accept messages
   at that URL.  A connects to B, and sends a request to establish the
   session.  A and B may now exchange messages using SEND requests on
   the connection.  Each party targets such requests to the peer's URL.

   When either party wishes to end the session, it informs its peer
   using the appropriate mechanism of the chosen signaling protocol,
   such as a SIP BYE request.

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

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






Campbell (Ed.)         Expires November 15, 2004                [Page 6]

Internet-Draft                    MSRP                          May 2004


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 the
   Session Initiation Protocol (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 port field is normally not
   used, and MAY be set to any value chosen by the endpoint.  A port
   field value of zero has the standard SDP meaning.  Non-zero values
   MUST not be repeated in other MSRP m-lines in the same SDP document.

   The protocol field is used only to designate MSRP.  The underlying
   transport protocol is determined in the MSRP URL, as described below.
   Therefore, the protocol field MUST take the value of "msrp".

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

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

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

      m=message 9999 msrp *

5.2  The Accept Types Attribute

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



Campbell (Ed.)         Expires November 15, 2004                [Page 7]

Internet-Draft                    MSRP                          May 2004


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

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

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

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

5.3  MIME Wrappers

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

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

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

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



Campbell (Ed.)         Expires November 15, 2004                [Page 8]

Internet-Draft                    MSRP                          May 2004


   bodies, format entries from the m-line SHOULD NOT be repeated in this
   attribute.

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

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

5.4  URL Negotiations

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

   a=path ":" MSRP_URL *(SP MSRP_URL)

   where MSRP_URL is an MSRP or MSRPS URL as defined in Section 6.1.
   MSRP URLs included in an SDP offer or answer MUST include an explicit
   port number.

   A device uses the URL to determine a host address and port when
   connecting, and to identify the target when sending messages.  For
   MSRP sessions, the address field in the C-line is not relevant, and
   MUST be ignored.  The port field in the M-line MUST be ignored if
   non-zero.  Zero values have the usual meaning for SDP.

   A device will further use the URL to determine the transport
   protocol, and whether to use TLS.  This information is encoded in the
   URL scheme.

   Both offerer and answerer store the path values received from the
   peer.  For a given endpoint, the local URL is the URL that the
   endpoint put into a SDP path attribute to represent itself.  The peer
   URL is the URL sent by the peer to represent itself.  If the path
   attribute received from the peer contains more than one URL, then the
   peer URL is the rightmost, while the leftmost entry represents the



Campbell (Ed.)         Expires November 15, 2004                [Page 9]

Internet-Draft                    MSRP                          May 2004


   adjacent hop.  If only one entry is present, then it is both the peer
   and adjacent URL.  The remote path is the entire path attribute value
   received from the peer.

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

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

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


5.5  Path Attributes with Multiple URLs

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

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

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

   While endpoints that implement only this specification will never
   introduce a relay, they will need to be able to interoperate with



Campbell (Ed.)         Expires November 15, 2004               [Page 10]

Internet-Draft                    MSRP                          May 2004


   other endpoints that do use relays.  Therefore, they MUST be prepared
   to receive more than one URL in the SDP path attribute.  When an
   endpoint receives more than one URL in a path header, only the first
   entry is relevant for purposes of resolving the address and port, and
   establishing the network connection, as it describes the first
   adjacent hop.

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

5.6  Updated SDP Offers

   To do: Revisit this section based on new connection management rules

   MSRP endpoints may sometimes need to send additional SDP exchanges
   for an existing session.  They may need to send periodic exchanges
   with no change to refresh state in the network, for example, SIP
   timers.  They may need to change some other stream in a session
   without affecting the MSRP stream, or they may need to change an MSRP
   stream without affecting some other stream.

   If either party wish to send an SDP document that changes nothing at
   all, then it MUST have the same o-line version as in the previous
   exchange.

5.7  Example SDP Exchange

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

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

   B responds with its own URL:

                     v=0
                     o=userb 2890844530 2890844532 IN IP4 bob.example.com
                     s=
                     c=IN IP4 dontlookhere
                     t=0 0
                     m=message 9999 msrp *



Campbell (Ed.)         Expires November 15, 2004               [Page 11]

Internet-Draft                    MSRP                          May 2004


                     a=accept-types:message/cpim text/plain
                     a=path:msrp://bob.example.com:8493/si438ds

   A immediately sends some MSRP traffic: Either a VISIT request (if it
   has no immediate content to send) or a SEND request (if it does have
   immediate content.) Afterwards, A and B may now exchange IMs by
   executing SEND transactions.

5.8  Connection Negotiation

   Previous versions of this document included a mechanism to negotiate
   the direction for any required TCP connection.  The mechanism was
   loosely based on COMEDIA [20]work being done in the MMUSIC working
   group.  The primary motivation was to allow MSRP sessions to succeed
   in situations where the offerer could not accept connections but the
   answerer could.  For example, the offerer might be behind a NAT,
   while the answerer might have a globally routable address.

   The SIMPLE working group chose to remove that mechanism from MSRP, as
   it added a great deal of complexity to connection management.
   Instead, MSRP now specifies default connection directions.

6.  The Message Session Relay Protocol

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

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

6.1  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-scheme "://" [userinfo "@"] hostport ["/"
      resource]
      msrp-scheme = "msrp" / "msrps" / "smsrp" / "smsrps"
      resource = 1*unreserved

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

   An MSRP URL server part identifies a participant in an MSRP session.
   If the server part contains a numeric IP address, it MUST also



Campbell (Ed.)         Expires November 15, 2004               [Page 12]

Internet-Draft                    MSRP                          May 2004


   contain a port.  The resource part identifies a particular session
   the participant.  The absence of the resource part indicates a
   reference to an MSRP host device, but does not specifically refer to
   a particular session resource.

   The underlying transport protocol and the protection level (that is,
   whether TLS is used) is determined by the URL scheme:

   msrp MSRP over TCP without TLS.
   msrps MSRP over TCP with TLS.
   smsrp MSRP over SCTP without TLS.
   smsrps MSRP over SCTP with TLS.

      This document only describes the binding for MSRP over TCP.  The
      schema for SCTP are reserved herein, but binding MSRP to SCTP is
      out of scope for this document.

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

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

   The following is an example of a typical MSRP URL:

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

6.1.1  MSRP URL Comparison

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

   1.  The schema must match exactly.

   2.  The host part is compared as case insensitive.

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



Campbell (Ed.)         Expires November 15, 2004               [Page 13]

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

   5.  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.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 a connection attempt fails, the device SHOULD attempt to connect
   to the addresses returned in any additional A or AAAA records, in the
   order the records were presented.

      This process assumes that the connection port is always known
      prior to resolution.  This is always true for the MSRP URL uses
      described in this document, that is, URLs always created and
      consumed by automata, rather than by humans.  The introduction of
      relays may create situations where this is not the case.  For
      example, the MSRP URL that a user enters into a client to
      configure it to use a relay may be intended to be easily
      remembered and communicated by humans, and therefore is likely to
      omit the port.  Therefore, the relay specification may describe
      additional steps to resolve the port number.

6.2  Connection Direction

   When SIP is used as the signaling protocol, the device sending the
   initial request to communicate is responsible for opening the
   connection.  In most cases, the device sends an offer in an INVITE or
   UPDATE request, and gets a response in a 2xx or 18x response.  In
   this case, the inviter opens a connection after receiving the
   response.  This can be done in parallel to sending an ACK request.

   Another, less common scenario is when the inviter sends an INVITE
   request with no offer, and the invitee sends an offer in the
   response.  In this case, the inviter opens the connection after it
   receives the offer.  It waits for successful connection prior to
   sending the answer in the SIP ACK request.



Campbell (Ed.)         Expires November 15, 2004               [Page 14]

Internet-Draft                    MSRP                          May 2004


      Open Issue: The delayed offer is not likely to work in SIP, as the
      invitee is almost certainly to propose RTP rather than MSRP.  We
      either need to do more work to specify how an endpoint that
      supports both handles a delayed offer, or remove any reference to
      this.

   Other signaling protocols may use other approaches.  Unless specific
   behavior is specified for a particular signaling protocol, the
   offerer is always responsible for opening the connection.
      Open Issue: Should we put in a hook to allow SDP extensions to be
      used to determine connection direction? For example, if COMEDIA
      evolves to a point where it is workable for MSRP, why not allow
      using it?

   In all cases, the connecting endpoint connects to the device and port
   indicated by the connection URL, using the protocol and protection
   level specified by the URL scheme.  If it determines that it already
   has a connection  associated with a URL that has a matching scheme,
   host part, and port, it SHOULD reuse that connection rather than
   opening a new one.  Once a connection has succeeded, or the decision
   to reuse a connection has been made, the connecting device MUST
   immediately send an MSRP request in the context of the new session.
   This message allows the device accepting the connection to associate
   the MSRP session with the connection.  This MAY be a SEND request, if
   the device has content to send immediately, or a VISIT request.

      Open Issue: We are still discussing whether the offerer or the
      answerer should be responsible for connecting.

   Either endpoint MAY tear down a connection when it no longer has any
   active or proposed sessions associated with the connection.

6.3  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] Closing
       request-start  = "MSRP" SP Method CRLF
       response-start = "MSRP" SP Status-Code SP
                                Reason CRLF

       Method       = SEND / VISIT / other-method
       other-method = 1*(ALPHA)



Campbell (Ed.)         Expires November 15, 2004               [Page 15]

Internet-Draft                    MSRP                          May 2004


       header       = Tran-ID / Message-ID/ Session-URL / Content-Types /
                      From-Path / To-Path / Message-Receipt / Receipt-ID /
                      Byte-Range / Boundary

       Status-Code  = 200    ;Success
                    / 400    ;Bad Request
                    / 403    ;Forbidden
                    / 415    ;Unsupported Content Type
                    / 426    ;Upgrade Required
                    / 481    ;No session
                    / 506    ;duplicate session
                    / other-status  ; extension codes
       other-status = 3(NUM)


       Reason       = token ; Human readable text describing status
       Tran-ID      = "Tr-ID" ":" token
       Message-ID   = "Message-ID" ":" token

       Boundary     = "Boundary" ":" 0*65(bchars) bcharsnospace
       bcharsnospace= DIGIT / ALPHA / "'" / "(" / ")" /
                         "+" / "_" / "," / "-" / "." /
                         "/" / ":" / "=" / "?"
       bchars       = bcharsnospace / " "

       Closing        = "-------" Boundary Continue-Flag CRLF ; Boundary must match Boundary header field value
       Continue-Flag = "+" / "$"

       Content-Type = "Content-Type" ":" media-type
       media-type   = type "/" subtype *( ";" parameter )
       type         = token
       subtype      = token
       parameter    = attribute "=" value
       attribute    = token
       value        = token | quoted-string

       To-Path                 = "To-Path" ":" msrp_url *(SP msrp_url)
       From-Path               = "From-Path" ":" msrp_url *(SP msrp_url)

       Message-Receipt = "Message-Receipt" ":" message-receipt-spec ( SEMI receipt-type )
       message-receipt-spec     = "negative" / "none" / "all"
       receipt-type    = "receipt-type" "=" media-type; <media-type> is detailed in [RFC3261]

       Byte-Range      = "Byte-Range" ":" byte-range-spec
       byte-range-spec  = first-byte "-" last-byte
       first-byte      = 1*DIGIT
       last-byte       = 1*DIGIT




Campbell (Ed.)         Expires November 15, 2004               [Page 16]

Internet-Draft                    MSRP                          May 2004


       Receipt-ID               = "Receipt-ID" ":" token


   All requests and responses MUST contain at least a TR-ID header
   field.  All requests must also contain the To-Path and From-Path,
   Message-ID, and Boundary header fields, as well as the Closing field.
   Messages MAY contain other fields, depending on the method or
   response code.

6.3.1  Message Framing

   MSRP messages are framed using the Boundary header field value.  The
   Boundary header field contains a boundary string.  The Closing field
   contains the same boundary string with a prefix of "-------" (seven
   hyphens) and single character suffix representing a continuation
   flag.

   The closing field is constructed to allow for simple high speed
   parsing.  The use of seven hyphens forces for of them to be aligned
   on a 32 bit boundary.  A parser can quickly scan for the closing by
   looking for a 32 bit value equivalent to "----".  Once this word is
   found, the scanner can carefully check and see if this is the
   boundary it is looking for or just some random data.  The boundary
   string SHOULD have at least 16 bits of randomness in it.  For
   example, a valid boundary would be "Boundary:6ea7" where the 6ea7 was
   a randomly chosen four digit hexadecimal number.  This reduces the
   chance of the boundary string colliding with content data.

   The boundary string MUST NOT occur inside the body itself.  The
   sender MUST ensure that a collision does not occur.

      Since the message fragmentation section (Section 6.7) of this
      document says that large content should be sent in parcels, it
      should always be possible to check for boundary collisions prior
      to sending a parcel.  Even in the case of streaming content, where
      the sender does not have all of the content prior to sending the
      first message, the chunk size should be small enough so that it is
      practical to check each chunk for collisions prior to sending.

   The MSRP boundary strings are distinct and independent from any MIME
   boundaries that may exist in the message body.  For example, if the
   body is of a multipart type, the MIME headers will include a
   multipart boundary.  This multipart boundary MUST NOT be the same
   string used in the MSRP Boundary header field.

   The Closing field contains both the message boundary string and the
   Continuation-Flag.  The Continuation-Flag indicates whether the
   entire content has been sent or not.  Normally, the flag takes the



Campbell (Ed.)         Expires November 15, 2004               [Page 17]

Internet-Draft                    MSRP                          May 2004


   value of "$" (dollar sign) to indicate that all content has been
   sent, or "+" to indicate that there is additional content that has
   not yet been sent.

   The term "content" in this context means a complete logical instant
   message, from the perspective of the user.  The content could be a
   short text message, a long file transfer, etc.  The logical instant
   message does not necessarily correspond one-to-one with a physical
   MSRP message.  For example, a video message may be one logical
   instant message from the users' perspective, but it will generally be
   sent as a series of parcels.  Each parcel would be sent as the
   payload in one physical MSRP SEND request.  All the requests except
   the final one would contain "+" in the continuation-flag to indicate
   that the content is not complete.  The final message would contain
   "$" to indicate that complete content has been sent.

   The sender MUST NOT include a completion-flag of "+" if the payload
   MIME type does not support content fragmentation.

6.3.2  Message Examples

   The following is an example MSRP message sending a text payload:

   MSRP SEND
   Boundary: dkei38sd
   To-Path:msrp://alice.atlanta.com:7777/iau39
   From-Path:msrp://bob.atlanta.com:8888/9di4ea
   TR-ID: 456
   Message-ID: 456
   Content-Type: "text/plain"

   Hi, Alice! I'm Bob!
   -------dkei38sd$


   The following is an example of an MSRP message containing a MIME type
   that uses an internal boundary (not to be confused with the MSRP
   boundary):

   MSRP SEND
   Boundary:a38sdo To-Path:msrp://bob.atlanta.com:8888/9di4ea
   From-Path:msrp:alice.atlanta.com:7777/iau39
   TR-ID: 456
   Message-ID: 456
   Content-Type: multipart/byteranges;boundary=abcde

   --abcde
   Content-Type: image/jpeg



Campbell (Ed.)         Expires November 15, 2004               [Page 18]

Internet-Draft                    MSRP                          May 2004


   Content-range: bytes 0-*/50270
   [large jpg file]
   --abcde--
   -------a38sdo$

6.4  MSRP Transactions

   An MSRP transaction consists of exactly one request and one response.
   A response matches a transaction if the following are true:

      It shares the same TR-ID value.
      It is received on the same connection on which the request was
      sent.
      The To-Path has a single entry, which matches the response
      recipient's local URI for the session.

   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 timeout interval SHOULD be 30 seconds, but other values may be
   established as a matter of local policy.

6.5  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,
   identified by MSRP URLs.

6.5.1  Initiating an MSRP session

   When an endpoint wishes to engage a peer 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.

   Under normal circumstances, the  answerer MUST be prepared to accept
   a connection from the offerer.




Campbell (Ed.)         Expires November 15, 2004               [Page 19]

Internet-Draft                    MSRP                          May 2004


   The offerer MUST perform the following steps:

   1.  Construct a MSRP URL to serve as the local URL.

   2.  Construct an SDP offer as described in Section 5, including the
       list of allowed IM payload formats in the accept-types attribute.
       The offerer puts its local URL into the path attribute, as
       described in Section 5.4.  This URL becomes the offerer's local
       path.

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

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

   1.  Store the contents of the offered sdp path attribute as the
       remote path for he session.

   2.  Construct a MSRP URL that resolves to itself.  Save this as the
       local URL for the session.

   3.  Listen for a connection on the transport, address, and port
       described by the local URL.

   4.  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 accept-types attribute contains the SEND payload media
           types that the answerer is willing to accept.  The
           accept-types attribute in the answer MUST be either the same
           as that of the offer, or a subset.

       3.  The path attribute contains the answerer's local URL.

      Again, this document assumes that no relays are introduced.  If
      the answerer were to introduce one or more relay, it would add the
      appropriate URLs to the path attribute in the SDP answer.  It
      would not need to listen for a connection, as the first relay in
      its path would have that honor.

   When the offerer receives the answer, it MUST perform the following
   steps:

   1.  Save the path attribute contents from the SDP answer as the
       remote path.



Campbell (Ed.)         Expires November 15, 2004               [Page 20]

   2.  Designate the first entry in the remote path as the adjacent-hop
       URL.

   3.  Check to see if a connection already exists that is associated
       with URL that matches the scheme, host part, and port of the
       adjacent-hop URL.  If such a connection exists, the device SHOULD
       reuse it, rather than opening a new connection.

   4.  If no matching connection exists, attempt to open a connection to
       the adjacent hop using the transport, address, port, and
       protection mode designated by the adjacent-hop URL.

   5.  If the connection succeeds, or if a connection is reused,
       immediately send a MSRP request to the opposite peer.  This
       SHOULD be a visit request, but MAY be a SEND request if the
       endpoint has legitimate content to send.

6.5.2  Handling the initial request

   An MSRP device that accepts a network connection will receive an
   immediate MSRP request from the connecting endpoint.  This may be a
   SEND or VISIT request.  When an endpoint receives such a request, it
   MUST perform the following procedures:

   1.  Check if state exists for a session with a local URL that matches
       the To-Path header field value of the VISIT request.  If so, and
       if no previous request has been received for that URL on a
       different connection, then return a 200 response, and save state
       associating the first URL in the From-Path header field with the
       connection on which the request was received .

   2.  If the state exists, and a matching request has occurred on a
       different connection, return a 506 response and do not change
       session state in any way.

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

6.5.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 a To-Path header field containing the path to the opposite
       endpoint, in order from left to right.

   2.  Insert a From-Path header field containing the local URL.




Campbell (Ed.)         Expires November 15, 2004               [Page 21]

Internet-Draft                    MSRP                          May 2004


   3.  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
       "*" was present in the accept-types attribute, then the media
       type SHOULD match one of the explicitly listed entries, but MAY
       be any other arbitrary value.

   4.  Set the TR-ID and Message-ID header fields to a unique value.
       The sender MAY set these fields to the same value.

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

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

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

   8.  If any other response code is received, or if the transaction
       times out, the endpoint SHOULD assume the session has failed,
       either tear down the session, or attempt to re-establish the
       session by sending an updated SDP offer proposing a new
       connection.  If a new connection is established, the endpoint MAY
       choose to resend the content on the new connection.

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

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

   1.  Check that it has state for a session with a local URL matching
       the To-Path value.  If no matching session exists, return a 481
       response.

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

   3.  If it does, return a 200 response and render the message to the
       user.  The method of rendering is a matter of local policy.  If
       the message contained no body at all, the endpoint should quietly
       ignore it.



Campbell (Ed.)         Expires November 15, 2004               [Page 22]

   4.  If it does not understand the media type, return a 415 response.
       The endpoint MUST NOT return a 415 response for any media type
       for which it indicated support in the SDP exchange.

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

   Each peer MUST destroy all local state for the session.  This
   involves completely removing the state entry for the session and
   invalidating the session URL.

   If no other sessions are using the connection, the endpoint that
   opened it SHOULD tear it down.  However, the passive party MAY tear
   down an unused connection after a locally configured timeout period.

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

   When an endpoint is signaled of its peer's intent to close a session,
   it SHOULD NOT initiate any more SEND requests.  It SHOULD wait for
   any outstanding transactions that it initiated to complete, and it
   SHOULD attempt respond to any open SEND transactions received prior
   to being signaled.

   It is not possible to completely eliminate the chance of a session
   terminating with incomplete SEND transactions.  When this occurs, the
   endpoint SHOULD clearly inform the user that the messages may not
   have been delivered.

6.5.5  Managing Session State and Connections

   A MSRP session is represented by state at each endpoint, identified
   by the local URL and remote path.  An active session also has an
   associated network connection.

   If the connection fails for any reason, the device MUST invalidate
   the session state for all sessions using the connection.  Once a



Campbell (Ed.)         Expires November 15, 2004               [Page 23]

Internet-Draft                    MSRP                          May 2004


   connection is dropped, any associated session state MUST NOT be
   reused.  If an endpoint wishes to continue to communicate after
   detecting a connection failure, it MAY initiate a new SDP exchange to
   negotiate a new session URL.  Otherwise, it SHOULD attempt to tear
   down the session using the rules of the signaling protocol.

      It would be nice to allow sessions to be recovered after a
      connection failure, perhaps by allowing the active endpoint to
      reconnect, and send a new VISIT request.  However, this approach
      creates a race condition between the time that the hosting device
      notices the failed connection, and the time that the endpoint
      tries to recover the session.  If the endpoint attempts to
      reconnect prior to the hosting device noticing the failure, the
      hosting device will interpret the recovery attempt as a conflict.
      The only way around this would be to force the hosting device to
      do a liveness check on the original connection, which would create
      a lot of complexity and overhead that do not seem to be worth the
      trouble.

6.6  Delivery Status Notification

   Delivery Status Notification (DSN)[10] provides an extensible MIME
   content-type that is used to convey both positive and negative status
   of messages in the network.  This functionality is extremely useful
   for MSRP sessions that traverse a relay device.  Relay support is
   considered out of scope for this specification and will be included
   in a separate specification.  This section will only cover
   functionality required by non-relay aware endpoints for basic MSRP
   operation.  An MSRP endpoint MUST be capable of performing the DSN
   operations described in this specification and SHOULD support the DSN
   MIME type outlined.  An MSRP endpoint MAY use an alternative payload
   for reporting message status using the procedures outlined in this
   specification.

6.6.1  Endpoint DSN Request

   An endpoint that wishes to be informed of message delivery/failure
   needs to request such information.  This is achieved by including an
   MSRP Receipt-Request header in the request.  The header can equal one
   of three values:

   negative:  Indicates the client only requires failure delivery
      report.
    none:  Indicates the client requires no delivery reports.
   all:  Indicates the client requires both positive and negative
      delivery reports.

   Within the scope of this specification the Receipt-Request header is



Campbell (Ed.)         Expires November 15, 2004               [Page 24]

Internet-Draft                    MSRP                          May 2004


   only used in MSRP SEND requests.  Future extensions to this
   specification MAY use the mechanism described in this document for
   delivery/failure status notification of other MSRP requests.

   The default value for this header if not present in a request is
   'negative'.  An example of this header would be:

      Message-Receipt: negative

   The default DSN MIME type is detailed in RFC 1894[10].  It is
   possible for MSRP endpoints to use a different format if required.
   This can be achieved by including a 'receipt-type' parameter in the
   Message-Receipt header.  This parameter contains the alternative MIME
   type that SHOULD be used for this particular receipt transaction.  A
   client specifying an alternative 'receipt-type' for an MSRP
   transaction MUST also be capable of receiving the default format
   specified in this document.  This allows intermediaries, such as MSRP
   relays, to generate failure reports when MSRP transaction failure
   occurs.

6.6.2  DSN generation

   An MSRP endpoint implementing this specification SHOULD be able to
   generate positive delivery status of MSRP requests.  On receiving an
   MSRP request containing a Message-Receipt header with a value of
   'all', the endpoint will carry out normal MSRP response generation
   and MUST generate an MSRP REPORT request using the following
   procedures:

   1.  Insert a To header containing the From value from the original
       request.
   2.  Insert a From header containing the To value from the original
       request.
   3.  Insert the message status payload in the body of the request.  If
       the default DSN MIME type from DSN[10] is used then the MSRP
       Content-Type header MUST use the value multipart/report.  The
       relevance of DSN headers in MSRP can be found in section 7.6.5.
       An alternative MIME type MAY be used but MUST be specified in the
       Content-Type header.  Negative DSN generation is considered out
       of the scope of this document and will be covered in a separate
       MSRP relay document.
   4.  Insert a new transaction ID (TR-ID).
   5.  (Optional) Insert an MSRP Byte-Range header containing the value
       from 'multipart/byteranges' MIME header Content-range from the
       payload of a chunked message.  It is possible that an entity
       downstream may decide to break up an MSRP SEND message and send
       it in separate chunks.  The originating client would be
       transparent to this operation but would need to be informed if a



Campbell (Ed.)         Expires November 15, 2004               [Page 25]

Internet-Draft                    MSRP                          May 2004


       DSN only represents part of the request.

6.6.3  Receiving positive DSN

   An MSRP endpoint implementing this specification MUST be able to
   receive positive delivery status of MSRP requests.

6.6.4  Receiving negative DSN

   An MSRP endpoint implementing this specification MUST be able to
   receive negative delivery status of MSRP requests.

6.6.5  DSN headers in MSRP

   The format of a default DSN report is taken from RFC 1894[10].  Only
   a minimal subset of fields are used, as detailed in the remainder of
   this section.

6.6.5.1  Per-Message DSN header usage

   original-envelope-id: See Section 6.6.5.3

   reporting-mta:       See Section 6.6.5.4

   dsn-gateway: Not Used

   received-from-mta: Not Used

   arrival-date: Not Used

6.6.5.2  Per-Recipient DSN header usage

   original-recipient           Not Used

   final-recipient: See Section 6.6.5.5

   action: See Section 6.6.5.6

   status: See Section 6.6.5.7

   remote-mta: Not Used

   diagnostic-code: Not Used

   last-attempt-date: Not Used

   will-retry-until:Not Used




Campbell (Ed.)         Expires November 15, 2004               [Page 26]

Internet-Draft                    MSRP                          May 2004


6.6.5.3  original-envelope-id usage

   The 'original-envelope-id' field contains a unique identifier which
   is used to correlate a DSN report with the originating MSRP
   transaction.  The entity generating the DSN report MUST insert the
   Message-ID value that appeared in the original MSRP request into the
   'original-envelope-id' field.  This allows a requesting client to
   explicitly correlate a REPORT request with the original request.
   This correlation is implementation specific and makes no requirements
   on clients to hold state for transactions ID's.  Information
   regarding the original request can be obtained from the DSN MIME type
   outlined in [10].

6.6.5.4  reporting-mta

   The 'reporting-mta-field' MUST follow the guidelines set out in RFC
   1894[10].  The 'mta-name-type' from RFC1894[10] MUST use the value of
   'msrp-name-type', as defined in section 9 of this specification.  The
   'mta-name' value for this field as specified in RFC1894 [10] MUST
   equal an MSRP URL representing itself.

6.6.5.5  final-recipient

   The 'final-recipient-field' MUST follow the guidelines set out in RFC
   1894[10].  The 'address-type' from RFC1894 [10] MUST use the value of
   'msrp-address-type', as defined in section 9 of this specification.
   The 'address-type' value for this field as specified in RFC1894 [10]
   MUST equal the value contained in the MSRP 'To' header from the
   original request being reported on.

6.6.5.6  action

   The 'action' field MUST follow the guidelines set out in RFC
   1894[10].  An MSRP entity constructing a DSN report MUST use the
   'delivered' value for a successful delivery and MUST use the 'failed'
   value for an un-successful delivery.  The other values specified for
   the 'action' field in RFC 1894[10] MAY be used.

6.6.5.7  status

   The 'status' field MUST follow the guidelines set out in RFC
   1894[10].  An MSRP entity constructing a DSN report MUST represent
   the MSRP status code in the correct format detailed in RFC 1894[10]
   for the 'status' field of a DSN report.  An MSRP status code consists
   of a three digit number while a DSN status is three digits separated
   by '.'.  An example would be:

   Status: 5.0.0 (unknown permanent failure)



Campbell (Ed.)         Expires November 15, 2004               [Page 27]

Internet-Draft                    MSRP                          May 2004


   When generating this field the first digit of the MSRP status code
   (working from left to right) MUST be placed in the first part of the
   'status' DSN field.  The second digit MUST be placed in the second
   part of the 'status' DSN field.  The third digit MUST be placed in
   the third part of the 'status' DSN field.  An example of a DSN
   'status' field value would be:

   An MSRP '200' success response would be mapped to:

   Status: 2.0.0 (OK)

   The MSRP reason phrase mapped to a DSN 'status' field MAY be enclosed
   in parentheses if required.

6.7  Message Fragmentation

   MSRP devices SHOULD break large content into fragments, and send each
   fragment in a separate SEND request.  A message fragment sent in this
   way is known as a "parcel".  Large content is defined to be anything
   larger than 2K bytes.  Each parcel is encapsulated using the
   "message/byteranges" MIME type, defined in RFC2616 [11], to correlate
   parts of the message.  The definition of large is determined by local
   policy.  MSRP endpoints MUST be capable of receiving and processing
   fragmented messages.

      Open Issue: Do we want to negotiate the use of message/byteranges
      like any other MIME type? I assume no, as we want to allow relays
      to fragment messages, and relays are not privy to the
      content-types negotiated for a session.

   Although relays are not in scope for this document, we expect that
   relays will be able to introduce fragmentation, as well as change the
   fragmentation of previously fragmented messages.  Therefore, all MSRP
   endpoints MUST be able to receive fragmented messages.

6.7.1  MSRP Usage of message/byteranges

   The "message/byteranges" type allows multiple ranges in a single
   document.  However, MSRP devices MUST NOT include more than one byte
   range in a single request.  Although the HTTP usage for a document
   containing a single byte range indicates putting the "Content-Range"
   header in a header field, rather  than in the body itself,
   "Content-Range" MUST NOT appear as an MSRP header field.

      Open Issue: How much of the message/byteranges specification
      should we explain or copy forward? Copying too much obscures the
      fact that rfc2616 is the normative definition, but it may be
      helpful to have more context here.



Campbell (Ed.)         Expires November 15, 2004               [Page 28]

Internet-Draft                    MSRP                          May 2004


   If the MSRP device has a priori knowledge of the overall content
   length, it SHOULD put that length into instance-length.  The device
   MAY place a "*" in instance-length if it does not have such
   knowledge.

   Similarly, if the device has a priori knowledge of the number of
   bytes in a byte range, it SHOULD place the last byte position in
   last-byte-pos.  Otherwise, it MAY use a "*".  If "*" is present, the
   recipient MUST determine the last-byte-position through normal
   request framing and body processing.  An MSRP device MUST put the
   initial byte position in first-byte-pos.

6.8  Method Descriptions

   This section summarizes the purpose of each MSRP method.  All MSRP
   messages MUST contain the TR-ID, From-Path, To-Path, and Boundary
   header fields, as well as a Closing field.  Additional requirements
   exist depending on the individual method.

6.8.1  SEND

   The SEND method is used by both the host and visitor endpoints to
   send instant messages to its peer endpoint.  A SEND request MUST
   contain a To-Path header field containing the sender's remote path, a
   From-Path header field containing the sender's local URL, and a
   Message-ID header field.  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.

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

6.8.2  VISIT

   The visiting endpoint uses the VISIT method to associate a network
   connection with the session state at the listening device.  A VISIT
   request MUST include a To-Path header including the sender's remote
   path, and a From-Path header field containing the sender's local URL.

   This purpose can also be served by a SEND request, if the sender has
   immediate content to send.

      Open Issue: There is overlap between SEND and VISIT as currently
      defined.  We should consider either removing VISIT entirely and



Campbell (Ed.)         Expires November 15, 2004               [Page 29]

Internet-Draft                    MSRP                          May 2004


      just use an empty SEND request, or we should always require VISIT.
      (This would not apply to a endpoint connecting to its own relay.)

6.8.3  REPORT

   Report is used by an endpoint or relay to convey message delivery
   status

6.9  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 original request, and To-Path and From-Path
   headers matching those of the original request.

6.9.1  200

   The 200 response code indicates a successful transaction.

6.9.2  400

   A 400 response indicates a request was unintelligible.

6.9.3  415

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

6.9.4  426

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


6.9.5  481

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

6.9.6  506

   A 506 response indicates that a VISIT request occurred in which the
   To-Path header indicates a local path that is already associated with
   another connection.  A 506 response MUST NOT be returned in response
   to any method other than VISIT.

6.10  Header Field Descriptions

   This section summarizes the various header fields.  MSRP header



Campbell (Ed.)         Expires November 15, 2004               [Page 30]

Internet-Draft                    MSRP                          May 2004


   fields are single valued; that is, they MUST NOT occur more than once
   in a particular request or response.

6.10.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.10.2  Message-ID

   The Message-ID header field contains a message identifier used to map
   a delivery status notification to the corresponding request.  TR-ID
   cannot be used for this purpose, as it may change between hops if
   relays are involved.  A Message-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 Message-ID.
   The Message-ID value MAY be the same as the original TR-ID value.

6.10.3  To-Path

   The To-Path header field is used to indicate the sender's remote
   path.  All MSRP requests MUST contain a To-Path header field.

6.10.4  From-Path

   The From-Path header field is used to indicate the sender's local
   URL.  All MSRP requests MUST contain a From-Path header field.

6.10.5  Boundary

   The Boundary header field contains the boundary string that is used
   to terminate the message.  This string MUST have at least 16 bits of
   randomness.  This string MUST NOT be duplicated anywhere else in the
   message.  The Boundary header field is mandatory for all MSRP
   messages, and SHOULD be the first header field in the message.

6.10.6  Closing

   The Closing field contains the same boundary string that was
   originally listed in the Boundary header field, as well as the
   Continuation-Flag field.  The Closing field MUST occur at the end of
   each MSRP message.  If the message content has been sent completely,
   the Interrupt-Flag field value MUST be ""$ (dollar sign).  If there
   is further content to send as part of the "logical" instant message,
   this field value MUST be "+".  (plus sign.)



Campbell (Ed.)         Expires November 15, 2004               [Page 31]

Internet-Draft                    MSRP                          May 2004


6.10.7  Content-Type

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

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

7.  Example

   This section shows an example message flow for the most common
   scenario.  The example assumes SIP is used to transport the SDP
   exchange.  Details of the SIP messages and SIP proxy infrastructure
   are omitted for the sake of brevity.  In the example, assume the
   offerer is sip:alice@atlanta.com and the answerer is
   sip:bob@biloxi.com.

           Alice                     Bob
             |                        |
             |                        |
             |(1) (SIP) INVITE        |
             |----------------------->|
             |(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 local URL of
       msrp://alicepc.atlanta.com:7777/iau39 and listens for a
       connection on TCP port 7777.

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




Campbell (Ed.)         Expires November 15, 2004               [Page 32]

Internet-Draft                    MSRP                          May 2004


       v=0
       o=alice 2890844557 2890844559 IN IP4 host.anywhere.com
       s=
       c=IN IP4 fillername
       t=0 0
       m=message 9999 msrp *
       a=accept-types:text/plain
       a=path:msrp://alicepc.atlanta.com:7777/iau39

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

       v=0
       o=bob 2890844612 2890844616 IN IP4 host.anywhere.com
       s=
       c=IN IP4 ignorefield
       t=0 0
       m=message 9999 msrp *
       a=accept-types:text/plain
       a=path:msrp://bob.atlanta.com:8888/9di4ea

   3.  Alice->Bob (SIP): ACK

   4.  (Alice opens connection to Bob.  This may occur in parallel with
       the previous step.) Alice->Bob (MSRP):

       MSRP SEND
       Boundary: d93kswow
       To-Path:msrp://bob.atlanta.com:8888/9di4ea
       From-Path:msrp://alicepc.atlanta.com:7777/iau39
       TR-ID: 123
       Message-ID: 123
       Content-Type: "text/plain"
       Hi, I'm Alice!
       -------d93kswow$

   5.  Bob->Alice (MSRP):

       MSRP 200 OK
       Boundary: 839s9ed
       To-Path:msrp://bob.atlanta.com:8888/9di4ea
       From-Path:msrp://alicepc.atlanta.com:7777/iau39
       TR-ID: 123
       -------839s9ed$

   6.  Bob->Alice (MSRP):

       MSRP SEND
       Boundary: dkei38sd



Campbell (Ed.)         Expires November 15, 2004               [Page 33]

Internet-Draft                    MSRP                          May 2004


       To-Path:msrp://alice.atlanta.com:7777/iau39
       From-Path:msrp://bob.atlanta.com:8888/9di4ea
       TR-ID: 456
       Message-ID: 456
       Content-Type: "text/plain"

       Hi, Alice! I'm Bob!
       -------dkei38sd$

   7.  Alice->Bob (MSRP):

       MSRP 200 OK
       Boundary: diw3ids
       To-Path:msrp://alice.atlanta.com:7777/iau39
       From-Path:msrp://bob.atlanta.com:8888/9di4ea
       TR-ID: 456
       -------diw3ids$

   8.  Alice->Bob (SIP): BYE

       Alice invalidates local session state.

   9.  Bob invalidates local state for the session.

       Bob->Alice (SIP): 200 OK

8.  IANA Considerations

8.1  MSRP Port

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

8.2  MSRP URL Schema

   This document defines the URL schema of "msrp" "msrps", "smsrp", and
   "smsrps".

8.2.1  Syntax

   See Section 6.1.

8.2.2  Character Encoding

   See Section 6.1.





Campbell (Ed.)         Expires November 15, 2004               [Page 34]

Internet-Draft                    MSRP                          May 2004


8.2.3  Intended Usage

   See Section 6.1.

8.2.4  Protocols

   The Message Session Relay Protocol (MSRP).

8.2.5  Security Considerations

   See Section 9.

8.2.6  Relevant Publications

   RFCXXXX

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

8.3  SDP Parameters

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

8.3.1  Accept Types

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

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

8.3.3  Path

   Attribute-name:  path
   Long-form Attribute Name MSRP URL Path
   Type: Media level






Campbell (Ed.)         Expires November 15, 2004               [Page 35]

Internet-Draft                    MSRP                          May 2004


   Subject to Charset Attribute No
   Purpose and Appropriate Values See Section 5.4.

8.4  IANA registration forms for DSN types

8.4.1  IANA registration form for address-type

   This document registers a new 'address-type' for use in conjunction
   with RFC1894[10].  The authors request that these values be recorded
   in the IANA registry for DSN 'address-type'.

   Proposed Address name: msrp-address-type

   Syntax: See Section 6.1

8.4.2  IANA registration form for MTA-name-type

   This document registers a new 'MTA-name-type' for use in conjunction
   with RFC1894[10].  The authors request that these values be recorded
   in the IANA registry for DSN 'MTA-name-type'.

   Proposed Address name: msrp-name-type

   Syntax: See See Section 6.1

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  TLS and the MSRPS Scheme

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

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




Campbell (Ed.)         Expires November 15, 2004               [Page 36]

Internet-Draft                    MSRP                          May 2004


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

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

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

      There have since been proposals that we only allow start-tls at
      connection time.  Do we have a consensus here one way or the
      other?

   The "msrps" and "smsrps" URI schema indicates that the connection
   MUST be protected with TLS.

      Relay handling of "msrps" and "smsrps" are beyond the scope of
      this document.  However, any relay specification MUST explicitly
      specify this.

   MSRP requests for "msrps" URLs MUST be sent over TLS protected
   connections.  If a device receives a request for a "msrps" or
   "smsrps" URL over an unprotected connection, it MUST reject the
   request with a 426 response.

9.1.1  Sensitivity of Session URLs

   The URLs sent in the SDP offer/answer exchange for a MSRP session are
   used by the endpoints to identify each other.  If an attacker were
   able to acquire the session URL, either by guessing it or by
   eavesdropping, there is a window of opportunity in which the attacker
   could hijack the session connecting and sending a MSRP request to the
   listening device before the legitimate peer.  Because of this
   sensitivity, these URLs SHOULD be constructed in a way to make them
   difficult to guess, and should be sufficiently random so that it is
   unlikely to be reused.  All mechanisms used to transport these URLs
   SHOULD be protected from eavesdroppers and man-in-the-middle attacks.

   Therefore a MSRP device 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



Campbell (Ed.)         Expires November 15, 2004               [Page 37]

Internet-Draft                    MSRP                          May 2004


   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.1.2  End to End Protection of IMs

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

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

9.1.3  CPIM compatibility

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

9.1.4  PKI Considerations

   Several aspects of MSRP will benefit from being used in the context
   of a public key infrastructure.  For example, the MSRPS scheme
   allows, and even encourages, TLS connections between endpoint
   devices.  And while MSRP allows for a symmetric session key to
   protect all messages in a session, it is most likely that session key
   itself would be exchanged in a signaling protocol such as SIP.  Since



Campbell (Ed.)         Expires November 15, 2004               [Page 38]

Internet-Draft                    MSRP                          May 2004


   that key is extremely sensitive, its exchange would also need to be
   protected.  In SIP, the preferred mechanism for this would be S/MIME,
   which would also benefit from a PKI.

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

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

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

10.  Changes from Previous Draft Versions

   This section to be deleted prior to publication as an RFC

10.1  draft-ietf-simple-message-sessions-06

      Changed To and From header names to To-Path and From-Path.  Added
      more clarification to path handling, and commentary on how it
      enables relay usage.
      Changed mechanism for signaling transport and TLS protection into
      the MSRP URL, rather than the SDP M-Line.
      Removed length field from start line and added Boundary header
      field and Closing field.
      Added recommendation to fragment any content over 2k.
      Added Rohan's proposal to make offerer connect to answerer.  (With
      open issue for more discussion.)
      Changed To-Path and From-Path usage in responses to indicate the
      destination and source of the response, rather than merely copy
      from the associated request.
      Updated DSN section.  Added text on field usage.
      Fixed change section--changes from version 05 were erroneously
      attributed to 04.

10.2  draft-ietf-simple-message-sessions-05

      Changed the use of session URLs.  Instead of a single session URL,
      each endpoint is identified by a distinct URL.  MSRP requests will
      put the destination URL in a To header, and the sender URL in a
      From header.



Campbell (Ed.)         Expires November 15, 2004               [Page 39]

Internet-Draft                    MSRP                          May 2004


      Changed the SDP exchange of MSRP URLs to handle the URL for each
      endpoint.  Further, changed the SDP attribute to support a list of
      URLs in each direction.  This may be used with relays to exchange
      paths, rather than single URLs.  MSRP endpoints must be able to
      intelligently process such a list if received.  This document does
      not, however, describe how to generate such a list.
      Added section for Delivery Status Notification handling, and added
      associated entries into the syntax definition.
      Added content fragmentation section.
      Removed recommendation to start separate session for large
      transfers.
      Corrected some mistakes in the syntax definitions.
      Added Chris Boulton as a co-author for his contribution of the DSN
      text.

10.3  draft-ietf-simple-message-sessions-04

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

10.4  draft-ietf-simple-message-sessions-03

      Removed all specification of relays, and all features specific to
      the use of relays.  The working group has chosen to move relay
      work into a separate effort, in order to advance the base
      specification.  (The MSRP acronym is unchanged for the sake of
      convenience.) This included removal of the BIND method, all
      response codes specific to BIND, Digest Authentication, and the
      inactivity timeout.
      Removed text indicating that an endpoint could retry failed
      requests on the same connection.  Rather, the endpoint should
      consider the connection dead, and either signal a reconnection or
      end the session.
      Added text describing subsequent SDP exchanges.  Added mandatory
      "count" parameter to the direction attribute to allow explicit
      signaling of the need to reconnect.
      Added text to describe the use of send and receive only indicators
      in SDP for one-way transfer of large content.
      Added text requiring unique port field values if multiple M-line's
      exist.
      Corrected a number of editorial mistakes.

10.5  draft-ietf-simple-message-sessions-02

      Moved all content type negotiation from the "m"-line format list
      into "a"-line attributes.  Added the accept-types attribute.  This
      is due to the fact that the sdp format-list syntax is not



Campbell (Ed.)         Expires November 15, 2004               [Page 40]

Internet-Draft                    MSRP                          May 2004


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

10.6  draft-ietf-simple-message-sessions-01

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

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



Campbell (Ed.)         Expires November 15, 2004               [Page 41]

Internet-Draft                    MSRP                          May 2004


      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.

10.8  draft-campbell-simple-im-sessions-01

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

11.  Contributors

   In addition to the editor, The following people contributed extensive
   work to this document:

      Chris Boulton
      Cullen Jennings
      Paul Kyzivat
      Rohan Mahy
      Adam Roach
      Jonathan Rosenberg
      Robert Sparks

12.  Acknowledgments

   The following people contributed substantial discussion and feedback
   to this ongoing effort:
    Allison Mankin Jon Peterson Brian Rosen Dean Willis
                        Aki Niemi Hisham Khartabil Pekka Pessi Orit Levin

13.  References

13.1  Normative References

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



Campbell (Ed.)         Expires November 15, 2004               [Page 42]

Internet-Draft                    MSRP                          May 2004


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

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

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

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

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

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

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

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

   [10]  Moore, K. and G. Vaudreuil, "An Extensible Message Format for
         Delivery Status Notifications", RFC 1894, January 1996.

   [11]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
         Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
         HTTP/1.1", RFC 2616, June 1999.

13.2  Informational References

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

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

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



Campbell (Ed.)         Expires November 15, 2004               [Page 43]

Internet-Draft                    MSRP                          May 2004


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

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

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

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

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

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


Author's Address

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

   EMail: bcampbell@dynamicsoft.com


















Campbell (Ed.)         Expires November 15, 2004               [Page 44]

Internet-Draft                    MSRP                          May 2004


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 (2004).  All Rights Reserved.

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

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

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Campbell (Ed.)         Expires November 15, 2004               [Page 45]

Internet-Draft                    MSRP                          May 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

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











































Campbell (Ed.)         Expires November 15, 2004               [Page 46]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/