draft-ietf-simple-message-sessions-13.txt   draft-ietf-simple-message-sessions-14.txt 
SIMPLE WG B. Campbell, Ed. Network Working Group B. Campbell, Ed.
Internet-Draft Estacado Systems Internet-Draft Estacado Systems
Expires: June 24, 2006 R. Mahy, Ed. Expires: August 29, 2006 R. Mahy, Ed.
SIP Edge, LLC SIP Edge, LLC
C. Jennings, Ed. C. Jennings, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
December 21, 2005 February 25, 2006
The Message Session Relay Protocol The Message Session Relay Protocol
draft-ietf-simple-message-sessions-13.txt draft-ietf-simple-message-sessions-14
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 The list of current Internet-Drafts can be accessed at
http://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 June 24, 2006. This Internet-Draft will expire on August 29, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes the Message Session Relay Protocol, a This document describes the Message Session Relay Protocol, a
protocol for transmitting a series of related instant messages in the protocol for transmitting a series of related instant messages in the
context of a session. Message sessions are treated like any other context of a session. Message sessions are treated like any other
media stream when set up via a rendezvous or session set up protocol media stream when set up via a rendezvous or session creation
such as the Session Initiation Protocol. protocol such as the Session Initiation Protocol.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability of MSRP . . . . . . . . . . . . . . . . . . . . 5 3. Applicability of MSRP . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
5. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. MSRP Framing and Message Chunking . . . . . . . . . . . . 9 5.1. MSRP Framing and Message Chunking . . . . . . . . . . . . 9
5.2. MSRP Addressing . . . . . . . . . . . . . . . . . . . . . 10 5.2. MSRP Addressing . . . . . . . . . . . . . . . . . . . . . 10
5.3. MSRP Transaction and Report Model . . . . . . . . . . . . 10 5.3. MSRP Transaction and Report Model . . . . . . . . . . . . 10
5.4. MSRP Connection Model . . . . . . . . . . . . . . . . . . 12 5.4. MSRP Connection Model . . . . . . . . . . . . . . . . . . 12
6. MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 15 6.1. MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 15
6.2. Resolving MSRP Host Device . . . . . . . . . . . . . . . 15 6.2. Resolving MSRP Host Device . . . . . . . . . . . . . . . 15
7. Method-Specific Behavior . . . . . . . . . . . . . . . . . . . 16 7. Method-Specific Behavior . . . . . . . . . . . . . . . . . . . 16
7.1. Constructing Requests . . . . . . . . . . . . . . . . . . 16 7.1. Constructing Requests . . . . . . . . . . . . . . . . . . 16
7.1.1. Sending SEND Requests . . . . . . . . . . . . . . . . 18 7.1.1. Sending SEND Requests . . . . . . . . . . . . . . . . 18
7.1.2. Sending REPORT Requests . . . . . . . . . . . . . . . 20 7.1.2. Sending REPORT Requests . . . . . . . . . . . . . . . 20
7.1.3. Generate Failure REPORTs . . . . . . . . . . . . . . . 21 7.1.3. Generating Success Reports . . . . . . . . . . . . . . 21
7.1.4. Generating Failure Reports . . . . . . . . . . . . . . 21
7.2. Constructing Responses . . . . . . . . . . . . . . . . . 22 7.2. Constructing Responses . . . . . . . . . . . . . . . . . 22
7.3. Receiving Requests . . . . . . . . . . . . . . . . . . . 23 7.3. Receiving Requests . . . . . . . . . . . . . . . . . . . 23
7.3.1. Receiving SEND Requests . . . . . . . . . . . . . . . 23 7.3.1. Receiving SEND Requests . . . . . . . . . . . . . . . 23
7.3.2. Receiving REPORT Requests . . . . . . . . . . . . . . 25 7.3.2. Receiving REPORT Requests . . . . . . . . . . . . . . 25
8. Using MSRP with SIP and SDP . . . . . . . . . . . . . . . . . 26 8. Using MSRP with SIP and SDP . . . . . . . . . . . . . . . . . 26
8.1. SDP Connection and Media Lines . . . . . . . . . . . . . 27 8.1. SDP Connection and Media Lines . . . . . . . . . . . . . 27
8.2. URL Negotiations . . . . . . . . . . . . . . . . . . . . 27 8.2. URL Negotiations . . . . . . . . . . . . . . . . . . . . 27
8.3. Path Attributes with Multiple URLs . . . . . . . . . . . 28 8.3. Path Attributes with Multiple URLs . . . . . . . . . . . 28
8.4. Updated SDP Offers . . . . . . . . . . . . . . . . . . . 29 8.4. Updated SDP Offers . . . . . . . . . . . . . . . . . . . 29
8.5. Connection Negotiation . . . . . . . . . . . . . . . . . 30 8.5. Connection Negotiation . . . . . . . . . . . . . . . . . 30
8.6. Content Type Negotiation . . . . . . . . . . . . . . . . 30 8.6. Content Type Negotiation . . . . . . . . . . . . . . . . 30
8.7. Example SDP Exchange . . . . . . . . . . . . . . . . . . 32 8.7. Example SDP Exchange . . . . . . . . . . . . . . . . . . 32
8.8. MSRP User Experience with SIP . . . . . . . . . . . . . . 32 8.8. MSRP User Experience with SIP . . . . . . . . . . . . . . 32
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 33 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 33
10. Response Code Descriptions . . . . . . . . . . . . . . . . . . 35 10. Response Code Descriptions . . . . . . . . . . . . . . . . . . 35
10.1. 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.1. 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.2. 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.2. 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.3. 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.3. 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.4. 408 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.4. 408 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.5. 413 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.5. 413 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.6. 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.6. 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.7. 423 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.7. 423 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.8. 426 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.8. 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.9. 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.9. 501 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.10. 501 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.10. 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.11. 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
11.1. Basic IM Session . . . . . . . . . . . . . . . . . . . . 37 11.1. Basic IM Session . . . . . . . . . . . . . . . . . . . . 37
11.2. Message with XHTML Content . . . . . . . . . . . . . . . 40 11.2. Message with XHTML Content . . . . . . . . . . . . . . . 40
11.3. Chunked Message . . . . . . . . . . . . . . . . . . . . . 40 11.3. Chunked Message . . . . . . . . . . . . . . . . . . . . . 40
11.4. System Message . . . . . . . . . . . . . . . . . . . . . 40 11.4. System Message . . . . . . . . . . . . . . . . . . . . . 40
11.5. Positive Report . . . . . . . . . . . . . . . . . . . . . 41 11.5. Positive Report . . . . . . . . . . . . . . . . . . . . . 41
11.6. Forked IM . . . . . . . . . . . . . . . . . . . . . . . . 41 11.6. Forked IM . . . . . . . . . . . . . . . . . . . . . . . . 41
12. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 44 12. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 45
13. CPIM Compatibility . . . . . . . . . . . . . . . . . . . . . . 44 13. CPIM Compatibility . . . . . . . . . . . . . . . . . . . . . . 45
14. Security Considerations . . . . . . . . . . . . . . . . . . . 45 14. Security Considerations . . . . . . . . . . . . . . . . . . . 46
14.1. Transport Level Protection . . . . . . . . . . . . . . . 45 14.1. Transport Level Protection . . . . . . . . . . . . . . . 46
14.2. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . 47 14.2. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . 48
14.3. Using TLS in Peer to Peer Mode . . . . . . . . . . . . . 47 14.3. Using TLS in Peer to Peer Mode . . . . . . . . . . . . . 48
14.4. Other Security Concerns . . . . . . . . . . . . . . . . . 49 14.4. Other Security Concerns . . . . . . . . . . . . . . . . . 50
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
15.1. MSRP Method Names . . . . . . . . . . . . . . . . . . . . 51 15.1. MSRP Method Names . . . . . . . . . . . . . . . . . . . . 52
15.2. MSRP Header Fields . . . . . . . . . . . . . . . . . . . 51 15.2. MSRP Header Fields . . . . . . . . . . . . . . . . . . . 52
15.3. MSRP Status Codes . . . . . . . . . . . . . . . . . . . . 51 15.3. MSRP Status Codes . . . . . . . . . . . . . . . . . . . . 52
15.4. MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 52 15.4. MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 53
15.5. MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . 52 15.5. MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . 53
15.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . 52 15.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . 53
15.7. SDP Attribute Names . . . . . . . . . . . . . . . . . . . 52 15.7. SDP Attribute Names . . . . . . . . . . . . . . . . . . . 53
15.7.1. Accept Types . . . . . . . . . . . . . . . . . . . . . 52 15.7.1. Accept Types . . . . . . . . . . . . . . . . . . . . . 53
15.7.2. Wrapped Types . . . . . . . . . . . . . . . . . . . . 53 15.7.2. Wrapped Types . . . . . . . . . . . . . . . . . . . . 54
15.7.3. Max Size . . . . . . . . . . . . . . . . . . . . . . . 53 15.7.3. Max Size . . . . . . . . . . . . . . . . . . . . . . . 54
15.7.4. Path . . . . . . . . . . . . . . . . . . . . . . . . . 53 15.7.4. Path . . . . . . . . . . . . . . . . . . . . . . . . . 54
16. Contributors and Acknowledgments . . . . . . . . . . . . . . . 53 16. Contributors and Acknowledgments . . . . . . . . . . . . . . . 54
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
17.1. Normative References . . . . . . . . . . . . . . . . . . 54 17.1. Normative References . . . . . . . . . . . . . . . . . . 55
17.2. Informational References . . . . . . . . . . . . . . . . 55 17.2. Informational References . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58
Intellectual Property and Copyright Statements . . . . . . . . . . 58 Intellectual Property and Copyright Statements . . . . . . . . . . 59
1. Introduction 1. Introduction
A series of related instant messages between two or more parties can A series of related instant messages between two or more parties can
be viewed as part of a "message session", that is, a conversational be viewed as part of a "message session", that is, a conversational
exchange of messages with a definite beginning and end. This is in exchange of messages with a definite beginning and end. This is in
contrast to individual messages each sent independently. Messaging contrast to individual messages each sent independently. Messaging
schemes that track only individual messages can be described as schemes that track only individual messages can be described as
"page-mode" messaging, whereas messaging that is part of a "session" "page-mode" messaging, whereas messaging that is part of a "session"
with a definite start and end is called "session-mode" messaging. with a definite start and end is called "session-mode" messaging.
Page-mode messaging is enabled in SIP via the SIP [4] MESSAGE method Page-mode messaging is enabled in SIP via the SIP [4] MESSAGE method
[21]. Session-mode messaging has a number of benefits [22] over [21]. Session-mode messaging has a number of benefits over page-mode
page-mode messaging, however, such as explicit rendezvous, tighter messaging, however, such as explicit rendezvous, tighter integration
integration with other media types, direct client-to-client with other media types, direct client-to-client operation, and
operation, and brokered privacy and security. brokered privacy and security.
This document defines a session-oriented instant message transport This document defines a session-oriented instant message transport
protocol called the Message Session Relay Protocol (MSRP), whose protocol called the Message Session Relay Protocol (MSRP), whose
sessions can be negotiated with an offer or answer [3] using the sessions can be negotiated with an offer or answer [3] using the
Session Description Protocol(SDP [2]). The exchange is carried by Session Description Protocol(SDP [2]). The exchange is carried by
some signaling protocol, such as the Session Initiation Protocol (SIP some signaling protocol, such as the Session Initiation Protocol (SIP
[4]). This allows a communication user agent to offer a messaging [4]). This allows a communication user agent to offer a messaging
session as one of the possible media types in a session. For session as one of the possible media types in a session. For
instance, Alice may want to communicate with Bob. Alice doesn't know instance, Alice may want to communicate with Bob. Alice doesn't know
at the moment whether Bob has his phone or his IM client handy, but at the moment whether Bob has his phone or his IM client handy, but
she's willing to use either. She sends an invitation to a session to she's willing to use either. She sends an invitation to a session to
the address of record she has for Bob, sip:bob@example.com. Her the address of record she has for Bob, sip:bob@example.com. Her
invitation offers both voice and an IM session. The SIP services at invitation offers both voice and an IM session. The SIP services at
example.com forward the invitation to Bob at his currently registered example.com forward the invitation to Bob at his currently registered
clients. Bob accepts the invitation at his IM client and they begin clients. Bob accepts the invitation at his IM client and they begin
a threaded chat conversation. a threaded chat conversation.
When a user uses an IM URL, RFC 3861 [32] defines how DNS can be used When a user uses an IM URL, RFC 3861 [31] defines how DNS can be used
to map this to a particular protocol to establish the session such as to map this to a particular protocol to establish the session such as
SIP. SIP can use an offer answer model to transport the MSRP URLs SIP. SIP can use an offer answer model to transport the MSRP URLs
for the media in SDP. This document defines how the offer/answer for the media in SDP. This document defines how the offer/answer
exchange works to establish MSRP connections and how messages are exchange works to establish MSRP connections and how messages are
sent across the MSRP protocol, but it does not deal with the issues sent across the MSRP protocol, but it does not deal with the issues
of mapping an IM URL to a session establishment protocol. of mapping an IM URL to a session establishment protocol.
This session model allows message sessions to be integrated into This session model allows message sessions to be integrated into
advanced communications applications with little to no additional advanced communications applications with little to no additional
protocol development. For example, during the above chat session, protocol development. For example, during the above chat session,
Bob decides Alice really needs to be talking to Carol. Bob can Bob decides Alice really needs to be talking to Carol. Bob can
transfer [20] Alice to Carol, introducing them into their own transfer [20] Alice to Carol, introducing them into their own
messaging session. Messaging sessions can then be easily integrated messaging session. Messaging sessions can then be easily integrated
into call-center and dispatch environments using third-party call into call-center and dispatch environments using third-party call
control [19] and conferencing [18] applications. control [19] and conferencing [18] applications.
This document specifies MSRP behavior only for peer-to-peer sessions, This document specifies MSRP behavior only for peer-to-peer sessions,
that is, sessions crossing only a single hop. However, work to that is, sessions crossing only a single hop. MSRP relay devices
specify behavior for MSRP relay devices [23] (referred to herein as [22] (referred to herein as "relays") are specified in a separate
"relays") is occurring as a separate effort. document.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [5]. document are to be interpreted as described in RFC-2119 [5].
This document consistently refers to a "message" as a complete unit This document consistently refers to a "message" as a complete unit
of MIME or text content. In some cases, a message is split and of MIME or text content. In some cases, a message is split and
delivered in more than one MSRP request. Each of these portions of delivered in more than one MSRP request. Each of these portions of
skipping to change at page 5, line 38 skipping to change at page 5, line 38
with an MSRP session to each of the participating endpoints. The with an MSRP session to each of the participating endpoints. The
rendezvous mechanism MUST implement mechanisms to provide these rendezvous mechanism MUST implement mechanisms to provide these
URLs securely - they MUST NOT be made available to an untrusted URLs securely - they MUST NOT be made available to an untrusted
third party or be easily discoverable. third party or be easily discoverable.
The rendezvous mechanism MUST provide mechanisms for the The rendezvous mechanism MUST provide mechanisms for the
negotiation of any supported MSRP extensions that are not negotiation of any supported MSRP extensions that are not
backwards compatible. backwards compatible.
The rendezvous mechanism MUST be able to natively transport im: The rendezvous mechanism MUST be able to natively transport im:
URIs or automatically translate im: URIs [27] into the addressing URIs or automatically translate im: URIs [26] into the addressing
identifiers of the rendezvous protocol. identifiers of the rendezvous protocol.
To use a rendezvous mechanism with MSRP, an RFC must be prepared To use a rendezvous mechanism with MSRP, an RFC must be prepared
describing how it exchanges MSRP URLs and meets these requirements describing how it exchanges MSRP URLs and meets these requirements
listed here. This document provides such a description for the use listed here. This document provides such a description for the use
of MSRP in the context of SIP and SDP. of MSRP in the context of SIP and SDP.
SIP meets these requirements for a rendezvous mechanism. The MSRP SIP meets these requirements for a rendezvous mechanism. The MSRP
URLs are exchanged using SDP in an offer/answer exchange via SIP. URLs are exchanged using SDP in an offer/answer exchange via SIP.
The exchanged SDP can also be used to negotiate MSRP extensions. The exchanged SDP can also be used to negotiate MSRP extensions.
skipping to change at page 8, line 29 skipping to change at page 8, line 29
-------a786hjs2$ -------a786hjs2$
Alice's request begins with the MSRP start line, which contains a Alice's request begins with the MSRP start line, which contains a
transaction identifier that is also used for request framing. Next transaction identifier that is also used for request framing. Next
she includes the path of URLs to the destination in the To-Path she includes the path of URLs to the destination in the To-Path
header field, and her own URL in the From-Path header field. In this header field, and her own URL in the From-Path header field. In this
typical case there is just one "hop", so there is only one URL in typical case there is just one "hop", so there is only one URL in
each path header field. She also includes a message ID which she can each path header field. She also includes a message ID which she can
use to correlate status reports with the original message. Next she use to correlate status reports with the original message. Next she
puts the actual content. Finally she closes the request with an end- puts the actual content. Finally she closes the request with an end-
line seven hyphens, the transaction identifier and a "$" to indicate line of seven hyphens, the transaction identifier and a "$" to
this request contains the end of a complete message. indicate this request contains the end of a complete message.
If Alice wants to deliver a very large message, she can split the If Alice wants to deliver a very large message, she can split the
message into chunks and deliver each chunk in a separate SEND message into chunks and deliver each chunk in a separate SEND
request. The message ID corresponds to the whole message, so the request. The message ID corresponds to the whole message, so the
receiver can also use it to reassemble the message and tell which receiver can also use it to reassemble the message and tell which
chunks belong with which message. Chunking is described in more chunks belong with which message. Chunking is described in more
detail in Section 5.1. The Byte-Range header field identifies the detail in Section 5.1. The Byte-Range header field identifies the
portion of the message carried in this chunk and the total size of portion of the message carried in this chunk and the total size of
the message. the message.
skipping to change at page 10, line 39 skipping to change at page 10, line 39
features of TCP. features of TCP.
The chunking mechanism only applies to the SEND method, as it is the The chunking mechanism only applies to the SEND method, as it is the
only method used to transfer message content. only method used to transfer message content.
5.2. MSRP Addressing 5.2. MSRP Addressing
MSRP entities are addressed using URLs. The MSRP URL schemes are MSRP entities are addressed using URLs. The MSRP URL schemes are
defined in Section 6. The syntax of the To-Path and From-Path header defined in Section 6. The syntax of the To-Path and From-Path header
fields each allow for a list of URLs. This was done to allow the fields each allow for a list of URLs. This was done to allow the
protocol to work with gateways or relays defined in the future, to protocol to work with relays, which are defined in a separate
provide a complete path to the end recipient. When two MSRP nodes document, to provide a complete path to the end recipient. When two
communicate directly they need only one URL in the To-Path list and MSRP nodes communicate directly they need only one URL in the To-Path
one URL in the From-Path list. list and one URL in the From-Path list.
5.3. MSRP Transaction and Report Model 5.3. MSRP Transaction and Report Model
A sender sends MSRP requests to a receiver. The receiver MUST A sender sends MSRP requests to a receiver. The receiver MUST
quickly accept or reject the request. If the receiver initially quickly accept or reject the request. If the receiver initially
accepted the request, it still may then do things that take accepted the request, it still may then do things that take
significant time to succeed or fail. For example, if the receiver is significant time to succeed or fail. For example, if the receiver is
an MSRP to XMPP [30] gateway, it may forward the message over XMPP. an MSRP to XMPP [29] gateway, it may forward the message over XMPP.
The XMPP side may later indicate that the request did not work. At The XMPP side may later indicate that the request did not work. At
this point, the MSRP receiver may need to indicate that the request this point, the MSRP receiver may need to indicate that the request
did not succeed. There are two important concepts here: first, the did not succeed. There are two important concepts here: first, the
hop by hop delivery of the request may succeed or fail; second, the hop by hop delivery of the request may succeed or fail; second, the
end result of the request may be successfully processed or not. The end result of the request may be successfully processed or not. The
first type of status is referred to as "transaction status" and may first type of status is referred to as "transaction status" and may
be returned in response to a request. The second type of status is be returned in response to a request. The second type of status is
referred to as "delivery status" and may be returned in a REPORT referred to as "delivery status" and may be returned in a REPORT
transaction. transaction.
The original sender of a request can indicate if they wish to receive The original sender of a request can indicate if they wish to receive
reports for requests that fail, and can independently indicate if reports for requests that fail, and can independently indicate if
they wish to receive reports for requests that succeed. A receiver they wish to receive reports for requests that succeed. A receiver
only sends a success REPORT if it knows that the request was only sends a success REPORT if it knows that the request was
successfully delivered, and the sender requested a success report. A successfully delivered, and the sender requested a success report. A
receiver only sends a failure REPORT if the request failed to be receiver only sends a failure REPORT if the request failed to be
delivered and the sender requested failure reports. delivered and the sender requested failure reports.
This document describes the behavior of MSRP endpoints. MSRP This document describes the behavior of MSRP endpoints. MSRP
relays or gateways are likely to have additional conditions that relays will introduce additional conditions that indicate a
indicate a failure REPORT should be sent, such as the failure to failure REPORT should be sent, such as the failure to receive a
receive a positive response from the next hop. positive response from the next hop.
Two header fields control the sender's desire to receive reports. Two header fields control the sender's desire to receive reports.
The header field "Success-Report" can have a value of "yes" or "no" The header field "Success-Report" can have a value of "yes" or "no"
and the "Failure-Report" header field can have a value of "yes", and the "Failure-Report" header field can have a value of "yes",
"no", or "partial". "no", or "partial".
The combinations of reporting are needed to meet the various The combinations of reporting are needed to meet the various
scenarios of currently deployed IM systems. Success-Report might be scenarios of currently deployed IM systems. Success-Report might be
"no" in many public systems to reduce load but might be "yes" in "no" in many public systems to reduce load but might be "yes" in
certain enterprise systems, such as systems used for securities certain enterprise systems, such as systems used for securities
trading. A Failure-Report value of "no" is useful for sending system trading. A Failure-Report value of "no" is useful for sending system
messages such as "the system is going down in 5 minutes" without messages such as "the system is going down in 5 minutes" without
causing a response explosion to the sender. A Failure-Report of causing a response explosion to the sender. A Failure-Report of
"yes" is used by many systems that wish to notify the user if the "yes" is used by many systems that wish to notify the user if the
message failed. A Failure-Report of "partial" is a way to report message failed. A Failure-Report of "partial" is a way to report
errors other than timeouts. The timeout error reporting requires the errors other than timeouts. The timeout error reporting requires the
sending hop to run a timer and the receiving hop to send an sending hop to run a timer and the receiving hop to send an
acknowledgment to stop the timer. Some systems don't want the acknowledgment to stop the timer. Some systems don't want the
overhead of doing this. "Partial" allows them to choose not to so, overhead of doing this. "Partial" allows them to choose not to do
but still allows error responses to be sent in many cases. so, but still allows error responses to be sent in many cases.
The "partial" value allows a compromise between no reporting of The "partial" value allows a compromise between no reporting of
failures, and reporting all failures. For example, with failures, and reporting all failures. For example, with
"partial", an sending device does not have keep transaction state "partial", an sending device does not have to keep transaction
around waiting for a positive acknowledgment. But it still allows state around waiting for a positive acknowledgment. But it still
devices to report other types of errors. For example, the allows devices to report other types of errors. For example, the
receiving device could still report a policy violation such as an receiving device could still report a policy violation such as an
unacceptable content-type, or an ICMP error trying to connect to a unacceptable content-type, or an ICMP error trying to connect to a
downstream device. downstream device.
5.4. MSRP Connection Model 5.4. MSRP Connection Model
When an MSRP endpoint wishes to send a request to a peer identified When an MSRP endpoint wishes to send a request to a peer identified
by an MSRP URL, it first needs a transport connection, with the by an MSRP URL, it first needs a transport connection, with the
appropriate security properties, to the host specified in the URL. appropriate security properties, to the host specified in the URL.
If the sender already has such a connection, that is, one associated If the sender already has such a connection, that is, one associated
skipping to change at page 16, line 17 skipping to change at page 16, line 17
order the records were presented. order the records were presented.
This process assumes that the connection port is always known This process assumes that the connection port is always known
prior to resolution. This is always true for the MSRP URL uses prior to resolution. This is always true for the MSRP URL uses
described in this document, that is, URLs exchanged in the SDP described in this document, that is, URLs exchanged in the SDP
offer and answer. The introduction of relays may create offer and answer. The introduction of relays may create
situations where this is not the case. For example, the MSRP URL 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 that a user enters into a client to configure it to use a relay
may be intended to be easily remembered and communicated by may be intended to be easily remembered and communicated by
humans, and therefore is likely to omit the port. Therefore, the humans, and therefore is likely to omit the port. Therefore, the
relay specification [23] may describe additional steps to resolve relay specification [22] may describe additional steps to resolve
the port number. the port number.
MSRP devices MAY use other methods for discovering other such MSRP devices MAY use other methods for discovering other such
devices, when appropriate. For example, MSRP endpoints may use other devices, when appropriate. For example, MSRP endpoints may use other
mechanisms to discover relays, which are beyond the scope of this mechanisms to discover relays, which are beyond the scope of this
document. document.
7. Method-Specific Behavior 7. Method-Specific Behavior
7.1. Constructing Requests 7.1. Constructing Requests
skipping to change at page 16, line 49 skipping to change at page 16, line 49
continues to handle a body, if present. If the request has a body, continues to handle a body, if present. If the request has a body,
it must contain a Content-Type header field. It may contain other it must contain a Content-Type header field. It may contain other
MIME-specific header fields. The Content-Type header field MUST be MIME-specific header fields. The Content-Type header field MUST be
the last field in the message header section. The body MUST be the last field in the message header section. The body MUST be
separated from the header fields with an extra CRLF. separated from the header fields with an extra CRLF.
Non-SEND requests are not intended to carry message content, and are Non-SEND requests are not intended to carry message content, and are
therefore not interruptible. Non-SEND request bodies MUST NOT be therefore not interruptible. Non-SEND request bodies MUST NOT be
larger than 10240 octets. larger than 10240 octets.
ALthough this document does discuss any particular usage of bodies Although this document does not discuss any particular usage of
in non-SEND requests, they may be useful in the future for bodies in non-SEND requests, they may be useful in the future for
carrying security or identity information, information about a carrying security or identity information, information about a
message in progress, etc. The 10K size limit was chosen to be message in progress, etc. The 10K size limit was chosen to be
large enough for most of such applications, but small enough to large enough for most of such applications, but small enough to
avoid the fairness issues caused by sending arbitrarily large avoid the fairness issues caused by sending arbitrarily large
content in non-interuptible method bodies. content in non-interruptible method bodies.
A request with no body MUST NOT include a Content-Type header field. A request with no body MUST NOT include a Content-Type header field.
Note that, if no body is present, no extra CRLF will be present Note that, if no body is present, no extra CRLF will be present
between the header section and the end-line. between the header section and the end-line.
Requests with no bodies are useful when a client wishes to send Requests with no bodies are useful when a client wishes to send
"traffic", but does not wish to send content to be rendered to the "traffic", but does not wish to send content to be rendered to the
peer user. For example, the offerer must send a SEND request peer user. For example, the offerer must send a SEND request
immediately upon establishing a connection. If it has nothing to immediately upon establishing a connection. If it has nothing to
say at the moment, it can send a request with no body. Bodiless say at the moment, it can send a request with no body. Bodiless
requests may also be used in certain applications to keep NAT requests may also be used in certain applications to keep NAT
bindings alive, etc. bindings alive, etc.
Bodiless requests are distinct from requests with empty bodies. A Bodiless requests are distinct from requests with empty bodies. A
request with an empty body will have a Content-Type header field request with an empty body will have a Content-Type header field
value, and will generally be rendered to the recipient according value, and will generally be rendered to the recipient according
to the rules for that type. to the rules for that type.
The end-line that terminates the request MUST be composed of seven The end-line that terminates the request MUST be composed of seven
"-" (minus sign) characters, the transaction ID as used in the start "-" (minus sign) characters, the transaction ID as used in the start
line, and a flag character. If a body is present, the end-line must line, and a flag character. If a body is present, the end-line must
be followed by a CRLF that is not part of the body. If the chunk be preceded by a CRLF that is not part of the body. If the chunk
represents the data that forms the end of the complete message, the represents the data that forms the end of the complete message, the
flag value MUST be a "$". If sender is aborting an incomplete flag value MUST be a "$". If sender is aborting an incomplete
message, and intends to send no further chunks in that message, it message, and intends to send no further chunks in that message, it
MUST be a "#". Otherwise it MUST be a "+". MUST be a "#". Otherwise it MUST be a "+".
If the request contains a body, the sender MUST ensure that the end- If the request contains a body, the sender MUST ensure that the end-
line (seven hyphens, the transaction identifier, and a continuation line (seven hyphens, the transaction identifier, and a continuation
flag) is not present in the body. If the end-line is present in the flag) is not present in the body. If the end-line is present in the
body, the sender MUST choose a new transaction identifier that is not body, the sender MUST choose a new transaction identifier that is not
present in the body, and add a CRLF if needed, and the end-line, present in the body, and add a CRLF if needed, and the end-line,
including the "$", "#", or "+" character. including the "$", "#", or "+" character.
Some implementations may choose to implement this such that if they Some implementations may choose to scan for the closing sequence as
find the closing sequence in the body of the message they are they send the body, and if it is encountered, simply interrupt the
sending, simply interrupting the message at that point and starting a chunk at that point and start a new transaction with a different
new transaction with a different transaction identifier to carry the transaction identifier to carry the rest of the body. Other
rest of the body. Other implementation may choose to scan the data implementation may choose to scan the data an ensure that the body
an ensure that the body does not contain the transaction identifier does not contain the transaction identifier before they start sending
before they start sending the transaction. the transaction.
Finally, requests which have no body MUST NOT contain a Content-Type Finally, requests which have no body MUST NOT contain a Content-Type
header field or any other MIME specific header field. Requests header field or any other MIME specific header field. Requests
without bodies MUST contain a end-line after the final header field. without bodies MUST contain a end-line after the final header field.
Once a request is ready for delivery, the sender follows the Once a request is ready for delivery, the sender follows the
connection management (Section 5.4) rules to forward the request over connection management (Section 5.4) rules to forward the request over
an existing open connection or create a new connection. an existing open connection or create a new connection.
7.1.1. Sending SEND Requests 7.1.1. Sending SEND Requests
skipping to change at page 20, line 31 skipping to change at page 20, line 31
gets a chance to send some fair portion of data at regular intervals gets a chance to send some fair portion of data at regular intervals
suitable to the application. suitable to the application.
The sender MUST NOT assume that a message is received by the peer The sender MUST NOT assume that a message is received by the peer
with the same chunk allocation with which it was sent. An with the same chunk allocation with which it was sent. An
intervening relay could possibly break SEND requests into smaller intervening relay could possibly break SEND requests into smaller
chunks, or aggregate multiple chunks into larger ones. chunks, or aggregate multiple chunks into larger ones.
The default disposition of bodies is "render". If the sender wants The default disposition of bodies is "render". If the sender wants
different disposition, it MAY insert a Content-Disposition[9] header different disposition, it MAY insert a Content-Disposition[9] header
field. Since MSRP is a binary protocol, transfer encoding is always field. Since MSRP can carry unencoded binary payloads, transfer
"binary", and transfer-encoding parameters MUST NOT be present. encoding is always "binary", and transfer-encoding parameters MUST
NOT be present.
7.1.2. Sending REPORT Requests 7.1.2. Sending REPORT Requests
REPORT requests are similar to SEND requests, except that report REPORT requests are similar to SEND requests, except that report
requests MUST NOT include Success-Report or Failure-Report header requests MUST NOT include Success-Report or Failure-Report header
fields, and MUST contain a Status header field. REPORT requests MUST fields, and MUST contain a Status header field. REPORT requests MUST
contain the Message-ID header field from the original SEND request. contain the Message-ID header field from the original SEND request.
If an MSRP element receives a REPORT for a Message-ID it does not If an MSRP element receives a REPORT for a Message-ID it does not
recognize, it SHOULD silently ignore the REPORT. recognize, it SHOULD silently ignore the REPORT.
skipping to change at page 21, line 4 skipping to change at page 21, line 5
recognize, it SHOULD silently ignore the REPORT. recognize, it SHOULD silently ignore the REPORT.
An MSRP endpoint MUST be able to generate success REPORT requests. An MSRP endpoint MUST be able to generate success REPORT requests.
REPORT requests will normally not include a body, as the REPORT REPORT requests will normally not include a body, as the REPORT
request header fields can carry sufficient information in most cases. request header fields can carry sufficient information in most cases.
However, REPORT requests MAY include a body containing additional However, REPORT requests MAY include a body containing additional
information about the status of the associated SEND request. Such a information about the status of the associated SEND request. Such a
body is informational only, and the sender of the REPORT request body is informational only, and the sender of the REPORT request
SHOULD NOT assume that the recipient pays any attention to the body. SHOULD NOT assume that the recipient pays any attention to the body.
REPORT requests are not interruptible. REPORT requests are not interruptible.
7.1.3. Generating Success Reports
An endpoint MUST send a success report if it successfully receives a An endpoint MUST send a success report if it successfully receives a
SEND request which contained a Success-Report value of "yes" and SEND request which contained a Success-Report value of "yes" and
either contains a complete message, or contains the last chunk needed either contains a complete message, or contains the last chunk needed
to complete the message. This request is sent following the normal to complete the message. This request is sent following the normal
procedures (Section 7.1), with a few additional requirements. procedures (Section 7.1), with a few additional requirements.
The endpoint inserts a To-Path header field containing the From-Path The endpoint inserts a To-Path header field containing the From-Path
value from the original request, and a From-Path header field value from the original request, and a From-Path header field
containing the URL identifying itself in the session. The endpoint containing the URL identifying itself in the session. The endpoint
then inserts a Status header field with a namespace of "000", a then inserts a Status header field with a namespace of "000", a
skipping to change at page 21, line 34 skipping to change at page 21, line 36
response code. If a future specification uses the short-status response code. If a future specification uses the short-status
field for some other purpose, it MUST define a new namespace field field for some other purpose, it MUST define a new namespace field
value. value.
The endpoint MUST NOT send a success report for a SEND request that The endpoint MUST NOT send a success report for a SEND request that
either contained no Success-Report header field, or contained such a either contained no Success-Report header field, or contained such a
field with a value of "no". That is, if no Success-Report header field with a value of "no". That is, if no Success-Report header
field is present, it is treated identically to one with a value of field is present, it is treated identically to one with a value of
"no." "no."
7.1.3. Generate Failure REPORTs 7.1.4. Generating Failure Reports
If an MSRP endpoint receives a SEND request that it cannot process If an MSRP endpoint receives a SEND request that it cannot process
for some reason, and the Failure-Report header field either was not for some reason, and the Failure-Report header field either was not
present in the original request, or had a value of "yes", it SHOULD present in the original request, or had a value of "yes", it SHOULD
simply include the appropriate error code in the transaction simply include the appropriate error code in the transaction
response. However, there may be situations where the error cannot be response. However, there may be situations where the error cannot be
determined quickly, such as when the endpoint is a gateway that must determined quickly, such as when the endpoint is a gateway that must
wait for a downstream network to indicate an error. In this wait for a downstream network to indicate an error. In this
situation, it MAY send a 200 OK response to the request, and then situation, it MAY send a 200 OK response to the request, and then
send a failure REPORT request when the error is detected. send a failure REPORT request when the error is detected.
skipping to change at page 22, line 27 skipping to change at page 22, line 29
indicating the actual range being reported on. It can take the indicating the actual range being reported on. It can take the
range-start and total values from the original SEND request, but MUST range-start and total values from the original SEND request, but MUST
calculate the range-end field from the actual body data. calculate the range-end field from the actual body data.
Endpoints SHOULD NOT send REPORT requests if they have reason to Endpoints SHOULD NOT send REPORT requests if they have reason to
believe the request will not be delivered. For example, they SHOULD believe the request will not be delivered. For example, they SHOULD
NOT send a REPORT request on a session that is no longer valid. NOT send a REPORT request on a session that is no longer valid.
This section only describes failure report generation behavior for This section only describes failure report generation behavior for
MSRP endpoints. Relay behavior is beyond the scope of this MSRP endpoints. Relay behavior is beyond the scope of this
document, and will be considered in a separate document [23]. We document, and will be considered in a separate document [22]. We
expect failure reports to be more commonly generated by relays expect failure reports to be more commonly generated by relays
than by endpoints. than by endpoints.
7.2. Constructing Responses 7.2. Constructing Responses
If an MSRP endpoint receives a request that either contains a If an MSRP endpoint receives a request that either contains a
Failure-Report header field value of "yes", or does not contain a Failure-Report header field value of "yes", or does not contain a
Failure-Report header field at all, it MUST immediately generate a Failure-Report header field at all, it MUST immediately generate a
response. Likewise, if an MSRP endpoint receives a request that response. Likewise, if an MSRP endpoint receives a request that
contains a Failure-Report header field value of "partial", and the contains a Failure-Report header field value of "partial", and the
skipping to change at page 22, line 51 skipping to change at page 23, line 5
To construct the response, the endpoint first creates the response To construct the response, the endpoint first creates the response
start-line, inserting appropriate response code and reason fields. start-line, inserting appropriate response code and reason fields.
The transaction identifier in the response start line MUST match the The transaction identifier in the response start line MUST match the
transaction identifier from the original request. transaction identifier from the original request.
The endpoint then inserts an appropriate To-Path header field. If The endpoint then inserts an appropriate To-Path header field. If
the request triggering the response was a SEND request, the To-Path the request triggering the response was a SEND request, the To-Path
header field is formed by copying the last (right-most) URL in the header field is formed by copying the last (right-most) URL in the
From-Path header field of the request. (Responses to SEND requests From-Path header field of the request. (Responses to SEND requests
are returned only to the previous hop.) For responses to all other are returned only to the previous hop.) For responses to all other
request methods, the To-Path header field field contains the full request methods, the To-Path header field contains the full path back
path back to the original sender. This full path is generated by to the original sender. This full path is generated by taking the
taking the list of URLs from the From-Path of the original request, list of URLs from the From-Path of the original request, reversing
reversing the list, and writing the reversed list into the To-Path of the list, and writing the reversed list into the To-Path of the
the response. (Legal REPORT requests do not request responses, so response. (Legal REPORT requests do not request responses, so this
this specification doesn't exercise the behavior described above, specification doesn't exercise the behavior described above, however
however we expect that extensions for gateways and relays will need we expect that extensions for gateways and relays will need such
such behavior.) behavior.)
Finally, the endpoint inserts a From-Path header field containing the Finally, the endpoint inserts a From-Path header field containing the
URL that identifies it in the context of the session, followed by the URL that identifies it in the context of the session, followed by the
end-line after the last header field. The response MUST be end-line after the last header field. The response MUST be
transmitted back on the same connection on which the original request transmitted back on the same connection on which the original request
arrived. arrived.
7.3. Receiving Requests 7.3. Receiving Requests
The receiving endpoint must first check the URL in the To-Path to The receiving endpoint must first check the URL in the To-Path to
skipping to change at page 24, line 25 skipping to change at page 24, line 29
bytes 1 to 100 were received and a chunk arrives that contains bytes bytes 1 to 100 were received and a chunk arrives that contains bytes
50 to 150, this second chunk will overwrite bytes 50 to 100 of the 50 to 150, this second chunk will overwrite bytes 50 to 100 of the
data that had already been received. Although other schemes work, data that had already been received. Although other schemes work,
this is the easiest for the receiver and results in consistent this is the easiest for the receiver and results in consistent
behavior between clients. behavior between clients.
There are situations in which the receiver may not be able to give There are situations in which the receiver may not be able to give
precedence to the last chunk received when chunks overlap. For precedence to the last chunk received when chunks overlap. For
example, the recipient might incrementally render chunks as they example, the recipient might incrementally render chunks as they
arrive. If a new chunk arrives that overlaps with a previously arrive. If a new chunk arrives that overlaps with a previously
rendered chunk, it would be to late to "take back" any conflicting rendered chunk, it would be too late to "take back" any
data from the first chunk. Therefore, the requirement to give conflicting data from the first chunk. Therefore, the requirement
precedent to the most recent chunk is specified at a "SHOULD" to give precedence to the most recent chunk is specified at a
strength. This requirement is not intended to disallow "SHOULD" strength. This requirement is not intended to disallow
applications where it does not make sense. applications where this behavior does not make sense.
The seven "-" in the end-line are used so that the receiver can The seven "-" in the end-line are used so that the receiver can
search for the value "----", 32 bits at a time to find the probable search for the value "----", 32 bits at a time to find the probable
location of the end-line. This allows most processors to locate the location of the end-line. This allows most processors to locate the
boundaries and copy the memory at the same rate that a normal memory boundaries and copy the memory at the same rate that a normal memory
copy could be done. This approach results in a system that is as copy could be done. This approach results in a system that is as
fast as framing based on specifying the body length in the header fast as framing based on specifying the body length in the header
fields of the request, but also allows for the interruption of fields of the request, but also allows for the interruption of
messages. messages.
skipping to change at page 26, line 4 skipping to change at page 26, line 7
state about each outstanding sent message so that it can correlate state about each outstanding sent message so that it can correlate
REPORT requests to the original messages. REPORT requests to the original messages.
An endpoint that receives a REPORT request containing a Status header An endpoint that receives a REPORT request containing a Status header
field with a namespace field of "000" MUST interpret the report in field with a namespace field of "000" MUST interpret the report in
exactly the same way it would interpret an MSRP transaction response exactly the same way it would interpret an MSRP transaction response
with a response code matching the short-code field. with a response code matching the short-code field.
It is possible to receive a failure report or a failure transaction It is possible to receive a failure report or a failure transaction
response for a chunk that is currently being delivered. In this response for a chunk that is currently being delivered. In this
case, the entire message corresponding to that chunk should be case, the entire message corresponding to that chunk SHOULD be
aborted, by including the "#" character in the continuation field of aborted, by including the "#" character in the continuation field of
the end-line. the end-line.
It is possible that an endpoint will receive a REPORT request on a It is possible that an endpoint will receive a REPORT request on a
session that is no longer valid. The endpoint's behavior if this session that is no longer valid. The endpoint's behavior if this
happens is a matter of local policy. The endpoint is not required to happens is a matter of local policy. The endpoint is not required to
take any steps to facilitate such late delivery, i.e. it is not take any steps to facilitate such late delivery, i.e. it is not
expected to keep a connection active in case late REPORTs might expected to keep a connection active in case late REPORTs might
arrive. arrive.
skipping to change at page 26, line 45 skipping to change at page 26, line 48
session description is accompanied by a mandatory "path" attribute. session description is accompanied by a mandatory "path" attribute.
This attribute contains a space-separated list of URLs that must be This attribute contains a space-separated list of URLs that must be
visited to contact the user agent advertising this session- visited to contact the user agent advertising this session-
description. If more than one URL is present, the leftmost URL is description. If more than one URL is present, the leftmost URL is
the first URL that must be visited to reach the target resource. the first URL that must be visited to reach the target resource.
(The path list can contain multiple URLs to allow for the deployment (The path list can contain multiple URLs to allow for the deployment
of gateways or relays in the future.) MSRP implementations that can of gateways or relays in the future.) MSRP implementations that can
accept incoming connections without the need for relays will accept incoming connections without the need for relays will
typically only provide a single URL here. typically only provide a single URL here.
An MSRP media line is also be accompanied by an "accept-types" An MSRP media line is also accompanied by an "accept-types"
attribute, and optionally an "accept-wrapped-types" attribute. These attribute, and optionally an "accept-wrapped-types" attribute. These
attributes are used to specify the MIME types that are acceptable to attributes are used to specify the MIME types that are acceptable to
the endpoint. the endpoint.
8.1. SDP Connection and Media Lines 8.1. SDP Connection and Media Lines
The format of an SDP connection-line takes the following format: The format of an SDP connection-line takes the following format:
c=<network type> <address type> <connection address> c=<network type> <address type> <connection address>
skipping to change at page 27, line 48 skipping to change at page 27, line 48
The connection information is copied to the c-line and m-line for The connection information is copied to the c-line and m-line for
purposes of backwards compatibility with conventional SDP usages. purposes of backwards compatibility with conventional SDP usages.
While MSRP could theoretically carry any media type, "message" is While MSRP could theoretically carry any media type, "message" is
appropriate. appropriate.
8.2. URL Negotiations 8.2. 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 that are negotiated in the SDP exchange. Each SDP offer or answer that
proposes MSRP MUST contain a path attribute containing one or more proposes MSRP MUST contain a path attribute containing one or more
MSRP URLs. The path attribute is used in an SDP a-line, and has has MSRP URLs. The path attribute is used in an SDP a-line, and has the
the following syntax: following syntax:
path = path-label ":" path-list path = path-label ":" path-list
path-label = "path" path-label = "path"
path-list= MSRP-URL *(SP MSRP-URL) path-list= MSRP-URL *(SP MSRP-URL)
where MSRP-URL is an msrp: or msrps: URL as defined in Section 6. where MSRP-URL is an msrp: or msrps: URL as defined in Section 6.
MSRP URLs included in an SDP offer or answer MUST include explicit MSRP URLs included in an SDP offer or answer MUST include explicit
port numbers. port numbers.
An MSRP device uses the URL to determine a host address, port, An MSRP device uses the URL to determine a host address, port,
skipping to change at page 28, line 29 skipping to change at page 28, line 29
target URL is the rightmost, while the leftmost entry represents the target URL is the rightmost, while the leftmost entry represents the
adjacent hop. If only one entry is present, then it is both the peer adjacent hop. If only one entry is present, then it is both the peer
and adjacent hop URL. The target path is the entire path attribute and adjacent hop URL. The target path is the entire path attribute
value received from the peer. value 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://alice.example.com:7394/2s93i;tcp" "msrp://alice.example.com:7394/2s93i;tcp"
v=0 v=0
o=alice 2890844526 2890844527 IN IP4 alice.example.com o=alice 2890844526 2890844527 IN IP4 alice.example.com
s= s= -
c=IN IP4 alice.example.com c=IN IP4 alice.example.com
t=0 0
m=message 7394 TCP/MSRP * m=message 7394 TCP/MSRP *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrp://alice.example.com:7394/2s93i;tcp a=path:msrp://alice.example.com:7394/2s93i;tcp
The rightmost URL in the path attribute MUST identify the endpoint The rightmost URL in the path attribute MUST identify the endpoint
that 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 requests associated with the session. It endpoint wishes to receive requests associated with the session. It
MUST be assigned for this particular session, and MUST NOT duplicate MUST be assigned for this particular session, and MUST NOT duplicate
any URL in use for any other session in which the endpoint is any URL in use for any other session in which the endpoint is
currently participating. It SHOULD be hard to guess, and protected currently participating. It SHOULD be hard to guess, and protected
from eavesdroppers. This is discussed in more detail in Section 14. from eavesdroppers. This is discussed in more detail in Section 14.
8.3. Path Attributes with Multiple URLs 8.3. Path Attributes with Multiple URLs
As mentioned previously, this document describes MSRP for peer-to- As mentioned previously, this document describes MSRP for peer-to-
peer scenarios, that is, when no relays are used. The use of relays peer scenarios, that is, when no relays are used. The use of relays
are described in a separate document [23]. In order to allow an MSRP are described in a separate document [22]. In order to allow an MSRP
device that only implements the core specification to interoperate device that only implements the core specification to interoperate
with devices that use relays, this document must include a few with devices that use relays, this document must include a few
assumptions about how relays work. assumptions about how relays work.
An endpoint that uses one or more relays will indicate that by An endpoint that uses one or more relays will indicate that by
putting a URL for each device in the relay chain into the SDP path putting a URL for each device in the relay chain into the SDP path
attribute. The final entry will point to the endpoint itself. The attribute. The final entry will point to the endpoint itself. The
other entries will indicate each proposed relay, in order. The first other entries will indicate each proposed relay, in order. The first
entry will point to the first relay in the chain from the perspective entry will point to the first relay in the chain from the perspective
of the peer; that is, the relay to which the peer device, or a relay of the peer; that is, the relay to which the peer device, or a relay
skipping to change at page 29, line 28 skipping to change at page 29, line 28
Even though endpoints that implement only this specification will Even though endpoints that implement only this specification will
never introduce a relay, they need to be able to interoperate with never introduce a relay, they need to be able to interoperate with
other endpoints that do use relays. Therefore, they MUST be prepared other endpoints that do use relays. Therefore, they MUST be prepared
to receive more than one URL in the SDP path attribute. When an to receive more than one URL in the SDP path attribute. When an
endpoint receives more than one URL in a path attribute, only the endpoint receives more than one URL in a path attribute, only the
first entry is relevant for purposes of resolving the address and first entry is relevant for purposes of resolving the address and
port, and establishing the network connection, as it describes the port, and establishing the network connection, as it describes the
first adjacent hop. first adjacent hop.
If an endpoint puts more than one URL in a path attribute, the final 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 URL in the path attribute (the peer URL) identifies the session, and
properties described above. Uniqueness requirements for other must not duplicate the URL of any other session in which the endpoint
entries in the attribute are out of scope for this document. is currently participating. Uniqueness requirements for other
entries in the path attribute are out of scope for this document.
8.4. Updated SDP Offers 8.4. Updated SDP Offers
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
session timers or the SIP UPDATE[24] request. They may need to session timers or the SIP UPDATE[23] request. They may need to
change some other stream in a session without affecting the MSRP change some other stream in a session without affecting the MSRP
stream, or they may need to change an MSRP stream without affecting stream, or they may need to change an MSRP stream without affecting
some other stream. some other stream.
Either peer may initiate an updated exchange at any time. The Either peer may initiate an updated exchange at any time. The
endpoint that sends the new offer assumes the role of offerer for all endpoint that sends the new offer assumes the role of offerer for all
purposes. The answerer MUST respond with a path attribute that purposes. The answerer MUST respond with a path attribute that
represents a valid path to itself at the time of the updated represents a valid path to itself at the time of the updated
exchange. This new path may be the same as its previous path, but exchange. This new path may be the same as its previous path, but
may be different. The new offerer MUST NOT assume that the peer will may be different. The new offerer MUST NOT assume that the peer will
answer with the same path it used previously. answer with the same path it used previously.
If either party wishes to send an SDP document that changes nothing If either party wishes to send an SDP document that changes nothing
at all, then it MUST have the same o-line as in the previous at all, then it MUST have the same o-line as in the previous
exchange. exchange.
8.5. Connection Negotiation 8.5. 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 the COMEDIA [26] work being done in the MMUSIC loosely based on the COMEDIA [25] work being done in the MMUSIC
working group. The primary motivation was to allow MSRP sessions to working group. The primary motivation was to allow MSRP sessions to
succeed in situations where the offerer could not accept connections succeed in situations where the offerer could not accept connections
but the answerer could. For example, the offerer might be behind a but the answerer could. For example, the offerer might be behind a
NAT, while the answerer might have a globally routable address. NAT, while the answerer might have a globally routable address.
The SIMPLE working group chose to remove that mechanism from MSRP, as The SIMPLE working group chose to remove that mechanism from MSRP, as
it added a great deal of complexity to connection management. it added a great deal of complexity to connection management.
Instead, MSRP now specifies a default connection direction. The Instead, MSRP now specifies a default connection direction. The
party that sent the original offer is responsible for connecting to party that sent the original offer is responsible for connecting to
its peer. its peer.
skipping to change at page 32, line 13 skipping to change at page 32, line 25
max-size-label = "max-size" max-size-label = "max-size"
max-size-value = 1*(DIGIT) ;max size in octets max-size-value = 1*(DIGIT) ;max size in octets
8.7. Example SDP Exchange 8.7. Example SDP Exchange
Endpoint A wishes to invite Endpoint B to an MSRP session. A offers Endpoint A wishes to invite Endpoint B to an 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 c=IN IP4 alice.example.com
t=0 0 t=0 0
m=message 7394 TCP/MSRP * m=message 7394 TCP/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;tcp a=path:msrp://alice.example.com:7394/2s93i9;tcp
B responds with its own URL: B responds with its own URL:
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 bob.example.com c=IN IP4 bob.example.com
t=0 0 t=0 0
m=message 8493 TCP/MSRP * m=message 8493 TCP/MSRP *
a=accept-types:message/cpim text/plain a=accept-types:message/cpim text/plain
a=path:msrp://bob.example.com:8493/si438ds;tcp a=path:msrp://bob.example.com:8493/si438ds;tcp
8.8. MSRP User Experience with SIP 8.8. MSRP User Experience with SIP
In typical SIP applications, when an endpoint receives an INVITE In typical SIP applications, when an endpoint receives an INVITE
request, it alerts the user, and waits for user input before request, it alerts the user, and waits for user input before
skipping to change at page 33, line 4 skipping to change at page 33, line 15
suggest that MSRP endpoints using SIP signaling SHOULD allow a mode suggest that MSRP endpoints using SIP signaling SHOULD allow a mode
where the endpoint quietly accepts the session, and begins displaying where the endpoint quietly accepts the session, and begins displaying
messages. messages.
This guideline may not make sense for all situations, such as for This guideline may not make sense for all situations, such as for
mixed media applications, where both MSRP and audio sessions are mixed media applications, where both MSRP and audio sessions are
offered in the same INVITE. In general, good application design offered in the same INVITE. In general, good application design
should take precedence. should take precedence.
SIP INVITE requests may be forked by a SIP proxy, resulting in more SIP INVITE requests may be forked by a SIP proxy, resulting in more
than one endpoint receiving the same INVITE. SIP early media [29] than one endpoint receiving the same INVITE. SIP early media [28]
techniques can be used to establish a preliminary session with each techniques can be used to establish a preliminary session with each
endpoint so the initial message(s) are displayed on each endpoint, endpoint so the initial message(s) are displayed on each endpoint,
and canceling the INVITE transaction for any endpoints that do not and canceling the INVITE transaction for any endpoints that do not
send MSRP traffic after some period of time, so that they cease send MSRP traffic after some period of time, so that they cease
receiving MSRP traffic from the inviter. receiving MSRP traffic from the inviter.
9. Formal Syntax 9. Formal Syntax
MSRP is a text protocol that uses the UTF-8 [14] transformation MSRP is a text protocol that uses the UTF-8 [14] transformation
format. format.
skipping to change at page 36, line 44 skipping to change at page 37, line 5
A 415 response indicates the SEND request contained a MIME content- A 415 response indicates the SEND request contained a MIME content-
type that is not understood by the receiver. The sender should not type that is not understood by the receiver. The sender should not
send any further messages with the same content-type for the duration send any further messages with the same content-type for the duration
of the session. of the session.
10.7. 423 10.7. 423
A 423 response indicates that one of the requested parameters is out A 423 response indicates that one of the requested parameters is out
of bounds. It is used by the relay extensions to this document. of bounds. It is used by the relay extensions to this document.
10.8. 426 10.8. 481
A 426 response indicates that the request is only allowed over secure
connections.
10.9. 481
A 481 response indicates that the indicated session does not exist. A 481 response indicates that the indicated session does not exist.
The sender should terminate the session. The sender should terminate the session.
10.10. 501 10.9. 501
A 501 response indicates that the recipient does not understand the A 501 response indicates that the recipient does not understand the
request method. request method.
The 501 response code exists to allow some degree of method The 501 response code exists to allow some degree of method
extensibility. It is not intended as a license to ignore methods extensibility. It is not intended as a license to ignore methods
defined in this document; rather it is a mechanism to report lack defined in this document; rather it is a mechanism to report lack
of support of extension methods. of support of extension methods.
10.11. 506 10.10. 506
A 506 response indicates that a request arrived on a session which is A 506 response indicates that a request arrived on a session which is
already bound to another network connection. The sender should cease already bound to another network connection. The sender should cease
sending messages for that session on this connection. sending messages for that session on this connection.
11. Examples 11. Examples
11.1. Basic IM Session 11.1. Basic IM Session
This section shows an example flow for the most common scenario. The This section shows an example flow for the most common scenario. The
skipping to change at page 38, line 36 skipping to change at page 38, line 36
| | | |
| | | |
1. Alice constructs a local URL of 1. Alice constructs a local URL of
msrp://alicepc.example.com:7777/iau39;tcp . msrp://alicepc.example.com:7777/iau39;tcp .
Alice->Bob (SIP): INVITE sip:bob@example.com Alice->Bob (SIP): INVITE sip:bob@example.com
v=0 v=0
o=alice 2890844557 2890844559 IN IP4 alicepc.example.com o=alice 2890844557 2890844559 IN IP4 alicepc.example.com
s= s= -
c=IN IP4 alicepc.example.com c=IN IP4 alicepc.example.com
t=0 0 t=0 0
m=message 7777 TCP/MSRP * m=message 7777 TCP/MSRP *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrp://alicepc.example.com:7777/iau39;tcp a=path:msrp://alicepc.example.com:7777/iau39;tcp
2. Bob listens on port 8888, and sends the following response: 2. Bob listens on port 8888, and sends the following response:
Bob->Alice (SIP): 200 OK Bob->Alice (SIP): 200 OK
v=0 v=0
o=bob 2890844612 2890844616 IN IP4 bob.example.com o=bob 2890844612 2890844616 IN IP4 bob.example.com
s= s= -
c=IN IP4 bob.example.com c=IN IP4 bob.example.com
t=0 0 t=0 0
m=message 8888 TCP/MSRP * m=message 8888 TCP/MSRP *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrp://bob.example.com:8888/9di4ea;tcp a=path:msrp://bob.example.com:8888/9di4ea;tcp
3. Alice->Bob (SIP): ACK sip:bob@example.com 3. Alice->Bob (SIP): ACK sip:bob@example.com
4. (Alice opens connection to Bob.) Alice->Bob (MSRP): 4. (Alice opens connection to Bob.) Alice->Bob (MSRP):
skipping to change at page 41, line 43 skipping to change at page 41, line 43
11.6. Forked IM 11.6. Forked IM
Traditional IM systems generally do a poor job of handling multiple Traditional IM systems generally do a poor job of handling multiple
simultaneous IM clients online for the same person. While some do a simultaneous IM clients online for the same person. While some do a
better job than many existing systems, handling of multiple clients better job than many existing systems, handling of multiple clients
is fairly crude. This becomes a much more significant issue when is fairly crude. This becomes a much more significant issue when
always-on mobile devices are available, but it is desirable to use always-on mobile devices are available, but it is desirable to use
them only if another IM client is not available. them only if another IM client is not available.
Using SIP makes rendezvous decisions explicit, deterministic, and Using SIP makes rendezvous decisions explicit, deterministic, and
very flexible. In contrast, "pager-mode" IM systems use implicit very flexible. In contrast, "page-mode" IM systems use implicit
implementation-specific decisions which IM clients cannot influence. implementation-specific decisions which IM clients cannot influence.
With SIP session mode messaging, rendezvous decisions can be under With SIP session mode messaging, rendezvous decisions can be under
control of the client in a predictable, interoperable way for any control of the client in a predictable, interoperable way for any
host that implements callee capabilities [31]. As a result, host that implements callee capabilities [30]. As a result,
rendezvous policy is managed consistently for each address of record. rendezvous policy is managed consistently for each address of record.
The following example shows Juliet with several IM clients where she The following example shows Juliet with several IM clients where she
can be reached. Each of these has a unique SIP Contact and MSRP can be reached. Each of these has a unique SIP Contact and MSRP
session. The example takes advantage of SIP's capability to "fork" session. The example takes advantage of SIP's capability to "fork"
an invitation to several Contacts in parallel, in sequence, or in an invitation to several Contacts in parallel, in sequence, or in
combination. Juliet has registered from her chamber, the balcony, combination. Juliet has registered from her chamber, the balcony,
her PDA, and as a last resort, you can leave a message with her her PDA, and as a last resort, you can leave a message with her
Nurse. Juliet's contacts are listed below. The q-values express Nurse. Juliet's contacts are listed below. The q-values express
relative preference (q=1.0 is the highest preference). relative preference (q=1.0 is the highest preference).
skipping to change at page 42, line 20 skipping to change at page 42, line 20
The example uses REGISTER to learn of Juliet's registered The example uses REGISTER to learn of Juliet's registered
contacts. This does not constitute an endorsement of that contacts. This does not constitute an endorsement of that
approach; it is used here to avoid cluttering the example with too approach; it is used here to avoid cluttering the example with too
many SIP details. A more realistic application would be the use a many SIP details. A more realistic application would be the use a
SIP proxy or redirect server for this purpose. SIP proxy or redirect server for this purpose.
We query for a list of Juliet's contacts by sending a REGISTER: We query for a list of Juliet's contacts by sending a REGISTER:
REGISTER sip:thecapulets.example.com SIP/2.0 REGISTER sip:thecapulets.example.com SIP/2.0
To: Juliet <sip:juliet@thecapulets.example.com> To: Juliet <sip:juliet@thecapulets.example.com>
From: Juliet <sip:juliet@thecapulets.example.com>;tag=12345 From: Romeo <sip:romeo@montague.example.com>;tag=12345
Via: SIP/2.0/UDP romeospc.example.com:5060;branch=z9hG4bKnashds7
Call-ID: 09887877 Call-ID: 09887877
Max-Forwards=70
CSeq: 772 REGISTER CSeq: 772 REGISTER
The Response contains her Contacts: The Response contains her Contacts:
SIP/2.0 200 OK SIP/2.0 200 OK
To: Juliet <sip:juliet@thecapulets.example.com> To: Juliet <sip:juliet@thecapulets.example.com>
From: Juliet <sip:juliet@thecapulets.example.com>;tag=12345 From: Juliet <sip:juliet@thecapulets.example.com>;tag=12345
Via: SIP/2.0/UDP romeospc.example.com:5060;branch=z9hG4bKnashds7
Call-ID: 09887877 Call-ID: 09887877
CSeq: 772 REGISTER CSeq: 772 REGISTER
Contact: <sip:juliet@balcony.thecapulets.example.com> Contact: <sip:juliet@balcony.thecapulets.example.com>
;q=0.9;expires=3600 ;q=0.9;expires=3600
Contact: <sip:juliet@chamber.thecapulets.example.com> Contact: <sip:juliet@chamber.thecapulets.example.com>
;q=1.0;expires=3600 ;q=1.0;expires=3600
Contact: <sip:jcapulet@veronamobile.example.net>;q=0.4;expires=3600 Contact: <sip:jcapulet@veronamobile.example.net>;q=0.4;expires=3600
Contact: <sip:nurse@thecapulets.example.com>;q=0.1;expires=3600 Contact: <sip:nurse@thecapulets.example.com>;q=0.1;expires=3600
When Romeo opens his IM program, he selects Juliet and types the When Romeo opens his IM program, he selects Juliet and types the
skipping to change at page 44, line 9 skipping to change at page 45, line 9
| Hi Romeo, Juliet is | | Hi Romeo, Juliet is |
| with her father now | | with her father now |
| can I take a message?| | can I take a message?|
| | | |
| Tell her to go to confession tomorrow.... | | Tell her to go to confession tomorrow.... |
12. Extensibility 12. Extensibility
MSRP was designed to be only minimally extensible. New MSRP Methods, MSRP was designed to be only minimally extensible. New MSRP Methods,
header fields, and status codes can be defined in standards track header fields, and status codes can be defined in standards track
RFCs. There is no registry of header fields, methods, or status RFCs. MSRP does not contain a version number or any negotiation
codes, since the number of new elements and total extensions is mechanism to require or discover new features. If an extension is
expected to be very small. MSRP does not contain a version number or specified in the future that requires negotiation, the specification
any negotiation mechanism to require or discover new features. If a will need to describe how the extension is to be negotiated in the
non-interoperable update or extension occurs in the future, it will encapsulating signaling protocol. If a non-interoperable update or
be treated as a new protocol, and must describe how its use will be extension occurs in the future, it will be treated as a new protocol,
signaled. and must describe how its use will be signaled.
In order to allow extension header fields without breaking In order to allow extension header fields without breaking
interoperability, if an MSRP device receives a request or response interoperability, if an MSRP device receives a request or response
containing a header field that it does not understand, it MUST ignore containing a header field that it does not understand, it MUST ignore
the header field and process the request or response as if the header the header field and process the request or response as if the header
field was not present. If an MSRP device receives a request with an field was not present. If an MSRP device receives a request with an
unknown method, it MUST return a 501 response. unknown method, it MUST return a 501 response.
MSRP was designed to use lists of URLs instead of a single URL in the MSRP was designed to use lists of URLs instead of a single URL in the
To-Path and From-Path header fields in anticipation of relay or To-Path and From-Path header fields in anticipation of relay or
gateway functionality being added. In addition, msrp: and msrps: gateway functionality being added. In addition, msrp: and msrps:
URLs can contain parameters that are extensible. URLs can contain parameters that are extensible.
13. CPIM Compatibility 13. CPIM Compatibility
MSRP sessions may go to a gateway to other CPIM [27] compatible MSRP sessions may go to a gateway to other CPIM [26] 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, which do not include a concept of sessions. Furthermore, semantics, which 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" [12] bodies. Such a gateway MUST SHOULD be wrapped in "message/cpim" [12] 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 attribute. MSRP endpoints sending instant messages to a peer that
has 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
skipping to change at page 46, line 34 skipping to change at page 47, line 34
man-in-the-middle. man-in-the-middle.
Realistically, using TLS with certificates from well known Realistically, using TLS with certificates from well known
certificate authorities is difficult for peer-to-peer connections, as certificate authorities is difficult for peer-to-peer connections, as
the types of hosts that end clients use for sending instant messages the types of hosts that end clients use for sending instant messages
are unlikely to have long-term stable IP addresses or DNS names that are unlikely to have long-term stable IP addresses or DNS names that
certificates can bind to. In addition, the cost of server certificates can bind to. In addition, the cost of server
certificates from well-known certificate authorities is currently certificates from well-known certificate authorities is currently
expensive enough to discourage their use for each client. Using TLS expensive enough to discourage their use for each client. Using TLS
in a peer-to-peer mode without well known certificate is discussed in in a peer-to-peer mode without well known certificate is discussed in
section Section 14.3. Section 14.3.
TLS becomes much more practical when some form of relay is TLS becomes much more practical when some form of relay is
introduced. Clients can then form TLS connections to relays, which introduced. Clients can then form TLS connections to relays, which
are much more likely to have TLS certificates. While this are much more likely to have TLS certificates. While this
specification does not address such relays, they are described by a specification does not address such relays, they are described by a
companion document [23]. That document makes extensive use of TLS to companion document [22]. That document makes extensive use of TLS to
protect traffic between clients and relays, and between one relay and protect traffic between clients and relays, and between one relay and
another. another.
TLS is used to authenticate devices and to provide integrity and TLS is used to authenticate devices and to provide integrity and
confidentiality for the header fields being transported. MSRP confidentiality for the header fields being transported. MSRP
elements MUST implement TLS and MUST also implement the TLS elements MUST implement TLS and MUST also implement the TLS
ClientExtendedHello extended hello information for server name ClientExtendedHello extended hello information for server name
indication as described in [11]. A TLS cipher-suite of indication as described in [11]. A TLS cipher-suite of
TLS_RSA_WITH_AES_128_CBC_SHA [13] MUST be supported (other cipher- TLS_RSA_WITH_AES_128_CBC_SHA [13] MUST be supported (other cipher-
suites MAY also be supported). suites MAY also be supported).
skipping to change at page 47, line 15 skipping to change at page 48, line 15
14.2. S/MIME 14.2. S/MIME
The only strong security for non-TLS connections is achieved using The only strong security for non-TLS connections is achieved using
S/MIME. S/MIME.
Since MSRP carries arbitrary MIME content, it can trivially carry Since MSRP carries arbitrary MIME content, it can trivially carry
S/MIME protected messages as well. All MSRP implementations MUST S/MIME protected messages as well. All MSRP implementations MUST
support the multipart/signed MIME type even if they do not support support the multipart/signed MIME type even if they do not support
S/MIME. Since SIP can carry a session key, S/MIME messages in the S/MIME. Since SIP can carry a session key, S/MIME messages in the
context of a session could also be protected using a key-wrapped context of a session could also be protected using a key-wrapped
shared secret [28] provided in the session setup. MSRP is a binary shared secret [27] provided in the session setup. MSRP can carry
protocol and MIME bodies MUST be transferred with a transfer encoding unencoded binary payloads. Therefore MIME bodies MUST be transferred
of binary. If a message is both signed and encrypted, it SHOULD be with a transfer encoding of binary. If a message is both signed and
signed first, then encrypted. If S/MIME is supported, SHA-1, RSA, encrypted, it SHOULD be signed first, then encrypted. If S/MIME is
and AES-128 MUST be supported. supported, SHA-1, RSA, and AES-128 MUST be supported.
This does not actually require the endpoint to have certificates from This does not actually require the endpoint to have certificates from
a well-known certificate authority. When MSRP is used with SIP, the a well-known certificate authority. When MSRP is used with SIP, the
Identity [16] and Certificates [25] mechanisms provide S/MIME based Identity [16] and Certificates [24] mechanisms provide S/MIME based
delivery of a secret between A and B. No SIP intermediary except the delivery of a secret between A and B. No SIP intermediary except the
explicitly trusted authentication service (one per user) can see the explicitly trusted authentication service (one per user) can see the
secret. The S/MIME encryption of the SDP can also be used by SIP to secret. The S/MIME encryption of the SDP can also be used by SIP to
exchange keying material that can be used in MSRP. The MSRP session exchange keying material that can be used in MSRP. The MSRP session
can then use S/MIME with this keying material to encrypt and sign can then use S/MIME with this keying material to encrypt and sign
messages sent over MSRP. The connection can still be hijacked since messages sent over MSRP. The connection can still be hijacked since
the secret is sent in clear text to the other end of the TCP the secret is sent in clear text to the other end of the TCP
connection, but the consequences are mitigated if all the MSRP connection, but the consequences are mitigated if all the MSRP
content is encrypted and signed with S/MIME. Although out of scope content is encrypted and signed with S/MIME. Although out of scope
for this document, the SIP negotiation of MSRP session can negotiate for this document, the SIP negotiation of MSRP session can negotiate
skipping to change at page 49, line 9 skipping to change at page 50, line 9
m=message 7654 TCP/TLS/MSRP * m=message 7654 TCP/TLS/MSRP *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrp://atlanta.example.com:7654/jshA7we;tcp a=path:msrp://atlanta.example.com:7654/jshA7we;tcp
a=fingerprint:SHA-1 \ a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
14.4. Other Security Concerns 14.4. Other Security Concerns
MSRP cannot be used as an amplifier for DoS attacks, but it can be MSRP cannot be used as an amplifier for DoS attacks, but it can be
used to form a distributed attack to consume TCP connection resource used to form a distributed attack to consume TCP connection resource
on servers. The attacker, Eve, sends a SIP INVITE with no offer to on servers. The attacker, Mallory, sends a SIP INVITE with no offer
Alice. Alice returns a 200 with an offer and Eve returns an answer to Alice. Alice returns a 200 with an offer and Mallory returns an
with SDP indicating that her MSRP address is the address of Tom. answer with SDP indicating that his MSRP address is the address of
Since Alice sent the offer, Alice will initiate a connection to Tom Tom. Since Alice sent the offer, Alice will initiate a connection to
using up resources on Tom's server. Given the huge number of IM Tom using up resources on Tom's server. Given the huge number of IM
clients, and the relatively few TCP connections that most servers clients, and the relatively few TCP connections that most servers
support, this is a fairly straightforward attack. support, this is a fairly straightforward attack.
SIP is attempting to address issues in dealing with spam. The spam SIP is attempting to address issues in dealing with spam. The spam
issue is probably best dealt with at the SIP level when an MSRP issue is probably best dealt with at the SIP level when an MSRP
session is initiated and not at the MSRP level. session is initiated and not at the MSRP level.
If a sender chooses to employ S/MIME to protect a message, all S/MIME If a sender chooses to employ S/MIME to protect a message, all S/MIME
operations MUST occur prior to breaking the message into chunks, if operations apply to the complete message, prior to any breaking of
needed. the message into chunks.
The signaling will have set up the session to or from some specific The signaling will have set up the session to or from some specific
URLs that will often have "im:" or "sip:" URI schemes. When the URLs that will often have "im:" or "sip:" URI schemes. When the
signaling has been set up to a specific end user, and S/MIME is signaling has been set up to a specific end user, and S/MIME is
implemented, then the client needs to verify that the name in the implemented, then the client needs to verify that the name in the
SubjectAltName of the certificate contains an entry that matches the SubjectAltName of the certificate contains an entry that matches the
URI that was used for the other end in the signaling. There are some URI that was used for the other end in the signaling. There are some
cases, such as IM conferencing, where the S/MIME certificate name and cases, such as IM conferencing, where the S/MIME certificate name and
the signaled identity will not match. In these cases, the client the signaled identity will not match. In these cases, the client
should ensure that the user is informed that the message came from should ensure that the user is informed that the message came from
skipping to change at page 52, line 7 skipping to change at page 53, line 7
Code [RFC Number] Code [RFC Number]
The following information must be provided in an RFC publication in The following information must be provided in an RFC publication in
order to register a new MSRP Method: order to register a new MSRP Method:
The status code number. The status code number.
The RFC number in which the method is registered. The RFC number in which the method is registered.
15.4. MSRP Port 15.4. MSRP Port
MSRP uses TCP port XYZ, to be determined by IANA after this document MSRP uses TCP port XYZ. Usage of this value is described in
is approved for publication. Usage of this value is described in
Section 6. Section 6.
[NOTE TO IANA/RFC Editor: Please replace XYZ in this section with the [NOTE TO IANA/RFC Editor: Please replace XYZ in this section with the
assigned port number.] assigned port number.]
15.5. MSRP URL Schemes 15.5. MSRP URL Schemes
This document defines the URL schemes of "msrp" and "msrps". This document defines the URL schemes of "msrp" and "msrps".
Syntax: See Section 6. Syntax: See Section 6.
skipping to change at page 54, line 20 skipping to change at page 55, line 19
Miguel Garcia, Peter Ridler, Sam Hartman, and Jean Mahoney. Miguel Garcia, Peter Ridler, Sam Hartman, and Jean Mahoney.
17. References 17. References
17.1. Normative References 17.1. Normative References
[1] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [1] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", draft-ietf-mmusic-sdp-new-25 (work in Description Protocol", draft-ietf-mmusic-sdp-new-26 (work in
progress), July 2005. progress), July 2006.
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [4] 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.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 55, line 51 skipping to change at page 56, line 51
[20] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation [20] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation
Protocol Call Control - Transfer", Protocol Call Control - Transfer",
draft-ietf-sipping-cc-transfer-05 (work in progress), draft-ietf-sipping-cc-transfer-05 (work in progress),
July 2005. July 2005.
[21] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and [21] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002. Instant Messaging", RFC 3428, December 2002.
[22] Mahy, R., "Benefits and Motivation for Session Mode Instant [22] Jennings, C., Mahy, R., and A. , "Relay Extensions for Message
Messaging", draft-mahy-simple-why-session-mode-01 (work in
progress), February 2004.
[23] Jennings, C. and R. Mahy, "Relay Extensions for Message
Sessions Relay Protocol (MSRP)", Sessions Relay Protocol (MSRP)",
draft-ietf-simple-msrp-relays-05 (work in progress), July 2005. draft-ietf-simple-msrp-relays-07 (work in progress),
February 2006.
[24] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE [23] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002. Method", RFC 3311, October 2002.
[25] Jennings, C. and J. Peterson, "Certificate Management Service [24] Jennings, C. and J. Peterson, "Certificate Management Service
for SIP", draft-ietf-sipping-certs-02 (work in progress), for SIP", draft-ietf-sipping-certs-02 (work in progress),
July 2005. July 2005.
[26] Yon, D. and G. Camarillo, "Connection-Oriented Media Transport [25] Yon, D. and G. Camarillo, "Connection-Oriented Media Transport
in SDP", rfc 4145, September 2005. in SDP", rfc 4145, September 2005.
[27] Peterson, J., "A Common Profile for Instant Messaging (CPIM)", [26] Peterson, J., "A Common Profile for Instant Messaging (CPIM)",
rfc 3860, August 2004. rfc 3860, August 2004.
[28] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, [27] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217,
December 2001. December 2001.
[29] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone [28] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone
Generation in the Session Initiation Protocol (SIP)", rfc 3960, Generation in the Session Initiation Protocol (SIP)", rfc 3960,
December 2004. December 2004.
[30] Saint-Andre, P., "Extensible Messaging and Presence Protocol [29] Saint-Andre, P., "Extensible Messaging and Presence Protocol
(XMPP): Instant Messaging and Presence", RFC 3921, (XMPP): Instant Messaging and Presence", RFC 3921,
October 2004. October 2004.
[31] Rosenberg, J., "Indicating User Agent Capabilities in the [30] Rosenberg, J., "Indicating User Agent Capabilities in the
Session Initiation Protocol (SIP)", RFC 3840, August 2004. Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[32] Peterson, J., "Address Resolution for Instant Messaging and [31] Peterson, J., "Address Resolution for Instant Messaging and
Presence", rfc 3861, August 2004. Presence", rfc 3861, August 2004.
Authors' Addresses Authors' Addresses
Ben Campbell (editor) Ben Campbell (editor)
Estacado Systems Estacado Systems
17210 Campbell Road 17210 Campbell Road
Suite 250 Suite 250
Dallas, TX 75252 Dallas, TX 75252
USA USA
skipping to change at page 58, line 41 skipping to change at page 59, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 78 change blocks. 
165 lines changed or deleted 162 lines changed or added

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