WDIFF

draft-ietf-simple-message-sessions-07.txt --> draft-ietf-simple-message-sessions-08.txt

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.

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

Campbell, et al. Expires January 16, February 23, 2005 [Page 1]

Internet-Draft MSRP July August 2004

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

Campbell, et al. Expires January 16, 2005 [Page 2]
Internet-Draft MSRP July 2004

11.1 Basic IM session . . . . . . . 37
13. Security Considerations . . . . . . . . . . . . . 33
11.2 Chunked Message . . . . . 38

Campbell, et al. Expires February 23, 2005 [Page 2]

Internet-Draft MSRP August 2004

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 . . . . . . . . . . . . 42
15.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . 43
15.3.1 Accept Types . . . . . . . . . . . . . . . . . . . . 43
15.3.2 Wrapped Types . . . . . . . . . . . . . . . . . . . 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 41
15.2 draft-ietf-simple-message-sessions-07 . . . . . . . . . 44
16.2 41
15.3 draft-ietf-simple-message-sessions-06 . . . . . . . . . 44
16.3 42
15.4 draft-ietf-simple-message-sessions-05 . . . . . . . . . 45
16.4 42
15.5 draft-ietf-simple-message-sessions-04 . . . . . . . . . 45
16.5 43
15.6 draft-ietf-simple-message-sessions-03 . . . . . . . . . 45
16.6 43
15.7 draft-ietf-simple-message-sessions-02 . . . . . . . . . 46
16.7 43
15.8 draft-ietf-simple-message-sessions-01 . . . . . . . . . 46
16.8 44
15.9 draft-ietf-simple-message-sessions-00 . . . . . . . . . 47
16.9 44
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

Campbell, et al. Expires January 16, February 23, 2005 [Page 3]

Internet-Draft MSRP July August 2004

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

Campbell, et al. Expires January 16, February 23, 2005 [Page 4]

Internet-Draft MSRP July August 2004

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

Campbell, et al. Expires January 16, February 23, 2005 [Page 5]

Internet-Draft MSRP July August 2004

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.

Campbell, et al. Expires January 16, February 23, 2005 [Page 6]

Internet-Draft MSRP July August 2004

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

Campbell, et al. Expires January 16, February 23, 2005 [Page 7]

Internet-Draft MSRP July August 2004

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.

Campbell, et al. Expires January 16, February 23, 2005 [Page 8]

Internet-Draft MSRP July August 2004

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$

The receiver uses the value of the Message-ID header

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

The 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, recipient. When two MSRP nodes
communicate directly they need only one URL in the flag MUST be a "$",
otherwise To-Path list and
one URL in the flag MUST be From-Path list.

4.3 MSRP Transaction and Report Model

A sender sends MSRP requests to a "+". receiver. The Byte-Range header value contains a starting value followed by a
"-", an ending value followed by a "/", and finally the total length.
The starting value indicates the index into the message where the
first byte in the current chunk belongs. The index of the first
octet in the complete message is ONE, not zero. The ending value
indicates the location where the last octet belongs. The body MAY
contain less data than is indicated by the end but it receiver MUST NOT
contain more octets than indicated. The length indicates the number
of octets in
quickly accept or reject the complete message. Both request. If the ending value and length
MAY have receiver initially
accepted the value of "*" in some request, it still may then do things that take
significant time to succeed or all of fail. For example, if the chunks, receiver is
an MSRP to XMPP [29] gateway, it may forward the message over XMPP.
The XMPP side may later indicate that they are not specified. If no Byte-Range header is present, the
SEND request MUST be treated as if there was a Byte-Range header
present with a value of "1-*/*".

This chunking mechanism allows a sender to interrupt a chunk part way
through sending it by writing out the boundary termination and did not work. At
this point, the
"+" flag MSRP receiver may need to indicate that the end of this chunk is request
did not succeed. There are two important concepts here: first, the end of the
complete message. The ability to interrupt messages allows multiple

Campbell, et al. Expires January 16, February 23, 2005 [Page 9]

Internet-Draft MSRP July August 2004

sessions to share a TCP connection, and for large messages to be sent
efficiently while not blocking other messages that share

hop by hop delivery of the same
connection.

To insure fairness over a connection, senders MUST NOT send chunks
with a body larger than 2048 octets unless they are prepared to
interrupt them. A sender can use one request may succeed or fail; second, the
end result of the following two strategies
to satisfy this requirement. request may be successfully processed or not. The sender
first type of status is STRONGLY RECOMMENDED referred to
send messages larger than 2048 octets using as few chunks as
possible, interrupting chunks (at least 2048 octets long) when other
traffic "transaction status" and may
be returned in response to a request. The second type of status is waiting
referred to use as "request status" and may be returned 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 it knows that the same connection. Alternatively, request succeeded,
and the sender MAY simply send chunks in 2048 octet increments until requested a success report. A receiver only sends a
failure REPORT if the
final chunk. Note that request failed and the former strategy results in markedly more
efficient use of sender requested failure
reports.

This document describes the connection. All behavior of MSRP nodes MUST endpoints. MSRP
relays or gateways are likely to have additional conditions that
indicate a failure REPORT should be able sent, such as the failure to
receive chunks of any size a positive response from 0 octets to the maximum number of
octets they can next hop.

Two header fields control the sender's desire to receive for reports.
The header "Report-Success" can have a complete message. Senders SHOULD NOT
break messages into chunks smaller than 2048 octets, except for the
final chunk value of "yes" or "no" and the
"Report-Failure" header can have a complete message.

Receivers MUST not assume value of "yes", "no", or
"partial".

The combinations of reporting are needed to meet the chunks will various
scenarios of currently deployed IM systems. Report-Success might be delivered
"no" in order or
that they will receive all the chunks with "+" flags before they
receive the chunk with the "$" flag. In certain cases many public systems to reduce load but is used in some
current enterprise systems, such as systems used for securities
trading. A Report-Failure value of connection
failure, it "no" is possible useful for information sending system
messages such as "the system is going down in 5 minutes" without
causing a response explosion to be duplicated. If chunks
data the sender. A Report-Failure of
"yes" is received used by many systems that overlaps already received data for the same
message, the last chunk received takes precedence (even though this
may not have been wish to notify the last chunk transmitted). For example, user if bytes
1 the
message failed but some other systems choose to 100 was received and use a chunk arrives that contains bytes 50 to
150, this second chunk will overwrite bytes 50 to 100 value of
"partial" to reduce the data
that had already been received. Although other schemes work, this is
the easiest for load on the receiver and results servers caused by 200 OK
responses, but still allow error responses to be sent in consistent behavior
between clients.

The seven "-" before the boundary are used so that the receiver can
search for the value "----", 32 bits at many cases.

4.4 MSRP Connection Model

When MSRP wishes to send a time request to find the probable
location of a peer identified by an MSRP
URL, it first needs a connection, with the boundary. This allows most processors appropriate security
properties, to locate the
boundaries and copy host specified in the memory at URL. If the sender already
has such a connection, that is, one associated with the same rate host,
port, and URL scheme, then it SHOULD reuse that connection.

