WDIFF

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

SIMPLE Working Group B. Campbell
Internet-Draft J. Rosenberg
Expires: July 27, September 29, 2004 R. Sparks
dynamicsoft
P. Kyzivat
Cisco Systems
January 27,
March 31, 2004

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

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 July 27, September 29, 2004.

Abstract

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

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

Internet-Draft MSRP January March 2004

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation for Session-mode Messaging . . . . . . . . . . 4
3. Scope of this Document . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6
5. Architectural Considerations . . . . . . . . . . . . . . . 7
5.1 Transferring Large Content . . . . . . . . . . . . . . . . 7
6. SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . 7
6.1 Use of the SDP M-line . . . . . . . . . . . . . . . . . . 8
6.2 The Direction Accept Types Attribute . . . . . . . . . . . . . . . . . 8
6.3 The Accept Types Attribute . . . . MIME Wrappers . . . . . . . . . . . . 10
6.4 MIME Wrappers . . . . . . . . . . 9
6.4 URL Negotiations . . . . . . . . . . . . 10
6.5 URL Negotiations . . . . . . . . . 10
6.5 Path Attributes with Multiple URLs . . . . . . . . . . . . 11
6.6 Updated SDP Offers . . . . . . . . . . . . . . . . . . . . 12 11
6.7 Example SDP Exchange . . . . . . . . . . . . . . . . . . . 12
6.8 Connection Negotiation . . . . . . . . . . . . . . . . . . 12
6.9 Negotiation of Delivery Status Notifications . . . . . . . 13
7. The Message Session Relay Protocol . . . . . . . . . . . . 13
7.1 MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . 14 13
7.1.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 14
7.1.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 15 14
7.1.3 The msrps URL Scheme . . . . . . . . . . . . . . . . . . . 16 15
7.2 Connection Managment . . . . . . . . . . . . . . . . . . . 15
7.3 MSRP messages . . . . . . . . . . . . . . . . . . . . . . 16
7.3 15
7.4 MSRP Transactions . . . . . . . . . . . . . . . . . . . . 17
7.4 16
7.5 MSRP Sessions . . . . . . . . . . . . . . . . . . . . . . 17
7.4.1
7.5.1 Initiating an MSRP session . . . . . . . . . . . . . . . . 17
7.4.2
7.5.2 Handling VISIT requests . . . . . . . . . . . . . . . . . 21
7.4.3 19
7.5.3 Sending Instant Messages on a Session . . . . . . . . . . 21
7.4.4 19
7.5.4 Ending a Session . . . . . . . . . . . . . . . . . . . . . 22
7.4.5 20
7.5.5 Managing Session State and Connections . . . . . . . . . . 23
7.5 21
7.6 Delivery Status Notifications . . . . . . . . . . . . . . 22
7.7 Method Descriptions . . . . . . . . . . . . . . . . . . . 24
7.5.1 22
7.7.1 SEND . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.5.2 22
7.7.2 VISIT . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.6 22
7.8 Response Code Descriptions . . . . . . . . . . . . . . . . 24
7.6.1 22
7.8.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.6.2 23
7.8.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.6.3 23
7.8.3 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.6.4 23
7.8.4 426 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.6.5 23
7.8.5 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.6.6 23
7.8.6 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.7 23
7.9 Header Field Descriptions . . . . . . . . . . . . . . . . 25
7.7.1 23
7.9.1 TR-ID . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.7.2 Content-Type 23
7.9.2 To . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.7.3 S-URL . . . 23
7.9.3 From . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.9.4 Content-Type . . . . . . . . . . . . . . . . . 26 . . . . . . 24

Campbell, et al. Expires September 29, 2004 [Page 2]

Internet-Draft MSRP March 2004

8. Example . . . . . . . . . . . . . . . . . . . . . . . . . 26 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . 28 27
9.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 28 27
9.2 MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . . 28 27
9.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 28

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

Internet-Draft MSRP January 2004 27
9.2.2 Character Encoding . . . . . . . . . . . . . . . . . . . . 28 27
9.2.3 Intended Usage . . . . . . . . . . . . . . . . . . . . . . 28 27
9.2.4 Protocols . . . . . . . . . . . . . . . . . . . . . . . . 28 27
9.2.5 Security Considerations . . . . . . . . . . . . . . . . . 29 27
9.2.6 Relevant Publications . . . . . . . . . . . . . . . . . . 29 27
9.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 29 28
9.3.1 Direction . Accept Types . . . . . . . . . . . . . . . . . . . . . . . 29 28
9.3.2 Accept Wrapped Types . . . . . . . . . . . . . . . . . . . . . . . 29 28
9.3.3 Wrapped Types Path . . . . . . . . . . . . . . . . . . . . . . 29 . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . 29 28
10.1 TLS and the MSRPS Scheme . . . . . . . . . . . . . . . . . 30 28
10.1.1 Sensitivity of the Session URL . . . . . . . . . . . . . . 30 29
10.1.2 End to End Protection of IMs . . . . . . . . . . . . . . . 31 30
10.1.3 CPIM compatibility . . . . . . . . . . . . . . . . . . . . 31 30
10.1.4 PKI Considerations . . . . . . . . . . . . . . . . . . . . 32 31
11. Changes from Previous Draft Versions . . . . . . . . . . . 32 31
11.1 draft-ietf-simple-message-sessions-04 . . . . . . . . . . 31
11.2 draft-ietf-simple-message-sessions-03 . . . . . . . . . . 32
11.2
11.3 draft-ietf-simple-message-sessions-02 . . . . . . . . . . 33
11.3 32
11.4 draft-ietf-simple-message-sessions-01 . . . . . . . . . . 33
11.4 32
11.5 draft-ietf-simple-message-sessions-00 . . . . . . . . . . 34
11.5 33
11.6 draft-campbell-simple-im-sessions-01 . . . . . . . . . . . 34 33
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . 34
Normative References . . . . . . . . . . . . . . . . . . . 35 34
Informational References . . . . . . . . . . . . . . . . . 35 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 36 35
Intellectual Property and Copyright Statements . . . . . . 38 37

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

