draft-ietf-simple-message-sessions-12.txt   draft-ietf-simple-message-sessions-13.txt 
SIMPLE WG B. Campbell, Ed. SIMPLE WG B. Campbell, Ed.
Internet-Draft Estacado Systems Internet-Draft Estacado Systems
Expires: April 9, 2006 R. Mahy, Ed. Expires: June 24, 2006 R. Mahy, Ed.
blankespace SIP Edge, LLC
C. Jennings, Ed. C. Jennings, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
October 6, 2005 December 21, 2005
The Message Session Relay Protocol The Message Session Relay Protocol
draft-ietf-simple-message-sessions-12.txt draft-ietf-simple-message-sessions-13.txt
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 April 9, 2006. This Internet-Draft will expire on June 24, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . 17 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. Generate 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 . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . . . 29 8.5. Connection Negotiation . . . . . . . . . . . . . . . . . 30
8.6. Content Type Negotiation . . . . . . . . . . . . . . . . 30 8.6. Content Type Negotiation . . . . . . . . . . . . . . . . 30
8.7. Example SDP Exchange . . . . . . . . . . . . . . . . . . 31 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 . . . . . . . . . . . . . . . . . . . . . . . . 32 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 33
10. Response Code Descriptions . . . . . . . . . . . . . . . . . . 35 10. Response Code Descriptions . . . . . . . . . . . . . . . . . . 35
10.1. 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.1. 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.2. 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.2. 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.3. 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.3. 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.4. 408 . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 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. 426 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.9. 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.9. 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.10. 501 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.10. 501 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.11. 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 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 . . . . . . . . . . . . . . . 39 11.2. Message with XHTML Content . . . . . . . . . . . . . . . 40
11.3. Chunked Message . . . . . . . . . . . . . . . . . . . . . 39 11.3. Chunked Message . . . . . . . . . . . . . . . . . . . . . 40
11.4. System Message . . . . . . . . . . . . . . . . . . . . . 39 11.4. System Message . . . . . . . . . . . . . . . . . . . . . 40
11.5. Positive Report . . . . . . . . . . . . . . . . . . . . . 40 11.5. Positive Report . . . . . . . . . . . . . . . . . . . . . 41
11.6. Forked IM . . . . . . . . . . . . . . . . . . . . . . . . 40 11.6. Forked IM . . . . . . . . . . . . . . . . . . . . . . . . 41
12. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 44 12. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 44
13. CPIM Compatibility . . . . . . . . . . . . . . . . . . . . . . 44 13. CPIM Compatibility . . . . . . . . . . . . . . . . . . . . . . 44
14. Security Considerations . . . . . . . . . . . . . . . . . . . 45 14. Security Considerations . . . . . . . . . . . . . . . . . . . 45
14.1. Transport Level Protection . . . . . . . . . . . . . . . 45 14.1. Transport Level Protection . . . . . . . . . . . . . . . 45
14.2. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . 47 14.2. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . 47
14.3. Other Security Concerns . . . . . . . . . . . . . . . . . 47 14.3. Using TLS in Peer to Peer Mode . . . . . . . . . . . . . 47
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 14.4. Other Security Concerns . . . . . . . . . . . . . . . . . 49
15.1. MSRP Method Names . . . . . . . . . . . . . . . . . . . . 49 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
15.2. MSRP Header Fields . . . . . . . . . . . . . . . . . . . 49 15.1. MSRP Method Names . . . . . . . . . . . . . . . . . . . . 51
15.3. MSRP Status Codes . . . . . . . . . . . . . . . . . . . . 50 15.2. MSRP Header Fields . . . . . . . . . . . . . . . . . . . 51
15.4. MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 50 15.3. MSRP Status Codes . . . . . . . . . . . . . . . . . . . . 51
15.5. MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . 50 15.4. MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 52
15.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . 51 15.5. MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . 52
15.7. SDP Attribute Names . . . . . . . . . . . . . . . . . . . 51 15.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . 52
15.7.1. Accept Types . . . . . . . . . . . . . . . . . . . . . 51 15.7. SDP Attribute Names . . . . . . . . . . . . . . . . . . . 52
15.7.2. Wrapped Types . . . . . . . . . . . . . . . . . . . . 51 15.7.1. Accept Types . . . . . . . . . . . . . . . . . . . . . 52
15.7.3. Max Size . . . . . . . . . . . . . . . . . . . . . . . 52 15.7.2. Wrapped Types . . . . . . . . . . . . . . . . . . . . 53
15.7.4. Path . . . . . . . . . . . . . . . . . . . . . . . . . 52 15.7.3. Max Size . . . . . . . . . . . . . . . . . . . . . . . 53
16. Contributors and Acknowledgments . . . . . . . . . . . . . . . 52 15.7.4. Path . . . . . . . . . . . . . . . . . . . . . . . . . 53
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 16. Contributors and Acknowledgments . . . . . . . . . . . . . . . 53
17.1. Normative References . . . . . . . . . . . . . . . . . . 52 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
17.2. Informational References . . . . . . . . . . . . . . . . 53 17.1. Normative References . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 17.2. Informational References . . . . . . . . . . . . . . . . 55
Intellectual Property and Copyright Statements . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57
Intellectual Property and Copyright Statements . . . . . . . . . . 58
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
[19]. Session-mode messaging has a number of benefits [20] over [21]. Session-mode messaging has a number of benefits [22] over
page-mode messaging, however, such as explicit rendezvous, tighter page-mode messaging, however, such as explicit rendezvous, tighter
integration with other media types, direct client-to-client integration with other media types, direct client-to-client
operation, and brokered privacy and security. operation, and 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 [31] defines how DNS can be used When a user uses an IM URL, RFC 3861 [32] 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 [18] 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 [17] and conferencing [16] 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. However, work to
specify behavior for MSRP relay devices [21] (referred to herein as specify behavior for MSRP relay devices [23] (referred to herein as
"relays") is occurring as a separate effort. "relays") is occurring as a separate effort.
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
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 [25] into the addressing URIs or automatically translate im: URIs [27] 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 6, line 13 skipping to change at page 6, line 13
including using the sips mechanism to ensure transport security including using the sips mechanism to ensure transport security
across intermediaries and S/MIME for end-to-end protection of the SDP across intermediaries and S/MIME for end-to-end protection of the SDP
entity. SIP can carry arbitrary URIs (including im: URIs) in the entity. SIP can carry arbitrary URIs (including im: URIs) in the
Request-URI, and procedures are available to map im: URIs to sip: or Request-URI, and procedures are available to map im: URIs to sip: or
sips: URIs. It is expected that initial deployments of MSRP will use sips: URIs. It is expected that initial deployments of MSRP will use
SIP as its rendezvous mechanism. SIP as its rendezvous mechanism.
4. Protocol Overview 4. Protocol Overview
MSRP is a text-based, connection-oriented protocol for exchanging MSRP is a text-based, connection-oriented protocol for exchanging
arbitrary (binary) MIME content, especially instant messages. This arbitrary (binary) MIME[8] content, especially instant messages.
section is a non-normative overview of how MSRP works and how it is This section is a non-normative overview of how MSRP works and how it
used with SIP. is used with SIP.
MSRP sessions are typically arranged using SIP the same way a session MSRP sessions are typically arranged using SIP the same way a session
of audio or video media is set up. One SIP user agent (Alice) sends of audio or video media is set up. One SIP user agent (Alice) sends
the other (Bob) a SIP invitation containing an offered session- the other (Bob) a SIP invitation containing an offered session-
description which includes a session of MSRP. The receiving SIP user description which includes a session of MSRP. The receiving SIP user
agent can accept the invitation and include an answer session- agent can accept the invitation and include an answer session-
description which acknowledges the choice of media. Alice's session description which acknowledges the choice of media. Alice's session
description contains an MSRP URL that describes where she is willing description contains an MSRP URL that describes where she is willing
to receive MSRP requests from Bob, and vice-versa. (Note: Some lines to receive MSRP requests from Bob, and vice-versa. (Note: Some lines
in the examples are removed for clarity and brevity.) in the examples are removed for clarity and brevity.)
skipping to change at page 10, line 25 skipping to change at page 10, line 25
Byte-Range: 5-8/8 Byte-Range: 5-8/8
Content-Type: text/plain Content-Type: text/plain
EFGH EFGH
-------dkei38ia$ -------dkei38ia$
This chunking mechanism allows a sender to interrupt a chunk part of This chunking mechanism allows a sender to interrupt a chunk part of
the way through sending it. The ability to interrupt messages allows the way through sending it. The ability to interrupt messages allows
multiple sessions to share a TCP connection, and for large messages multiple sessions to share a TCP connection, and for large messages
to be sent efficiently while not blocking other messages that share to be sent efficiently while not blocking other messages that share
the same connection. Any chunk that is larger than 2048 octets MUST the same connection, or even the same MSRP session. Any chunk that
be interruptible. While MSRP would be simpler to implement if each is larger than 2048 octets MUST be interruptible. While MSRP would
MSRP session used its own TCP connection, that approach would be simpler to implement if each MSRP session used its own TCP
circumvent the congestion avoidance features of TCP. connection, that approach would circumvent the congestion avoidance
features of TCP.
The chunking mechanism only applies to the SEND method, as it is the
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 gateways or relays defined in the future, to
provide a complete path to the end recipient. When two MSRP nodes provide a complete path to the end recipient. When two MSRP nodes
communicate directly they need only one URL in the To-Path list and communicate directly they need only one URL in the To-Path list and
one URL in the From-Path list. 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 [29] gateway, it may forward the message over XMPP. an MSRP to XMPP [30] 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.
skipping to change at page 14, line 4 skipping to change at page 14, line 6
circumstances. circumstances.
If an endpoint attempts to re-create a failed session in this manner, If an endpoint attempts to re-create a failed session in this manner,
it MUST NOT assume that the MSRP URLs in the SDP will be the same as it MUST NOT assume that the MSRP URLs in the SDP will be the same as
the old ones. the old ones.
A connection SHOULD NOT be closed while there are sessions associated A connection SHOULD NOT be closed while there are sessions associated
with it. with it.
6. MSRP URLs 6. MSRP URLs
URLs using the MSRP and MSRPS schema are used to identify a session URLs using the MSRP and MSRPS schema are used to identify a session
of instant messages at a particular MSRP device. MSRP URLs are of instant messages at a particular MSRP device. MSRP URLs are
ephemeral; an MSRP device will generally use a different MSRP URL for ephemeral; an MSRP device will generally use a different MSRP URL for
each distinct session. An MSRP URL generally has no meaning outside each distinct session. An MSRP URL generally has no meaning outside
of the associated session. of the associated session.
An MSRP URL follows a subset of the URL syntax in Appendix A of An MSRP URL follows a subset of the URL syntax in Appendix A of
RFC3986 [9], with a scheme of "msrp" or "msrps". The syntax is RFC3986 [10], with a scheme of "msrp" or "msrps". The syntax is
described in Section 9. described in Section 9.
The constructions for "userinfo", and "unreserved" are detailed in The constructions for "userinfo", and "unreserved" are detailed in
RFC3986 [9]. In order to allow IPV6 addressing, the construction for RFC3986 [10]. In order to allow IPV6 addressing, the construction
hostport is that used for SIP in RFC3261. URLs designating MSRP over for hostport is that used for SIP in RFC3261. URLs designating MSRP
TCP MUST include the "tcp" transport parameter. over TCP MUST include the "tcp" transport parameter.
Since this document only specifies MSRP over TCP, all MSRP URLs Since this document only specifies MSRP over TCP, all MSRP URLs
herein use the "tcp" transport parameter. Documents that provide herein use the "tcp" transport parameter. Documents that provide
bindings on other transports should define respective parameters bindings on other transports should define respective parameters
for those transports. for those transports.
An MSRP URL hostport field identifies a participant in a particular An MSRP URL hostport field identifies a participant in a particular
MSRP session. If the hostport contains a numeric IP address, it MUST MSRP session. If the hostport contains a numeric IP address, it MUST
also contain a port. The session-id part identifies a particular also contain a port. The session-id part identifies a particular
session of the participant. The absence of the session-id part session of the participant. The absence of the session-id part
skipping to change at page 16, line 13 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 [21] may describe additional steps to resolve relay specification [23] 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 35 skipping to change at page 16, line 39
To form a new request, the sender creates a unique transaction To form a new request, the sender creates a unique transaction
identifier and uses this and the method name to create an MSRP identifier and uses this and the method name to create an MSRP
request start line. Next, the sender places the target URL in a To- request start line. Next, the sender places the target URL in a To-
Path header field, and the sender's URL in a From-Path header field. Path header field, and the sender's URL in a From-Path header field.
If multiple URLs are present in the To-Path, the leftmost is the If multiple URLs are present in the To-Path, the leftmost is the
first URL visited; the rightmost URL is the last URL visited. The first URL visited; the rightmost URL is the last URL visited. The
processing then becomes method specific. Additional method-specific processing then becomes method specific. Additional method-specific
header fields are added as described in the following sections. header fields are added as described in the following sections.
After any method-specific header fields are added, processing After any method-specific header fields are added, processing
continues to handle a body, if present. A body in a non-SEND request continues to handle a body, if present. If the request has a body,
MUST NOT be longer than 2048 octets. If the request has a body, it it must contain a Content-Type header field. It may contain other
must contain a Content-Type header field. It may contain other MIME- MIME-specific header fields. The Content-Type header field MUST be
specific header fields. The Content-Type header field MUST be the the last field in the message header section. The body MUST be
last field in the message header section. The body MUST be separated separated from the header fields with an extra CRLF.
from the header fields with an extra CRLF.
Non-SEND requests are not intended to carry message content, and are
therefore not interruptible. Non-SEND request bodies MUST NOT be
larger than 10240 octets.
ALthough this document does discuss any particular usage of bodies
in non-SEND requests, they may be useful in the future for
carrying security or identity information, information about a
message in progress, etc. The 10K size limit was chosen to be
large enough for most of such applications, but small enough to
avoid the fairness issues caused by sending arbitrarily large
content in non-interuptible 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
skipping to change at page 20, line 19 skipping to change at page 20, line 30
scheme to alternate between them such that each concurrent request scheme to alternate between them such that each concurrent request
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 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 is a binary protocol, transfer encoding is always
"binary", and transfer-encoding parameters MUST NOT be present. "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.
skipping to change at page 20, line 41 skipping to change at page 21, line 4
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.
Since REPORT requests are not interruptible, the size of such a body
MUST NOT exceed 2048 octets. REPORT requests are not interruptible.
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
skipping to change at page 22, line 15 skipping to change at page 22, line 27
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 [21]. We document, and will be considered in a separate document [23]. 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 28, line 34 skipping to change at page 28, line 47
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 [21]. In order to allow an MSRP are described in a separate document [23]. 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 24 skipping to change at page 29, line 37
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 (the peer URL) attribute MUST exhibit the uniqueness
properties described above. Uniqueness requirements for other properties described above. Uniqueness requirements for other
entries in the attribute are out of scope for this document. entries in the 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. They may need to change some other stream in a session timers or the SIP UPDATE[24] request. They may need to
session without affecting the MSRP stream, or they may need to change change some other stream in a session without affecting the MSRP
an MSRP stream without affecting some other stream. stream, or they may need to change an MSRP stream without affecting
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 [24] work being done in the MMUSIC loosely based on the COMEDIA [26] 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 38 skipping to change at page 33, line 4
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 [28] than one endpoint receiving the same INVITE. SIP early media [29]
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 41, line 8 skipping to change at page 41, line 47
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, "pager-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 [30]. As a result, host that implements callee capabilities [31]. 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 44, line 31 skipping to change at page 44, line 31
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 [25] compatible MSRP sessions may go to a gateway to other CPIM [27] 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
type, and SHOULD support the S/MIME features of that format. type, and SHOULD support the S/MIME[7] features of that format.
If a message is to be wrapped in a message/cpim envelope, the If a message is to be wrapped in a message/cpim envelope, the
wrapping MUST be done prior to breaking the message into chunks, if wrapping MUST be done prior to breaking the message into chunks, if
needed. needed.
All MSRP endpoints MUST recognize the From, To, DateTime, and Require All MSRP endpoints MUST recognize the From, To, DateTime, and Require
header fields as defined in RFC3862. Such applications SHOULD header fields as defined in RFC3862. Such applications SHOULD
recognize the CC header field, and MAY recognize the Subject header recognize the CC header field, and MAY recognize the Subject header
field. Any MSRP application that recognizes any message/cpim header field. Any MSRP application that recognizes any message/cpim header
field MUST understand the NS (name space) header field. field MUST understand the NS (name space) header field.
skipping to change at page 46, line 26 skipping to change at page 46, line 26
from a well-known certificate authority. Furthermore, we assume that from a well-known certificate authority. Furthermore, we assume that
the signaling to set up the session is protected by the rendezvous the signaling to set up the session is protected by the rendezvous
protocol. In this case, when host A contacts host B, the secret is protocol. In this case, when host A contacts host B, the secret is
passed through a confidential channel to A. A connects with TLS to B. passed through a confidential channel to A. A connects with TLS to B.
B presents a valid certificate, so A knows it really is connected to B presents a valid certificate, so A knows it really is connected to
B. A then delivers the secret provided by B, so that B can verify it B. A then delivers the secret provided by B, so that B can verify it
is connected to A. In this case, a rogue SIP Proxy can see the secret is connected to A. In this case, a rogue SIP Proxy can see the secret
in the SIP signaling traffic and could potentially insert itself as a in the SIP signaling traffic and could potentially insert itself as a
man-in-the-middle. man-in-the-middle.
Realistically, using TLS is difficult for peer-to-peer connections, Realistically, using TLS with certificates from well known
as the types of hosts that end clients use for sending instant certificate authorities is difficult for peer-to-peer connections, as
messages are unlikely to have long-term stable IP addresses or DNS the types of hosts that end clients use for sending instant messages
names that certificates can bind to. In addition, the cost of server are unlikely to have long-term stable IP addresses or DNS names that
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. While not expensive enough to discourage their use for each client. Using TLS
in scope for this document, using TLS with a DH profile is possible. in a peer-to-peer mode without well known certificate is discussed in
section 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 [21]. That document makes extensive use of TLS to companion document [23]. 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 [10]. 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).
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 [26] provided in the session setup. MSRP is a binary shared secret [28] provided in the session setup. MSRP is a binary
protocol and MIME bodies MUST be transferred with a transfer encoding protocol and MIME bodies MUST be transferred with a transfer encoding
of binary. If a message is both signed and encrypted, it SHOULD be of binary. If a message is both signed and encrypted, it SHOULD be
signed first, then encrypted. If S/MIME is supported, SHA-1, RSA, signed first, then encrypted. If S/MIME is supported, SHA-1, RSA,
and AES-128 MUST be supported. 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 [22] and Certificates [23] mechanisms provide S/MIME based Identity [16] and Certificates [25] 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
symmetric keying material to be used with S/MIME for integrity and symmetric keying material to be used with S/MIME for integrity and
privacy. privacy.
14.3. Other Security Concerns 14.3. Using TLS in Peer to Peer Mode
TLS can be used with a self signed certificate as long as there is a
mechanism for both sides to ascertain that the other side used the
correct certificate. When used with SDP and SIP, the correct
certificate can be verified by passing a fingerprint of the
certificate in the SDP and ensuring that the SDP has suitable
integrity protection. When SIP is used to transport the SDP, the
integrity can be provided by the SIP Identity mechanism[16]. The
rest of this section describes the details of this approach.
If self-signed certificates are used, the content of the
subjectAltName attribute inside the certificate MAY use the uniform
resource identifier (URI) of the user. In SIP, this URI of the user
is the User's Address of Record (AOR). This is useful for debugging
purposes only and is not required to bind the certificate to one of
the communication endpoints. Unlike normal TLS operations in this
protocol, when doing peer to peer TLS, the subjectAltName is not an
important component of the certificate verification. If the endpoint
is also able to make anonymous sessions, a distinct, unique
certificate MUST be used for this purpose. For a client that works
with multiple users, each user SHOULD have its own certificate.
Because the generation of public/private key pairs is relatively
expensive, endpoints are not required to generate certificates for
each session.
A certificate fingerprint is the output of a one-way hash function
computed over the distinguished encoding rules (DER) form of the
certificate. The endpoint MUST use the certificate fingerprint
attribute as specified in [17] and MUST include this in the SDP. The
certificate presented during the TLS handshake needs to match the
fingerprint exchanged via the SDP and if the fingerprint does not
match the hashed certificate then the endpoint MUST tear down the
media session immediately.
When using SIP, the integrity of the fingerprint can be ensured
through the SIP Identity mechanism [16]. When a client wishes to use
SIP to set up a secure MSRP session with another endpoint it sends an
offer in a SIP message to the other endpoint. This offer includes,
as part of the SDP payload, the fingerprint of the certificate that
the endpoint wants to use. The SIP message containing the offer is
sent to the offerer's sip proxy which will add an identity header
according to the procedures outlined in [16]. When the far endpoint
receives the SIP message it can verify the identity of the sender
using the identity header. Since the identity header is a digital
signature across several SIP headers, in addition to the body or
bodies of the SIP message, the receiver can also be certain that the
message has not been tampered with after the digital signature was
added to the SIP message.
An example of SDP with a fingerprint attribute is shown in the
following figure. Note the fingerprint is shown spread over two
lines due to formatting consideration but should all be on one line.
c=IN IP4 atlanta.example.com
m=message 7654 TCP/TLS/MSRP *
a=accept-types:text/plain
a=path:msrp://atlanta.example.com:7654/jshA7we;tcp
a=fingerprint:SHA-1 \
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
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, Eve, sends a SIP INVITE with no offer to
Alice. Alice returns a 200 with an offer and Eve returns an answer Alice. Alice returns a 200 with an offer and Eve returns an answer
with SDP indicating that her MSRP address is the address of Tom. with SDP indicating that her MSRP address is the address of Tom.
Since Alice sent the offer, Alice will initiate a connection to Tom Since Alice sent the offer, Alice will initiate a connection to Tom
using up resources on Tom's server. Given the huge number of IM 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.
skipping to change at page 52, line 47 skipping to change at page 54, line 20
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-23 (work in Description Protocol", draft-ietf-mmusic-sdp-new-25 (work in
progress), December 2004. progress), July 2005.
[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.
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004.
[8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies", Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996. RFC 2045, November 1996.
[8] Troost, R., Dorner, S., and K. Moore, "Communicating [9] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Content- Presentation Information in Internet Messages: The Content-
Disposition header field", RFC 2183, August 1997. Disposition header field", RFC 2183, August 1997.
[9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 3986, Resource Identifiers (URI): Generic Syntax", RFC 3986,
January 2005. January 2005.
[10] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and [11] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
T. Wright, "Transport Layer Security (TLS) Extensions", T. Wright, "Transport Layer Security (TLS) Extensions",
RFC 3546, June 2003. RFC 3546, June 2003.
[11] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[12] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging [12] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging
(CPIM): Message Format", RFC 3862, August 2004. (CPIM): Message Format", RFC 3862, August 2004.
[13] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for [13] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 3268, June 2002. Transport Layer Security (TLS)", RFC 3268, June 2002.
[14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [14] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 3629, November 2003. RFC 3629, November 2003.
[15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", rfc 2046, Extensions (MIME) Part Two: Media Types", rfc 2046,
November 1996. November 1996.
[16] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-06 (work in progress), October 2005.
[17] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", draft-ietf-mmusic-comedia-tls-05
(work in progress), September 2005.
17.2. Informational References 17.2. Informational References
[16] Johnston, A. and O. Levin, "Session Initiation Protocol Call [18] Johnston, A. and O. Levin, "Session Initiation Protocol Call
Control - Conferencing for User Agents", Control - Conferencing for User Agents",
draft-ietf-sipping-cc-conferencing-05 (work in progress), draft-ietf-sipping-cc-conferencing-07 (work in progress),
October 2004. June 2005.
[17] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, [19] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
"Best Current Practices for Third Party Call Control in the "Best Current Practices for Third Party Call Control in the
Session Initiation Protocol", RFC 3725, April 2004. Session Initiation Protocol", RFC 3725, April 2004.
[18] Sparks, R. and A. Johnston, "Session Initiation Protocol Call [20] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation
Control - Transfer", draft-ietf-sipping-cc-transfer-03 (work in Protocol Call Control - Transfer",
progress), October 2004. draft-ietf-sipping-cc-transfer-05 (work in progress),
July 2005.
[19] 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.
[20] Mahy, R., "Benefits and Motivation for Session Mode Instant [22] Mahy, R., "Benefits and Motivation for Session Mode Instant
Messaging", draft-mahy-simple-why-session-mode-01 (work in Messaging", draft-mahy-simple-why-session-mode-01 (work in
progress), February 2004. progress), February 2004.
[21] Jennings, C. and R. Mahy, "Relay Extensions for Message [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-05 (work in progress), July 2005.
[22] Peterson, J. and C. Jennings, "Enhancements for Authenticated [24] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Identity Management in the Session Initiation Protocol (SIP)", Method", RFC 3311, October 2002.
draft-ietf-sip-identity-03 (work in progress), September 2004.
[23] Jennings, C. and J. Peterson, "Certificate Management Service [25] Jennings, C. and J. Peterson, "Certificate Management Service
for SIP", draft-ietf-sipping-certs-00 (work in progress), for SIP", draft-ietf-sipping-certs-02 (work in progress),
October 2004. July 2005.
[24] Yon, D., "Connection-Oriented Media Transport in SDP", [26] Yon, D. and G. Camarillo, "Connection-Oriented Media Transport
draft-ietf-mmusic-sdp-comedia-09 (work in progress), in SDP", rfc 4145, September 2005.
September 2004.
[25] Peterson, J., "A Common Profile for Instant Messaging (CPIM)", [27] Peterson, J., "A Common Profile for Instant Messaging (CPIM)",
rfc 3860, August 2004. rfc 3860, August 2004.
[26] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, [28] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217,
December 2001. December 2001.
[27] Ramsdell, B., "S/MIME Version 3 Message Specification", [29] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone
RFC 2633, June 1999. Generation in the Session Initiation Protocol (SIP)", rfc 3960,
December 2004.
[28] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone
Generation in the Session Initiation Protocol (SIP)",
draft-ietf-sipping-early-media-02 (work in progress),
June 2004.
[29] Saint-Andre, P., "Extensible Messaging and Presence Protocol [30] 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.
[30] Rosenberg, J., "Indicating User Agent Capabilities in the [31] Rosenberg, J., "Indicating User Agent Capabilities in the
Session Initiation Protocol (SIP)", RFC 3840, August 2004. Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[31] Peterson, J., "Address Resolution for Instant Messaging and [32] 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
Email: ben@estacado.net Email: ben@estacado.net
Rohan Mahy (editor) Rohan Mahy (editor)
blankespace SIP Edge, LLC
Email: rohan@ekabal.com Email: rohan@ekabal.com
Cullen Jennings (editor) Cullen Jennings (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Dr. 170 West Tasman Dr.
MS: SJC-21/2 MS: SJC-21/2
San Jose, CA 95134 San Jose, CA 95134
USA USA
 End of changes. 69 change blocks. 
129 lines changed or deleted 215 lines changed or added

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