Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 4975


The Message Session Relay Protocol (MSRP)

Part 2 of 4, p. 17 to 36
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 17 
7.  Method-Specific Behavior

7.1.  Constructing Requests

   To form a new request, the sender creates a transaction identifier
   and uses this and the method name to create an MSRP request start
   line.  The transaction identifier MUST NOT collide with that of other
   transactions that exist at the same time.  Therefore, it MUST contain
   at least 64 bits of randomness.

   Next, the sender places the target path in a To-Path header field,
   and the sender's URI in a From-Path header field.  If multiple URIs
   are present in the To-Path, the leftmost is the first URI visited;
   the rightmost URI is the last URI visited.  The processing then
   becomes method specific.  Additional method-specific header fields
   are added as described in the following sections.

   After any method-specific header fields are added, processing
   continues to handle a body, if present.  If the request has a body,
   it MUST contain a Content-Type header field.  It may contain other
   MIME-specific header fields.  The Content-Type header field MUST be
   the last field in the message header section.  The body MUST be
   separated from the header fields with an extra CRLF.

   Non-SEND requests are not intended to carry message content, and are
   therefore not interruptible.  Non-SEND request bodies MUST NOT be
   larger than 10240 octets.

      Although this document does not discuss any particular usage of
      bodies in non-SEND requests, they may be useful in the future for
      carrying security or identity information, information about a
      message in progress, etc.  The 10K size limit was chosen to be
      large enough for most of such applications, but small enough to
      avoid the fairness issues caused by sending arbitrarily large
      content in non-interruptible method bodies.

   A request with no body MUST NOT include a Content-Type or any other
   MIME-specific header fields.  A request without a body MUST contain
   an end-line after the final header field.  No extra CRLF will be
   present between the header section and the end-line.

      Requests with no bodies are useful when a client wishes to send
      "traffic", but does not wish to send content to be rendered to the
      peer user.  For example, the active endpoint sends a SEND request
      immediately upon establishing a connection.  If it has nothing to
      say at the moment, it can send a request with no body.  Bodiless
      requests may also be used in certain applications to keep Network
      Address Translation (NAT) bindings alive, etc.

Top      Up      ToC       Page 18 
      Bodiless requests are distinct from requests with empty bodies.  A
      request with an empty body will have a Content-Type header field
      value and will generally be rendered to the recipient according to
      the rules for that type.

   The end-line that terminates the request MUST be composed of seven
   "-" (minus sign) characters, the transaction ID as used in the start
   line, and a flag character.  If a body is present, the end-line MUST
   be preceded by a CRLF that is not part of the body.  If the chunk
   represents the data that forms the end of the complete message, the
   flag value MUST be a "$".  If the sender is aborting an incomplete
   message, and intends to send no further chunks in that message, the
   flag MUST be a "#".  Otherwise, the flag MUST be a "+".

   If the request contains a body, the sender MUST ensure that the end-
   line (seven hyphens, the transaction identifier, and a continuation
   flag) is not present in the body.  If the end-line is present in the
   body, the sender MUST choose a new transaction identifier that is not
   present in the body, and add a CRLF if needed, and the end-line,
   including the "$", "#", or "+" character.

   Some implementations may choose to scan for the closing sequence as
   they send the body, and if it is encountered, simply interrupt the
   chunk at that point and start a new transaction with a different
   transaction identifier to carry the rest of the body.  Other
   implementations may choose to scan the data and ensure that the body
   does not contain the transaction identifier before they start sending
   the transaction.

   Once a request is ready for delivery, the sender follows the
   connection management (Section 5.4) rules to forward the request over
   an existing open connection or create a new connection.

7.1.1.  Sending SEND Requests

   When an endpoint has a message to deliver, it first generates a new
   Message-ID.  The value MUST be highly unlikely to be repeated by
   another endpoint instance, or by the same instance in the future.  If
   necessary, the endpoint breaks the message into chunks.  It then
   generates a SEND request for each chunk, following the procedures for
   constructing requests (Section 7.1).

      The Message-ID header field provides a unique message identifier
      that refers to a particular version of a particular message.  The
      term "Message" in this context refers to a unit of content that
      the sender wishes to convey to the recipient.  While such a
      message may be broken into chunks, the Message-ID refers to the
      entire message, not a chunk of the message.

