draft-ietf-simple-message-sessions-03.txt   draft-ietf-simple-message-sessions-04.txt 
SIMPLE Working Group B. Campbell SIMPLE Working Group B. Campbell
Internet-Draft J. Rosenberg Internet-Draft J. Rosenberg
Expires: July 27, 2004 R. Sparks Expires: September 29, 2004 R. Sparks
dynamicsoft dynamicsoft
P. Kyzivat P. Kyzivat
Cisco Systems Cisco Systems
January 27, 2004 March 31, 2004
The Message Session Relay Protocol The Message Session Relay Protocol
draft-ietf-simple-message-sessions-03 draft-ietf-simple-message-sessions-04
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 27, 2004. This Internet-Draft will expire on September 29, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document describes the Message Session Relay Protocol (MSRP), a This document describes the Message Session Relay Protocol (MSRP), a
mechanism for transmitting a series of Instant Messages within a mechanism for transmitting a series of Instant Messages within a
session. MSRP sessions are managed using the Session Description session. MSRP sessions are managed using the Session Description
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation for Session-mode Messaging . . . . . . . . . . 4 2. Motivation for Session-mode Messaging . . . . . . . . . . 4
3. Scope of this Document . . . . . . . . . . . . . . . . . . 5 3. Scope of this Document . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6
5. Architectural Considerations . . . . . . . . . . . . . . . 7 5. Architectural Considerations . . . . . . . . . . . . . . . 7
5.1 Transferring Large Content . . . . . . . . . . . . . . . . 7 5.1 Transferring Large Content . . . . . . . . . . . . . . . . 7
6. SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . 7 6. SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . 7
6.1 Use of the SDP M-line . . . . . . . . . . . . . . . . . . 8 6.1 Use of the SDP M-line . . . . . . . . . . . . . . . . . . 8
6.2 The Direction Attribute . . . . . . . . . . . . . . . . . 8 6.2 The Accept Types Attribute . . . . . . . . . . . . . . . . 8
6.3 The Accept Types Attribute . . . . . . . . . . . . . . . . 10 6.3 MIME Wrappers . . . . . . . . . . . . . . . . . . . . . . 9
6.4 MIME Wrappers . . . . . . . . . . . . . . . . . . . . . . 10 6.4 URL Negotiations . . . . . . . . . . . . . . . . . . . . . 10
6.5 URL Negotiations . . . . . . . . . . . . . . . . . . . . . 11 6.5 Path Attributes with Multiple URLs . . . . . . . . . . . . 11
6.6 Updated SDP Offers . . . . . . . . . . . . . . . . . . . . 12 6.6 Updated SDP Offers . . . . . . . . . . . . . . . . . . . . 11
6.7 Example SDP Exchange . . . . . . . . . . . . . . . . . . . 13 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. The Message Session Relay Protocol . . . . . . . . . . . . 13
7.1 MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1 MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 14 7.1.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 14
7.1.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 15 7.1.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 14
7.1.3 The msrps URL Scheme . . . . . . . . . . . . . . . . . . . 16 7.1.3 The msrps URL Scheme . . . . . . . . . . . . . . . . . . . 15
7.2 MSRP messages . . . . . . . . . . . . . . . . . . . . . . 16 7.2 Connection Managment . . . . . . . . . . . . . . . . . . . 15
7.3 MSRP Transactions . . . . . . . . . . . . . . . . . . . . 17 7.3 MSRP messages . . . . . . . . . . . . . . . . . . . . . . 15
7.4 MSRP Sessions . . . . . . . . . . . . . . . . . . . . . . 17 7.4 MSRP Transactions . . . . . . . . . . . . . . . . . . . . 16
7.4.1 Initiating an MSRP session . . . . . . . . . . . . . . . . 17 7.5 MSRP Sessions . . . . . . . . . . . . . . . . . . . . . . 17
7.4.2 Handling VISIT requests . . . . . . . . . . . . . . . . . 21 7.5.1 Initiating an MSRP session . . . . . . . . . . . . . . . . 17
7.4.3 Sending Instant Messages on a Session . . . . . . . . . . 21 7.5.2 Handling VISIT requests . . . . . . . . . . . . . . . . . 19
7.4.4 Ending a Session . . . . . . . . . . . . . . . . . . . . . 22 7.5.3 Sending Instant Messages on a Session . . . . . . . . . . 19
7.4.5 Managing Session State and Connections . . . . . . . . . . 23 7.5.4 Ending a Session . . . . . . . . . . . . . . . . . . . . . 20
7.5 Method Descriptions . . . . . . . . . . . . . . . . . . . 24 7.5.5 Managing Session State and Connections . . . . . . . . . . 21
7.5.1 SEND . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.6 Delivery Status Notifications . . . . . . . . . . . . . . 22
7.5.2 VISIT . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.7 Method Descriptions . . . . . . . . . . . . . . . . . . . 22
7.6 Response Code Descriptions . . . . . . . . . . . . . . . . 24 7.7.1 SEND . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.6.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.7.2 VISIT . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.6.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.8 Response Code Descriptions . . . . . . . . . . . . . . . . 22
7.6.3 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.8.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.6.4 426 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.8.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.6.5 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.8.3 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.6.6 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.8.4 426 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.7 Header Field Descriptions . . . . . . . . . . . . . . . . 25 7.8.5 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.7.1 TR-ID . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.8.6 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.7.2 Content-Type . . . . . . . . . . . . . . . . . . . . . . . 25 7.9 Header Field Descriptions . . . . . . . . . . . . . . . . 23
7.7.3 S-URL . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.9.1 TR-ID . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8. Example . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.9.2 To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . 28 7.9.3 From . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 28 7.9.4 Content-Type . . . . . . . . . . . . . . . . . . . . . . . 24
9.2 MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . . 28 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . 27
9.2.2 Character Encoding . . . . . . . . . . . . . . . . . . . . 28 9.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 27
9.2.3 Intended Usage . . . . . . . . . . . . . . . . . . . . . . 28 9.2 MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . . 27
9.2.4 Protocols . . . . . . . . . . . . . . . . . . . . . . . . 28 9.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.2.5 Security Considerations . . . . . . . . . . . . . . . . . 29 9.2.2 Character Encoding . . . . . . . . . . . . . . . . . . . . 27
9.2.6 Relevant Publications . . . . . . . . . . . . . . . . . . 29 9.2.3 Intended Usage . . . . . . . . . . . . . . . . . . . . . . 27
9.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 29 9.2.4 Protocols . . . . . . . . . . . . . . . . . . . . . . . . 27
9.3.1 Direction . . . . . . . . . . . . . . . . . . . . . . . . 29 9.2.5 Security Considerations . . . . . . . . . . . . . . . . . 27
9.3.2 Accept Types . . . . . . . . . . . . . . . . . . . . . . . 29 9.2.6 Relevant Publications . . . . . . . . . . . . . . . . . . 27
9.3.3 Wrapped Types . . . . . . . . . . . . . . . . . . . . . . 29 9.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . 29 9.3.1 Accept Types . . . . . . . . . . . . . . . . . . . . . . . 28
10.1 TLS and the MSRPS Scheme . . . . . . . . . . . . . . . . . 30 9.3.2 Wrapped Types . . . . . . . . . . . . . . . . . . . . . . 28
10.1.1 Sensitivity of the Session URL . . . . . . . . . . . . . . 30 9.3.3 Path . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1.2 End to End Protection of IMs . . . . . . . . . . . . . . . 31 10. Security Considerations . . . . . . . . . . . . . . . . . 28
10.1.3 CPIM compatibility . . . . . . . . . . . . . . . . . . . . 31 10.1 TLS and the MSRPS Scheme . . . . . . . . . . . . . . . . . 28
10.1.4 PKI Considerations . . . . . . . . . . . . . . . . . . . . 32 10.1.1 Sensitivity of the Session URL . . . . . . . . . . . . . . 29
11. Changes from Previous Draft Versions . . . . . . . . . . . 32 10.1.2 End to End Protection of IMs . . . . . . . . . . . . . . . 30
11.1 draft-ietf-simple-message-sessions-03 . . . . . . . . . . 32 10.1.3 CPIM compatibility . . . . . . . . . . . . . . . . . . . . 30
11.2 draft-ietf-simple-message-sessions-02 . . . . . . . . . . 33 10.1.4 PKI Considerations . . . . . . . . . . . . . . . . . . . . 31
11.3 draft-ietf-simple-message-sessions-01 . . . . . . . . . . 33 11. Changes from Previous Draft Versions . . . . . . . . . . . 31
11.4 draft-ietf-simple-message-sessions-00 . . . . . . . . . . 34 11.1 draft-ietf-simple-message-sessions-04 . . . . . . . . . . 31
11.5 draft-campbell-simple-im-sessions-01 . . . . . . . . . . . 34 11.2 draft-ietf-simple-message-sessions-03 . . . . . . . . . . 32
11.3 draft-ietf-simple-message-sessions-02 . . . . . . . . . . 32
11.4 draft-ietf-simple-message-sessions-01 . . . . . . . . . . 32
11.5 draft-ietf-simple-message-sessions-00 . . . . . . . . . . 33
11.6 draft-campbell-simple-im-sessions-01 . . . . . . . . . . . 33
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . 34 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . 34
Normative References . . . . . . . . . . . . . . . . . . . 35 Normative References . . . . . . . . . . . . . . . . . . . 34
Informational References . . . . . . . . . . . . . . . . . 35 Informational References . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . 38 Intellectual Property and Copyright Statements . . . . . . 37
1. Introduction 1. Introduction
The MESSAGE [10] extension to SIP [2] allows SIP to be used to The MESSAGE [10] extension to SIP [2] allows SIP to be used to
transmit instant messages. Instant messages sent using the MESSAGE transmit instant messages. Instant messages sent using the MESSAGE
method are normally independent of each other. This approach is often method are normally independent of each other. This approach is often
called page-mode messaging, since it follows a model similar to that called page-mode messaging, since it follows a model similar to that
used by many two-way pager devices. Page-mode messaging makes sense used by many two-way pager devices. Page-mode messaging makes sense
for instant message exchanges where a small number of messages occur. for instant message exchanges where a small number of messages occur.
Endpoints may treat page-mode messages as if they took place in an Endpoints may treat page-mode messages as if they took place in an
skipping to change at page 6, line 24 skipping to change at page 6, line 24
MSRP uses the following primitives: MSRP uses the following primitives:
SEND: Used to send message content from one endpoint to another. SEND: Used to send message content from one endpoint to another.
VISIT: Used by an endpoint to establish a session association to the VISIT: Used by an endpoint to establish a session association to the
host endpoint. host endpoint.
Assume A is an endpoint that wishes to establish a message session, 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 and B is the endpoint invited by A. A invites B to participate in a
message session by sending a URL that represents the session. This message session by sending a URL. This URL is temporary, and must not
URL is temporary, and must not duplicate the URL used for any other duplicate any URL that A has offered for other active sessions.
active sessions.
B "visits" A by connecting to A and sending a VISIT request B "visits" A by connecting to A and sending a VISIT request
containing the URL that A provided. This associates the connection containing the URL that A provided. This associates the connection
from B with the session. B then responds to the invitation, informing from B with the session. B then responds to the invitation with a URL
A that B has accepted the session. A and B may now exchange messages of its own. This informs A that B has accepted the session, and will
using SEND requests on the connection. 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 When either party wishes to end the session, it informs its peer
a SIP BYE request. A terminates the session by invalidating using the appropriate mechanism of the chosen signaling protocol,
associated state, and dropping the connection. such as a SIP BYE request.
The end to end case looks something like the following. (Note that 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 the example shows a logical flow only; syntax will come later in this
document.) document.)
A->B (SDP): offer (msrp://A/123) A->B (SDP): offer (msrp://A/123)
B->A (MSRP): VISIT (msrp://A/123) B->A (MSRP): VISIT (msrp://A/123, msrp://B/456)
A->B (MSRP): 200 OK A->B (MSRP): 200 OK
B->A (SDP): answer(msrp://A/123) B->A (SDP): answer(msrp://B/456)
A->B (MSRP): SEND A->B (MSRP): SEND (msrp://B/456)
B->A (MSRP): 200 OK B->A (MSRP): 200 OK
B->A (MSRP): SEND B->A (MSRP): SEND (msrp://A/123)
A->B (MSRP): 200 OK A->B (MSRP): 200 OK
5. Architectural Considerations 5. Architectural Considerations
There are a number of considerations that, if handled in a reasonable There are a number of considerations that, if handled in a reasonable
fashion, will allow more effective use of the protocols described in fashion, will allow more effective use of the protocols described in
this document. this document.
5.1 Transferring Large Content 5.1 Transferring Large Content
skipping to change at page 7, line 51 skipping to change at page 8, line 4
peer wishes to send very large content, it SHOULD establish 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 for that purpose. It should also indicate that the
dedicated session is send only, so that the receiving endpoint does dedicated session is send only, so that the receiving endpoint does
not attempt to send content back along the same session. not attempt to send content back along the same session.
6. SDP Offer-Answer Exchanges for MSRP Sessions 6. SDP Offer-Answer Exchanges for MSRP Sessions
MSRP sessions will typically be initiated using the Session MSRP sessions will typically be initiated using the Session
Description Protocol (SDP) [1] offer-answer mechanism, carried in the Description Protocol (SDP) [1] offer-answer mechanism, carried in the
Session Initiation Protocol (SIP) [2] or any other protocol Session Initiation Protocol (SIP) [2] or any other protocol
supporting it. MSRP borrows the idea of the direction attributes from supporting it.
COMEDIA [18], but does not depend on that specification.
6.1 Use of the SDP M-line 6.1 Use of the SDP M-line
The SDP "m"-line takes the following form: The SDP "m"-line takes the following form:
m=<media> <port> <protocol> <format list> m=<media> <port> <protocol> <format list>
For non-RTP media sessions, The media field specifies the top level For non-RTP media sessions, The media field specifies the top level
MIME media type for the session. For MSRP sessions, the media field MIME media type for the session. For MSRP sessions, the media field
MUST have the value of "message". The port field is normally not MUST have the value of "message". The port field is normally not
skipping to change at page 8, line 33 skipping to change at page 8, line 33
protocols, the field value MUST be defined by the specification for protocols, the field value MUST be defined by the specification for
that protocol binding. that protocol binding.
The format list list is ignored for MSRP. This is because MSRP The format list list is ignored for MSRP. This is because MSRP
formats are specified as MIME content types, which are not convenient formats are specified as MIME content types, which are not convenient
to encode in the SDP format list syntax. Instead, the allowed formats to encode in the SDP format list syntax. Instead, the allowed formats
are negotiated using "a"-line attributes. For MSRP sessions, the are negotiated using "a"-line attributes. For MSRP sessions, the
format list SHOULD contain a "*" character, and nothing else. format list SHOULD contain a "*" character, and nothing else.
The port field in the M-line is not used to determine the port to 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 which to connect. Rather, the actual port is determined by the the
contents of the session URL (Section 7.1). However, a port value of MSRP URL (Section 7.1) in the path attribute. However, a port value
zero has the normal SDP meaning. of zero has the normal SDP meaning.
The following example illustrates an m-line for a message session, The following example illustrates an m-line for a message session,
where the endpoint is willing to accept root payloads of message/ where the endpoint is willing to accept root payloads of message/
cpim, plain text or HTML. The second two types could either be cpim, plain text or HTML. The second two types could either be
presented as the root body, or could be contained within message/cpim presented as the root body, or could be contained within message/cpim
bodies. bodies.
m=message 9999 msrp/tcp * m=message 9999 msrp/tcp *
6.2 The Direction Attribute 6.2 The Accept Types Attribute
Since MSRP uses connection oriented transport protocols, one goal of
the SDP negotiation is to determine which participant initiates the
transport connection. The direction attribute advertises whether the
offerer or answerer wishes to initiate the connection, wishes the
peer endpoint to initiate the connection, or doesn't care.
The endpoint that accepts the connection is said to "host" the
session, and is known as the hosting endpoint. The endpoint that
initiates the connection is said to "visit" the session, and is known
as the visiting endpoint.
The direction attribute is included in an SDP a-line, with a value
taking the following syntax:
direction = direction-label ":" role
direction-label = "direction"
role = active / passive / both
active = "active" sp count
passive = "passive" sp count
both = "both" sp count [sp timeout]
count = 1*DIGIT ; Connection count
timeout = 1*DIGIT ; timeout value in seconds
The values for the role field are as follows:
passive: The endpoint wishes to host the session
active: The endpoint wishes the peer to host the session.
both: The endpoint is willing to act as either host or visitor. If
"both" is selected, it may contain an optional timeout value. This
timeout specifies how much time the answerer should wait before
giving up on a connection and attempting to take over as host
device. If the timeout value is not specified, it defaults to 30
seconds.
The SDP offer for an MSRP session MUST contain a direction attribute,
which MAY take any of the defined values. If the offerer is capable
of hosting the session, then it SHOULD select "both". The endpoint
SHOULD NOT select "active" unless it cannot host the session under
any circumstances. The endpoint SHOULD NOT select "passive" unless it
has no option but to host the session.
The count is used to determine if a new connection is required in
future SDP exchanges for a given stream. For 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 for the stream.
The SDP answer also MUST contain a direction attribute, but its value
choices are limited based on the value in the offer. If the offer
contained "active", then the answerer MUST either select "passive" or
reject the offer. Likewise, if the offer contained "passive", then
the answerer MUST select "active" or reject the offer. If the offer
contained "both", the answerer SHOULD select "active", but MAY select
"passive" if it is unable to reach the host device, or if local
policy requires it to act as host. The answerer MUST set the count
parameter to the same value as that in the offer.
6.3 The Accept Types Attribute
MSRP can carry any MIME encoded payload. Endpoints specify MIME MSRP can carry any MIME encoded payload. Endpoints specify MIME
content types that they are willing to receive in the accept types content types that they are willing to receive in the accept types
"a"-line attribute. This attribute has the following syntax: "a"-line attribute. This attribute has the following syntax:
accept-types = accept-types-label ":" format-list accept-types = accept-types-label ":" format-list
accept-types-label = "accept-types" accept-types-label = "accept-types"
format-list = format-entry *( SP format-entry) format-list = format-entry *( SP
format-entry = (type "/" subtype) / ("*") format-entry) format-entry = (type "/" subtype) / ("*")
type = token type = token
subtype = token subtype = token
SDP offers for MSRP sessions MUST include an accept-types attribute. SDP offers for MSRP sessions MUST include an accept-types attribute.
SDP answers MUST also include the attribute, which MUST contain SDP answers MUST also include the attribute, which MUST contain
either the same list as in the offer or a subset of that list. either the same list as in the offer or a subset of that list.
A "*" entry in the accept-types attribute indicates that the sender A "*" entry in the accept-types attribute indicates that the sender
may attempt to send messages with media types that have not been may attempt to send messages with media types that have not been
explicitly listed. If the receiver is able to process the media type, explicitly listed. If the receiver is able to process the media type,
skipping to change at page 10, line 41 skipping to change at page 9, line 31
types. This feature is needed as, otherwise, the list of formats for types. This feature is needed as, otherwise, the list of formats for
rich IM devices may be prohibitively large. rich IM devices may be prohibitively large.
The accept-types attribute may include container types, that is, mime The accept-types attribute may include container types, that is, mime
formats that contain other types internally. If compound types are formats that contain other types internally. If compound types are
used, the types listed in the accept-types attribute may be used both used, the types listed in the accept-types attribute may be used both
as the root payload, or may be wrapped in a listed container type. as the root payload, or may be wrapped in a listed container type.
(Note that the container type MUST also be listed in the accept-types (Note that the container type MUST also be listed in the accept-types
attribute.) attribute.)
6.4 MIME Wrappers 6.3 MIME Wrappers
The MIME content-types in the accept-types attribute will often The MIME content-types in the accept-types attribute will often
include container types; that is, types that contain other types. For include container types; that is, types that contain other types. For
example, "message/cpim" or "multipart/mixed." Occasionally an example, "message/cpim" or "multipart/mixed." Occasionally an
endpoint will need to specify a MIME body type that can only be used endpoint will need to specify a MIME body type that can only be used
if wrapped inside a listed container type. if wrapped inside a listed container type.
Endpoints MAY specify MIME types that are only allowed to be wrapped Endpoints MAY specify MIME types that are only allowed to be wrapped
inside compound types using the "accept-wrapped-types" attribute in inside compound types using the "accept-wrapped-types" attribute in
an SDP a-line. This attribute has the following syntax: an SDP a-line. This attribute has the following syntax:
accept-wrapped-types = wrapped-types-label ":" format-list accept-wrapped-types = wrapped-types-label ":" format-list
wrapped-types-label = "accept-wrapped-types" wrapped-types-label = "accept-wrapped-types" `
`
The format-list element has the identical syntax as defined for the The format-list element has the identical syntax as defined for the
accept-types attribute. The semantics for this attribute are accept-types attribute. The semantics for this attribute are
identical to those of the accept-types attribute, with the exception identical to those of the accept-types attribute, with the exception
that the specified types may only be used when wrapped inside that the specified types may only be used when wrapped inside
containers. Only types listed in accept-types may be used as the containers. Only types listed in accept-types may be used as the
"root" type for the entire body. Since any type listed in "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 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 bodies, format entries from the m-line SHOULD NOT be repeated in this
attribute. attribute.
skipping to change at page 11, line 35 skipping to change at page 10, line 23
The approach of specifying types that are only allowed inside of The approach of specifying types that are only allowed inside of
containers separately from the primary payload types allows an containers separately from the primary payload types allows an
endpoint to force the use of certain wrappers. For example, a CPIM endpoint to force the use of certain wrappers. For example, a CPIM
gateway device may require all messages to be wrapped inside gateway device may require all messages to be wrapped inside
message/cpim bodies, but may allow several content types inside message/cpim bodies, but may allow several content types inside
the wrapper. If the gateway were to specify the wrapped types in the wrapper. If the gateway were to specify the wrapped types in
the accept-types attribute, its peer could choose to use those the accept-types attribute, its peer could choose to use those
types without the wrapper. types without the wrapper.
6.5 URL Negotiations 6.4 URL Negotiations
An MSRP session is identified by an MSRP URL, which is determined by Each endpoint in an MSRP session is identified by a URL. These URLs
the hosting endpoint, and negotiated in the SDP exchange. Any SDP are negotiated in the SDP exchange. Each SDP offer or answer MUST
offer or answer that creates a possibility that the sender will host contain one or more MSRP URL in a path attribute. This attribute has
the session, that is, it contains a direction value of "passive" or the following syntax:
"both", MUST contain an MSRP URL in a session attribute. This
attribute has the following syntax:
a=session:<MSRP_URL> a=path ":" MSRP_URL *(SP MSRP_URL)
where <MSRP_URL> is an MSRP or MSRPS URL as defined in Section 7.1. where MSRP_URL is an MSRP or MSRPS URL as defined in Section 7.1.
The visitor will use the session URL established by the host both to The answerer will use the offered URL(s) to resolve the host address
resolve the host address and port, and to identify the session when and port when connecting, and to identify the target when sending
connecting. For MSRP sessions, the address field in the C-line is not 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 relevant, and MUST be ignored. The port field in the M-line MUST be
ignored if non-zero. Zero values have the normal meaning for SDP. ignored if non-zero. Zero values have the usual meaning for SDP.
The following example shows an SDP offer with a session URL of Both offerer and answerer store the path values received from the
"msrp://example.com:7394/2s93i" peer. For a given endpoint, the local URL is the URL that the
endpoint put into a 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"
v=0 v=0
o=someuser 2890844526 2890844527 IN IP4 alice.example.com o=someuser 2890844526 2890844527 IN IP4 alice.example.com
s= s=
c=IN IP4 alice.example.com c=IN IP4 alice.example.com m=message 9999 msrp/tcp *
m=message 9999 msrp/tcp *
a=accept-types:text/plain a=accept-types:text/plain
a=direction:both 0 a=path:msrp://a.example.com:7394/2s93i
a=session:msrp://example.com:7394/2s93i
The session URL MUST be a temporary URL assigned just for this The first URI in the path attribute MUST identify the endpoint that
particular session. It MUST NOT duplicate any URL in use for any generated the SDP document, or some other location where that
other session hosted by the endpoint. Further, since the peer endpoint wishes to receive messages associated with the session. If
endpoint will use the session URL to identify itself when connecting, the URL identifies the endpoint, it MUST MUST be a temporary URL
it SHOULD be hard to guess, and protected from eavesdroppers. This assigned just for this particular session, and MUST NOT duplicate any
will be discussed in more detail in Section 10. URL in use for any other session in which the endpoint 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
MSRP endpoints may sometimes need to send additional SDP exchanges As mentioned previously, this document describes MSRP for
for an existing session. For example, they may need to negotiate a peer-to-peer scenarios, that is, when no relays are used. However, we
new connection because of a TCP failure or some other reason. They expect a separate document to describe the use of relays in the near
may need to send periodic exchanges with no change to refresh state future. The path attribute supports lists of URLs in order to
in the network, for example, SIP timers. They may need to change some facilitate that work. For peer-to-peer session, a path attribute will
other stream in a session without affecting the MSRP stream, or they contain exactly one URL, describing an endpoint. This means that
may need to change an MSRP stream without affecting some other endpoints that only implement this specification will never send more
stream. 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.
Once MSRP endpoints have completed an intitial negotiation, further If an endpoint puts more than one URL in a path attribute, final URL
exchanges do not change their roles as the active or passive party in the path attribute MUST exhibit the uniqueness properties
for that particular stream. This means that if the visitor sends a described above. Uniqueness requirements for other entries in the
new SDP offer, it MUST remain the visitor, i.e. it MUST offer a attribute are out of scope for this document.
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 6.6 Updated SDP Offers
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
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 To do: Revisit this section based on new connection management rules
MUST close the existing connection, open a new connection, and send a
VISIT request as described below. 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.
If either party wish to send an SDP document that changes nothing at 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 all, then it MUST have the same o-line version as in the previous
exchange. exchange.
6.7 Example SDP Exchange 6.7 Example SDP Exchange
Endpoint A wishes to invite Endpoint B to a MSRP session. A offers Endpoint A wishes to invite Endpoint B to a MSRP session. A offers
the following session description containing the following lines: the following session description:
v=0 v=0
o=usera 2890844526 2890844527 IN IP4 alice.example.com o=usera 2890844526 2890844527 IN IP4 alice.example.com
s= s=
c=IN IP4 alice.example.com c=IN IP4 alice.example.com t=0 0
t=0 0
m=message 9999 msrp/tcp * m=message 9999 msrp/tcp *
a=accept-types: message/cpim text/plain text/html a=accept-types: message/cpim text/plain text/html
a=direction:both 0 a=path:msrp://alice.example.com:7394/2s93i9
a=session:msrp://alice.example.com:7394/2s93i9
Endpoint B chooses to participate in the role of visitor, opens a TCP Endpoint B performs a VISIT transaction passing the URL of msrp://
connection to alice.example.com:7394, and successfully performs a alice.example.com:7394/2s93i9. B indicates that it has accomplished
VISIT transaction passing the URL of msrp://alice.example.com:7394/ this by answering with:
2s93i9. B indicates that it has accomplished this by answering with:
v=0 v=0
o=userb 2890844530 2890844532 IN IP4 bob.example.com o=userb 2890844530 2890844532 IN IP4 bob.example.com
s= s=
c=IN IP4 dontlookhere c=IN IP4 dontlookhere
t=0 0 t=0 0
m=message 9999 msrp/tcp * m=message 9999 msrp/tcp *
a=accept-types:message/cpim text/plain 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 A may now send IMs to B by executing SEND transactions.
connection on which B sent the VISIT request.
6.8 Connection Negotiation
Previous versions of this document included a mechanism to negotiate
the direction for any required TCP connection. The mechanism was
loosely based on 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.
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 7. The Message Session Relay Protocol
The Message Session Relay Protocol (MSRP) is a text based, message The Message Session Relay Protocol (MSRP) is a text based, message
oriented protocol for the transfer of instant messages in the context oriented protocol for the transfer of instant messages in the context
of a session. MSRP uses the UTF8 character set. of a session. MSRP uses the UTF8 character set.
MSRP messages MUST be sent over a reliable, congestion-controlled, MSRP messages MUST be sent over a reliable, congestion-controlled,
connection-oriented transport protocol. This document specifies the connection-oriented transport protocol. This document specifies the
use of MSRP over TCP. Other documents may specify bindings for other use of MSRP over TCP. Other documents may specify bindings for other
such protocols. such protocols.
7.1 MSRP URLs 7.1 MSRP URLs
MSRP sessions are identified by MSRP URLs. An MSRP URL follows a An MSRP URL follows a subset of the URL syntax in Appendix A of
subset of the URL syntax in Appendix A of RFC2396 [4], with a scheme RFC2396 [4], with a scheme of "msrp":
of "msrp":
msrp_url = "msrp" ":" "//" [userinfo] hostport ["/' resource] msrp_url = "msrp" ":" "//" [userinfo] hostport ["/' resource]
resource = 1*unreserved resource = 1*unreserved
The constructions for "userinfo", "hostport", and "unreserved" are The constructions for "userinfo", "hostport", and "unreserved" are
detailed in RFC2396 [4]. detailed in RFC2396 [4].
An MSRP URL server part identifies the hosting device of an MSRP An MSRP URL server part identifies a participant in an MSRP session.
session. If the server part contains a numeric IP address, it MUST If the server part contains a numeric IP address, it MUST also
also contain a port. The resource part identifies a particular contain a port. The resource part identifies a particular session the
session at that host device. The absence of the resource part participant. The absence of the resource part indicates a reference
indicates a reference to an MSRP host device, but does not to an MSRP host device, but does not specifically refer to a
specifically refer to a particular session resource. particular session resource.
MSRP has an IANA registered recommended port defined in Section 9.1. 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 This value is not a default, as the URL process described herein will
always explicitly resolve a port number. However, the URLs SHOULD be always explicitly resolve a port number. However, the URLs SHOULD be
configured so that the recommended port is used whenever appropriate. configured so that the recommended port is used whenever appropriate.
This makes life easier for network administrators who need to manage This makes life easier for network administrators who need to manage
firewall policy for MSRP. firewall policy for MSRP.
The server part will typically not contain a userinfo component, but 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. MAY do so to indicate a user account for which the session is valid.
skipping to change at page 15, line 35 skipping to change at page 14, line 47
If the server part contains a numeric IP address and port, they MUST If the server part contains a numeric IP address and port, they MUST
be used as listed. be used as listed.
If the server part contains a host name and a port, the connecting 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, device MUST determine a host address by doing an A or AAAA DNS query,
and use the port as listed. and use the port as listed.
If the server part contains a host name but no port, the connecting If the server part contains a host name but no port, the connecting
device MUST perform the following steps: device MUST perform the following steps:
1. Construct an SRV [6] query string by prefixing the host name 1. Construct an SRV [6] query string by prefixing the host name with
with the service field "_msrp" and the protocol field ("_tcp" for the service field "_msrp" and the protocol field ("_tcp" for
TCP). For example, "_msrp._tcp.host.example.com". TCP). For example, "_msrp._tcp.host.example.com".
2. Perform a DNS SRV query using this query string. 2. Perform a DNS SRV query using this query string.
3. Select a resulting record according to the rules in RFC2782 [6]. 3. Select a resulting record according to the rules in RFC2782 [6].
Determine the port from the chosen record. Determine the port from the chosen record.
4. If necessary, determine a host device address by performing an A 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 or AAAA query on the host name field in the selected SRV result
record. If multiple A or AAAA records are returned, the first record. If multiple A or AAAA records are returned, the first
skipping to change at page 16, line 23 skipping to change at page 15, line 36
resolve an MSRP URL and does not know the protocol, it SHOULD assume resolve an MSRP URL and does not know the protocol, it SHOULD assume
TCP. TCP.
7.1.3 The msrps URL Scheme 7.1.3 The msrps URL Scheme
The "msrps" URL Scheme indicates that each hop MUST be secured with 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 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 MSRPS URL MUST NOT be considered equivalent to an MSRP URL. The MSRPS
scheme is further discussed in Section 10. scheme is further discussed in Section 10.
7.2 MSRP messages 7.2 Connection Managment
When an MSRP endpoint receives an SDP offer, and intends to accept
it, it MUST establish a connection device described by the remote
URL, if one does not already exist. If it already has a connection
associated with another session for which the peer URL host part
matches the host part of the 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 MSRP messages are either requests or responses. Requests and
responses are distinguished from one another by the first line. The responses are distinguished from one another by the first line. The
first line of a Request takes the form of the request-start entry 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 below. Likewise, the first line of a response takes the form of
response-start. The syntax for an MSRP message is as follows: response-start. The syntax for an MSRP message is as follows:
msrp-message = request-start/response-start *(header CRLF) msrp-message = request-start/response-start *(header CRLF)
[CRLF body] [CRLF body]
request-start = "MSRP" SP length SP Method CRLF request-start = "MSRP" SP length SP Method CRLF
skipping to change at page 17, line 5 skipping to change at page 16, line 31
/ 400 ;Bad Request / 400 ;Bad Request
/ 403 ;Forbidden / 403 ;Forbidden
/ 415 ;Unsupported Content Type / 415 ;Unsupported Content Type
/ 426 ;Upgrade Required / 426 ;Upgrade Required
/ 481 ;No session / 481 ;No session
/ 506 ;duplicate session / 506 ;duplicate session
Reason = token ; Human readable text describing status Reason = token ; Human readable text describing status
Transaction-ID = "Tr-ID" ":" token Transaction-ID = "Tr-ID" ":" token
Content-Type = "Content-Type" ":" quoted-string Content-Type = "Content-Type" ":" quoted-string
Session-URL = "S-URL" ":" msrp_url To = "To" ":" msrp_url *(SP msrp_url)
From = "From" ":" msrp_url
All requests and responses MUST contain at least a TR-ID header All requests and responses MUST contain at least a TR-ID header
field. Messages MAY contain other fields, depending on the method or field. All requests must also contain the To and From header fields.
Messages MAY contain other fields, depending on the method or
response code. response code.
7.3 MSRP Transactions 7.4 MSRP Transactions
An MSRP transaction consists of exactly one request and one response. An MSRP transaction consists of exactly one request and one response.
A response matches a transaction if it share the same TR-ID value, 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. and arrives on the same connection on which the transaction was sent.
Endpoints MUST select TR-ID header field values in requests so that 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 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 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 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 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 above. In particular, TR-ID values are not required to follow any
sequence. sequence.
MSRP Transactions complete when a response is received, or after a MSRP Transactions complete when a response is received, or after a
timeout interval expires with no response. Endpoints MUST treat such timeout interval expires with no response. Endpoints MUST treat such
timeouts in exactly the same way they would treat a 500 response. The timeouts in exactly the same way they would treat a 500 response. The
timeout interval SHOULD be 30 seconds, but other values may be timeout interval SHOULD be 30 seconds, but other values may be
established as a matter of local policy. established as a matter of local policy.
7.4 MSRP Sessions 7.5 MSRP Sessions
AN MSRP session is a context in which a series of instant messages AN MSRP session is a context in which a series of instant messages
are exchanged, using SEND requests. A session has two endpoints (a are exchanged, using SEND requests. A session has two endpoints,
host and a visitor). A session is identified by an MSRP URL. identified by MSRP URLs.
7.4.1 Initiating an MSRP session 7.5.1 Initiating an MSRP session
When an endpoint wishes to engage a peer endpoint in a message When an endpoint wishes to engage a peer in a message session, it
session, it invites the peer to communicate using an SDP offer, invites the peer to communicate using an SDP offer, carried over SIP
carried over SIP or some other protocol supporting the SDP offer/ or some other protocol supporting the SDP offer/answer model. For the
answer model. For the purpose of this document, we will refer to the purpose of this document, we will refer to the endpoint choosing to
endpoint choosing to initiate communication as the offerer, and the initiate communication as the offerer, and the peer being invited as
peer being invited as the answerer. the answerer.
The offerer SHOULD volunteer to act as the hosting endpoint if The offerer MUST be prepared to accept a connection from the
allowed by policy and network topology. The peer that is not the host answerer.
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.
If the offerer wishes to host the session, it MUST perform the The offerer MUST perform the following steps:
following steps:
1. Construct a session MSRP URL . This URL MUST resolve to the 1. Construct a MSRP URL to serve as the local URL. This URL MUST
location that the offerer wishes to host the connection. The URL resolve to the location that the offerer wishes to host the
SHOULD be temporary, SHOULD be hard to guess, and MUST not connection.
duplicate the URL of any other session currently hosted by the
offerer.
2. Listen for a connection from the peer. 2. Listen for a connection from the peer.
3. Construct an SDP offer as described in Section 6, including the 3. Construct an SDP offer as described in Section 6, including the
list of allowed IM payload formats in the accept-types attribute. list of allowed IM payload formats in the accept-types attribute.
The offerer maps the session URL to the session attribute, as The offerer puts its local URL into the path attribute, as
described in Section 6.5. described in Section 6.4. This URL becomes the offerer's local
path.
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 4. Send the SDP offer using the normal processing for the signaling
protocol. protocol.
If the offerer chooses to force the answerer to host the session, it If the answerer chooses to participate, it MUST perform the following
MUST perform the following steps instead: steps:
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 1. Parse the first URL from the offered path attribute. We will
protocol. 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
path are identical.
When the answerer receives the SDP offer and chooses to participate 2. Determine if it has any existing connection that is associated
in the session, it must choose whether to act as the host or the with a peer URL host part that matches that of the remote URL,
visitor. A direction attribute value of "both" in the offer indicates and with a transport protocol matching that from the M-line. If
that the offerer prefers to host, but will allow the answerer to one exists, the answerer SHOULD use it for the new session rather
host. In this case the answerer SHOULD act as the visitor, but MAY than establishing a new connection.
choose to host. A value of "passive" means the offerer insists upon
hosting, in which case the answerer MUST act as visitor or decline
the offer.
If the answerer chooses to participate as a visitor, it MUST perform [Open Issue: Should we discuss situations when an endpoint may
the following steps: want to intentially not share a connection?]
1. Determine the host address and port from the session URL, 3. If no appropriate connection already exists, determine the host
following the procedures in section Section 7.1 address and port from the remote URL, following the procedures in
section Section 7.1, and connect using the transport protocol
from the M-line.
2. Connect to the host address and port, using the transport 4. Construct a MSRP URL . This URL MUST resolve to the the answerer.
protocol from the M-line. This URL becomes the answerer's local URL.
3. Construct a VISIT request, which MUST contain the following 5. Construct a VISIT request, which MUST contain the following
information: information:
1. An S-URL header field containing the session URL. 1. An To header field containing the remote URL.
2. A TR-ID header field containing a unique transaction ID. 2. A From containing the answerer's local URL.
3. A size field containing size of the message subsequent to the 3. A TR-ID header field containing a unique transaction ID.
4. A size field containing size of the message subsequent to the
start-line. start-line.
4. Send the request and wait for a response 6. Send the request and wait for a response
5. If the transaction succeeds, send a SDP answer via the signaling 7. If the VISIT transaction succeeds, send a SDP answer via the
protocol, according to the following rules: signaling protocol, according to the following rules:
1. The C-line is copied unmodified from the offer. 1. The C-line is copied unmodified from the offer.
2. The M-Line contains a dummy port value, the protocol field 2. The M-Line contains a dummy port value, the protocol field
from the original offer, and the accept-types attribute from the original offer.
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 by the direction attribute of the answer. If the
answerer 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 the offerer is unable to open a TCP
connection to the host device, this connection attempt may take a
fairly large number of seconds to timeout. This length of time will
not be acceptable for many call flow scenarios. Therefore, the
devices SHOULD limit the time they wait for the TCP connection to a
shorter timeout value, which will default to 30 seconds. However, the
offerer MAY supply a different time in the timeout parameter of the
"both" direction value. If the offerer supplies a value, the answerer
SHOULD use that value for the TCP connection timeout, interpreted as
an integer number of seconds.
If the answerer chooses to host the session, it MUST perform the
following steps:
1. Construct a new session URL . This MUST be a MSRP or MSRPS URL,
MUST resolve to the answerer, and MUST not be the same as the
session URL in the offer. The URL SHOULD be temporary, SHOULD be
hard to guess, and MUST not duplicate URLs currently identifying
any active sessions hosted by the answerer.
2. Listen for a connection from the peer.
3. Construct an SDP answer as described in Section 6, mapping the
new session URL to the session attribute, insert a direction
attribute with the value of "passive", and the count value copied
from the offer.
4. Send the SDP offer using the normal processing for the signaling
protocol.
When the offerer receives the SDP answer, it must determine who will
continue to host the session. If the answer contained a direction
attribute value of "active", the offerer MUST continue as host. If
the offer contained "active" or "both" and the answer contains
"passive", then the offerer MUST allow the answerer to host the
session.
If the offerer chooses not to continue as host, it MUST perform the
following steps:
1. Release resources it acquired in expectation of hosting the
session, if any.
2. Determine the host address and port from the session URL of the
answer, following the procedures in section Section 7.1
3. Connect to the host address and port, using the transport
protocol from the M-line.
4. Construct a VISIT request, which MUST contain the following
information:
1. A S-URL header field containing the session URL.
2. A TR-ID header field containing a unique transaction ID.
3. A size field containing size of the message subsequent to the 3. The accept-types attribute contains the SEND payload media
start-line. 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.
5. Send the request and wait for a response 4. The path attribute contains the answerer's local URL.
6. If either the connection attempt or the VISIT transaction fail, 8. If the VISIT transaction fails, the answerer MUST reject the
acknowledge the answer, then initiate the tear-down of the offer.
session using the signaling protocol.
7.4.2 Handling VISIT requests 7.5.2 Handling VISIT requests
An MSRP endpoint that is hosting a session will receive a VISIT An MSRP endpoint that is hosting a session will receive a VISIT
request from the visiting endpoint. When an endpoint receives a VISIT request from the visiting endpoint. When an endpoint receives a VISIT
request, it MUST perform the following procedures: request, it MUST perform the following procedures:
1. Check if state exists for a session with a URL that matches the 1. Check if state exists for a session with a local URL that matches
S-URL of the VISIT request. If so, and if no visitor connection the To header field value of the VISIT request. If so, and if no
has been associated with the session, then return a 200 response, previous VISIT request has been received for that URL, then
and save state designating the connection on which the request return a 200 response, and save state associating the URL in the
was received as the visitor leg of the session. From header field with the connection on which the request was
received .
2. If the session exists, and the visitor connection has already 2. If the state exists, and a matching VISIT transaction has already
been established, return a 506 response and do not change session occured, return a 506 response and do not change session state in
state in any way. any way.
3. If no matching session exists, return a 481 request, and do not 3. If no matching state exists, return a 481 response, and do not
change session state in any way. change session state in any way.
7.4.3 Sending Instant Messages on a Session 7.5.3 Sending Instant Messages on a Session
Once a MSRP session has been established, either endpoint may send Once a MSRP session has been established, either endpoint may send
instant messages to its peer using the SEND method. When an endpoint 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 wishes to do so, it MUST construct a SEND request according to the
following process: following process:
1. Insert the message payload in the body, and the media type in the 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 Content-Type header field. The media type MUST match one of the
types in the format list negotiated in the SDP exchange. If a "*" types in the format list negotiated in the SDP exchange. If a "*"
was present in the accept-types attribute, then the media type was present in the accept-types attribute, then the media type
SHOULD match one of the explicitly listed entries, but MAY be any SHOULD match one of the explicitly listed entries, but MAY be any
other arbitrary value. other arbitrary value.
2. Set the TR-ID header field to a unique value. 4. Set the TR-ID header field to a unique value.
3. Send the request on the connection associated with the session. 5. Send the request on the connection associated with the session.
4. If a 2xx response code is received, the transaction was 6. If a 2xx response code is received, the transaction was
successful. successful.
5. If a 415 response is received, this indicates the recipient is 7. If a 415 response is received, this indicates the recipient is
unable or unwilling to process the media type. The sender SHOULD unable or unwilling to process the media type. The sender SHOULD
NOT attempt to send that particular media type again in the NOT attempt to send that particular media type again in the
context of this session. context of this session.
6. If any other response code is received, or if the transaction 8. If any other response code is received, or if the transaction
times out, the endpoint SHOULD assume the session has failed, and times out, the endpoint SHOULD assume the session has failed,
initiate tear-down, either ending the session, or by sending an either tear down the session, or attempt to re-establish the
updated SDP offer proposing a new connection. If a new connection session by sending an updated SDP offer proposing a new
is established, the endpoint MAY choose to resend the content on connection. If a new connection is established, the endpoint MAY
the new connection. choose to resend the content on the new connection.
Open Issue: Do we need to create a duplicate mechanism to suppress Open Issue: Do we need to create a duplicate mechanism to suppress
duplicate messages when a new connection is established in this duplicate messages when a new connection is established in this
fashion? mechanism? List consensus seems to indicate we do. We may fashion? mechanism? List consensus seems to indicate we do. We may
need to specify that the tr-id space spans a sequence of need to specify that the tr-id space spans a sequence of
connections if they are associated with same stream, and of connections if they are associated with same stream, and of
course, specify what it means for a stream to span connections. course, specify what it means for a stream to span connections.
When an endpoint receives a SEND request, it MUST perform the When an endpoint receives a SEND request, it MUST perform the
following steps. following steps.
1. Determine that it understands the media type in the body, if any 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. exists.
2. If it does, return a 200 response and render the message to the 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 user. The method of rendering is a matter of local policy. If the
message contained no body at all, the endpoint should quietly message contained no body at all, the endpoint should quietly
ingore it. ingore it.
3. If it does not understand the media type, return a 415 response. 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 The endpoint MUST NOT return a 415 response for any media type
for which it indicated support in the SDP exchange. for which it indicated support in the SDP exchange.
7.4.4 Ending a Session 7.5.4 Ending a Session
When either endpoint in an MSRP session wishes to end the session, it When either endpoint in an MSRP session wishes to end the session, it
first signals its intent using the normal processing for the first signals its intent using the normal processing for the
signaling protocol. For example, in SIP, it would send a BYE request signaling protocol. For example, in SIP, it would send a BYE request
to the peer. After agreeing to end the session, the host endpoint to the peer. After agreeing to end the session, the host endpoint
MUST release any resources acquired as part of the session. MUST release any resources acquired as part of the session.
The host MUST destroy local state for the session. This involves Each peer MUST destroy all local state for the session. This involves
completely removing the state entry for this session and invalidating completely removing the state entry for the session and invalidating
session URL. the session URL.
Since these host actions completely destroy the session state at If no other sessions are using the connection, the endpoint that
the hosting device, the visitor is not required to take further opened it SHOULD tear it down. However, the passive party MAY tear
action beyond cleaning up any local state. down an unused connection after a locally configured timeout period.
When an endpoint chooses to close a session, it may have SEND When an endpoint chooses to close a session, it may have SEND
transactions outstanding. For example, it may have send SEND requests transactions outstanding. For example, it may have send SEND requests
to which it has not yet received a response, or it may have received 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 SEND requests that to which it has not responded. Once an endpoint
has decided to close the connection, it SHOULD wait for such has decided to close the connection, it SHOULD wait for such
outstanding transactions to complete. It SHOULD NOT generate any new outstanding transactions to complete. It SHOULD NOT generate any new
SEND transactions, and it MAY choose not to respond to any new SEND 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 requests that are received after it decides to close the session. It
SHOULD not respond to any new messages that arrive after it signals SHOULD not respond to any new messages that arrive after it signals
skipping to change at page 23, line 31 skipping to change at page 21, line 29
it SHOULD NOT initiate any more SEND requests. It SHOULD wait for any it SHOULD NOT initiate any more SEND requests. It SHOULD wait for any
outstanding transactions that it initiated to complete, and it SHOULD outstanding transactions that it initiated to complete, and it SHOULD
attempt respond to any open SEND transactions received prior to being attempt respond to any open SEND transactions received prior to being
signaled. signaled.
It is not possible to completely eliminate the chance of a session It is not possible to completely eliminate the chance of a session
terminating with incomplete SEND transactions. When this occurs, the terminating with incomplete SEND transactions. When this occurs, the
endpoint SHOULD clearly inform the user that the messages may not endpoint SHOULD clearly inform the user that the messages may not
have been delivered. have been delivered.
7.4.5 Managing Session State and Connections 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 identified by an MSRP URL. An active
session also has an associated network connection.
When session state is destroyed for any reason, the hosting device A MSRP session is represented by state at each endpoint, identified
SHOULD drop the connection. by the local URL and remote path. An active session also has an
associated network connection.
If the connection fails for any reason, the session hosting device If the connection fails for any reason, the session hosting device
MUST invalidate the session state. Once a connection is dropped, the MUST invalidate the session state for all sessions using the
associated session state MUST NOT be reused. If an endpoint wishes to connection. Once a connection is dropped, any associated session
continue to communicate after detecting a connection failure, it MAY state MUST NOT be reused. If an endpoint wishes to continue to
initiate a new SDP exchange to negotiate a new session URL. communicate after detecting a connection failure, it MAY initiate a
Otherwise, it SHOULD attempt to tear down the session using the rules new SDP exchange to negotiate a new session URL. Otherwise, it SHOULD
of the signaling protocol. 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 It would be nice to allow sessions to be recovered after a
connection failure, perhaps by allowing the active endpoint to connection failure, perhaps by allowing the active endpoint to
reconnect, and send a new VISIT request. However, this approach reconnect, and send a new VISIT request. However, this approach
creates a race condition between the time that the hosting device creates a race condition between the time that the hosting device
notices the failed connection, and the time that the endpoint notices the failed connection, and the time that the endpoint
tries to recover the session. If the endpoint attempts to tries to recover the session. If the endpoint attempts to
reconnect prior to the hosting device noticing the failure, the reconnect prior to the hosting device noticing the failure, the
hosting device will interpret the recovery attempt as a conflict. hosting device will interpret the recovery attempt as a conflict.
The only way around this would be to force the hosting device to The only way around this would be to force the hosting device to
do a liveness check on the original connection, which would create 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 a lot of complexity and overhead that do not seem to be worth the
trouble. trouble.
7.5 Method Descriptions 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 This section summarizes the purpose of each MSRP method. All MSRP
messages MUST contain the TR-ID header fields. All messages MUST messages MUST contain the TR-ID, From, and To header fields. All
contain a length field in the start line that indicates the overall messages MUST contain a length field in the start line that indicates
length of the request, including any body, but not including the the overall length of the request, including any body, but not
start line itself. Additional requirements exist depending on the including the start line itself. Additional requirements exist
individual method. depending on the individual method.
7.5.1 SEND 7.7.1 SEND
The SEND method is used by both the host and visitor endpoints to The SEND method is used by both the host and visitor endpoints to
send instant messages to its peer endpoint. SEND requests SHOULD send instant messages to its peer endpoint. A SEND request MUST
contain a MIME body part. The body MUST be of a media type included contain a To header field containing the sender's remote path, and a
in the format list negotiated in the SDP exchange. If a body is From header field containing the sender's local URL. SEND requests
present, the request MUST contain a Content-Type header field 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. identifying the media type of the body.
To Do: We plan to expand the use of MIME headers to allow any 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 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 this version for the sake of getting the draft out as soon as
possible, but will follow soon. possible, but will follow soon.
7.5.2 VISIT 7.7.2 VISIT
The visiting endpoint uses the VISIT method to associate a network The visiting endpoint uses the VISIT method to associate a network
connection with the session state at the hosting device. The request connection with the session state at the hosting device. A VISIT
MUST contain a S-URL header matching the session URL. request MUST include a To header including the sender's remote URL,
and a From header field containing the sender's local URL.
7.6 Response Code Descriptions 7.8 Response Code Descriptions
This section summarizes the various response codes. Except where This section summarizes the various response codes. Except where
noted, all responses MUST contain a TR-ID header field matching the noted, all responses MUST contain a TR-ID header field matching the
TR-ID header field of the associated request. TR-ID header field of the original request, and To and From headers
matching those of the original request.
7.6.1 200 7.8.1 200
The 200 response code indicates a successful transaction. The 200 response code indicates a successful transaction.
7.6.2 400 7.8.2 400
A 400 response indicates a request was unintelligible. A 400 response indicates a request was unintelligible.
7.6.3 415 7.8.3 415
A 415 response indicates the SEND request contained a MIME A 415 response indicates the SEND request contained a MIME
content-type that is not understood by the receiver. content-type that is not understood by the receiver.
7.6.4 426 7.8.4 426
A 426 response indicates that the request is only allowed over TLS A 426 response indicates that the request is only allowed over TLS
protected connections. protected connections.
7.6.5 481 7.8.5 481
A 481 response indicates that no session exists for the connection. A 481 response indicates that no session exists for the connection.
7.6.6 506 7.8.6 506
A 506 response indicates that a VISIT request occurred in which the A 506 response indicates that a VISIT request occurred in which the
S-URL indicates a session that is already associated with another To header indicates a local path that is already associated with
connection. A 506 response MUST NOT be returned in response to any another connection. A 506 response MUST NOT be returned in response
method other than VISIT. to any method other than VISIT.
7.7 Header Field Descriptions 7.9 Header Field Descriptions
This section summarizes the various header fields. MSRP header fields This section summarizes the various header fields. MSRP header fields
are single valued; that is, they MUST NOT occur more than once in a are single valued; that is, they MUST NOT occur more than once in a
particular request or response. particular request or response.
7.7.1 TR-ID 7.9.1 TR-ID
The TR-ID header field contains a transaction identifier used to map 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 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. among all values used by a given endpoint inside a given session.
MSRP elements MUST NOT assume any additional semantics for TR-ID. MSRP elements MUST NOT assume any additional semantics for TR-ID.
7.7.2 Content-Type 7.9.2 To
The To header field is used to indicate the sender's remote path. All
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 contain a From header field.
7.9.4 Content-Type
The Content-Type header field is used to indicate the MIME media 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. 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 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 MIME header. This is not reflected in this version, but will be in
a shortly forthcoming one. a shortly forthcoming one.
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 8. Example
This section shows an example message flow for the most common This section shows an example message flow for the most common
scenario. The example assumes SIP is used to transport the SDP scenario. The example assumes SIP is used to transport the SDP
exchange. Details of the SIP messages and SIP proxy infrastructure exchange. Details of the SIP messages and SIP proxy infrastructure
are omitted for the sake of brevity. In the example, assume the are omitted for the sake of brevity. In the example, assume the
offerer is sip:alice@atlanta.com and the answerer is offerer is sip:alice@atlanta.com and the answerer is
sip:bob@biloxi.com. In any given MSRP message, an "xx" in the length 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. field indicates the actual length of the rest of the message.
skipping to change at page 26, line 48 skipping to change at page 25, line 33
|<-----------------------| |<-----------------------|
|(9) (MSRP) 200 OK | |(9) (MSRP) 200 OK |
|----------------------->| |----------------------->|
|(10) (SIP) BYE | |(10) (SIP) BYE |
|----------------------->| |----------------------->|
|(11) (SIP) 200 OK | |(11) (SIP) 200 OK |
|<-----------------------| |<-----------------------|
| | | |
| | | |
1. Alice constructs a session URL of msrp:// 1. Alice constructs a local URL of msrp://alicepc.atlanta.com:7777/
alicepc.atlanta.com:7777/iau39 and listens for a connection on iau39 and listens for a connection on TCP port 7777.
TCP port 7777.
Alice->Bob (SIP): INVITE sip:bob@biloxi.com Alice->Bob (SIP): INVITE sip:bob@biloxi.com
v=0 v=0
o=alice 2890844557 2890844559 IN IP4 host.anywhere.com o=alice 2890844557 2890844559 IN IP4 host.anywhere.com
s= s=
c=IN IP4 fillername c=IN IP4 fillername
t=0 0 t=0 0
m=message 9999 msrp/tcp * m=message 9999 msrp/tcp *
a=accept-types:text/plain a=accept-types:text/plain
a=direction:both 0 a=path:msrp://alicepc.atlanta.com:7777/iau39
a=session:msrp://alicepc.atlanta.com:7777/iau39
2. Bob opens a TCP connection to alicepc.atlanta.com:7777: 2. Bob opens a TCP connection to alicepc.atlanta.com:7777:
Bob->Alice (MSRP): Bob->Alice (MSRP):
MSRP xx VISIT MSRP xx VISIT
S-URL:msrp://alicepc.atlanta.com:7777/iau39 To:msrp://alicepc.atlanta.com:7777/iau39
From:msrp://bob.atlanta.com:8888/9di4ea
Tr-ID: sie09s Tr-ID: sie09s
3. Alice->Bob (MSRP): 3. Alice->Bob (MSRP):
MSRP xx 200 OK MSRP xx 200 OK
To:msrp://alicepc.atlanta.com:7777/iau39
From:msrp://bob.atlanta.com:8888/9di4ea
Tr-ID: sie09s Tr-ID: sie09s
4. Bob->Alice (SIP): 200 OK 4. Bob->Alice (SIP): 200 OK
v=0 v=0
o=bob 2890844612 2890844616 IN IP4 host.anywhere.com o=bob 2890844612 2890844616 IN IP4 host.anywhere.com
s= s=
c=IN IP4 ignorefield c=IN IP4 ignorefield
t=0 0 t=0 0
m=message 9999 msrp/tcp * m=message 9999 msrp/tcp *
a=accept-types:text/plain a=accept-types:text/plain
a=direction:active 0 a=path:msrp://bob.atlanta.com:8888/9di4ea
5. Alice->Bob (SIP): ACK 5. Alice->Bob (SIP): ACK
6. Alice->Bob (MSRP): 6. Alice->Bob (MSRP):
MSRP xx SEND MSRP xx SEND
To:msrp://bob.atlanta.com:8888/9di4ea
From:msrp://alicepc.atlanta.com:7777/iau39
TR-ID: 123 TR-ID: 123
Content-Type: "text/plain" Content-Type: "text/plain"
Hi, I'm Alice! Hi, I'm Alice!
7. Bob->Alice (MSRP): 7. Bob->Alice (MSRP):
MSRP xx 200 OK MSRP xx 200 OK
To:msrp://bob.atlanta.com:8888/9di4ea
From:msrp://alicepc.atlanta.com:7777/iau39
TR-ID: 123 TR-ID: 123
8. Bob->Alice (MSRP): 8. Bob->Alice (MSRP):
MSRP xx SEND MSRP xx SEND
To:msrp://alice.atlanta.com:7777/iau39
From:msrp://bob.atlanta.com:8888/9di4ea
TR-ID: 456 TR-ID: 456
Content-Type: "text/plain" Content-Type: "text/plain"
Hi, Alice! I'm Bob! Hi, Alice! I'm Bob!
9. Alice->Bob (MSRP): 9. Alice->Bob (MSRP):
MSRP xx 200 OK MSRP xx 200 OK
To:msrp://alice.atlanta.com:7777/iau39
From:msrp://bob.atlanta.com:8888/9di4ea
TR-ID: 456 TR-ID: 456
10. Alice->Bob (SIP): BYE 10. Alice->Bob (SIP): BYE
Alice invalidates session and drops connection. Alice invalidates local session state.
11. Bob invalidates local state for the session. 11. Bob invalidates local state for the session.
Bob->Alice (SIP): 200 OK Bob->Alice (SIP): 200 OK
9. IANA Considerations 9. IANA Considerations
9.1 MSRP Port 9.1 MSRP Port
MSRP uses TCP port XYX, to be determined by IANA after this document MSRP uses TCP port XYX, to be determined by IANA after this document
skipping to change at page 29, line 12 skipping to change at page 28, line 4
The Message Session Relay Protocol (MSRP). The Message Session Relay Protocol (MSRP).
9.2.5 Security Considerations 9.2.5 Security Considerations
See Section 10. See Section 10.
9.2.6 Relevant Publications 9.2.6 Relevant Publications
RFCXXXX RFCXXXX
[Note to RFC Editor: Please replace RFCXXXX in the above paragraph [Note to RFC Editor: Please replace RFCXXXX in the above paragraph
with the actual number assigned to this document. with the actual number assigned to this document.
9.3 SDP Parameters 9.3 SDP Parameters
This document registers the following SDP parameters in the This document registers the following SDP parameters in the
sdp-parameters registry: sdp-parameters registry:
9.3.1 Direction 9.3.1 Accept Types
Attribute-name: direction Attribute-name: accept-types
Long-form Attribute Name Direction Long-form Attribute Name Acceptable MIME Types
Type: Media level Type: Media level
Subject to Charset Attribute No Subject to Charset Attribute No
Purpose and Appropriate Values See Section 6.2. Purpose and Appropriate Values See Section 6.2.
9.3.2 Accept Types 9.3.2 Wrapped Types
Attribute-name: accept-types Attribute-name: accept-wrapped-types
Long-form Attribute Name Acceptable MIME Types Long-form Attribute Name Acceptable MIME Types Inside Wrappers
Type: Media level Type: Media level
Subject to Charset Attribute No Subject to Charset Attribute No
Purpose and Appropriate Values See Section 6.3. Purpose and Appropriate Values See Section 6.3.
9.3.3 Wrapped Types 9.3.3 Path
Attribute-name: accept-wrapped-types Attribute-name: path
Long-form Attribute Name Acceptable MIME Types Inside Wrappers Long-form Attribute Name MSRP URL Path
Type: Media level Type: Media level
Subject to Charset Attribute No Subject to Charset Attribute No
Purpose and Appropriate Values See Section 6.4. Purpose and Appropriate Values See Section 6.4.
10. Security Considerations 10. Security Considerations
There are a number of security considerations for MSRP, some of which There are a number of security considerations for MSRP, some of which
are mentioned elsewhere in this document. This section discusses are mentioned elsewhere in this document. This section discusses
those further, and introduces some new ones. those further, and introduces some new ones.
skipping to change at page 30, line 22 skipping to change at page 29, line 11
means that all MSRP server devices, that is, all devices that listen means that all MSRP server devices, that is, all devices that listen
for TCP connections, MUST be prepared to handle both TLS and plain for TCP connections, MUST be prepared to handle both TLS and plain
text connections on the same port. When a device accepts a TCP text connections on the same port. When a device accepts a TCP
connection, it MUST watch for the TLS handshake messages to determine connection, it MUST watch for the TLS handshake messages to determine
if a particular connection uses TLS. If the first data received is 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 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 TLS handshake until it reads the entire message. Once the message has
been completely received, the device resumes watching for the start been completely received, the device resumes watching for the start
TLS message. TLS message.
An MSRP device MAY refuse to accept a given request over a non-TLS Any MSRP device MAY refuse to accept a given request over a non-TLS
connection by returning a 426 response. connection by returning a 426 response.
MSRP devices acting in the role of TCP client MAY perform a TLS 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 handshake at any time, as long as the request occurs between MSRP
messages. The endpoint MUST NOT send a start TLS request in the messages. The endpoint MUST NOT send a start TLS request in the
middle of an MSRP message. middle of an MSRP message.
The working group considered only requiring the endpoint to watch The working group considered only requiring the endpoint to watch
for a TLS handshake at the beginning of the session. However, the 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 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. TLS request or an MSRP request by only reading ahead three bytes.
Therefore, the working group chose to allow a session to switch to Therefore, the working group chose to allow a session to switch to
TLS in mid-stream, as long as the switch occurs between MRSP TLS in mid-stream, as long as the switch occurs between MRSP
messages. messages.
The MSRPS URI scheme indicates that all hops in an MSRP session MUST 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 be protected with TLS. Since this document does not specify the use
of intermidiary devices, then MSRPS support is trivially equivilant of intermidiary devices, then MSRPS support is trivially equivilant
to TLS support. However, if intermediaries do exist, either as to TLS support. However, if intermediaries do exist, either as
described in an MSRP extension document, or as sort of proprietary described in an MSRP extension document, or as some sort of
devices, they MUST ensure protection at all hops for an MSRPS URL. 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 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 connection. If a hosting device receives a VISIT request for an MSRPS
URL over an unprotected connection, it MUST reject the request with a URL over an unprotected connection, it MUST reject the request with a
426 response. 426 response.
10.1.1 Sensitivity of the Session URL 10.1.1 Sensitivity of the Session URL
The URL of a MSRP session is used by the visiting endpoint to The URL sent in the SDP offer for a MSRP session is used by the
identify itself to the hosting device. If an attacker were able to answerer to identify itself to the hosting device. If an attacker
acquire the session URL, either by guessing it or by eavesdropping, were able to acquire the session URL, either by guessing it or by
there is a window of opportunity in which the attacker could hijack eavesdropping, there is a window of opportunity in which the attacker
the session by sending a VISIT request to the host device before the could hijack the session by sending a VISIT request to the host
true visiting endpoint. Because of this sensitivity, the session URL device before the true visiting endpoint. Because of this
SHOULD be constructed in a way to make it difficult to guess, and sensitivity, the session URL SHOULD be constructed in a way to make
should be sufficiently random so that it is unlikely to be reused. it difficult to guess, and should be sufficiently random so that it
All mechanisms used to transport the session URL to the visitor and is unlikely to be reused. All mechanisms used to transport this URL
back to the host SHOULD be protected from eavesdroppers and to the answerer SHOULD be protected from eavesdroppers and
man-in-the-middle attacks. man-in-the-middle attacks.
Therefore an MSRP device MUST support the use of TLS for at least the Therefore a MSRP device MUST support the use of TLS for at least the
VISIT request, which by extension indicates the endpoint MUST support VISIT request, which by extension indicates the endpoint MUST support
the use of TLS for all MSRP messages. Further, MSRP connections the use of TLS for all MSRP messages. Further, MSRP connections
SHOULD actually be protected with TLS. Further, an MSRP endpoint MUST SHOULD actually be protected with TLS. Further, an MSRP endpoint MUST
be capable of using the security features of the signaling protocol be capable of using the security features of the signaling protocol
in order to protect the SDP exchange and SHOULD actually use them on in order to protect the SDP exchange and SHOULD actually use them on
all such exchanges. End-to-end protection schemes SHOULD be preferred all such exchanges. End-to-end protection schemes SHOULD be preferred
over hop-by-hop schemes for protection of the SDP exchange. over hop-by-hop schemes for protection of the SDP exchange.
10.1.2 End to End Protection of IMs 10.1.2 End to End Protection of IMs
skipping to change at page 32, line 42 skipping to change at page 31, line 36
use of self-signed certificates, and SHOULD support the ability to use of self-signed certificates, and SHOULD support the ability to
configure lists of trusted certificates. configure lists of trusted certificates.
To Do: Add text discussion the use of TLS certificates in more To Do: Add text discussion the use of TLS certificates in more
detail. detail.
11. Changes from Previous Draft Versions 11. Changes from Previous Draft Versions
This section to be deleted prior to publication as an RFC This section to be deleted prior to publication as an RFC
11.1 draft-ietf-simple-message-sessions-03 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.
11.2 draft-ietf-simple-message-sessions-03
Removed all specification of relays, and all features specific to Removed all specification of relays, and all features specific to
the use of relays. The working group has chosen to move relay work the use of relays. The working group has chosen to move relay work
into a separate effort, in order to advance the base into a separate effort, in order to advance the base
specification. (The MSRP acronym is unchanged for the sake of specification. (The MSRP acronym is unchanged for the sake of
convenience.) This included removal of the BIND method, all convenience.) This included removal of the BIND method, all
response codes specific to BIND, Digest Authentication, and the response codes specific to BIND, Digest Authentication, and the
inactivity timeout. inactivity timeout.
Removed text indicating that an endpoint could retry failed Removed text indicating that an endpoint could retry failed
requests on the same connection. Rather, the endpoint should requests on the same connection. Rather, the endpoint should
consider the connection dead, and either signal a reconnection or consider the connection dead, and either signal a reconnection or
end the session. end the session.
Added text describing subsequent SDP exchanges. Added mandatory Added text describing subsequent SDP exchanges. Added mandatory
"count" parameter to the direction attribute to allow explicit "count" parameter to the direction attribute to allow explicit
signaling of the need to reconnect. signaling of the need to reconnect.
Added text to describe the use of send and receive only indicators Added text to describe the use of send and receive only indicators
in SDP for one-way transfer of large content. in SDP for one-way transfer of large content.
Added text requiring unique port field values if multiple M-line's Added text requiring unique port field values if multiple M-line's
skipping to change at page 33, line 18 skipping to change at page 32, line 27
end the session. end the session.
Added text describing subsequent SDP exchanges. Added mandatory Added text describing subsequent SDP exchanges. Added mandatory
"count" parameter to the direction attribute to allow explicit "count" parameter to the direction attribute to allow explicit
signaling of the need to reconnect. signaling of the need to reconnect.
Added text to describe the use of send and receive only indicators Added text to describe the use of send and receive only indicators
in SDP for one-way transfer of large content. in SDP for one-way transfer of large content.
Added text requiring unique port field values if multiple M-line's Added text requiring unique port field values if multiple M-line's
exist. exist.
Corrected a number of editorial mistakes. Corrected a number of editorial mistakes.
11.2 draft-ietf-simple-message-sessions-02 11.3 draft-ietf-simple-message-sessions-02
Moved all content type negotiation from the "m"-line format list Moved all content type negotiation from the "m"-line format list
into "a"-line attributes. Added the accept-types attribute. This into "a"-line attributes. Added the accept-types attribute. This
is due to the fact that the sdp format-list syntax is not is due to the fact that the sdp format-list syntax is not
conducive to encoding MIME content types values. conducive to encoding MIME content types values.
Added "other-method" construction to the message syntax to allow Added "other-method" construction to the message syntax to allow
for extensible methods. for extensible methods.
Consolidated all syntax definitions into the same section. Cleaned Consolidated all syntax definitions into the same section. Cleaned
up ABNF for digest challenge and response syntax. up ABNF for digest challenge and response syntax.
Changed the session inactivity timeout to 12 minutes. Changed the session inactivity timeout to 12 minutes.
Required support for the SHA1 alogorithm. Required support for the SHA1 alogorithm.
Required support for the message/cpim format. Required support for the message/cpim format.
Fixed lots of editorial issues. Fixed lots of editorial issues.
Documented a number of open issues from recent list discussions. Documented a number of open issues from recent list discussions.
11.3 draft-ietf-simple-message-sessions-01 11.4 draft-ietf-simple-message-sessions-01
Abstract rewritten. Abstract rewritten.
Added architectural considerations section. Added architectural considerations section.
The m-line format list now only describes the root body part for a The m-line format list now only describes the root body part for a
request. Contained body part types may be described in the request. Contained body part types may be described in the
"accept-wrapped-types" a-line attribute. "accept-wrapped-types" a-line attribute.
Added a standard dummy value for the m-line port field. Clarified Added a standard dummy value for the m-line port field. Clarified
that a zero in this field has normal SDP meaning. that a zero in this field has normal SDP meaning.
Clarified that an endpoint is globally configured as to whether or Clarified that an endpoint is globally configured as to whether or
not to use a relay. There is no relay discovery mechanism not to use a relay. There is no relay discovery mechanism
intrinsic to MSRP. intrinsic to MSRP.
Changed digest algorithm to SHA1. Added TR-ID and S-URI to the Changed digest algorithm to SHA1. Added TR-ID and S-URI to the
hash for digest authentication. hash for digest authentication.
CMS usage replaced with S/MIME. CMS usage replaced with S/MIME.
TLS and MSRPS usage clarified. TLS and MSRPS usage clarified.
Session state timeout is now based on SEND activity, rather than Session state timeout is now based on SEND activity, rather than
BIND and VISIT refreshes. BIND and VISIT refreshes.
Default port added. Default port added.
Added sequence diagrams to the example message flows. Added sequence diagrams to the example message flows.
Added discussion of self-signed certificates in the security Added discussion of self-signed certificates in the security
considerations section. considerations section.
11.4 draft-ietf-simple-message-sessions-00 11.5 draft-ietf-simple-message-sessions-00
Name changed to reflect status as a work group item. Name changed to reflect status as a work group item.
This version no longer supports the use of multiple sessions This version no longer supports the use of multiple sessions
across a single TCP session. This has several related changes: across a single TCP session. This has several related changes:
There is now a single session URI, rather than a separate one for 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 each endpoint. The session URI is not required to be in requests
other than BIND and VISIT, as the session can be determined based other than BIND and VISIT, as the session can be determined based
on the connection on which it arrives. on the connection on which it arrives.
BIND and VISIT now create soft state, eliminating the need for the BIND and VISIT now create soft state, eliminating the need for the
RELEASE and LEAVE methods. RELEASE and LEAVE methods.
skipping to change at page 34, line 36 skipping to change at page 33, line 45
Format list negotiation expanded to allow a "prefer these formats Format list negotiation expanded to allow a "prefer these formats
but try anything" semantic but try anything" semantic
Clarified handling of direction notification failures. Clarified handling of direction notification failures.
Clarified signaling associated with session failure due to dropped Clarified signaling associated with session failure due to dropped
connections. connections.
Clarified security related motivations for MSRP. Clarified security related motivations for MSRP.
Removed MIKEY dependency for session key exchange. Simple usage of Removed MIKEY dependency for session key exchange. Simple usage of
k-lines in SDP, where the SDP exchange is protected end-to-end k-lines in SDP, where the SDP exchange is protected end-to-end
seems sufficient. seems sufficient.
11.5 draft-campbell-simple-im-sessions-01 11.6 draft-campbell-simple-im-sessions-01
Version 01 is a significant re-write. References to COMEDIA were Version 01 is a significant re-write. References to COMEDIA were
removed, as it was determined that COMEDIA would not allow removed, as it was determined that COMEDIA would not allow
connections to be used bidirectional in the presence of NATs. connections to be used bidirectional in the presence of NATs.
Significantly more discussion of a concrete mechanism has been added Significantly more discussion of a concrete mechanism has been added
to make up for no longer using COMEDIA. Additionally, this draft and to make up for no longer using COMEDIA. Additionally, this draft and
draft-campbell-cpimmsg-sessions (which would have also changed draft-campbell-cpimmsg-sessions (which would have also changed
drastically) have now been combined into this single draft. drastically) have now been combined into this single draft.
12. Contributors 12. Contributors
The following people contributed substantially to this ongoing The following people contributed substantially to this ongoing
effort: effort:
Rohan Mahy Allison Mankin Jon Peterson Brian Rosen Dean Willis Adam Roach
Rohan Mahy Cullen Jennings Aki Niemi Hisham Khartabil Pekka Pessi Chris Boulton
Allison Mankin
Jon Peterson
Brian Rosen
Dean Willis
Adam Roach
Cullen Jennings
Aki Niemi
Hisham Khartabil
Pekka Pessi
Chris Boulton
Normative References Normative References
[1] Handley, M. and V. Jacobson, "SDP: Session Description [1] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/