WDIFF

draft-ietf-simple-message-sessions-00.txt --> draft-ietf-simple-message-sessions-01.txt

SIMPLE Working Group B. Campbell
Internet-Draft J. Rosenberg
Expires: November 20, December 29, 2003 R. Sparks
dynamicsoft
P. Kyzivat
Cisco Systems
May 22,
June 30, 2003

Instant Message Sessions in SIMPLE
draft-ietf-simple-message-sessions-00
draft-ietf-simple-message-sessions-01

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 November 20, December 29, 2003.

Abstract

The SIP MESSAGE method is used to send instant messages, where each
message is independent of any other message.

This is often called
pager-mode messaging, due to the fact that this model is similar to
that of most two-way pager devices. Another model is called
session-mode. In session-mode, document describes the instant messages are part of Message Session Relay Protocol (MSRP), a
media session that provides ordering,
mechanism for transmitting a security context, and other
functions. This media session is established series of Instant Messages within a
session. MSRP sessions are managed using the SDP offer/answer model
carried by a SIP INVITE, just signaling protocol such as an audio SIP.

MSRP supports end-to-end Instant Message Sessions, as well as
sessions traversing one or video session would be established. two relays.

Campbell, et al. Expires November 20, December 29, 2003 [Page 1]

Internet-Draft SIMPLE IM Sessions May June 2003

This document describes the Message Session Relay Protocol (MSRP), a
mechanism for transmitting session-mode messages with minimalist
relay support. Additionally, this document describes using the SDP
offer/answer model to initiate such sessions.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation for Session-mode Messaging . . . . . . . . . . . 4
3. Scope of this Document . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 5
5. SDP Offer-Answer Exchanges for MSRP Sessions. Architectural Considerations . . . . . . . . . . . . . . . . 8
5.1 Use of the SDP M-line Relays . . . . . . . . . . . . . . . . . . . . . . . 8
5.2 The Direction Attribute Transferring Large Content . . . . . . . . . . . . . . . . . 9
5.3 URL Negotiations Connection Sharing . . . . . . . . . . . . . . . . . . . . . 10
5.4 Example 9
6. SDP Exchange Offer-Answer Exchanges for MSRP Sessions . . . . . . . . 10
6.1 Use of the SDP M-line . . . . . . . . . . . 11
6. The Message Session Relay Protocol . . . . . . . . 10
6.2 The Direction Attribute . . . . 11
6.1 MSRP URLs . . . . . . . . . . . . . . 11
6.3 MIME Wrappers . . . . . . . . . . 11
6.2 MSRP URL Comparison . . . . . . . . . . . . . 13
6.4 URL Negotiations . . . . . . 12
6.3 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 13
6.3.1 The msrps URL Scheme .
6.5 Example SDP Exchange . . . . . . . . . . . . . . . . . . 14
6.4 MSRP messages . . 14
7. The Message Session Relay Protocol . . . . . . . . . . . . . 15
7.1 MSRP URLs . . . . . . . 14
6.5 MSRP Transactions . . . . . . . . . . . . . . . . . . . . 15
6.6
7.1.1 MSRP Sessions . . URL Comparison . . . . . . . . . . . . . . . . . . . . 16
6.6.1 Initiating an
7.1.2 Resolving MSRP session Host Device . . . . . . . . . . . . . . . . . 16
6.6.2 Handling VISIT requests
7.1.3 The msrps URL Scheme . . . . . . . . . . . . . . . . . 19
6.6.3 Sending Instant Messages on a Session . . . 17
7.2 MSRP messages . . . . . . . 20
6.6.4 Managing Session State and Connections . . . . . . . . . . 21
6.7 MSRP Relays . . . . . . 17
7.3 MSRP Transactions . . . . . . . . . . . . . . . . . 22
6.7.1 Establishing Session State at a Relay . . . . 18
7.4 MSRP Sessions . . . . . . 22
6.7.2 Removing Session State from a relay . . . . . . . . . . . 24
6.7.3 Sending IMs across an MSRP relay . . . . . . 19
7.4.1 Initiating an MSRP session . . . . . . . 24
6.7.4 Relay Pairs . . . . . . . . . . 19
7.4.2 Handling VISIT requests . . . . . . . . . . . . . 24
6.8 Session State Expiration . . . . . 23
7.4.3 Sending Instant Messages on a Session . . . . . . . . . . . 23
7.4.4 Ending a Session . 26
6.9 Digest Authentication . . . . . . . . . . . . . . . . . . 26
6.9.1 The MD5 Algorithm . . . 24
7.4.5 Session Inactivity Timer . . . . . . . . . . . . . . . . . 27
6.10 Method Descriptions . 24
7.4.6 Managing Session State and Connections . . . . . . . . . . . 25
7.5 MSRP Relays . . . . . . . 28
6.10.1 BIND . . . . . . . . . . . . . . . . . 26
7.5.1 Establishing Session State at a Relay . . . . . . . . . . 28
6.10.2 SEND . 26
7.5.2 Removing Session State from a relay . . . . . . . . . . . . 28
7.5.3 Sending IMs across an MSRP relay . . . . . . . . . . . . . . 28
6.10.3 VISIT
7.5.4 Relay Pairs . . . . . . . . . . . . . . . . . . . . . . . . 28
7.6 Digest Authentication . . 29
6.11 Response Code Descriptions . . . . . . . . . . . . . . . . 29
6.11.1 200 . 30
7.6.1 The SHA1 Algorithm . . . . . . . . . . . . . . . . . . . . . 31
7.7 Method Descriptions . . . . . 29
6.11.2 400 . . . . . . . . . . . . . . . 31
7.7.1 BIND . . . . . . . . . . . . 29
6.11.3 401 . . . . . . . . . . . . . . . . 31
7.7.2 SEND . . . . . . . . . . . 29
6.11.4 403 . . . . . . . . . . . . . . . . . 32
7.7.3 VISIT . . . . . . . . . . 30
6.11.5 415 . . . . . . . . . . . . . . . . . 32
7.8 Response Code Descriptions . . . . . . . . . . 30
6.11.6 481 . . . . . . . 32
7.8.1 200 . . . . . . . . . . . . . . . . . . . . 30
6.11.7 500 . . . . . . . . 32
7.8.2 400 . . . . . . . . . . . . . . . . . . . 30

Campbell, et al. Expires November 20, 2003 [Page 2]

Internet-Draft SIMPLE IM Sessions May 2003

6.11.8 506 . . . . . . . . . 33
7.8.3 401 . . . . . . . . . . . . . . . . . . 30
6.12 Header Field Descriptions . . . . . . . . . . 33
7.8.4 403 . . . . . . 30
6.12.1 TR-ID . . . . . . . . . . . . . . . . . . . . . . 33
7.8.5 415 . . . . 30
6.12.2 Exp . . . . . . . . . . . . . . . . . . . . . . . . 33
7.8.6 426 . . . 30
6.12.3 CAuth . . . . . . . . . . . . . . . . . . . . . . . . . 33

Campbell, et al. Expires December 29, 2003 [Page 2]

Internet-Draft SIMPLE IM Sessions June 2003

7.8.7 481 . 31
6.12.4 SChal . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.12.5 Content-Type . 33
7.8.8 500 . . . . . . . . . . . . . . . . . . . . . . 32
6.12.6 S-URL . . . . . . 33
7.8.9 506 . . . . . . . . . . . . . . . . . . . . 32
7. Examples . . . . . . . . 33
7.9 Header Field Descriptions . . . . . . . . . . . . . . . . . 32
7.1 No Relay 33
7.9.1 TR-ID . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.2 Single Relay . . 34
7.9.2 Exp . . . . . . . . . . . . . . . . . . . . . 34
7.3 Two Relays . . . . . . . 34
7.9.3 CAuth . . . . . . . . . . . . . . . . . 37
8. IANA Considerations . . . . . . . . . . 34
7.9.4 SChal . . . . . . . . . 40 . . . . . . . . . . . . . . . . . . 35
7.9.5 Content-Type . . . . . . . . . . . . . . . . . . . . . . . . 36
7.9.6 S-URL . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.1 No Relay . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.2 Single Relay . . . . . . . . . . . . . . . . . . . . . . . . 39
8.3 Two Relays . . . . . . . . . . . . . . . . . . . . . . . . . 42
9. Security IANA Considerations . . . . . . . . . . . . . . . . . 40 . . . 46
9.1 The MSRPS Scheme MSRP Port . . . . . . . . . . . . . . . . . . . . . . 40 . . . 46
9.2 Sensitivity of the Session MSRP URL Schemes . . . . . . . . . . . . . . 41
9.3 End to End Protection of IMs . . . . . . . . 46
9.2.1 Syntax . . . . . . . 41
9.4 CPIM compatibility . . . . . . . . . . . . . . . . . . . . 42
10. Changes introduced in
draft-ietf-simple-message-sessions-00 46
9.2.2 Character Encoding . . . . . . . . . . 42
11. Changes introduced in
draft-campbell-simple-im-sessions-01 . . . . . . . . . . . 43
12. Contributors 46
9.2.3 Intended Usage . . . . . . . . . . . . . . . . . . . . . . . 43
Normative References 47
9.2.4 Protocols . . . . . . . . . . . . . . . . . . . 43
Informational References . . . . . . 47
9.2.5 Security Considerations . . . . . . . . . . . 44
Authors' Addresses . . . . . . . 47
9.2.6 Relevant Publications . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . 46

Campbell, et al. Expires November 20, 2003 [Page 3]

Internet-Draft SIMPLE IM Sessions May 2003 47
9.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . 47
9.3.1 Direction . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.3.2 Wrapped Types . . . . . . . . . . . . . . . . . . . . . . . 47
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 . . . . . . . . . . . . . . . . 49
10.4 CPIM compatibility . . . . . . . . . . . . . . . . . . . . . 50
10.5 PKI Considerations . . . . . . . . . . . . . . . . . . . . . 50
11. Changes from Previous Draft Versions . . . . . . . . . . . . 50
11.1 draft-ietf-simple-message-sessions-01 . . . . . . . . . . . 51
11.2 draft-ietf-simple-message-sessions-00 . . . . . . . . . . . 51
11.3 draft-campbell-simple-im-sessions-01 . . . . . . . . . . . . 52
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52
Normative References . . . . . . . . . . . . . . . . . . . . 53
Informational References . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 54
Intellectual Property and Copyright Statements . . . . . . . 56

Campbell, et al. Expires December 29, 2003 [Page 3]

Internet-Draft SIMPLE IM Sessions June 2003

1. Introduction

The MESSAGE [9] [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 pager-mode page-mode messaging, since it follows a model similar to that
used by many two-way pager devices. Pager-mode page-mode messaging makes sense
for instant message exchanges where a small number of messages occur.

There are also applications in which it is useful for instant
messages to be associated together in some way. 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 5) 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 pager-mode 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, unless proxies also act as message
relays.

Each pager mode page-mode message involves a complete SIP transaction, that is,
a request and a response. Any pager-mode page-mode message exchange that
involves more than 2 or 3 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
significant limitations in message size, a prohibition against
overlapping requests, etc. Much of this has been required because of

Campbell, et al. Expires November 20, December 29, 2003 [Page 4]

Internet-Draft SIMPLE IM Sessions May June 2003

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,
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 [11], [12], third party call control [12], [13], call transfer [13], [14],
QoS integration [14], [15], and privacy [15] [16] can all be applied to message
sessions.

Messaging sessions can also reduce the overhead in each individual
message. In pager-mode, 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.

4. Protocol Overview

Campbell, et al. Expires November 20, December 29, 2003 [Page 5]

Internet-Draft SIMPLE IM Sessions May June 2003

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