When a normal memory
copy could be done. This approach results in a system that new MSRP session is as
fast as framing based on specifying the body length in the headers of
the request, but also allows for created, the interruption of messages.

The ability to interrupt messages convention is needed so that TCP connections
can be shared. Connection sharing is necessary for "fair" allocation
of bandwidth in congestion situations and for allowing MSRP network
elements the
element that have sent the SDP offer MUST immediately issue a very large number of concurrent connections SEND request
to
different users. the answerer. This request MAY have a empty body, or MAY carry

Campbell, et al. Expires January 16, February 23, 2005 [Page 10]

Internet-Draft MSRP July August 2004

4.2 MSRP Addressing

MSRP entities are addressed using URLs. The MSRP URL schemes are
defined in Section 5. The syntax of the To-Path and From-Path
headers allow for

content.

When a list of URLs. This was done new connection needs to allow be formed, the
protocol to work with gateways or relays defined in element looks at the future,
URL to
provide a complete path decide on the type of connection (TLS, TCP, etc.) then
connects to the end recipient. When two MSRP nodes
communicate directly they need only one host indicated by the URL, following the URL
resolution rules in Section 5.2. For connections using the To-Path list and
one URL msrps:
scheme, the SubjectAltName in the From-Path list.

4.3 MSRP Transaction and Report Model

A sender sends MSRP requests to a receiver. The receiver received certificate MUST
quickly accept or reject match the request. If
hostname part of the receiver initially
accepted URL and the request, it still may then do things certificate MUST be valid, including
having a date that take
significant time to succeed or fail. For example, if the receiver is valid and being signed by an MSRP to XMPP [29] gateway, it may forward acceptable
certificate authority. At this point the message over XMPP.
The XMPP side may later indicate device that initiated the request did not work. At
connection can assume that this point, connection is with the MSRP receiver may need to indicate that correct host.

If the request
did not succeed. There are two important concepts here: first, connection used mutual TLS authentication, and the
hop by hop delivery TLS client
presented a valid certificate, then the element accepting the
connection can know the identity of the connecting host. When mutual
TLS authentication is not used, the listening device MUST wait until
it receives a request may succeed or fail; second, on the
end result connection to determine the identity of
the request may be successfully processed or not. The connecting device.

When the first type of status is referred to as "transaction status" and may
be returned in response to request arrives, its To-Path header field should
contain a request. The second type of status is
referred to as "request status" and may be returned URL that the listening element handed out in the SDP for a REPORT
transaction.
session. The original sender of a request can indicate if they wish to receive
reports for requests element that fail, accepted the connection looks up the URL
in the received request, and can independently indicate if
they wish to receive reports for requests that succeed. A receiver
only sends a success REPORT if determines which session it knows matches. If
a match exists, the node MUST assume that the request succeeded,
and host that formed the sender requested a success report. A receiver only sends a
failure REPORT if
connection is the request failed and host that this URL was given to. If no match
exists, the sender requested failure
reports.

This document describes node MUST reject the behavior of MSRP endpoints. MSRP
relays or gateways are likely to have additional conditions that
indicate request with a failure REPORT should be sent, such as the failure 481 response. The
node MUST also check to
receive a positive response from make sure the next hop.

Two header fields control session is not already in use
on another connection. If so, it MUST reject the sender's desire request with a 506
response.

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

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

Campbell, et al. Expires January 16, February 23, 2005 [Page 11]

Internet-Draft MSRP July August 2004

transaction is sent,

without warning of the element MUST inform duplicates.

In this situation, the user endpoint MUST choose Message-ID values so that
they are unique in the
request probably failed. If the value is set to "partial", then context of both the
element sending original session and the transaction does not have to run
replacement session.

When endpoints create a timer, but
MUST inform new session in this fashion, the user if receives a non-recoverable error response to
the transaction.

Similarly if the value of the Report-Success header is "yes", then
the receiving node MUST send a "success" REPORT after the request is
complete to indicate that the request succeeded. Likewise if the
value is "no", it MUST NOT send a success REPORT.

A consequence of this is that if an MSRP element receives chunks for a request
that has
given logical message MAY be split across the Report-Failure header set to a value of "no", it 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 be
treated not assume that the same as a Report-Success header with value of "no". If
no Report-Failure header is present, it MUST be treated new URLs in the same as a
Report-Failure header with value of "yes". REPORT requests MUST have SDP will be the
same Message-ID header value as the request they old ones. A connection SHOULD not be closed while there
are reporting
on. They MAY also have the Byte-Range of the chunk they sessions that are
reporting on. If an using this connection.

5. MSRP element receives a REPORT for URLs

An MSRP URL follows a Message-ID
it does not recognize, it SHOULD silently ignore the REPORT.

Report-Success and Report-Failure MUST NOT be present in a REPORT
request. MSRP nodes MUST NOT send REPORT requests in response to
report requests. MSRP Nodes MUST NOT send MSRP responses to REPORT
requests.

The combinations of reporting may seem overly complex but they are
needed to meet the various scenarios of currently deployed IM
systems. Report-Success might be "no" in many public systems to
reduce load but is used in some current enterprise systems, such as
systems used for securities trading. A Report-Failure value of "no"
is useful for sending system messages such as "the system is going
down in 5 minutes" without causing a response explosion to the
sender. A Report-Failure of "yes" is used by many systems that wish
to notify the user if the message failed but some other systems
choose to use a value of "partial" to reduce the load on the servers
caused by 200 OK responses, but still allow error responses to be
sent in many cases.

4.4 MSRP Connection Model

When MSRP wishes to send a request to a peer identified by an MSRP

Campbell, et al. Expires January 16, 2005 [Page 12]
Internet-Draft MSRP July 2004

URL, it first needs a connection, with the appropriate security
properties, to the host specified in the URL. If the sender already
has such a connection, that is, one associated with the same host,
port, and URL scheme, then it SHOULD reuse that connection.

When a new MSRP session is created, the convention is that the
element that sent the SDP offer MUST immediately issue a SEND request
to the answerer. This request MAY have a empty body, or MAY carry
content.

When 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 the host indicated 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 of the URL and the certificate 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.

If the connection used mutual TLS authentication, and the TLS client
presented a valid certificate, then the element accepting the
connection can know the identity of the connecting host. When mutual
TLS authentication is not used, the listening device MUST wait until
it receives a request on the connection to determine the identity of
the connecting device.

When the first request arrives, it's To-Path header field should
contain a URL that the listening element handed out in the SDP for a
session. The element that accepted the connection looks up the URL
in the received request, and determines which session it matches. If
a match exists, the node MUST assume that the host that formed the
connection is the host that this URL was given to. If no match
exists, the node MUST reject the request with a 481 response. The
node MUST also check to make sure the session is not already in use
on another connection. If so, it MUST reject the request with a 506
response.

If it were legal to have multiple connections associated with the
same session, a security problem would exist. If the initial SEND
request is not protected, an eavesdropper might learn the URL, and
use it to insert messages into the session via a different
connection.

