SIMPLE WG                                               B. Campbell, Ed.
Internet-Draft                                          Estacado Systems
Expires: January 16, February 23, 2005                                  R. Mahy Mahy, Ed.
                                                        C. Jennings Jennings, Ed.
                                                     Cisco Systems, Inc.
                                                           July 18,
                                                         August 25, 2004

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

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, I certify each
   author represents that any applicable patent or other IPR claims of
   which I am he or she is aware have been or will be disclosed, and any of
   which I he or she become aware will be disclosed, in accordance with
   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 January 16, February 23, 2005.

Copyright Notice

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

Abstract

   This document describes the Message Session Relay Protocol (MSRP), a
   protocol for transmitting a series of related instant messages in the
   context of a session.  Message sessions are treated like any other
   media stream when setup via a rendezvous or session setup protocol
   such as the Session Initiation Protocol (SIP).

Table of Contents

   1.   Conventions  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.   Introduction and Background  . . . . . . . . . . . . . . . .   4
   3.   Protocol Overview  . . . . . . . . . . . . . . . . . . . . .   5
   4.   Key Concepts . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.1  MSRP Framing and Message Chunking  . . . . . . . . . . . .   8
     4.2  MSRP Addressing  . . . . . . . . . . . . . . . . . . . . .  11   9
     4.3  MSRP Transaction and Report Model  . . . . . . . . . . . .  11   9
     4.4  MSRP Connection Model  . . . . . . . . . . . . . . . . . .  12  10
   5.   MSRP URLs  . . . . . . . . . . . . . . . . . . . . . . . . .  14  12
     5.1  MSRP URL Comparison  . . . . . . . . . . . . . . . . . . .  15  13
     5.2  Resolving MSRP Host Device . . . . . . . . . . . . . . . .  16  14
   6.   Method-Specific Behavior . . . . . . . . . . . . . . . . . .  16  14
     6.1  Constructing Requests  . . . . . . . . . . . . . . . . . .  16  14
       6.1.1  Delivering SEND requests . . . . . . . . . . . . . . .  17  15
       6.1.2  Sending REPORT requests  . . . . . . . . . . . . . . .  19  18
       6.1.3  Failure REPORT Generation  . . . . . . . . . . . . . .  19  18
     6.2  Constructing Responses . . . . . . . . . . . . . . . . . .  20  19
     6.3  Receiving Requests . . . . . . . . . . . . . . . . . . . .  21  20
       6.3.1  Receiving SEND requests  . . . . . . . . . . . . . . .  21  20
       6.3.2  Receiving REPORT requests  . . . . . . . . . . . . . .  22  21
   7.   Using MSRP with SIP  . . . . . . . . . . . . . . . . . . . .  22
     7.1  SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . .  22
       7.1.1  URL Negotiations . . . . . . . . . . . . . . . . . . .  25  24
       7.1.2  Path Attributes with Multiple URLs . . . . . . . . . .  26  25
       7.1.3  Updated SDP Offers . . . . . . . . . . . . . . . . . .  27  26
       7.1.4  Example SDP Exchange . . . . . . . . . . . . . . . . .  27  26
       7.1.5  Connection Negotiation . . . . . . . . . . . . . . . .  28  27
     7.2  MSRP User Experience with SIP  . . . . . . . . . . . . . .  28  27
   8.   DSN payloads in MSRP REPORT Requests . . . .   Formal Syntax  . . . . . . . .  28
     8.1  Per-Message DSN header usage . . . . . . . . . . . . . . .  28
     8.2  Per-Recipient DSN header usage .
   9.   Response Code Descriptions . . . . . . . . . . . . .  29
     8.3  original-envelope-id usage . . . .  30
     9.1  200  . . . . . . . . . . . .  29
     8.4  reporting-mta . . . . . . . . . . . . . . .  30
     9.2  400  . . . . . . .  29
     8.5  final-recipient . . . . . . . . . . . . . . . . . . . .  30
     9.3  403  .  29
     8.6  action . . . . . . . . . . . . . . . . . . . . . . . . . .  30
     8.7  status
     9.4  415  . . . . . . . . . . . . . . . . . . . . . . . . . . .  30
   9.   Formal Syntax
     9.5  426  . . . . . . . . . . . . . . . . . . . . . . .  30
   10.  Response Code Descriptions . . . .  31
     9.6  481  . . . . . . . . . . . . .  32
     10.1   200 . . . . . . . . . . . . . .  31
     9.7  506  . . . . . . . . . . . .  33
     10.2   400 . . . . . . . . . . . . . . .  31
   10.  Examples . . . . . . . . . . .  33
     10.3   403 . . . . . . . . . . . . . . .  31
     10.1   Basic IM session . . . . . . . . . . .  33
     10.4   415 . . . . . . . . .  31
     10.2   Chunked Message  . . . . . . . . . . . . . . . . .  33
     10.5   426 . . .  33
     10.3   System Message . . . . . . . . . . . . . . . . . . . . .  33
     10.4   Positive Report  . .  33
     10.6   481 . . . . . . . . . . . . . . . . . .  34
     10.5   Forked IM  . . . . . . . .  33
     10.7   506 . . . . . . . . . . . . . . .  34
   11.  Extensibility  . . . . . . . . . . .  33
   11.  Examples . . . . . . . . . . . .  37
   12.  CPIM compatibility . . . . . . . . . . . . . .  33
     11.1   Basic IM session . . . . . . .  37
   13.  Security Considerations  . . . . . . . . . . . . .  33
     11.2   Chunked Message . . . . .  38
   14.  IANA Considerations  . . . . . . . . . . . . . . .  36
     11.3   System Message . . . . .  40
     14.1   MSRP Port  . . . . . . . . . . . . . . . .  36
     11.4   Positive Report . . . . . . .  40
     14.2   MSRP URL Schemes . . . . . . . . . . . . .  37
     11.5   Forked IM . . . . . . .  40
     14.3   SDP Parameters . . . . . . . . . . . . . . . .  37
   12.  Extensibility . . . . .  40
       14.3.1   Accept Types . . . . . . . . . . . . . . . . . .  40
   13.  CPIM compatibility . .  40
       14.3.2   Wrapped Types  . . . . . . . . . . . . . . . . . . .  40
   14.  Security Considerations
       14.3.3   Max Size . . . . . . . . . . . . . . . . . .  40
   15.  IANA Considerations . . . .  41
       14.3.4   Path . . . . . . . . . . . . . . . .  42
     15.1   MSRP Port . . . . . . . .  41
   15.  Change History . . . . . . . . . . . . . . .  42
     15.2   MSRP URL Schemes . . . . . . . .  41
     15.1   draft-ietf-simple-message-sessions-08  . . . . . . . . .  41
     15.2   draft-ietf-simple-message-sessions-07  . . .  42
     15.3   SDP Parameters . . . . . .  41
     15.3   draft-ietf-simple-message-sessions-06  . . . . . . . . .  42
     15.4   draft-ietf-simple-message-sessions-05  . . . . . .  43
       15.3.1   Accept Types . . .  42
     15.5   draft-ietf-simple-message-sessions-04  . . . . . . . . .  43
     15.6   draft-ietf-simple-message-sessions-03  . . . . . . . . .  43
       15.3.2   Wrapped Types
     15.7   draft-ietf-simple-message-sessions-02  . . . . . . . . .  43
     15.8   draft-ietf-simple-message-sessions-01  . . . . . . . . . .  43
       15.3.3   Path . . . . . . . . . . . . . . . . . . . . . . . .  43
     15.4   IANA registration forms for DSN types  . . . . . . . . .  43
       15.4.1   IANA registration form for address-type  . . . . . .  43
       15.4.2   IANA registration form for MTA-name-type . . . . . .  44
   16.  Change History . . . . . . . . . . . . . . . . . . . . . . .  44
     16.1   draft-ietf-simple-message-sessions-07  . . . . . . . . .  44
     16.2   draft-ietf-simple-message-sessions-06  44
     15.9   draft-ietf-simple-message-sessions-00  . . . . . . . . .  44
     16.3   draft-ietf-simple-message-sessions-05  . . . . . . . . .  45
     16.4   draft-ietf-simple-message-sessions-04  . . . . . . . . .  45
     16.5   draft-ietf-simple-message-sessions-03  . . . . . . . . .  45
     16.6   draft-ietf-simple-message-sessions-02  . . . . . . . . .  46
     16.7   draft-ietf-simple-message-sessions-01  . . . . . . . . .  46
     16.8   draft-ietf-simple-message-sessions-00  . . . . . . . . .  47
     16.9
     15.10  draft-campbell-simple-im-sessions-01 . . . . . . . . . .  47
   17.  45
   16.  Contributors and Acknowledgments . . . . . . . . . . . . . .  47
   18.  45
   17.  References . . . . . . . . . . . . . . . . . . . . . . . . .  48
   18.1  45
   17.1   Normative References . . . . . . . . . . . . . . . . . . .  48
   18.2  45
   17.2   Informational References . . . . . . . . . . . . . . . . .  49  46
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  50  48
        Intellectual Property and Copyright Statements . . . . . . .  52  49

1.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [5].

   This document consistently refers to a "message" as a complete unit
   of MIME or text content.  In some cases a message is split and
   delivered in more than one MSRP request.  Each of these portions of
   the complete message is called a "chunk".