Internet-Draft MSRP January March 2004

1. Introduction

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

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

One of the primary purposes of SIP and SDP (Section 6) is the
management of media sessions. Session-mode messaging can be thought
of as a media session like any other. This document describes the
motivations for session-mode messaging, the Message Session Relay
Protocol, and the use of the SDP offer/answer mechanism for managing
MSRP session.

2. Motivation for Session-mode Messaging

Message sessions offer several advantages over page-mode messages.
For message exchanges that include more than a small number of
message transactions, message sessions offer a way to remove
messaging load from intervening SIP proxies. For example, a minimal
session setup and tear-down requires one INVITE/ACK transaction, and
one BYE transaction, for a total of 5 SIP messages. Normal SIP
request routing allows for all but the initial INVITE transaction to
bypass any intervening proxies that do not specifically request to be
in the path for future requests. Session-mode messages never cross
the SIP proxies themselves.

Each page-mode message involves a complete SIP transaction, that is,
a request and a response. Any page-mode message exchange that
involves more than 2 MESSAGE requests will generate more SIP requests
than a minimal session initiation sequence. Since MESSAGE is normally
used outside of a SIP dialog, these requests will typically traverse
the entire proxy network between the endpoints.

Due to network congestion concerns, the MESSAGE method has

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

Internet-Draft MSRP January March 2004

significant limitations in message size, a prohibition against
overlapping requests, etc. Much of this has been required because of
perceived limitations in the congestion-avoidance features of SIP
itself. Work is in progress to mitigate these concerns.

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

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

Finally, SIP devices can treat message sessions like any other media
sessions. Any SIP feature that can be applied to other sorts of media
sessions can equally apply to message sessions. For example,
conferencing [12], third party call control [13], call transfer [14],
QoS integration [15], and privacy [16] can all be applied to message
sessions.

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

3. Scope of this Document

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

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

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

Internet-Draft MSRP January March 2004

4. Protocol Overview

The Message Session Relay Protocol (MSRP) provides a mechanism for
transporting session-mode messages between endpoints. MSRP uses
connection oriented, reliable network transport protocols only. It
can operate in the presence of many NAT and firewall environments, as
it allows participants to positively associate message sessions with
specific connections, and does not depend upon connection source
address, which may be obscured by NATs.

MSRP uses the following primitives:

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

VISIT: Used by an endpoint to establish a session association to the
host endpoint.

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. URL. This URL is temporary, and must not
duplicate the any URL used that A has offered 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 invitation with a URL
of its own. This informs A that B has accepted the session. session, and will
accept messages at that URL. A and B may now exchange messages using
SEND requests on the connection. Each party targets such requests to
the peer's URL.