B->A (MSRP): VISIT (msrp://A/123)

Campbell, et al. Expires November 20, December 29, 2003 [Page 6]

Internet-Draft SIMPLE IM Sessions May June 2003

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 state associated with the session will expire over time, based on state has an expiration time specified in the 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 lifetime of hosting device invalidates the session is to exceed state
and terminates all associated connections. Endpoints that expiration time, the visitor must
update the expiration with are
otherwise idle may keep a new VISIT request prior to expiration. 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

Campbell, et al. Expires November 20, December 29, 2003 [Page 7]

Internet-Draft SIMPLE IM Sessions May June 2003

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 much the same as in
VISIT. request contains an expiration time. If the life of a relay-hosted session is successful VISIT
request does not occur prior to exceed the
expiration value in the BIND request, expiration, the host endpoint relay will refresh
destroy the expiration time with a new BIND request prior to expiration. 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. SDP Offer-Answer Exchanges for MSRP Sessions.

MSRP sessions will typically be initiated using the Session
Description Protocol (SDP) [1] offer-answer mechanism, carried Architectural Considerations

There are a number of considerations that, if handled in SIP
[2] or any other protocol supporting it. MSRP borrows the idea a reasonable
fashion, will allow more effective use of the
direction attributes from COMEDIA [17], but does not depend on that
specification. protocols described in
this document.

5.1 Use of the SDP M-line Relays

The SDP m-line takes 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 following form:

m=<media> <port> <protocol> <format list> other.
For non-RTP media sessions, The media field specifies the top level
MIME media type example, both endpoints may be behind separate firewalls that
only allow outbound connections. Relays may also be needed for the session. policy
enforcement. For MSRP sessions, example, parts of the media field
MUST have financial industry require the value
logging of "message". The proto field MUST designate all communication.

However, the
message session mechanism and transport protocol, separated by use of such relays has a "/"
character. For MSRP, left part significant impact on the
scalability of this value MUST 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 "msrp". For MSRP
over TCP, used indescrimantly. In the right part absence of this field MUST take the value "tcp". For
strong reasons to use relays, MSRP over other transport protocols, the field value MUST endpoints SHOULD be defined
by the specification for that protocol binding. The format list MUST
indicate the MIME content-types that the endpoint is willing configured to
accept in
set up point-to-point sessions.

MSRP supports the payload use of SEND requests. If any two relays, where each endpoint has a relay
acting on its behalf. However, most of the allowed types
are compound in nature, that is, they allow one or more arbitrary
MIME body parts to be embedded within them, then the format list MUST
include the content-types allowed for the embedded parts. If the
final entry in the format list is network topology issues
mentioned above can work with a "*", this indicates single relay, if that the
endpoint relay is may be willing to receive other types
reachable by both endpoints. Dual relays are only needed for cases of
very strict firewall policy, such as well, but the
types listed explicitly when only specific hosts are preferred. The format list in the SDP
answer MUST be
allowed to connect to the same as, outside world; or situations requiring
strict policy enforcement at both endpoint domains. If a subset of, the list provided in the
offer. given usage

Campbell, et al. Expires November 20, December 29, 2003 [Page 8]

Internet-Draft SIMPLE IM Sessions May June 2003

scenario can be solved with a 415. Note that all explicit
entries single relay, then a second relay
SHOULD NOT be used.

In spite of these recommendations, relays serve a real purpose in
that the format list should be considered preferred over any
non-listed types. This feature is needed as, otherwise, increase the format
list for IM devices may be prohibitively large.

The port field likelihood of two arbitrary endpoints being
able to talk to one another. Therefore if a provider deploys MSRP
endpoints in the M-line is a network configuration that prevents them from
receiving TCP connections from arbitrary peers, and does not used wish to determine
explicitly prevent MSRP communication with the port to
which to connect. Rather, outside world, then
the actual port is determined by provider SHOULD provide its endpoints with the
contents use of the session URL. (Section 6.1).

The following example illustrates an m-line for MSRP
relay that is reachable from arbitrary peers.

5.2 Transferring Large Content

MSRP endpoints may attempt to send very long messages on a CPIM session.
For example, most commercial instant messaging systems have a file
transfer feature. Since MSRP does not impose message
session, where the endpoint size limits,
there is willing nothing to accept payloads prevent endpoints from transferring files over
it.

An analysis of plain
text whether it makes sense to do this, rather than sending
such content over FTP, HTTP, or HTML, which may appear at some other such protocol, is beyond
the top level scope of the payload, or
may this document. However, implementers should be embedded inside a message/cpim body part.

m=message 49232 msrp/tcp message/cpim text/plain text/html

5.2 The Direction Attribute

Since MSRP uses connection oriented transport protocols, one goal aware of
the SDP negotiation is to determine which participant initiates the
transport connection. impact of sending very large messages over MSRP. The direction attribute advertises whether primary
impact is, since MSRP is sent over TCP, is that any additional
messages that the
offerer or answerer sender wishes to initiate send will be blocked until the
large transfer is complete. This includes responses to messages sent
by the connection, wishes peer. Therefore, any SEND transactions initiated by the peer endpoint
are likely to initiate the connection, or doesn't care.

The endpoint that accepts time out, even though they are received without
problems.

Further, there is no way to abort the connection, or has sending of a relay accept very large message
before it is complete. For the
connection on its behalf, sake of efficiency, the framing
mechanism in MSRP is said very simple. There is no clean way to "host" recover
framing if the session, and complete message is known
as not sent.

These issues can be mitigated greatly if the hosting endpoint. The endpoint that initiates simply
establishes a separate session for the connection
is said transfer. This allows the
transfer to "visit" be sent without interfering with any instant messages
being sent on other sessions. Further, the session, and is known as endpoint can abort the visiting
endpoint.

The direction attribute is included in an SDP a-line, with a value
taking
transfer by simply tearing down the following syntax:

direction = direction-label ":" role
direction-label = "direction"
role = active / passive / both
active = "active"
passive = "passive"
both = "both"

The values transfer session. Therefore, if a
peer wishes to send very large content, it SHOULD establish a
dedicated session for that purpose.

5.3 Connection Sharing

The SIMPLE working group spent quite a bit of effort in the role field are as follows:
consideration of shared TCP connections. Connection sharing would

Campbell, et al. Expires November 20, December 29, 2003 [Page 9]

Internet-Draft SIMPLE IM Sessions May 2003

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.

The SDP offer for an MSRP session MUST contain a direction attribute,
which MAY take any June 2003

offer value whenever a large number of message sessions cross the defined values. If the offerer
same two adjacent devices. This situation is capable
of hosting likely to occur in the session, or can arrange for a
two relay to host model. It may also occur in the
session on its behalf, then it SHOULD select "both". 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 endpoint
SHOULD NOT select "active" unless biggest problem is it cannot host 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 under
any circumstances. The endpoint SHOULD NOT select "passive" unless it
has no option but to host would block transfer of messages
on the other session. The SDP answer also MUST contain a direction attribute, but its value
choices are limited based 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 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", protocol, so the answerer SHOULD select "active", but MAY select
"passive" if local policy requires it
work group chose not to act go that route.

It may be possible to relax this requirement using other transport
protocols, such as host.

5.3 URL Negotiations

An MSRP session 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 identified by an beyond the scope
of this document.

6. SDP Offer-Answer Exchanges for MSRP URL, which is determined by Sessions

MSRP sessions will typically be initiated using the hosting endpoint, and negotiated Session
Description Protocol (SDP) [1] offer-answer mechanism, carried in the SDP exchange. Any SDP
offer SIP
[2] or answer that creates a possibility that any other protocol supporting it. MSRP borrows the sender will host idea of the session, that is, contains a
direction value attributes from COMEDIA [18], but does not depend on that
specification.

6.1 Use of "passive" or
"both", MUST contain an MSRP URL in a session attribute. This
attribute has the following syntax:

a=session:<MSRP_URL>

where <MSRP_URL> is an MSRP or MSRPS URL as defined in Section 6.1. SDP M-line

The visitor will use the session URL established by SDP m-line takes the host both to
resolve following form:

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

For non-RTP media sessions, The media field specifies the host address and port, and to identify top level
MIME media type for the session when
connecting. session. For MSRP sessions, the address media field in the C-line and
MUST have the value of "message". The port field in the M-line are is normally not relevant,
used, and MUST SHOULD be ignored.

The following example shows an set to 9999. An exception is when the port field
value is set to zero, according to normal SDP offer with a usage.

The proto field MUST designate the message session URL mechanism and
transport protocol, separated by a "/" character. For MSRP, left part
of
"msrp://example.com:7394/2s93i"

c=IN IP4 useless.host.name
m=message 7394 msrp/tcp text/plain
a=direction:both
a=session:msrp://example.com:7394/2s93i 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

Campbell, et al. Expires November 20, December 29, 2003 [Page 10]

Internet-Draft SIMPLE IM Sessions May June 2003

The session URL

protocols, the field value MUST be a temporary URL assigned just defined by the specification for
that protocol binding.

The format list MUST indicate the MIME content-types that the
endpoint is willing to accept in the payload of SEND requests. If the
final entry in the format list is a "*", this
particular session. It indicates that the
endpoint is may be willing to receive other types as well, but the
types listed explicitly are preferred. The format list in the SDP
answer MUST NOT duplicate any URL be the same as, or a subset of, the list provided in use for the
offer.

A "*" in the format list indicates that the sender may attempt to
send messages with other 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 in the format list should be considered preferred over any
non-listed types. This feature is needed as, otherwise, the format
list for IM devices may be prohibitively large.

The m-line format list may include MIME wrapper types, that is,
mime formats that contain other session hosted by types internally. The types listed
in the endpoint format field can be used both as the root payload, or relay. Further, since may
be contained in container types. (Note that the
peer endpoint will use container type
must also be listed in the session URL to identify itself format list.) A list of types that are
only allowed when
connecting, it SHOULD be hard to guess, and protected from
eavesdroppers. This will wrapped in containers can be discussed communicated in more detail the
accept-wrapped-types (Section 6.3) attribute.

The port field in the Security
Considerations section.

5.4 Example SDP Exchange

Endpoint A wishes to invite Endpoint B M-line is not normally used to a MSRP session. A offers
the following session description containing determine the following lines:

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

Endpoint B chooses
port to participate in which to connect. Rather, the role actual port is determined by
the contents of visitor, opens a TCP
connection to alice.example.com:7394, and successfully performs a
VISIT transaction passing the session URL (Section 7.1). However, a port value
of msrp://alice.example.com:7394/
2s93i9;. B indicates that it zero has accomplished this by answering with:

c=IN IP4 dontlookhere
m=message 7394 msrp/tcp message/cpim text/plain
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.

6. The Message Session Relay Protocol normal SDP meaning.

The Message Session Relay Protocol (MSRP) is following example illustrates an m-line for a text based, message
oriented protocol for the transfer of instant messages in session,
where the context endpoint is willing to accept root payloads of a session. MSRP uses the UTF8 character set.

MSRP messages MUST message/
cpim, plain text or HTML. The second two types could either be sent over reliable, congestion-controlled,
connection-oriented transport protocols, such
presented as TCP.

6.1 MSRP URLs

MSRP sessions are identified by MSRP URLs. An the root body, or could be contained within message/cpim
bodies.

m=message 9999 msrp/tcp message/cpim text/plain text/html

6.2 The Direction Attribute

Since MSRP URL follows a
subset uses connection oriented transport protocols, one goal of
the URL syntax in Appendix A of RFC2396 [4], with a scheme
of "msrp":

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

resource = 1*unreserved 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.

Campbell, et al. Expires November 20, December 29, 2003 [Page 11]

Internet-Draft SIMPLE IM Sessions May June 2003

The constructions for "userinfo", "hostport", endpoint that accepts the connection, or has a relay accept the
connection on its behalf, is said to "host" the session, and "unreserved" are
detailed in RFC2396 [4].

An MSRP URL server part identifies is known
as the hosting device of 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 MSRP 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" [sp timeout]
both = "both"
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. There

both The endpoint is no default port for MSRP URLs. willing to act as either host or visitor. If the server part
contains a numeric IP address,
"both" is selected, it MUST also may contain an optional timeout value. This
timeout specifies how much time the answerer should wait before
giving up on a port. The
resource part identifies a particular session at that connection and attempting to take over as host
device.
The absence of If the resource part indicates a reference timeout value is not specified, it defaults to 30
seconds.

The SDP offer for an MSRP
host device, but does not specifically refer to a particular session
resource.

Open Issue: Do we need a default port? Cullen points out it would
at least be useful for firewall configuration.

The server part will typically not MUST contain a userinfo component, but
MAY do so to indicate a user account for direction attribute,
which MAY take any of the session is valid.
Note that this is not defined values. If the same thing as identifying offerer is capable
of hosting the session
itself. If session, or can arrange for a userinfo component exists, MUST be constructed only from
"unreserved" characters, relay to avoid a need for escape processing.
Escaping MUST host the
session on its behalf, then it SHOULD select "both". The endpoint
SHOULD NOT be used in an MSRP URL. Furthermore, a userinfo
part MUST select "active" unless it cannot host the session under
any circumstances. The endpoint SHOULD NOT contain password information. select "passive" unless it
has no option but to host the session.

The following is an example of SDP answer also MUST contain a typical MSRP URL:

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

6.2 MSRP URL Comparison

MSRP URL comparisons direction attribute, but its value
choices are limited based on the value in the offer. If the offer
contained "active", then the answerer MUST be performed according to either select "passive" or
reject the following
rules:

The host part is compared as case insensitive. offer. Likewise, if the offer contained "passive", then
the answerer MUST select"active" or reject the offer. If the port exists explicitly in either URL, then offer
contained "both", the answerer SHOULD select "active", but MAY select
"passive" if it must match
exactly. Since there is no default port for MSRP, a URL with an
explicit port is never equivalent to another with no port
specified.

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

Userinfo parts are not considered for URL comparison.

Path normalization is not relevant for MSRP URLs. Escape
normalization is not required, since reach the relevant parts are limited host device, or if local
policy requires it to unreserved characters. act as host.

Campbell, et al. Expires November 20, December 29, 2003 [Page 12]

Internet-Draft SIMPLE IM Sessions May June 2003

6.3 Resolving MSRP Host Device

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

If MIME Wrappers

The MIME content-types in the server part contains a numeric IP address M-line format list will often include
compound types; that is, types that contain other types. For example,
"message/cpim" or "multipart/mixed." Occasionally and port, they MUST endpoint will
need to specify a MIME body type that can only be used as listed..

If the server part contains a host name and if wrapped
inside a port, listed container type.

Endpoints MAY specify MIME types that are only allowed to be wrapped
inside compound types using the connecting
device MUST determine a host address by doing "accept-wrapped-types" attribute in
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 SDP a-line. This attribute has the following steps:

1. Construct an SRV [6] query string by prefixing syntax:

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

The format-list element has the host name
with identical syntax as the service field "_msrp" and format list
in the protocol field ("_tcp" m-line. The semantics for
TCP). For example, "_msrp._tcp.host.example.com".

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

3. Select a resulting record according attribute are identical to
those of the rules in RFC2782 [6].
Determine m-line format list, with the port from exception that the chosen record.

4. If necessary, determine a host device address by performing an A
or AAAA query
specified types may only be used when wrapped inside containers. The
container types would be specified on the host name field in m-line normally. Since any
type listed on the selected SRV result
record. If multiple A m-line may be used both as a root body, or AAAA records are returned, wrapped
in other bodies, format entries from the first
entry m-line SHOULD NOT be chosen for the initial connection attempt. This
allows any ordering created
repeated in the DNS to be preserved.

5. this attribute.

This approach does not allow for specifying distinct lists of
acceptable wrapped types for different types of containers. If the connection attempt fails, the device SHOULD attempt to
connect to the addresses returned in any additional A or AAAA
records, an
endpoint understands a MIME type in the order the records were presented. If all context 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.

Open Issue: We need to carefully consider the rules about A RR
selection. I am sure there are others who understand this much
better than I do. Ted pointed us one wrapper, it is
assumed to RFC1794, which if I understand
correctly indicates that some systems may attempt to load balance
by controlling the order it in which A RRs are presented. Attempts the context of any other acceptable
wrappers, subject to
randomize selection any constraints defined by the client could distort any such control.

Note wrapper types
themselves.

The approach of specifying types that in most cases, the transport protocol will be determined are only allowed inside of
containers separately from the resolution process. primary payload types allows an
endpoint to force the use of certain wrappers. For example, if a CPIM
gateway device may require all messages to be wrapped inside
message/cpim bodies, but may allow several content types inside
the MSRP URL
was communicated wrapper. If the gateway were to specify the wrapped types in
the m-line format list, its peer could choose to use those types
without the wrapper.

6.4 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, answer that creates a possibility that the SDP M-line sender will
contain host
the transport protocol. When session, that is, contains a direction value of "passive" or
"both", MUST contain an MSRP URL is communicated
outside of SDP, the protocol SHOULD also be communicated. For in a session attribute. This

Campbell, et al. Expires November 20, December 29, 2003 [Page 13]

Internet-Draft SIMPLE IM Sessions May June 2003

example, a client may be configured to use a particular relay that

attribute has the following syntax:

a=session:<MSRP_URL>

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

The client MUST also be told what
protocol to use. If a device needs visitor will use the session URL established by the host both to
resolve an the host address and port, and to identify the session when
connecting. For MSRP URL and does sessions, the address field in the C-line is not know
relevant, and MUST be ignored. The port field in the protocol, it SHOULD assume TCP.

Open Issue: Do we need to do an NAPTR query to determine M-line MUST be
ignored if non-zero. Zero values have the
protocol?

6.3.1 normal meeting for SDP.

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

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

The "msrps" session URL Scheme indicates that each hop MUST be secured with
TLS. Otherwise, it is used identically as an MSRP URL, except that a
MSRPS temporary URL assigned just for this
particular session. It MUST NOT be considered equivalent to an MSRP URL. The MSRPS
scheme is further discussed duplicate any URL in use for any
other session hosted by the Security Considerations section.

6.4 MSRP messages

MSRP messages are either requests endpoint or responses. Requests relay. Further, since the
peer endpoint will use the session URL to identify itself when
connecting, it SHOULD be hard to guess, and
responses are distinguished protected from one another by the first line. The
first line of
eavesdroppers. This will be discussed in more detail in Section 10.

6.5 Example SDP Exchange

Endpoint A wishes to invite Endpoint B to a Request takes MSRP session. A offers
the form of following session description containing the request-start entry
below. Likewise, following lines:

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

Endpoint B chooses to participate in the first line role of visitor, opens a response takes 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 message/cpim text/plain
a=direction:active

A may now send IMs to B by executing SEND transactions on the form of
response-start. The syntax for an MSRP message is as follows: same

Campbell, et al. Expires November 20, December 29, 2003 [Page 14]

Internet-Draft SIMPLE IM Sessions May June 2003

connection on which B sent the length of VISIT request.

7. The Message Session Relay Protocol

The Message Session Relay Protocol (MSRP) is a text based, message
oriented protocol for the message, exclusive transfer of instant messages in the start line.
Method = SEND / BIND / VISIT
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
/ 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 context
of seconds

All requests and responses MUST contain at least a TR-ID header
field. Messages MAY contain other fields, depending on session. MSRP uses the method or
response code.

6.5 UTF8 character set.

MSRP Transactions

An messages MUST be sent over reliable, congestion-controlled,
connection-oriented transport protocols, such as TCP.

7.1 MSRP transaction consists URLs

MSRP sessions are identified by MSRP URLs. An MSRP URL follows a
subset of exactly one request and one response. the URL syntax in Appendix A response matches of RFC2396 [4], with a transaction if it share the same TR-ID value, scheme
of "msrp":

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

resource = 1*unreserved

The constructions for "userinfo", "hostport", and arrives on the same connection on which the transaction was sent.

BIND is always hop by hop. VISIT transactions "unreserved" are usually hop-by-hop,
but may be relayed
detailed in situations where RFC2396 [4].

An MSRP URL server part identifies the visiting endpoint uses hosting device of an MSRP
session. If the server part contains a
relay. However, SEND transactions are end to end, meaning numeric IP address, it MUST
also contain a port. The resource part identifies a particular
session at that under
normal circumstances the response is sent by host device. The absence of the peer endpoint, even
if there are intervening relays.

Endpoints MUST select TR-ID header field values 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 requests so that
they are Section 9.1.
However, this value should not repeated by be considered a default, as the same endpoint in scope of URL
process described herein will always explicitly resolve a port
number. However, the given
session. TR-ID values URLs SHOULD be globally unique. 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 TR-ID space of
each endpoint server part will typically not contain a userinfo component, but
MAY do so to indicate a user account for which the session is independent of valid.
Note that of its peer. Endpoints this is not the same thing as identifying the session
itself. If a userinfo component exists, MUST NOT
infer any semantics be constructed only from the TR-ID header field beyond what
"unreserved" characters, to avoid a need for escape processing.
Escaping MUST NOT be used in an MSRP URL. Furthermore, a userinfo
part MUST NOT contain password information.

The following is stated an example of a typical MSRP URL:

Campbell, et al. Expires November 20, December 29, 2003 [Page 15]

Internet-Draft SIMPLE IM Sessions May June 2003

above. In particular, TR-ID values are not required to follow any
sequence.

MSRP Transactions complete when a response 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
size of the timeout interval is a matter of local policy.

6.6 MSRP Sessions

AN MSRP session is a context in which a series of instant messages
are exchanged, using SEND requests. A session has two endpoints (a
host and a visitor) and may have one or two relays. A session is
identified by an

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

7.1.1 MSRP URL.

6.6.1 Initiating an URL Comparison

MSRP session

When an endpoint wishes to engage a peer endpoint in a 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 will refer to the
endpoint choosing to initiate communication as the offerer, and the
peer being invited as URL comparisons MUST be performed according to the answerer. following
rules:

The offerer SHOULD volunteer to act host part is compared as case insensitive.

If the hosting endpoint if
allowed by policy and network topology. port exists explicitly in either URL, then it must match
exactly. An endpoint URL with an explicit port is said never equivalent to host a
session if one of two conditions are true.
another with no port specified.

The host either directly
listens for a connection from the peer endpoint, and maintains
session state itself, or it uses resource part is compared as case insensitive. A URL without a BIND request
resource part is never equivalent to initialize session
state at a relay one that will listen for includes a connection from the peer. The
peer that resource
part.

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 designated as identified by the visitor. The offerer
MAY request server part of an MSRP URL.

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

If the server part contains a host if it is prevented from
accepting connections by network topology or policy, name and is not able
to bind to a relay to act on its behalf.

If port, the offerer wishes to connecting
device MUST determine a host address by doing an A or AAAA DNS query,
and use the session directly, that is without
using port as listed.

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

1. Construct a session MSRP URL . This URL MUST be resolvable to an SRV [6] query string by prefixing the
offerer. The URL SHOULD be temporary, SHOULD be hard to guess,
and MUST not duplicate host name
with the URL of any other session currently
hosted by service field "_msrp" and the offerer.

2. Listen protocol field ("_tcp" for
TCP). For example, "_msrp._tcp.host.example.com".

2. Perform a connection from the peer. DNS SRV query using this query string.

3. Construct an SDP offer as described in Section 5, including Select a resulting record according to the
list of allowed IM payload formats rules in RFC2782 [6].
Determine the format list. The
offerer maps the session URL to port from the session attribute, as chosen record.

4. If necessary, determine a host device address by performing an A

Campbell, et al. Expires November 20, December 29, 2003 [Page 16]

Internet-Draft SIMPLE IM Sessions May June 2003

described

or AAAA query on the host name field in Section 5.3.

4. Insert a direction attribute. This value the selected SRV result
record. If multiple A or AAAA records are returned, the first
entry SHOULD be "both",
indicating that chosen for the offerer will allow initial connection attempt. This
allows any ordering created in the answerer DNS to override be preserved.

5. If the offerer's decision connection attempt fails, the device SHOULD attempt to host. The value MAY be "passive" if
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
offerer is prevented transport protocol will be determined
separately from allowing the answerer override this
choice.

5. Send resolution process. For example, if the MSRP URL
was communicated in an SDP offer using or answer, the normal processing for SDP M-line will
contain the signaling transport protocol.

If When an MSRP URL is communicated
outside of SDP, the offerer chooses protocol SHOULD also be communicated. For
example, a client may be configured to force the answerer use a particular relay that is
referenced with an MSRP URL. The client MUST also be told what
protocol to host use. If a device needs to resolve an MSRP URL and does
not know the session, protocol, it SHOULD assume TCP.

7.1.3 The msrps URL Scheme

The "msrps" URL Scheme indicates that each hop MUST perform the following steps instead:

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

2. Insert a direction attribute be secured with
TLS. Otherwise, it is used identically as an MSRP URL, except that a value of "active".

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

When the answerer receives the SDP offer and chooses
MSRPS URL MUST NOT be considered equivalent to participate an MSRP URL. The MSRPS
scheme is further discussed in the session, it must choose whether of act as the host Section 10.

7.2 MSRP messages

MSRP messages are either requests or responses. Requests and
responses are distinguished from one another by the
visitor. A direction attribute value first line. The
first line of "both" in the offer indicates
that a Request takes the offerer wishes to host, but will allow form of the answerer to host,
in which case request-start entry
below. Likewise, the answerer SHOULD act first line of a response takes the form of
response-start. The syntax for an MSRP message is as follows:

Campbell, et al. Expires December 29, 2003 [Page 17]

Internet-Draft SIMPLE IM Sessions June 2003

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 visitor, but MAY choose
to host. A value length of "passive" means the offerer insists upon hosting,
in which case message, exclusive of the answerer start line.
Method = SEND / BIND / VISIT
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

All requests and responses MUST act as visitor or decline the offer.

If contain at least a TR-ID header
field. Messages MAY contain other fields, depending on the answerer chooses to participate as method or
response code.

7.3 MSRP Transactions

An MSRP transaction consists of exactly one request and one response.
A response matches a visitor, transaction if it MUST perform
the following steps:

1. Determine share the host address same TR-ID value,
and port from arrives on the session URL,
following same connection on which the procedures transaction was sent.

BIND is always hop by hop. VISIT transactions are usually hop-by-hop,
but may be relayed in section Section 6.1

2. Connect to situations where the host address and port, using visiting endpoint uses a
relay. However, SEND transactions are end-to-end, meaning that under
normal circumstances the transport
protocol from response is sent by the M-line.

3. Construct a VISIT request, which peer endpoint, even
if there are intervening relays.

Endpoints MUST contain the following
information:

1. An S-URL select TR-ID header field containing values in requests so that
they are not repeated by the 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 NOT
infer any semantics from the session URL.

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

3. An Exp header field containing the expiration time for the
VISIT request. beyond what is stated

Campbell, et al. Expires November 20, December 29, 2003 [Page 17] 18]