If a connection fails for any reason, then an MSRP endpoint MUST
consider failed any sessions associated with the connection as well.
When an endpoint notices such a failure, it SHOULD attempt to
re-create any such sessions using a new SDP exchange. If a

Campbell, et al. Expires January 16, 2005 [Page 13]
Internet-Draft MSRP July 2004

replacement session is successfully created, endpoints MAY attempt to
resend any content for which delivery on the original session could
not be confirmed. If it does this, the Message-ID values for the
resent messages MUST match those used in the initial attempts. If
the receiving endpoint receives more than one message with the same
Message-ID. It SHOULD assume that the messages are duplicates. It
MAY take any action based on that knowledge, but SHOULD NOT present
the duplicate messages to the user without warning of the duplicates.

In this situation, the endpoint MUST choose Message-ID values so that
they are unique in the context of both the original session and the
replacement session.

When endpoints create a new session in this fashion, the chunks for a
given logical message MAY be split across the sessions. However,
endpoints SHOULD NOT split chunks between sessions under normal
circumstances.

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

5. MSRP URLs

An MSRP URL follows a subset of subset of the URL syntax in Appendix A of
RFC2396 [11], [10], with a scheme of "msrp" or "msrps":

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

The constructions for "userinfo", "hostport", and "unreserved" are
detailed in RFC2396 [11]. [10]. URLs designating MSRP over TCP MUST
include the "tcp" parameter. If some other transport is used, the
"tcp" parameter MUST NOT be present.

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

An MSRP URL server part hostport field identifies a participant in an MSRP
session.

Campbell, et al. Expires January 16, 2005 [Page 14]
Internet-Draft MSRP July 2004 If the server part hostport contains a numeric IP address, it MUST also
contain a port. The resource part identifies a particular session
the participant. The absence of the resource part indicates a
reference to an MSRP host device, but does not specifically refer to
a particular session resource.

A scheme of "msrps" indicates the underlying connection MUST be
protected with TLS.

Campbell, et al. Expires February 23, 2005 [Page 12]

Internet-Draft MSRP August 2004

MSRP has an IANA registered recommended port defined in Section 15.1. 14.1.
This value is not a default, as 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 network administrators who
need to manage firewall policy for MSRP.

The server part will typically not contain a userinfo component, but
MAY do so to indicate a user account for which the session is valid.
Note that this is not the same thing as identifying the session
itself. If a userinfo component exists, 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, a userinfo
part MUST NOT contain password information.

The following is an example of a typical MSRP URL:

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

5.1 MSRP URL Comparison

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

1. The scheme must match exactly.

2. The host part If the hostpart contains an eplicit IP address, and/or port,
these are compared numerically. Otherwise, hostpart is compared
as a case insensitive. insensitive character string.

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

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

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

Campbell, et al. Expires January 16, 2005 [Page 15]
Internet-Draft MSRP July 2004

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.

Campbell, et al. Expires February 23, 2005 [Page 13]

Internet-Draft MSRP August 2004

5.2 Resolving MSRP Host Device

An MSRP host device is identified by the server part of an MSRP URL.

If the server part contains a numeric IP address and port, they MUST
be used as listed.

If the server part contains a host name and a port, the connecting
device MUST determine a host address by doing an A or AAAA DNS query,
and use the port as listed.

If a connection attempt fails, the device SHOULD attempt to connect
to the addresses returned in any additional A or AAAA records, in the
order the records were presented.

This process assumes that the connection port is always known
prior to resolution. This is always true for the MSRP URL uses
described in this document, that is, URLs always created and
consumed by automata, rather than by humans. The introduction of
relays may create situations where this is not the case. For
example, the MSRP URL that a user enters into a client to
configure it to use a relay may be intended to be easily
remembered and communicated by humans, and therefore is likely to
omit the port. Therefore, the relay specification [21] may
describe additional steps to resolve 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 are beyond the scope 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 an MSRP
request start line. Next, the sender places the target path in a
To-Path header, and the sender's URL in a From-Path header. If
multiple URLs are present in the To-Path, the leftmost is the first
URL visited; the rightmost URL is the last URL visited. The
processing then becomes method specific. Additional method-specific

Campbell, et al. Expires January 16, 2005 [Page 16]
Internet-Draft MSRP July 2004
headers are added as described in the following sections.

After any method-specific headers are added, processing continues to
handle a body, if present. A body in a Non-SEND request MUST NOT be
longer than 2048 octets. If the request has a body, it must contain
a Content-Type header field. It may contain other MIME specific

Campbell, et al. Expires February 23, 2005 [Page 14]

Internet-Draft MSRP August 2004

headers. The Content-Type header MUST be the last header line. The
body MUST be separated from the headers with an extra CRLF.

The boundary marker that terminates the body MUST be preceded by a
CRLF that is not part of the body and then seven "-" (minus sign)
characters. After the boundary marker, there MUST be a flag
character that is a "$" (for the last chunk of the complete
message), "#" (for the last chunk of an aborted message), or "+" (for
chunks other than the last). If the chunk represents the data that
forms the end of the complete message, the flag value MUST be a "$".
If sender is abandoning an incomplete message, and intends to send no
further chunks in that message, it MUST be a "#". Otherwise it MUST
be a "+".

If the request contains a body, the sender MUST check the body to
insure that the closing sequence (a CRLF, seven hyphens, and the
transaction identifier) is not present in the body. If the closing
sequence is present in the body, the sender MUST choose a new
transaction identifier that is not present in the body, and add the
closing sequence, including the "$" "$", "#", or "+" character, and a
final CRLF.

Finally, requests which have no body MUST NOT contain a Content-Type
header or any other MIME specific header. Bodiless requests MUST
contain a closing sequence after the final header.

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

6.1.1 Delivering SEND requests

When an endpoint has a message to deliver, it first generates a new
unique Message-ID. This ID MUST be unique within the scope of the
session. If the message is larger than 2048 octets in length, it
either generates an interruptible chunk (which is RECOMMENDED), or it
MAY break the complete message into chunks of 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 the
Message-ID. If 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 of the same message MUST use the
same Report-Failure and Report-Success values in their SEND requests.

If success reports are requested, i.e. the value of the
Report-Success header is "yes", the sending device MAY wish to run a

Campbell, et al. Expires February 23, 2005 [Page 15]

Internet-Draft MSRP August 2004

timer of some value that makes sense for it's 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

Campbell, et al. Expires January 16, 2005 [Page 17]
Internet-Draft MSRP July 2004
inform the user.

The first chunk of the message SHOULD, and all subsequent chunks MUST
include a Byte-Range header field. The range-start field MUST
indicate

If the position value of "Report-Failure" is set to "yes", then the first byte in sender of
the body in request runs a timer. If a 200 response to the overall
message. The range-end field SHOULD indicate transaction is
not received within 30 seconds from the position of time the last byte in the body, if known. It MUST take the value of "*" if the position
transaction is unknown, or if sent, the element MUST inform the user that the
request needs probably failed. If the value is set to be interruptible.
The total field SHOULD contain "partial", then the total size of
element sending the message, if
known. The total filed MAY contain transaction does not have to run a "*" if timer, but
MUST inform the total size of user if receives a non-recoverable error response to
the
message transaction.