When either party wishes to end the session, it informs its peer with
using the appropriate mechanism of the chosen signaling protocol,
such as 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) (msrp://A/123, msrp://B/456)
A->B (MSRP): 200 OK
B->A (SDP): answer(msrp://A/123) answer(msrp://B/456)
A->B (MSRP): SEND (msrp://B/456)
B->A (MSRP): 200 OK
B->A (MSRP): SEND

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

Internet-Draft MSRP January March 2004

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

5. Architectural Considerations

There are a number of considerations that, if handled in a reasonable
fashion, will allow more effective use of the protocols described in
this document.

5.1 Transferring Large Content

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

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

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

These issues can be mitigated greatly if the endpoint simply
establishes a separate session for the transfer. This allows the
transfer to be sent without interfering with any instant messages
being sent on other sessions. Further, the endpoint can abort the
transfer by simply tearing down the transfer session. Therefore, if a
peer wishes to send very large content, it SHOULD establish a
dedicated session for that purpose. It should also indicate that the
dedicated session is send only, so that the receiving endpoint does
not attempt to send content back along the same session.

6. SDP Offer-Answer Exchanges for MSRP Sessions

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

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

Internet-Draft MSRP January March 2004

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

supporting it.

6.1 Use of the SDP M-line

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

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

For non-RTP media sessions, The media field specifies the top level
MIME media type for the session. For MSRP sessions, the media field
MUST have the value of "message". The port field is normally not
used, and MAY be set to any value chosen by the endpoint. A port
field value of zero has the standard SDP meaning. Non-zero values
MUST not be repeated in other MSRP m-lines in the same SDP document.

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

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

The port field in the M-line is not used to determine the port to
which to connect. Rather, the actual port is determined by the
contents of the session
MSRP URL (Section 7.1). 7.1) in the path attribute. However, a port value
of zero has the normal SDP meaning.

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

m=message 9999 msrp/tcp *

6.2 The Direction Accept Types Attribute

Since

MSRP uses connection oriented transport protocols, one goal of
the SDP negotiation is can carry any MIME encoded payload. Endpoints specify MIME
content types that they are willing to determine which participant initiates receive in the
transport connection. The direction accept types
"a"-line attribute. This attribute advertises whether the
offerer or answerer wishes to initiate the connection, wishes the
peer endpoint to initiate has the connection, or doesn't care. following syntax:

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

Internet-Draft MSRP January March 2004

The endpoint that accepts the connection is said to "host" the
session, and is known as the hosting endpoint. The endpoint that
initiates the connection is said to "visit" the session, and is known
as the visiting endpoint.

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

direction

accept-types = direction-label accept-types-label ":" role
direction-label = "direction"
role = active / passive / both
active format-list
accept-types-label = "active" sp count
passive "accept-types"
format-list = "passive" sp count
both format-entry *( SP
format-entry) format-entry = "both" sp count [sp timeout]
count (type "/" subtype) / ("*")
type = 1*DIGIT ; Connection count
timeout token
subtype = 1*DIGIT ; timeout value in seconds

The values token

SDP offers for MSRP sessions MUST include an accept-types attribute.
SDP answers MUST also include the role field are as follows:

passive: The endpoint wishes to host the session

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

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

The SDP offer for an MSRP session MUST contain or a direction attribute,
which MAY take any subset of that list.

A "*" entry in the defined values. accept-types attribute indicates that the sender
may attempt to send messages with media types that have not been
explicitly listed. If the offerer receiver is capable
of hosting able to process the session, then it SHOULD select "both". The endpoint
SHOULD NOT select "active" unless media type,
it cannot host the session under
any circumstances. The endpoint SHOULD NOT select "passive" unless does so. If not, it
has no option but to host the session.

The count is used to determine if will respond with a new connection 415. Note that all
explicit entries SHOULD be considered preferred over any non-listed
types. This feature is required in
future SDP exchanges for a given stream. For needed as, otherwise, the initial SDP
exchange, the count pamameter MUST be set to zero. Endpoints sending
a new offer related to an existing stream MUST increment this count
from the value in the most recent successful exchange list of formats for the stream.
rich IM devices may be prohibitively large.

The SDP answer also MUST accept-types attribute may include container types, that is, mime
formats that contain a direction attribute, but its value
choices other types internally. If compound types are limited based on
used, the value types listed in the offer. If the offer
contained "active", then accept-types attribute may be used both
as the answerer MUST either select "passive" root payload, or
reject the offer. Likewise, if the offer contained "passive", then may be wrapped in a listed container type.
(Note that the answerer container type MUST select "active" or reject the offer. If the offer

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

Internet-Draft MSRP January 2004

contained "both", the answerer SHOULD select "active", but MAY select
"passive" if it is unable to reach also be listed in the host device, or if local
policy requires it to act as host. accept-types
attribute.)

6.3 MIME Wrappers

The answerer MUST set MIME content-types in the count
parameter accept-types attribute will often
include container types; that is, types that contain other types. For
example, "message/cpim" or "multipart/mixed." Occasionally an
endpoint will need to the same value as specify a MIME body type that in the offer.

6.3 The Accept Types Attribute

MSRP can carry any MIME encoded payload. only be used
if wrapped inside a listed container type.

Endpoints MAY specify MIME
content types that they are willing only allowed to receive in the accept be wrapped
inside compound types
"a"-line attribute. using the "accept-wrapped-types" attribute in
an SDP a-line. This attribute has the following syntax:

accept-types

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

The format-list = format-entry *( SP format-entry)
format-entry = (type "/" subtype) / ("*")
type = token
subtype = token

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

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

The accept-types attribute may include container types, that is, mime
formats that contain other types internally. If compound types are
used, the used when wrapped inside
containers. Only types listed in the accept-types attribute may be used both as the root payload, or may be wrapped in a listed container type.
(Note that
"root" type for the container entire body. Since any type MUST also be listed in the accept-types
attribute.)

6.4 MIME Wrappers

The MIME content-types in the
accept-types attribute will often
include container types; that is, types that contain other types. For
example, "message/cpim" or "multipart/mixed." Occasionally an
endpoint will need to specify a MIME body type that can only may be used
if wrapped inside both as a listed container type.

Endpoints MAY specify MIME types that are only allowed to be root body, and wrapped
inside compound types using the "accept-wrapped-types" attribute in
an SDP a-line. This attribute has the following syntax: other

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

Internet-Draft MSRP January March 2004

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

The format-list element has the identical syntax as defined for the
accept-types attribute. The semantics for this attribute are
identical to those of the accept-types attribute, with the exception
that the specified types may only be used when wrapped inside
containers. Only types listed in accept-types may be used as the
"root" type for the entire body. Since any type listed in
accept-types may be used both as a root body, and wrapped in other

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

This approach does not allow for specifying distinct lists of
acceptable wrapped types for different types of containers. If an
endpoint understands a MIME type in the context of one wrapper, it is
assumed to understand it in the context of any other acceptable
wrappers, subject to any constraints defined by the wrapper types
themselves.

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

6.5

6.4 URL Negotiations

Each endpoint in an MSRP session is identified by an MSRP URL, which is determined by
the hosting endpoint, and a URL. These URLs
are negotiated in the SDP exchange. Any Each SDP offer or answer that creates a possibility that the sender will host
the session, that is, it contains a direction value of "passive" or
"both", MUST
contain an one or more MSRP URL in a session path attribute. This attribute has
the following syntax:

a=session:<MSRP_URL>

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

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

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

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

Internet-Draft MSRP January 2004

The following example shows an SDP offer with

Both offerer and answerer store the path values received from the
peer. For a session given endpoint, the local URL of
"msrp://example.com:7394/2s93i"

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

The session is the URL MUST be that the
endpoint put into a temporary URL assigned just for this
particular session. It path attribute value to send to its peer. The
remote URL is the URL received from the peer. If the path attribute
received from the peer contains more than one URL, then the remote
URL is the first one. The remote path is the entire path attribute
value received from the peer.

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

Campbell, et al. Expires September 29, 2004 [Page 10]

Internet-Draft MSRP March 2004

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

The first URI in the path attribute MUST identify the endpoint that
generated the SDP document, or some other location where that
endpoint wishes to receive messages associated with the session. If
the URL identifies the endpoint, it MUST MUST be a temporary URL
assigned just for this particular session, and MUST NOT duplicate any
URL in use for any other session hosted by the endpoint. Further, since in which the peer endpoint will use the session URL to identify itself when connecting, is currently
participating. Further, it SHOULD be hard to guess, and protected
from eavesdroppers. This will be discussed in more detail in Section
10.

6.6 Updated SDP Offers

6.5 Path Attributes with Multiple URLs

As mentioned previously, this document describes MSRP endpoints may sometimes need to send additional SDP exchanges for an existing session. For example, they may need to negotiate a
new connection because of a TCP failure or some other reason. They
may need to send periodic exchanges with
peer-to-peer scenarios, that is, when no change relays are used. However, we
expect a separate document to refresh state describe the use of relays in the network, for example, SIP timers. They may need to change some
other stream near
future. The path attribute supports lists of URLs in order to
facilitate that work. For peer-to-peer session, a session path attribute will
contain exactly one URL, describing an endpoint. This means that
endpoints that only implement this specification will never send more
than one URL in a path attribute, but MUST be prepared to receive
more than one. When an endpoint receives more than one URL in a path
header, only the first entry is relevant for purposes of resolving
the address and port, and establishing the network connection.

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

6.6 Updated SDP Offers

To do: Revisit this section based on new connection management rules

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

Once

Campbell, et al. Expires September 29, 2004 [Page 11]

Internet-Draft MSRP endpoints have completed an intitial negotiation, further
exchanges do not change their roles as the active or passive March 2004

If either party
for that particular stream. This means that if the visitor sends a
new wish to send an SDP offer, document that changes nothing at
all, then it MUST remain have the visitor, i.e. it MUST offer same o-line version as in the previous
exchange.

6.7 Example SDP Exchange

Endpoint A wishes to invite Endpoint B to a
direction of "active" and it MUST NOT include an MSRP URL. Likewise,
if the host sends a new offer, it MUST include a direction of
"passive" and it MUST include a URL. Updated offers MUST NOT include
a direction of "both."

If offering party wishes to establish a new connection as a result of
the updated exchange, it MUST increment the count parameter in the
direction attribute from that of the most recent successful exchange.
If the passive endpoint wishes the the visitor to re-connect, it the
included URL MUST be different than the URL from previous offers.
This new URL MAY be completely different from the original and MAY
even resolve to a different location. If the active party sends a new
offer with an incremented count parameter, the passive party MUST
supply a new URL, or reject the offer. If either party sends a new

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

Internet-Draft MSRP January 2004

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

If this negotiation results in a new session URL, the active party
MUST close the existing connection, open a new connection, and send a
VISIT request as described below.

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

6.7 Example SDP Exchange

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

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

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

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

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

6.8 Connection Negotiation

Previous versions of this document included a mechanism to negotiate
the VISIT request.

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

The SIMPLE working group chose to remove that mechanism from MSRP for
a number of reasons:

It added a great deal of complexity to session creation.
The work in MSRP had begun to diverge from the work in MMUSIC.

Campbell, et al. Expires September 29, 2004 [Page 12]

Internet-Draft MSRP March 2004

There was a lack of successful implementation experience of the
COMEDIA work.

6.9 Negotiation of Delivery Status Notifications

To Do.

7. The Message Session Relay Protocol

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

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

Internet-Draft MSRP January 2004

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

7.1 MSRP URLs

MSRP sessions are identified by MSRP URLs.

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

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

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

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

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

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

Campbell, et al. Expires September 29, 2004 [Page 13]

Internet-Draft MSRP March 2004

Escaping MUST NOT be used in an MSRP URL. Furthermore, a userinfo
part MUST NOT contain password information.

The following is an example of a typical MSRP URL:

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

7.1.1 MSRP URL Comparison

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

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

Internet-Draft MSRP January 2004

1. The host part is compared as case insensitive.

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

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

4. Userinfo parts are not considered for URL comparison.

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

7.1.2 Resolving MSRP Host Device

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

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

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

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

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

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

Campbell, et al. Expires September 29, 2004 [Page 14]

Internet-Draft MSRP March 2004

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

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

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

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

Internet-Draft MSRP January 2004
fail, the device SHOULD attempt to use any additional SRV records
that may have been returned, following the normal rules for SRV
record selection.

In most cases, the transport protocol will be determined separately
from the resolution process. For example, if the MSRP URL was
communicated in an SDP offer or answer, the SDP M-line will contain
the transport protocol. When an MSRP URL is communicated outside of
SDP, the protocol SHOULD also be communicated. If a device needs to
resolve an MSRP URL and does not know the protocol, it SHOULD assume
TCP.

7.1.3 The msrps URL Scheme

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

7.2 Connection Managment

When an MSRP messages

MSRP messages are either requests or responses. Requests endpoint receives an SDP offer, and
responses are distinguished from one another intends to accept
it, it MUST establish a connection device described by the first line. The
first line of remote
URL, if one does not already exist. If it already has a Request takes the form of connection
associated with another session for which the request-start entry
below. Likewise, peer URL host part
matches the first line host part of a response takes the form of
response-start. The syntax remote URL, it SHOULD use the that
connection, instead. Once connected, the answerer MUST send a VISIT
request to associate the new session with the connection, prior to
sending the SDP answer.

Either endpoint MAY tear down a connection when it no longer has any
active or proposed sessions associated with the connection.

7.3 MSRP messages

MSRP messages are either requests or responses. Requests and

Campbell, et al. Expires September 29, 2004 [Page 15]

Internet-Draft MSRP March 2004

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

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

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

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

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

Internet-Draft MSRP January 2004
Content-Type = "Content-Type" ":" quoted-string
Session-URL
To = "To" ":" msrp_url *(SP msrp_url)
From = "S-URL" "From" ":" msrp_url

All requests and responses MUST contain at least a TR-ID header
field. All requests must also contain the To and From header fields.
Messages MAY contain other fields, depending on the method or
response code.

7.3

7.4 MSRP Transactions

An MSRP transaction consists of exactly one request and one response.
A response matches a transaction if it share the same TR-ID value,
and arrives on the same connection on which the transaction was sent.

Endpoints MUST select TR-ID header field 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 TR-ID header field beyond what is stated
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
timeout interval SHOULD be 30 seconds, but other values may be
established as a matter of local policy.

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 a visitor). A session is identified by an MSRP URL.

7.4.1 Initiating an 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 the answerer.

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

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

Internet-Draft MSRP January 2004

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

1. Construct a session MSRP URL . This URL MUST resolve to the
location that the offerer wishes to host the connection. The URL
SHOULD be temporary, SHOULD be hard to guess, and MUST not
duplicate the URL of any other session currently hosted by the
offerer.

2. Listen for a connection from the peer.

3. Construct an SDP offer as described in Section 6, including the
list of allowed IM payload formats in the accept-types attribute.
The offerer maps the session URL to the session attribute, as
described in Section 6.5.

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. The direction attribute must
also contain the count parameter, which will be set to zero for
an initial exchange.

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

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

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

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

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

When the answerer receives the SDP offer and chooses to participate
in the session, it must choose whether to act as the host or the
visitor. A direction attribute value of "both" in the offer indicates
that the offerer prefers to host, but will allow the answerer to
host. In this case the answerer SHOULD act as the visitor, but MAY
choose to host. A value of "passive" means the offerer insists upon

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

Internet-Draft MSRP January 2004

hosting, in which case the answerer MUST act as visitor or decline
the offer.

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

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

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

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

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

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

3. 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, 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 the accept-types attribute
contains the SEND payload media types that the answerer is
willing to accept. The accept-types attribute in the answer
MUST be either the same as that of the offer, or it MUST be a
subset.

3. A direction attribute containing the value "active", and the
count value copied from the offer.

6. If the transaction fails, the answerer MAY choose to act as host,
if allowed not repeated by the direction attribute same endpoint in scope of the answer. If the
answerer given
session. TR-ID values SHOULD be globally unique. The TR-ID space of
each endpoint is unable or unwilling to host, then it should return an
error response as appropriate for the signaling protocol.

Some TCP connection failure conditions may ordinarily take some time
to notice. For example, if independent of that of its peer. Endpoints MUST NOT
infer any semantics from the offerer TR-ID header field beyond what is unable to open a TCP
connection to the host device, this connection attempt may take a
fairly large number of seconds stated
above. In particular, TR-ID values are not required to timeout. This length of time will follow any
sequence.

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

Internet-Draft MSRP January March 2004

not be acceptable for many call flow scenarios. Therefore, the
devices SHOULD limit

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 time same way they wait for the TCP connection to would treat a
shorter 500 response. The
timeout value, interval SHOULD be 30 seconds, but other values may be
established as a matter of local policy.

7.5 MSRP Sessions

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

7.5.1 Initiating an MSRP session

When an endpoint wishes to 30 seconds. However, the
offerer MAY supply engage a different time peer in a message session, it
invites the timeout parameter of peer to communicate using an SDP offer, carried over SIP
or some other protocol supporting the SDP offer/answer model. For the
"both" direction value. If
purpose of this document, we will refer to the offerer supplies a value, endpoint choosing to
initiate communication as the answerer
SHOULD use that value for offerer, and the TCP connection timeout, interpreted peer being invited as
an integer number of seconds.

If
the answerer chooses answerer.

The offerer MUST be prepared to host accept a connection from the session, it
answerer.

The offerer MUST perform the following steps:

1. Construct a new session MSRP URL . to serve as the local URL. This MUST be a MSRP or MSRPS URL, URL MUST
resolve to the answerer, and MUST not be the same as the
session URL in location that the offer. The URL SHOULD be temporary, SHOULD be
hard offerer wishes to guess, and MUST not duplicate URLs currently identifying
any active sessions hosted by host the answerer.
connection.

2. Listen for a connection from the peer.

3. Construct an SDP answer offer as described in Section 6, mapping including the
list of allowed IM payload formats in the accept-types attribute.
The offerer puts its local URL into the path attribute, as
described in Section 6.4. This URL becomes the offerer's local
path.

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

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

1. Parse the first URL from the offered path attribute. We will
refer to this URL as the remote URL. The full path attribute
value will be the answerer's remote path. If the path only
contained a single URL entry, then the remote URL and the remote

Campbell, et al. Expires September 29, 2004 [Page 17]

Internet-Draft MSRP March 2004

path are identical.

2. Determine if it has any existing connection that is associated
with a peer URL host part that matches that of the remote URL,
and with a transport protocol matching that from the M-line. If
one exists, the answerer SHOULD use it for the new session URL rather
than establishing a new connection.

[Open Issue: Should we discuss situations when an endpoint may
want to the session attribute, insert intentially not share a direction
attribute with connection?]

3. If no appropriate connection already exists, determine the value of "passive", host
address and the count value copied port from the offer.

4. Send remote URL, following the SDP offer procedures in
section Section 7.1, and connect using the normal processing for the signaling
protocol.

When the offerer receives transport protocol
from the SDP answer, it must determine who will
continue M-line.

4. Construct a MSRP URL . This URL MUST resolve to host the session. If the answer contained a direction
attribute value of "active", answerer.
This URL becomes the offerer answerer's local URL.

5. Construct a VISIT request, which MUST continue as host. If contain the offer contained "active" or "both" and following
information:

1. An To header field containing the answer contains
"passive", then remote URL.

2. A From containing the offerer MUST allow answerer's local URL.

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

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

6. Send the request and wait for a response

7. If the offerer chooses not VISIT transaction succeeds, send a SDP answer via the
signaling protocol, according to continue as host, it MUST perform the following steps: rules:

1. Release resources it acquired in expectation of hosting The C-line is copied unmodified from the
session, if any. offer.

2. Determine the host address and The M-Line contains a dummy port value, the protocol field
from the session URL of original offer.

3. The accept-types attribute contains the
answer, following SEND payload media
types that the procedures in section Section 7.1

3. Connect answerer is willing to accept. The
accept-types attribute in the host address and port, using the transport
protocol from answer MUST be either the M-line.

4. Construct a VISIT request, which same
as that of the offer, or it MUST contain be a subset.

4. The path attribute contains the following
information: answerer's local URL.

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

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

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

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

5. Send the request and wait for a response

6. 18]