2.  Introduction and Background

   A series of related textual messages between two or more parties can
   be viewed as part of a session with a definite start and end.  This
   is in contrast to individual messages each sent completely
   independently.  The SIMPLE Working Group describes 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 SIP [4]MESSAGE
   method [19].  Session-mode messaging has a number of benefits [20]
   over page-mode messaging however, such as explicit rendezvous,
   tighter integration with other media types, direct client-to-client
   operation, and brokered privacy and security.

   This document defines a session-oriented instant message transport
   protocol called the Message Session Relay Protocol (MSRP), whose
   sessions can be included in an offer or answer [3] of a session description (for example, SDP using the Session
   Description Protocol(SDP [2]).  The exchange is carried by some
   signaling protocol, such as SIP [4].  This allows a communication
   user agent to offer a messaging session as one of the possible media
   types in a session.  For instance, Alice may want to communicate with
   Bob.  Alice doesn't know at the moment whether Bob has his phone or
   his IM client handy, but she's willing to use either.  She sends an
   invitation to a session to the address of record she has for Bob,
   sip:bob@example.com.  Her invitation offers both voice and an IM
   session.  The SIP services at example.com forward the invitation to
   Bob at his currently registered clients.  Bob accepts the invitation
   at his IM client and they begin a threaded chat conversation.

   This session model allows message sessions to be integrated into
   advanced communications applications with little to no additional
   protocol development.  For example, during the above chat session,
   Bob decides Alice really needs to be talking to Carol.  Bob can
   transfer [18] Alice to Carol, introducing them into their own
   messaging session.  Messaging sessions can 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 a text-based, connection-oriented protocol for exchanging
   arbitrary (binary) MIME content, especially instant messages.  This
   section is a non-normative overview of how MSRP works and how it is
   used with SIP.

   MSRP sessions are typically arranged using SIP the same way a session
   of audio or video media is setup.  One SIP user agent (Alice) sends
   the other (Bob) a SIP invitation containing an offer
   session-description which includes a session of MSRP.  The receiving
   SIP user agent can accept the invitation and include an answer
   session-description which acknowledges the choice of media.  Alice's
   session description contains an MSRP URL that describes where she is
   willing to receive MSRP requests from Bob, and vice-versa.  (Note:
   Some lines in the examples are removed for clarity and brevity.)
       Alice sends to 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 or a chunk (a portion of a complete
   message), while REPORT requests report on the status of an earlier
   SEND request.  When Alice receives Bob's answer, she checks to see if
   she has an existing connection to Bob.  If not, she opens a new
   connection to Bob using the URL he provided in the SDP.  Alice then
   delivers a SEND request to Bob with her initial message, and Bob
   replies indicating that Alice's request was received successfully.

   MSRP a786hjs2 SEND
   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
   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 start line, which contains a
   transaction identifier that is also used as a final boundary marker.
   Next she includes the path of URLs to the destination in the To-Path
   header, and her own URL in the 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 original message.
   Next she puts the actual content.  Finally she closes the request
   with an end line: seven hyphens, the transaction identifier /
   boundary marker and a "$" to indicate this request contains the end
   of a complete message.

   If Alice wants to deliver a very large message, she can split the
   message into chunks and deliver each chunk in a separate SEND
   request.  The message ID corresponds to the whole message, so the
   receiver can also use it to reassemble the message and tell which
   chunks belong with which message.  Chunking is 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 especially useful if Alice
   sent a series of SEND request containing chunks of a single message.
   More on requesting types of reports and errors is described in
   Section 4.3.

   Alice and Bob generally choose their MSRP URLs in such a way that is
   difficult to guess the exact URL.  Alice and Bob can reject requests
   to URLs they are not expecting to service, and can correlate the
   specific URL with the probable sender.  Alice and Bob can also use
   TLS [1] to provide channel security over this hop.  To receive MSRP
   requests over a TLS protected connection, Alice or Bob could
   advertise URLs with the "msrps" scheme instead of "msrp."

   This document specifies MSRP behavior only peer-to-peer session, that
   is, for a single hop.  But is designed with the expectation that MSRP
   can carry URLs for nodes on the far side of gateways or relays.  For
   this reason, a URL with the "msrps" scheme makes no assertion about
   the security properties of other hops, just the 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 same destination host, port, transport protocol,
   and scheme.  MSRP nodes can keep track of how many sessions are using
   a particular connection and close these connections when no sessions
   have used them for some period of 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 overall message.  To support this, MSRP uses a boundary based
   framing mechanism.  The header of an MSRP request contains a unique
   boundary string that is used to indicate the end of the request.
   Following the boundary string at the end of the body data, there is a
   flag that indicates whether this is the last chunk of data for this
   message or whether the message will be continued in a subsequent
   chunk.  There is also a Byte-Range header in the request that
   indicates the overall position of this chunk inside the complete
   message.

   For example, the following snippet of two SEND requests demonstrates
   a message that contains the text "abcdEFGH" being sent as two chunks.

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

    abcd
    -------dkei38sd+

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

    EFGH
    -------dkei38ia$

   This chunking mechanism allows a sender to interrupt a chunk part way
   through sending it.  The receiver uses the value of the Message-ID header ability to determine
   which of interrupt messages allows
   multiple chunks belong sessions to share a TCP connection, and for large messages
   to be sent efficiently while not blocking other messages that share
   the same message. connection.

   The Message-ID
   header MUST have the same value for each chunk in the same message,
   and a sender MUST ensure ability to interrupt messages is needed so that the message ID TCP connections
   can be shared.  Connection sharing is unique necessary for each "fair" allocation
   of
   the messages it sends within a particular session.

   The boundary marker bandwidth in congestion situations and for allowing MSRP network
   elements that terminates the body MUST be preceded by have a
   CRLF that is not part very large number of concurrent connections to
   different users.

4.2  MSRP Addressing

   MSRP entities are addressed using URLs.  The MSRP URL schemes are
   defined in Section 5.  The syntax of the body To-Path and then seven "-" (minus sign)
   characters.  After the boundary marker, there MUST be a flag
   character that is either From-Path
   headers allow for a "$" (for the last chunk list of URLs.  This was done to allow the message)
   protocol to work with gateways or
   "+" (for chunks other than the last).  If the chunk represents relays defined in the
   data that forms future, to
   provide a complete path to the end of the message, the flag MUST be a "$",
   otherwise recipient.  When two MSRP nodes
   communicate directly they need only one URL in the flag MUST be a "+".

   The Byte-Range header value contains a starting value followed by a
   "-", an ending value followed by a "/", To-Path list and finally
   one URL in the total length. From-Path list.

4.3  MSRP Transaction and Report Model

   A sender sends MSRP requests to a receiver.  The starting value indicates the index into receiver MUST
   quickly accept or reject the message where request.  If the
   first byte in receiver initially
   accepted the current chunk belongs.  The index of request, it still may then do things that take
   significant time to succeed or fail.  For example, if the first
   octet in receiver is
   an MSRP to XMPP [29] gateway, it may forward the complete message is ONE, not zero. over XMPP.
   The ending value
   indicates XMPP side may later indicate that the location where request did not work.  At
   this point, the last octet belongs.  The body MAY
   contain less data than is indicated by MSRP receiver may need to indicate that the end but it MUST NOT
   contain more octets than indicated.  The length indicates request
   did not succeed.  There are two important concepts here: first, the number
   hop by hop delivery of octets in the complete message.  Both the ending value and length
   MAY have the value of "*" in some request may succeed or all of fail; second, the chunks, to indicate
   that they are not specified.  If no Byte-Range header is present,
   end result of the
   SEND request MUST may be treated successfully processed or not.  The
   first type of status is referred to as if there was a Byte-Range header
   present with "transaction status" and may
   be returned in response to a value request.  The second type of "1-*/*".

   This chunking mechanism allows status is
   referred to as "request status" and may be returned in a REPORT
   transaction.

   The original sender of a request can indicate if they wish to interrupt receive
   reports for requests that fail, and can independently indicate if
   they wish to receive reports for requests that succeed.  A receiver
   only sends a chunk part way
   through sending success REPORT if it by writing out knows that the boundary termination request succeeded,
   and the
   "+" flag to indicate that sender requested a success report.  A receiver only sends a
   failure REPORT if the end of this chunk is not request failed and the end sender requested failure
   reports.

      This document describes the behavior of MSRP endpoints.  MSRP
      relays or gateways are likely to have additional conditions that
      indicate a failure REPORT should be sent, such as the
   complete message.  The ability failure to interrupt messages allows multiple
   sessions
      receive a positive response from the next hop.

   Two header fields control the sender's desire to share receive reports.
   The header "Report-Success" can have a TCP connection, value of "yes" or "no" and for large messages to be sent
   efficiently while not blocking other messages that share the same
   connection.

   To insure fairness over a connection, senders MUST NOT send chunks
   with
   "Report-Failure" header can have a body larger than 2048 octets unless they value of "yes", "no", or
   "partial".

   The combinations of reporting are prepared needed to
   interrupt them.  A sender can use one of meet the following two strategies various
   scenarios of currently deployed IM systems.  Report-Success might be
   "no" in many public systems to satisfy this requirement.  The sender reduce load but is STRONGLY RECOMMENDED to
   send messages larger than 2048 octets using used in some
   current enterprise systems, such as few chunks systems used for securities
   trading.  A Report-Failure value of "no" is useful for sending system
   messages such as
   possible, interrupting chunks (at least 2048 octets long) when other
   traffic "the system is waiting going down in 5 minutes" without
   causing a response explosion to use the same connection.  Alternatively, the
   sender MAY simply send chunks in 2048 octet increments until the
   final chunk.  Note sender.  A Report-Failure of
   "yes" is used by many systems that wish to notify the former strategy results in markedly more
   efficient user if the
   message failed but some other systems choose to use a value of
   "partial" to reduce the connection.  All MSRP nodes MUST load on the servers caused by 200 OK
   responses, but still allow error responses to be able sent in many cases.

4.4  MSRP Connection Model

   When MSRP wishes to
   receive chunks of any size from 0 octets send a request to the maximum number of
   octets they can receive for a complete message.  Senders SHOULD NOT
   break messages into chunks smaller than 2048 octets, except for the
   final chunk of peer identified by an MSRP
   URL, it first needs a complete message.

   Receivers MUST not assume connection, with the chunks will be delivered appropriate security
   properties, to the host specified in order or
   that they will receive all the chunks with "+" flags before they
   receive URL.  If the chunk sender already
   has such a connection, that is, one associated with the "$" flag.  In certain cases of connection
   failure, same host,
   port, and URL scheme, then it SHOULD reuse that connection.

   When a new MSRP session is possible for information to be duplicated.  If chunks
   data created, the convention is received that overlaps already received data for the same
   message, the last chunk received takes precedence (even though this
   may not have been
   element that sent the last chunk transmitted).  For example, if bytes
   1 to 100 was received and SDP offer MUST immediately issue a chunk arrives that contains bytes 50 SEND request
   to
   150, this second chunk will overwrite bytes 50 the answerer.  This request MAY have a empty body, or MAY carry
   content.

   When a new connection needs to 100 be formed, the element looks at the
   URL to decide on the type of connection (TLS, TCP, etc.) then
   connects to the data
   that had already been received.  Although other schemes work, this is host indicated by the easiest for URL, following the receiver and results URL
   resolution rules in consistent behavior
   between clients.

   The seven "-" before Section 5.2.  For connections using the boundary are used so that msrps:
   scheme, the receiver can
   search for SubjectAltName in the value "----", 32 bits at a time to find received certificate MUST match the probable
   location
   hostname part of the boundary.  This allows most processors to locate the
   boundaries URL and copy the memory at the same rate that a normal memory
   copy could certificate MUST be done.  This approach results in valid, including
   having a system date that is as
   fast as framing based on specifying the body length in the headers of
   the request, but also allows for valid and being signed by an acceptable
   certificate authority.  At this point the interruption of messages.

   The ability to interrupt messages is needed so device that TCP connections initiated the
   connection can be shared.  Connection sharing assume that this connection is necessary for "fair" allocation
   of bandwidth in congestion situations with the correct host.

   If the connection used mutual TLS authentication, and for allowing MSRP network
   elements that have the TLS client
   presented a very large number of concurrent connections to
   different users.

4.2  MSRP Addressing

   MSRP entities are addressed using URLs.  The MSRP URL schemes are
   defined in Section 5.  The syntax valid certificate, then the element accepting the
   connection can know the identity of the To-Path and From-Path
   headers allow for connecting host.  When mutual
   TLS authentication is not used, the listening device MUST wait until
   it receives a list of URLs.  This was done to allow request on the
   protocol connection to work with gateways or relays defined in determine the future, to
   provide a complete path to identity of
   the end recipient. connecting device.

   When two MSRP nodes
   communicate directly they need only one URL in the first request arrives, its To-Path list and
   one header field should
   contain a URL that the listening element handed out in the From-Path list.

4.3  MSRP Transaction and Report Model

   A sender sends MSRP requests to SDP for a receiver.
   session.  The receiver MUST
   quickly accept or reject element that accepted the request.  If connection looks up the receiver initially
   accepted URL
   in the received request, and determines which session it still may then do things matches.  If
   a match exists, the node MUST assume that take
   significant time to succeed or fail.  For example, if the receiver host that formed the
   connection is
   an MSRP to XMPP [29] gateway, it may forward the message over XMPP.
   The XMPP side may later indicate host that the request did not work.  At this point, URL was given to.  If no match
   exists, the MSRP receiver may need to indicate that node MUST reject the request
   did not succeed.  There are two important concepts here: first, the
   hop by hop delivery of with a 481 response.  The
   node MUST also check to make sure the request may succeed or fail; second, the
   end result of the request may be successfully processed or not.  The
   first type of status is referred to as "transaction status" and may
   be returned in response to a request.  The second type of status session is
   referred to as "request status" and may be returned not already in a REPORT
   transaction.

   The original sender of a request can indicate if they wish to receive
   reports for requests that fail, and can independently indicate if
   they wish to receive reports for requests that succeed.  A receiver
   only sends a success REPORT if use
   on another connection.  If so, it knows that the request succeeded,
   and the sender requested a success report.  A receiver only sends a
   failure REPORT if MUST reject the request failed and the sender requested failure
   reports.

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

   Two header fields control the sender's desire 506
   response.

      If it were legal to receive reports.
   The header "Report-Success" can have a value of "yes" or "no" and multiple connections associated with the
   "Report-Failure" header can have
      same session, a value of "yes", "no", or
   "partial". security problem would exist.  If the value of "Report-Failure" initial SEND
      request is set to "yes", then not protected, an eavesdropper might learn the sender of URL, and
      use it to insert messages into the request runs session via a timer. different
      connection.

   If a 200 response to the transaction is
   not received within 30 seconds from connection fails for any reason, then an MSRP endpoint MUST
   consider failed any sessions associated with the time connection as well.
   When an endpoint notices such a failure, it MAY attempt to re-create
   any such sessions.  If it chooses to do so, it MUST use new SDP
   exchange.  If a replacement session is successfully created,
   endpoints MAY attempt to resend any content for which delivery on the last byte of
   original session could not be confirmed.  If it does this, the
   transaction is sent,
   Message-ID values for the element resent messages MUST inform the user that match those used in
   the
   request probably failed. initial attempts.  If the value is set to "partial", then receiving endpoint receives more than
   one message with the
   element sending same Message-ID.  It SHOULD assume that the transaction does not have to run a timer,
   messages are duplicates.  It MAY take any action based on that
   knowledge, but
   MUST inform SHOULD NOT present the user if receives a non-recoverable error response duplicate messages to the transaction.

   Similarly if the value user
   without warning of the Report-Success header is "yes", then duplicates.

   In this situation, the receiving node endpoint MUST send a "success" REPORT after the request is
   complete to indicate choose Message-ID values so that
   they are unique in the request succeeded.  Likewise if context of both the
   value is "no", it MUST NOT send original session and the
   replacement session.

   When endpoints create a success REPORT.

   A consequence of new session in this is that if an MSRP element receives a request
   that has fashion, the Report-Failure header set to chunks for a value of "no", it
   given logical message MAY be split across the sessions.  However,
   endpoints SHOULD NOT send any responses to this request, because the element sending
   the request would not do anything with the resulting response. split chunks between sessions under normal
   circumstances.

   If a connection fails, the value is "partial", it sender SHOULD NOT send a 200 response attempt to re-setup the
   request, but SHOULD send URL
   path using a non-200 class response if appropriate.

   If no Report-Success header is present new offer, for example, in a SEND request, it SIP re-invite or update
   [12].  It MUST not assume that the new URLs in the SDP will be
   treated the
   same as the old ones.  A connection SHOULD not be closed while there
   are sessions that are using this connection.

5.  MSRP URLs

   An MSRP URL follows a Report-Success header with value subset of "no".  If
   no Report-Failure header is present, it MUST be treated the same as a
   Report-Failure header URL syntax in Appendix A of
   RFC2396 [10], with value a scheme of "yes".  REPORT requests MUST have
   the same Message-ID header value as the request they "msrp" or "msrps":

      MSRP_urls = msrp-scheme "://" [userinfo "@"] hostport ["/"
      resource] ";" transport
      msrp-scheme = "msrp" / "msrps"
      resource = 1*unreserved
      transport = "tcp" / ALPHANUM

   The constructions for "userinfo", "hostport", and "unreserved" are reporting
   on.  They MAY also have the Byte-Range of
   detailed in RFC2396 [10].  URLs designating MSRP over TCP MUST
   include the chunk they are
   reporting on. "tcp" parameter.  If an MSRP element receives a REPORT for a Message-ID
   it does not recognize, it SHOULD silently ignore some other transport is used, the REPORT.

   Report-Success and Report-Failure
   "tcp" parameter MUST NOT be present in a REPORT
   request. present.

      Since this document only specifies MSRP nodes MUST NOT send REPORT requests over TCP, all MSRP URLs
      herein  use the "tcp" parameter.  Documents that provide bindings
      on other transports should define respective parameters for those
      transports.

   An MSRP URL hostport field identifies a participant in response to
   report requests. an MSRP Nodes
   session.  If the hostport contains a numeric IP address, it MUST NOT send MSRP responses to REPORT
   requests. also
   contain a port.  The combinations resource part identifies a particular session
   the participant.  The absence of reporting may seem overly complex the resource part indicates a
   reference to an MSRP host device, but they are
   needed does not specifically refer to meet the various scenarios
   a particular session resource.

   A scheme of currently deployed IM
   systems.  Report-Success might "msrps" indicates the underlying connection MUST be "no"
   protected with TLS.

   MSRP has an IANA registered recommended port defined in many public systems to
   reduce load but Section 14.1.
   This value is used in some current enterprise systems, such not a default, as
   systems the URL negotiation process described
   herein will always include explicit port numbers.  However, the URLs
   SHOULD be configured so that the recommended port is used whenever
   appropriate.  This makes life easier for securities trading.  A Report-Failure value of "no"
   is useful network administrators who
   need to manage firewall policy for sending system messages such as "the system is going
   down in 5 minutes" without causing MSRP.

   The server part will typically not contain a response explosion userinfo component, but
   MAY do so to indicate a user account for which the
   sender.  A Report-Failure of "yes" session is used by many systems valid.
   Note that wish
   to notify this is not the user if same thing as identifying the message failed but some other systems
   choose to use session
   itself.  If a value of "partial" to reduce the load on the servers
   caused by 200 OK responses, but still allow error responses userinfo component exists, it MUST be constructed only
   from "unreserved" characters, to avoid a need for escape processing.
   Escaping MUST NOT be
   sent used in many cases.

4.4  MSRP Connection Model

   When an MSRP wishes to send a request to URL.  Furthermore, a peer identified by userinfo
   part MUST NOT contain password information.

   The following is an MSRP
   URL, it first needs example of a connection, with the appropriate security
   properties, typical MSRP URL:

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

5.1  MSRP URL Comparison

   MSRP URL comparisons MUST be performed according to the host specified in the URL. following
   rules:

   1.  The scheme must match exactly.

   2.  If the sender already
   has such hostpart contains an eplicit IP address, and/or port,
       these are compared numerically.  Otherwise, hostpart is compared
       as a connection, that is, one associated with case insensitive character string.

   3.  If the same host,
   port, and URL scheme, port exists explicitly in either URL, then it SHOULD reuse that connection.

   When a new MSRP session must match
       exactly.  An URL with an explicit port is created, the convention never equivalent to
       another with no port specified.

   4.  The resource part is that the
   element that sent the SDP offer MUST immediately issue compared as case sensitive.  A URL without a SEND request
       resource part is never equivalent to the answerer.  This request MAY have a empty body, or MAY carry
   content.

   When one that includes a new connection needs to be formed, the element looks at the
   URL to decide on the type of connection (TLS, TCP, etc.) then
   connects to 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 relevant parts are limited
   to unreserved characters.

5.2  Resolving MSRP Host Device

   An MSRP host indicated device is identified by the URL, following the URL
   resolution rules in Section 5.2.  For connections using the msrps:
   scheme, the SubjectAltName in the received certificate MUST match the
   hostname port server part of an MSRP URL.

   If the URL server part contains a numeric IP address and the certificate port, they MUST
   be valid, including
   having a date that is valid and being signed by an acceptable
   certificate authority.  At this point the device that initiated the
   connection can assume that this connection is with the correct host. used as listed.

   If the connection used mutual TLS authentication, server part contains a host name and the TLS client
   presented a valid certificate, then the element accepting the
   connection can know the identity of port, the connecting host.  When mutual
   TLS authentication is not used, the listening
   device MUST wait until
   it receives determine a request on host address by doing an A or AAAA DNS query,
   and use the port as listed.

   If a connection attempt fails, the device SHOULD attempt to connect
   to determine the identity of addresses returned in any additional A or AAAA records, in the connecting device.

   When
   order the first request arrives, it's To-Path header field should
   contain a URL records were presented.

      This process assumes that the listening element handed out in the SDP for a
   session.  The element that accepted the connection looks up port is always known
      prior to resolution.  This is always true for the MSRP URL uses
      described in the received request, this document, that is, URLs always created and determines which session
      consumed by automata, rather than by humans.  The introduction of
      relays may create situations where this is not the case.  For
      example, the MSRP URL that a user enters into a client to
      configure it matches.  If to use a match exists, relay may be intended to be easily
      remembered and communicated by humans, and therefore is likely to
      omit the node MUST assume that port.  Therefore, the host that formed relay specification [21] may
      describe additional steps to resolve the
   connection is port number.

   MSRP devices MAY use other methods for discovering other such
   devices, when appropriate.  For example, MSRP endpoints may use other
   mechanisms to discover relays, which are beyond the host that scope of this URL was given to.  If no match
   exists, the node MUST reject
   document.

6.  Method-Specific Behavior

6.1  Constructing Requests

   To form a new request, the request with sender creates a 481 response.  The
   node MUST also check unique transaction
   identifier and uses this and the method name to make sure create an MSRP
   request start line.  Next, the session is not already sender places the target path in use
   on another connection.  If so, it MUST reject a
   To-Path header, and the request with sender's URL in a 506
   response. From-Path header.  If it were legal to have
   multiple connections associated with URLs are present in the
      same session, a security problem would exist.  If To-Path, the initial SEND
      request leftmost is not protected, an eavesdropper might learn the URL, and
      use it to insert messages into first
   URL visited; the session via a different
      connection.

   If a connection fails for any reason, then an MSRP endpoint MUST
   consider failed any sessions associated with rightmost URL is the connection last URL visited.  The
   processing then becomes method specific.  Additional method-specific
   headers are added as well.
   When an endpoint notices such a failure, it SHOULD attempt to
   re-create described in the following sections.

   After any such sessions using method-specific headers are added, processing continues to
   handle a new SDP exchange.  If body, if present.  A body in a
   replacement session is successfully created, endpoints MAY attempt to
   resend any content for which delivery on the original session could
   not Non-SEND request MUST NOT be confirmed.
   longer than 2048 octets.  If it does this, the Message-ID values for the
   resent messages request has a body, it must contain
   a Content-Type header field.  It may contain other MIME specific
   headers.  The Content-Type header MUST match those used in be the initial attempts.  If last header line.  The
   body MUST be separated from the receiving endpoint receives more than one message headers with the same
   Message-ID.  It SHOULD assume an extra CRLF.

   The boundary marker that terminates the messages are duplicates.  It
   MAY take any action based on body MUST be preceded by a
   CRLF that knowledge, but SHOULD NOT present
   the duplicate messages to the user without warning is not part of the duplicates.

   In this situation, body and then seven "-" (minus sign)
   characters.  After the endpoint boundary marker, there MUST choose Message-ID values so be a flag
   character that
   they are unique in is  a "$" (for the context last chunk of both the original session and the
   replacement session.

   When endpoints create a new session in this fashion, complete
   message), "#" (for the last chunk of an aborted message), or "+" (for
   chunks for a
   given logical message MAY be split across other than the sessions.  However,
   endpoints SHOULD NOT split chunks between sessions under normal
   circumstances. last).  If a connection fails, the sender SHOULD attempt to re-setup chunk represents the URL
   path using a new offer, for example, in a SIP re-invite or update
   [13].  It MUST not assume data that
   forms the new URLs in the SDP will be end of the
   same as complete message, the old ones.  A connection SHOULD not flag value MUST be closed while there
   are sessions a "$".
   If sender is abandoning an incomplete message, and intends to send no
   further chunks in that are using this connection.

5.  MSRP URLs

   An MSRP URL follows message, it MUST be a subset of "#".  Otherwise it MUST
   be a "+".

   If the URL syntax in Appendix A of
   RFC2396 [11], with request contains a scheme of "msrp" or "msrps":

      MSRP_urls = msrp-scheme "://" [userinfo "@"] hostport ["/"
      resource] ";" transport
      msrp-scheme = "msrp" / "msrps"
      resource = 1*unreserved
      transport = "tcp" / token

   The constructions for "userinfo", "hostport", body, the sender MUST check the body to
   insure that the closing sequence (a CRLF, seven hyphens, and "unreserved" are
   detailed the
   transaction identifier) is not present in RFC2396 [11].  URLs designating MSRP over TCP MUST
   include the "tcp" parameter. body.  If some other transport the closing
   sequence is used, present in the
   "tcp" parameter body, the sender MUST NOT be present.

      Since this document only specifies MSRP over TCP, all MSRP URLs
      herein  use the "tcp" parameter.  Documents choose a new
   transaction identifier 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
      particular combination of transport parameters.

   An MSRP URL server part identifies a participant not present in an MSRP session.

   If the server part contains body, and add the
   closing sequence, including the "$", "#", or "+" character, and a numeric IP address, it
   final CRLF.

   Finally, requests which have no body MUST also NOT contain a port.  The resource part identifies Content-Type
   header or any other MIME specific header.  Bodiless requests MUST
   contain a particular session
   the participant.  The absence of closing sequence after the resource part indicates final header.

   Once a
   reference request is ready for delivery, the sender follows the
   connection management (Section 4.4) rules to forward the request over
   an MSRP host device, but does not specifically refer existing open connection or create a new connection.

6.1.1  Delivering SEND requests

   When an endpoint has a message to deliver, it first generates a particular session resource.

   A scheme of "msrps" indicates the underlying connection new
   unique Message-ID.  This ID MUST be
   protected with TLS.

   MSRP has an IANA registered recommended port defined in Section 15.1.
   This value is not a default, as unique within the URL negotiation process described
   herein will always include explicit port numbers.  However, scope of the URLs
   SHOULD be configured so that
   session.  If the recommended port message is used whenever
   appropriate.  This makes life easier for network administrators who
   need to manage firewall policy for MSRP.

   The server part will typically not contain a userinfo component, but larger than 2048 octets in length, it
   either generates an interruptible chunk (which is RECOMMENDED), or it
   MAY do so to indicate break the complete message into chunks of 2048 octets.  It then
   generates a user account SEND request for which the session is valid.
   Note that this is not each chunk,  following the same thing as identifying procedures
   for constructing requests (Section 6.1).

   Each chunk MUST contain a Message-ID header field containing the session
   itself.
   Message-ID.  If a userinfo component exists, the sender wishes non-default status reporting, it
   MUST be constructed only
   from "unreserved" characters, to avoid a need for escape processing.
   Escaping MUST NOT be used in an MSRP URL.  Furthermore, insert a userinfo
   part MUST NOT contain password information.

   The following is Report-Failure and/or Report-Success header field with
   an example appropriate value.  All chunks of a typical MSRP URL:

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

5.1  MSRP URL Comparison

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

   1.  The scheme must match exactly.

   2.  The host part is compared as case insensitive.

   3.
   same Report-Failure and Report-Success values in their SEND requests.

   If success reports are requested, i.e.  the port exists explicitly in either URL, then it must match
       exactly.  An URL with an explicit port value of the
   Report-Success header is never equivalent "yes", the sending device MAY wish to
       another with no port specified.

   4.  The resource part is compared as case sensitive.  A URL without run a
       resource part is never equivalent to one
   timer of some value that 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 makes sense for URL comparison.

   Path normalization its application and take
   action if a success Report is not relevant received in this time.  There is no
   universal value for MSRP URLs.  Escape
   normalization this timer.  For many IM applications, it may be
   2 minutes while for some trading systems it may be under a second.
   Regardless of whether such a timer is used, if the success report has
   not required, since been received by the time the session is ended, the relevant parts are limited
   to unreserved characters.

5.2  Resolving MSRP Host Device

   An MSRP host device SHOULD
   inform the user.

   If the value of "Report-Failure" is identified by set to "yes", then the server part sender of an MSRP URL.

   If
   the server part contains request runs a numeric IP address and port, they MUST
   be used as listed. timer.  If the server part contains a host name and a port, 200 response to the connecting
   device MUST determine a host address by doing an A or AAAA DNS query,
   and use transaction is
   not received within 30 seconds from the port as listed.

   If a connection attempt fails, time the device SHOULD attempt to connect
   to last byte of the addresses returned in any additional A or AAAA records, in
   transaction is sent, the
   order element MUST inform the records were presented.

      This process assumes user that the connection port
   request probably failed.  If the value is always known
      prior set to resolution.  This is always true for "partial", then the MSRP URL uses
      described in this document, that is, URLs always created and
      consumed by automata, rather than by humans.  The introduction of
      relays may create situations where this is not the case.  For
      example,
   element sending the MSRP URL that transaction does not have to run a timer, but
   MUST inform the user enters into if receives a client to
      configure it non-recoverable error response to use
   the transaction.

   If no Report-Success header is present in a relay may be intended to SEND request, it MUST be easily
      remembered and communicated by humans, and therefore
   treated the same as a Report-Success header with value of "no".  If
   no Report-Failure header is likely to
      omit present, it MUST be treated the port.  Therefore, same as a
   Report-Failure header with value of "yes".  REPORT requests MUST have
   the relay specification [21] may
      describe additional steps to resolve same Message-ID header value as the port number.

   MSRP devices MAY use other methods for discovering other such
   devices, when appropriate.  For example, MSRP endpoints may use other
   mechanisms to discover relays, which request they are beyond reporting
   on.  They MAY also have the scope Byte-Range of this
   document.

6.  Method-Specific Behavior

6.1  Constructing Requests

   To form a new request, the sender creates a unique transaction
   identifier and uses this and the method name to create chunk they are
   reporting on.  If an MSRP
   request start line.  Next, the sender places the target path in element receives a
   To-Path header, and the sender's URL in REPORT for a From-Path header.  If
   multiple URLs are present in the To-Path, the leftmost is the first
   URL visited; Message-ID
   it does not recognize, it SHOULD silently ignore the rightmost URL is the last URL visited.  The
   processing then becomes REPORT.

   Report-Success and Report-Failure MUST NOT be present for any method specific.  Additional method-specific
   headers are added as described
   other than SEND.  MSRP nodes MUST NOT send REPORT requests in the following sections.

   After any method-specific headers are added, processing continues
   response to
   handle a body, if present.  A body in a Non-SEND request report requests.  MSRP Nodes MUST NOT be
   longer than 2048 octets.  If send MSRP responses
   to REPORT requests.

   The Byte-Range header value contains a starting value (range-start)
   followed by a "-", an ending value (range-end) followed by a "/", and
   finally the request has total length.  The first byte in the message is indicated
   by a body, it must contain one, rather than a Content-Type header field.  It may contain other MIME specific
   headers. zero.

   The Content-Type header MUST be first chunk of the last message SHOULD, and all subsequent chunks MUST
   include a Byte-Range header line. field.  The
   body range-start field MUST be separated from the headers with an extra CRLF.

   If
   indicate the request contains a body, position of the sender MUST check first byte in the body to
   insure that the closing sequence (a CRLF, seven hyphens, and the
   transaction identifier) is not present in the body.  If overall
   message (that is, a value of one).  The range-end field SHOULD
   indicate the closing
   sequence is present position of the last byte in the body, the sender if known.  It
   MUST choose a new
   transaction identifier that take the value of "*" if the position is not present in unknown, or if the body, and add
   request needs to be interruptible.  The total field SHOULD contain
   the
   closing sequence, including total size of the "$" or "+" character, and a final
   CRLF.

   Finally, requests which have no body MUST NOT message, if known.  The total field MAY contain
   a Content-Type
   header or any "*" if the total size of the message is not known in advance.  All
   chunks other MIME specific header.  Bodiless requests than the last MUST
   contain include a closing sequence after "+" character in the
   continuation field of the closing line.  The final header.

   Once chunk MUST use a request
   "$" character if it completes the message, or a "#" if the sender is ready for delivery,
   aborting the message.  The sender follows MUST send all chunks in Byte-Range
   order.  (However, the
   connection management (Section 4.4) rules to forward receiver cannot assume the request over
   an existing open connection or create a new connection.

6.1.1  Delivering SEND requests

   When will be
   delivered in order, as an endpoint has a message to deliver, it first generates intervening relay may have changed the
   order.)

   To insure fairness over a new
   unique Message-ID.  This ID connection, senders MUST be unique within the scope NOT send chunks
   with a body larger than 2048 octets unless they are prepared to
   interrupt them.  A sender can use one of the
   session.  If the message following two strategies
   to satisfy this requirement.  The sender is STRONGLY RECOMMENDED to
   send messages larger than 2048 octets in length, it
   either generates an interruptible chunk (which using as few chunks as
   possible, interrupting chunks (at least 2048 octets long) when other
   traffic is RECOMMENDED), or it
   MAY break waiting to use the complete message into same connection.  Alternatively, the
   sender MAY simply send chunks of in 2048 octets.  It then
   generates a SEND request for each chunk,  following the procedures
   for constructing requests (Section 6.1).

   Each chunk MUST contain a Message-ID header field containing octet increments until the
   Message-ID.  If
   final chunk.  Note that the sender wishes non-default status reporting, it
   MUST insert a Report-Failure and/or Report-Success header field with
   an appropriate value.  All chunks former strategy results in markedly more
   efficient use of the same message connection.  All MSRP nodes MUST use the
   same Report-Failure and Report-Success values in their SEND requests.

   If success reports are requested, the sending device MAY wish be able to run
   a timer
   receive chunks of some value that makes sense any size from 0 octets to the maximum number of
   octets they can receive for it's application and take
   action if a success Report is not received in this time.  There is no
   universal value for this timer.  For many IM applications, it may be
   2 minutes while complete message.  Senders SHOULD NOT
   break messages into chunks smaller than 2048 octets, except for some trading systems it may be under a second.
   Regardless the
   final chunk of whether such a timer complete message.

   A SEND request is used, interruptible if the success report it either has
   not been received by the time the session is ended, the device SHOULD
   inform the user.

   The first chunk of the message SHOULD, and all subsequent chunks MUST
   include a no Byte-Range header field.  The range-start
   field, or has such a field MUST
   indicate the position of the first byte with a "*" in the last-byte sub-field.

   A SEND request is interrupted while a body is in the overall
   message.  The range-end field SHOULD indicate the position process of the
   last byte in the body, if known.  It MUST take the value of "*" if
   the position is unknown, or if the request needs to be interruptible.
   The total field SHOULD contain the total size of the message, if
   known.  The total filed MAY contain a "*" if the total size of the
   message is not known in advance.  All chunks other than the last MUST
   include a "+" character in the continuation field of the 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 requests will be delivered in order, as an intervening
   relay may have changed the order.)

   If the sender chooses to send a body larger than 2048 octets in a
   single chunk, the request MUST be constructed so that it can be
   interrupted.  A SEND request is interruptible if it either has no
   Byte-Range header field, or has such a field with a "*" in the
   last-byte sub-field.

   A SEND request is interrupted while a body is in the process of being
   written to being
   written to the connection by simply noting how much of the message
   has already been written to the connection, then writing out the
   boundary string to end the chunk.  It can then be resumed in a
   another chunk with the same Message-ID and a Byte-Range header range
   start field containing the position of the first byte after the
   interruption occurred.

   SEND requests larger than 2k MUST be interrupted to send pending
   response or REPORT requests.  If multiple SEND requests from
   different sessions are concurrently being sent over the same
   connections,
   connection, the device SHOULD implement some scheme to alternate
   between them such that each concurrent request gets a chance to send
   some fair portion of data at regular intervals suitable to the
   application.

   The sender MUST NOT assume that a message is received by the peer
   with the same chunk allocation it was sent with.  An intervening
   relay could possibly break SEND requests into smaller chunks, or
   aggregate multiple chunks into larger ones.

   The default disposition of body is "render".  If the sender wants
   different disposition, it MAY insert a Content-Disposition header.
   Since MSRP is a binary protocol, transfer encoding MUST be "binary".

