SIMPLE Working Group WG                                               B. Campbell (Ed.) Campbell, Ed.
Internet-Draft                                               dynamicsoft
Expires: November 15, 2004                                  May 17, January 16, 2005                                        R. Mahy
                                                             C. Jennings
                                                     Cisco Systems, Inc.
                                                           July 18, 2004

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

Status of this Memo

   This document is an Internet-Draft

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and is any of which I become aware will be disclosed, in full conformance accordance with
   all provisions of Section 10 of RFC2026.
   RFC 3668.

   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. January 16, 2005.

Copyright Notice

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

Abstract

   This document describes the Message Session Relay Protocol (MSRP), a
   mechanism
   protocol for transmitting a series of Instant Messages within related instant messages in the
   context of a session.  MSRP  Message sessions are managed using the Session Description
   Protocol (SDP) offer/answer model carried by treated like any other
   media stream when setup via a signaling rendezvous or session setup protocol
   such as the Session Initiation Protocol (SIP).

Table of Contents

   1.   Introduction   Conventions  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.   Motivation for Session-mode Messaging  .   Introduction and Background  . . . . . . . . . .   4
   3.   Scope of this Document . . . . . .   4
   3.   Protocol Overview  . . . . . . . . . . . . .   5
   4.   Protocol Overview . . . . . . . .   5
   4.   Key Concepts . . . . . . . . . . . . .   6
   5.   SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . .   7
     5.1  Use of the SDP M-line . . .   8
     4.1  MSRP Framing and Message Chunking  . . . . . . . . . . . .   8
     4.2  MSRP Addressing  . . .   7
     5.2  The Accept Types Attribute . . . . . . . . . . . . . . . .   7
     5.3  MIME Wrappers . .  11
     4.3  MSRP Transaction and Report Model  . . . . . . . . . . . .  11
     4.4  MSRP Connection Model  . . . . . . . .   8
     5.4  URL Negotiations . . . . . . . . . .  12
   5.   MSRP URLs  . . . . . . . . . . .   9
     5.5  Path Attributes with Multiple URLs . . . . . . . . . . . .  10
     5.6  Updated SDP Offers . .  14
     5.1  MSRP URL Comparison  . . . . . . . . . . . . . . . . . .  11
     5.7  Example SDP Exchange .  15
     5.2  Resolving MSRP Host Device . . . . . . . . . . . . . . . .  16
   6.   Method-Specific Behavior . .  11
     5.8  Connection Negotiation . . . . . . . . . . . . . . . .  16
     6.1  Constructing Requests  . .  12
   6.   The Message Session Relay Protocol . . . . . . . . . . . . .  12
     6.1  MSRP URLs . . .  16
       6.1.1  Delivering SEND requests . . . . . . . . . . . . . . .  17
       6.1.2  Sending REPORT requests  . . . . . .  12
       6.1.1  MSRP URL Comparison . . . . . . . . .  19
       6.1.3  Failure REPORT Generation  . . . . . . . .  13
       6.1.2  Resolving MSRP Host Device . . . . . .  19
     6.2  Constructing Responses . . . . . . . .  14
     6.2  Connection Direction . . . . . . . . . .  20
     6.3  Receiving Requests . . . . . . . . .  14
     6.3  MSRP Messages . . . . . . . . . . .  21
       6.3.1  Receiving SEND requests  . . . . . . . . . . .  15
       6.3.1  Message Framing . . . .  21
       6.3.2  Receiving REPORT requests  . . . . . . . . . . . . . .  22
   7.   Using MSRP with SIP  .  17
       6.3.2  Message Examples . . . . . . . . . . . . . . . . . . .  18
     6.4  22
     7.1  SDP Offer-Answer Exchanges for MSRP Transactions  . . Sessions . . . . . . .  22
       7.1.1  URL Negotiations . . . . . . . . . . .  19
     6.5  MSRP Sessions  . . . . . . . . . . . .  25
       7.1.2  Path Attributes with Multiple URLs . . . . . . . . . .  19
       6.5.1  Initiating an MSRP session  26
       7.1.3  Updated SDP Offers . . . . . . . . . . . . . .  19
       6.5.2  Handling the initial request . . . .  27
       7.1.4  Example SDP Exchange . . . . . . . . .  21
       6.5.3  Sending Instant Messages on a Session . . . . . . . .  21
       6.5.4  Ending a Session  27
       7.1.5  Connection Negotiation . . . . . . . . . . . . . . . .  28
     7.2  MSRP User Experience with SIP  . . .  23
       6.5.5  Managing Session State and Connections . . . . . . . .  23
     6.6  Delivery Status Notification . . .  28
   8.   DSN payloads in MSRP REPORT Requests . . . . . . . . . . . .  24
       6.6.1  Endpoint  28
     8.1  Per-Message DSN Request . . header usage . . . . . . . . . . . . . . .  24
       6.6.2  28
     8.2  Per-Recipient DSN generation . . . . . . . . . . . . . header usage . . . . . . .  25
       6.6.3  Receiving positive DSN . . . . . . .  29
     8.3  original-envelope-id usage . . . . . . . . .  26
       6.6.4  Receiving negative DSN . . . . . . .  29
     8.4  reporting-mta  . . . . . . . . .  26
       6.6.5  DSN headers in MSRP . . . . . . . . . . . . .  29
     8.5  final-recipient  . . . .  26
     6.7  Message Fragmentation . . . . . . . . . . . . . . . . .  29
     8.6  action .  28
       6.7.1  MSRP Usage of message/byteranges . . . . . . . . . . .  28
     6.8  Method Descriptions . . . . . . . . . . . . . .  30
     8.7  status . . . . .  29
       6.8.1  SEND . . . . . . . . . . . . . . . . . . . . .  30
   9.   Formal Syntax  . . . .  29
       6.8.2  VISIT . . . . . . . . . . . . . . . . . . .  30
   10.  Response Code Descriptions . . . . .  29
       6.8.3  REPORT . . . . . . . . . . . .  32
     10.1   200  . . . . . . . . . . . .  30
     6.9  Response Code Descriptions . . . . . . . . . . . . . .  33
     10.2   400  . .  30
       6.9.1  200 . . . . . . . . . . . . . . . . . . . . . . . .  33
     10.3   403  .  30
       6.9.2  400 . . . . . . . . . . . . . . . . . . . . . . . . .  30
       6.9.3  33
     10.4   415  . . . . . . . . . . . . . . . . . . . . . . . . .  30
       6.9.4 .  33
     10.5   426  . . . . . . . . . . . . . . . . . . . . . . . . .  30
       6.9.5 .  33
     10.6   481  . . . . . . . . . . . . . . . . . . . . . . . . .  30
       6.9.6 .  33
     10.7   506  . . . . . . . . . . . . . . . . . . . . . . . . .  30
     6.10   Header Field Descriptions .  33
   11.  Examples . . . . . . . . . . . . . .  30
       6.10.1   TR-ID . . . . . . . . . . . .  33
     11.1   Basic IM session . . . . . . . . . . .  31
       6.10.2   Message-ID . . . . . . . . .  33
     11.2   Chunked Message  . . . . . . . . . . . .  31
       6.10.3   To-Path . . . . . . . .  36
     11.3   System Message . . . . . . . . . . . . . . .  31
       6.10.4   From-Path . . . . . .  36
     11.4   Positive Report  . . . . . . . . . . . . . . .  31
       6.10.5   Boundary . . . . .  37
     11.5   Forked IM  . . . . . . . . . . . . . . . . .  31
       6.10.6   Closing . . . . . .  37
   12.  Extensibility  . . . . . . . . . . . . . . . .  31
       6.10.7   Content-Type . . . . . . .  40
   13.  CPIM compatibility . . . . . . . . . . . . .  32
   7.   Example . . . . . . . .  40
   14.  Security Considerations  . . . . . . . . . . . . . . . . . .  32
   8.  40
   15.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  34
     8.1  42
     15.1   MSRP Port  . . . . . . . . . . . . . . . . . . . . . . . .  34
     8.2  42
     15.2   MSRP URL Schema Schemes . . . . . . . . . . . . . . . . . . . .  42
     15.3   SDP Parameters .  34
       8.2.1  Syntax . . . . . . . . . . . . . . . . . . . .  43
       15.3.1   Accept Types . . . .  34
       8.2.2  Character Encoding . . . . . . . . . . . . . . . .  43
       15.3.2   Wrapped Types  . .  34
       8.2.3  Intended Usage . . . . . . . . . . . . . . . . .  43
       15.3.3   Path . . .  35
       8.2.4  Protocols . . . . . . . . . . . . . . . . . . . . .  43
     15.4   IANA registration forms for DSN types  .  35
       8.2.5  Security Considerations . . . . . . . .  43
       15.4.1   IANA registration form for address-type  . . . . . .  43
       15.4.2   IANA registration form for MTA-name-type .  35
       8.2.6  Relevant Publications . . . . .  44
   16.  Change History . . . . . . . . . . .  35
     8.3  SDP Parameters . . . . . . . . . . . .  44
     16.1   draft-ietf-simple-message-sessions-07  . . . . . . . . .  44
     16.2   draft-ietf-simple-message-sessions-06  .  35
       8.3.1  Accept Types . . . . . . . .  44
     16.3   draft-ietf-simple-message-sessions-05  . . . . . . . . .  45
     16.4   draft-ietf-simple-message-sessions-04  . . . .  35
       8.3.2  Wrapped Types . . . . .  45
     16.5   draft-ietf-simple-message-sessions-03  . . . . . . . . .  45
     16.6   draft-ietf-simple-message-sessions-02  . . . . . .  35
       8.3.3  Path . . . . . . . . . . . . . . . . . . . . . . . . .  35
     8.4  IANA registration forms for DSN types  . . . . . . . . . .  36
       8.4.1  IANA registration form for address-type  . . . .  46
     16.7   draft-ietf-simple-message-sessions-01  . . .  36
       8.4.2  IANA registration form for MTA-name-type . . . . . .  46
     16.8   draft-ietf-simple-message-sessions-00  .  36
   9.   Security Considerations . . . . . . . .  47
     16.9   draft-campbell-simple-im-sessions-01 . . . . . . . . . .  36
     9.1  TLS  47
   17.  Contributors 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  . . . . . . . Acknowledgments . .  40
     10.6   draft-ietf-simple-message-sessions-01 . . . . . . . . .  41
     10.7   draft-ietf-simple-message-sessions-00 . . .  47
   18.  References . . . . . .  41
     10.8   draft-campbell-simple-im-sessions-01 . . . . . . . . . .  42
   11.  Contributors . . . . . . . . .  48
   18.1   Normative References . . . . . . . . . . . . . . .  42
   12.  Acknowledgments . . . .  48
   18.2   Informational References . . . . . . . . . . . . . . . . .  49
        Authors' Addresses .  42
   13.  References . . . . . . . . . . . . . . . . . . . .  50
        Intellectual Property and Copyright Statements . . . . .  42
   13.1   Normative References . . . . . . . . . . . . . . . . . . .  42
   13.2   Informational References . . . . . . . . . . . . . . . . .  43
        Author's Address . . . . . . . . . . . . . . . . . . . . . .  44
        Intellectual Property and Copyright Statements . . . . . . .  45  52

1.  Introduction  Conventions

   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 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and another.

   There are also applications "OPTIONAL" in which it is useful for instant
   messages this
   document are to be formally associated interpreted as described in a session.  For example, a user
   may wish RFC-2119 [5].

   This document consistently refers to join a "message" as a complete unit
   of MIME or text conference, participate in the conference for content.  In some period of time, then leave the conference.  This usage cases a message is
   analogous to regular media sessions that are typically initiated,
   managed, split and terminated using SIP.  We commonly refer to this model
   as session-mode messaging.

   One
   delivered in more than one MSRP request.  Each of the primary purposes these portions of SIP and SDP (Section 5) is
   the
   management complete message is called a "chunk".

2.  Introduction and Background

   A series of media sessions.  Session-mode messaging related textual messages between two or more parties can
   be thought
   of viewed as part of a media session like any other. with a definite start and end.  This document
   is in contrast to individual messages each sent completely
   independently.  The SIMPLE Working Group describes the
   motivations for session-mode messaging, the Message Session Relay
   Protocol, and the use messaging schemes
   that only track individual messages as "page-mode" messages, whereas
   messaging that is part of a "session" with a definite start and end
   is called session-mode messaging.

   Page-mode messaging is enabled in SIMPLE via the SDP offer/answer mechanism for managing
   MSRP session.

2.  Motivation for SIP [4]MESSAGE
   method [19].  Session-mode Messaging

   Message sessions offer several advantages over page-mode messages.
   For message exchanges that include more than messaging has a small number of
   message transactions, message sessions offer a way to remove benefits [20]
   over page-mode messaging load from intervening SIP proxies.  For example, a minimal
   session setup however, such as explicit rendezvous,
   tighter integration with other media types, direct client-to-client
   operation, and tear-down requires one INVITE/ACK transaction, brokered privacy and
   one BYE transaction, for security.

   This document defines 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 session-oriented instant message transport
   protocol (MSRP), whose sessions can be included 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 an offer or answer
   [3] of a response.  Any page-mode message session description (for example, SDP [2]).  The exchange that
   involves more than 2 MESSAGE requests will generate more is
   carried by some signaling protocol, such as SIP requests
   than [4].  This allows a minimal
   communication user agent to offer a messaging session initiation sequence.  Since MESSAGE is
   normally used outside as one of a SIP dialog, these requests will typically
   traverse the entire proxy network between the endpoints.

   Due
   possible media types in a session.  For instance, Alice may want to network congestion concerns,
   communicate with Bob.  Alice doesn't know at the MESSAGE method moment whether Bob
   has
   significant limitations in message size, his phone or his IM client handy, but she's willing to use
   either.  She sends an invitation to a prohibition against
   overlapping requests, etc.  Much of this has been required because of
   perceived limitations in session to the congestion-avoidance features address 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
   record she has for secure message
   exchanges. Bob, sip:bob@example.com.  Her invitation offers
   both voice and an IM session.  The SIP MESSAGE request inherits services at example.com
   forward the S/MIME features of
   SIP, allowing a message invitation 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 Bob at his currently registered clients.
   Bob accepts the time
   of session initiation. invitation at his IM client and they begin a threaded
   chat conversation.

   This key can session model allows message sessions to be used integrated into
   advanced communications applications with little 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
   protocol development.  For example, during the session key can be done using standard techniques that apply
   to voice and video, in addition above chat session,
   Bob decides Alice really needs to instant messaging.

   Finally, SIP devices can treat message sessions like any other media
   sessions.  Any SIP feature that can be applied talking to other sorts of
   media sessions Carol.  Bob 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 Alice to message
   sessions. Carol, introducing them into their own
   messaging session.  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 then be easily integrated
   into call-center and dispatch environments utilizing third-party call
   control [17] and conferencing [16] applications.