If no Report-Success header is not known present in advance. All chunks other than the last MUST
include a "+" character in the continuation field of the closing
line. The final chunk SEND request, it MUST use be
treated the same as a "$" character. The sender Report-Success header with value of "no". If
no Report-Failure header is present, it MUST
send all chunks in Byte-Range order. (However,the receiver cannot
assume be treated the same as a
Report-Failure header with value of "yes". REPORT requests will be delivered in order, MUST have
the same Message-ID header value as an intervening
relay may the request they are reporting
on. They MAY also have changed the order.)

If Byte-Range of the sender chooses to send chunk they are
reporting on. If an MSRP element receives a body larger than 2048 octets in REPORT for a
single chunk, Message-ID
it does not recognize, it SHOULD silently ignore the request REPORT.

Report-Success and Report-Failure MUST NOT be constructed so that it can be
interrupted. A SEND request is interruptible if it either has no present for any method
other than SEND. MSRP nodes MUST NOT send REPORT requests in
response to report requests. MSRP Nodes MUST NOT send MSRP responses
to REPORT requests.

The Byte-Range header field, or has such value contains a field with starting value (range-start)
followed by a "*" in the
last-byte sub-field.

A SEND request is interrupted while "-", an ending value (range-end) followed by a body is in the process of being
written to "/", and
finally the connection by simply noting how much of total length. The first byte in 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 is indicated
by a
another one, rather than a zero.

The first chunk with of the same Message-ID message SHOULD, and all subsequent chunks MUST
include a Byte-Range header range
start field. The range-start field containing MUST
indicate 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 in the same
connections, body in the device overall
message (that is, a value of one). The range-end field SHOULD implement some scheme to alternate
between them such that each concurrent
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 gets a chance needs to send
some fair portion be interruptible. The total field SHOULD contain
the total size of data at regular intervals suitable to the
application. message, if known. The sender MUST NOT assume that total field MAY contain
a "*" if the total size of the message is received by not known in advance. All
chunks other than the peer
with last MUST include a "+" character in the same
continuation field of the closing line. The final chunk allocation MUST use a
"$" character if it was sent with. An intervening
relay could possibly break SEND requests into smaller chunks, completes the message, or
aggregate multiple chunks into larger ones.

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

Campbell, et al. Expires January 16, February 23, 2005 [Page 18] 16]

Internet-Draft MSRP July August 2004

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

aborting the message. The sender MUST
contain send all chunks in Byte-Range
order. (However, the Message-ID header from receiver cannot assume the original SEND request.

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

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

To insure fairness over a body. If connection, senders MUST NOT send chunks
with a body is included, it SHOULD
be larger than 2048 octets unless they are prepared to
interrupt them. A sender can use one of the DSN MIME type detailed in RFC1894 [8], but MAY be of some following two strategies
to satisfy this requirement. The sender is STRONGLY RECOMMENDED to
send messages larger than 2048 octets using as few chunks as
possible, interrupting chunks (at least 2048 octets long) when other type if
traffic is waiting to use the sender of same connection. Alternatively, the SEND request indicated support
sender MAY simply send chunks in 2048 octet increments until the
"receipt-type" parameter of
final chunk. Note that the respective Report-Success or
Report-Failure header field. This parameter contains former strategy results in markedly more
efficient use of the alternative
MIME type that SHOULD be used for this particular report. A client
specifying an alternative 'receipt-type' for an connection. All MSRP transaction nodes MUST
also be capable able to
receive chunks of receiving any size from 0 octets to the default format specified in this
RFC1894. Use maximum number of the DSN MIME format in MSRP is described in Section
8

An endpoint MUST send
octets they can receive for a success report if it successfully receives 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 which contained a Report-Success value of "yes", and is interruptible if it either contains a complete message, has no Byte-Range header
field, or contains the last chunk needed
to complete has such a field with a "*" in the message. This last-byte sub-field.

A SEND request is sent following the normal
procedures (Section 6.1), with a few additional requirements.

The endpoint inserts interrupted while a To-Path header field containing body is in the From-Path
value from process of being
written to the original request, and a From-Path header containing connection by simply noting how much of the URL identifying itself in message
has already been written to the session. The endpoint connection, then inserts writing out the
boundary string to end the chunk. It can then be resumed in a Status header field
another chunk with a namespace of "000", a short-status of
"200" and a relevant Reason phrase, the same Message-ID and a Message-ID Byte-Range header range
start field containing the value 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 original request.

Positive status reports same
connection, the device SHOULD NOT include implement some scheme to alternate
between them such that each concurrent request gets a payload. chance to send
some fair portion of data at regular intervals suitable to the
application.

The endpoint sender MUST NOT send a success report for a SEND request assume that
either contained no Report-Success header field, or contained such a
field message is received by the peer
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 same chunk allocation it was not present
in the original request, sent with. An intervening
relay could possibly break SEND requests into smaller chunks, or had a value
aggregate multiple chunks into larger ones.

The default disposition of "yes", body is "render". If the sender wants
different disposition, it SHOULD simply
send MAY insert a transaction response with an appropriate error response code.
However, there may be situations where the error cannot be determined
quickly, such as when the endpoint Content-Disposition header.
Since MSRP is a gateway that must wait for a
downstream network to indicate an error. In this situation, it MAY binary protocol, transfer encoding MUST be "binary".

Campbell, et al. Expires January 16, February 23, 2005 [Page 19] 17]

Internet-Draft MSRP July August 2004

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", then it MUST NOT send a failure

6.1.2 Sending REPORT
request, and SHOULD NOT send an MSRP response.

Construction of failure requests

REPORT requests is identical are similar to that for
success reports, SEND requests, except the Status that report
requests MUST NOT include Report-Success or Report-Failure header code
fields, 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 a Status header field. REPORT requests MAY contain a payload, using the DSN MIME
type. They MAY MUST
contain some other type if allowed by a receipt-type
in the Report-Failure Message-ID header field. from the original SEND request.

If an MSRP element receives a failure report is sent in response to a SEND request that
contained REPORT for a chunk, 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 Byte-Range header indicating body, as the
actual range being reported on. It REPORT
request header fields can take carry sufficient information in most cases.
However, REPORT requests MAY include a body containing additional
information about the range-start and
total values from status of the original assocated SEND request, but MUST calculate request. Such a
body is informational only, and the
range-end field from sender of the actual body data.

Endpoints REPORT request
SHOULD NOT send REPORT requests if they have reason assume that the recipient pays any attention to
believe the request will body.
Since REPORT requests are not be delivered. For example, they SHOULD interruptible, the size of such a body
MUST NOT exceed 2 kilobytes.

An endpoint MUST send a REPORT success report if it successfully receives a
SEND request on which contained a session that is no longer valid. Report-Success value of "yes" and
either contains a complete message, or contains the last chunk needed
to complete the message. This section only describes failure report generation behavior for
MSRP endpoints. Relay behavior request is beyond sent following the scope of this
document, 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 will be considered a From-Path header containing
the URL identifying itself in the session. The endpoint then inserts
a separate document. We
expect failure reports to be more commonly generated by relays
than by endpoints.