Internet-Draft SIMPLE IM Sessions May June 2003

4. A size field containing

above. In particular, TR-ID values are not required to follow any
sequence.

4. Send the request the timeout interval is a matter of local policy, with a
default of 30 seconds after a request has been completely sent.

7.4 MSRP Sessions

AN MSRP session is a context in which a series of instant messages
are exchanged, using SEND requests. A session has two endpoints (a
host and wait for a response

5. If the transaction succeeds, set the actual expiration time visitor) 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 to
the value engage a peer endpoint in a message
session, it invites the Exp header field in peer to communicate using an SDP offer,
carried over SIP or some other protocol supporting the response, and send a SDP offer/
answer via model. For the signaling protocol, according purpose of this document, we will refer to the following
rules:

1. The C-line is copied unmodified from the offer.

2. The M-Line contains a dummy port value, the protocol field
from
endpoint choosing to initiate communication as the original offer, offerer, and a format list describing the
SEND payload media types that
peer being invited as the answerer answerer.

The offerer SHOULD volunteer to act as the hosting endpoint if
allowed by policy and network topology. An endpoint is willing said to
accept. host a
session if one of two conditions are true. The format list in the answer MUST be host either directly
listens for a connection from the same
as the format list in the offer, peer endpoint, and maintains
session state itself, or it uses a subset.