Top      Up      ToC       Page 19 
      The uniqueness of the message identifier is ensured by the host
      that generates it.  This message identifier is intended to be
      machine readable and not necessarily meaningful to humans.  A
      message identifier pertains to exactly one version of a particular
      message; subsequent revisions to the message each receive new
      message identifiers.  Endpoints can ensure sufficient uniqueness
      in any number of ways, the selection of which is an implementation
      choice.  For example, an endpoint could concatenate an instance
      identifier such as a MAC address, its idea of the number of
      seconds since the epoch, a process ID, and a monotonically
      increasing 16-bit integer, all base-64 encoded.  Alternately, an
      endpoint without an on-board clock could simply use a 64-bit
      random number.

   Each chunk of a message MUST contain a Message-ID header field
   containing the Message-ID.  If the sender wishes non-default status
   reporting, it MUST insert a Failure-Report and/or Success-Report
   header field with an appropriate value.  All chunks of the same
   message MUST use the same Failure-Report and Success-Report values in
   their SEND requests.

   If success reports are requested, i.e., the value of the Success-
   Report header field is "yes", the sending device MAY wish to run a
   timer of some value that makes sense for its 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 for some trading systems it may be under a second.
   Regardless of whether such a timer is used, if the success report has
   not been received by the time the session is ended, the device SHOULD
   inform the user.

   If the value of "Failure-Report" is set to "yes", then the sender of
   the request runs a timer.  If a 200 response to the transaction is
   not received within 30 seconds from the time the last byte of the
   transaction is sent, or submitted to the operating system for
   sending, the element MUST inform the user that the request probably
   failed.  If the value is set to "partial", then the element sending
   the transaction does not have to run a timer, but MUST inform the
   user if it receives a non-recoverable error response to the
   transaction.  Regardless of the Failure-Report value, there is no
   requirement to wait for a response prior to sending the next request.

      The treatment of timers for success reports and failure reports is
      intentionally inconsistent.  An explicit timeout value makes sense
      for failure reports since such reports will usually refer to a
      message "chunk" that is acknowledged on a hop-by-hop basis.  This