6.2 Constructing Responses

If an MSRP 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.

The endpoint receives MUST NOT send a success report for a SEND request that
either contains a
Report-Failure contained no Report-Success header value of "yes", field, or does not contain contained such a
Report-Failure
field with a value of "no". That is, if no Report-Success header
field at all, is present, it MUST immediately generate is treated identically to one with a
response. Likewise, if value of
"no."

6.1.3 Failure REPORT Generation

If an MSRP endpoint receives a SEND request that
contains a Report-Failure header value of "partial", it cannot process
for some reason, and the receiver
is unable to process Report-Failure header either was not present
in the original request, or had a value of "yes", it SHOULD immediately generate a
response.

To construct the response, the endpoint first creates simply
include the response
start-line, inserting appropriate response appopriate error 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 respons.
However, there may be situations where the request triggering error cannot be determined
quickly, such as when the response was endpoint is a gateway that must wait for a SEND request, the To-Path

Campbell, et al. Expires January 16, February 23, 2005 [Page 20] 18]

Internet-Draft MSRP July August 2004

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

downstream network to indicate an error. In this situation, it MAY
send a 200 OK response 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 then send a failure REPORT requests do not
request responses, so this specification doesn't exercise when the
behavior described above, however we expect that extensions for
gateways and relays will need such behavior.)

Finally, error is detected.

If the endpoint inserts receives a From-Path SEND request with a Report-Failure header
field containing the
URL that identifies it in the context value of "no", then it MUST NOT send a failure REPORT request,
and SHOULD NOT send an MSRP response. If the session, followed by the
closing sequence after value is "partial", it
SHOULD NOT send a 200 response to the last header field. 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
transmitted back on
treated the same connection on which as a Report-Failure header with value of "yes".

Construction of failure REPORT requests is identical to that for
success reports, except the original Status header code and reason fields MUST
contain appropriate error codes. Any error response code defined in
this specification MAY also be used in failure reports.

If a failure report is sent in response to a SEND request
arrived.

6.3 Receiving Requests

The receiving endpoint must first check that
contained a chunk, it MUST include a Byte-Range header indicating the URL in
actual range being reported on. It can take the To-Path to
make sure range-start and
total values from the request belongs 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 an existing session. When
believe the request is received, the To-Path will have exactly one URL, which
MUST map to an existing not be delivered. For example, they SHOULD
NOT send a REPORT request on a session that is associated with the
connection on which no longer valid.

This section only describes failure report generation behavior for
MSRP endpoints. Relay behavior is beyond the request arrived. If scope of this is not true,
document, and
the 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 contained that either contains a
Report-Failure header value of "no", then the
receiver SHOULD quietly ignore the request. If the "yes", or does not contain a
Report-Failure header is not present, or had any other value, then the receiver field at all, it MUST
return immediately generate a 481
response.

Further request processing by the receiver is method specific.

6.3.1 Receiving SEND requests

When the receiving Likewise, if an MSRP endpoint receives a SEND request, it first
determines if it contains a complete message, or a chunk from a
larger message. If the request that
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 Report-Failure header value of "partial", and the data from receiver
is unable to process the request and places request, it in SHOULD immediately generate a
response.

To construct the response, the endpoint first creates the response
start-line, inserting appropriate place response code and reason fields.
The transaction identifier in the buffer. The receiver response start line MUST determine the actual length of each
chunk by inspecting the payload itself; it is possible the body is
shorter than match the range-end field indicates. This can occur if
transaction identifier from the
sender interrupted a SEND request unexpectedly. It is worth nothing original request.

Campbell, et al. Expires January 16, February 23, 2005 [Page 21] 19]

Internet-Draft MSRP July August 2004

that

The endpoint then inserts an appropriate To-Path header field. If
the chunk that has request triggering the response was a termination character of "$" defines SEND request, the
total length To-Path
header field is formed by copying the last (right-most) URI in the
From-Path header field of the message.

What is done with request. (Unlike other methods,
responses to SEND requests are returned only to the body 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 outside generated by taking the scope list of MSRP URLs from the From-Path of the
original request, reversing the list, and largely
determined by writing the MIME type. The body MAY be rendered after reversed list
into the
whole message is received or partially rendered as it is being
received.

If 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 SEND request contained endpoint inserts a Content-Type From-Path header field indicating
an unsupported MIME type, containing the receiver SHOULD send a 415 response, if
allowed
URL that identifies it in the context of the session, followed by the Report-Failure
closing sequence after the last header field. All MSRP endpoints The response MUST be able to receive the multipart/mixed and multipart/alternative MIME
types.

If
transmitted back on the SEND request contained a Report-Success header field with a
value of "yes", and same connection on which the original request is either contains
arrived.

6.3 Receiving Requests

The receiving endpoint must first check the entire message
or URL in the last chunk needed To-Path to complete a message,
make sure the receiver MUST
send a success REPORT request back belongs to the sender.

6.3.2 Receiving REPORT requests

When an endpoint receives a REPORT request, it may correlate it to existing session. When the original SEND
request using is received, the Message-ID and To-Path will have exactly one URL, which
MUST map to an existing session that is associated with the Byte-Range, if
present.
connection on which the request arrived. If it requested success reports, then it SHOULD keep enough
state about each outstanding sent message so that it can correlate
REPORT requests to this is not true, and
the original messages.

An endpoint that receives a REPORT request containing contained a Status Report-Failure header
with a namespace field value of "000", it "no", then the
receiver SHOULD interpret quietly ignore the report in
exactly request. If the same way it would interpret an MSRP transaction response
with Report-Failure
header is not present, or had any other value, then the receiver MUST
return a response code matching 481 response.

Further request processing by the short-code field.

It receiver is possible to receive method specific.

6.3.1 Receiving SEND requests

When the receiving endpoint receives a failure report or SEND request, it first
determines if it contains a failure transaction
response for complete message, or 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 from a REPORT
larger message. If the request on a
session that is contains no longer valid. The endpoint's behavior if this
happens is Byte-Range header, or
contains one with a matter range-start value 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 "1", and the closing line
continuation flag has a connection active in case late REPORTs might
arrive.

7. Using MSRP with SIP

7.1 SDP Offer-Answer Exchanges for MSRP Sessions

MSRP sessions will typically be initiated using value of "$", then the Session

Campbell, et al. Expires January 16, 2005 [Page 22]
Internet-Draft MSRP July 2004

Description Protocol (SDP) [2] via request contained the SIP offer-answer mechanism
[3].

This document defines
entire message. Otherwise, the receiver looks at the Message-ID
value to associate chunks together into the original message. It
forms a handful of new SDP parameters virtual buffer to setup MSRP
sessions. These are detailed below and in receive the IANA Considerations
section.

The general format message, keeping track of an SDP media-line is:

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

An offered or accepted MSRP media-line MUST which
bytes have been received and which are missing. The receiver takes
the following value
exactly, with data from the exception that request and places it in 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 appropriate place in
the buffer. The receiver MUST set determine the port number actual length of that media-line
to zero (0).)