3. A direction attribute containing BIND request to initialize session
state at a relay that will listen for a connection from the value "active".

6. If peer. The
peer that is not the host is designated as the transaction fails, visitor. The offerer
MAY request the answerer MAY choose to act as host, host if allowed by the direction attribute of the answer. If the
answerer it is unable prevented from
accepting connections by network topology or unwilling policy, and is not able
to host, then it should return an
error response as appropriate for the signaling protocol. bind to a relay to act on its behalf.

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

1. Construct a new session MSRP URL . This URL MUST be a MSRP URL, MUST
resolve resolvable to the answerer, and MUST not be the same as the session
URL in the offer.
offerer. The URL SHOULD be temporary, SHOULD be hard to guess,
and MUST not duplicate URLs currently identifying the URL of any
active sessions other session currently
hosted by the answerer. offerer.

2. Listen for a connection from the peer.

3. Construct an SDP answer offer as described in Section 5, mapping 6, including the
list of allowed IM payload formats in the format list. The

Campbell, et al. Expires December 29, 2003 [Page 19]

Internet-Draft SIMPLE IM Sessions June 2003

offerer maps the
new session URL to the session attribute, and inserting attribute, as
described in Section 6.4.

4. Insert a direction attribute. This value SHOULD be "both",
indicating that the offerer will allow the answerer to override
the offerer's decision to host. If "both" is selected, the
offerer SHOULD leave the timeout at the default value (by leaving
out the value entirely." However, the offerer MAY select a
different timeout if circumstances warrant it. The direction
value MAY be "passive" if the offerer is prevented from allowing
the answerer override this choice.

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 the a value of "passive".

4. "active".

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

When the offerer answerer receives the SDP answer, offer and chooses to participate
in the session, it must determine who will
continue to host choose whether of act as the session. If host or the answer contained a
visitor. A direction attribute value of "active", the offerer MUST continue as host. If
the offer contained "active" or "both" and in the answer contains
"passive", then offer indicates
that the offerer MUST wishes to host, but will allow the answerer to host host,
in which case the

Campbell, et al. Expires November 20, 2003 [Page 18]

Internet-Draft SIMPLE IM Sessions May 2003

session.

If answerer SHOULD act as the visitor, but MAY choose
to host. A value of "passive" means the offerer insists upon hosting,
in which case the answerer MUST act as visitor or decline the offer.

If the answerer chooses not to continue participate as host, a visitor, it MUST perform
the following steps:

1. Release resources it acquired in expectation of hosting the
session, if any.

2. Determine the host address and port from the session URL of the
answer, URL,
following the procedures in section Section 6.1

3. 7.1

2. Connect 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. A An S-URL header field containing the session URL.

Campbell, et al. Expires December 29, 2003 [Page 20]

Internet-Draft SIMPLE IM Sessions June 2003

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

3. An Exp header field containing the expiration time for the
VISIT request.

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

4. Send the request and wait for a response

5. If the transaction succeeds, set send a SDP answer via the signaling
protocol, according to the following rules:

1. The C-line is copied unmodified from the offer.

2. The M-Line contains a dummy port value, the protocol field
from the original offer, and a format list describing the
SEND payload media types that the answerer is willing to
accept. The format list in the actual expiration time to answer MUST be either the value in same
as the Exp header field format list in the response, and
acknowledge the answer via offer, or a subset.

3. A direction attribute containing the signaling protocol. value "active".

6. If either the
connection attempt or the VISIT transaction fail, acknowledge fails, the
answer, then initiate answerer MAY choose to act as host,
if allowed by the tear-down direction attribute of the session using answer. If the
signaling protocol.

6.6.2 Handling VISIT requests

An MSRP endpoint that
answerer is hosting a session will receive a VISIT
request from the visiting endpoint. When an endpoint receives a VISIT
request, unable or unwilling to host, then it MUST perform the following procedures:

1. Check if state exists should return an
error response as appropriate for a session with a URL that matches the
S-URL of the VISIT request. If so, and if no visitor signaling protocol.

Some TCP connection
has been associated with the session, determine the expiration failure conditions may ordinarily take some time according
to notice. For example, if the procedures in Section 6.8, then return offerer is unable to open a
200 response, and save state designating the TCP
connection on which

Campbell, et al. Expires November 20, 2003 [Page 19]

Internet-Draft SIMPLE IM Sessions May 2003

the request was received as the visitor leg of the session.

2. If the session exists, and to the visitor host device, this connection has already
been established, and attempt may take a
fairly large number of seconds to timeout. This length of time will
not be acceptable for many call flow scenarios. Therefore, the request arrived on
devices SHOULD limit the existing visitor
connection, treat time they wait for the request as TCP connection to a refresh, as described in
Section 6.8. If
shorter timeout value, which will default to 30 seconds. However, the request arrived on
offerer MAY supply a different connection,
return a 506 response and do not change session state time in any way.

3. the timeout parameter of the
"both" direction value. If no matching session exists, return a 481 request, and do not
change session state in any way.

6.6.3 Sending Instant Messages on a Session

Once the offerer supplies a MSRP session has been established, either endpoint may send
instant messages to its peer using value, the SEND method. When answerer
SHOULD use that value for the TCP connection timeout, interpreted as
an endpoint
wishes integer number of seconds.

If the answerer chooses to do so, host the session, it MUST construct a SEND request according to perform the
following process: steps:

1. Insert the message payload in Construct a new session URL . This MUST be a MSRP or MSRPS URL,
MUST resolve to the body, answerer, and the media type in the
Content-Type header field. The media type MUST match one of the
types in not be the format list negotiated in same as the SDP exchange. If a "*"
is present
session URL in the format list, then the media type offer. The URL SHOULD be temporary, SHOULD match
one of the explicitly listed entries, but MAY be
hard to guess, and MUST not duplicate URLs currently identifying
any other
arbitrary value.

2. Set active sessions hosted by the TR-ID header field to answerer.

2. Listen for a unique value. connection from the peer.

Campbell, et al. Expires December 29, 2003 [Page 21]

Internet-Draft SIMPLE IM Sessions June 2003

3. Send Construct an SDP answer as described in Section 6, mapping the request on
new session URL to the connection associated session attribute, and inserting a
direction attribute with the session. value of "passive".

4. If a 2xx response code is received, Send the transaction was
successful.

5. If a 5xx response code is received, SDP offer using the transaction failed, but
may possibly be successful if retried. The endpoint MAY retry normal processing for the
request as a new transaction, that is, with a new TR-ID value. If signaling
protocol.

When the endpoint offerer receives 5xx responses more than some threshold
number of times in a row, the SDP answer, it SHOULD assume must determine who will
continue to host the session has
failed, and initiate tear-down via session. If the signaling protocol. The
threshold value is answer contained a matter direction
attribute value of local policy.

6. "active", the offerer MUST continue as host. If a 415 response is received, this indicates
the recipient is
unable offer contained "active" or unwilling to process "both" and the media type. The sender SHOULD
NOT attempt answer contains
"passive", then the offerer MUST allow the answerer to send that particular media type again in host the
context of this
session.

If any other response code is received, the endpoint SHOULD
assume offerer chooses not to continue as host, it MUST perform the session has failed,
following steps:

1. Release resources it acquired in expectation of hosting the
session, if any.

2. Determine the host address and initiate tear-down.

Campbell, et al. Expires November 20, 2003 [Page 20]

Internet-Draft SIMPLE IM Sessions May 2003

When an endpoint receives port from the session URL of the
answer, following the procedures in section Section 7.1

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

4. Construct a SEND VISIT request, it which MUST perform contain the following steps.
information:

1. Determine that it understands the media type in A S-URL header field containing the body, if any
exists. session URL.

2. If it does, return A TR-ID header field containing a 200 response and render unique transaction ID.

3. A size field containing size of the message subsequent to the
user. The method of rendering is
start-line.

5. Send the request and wait for a matter of local policy.

3. response

6. If it does not understand the media type, return a 415 response.

6.6.3.1 Ending a Session

When either endpoint in an MSRP session wishes to end transaction succeeds, set the session, it
first signals its intent using actual expiration time to
the normal processing for value in the
signaling protocol. For example, Exp header field in SIP, it would send a BYE request
to the peer. After agreeing to end response, and
acknowledge the session, answer via the host endpoint
MUST release any resources acquired as part of signaling protocol. If either the session. The
process for this differs depending on whether
connection attempt or the session is hosted
directly by VISIT transaction fail, acknowledge the host, or an a relay.

The host MUST destroy local state for
answer, then initiate the session. This involves
completely removing tear-down of the state entry for this session and invalidating session URL. If the host is using an the
signaling protocol.

Campbell, et al. Expires December 29, 2003 [Page 22]

Internet-Draft SIMPLE IM Sessions June 2003

7.4.2 Handling VISIT requests

An MSRP relay, it MUST send endpoint that is hosting a session will receive a BIND
containing an expires value of zero. This VISIT
request MUST be sent host
connection established by from the original BIND request. This BIND
request visiting endpoint. When an endpoint receives a VISIT
request, it MUST include perform the following procedures:

1. Check if state exists for a session with a URL in that matches the
S-URL header field.

Since these host actions completely destroy of the session VISIT request. If so, and if no visitor connection
has been associated with the session, then return a 200 response,
and save state at designating the hosting device, connection on which the request
was received as the visitor is not required to take further
action beyond cleaning up any local state. leg of the session.

2. If for some reason the
host fails to destroy session state, the state will be invalidated
anyway when either of exists, and the original BIND or VISIT requests expire.

6.6.4 Managing Session State visitor connection has already
been established, return a 506 response and Connections

A MSRP do not change session is represented by
state at the host device. As mention
previously, in any way.

3. If no matching session exists, return a 481 request, and do not
change session state is identified by an in any way.

7.4.3 Sending Instant Messages on a Session

Once a MSRP URL. An active session also has two associated network connections. The connection
hosting device and been established, either endpoint may send
instant messages to its peer using the host SEND method. When an endpoint is known as
wishes to do so, it MUST construct a SEND request according to the
following process:

1. Insert the message payload in the body, and the media type in the host connection.
Content-Type header field. The connection with the visiting endpoint is media type MUST match one of the visiting connection.
Note that when
types in the session state is hosted directly by an endpoint, format list negotiated in the host connection may not involve SDP exchange. If a physical network connection;
rather it "*"
is a logical connection present in the device maintains with itself.

When session state is destroyed for any reason, format list, then the hosting device

Campbell, et al. Expires November 20, 2003 [Page 21]

Internet-Draft SIMPLE IM Sessions May 2003 media type SHOULD drop match
one of the connection(s).

If a connection fails for explicitly listed entries, but MAY be any reason, other
arbitrary value.

2. Set the session hosting device MUST
invalidate TR-ID header field to a unique value.

3. Send the session state. This is true regardless of whether request on the
dropped connection associated with the session.

4. If a 2xx response code is received, the host or visiting connection. Once transaction was
successful.

5. If a
connection 5xx response code is dropped, received, the associated session state MUST NOT transaction failed, but
may possibly be
reused. If successful if retried. The endpoint MAY retry the endpoints wish to continue to communicate after a
connection failure, they must initiate
request as a new session. An endpoint
detecting transaction, that is, with a connection failure SHOULD attempt to tear down the
session using new TR-ID value. If
the rules endpoint receives 5xx responses more than some threshold
number of the signaling protocol.

It would be nice to allow sessions to be recovered after times in a
connection failure, perhaps by allowing row, it SHOULD assume the opposite endpoint to
reconnect, session has
failed, and send initiate tear-down via the signaling protocol. The
threshold value is a new VISIT or BIND request. However, this
approach creates matter of local policy.

Campbell, et al. Expires December 29, 2003 [Page 23]

Internet-Draft SIMPLE IM Sessions June 2003

6. If a race condition between the time that the
hosting device notices the failed connection, and 415 response is received, this indicates the time that recipient is
unable or unwilling to process the endpoint tries media type. The sender SHOULD
NOT attempt to recover send that particular media type again in the
context of this session.

7. If any other response code is received, the endpoint
attempts to reconnect prior to SHOULD
assume the hosting device noticing session has failed, and initiate tear-down.

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

1. Determine that it understands the hosting device will interpret media type in the recovery attempt as body, if any
exists.

2. If it does, return a conflict. The only way around this would be to force 200 response and render the hosting
device message to do a liveness check on the original connection, which
would create
user. The method of rendering is a lot matter of complexity and overhead that do local policy.

3. If it does not seem to
be worth understand the trouble.

6.7 MSRP Relays

6.7.1 Establishing Session State at a Relay

An endpoint that wishes to host a MSRP session MAY do so by
initiating session state at media type, return a MSRP relay, rather than hosting
directly. An endpoint may wish to do this because network topology or
local policy prevents 415 response.

7.4.4 Ending a peer from connecting directly Session

When either endpoint in an MSRP session wishes to end the
endpoint. The use of a relay should not be session, it
first signals its intent using the default case, that is, normal processing for the
signaling protocol. For example, in SIP, it would send a hosting BYE request
to the peer. After agreeing to end the session, the host endpoint that
MUST release any resources acquired as part of the session. The
process for this differs depending on whether the session is not prevented from doing so hosted
directly by topology the host, or
policy SHOULD an a relay.

The host MUST destroy local state for the session. This involves
completely removing the state entry for this session directly. In order to use a relay, and invalidating
session URL. If the host is using an MSRP endpoint relay, it MUST have knowledge of that relay's existence and
location..

We previously mentioned how send a BIND
containing an endpoint wishing to expires value of zero. This request MUST be sent host a MSRP
session constructs
connection established by the original BIND request. This BIND
request MUST include the session URL. When using a relay, URL in the endpoint
delegates that responsibility to S-URL header field.

Since these host actions completely destroy the relay.

To establish session state at a relay,
the endpoint MUST perform hosting device, the
following steps:

1. Open a network connection visitor is not required to take further
action beyond cleaning up any local state. If for some reason the
host fails to destroy session state, the relay state will be invalidated
anyway when the inactivity timer expires.

7.4.5 Session Inactivity Timer

State associated with MSRP sessions, either at the relays address and
the well-known port for MSRP relays, host endpoint, or at another port if so
a hosting or visiting relay, is soft-state; that is, it expires over

Campbell, et al. Expires November 20, December 29, 2003 [Page 22] 24]