Top      Up      ToC       Page 20 
      is not the case for success reports, which are end-to-end and may
      refer to the entire message content, which can be arbitrarily

   If no Success-Report header field is present in a SEND request, it
   MUST be treated the same as a Success-Report header field with a
   value of "no".  If no Failure-Report header field is present, it MUST
   be treated the same as a Failure-Report header field with a value of
   "yes".  If an MSRP endpoint receives a REPORT for a Message-ID it
   does not recognize, it SHOULD silently ignore the REPORT.

   The Byte-Range header field value contains a starting value (range-
   start) followed by a "-", an ending value (range-end) followed by a
   "/", and finally the total length.  The first octet in the message
   has a position of one, rather than a zero.

   The first chunk of the message SHOULD, and all subsequent chunks
   MUST, include a Byte-Range header field.  The range-start field MUST
   indicate the position of the first byte in the body in the overall
   message (for the first chunk this field will have a value of one).
   The range-end field SHOULD indicate the position 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 field MAY contain a "*" if the total size of the message is not
   known in advance.  The sender MUST send all chunks in Byte-Range
   order.  (However, the receiver cannot assume that the requests will
   be delivered in order, as intervening relays may have changed the

   There are some circumstances where an endpoint may choose to send an
   empty SEND request.  For the sake of consistency, a Byte-Range header
   field referring to nonexistent or zero-length content MUST still have
   a range-start value of 1.  For example, "1-0/0".

   To ensure fairness over a connection, senders MUST NOT send chunks
   with a body larger than 2048 octets unless they are prepared to
   interrupt them (meaning that any chunk with a body of greater than
   2048 octets will have a "*" character in the range-end field).  A
   sender can use one of the following two strategies to satisfy this
   requirement.  The sender is STRONGLY RECOMMENDED to send messages
   larger than 2048 octets using as few chunks as possible, interrupting
   chunks (at least 2048 octets long) only when other traffic is waiting
   to use the same connection.  Alternatively, the sender MAY simply
   send chunks in 2048-octet increments until the final chunk.  Note
   that the former strategy results in markedly more efficient use of
   the connection.  All MSRP nodes MUST be able to receive chunks of any
   size from zero octets to the maximum number of octets they can

Top      Up      ToC       Page 21 
   receive for a complete message.  Senders SHOULD NOT break messages
   into chunks smaller than 2048 octets, except for the final chunk of a
   complete message.

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

   SEND requests larger than 2048 octets MUST be interrupted if the
   sender needs to send pending responses or REPORT requests.  If
   multiple SEND requests from different sessions are concurrently being
   sent over the same 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 with which it was sent.  An
   intervening relay could possibly break SEND requests into smaller
   chunks, or aggregate multiple chunks into larger ones.

   The default disposition of messages is to be rendered to the user.
   If the sender wants a different disposition, it MAY insert a Content-
   Disposition [9] header field.  Values MAY include any from RFC 2183
   [9] or the IANA registry it defines.  Since MSRP can carry unencoded
   binary payloads, transfer encoding is always "binary", and transfer-
   encoding parameters MUST NOT be present.

7.1.2.  Sending REPORT Requests

   REPORT requests are similar to SEND requests, except that report
   requests MUST NOT include Success-Report or Failure-Report header
   fields, and MUST contain a Status header field.  REPORT requests MUST
   contain the Message-ID header field 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 will normally not include a body, as the REPORT
   request header fields can carry sufficient information in most cases.
   However, REPORT requests MAY include a body containing additional
   information about the status of the associated SEND request.  Such a

Top      Up      ToC       Page 22 
   body is informational only, and the sender of the REPORT request
   SHOULD NOT assume that the recipient pays any attention to the body.
   REPORT requests are not interruptible.

   Success-Report and Failure-Report header fields MUST NOT be present
   in REPORT requests.  MSRP nodes MUST NOT send REPORT requests in
   response to REPORT requests.  MSRP nodes MUST NOT send MSRP responses
   to REPORT requests.

   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 for a session that is no longer valid.

7.1.3.  Generating Success Reports

   When an endpoint receives a message in one or more chunks that
   contain a Success-Report value of "yes", it MUST send a success
   report or reports covering all bytes that are received successfully.
   The success reports are sent in the form of REPORT requests,
   following the normal procedures (Section 7.1), with a few additional

   The receiver MAY wait until it receives the last chunk of a message,
   and send a success report that covers the complete message.
   Alternately, it MAY generate incremental success REPORTs as the
   chunks are received.  These can be sent periodically and cover all
   the bytes that have been received so far, or they can be sent after a
   chunk arrives and cover just the part from that chunk.

      It is helpful to think of a success REPORT as reporting on a
      particular range of bytes, rather than on a particular chunk sent
      by a client.  The sending client cannot depend on the Byte-Range
      header field in a given success report matching that of a
      particular SEND request.  For example, an intervening MSRP relay
      may break chunks into smaller chunks, or aggregate multiple chunks
      into larger ones.  A side effect of this is, even if no relay is
      used, the receiving client may report on byte ranges that do not
      exactly match those in the original chunks sent by the sender.  It
      can wait until all bytes in a message are received and report on
      the whole, it can report as it receives each chunk, or it can
      report on any other received range.  Reporting on ranges smaller
      than the entire message contents allows certain improved user
      experiences for the sender.  For example, a sending client could
      display incremental status information showing which ranges of
      bytes have been acknowledged by the receiver.  However, the choice
      on whether to report incrementally is entirely up to the receiving
      client.  There is no mechanism for the sender to assert its desire
      to receive incremental reports or not.  Since the presence of a

Top      Up      ToC       Page 23 
      relay can cause the receiver to see a very different chunk
      allocation than the sender, such a mechanism would be of
      questionable value.

   When generating a REPORT request, the endpoint inserts a To-Path
   header field containing the From-Path value from the original
   request, and a From-Path header field containing the URI identifying
   itself in the session.  The endpoint then inserts a Status header
   field with a namespace of "000", a status-code of "200", and an
   implementation-defined comment phrase.  It also inserts a Message-ID
   header field containing the value from the original request.

      The namespace field denotes the context of the status-code field.
      The namespace value of "000" means the status-code should be
      interpreted in the same way as the matching MSRP transaction
      response code.  If a future specification uses the status-code
      field for some other purpose, it MUST define a new namespace field

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

7.1.4.  Generating Failure Reports

   If an MSRP endpoint receives a SEND request that it cannot process
   for some reason, and the Failure-Report header field either was not
   present in the original request or had a value of "yes", it SHOULD
   simply include the appropriate error code in the transaction
   response.  However, there may be situations where the error cannot be
   determined quickly, such as when the endpoint is a gateway that waits
   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 Failure-Report header
   field value of "no", then it MUST NOT send a failure REPORT request,
   and MUST NOT send a transaction response.  If the value is "partial",
   it MUST NOT send a 200 transaction response to the request, but
   SHOULD send an appropriate non-200 class response if a failure

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

Top      Up      ToC       Page 24 
   Construction of failure REPORT requests is identical to that for
   success REPORT requests, except the Status header field code field
   MUST contain the appropriate error code.  Any error response code
   defined in this specification MAY also be used in failure reports.

   If a failure REPORT request is sent in response to a SEND request
   that contained a chunk, it MUST include a Byte-Range header field
   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.

      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 [23].  We
      expect failure reports to be more commonly generated by relays
      than by endpoints.

7.2.  Constructing Responses

   If an MSRP endpoint receives a request that either contains a
   Failure-Report header field value of "yes" or does not contain a
   Failure-Report header field at all, it MUST immediately generate a
   response.  Likewise, if an MSRP endpoint receives a request that
   contains a Failure-Report header field 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 the appropriate response code and optionally a
   comment.  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 first (leftmost) URI in the
   From-Path header field of the request. (Responses to SEND requests
   are returned only to the previous hop.) For responses to all other
   request methods, the To-Path header field contains the full path back
   to the original sender.  This full path is generated by copying the
   list of URIs from the From-Path of the original request 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
   URI that identifies it in the context of the session, followed by the
   end-line after the last header field.  Since a response is never

Top      Up      ToC       Page 25 
   chunked, the continuation flag in the end-line will always contain a
   dollar sign ("$").  The response MUST be transmitted back on the same
   connection on which the original request arrived.

7.3.  Receiving Requests

   The receiving endpoint MUST first check the URI 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 URI, which
   MUST map to an existing session that is associated with the
   connection on which the request arrived.  If this is not true, then
   the receiver MUST generate a 481 error and ignore the request.  Note
   that if the Failure-Report header field had a value of "no", then no
   error report would be sent.

   Further request processing by the receiver is method specific.

7.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 field, 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.  The
   receiver 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 SHOULD 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 noting that the chunk that has a termination character of
   "$" defines the total length of the message.

      It is technically illegal for the sender to prematurely interrupt
      a request that had anything other than "*" in the last-byte
      position of the Byte-Range header field.  But having the receiver
      calculate a chunk length based on actual content adds resilience
      in the face of sender errors.  Since this should never happen with
      compliant senders, this only has a "SHOULD" strength.

   Receivers MUST not assume that the chunks will be delivered in order
   or that they will receive all the chunks with "+" flags before they
   receive the chunk with the "$" flag.  In certain cases of connection
   failure, it is possible for information to be duplicated.  If chunk
   data is received that overlaps already received data for the same

Top      Up      ToC       Page 26 
   message, the last chunk received SHOULD take precedence (even though
   this may not have been the last chunk transmitted).  For example, if
   bytes 1 to 100 were 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.

      There are situations in which the receiver may not be able to give
      precedence to the last chunk received when chunks overlap.  For
      example, the recipient might incrementally render chunks as they
      arrive.  If a new chunk arrives that overlaps with a previously
      rendered chunk, it would be too late to "take back" any
      conflicting data from the first chunk.  Therefore, the requirement
      to give precedence to the most recent chunk is specified at a
      "SHOULD" strength.  This requirement is not intended to disallow
      applications where this behavior does not make sense.

   The seven "-" in the end-line are used so that the receiver can
   search for the value "----", 32 bits at a time to find the probable
   location of the end-line.  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 header
   fields of the request, but also allows for the interruption of

   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 media-type, and the Failure-Report value is not "no",
   the receiver MUST generate a response with a status code of 415.  All
   MSRP endpoints MUST be able to receive the multipart/mixed [15] and
   multipart/alternative [15] media-types.

   If the Success-Report header field was set to "yes", the receiver
   must construct and send one or more success reports, as described in
   Section 7.1.3.

Top      Up      ToC       Page 27 
7.3.2.  Receiving REPORT Requests

   When an endpoint receives a REPORT request, it correlates the report
   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
   field with a namespace field of "000" MUST interpret the report in
   exactly the same way it would interpret an MSRP transaction response
   with a response code matching the status-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, by including the "#" character in the continuation field of
   the end-line.

   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

   When an endpoint that sent a SEND request receives a failure REPORT
   indicating that a particular byte range was not received, it MUST
   treat the session as failed.  If it wishes to recover, it MUST first
   re-negotiate the URIs at the signaling level then resend that range
   of bytes of the message on the resulting new session.

   MSRP nodes MUST NOT send MSRP REPORT requests in response to other
   REPORT requests.

8.  Using MSRP with SIP and SDP

   MSRP sessions will typically be initiated using the Session
   Description Protocol (SDP) [2] via the SIP offer/answer mechanism

   This document defines a handful of new SDP parameters to set up MSRP
   sessions.  These are detailed below and in the IANA Considerations

   An MSRP media-line (that is, a media-line proposing MSRP) in the
   session description is accompanied by a mandatory "path" attribute.
   This attribute contains a space-separated list of URIs to be visited

Top      Up      ToC       Page 28 
   to contact the user agent advertising this session description.  If
   more than one URI is present, the leftmost URI is the first URI to be
   visited to reach the target resource.  (The path list can contain
   multiple URIs to allow for the deployment of gateways or relays in
   the future.)  MSRP implementations that can accept incoming
   connections without the need for relays will typically only provide a
   single URI here.

   An MSRP media line is also accompanied by an "accept-types"
   attribute, and optionally an "accept-wrapped-types" attribute.  These
   attributes are used to specify the media-types that are acceptable to
   the endpoint.

8.1.  SDP Connection and Media-Lines

   An SDP connection-line takes the following format:

   c=<network type> <address type> <connection address>

                  Figure 4: Standard SDP Connection Line

   The network type and address type fields are used as normal for SDP.
   The connection address field MUST be set to the IP address or fully
   qualified domain name from the MSRP URI identifying the endpoint in
   its path attribute.

   The general format of an SDP media-line is:

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

                     Figure 5: Standard SDP Media Line

   An offered or accepted media-line for MSRP over TCP MUST include a
   protocol field value of "TCP/MSRP", or "TCP/TLS/MSRP" for TLS.  The
   media field value MUST be "message".  The format list field MUST be
   set to "*".

   The port field value MUST match the port value used in the endpoint's
   MSRP URI in the path attribute, except that, as described in [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) in the
   response.  Since MSRP allows multiple sessions to share the same TCP
   connection, multiple m-lines in a single SDP document may share the
   same port field value; MSRP devices MUST NOT assume any particular
   relationship between m-lines on the sole basis that they have
   matching port field values.

Top      Up      ToC       Page 29 
      MSRP devices do not use the c-line address field, or the m-line
      port and format list fields to determine where to connect.
      Rather, they use the attributes defined in this specification.
      The connection information is copied to the c-line and m-line for
      purposes of backwards compatibility with conventional SDP usages.
      While MSRP could theoretically carry any media-type, "message" is

8.2.  URI Negotiations

   Each endpoint in an MSRP session is identified by a URI.  These URIs
   are negotiated in the SDP exchange.  Each SDP offer or answer that
   proposes MSRP MUST contain a "path" attribute containing one or more
   MSRP URIs.  The path attribute is used in an SDP a-line, and has the
   following syntax:

        path = path-label ":" path-list
        path-label = "path"
        path-list= MSRP-URI *(SP MSRP-URI)

                            Figure 6: Path Attribute

   where MSRP-URI is an "msrp" or "msrps" URI as defined in Section 6.
   MSRP URIs included in an SDP offer or answer MUST include explicit
   port numbers.

   An MSRP device uses the URI to 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 URI to represent itself and
   sends that URI to its peer in the SDP document.  Each peer stores the
   path value received from the other peer and uses that value as the
   target for requests inside the resulting session.  If the path
   attribute received from the peer contains more than one URI, then the
   target URI is the rightmost, while the leftmost entry represents the
   adjacent hop.  If only one entry is present, then it is both the peer
   and adjacent hop URI.  The target path is the entire path attribute
   value received from the peer.

   The following example shows an SDP offer with a session URI of

Top      Up      ToC       Page 30 
    o=alice 2890844526 2890844527 IN IP4
    s= -
    c=IN IP4
    t=0 0
    m=message 7394 TCP/MSRP *

                 Figure 7: Example SDP with Path Attribute

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

8.3.  Path Attributes with Multiple URIs

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

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

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

   Even though endpoints that implement only this specification will
   never introduce a relay, they need to be able to interoperate with
   other endpoints that do use relays.  Therefore, they MUST be prepared
   to receive more than one URI in the SDP path attribute.  When an
   endpoint receives more than one URI in a path attribute, only the

Top      Up      ToC       Page 31 
   first entry is relevant for purposes of resolving the address and
   port, and establishing the network connection, as it describes the
   first adjacent hop.

   If an endpoint puts more than one URI in a path attribute, the final
   URI in the path attribute (the peer URI) identifies the session, and
   MUST not duplicate the URI of any other session in which the endpoint
   is currently participating.  Uniqueness requirements for other
   entries in the path attribute are out of scope for this document.

8.4.  Updated SDP Offers

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

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

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

8.5.  Connection Negotiation

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

   The SIMPLE working group chose to remove that mechanism from MSRP, as
   it added a great deal of complexity to connection management.
   Instead, MSRP now specifies a default connection direction.  The
   party that sent the original offer is responsible for connecting to
   its peer.

Top      Up      ToC       Page 32 
8.6.  Content Type Negotiation

   An SDP media-line proposing MSRP MUST be accompanied by an accept-
   types attribute.

   An entry of "*" 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.

   This specification requires the support of certain data formats.
   Mandatory formats MUST be signaled like any other, either explicitly
   or by the use of a "*".

   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 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 media-type that
   can only be used if wrapped inside a listed container type.

   Endpoints MAY specify media-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 container types listed in the
   accept-types attribute.  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 both used 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 media-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

Top      Up      ToC       Page 33 
      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
      Common Presence and Instant Messaging (CPIM) [12] 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

   If the recipient of an offer does not understand any of the payload
   types indicated in the offered SDP, it SHOULD indicate that using the
   appropriate mechanism of the rendezvous protocol.  For example, in
   SIP, it SHOULD return a SIP 488 response.

   An MSRP endpoint MUST NOT send content of a type not signaled by the
   peer in either an accept-types or an accept-wrapped-types attribute.
   Furthermore, it MUST NOT send a top-level (i.e., not wrapped) MIME
   document of a type not signaled in the accept-types attribute.  In
   either case, the signaling could be explicit, or implicit through the
   use of the "*" character.

   An endpoint MAY indicate the maximum size message it wishes to
   receive using the max-size a-line attribute.  Max-size refers to the
   complete message in octets, not the size of any one chunk.  Senders
   SHOULD NOT exceed the max-size limit for any message sent in the
   resulting session.  However, the receiver should consider max-size
   value as a hint.

   Media format entries may include parameters.  The interpretation of
   such parameters varies between media-types.  For the purposes of
   media-type negotiation, a format-entry with one or more parameters is
   assumed to match the same format-entry with no parameters.

Top      Up      ToC       Page 34 
   The formal syntax for these attributes is as follows:

        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-param ) )
                        / ("*")

        type = token
        subtype = token
        type-param = parm-attribute "=" parm-value
        parm-attribute = token
        parm-value = token / quoted-string

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

                           Figure 8: Attribute Syntax