6.1.2  Sending REPORT requests

   REPORT requests are similar to SEND requests, except that report
   requests MUST NOT include Report-Success or Report-Failure header
   fields, and MUST contain a Status header field.  REPORT requests MUST
   contain the Message-ID header from the original SEND request.

   If an MSRP element receives a REPORT for a Message-ID it does not
   recognize, it SHOULD silently ignore the REPORT.

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

   REPORT requests MAY will normally not include a body.  If a body is included, it SHOULD
   be of body, as the DSN MIME type detailed REPORT
   request header fields can carry sufficient information in RFC1894 [8], but most cases.
   However, REPORT requests MAY be of some
   other type if include a body containing additional
   information about the sender status of the assocated SEND request indicated support in request.  Such a
   body is informational only, and the
   "receipt-type" parameter sender of the respective Report-Success or
   Report-Failure header field.  This parameter contains the alternative
   MIME type that REPORT request
   SHOULD be used for this particular report.  A client
   specifying an alternative 'receipt-type' for an MSRP transaction MUST
   also be capable of receiving NOT assume that the default format specified in this
   RFC1894.  Use of recipient pays any attention to the DSN MIME format in MSRP is described in Section
   8 body.
   Since REPORT requests are not interruptible, the size of such a body
   MUST NOT exceed 2 kilobytes.

   An endpoint MUST send a success report if it successfully receives a
   SEND request which contained a Report-Success value of "yes", "yes" and
   either contains a complete message, or contains the last chunk needed
   to complete the message.  This request is sent following the normal
   procedures (Section 6.1), with a few additional requirements.

   The endpoint inserts a To-Path header field containing the From-Path
   value from the original request, and a From-Path header containing
   the URL identifying itself in the session.  The endpoint 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 value from the original request.

   Positive status reports SHOULD NOT include a payload.

   The endpoint MUST NOT send a success report for a SEND request that
   either contained no Report-Success header field, or contained such a
   field with a value of "no".  That is, if no Report-Success header
   field is present, it is treated identically to one with a value of
   "no."