Internet-Draft MSRP March 2004

8. If either the connection attempt or the VISIT transaction fail,
acknowledge the answer, then initiate the tear-down of fails, the
session using answerer MUST reject the signaling protocol.

7.4.2
offer.

7.5.2 Handling VISIT requests

An MSRP endpoint that is hosting a session will receive a VISIT
request from the visiting endpoint. When an endpoint receives a VISIT
request, it MUST perform the following procedures:

1. Check if state exists for a session with a local URL that matches
the
S-URL To header field value of the VISIT request. If so, and if no visitor connection
previous VISIT request has been associated with the session, received for that URL, then
return a 200 response, and save state designating associating the URL in the
From header field with the connection on which the request was
received as the visitor leg of the session. .

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

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

7.4.3

7.5.3 Sending Instant Messages on a Session

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

1. Insert a To header field containing the remote path. Note that
this is the full remote path, not just the remote URL.

2. Insert a From header field containing the local URL.

3. Insert the message payload in the body, and the media type in the
Content-Type header field. The media type MUST match one of the
types in the format list negotiated in the SDP exchange. If a "*"
was present in the accept-types attribute, then the media type
SHOULD match one of the explicitly listed entries, but MAY be any
other arbitrary value.

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

5. Send the request on the connection associated with the session.

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