m=message 9 msrp *

While MSRP could theoretically carry any media type, "message" is
appropriate. For MSRP, each
chunk by inspecting the port number payload itself; it is always ignored--the
actual port number possible the body is provided in an

Campbell, et al. Expires February 23, 2005 [Page 20]

Internet-Draft MSRP URL. Instead "9" is
used, which is an innocuous value which is assigned to August 2004

shorter than the discard
port. The protocol range-end field indicates. This can occur if the
sender interrupted a SEND request unexpectedly. It is always "msrp", and worth nothing
that the value chunk that has a termination character of "$" defines the
total length of the format
list message.

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 chunk with the "$" flag. In certain cases of connection
failure, it is always a single asterisk character ("*").

An MSRP media-line possible for information to be duplicated. If chunks
data is always accompanied by a mandatory "path"
attribute. This attribute contains received 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 space separated list of URLs chunk arrives that must be visited contains bytes 50 to contact
150, this second chunk will overwrite bytes 50 to 100 of the user agent advertising data
that had already been received. Although other schemes work, this
session-description. If more than one URL is present,
the leftmost
URL is easiest for the first URL receiver and results in consistent behavior
between clients.

The seven "-" before the boundary are used so that must be visited to reach the target
resource. (The path list receiver can contain multiple URLs to allow
search for the
deployment value "----", 32 bits at a time to find the probable
location of gateways or relays in the future.) MSRP
implementations which can accept incoming connections will typically
only provide boundary. This allows most processors to locate the
boundaries and copy the memory at the same rate that a single URL here.

MSRP media lines MUST also normal memory
copy could be accompanied by an "accept-types"
attribute. done. This attribute contains approach results in a list of MIME types which are
acceptable to system that is as
fast as framing based on specifying the endpoint.

A "*" entry body length in the accept-types attribute indicates that headers of
the sender
may attempt to send content with media types that have not been
explicitly listed. Likewise, an entry request, but also allows for the interruption of messages.

What is done with an explicit type the body is outside the scope of MSRP and a
"*" character 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 subtype indicates that SEND request contained a Content-Type header field indicating
an unsupported MIME type, the sender may attempt to receiver SHOULD send content with any subtype of that type. If a 415 response, if
allowed by the receiver receives
an Report-Failure header field. All MSRP request and is endpoints MUST
be able to process receive the media type, multipart/mixed and multipart/alternative MIME
types.

6.3.2 Receiving REPORT requests

When an endpoint receives a REPORT request, it does so. may correlate it to
the original SEND request using the Message-ID and the Byte-Range, if
present. If not, it will respond 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 415 response. Note that all explicit
entries namespace field of "000", it SHOULD be considered preferred over any non-listed types. interpret the report in
exactly the same way it would interpret an MSRP transaction response

Campbell, et al. Expires January 16, February 23, 2005 [Page 23] 21]

Internet-Draft MSRP July August 2004

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

with a response code matching the root payload, short-code field.

It is possible to receive a failure report or may be wrapped in a listed container type.
Any container types MUST also be listed in failure transaction
response for a chunk that is currently being delivered. In this case
the accept-types
attribute.

Occasionally entire message corresponding to that chunk should be aborted.

It is possible that an endpoint will need to specify receive a MIME body type REPORT request on a
session that
can only be used is no longer valid. The endpoint's behavior if wrapped inside this
happens is a listed container type.

Endpoints MAY specify MIME types that are only allowed when wrapped
inside compound types using the "accept-wrapped-types" attribute 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
an case late REPORTs might
arrive.

MSRP Modes MUST NOT send MSRP responses to REPORT requests.

7. Using MSRP with SIP

7.1 SDP a-line.

The semantics Offer-Answer Exchanges for accept-wrapped-types are identical 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 those 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
accept-types attribute, following value
exactly, with the exception that the specified types
may only be used when wrapped inside containers. Only types listed
in the accept-types attribute may port field MAY be used as the "root" type for the
entire body. Since 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 type listed media type, "message" is
appropriate. For MSRP, the port number is always ignored--the
actual port number is provided in accept-types may be used both
as an MSRP URL. Instead a root body, dummy
value is used, which is always ignored if non-zero. The protocol
is always "msrp", and wrapped in other bodies, the value of the format entries from
accept-types SHOULD NOT be repeated in this list is always a
single asterisk character ("*").

An MSRP media-line is always accompanied by a mandatory "path"
attribute. This approach does not allow for specifying distinct lists of
acceptable wrapped types for different types of containers. If an
endpoint understands attribute contains a MIME type in the context space separated list of URLs

Campbell, et al. Expires February 23, 2005 [Page 22]

Internet-Draft MSRP August 2004

that must be visited to contact the user agent advertising this
session-description. If more than one wrapper, it URL is
assumed to understand it in present, the context of any other acceptable
wrappers, subject to any constraints defined by leftmost
URL is the wrapper types
themselves.

The approach of specifying types first URL that are only allowed inside of
containers separately from must be visited to reach the primary payload types allows an
endpoint target
resource. (The path list can contain multiple URLs to force allow for the use
deployment of certain wrappers. For example, gateways or relays in the future.) MSRP
implementations which can accept incoming connections will typically
only provide a
CPIM [14] gateway device may require all messages to single URL here.

MSRP media lines MUST also be wrapped
inside message/cpim bodies, but may allow several content accompanied by an "accept-types"
attribute. This attribute contains a list of MIME types
inside the wrapper. If the gateway were which are
acceptable to specify the wrapped
types endpoint.

A "*" entry in the accept-types attribute, its peer might attribute indicates that the sender
may attempt to use
those types without the wrapper.
All send content with media types listed in either the accept-types or
accept-wrapped-types attributes MAY include that have not been
explicitly listed. Likewise, an entry with an explicit type and a max-size parameter,
indicating
"*" character as the largest message it is willing to accept of subtype indicates that
type. Max-size refers to the complete message, not the size of sender may attempt to
send content with any one chunk. Senders MUST NOT exceed the max-size limit, if
any, when sending messages subtype of any listed that type. If a type is
listed without the parameter, then no preset size limit exists.

Campbell, et al. Expires January 16, 2005 [Page 24]
Internet-Draft MSRP July 2004

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 receiver receives
an MSRP session request and is identified by able to process the media type, it does so.
If not, it will respond with a URL. These URLs
are negotiated in 415 response. Note that all explicit
entries SHOULD be considered preferred over any non-listed types.
This feature is needed as, otherwise, the SDP exchange. Each SDP offer or answer MUST 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 one or more MSRP URL other types internally. If compound types are
used, the types listed in a path attribute. This the accept-types attribute has may be used both
as the following syntax:

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

where MSRP_URL is an msrp: root payload, or msrps: URL as defined in Section 5.
MSRP URLs included may be wrapped in an SDP offer or answer a listed container type.
Any container types MUST include explicit
port numbers.