6.1.3  Failure REPORT Generation

   If an MSRP endpoint receives a SEND request that it cannot process
   for some reason, and the Report-Failure header either was not present
   in the original request, or had a value of "yes", it SHOULD simply
   send a transaction response with an appropriate
   include the appopriate error response code. code in the transaction respons.
   However, there may be situations where the error cannot be determined
   quickly, such as when the endpoint is a gateway that must wait for a
   downstream network to indicate an error.  In this situation, it MAY
   send a 200 OK response to the request, and then send a failure REPORT
   request when the error is detected.

   If the endpoint receives a SEND request with a Report-Failure header
   field value of "none", "no", then it MUST NOT send a failure REPORT request,
   and SHOULD NOT send an MSRP response.  If the value is "partial", it
   SHOULD NOT send a 200 response to the request, but SHOULD send a
   non-200 class response if appropriate.

   As stated above, if no Report-Failure header is present, it MUST be
   treated the same as a Report-Failure header with value of "yes".

   Construction of failure REPORT requests is identical to that for
   success reports, except the Status header code and reason fields
   SHOULD MUST
   contain appropriate error codes.  Any error response code defined in
   this specification MAY also be used in failure reports.
   Failure REPORT requests MAY contain a payload, using the DSN MIME
   type.  They MAY contain some other type if allowed by a receipt-type
   in the Report-Failure header field.

   If a failure report is sent in response to a SEND request that
   contained a chunk, it MUST include a Byte-Range header indicating the
   actual range being reported on.  It can take the range-start and
   total values from the original SEND request, but MUST calculate the
   range-end field from the actual body data.

   Endpoints SHOULD NOT send REPORT requests if they have reason to
   believe the request will not be delivered.  For example, they SHOULD
   NOT send a REPORT request on a session that is no longer valid.

      This section only describes failure report generation behavior for
      MSRP endpoints.  Relay behavior is beyond the scope of this
      document, and will be considered in a separate document.  We
      expect failure reports to be more commonly generated by 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 immediately generate a
   response.  Likewise, if an MSRP endpoint receives a request that
   contains a Report-Failure header value of "partial", and the receiver
   is unable to process the request, it SHOULD immediately generate a
   response.

   To construct the response, the endpoint first creates the response
   start-line, inserting appropriate response code and reason fields.
   The transaction identifier in the response start line MUST match the
   transaction identifier from the original request.

   The endpoint then inserts an appropriate To-Path header field.  If
   the request triggering the response was a SEND request, the To-Path
   header field is formed by copying the last (right-most) URI in the
   From-Path header field of the request.  (Unlike other methods,
   responses to SEND requests are returned only to the previous hop.)
   For responses to all other requests, the 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 writing the reversed list
   into the To-Path of the response.  (Legal REPORT requests do not
   request responses, so this specification doesn't exercise the
   behavior described above, however we expect that extensions for
   gateways and relays will need such behavior.)

   Finally, the endpoint inserts a From-Path header field containing the
   URL that identifies it in the context of the session, followed by the
   closing sequence after the last header field.  The response MUST be
   transmitted back on the same connection on which the original request
   arrived.