Internet-Draft SIMPLE IM Sessions May June 2003

configured.

2. Construct

time if no message activity occurs. Each such device maintains a BIND request pair
of inactivity timer, each with a S-URL that refers to the relay.

3. Set an initial value of 1 minute. One of
these timers is assigned for each endpoint.

All devices use the Expire header field to a desired same, predetermined timer expiration value.

4. Send the BIND request
While there might be some utility in negotiating this timer on the connection.

5. Respond a
per device basis, such negotiation would add a great deal of
complexity to any authentication request from MSRP.

When a hosting device or visiting relay returns a successful response
to a VISIT request, it MUST initialize both timers. The device MUST
reset a timer anytime the relay.

6. associated endpoint sends a SEND request.
If either timer expires without being reset, the response has a 2xx status code, use device MUST
invalidate the URL session, using normal procedures depending on the
device's role in the S-URL
header field as session.

Each endpoint MUST keep a similar timer, which it initializes when
the session URL. The endpoint uses is created from its perspective. For the host endpoint,
this URL is when it receives a successful response to a BIND request. For
a visiting 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 in
exactly the same manner as it had constructed session, it itself.
Additionally, accept
MUST send a SEND request. This request MAY be sent without a body if
there is no user data to send. Endpoints MUST select the expires timer value in the response as session
expiration time.

A MSRP relay listens
so that there is sufficient time for connections the SEND request to traverse to its well-known port at all
times. When it receives a BIND request, it SHOULD authenticate
the
request, either using digest-authentication, TLS authentication, or
some other authentication mechanism. opposite endpoint. If authentication succeeds, the
relay performs the following steps:

1. Verify endpoint waits to the client last moment,
there is authorized to BIND to this relay. If not,
return a 403 response danger that it will not be received by all relevant
devices in time to prevent session destruction.

7.4.6 Managing Session State and make no Connections

A MSRP session is represented by state change.

2. If at the client is authorized, construct a host device. As mention
previously, session state is identified by an MSRP URL. An active
session also has two associated network connections. The
URL MUST resolve to the relay. It SHOULD be temporary, connection
hosting device and hard
to guess. It MUST not duplicate URL used in any active sessions
hosted by the relay. If host endpoint is known as the relay wishes host connection.
The connection with the visiting endpoint to
connect over a point other than the MSRP relay well-know port, it
MUST explicitly add the port number to visitor URL.

3. Establish is the expiration time for visiting connection.
Note that when the session according to
section Section 6.8.

4. Create state for the session. The relay MUST associate is hosted directly by an endpoint,
the host connection on which may not involve a physical network connection;
rather it is a logical connection the device maintains with itself.

When session state is destroyed for any reason, the BIND request arrived as hosting device
SHOULD drop the host connection(s).

If a connection fails for the session.

5. Return a 200 response, with any reason, the session URL in the S-URL header
field, and hosting device MUST
invalidate the session expiration time in the Exp header field..

When an MSRP relay receives a VISIT request, it MUST perform state. This is true regardless of whether the
following steps:

1. Check
dropped connection is the S-URL header field value to see it matches host or visiting connection. Once a
connection is dropped, the URL for
an existing associated session state entry. MUST NOT be

Campbell, et al. Expires November 20, December 29, 2003 [Page 23] 25]

Internet-Draft SIMPLE IM Sessions May June 2003

reused. If not, return the endpoints wish to continue to communicate after a 481 response and make no state changes

3. If it matches, but another
connection has already been associated
with failure, they must initiate a new session. An endpoint
detecting a connection failure SHOULD attempt to tear down the
session URL, return using the rules of the signaling protocol.

It would be nice to allow sessions to be recovered after a 506 response and make no state
changes. If
connection failure, perhaps by allowing the session has been previously associated with opposite endpoint to
reconnect, and send a new VISIT or BIND request. However, this
approach creates a race condition between the time that the
hosting device notices the failed connection, treate and the request as a refresh.

4. time that
the endpoint tries to recover the session. If it matches, and no visiting connection has been previously
associated with the session, then endpoint
attempts to reconnect prior to the VISIT succeeds. The relay
assigns hosting device noticing the connection on which it received
failure, the VISIT request hosting device will interpret the recovery attempt as
a conflict. The only way around this would be to force the visiting connection for hosting
device to do a liveness check on the session, and returns original connection, which
would create a 200
response. The visit expiration time is established as described
in Section 6.8 lot of complexity and returned in overhead that do not seem to
be worth the response.