Internet-Draft MSRP January 2004

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

Campbell, et al. Expires September 29, 2004 [Page 19]

7. If a 415 response is received, this indicates the recipient is
unable or unwilling to process the media type. The sender SHOULD
NOT attempt to send that particular media type again in the
context of this session.

8. If any other response code is received, or if the transaction
times out, the endpoint SHOULD assume the session has failed, and
initiate tear-down,
either ending tear down the session, or attempt to re-establish the
session by sending an updated SDP offer proposing a new
connection. If a new connection is established, the endpoint MAY
choose to resend the content on the new connection.

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

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

1. Check that it has state for a session with a local URL matching
the To value. If no matching session exists, return a 481
response.
2. Determine that it understands the media type in the body, if any
exists.

3. If it does, return a 200 response and render the message to the
user. The method of rendering is a matter of local policy. If the
message contained no body at all, the endpoint should quietly
ingore it.

4. If it does not understand the media type, return a 415 response.
The endpoint MUST NOT return a 415 response for any media type
for which it indicated support in the SDP exchange.

7.4.4

7.5.4 Ending a Session

When either endpoint in an MSRP session wishes to end the session, it
first signals its intent using the normal processing for the
signaling protocol. For example, in SIP, it would send a BYE request
to the peer. After agreeing to end the session, the host endpoint
MUST release any resources acquired as part of the session.