6.3  Receiving Requests

   The receiving endpoint must first check the URL in the To-Path to
   make sure the request belongs to an existing session.  When the
   request is received, the To-Path will have exactly one URL, which
   MUST map to an existing session that is associated with the
   connection on which the request arrived.  If this is not true, and
   the request contained a Report-Failure header value of "no", then the
   receiver SHOULD quietly ignore the request.  If the Report-Failure
   header is not present, or had any other value, then the receiver MUST
   return a 481 response.

   Further request processing by the receiver is method specific.

6.3.1  Receiving SEND requests

   When the receiving endpoint receives a SEND request, it first
   determines if it contains a complete message, or a chunk from a
   larger message.  If the request contains no Byte-Range header, or
   contains one  with a range-start value of "1", and the closing line
   continuation flag has a value of "$", then the request contained the
   entire message.  Otherwise, the receiver looks at the Message-ID
   value to associate chunks together into the original message.  It
   forms a virtual buffer to receive the message, keeping track of which
   bytes have been received and which are missing.  The receiver takes
   the data from the request and places it in the appropriate place in
   the buffer.  The receiver MUST determine the actual length of each
   chunk by inspecting the payload itself; it is 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

   Receivers MUST not assume the chunks will be delivered in order or
   that they will receive all the chunks with "+" flags before they
   receive the body is outside chunk with the scope "$" flag.  In certain cases of MSRP and largely
   determined by the MIME type.  The body MAY connection
   failure, it is possible for information to be rendered after the
   whole message duplicated.  If chunks
   data is received or partially that overlaps already received data for the 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 100 was received and a chunk arrives that contains bytes 50 to
   150, this second chunk will overwrite bytes 50 to 100 of the data
   that had already been received.  Although other schemes work, this is
   the easiest for the receiver and results in consistent behavior
   between clients.

   The seven "-" before the boundary are used so that the receiver can
   search for the value "----", 32 bits at a time to find the probable
   location of the boundary.  This allows most processors to locate the
   boundaries and copy the memory at the same rate that a normal memory
   copy could be done.  This approach results in a system that is as
   fast as framing based on specifying the body length in the headers of
   the request, but also allows for the interruption of messages.

   What is done with the body is outside the scope of MSRP and largely
   determined by the MIME Content-Type and Content-Disposition.  The
   body MAY be rendered after the whole message is received or partially
   rendered as it is being received.

   If the SEND request contained a Content-Type header field indicating
   an unsupported MIME type, the receiver SHOULD send a 415 response, if
   allowed by the Report-Failure header field.  All MSRP endpoints MUST
   be able to receive the multipart/mixed and multipart/alternative MIME
   types.

   If the SEND request contained a Report-Success header field with a
   value of "yes", and the request is either contains the entire message
   or the last chunk needed to complete a message, the receiver MUST
   send a success REPORT request back to the sender.