6.7.2 Removing trouble.

7.5 MSRP Relays

7.5.1 Establishing Session State from at a relay Relay

An endpoint that wishes to host a MSRP relay SHOULD remove session MAY do so by
initiating session state for at a session when any of MSRP relay, rather than hosting
directly. An endpoint may wish to do this because network topology or
local policy prevents a peer from connecting directly to the
following conditions occur:

o
endpoint. The expiration time for either use of a relay should not be the BIND or VISIT is reached
without default case, that is,
a respective refresh request.

o The hosting endpoint that is not prevented from doing so by topology or
policy SHOULD host sends the session directly. In order to use a BIND refresh request matching with relay, an expiration
value
MSRP endpoint MUST have knowledge of zero.

o Either the host or visitor network connection fails for any
reason.

6.7.3 Sending IMs across that relay's existence and
location..

We previously mentioned how an endpoint wishing to host a MSRP relay

Once
session constructs session URL. When using a relay, the endpoint
delegates that responsibility to the relay.

To establish session state at a relay, the endpoint MUST perform the
following steps:

1. Open a session is established network connection to the relay at a relay, the host relays address and visitor may
exchange IMs by sending SEND requests. Under normal circumstances,
port. Normally, this information will be resolved from an MSRP
URL representing the relay does not respond to SEND requests in any way. Rather, relay, although the relay MUST forward the MAY be configured
with an explicit address and port, rather than a URL.

2. Construct a BIND request with a S-URL that refers to the peer connection unchanged.
Likewise, if relay.

3. Set the relay receives Expire header field to a response it MUST forward desired value.

Campbell, et al. Expires December 29, 2003 [Page 26]

Internet-Draft SIMPLE IM Sessions June 2003

4. Send the BIND request unchanged on the peer connection.

If a SEND

5. Respond to any authentication request arrives on a connection that is not associated with
a session, from the relay MUST return relay.

6. If the response has a 481 response.

6.7.4 Relay Pairs

In rare circumstances, two relays may be required 2xx status code, use the URL in a session. For
example, two endpoints may exist the S-URL
header field as the session URL. The endpoint uses this URL in separate administrative domains,
where each domain's policy insist that
exactly the same manner as it had constructed it itself.
Additionally, accept the expires value in the response as
pre-visit expiration time.

A MSRP relay listens for connections at all sessions must cross that
domain's times. When it receives 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 is authorized to BIND to this relay. A relay operating on behalf of If not,
return a 403 response and make no state change.

2. If the visiting endpoint

Campbell, et al. Expires November 20, 2003 [Page 24]

Internet-Draft SIMPLE IM Sessions May 2003 client is known as authorized, construct a visiting relay. An session MSRP relay MAY URL. The
URL MUST resolve to the relay. It SHOULD be capable of acting
as a visiting temporary, and hard
to guess. It MUST not duplicate URL used in any active sessions
hosted by the relay.

In a two If the relay scenario, wishes the visitor connects visiting endpoint to
connect over a relay operating on
its behalf, rather point other than connecting directly to the hosting device.
The visitor sends a VISIT request as it would if MSRP relay well-know port, it had connected
directly
MUST explicitly add the port number to visitor URL.

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

4. Create state for the session. The visiting relay then connect to MUST associate the hosting device and performs a VISIT request
connection on behalf of which the
visitor.

When a relay that is capable of acting BIND request arrived as a visiting relay receives a
VISIT request, it MUST check to see if the S-URL of host
connection for the request
matches session.

5. Return a domain that the relay hosts. If 200 response, with the session URL matches, then the
visitor is not requesting in the relay act as a visiting relay, S-URL header
field, and it
SHOULD operate normally. If the URL does not match, then pre-visit session expiration time in the Exp
header field.

When an MSRP relay
SHOULD receives a VISIT request, it MUST perform the
following steps:

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

2. Determine that Check the visiting endpoint is authorized S-URL header field value to use this
device as a visiting relay. see it matches the URL for
an existing session state entry.

2. If not, return a 403 481 response and
drop the connection. make no state changes

3. Attempt to open a If it matches, but another connection to the hosting device, determining has already been associated
with the address session URL, return a 506 response and port from make no state
changes. If the S-URL exactly session has been previously associated with this

Campbell, et al. Expires December 29, 2003 [Page 27]

Internet-Draft SIMPLE IM Sessions June 2003

connection, treat the request as if it were a
visiting endpoint connecting directly. refresh.

4. If this it matches, and no visiting connection is
successful, continue has been previously
associated with the remaining steps. Otherwise, return session, then the VISIT succeeds. The relay
assigns the connection on which it received the VISIT request as
the visiting connection for the session, and returns a 500 200
response.

4. Create local

7.5.2 Removing Session State from a relay

An MSRP relay SHOULD remove state to associate for a session when any of the
following conditions occur:

o The session inactivity timer expires.

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

o The host sends a BIND refresh request matching with an expiration
value of zero.

o Either the host or visitor network connection to fails for any
reason.

7.5.3 Sending IMs across an MSRP relay

Once a session is established at a relay, the host device
with and visitor may
exchange IMs by sending SEND requests. Under normal circumstances,
the connection relay does not respond to SEND requests in any way. Rather, the visiting device.

5. Relay
relay MUST forward the VISIT request unchanged to the hosting device.

6. Relay peer connection unchanged.
Likewise, if the relay receives a response to it MUST forward the VISIT
request unchanged to on the visiting
endpoint. peer connection.

If the response a SEND request arrives on a connection that is not associated with
a 200, set the expiration time for
the local session state to the value in the Exp header in session, the relay MUST return a 481 response.

7.5.4 Relay all subsequent arriving on one of the associated
connections to the peer connection.

The preceding steps result Pairs

In rare circumstances, two relays may be required in local session state a session. For
example, two endpoints may exist in separate administrative domains,
where each domain's policy insist that expires based all sessions must cross that
domain's relay. A relay operating on the expiration time negotiated between behalf of the visiting endpoint and
the hosting device. The
is known as a visiting relay. An MSRP relay MAY be capable of acting
as a visiting relay.

This document does not describe a mechanism for an endpoint will send VISIT requests on
the same connection from time to time
discover that it needs to refresh the session state
expiration time. A use a visiting relay MUST refresh the local expiration relay. We assume that an

Campbell, et al. Expires November 20, December 29, 2003 [Page 25] 28]

Internet-Draft SIMPLE IM Sessions May June 2003

time based

endpoint is globally configured to use or not use such a relay,
and does not make this decision on the Exp header field value in a successful response session-by-session basis.
This, of course, does not preclude using some other mechanism to
make such a VISIT request. If the local expiration time passes without decision.

In a
refresh, the visiting two relay SHOULD invalidate scenario, the session state and
SHOULD drop visitor connects to a relay operating on
its behalf, rather than connecting directly to the associated connections.

If either associated connection fails for any reason, hosting device.
The visitor sends a VISIT request as it would if it had connected
directly to the hosting device. The visiting relay SHOULD invalidate then connects to
the session state, hosting device and SHOULD drop the peer
connection.

6.8 Session State Expiration

State associated with MSRP sessions, either at performs a VISIT request on behalf of the host endpoint or
visitor.

When a
host relay, is soft-state; relay that is, it expires over time unless
refreshed. The expiration time is determined by the Expires header
field in VISIT and BIND requests. All capable of acting as a visiting relay receives a
VISIT and BIND requests request, it MUST
contain an Expires header field. This field is defined as an integer
number check to see if the S-URL of seconds from the time request
matches a domain that the request relay hosts. If the URL matches, then the
visitor is received.

When a hosting device (endpoint or relay) creates session state due
to not requesting the relay act as a successful VISIT request, visiting relay, and it
SHOULD accept operate normally. If the Expires value
from URL does not match, then the relay
SHOULD perform the following steps:

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

2. Determine that the visiting endpoint is authorized to use this
device as a smaller value. It MUST NOT
choose visiting relay. If not, return a larger value. The device MUST communicate 403 response and
drop the actual chosen
value back connection.

3. Attempt to the opposite endpoint by placing the value in an
expires header field in the response.

Likewise, when open a relay creates session state due connection to a successful BIND
request, it SHOULD accept the expires value hosting device, determining
the address and port from the request,
although S-URL exactly as if it MAY choose were a smaller value. It MUST NOT choose
visiting endpoint connecting directly. If this connection is
successful, continue with the remaining steps. Otherwise, return
a larger
value. The device MUST communicate 500 response.

4. Create local state to associate the actual chosen value back connection to the opposite endpoint by placing host device
with the value in an Expires header field
in connection to the response.

A visiting relay does not normally respond to a VISIT request.
Rather, it relays device.

5. Relay the VISIT request unchanged to the hosting device, and relays device.

6. Relay the
resulting response back to the VISIT request unchanged to the visiting
endpoint. This prevents it
from being able

7. Relay all subsequent arriving on one of the associated
connections to negotiate the expiration time in peer connection.

If either associated connection fails for any reason, the same way as
hosting devices. Therefore, a visiting
relay MUST determine session
expiration time from invalidate the Exp header field in any 200 response
returned by session state, and MUST drop the hosting device.

6.9 peer
connection.

Campbell, et al. Expires December 29, 2003 [Page 29]

Internet-Draft SIMPLE IM Sessions June 2003

7.6 Digest Authentication

MSRP relays may use the digest authentication scheme to authenticate
users. MSRP digest authentication is a simplified version of HTTP
digest authentication [18], [19], but this specification does not
normatively depend on that document. MSRP digest authentication does
not support the concept of a protection domain, nor does it support
integrity protection. Since a user of a relay is expected to have

Campbell, et al. Expires November 20, 2003 [Page 26]

Internet-Draft SIMPLE IM Sessions May 2003
credentials for that particular relay, it does not support the realm
concept. Finally, since digest authentication is only expected for
the initial BIND or VISIT request, MSRP does not support HTTP digest
optimizations such as MD5-sess and preemptive credential loading by
the client.

Typically, a hosting user that uses a relay will have a preexisting
relationship with that relay. This relationship SHOULD include
authentication credentials. An MSRP relay SHOULD authenticate initial
BIND requests.

It is less likely that the visiting user will have an account at the
hosting relay, so in many most cases the authentication of VISIT requests
is not useful. However a relay MAY authenticate initial VISIT
requests. A visiting relay SHOULD authenticate initial VISIT
requests, as it is much more likely to share credentials with the
visiting user.

There has been some discussion that a hosting relay SHOULD also
authenticate VISIT requests. However, it will be very common for
visiting users to have no preexisting relationship with the host
relay. Using authentication here would require the host endpoint
to send temporary credentials in the SDP exchange, perhaps as part
of the session URL. However, these temporary credentials would
necessarily be transferred via the same channels as the session
URL itself. If the credentials are sufficiently protected in
transfer, then so is the session URL. Further, since the session
URL is intended for a one time use, and is expected to be hard to
guess, that URL itself may should be sufficient for this purpose. Any
situation where this is not adequate can be covered by the use of
the MSRPS scheme.

MSRP relays MUST NOT request authentication for any method other than
BIND and VISIT.

If a relay wishes to authenticate a request using digest
authentication, 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

Campbell, et al. Expires December 29, 2003 [Page 30]

Internet-Draft SIMPLE IM Sessions June 2003

received in a 401 response, it MAY do so by sending a new VISIT or
BIND request, identical to the previous request, but with a CAuth
header field containing the response to the challenge.

6.9.1

7.6.1 The MD5 SHA1 Algorithm