8.7.  Example SDP Exchange

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

    o=usera 2890844526 2890844527 IN IP4
    s= -
    c=IN IP4
    t=0 0
    m=message 7394 TCP/MSRP *
    a=accept-types:message/cpim text/plain text/html

                       Figure 9: SDP from Endpoint A

Top      Up      ToC       Page 35 
   B responds with its own URI:

    o=userb 2890844530 2890844532 IN IP4
    s= -
    c=IN IP4
    t=0 0
    m=message 8493 TCP/MSRP *
    a=accept-types:message/cpim text/plain

                       Figure 10: SDP from Endpoint B

8.8.  MSRP User Experience with SIP

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

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

      This guideline may not make sense for all situations, such as for
      mixed-media applications, where both MSRP and audio sessions are
      offered in the same INVITE.  In general, good application design
      should take precedence.

   SIP INVITE requests may be forked by a SIP proxy, resulting in more
   than one endpoint receiving the same INVITE.  SIP early media [29]
   techniques can be used to establish a preliminary session with each
   endpoint so the initial message(s) are displayed on each endpoint,
   and canceling the INVITE transaction for any endpoints that do not
   send MSRP traffic after some period of time, so that they cease
   receiving MSRP traffic from the inviter.

8.9.  SDP Direction Attribute and MSRP

   SDP defines a number of attributes that modify the direction of media
   flows.  These are the "sendonly", "recvonly", "inactive", and
   "sendrecv" attributes.

Top      Up      ToC       Page 36 
   If a "sendonly" or "recvonly" attribute modifies an MSRP media
   description line, the attribute indicates the direction of MSRP SEND
   requests that contain regular message payloads.  Unless otherwise
   specified, these attributes do not affect the direction of other
   types of requests, such as REPORT.  SEND requests that contain some
   kind of control or reporting protocol rather than regular message
   payload (e.g., Instant Message Delivery Notification (IMDN) reports)
   should be generated according to the protocol rules as if no
   direction attribute were present.

(page 36 continued on part 3)

Next RFC Part