3.  Protocol Overview

   MSRP is established a text-based, connection-oriented protocol for exchanging
   arbitrary (binary) MIME content, especially instant messages.  As a result, messaging session mechanisms can be designed
   with significantly less overhead.

3.  Scope of this Document  This document describes the use
   section is a non-normative overview of how MSRP between endpoints.  It does
   not specify the use of intermediaries, nor does works and how it prohibit such use.
   We expect an extension to this specification to define is
   used with SIP.

   MSRP
   intermediaries and their use.

   This document describes sessions are typically arranged using SIP the use same way a session
   of MSRP over TCP.  MSRP may be used
   over other congestion-controlled protocols such as SCTP.  However, audio or video media is setup.  One SIP user agent (Alice) sends
   the specific bindings for other such protocols are outside the scope (Bob) a SIP invitation containing an offer
   session-description which includes a session of this document.

4.  Protocol Overview MSRP.  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 receiving
   SIP user agent can operate in accept the presence of many NAT and firewall environments, as
   it allows participants to positively associate message sessions with
   specific connections, invitation and does not depend upon connection source
   address, include an answer
   session-description which may be obscured by NATs.

   MSRP uses acknowledges the following primitives:

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

   VISIT: Used by an endpoint to establish a choice of media.  Alice's
   session association to the
      host endpoint.

   REPORT Used to carry MSRP message report/receipt information.

   Assume A is description contains an endpoint MSRP URL that wishes describes where she is
   willing to establish a message session, receive MSRP requests from Bob, and B is vice-versa.  (Note:
   Some lines in the endpoint invited by A.  A invites B examples are removed for clarity and brevity.)
       Alice sends to participate in Bob:

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

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

       Bob sends to Alice:

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

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

       Alice sends to Bob:

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

   MSRP defines two request types, or methods.  SEND requests are used
   to deliver a complete 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 or a URL chunk (a portion 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 complete
   message), while REPORT requests report on the connection.  Each party targets such requests to the peer's URL. status of an earlier
   SEND request.  When either party wishes Alice receives Bob's answer, she checks to end the session, it informs its peer
   using the appropriate mechanism of the chosen signaling protocol,
   such as see if
   she has an existing connection to Bob.  If not, she opens a SIP BYE request.

   The end new
   connection to end case looks something like Bob using the following.  (Note that URL he provided in the example shows SDP.  Alice then
   delivers 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): request to Bob with her initial message, and Bob
   replies indicating that Alice's request was received successfully.

   MSRP a786hjs2 SEND (msrp://A/123)
   A->B (MSRP):
   To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp
   From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp
   Message-ID: 87652
   Content-Type: text/plain

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

   MSRP a786hjs2 200 OK

5.  SDP Offer-Answer Exchanges for MSRP Sessions
   To-Path: msrp://atlanta.example.com:7654/jshA7we;tcp
   From-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp
   Message-ID: 87652
   -------a786hjs2$

   Alice's request begins with the MSRP sessions will typically be initiated using start line, which contains a
   transaction identifier that is also used as a final boundary marker.
   Next she includes 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 path of URLs to the SDP M-line

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

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

   For non-RTP media sessions, The media field specifies To-Path
   header, and her own URL in the top level
   MIME media type for From-Path header.  In this typical
   case there is just one "hop", so there is only one URL in each path
   header field.  She also includes a message ID which she can use to
   correlate responses and status reports with the session.  For MSRP sessions, original message.
   Next she puts the media field
   MUST have actual content.  Finally she closes the value of "message".  The port field is normally not
   used, request
   with an end line: seven hyphens, the transaction identifier /
   boundary marker and MAY be set a "$" to any value chosen by indicate this request contains the endpoint.  A port
   field value end
   of zero has a complete message.

   If Alice wants to deliver a very large message, she can split the standard SDP meaning.  Non-zero values
   MUST not be repeated in other MSRP m-lines
   message into chunks and deliver each chunk in the same SDP document. a separate SEND
   request.  The protocol field is used only message ID corresponds to designate MSRP.  The underlying
   transport protocol is determined in the MSRP URL, as described below.
   Therefore, whole message, so the protocol field MUST take
   receiver can also use it to reassemble the value of "msrp".

   The format list list message and tell which
   chunks belong with which message.  Chunking is ignored for MSRP. described in more
   detail in Section 4.1.

   Alice can also specify what type of reporting she would like in
   response to her request.  If Alice requests positive
   acknowledgements, Bob sends a REPORT request to Alice confirming the
   delivery of her complete message.  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 especially useful if Alice
   sent a "*" character, series of SEND request containing chunks of a single message.
   More on requesting types of reports and nothing else.

   The port field errors is described in the M-line
   Section 4.3.

   Alice and Bob generally choose their MSRP URLs in such a way that is not used
   difficult to determine guess the port exact URL.  Alice and Bob can reject requests
   to
   which URLs they are not expecting to connect.  Rather, the actual port is determined by the service, and can correlate the
   MSRP
   specific URL (Section 6.1) in with the path attribute.  However, probable sender.  Alice and Bob can also use
   TLS [1] to provide channel security over this hop.  To receive MSRP
   requests over a port value
   of zero has TLS protected connection, Alice or Bob could
   advertise URLs with the normal SDP meaning.

   The following example illustrates an m-line "msrps" scheme instead of "msrp."

   This document specifies MSRP behavior only peer-to-peer session, that
   is, for a message session,
   where the endpoint single hop.  But is willing to accept root payloads of message/
   cpim, plain text or HTML.  The second two types could either be
   presented as designed with the root body, or could be contained within message/cpim
   bodies.

      m=message 9999 msrp *

5.2  The Accept Types Attribute expectation that MSRP
   can carry any MIME encoded payload.  Endpoints specify MIME
   content types that they are willing to receive in URLs for nodes on the accept types
   "a"-line attribute.  This attribute has far side of gateways or relays.  For
   this reason, a URL with the following syntax:

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

   SDP offers for MSRP sessions MUST include an accept-types attribute.
   SDP answers MUST also include "msrps" scheme makes no assertion about
   the attribute, which MUST contain
   either security properties of other hops, just the same list as next hop.

   MSRP URLs are discussed in more detail in Section 5.

   An adjacent pair of busy MSRP nodes (for example two gateways) can
   easily have several sessions, and exchange traffic for several
   simultaneous users.  The nodes can use existing connections to carry
   new traffic with the offer or same destination host, port, transport protocol,
   and scheme.  MSRP nodes can keep track of how many sessions are using
   a subset particular connection and close these connections when no sessions
   have used them for some period of that list.

   A "*" entry time.  Connection management is
   discussed in more detail in Section 4.4.

4.  Key Concepts

4.1  MSRP Framing and Message Chunking

   Messages sent using MSRP can be very large and can be delivered in
   several SEND requests, where each SEND request contains one chunk of
   the accept-types attribute indicates that the sender
   may attempt to send messages with media types overall message.  To support this, MSRP uses a boundary based
   framing mechanism.  The header of an MSRP request contains a unique
   boundary string that have not been
   explicitly listed.  If the receiver is able used to process indicate the media
   type, it does so.  If not, it will respond with end of the request.
   Following the boundary string at the end of the body data, there is a 415.  Note
   flag that all
   explicit entries SHOULD be considered preferred over any non-listed
   types.  This feature indicates whether this is needed as, otherwise, the list of formats last chunk of data 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, this
   message or may whether the message will be wrapped continued in a listed container type.
   (Note that the container type MUST subsequent
   chunk.  There is also be listed in the accept-types
   attribute.)

5.3  MIME Wrappers

   The MIME content-types a Byte-Range header in the accept-types attribute will often
   include container types; that is, types request that contain other types.
   indicates the overall position of this chunk inside the complete
   message.

   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 the following snippet of two SEND requests demonstrates
   a listed container type.

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

                     accept-wrapped-types = wrapped-types-label ":" format-list
                     wrapped-types-label = "accept-wrapped-types" ` text "abcdEFGH" being sent as two chunks.

    MSRP dkei38sd SEND
    Message-ID: 456
    Byte-Range: 1-4/8
    Content-Type: "text/plain"

    abcd
    -------dkei38sd+

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

    EFGH
    -------dkei38ia$

   The format-list element has receiver uses the identical syntax as defined for value of the
   accept-types attribute.  The semantics for this attribute are
   identical Message-ID header to those determine
   which of  multiple chunks belong to 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 same message.  The Message-ID
   header MUST have the
   "root" type same value for each chunk in the entire body.  Since any type listed in
   accept-types may be used both as a root body, same message,
   and wrapped in other
   bodies, format entries from a sender MUST ensure that the m-line SHOULD NOT be repeated in this
   attribute.

   This approach does not allow for specifying distinct lists of
   acceptable wrapped types message ID is unique for different types each of containers.  If an
   endpoint understands
   the messages it sends within a MIME type in particular session.

   The boundary marker that terminates the context body MUST be preceded by a
   CRLF that is not part of one wrapper, it the body and then seven "-" (minus sign)
   characters.  After the boundary marker, there MUST be a flag
   character that is
   assumed to understand it in either a "$" (for the context last chunk of any the message) or
   "+" (for chunks other acceptable
   wrappers, subject to any constraints defined by than the wrapper types
   themselves.

      The approach of specifying types last).  If the chunk represents the
   data that are only allowed inside forms the end of
      containers separately from the primary payload types allows an
      endpoint to force message, the use of certain wrappers.  For example, flag MUST be a
      CPIM gateway device may require all messages to "$",
   otherwise the flag MUST be wrapped inside
      message/cpim bodies, but may allow several content types inside a "+".

   The Byte-Range header value contains a starting value followed by a
   "-", an ending value followed by a "/", and finally the wrapper.  If total length.
   The starting value indicates the gateway were to specify index into the wrapped types message where the
   first byte in the accept-types attribute, its peer could choose to use those
      types without current chunk belongs.  The index of the wrapper.

5.4  URL Negotiations

   Each endpoint first
   octet in an MSRP session is identified the complete message is ONE, not zero.  The ending value
   indicates the location where the last octet belongs.  The body MAY
   contain less data than is indicated by a URL.  These URLs
   are negotiated in the SDP exchange.  Each SDP offer or answer end but it MUST NOT
   contain one or more MSRP URL in a path attribute.  This attribute has octets than indicated.  The length indicates 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 number
   of octets 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 complete message.  Both the target when sending messages.  For
   MSRP sessions, ending value and length
   MAY have the address field value of "*" in some or all of the C-line is chunks, to indicate
   that they are not relevant, and
   MUST be ignored.  The port field in specified.  If no Byte-Range header is present, the M-line
   SEND request MUST be ignored treated as 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. there was a Byte-Range header
   present with a value of "1-*/*".

   This information is encoded in the
   URL scheme.

   Both offerer and answerer store the path values received from the
   peer.  For chunking mechanism allows a given endpoint, sender to interrupt a chunk part way
   through sending it by writing out the local URL is boundary termination and the URL
   "+" flag to indicate that the
   endpoint put into a SDP path attribute to represent itself.  The peer
   URL end of this chunk is not the URL sent by end of the peer
   complete message.  The ability to represent itself.  If the path
   attribute received from interrupt messages allows multiple
   sessions to share a TCP connection, and for large messages to be sent
   efficiently while not blocking other messages that share the peer contains more same
   connection.

   To insure fairness over a connection, senders MUST NOT send chunks
   with a body larger than 2048 octets unless they are prepared to
   interrupt them.  A sender can use one URL, then of the
   peer URL following two strategies
   to satisfy this requirement.  The sender is STRONGLY RECOMMENDED to
   send messages larger than 2048 octets using as few chunks as
   possible, interrupting chunks (at least 2048 octets long) when other
   traffic is waiting to use the rightmost, while same connection.  Alternatively, the leftmost entry represents
   sender MAY simply send chunks in 2048 octet increments until the
   adjacent hop.  If only one entry is present, then it is both
   final chunk.  Note that the peer
   and adjacent URL.  The remote path is former strategy results in markedly more
   efficient use of the entire path attribute value
   received connection.  All MSRP nodes MUST be able to
   receive chunks of any size from 0 octets to the peer.

   The following example shows an SDP offer with a session URL maximum number 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
   octets they can receive for a complete message.  Senders SHOULD NOT
   break messages into chunks smaller than 2048 octets, except for the path attribute
   final chunk of a complete message.

   Receivers MUST identify the endpoint
   that generated not assume the SDP document, chunks will be delivered in order or some other location where
   that
   endpoint wishes to they will receive messages associated all the chunks with "+" flags before they
   receive the session.  It
   MUST MUST chunk with the "$" flag.  In certain cases of connection
   failure, it is possible for information to be a temporary URL assigned just duplicated.  If chunks
   data is received that overlaps already received data 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 same
   message, the last chunk received takes precedence (even though this
   may not have been the last chunk transmitted).  For example, if bytes
   1 to guess, 100 was received and protected from eavesdroppers.  This a chunk arrives that contains bytes 50 to
   150, this second chunk will be
   discussed in more detail in Section 9.

5.5  Path Attributes with Multiple URLs

   As mentioned previously, overwrite bytes 50 to 100 of the data
   that had already been received.  Although other schemes work, this document describes MSRP is
   the easiest for
   peer-to-peer scenarios, that is, when no relays the receiver and results in consistent behavior
   between clients.

   The seven "-" before the boundary are used.  However,
   we expect used so that the receiver can
   search for the value "----", 32 bits at a separate document time to describe find the use probable
   location of relays in the
   near future.  In order boundary.  This allows most processors to allow an MSRP device that only implements locate the core specification to interoperate with devices
   boundaries and copy the memory at the same rate 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 normal memory
   copy could be done.  This approach results in a URL for each device system that is as
   fast as framing based on specifying the body length in the relay chain into headers of
   the SDP path
   attribute.  The final entry would point to request, but also allows for the endpoint itself.  The
   other entries would indicate each proposed relay, in order. interruption of messages.

   The
   first entry would point ability to the first relay in the chain; interrupt messages is needed so that is, the
   relay to which the peer device, or a relay operation on its behalf,
   should connect.

   Endpoints TCP connections
   can be shared.  Connection sharing is necessary for "fair" allocation
   of bandwidth in congestion situations and for allowing MSRP network
   elements that do not wish to insert have a relay, including those that do
   not support relays at all, will put exactly one URL into the path
   attribute.  This very large number of concurrent connections to
   different users.

4.2  MSRP Addressing

   MSRP entities are addressed using URLs.  The MSRP URL represents both the endpoint for schemes are
   defined in Section 5.  The syntax of the session, To-Path and the connection point.

   While endpoints that implement only this specification will never
   introduce From-Path
   headers allow for a relay, they will need list of URLs.  This was done to be able allow the
   protocol to interoperate work with
   other endpoints that do use relays.  Therefore, they MUST be prepared
   to receive more than one URL gateways or relays defined in the SDP future, to
   provide a complete path attribute. to the end recipient.  When an
   endpoint receives more than two MSRP nodes
   communicate directly they need only one URL in a path header, only the first
   entry is relevant for purposes of resolving the address and port, To-Path list 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 From-Path list.

4.3  MSRP Transaction and Report Model

   A sender sends MSRP requests to a receiver.  The receiver MUST exhibit
   quickly accept or reject the uniqueness
   properties described above.  Uniqueness requirements for other
   entries in request.  If 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 receiver initially
   accepted the request, it still may sometimes need then do things that take
   significant time to send additional SDP exchanges
   for succeed or fail.  For example, if the receiver is
   an existing session.  They may need to send periodic exchanges
   with no change MSRP to refresh state in XMPP [29] gateway, it may forward the network, for example, SIP
   timers.  They message over XMPP.
   The XMPP side may need to change some other stream in a session
   without affecting later indicate that the request did not work.  At
   this point, the MSRP stream, or they receiver may need to change an MSRP
   stream without affecting some other stream.

   If either party wish to send an SDP document indicate that changes nothing at
   all, then it MUST have the same o-line version as in request
   did not succeed.  There are two important concepts here: first, the previous
   exchange.

5.7  Example SDP Exchange

   Endpoint A wishes to invite Endpoint B to a MSRP session.  A offers
   hop by hop delivery of 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 *
                     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) may succeed or a SEND fail; second, the
   end result of the 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 be successfully processed or not.  The
   first type of this document included status is referred to as "transaction status" and may
   be returned in response to a mechanism request.  The second type of status is
   referred to negotiate
   the direction for any required TCP connection.  The mechanism was
   loosely based on COMEDIA [20]work being done as "request status" and may be returned in the MMUSIC working
   group. a REPORT
   transaction.

   The primary motivation was original sender of a request can indicate if they wish to allow MSRP sessions receive
   reports for requests that fail, and can independently indicate if
   they wish to succeed
   in situations where the offerer could not accept connections but receive reports for requests that succeed.  A receiver
   only sends a success REPORT if it knows that the
   answerer could.  For example, request succeeded,
   and the offerer might be behind sender requested a NAT,
   while the answerer might have success report.  A receiver only sends a globally routable address.

   The SIMPLE working group chose
   failure REPORT if the request failed and the sender requested failure
   reports.

      This document describes the behavior of MSRP endpoints.  MSRP
      relays or gateways are likely to remove have additional conditions that mechanism from MSRP,
      indicate a failure REPORT should be sent, such as
   it added the failure to
      receive a great deal of complexity positive response from the next hop.

   Two header fields control the sender's desire to connection management.
   Instead, MSRP now specifies default connection directions.

6.  The Message Session Relay Protocol receive reports.
   The Message Session Relay Protocol (MSRP) is header "Report-Success" can have a text based, message
   oriented protocol for value of "yes" or "no" and the transfer
   "Report-Failure" header can have a value of instant messages in "yes", "no", or
   "partial".

   If the context value of a session.  MSRP uses "Report-Failure" is set to "yes", then the UTF8 character set.

   MSRP messages MUST be sent over sender of
   the request runs a reliable, congestion-controlled,
   connection-oriented transport protocol.  This document specifies timer.  If a 200 response to 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 transaction is
   not received within 30 seconds from the URL syntax in Appendix A of
   RFC2396 [4], with a scheme time the last byte 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
   transaction is sent, the element MUST also
   contain a port.  The resource part identifies a particular session inform the participant.  The absence of user that the resource part indicates a
   reference
   request probably failed.  If the value is set to an MSRP host device, but "partial", then the
   element sending the transaction does not specifically refer have to run a particular session resource.

   The underlying transport protocol and timer, but
   MUST inform the protection level (that is,
   whether TLS is used) is determined by user if receives a non-recoverable error response to
   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 transaction.

   Similarly if 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 of the Report-Success header is not a default, as "yes", then
   the URL process described herein will
   always explicitly resolve receiving node MUST send a port number.  However, "success" REPORT after the URLs SHOULD be
   configured so request is
   complete to indicate that the recommended port request succeeded.  Likewise if the
   value is used whenever appropriate.
   This makes life easier for network administrators who need "no", it MUST NOT send a success REPORT.

   A consequence of this is that if an MSRP element receives a request
   that has the Report-Failure header set to manage
   firewall policy for MSRP.

   The server part will typically not contain a userinfo component, but
   MAY do so value of "no", it SHOULD
   NOT send any responses to indicate this request, because the element sending
   the request would not do anything with the resulting response.  If
   the value is "partial", it SHOULD NOT send a user account for which 200 response to the session
   request, but SHOULD send a non-200 class response if appropriate.

   If no Report-Success header is valid.
   Note that this present in a SEND request, it MUST be
   treated the same as a Report-Success header with value of "no".  If
   no Report-Failure header is not present, it MUST be treated the same thing as identifying a
   Report-Failure header with value of "yes".  REPORT requests MUST have
   the session
   itself. same Message-ID header value as the request they are reporting
   on.  They MAY also have the Byte-Range of the chunk they are
   reporting on.  If an MSRP element receives a userinfo component exists, REPORT for a Message-ID
   it does not recognize, it SHOULD silently ignore the REPORT.

   Report-Success and Report-Failure MUST NOT be constructed only
   from "unreserved" characters, to avoid present in a need for escape processing.
   Escaping REPORT
   request.  MSRP nodes MUST NOT be used send REPORT requests in an response to
   report requests.  MSRP URL.  Furthermore, a userinfo
   part Nodes MUST NOT contain password information. send MSRP responses to REPORT
   requests.

   The following is an example combinations of a typical MSRP URL:

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

6.1.1  MSRP URL Comparison

   MSRP URL comparisons MUST be performed according reporting may seem overly complex but they are
   needed to meet the following
   rules:

   1.  The schema must match exactly.

   2.  The host part is compared as case insensitive.

   3.  If the port exists explicitly various scenarios of currently deployed IM
   systems.  Report-Success might be "no" in either URL, then it must match
       exactly.  An URL with an explicit port is never equivalent many public systems to
       another with no port specified.

   4.  The resource part
   reduce load but is compared used in some current enterprise systems, such as case insensitive.
   systems used for securities trading.  A URL Report-Failure value of "no"
   is useful for sending system messages such as "the system is going
   down in 5 minutes" without causing a resource part is never equivalent response explosion to one the
   sender.  A Report-Failure of "yes" is used by many systems that includes wish
   to notify the user if the message failed but some other systems
   choose to use 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 value of "partial" to reduce the relevant parts are limited load on the servers
   caused by 200 OK responses, but still allow error responses to unreserved characters.

6.1.2  Resolving be
   sent in many cases.

4.4  MSRP Host Device

   An Connection Model

   When MSRP host device is wishes to send a request to a peer identified by the server part of an MSRP
   URL, it first needs a connection, with the appropriate security
   properties, to the host specified in the URL.  If the server part contains sender already
   has such a numeric IP address and port, they MUST
   be used as listed.

   If connection, that is, one associated with the server part contains a host name same host,
   port, and URL scheme, then it SHOULD reuse that connection.

   When a port, new MSRP session is created, the connecting
   device convention is that the
   element that sent the SDP offer MUST determine a host address by doing an A or AAAA DNS query,
   and use immediately issue a SEND request
   to the port as listed.

   If answerer.  This request MAY have a empty body, or MAY carry
   content.

   When a new connection attempt fails, needs to be formed, the device SHOULD attempt element looks at the
   URL to connect decide on the type of connection (TLS, TCP, etc.) then
   connects to the addresses returned in any additional A or AAAA records, host indicated by the URL, following the URL
   resolution rules in Section 5.2.  For connections using the
   order msrps:
   scheme, the records were presented.

      This process assumes that SubjectAltName in the connection received certificate MUST match the
   hostname port is always known
      prior to resolution.  This is always true for of the MSRP URL uses
      described in this document, and the certificate MUST be valid, including
   having a date that is, URLs always created is valid and
      consumed by automata, rather than being signed by humans.  The introduction of
      relays may create situations where an acceptable
   certificate authority.  At this is not point the case.  For
      example, device that initiated the MSRP URL
   connection can assume that a user enters into a this connection is with the correct host.

   If the connection used mutual TLS authentication, and the TLS client to
      configure it to use
   presented a relay may be intended to be easily
      remembered and communicated by humans, and therefore is likely to
      omit valid certificate, then the port.  Therefore, element accepting the relay specification may describe
      additional steps to resolve
   connection can know the port number.

6.2  Connection Direction identity of the connecting host.  When SIP mutual
   TLS authentication is used as the signaling protocol, not used, the listening device sending the
   initial MUST wait until
   it receives a request on the connection to communicate is responsible for opening determine the
   connection.  In most cases, identity of
   the device sends an offer in an INVITE or
   UPDATE request, and gets connecting device.

   When the first request arrives, it's To-Path header field should
   contain a response URL that the listening element handed out in a 2xx or 18x response.  In
   this case, the inviter opens SDP for a
   session.  The element that accepted the connection after receiving looks up the
   response.  This can be done URL
   in parallel to sending an ACK request.

   Another, less common scenario is when the inviter sends an INVITE
   request with no offer, received request, and determines which session it matches.  If
   a match exists, the invitee sends an offer in the
   response.  In this case, node MUST assume that the inviter opens host that formed the
   connection after it
   receives is the offer.  It waits for successful connection prior to
   sending host that this URL was given to.  If no match
   exists, the answer in node MUST reject the SIP ACK request.

      Open Issue: request with a 481 response.  The delayed offer
   node MUST also check to make sure the session is not likely to work already in SIP, as use
   on another connection.  If so, it MUST reject 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 request with a delayed offer, or remove any reference 506
   response.

      If it were legal to
      this.

   Other signaling protocols may use other approaches.  Unless specific
   behavior is specified for have multiple connections associated with the
      same session, a particular signaling protocol, security problem would exist.  If the
   offerer initial SEND
      request is always responsible for opening not protected, an eavesdropper might learn the URL, and
      use it to insert messages into the session via a different
      connection.
      Open Issue: Should we put in

   If 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 fails for MSRP, why not allow
      using it?

   In all cases, the connecting any reason, then an MSRP 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 MUST
   consider failed any sessions associated with the connection as well.
   When an endpoint notices such a URL that has a matching scheme,
   host part, and port, failure, it SHOULD reuse that connection rather than
   opening attempt to
   re-create any such sessions using a new one.  Once SDP exchange.  If a connection has succeeded, or the decision
   replacement session is successfully created, endpoints MAY attempt to reuse a connection has been made,
   resend any content for which delivery on the connecting device original session could
   not be confirmed.  If it does this, the Message-ID values for the
   resent messages MUST
   immediately send an MSRP request match those used in the context of initial attempts.  If
   the new session.
   This receiving endpoint receives more than one message allows with the device accepting same
   Message-ID.  It SHOULD assume that the connection messages are duplicates.  It
   MAY take any action based on that knowledge, but SHOULD NOT present
   the duplicate messages to associate the MSRP session with user without warning of the connection.  This MAY be a SEND request, if duplicates.

   In this situation, the device has content to send immediately, or a VISIT request.

      Open Issue: We endpoint MUST choose Message-ID values so that
   they are still discussing whether unique in the offerer or context of both the
      answerer should be responsible original session and the
   replacement session.

   When endpoints create a new session in this fashion, the chunks for connecting.

   Either endpoint a
   given logical message MAY tear down be split across the sessions.  However,
   endpoints SHOULD NOT split chunks between sessions under normal
   circumstances.

   If a connection when it no longer has any
   active fails, the sender SHOULD attempt to re-setup the URL
   path using a new offer, for example, in a SIP re-invite or proposed sessions associated with update
   [13].  It MUST not assume that the new URLs in the SDP will be the
   same as the old ones.  A connection SHOULD not be closed while there
   are sessions that are using this connection.

6.3

5.  MSRP Messages URLs

   An MSRP messages are either requests or responses.  Requests and
   responses are distinguished from one another by the first line.  The
   first line of URL follows a Request takes the form subset of the request-start entry
   below.  Likewise, the first line URL syntax in Appendix A of
   RFC2396 [11], with a response takes the form scheme 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)
       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 "msrp" or "msrps":

      MSRP_urls = "Boundary" ":" 0*65(bchars) bcharsnospace
       bcharsnospace= DIGIT / ALPHA / "'" / "(" / ")" /
                         "+" / "_" / "," / "-" / "." /
                         "/" / ":" / "=" / "?"
       bchars msrp-scheme "://" [userinfo "@"] hostport ["/"
      resource] ";" transport
      msrp-scheme = bcharsnospace "msrp" / " "

       Closing "msrps"
      resource = "-------" Boundary Continue-Flag CRLF ; Boundary must match Boundary header field value
       Continue-Flag 1*unreserved
      transport = "+" "tcp" / "$"

       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

   The constructions for "userinfo", "hostport", and "unreserved" are
   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
       Receipt-ID       	= "Receipt-ID" ":" token

   All requests and responses RFC2396 [11].  URLs designating MSRP over TCP 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
   include the Closing field.
   Messages MAY contain "tcp" parameter.  If some other fields, depending transport is used, the
   "tcp" parameter MUST NOT be present.

      Since this document only specifies MSRP over TCP, all MSRP URLs
      herein  use the "tcp" parameter.  Documents that provide bindings
      on other transports should define respective parameters for those
      transports.  A MSRP URL with multiple, contradictory transports is
      invalid, unless some other document specifies meaning for the method or
   response code.

6.3.1  Message Framing
      particular combination of transport parameters.

   An MSRP messages are framed using URL server part identifies a participant in an MSRP session.

   If the Boundary header field value.  The
   Boundary header field server part contains a boundary string. numeric IP address, it MUST also
   contain a port.  The Closing field
   contains the same boundary string with resource part identifies a prefix particular session
   the participant.  The absence of "-------" (seven
   hyphens) and single character suffix representing the resource part indicates a continuation
   flag.

   The closing field is constructed
   reference to allow for simple high speed
   parsing.  The use of seven hyphens forces for of them an MSRP host device, but does not specifically refer to be aligned
   on
   a 32 bit boundary. particular session resource.

   A parser can quickly scan for scheme of "msrps" indicates the closing by
   looking for a 32 bit value equivalent to "----".  Once this word underlying connection MUST be
   protected with TLS.

   MSRP has an IANA registered recommended port defined in Section 15.1.
   This value is
   found, not a default, as the scanner can carefully check and see if this is URL negotiation process described
   herein will always include explicit port numbers.  However, the
   boundary it URLs
   SHOULD be configured so that the recommended port is looking used whenever
   appropriate.  This makes life easier for or just some random data. network administrators who
   need to manage firewall policy for MSRP.

   The boundary
   string SHOULD have at least 16 bits of randomness in it.  For
   example, server part will typically not contain a valid boundary would be "Boundary:6ea7" where the 6ea7 was userinfo component, but
   MAY do so to indicate a randomly chosen four digit hexadecimal number.  This reduces user account for which the
   chance of session is valid.
   Note that this is not the boundary string colliding with content data.

   The boundary string MUST NOT occur inside same thing as identifying the body session
   itself.  The
   sender MUST ensure that  If 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, userinfo component exists, it
      should always MUST be possible to check for boundary collisions prior constructed only
   from "unreserved" characters, to sending avoid a parcel.  Even need for escape processing.
   Escaping MUST NOT be used in the case of streaming content, where
      the sender does not have all an MSRP URL.  Furthermore, a userinfo
   part MUST NOT contain password information.

   The following is an example of the content prior to sending the
      first message, the chunk size should a typical MSRP URL:

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

5.1  MSRP URL Comparison

   MSRP URL comparisons MUST be small enough so that it is
      practical performed according to check each chunk for collisions prior the following
   rules:

   1.  The scheme 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 sending.
       another with no port specified.

   4.  The MSRP boundary strings are distinct and independent from any MIME
   boundaries resource part is compared as case sensitive.  A URL without a
       resource part is never equivalent to one that may exist in the message body.  For example, if includes a resource
       part.

   5.  URLs with different "transport" parameters never match.  Two URLs
       that are identical except for transport are not equivalent.

   6.  Userinfo parts are not considered for URL comparison.

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

5.2  Resolving MSRP Host Device

   An MSRP host device is identified by the server part of a multipart type, an MSRP URL.

   If the MIME headers will include server part contains a
   multipart boundary.  This multipart boundary numeric IP address and port, they MUST NOT
   be the same
   string used in as listed.

   If the MSRP Boundary header field.

   The Closing field server part contains both the message boundary string a host name and a port, the
   Continuation-Flag.  The Continuation-Flag indicates whether the
   entire content has been sent connecting
   device MUST determine a host address by doing an A or not.  Normally, AAAA DNS query,
   and use the flag takes port as listed.

   If a connection attempt fails, the
   value of "$" (dollar sign) device SHOULD attempt to indicate that all content has been
   sent, or "+" connect
   to indicate that there is the addresses returned in any additional content A or AAAA records, in the
   order the records were presented.

      This process assumes that has
   not yet been sent.

   The term "content" the connection port is always known
      prior to resolution.  This is always true for the MSRP URL uses
      described in this context means a complete logical instant
   message, from the perspective 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 user.  The content could be case.  For
      example, the MSRP URL that a
   short text message, user enters into a long file transfer, etc.  The logical instant
   message does not necessarily correspond one-to-one with client to
      configure it to use a physical relay may be intended to be easily
      remembered and communicated by humans, and therefore is likely to
      omit the port.  Therefore, the relay specification [21] may
      describe additional steps to resolve the port number.

   MSRP message. devices MAY use other methods for discovering other such
   devices, when appropriate.  For example, a video message MSRP endpoints may be one logical
   instant message from use other
   mechanisms to discover relays, which are beyond the users' perspective, but it will generally be
   sent as a series scope of parcels.  Each parcel would be sent as this
   document.

6.  Method-Specific Behavior

6.1  Constructing Requests

   To form a new request, the
   payload in one physical sender creates a unique transaction
   identifier and uses this and the method name to create an MSRP SEND request.  All
   request start line.  Next, the requests except sender places the final one would contain "+" target path in a
   To-Path header, and the continuation-flag to indicate
   that sender's URL in a From-Path header.  If
   multiple URLs are present in the content To-Path, the leftmost is not complete. the first
   URL visited; the rightmost URL is the last URL visited.  The final message would contain
   "$"
   processing then becomes method specific.  Additional method-specific
   headers are added as described in the following sections.

   After any method-specific headers are added, processing continues to indicate that complete content has been sent.

   The sender MUST NOT include
   handle a completion-flag of "+" body, if present.  A body in a Non-SEND request MUST NOT be
   longer than 2048 octets.  If the payload
   MIME type does not support content fragmentation.

6.3.2  Message Examples

   The following is an example MSRP message sending request has 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 body, it must contain
   a Content-Type header field.  It may contain other MIME type
   that uses an internal boundary (not to specific
   headers.  The Content-Type header MUST be the last header line.  The
   body MUST be confused separated from the headers with an extra CRLF.

   If 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
   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 contains a transaction if body, the following are true:

      It shares sender MUST check the same TR-ID value.
      It body to
   insure that the closing sequence (a CRLF, seven hyphens, and the
   transaction identifier) is received on not present in the same connection on which body.  If the request was
      sent.
      The To-Path has a single entry, which matches closing
   sequence is present in the response
      recipient's local URI for body, the session.

   Endpoints sender MUST select TR-ID header field values in requests so choose a new
   transaction identifier that
   they are is not repeated by the same endpoint present 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 body, and add 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,
   closing sequence, including the "$" or after "+" character, and a
   timeout interval expires with final
   CRLF.

   Finally, requests which have no response.  Endpoints body MUST treat such
   timeouts in exactly the same way they would treat NOT contain a 500 response.
   The timeout interval SHOULD be 30 seconds, but Content-Type
   header or any other values may be
   established as MIME specific header.  Bodiless requests MUST
   contain a matter of local policy.

6.5  MSRP Sessions

   AN MSRP session is closing sequence after the final header.

   Once a context in which request is ready for delivery, the sender follows the
   connection management (Section 4.4) rules to forward the request over
   an existing open connection or create a series of instant messages
   are exchanged, using new connection.

6.1.1  Delivering SEND requests.  A session has two endpoints,
   identified by MSRP URLs.

6.5.1  Initiating an MSRP session requests

   When an endpoint wishes to engage a peer in has 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 deliver, it first generates a new
   unique Message-ID.  This ID MUST be unique within the purpose scope of this document, we will refer to the endpoint choosing
   to initiate communication as the offerer, and
   session.  If the peer being invited
   as message is larger than 2048 octets in length, it
   either generates an interruptible chunk (which is RECOMMENDED), or it
   MAY break the answerer.

   Under normal circumstances, complete message into chunks of 2048 octets.  It then
   generates a SEND request for each chunk,  following the  answerer procedures
   for constructing requests (Section 6.1).

   Each chunk MUST be prepared to accept contain a connection from Message-ID header field containing the offerer.

   The offerer MUST perform
   Message-ID.  If the following steps:

   1.  Construct sender wishes non-default status reporting, it
   MUST insert a MSRP URL to serve as the local URL.

   2.  Construct Report-Failure and/or Report-Success header field with
   an SDP offer as described in Section 5, including the
       list appropriate value.  All chunks of allowed IM payload formats in the accept-types attribute.
       The offerer puts its local URL into same message MUST use the path attribute, as
       described
   same Report-Failure and Report-Success values 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. their SEND requests.

   If success reports are requested, the answerer chooses sending device MAY wish to participate, it MUST perform the following
   steps:

   1.  Store the contents run
   a timer of the offered sdp path attribute as the
       remote path some value that makes sense for he session.

   2.  Construct it's application and take
   action if a MSRP URL that resolves to itself.  Save success Report is not received in this as the
       local URL time.  There is no
   universal value for the session.

   3.  Listen this timer.  For many IM applications, it may be
   2 minutes while for some trading systems it may be under a connection on second.
   Regardless of whether such a timer is used, if the transport, address, and port
       described success report has
   not been received by the local URL.

   4.  Send a SDP answer via time the signaling protocol, according to session is ended, the
       following rules:

       1. device SHOULD
   inform the user.

   The C-line is copied unmodified from first chunk of the offer.

       2. message SHOULD, and all subsequent chunks MUST
   include a Byte-Range header field.  The accept-types attribute contains range-start field MUST
   indicate the SEND payload media
           types that position of the answerer is willing to accept.  The
           accept-types attribute first byte in the answer MUST be either body in the same
           as that overall
   message.  The range-end field SHOULD indicate the position 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
   last byte in the SDP answer. body, if known.  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 take the SDP answer as value of "*" if
   the
       remote path.

   2.  Designate position is unknown, or if the first entry in request needs to be interruptible.
   The total field SHOULD contain the remote path as total size of the adjacent-hop
       URL.

   3.  Check to see message, if
   known.  The total filed MAY contain a connection already exists that is associated
       with URL that matches "*" if the scheme, host part, and port total size of the
       adjacent-hop URL.  If such a connection exists, the device SHOULD
       reuse it, rather
   message is not known in advance.  All chunks other than opening a new connection.

   4.  If no matching connection exists, attempt to open the last MUST
   include a connection to "+" character in the adjacent hop using continuation field of the transport, address, port, and
       protection mode designated by closing
   line.  The final chunk MUST use a "$" character.  The sender MUST
   send all chunks in Byte-Range order.  (However,the receiver cannot
   assume the adjacent-hop URL.

   5. requests will be delivered in order, as an intervening
   relay may have changed the order.)

   If the connection succeeds, or if a connection is reused,
       immediately sender chooses to send a MSRP request to body larger than 2048 octets in a
   single chunk, the opposite peer.  This
       SHOULD request MUST be a visit request, but MAY constructed so that it can be a
   interrupted.  A SEND request is interruptible if the
       endpoint it either 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 no
   Byte-Range header field, or VISIT request.  When an endpoint receives has such a request, it
   MUST perform the following procedures:

   1.  Check if state exists for a session field with a local URL that matches
       the To-Path header field value of "*" in the VISIT request.  If so, and
       if no previous
   last-byte sub-field.

   A SEND request has been received for that URL on a
       different connection, then return is interrupted while a 200 response, and save state
       associating the first URL body is in the From-Path header field with process of being
   written to the connection on which the request was received .

   2.  If by simply noting how much of 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 message
   has already 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 written to the
   following process:

   1.  Insert a To-Path header field containing connection, then writing out the path
   boundary string to end the opposite
       endpoint, chunk.  It can then be resumed in order from left to right.

   2.  Insert a From-Path
   another chunk with the same Message-ID and a Byte-Range header range
   start field containing the local URL.

   3.  Insert the message payload in the body, and the media type in the
       Content-Type header field.  The media type MUST match one position 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 first byte after the explicitly listed entries, but MAY
   interruption occurred.

   SEND requests larger than 2k MUST 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 interrupted to send pending
   response or REPORT requests.  If multiple SEND requests from
   different sessions are concurrently being sent over the same value.

   5.  Send
   connections, the device SHOULD implement some scheme to alternate
   between them such that each concurrent request on the connection associated with the session.

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

   7.  If gets a 415 response is received, this indicates the recipient is
       unable or unwilling chance to send
   some fair portion of data at regular intervals suitable to process the media type.
   application.

   The sender SHOULD MUST NOT attempt to send assume that particular media type again in the
       context of this session.

   8.  If any other response code a message is received, or if the transaction
       times out, the endpoint SHOULD assume received by the session has failed,
       either tear down peer
   with the session, same chunk allocation it was sent with.  An intervening
   relay could possibly break SEND requests into smaller chunks, or attempt to re-establish the
       session by sending an updated SDP offer proposing a new
       connection.  If a new connection
   aggregate multiple chunks into larger ones.

   The default disposition of body is established, "render".  If the endpoint sender wants
   different disposition, it 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 insert a new connection Content-Disposition header.
   Since MSRP 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 binary protocol, transfer encoding MUST be "binary".

6.1.2  Sending REPORT requests

   REPORT requests are associated with same stream, and of
      course, specify what it means for a stream similar to span connections.

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

   1.  Check requests, except that it has state for a session with report
   requests MUST NOT include Report-Success or Report-Failure header
   fields, and MUST contain a local URL matching Status header field.  REPORT requests MUST
   contain the To-Path value. Message-ID header from the original SEND request.

   An MSRP endpoint MUST be able to generate success REPORT requests.

   REPORT requests MAY include a body.  If no matching session exists, return a 481
       response.

   2.  Determine that body is included, it understands SHOULD
   be of the media DSN MIME type detailed in the body, RFC1894 [8], but MAY be of some
   other type 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 sender of local policy.  If
       the message contained no body at all, the endpoint should quietly
       ignore it.

   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 SEND request indicated support in the SDP exchange.

6.5.4  Ending a Session

   When either endpoint in an MSRP session wishes to end
   "receipt-type" parameter of the session, it
   first signals its intent using respective Report-Success or
   Report-Failure header field.  This parameter contains the normal processing alternative
   MIME type that SHOULD be used for this particular report.  A client
   specifying an alternative 'receipt-type' for an MSRP transaction MUST
   also be capable of receiving the
   signaling protocol.  For example, default format specified in SIP, it would send a BYE request
   to the peer.  After agreeing to end the session, this
   RFC1894.  Use of the host DSN MIME format in MSRP is described in Section
   8

   An endpoint MUST release any resources acquired as part send a success report if it successfully receives a
   SEND request which contained a Report-Success value of "yes", and
   either contains a complete message, or contains the session.

   Each peer MUST destroy all local state for last chunk needed
   to complete the session. message.  This
   involves completely removing request is sent following the state entry for normal
   procedures (Section 6.1), with a few additional requirements.

   The endpoint inserts a To-Path header field containing the session and
   invalidating From-Path
   value from the session URL.

   If no other sessions are using original request, and a From-Path header containing
   the connection, URL identifying itself in the session.  The endpoint that
   opened it SHOULD tear it down.  However, then inserts
   a  Status header field with a namespace of "000", a short-status of
   "200" and a relevant Reason phrase, and a Message-ID header field
   containing the passive party MAY tear
   down an unused connection after value from the original request.

   Positive status reports SHOULD NOT include a locally configured timeout period.

   When an payload.

   The endpoint chooses to close a session, it may have SEND
   transactions outstanding.  For example, it may have MUST NOT send SEND
   requests to which it has not yet received a response, or it may have
   received success report for a SEND requests request that to which it has not responded.  Once
   either contained no Report-Success header field, or contained such a
   field with a value of "no".

6.1.3  Failure REPORT Generation

   If an MSRP endpoint has decided to close the connection, receives a SEND request that it SHOULD wait cannot process
   for such
   outstanding transactions to complete.  It SHOULD NOT generate any new
   SEND transactions, some reason, and it MAY choose the Report-Failure header either was not to respond to any new SEND
   requests that are received after it decides to close present
   in the session.  It
   SHOULD not respond to any new messages that arrive after original request, or had a value of "yes", it signals
   its intent to close the session.

   When SHOULD simply
   send a transaction response with an appropriate error response code.
   However, there may be situations where the error cannot be determined
   quickly, such as when the endpoint is signaled of its peer's intent to close a session,
   it SHOULD NOT initiate any more SEND requests.  It SHOULD gateway that must wait for
   any outstanding transactions that it initiated a
   downstream network to complete, and indicate an error.  In this situation, it
   SHOULD attempt respond to any open SEND transactions received prior
   to being signaled.

   It is not possible MAY
   send a 200 OK response to completely eliminate the chance of request, and then send a session
   terminating with incomplete SEND transactions.  When this occurs, the
   endpoint SHOULD clearly inform the user that failure REPORT
   request when the messages may not
   have been delivered.

6.5.5  Managing Session State and Connections

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

   If the connection fails for any reason, the device MUST invalidate
   the session state for all sessions using the connection.  Once a
   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 receives a new SDP exchange to
   negotiate SEND request with a new session URL.  Otherwise, Report-Failure header
   field value of "none", then it MUST NOT send a failure REPORT
   request, and SHOULD attempt NOT send an MSRP response.

   Construction of failure REPORT requests is identical to tear
   down that for
   success reports, except the session using the rules of the signaling protocol.

      It would be nice to allow sessions to Status header code and reason fields
   SHOULD contain appropriate error codes.  Any error response code
   defined in this specification MAY also be recovered after used in failure reports.
   Failure REPORT requests MAY contain a
      connection failure, perhaps payload, using the DSN MIME
   type.  They MAY contain some other type if allowed by allowing a receipt-type
   in the active endpoint to
      reconnect, and send Report-Failure header field.

   If a new VISIT request.  However, this approach
      creates failure report is sent in response to a race condition between the time SEND request that
   contained a chunk, it MUST include a Byte-Range header indicating the hosting device
      notices
   actual range being reported on.  It can take the failed connection, range-start and
   total values from the time that the endpoint
      tries to recover original SEND request, but MUST calculate the session.  If
   range-end field from the endpoint attempts to
      reconnect prior actual body data.

   Endpoints SHOULD NOT send REPORT requests if they have reason to
   believe the hosting device noticing the failure, the
      hosting device request will interpret the recovery attempt as a conflict.
      The only way around this would not be to force the hosting device to
      do delivered.  For example, they SHOULD
   NOT send a liveness check REPORT request 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 session that is used to convey both positive and negative status
   of messages in the network. no longer valid.

      This functionality is extremely useful section only describes failure report generation behavior for
      MSRP sessions that traverse a relay device. endpoints.  Relay support behavior is
   considered out of beyond the scope for of this specification
      document, and will be included considered in a separate specification.  This section will only cover
   functionality required document.  We
      expect failure reports to be more commonly generated by non-relay aware endpoints for basic MSRP
   operation.  An relays
      than by endpoints.

6.2  Constructing Responses

   If an MSRP endpoint receives a request that either contains a
   Report-Failure header value of "yes", or does not contain a
   Report-Failure header field at all, it MUST be capable immediately generate a
   response.  Likewise, if an MSRP endpoint receives a request that
   contains a Report-Failure header value of performing the DSN
   operations described in this specification "partial", and the receiver
   is unable to process the request, it SHOULD support immediately generate a
   response.

   To construct the response, the DSN
   MIME type outlined.  An MSRP endpoint MAY use an alternative payload
   for reporting message status using first creates the procedures outlined response
   start-line, inserting appropriate response code and reason fields.
   The transaction identifier in this
   specification.

6.6.1  Endpoint DSN Request

   An the response start line MUST match the
   transaction identifier from the original request.

   The endpoint that wishes to be informed of message delivery/failure
   needs to then inserts an appropriate To-Path header field.  If
   the request such information.  This triggering the response was a SEND request, the To-Path
   header field is achieved formed by including an
   MSRP Receipt-Request header copying the last (right-most) URI in the request.  The
   From-Path header can equal one field of three values:

   negative:  Indicates the client request.  (Unlike other methods,
   responses to SEND requests are returned only requires failure delivery
      report.
    none:  Indicates to the client requires no delivery reports.
   all:  Indicates previous hop.)
   For responses to all other requests, the client requires both positive To-Path header field
   contains the full path back to the original sender.  This full path
   is generated by taking the list of URLs from the From-Path of the
   original request, reversing the list, and negative
      delivery reports.

   Within writing the scope reversed list
   into the To-Path of the response.  (Legal REPORT requests do not
   request responses, so this specification doesn't exercise the Receipt-Request header is
   only used in MSRP SEND requests.  Future extensions to this
   specification MAY use the mechanism
   behavior described in this document for
   delivery/failure status notification of other MSRP requests.

   The default value above, however we expect that extensions for this header if not present in
   gateways and relays will need such behavior.)

   Finally, the endpoint inserts a request is
   'negative'.  An example of this From-Path header would be:

      Message-Receipt: negative

   The default DSN MIME type is detailed field containing the
   URL that identifies it in RFC 1894[10].  It is
   possible for MSRP endpoints to use a different format if required.
   This can be achieved the context of the session, followed by including a 'receipt-type' parameter in the
   Message-Receipt header.  This parameter contains
   closing sequence after the alternative MIME
   type that SHOULD be used for this particular receipt transaction.  A
   client specifying an alternative 'receipt-type' for an MSRP
   transaction last header field.  The response MUST also be capable of
   transmitted back on the same connection on which the original request
   arrived.

6.3  Receiving Requests

   The receiving endpoint must first check the default format
   specified URL in this document.  This allows intermediaries, such as MSRP
   relays, the To-Path to generate failure reports when MSRP transaction failure
   occurs.

6.6.2  DSN generation

   An MSRP endpoint implementing this specification SHOULD be able
   make sure the request belongs to
   generate positive delivery status of MSRP requests.  On receiving an
   MSRP existing session.  When the
   request containing a Message-Receipt header with a value of
   'all', is received, the endpoint To-Path will carry out normal MSRP response generation
   and have exactly one URL, which
   MUST generate map to an MSRP REPORT existing session that is associated with the
   connection on which the request using arrived.  If this is not true, and
   the following
   procedures:

   1.  Insert request contained a To Report-Failure header containing the From value from of "no", then the
   receiver SHOULD quietly ignore the original request.
   2.  Insert a From  If the Report-Failure
   header containing is not present, or had any other value, then the To value from receiver MUST
   return a 481 response.

   Further request processing by the original
       request.
   3.  Insert receiver is method specific.

6.3.1  Receiving SEND requests

   When the message status payload in receiving endpoint receives a SEND request, it first
   determines if it contains a complete message, or a chunk from a
   larger message.  If the body request contains no Byte-Range header, or
   contains one  with a range-start value of "1", and the request.  If
       the default DSN MIME type from DSN[10] is used closing line
   continuation flag has a value of "$", then the MSRP
       Content-Type header MUST use request contained the
   entire message.  Otherwise, the receiver looks at the Message-ID
   value multipart/report.  The
       relevance to associate chunks together into the original message.  It
   forms a virtual buffer to receive the message, keeping track of DSN headers which
   bytes have been received and which are missing.  The receiver takes
   the data from the request and places it in MSRP can be found the appropriate place in section 7.6.5.
       An alternative MIME type MAY be used but
   the buffer.  The receiver MUST be specified in determine the
       Content-Type header.  Negative DSN generation actual length of each
   chunk by inspecting the payload itself; it is considered out possible the body is
   shorter than the range-end field indicates.  This can occur if the
   sender interrupted a SEND request unexpectedly.  It is worth nothing
   that the chunk that has a termination character of "$" defines the
   total length of the message.

   What is done with the body is outside 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 and largely
   determined by the value
       from 'multipart/byteranges' MIME header Content-range from type.  The body MAY be rendered after the
       payload of a chunked message.  It
   whole message is possible that an entity
       downstream may decide to break up an MSRP received or partially rendered as it is being
   received.

   If the SEND message and request contained a Content-Type header field indicating
   an unsupported MIME type, the receiver SHOULD send
       it in separate chunks.  The originating client would be
       transparent to this operation but would need to be informed if a
       DSN only represents part of 415 response, if
   allowed by 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 Report-Failure header field.  All MSRP endpoint implementing this specification endpoints 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 multipart/mixed and multipart/alternative MIME
   types.

   If the SEND request contained a Report-Success 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

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 a
   value that appeared in of "yes", and the original MSRP request into is either contains the
   'original-envelope-id' field.  This allows a requesting client entire message
   or the last chunk needed to
   explicitly correlate complete a message, the receiver MUST
   send a success REPORT request with back to the original request.
   This correlation is implementation specific and makes no requirements
   on clients sender.

6.3.2  Receiving REPORT requests

   When an endpoint receives a REPORT request, it may correlate it to hold state for transactions ID's.  Information
   regarding
   the original SEND request can be obtained from using the DSN MIME type
   outlined in [10].

6.6.5.4  reporting-mta

   The 'reporting-mta-field' MUST follow Message-ID and the guidelines set out in RFC
   1894[10].  The 'mta-name-type' from RFC1894[10] MUST use Byte-Range, if
   present.  If it requested success reports, then it SHOULD keep enough
   state about each outstanding sent message so that it can correlate
   REPORT requests to the value of
   'msrp-name-type', as defined in section 9 of this specification.  The
   'mta-name' value for this original messages.

   An endpoint that receives a REPORT request containing a Status header
   with a namespace 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 "000", it SHOULD interpret the value contained report in
   exactly the same way it would interpret an MSRP 'To' header from the
   original request being reported on.

6.6.5.6  action

   The 'action' field MUST follow transaction response
   with a response code matching the guidelines set out in RFC
   1894[10].  An MSRP entity constructing short-code field.

   It is possible to receive a DSN failure report MUST use the
   'delivered' value or a failure transaction
   response for a successful delivery and MUST use chunk that is currently being delivered.  In this case
   the 'failed'
   value for an un-successful delivery.  The other values specified entire message corresponding to that chunk should be aborted.

   It is possible that an endpoint will receive a REPORT request on a
   session that is no longer valid.  The endpoint's behavior if this
   happens is a matter of local policy.  The endpoint is not required to
   take any steps to facilitate such late delivery, i.e.  it is not
   expected to keep a connection active in case late REPORTs might
   arrive.

7.  Using MSRP with SIP

7.1  SDP Offer-Answer Exchanges for MSRP Sessions

   MSRP sessions will typically be initiated using the 'action' field Session
   Description Protocol (SDP) [2] via the SIP offer-answer mechanism
   [3].

   This document defines a handful of new SDP parameters to setup MSRP
   sessions.  These are detailed below and in RFC 1894[10] MAY be used.

6.6.5.7  status the IANA Considerations
   section.

   The 'status' field general format of an SDP media-line is:

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

   An offered or accepted MSRP media-line MUST follow have the guidelines following value
   exactly, with the exception that the port field MAY be set out in RFC
   1894[10].  An MSRP entity constructing to zero.
   (According to [3], a DSN report user agent that wishes to accept an offer, but
   not a specific media-line MUST represent set the port number of that media-line
   to zero (0).)

   m=message 9 msrp *

      While MSRP status code in could theoretically carry any media type, "message" is
      appropriate.  For MSRP, the correct format detailed port number is always ignored--the
      actual port number is provided in RFC 1894[10]
   for an MSRP URL.  Instead "9" is
      used, which is an innocuous value which is assigned to the 'status' field discard
      port.  The protocol is always "msrp", and the value of the format
      list is always a DSN report. single asterisk character ("*").

   An MSRP status code consists
   of a three digit number while a DSN status media-line is three digits separated always accompanied by '.'.  An example would be:

   Status: 5.0.0 (unknown permanent failure)
   When generating a mandatory "path"
   attribute.  This attribute contains a space separated list of URLs
   that must be visited to contact the user agent advertising this field
   session-description.  If more than one URL is present, the leftmost
   URL is the first digit of URL that must be visited to reach the MSRP status code
   (working from left target
   resource.  (The path list can contain multiple URLs to right) MUST be placed in allow for the first part
   deployment of gateways or relays in the
   'status' DSN field.  The second digit future.)  MSRP
   implementations which can accept incoming connections will typically
   only provide a single URL here.

   MSRP media lines MUST also be placed in the second
   part accompanied by an "accept-types"
   attribute.  This attribute contains a list of MIME types which are
   acceptable to the 'status' DSN field.  The third digit MUST be placed endpoint.

   A "*" entry in the third part of accept-types attribute indicates that 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 sender
   may attempt to a DSN 'status' field MAY be enclosed
   in parentheses if required.

6.7  Message Fragmentation

   MSRP devices SHOULD break large send content into fragments, with media types that have not been
   explicitly listed.  Likewise, an entry with an explicit type and send each
   fragment in a separate SEND request.  A message fragment sent in this
   way is known
   "*" character 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], subtype indicates that the sender may attempt to correlate
   parts
   send content with any subtype of the message.  The definition of large is determined by local
   policy. that type.  If the receiver receives
   an MSRP endpoints MUST be capable of receiving request and processing
   fragmented messages.

      Open Issue: Do we want is able to negotiate process the use of message/byteranges
      like media type, it does so.
   If not, it will respond with a 415 response.  Note that all explicit
   entries SHOULD be considered preferred over any other MIME type? I assume no, as we want to allow relays
      to fragment messages, and relays are not privy to non-listed types.

   This feature is needed as, otherwise, the
      content-types negotiated list of formats for a session.

   Although relays 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 not
   used, the types listed in scope for this document, we expect that
   relays will the accept-types attribute may be able to introduce fragmentation, as well used both
   as change the
   fragmentation of previously fragmented messages.  Therefore, all MSRP
   endpoints MUST root payload, or may be able to receive fragmented messages.

6.7.1  MSRP Usage of message/byteranges

   The "message/byteranges" type allows multiple ranges wrapped in a single
   document.  However, MSRP devices listed container type.
   Any container types MUST NOT include more than one byte
   range also be listed in a single request.  Although the HTTP usage for accept-types
   attribute.

   Occasionally an endpoint will need to specify a document
   containing MIME body type that
   can only be used if wrapped inside a single byte range indicates putting listed container type.

   Endpoints MAY specify MIME types that are only allowed when wrapped
   inside compound types using the "Content-Range"
   header in a header field, rather  than "accept-wrapped-types" attribute in the body itself,
   "Content-Range" MUST NOT appear as
   an MSRP header field.

      Open Issue: How much SDP a-line.

   The semantics for accept-wrapped-types are identical to those of the message/byteranges specification
      should we explain or copy forward? Copying too much obscures
   accept-types attribute, with the
      fact exception that rfc2616 is the normative definition, but it specified types
   may only be
      helpful to have more context here.

   If used when wrapped inside containers.  Only types listed
   in the MSRP device has a priori knowledge of accept-types attribute may be used as the overall content
   length, it SHOULD put that length into instance-length.  The device
   MAY place "root" type for the
   entire body.  Since any type listed in accept-types may be used both
   as a "*" root body, and wrapped in instance-length if it other bodies, format entries from
   accept-types SHOULD NOT be repeated in this attribute.

   This approach does not have such
   knowledge.

   Similarly, if the device has a priori knowledge allow for specifying distinct lists of the number
   acceptable wrapped types for different types of
   bytes in containers.  If an
   endpoint understands a byte range, it SHOULD place the last byte position MIME type in
   last-byte-pos.  Otherwise, the context of one wrapper, 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
   assumed to understand it in first-byte-pos.

6.8  Method Descriptions

   This section summarizes the purpose context 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 any other acceptable
   wrappers, subject to any constraints defined by the individual method.

6.8.1  SEND wrapper types
   themselves.

      The SEND method is used by both approach of specifying types that are only allowed inside of
      containers separately from the host and visitor endpoints primary payload types allows an
      endpoint to
   send instant force the use of certain wrappers.  For example, a
      CPIM [14] 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 endpoint.  A SEND request MUST
   contain a To-Path header field containing might attempt to use
      those types without the sender's remote path, a
   From-Path header field containing wrapper.
      All types listed in either the sender's local URL, and a
   Message-ID header field.  SEND requests SHOULD contain accept-types or
      accept-wrapped-types attributes MAY include a MIME body
   part.  The body max-size parameter,
      indicating the largest message it is willing to accept of that
      type.  Max-size refers to the complete message, not the size of
      any one chunk.  Senders MUST be NOT exceed the max-size limit, if
      any, when sending messages of any listed type.  If a media type included in is
      listed without the format list parameter, then no preset size limit exists.

           accept-types = accept-types-label ":" format-list
           accept-types-label = "accept-types"
           accept-wrapped-types = wrapped-types-label ":" format-list
           wrapped-types-label = "accept-wrapped-types"
           format-list = format-entry *( SP format-entry)
           format-entry = ctype [SEMI max-size]
           ctype = (type "/" subtype) / (type "/" "*") / ("*")
           type = token
           subtype = token
           max-size = "max" "=" 1*(DIGIT)

7.1.1  URL Negotiations

   Each endpoint in an MSRP session is identified by a URL.  These URLs
   are negotiated in the SDP exchange.  If a body is present, the request  Each SDP offer or answer 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 one or more MSRP URL in a SEND request. path attribute.  This is not included in
      this version for attribute has
   the sake of getting the draft out as soon following syntax:

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

   where MSRP_URL is an msrp: or msrps: URL as
      possible, but will follow soon.

6.8.2  VISIT

   The visiting endpoint defined in Section 5.
   MSRP URLs included in an SDP offer or answer MUST include  explicit
   port numbers.

   An MSRP device uses the VISIT method URL to associate a network
   connection with the session state at the listening device.  A VISIT
   request MUST include determine a To-Path header including the sender's remote
   path, host address, port,
   transport, and protection level when connecting, 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 identify the
   target when sending requests and VISIT as currently
      defined.  We should consider either removing VISIT entirely responses.

   The offerer and
      just use an empty SEND request, or we should always require VISIT.
      (This would not apply to answerer each selects a endpoint connecting URL to its own relay.)

6.8.3  REPORT

   Report is used by an endpoint or relay represent itself, and
   send it 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 peer device in the original request, and To-Path and From-Path
   headers matching those of SDP document.  Each device stores
   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 path value received from the SEND request contained a MIME
   content-type peer, and uses that is not understood by value as the receiver.

6.9.4  426

   A 426 response indicates that
   target for requests inside the request resulting session.  If the path
   attribute received from the peer contains more than one URL, then the
   target URL is the rightmost, while the leftmost entry represents the
   adjacent hop.  If only allowed over TLS
   protected connections.

6.9.5  481

   A 481 response indicates that no session exists for one entry is present, then it is both the connection.

6.9.6  506

   A 506 response indicates that peer
   and adjacent hop URL.  The target path is the entire path attribute
   value received from the peer.

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

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

   The rightmost URI in which the
   To-Path header indicates a local path attribute MUST identify the endpoint
   that is already generated the SDP document, or some other location where that
   endpoint wishes to receive requests associated with
   another connection.  A 506 response the session.  It
   MUST NOT be returned assigned  for this particular session, and MUST NOT duplicate
   any URI in response
   to use for any method other than VISIT.

6.10  Header Field Descriptions

   This section summarizes session in which the various header fields. endpoint is
   currently participating.  It SHOULD be hard to guess, and protected
   from eavesdroppers.  This is discussed in more detail in Section 14.

7.1.2  Path Attributes with Multiple URLs

   As mentioned previously, this document describes MSRP header
   fields are single valued; for
   peer-to-peer scenarios, 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 when no relays are used.  However,
   we expect a response separate document to describe 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 use of relays.  In
   order to allow an MSRP device that only implements the corresponding request.  TR-ID
   cannot be used for core
   specification to interoperate with devices that use relays, this purpose, as it may change between hops if
   relays are involved.  A Message-ID value MUST be unique among all
   values used by
   document must include a given few assumptions about how relays work.

   An endpoint inside that uses one or more relays will indicate that by
   putting a given session.  MSRP
   elements MUST NOT assume any additional semantics URL for Message-ID.
   The Message-ID value MAY be each device in the same as relay chain into the original TR-ID value.

6.10.3  To-Path SDP path
   attribute.  The To-Path header field is used final entry would point to indicate the sender's remote
   path.  All MSRP requests MUST contain a To-Path header field.

6.10.4  From-Path endpoint itself.  The From-Path header field is used to
   other entries would 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 each proposed relay, in the
   message. order.  The Boundary header field is mandatory for all MSRP
   messages, and SHOULD be
   first entry would point to the first header field relay in the message.

6.10.6  Closing

   The Closing field contains the same boundary string chain; that was
   originally listed in is, the Boundary header field, as well as
   relay to which the
   Continuation-Flag field.  The Closing field MUST occur 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 end of
   each MSRP message.  If path
   attribute.  This URL represents both the message content has been sent completely, endpoint for the Interrupt-Flag field value MUST be ""$ (dollar sign).  If there
   is further content to send as part of session,
   and the "logical" instant message, connection point.

   While endpoints that implement only this field value MUST specification will never
   introduce a relay, they will need to be "+".  (plus sign.)

6.10.7  Content-Type

   The Content-Type header field is used able to indicate the MIME media type
   of the body.  Content-Type interoperate with
   other endpoints that do use relays.  Therefore, they MUST be present if a body is present.

      To Do: The work group has agreed prepared
   to allow the use of any standard
      MIME header.  This is not reflected receive more than one URL in this version, but will be the SDP path attribute.  When an
   endpoint receives more than one URL in a shortly forthcoming one.

7.  Example

   This section shows an example message flow for path header, only the most common
   scenario.  The example assumes SIP first
   entry is used to transport the SDP
   exchange.  Details relevant for purposes of resolving the SIP messages address and SIP proxy infrastructure
   are omitted for port, and
   establishing the sake of brevity.  In network connection, as it describes the example, assume first
   adjacent hop.

   If an endpoint puts more than one URL in a path attribute, the
   offerer is sip:alice@atlanta.com and 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.

7.1.3  Updated SDP Offers

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

   Either peer may initiate an updated exchange at any time.  The
   endpoint that sends the new offer assumes the role of offerer for all
   purposes.  The answerer MUST respond with a path attribute that
   represents a valid path to itself at the time of the updated
   exchange.  This new path may be the same as its previous path, but
   may be different.  The new offerer MUST NOT assume that the peer will
   answer with the same path it used previously.

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

7.1.4  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 9 msrp *
    a=accept-types: message/cpim text/plain text/html
    a=path:msrp://alice.example.com:7394/2s93i9;tcp

   B responds with its own URL:

    v=0
    o=userb 2890844530 2890844532 IN IP4 bob.example.com
    s=
    c=IN IP4 bob.example.com
    t=0 0
    m=message 9 msrp *
    a=accept-types:message/cpim text/plain
    a=path:msrp://bob.example.com:8493/si438ds;tcp

7.1.5  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 the COMEDIA [24]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 a default connection direction.

7.2  MSRP User Experience with SIP

   In typical SIP applications, when an endpoint receives an INVITE
   request, it alerts the user, and waits for user input before
   responding.  This is analogous to the typical telephone user
   experience, where the callee "answers" the call.

   In contrast, the typical user experience for instant messaging
   applications is that the initial received message is immediately
   displayed to the user, without waiting for the user to "join" the
   conversation.  Therefore, the principle of least surprise would
   suggest that MSRP endpoints using SIP signaling SHOULD allow a mode
   where the endpoint quietly accepts the session, and begins displaying
   messages.

   SIP INVITE requests may be forked by a SIP proxy, resulting in more
   than one endpoint receiving the same INVITE.  SIP early media [28]
   techniques can be used to establish a preliminary session with each
   endpoint, and canceling the INVITE transaction for any endpoints that
   do not send MSRP traffic after some period of time.

8.  DSN payloads in MSRP REPORT Requests

   The format of a default REPORT request payload format the DSN taken
   from RFC1894 [8].  Only a minimal subset of fields are relevant for
   MSRP, as detailed in the remainder of this section.

8.1  Per-Message DSN header usage

   original-envelope-id: See Section 8.3

   reporting-mta:       See Section 8.4

   dsn-gateway: Not Used
   received-from-mta: Not Used

   arrival-date: Not Used

8.2  Per-Recipient DSN header usage

   original-recipient           Not Used

   final-recipient: See Section 8.5

   action: See Section 8.6

   status: See Section 8.7

   remote-mta: Not Used

   diagnostic-code: Not Used

   last-attempt-date: Not Used

   will-retry-until:Not Used

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

8.4  reporting-mta

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

8.5  final-recipient

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

8.6  action

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

8.7  status

   The 'status' field MUST follow the guidelines set out in RFC 1894[8].
   An MSRP entity constructing a DSN report MUST represent the MSRP
   status code in the correct format detailed in RFC 1894[8] 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)

   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.

9.  Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC-2234 [6].

   msrp-req-or-resp = msrp-request / msrp-response
   msrp-request = req-start headers [content-stuff] end-line
   msrp-response = resp-start headers end-line

   req-start  = pMSRP SP transact-id SP method CRLF
   resp-start = pMSRP SP transact-id SP status-code [SP phrase] CRLF
   phrase = utf8text

   pMSRP = %4d.53.52.50 ; MSRP in caps
   transact-id = ident
   method = mSEND / mREPORT / other-method
   mSEND = %53.45.4e.44 ; SEND in caps
   mREPORT = %52.45.50.4f.52.54; REPORT in caps

   other-method = 1*UPALPHA
   status-code = 3DIGIT

   headers = 1*( header CRLF )

   header = ( To-Path
    / From-Path
    / Message-ID
    / Report-Success
    / Report-Failure
    / Byte-Range
    / Status
    / Mime-Header
    / ext-header )

   To-Path = "To-Path:" SP URL *( SP URL )
   From-Path = "From-Path:" SP URL *( SP URL )
   Message-ID = "Message-ID:" SP ident
   Report-Success = "Report-Success:" SP ("yes" / "no" )
   Report-Failure = "Report-Failure:" SP ("yes" / "no" / "partial" )
   Byte-Range = "Byte-Range:" SP range-start "-" range-end "/" total
   range-start = 1*DIGIT
   range-end   = 1*DIGIT / "*"
   total       = 1*DIGIT / "*"
   Status = "Status:" SP namespace SP short-status [SP text-reason]

   ident = alphanum  3*31ident-char
   ident-char = alphanum / "." / "-" / "+" / "%" / "="

   content-stuff = *(Other-Mime-Header CRLF)
                   Content-Type 2CRLF data CRLF

   Content-Type = "Content-Type:" SP media-type
   media-type = type "/" subtype *( ";" gen-param )
   type = token
   subtype = token

   gen-param = pname [ "=" pval ]
   pname = token
   pval  = token / quoted-string

   token = 1*(alphanum / "-" / "." / "!" / "%"
                       / "*" / "_" / "+"

   quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE
   qdtext = SP / HT / %x21 / %x23-5B / %x5D-7E
               / UTF8-NONASCII
   qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE)
   BACKSLASH = "\"
   DQUOTE = %x22

   Other-Mime-Header = (Content-ID
    / Content-Description
    / Content-Disposition
    / mime-extension-field);

       ; Content-ID, and Content-Description are defined in RFC2045.
       ; Content-Disposition is defined in RFC2183
       ; MIME-extension-field indicates additional MIME extension
       ; headers as described in RFC2045

   data = *OCTET
   end-line = "-------" transact-id continuation-flag CRLF
   continuation-flag = "+" / "$"

   ext-header = hname ":" SP hval CRLF
   hname = alpha *token
   hval = utf8text

   utf8text = *(HT / %x20-7E / UTF8-NONASCII)

   UTF8-NONASCII = %xC0-DF 1UTF8-CONT
                 / %xE0-EF 2UTF8-CONT
                 / %xF0-F7 3UTF8-CONT
                 / %xF8-Fb 4UTF8-CONT
                 / %xFC-FD 5UTF8-CONT
   UTF8-CONT     = %x80-BF

10.  Response Code Descriptions

   This section summarizes the semantics of various response codes that
   may be used in MSRP transaction responses.  These codes may also be
   used in the Status header in REPORT requests.

10.1  200

   The 200 response code indicates a successful transaction.

10.2  400

   A 400 response indicates a request was unintelligible.

10.3  403

   The action is not allowed

10.4  415

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

10.5  426

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

10.6  481

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

10.7  506

   A 506 response indicates that a request arrived on a session which is
   already bound to another network connection.

11.  Examples

11.1  Basic IM session

   This section shows an example 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@example.com and the answerer is
   sip:bob@biloxi.com.

           Alice                     Bob sip:bob@example.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.example.com:7777/iau39;tcp .

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

        v=0
        o=alice 2890844557 2890844559 IN IP4 alicepc.example.com
        s=
        c=IN IP4 alicepc.example.com
        t=0 0
        m=message 9 msrp *
        a=accept-types:text/plain
        a=path:msrp://alicepc.example.com:7777/iau39;tcp

   2.  Bob listens on port 8888, and sends the following response:
   3.  Bob->Alice (SIP): 200 OK

        v=0
        o=bob 2890844612 2890844616 IN IP4 bob.example.com
        s=
        c=IN IP4 bob.example.com
        t=0 0
        m=message 9 msrp *
        a=accept-types:text/plain
        a=path:msrp://bob.example.com:8888/9di4ea;tcp

   4.  Alice->Bob (SIP): ACK

   5.  (Alice opens connection to Bob.) Alice->Bob (MSRP):

        MSRP d93kswow SEND
        To-Path:msrp://bob.example.com:8888/9di4ea;tcp
        From-Path:msrp://alicepc.example.com:7777/iau39;tcp
        Message-ID: 12339sdqwer
        Content-Type:text/plain
        Hi, I'm Alice!
        -------d93kswow$

   6.  Bob->Alice (MSRP):

        MSRP d93kswow 200 OK
        To-Path:msrp://bob.example.com:8888/9di4ea;tcp
        From-Path:msrp://alicepc.example.com:7777/iau39;tcp
        -------d93kswow$

   7.  Bob->Alice (MSRP):

        MSRP dkei38sd SEND
        To-Path:msrp://alice.example.com:7777/iau39;tcp
        From-Path:msrp://bob.example.com:8888/9di4ea;tcp
        Message-ID: 456
        Content-Type:text/plain

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

   8.  Alice->Bob (MSRP):

        MSRP dkei38sd 200 OK
        To-Path:msrp://alice.example.com:7777/iau39;tcp
        From-Path:msrp://bob.example.com:8888/9di4ea;tcp
        -------dkei38sd$

   9.  Alice->Bob (SIP): BYE

        Alice invalidates local session state.

   10.  Bob invalidates local state for the session.

        Bob->Alice (SIP): 200 OK

11.2  Chunked Message

   For an example of a chunked message, see the example in Section 4.1.

11.3  System Message

   Sysadmin->Alice (MSRP):

   MSRP d93kswow SEND
   To-Path:msrp://alicepc.example.com:8888/9di4ea;tcp
   From-Path:msrp://example.com:7777/iau39;tcp
   Message-ID: 12339sdqwer
   Report-Failure: no
   Report-Success: no
   Content-Type:text/plain
   The system is going down in 5 minutes
   -------d93kswow$

11.4  Positive Report

   Alice->Bob (MSRP):

   MSRP d93kswow SEND
   To-Path:msrp://bob.example.com:8888/9di4ea;tcp
   From-Path:msrp://alicepc.example.com:7777/iau39;tcp
   Message-ID: 12339sdqwer
   Report-Success: yes
   Content-Type:text/html

   <html><body>
   <p>Here is that important link...
   <a href="www.example.com/foobar">foobar</a>
   </p>
   </body></html>
   -------d93kswow$

   Bob->Alice (MSRP):

   MSRP d93kswow 200 OK
   To-Path:msrp://alicepc.example.com:7777/iau39;tcp
   From-Path:msrp://bob.example.com:8888/9di4ea;tcp
   -------d93kswow$

   Bob->Alice (MSRP):

   MSRP dkei38sd SEND
   To-Path:msrp://alicepc.example.com:7777/iau39;tcp
   From-Path:msrp://bob.example.com:8888/9di4ea;tcp
   Message-ID: 12339sdqwer
   Status: 000 200 OK
   -------dkei38sd$

11.5  Forked IM

   Traditional IM systems generally do a poor job of handling multiple
   simultaneous IM clients online for the same person.  While some do a
   better job than many existing systems, handling of multiple clients
   is fairly crude.  This becomes a much more significant issue when
   always-on mobile devices are available, but when it is desirable to
   use them only if another IM client is not available.

   Using SIP makes rendezvous decisions explicit, deterministic, and
   very flexible; instead "pager-mode" IM systems use implicit
   implementation-specific decisions which IM clients cannot influence.

   With SIP session mode messaging rendezvous decisions can be under
   control of the client in a predictable, interoperable way for any
   host that implements callee capabilities [30].  As a result,
   rendezvous policy is managed consistently for each address of record.

   The following example shows Juliet with several IM clients where she
   can be reached.  Each of these has a unique SIP Contact and MSRP
   session.  The example takes advantage of SIP's capability to "fork"
   an invitation to several Contacts in parallel, in sequence, or in
   combination.  Juliet has registered from her chamber, the balcony,
   her PDA, and as a last resort, you can leave a message with her
   Nurse.  Juliet's contacts are listed below.  The q-values express
   relative preference (q=1.0 is the highest preference).

      We query for a list of Juliet's contacts by sending a REGISTER:

   REGISTER sip:thecapulets.example.com SIP/2.0
   To: Juliet <sip:juliet@thecapulets.example.com>
   From: Juliet <sip:juliet@thecapulets.example.com>;tag=12345
   Call-ID: 09887877
   CSeq: 772 REGISTER

      The Response contains her Contacts:

   SIP/2.0 200 OK
   To: Juliet <sip:juliet@thecapulets.example.com>
   From: Juliet <sip:juliet@thecapulets.example.com>;tag=12345
   Call-ID: 09887877
   CSeq: 771 REGISTER
   Contact: <sip:juliet@balcony.thecapulets.example.com>
    ;q=0.9;expires=3600
   Contact: <sip:juliet@chamber.thecapulets.example.com>
    ;q=1.0;expires=3600
   Contact: <sip:jcapulet@veronamobile.example.net>;q=0.4;expires=3600
   Contact: <sip:nurse@thecapulets.example.com>;q=0.1;expires=3600

   When Romeo opens his IM program, he selects Juliet and types the
   message "art thou hither?" (instead of "you there?").  His client
   sends a SIP invitation to sip:juliet@thecapulets.example.com.  The
   Proxy there tries first the balcony and the chamber simultaneously.
   A client is running on both those systems, both of which setup early
   sessions of MSRP with Romeo's client.  The client automatically sends
   the message over the MSRPS to the two MSPR URIs involved.  After a
   delay of a several seconds with no reply or activity from Juliet, the
   proxy cancels the invitation at her first two contacts, and forwards
   the invitation on to Juliet's PDA.  Since her father is talking to
   her about her wedding, she selects "Do Not Disturb" on her PDA, which
   sends a "Busy Here" response.  The proxy then tries the Nurse, who
   answers and tells Romeo what is going on.

    Romeo       Juliet's     Juliet/      Juliet/      Juliet/     Nurse
                 Proxy       balcony      chamber       PDA

      |            |            |            |           |           |
      |--INVITE--->|            |
             |(1) (SIP) INVITE            |
             |----------------------->|
             |(4) (SIP) 200 OK           |
             |<-----------------------|
             |(5) (SIP) ACK           |
             |----------------------->|
             |(6) (MSRP) SEND
      |
             |----------------------->|
             |(7) (MSRP) 200 OK            |--INVITE--->|            |
             |<-----------------------|
             |(8) (MSRP) SEND           |
             |<-----------------------|
             |(9) (MSRP) 200 OK           |
             |----------------------->|
             |(10) (SIP) BYE
      |
             |----------------------->|
             |(11) (SIP) 200 OK            |<----180----|            |
             |<-----------------------|           |           |
      |<----180----|            |            |

   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
       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
       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):           |           |
      |---PRACK---------------->|            |           |           |
      |<----200-----------------|            |           |           |
      |<===Early 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 Session==>| art thou hither?       |           |
      |            |            |            |           |           |
      |            |--INVITE---------------->|           |           |
      |            |<----180-----------------|           |           |
      |<----180----|            |            |           |           |
      |---PRACK----------------------------->|           |           |
      |<----200------------------------------|           |           |
      |<========Early MSRP Port Session==========>| art thou hither?      |
      |            |            |            |           |           |
      |            |            |            |           |           |
      |            | .... Time Passes ....   |           |           |
      |            |            |            |           |           |
      |            |            |            |           |           |
      |            |--CANCEL--->|            |           |           |
      |            |<---200-----|            |           |           |
      |            |<---487-----|            |           |           |
      |            |----ACK---->|            |           |           |
      |            |--CANCEL---------------->|           |           |
      |            |<---200------------------|           |           |
      |            |<---487------------------|           |           |
      |            |----ACK----------------->|           |           |
      |            |--INVITE---------------------------->|  romeo wants
      |            |            |            |           |  to IM w/ you
      |            |<---486 Busy Here--------------------|           |
      |            |----ACK----------------------------->|           |
      |            |            |            |           |           |
      |            |--INVITE---------------------------------------->|
      |            |<---200 OK---------------------------------------|
      |<--200 OK---|            |            |           |           |
      |---ACK------------------------------------------------------->|
      |<================MSRP Session================================>|
      |            |            |            |           |           |
      |                                         Hi Romeo, Juliet is  |
      |                                         with her father now  |
      |                                         can i take a message?|
      |                                                              |
      |  Tell her to go to confession tommorrow....                  |

12.  Extensibility

   MSRP uses TCP port XYX, was designed to be determined by IANA after this document only minimally extensible.  New MSRP Methods,
   Headers, and status codes can be defined in standards track RFCs.
   There is approved for publication.  Usage no registry of this value is described in
   Section 6.1

8.2  MSRP URL Schema

   This document defines headers, methods, or status codes, since the URL schema
   number of "msrp" "msrps", "smsrp", new elements and
   "smsrps".

8.2.1  Syntax

   See Section 6.1.

8.2.2  Character Encoding

   See Section 6.1.

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 total extensions is expected to RFC Editor: Please replace RFCXXXX in the above paragraph
   with the actual be very
   small.  MSRP does not contain a version number assigned or any negotiation
   mechanism to this document.

8.3  SDP Parameters

   This document registers the following SDP parameters require or discover new features.

   MSRP was designed to use lists of URLs instead of a single URL 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
   To-Path 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 From-Path headers in anticipation of relay or gateway
   functionality being added.  In addition, msrp: and msrps: URLs can
   contain parameters which are extensible.

13.  CPIM compatibility

   MSRP sessions may be gatewayed to Charset Attribute No
   Purpose other CPIM [25]compatible
   protocols.  If this occurs, the gateway MUST maintain session state,
   and Appropriate Values See Section 5.3.

8.3.3  Path

   Attribute-name:  path
   Long-form Attribute Name MUST translate between the MSRP URL Path
   Type: Media level
   Subject to Charset Attribute No
   Purpose session semantics 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 CPIM
   semantics that these values do not include a concept of sessions.  Furthermore,
   when one endpoint of the session is a CPIM gateway, instant messages
   SHOULD be recorded wrapped 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 "message/cpim" [7] bodies.  Such a new 'MTA-name-type' for use gateway MUST
   include "message/cpim" as the first entry in conjunction
   with RFC1894[10].  The authors request its SDP accept-types
   attribute.  MSRP endpoints sending instant messages to a peer that these values be recorded
   has included 'message/cpim" as the first entry in the IANA registry for DSN 'MTA-name-type'.

   Proposed Address name: msrp-name-type

   Syntax: See See Section 6.1

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

14.  Security Considerations

   There

   Instant Messaging systems are used to exchange a number variety of security considerations sensitive
   information ranging from personal conversations, to corporate
   confidential information, to account numbers and other financial
   trading information.  IM is used by individuals, corporations, and
   governments for MSRP, some communicating important information.  Like many
   communications systems, the properties of which
   are mentioned elsewhere in this document.  This section discusses
   those further, Integrity and introduces some new ones.

9.1  TLS
   Confidentiality of the exchanged information, along with the
   possibility of Anonymous communications, and knowing you are
   communicating with the MSRPS Scheme

   All correct other party are required.  MSRP devices must support TLS, with at least pushes
   many of the
   TLS_RSA_WITH_AES_128_CBC_SHA [8] cipher suite.  Other cipher suites
   MAY be supported. hard problems to SIP when SIP sets up the session, but
   some of the problems remain.  Spam and DoS attacks are also very
   relevant to IM systems.

   MSRP does not define a separate TCP port needs to provide confidentiality and integrity for TLS connections.  This
   means that all MSRP server devices, that is, all devices the messages
   it transfers.  It also needs to provide assurances the connected host
   is the host that listen
   for TCP connections, MUST be prepared it meant to connect to handle both TLS and plain
   text connections on that the same port. connection has
   not been hijacked.

   When a device accepts a using only TCP
   connection, it MUST watch for the TLS handshake messages to determine
   if connections, MSRP security is fairly weak.  If
   host A is contacting B, B passes its hostname and a particular connection uses TLS. secret to A using
   SIP.  If the first data received SIP offer or answer is not part of a start TLS request, the device ceases or S/MIME [27] protected,
   anyone can see this secret.  A then connects to watch for the
   TLS handshake until it reads the entire message.  Once provided host
   name and passes the message
   has been completely received, secret in the device resumes watching for clear across the
   start TLS message.

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

   MSRP devices acting to B.
   A assumes that it is talking to B based on where it sent the SYN
   packet and then delivers the secret in plain text across the role
   connections.  B assumes it is talking to A because the host on the
   other end 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 connection delivered the secret.  An attacker that
   could ACK the SYN packet could insert itself as a start TLS request man in the middle of an MSRP message.

      The working group considered only requiring
   in the endpoint to watch
      for a connection.

   When using TLS handshake at connections, the beginning of security is significantly improved.
   We assume that the session.  However, host accepting the
      endpoint should be able to determine if connection has a new message is certificate
   from a start well know certificate authority.  Furthermore, we assume that
   the SIP signaling to set up the session is protected with TLS request or an MSRP request by only reading ahead three bytes.
      Therefore, (using
   sips).  In this case, when host A contacts host B, the working group chose secret is
   passed through a SIP confidential channel to allow A.  A connects with TLS
   to B.  B presents a session valid certificate, so A knows it really is
   connected to switch B.  A then delivers the secret provided by B, so that B
   can verify it is connected to
      TLS A.  In this case, a rogue SIP Proxy can
   see the secret in mid-stream, the SIP signaling traffic and could potentially
   insert itself as long a man-in-the-middle.

   Realistically, using TLS is only feasible when connecting to gateways
   or relays , as the switch occurs between MRSP
      messages.

      There have since been proposals types of hosts that we only allow start-tls at
      connection time.  Do we end clients use for sending
   instant messages are unlikely to have a consensus here one way long term stable IP address
   or a stable DNS name that a certificate can bind to.  In addition,
   the cost of server certificates from well known certificate
   authorities is currently too high for the vast majority of end users
   to even consider getting one for each client.

   The only real security for connections without relays is achieved
   using S/MIME.  This does not require the
      other? actual endpoint to have
   certificates from a well known certificate authority.  The "msrps" Identity
   [22] and "smsrps" URI schema indicates that the connection
   MUST be protected Certificates [23] mechanism with TLS.

      Relay handling SIP provides S/MIME based
   delivery of "msrps" a secret between A and "smsrps" are beyond B.  No SIP intermediary except 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 trusted authentication service (one per user) can see the
   request with a 426 response.

9.1.1  Sensitivity of Session URLs
   secret.  The URLs sent in S/MIME encryption of the SDP offer/answer exchange for a MSRP session are can also be used by the endpoints SIP to identify each other.  If an attacker were
   able
   exchange keying material that can be used in MRSP.  The MSRP session
   can then use S/MIME with this keying material to acquire encrypt and sign
   messages sent over MSRP.  The connection can still be hijacked since
   the session URL, either by guessing it or by
   eavesdropping, there secret is a window of opportunity sent in which the attacker
   could hijack the session connecting and sending a MSRP request clear text to the
   listening device before the legitimate peer.  Because other end of the TCP
   connection, but this
   sensitivity, these URLs SHOULD be constructed in a way to make them
   difficult to guess, risk is mitigated if all the MSRP content is
   encrypted and should signed with S/MIME.

   MSRP can not be sufficiently random so that used as an amplifier for DoS attacks, but it is
   unlikely to can be reused.  All mechanisms
   used to transport these URLs
   SHOULD be protected from eavesdroppers and man-in-the-middle attacks.

   Therefore form a MSRP device MUST support the use of TLS for all MSRP
   messages.  Further, MSRP connections SHOULD actually be protected distributed attack to consume TCP connection resource
   on servers.  The attacker, Eve, sends an SIP INVITE with no offer to
   Alice.  Alice returns a 200 with TLS.  Further, an offer and Eve returns an answer
   with the SDP that indicates that her MSRP endpoint MUST be capable of using address is the
   security features address of
   Tom.  Since Alice sent the signaling protocol in order offer, Alice will initiate a connection to protect the
   SDP exchange and SHOULD actually use them
   Tom using up resources on all such exchanges.
   End-to-end protection schemes SHOULD be preferred over hop-by-hop
   schemes for protection of Tom's server.  Given the SDP exchange.

9.1.2  End to End Protection huge number 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 IM
   clients, 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 relatively few TCP connections that while each protected body could use separate keying
   material, most servers
   support, this is inefficient a fairly straightforward attack.

   SIP is attempting to address issues in that it requires dealing with spam.  The spam
   issue is probably best dealt with at the SIP level when an independent
   public key operation for each message.  Endpoints wishing MSRP
   session is initiated and not at the MSRP level.

   TLS is used to invoke
   end-to-end protection of message sessions SHOULD exchange symmetric
   keys in SDP k-lines, authenticate devices and use secret key encryption on to provide integrity and
   confidentiality for each MSRP
   message.  When symmetric keys are present in the SDP, the
   offer-answer exchange headers being transported.  MSRP elements
   MUST be protected from eavesdropping implement TLS and
   tampering using MUST also implement the appropriate facilities TLS
   ClientExtendedHello extended hello information for server name
   indication as described in [12].  A TLS cipher-suite of
   TLS_RSA_WITH_AES_128_CBC_SHA [15] MUST be supported (other
   cipher-suites MAY also be supported).

   Since MSRP carries arbitrary MIME content, it can trivially carry S/
   MIME protected messages as well.  All MSRP implementations MUST
   support the signaling protocol.
   For example, multipart/signed MIME type even if they do not support S/
   MIME.  Since SIP can carry a session key, S/MIME messages in the signaling protocol is SIP, the SDP exchange MUST
   context of a session could also be protected using S/MIME.

9.1.3  CPIM compatibility a key-wrapped
   shared secret [26] provided in the session setup.

15.  IANA Considerations

15.1  MSRP sessions may be gatewayed Port

   MSRP uses TCP port XYX, to other CPIM [19]compatible
   protocols.  If be determined by IANA after this occurs, document
   is approved for publication.  Usage of this value is described in
   Section 5

15.2  MSRP URL Schemes

   This document defines the gateway MUST maintain session state, URL schemes of "msrp" and MUST translate between "msrps".

   Syntax See Section 5.
   Character Encoding See Section 5.
   Intended Usage See Section 5.
   Protocols The Message Session Relay Protocol (MSRP).
   Security Considerations See Section 14.
   Relevant Publications RFCXXXX
         [Note to RFC Editor: Please replace RFCXXXX in the above
         paragraph with the actual number assigned to this document.

15.3  SDP Parameters

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

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

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

15.3.3  Path

   Attribute-name:  path
   Long-form Attribute Name MSRP session semantics URL Path
   Type: Media level
   Subject to Charset Attribute No
   Purpose and CPIM
   semantics that do not include a concept of sessions.  Furthermore,
   when one endpoint of the session is Appropriate Values See Section 7.1.1.

15.4  IANA registration forms for DSN types

15.4.1  IANA registration form for address-type

   This document registers a CPIM gateway, instant messages
   SHOULD new 'address-type' for use in conjunction
   with RFC1894[8].  The authors request that these values be wrapped recorded
   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 IANA registry for DSN 'address-type'.

   Proposed Address name: msrp-address-type
   Syntax: See Section 5

15.4.2  IANA registration form for MTA-name-type

   This document registers a peer new 'MTA-name-type' for use in conjunction
   with RFC1894[8].  The authors request that
   has included 'message/cpim" as the first entry these values be recorded
   in the accept-types
   attribute SHOULD encapsulate all instant message bodies IANA registry for DSN 'MTA-name-type'.

   Proposed Address name: msrp-name-type

   Syntax: See Section 5

16.  Change History

16.1  draft-ietf-simple-message-sessions-07

      Significant re-write to attempt to improve readability.
      Added maximum size parameter in "message/
   cpim" wrappers.  All MSRP endpoints MUST support the message/cpim
   type, and SHOULD support accept-types
      Changed the S/MIME features of that format.

9.1.4  PKI Considerations

   Several aspects Boundary field to be part of MSRP will benefit from being used in the context
   of start-line rather
      than a public key infrastructure.  For example, header field.
      Removed the MSRPS scheme
   allows, TR-IDheader, and even encourages, TLS connections between endpoint
   devices.  And while MSRP allows for a symmetric session key to
   protect all messages in a session, it is most likely that session key
   itself would be exchanged in a signaling protocol such as SIP.  Since
   that key is extremely sensitive, its exchange would also need changed request-response matching to
      be
   protected.  In SIP, based on the preferred mechanism for this would be S/MIME, Boundary field value.  Responses still contain the
      TR-ID header, which would also benefit must match the Boundary from a PKI.

   However, all of these features may be used without PKI.  Each
   endpoint could instead use self signed certificates.  This will, the request.
      Removed transport selection from URL scheme and added the "tcp"
      parameter.
      Added description of
   course, be less convenient than with a PKI, in that there would be no
   certificate authority to act as the "simple" mode with no transaction
      responses, and made mode selection dependent on the reporting
      level requested for a trusted introducer.  Peers would be
   required give message.
      Changed the DSN section to exchange certificates prior reflect separate request of success and
      failure reports.  Enhanced REPORT method to securely communicating.

   Since, at least be useful even without
      a payload.
      removed SRV usage for the immediate future, any given MSRP
   implementation URL resolution.  This is likely only used for relay
      discovery, and therefore should be moved to communicate with at least some peers the relay draft.
      Added discussion about late REPORT handling.  Asserted that
   do not have a PKI available, MSRP implementations SHOULD support REPORT
      requests are always sent in simple mode.
      Removed the
   use of self-signed certificates, and SHOULD support dependency on multipart/byteranges for fragmentation.
      Incorporated the ability to
   configure lists of trusted certificates.

      To Do: Add text discussion Byte-Range header into the base MSRP header set.
      Removed the VISIT method.  Change to use of TLS certificates in more
      detail.

10.  Changes from Previous Draft Versions

   This section SEND to be deleted prior serve the purpose
      formerly reserved to publication as an RFC

10.1 VISIT.

16.2  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 TR-ID header from version 05 were erroneously
      attributed to 04.

10.2

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

16.4  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

16.5  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

16.6  draft-ietf-simple-message-sessions-02

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

10.6

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

16.8  draft-ietf-simple-message-sessions-00

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

10.8

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

17.  Contributors and Acknowledgments

   In addition to the editor, The following people contributed extensive
   work to this document: Chris Boulton Boulton, Cullen Jennings Jennings, Paul Kyzivat Kyzivat,
   Rohan Mahy Mahy, Adam Roach Roach, Jonathan Rosenberg Rosenberg, Robert Sparks

12.  Acknowledgments Sparks.

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

13. Levin.

18.  References

13.1

18.1  Normative References

   [1]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
         2246, January 1999.

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

   [2]

   [3]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         Session Description Protocol (SDP)", RFC 3264, June 2002.

   [4]   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,

   [5]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [6]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 2234, November 1997.

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

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

   [9]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part One: Format of Internet Message Bodies",
         RFC 2045, November 1996.

   [10]  Troost, R., Dorner, S. and J. Vincent, "Instant Messaging /
         Presence Protocol Requirements", K. Moore, "Communicating
         Presentation Information in Internet Messages: The
         Content-Disposition Header Field", RFC 2779, February 2000.

   [4] 2183, August 1997.

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

   [5]

   [12]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and
         T. Wright, "Transport Layer Security (TLS) Extensions", RFC
         3546, June 2003.

   [13]  Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
         Method", RFC 3311, October 2002.

   [14]  Atkins, D. and G. Klyne, "Common Presence and Instant Messaging
         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]

   [15]  Chown, P., ""Advanced "Advanced Encryption Standard (AES) Ciphersuites for
         Transport Layer Security Secur ity (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

18.2  Informational References

   [12]  Campbell, B.

   [16]  Johnston, A. and J. Rosenberg, O. Levin, "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 Call
         Control - Conferencing for SIP",
         draft-ietf-sipping-cc-framework-02 User Agents",
         draft-ietf-sipping-cc-conferencing-03 (work in progress), May
         2003.

   [15]
         February 2004.

   [17]  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 draft-ietf-sipping-3pcc-06 (work
         in progress), June 2003.

   [16] January 2004.

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

   [17]  Camarillo, G., Marshall, W. and J. 2004.

   [19]  Campbell, B., Rosenberg, "Integration of
         Resource Management J., Schulzrinne, H., Huitema, C. and Session
         D. Gurle, "Session Initiation Protocol (SIP)", (SIP) Extension for
         Instant Messaging", RFC
         3312, October 3428, December 2002.

   [18]

   [20]  Mahy, R., "Benefits and Motivation for Session Mode Instant
         Messaging", draft-mahy-simple-why-session-mode-00 (work in
         progress), February 2004.

   [21]  Mahy, R. and C. Jennings, "Relays for the Message Session Relay
         Protocol (MSRP)", draft-ietf-simple-msrp-relays-01.txt (work in
         progress), July 2004.

   [22]  Peterson, J., "A Privacy Mechanism J. and C. Jennings, "Enhancements for Authenticated
         Identity Management in the Session Initiation  Protocol (SIP)", RFC 3323 , November 2002.

   [19]
         draft-ietf-sip-identity-02 (work in progress), May 2004.

   [23]  Jennings, C. and J. Peterson, "Certificate Management Service
         for SIP", draft-jennings-sipping-certs-03 (work in progress),
         May 2004.

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

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

   [20]  Yon, D., "Connection-Oriented

   [26]  Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217,
         December 2001.

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

   [28]  Camarillo, G. and H. Schulzrinne, "Early Media Transport and Ringing Tone
         Generation in SDP",
         draft-ietf-mmusic-sdp-comedia-05 the Session Initiation Protocol (SIP)",
         draft-ietf-sipping-early-media-02 (work in progress), March
         2003.

Author's Address June
         2004.

   [29]  Saint-Andre, P., "Extensible Messaging and Presence Protocol
         (XMPP): Instant Messaging and  Presence", draft-ietf-xmpp-im-22
         (work in progress), April 2004.

   [30]  Rosenberg, J., "Indicating User Agent Capabilities in the
         Session Initiation Protocol  (SIP)",
         draft-ietf-sip-callee-caps-03 (work in progress), January 2004.

Authors' Addresses

   Ben Campbell
   dynamicsoft
   5100 Tennyson Parkway (editor)

   EMail: ben@nostrum.com

   Rohan Mahy
   Cisco Systems, Inc.
   5617 Scotts Valley Drive, Suite 1200
   Plano, TX  75024 200
   Scotts Valley, CA  95066
   USA

   EMail: rohan@cisco.com
   Cullen Jennings
   Cisco Systems, Inc.
   170 West Tasman Dr.
   MS: SJC-21/2
   San Jose, CA  95134
   USA

   EMail: bcampbell@dynamicsoft.com fluffy@cisco.com

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property
   Intellectual Property Rights 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 nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation RFC documents can be
   found in BCP-11. BCP 78 and BCP 79.

   Copies of
   claims of rights IPR disclosures made available for publication to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF Secretariat. on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which that may cover technology that may be required to practice implement
   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 at
   ietf-ipr@ietf.org.

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

   This document and the information contained herein is are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIMS DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

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