6.3.2  Receiving REPORT requests

   When an endpoint receives a REPORT request, it may correlate it to
   the original SEND request using the Message-ID and the 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 original messages.

   An endpoint that receives a REPORT request containing a Status header
   with a namespace field of "000", it SHOULD interpret the report in
   exactly the same way it would interpret an MSRP transaction response
   with a response code matching the short-code field.

   It is possible to receive a failure report or a failure transaction
   response for a chunk that is currently being delivered.  In this case
   the 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.

   MSRP Modes MUST NOT send MSRP responses to REPORT requests.

7.  Using MSRP with SIP

7.1  SDP Offer-Answer Exchanges for MSRP Sessions

   MSRP sessions will typically be initiated using the 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 the IANA Considerations
   section.

   The general format of an SDP media-line is:

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

   An offered or accepted MSRP media-line MUST have the following value
   exactly, with the exception that the port field MAY be set to zero.
   (According to [3], a user agent that wishes to accept an offer, but
   not a specific media-line MUST set the port number of that media-line
   to zero (0).)

   m=message 9 msrp *

      While MSRP could theoretically carry any media type, "message" is
      appropriate.  For MSRP, the port number is always ignored--the
      actual port number is provided in an MSRP URL.  Instead "9" is
      used, which is an innocuous value which is assigned to the discard
      port.  The protocol is always "msrp", and the value of the format
      list is always a single asterisk character ("*").

   An MSRP media-line is always accompanied by a mandatory "path"
   attribute.  This attribute contains a space separated list of URLs
   that must be visited to contact the user agent advertising this
   session-description.  If more than one URL is present, the leftmost
   URL is the first URL that must be visited to reach the target
   resource.  (The path list can contain multiple URLs to allow for the
   deployment of gateways or relays in the future.)  MSRP
   implementations which can accept incoming connections will typically
   only provide a single URL here.

   MSRP media lines MUST also be accompanied by an "accept-types"
   attribute.  This attribute contains a list of MIME types which are
   acceptable to the endpoint.

   A "*" entry in the accept-types attribute indicates that the sender
   may attempt to send content with media types that have not been
   explicitly listed.  Likewise, an entry with an explicit type and a
   "*" character as the subtype indicates that the sender may attempt to
   send content with any subtype of that type.  If the receiver receives
   an MSRP request and is able to process the 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 non-listed types.

   This feature is needed as, otherwise, the list of formats for rich IM
   devices may be prohibitively large.

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

   Occasionally an endpoint will need to specify a MIME body type that
   can only be used if wrapped inside a listed container type.

   Endpoints MAY specify MIME types that are only allowed when wrapped
   inside compound types using the "accept-wrapped-types" attribute in
   an SDP a-line.

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

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

      The approach of specifying types that are only allowed inside of
      containers separately from the primary payload types allows an
      endpoint to force the use of certain wrappers.  For example, a
      CPIM [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 might attempt to use
      those types without the wrapper.
      All types listed in either the accept-types or
      accept-wrapped-types attributes MAY include a 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 NOT exceed the max-size limit, if
      any, when sending messages of any listed type.  If a type is
      listed without the 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. MSRP
   sessions.  These URLs are negotiated detailed below and in the IANA Considerations
   section.

   The general format of an SDP exchange.  Each SDP offer or answer MUST
   contain one media-line is:

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

   An offered or more accepted MSRP URL in a path attribute.  This attribute has media-line MUST have the following syntax:

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

   where MSRP_URL is an msrp: or msrps: URL as defined in Section 5.
   MSRP URLs included in value
   exactly, with the exception that the port field MAY be set to zero.
   (According to [3], a user agent that wishes to accept an SDP offer or answer offer, but
   not a specific media-line MUST include  explicit set the port numbers.

   An number of that media-line
   to zero (0).)

   m=message 9 msrp *

      While MSRP device uses could theoretically carry any media type, "message" is
      appropriate.  For MSRP, the URL to determine port number is always ignored--the
      actual port number is provided in an MSRP URL.  Instead a host address, port,
   transport, and protection level when connecting, and to identify the
   target when sending requests and responses. dummy
      value is used, which is always ignored if non-zero.  The offerer and answerer each selects a URL to represent itself, protocol
      is always "msrp", and
   send it to the peer device in value of the SDP document.  Each device stores format list is always a
      single asterisk character ("*").

   An MSRP media-line is always accompanied by a mandatory "path"
   attribute.  This attribute contains a space separated list of URLs
   that must be visited to contact the path value received from user agent advertising this
   session-description.  If more than one URL is present, the peer, and uses leftmost
   URL is the first URL that value as must be visited to reach the target
   resource.  (The path list can contain multiple URLs to allow for requests inside the resulting session.  If
   deployment of gateways or relays in the path future.)  MSRP
   implementations which can accept incoming connections will typically
   only provide a single URL here.

   MSRP media lines MUST also be accompanied by an "accept-types"
   attribute.  This attribute received from the peer contains more than one URL, then a list of MIME types which are
   acceptable to the
   target URL is endpoint.

   A "*" entry in the rightmost, while accept-types attribute indicates that the leftmost sender
   may attempt to send content with media types that have not been
   explicitly listed.  Likewise, an entry represents with an explicit type and a
   "*" character as the
   adjacent hop. subtype indicates that the sender may attempt to
   send content with any subtype of that type.  If only one entry is present, then it is both the peer receiver receives
   an MSRP request and adjacent hop URL.  The target path is able to process the entire path attribute
   value received from the peer.

   The following example shows an SDP offer media type, it does so.
   If not, it will respond with a session URL 415 response.  Note that all explicit
   entries SHOULD be considered preferred over any non-listed types.
   This feature is needed as, otherwise, the list 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 formats for rich IM
   devices may be prohibitively large.

   The rightmost URI 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 path accept-types attribute may be used both
   as the root payload, or may be wrapped in a listed container type.
   Any container types MUST identify also be listed in the accept-types
   attribute.

   Occasionally an endpoint will need to specify a MIME body type that generated
   can only be used if wrapped inside a listed container type.

   Endpoints MAY specify MIME types that are only allowed when wrapped
   inside compound types using the "accept-wrapped-types" attribute in
   an SDP document, or some other location where that
   endpoint wishes a-line.

   The semantics for accept-wrapped-types are identical to receive requests associated those of the
   accept-types attribute, with the session.  It
   MUST exception that the specified types
   may only be assigned  for this particular session, and MUST NOT duplicate
   any URI used when wrapped inside containers.  Only types listed
   in use the accept-types attribute may be used as the "root" type for the
   entire body.  Since any other session type listed in which the endpoint is
   currently participating.  It SHOULD accept-types may be hard to guess, used both
   as a root body, and protected
   from eavesdroppers.  This is discussed wrapped in more detail other bodies, format entries from
   accept-types SHOULD NOT be repeated in Section 14.

7.1.2  Path Attributes with Multiple URLs

   As mentioned previously, this document describes MSRP attribute.

   This approach does not allow for
   peer-to-peer scenarios, that is, when no relays are used.  However,
   we expect specifying distinct lists of
   acceptable wrapped types for different types of containers.  If an
   endpoint understands a separate document MIME type in the context of one wrapper, it is
   assumed to describe understand it in the use context of relays.  In
   order any other acceptable
   wrappers, subject to allow an MSRP device any constraints defined by the wrapper types
   themselves.

      The approach of specifying types that are only implements allowed inside of
      containers separately from the core
   specification primary payload types allows an
      endpoint to interoperate with devices that force the 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 of certain wrappers.  For example, a URL for each
      CPIM [13] gateway device in the relay chain into the SDP path
   attribute.  The final entry would point may require all messages to be wrapped
      inside message/cpim bodies, but may allow several content types
      inside the endpoint itself.  The
   other entries would indicate each proposed relay, in order.  The
   first entry would point wrapper.  If the gateway were to specify the first relay wrapped
      types in the chain; that is, the
   relay to which the peer device, or a relay operation on accept-types attribute, its behalf,
   should connect.

   Endpoints that do not wish peer might attempt to insert a relay, including use
      those that do
   not support relays at all, will put exactly one URL into the path
   attribute.  This URL represents both types without the wrapper.
      An endpoint for the session,
   and MAY indicate the connection point.

   While endpoints that implement only this specification will never
   introduce a relay, they will need to be able to interoperate with
   other endpoints that do use relays.  Therefore, maximim size message they MUST be prepared wish to
      receive more than one URL in using the max-size a-line attribute Max-size refers to the SDP path attribute.  When an
   endpoint receives more than
      complete message, not the size of any one URL in a path header, only chunk.  Senders SHOULD
      NOT exceed the first
   entry is relevant max-size limit for purposes of resolving any message sent in the address and port, and
   establishing
      resulting session.  However, the network connection, receiver should consider max-size
      value as it describes the first
   adjacent hop.

   If an endpoint puts more than one a hint.

           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 = (type "/" subtype) / (type "/" "*") / ("*")
           type = token
           subtype = token

           max-size = max-size-label ":" max-size-value
           max-size-label = "max-size"
           max-size-value = 1*(DIGIT)

7.1.1  URL Negotiations

   Each endpoint in an MSRP session is identified by a path attribute, URL.  These URLs
   are negotiated in the final SDP exchange.  Each SDP offer or answer MUST
   contain one or more MSRP URL in the a path (the peer URL) attribute.  This attribute MUST exhibit has
   the uniqueness
   properties described above.  Uniqueness requirements for other
   entries following syntax:

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

   where MSRP_URL is an msrp: or msrps: URL as defined in the attribute are out of scope for this document.

7.1.3  Updated Section 5.
   MSRP URLs included in an SDP Offers offer or answer MUST include  explicit
   port numbers.

   An MSRP endpoints may sometimes need device uses the URL to send additional SDP exchanges
   for an existing session.  They may need determine a host address, port,
   transport, and protection level when connecting, and to identify the
   target when sending requests and responses.

   The offerer and answerer each selects a URL to represent itself, and
   send periodic exchanges
   with no change it to refresh state in the network, for example, SIP
   Session Timers.  They may need to change some other stream peer device 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 SDP document.  Each device stores
   the new offer assumes path value received from the role of offerer peer, and uses that value as the
   target for all
   purposes.  The answerer MUST respond with a requests inside the resulting session.  If the path
   attribute that
   represents a valid path to itself at received from the time of peer contains more than one URL, then the updated
   exchange.  This new path may be
   target URL is the same as its previous path, but
   may be different.  The new offerer MUST NOT assume that rightmost, while the peer will
   answer with leftmost entry represents the same path it used previously.
   adjacent hop.  If either party wishes to send an SDP document that changes nothing
   at all, only one entry is present, then it MUST have is both the same o-line as in peer
   and adjacent hop URL.  The target path is the previous
   exchange.

7.1.4  Example SDP Exchange

   Endpoint A wishes to invite Endpoint B to a MSRP session.  A offers entire path attribute
   value received from the peer.

   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 example shows an SDP offer with its own URL: a session URL of
   "msrp://a.example.com:7394/2s93i;tcp"

    v=0
    o=userb 2890844530 2890844532
    o=alice 2890844526 2890844527 IN IP4 bob.example.com alice.example.com
    s=
    c=IN IP4 bob.example.com
    t=0 0 alice.example.com
    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
    a=accept-types:text/plain
    a=path:msrp://a.example.com:7394/2s93i;tcp

   The rightmost URI in the path attribute MUST identify the endpoint
   that generated the SDP document, or some other location where that
   endpoint wishes to negotiate receive requests associated with the direction session.  It
   MUST be assigned  for this particular session, and MUST NOT duplicate
   any required TCP connection.  The mechanism was
   loosely based on URI in use for any other session in which the COMEDIA [24]work being done endpoint is
   currently participating.  It SHOULD be hard to guess, and protected
   from eavesdroppers.  This is discussed in more detail in Section 13.

7.1.2  Path Attributes with Multiple URLs

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

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

   Endpoints that do not accept connections
   but wish to insert a relay, including those that do
   not support relays at all, will put exactly one URL into the answerer could.  For example, path
   attribute.  This URL represents both the offerer might be behind a
   NAT, while endpoint for the answerer might have a globally routable address.

   The SIMPLE working group chose to remove session,
   and the connection point.

   While endpoints that mechanism from MSRP, as
   it added implement only this specification will never
   introduce a great deal of complexity relay, they will need to connection management.
   Instead, MSRP now specifies a default connection direction.

7.2  MSRP User Experience be able to interoperate with SIP

   In typical SIP applications, when
   other endpoints that do use relays.  Therefore, they MUST be prepared
   to receive more than one URL in the SDP path attribute.  When an
   endpoint receives an INVITE
   request, it alerts more than one URL in a path header, only the user, and waits for user input before
   responding.  This first
   entry is analogous to relevant for purposes of resolving the typical telephone user
   experience, where address and port, and
   establishing the callee "answers" network connection, as it describes the call.

   In contrast, first
   adjacent hop.

   If an endpoint puts more than one URL in a path attribute, the typical user experience for instant messaging
   applications is that final
   URL in the initial received message is immediately
   displayed to path (the peer URL) attribute MUST exhibit the user, without waiting uniqueness
   properties described above.  Uniqueness requirements for other
   entries in the user to "join" the
   conversation.  Therefore, the principle attribute are out of least surprise would
   suggest that scope for this document.

7.1.3  Updated SDP Offers

   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 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 more
   than one endpoint receiving the same INVITE. network, for example, SIP early media [28]
   techniques can be used
   Session Timers.  They may need to establish change some other stream in a preliminary
   session with each
   endpoint, and canceling without affecting the INVITE transaction for any endpoints that
   do not send MSRP traffic after stream, or they may need to change
   an MSRP stream without affecting some period of other stream.

   Either peer may initiate an updated exchange at any time.

8.  DSN payloads in MSRP REPORT Requests  The format of a default REPORT request payload format
   endpoint that sends the DSN taken
   from RFC1894 [8].  Only a minimal subset of fields are relevant for
   MSRP, as detailed in new offer assumes the remainder role 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. offerer for all
   purposes.  The entity generating the DSN report answerer MUST insert the
   Message-ID value that appeared in the original MSRP request into the
   'original-envelope-id' field.  This allows respond with a requesting client to
   explicitly correlate path attribute that
   represents a REPORT request with the original request.
   This correlation is implementation specific and makes no requirements
   on clients valid path to hold state for transactions ID's.  Information
   regarding itself at the original request can time of the updated
   exchange.  This new path may be obtained from the DSN MIME type
   outlined in [8].

8.4  reporting-mta same as its previous path, but
   may be different.  The 'reporting-mta-field' new offerer MUST follow NOT assume that the guidelines set out in RFC
   1894[8].  The 'mta-name-type' from RFC1894[8] 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 use have the value of
   'msrp-name-type', as defined in Section 15.4 of this specification.
   The 'mta-name' value for this field same o-line as specified in RFC1894 [8] MUST
   equal the previous
   exchange.

7.1.4  Example SDP Exchange

   Endpoint A wishes to invite Endpoint B to a MSRP URL representing itself in session.  A offers
   the context 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 session.

8.5  final-recipient direction for any required TCP connection.  The 'final-recipient-field' MUST follow mechanism was
   loosely based on the guidelines set out COMEDIA [24] work being done 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. MMUSIC
   working group.  The 'address-type' value for this field as specified primary motivation was to allow MSRP sessions to
   succeed in RFC1894 [8] MUST equal situations where the offerer could not accept connections
   but the final value contained in answerer could.  For example, the MSRP
   'To-Path' header from offerer might be behind a
   NAT, while the original request.

8.6  action answerer might have a globally routable address.

   The 'action' field MUST follow the guidelines set out in RFC 1894[8].
   An SIMPLE working group chose to remove that mechanism from MSRP, as
   it added a great deal of complexity to connection management.
   Instead, MSRP entity constructing now specifies a DSN report MUST use default connection direction.

7.2  MSRP User Experience with SIP

   In typical SIP applications, when an endpoint receives an INVITE
   request, it alerts the 'delivered'
   value for a successful delivery user, and MUST use the 'failed' value for
   an unsuccessful delivery.  The other values specified waits for user input before
   responding.  This is analogous to the
   'action' field in RFC 1894[8] MAY be used.

8.7  status

   The 'status' field MUST follow typical telephone user
   experience, where the guidelines set out in RFC 1894[8].
   An MSRP entity constructing a DSN report MUST represent callee "answers" the MSRP
   status code in call.

   In contrast, the correct format detailed in RFC 1894[8] typical user experience for instant messaging
   applications is that the
   'status' field of a DSN report.  An MSRP status code consists of a
   three digit number while a DSN status initial received message is three digits separated by
   '.'.  An example would be:

   Status: 5.0.0 (unknown permanent failure)

   When generating this field immediately
   displayed to the first digit of user, without waiting for the MSRP status code
   (working from left user to right) MUST be placed in the first part of "join" the
   'status' DSN field.  The second digit MUST be placed in
   conversation.  Therefore, the second
   part principle of least surprise would
   suggest that MSRP endpoints using SIP signaling SHOULD allow a mode
   where the 'status' DSN field.  The third digit MUST endpoint quietly accepts the session, and begins displaying
   messages.

   SIP INVITE requests may be placed forked by a SIP proxy, resulting in more
   than one endpoint receiving the third part of the 'status' DSN field.  An example of a DSN
   'status' field value would be:

   An MSRP '200' success response would same INVITE.  SIP early media [28]
   techniques can be mapped to:

   Status: 2.0.0 (OK)

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

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

   MSRP is a text protocol that uses the UTF-8 [15] transformation
   format.

   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 %x4D.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 =
   dUmMy= "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 / "-" 1*(%x21 / "." %xx23-27 / "!" %x2A-2B / "%" %x2D-2E
              / "*" %x30-39 / "_" %x41-5A / "+" %x5E-7E)

   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
   CRLF   = %x0D.0A
   HT     = %x09
   SP     = %x20
   UPALPHA  = %x41-5A
   LOWALPHA = %x61-7A
   DIGIT    = %x30-39
   ALPHANUM = LOWALPHA / UPALPHA / DIGIT

   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.

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

