WDIFF

draft-ietf-simple-message-sessions-02.txt --> draft-ietf-simple-message-sessions-03.txt

SIMPLE Working Group B. Campbell
Internet-Draft J. Rosenberg
Expires: April 22, July 27, 2004 R. Sparks
dynamicsoft
P. Kyzivat
Cisco Systems
October 23, 2003
January 27, 2004

The Message Session Relay Protocol
draft-ietf-simple-message-sessions-02
draft-ietf-simple-message-sessions-03

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

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 April 22, July 27, 2004.

Abstract

This document describes the Message Session Relay Protocol (MSRP), a
mechanism for transmitting a series of Instant Messages within a
session. MSRP sessions are managed using the Session Description
Protocol (SDP) offer/answer model carried by a signaling protocol
such as the Session Initiation Protocol (SIP).

MSRP supports end-to-end Instant Message Sessions, as well as
sessions traversing one or two relays.

Campbell, et al. Expires April 22, July 27, 2004 [Page 1]

Internet-Draft MSRP October 2003 January 2004

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation for Session-mode Messaging . . . . . . . . . . . 4
3. Scope of this Document . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 6
5. Architectural Considerations . . . . . . . . . . . . . . . . 7
5.1 Use of Relays . . . . . . . . . . . . . . . . . . . . . . . 8
5.2 Transferring Large Content . . . . . . . . . . . . . . . . . 8
5.3 Connection Sharing . . . . . . . . . . . . . . . . . . . . . 9 7
6. SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . . 10 7
6.1 Use of the SDP M-line . . . . . . . . . . . . . . . . . . . 10 8
6.2 The Direction Attribute . . . . . . . . . . . . . . . . . . 11 8
6.3 The Accept Types Attribute . . . . . . . . . . . . . . . . . 12 10
6.4 MIME Wrappers . . . . . . . . . . . . . . . . . . . . . . . 13 10
6.5 URL Negotiations . . . . . . . . . . . . . . . . . . . . . . 13 11
6.6 Updated SDP Offers . . . . . . . . . . . . . . . . . . . . 12
6.7 Example SDP Exchange . . . . . . . . . . . . . . . . . . . . 14 13
7. The Message Session Relay Protocol . . . . . . . . . . . . . 15 13
7.1 MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . . 15 14
7.1.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . . 16 14
7.1.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . . 16 15
7.1.3 The msrps URL Scheme . . . . . . . . . . . . . . . . . . . . 17 16
7.2 MSRP messages . . . . . . . . . . . . . . . . . . . . . . . 17 16
7.3 MSRP Transactions . . . . . . . . . . . . . . . . . . . . . 19 17
7.4 MSRP Sessions . . . . . . . . . . . . . . . . . . . . . . . 19 17
7.4.1 Initiating an MSRP session . . . . . . . . . . . . . . . . . 19 17
7.4.2 Handling VISIT requests . . . . . . . . . . . . . . . . . . 23 21
7.4.3 Sending Instant Messages on a Session . . . . . . . . . . . 23 21
7.4.4 Ending a Session . . . . . . . . . . . . . . . . . . . . . . 25 22
7.4.5 Managing Session Inactivity Timer State and Connections . . . . . . . . . . 23
7.5 Method Descriptions . . . . . . . . 26
7.4.6 Managing Session State and Connections . . . . . . . . . . . 27
7.5 MSRP Relays 24
7.5.1 SEND . . . . . . . . . . . . . . . . . . . . . . . . 27
7.5.1 Establishing Session State at a Relay . . . 24
7.5.2 VISIT . . . . . . . . 28
7.5.2 Removing Session State from a relay . . . . . . . . . . . . 29
7.5.3 Sending IMs across an MSRP relay . . . . . . 24
7.6 Response Code Descriptions . . . . . . . . 30
7.5.4 Relay Pairs . . . . . . . . 24
7.6.1 200 . . . . . . . . . . . . . . . . 30
7.5.5 Relay Shutdown . . . . . . . . . . . 24
7.6.2 400 . . . . . . . . . . . . 31
7.6 Digest Authentication . . . . . . . . . . . . . . . 25
7.6.3 415 . . . . 31
7.6.1 The SHA1 Algorithm . . . . . . . . . . . . . . . . . . . . . 33
7.7 Method Descriptions . . 25
7.6.4 426 . . . . . . . . . . . . . . . . . . 33
7.7.1 BIND . . . . . . . . . 25
7.6.5 481 . . . . . . . . . . . . . . . . . . . 34
7.7.2 SEND . . . . . . . . 25
7.6.6 506 . . . . . . . . . . . . . . . . . . . . 34
7.7.3 VISIT . . . . . . . 25
7.7 Header Field Descriptions . . . . . . . . . . . . . . . . 25
7.7.1 TR-ID . . . . 34
7.8 Response Code Descriptions . . . . . . . . . . . . . . . . . 34
7.8.1 200 . . . . . 25
7.7.2 Content-Type . . . . . . . . . . . . . . . . . . . . . . . 35
7.8.2 400 25
7.7.3 S-URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.8.3 401 . . . . . 26
8. Example . . . . . . . . . . . . . . . . . . . . . . . 35
7.8.4 403 . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . 35

Campbell, et al. Expires April 22, 2004 [Page 2]

Internet-Draft 28
9.1 MSRP October 2003

7.8.5 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.8.6 426 . . . . . . . . . . . . . . . . . . . . . . . . . . . Port . 35
7.8.7 481 . . . . . . . . . . . . . . . . . . . . . . . 28
9.2 MSRP URL Schemes . . . . . 35
7.8.8 500 . . . . . . . . . . . . . . . . 28
9.2.1 Syntax . . . . . . . . . . . . 35
7.8.9 506 . . . . . . . . . . . . . . 28

Campbell, et al. Expires July 27, 2004 [Page 2]

Internet-Draft MSRP January 2004

9.2.2 Character Encoding . . . . . . . . . . . . . . 35
7.9 Header Field Descriptions . . . . . . 28
9.2.3 Intended Usage . . . . . . . . . . . 36
7.9.1 TR-ID . . . . . . . . . . . 28
9.2.4 Protocols . . . . . . . . . . . . . . . . 36
7.9.2 Exp . . . . . . . . 28
9.2.5 Security Considerations . . . . . . . . . . . . . . . . . 29
9.2.6 Relevant Publications . . . 36
7.9.3 CAuth . . . . . . . . . . . . . . . 29
9.3 SDP Parameters . . . . . . . . . . . . 36
7.9.4 SChal . . . . . . . . . . 29
9.3.1 Direction . . . . . . . . . . . . . . . . . 37
7.9.5 Content-Type . . . . . . . 29
9.3.2 Accept Types . . . . . . . . . . . . . . . . . 37
7.9.6 S-URL . . . . . . 29
9.3.3 Wrapped Types . . . . . . . . . . . . . . . . . . . . . 37
8. Examples . 29
10. Security Considerations . . . . . . . . . . . . . . . . . 29
10.1 TLS and the MSRPS Scheme . . . . . . . . 37
8.1 No Relay . . . . . . . . . 30
10.1.1 Sensitivity of the Session URL . . . . . . . . . . . . . . 30
10.1.2 End to End Protection of IMs . . . 38
8.2 Single Relay . . . . . . . . . . . . 31
10.1.3 CPIM compatibility . . . . . . . . . . . . 40
8.3 Two Relays . . . . . . . . 31
10.1.4 PKI Considerations . . . . . . . . . . . . . . . . . 43
9. IANA Considerations . . . 32
11. Changes from Previous Draft Versions . . . . . . . . . . . 32
11.1 draft-ietf-simple-message-sessions-03 . . . . . . 46
9.1 MSRP Port . . . . 32
11.2 draft-ietf-simple-message-sessions-02 . . . . . . . . . . 33
11.3 draft-ietf-simple-message-sessions-01 . . . . . . . . . . 33
11.4 draft-ietf-simple-message-sessions-00 . 46
9.2 MSRP URL Schemes . . . . . . . . . 34
11.5 draft-campbell-simple-im-sessions-01 . . . . . . . . . . . 34
12. Contributors . . 47
9.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . 34
Normative References . . . . . . 47
9.2.2 Character Encoding . . . . . . . . . . . . . 35
Informational References . . . . . . . . 47
9.2.3 Intended Usage . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . 47
9.2.4 Protocols . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . . . . . . . . . . 47
9.2.5 Security Considerations . . . . . . . . . . . . . . . . . . 47
9.2.6 Relevant Publications . . . . . . . . . . . . . . . . . . . 47
9.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . 47
9.3.1 Direction . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.3.2 Accept Types . . . . . . . . . . . . . . . . . . . . . . . . 48
9.3.3 Wrapped Types . . . . . . . . . . . . . . . . . . . . . . . 48
10. Security Considerations . . . . . . . . . . . . . . . . . . 48
10.1 TLS and the MSRPS Scheme . . . . . . . . . . . . . . . . . . 48
10.2 Sensitivity of the Session URL . . . . . . . . . . . . . . . 49
10.3 End to End Protection of IMs . . . . . . . . . . . . . . . . 50
10.4 CPIM compatibility . . . . . . . . . . . . . . . . . . . . . 50
10.5 PKI Considerations . . . . . . . . . . . . . . . . . . . . . 50
11. Changes from Previous Draft Versions . . . . . . . . . . . . 51
11.1 draft-ietf-simple-message-sessions-02 . . . . . . . . . . . 51
11.2 draft-ietf-simple-message-sessions-01 . . . . . . . . . . . 51
11.3 draft-ietf-simple-message-sessions-00 . . . . . . . . . . . 52
11.4 draft-campbell-simple-im-sessions-01 . . . . . . . . . . . . 52
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53
Normative References . . . . . . . . . . . . . . . . . . . . 53
Informational References . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55
Intellectual Property and Copyright Statements . . . . . . . 56

Campbell, et al. Expires April 22, 2004 [Page 3]

Internet-Draft MSRP October 2003

1. Introduction

The MESSAGE [10] extension to SIP [2] allows SIP to be used to
transmit instant messages. Instant messages sent using the MESSAGE
method are normally independent of each other. This approach is often
called page-mode messaging, since it follows a model similar to that
used by many two-way pager devices. Page-mode messaging makes sense
for instant message exchanges where a small number of messages occur.
Endpoints may treat page-mode messages as if they took place in an
imaginative session, but there is no formal relationship between one
message and another.

There are also applications in which it is useful for instant
messages to be formally associated in a session. For example, a user
may wish to join a text conference, participate in the conference for
some period of time, then leave the conference. This usage is
analogous to regular media sessions that are typically initiated,
managed, and terminated using SIP. We commonly refer to this model as
session-mode messaging.

One of the primary purposes of SIP and SDP (Section 6) is the
management of media sessions. Session-mode messaging can be thought
of as a media session like any other. 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 a small number of
message transactions, message sessions offer a way to remove
messaging load from intervening SIP proxies. For example, a minimal
session setup and tear-down requires one INVITE/ACK transaction, and
one BYE transaction, for a total of 5 SIP messages. Normal SIP
request routing allows for all but the initial INVITE transaction to
bypass any intervening proxies that do not specifically request to be
in the path for future requests. Session-mode messages never cross
the SIP proxies themselves.

Each page-mode message involves a complete SIP transaction, that is,
a request and a response. Any page-mode message exchange that
involves more than 2 MESSAGE requests will generate more SIP requests
than a minimal 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 to network congestion concerns, the MESSAGE method has

Campbell, et al. Expires April 22, 2004 [Page 4]

Internet-Draft MSRP October 2003

significant limitations in message size, 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 is in progress to mitigate these concerns.

However, session-mode messages are always sent over reliable,
congestion-safe transports. Therefore, there are no restrictions on
message sizes. There is no requirement to wait for acknowledgement
before sending another message, so that message transactions can be
overlapped.

Message sessions allow greater efficiency for secure message
exchanges. The 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, a session key can be established at the time
of session initiation. This key can be used to protect each message
that is part of the session. This requires only symmetric key
operations for each subsequent IM, and no additional certificate
exchanges are required after the initial exchange. The establishment
of 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 SIP feature that can be applied to other sorts of media
sessions can equally apply to message sessions. For example,
conferencing [12], third party call control [13], call transfer [14],
QoS integration [15], and privacy [16] can all be applied to message
sessions.

Messaging sessions can also reduce the overhead in each individual
message. In page-mode, each message needs to include all of the SIP
headers that are mandated by RFC 3261 [2]. However, many of these
headers are not needed once a context is established for exchanging
messages. As a result, messaging session mechanisms can be designed
with significantly less overhead.

3. Scope of this Document

This document describes the use of MSRP between endpoints, or via one
or two relays, where endpoints have advance knowledge of the relays.
It does not provide a mechanism for endpoints to determine whether a
relay is needed, or for endpoints to discover the presence of relays.

This document describes the use of MSRP over TCP. MSRP may be used
over other congestion-controlled protocols such as SCTP. However, the
specific bindings for other such protocols are outside the scope of
this document.

Campbell, et al. Expires April 22, 2004 [Page 5]

Internet-Draft MSRP October 2003

4. Protocol Overview

The Message Session Relay Protocol (MSRP) provides a mechanism for
transporting session-mode messages between endpoints. MSRP also
contains primitives to allow the use of one or two relay devices.
MSRP uses connection oriented, reliable network transport protocols
only. It is intrinsically NAT and firewall friendly, as it allows
participants 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 to send message content from one endpoint to another.

VISIT: Used by an endpoint to establish a session association to the
opposite endpoint, or to a relay that was selected by the opposite
endpoint.

BIND: Used by an endpoint to establish a session at a relay, and
allow the opposite endpoint to visit that relay.

The simplest use case for MSRP is a session that goes directly
between endpoints, with no intermediaries involved. Assume A is an
endpoint that wishes to establish a message session, and B is the
endpoint invited by A. A invites B to participate in a message
session by sending a URL that represents the session. This URL is
temporary, and must not duplicate the URL used for any other active
sessions.

B "visits" A by connecting to A and sending a VISIT request
containing the URL that A provided. This associates the connection
from B with the session. B then responds to the invitation, informing
A that B has accepted the session. A and B may now exchange messages
using SEND requests on the connection.

When either party wishes to end the session, it informs the peer
party with a SIP BYE request. A terminates the session by
invalidating associated state, and dropping the connection.

The end to end case looks something like the following. (Note that
the example shows a logical flow only; syntax will come later in this
document.)

