draft-ietf-simple-message-sessions-15.txt   draft-ietf-simple-message-sessions-16.txt 
Network Working Group B. Campbell, Ed. Network Working Group B. Campbell, Ed.
Internet-Draft Estacado Systems Internet-Draft Estacado Systems
Expires: December 26, 2006 R. Mahy, Ed. Intended status: Standards Track R. Mahy, Ed.
Plantronics Expires: April 25, 2007 Plantronics
C. Jennings, Ed. C. Jennings, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
June 24, 2006 October 22, 2006
The Message Session Relay Protocol The Message Session Relay Protocol
draft-ietf-simple-message-sessions-15 draft-ietf-simple-message-sessions-16
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 December 26, 2006. This Internet-Draft will expire on April 25, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). 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
skipping to change at page 2, line 14 skipping to change at page 2, line 14
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 . . . . . . . . . . . . 11
5.4. MSRP Connection Model . . . . . . . . . . . . . . . . . . 12 5.4. MSRP Connection Model . . . . . . . . . . . . . . . . . . 12
6. MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. MSRP URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 15 6.1. MSRP URI Comparison . . . . . . . . . . . . . . . . . . . 15
6.2. Resolving MSRP Host Device . . . . . . . . . . . . . . . 16 6.2. Resolving MSRP Host Device . . . . . . . . . . . . . . . 16
7. Method-Specific Behavior . . . . . . . . . . . . . . . . . . . 16 7. Method-Specific Behavior . . . . . . . . . . . . . . . . . . . 17
7.1. Constructing Requests . . . . . . . . . . . . . . . . . . 16 7.1. Constructing Requests . . . . . . . . . . . . . . . . . . 17
7.1.1. Sending SEND Requests . . . . . . . . . . . . . . . . 18 7.1.1. Sending SEND Requests . . . . . . . . . . . . . . . . 18
7.1.2. Sending REPORT Requests . . . . . . . . . . . . . . . 21 7.1.2. Sending REPORT Requests . . . . . . . . . . . . . . . 21
7.1.3. Generating Success Reports . . . . . . . . . . . . . . 21 7.1.3. Generating Success Reports . . . . . . . . . . . . . . 22
7.1.4. Generating Failure Reports . . . . . . . . . . . . . . 22 7.1.4. Generating Failure Reports . . . . . . . . . . . . . . 23
7.2. Constructing Responses . . . . . . . . . . . . . . . . . 23 7.2. Constructing Responses . . . . . . . . . . . . . . . . . 24
7.3. Receiving Requests . . . . . . . . . . . . . . . . . . . 24 7.3. Receiving Requests . . . . . . . . . . . . . . . . . . . 25
7.3.1. Receiving SEND Requests . . . . . . . . . . . . . . . 24 7.3.1. Receiving SEND Requests . . . . . . . . . . . . . . . 25
7.3.2. Receiving REPORT Requests . . . . . . . . . . . . . . 26 7.3.2. Receiving REPORT Requests . . . . . . . . . . . . . . 26
8. Using MSRP with SIP and SDP . . . . . . . . . . . . . . . . . 27 8. Using MSRP with SIP and SDP . . . . . . . . . . . . . . . . . 27
8.1. SDP Connection and Media Lines . . . . . . . . . . . . . 27 8.1. SDP Connection and Media Lines . . . . . . . . . . . . . 28
8.2. URL Negotiations . . . . . . . . . . . . . . . . . . . . 28 8.2. URI Negotiations . . . . . . . . . . . . . . . . . . . . 29
8.3. Path Attributes with Multiple URLs . . . . . . . . . . . 29 8.3. Path Attributes with Multiple URIs . . . . . . . . . . . 30
8.4. Updated SDP Offers . . . . . . . . . . . . . . . . . . . 30 8.4. Updated SDP Offers . . . . . . . . . . . . . . . . . . . 30
8.5. Connection Negotiation . . . . . . . . . . . . . . . . . 30 8.5. Connection Negotiation . . . . . . . . . . . . . . . . . 31
8.6. Content Type Negotiation . . . . . . . . . . . . . . . . 31 8.6. Content Type Negotiation . . . . . . . . . . . . . . . . 31
8.7. Example SDP Exchange . . . . . . . . . . . . . . . . . . 32 8.7. Example SDP Exchange . . . . . . . . . . . . . . . . . . 33
8.8. MSRP User Experience with SIP . . . . . . . . . . . . . . 33 8.8. MSRP User Experience with SIP . . . . . . . . . . . . . . 34
8.9. SDP direction attribute and MSRP . . . . . . . . . . . . 34 8.9. SDP direction attribute and MSRP . . . . . . . . . . . . 34
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 34 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 35
10. Response Code Descriptions . . . . . . . . . . . . . . . . . . 36 10. Response Code Descriptions . . . . . . . . . . . . . . . . . . 37
10.1. 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.1. 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.2. 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.2. 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.3. 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.3. 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.4. 408 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.4. 408 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.5. 413 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.5. 413 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.6. 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.6. 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.7. 423 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.7. 423 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.8. 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.8. 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.9. 501 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.9. 501 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.10. 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.10. 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Basic IM Session . . . . . . . . . . . . . . . . . . . . 38 11.1. Basic IM Session . . . . . . . . . . . . . . . . . . . . 39
11.2. Message with XHTML Content . . . . . . . . . . . . . . . 41 11.2. Message with XHTML Content . . . . . . . . . . . . . . . 41
11.3. Chunked Message . . . . . . . . . . . . . . . . . . . . . 41 11.3. Chunked Message . . . . . . . . . . . . . . . . . . . . . 42
11.4. System Message . . . . . . . . . . . . . . . . . . . . . 41 11.4. Chunked Message with message/cpim payload . . . . . . . . 42
11.5. Positive Report . . . . . . . . . . . . . . . . . . . . . 42 11.5. System Message . . . . . . . . . . . . . . . . . . . . . 43
11.6. Forked IM . . . . . . . . . . . . . . . . . . . . . . . . 42 11.6. Positive Report . . . . . . . . . . . . . . . . . . . . . 44
12. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 45 11.7. Forked IM . . . . . . . . . . . . . . . . . . . . . . . . 44
13. CPIM Compatibility . . . . . . . . . . . . . . . . . . . . . . 45 12. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 47
14. Security Considerations . . . . . . . . . . . . . . . . . . . 46 13. CPIM Compatibility . . . . . . . . . . . . . . . . . . . . . . 47
14.1. Transport Level Protection . . . . . . . . . . . . . . . 46 14. Security Considerations . . . . . . . . . . . . . . . . . . . 48
14.2. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . 48 14.1. Secrecy of the MSRP URI . . . . . . . . . . . . . . . . . 49
14.3. Using TLS in Peer to Peer Mode . . . . . . . . . . . . . 48 14.2. Transport Level Protection . . . . . . . . . . . . . . . 49
14.4. Other Security Concerns . . . . . . . . . . . . . . . . . 50 14.3. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . 50
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 14.4. Using TLS in Peer-to-Peer Mode . . . . . . . . . . . . . 51
15.1. MSRP Method Names . . . . . . . . . . . . . . . . . . . . 52 14.5. Other Security Concerns . . . . . . . . . . . . . . . . . 52
15.2. MSRP Header Fields . . . . . . . . . . . . . . . . . . . 52 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
15.3. MSRP Status Codes . . . . . . . . . . . . . . . . . . . . 52 15.1. MSRP Method Names . . . . . . . . . . . . . . . . . . . . 54
15.4. MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 53 15.2. MSRP Header Fields . . . . . . . . . . . . . . . . . . . 54
15.5. MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . 53 15.3. MSRP Status Codes . . . . . . . . . . . . . . . . . . . . 55
15.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . 53 15.4. MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 55
15.7. SDP Attribute Names . . . . . . . . . . . . . . . . . . . 53 15.5. URI Schema . . . . . . . . . . . . . . . . . . . . . . . 55
15.7.1. Accept Types . . . . . . . . . . . . . . . . . . . . . 53 15.5.1. MSRP Scheme . . . . . . . . . . . . . . . . . . . . . 55
15.7.2. Wrapped Types . . . . . . . . . . . . . . . . . . . . 54 15.5.2. MSRPS Scheme . . . . . . . . . . . . . . . . . . . . . 56
15.7.3. Max Size . . . . . . . . . . . . . . . . . . . . . . . 54 15.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . 56
15.7.4. Path . . . . . . . . . . . . . . . . . . . . . . . . . 54 15.7. SDP Attribute Names . . . . . . . . . . . . . . . . . . . 57
16. Contributors and Acknowledgments . . . . . . . . . . . . . . . 55 15.7.1. Accept Types . . . . . . . . . . . . . . . . . . . . . 57
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 15.7.2. Wrapped Types . . . . . . . . . . . . . . . . . . . . 57
17.1. Normative References . . . . . . . . . . . . . . . . . . 55 15.7.3. Max Size . . . . . . . . . . . . . . . . . . . . . . . 57
17.2. Informational References . . . . . . . . . . . . . . . . 56 15.7.4. Path . . . . . . . . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58 16. Contributors and Acknowledgments . . . . . . . . . . . . . . . 58
Intellectual Property and Copyright Statements . . . . . . . . . . 59 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
17.1. Normative References . . . . . . . . . . . . . . . . . . 58
17.2. Informational References . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61
Intellectual Property and Copyright Statements . . . . . . . . . . 62
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 over page-mode [22]. Session-mode messaging has a number of benefits over page-mode
messaging, however, such as explicit rendezvous, tighter integration messaging, however, such as explicit rendezvous, tighter integration
with other media types, direct client-to-client operation, and with other media-types, direct client-to-client 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 [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 URIs
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 [21] 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 [20] and conferencing [19] 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. MSRP relay devices that is, sessions crossing only a single hop. MSRP relay devices
[22] (referred to herein as "relays") are specified in a separate [23] (referred to herein as "relays") are specified in a separate
document. document. An endpoint that implements this specification, but not
the relay specification, will be unable to introduce relays into the
message path, but will still be able to interoperate with peers that
do use relays.
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
the complete message is called a "chunk". the complete message is called a "chunk".
3. Applicability of MSRP 3. Applicability of MSRP
MSRP is not designed for use as a standalone protocol. MSRP MUST be MSRP is not designed for use as a standalone protocol. MSRP MUST be
used only in the context of a rendezvous mechanism meeting the used only in the context of a rendezvous mechanism meeting the
following requirements: following requirements:
The rendezvous mechanism MUST provide both MSRP URLs associated o The rendezvous mechanism MUST provide both MSRP URIs associated
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 protect the rendezvous mechanism MUST implement mechanisms to protect the
confidentiality of these URLs - they MUST NOT be made available to confidentiality of these URIs - they MUST NOT be made available to
an untrusted third party or be easily discoverable. an untrusted third party or be easily discoverable.
The rendezvous mechanism MUST provide mechanisms for the o 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: o The rendezvous mechanism MUST be able to natively transport im:
URIs or automatically translate im: URIs [26] 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 URIs 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. URIs 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.
This SDP can be secured using any of the mechanisms available in SIP, This SDP can be secured using any of the mechanisms available in SIP,
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
body. SIP can carry arbitrary URIs (including im: URIs) in the body. 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
skipping to change at page 6, line 23 skipping to change at page 6, line 27
arbitrary (binary) MIME[8] content, especially instant messages. arbitrary (binary) MIME[8] content, especially instant messages.
This section is a non-normative overview of how MSRP works and how it This section is a non-normative overview of how MSRP works and how it
is 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 URI 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.)
Alice sends to Bob: Alice sends to Bob:
INVITE sip:bob@biloxi.example.com SIP/2.0 INVITE sip:bob@biloxi.example.com SIP/2.0
To: <sip:bob@biloxi.example.com> To: <sip:bob@biloxi.example.com>
From: <sip:alice@atlanta.example.com>;tag=786 From: <sip:alice@atlanta.example.com>;tag=786
Call-ID: 3413an89KU Call-ID: 3413an89KU
Content-Type: application/sdp Content-Type: application/sdp
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
m=message 7654 TCP/MSRP * m=message 7654 TCP/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/jshA7weztas;tcp
Bob sends to Alice: Bob sends to Alice:
SIP/2.0 200 OK SIP/2.0 200 OK
To: <sip:bob@biloxi.example.com>;tag=087js To: <sip:bob@biloxi.example.com>;tag=087js
From: <sip:alice@atlanta.example.com>;tag=786 From: <sip:alice@atlanta.example.com>;tag=786
Call-ID: 3413an89KU Call-ID: 3413an89KU
Content-Type: application/sdp Content-Type: application/sdp
c=IN IP4 biloxi.example.com c=IN IP4 biloxi.example.com
m=message 12763 TCP/MSRP * m=message 12763 TCP/MSRP *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrp://biloxi.example.com:12763/kjhd37s2s2;tcp a=path:msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
Alice sends to Bob: Alice sends to Bob:
ACK sip:bob@biloxi SIP/2.0 ACK sip:bob@biloxi SIP/2.0
To: <sip:bob@biloxi.example.com>;tag=087js To: <sip:bob@biloxi.example.com>;tag=087js
From: <sip:alice@atlanta.example.com>;tag=786 From: <sip:alice@atlanta.example.com>;tag=786
Call-ID: 3413an89KU Call-ID: 3413an89KU
Figure 1: Session Setup
MSRP defines two request types, or methods. SEND requests are used MSRP defines two request types, or methods. SEND requests are used
to deliver a complete message or a chunk (a portion of a complete to deliver a complete message or a chunk (a portion of a complete
message), while REPORT requests report on the status of a previously message), while REPORT requests report on the status of a previously
sent message, or a range of bytes inside a message. When Alice sent message, or a range of bytes inside a message. When Alice
receives Bob's answer, she checks to see if she has an existing receives Bob's answer, she checks to see if she has an existing
connection to Bob. If not, she opens a new connection to Bob using connection to Bob. If not, she opens a new connection to Bob using
the URL he provided in the SDP. Alice then delivers a SEND request the URI he provided in the SDP. Alice then delivers a SEND request
to Bob with her initial message, and Bob replies indicating that to Bob with her initial message, and Bob replies indicating that
Alice's request was received successfully. Alice's request was received successfully.
MSRP a786hjs2 SEND MSRP a786hjs2 SEND
To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp To-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp From-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: 87652 Message-ID: 87652491
Byte-Range: 1-25/25 Byte-Range: 1-25/25
Content-Type: text/plain Content-Type: text/plain
Hey Bob, are you there? Hey Bob, are you there?
-------a786hjs2$ -------a786hjs2$
MSRP a786hjs2 200 OK MSRP a786hjs2 200 OK
To-Path: msrp://atlanta.example.com:7654/jshA7we;tcp To-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp From-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
Byte-Range: 1-25/25 Byte-Range: 1-25/25
-------a786hjs2$ -------a786hjs2$
Figure 2: Example MSRP Exchange
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 URIs 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 URI 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 URI 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 of seven hyphens, the transaction identifier and a "$" to line of seven hyphens, the transaction identifier and a "$" to
indicate 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
skipping to change at page 8, line 48 skipping to change at page 8, line 50
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.
Alice can also specify what type of reporting she would like in Alice can also specify what type of reporting she would like in
response to her request. If Alice requests positive acknowledgments, response to her request. If Alice requests positive acknowledgments,
Bob sends a REPORT request to Alice confirming the delivery of her Bob sends a REPORT request to Alice confirming the delivery of her
complete message. This is especially useful if Alice sent a series complete message. This is especially useful if Alice sent a series
of SEND request containing chunks of a single message. More on of SEND request containing chunks of a single message. More on
requesting types of reports and errors is described in Section 5.3. requesting types of reports and errors is described in Section 5.3.
Alice and Bob generally choose their MSRP URLs in such a way that is Alice and Bob choose their MSRP URIs in such a way that is difficult
difficult to guess the exact URL. Alice and Bob can reject requests to guess the exact URI. Alice and Bob can reject requests to URIs
to URLs they are not expecting to service, and can correlate the they are not expecting to service, and can correlate the specific URI
specific URL with the probable sender. Alice and Bob can also use with the probable sender. Alice and Bob can also use TLS [1] to
TLS [1] to provide channel security over this hop. To receive MSRP provide channel security over this hop. To receive MSRP requests
requests over a TLS protected connection, Alice or Bob could over a TLS protected connection, Alice or Bob could advertise URIs
advertise URLs with the "msrps" scheme instead of "msrp." with the "msrps" scheme instead of "msrp."
MSRP is designed with the expectation that MSRP can carry URLs for MSRP is designed with the expectation that MSRP can carry URIs for
nodes on the far side of relays. For this reason, a URL with the nodes on the far side of relays. For this reason, a URI with the
"msrps" scheme makes no assertion about the security properties of "msrps" scheme makes no assertion about the security properties of
other hops, just the next hop. The user agent knows the URL for each other hops, just the next hop. The user agent knows the URI for each
hop, so it can verify that each URL has the desired security hop, so it can verify that each URI has the desired security
properties. properties.
MSRP URLs are discussed in more detail in Section 6. MSRP URIs are discussed in more detail in Section 6.
An adjacent pair of busy MSRP nodes (for example two relays) can An adjacent pair of busy MSRP nodes (for example two relays) can
easily have several sessions, and exchange traffic for several easily have several sessions, and exchange traffic for several
simultaneous users. The nodes can use existing connections to carry simultaneous users. The nodes can use existing connections to carry
new traffic with the same destination host, port, transport protocol, new traffic with the same destination host, port, transport protocol,
and scheme. MSRP nodes can keep track of how many sessions are using and scheme. MSRP nodes can keep track of how many sessions are using
a particular connection and close these connections when no sessions a particular connection and close these connections when no sessions
have used them for some period of time. Connection management is have used them for some period of time. Connection management is
discussed in more detail in Section 5.4. discussed in more detail in Section 5.4.
skipping to change at page 10, line 6 skipping to change at page 10, line 6
the end-line, there is a flag that indicates whether this is the last the end-line, there is a flag that indicates whether this is the last
chunk of data for this message or whether the message will be chunk of data for this message or whether the message will be
continued in a subsequent chunk. There is also a Byte-Range header continued in a subsequent chunk. There is also a Byte-Range header
field in the request that indicates that the overall position of this field in the request that indicates that the overall position of this
chunk inside the complete message. chunk inside the complete message.
For example, the following snippet of two SEND requests demonstrates For example, the following snippet of two SEND requests demonstrates
a message that contains the text "abcdEFGH" being sent as two chunks. a message that contains the text "abcdEFGH" being sent as two chunks.
MSRP dkei38sd SEND MSRP dkei38sd SEND
Message-ID: 456 Message-ID: 4564dpWd
Byte-Range: 1-4/8 Byte-Range: 1-*/8
Content-Type: text/plain Content-Type: text/plain
abcd abcd
-------dkei38sd+ -------dkei38sd+
MSRP dkei38ia SEND MSRP dkei38ia SEND
Message-ID: 456 Message-ID: 4564dpWd
Byte-Range: 5-8/8 Byte-Range: 5-8/8
Content-Type: text/plain Content-Type: text/plain
EFGH EFGH
-------dkei38ia$ -------dkei38ia$
Figure 3: Breaking a Message into Chunks
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, or even the same MSRP session. Any chunk that the same connection, or even the same MSRP session. Any chunk that
is larger than 2048 octets MUST be interruptible. While MSRP would is larger than 2048 octets MUST be interruptible. While MSRP would
be simpler to implement if each MSRP session used its own TCP be simpler to implement if each MSRP session used its own TCP
connection, there are compelling reasons to conserve connection. For connection, there are compelling reasons to conserve connection. For
example, the TCP peer may be a relay device that connects to many example, the TCP peer may be a relay device that connects to many
other peers. Such a device will scale better if each peer does not other peers. Such a device will scale better if each peer does not
create a large number of connections. create a large number of connections. (Note that in the above
example, the initial chunk was interruptible for the sake of example,
even though its size is was well below the limit for which
interuptibility would be required.)
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 URIs. The MSRP URI 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 URIs. This was done to allow the
protocol to work with relays, which are defined in a separate protocol to work with relays, which are defined in a separate
document, to provide a complete path to the end recipient. When two document, to provide a complete path to the end recipient. When two
MSRP nodes communicate directly they need only one URL in the To-Path MSRP nodes communicate directly they need only one URI in the To-Path
list and one URL in the From-Path list. list and one URI 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.
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
skipping to change at page 12, line 15 skipping to change at page 12, line 22
"partial", an sending device does not have to keep transaction "partial", an sending device does not have to keep transaction
state around waiting for a positive acknowledgment. But it still state around waiting for a positive acknowledgment. But it still
allows devices to report other types of errors. The receiving allows devices to report other types of errors. The receiving
device could still report a policy violation such as an 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 URI, 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 URI.
If the sender already has such a connection, that is, one associated If the sender already has such a connection, that is, one associated
with the same host, port, and URL scheme, then it SHOULD reuse that with the same host, port, and URI scheme, then it SHOULD reuse that
connection. connection.
When a new MSRP session is created, the initiating endpoint MUST act When a new MSRP session is created, the initiating endpoint MUST act
as the "active" endpoint, meaning that it is responsible for opening as the "active" endpoint, meaning that it is responsible for opening
the transport connection to the answerer, if a new connection is the transport connection to the answerer, if a new connection is
required. However, this requirement MAY be weakened if standardized required. However, this requirement MAY be weakened if standardized
mechanisms for negotiating the connection direction become available, mechanisms for negotiating the connection direction become available,
and is implemented by both parties to the connection. and is implemented by both parties to the connection.
Likewise, the active endpoint MUST immediately issue a SEND request. Likewise, the active endpoint MUST immediately issue a SEND request.
skipping to change at page 12, line 40 skipping to change at page 12, line 47
to send, or it MAY have no body at all. to send, or it MAY have no body at all.
The first SEND request serves to bind a connection to an MSRP The first SEND request serves to bind a connection to an MSRP
session from the perspective of the passive endpoint. If the session from the perspective of the passive endpoint. If the
connection is not authenticated with TLS, and the active endpoint connection is not authenticated with TLS, and the active endpoint
did not send an immediate request, the passive endpoint would have did not send an immediate request, the passive endpoint would have
no way to determine who had connected, and would not be able to no way to determine who had connected, and would not be able to
safely send any requests towards the active party until after the safely send any requests towards the active party until after the
active party sends its first request. active party sends its first request.
When an element needs to form a new connection, it looks at the URL When an element needs to form a new connection, it looks at the URI
to decide on the type of connection (TLS, TCP, etc.) then connects to to decide on the type of connection (TLS, TCP, etc.) then connects to
the host indicated by the URL, following the URL resolution rules in the host indicated by the URI, following the URI resolution rules in
Section 6.2. Connections using the "msrps" scheme MUST use TLS. The Section 6.2. Connections using the "msrps" scheme MUST use TLS. The
SubjectAltName in the received certificate MUST match the hostname SubjectAltName in the received certificate MUST match the hostname
part of the URL and the certificate MUST be valid, including having a part of the URI and the certificate MUST be valid according to RFC
date that is valid and being signed by an acceptable certificate 3280 [16], including having a date that is valid and being signed by
authority. At this point the device that initiated the connection an acceptable certification authority. At this point the device that
can assume that this connection is with the correct host. initiated the connection can assume that this connection is with the
correct host.
The rules on certificate name matching and CA signing MAY be relaxed The rules on certificate name matching and CA signing MAY be relaxed
when using TLS peer-to-peer. In this case, a mechanism to ensure when using TLS peer-to-peer. In this case, a mechanism to ensure
that the peer used a correct certificate MUST be used. See that the peer used a correct certificate MUST be used. See
Section 14.3 for details. Section 14.4 for details.
If the connection used mutual TLS authentication, and the TLS client If the connection used mutual TLS authentication, and the TLS client
presented a valid certificate, then the element accepting the presented a valid certificate, then the element accepting the
connection can immediately know the identity of the connecting host. connection can verify the identity of the connecting device by
comparing the hostname part of the target URI in the SDP provided by
the peer device against the SubjectAltName in the client certificate.
When mutual TLS authentication is not used, the listening device MUST When mutual TLS authentication is not used, the listening device MUST
wait until it receives a request on the connection, at which time it wait until it receives a request on the connection, at which time it
infers the identity of the connecting device from the associated infers the identity of the connecting device from the associated
session description. session description.
When the first request arrives, its To-Path header field should When the first request arrives, its To-Path header field should
contain a URL that the listening element provided in the SDP for a contain a URI that the listening element provided in the SDP for a
session. The element that accepted the connection looks up the URL session. The element that accepted the connection looks up the URI
in the received request, and determines which session it matches. If in the received request, and determines which session it matches. If
a match exists, the node MUST assume that the host that formed the a match exists, the node MUST assume that the host that formed the
connection is the host to which this URL was given. If no match connection is the host to which this URI was given. If no match
exists, the node MUST reject the request with a 481 response. The exists, the node MUST reject the request with a 481 response. The
node MUST also check to make sure the session is not already in use node MUST also check to make sure the session is not already in use
on another connection. If the session is already in use, it MUST on another connection. If the session is already in use, it MUST
reject the request with a 506 response. reject the request with a 506 response.
If it were legal to have multiple connections associated with the If it were legal to have multiple connections associated with the
same session, a security problem would exist. If the initial SEND same session, a security problem would exist. If the initial SEND
request is not protected, an eavesdropper might learn the URL, and request is not protected, an eavesdropper might learn the URI, and
use it to insert messages into the session via a different use it to insert messages into the session via a different
connection. connection.
If a connection fails for any reason, then an MSRP endpoint MUST If a connection fails for any reason, then an MSRP endpoint MUST
consider any sessions associated with the connection as also having consider any sessions associated with the connection as also having
failed. When either endpoint notices such a failure, it MAY attempt failed. When either endpoint notices such a failure, it MAY attempt
to re-create any such sessions. If it chooses to do so, it MUST use to re-create any such sessions. If it chooses to do so, it MUST use
a new SDP exchange, for example, in a SIP re-INVITE. If a a new SDP exchange, for example, in a SIP re-INVITE. If a
replacement session is successfully created, endpoints MAY attempt to replacement session is successfully created, endpoints MAY attempt to
resend any content for which delivery on the original session could resend any content for which delivery on the original session could
skipping to change at page 14, line 8 skipping to change at page 14, line 19
duplication. Note that acknowledgments as needed based on the duplication. Note that acknowledgments as needed based on the
Failure-Report and Success-Report settings are still necessary even Failure-Report and Success-Report settings are still necessary even
for requests containing duplicate content. for requests containing duplicate content.
When endpoints create a new session in this fashion, the chunks for a When endpoints create a new session in this fashion, the chunks for a
given logical message MAY be split across the sessions. However, given logical message MAY be split across the sessions. However,
endpoints SHOULD NOT split chunks between sessions under non-failure endpoints SHOULD NOT split chunks between sessions under non-failure
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 URIs 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 URIs
URLs using the "msrp" and "msrps" schema are used to identify a URIs using the "msrp" and "msrps" schema are used to identify a
session of instant messages at a particular MSRP device. MSRP URLs session of instant messages at a particular MSRP device. MSRP URIs
are ephemeral; an MSRP device will generally use a different MSRP URL are ephemeral; an MSRP device will generally use a different MSRP URI
for each distinct session. An MSRP URL generally has no meaning for each distinct session. An MSRP URI generally has no meaning
outside of the associated session. outside of the associated session.
An MSRP URL follows a subset of the URL syntax in Appendix A of An MSRP URI follows a subset of the URI syntax in Appendix A of
RFC3986 [10], 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.
MSRP URIs are primarily expected to be generated and exchanged
between systems, and are not intended for "human consumption".
Therefore, they are encoded entirely in US-ASCII.
The constructions for "userinfo", and "unreserved" are detailed in The constructions for "userinfo", and "unreserved" are detailed in
RFC3986 [10]. In order to allow IPV6 addressing, the construction RFC3986 [10]. In order to allow IPV6 addressing, the construction
for hostport is that used for SIP in RFC3261. URLs designating MSRP for hostport is that used for SIP in RFC3261. URIs designating MSRP
over 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 URIs
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 URI 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
indicates a reference to an MSRP host device, but does not indicates a reference to an MSRP host device, but does not
specifically refer to a particular session. specifically refer to a particular session.
A scheme of "msrps" indicates that the underlying connection MUST be A scheme of "msrps" indicates that the underlying connection MUST be
protected with TLS. protected with TLS.
MSRP has an IANA-registered recommended port defined in Section 15.4. MSRP has an IANA-registered recommended port defined in Section 15.4.
This value is not a default, as the URL negotiation process described This value is not a default, as the URI negotiation process described
herein will always include explicit port numbers. However, the URLs herein will always include explicit port numbers. However, the URIs
SHOULD be configured so that the recommended port is used whenever SHOULD be configured so that the recommended port is used whenever
appropriate. This makes life easier for network administrators who appropriate. This makes life easier for network administrators who
need to manage firewall policy for MSRP. need to manage firewall policy for MSRP.
The hostport will typically not contain a userinfo component, but MAY The hostport component will typically not contain a userinfo
do so to indicate a user account for which the session is valid. component, but MAY do so to indicate a user account for which the
Note that this is not the same thing as identifying the session session is valid. Note that this is not the same thing as
itself. If a userinfo component exists, it MUST be constructed only identifying the session itself. If a userinfo component exists, it
from "unreserved" characters, to avoid a need for escape processing. MUST be constructed only from "unreserved" characters, to avoid a
Escaping MUST NOT be used in an MSRP URL. Furthermore, a userinfo need for escape processing. Escaping MUST NOT be used in an MSRP
part MUST NOT contain password information. URI. Furthermore, a userinfo part MUST NOT contain password
information.
The limitation of userinfo to unreserved characters is an The limitation of userinfo to unreserved characters is an
additional restriction to the userinfo definition in RFC3986. additional restriction to the userinfo definition in RFC3986.
That version allows reserved characters. The additional That version allows reserved characters. The additional
restriction is to avoid the need for escaping. restriction is to avoid the need for escaping.
The following is an example of a typical MSRP URL: The following is an example of a typical MSRP URI:
msrp://host.example.com:8493/asfd34;tcp msrp://host.example.com:8493/asfd34;tcp
6.1. MSRP URL Comparison 6.1. MSRP URI Comparison
MSRP URL comparisons MUST be performed according to the following MSRP URI comparisons MUST be performed according to the following
rules: rules:
1. The scheme MUST match. Scheme comparison is case insensitive. 1. The scheme MUST match. Scheme comparison is case insensitive.
2. If the hostpart contains an explicit IP address, and/or port, 2. If the hostpart contains an explicit IP address, and/or port,
these are compared for address and port equivalence. Otherwise, these are compared for address and port equivalence. Otherwise,
hostpart is compared as a case insensitive character string. hostpart is compared as a case insensitive character string.
3. If the port exists explicitly in either URL, then it MUST match 3. If the port exists explicitly in either URI, then it MUST match
exactly. A URL with an explicit port is never equivalent to exactly. A URI with an explicit port is never equivalent to
another with no port specified. another with no port specified.
4. The session-id part is compared as case sensitive. A URL without 4. The session-id part is compared as case sensitive. A URI without
a session-id part is never equivalent to one that includes one. a session-id part is never equivalent to one that includes one.
5. URLs with different "transport" parameters never match. Two URLs 5. URIs with different "transport" parameters never match. Two URIs
that are identical except for transport are not equivalent. The that are identical except for transport are not equivalent. The
transport parameter is case-insensitive. transport parameter is case-insensitive.
6. Userinfo parts are not considered for URL comparison. 6. Userinfo parts are not considered for URI comparison.
Path normalization is not relevant for MSRP URLs. Escape Path normalization is not relevant for MSRP URIs. Escape
normalization is not required due to character restrictions in the normalization is not required due to character restrictions in the
formal syntax. formal syntax.
6.2. Resolving MSRP Host Device 6.2. Resolving MSRP Host Device
An MSRP host device is identified by the hostport of an MSRP URL. An MSRP host device is identified by the hostport of an MSRP URI.
If the hostport contains a numeric IP address and port, they MUST be If the hostport contains a numeric IP address and port, they MUST be
used as listed. used as listed.
If the hostport contains a host name and a port, the connecting If the hostport contains a host name and a port, the connecting
device MUST determine a host address by doing an A or AAAA DNS query, device MUST determine a host address by doing an A or AAAA DNS query,
and use the port as listed. and use the port as listed.
If a connection attempt fails, the device SHOULD attempt to connect If a connection attempt fails, the device SHOULD attempt to connect
to the addresses returned in any additional A or AAAA records, in the to the addresses returned in any additional A or AAAA records, in the
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 URI uses
described in this document, that is, URLs exchanged in the SDP described in this document, that is, URIs 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 URI
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 [22] 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
To form a new request, the sender creates a unique transaction To form a new request, the sender creates a transaction identifier
identifier and uses this and the method name to create an MSRP and uses this and the method name to create an MSRP request start
request start line. Next, the sender places the target URL in a To- line. The transaction identifier MUST NOT collide with that of other
Path header field, and the sender's URL in a From-Path header field. transactions that exist at the same time. Therefore, it MUST contain
If multiple URLs are present in the To-Path, the leftmost is the at least 64 bits of randomness.
first URL visited; the rightmost URL is the last URL visited. The
processing then becomes method specific. Additional method-specific Next, the sender places the target path in a To-Path header field,
header fields are added as described in the following sections. and the sender's URI in a From-Path header field. If multiple URIs
are present in the To-Path, the leftmost is the first URI visited;
the rightmost URI is the last URI visited. The processing then
becomes method specific. Additional method-specific 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. 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 not discuss any particular usage of Although this document does not discuss any particular usage of
bodies 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-interruptible 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 or any other
Note that, if no body is present, no extra CRLF will be present MIME-specific header fields. A request without a body MUST contain a
end-line after the final header field. 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 active endpoint sends a SEND request peer user. For example, the active endpoint sends 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 preceded 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
skipping to change at page 18, line 13 skipping to change at page 18, line 34
including the "$", "#", or "+" character. including the "$", "#", or "+" character.
Some implementations may choose to scan for the closing sequence as Some implementations may choose to scan for the closing sequence as
they send the body, and if it is encountered, simply interrupt the they send the body, and if it is encountered, simply interrupt the
chunk at that point and start a new transaction with a different chunk at that point and start a new transaction with a different
transaction identifier to carry the rest of the body. Other transaction identifier to carry the rest of the body. Other
implementation may choose to scan the data an ensure that the body implementation may choose to scan the data an ensure that the body
does not contain the transaction identifier before they start sending does not contain the transaction identifier before they start sending
the transaction. the transaction.
Finally, requests which have no body MUST NOT contain a Content-Type
header field or any other MIME-specific header field. Requests
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
When an endpoint has a message to deliver, it first generates a new When an endpoint has a message to deliver, it first generates a new
Message-ID. This ID MUST be globally unique. If necessary, it Message-ID. The value MUST be highly unlikely to be repeated by
breaks the message into chunks. It then generates a SEND request for another endpoint instance, or by the same instance in the future. If
each chunk, following the procedures for constructing requests necessary, the endpoint breaks the message into chunks. It then
(Section 7.1). generates a SEND request for each chunk, following the procedures for
constructing requests (Section 7.1).
The Message-ID header field provides a globally unique message The Message-ID header field provides a unique message identifier
identifier that refers to a particular version of a particular that refers to a particular version of a particular message. The
message. The term "Message" in this context refers to a unit of term "Message" in this context refers to a unit of content that
content that the sender wishes to convey to the recipient. While the sender wishes to convey to the recipient. While such a
such a message may be broken into chunks, the Message-ID refers to message may be broken into chunks, the Message-ID refers to the
the entire message, not a chunk of the message. entire message, not a chunk of the message.
The uniqueness of the message identifier is guaranteed by the host
The uniqueness of the message identifier is ensured by the host
that generates it. This message identifier is intended to be that generates it. This message identifier is intended to be
machine readable and not necessarily meaningful to humans. A machine readable and not necessarily meaningful to humans. A
message identifier pertains to exactly one version of a particular message identifier pertains to exactly one version of a particular
message; subsequent revisions to the message each receive new message; subsequent revisions to the message each receive new
message identifiers. message identifiers.
Endpoints can ensure sufficient uniqueness in any number of ways,
the selection of which is an implementation choice. For example,
an endpoint could concatenate an instance identifier such as a MAC
address, its idea of the number of seconds since the epoque, a
process ID, and a monotonically increasing 16 bit integer, all
base-64 encoded. Alternately, an endpoint without an on-board
clock could simply use a 64-bit random number.
Each chunk of a message MUST contain a Message-ID header field Each chunk of a message MUST contain a Message-ID header field
containing the Message-ID. If the sender wishes non-default status containing the Message-ID. If the sender wishes non-default status
reporting, it MUST insert a Failure-Report and/or Success-Report reporting, it MUST insert a Failure-Report and/or Success-Report
header field with an appropriate value. All chunks of the same header field with an appropriate value. All chunks of the same
message MUST use the same Failure-Report and Success-Report values in message MUST use the same Failure-Report and Success-Report values in
their SEND requests. their SEND requests.
If success reports are requested, i.e. the value of the Success- If success reports are requested, i.e. the value of the Success-
Report header field is "yes", the sending device MAY wish to run a Report header field is "yes", the sending device MAY wish to run a
skipping to change at page 21, line 32 skipping to change at page 22, line 8
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.
Success-Report and Failure-Report header fields MUST NOT be present Success-Report and Failure-Report header fields MUST NOT be present
in REPORT requests. MSRP nodes MUST NOT send REPORT requests in in REPORT requests. MSRP nodes MUST NOT send REPORT requests in
response to REPORT requests. MSRP Nodes MUST NOT send MSRP responses response to REPORT requests. MSRP Nodes MUST NOT send MSRP responses
to REPORT requests. to REPORT requests.
Endpoints SHOULD NOT send REPORT requests if they have reason to
believe the request will not be delivered. For example, they SHOULD
NOT send a REPORT request for a session that is no longer valid.
7.1.3. Generating Success Reports 7.1.3. Generating Success Reports
When an endpoint receives a message in one or more chunks that When an endpoint receives a message in one or more chunks that
contain a Success-Reports value of "true", it MUST send a success contain a Success-Reports value of "yes", it MUST send a success
report or reports covering all bytes that are received successfully. report or reports covering all bytes that are received successfully.
The success reports are sent in the form of REPORT requests, The success reports are sent in the form of REPORT requests,
following the normal procedures (Section 7.1), with a few additional following the normal procedures (Section 7.1), with a few additional
requirements. requirements.
The receiver MAY wait until it receives the last chunk of a message, The receiver MAY wait until it receives the last chunk of a message,
and send a success report that covers the complete message. and send a success report that covers the complete message.
Alternately, it MAY generate incremental success REPORTs as the Alternately, it MAY generate incremental success REPORTs as the
chunks are received. These can be sent periodically and cover all chunks are received. These can be sent periodically and cover all
the bytes that have been received so far, or they can be sent after a the bytes that have been received so far, or they can be sent after a
skipping to change at page 22, line 27 skipping to change at page 23, line 7
by the receiver. by the receiver.
However, the choice on whether to report incrementally is entirely However, the choice on whether to report incrementally is entirely
up to the receiving client. There is no mechanism for the sender up to the receiving client. There is no mechanism for the sender
to assert its desire to receive incremental reports or not. Since to assert its desire to receive incremental reports or not. Since
the presence of a relay can cause the receiver to see a very the presence of a relay can cause the receiver to see a very
different chunk allocation than the sender, such a mechanism would different chunk allocation than the sender, such a mechanism would
be of questionable value. be of questionable value.
When generating a REPORT request, the endpoint inserts a To-Path When generating a REPORT request, the endpoint inserts a To-Path
header field containing the From-Path value from the original header field containing the From-Path value from the original
request, and a From-Path header field containing the URL identifying request, and a From-Path header field containing the URI identifying
itself in the session. The endpoint then inserts a Status header itself in the session. The endpoint then inserts a Status header
field with a namespace of "000", a status-code of "200" and an field with a namespace of "000", a status-code of "200" and an
implementation-defined comment phrase. It also inserts a Message-ID implementation-defined comment phrase. It also inserts a Message-ID
header field containing the value from the original request. header field containing the value from the original request.
The namespace field denotes the context of the status-code field. The namespace field denotes the context of the status-code field.
The namespace value of "000" means the status-code should be The namespace value of "000" means the status-code should be
interpreted in the same way as the matching MSRP transaction interpreted in the same way as the matching MSRP transaction
response code. If a future specification uses the status-code response code. If a future specification uses the status-code
field for some other purpose, it MUST define a new namespace field field for some other purpose, it MUST define a new namespace field
skipping to change at page 23, line 33 skipping to change at page 24, line 12
reason fields MUST contain appropriate error codes. Any error reason fields MUST contain appropriate error codes. Any error
response code defined in this specification MAY also be used in response code defined in this specification MAY also be used in
failure reports. failure reports.
If a failure REPORT request is sent in response to a SEND request If a failure REPORT request is sent in response to a SEND request
that contained a chunk, it MUST include a Byte-Range header field that contained a chunk, it MUST include a Byte-Range header field
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
believe the request will not be delivered. For example, they SHOULD
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 [22]. 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
receiver is unable to process the request, it SHOULD immediately receiver is unable to process the request, it SHOULD immediately
generate a response. generate a response.
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) URI 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 contains the full path back request methods, the To-Path header field contains the full path back
to the original sender. This full path is generated by taking the to the original sender. This full path is generated by taking the
list of URLs from the From-Path of the original request, reversing list of URIs from the From-Path of the original request, reversing
the list, and writing the reversed list into the To-Path of the the list, and writing the reversed list into the To-Path of the
response. (Legal REPORT requests do not request responses, so this response. (Legal REPORT requests do not request responses, so this
specification doesn't exercise the behavior described above, however specification doesn't exercise the behavior described above, however
we expect that extensions for gateways and relays will need such we expect that extensions for gateways and relays will need 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 URI 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 URI in the To-Path to
make sure the request belongs to an existing session. When the make sure the request belongs to an existing session. When the
request is received, the To-Path will have exactly one URL, which request is received, the To-Path will have exactly one URI, which
MUST map to an existing session that is associated with the MUST map to an existing session that is associated with the
connection on which the request arrived. If this is not true, then connection on which the request arrived. If this is not true, then
the receiver MUST generate a 481 error and ignore the request. Note the receiver MUST generate a 481 error and ignore the request. Note
that if the Failure-Report header field had a value of "no", then no that if the Failure-Report header field had a value of "no", then no
error report would be sent. error report would be sent.
Further request processing by the receiver is method specific. Further request processing by the receiver is method specific.
7.3.1. Receiving SEND Requests 7.3.1. Receiving SEND Requests
skipping to change at page 26, line 11 skipping to change at page 26, line 33
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.
What is done with the body is outside the scope of MSRP and largely What is done with the body is outside the scope of MSRP and largely
determined by the MIME Content-Type and Content-Disposition. The determined by the MIME Content-Type and Content-Disposition. The
body MAY be rendered after the whole message is received or partially body MAY be rendered after the whole message is received or partially
rendered as it is being received. rendered as it is being received.
If the SEND request contained a Content-Type header field indicating If the SEND request contained a Content-Type header field indicating
an unsupported MIME type, and the Failure-Report value is not "no", an unsupported media-type, and the Failure-Report value is not "no",
the receiver MUST generate a response with a status code of 415. All the receiver MUST generate a response with a status code of 415. All
MSRP endpoints MUST be able to receive the multipart/mixed [15] and MSRP endpoints MUST be able to receive the multipart/mixed [15] and
multipart/alternative [15] MIME types. multipart/alternative [15] media-types.
If the Success-Report header field was set to "yes", the receiver If the Success-Report header field was set to "yes", the receiver
must construct and send one or more success reports, as described in must construct and send one or more success reports, as described in
Section 7.1.3. Section 7.1.3.
7.3.2. Receiving REPORT Requests 7.3.2. Receiving REPORT Requests
When an endpoint receives a REPORT request, it correlates it to the When an endpoint receives a REPORT request, it correlates it to the
original SEND request using the Message-ID and the Byte-Range, if original SEND request using the Message-ID and the Byte-Range, if
present. If it requested success reports, then it SHOULD keep enough present. If it requested success reports, then it SHOULD keep enough
skipping to change at page 26, line 49 skipping to change at page 27, line 23
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.
When an endpoint that sent a SEND request receives a failure REPORT When an endpoint that sent a SEND request receives a failure REPORT
indicating that a particular byte range was not received, it MUST indicating that a particular byte range was not received, it MUST
treat the session as failed. If it wishes to recover, it MUST first treat the session as failed. If it wishes to recover, it MUST first
re-negotiate the URLs at the signaling level then resend that range re-negotiate the URIs at the signaling level then resend that range
of bytes of the message on the resulting new session. of bytes of the message on the resulting new session.
MSRP nodes MUST NOT send MSRP REPORT requests in response to other MSRP nodes MUST NOT send MSRP REPORT requests in response to other
REPORT requests. REPORT requests.
8. Using MSRP with SIP and SDP 8. Using MSRP with SIP and SDP
MSRP sessions will typically be initiated using the Session MSRP sessions will typically be initiated using the Session
Description Protocol (SDP) [2] via the SIP offer/answer mechanism Description Protocol (SDP) [2] via the SIP offer/answer mechanism
[3]. [3].
This document defines a handful of new SDP parameters to set up MSRP This document defines a handful of new SDP parameters to set up MSRP
sessions. These are detailed below and in the IANA Considerations sessions. These are detailed below and in the IANA Considerations
section. section.
An MSRP media-line (that is, a media-line proposing MSRP) in the An MSRP media-line (that is, a media-line proposing MSRP) in the
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 to be visited This attribute contains a space-separated list of URIs to be visited
to contact the user agent advertising this session-description. If to contact the user agent advertising this session-description. If
more than one URL is present, the leftmost URL is the first URL to be more than one URI is present, the leftmost URI is the first URI to be
visited to reach the target resource. (The path list can contain visited to reach the target resource. (The path list can contain
multiple URLs to allow for the deployment of gateways or relays in multiple URIs to allow for the deployment of gateways or relays in
the future.) MSRP implementations that can accept incoming the future.) MSRP implementations that can accept incoming
connections without the need for relays will typically only provide a connections without the need for relays will typically only provide a
single URL here. single URI here.
An MSRP media line is also 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 media-types that are acceptable to
the endpoint. the endpoint.
8.1. SDP Connection and Media Lines 8.1. SDP Connection and Media Lines
An SDP connection-line takes the following format: An SDP connection-line takes the following format:
c=<network type> <address type> <connection address> c=<network type> <address type> <connection address>
Figure 4: Standard SDP Connection Line
The network type and address type fields are used as normal for SDP. The network type and address type fields are used as normal for SDP.
The connection address field MUST be set to the IP address or fully The connection address field MUST be set to the IP address or fully
qualified domain name from the MSRP URL identifying the endpoint in qualified domain name from the MSRP URI identifying the endpoint in
its path attribute. its path attribute.
The general format of an SDP media-line is: The general format of an SDP media-line is:
m=<media> <port> <protocol> <format list> m=<media> <port> <protocol> <format list>
Figure 5: Standard SDP Medial Line
An offered or accepted media-line for MSRP over TCP MUST include a An offered or accepted media-line for MSRP over TCP MUST include a
protocol field value of "TCP/MSRP", or "TCP/TLS/MSRP" for TLS. The protocol field value of "TCP/MSRP", or "TCP/TLS/MSRP" for TLS. The
media field value MUST be "message". The format list field MUST be media field value MUST be "message". The format list field MUST be
set to "*". set to "*".
The port field value MUST match the port value used in the endpoint's The port field value MUST match the port value used in the endpoint's
MSRP URL in the path attribute, except that, as described in [3], a MSRP URI in the path attribute, except that, as described in [3], a
user agent that wishes to accept an offer, but not a specific media- user agent that wishes to accept an offer, but not a specific media-
line, MUST set the port number of that media-line to zero (0) in the line, MUST set the port number of that media-line to zero (0) in the
response. Since MSRP allows multiple sessions to share the same TCP response. Since MSRP allows multiple sessions to share the same TCP
connection, multiple m-lines in a single SDP document may share the connection, multiple m-lines in a single SDP document may share the
same port field value; MSRP devices MUST NOT assume any particular same port field value; MSRP devices MUST NOT assume any particular
relationship between m-lines on the sole basis that they have relationship between m-lines on the sole basis that they have
matching port field values. matching port field values.
MSRP devices do not use the c-line address field, or the m-line MSRP devices do not use the c-line address field, or the m-line
port and format list fields to determine where to connect. port and format list fields to determine where to connect.
Rather, they use the attributes defined in this specification. Rather, they use the attributes defined in this specification.
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. URI Negotiations
Each endpoint in an MSRP session is identified by a URL. These URLs Each endpoint in an MSRP session is identified by a URI. These URIs
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 the MSRP URIs. The path attribute is used in an SDP a-line, and has 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-URI *(SP MSRP-URI)
where MSRP-URL is an "msrp" or "msrps" URL as defined in Section 6. Figure 6: Path Attribute
MSRP URLs included in an SDP offer or answer MUST include explicit
where MSRP-URI is an "msrp" or "msrps" URI as defined in Section 6.
MSRP URIs 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 URI to determine a host address, port,
transport, and protection level when connecting, and to identify the transport, and protection level when connecting, and to identify the
target when sending requests and responses. target when sending requests and responses.
The offerer and answerer each selects a URL to represent itself and The offerer and answerer each selects a URI to represent itself and
sends it to the peer device in the SDP document. Each device stores sends it to the peer device in the SDP document. Each device stores
the path value received from the peer and uses that value as the the path value received from the peer and uses that value as the
target for requests inside the resulting session. If the path target for requests inside the resulting session. If the path
attribute received from the peer contains more than one URL, then the attribute received from the peer contains more than one URI, then the
target URL is the rightmost, while the leftmost entry represents the target URI 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 URI. 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 URI of
"msrp://alice.example.com:7394/2s93i;tcp" "msrp://alice.example.com:7394/2s93i9ek2a;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 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/2s93i9ek2a;tcp
The rightmost URL in the path attribute MUST identify the endpoint Figure 7: Example SDP with Path Attribute
The rightmost URI 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 URI 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 URIs
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 [22]. 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 URI 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
operating on its behalf, should connect. operating on its behalf, should connect.
Endpoints that do not wish to insert a relay, including those that do Endpoints that do not wish to insert a relay, including those that do
not support relays at all, will put exactly one URL into the path not support relays at all, will put exactly one URI into the path
attribute. This URL represents both the endpoint for the session, attribute. This URI represents both the endpoint for the session,
and the connection point. and the connection point.
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 URI in the SDP path attribute. When an
endpoint receives more than one URL in a path attribute, only the endpoint receives more than one URI 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 URI in a path attribute, the final
URL in the path attribute (the peer URL) identifies the session, and URI in the path attribute (the peer URI) identifies the session, and
MUST not duplicate the URL of any other session in which the endpoint MUST not duplicate the URI of any other session in which the endpoint
is currently participating. Uniqueness requirements for other is currently participating. Uniqueness requirements for other
entries in the path attribute are out of scope for this document. 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[23] request. They may need to session timers or the SIP UPDATE[24] 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 [25] 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.
8.6. Content Type Negotiation 8.6. Content Type Negotiation
An SDP media-line proposing MSRP MUST be accompanied by an accept- An SDP media-line proposing MSRP MUST be accompanied by an accept-
types attribute. types attribute.
An entry of "*" in the accept-types attribute indicates that the An entry of "*" in the accept-types attribute indicates that the
sender may attempt to send content with media types that have not sender may attempt to send content with media-types that have not
been explicitly listed. Likewise, an entry with an explicit type and been explicitly listed. Likewise, an entry with an explicit type and
a "*" character as the subtype indicates that the sender may attempt a "*" character as the subtype indicates that the sender may attempt
to send content with any subtype of that type. If the receiver to send content with any subtype of that type. If the receiver
receives an MSRP request and is able to process the media type, it receives an MSRP request and is able to process the media-type, it
does so. If not, it will respond with a 415 response. Note that all does so. If not, it will respond with a 415 response. Note that all
explicit entries SHOULD be considered preferred over any non-listed explicit entries SHOULD be considered preferred over any non-listed
types. This feature is needed as, otherwise, the list of formats for types. This feature is needed as, otherwise, the list of formats for
rich IM devices may be prohibitively large. rich IM devices may be prohibitively large.
This specification requires the support of certain data formats. This specification requires the support of certain data formats.
Mandatory formats MUST be signaled like any other, either explicitly Mandatory formats MUST be signaled like any other, either explicitly
or by the use of a "*". or by the use of a "*".
The accept-types attribute may include container types, that is, MIME The accept-types attribute may include container types, that is, MIME
formats that contain other types internally. If compound types are formats that contain other types internally. If compound types are
used, the types listed in the accept-types attribute may be used both used, the types listed in the accept-types attribute may be used both
as the root payload, or may be wrapped in a listed container type. as the root payload, or may be wrapped in a listed container type.
Any container types MUST also be listed in the accept-types Any container types MUST also be listed in the accept-types
attribute. attribute.
Occasionally an endpoint will need to specify a MIME body type that Occasionally an endpoint will need to specify a MIME media-type that
can only be used if wrapped inside a listed container type. can only be used if wrapped inside a listed container type.
Endpoints MAY specify MIME types that are only allowed when wrapped Endpoints MAY specify media-types that are only allowed when wrapped
inside compound types using the "accept-wrapped-types" attribute in inside compound types using the "accept-wrapped-types" attribute in
an SDP a-line. an SDP a-line.
The semantics for accept-wrapped-types are identical to those of the The semantics for accept-wrapped-types are identical to those of the
accept-types attribute, with the exception that the specified types accept-types attribute, with the exception that the specified types
may only be used when wrapped inside container types listed in may only be used when wrapped inside container types listed in
accept-types attribute. Only types listed in the accept-types accept-types attribute. Only types listed in the accept-types
attribute may be used as the "root" type for the entire body. Since attribute may be used as the "root" type for the entire body. Since
any type listed in accept-types may be used both as a root body, and any type listed in accept-types may be used both as a root body, and
wrapped in other bodies, format entries from accept-types SHOULD NOT wrapped in other bodies, format entries from accept-types SHOULD NOT
be repeated in this attribute. be repeated in this attribute.
This approach does not allow for specifying distinct lists of This approach does not allow for specifying distinct lists of
acceptable wrapped types for different types of containers. If an acceptable wrapped types for different types of containers. If an
endpoint understands a MIME type in the context of one wrapper, it is endpoint understands a media-type in the context of one wrapper, it
assumed to understand it in the context of any other acceptable is assumed to understand it in the context of any other acceptable
wrappers, subject to any constraints defined by the wrapper types wrappers, subject to any constraints defined by the wrapper types
themselves. themselves.
The approach of specifying types that are only allowed inside of The approach of specifying types that are only allowed inside of
containers separately from the primary payload types allows an containers separately from the primary payload types allows an
endpoint to force the use of certain wrappers. For example, a endpoint to force the use of certain wrappers. For example, a
CPIM [12] gateway device may require all messages to be wrapped CPIM [12] gateway device may require all messages to be wrapped
inside message/cpim bodies, but may allow several content types inside message/cpim bodies, but may allow several content types
inside the wrapper. If the gateway were to specify the wrapped inside the wrapper. If the gateway were to specify the wrapped
types in the accept-types attribute, its peer might attempt to use types in the accept-types attribute, its peer might attempt to use
skipping to change at page 32, line 42 skipping to change at page 33, line 27
wrapped-types-label = "accept-wrapped-types" wrapped-types-label = "accept-wrapped-types"
format-list = format-entry *( SP format-entry) format-list = format-entry *( SP format-entry)
format-entry = (type "/" subtype) / (type "/" "*") / ("*") format-entry = (type "/" subtype) / (type "/" "*") / ("*")
type = token type = token
subtype = token subtype = token
max-size = max-size-label ":" max-size-value max-size = max-size-label ":" max-size-value
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
Figure 8: Attribute Syntax
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/2s93i93idj;tcp
B responds with its own URL: Figure 9: SDP from Endpoint A
B responds with its own URI:
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/si438dsaodes;tcp
Figure 10: SDP From Endpoint B
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
responding. This is analogous to the typical telephone user responding. This is analogous to the typical telephone user
experience, where the callee "answers" the call. experience, where the callee "answers" the call.
In contrast, the typical user experience for instant messaging In contrast, the typical user experience for instant messaging
applications is that the initial received message is immediately applications is that the initial received message is immediately
skipping to change at page 33, line 46 skipping to change at page 34, line 37
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.
8.9. SDP direction attribute and MSRP 8.9. SDP direction attribute and MSRP
SDP defines a number of attributes that modify the direction of media SDP defines a number of attributes that modify the direction of media
flows. These are the "sendonly", "recvonly", "inactive", and flows. These are the "sendonly", "recvonly", "inactive", and
skipping to change at page 34, line 26 skipping to change at page 35, line 16
kind of control or reporting protocol rather than regular message kind of control or reporting protocol rather than regular message
payload (e.g., IMDN reports) should be generated according to the payload (e.g., IMDN reports) should be generated according to the
protocol rules as if no direction attribute were present. protocol rules as if no direction attribute were present.
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.
The following syntax specification uses the augmented Backus-Naur The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [6]. Form (BNF) as described in RFC 4234 [6].
msrp-req-or-resp = msrp-request / msrp-response msrp-req-or-resp = msrp-request / msrp-response
msrp-request = req-start headers [content-stuff] end-line msrp-request = req-start headers [content-stuff] end-line
msrp-response = resp-start headers end-line msrp-response = resp-start headers end-line
req-start = pMSRP SP transact-id SP method CRLF req-start = pMSRP SP transact-id SP method CRLF
resp-start = pMSRP SP transact-id SP status-code [SP comment] CRLF resp-start = pMSRP SP transact-id SP status-code [SP comment] CRLF
comment = utf8text comment = utf8text
pMSRP = %x4D.53.52.50 ; MSRP in caps pMSRP = %x4D.53.52.50 ; MSRP in caps
transact-id = ident transact-id = ident
method = mSEND / mREPORT / other-method method = mSEND / mREPORT / other-method
mSEND = %x53.45.4e.44 ; SEND in caps mSEND = %x53.45.4e.44 ; SEND in caps
mREPORT = %x52.45.50.4f.52.54; REPORT in caps mREPORT = %x52.45.50.4f.52.54; REPORT in caps
other-method = 1*UPALPHA other-method = 1*UPALPHA
status-code = 3DIGIT ; any code defined in this document status-code = 3DIGIT ; any code defined in this document
; or an extension document ; or an extension document
MSRP-URL = msrp-scheme "://" [userinfo "@"] hostport MSRP-URI = msrp-scheme "://" [userinfo "@"] hostport
["/" session-id] ";" transport *( ";" url-parameter) ["/" session-id] ";" transport *( ";" URI-parameter)
; userinfo as defined in RFC3986, except ; userinfo as defined in RFC3986, except
; limited to unreserved. ; limited to unreserved.
; hostport as defined in RFC3261 ; hostport as defined in RFC3261
msrp-scheme = "msrp" / "msrps" msrp-scheme = "msrp" / "msrps"
session-id = 1*( unreserved / "+" / "=" / "/" ) session-id = 1*( unreserved / "+" / "=" / "/" )
; unreserved as defined in RFC3986 ; unreserved as defined in RFC3986
transport = "tcp" / ALPHANUM transport = "tcp" / ALPHANUM
url-parameter = token ["=" token] URI-parameter = token ["=" token]
headers = To-Path CRLF From-Path CRLF 1*( header CRLF ) headers = To-Path CRLF From-Path CRLF 1*( header CRLF )
header = Message-ID header = Message-ID
/ Success-Report / Success-Report
/ Failure-Report / Failure-Report
/ Byte-Range / Byte-Range
/ Status / Status
/ ext-header / ext-header
To-Path = "To-Path:" SP MSRP-URL *( SP MSRP-URL ) To-Path = "To-Path:" SP MSRP-URI *( SP MSRP-URI )
From-Path = "From-Path:" SP MSRP-URL *( SP MSRP-URL ) From-Path = "From-Path:" SP MSRP-URI *( SP MSRP-URI )
Message-ID = "Message-ID:" SP ident Message-ID = "Message-ID:" SP ident
Success-Report = "Success-Report:" SP ("yes" / "no" ) Success-Report = "Success-Report:" SP ("yes" / "no" )
Failure-Report = "Failure-Report:" SP ("yes" / "no" / "partial" ) Failure-Report = "Failure-Report:" SP ("yes" / "no" / "partial" )
Byte-Range = "Byte-Range:" SP range-start "-" range-end "/" total Byte-Range = "Byte-Range:" SP range-start "-" range-end "/" total
range-start = 1*DIGIT range-start = 1*DIGIT
range-end = 1*DIGIT / "*" range-end = 1*DIGIT / "*"
total = 1*DIGIT / "*" total = 1*DIGIT / "*"
Status = "Status:" SP namespace SP status-code [SP text-reason] Status = "Status:" SP namespace SP status-code [SP text-reason]
namespace = 3(DIGIT); "000" for all codes defined in this document. namespace = 3(DIGIT); "000" for all codes defined in this document.
text-reason = utf8text text-reason = utf8text
ident = alphanum 3*31ident-char ident = ALPHANUM 3*31ident-char
ident-char = alphanum / "." / "-" / "+" / "%" / "=" ident-char = ALPHANUM / "." / "-" / "+" / "%" / "="
content-stuff = *(Other-Mime-header CRLF) content-stuff = *(Other-Mime-header CRLF)
Content-Type 2CRLF data CRLF Content-Type 2CRLF data CRLF
Content-Type = "Content-Type:" SP media-type Content-Type = "Content-Type:" SP media-type
media-type = type "/" subtype *( ";" gen-param ) media-type = type "/" subtype *( ";" gen-param )
type = token type = token
subtype = token subtype = token
gen-param = pname [ "=" pval ] gen-param = pname [ "=" pval ]
skipping to change at page 36, line 39 skipping to change at page 37, line 31
utf8text = *(HTAB / %x20-7E / UTF8-NONASCII) utf8text = *(HTAB / %x20-7E / UTF8-NONASCII)
UTF8-NONASCII = %xC0-DF 1UTF8-CONT UTF8-NONASCII = %xC0-DF 1UTF8-CONT
/ %xE0-EF 2UTF8-CONT / %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT / %xF0-F7 3UTF8-CONT
/ %xF8-Fb 4UTF8-CONT / %xF8-Fb 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT / %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF UTF8-CONT = %x80-BF
Figure 11: MSRP ABNF
10. Response Code Descriptions 10. Response Code Descriptions
This section summarizes the semantics of various response codes that This section summarizes the semantics of various response codes that
may be used in MSRP transaction responses. These codes may also be may be used in MSRP transaction responses. These codes may also be
used in the Status header field in REPORT requests. used in the Status header field in REPORT requests.
10.1. 200 10.1. 200
The 200 response code indicates a successful transaction. The 200 response code indicates a successful transaction.
skipping to change at page 37, line 38 skipping to change at page 38, line 33
to a chunk of an undesired message. to a chunk of an undesired message.
If a message sender receives a 413 in a response, or in a REPORT If a message sender receives a 413 in a response, or in a REPORT
request, it MUST NOT send any further chunks in the message, that is, request, it MUST NOT send any further chunks in the message, that is,
any further chunks with the same Message-ID value. If the sender any further chunks with the same Message-ID value. If the sender
receives the 413 while in the process of sending a chunk, and the receives the 413 while in the process of sending a chunk, and the
chunk is interruptible, the sender MUST interrupt it. chunk is interruptible, the sender MUST interrupt it.
10.6. 415 10.6. 415
A 415 response indicates the SEND request contained a MIME content- A 415 response indicates the SEND request contained a media type that
type that is not understood by the receiver. The sender should not is not understood by the receiver. The sender should not send any
send any further messages with the same content-type for the duration further messages with the same content-type for the duration of the
of the session. 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. 481 10.8. 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.
skipping to change at page 39, line 29 skipping to change at page 39, line 50
|<-----------------------| |<-----------------------|
|(7) (MSRP) 200 OK | |(7) (MSRP) 200 OK |
|----------------------->| |----------------------->|
|(8) (SIP) BYE | |(8) (SIP) BYE |
|----------------------->| |----------------------->|
|(9) (SIP) 200 OK | |(9) (SIP) 200 OK |
|<-----------------------| |<-----------------------|
| | | |
| | | |
1. Alice constructs a local URL of Figure 12: Basic IM Session Example
msrp://alicepc.example.com:7777/iau39;tcp . 1. Alice constructs a local URI of
msrp://alicepc.example.com:7777/iau39soe2843z;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/iau39soe2843z;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/9di4eae923wzd;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):
MSRP d93kswow SEND MSRP d93kswow SEND
To-Path: msrp://bob.example.com:8888/9di4ea;tcp To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7777/iau39;tcp From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
Message-ID: 12339sdqwer Message-ID: 12339sdqwer
Content-Type: text/plain Content-Type: text/plain
Hi, I'm Alice! Hi, I'm Alice!
-------d93kswow$ -------d93kswow$
5. Bob->Alice (MSRP): 5. Bob->Alice (MSRP):
MSRP d93kswow 200 OK MSRP d93kswow 200 OK
To-Path: msrp://alicepc.example.com:7777/iau39;tcp To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bob.example.com:8888/9di4ea;tcp From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
-------d93kswow$ -------d93kswow$
6. Bob->Alice (MSRP): 6. Bob->Alice (MSRP):
MSRP dkei38sd SEND MSRP dkei38sd SEND
To-Path: msrp://alicepc.example.com:7777/iau39;tcp To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bob.example.com:8888/9di4ea;tcp From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
Message-ID: 456 Message-ID: 456s9wlk3
Content-Type: text/plain Content-Type: text/plain
Hi, Alice! I'm Bob! Hi, Alice! I'm Bob!
-------dkei38sd$ -------dkei38sd$
7. Alice->Bob (MSRP): 7. Alice->Bob (MSRP):
MSRP dkei38sd 200 OK MSRP dkei38sd 200 OK
To-Path: msrp://alicepc.example.com:7777/iau39;tcp To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://bob.example.com:8888/9di4ea;tcp From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
-------dkei38sd$ -------dkei38sd$
8. Alice->Bob (SIP): BYE sip:bob@example.com 8. Alice->Bob (SIP): BYE sip:bob@example.com
Alice invalidates local session state. Alice invalidates local session state.
9. Bob invalidates local state for the session. 9. Bob invalidates local state for the session.
Bob->Alice (SIP): 200 OK Bob->Alice (SIP): 200 OK
skipping to change at page 41, line 6 skipping to change at page 42, line 4
8. Alice->Bob (SIP): BYE sip:bob@example.com 8. Alice->Bob (SIP): BYE sip:bob@example.com
Alice invalidates local session state. Alice invalidates local session state.
9. Bob invalidates local state for the session. 9. Bob invalidates local state for the session.
Bob->Alice (SIP): 200 OK Bob->Alice (SIP): 200 OK
11.2. Message with XHTML Content 11.2. Message with XHTML Content
MSRP dsdfoe38sd SEND MSRP dsdfoe38sd SEND
To-Path: msrp://alice.example.com:7777/iau39;tcp To-Path: msrp://alice.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bob.example.com:8888/9di4ea;tcp From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
Message-ID: 456 Message-ID: 456so39s
Content-Type: application/xhtml+xml Content-Type: application/xhtml+xml
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html <!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"_http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd_"> "_http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd_">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head> <head>
<title>FY2005 Results</title> <title>FY2005 Results</title>
</head> </head>
<body> <body>
<p>See the results at <a <p>See the results at <a
href="http://example.org/">example.org</a>.</p> href="http://example.org/">example.org</a>.</p>
</body> </body>
</html> </html>
-------dsdfoe38sd$ -------dsdfoe38sd$
Figure 13: Example Message with XHTML
11.3. Chunked Message 11.3. Chunked Message
For an example of a chunked message, see the example in Section 5.1. For an example of a chunked message, see the example in Section 5.1.
11.4. System Message 11.4. Chunked Message with message/cpim payload
This example shows a chunked message containing a CPIM message that
wraps a text/plain payload. It is worth noting that MSRP considers
the complete CPIM message before chunking the message, thus, the CPIM
headers are included in only the first chunk. The MSRP Content-Type
and Byte-Range headers, present in both chunks, refer to the whole
CPIM message.
MSRP d93kswow SEND
To-Path: msrp://bobpc.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7654/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-137/148
Content-Type: message/cpim
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>
DateTime: 2006-05-15T15:02:31-03:00
Content-Type: text/plain
ABCD
-------d93kswow+
Figure 14: First Chunk
Alice sends the second and last chunk.
MSRP op2nc9a SEND
To-Path: msrp://bobpc.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7654/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 138-148/148
Content-Type: message/cpim
1234567890
-------op2nc9a$
Figure 15: Second Chunk
11.5. System Message
Sysadmin->Alice (MSRP): Sysadmin->Alice (MSRP):
MSRP d93kswow SEND MSRP d93kswow SEND
To-Path: msrp://alicepc.example.com:8888/9di4ea;tcp To-Path: msrp://alicepc.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://example.com:7777/iau39;tcp From-Path: msrp://example.com:7777/iau39soe2843z;tcp
Message-ID: 12339sdqwer Message-ID: 12339sdqwer
Failure-Report: no Failure-Report: no
Success-Report: no Success-Report: no
Content-Type: text/plain Content-Type: text/plain
This conference will end in 5 minutes This conference will end in 5 minutes
-------d93kswow$ -------d93kswow$
11.5. Positive Report 11.6. Positive Report
Alice->Bob (MSRP): Alice->Bob (MSRP):
MSRP d93kswow SEND MSRP d93kswow SEND
To-Path: msrp://bob.example.com:8888/9di4ea;tcp To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7777/iau39;tcp From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
Message-ID: 12339sdqwer Message-ID: 12339sdqwer
Byte-Range: 1-106/106 Byte-Range: 1-106/106
Success-Report: yes Success-Report: yes
Failure-Report: no Failure-Report: no
Content-Type: text/html Content-Type: text/html
<html><body> <html><body>
<p>Here is that important link... <p>Here is that important link...
<a href="http://www.example.com/foobar">foobar</a> <a href="http://www.example.com/foobar">foobar</a>
</p> </p>
</body></html> </body></html>
-------d93kswow$ -------d93kswow$
Figure 16: Initial SEND Request
Bob->Alice (MSRP): Bob->Alice (MSRP):
MSRP dkei38sd REPORT MSRP dkei38sd REPORT
To-Path: msrp://alicepc.example.com:7777/iau39;tcp To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bob.example.com:8888/9di4ea;tcp From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
Message-ID: 12339sdqwer Message-ID: 12339sdqwer
Byte-Range: 1-106/106 Byte-Range: 1-106/106
Status: 000 200 OK Status: 000 200 OK
-------dkei38sd$ -------dkei38sd$
11.6. Forked IM Figure 17: Success Report
11.7. 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, "page-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 [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 45, line 4 skipping to change at page 47, line 4
| |<---200 OK---------------------------------------| | |<---200 OK---------------------------------------|
|<--200 OK---| | | | | |<--200 OK---| | | | |
|---ACK------------------------------------------------------->| |---ACK------------------------------------------------------->|
|<================MSRP Session================================>| |<================MSRP Session================================>|
| | | | | | | | | | | |
| 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.... |
Figure 18: Forking Example
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. MSRP does not contain a version number or any negotiation RFCs. MSRP does not contain a version number or any negotiation
mechanism to require or discover new features. If an extension is mechanism to require or discover new features. If an extension is
specified in the future that requires negotiation, the specification specified in the future that requires negotiation, the specification
will need to describe how the extension is to be negotiated in the will need to describe how the extension is to be negotiated in the
encapsulating signaling protocol. If a non-interoperable update or encapsulating signaling protocol. If a non-interoperable update or
extension occurs in the future, it will be treated as a new protocol, extension occurs in the future, it will be treated as a new protocol,
and MUST describe how its use will be 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 URIs instead of a single URI 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. URIs can contain parameters that are extensible.
13. CPIM Compatibility 13. CPIM Compatibility
MSRP sessions may go to a gateway to other CPIM [26] 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
skipping to change at page 46, line 45 skipping to change at page 49, line 5
the correct party, and allow the possibility of anonymous the correct party, and allow the possibility of anonymous
communication. MSRP pushes many of the hard problems to SIP when SIP communication. MSRP pushes many of the hard problems to SIP when SIP
sets up the session, but some of the problems remain. Spam and DoS sets up the session, but some of the problems remain. Spam and DoS
attacks are also very relevant to IM systems. attacks are also very relevant to IM systems.
MSRP needs to provide confidentiality and integrity for the messages MSRP needs to provide confidentiality and integrity for the messages
it transfers. It also needs to provide assurances that the connected it transfers. It also needs to provide assurances that the connected
host is the host that it meant to connect to and that the connection host is the host that it meant to connect to and that the connection
has not been hijacked. has not been hijacked.
14.1. Transport Level Protection 14.1. Secrecy of the MSRP URI
When an endpoint sends an MSRP URI to its peer in a rendez-vous
protocol, that URI is effectively a secret shared between the peers.
If an attacker learns or guesses the URI prior to the completion of
session setup, it may be able to impersonate one of the peers.
Assuming the URI exchange in the rendez-vous protocol is sufficiently
protected, it is critical that the URI remain difficult to "guess"
via brute force methods. Most components of the URI, such as the
scheme and the hostport components, are common knowledge. The
secrecy is entirely provided by the session-id component.
Therefore, when an MSRP device generates an MSRP URI to be used in
the initiation of an MSRP session, the session-id component MUST
contain at least 80 bits of randomness.
14.2. Transport Level Protection
When using only TCP connections, MSRP security is fairly weak. If When using only TCP connections, MSRP security is fairly weak. If
host A is contacting host B, B passes its hostname and a secret to A host A is contacting host B, B passes its hostname and a secret to A
using a rendezvous protocol. Although MSRP requires the use of a using a rendezvous protocol. Although MSRP requires the use of a
rendezvous protocol with the ability to protect this exchange, there rendezvous protocol with the ability to protect this exchange, there
is no guarantee that the protection will be used all the time. If is no guarantee that the protection will be used all the time. If
such protection is not used, anyone can see this secret. Host A then such protection is not used, anyone can see this secret. Host A then
connects to the provided host name and passes the secret in the clear connects to the provided host name and passes the secret in the clear
across the connection to B. Host A assumes that it is talking to B across the connection to B. Host A assumes that it is talking to B
based on where it sent the SYN packet and then delivers the secret in based on where it sent the SYN packet and then delivers the secret in
plain text across the connections. Host B assumes it is talking to A plain text across the connections. Host B assumes it is talking to A
because the host on the other end of the connection delivered the because the host on the other end of the connection delivered the
secret. An attacker that could ACK the SYN packet could insert secret. An attacker that could ACK the SYN packet could insert
itself as a man in the middle in the connection. itself as a man in the middle in the connection.
When using TLS connections, the security is significantly improved. When using TLS connections, the security is significantly improved.
We assume that the host accepting the connection has a certificate We assume that the host accepting the connection has a certificate
from a well-known certificate authority. Furthermore, we assume that from a well-known certification authority. Furthermore, we assume
the signaling to set up the session is protected by the rendezvous that the signaling to set up the session is protected by the
protocol. In this case, when host A contacts host B, the secret is rendezvous protocol. In this case, when host A contacts host B, the
passed through a confidential channel to A. A connects with TLS to B. secret is passed through a confidential channel to A. A connects with
B presents a valid certificate, so A knows it really is connected to TLS to B. B presents a valid certificate, so A knows it really is
B. A then delivers the secret provided by B, so that B can verify it connected to B. A then delivers the secret provided by B, so that B
is connected to A. In this case, a rogue SIP Proxy can see the secret can verify it is connected to A. In this case, a rogue SIP Proxy can
in the SIP signaling traffic and could potentially insert itself as a see the secret in the SIP signaling traffic and could potentially
man-in-the-middle. insert itself as a 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 certification authorities is difficult for peer-to-peer connections,
the types of hosts that end clients use for sending instant messages as the types of hosts that end clients use for sending instant
are unlikely to have long-term stable IP addresses or DNS names that messages are unlikely to have long-term stable IP addresses or DNS
certificates can bind to. In addition, the cost of server names that certificates can bind to. In addition, the cost of server
certificates from well-known certificate authorities is currently certificates from well-known certification 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 14.3. Section 14.4.
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 [22]. 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 [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).
14.2. S/MIME 14.3. 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 media-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 [27] provided in the session setup. MSRP can carry shared secret [28] provided in the session setup. MSRP can carry
unencoded binary payloads. Therefore MIME bodies MUST be transferred unencoded binary payloads. Therefore MIME bodies MUST be transferred
with a transfer encoding of binary. If a message is both signed and with a transfer encoding of binary. If a message is both signed and
encrypted, it SHOULD be signed first, then encrypted. If S/MIME is encrypted, it SHOULD be signed first, then encrypted. If S/MIME is
supported, SHA-1, RSA, and AES-128 MUST be supported. supported, SHA-1, SHA-256, RSA, and AES-128 MUST be supported. For
RSA, implementations MUST support key sizes of at least 1024 bits and
SHOULD support key sizes of 2048 bits or more.
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 certification authority. When MSRP is used with SIP,
Identity [16] and Certificates [24] mechanisms provide S/MIME based the Identity [17] and Certificates [25] mechanisms provide S/MIME
delivery of a secret between A and B. No SIP intermediary except the based delivery of a secret between A and B. No SIP intermediary
explicitly trusted authentication service (one per user) can see the except the explicitly trusted authentication service (one per user)
secret. The S/MIME encryption of the SDP can also be used by SIP to can see the secret. The S/MIME encryption of the SDP can also be
exchange keying material that can be used in MSRP. The MSRP session used by SIP to exchange keying material that can be used in MSRP.
can then use S/MIME with this keying material to encrypt and sign
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
connection, but the consequences are mitigated if all the MSRP
content is encrypted and signed with S/MIME. Although out of scope
for this document, the SIP negotiation of MSRP session can negotiate
symmetric keying material to be used with S/MIME for integrity and
privacy.
14.3. Using TLS in Peer to Peer Mode The MSRP session can then use S/MIME with this keying material to
sign and encrypt 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 connection, but the consequences are mitigated if all the
MSRP content is signed and encrypted with S/MIME. Although out of
scope for this document, the SIP negotiation of MSRP session can
negotiate symmetric keying material to be used with S/MIME for
integrity and privacy.
14.4. Using TLS in Peer-to-Peer Mode
TLS can be used with a self-signed certificate as long as there is a 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 mechanism for both sides to ascertain that the other side used the
correct certificate. When used with SDP and SIP, the correct correct certificate. When used with SDP and SIP, the correct
certificate can be verified by passing a fingerprint of the certificate can be verified by passing a fingerprint of the
certificate in the SDP and ensuring that the SDP has suitable certificate in the SDP and ensuring that the SDP has suitable
integrity protection. When SIP is used to transport the SDP, the integrity protection. When SIP is used to transport the SDP, the
integrity can be provided by the SIP Identity mechanism[16]. The integrity can be provided by the SIP Identity mechanism[17]. The
rest of this section describes the details of this approach. rest of this section describes the details of this approach.
If self-signed certificates are used, the content of the If self-signed certificates are used, the content of the
subjectAltName attribute inside the certificate MAY use the uniform subjectAltName attribute inside the certificate MAY use the uniform
resource identifier (URI) of the user. In SIP, this URI of the user 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 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 purposes only and is not required to bind the certificate to one of
the communication endpoints. Unlike normal TLS operations in this the communication endpoints. Unlike normal TLS operations in this
protocol, when doing peer-to-peer TLS, the subjectAltName is not an protocol, when doing peer-to-peer TLS, the subjectAltName is not an
important component of the certificate verification. If the endpoint important component of the certificate verification. If the endpoint
is also able to make anonymous sessions, a distinct, unique is also able to make anonymous sessions, a distinct, unique
certificate MUST be used for this purpose. For a client that works certificate MUST be used for this purpose. For a client that works
with multiple users, each user SHOULD have its own certificate. with multiple users, each user SHOULD have its own certificate.
Because the generation of public/private key pairs is relatively Because the generation of public/private key pairs is relatively
expensive, endpoints are not required to generate certificates for expensive, endpoints are not required to generate certificates for
each session. each session.
A certificate fingerprint is the output of a one-way hash function A certificate fingerprint is the output of a one-way hash function
computed over the distinguished encoding rules (DER) form of the computed over the distinguished encoding rules (DER) form of the
certificate. The endpoint MUST use the certificate fingerprint certificate. The endpoint MUST use the certificate fingerprint
attribute as specified in [17] and MUST include this in the SDP. The attribute as specified in [18] and MUST include this in the SDP. The
certificate presented during the TLS handshake needs to match the certificate presented during the TLS handshake needs to match the
fingerprint exchanged via the SDP and if the fingerprint does not fingerprint exchanged via the SDP and if the fingerprint does not
match the hashed certificate then the endpoint MUST tear down the match the hashed certificate then the endpoint MUST tear down the
media session immediately. media session immediately.
When using SIP, the integrity of the fingerprint can be ensured When using SIP, the integrity of the fingerprint can be ensured
through the SIP Identity mechanism [16]. When a client wishes to use through the SIP Identity mechanism [17]. When a client wishes to use
SIP to set up a secure MSRP session with another endpoint it sends an SIP to set up a secure MSRP session with another endpoint it sends an
SDP offer in a SIP message to the other endpoint. This offer SDP offer in a SIP message to the other endpoint. This offer
includes, as part of the SDP payload, the fingerprint of the includes, as part of the SDP payload, the fingerprint of the
certificate that the endpoint wants to use. The SIP message certificate that the endpoint wants to use. The SIP message
containing the offer is sent to the offerer's SIP proxy which will containing the offer is sent to the offerer's SIP proxy which will
add an Identity header according to the procedures outlined in [16]. add an Identity header according to the procedures outlined in [17].
When the far endpoint receives the SIP message it can verify the When the far endpoint receives the SIP message it can verify the
identity of the sender using the Identity header. Since the Identity identity of the sender using the Identity header. Since the Identity
header is a digital signature across several SIP headers, in addition 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 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 certain that the message has not been tampered with after the digital
signature was added to the SIP message. signature was added to the SIP message.
An example of SDP with a fingerprint attribute is shown in the An example of SDP with a fingerprint attribute is shown in the
following figure. Note the fingerprint is shown spread over two following figure. Note the fingerprint is shown spread over two
lines due to formatting consideration but should all be on one line. lines due to formatting consideration but should all be on one line.
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
m=message 7654 TCP/TLS/MSRP * m=message 7654 TCP/TLS/MSRP *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrps://atlanta.example.com:7654/jshA7we;tcp a=path:msrps://atlanta.example.com:7654/jshA7weso3ks;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 Figure 19: SDP with Fingerprint Attribute
14.5. 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 resources used to form a distributed attack to consume TCP connection resources
on servers. The attacker, Mallory, sends a SIP INVITE with no offer on servers. The attacker, Mallory, sends a SIP INVITE with no offer
to Alice. Alice returns a 200 with an offer and Mallory returns an to Alice. Alice returns a 200 with an offer and Mallory returns an
answer with SDP indicating that his MSRP address is the address of answer with SDP indicating that his 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 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 apply to the complete message, prior to any breaking of operations apply to the complete message, prior to any breaking of
the message into chunks. 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 URIs 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
the user identified in the certificate and does not assume that the the user identified in the certificate and does not assume that the
message came from the party they signaled. message came from the party they signaled.
skipping to change at page 51, line 28 skipping to change at page 54, line 4
same pair of identities. Nor does it prohibit an endpoint sending a same pair of identities. Nor does it prohibit an endpoint sending a
message on behalf of another identity, such as may be the case for a message on behalf of another identity, such as may be the case for a
conference server. The recipient's endpoint should determine its conference server. The recipient's endpoint should determine its
level of trust of the authenticity of the sender independently for level of trust of the authenticity of the sender independently for
each session. The fact that an endpoint trusts the authenticity of each session. The fact that an endpoint trusts the authenticity of
the sender on any given session should not affect the level of trust the sender on any given session should not affect the level of trust
it assigns for apparently the same sender on a different session. it assigns for apparently the same sender on a different session.
When MSRP clients form or acquire a certificate, they SHOULD ensure When MSRP clients form or acquire a certificate, they SHOULD ensure
that the subjectAltName has a GeneralName entry of type that the subjectAltName has a GeneralName entry of type
uniformResourceIdentifier for each URL corresponding to this client uniformResourceIdentifier for each URI corresponding to this client
and should always include an "im:" URI. It is fine if the and should always include an "im:" URI. It is fine if the
certificate contains other URIs such as "sip:" or "xmpp:" URIs. certificate contains other URIs such as "sip:" or "xmpp:" URIs.
MSRP implementors should be aware of a potential attack on MSRP MSRP implementors should be aware of a potential attack on MSRP
devices that involves placing very large values in the byte-range devices that involves placing very large values in the byte-range
header field, potentially causing the device to allocate very large header field, potentially causing the device to allocate very large
memory buffers to hold the message. Implementations SHOULD apply memory buffers to hold the message. Implementations SHOULD apply
some degree of sanity checking on byte-range values before allocating some degree of sanity checking on byte-range values before allocating
such buffers. such buffers.
skipping to change at page 52, line 18 skipping to change at page 54, line 41
Parameters and initiates its population as follows. New parameters Parameters and initiates its population as follows. New parameters
in this sub-registry must be published in an RFC (either as an IETF in this sub-registry must be published in an RFC (either as an IETF
submission or RFC Editor submission). submission or RFC Editor submission).
SEND - [RFCXXXX] SEND - [RFCXXXX]
REPORT - [RFCXXXX] REPORT - [RFCXXXX]
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 method name. o The method name.
The RFC number in which the method is registered. o The RFC number in which the method is registered.
15.2. MSRP Header Fields 15.2. MSRP Header Fields
This specification establishes the header field-Field sub-registry This specification establishes the header field-Field sub-registry
under MSRP Parameters. New parameters in this sub-registry must be under MSRP Parameters. New parameters in this sub-registry must be
published in an RFC (either as an IETF submission or RFC Editor published in an RFC (either as an IETF submission or RFC Editor
submission). Its initial population is defined as follows: submission). Its initial population is defined as follows:
To-Path - [RFCXXXX] To-Path - [RFCXXXX]
From-Path - [RFCXXXX] From-Path - [RFCXXXX]
Success-Report - [RFCXXXX] Success-Report - [RFCXXXX]
Failure-Report - [RFCXXXX] Failure-Report - [RFCXXXX]
Byte-Range - [RFCXXXX] Byte-Range - [RFCXXXX]
Status - [RFCXXXX] Status - [RFCXXXX]
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 header field: order to register a new MSRP header field:
The header field name. o The header field name.
The RFC number in which the method is registered. o The RFC number in which the method is registered.
15.3. MSRP Status Codes 15.3. MSRP Status Codes
This specification establishes the Status-Code sub-registry under This specification establishes the Status-Code sub-registry under
MSRP Parameters. New parameters in this sub-registry must be MSRP Parameters. New parameters in this sub-registry must be
published in an RFC (either as an IETF submission or RFC Editor published in an RFC (either as an IETF submission or RFC Editor
submission). Its initial population is defined in Section 10. It submission). Its initial population is defined in Section 10. It
takes the following format: takes the following format:
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 status code: order to register a new MSRP status code:
The status code number. o The status code number.
The RFC number in which the method is registered. o The RFC number in which the method is registered.
15.4. MSRP Port 15.4. MSRP Port
MSRP uses TCP port XYZ. Usage of this value is described in MSRP uses TCP port XYZ, from the "registered" port range. Usage of
Section 6. this value is described in 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. URI Schema
This document defines the URL schemes of "msrp" and "msrps". This document requests permanent registration the URI schemes of
"msrp" and "msrps".
Syntax: See Section 6. 15.5.1. MSRP Scheme
Character Encoding: See Section 6. URI Scheme Name "msrp"
Intended Usage: See Section 6. URI Scheme Syntax See the ABNF construction for "MSRP-URI" in
Protocols: The Message Session Relay Protocol (MSRP). Section 9 of RFCXXXX.
Security Considerations: See Section 14. URI Scheme Semantics See Section 6 of RFCXXXX.
Relevant Publications: RFCXXXX Encoding Considerations See Section 6 of RFCXXXX.
Applications/Protocols that use this URI Scheme The Message Session
Relay Protocol (MSRP).
Interoperability Considerations MSRP URIs are expected to be used
only by implemetations of MSRP. No additional interoperability
issues are expected.
Security Considerations See Section 14.1 of RFCXXXX for specific
security considerations for MSRP URIs, and Section 14 of RFCXXXX
for security considerations for MSRP in general.
Contact Ben Campbell (ben@estacado.net).
Author/Change Controller This is a permanent registration request.
Change control does not apply.
15.5.2. MSRPS Scheme
URI Scheme Name "msrps"
URI Scheme Syntax See the ABNF construction for "MSRP-URI" in
Section 9 of RFCXXXX.
URI Scheme Semantics See Section 6 of RFCXXXX.
Encoding Considerations See Section 6 of RFCXXXX.
Applications/Protocols that use this URI Scheme The Message Session
Relay Protocol (MSRP).
Interoperability Considerations MSRP URIs are expected to be used
only by implementations of MSRP. No additional interoperability
issues are expected.
Security Considerations See Section 14.1 of RFCXXXX for specific
security considerations for MSRP URIs, and Section 14 of RFCXXXX
for security considerations for MSRP in general.
Contact Ben Campbell (ben@estacado.net).
Author/Change Controller This is a permanent registration request.
Change control does not apply.
15.6. SDP Transport Protocol 15.6. SDP Transport Protocol
MSRP defines the a new SDP protocol field values "TCP/MSRP" and "TCP/ MSRP defines the a new SDP protocol field values "TCP/MSRP" and "TCP/
TLS/MSRP", which should be registered in the sdp-parameters registry TLS/MSRP", which should be registered in the sdp-parameters registry
under "proto". This first value indicates the MSRP protocol when TCP under "proto". This first value indicates the MSRP protocol when TCP
is used as an underlying transport. The second indicates that TLS is is used as an underlying transport. The second indicates that TLS is
used. used.
Specifications defining new protocol values must define the rules for Specifications defining new protocol values must define the rules for
skipping to change at page 54, line 4 skipping to change at page 57, line 13
which is a single occurrence of "*". Actual format determination is which is a single occurrence of "*". Actual format determination is
made using the "accept-types" and "accept-wrapped-types" attributes. made using the "accept-types" and "accept-wrapped-types" attributes.
15.7. SDP Attribute Names 15.7. SDP Attribute Names
This document registers the following SDP attribute parameter names This document registers the following SDP attribute parameter names
in the sdp-parameters registry. These names are to be used in the in the sdp-parameters registry. These names are to be used in the
SDP att-name field. SDP att-name field.
15.7.1. Accept Types 15.7.1. Accept Types
Contact Information: Ben Campbell (ben@estacado.net) Contact Information: Ben Campbell (ben@estacado.net)
Attribute-name: accept-types Attribute-name: accept-types
Long-form Attribute Name: Acceptable MIME Types Long-form Attribute Name: Acceptable Media Types
Type: Media level Type: Media level
Subject to Charset Attribute: No Subject to Charset Attribute: No
Purpose and Appropriate Values: The "accept-types" attribute contains Purpose and Appropriate Values: The "accept-types" attribute
a list of MIME content-types that the endpoint is willing to contains a list of media-types that the endpoint is willing to
receive. It may contain zero or more registered MIME types, or receive. It may contain zero or more registered media-types, or
"*" in a space delimited string. "*" in a space delimited string.
15.7.2. Wrapped Types 15.7.2. Wrapped Types
Contact Information: Ben Campbell (ben@estacado.net) Contact Information: Ben Campbell (ben@estacado.net)
Attribute-name: accept-wrapped-types Attribute-name: accept-wrapped-types
Long-form Attribute Name: Acceptable MIME Types Inside Wrappers Long-form Attribute Name: Acceptable media-types Inside Wrappers
Type: Media level Type: Media level
Subject to Charset Attribute: No Subject to Charset Attribute: No
Purpose and Appropriate Values: The "accept-wrapped-types" attribute Purpose and Appropriate Values: The "accept-wrapped-types" attribute
contains a list of MIME content-types that the endpoint is willing contains a list of media types that the endpoint is willing to
to receive in an MSRP message with multipart content, but may not receive in an MSRP message with multipart content, but may not be
be used as the outermost type of the message. It may contain zero used as the outermost type of the message. It may contain zero or
or more registered MIME types, or "*" in a space delimited string. more registered media-types, or "*" in a space delimited string.
15.7.3. Max Size 15.7.3. Max Size
Contact Information: Ben Campbell (ben@estacado.net) Contact Information: Ben Campbell (ben@estacado.net)
Attribute-name: max-size Attribute-name: max-size
Long-form Attribute Name: Maximum message size. Long-form Attribute Name: Maximum message size.
Type: Media level Type: Media level
Subject to Charset Attribute: No Subject to Charset Attribute: No
Purpose and Appropriate Values: The "max-size" attribute indicates Purpose and Appropriate Values: The "max-size" attribute indicates
the largest message an endpoint wishes to accept. It may take any the largest message an endpoint wishes to accept. It may take any
skipping to change at page 54, line 39 skipping to change at page 58, line 4
Contact Information: Ben Campbell (ben@estacado.net) Contact Information: Ben Campbell (ben@estacado.net)
Attribute-name: max-size Attribute-name: max-size
Long-form Attribute Name: Maximum message size. Long-form Attribute Name: Maximum message size.
Type: Media level Type: Media level
Subject to Charset Attribute: No Subject to Charset Attribute: No
Purpose and Appropriate Values: The "max-size" attribute indicates Purpose and Appropriate Values: The "max-size" attribute indicates
the largest message an endpoint wishes to accept. It may take any the largest message an endpoint wishes to accept. It may take any
numeric value, specified in octets. numeric value, specified in octets.
15.7.4. Path 15.7.4. Path
Contact Information: Ben Campbell (ben@estacado.net) Contact Information: Ben Campbell (ben@estacado.net)
Attribute-name: path Attribute-name: path
Long-form Attribute Name: MSRP URL Path Long-form Attribute Name: MSRP URI Path
Type: Media level Type: Media level
Subject to Charset Attribute: No Subject to Charset Attribute: No
Purpose and Appropriate Values: The "path" attribute indicates a Purpose and Appropriate Values: The "path" attribute indicates a
series of MSRP devices that must be visited by messages sent in series of MSRP devices that must be visited by messages sent in
the session, including the final endpoint. The attribute contains the session, including the final endpoint. The attribute contains
one or more MSRP URIs, delimited by the space character. one or more MSRP URIs, delimited by the space character.
16. Contributors and Acknowledgments 16. Contributors and Acknowledgments
In addition to the editors, the following people contributed In addition to the editors, the following people contributed
skipping to change at page 55, line 25 skipping to change at page 58, line 34
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-26 (work in Description Protocol", RFC 4566, July 2006.
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.
[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 4234, October 2005.
[7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions [7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, (S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004. July 2004.
[8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [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.
[9] Troost, R., Dorner, S., and K. Moore, "Communicating [9] Troost, R., Dorner, S., and K. Moore, "Communicating
skipping to change at page 56, line 23 skipping to change at page 59, line 33
[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 [16] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure: Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[17] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)", Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-06 (work in progress), October 2005. RFC 4474, August 2006.
[17] Lennox, J., "Connection-Oriented Media Transport over the [18] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", draft-ietf-mmusic-comedia-tls-06 Description Protocol (SDP)", RFC 4572, July 2006.
(work in progress), March 2006.
17.2. Informational References 17.2. Informational References
[18] Johnston, A. and O. Levin, "Session Initiation Protocol Call [19] Johnston, A. and O. Levin, "Session Initiation Protocol Call
Control - Conferencing for User Agents", Control - Conferencing for User Agents", RFC 4579, August 2006.
draft-ietf-sipping-cc-conferencing-07 (work in progress),
June 2005.
[19] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, [20] 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.
[20] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation [21] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation
Protocol Call Control - Transfer", Protocol Call Control - Transfer",
draft-ietf-sipping-cc-transfer-06 (work in progress), draft-ietf-sipping-cc-transfer-07 (work in progress),
March 2006. October 2006.
[21] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and [22] 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] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for [23] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for
Message Sessions Relay Protocol (MSRP)", Message Sessions Relay Protocol (MSRP)",
draft-ietf-simple-msrp-relays-07 (work in progress), draft-ietf-simple-msrp-relays-08 (work in progress), July 2006.
February 2006.
[23] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE [24] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002. Method", RFC 3311, October 2002.
[24] Jennings, C. and J. Peterson, "Certificate Management Service [25] Jennings, C., Peterson, J., and J. Fischl, "Certificate
for SIP", draft-ietf-sipping-certs-03 (work in progress), Management Service for SIP", draft-ietf-sip-certs-01 (work in
March 2006. progress), June 2006.
[25] Yon, D. and G. Camarillo, "Connection-Oriented Media Transport [26] Yon, D. and G. Camarillo, "Connection-Oriented Media Transport
in SDP", rfc 4145, September 2005. in SDP", RFC 4145, September 2005.
[26] 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.
[27] 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.
[28] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone [29] 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.
[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
skipping to change at page 59, line 5 skipping to change at page 62, line 5
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
Phone: +1 408 421-9990 Phone: +1 408 421-9990
Email: fluffy@cisco.com Email: fluffy@cisco.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 59, line 29 skipping to change at page 62, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
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 provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 235 change blocks. 
416 lines changed or deleted 566 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/