9.1  200

   The 200 response code indicates a successful transaction.

10.2

9.2  400

   A 400 response indicates a request was unintelligible.

10.3

9.3  403

   The action is not allowed

10.4

9.4  415

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

10.5

9.5  426

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

10.6

9.6  481

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

10.7

9.7  506

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

11.

10.  Examples

11.1

10.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@example.com.

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

   3.  Alice->Bob (SIP): ACK

   5.

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

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

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

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

   8.  Alice->Bob (SIP): BYE

       Alice invalidates local session state.

   10.

   9.  Bob invalidates local state for the session.

       Bob->Alice (SIP): 200 OK

11.2

10.2  Chunked Message

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

11.3

10.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
   This conference will end in 5 minutes
   -------d93kswow$

11.4

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

10.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 772 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 MSRP 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--->|            |            |           |           |
      |            |--INVITE--->|            |           |           |
      |            |<----180----|            |           |           |
      |<----180----|            |            |           |           |
      |---PRACK---------------->|            |           |           |
      |<----200-----------------|            |           |           |
      |<===Early MSRP Session==>| art thou hither?       |           |
      |            |            |            |           |           |
      |            |--INVITE---------------->|           |           |
      |            |<----180-----------------|           |           |
      |<----180----|            |            |           |           |
      |---PRACK----------------------------->|           |           |
      |<----200------------------------------|           |           |
      |<========Early MSRP 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.

