WDIFF

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

Internet-Draft dynamicsoft
Expires: November 15, 2004 May 17, January 16, 2005 R. Mahy
C. Jennings
Cisco Systems, Inc.
July 18, 2004

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

Status of this Memo

This document is an Internet-Draft

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

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on November 15, 2004. January 16, 2005.

Abstract

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

Campbell (Ed.)

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

Table of Contents

1. Introduction Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation for Session-mode Messaging . Introduction and Background . . . . . . . . . . 4
3. Scope of this Document . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . 5
4. Key Concepts . . . . . . . . . . . . . 6
5. SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . . 7
5.1 Use of the SDP M-line . . . 8
4.1 MSRP Framing and Message Chunking . . . . . . . . . . . . 8
4.2 MSRP Addressing . . . 7
5.2 The Accept Types Attribute . . . . . . . . . . . . . . . . 7
5.3 MIME Wrappers . . 11
4.3 MSRP Transaction and Report Model . . . . . . . . . . . . 11
4.4 MSRP Connection Model . . . . . . . . 8
5.4 URL Negotiations . . . . . . . . . . 12
5. MSRP URLs . . . . . . . . . . . 9
5.5 Path Attributes with Multiple URLs . . . . . . . . . . . . 10
5.6 Updated SDP Offers . . 14
5.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . 11
5.7 Example SDP Exchange . 15
5.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 16
6. Method-Specific Behavior . . 11
5.8 Connection Negotiation . . . . . . . . . . . . . . . . 16
6.1 Constructing Requests . . 12
6. The Message Session Relay Protocol . . . . . . . . . . . . . 12
6.1 MSRP URLs . . . 16
6.1.1 Delivering SEND requests . . . . . . . . . . . . . . . 17
6.1.2 Sending REPORT requests . . . . . . 12
6.1.1 MSRP URL Comparison . . . . . . . . . 19
6.1.3 Failure REPORT Generation . . . . . . . . 13
6.1.2 Resolving MSRP Host Device . . . . . . 19
6.2 Constructing Responses . . . . . . . . 14
6.2 Connection Direction . . . . . . . . . . 20
6.3 Receiving Requests . . . . . . . . . 14
6.3 MSRP Messages . . . . . . . . . . . 21
6.3.1 Receiving SEND requests . . . . . . . . . . . 15
6.3.1 Message Framing . . . . 21
6.3.2 Receiving REPORT requests . . . . . . . . . . . . . . 22
7. Using MSRP with SIP . 17
6.3.2 Message Examples . . . . . . . . . . . . . . . . . . . 18
6.4 22
7.1 SDP Offer-Answer Exchanges for MSRP Transactions . . . . . . Sessions . . . . . . . 22
7.1.1 URL Negotiations . . . . . . . 19
6.5 MSRP Sessions . . . . . . . . . . . . 25
7.1.2 Path Attributes with Multiple URLs . . . . . . . . . . 19
6.5.1 Initiating an MSRP session 26
7.1.3 Updated SDP Offers . . . . . . . . . . . . . . 19
6.5.2 Handling the initial request . . . . 27
7.1.4 Example SDP Exchange . . . . . . . . . 21
6.5.3 Sending Instant Messages on a Session . . . . . . . . 21
6.5.4 Ending a Session 27
7.1.5 Connection Negotiation . . . . . . . . . . . . . . . . 28
7.2 MSRP User Experience with SIP . . . 23
6.5.5 Managing Session State and Connections . . . . . . . . 23
6.6 Delivery Status Notification . . . 28
8. DSN payloads in MSRP REPORT Requests . . . . . . . . . . . . 24
6.6.1 Endpoint 28
8.1 Per-Message DSN Request . . header usage . . . . . . . . . . . . . . . 24
6.6.2 28
8.2 Per-Recipient DSN generation . . . . . . . . . . . . . header usage . . . . . . . 25
6.6.3 Receiving positive DSN . . . . . . . 29
8.3 original-envelope-id usage . . . . . . . . . 26
6.6.4 Receiving negative DSN . . . . . . . 29
8.4 reporting-mta . . . . . . . . . 26
6.6.5 DSN headers in MSRP . . . . . . . . . . . . . 29
8.5 final-recipient . . . . 26
6.7 Message Fragmentation . . . . . . . . . . . . . . . . . 29
8.6 action . 28
6.7.1 MSRP Usage of message/byteranges . . . . . . . . . . . 28
6.8 Method Descriptions . . . . . . . . . . . . . . 30
8.7 status . . . . . 29
6.8.1 SEND . . . . . . . . . . . . . . . . . . . . . 30
9. Formal Syntax . . . . 29
6.8.2 VISIT . . . . . . . . . . . . . . . . . . . 30
10. Response Code Descriptions . . . . . 29
6.8.3 REPORT . . . . . . . . . . . . 32
10.1 200 . . . . . . . . . . . . 30
6.9 Response Code Descriptions . . . . . . . . . . . . . . 33
10.2 400 . . 30
6.9.1 200 . . . . . . . . . . . . . . . . . . . . . . . . 33
10.3 403 . 30
6.9.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.9.3 33
10.4 415 . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.9.4 . 33
10.5 426 . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.9.5 . 33
10.6 481 . . . . . . . . . . . . . . . . . . . . . . . . . 30

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

Internet-Draft MSRP May 2004

6.9.6 . 33
10.7 506 . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.10 Header Field Descriptions . 33
11. Examples . . . . . . . . . . . . . . . 30
6.10.1 TR-ID . . . . . . . . . . . 33

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

11.1 Basic IM session . . . . . . . . . . . . 31
6.10.2 Message-ID . . . . . . . . 33
11.2 Chunked Message . . . . . . . . . . . . . 31
6.10.3 To-Path . . . . . . . 36
11.3 System Message . . . . . . . . . . . . . . . 31
6.10.4 From-Path . . . . . . 36
11.4 Positive Report . . . . . . . . . . . . . . . 31
6.10.5 Boundary . . . . . 37
11.5 Forked IM . . . . . . . . . . . . . . . . . 31
6.10.6 Closing . . . . . . 37
12. Extensibility . . . . . . . . . . . . . . . . 31
6.10.7 Content-Type . . . . . . . 40
13. CPIM compatibility . . . . . . . . . . . . . 32
7. Example . . . . . . . . 40
14. Security Considerations . . . . . . . . . . . . . . . . . . 32
8. 40
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34
8.1 42
15.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 34
8.2 42
15.2 MSRP URL Schema . Schemes . . . . . . . . . . . . . . . . . . . . 34
8.2.1 Syntax 42
15.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . 43
15.3.1 Accept Types . . . 34
8.2.2 Character Encoding . . . . . . . . . . . . . . . . . 43
15.3.2 Wrapped Types . 34
8.2.3 Intended Usage . . . . . . . . . . . . . . . . . . 43
15.3.3 Path . . 35
8.2.4 Protocols . . . . . . . . . . . . . . . . . . . . . . 35
8.2.5 Security Considerations 43
15.4 IANA registration forms for DSN types . . . . . . . . . 43
15.4.1 IANA registration form for address-type . . . . . . 35
8.2.6 Relevant Publications . . . . . . . . . . . . . . . . 35
8.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 35
8.3.1 Accept Types . . . . . . . . . . . . . . . . . . . . . 35
8.3.2 Wrapped Types . . . . . . . . . . . . . . . . . . . . 35
8.3.3 Path . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.4 IANA registration forms for DSN types . . . . . . . . . . 36
8.4.1 IANA registration form for address-type . . . . . . . 36
8.4.2 43
15.4.2 IANA registration form for MTA-name-type . . . . . . 44
16. Change History . 36
9. Security Considerations . . . . . . . . . . . . . . . . . . 36
9.1 TLS and the MSRPS Scheme . . . . . . . . . . . . . . . . . 36
9.1.1 Sensitivity of Session URLs . . . . . . . . . . . . . 37
9.1.2 End to End Protection of IMs . . . . . . . . . 44
16.1 draft-ietf-simple-message-sessions-07 . . . . 38
9.1.3 CPIM compatibility . . . . . 44
16.2 draft-ietf-simple-message-sessions-06 . . . . . . . . . 44
16.3 draft-ietf-simple-message-sessions-05 . . . . 38
9.1.4 PKI Considerations . . . . . 45
16.4 draft-ietf-simple-message-sessions-04 . . . . . . . . . 45
16.5 draft-ietf-simple-message-sessions-03 . . . . 38
10. Changes from Previous Draft Versions . . . . . 45
16.6 draft-ietf-simple-message-sessions-02 . . . . . . . 39
10.1 draft-ietf-simple-message-sessions-06 . . 46
16.7 draft-ietf-simple-message-sessions-01 . . . . . . . 39
10.2 draft-ietf-simple-message-sessions-05 . . 46
16.8 draft-ietf-simple-message-sessions-00 . . . . . . . 39
10.3 draft-ietf-simple-message-sessions-04 . . 47
16.9 draft-campbell-simple-im-sessions-01 . . . . . . . 40
10.4 draft-ietf-simple-message-sessions-03 . . . 47
17. Contributors and Acknowledgments . . . . . . 40
10.5 draft-ietf-simple-message-sessions-02 . . . . . . . . 47
18. References . 40
10.6 draft-ietf-simple-message-sessions-01 . . . . . . . . . 41
10.7 draft-ietf-simple-message-sessions-00 . . . . . . . . . 41
10.8 draft-campbell-simple-im-sessions-01 . . . . . . 48
18.1 Normative References . . . . 42
11. Contributors . . . . . . . . . . . . . . . 48
18.2 Informational References . . . . . . . . . 42
12. Acknowledgments . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . 42
13. References . . . . . . . 50
Intellectual Property and Copyright Statements . . . . . . . . . . . . . . . . . . 42
13.1 Normative References . . . . . . . . . . . . . . . . . . . 42
13.2 Informational References . . . . . . . . . . . . . . . . . 43
Author's Address . . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . 45

Campbell (Ed.) 52

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

1. Introduction Conventions

The MESSAGE [12] extension to SIP [2] allows SIP key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be used to
transmit instant messages. Instant messages sent using the MESSAGE
method are normally independent of each other. interpreted as described in RFC-2119 [5].

This approach is
often called page-mode messaging, since it follows a model similar document consistently refers to
that used by many two-way pager devices. Page-mode messaging makes
sense for instant message exchanges where a small number of messages
occur. Endpoints may treat page-mode messages "message" as if they took place
in an imaginative session, but there is no formal relationship
between one a complete unit
of MIME or text content. In some cases a message is split and another.

There are also applications
delivered in which it more than one MSRP request. Each of these portions of
the complete message is useful for instant called a "chunk".

2. Introduction and Background

A series of related textual messages to between two or more parties can
be formally associated in a session. For example, viewed as part of a user
may wish to join session with a text conference, participate in the conference for
some period of time, then leave the conference. definite start and end. This usage
is
analogous in contrast to regular media sessions that are typically initiated,
managed, and terminated using SIP. We commonly refer to this model individual messages each sent completely
independently. The SIMPLE Working Group describes messaging schemes
that only track individual messages as session-mode messaging.

One of the primary purposes "page-mode" messages, whereas
messaging that is part of SIP a "session" with a definite start and SDP (Section 5) end
is called session-mode messaging.

Page-mode messaging is enabled in SIMPLE via the
management of media sessions. SIP [4]MESSAGE
method [19]. Session-mode messaging can be thought has a number of benefits [20]
over page-mode messaging however, such as a explicit rendezvous,
tighter integration with other media session like any other. types, direct client-to-client
operation, and brokered privacy and security.

This document describes the
motivations for session-mode messaging, the Message Session Relay
Protocol, and the use of the SDP offer/answer mechanism for managing
MSRP session.

2. Motivation for Session-mode Messaging

