draft-ietf-simple-message-sessions-02.txt   draft-ietf-simple-message-sessions-03.txt 
SIMPLE Working Group B. Campbell SIMPLE Working Group B. Campbell
Internet-Draft J. Rosenberg Internet-Draft J. Rosenberg
Expires: April 22, 2004 R. Sparks Expires: July 27, 2004 R. Sparks
dynamicsoft dynamicsoft
P. Kyzivat P. Kyzivat
Cisco Systems Cisco Systems
October 23, 2003 January 27, 2004
The Message Session Relay Protocol The Message Session Relay Protocol
draft-ietf-simple-message-sessions-02 draft-ietf-simple-message-sessions-03
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 April 22, 2004. This Internet-Draft will expire on July 27, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). 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
Protocol (SDP) offer/answer model carried by a signaling protocol Protocol (SDP) offer/answer model carried by a signaling protocol
such as the Session Initiation Protocol (SIP). such as the Session Initiation Protocol (SIP).
MSRP supports end-to-end Instant Message Sessions, as well as
sessions traversing one or two relays.
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 Use of Relays . . . . . . . . . . . . . . . . . . . . . . . 8 5.1 Transferring Large Content . . . . . . . . . . . . . . . . 7
5.2 Transferring Large Content . . . . . . . . . . . . . . . . . 8 6. SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . 7
5.3 Connection Sharing . . . . . . . . . . . . . . . . . . . . . 9 6.1 Use of the SDP M-line . . . . . . . . . . . . . . . . . . 8
6. SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . . 10 6.2 The Direction Attribute . . . . . . . . . . . . . . . . . 8
6.1 Use of the SDP M-line . . . . . . . . . . . . . . . . . . . 10 6.3 The Accept Types Attribute . . . . . . . . . . . . . . . . 10
6.2 The Direction Attribute . . . . . . . . . . . . . . . . . . 11 6.4 MIME Wrappers . . . . . . . . . . . . . . . . . . . . . . 10
6.3 The Accept Types Attribute . . . . . . . . . . . . . . . . . 12 6.5 URL Negotiations . . . . . . . . . . . . . . . . . . . . . 11
6.4 MIME Wrappers . . . . . . . . . . . . . . . . . . . . . . . 13 6.6 Updated SDP Offers . . . . . . . . . . . . . . . . . . . . 12
6.5 URL Negotiations . . . . . . . . . . . . . . . . . . . . . . 13 6.7 Example SDP Exchange . . . . . . . . . . . . . . . . . . . 13
6.6 Example SDP Exchange . . . . . . . . . . . . . . . . . . . . 14 7. The Message Session Relay Protocol . . . . . . . . . . . . 13
7. The Message Session Relay Protocol . . . . . . . . . . . . . 15 7.1 MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1 MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 14
7.1.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . . 16 7.1.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 15
7.1.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . . 16 7.1.3 The msrps URL Scheme . . . . . . . . . . . . . . . . . . . 16
7.1.3 The msrps URL Scheme . . . . . . . . . . . . . . . . . . . . 17 7.2 MSRP messages . . . . . . . . . . . . . . . . . . . . . . 16
7.2 MSRP messages . . . . . . . . . . . . . . . . . . . . . . . 17 7.3 MSRP Transactions . . . . . . . . . . . . . . . . . . . . 17
7.3 MSRP Transactions . . . . . . . . . . . . . . . . . . . . . 19 7.4 MSRP Sessions . . . . . . . . . . . . . . . . . . . . . . 17
7.4 MSRP Sessions . . . . . . . . . . . . . . . . . . . . . . . 19 7.4.1 Initiating an MSRP session . . . . . . . . . . . . . . . . 17
7.4.1 Initiating an MSRP session . . . . . . . . . . . . . . . . . 19 7.4.2 Handling VISIT requests . . . . . . . . . . . . . . . . . 21
7.4.2 Handling VISIT requests . . . . . . . . . . . . . . . . . . 23 7.4.3 Sending Instant Messages on a Session . . . . . . . . . . 21
7.4.3 Sending Instant Messages on a Session . . . . . . . . . . . 23 7.4.4 Ending a Session . . . . . . . . . . . . . . . . . . . . . 22
7.4.4 Ending a Session . . . . . . . . . . . . . . . . . . . . . . 25 7.4.5 Managing Session State and Connections . . . . . . . . . . 23
7.4.5 Session Inactivity Timer . . . . . . . . . . . . . . . . . . 26 7.5 Method Descriptions . . . . . . . . . . . . . . . . . . . 24
7.4.6 Managing Session State and Connections . . . . . . . . . . . 27 7.5.1 SEND . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.5 MSRP Relays . . . . . . . . . . . . . . . . . . . . . . . . 27 7.5.2 VISIT . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.5.1 Establishing Session State at a Relay . . . . . . . . . . . 28 7.6 Response Code Descriptions . . . . . . . . . . . . . . . . 24
7.5.2 Removing Session State from a relay . . . . . . . . . . . . 29 7.6.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.5.3 Sending IMs across an MSRP relay . . . . . . . . . . . . . . 30 7.6.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.5.4 Relay Pairs . . . . . . . . . . . . . . . . . . . . . . . . 30 7.6.3 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.5.5 Relay Shutdown . . . . . . . . . . . . . . . . . . . . . . . 31 7.6.4 426 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.6 Digest Authentication . . . . . . . . . . . . . . . . . . . 31 7.6.5 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.6.1 The SHA1 Algorithm . . . . . . . . . . . . . . . . . . . . . 33 7.6.6 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.7 Method Descriptions . . . . . . . . . . . . . . . . . . . . 33 7.7 Header Field Descriptions . . . . . . . . . . . . . . . . 25
7.7.1 BIND . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.7.1 TR-ID . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.7.2 SEND . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.7.2 Content-Type . . . . . . . . . . . . . . . . . . . . . . . 25
7.7.3 VISIT . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.7.3 S-URL . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.8 Response Code Descriptions . . . . . . . . . . . . . . . . . 34 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.8.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 9. IANA Considerations . . . . . . . . . . . . . . . . . . . 28
7.8.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 28
7.8.3 401 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.2 MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . . 28
7.8.4 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.8.5 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.2.2 Character Encoding . . . . . . . . . . . . . . . . . . . . 28
7.8.6 426 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.2.3 Intended Usage . . . . . . . . . . . . . . . . . . . . . . 28
7.8.7 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.2.4 Protocols . . . . . . . . . . . . . . . . . . . . . . . . 28
7.8.8 500 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.2.5 Security Considerations . . . . . . . . . . . . . . . . . 29
7.8.9 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.2.6 Relevant Publications . . . . . . . . . . . . . . . . . . 29
7.9 Header Field Descriptions . . . . . . . . . . . . . . . . . 36 9.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 29
7.9.1 TR-ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 9.3.1 Direction . . . . . . . . . . . . . . . . . . . . . . . . 29
7.9.2 Exp . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 9.3.2 Accept Types . . . . . . . . . . . . . . . . . . . . . . . 29
7.9.3 CAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 9.3.3 Wrapped Types . . . . . . . . . . . . . . . . . . . . . . 29
7.9.4 SChal . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10. Security Considerations . . . . . . . . . . . . . . . . . 29
7.9.5 Content-Type . . . . . . . . . . . . . . . . . . . . . . . . 37 10.1 TLS and the MSRPS Scheme . . . . . . . . . . . . . . . . . 30
7.9.6 S-URL . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.1.1 Sensitivity of the Session URL . . . . . . . . . . . . . . 30
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.1.2 End to End Protection of IMs . . . . . . . . . . . . . . . 31
8.1 No Relay . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.1.3 CPIM compatibility . . . . . . . . . . . . . . . . . . . . 31
8.2 Single Relay . . . . . . . . . . . . . . . . . . . . . . . . 40 10.1.4 PKI Considerations . . . . . . . . . . . . . . . . . . . . 32
8.3 Two Relays . . . . . . . . . . . . . . . . . . . . . . . . . 43 11. Changes from Previous Draft Versions . . . . . . . . . . . 32
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 46 11.1 draft-ietf-simple-message-sessions-03 . . . . . . . . . . 32
9.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . . 46 11.2 draft-ietf-simple-message-sessions-02 . . . . . . . . . . 33
9.2 MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . . . 47 11.3 draft-ietf-simple-message-sessions-01 . . . . . . . . . . 33
9.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 11.4 draft-ietf-simple-message-sessions-00 . . . . . . . . . . 34
9.2.2 Character Encoding . . . . . . . . . . . . . . . . . . . . . 47 11.5 draft-campbell-simple-im-sessions-01 . . . . . . . . . . . 34
9.2.3 Intended Usage . . . . . . . . . . . . . . . . . . . . . . . 47 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . 34
9.2.4 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . 47 Normative References . . . . . . . . . . . . . . . . . . . 35
9.2.5 Security Considerations . . . . . . . . . . . . . . . . . . 47 Informational References . . . . . . . . . . . . . . . . . 35
9.2.6 Relevant Publications . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 36
9.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . 47 Intellectual Property and Copyright Statements . . . . . . 38
9.3.1 Direction . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.3.2 Accept Types . . . . . . . . . . . . . . . . . . . . . . . . 48
9.3.3 Wrapped Types . . . . . . . . . . . . . . . . . . . . . . . 48
10. Security Considerations . . . . . . . . . . . . . . . . . . 48
10.1 TLS and the MSRPS Scheme . . . . . . . . . . . . . . . . . . 48
10.2 Sensitivity of the Session URL . . . . . . . . . . . . . . . 49
10.3 End to End Protection of IMs . . . . . . . . . . . . . . . . 50
10.4 CPIM compatibility . . . . . . . . . . . . . . . . . . . . . 50
10.5 PKI Considerations . . . . . . . . . . . . . . . . . . . . . 50
11. Changes from Previous Draft Versions . . . . . . . . . . . . 51
11.1 draft-ietf-simple-message-sessions-02 . . . . . . . . . . . 51
11.2 draft-ietf-simple-message-sessions-01 . . . . . . . . . . . 51
11.3 draft-ietf-simple-message-sessions-00 . . . . . . . . . . . 52
11.4 draft-campbell-simple-im-sessions-01 . . . . . . . . . . . . 52
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53
Normative References . . . . . . . . . . . . . . . . . . . . 53
Informational References . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55
Intellectual Property and Copyright Statements . . . . . . . 56
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 5, line 43 skipping to change at page 5, line 43
Messaging sessions can also reduce the overhead in each individual Messaging sessions can also reduce the overhead in each individual
message. In page-mode, each message needs to include all of the SIP message. In page-mode, each message needs to include all of the SIP
headers that are mandated by RFC 3261 [2]. However, many of these headers that are mandated by RFC 3261 [2]. However, many of these
headers are not needed once a context is established for exchanging headers are not needed once a context is established for exchanging
messages. As a result, messaging session mechanisms can be designed messages. As a result, messaging session mechanisms can be designed
with significantly less overhead. with significantly less overhead.
3. Scope of this Document 3. Scope of this Document
This document describes the use of MSRP between endpoints, or via one This document describes the use of MSRP between endpoints. It does
or two relays, where endpoints have advance knowledge of the relays. not specify the use of intermediaries, nor does it prohibit such use.
It does not provide a mechanism for endpoints to determine whether a We expect an extension to this specification to define MSRP
relay is needed, or for endpoints to discover the presence of relays. intermediaries and their use.
This document describes the use of MSRP over TCP. MSRP may be used This document describes the use of MSRP over TCP. MSRP may be used
over other congestion-controlled protocols such as SCTP. However, the over other congestion-controlled protocols such as SCTP. However, the
specific bindings for other such protocols are outside the scope of specific bindings for other such protocols are outside the scope of
this document. this document.
4. Protocol Overview 4. Protocol Overview
The Message Session Relay Protocol (MSRP) provides a mechanism for The Message Session Relay Protocol (MSRP) provides a mechanism for
transporting session-mode messages between endpoints. MSRP also transporting session-mode messages between endpoints. MSRP uses
contains primitives to allow the use of one or two relay devices. connection oriented, reliable network transport protocols only. It
MSRP uses connection oriented, reliable network transport protocols can operate in the presence of many NAT and firewall environments, as
only. It is intrinsically NAT and firewall friendly, as it allows it allows participants to positively associate message sessions with
participants to positively associate message sessions with specific specific connections, and does not depend upon connection source
connections, and does not depend upon connection source address, address, which may be obscured by NATs.
which may be obscured by NATs.
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
opposite endpoint, or to a relay that was selected by the opposite host endpoint.
endpoint.
BIND: Used by an endpoint to establish a session at a relay, and
allow the opposite endpoint to visit that relay.
The simplest use case for MSRP is a session that goes directly Assume A is an endpoint that wishes to establish a message session,
between endpoints, with no intermediaries involved. Assume A is an and B is the endpoint invited by A. A invites B to participate in a
endpoint that wishes to establish a message session, and B is the message session by sending a URL that represents the session. This
endpoint invited by A. A invites B to participate in a message URL is temporary, and must not duplicate the URL used for any other
session by sending a URL that represents the session. This URL is active sessions.
temporary, and must not duplicate the URL used for any other active
sessions.
B "visits" A by connecting to A and sending a VISIT request 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, informing
A that B has accepted the session. A and B may now exchange messages A that B has accepted the session. A and B may now exchange messages
using SEND requests on the connection. using SEND requests on the connection.
When either party wishes to end the session, it informs the peer When either party wishes to end the session, it informs its peer with
party with a SIP BYE request. A terminates the session by a SIP BYE request. A terminates the session by invalidating
invalidating associated state, and dropping the connection. associated state, and dropping the connection.
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)
A->B (MSRP): 200 OK A->B (MSRP): 200 OK
B->A (SDP): answer(msrp://A/123) B->A (SDP): answer(msrp://A/123)
A->B (MSRP): SEND A->B (MSRP): SEND
B->A (MSRP): 200 OK B->A (MSRP): 200 OK
B->A (MSRP): SEND B->A (MSRP): SEND
A->B (MSRP): 200 OK A->B (MSRP): 200 OK
The session state has an associated inactivity timer. This timer is
initialized when a successful VISIT request occurs, and is reset each
time either endpoint sends a SEND request. If this timer expires
without being reset, the hosting device invalidates the session state
and terminates all associated connections. Endpoints that are
otherwise idle may keep a session active by periodically sending SEND
requests with no content.
A slightly more complicated case involves a single relay, known about
in advance by one of the parties. The endpoint that has the
preexisting relationship with the relay uses the BIND method to
establish session state in the relay. The relay returns a temporary
URL, that identifies the session. For endpoints A and B, and relay R,
the flow would look like the following:
A->R: MSRP: BIND(msrp://r)
R->A: MSRP: 200 OK (msrp://r/4uye)
A->B (SDP): offer (msrp://r/4uye)
B->R (MSRP): VISIT (msrp://r/4uye)
R->B (MSRP): 200 OK
B->A (SDP): answer(msrp://r/4uye)
A->R (MSRP): SEND
R->B (MSRP): SEND
B->R (MSRP): 200 OK
R->A (MSRP): 200 OK
B->R (MSRP): SEND
R->A (MSRP): SEND
A->R (MSRP): 200 OK
R->B (MSRP): 200 OK
The BIND request contains an expiration time. If a successful VISIT
request does not occur prior to the expiration, the relay will
destroy the session. Additionally, when tearing down a session, the
host endpoint invalidates the session state by issuing a BIND request
with an expiration value of zero.
5. Architectural Considerations 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 Use of Relays 5.1 Transferring Large Content
The primary motivation for relay support in MSRP is to deal with
situations where, due to issues of network topologies, neither
endpoint is able to receive an inbound TCP connection from the other.
For example, both endpoints may be behind separate firewalls that
only allow outbound connections. Relays may also be needed for policy
enforcement. For example, parts of the financial industry require the
logging of all communication.
However, the use of such relays has a significant impact on the
scalability of MSRP. Each relay will require two TCP connections for
each session in use, as well as memory for local session state
storage. Most general purpose platforms on which one might implement
MSRP relays will have relatively low limits on the number of
simultaneous TCP connections they can handle.
Therefore relays SHOULD NOT be used indiscriminately. In the absence
of strong reasons to use relays, MSRP endpoints SHOULD be configured
to set up point-to-point sessions.
MSRP supports the use of two relays, where each endpoint has a relay
acting on its behalf. However, most of the network topology issues
mentioned above can work with a single relay, if that relay is
reachable by both endpoints. Dual relays are only needed for cases of
very strict firewall policy, such as when only specific hosts are
allowed to connect to the outside world; or situations requiring
strict policy enforcement at both endpoint domains. If a given usage
scenario can be solved with a single relay, then a second relay
SHOULD NOT be used.
In spite of these recommendations, relays serve a real purpose in
that they increase the likelihood of two arbitrary endpoints being
able to talk to one another. Therefore if a provider deploys MSRP
endpoints in a network configuration that prevents them from
receiving TCP connections from arbitrary peers, and does not wish to
explicitly prevent MSRP communication with the outside world, then
the provider SHOULD provide its endpoints with the use of an MSRP
relay that is reachable from arbitrary peers.
5.2 Transferring Large Content
MSRP endpoints may attempt to send very long messages in a session. MSRP endpoints may attempt to send very long messages in a session.
For example, most commercial instant messaging systems have a file For example, most commercial instant messaging systems have a file
transfer feature. Since MSRP does not impose message size limits, transfer feature. Since MSRP does not impose message size limits,
there is nothing to prevent endpoints from transferring files over there is nothing to prevent endpoints from transferring files over
it. it.
An analysis of whether it makes sense to do this, rather than sending An analysis of whether it makes sense to do this, rather than sending
such content over FTP, HTTP, or some other such protocol, is beyond such content over FTP, HTTP, or some other such protocol, is beyond
the scope of this document. However, implementers should be aware of the scope of this document. However, implementers should be aware of
skipping to change at page 9, line 29 skipping to change at page 7, line 42
before it is complete. For the sake of efficiency, the framing before it is complete. For the sake of efficiency, the framing
mechanism in MSRP is very simple. There is no clean way to recover mechanism in MSRP is very simple. There is no clean way to recover
framing if the complete message is not sent. framing if the complete message is not sent.
These issues can be mitigated greatly if the endpoint simply These issues can be mitigated greatly if the endpoint simply
establishes a separate session for the transfer. This allows the establishes a separate session for the transfer. This allows the
transfer to be sent without interfering with any instant messages transfer to be sent without interfering with any instant messages
being sent on other sessions. Further, the endpoint can abort the being sent on other sessions. Further, the endpoint can abort the
transfer by simply tearing down the transfer session. Therefore, if a transfer by simply tearing down the transfer session. Therefore, if a
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. dedicated session for that purpose. It should also indicate that the
dedicated session is send only, so that the receiving endpoint does
Open Issue: Do we need a mechanism to communicate the purpose of not attempt to send content back along the same session.
the session? It has been mentioned that the peer may not realize
the purpose of the session, and start using it for normal
messaging. Also, there has been discussion that we need a stronger
mechanism to avoid transaction timeouts caused by long requests.
5.3 Connection Sharing
The SIMPLE working group spent quite a bit of effort in the
consideration of shared TCP connections. Connection sharing would
offer value whenever a large number of message sessions cross the
same two adjacent devices. This situation is likely to occur in the
two relay model. It may also occur in the point-to-point model if the
endpoints are multiuser devices, as is likely with web-hosted
messaging services.
Unfortunately, such connection sharing in TCP created significant
problems. The biggest problem is it introduced a head-of-line
blocking problem that spanned sessions. For example, if two different
pairs of users had sessions that crossed the same shared connection,
a large message sent on one session would block transfer of messages
on the other session. The working group considered this an
unacceptable property of shared connections. One possible solution
was to put limits on message size, and possibly add mechanisms to
allow breaking messages into many chunks. However, these solutions
promised to add a great deal of complexity to the protocol, so the
work group chose not to go that route.
It may be possible to relax this requirement using other transport
protocols, such as SCTP. The lack of connection sharing in this
document should not be construed to prohibit shared connections on
other such protocols. However, such specification is beyond the scope
of this document.
6. SDP Offer-Answer Exchanges for MSRP Sessions 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. MSRP borrows the idea of the direction attributes from
COMEDIA [18], but does not depend on that specification. 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
used, and SHOULD be set to 9999. An exception is when the port field used, and MAY be set to any value chosen by the endpoint. A port
value is set to zero, according to normal SDP usage. field value of zero has the standard SDP meaning. Non-zero values
MUST not be repeated in other MSRP m-lines in the same SDP document.
The proto field MUST designate the message session mechanism and The proto field MUST designate the message session mechanism and
transport protocol, separated by a "/" character. For MSRP, left part transport protocol, separated by a "/" character. For MSRP, left part
of this value MUST be "msrp". For MSRP over TCP, the right part of of this value MUST be "msrp". For MSRP over TCP, the right part of
this field MUST take the value "tcp". For MSRP over other transport this field MUST take the value "tcp". For MSRP over other transport
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 normally used to determine the The port field in the M-line is not used to determine the port to
port to which to connect. Rather, the actual port is determined by which to connect. Rather, the actual port is determined by the
the contents of the session URL (Section 7.1). However, a port value contents of the session URL (Section 7.1). However, a port value of
of zero has the normal SDP meaning. 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 Direction Attribute
Since MSRP uses connection oriented transport protocols, one goal of Since MSRP uses connection oriented transport protocols, one goal of
the SDP negotiation is to determine which participant initiates the the SDP negotiation is to determine which participant initiates the
transport connection. The direction attribute advertises whether the transport connection. The direction attribute advertises whether the
offerer or answerer wishes to initiate the connection, wishes the offerer or answerer wishes to initiate the connection, wishes the
peer endpoint to initiate the connection, or doesn't care. peer endpoint to initiate the connection, or doesn't care.
The endpoint that accepts the connection, or has a relay accept the The endpoint that accepts the connection is said to "host" the
connection on its behalf, is said to "host" the session, and is known session, and is known as the hosting endpoint. The endpoint that
as the hosting endpoint. The endpoint that initiates the connection initiates the connection is said to "visit" the session, and is known
is said to "visit" the session, and is known as the visiting as the visiting endpoint.
endpoint.
The direction attribute is included in an SDP a-line, with a value The direction attribute is included in an SDP a-line, with a value
taking the following syntax: taking the following syntax:
direction = direction-label ":" role direction = direction-label ":" role
direction-label = "direction" direction-label = "direction"
role = active / passive / both role = active / passive / both
active = "active" active = "active" sp count
passive = "passive" passive = "passive" sp count
both = "both" [sp timeout] both = "both" sp count [sp timeout]
count = 1*DIGIT ; Connection count
timeout = 1*DIGIT ; timeout value in seconds timeout = 1*DIGIT ; timeout value in seconds
The values for the role field are as follows: The values for the role field are as follows:
passive: The endpoint wishes to host the session passive: The endpoint wishes to host the session
active: The endpoint wishes the peer 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: The endpoint is willing to act as either host or visitor. If
"both" is selected, it may contain an optional timeout value. This "both" is selected, it may contain an optional timeout value. This
timeout specifies how much time the answerer should wait before timeout specifies how much time the answerer should wait before
giving up on a connection and attempting to take over as host giving up on a connection and attempting to take over as host
device. If the timeout value is not specified, it defaults to 30 device. If the timeout value is not specified, it defaults to 30
seconds. seconds.
The SDP offer for an MSRP session MUST contain a direction attribute, 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 which MAY take any of the defined values. If the offerer is capable
of hosting the session, or can arrange for a relay to host the of hosting the session, then it SHOULD select "both". The endpoint
session on its behalf, then it SHOULD select "both". The endpoint
SHOULD NOT select "active" unless it cannot host the session under SHOULD NOT select "active" unless it cannot host the session under
any circumstances. The endpoint SHOULD NOT select "passive" unless it any circumstances. The endpoint SHOULD NOT select "passive" unless it
has no option but to host the session. 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 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 choices are limited based on the value in the offer. If the offer
contained "active", then the answerer MUST either select "passive" or contained "active", then the answerer MUST either select "passive" or
reject the offer. Likewise, if the offer contained "passive", then reject the offer. Likewise, if the offer contained "passive", then
the answerer MUST select "active" or reject the offer. If the offer the answerer MUST select "active" or reject the offer. If the offer
contained "both", the answerer SHOULD select "active", but MAY select contained "both", the answerer SHOULD select "active", but MAY select
"passive" if it is unable to reach the host device, or if local "passive" if it is unable to reach the host device, or if local
policy requires it to act as host. 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 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)
skipping to change at page 13, line 19 skipping to change at page 11, line 7
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 14, line 19 skipping to change at page 12, line 8
The visitor will use the session URL established by the host both to The visitor will use the session URL established by the host both to
resolve the host address and port, and to identify the session when resolve the host address and port, and to identify the session when
connecting. For MSRP sessions, the address field in the C-line is not connecting. For MSRP sessions, the address field in the C-line is not
relevant, and MUST be ignored. The port field in the M-line MUST be 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 normal meaning for SDP.
The following example shows an SDP offer with a session URL of The following example shows an SDP offer with a session URL of
"msrp://example.com:7394/2s93i" "msrp://example.com:7394/2s93i"
c=IN IP4 useless.host.name v=0
o=someuser 2890844526 2890844527 IN IP4 alice.example.com
s=
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 a=direction:both 0
a=session:msrp://example.com:7394/2s93i a=session:msrp://example.com:7394/2s93i
The session URL MUST be a temporary URL assigned just for this The session URL MUST be a temporary URL assigned just for this
particular session. It MUST NOT duplicate any URL in use for any particular session. It MUST NOT duplicate any URL in use for any
other session hosted by the endpoint or relay. Further, since the other session hosted by the endpoint. Further, since the peer
peer endpoint will use the session URL to identify itself when endpoint will use the session URL to identify itself when connecting,
connecting, it SHOULD be hard to guess, and protected from it SHOULD be hard to guess, and protected from eavesdroppers. This
eavesdroppers. This will be discussed in more detail in Section 10. will be discussed in more detail in Section 10.
6.6 Example SDP Exchange 6.6 Updated SDP Offers
MSRP endpoints may sometimes need to send additional SDP exchanges
for an existing session. For example, they may need to negotiate a
new connection because of a TCP failure or some other reason. They
may need to send periodic exchanges with no change to refresh state
in the network, for example, SIP timers. They may need to change some
other stream in a session without affecting the MSRP stream, or they
may need to change an MSRP stream without affecting some other
stream.
Once MSRP endpoints have completed an intitial negotiation, further
exchanges do not change their roles as the active or passive party
for that particular stream. This means that if the visitor sends a
new SDP offer, it MUST remain the visitor, i.e. it MUST offer a
direction of "active" and it MUST NOT include an MSRP URL. Likewise,
if the host sends a new offer, it MUST include a direction of
"passive" and it MUST include a URL. Updated offers MUST NOT include
a direction of "both."
If offering party wishes to establish a new connection as a result of
the updated exchange, it MUST increment the count parameter in the
direction attribute from that of the most recent successful exchange.
If the passive endpoint wishes the the visitor to re-connect, it the
included URL MUST be different than the URL from previous offers.
This new URL MAY be completely different from the original and MAY
even resolve to a different location. If the active party sends a new
offer with an incremented count parameter, the passive party MUST
supply a new URL, or reject the offer. If either party sends a new
offer with the same count value as the previous exchange, the session
URI MUST NOT change.
If this negotiation results in a new session URL, the active party
MUST close the existing connection, open a new connection, and send a
VISIT request as described below.
If either party wish to send an SDP document that changes nothing at
all, then it MUST have the same o-line version as in the previous
exchange.
6.7 Example SDP Exchange
Endpoint A wishes to invite Endpoint B to a MSRP session. A offers 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 containing the following lines:
v=0
o=usera 2890844526 2890844527 IN IP4 alice.example.com
s=
c=IN IP4 alice.example.com c=IN IP4 alice.example.com
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 a=direction:both 0
a=session: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 chooses to participate in the role of visitor, opens a TCP
connection to alice.example.com:7394, and successfully performs a connection to alice.example.com:7394, and successfully performs a
VISIT transaction passing the URL of msrp://alice.example.com:7394/ VISIT transaction passing the URL of msrp://alice.example.com:7394/
2s93i9. B indicates that it has accomplished this by answering with: 2s93i9. B indicates that it has accomplished this by answering with:
v=0
o=userb 2890844530 2890844532 IN IP4 bob.example.com
s=
c=IN IP4 dontlookhere c=IN IP4 dontlookhere
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 a=direction:active 0
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 on the same
connection on which B sent the VISIT request. connection on which B sent the VISIT request.
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.
skipping to change at page 15, line 40 skipping to change at page 14, line 30
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 the hosting device of an MSRP
session. If the server part contains a numeric IP address, it MUST session. If the server part contains a numeric IP address, it MUST
also contain a port. The resource part identifies a particular also contain a port. The resource part identifies a particular
session at that host device. The absence of the resource part session at that host device. The absence of the resource part
indicates a reference to an MSRP host device, but does not indicates a reference to an MSRP host device, but does not
specifically refer to a particular session resource. specifically refer to a 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 SHOULD NOT be considered a default, as the URL process This value is not a default, as the URL process described herein will
described herein will always explicitly resolve a port number. always explicitly resolve a port number. However, the URLs SHOULD be
However, the URLs SHOULD be configured so that the recommended port configured so that the recommended port is used whenever appropriate.
is used whenever appropriate. This makes life easier for network This makes life easier for network administrators who need to manage
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.
Note that this is not the same thing as identifying the session Note that this is not the same thing as identifying the session
itself. If a userinfo component exists, MUST be constructed only from itself. If a userinfo component exists, MUST be constructed only from
"unreserved" characters, to avoid a need for escape processing. "unreserved" characters, to avoid a need for escape processing.
Escaping MUST NOT be used in an MSRP URL. Furthermore, a userinfo Escaping MUST NOT be used in an MSRP URL. Furthermore, a userinfo
part MUST NOT contain password information. part MUST NOT contain password information.
The following is an example of a typical MSRP URL: The following is an example of a typical MSRP URL:
skipping to change at page 17, line 21 skipping to change at page 16, line 8
entry SHOULD be chosen for the initial connection attempt. This entry SHOULD be chosen for the initial connection attempt. This
allows any ordering created in the DNS to be preserved. allows any ordering created in the DNS to be preserved.
5. If the connection attempt fails, the device SHOULD attempt to 5. If the connection attempt fails, the device SHOULD attempt to
connect to the addresses returned in any additional A or AAAA connect to the addresses returned in any additional A or AAAA
records, in the order the records were presented. If all of these records, in the order the records were presented. If all of these
fail, the device SHOULD attempt to use any additional SRV records fail, the device SHOULD attempt to use any additional SRV records
that may have been returned, following the normal rules for SRV that may have been returned, following the normal rules for SRV
record selection. record selection.
Note that in most cases, the transport protocol will be determined In most cases, the transport protocol will be determined separately
separately from the resolution process. For example, if the MSRP URL from the resolution process. For example, if the MSRP URL was
was communicated in an SDP offer or answer, the SDP M-line will communicated in an SDP offer or answer, the SDP M-line will contain
contain the transport protocol. When an MSRP URL is communicated the transport protocol. When an MSRP URL is communicated outside of
outside of SDP, the protocol SHOULD also be communicated. For SDP, the protocol SHOULD also be communicated. If a device needs to
example, a client may be configured to use a particular relay that is resolve an MSRP URL and does not know the protocol, it SHOULD assume
referenced with an MSRP URL. The client MUST also be told what TCP.
protocol to use. If a device needs to resolve an MSRP URL and does
not know the protocol, it SHOULD assume TCP.
7.1.3 The msrps URL Scheme 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 MSRP messages
skipping to change at page 18, line 5 skipping to change at page 16, line 39
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
response-start = "MSRP" SP length SP Status-Code SP response-start = "MSRP" SP length SP Status-Code SP
Reason CRLF Reason CRLF
length = 1*DIGIT ; the length of the message, length = 1*DIGIT ; the length of the message,
; exclusive of the start line. ; exclusive of the start line.
Method = SEND / BIND / VISIT / other-method Method = SEND / VISIT / other-method
other-method = token other-method = token
header = Client-Authenticate / Server-Challenge / header = Transaction-ID / Session-URL / Content-Types
Transaction-ID / Session-URL/ Content-Type / Expires
Status-Code = 200 ;Success Status-Code = 200 ;Success
/ 400 ;Bad Request / 400 ;Bad Request
/ 401 ;Authentication Required
/ 403 ;Forbidden / 403 ;Forbidden
/ 415 ;Unsupported Content Type / 415 ;Unsupported Content Type
/ 426 ;Upgrade Required / 426 ;Upgrade Required
/ 481 ;No session / 481 ;No session
/ 500 ;Cannot Deliver
/ 506 ;duplicate session / 506 ;duplicate session
Reason = token ; Human readable text describing status Reason = token ; Human readable text describing status
Client-Authenticate = "CAuth" ":" credentials
Server-Challenge = "SChal" ":" challenge
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 Session-URL = "S-URL" ":" msrp_url
Expires = "Exp"":" delta-seconds
delta-seconds = 1*DIGIT ; Integer number of seconds
challenge = digest-scheme SP digest-challenge *("," digest-challenge)
digest-scheme = "Digest"
digest-challenge = nonce / algorithm / auth-param
nonce = "nonce" "=" nonce-value
nonce-value = quoted-string
algorithm = "algorithm" "=" ( "SHA1" / token )
credentials = "Digest" digest-response *("," digest-response)
digest-response = username / nonce / response / algorithm /
auth-param
username = "username" "=" username-value
username-value = quoted-string
response = "response" "=" request-digest
request-digest = <"> 40LHEX <">
LHEX = "0" / "1" / "2" / "3" /
"4" / "5" / "6" / "7" /
"8" / "9" / "a" / "b" /
"c" / "d" / "e" / "f"
All requests and responses MUST contain at least a TR-ID header All requests and responses MUST contain at least a TR-ID header
field. Messages MAY contain other fields, depending on the method or field. Messages MAY contain other fields, depending on the method or
response code. response code.
7.3 MSRP Transactions 7.3 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.
BIND is always hop by hop. VISIT transactions are usually hop-by-hop,
but may be relayed in situations where the visiting endpoint uses a
relay. However, SEND transactions are end-to-end, meaning that under
normal circumstances the response is sent by the peer endpoint, even
if there are intervening relays.
Endpoints MUST select TR-ID header field values 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.4 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 (a
host and a visitor) and may have one or two relays. A session is host and a visitor). A session is identified by an MSRP URL.
identified by an MSRP URL.
7.4.1 Initiating an MSRP session 7.4.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 endpoint in a message
session, it invites the peer to communicate using an SDP offer, session, it invites the peer to communicate using an SDP offer,
carried over SIP or some other protocol supporting the SDP offer/ carried over SIP or some other protocol supporting the SDP offer/
answer model. For the purpose of this document, we will refer to the answer model. For the purpose of this document, we will refer to the
endpoint choosing to initiate communication as the offerer, and the endpoint choosing to initiate communication as the offerer, and the
peer being invited as the answerer. peer being invited as the answerer.
The offerer SHOULD volunteer to act as the hosting endpoint if The offerer SHOULD volunteer to act as the hosting endpoint if
allowed by policy and network topology. An endpoint is said to host a allowed by policy and network topology. The peer that is not the host
session if one of two conditions are true. The host either directly is designated as the visitor. The offerer MAY request the answerer to
listens for a connection from the peer endpoint, and maintains act as host if it is prevented from accepting connections by network
session state itself, or it uses a BIND request to initialize session topology or policy.
state at a relay that will listen for a connection from the peer. The
peer that is not the host is designated as the visitor. The offerer
MAY request the answerer to act as host if it is prevented from
accepting connections by network topology or policy, and is not able
to bind to a relay to act on its behalf.
If the offerer wishes to host the session directly, that is without If the offerer wishes to host the session, it MUST perform the
using a relay, it MUST perform the following steps: following steps:
1. Construct a session MSRP URL . This URL MUST be resolvable to the 1. Construct a session MSRP URL . This URL MUST resolve to the
offerer. The URL SHOULD be temporary, SHOULD be hard to guess, location that the offerer wishes to host the connection. The URL
and MUST not duplicate the URL of any other session currently SHOULD be temporary, SHOULD be hard to guess, and MUST not
hosted by the offerer. 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 maps the session URL to the session attribute, as
described in Section 6.5. described in Section 6.5.
4. Insert a direction attribute. This value SHOULD be "both", 4. Insert a direction attribute. This value SHOULD be "both",
indicating that the offerer will allow the answerer to override indicating that the offerer will allow the answerer to override
the offerer's decision to host. If "both" is selected, the the offerer's decision to host. If "both" is selected, the
offerer SHOULD leave the timeout at the default value (by leaving offerer SHOULD leave the timeout at the default value (by leaving
out the value entirely. However, the offerer MAY select a out the value entirely. However, the offerer MAY select a
different timeout if circumstances warrant it. The direction different timeout if circumstances warrant it. The direction
value MAY be "passive" if the offerer is prevented from allowing value MAY be "passive" if the offerer is prevented from allowing
the answerer override this choice. 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 5. 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 offerer chooses to force the answerer to host the session, it
MUST perform the following steps instead: MUST perform the following steps instead:
1. Construct an SDP offer as described above, but with no session 1. Construct an SDP offer as described above, but with no session
attribute. attribute.
2. Insert a direction attribute with a value of "active". 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 3. Send the offer using normal processing for the signaling
protocol. protocol.
When the answerer receives the SDP offer and chooses to participate When the answerer receives the SDP offer and chooses to participate
in the session, it must choose whether to act as the host or the in the session, it must choose whether to act as the host or the
visitor. A direction attribute value of "both" in the offer indicates visitor. A direction attribute value of "both" in the offer indicates
that the offerer prefers to host, but will allow the answerer to that the offerer prefers to host, but will allow the answerer to
host. In this case the answerer SHOULD act as the visitor, but MAY host. In this case the answerer SHOULD act as the visitor, but MAY
choose to host. A value of "passive" means the offerer insists upon choose to host. A value of "passive" means the offerer insists upon
skipping to change at page 21, line 44 skipping to change at page 19, line 40
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, and the accept-types attribute
contains the SEND payload media types that the answerer is contains the SEND payload media types that the answerer is
willing to accept. The accept-types attribute in the answer 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 MUST be either the same as that of the offer, or it MUST be a
subset. subset.
3. A direction attribute containing the value "active". 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, 6. If the transaction fails, the answerer MAY choose to act as host,
if allowed by the direction attribute of the answer. If the if allowed by the direction attribute of the answer. If the
answerer is unable or unwilling to host, then it should return an answerer is unable or unwilling to host, then it should return an
error response as appropriate for the signaling protocol. error response as appropriate for the signaling protocol.
Some TCP connection failure conditions may ordinarily take some time Some TCP connection failure conditions may ordinarily take some time
to notice. For example, if the offerer is unable to open a TCP to notice. For example, if the offerer is unable to open a TCP
connection to the host device, this connection attempt may take a connection to the host device, this connection attempt may take a
fairly large number of seconds to timeout. This length of time will fairly large number of seconds to timeout. This length of time will
skipping to change at page 22, line 27 skipping to change at page 20, line 24
1. Construct a new session URL . This MUST be a MSRP or MSRPS URL, 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 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 session URL in the offer. The URL SHOULD be temporary, SHOULD be
hard to guess, and MUST not duplicate URLs currently identifying hard to guess, and MUST not duplicate URLs currently identifying
any active sessions hosted by the answerer. any active sessions hosted by the answerer.
2. Listen for a connection from the peer. 2. Listen for a connection from the peer.
3. Construct an SDP answer as described in Section 6, mapping the 3. Construct an SDP answer as described in Section 6, mapping the
new session URL to the session attribute, and inserting a new session URL to the session attribute, insert a direction
direction attribute with the value of "passive". 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 4. Send the SDP offer using the normal processing for the signaling
protocol. protocol.
When the offerer receives the SDP answer, it must determine who will When the offerer receives the SDP answer, it must determine who will
continue to host the session. If the answer contained a direction continue to host the session. If the answer contained a direction
attribute value of "active", the offerer MUST continue as host. If attribute value of "active", the offerer MUST continue as host. If
the offer contained "active" or "both" and the answer contains the offer contained "active" or "both" and the answer contains
"passive", then the offerer MUST allow the answerer to host the "passive", then the offerer MUST allow the answerer to host the
session. session.
skipping to change at page 23, line 17 skipping to change at page 21, line 14
1. A S-URL header field containing the session URL. 1. A S-URL header field containing the session URL.
2. A TR-ID header field containing a unique transaction ID. 2. A TR-ID header field containing a unique transaction ID.
3. A size field containing size of the message subsequent to the 3. A size field containing size of the message subsequent to the
start-line. start-line.
5. Send the request and wait for a response 5. Send the request and wait for a response
6. If the transaction succeeds, set the actual expiration time to 6. If either the connection attempt or the VISIT transaction fail,
the value in the Exp header field in the response, and acknowledge the answer, then initiate the tear-down of the
acknowledge the answer via the signaling protocol. If either the session using the signaling protocol.
connection attempt or the VISIT transaction fail, acknowledge the
answer, then initiate the tear-down of the session using the
signaling protocol.
7.4.2 Handling VISIT requests 7.4.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 URL that matches the
S-URL of the VISIT request. If so, and if no visitor connection S-URL of the VISIT request. If so, and if no visitor connection
has been associated with the session, then return a 200 response, has been associated with the session, then return a 200 response,
skipping to change at page 24, line 15 skipping to change at page 22, line 8
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. 2. Set the TR-ID header field to a unique value.
3. Send the request on the connection associated with the session. 3. Send the request on the connection associated with the session.
4. If a 2xx response code is received, the transaction was 4. If a 2xx response code is received, the transaction was
successful. successful.
5. If a 5xx response code is received, the transaction failed, but 5. If a 415 response is received, this indicates the recipient is
other transactions may still succeed in the future. The endpoint
MAY attempt to send the message content again in a new request,
that is, with a new TR-ID value. If the endpoint receives 5xx
responses more than some threshold number of times in a row, it
SHOULD assume the session has failed, and initiate tear-down via
the signaling protocol. The threshold value is a matter of local
policy.
6. 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.
7. If any other response code is received, the endpoint SHOULD 6. If any other response code is received, or if the transaction
assume the session has failed, and initiate tear-down. times out, the endpoint SHOULD assume the session has failed, and
initiate tear-down, either ending the session, or by sending an
Normally transaction timeouts are treated the same as transactions updated SDP offer proposing a new connection. If a new connection
that receive 5xx responses But, unlike transactions that fail is established, the endpoint MAY choose to resend the content on
explicitly, requests that have been timed out may in fact have the new connection.
been delivered to the peer endpoint, and even presented to the
user. Attempting to resend such messages may result in the peer
user seeing duplicate messages. Therefore a client implementation
should take such action carefully, and should clearly indicate the
situation to the user.
Open Issue: Do we need to create a duplicate suppression Open Issue: Do we need to create a duplicate mechanism to suppress
mechanism? If retries were sent with with the TR-ID, then the duplicate messages when a new connection is established in this
recipient could recognize a duplicate message if it occurs in the fashion? mechanism? List consensus seems to indicate we do. We may
same session. need to specify that the tr-id space spans a sequence of
connections if they are associated with same stream, and of
course, specify what it means for a stream to span connections.
When an endpoint receives a SEND request, it MUST perform the 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. 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 2. If it does, return a 200 response and render the message to the
user. The method of rendering is a matter of local policy. user. The method of rendering is a matter of local policy. If the
message contained no body at all, the endpoint should quietly
ingore it.
3. If it does not understand the media type, return a 415 response. 3. If it does not understand the media type, return a 415 response.
The endpoint MUST NOT return a 415 response for any media type
for which it indicated support in the SDP exchange.
7.4.4 Ending a Session 7.4.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. The MUST release any resources acquired as part of the session.
process for this differs depending on whether the session is hosted
directly by the host, or by a relay.
The host MUST destroy local state for the session. This involves The host MUST destroy local state for the session. This involves
completely removing the state entry for this session and invalidating completely removing the state entry for this session and invalidating
session URL. If the host is using an MSRP relay, it MUST send a BIND session URL.
containing an expires value of zero. This request MUST be sent on the
host connection established by the original BIND request. This BIND
request MUST include the session URL in the S-URL header field.
Since these host actions completely destroy the session state at Since these host actions completely destroy the session state at
the hosting device, the visitor is not required to take further the hosting device, the visitor is not required to take further
action beyond cleaning up any local state. If for some reason the action beyond cleaning up any local state.
host fails to destroy session state, the state will be invalidated
anyway when the inactivity timer expires.
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
its intent to close the session. its intent to close the session.
When an endpoint is signaled of its peer's intent to close a session, When an endpoint is signaled of its peer's intent to close a session,
it SHOULD NOT initiate any more SEND requests. It SHOULD wait for any 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, an terminating with incomplete SEND transactions. When this occurs, the
endpoint SHOULD clearly inform the user that the messages mat not endpoint SHOULD clearly inform the user that the messages may not
have been delivered. have been delivered.
7.4.5 Session Inactivity Timer 7.4.5 Managing Session State and Connections
State associated with MSRP sessions, either at the host endpoint, or
a hosting or visiting relay, is soft-state; that is, it expires over
time if no message activity occurs. Each such device maintains a pair
of inactivity timer, each with an initial value of 12 minutes. One of
these timers is assigned for each endpoint.
All devices use the same, predetermined timer expiration value.
While there might be some utility in negotiating this timer on a
per device basis, such negotiation would add a great deal of
complexity to MSRP. The choice of 12 minutes is somewhat
arbitrary, but is intended to balance the bandwidth overhead
against how quickly a relay can shed stale sessions. Since host
endpoints will normally explicitly destroy sessions, stale
sessions should only occur under failure conditions.
Open Issue: In the 2 relay use case, the visitor does not
explicitly remove state from the visiting relay. Rather, the
visiting relay must infer that a session has been removed when the
host device closes the connection, or when the inactivity timer
expires.
When a hosting device or visiting relay returns a successful response
to a VISIT request, it MUST initialize both timers. The device MUST
reset a timer anytime the associated endpoint sends a SEND request.
If either timer expires without being reset, the device MUST
invalidate the session, using normal procedures depending on the
device's role in the session.
Each endpoint MUST keep a similar timer, which it initializes when
the session is created from its perspective. For the host endpoint,
this is when it receives a successful response to a BIND request. For
a visiting endpoint, this is when it sees a successful response to a
VISIT request. Each endpoint resets its timer whenever it sends a
SEND request. If an endpoint inactivity timer approaches expiration,
and the endpoint wishes to continue participating in the session, it
MUST send a SEND request. This request MAY be sent without a body if
there is no user data to send. Endpoints MUST select the timer value
so that there is sufficient time for the SEND request to traverse to
the opposite endpoint. If the endpoint waits to the last moment,
there is a danger that it will not be received by all relevant
devices in time to prevent session destruction.
Open Issue: There has been list discussion suggesting we should
have a separate KEEPALIVE method for this purpose, rather than
using SEND requests.
7.4.6 Managing Session State and Connections
A MSRP session is represented by state at the host device. As mention A MSRP session is represented by state at the host device. As mention
previously, session state is identified by an MSRP URL. An active previously, session state is identified by an MSRP URL. An active
session also has two associated network connections. The connection session also has an associated network connection.
between the hosting device and the host endpoint is known as the host
connection. The connection with the visiting endpoint is the visiting
connection. Note that when the session state is hosted directly by
an endpoint, the host connection may not involve a physical network
connection; rather it is a logical connection the device maintains
with itself.
When session state is destroyed for any reason, the hosting device When session state is destroyed for any reason, the hosting device
SHOULD drop the connection(s). SHOULD drop the connection.
If a connection fails for any reason, the session hosting device MUST If the connection fails for any reason, the session hosting device
invalidate the session state. This is true regardless of whether the MUST invalidate the session state. Once a connection is dropped, the
dropped connection is the host or visiting connection. Once a associated session state MUST NOT be reused. If an endpoint wishes to
connection is dropped, the associated session state MUST NOT be continue to communicate after detecting a connection failure, it MAY
reused. If the endpoints wish to continue to communicate after a initiate a new SDP exchange to negotiate a new session URL.
connection failure, they must initiate a new session. An endpoint Otherwise, it SHOULD attempt to tear down the session using the rules
detecting a connection failure SHOULD attempt to tear down the of the signaling protocol.
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 opposite endpoint to connection failure, perhaps by allowing the active endpoint to
reconnect, and send a new VISIT or BIND request. However, this reconnect, and send a new VISIT request. However, this approach
approach creates a race condition between the time that the creates a race condition between the time that the hosting device
hosting device notices the failed connection, and the time that notices the failed connection, and the time that the endpoint
the endpoint tries to recover the session. If the endpoint tries to recover the session. If the endpoint attempts to
attempts to reconnect prior to the hosting device noticing the reconnect prior to the hosting device noticing the failure, the
failure, the hosting device will interpret the recovery attempt as hosting device will interpret the recovery attempt as a conflict.
a conflict. The only way around this would be to force the hosting The only way around this would be to force the hosting device to
device to do a liveness check on the original connection, which do a liveness check on the original connection, which would create
would create a lot of complexity and overhead that do not seem to a lot of complexity and overhead that do not seem to be worth the
be worth the trouble. trouble.
7.5 MSRP Relays
MSRP supports the use of message relays. This specification describes
the use of one or two relays. While more than two relays are not
forbidden by MSRP, a solution for an arbitary number of relays is
beyond the scope of this document.
7.5.1 Establishing Session State at a Relay
An endpoint that wishes to host a MSRP session MAY do so by
initiating session state at a MSRP relay, rather than hosting
directly. An endpoint may wish to do this because network topology or
local policy prevents a peer from connecting directly to the
endpoint. The use of a relay should not be the default case, that is,
a hosting endpoint that is not prevented from doing so by topology or
policy SHOULD host the session directly. In order to use a relay, an
MSRP endpoint MUST have knowledge of that relay's existence and
location.
We previously mentioned how an endpoint wishing to host a MSRP
session constructs the session URL. When using a relay, the endpoint
delegates that responsibility to the relay.
To establish session state at a relay, the endpoint MUST perform the
following steps:
1. Open a network connection to the relay at the relays address and
port. Normally, this information will be resolved from an MSRP
URL representing the relay, although the relay MAY be configured
with an explicit address and port, rather than a URL.
2. Construct a BIND request with a S-URL that refers to the relay.
3. Set the Exp header field to a desired value.
4. Send the BIND request on the connection.
5. Respond to any authentication request from the relay.
6. If the response has a 2xx status code, use the URL in the S-URL
header field as the session URL. The endpoint uses this URL in
exactly the same manner as it had constructed it itself.
Additionally, accept the expires value in the response as
pre-visit expiration time.
A MSRP relay listens for connections at all times. When it receives a
BIND request, it SHOULD authenticate the request, either using
digest-authentication, TLS authentication, or some other
authentication mechanism. If authentication succeeds, the relay
performs the following steps:
1. Verify the client is authorized to BIND to this relay. If not,
return a 403 response and make no state change.
2. If the client is authorized, construct a session MSRP URL. The
URL MUST resolve to the relay. It SHOULD be temporary, and hard
to guess. It MUST not duplicate any URL used in any active
sessions hosted by the relay. If the relay wishes the visiting
endpoint to connect over a port other than the MSRP relay
well-know port, it MUST explicitly add the port number to visitor
URL.
3. Establish the pre-visit expiration time for the session according
to Section 7.4.5.
4. Create state for the session. The relay MUST associate the
connection on which the BIND request arrived as the host
connection for the session.
5. Return a 200 response, with the session URL in the S-URL header
field, and the pre-visit session expiration time in the Exp
header field.
When an MSRP relay receives a VISIT request, it MUST perform the
following steps:
1. Check the S-URL header field value to see it matches the URL for
an existing session state entry.
2. If not, return a 481 response and make no state changes
3. If it matches, but another connection has already been associated
with the session URL, return a 506 response and make no state
changes. If the session has been previously associated with this
connection, treat the request as a refresh.
4. If it matches, and no visiting connection has been previously
associated with the session, then the VISIT succeeds. The relay
assigns the connection on which it received the VISIT request as
the visiting connection for the session, and returns a 200
response.
7.5.2 Removing Session State from a relay
An MSRP relay SHOULD remove state for a session when any of the
following conditions occur:
o The session inactivity timer expires.
o The pre-visit timer expires before a VISIT request has occurred.
o The host sends a BIND refresh request matching with an expiration
value of zero.
o Either the host or visitor network connection fails for any
reason.
7.5.3 Sending IMs across an MSRP relay
Once a session is established at a relay, the host and visitor may
exchange IMs by sending SEND requests. Under normal circumstances,
the relay does not respond to SEND requests in any way. Rather, the
relay MUST forward the request to the peer connection unchanged.
Likewise, if the relay receives a response it MUST forward the
request unchanged on the peer connection.
If a SEND request arrives on a connection that is not associated with
a session, the relay MUST return a 481 response.
7.5.4 Relay Pairs
In rare circumstances, two relays may be required in a session. For
example, two endpoints may exist in separate administrative domains,
where each domain's policy insist that all sessions must cross that
domain's relay. A relay operating on behalf of the visiting endpoint
is known as a visiting relay. An MSRP relay MAY be capable of acting
as a visiting relay.
This document does not describe a mechanism for an endpoint to
discover that it needs to use a visiting relay. We assume that an
endpoint is globally configured to use or not use such a relay,
and does not make this decision on a session-by-session basis.
This, of course, does not preclude using some other mechanism to
make such a decision.
In a two relay scenario, the visitor connects to a relay operating on
its behalf, rather than connecting directly to the hosting device.
The visitor sends a VISIT request as it would if it had connected
directly to the hosting device. The visiting relay then connects to
the hosting device and performs a VISIT request on behalf of the
visitor.
When a relay that is capable of acting as a visiting relay receives a
VISIT request, it MUST check to see if the S-URL of the request
matches a domain that the relay hosts. If the URL matches, then the
visitor is not requesting the relay act as a visiting relay, and it
SHOULD operate normally. If the URL does not match, then the relay
SHOULD perform the following steps:
1. The relay SHOULD authenticate the VISIT request, using digest
authentication or some other mechanism.
2. Determine that the visiting endpoint is authorized to use this
device as a visiting relay. If not, return a 403 response and
drop the connection.
3. Attempt to open a connection to the hosting device, determining
the address and port from the S-URL exactly as if it were a
visiting endpoint connecting directly. If this connection is
successful, continue with the remaining steps. Otherwise, return
a 500 response.
4. Create local state to associate the connection to the host device
with the connection to the visiting device.
5. Relay the VISIT request unchanged to the hosting device.
6. Relay the response to the VISIT request unchanged to the visiting
endpoint.
7. Relay all subsequent requests arriving on one of the associated
connections to the peer connection.
If either associated connection fails for any reason, the visiting
relay MUST invalidate the session state, and MUST drop the peer
connection.
7.5.5 Relay Shutdown
Relay administrators will occasionally need to take MSRP relays out
of service. A relay implementation SHOULD allow a graceful shutdown
that minimizes the occurrence of "lost", or timed out, messages. When
a relay effects a graceful shutdown, it SHOULD refuse all new
connection attempts, and refuse all MSRP requests, returning 481
responses. In order to allow any open transactions a high chance of
completion, the relay SHOULD wait at least one transaction timeout
period (normally 30 seconds) between the time it starts refusing
requests and the time it closes existing connections and shuts down.
Open Issue: We have discussed that an endpoint implementation may
attempt to establish a new session (perhaps using a different
relay) with its peer. Do we wish to specify anything at all about
such behavior?
7.6 Digest Authentication
MSRP relays may use the digest authentication scheme to authenticate
users. MSRP digest authentication is a simplified version of HTTP
digest authentication [19], but this specification does not
normatively depend on that document. MSRP digest authentication does
not support the concept of a protection domain, nor does it support
integrity protection. Since a user of a relay is expected to have
credentials for that particular relay, it does not support the realm
concept. Finally, since digest authentication is only expected for
the initial BIND or VISIT request, MSRP does not support HTTP digest
optimizations such as MD5-sess and preemptive credential loading by
the client.
Typically, a hosting user that uses a relay will have a preexisting
relationship with that relay. This relationship SHOULD include
authentication credentials. An MSRP relay SHOULD authenticate initial
BIND requests.
It is less likely that the visiting user will have an account at the
hosting relay, so in most cases the authentication of VISIT requests
is not useful. However a relay MAY authenticate initial VISIT
requests. A visiting relay SHOULD authenticate initial VISIT
requests, as it is much more likely to share credentials with the
visiting user.
There has been some discussion that a hosting relay SHOULD also
authenticate VISIT requests. However, it will be common for
visiting users to have no preexisting relationship with the host
relay. Using authentication here would require the host endpoint
to send temporary credentials in the SDP exchange, perhaps as part
of the session URL. However, these temporary credentials would
necessarily be transferred via the same channels as the session
URL itself. If the credentials are sufficiently protected in
transfer, then so is the session URL. Further, since the session
URL is intended for a one time use, and is expected to be hard to
guess, that URL itself should be sufficient for this purpose. Any
situation where this is not adequate can be covered by the use of
the MSRPS scheme.
MSRP relays MUST NOT request authentication for any method other than
BIND and VISIT.
If a relay wishes to authenticate a request using digest
authentication, it MAY challenge the request by responding with a
401 response, which MUST include a SChal header field.
If an endpoint wishes to respond to a digest authentication challenge
received in a 401 response, it MAY do so by sending a new VISIT or
BIND request, identical to the previous request, but with a CAuth
header field containing the response to the challenge.
7.6.1 The SHA1 Algorithm
The only digest authentication algorithm defined in this
specification is SHA1. [9] Other algorithms can be added as
extensions. SHA1 is the default algorithm if no algorithm directive
is present in the challenge. All MSRP devices MUST support SHA1.
Open Issue: Do we need to specify how to offer more than one
algorithm in a challenge? Do we need multiple algorithms possible
for a particular challenge, or should we follow the HTTP digest
approach of multiple challenges. It has been suggested that SHA1
MUST always be offered, to ensure that the client and server will
have at least one common algorithm.
The SHA1 digest is defined as follows:
Let KD(secret, data) denote the string obtained by performing the
digest algorithm to the data "data" with the secret "secret". Let
H(data) denote the string obtained by performing the checksum
algorithm on the data "data".
For the "SHA1" algorithm, H(data) = SHA1(data), and KD(secret,data) =
H(concat(secret, ":", data)
Section 7.2 describes the syntax for the request-digest value in a
CAuth header as 40 digits in lower case hexadecimal notation. The
actual structure of the field is defined as follows. Note that
unq(quoted-string) denotes the value of the string with the quotes
removed.
request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > <">
A1 = unq(username-value) ":" shared-secret ; "unq" denotes removal of quotes
A2 = concat(Method,TR-ID,S-URI)
When the relay receives a CAuth header, it SHOULD check its validity
by looking up the shared secret, or H(A1), performing the same digest
operation as performed by the client, and comparing the results to
the request-digest value.
7.7 Method Descriptions 7.5 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 header fields. All messages MUST
contain a length field in the start line that indicates the overall contain a length field in the start line that indicates the overall
length of the request, including any body, but not including the length of the request, including any body, but not including the
start line itself. Additional requirements exist depending on the start line itself. Additional requirements exist depending on the
individual method. Except where otherwise noted, all requests are hop individual method.
by hop.
7.7.1 BIND
The BIND method is used by a host endpoint to establish or refresh
session state at a hosting relay. BIND requests SHOULD be
authenticated. BIND requests MUST contain the S-URL and Exp header
fields and MAY contain the CAuth header fields.
A successful response to a BIND request MUST contain the S-URL and
Exp header fields.
7.7.2 SEND 7.5.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. SEND requests SHOULD
contain a MIME body part. The body MUST be of a media type included 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 in the format list negotiated in the SDP exchange. If a body is
present, the request MUST contain a Content-Type header field present, the request MUST contain a Content-Type header field
identifying the media type of the body. identifying the media type of the body.
Unlike other methods, SEND requests are end to end in nature. This To Do: We plan to expand the use of MIME headers to allow any
means the request is consumed only by the opposite endpoint. Under standard MIME header in a SEND request. This is not included in
normal conditions, any intervening relays merely forward the request this version for the sake of getting the draft out as soon as
on towards the peer endpoint. possible, but will follow soon.
7.7.3 VISIT 7.5.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, which could connection with the session state at the hosting device. The request
be either the host endpoint or a relay operating on behalf of the MUST contain a S-URL header matching the session URL.
host endpoint. The request MUST contain a S-URL header matching the
session URL.
There is normally no authentication operation for the VISIT
request. This is because the session URL acts as a shared secret
between host and the visitor. This puts certain requirements on
the handling of the session URLs that are discussed in Section 10.
However, if a visiting relay is used, it SHOULD authenticate VISIT
requests.
7.8 Response Code Descriptions 7.6 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. Responses are never TR-ID header field of the associated request.
consumed by relays.
7.8.1 200 7.6.1 200
The 200 response code indicates a successful transaction. The 200 response code indicates a successful transaction.
7.8.2 400 7.6.2 400
A 400 response indicates a request was unintelligible. A 400 response indicates a request was unintelligible.
7.8.3 401 7.6.3 415
A 401 response indicates authentication is required. 401 responses
MUST NOT be used in response to any method other than BIND and VISIT.
A 401 response MUST contain a SChal header field.
7.8.4 403
A 403 response indicates the user is not authorized to perform the
action.
7.8.5 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.8.6 426 7.6.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.8.7 481 7.6.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.8.8 500 7.6.6 506
A 500 response indicates that a relay was unable to deliver a request
to the target.
7.8.9 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 S-URL indicates a session that is already associated with another
connection. A 506 response MUST NOT be returned in response to any connection. A 506 response MUST NOT be returned in response to any
method other than VISIT. method other than VISIT.
7.9 Header Field Descriptions 7.7 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.9.1 TR-ID 7.7.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.9.2 Exp 7.7.2 Content-Type
The Exp header field specifies when the state associated with a BIND
request will expire, if no successful VISIT request has been
received. The value is specified as an integer number of seconds from
the time the request is received. BIND requests MUST contain this
header field. Furthermore, successful responses to BIND requests MUST
also contain the Exp header.
The maximum value for the Exp header field is (2**32)-1 seconds.
Exp has no meaning if it occurs in MSRP messages other than BIND
requests, and responses to those requests. MSRP compliant devices
SHOULD NOT use Exp in other requests or responses, unless that usage
is defined in an extension to this specification.
7.9.3 CAuth
The CAuth header field is used by a host endpoint to offer digest
authentication credentials to a relay, in response to a digest
authentication challenge. CAuth SHOULD NOT be present in a request of
any method other than BIND and VISIT.
The syntax of the CAuth credentials is described in Section 7.2
The meaning of each value is as follows:
username: The user's account name.
nonce: The nonce value copied from the challenge.
response: A 32 hex digit string that proves user knowledge of the
shared secret.
algorithm: The algorithm value copied from the challenge.
auth-param: Additional parameters for the sake of extensibility.
7.9.4 SChal
The SChal header field is used by a relay to carry the challenge in a
digest authentication attempt. Exactly one SChal header field MUST
exist in a 401 response. The SChal header MUST NOT be used in any
message except for a 401 response. The syntax for the SChal challenge
is described in Section 7.2
The meaning of each value is as follows:
digest scheme: A token to identify the particular authentication
scheme. Since MSRP only supports digest, this value MUST be set to
"Digest"
nonce: A server-specified string, which the relay SHOULD uniquely
generate each time it sends a 401 response. This string SHOULD
take the form of base64 or hexadecimal data, to avoid the presence
of a double-quote character, which is not allowed.
algorithm: A token indicating the algorithms to be used to generate
the digest and checksum. This directive exists for the sake of
extensibility; the only value defined by this document is "SHA1".
Absence of this directive indicates a value of "SHA1".
7.9.5 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.
Open Issue: We may need to clean up our MIME usage. This includes To Do: The work group has agreed to allow the use of any standard
better defining the Content-Type usage possibly moving MIME header. This is not reflected in this version, but will be in
content-type into the body, indicating MIME version, etc. a shortly forthcoming one.
7.9.6 S-URL 7.7.3 S-URL
The S-URL header field is used to identify the session. The S-URI The S-URL header field is used to identify the session. The S-URI
header field MUST be present in a BIND request, a successful response header field must be included in VISIT requests.
to a BIND request, or a VISIT request.
8. Examples 8. Example
This section shows some example message flows for various common This section shows an example message flow for the most common
scenarios. The examples assume 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 examples, 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.
8.1 No Relay
In this scenario, the session goes directly between endpoints with no
MSRP relays involved.
Alice Bob Alice Bob
| | | |
| | | |
|(1) (SIP) INVITE | |(1) (SIP) INVITE |
|----------------------->| |----------------------->|
|(2) (MSRP) VISIT | |(2) (MSRP) VISIT |
|<-----------------------| |<-----------------------|
|(3) (MSRP) 200 OK | |(3) (MSRP) 200 OK |
|----------------------->| |----------------------->|
|(4) (SIP) 200 OK | |(4) (SIP) 200 OK |
skipping to change at page 38, line 47 skipping to change at page 27, line 4
|(11) (SIP) 200 OK | |(11) (SIP) 200 OK |
|<-----------------------| |<-----------------------|
| | | |
| | | |
1. Alice constructs a session URL of msrp:// 1. Alice constructs a session URL of msrp://
alicepc.atlanta.com:7777/iau39 and listens for a connection on alicepc.atlanta.com:7777/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
o=alice 2890844557 2890844559 IN IP4 host.anywhere.com
s=
c=IN IP4 fillername c=IN IP4 fillername
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 a=direction:both 0
a=session: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 S-URL:msrp://alicepc.atlanta.com:7777/iau39
Tr-ID: sie09s Tr-ID: sie09s
3. Alice->Bob (MSRP): 3. Alice->Bob (MSRP):
MSRP xx 200 OK MSRP xx 200 OK
Tr-ID: sie09s Tr-ID: sie09s
Exp:300
4. Bob->Alice (SIP): 200 OK 4. Bob->Alice (SIP): 200 OK
v=0
o=bob 2890844612 2890844616 IN IP4 host.anywhere.com
s=
c=IN IP4 ignorefield c=IN IP4 ignorefield
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 a=direction:active 0
5. Alice->Bob (SIP): ACK 5. Alice->Bob (SIP): ACK
6. Alice->Bob (MSRP): 6. Alice->Bob (MSRP):
MSRP xx SEND MSRP xx SEND
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
skipping to change at page 40, line 4 skipping to change at page 28, line 15
MSRP xx SEND MSRP xx SEND
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
TR-ID: 456 TR-ID: 456
10. Alice->Bob (SIP): BYE 10. Alice->Bob (SIP): BYE
Alice invalidates session and drops connection. Alice invalidates session and drops connection.
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
8.2 Single Relay
This scenario introduces an MSRP relay at relay.atlanta.com.
Alice Relay Bob
| | |
| | |
|(1) (MSRP) BIND | |
|----------------------->| |
|(2) (MSRP) 200 OK | |
|<-----------------------| |
|(3) (SIP) INVITE | |
|------------------------------------------------>|
| |(4) (MSRP) VISIT |
| |<-----------------------|
| |(5) (MSRP) 200 OK |
| |----------------------->|
|(6) (SIP) 200 OK | |
|<------------------------------------------------|
|(7) (SIP) ACK | |
|------------------------------------------------>|
|(8) (MSRP) SEND | |
|----------------------->| |
| |(9) (MSRP) SEND |
| |----------------------->|
| |(10) (MSRP) 200 OK |
| |<-----------------------|
|(11) (MSRP) 200 OK | |
|<-----------------------| |
| |(12) (MSRP) SEND |
| |<-----------------------|
|(13) (MSRP) SEND | |
|<-----------------------| |
|(14) (MSRP) 200 OK | |
|----------------------->| |
| |(15) (MSRP) 200 OK |
| |----------------------->|
|(16) (SIP) BYE | |
|------------------------------------------------>|
|(17) (MSRP) BIND | |
|----------------------->| |
|(18) (MSRP) 200 OK | |
|<-----------------------| |
|(19) (SIP) 200 OK | |
|<------------------------------------------------|
| | |
| | |
1. Alice->Relay (MSRP): Alice opens a connection to the relay, and
sends the following:
MSRP xx BIND
S-URL:msrp://relay.atlanta.com
TR-ID: 321
Exp:600
2. Relay->Alice (MSRP):
MSRP xx 200 OK
TR-ID: 321
S-URL: msrp://relay.atlanta.com:7777/iau39
Exp:300
3. Alice->Bob (SIP): INVITE sip:bob@biloxi.com
c=IN IP4 dummyvalue
m=message 9999 msrp/tcp *
a=accept-types:text/plain
a=direction:passive
a=session:msrp://relay.atlanta.com:7777/iau39
4. Bob->Alice: Open connection to relay.atlanta.com:7777.
Bob->Relay (MSRP):
MSRP xx VISIT
S-URL:msrp://relay.atlanta.com:7777/iau39
TR-ID: sie09s
5. Relay->Bob (MSRP):
MSRP xx 200 OK
TR-ID: sie09s
Exp:300
6. Bob->Alice (SIP): 200 OK
c=IN IP4 nobodybutuschickens
m=message 9999 msrp/tcp *
a=accept-types:text/plain
a=direction:active
7. Alice->Bob (SIP): ACK
8. Alice->Relay (MSRP):
MSRP xx SEND
TR-ID: 123
Content-Type: "text/plain"
Hi, I'm Alice!
9. Relay->Bob (MSRP):
MSRP xx SEND
TR-ID: 123
Content-Type: "text/plain"
Hi, I'm Alice!
10. Bob->Relay (MSRP):
MSRP xx 200 OK
TR-ID: 123
11. Relay->Alice (MSRP):
MSRP xx 200 OK
TR-ID: 123
12. Bob->Relay (MSRP):
MSRP xx SEND
TR-ID: 456
Content-Type:"text/plain"
Hi, Alice! I'm Bob!
13. Relay->Alice (MSRP):
MSRP xx SEND
TR-ID: 456
Content-Type: "text/plain"
Hi, Alice! I'm Bob!
14. Alice->relay (MSRP):
MSRP xx 200 OK
TR-ID: 456
15. Relay->Bob (MSRP):
MSRP xx 200 OK
TR-ID: 456
16. Alice->Bob (SIP): BYE
17. Alice->Relay (MSRP):
MSRP xx BIND
S-URL: msrp://relay.atlanta.com:7777/iau39
TR-ID: 42
Exp:0
18. Relay->Alice (MSRP): Relay invalidates session state.
MSRP xx 200 OK
TR-ID: 42
Exp:0
19. Bob invalidates local state for the session.
Bob->Alice (SIP): 200 OK
8.3 Two Relays
In this scenario, both Alice and Bob are each required by local
policy to route all sessions through a different local relay.
Alice AtlantaRelay BiloxiRelay Bob
| | | |
| | | |
|(1) (MSRP) BIND | |
|------------->| | |
|(2) (MSRP) 200 OK | |
|<-------------| | |
|(3) (SIP) INVITE | |
|------------------------------------------->|
| | |(4) (MSRP) VISIT
| | |<-------------|
| |(5) (MSRP) VISIT |
| |<-------------| |
| |(6) (MSRP) 200 OK |
| |------------->| |
| | |(7) (MSRP) 200 OK
| | |------------->|
|(8) (SIP) 200 OK | |
|<-------------------------------------------|
|(9) (SIP) ACK | | |
|------------------------------------------->|
|(10) (MSRP) SEND | |
|------------->| | |
| |(11) (MSRP) SEND |
| |------------->| |
| | |(12) (MSRP) SEND
| | |------------->|
| | |(13) (MSRP) 200 OK
| | |<-------------|
| |(14) (MSRP) 200 OK |
| |<-------------| |
|(15) (MSRP) SEND | |
|<-------------| | |
|(16) (SIP) BYE| | |
|------------------------------------------->|
|(17) (MSRP) BIND | |
|------------->| | |
|(18) (MSRP) 200 OK | |
|<-------------| | |
|(19) (SIP) 200 OK | |
|<-------------------------------------------|
| | | |
| | | |
1. Alice->AtlantaRelay (MSRP): Alice opens a connection to her
relay, and sends the following:
MSRP xx BIND
S-URL: msrp://relay.atlanta.com
TR-ID: 321
Exp:600
2. AtlantaRelay->Alice (MSRP):
MSRP xx 200 OK
TR-ID: 321
S-URL: msrp://relay.atlanta.com:7777/iau39
Exp:600
3. Alice->Bob (SIP): INVITE sip:bob@biloxi.com
c=IN IP4 blahblahblah
m=message 9999 msrp/tcp *
a=accept-types:text/plain
a=session:msrp://relay.atlanta.com:7777/iau39
a=direction:passive
4. Bob determines that, due to local policy, he must connect
through his own relay.
Bob->BiloxiRelay (MSRP): Bob opens a connection to his relay,
and sends the following:
MSRP xx VISIT
S-URL: msrp://relay.atlanta.com:7777/iau39
TR-ID: 934
5. BiloxiRelay->AtlantaRelay (MSRP): BiloxiRelay resolves the URL,
opens a connection to relay.atlanta.com:7777, and sends the
following:
MSRP xx VISIT
S-URL: msrp://relay.atlanta.com:7777/iau39
TR-ID: 934
6. AtlantaRelay->BiloxiRelay(MSRP):
MSRP xx 200 OK
TR-ID: 934
7. BiloxiRelay->Bob(MSRP):
MSRP xx 200 OK
TR-ID: 934
8. Bob->Alice (SIP): 200 OK
c=IN IP4 stuff
m=message 9999 msrp/tcp *
a=accept-types:text/plain
a=direction: active
9. Alice->Bob (SIP): ACK
10. Alice->AtlantaRelay (MSRP):
MSRP xx SEND
TR-ID: 123
Content-Type: "text/plain"
Hi, I'm Alice!
11. AtlantaRelay ->BiloxiRelay (MSRP):
MSRP xx SEND
TR-ID: 123
Content-Type: "text/plain"
Hi, I'm Alice!
12. BiloxiRelay->Bob (MSRP):
MSRP xx SEND
TR-ID: 123
Content-Type: "text/plain"
Hi, I'm Alice!
13. Bob->BiloxiRelay (MSRP):
MSRP xx 200 OK
TR-ID: 123
14. BiloxiRelay->AtlantaRelay (MSRP):
MSRP xx 200 OK
TR-ID: 123
15. AtlantaRelay->Alice (MSRP):
MSRP xx 200 OK
TR-ID: 123
16. Alice->Bob (SIP): BYE
17. Alice->AtlantaRelay (MSRP):
MSRP xx BIND
S-URL: msrp://relay.atlanta.com:7777/iau39
TR-ID: 42
Exp:0
18. Relay->Alice (MSRP): Relay invalidates session state.
MSRP xx 200 OK
TR-ID: 42
Exp:0
19. 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
is approved for publication. Usage of this value is described in is approved for publication. Usage of this value is described in
Section 7.1 Section 7.1
9.2 MSRP URL Schemes 9.2 MSRP URL Schemes
skipping to change at page 48, line 27 skipping to change at page 30, line 5
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.
Open Issue: There have been suggestions that we need more here
covering the multiple authentication possibilities, MITM attack
possibility on digest if not over TLS, and possible bid-down
attacks on the digest algorithm selection.
10.1 TLS and the MSRPS Scheme 10.1 TLS and the MSRPS Scheme
All MSRP devices must support TLS, with at least the All MSRP devices must support TLS, with at least the
TLS_RSA_WITH_AES_128_CBC_SHA [8] cipher suite. Other cipher suites TLS_RSA_WITH_AES_128_CBC_SHA [8] cipher suite. Other cipher suites
MAY be supported. MAY be supported.
MSRP does not define a separate TCP port for TLS connections. This MSRP does not define a separate TCP port for TLS connections. This
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
skipping to change at page 49, line 17 skipping to change at page 30, line 39
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. Ensuring this implies some additional rules. A be protected with TLS. Since this document does not specify the use
relay MUST return an MSRPS URL to a BIND request if the request of intermidiary devices, then MSRPS support is trivially equivilant
arrived over TLS and included a MSRPS URI in the S-URI header field. to TLS support. However, if intermediaries do exist, either as
The relay MAY return an MSRPS URI to any BIND request that arrives described in an MSRP extension document, or as sort of proprietary
over TLS, but MUST NOT return an MSRP URI to a BIND request that does devices, they MUST ensure protection at all hops for an MSRPS URL.
not arrive over TLS. If a relay receives a BIND request with an MSRPS
S-URI, over a non-TLS connection, it MUST reject the request with a
426 response. A relay may insist on always using MSRPS by returning a
426 to any bind received over an unprotected connection, and always
returning MSRPS URLs to BIND requests over protected connections.
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 visiting relay 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.2 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 of a MSRP session is used by the visiting endpoint to
identify itself to the hosting device, regardless of whether the identify itself to the hosting device. If an attacker were able to
session is directly hosted by the host endpoint, or is hosted by a acquire the session URL, either by guessing it or by eavesdropping,
relay. If an attacker were able to acquire the session URL, either by there is a window of opportunity in which the attacker could hijack
guessing it or by eavesdropping, there is a window of opportunity in the session by sending a VISIT request to the host device before the
which the attacker could hijack the session by sending a VISIT true visiting endpoint. Because of this sensitivity, the session URL
request to the host device before the true visiting endpoint. Because SHOULD be constructed in a way to make it difficult to guess, and
of this sensitivity, the session URL SHOULD be constructed in a way should be sufficiently random so that it is unlikely to be reused.
to make it difficult to guess, and should be sufficiently random so All mechanisms used to transport the session URL to the visitor and
that it is unlikely to be reused. All mechanisms used to transport back to the host SHOULD be protected from eavesdroppers and
the session URL to the visitor and back to the host SHOULD be man-in-the-middle attacks.
protected from eavesdroppers and man-in-the-middle attacks.
Therefore an MSRP device MUST support the use of TLS for at least the Therefore an 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.3 End to End Protection of IMs 10.1.2 End to End Protection of IMs
Instant messages can contain very sensitive information. As a result, Instant messages can contain very sensitive information. As a result,
as specified in RFC 2779 [3], instant messaging protocols need to as specified in RFC 2779 [3], instant messaging protocols need to
provide for encryption, integrity and authentication of instant provide for encryption, integrity and authentication of instant
messages. Therefore MSRP endpoints MUST support the end-to-end messages. Therefore MSRP endpoints MUST support the end-to-end
encryption and integrity of bodies sent via SEND requests using encryption and integrity of bodies sent via SEND requests using
Secure MIME (S/MIME) [7]. Secure MIME (S/MIME) [7].
Note that while each protected body could use separate keying Note that while each protected body could use separate keying
material, this is inefficient in that it requires an independent material, this is inefficient in that it requires an independent
public key operation for each message. Endpoints wishing to invoke public key operation for each message. Endpoints wishing to invoke
end-to-end protection of message sessions SHOULD exchange symmetric end-to-end protection of message sessions SHOULD exchange symmetric
keys in SDP k-lines, and use secret key encryption on for each MSRP keys in SDP k-lines, and use secret key encryption on for each MSRP
message. When symmetric keys are present in the SDP, the offer-answer message. When symmetric keys are present in the SDP, the offer-answer
exchange MUST be protected from eavesdropping and tampering using the exchange MUST be protected from eavesdropping and tampering using the
appropriate facilities of the signaling protocol. For example, if the appropriate facilities of the signaling protocol. For example, if the
signaling protocol is SIP, the SDP exchange MUST be protected using signaling protocol is SIP, the SDP exchange MUST be protected using
S/MIME. S/MIME.
10.4 CPIM compatibility 10.1.3 CPIM compatibility
MSRP sessions may be gatewayed to other CPIM [17]compatible MSRP sessions may be gatewayed to other CPIM [17]compatible
protocols. If this occurs, the gateway MUST maintain session state, protocols. If this occurs, the gateway MUST maintain session state,
and MUST translate between the MSRP session semantics and CPIM and MUST translate between the MSRP session semantics and CPIM
semantics that do not include a concept of sessions. Furthermore, semantics that do not include a concept of sessions. Furthermore,
when one endpoint of the session is a CPIM gateway, instant messages when one endpoint of the session is a CPIM gateway, instant messages
SHOULD be wrapped in "message/cpim" [5] bodies. Such a gateway MUST SHOULD be wrapped in "message/cpim" [5] bodies. Such a gateway MUST
include "message/cpim" as the first entry in its SDP accept-types include "message/cpim" as the first entry in its SDP accept-types
attribute. MSRP endpoints sending instant messages to a peer that has attribute. MSRP endpoints sending instant messages to a peer that has
included 'message/cpim" as the first entry in the accept-types included 'message/cpim" as the first entry in the accept-types
attribute SHOULD encapsulate all instant message bodies in "message/ attribute SHOULD encapsulate all instant message bodies in "message/
cpim" wrappers. All MSRP endpoints MUST support the message/cpim cpim" wrappers. All MSRP endpoints MUST support the message/cpim
type, and SHOULD support the S/MIME features of that format. type, and SHOULD support the S/MIME features of that format.
10.5 PKI Considerations 10.1.4 PKI Considerations
Several aspects of MSRP will benefit from being used in the context Several aspects of MSRP will benefit from being used in the context
of a public key infrastructure. For example, the MSRPS scheme allows, of a public key infrastructure. For example, the MSRPS scheme allows,
and even encourages, TLS connections between endpoint devices. And and even encourages, TLS connections between endpoint devices. And
while MSRP allows for a symmetric session key to protect all messages while MSRP allows for a symmetric session key to protect all messages
in a session, it is most likely that session key itself would be in a session, it is most likely that session key itself would be
exchanged in a signaling protocol such as SIP. Since that key is exchanged in a signaling protocol such as SIP. Since that key is
extremely sensitive, its exchange would also need to be protected. In extremely sensitive, its exchange would also need to be protected. In
SIP, the preferred mechanism for this would be S/MIME, which would SIP, the preferred mechanism for this would be S/MIME, which would
also benefit from a PKI. also benefit from a PKI.
skipping to change at page 51, line 20 skipping to change at page 32, line 35
less convenient than with a PKI, in that there would be no less convenient than with a PKI, in that there would be no
certificate authority to act as a trusted introducer. Peers would be certificate authority to act as a trusted introducer. Peers would be
required to exchange certificates prior to securely communicating. required to exchange certificates prior to securely communicating.
Since, at least for the immediate future, any given MSRP Since, at least for the immediate future, any given MSRP
implementation is likely to communicate with at least some peers that implementation is likely to communicate with at least some peers that
do not have a PKI available, MSRP implementations SHOULD support the do not have a PKI available, MSRP implementations SHOULD support the
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
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-02 11.1 draft-ietf-simple-message-sessions-03
Removed all specification of relays, and all features specific to
the use of relays. The working group has chosen to move relay work
into a separate effort, in order to advance the base
specification. (The MSRP acronym is unchanged for the sake of
convenience.) This included removal of the BIND method, all
response codes specific to BIND, Digest Authentication, and the
inactivity timeout.
Removed text indicating that an endpoint could retry failed
requests on the same connection. Rather, the endpoint should
consider the connection dead, and either signal a reconnection or
end the session.
Added text describing subsequent SDP exchanges. Added mandatory
"count" parameter to the direction attribute to allow explicit
signaling of the need to reconnect.
Added text to describe the use of send and receive only indicators
in SDP for one-way transfer of large content.
Added text requiring unique port field values if multiple M-line's
exist.
Corrected a number of editorial mistakes.
11.2 draft-ietf-simple-message-sessions-02
Moved all content type negotiation from the "m"-line format list 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.2 draft-ietf-simple-message-sessions-01 11.3 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
skipping to change at page 52, line 4 skipping to change at page 33, line 46
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.3 draft-ietf-simple-message-sessions-00 11.4 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 52, line 42 skipping to change at page 34, line 36
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.4 draft-campbell-simple-im-sessions-01 11.5 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
skipping to change at page 54, line 42 skipping to change at page 36, line 37
[16] Peterson, J., "A Privacy Mechanism for the Session Initiation [16] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323 , November 2002. Protocol (SIP)", RFC 3323 , November 2002.
[17] Peterson, J., "A Common Profile for Instant Messaging (CPIM)", [17] Peterson, J., "A Common Profile for Instant Messaging (CPIM)",
draft-ietf-impp-im-04 (work in progress), August 2003. draft-ietf-impp-im-04 (work in progress), August 2003.
[18] Yon, D., "Connection-Oriented Media Transport in SDP", [18] Yon, D., "Connection-Oriented Media Transport in SDP",
draft-ietf-mmusic-sdp-comedia-05 (work in progress), March draft-ietf-mmusic-sdp-comedia-05 (work in progress), March
2003. 2003.
[19] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
Authors' Addresses Authors' Addresses
Ben Campbell Ben Campbell
dynamicsoft dynamicsoft
5100 Tennyson Parkway 5100 Tennyson Parkway
Suite 1200 Suite 1200
Plano, TX 75024 Plano, TX 75024
EMail: bcampbell@dynamicsoft.com EMail: bcampbell@dynamicsoft.com
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
EMail: jdrosen@dynamicsoft.com EMail: jdrosen@dynamicsoft.com
Robert Sparks Robert Sparks
dynamicsoft dynamicsoft
5100 Tennyson Parkway 5100 Tennyson Parkway
skipping to change at page 56, line 29 skipping to change at page 38, line 29
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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