draft-ietf-simple-message-sessions-01.txt   draft-ietf-simple-message-sessions-02.txt 
SIMPLE Working Group B. Campbell SIMPLE Working Group B. Campbell
Internet-Draft J. Rosenberg Internet-Draft J. Rosenberg
Expires: December 29, 2003 R. Sparks Expires: April 22, 2004 R. Sparks
dynamicsoft dynamicsoft
P. Kyzivat P. Kyzivat
Cisco Systems Cisco Systems
June 30, 2003 October 23, 2003
Instant Message Sessions in SIMPLE The Message Session Relay Protocol
draft-ietf-simple-message-sessions-01 draft-ietf-simple-message-sessions-02
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 December 29, 2003. This Internet-Draft will expire on April 22, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). 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 SDP offer/answer model session. MSRP sessions are managed using the Session Description
carried by a signaling protocol such as SIP. Protocol (SDP) offer/answer model carried by a signaling protocol
such as the Session Initiation Protocol (SIP).
MSRP supports end-to-end Instant Message Sessions, as well as MSRP supports end-to-end Instant Message Sessions, as well as
sessions traversing one or two relays. 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 . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 6
5. Architectural Considerations . . . . . . . . . . . . . . . . 8 5. Architectural Considerations . . . . . . . . . . . . . . . . 7
5.1 Use of Relays . . . . . . . . . . . . . . . . . . . . . . . 8 5.1 Use of Relays . . . . . . . . . . . . . . . . . . . . . . . 8
5.2 Transferring Large Content . . . . . . . . . . . . . . . . . 9 5.2 Transferring Large Content . . . . . . . . . . . . . . . . . 8
5.3 Connection Sharing . . . . . . . . . . . . . . . . . . . . . 9 5.3 Connection Sharing . . . . . . . . . . . . . . . . . . . . . 9
6. SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . . 10 6. SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . . 10
6.1 Use of the SDP M-line . . . . . . . . . . . . . . . . . . . 10 6.1 Use of the SDP M-line . . . . . . . . . . . . . . . . . . . 10
6.2 The Direction Attribute . . . . . . . . . . . . . . . . . . 11 6.2 The Direction Attribute . . . . . . . . . . . . . . . . . . 11
6.3 MIME Wrappers . . . . . . . . . . . . . . . . . . . . . . . 13 6.3 The Accept Types Attribute . . . . . . . . . . . . . . . . . 12
6.4 URL Negotiations . . . . . . . . . . . . . . . . . . . . . . 13 6.4 MIME Wrappers . . . . . . . . . . . . . . . . . . . . . . . 13
6.5 Example SDP Exchange . . . . . . . . . . . . . . . . . . . . 14 6.5 URL Negotiations . . . . . . . . . . . . . . . . . . . . . . 13
6.6 Example SDP Exchange . . . . . . . . . . . . . . . . . . . . 14
7. The Message Session Relay Protocol . . . . . . . . . . . . . 15 7. The Message Session Relay Protocol . . . . . . . . . . . . . 15
7.1 MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1 MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . . 16 7.1.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . . 16
7.1.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . . 16 7.1.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . . 16
7.1.3 The msrps URL Scheme . . . . . . . . . . . . . . . . . . . . 17 7.1.3 The msrps URL Scheme . . . . . . . . . . . . . . . . . . . . 17
7.2 MSRP messages . . . . . . . . . . . . . . . . . . . . . . . 17 7.2 MSRP messages . . . . . . . . . . . . . . . . . . . . . . . 17
7.3 MSRP Transactions . . . . . . . . . . . . . . . . . . . . . 18 7.3 MSRP Transactions . . . . . . . . . . . . . . . . . . . . . 19
7.4 MSRP Sessions . . . . . . . . . . . . . . . . . . . . . . . 19 7.4 MSRP Sessions . . . . . . . . . . . . . . . . . . . . . . . 19
7.4.1 Initiating an MSRP session . . . . . . . . . . . . . . . . . 19 7.4.1 Initiating an MSRP session . . . . . . . . . . . . . . . . . 19
7.4.2 Handling VISIT requests . . . . . . . . . . . . . . . . . . 23 7.4.2 Handling VISIT requests . . . . . . . . . . . . . . . . . . 23
7.4.3 Sending Instant Messages on a Session . . . . . . . . . . . 23 7.4.3 Sending Instant Messages on a Session . . . . . . . . . . . 23
7.4.4 Ending a Session . . . . . . . . . . . . . . . . . . . . . . 24 7.4.4 Ending a Session . . . . . . . . . . . . . . . . . . . . . . 25
7.4.5 Session Inactivity Timer . . . . . . . . . . . . . . . . . . 24 7.4.5 Session Inactivity Timer . . . . . . . . . . . . . . . . . . 26
7.4.6 Managing Session State and Connections . . . . . . . . . . . 25 7.4.6 Managing Session State and Connections . . . . . . . . . . . 27
7.5 MSRP Relays . . . . . . . . . . . . . . . . . . . . . . . . 26 7.5 MSRP Relays . . . . . . . . . . . . . . . . . . . . . . . . 27
7.5.1 Establishing Session State at a Relay . . . . . . . . . . . 26 7.5.1 Establishing Session State at a Relay . . . . . . . . . . . 28
7.5.2 Removing Session State from a relay . . . . . . . . . . . . 28 7.5.2 Removing Session State from a relay . . . . . . . . . . . . 29
7.5.3 Sending IMs across an MSRP relay . . . . . . . . . . . . . . 28 7.5.3 Sending IMs across an MSRP relay . . . . . . . . . . . . . . 30
7.5.4 Relay Pairs . . . . . . . . . . . . . . . . . . . . . . . . 28 7.5.4 Relay Pairs . . . . . . . . . . . . . . . . . . . . . . . . 30
7.6 Digest Authentication . . . . . . . . . . . . . . . . . . . 30 7.5.5 Relay Shutdown . . . . . . . . . . . . . . . . . . . . . . . 31
7.6.1 The SHA1 Algorithm . . . . . . . . . . . . . . . . . . . . . 31 7.6 Digest Authentication . . . . . . . . . . . . . . . . . . . 31
7.7 Method Descriptions . . . . . . . . . . . . . . . . . . . . 31 7.6.1 The SHA1 Algorithm . . . . . . . . . . . . . . . . . . . . . 33
7.7.1 BIND . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 7.7 Method Descriptions . . . . . . . . . . . . . . . . . . . . 33
7.7.2 SEND . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.7.1 BIND . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.7.3 VISIT . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.7.2 SEND . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.8 Response Code Descriptions . . . . . . . . . . . . . . . . . 32 7.7.3 VISIT . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.8.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.8 Response Code Descriptions . . . . . . . . . . . . . . . . . 34
7.8.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.8.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.8.3 401 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.8.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.8.4 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.8.3 401 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.8.5 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.8.4 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.8.6 426 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.8.5 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.8.7 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.8.6 426 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.8.8 500 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.8.7 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.8.9 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.8.8 500 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.9 Header Field Descriptions . . . . . . . . . . . . . . . . . 33 7.8.9 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.9.1 TR-ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.9 Header Field Descriptions . . . . . . . . . . . . . . . . . 36
7.9.2 Exp . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.9.1 TR-ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.9.3 CAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.9.2 Exp . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.9.4 SChal . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.9.3 CAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.9.5 Content-Type . . . . . . . . . . . . . . . . . . . . . . . . 36 7.9.4 SChal . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.9.6 S-URL . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7.9.5 Content-Type . . . . . . . . . . . . . . . . . . . . . . . . 37
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7.9.6 S-URL . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1 No Relay . . . . . . . . . . . . . . . . . . . . . . . . . . 36 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.2 Single Relay . . . . . . . . . . . . . . . . . . . . . . . . 39 8.1 No Relay . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.3 Two Relays . . . . . . . . . . . . . . . . . . . . . . . . . 42 8.2 Single Relay . . . . . . . . . . . . . . . . . . . . . . . . 40
8.3 Two Relays . . . . . . . . . . . . . . . . . . . . . . . . . 43
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 46 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 46
9.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . . 46 9.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.2 MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . . . 46 9.2 MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . . . 47
9.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 9.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.2.2 Character Encoding . . . . . . . . . . . . . . . . . . . . . 46 9.2.2 Character Encoding . . . . . . . . . . . . . . . . . . . . . 47
9.2.3 Intended Usage . . . . . . . . . . . . . . . . . . . . . . . 47 9.2.3 Intended Usage . . . . . . . . . . . . . . . . . . . . . . . 47
9.2.4 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . 47 9.2.4 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.2.5 Security Considerations . . . . . . . . . . . . . . . . . . 47 9.2.5 Security Considerations . . . . . . . . . . . . . . . . . . 47
9.2.6 Relevant Publications . . . . . . . . . . . . . . . . . . . 47 9.2.6 Relevant Publications . . . . . . . . . . . . . . . . . . . 47
9.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . 47 9.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . 47
9.3.1 Direction . . . . . . . . . . . . . . . . . . . . . . . . . 47 9.3.1 Direction . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.3.2 Wrapped Types . . . . . . . . . . . . . . . . . . . . . . . 47 9.3.2 Accept Types . . . . . . . . . . . . . . . . . . . . . . . . 48
9.3.3 Wrapped Types . . . . . . . . . . . . . . . . . . . . . . . 48
10. Security Considerations . . . . . . . . . . . . . . . . . . 48 10. Security Considerations . . . . . . . . . . . . . . . . . . 48
10.1 TLS and the MSRPS Scheme . . . . . . . . . . . . . . . . . . 48 10.1 TLS and the MSRPS Scheme . . . . . . . . . . . . . . . . . . 48
10.2 Sensitivity of the Session URL . . . . . . . . . . . . . . . 49 10.2 Sensitivity of the Session URL . . . . . . . . . . . . . . . 49
10.3 End to End Protection of IMs . . . . . . . . . . . . . . . . 49 10.3 End to End Protection of IMs . . . . . . . . . . . . . . . . 50
10.4 CPIM compatibility . . . . . . . . . . . . . . . . . . . . . 50 10.4 CPIM compatibility . . . . . . . . . . . . . . . . . . . . . 50
10.5 PKI Considerations . . . . . . . . . . . . . . . . . . . . . 50 10.5 PKI Considerations . . . . . . . . . . . . . . . . . . . . . 50
11. Changes from Previous Draft Versions . . . . . . . . . . . . 50 11. Changes from Previous Draft Versions . . . . . . . . . . . . 51
11.1 draft-ietf-simple-message-sessions-01 . . . . . . . . . . . 51 11.1 draft-ietf-simple-message-sessions-02 . . . . . . . . . . . 51
11.2 draft-ietf-simple-message-sessions-00 . . . . . . . . . . . 51 11.2 draft-ietf-simple-message-sessions-01 . . . . . . . . . . . 51
11.3 draft-campbell-simple-im-sessions-01 . . . . . . . . . . . . 52 11.3 draft-ietf-simple-message-sessions-00 . . . . . . . . . . . 52
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 11.4 draft-campbell-simple-im-sessions-01 . . . . . . . . . . . . 52
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53
Normative References . . . . . . . . . . . . . . . . . . . . 53 Normative References . . . . . . . . . . . . . . . . . . . . 53
Informational References . . . . . . . . . . . . . . . . . . 53 Informational References . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55
Intellectual Property and Copyright Statements . . . . . . . 56 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
imaginative session, but there is no formal relationship between one
message and another.
There are also applications in which it is useful for instant There are also applications in which it is useful for instant
messages to be associated together in some way. For example, a user messages to be formally associated in a session. For example, a user
may wish to join a text conference, participate in the conference for may wish to join a text conference, participate in the conference for
some period of time, then leave the conference. This usage is some period of time, then leave the conference. This usage is
analogous to regular media sessions that are typically initiated, analogous to regular media sessions that are typically initiated,
managed, and terminated using SIP. We commonly refer to this model as managed, and terminated using SIP. We commonly refer to this model as
session-mode messaging. session-mode messaging.
One of the primary purposes of SIP and SDP (Section 6) is the One of the primary purposes of SIP and SDP (Section 6) is the
management of media sessions. Session-mode messaging can be thought management of media sessions. Session-mode messaging can be thought
of as a media session like any other. This document describes the of as a media session like any other. This document describes the
motivations for session-mode messaging, the Message Session Relay motivations for session-mode messaging, the Message Session Relay
skipping to change at page 4, line 40 skipping to change at page 4, line 43
Message sessions offer several advantages over page-mode messages. Message sessions offer several advantages over page-mode messages.
For message exchanges that include more than a small number of For message exchanges that include more than a small number of
message transactions, message sessions offer a way to remove message transactions, message sessions offer a way to remove
messaging load from intervening SIP proxies. For example, a minimal messaging load from intervening SIP proxies. For example, a minimal
session setup and tear-down requires one INVITE/ACK transaction, and session setup and tear-down requires one INVITE/ACK transaction, and
one BYE transaction, for a total of 5 SIP messages. Normal SIP one BYE transaction, for a total of 5 SIP messages. Normal SIP
request routing allows for all but the initial INVITE transaction to request routing allows for all but the initial INVITE transaction to
bypass any intervening proxies that do not specifically request to be bypass any intervening proxies that do not specifically request to be
in the path for future requests. Session-mode messages never cross in the path for future requests. Session-mode messages never cross
the SIP proxies themselves, unless proxies also act as message the SIP proxies themselves.
relays.
Each page-mode message involves a complete SIP transaction, that is, Each page-mode message involves a complete SIP transaction, that is,
a request and a response. Any page-mode message exchange that a request and a response. Any page-mode message exchange that
involves more than 2 MESSAGE requests will generate more SIP requests involves more than 2 MESSAGE requests will generate more SIP requests
than a minimal session initiation sequence. Since MESSAGE is normally than a minimal session initiation sequence. Since MESSAGE is normally
used outside of a SIP dialog, these requests will typically traverse used outside of a SIP dialog, these requests will typically traverse
the entire proxy network between the endpoints. the entire proxy network between the endpoints.
Due to network congestion concerns, the MESSAGE method has Due to network congestion concerns, the MESSAGE method has
significant limitations in message size, a prohibition against significant limitations in message size, a prohibition against
overlapping requests, etc. Much of this has been required because of overlapping requests, etc. Much of this has been required because of
perceived limitations in the congestion-avoidance features of SIP perceived limitations in the congestion-avoidance features of SIP
itself. Work is in progress to mitigate these concerns. itself. Work is in progress to mitigate these concerns.
However, session-mode messages are always sent over reliable, However, session-mode messages are always sent over reliable,
congestion-safe transports. Therefore, there are no restrictions on congestion-safe transports. Therefore, there are no restrictions on
message sizes. There is no requirement to wait for acknowledgement, message sizes. There is no requirement to wait for acknowledgement
so that message transactions can be overlapped. before sending another message, so that message transactions can be
overlapped.
Message sessions allow greater efficiency for secure message Message sessions allow greater efficiency for secure message
exchanges. The SIP MESSAGE request inherits the S/MIME features of exchanges. The SIP MESSAGE request inherits the S/MIME features of
SIP, allowing a message to be signed and/or encrypted. However, this SIP, allowing a message to be signed and/or encrypted. However, this
approach requires public key operations for each message. With approach requires public key operations for each message. With
session-mode messaging, a session key can be established at the time session-mode messaging, a session key can be established at the time
of session initiation. This key can be used to protect each message of session initiation. This key can be used to protect each message
that is part of the session. This requires only symmetric key that is part of the session. This requires only symmetric key
operations for each subsequent IM, and no additional certificate operations for each subsequent IM, and no additional certificate
exchanges are required after the initial exchange. The establishment exchanges are required after the initial exchange. The establishment
skipping to change at page 8, line 41 skipping to change at page 8, line 24
enforcement. For example, parts of the financial industry require the enforcement. For example, parts of the financial industry require the
logging of all communication. logging of all communication.
However, the use of such relays has a significant impact on the However, the use of such relays has a significant impact on the
scalability of MSRP. Each relay will require two TCP connections for scalability of MSRP. Each relay will require two TCP connections for
each session in use, as well as memory for local session state each session in use, as well as memory for local session state
storage. Most general purpose platforms on which one might implement storage. Most general purpose platforms on which one might implement
MSRP relays will have relatively low limits on the number of MSRP relays will have relatively low limits on the number of
simultaneous TCP connections they can handle. simultaneous TCP connections they can handle.
Therefore relays SHOULD NOT be used indescrimantly. In the absence of Therefore relays SHOULD NOT be used indiscriminately. In the absence
strong reasons to use relays, MSRP endpoints SHOULD be configured to of strong reasons to use relays, MSRP endpoints SHOULD be configured
set up point-to-point sessions. to set up point-to-point sessions.
MSRP supports the use of two relays, where each endpoint has a relay MSRP supports the use of two relays, where each endpoint has a relay
acting on its behalf. However, most of the network topology issues acting on its behalf. However, most of the network topology issues
mentioned above can work with a single relay, if that relay is mentioned above can work with a single relay, if that relay is
reachable by both endpoints. Dual relays are only needed for cases of reachable by both endpoints. Dual relays are only needed for cases of
very strict firewall policy, such as when only specific hosts are very strict firewall policy, such as when only specific hosts are
allowed to connect to the outside world; or situations requiring allowed to connect to the outside world; or situations requiring
strict policy enforcement at both endpoint domains. If a given usage strict policy enforcement at both endpoint domains. If a given usage
scenario can be solved with a single relay, then a second relay scenario can be solved with a single relay, then a second relay
SHOULD NOT be used. SHOULD NOT be used.
In spite of these recommendations, relays serve a real purpose in In spite of these recommendations, relays serve a real purpose in
that the increase the likelihood of two arbitrary endpoints being that they increase the likelihood of two arbitrary endpoints being
able to talk to one another. Therefore if a provider deploys MSRP able to talk to one another. Therefore if a provider deploys MSRP
endpoints in a network configuration that prevents them from endpoints in a network configuration that prevents them from
receiving TCP connections from arbitrary peers, and does not wish to receiving TCP connections from arbitrary peers, and does not wish to
explicitly prevent MSRP communication with the outside world, then explicitly prevent MSRP communication with the outside world, then
the provider SHOULD provide its endpoints with the use of an MSRP the provider SHOULD provide its endpoints with the use of an MSRP
relay that is reachable from arbitrary peers. relay that is reachable from arbitrary peers.
5.2 Transferring Large Content 5.2 Transferring Large Content
MSRP endpoints may attempt to send very long messages on 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
the impact of sending very large messages over MSRP. The primary the impact of sending very large messages over MSRP. The primary
impact is, since MSRP is sent over TCP, is that any additional impact is, since MSRP is sent over TCP, is that any additional
skipping to change at page 9, line 48 skipping to change at page 9, line 31
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.
Open Issue: Do we need a mechanism to communicate the purpose of
the session? It has been mentioned that the peer may not realize
the purpose of the session, and start using it for normal
messaging. Also, there has been discussion that we need a stronger
mechanism to avoid transaction timeouts caused by long requests.
5.3 Connection Sharing 5.3 Connection Sharing
The SIMPLE working group spent quite a bit of effort in the The SIMPLE working group spent quite a bit of effort in the
consideration of shared TCP connections. Connection sharing would consideration of shared TCP connections. Connection sharing would
offer value whenever a large number of message sessions cross the offer value whenever a large number of message sessions cross the
same two adjacent devices. This situation is likely to occur in 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 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 endpoints are multiuser devices, as is likely with web-hosted
messaging services. messaging services.
skipping to change at page 10, line 31 skipping to change at page 10, line 20
It may be possible to relax this requirement using other transport It may be possible to relax this requirement using other transport
protocols, such as SCTP. The lack of connection sharing in this protocols, such as SCTP. The lack of connection sharing in this
document should not be construed to prohibit shared connections on document should not be construed to prohibit shared connections on
other such protocols. However, such specification is beyond the scope other such protocols. However, such specification is beyond the scope
of this document. 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 SIP Description Protocol (SDP) [1] offer-answer mechanism, carried in the
[2] or any other protocol supporting it. MSRP borrows the idea of the Session Initiation Protocol (SIP) [2] or any other protocol
direction attributes from COMEDIA [18], but does not depend on that supporting it. MSRP borrows the idea of the direction attributes from
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 SHOULD be set to 9999. An exception is when the port field
value is set to zero, according to normal SDP usage. value is set to zero, according to normal SDP usage.
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 MUST indicate the MIME content-types that the The format list list is ignored for MSRP. This is because MSRP
endpoint is willing to accept in the payload of SEND requests. If the formats are specified as MIME content types, which are not convenient
final entry in the format list is a "*", this indicates that the to encode in the SDP format list syntax. Instead, the allowed formats
endpoint is may be willing to receive other types as well, but the are negotiated using "a"-line attributes. For MSRP sessions, the
types listed explicitly are preferred. The format list in the SDP format list SHOULD contain a "*" character, and nothing else.
answer MUST be the same as, or a subset of, the list provided in the
offer.
A "*" in the format list indicates that the sender may attempt to
send messages with other media types that have not been explicitly
listed. If the receiver is able to process the media type, it does
so. If not, it will respond with a 415. Note that all explicit
entries in the format list should be considered preferred over any
non-listed types. This feature is needed as, otherwise, the format
list for IM devices may be prohibitively large.
The m-line format list may include MIME wrapper types, that is,
mime formats that contain other types internally. The types listed
in the format field can be used both as the root payload, or may
be contained in container types. (Note that the container type
must also be listed in the format list.) A list of types that are
only allowed when wrapped in containers can be communicated in the
accept-wrapped-types (Section 6.3) attribute.
The port field in the M-line is not normally used to determine the The port field in the M-line is not normally used to determine the
port to which to connect. Rather, the actual port is determined by port to which to connect. Rather, the actual port is determined by
the contents of the session URL (Section 7.1). However, a port value the contents of the session URL (Section 7.1). However, a port value
of zero has the normal SDP meaning. of zero has the normal SDP meaning.
The following example illustrates an m-line for a message session, The following example illustrates an m-line for a message session,
where the endpoint is willing to accept root payloads of message/ where the endpoint is willing to accept root payloads of message/
cpim, plain text or HTML. The second two types could either be cpim, plain text or HTML. The second two types could either be
presented as the root body, or could be contained within message/cpim presented as the root body, or could be contained within message/cpim
bodies. bodies.
m=message 9999 msrp/tcp message/cpim text/plain text/html 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, or has a relay accept the
skipping to change at page 12, line 18 skipping to change at page 11, line 36
is said to "visit" the session, and is known as the visiting is said to "visit" the session, and is known 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"
passive = "passive" [sp timeout] passive = "passive"
both = "both" both = "both" [sp timeout]
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, or can arrange for a relay to host the
session on its behalf, then it SHOULD select "both". The endpoint session on its behalf, then it SHOULD select "both". The endpoint
skipping to change at page 13, line 5 skipping to change at page 12, line 22
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.
6.3 MIME Wrappers 6.3 The Accept Types Attribute
The MIME content-types in the M-line format list will often include MSRP can carry any MIME encoded payload. Endpoints specify MIME
compound types; that is, types that contain other types. For example, content types that they are willing to receive in the accept types
"message/cpim" or "multipart/mixed." Occasionally and endpoint will "a"-line attribute. This attribute has the following syntax:
need to specify a MIME body type that can only be used if wrapped
inside a listed container type. accept-types = accept-types-label ":" format-list
accept-types-label = "accept-types"
format-list = format-entry *( SP format-entry)
format-entry = (type "/" subtype) / ("*")
type = token
subtype = token
SDP offers for MSRP sessions MUST include an accept-types attribute.
SDP answers MUST also include the attribute, which MUST contain
either the same list as in the offer or a subset of that list.
A "*" entry in the accept-types attribute indicates that the sender
may attempt to send messages with media types that have not been
explicitly listed. If the receiver is able to process the media type,
it does so. If not, it will respond with a 415. Note that all
explicit entries SHOULD be considered preferred over any non-listed
types. This feature is needed as, otherwise, the list of formats for
rich IM devices may be prohibitively large.
The accept-types attribute may include container types, that is, mime
formats that contain other types internally. If compound types are
used, the types listed in the accept-types attribute may be used both
as the root payload, or may be wrapped in a listed container type.
(Note that the container type MUST also be listed in the accept-types
attribute.)
6.4 MIME Wrappers
The MIME content-types in the accept-types attribute will often
include container types; that is, types that contain other types. For
example, "message/cpim" or "multipart/mixed." Occasionally an
endpoint will need to specify a MIME body type that can only be used
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 the format list The format-list element has the identical syntax as defined for the
in the m-line. The semantics for this attribute are identical to accept-types attribute. The semantics for this attribute are
those of the m-line format list, with the exception that the identical to those of the accept-types attribute, with the exception
specified types may only be used when wrapped inside containers. The that the specified types may only be used when wrapped inside
container types would be specified on the m-line normally. Since any containers. Only types listed in accept-types may be used as the
type listed on the m-line may be used both as a root body, or wrapped "root" type for the entire body. Since any type listed in
in other bodies, format entries from the m-line SHOULD NOT be accept-types may be used both as a root body, and wrapped in other
repeated in this attribute. bodies, format entries from the m-line SHOULD NOT be repeated in this
attribute.
This approach does not allow for specifying distinct lists of This approach does not allow for specifying distinct lists of
acceptable wrapped types for different types of containers. If an acceptable wrapped types for different types of containers. If an
endpoint understands a MIME type in the context of one wrapper, it is endpoint understands a MIME type in the context of one wrapper, it is
assumed to understand it in the context of any other acceptable assumed to understand it in the context of any other acceptable
wrappers, subject to any constraints defined by the wrapper types wrappers, subject to any constraints defined by the wrapper types
themselves. themselves.
The approach of specifying types that are only allowed inside of The approach of specifying types that are only allowed inside of
containers separately from the primary payload types allows an containers separately from the primary payload types allows an
endpoint to force the use of certain wrappers. For example, a CPIM endpoint to force the use of certain wrappers. For example, a CPIM
gateway device may require all messages to be wrapped inside gateway device may require all messages to be wrapped inside
message/cpim bodies, but may allow several content types inside message/cpim bodies, but may allow several content types inside
the wrapper. If the gateway were to specify the wrapped types in the wrapper. If the gateway were to specify the wrapped types in
the m-line format list, its peer could choose to use those types the accept-types attribute, its peer could choose to use those
without the wrapper. types without the wrapper.
6.4 URL Negotiations 6.5 URL Negotiations
An MSRP session is identified by an MSRP URL, which is determined by An MSRP session is identified by an MSRP URL, which is determined by
the hosting endpoint, and negotiated in the SDP exchange. Any SDP the hosting endpoint, and negotiated in the SDP exchange. Any SDP
offer or answer that creates a possibility that the sender will host offer or answer that creates a possibility that the sender will host
the session, that is, contains a direction value of "passive" or the session, that is, it contains a direction value of "passive" or
"both", MUST contain an MSRP URL in a session attribute. This "both", MUST contain an MSRP URL in a session attribute. This
attribute has the following syntax: attribute has the following syntax:
a=session:<MSRP_URL> a=session:<MSRP_URL>
where <MSRP_URL> is an MSRP or MSRPS URL as defined in Section 7.1. where <MSRP_URL> is an MSRP or MSRPS URL as defined in Section 7.1.
The visitor will use the session URL established by the host both to The 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 meeting 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 c=IN IP4 useless.host.name
m=message 9999 msrp/tcp text/plain m=message 9999 msrp/tcp *
a=accept-types:text/plain
a=direction:both a=direction:both
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 or relay. Further, since the
peer endpoint will use the session URL to identify itself when peer endpoint will use the session URL to identify itself when
connecting, it SHOULD be hard to guess, and protected from connecting, it SHOULD be hard to guess, and protected from
eavesdroppers. This will be discussed in more detail in Section 10. eavesdroppers. This will be discussed in more detail in Section 10.
6.5 Example SDP Exchange 6.6 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:
c=IN IP4 alice.example.com c=IN IP4 alice.example.com
m=message 9999 msrp/tcp message/cpim text/plain text/html m=message 9999 msrp/tcp *
a=accept-types: message/cpim text/plain text/html
a=direction:both a=direction:both
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:
c=IN IP4 dontlookhere c=IN IP4 dontlookhere
m=message 9999 msrp/tcp message/cpim text/plain m=message 9999 msrp/tcp *
a=accept-types:message/cpim text/plain
a=direction:active a=direction:active
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.
MSRP messages MUST be sent over reliable, congestion-controlled, MSRP messages MUST be sent over a reliable, congestion-controlled,
connection-oriented transport protocols, such as TCP. connection-oriented transport protocol. This document specifies the
use of MSRP over TCP. Other documents may specify bindings for other
such protocols.
7.1 MSRP URLs 7.1 MSRP URLs
MSRP sessions are identified by MSRP URLs. An MSRP URL follows a MSRP sessions are identified by MSRP URLs. An MSRP URL follows a
subset of the URL syntax in Appendix A of RFC2396 [4], with a scheme subset of the URL syntax in Appendix A of RFC2396 [4], with a scheme
of "msrp": of "msrp":
msrp_url = "msrp" ":" "//" [userinfo] hostport ["/' resource] msrp_url = "msrp" ":" "//" [userinfo] hostport ["/' resource]
resource = 1*unreserved resource = 1*unreserved
The constructions for "userinfo", "hostport", and "unreserved" are The constructions for "userinfo", "hostport", and "unreserved" are
detailed in RFC2396 [4]. detailed in RFC2396 [4].
An MSRP URL server part identifies the hosting device of an MSRP An MSRP URL server part identifies 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
skipping to change at page 15, line 36 skipping to change at page 15, line 40
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.
However, this value should not be considered a default, as the URL This value SHOULD NOT be considered a default, as the URL process
process described herein will always explicitly resolve a port described herein will always explicitly resolve a port number.
number. However, the URLs SHOULD be configured so that the However, the URLs SHOULD be configured so that the recommended port
recommended port is used whenever appropriate. This makes life easier is used whenever appropriate. This makes life easier for network
for network administrators who need to manage firewall policy for administrators who need to manage firewall policy for MSRP.
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:
msrp://host.example.com:8493/asfd34 msrp://host.example.com:8493/asfd34
7.1.1 MSRP URL Comparison 7.1.1 MSRP URL Comparison
MSRP URL comparisons MUST be performed according to the following MSRP URL comparisons MUST be performed according to the following
rules: rules:
The host part is compared as case insensitive. 1. The host part is compared as case insensitive.
If the port exists explicitly in either URL, then it must match 2. If the port exists explicitly in either URL, then it must match
exactly. An URL with an explicit port is never equivalent to exactly. An URL with an explicit port is never equivalent to
another with no port specified. another with no port specified.
The resource part is compared as case insensitive. A URL without a 3. The resource part is compared as case insensitive. A URL without
resource part is never equivalent to one that includes a resource a resource part is never equivalent to one that includes a
part. resource part.
Userinfo parts are not considered for URL comparison. 4. Userinfo parts are not considered for URL comparison.
Path normalization is not relevant for MSRP URLs. Escape Path normalization is not relevant for MSRP URLs. Escape
normalization is not required, since the relevant parts are limited normalization is not required, since the relevant parts are limited
to unreserved characters. to unreserved characters.
7.1.2 Resolving MSRP Host Device 7.1.2 Resolving MSRP Host Device
An MSRP host device is identified by the server part of an MSRP URL. An MSRP host device is identified by the server part of an MSRP URL.
If the server part contains a numeric IP address and port, they MUST If the server part contains a numeric IP address and port, they MUST
be used as listed.. be used as listed.
If the server part contains a host name and a port, the connecting If the server part contains a host name and a port, the connecting
device MUST determine a host address by doing an A or AAAA DNS query, device MUST determine a host address by doing an A or AAAA DNS query,
and use the port as listed. and use the port as listed.
If the server part contains a host name but no port, the connecting If the server part contains a host name but no port, the connecting
device MUST perform the following steps: device MUST perform the following steps:
1. Construct an SRV [6] query string by prefixing the host name 1. Construct an SRV [6] query string by prefixing the host name
with the service field "_msrp" and the protocol field ("_tcp" for with the service field "_msrp" and the protocol field ("_tcp" for
skipping to change at page 18, line 10 skipping to change at page 17, line 51
responses are distinguished from one another by the first line. The responses are distinguished from one another by the first line. The
first line of a Request takes the form of the request-start entry first line of a Request takes the form of the request-start entry
below. Likewise, the first line of a response takes the form of below. Likewise, the first line of a response takes the form of
response-start. The syntax for an MSRP message is as follows: response-start. The syntax for an MSRP message is as follows:
msrp-message = request-start/response-start *(header CRLF) msrp-message = request-start/response-start *(header CRLF)
[CRLF body] [CRLF body]
request-start = "MSRP" SP length SP Method CRLF request-start = "MSRP" SP length SP Method CRLF
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, exclusive of the start line.
Method = SEND / BIND / VISIT length = 1*DIGIT ; the length of the message,
; exclusive of the start line.
Method = SEND / BIND / VISIT / other-method
other-method = token
header = Client-Authenticate / Server-Challenge / header = Client-Authenticate / Server-Challenge /
Transaction-ID / Session-URL/ Content-Type / Expires Transaction-ID / Session-URL/ Content-Type / Expires
Status-Code = 200 ;Success Status-Code = 200 ;Success
/ 400 ;Bad Request / 400 ;Bad Request
/ 401 ;Authentication Required / 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 / 500 ;Cannot Deliver
skipping to change at page 18, line 23 skipping to change at page 18, line 18
Transaction-ID / Session-URL/ Content-Type / Expires Transaction-ID / Session-URL/ Content-Type / Expires
Status-Code = 200 ;Success Status-Code = 200 ;Success
/ 400 ;Bad Request / 400 ;Bad Request
/ 401 ;Authentication Required / 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 / 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 Client-Authenticate = "CAuth" ":" credentials
Server-Challenge = "SChal" ":" challenge 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 Expires = "Exp"":" delta-seconds
delta-seconds= 1*DIGIT ; Integer number of 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.
skipping to change at page 19, line 10 skipping to change at page 19, line 30
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
size of the timeout interval is a matter of local policy, with a timeout interval SHOULD be 30 seconds, but other values may be
default of 30 seconds after a request has been completely sent. 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) and may have one or two relays. 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
skipping to change at page 19, line 51 skipping to change at page 20, line 23
using a relay, it MUST perform the following steps: using a relay, it MUST perform the following steps:
1. Construct a session MSRP URL . This URL MUST be resolvable to the 1. Construct a session MSRP URL . This URL MUST be resolvable to the
offerer. The URL SHOULD be temporary, SHOULD be hard to guess, offerer. The URL SHOULD be temporary, SHOULD be hard to guess,
and MUST not duplicate the URL of any other session currently and MUST not duplicate the URL of any other session currently
hosted by the offerer. 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 format list. The list of allowed IM payload formats in the accept-types attribute.
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.4. 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.
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".
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 of 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 wishes to host, but will allow the answerer to host, that the offerer prefers to host, but will allow the answerer to
in which case the answerer SHOULD act as the visitor, but MAY choose host. In this case the answerer SHOULD act as the visitor, but MAY
to host. A value of "passive" means the offerer insists upon hosting, choose to host. A value of "passive" means the offerer insists upon
in which case the answerer MUST act as visitor or decline the offer. hosting, in which case the answerer MUST act as visitor or decline
the offer.
If the answerer chooses to participate as a visitor, it MUST perform If the answerer chooses to participate as a visitor, it MUST perform
the following steps: the following steps:
1. Determine the host address and port from the session URL, 1. Determine the host address and port from the session URL,
following the procedures in section Section 7.1 following the procedures in section Section 7.1
2. Connect to the host address and port, using the transport 2. Connect to the host address and port, using the transport
protocol from the M-line. protocol from the M-line.
skipping to change at page 21, line 18 skipping to change at page 21, line 38
start-line. start-line.
4. Send the request and wait for a response 4. Send the request and wait for a response
5. If the transaction succeeds, send a SDP answer via the signaling 5. If the transaction succeeds, send a SDP answer via the signaling
protocol, according to the following rules: protocol, according to the following rules:
1. The C-line is copied unmodified from the offer. 1. The C-line is copied unmodified from the offer.
2. The M-Line contains a dummy port value, the protocol field 2. The M-Line contains a dummy port value, the protocol field
from the original offer, and a format list describing the from the original offer, and the accept-types attribute
SEND payload media types that the answerer is willing to contains the SEND payload media types that the answerer is
accept. The format list in the answer MUST be either the same willing to accept. The accept-types attribute in the answer
as the format list in the offer, or a subset. MUST be either the same as that of the offer, or it MUST be a
subset.
3. A direction attribute containing the value "active". 3. A direction attribute containing the value "active".
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
skipping to change at page 23, line 34 skipping to change at page 24, line 4
7.4.3 Sending Instant Messages on a Session 7.4.3 Sending Instant Messages on a Session
Once a MSRP session has been established, either endpoint may send Once a MSRP session has been established, either endpoint may send
instant messages to its peer using the SEND method. When an endpoint instant messages to its peer using the SEND method. When an endpoint
wishes to do so, it MUST construct a SEND request according to the wishes to do so, it MUST construct a SEND request according to the
following process: following process:
1. Insert the message payload in the body, and the media type in the 1. Insert the message payload in the body, and the media type in the
Content-Type header field. The media type MUST match one of the Content-Type header field. The media type MUST match one of the
types in the format list negotiated in the SDP exchange. If a "*" types in the format list negotiated in the SDP exchange. If a "*"
is present in the format list, then the media type SHOULD match was present in the accept-types attribute, then the media type
one of the explicitly listed entries, but MAY be any other SHOULD match one of the explicitly listed entries, but MAY be any
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 5xx response code is received, the transaction failed, but
may possibly be successful if retried. The endpoint MAY retry the other transactions may still succeed in the future. The endpoint
request as a new transaction, that is, with a new TR-ID value. If MAY attempt to send the message content again in a new request,
the endpoint receives 5xx responses more than some threshold that is, with a new TR-ID value. If the endpoint receives 5xx
number of times in a row, it SHOULD assume the session has responses more than some threshold number of times in a row, it
failed, and initiate tear-down via the signaling protocol. The SHOULD assume the session has failed, and initiate tear-down via
threshold value is a matter of local policy. the signaling protocol. The threshold value is a matter of local
policy.
6. If a 415 response is received, this indicates the recipient is 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 7. If any other response code is received, the endpoint SHOULD
assume the session has failed, and initiate tear-down. assume the session has failed, and initiate tear-down.
Normally transaction timeouts are treated the same as transactions
that receive 5xx responses But, unlike transactions that fail
explicitly, requests that have been timed out may in fact have
been delivered 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
mechanism? If retries were sent with with the TR-ID, then the
recipient could recognize a duplicate message if it occurs in the
same session.
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.
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.
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. The
process for this differs depending on whether the session is hosted process for this differs depending on whether the session is hosted
directly by the host, or an a relay. 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. If the host is using an MSRP relay, it MUST send a BIND
containing an expires value of zero. This request MUST be sent host containing an expires value of zero. This request MUST be sent on the
connection established by the original BIND request. This BIND host connection established by the original BIND request. This BIND
request MUST include the session URL in the S-URL header field. 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. If for some reason the
host fails to destroy session state, the state will be invalidated host fails to destroy session state, the state will be invalidated
anyway when the inactivity timer expires. anyway when the inactivity timer expires.
When an endpoint chooses to close a session, it may have SEND
transactions outstanding. For example, it may have send SEND requests
to which it has not yet received a response, or it may have received
SEND requests that to which it has not responded. Once an endpoint
has decided to close the connection, it SHOULD wait for such
outstanding transactions to complete. It SHOULD NOT generate any new
SEND transactions, and it MAY choose not to respond to any new SEND
requests that are received after it decides to close the session. It
SHOULD not respond to any new messages that arrive after it signals
its intent to close the session.
When an endpoint is signaled of its peer's intent to close a session,
it SHOULD NOT initiate any more SEND requests. It SHOULD wait for any
outstanding transactions that it initiated to complete, and it SHOULD
attempt respond to any open SEND transactions received prior to being
signaled.
It is not possible to completely eliminate the chance of a session
terminating with incomplete SEND transactions. When this occurs, an
endpoint SHOULD clearly inform the user that the messages mat not
have been delivered.
7.4.5 Session Inactivity Timer 7.4.5 Session Inactivity Timer
State associated with MSRP sessions, either at the host endpoint, or State associated with MSRP sessions, either at the host endpoint, or
a hosting or visiting relay, is soft-state; that is, it expires over 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 time if no message activity occurs. Each such device maintains a pair
of inactivity timer, each with an initial value of 1 minute. One of of inactivity timer, each with an initial value of 12 minutes. One of
these timers is assigned for each endpoint. these timers is assigned for each endpoint.
All devices use the same, predetermined timer expiration value. All devices use the same, predetermined timer expiration value.
While there might be some utility in negotiating this timer on a While there might be some utility in negotiating this timer on a
per device basis, such negotiation would add a great deal of per device basis, such negotiation would add a great deal of
complexity to MSRP. 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 When a hosting device or visiting relay returns a successful response
to a VISIT request, it MUST initialize both timers. The device MUST to a VISIT request, it MUST initialize both timers. The device MUST
reset a timer anytime the associated endpoint sends a SEND request. reset a timer anytime the associated endpoint sends a SEND request.
If either timer expires without being reset, the device MUST If either timer expires without being reset, the device MUST
invalidate the session, using normal procedures depending on the invalidate the session, using normal procedures depending on the
device's role in the session. device's role in the session.
Each endpoint MUST keep a similar timer, which it initializes when Each endpoint MUST keep a similar timer, which it initializes when
the session is created from its perspective. For the host endpoint, the session is created from its perspective. For the host endpoint,
skipping to change at page 25, line 34 skipping to change at page 27, line 5
VISIT request. Each endpoint resets its timer whenever it sends a VISIT request. Each endpoint resets its timer whenever it sends a
SEND request. If an endpoint inactivity timer approaches expiration, SEND request. If an endpoint inactivity timer approaches expiration,
and the endpoint wishes to continue participating in the session, it 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 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 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 so that there is sufficient time for the SEND request to traverse to
the opposite endpoint. If the endpoint waits to the last moment, the opposite endpoint. If the endpoint waits to the last moment,
there is a danger that it will not be received by all relevant there is a danger that it will not be received by all relevant
devices in time to prevent session destruction. 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 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 two associated network connections. The connection
hosting device and the host endpoint is known as the host connection. between the hosting device and the host endpoint is known as the host
The connection with the visiting endpoint is the visiting connection. connection. The connection with the visiting endpoint is the visiting
Note that when the session state is hosted directly by an endpoint, connection. Note that when the session state is hosted directly by
the host connection may not involve a physical network connection; an endpoint, the host connection may not involve a physical network
rather it is a logical connection the device maintains with itself. 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(s).
If a connection fails for any reason, the session hosting device MUST If a connection fails for any reason, the session hosting device MUST
invalidate the session state. This is true regardless of whether the invalidate the session state. This is true regardless of whether the
dropped connection is the host or visiting connection. Once a dropped connection is the host or visiting connection. Once a
connection is dropped, the associated session state MUST NOT be connection is dropped, the associated session state MUST NOT be
reused. If the endpoints wish to continue to communicate after a reused. If the endpoints wish to continue to communicate after a
connection failure, they must initiate a new session. An endpoint connection failure, they must initiate a new session. An endpoint
skipping to change at page 26, line 24 skipping to change at page 27, line 48
the endpoint tries to recover the session. If the endpoint the endpoint tries to recover the session. If the endpoint
attempts to reconnect prior to the hosting device noticing the attempts to reconnect prior to the hosting device noticing the
failure, the hosting device will interpret the recovery attempt as failure, the hosting device will interpret the recovery attempt as
a conflict. The only way around this would be to force the hosting a conflict. The only way around this would be to force the hosting
device to do a liveness check on the original connection, which device to do a liveness check on the original connection, which
would create a lot of complexity and overhead that do not seem to would create a lot of complexity and overhead that do not seem to
be worth the trouble. be worth the trouble.
7.5 MSRP Relays 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 7.5.1 Establishing Session State at a Relay
An endpoint that wishes to host a MSRP session MAY do so by An endpoint that wishes to host a MSRP session MAY do so by
initiating session state at a MSRP relay, rather than hosting initiating session state at a MSRP relay, rather than hosting
directly. An endpoint may wish to do this because network topology or directly. An endpoint may wish to do this because network topology or
local policy prevents a peer from connecting directly to the local policy prevents a peer from connecting directly to the
endpoint. The use of a relay should not be the default case, that is, 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 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 policy SHOULD host the session directly. In order to use a relay, an
MSRP endpoint MUST have knowledge of that relay's existence and MSRP endpoint MUST have knowledge of that relay's existence and
location.. location.
We previously mentioned how an endpoint wishing to host a MSRP We previously mentioned how an endpoint wishing to host a MSRP
session constructs session URL. When using a relay, the endpoint session constructs the session URL. When using a relay, the endpoint
delegates that responsibility to the relay. delegates that responsibility to the relay.
To establish session state at a relay, the endpoint MUST perform the To establish session state at a relay, the endpoint MUST perform the
following steps: following steps:
1. Open a network connection to the relay at the relays address and 1. Open a network connection to the relay at the relays address and
port. Normally, this information will be resolved from an MSRP port. Normally, this information will be resolved from an MSRP
URL representing the relay, although the relay MAY be configured URL representing the relay, although the relay MAY be configured
with an explicit address and port, rather than a URL. with an explicit address and port, rather than a URL.
2. Construct a BIND request with a S-URL that refers to the relay. 2. Construct a BIND request with a S-URL that refers to the relay.
3. Set the Expire header field to a desired value. 3. Set the Exp header field to a desired value.
4. Send the BIND request on the connection. 4. Send the BIND request on the connection.
5. Respond to any authentication request from the relay. 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 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 header field as the session URL. The endpoint uses this URL in
exactly the same manner as it had constructed it itself. exactly the same manner as it had constructed it itself.
Additionally, accept the expires value in the response as Additionally, accept the expires value in the response as
pre-visit expiration time. pre-visit expiration time.
skipping to change at page 27, line 26 skipping to change at page 29, line 7
BIND request, it SHOULD authenticate the request, either using BIND request, it SHOULD authenticate the request, either using
digest-authentication, TLS authentication, or some other digest-authentication, TLS authentication, or some other
authentication mechanism. If authentication succeeds, the relay authentication mechanism. If authentication succeeds, the relay
performs the following steps: performs the following steps:
1. Verify the client is authorized to BIND to this relay. If not, 1. Verify the client is authorized to BIND to this relay. If not,
return a 403 response and make no state change. return a 403 response and make no state change.
2. If the client is authorized, construct a session MSRP URL. The 2. If the client is authorized, construct a session MSRP URL. The
URL MUST resolve to the relay. It SHOULD be temporary, and hard URL MUST resolve to the relay. It SHOULD be temporary, and hard
to guess. It MUST not duplicate URL used in any active sessions to guess. It MUST not duplicate any URL used in any active
hosted by the relay. If the relay wishes the visiting endpoint to sessions hosted by the relay. If the relay wishes the visiting
connect over a point other than the MSRP relay well-know port, it endpoint to connect over a port other than the MSRP relay
MUST explicitly add the port number to visitor URL. well-know port, it MUST explicitly add the port number to visitor
URL.
3. Establish the pre-visit expiration time for the session according 3. Establish the pre-visit expiration time for the session according
to section Section 7.4.5. to Section 7.4.5.
4. Create state for the session. The relay MUST associate the 4. Create state for the session. The relay MUST associate the
connection on which the BIND request arrived as the host connection on which the BIND request arrived as the host
connection for the session. connection for the session.
5. Return a 200 response, with the session URL in the S-URL header 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 field, and the pre-visit session expiration time in the Exp
header field. header field.
When an MSRP relay receives a VISIT request, it MUST perform the When an MSRP relay receives a VISIT request, it MUST perform the
skipping to change at page 29, line 44 skipping to change at page 31, line 26
a 500 response. a 500 response.
4. Create local state to associate the connection to the host device 4. Create local state to associate the connection to the host device
with the connection to the visiting device. with the connection to the visiting device.
5. Relay the VISIT request unchanged to the hosting device. 5. Relay the VISIT request unchanged to the hosting device.
6. Relay the response to the VISIT request unchanged to the visiting 6. Relay the response to the VISIT request unchanged to the visiting
endpoint. endpoint.
7. Relay all subsequent arriving on one of the associated 7. Relay all subsequent requests arriving on one of the associated
connections to the peer connection. connections to the peer connection.
If either associated connection fails for any reason, the visiting If either associated connection fails for any reason, the visiting
relay MUST invalidate the session state, and MUST drop the peer relay MUST invalidate the session state, and MUST drop the peer
connection. 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 7.6 Digest Authentication
MSRP relays may use the digest authentication scheme to authenticate MSRP relays may use the digest authentication scheme to authenticate
users. MSRP digest authentication is a simplified version of HTTP users. MSRP digest authentication is a simplified version of HTTP
digest authentication [19], but this specification does not digest authentication [19], but this specification does not
normatively depend on that document. MSRP digest authentication does normatively depend on that document. MSRP digest authentication does
not support the concept of a protection domain, nor does it support not support the concept of a protection domain, nor does it support
integrity protection. Since a user of a relay is expected to have integrity protection. Since a user of a relay is expected to have
credentials for that particular relay, it does not support the realm credentials for that particular relay, it does not support the realm
concept. Finally, since digest authentication is only expected for concept. Finally, since digest authentication is only expected for
skipping to change at page 31, line 13 skipping to change at page 33, line 10
If an endpoint wishes to respond to a digest authentication challenge 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 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 BIND request, identical to the previous request, but with a CAuth
header field containing the response to the challenge. header field containing the response to the challenge.
7.6.1 The SHA1 Algorithm 7.6.1 The SHA1 Algorithm
The only digest authentication algorithm defined in this The only digest authentication algorithm defined in this
specification is SHA1. [9] Other algorithms can be added as specification is SHA1. [9] Other algorithms can be added as
extensions. SHA1 is the default algorithm if no algorithm directive extensions. SHA1 is the default algorithm if no algorithm directive
is present in the challenge. 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: The SHA1 digest is defined as follows:
Let KD(secret, data) denote the string obtained by performing the Let KD(secret, data) denote the string obtained by performing the
digest algorithm to the data "data" with the secret "secret". Let digest algorithm to the data "data" with the secret "secret". Let
H(data) denote the string obtained by performing the checksum H(data) denote the string obtained by performing the checksum
algorithm on the data "data". algorithm on the data "data".
For the "SHA1" algorithm, H(data) = SHA1(data), and KD(secret,data) = For the "SHA1" algorithm, H(data) = SHA1(data), and KD(secret,data) =
H(concat(secret, ":", data) H(concat(secret, ":", data)
The request-digest value in a CAuth header field takes the following Section 7.2 describes the syntax for the request-digest value in a
format. Note that unq(quoted-string) denotes the value of the string CAuth header as 40 digits in lower case hexadecimal notation. The
with the quotes removed. 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) ) > <"> request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > <">
A1 = unq(username-value) ":" shared-secret A1 = unq(username-value) ":" shared-secret ; "unq" denotes removal of quotes
A2 = concat(Method,TR-ID,S-URI) A2 = concat(Method,TR-ID,S-URI)
When the relay receives a CAuth header, it SHOULD check its validity 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 by looking up the shared secret, or H(A1), performing the same digest
operation as performed by the client, and comparing the results to operation as performed by the client, and comparing the results to
the request-digest value. the request-digest value.
7.7 Method Descriptions 7.7 Method Descriptions
This section summarizes the purpose of each MSRP method. All MSRP This section summarizes the purpose of each MSRP method. All MSRP
skipping to change at page 33, line 30 skipping to change at page 35, line 34
7.8.5 415 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.8.6 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.
Open Issue: Do we need to make 426 extensible to support other
types of protection?
7.8.7 481 7.8.7 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.8.8 500
A 500 response indicates that a relay was unable to deliver a SEND A 500 response indicates that a relay was unable to deliver a request
request to the target. to the target.
7.8.9 506 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.9 Header Field Descriptions
skipping to change at page 34, line 18 skipping to change at page 36, line 22
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.9.2 Exp
The Exp header field specifies when the state associated with a BIND The Exp header field specifies when the state associated with a BIND
request will expire, if no successful VISIT request has been request will expire, if no successful VISIT request has been
received.. The value is specified as an integer number of seconds received. The value is specified as an integer number of seconds from
from the time the request is received. BIND requests MUST contain the time the request is received. BIND requests MUST contain this
this header field. Furthermore, successful responses to BIND requests header field. Furthermore, successful responses to BIND requests MUST
MUST also contain the Exp header. also contain the Exp header.
The maximum value for the Exp header field is (2**32)-1 seconds. 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 Exp has no meaning if it occurs in MSRP messages other than BIND
requests, and responses to those requests. MSRP compliant devices requests, and responses to those requests. MSRP compliant devices
SHOULD NOT use Exp in other requests or responses, unless that usage SHOULD NOT use Exp in other requests or responses, unless that usage
is defined in an extension to this specification. is defined in an extension to this specification.
7.9.3 CAuth 7.9.3 CAuth
The CAuth header field is used by a host endpoint to respond to offer The CAuth header field is used by a host endpoint to offer digest
digest authentication credentials to a relay, usually in response to authentication credentials to a relay, in response to a digest
a digest authentication challenge. CAuth SHOULD NOT be present in a authentication challenge. CAuth SHOULD NOT be present in a request of
request of any method other than BIND and VISIT. any method other than BIND and VISIT.
The CAuth credentials adhere to the following syntax:
credentials = "Digest" digest-response The syntax of the CAuth credentials is described in Section 7.2
digest-response = 1#( username | nonce |
response | [ algorithm ] |
[auth-param] )
username = "username" "=" username-value
username-value = quoted-string
response = "response" "=" request-digest
request-digest = <"> 32LHEX <">
LHEX = "0" | "1" | "2" | "3" |
"4" | "5" | "6" | "7" |
"8" | "9" | "a" | "b" |
"c" | "d" | "e" | "f"
The meaning of each value is as follows: The meaning of each value is as follows:
username: The user's account name. username: The user's account name.
nonce: The nonce value copied from the challenge. nonce: The nonce value copied from the challenge.
response: A 32 hex digit string that proves user knowledge of the response: A 32 hex digit string that proves user knowledge of the
shared secret. shared secret.
algorithm: The algorithm value copied from the challenge. algorithm: The algorithm value copied from the challenge.
auth-param: Additional parameters for the sake of extensibility. auth-param: Additional parameters for the sake of extensibility.
7.9.4 SChal 7.9.4 SChal
The SChal header field is used by a relay to carry the challenge in a The SChal header field is used by a relay to carry the challenge in a
digest authentication attempt. Exactly one SChal header field MUST digest authentication attempt. Exactly one SChal header field MUST
exist in a 401 response. The SChal header MUST NOT be used in any exist in a 401 response. The SChal header MUST NOT be used in any
message except for a 401 response. The SChal header field value is message except for a 401 response. The syntax for the SChal challenge
made up of a challenge according to the following syntax: is described in Section 7.2
challenge= digest-scheme SP digest-challenge
digest-scheme = "Digest"
digest-challenge = 1#( nonce | [ algorithm ] |
[auth-param] )
nonce = "nonce" "=" nonce-value
nonce-value = quoted-string
algorithm = "algorithm" "=" ( "SHA1" | token )
The meaning of each value is as follows: The meaning of each value is as follows:
digest scheme: A token to identify the particular authentication digest scheme: A token to identify the particular authentication
scheme. For digest, the value MUST be "Digest." This token is scheme. Since MSRP only supports digest, this value MUST be set to
present for the sake of extensibility. "Digest"
nonce: A server-specified string, which the relay SHOULD uniquely nonce: A server-specified string, which the relay SHOULD uniquely
generate each time it sends a 401 response. This string SHOULD generate each time it sends a 401 response. This string SHOULD
take the form of base64 or hexadecimal data, to avoid the presence take the form of base64 or hexadecimal data, to avoid the presence
of a double-quote character, which is not allowed. of a double-quote character, which is not allowed.
algorithm: A token indicating the algorithms to be used to generate algorithm: A token indicating the algorithms to be used to generate
the digest and checksum. This directive exists for the sake of the digest and checksum. This directive exists for the sake of
extensibility; the only value defined by this document is "SHA1". extensibility; the only value defined by this document is "SHA1".
Absence of this directive indicates a value of "SHA1". Absence of this directive indicates a value of "SHA1".
7.9.5 Content-Type 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
better defining the Content-Type usage possibly moving
content-type into the body, indicating MIME version, etc.
7.9.6 S-URL 7.9.6 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 present in a BIND request, a successful response
to a BIND request, or a VISIT request. to a BIND request, or a VISIT request.
8. Examples 8. Examples
This section shows some example message flows for various common This section shows some example message flows for various common
scenarios. The examples assume SIP is used to transport the SDP scenarios. The examples assume SIP is used to transport the SDP
skipping to change at page 37, line 33 skipping to change at page 38, line 42
|<-----------------------| |<-----------------------|
|(9) (MSRP) 200 OK | |(9) (MSRP) 200 OK |
|----------------------->| |----------------------->|
|(10) (SIP) BYE | |(10) (SIP) BYE |
|----------------------->| |----------------------->|
|(11) (SIP) 200 OK | |(11) (SIP) 200 OK |
|<-----------------------| |<-----------------------|
| | | |
| | | |
1. Alice constructs a session URL of msrp://alicepc.atlanta.com/ 1. Alice constructs a session URL of msrp://
iau39 and listens for a connection on TCP port 7777. alicepc.atlanta.com:7777/iau39 and listens for a connection on
TCP port 7777.
Alice->Bob (SIP): INVITE sip:bob@biloxi.com Alice->Bob (SIP): INVITE sip:bob@biloxi.com
c=IN IP4 fillername c=IN IP4 fillername
m=message 9999 msrp/tcp text/plain m=message 9999 msrp/tcp *
a=accept-types:text/plain
a=direction:both a=direction:both
a=session:msrp://alicepc.atlanta.com/iau39:7777 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/iau39:7777 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 Exp:300
4. Bob->Alice (SIP): 200 OK 4. Bob->Alice (SIP): 200 OK
c=IN IP4 ignorefield c=IN IP4 ignorefield
m=message 9999 msrp/tcp text/plain m=message 9999 msrp/tcp *
a=accept-types:text/plain
a=direction:active a=direction:active
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 26 skipping to change at page 41, line 28
2. Relay->Alice (MSRP): 2. Relay->Alice (MSRP):
MSRP xx 200 OK MSRP xx 200 OK
TR-ID: 321 TR-ID: 321
S-URL: msrp://relay.atlanta.com:7777/iau39 S-URL: msrp://relay.atlanta.com:7777/iau39
Exp:300 Exp:300
3. Alice->Bob (SIP): INVITE sip:bob@biloxi.com 3. Alice->Bob (SIP): INVITE sip:bob@biloxi.com
c=IN IP4 dummyvalue c=IN IP4 dummyvalue
m=message 9999 msrp/tcp text/plain m=message 9999 msrp/tcp *
a=accept-types:text/plain
a=direction:passive a=direction:passive
a=session:msrp://relay.atlanta.com:7777/iau39 a=session:msrp://relay.atlanta.com:7777/iau39
4. Bob->Alice: Open connection to relay.atlanta.com:7777. 4. Bob->Alice: Open connection to relay.atlanta.com:7777.
Bob->Relay (MSRP): Bob->Relay (MSRP):
MSRP xx VISIT MSRP xx VISIT
S-URL:msrp://relay.atlanta.com:7777/iau39 S-URL:msrp://relay.atlanta.com:7777/iau39
TR-ID: msrp:sie09s TR-ID: sie09s
5. Relay->Bob (MSRP): 5. Relay->Bob (MSRP):
MSRP xx 200 OK MSRP xx 200 OK
TR-ID: sie09s TR-ID: sie09s
Exp:300 Exp:300
6. Bob->Alice (SIP): 200 OK 6. Bob->Alice (SIP): 200 OK
c=IN IP4 nobodybutuschickens c=IN IP4 nobodybutuschickens
m=message 9999 msrp/tcp text/plain m=message 9999 msrp/tcp *
a=accept-types:text/plain
a=direction:active a=direction:active
7. Alice->Bob (SIP): ACK 7. Alice->Bob (SIP): ACK
8. Alice->Relay (MSRP): 8. Alice->Relay (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!
9. Relay->Bob (MSRP): 9. Relay->Bob (MSRP):
MSRP xx SEND MSRP xx SEND
skipping to change at page 44, line 16 skipping to change at page 44, line 45
2. AtlantaRelay->Alice (MSRP): 2. AtlantaRelay->Alice (MSRP):
MSRP xx 200 OK MSRP xx 200 OK
TR-ID: 321 TR-ID: 321
S-URL: msrp://relay.atlanta.com:7777/iau39 S-URL: msrp://relay.atlanta.com:7777/iau39
Exp:600 Exp:600
3. Alice->Bob (SIP): INVITE sip:bob@biloxi.com 3. Alice->Bob (SIP): INVITE sip:bob@biloxi.com
c=IN IP4 blahblahblah c=IN IP4 blahblahblah
m=message 9999 msrp/tcp text/plain m=message 9999 msrp/tcp *
a=accept-types:text/plain
a=session:msrp://relay.atlanta.com:7777/iau39 a=session:msrp://relay.atlanta.com:7777/iau39
a=direction:passive a=direction:passive
4. Bob determines that, due to local policy, he must connect 4. Bob determines that, due to local policy, he must connect
through his own relay. through his own relay.
Bob->BiloxiRelay (MSRP): Bob opens a connection to his relay, Bob->BiloxiRelay (MSRP): Bob opens a connection to his relay,
and sends the following: and sends the following:
MSRP xx VISIT MSRP xx VISIT
S-URL: msrp://relay.atlanta.com:7777/iau39 S-URL: msrp://relay.atlanta.com:7777/iau39
TR-ID: 934 TR-ID: 934
skipping to change at page 45, line 9 skipping to change at page 45, line 35
TR-ID: 934 TR-ID: 934
7. BiloxiRelay->Bob(MSRP): 7. BiloxiRelay->Bob(MSRP):
MSRP xx 200 OK MSRP xx 200 OK
TR-ID: 934 TR-ID: 934
8. Bob->Alice (SIP): 200 OK 8. Bob->Alice (SIP): 200 OK
c=IN IP4 stuff c=IN IP4 stuff
m=message 9999 msrp/tcp text/plain m=message 9999 msrp/tcp *
a=accept-types:text/plain
a=direction: active a=direction: active
9. Alice->Bob (SIP): ACK 9. Alice->Bob (SIP): ACK
10. Alice->AtlantaRelay (MSRP): 10. Alice->AtlantaRelay (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!
skipping to change at page 47, line 32 skipping to change at page 47, line 45
with the actual number assigned to this document. with the actual number assigned to this document.
9.3 SDP Parameters 9.3 SDP Parameters
This document registers the following SDP parameters in the This document registers the following SDP parameters in the
sdp-parameters registry: sdp-parameters registry:
9.3.1 Direction 9.3.1 Direction
Attribute-name: direction Attribute-name: direction
Long-form Attribute Name Direction Long-form Attribute Name Direction
Type: Media level Type: Media level
Subject to Charset Attribute No Subject to Charset Attribute No
Purpose and Appropriate Values See Section 6.2. Purpose and Appropriate Values See Section 6.2.
9.3.2 Wrapped Types 9.3.2 Accept Types
Attribute-name: accept-wrapped-types Attribute-name: accept-types
Long-form Attribute Name Acceptable MIME Types
Type: Media level
Subject to Charset Attribute No
Purpose and Appropriate Values See Section 6.3.
Long-form Attribute Name Acceptable MIME Types Inside Wrappers 9.3.3 Wrapped Types
Attribute-name: accept-wrapped-types
Long-form Attribute Name Acceptable MIME Types Inside Wrappers
Type: Media level Type: Media level
Subject to Charset Attribute No Subject to Charset Attribute No
Purpose and Appropriate Values See Section 6.3. Purpose and Appropriate Values See Section 6.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
connection, it MUST watch for the TLS handshake messages to determine connection, it MUST watch for the TLS handshake messages to determine
if a particular connection uses TLS. If the first data received is if a particular connection uses TLS. If the first data received is
not part of a TLS handshake request, the device ceases to watch for not part of a start TLS request, the device ceases to watch for the
the TLS handshake and begins normal MSRP processing. TLS handshake until it reads the entire message. Once the message has
been completely received, the device resumes watching for the start
TLS message.
An MSRP device MAY refuse to accept a given request over a non-TLS An MSRP device MAY refuse to accept a given request over a non-TLS
connection by returning a 426 response, after which it MUST either connection by returning a 426 response.
immediately close the connection, or begin watching for a TLS
handshake request as it would if it had just accepted a connection.
MSRP devices acting in the role of TCP client MAY perform a TLS MSRP devices acting in the role of TCP client MAY perform a TLS
handshake either immediately upon connection, or immediately after handshake at any time, as long as the request occurs between MSRP
receiving a 426 response. They MUST NOT attempt to upgrade to TLS at messages. The endpoint MUST NOT send a start TLS request in the
any other time. middle of an MSRP message.
Allowing clients to upgrade at any time would require the server The working group considered only requiring the endpoint to watch
device to check every single request to determine if it is an MSRP for a TLS handshake at the beginning of the session. However, the
request or a TLS handshake request. The specified approach only endpoint should be able to determine if a new message is a start
requires this check on the initial data received on a connection, TLS request or an MSRP request by only reading ahead three bytes.
or on data received immediately after a 426 response. In both Therefore, the working group chose to allow a session to switch to
cases, the receiver will have to peek ahead in the received data TLS in mid-stream, as long as the switch occurs between MRSP
stream to look for the TLS, then read again from the start once messages.
the presence or absence of TLS has been determined.
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. Ensuring this implies some additional rules. A
relay MUST return an MSRPS URL to a BIND request if the request relay MUST return an MSRPS URL to a BIND request if the request
arrived over TLS and included a MSRPS URI in the S-URI header field. arrived over TLS and included a MSRPS URI in the S-URI header field.
The relay MAY return an MSRPS URI to any BIND request that arrives The relay MAY return an MSRPS URI to any BIND request that arrives
over TLS, but MUST NOT return an MSRP URI to a BIND request that does over TLS, but MUST NOT return an MSRP URI to a BIND request that does
not arrive over TLS. If a relay receives a BIND request with an MSRPS 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 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 response. A relay may insist on always using MSRPS by returning a
skipping to change at page 49, line 21 skipping to change at page 49, line 38
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 visiting relay 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.2 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, regardless of whether the
session is directly hosted by the host endpoint, or is hosted by a session is directly hosted by the host endpoint, or is hosted by a
relay. If an attacker were able to acquire session URL, either by relay. If an attacker were able to acquire the session URL, either by
guessing it or by eavesdropping, there is a window of opportunity in guessing it or by eavesdropping, there is a window of opportunity in
which the attacker could hijack the session by sending a VISIT which the attacker could hijack the session by sending a VISIT
request to the host device before the true visiting endpoint. Because request to the host device before the true visiting endpoint. Because
of this sensitivity, the session URL SHOULD be constructed in a way of this sensitivity, the session URL SHOULD be constructed in a way
to make it difficult to guess, and should be sufficiently random so to make it difficult to guess, and should be sufficiently random so
that it is unlikely to be reused. All mechanisms used to transport that it is unlikely to be reused. All mechanisms used to transport
the session URL to the visitor and back to the host SHOULD be the session URL to the visitor and back to the host SHOULD be
protected from eavesdroppers and 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
skipping to change at page 50, line 20 skipping to change at page 50, line 37
S/MIME. S/MIME.
10.4 CPIM compatibility 10.4 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 format list. include "message/cpim" as the first entry in its SDP accept-types
MSRP endpoints sending instant messages to a peer that has included attribute. MSRP endpoints sending instant messages to a peer that has
'message/cpim" as the first entry in the format list SHOULD included 'message/cpim" as the first entry in the accept-types
encapsulate all instant message bodies in "message/cpim" wrappers. attribute SHOULD encapsulate all instant message bodies in "message/
All MSRP endpoints SHOULD support the S/MIME features of that format. cpim" wrappers. All MSRP endpoints MUST support the message/cpim
type, and SHOULD support the S/MIME features of that format.
10.5 PKI Considerations 10.5 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
skipping to change at page 51, line 4 skipping to change at page 51, line 21
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.
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-01 11.1 draft-ietf-simple-message-sessions-02
Abstract rewritten. Moved all content type negotiation from the "m"-line format list
into "a"-line attributes. Added the accept-types attribute. This
is due to the fact that the sdp format-list syntax is not
conducive to encoding MIME content types values.
Added "other-method" construction to the message syntax to allow
for extensible methods.
Consolidated all syntax definitions into the same section. Cleaned
up ABNF for digest challenge and response syntax.
Changed the session inactivity timeout to 12 minutes.
Required support for the SHA1 alogorithm.
Required support for the message/cpim format.
Fixed lots of editorial issues.
Documented a number of open issues from recent list discussions.
Added architectural considerations section. 11.2 draft-ietf-simple-message-sessions-01
Abstract rewritten.
Added architectural considerations section.
The m-line format list now only describes the root body part for a 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.2 draft-ietf-simple-message-sessions-00 11.3 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.
The MSRP URL format was changed to better reflect generic URL The MSRP URL format was changed to better reflect generic URL
standards. URL comparison and resolution rules were added. SRV standards. URL comparison and resolution rules were added. SRV
usage added. usage added.
Determination of host and visitor roles now uses a direction Determination of host and visitor roles now uses a direction
attribute much like the one used in COMEDIA. attribute much like the one used in COMEDIA.
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.3 draft-campbell-simple-im-sessions-01 11.4 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 bidirectionally in the presence of NATs. connections to be used bidirectional in the presence of NATs.
Significantly more discussion of a concrete mechanism has been added Significantly more discussion of a concrete mechanism has been added
to make up for no longer using COMEDIA. Additionally, this draft and to make up for no longer using COMEDIA. Additionally, this draft and
draft-campbell-cpimmsg-sessions (which would have also changed draft-campbell-cpimmsg-sessions (which would have also changed
drastically) have now been combined into this single draft. drastically) have now been combined into this single draft.
12. Contributors 12. Contributors
The following people contributed substantially to this ongoing The following people contributed substantially to this ongoing
effort: effort:
Rohan Mahy Rohan Mahy
Allison Mankin Allison Mankin
Jon Peterson Jon Peterson
Brian Rosen Brian Rosen
Dean Willis Dean Willis
Adam Roach Adam Roach
Cullen Jennings Cullen Jennings
Aki Niemi
Hisham Khartabil
Pekka Pessi
Chris Boulton
Normative References Normative References
[1] Handley, M. and V. Jacobson, "SDP: Session Description [1] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
skipping to change at page 54, line 4 skipping to change at page 54, line 21
"RTP: A Transport Protocol for Real-Time Applications", RFC "RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996. 1889, January 1996.
[12] Mahy, R., Campbell, B., Sparks, R., Rosenberg, J., Petrie, D. [12] Mahy, R., Campbell, B., Sparks, R., Rosenberg, J., Petrie, D.
and A. Johnston, "A Multi-party Application Framework for SIP", and A. Johnston, "A Multi-party Application Framework for SIP",
draft-ietf-sipping-cc-framework-02 (work in progress), May draft-ietf-sipping-cc-framework-02 (work in progress), May
2003. 2003.
[13] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo, [13] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo,
"Best Current Practices for Third Party Call Control in the "Best Current Practices for Third Party Call Control in the
Session Initiation Protocol", draft-ietf-sipping-3pcc-03 (work Session Initiation Protocol", draft-ietf-sipping-3pcc-04 (work
in progress), March 2003. in progress), June 2003.
[14] Sparks, R. and A. Johnston, "Session Initiation Protocol Call [14] Sparks, R. and A. Johnston, "Session Initiation Protocol Call
Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in
progress), February 2003. progress), February 2003.
[15] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of [15] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of
Resource Management and Session Initiation Protocol (SIP)", RFC Resource Management and Session Initiation Protocol (SIP)", RFC
3312, October 2002. 3312, October 2002.
[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-03 (work in progress), May 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., [19] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999. Basic and Digest Access Authentication", RFC 2617, June 1999.
Authors' Addresses Authors' Addresses
skipping to change at page 57, line 7 skipping to change at page 57, line 7
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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