The only digest authentication algorithm defined in this
specification is MD5. [8] SHA1. [9] Other algorithms can be added as
extensions. MD5 SHA1 is the default algorithm if no algorithm directive
is present in the challenge.

Campbell, et al. Expires November 20, 2003 [Page 27]

Internet-Draft SIMPLE IM Sessions May 2003

The MD5 algorithm SHA1 digest is defined as follows:

Let KD(secret, data) denote the string obtained by performing the
digest algorithm to the data "data" with the secret "secret". Let
H(data) denote the string obtained by performing the checksum
algorithm on the data "data".

For the "MD5" "SHA1" algorithm, H(data) = MD5(data), SHA1(data), and KD(secret,data) =
H(concat(secret, ":", data)

The request-digest value in a CAuth header field takes the following
format. Note that unq(quoted-string) denotes the value of the string
with the quotes removed.

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

When the relay receives a CAuth header, it SHOULD check its validity
by looking up the shared secret, or H(A1), performing the same digest
operation as performed by the client, and comparing the results to
the request-digest value.

6.10

7.7 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. Except where otherwise noted, all requests are hop
by hop.

6.10.1

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 be

Campbell, et al. Expires December 29, 2003 [Page 31]

Internet-Draft SIMPLE IM Sessions June 2003

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.

6.10.2

7.7.2 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

Campbell, et al. Expires November 20, 2003 [Page 28]

Internet-Draft SIMPLE IM Sessions May 2003
in the format list negotiated in the SDP exchange. If a body is
present, the request MUST contain a Content-Type header field
identifying the media type of the body.

Unlike other methods, SEND requests are end to end in nature. This
means the request is consumed only by the opposite endpoint. Under
normal conditions, any intervening relays merely forward the request
on towards the peer endpoint.

6.10.3

7.7.3 VISIT

The visiting endpoint uses the VISIT method to associate a network
connection with the session state at the hosting device, which could
be either the host endpoint or a relay operating on behalf of the
host endpoint. VISIT is also used to refresh the expiration time for
the visiting connection. The request MUST contain a S-URL header matching the
session URL. A VISIT request MUST contain the Expires
header field.

Successful responses to a VISIT request MUST contain the Expires
header.

There is normally no authentication operation for the VISIT
request. This is because the session URL acts as a shared secret
between host and the visitor. This puts certain requirements on
the handling of the session URLs that are discussed in Section 9. 10.
However, if a visiting relay is used, it SHOULD authenticate
initial VISIT requests, and MAY authenticate subsequent VISIT
refresh
requests.

6.11

7.8 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. Responses are never
consumed by relays.

6.11.1

7.8.1 200

The 200 response code indicates a successful transaction.

6.11.2 400

A 400 response indicates a request was unintelligible.

6.11.3 401

Campbell, et al. Expires November 20, December 29, 2003 [Page 29] 32]

Internet-Draft SIMPLE IM Sessions May June 2003

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
MUST NOT be used in response to any method other than BIND and VISIT.
A 401 response MUST contain a SChal header field.

6.11.4

7.8.4 403

A 403 response indicates the user is not authorized to perform the
action.

6.11.5

7.8.5 415

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

6.11.6

7.8.6 426

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

Open Issue: Do we need to make 426 extensible to support other
types of protection?

7.8.7 481

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

6.11.7

7.8.8 500

A 500 response indicates that a relay was unable to deliver a SEND
request to the target.

6.11.8

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

6.12

7.9 Header Field Descriptions

This section summarizes the various header fields. MSRP header fields

Campbell, et al. Expires December 29, 2003 [Page 33]

Internet-Draft SIMPLE IM Sessions June 2003

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

6.12.1

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

6.12.2

7.9.2 Exp

The Exp header field specifies when the state associated with a BIND
or VISIT
request will expire. expire, if no successful VISIT request has been
received.. The value is specified as an integer number of seconds
from the time the request is received. BIND and

Campbell, et al. Expires November 20, 2003 [Page 30]

Internet-Draft SIMPLE IM Sessions May 2003

VISIT requests MUST contain
this header field. Furthermore, successful responses to BIND or VISIT requests must
MUST also contain the Exp header.

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

Exp has no meaning if it occurs in MSRP messages other than BIND and
VISIT
requests, and responses to those requests. MSRP compliant devices
SHOULD NOT use Exp in other requests or responses, unless that usage
is defined in an extension to this specification.

6.12.3

7.9.3 CAuth

The CAuth header field is used by a host endpoint to respond to offer
digest authentication credentials to a relay, usually in response to
a digest authentication challenge. CAuth SHOULD NOT be present in a
request of any method other than BIND and VISIT.

The CAuth credentials adhere to the following syntax:

credentials = "Digest" digest-response
digest-response = 1#( username | nonce |
response | [ algorithm ] |
[auth-param] )

username = "username" "=" username-value
username-value = quoted-string
response = "response" "=" request-digest
request-digest = <"> 32LHEX <">
LHEX = "0" | "1" | "2" | "3" |
"4" | "5" | "6" | "7" |
"8" | "9" | "a" | "b" |
"c" | "d" | "e" | "f"

Campbell, et al. Expires December 29, 2003 [Page 34]

Internet-Draft SIMPLE IM Sessions June 2003

The meaning of each value is as follows:

username: The user's account name.

nonce: The nonce value copied from the challenge.

response: A 32 hex digit string that proves user knowledge of the
shared secret.

algorithm: The algorithm value copied from the challenge.

auth-param: Additional parameters for the sake of extensibility.

Campbell, et al. Expires November 20, 2003 [Page 31]

Internet-Draft SIMPLE IM Sessions May 2003

6.12.4

7.9.4 SChal

The SChal header field is used by a relay to carry the challenge in a
digest authentication attempt. Exactly one SChal header field MUST
exist in a 401 response. The SChal header MUST NOT be used in any
message except for a 401 response. The SChal header field value is
made up of a challenge according to the following syntax:

challenge= digest-scheme SP digest-challenge

digest-scheme = "Digest"
digest-challenge = 1#( nonce | [ algorithm ] |
[auth-param] )
nonce = "nonce" "=" nonce-value
nonce-value = quoted-string
algorithm = "algorithm" "=" ( "MD5" "SHA1" | token )

The meaning of each value is as follows:

digest scheme: A token to identify the particular authentication
scheme. For digest, the value MUST be "Digest." This token is
present for the sake of extensibility.

nonce: A server-specified string, which the relay SHOULD uniquely
generate each time it sends a 401 response. This string SHOULD
take the form of base64 or hexadecimal data, to avoid the presence
of a double-quote character, which is not allowed.

algorithm: A token indicating the algorithms to be used to generate
the digest and checksum. This directive exists for the sake of
extensibility; the only value defined by this document is "MD5".
absence "SHA1".
Absence of this directive indicates a value of "MD5."

6.12.5 "SHA1".

Campbell, et al. Expires December 29, 2003 [Page 35]

Internet-Draft SIMPLE IM Sessions June 2003

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

6.12.6

7.9.6 S-URL

The S-URL header field is used to identify the session. The S-URI
header field MUST be present in a BIND request, a successful response
to a BIND request, or a VISIT request.

8. Examples

Campbell, et al. Expires November 20, 2003 [Page 32]

Internet-Draft SIMPLE IM Sessions May 2003

This section shows some example message flows for various common
scenarios. The examples assume SIP is used to transport the SDP
exchange. Details of the SIP messages and SIP proxy infrastructure
are omitted for the sake of brevity. In the examples, 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.

7.1

8.1 No Relay

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

Campbell, et al. Expires December 29, 2003 [Page 36]

Internet-Draft SIMPLE IM Sessions June 2003

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) SEND |
|<-----------------------|
|(9) (MSRP) 200 OK |
|----------------------->|
|(10) (SIP) BYE |
|----------------------->|
|(11) (SIP) 200 OK |
|<-----------------------|
| |
| |

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

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

c=IN IP4 fillername
m=message 7777 9999 msrp/tcp text/plain
a=direction:both
a=session:msrp://alicepc.atlanta.com/iau39:7777

3. Bob->Alice: Open

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

4. alicepc.atlanta.com:7777:

Bob->Alice (MSRP):

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

Campbell, et al. Expires December 29, 2003 [Page 37]

Internet-Draft SIMPLE IM Sessions June 2003

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 7777 9999 msrp/tcp text/plain
a=direction:active

5. Alice->Bob (SIP): ACK

6. Alice->Bob (MSRP):

Campbell, et al. Expires November 20, 2003 [Page 33]

Internet-Draft SIMPLE IM Sessions May 2003

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

10.

8. Bob->Alice (MSRP):

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

Hi, Alice! I'm Bob!

11.

9. Alice->Bob (MSRP):

MSRP xx 200 OK
TR-ID: 456

12.

10. Alice->Bob (SIP): BYE

13.

Alice invalidates session and drops connection.

14.

Campbell, et al. Expires December 29, 2003 [Page 38]

11. Bob invalidates local state for the session.

15.

Bob->Alice (SIP): 200 OK

7.2

8.2 Single Relay

This scenario introduces 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 | |
|<-----------------------| |
|(19) (SIP) 200 OK | |

Campbell, et al. Expires December 29, 2003 [Page 39]

Internet-Draft SIMPLE IM Sessions June 2003

|<------------------------------------------------|
| | |
| | |

1. Alice->Relay (MSRP): Alice opens a connection to the relay, and
sends the following:

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

Campbell, et al. Expires November 20, 2003 [Page 34]

Internet-Draft SIMPLE IM Sessions May 2003

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 7777 9999 msrp/tcp text/plain
a=direction:passive
a=session:msrp://relay.atlanta.com:7777/iau39

4. Bob->Alice: Open connection to relay.atlanta.com:7777.

Bob->Relay (MSRP):

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

5. Relay->Bob (MSRP):

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

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

Campbell, et al. Expires December 29, 2003 [Page 40]

Internet-Draft SIMPLE IM Sessions June 2003

c=IN IP4 nobodybutchickens nobodybutuschickens
m=message 7777 9999 msrp/tcp 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!

Campbell, et al. Expires November 20, 2003 [Page 35]

10.

9. Relay->Bob (MSRP):

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

11.

10. Bob->Relay (MSRP):

MSRP xx 200 OK
TR-ID: 123

12.

11. Relay->Alice (MSRP):

MSRP xx 200 OK
TR-ID: 123

13.

12. Bob->Relay (MSRP):

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

Hi, Alice! I'm Bob!

14.

13. Relay->Alice (MSRP):

MSRP xx SEND
TR-ID: 456

Campbell, et al. Expires December 29, 2003 [Page 41]

Internet-Draft SIMPLE IM Sessions June 2003

Content-Type: "text/plain"

Hi, Alice! I'm Bob!

15.

14. Alice->relay (MSRP):

MSRP xx 200 OK
TR-ID: 456

16.

15. Relay->Bob (MSRP):

MSRP xx 200 OK
TR-ID: 456

Campbell, et al. Expires November 20, 2003 [Page 36]

Internet-Draft SIMPLE IM Sessions May 2003

17.

16. Alice->Bob (SIP): BYE

18.

17. Alice->Relay (MSRP):

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

19.

18. Relay->Alice (MSRP): (relay Relay invalidates session state) state.

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

20. Bob invalidates local state for the session.

21. Bob->Alice (SIP):
TR-ID: 42
Exp:0

19. Bob invalidates local state for the session.

Bob->Alice (SIP): 200 OK

8.3 Two Relays

In this scenario, both Alice and Bob are each required by local
policy to route all sessions through a different local relay.

Campbell, et al. Expires December 29, 2003 [Page 42]

Internet-Draft SIMPLE IM Sessions June 2003