11.  Extensibility

   MSRP was designed to be only minimally extensible.  New MSRP Methods,
   Headers, and status codes can be defined in standards track RFCs.
   There is no registry of headers, methods, or status codes, since the
   number of new elements and total extensions is expected to be very
   small.  MSRP does not contain a version number or any negotiation
   mechanism to require or discover new features.  If a
   non-interoperable update or extension occurs in the future, it will
   be treated as a new protocol, and must describe how its use will be
   signaled.

   In order to allow extension header fields without breaking
   interoperablility, if an MSRP device receives a request or response
   containing a header field that it does not understand, it MUST ignore
   the header field and process the request or response as if the header
   field was not present.

   MSRP was designed to use lists of URLs instead of a single URL in the
   To-Path and 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.

12.  CPIM compatibility

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

14.

   If a message is to be wrapped in a message/cpim envelope, the
   wrapping MUST be done prior to breaking the message into chuncks, if
   needed.

13.  Security Considerations

   Instant Messaging systems are used to exchange a variety of 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 communicating important information.  Like many
   communications systems, the properties of Integrity and
   Confidentiality of the exchanged information, along with the
   possibility of Anonymous communications, and knowing you are
   communicating with the correct other party are required.  MSRP pushes
   many of the 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 needs to provide confidentiality and integrity for the messages
   it transfers.  It also needs to provide assurances the connected host
   is the host that it meant to connect to and that the connection has
   not been hijacked.

   When using only TCP connections, MSRP security is fairly weak.  If
   host A is contacting B, B passes its hostname and a secret to A using
   SIP.  If the SIP offer or answer is not TLS or S/MIME [27] protected,
   anyone can see this secret.  A then connects to the provided host
   name and passes the secret in the clear across the connection 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
   connections.  B assumes it is talking to A because the host on the
   other end of the connection delivered the secret.  An attacker that
   could ACK the SYN packet could insert itself as a man in the middle
   in the connection.

   When using TLS connections, the security is significantly improved.
   We assume that the host accepting the connection has a certificate
   from a well know certificate authority.  Furthermore, we assume that
   the SIP signaling to set up the session is protected with TLS (using
   sips).  In this case, when host A contacts host B, the secret is
   passed through a SIP confidential channel to A.  A connects with TLS
   to B.  B presents a valid certificate, so A knows it really is
   connected to B.  A then delivers the secret provided by B, so that B
   can verify it is connected to A.  In this case, a rogue SIP Proxy can
   see the secret in the SIP signaling traffic and could potentially
   insert itself as a man-in-the-middle.

   Realistically, using TLS is only feasible when connecting to gateways
   or relays , as the types of hosts that end clients use for sending
   instant messages are unlikely to have a 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 actual endpoint to have
   certificates from a well known certificate authority.  The Identity
   [22] and Certificates [23] mechanism with SIP provides S/MIME based
   delivery of a secret between A and B.  No SIP intermediary except the
   explicitly trusted authentication service (one per user) can see the
   secret.  The S/MIME encryption of the SDP can also be used by SIP to
   exchange keying material that can be used in MRSP.  The MSRP session
   can then use S/MIME with this keying material to encrypt and sign
   messages sent over MSRP.  The connection can still be hijacked since
   the secret is sent in clear text to the other end of the TCP
   connection, but this risk is mitigated if all the MSRP content is
   encrypted and signed with S/MIME.

   MSRP can not be used as an amplifier for DoS attacks, but it can be
   used to form a 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 an offer and Eve returns an answer
   with the SDP that indicates that her MSRP address is the address of
   Tom.  Since Alice sent the offer, Alice will initiate a connection to
   Tom using up resources on Tom's server.  Given the huge number of IM
   clients, and the relatively few TCP connections that most servers
   support, this is a fairly straightforward attack.

   SIP is attempting to address issues in dealing with spam.  The spam
   issue is probably best dealt with at the SIP level when an MSRP
   session is initiated and not at the MSRP level.

   TLS is used to authenticate devices and to provide integrity and
   confidentiality for the headers being transported.  MSRP elements
   MUST implement TLS and MUST also implement the TLS
   ClientExtendedHello extended hello information for server name
   indication as described in [12]. [11].  A TLS cipher-suite of
   TLS_RSA_WITH_AES_128_CBC_SHA [15] [14] 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 multipart/signed MIME type even if they do not support S/
   MIME.  Since SIP can carry a session key, S/MIME messages in the
   context of a session could also be protected using a key-wrapped
   shared secret [26] provided in the session setup.

15.

   If a sender chooses to employ S/MIME to protect a message, all S/MIME
   operations MUST occur prior to breaking the message into chunks, if
   needed.

14.  IANA Considerations

15.1

14.1  MSRP Port

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

15.2

14.2  MSRP URL Schemes

   This document defines the URL schemes of "msrp" and "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. 13.
   Relevant Publications RFCXXXX
         [Note to RFC Editor: Please replace RFCXXXX in the above
         paragraph with the actual number assigned to this document.

15.3

14.3  SDP Parameters

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

15.3.1

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

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

14.3.3  Max Size

   Attribute-name:  max-size
   Long-form Attribute Name Maximum message size.
   Type: Media level
   Subject to Charset Attribute No
   Purpose and Appropriate Values See Section 7.1.

14.3.4  Path

   Attribute-name:  path
   Long-form Attribute Name MSRP URL Path
   Type: Media level
   Subject to Charset Attribute No
   Purpose and Appropriate Values See Section 7.1.1.

15.4  IANA registration forms for

15.  Change History

15.1  draft-ietf-simple-message-sessions-08

      Removed DSN types

15.4.1  IANA registration form for address-type

   This document registers section.  Removed statements that an error report
      SHOULD contain a new 'address-type' body.  REPORT requests may now contain
      informational bodies no larger than 2K, but the recipient is free
      to ignore them.
      Added the "#" value for use in conjunction
   with RFC1894[8].  The authors request the continuation-flag to indicate the last
      chunk of an abandoned message.
      Added direction that these values s/mime and cpim envelops must be recorded
   in applied
      before chunking.
      Added direction to set the 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 last-byte field in byte-range to "*" if
      there is any chance of interrupting a new 'MTA-name-type' SEND request.
      Changed max-size to refer to entire message, instead of a
      particular MIME content-type
      Added requirent for use in conjunction
   with RFC1894[8].  The authors request that these values be recorded
   in the IANA registry for DSN 'MTA-name-type'.

   Proposed Address name: msrp-name-type

   Syntax: See Section 5

16.  Change History

16.1 use of UTF-8, and reference to RFC3629
      Added requrement to ignore unknown headers.
      Several ABNF fixes
      Removed redundant material between normative sections.
      Numerous editorial fixes.

15.2  draft-ietf-simple-message-sessions-07

      Significant re-write to attempt to improve readability.
      Added maximum size parameter in accept-types
      Changed the Boundary field to be part of the start-line rather
      than a header field.
      Removed the TR-IDheader, and changed request-response matching to
      be based on the Boundary field value.  Responses still contain the
      TR-ID header, which must match the Boundary from the request.

      Removed transport selection from URL scheme and added the "tcp"
      parameter.
      Added description of the "simple" mode with no transaction
      responses, and made mode selection dependent on the reporting
      level requested for a give message.
      Changed the DSN section to reflect separate request of success and
      failure reports.  Enhanced REPORT method to be useful even without
      a payload.
      removed SRV usage for URL resolution.  This is only used for relay
      discovery, and therefore should be moved to the relay draft.
      Added discussion about late REPORT handling.  Asserted that REPORT
      requests are always sent in simple mode.
      Removed the dependency on multipart/byteranges for fragmentation.
      Incorporated the Byte-Range header into the base MSRP header set.
      Removed the VISIT method.  Change to use SEND to serve the purpose
      formerly reserved to VISIT.

16.2

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

16.3

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

16.4

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

16.5

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

16.6

15.7  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 algorithm.
      Required support for the message/cpim format.
      Fixed lots of editorial issues.
      Documented a number of open issues from recent list discussions.

16.7

15.8  draft-ietf-simple-message-sessions-01

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

16.8

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

16.9

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

17.

16.  Contributors and Acknowledgments

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

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

18.

17.  References

18.1

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

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

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

   [9]   Troost, R., Dorner, S. and K. Moore, "Communicating
         Presentation Information in Internet Messages: The
         Content-Disposition Header Field", RFC 2183, August 1997.

   [11]

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

   [12]

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

   [13]

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

   [14]

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

   [15]

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

18.2

   [15]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
         3269, November 2003.

17.2  Informational References

   [16]  Johnston, A. and O. Levin, "Session Initiation Protocol Call
         Control - Conferencing for User Agents",
         draft-ietf-sipping-cc-conferencing-03 (work in progress),
         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-06 (work
         in progress), January 2004.

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

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

   [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. and C. Jennings, "Enhancements for Authenticated
         Identity Management in the Session Initiation  Protocol (SIP)",
         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.

   [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 and Ringing Tone
         Generation in the Session Initiation Protocol (SIP)",
         draft-ietf-sipping-early-media-02 (work in progress), 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 (editor)
   Estacado Systems

   EMail: ben@nostrum.com

   Rohan Mahy (editor)
   Cisco Systems, Inc.
   5617 Scotts Valley Drive, Suite 200
   Scotts Valley, CA  95066
   USA

   EMail: rohan@cisco.com

   Cullen Jennings (editor)
   Cisco Systems, Inc.
   170 West Tasman Dr.
   MS: SJC-21/2
   San Jose, CA  95134
   USA

   EMail: fluffy@cisco.com

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made 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 implementers or users of this
   specification can be obtained from the IETF 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 that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein 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 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.