The host

Each peer MUST destroy all local state for the session. This involves
completely removing the state entry for this the session and invalidating
the session URL.

If no other sessions are using the connection, the endpoint that

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

Internet-Draft MSRP January March 2004

Since these host actions completely destroy the session state at
the hosting device,

opened it SHOULD tear it down. However, the visitor is not required to take further
action beyond cleaning up any local state. passive party MAY tear
down an unused connection after a locally configured timeout period.

When an endpoint chooses to close a session, it may have SEND
transactions outstanding. For example, it may have send SEND requests
to which it has not yet received a response, or it may have received
SEND requests that to which it has not responded. Once an endpoint
has decided to close the connection, it SHOULD wait for such
outstanding transactions to complete. It SHOULD NOT generate any new
SEND transactions, and it MAY choose not to respond to any new SEND
requests that are received after it decides to close the session. It
SHOULD not respond to any new messages that arrive after it signals
its intent to close the session.

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

It is not possible to completely eliminate the chance of a session
terminating with incomplete SEND transactions. When this occurs, the
endpoint SHOULD clearly inform the user that the messages may not
have been delivered.

7.4.5

7.5.5 Managing Session State and Connections

A MSRP session is represented by state at the host device. As mention
previously, session state is each endpoint, identified
by an MSRP URL. the local URL and remote path. An active session also has an
associated network connection.

When session state is destroyed for any reason, the hosting device
SHOULD drop the connection.

If the connection fails for any reason, the session hosting device
MUST invalidate the session state. state for all sessions using the
connection. Once a connection is dropped, the any associated session
state MUST NOT be reused. If an endpoint wishes to continue to
communicate after detecting a connection failure, it MAY initiate a
new SDP exchange to negotiate a new session URL. Otherwise, it SHOULD
attempt to tear down the session using the rules of the signaling
protocol.

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

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