|(1) (MSRP) BIND | |
|------------->| | |
|(2) (MSRP) 200 OK | |
|<-------------| | |
|(3) (SIP) INVITE | |
|------------------------------------------->|
| | |(4) (MSRP) VISIT
| | |<-------------|
| |(5) (MSRP) VISIT |
| |<-------------| |
| |(6) (MSRP) 200 OK |
| |------------->| |
| | |(7) (MSRP) 200 OK
| | |------------->|
|(8) (SIP) 200 OK | |
|<-------------------------------------------|
|(9) (SIP) ACK | | |
|------------------------------------------->|
|(10) (MSRP) SEND | |
|------------->| | |
| |(11) (MSRP) SEND |
| |------------->| |
| | |(12) (MSRP) SEND
| | |------------->|
| | |(13) (MSRP) 200 OK
| | |<-------------|
| |(14) (MSRP) 200 OK |
| |<-------------| |
|(15) (MSRP) SEND | |
|<-------------| | |
|(16) (SIP) BYE| | |
|------------------------------------------->|
|(17) (MSRP) BIND | |
|------------->| | |
|(18) (MSRP) 200 OK | |
|<-------------| | |
|(19) (SIP) 200 OK

7.3 Two Relays

In this scenario, both Alice and Bob are each required by local
policy to route all sessions through a different local relay. | |
|<-------------------------------------------|
| | | |
| | | |

1. Alice->AtlantaRelay (MSRP): Alice opens a connection to the her
relay, and sends the following:

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

Campbell, et al. Expires December 29, 2003 [Page 43]

Internet-Draft SIMPLE IM Sessions June 2003

Exp:600

2. AtlantaRelay->Alice (MSRP):

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

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

c=IN IP4 blahblahblah
m=message 7777 9999 msrp/tcp text/plain

Campbell, et al. Expires November 20, 2003 [Page 37]

Internet-Draft SIMPLE IM Sessions May 2003
a=session:msrp://relay.atlanta.com:7777/iau39
a=direction:passive

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

5. relay.

Bob->BiloxiRelay (MSRP): Bob opens a connection to his relay,
and sends the following:

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

5. BiloxiRelay->AtlantaRelay (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
Exp:600

6. AtlantaRelay->BiloxiRelay(MSRP):

MSRP xx 200 OK
TR-ID: 934
Exp:600

7. BiloxiRelay->Bob(MSRP):

MSRP xx 200 OK

Campbell, et al. Expires December 29, 2003 [Page 44]

Internet-Draft SIMPLE IM Sessions June 2003

TR-ID: 934
Exp:600

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

c=IN IP4 stuff
m=message 7777 9999 msrp/tcp text/plain
a=direction: active

10.

9. Alice->Bob (SIP): ACK

Campbell, et al. Expires November 20, 2003 [Page 38]

11.

10. Alice->AtlantaRelay (MSRP):

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

12.

11. AtlantaRelay ->BiloxiRelay (MSRP):

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

13.

12. BiloxiRelay->Bob (MSRP):

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

14.

13. Bob->BiloxiRelay (MSRP):

MSRP xx 200 OK
TR-ID: 123

15.

14. BiloxiRelay->AtlantaRelay (MSRP):

MSRP xx 200 OK
TR-ID: 123

16.

Campbell, et al. Expires December 29, 2003 [Page 45]

Internet-Draft SIMPLE IM Sessions June 2003

15. AtlantaRelay->Alice (MSRP):

MSRP xx 200 OK
TR-ID: 123

17.

16. Alice->Bob (SIP): BYE

18.

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 invalidates session state.

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

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

Campbell, et al. Expires December 29, 2003 [Page 46]

Internet-Draft SIMPLE IM Sessions June 2003

9.2.3 Intended Usage

See Section 7.1.

9.2.4 Protocols

The Message Session Relay Protocol (MSRP).

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.

9.3.2 Wrapped Types

Attribute-name: accept-wrapped-types

Long-form Attribute Name Acceptable MIME Types Inside Wrappers

Type: Media level

Subject to Charset Attribute No

Campbell, et al. Expires November 20, December 29, 2003 [Page 39] 47]

Internet-Draft SIMPLE IM Sessions May June 2003

Exp:0

19. Relay->Alice (MSRP): (relay invalidates session state)

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

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

8. IANA

Purpose and Appropriate Values See Section 6.3.

10. Security Considerations

To Do.

Do we need

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.

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 TLS handshake request, the device ceases to watch for
the TLS handshake and begins normal MSRP processing.

An MSRP device MAY refuse to accept a given request over a non-TLS
connection by returning a 426 response, after which it MUST either
immediately close the connection, or begin watching for a TLS
handshake request as it would if it had just accepted a connection.

MSRP devices acting in the role of TCP client MAY perform a TLS
handshake either immediately upon connection, or immediately after
receiving a 426 response. They MUST NOT attempt to upgrade to TLS at
any other time.

Allowing clients to upgrade at any time would require the server
device to register URL schemes check every single request to determine if it is an MSRP
request or SDP a-line attributes?

9. Security Considerations

There are a number of security considerations TLS handshake request. The specified approach only
requires this check on the initial data received on a connection,
or on data received immediately after a 426 response. In both
cases, the receiver will have to peek ahead in the received data
stream to look for MSRP, some the TLS, then read again from the start once
the presence or absence of which
are mentioned elsewhere in this document. This section discusses
those further, and introduces some new ones.

9.1 The MSRPS Scheme TLS has been determined.

The MSRPS URI scheme indicates that all hops in an MSRP session MUST
be protected with TLS. Ensuring this implies some additional rules. An
MSRP A
relay MUST NOT return an MSRPS URL in the S-URL header field in
a response to a BIND request unless the BIND request itself was
received over a TLS protected session. A VISIT request for an MSRPS
URL MUST be sent over a TLS protected connection. If a visiting relay
receives a VISIT request for an MSRPS URL, the connection to the
hosting device MUST also be protected.

There has been controversy on whether an MSRPS scheme is really
needed, since there is a small limit to the total number of hops
in an MSRP session. However, a mechanism is required to inform the
visitor to use TLS in the first place. We could have used an SDP
a-line attribute for this. However, there also needs to be a
mechanism for a hosting relay to tell the host endpoint to request
the visitor use TLS. The MSRPS scheme seems to best fit all of
these requirements.

Open Issue: There is also some controversy if the request
arrived over how TLS should be
used with MSRP. The changes and included a MSRPS URI in this draft version make it possible the S-URI header field.
The relay MAY return an MSRPS URI to any BIND request that arrives

Campbell, et al. Expires November 20, December 29, 2003 [Page 40] 48]

Internet-Draft SIMPLE IM Sessions May June 2003

for relays to act as tunnels, where the TLS handshake is
end-to-end. This is much the same way that TLS is handled by HTTPS
proxies. However, this usage requires at least one endpoint

over TLS, but MUST NOT return an MSRP URI to
have a TLS server certificate, which may BIND request that does
not be likely. Another
approach is to make TLS usage hop-by-hop. When at least one arrive over TLS. If a relay
is used, only receives a BIND request with an MSRPS
S-URI, over a non-TLS connection, it MUST reject the relays would need server certificates. Even if
we support end-to-end TLS, we request with a
426 response. A relay may still need insist on always using MSRPS by returning a way
426 to specify
hop-by-hop TLS, because since end-to-end TLS would delay the TLS
handshake until _after_ the BIND any bind received over an unprotected connection, and VISIT requests, these always
returning MSRPS URLs to BIND requests would not over protected connections.

A VISIT request for an MSRPS URL MUST be protected.

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

10.2 Sensitivity of the Session URL

The URL of a MSRP session is used by the visiting endpoint to
identify itself to the hosting device, regardless of whether the
session is directly hosted by the host endpoint, or is hosted by a
relay. If an attacker were able to acquire 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
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.

9.3

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

Campbell, et al. Expires November 20, December 29, 2003 [Page 41] 49]

Internet-Draft SIMPLE IM Sessions May June 2003

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.

Open Issue: This subsection needs very close scrutiny for accuracy
and security. In particular, do we need to say more about the
signaling protocol is SIP, the SDP exchange MUST be protected using
secret key operations in CMS?

9.4
S/MIME.

10.4 CPIM compatibility

MSRP sessions may be gatewayed to other CPIM [16]compatible [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
include "message/cpim" as the first entry in its SDP format list.
MSRP endpoints sending instant messages to a peer peer that has included
'message/cpim" as the first entry in the format list SHOULD
encapsulate all instant message bodies in "message/cpim" wrappers.
All MSRP endpoints SHOULD support the S/MIME features of that format.

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

11. Changes from Previous Draft Versions

Campbell, et al. Expires December 29, 2003 [Page 50]

Internet-Draft SIMPLE IM Sessions June 2003

This section to be deleted prior to publication as an RFC

11.1 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 included
'message/cpim" normal SDP meaning.

Clarified that an endpoint is globally configured as to whether or
not to use a relay. There is no relay discovery mechanism
intrinsic to MSRP.

Changed digest algorithm to SHA1. Added TR-ID and S-URI to the first entry in
hash for digest authentication.

CMS usage replaced with S/MIME.

TLS and MSRPS usage clarified.

Session state timeout is now based on SEND activity, rather than
BIND and VISIT refreshes.

Default port added.

Added sequence diagrams to the format list SHOULD
encapsulate all instant example message bodies in "message/cpim" wrappers.
All MSRP endpoints SHOULD support the S/MIME features flows.

Added discussion of that format.

10. Changes introduced self-signed certificates in the security
considerations section.

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

Campbell, et al. Expires December 29, 2003 [Page 51]

Internet-Draft SIMPLE IM Sessions June 2003

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.

Campbell, et al. Expires November 20, 2003 [Page 42]

Internet-Draft SIMPLE IM Sessions May 2003

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. Changes introduced in

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

12. Contributors

The following people contributed substantially to this ongoing
effort:

Rohan Mahy
Allison Mankin
Jon Peterson
Brian Rosen
Dean Willis
Adam Roach
Cullen Jennings

Campbell, et al. Expires December 29, 2003 [Page 52]

Internet-Draft SIMPLE IM Sessions June 2003

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 /

Campbell, et al. Expires November 20, 2003 [Page 43]

Internet-Draft SIMPLE IM Sessions May 2003
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] Housley, R., "Cryptographic Ramsdell, B., "S/MIME Version 3 Message Syntax (CMS)", Specification", RFC 3369,
August 2002.
2633, June 1999.

[8] Rivest, R., "The MD5 Message-Digest Algorithm", Chown, P., ""Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 1321, April
1992. 3268, June 2002.

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

Informational References

[9]

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

[10]

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

[11]

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

[12]

[13] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo,
"Best Current Practices for Third Party Call Control in the

Campbell, et al. Expires December 29, 2003 [Page 53]

Internet-Draft SIMPLE IM Sessions June 2003

Session Initiation Protocol", draft-ietf-sipping-3pcc-03 (work
in progress), March 2003.

[13]

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

[14]

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

[15]

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

Campbell, et al. Expires November 20, 2003 [Page 44]

Internet-Draft SIMPLE IM Sessions May 2003

[16]

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

[17]

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

[18]

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

Authors' Addresses

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

EMail: bcampbell@dynamicsoft.com

Jonathan Rosenberg
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ 07054

EMail: jdrosen@dynamicsoft.com

Campbell, et al. Expires December 29, 2003 [Page 54]

Internet-Draft SIMPLE IM Sessions June 2003

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 November 20, December 29, 2003 [Page 45] 55]

Internet-Draft SIMPLE IM Sessions May June 2003

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 November 20, December 29, 2003 [Page 46] 56]

Internet-Draft SIMPLE IM Sessions May June 2003

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

Acknowledgement

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

Campbell, et al. Expires November 20, December 29, 2003 [Page 47] 57]

----