A->B (SDP): offer (msrp://A/123)

Campbell, et al. Expires April 22, 2004 [Page 6]

Internet-Draft MSRP October 2003

B->A (MSRP): VISIT (msrp://A/123)
A->B (MSRP): 200 OK
B->A (SDP): answer(msrp://A/123)
A->B (MSRP): SEND
B->A (MSRP): 200 OK
B->A (MSRP): SEND
A->B (MSRP): 200 OK

The session state has an associated inactivity timer. This timer is
initialized when a successful VISIT request occurs, and is reset each
time either endpoint sends a SEND request. If this timer expires
without being reset, the hosting device invalidates the session state
and terminates all associated connections. Endpoints that are
otherwise idle may keep a session active by periodically sending SEND
requests with no content.

A slightly more complicated case involves a single relay, known about
in advance by one of the parties. The endpoint that has the
preexisting relationship with the relay uses the BIND method to
establish session state in the relay. The relay returns a temporary
URL, that identifies the session. For endpoints A and B, and relay R,
the flow would look like the following:

A->R: MSRP: BIND(msrp://r)
R->A: MSRP: 200 OK (msrp://r/4uye)
A->B (SDP): offer (msrp://r/4uye)
B->R (MSRP): VISIT (msrp://r/4uye)
R->B (MSRP): 200 OK
B->A (SDP): answer(msrp://r/4uye)
A->R (MSRP): SEND
R->B (MSRP): SEND
B->R (MSRP): 200 OK
R->A (MSRP): 200 OK
B->R (MSRP): SEND
R->A (MSRP): SEND
A->R (MSRP): 200 OK
R->B (MSRP): 200 OK

The BIND request contains an expiration time. If a successful VISIT
request does not occur prior to the expiration, the relay will
destroy the session. Additionally, when tearing down a session, the
host endpoint invalidates the session state by issuing a BIND request
with an expiration value of zero.

5. Architectural Considerations

There are a number of considerations that, if handled in a reasonable

Campbell, et al. Expires April 22, 2004 [Page 7]

Internet-Draft MSRP October 2003

fashion, will allow more effective use of the protocols described in
this document.

5.1 Use of Relays

The primary motivation for relay support in MSRP is to deal with
situations where, due to issues of network topologies, neither
endpoint is able to receive an inbound TCP connection from the other.
For example, both endpoints may be behind separate firewalls that
only allow outbound connections. Relays may also be needed for policy
enforcement. For example, parts of the financial industry require the
logging of all communication.

However, the use of such relays has a significant impact on the
scalability of MSRP. Each relay will require two TCP connections for
each session in use, as well as memory for local session state
storage. Most general purpose platforms on which one might implement
MSRP relays will have relatively low limits on the number of
simultaneous TCP connections they can handle.

Therefore relays SHOULD NOT be used indiscriminately. In the absence
of strong reasons to use relays, MSRP endpoints SHOULD be configured
to set up point-to-point sessions.

MSRP supports the use of two relays, where each endpoint has a relay
acting on its behalf. However, most of the network topology issues
mentioned above can work with a single relay, if that relay is
reachable by both endpoints. Dual relays are only needed for cases of
very strict firewall policy, such as when only specific hosts are
allowed to connect to the outside world; or situations requiring
strict policy enforcement at both endpoint domains. If a given usage
scenario can be solved with a single relay, then a second relay
SHOULD NOT be used.

In spite of these recommendations, relays serve a real purpose in
that they increase the likelihood of two arbitrary endpoints being
able to talk to one another. Therefore if a provider deploys MSRP
endpoints in a network configuration that prevents them from
receiving TCP connections from arbitrary peers, and does not wish to
explicitly prevent MSRP communication with the outside world, then
the provider SHOULD provide its endpoints with the use of an MSRP
relay that is reachable from arbitrary peers.

5.2 Transferring Large Content

MSRP endpoints may attempt to send very long messages in a session.
For example, most commercial instant messaging systems have a file
transfer feature. Since MSRP does not impose message size limits,

Campbell, et al. Expires April 22, 2004 [Page 8]

Internet-Draft MSRP October 2003

there is nothing to prevent endpoints from transferring files over
it.

An analysis of whether it makes sense to do this, rather than sending
such content over FTP, HTTP, or some other such protocol, is beyond
the scope of this document. However, implementers should be aware of
the impact of sending very large messages over MSRP. The primary
impact is, since MSRP is sent over TCP, is that any additional
messages that the sender wishes to send will be blocked until the
large transfer is complete. This includes responses to messages sent
by the peer. Therefore, any SEND transactions initiated by the peer
are likely to time out, even though they are received without
problems.

Further, there is no way to abort the sending of a very large message
before it is complete. For the sake of efficiency, the framing
mechanism in MSRP is very simple. There is no clean way to recover
framing if the complete message is not sent.

These issues can be mitigated greatly if the endpoint simply
establishes a separate session for the transfer. This allows the
transfer to be sent without interfering with any instant messages
being sent on other sessions. Further, the endpoint can abort the
transfer by simply tearing down the transfer session. Therefore, if a
peer wishes to send very large content, it SHOULD establish a
dedicated session for that purpose.

Open Issue: Do we need a mechanism to communicate the purpose of
the session? It has been mentioned that the peer may not realize
the purpose of the session, and start using it for normal
messaging. Also, there has been discussion that we need a stronger
mechanism to avoid transaction timeouts caused by long requests.

5.3 Connection Sharing

The SIMPLE working group spent quite a bit of effort in the
consideration of shared TCP connections. Connection sharing would
offer value whenever a large number of message sessions cross the
same two adjacent devices. This situation is likely to occur in the
two relay model. It may also occur in the point-to-point model if the
endpoints are multiuser devices, as is likely with web-hosted
messaging services.

Unfortunately, such connection sharing in TCP created significant
problems. The biggest problem is it introduced a head-of-line
blocking problem that spanned sessions. For example, if two different
pairs of users had sessions that crossed the same shared connection,
a large message sent on one session would block transfer of messages

Campbell, et al. Expires April 22, 2004 [Page 9]

Internet-Draft MSRP October 2003

on the other session. The working group considered this an
unacceptable property of shared connections. One possible solution
was to put limits on message size, and possibly add mechanisms to
allow breaking messages into many chunks. However, these solutions
promised to add a great deal of complexity to the protocol, so the
work group chose not to go that route.

It may be possible to relax this requirement using other transport
protocols, such as SCTP. The lack of connection sharing in this
document should not be construed to prohibit shared connections on
other such protocols. However, such specification is beyond the scope
of this document.

6. SDP Offer-Answer Exchanges for MSRP Sessions

MSRP sessions will typically be initiated using the Session
Description Protocol (SDP) [1] offer-answer mechanism, carried in the
Session Initiation Protocol (SIP) [2] or any other protocol
supporting it. MSRP borrows the idea of the direction attributes from
COMEDIA [18], but does not depend on that specification.

6.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 type for the session. For MSRP sessions, the media field
MUST have the value of "message". The port field is normally not
used, and SHOULD be set to 9999. An exception is when the port field
value is set to zero, according to normal SDP usage.

The proto field MUST designate the message session mechanism and
transport protocol, separated by a "/" character. For MSRP, left part
of this value MUST be "msrp". For MSRP over TCP, the right part of
this field MUST take the value "tcp". For MSRP over other transport
protocols, the field value MUST be defined by the specification for
that protocol binding.

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

The port field in the M-line is not normally used to determine the
port to which to connect. Rather, the actual port is determined by

Campbell, et al. Expires April 22, 2004 [Page 10]

Internet-Draft MSRP October 2003

the contents of the session URL (Section 7.1). However, a port value
of zero has the normal SDP meaning.

The following example illustrates an m-line for a message session,
where the endpoint is willing to accept root payloads of message/
cpim, plain text or HTML. The second two types could either be
presented as the root body, or could be contained within message/cpim
bodies.

m=message 9999 msrp/tcp *

6.2 The Direction Attribute

Since MSRP uses connection oriented transport protocols, one goal of
the SDP negotiation is to determine which participant initiates the
transport connection. The direction attribute advertises whether the
offerer or answerer wishes to initiate the connection, wishes the
peer endpoint to initiate the connection, or doesn't care.

The endpoint that accepts the connection, or has a relay accept the
connection on its behalf, is said to "host" the session, and is known
as the hosting endpoint. The endpoint that initiates the connection
is said to "visit" the session, and is known as the visiting
endpoint.

The direction attribute is included in an SDP a-line, with a value
taking the following syntax:

direction = direction-label ":" role
direction-label = "direction"
role = active / passive / both
active = "active"
passive = "passive"
both = "both" [sp timeout]
timeout = 1*DIGIT ; timeout value in seconds

The values for the role field are as follows:

passive: The endpoint wishes to host the session

active: The endpoint wishes the peer to host the session.

both: The endpoint is willing to act as either host or visitor. If
"both" is selected, it may contain an optional timeout value. This
timeout specifies how much time the answerer should wait before
giving up on a connection and attempting to take over as host
device. If the timeout value is not specified, it defaults to 30
seconds.

Campbell, et al. Expires April 22, 2004 [Page 11]

Internet-Draft MSRP October 2003

The SDP offer for an MSRP session MUST contain a direction attribute,
which MAY take any of the defined values. If the offerer is capable
of hosting the session, or can arrange for a relay to host the
session on its behalf, then it SHOULD select "both". The endpoint
SHOULD NOT select "active" unless it cannot host the session under
any circumstances. The endpoint SHOULD NOT select "passive" unless it
has no option but to host the session.

The SDP answer also MUST contain a direction attribute, but its value
choices are limited based on the value in the offer. If the offer
contained "active", then the answerer MUST either select "passive" or
reject the offer. Likewise, if the offer contained "passive", then
the answerer MUST select "active" or reject the offer. If the offer
contained "both", the answerer SHOULD select "active", but MAY select
"passive" if it is unable to reach the host device, or if local
policy requires it to act as host.

6.3 The Accept Types Attribute

MSRP can carry any MIME encoded payload. Endpoints specify MIME
content types that they are willing to receive in the accept types
"a"-line attribute. This attribute has the following syntax:

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

SDP offers for MSRP sessions MUST include an accept-types attribute.
SDP answers MUST also include the attribute, which MUST contain
either the same list as in the offer or a subset of that list.

A "*" entry in the accept-types attribute indicates that the sender
may attempt to send messages with media types that have not been
explicitly listed. If the receiver is able to process the media type,
it does so. If not, it will respond with a 415. Note that all
explicit entries SHOULD be considered preferred over any non-listed
types. This feature is needed as, otherwise, the list of formats for
rich IM devices may be prohibitively large.

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

Campbell, et al. Expires April 22, 2004 [Page 12]

Internet-Draft MSRP October 2003

6.4 MIME Wrappers

Endpoints MAY specify MIME types that are only allowed to be wrapped
inside compound types using the "accept-wrapped-types" attribute 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"

The format-list element has the identical syntax as defined for the
accept-types attribute. The semantics for this attribute are
identical to those of the accept-types attribute, with the exception
that the specified types may only be used when wrapped inside
containers. Only types listed in accept-types may be used as the
"root" type for the entire body. Since any type listed in
accept-types may be used both as a root body, and wrapped in other
bodies, format entries from 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 a MIME type in the context of one wrapper, it is
assumed to understand it in the context of any other acceptable
wrappers, subject to any constraints defined by the wrapper types
themselves.

The approach of specifying types that are only allowed inside of
containers separately from the primary payload types allows an
endpoint to force the use of certain wrappers. For example, a CPIM
gateway device may require all messages to be wrapped inside
message/cpim bodies, but may allow several content types inside
the wrapper. If the gateway were to specify the wrapped types in
the accept-types attribute, its peer could choose to use those
types without the wrapper.

6.5 URL Negotiations

An MSRP session is identified by an MSRP URL, which is determined by
the hosting endpoint, and negotiated in the SDP exchange. Any SDP
offer or answer that creates a possibility that the sender will host
the session, that is, it contains a direction value of "passive" or
"both", MUST contain an MSRP URL in a session attribute. This

Campbell, et al. Expires April 22, 2004 [Page 13]

Internet-Draft MSRP October 2003

attribute has the following syntax:

a=session:<MSRP_URL>

where <MSRP_URL> is an MSRP or MSRPS URL as defined in Section 7.1.

The visitor will use the session URL established by the host both to
resolve the host address and port, and to identify the session when
connecting. For MSRP sessions, the address field in the C-line is not
relevant, and MUST be ignored. The port field in the M-line MUST be
ignored if non-zero. Zero values have the normal meaning for SDP.

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

c=IN IP4 useless.host.name
m=message 9999 msrp/tcp *
a=accept-types:text/plain
a=direction:both
a=session:msrp://example.com:7394/2s93i

The session URL MUST be a temporary URL assigned just for this
particular session. It MUST NOT duplicate any URL in use for any
other session hosted by the endpoint or relay. Further, since the
peer endpoint will use the session URL to identify itself when
connecting, it SHOULD be hard to guess, and protected from
eavesdroppers. This will be discussed in more detail in Section 10.

6.6 Example SDP Exchange

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

c=IN IP4 alice.example.com
m=message 9999 msrp/tcp *
a=accept-types: message/cpim text/plain text/html
a=direction:both
a=session:msrp://alice.example.com:7394/2s93i9

Endpoint B chooses to participate in the role of visitor, opens a TCP
connection to alice.example.com:7394, and successfully performs a
VISIT transaction passing the URL of msrp://alice.example.com:7394/
2s93i9. B indicates that it has accomplished this by answering with:

c=IN IP4 dontlookhere
m=message 9999 msrp/tcp *
a=accept-types:message/cpim text/plain

Campbell, et al. Expires April 22, 2004 [Page 14]

Internet-Draft MSRP October 2003

a=direction:active

A may now send IMs to B by executing SEND transactions on the same
connection on which B sent the VISIT request.

7. The Message Session Relay Protocol

The Message Session Relay Protocol (MSRP) is a text based, message
oriented protocol for the transfer of instant messages in the context
of a session. MSRP uses the UTF8 character set.

MSRP messages MUST be sent over a reliable, congestion-controlled,
connection-oriented transport protocol. This document specifies the
use of MSRP over TCP. Other documents may specify bindings for other
such protocols.

7.1 MSRP URLs

MSRP sessions are identified by MSRP URLs. An MSRP URL follows a
subset of the URL syntax in Appendix A of RFC2396 [4], with a scheme
of "msrp":

msrp_url = "msrp" ":" "//" [userinfo] hostport ["/' resource]
resource = 1*unreserved

The constructions for "userinfo", "hostport", and "unreserved" are
detailed in RFC2396 [4].

An MSRP URL server part identifies the hosting device of an MSRP
session. If the server part contains a numeric IP address, it MUST
also contain a port. The resource part identifies a particular
session at that host device. The absence of the resource part
indicates a reference to an MSRP host device, but does not
specifically refer to a particular session resource.

MSRP has an IANA registered recommended port defined in Section 9.1.
This value SHOULD NOT be considered a default, as the URL process
described herein will always explicitly resolve a port number.
However, the URLs SHOULD be configured so that the recommended port
is used whenever appropriate. This makes life easier for network
administrators who need to manage firewall policy for MSRP.

The server part will typically not contain a userinfo component, but
MAY do so to indicate a user account for which the session is valid.
Note that this is not the same thing as identifying the session
itself. If a userinfo component exists, MUST be constructed only from
"unreserved" characters, to avoid a need for escape processing.
Escaping MUST NOT be used in an MSRP URL. Furthermore, a userinfo

Campbell, et al. Expires April 22, 2004 [Page 15]

Internet-Draft MSRP October 2003

part MUST NOT contain password information.

The following is an example of a typical MSRP URL:

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

7.1.1 MSRP URL Comparison

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

1. The host part is compared as case insensitive.

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

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

4. Userinfo parts are not considered for URL comparison.

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

7.1.2 Resolving MSRP Host Device

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

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

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

If the server part contains a host name but no port, the connecting
device MUST perform the following steps:

1. Construct an SRV [6] query string by prefixing the host name
with the service field "_msrp" and the protocol field ("_tcp" for
TCP). For example, "_msrp._tcp.host.example.com".

2. Perform a DNS SRV query using this query string.

Campbell, et al. Expires April 22, 2004 [Page 16]

Internet-Draft MSRP October 2003

3. Select a resulting record according to the rules in RFC2782 [6].
Determine the port from the chosen record.

4. If necessary, determine a host device address by performing an A
or AAAA query on the host name field in the selected SRV result
record. If multiple A or AAAA records are returned, the first
entry SHOULD be chosen for the initial connection attempt. This
allows any ordering created in the DNS to be preserved.

5. If the connection attempt fails, the device SHOULD attempt to
connect to the addresses returned in any additional A or AAAA
records, in the order the records were presented. If all of these
fail, the device SHOULD attempt to use any additional SRV records
that may have been returned, following the normal rules for SRV
record selection.

Note that in most cases, the transport protocol will be determined
separately from the resolution process. For example, if the MSRP URL
was communicated in an SDP offer or answer, the SDP M-line will
contain the transport protocol. When an MSRP URL is communicated
outside of SDP, the protocol SHOULD also be communicated. For
example, a client may be configured to use a particular relay that is
referenced with an MSRP URL. The client MUST also be told what
protocol to use. If a device needs to resolve an MSRP URL and does
not know the protocol, it SHOULD assume TCP.

7.1.3 The msrps URL Scheme

The "msrps" URL Scheme indicates that each hop MUST be secured with
TLS. Otherwise, it is used identically as an MSRP URL, except that a
MSRPS URL MUST NOT be considered equivalent to an MSRP URL. The MSRPS
scheme is further discussed in Section 10.

7.2 MSRP messages

MSRP messages are either requests or responses. Requests and
responses are distinguished from one another by the first line. The
first line of a Request takes the form of the request-start entry
below. Likewise, the first line of a response takes the form of
response-start. The syntax for an MSRP message is as follows:

msrp-message = request-start/response-start *(header CRLF)
[CRLF body]
request-start = "MSRP" SP length SP Method CRLF
response-start = "MSRP" SP length SP Status-Code SP
Reason CRLF

length = 1*DIGIT ; the length of the message, 38

Campbell, et al. Expires April 22, July 27, 2004 [Page 17] 3]

Internet-Draft MSRP October 2003

; exclusive of the start line.
Method = SEND / BIND / VISIT / other-method
other-method = token
header = Client-Authenticate / Server-Challenge /
Transaction-ID / Session-URL/ Content-Type / Expires
Status-Code = 200 ;Success
/ 400 ;Bad Request
/ 401 ;Authentication Required
/ 403 ;Forbidden
/ 415 ;Unsupported Content Type
/ 426 ;Upgrade Required
/ 481 ;No session
/ 500 ;Cannot Deliver
/ 506 ;duplicate session

Reason = token ; Human readable text describing status
Client-Authenticate = "CAuth" ":" credentials
Server-Challenge = "SChal" ":" challenge
Transaction-ID = "Tr-ID" ":" token
Content-Type = "Content-Type" ":" quoted-string
Session-URL = "S-URL" ":" msrp_url
Expires = "Exp"":" delta-seconds
delta-seconds = 1*DIGIT ; Integer number of seconds

challenge = digest-scheme SP digest-challenge *("," digest-challenge)
digest-scheme = "Digest"
digest-challenge = nonce / algorithm / auth-param
nonce = "nonce" "=" nonce-value
nonce-value = quoted-string
algorithm = "algorithm" "=" ( "SHA1" / token )

credentials = "Digest" digest-response *("," digest-response)
digest-response = username / nonce / response / algorithm /
auth-param
username = "username" "=" username-value
username-value = quoted-string
response = "response" "=" request-digest
request-digest = <"> 40LHEX <">
LHEX = "0" / "1" / "2" / "3" /
"4" / "5" / "6" / "7" /
"8" / "9" / "a" / "b" /
"c" / "d" / "e" / "f"

All requests and responses MUST contain at least a TR-ID header

Campbell, et al. Expires April 22, January 2004 [Page 18]

Internet-Draft MSRP October 2003

field. Messages MAY contain other fields, depending on

1. Introduction

The MESSAGE [10] extension to SIP [2] allows SIP to be used to
transmit instant messages. Instant messages sent using the MESSAGE
method or
response code.

7.3 MSRP Transactions

An MSRP transaction consists are normally independent of exactly one request and one response.
A response matches each other. This approach is often
called page-mode messaging, since it follows a transaction model similar to that
used by many two-way pager devices. Page-mode messaging makes sense
for instant message exchanges where a small number of messages occur.
Endpoints may treat page-mode messages as if it share the same TR-ID value, they took place in an
imaginative session, but there is no formal relationship between one
message and arrives on the same connection on another.

There are also applications in which the transaction was sent.

BIND it is always hop by hop. VISIT transactions are usually hop-by-hop,
but may useful for instant
messages to be relayed formally associated in situations where the visiting endpoint uses a
relay. However, SEND transactions are end-to-end, meaning that under
normal circumstances the response is sent by the peer endpoint, even
if there are intervening relays.

Endpoints MUST select TR-ID header field values session. For example, a user
may wish to join a text conference, participate in requests so that
they are not repeated by the same endpoint in scope conference for
some period of time, then leave the given
session. TR-ID values SHOULD be globally unique. The TR-ID space of
each endpoint conference. This usage is independent of
analogous to regular media sessions that of its peer. Endpoints MUST NOT
infer any semantics from the TR-ID header field beyond what is stated
above. In particular, TR-ID values are not required typically initiated,
managed, and terminated using SIP. We commonly refer to follow any
sequence.

MSRP Transactions complete when a response this model as
session-mode messaging.

One of the primary purposes of SIP and SDP (Section 6) is received, or after a
timeout interval expires with no response. Endpoints MUST treat such
timeouts in exactly the same way they would treat a 500 response. The
timeout interval SHOULD be 30 seconds, but other values may
management of media sessions. Session-mode messaging can be
established thought
of as a matter media session like any other. This document describes the
motivations for session-mode messaging, the Message Session Relay
Protocol, and the use of local policy.

7.4 MSRP Sessions

AN the SDP offer/answer mechanism for managing
MSRP session is a context in which session.

2. Motivation for Session-mode Messaging

Message sessions offer several advantages over page-mode messages.
For message exchanges that include more than a series small number of instant messages
are exchanged, using SEND requests. A
message transactions, message sessions offer a way to remove
messaging load from intervening SIP proxies. For example, a minimal
session has two endpoints (a
host setup and a visitor) tear-down requires one INVITE/ACK transaction, and may have
one or two relays. A session is
identified by an MSRP URL.

7.4.1 Initiating an MSRP session

When an endpoint wishes BYE transaction, for a total of 5 SIP messages. Normal SIP
request routing allows for all but the initial INVITE transaction to engage
bypass any intervening proxies that do not specifically request to be
in the path for future requests. Session-mode messages never cross
the SIP proxies themselves.

Each page-mode message involves a peer endpoint in complete SIP transaction, that is,
a request and a response. Any page-mode message
session, it invites the peer to communicate using an SDP offer,
carried over exchange that
involves more than 2 MESSAGE requests will generate more SIP or some other protocol supporting the SDP offer/
answer model. For the purpose requests
than a minimal session initiation sequence. Since MESSAGE is normally
used outside of this document, we a SIP dialog, these requests will refer to the
endpoint choosing to initiate communication as the offerer, and typically traverse
the
peer being invited as entire proxy network between the answerer.

The offerer SHOULD volunteer endpoints.

Due to act as the hosting endpoint if
allowed by policy and network topology. An endpoint is said to host a
session if one of two conditions are true. The host either directly congestion concerns, the MESSAGE method has

Campbell, et al. Expires April 22, July 27, 2004 [Page 19] 4]

Internet-Draft MSRP October 2003

listens for January 2004

significant limitations in message size, a connection from prohibition against
overlapping requests, etc. Much of this has been required because of
perceived limitations in the peer endpoint, and maintains
session state itself, or it uses a BIND request congestion-avoidance features of SIP
itself. Work is in progress to initialize session
state at a relay that will listen mitigate these concerns.

However, session-mode messages are always sent over reliable,
congestion-safe transports. Therefore, there are no restrictions on
message sizes. There is no requirement to wait for a connection from the peer. The
peer acknowledgement
before sending another message, so that is not the host is designated as the visitor. message transactions can be
overlapped.

Message sessions allow greater efficiency for secure message
exchanges. The offerer
MAY SIP MESSAGE request inherits the answerer to act as host if it is prevented from
accepting connections by network topology or policy, and is not able
to bind to S/MIME features of
SIP, allowing a relay to act on its behalf.

If the offerer wishes message to host the session directly, that is without
using a relay, it MUST perform the following steps:

1. Construct be signed and/or encrypted. However, this
approach requires public key operations for each message. With
session-mode messaging, a session MSRP URL . This URL MUST key can be resolvable to established at the
offerer. The URL SHOULD be temporary, SHOULD time
of session initiation. This key can be hard used to guess,
and MUST not duplicate the URL protect each message
that is part of any other session currently
hosted by the offerer.

2. Listen session. This requires only symmetric key
operations for a connection from the peer.

3. Construct an SDP offer as described in Section 6, including the
list of allowed IM payload formats in each subsequent IM, and no additional certificate
exchanges are required after the accept-types attribute. initial exchange. The offerer maps establishment
of the session URL key can be done using standard techniques that apply
to the session attribute, as
described voice and video, in Section 6.5.

4. Insert a direction attribute. This value SHOULD addition to instant messaging.

Messaging sessions can also reduce the offerer's decision overhead in each individual
message. In page-mode, each message needs to host. If "both" is selected, the
offerer SHOULD leave the timeout at the default value (by leaving
out include all of the value entirely. SIP
headers that are mandated by RFC 3261 [2]. However, the offerer MAY select many of these
headers are not needed once a
different timeout if circumstances warrant it. The direction
value MAY be "passive" if the offerer context is prevented from allowing
the answerer override this choice.

5. Send the SDP offer using the normal processing established for the signaling
protocol.

If the offerer chooses to force the answerer to host the session, it
MUST perform the following steps instead:

1. Construct an SDP offer as described above, but with no session
attribute.

2. Insert exchanging
messages. As a direction attribute result, messaging session mechanisms can be designed
with a value of "active". significantly less overhead.

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

When the answerer receives Scope of this Document

This document describes the SDP offer and chooses to participate
in use of MSRP between endpoints. It does
not specify the session, use of intermediaries, nor does it must choose whether prohibit such use.
We expect an extension to act this specification to define MSRP
intermediaries and their use.

This document describes the use of MSRP over TCP. MSRP may be used
over other congestion-controlled protocols such as SCTP. However, the host or
specific bindings for other such protocols are outside the scope of
this document.

Campbell, et al. Expires April 22, July 27, 2004 [Page 20] 5]

Internet-Draft MSRP October 2003

visitor. A direction attribute value of "both" January 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 offer indicates
that the offerer prefers to host, but will allow the answerer to
host. In this case the answerer SHOULD act presence of many NAT and firewall environments, as the visitor, but MAY
choose
it allows participants to host. A value of "passive" means the offerer insists positively associate message sessions with
specific connections, and does not depend upon
hosting, in connection source
address, which case the answerer MUST act as visitor or decline
the offer.

If the answerer chooses to participate as a visitor, it MUST perform may be obscured by NATs.

MSRP uses the following steps:

1. Determine the host address and port primitives:

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

VISIT: Used by an endpoint to establish a session URL,
following the procedures in section Section 7.1

2. Connect association to the
host address and port, using the transport
protocol from the M-line.

3. Construct a VISIT request, which MUST contain the following
information:

1. An S-URL header field containing the session URL.

2. A TR-ID header field containing a unique transaction ID.

3. endpoint.

Assume A size field containing size of the message subsequent is an endpoint that wishes to the
start-line.

4. Send the request and wait for a response

5. If the transaction succeeds, send establish a SDP answer via message session,
and B is the signaling
protocol, according endpoint invited by A. A invites B to participate in a
message session by sending a URL that represents the following rules:

1. The C-line session. This
URL is copied unmodified from temporary, and must not duplicate the offer.

2. The M-Line contains URL used for any other
active sessions.

B "visits" A by connecting to A and sending a dummy port value, VISIT request
containing the protocol field
from URL that A provided. This associates the original offer, and connection
from B with the accept-types attribute
contains session. B then responds to the SEND payload media types invitation, informing
A that B has accepted the answerer is
willing to accept. The accept-types attribute in session. A and B may now exchange messages
using SEND requests on the answer
MUST be connection.

When either party wishes to end the same as that of the offer, or session, it MUST be informs its peer with
a
subset.

3. SIP BYE request. A direction attribute containing the value "active".

6. If the transaction fails, terminates the answerer MAY choose to act as host,
if allowed session by invalidating
associated state, and dropping the direction attribute of the answer. If the
answerer is unable or unwilling connection.

The end to host, then it should return an
error response as appropriate for end case looks something like the signaling protocol.

Some TCP connection failure conditions may ordinarily take some time following. (Note that
the example shows a logical flow only; syntax will come later in this
document.)

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

Campbell, et al. Expires April 22, July 27, 2004 [Page 21] 6]

Internet-Draft MSRP October 2003

to notice. For example, January 2004

A->B (MSRP): 200 OK

5. Architectural Considerations

There are a number of considerations that, if the offerer is unable to open handled in a TCP
connection to reasonable
fashion, will allow more effective use of the host device, protocols described in
this connection attempt document.

5.1 Transferring Large Content

MSRP endpoints may take a
fairly large number of seconds attempt to timeout. This length of time will send very long messages in a session.
For example, most commercial instant messaging systems have a file
transfer feature. Since MSRP does not be acceptable for many call flow scenarios. Therefore, the
devices SHOULD limit the time they wait for the TCP connection impose message size limits,
there is nothing to a
shorter timeout value, which will default prevent endpoints from transferring files over
it.

An analysis of whether it makes sense to 30 seconds. However, the
offerer MAY supply a different time in do this, rather than sending
such content over FTP, HTTP, or some other such protocol, is beyond
the timeout parameter scope of the
"both" direction value. If the offerer supplies a value, the answerer
SHOULD use that value for the TCP connection timeout, interpreted as
an integer number this document. However, implementers should be aware of seconds.

If the answerer chooses to host the session, it MUST perform
the
following steps:

1. Construct a new session URL . This MUST be a impact of sending very large messages over MSRP. The primary
impact is, since MSRP or MSRPS URL,
MUST resolve to is sent over TCP, is that any additional
messages that the answerer, and MUST not sender wishes to send will be blocked until the same as the
session URL in the offer. The URL SHOULD be temporary, SHOULD be
hard
large transfer is complete. This includes responses to guess, and MUST not duplicate URLs currently identifying
any active sessions hosted messages sent
by the answerer.

2. Listen for a connection from the peer.

3. Construct an SDP answer as described in Section 6, mapping Therefore, any SEND transactions initiated by the
new session URL peer
are likely to time out, even though they are received without
problems.

Further, there is no way to abort the session attribute, and inserting sending of a
direction attribute with very large message
before it is complete. For the value sake of "passive".

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

When the offerer receives efficiency, the SDP answer, it must determine who will
continue framing
mechanism in MSRP is very simple. There is no clean way to host recover
framing if the session. If complete message is not sent.

These issues can be mitigated greatly if the answer contained endpoint simply
establishes a direction
attribute value of "active", the offerer MUST continue as host. If
the offer contained "active" or "both" and the answer contains
"passive", then the offerer MUST allow the answerer to host separate session for the
session.

If transfer. This allows the offerer chooses not
transfer to continue as host, it MUST perform the
following steps:

1. Release resources it acquired in expectation of hosting be sent without interfering with any instant messages
being sent on other sessions. Further, the
session, if any.

2. Determine endpoint can abort the host address and port from
transfer by simply tearing down the transfer session. Therefore, if a
peer wishes to send very large content, it SHOULD establish a
dedicated session URL of for that purpose. It should also indicate that the
answer, following
dedicated session is send only, so that the procedures in section Section 7.1

3. Connect receiving endpoint does
not attempt to send content back along the host address and port, same session.

6. SDP Offer-Answer Exchanges for MSRP Sessions

MSRP sessions will typically be initiated using the transport Session
Description Protocol (SDP) [1] offer-answer mechanism, carried in the
Session Initiation Protocol (SIP) [2] or any other protocol from
supporting it. MSRP borrows the M-line. idea of the direction attributes from

Campbell, et al. Expires April 22, July 27, 2004 [Page 22] 7]

Internet-Draft MSRP October 2003

4. Construct a VISIT request, which MUST contain the following
information:

1. A S-URL header field containing the session URL.

2. A TR-ID header field containing a unique transaction ID.

3. A size field containing size January 2004

COMEDIA [18], but does not depend on that specification.

6.1 Use of the message subsequent to the
start-line.

5. Send the request and wait for a response

6. If the transaction succeeds, set the actual expiration time to
the value in SDP M-line

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

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

For non-RTP media sessions, The media field in the response, and
acknowledge the answer via the signaling protocol. If either specifies the
connection attempt or top level
MIME media type for the VISIT transaction fail, acknowledge session. For MSRP sessions, the
answer, then initiate media field
MUST have the tear-down value of "message". The port field is normally not
used, and MAY be set to any value chosen by the session using endpoint. A port
field value of zero has the
signaling protocol.

7.4.2 Handling VISIT requests

An standard SDP meaning. Non-zero values
MUST not be repeated in other MSRP endpoint that is hosting a session will receive a VISIT
request from m-lines in the visiting endpoint. When an endpoint receives a VISIT
request, it same SDP document.

The proto field MUST perform designate the following procedures:

1. Check if state exists for a message session with mechanism and
transport protocol, separated by a URL that matches the
S-URL "/" character. For MSRP, left part
of this value MUST be "msrp". For MSRP over TCP, the VISIT request. If so, and if no visitor connection
has been associated with right part of
this field MUST take the session, then return a 200 response,
and save state designating value "tcp". For MSRP over other transport
protocols, the connection on which field value MUST be defined by the request
was received specification for
that protocol binding.

The format list list is ignored for MSRP. This is because MSRP
formats are specified as MIME content types, which are not convenient
to encode in the visitor leg of the session.

2. If SDP format list syntax. Instead, the session exists, and allowed formats
are negotiated using "a"-line attributes. For MSRP sessions, the visitor connection has already
been established, return a 506 response and do not change session
state in any way.

3. If no matching session exists, return a 481 request,
format list SHOULD contain a "*" character, and do not
change session state nothing else.

The port field in any way.

7.4.3 Sending Instant Messages on a Session

Once a MSRP session has been established, either endpoint may send
instant messages the M-line is not used to its peer using determine the SEND method. When an endpoint
wishes port to do so, it MUST construct a SEND request according
which to connect. Rather, the
following process:

1. Insert actual port is determined by the message payload in
contents of the body, and session URL (Section 7.1). However, a port value of
zero has the media type in normal SDP meaning.

The following example illustrates an m-line for a message session,
where the
Content-Type header field. endpoint is willing to accept root payloads of message/
cpim, plain text or HTML. The media type MUST match second two types could either be
presented as the root body, or could be contained within message/cpim
bodies.

m=message 9999 msrp/tcp *

6.2 The Direction Attribute

Since MSRP uses connection oriented transport protocols, one goal of
the
types in SDP negotiation is to determine which participant initiates the format list negotiated in
transport connection. The direction attribute advertises whether the SDP exchange. If a "*"
offerer or answerer wishes to initiate the connection, wishes the
peer endpoint to initiate the connection, or doesn't care.

Campbell, et al. Expires April 22, July 27, 2004 [Page 23] 8]

Internet-Draft MSRP October 2003

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.

2. Set the TR-ID header field to a unique value.

3. Send the request on January 2004

The endpoint that accepts the connection associated with the session.

4. If a 2xx response code is received, said to "host" the transaction was
successful.

5. If a 5xx response code
session, and is received, the transaction failed, but
other transactions may still succeed in known as the future. hosting endpoint. The endpoint
MAY attempt to send the message content again in a new request, that is, with a new TR-ID value. If
initiates the endpoint receives 5xx
responses more than some threshold number of times in a row, it
SHOULD assume connection is said to "visit" the session has failed, session, and initiate tear-down via is known
as the signaling protocol. visiting endpoint.

The threshold value direction attribute is included in an SDP a-line, with a matter of local
policy.

6. If a 415 response is received, this indicates the recipient is
unable or unwilling to process value
taking the media type. The sender SHOULD
NOT attempt to send that particular media type again following syntax:

direction = direction-label ":" role
direction-label = "direction"
role = active / passive / both
active = "active" sp count
passive = "passive" sp count
both = "both" sp count [sp timeout]
count = 1*DIGIT ; Connection count
timeout = 1*DIGIT ; timeout value in seconds

The values for the
context of this session.

7. If any other response code is received, the endpoint SHOULD
assume the session has failed, and initiate tear-down.

Normally transaction timeouts role field are treated the same as transactions
that receive 5xx responses But, unlike transactions that fail
explicitly, requests that have been timed out may in fact have
been delivered follows:

passive: The endpoint wishes to host the session

active: The endpoint wishes the peer endpoint, and even presented to host the
user. Attempting session.

both: The endpoint is willing to resend such messages act as either host or visitor. If
"both" is selected, it may result in contain an optional timeout value. This
timeout specifies how much time the peer
user seeing duplicate messages. Therefore a client implementation answerer should take such action carefully, wait before
giving up on a connection and should clearly indicate the
situation attempting to take over as host
device. If the user.

Open Issue: Do we need timeout value is not specified, it defaults to create 30
seconds.

The SDP offer for an MSRP session MUST contain a duplicate suppression
mechanism? direction attribute,
which MAY take any of the defined values. If retries were sent with with the TR-ID, then offerer is capable
of hosting the
recipient could recognize a duplicate message if session, then it occurs in the
same session.

When an SHOULD select "both". The endpoint receives a SEND request, it MUST perform the
following steps.

1. Determine that
SHOULD NOT select "active" unless it understands the media type in cannot host the body, if session under
any
exists.

Campbell, et al. Expires April 22, 2004 [Page 24]

Internet-Draft MSRP October 2003

2. If circumstances. The endpoint SHOULD NOT select "passive" unless it does, return a 200 response and render the message
has no option but to host the
user. session.

The method of rendering count is used to determine if a matter of local policy.

3. If it does not understand the media type, return new connection is required in
future SDP exchanges for a 415 response.

7.4.4 Ending given stream. For the initial SDP
exchange, the count pamameter MUST be set to zero. Endpoints sending
a Session

When either endpoint in an MSRP session wishes new offer related to end an existing stream MUST increment this count
from the session, it
first signals its intent using value in the normal processing most recent successful exchange for the
signaling protocol. For example, in SIP, it would send stream.

The SDP answer also MUST contain a BYE request
to direction attribute, but its value
choices are limited based on the peer. After agreeing to end value in the session, offer. If the host endpoint offer
contained "active", then the answerer MUST release any resources acquired as part of either select "passive" or
reject the session. The
process for this differs depending on whether offer. Likewise, if the session is hosted
directly by offer contained "passive", then
the host, or by a relay.

The host answerer MUST destroy local state for the session. This involves
completely removing select "active" or reject the state entry for this session and invalidating
session URL. offer. If the host is using an offer

Campbell, et al. Expires July 27, 2004 [Page 9]

Internet-Draft MSRP relay, January 2004

contained "both", the answerer SHOULD select "active", but MAY select
"passive" if it is unable to reach the host device, or if local
policy requires it to act as host. The answerer MUST send a BIND
containing an expires set the count
parameter to the same value of zero. This request MUST be sent on as that in the
host connection established by offer.

6.3 The Accept Types Attribute

MSRP can carry any MIME encoded payload. Endpoints specify MIME
content types that they are willing to receive in the original BIND request. accept types
"a"-line attribute. This BIND
request attribute has the following syntax:

SDP offers for MSRP sessions MUST include an accept-types attribute.
SDP answers MUST also include the session URL in attribute, which MUST contain
either the S-URL header field.

Since these host actions completely destroy same list as in the session state at offer or a subset of that list.

A "*" entry in the hosting device, accept-types attribute indicates that the visitor is not required sender
may attempt to take further
action beyond cleaning up any local state. send messages with media types that have not been
explicitly listed. If for some reason the
host fails receiver is able to destroy session state, the state will be invalidated
anyway when process the inactivity timer expires.

When an endpoint chooses to close a session, it may have SEND
transactions outstanding. For example, media type,
it may have send SEND requests
to which does so. If not, it has not yet received will respond with a response, or it may have received
SEND requests 415. Note that to which it has not responded. Once an endpoint
has decided to close the connection, it SHOULD wait for such
outstanding transactions to complete. It all
explicit entries SHOULD NOT generate any new
SEND transactions, and it MAY choose not to respond to be considered preferred over any new SEND
requests non-listed
types. This feature is needed as, otherwise, the list of formats for
rich IM devices may be prohibitively large.

The accept-types attribute may include container types, that is, mime
formats that contain other types internally. If compound types are received after it decides to close
used, the session. It
SHOULD not respond to any new messages types listed in the accept-types attribute may be used both
as the root payload, or may be wrapped in a listed container type.
(Note that arrive after it signals
its intent to close the session.

When container type MUST also be listed in the accept-types
attribute.)

6.4 MIME Wrappers

The MIME content-types 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 is signaled of its peer's intent will need to close specify a session,
it SHOULD NOT initiate any more SEND requests. It SHOULD wait for any
outstanding transactions MIME body type that it initiated to complete, and it SHOULD
attempt respond to any open SEND transactions received prior to being
signaled.

It is not possible can only be used
if wrapped inside a listed container type.

Endpoints MAY specify MIME types that are only allowed to completely eliminate be wrapped
inside compound types using the chance of a session
terminating with incomplete SEND transactions. When this occurs, "accept-wrapped-types" attribute in
an
endpoint SHOULD clearly inform the user that SDP a-line. This attribute has the messages mat not following syntax:

Campbell, et al. Expires April 22, July 27, 2004 [Page 25] 10]

Internet-Draft MSRP October 2003

have been delivered.

7.4.5 Session Inactivity Timer

State associated with MSRP sessions, either at January 2004

accept-wrapped-types = wrapped-types-label ":" format-list
wrapped-types-label = "accept-wrapped-types"
`

The format-list element has the host endpoint, or
a hosting or visiting relay, is soft-state; that is, it expires over
time if no message activity occurs. Each such device maintains a pair
of inactivity timer, each with an initial value of 12 minutes. One identical syntax as defined for the
accept-types attribute. The semantics for this attribute are
identical to those of
these timers is assigned the accept-types attribute, with the exception
that the specified types may only be used when wrapped inside
containers. Only types listed in accept-types may be used as the
"root" type for each endpoint.

All devices use the same, predetermined timer expiration value.
While there might entire body. Since any type listed in
accept-types may be some utility used both as a root body, and wrapped in other
bodies, format entries from the m-line SHOULD NOT be repeated in negotiating this timer on a
per device basis, such negotiation would add
attribute.

This approach does not allow for specifying distinct lists of
acceptable wrapped types for different types of containers. If an
endpoint understands a great deal MIME type in the context of
complexity one wrapper, it is
assumed to MSRP. The choice understand it in the context of 12 minutes is somewhat
arbitrary, but is intended any other acceptable
wrappers, subject to balance any constraints defined by the bandwidth overhead
against how quickly a relay can shed stale sessions. Since host
endpoints will normally explicitly destroy sessions, stale
sessions should wrapper types
themselves.

The approach of specifying types that are only occur under failure conditions.

Open Issue: In the 2 relay use case, the visitor does not
explicitly remove state allowed inside of
containers separately from the visiting relay. Rather, the
visiting relay must infer that a session has been removed when the
host device closes the connection, or when primary payload types allows an
endpoint to force the inactivity timer
expires.

When use of certain wrappers. For example, a hosting CPIM
gateway device or visiting relay returns a successful response may require all messages to a VISIT request, it MUST initialize both timers. The device MUST
reset a timer anytime the associated endpoint sends a SEND request.
If either timer expires without being reset, be wrapped inside
message/cpim bodies, but may allow several content types inside
the device MUST
invalidate wrapper. If the session, using normal procedures depending on gateway were to specify the
device's role wrapped types in
the session.

Each endpoint MUST keep a similar timer, which it initializes when accept-types attribute, its peer could choose to use those
types without the wrapper.

6.5 URL Negotiations

An MSRP session is created from its perspective. For the host endpoint,
this identified by an MSRP URL, which is when it receives a successful response to a BIND request. For
a visiting determined by
the hosting endpoint, this is when it sees a successful response to a
VISIT request. Each endpoint resets its timer whenever it sends a
SEND request. If an endpoint inactivity timer approaches expiration, and the endpoint wishes to continue participating negotiated in the SDP exchange. Any SDP
offer or answer that creates a possibility that the sender will host
the session, that is, it contains a direction value of "passive" or
"both", MUST send contain an MSRP URL in a SEND request. session attribute. This request MAY be sent without a body if
there is no user data to send. Endpoints MUST select
attribute has the timer value
so that there following syntax:

a=session:<MSRP_URL>

where <MSRP_URL> is sufficient time for an MSRP or MSRPS URL as defined in Section 7.1.

The visitor will use the SEND request session URL established by the host both to traverse
resolve the host address and port, and to identify the opposite endpoint. If session when
connecting. For MSRP sessions, the endpoint waits to address field in the last moment,
there C-line is a danger that it will not
relevant, and MUST be received by all relevant
devices ignored. The port field in time to prevent session destruction. the M-line MUST be
ignored if non-zero. Zero values have the normal meaning for SDP.

Campbell, et al. Expires April 22, July 27, 2004 [Page 26] 11]

Internet-Draft MSRP October 2003

Open Issue: There has been list discussion suggesting we should
have January 2004

The following example shows an SDP offer with a separate KEEPALIVE method session URL of
"msrp://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/tcp *
a=accept-types:text/plain
a=direction:both 0
a=session:msrp://example.com:7394/2s93i

The session URL MUST be a temporary URL assigned just for this purpose, rather than
using SEND requests.

7.4.6 Managing Session State and Connections

A MSRP session is represented by state at the host device. As mention
previously,
particular session. It MUST NOT duplicate any URL in use for any
other session state is identified hosted by an MSRP URL. An active
session also has two associated network connections. The connection
between the hosting device and endpoint. Further, since the host peer
endpoint is known as will use the host
connection. The session URL to identify itself when connecting,
it SHOULD be hard to guess, and protected from eavesdroppers. This
will be discussed in more detail in Section 10.

6.6 Updated SDP Offers

MSRP endpoints may sometimes need to send additional SDP exchanges
for an existing session. For example, they may need to negotiate a
new connection because of a TCP failure or some other reason. They
may need to send periodic exchanges with no change to refresh state
in the visiting endpoint is network, for example, SIP timers. They may need to change some
other stream in a session without affecting the visiting
connection. Note MSRP stream, or they
may need to change an MSRP stream without affecting some other
stream.

Once MSRP endpoints have completed an intitial negotiation, further
exchanges do not change their roles as the active or passive party
for that when particular stream. This means that if the visitor sends a
new SDP offer, it MUST remain the session state is hosted directly by visitor, i.e. it MUST offer a
direction of "active" and it MUST NOT include an endpoint, MSRP URL. Likewise,
if the host connection may not involve sends a physical network
connection; rather new offer, it is MUST include a logical connection the device maintains
with itself.

When session state is destroyed for any reason, the hosting device
SHOULD drop the connection(s). direction of
"passive" and it MUST include a URL. Updated offers MUST NOT include
a direction of "both."

If offering party wishes to establish a new connection fails for any reason, as a result of
the session hosting device updated exchange, it MUST
invalidate increment the session state. This is true regardless count parameter in the
direction attribute from that of whether the
dropped connection is most recent successful exchange.
If the host or visiting connection. Once a
connection is dropped, passive endpoint wishes the associated session state the visitor to re-connect, it the
included URL MUST NOT be
reused. If different than the endpoints wish to continue URL from previous offers.
This new URL MAY be completely different from the original and MAY
even resolve to communicate after a
connection failure, they must initiate different location. If the active party sends a new session. An endpoint
detecting a connection failure SHOULD attempt to tear down the
session using the rules of
offer with an incremented count parameter, the signaling protocol.

It would be nice to allow sessions to be recovered after passive party MUST
supply a
connection failure, perhaps by allowing new URL, or reject the opposite endpoint to
reconnect, and send offer. If either party sends a new VISIT or BIND request. However,

Campbell, et al. Expires July 27, 2004 [Page 12]

Internet-Draft MSRP January 2004

offer with the same count value as the previous exchange, the session
URI MUST NOT change.

If this
approach creates negotiation results in a race condition between the time that new session URL, the
hosting device notices active party
MUST close the failed existing connection, open a new connection, and the time that
the endpoint tries send a
VISIT request as described below.

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

6.7 Example SDP Exchange

Endpoint A wishes to reconnect prior invite Endpoint B to a MSRP session. A offers
the hosting device noticing the
failure, the hosting device will interpret following session description containing the recovery attempt as
a conflict. The only way around this would be following lines:

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/tcp *
a=accept-types: message/cpim text/plain text/html
a=direction:both 0
a=session:msrp://alice.example.com:7394/2s93i9

Endpoint B chooses to force participate in the hosting
device role of visitor, opens a TCP
connection to do alice.example.com:7394, and successfully performs a liveness check on
VISIT transaction passing the original connection, which
would create a lot URL of complexity and overhead msrp://alice.example.com:7394/
2s93i9. B indicates that do not seem it has accomplished this by answering with:

v=0
o=userb 2890844530 2890844532 IN IP4 bob.example.com
s=
c=IN IP4 dontlookhere
t=0 0
m=message 9999 msrp/tcp *
a=accept-types:message/cpim text/plain
a=direction:active 0

A may now send IMs to
be worth the trouble.

7.5 MSRP Relays

MSRP supports B by executing SEND transactions on the use of message relays. This specification describes same
connection on which B sent the use of one or two relays. While more than two relays are not
forbidden by MSRP, VISIT request.

7. The Message Session Relay Protocol

The Message Session Relay Protocol (MSRP) is a solution text based, message
oriented protocol for an arbitary number the transfer of relays is
beyond instant messages in the scope context
of this document. a session. MSRP uses the UTF8 character set.

Campbell, et al. Expires April 22, July 27, 2004 [Page 27] 13]

Internet-Draft MSRP October 2003

7.5.1 Establishing Session State at a Relay

An endpoint that wishes to host January 2004

MSRP messages MUST be sent over a reliable, congestion-controlled,
connection-oriented transport protocol. This document specifies the
use of MSRP session MAY do so over TCP. Other documents may specify bindings for other
such protocols.

7.1 MSRP URLs

MSRP sessions are identified by
initiating session state at a MSRP relay, rather than hosting
directly. URLs. An endpoint may wish to do this because network topology or
local policy prevents MSRP URL follows a peer from connecting directly to
subset of the
endpoint. The use URL syntax in Appendix A of RFC2396 [4], with a relay should not be scheme
of "msrp":

msrp_url = "msrp" ":" "//" [userinfo] hostport ["/' resource]
resource = 1*unreserved

The constructions for "userinfo", "hostport", and "unreserved" are
detailed in RFC2396 [4].

An MSRP URL server part identifies the default case, that is,
a hosting endpoint that is not prevented from doing so by topology or
policy SHOULD host the session directly. In order to use a relay, an
MSRP endpoint MUST have knowledge device of that relay's existence and
location.

We previously mentioned how an endpoint wishing to host a MSRP
session constructs
session. If the session URL. When using server part contains a relay, the endpoint
delegates that responsibility to the relay.

To establish numeric IP address, it MUST
also contain a port. The resource part identifies a particular
session state at a relay, the endpoint MUST perform that host device. The absence of the
following steps:

1. Open resource part
indicates a network connection reference to the relay at the relays address and
port. Normally, this information will be resolved from an MSRP
URL representing host device, but does not
specifically refer to a particular session resource.

MSRP has an IANA registered recommended port defined in Section 9.1.
This value is not a default, as the relay, although URL process described herein will
always explicitly resolve a port number. However, the relay MAY URLs SHOULD be
configured
with an explicit address and port, rather than a URL.

2. Construct a BIND request with a S-URL so that refers to the relay.

3. Set the Exp header field recommended port is used whenever appropriate.
This makes life easier for network administrators who need to manage
firewall policy for MSRP.

The server part will typically not contain a desired value.

4. Send the BIND request on the connection.

5. Respond userinfo component, but
MAY do so to any authentication request from the relay.

6. If the response has indicate a 2xx status code, use the URL in the S-URL
header field as user account for which the session URL. The endpoint uses is valid.
Note that this URL in
exactly is not the same manner thing as it had constructed it itself.
Additionally, accept identifying the expires value session
itself. If a userinfo component exists, MUST be constructed only from
"unreserved" characters, to avoid a need for escape processing.
Escaping MUST NOT be used in the response as
pre-visit expiration time.

A an MSRP relay listens for connections at all times. When it receives URL. Furthermore, a
BIND request, it SHOULD authenticate the request, either using
digest-authentication, TLS authentication, or some other
authentication mechanism. If authentication succeeds, the relay
performs the following steps:

1. Verify the client userinfo
part MUST NOT contain password information.

The following is authorized to BIND to this relay. If not,
return an example of a 403 response and make no state change. typical MSRP URL:

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

7.1.1 MSRP URL Comparison

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

Campbell, et al. Expires April 22, July 27, 2004 [Page 28] 14]

Internet-Draft MSRP October 2003

2. If the client is authorized, construct a session MSRP URL. January 2004

1. The
URL MUST resolve to the relay. It SHOULD be temporary, and hard
to guess. It MUST not duplicate any URL used in any active
sessions hosted by the relay. host part is compared as case insensitive.

2. If the relay wishes the visiting
endpoint to connect over a port other than the MSRP relay
well-know port, it MUST exists explicitly add the in either URL, then it must match
exactly. An URL with an explicit port number is never equivalent to visitor
URL.
another with no port specified.

3. Establish the pre-visit expiration time for the session according
to Section 7.4.5.

4. Create state for the session. The relay MUST associate the
connection on which the BIND request arrived resource part is compared as the host
connection for the session.

5. Return case insensitive. A URL without
a 200 response, with the session resource part is never equivalent to one that includes a
resource part.

4. Userinfo parts are not considered for URL in the S-URL header
field, and the pre-visit session expiration time in the Exp
header field.

When an comparison.

Path normalization is not relevant for MSRP relay receives a VISIT request, it MUST perform the
following steps:

1. Check URLs. Escape
normalization is not required, since the S-URL header field value relevant parts are limited
to see it matches unreserved characters.

7.1.2 Resolving MSRP Host Device

An MSRP host device is identified by the URL for server part of an existing session state entry.

2. MSRP URL.

If not, return the server part contains a 481 response numeric IP address and make no state changes

3. port, they MUST
be used as listed.

If it matches, but another connection has already been associated
with the session URL, return server part contains a 506 response host name and make no state
changes. If the session has been previously associated with this
connection, treat a port, the request as connecting
device MUST determine a refresh.

4. If it matches, host address by doing an A or AAAA DNS query,
and no visiting connection has been previously
associated with the session, then the VISIT succeeds. The relay
assigns the connection on which it received use the VISIT request port as listed.

If the visiting connection for the session, and returns a 200
response.

7.5.2 Removing Session State from a relay

An MSRP relay SHOULD remove state for server part contains a session when any of host name but no port, the connecting
device MUST perform the following conditions occur:

o The session inactivity timer expires.

o The pre-visit timer expires before a VISIT request has occurred.

Campbell, et al. Expires April 22, 2004 [Page 29]

Internet-Draft MSRP October 2003

o The host sends a BIND refresh request matching with steps:

1. Construct an expiration
value of zero.

o Either SRV [6] query string by prefixing the host or visitor network connection fails name
with the service field "_msrp" and the protocol field ("_tcp" for any
reason.

7.5.3 Sending IMs across an MSRP relay

Once
TCP). For example, "_msrp._tcp.host.example.com".

2. Perform a session is established at DNS SRV query using this query string.

3. Select a relay, resulting record according to the rules in RFC2782 [6].
Determine the port from the chosen record.

4. If necessary, determine a host and visitor may
exchange IMs device address by sending SEND requests. Under normal circumstances, performing an A
or AAAA query on the relay does not respond to SEND requests host name field in any way. Rather, the
relay MUST forward selected SRV result
record. If multiple A or AAAA records are returned, the request first
entry SHOULD be chosen for the initial connection attempt. This
allows any ordering created in the DNS to be preserved.

5. If the peer connection unchanged.
Likewise, if attempt fails, the relay receives a response it MUST forward device SHOULD attempt to
connect to the
request unchanged on addresses returned in any additional A or AAAA
records, in the peer connection. order the records were presented. If a SEND request arrives on a connection all of these

Campbell, et al. Expires July 27, 2004 [Page 15]

Internet-Draft MSRP January 2004

fail, the device SHOULD attempt to use any additional SRV records
that is not associated with
a session, may have been returned, following the relay MUST return a 481 response.

7.5.4 Relay Pairs normal rules for SRV
record selection.

In rare circumstances, two relays may most cases, the transport protocol will be required in a session. determined separately
from the resolution process. For example, two endpoints may exist if the MSRP URL was
communicated in separate administrative domains,
where each domain's policy insist that all sessions must cross that
domain's relay. A relay operating on behalf of an SDP offer or answer, the visiting endpoint
is known as a visiting relay. An SDP M-line will contain
the transport protocol. When an MSRP relay MAY be capable of acting
as a visiting relay.

This document does not describe URL is communicated outside of
SDP, the protocol SHOULD also be communicated. If a mechanism for an endpoint to
discover that it device needs to use a visiting relay. We assume that
resolve an
endpoint is globally configured to use or not use such a relay, MSRP URL and does not make this decision on a session-by-session basis.
This, of course, does not preclude using some other mechanism to
make such a decision.

In a two relay scenario, the visitor connects to a relay operating on
its behalf, rather than connecting directly to know the hosting device.
The visitor sends a VISIT request as it would if protocol, it had connected
directly to the hosting device. SHOULD assume
TCP.

7.1.3 The visiting relay then connects to
the hosting device and performs a VISIT request on behalf of the
visitor.

When a relay msrps URL Scheme

The "msrps" URL Scheme indicates that each hop MUST be secured with
TLS. Otherwise, it is capable of acting used identically as an MSRP URL, except that a visiting relay receives a
VISIT request, it
MSRPS URL MUST check NOT be considered equivalent to see if an MSRP URL. The MSRPS
scheme is further discussed in Section 10.

7.2 MSRP messages

MSRP messages are either requests or responses. Requests and
responses are distinguished from one another by the S-URL first line. The
first line of the request
matches a domain that Request takes the relay hosts. If form of the URL matches, then request-start entry
below. Likewise, the
visitor is not requesting first line of a response takes the relay act form of
response-start. The syntax for an MSRP message is as a visiting relay, and it
SHOULD operate normally. If follows:

msrp-message = request-start/response-start *(header CRLF)
[CRLF body]
request-start = "MSRP" SP length SP Method CRLF
response-start = "MSRP" SP length SP Status-Code SP
Reason CRLF

length = 1*DIGIT ; the URL does not match, then length of the relay
SHOULD perform message,
; exclusive of the following steps: start line.
Method = SEND / VISIT / other-method
other-method = token
header = Transaction-ID / Session-URL / Content-Types
Status-Code = 200 ;Success
/ 400 ;Bad Request
/ 403 ;Forbidden
/ 415 ;Unsupported Content Type
/ 426 ;Upgrade Required
/ 481 ;No session
/ 506 ;duplicate session

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

Campbell, et al. Expires April 22, July 27, 2004 [Page 30] 16]

Internet-Draft MSRP October 2003

1. The relay SHOULD authenticate the VISIT request, using digest
authentication or some other mechanism.

2. Determine that the visiting endpoint is authorized to use this
device as a visiting relay. If not, return a 403 response and
drop the connection.

3. Attempt to open a connection to the hosting device, determining
the address January 2004

Content-Type = "Content-Type" ":" quoted-string
Session-URL = "S-URL" ":" msrp_url

All requests and port from the S-URL exactly as if it were a
visiting endpoint connecting directly. If this connection is
successful, continue with the remaining steps. Otherwise, return responses MUST contain at least a 500 response.

4. Create local state to associate the connection to the host device
with the connection to the visiting device.

5. Relay the VISIT request unchanged to the hosting device.

6. Relay TR-ID header
field. Messages MAY contain other fields, depending on the method or
response to the VISIT code.

7.3 MSRP Transactions

An MSRP transaction consists of exactly one request unchanged to the visiting
endpoint.

7. Relay all subsequent requests arriving on and one of response.
A response matches a transaction if it share the associated
connections to same TR-ID value,
and arrives on the peer connection.

If either associated same connection fails for any reason, on which the visiting
relay transaction was sent.

Endpoints MUST invalidate select TR-ID header field values in requests so that
they are not repeated by the session state, and same endpoint in scope of the given
session. TR-ID values SHOULD be globally unique. The TR-ID space of
each endpoint is independent of that of its peer. Endpoints MUST drop NOT
infer any semantics from the peer
connection.

7.5.5 Relay Shutdown

Relay administrators will occasionally need TR-ID header field beyond what is stated
above. In particular, TR-ID values are not required to take follow any
sequence.

MSRP relays out
of service. A relay implementation SHOULD allow Transactions complete when a graceful shutdown
that minimizes the occurrence of "lost", response is received, or timed out, messages. When after a relay effects
timeout interval expires with no response. Endpoints MUST treat such
timeouts in exactly the same way they would treat a graceful shutdown, it 500 response. The
timeout interval SHOULD refuse all new
connection attempts, and refuse all be 30 seconds, but other values may be
established as a matter of local policy.

7.4 MSRP requests, returning 481
responses. In order to allow any open transactions Sessions

AN MSRP session is a high chance context in which a series of
completion, the relay SHOULD wait at least one transaction timeout
period (normally 30 seconds) between the time it starts refusing
requests and the time it closes existing connections instant messages
are exchanged, using SEND requests. A session has two endpoints (a
host and shuts down.

Open Issue: We have discussed that a visitor). A session is identified by an MSRP URL.

7.4.1 Initiating an MSRP session

When an endpoint implementation may
attempt wishes to establish engage a new session (perhaps using peer endpoint in a different
relay) with its peer. Do message
session, it invites the peer to communicate using an SDP offer,
carried over SIP or some other protocol supporting the SDP offer/
answer model. For the purpose of this document, we wish will refer to specify anything at all about
such behavior?

7.6 Digest Authentication

MSRP relays may use the digest authentication scheme
endpoint choosing to initiate communication as the offerer, and the
peer being invited as the answerer.

The offerer SHOULD volunteer to act as the hosting endpoint if
allowed by policy and network topology. The peer that is not the host
is designated as the visitor. The offerer MAY request the answerer to authenticate
act as host if it is prevented from accepting connections by network
topology or policy.

Campbell, et al. Expires April 22, July 27, 2004 [Page 31] 17]

Internet-Draft MSRP October 2003

users. MSRP digest authentication is January 2004

If the offerer wishes to host the session, it MUST perform the
following steps:

1. Construct a simplified version of HTTP
digest authentication [19], but this specification does not
normatively depend on that document. session MSRP digest authentication does URL . This URL MUST resolve to the
location that the offerer wishes to host the connection. The URL
SHOULD be temporary, SHOULD be hard to guess, and MUST not support
duplicate the concept URL of any other session currently hosted by the
offerer.

2. Listen for a protection domain, nor does it support
integrity protection. Since a user connection from the peer.

3. Construct an SDP offer as described in Section 6, including the
list of a relay is expected to have
credentials for that particular relay, it does not support allowed IM payload formats in the realm
concept. Finally, since digest authentication is only expected for accept-types attribute.
The offerer maps the initial BIND or VISIT request, MSRP does not support HTTP digest
optimizations such as MD5-sess and preemptive credential loading by session URL to the client.

Typically, a hosting user that uses a relay will have session attribute, as
described in Section 6.5.

4. Insert a preexisting
relationship with that relay. direction attribute. This relationship SHOULD include
authentication credentials. An MSRP relay value SHOULD authenticate initial
BIND requests.

It is less likely be "both",
indicating that the visiting user offerer will have an account at allow the
hosting relay, so in most cases answerer to override
the authentication of VISIT requests offerer's decision to host. If "both" is not useful. However selected, the
offerer SHOULD leave the timeout at the default value (by leaving
out the value entirely. However, the offerer MAY select a relay
different timeout if circumstances warrant it. The direction
value MAY authenticate initial VISIT
requests. A visiting relay SHOULD authenticate initial VISIT
requests, as it be "passive" if the offerer is much more likely to share credentials with prevented from allowing
the
visiting user.

There has been some discussion that a hosting relay SHOULD answerer override this choice. The direction attribute must
also
authenticate VISIT requests. However, it contain the count parameter, which will be common set to zero for
an initial exchange.

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

If the offerer chooses to force the answerer to host the session, it
MUST perform the following steps instead:

1. Construct an SDP offer as described above, but with no session
attribute.

2. Insert a direction attribute with a value of "active", with an
appropriate count parameter value.

3. Send the offer using normal processing for
visiting users to have no preexisting relationship with the host
relay. Using authentication here would require signaling
protocol.

When the host endpoint
to send temporary credentials in answerer receives the SDP exchange, perhaps as part
of the session URL. However, these temporary credentials would
necessarily be transferred via offer and chooses to participate
in the same channels session, it must choose whether to act as the session
URL itself. If host or the credentials are sufficiently protected
visitor. A direction attribute value of "both" in
transfer, then so is the session URL. Further, since offer indicates
that the session
URL is intended for a one time use, and is expected offerer prefers to be hard host, but will allow the answerer to
guess, that URL itself should be sufficient for this purpose. Any
situation where
host. In this is not adequate can be covered by case the use answerer SHOULD act as the visitor, but MAY
choose to host. A value of "passive" means the MSRPS scheme. offerer insists upon

Campbell, et al. Expires July 27, 2004 [Page 18]

Internet-Draft MSRP relays January 2004

hosting, in which case the answerer MUST NOT request authentication for any method other than
BIND and VISIT. act as visitor or decline
the offer.

If a relay wishes the answerer chooses to authenticate participate as a request using digest
authentication, visitor, it MAY challenge the request by responding with a
401 response, which MUST include a SChal header field.

If an endpoint wishes to respond to a digest authentication challenge
received perform
the following steps:

1. Determine the host address and port from the session URL,
following the procedures in section Section 7.1

2. Connect to the host address and port, using the transport
protocol from the M-line.

3. Construct a 401 response, it MAY do so by sending a new VISIT or
BIND request, identical to which MUST contain the previous request, but with a CAuth following
information:

1. An S-URL header field containing the response to session URL.

2. A TR-ID header field containing a unique transaction ID.

3. A size field containing size of the challenge.

Campbell, et al. Expires April 22, 2004 [Page 32]

Internet-Draft MSRP October 2003

7.6.1 The SHA1 Algorithm

The only digest authentication algorithm defined in this
specification is SHA1. [9] Other algorithms can be added as
extensions. SHA1 is message subsequent to the default algorithm if no algorithm directive
is present in
start-line.

4. Send the challenge. All MSRP devices MUST support SHA1.

Open Issue: Do we need to specify how to offer more than one
algorithm in a challenge? Do we need multiple algorithms possible request and wait for a particular challenge, or should we follow response

5. If the HTTP digest
approach of multiple challenges. It has been suggested that SHA1
MUST always be offered, transaction succeeds, send a SDP answer via the signaling
protocol, according to ensure that the client and server will
have at least one common algorithm. following rules:

1. The SHA1 digest C-line is defined as follows:

Let KD(secret, data) denote the string obtained by performing the
digest algorithm to copied unmodified from the data "data" with offer.

2. The M-Line contains a dummy port value, the secret "secret". Let
H(data) denote protocol field
from the string obtained by performing original offer, and the checksum
algorithm on accept-types attribute
contains the data "data".

For SEND payload media types that the "SHA1" algorithm, H(data) = SHA1(data), and KD(secret,data) =
H(concat(secret, ":", data)

Section 7.2 describes answerer is
willing to accept. The accept-types attribute in the syntax for answer
MUST be either the request-digest value in a
CAuth header same as 40 digits in lower case hexadecimal notation. The
actual structure that of the field is defined as follows. Note that
unq(quoted-string) denotes offer, or it MUST be a
subset.

3. A direction attribute containing the value of the string with "active", and the quotes
removed.

request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > <">
A1 = unq(username-value) ":" shared-secret ; "unq" denotes removal of quotes
A2 = concat(Method,TR-ID,S-URI)

When
count value copied from the relay receives a CAuth header, it SHOULD check its validity
by looking up offer.

6. If the shared secret, or H(A1), performing transaction fails, the same digest
operation answerer MAY choose to act as performed host,
if allowed by the client, and comparing direction attribute of the results to answer. If the request-digest value.

7.7 Method Descriptions

This section summarizes
answerer is unable or unwilling to host, then it should return an
error response as appropriate for the purpose of each MSRP method. All MSRP
messages MUST contain signaling protocol.

Some TCP connection failure conditions may ordinarily take some time
to notice. For example, if the TR-ID header fields. All messages MUST
contain offerer is unable to open a length field in the start line that indicates TCP
connection to the overall host device, this connection attempt may take a
fairly large number of seconds to timeout. This length of the request, including any body, but not including the
start line itself. Additional requirements exist depending on the
individual method. Except where otherwise noted, all requests are hop
by hop. time will

Campbell, et al. Expires April 22, July 27, 2004 [Page 33] 19]

Internet-Draft MSRP October 2003

7.7.1 BIND

The BIND method is used by a host endpoint to establish or refresh
session state at a hosting relay. BIND requests SHOULD January 2004

not be
authenticated. BIND requests MUST contain the S-URL and Exp header
fields and MAY contain the CAuth header fields.

A successful response to a BIND request MUST contain the S-URL and
Exp header fields.

7.7.2 SEND

The SEND method is used by both acceptable for many call flow scenarios. Therefore, the host and visitor endpoints to
send instant messages to its peer endpoint. SEND requests
devices SHOULD
contain limit the time they wait for the TCP connection to a MIME body part. The body MUST be of
shorter timeout value, which will default to 30 seconds. However, the
offerer MAY supply a media type included different time in the format list negotiated in timeout parameter of the SDP exchange.
"both" direction value. If a body is
present, the request MUST contain offerer supplies a Content-Type header field
identifying value, the media type answerer
SHOULD use that value for the TCP connection timeout, interpreted as
an integer number of seconds.

If the body.

Unlike other methods, SEND requests are end answerer chooses to end in nature. host the session, it MUST perform the
following steps:

1. Construct a new session URL . This
means MUST be a MSRP or MSRPS URL,
MUST resolve to the request is consumed only by answerer, and MUST not be the opposite endpoint. Under
normal conditions, any intervening relays merely forward same as the request
on towards
session URL in the peer endpoint.

7.7.3 VISIT offer. The visiting endpoint uses the VISIT method URL SHOULD be temporary, SHOULD be
hard to associate guess, and MUST not duplicate URLs currently identifying
any active sessions hosted by the answerer.

2. Listen for a network connection with from the session state at peer.

3. Construct an SDP answer as described in Section 6, mapping the hosting device, which could
be either
new session URL to the host endpoint or session attribute, insert a relay operating on behalf direction
attribute with the value of "passive", and the
host endpoint. The request MUST contain a S-URL header matching count value copied
from the offer.

4. Send the SDP offer using the
session URL.

There is normally no authentication operation normal processing for the VISIT
request. This is because signaling
protocol.

When the session URL acts as a shared secret
between host and offerer receives the visitor. This puts certain requirements on SDP answer, it must determine who will
continue to host the handling of session. If the session URLs that are discussed in Section 10.
However, if answer contained a visiting relay is used, it SHOULD authenticate VISIT
requests.

7.8 Response Code Descriptions

This section summarizes direction
attribute value of "active", the various response codes. Except where
noted, all responses offerer MUST contain a TR-ID header field matching continue as host. If
the
TR-ID header field of offer contained "active" or "both" and the associated request. Responses are never
consumed by relays.

Campbell, et al. Expires April 22, 2004 [Page 34]

Internet-Draft MSRP October 2003

7.8.1 200

The 200 response code indicates a successful transaction.

7.8.2 400

A 400 response indicates a request was unintelligible.

7.8.3 401

A 401 response indicates authentication is required. 401 responses answer contains
"passive", then the offerer MUST NOT be used in response allow the answerer to any method other than BIND and VISIT.
A 401 response MUST contain a SChal header field.

7.8.4 403

A 403 response indicates host the user is
session.

If the offerer chooses not authorized to continue as host, it MUST perform the
action.

7.8.5 415

A 415 response indicates the SEND request contained a MIME
content-type that is not understood by
following steps:

1. Release resources it acquired in expectation of hosting the receiver.

7.8.6 426

A 426 response indicates that
session, if any.

2. Determine the host address and port from the request is only allowed over TLS
protected connections.

7.8.7 481

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

7.8.8 500

A 500 response indicates that a relay was unable to deliver a request
answer, following the procedures in section Section 7.1

3. Connect to the target.

7.8.9 506

A 506 response indicates that host address and port, using the transport
protocol from the M-line.

4. Construct a VISIT request occurred in request, which the
S-URL indicates a session that is already associated with another
connection. A 506 response MUST NOT be returned in response to any
method other than VISIT. contain the following
information:

Campbell, et al. Expires April 22, July 27, 2004 [Page 35]

Internet-Draft MSRP October 2003

7.9 Header Field Descriptions

This section summarizes the various header fields. MSRP 20]

1. A S-URL header fields
are single valued; that is, they MUST NOT occur more than once in a
particular request or response.

7.9.1 TR-ID

The field containing the session URL.

2. A TR-ID header field contains containing a unique transaction identifier used ID.

3. A size field containing size of the message subsequent to map the
start-line.

5. Send the request and wait for a response to

6. If either the corresponding request. A TR-ID value MUST be unique
among all values used by connection attempt or the VISIT transaction fail,
acknowledge the answer, then initiate the tear-down of the
session using the signaling protocol.

7.4.2 Handling VISIT requests

An MSRP endpoint that is hosting a given session will receive a VISIT
request from the visiting endpoint. When an endpoint inside receives a given session.
MSRP elements VISIT
request, it MUST NOT assume any additional semantics perform the following procedures:

1. Check if state exists for TR-ID.

7.9.2 Exp

The Exp header field specifies when a session with a URL that matches the
S-URL of the state associated with a BIND
request will expire, VISIT request. If so, and if no successful VISIT request visitor connection
has been
received. The value is specified as an integer number of seconds from associated with the time session, then return a 200 response,
and save state designating the connection on which the request is received. BIND requests MUST contain this
header field. Furthermore, successful responses to BIND requests MUST
also contain
was received as the Exp header.

The maximum value for visitor leg of the Exp header field is (2**32)-1 seconds.

Exp session.

2. If the session exists, and the visitor connection has already
been established, return a 506 response and do not change session
state in any way.

3. If no meaning if it occurs matching session exists, return a 481 request, and do not
change session state in any way.

7.4.3 Sending Instant Messages on a Session

Once a MSRP session has been established, either endpoint may send
instant messages other than BIND
requests, and responses to those requests. MSRP compliant devices
SHOULD NOT use Exp in other requests or responses, unless that usage
is defined in its peer using the SEND method. When an extension to this specification.

7.9.3 CAuth

The CAuth header field is used by a host endpoint
wishes to offer digest
authentication credentials to do so, it MUST construct a relay, in response SEND request according to the
following process:

1. Insert the message payload in the body, and the media type in the
Content-Type header field. The media type MUST match one of the
types in the format list negotiated in the SDP exchange. If a digest
authentication challenge. CAuth SHOULD NOT be "*"
was present in a request the accept-types attribute, then the media type
SHOULD match one of the explicitly listed entries, but MAY be any method
other than BIND and VISIT.

The syntax of arbitrary value.

2. Set the CAuth credentials is described in Section 7.2

The meaning of each value is as follows:

username: The user's account name.

nonce: The nonce value copied from TR-ID header field to a unique value.

3. Send the challenge.

response: A 32 hex digit string that proves user knowledge of request on the connection associated with the
shared secret. session.

Campbell, et al. Expires April 22, July 27, 2004 [Page 36] 21]

Internet-Draft MSRP October 2003

algorithm: The algorithm value copied from January 2004

4. If a 2xx response code is received, the challenge.

auth-param: Additional parameters for transaction was
successful.

5. If a 415 response is received, this indicates the sake of extensibility.

7.9.4 SChal

The SChal header field recipient is used by a relay
unable or unwilling to carry process the challenge in a
digest authentication attempt. Exactly one SChal header field MUST
exist in a 401 response. media type. The SChal header MUST sender SHOULD
NOT be used attempt to send that particular media type again in any
message except for a 401 response. The syntax for the SChal challenge
is described in Section 7.2

The meaning
context of each value this session.

6. If any other response code is as follows:

digest scheme: A token to identify received, or if the particular authentication
scheme. Since MSRP only supports digest, this value MUST be set to
"Digest"

nonce: A server-specified string, which transaction
times out, the relay SHOULD uniquely
generate each time it sends a 401 response. This string endpoint SHOULD
take assume the form of base64 session has failed, and
initiate tear-down, either ending the session, or hexadecimal data, by sending an
updated SDP offer proposing a new connection. If a new connection
is established, the endpoint MAY choose to resend the content on
the new connection.

Open Issue: Do we need to create a duplicate mechanism to avoid the presence
of suppress
duplicate messages when a double-quote character, which new connection is not allowed.

algorithm: A token indicating the algorithms established in this
fashion? mechanism? List consensus seems to be used indicate we do. We may
need to generate
the digest and checksum. This directive exists for specify that the sake tr-id space spans a sequence of
extensibility; the only value defined by this document is "SHA1".
Absence
connections if they are associated with same stream, and of this directive indicates
course, specify what it means for a value of "SHA1".

7.9.5 Content-Type

The Content-Type header field is used stream to indicate span connections.

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

1. Determine that it understands the MIME media type
of in the body. Content-Type MUST be present body, if any
exists.

2. If it does, return a body is present.

Open Issue: We may need to clean up our MIME usage. This includes
better defining 200 response and render the Content-Type usage possibly moving
content-type into message to the body, indicating MIME version, etc.

7.9.6 S-URL
user. The S-URL header field method of rendering is used to identify a matter of local policy. If the session.
message contained no body at all, the endpoint should quietly
ingore it.

3. If it does not understand the media type, return a 415 response.
The S-URI
header field endpoint MUST be present in a BIND request, NOT return a successful 415 response
to a BIND request, or for any media type
for which it indicated support in the SDP exchange.

7.4.4 Ending a VISIT request.

8. Examples

This section shows some example message flows Session

When either endpoint in an MSRP session wishes to end the session, it
first signals its intent using the normal processing for various common
scenarios. The examples assume SIP is used the
signaling protocol. For example, in SIP, it would send a BYE request
to transport the SDP
exchange. Details peer. After agreeing to end the session, the host endpoint
MUST release any resources acquired as part of the SIP messages session.

The host MUST destroy local state for the session. This involves
completely removing the state entry for this session and SIP proxy infrastructure invalidating
session URL.

Campbell, et al. Expires April 22, July 27, 2004 [Page 37] 22]

Internet-Draft MSRP October 2003

are omitted for the sake of brevity. In January 2004

Since these host actions completely destroy the examples, assume session state at
the
offerer is sip:alice@atlanta.com and hosting device, the answerer visitor is
sip:bob@biloxi.com. In not required to take further
action beyond cleaning up any given MSRP message, local state.

When an "xx" in endpoint chooses to close a session, it may have SEND
transactions outstanding. For example, it may have send SEND requests
to which it has not yet received a response, or it may have received
SEND requests that to which it has not responded. Once an endpoint
has decided to close the length
field indicates 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 to close the actual length session. It
SHOULD not respond to any new messages that arrive after it signals
its intent to close the session.

When an endpoint is signaled of its peer's intent to close a session,
it SHOULD NOT initiate any more SEND requests. It SHOULD wait for any
outstanding transactions that it initiated to complete, and it SHOULD
attempt respond to any open SEND transactions received prior to being
signaled.

It is not possible to completely eliminate the rest chance of the message.

8.1 No Relay

In this scenario, the a session goes directly between endpoints
terminating with no
MSRP relays involved.

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

1. Alice constructs a session URL of msrp://
alicepc.atlanta.com:7777/iau39 transactions. When this occurs, the
endpoint SHOULD clearly inform the user that the messages may not
have been delivered.

7.4.5 Managing Session State and listens for a connection on
TCP port 7777.

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

c=IN IP4 fillername
m=message 9999 msrp/tcp *
a=accept-types:text/plain
a=direction:both

Campbell, et al. Expires April 22, 2004 [Page 38]

Internet-Draft MSRP October 2003

a=session:msrp://alicepc.atlanta.com:7777/iau39

2. Bob opens a TCP connection to alicepc.atlanta.com:7777:

Bob->Alice (MSRP):

MSRP xx VISIT
S-URL:msrp://alicepc.atlanta.com:7777/iau39
Tr-ID: sie09s

3. Alice->Bob (MSRP):

MSRP xx 200 OK
Tr-ID: sie09s
Exp:300

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

c=IN IP4 ignorefield
m=message 9999 msrp/tcp *
a=accept-types:text/plain
a=direction:active

5. Alice->Bob (SIP): ACK
6. Alice->Bob (MSRP):

MSRP xx SEND
TR-ID: 123
Content-Type: "text/plain"
Hi, I'm Alice!

7. Bob->Alice (MSRP):

MSRP xx 200 OK
TR-ID: 123

8. Bob->Alice (MSRP): Connections

A MSRP xx SEND
TR-ID: 456
Content-Type: "text/plain"

Hi, Alice! I'm Bob!

9. Alice->Bob (MSRP): session is represented by state at the host device. As mention
previously, session state is identified by an MSRP xx 200 OK
TR-ID: 456

Campbell, et al. Expires April 22, 2004 [Page 39]

10. Alice->Bob (SIP): BYE

Alice invalidates URL. An active
session and drops also has an associated network connection.

11. Bob invalidates local

When session state is destroyed for any reason, the session.

Bob->Alice (SIP): 200 OK

8.2 Single Relay

This scenario introduces hosting device
SHOULD drop the connection.

If the connection fails for any reason, the session hosting device
MUST invalidate the session state. Once a connection is dropped, the
associated session state MUST NOT be reused. If an MSRP relay at relay.atlanta.com.

Alice Relay Bob
| | |
| | |
|(1) (MSRP) BIND | |
|----------------------->| |
|(2) (MSRP) 200 OK | |
|<-----------------------| |
|(3) (SIP) INVITE | |
|------------------------------------------------>|
| |(4) (MSRP) VISIT |
| |<-----------------------|
| |(5) (MSRP) 200 OK |
| |----------------------->|
|(6) (SIP) 200 OK | |
|<------------------------------------------------|
|(7) (SIP) ACK | |
|------------------------------------------------>|
|(8) (MSRP) SEND | |
|----------------------->| |
| |(9) (MSRP) SEND |
| |----------------------->|
| |(10) (MSRP) 200 OK |
| |<-----------------------|
|(11) (MSRP) 200 OK | |
|<-----------------------| |
| |(12) (MSRP) SEND |
| |<-----------------------|
|(13) (MSRP) SEND | |
|<-----------------------| |
|(14) (MSRP) 200 OK | |
|----------------------->| |
| |(15) (MSRP) 200 OK |
| |----------------------->|
|(16) (SIP) BYE | |
|------------------------------------------------>|
|(17) (MSRP) BIND | |
|----------------------->| |
|(18) (MSRP) 200 OK | | endpoint wishes to
continue to communicate after detecting a connection failure, it MAY
initiate a new SDP exchange to negotiate a new session URL.
Otherwise, it SHOULD attempt to tear down the session using the rules
of the signaling protocol.

It would be nice to allow sessions to be recovered after a
connection failure, perhaps by allowing the active endpoint to
reconnect, and send a new VISIT request. However, this approach
creates a race condition between the time that the hosting device
notices the failed connection, and the time that the endpoint

Campbell, et al. Expires April 22, July 27, 2004 [Page 40] 23]

Internet-Draft MSRP October 2003

|<-----------------------| |
|(19) (SIP) 200 OK | |
|<------------------------------------------------|
| | |
| | |

1. Alice->Relay (MSRP): Alice opens January 2004

tries to recover the session. If the endpoint attempts to
reconnect prior to the hosting device noticing the failure, the
hosting device will interpret the recovery attempt as a conflict.
The only way around this would be to force the hosting device to
do a liveness check on the original connection, which would create
a lot of complexity and overhead that do not seem to be worth the
trouble.

7.5 Method Descriptions

This section summarizes the purpose of each MSRP method. All MSRP
messages MUST contain the TR-ID header fields. All messages MUST
contain a length field in the start line that indicates the overall
length of the request, including any body, but not including the
start line itself. Additional requirements exist depending on the
individual method.

7.5.1 SEND

The SEND method is used by both the host and visitor endpoints to
send instant messages to its peer endpoint. SEND requests SHOULD
contain a MIME body part. The body MUST be of a media type included
in the format list negotiated in the SDP exchange. If a connection to body is
present, the relay, and
sends request MUST contain a Content-Type header field
identifying the following:

MSRP xx BIND
S-URL:msrp://relay.atlanta.com
TR-ID: 321
Exp:600

2. Relay->Alice (MSRP):

MSRP xx 200 OK
TR-ID: 321
S-URL: msrp://relay.atlanta.com:7777/iau39
Exp:300

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

c=IN IP4 dummyvalue
m=message 9999 msrp/tcp *
a=accept-types:text/plain
a=direction:passive
a=session:msrp://relay.atlanta.com:7777/iau39

4. Bob->Alice: Open connection media type of the body.

To Do: We plan to relay.atlanta.com:7777.

Bob->Relay (MSRP):

MSRP xx VISIT
S-URL:msrp://relay.atlanta.com:7777/iau39
TR-ID: sie09s

5. Relay->Bob (MSRP):

MSRP xx 200 OK
TR-ID: sie09s
Exp:300

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

c=IN IP4 nobodybutuschickens
m=message 9999 msrp/tcp *

Campbell, et al. Expires April 22, 2004 [Page 41]

Internet-Draft MSRP October 2003

a=accept-types:text/plain
a=direction:active

7. Alice->Bob (SIP): ACK
8. Alice->Relay (MSRP):

MSRP xx SEND
TR-ID: 123
Content-Type: "text/plain"
Hi, I'm Alice!

9. Relay->Bob (MSRP):

MSRP xx expand the use of MIME headers to allow any
standard MIME header in a SEND
TR-ID: 123
Content-Type: "text/plain"
Hi, I'm Alice!

10. Bob->Relay (MSRP):

MSRP xx 200 OK
TR-ID: 123

11. Relay->Alice (MSRP):

MSRP xx request. This is not included in
this version for the sake of getting the draft out as soon as
possible, but will follow soon.

7.5.2 VISIT

The visiting endpoint uses the VISIT method to associate a network
connection with the session state at the hosting device. The request
MUST contain a S-URL header matching the session URL.

7.6 Response Code Descriptions

This section summarizes the various response codes. Except where
noted, all responses MUST contain a TR-ID header field matching the
TR-ID header field of the associated request.

7.6.1 200 OK
TR-ID: 123

12. Bob->Relay (MSRP):

MSRP xx SEND
TR-ID: 456
Content-Type:"text/plain"

Hi, Alice! I'm Bob!

13. Relay->Alice (MSRP):

MSRP xx SEND
TR-ID: 456
Content-Type: "text/plain"

Hi, Alice! I'm Bob!

14. Alice->relay (MSRP):

MSRP xx

The 200 OK
TR-ID: 456 response code indicates a successful transaction.

Campbell, et al. Expires April 22, July 27, 2004 [Page 42]

15. Relay->Bob (MSRP):

MSRP xx 200 OK
TR-ID: 456

16. Alice->Bob (SIP): BYE

17. Alice->Relay (MSRP): 24]

Internet-Draft MSRP xx BIND
S-URL: msrp://relay.atlanta.com:7777/iau39
TR-ID: 42
Exp:0

18. Relay->Alice (MSRP): Relay invalidates January 2004

7.6.2 400

A 400 response indicates a request was unintelligible.

7.6.3 415

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

7.6.4 426

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

7.6.5 481

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

7.6.6 506

A 506 response indicates that a VISIT request occurred in which the
S-URL indicates a session that is already associated with another
connection. A 506 response MUST NOT be returned in response to any
method other than VISIT.

7.7 Header Field Descriptions

This section summarizes the various header fields. MSRP header fields
are single valued; that is, they MUST NOT occur more than once in a
particular request or response.

7.7.1 TR-ID

The TR-ID header field contains a transaction identifier used to map
a response to the corresponding request. A TR-ID value MUST be unique
among all values used by a given endpoint inside a given session.
MSRP elements MUST NOT assume any additional semantics for TR-ID.

7.7.2 Content-Type

The Content-Type header field is used to indicate the MIME media type
of the body. Content-Type MUST be present if a body is present.

To Do: The work group has agreed to allow the use of any standard
MIME header. This is not reflected in this version, but will be in
a shortly forthcoming one.

Campbell, et al. Expires July 27, 2004 [Page 25]

Internet-Draft MSRP xx 200 OK
TR-ID: 42
Exp:0

19. Bob invalidates local state for January 2004

7.7.3 S-URL

The S-URL header field is used to identify the session.

Bob->Alice (SIP): 200 OK

8.3 Two Relays

In this scenario, both Alice The S-URI
header field must be included in VISIT requests.

8. Example

This section shows an example message flow for the most common
scenario. The example assumes SIP is used to transport the SDP
exchange. Details of the SIP messages and Bob SIP proxy infrastructure
are each required by local
policy to route all sessions through a different local relay. omitted for the sake of brevity. In the example, assume the
offerer is sip:alice@atlanta.com and the answerer is
sip:bob@biloxi.com. In any given MSRP message, an "xx" in the length
field indicates the actual length of the rest of the message.

Alice AtlantaRelay BiloxiRelay Bob
| |
| |
| | | |
|(1) (MSRP) BIND | |
|------------->| | |
|(2) (MSRP) 200 OK | |
|<-------------| | |
|(3) (SIP) INVITE | |
|------------------------------------------->|
| | |(4) (MSRP) VISIT
| | |<-------------|
| |(5)
|----------------------->|
|(2) (MSRP) VISIT |
| |<-------------| |
| |(6) (MSRP) 200 OK |
| |------------->| |
| | |(7)
|<-----------------------|
|(3) (MSRP) 200 OK | | |------------->|
|(8)
|----------------------->|
|(4) (SIP) 200 OK | |
|<-------------------------------------------|
|(9)
|<-----------------------|
|(5) (SIP) ACK | | |
|------------------------------------------->|

Campbell, et al. Expires April 22, 2004 [Page 43]

Internet-Draft MSRP October 2003

|(10) (MSRP) SEND | |
|------------->| | |
| |(11) (MSRP) SEND |
| |------------->| |
| | |(12)
|----------------------->|
|(6) (MSRP) SEND | | |------------->|
| | |(13) (MSRP) 200 OK
| | |<-------------|
| |(14)
|----------------------->|
|(7) (MSRP) 200 OK |
| |<-------------| |
|(15)
|<-----------------------|
|(8) (MSRP) SEND | |
|<-------------| | |
|(16) (SIP) BYE| | |
|------------------------------------------->|
|(17) (MSRP) BIND | |
|------------->| | |
|(18)
|<-----------------------|
|(9) (MSRP) 200 OK | |
|<-------------| | |
|(19)
|----------------------->|
|(10) (SIP) 200 OK | |
|<-------------------------------------------|
| | BYE |
|----------------------->|
|(11) (SIP) 200 OK |
|<-----------------------|
| |
| |

1. Alice->AtlantaRelay (MSRP): Alice opens constructs a connection to her
relay, session URL of msrp://
alicepc.atlanta.com:7777/iau39 and sends the following:

MSRP xx BIND
S-URL: msrp://relay.atlanta.com
TR-ID: 321
Exp:600

2. AtlantaRelay->Alice (MSRP):

MSRP xx 200 OK
TR-ID: 321
S-URL: msrp://relay.atlanta.com:7777/iau39
Exp:600

3. listens for a connection on
TCP port 7777.

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

Campbell, et al. Expires July 27, 2004 [Page 26]

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

Campbell, et al. Expires April 22, 2004 [Page 44]

Internet-Draft MSRP October 2003

4. Bob determines that, due to local policy, he must connect
through his own relay.

Bob->BiloxiRelay (MSRP):
a=direction:both 0
a=session:msrp://alicepc.atlanta.com:7777/iau39

2. Bob opens a TCP connection to his relay,
and sends the following:

MSRP xx VISIT
S-URL: msrp://relay.atlanta.com:7777/iau39
TR-ID: 934

5. BiloxiRelay->AtlantaRelay alicepc.atlanta.com:7777:

Bob->Alice (MSRP): BiloxiRelay resolves the URL,
opens a connection to relay.atlanta.com:7777, and sends the
following:

MSRP xx VISIT
S-URL: msrp://relay.atlanta.com:7777/iau39
TR-ID: 934

6. AtlantaRelay->BiloxiRelay(MSRP):

MSRP xx 200 OK
TR-ID: 934

7. BiloxiRelay->Bob(MSRP):
S-URL:msrp://alicepc.atlanta.com:7777/iau39
Tr-ID: sie09s

3. Alice->Bob (MSRP):

MSRP xx 200 OK
TR-ID: 934

8.
Tr-ID: sie09s

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

v=0
o=bob 2890844612 2890844616 IN IP4 host.anywhere.com
s=
c=IN IP4 stuff ignorefield
t=0 0
m=message 9999 msrp/tcp *
a=accept-types:text/plain
a=direction: active

9.
a=direction:active 0

5. Alice->Bob (SIP): ACK

10. Alice->AtlantaRelay

6. Alice->Bob (MSRP):

MSRP xx SEND
TR-ID: 123
Content-Type: "text/plain"
Hi, I'm Alice!

11. AtlantaRelay ->BiloxiRelay

7. Bob->Alice (MSRP):

MSRP xx SEND 200 OK
TR-ID: 123

8. Bob->Alice (MSRP):

Campbell, et al. Expires April 22, July 27, 2004 [Page 45] 27]

Internet-Draft MSRP October 2003

Content-Type: "text/plain"
Hi, I'm Alice!

12. BiloxiRelay->Bob (MSRP): January 2004

MSRP xx SEND
TR-ID: 123 456
Content-Type: "text/plain"

Hi, I'm Alice!

13. Bob->BiloxiRelay (MSRP):

MSRP xx 200 OK
TR-ID: 123

14. BiloxiRelay->AtlantaRelay (MSRP):

MSRP xx 200 OK
TR-ID: 123

15. AtlantaRelay->Alice I'm Bob!

9. Alice->Bob (MSRP):

MSRP xx 200 OK
TR-ID: 123

16. 456

10. Alice->Bob (SIP): BYE

17. Alice->AtlantaRelay (MSRP):

MSRP xx BIND
S-URL: msrp://relay.atlanta.com:7777/iau39
TR-ID: 42
Exp:0

18. Relay->Alice (MSRP): Relay

Alice invalidates session state.

MSRP xx 200 OK
TR-ID: 42
Exp:0

19. and drops connection.

11. Bob invalidates local state for the session.

Bob->Alice (SIP): 200 OK

9. IANA Considerations

9.1 MSRP Port

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

Campbell, et al. Expires April 22, 2004 [Page 46]

Internet-Draft MSRP October 2003
Section 7.1

9.2 MSRP URL Schemes

This document defines the URL schemes of "msrp" and "msrps".

9.2.1 Syntax

See Section 7.1.

9.2.2 Character Encoding

See Section 7.1.

9.2.3 Intended Usage

See Section 7.1.

9.2.4 Protocols

The Message Session Relay Protocol (MSRP).

Campbell, et al. Expires July 27, 2004 [Page 28]

Internet-Draft MSRP January 2004

9.2.5 Security Considerations

See Section 10.

9.2.6 Relevant Publications

RFCXXXX

[Note to RFC Editor: Please replace RFCXXXX in the above paragraph
with the actual number assigned to this document.

9.3 SDP Parameters

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

9.3.1 Direction

Attribute-name: direction
Long-form Attribute Name Direction
Type: Media level
Subject to Charset Attribute No
Purpose and Appropriate Values See Section 6.2.

Campbell, et al. Expires April 22, 2004 [Page 47]

Internet-Draft MSRP October 2003

9.3.2 Accept Types

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

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

10. Security Considerations

There are a number of security considerations for MSRP, some of which
are mentioned elsewhere in this document. This section discusses
those further, and introduces some new ones.

Open Issue: There have been suggestions that we need more here
covering the multiple authentication possibilities, MITM attack
possibility on digest if not over TLS, some of which
are mentioned elsewhere in this document. This section discusses
those further, and possible bid-down
attacks on the digest algorithm selection. introduces some new ones.

Campbell, et al. Expires July 27, 2004 [Page 29]

Internet-Draft MSRP January 2004

10.1 TLS and the MSRPS Scheme

All MSRP devices must support TLS, with at least the
TLS_RSA_WITH_AES_128_CBC_SHA [8] cipher suite. Other cipher suites
MAY be supported.

MSRP does not define a separate TCP port for TLS connections. This
means that all MSRP server devices, that is, all devices that listen
for TCP connections, MUST be prepared to handle both TLS and plain
text connections on the same port. When a device accepts a TCP
connection, it MUST watch for the TLS handshake messages to determine
if a particular connection uses TLS. If the first data received is
not part of a start TLS request, the device ceases to watch for the
TLS handshake until it reads the entire message. Once the message has
been completely received, the device resumes watching for the start
TLS message.

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

MSRP devices acting in the role of TCP client MAY perform a TLS

Campbell, et al. Expires April 22, 2004 [Page 48]

Internet-Draft MSRP October 2003
handshake at any time, as long as the request occurs between MSRP
messages. The endpoint MUST NOT send a start TLS request in the
middle of an MSRP message.

The working group considered only requiring the endpoint to watch
for a TLS handshake at the beginning of the session. However, the
endpoint should be able to determine if a new message is a start
TLS request or an MSRP request by only reading ahead three bytes.
Therefore, the working group chose to allow a session to switch to
TLS in mid-stream, as long as the switch occurs between MRSP
messages.

The MSRPS URI scheme indicates that all hops in an MSRP session MUST
be protected with TLS. Ensuring Since this implies some additional rules. A
relay MUST return an document does not specify the use
of intermidiary devices, then MSRPS URL support is trivially equivilant
to a BIND request if the request
arrived over TLS and included a MSRPS URI support. However, if intermediaries do exist, either as
described in the S-URI header field.
The relay MAY return an MSRPS URI to any BIND request that arrives
over TLS, but MUST NOT return an MSRP URI to a BIND request that does
not arrive over TLS. If a relay receives a BIND request with an MSRPS
S-URI, over a non-TLS connection, it extension document, or as sort of proprietary
devices, they MUST reject the request with a
426 response. A relay may insist on always using MSRPS by returning a
426 to any bind received over ensure protection at all hops for an unprotected connection, and always
returning MSRPS URLs to BIND requests over protected connections. URL.

A VISIT request for an MSRPS URL MUST be sent over a TLS protected
connection. If a visiting relay hosting device receives a VISIT request for an MSRPS
URL over an unprotected connection, it MUST reject the request with a
426 response.

10.2

10.1.1 Sensitivity of the Session URL

The URL of a MSRP session is used by the visiting endpoint to

Campbell, et al. Expires July 27, 2004 [Page 30]

Internet-Draft MSRP January 2004

identify itself to the hosting device, regardless of whether the
session is directly hosted by the host endpoint, or is hosted by a
relay. device. If an attacker were able to
acquire the session URL, either by guessing it or by eavesdropping,
there is a window of opportunity in which the attacker could hijack
the session by sending a VISIT request to the host device before the
true visiting endpoint. Because of this sensitivity, the session URL
SHOULD be constructed in a way to make it difficult to guess, and
should be sufficiently random so that it is unlikely to be reused.
All mechanisms used to transport the session URL to the visitor and
back to the host SHOULD be protected from eavesdroppers and
man-in-the-middle attacks.

Therefore an MSRP device MUST support the use of TLS for at least the
VISIT request, which by extension indicates the endpoint MUST support
the use of TLS for all MSRP messages. Further, MSRP connections
SHOULD actually be protected with TLS. Further, an MSRP endpoint MUST

Campbell, et al. Expires April 22, 2004 [Page 49]

Internet-Draft MSRP October 2003
be capable of using the security features of the signaling protocol
in order to protect the SDP exchange and SHOULD actually use them on
all such exchanges. End-to-end protection schemes SHOULD be preferred
over hop-by-hop schemes for protection of the SDP exchange.

10.3

10.1.2 End to End Protection of IMs

Instant messages can contain very sensitive information. As a result,
as specified in RFC 2779 [3], instant messaging protocols need to
provide for encryption, integrity and authentication of instant
messages. Therefore MSRP endpoints MUST support the end-to-end
encryption and integrity of bodies sent via SEND requests using
Secure MIME (S/MIME) [7].

Note that while each protected body could use separate keying
material, this is inefficient in that it requires an independent
public key operation for each message. Endpoints wishing to invoke
end-to-end protection of message sessions SHOULD exchange symmetric
keys in SDP k-lines, and use secret key encryption on for each MSRP
message. When symmetric keys are present in the SDP, the offer-answer
exchange MUST be protected from eavesdropping and tampering using the
appropriate facilities of the signaling protocol. For example, if the
signaling protocol is SIP, the SDP exchange MUST be protected using
S/MIME.

10.4

10.1.3 CPIM compatibility

MSRP sessions may be gatewayed to other CPIM [17]compatible
protocols. If this occurs, the gateway MUST maintain session state,
and MUST translate between the MSRP session semantics and CPIM
semantics that do not include a concept of sessions. Furthermore,
when one endpoint of the session is a CPIM gateway, instant messages
SHOULD be wrapped in "message/cpim" [5] bodies. Such a gateway MUST

Campbell, et al. Expires July 27, 2004 [Page 31]

Internet-Draft MSRP January 2004

include "message/cpim" as the first entry in its SDP accept-types
attribute. MSRP endpoints sending instant messages to a peer that has
included 'message/cpim" as the first entry in the accept-types
attribute SHOULD encapsulate all instant message bodies in "message/
cpim" wrappers. All MSRP endpoints MUST support the message/cpim
type, and SHOULD support the S/MIME features of that format.

10.5

10.1.4 PKI Considerations

Several aspects of MSRP will benefit from being used in the context
of a public key infrastructure. For example, the MSRPS scheme allows,
and even encourages, TLS connections between endpoint devices. And
while MSRP allows for a symmetric session key to protect all messages
in a session, it is most likely that session key itself would be
exchanged in a signaling protocol such as SIP. Since that key is

Campbell, et al. Expires April 22, 2004 [Page 50]

Internet-Draft MSRP October 2003
extremely sensitive, its exchange would also need to be protected. In
SIP, the preferred mechanism for this would be S/MIME, which would
also benefit from a PKI.

However, all of these features may be used without PKI. Each endpoint
could instead use self signed certificates. This will, of course, be
less convenient than with a PKI, in that there would be no
certificate authority to act as a trusted introducer. Peers would be
required to exchange certificates prior to securely communicating.

Since, at least for the immediate future, any given MSRP
implementation is likely to communicate with at least some peers that
do not have a PKI available, MSRP implementations SHOULD support the
use of self-signed certificates, and SHOULD support the ability to
configure lists of trusted certificates.

To Do: Add text discussion the use of TLS certificates in more
detail.

11. Changes from Previous Draft Versions

This section to be deleted prior to publication as an RFC

11.1 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 July 27, 2004 [Page 32]

Internet-Draft MSRP January 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.

11.2 draft-ietf-simple-message-sessions-02

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

11.2

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

Campbell, et al. Expires April 22, 2004 [Page 51]

Internet-Draft MSRP October 2003
Changed digest algorithm to SHA1. Added TR-ID and S-URI to the
hash for digest authentication.
CMS usage replaced with S/MIME.
TLS and MSRPS usage clarified.
Session state timeout is now based on SEND activity, rather than
BIND and VISIT refreshes.

Campbell, et al. Expires July 27, 2004 [Page 33]

Internet-Draft MSRP January 2004

Default port added.
Added sequence diagrams to the example message flows.
Added discussion of self-signed certificates in the security
considerations section.

11.3

11.4 draft-ietf-simple-message-sessions-00

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

11.4

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

Campbell, et al. Expires April 22, 2004 [Page 52]

Internet-Draft MSRP October 2003

12. Contributors

The following people contributed substantially to this ongoing
effort:

Campbell, et al. Expires July 27, 2004 [Page 34]

Internet-Draft MSRP January 2004

Rohan Mahy
Allison Mankin
Jon Peterson
Brian Rosen
Dean Willis
Adam Roach
Cullen Jennings
Aki Niemi
Hisham Khartabil
Pekka Pessi
Chris Boulton

Normative References

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

[2] 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. and J. Vincent, "Instant Messaging /
Presence Protocol Requirements", RFC 2779, February 2000.

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

[5] 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 Message Specification", RFC
2633, June 1999.

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

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

Campbell, et al. Expires April 22, 2004 [Page 53]

Internet-Draft MSRP October 2003

Informational References

[10] Campbell, B. and J. Rosenberg, "Session Initiation Protocol
Extension for Instant Messaging", RFC 3428, September 2002.

Campbell, et al. Expires July 27, 2004 [Page 35]

Internet-Draft MSRP January 2004

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

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

[13] 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 (work
in progress), June 2003.

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

[15] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of
Resource Management and Session Initiation Protocol (SIP)", RFC
3312, October 2002.

[16] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323 , November 2002.

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

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

[19] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.

Campbell, et al. Expires April 22, 2004 [Page 54]

Internet-Draft MSRP October 2003

Authors' Addresses

Ben Campbell
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75024

EMail: bcampbell@dynamicsoft.com

Campbell, et al. Expires July 27, 2004 [Page 36]

Internet-Draft MSRP January 2004

Jonathan Rosenberg
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ 07054

EMail: jdrosen@dynamicsoft.com

Robert Sparks
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75024

EMail: rsparks@dynamicsoft.com

Paul Kyzivat
Cisco Systems
Mail Stop LWL3/12/2
900 Chelmsford St.
Lowell, MA 01851

EMail: pkyzivat@cisco.com

Campbell, et al. Expires April 22, July 27, 2004 [Page 55] 37]

Internet-Draft MSRP October 2003 January 2004

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property 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 does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 or users of this specification can
be obtained from the IETF Secretariat.

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

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

Campbell, et al. Expires April 22, July 27, 2004 [Page 56] 38]

Internet-Draft MSRP October 2003 January 2004

HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgment

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

Campbell, et al. Expires April 22, July 27, 2004 [Page 57] 39]

----