Internet-Draft MSRP January 2004
tries to recover the session. If the endpoint attempts to
reconnect prior to the hosting device noticing the failure, the
hosting device will interpret the recovery attempt as a conflict.

Campbell, et al. Expires September 29, 2004 [Page 21]

Internet-Draft MSRP March 2004

The only way around this would be to force the hosting device to
do a liveness check on the original connection, which would create
a lot of complexity and overhead that do not seem to be worth the
trouble.

7.5

Open Issue: Is this still an issue with shared connections?

7.6 Delivery Status Notifications

To Do.

7.7 Method Descriptions

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

7.5.1

7.7.1 SEND

The SEND method is used by both the host and visitor endpoints to
send instant messages to its peer endpoint. A SEND request MUST
contain a To header field containing the sender's remote path, and a
From header field containing the sender's local URL. SEND requests
SHOULD contain a MIME body part. The body MUST be of a media type
included in the format list negotiated in the SDP exchange. If a body
is present, the request MUST contain a Content-Type header field
identifying the media type of the body.

To Do: We plan to expand the use of MIME headers to allow any
standard MIME header in a SEND request. This is not included in
this version for the sake of getting the draft out as soon as
possible, but will follow soon.

7.5.2

7.7.2 VISIT

The visiting endpoint uses the VISIT method to associate a network
connection with the session state at the hosting device. The A VISIT
request MUST contain include a S-URL To header matching including the session sender's remote URL,
and a From header field containing the sender's local URL.

7.6

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 original request, and To and From headers

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

Internet-Draft MSRP March 2004

matching those of the original request.

7.6.1

7.8.1 200

The 200 response code indicates a successful transaction.

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

Internet-Draft MSRP January 2004

7.6.2

7.8.2 400

A 400 response indicates a request was unintelligible.

7.6.3

7.8.3 415

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

7.6.4

7.8.4 426

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

7.6.5

7.8.5 481

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

7.6.6

7.8.6 506

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

7.7

7.9 Header Field Descriptions

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

7.7.1

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 elements MUST NOT assume any additional semantics for TR-ID.

7.9.2 To

The To header field is used to indicate the sender's remote path. All

Campbell, et al. Expires September 29, 2004 [Page 23]

Internet-Draft MSRP March 2004

MSRP requests MUST contain a To header field.

7.9.3 From

The From header field is used to indicate the sender's local URL. All
MSRP requests MUST NOT assume any additional semantics for TR-ID.

7.7.2 contain a From header field.

7.9.4 Content-Type

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

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

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

Internet-Draft MSRP January 2004

7.7.3 S-URL

The S-URL header field is used to identify the session. The S-URI
header field must be included in VISIT requests.

8. Example

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

Campbell, et al. Expires September 29, 2004 [Page 24]

Internet-Draft MSRP March 2004

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 local URL of msrp://
alicepc.atlanta.com:7777/iau39 msrp://alicepc.atlanta.com:7777/
iau39 and listens for a connection on TCP port 7777.

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

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

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

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

Bob->Alice (MSRP):

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

Campbell, et al. Expires September 29, 2004 [Page 25]

Internet-Draft MSRP March 2004

From:msrp://bob.atlanta.com:8888/9di4ea
Tr-ID:sie09s

3. Alice->Bob (MSRP):

MSRP xx 200 OK
Tr-ID: sie09s
To:msrp://alicepc.atlanta.com:7777/iau39
From:msrp://bob.atlanta.com:8888/9di4ea
Tr-ID:sie09s

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

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

5. Alice->Bob (SIP): ACK

6. Alice->Bob (MSRP):

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

7. Bob->Alice (MSRP):

MSRP xx 200 OK
To:msrp://bob.atlanta.com:8888/9di4ea
From:msrp://alicepc.atlanta.com:7777/iau39
TR-ID: 123

8. Bob->Alice (MSRP):

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

Internet-Draft MSRP January 2004

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

Hi, Alice! I'm Bob!

Campbell, et al. Expires September 29, 2004 [Page 26]

9. Alice->Bob (MSRP):

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

10. Alice->Bob (SIP): BYE

Alice invalidates local session and drops connection. state.

11. Bob invalidates local state for the session.

Bob->Alice (SIP): 200 OK

9. IANA Considerations

9.1 MSRP Port

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

9.2 MSRP URL Schemes

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

9.2.1 Syntax

See Section 7.1.

9.2.2 Character Encoding

See Section 7.1.

9.2.3 Intended Usage

See Section 7.1.

9.2.4 Protocols

The Message Session Relay Protocol (MSRP).

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

Internet-Draft MSRP January 2004

9.2.5 Security Considerations

See Section 10.

9.2.6 Relevant Publications

RFCXXXX

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

Internet-Draft MSRP March 2004

