draft-ietf-simple-message-sessions-11.txt   draft-ietf-simple-message-sessions-12.txt 
SIMPLE WG B. Campbell, Ed. SIMPLE WG B. Campbell, Ed.
Internet-Draft Estacado Systems Internet-Draft Estacado Systems
Expires: January 17, 2006 R. Mahy, Ed. Expires: April 9, 2006 R. Mahy, Ed.
blankespace blankespace
C. Jennings, Ed. C. Jennings, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
July 16, 2005 October 6, 2005
The Message Session Relay Protocol The Message Session Relay Protocol
draft-ietf-simple-message-sessions-11.txt draft-ietf-simple-message-sessions-12.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 17, 2006. This Internet-Draft will expire on April 9, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes the Message Session Relay Protocol, a This document describes the Message Session Relay Protocol, a
protocol for transmitting a series of related instant messages in the protocol for transmitting a series of related instant messages in the
context of a session. Message sessions are treated like any other context of a session. Message sessions are treated like any other
media stream when setup via a rendezvous or session setup protocol media stream when setup via a rendezvous or session setup protocol
such as the Session Initiation Protocol. such as the Session Initiation Protocol.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability of MSRP . . . . . . . . . . . . . . . . . . . 5 3. Applicability of MSRP . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
5. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1 MSRP Framing and Message Chunking . . . . . . . . . . . . 9 5.1. MSRP Framing and Message Chunking . . . . . . . . . . . . 9
5.2 MSRP Addressing . . . . . . . . . . . . . . . . . . . . . 10 5.2. MSRP Addressing . . . . . . . . . . . . . . . . . . . . . 10
5.3 MSRP Transaction and Report Model . . . . . . . . . . . . 10 5.3. MSRP Transaction and Report Model . . . . . . . . . . . . 10
5.4 MSRP Connection Model . . . . . . . . . . . . . . . . . . 12 5.4. MSRP Connection Model . . . . . . . . . . . . . . . . . . 12
6. MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 15 6.1. MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 15
6.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 15 6.2. Resolving MSRP Host Device . . . . . . . . . . . . . . . 15
7. Method-Specific Behavior . . . . . . . . . . . . . . . . . . 16 7. Method-Specific Behavior . . . . . . . . . . . . . . . . . . . 16
7.1 Constructing Requests . . . . . . . . . . . . . . . . . . 16 7.1. Constructing Requests . . . . . . . . . . . . . . . . . . 16
7.1.1 Sending SEND requests . . . . . . . . . . . . . . . . 17 7.1.1. Sending SEND Requests . . . . . . . . . . . . . . . . 17
7.1.2 Sending REPORT requests . . . . . . . . . . . . . . . 20 7.1.2. Sending REPORT Requests . . . . . . . . . . . . . . . 20
7.1.3 Failure REPORT Generation . . . . . . . . . . . . . . 21 7.1.3. Generate Failure REPORTs . . . . . . . . . . . . . . . 21
7.2 Constructing Responses . . . . . . . . . . . . . . . . . . 22 7.2. Constructing Responses . . . . . . . . . . . . . . . . . 22
7.3 Receiving Requests . . . . . . . . . . . . . . . . . . . . 23 7.3. Receiving Requests . . . . . . . . . . . . . . . . . . . 23
7.3.1 Receiving SEND requests . . . . . . . . . . . . . . . 23 7.3.1. Receiving SEND Requests . . . . . . . . . . . . . . . 23
7.3.2 Receiving REPORT requests . . . . . . . . . . . . . . 25 7.3.2. Receiving REPORT Requests . . . . . . . . . . . . . . 25
8. Using MSRP with SIP . . . . . . . . . . . . . . . . . . . . 26 8. Using MSRP with SIP and SDP . . . . . . . . . . . . . . . . . 26
8.1 SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . 26 8.1. SDP Connection and Media Lines . . . . . . . . . . . . . 26
8.1.1 URL Negotiations . . . . . . . . . . . . . . . . . . . 28 8.2. URL Negotiations . . . . . . . . . . . . . . . . . . . . 27
8.1.2 Path Attributes with Multiple URLs . . . . . . . . . . 29 8.3. Path Attributes with Multiple URLs . . . . . . . . . . . 28
8.1.3 SDP Connection and Media Lines . . . . . . . . . . . . 30 8.4. Updated SDP Offers . . . . . . . . . . . . . . . . . . . 29
8.1.4 Updated SDP Offers . . . . . . . . . . . . . . . . . . 30 8.5. Connection Negotiation . . . . . . . . . . . . . . . . . 29
8.1.5 Example SDP Exchange . . . . . . . . . . . . . . . . . 31 8.6. Content Type Negotiation . . . . . . . . . . . . . . . . 30
8.1.6 Connection Negotiation . . . . . . . . . . . . . . . . 31 8.7. Example SDP Exchange . . . . . . . . . . . . . . . . . . 31
8.2 MSRP User Experience with SIP . . . . . . . . . . . . . . 32 8.8. MSRP User Experience with SIP . . . . . . . . . . . . . . 32
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 32 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 32
10. Response Code Descriptions . . . . . . . . . . . . . . . . . 35 10. Response Code Descriptions . . . . . . . . . . . . . . . . . . 35
10.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.1. 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.2. 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.3 403 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.3. 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.4 408 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.4. 408 . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.5 413 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.5. 413 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.6 415 . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.6. 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.7 423 . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.7. 423 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.8 426 . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.8. 426 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.9 481 . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.9. 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.10 501 . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.10. 501 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.11 506 . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.11. 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 36 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
11.1 Basic IM session . . . . . . . . . . . . . . . . . . . . 37 11.1. Basic IM Session . . . . . . . . . . . . . . . . . . . . 37
11.2 Message with XHTML Content . . . . . . . . . . . . . . . 39 11.2. Message with XHTML Content . . . . . . . . . . . . . . . 39
11.3 Chunked Message . . . . . . . . . . . . . . . . . . . . 39 11.3. Chunked Message . . . . . . . . . . . . . . . . . . . . . 39
11.4 System Message . . . . . . . . . . . . . . . . . . . . . 39 11.4. System Message . . . . . . . . . . . . . . . . . . . . . 39
11.5 Positive Report . . . . . . . . . . . . . . . . . . . . 40 11.5. Positive Report . . . . . . . . . . . . . . . . . . . . . 40
11.6 Forked IM . . . . . . . . . . . . . . . . . . . . . . . 40 11.6. Forked IM . . . . . . . . . . . . . . . . . . . . . . . . 40
12. Extensibility . . . . . . . . . . . . . . . . . . . . . . . 44 12. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 44
13. CPIM compatibility . . . . . . . . . . . . . . . . . . . . . 44 13. CPIM Compatibility . . . . . . . . . . . . . . . . . . . . . . 44
14. Security Considerations . . . . . . . . . . . . . . . . . . 45 14. Security Considerations . . . . . . . . . . . . . . . . . . . 45
14.1 Transport Level Protection . . . . . . . . . . . . . . . 45 14.1. Transport Level Protection . . . . . . . . . . . . . . . 45
14.2 S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . 46 14.2. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . 47
14.3 Other Security Concerns . . . . . . . . . . . . . . . . 47 14.3. Other Security Concerns . . . . . . . . . . . . . . . . . 47
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 49 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
15.1 MSRP Method Names . . . . . . . . . . . . . . . . . . . 49 15.1. MSRP Method Names . . . . . . . . . . . . . . . . . . . . 49
15.2 MSRP Header Fields . . . . . . . . . . . . . . . . . . . 49 15.2. MSRP Header Fields . . . . . . . . . . . . . . . . . . . 49
15.3 MSRP Status Codes . . . . . . . . . . . . . . . . . . . 50 15.3. MSRP Status Codes . . . . . . . . . . . . . . . . . . . . 50
15.4 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . 50 15.4. MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 50
15.5 MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . 50 15.5. MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . 50
15.6 SDP Transport Protocol . . . . . . . . . . . . . . . . . 50 15.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . 51
15.7 SDP Attribute Names . . . . . . . . . . . . . . . . . . 51 15.7. SDP Attribute Names . . . . . . . . . . . . . . . . . . . 51
15.7.1 Accept Types . . . . . . . . . . . . . . . . . . . . 51 15.7.1. Accept Types . . . . . . . . . . . . . . . . . . . . . 51
15.7.2 Wrapped Types . . . . . . . . . . . . . . . . . . . 51 15.7.2. Wrapped Types . . . . . . . . . . . . . . . . . . . . 51
15.7.3 Max Size . . . . . . . . . . . . . . . . . . . . . . 51 15.7.3. Max Size . . . . . . . . . . . . . . . . . . . . . . . 52
15.7.4 Path . . . . . . . . . . . . . . . . . . . . . . . . 52 15.7.4. Path . . . . . . . . . . . . . . . . . . . . . . . . . 52
16. Contributors and Acknowledgments . . . . . . . . . . . . . . 52 16. Contributors and Acknowledgments . . . . . . . . . . . . . . . 52
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
17.1 Normative References . . . . . . . . . . . . . . . . . . 52 17.1. Normative References . . . . . . . . . . . . . . . . . . 52
17.2 Informational References . . . . . . . . . . . . . . . . 53 17.2. Informational References . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . 56 Intellectual Property and Copyright Statements . . . . . . . . . . 57
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 completely independently. contrast to individual messages each sent independently. Messaging
Messaging schemes that only track individual messages can be schemes that track only individual messages can be described as
described as "page-mode" messaging, whereas messaging that is part of "page-mode" messaging, whereas messaging that is part of a "session"
a "session" with a definite start and end is called "session-mode" with a definite start and end is called "session-mode" messaging.
messaging.
Page-mode messaging is enabled in SIP via the SIP [4] MESSAGE method Page-mode messaging is enabled in SIP via the SIP [4] MESSAGE method
[19]. Session-mode messaging has a number of benefits [20] over [19]. Session-mode messaging has a number of benefits [20] over
page-mode messaging however, such as explicit rendezvous, tighter page-mode messaging, however, such as explicit rendezvous, tighter
integration with other media types, direct client-to-client integration with other media types, direct client-to-client
operation, and brokered privacy and security. operation, and brokered privacy and security.
This document defines a session-oriented instant message transport This document defines a session-oriented instant message transport
protocol called the Message Session Relay Protocol (MSRP), whose protocol called the Message Session Relay Protocol (MSRP), whose
sessions can be negotiated with an offer or answer [3] using the sessions can be negotiated with an offer or answer [3] using the
Session Description Protocol(SDP [2]). The exchange is carried by Session Description Protocol(SDP [2]). The exchange is carried by
some signaling protocol, such as the Session Initiation Protocol (SIP some signaling protocol, such as the Session Initiation Protocol (SIP
[4]). This allows a communication user agent to offer a messaging [4]). This allows a communication user agent to offer a messaging
session as one of the possible media types in a session. For session as one of the possible media types in a session. For
skipping to change at page 4, line 41 skipping to change at page 4, line 40
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 [31] defines how DNS can be used
to map this to a particular protocol to establish the session such as to map this to a particular protocol to establish the session such as
SIP. SIP can use an offer answer model to transport the MSRP URLs SIP. SIP can use an offer answer model to transport the MSRP URLs
for the media in SDP. This document defines how the offer-answer for the media in SDP. This document defines how the offer/answer
exchange works to establish MSRP connections and how messages are exchange works to establish MSRP connections and how messages are
sent across the MSRP protocol but it does not deal with the issues of sent across the MSRP protocol, but it does not deal with the issues
mapping an IM URL to a session establishment protocol. of mapping an IM URL to a session establishment protocol.
This session model allows message sessions to be integrated into This session model allows message sessions to be integrated into
advanced communications applications with little to no additional advanced communications applications with little to no additional
protocol development. For example, during the above chat session, protocol development. For example, during the above chat session,
Bob decides Alice really needs to be talking to Carol. Bob can Bob decides Alice really needs to be talking to Carol. Bob can
transfer [18] Alice to Carol, introducing them into their own transfer [18] 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 utilizing third-party call into call-center and dispatch environments using third-party call
control [17] and conferencing [16] applications. control [17] and conferencing [16] applications.
This document specifies MSRP behavior only for peer-to-peer sessions, This document specifies MSRP behavior only for peer-to-peer sessions,
that is, sessions crossing only a single hop. However, work to that is, sessions crossing only a single hop. However, work to
specify behavior for MSRP relay devices [21] (referred to herein as specify behavior for MSRP relay devices [21] (referred to herein as
"relays") is occurring as a separate effort. "relays") is occurring as a separate effort.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [5]. document are to be interpreted as described in RFC-2119 [5].
This document consistently refers to a "message" as a complete unit This document consistently refers to a "message" as a complete unit
of MIME or text content. In some cases a message is split and of MIME or text content. In some cases, a message is split and
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 The rendezvous mechanism MUST provide both MSRP URLs associated
skipping to change at page 6, line 21 skipping to change at page 6, line 21
MSRP is a text-based, connection-oriented protocol for exchanging MSRP is a text-based, connection-oriented protocol for exchanging
arbitrary (binary) MIME content, especially instant messages. This arbitrary (binary) MIME content, especially instant messages. This
section is a non-normative overview of how MSRP works and how it is section is a non-normative overview of how MSRP works and how it is
used with SIP. 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 setup. One SIP user agent (Alice) sends of audio or video media is setup. 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 answer session- agent can accept the invitation and include an answer session-
description which acknowledges the choice of media. Alice's session description which acknowledges the choice of media. Alice's session
description contains an MSRP URL that describes where she is willing description contains an MSRP URL that describes where she is willing
to receive MSRP requests from Bob, and vice-versa. (Note: Some lines to receive MSRP requests from Bob, and vice-versa. (Note: Some lines
in the examples are removed for clarity and brevity.) in the examples are removed for clarity and brevity.)
Alice sends to Bob: Alice sends to Bob:
INVITE sip:bob@atlanta.example.com SIP/2.0 INVITE sip:bob@atlanta.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
skipping to change at page 8, line 18 skipping to change at page 8, line 18
Message-ID: 87652 Message-ID: 87652
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/jshA7we;tcp
From-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp From-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp
Message-ID: 87652
Byte-Range: 1-25/25 Byte-Range: 1-25/25
-------a786hjs2$ -------a786hjs2$
Alice's request begins with the MSRP start line, which contains a Alice's request begins with the MSRP start line, which contains a
transaction identifier that is also used for request framing. Next transaction identifier that is also used for request framing. Next
she includes the path of URLs to the destination in the To-Path she includes the path of URLs to the destination in the To-Path
header, and her own URL in the From-Path header. In this typical header field, and her own URL in the From-Path header field. In this
case there is just one "hop", so there is only one URL in each path typical case there is just one "hop", so there is only one URL in
header field. She also includes a message ID which she can use to each path header field. She also includes a message ID which she can
correlate responses and status reports with the original message. use to correlate status reports with the original message. Next she
Next she puts the actual content. Finally she closes the request puts the actual content. Finally she closes the request with an end-
with an end-line seven hyphens, the transaction identifier and a "$" line seven hyphens, the transaction identifier and a "$" to indicate
to indicate this request contains the end of a complete message. this request contains the end of a complete message.
If Alice wants to deliver a very large message, she can split the If Alice wants to deliver a very large message, she can split the
message into chunks and deliver each chunk in a separate SEND message into chunks and deliver each chunk in a separate SEND
request. The message ID corresponds to the whole message, so the request. The message ID corresponds to the whole message, so the
receiver can also use it to reassemble the message and tell which receiver can also use it to reassemble the message and tell which
chunks belong with which message. Chunking is described in more chunks belong with which message. Chunking is described in more
detail in Section 5.1. The Byte-Range header identifies the portion detail in Section 5.1. The Byte-Range header field identifies the
of the message carried in this chunk and the total size of the portion of the message carried in this chunk and the total size of
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 generally choose their MSRP URLs in such a way that is
difficult to guess the exact URL. Alice and Bob can reject requests difficult to guess the exact URL. Alice and Bob can reject requests
skipping to change at page 9, line 29 skipping to change at page 9, line 28
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.
5. Key Concepts 5. Key Concepts
5.1 MSRP Framing and Message Chunking 5.1. MSRP Framing and Message Chunking
Messages sent using MSRP can be very large and can be delivered in Messages sent using MSRP can be very large and can be delivered in
several SEND requests, where each SEND request contains one chunk of several SEND requests, where each SEND request contains one chunk of
the overall message. Long chunks may be interrupted in mid- the overall message. Long chunks may be interrupted in mid-
transmission to ensure fairness across shared transport connections. transmission to ensure fairness across shared transport connections.
To support this, MSRP uses a boundary based framing mechanism. The To support this, MSRP uses a boundary based framing mechanism. The
start line of an MSRP request contains a unique identifier that is start line of an MSRP request contains a unique identifier that is
also used to indicate the end of the request. Included at the end of also used to indicate the end of the request. Included at the end of
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
in the request that indicates the overall position of this chunk field in the request that indicates the overall position of this
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: 456
Byte-Range: 1-4/8 Byte-Range: 1-4/8
Content-Type: text/plain Content-Type: text/plain
abcd abcd
skipping to change at page 10, line 30 skipping to change at page 10, line 30
This chunking mechanism allows a sender to interrupt a chunk part of This chunking mechanism allows a sender to interrupt a chunk part of
the way through sending it. The ability to interrupt messages allows the way through sending it. The ability to interrupt messages allows
multiple sessions to share a TCP connection, and for large messages multiple sessions to share a TCP connection, and for large messages
to be sent efficiently while not blocking other messages that share to be sent efficiently while not blocking other messages that share
the same connection. Any chunk that is larger than 2048 octets MUST the same connection. Any chunk that is larger than 2048 octets MUST
be interruptible. While MSRP would be simpler to implement if each be interruptible. While MSRP would be simpler to implement if each
MSRP session used its own TCP connection, that approach would MSRP session used its own TCP connection, that approach would
circumvent the congestion avoidance features of TCP. circumvent the congestion avoidance features of TCP.
5.2 MSRP Addressing 5.2. MSRP Addressing
MSRP entities are addressed using URLs. The MSRP URL schemes are MSRP entities are addressed using URLs. The MSRP URL schemes are
defined in Section 6. The syntax of the To-Path and From-Path defined in Section 6. The syntax of the To-Path and From-Path header
headers each allow for a list of URLs. This was done to allow the fields each allow for a list of URLs. This was done to allow the
protocol to work with gateways or relays defined in the future, to protocol to work with gateways or relays defined in the future, to
provide a complete path to the end recipient. When two MSRP nodes provide a complete path to the end recipient. When two MSRP nodes
communicate directly they need only one URL in the To-Path list and communicate directly they need only one URL in the To-Path list and
one URL in the From-Path list. one URL in the From-Path list.
5.3 MSRP Transaction and Report Model 5.3. MSRP Transaction and Report Model
A sender sends MSRP requests to a receiver. The receiver MUST A sender sends MSRP requests to a receiver. The receiver MUST
quickly accept or reject the request. If the receiver initially quickly accept or reject the request. If the receiver initially
accepted the request, it still may then do things that take accepted the request, it still may then do things that take
significant time to succeed or fail. For example, if the receiver is significant time to succeed or fail. For example, if the receiver is
an MSRP to XMPP [29] gateway, it may forward the message over XMPP. an MSRP to XMPP [29] gateway, it may forward the message over XMPP.
The XMPP side may later indicate that the request did not work. At The XMPP side may later indicate that the request did not work. At
this point, the MSRP receiver may need to indicate that the request this point, the MSRP receiver may need to indicate that the request
did not succeed. There are two important concepts here: first, the did not succeed. There are two important concepts here: first, the
hop by hop delivery of the request may succeed or fail; second, the hop by hop delivery of the request may succeed or fail; second, the
skipping to change at page 11, line 22 skipping to change at page 11, line 22
successfully delivered, and the sender requested a success report. A successfully delivered, and the sender requested a success report. A
receiver only sends a failure REPORT if the request failed to be receiver only sends a failure REPORT if the request failed to be
delivered and the sender requested failure reports. delivered and the sender requested failure reports.
This document describes the behavior of MSRP endpoints. MSRP This document describes the behavior of MSRP endpoints. MSRP
relays or gateways are likely to have additional conditions that relays or gateways are likely to have additional conditions that
indicate a failure REPORT should be sent, such as the failure to indicate a failure REPORT should be sent, such as the failure to
receive a positive response from the next hop. receive a positive response from the next hop.
Two header fields control the sender's desire to receive reports. Two header fields control the sender's desire to receive reports.
The header "Success-Report" can have a value of "yes" or "no" and the The header field "Success-Report" can have a value of "yes" or "no"
"Failure-Report" header can have a value of "yes", "no", or and the "Failure-Report" header field can have a value of "yes",
"partial". "no", or "partial".
The combinations of reporting are needed to meet the various The combinations of reporting are needed to meet the various
scenarios of currently deployed IM systems. Success-Report might be scenarios of currently deployed IM systems. Success-Report might be
"no" in many public systems to reduce load but might be "yes" in "no" in many public systems to reduce load but might be "yes" in
certain enterprise systems, such as systems used for securities certain enterprise systems, such as systems used for securities
trading. A Failure-Report value of "no" is useful for sending system trading. A Failure-Report value of "no" is useful for sending system
messages such as "the system is going down in 5 minutes" without messages such as "the system is going down in 5 minutes" without
causing a response explosion to the sender. A Failure-Report of causing a response explosion to the sender. A Failure-Report of
"yes" is used by many systems that wish to notify the user if the "yes" is used by many systems that wish to notify the user if the
message failed. A Failure-Report of "partial" is a way to report message failed. A Failure-Report of "partial" is a way to report
errors other than timeouts. The timeout error reporting requires the errors other than timeouts. The timeout error reporting requires the
sending hop to run a timer and the receiving hop to send an sending hop to run a timer and the receiving hop to send an
acknowledgment to stop the timer. Some systems don't want the acknowledgment to stop the timer. Some systems don't want the
overhead of doing this so choose not to but still allow error overhead of doing this. "Partial" allows them to choose not to so,
responses to be sent in many cases and these systems can use but still allows error responses to be sent in many cases.
"partial".
The "partial" value allows a compromise between no reporting of The "partial" value allows a compromise between no reporting of
failures, and reporting all failures. For example, with failures, and reporting all failures. For example, with
"partial", an sending device does not have keep transaction state "partial", an sending device does not have keep transaction state
around waiting for a positive acknowledgement. But it still around waiting for a positive acknowledgment. But it still allows
allows devices to report other types of errors. For example, the devices to report other types of errors. For example, the
receiving device could still report a policy violation such as an receiving device could still report a policy violation such as an
unacceptable content-type, or an ICMP error trying to connect to a unacceptable content-type, or an ICMP error trying to connect to a
downstream device. downstream device.
5.4 MSRP Connection Model 5.4. MSRP Connection Model
When MSRP wishes to send a request to a peer identified by an MSRP When an MSRP endpoint wishes to send a request to a peer identified
URL, it first needs a transport connection, with the appropriate by an MSRP URL, it first needs a transport connection, with the
security properties, to the host specified in the URL. If the sender appropriate security properties, to the host specified in the URL.
already has such a connection, that is, one associated with the same If the sender already has such a connection, that is, one associated
host, port, and URL scheme, then it SHOULD reuse that connection. with the same host, port, and URL scheme, then it SHOULD reuse that
connection.
When a new MSRP session is created, the offerer MUST act as the When a new MSRP session is created, the offerer MUST act as the
"active" endpoint, meaning that it is responsible for opening the "active" endpoint, meaning that it is responsible for opening the
transport connection to the answerer, if a new connection is 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.
This initial SEND request MAY have a body if the sender has content This initial SEND request MAY have a body if the sender has content
to send, or it MAY have no body at all. to send, or it MAY have no body at all.
The first SEND request servers 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 URL
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 URL, following the URL resolution rules in
skipping to change at page 12, line 51 skipping to change at page 12, line 52
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 immediately know the identity of the connecting host.
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 handed out in the SDP for a contain a URL 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 URL
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 URL 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
skipping to change at page 13, line 28 skipping to change at page 13, line 29
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
not be confirmed. If it does this, the Message-ID values for the not be confirmed. If it does this, the Message-ID values for the
resent messages MUST match those used in the initial attempts. If resent messages MUST match those used in the initial attempts. If
the receiving endpoint receives more than one message with the same the receiving endpoint receives more than one message with the same
Message-ID. It SHOULD assume that the messages are duplicates. It Message-ID, it SHOULD assume that the messages are duplicates. The
MAY take any action based on that knowledge, but SHOULD NOT present specific action that an endpoint takes when it receives a duplicate
the duplicate messages to the user without warning of the message is a matter of local policy, except that it SHOULD NOT
duplication. Note that acknowledgements as needed based on the present the duplicate messages to the user without warning of the
Failure-Report and Success-Report settings is still necessary even duplication. Note that acknowledgments as needed based on the
Failure-Report and Success-Report settings are still necessary even
for requests containing duplicate content. for requests containing duplicate content.
In this situation, the endpoint MUST ensure that the Message-ID of
each distinct (i.e. non-duplicate) message is unique in the context
of both the original session and the replacement session.
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 URLs in the SDP will be the same as
the old ones. the old ones.
A connection SHOULD NOT be closed while there are sessions associated A connection SHOULD NOT be closed while there are sessions associated
skipping to change at page 15, line 14 skipping to change at page 15, line 10
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 URL:
msrp://host.example.com:8493/asfd34;tcp msrp://host.example.com:8493/asfd34;tcp
6.1 MSRP URL Comparison 6.1. MSRP URL Comparison
MSRP URL comparisons MUST be performed according to the following MSRP URL comparisons MUST be performed according to the following
rules: rules:
1. The 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.
skipping to change at page 15, line 42 skipping to change at page 15, line 38
5. URLs with different "transport" parameters never match. Two URLs 5. URLs with different "transport" parameters never match. Two URLs
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 URL comparison.
Path normalization is not relevant for MSRP URLs. Escape Path normalization is not relevant for MSRP URLs. 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 URL.
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.
skipping to change at page 16, line 27 skipping to change at page 16, line 23
relay specification [21] may describe additional steps to resolve relay specification [21] 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 unique transaction
identifier and uses this and the method name to create an MSRP identifier and uses this and the method name to create an MSRP
request start line. Next, the sender places the target URL in a To- request start line. Next, the sender places the target URL in a To-
Path header, and the sender's URL in a From-Path header. If multiple Path header field, and the sender's URL in a From-Path header field.
URLs are present in the To-Path, the leftmost is the first URL If multiple URLs are present in the To-Path, the leftmost is the
visited; the rightmost URL is the last URL visited. The processing first URL visited; the rightmost URL is the last URL visited. The
then becomes method specific. Additional method-specific headers are processing then becomes method specific. Additional method-specific
added as described in the following sections. header fields are added as described in the following sections.
After any method-specific headers are added, processing continues to After any method-specific header fields are added, processing
handle a body, if present. A body in a non-SEND request MUST NOT be continues to handle a body, if present. A body in a non-SEND request
longer than 2048 octets. If the request has a body, it must contain MUST NOT be longer than 2048 octets. If the request has a body, it
a Content-Type header field. It may contain other MIME-specific must contain a Content-Type header field. It may contain other MIME-
headers. The Content-Type header MUST be the last header line. The specific header fields. The Content-Type header field MUST be the
body MUST be separated from the headers with an extra CRLF. last field in the message header section. The body MUST be separated
from the header fields with an extra CRLF.
A request with no body MUST NOT include a Content-Type header field. A request with no body MUST NOT include a Content-Type header field.
Note that, if no body is present, no extra CRLF will be present Note that, if no body is present, no extra CRLF will be present
between the headers and the end-line. between the header section and the end-line.
Requests with no bodies are useful when a client wishes to send Requests with no bodies are useful when a client wishes to send
"traffic", but does not wish to send content to be rendered to the "traffic", but does not wish to send content to be rendered to the
peer user. For example, the offerer must send a SEND request peer user. For example, the offerer must send a SEND request
immediately upon establishing a connection. If it has nothing to immediately upon establishing a connection. If it has nothing to
say at the moment, it can send a request with no body. Bodiless say at the moment, it can send a request with no body. Bodiless
requests may also be used in certain applications to keep NAT requests may also be used in certain applications to keep NAT
bindings alive, etc. bindings alive, etc.
Bodiless requests are distinct from requests with empty bodies. Bodiless requests are distinct from requests with empty bodies. A
An request with an empty body will have a Content-Type header request with an empty body will have a Content-Type header field
value, and will generally be rendered to the recipient according value, and will generally be rendered to the recipient according
to the rules for that type. to the rules for that type.
The end-line that terminates the request MUST be composed of seven The end-line that terminates the request MUST be composed of seven
"-" (minus sign) characters, the transaction ID as used in the start "-" (minus sign) characters, the transaction ID as used in the start
line, and a flag character. If a body is present, the end-line must line, and a flag character. If a body is present, the end-line must
be followed by a CRLF that is not part of the body. If the chunk be followed by a CRLF that is not part of the body. If the chunk
represents the data that forms the end of the complete message, the represents the data that forms the end of the complete message, the
flag value MUST be a "$". If sender is aborting an incomplete flag value MUST be a "$". If sender is aborting an incomplete
message, and intends to send no further chunks in that message, it message, and intends to send no further chunks in that message, it
skipping to change at page 17, line 37 skipping to change at page 17, line 35
Some implementations may choose to implement this such that if they Some implementations may choose to implement this such that if they
find the closing sequence in the body of the message they are find the closing sequence in the body of the message they are
sending, simply interrupting the message at that point and starting a sending, simply interrupting the message at that point and starting a
new transaction with a different transaction identifier to carry the new transaction with a different transaction identifier to carry the
rest of the body. Other implementation may choose to scan the data rest of the body. Other implementation may choose to scan the data
an ensure that the body does not contain the transaction identifier an ensure that the body does not contain the transaction identifier
before they start sending the transaction. before they start sending the transaction.
Finally, requests which have no body MUST NOT contain a Content-Type Finally, requests which have no body MUST NOT contain a Content-Type
header or any other MIME specific header. Requests without bodies header field or any other MIME specific header field. Requests
MUST contain a end-line after the final header. 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
unique Message-ID. This ID MUST be globally unique. If necessary, Message-ID. This ID MUST be globally unique. If necessary, it
it breaks the message into chunks. It then generates a SEND request breaks the message into chunks. It then generates a SEND request for
for each chunk, following the procedures for constructing requests each chunk, following the procedures for constructing requests
(Section 7.1). (Section 7.1).
The Message-ID header field provides a unique message identifier The Message-ID header field provides a globally unique message
that refers to a particular version of a particular message. The identifier that refers to a particular version of a particular
term "Message" in this context refers to a unit of content that message. The term "Message" in this context refers to a unit of
the sender wishes to convey to the recipient. While such a content that the sender wishes to convey to the recipient. While
message may be broken into chunks, the Message-ID refers to the such a message may be broken into chunks, the Message-ID refers to
entire message, not a chunk of the message. the 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 guaranteed 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.
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 is "yes", the sending device MAY wish to run a timer of Report header field is "yes", the sending device MAY wish to run a
some value that makes sense for its application and take action if a timer of some value that makes sense for its application and take
success Report is not received in this time. There is no universal action if a success Report is not received in this time. There is no
value for this timer. For many IM applications, it may be 2 minutes universal value for this timer. For many IM applications, it may be
while for some trading systems it may be under a second. Regardless 2 minutes while for some trading systems it may be under a second.
of whether such a timer is used, if the success report has not been Regardless of whether such a timer is used, if the success report has
received by the time the session is ended, the device SHOULD inform not been received by the time the session is ended, the device SHOULD
the user. inform the user.
If the value of "Failure-Report" is set to "yes", then the sender of If the value of "Failure-Report" is set to "yes", then the sender of
the request runs a timer. If a 200 response to the transaction is the request runs a timer. If a 200 response to the transaction is
not received within 30 seconds from the time the last byte of the not received within 30 seconds from the time the last byte of the
transaction is sent, or submitted to the operating system for transaction is sent, or submitted to the operating system for
sending, the element MUST inform the user that the request probably sending, the element MUST inform the user that the request probably
failed. If the value is set to "partial", then the element sending failed. If the value is set to "partial", then the element sending
the transaction does not have to run a timer, but MUST inform the the transaction does not have to run a timer, but MUST inform the
user if it receives a non-recoverable error response to the user if it receives a non-recoverable error response to the
transaction. transaction.
If no Success-Report header is present in a SEND request, it MUST be If no Success-Report header field is present in a SEND request, it
treated the same as a Success-Report header with value of "no". If MUST be treated the same as a Success-Report header field with value
no Failure-Report header is present, it MUST be treated the same as a of "no". If no Failure-Report header field is present, it MUST be
Failure-Report header with value of "yes". If an MSRP endpoint treated the same as a Failure-Report header field with value of
receives a REPORT for a Message-ID it does not recognize, it SHOULD "yes". If an MSRP endpoint receives a REPORT for a Message-ID it
silently ignore the REPORT. does not recognize, it SHOULD silently ignore the REPORT.
Success-Report and Failure-Report MUST NOT be present in REPORT Success-Report and Failure-Report header fields MUST NOT be present
requests. MSRP nodes MUST NOT send REPORT requests in response to in REPORT requests. MSRP nodes MUST NOT send REPORT requests in
report requests. MSRP Nodes MUST NOT send MSRP responses to REPORT response to REPORT requests. MSRP Nodes MUST NOT send MSRP responses
requests. to REPORT requests.
The Byte-Range header value contains a starting value (range-start) The Byte-Range header field value contains a starting value (range-
followed by a "-", an ending value (range-end) followed by a "/", and start) followed by a "-", an ending value (range-end) followed by a
finally the total length. The first octet in the message has a "/", and finally the total length. The first octet in the message
position of one, rather than a zero. has a position of one, rather than a zero.
The first chunk of the message SHOULD, and all subsequent chunks MUST The first chunk of the message SHOULD, and all subsequent chunks MUST
include a Byte-Range header field. The range-start field MUST include a Byte-Range header field. The range-start field MUST
indicate the position of the first byte in the body in the overall indicate the position of the first byte in the body in the overall
message (for the first chunk this field will have a value of one). message (for the first chunk this field will have a value of one).
The range-end field SHOULD indicate the position of the last byte in The range-end field SHOULD indicate the position of the last byte in
the body, if known. It MUST take the value of "*" if the position is the body, if known. It MUST take the value of "*" if the position is
unknown, or if the request needs to be interruptible. The total unknown, or if the request needs to be interruptible. The total
field SHOULD contain the total size of the message, if known. The field SHOULD contain the total size of the message, if known. The
total field MAY contain a "*" if the total size of the message is not total field MAY contain a "*" if the total size of the message is not
skipping to change at page 19, line 48 skipping to change at page 19, line 48
the connection. All MSRP nodes MUST be able to receive chunks of any the connection. All MSRP nodes MUST be able to receive chunks of any
size from zero octets to the maximum number of octets they can size from zero octets to the maximum number of octets they can
receive for a complete message. Senders SHOULD NOT break messages receive for a complete message. Senders SHOULD NOT break messages
into chunks smaller than 2048 octets, except for the final chunk of a into chunks smaller than 2048 octets, except for the final chunk of a
complete message. complete message.
A SEND request is interrupted while a body is in the process of being A SEND request is interrupted while a body is in the process of being
written to the connection by simply noting how much of the message written to the connection by simply noting how much of the message
has already been written to the connection, then writing out the end- has already been written to the connection, then writing out the end-
line to end the chunk. It can then be resumed in a another chunk line to end the chunk. It can then be resumed in a another chunk
with the same Message-ID and a Byte-Range header range start field with the same Message-ID and a Byte-Range header field range start
containing the position of the first byte after the interruption field containing the position of the first byte after the
occurred. interruption occurred.
SEND requests larger than 2048 octets MUST be interrupted if the SEND requests larger than 2048 octets MUST be interrupted if the
sender needs to send pending responses or REPORT requests. If sender needs to send pending responses or REPORT requests. If
multiple SEND requests from different sessions are concurrently being multiple SEND requests from different sessions are concurrently being
sent over the same connection, the device SHOULD implement some sent over the same connection, the device SHOULD implement some
scheme to alternate between them such that each concurrent request scheme to alternate between them such that each concurrent request
gets a chance to send some fair portion of data at regular intervals gets a chance to send some fair portion of data at regular intervals
suitable to the application. suitable to the application.
The sender MUST NOT assume that a message is received by the peer The sender MUST NOT assume that a message is received by the peer
with the same chunk allocation with which it was sent. An with the same chunk allocation with which it was sent. An
intervening relay could possibly break SEND requests into smaller intervening relay could possibly break SEND requests into smaller
chunks, or aggregate multiple chunks into larger ones. chunks, or aggregate multiple chunks into larger ones.
The default disposition of bodies is "render". If the sender wants The default disposition of bodies is "render". If the sender wants
different disposition, it MAY insert a Content-Disposition header. different disposition, it MAY insert a Content-Disposition header
Since MSRP is a binary protocol, transfer encoding is always field. Since MSRP is a binary protocol, transfer encoding is always
"binary", and transfer-encoding parameters MUST NOT be present. "binary", and transfer-encoding parameters MUST NOT be present.
7.1.2 Sending REPORT requests 7.1.2. Sending REPORT Requests
REPORT requests are similar to SEND requests, except that report REPORT requests are similar to SEND requests, except that report
requests MUST NOT include Success-Report or Failure-Report header requests MUST NOT include Success-Report or Failure-Report header
fields, and MUST contain a Status header field. REPORT requests MUST fields, and MUST contain a Status header field. REPORT requests MUST
contain the Message-ID header from the original SEND request. contain the Message-ID header field from the original SEND request.
If an MSRP element receives a REPORT for a Message-ID it does not If an MSRP element receives a REPORT for a Message-ID it does not
recognize, it SHOULD silently ignore the REPORT. recognize, it SHOULD silently ignore the REPORT.
An MSRP endpoint MUST be able to generate success REPORT requests. An MSRP endpoint MUST be able to generate success REPORT requests.
REPORT requests will normally not include a body, as the REPORT REPORT requests will normally not include a body, as the REPORT
request header fields can carry sufficient information in most cases. request header fields can carry sufficient information in most cases.
However, REPORT requests MAY include a body containing additional However, REPORT requests MAY include a body containing additional
information about the status of the associated SEND request. Such a information about the status of the associated SEND request. Such a
skipping to change at page 20, line 51 skipping to change at page 20, line 51
Since REPORT requests are not interruptible, the size of such a body Since REPORT requests are not interruptible, the size of such a body
MUST NOT exceed 2048 octets. MUST NOT exceed 2048 octets.
An endpoint MUST send a success report if it successfully receives a An endpoint MUST send a success report if it successfully receives a
SEND request which contained a Success-Report value of "yes" and SEND request which contained a Success-Report value of "yes" and
either contains a complete message, or contains the last chunk needed either contains a complete message, or contains the last chunk needed
to complete the message. This request is sent following the normal to complete the message. This request is sent following the normal
procedures (Section 7.1), with a few additional requirements. procedures (Section 7.1), with a few additional requirements.
The endpoint inserts a To-Path header field containing the From-Path The endpoint inserts a To-Path header field containing the From-Path
value from the original request, and a From-Path header containing value from the original request, and a From-Path header field
the URL identifying itself in the session. The endpoint then inserts containing the URL identifying itself in the session. The endpoint
a Status header field with a namespace of "000", a short-status of then inserts a Status header field with a namespace of "000", a
"200" and an implementation defined comment phrase. It also inserts short-status of "200" and an implementation defined comment phrase.
a Message-ID header field containing the value from the original It also inserts a Message-ID header field containing the value from
request. the original request.
The namespace field denotes the context of the short-status field. The namespace field denotes the context of the short-status field.
The namespace value of "000" means the short-status should be The namespace value of "000" means the short-status 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 short-status response code. If a future specification uses the short-status
field for some other purpose, it MUST define a new namespace field field for some other purpose, it MUST define a new namespace field
value. value.
The endpoint MUST NOT send a success report for a SEND request that The endpoint MUST NOT send a success report for a SEND request that
either contained no Success-Report header field, or contained such a either contained no Success-Report header field, or contained such a
field with a value of "no". That is, if no Success-Report header field with a value of "no". That is, if no Success-Report header
field is present, it is treated identically to one with a value of field is present, it is treated identically to one with a value of
"no." "no."
7.1.3 Failure REPORT Generation 7.1.3. Generate Failure REPORTs
If an MSRP endpoint receives a SEND request that it cannot process If an MSRP endpoint receives a SEND request that it cannot process
for some reason, and the Failure-Report header either was not present for some reason, and the Failure-Report header field either was not
in the original request, or had a value of "yes", it SHOULD simply present in the original request, or had a value of "yes", it SHOULD
include the appropriate error code in the transaction response. simply include the appropriate error code in the transaction
However, there may be situations where the error cannot be determined response. However, there may be situations where the error cannot be
quickly, such as when the endpoint is a gateway that must wait for a determined quickly, such as when the endpoint is a gateway that must
downstream network to indicate an error. In this situation, it MAY wait for a downstream network to indicate an error. In this
send a 200 OK response to the request, and then send a failure REPORT situation, it MAY send a 200 OK response to the request, and then
request when the error is detected. send a failure REPORT request when the error is detected.
If the endpoint receives a SEND request with a Failure-Report header If the endpoint receives a SEND request with a Failure-Report header
field value of "no", then it MUST NOT send a failure REPORT request, field value of "no", then it MUST NOT send a failure REPORT request,
and MUST NOT send a transaction response. If the value is "partial", and MUST NOT send a transaction response. If the value is "partial",
it MUST NOT send a 200 transaction response to the request, but it MUST NOT send a 200 transaction response to the request, but
SHOULD send an appropriate non-200 class response if a failure SHOULD send an appropriate non-200 class response if a failure
occurs. occurs.
As stated above, if no Failure-Report header is present, it MUST be As stated above, if no Failure-Report header field is present, it
treated the same as a Failure-Report header with value of "yes". MUST be treated the same as a Failure-Report header field with value
of "yes".
Construction of failure REPORT requests is identical to that for Construction of failure REPORT requests is identical to that for
success reports, except the Status header code and reason fields MUST success REPORT requests, except the Status header field code and
contain appropriate error codes. Any error response code defined in reason fields MUST contain appropriate error codes. Any error
this specification MAY also be used in failure reports. response code defined in this specification MAY also be used in
failure reports.
If a failure report is sent in response to a SEND request that If a failure REPORT request is sent in response to a SEND request
contained a chunk, it MUST include a Byte-Range header indicating the that contained a chunk, it MUST include a Byte-Range header field
actual range being reported on. It can take the range-start and indicating the actual range being reported on. It can take the
total values from the original SEND request, but MUST calculate the range-start and total values from the original SEND request, but MUST
range-end field from the actual body data. calculate the range-end field from the actual body data.
Endpoints SHOULD NOT send REPORT requests if they have reason to Endpoints SHOULD NOT send REPORT requests if they have reason to
believe the request will not be delivered. For example, they SHOULD believe the request will not be delivered. For example, they SHOULD
NOT send a REPORT request on a session that is no longer valid. NOT send a REPORT request on a session that is no longer valid.
This section only describes failure report generation behavior for This section only describes failure report generation behavior for
MSRP endpoints. Relay behavior is beyond the scope of this MSRP endpoints. Relay behavior is beyond the scope of this
document, and will be considered in a separate document. We document, and will be considered in a separate document [21]. 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 value of "yes", or does not contain a Failure- Failure-Report header field value of "yes", or does not contain a
Report header field at all, it MUST immediately generate a response. Failure-Report header field at all, it MUST immediately generate a
Likewise, if an MSRP endpoint receives a request that contains a response. Likewise, if an MSRP endpoint receives a request that
Failure-Report header value of "partial", and the receiver is unable contains a Failure-Report header field value of "partial", and the
to process the request, it SHOULD immediately generate a response. receiver is unable to process the request, it SHOULD immediately
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) URL in the
From-Path header field of the request. (Responses to SEND requests From-Path header field of the request. (Responses to SEND requests
are returned only to the previous hop.) For responses to all other are returned only to the previous hop.) For responses to all other
request methods, the To-Path header field contains the full path back request methods, the To-Path header field field contains the full
to the original sender. This full path is generated by taking the path back to the original sender. This full path is generated by
list of URLs from the From-Path of the original request, reversing taking the list of URLs from the From-Path of the original request,
the list, and writing the reversed list into the To-Path of the reversing the list, and writing the reversed list into the To-Path of
response. (Legal REPORT requests do not request responses, so this the response. (Legal REPORT requests do not request responses, so
specification doesn't exercise the behavior described above, however this specification doesn't exercise the behavior described above,
we expect that extensions for gateways and relays will need such however we expect that extensions for gateways and relays will need
behavior.) such behavior.)
Finally, the endpoint inserts a From-Path header field containing the Finally, the endpoint inserts a From-Path header field containing the
URL that identifies it in the context of the session, followed by the URL that identifies it in the context of the session, followed by the
end-line after the last header field. The response MUST be end-line after the last header field. The response MUST be
transmitted back on the same connection on which the original request transmitted back on the same connection on which the original request
arrived. arrived.
7.3 Receiving Requests 7.3. Receiving Requests
The receiving endpoint must first check the URL in the To-Path to The receiving endpoint must first check the URL in the To-Path to
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 URL, 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 had a value of "no", then no error that if the Failure-Report header field had a value of "no", then no
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
When the receiving endpoint receives a SEND request, it first When the receiving endpoint receives a SEND request, it first
determines if it contains a complete message, or a chunk from a determines if it contains a complete message, or a chunk from a
larger message. If the request contains no Byte-Range header, or larger message. If the request contains no Byte-Range header field,
contains one with a range-start value of "1", and the closing line or contains one with a range-start value of "1", and the closing line
continuation flag has a value of "$", then the request contained the continuation flag has a value of "$", then the request contained the
entire message. Otherwise, the receiver looks at the Message-ID entire message. Otherwise, the receiver looks at the Message-ID
value to associate chunks together into the original message. It value to associate chunks together into the original message. It
forms a virtual buffer to receive the message, keeping track of which forms a virtual buffer to receive the message, keeping track of which
bytes have been received and which are missing. The receiver takes bytes have been received and which are missing. The receiver takes
the data from the request and places it in the appropriate place in the data from the request and places it in the appropriate place in
the buffer. The receiver SHOULD determine the actual length of each the buffer. The receiver SHOULD determine the actual length of each
chunk by inspecting the payload itself; it is possible the body is chunk by inspecting the payload itself; it is possible the body is
shorter than the range-end field indicates. This can occur if the shorter than the range-end field indicates. This can occur if the
sender interrupted a SEND request unexpectedly. It is worth nothing sender interrupted a SEND request unexpectedly. It is worth noting
that the chunk that has a termination character of "$" defines the that the chunk that has a termination character of "$" defines the
total length of the message. total length of the message.
It is technically illegal for the sender to prematurely interrupt It is technically illegal for the sender to prematurely interrupt
a request that had anything other than "*" in the last-byte a request that had anything other than "*" in the last-byte
position of the Byte-Range header. But having the receiver position of the Byte-Range header field. But having the receiver
calculate a chunk length based on actual content adds resilience calculate a chunk length based on actual content adds resilience
in the face of sender errors. Since this should never happen with in the face of sender errors. Since this should never happen with
compliant senders, this only has a SHOULD strength. compliant senders, this only has a SHOULD strength.
Receivers MUST not assume the chunks will be delivered in order or Receivers MUST not assume the chunks will be delivered in order or
that they will receive all the chunks with "+" flags before they that they will receive all the chunks with "+" flags before they
receive the chunk with the "$" flag. In certain cases of connection receive the chunk with the "$" flag. In certain cases of connection
failure, it is possible for information to be duplicated. If chunk failure, it is possible for information to be duplicated. If chunk
data is received that overlaps already received data for the same data is received that overlaps already received data for the same
message, the last chunk received SHOULD take precedence (even though message, the last chunk received SHOULD take precedence (even though
this may not have been the last chunk transmitted). For example, if this may not have been the last chunk transmitted). For example, if
bytes 1 to 100 were received and a chunk arrives that contains bytes bytes 1 to 100 were received and a chunk arrives that contains bytes
50 to 150, this second chunk will overwrite bytes 50 to 100 of the 50 to 150, this second chunk will overwrite bytes 50 to 100 of the
data that had already been received. Although other schemes work, data that had already been received. Although other schemes work,
this is the easiest for the receiver and results in consistent this is the easiest for the receiver and results in consistent
behavior between clients. behavior between clients.
There are situations in which the receiver may not be able to give There are situations in which the receiver may not be able to give
precedent to the last chunk received when chunks overlap. For precedence to the last chunk received when chunks overlap. For
example, the recipient might incrementally render chunks as they example, the recipient might incrementally render chunks as they
arrive. If a new chunk arrives that overlaps with a previously arrive. If a new chunk arrives that overlaps with a previously
rendered chunk, it would be to late to "take back" any conflicting rendered chunk, it would be to late to "take back" any conflicting
data from the first chunk. Therefore, the requirement to give data from the first chunk. Therefore, the requirement to give
precedent to the most recent chunk is specified at a "SHOULD" precedent to the most recent chunk is specified at a "SHOULD"
strength. This requirement is not intended to disallow strength. This requirement is not intended to disallow
applications where it does not make sense. applications where it does not make sense.
The seven "-" in the end-line are used so that the receiver can The seven "-" in the end-line are used so that the receiver can
search for the value "----", 32 bits at a time to find the probable search for the value "----", 32 bits at a time to find the probable
location of the end-line. This allows most processors to locate the location of the end-line. This allows most processors to locate the
boundaries and copy the memory at the same rate that a normal memory boundaries and copy the memory at the same rate that a normal memory
copy could be done. This approach results in a system that is as copy could be done. This approach results in a system that is as
fast as framing based on specifying the body length in the headers of fast as framing based on specifying the body length in the header
the request, but also allows for the interruption of messages. fields of the request, but also allows for the interruption of
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 MIME 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] MIME types.
If the Success-Report header was set to "yes", then when a complete If the Success-Report header field was set to "yes", then when a
message has been received, the receiver MUST send a success REPORT complete message has been received, the receiver MUST send a success
with a byte range covering the whole message. If the Success-Report REPORT with a byte range covering the whole message. If the Success-
header is set to "yes", then the receiver MAY generate incremental Report header field is set to "yes", then the receiver MAY generate
success REPORTs as the chunks are received. These can be sent incremental success REPORTs as the chunks are received. These can be
periodically and cover all the bytes that have been received so far sent periodically and cover all the bytes that have been received so
or they can be sent after a chunk arrives and cover just the part far, or they can be sent after a chunk arrives and cover just the
from that chunk. part from that chunk.
It is helpful to think of a success REPORT as reporting on a It is helpful to think of a success REPORT as reporting on a
particular range of bytes, rather than on a particular chunk sent particular range of bytes, rather than on a particular chunk sent
by a client. The sending client cannot depend on the Byte-Range by a client. The sending client cannot depend on the Byte-Range
header field in a given success report matching the that of a header field in a given success report matching that of a
particular SEND request. For example, an intervening MSRP relay particular SEND request. For example, an intervening MSRP relay
may break chunks into smaller chunks, or aggregate multiple chunks may break chunks into smaller chunks, or aggregate multiple chunks
into larger ones. into larger ones.
A side effect of this is, even if no relay is used, the receiving A side effect of this is, even if no relay is used, the receiving
client may report on byte ranges that do not exactly match those client may report on byte ranges that do not exactly match those
in the original chunks sent by the sender. It can wait until all in the original chunks sent by the sender. It can wait until all
bytes in a message are received and report on the whole, it can bytes in a message are received and report on the whole, it can
report as it receives each chunk, or it can report on any other report as it receives each chunk, or it can report on any other
received range. received range.
Reporting on ranges smaller than the entire message contents Reporting on ranges smaller than the entire message contents
skipping to change at page 25, line 23 skipping to change at page 25, line 26
example, a sending client could display incremental status example, a sending client could display incremental status
information showing which ranges of bytes have been acknowledged information showing which ranges of bytes have been acknowledged
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.
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
state about each outstanding sent message so that it can correlate state about each outstanding sent message so that it can correlate
REPORT requests to the original messages. REPORT requests to the original messages.
An endpoint that receives a REPORT request containing a Status header An endpoint that receives a REPORT request containing a Status header
with a namespace field of "000", MUST interpret the report in exactly field with a namespace field of "000" MUST interpret the report in
the same way it would interpret an MSRP transaction response with a exactly the same way it would interpret an MSRP transaction response
response code matching the short-code field. with a response code matching the short-code field.
It is possible to receive a failure report or a failure transaction It is possible to receive a failure report or a failure transaction
response for a chunk that is currently being delivered. In this case response for a chunk that is currently being delivered. In this
the entire message corresponding to that chunk should be aborted, by case, the entire message corresponding to that chunk should be
including the "#" character in the continuation field of the end- aborted, by including the "#" character in the continuation field of
line. the end-line.
It is possible that an endpoint will receive a REPORT request on a It is possible that an endpoint will receive a REPORT request on a
session that is no longer valid. The endpoint's behavior if this session that is no longer valid. The endpoint's behavior if this
happens is a matter of local policy. The endpoint is not required to happens is a matter of local policy. The endpoint is not required to
take any steps to facilitate such late delivery, i.e. it is not take any steps to facilitate such late delivery, i.e. it is not
expected to keep a connection active in case late REPORTs might expected to keep a connection active in case late REPORTs might
arrive. arrive.
When and 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 URLs 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 responses to other MSRP nodes MUST NOT send MSRP REPORT requests in responses to other
REPORT requests. REPORT requests.
8. Using MSRP with SIP 8. Using MSRP with SIP and SDP
8.1 SDP Offer-Answer Exchanges for MSRP Sessions
MSRP sessions will typically be initiated using the Session MSRP sessions will typically be initiated using the Session
Description Protocol (SDP) [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 setup MSRP This document defines a handful of new SDP parameters to setup 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 in the session description is always accompanied An MSRP media-line (that is, a media-line proposing MSRP) in the
by a mandatory "path" attribute. This attribute contains a space session description is accompanied by a mandatory "path" attribute.
separated list of URLs that must be visited to contact the user agent This attribute contains a space-separated list of URLs that must be
advertising this session-description. If more than one URL is visited to contact the user agent advertising this session-
present, the leftmost URL is the first URL that must be visited to description. If more than one URL is present, the leftmost URL is
reach the target resource. (The path list can contain multiple URLs the first URL that must be visited to reach the target resource.
to allow for the deployment of gateways or relays in the future.) (The path list can contain multiple URLs to allow for the deployment
MSRP implementations which can accept incoming connections will of gateways or relays in the future.) MSRP implementations that can
accept incoming connections without the need for relays will
typically only provide a single URL here. typically only provide a single URL here.
An MSRP media line MUST also be accompanied by an "accept-types" An MSRP media line is also be accompanied by an "accept-types"
attribute. This attribute contains a list of MIME types which are attribute, and optionally an "accept-wrapped-types" attribute. These
acceptable to the endpoint. attributes are used to specify the MIME types that are acceptable to
the endpoint.
A "*" entry in the accept-types attribute indicates that the sender
may attempt to send content with media types that have not been
explicitly listed. Likewise, an entry with an explicit type and a
"*" character as the subtype indicates that the sender may attempt 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 does so.
If not, it will respond with a 415 response. Note that all explicit
entries SHOULD be considered preferred over any non-listed types.
This feature is needed as, otherwise, the list of formats for rich IM
devices may be prohibitively large.
The accept-types attribute may include container types, that is, MIME
formats that contain other types internally. If compound types are
used, the types listed in the accept-types attribute may be used both
as the root payload, or may be wrapped in a listed container type.
Any container types MUST also be listed in the accept-types
attribute.
Occasionally an endpoint will need to specify a MIME body type that
can only be used if wrapped inside a listed container type.
Endpoints MAY specify MIME types that are only allowed when wrapped 8.1. SDP Connection and Media Lines
inside compound types using the "accept-wrapped-types" attribute in
an SDP a-line.
The semantics for accept-wrapped-types are identical to those of the The format of an SDP connection-line takes the following format:
accept-types attribute, with the exception that the specified types
may only be used when wrapped inside container types listed in
accept-types attribute. Only types listed in the accept-types
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
wrapped in other bodies, format entries from accept-types SHOULD NOT
be repeated in this attribute.
This approach does not allow for specifying distinct lists of c=<network type> <address type> <connection address>
acceptable wrapped types for different types of containers. If an
endpoint understands a MIME type in the context of one wrapper, it is
assumed to understand it in the context of any other acceptable
wrappers, subject to any constraints defined by the wrapper types
themselves.
The approach of specifying types that are only allowed inside of The network type and address type fields are used as normal for SDP.
containers separately from the primary payload types allows an The connection address field MUST be set to the IP address or fully
endpoint to force the use of certain wrappers. For example, a qualified domain name from the MSRP URL identifying the endpoint in
CPIM [12] gateway device may require all messages to be wrapped its path attribute.
inside message/cpim bodies, but may allow several content types
inside the wrapper. If the gateway were to specify the wrapped
types in the accept-types attribute, its peer might attempt to use
those types without the wrapper.
If the recipient of an offer does not understand any of the payload The general format of an SDP media-line is:
types indicated in the offered SDP, it SHOULD indicate that using the
appropriate mechanism of the rendezvous protocol. For example, in
SIP, it SHOULD return a SIP 488 response.
An endpoint MAY indicate the maximum size message they wish to m=<media> <port> <protocol> <format list>
receive using the max-size a-line attribute. Max-size refers to the
complete message in octets, not the size of any one chunk. Senders
SHOULD NOT exceed the max-size limit for any message sent in the
resulting session. However, the receiver should consider max-size
value as a hint.
The formal syntax for these attributes are as follows: 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
media field value MUST be "message". The format list field MUST be
set to "*".
accept-types = accept-types-label ":" format-list The port field value MUST match the port value used in the endpoint's
accept-types-label = "accept-types" MSRP URL in the path attribute, except that, as described in [3], a
accept-wrapped-types = wrapped-types-label ":" format-list user agent that wishes to accept an offer, but not a specific media-
wrapped-types-label = "accept-wrapped-types" line MUST, set the port number of that media-line to zero (0) in the
format-list = format-entry *( SP format-entry) response. Since MSRP allows multiple sessions to share the same TCP
format-entry = (type "/" subtype) / (type "/" "*") / ("*") connection, multiple m-lines in a single SDP document may share the
type = token same port field value; MSRP devices MUST NOT assume any particular
subtype = token relationship between m-lines on the sole basis that they have
matching port field values.
max-size = max-size-label ":" max-size-value MSRP devices do not use the c-line address field, or the m-line
max-size-label = "max-size" port and format list fields to determine where to connect.
max-size-value = 1*(DIGIT) ;max size in octets Rather, they use the attributes defined in this specification.
The connection information is copied to the c-line and m-line for
purposes of backwards compatibility with conventional SDP usages.
While MSRP could theoretically carry any media type, "message" is
appropriate.
8.1.1 URL Negotiations 8.2. URL Negotiations
Each endpoint in an MSRP session is identified by a URL. These URLs Each endpoint in an MSRP session is identified by a URL. These URLs
are negotiated in the SDP exchange. Each SDP offer or answer MUST are negotiated in the SDP exchange. Each SDP offer or answer that
contain one or more MSRP URL in a path attribute. This attribute has proposes MSRP MUST contain a path attribute containing one or more
MSRP URLs. The path attribute is used in an SDP a-line, and has has
the following syntax: the following syntax:
"a=path:" MSRP-URL *(SP MSRP-URL) path = path-label ":" path-list
path-label = "path"
path-list= MSRP-URL *(SP MSRP-URL)
where MSRP-URL is an msrp: or msrps: URL as defined in Section 6. where MSRP-URL is an msrp: or msrps: URL as defined in Section 6.
MSRP URLs included in an SDP offer or answer MUST include explicit MSRP URLs included in an SDP offer or answer MUST include explicit
port numbers. port numbers.
An MSRP device uses the URL to determine a host address, port, An MSRP device uses the URL to determine a host address, port,
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 URL to represent itself and
send 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 URL, then the
target URL is the rightmost, while the leftmost entry represents the target URL is the rightmost, while the leftmost entry represents the
adjacent hop. If only one entry is present, then it is both the peer adjacent hop. If only one entry is present, then it is both the peer
and adjacent hop URL. The target path is the entire path attribute and adjacent hop URL. The target path is the entire path attribute
value received from the peer. value received from the peer.
The following example shows an SDP offer with a session URL of The following example shows an SDP offer with a session URL of
"msrp://alice.example.com:7394/2s93i;tcp" "msrp://alice.example.com:7394/2s93i;tcp"
v=0 v=0
o=alice 2890844526 2890844527 IN IP4 alice.example.com o=alice 2890844526 2890844527 IN IP4 alice.example.com
s= s=
c=IN IP4 alice.example.com c=IN IP4 alice.example.com
m=message 7394 TCP/MSRP * m=message 7394 TCP/MSRP *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrp://alice.example.com:7394/2s93i;tcp a=path:msrp://alice.example.com:7394/2s93i;tcp
The rightmost URL in the path attribute MUST identify the endpoint The rightmost URL in the path attribute MUST identify the endpoint
that generated the SDP document, or some other location where that that generated the SDP document, or some other location where that
skipping to change at page 29, line 20 skipping to change at page 28, line 30
a=path:msrp://alice.example.com:7394/2s93i;tcp a=path:msrp://alice.example.com:7394/2s93i;tcp
The rightmost URL in the path attribute MUST identify the endpoint The rightmost URL in the path attribute MUST identify the endpoint
that generated the SDP document, or some other location where that that generated the SDP document, or some other location where that
endpoint wishes to receive requests associated with the session. It endpoint wishes to receive requests associated with the session. It
MUST be assigned for this particular session, and MUST NOT duplicate MUST be assigned for this particular session, and MUST NOT duplicate
any URL in use for any other session in which the endpoint is any URL in use for any other session in which the endpoint is
currently participating. It SHOULD be hard to guess, and protected currently participating. It SHOULD be hard to guess, and protected
from eavesdroppers. This is discussed in more detail in Section 14. from eavesdroppers. This is discussed in more detail in Section 14.
8.1.2 Path Attributes with Multiple URLs 8.3. Path Attributes with Multiple URLs
As mentioned previously, this document describes MSRP for peer-to- As mentioned previously, this document describes MSRP for peer-to-
peer scenarios, that is, when no relays are used. However, we expect peer scenarios, that is, when no relays are used. The use of relays
a separate document to describe the use of relays. In order to allow are described in a separate document [21]. In order to allow an MSRP
an MSRP device that only implements the core specification to device that only implements the core specification to interoperate
interoperate with devices that use relays, this document must include with devices that use relays, this document must include a few
a few assumptions about how relays work. assumptions about how relays work.
An endpoint that uses one or more relays will indicate that by An endpoint that uses one or more relays will indicate that by
putting a URL for each device in the relay chain into the SDP path putting a URL for each device in the relay chain into the SDP path
attribute. The final entry would point to the endpoint itself. The attribute. The final entry will point to the endpoint itself. The
other entries would indicate each proposed relay, in order. The other entries will indicate each proposed relay, in order. The first
first entry would point to the first relay in the chain from the entry will point to the first relay in the chain from the perspective
perspective of the peer; that is, the relay to which the peer device, of the peer; that is, the relay to which the peer device, or a relay
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 URL into the path
attribute. This URL represents both the endpoint for the session, attribute. This URL 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 URL in the SDP path attribute. When an
endpoint receives more than one URL in a path header, only the first endpoint receives more than one URL in a path attribute, only the
entry is relevant for purposes of resolving the address and port, and first entry is relevant for purposes of resolving the address and
establishing the network connection, as it describes the first port, and establishing the network connection, as it describes the
adjacent hop. first adjacent hop.
If an endpoint puts more than one URL in a path attribute, the final If an endpoint puts more than one URL in a path attribute, the final
URL in the path (the peer URL) attribute MUST exhibit the uniqueness URL in the path (the peer URL) attribute MUST exhibit the uniqueness
properties described above. Uniqueness requirements for other properties described above. Uniqueness requirements for other
entries in the attribute are out of scope for this document. entries in the attribute are out of scope for this document.
8.1.3 SDP Connection and Media Lines 8.4. Updated SDP Offers
The format of an SDP connection-line takes the following format:
c=<network type> <address type> <connection address>
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
qualified domain name from the MSRP URL identifying the endpoint in
its PATH attribute.
The general format of an SDP media-line is:
m=<media> <port> <protocol> <format list>
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
media field value MUST be "message". The format list field MUST be
set to "*".
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
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
response.) Since MSRP allows multiple sessions to share the same TCP
connection, multiple m-lines in a single SDP document may share the
same port field value; MSRP devices MUST NOT assume any particular
relationship between m-lines on the sole basis that they have
matching port field values.
MSRP devices do not use the c-line address field, or the m-line
port and format list fields to determine where to connect.
Rather, they use the attributes defined in this specification.
The connection information is copied to the c-line and m-line for
purposes of backwards compatibility with conventional SDP usages.
While MSRP could theoretically carry any media type, "message" is
appropriate.
8.1.4 Updated SDP Offers
MSRP endpoints may sometimes need to send additional SDP exchanges MSRP endpoints may sometimes need to send additional SDP exchanges
for an existing session. They may need to send periodic exchanges for an existing session. They may need to send periodic exchanges
with no change to refresh state in the network, for example, SIP with no change to refresh state in the network, for example, SIP
Session Timers. They may need to change some other stream in a session timers. They may need to change some other stream in a
session without affecting the MSRP stream, or they may need to change session without affecting the MSRP stream, or they may need to change
an MSRP stream without affecting some other stream. an MSRP stream without affecting some other stream.
Either peer may initiate an updated exchange at any time. The Either peer may initiate an updated exchange at any time. The
endpoint that sends the new offer assumes the role of offerer for all endpoint that sends the new offer assumes the role of offerer for all
purposes. The answerer MUST respond with a path attribute that purposes. The answerer MUST respond with a path attribute that
represents a valid path to itself at the time of the updated represents a valid path to itself at the time of the updated
exchange. This new path may be the same as its previous path, but exchange. This new path may be the same as its previous path, but
may be different. The new offerer MUST NOT assume that the peer will may be different. The new offerer MUST NOT assume that the peer will
answer with the same path it used previously. answer with the same path it used previously.
If either party wishes to send an SDP document that changes nothing If either party wishes to send an SDP document that changes nothing
at all, then it MUST have the same o-line as in the previous at all, then it MUST have the same o-line as in the previous
exchange. exchange.
8.1.5 Example SDP Exchange 8.5. Connection Negotiation
Previous versions of this document included a mechanism to negotiate
the direction for any required TCP connection. The mechanism was
loosely based on the COMEDIA [24] work being done in the MMUSIC
working group. The primary motivation was to allow MSRP sessions to
succeed in situations where the offerer could not accept connections
but the answerer could. For example, the offerer might be behind a
NAT, while the answerer might have a globally routable address.
The SIMPLE working group chose to remove that mechanism from MSRP, as
it added a great deal of complexity to connection management.
Instead, MSRP now specifies a default connection direction. The
party that sent the original offer is responsible for connecting to
its peer.
8.6. Content Type Negotiation
An SDP media-line proposing MSRP MUST be accompanied by an accept-
types attribute.
An entry of "*" in the accept-types attribute indicates that the
sender may attempt to send content with media types that have not
been explicitly listed. Likewise, an entry with an explicit type and
a "*" character as the subtype indicates that the sender may attempt
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
does so. If not, it will respond with a 415 response. Note that all
explicit entries SHOULD be considered preferred over any non-listed
types. This feature is needed as, otherwise, the list of formats for
rich IM devices may be prohibitively large.
The accept-types attribute may include container types, that is, MIME
formats that contain other types internally. If compound types are
used, the types listed in the accept-types attribute may be used both
as the root payload, or may be wrapped in a listed container type.
Any container types MUST also be listed in the accept-types
attribute.
Occasionally an endpoint will need to specify a MIME body type that
can only be used if wrapped inside a listed container type.
Endpoints MAY specify MIME types that are only allowed when wrapped
inside compound types using the "accept-wrapped-types" attribute in
an SDP a-line.
The semantics for accept-wrapped-types are identical to those of the
accept-types attribute, with the exception that the specified types
may only be used when wrapped inside container types listed in
accept-types attribute. Only types listed in the accept-types
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
wrapped in other bodies, format entries from accept-types SHOULD NOT
be repeated in this attribute.
This approach does not allow for specifying distinct lists of
acceptable wrapped types for different types of containers. If an
endpoint understands a MIME type in the context of one wrapper, it is
assumed to understand it in the context of any other acceptable
wrappers, subject to any constraints defined by the wrapper types
themselves.
The approach of specifying types that are only allowed inside of
containers separately from the primary payload types allows an
endpoint to force the use of certain wrappers. For example, a
CPIM [12] gateway device may require all messages to be wrapped
inside message/cpim bodies, but may allow several content types
inside the wrapper. If the gateway were to specify the wrapped
types in the accept-types attribute, its peer might attempt to use
those types without the wrapper.
If the recipient of an offer does not understand any of the payload
types indicated in the offered SDP, it SHOULD indicate that using the
appropriate mechanism of the rendezvous protocol. For example, in
SIP, it SHOULD return a SIP 488 response.
An endpoint MAY indicate the maximum size message they wish to
receive using the max-size a-line attribute. Max-size refers to the
complete message in octets, not the size of any one chunk. Senders
SHOULD NOT exceed the max-size limit for any message sent in the
resulting session. However, the receiver should consider max-size
value as a hint.
The formal syntax for these attributes are as follows:
accept-types = accept-types-label ":" format-list
accept-types-label = "accept-types"
accept-wrapped-types = wrapped-types-label ":" format-list
wrapped-types-label = "accept-wrapped-types"
format-list = format-entry *( SP format-entry)
format-entry = (type "/" subtype) / (type "/" "*") / ("*")
type = token
subtype = token
max-size = max-size-label ":" max-size-value
max-size-label = "max-size"
max-size-value = 1*(DIGIT) ;max size in octets
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 *
skipping to change at page 31, line 44 skipping to change at page 32, line 17
v=0 v=0
o=userb 2890844530 2890844532 IN IP4 bob.example.com o=userb 2890844530 2890844532 IN IP4 bob.example.com
s= s=
c=IN IP4 bob.example.com c=IN IP4 bob.example.com
t=0 0 t=0 0
m=message 8493 TCP/MSRP * m=message 8493 TCP/MSRP *
a=accept-types:message/cpim text/plain a=accept-types:message/cpim text/plain
a=path:msrp://bob.example.com:8493/si438ds;tcp a=path:msrp://bob.example.com:8493/si438ds;tcp
8.1.6 Connection Negotiation 8.8. MSRP User Experience with SIP
Previous versions of this document included a mechanism to negotiate
the direction for any required TCP connection. The mechanism was
loosely based on the COMEDIA [24] work being done in the MMUSIC
working group. The primary motivation was to allow MSRP sessions to
succeed in situations where the offerer could not accept connections
but the answerer could. For example, the offerer might be behind a
NAT, while the answerer might have a globally routable address.
The SIMPLE working group chose to remove that mechanism from MSRP, as
it added a great deal of complexity to connection management.
Instead, MSRP now specifies a default connection direction. Namely,
the party that sent the original offer.
8.2 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
displayed to the user, without waiting for the user to "join" the displayed to the user, without waiting for the user to "join" the
conversation. Therefore, the principle of least surprise would conversation. Therefore, the principle of least surprise would
skipping to change at page 34, line 4 skipping to change at page 34, line 11
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 ]
pname = token pname = token
pval = token / quoted-string pval = token / quoted-string
skipping to change at page 34, line 34 skipping to change at page 34, line 40
; token is compared case-insensitive ; token is compared case-insensitive
quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE
qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E
/ UTF8-NONASCII / UTF8-NONASCII
qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE) qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE)
BACKSLASH = "\" BACKSLASH = "\"
UPALPHA = %x41-5A UPALPHA = %x41-5A
ALPHANUM = ALPHA / DIGIT ALPHANUM = ALPHA / DIGIT
Other-Mime-Header = (Content-ID Other-Mime-header = (Content-ID
/ Content-Description / Content-Description
/ Content-Disposition / Content-Disposition
/ mime-extension-field); / mime-extension-field);
; Content-ID, and Content-Description are defined in RFC2045. ; Content-ID, and Content-Description are defined in RFC2045.
; Content-Disposition is defined in RFC2183 ; Content-Disposition is defined in RFC2183
; MIME-extension-field indicates additional MIME extension ; MIME-extension-field indicates additional MIME extension
; headers as described in RFC2045 ; header fields as described in RFC2045
data = *OCTET data = *OCTET
end-line = "-------" transact-id continuation-flag CRLF end-line = "-------" transact-id continuation-flag CRLF
continuation-flag = "+" / "$" / "#" continuation-flag = "+" / "$" / "#"
ext-header = hname ":" SP hval CRLF ext-header = hname ":" SP hval CRLF
hname = ALPHA *token hname = ALPHA *token
hval = utf8text hval = utf8text
utf8text = *(HTAB / %x20-7E / UTF8-NONASCII) utf8text = *(HTAB / %x20-7E / UTF8-NONASCII)
skipping to change at page 35, line 20 skipping to change at page 35, line 25
/ %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
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 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.
10.2 400 10.2. 400
A 400 response indicates a request was unintelligible. The sender A 400 response indicates a request was unintelligible. The sender
may retry the request after correcting the error. may retry the request after correcting the error.
10.3 403 10.3. 403
A 403 response indicates the attempted action is not allowed. The A 403 response indicates the attempted action is not allowed. The
sender should not try the request again. sender should not try the request again.
10.4 408 10.4. 408
A 408 response indicates that a downstream transaction did not A 408 response indicates that a downstream transaction did not
complete in the alloted time. It is never sent by any elements complete in the alloted time. It is never sent by any elements
described in this specification. However, 408 is used in the MSRP described in this specification. However, 408 is used in the MSRP
Relay extension; therefore MSRP endpoints may receive it. An Relay extension; therefore MSRP endpoints may receive it. An
endpoint MUST treat a 408 response in the same manner as it would endpoint MUST treat a 408 response in the same manner as it would
treat a local timeout. treat a local timeout.
10.5 413 10.5. 413
A 413 response indicates that the receiver wishes the sender to stop A 413 response indicates that the receiver wishes the sender to stop
sending the particular message. Typically, a 413 is sent in response sending the particular message. Typically, a 413 is sent in response
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 MIME content-
type that is not understood by the receiver. The sender should not type that is not understood by the receiver. The sender should not
send any further messages with the same content-type for the duration send any further messages with the same content-type for the duration
of the session. of the session.
10.7 423 10.7. 423
A 423 response indicates that one of the requested parameters is out A 423 response indicates that one of the requested parameters is out
of bounds. It is used by the relay extensions to this document. of bounds. It is used by the relay extensions to this document.
10.8 426 10.8. 426
A 426 response indicates that the request is only allowed over secure A 426 response indicates that the request is only allowed over secure
connections. connections.
10.9 481 10.9. 481
A 481 response indicates that the indicated session does not exist. A 481 response indicates that the indicated session does not exist.
The sender should terminate the session. The sender should terminate the session.
10.10 501 10.10. 501
A 501 response indicates that the recipient does not understand the A 501 response indicates that the recipient does not understand the
request method. request method.
The 501 response code exists to allow some degree of method The 501 response code exists to allow some degree of method
extensibility. It is not intended as a license to ignore methods extensibility. It is not intended as a license to ignore methods
defined in this document; rather it is a mechanism to report lack defined in this document; rather it is a mechanism to report lack
of support of extension methods. of support of extension methods.
10.11 506 10.11. 506
A 506 response indicates that a request arrived on a session which is A 506 response indicates that a request arrived on a session which is
already bound to another network connection. The sender should cease already bound to another network connection. The sender should cease
sending messages for that session on this connection. sending messages for that session on this connection.
11. Examples 11. Examples
11.1 Basic IM session 11.1. Basic IM Session
This section shows an example flow for the most common scenario. The This section shows an example flow for the most common scenario. The
example assumes SIP is used to transport the SDP exchange. Details example assumes SIP is used to transport the SDP exchange. Details
of the SIP messages and SIP proxy infrastructure are omitted for the of the SIP messages and SIP proxy infrastructure are omitted for the
sake of brevity. In the example, assume the offerer is sake of brevity. In the example, assume the offerer is
sip:alice@example.com and the answerer is sip:bob@example.com. sip:alice@example.com and the answerer is sip:bob@example.com.
Alice Bob Alice Bob
| | | |
| | | |
skipping to change at page 39, line 15 skipping to change at page 39, line 19
-------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
11.2 Message with XHTML Content 11.2. Message with XHTML Content
MSRP dsdfoe38sd SEND MSRP dsdfoe38sd SEND
To-Path: msrp://alice.atlanta.com:7777/iau39;tcp To-Path: msrp://alice.atlanta.com:7777/iau39;tcp
From-Path: msrp://bob.atlanta.com:8888/9di4ea;tcp From-Path: msrp://bob.atlanta.com:8888/9di4ea;tcp
Message-ID: 456 Message-ID: 456
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"
skipping to change at page 39, line 38 skipping to change at page 39, line 42
<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$
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. 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/9di4ea;tcp
From-Path: msrp://example.com:7777/iau39;tcp From-Path: msrp://example.com:7777/iau39;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.5. 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/9di4ea;tcp
From-Path: msrp://alicepc.example.com:7777/iau39;tcp From-Path: msrp://alicepc.example.com:7777/iau39;tcp
Message-ID: 12339sdqwer Message-ID: 12339sdqwer
Success-Report: yes Success-Report: yes
Failure-Report: no Failure-Report: no
Content-Type: text/html Content-Type: text/html
skipping to change at page 40, line 37 skipping to change at page 40, line 41
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/iau39;tcp
From-Path: msrp://bob.example.com:8888/9di4ea;tcp From-Path: msrp://bob.example.com:8888/9di4ea;tcp
Message-ID: 12339sdqwer Message-ID: 12339sdqwer
Status: 000 200 OK Status: 000 200 OK
-------dkei38sd$ -------dkei38sd$
11.6 Forked IM 11.6. Forked IM
Traditional IM systems generally do a poor job of handling multiple Traditional IM systems generally do a poor job of handling multiple
simultaneous IM clients online for the same person. While some do a simultaneous IM clients online for the same person. While some do a
better job than many existing systems, handling of multiple clients better job than many existing systems, handling of multiple clients
is fairly crude. This becomes a much more significant issue when is fairly crude. This becomes a much more significant issue when
always-on mobile devices are available, but it is desirable to use always-on mobile devices are available, but it is desirable to use
them only if another IM client is not available. them only if another IM client is not available.
Using SIP makes rendezvous decisions explicit, deterministic, and Using SIP makes rendezvous decisions explicit, deterministic, and
very flexible; instead "pager-mode" IM systems use implicit very flexible. In contrast, "pager-mode" IM systems use implicit
implementation-specific decisions which IM clients cannot influence. implementation-specific decisions which IM clients cannot influence.
With SIP session mode messaging rendezvous decisions can be under With SIP session mode messaging, rendezvous decisions can be under
control of the client in a predictable, interoperable way for any control of the client in a predictable, interoperable way for any
host that implements callee capabilities [30]. As a result, host that implements callee capabilities [30]. As a result,
rendezvous policy is managed consistently for each address of record. rendezvous policy is managed consistently for each address of record.
The following example shows Juliet with several IM clients where she The following example shows Juliet with several IM clients where she
can be reached. Each of these has a unique SIP Contact and MSRP can be reached. Each of these has a unique SIP Contact and MSRP
session. The example takes advantage of SIP's capability to "fork" session. The example takes advantage of SIP's capability to "fork"
an invitation to several Contacts in parallel, in sequence, or in an invitation to several Contacts in parallel, in sequence, or in
combination. Juliet has registered from her chamber, the balcony, combination. Juliet has registered from her chamber, the balcony,
her PDA, and as a last resort, you can leave a message with her her PDA, and as a last resort, you can leave a message with her
skipping to change at page 44, line 8 skipping to change at page 44, line 8
| | | | | | | | | | | |
| Hi Romeo, Juliet is | | Hi Romeo, Juliet is |
| with her father now | | with her father now |
| can I take a message?| | can I take a message?|
| | | |
| Tell her to go to confession tomorrow.... | | Tell her to go to confession tomorrow.... |
12. Extensibility 12. Extensibility
MSRP was designed to be only minimally extensible. New MSRP Methods, MSRP was designed to be only minimally extensible. New MSRP Methods,
Headers, and status codes can be defined in standards track RFCs. header fields, and status codes can be defined in standards track
There is no registry of headers, methods, or status codes, since the RFCs. There is no registry of header fields, methods, or status
number of new elements and total extensions is expected to be very codes, since the number of new elements and total extensions is
small. MSRP does not contain a version number or any negotiation expected to be very small. MSRP does not contain a version number or
mechanism to require or discover new features. If a non- any negotiation mechanism to require or discover new features. If a
interoperable update or extension occurs in the future, it will be non-interoperable update or extension occurs in the future, it will
treated as a new protocol, and must describe how its use will be be treated as a new protocol, and must describe how its use will be
signaled. signaled.
In order to allow extension header fields without breaking In order to allow extension header fields without breaking
interoperability, if an MSRP device receives a request or response interoperability, if an MSRP device receives a request or response
containing a header field that it does not understand, it MUST ignore containing a header field that it does not understand, it MUST ignore
the header field and process the request or response as if the header the header field and process the request or response as if the header
field was not present. If an MSRP device receives a request with an field was not present. If an MSRP device receives a request with an
unknown method, it MUST return a 501 response. unknown method, it MUST return a 501 response.
MSRP was designed to use lists of URLs instead of a single URL in the MSRP was designed to use lists of URLs instead of a single URL in the
To-Path and From-Path headers in anticipation of relay or gateway To-Path and From-Path header fields in anticipation of relay or
functionality being added. In addition, msrp: and msrps: URLs can gateway functionality being added. In addition, msrp: and msrps:
contain parameters which are extensible. URLs can contain parameters that are extensible.
13. CPIM compatibility 13. CPIM Compatibility
MSRP sessions may go to a gateway to other CPIM [25] compatible MSRP sessions may go to a gateway to other CPIM [25] compatible
protocols. If this occurs, the gateway MUST maintain session state, protocols. If this occurs, the gateway MUST maintain session state,
and MUST translate between the MSRP session semantics and CPIM and MUST translate between the MSRP session semantics and CPIM
semantics, which do not include a concept of sessions. Furthermore, semantics, which do not include a concept of sessions. Furthermore,
when one endpoint of the session is a CPIM gateway, instant messages when one endpoint of the session is a CPIM gateway, instant messages
SHOULD be wrapped in "message/cpim" [12] bodies. Such a gateway MUST SHOULD be wrapped in "message/cpim" [12] bodies. Such a gateway MUST
include "message/cpim" as the first entry in its SDP accept-types include "message/cpim" as the first entry in its SDP accept-types
attribute. MSRP endpoints sending instant messages to a peer that attribute. MSRP endpoints sending instant messages to a peer that
has included "message/cpim" as the first entry in the accept-types has included "message/cpim" as the first entry in the accept-types
attribute SHOULD encapsulate all instant message bodies in "message/ attribute SHOULD encapsulate all instant message bodies in "message/
cpim" wrappers. All MSRP endpoints MUST support the message/cpim cpim" wrappers. All MSRP endpoints MUST support the message/cpim
type, and SHOULD support the S/MIME features of that format. type, and SHOULD support the S/MIME features of that format.
If a message is to be wrapped in a message/cpim envelope, the If a message is to be wrapped in a message/cpim envelope, the
wrapping MUST be done prior to breaking the message into chunks, if wrapping MUST be done prior to breaking the message into chunks, if
needed. needed.
All MSRP endpoints MUST recognize the From, To, DateTime, and Require All MSRP endpoints MUST recognize the From, To, DateTime, and Require
headers as defined in RFC3862. Such applications SHOULD recognize header fields as defined in RFC3862. Such applications SHOULD
the CC header, and MAY recognize the Subject header. Any MSRP recognize the CC header field, and MAY recognize the Subject header
application that recognizes any message/cpim header MUST understand field. Any MSRP application that recognizes any message/cpim header
the NS (name space) header. field MUST understand the NS (name space) header field.
All message/cpim body parts sent by an MSRP endpoint MUST include the All message/cpim body parts sent by an MSRP endpoint MUST include the
From and To headers. If the message/cpim body part is protected From and To header fields. If the message/cpim body part is
using S/MIME, then it MUST also include the DateTime header. protected using S/MIME, then it MUST also include the DateTime header
field.
The NS, To, and CC headers may occur multiple times. Other headers The NS, To, and CC header fields may occur multiple times. Other
defined in RFC3862 MUST NOT occur more than once in a given message/ header fields defined in RFC3862 MUST NOT occur more than once in a
cpim body part in an MSRP message. The Require header MAY include given message/cpim body part in an MSRP message. The Require header
multiple values. The NS header MAY occur zero or more times, field MAY include multiple values. The NS header field MAY occur
depending on how many name spaces are being referenced. zero or more times, depending on how many name spaces are being
referenced.
Extension headers MAY occur more than once, depending on the Extension header fields MAY occur more than once, depending on the
definition of such headers. definition of such header fields.
Using message/cpim envelopes are also useful if an MSRP device Using message/cpim envelopes are also useful if an MSRP device
wishes to send a message on behalf of some other identity. The wishes to send a message on behalf of some other identity. The
device may add a message/cpim envelope with the appropriate From device may add a message/cpim envelope with the appropriate From
header value. header field value.
14. Security Considerations 14. Security Considerations
Instant Messaging systems are used to exchange a variety of sensitive Instant Messaging systems are used to exchange a variety of sensitive
information ranging from personal conversations, to corporate information ranging from personal conversations, to corporate
confidential information, to account numbers and other financial confidential information, to account numbers and other financial
trading information. IM is used by individuals, corporations, and trading information. IM is used by individuals, corporations, and
governments for communicating important information. Like many governments for communicating important information. IM systems need
communications systems, the properties of Integrity and to provide the properties of integrity and confidentiality for the
Confidentiality of the exchanged information, along with the exchanged information, the knowledge that you are communicating with
possibility of Anonymous communications, and knowing you are the correct party, and allow the possibility of anonymous
communicating with the correct other party are required. MSRP pushes communication. MSRP pushes many of the hard problems to SIP when SIP
many of the hard problems to SIP when SIP sets up the session, but sets up the session, but some of the problems remain. Spam and DoS
some of the problems remain. Spam and DoS attacks are also very attacks are also very relevant to IM systems.
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. 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 B, B passes its hostname and a secret to A using host A is contacting host B, B passes its hostname and a secret to A
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. 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. A assumes that it is talking to B based across the connection to B. Host A assumes that it is talking to B
on where it sent the SYN packet and then delivers the secret in plain based on where it sent the SYN packet and then delivers the secret in
text across the connections. B assumes it is talking to A because plain text across the connections. Host B assumes it is talking to A
the host on the other end of the connection delivered the secret. An because the host on the other end of the connection delivered the
attacker that could ACK the SYN packet could insert itself as a man secret. An attacker that could ACK the SYN packet could insert
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 certificate authority. Furthermore, we assume that
the signaling to set up the session is protected by the rendezvous the signaling to set up the session is protected by the rendezvous
protocol. In this case, when host A contacts host B, the secret is protocol. In this case, when host A contacts host B, the secret is
passed through a confidential channel to A. A connects with TLS to B. passed through a confidential channel to A. A connects with TLS to B.
B presents a valid certificate, so A knows it really is connected to B presents a valid certificate, so A knows it really is connected to
B. A then delivers the secret provided by B, so that B can verify it B. A then delivers the secret provided by B, so that B can verify it
is connected to A. In this case, a rogue SIP Proxy can see the secret is connected to A. In this case, a rogue SIP Proxy can see the secret
in the SIP signaling traffic and could potentially insert itself as a in the SIP signaling traffic and could potentially insert itself as a
man-in-the-middle. man-in-the-middle.
Realistically, using TLS is difficult for peer to peer connections, Realistically, using TLS is difficult for peer-to-peer connections,
as the types of hosts that end clients use for sending instant as the types of hosts that end clients use for sending instant
messages are unlikely to have long term stable IP addresses or DNS messages are unlikely to have long-term stable IP addresses or DNS
names that 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 certificate authorities is currently
expensive enough to discourage their use for each client. While not expensive enough to discourage their use for each client. While not
in scope for this document, using TLS with a DH profile is possible. in scope for this document, using TLS with a DH profile is possible.
TLS becomes much more practical when some form of relay is TLS becomes much more practical when some form of relay is
introduced. Clients can then form TLS connections to relays, which introduced. Clients can then form TLS connections to relays, which
are much more likely to have TLS certificates. While this are much more likely to have TLS certificates. While this
specification does not address such relays, they are described by a specification does not address such relays, they are described by a
companion document [21]. That document makes extensive use of TLS to companion document [21]. 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 headers being transported. MSRP elements confidentiality for the header fields being transported. MSRP
MUST implement TLS and MUST also implement the TLS elements MUST implement TLS and MUST also implement the TLS
ClientExtendedHello extended hello information for server name ClientExtendedHello extended hello information for server name
indication as described in [10]. A TLS cipher-suite of indication as described in [10]. A TLS cipher-suite of
TLS_RSA_WITH_AES_128_CBC_SHA [13] MUST be supported (other cipher- TLS_RSA_WITH_AES_128_CBC_SHA [13] MUST be supported (other cipher-
suites MAY also be supported). suites MAY also be supported).
14.2 S/MIME 14.2. S/MIME
The only strong security for non-TLS connections is achieved using The only strong security for non-TLS connections is achieved using
S/MIME. S/MIME.
Since MSRP carries arbitrary MIME content, it can trivially carry Since MSRP carries arbitrary MIME content, it can trivially carry
S/MIME protected messages as well. All MSRP implementations MUST S/MIME protected messages as well. All MSRP implementations MUST
support the multipart/signed MIME type even if they do not support support the multipart/signed MIME type even if they do not support
S/MIME. Since SIP can carry a session key, S/MIME messages in the S/MIME. Since SIP can carry a session key, S/MIME messages in the
context of a session could also be protected using a key-wrapped context of a session could also be protected using a key-wrapped
shared secret [26] provided in the session setup. MSRP is a binary shared secret [26] provided in the session setup. MSRP is a binary
protocol and MIME bodies MUST be transferred with a transfer encoding protocol and MIME bodies MUST be transferred with a transfer encoding
of binary. If a message is both signed and encrypted, it SHOULD be of binary. If a message is both signed and encrypted, it SHOULD be
signed first, then encrypted. If S/MIME is supported, SHA-1, RSA, signed first, then encrypted. If S/MIME is supported, SHA-1, RSA,
and AES-128 MUST be supported. and AES-128 MUST be supported.
This does not actually require the endpoint to have certificates from This does not actually require the endpoint to have certificates from
a well known certificate authority. When MSRP is used with SIP, the a well-known certificate authority. When MSRP is used with SIP, the
Identity [22] and Certificates [23] mechanisms provide S/MIME based Identity [22] and Certificates [23] mechanisms provide S/MIME based
delivery of a secret between A and B. No SIP intermediary except the delivery of a secret between A and B. No SIP intermediary except the
explicitly trusted authentication service (one per user) can see the explicitly trusted authentication service (one per user) can see the
secret. The S/MIME encryption of the SDP can also be used by SIP to secret. The S/MIME encryption of the SDP can also be used by SIP to
exchange keying material that can be used in MSRP. The MSRP session exchange keying material that can be used in MSRP. The MSRP session
can then use S/MIME with this keying material to encrypt and sign can then use S/MIME with this keying material to encrypt and sign
messages sent over MSRP. The connection can still be hijacked since messages sent over MSRP. The connection can still be hijacked since
the secret is sent in clear text to the other end of the TCP the secret is sent in clear text to the other end of the TCP
connection, but the consequences are mitigated if all the MSRP connection, but the consequences are mitigated if all the MSRP
content is encrypted and signed with S/MIME. It is out of scope for content is encrypted and signed with S/MIME. Although out of scope
this document but there is nothing stopping the SIP negotiation of for this document, the SIP negotiation of MSRP session can negotiate
MSRP session from negotiating symmetric keying material that is used symmetric keying material to be used with S/MIME for integrity and
with S/MIME for integrity and privacy. privacy.
14.3 Other Security Concerns 14.3. Other Security Concerns
MSRP can not be used as an amplifier for DoS attacks, but it can be MSRP can not be used as an amplifier for DoS attacks, but it can be
used to form a distributed attack to consume TCP connection resource used to form a distributed attack to consume TCP connection resource
on servers. The attacker, Eve, sends a SIP INVITE with no offer to on servers. The attacker, Eve, sends a SIP INVITE with no offer to
Alice. Alice returns a 200 with an offer and Eve returns an answer Alice. Alice returns a 200 with an offer and Eve returns an answer
with the SDP that indicates that her MSRP address is the address of with SDP indicating that her MSRP address is the address of Tom.
Tom. Since Alice sent the offer, Alice will initiate a connection to Since Alice sent the offer, Alice will initiate a connection to Tom
Tom using up resources on Tom's server. Given the huge number of IM using up resources on Tom's server. Given the huge number of IM
clients, and the relatively few TCP connections that most servers clients, and the relatively few TCP connections that most servers
support, this is a fairly straightforward attack. support, this is a fairly straightforward attack.
SIP is attempting to address issues in dealing with spam. The spam SIP is attempting to address issues in dealing with spam. The spam
issue is probably best dealt with at the SIP level when an MSRP issue is probably best dealt with at the SIP level when an MSRP
session is initiated and not at the MSRP level. session is initiated and not at the MSRP level.
If a sender chooses to employ S/MIME to protect a message, all S/MIME If a sender chooses to employ S/MIME to protect a message, all S/MIME
operations MUST occur prior to breaking the message into chunks, if operations MUST occur prior to breaking the message into chunks, if
needed. needed.
The signaling will have set up the session to or from some specific The signaling will have set up the session to or from some specific
URLs that will often have "im:" or "sip:" URI schemes. When the URLs that will often have "im:" or "sip:" URI schemes. When the
signaling has been set up to a specific end user, and S/MIME is signaling has been set up to a specific end user, and S/MIME is
implemented, then the client needs to verify that the name in the implemented, then the client needs to verify that the name in the
SubjectAltName of the certificate contains an entry that matches the SubjectAltName of the certificate contains an entry that matches the
URI that was used for the other end in the signaling. There are some URI that was used for the other end in the signaling. There are some
cases, such as IM conferencing, where the S/MIME certificate name and cases, such as IM conferencing, where the S/MIME certificate name and
the signaled identity will not match. In these cases the client the signaled identity will not match. In these cases, the client
should ensure that the user is informed that the message came from should ensure that the user is informed that the message came from
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.
In some cases, a sending device may need to attribute a message to In some cases, a sending device may need to attribute a message to
some other identity, and may use different identities for different some other identity, and may use different identities for different
messages in the same session. For example, a conference server may messages in the same session. For example, a conference server may
send messages on behalf of multiple users on the same session. send messages on behalf of multiple users on the same session.
Rather than add additional headers to MSRP for this purpose, MSRP Rather than add additional header fields to MSRP for this purpose,
relies on the message/cpim format for this purpose. The sender may MSRP relies on the message/cpim format for this purpose. The sender
envelope such a message in a message/cpim body, and place the actual may envelop such a message in a message/cpim body, and place the
sender identity in the From field. The trustworthiness of such an actual sender identity in the From field. The trustworthiness of
attribution is affected by the security properties of the session in such an attribution is affected by the security properties of the
the same way that the trustworthiness of the identity of the actual session in the same way that the trustworthiness of the identity of
peer is affected, with the additional issue of determining whether the actual peer is affected, with the additional issue of determining
the recipient trusts the sender to assert the identity. whether the recipient trusts the sender to assert the identity.
This approach can result in nesting of message/cpim envelopes. For This approach can result in nesting of message/cpim envelopes. For
example, a message originates from a CPIM gateway, and is then example, a message originates from a CPIM gateway, and is then
forwarded by a conference server onto a new session. Both the forwarded by a conference server onto a new session. Both the
gateway and the conference server introduce envelopes. In this case, gateway and the conference server introduce envelopes. In this case,
the recipient client SHOULD indicate the chain of identity assertions the recipient client SHOULD indicate the chain of identity assertions
to the user, rather than allow the user to assume that either the to the user, rather than allow the user to assume that either the
gateway or the conference server originated the message. gateway or the conference server originated the message.
It is possible that a recipient might receive messages that are It is possible that a recipient might receive messages that are
skipping to change at page 49, line 20 skipping to change at page 49, line 25
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.
15. IANA Considerations 15. IANA Considerations
This specification requests the IANA to create a registry for MSRP This specification instructs IANA to create a new registry for MSRP
parameters under http://www.iana.org/assignments/msrp-parameters. parameters. The MSRP Parameter registry is a container for sub-
This section further introduces sub-registries for MSRP method names, registries. This section further introduces sub-registries for MSRP
status codes, and header field names. method names, status codes, and header field names.
[Note to RFC Editor: Please replace all occurrences of RFCXXXX in [NOTE TO IANA/RFC Editor: Please replace all occurrences of RFCXXXX
this section with the actual number assigned to this document.] in this section with the actual number assigned to this document.]
15.1 MSRP Method Names 15.1. MSRP Method Names
This specification establishes the Method sub-registry under This specification establishes the Method sub-registry under MSRP
http://www.iana.org/assignments/msrp-parameters and initiates its Parameters and initiates its population as follows:
population as follows:
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. The method name.
The RFC number in which the method is registered. 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 sub-registry under This specification establishes the header field-Field sub-registry
http://www.iana.org/assignments/msrp-parameters. Its initial under MSRP Parameters. Its initial population is defined as follows:
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 Method: order to register a new MSRP Method:
The header field name. The header field name.
The RFC number in which the method is registered. 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
http://www.iana.org/assignments/msrp-parameters. Its initial MSRP Parameters. Its initial population is defined in Section 10.
population is defined in Section 10. It takes the following format: It 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 Method: order to register a new MSRP Method:
The status code number. The status code number.
The RFC number in which the method is registered. The RFC number in which the method is registered.
15.4 MSRP Port 15.4. MSRP Port
MSRP uses TCP port XYX, to be determined by IANA after this document MSRP uses TCP port XYZ, to be determined by IANA after this document
is approved for publication. Usage of this value is described in is approved for publication. Usage of this value is described in
Section 6 Section 6.
15.5 MSRP URL Schemes [NOTE TO IANA/RFC Editor: Please replace XYZ in this section with the
assigned port number.]
15.5. MSRP URL Schemes
This document defines the URL schemes of "msrp" and "msrps". This document defines the URL schemes of "msrp" and "msrps".
Syntax: See Section 6. Syntax: See Section 6.
Character Encoding: See Section 6. Character Encoding: See Section 6.
Intended Usage: See Section 6. Intended Usage: See Section 6.
Protocols: The Message Session Relay Protocol (MSRP). Protocols: The Message Session Relay Protocol (MSRP).
Security Considerations: See Section 14. Security Considerations: See Section 14.
Relevant Publications: RFCXXXX Relevant Publications: RFCXXXX
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
the associated media format namespace. The "TCP/MSRP" and "TCP/TLS/ the associated media format namespace. The "TCP/MSRP" and "TCP/TLS/
MSRP" protocol values allow only one value in the format field (fmt), MSRP" protocol values allow only one value in the format field (fmt),
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 MIME 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 contains
a list of MIME content-types that the endpoint is willing to a list of MIME content-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 MIME 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 MIME 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 MIME content-types that the endpoint is willing
to receive in an MSRP message with multipart content, but may not to receive in an MSRP message with multipart content, but may not
be used as the outermost type of the message. It may contain zero be used as the outermost type of the message. It may contain zero
or more registered MIME types, or "*" in a space delimited string. or more registered MIME 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
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 URL 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
extensive work to this document: Chris Boulton, Paul Kyzivat, Orit extensive work to this document: Chris Boulton, Paul Kyzivat, Orit
Levin, Adam Roach, Jonathan Rosenberg, and Robert Sparks. Levin, Adam Roach, Jonathan Rosenberg, and Robert Sparks.
The following people contributed substantial discussion and feedback The following people contributed substantial discussion and feedback
to this ongoing effort: Eric Burger, Allison Mankin, Jon Peterson, to this ongoing effort: Eric Burger, Allison Mankin, Jon Peterson,
Brian Rosen, Dean Willis, Aki Niemi, Hisham Khartabil, Pekka Pessi, Brian Rosen, Dean Willis, Aki Niemi, Hisham Khartabil, Pekka Pessi,
Miguel Garcia, Peter Ridler, and Sam Hartman. Miguel Garcia, Peter Ridler, Sam Hartman, and Jean Mahoney.
17. References 17. References
17.1 Normative References 17.1. Normative References
[1] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [1] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", draft-ietf-mmusic-sdp-new-23 (work in Description Protocol", draft-ietf-mmusic-sdp-new-23 (work in
progress), December 2004. progress), December 2004.
[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.
skipping to change at page 53, line 15 skipping to change at page 53, line 22
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies", Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996. RFC 2045, November 1996.
[8] Troost, R., Dorner, S., and K. Moore, "Communicating [8] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Content- Presentation Information in Internet Messages: The Content-
Disposition Header Field", RFC 2183, August 1997. Disposition header field", RFC 2183, August 1997.
[9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", rfc 3986, Resource Identifiers (URI): Generic Syntax", RFC 3986,
January 2005. January 2005.
[10] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and [10] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
T. Wright, "Transport Layer Security (TLS) Extensions", T. Wright, "Transport Layer Security (TLS) Extensions",
RFC 3546, June 2003. RFC 3546, June 2003.
[11] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE [11] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002. Method", RFC 3311, October 2002.
[12] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging [12] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging
skipping to change at page 53, line 41 skipping to change at page 53, line 48
[13] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for [13] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Secur ity (TLS)", RFC 3268, June 2002. Transport Layer Secur ity (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.
17.2 Informational References 17.2. Informational References
[16] Johnston, A. and O. Levin, "Session Initiation Protocol Call [16] Johnston, A. and O. Levin, "Session Initiation Protocol Call
Control - Conferencing for User Agents", Control - Conferencing for User Agents",
draft-ietf-sipping-cc-conferencing-05 (work in progress), draft-ietf-sipping-cc-conferencing-05 (work in progress),
October 2004. October 2004.
[17] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, [17] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
"Best Current Practices for Third Party Call Control in the "Best Current Practices for Third Party Call Control in the
Session Initiation Protocol", rfc 3725, April 2004. Session Initiation Protocol", RFC 3725, April 2004.
[18] Sparks, R. and A. Johnston, "Session Initiation Protocol Call [18] Sparks, R. and A. Johnston, "Session Initiation Protocol Call
Control - Transfer", draft-ietf-sipping-cc-transfer-03 (work in Control - Transfer", draft-ietf-sipping-cc-transfer-03 (work in
progress), October 2004. progress), October 2004.
[19] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and [19] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002. Instant Messaging", RFC 3428, December 2002.
[20] Mahy, R., "Benefits and Motivation for Session Mode Instant [20] Mahy, R., "Benefits and Motivation for Session Mode Instant
skipping to change at page 54, line 48 skipping to change at page 55, line 6
[27] Ramsdell, B., "S/MIME Version 3 Message Specification", [27] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633, June 1999. RFC 2633, June 1999.
[28] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone [28] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone
Generation in the Session Initiation Protocol (SIP)", Generation in the Session Initiation Protocol (SIP)",
draft-ietf-sipping-early-media-02 (work in progress), draft-ietf-sipping-early-media-02 (work in progress),
June 2004. June 2004.
[29] Saint-Andre, P., "Extensible Messaging and Presence Protocol [29] Saint-Andre, P., "Extensible Messaging and Presence Protocol
(XMPP): Instant Messaging and Presence", rfc 3921, (XMPP): Instant Messaging and Presence", RFC 3921,
October 2004. October 2004.
[30] Rosenberg, J., "Indicating User Agent Capabilities in the [30] Rosenberg, J., "Indicating User Agent Capabilities in the
Session Initiation Protocol (SIP)", rfc 3840, August 2004. Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[31] Peterson, J., "Address Resolution for Instant Messaging and [31] Peterson, J., "Address Resolution for Instant Messaging and
Presence", rfc 3861, August 2004. Presence", rfc 3861, August 2004.
Authors' Addresses Authors' Addresses
Ben Campbell (editor) Ben Campbell (editor)
Estacado Systems Estacado Systems
17210 Campbell Road 17210 Campbell Road
Suite 250 Suite 250
 End of changes. 177 change blocks. 
553 lines changed or deleted 563 lines changed or added

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