Message sessions offer several advantages over page-mode messages.
For message exchanges that include more than defines a small number of
message transactions, session-oriented instant message transport
protocol (MSRP), whose sessions can be included in an offer or answer
[3] of a way to remove
messaging load from intervening SIP proxies. For session description (for example, SDP [2]). The exchange is
carried by some signaling protocol, such as SIP [4]. This allows a minimal
communication user agent to offer a messaging session setup and tear-down requires one INVITE/ACK transaction, and as one BYE transaction, for a total of 5 SIP messages. Normal SIP
request routing allows for all but the initial INVITE transaction
possible media types in a session. For instance, Alice may want to
bypass any intervening proxies that do not specifically request
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 be
in the path address of
record she has for future requests. Session-mode messages never cross
the Bob, sip:bob@example.com. Her invitation offers
both voice and an IM session. The SIP proxies themselves.

Each page-mode message involves a complete SIP transaction, that is,
a request 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 response. Any page-mode message exchange that
involves more than 2 MESSAGE requests will generate more SIP requests
than a minimal threaded
chat conversation.

This session initiation sequence. Since MESSAGE is
normally used outside of a SIP dialog, these requests will typically
traverse the entire proxy network between the endpoints.

Due model allows message sessions to network congestion concerns, be integrated into
advanced communications applications with little to no additional
protocol development. For example, during the MESSAGE method has

Campbell (Ed.) 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 November 15, 2004 January 16, 2005 [Page 4]
Internet-Draft MSRP May July 2004

significant limitations in message size,

into call-center and dispatch environments utilizing third-party call
control [17] and conferencing [16] applications.

3. Protocol Overview

MSRP is a prohibition against
overlapping requests, etc. Much of this has been required because of
perceived limitations in the congestion-avoidance features of SIP
itself. Work text-based, connection-oriented protocol for exchanging
arbitrary (binary) MIME content, especially instant messages. This
section is in progress to mitigate these concerns.

However, session-mode messages are always sent over reliable,
congestion-safe transports. Therefore, there are no restrictions on
message sizes. There a non-normative overview of how MSRP works and how it is no requirement to wait for acknowledgement
before sending another message, so that message transactions can be
overlapped.

Message
used with SIP.

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

Finally, SIP devices can treat message sessions like any other media
sessions. Any (Bob) a SIP feature that can be applied to other sorts invitation containing an offer
session-description which includes a session of
media sessions can equally apply to message sessions. For example,
conferencing [14], third party call control [15], call transfer [16],
QoS integration [17], and privacy [18] can all be applied to message
sessions.

Messaging sessions MSRP. The receiving
SIP user agent can also reduce accept the overhead in each individual
message. In page-mode, each message needs to invitation and include all of an answer
session-description which acknowledges the SIP
headers that are mandated by RFC 3261 [2]. However, many choice of these
headers are not needed once a context is established for exchanging
messages. As a result, messaging media. Alice's
session mechanisms can be designed
with significantly less overhead.

3. Scope of this Document

This document describes the use of MSRP between endpoints. It does
not specify the use of intermediaries, nor does it prohibit such use.
We expect description contains an extension to this specification to define MSRP
intermediaries and their use.

This document URL that describes the use of MSRP over TCP. where she is
willing to receive MSRP may be used
over other congestion-controlled protocols such as SCTP. However, requests from Bob, and vice-versa. (Note:
Some lines in the specific bindings for other such protocols examples are outside the scope
of this document.

Campbell (Ed.) removed for clarity and brevity.)

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

4. Protocol Overview

The Message Session Relay Protocol (MSRP) provides a mechanism for
transporting session-mode messages between endpoints. MSRP uses
connection oriented, reliable network transport protocols only. It
can operate in the presence of many NAT and firewall environments, as
it allows participants

Alice sends to positively associate message sessions with
specific connections, and does not depend upon connection source
address, which may be obscured by NATs.

MSRP uses the following primitives:

SEND: Used 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 send message content from one endpoint 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 another.

VISIT: Used by an endpoint 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 establish deliver a session association to the
host endpoint. complete message or a chunk (a portion of a complete
message), while REPORT Used requests report on the status of an earlier
SEND request. When Alice receives Bob's answer, she checks to carry MSRP message report/receipt information.

Assume A is see if
she has an endpoint that wishes existing connection to establish Bob. If not, she opens a message session,
and B is the endpoint invited by A. A invites B new
connection to participate in a
message session by sending a URL. This URL is temporary, and must
not duplicate any Bob using the URL that A has offered for other active sessions.

B he provided in the SDP. Alice then responds
delivers a SEND request to the invitation Bob with a URL of its own. This
informs A her initial message, and Bob
replies indicating that B has accepted Alice's request was received successfully.

Campbell, et al. Expires January 16, 2005 [Page 6]
Internet-Draft MSRP July 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 session, and will accept messages
at MSRP start line, which contains a
transaction identifier that URL. A connects to B, and sends is also used as a request final boundary marker.
Next she includes the path of URLs to establish the
session. A destination in the To-Path
header, and B may now exchange messages using SEND requests on her own URL in the connection. Each party targets such requests 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 peer's URL.

When either party wishes to original message.
Next she puts the actual content. Finally she closes the request
with an end line: seven hyphens, the session, it informs its peer
using transaction identifier /
boundary marker and a "$" to indicate this request contains the appropriate mechanism end
of a complete message.

If Alice wants to deliver a very large message, she can split the chosen signaling protocol,
such as
message into chunks and deliver each chunk in a SIP BYE separate SEND
request. The end message ID corresponds to end case looks something like the following. (Note that whole message, so the example shows a logical flow only; syntax will come later in this
document.)

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

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

Internet-Draft MSRP May 2004

5. SDP Offer-Answer Exchanges for MSRP Sessions

MSRP sessions will typically be initiated using
receiver can also use it to reassemble the Session
Description Protocol (SDP) [1] offer-answer mechanism, carried message and tell which
chunks belong with which message. Chunking is described in the
Session Initiation Protocol (SIP) [2] or any other protocol
supporting it.

5.1 Use of the SDP M-line

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

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

For non-RTP media sessions, The media field specifies the top level
MIME media more
detail in Section 4.1.

Alice can also specify what type for the session. For MSRP sessions, the media field
MUST have the value of "message". The port field is normally not
used, and MAY be set reporting she would like in
response to any value chosen by her request. If Alice requests positive
acknowledgements, Bob sends a REPORT request to Alice confirming the endpoint. A port
field value
delivery of zero has the standard SDP meaning. Non-zero values
MUST not be repeated 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 other
Section 4.3.

Alice and Bob generally choose their MSRP m-lines URLs in the same SDP document.

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

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

The port field in can correlate the M-line is not used to determine
specific URL with the port to
which probable sender. Alice and Bob can also use
TLS [1] to connect. Rather, provide channel security over this hop. To receive MSRP

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

requests over a TLS protected connection, Alice or Bob could
advertise URLs with the actual port "msrps" scheme instead of "msrp."

This document specifies MSRP behavior only peer-to-peer session, that
is, for a single hop. But is determined by the designed with the expectation that MSRP URL (Section 6.1) in
can carry URLs for nodes on the path attribute. However, far side of gateways or relays. For
this reason, a port value URL with the "msrps" scheme makes no assertion about
the security properties of zero has other hops, just the normal SDP meaning.

The following next hop.

MSRP URLs are discussed in more detail in Section 5.