[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 Accept Types

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

9.3.2 Accept Wrapped Types

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

9.3.3 Wrapped Types Path

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

10. Security Considerations

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

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

Internet-Draft MSRP January 2004

10.1 TLS and the MSRPS Scheme

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

MSRP does not define a separate TCP port for TLS connections. This
means that all MSRP server devices, that is, all devices that listen
for TCP connections, MUST be prepared to handle both TLS and plain
text connections on the same port. When a device accepts a TCP

Campbell, et al. Expires September 29, 2004 [Page 28]

Internet-Draft MSRP March 2004

connection, it MUST watch for the TLS handshake messages to determine
if a particular connection uses TLS. If the first data received is
not part of a start TLS request, the device ceases to watch for the
TLS handshake until it reads the entire message. Once the message has
been completely received, the device resumes watching for the start
TLS message.

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

MSRP devices acting in the role of TCP client MAY perform a TLS
handshake at any time, as long as the request occurs between MSRP
messages. The endpoint MUST NOT send a start TLS request in the
middle of an MSRP message.

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

The MSRPS URI scheme indicates that all hops in an MSRP session MUST
be protected with TLS. Since this document does not specify the use
of intermidiary devices, then MSRPS support is trivially equivilant
to TLS support. However, if intermediaries do exist, either as
described in an MSRP extension document, or as some sort of
proprietary devices, they MUST ensure protection at all hops for an
MSRPS URL.

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

10.1.1 Sensitivity of the Session URL

The URL of sent in the SDP offer for a MSRP session is used by the visiting endpoint
answerer to

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

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

Campbell, et al. Expires September 29, 2004 [Page 29]

Internet-Draft MSRP March 2004

man-in-the-middle attacks.

Therefore an a 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.

10.1.2 End to End Protection of IMs

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

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

10.1.3 CPIM compatibility

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

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

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

Campbell, et al. Expires September 29, 2004 [Page 30]

Internet-Draft MSRP March 2004

10.1.4 PKI Considerations

Several aspects of MSRP will benefit from being used in the context
of a public key infrastructure. For example, the MSRPS scheme allows,
and even encourages, TLS connections between endpoint devices. And
while MSRP allows for a symmetric session key to protect all messages
in a session, it is most likely that session key itself would be
exchanged in a signaling protocol such as SIP. Since that key is
extremely sensitive, its exchange would also need to be protected. In
SIP, the preferred mechanism for this would be S/MIME, which would
also benefit from a PKI.

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

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

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

11. Changes from Previous Draft Versions

This section to be deleted prior to publication as an RFC

11.1 draft-ietf-simple-message-sessions-04

Removed the direction attribute. Rather than using a comedia
styled direction negotiation, we just state that the answerer
opens any needed connection.
Changed the use of session URLs. Instead of a single session URL,
each endpoint is identified by a distinct URL. MSRP requests will
put the destination URL in a To header, and the sender URL in a
From header.
Changed the SDP exchange of MSRP URLs to handle the URL for each
endpoint. Further, changed the SDP attribute to support a list of
URLs in each direction. This may be used with relays to exchange
paths, rather than single URLs. MSRP endpoints must be able to
intelligently process such a list if received. This document does
not, however, describe how to generate such a list.
Added skeleton sections for Delivery Status Notification handling
and negotiation.

Campbell, et al. Expires September 29, 2004 [Page 31]

Internet-Draft MSRP March 2004

11.2 draft-ietf-simple-message-sessions-03

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

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

Internet-Draft MSRP January 2004
Removed text indicating that an endpoint could retry failed
requests on the same connection. Rather, the endpoint should
consider the connection dead, and either signal a reconnection or
end the session.
Added text describing subsequent SDP exchanges. Added mandatory
"count" parameter to the direction attribute to allow explicit
signaling of the need to reconnect.
Added text to describe the use of send and receive only indicators
in SDP for one-way transfer of large content.
Added text requiring unique port field values if multiple M-line's
exist.
Corrected a number of editorial mistakes.

11.2

11.3 draft-ietf-simple-message-sessions-02

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

11.3

11.4 draft-ietf-simple-message-sessions-01

Abstract rewritten.
Added architectural considerations section.
The m-line format list now only describes the root body part for a
request. Contained body part types may be described in the
"accept-wrapped-types" a-line attribute.
Added a standard dummy value for the m-line port field. Clarified
that a zero in this field has normal SDP meaning.

Campbell, et al. Expires September 29, 2004 [Page 32]

Internet-Draft MSRP March 2004

Clarified that an endpoint is globally configured as to whether or
not to use a relay. There is no relay discovery mechanism
intrinsic to MSRP.
Changed digest algorithm to SHA1. Added TR-ID and S-URI to the
hash for digest authentication.
CMS usage replaced with S/MIME.
TLS and MSRPS usage clarified.
Session state timeout is now based on SEND activity, rather than
BIND and VISIT refreshes.

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

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

11.4

11.5 draft-ietf-simple-message-sessions-00

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

11.5

11.6 draft-campbell-simple-im-sessions-01

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

Campbell, et al. Expires September 29, 2004 [Page 33]

Internet-Draft MSRP March 2004

drastically) have now been combined into this single draft.

12. Contributors

The following people contributed substantially to this ongoing
effort:

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

Internet-Draft MSRP January 2004
Rohan Mahy Allison Mankin Jon Peterson Brian Rosen Dean Willis Adam Roach
Cullen Jennings Aki Niemi Hisham Khartabil Pekka Pessi Chris Boulton

Normative References

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

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

[3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
Presence Protocol Requirements", RFC 2779, February 2000.

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

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

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

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

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

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

Informational References

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

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

Internet-Draft MSRP January 2004

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

Campbell, et al. Expires September 29, 2004 [Page 34]

Internet-Draft MSRP March 2004

1889, January 1996.

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

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

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

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

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

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

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

Authors' Addresses

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

EMail: bcampbell@dynamicsoft.com

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

Internet-Draft MSRP January 2004

Jonathan Rosenberg
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ 07054

EMail: jdrosen@dynamicsoft.com

Campbell, et al. Expires September 29, 2004 [Page 35]

Internet-Draft MSRP March 2004

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 July 27, September 29, 2004 [Page 37] 36]

Internet-Draft MSRP January March 2004

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.

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

Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

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

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

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

Internet-Draft MSRP January March 2004

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

Acknowledgment

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

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

----