An MSRP device uses also be listed in the URL accept-types
attribute.

Occasionally an endpoint will need to determine specify 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 MIME body type that
can only be used if wrapped inside a URL to represent itself, and
send it to listed container type.

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

The semantics for accept-wrapped-types are identical to those of the path value received from
accept-types attribute, with the peer, and uses exception that value as the
target for requests specified types
may only be used when wrapped inside containers. Only types listed
in the resulting session. If the path
attribute received from the peer contains more than one URL, then the
target URL is the rightmost, while the leftmost entry represents the
adjacent hop. If only one entry is present, then it is both accept-types attribute may be used as the peer
and adjacent hop URL. The target path is "root" type for the
entire path attribute
value received body. Since any type listed in accept-types may be used both
as a root body, and wrapped in other bodies, format entries from the peer.

The following example shows
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 SDP offer with
endpoint understands a session URL MIME type in the context 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 one wrapper, it is

Campbell, et al. Expires January 16, February 23, 2005 [Page 25] 23]

Internet-Draft MSRP July August 2004

a=path:msrp://a.example.com:7394/2s93i;tcp

The rightmost URI

assumed to understand it in the path attribute MUST identify the endpoint
that generated the SDP document, or some context of any other location where that
endpoint wishes acceptable
wrappers, subject 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 constraints defined by the endpoint is
currently participating. It SHOULD be hard to guess, and protected
from eavesdroppers. This is discussed in more detail in Section 14.

7.1.2 Path Attributes with Multiple URLs

As mentioned previously, this document describes MSRP for
peer-to-peer scenarios, wrapper types
themselves.

The approach of specifying types that is, when no relays are used. However,
we expect a separate document only allowed inside of
containers separately from the primary payload types allows an
endpoint to describe force the use of relays. In
order certain wrappers. For example, a
CPIM [13] gateway device may require all messages to be wrapped
inside message/cpim bodies, but may allow an MSRP device that only implements several content types
inside the core
specification wrapper. If the gateway were to specify the wrapped
types in the accept-types attribute, its peer might attempt to interoperate with devices that use relays, this
document must include a few assumptions about how relays work.
those types without the wrapper.
An endpoint that uses one or more relays will MAY indicate that by
putting a URL for each device in the relay chain into the SDP path
attribute. The final entry would point maximim size message they wish to
receive using the endpoint itself. The
other entries would indicate each proposed relay, in order. The
first entry would point max-size a-line attribute Max-size refers to the first relay in
complete message, not the chain; that is, size of any one chunk. Senders SHOULD
NOT exceed the
relay to which max-size limit for any message sent in the peer device, or a relay operation on its behalf,
resulting session. However, the receiver should connect.

Endpoints that do not wish to insert consider max-size
value as a relay, including those that do
not support relays at all, will put exactly one URL into the path
attribute. This 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 represents both the Negotiations

Each endpoint for the session,
and the connection point.

While endpoints that implement only this specification will never
introduce in an MSRP session is identified by a relay, they will need to be able to interoperate with
other endpoints that do use relays. Therefore, they MUST be prepared
to receive more than one URL URL. These URLs
are negotiated in the SDP path attribute. When an
endpoint receives more than exchange. Each SDP offer or answer MUST
contain one or more MSRP URL in a path header, only attribute. This attribute has
the first
entry following syntax:

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

where MSRP_URL is relevant for purposes of resolving the address and port, and
establishing the network connection, as it describes the first
adjacent hop.

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

Campbell, et al. Expires January 16, 2005 [Page 26]
Internet-Draft Section 5.
MSRP July 2004

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

An 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 device uses the network, for example, SIP
Session Timers. They may need URL to change some other stream in determine a
session without affecting the MSRP stream, or they may need host address, port,
transport, and protection level when connecting, and to change
an identify the

Campbell, et al. Expires February 23, 2005 [Page 24]

Internet-Draft MSRP stream without affecting some other stream.

Either peer may initiate an updated exchange at any time. August 2004

target when sending requests and responses.

The
endpoint that sends the new offer assumes the role of offerer for all
purposes. The and answerer MUST respond with a path attribute that
represents each selects a valid path URL to represent itself, and
send it to itself at the time of peer device in the SDP document. Each device stores
the updated
exchange. This new path may be value received from the same as its previous path, but
may be different. The new offerer MUST NOT assume peer, and uses that value as the peer will
answer with
target for requests inside the resulting session. If the same path it used previously.
attribute received from the peer contains more than one URL, then the
target URL is the rightmost, while the leftmost entry represents the
adjacent hop. If 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

Campbell, et al. Expires January 16, 2005 [Page 27]
Internet-Draft
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 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 13.

7.1.2 Path Attributes with Multiple URLs

As mentioned previously, this document describes MSRP July 2004

7.1.5 Connection Negotiation

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

An endpoint that uses one or more relays will indicate that by
putting a URL for each device in the relay chain into the SDP path
attribute. The final entry would point to negotiate the direction for any required TCP connection. endpoint itself. The mechanism was
loosely based on
other entries would indicate each proposed relay, in order. The
first entry would point to the COMEDIA [24]work being done first relay in the MMUSIC
working group. The primary motivation was chain; that is, the
relay to allow which the peer device, or a relay operation on its behalf,
should connect.

Campbell, et al. Expires February 23, 2005 [Page 25]

Internet-Draft MSRP sessions August 2004

Endpoints that do not wish to
succeed in situations where the offerer could insert a relay, including those that do
not accept connections
but 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 the typical telephone user
experience, where the callee "answers" the call.

In contrast, the typical user experience relevant for instant messaging
applications is that purposes of resolving the initial received message is immediately
displayed to address and port, and
establishing the user, without waiting for network connection, as it describes the first
adjacent hop.

If an endpoint puts more than one URL in a path attribute, the user to "join" final
URL in the
conversation. Therefore, path (the peer URL) attribute MUST exhibit the principle uniqueness
properties described above. Uniqueness requirements for other
entries in the 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 the DSN taken
from RFC1894 [8]. Only a minimal subset of fields are relevant for
MSRP, as detailed in
endpoint that sends the remainder of this section.

8.1 Per-Message DSN header usage

original-envelope-id: See Section 8.3

reporting-mta: See Section 8.4

dsn-gateway: Not Used

Campbell, et al. Expires January 16, 2005 [Page 28]
Internet-Draft MSRP July 2004

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 new offer assumes the originating MSRP
transaction. role of offerer for all
purposes. The entity generating the DSN report answerer MUST insert the
Message-ID value respond with a path attribute that appeared in the original MSRP request into the
'original-envelope-id' field. This allows
represents a requesting client valid path to
explicitly correlate a REPORT request with itself at the original request.
This correlation is implementation specific and makes no requirements
on clients to hold state for transactions ID's. Information
regarding time of the original request can 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', same o-line as defined in Section 15.4 the previous
exchange.

7.1.4 Example SDP Exchange

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

Campbell, et al. Expires February 23, 2005 [Page 26]