An adjacent pair of busy MSRP nodes (for example illustrates an m-line 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 message session, 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 endpoint 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 willing used to accept root payloads indicate the end of message/
cpim, plain text or HTML. The second two types could either be
presented as the root body, 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 could whether the message will be contained within message/cpim
bodies.

m=message 9999 msrp *

5.2 The Accept Types Attribute

MSRP can carry any MIME encoded payload. Endpoints specify MIME
content types that they are willing to receive continued in a subsequent
chunk. There is also a Byte-Range header in the accept types
"a"-line attribute. This attribute has request that
indicates the overall position of this chunk inside the complete
message.

For example, the following syntax:

Campbell (Ed.) snippet of two SEND requests demonstrates
a message that contains the text "abcdEFGH" being sent as two chunks.

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

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

SDP offers for

MSRP sessions MUST include an accept-types attribute.
SDP answers MUST also include dkei38sd SEND
Message-ID: 456
Byte-Range: 1-4/8
Content-Type: "text/plain"

abcd
-------dkei38sd+

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

EFGH
-------dkei38ia$

The receiver uses the attribute, value of the Message-ID header to determine
which of multiple chunks belong to the same message. The Message-ID
header MUST contain
either have the same list as value for each chunk in the offer or same message,
and a subset of that list.

A "*" entry in the accept-types attribute indicates that the sender
may attempt to send messages with media types MUST ensure that have not been
explicitly listed. If the receiver message ID is able to process unique for each of
the media
type, it does so. If not, messages it will respond with sends within a 415. Note particular session.

The boundary marker that all
explicit entries SHOULD be considered preferred over any non-listed
types. This feature is needed as, otherwise, terminates the list of formats for
rich IM devices may body MUST be prohibitively large.

The accept-types attribute may include container types, that is, mime
formats preceded by a
CRLF that contain other types internally. If compound types are
used, is not part of the types listed in body and then seven "-" (minus sign)
characters. After the accept-types attribute may be used both
as boundary marker, there MUST be a flag
character that is either a "$" (for the root payload, last chunk of the message) or may
"+" (for chunks other than the last). If the chunk represents the
data that forms the end of the message, the flag MUST be wrapped in a listed container type.
(Note that "$",
otherwise the container type flag MUST also be listed in a "+".

The Byte-Range header value contains a starting value followed by a
"-", an ending value followed by a "/", and finally the accept-types
attribute.)

5.3 MIME Wrappers total length.
The MIME content-types starting value indicates the index into the message where the
first byte in the accept-types attribute will often
include container types; that is, types that contain other types.
For example, "message/cpim" or "multipart/mixed." Occasionally an
endpoint will need to specify a MIME body type that can only be used
if wrapped inside a listed container type.

Endpoints MAY specify MIME types that are only allowed to be wrapped
inside compound types using current chunk belongs. The index of the "accept-wrapped-types" attribute first
octet in
an SDP a-line. This attribute has the following syntax:

accept-wrapped-types = wrapped-types-label ":" format-list
wrapped-types-label = "accept-wrapped-types" ` complete message is ONE, not zero. The format-list element has ending value
indicates the identical syntax as defined for location where the
accept-types attribute. last octet belongs. The semantics for this attribute are
identical to those body MAY
contain less data than is indicated by the end but it MUST NOT
contain more octets than indicated. The length indicates the number
of octets in the accept-types attribute, with complete message. Both the exception
that ending value and length
MAY have the specified types may only be used when wrapped inside
containers. Only types listed value of "*" in accept-types may be used as the
"root" type for some or all of the entire body. Since any type listed in
accept-types may chunks, to indicate
that they are not specified. If no Byte-Range header is present, the
SEND request MUST be used both treated as if there was a root body, and wrapped in other

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

Internet-Draft MSRP May 2004

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

This approach does not allow for specifying distinct lists of
acceptable wrapped types for different types of containers. If an
endpoint understands Byte-Range header
present with a MIME type in the context value of one wrapper, it is
assumed "1-*/*".

This chunking mechanism allows a sender to understand interrupt a chunk part way
through sending it in by writing out the context of any other acceptable
wrappers, subject boundary termination and the
"+" flag to any constraints defined by indicate that the wrapper types
themselves.

The approach end of specifying types that are only allowed inside this chunk is not the end of
containers separately from the primary payload types
complete message. The ability to interrupt messages allows an
endpoint multiple

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

sessions to force the use of certain wrappers. For example, share a
CPIM gateway device may require all TCP connection, and for large messages to be wrapped inside
message/cpim bodies, but may allow several content types inside
the wrapper. If the gateway were to specify the wrapped types in sent
efficiently while not blocking other messages that share the accept-types attribute, its peer could choose 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 those
types without the wrapper.

5.4 URL Negotiations

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

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

where MSRP_URL two strategies
to satisfy this requirement. The sender is an MSRP or MSRPS URL as defined in Section 6.1.
MSRP URLs included in an SDP offer or answer MUST include an explicit
port number.

A device uses the URL STRONGLY RECOMMENDED to determine a host address and port
send messages larger than 2048 octets using as few chunks as
possible, interrupting chunks (at least 2048 octets long) when
connecting, and other
traffic is waiting to identify use the target when sending messages. For
MSRP sessions, same connection. Alternatively, the address field
sender MAY simply send chunks in 2048 octet increments until the C-line is not relevant, and
MUST be ignored. The port field
final chunk. Note that the former strategy results in markedly more
efficient use of the M-line connection. All MSRP nodes MUST be ignored if
non-zero. Zero values have able to
receive chunks of any size from 0 octets to the usual meaning maximum number of
octets they can receive for SDP.

A device a complete message. Senders SHOULD NOT
break messages into chunks smaller than 2048 octets, except for the
final chunk of a complete message.

Receivers MUST not assume the chunks will further use be delivered in order or
that they will receive all the URL to determine chunks with "+" flags before they
receive the transport
protocol, and whether to use TLS. This chunk with the "$" flag. In certain cases of connection
failure, it is possible for information to be duplicated. If chunks
data is encoded in received that overlaps already received data for the
URL scheme.

Both offerer and answerer store same
message, the path values last chunk received from takes precedence (even though this
may not have been the
peer. last chunk transmitted). For a given endpoint, the local URL example, if bytes
1 to 100 was received and a chunk arrives that contains bytes 50 to
150, this second chunk will overwrite bytes 50 to 100 of the data
that had already been received. Although other schemes work, this is
the URL easiest for the receiver and results in consistent behavior
between clients.

The seven "-" before the boundary are used so that the
endpoint put into receiver can
search for the value "----", 32 bits at a SDP path attribute time to represent itself. The peer
URL is find the URL sent by probable
location of the peer boundary. This allows most processors to represent itself. If locate the path
attribute received from
boundaries and copy the peer contains more than one URL, then memory at the
peer URL same rate that a normal memory
copy could be done. This approach results in a system that is as
fast as framing based on specifying the rightmost, while body length in the leftmost entry represents headers of
the

Campbell (Ed.) request, but also allows for the interruption of messages.

The ability to interrupt messages 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 that have a very large number of concurrent connections to
different users.

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

adjacent hop. If only one entry is present, then it is both the peer
and adjacent URL.

4.2 MSRP Addressing

MSRP entities are addressed using URLs. The remote path is MSRP URL schemes are
defined in Section 5. The syntax of the entire path attribute value
received from To-Path and From-Path
headers allow for a list of URLs. This was done to allow the peer.

The following example shows an SDP offer
protocol to work with gateways or relays defined in the future, to
provide a session URL of
"msrp://a.example.com:7394/2s93i"

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

The rightmost URI in the complete path attribute MUST identify the endpoint
that generated the SDP document, or some other location where that
endpoint wishes to receive messages associated with the session. It
MUST MUST be a temporary end recipient. When two MSRP nodes
communicate directly they need only one URL assigned just for this particular
session, in the To-Path list and MUST NOT duplicate any
one URL in use for any other session
in which the endpoint is currently participating. Further, it SHOULD
be hard to guess, From-Path list.

4.3 MSRP Transaction and protected from eavesdroppers. This will be
discussed in more detail in Section 9.

5.5 Path Attributes with Multiple URLs

As mentioned previously, this document describes Report Model

A sender sends MSRP for
peer-to-peer scenarios, that is, when no relays are used. However,
we expect a separate document requests to describe a receiver. The receiver MUST
quickly accept or reject the use of relays in request. If the
near future. In order receiver initially
accepted the request, it still may then do things that take
significant time to allow succeed or fail. For example, if the receiver is
an MSRP device that only implements
the core specification to interoperate with devices XMPP [29] gateway, it may forward the message over XMPP.
The XMPP side may later indicate that use relays,
this document must include a few assumptions about how relays the request did not work.

An endpoint that uses one or more relays will At
this point, the MSRP receiver may need to indicate that the request
did not succeed. There are two important concepts here: first, the
hop by
putting a URL for each device in hop delivery of the relay chain into request may succeed or fail; second, the SDP path
attribute. The final entry would point to
end result of the endpoint itself. The
other entries would indicate each proposed relay, in order. request may be successfully processed or not. The
first entry would point type of status is referred to the first relay as "transaction status" and may
be returned in the chain; that is, the
relay response to which the peer device, or a relay operation on its behalf,
should connect.

Endpoints that do not wish request. The second type of status is
referred to insert a relay, including those that do
not support relays at all, will put exactly one URL into the path
attribute. This URL represents both the endpoint for the session, as "request status" and the connection point.

While endpoints that implement only this specification will never
introduce may be returned in a relay, REPORT
transaction.

The original sender of a request can indicate if they will need to be able wish to interoperate with

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

Internet-Draft MSRP May 2004

other endpoints receive
reports for requests that do use relays. Therefore, fail, and can independently indicate if
they MUST be prepared wish to receive more than one URL in reports for requests that succeed. A receiver
only sends a success REPORT if it knows that the SDP path attribute. When an
endpoint receives more than one URL in request succeeded,
and the sender requested a path header, success report. A receiver only sends a
failure REPORT if the first
entry is relevant for purposes of resolving the address and port, request failed and
establishing the network connection, as it sender requested failure
reports.

This document describes the first
adjacent hop.

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

5.6 Updated SDP Offers

To do: Revisit this section based on new connection management rules MSRP endpoints may sometimes need endpoints. MSRP
relays or gateways are likely to send have additional SDP exchanges
for an existing session. They may need to send periodic exchanges
with no change conditions that
indicate a failure REPORT should be sent, such as the failure to refresh state in
receive a positive response from the network, for example, SIP
timers. They may need next hop.

Two header fields control the sender's desire to change some other stream in receive reports.
The header "Report-Success" can have a session
without affecting value of "yes" or "no" and the MSRP stream,
"Report-Failure" header can have a value of "yes", "no", or they may need to change an MSRP
stream without affecting some other stream.
"partial".

If either party wish the value of "Report-Failure" is set to send an SDP document that changes nothing at
all, "yes", then it the sender of
the request runs a timer. If a 200 response to the transaction is
not received within 30 seconds from the time the last byte of the

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

transaction is sent, the element MUST have inform the same o-line version as in user that the previous
exchange.

5.7 Example SDP Exchange

Endpoint A wishes
request probably failed. If the value is set to invite Endpoint B "partial", then the
element sending the transaction does not have to run a MSRP session. A offers timer, but
MUST inform the following session description:

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

B responds with its own URL:

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

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

Internet-Draft MSRP May 2004

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

A immediately sends some MSRP traffic: Either user if receives a VISIT request (if it
has no immediate content non-recoverable error response to send) or
the transaction.

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

A and B may now exchange IMs by
executing SEND transactions.

5.8 Connection Negotiation

Previous versions consequence of this document included is that if an MSRP element receives a mechanism to negotiate
the direction for any required TCP connection. The mechanism was
loosely based on COMEDIA [20]work being done in request
that has the MMUSIC working
group. The primary motivation was Report-Failure header set to allow MSRP sessions a value of "no", it SHOULD
NOT send any responses to succeed
in situations where this request, because the offerer could element sending
the request would not accept connections but do anything with the
answerer could. For example, resulting response. If
the offerer might be behind value is "partial", it SHOULD NOT send a NAT,
while 200 response to the answerer might have
request, but SHOULD send a globally routable address.

The SIMPLE working group chose to remove that mechanism from MSRP, as non-200 class response if appropriate.

If no Report-Success header is present in a SEND request, it added MUST be
treated the same as a great deal Report-Success header with value of complexity to connection management.
Instead, MSRP now specifies default connection directions.

6. The Message Session Relay Protocol

The Message Session Relay Protocol (MSRP) "no". If
no Report-Failure header is a text based, message
oriented protocol for present, it MUST be treated the transfer same as a
Report-Failure header with value of instant messages in "yes". REPORT requests MUST have
the context
of a session. MSRP uses same Message-ID header value as the UTF8 character set.

MSRP messages MUST be sent over a reliable, congestion-controlled,
connection-oriented transport protocol. This document specifies request they are reporting
on. They MAY also have the
use Byte-Range of the chunk they are
reporting on. If an MSRP over TCP. Other documents may specify bindings element receives a REPORT for other
such protocols.

6.1 MSRP URLs

An MSRP URL follows a subset of Message-ID
it does not recognize, it SHOULD silently ignore the URL syntax in Appendix A of
RFC2396 [4], with a scheme of "msrp":

msrp_url = msrp-scheme "://" [userinfo "@"] hostport ["/"
resource]
msrp-scheme = "msrp" / "msrps" / "smsrp" / "smsrps"
resource = 1*unreserved

The constructions for "userinfo", "hostport", REPORT.

Report-Success and "unreserved" are
detailed Report-Failure MUST NOT be present in RFC2396 [4].

An MSRP URL server part identifies a participant REPORT
request. MSRP nodes MUST NOT send REPORT requests in an response to
report requests. MSRP session.
If the server part contains a numeric IP address, it Nodes MUST also

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

Internet-Draft NOT send MSRP May 2004

contain a port. The resource part identifies a particular session
the participant. responses to REPORT
requests.

The absence combinations of the resource part indicates a
reference to an MSRP host device, reporting may seem overly complex but does not specifically refer they are
needed to
a particular session resource.

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

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

This document only describes the binding for MSRP over TCP. The
schema for SCTP are reserved herein, but binding MSRP various scenarios of currently deployed IM
systems. Report-Success might be "no" in many public systems to SCTP
reduce load but is
out of scope for this document.

MSRP has an IANA registered recommended port defined used in Section 8.1.
This some current enterprise systems, such as
systems used for securities trading. A Report-Failure value of "no"
is not a default, useful for sending system messages such as the URL process described herein will
always explicitly resolve "the system is going
down in 5 minutes" without causing a port number. However, the URLs SHOULD be
configured so that response explosion to the recommended port
sender. A Report-Failure of "yes" is used whenever appropriate.
This makes life easier for network administrators who need by many systems that wish
to manage
firewall policy for MSRP.

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

4.4 MSRP URL. Furthermore, Connection Model

When MSRP wishes to send a userinfo
part MUST NOT contain password information.

The following is an example of request to a typical MSRP URL:

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

6.1.1 peer identified by an MSRP URL Comparison

Campbell, et al. Expires January 16, 2005 [Page 12]
Internet-Draft MSRP URL comparisons MUST be performed according to the following
rules:

1. The schema must match exactly.

2. The host part is compared as case insensitive.

3. If the port exists explicitly in either July 2004

URL, then it must match
exactly. An URL first needs a connection, with an explicit port is never equivalent the appropriate security
properties, to
another with no port specified.

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

4. The resource part is compared as case insensitive. A URL without the host specified in the URL. If the sender already
has such a resource part is never equivalent to connection, that is, one associated with the same host,
port, and URL scheme, then it SHOULD reuse that includes connection.

When a
resource part.

5. Userinfo parts are not considered for URL comparison.

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

6.1.2 Resolving MSRP Host Device

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

If
element that sent the server part contains a numeric IP address and port, they SDP offer MUST
be used as listed.

If the server part contains a host name and immediately issue a port, SEND request
to the connecting
device MUST determine answerer. This request MAY have a host address by doing an A empty body, or AAAA DNS query,
and use the port as listed.

If MAY carry
content.

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

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

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

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

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

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

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

Internet-Draft MSRP May 2004

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

Other signaling protocols may not already in use other approaches. Unless specific
behavior is specified for a particular signaling protocol, the
offerer is always responsible for opening the
on another connection.
Open Issue: Should we put in If so, it MUST reject the request with a hook to allow SDP extensions to be
used to determine connection direction? For example, if COMEDIA
evolves 506
response.

If it were legal to have multiple connections associated with the
same session, a point where it security problem would exist. If the initial SEND
request is workable for MSRP, why not allow
using it?

In all cases, the connecting endpoint connects to the device and port
indicated by protected, an eavesdropper might learn the connection URL, using the protocol and protection
level specified by
use it to insert messages into the URL scheme. session via a different
connection.

If it determines that it already
has a connection fails for any reason, then an MSRP endpoint MUST
consider failed any sessions associated with a URL that has a matching scheme,
host part, and port, it SHOULD reuse that the connection rather than
opening as well.
When an endpoint notices such a failure, it SHOULD attempt to
re-create any such sessions using a new one. Once SDP exchange. If a connection has succeeded, or the decision

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

replacement session is successfully created, endpoints MAY attempt to reuse a connection has been made,
resend any content for which delivery on the connecting device original session could
not be confirmed. If it does this, the Message-ID values for the
resent messages MUST
immediately send an MSRP request match those used in the context of initial attempts. If
the new session.
This receiving endpoint receives more than one message allows with the device accepting same
Message-ID. It SHOULD assume that the connection messages are duplicates. It
MAY take any action based on that knowledge, but SHOULD NOT present
the duplicate messages to associate the MSRP 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 with and the connection. This
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 SEND request, if connection fails, the device has content sender SHOULD attempt to send immediately, or a VISIT request.

Open Issue: We are still discussing whether re-setup the offerer URL
path using a new offer, for example, in a SIP re-invite or update
[13]. It MUST not assume that the
answerer should new URLs in the SDP will be responsible for connecting.

Either endpoint MAY tear down a the
same as the old ones. A connection when it no longer has any
active or proposed SHOULD not be closed while there
are sessions associated with the that are using this connection.

6.3 MSRP Messages

5. MSRP messages are either requests or responses. Requests and
responses are distinguished from one another by the first line. The
first line of URLs

An MSRP URL follows a Request takes the form subset of the request-start entry
below. Likewise, the first line URL syntax in Appendix A of
RFC2396 [11], with a response takes the form scheme of
response-start. The syntax for an MSRP message is as follows:

msrp-message "msrp" or "msrps":

MSRP_urls = request-start/response-start *(header CRLF)
[CRLF body] Closing
request-start msrp-scheme "://" [userinfo "@"] hostport ["/"
resource] ";" transport
msrp-scheme = "MSRP" SP Method CRLF
response-start "msrp" / "msrps"
resource = "MSRP" SP Status-Code SP
Reason CRLF

Method 1*unreserved
transport = SEND "tcp" / VISIT / other-method
other-method = 1*(ALPHA)

Campbell (Ed.) token

The constructions for "userinfo", "hostport", and "unreserved" are
detailed in RFC2396 [11]. 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 identifies a participant in an MSRP session.

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

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

Status-Code = 200 ;Success
/ 400 ;Bad Request
/ 403 ;Forbidden
/ 415 ;Unsupported Content Type
/ 426 ;Upgrade Required
/ 481 ;No

If the server part contains a numeric IP address, it MUST also
contain a port. The resource part identifies a particular session
/ 506 ;duplicate
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
/ other-status ; extension codes
other-status = 3(NUM)

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

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

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

Content-Type = "Content-Type" ":" media-type
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
parameter = attribute "=" value
attribute = token resource.

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

MSRP has an IANA registered recommended port defined in Section 15.1.
This value = token | quoted-string

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

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

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

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

Internet-Draft MSRP May 2004

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

All requests and responses MUST contain at least not a TR-ID header
field. All requests must also contain the To-Path and From-Path,
Message-ID, and Boundary header fields, as well default, as the Closing field.
Messages MAY contain other fields, depending on URL negotiation process described
herein will always include explicit port numbers. However, the method or
response code.

6.3.1 Message Framing

MSRP messages are framed using URLs
SHOULD be configured so that the Boundary header field value. The
Boundary header field contains a boundary string. recommended port is used whenever
appropriate. This makes life easier for network administrators who
need to manage firewall policy for MSRP.

The Closing field
contains the same boundary string with a prefix of "-------" (seven
hyphens) and single character suffix representing server part will typically not contain a continuation
flag.

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

The boundary string MUST NOT occur inside same thing as identifying the body session
itself. The
sender MUST ensure that If a collision does not occur.

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

The MSRP boundary strings are distinct and independent from any MIME
boundaries that may exist in the message body. For example, if the
body is of a multipart type, the MIME headers will include a
multipart boundary. This multipart boundary escape processing.
Escaping MUST NOT be the same
string used in the an MSRP Boundary header field. URL. Furthermore, a userinfo
part MUST NOT contain password information.

The Closing field contains both the message boundary string and 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
Continuation-Flag. following
rules:

1. The Continuation-Flag indicates whether the
entire content has been sent or not. Normally, the flag takes scheme must match exactly.

2. The host part is compared as case insensitive.

3. If the

Campbell (Ed.) 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 November 15, 2004 January 16, 2005 [Page 17] 15]
Internet-Draft MSRP May July 2004

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

6. Userinfo parts are not considered for URL comparison.

Path normalization is additional content that has not yet been sent.

The term "content" in this context means a complete logical instant
message, from relevant for MSRP URLs. Escape
normalization is not required, since the relevant parts are limited
to unreserved characters.

5.2 Resolving MSRP Host Device

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

If the user. The content could be server part contains a
short text message, numeric IP address and port, they MUST
be used as listed.

If the server part contains a long file transfer, etc. The logical instant
message does not necessarily correspond one-to-one with host name and a physical
MSRP message. For example, port, the connecting
device MUST determine a video message may be one logical
instant message from host address by doing an A or AAAA DNS query,
and use the users' perspective, but it will generally be
sent port as listed.

If a series of parcels. Each parcel would be sent as the
payload in one physical MSRP SEND request. All connection attempt fails, the requests except device SHOULD attempt to connect
to the final one would contain "+" addresses returned in any additional A or AAAA records, in the continuation-flag to indicate
order the records were presented.

This process assumes that the content connection port is not complete. The final message would contain
"$" always known
prior to indicate resolution. This is always true for the MSRP URL uses
described in this document, that complete content has been sent. is, URLs always created and
consumed by automata, rather than by humans. The sender MUST NOT include a completion-flag introduction of "+" if the payload
MIME type does not support content fragmentation.

6.3.2 Message Examples

The following
relays may create situations where this is an example not the case. For
example, the MSRP message sending URL that a text payload:

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

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

The following is an example of an MSRP message containing user enters into a MIME type
that uses an internal boundary (not client to
configure it to use a relay may be intended to be confused with 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
boundary):

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

--abcde
Content-Type: image/jpeg

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

Internet-Draft MSRP May 2004

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

6.4 MSRP Transactions

An devices MAY use other methods for discovering other such
devices, when appropriate. For example, MSRP transaction consists endpoints may use other
mechanisms to discover relays, which are beyond the scope of exactly one request and one response.
A response matches this
document.

6. Method-Specific Behavior

6.1 Constructing Requests

To form a transaction if new request, the following are true:

It shares sender creates a unique transaction
identifier and uses this and the same TR-ID value.
It is received on method name to create an MSRP
request start line. Next, the same connection on which sender places the request was
sent.
The To-Path has target path in a single entry, which matches the response
recipient's local URI for
To-Path header, and the session.

Endpoints MUST select TR-ID header field values sender's URL in requests so that
they a From-Path header. If
multiple URLs are not repeated by the same endpoint present in scope of the given
session. TR-ID values SHOULD be globally unique. The TR-ID space of
each endpoint To-Path, the leftmost is independent of that of its peer. Endpoints MUST NOT
infer any semantics from the TR-ID header field beyond what first
URL visited; the rightmost URL is stated
above. In particular, TR-ID values 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 not required to follow added as described in the following sections.

After any
sequence.

MSRP Transactions complete when method-specific headers are added, processing continues to
handle a response is received, or after body, if present. A body in a
timeout interval expires with no response. Endpoints Non-SEND request MUST treat such
timeouts in exactly NOT be
longer than 2048 octets. If the same way they would treat request has a 500 response. body, it must contain
a Content-Type header field. It may contain other MIME specific
headers. The timeout interval SHOULD Content-Type header MUST be 30 seconds, but other values may the last header line. The
body MUST be
established as a matter of local policy.

6.5 MSRP Sessions

AN MSRP session is a context in which a series of instant messages
are exchanged, using SEND requests. A session has two endpoints,
identified by MSRP URLs.

6.5.1 Initiating an MSRP session

When an endpoint wishes to engage a peer in a message session, it
invites separated from the peer to communicate using headers with an SDP offer, carried over SIP
or some other protocol supporting the SDP offer/answer model. For
the purpose of this document, we will refer to the endpoint choosing
to initiate communication as the offerer, and the peer being invited
as the answerer.

Under normal circumstances, extra CRLF.

If the answerer MUST be prepared to accept request contains a connection from body, the offerer.

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

Internet-Draft MSRP May 2004

The offerer sender MUST perform check the following steps:

1. Construct a MSRP URL body to serve as
insure that the local URL.

2. Construct an SDP offer as described in Section 5, including closing sequence (a CRLF, seven hyphens, and the
list of allowed IM payload formats
transaction identifier) is not present in the accept-types attribute.
The offerer puts its local URL into body. If the path attribute, as
described closing
sequence is present in Section 5.4. This URL becomes the offerer's local
path.

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

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

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

2. Construct choose a MSRP URL new
transaction identifier that resolves to itself. Save this as is not present in the
local URL for body, and add the session.

3. Listen for a connection on
closing sequence, including the transport, address, "$" or "+" character, and port
described by the local URL.

4. Send a SDP answer via the signaling protocol, according to 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
following rules:

1. The C-line final header.

Once a request is copied unmodified from the offer.

2. The accept-types attribute contains ready for delivery, the SEND payload media
types that sender follows the answerer is willing
connection management (Section 4.4) rules to accept. The
accept-types attribute in forward the answer 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 either unique within the same
as that scope of the offer, or a subset.

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

Again, this document assumes that no relays are introduced.
session. If the answerer were to introduce one message is larger than 2048 octets in length, it
either generates an interruptible chunk (which is RECOMMENDED), or more relay, it would add the
appropriate URLs to the path attribute in
MAY break the SDP answer. complete message into chunks of 2048 octets. It
would not need to listen for then
generates a connection, as SEND request for each chunk, following the first relay in
its path would have that honor.

When procedures
for constructing requests (Section 6.1).

Each chunk MUST contain a Message-ID header field containing the offerer receives
Message-ID. If the answer, sender wishes non-default status reporting, it
MUST perform the following
steps:

1. Save insert a Report-Failure and/or Report-Success header field with
an appropriate value. All chunks of the path attribute contents from same message MUST use the SDP answer as the
remote path.

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

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

3. Check to see if a connection already exists that is associated
with URL that matches the scheme, host part,
same Report-Failure and port of the
adjacent-hop URL. Report-Success values in their SEND requests.

If such a connection exists, success reports are requested, the sending device SHOULD
reuse it, rather than opening a new connection.

4. If no matching connection exists, attempt MAY wish to open run
a connection to
the adjacent hop using the transport, address, port, timer of some value that makes sense for it's application and
protection mode designated by the adjacent-hop URL.

5. If the connection succeeds, or take
action if a connection success Report is reused,
immediately send a MSRP request to the opposite peer. This
SHOULD not received in this time. There is no
universal value for this timer. For many IM applications, it may be a visit request, but MAY
2 minutes while for some trading systems it may be under a SEND request second.
Regardless of whether such a timer is used, if the
endpoint success report has legitimate content to send.

6.5.2 Handling
not been received by the time the session is ended, the initial request

An MSRP device that accepts a network connection will receive an
immediate SHOULD

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

inform the connecting endpoint. This may be a
SEND or VISIT request. When an endpoint receives such user.

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

1. Check if state exists for a session with a local URL that matches position of the To-Path header first byte in the body in the overall
message. The range-end field value SHOULD indicate the position of the VISIT request. If so, and
if no previous request has been received for that URL on a
different connection, then return a 200 response, and save state
associating the first URL
last byte in the From-Path header field with the
connection on which body, if known. It MUST take the request was received .

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

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

6.5.3 Sending Instant Messages on a Session

Once a MSRP session has been established, either endpoint may send
instant messages to its peer using position is unknown, or if the SEND method. When an endpoint
wishes to do so, it MUST construct a SEND request according needs to the
following process:

1. Insert a To-Path header be interruptible.
The total field containing SHOULD contain the path to total size of the opposite
endpoint, in order from left to right.

2. Insert message, if
known. The total filed MAY contain a From-Path header field containing "*" if the local URL.

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

Internet-Draft MSRP May 2004

3. Insert total size of the
message payload is not known in advance. All chunks other than the body, and the media type last MUST
include a "+" character in the
Content-Type header field. The media type MUST match one continuation field of the
types closing
line. The final chunk MUST use a "$" character. The sender MUST
send all chunks in Byte-Range order. (However,the receiver cannot
assume the format list negotiated requests will be delivered in order, as an intervening
relay may have changed the SDP exchange. order.)

If a
"*" was present in the accept-types attribute, then the media
type SHOULD match one of the explicitly listed entries, but MAY
be any other arbitrary value.

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

5. Send send a body larger than 2048 octets in a
single chunk, the request on the connection associated MUST be constructed so that it can be
interrupted. A SEND request is interruptible if it either has no
Byte-Range header field, or has such a field with the session.

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

7. If
last-byte sub-field.

A SEND request is interrupted while a 415 response body is received, this indicates in the recipient is
unable or unwilling to process the media type. The sender SHOULD
NOT attempt of being
written to send that particular media type again in the
context connection by simply noting how much of this session.

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

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

When an endpoint receives a SEND request, it MUST perform Byte-Range header range
start field containing the
following steps.

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

2. Determine that it understands position of the media type in first byte after the body, if any
exists.

3. If it does, return a 200
interruption occurred.

SEND requests larger than 2k MUST be interrupted to send pending
response and render or REPORT requests. If multiple SEND requests from
different sessions are concurrently being sent over the message to same
connections, the
user. The method of rendering is device SHOULD implement some scheme to alternate
between them such that each concurrent request gets a matter chance to send
some fair portion of local policy. If
the message contained no body data at all, the endpoint should quietly
ignore it.

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

4. If it does not understand regular intervals suitable to the media type, return a 415 response.
application.

The endpoint sender MUST NOT return assume that a 415 response for any media type
for which it indicated support in message is received by the SDP exchange.

6.5.4 Ending a Session

When either endpoint in an MSRP session wishes to end peer
with the session, same chunk allocation it
first signals its intent using the normal processing for was sent with. An intervening
relay could possibly break SEND requests into smaller chunks, or
aggregate multiple chunks into larger ones.

The default disposition of body is "render". If the
signaling protocol. For example, in SIP, sender wants
different disposition, it would send MAY insert a BYE request
to the peer. After agreeing Content-Disposition header.
Since MSRP is a binary protocol, transfer encoding MUST be "binary".

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

6.1.2 Sending REPORT requests

REPORT requests are similar to end the session, the host endpoint SEND requests, except that report
requests MUST release any resources acquired as part of NOT include Report-Success or Report-Failure header
fields, and MUST contain a Status header field. REPORT requests MUST
contain the session.

Each peer Message-ID header from the original SEND request.

An MSRP endpoint MUST destroy all local state for be able to generate success REPORT requests.

REPORT requests MAY include a body. If a body is included, it SHOULD
be of the session. This
involves completely removing DSN MIME type detailed in RFC1894 [8], but MAY be of some
other type if the state entry for sender of the session and
invalidating SEND request indicated support in the session URL.

If no other sessions are using
"receipt-type" parameter of the connection, respective Report-Success or
Report-Failure header field. This parameter contains the endpoint alternative
MIME type that
opened it SHOULD tear it down. However, the passive party MAY tear
down be used for this particular report. A client
specifying an unused connection after a locally configured timeout period.

When alternative 'receipt-type' for an MSRP transaction MUST
also be capable of receiving the default format specified in this
RFC1894. Use of the DSN MIME format in MSRP is described in Section
8

An endpoint chooses to close MUST send a session, it may have SEND
transactions outstanding. For example, success report if it may have send successfully receives a
SEND
requests to request which it has not yet received contained a response, Report-Success value of "yes", and
either contains a complete message, or it may have
received SEND requests that to which it has not responded. Once an
endpoint has decided to close contains the connection, it SHOULD wait for such
outstanding transactions to complete. It SHOULD NOT generate any new
SEND transactions, and it MAY choose not to respond to any new SEND
requests that are received after it decides last chunk needed
to close complete the session. It
SHOULD not respond to any new messages that arrive after it signals
its intent to close message. This request is sent following the normal
procedures (Section 6.1), with a few additional requirements.

The endpoint inserts a To-Path header field containing the From-Path
value from the original request, and a From-Path header containing
the URL identifying itself in the session.

When an The endpoint is signaled then inserts
a Status header field with a namespace of its peer's intent to close "000", a session,
it short-status of
"200" and a relevant Reason phrase, and a Message-ID header field
containing the value from the original request.

Positive status reports SHOULD NOT initiate any more SEND requests. It SHOULD wait include a payload.

The endpoint MUST NOT send a success report for
any outstanding transactions a SEND request that
either contained no Report-Success header field, or contained such a
field with a value of "no".

6.1.3 Failure REPORT Generation

If an MSRP endpoint receives a SEND request that it initiated to complete, cannot process
for some reason, and it
SHOULD attempt respond to any open SEND transactions received prior
to being signaled.

It is the Report-Failure header either was not possible to completely eliminate present
in the chance original request, or had a value of "yes", it SHOULD simply
send a session
terminating transaction response with incomplete SEND transactions. When this occurs, an appropriate error response code.
However, there may be situations where the
endpoint SHOULD clearly inform error cannot be determined
quickly, such as when the user endpoint is a gateway that the messages may not
have been delivered.

6.5.5 Managing Session State and Connections

A must wait for a
downstream network to indicate an error. In this situation, it MAY

Campbell, et al. Expires January 16, 2005 [Page 19]
Internet-Draft MSRP session is represented by state at each endpoint, identified
by July 2004

send a 200 OK response to the local URL request, and remote path. An active session also has an
associated network connection.

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

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

Internet-Draft MSRP May 2004

connection failure REPORT
request when the error is dropped, any associated session state MUST NOT be
reused. detected.

If an the endpoint wishes to continue to communicate after
detecting a connection failure, it MAY initiate receives a new SDP exchange to
negotiate SEND request with a new session URL. Otherwise, Report-Failure header
field value of "none", then it MUST NOT send a failure REPORT
request, and SHOULD attempt to tear
down the session using the rules NOT send an MSRP response.

Construction of the signaling protocol.

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

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

Endpoints SHOULD NOT send REPORT requests if they have reason to
believe the hosting device noticing the failure, the
hosting device request will interpret the recovery attempt as a conflict.
The only way around this would not be to force the hosting device to
do delivered. For example, they SHOULD
NOT send a liveness check REPORT request on the original connection, which would create a lot of complexity and overhead that do not seem to be worth the
trouble.

6.6 Delivery Status Notification

Delivery Status Notification (DSN)[10] provides an extensible MIME
content-type session that is used to convey both positive and negative status
of messages in the network. no longer valid.

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

6.2 Constructing Responses

If an MSRP endpoint MUST be capable receives a request that either contains a
Report-Failure header value of performing the DSN
operations described in this specification and SHOULD support the DSN
MIME type outlined. An MSRP endpoint MAY use "yes", or does not contain a
Report-Failure header field at all, it MUST immediately generate a
response. Likewise, if an alternative payload
for reporting message status using the procedures outlined in this
specification.

6.6.1 Endpoint DSN Request

An MSRP endpoint receives a request that wishes to be informed
contains a Report-Failure header value of message delivery/failure
needs to request such information. This "partial", and the receiver
is achieved by including an
MSRP Receipt-Request header in unable to process the request. The header can equal one
of three values:

negative: Indicates request, it SHOULD immediately generate a
response.

To construct the client only requires failure delivery
report.
none: Indicates response, the client requires no delivery reports.
all: Indicates endpoint first creates the client requires both positive response
start-line, inserting appropriate response code and negative
delivery reports.

Within reason fields.
The transaction identifier in the scope of this specification response start line MUST match the
transaction identifier from the Receipt-Request original request.

The endpoint then inserts an appropriate To-Path header is

Campbell (Ed.) field. If
the request triggering the response was a SEND request, the To-Path

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

only used

header field is formed by copying the last (right-most) URI in MSRP the
From-Path header field of the request. (Unlike other methods,
responses to SEND requests. Future extensions requests are returned only to the previous hop.)
For responses to all other requests, the To-Path header field
contains the full path back to the original sender. This full path
is generated by taking the list of URLs from the From-Path of the
original request, reversing the list, and writing the reversed list
into the To-Path of the response. (Legal REPORT requests do not
request responses, so this specification MAY use doesn't exercise the mechanism
behavior described in this document for
delivery/failure status notification of other MSRP requests.

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

Finally, the endpoint inserts a From-Path header if not present field containing the
URL that identifies it in a request is
'negative'. An example the context of this the session, followed by the
closing sequence after the last header would be:

Message-Receipt: negative field. The default DSN MIME type is detailed in RFC 1894[10]. It is
possible for MSRP endpoints to use a different format if required.
This can response MUST be achieved by including a 'receipt-type' parameter
transmitted back on the same connection on which the original request
arrived.

6.3 Receiving Requests

The receiving endpoint must first check the URL in the
Message-Receipt header. This parameter contains To-Path to
make sure the alternative MIME
type that SHOULD be used for this particular receipt transaction. A
client specifying an alternative 'receipt-type' for an MSRP
transaction MUST also be capable of receiving the default format
specified in this document. This allows intermediaries, such as MSRP
relays, to generate failure reports when MSRP transaction failure
occurs.

6.6.2 DSN generation

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

1. Insert a To header containing
connection on which the From value from request arrived. If this is not true, and
the original
request.
2. Insert request contained a From Report-Failure header containing the To value from the original
request.
3. Insert the message status payload in the body of "no", then the
receiver SHOULD quietly ignore the request. If the default DSN MIME type from DSN[10] Report-Failure
header is used not present, or had any other value, then the MSRP
Content-Type header MUST use the value multipart/report. The
relevance of DSN headers in MSRP can be found in section 7.6.5.
An alternative MIME type MAY be used but receiver MUST be specified in
return a 481 response.

Further request processing by the
Content-Type header. Negative DSN generation receiver is considered out
of method specific.

6.3.1 Receiving SEND requests

When the scope of this document and will be covered in receiving endpoint receives a separate
MSRP relay document.
4. Insert SEND request, it first
determines if it contains a new transaction ID (TR-ID).
5. (Optional) Insert an MSRP Byte-Range header containing the value
from 'multipart/byteranges' MIME header Content-range complete message, or a chunk from a
larger message. If the
payload request contains no Byte-Range header, or
contains one with a range-start value of "1", and the closing line
continuation flag has a chunked 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 is possible that an entity
downstream may decide
forms a virtual buffer to break up an MSRP SEND message receive the message, keeping track of which
bytes have been received and send which are missing. The receiver takes
the data from the request and places it in separate chunks. the appropriate place in
the buffer. The originating client would be
transparent to this operation but would need to be informed receiver MUST determine the actual length of each
chunk by inspecting the payload itself; it is possible the body is
shorter than the range-end field indicates. This can occur if the
sender interrupted a

Campbell (Ed.) SEND request unexpectedly. It is worth nothing

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

DSN only represents part

that the chunk that has a termination character of "$" defines the request.

6.6.3 Receiving positive DSN

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

6.6.4 Receiving negative DSN

An MSRP endpoint implementing this specification MUST be able to
receive negative delivery status the message.

What is done with the body is outside the scope of MSRP requests.

6.6.5 DSN headers in MSRP and largely
determined by the MIME type. The format of a default DSN report body MAY be rendered after the
whole message is taken from RFC 1894[10]. Only
a minimal subset of fields are used, received or partially rendered as detailed in it is being
received.

If the remainder of
this section.

6.6.5.1 Per-Message DSN SEND request contained a Content-Type header usage

original-envelope-id: See Section 6.6.5.3

reporting-mta: See Section 6.6.5.4

dsn-gateway: Not Used

received-from-mta: Not Used

arrival-date: Not Used

6.6.5.2 Per-Recipient DSN header usage

original-recipient Not Used

final-recipient: See Section 6.6.5.5

action: See Section 6.6.5.6

status: See Section 6.6.5.7

remote-mta: Not Used

diagnostic-code: Not Used

last-attempt-date: Not Used

will-retry-until:Not Used

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

Internet-Draft MSRP May 2004

6.6.5.3 original-envelope-id usage

The 'original-envelope-id' field contains a unique identifier which
is used to correlate indicating
an unsupported MIME type, the receiver SHOULD send a DSN report with 415 response, if
allowed by the originating Report-Failure header field. All MSRP
transaction. The entity generating the DSN report endpoints MUST insert
be able to receive the
Message-ID multipart/mixed and multipart/alternative MIME
types.

If the SEND request contained a Report-Success header field with a
value that appeared in of "yes", and the original MSRP request into is either contains the
'original-envelope-id' field. This allows a requesting client entire message
or the last chunk needed to
explicitly correlate complete a message, the receiver MUST
send a success REPORT request with back to the sender.

6.3.2 Receiving REPORT requests

When an endpoint receives a REPORT request, it may correlate it to
the original request.
This correlation is implementation specific SEND request using the Message-ID and makes no requirements
on clients to hold the Byte-Range, if
present. If it requested success reports, then it SHOULD keep enough
state for transactions ID's. Information
regarding about each outstanding sent message so that it can correlate
REPORT requests to the original messages.

An endpoint that receives a REPORT request can be obtained from containing a Status header
with a namespace field of "000", it SHOULD interpret the DSN MIME type
outlined report in [10].

6.6.5.4 reporting-mta

The 'reporting-mta-field' MUST follow
exactly the guidelines set out in RFC
1894[10]. The 'mta-name-type' from RFC1894[10] MUST use same way it would interpret an MSRP transaction response
with a response code matching the value of
'msrp-name-type', as defined in section 9 of this specification. The
'mta-name' value short-code field.

It is possible to receive a failure report or a failure transaction
response for a chunk that is currently being delivered. In this field as specified in RFC1894 [10] MUST
equal an MSRP URL representing itself.

6.6.5.5 final-recipient

The 'final-recipient-field' MUST follow case
the guidelines set out in RFC
1894[10]. entire message corresponding to that chunk should be aborted.

It is possible that an endpoint will receive a REPORT request on a
session that is no longer valid. The 'address-type' from RFC1894 [10] MUST use the value of
'msrp-address-type', as defined in section 9 of endpoint's behavior if this specification.
happens is a matter of local policy. The 'address-type' value for this field as specified 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 RFC1894 [10]
MUST equal case late REPORTs might
arrive.

7. Using MSRP with SIP

7.1 SDP Offer-Answer Exchanges for MSRP Sessions

MSRP sessions will typically be initiated using the value contained in Session

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

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

This document defines a handful of new SDP parameters to setup MSRP 'To' header from
sessions. These are detailed below and in the
original request being reported on.

6.6.5.6 action IANA Considerations
section.

The 'action' field MUST follow the guidelines set out in RFC
1894[10]. general format of an SDP media-line is:

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

An offered or accepted MSRP entity constructing a DSN report media-line MUST use have the
'delivered' following value for a successful delivery and MUST use
exactly, with the 'failed'
value for an un-successful delivery. The other values specified for exception that the 'action' port field in RFC 1894[10] MAY be used.

6.6.5.7 status

The 'status' field MUST follow the guidelines set out in RFC
1894[10]. An MSRP entity constructing to zero.
(According to [3], a DSN report user agent that wishes to accept an offer, but
not a specific media-line MUST represent set the port number of that media-line
to zero (0).)

m=message 9 msrp *

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

An MSRP status code consists
of media-line is always accompanied by a three digit number while mandatory "path"
attribute. This attribute contains a DSN status is three digits space separated
by '.'. An example would be:

Status: 5.0.0 (unknown permanent failure)

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

Internet-Draft MSRP May 2004

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

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

A "*" entry in the third part of accept-types attribute indicates that the 'status' DSN field. An example of a DSN
'status' field value would be:

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

Status: 2.0.0 (OK)

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

6.7 Message Fragmentation

MSRP devices SHOULD break large send content into fragments, with media types that have not been
explicitly listed. Likewise, an entry with an explicit type and send each
fragment in a separate SEND request. A message fragment sent in this
way is known
"*" character as a "parcel". Large content is defined to be anything
larger than 2K bytes. Each parcel is encapsulated using the
"message/byteranges" MIME type, defined in RFC2616 [11], subtype indicates that the sender may attempt to correlate
parts
send content with any subtype of that type. If the message. The definition of large is determined by local
policy. receiver receives
an MSRP endpoints MUST be capable of receiving and processing
fragmented messages.

Open Issue: Do we want to negotiate the use of message/byteranges
like any other MIME type? I assume no, as we want to allow relays
to fragment messages, request and relays are not privy is able to process the
content-types negotiated for media type, it does so.
If not, it will respond with a session.

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

6.7.1 considered preferred over any non-listed types.

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

This feature is needed as, otherwise, the list of message/byteranges

The "message/byteranges" type allows multiple ranges in a single
document. However, MSRP formats for rich IM
devices MUST NOT may be prohibitively large.

The accept-types attribute may include more than one byte
range container types, that is, MIME
formats that contain other types internally. If compound types are
used, the types listed in a single request. Although the HTTP usage for a document
containing a single byte range indicates putting accept-types attribute may be used both
as the "Content-Range"
header root payload, or may be wrapped in a header field, rather than listed container type.
Any container types MUST also be listed in the accept-types
attribute.

Occasionally an endpoint will need to specify a MIME body itself,
"Content-Range" MUST NOT appear as type that
can only be used if wrapped inside a listed container type.

Endpoints MAY specify MIME types that are only allowed when wrapped
inside compound types using the "accept-wrapped-types" attribute in
an MSRP header field.

Open Issue: How much SDP a-line.

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

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

Internet-Draft MSRP May 2004

If used when wrapped inside containers. Only types listed
in the MSRP device has a priori knowledge of accept-types attribute may be used as the overall content
length, it SHOULD put that length into instance-length. The device
MAY place a "*" in instance-length if it does not have such
knowledge.

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

6.8 Method Descriptions

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

6.8.1 SEND

The SEND method is accept-types may be used by both the host and visitor endpoints to
send instant messages to its peer endpoint. A SEND request MUST
contain a To-Path header field containing the sender's remote path,
as a
From-Path header field containing the sender's local URL, root body, and a
Message-ID header field. SEND requests wrapped in other bodies, format entries from
accept-types SHOULD contain a MIME body
part. The body MUST NOT be repeated in this attribute.

This approach does not allow for specifying distinct lists of
acceptable wrapped types for different types of containers. If an
endpoint understands a media MIME type included in the format list
negotiated in the SDP exchange. If a body context of one wrapper, it is present,
assumed to understand it in the request
MUST contain a Content-Type header field identifying context of any other acceptable
wrappers, subject to any constraints defined by the media type wrapper types
themselves.

The approach of specifying types that are only allowed inside of
containers separately from the body.

To Do: We plan primary payload types allows an
endpoint to expand force the use of MIME headers to allow any
standard MIME header in certain wrappers. For example, a SEND request. This is not included in
this version for
CPIM [14] gateway device may require all messages to be wrapped
inside message/cpim bodies, but may allow several content types
inside the sake of getting wrapper. If the draft out as soon as
possible, but will follow soon.

6.8.2 VISIT

The visiting endpoint uses gateway were to specify the VISIT method wrapped
types in the accept-types attribute, its peer might attempt to associate a network
connection with use
those types without the session state at wrapper.
All types listed in either the listening device. A VISIT
request MUST accept-types or
accept-wrapped-types attributes MAY include a To-Path header including max-size parameter,
indicating the sender's remote
path, and a From-Path header field containing largest message it is willing to accept of that
type. Max-size refers to the sender's local URL.

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

Open Issue: There size of
any one chunk. Senders MUST NOT exceed the max-size limit, if
any, when sending messages of any listed type. If a type is overlap between SEND and VISIT as currently
defined. We should consider either removing VISIT entirely and

Campbell (Ed.)
listed without the parameter, then no preset size limit exists.

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

just use

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

7.1.1 URL Negotiations

Each endpoint in an empty SEND request, or we should always require VISIT.
(This would not apply to MSRP session is identified by a endpoint connecting to its own relay.)

6.8.3 REPORT

Report is used by an endpoint URL. These URLs
are negotiated in the SDP exchange. Each SDP offer or relay to convey message delivery
status

6.9 Response Code Descriptions answer MUST
contain one or more MSRP URL in a path attribute. This section summarizes attribute has
the various response codes. Except following syntax:

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

where
noted, all responses MSRP_URL is an msrp: or msrps: URL as defined in Section 5.
MSRP URLs included in an SDP offer or answer MUST contain include explicit
port numbers.

An MSRP device uses the URL to determine a TR-ID header field matching host address, port,
transport, and protection level when connecting, and to identify the
TR-ID header field
target when sending requests and responses.

The offerer and answerer each selects a URL to represent itself, and
send it to the peer device in the SDP document. Each device stores
the path value received from the peer, and uses that value as the
target for requests inside the resulting session. If the path
attribute received from the peer contains more than one 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 the peer
and adjacent hop URL. The target path is the entire path attribute
value received from the peer.

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

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

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

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

7.1.2 Path Attributes with Multiple URLs

As mentioned previously, this document describes MSRP for
peer-to-peer scenarios, that is, when no relays are used. However,
we expect a separate document to describe the 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 must include a few assumptions about how relays work.

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

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

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

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

7.1.3 Updated SDP Offers

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

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

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

7.1.4 Example SDP Exchange

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

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

B responds with its own URL:

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

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

7.1.5 Connection Negotiation

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

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

7.2 MSRP User Experience with SIP

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

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

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

8. DSN payloads in MSRP REPORT Requests

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

8.1 Per-Message DSN header usage

original-envelope-id: See Section 8.3

reporting-mta: See Section 8.4

dsn-gateway: Not Used

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

8.4 reporting-mta

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

8.5 final-recipient

The 'final-recipient-field' MUST follow the guidelines set out in RFC
1894[8]. The 'address-type' from RFC1894 [8] MUST use the value of
'msrp-address-type', as defined in Section 15.4 of this

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 MSRP entity constructing a DSN report MUST use the 'delivered'
value for a successful delivery and MUST use the 'failed' value for
an unsuccessful delivery. The other values specified for the
'action' field in RFC 1894[8] MAY be used.

8.7 status

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

Status: 5.0.0 (unknown permanent failure)

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

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

Status: 2.0.0 (OK)

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

9. Formal Syntax

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

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

req-start = pMSRP SP transact-id SP method CRLF

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 ; MSRP in caps
transact-id = ident
method = mSEND / mREPORT / other-method
mSEND = %53.45.4e.44 ; SEND in caps
mREPORT = %52.45.50.4f.52.54; REPORT in caps

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

headers = 1*( header CRLF )

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

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

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

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

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

gen-param = pname [ "=" pval ]

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

pname = token
pval = token / quoted-string

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

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

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

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

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

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

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

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

10. Response Code Descriptions

This section summarizes the original request, and To-Path and From-Path
headers matching those semantics of various response codes that
may be used in MSRP transaction responses. These codes may also be
used in the original request.

6.9.1 Status header in REPORT requests.

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

10.1 200

The 200 response code indicates a successful transaction.

6.9.2

10.2 400

A 400 response indicates a request was unintelligible.

6.9.3

10.3 403

The action is not allowed

10.4 415

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

6.9.4

10.5 426

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

6.9.5

10.6 481

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

6.9.6

10.7 506

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

6.10 Header Field Descriptions

11. Examples

11.1 Basic IM session

This section summarizes shows an example flow for the various header fields. 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 header

Campbell (Ed.) July 2004

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

1. Alice constructs a local URL of
msrp://alicepc.example.com:7777/iau39;tcp .

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

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

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

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

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

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

6.10.1 TR-ID

The TR-ID header field contains a transaction identifier used to map
a response

a=path:msrp://bob.example.com:8888/9di4ea;tcp

4. Alice->Bob (SIP): ACK

5. (Alice opens connection to the corresponding request. A TR-ID value MUST be
unique among all values used by a given endpoint inside a given
session. Bob.) Alice->Bob (MSRP):

MSRP elements MUST NOT assume any additional semantics for
TR-ID.

6.10.2 Message-ID

The Message-ID header field contains a message identifier used to map
a delivery status notification to the corresponding request. TR-ID
cannot be used for this purpose, as it may change between hops if
relays are involved. A Message-ID value MUST be unique among all
values used by a given endpoint inside a given session. d93kswow SEND
To-Path:msrp://bob.example.com:8888/9di4ea;tcp
From-Path:msrp://alicepc.example.com:7777/iau39;tcp
Message-ID: 12339sdqwer
Content-Type:text/plain
Hi, I'm Alice!
-------d93kswow$

6. Bob->Alice (MSRP):

MSRP
elements MUST NOT assume any additional semantics for Message-ID.
The Message-ID value MAY be the same as the original TR-ID value.

6.10.3 To-Path

The To-Path header field is used to indicate the sender's remote
path. All d93kswow 200 OK
To-Path:msrp://bob.example.com:8888/9di4ea;tcp
From-Path:msrp://alicepc.example.com:7777/iau39;tcp
-------d93kswow$

7. Bob->Alice (MSRP):

MSRP requests MUST contain a To-Path header field.

6.10.4 From-Path

The From-Path header field is used to indicate the sender's dkei38sd SEND
To-Path:msrp://alice.example.com:7777/iau39;tcp
From-Path:msrp://bob.example.com:8888/9di4ea;tcp
Message-ID: 456
Content-Type:text/plain

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

8. Alice->Bob (MSRP):

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

9. Alice->Bob (SIP): BYE

Alice invalidates local
URL. All session state.

10. Bob invalidates local state for the session.

Bob->Alice (SIP): 200 OK

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

11.2 Chunked Message

For an example of a From-Path header field.

6.10.5 Boundary

The Boundary header field contains the boundary string that is used
to terminate chunked message, see the message. This string MUST have at least 16 bits of
randomness. This string MUST NOT be duplicated anywhere else example in the
message. The Boundary header field is mandatory for all Section 4.1.

11.3 System Message

Sysadmin->Alice (MSRP):

MSRP
messages, and SHOULD be the first header field in the message.

6.10.6 Closing

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

Campbell (Ed.) going down in 5 minutes
-------d93kswow$

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

6.10.7 Content-Type

The Content-Type header field

11.4 Positive Report

Alice->Bob (MSRP):

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

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

Bob->Alice (MSRP):

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

Bob->Alice (MSRP):

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

11.5 Forked IM

Traditional IM systems generally do a poor job of handling multiple
simultaneous IM clients online for the MIME media type 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, 2005 [Page 37]
Internet-Draft MSRP July 2004

With SIP session mode messaging rendezvous decisions can be under
control of the body. Content-Type MUST be present if client in a body predictable, interoperable way for any
host that implements callee capabilities [30]. As a result,
rendezvous policy is present.

To Do: managed consistently for each address of record.

The work group following example shows Juliet with several IM clients where she
can be reached. Each of these has agreed to allow the use a unique SIP Contact and MSRP
session. The example takes advantage of any standard
MIME header. This is not reflected SIP's capability to "fork"
an invitation to several Contacts in this version, but will be 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 shortly forthcoming one.

7. Example

This section shows an example message flow for the most common
scenario. with her
Nurse. Juliet's contacts are listed below. The example assumes SIP q-values express
relative preference (q=1.0 is used to transport the SDP
exchange. Details highest preference).

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

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

The Response contains her Contacts:

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

When Romeo opens his IM program, he selects Juliet and types the
message "art thou hither?" (instead of "you there?"). His client
sends a SIP messages invitation to sip:juliet@thecapulets.example.com. The
Proxy there tries first the balcony and SIP proxy infrastructure
are omitted for the sake chamber simultaneously.
A client is running on both those systems, both of brevity. In which setup early
sessions of MSRP with Romeo's client. The client automatically sends
the example, assume message over the
offerer is sip:alice@atlanta.com MSRPS to the two MSPR URIs involved. After a
delay of a several seconds with no reply or activity from Juliet, the
proxy cancels the invitation at her first two contacts, and forwards
the answerer invitation on to Juliet's PDA. Since her father is
sip:bob@biloxi.com.

Alice Bob talking to

Campbell, et al. Expires January 16, 2005 [Page 38]
Internet-Draft MSRP July 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----| | | | |
|(1) (SIP) INVITE
|---PRACK---------------->| |
|----------------------->|
|(4) (SIP) 200 OK |
|<-----------------------|
|(5) (SIP) ACK |
|----------------------->|
|(6) (MSRP) SEND
|<----200-----------------| |
|----------------------->|
|(7) (MSRP) 200 OK |
|<-----------------------|
|(8) (MSRP) SEND |
|<-----------------------|
|(9) (MSRP) 200 OK
|<===Early MSRP Session==>| art thou hither? |
|----------------------->|
|(10) (SIP) BYE |
|----------------------->|
|(11) (SIP) 200 OK
|
|<-----------------------| | | | |

1. Alice constructs a local URL of
msrp://alicepc.atlanta.com:7777/iau39 and listens for a
connection on TCP port 7777.

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

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

Internet-Draft MSRP May 2004

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

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

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

3. Alice->Bob (SIP): ACK

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

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

5. Bob->Alice (MSRP):

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

6. Bob->Alice (MSRP):

MSRP SEND
Boundary: dkei38sd

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

Internet-Draft MSRP May 2004

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

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

7. Alice->Bob (MSRP):

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

8. Alice->Bob (SIP): BYE

Alice invalidates local session state.

9. Bob invalidates local state for the session.

Bob->Alice (SIP): 200 OK

8. IANA Considerations

8.1 MSRP Port |
| |--INVITE---------------->| | |
| |<----180-----------------| | |
|<----180----| | | | |
|---PRACK----------------------------->| | |
|<----200------------------------------| | |
|<========Early MSRP uses TCP port XYX, Session==========>| art thou hither? |
| | | | | |
| | | | | |
| | .... Time Passes .... | | |
| | | | | |
| | | | | |
| |--CANCEL--->| | | |
| |<---200-----| | | |
| |<---487-----| | | |
| |----ACK---->| | | |
| |--CANCEL---------------->| | |
| |<---200------------------| | |
| |<---487------------------| | |
| |----ACK----------------->| | |
| |--INVITE---------------------------->| romeo wants
| | | | | to be determined by IANA after this document
is approved for publication. Usage of this value is described in
Section 6.1

8.2 MSRP URL Schema

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

8.2.1 Syntax

See Section 6.1.

8.2.2 Character Encoding

See Section 6.1.

Campbell (Ed.) IM w/ you
| |<---486 Busy Here--------------------| |
| |----ACK----------------------------->| |
| | | | | |
| |--INVITE---------------------------------------->|
| |<---200 OK---------------------------------------|
|<--200 OK---| | | | |
|---ACK------------------------------------------------------->|
|<================MSRP Session================================>|
| | | | | |

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

8.2.3 Intended Usage

See Section 6.1.

8.2.4 Protocols

The Message Session Relay Protocol (MSRP).

8.2.5 Security Considerations

See Section 9.

8.2.6 Relevant Publications

RFCXXXX

[Note to RFC Editor: Please replace RFCXXXX in the above paragraph

| Hi Romeo, Juliet is |
| with the actual number assigned to this document.

8.3 SDP Parameters

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

8.3.1 Accept Types

Attribute-name: accept-types
Long-form Attribute Name Acceptable MIME Types
Type: Media level
Subject her father now |
| can i take a message?|
| |
| Tell her to Charset Attribute No
Purpose and Appropriate Values See Section 5.2.

8.3.2 Wrapped Types

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

8.3.3 Path

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

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

Internet-Draft confession tommorrow.... |

12. Extensibility

MSRP May 2004

Subject was designed to Charset Attribute No
Purpose 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 Appropriate Values See Section 5.4.

8.4 IANA registration forms for DSN types

8.4.1 IANA registration form for address-type

This document registers total extensions is expected to be very
small. MSRP does not contain a version number or any negotiation
mechanism to require or discover new 'address-type' for features.

MSRP was designed to use lists of URLs instead of a single URL in conjunction
with RFC1894[10]. The authors request 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. 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 these values do not include a concept of sessions. Furthermore,
when one endpoint of the session is a CPIM gateway, instant messages
SHOULD be recorded wrapped in the IANA registry for DSN 'address-type'.

Proposed Address name: msrp-address-type

Syntax: See Section 6.1

8.4.2 IANA registration form for MTA-name-type

This document registers "message/cpim" [7] bodies. Such a new 'MTA-name-type' for use gateway MUST
include "message/cpim" as the first entry in conjunction
with RFC1894[10]. The authors request its SDP accept-types
attribute. MSRP endpoints sending instant messages to a peer that these values be recorded
has included 'message/cpim" as the first entry in the IANA registry for DSN 'MTA-name-type'.

Proposed Address name: msrp-name-type

Syntax: See See Section 6.1

9. accept-types
attribute SHOULD encapsulate all instant message bodies in "message/
cpim" wrappers. All MSRP endpoints MUST support the message/cpim
type, and SHOULD support the S/MIME features of that format.

14. Security Considerations

There

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

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

All correct other party are required. MSRP devices must support TLS, with at least pushes

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

many of the
TLS_RSA_WITH_AES_128_CBC_SHA [8] cipher suite. Other cipher suites
MAY be supported. hard problems to SIP when SIP sets up the session, but
some of the problems remain. Spam and DoS attacks are also very
relevant to IM systems.

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

When a device accepts a using only TCP
connection, it MUST watch for the TLS handshake messages to determine
if connections, MSRP security is fairly weak. If
host A is contacting B, B passes its hostname and a particular connection uses TLS. secret to A using
SIP. If the first data received SIP offer or answer is not part of a start TLS request, the device ceases or S/MIME [27] protected,
anyone can see this secret. A then connects to watch for the
TLS handshake until 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 reads sent the entire message. Once SYN
packet and then delivers the secret in plain text across the
connections. B assumes it is talking to A because the message
has been completely received, host on the device resumes watching for
other end of the
start TLS message.

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

Internet-Draft MSRP May 2004

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

MSRP devices acting in delivered the role of TCP client MAY perform a TLS
handshake at any time, as long as secret. An attacker that
could ACK the request occurs between MSRP
messages. The endpoint MUST NOT send SYN packet could insert itself as a start TLS request man in the middle of an MSRP message.

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

When using TLS handshake at the beginning of the session. However, connections, the
endpoint should be able to determine if a new message security is a start
TLS request or an MSRP request by only reading ahead three bytes.
Therefore, significantly improved.
We assume that the working group chose to allow a session to switch to
TLS in mid-stream, as long as host accepting the switch occurs between MRSP
messages.

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

The "msrps" and "smsrps" URI schema indicates certificate
from a well know certificate authority. Furthermore, we assume that
the connection
MUST be protected with TLS.

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

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

9.1.1 Sensitivity of Session URLs

The URLs sent in TLS (using
sips). In this case, when host A contacts host B, the SDP offer/answer exchange for secret is
passed through a MSRP session are
used by the endpoints SIP confidential channel to identify each other. If an attacker were
able A. A connects with TLS
to B. B presents a valid certificate, so A knows it really is
connected to acquire B. A then delivers the session URL, either secret provided by guessing B, so that B
can verify it or by
eavesdropping, there is connected to A. In this case, a window of opportunity in which rogue SIP Proxy can
see the attacker
could hijack secret in the session connecting SIP signaling traffic and sending could potentially
insert itself as a MSRP request man-in-the-middle.

Realistically, using TLS is only feasible when connecting to gateways
or relays , as the
listening device before the legitimate peer. Because types of this
sensitivity, these URLs SHOULD be constructed in a way to make them
difficult to guess, and should be sufficiently random so hosts that it is end clients use for sending
instant messages are unlikely to be reused. All mechanisms used to transport these URLs
SHOULD be protected from eavesdroppers and man-in-the-middle attacks.

Therefore have a MSRP device MUST support long term stable IP address
or a stable DNS name that a certificate can bind to. In addition,
the use cost of TLS 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 all MSRP
messages. Further, MSRP connections SHOULD actually be protected
with TLS. Further, an MSRP without relays is achieved
using S/MIME. This does not require the actual endpoint MUST be capable to have
certificates from a well known certificate authority. The Identity
[22] and Certificates [23] mechanism with SIP provides S/MIME based
delivery of using a secret between A and B. No SIP intermediary except the

Campbell (Ed.)
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 November 15, 2004 January 16, 2005 [Page 37] 41]
Internet-Draft MSRP May July 2004

security features of the signaling protocol

exchange keying material that can be used in order MRSP. The MSRP session
can then use S/MIME with this keying material to protect the
SDP exchange encrypt and SHOULD actually use them on all such exchanges.
End-to-end protection schemes SHOULD be preferred sign
messages sent over hop-by-hop
schemes for protection of MSRP. The connection can still be hijacked since
the SDP exchange.

9.1.2 End secret is sent in clear text to End Protection the other end of IMs

Instant messages the TCP
connection, but this risk is mitigated if all the MSRP content is
encrypted and signed with S/MIME.

MSRP can contain very sensitive information. As a
result, not be used as specified in RFC 2779 [3], instant messaging protocols
need to provide an amplifier for encryption, integrity 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 authentication of
instant messages. Therefore Eve returns an answer
with the SDP that indicates that her MSRP endpoints MUST support address is the
end-to-end encryption and integrity address of bodies
Tom. Since Alice sent via SEND requests the offer, Alice will initiate a connection to
Tom using Secure MIME (S/MIME) [7].

Note up resources on Tom's server. Given the huge number of IM
clients, and the relatively few TCP connections that while each protected body could use separate keying
material, most servers
support, this is inefficient a fairly straightforward attack.

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

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

Since MSRP carries arbitrary MIME content, it can trivially carry S/
MIME protected using S/MIME.

9.1.3 CPIM compatibility messages as well. All MSRP sessions may be gatewayed to other CPIM [19]compatible
protocols. If this occurs, the gateway MUST maintain session state,
and implementations MUST translate between
support the MSRP session semantics and CPIM
semantics that multipart/signed MIME type even if they do not include support S/
MIME. Since SIP can carry a concept of sessions. Furthermore,
when one endpoint of the session is a CPIM gateway, instant key, S/MIME messages
SHOULD be wrapped in "message/cpim" [5] bodies. Such a gateway MUST
include "message/cpim" as the first entry
context of a session could also be protected using a key-wrapped
shared secret [26] provided in its SDP accept-types
attribute. the session setup.

15. IANA Considerations

15.1 MSRP endpoints sending instant messages Port

MSRP uses TCP port XYX, to a peer that
has included 'message/cpim" as the first entry be determined by IANA after this document
is approved for publication. Usage of this value is described in
Section 5

15.2 MSRP URL Schemes

This document defines the accept-types
attribute SHOULD encapsulate all instant message bodies 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.
Relevant Publications RFCXXXX
[Note to RFC Editor: Please replace RFCXXXX in "message/
cpim" wrappers. All MSRP endpoints MUST support the message/cpim
type, and SHOULD support above
paragraph with the S/MIME features of that format.

9.1.4 PKI Considerations

Several aspects of MSRP will benefit from being used in actual number assigned to this document.

15.3 SDP Parameters

This document registers the context
of a public key infrastructure. For example, following SDP parameters in the MSRPS scheme
allows,
sdp-parameters registry:

15.3.1 Accept Types

Attribute-name: accept-types
Long-form Attribute Name Acceptable MIME Types
Type: Media level
Subject to Charset Attribute No
Purpose and even encourages, TLS connections between endpoint
devices. And while Appropriate Values See Section 7.1.

15.3.2 Wrapped Types

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

15.3.3 Path

Attribute-name: path
Long-form Attribute Name MSRP allows 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 DSN types

15.4.1 IANA registration form for address-type

This document registers a symmetric session key to
protect all messages new 'address-type' for use in a session, it is most likely conjunction
with RFC1894[8]. The authors request that session key
itself would these values be exchanged recorded
in a signaling protocol such as SIP. Since

Campbell (Ed.) the IANA registry for DSN 'address-type'.

Proposed Address name: msrp-address-type

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

Syntax: See Section 5

15.4.2 IANA registration form for MTA-name-type

This document registers a new 'MTA-name-type' for use in conjunction
with RFC1894[8]. The authors request that key is extremely sensitive, its exchange would also need these values be recorded
in the IANA registry for DSN 'MTA-name-type'.

Proposed Address name: msrp-name-type

Syntax: See Section 5

16. Change History

16.1 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
protected. In SIP, part of the preferred mechanism for this would start-line rather
than a header field.
Removed the TR-IDheader, and changed request-response matching to
be S/MIME, based on the Boundary field value. Responses still contain the
TR-ID header, which would also benefit must match the Boundary from a PKI.

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

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

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

10. Changes from Previous Draft Versions

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

10.1 VISIT.

16.2 draft-ietf-simple-message-sessions-06

Changed To and From header names to To-Path and From-Path. Added
more clarification to path handling, and commentary on how it
enables relay usage.
Changed mechanism for signaling transport and TLS protection into
the MSRP URL, rather than the SDP M-Line.

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

10.2

16.3 draft-ietf-simple-message-sessions-05

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

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

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

10.3

16.4 draft-ietf-simple-message-sessions-04

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

10.4

16.5 draft-ietf-simple-message-sessions-03

Removed all specification of relays, and all features specific to
the use of relays. The working group has chosen to move relay
work into a separate effort, in order to advance the base
specification. (The MSRP acronym is unchanged for the sake of
convenience.) This included removal of the BIND method, all
response codes specific to BIND, Digest Authentication, and the
inactivity timeout.

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.

10.5

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

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

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

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

10.6

16.7 draft-ietf-simple-message-sessions-01

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

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.

10.7

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

Name changed to reflect status as a work group item.
This version no longer supports the use of multiple sessions
across a single TCP session. This has several related changes:
There is now a single session URI, rather than a separate one for
each endpoint. The session URI is not required to be in requests
other than BIND and VISIT, as the session can be determined based
on the connection on which it arrives.
BIND and VISIT now create soft state, eliminating the need for the
RELEASE and LEAVE methods.
The MSRP URL format was changed to better reflect generic URL
standards. URL comparison and resolution rules were added. SRV
usage added.

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

Internet-Draft MSRP May 2004
Determination of host and visitor roles now uses a direction
attribute much like the one used in COMEDIA.
Format list negotiation expanded to allow a "prefer these formats
but try anything" semantic
Clarified handling of direction notification failures.
Clarified signaling associated with session failure due to dropped
connections.
Clarified security related motivations for MSRP.
Removed MIKEY dependency for session key exchange. Simple usage
of k-lines in SDP, where the SDP exchange is protected end-to-end
seems sufficient.

10.8

16.9 draft-campbell-simple-im-sessions-01

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

11.

17. Contributors and Acknowledgments

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

12. Acknowledgments Sparks.

The following people contributed substantial discussion and feedback

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

to this ongoing effort: Allison Mankin Mankin, Jon Peterson Peterson, Brian Rosen Rosen,
Dean Willis Willis, Aki Niemi Niemi, Hisham Khartabil Khartabil, Pekka Pessi Pessi, Orit Levin

13. Levin.

18. References

13.1

18.1 Normative References

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

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

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

Internet-Draft MSRP May 2004

[2]

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

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

[3] Day, M., Aggarwal, S.

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

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

[7] Atkins, D. and G. Klyne, "Common Presence Protocol Requirements", 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 2779, February 2000.

[4] 1894, January 1996.

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

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

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

[5]

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

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

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

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

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

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

[8] Format", draft-ietf-impp-cpim-msgfmt-08
(work in progress), January 2003.

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

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

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

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

13.2

18.2 Informational References

[12] Campbell, B.

[16] Johnston, A. and J. Rosenberg, O. Levin, "Session Initiation Protocol
Extension for Instant Messaging", RFC 3428, September 2002.

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

[14] Mahy, R., Campbell, B., Sparks, R., Rosenberg, J., Petrie, D.
and A. Johnston, "A Multi-party Application Framework Call
Control - Conferencing for SIP",
draft-ietf-sipping-cc-framework-02 User Agents",
draft-ietf-sipping-cc-conferencing-03 (work in progress), May
2003.

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

Internet-Draft MSRP May 2004

[15]
February 2004.

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

[16] January 2004.

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

[17] Camarillo, G., Marshall, W. 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. Rosenberg, "Integration of
Resource Management and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)", RFC
3312, October 2002.

[18]
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 Privacy Mechanism 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)", RFC 3323 , November 2002.

[19] Peterson, J., "A Common Profile for (SIP)",
draft-ietf-sipping-early-media-02 (work in progress), June
2004.

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

[20] Yon, D., "Connection-Oriented Media Transport April 2004.

[30] Rosenberg, J., "Indicating User Agent Capabilities in SDP",
draft-ietf-mmusic-sdp-comedia-05 the
Session Initiation Protocol (SIP)",
draft-ietf-sip-callee-caps-03 (work in progress), March
2003.

Author's Address January 2004.

Authors' Addresses

Ben Campbell
dynamicsoft
5100 Tennyson Parkway (editor)

EMail: ben@nostrum.com

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

EMail: bcampbell@dynamicsoft.com

Campbell (Ed.) rohan@cisco.com

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

Cullen Jennings
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, 2005 [Page 44] 51]
Internet-Draft MSRP May July 2004

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither nor does it represent that it has
made any independent effort to identify any such rights. Information
on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation RFC documents can be
found in BCP-11. BCP 78 and BCP 79.

Copies of
claims of rights IPR disclosures made available for publication to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementors implementers or users of this
specification can be obtained from the IETF Secretariat. on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which that may cover technology that may be required to practice implement
this standard. Please address the information to the IETF Executive
Director.

Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose at
ietf-ipr@ietf.org.

Disclaimer of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

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

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

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

Internet-Draft MSRP May 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

Campbell, et al. Expires November 15, 2004 January 16, 2005 [Page 46] 52]
----