draft-ietf-simple-message-sessions-05.txt   draft-ietf-simple-message-sessions-06.txt 
SIMPLE Working Group B. Campbell SIMPLE Working Group B. Campbell (Ed.)
Internet-Draft J. Rosenberg Internet-Draft dynamicsoft
Expires: October 11, 2004 R. Sparks Expires: November 15, 2004 May 17, 2004
dynamicsoft
P. Kyzivat
Cisco Systems
C. Boulton
Ubiquity Software Corporation
April 12, 2004
The Message Session Relay Protocol The Message Session Relay Protocol
draft-ietf-simple-message-sessions-05 draft-ietf-simple-message-sessions-06
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
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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
www.ietf.org/ietf/1id-abstracts.txt. http://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 October 11, 2004. This Internet-Draft will expire on November 15, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document describes the Message Session Relay Protocol (MSRP), a This document describes the Message Session Relay Protocol (MSRP), a
mechanism for transmitting a series of Instant Messages within a mechanism for transmitting a series of Instant Messages within a
session. MSRP sessions are managed using the Session Description session. MSRP sessions are managed using the Session Description
Protocol (SDP) offer/answer model carried by a signaling protocol Protocol (SDP) offer/answer model carried by a signaling protocol
such as the Session Initiation Protocol (SIP). such as the Session Initiation Protocol (SIP).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation for Session-mode Messaging . . . . . . . . . . 4 2. Motivation for Session-mode Messaging . . . . . . . . . . . 4
3. Scope of this Document . . . . . . . . . . . . . . . . . . 5 3. Scope of this Document . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 6
5. Architectural Considerations . . . . . . . . . . . . . . . 7 5. SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . . 7
6. SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . 7 5.1 Use of the SDP M-line . . . . . . . . . . . . . . . . . . 7
6.1 Use of the SDP M-line . . . . . . . . . . . . . . . . . . 7 5.2 The Accept Types Attribute . . . . . . . . . . . . . . . . 7
6.2 The Accept Types Attribute . . . . . . . . . . . . . . . . 8 5.3 MIME Wrappers . . . . . . . . . . . . . . . . . . . . . . 8
6.3 MIME Wrappers . . . . . . . . . . . . . . . . . . . . . . 8 5.4 URL Negotiations . . . . . . . . . . . . . . . . . . . . . 9
6.4 URL Negotiations . . . . . . . . . . . . . . . . . . . . . 9 5.5 Path Attributes with Multiple URLs . . . . . . . . . . . . 10
6.5 Path Attributes with Multiple URLs . . . . . . . . . . . . 10 5.6 Updated SDP Offers . . . . . . . . . . . . . . . . . . . . 11
6.6 Updated SDP Offers . . . . . . . . . . . . . . . . . . . . 11 5.7 Example SDP Exchange . . . . . . . . . . . . . . . . . . . 11
6.7 Example SDP Exchange . . . . . . . . . . . . . . . . . . . 11 5.8 Connection Negotiation . . . . . . . . . . . . . . . . . . 12
6.8 Connection Negotiation . . . . . . . . . . . . . . . . . . 12 6. The Message Session Relay Protocol . . . . . . . . . . . . . 12
7. The Message Session Relay Protocol . . . . . . . . . . . . 12 6.1 MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1 MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . 13
7.1.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 13 6.1.2 Resolving MSRP Host Device . . . . . . . . . . . . . . 14
7.1.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 13 6.2 Connection Direction . . . . . . . . . . . . . . . . . . . 14
7.1.3 The msrps URL Scheme . . . . . . . . . . . . . . . . . . . 14 6.3 MSRP Messages . . . . . . . . . . . . . . . . . . . . . . 15
7.2 Connection Managment . . . . . . . . . . . . . . . . . . . 14 6.3.1 Message Framing . . . . . . . . . . . . . . . . . . . 17
7.3 MSRP messages . . . . . . . . . . . . . . . . . . . . . . 15 6.3.2 Message Examples . . . . . . . . . . . . . . . . . . . 18
7.4 MSRP Transactions . . . . . . . . . . . . . . . . . . . . 16 6.4 MSRP Transactions . . . . . . . . . . . . . . . . . . . . 19
7.5 MSRP Sessions . . . . . . . . . . . . . . . . . . . . . . 17 6.5 MSRP Sessions . . . . . . . . . . . . . . . . . . . . . . 19
7.5.1 Initiating an MSRP session . . . . . . . . . . . . . . . . 17 6.5.1 Initiating an MSRP session . . . . . . . . . . . . . . 19
7.5.2 Handling VISIT requests . . . . . . . . . . . . . . . . . 19 6.5.2 Handling the initial request . . . . . . . . . . . . . 21
7.5.3 Sending Instant Messages on a Session . . . . . . . . . . 19 6.5.3 Sending Instant Messages on a Session . . . . . . . . 21
7.5.4 Ending a Session . . . . . . . . . . . . . . . . . . . . . 20 6.5.4 Ending a Session . . . . . . . . . . . . . . . . . . . 23
7.5.5 Managing Session State and Connections . . . . . . . . . . 21 6.5.5 Managing Session State and Connections . . . . . . . . 23
7.6 Delivery Status Notification . . . . . . . . . . . . . . . 22 6.6 Delivery Status Notification . . . . . . . . . . . . . . . 24
7.6.1 Endpoint DSN Request . . . . . . . . . . . . . . . . . . . 22 6.6.1 Endpoint DSN Request . . . . . . . . . . . . . . . . . 24
7.6.2 DSN generation . . . . . . . . . . . . . . . . . . . . . . 23 6.6.2 DSN generation . . . . . . . . . . . . . . . . . . . . 25
7.6.3 Receiving positive DSN . . . . . . . . . . . . . . . . . . 24 6.6.3 Receiving positive DSN . . . . . . . . . . . . . . . . 26
7.6.4 Receiving negative DSN . . . . . . . . . . . . . . . . . . 24 6.6.4 Receiving negative DSN . . . . . . . . . . . . . . . . 26
7.6.5 DSN headers in MSRP . . . . . . . . . . . . . . . . . . . 24 6.6.5 DSN headers in MSRP . . . . . . . . . . . . . . . . . 26
7.7 Message Fragmentation . . . . . . . . . . . . . . . . . . 24 6.7 Message Fragmentation . . . . . . . . . . . . . . . . . . 28
7.7.1 MSRP Usage of message/byteranges . . . . . . . . . . . . . 24 6.7.1 MSRP Usage of message/byteranges . . . . . . . . . . . 28
7.8 Method Descriptions . . . . . . . . . . . . . . . . . . . 25 6.8 Method Descriptions . . . . . . . . . . . . . . . . . . . 29
7.8.1 SEND . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.8.1 SEND . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.8.2 VISIT . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.8.2 VISIT . . . . . . . . . . . . . . . . . . . . . . . . 29
7.8.3 REPORT . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.8.3 REPORT . . . . . . . . . . . . . . . . . . . . . . . . 30
7.9 Response Code Descriptions . . . . . . . . . . . . . . . . 26 6.9 Response Code Descriptions . . . . . . . . . . . . . . . . 30
7.9.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.9.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.9.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.9.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.9.3 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.9.3 415 . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.9.4 426 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.9.4 426 . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.9.5 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.9.5 481 . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.9.6 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.9.6 506 . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.10 Header Field Descriptions . . . . . . . . . . . . . . . . 26 6.10 Header Field Descriptions . . . . . . . . . . . . . . . 30
7.10.1 TR-ID . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.10.1 TR-ID . . . . . . . . . . . . . . . . . . . . . . . 31
7.10.2 To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.10.2 Message-ID . . . . . . . . . . . . . . . . . . . . . 31
7.10.3 From . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.10.3 To-Path . . . . . . . . . . . . . . . . . . . . . . 31
7.10.4 Content-Type . . . . . . . . . . . . . . . . . . . . . . . 27 6.10.4 From-Path . . . . . . . . . . . . . . . . . . . . . 31
8. Example . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.10.5 Boundary . . . . . . . . . . . . . . . . . . . . . . 31
9. IANA Considerations . . . . . . . . . . . . . . . . . . . 30 6.10.6 Closing . . . . . . . . . . . . . . . . . . . . . . 31
9.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 30 6.10.7 Content-Type . . . . . . . . . . . . . . . . . . . . 32
9.2 MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . . 30 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 30 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34
9.2.2 Character Encoding . . . . . . . . . . . . . . . . . . . . 30 8.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 34
9.2.3 Intended Usage . . . . . . . . . . . . . . . . . . . . . . 30 8.2 MSRP URL Schema . . . . . . . . . . . . . . . . . . . . . 34
9.2.4 Protocols . . . . . . . . . . . . . . . . . . . . . . . . 30 8.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . 34
9.2.5 Security Considerations . . . . . . . . . . . . . . . . . 30 8.2.2 Character Encoding . . . . . . . . . . . . . . . . . . 34
9.2.6 Relevant Publications . . . . . . . . . . . . . . . . . . 30 8.2.3 Intended Usage . . . . . . . . . . . . . . . . . . . . 35
9.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 31 8.2.4 Protocols . . . . . . . . . . . . . . . . . . . . . . 35
9.3.1 Accept Types . . . . . . . . . . . . . . . . . . . . . . . 31 8.2.5 Security Considerations . . . . . . . . . . . . . . . 35
9.3.2 Wrapped Types . . . . . . . . . . . . . . . . . . . . . . 31 8.2.6 Relevant Publications . . . . . . . . . . . . . . . . 35
9.3.3 Path . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 35
10. Security Considerations . . . . . . . . . . . . . . . . . 31 8.3.1 Accept Types . . . . . . . . . . . . . . . . . . . . . 35
10.1 TLS and the MSRPS Scheme . . . . . . . . . . . . . . . . . 31 8.3.2 Wrapped Types . . . . . . . . . . . . . . . . . . . . 35
10.1.1 Sensitivity of the Session URL . . . . . . . . . . . . . . 32 8.3.3 Path . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.1.2 End to End Protection of IMs . . . . . . . . . . . . . . . 33 8.4 IANA registration forms for DSN types . . . . . . . . . . 36
10.1.3 CPIM compatibility . . . . . . . . . . . . . . . . . . . . 33 8.4.1 IANA registration form for address-type . . . . . . . 36
10.1.4 PKI Considerations . . . . . . . . . . . . . . . . . . . . 34 8.4.2 IANA registration form for MTA-name-type . . . . . . . 36
11. Changes from Previous Draft Versions . . . . . . . . . . . 34 9. Security Considerations . . . . . . . . . . . . . . . . . . 36
11.1 draft-ietf-simple-message-sessions-04 . . . . . . . . . . 34 9.1 TLS and the MSRPS Scheme . . . . . . . . . . . . . . . . . 36
11.2 draft-ietf-simple-message-sessions-03 . . . . . . . . . . 35 9.1.1 Sensitivity of Session URLs . . . . . . . . . . . . . 37
11.3 draft-ietf-simple-message-sessions-02 . . . . . . . . . . 35 9.1.2 End to End Protection of IMs . . . . . . . . . . . . . 38
11.4 draft-ietf-simple-message-sessions-01 . . . . . . . . . . 35 9.1.3 CPIM compatibility . . . . . . . . . . . . . . . . . . 38
11.5 draft-ietf-simple-message-sessions-00 . . . . . . . . . . 36 9.1.4 PKI Considerations . . . . . . . . . . . . . . . . . . 38
11.6 draft-campbell-simple-im-sessions-01 . . . . . . . . . . . 37 10. Changes from Previous Draft Versions . . . . . . . . . . . . 39
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . 37 10.1 draft-ietf-simple-message-sessions-06 . . . . . . . . . 39
Normative References . . . . . . . . . . . . . . . . . . . 37 10.2 draft-ietf-simple-message-sessions-05 . . . . . . . . . 39
Informational References . . . . . . . . . . . . . . . . . 38 10.3 draft-ietf-simple-message-sessions-04 . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 39 10.4 draft-ietf-simple-message-sessions-03 . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . 40 10.5 draft-ietf-simple-message-sessions-02 . . . . . . . . . 40
10.6 draft-ietf-simple-message-sessions-01 . . . . . . . . . 41
10.7 draft-ietf-simple-message-sessions-00 . . . . . . . . . 41
10.8 draft-campbell-simple-im-sessions-01 . . . . . . . . . . 42
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
13.1 Normative References . . . . . . . . . . . . . . . . . . . 42
13.2 Informational References . . . . . . . . . . . . . . . . . 43
Author's Address . . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . 45
1. Introduction 1. Introduction
The MESSAGE [12] extension to SIP [2] allows SIP to be used to The MESSAGE [12] 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
called page-mode messaging, since it follows a model similar to that often called page-mode messaging, since it follows a model similar to
used by many two-way pager devices. Page-mode messaging makes sense that used by many two-way pager devices. Page-mode messaging makes
for instant message exchanges where a small number of messages occur. sense for instant message exchanges where a small number of messages
Endpoints may treat page-mode messages as if they took place in an occur. Endpoints may treat page-mode messages as if they took place
imaginative session, but there is no formal relationship between one in an imaginative session, but there is no formal relationship
message and another. 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 formally associated in a session. 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
session-mode messaging. as 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 5) 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
Protocol, and the use of the SDP offer/answer mechanism for managing Protocol, and the use of the SDP offer/answer mechanism for managing
MSRP session. MSRP session.
2. Motivation for Session-mode Messaging 2. Motivation for Session-mode Messaging
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
skipping to change at page 4, line 48 skipping to change at page 4, line 48
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. the SIP proxies themselves.
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
used outside of a SIP dialog, these requests will typically traverse normally used outside of a SIP dialog, these requests will typically
the entire proxy network between the endpoints. traverse 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
skipping to change at page 5, line 28 skipping to change at page 5, line 28
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
of the session key can be done using standard techniques that apply of the session key can be done using standard techniques that apply
to voice and video, in addition to instant messaging. to voice and video, in addition to instant messaging.
Finally, SIP devices can treat message sessions like any other media Finally, SIP devices can treat message sessions like any other media
sessions. Any SIP feature that can be applied to other sorts of media sessions. Any SIP feature that can be applied to other sorts of
sessions can equally apply to message sessions. For example, media sessions can equally apply to message sessions. For example,
conferencing [14], third party call control [15], call transfer [16], conferencing [14], third party call control [15], call transfer [16],
QoS integration [17], and privacy [18] can all be applied to message QoS integration [17], and privacy [18] can all be applied to message
sessions. sessions.
Messaging sessions can also reduce the overhead in each individual Messaging sessions can also reduce the overhead in each individual
message. In page-mode, each message needs to include all of the SIP message. In page-mode, each message needs to include all of the SIP
headers that are mandated by RFC 3261 [2]. However, many of these headers that are mandated by RFC 3261 [2]. However, many of these
headers are not needed once a context is established for exchanging headers are not needed once a context is established for exchanging
messages. As a result, messaging session mechanisms can be designed messages. As a result, messaging session mechanisms can be designed
with significantly less overhead. with significantly less overhead.
3. Scope of this Document 3. Scope of this Document
This document describes the use of MSRP between endpoints. It does This document describes the use of MSRP between endpoints. It does
not specify the use of intermediaries, nor does it prohibit such use. not specify the use of intermediaries, nor does it prohibit such use.
We expect an extension to this specification to define MSRP We expect an extension to this specification to define MSRP
intermediaries and their use. intermediaries and their use.
This document describes the use of MSRP over TCP. MSRP may be used This document describes the use of MSRP over TCP. MSRP may be used
over other congestion-controlled protocols such as SCTP. However, the over other congestion-controlled protocols such as SCTP. However,
specific bindings for other such protocols are outside the scope of the specific bindings for other such protocols are outside the scope
this document. of this document.
4. Protocol Overview 4. Protocol Overview
The Message Session Relay Protocol (MSRP) provides a mechanism for The Message Session Relay Protocol (MSRP) provides a mechanism for
transporting session-mode messages between endpoints. MSRP uses transporting session-mode messages between endpoints. MSRP uses
connection oriented, reliable network transport protocols only. It connection oriented, reliable network transport protocols only. It
can operate in the presence of many NAT and firewall environments, as can operate in the presence of many NAT and firewall environments, as
it allows participants to positively associate message sessions with it allows participants to positively associate message sessions with
specific connections, and does not depend upon connection source specific connections, and does not depend upon connection source
address, which may be obscured by NATs. address, which may be obscured by NATs.
MSRP uses the following primitives: MSRP uses the following primitives:
SEND: Used to send message content from one endpoint to another. SEND: Used to send message content from one endpoint to another.
VISIT: Used by an endpoint to establish a session association to the VISIT: Used by an endpoint to establish a session association to the
host endpoint. host endpoint.
REPORT Used to carry MSRP message report/receipt information.
Assume A is an endpoint that wishes to establish a message session, Assume A is an endpoint that wishes to establish a message session,
and B is the endpoint invited by A. A invites B to participate in a and B is the endpoint invited by A. A invites B to participate in a
message session by sending a URL. This URL is temporary, and must not message session by sending a URL. This URL is temporary, and must
duplicate any URL that A has offered for other active sessions. not duplicate any URL that A has offered for other active sessions.
B "visits" A by connecting to A and sending a VISIT request B then responds to the invitation with a URL of its own. This
containing the URL that A provided. This associates the connection informs A that B has accepted the session, and will accept messages
from B with the session. B then responds to the invitation with a URL at that URL. A connects to B, and sends a request to establish the
of its own. This informs A that B has accepted the session, and will session. A and B may now exchange messages using SEND requests on
accept messages at that URL. A and B may now exchange messages using the connection. Each party targets such requests to the peer's URL.
SEND requests on the connection. Each party targets such requests to
the peer's URL.
When either party wishes to end the session, it informs its peer When either party wishes to end the session, it informs its peer
using the appropriate mechanism of the chosen signaling protocol, using the appropriate mechanism of the chosen signaling protocol,
such as a SIP BYE request. such as a SIP BYE request.
The end to end case looks something like the following. (Note that The end to end case looks something like the following. (Note that
the example shows a logical flow only; syntax will come later in this the example shows a logical flow only; syntax will come later in this
document.) document.)
A->B (SDP): offer (msrp://A/123) A->B (SDP): offer (msrp://A/123)
B->A (MSRP): VISIT (msrp://A/123, msrp://B/456)
A->B (MSRP): 200 OK
B->A (SDP): answer(msrp://B/456) B->A (SDP): answer(msrp://B/456)
A->B (TCP) connect
A->B (MSRP): SEND (msrp://B/456) A->B (MSRP): SEND (msrp://B/456)
B->A (MSRP): 200 OK B->A (MSRP): 200 OK
B->A (MSRP): SEND (msrp://A/123) B->A (MSRP): SEND (msrp://A/123)
A->B (MSRP): 200 OK A->B (MSRP): 200 OK
5. Architectural Considerations 5. SDP Offer-Answer Exchanges for MSRP Sessions
There are a number of considerations that, if handled in a reasonable
fashion, will allow more effective use of the protocols described in
this document.
6. SDP Offer-Answer Exchanges for MSRP Sessions
MSRP sessions will typically be initiated using the Session MSRP sessions will typically be initiated using the Session
Description Protocol (SDP) [1] offer-answer mechanism, carried in the Description Protocol (SDP) [1] offer-answer mechanism, carried in the
Session Initiation Protocol (SIP) [2] or any other protocol Session Initiation Protocol (SIP) [2] or any other protocol
supporting it. supporting it.
6.1 Use of the SDP M-line 5.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 MAY be set to any value chosen by the endpoint. A port used, and MAY be set to any value chosen by the endpoint. A port
field value of zero has the standard SDP meaning. Non-zero values field value of zero has the standard SDP meaning. Non-zero values
MUST not be repeated in other MSRP m-lines in the same SDP document. MUST not be repeated in other MSRP m-lines in the same SDP document.
The proto field MUST designate the message session mechanism and The protocol field is used only to designate MSRP. The underlying
transport protocol, separated by a "/" character. For MSRP, left part transport protocol is determined in the MSRP URL, as described below.
of this value MUST be "msrp". For MSRP over TCP, the right part of Therefore, the protocol field MUST take the value of "msrp".
this field MUST take the value "tcp". For MSRP over other transport
protocols, the field value MUST be defined by the specification for
that protocol binding.
The format list list is ignored for MSRP. This is because MSRP The format list list is ignored for MSRP. This is because MSRP
formats are specified as MIME content types, which are not convenient formats are specified as MIME content types, which are not convenient
to encode in the SDP format list syntax. Instead, the allowed formats to encode in the SDP format list syntax. Instead, the allowed
are negotiated using "a"-line attributes. For MSRP sessions, the formats are negotiated using "a"-line attributes. For MSRP sessions,
format list SHOULD contain a "*" character, and nothing else. the format list SHOULD contain a "*" character, and nothing else.
The port field in the M-line is not used to determine the port to The port field in the M-line is not used to determine the port to
which to connect. Rather, the actual port is determined by the the which to connect. Rather, the actual port is determined by the the
MSRP URL (Section 7.1) in the path attribute. However, a port value MSRP URL (Section 6.1) in the path attribute. 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 * m=message 9999 msrp *
6.2 The Accept Types Attribute 5.2 The Accept Types Attribute
MSRP can carry any MIME encoded payload. Endpoints specify MIME MSRP can carry any MIME encoded payload. Endpoints specify MIME
content types that they are willing to receive in the accept types content types that they are willing to receive in the accept types
"a"-line attribute. This attribute has the following syntax: "a"-line attribute. This attribute has the following syntax:
accept-types = accept-types-label ":" format-list accept-types = accept-types-label ":" format-list
accept-types-label = "accept-types" accept-types-label = "accept-types"
format-list = format-entry *( SP format-list = format-entry *( SP
format-entry) format-entry = (type "/" subtype) / ("*") format-entry) format-entry = (type "/" subtype) / ("*")
type = token type = token
subtype = token subtype = token
SDP offers for MSRP sessions MUST include an accept-types attribute. SDP offers for MSRP sessions MUST include an accept-types attribute.
SDP answers MUST also include the attribute, which MUST contain SDP answers MUST also include the attribute, which MUST contain
either the same list as in the offer or a subset of that list. either the same list as in the offer or a subset of that list.
A "*" entry in the accept-types attribute indicates that the sender A "*" entry in the accept-types attribute indicates that the sender
may attempt to send messages with media types that have not been may attempt to send messages with media types that have not been
explicitly listed. If the receiver is able to process the media type, explicitly listed. If the receiver is able to process the media
it does so. If not, it will respond with a 415. Note that all 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 explicit entries SHOULD be considered preferred over any non-listed
types. This feature is needed as, otherwise, the list of formats for types. This feature is needed as, otherwise, the list of formats for
rich IM devices may be prohibitively large. rich IM devices may be prohibitively large.
The accept-types attribute may include container types, that is, mime The accept-types attribute may include container types, that is, mime
formats that contain other types internally. If compound types are formats that contain other types internally. If compound types are
used, the types listed in the accept-types attribute may be used both used, the types listed in the accept-types attribute may be used both
as the root payload, or may be wrapped in a listed container type. as the root payload, or may be wrapped in a listed container type.
(Note that the container type MUST also be listed in the accept-types (Note that the container type MUST also be listed in the accept-types
attribute.) attribute.)
6.3 MIME Wrappers 5.3 MIME Wrappers
The MIME content-types in the accept-types attribute will often The MIME content-types in the accept-types attribute will often
include container types; that is, types that contain other types. For include container types; that is, types that contain other types.
example, "message/cpim" or "multipart/mixed." Occasionally an For example, "message/cpim" or "multipart/mixed." Occasionally an
endpoint will need to specify a MIME body type that can only be used endpoint will need to specify a MIME body type that can only be used
if wrapped inside a listed container type. if wrapped inside a listed container type.
Endpoints MAY specify MIME types that are only allowed to be wrapped Endpoints MAY specify MIME types that are only allowed to be wrapped
inside compound types using the "accept-wrapped-types" attribute in inside compound types using the "accept-wrapped-types" attribute in
an SDP a-line. This attribute has the following syntax: an SDP a-line. This attribute has the following syntax:
accept-wrapped-types = wrapped-types-label ":" format-list accept-wrapped-types = wrapped-types-label ":" format-list
wrapped-types-label = "accept-wrapped-types" ` wrapped-types-label = "accept-wrapped-types" `
skipping to change at page 9, line 29 skipping to change at page 9, line 16
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
gateway device may require all messages to be wrapped inside CPIM gateway device may require all messages to be wrapped inside
message/cpim bodies, but may allow several content types inside message/cpim bodies, but may allow several content types inside
the wrapper. If the gateway were to specify the wrapped types in the wrapper. If the gateway were to specify the wrapped types in
the accept-types attribute, its peer could choose to use those the accept-types attribute, its peer could choose to use those
types without the wrapper. types without the wrapper.
6.4 URL Negotiations 5.4 URL Negotiations
Each endpoint in an MSRP session is identified by a URL. These URLs Each endpoint in an MSRP session is identified by a URL. These URLs
are negotiated in the SDP exchange. Each SDP offer or answer MUST are negotiated in the SDP exchange. Each SDP offer or answer MUST
contain one or more MSRP URL in a path attribute. This attribute has contain one or more MSRP URL in a path attribute. This attribute has
the following syntax: the following syntax:
a=path ":" MSRP_URL *(SP MSRP_URL) a=path ":" MSRP_URL *(SP MSRP_URL)
where MSRP_URL is an MSRP or MSRPS URL as defined in Section 7.1. where MSRP_URL is an MSRP or MSRPS URL as defined in Section 6.1.
MSRP URLs included in an SDP offer or answer MUST include an explicit
port number.
The answerer will use the offered URL(s) to resolve the host address A device uses the URL to determine a host address and port when
and port when connecting, and to identify the target when sending connecting, and to identify the target when sending messages. For
messages. For MSRP sessions, the address field in the C-line is not MSRP sessions, the address field in the C-line is not relevant, and
relevant, and MUST be ignored. The port field in the M-line MUST be MUST be ignored. The port field in the M-line MUST be ignored if
ignored if non-zero. Zero values have the usual meaning for SDP. non-zero. Zero values have the usual meaning for SDP.
A device will further use the URL to determine the transport
protocol, and whether to use TLS. This information is encoded in the
URL scheme.
Both offerer and answerer store the path values received from the Both offerer and answerer store the path values received from the
peer. For a given endpoint, the local URL is the URL that the peer. For a given endpoint, the local URL is the URL that the
endpoint put into a path attribute value to send to its peer. The endpoint put into a SDP path attribute to represent itself. The peer
peer URL is the URL received from the peer. If the path attribute URL is the URL sent by the peer to represent itself. If the path
received from the peer contains more than one URL, then the peer URL attribute received from the peer contains more than one URL, then the
is the last entry, while the first entry is the connection URL. If peer URL is the rightmost, while the leftmost entry represents the
only one entry is present, then it is both the peer and connection adjacent hop. If only one entry is present, then it is both the peer
URL. The remote path is the entire path attribute value received from and adjacent URL. The remote path is the entire path attribute value
the peer. received from the peer.
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://a.example.com:7394/2s93i" "msrp://a.example.com:7394/2s93i"
v=0 v=0
o=someuser 2890844526 2890844527 IN IP4 alice.example.com o=someuser 2890844526 2890844527 IN IP4 alice.example.com
s= s=
c=IN IP4 alice.example.com m=message 9999 msrp/tcp * c=IN IP4 alice.example.com m=message 9999 msrp *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrp://a.example.com:7394/2s93i a=path:msrp://a.example.com:7394/2s93i
The first URI in the path attribute MUST identify the endpoint that The rightmost URI in the path attribute MUST identify the endpoint
generated the SDP document, or some other location where that that generated the SDP document, or some other location where that
endpoint wishes to receive messages associated with the session. If endpoint wishes to receive messages associated with the session. It
the URL identifies the endpoint, it MUST MUST be a temporary URL MUST MUST be a temporary URL assigned just for this particular
assigned just for this particular session, and MUST NOT duplicate any session, and MUST NOT duplicate any URL in use for any other session
URL in use for any other session in which the endpoint is currently in which the endpoint is currently participating. Further, it SHOULD
participating. Further, it SHOULD be hard to guess, and protected be hard to guess, and protected from eavesdroppers. This will be
from eavesdroppers. This will be discussed in more detail in Section discussed in more detail in Section 9.
10.
6.5 Path Attributes with Multiple URLs 5.5 Path Attributes with Multiple URLs
As mentioned previously, this document describes MSRP for As mentioned previously, this document describes MSRP for
peer-to-peer scenarios, that is, when no relays are used. However, we peer-to-peer scenarios, that is, when no relays are used. However,
expect a separate document to describe the use of relays in the near we expect a separate document to describe the use of relays in the
future. The path attribute supports lists of URLs in order to near future. In order to allow an MSRP device that only implements
facilitate that work. For peer-to-peer session, a path attribute will the core specification to interoperate with devices that use relays,
contain exactly one URL, describing an endpoint. This means that this document must include a few assumptions about how relays work.
endpoints that only implement this specification will never send more
than one URL in a path attribute, but MUST be prepared to receive
more than one. When an endpoint receives more than one URL in a path
header, only the first entry is relevant for purposes of resolving
the address and port, and establishing the network connection, thus
the term connection URL.
If an endpoint puts more than one URL in a path attribute, final URL An endpoint that uses one or more relays will indicate that by
in the path (the peer URL) attribute MUST exhibit the uniqueness putting a URL for each device in the relay chain into the SDP path
properties described above. Uniqueness requirements for other entries attribute. The final entry would point to the endpoint itself. The
in the attribute are out of scope for this document. other entries would indicate each proposed relay, in order. The
first entry would point to the first relay in the chain; that is, the
relay to which the peer device, or a relay operation on its behalf,
should connect.
6.6 Updated SDP Offers Endpoints that do not wish to insert a relay, including those that do
not support relays at all, will put exactly one URL into the path
attribute. This URL represents both the endpoint for the session,
and the connection point.
While endpoints that implement only this specification will never
introduce a relay, they will need to be able to interoperate with
other endpoints that do use relays. Therefore, they MUST be prepared
to receive more than one URL in the SDP path attribute. When an
endpoint receives more than one URL in a path header, only the first
entry is relevant for purposes of resolving the address and port, and
establishing the network connection, as it describes the first
adjacent hop.
If an endpoint puts more than one URL in a path attribute, the final
URL in the path (the peer URL) attribute MUST exhibit the uniqueness
properties described above. Uniqueness requirements for other
entries in the attribute are out of scope for this document.
5.6 Updated SDP Offers
To do: Revisit this section based on new connection management rules To do: Revisit this section based on new connection management rules
MSRP endpoints may sometimes need to send additional SDP exchanges MSRP endpoints may sometimes need to send additional SDP exchanges
for an existing session. They may need to send periodic exchanges for an existing session. They may need to send periodic exchanges
with no change to refresh state in the network, for example, SIP with no change to refresh state in the network, for example, SIP
timers. They may need to change some other stream in a session timers. They may need to change some other stream in a session
without affecting the MSRP stream, or they may need to change an MSRP without affecting the MSRP stream, or they may need to change an MSRP
stream without affecting some other stream. stream without affecting some other stream.
If either party wish to send an SDP document that changes nothing at If either party wish to send an SDP document that changes nothing at
all, then it MUST have the same o-line version as in the previous all, then it MUST have the same o-line version as in the previous
exchange. exchange.
6.7 Example SDP Exchange 5.7 Example SDP Exchange
Endpoint A wishes to invite Endpoint B to a MSRP session. A offers Endpoint A wishes to invite Endpoint B to a MSRP session. A offers
the following session description: the following session description:
v=0 v=0
o=usera 2890844526 2890844527 IN IP4 alice.example.com o=usera 2890844526 2890844527 IN IP4 alice.example.com
s= s=
c=IN IP4 alice.example.com t=0 0 c=IN IP4 alice.example.com t=0 0
m=message 9999 msrp/tcp * m=message 9999 msrp *
a=accept-types: message/cpim text/plain text/html a=accept-types: message/cpim text/plain text/html
a=path:msrp://alice.example.com:7394/2s93i9 a=path:msrp://alice.example.com:7394/2s93i9
Endpoint B performs a VISIT transaction passing the URL of msrp:// B responds with its own URL:
alice.example.com:7394/2s93i9. B indicates that it has accomplished
this by answering with:
v=0 v=0
o=userb 2890844530 2890844532 IN IP4 bob.example.com o=userb 2890844530 2890844532 IN IP4 bob.example.com
s= s=
c=IN IP4 dontlookhere c=IN IP4 dontlookhere
t=0 0 t=0 0
m=message 9999 msrp/tcp * m=message 9999 msrp *
a=accept-types:message/cpim text/plain a=accept-types:message/cpim text/plain
a=path:msrp://bob.example.com:8493/si438ds a=path:msrp://bob.example.com:8493/si438ds
A may now send IMs to B by executing SEND transactions. A immediately sends some MSRP traffic: Either a VISIT request (if it
has no immediate content to send) or a SEND request (if it does have
immediate content.) Afterwards, A and B may now exchange IMs by
executing SEND transactions.
6.8 Connection Negotiation 5.8 Connection Negotiation
Previous versions of this document included a mechanism to negotiate Previous versions of this document included a mechanism to negotiate
the direction for any required TCP connection. The mechanism was the direction for any required TCP connection. The mechanism was
loosely based on COMEDIA [20]work being done in the MMUSIC working loosely based on COMEDIA [20]work being done in the MMUSIC working
group. The primary motivation was to allow MSRP sessions to succeed group. The primary motivation was to allow MSRP sessions to succeed
in situations where the offerer could not accpet connections but the in situations where the offerer could not accept connections but the
answerer could. For example, the offerer might be behind a NAT, while answerer could. For example, the offerer might be behind a NAT,
the answerer might have a globally routable address. while the answerer might have a globally routable address.
The SIMPLE working group chose to remove that mechanism from MSRP for
a number of reasons:
It added a great deal of complexity to session creation. The SIMPLE working group chose to remove that mechanism from MSRP, as
The work in MSRP had begun to diverge from the work in MMUSIC. it added a great deal of complexity to connection management.
There was a lack of successful implementation experience of the Instead, MSRP now specifies default connection directions.
COMEDIA work.
7. The Message Session Relay Protocol 6. The Message Session Relay Protocol
The Message Session Relay Protocol (MSRP) is a text based, message The Message Session Relay Protocol (MSRP) is a text based, message
oriented protocol for the transfer of instant messages in the context oriented protocol for the transfer of instant messages in the context
of a session. MSRP uses the UTF8 character set. of a session. MSRP uses the UTF8 character set.
MSRP messages MUST be sent over a reliable, congestion-controlled, MSRP messages MUST be sent over a reliable, congestion-controlled,
connection-oriented transport protocol. This document specifies the connection-oriented transport protocol. This document specifies the
use of MSRP over TCP. Other documents may specify bindings for other use of MSRP over TCP. Other documents may specify bindings for other
such protocols. such protocols.
7.1 MSRP URLs 6.1 MSRP URLs
An MSRP URL follows a subset of the URL syntax in Appendix A of An MSRP URL follows a subset of the URL syntax in Appendix A of
RFC2396 [4], with a scheme of "msrp": RFC2396 [4], with a scheme of "msrp":
msrp_url = "msrp://" [userinfo "@"] hostport ["/" resource] msrp_url = msrp-scheme "://" [userinfo "@"] hostport ["/"
resource]
msrp-scheme = "msrp" / "msrps" / "smsrp" / "smsrps"
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 a participant in an MSRP session. An MSRP URL server part identifies a participant in an MSRP session.
If the server part contains a numeric IP address, it MUST also If the server part contains a numeric IP address, it MUST also
contain a port. The resource part identifies a particular session the contain a port. The resource part identifies a particular session
participant. The absence of the resource part indicates a reference the participant. The absence of the resource part indicates a
to an MSRP host device, but does not specifically refer to a reference to an MSRP host device, but does not specifically refer to
particular session resource. a particular session resource.
MSRP has an IANA registered recommended port defined in Section 9.1. The underlying transport protocol and the protection level (that is,
whether TLS is used) is determined by the URL scheme:
msrp MSRP over TCP without TLS.
msrps MSRP over TCP with TLS.
smsrp MSRP over SCTP without TLS.
smsrps MSRP over SCTP with TLS.
This document only describes the binding for MSRP over TCP. The
schema for SCTP are reserved herein, but binding MSRP to SCTP is
out of scope for this document.
MSRP has an IANA registered recommended port defined in Section 8.1.
This value is not a default, as the URL process described herein will This value is not a default, as the URL process described herein will
always explicitly resolve a port number. However, the URLs SHOULD be always explicitly resolve a port number. However, the URLs SHOULD be
configured so that the recommended port is used whenever appropriate. configured so that the recommended port is used whenever appropriate.
This makes life easier for network administrators who need to manage This makes life easier for network administrators who need to manage
firewall policy for MSRP. firewall policy for MSRP.
The server part will typically not contain a userinfo component, but The server part will typically not contain a userinfo component, but
MAY do so to indicate a user account for which the session is valid. MAY do so to indicate a user account for which the session is valid.
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
"unreserved" characters, to avoid a need for escape processing. from "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 6.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:
1. The host part is compared as case insensitive. 1. The schema must match exactly.
2. If the port exists explicitly in either URL, then it must match 2. The host part is compared as case insensitive.
3. 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.
3. The resource part is compared as case insensitive. A URL without 4. The resource part is compared as case insensitive. A URL without
a resource part is never equivalent to one that includes a a resource part is never equivalent to one that includes a
resource part. resource part.
4. Userinfo parts are not considered for URL comparison. 5. 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 6.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 a connection attempt fails, the device SHOULD attempt to connect
device MUST perform the following steps: to the addresses returned in any additional A or AAAA records, in the
order the records were presented.
1. Construct an SRV [6] query string by prefixing the host name with
the service field "_msrp" and the protocol field ("_tcp" for
TCP). For example, "_msrp._tcp.host.example.com".
2. Perform a DNS SRV query using this query string.
3. Select a resulting record according to the rules in RFC2782 [6]. This process assumes that the connection port is always known
Determine the port from the chosen record. prior to resolution. This is always true for the MSRP URL uses
described in this document, that is, URLs always created and
consumed by automata, rather than by humans. The introduction of
relays may create situations where this is not the case. For
example, the MSRP URL that a user enters into a client to
configure it to use a relay may be intended to be easily
remembered and communicated by humans, and therefore is likely to
omit the port. Therefore, the relay specification may describe
additional steps to resolve the port number.
4. If necessary, determine a host device address by performing an A 6.2 Connection Direction
or AAAA query on the host name field in the selected SRV result
record. If multiple A or AAAA records are returned, the first
entry SHOULD be chosen for the initial connection attempt. This
allows any ordering created in the DNS to be preserved.
5. If the connection attempt fails, the device SHOULD attempt to When SIP is used as the signaling protocol, the device sending the
connect to the addresses returned in any additional A or AAAA initial request to communicate is responsible for opening the
records, in the order the records were presented. If all of these connection. In most cases, the device sends an offer in an INVITE or
fail, the device SHOULD attempt to use any additional SRV records UPDATE request, and gets a response in a 2xx or 18x response. In
that may have been returned, following the normal rules for SRV this case, the inviter opens a connection after receiving the
record selection. response. This can be done in parallel to sending an ACK request.
In most cases, the transport protocol will be determined separately Another, less common scenario is when the inviter sends an INVITE
from the resolution process. For example, if the MSRP URL was request with no offer, and the invitee sends an offer in the
communicated in an SDP offer or answer, the SDP M-line will contain response. In this case, the inviter opens the connection after it
the transport protocol. When an MSRP URL is communicated outside of receives the offer. It waits for successful connection prior to
SDP, the protocol SHOULD also be communicated. If a device needs to sending the answer in the SIP ACK request.
resolve an MSRP URL and does not know the protocol, it SHOULD assume
TCP.
7.1.3 The msrps URL Scheme Open Issue: The delayed offer is not likely to work in SIP, as the
invitee is almost certainly to propose RTP rather than MSRP. We
either need to do more work to specify how an endpoint that
supports both handles a delayed offer, or remove any reference to
this.
The "msrps" URL Scheme indicates that each hop MUST be secured with Other signaling protocols may use other approaches. Unless specific
TLS. Otherwise, it is used identically as an MSRP URL, except that a behavior is specified for a particular signaling protocol, the
MSRPS URL MUST NOT be considered equivalent to an MSRP URL. The MSRPS offerer is always responsible for opening the connection.
scheme is further discussed in Section 10. Open Issue: Should we put in a hook to allow SDP extensions to be
used to determine connection direction? For example, if COMEDIA
evolves to a point where it is workable for MSRP, why not allow
using it?
7.2 Connection Managment In all cases, the connecting endpoint connects to the device and port
indicated by the connection URL, using the protocol and protection
level specified by the URL scheme. If it determines that it already
has a connection associated with a URL that has a matching scheme,
host part, and port, it SHOULD reuse that connection rather than
opening a new one. Once a connection has succeeded, or the decision
to reuse a connection has been made, the connecting device MUST
immediately send an MSRP request in the context of the new session.
This message allows the device accepting the connection to associate
the MSRP session with the connection. This MAY be a SEND request, if
the device has content to send immediately, or a VISIT request.
When an MSRP endpoint receives an SDP offer, and intends to accept Open Issue: We are still discussing whether the offerer or the
it, it MUST establish a connection device described by the connection answerer should be responsible for connecting.
URL, if a connection does not already exist. If it already has a
connection associated with another session for which the connection
URL host part matches the host part of the connection URL for this
session, it SHOULD use the that connection, instead. Once connected,
the answerer MUST send a VISIT request to associate the new session
with the connection, prior to sending the SDP answer.
Either endpoint MAY tear down a connection when it no longer has any Either endpoint MAY tear down a connection when it no longer has any
active or proposed sessions associated with the connection. active or proposed sessions associated with the connection.
7.3 MSRP messages 6.3 MSRP Messages
MSRP messages are either requests or responses. Requests and MSRP messages are either requests or responses. Requests and
responses are distinguished from one another by the first line. The responses are distinguished from one another by the first line. The
first line of a Request takes the form of the request-start entry first line of a Request takes the form of the request-start entry
below. Likewise, the first line of a response takes the form of below. Likewise, the first line of a response takes the form of
response-start. The syntax for an MSRP message is as follows: response-start. The syntax for an MSRP message is as follows:
msrp-message = request-start/response-start *(header CRLF) msrp-message = request-start/response-start *(header CRLF)
[CRLF body] [CRLF body] Closing
request-start = "MSRP" SP length SP Method CRLF request-start = "MSRP" SP Method CRLF
response-start = "MSRP" SP length SP Status-Code SP response-start = "MSRP" SP Status-Code SP
Reason CRLF Reason CRLF
length = 1*DIGIT ; the length of the message,
; exclusive of the start line.
Method = SEND / VISIT / other-method Method = SEND / VISIT / other-method
other-method = token other-method = 1*(ALPHA)
header = Tran-ID / Session-URL / Content-Types / header = Tran-ID / Message-ID/ Session-URL / Content-Types /
From / To / Message-Receipt / Receipt-ID / From-Path / To-Path / Message-Receipt / Receipt-ID /
Byte-Range Byte-Range / Boundary
Status-Code = 200 ;Success Status-Code = 200 ;Success
/ 400 ;Bad Request / 400 ;Bad Request
/ 403 ;Forbidden / 403 ;Forbidden
/ 415 ;Unsupported Content Type / 415 ;Unsupported Content Type
/ 426 ;Upgrade Required / 426 ;Upgrade Required
/ 481 ;No session / 481 ;No session
/ 506 ;duplicate session / 506 ;duplicate session
/ other-status ; extension codes
other-status = 3(NUM)
Reason = token ; Human readable text describing status Reason = token ; Human readable text describing status
Tran-ID = "Tr-ID" ":" token Tran-ID = "Tr-ID" ":" token
Message-ID = "Message-ID" ":" token
Boundary = "Boundary" ":" 0*65(bchars) bcharsnospace
bcharsnospace= DIGIT / ALPHA / "'" / "(" / ")" /
"+" / "_" / "," / "-" / "." /
"/" / ":" / "=" / "?"
bchars = bcharsnospace / " "
Closing = "-------" Boundary Continue-Flag CRLF ; Boundary must match Boundary header field value
Continue-Flag = "+" / "$"
Content-Type = "Content-Type" ":" media-type Content-Type = "Content-Type" ":" media-type
media-type = type "/" subtype *( ";" parameter ) media-type = type "/" subtype *( ";" parameter )
type = token type = token
subtype = token subtype = token
parameter = attribute "=" value parameter = attribute "=" value
attribute = token attribute = token
value = token | quoted-string value = token | quoted-string
To = "To" ":" msrp_url *(SP msrp_url) To-Path = "To-Path" ":" msrp_url *(SP msrp_url)
From = "From" ":" msrp_url From-Path = "From-Path" ":" msrp_url *(SP msrp_url)
Message-Receipt = "Message-Receipt" ":" message-receipt-spec Message-Receipt = "Message-Receipt" ":" message-receipt-spec ( SEMI receipt-type )
( SEMI receipt-type )
message-receipt-spec = "negative" / "none" / "all" message-receipt-spec = "negative" / "none" / "all"
receipt-type = "receipt-type" "=" alt-receipt-type receipt-type = "receipt-type" "=" media-type; <media-type> is detailed in [RFC3261]
alt-receipt-type = r-type SLASH r-subtype *(SEMI r-parameter)
r-type = discrete-type / composite-type
discrete-type = "text" / "image" / "audio" / "video"
/ "application" / extension-token
composite-type = "message" / "multipart" / extension-token
extension-token = ietf-token / x-token
ietf-token = token
x-token = "x-" token
r-subtype = extension-token / iana-token
iana-token = token
r-parameter = r-attribute "=" r-value
r-attribute = token
r-value = token / quoted-string
Receipt-ID = "Receipt-ID" ":" token
Byte-Range = "Byte-Range" ":" byte-range-spec Byte-Range = "Byte-Range" ":" byte-range-spec
byte-range-spec = first-byte "-" last-byte byte-range-spec = first-byte "-" last-byte
first-byte = 1*DIGIT first-byte = 1*DIGIT
last-byte = 1*DIGIT last-byte = 1*DIGIT
Receipt-ID = "Receipt-ID" ":" token
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. All requests must also contain the To and From header fields. field. All requests must also contain the To-Path and From-Path,
Message-ID, and Boundary header fields, as well as the Closing field.
Messages MAY contain other fields, depending on the method or Messages MAY contain other fields, depending on the method or
response code. response code.
7.4 MSRP Transactions 6.3.1 Message Framing
MSRP messages are framed using the Boundary header field value. The
Boundary header field contains a boundary string. The Closing field
contains the same boundary string with a prefix of "-------" (seven
hyphens) and single character suffix representing a continuation
flag.
The closing field is constructed to allow for simple high speed
parsing. The use of seven hyphens forces for of them to be aligned
on a 32 bit boundary. A parser can quickly scan for the closing by
looking for a 32 bit value equivalent to "----". Once this word is
found, the scanner can carefully check and see if this is the
boundary it is looking for or just some random data. The boundary
string SHOULD have at least 16 bits of randomness in it. For
example, a valid boundary would be "Boundary:6ea7" where the 6ea7 was
a randomly chosen four digit hexadecimal number. This reduces the
chance of the boundary string colliding with content data.
The boundary string MUST NOT occur inside the body itself. The
sender MUST ensure that a collision does not occur.
Since the message fragmentation section (Section 6.7) of this
document says that large content should be sent in parcels, it
should always be possible to check for boundary collisions prior
to sending a parcel. Even in the case of streaming content, where
the sender does not have all of the content prior to sending the
first message, the chunk size should be small enough so that it is
practical to check each chunk for collisions prior to sending.
The MSRP boundary strings are distinct and independent from any MIME
boundaries that may exist in the message body. For example, if the
body is of a multipart type, the MIME headers will include a
multipart boundary. This multipart boundary MUST NOT be the same
string used in the MSRP Boundary header field.
The Closing field contains both the message boundary string and the
Continuation-Flag. The Continuation-Flag indicates whether the
entire content has been sent or not. Normally, the flag takes the
value of "$" (dollar sign) to indicate that all content has been
sent, or "+" to indicate that there is additional content that has
not yet been sent.
The term "content" in this context means a complete logical instant
message, from the perspective of the user. The content could be a
short text message, a long file transfer, etc. The logical instant
message does not necessarily correspond one-to-one with a physical
MSRP message. For example, a video message may be one logical
instant message from the users' perspective, but it will generally be
sent as a series of parcels. Each parcel would be sent as the
payload in one physical MSRP SEND request. All the requests except
the final one would contain "+" in the continuation-flag to indicate
that the content is not complete. The final message would contain
"$" to indicate that complete content has been sent.
The sender MUST NOT include a completion-flag of "+" if the payload
MIME type does not support content fragmentation.
6.3.2 Message Examples
The following is an example MSRP message sending a text payload:
MSRP SEND
Boundary: dkei38sd
To-Path:msrp://alice.atlanta.com:7777/iau39
From-Path:msrp://bob.atlanta.com:8888/9di4ea
TR-ID: 456
Message-ID: 456
Content-Type: "text/plain"
Hi, Alice! I'm Bob!
-------dkei38sd$
The following is an example of an MSRP message containing a MIME type
that uses an internal boundary (not to be confused with the MSRP
boundary):
MSRP SEND
Boundary:a38sdo To-Path:msrp://bob.atlanta.com:8888/9di4ea
From-Path:msrp:alice.atlanta.com:7777/iau39
TR-ID: 456
Message-ID: 456
Content-Type: multipart/byteranges;boundary=abcde
--abcde
Content-Type: image/jpeg
Content-range: bytes 0-*/50270
[large jpg file]
--abcde--
-------a38sdo$
6.4 MSRP Transactions
An MSRP transaction consists of exactly one request and one response. An MSRP transaction consists of exactly one request and one response.
A response matches a transaction if it share the same TR-ID value, A response matches a transaction if the following are true:
and arrives on the same connection on which the transaction was sent.
It shares the same TR-ID value.
It is received on the same connection on which the request was
sent.
The To-Path has a single entry, which matches the response
recipient's local URI for the session.
Endpoints MUST select TR-ID header field values in requests so that Endpoints MUST select TR-ID header field values in requests so that
they are not repeated by the same endpoint in scope of the given they are not repeated by the same endpoint in scope of the given
session. TR-ID values SHOULD be globally unique. The TR-ID space of session. TR-ID values SHOULD be globally unique. The TR-ID space of
each endpoint is independent of that of its peer. Endpoints MUST NOT each endpoint is independent of that of its peer. Endpoints MUST NOT
infer any semantics from the TR-ID header field beyond what is stated infer any semantics from the TR-ID header field beyond what is stated
above. In particular, TR-ID values are not required to follow any above. In particular, TR-ID values are not required to follow any
sequence. sequence.
MSRP Transactions complete when a response is received, or after a MSRP Transactions complete when a response is received, or after a
timeout interval expires with no response. Endpoints MUST treat such timeout interval expires with no response. Endpoints MUST treat such
timeouts in exactly the same way they would treat a 500 response. The timeouts in exactly the same way they would treat a 500 response.
timeout interval SHOULD be 30 seconds, but other values may be The timeout interval SHOULD be 30 seconds, but other values may be
established as a matter of local policy. established as a matter of local policy.
7.5 MSRP Sessions 6.5 MSRP Sessions
AN MSRP session is a context in which a series of instant messages AN MSRP session is a context in which a series of instant messages
are exchanged, using SEND requests. A session has two endpoints, are exchanged, using SEND requests. A session has two endpoints,
identified by MSRP URLs. identified by MSRP URLs.
7.5.1 Initiating an MSRP session 6.5.1 Initiating an MSRP session
When an endpoint wishes to engage a peer in a message session, it When an endpoint wishes to engage a peer in a message session, it
invites the peer to communicate using an SDP offer, carried over SIP invites the peer to communicate using an SDP offer, carried over SIP
or some other protocol supporting the SDP offer/answer model. For the or some other protocol supporting the SDP offer/answer model. For
purpose of this document, we will refer to the endpoint choosing to the purpose of this document, we will refer to the endpoint choosing
initiate communication as the offerer, and the peer being invited as to initiate communication as the offerer, and the peer being invited
the answerer. as the answerer.
The offerer MUST be prepared to accept a connection from the Under normal circumstances, the answerer MUST be prepared to accept
answerer. a connection from the offerer.
The offerer MUST perform the following steps: The offerer MUST perform the following steps:
1. Construct a MSRP URL to serve as the local URL. This URL MUST 1. Construct a MSRP URL to serve as the local URL.
resolve to the location that the offerer wishes to host the
connection.
2. Listen for a connection from the peer.
3. Construct an SDP offer as described in Section 6, including the 2. Construct an SDP offer as described in Section 5, including the
list of allowed IM payload formats in the accept-types attribute. list of allowed IM payload formats in the accept-types attribute.
The offerer puts its local URL into the path attribute, as The offerer puts its local URL into the path attribute, as
described in Section 6.4. This URL becomes the offerer's local described in Section 5.4. This URL becomes the offerer's local
path. path.
4. Send the SDP offer using the normal processing for the signaling 3. Send the SDP offer using the normal processing for the signaling
protocol. protocol.
If the answerer chooses to participate, it MUST perform the following If the answerer chooses to participate, it MUST perform the following
steps: steps:
1. Parse the first URL from the offered path attribute, to be the 1. Store the contents of the offered sdp path attribute as the
connection URL. The full path attribute value will be the remote path for he session.
answerer's remote path. If the path only contained a single URL
entry, then the connection URL and the remote path are identical.
2. Determine if it has any existing connection that is associated
with a connection URL host part that matches that of the
connection URL for this session, and with a transport protocol
matching that from the M-line. If one exists, the answerer SHOULD
use it for the new session rather than establishing a new
connection.
[Open Issue: Should we discuss situations when an endpoint may
want to intentially not share a connection?]
3. If no appropriate connection already exists, determine the host 2. Construct a MSRP URL that resolves to itself. Save this as the
address and port from the peer URL, following the procedures in local URL for the session.
section Section 7.1, and connect using the transport protocol
from the M-line.
4. Construct a MSRP URL . This URL MUST resolve to the the answerer. 3. Listen for a connection on the transport, address, and port
This URL becomes the answerer's local URL. described by the local URL.
5. Construct a VISIT request, which MUST contain the following 4. Send a SDP answer via the signaling protocol, according to the
information: following rules:
1. An To header field containing the remote URL. 1. The C-line is copied unmodified from the offer.
2. A From containing the answerer's local URL. 2. The accept-types attribute contains the SEND payload media
types that the answerer is willing to accept. The
accept-types attribute in the answer MUST be either the same
as that of the offer, or a subset.
3. A TR-ID header field containing a unique transaction ID. 3. The path attribute contains the answerer's local URL.
4. A size field containing size of the message subsequent to the Again, this document assumes that no relays are introduced. If
start-line. the answerer were to introduce one or more relay, it would add the
appropriate URLs to the path attribute in the SDP answer. It
would not need to listen for a connection, as the first relay in
its path would have that honor.
6. Send the request and wait for a response When the offerer receives the answer, it MUST perform the following
steps:
7. If the VISIT transaction succeeds, send a SDP answer via the 1. Save the path attribute contents from the SDP answer as the
signaling protocol, according to the following rules: remote path.
1. The C-line is copied unmodified from the offer. 2. Designate the first entry in the remote path as the adjacent-hop
URL.
2. The M-Line contains a dummy port value, the protocol field 3. Check to see if a connection already exists that is associated
from the original offer. with URL that matches the scheme, host part, and port of the
adjacent-hop URL. If such a connection exists, the device SHOULD
reuse it, rather than opening a new connection.
3. The accept-types attribute contains the SEND payload media 4. If no matching connection exists, attempt to open a connection to
types that the answerer is willing to accept. The the adjacent hop using the transport, address, port, and
accept-types attribute in the answer MUST be either the same protection mode designated by the adjacent-hop URL.
as that of the offer, or it MUST be a subset.
4. The path attribute contains the answerer's local URL. 5. If the connection succeeds, or if a connection is reused,
8. If the VISIT transaction fails, the answerer MUST reject the immediately send a MSRP request to the opposite peer. This
offer. SHOULD be a visit request, but MAY be a SEND request if the
endpoint has legitimate content to send.
7.5.2 Handling VISIT requests 6.5.2 Handling the initial request
An MSRP endpoint that is hosting a session will receive a VISIT An MSRP device that accepts a network connection will receive an
request from the visiting endpoint. When an endpoint receives a VISIT immediate MSRP request from the connecting endpoint. This may be a
request, it MUST perform the following procedures: SEND or VISIT request. When an endpoint receives such a request, it
MUST perform the following procedures:
1. Check if state exists for a session with a local URL that matches 1. Check if state exists for a session with a local URL that matches
the To header field value of the VISIT request. If so, and if no the To-Path header field value of the VISIT request. If so, and
previous VISIT request has been received for that URL, then if no previous request has been received for that URL on a
return a 200 response, and save state associating the URL in the different connection, then return a 200 response, and save state
From header field with the connection on which the request was associating the first URL in the From-Path header field with the
received . connection on which the request was received .
2. If the state exists, and a matching VISIT transaction has already 2. If the state exists, and a matching request has occurred on a
occured, return a 506 response and do not change session state in different connection, return a 506 response and do not change
any way. session state in any way.
3. If no matching state exists, return a 481 response, and do not 3. If no matching state exists, return a 481 response, and do not
change session state in any way. change session state in any way.
7.5.3 Sending Instant Messages on a Session 6.5.3 Sending Instant Messages on a Session
Once a MSRP session has been established, either endpoint may send Once a MSRP session has been established, either endpoint may send
instant messages to its peer using the SEND method. When an endpoint instant messages to its peer using the SEND method. When an endpoint
wishes to do so, it MUST construct a SEND request according to the wishes to do so, it MUST construct a SEND request according to the
following process: following process:
1. Insert a To header field containing the remote path. Note that 1. Insert a To-Path header field containing the path to the opposite
this is the full remote path, not just the connection or peer endpoint, in order from left to right.
URL.
2. Insert a From header field containing the local URL. 2. Insert a From-Path header field containing the local URL.
3. Insert the message payload in the body, and the media type in the 3. Insert the message payload in the body, and the media type in the
Content-Type header field. The media type MUST match one of the Content-Type header field. The media type MUST match one of the
types in the format list negotiated in the SDP exchange. If a "*" types in the format list negotiated in the SDP exchange. If a
was present in the accept-types attribute, then the media type "*" was present in the accept-types attribute, then the media
SHOULD match one of the explicitly listed entries, but MAY be any type SHOULD match one of the explicitly listed entries, but MAY
other arbitrary value. be any other arbitrary value.
4. Set the TR-ID header field to a unique value. 4. Set the TR-ID and Message-ID header fields to a unique value.
The sender MAY set these fields to the same value.
5. Send the request on the connection associated with the session. 5. Send the request on the connection associated with the session.
6. If a 2xx response code is received, the transaction was 6. If a 2xx response code is received, the transaction was
successful. successful.
7. If a 415 response is received, this indicates the recipient is 7. If a 415 response is received, this indicates the recipient is
unable or unwilling to process the media type. The sender SHOULD unable or unwilling to process the media type. The sender SHOULD
NOT attempt to send that particular media type again in the NOT attempt to send that particular media type again in the
context of this session. context of this session.
8. If any other response code is received, or if the transaction 8. If any other response code is received, or if the transaction
times out, the endpoint SHOULD assume the session has failed, times out, the endpoint SHOULD assume the session has failed,
either tear down the session, or attempt to re-establish the either tear down the session, or attempt to re-establish the
session by sending an updated SDP offer proposing a new session by sending an updated SDP offer proposing a new
connection. If a new connection is established, the endpoint MAY connection. If a new connection is established, the endpoint MAY
choose to resend the content on the new connection. choose to resend the content on the new connection.
Open Issue: Do we need to create a duplicate mechanism to suppress Open Issue: Do we need to create a duplicate mechanism to suppress
duplicate messages when a new connection is established in this duplicate messages when a new connection is established in this
fashion? mechanism? List consensus seems to indicate we do. We may fashion? mechanism? List consensus seems to indicate we do. We
need to specify that the tr-id space spans a sequence of may need to specify that the tr-id space spans a sequence of
connections if they are associated with same stream, and of connections if they are associated with same stream, and of
course, specify what it means for a stream to span connections. course, specify what it means for a stream to span connections.
When an endpoint receives a SEND request, it MUST perform the When an endpoint receives a SEND request, it MUST perform the
following steps. following steps.
1. Check that it has state for a session with a local URL matching 1. Check that it has state for a session with a local URL matching
the To value. If no matching session exists, return a 481 the To-Path value. If no matching session exists, return a 481
response. response.
2. Determine that it understands the media type in the body, if any 2. Determine that it understands the media type in the body, if any
exists. exists.
3. If it does, return a 200 response and render the message to the 3. If it does, return a 200 response and render the message to the
user. The method of rendering is a matter of local policy. If the user. The method of rendering is a matter of local policy. If
message contained no body at all, the endpoint should quietly the message contained no body at all, the endpoint should quietly
ingore it. ignore it.
4. If it does not understand the media type, return a 415 response. 4. If it does not understand the media type, return a 415 response.
The endpoint MUST NOT return a 415 response for any media type The endpoint MUST NOT return a 415 response for any media type
for which it indicated support in the SDP exchange. for which it indicated support in the SDP exchange.
7.5.4 Ending a Session 6.5.4 Ending a Session
When either endpoint in an MSRP session wishes to end the session, it When either endpoint in an MSRP session wishes to end the session, it
first signals its intent using the normal processing for the first signals its intent using the normal processing for the
signaling protocol. For example, in SIP, it would send a BYE request signaling protocol. For example, in SIP, it would send a BYE request
to the peer. After agreeing to end the session, the host endpoint to the peer. After agreeing to end the session, the host endpoint
MUST release any resources acquired as part of the session. MUST release any resources acquired as part of the session.
Each peer MUST destroy all local state for the session. This involves Each peer MUST destroy all local state for the session. This
completely removing the state entry for the session and invalidating involves completely removing the state entry for the session and
the session URL. invalidating the session URL.
If no other sessions are using the connection, the endpoint that If no other sessions are using the connection, the endpoint that
opened it SHOULD tear it down. However, the passive party MAY tear opened it SHOULD tear it down. However, the passive party MAY tear
down an unused connection after a locally configured timeout period. down an unused connection after a locally configured timeout period.
When an endpoint chooses to close a session, it may have SEND When an endpoint chooses to close a session, it may have SEND
transactions outstanding. For example, it may have send SEND requests transactions outstanding. For example, it may have send SEND
to which it has not yet received a response, or it may have received requests to which it has not yet received a response, or it may have
SEND requests that to which it has not responded. Once an endpoint received SEND requests that to which it has not responded. Once an
has decided to close the connection, it SHOULD wait for such endpoint has decided to close the connection, it SHOULD wait for such
outstanding transactions to complete. It SHOULD NOT generate any new outstanding transactions to complete. It SHOULD NOT generate any new
SEND transactions, and it MAY choose not to respond to any new SEND SEND transactions, and it MAY choose not to respond to any new SEND
requests that are received after it decides to close the session. It requests that are received after it decides to close the session. It
SHOULD not respond to any new messages that arrive after it signals SHOULD not respond to any new messages that arrive after it signals
its intent to close the session. its intent to close the session.
When an endpoint is signaled of its peer's intent to close a session, When an endpoint is signaled of its peer's intent to close a session,
it SHOULD NOT initiate any more SEND requests. It SHOULD wait for any it SHOULD NOT initiate any more SEND requests. It SHOULD wait for
outstanding transactions that it initiated to complete, and it SHOULD any outstanding transactions that it initiated to complete, and it
attempt respond to any open SEND transactions received prior to being SHOULD attempt respond to any open SEND transactions received prior
signaled. to being signaled.
It is not possible to completely eliminate the chance of a session It is not possible to completely eliminate the chance of a session
terminating with incomplete SEND transactions. When this occurs, the terminating with incomplete SEND transactions. When this occurs, the
endpoint SHOULD clearly inform the user that the messages may not endpoint SHOULD clearly inform the user that the messages may not
have been delivered. have been delivered.
7.5.5 Managing Session State and Connections 6.5.5 Managing Session State and Connections
A MSRP session is represented by state at each endpoint, identified A MSRP session is represented by state at each endpoint, identified
by the local URL and remote path. An active session also has an by the local URL and remote path. An active session also has an
associated network connection. associated network connection.
If the connection fails for any reason, the session hosting device If the connection fails for any reason, the device MUST invalidate
MUST invalidate the session state for all sessions using the the session state for all sessions using the connection. Once a
connection. Once a connection is dropped, any associated session connection is dropped, any associated session state MUST NOT be
state MUST NOT be reused. If an endpoint wishes to continue to reused. If an endpoint wishes to continue to communicate after
communicate after detecting a connection failure, it MAY initiate a detecting a connection failure, it MAY initiate a new SDP exchange to
new SDP exchange to negotiate a new session URL. Otherwise, it SHOULD negotiate a new session URL. Otherwise, it SHOULD attempt to tear
attempt to tear down the session using the rules of the signaling down the session using the rules of the signaling protocol.
protocol.
It would be nice to allow sessions to be recovered after a It would be nice to allow sessions to be recovered after a
connection failure, perhaps by allowing the active endpoint to connection failure, perhaps by allowing the active endpoint to
reconnect, and send a new VISIT request. However, this approach reconnect, and send a new VISIT request. However, this approach
creates a race condition between the time that the hosting device creates a race condition between the time that the hosting device
notices the failed connection, and the time that the endpoint notices the failed connection, and the time that the endpoint
tries to recover the session. If the endpoint attempts to tries to recover the session. If the endpoint attempts to
reconnect prior to the hosting device noticing the failure, the reconnect prior to the hosting device noticing the failure, the
hosting device will interpret the recovery attempt as a conflict. hosting device will interpret the recovery attempt as a conflict.
The only way around this would be to force the hosting device to The only way around this would be to force the hosting device to
do a liveness check on the original connection, which would create do a liveness check on the original connection, which would create
a lot of complexity and overhead that do not seem to be worth the a lot of complexity and overhead that do not seem to be worth the
trouble. trouble.
Open Issue: Is this still an issue with shared connections? 6.6 Delivery Status Notification
7.6 Delivery Status Notification
Delivery Status Notification (DSN)[10] provides an extensible MIME Delivery Status Notification (DSN)[10] provides an extensible MIME
content-type that is used to convey both positive and negative status content-type that is used to convey both positive and negative status
of messages in the network. This functionality is extremely useful of messages in the network. This functionality is extremely useful
for MSRP sessions that traverse a relay device. Relay support is for MSRP sessions that traverse a relay device. Relay support is
considered out of scope for this specification and will be included considered out of scope for this specification and will be included
in a separate specification. This section will only cover in a separate specification. This section will only cover
functionality required by non-relay aware endpoints for basic MSRP functionality required by non-relay aware endpoints for basic MSRP
operation. An MSRP endpoint MUST be capable of performing the DSN operation. An MSRP endpoint MUST be capable of performing the DSN
operations described in this specification and SHOULD support the DSN operations described in this specification and SHOULD support the DSN
MIME type outlined. An MSRP endpoint MAY use an alternative payload MIME type outlined. An MSRP endpoint MAY use an alternative payload
for reporting message status using the procedures outlined in this for reporting message status using the procedures outlined in this
specification which MUST be negotiated during the SDP offer/answer specification.
exchange.
7.6.1 Endpoint DSN Request 6.6.1 Endpoint DSN Request
An endpoint that wishes to be informed of message delivery/failure An endpoint that wishes to be informed of message delivery/failure
needs to request such information. This is achieved by including an needs to request such information. This is achieved by including an
MSRP Receipt-Request header in the request. The header can equal one MSRP Receipt-Request header in the request. The header can equal one
of three values: of three values:
negative: Indicates the client only requires failure delivery report. negative: Indicates the client only requires failure delivery
report.
none: Indicates the client requires no delivery reports. none: Indicates the client requires no delivery reports.
all: Indicates the client requires both positive and negative all: Indicates the client requires both positive and negative
delivery reports. delivery reports.
Within the scope of this specification the Receipt-Request header is Within the scope of this specification the Receipt-Request header is
only used in MSRP SEND requests. Future extensions to this only used in MSRP SEND requests. Future extensions to this
specification MAY use the mechanism described in this document for specification MAY use the mechanism described in this document for
delivery/failure status notification of other MSRP requests. delivery/failure status notification of other MSRP requests.
The default value for this header if not present in a request is The default value for this header if not present in a request is
'negative'. An example of this header would be: 'negative'. An example of this header would be:
skipping to change at page 23, line 12 skipping to change at page 25, line 17
The default value for this header if not present in a request is The default value for this header if not present in a request is
'negative'. An example of this header would be: 'negative'. An example of this header would be:
Message-Receipt: negative Message-Receipt: negative
The default DSN MIME type is detailed in RFC 1894[10]. It is The default DSN MIME type is detailed in RFC 1894[10]. It is
possible for MSRP endpoints to use a different format if required. possible for MSRP endpoints to use a different format if required.
This can be achieved by including a 'receipt-type' parameter in the This can be achieved by including a 'receipt-type' parameter in the
Message-Receipt header. This parameter contains the alternative MIME Message-Receipt header. This parameter contains the alternative MIME
type that SHOULD be used for this particular receipt transaction. type that SHOULD be used for this particular receipt transaction. A
The value included in this header MUST equal a value negotiated client specifying an alternative 'receipt-type' for an MSRP
during the SDP offer/answer exchange. transaction MUST also be capable of receiving the default format
specified in this document. This allows intermediaries, such as MSRP
Open Issue: If we negotiate this in the SDP, that also means the relays, to generate failure reports when MSRP transaction failure
format would be legal for normal messages. Is this okay? Also, I occurs.
assume that if we negotiated "*" in the sdp, then any format would be
legal? Do we even need this to be extensible?
Open Issue: Is the RFC1894 the right thing to use? Do we need to add
further verbiage on the format beyond the reference to the RFC?
7.6.2 DSN generation 6.6.2 DSN generation
An MSRP endpoint implementing this specification SHOULD be able to An MSRP endpoint implementing this specification SHOULD be able to
generate positive delivery status of MSRP requests. On receiving an generate positive delivery status of MSRP requests. On receiving an
MSRP request containing a Message-Receipt header with a value of MSRP request containing a Message-Receipt header with a value of
TRUE, the endpoint will carry out normal MSRP response generation and 'all', the endpoint will carry out normal MSRP response generation
MUST generate an MSRP REPORT request using the following procedures: and MUST generate an MSRP REPORT request using the following
procedures:
1. Insert a To header containing the From value from the original 1. Insert a To header containing the From value from the original
request. request.
2. Insert a From header containing the To value from the original 2. Insert a From header containing the To value from the original
request. request.
3. Insert the message status payload in the body of the request. If 3. Insert the message status payload in the body of the request. If
the default DSN MIME type from DSN[10] is used then the MSRP the default DSN MIME type from DSN[10] is used then the MSRP
Content-Type header MUST use the value multipart/report. The Content-Type header MUST use the value multipart/report. The
relevance of DSN headers in MSRP can be found in section 7.6.5. relevance of DSN headers in MSRP can be found in section 7.6.5.
An alternative MIME type MAY be used but MUST be specified in the An alternative MIME type MAY be used but MUST be specified in the
Content-Type header. Negative DSN generation is considered out Content-Type header. Negative DSN generation is considered out
of the scope of this document and will be covered in a separate of the scope of this document and will be covered in a separate
MSRP relay document. MSRP relay document.
4. Insert a new transaction ID (TR-ID). 4. Insert a new transaction ID (TR-ID).
5. Insert the TR-ID value that appeared in the original MSRP request 5. (Optional) Insert an MSRP Byte-Range header containing the value
into the Receipt-ID header. This allows a requesting client to from 'multipart/byteranges' MIME header Content-range from the
explicitly correlate a REPORT request with the original request. payload of a chunked message. It is possible that an entity
This correlation is implementation specific and makes no downstream may decide to break up an MSRP SEND message and send
requirements on clients to hold state for transactions ID's. it in separate chunks. The originating client would be
Information regarding the original request can be obtained from transparent to this operation but would need to be informed if a
the DSN MIME type outlined in [10]. DSN only represents part of the request.
6. If the associated SEND request contained a chunk, that is, used
the "message/byteranges" fromat, insert an MSRP Byte-Range header
containing the value from the Content-range header field. It is
possible that an intermediary device may have broken the MSRP
SEND request into chunks without the knowledge of the sending
client.
7.6.3 Receiving positive DSN 6.6.3 Receiving positive DSN
An MSRP endpoint implementing this specification MUST be able to An MSRP endpoint implementing this specification MUST be able to
receive positive delivery status of MSRP requests. receive positive delivery status of MSRP requests.
7.6.4 Receiving negative DSN 6.6.4 Receiving negative DSN
An MSRP endpoint implementing this specification MUST be able to An MSRP endpoint implementing this specification MUST be able to
receive negative delivery status of MSRP requests. receive negative delivery status of MSRP requests.
7.6.5 DSN headers in MSRP 6.6.5 DSN headers in MSRP
To Do - Define meaning + relevance of DSN headers. The format of a default DSN report is taken from RFC 1894[10]. Only
a minimal subset of fields are used, as detailed in the remainder of
this section.
7.7 Message Fragmentation 6.6.5.1 Per-Message DSN header usage
MSRP devices MAY break large content into fragments, and send each original-envelope-id: See Section 6.6.5.3
fragment in a separate SEND request. Each fragment is encapsulated
using the "message/byteranges" MIME type, defined in RFC2616 [11], to
correlate parts of the message. The definition of large is
determined by local policy. MSRP endpoints MUST be capable of
receiving and processing fragmented messages.
Open Issue: Do we want to negotiate the use of message/byterange like reporting-mta: See Section 6.6.5.4
any other MIME type? I assume no, as we want to allow relays to
fragment messages, and relays are not privy to the content-types dsn-gateway: Not Used
negotiated for a session.
received-from-mta: Not Used
arrival-date: Not Used
6.6.5.2 Per-Recipient DSN header usage
original-recipient Not Used
final-recipient: See Section 6.6.5.5
action: See Section 6.6.5.6
status: See Section 6.6.5.7
remote-mta: Not Used
diagnostic-code: Not Used
last-attempt-date: Not Used
will-retry-until:Not Used
6.6.5.3 original-envelope-id usage
The 'original-envelope-id' field contains a unique identifier which
is used to correlate a DSN report with the originating MSRP
transaction. The entity generating the DSN report MUST insert the
Message-ID value that appeared in the original MSRP request into the
'original-envelope-id' field. This allows a requesting client to
explicitly correlate a REPORT request with the original request.
This correlation is implementation specific and makes no requirements
on clients to hold state for transactions ID's. Information
regarding the original request can be obtained from the DSN MIME type
outlined in [10].
6.6.5.4 reporting-mta
The 'reporting-mta-field' MUST follow the guidelines set out in RFC
1894[10]. The 'mta-name-type' from RFC1894[10] MUST use the value of
'msrp-name-type', as defined in section 9 of this specification. The
'mta-name' value for this field as specified in RFC1894 [10] MUST
equal an MSRP URL representing itself.
6.6.5.5 final-recipient
The 'final-recipient-field' MUST follow the guidelines set out in RFC
1894[10]. The 'address-type' from RFC1894 [10] MUST use the value of
'msrp-address-type', as defined in section 9 of this specification.
The 'address-type' value for this field as specified in RFC1894 [10]
MUST equal the value contained in the MSRP 'To' header from the
original request being reported on.
6.6.5.6 action
The 'action' field MUST follow the guidelines set out in RFC
1894[10]. An MSRP entity constructing a DSN report MUST use the
'delivered' value for a successful delivery and MUST use the 'failed'
value for an un-successful delivery. The other values specified for
the 'action' field in RFC 1894[10] MAY be used.
6.6.5.7 status
The 'status' field MUST follow the guidelines set out in RFC
1894[10]. An MSRP entity constructing a DSN report MUST represent
the MSRP status code in the correct format detailed in RFC 1894[10]
for the 'status' field of a DSN report. An MSRP status code consists
of a three digit number while a DSN status is three digits separated
by '.'. An example would be:
Status: 5.0.0 (unknown permanent failure)
When generating this field the first digit of the MSRP status code
(working from left to right) MUST be placed in the first part of the
'status' DSN field. The second digit MUST be placed in the second
part of the 'status' DSN field. The third digit MUST be placed in
the third part of the 'status' DSN field. An example of a DSN
'status' field value would be:
An MSRP '200' success response would be mapped to:
Status: 2.0.0 (OK)
The MSRP reason phrase mapped to a DSN 'status' field MAY be enclosed
in parentheses if required.
6.7 Message Fragmentation
MSRP devices SHOULD break large content into fragments, and send each
fragment in a separate SEND request. A message fragment sent in this
way is known as a "parcel". Large content is defined to be anything
larger than 2K bytes. Each parcel is encapsulated using the
"message/byteranges" MIME type, defined in RFC2616 [11], to correlate
parts of the message. The definition of large is determined by local
policy. MSRP endpoints MUST be capable of receiving and processing
fragmented messages.
Open Issue: Do we want to negotiate the use of message/byteranges
like any other MIME type? I assume no, as we want to allow relays
to fragment messages, and relays are not privy to the
content-types negotiated for a session.
Although relays are not in scope for this document, we expect that Although relays are not in scope for this document, we expect that
relays will be able to introduce fragmentation, as well as change the relays will be able to introduce fragmentation, as well as change the
fragmentation of previously fragemented messages. Therefore, all MSRP fragmentation of previously fragmented messages. Therefore, all MSRP
endpoints MUST be able to receive fragmented messages. endpoints MUST be able to receive fragmented messages.
7.7.1 MSRP Usage of message/byteranges 6.7.1 MSRP Usage of message/byteranges
The "message/byteranges" type allows multiple ranges in a single The "message/byteranges" type allows multiple ranges in a single
document. However, MSRP devices MUST NOT include more than one byte document. However, MSRP devices MUST NOT include more than one byte
range in a single request. Although the HTTP usage for a document range in a single request. Although the HTTP usage for a document
containing a single byte range indicates putting the "Content-Range" containing a single byte range indicates putting the "Content-Range"
header in a header field, rather than in the body itself, header in a header field, rather than in the body itself,
"Content-Range" MUST NOT appear as an MSRP header field. "Content-Range" MUST NOT appear as an MSRP header field.
[Open Issue: How much of the message/byteranges specification should Open Issue: How much of the message/byteranges specification
we explain or copy forward? Copying too much obscures the fact that should we explain or copy forward? Copying too much obscures the
rfc2616 is the normative definition, but it may be helpful to have fact that rfc2616 is the normative definition, but it may be
more context here.] helpful to have more context here.
If the MSRP device has a priori knowledge of the overall content If the MSRP device has a priori knowledge of the overall content
length, it SHOULD put that length into instance-length. The device length, it SHOULD put that length into instance-length. The device
MAY place a "*" in instance-length if it does not have such MAY place a "*" in instance-length if it does not have such
knowledge. knowledge.
Similarly, if the device has a priori knowledge of the number of Similarly, if the device has a priori knowledge of the number of
bytes in a byte range, it SHOULD place the last bype position in bytes in a byte range, it SHOULD place the last byte position in
last-byte-pos. Otherwise, it MAY use a "*". If "*" is present, the last-byte-pos. Otherwise, it MAY use a "*". If "*" is present, the
recipient MUST determine the last-byte-position through normal recipient MUST determine the last-byte-position through normal
request framing and body processing. An MSRP device MUST put the request framing and body processing. An MSRP device MUST put the
initial byte position in first-byte-pos. initial byte position in first-byte-pos.
7.8 Method Descriptions 6.8 Method Descriptions
This section summarizes the purpose of each MSRP method. All MSRP This section summarizes the purpose of each MSRP method. All MSRP
messages MUST contain the TR-ID, From, and To header fields. All messages MUST contain the TR-ID, From-Path, To-Path, and Boundary
messages MUST contain a length field in the start line that indicates header fields, as well as a Closing field. Additional requirements
the overall length of the request, including any body, but not exist depending on the individual method.
including the start line itself. Additional requirements exist
depending on the individual method.
7.8.1 SEND 6.8.1 SEND
The SEND method is used by both the host and visitor endpoints to The SEND method is used by both the host and visitor endpoints to
send instant messages to its peer endpoint. A SEND request MUST send instant messages to its peer endpoint. A SEND request MUST
contain a To header field containing the sender's remote path, and a contain a To-Path header field containing the sender's remote path, a
From header field containing the sender's local URL. SEND requests From-Path header field containing the sender's local URL, and a
SHOULD contain a MIME body part. The body MUST be of a media type Message-ID header field. SEND requests SHOULD contain a MIME body
included in the format list negotiated in the SDP exchange. If a body part. The body MUST be of a media type included in the format list
is present, the request MUST contain a Content-Type header field negotiated in the SDP exchange. If a body is present, the request
identifying the media type of the body. MUST contain a Content-Type header field identifying the media type
of the body.
To Do: We plan to expand the use of MIME headers to allow any To Do: We plan to expand the use of MIME headers to allow any
standard MIME header in a SEND request. This is not included in standard MIME header in a SEND request. This is not included in
this version for the sake of getting the draft out as soon as this version for the sake of getting the draft out as soon as
possible, but will follow soon. possible, but will follow soon.
7.8.2 VISIT 6.8.2 VISIT
The visiting endpoint uses the VISIT method to associate a network The visiting endpoint uses the VISIT method to associate a network
connection with the session state at the hosting device. A VISIT connection with the session state at the listening device. A VISIT
request MUST include a To header including the sender's connection request MUST include a To-Path header including the sender's remote
URL, and a From header field containing the sender's local URL. path, and a From-Path header field containing the sender's local URL.
7.8.3 REPORT This purpose can also be served by a SEND request, if the sender has
immediate content to send.
Report is used by an endpoint/relay to convey message delivery status Open Issue: There is overlap between SEND and VISIT as currently
defined. We should consider either removing VISIT entirely and
just use an empty SEND request, or we should always require VISIT.
(This would not apply to a endpoint connecting to its own relay.)
7.9 Response Code Descriptions 6.8.3 REPORT
Report is used by an endpoint or relay to convey message delivery
status
6.9 Response Code Descriptions
This section summarizes the various response codes. Except where This section summarizes the various response codes. Except where
noted, all responses MUST contain a TR-ID header field matching the noted, all responses MUST contain a TR-ID header field matching the
TR-ID header field of the original request, and To and From headers TR-ID header field of the original request, and To-Path and From-Path
matching those of the original request. headers matching those of the original request.
7.9.1 200 6.9.1 200
The 200 response code indicates a successful transaction. The 200 response code indicates a successful transaction.
7.9.2 400 6.9.2 400
A 400 response indicates a request was unintelligible. A 400 response indicates a request was unintelligible.
7.9.3 415 6.9.3 415
A 415 response indicates the SEND request contained a MIME A 415 response indicates the SEND request contained a MIME
content-type that is not understood by the receiver. content-type that is not understood by the receiver.
7.9.4 426 6.9.4 426
A 426 response indicates that the request is only allowed over TLS A 426 response indicates that the request is only allowed over TLS
protected connections. protected connections.
7.9.5 481 6.9.5 481
A 481 response indicates that no session exists for the connection. A 481 response indicates that no session exists for the connection.
7.9.6 506 6.9.6 506
A 506 response indicates that a VISIT request occurred in which the A 506 response indicates that a VISIT request occurred in which the
To header indicates a local path that is already associated with To-Path header indicates a local path that is already associated with
another connection. A 506 response MUST NOT be returned in response another connection. A 506 response MUST NOT be returned in response
to any method other than VISIT. to any method other than VISIT.
7.10 Header Field Descriptions 6.10 Header Field Descriptions
This section summarizes the various header fields. MSRP header fields This section summarizes the various header fields. MSRP header
are single valued; that is, they MUST NOT occur more than once in a fields are single valued; that is, they MUST NOT occur more than once
particular request or response. in a particular request or response.
7.10.1 TR-ID 6.10.1 TR-ID
The TR-ID header field contains a transaction identifier used to map The TR-ID header field contains a transaction identifier used to map
a response to the corresponding request. A TR-ID value MUST be unique a response to the corresponding request. A TR-ID value MUST be
among all values used by a given endpoint inside a given session. unique among all values used by a given endpoint inside a given
MSRP elements MUST NOT assume any additional semantics for TR-ID. session. MSRP elements MUST NOT assume any additional semantics for
TR-ID.
7.10.2 To 6.10.2 Message-ID
The To header field is used to indicate the sender's remote path. All The Message-ID header field contains a message identifier used to map
MSRP requests MUST contain a To header field. a delivery status notification to the corresponding request. TR-ID
cannot be used for this purpose, as it may change between hops if
relays are involved. A Message-ID value MUST be unique among all
values used by a given endpoint inside a given session. MSRP
elements MUST NOT assume any additional semantics for Message-ID.
The Message-ID value MAY be the same as the original TR-ID value.
7.10.3 From 6.10.3 To-Path
The From header field is used to indicate the sender's local URL. All The To-Path header field is used to indicate the sender's remote
MSRP requests MUST contain a From header field. path. All MSRP requests MUST contain a To-Path header field.
7.10.4 Content-Type 6.10.4 From-Path
The From-Path header field is used to indicate the sender's local
URL. All MSRP requests MUST contain a From-Path header field.
6.10.5 Boundary
The Boundary header field contains the boundary string that is used
to terminate the message. This string MUST have at least 16 bits of
randomness. This string MUST NOT be duplicated anywhere else in the
message. The Boundary header field is mandatory for all MSRP
messages, and SHOULD be the first header field in the message.
6.10.6 Closing
The Closing field contains the same boundary string that was
originally listed in the Boundary header field, as well as the
Continuation-Flag field. The Closing field MUST occur at the end of
each MSRP message. If the message content has been sent completely,
the Interrupt-Flag field value MUST be ""$ (dollar sign). If there
is further content to send as part of the "logical" instant message,
this field value MUST be "+". (plus sign.)
6.10.7 Content-Type
The Content-Type header field is used to indicate the MIME media type The Content-Type header field is used to indicate the MIME media type
of the body. Content-Type MUST be present if a body is present. of the body. Content-Type MUST be present if a body is present.
To Do: The work group has agreed to allow the use of any standard To Do: The work group has agreed to allow the use of any standard
MIME header. This is not reflected in this version, but will be in MIME header. This is not reflected in this version, but will be
a shortly forthcoming one. in a shortly forthcoming one.
8. Example 7. Example
This section shows an example message flow for the most common This section shows an example message flow for the most common
scenario. The example assumes SIP is used to transport the SDP scenario. The example assumes SIP is used to transport the SDP
exchange. Details of the SIP messages and SIP proxy infrastructure exchange. Details of the SIP messages and SIP proxy infrastructure
are omitted for the sake of brevity. In the example, assume the are omitted for the sake of brevity. In the example, assume the
offerer is sip:alice@atlanta.com and the answerer is offerer is sip:alice@atlanta.com and the answerer is
sip:bob@biloxi.com. In any given MSRP message, an "xx" in the length sip:bob@biloxi.com.
field indicates the actual length of the rest of the message.
Alice Bob Alice Bob
| | | |
| | | |
|(1) (SIP) INVITE | |(1) (SIP) INVITE |
|----------------------->| |----------------------->|
|(2) (MSRP) VISIT |
|<-----------------------|
|(3) (MSRP) 200 OK |
|----------------------->|
|(4) (SIP) 200 OK | |(4) (SIP) 200 OK |
|<-----------------------| |<-----------------------|
|(5) (SIP) ACK | |(5) (SIP) ACK |
|----------------------->| |----------------------->|
|(6) (MSRP) SEND | |(6) (MSRP) SEND |
|----------------------->| |----------------------->|
|(7) (MSRP) 200 OK | |(7) (MSRP) 200 OK |
|<-----------------------| |<-----------------------|
|(8) (MSRP) SEND | |(8) (MSRP) SEND |
|<-----------------------| |<-----------------------|
|(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 local URL of msrp://alicepc.atlanta.com:7777/ 1. Alice constructs a local URL of
iau39 and listens for a connection on TCP port 7777. msrp://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
v=0 v=0
o=alice 2890844557 2890844559 IN IP4 host.anywhere.com o=alice 2890844557 2890844559 IN IP4 host.anywhere.com
s= s=
c=IN IP4 fillername c=IN IP4 fillername
t=0 0 t=0 0
m=message 9999 msrp/tcp * m=message 9999 msrp *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrp://alicepc.atlanta.com:7777/iau39 a=path:msrp://alicepc.atlanta.com:7777/iau39
2. Bob opens a TCP connection to alicepc.atlanta.com:7777: 2. Bob->Alice (SIP): 200 OK
Bob->Alice (MSRP):
MSRP xx VISIT
To:msrp://alicepc.atlanta.com:7777/iau39
From:msrp://bob.atlanta.com:8888/9di4ea
Tr-ID:sie09s
3. Alice->Bob (MSRP):
MSRP xx 200 OK
To:msrp://alicepc.atlanta.com:7777/iau39
From:msrp://bob.atlanta.com:8888/9di4ea
Tr-ID:sie09s
4. Bob->Alice (SIP): 200 OK
v=0 v=0
o=bob 2890844612 2890844616 IN IP4 host.anywhere.com o=bob 2890844612 2890844616 IN IP4 host.anywhere.com
s= s=
c=IN IP4 ignorefield c=IN IP4 ignorefield
t=0 0 t=0 0
m=message 9999 msrp/tcp * m=message 9999 msrp *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrp://bob.atlanta.com:8888/9di4ea a=path:msrp://bob.atlanta.com:8888/9di4ea
5. Alice->Bob (SIP): ACK 3. Alice->Bob (SIP): ACK
6. Alice->Bob (MSRP): 4. (Alice opens connection to Bob. This may occur in parallel with
the previous step.) Alice->Bob (MSRP):
MSRP xx SEND MSRP SEND
To:msrp://bob.atlanta.com:8888/9di4ea Boundary: d93kswow
From:msrp://alicepc.atlanta.com:7777/iau39 To-Path:msrp://bob.atlanta.com:8888/9di4ea
From-Path:msrp://alicepc.atlanta.com:7777/iau39
TR-ID: 123 TR-ID: 123
Message-ID: 123
Content-Type: "text/plain" Content-Type: "text/plain"
Hi, I'm Alice! Hi, I'm Alice!
-------d93kswow$
7. Bob->Alice (MSRP): 5. Bob->Alice (MSRP):
MSRP xx 200 OK MSRP 200 OK
To:msrp://bob.atlanta.com:8888/9di4ea Boundary: 839s9ed
From:msrp://alicepc.atlanta.com:7777/iau39 To-Path:msrp://bob.atlanta.com:8888/9di4ea
From-Path:msrp://alicepc.atlanta.com:7777/iau39
TR-ID: 123 TR-ID: 123
-------839s9ed$
8. Bob->Alice (MSRP): 6. Bob->Alice (MSRP):
MSRP xx SEND MSRP SEND
To:msrp://alice.atlanta.com:7777/iau39 Boundary: dkei38sd
From:msrp://bob.atlanta.com:8888/9di4ea To-Path:msrp://alice.atlanta.com:7777/iau39
From-Path:msrp://bob.atlanta.com:8888/9di4ea
TR-ID: 456 TR-ID: 456
Message-ID: 456
Content-Type: "text/plain" Content-Type: "text/plain"
Hi, Alice! I'm Bob! Hi, Alice! I'm Bob!
9. Alice->Bob (MSRP): -------dkei38sd$
MSRP xx 200 OK 7. Alice->Bob (MSRP):
To:msrp://alice.atlanta.com:7777/iau39
From:msrp://bob.atlanta.com:8888/9di4ea MSRP 200 OK
Boundary: diw3ids
To-Path:msrp://alice.atlanta.com:7777/iau39
From-Path:msrp://bob.atlanta.com:8888/9di4ea
TR-ID: 456 TR-ID: 456
-------diw3ids$
10. Alice->Bob (SIP): BYE 8. Alice->Bob (SIP): BYE
Alice invalidates local session state. Alice invalidates local session state.
11. Bob invalidates local state for the session. 9. Bob invalidates local state for the session.
Bob->Alice (SIP): 200 OK Bob->Alice (SIP): 200 OK
9. IANA Considerations 8. IANA Considerations
9.1 MSRP Port 8.1 MSRP Port
MSRP uses TCP port XYX, to be determined by IANA after this document MSRP uses TCP port XYX, to be determined by IANA after this document
is approved for publication. Usage of this value is described in is approved for publication. Usage of this value is described in
Section 7.1 Section 6.1
9.2 MSRP URL Schemes 8.2 MSRP URL Schema
This document defines the URL schemes of "msrp" and "msrps". This document defines the URL schema of "msrp" "msrps", "smsrp", and
"smsrps".
9.2.1 Syntax 8.2.1 Syntax
See Section 7.1. See Section 6.1.
9.2.2 Character Encoding 8.2.2 Character Encoding
See Section 7.1. See Section 6.1.
9.2.3 Intended Usage 8.2.3 Intended Usage
See Section 7.1. See Section 6.1.
9.2.4 Protocols 8.2.4 Protocols
The Message Session Relay Protocol (MSRP). The Message Session Relay Protocol (MSRP).
9.2.5 Security Considerations 8.2.5 Security Considerations
See Section 10. See Section 9.
9.2.6 Relevant Publications 8.2.6 Relevant Publications
RFCXXXX RFCXXXX
[Note to RFC Editor: Please replace RFCXXXX in the above paragraph [Note to RFC Editor: Please replace RFCXXXX in the above paragraph
with the actual number assigned to this document. with the actual number assigned to this document.
9.3 SDP Parameters 8.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 Accept Types 8.3.1 Accept Types
Attribute-name: accept-types Attribute-name: accept-types
Long-form Attribute Name Acceptable MIME Types Long-form Attribute Name Acceptable MIME Types
Type: Media level Type: Media level
Subject to Charset Attribute No Subject to Charset Attribute No
Purpose and Appropriate Values See Section 6.2. Purpose and Appropriate Values See Section 5.2.
9.3.2 Wrapped Types 8.3.2 Wrapped Types
Attribute-name: accept-wrapped-types Attribute-name: accept-wrapped-types
Long-form Attribute Name Acceptable MIME Types Inside Wrappers 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 5.3.
9.3.3 Path 8.3.3 Path
Attribute-name: path Attribute-name: path
Long-form Attribute Name MSRP URL Path Long-form Attribute Name MSRP URL Path
Type: Media level Type: Media level
Subject to Charset Attribute No Subject to Charset Attribute No
Purpose and Appropriate Values See Section 6.4. Purpose and Appropriate Values See Section 5.4.
10. Security Considerations 8.4 IANA registration forms for DSN types
8.4.1 IANA registration form for address-type
This document registers a new 'address-type' for use in conjunction
with RFC1894[10]. The authors request that these values be recorded
in the IANA registry for DSN 'address-type'.
Proposed Address name: msrp-address-type
Syntax: See Section 6.1
8.4.2 IANA registration form for MTA-name-type
This document registers a new 'MTA-name-type' for use in conjunction
with RFC1894[10]. The authors request that these values be recorded
in the IANA registry for DSN 'MTA-name-type'.
Proposed Address name: msrp-name-type
Syntax: See See Section 6.1
9. 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.
10.1 TLS and the MSRPS Scheme 9.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 start TLS request, the device ceases to watch for the not part of a start TLS request, the device ceases to watch for the
TLS handshake until it reads the entire message. Once the message has TLS handshake until it reads the entire message. Once the message
been completely received, the device resumes watching for the start has been completely received, the device resumes watching for the
TLS message. start TLS message.
Any MSRP device MAY refuse to accept a given request over a non-TLS Any MSRP device MAY refuse to accept a given request over a non-TLS
connection by returning a 426 response. connection by returning a 426 response.
MSRP devices acting in the role of TCP client MAY perform a TLS MSRP devices acting in the role of TCP client MAY perform a TLS
handshake at any time, as long as the request occurs between MSRP handshake at any time, as long as the request occurs between MSRP
messages. The endpoint MUST NOT send a start TLS request in the messages. The endpoint MUST NOT send a start TLS request in the
middle of an MSRP message. middle of an MSRP message.
The working group considered only requiring the endpoint to watch The working group considered only requiring the endpoint to watch
for a TLS handshake at the beginning of the session. However, the for a TLS handshake at the beginning of the session. However, the
endpoint should be able to determine if a new message is a start endpoint should be able to determine if a new message is a start
TLS request or an MSRP request by only reading ahead three bytes. TLS request or an MSRP request by only reading ahead three bytes.
Therefore, the working group chose to allow a session to switch to Therefore, the working group chose to allow a session to switch to
TLS in mid-stream, as long as the switch occurs between MRSP TLS in mid-stream, as long as the switch occurs between MRSP
messages. messages.
The MSRPS URI scheme indicates that all hops in an MSRP session MUST There have since been proposals that we only allow start-tls at
be protected with TLS. Since this document does not specify the use connection time. Do we have a consensus here one way or the
of intermidiary devices, then MSRPS support is trivially equivilant other?
to TLS support. However, if intermediaries do exist, either as
described in an MSRP extension document, or as some sort of
proprietary devices, they MUST ensure protection at all hops for an
MSRPS URL.
A VISIT request for an MSRPS URL MUST be sent over a TLS protected The "msrps" and "smsrps" URI schema indicates that the connection
connection. If a hosting device receives a VISIT request for an MSRPS MUST be protected with TLS.
URL over an unprotected connection, it MUST reject the request with a
426 response.
10.1.1 Sensitivity of the Session URL Relay handling of "msrps" and "smsrps" are beyond the scope of
this document. However, any relay specification MUST explicitly
specify this.
The URL sent in the SDP offer for a MSRP session is used by the MSRP requests for "msrps" URLs MUST be sent over TLS protected
answerer to identify itself to the hosting device. If an attacker connections. If a device receives a request for a "msrps" or
were able to acquire the session URL, either by guessing it or by "smsrps" URL over an unprotected connection, it MUST reject the
request with a 426 response.
9.1.1 Sensitivity of Session URLs
The URLs sent in the SDP offer/answer exchange for a MSRP session are
used by the endpoints to identify each other. If an attacker were
able to acquire the session URL, either by guessing it or by
eavesdropping, there is a window of opportunity in which the attacker eavesdropping, there is a window of opportunity in which the attacker
could hijack the session by sending a VISIT request to the host could hijack the session connecting and sending a MSRP request to the
device before the true visiting endpoint. Because of this listening device before the legitimate peer. Because of this
sensitivity, the session URL SHOULD be constructed in a way to make sensitivity, these URLs SHOULD be constructed in a way to make them
it difficult to guess, and should be sufficiently random so that it difficult to guess, and should be sufficiently random so that it is
is unlikely to be reused. All mechanisms used to transport this URL unlikely to be reused. All mechanisms used to transport these URLs
to the answerer SHOULD be protected from eavesdroppers and SHOULD be protected from eavesdroppers and man-in-the-middle attacks.
man-in-the-middle attacks.
Therefore a MSRP device MUST support the use of TLS for at least the Therefore a MSRP device MUST support the use of TLS for all MSRP
VISIT request, which by extension indicates the endpoint MUST support messages. Further, MSRP connections SHOULD actually be protected
the use of TLS for all MSRP messages. Further, MSRP connections with TLS. Further, an MSRP endpoint MUST be capable of using the
SHOULD actually be protected with TLS. Further, an MSRP endpoint MUST security features of the signaling protocol in order to protect the
be capable of using the security features of the signaling protocol SDP exchange and SHOULD actually use them on all such exchanges.
in order to protect the SDP exchange and SHOULD actually use them on End-to-end protection schemes SHOULD be preferred over hop-by-hop
all such exchanges. End-to-end protection schemes SHOULD be preferred schemes for protection of the SDP exchange.
over hop-by-hop schemes for protection of the SDP exchange.
10.1.2 End to End Protection of IMs 9.1.2 End to End Protection of IMs
Instant messages can contain very sensitive information. As a result, Instant messages can contain very sensitive information. As a
as specified in RFC 2779 [3], instant messaging protocols need to result, as specified in RFC 2779 [3], instant messaging protocols
provide for encryption, integrity and authentication of instant need to provide for encryption, integrity and authentication of
messages. Therefore MSRP endpoints MUST support the end-to-end instant messages. Therefore MSRP endpoints MUST support the
encryption and integrity of bodies sent via SEND requests using end-to-end encryption and integrity of bodies sent via SEND requests
Secure MIME (S/MIME) [7]. using Secure MIME (S/MIME) [7].
Note that while each protected body could use separate keying Note that while each protected body could use separate keying
material, this is inefficient in that it requires an independent material, this is inefficient in that it requires an independent
public key operation for each message. Endpoints wishing to invoke public key operation for each message. Endpoints wishing to invoke
end-to-end protection of message sessions SHOULD exchange symmetric end-to-end protection of message sessions SHOULD exchange symmetric
keys in SDP k-lines, and use secret key encryption on for each MSRP keys in SDP k-lines, and use secret key encryption on for each MSRP
message. When symmetric keys are present in the SDP, the offer-answer message. When symmetric keys are present in the SDP, the
exchange MUST be protected from eavesdropping and tampering using the offer-answer exchange MUST be protected from eavesdropping and
appropriate facilities of the signaling protocol. For example, if the tampering using the appropriate facilities of the signaling protocol.
signaling protocol is SIP, the SDP exchange MUST be protected using For example, if the signaling protocol is SIP, the SDP exchange MUST
S/MIME. be protected using S/MIME.
10.1.3 CPIM compatibility 9.1.3 CPIM compatibility
MSRP sessions may be gatewayed to other CPIM [19]compatible MSRP sessions may be gatewayed to other CPIM [19]compatible
protocols. If this occurs, the gateway MUST maintain session state, protocols. If this occurs, the gateway MUST maintain session state,
and MUST translate between the MSRP session semantics and CPIM and MUST translate between the MSRP session semantics and CPIM
semantics that do not include a concept of sessions. Furthermore, semantics that do not include a concept of sessions. Furthermore,
when one endpoint of the session is a CPIM gateway, instant messages when one endpoint of the session is a CPIM gateway, instant messages
SHOULD be wrapped in "message/cpim" [5] bodies. Such a gateway MUST SHOULD be wrapped in "message/cpim" [5] bodies. Such a gateway MUST
include "message/cpim" as the first entry in its SDP accept-types include "message/cpim" as the first entry in its SDP accept-types
attribute. MSRP endpoints sending instant messages to a peer that has attribute. MSRP endpoints sending instant messages to a peer that
included 'message/cpim" as the first entry in the accept-types has included 'message/cpim" as the first entry in the accept-types
attribute SHOULD encapsulate all instant message bodies in "message/ attribute SHOULD encapsulate all instant message bodies in "message/
cpim" wrappers. All MSRP endpoints MUST support the message/cpim cpim" wrappers. All MSRP endpoints MUST support the message/cpim
type, and SHOULD support the S/MIME features of that format. type, and SHOULD support the S/MIME features of that format.
10.1.4 PKI Considerations 9.1.4 PKI Considerations
Several aspects of MSRP will benefit from being used in the context Several aspects of MSRP will benefit from being used in the context
of a public key infrastructure. For example, the MSRPS scheme allows, of a public key infrastructure. For example, the MSRPS scheme
and even encourages, TLS connections between endpoint devices. And allows, and even encourages, TLS connections between endpoint
while MSRP allows for a symmetric session key to protect all messages devices. And while MSRP allows for a symmetric session key to
in a session, it is most likely that session key itself would be protect all messages in a session, it is most likely that session key
exchanged in a signaling protocol such as SIP. Since that key is itself would be exchanged in a signaling protocol such as SIP. Since
extremely sensitive, its exchange would also need to be protected. In that key is extremely sensitive, its exchange would also need to be
SIP, the preferred mechanism for this would be S/MIME, which would protected. In SIP, the preferred mechanism for this would be S/MIME,
also benefit from a PKI. which would also benefit from a PKI.
However, all of these features may be used without PKI. Each endpoint However, all of these features may be used without PKI. Each
could instead use self signed certificates. This will, of course, be endpoint could instead use self signed certificates. This will, of
less convenient than with a PKI, in that there would be no course, be less convenient than with a PKI, in that there would be no
certificate authority to act as a trusted introducer. Peers would be certificate authority to act as a trusted introducer. Peers would be
required to exchange certificates prior to securely communicating. required to exchange certificates prior to securely communicating.
Since, at least for the immediate future, any given MSRP Since, at least for the immediate future, any given MSRP
implementation is likely to communicate with at least some peers that implementation is likely to communicate with at least some peers that
do not have a PKI available, MSRP implementations SHOULD support the do not have a PKI available, MSRP implementations SHOULD support the
use of self-signed certificates, and SHOULD support the ability to use of self-signed certificates, and SHOULD support the ability to
configure lists of trusted certificates. configure lists of trusted certificates.
To Do: Add text discussion the use of TLS certificates in more To Do: Add text discussion the use of TLS certificates in more
detail. detail.
11. Changes from Previous Draft Versions 10. 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-04 10.1 draft-ietf-simple-message-sessions-06
Changed To and From header names to To-Path and From-Path. Added
more clarification to path handling, and commentary on how it
enables relay usage.
Changed mechanism for signaling transport and TLS protection into
the MSRP URL, rather than the SDP M-Line.
Removed length field from start line and added Boundary header
field and Closing field.
Added recommendation to fragment any content over 2k.
Added Rohan's proposal to make offerer connect to answerer. (With
open issue for more discussion.)
Changed To-Path and From-Path usage in responses to indicate the
destination and source of the response, rather than merely copy
from the associated request.
Updated DSN section. Added text on field usage.
Fixed change section--changes from version 05 were erroneously
attributed to 04.
10.2 draft-ietf-simple-message-sessions-05
Removed the direction attribute. Rather than using a comedia
styled direction negotiation, we just state that the answerer
opens any needed connection.
Changed the use of session URLs. Instead of a single session URL, Changed the use of session URLs. Instead of a single session URL,
each endpoint is identified by a distinct URL. MSRP requests will each endpoint is identified by a distinct URL. MSRP requests will
put the destination URL in a To header, and the sender URL in a put the destination URL in a To header, and the sender URL in a
From header. From header.
Changed the SDP exchange of MSRP URLs to handle the URL for each Changed the SDP exchange of MSRP URLs to handle the URL for each
endpoint. Further, changed the SDP attribute to support a list of endpoint. Further, changed the SDP attribute to support a list of
URLs in each direction. This may be used with relays to exchange URLs in each direction. This may be used with relays to exchange
paths, rather than single URLs. MSRP endpoints must be able to paths, rather than single URLs. MSRP endpoints must be able to
intelligently process such a list if received. This document does intelligently process such a list if received. This document does
not, however, describe how to generate such a list. not, however, describe how to generate such a list.
Added section for Delivery Status Notification handling, and added Added section for Delivery Status Notification handling, and added
associated entries into the syntax definition. associated entries into the syntax definition.
Added content fragmentation section. Added content fragmentation section.
Removed recommendation to start separate session for large Removed recommendation to start separate session for large
transfers. transfers.
Corrected some mistakes in the syntax definitions. Corrected some mistakes in the syntax definitions.
Added Chris Boulton as a co-author for his contribution of the DSN Added Chris Boulton as a co-author for his contribution of the DSN
text. text.
11.2 draft-ietf-simple-message-sessions-03 10.3 draft-ietf-simple-message-sessions-04
Removed the direction attribute. Rather than using a comedia
styled direction negotiation, we just state that the answerer
opens any needed connection.
10.4 draft-ietf-simple-message-sessions-03
Removed all specification of relays, and all features specific to Removed all specification of relays, and all features specific to
the use of relays. The working group has chosen to move relay work the use of relays. The working group has chosen to move relay
into a separate effort, in order to advance the base work into a separate effort, in order to advance the base
specification. (The MSRP acronym is unchanged for the sake of specification. (The MSRP acronym is unchanged for the sake of
convenience.) This included removal of the BIND method, all convenience.) This included removal of the BIND method, all
response codes specific to BIND, Digest Authentication, and the response codes specific to BIND, Digest Authentication, and the
inactivity timeout. inactivity timeout.
Removed text indicating that an endpoint could retry failed Removed text indicating that an endpoint could retry failed
requests on the same connection. Rather, the endpoint should requests on the same connection. Rather, the endpoint should
consider the connection dead, and either signal a reconnection or consider the connection dead, and either signal a reconnection or
end the session. end the session.
Added text describing subsequent SDP exchanges. Added mandatory Added text describing subsequent SDP exchanges. Added mandatory
"count" parameter to the direction attribute to allow explicit "count" parameter to the direction attribute to allow explicit
signaling of the need to reconnect. signaling of the need to reconnect.
Added text to describe the use of send and receive only indicators Added text to describe the use of send and receive only indicators
in SDP for one-way transfer of large content. in SDP for one-way transfer of large content.
Added text requiring unique port field values if multiple M-line's Added text requiring unique port field values if multiple M-line's
exist. exist.
Corrected a number of editorial mistakes. Corrected a number of editorial mistakes.
11.3 draft-ietf-simple-message-sessions-02 10.5 draft-ietf-simple-message-sessions-02
Moved all content type negotiation from the "m"-line format list Moved all content type negotiation from the "m"-line format list
into "a"-line attributes. Added the accept-types attribute. This into "a"-line attributes. Added the accept-types attribute. This
is due to the fact that the sdp format-list syntax is not is due to the fact that the sdp format-list syntax is not
conducive to encoding MIME content types values. conducive to encoding MIME content types values.
Added "other-method" construction to the message syntax to allow Added "other-method" construction to the message syntax to allow
for extensible methods. for extensible methods.
Consolidated all syntax definitions into the same section. Cleaned Consolidated all syntax definitions into the same section.
up ABNF for digest challenge and response syntax. Cleaned up ABNF for digest challenge and response syntax.
Changed the session inactivity timeout to 12 minutes. Changed the session inactivity timeout to 12 minutes.
Required support for the SHA1 alogorithm. Required support for the SHA1 alogorithm.
Required support for the message/cpim format. Required support for the message/cpim format.
Fixed lots of editorial issues. Fixed lots of editorial issues.
Documented a number of open issues from recent list discussions. Documented a number of open issues from recent list discussions.
11.4 draft-ietf-simple-message-sessions-01 10.6 draft-ietf-simple-message-sessions-01
Abstract rewritten. Abstract rewritten.
Added architectural considerations section. Added architectural considerations section.
The m-line format list now only describes the root body part for a The m-line format list now only describes the root body part for a
request. Contained body part types may be described in the request. Contained body part types may be described in the
"accept-wrapped-types" a-line attribute. "accept-wrapped-types" a-line attribute.
Added a standard dummy value for the m-line port field. Clarified Added a standard dummy value for the m-line port field. Clarified
that a zero in this field has normal SDP meaning. that a zero in this field has normal SDP meaning.
Clarified that an endpoint is globally configured as to whether or Clarified that an endpoint is globally configured as to whether or
not to use a relay. There is no relay discovery mechanism not to use a relay. There is no relay discovery mechanism
intrinsic to MSRP. intrinsic to MSRP.
skipping to change at page 36, line 25 skipping to change at page 41, line 38
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.5 draft-ietf-simple-message-sessions-00 10.7 draft-ietf-simple-message-sessions-00
Name changed to reflect status as a work group item. Name changed to reflect status as a work group item.
This version no longer supports the use of multiple sessions This version no longer supports the use of multiple sessions
across a single TCP session. This has several related changes: across a single TCP session. This has several related changes:
There is now a single session URI, rather than a separate one for There is now a single session URI, rather than a separate one for
each endpoint. The session URI is not required to be in requests each endpoint. The session URI is not required to be in requests
other than BIND and VISIT, as the session can be determined based other than BIND and VISIT, as the session can be determined based
on the connection on which it arrives. on the connection on which it arrives.
BIND and VISIT now create soft state, eliminating the need for the BIND and VISIT now create soft state, eliminating the need for the
RELEASE and LEAVE methods. RELEASE and LEAVE methods.
skipping to change at page 36, line 39 skipping to change at page 42, line 4
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
k-lines in SDP, where the SDP exchange is protected end-to-end of k-lines in SDP, where the SDP exchange is protected end-to-end
seems sufficient. seems sufficient.
11.6 draft-campbell-simple-im-sessions-01 10.8 draft-campbell-simple-im-sessions-01
Version 01 is a significant re-write. References to COMEDIA were Version 01 is a significant re-write. References to COMEDIA were
removed, as it was determined that COMEDIA would not allow removed, as it was determined that COMEDIA would not allow
connections to be used bidirectional in the presence of NATs. connections to be used bidirectional in the presence of NATs.
Significantly more discussion of a concrete mechanism has been added Significantly more discussion of a concrete mechanism has been added
to make up for no longer using COMEDIA. Additionally, this draft and to make up for no longer using COMEDIA. Additionally, this draft and
draft-campbell-cpimmsg-sessions (which would have also changed draft-campbell-cpimmsg-sessions (which would have also changed
drastically) have now been combined into this single draft. drastically) have now been combined into this single draft.
12. Contributors 11. Contributors
The following people contributed substantially to this ongoing In addition to the editor, The following people contributed extensive
effort: work to this document:
Rohan Mahy Allison Mankin Jon Peterson Brian Rosen Dean Willis Adam Roach
Cullen Jennings Aki Niemi Hisham Khartabil Pekka Pessi Chris Boulton
Normative References Chris Boulton
Cullen Jennings
Paul Kyzivat
Rohan Mahy
Adam Roach
Jonathan Rosenberg
Robert Sparks
12. Acknowledgments
The following people contributed substantial discussion and feedback
to this ongoing effort:
Allison Mankin Jon Peterson Brian Rosen Dean Willis
Aki Niemi Hisham Khartabil Pekka Pessi Orit Levin
13. References
13.1 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.
[3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / [3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
Presence Protocol Requirements", RFC 2779, February 2000. Presence Protocol Requirements", RFC 2779, February 2000.
skipping to change at page 38, line 13 skipping to change at page 43, line 40
[9] Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 [9] Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001. (SHA1)", RFC 3174, September 2001.
[10] Moore, K. and G. Vaudreuil, "An Extensible Message Format for [10] Moore, K. and G. Vaudreuil, "An Extensible Message Format for
Delivery Status Notifications", RFC 1894, January 1996. Delivery Status Notifications", RFC 1894, January 1996.
[11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., [11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
Informational References 13.2 Informational References
[12] Campbell, B. and J. Rosenberg, "Session Initiation Protocol [12] Campbell, B. and J. Rosenberg, "Session Initiation Protocol
Extension for Instant Messaging", RFC 3428, September 2002. Extension for Instant Messaging", RFC 3428, September 2002.
[13] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, [13] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC "RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996. 1889, January 1996.
[14] Mahy, R., Campbell, B., Sparks, R., Rosenberg, J., Petrie, D. [14] 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",
skipping to change at page 39, line 5 skipping to change at page 44, line 28
[18] Peterson, J., "A Privacy Mechanism for the Session Initiation [18] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323 , November 2002. Protocol (SIP)", RFC 3323 , November 2002.
[19] Peterson, J., "A Common Profile for Instant Messaging (CPIM)", [19] Peterson, J., "A Common Profile for Instant Messaging (CPIM)",
draft-ietf-impp-im-04 (work in progress), August 2003. draft-ietf-impp-im-04 (work in progress), August 2003.
[20] Yon, D., "Connection-Oriented Media Transport in SDP", [20] 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.
Authors' Addresses Author's Address
Ben Campbell Ben Campbell
dynamicsoft dynamicsoft
5100 Tennyson Parkway 5100 Tennyson Parkway
Suite 1200 Suite 1200
Plano, TX 75024 Plano, TX 75024
EMail: bcampbell@dynamicsoft.com EMail: bcampbell@dynamicsoft.com
Jonathan Rosenberg
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ 07054
EMail: jdrosen@dynamicsoft.com
Robert Sparks
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75024
EMail: rsparks@dynamicsoft.com
Paul Kyzivat
Cisco Systems
Mail Stop LWL3/12/2
900 Chelmsford St.
Lowell, MA 01851
EMail: pkyzivat@cisco.com
Chris Boulton
Ubiquity Software Corporation
Langstone Park
Newport, South Wales NP18 2LH
EMail: cboulton@ubiquity.net
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
 End of changes. 

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