Internet-Draft MSRP August 2004

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 specification.
The 'mta-name' value document included a mechanism to negotiate
the direction for this field as specified in RFC1894 [8] MUST
equal any required TCP connection. The mechanism was
loosely based on the COMEDIA [24] work being done in the MMUSIC
working group. The primary motivation was to allow MSRP URL representing itself sessions to
succeed in situations where the context of offerer could not accept connections
but the session.

8.5 final-recipient

The 'final-recipient-field' MUST follow answerer could. For example, the guidelines set out in RFC
1894[8]. offerer might be behind a
NAT, while the answerer might have a globally routable address.

The 'address-type' SIMPLE working group chose to remove that mechanism from RFC1894 [8] MUST use the value of
'msrp-address-type', MSRP, as defined in Section 15.4
it added a great deal of this

Campbell, et al. Expires January 16, 2005 [Page 29]
Internet-Draft MSRP July 2004

specification. The 'address-type' value for this field as specified
in RFC1894 [8] MUST equal the final value contained in the MSRP
'To-Path' header from the original request.

8.6 action

The 'action' field MUST follow the guidelines set out in RFC 1894[8].
An 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 the
'status' field of a DSN report. An MSRP status code consists of a
three digit number while a DSN status instant messaging
applications is three digits separated by
'.'. An example would be:

Status: 5.0.0 (unknown permanent failure)

When generating this field the first digit of that the MSRP status code
(working from left initial received message is immediately
displayed to right) MUST be placed in the first part of user, without waiting for the
'status' DSN field. The second digit MUST be placed in user to "join" the second
part
conversation. Therefore, the 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

Campbell, et al. Expires February 23, 2005 [Page 27]

Internet-Draft MSRP August 2004

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

Campbell, et al. Expires January 16, 2005 [Page 30]
Internet-Draft MSRP July 2004
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

Campbell, et al. Expires February 23, 2005 [Page 28]

Internet-Draft MSRP August 2004

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 ]

Campbell, et al. Expires January 16, 2005 [Page 31]
Internet-Draft MSRP July 2004
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);

Campbell, et al. Expires February 23, 2005 [Page 29]

Internet-Draft MSRP August 2004

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

Campbell, et al. Expires January 16, 2005 [Page 32]
Internet-Draft MSRP July 2004

10.1 in REPORT requests.

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

Campbell, et al. Expires February 23, 2005 [Page 30]

Internet-Draft MSRP August 2004

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.

Campbell, et al. Expires January 16, 2005 [Page 33]
Internet-Draft MSRP July 2004

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

Campbell, et al. Expires February 23, 2005 [Page 31]

Internet-Draft MSRP August 2004

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

Campbell, et al. Expires January 16, 2005 [Page 34]
Internet-Draft MSRP July 2004
a=path:msrp://bob.example.com:8888/9di4ea;tcp

3. Alice->Bob (SIP): ACK

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$

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$

6. Bob->Alice (MSRP):

Campbell, et al. Expires February 23, 2005 [Page 32]

Internet-Draft MSRP August 2004

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$

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$

8. Alice->Bob (SIP): BYE

Alice invalidates local session state.

10.

9. Bob invalidates local state for the session.

Bob->Alice (SIP): 200 OK

Campbell, et al. Expires January 16, 2005 [Page 35]
Internet-Draft MSRP July 2004

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$

Campbell, et al. Expires January 16, February 23, 2005 [Page 36] 33]

Internet-Draft MSRP July August 2004

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.

Campbell, et al. Expires January 16, February 23, 2005 [Page 37] 34]

Internet-Draft MSRP July August 2004

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

Campbell, et al. Expires January 16, February 23, 2005 [Page 38] 35]

Internet-Draft MSRP July August 2004

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

Campbell, et al. Expires January 16, February 23, 2005 [Page 39] 36]

Internet-Draft MSRP July August 2004

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

Campbell, et al. Expires February 23, 2005 [Page 37]

Internet-Draft MSRP August 2004

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

Campbell, et al. Expires January 16, 2005 [Page 40]
Internet-Draft MSRP July 2004
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

Campbell, et al. Expires February 23, 2005 [Page 38]

Internet-Draft MSRP August 2004

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

Campbell, et al. Expires January 16, 2005 [Page 41]
Internet-Draft MSRP July 2004
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.

Campbell, et al. Expires February 23, 2005 [Page 39]

Internet-Draft MSRP August 2004

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

Campbell, et al. Expires January 16, 2005 [Page 42]
Internet-Draft MSRP July 2004

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

Campbell, et al. Expires February 23, 2005 [Page 40]

Internet-Draft MSRP August 2004

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 a new 'address-type' for use in conjunction
with RFC1894[8]. The authors request section. Removed statements that these values be recorded
in the IANA registry for DSN 'address-type'.

Proposed Address name: msrp-address-type

Campbell, et al. Expires January 16, 2005 [Page 43]
Internet-Draft MSRP July 2004

Syntax: See Section 5

15.4.2 IANA registration form for MTA-name-type

This document registers an error report
SHOULD contain a new 'MTA-name-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 last-byte field in byte-range to "*" if
there is any chance of interrupting a SEND request.
Changed max-size to refer to entire message, instead of a
particular MIME content-type
Added requirent for DSN 'MTA-name-type'.

Proposed Address name: msrp-name-type

Syntax: See Section 5

16. Change History

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

Campbell, et al. Expires February 23, 2005 [Page 41]

Internet-Draft MSRP August 2004

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.

Campbell, et al. Expires January 16, 2005 [Page 44]
Internet-Draft MSRP July 2004
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.

Campbell, et al. Expires February 23, 2005 [Page 42]

Internet-Draft MSRP August 2004

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.

Campbell, et al. Expires January 16, 2005 [Page 45]
Internet-Draft MSRP July 2004
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.

Campbell, et al. Expires February 23, 2005 [Page 43]

Internet-Draft MSRP August 2004

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.

Campbell, et al. Expires January 16, 2005 [Page 46]
Internet-Draft MSRP July 2004
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

Campbell, et al. Expires February 23, 2005 [Page 44]

Internet-Draft MSRP August 2004

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

Campbell, et al. Expires January 16, 2005 [Page 47]
Internet-Draft MSRP July 2004
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.

Campbell, et al. Expires February 23, 2005 [Page 45]

Internet-Draft MSRP August 2004

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

Campbell, et al. Expires January 16, 2005 [Page 48]
Internet-Draft MSRP July 2004

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

Campbell, et al. Expires February 23, 2005 [Page 46]

Internet-Draft MSRP August 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

Campbell, et al. Expires January 16, 2005 [Page 49]
Internet-Draft MSRP July 2004
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)",

Campbell, et al. Expires February 23, 2005 [Page 47]

Internet-Draft MSRP August 2004

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

Campbell, et al. Expires January 16, 2005 [Page 50]
Internet-Draft MSRP July 2004

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

EMail: fluffy@cisco.com

Campbell, et al. Expires January 16, February 23, 2005 [Page 51] 48]

Internet-Draft MSRP July August 2004

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

Campbell, et al. Expires January 16, February 23, 2005 [Page 52] 49]

----