draft-ietf-simple-message-sessions-09.txt   draft-ietf-simple-message-sessions-10.txt 
SIMPLE WG B. Campbell, Ed. SIMPLE WG B. Campbell, Ed.
Internet-Draft Estacado Systems Internet-Draft Estacado Systems
Expires: April 24, 2005 R. Mahy, Ed. Expires: August 24, 2005 R. Mahy, Ed.
Airespace Airespace
C. Jennings, Ed. C. Jennings, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
October 24, 2004 February 20, 2005
The Message Session Relay Protocol The Message Session Relay Protocol
draft-ietf-simple-message-sessions-09.txt draft-ietf-simple-message-sessions-10.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 24, 2005. This Internet-Draft will expire on August 24, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes the Message Session Relay Protocol (MSRP), a This document describes the Message Session Relay Protocol (MSRP), 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 (SIP). such as the Session Initiation Protocol (SIP).
Table of Contents Table of Contents
1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction and Background . . . . . . . . . . . . . . . . 4 2. Introduction and Background . . . . . . . . . . . . . . . . 4
3. Applicability of MSRP . . . . . . . . . . . . . . . . . . . 5 3. Applicability of MSRP . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 6
5. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 MSRP Framing and Message Chunking . . . . . . . . . . . . 8 5.1 MSRP Framing and Message Chunking . . . . . . . . . . . . 8
5.2 MSRP Addressing . . . . . . . . . . . . . . . . . . . . . 9 5.2 MSRP Addressing . . . . . . . . . . . . . . . . . . . . . 9
5.3 MSRP Transaction and Report Model . . . . . . . . . . . . 9 5.3 MSRP Transaction and Report Model . . . . . . . . . . . . 10
5.4 MSRP Connection Model . . . . . . . . . . . . . . . . . . 10 5.4 MSRP Connection Model . . . . . . . . . . . . . . . . . . 11
6. MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 13 6.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 14
6.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 14 6.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 14
7. Method-Specific Behavior . . . . . . . . . . . . . . . . . . 14 7. Method-Specific Behavior . . . . . . . . . . . . . . . . . . 15
7.1 Constructing Requests . . . . . . . . . . . . . . . . . . 14 7.1 Constructing Requests . . . . . . . . . . . . . . . . . . 15
7.1.1 Delivering SEND requests . . . . . . . . . . . . . . . 15 7.1.1 Delivering SEND requests . . . . . . . . . . . . . . . 16
7.1.2 Sending REPORT requests . . . . . . . . . . . . . . . 17 7.1.2 Sending REPORT requests . . . . . . . . . . . . . . . 18
7.1.3 Failure REPORT Generation . . . . . . . . . . . . . . 18 7.1.3 Failure REPORT Generation . . . . . . . . . . . . . . 19
7.2 Constructing Responses . . . . . . . . . . . . . . . . . . 19 7.2 Constructing Responses . . . . . . . . . . . . . . . . . . 20
7.3 Receiving Requests . . . . . . . . . . . . . . . . . . . . 20 7.3 Receiving Requests . . . . . . . . . . . . . . . . . . . . 21
7.3.1 Receiving SEND requests . . . . . . . . . . . . . . . 20 7.3.1 Receiving SEND requests . . . . . . . . . . . . . . . 21
7.3.2 Receiving REPORT requests . . . . . . . . . . . . . . 22 7.3.2 Receiving REPORT requests . . . . . . . . . . . . . . 22
8. Using MSRP with SIP . . . . . . . . . . . . . . . . . . . . 22 8. Using MSRP with SIP . . . . . . . . . . . . . . . . . . . . 23
8.1 SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . 22 8.1 SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . 23
8.1.1 URL Negotiations . . . . . . . . . . . . . . . . . . . 25 8.1.1 URL Negotiations . . . . . . . . . . . . . . . . . . . 25
8.1.2 Path Attributes with Multiple URLs . . . . . . . . . . 26 8.1.2 Path Attributes with Multiple URLs . . . . . . . . . . 26
8.1.3 Updated SDP Offers . . . . . . . . . . . . . . . . . . 27 8.1.3 SDP Connection and Media Lines . . . . . . . . . . . . 27
8.1.4 Example SDP Exchange . . . . . . . . . . . . . . . . . 27 8.1.4 Updated SDP Offers . . . . . . . . . . . . . . . . . . 28
8.1.5 Connection Negotiation . . . . . . . . . . . . . . . . 28 8.1.5 Example SDP Exchange . . . . . . . . . . . . . . . . . 28
8.2 MSRP User Experience with SIP . . . . . . . . . . . . . . 28 8.1.6 Connection Negotiation . . . . . . . . . . . . . . . . 29
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 28 8.2 MSRP User Experience with SIP . . . . . . . . . . . . . . 29
10. Response Code Descriptions . . . . . . . . . . . . . . . . . 31 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 30
10.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. Response Code Descriptions . . . . . . . . . . . . . . . . . 32
10.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.3 403 . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.4 415 . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10.3 403 . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.5 426 . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10.4 408 . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.6 481 . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10.5 413 . . . . . . . . . . . . . . . . . . . . . . . . . . 33
10.7 501 . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10.6 415 . . . . . . . . . . . . . . . . . . . . . . . . . . 33
10.8 506 . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10.7 423 . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10.8 426 . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.1 Basic IM session . . . . . . . . . . . . . . . . . . . . 32 10.9 481 . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.2 Message with XHTML Content . . . . . . . . . . . . . . . 34 10.10 501 . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.3 Chunked Message . . . . . . . . . . . . . . . . . . . . 35 10.11 506 . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.4 System Message . . . . . . . . . . . . . . . . . . . . . 35 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34
11.5 Positive Report . . . . . . . . . . . . . . . . . . . . 36 11.1 Basic IM session . . . . . . . . . . . . . . . . . . . . 34
11.6 Forked IM . . . . . . . . . . . . . . . . . . . . . . . 36 11.2 Message with XHTML Content . . . . . . . . . . . . . . . 36
12. Extensibility . . . . . . . . . . . . . . . . . . . . . . . 39 11.3 Chunked Message . . . . . . . . . . . . . . . . . . . . 36
13. CPIM compatibility . . . . . . . . . . . . . . . . . . . . . 39 11.4 System Message . . . . . . . . . . . . . . . . . . . . . 36
14. Security Considerations . . . . . . . . . . . . . . . . . . 40 11.5 Positive Report . . . . . . . . . . . . . . . . . . . . 37
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 44 11.6 Forked IM . . . . . . . . . . . . . . . . . . . . . . . 37
15.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . 44 12. Extensibility . . . . . . . . . . . . . . . . . . . . . . . 40
15.2 MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . 44 13. CPIM compatibility . . . . . . . . . . . . . . . . . . . . . 40
15.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . 44 14. Security Considerations . . . . . . . . . . . . . . . . . . 41
15.3.1 Accept Types . . . . . . . . . . . . . . . . . . . . 44 14.1 Transport Level Protection . . . . . . . . . . . . . . . 42
15.3.2 Wrapped Types . . . . . . . . . . . . . . . . . . . 44 14.2 S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . 43
15.3.3 Max Size . . . . . . . . . . . . . . . . . . . . . . 44 14.3 Other Security Concerns . . . . . . . . . . . . . . . . 44
15.3.4 Path . . . . . . . . . . . . . . . . . . . . . . . . 45 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 45
16. Change History . . . . . . . . . . . . . . . . . . . . . . . 45 15.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . 45
16.1 draft-ietf-simple-message-sessions-09 . . . . . . . . . 45 15.2 MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . 45
16.2 draft-ietf-simple-message-sessions-08 . . . . . . . . . 45 15.3 SDP Transport Protocol . . . . . . . . . . . . . . . . . 46
16.3 draft-ietf-simple-message-sessions-07 . . . . . . . . . 46 15.4 SDP Attribute Names . . . . . . . . . . . . . . . . . . 46
16.4 draft-ietf-simple-message-sessions-06 . . . . . . . . . 46 15.4.1 Accept Types . . . . . . . . . . . . . . . . . . . . 46
16.5 draft-ietf-simple-message-sessions-05 . . . . . . . . . 47 15.4.2 Wrapped Types . . . . . . . . . . . . . . . . . . . 46
16.6 draft-ietf-simple-message-sessions-04 . . . . . . . . . 47 15.4.3 Max Size . . . . . . . . . . . . . . . . . . . . . . 47
16.7 draft-ietf-simple-message-sessions-03 . . . . . . . . . 47 15.4.4 Path . . . . . . . . . . . . . . . . . . . . . . . . 47
16.8 draft-ietf-simple-message-sessions-02 . . . . . . . . . 48 16. Change History . . . . . . . . . . . . . . . . . . . . . . . 47
16.9 draft-ietf-simple-message-sessions-01 . . . . . . . . . 48 16.1 draft-ietf-simple-message-sessions-10 . . . . . . . . . 47
16.10 draft-ietf-simple-message-sessions-00 . . . . . . . . . 49 16.2 draft-ietf-simple-message-sessions-09 . . . . . . . . . 48
16.11 draft-campbell-simple-im-sessions-01 . . . . . . . . . . 49 16.3 draft-ietf-simple-message-sessions-08 . . . . . . . . . 48
17. Contributors and Acknowledgments . . . . . . . . . . . . . . 49 16.4 draft-ietf-simple-message-sessions-07 . . . . . . . . . 49
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 16.5 draft-ietf-simple-message-sessions-06 . . . . . . . . . 49
18.1 Normative References . . . . . . . . . . . . . . . . . . . 50 16.6 draft-ietf-simple-message-sessions-05 . . . . . . . . . 50
18.2 Informational References . . . . . . . . . . . . . . . . . 51 16.7 draft-ietf-simple-message-sessions-04 . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 52 16.8 draft-ietf-simple-message-sessions-03 . . . . . . . . . 50
Intellectual Property and Copyright Statements . . . . . . . 53 16.9 draft-ietf-simple-message-sessions-02 . . . . . . . . . 51
16.10 draft-ietf-simple-message-sessions-01 . . . . . . . . . 51
16.11 draft-ietf-simple-message-sessions-00 . . . . . . . . . 51
16.12 draft-campbell-simple-im-sessions-01 . . . . . . . . . . 52
17. Contributors and Acknowledgments . . . . . . . . . . . . . . 52
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
18.1 Normative References . . . . . . . . . . . . . . . . . . 52
18.2 Informational References . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55
Intellectual Property and Copyright Statements . . . . . . . 56
1. Conventions 1. 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".
2. Introduction and Background 2. Introduction and Background
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, an 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 completely independently.
The SIMPLE Working Group describes messaging schemes that only track The SIMPLE Working Group describes messaging schemes that only track
individual messages as "page-mode" messages, whereas messaging that individual messages as "page-mode" messages, whereas messaging that
is part of a "session" with a definite start and end is called is part of a "session" with a definite start and end is called
session-mode messaging. "session-mode" messaging.
Page-mode messaging is enabled in SIMPLE via the SIP [4]MESSAGE Page-mode messaging is enabled in SIMPLE via the SIP [4]MESSAGE
method [18]. Session-mode messaging has a number of benefits [19] method [18]. Session-mode messaging has a number of benefits [19]
over page-mode messaging however, such as explicit rendezvous, over page-mode messaging however, such as explicit rendezvous,
tighter integration with other media types, direct client-to-client tighter 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 included in an offer or answer [3] using the Session sessions can be included in an offer or answer [3] using the Session
skipping to change at page 4, line 49 skipping to change at page 4, line 49
session as one of the possible media types in a session. For session as one of the possible media types in a session. For
instance, Alice may want to communicate with Bob. Alice doesn't know instance, Alice may want to communicate with Bob. Alice doesn't know
at the moment whether Bob has his phone or his IM client handy, but at the moment whether Bob has his phone or his IM client handy, but
she's willing to use either. She sends an invitation to a session to she's willing to use either. She sends an invitation to a session to
the address of record she has for Bob, sip:bob@example.com. Her the address of record she has for Bob, sip:bob@example.com. Her
invitation offers both voice and an IM session. The SIP services at invitation offers both voice and an IM session. The SIP services at
example.com forward the invitation to Bob at his currently registered example.com forward the invitation to Bob at his currently registered
clients. Bob accepts the invitation at his IM client and they begin clients. Bob accepts the invitation at his IM client and they begin
a threaded chat conversation. a threaded chat conversation.
When a user uses an IM URL, other documents define how DNS can be
used 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 for the media in SDP. This document defines how the
offer-answer exchange works to establish MSRP connections and how
messages are sent across the MSRP protocol but it does not deal with
the issues 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 [17] Alice to Carol, introducing them into their own transfer [17] 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 utilizing third-party call
control [16] and conferencing [15] applications. control [16] and conferencing [15] applications.
3. Applicability of MSRP 3. Applicability of MSRP
MSRP is not designed for use as a standalone protocol. MSRP MUST MSRP is not designed for use as a standalone protocol. MSRP MUST be
only be used 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
with an MSRP session to each of the participating endpoints. The with an MSRP session to each of the participating endpoints. The
rendezvous mechanism MUST implement mechanisms to provide these rendezvous mechanism MUST implement mechanisms to provide these
URLs securely - they MUST NOT be made available to an untrusted URLs securely - they MUST NOT be made available to an untrusted
third party or be easily discoverable. third party or be easily discoverable.
The rendezvous mechanism MUST provide mechanisms for the The rendezvous mechanism MUST provide mechanisms for the
negotiation of any supported MSRP extensions that are not negotiation of any supported MSRP extensions that are not
skipping to change at page 6, line 7 skipping to change at page 6, line 14
4. Protocol Overview 4. Protocol Overview
MSRP is a text-based, connection-oriented protocol for exchanging MSRP is a text-based, connection-oriented protocol for exchanging
arbitrary (binary) MIME content, especially instant messages. This arbitrary (binary) MIME 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 offer the other (Bob) a SIP invitation containing an offered
session-description which includes a session of MSRP. The receiving session-description which includes a session of MSRP. The receiving
SIP user agent can accept the invitation and include an answer SIP user 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 session description contains an MSRP URL that describes where she is
willing to receive MSRP requests from Bob, and vice-versa. (Note: willing to receive MSRP requests from Bob, and vice-versa. (Note:
Some lines in the examples are removed for clarity and brevity.) Some lines in the examples are removed for clarity and brevity.)
Alice sends to Bob: Alice sends to Bob:
INVITE sip:alice@atlanta.example.com SIP/2.0 INVITE sip:alice@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
Content-Type: application/sdp Content-Type: application/sdp
c=IN IP4 10.1.1.1 c=IN IP4 atlanta.example.com
m=message 9 msrp * m=message 7654 msrp/tcp *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrp://atlanta.example.com:7654/jshA7we;tcp a=path:msrp://atlanta.example.com:7654/jshA7we;tcp
Bob sends to Alice: Bob sends to Alice:
SIP/2.0 200 OK SIP/2.0 200 OK
To: <sip:bob@biloxi.example.com>;tag=087js To: <sip:bob@biloxi.example.com>;tag=087js
From: <sip:alice@atlanta.example.com>;tag=786 From: <sip:alice@atlanta.example.com>;tag=786
Call-ID: 3413an89KU Call-ID: 3413an89KU
Content-Type: application/sdp Content-Type: application/sdp
c=IN IP4 10.2.2.2 c=IN IP4 biloxi.example.com
m=message 9 msrp * m=message 12763 msrp/tcp *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrp://biloxi.example.com:12763/kjhd37s2s2;tcp a=path:msrp://biloxi.example.com:12763/kjhd37s2s2;tcp
Alice sends to Bob: Alice sends to Bob:
ACK sip:alice@atlanta.example.com SIP/2.0 ACK sip:alice@atlanta.example.com SIP/2.0
To: <sip:bob@biloxi.example.com>;tag=087js To: <sip:bob@biloxi.example.com>;tag=087js
From: <sip:alice@atlanta.example.com>;tag=786 From: <sip:alice@atlanta.example.com>;tag=786
Call-ID: 3413an89KU Call-ID: 3413an89KU
skipping to change at page 7, line 12 skipping to change at page 7, line 19
SEND request. When Alice receives Bob's answer, she checks to see if SEND request. When Alice receives Bob's answer, she checks to see if
she has an existing connection to Bob. If not, she opens a new she has an existing connection to Bob. If not, she opens a new
connection to Bob using the URL he provided in the SDP. Alice then connection to Bob using the URL he provided in the SDP. Alice then
delivers a SEND request to Bob with her initial message, and Bob delivers a SEND request to Bob with her initial message, and Bob
replies indicating that Alice's request was received successfully. replies indicating that Alice's request was received successfully.
MSRP a786hjs2 SEND MSRP a786hjs2 SEND
To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp
From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp
Message-ID: 87652 Message-ID: 87652
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 Message-ID: 87652
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 as a final boundary marker. transaction identifier that is also used as a final boundary marker.
Next she includes the path of URLs to the destination in the To-Path Next 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, and her own URL in the From-Path header. In this typical
case there is just one "hop", so there is only one URL in each path case there is just one "hop", so there is only one URL in each path
header field. She also includes a message ID which she can use to header field. She also includes a message ID which she can use to
correlate responses and status reports with the original message. correlate responses and status reports with the original message.
Next she puts the actual content. Finally she closes the request Next she puts the actual content. Finally she closes the request
with an end line: seven hyphens, the transaction identifier / with an end line: seven hyphens, the transaction identifier /
boundary marker and a "$" to indicate this request contains the end boundary marker and a "$" to indicate this request contains the end
of a complete message. 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. detail in Section 5.1. The Byte-Range header identifies the portion
of the message carried in this chunk and the total size of 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
to URLs they are not expecting to service, and can correlate the to URLs they are not expecting to service, and can correlate the
specific URL with the probable sender. Alice and Bob can also use specific URL with the probable sender. Alice and Bob can also use
TLS [1] to provide channel security over this hop. To receive MSRP TLS [1] to provide channel security over this hop. To receive MSRP
requests over a TLS protected connection, Alice or Bob could requests over a TLS protected connection, Alice or Bob could
advertise URLs with the "msrps" scheme instead of "msrp." advertise URLs with the "msrps" scheme instead of "msrp."
This document specifies MSRP behavior only 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 [20] (referred to herein as specify behavior for MSRP relay devices [20] (referred to herein as
"relays") is occuring as a separate effort. MSRP is designed with "relays") is occurring as a separate effort. MSRP is designed with
the expectation that MSRP can carry URLs for nodes on the far side of the expectation that MSRP can carry URLs for nodes on the far side of
such relays. For this reason, a URL with the "msrps" scheme makes no such relays. For this reason, a URL with the "msrps" scheme makes no
assertion about the security properties of other hops, just the next assertion about the security properties of other hops, just the next
hop. The user agent knows the URL for each hop, so it can verify hop. The user agent knows the URL for each hop, so it can verify
that each URL has the desired security properties. that each URL has the desired security properties.
MSRP URLs are discussed in more detail in Section 6. MSRP URLs are discussed in more detail in Section 6.
An adjacent pair of busy MSRP nodes (for example two relays) can An adjacent pair of busy MSRP nodes (for example two relays) can
easily have several sessions, and exchange traffic for several easily have several sessions, and exchange traffic for several
skipping to change at page 8, line 37 skipping to change at page 8, line 48
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 interruped to ensure the overall message. Long chunks may be interrupted in
fairness across shared transport connections. To support this, MSRP mid-transmission to ensure fairness across shared transport
uses a boundary based framing mechanism. The start line of an MSRP connections. To support this, MSRP uses a boundary based framing
request contains a unique boundary string that is used to indicate mechanism. The start line of an MSRP request contains a unique
the end of the request. Following the boundary string at the end of boundary string that is used to indicate the end of the request.
the body data, there is a flag that indicates whether this is the Following the boundary string at the end of the body data, there is a
last chunk of data for this message or whether the message will be flag that indicates whether this is the last chunk of data for this
continued in a subsequent chunk. There is also a Byte-Range header message or whether the message will be continued in a subsequent
in the request that indicates the overall position of this chunk chunk. There is also a Byte-Range header in the request that
inside the complete message. indicates the overall position of this 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
-------dkei38sd+ -------dkei38sd+
MSRP dkei38ia SEND MSRP dkei38ia SEND
Message-ID: 456 Message-ID: 456
Byte-Range: 5-8/8 Byte-Range: 5-8/8
Content-Type: text/plain Content-Type: text/plain
EFGH EFGH
-------dkei38ia$ -------dkei38ia$
This chunking mechanism allows a sender to interrupt a chunk part way This chunking mechanism allows a sender to interrupt a chunk part of
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. the same connection. Any chunk that is larger than 2048 octets MUST
be interruptible. While MSRP would be simpler to implement if each
The ability to interrupt messages is needed so that TCP connections MSRP session used its own TCP connection, that approach would
can be shared. Connection sharing is necessary for "fair" allocation circumvent the congestion avoidance features of TCP.
of bandwidth in congestion situations and for allowing MSRP network
elements that have a very large number of concurrent connections to
different users.
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
headers each allow for a list of URLs. This was done to allow the headers 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.
skipping to change at page 10, line 25 skipping to change at page 10, line 36
and the sender requested a success report. A receiver only sends a and the sender requested a success report. A receiver only sends a
failure REPORT if the request failed and the sender requested failure failure REPORT if the request failed and the sender requested failure
reports. 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 "Report-Success" can have a value of "yes" or "no" and the The header "Success-Report" can have a value of "yes" or "no" and the
"Report-Failure" header can have a value of "yes", "no", or "Failure-Report" header can have a value of "yes", "no", or
"partial". "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. Report-Success might be scenarios of currently deployed IM systems. Success-Report might be
"no" in many public systems to reduce load but is used in some "no" in many public systems to reduce load but is used in some
current enterprise systems, such as systems used for securities current enterprise systems, such as systems used for securities
trading. A Report-Failure 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 Report-Failure 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 but some other systems choose to use a value of message failed. A Failure-Report of "partial" is a way to report
"partial" to reduce the load on the servers caused by 200 OK errors except timeouts. The timeout error reporting requires the
responses, but still allow error responses to be sent in many cases. sending hop to run a timer and that receiving hop to send an
acknowledgment to stop the timer. Some systems don't want the
overhead of doing this so choose not to but still allow error
responses to be sent in many cases and these systems can use
"partial".
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 MSRP wishes to send a request to a peer identified by an MSRP
URL, it first needs a transport connection, with the appropriate URL, it first needs a transport connection, with the appropriate
security properties, to the host specified in the URL. If the sender security properties, to the host specified in the URL. If the sender
already has such a connection, that is, one associated with the same already has such a connection, that is, one associated with the same
host, port, and URL scheme, then it SHOULD reuse that connection. host, port, and URL scheme, then it SHOULD reuse that connection.
When a new MSRP session is created, the element that sent the SDP When a new MSRP session is created, the offerer MUST act as the
offer MUST immediately issue a SEND request to the answerer. This "active" endpoint, meaning that it is responsible for opening the
request MAY have a empty body, or MAY carry content. transport connection to the answerer, if a new connection is
required. However, this requirement MAY be weakened if standardized
mechanisms for negotiating the connection direction become available,
and is implemented by both parties to the connection.
Likewise, the offerer MUST open the transport connection to the Likewise, the active endpoint MUST immediately issue a SEND request.
answerer, if a new connection is required. However, this requirement This initial SEND request MAY have a empty body, or MAY carry
may be weakened if standardized mechanisms for negotiating the content.
connection direction become available, and is implemented by both
parties to the connection.
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
Section 6.2. Connections using the msrps: scheme MUST use TLS. The Section 6.2. Connections using the msrps: scheme MUST use TLS. The
SubjectAltName in the received certificate MUST match the hostname SubjectAltName in the received certificate MUST match the hostname
part of the URL and the certificate MUST be valid, including having a part of the URL and the certificate MUST be valid, including having a
date that is valid and being signed by an acceptable certificate date that is valid and being signed by an acceptable certificate
authority. At this point the device that initiated the connection authority. At this point the device that initiated the connection
can assume that this connection is with the correct host. can assume that this connection is with the correct host.
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 it wait until it receives a request on the connection, at which it
infers the identity of the connecting device from the associated SDP. infers the identity of the connecting device from the associated
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 handed out 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 that this URL was given to. 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 so, it MUST reject the request with a 506 on another connection. If the session is already in use, it MUST
response. reject the request with a 506 response.
If it were legal to have multiple connections associated with the If it were legal to have multiple connections associated with the
same session, a security problem would exist. If the initial SEND same session, a security problem would exist. If the initial SEND
request is not protected, an eavesdropper might learn the URL, and request is not protected, an eavesdropper might learn the URL, and
use it to insert messages into the session via a different use it to insert messages into the session via a different
connection. connection.
If a connection fails for any reason, then an MSRP endpoint MUST If a connection fails for any reason, then an MSRP endpoint MUST
consider any sessions associated with the connection as also having consider any sessions associated with the connection as also having
failed. When an endpoint notices such a failure, it MAY attempt to failed. When an endpoint notices such a failure, it MAY attempt to
re-create any such sessions. If it chooses to do so, it MUST use new re-create any such sessions. If it chooses to do so, it MUST use new
SDP exchange, for example, in a SIP re-invite or update [11]. If a SDP exchange, for example, in a SIP re-INVITE or UPDATE [11] request.
replacement session is successfully created, endpoints MAY attempt to If a replacement session is successfully created, endpoints MAY
resend any content for which delivery on the original session could attempt to resend any content for which delivery on the original
not be confirmed. If it does this, the Message-ID values for the session could not be confirmed. If it does this, the Message-ID
resent messages MUST match those used in the initial attempts. If values for the resent messages MUST match those used in the initial
the receiving endpoint receives more than one message with the same attempts. If the receiving endpoint receives more than one message
Message-ID. It SHOULD assume that the messages are duplicates. It with the same Message-ID. It SHOULD assume that the messages are
MAY take any action based on that knowledge, but SHOULD NOT present duplicates. It MAY take any action based on that knowledge, but
the duplicate messages to the user without warning of the SHOULD NOT present the duplicate messages to the user without warning
duplication. of the duplication.
In this situation, the endpoint MUST choose Message-ID values so that In this situation, the endpoint MUST ensure that the Message-ID of
they are unique in the context of both the original session and the each distinct (i.e. non-duplicate) message is unique in the context
replacement session. 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
with it. with it.
6. MSRP URLs 6. MSRP URLs
URLs using the MSRP and MSRPS schema are used to identify a session URLs using the MSRP and MSRPS schema are used to identify a session
of instant messages at a particular MSRP device. MSRP URLs are of instant messages at a particular MSRP device. MSRP URLs are
ephemeral; an MSRP device may use a different MSRP URL in a different ephemeral; an MSRP device will generally use a different MSRP URL for
session. An MSRP URL generally has no meaning outside of the each distinct session. An MSRP URL generally has no meaning outside
associated session. of the associated session.
An MSRP URL follows a subset of the URL syntax in Appendix A of An MSRP URL follows a subset of the URL syntax in Appendix A of
RFC2396bis [9], with a scheme of "msrp" or "msrps". The syntax is RFC2396bis [9], with a scheme of "msrp" or "msrps". The syntax is
described in Section 9. described in Section 9.
The constructions for "userinfo", and "unreserved" are detailed in The constructions for "userinfo", and "unreserved" are detailed in
RFC2396bis [9]. In order to allow IPV6 addressing, the construction RFC2396bis [9]. In order to allow IPV6 addressing, the construction
for hostport is that used for SIP in RFC3261. URLs designating MSRP for hostport is that used for SIP in RFC3261. URLs designating MSRP
over TCP MUST include the "tcp" transport parameter. over TCP MUST include the "tcp" transport parameter.
Since this document only specifies MSRP over TCP, all MSRP URLs Since this document only specifies MSRP over TCP, all MSRP URLs
herein use the "tcp" transport parameter. Documents that provide herein use the "tcp" transport parameter. Documents that provide
bindings on other transports should define respective parameters bindings on other transports should define respective parameters
for those transports. for those transports.
An MSRP URL hostport field identifies a participant in a particular An MSRP URL hostport field identifies a participant in a particular
MSRP session. If the hostport contains a numeric IP address, it MUST MSRP session. If the hostport contains a numeric IP address, it MUST
also contain a port. The session-id part identifies a particular also contain a port. The session-id part identifies a particular
session the participant. The absence of the session-id part session of the participant. The absence of the session-id part
indicates a reference to an MSRP host device, but does not indicates a reference to an MSRP host device, but does not
specifically refer to a particular session. specifically refer to a particular session.
A scheme of "msrps" indicates the underlying connection MUST be A scheme of "msrps" indicates the underlying connection MUST be
protected with TLS. protected with TLS.
MSRP has an IANA registered recommended port defined in Section 15.1. MSRP has an IANA registered recommended port defined in Section 15.1.
This value is not a default, as the URL negotiation process described This value is not a default, as the URL negotiation process described
herein will always include explicit port numbers. However, the URLs herein will always include explicit port numbers. However, the URLs
SHOULD be configured so that the recommended port is used whenever SHOULD be configured so that the recommended port is used whenever
skipping to change at page 13, line 40 skipping to change at page 14, line 10
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 exactly. 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 equivalency. Otherwise, these are compared for address and port equivalency. Otherwise,
hostpart is compared as a case insensitive character string. hostpart is compared as a case insensitive character string.
3. If the port exists explicitly in either URL, then it must match 3. If the port exists explicitly in either URL, then it must match
exactly. An URL with and explicit port is never equivalent to exactly. An URL with an explicit port is never equivalent to
another with no port specified. another with no port specified.
4. The session-id part is compared as case sensitive. A URL without 4. The session-id part is compared as case sensitive. A URL without
a session-id part is never equivalent to one that includes one. a session-id part is never equivalent to one that includes one.
5. URLs with different "transport" parameters never match. Two URLs 5. URLs with different "transport" parameters never match. Two URLs
that are identical except for transport are not equivalent. that are identical except for transport are not equivalent. The
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, since the relevant parts are limited normalization is not required due to character restrictions in the
to unreserved characters. formal syntax.
6.2 Resolving MSRP Host Device 6.2 Resolving MSRP Host Device
An MSRP host device is identified by the server part of an MSRP URL. An MSRP host device is identified by the server part of an MSRP URL.
If the server part contains a numeric IP address and port, they MUST If the server part contains a numeric IP address and port, they MUST
be used as listed. be used as listed.
If the server part contains a host name and a port, the connecting If the server part contains a host name and a port, the connecting
device MUST determine a host address by doing an A or AAAA DNS query, device MUST determine a host address by doing an A or AAAA DNS query,
skipping to change at page 15, line 12 skipping to change at page 15, line 33
multiple URLs are present in the To-Path, the leftmost is the first multiple URLs are present in the To-Path, the leftmost is the first
URL visited; the rightmost URL is the last URL visited. The URL visited; the rightmost URL is the last URL visited. The
processing then becomes method specific. Additional method-specific processing then becomes method specific. Additional method-specific
headers are added as described in the following sections. headers are added as described in the following sections.
After any method-specific headers are added, processing continues to After any method-specific headers are added, processing continues to
handle a body, if present. A body in a Non-SEND request MUST NOT be handle a body, if present. A body in a Non-SEND request MUST NOT be
longer than 2048 octets. If the request has a body, it must contain longer than 2048 octets. If the request has a body, it must contain
a Content-Type header field. It may contain other MIME specific a Content-Type header field. It may contain other MIME specific
headers. The Content-Type header MUST be the last header line. The headers. The Content-Type header MUST be the last header line. The
body MUST be separated from the headers with an extra CRLF. body MUST be separated from the headers with an extra CRLF. Note
that, if no body is present, no blank line will be present between
the headers and the boundary marker below.
The boundary marker that terminates the body MUST be preceded by a The boundary marker that terminates the body MUST be preceded by a
CRLF that is not part of the body and then seven "-" (minus sign) CRLF that is not part of the body and then seven "-" (minus sign)
characters. After the boundary marker, there MUST be a flag characters. After the boundary marker, there MUST be a flag
character. If the chunk represents the data that forms the end of character. If the chunk represents the data that forms the end of
the complete message, the flag value MUST be a "$". If sender is the complete message, the flag value MUST be a "$". If sender is
abandoning an incomplete message, and intends to send no further abandoning an incomplete message, and intends to send no further
chunks in that message, it MUST be a "#". Otherwise it MUST be a chunks in that message, it MUST be a "#". Otherwise it MUST be a
"+". "+".
If the request contains a body, the sender MUST ensure that the If the request contains a body, the sender MUST ensure that the
closing sequence (a CRLF, seven hyphens, and the transaction closing sequence (a CRLF, seven hyphens, and the transaction
identifier) is not present in the body. If the closing sequence is identifier) is not present in the body. If the closing sequence is
present in the body, the sender MUST choose a new transaction present in the body, the sender MUST choose a new transaction
identifier that is not present in the body, and add the closing identifier that is not present in the body, and add the closing
sequence, including the "$", "#", or "+" character, and a final CRLF. sequence, including the "$", "#", or "+" character, and a final CRLF.
Some implementations may choose to implement this such that if they
find the closing sequence in the body of the message they are
sending, simply interrupting the message at that point and starting a
new transaction with a different transaction identifier to carry the
rest of the body. Other implementation may choose to scan the data
an ensure that the body does not contain the transaction identifier
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. Bodiless requests MUST header or any other MIME specific header. Requests without bodies
contain a closing sequence after the final header. MUST contain a closing sequence after the final header.
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 Delivering SEND requests 7.1.1 Delivering 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 unique within the scope of the unique Message-ID. This ID MUST be unique within the scope of the
session. If necessary, it breaks the message into chunks. It then session. If necessary, it breaks the message into chunks. It then
generates a SEND request for each chunk, following the procedures for generates a SEND request for each chunk, following the procedures for
constructing requests (Section 7.1). constructing requests (Section 7.1).
Each chunk MUST contain a Message-ID header field containing the Each chunk MUST contain a Message-ID header field containing the
Message-ID. If the sender wishes non-default status reporting, it Message-ID. If the sender wishes non-default status reporting, it
MUST insert a Report-Failure and/or Report-Success header field with MUST insert a Failure-Report and/or Success-Report header field with
an appropriate value. All chunks of the same message MUST use the an appropriate value. All chunks of the same message MUST use the
same Report-Failure and Report-Success values in their SEND requests. same Failure-Report and Success-Report values in their SEND requests.
If success reports are requested, i.e. the value of the If success reports are requested, i.e. the value of the
Report-Success header is "yes", the sending device MAY wish to run a Success-Report header is "yes", the sending device MAY wish to run a
timer of some value that makes sense for its application and take timer of some value that makes sense for its application and take
action if a success Report is not received in this time. There is no action if a success Report is not received in this time. There is no
universal value for this timer. For many IM applications, it may be universal value for this timer. For many IM applications, it may be
2 minutes while for some trading systems it may be under a second. 2 minutes while for some trading systems it may be under a second.
Regardless of whether such a timer is used, if the success report has Regardless of whether such a timer is used, if the success report has
not been received by the time the session is ended, the device SHOULD not been received by the time the session is ended, the device SHOULD
inform the user. inform the user.
If the value of "Report-Failure" 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, the element MUST inform the user that the transaction is sent, the element MUST inform the user that the
request probably failed. If the value is set to "partial", then the request probably failed. If the value is set to "partial", then the
element sending the transaction does not have to run a timer, but element sending the transaction does not have to run a timer, but
MUST inform the user if receives a non-recoverable error response to MUST inform the user if receives a non-recoverable error response to
the transaction. the transaction.
If no Report-Success header is present in a SEND request, it MUST be If no Success-Report header is present in a SEND request, it MUST be
treated the same as a Report-Success header with value of "no". If treated the same as a Success-Report header with value of "no". If
no Report-Failure header is present, it MUST be treated the same as a no Failure-Report header is present, it MUST be treated the same as a
Report-Failure header with value of "yes". REPORT requests MUST have Failure-Report header with value of "yes". REPORT requests MUST have
the same Message-ID header value as the request they are reporting the same Message-ID header value as the request they are reporting
on. They MAY also have the Byte-Range of the chunk they are on. They MAY also have the Byte-Range of the chunk they are
reporting on. If an MSRP element receives a REPORT for a Message-ID reporting on. If an MSRP endpoint receives a REPORT for a Message-ID
it does not recognize, it SHOULD silently ignore the REPORT. it does not recognize, it SHOULD silently ignore the REPORT.
Report-Success and Report-Failure MUST NOT be present for any method Success-Report and Failure-Report MUST NOT be present for any method
other than SEND. MSRP nodes MUST NOT send REPORT requests in other than SEND. MSRP nodes MUST NOT send REPORT requests in
response to report requests. MSRP Nodes MUST NOT send MSRP responses response to report requests. MSRP Nodes MUST NOT send MSRP responses
to REPORT requests. to REPORT requests.
The Byte-Range header value contains a starting value (range-start) The Byte-Range header value contains a starting value (range-start)
followed by a "-", an ending value (range-end) followed by a "/", and followed by a "-", an ending value (range-end) followed by a "/", and
finally the total length. The first byte in the message is indicated finally the total length. The first octet in the message has a
by a one, rather than a zero. 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 (that is, a value of one). The range-end field SHOULD message (for the first chunk this field will have a value of one).
indicate the position of the last byte in the body, if known. It The range-end field SHOULD indicate the position of the last byte in
MUST take the value of "*" if the position is unknown, or if the the body, if known. It MUST take the value of "*" if the position is
request needs to be interruptible. The total field SHOULD contain unknown, or if the request needs to be interruptible. The total
the total size of the message, if known. The total field MAY contain field SHOULD contain the total size of the message, if known. The
a "*" if the total size of the message is not known in advance. The total field MAY contain a "*" if the total size of the message is not
sender MUST send all chunks in Byte-Range order. (However, the known in advance. The sender MUST send all chunks in Byte-Range
receiver cannot assume the requests will be delivered in order, as order. (However, the receiver cannot assume the requests will be
intervening relays may have changed the order.) delivered in order, as intervening relays may have changed the
order.)
To insure fairness over a connection, senders MUST NOT send chunks To ensure fairness over a connection, senders MUST NOT send chunks
with a body larger than 2048 octets unless they are prepared to with a body larger than 2048 octets unless they are prepared to
interrupt them (meaning that any chunk with a body of greater than interrupt them (meaning that any chunk with a body of greater than
2048 octets will have a "*" character in the range-end field). A 2048 octets will have a "*" character in the range-end field). A
sender can use one of the following two strategies to satisfy this sender can use one of the following two strategies to satisfy this
requirement. The sender is STRONGLY RECOMMENDED to send messages requirement. The sender is STRONGLY RECOMMENDED to send messages
larger than 2048 octets using as few chunks as possible, interrupting larger than 2048 octets using as few chunks as possible, interrupting
chunks (at least 2048 octets long) when other traffic is waiting to chunks (at least 2048 octets long) only when other traffic is waiting
use the same connection. Alternatively, the sender MAY simply send to use the same connection. Alternatively, the sender MAY simply
chunks in 2048 octet increments until the final chunk. Note that the send chunks in 2048 octet increments until the final chunk. Note
former strategy results in markedly more efficient use of the that the former strategy results in markedly more efficient use of
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 0 octets to the maximum number of octets they can receive size from zero octets to the maximum number of octets they can
for a complete message. Senders SHOULD NOT break messages into receive for a complete message. Senders SHOULD NOT break messages
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 has already been written to the connection, then writing out the
boundary string to end the chunk. It can then be resumed in a boundary string to end the chunk. It can then be resumed in a
another chunk with the same Message-ID and a Byte-Range header range another chunk with the same Message-ID and a Byte-Range header range
start field containing the position of the first byte after the start field containing the position of the first byte after the
interruption occurred. interruption occurred.
SEND requests larger than 2k MUST be interrupted to send pending SEND requests larger than 2048 octets MUST be interrupted to send
response or REPORT requests. If multiple SEND requests from pending responses or REPORT requests. If multiple SEND requests from
different sessions are concurrently being sent over the same different sessions are concurrently being sent over the same
connection, the device SHOULD implement some scheme to alternate connection, the device SHOULD implement some scheme to alternate
between them such that each concurrent request gets a chance to send between them such that each concurrent request gets a chance to send
some fair portion of data at regular intervals suitable to the some fair portion of data at regular intervals suitable to the
application. 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 body 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 MUST be "binary". Since MSRP is a binary protocol, transfer encoding is always
"binary", and transfer-encoding paramaters 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 Report-Success or Report-Failure 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 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
body is informational only, and the sender of the REPORT request body is informational only, and the sender of the REPORT request
SHOULD NOT assume that the recipient pays any attention to the body. SHOULD NOT assume that the recipient pays any attention to the body.
Since REPORT requests are not interruptible, the size of such a body 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 Report-Success 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 containing
the URL identifying itself in the session. The endpoint then inserts the URL identifying itself in the session. The endpoint then inserts
a Status header field with a namespace of "000", a short-status of a Status header field with a namespace of "000", a short-status of
"200" and a relevant Reason phrase, and a Message-ID header field "200" and a relevant Reason phrase, and a Message-ID header field
containing the value from the original request. containing the value from the original request.
The namespace field denotes the context the short-status field.
The namespace value of "000" means the short-status should be
interpreted in the same way as the matching MSRP transaction
response code. If a future specification uses the short-status
field for some other purpose, it MUST define a new namespace field
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 Report-Success 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 Report-Success 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 Failure REPORT Generation
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 Report-Failure header either was not present for some reason, and the Failure-Report header either was not present
in the original request, or had a value of "yes", it SHOULD simply in the original request, or had a value of "yes", it SHOULD simply
include the appropriate error code in the transaction response. include the appropriate error code in the transaction response.
However, there may be situations where the error cannot be determined However, there may be situations where the error cannot be determined
quickly, such as when the endpoint is a gateway that must wait for a quickly, such as when the endpoint is a gateway that must wait for a
downstream network to indicate an error. In this situation, it MAY downstream network to indicate an error. In this situation, it MAY
send a 200 OK response to the request, and then send a failure REPORT send a 200 OK response to the request, and then send a failure REPORT
request when the error is detected. request when the error is detected.
If the endpoint receives a SEND request with a Report-Failure 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 transaction response to the request, but SHOULD it MUST NOT send a 200 transaction response to the request, but
send an appropriate non-200 class responsea failure occurs. SHOULD send an appropriate non-200 class response if a failure
occurs.
As stated above, if no Report-Failure header is present, it MUST be As stated above, if no Failure-Report header is present, it MUST be
treated the same as a Report-Failure header with value of "yes". treated the same as a Failure-Report header 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 reports, except the Status header code and reason fields MUST
contain appropriate error codes. Any error response code defined in contain appropriate error codes. Any error response code defined in
this specification MAY also be used in failure reports. 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 is sent in response to a SEND request that
contained a chunk, it MUST include a Byte-Range header indicating the contained a chunk, it MUST include a Byte-Range header indicating the
actual range being reported on. It can take the range-start and actual range being reported on. It can take the range-start and
total values from the original SEND request, but MUST calculate the total values from the original SEND request, but MUST calculate the
skipping to change at page 19, line 38 skipping to change at page 20, line 29
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. 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
Report-Failure header value of "yes", or does not contain a Failure-Report header value of "yes", or does not contain a
Report-Failure header field at all, it MUST immediately generate a Failure-Report header field at all, it MUST immediately generate a
response. Likewise, if an MSRP endpoint receives a request that response. Likewise, if an MSRP endpoint receives a request that
contains a Report-Failure header value of "partial", and the receiver contains a Failure-Report header value of "partial", and the receiver
is unable to process the request, it SHOULD immediately generate a is unable to process the request, it SHOULD immediately generate a
response. 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) URI 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 contains the full path back
to the original sender. This full path is generated by taking the to the original sender. This full path is generated by taking the
list of URLs from the From-Path of the original request, reversing list of URLs from the From-Path of the original request, reversing
the list, and writing the reversed list into the To-Path of the the list, and writing the reversed list into the To-Path of the
response. (Legal REPORT requests do not request responses, so this response. (Legal REPORT requests do not request responses, so this
specification doesn't exercise the behavior described above, however specification doesn't exercise the behavior described above, however
we expect that extensions for gateways and relays will need such we expect that extensions for gateways and relays will need such
behavior.) behavior.)
skipping to change at page 20, line 27 skipping to change at page 21, line 18
closing sequence after the last header field. The response MUST be closing sequence 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, and connection on which the request arrived. If this is not true then
the request contained a Report-Failure header value of "no" or the receiver MUST generate an 481 error and ignore the request. Note
"partial", then the receiver SHOULD quietly ignore the request. If that if the Failure-Report header had a value of "no", then no error
the Report-Failure header is not present, or had a value of "yes", report would be sent.
then the receiver MUST return a 481 response.
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, or
contains one with a range-start value of "1", and the closing line 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
skipping to change at page 21, line 7 skipping to change at page 21, line 45
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 nothing
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 "*" in the last-byte position. a request that had anything other "*" in the last-byte position of
But having the receiver calculate a chunk length based on actual the Byte-Range header. But having the receiver calculate a chunk
content adds resilience in the face of sender erros. errors. length based on actual content adds resilience in the face of
Since this should never happen with compliant senders, this only sender errors. Since this should never happen with compliant
has a SHOULD strength. 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 chunks 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 takes precedence (even though this message, the last chunk received takes precedence (even though this
may not have been the last chunk transmitted). For example, if bytes may not have been the last chunk transmitted). For example, if bytes
1 to 100 was received and a chunk arrives that contains bytes 50 to 1 to 100 was received and a chunk arrives that contains bytes 50 to
150, this second chunk will overwrite bytes 50 to 100 of the data 150, this second chunk will overwrite bytes 50 to 100 of the data
that had already been received. Although other schemes work, this is that had already been received. Although other schemes work, this is
the easiest for the receiver and results in consistent behavior the easiest for the receiver and results in consistent behavior
between clients. between clients.
The seven "-" before the boundary are used so that the receiver can The seven "-" before the boundary are used so that the receiver can
skipping to change at page 21, line 40 skipping to change at page 22, line 30
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 headers of
the request, but also allows for the interruption of messages. 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, the receiver SHOULD send a 415 response or an unsupported MIME type, the receiver MUST generate a failure report
failure report, as appropriate for the Report-Failure header field with a 415 error code. Note that this failure report will not be
value. All MSRP endpoints MUST be able to receive the sent if the Report-Failure header contains a value of "no". All MSRP
multipart/mixed and multipart/alternative MIME types. endpoints MUST be able to receive the multipart/mixed and
multipart/alternative MIME types.
If the Report-Success header was set to "yes", then when a complete If the Success-Report header was set to "yes", then when a complete
message has been received, the receiver MUST send a sucess REPORT message has been received, the receiver MUST send a success REPORT
with a byte range covering the whole message. If the Report-Success with a byte range covering the whole message. If the Success-Report
header is not set to "no", then the receiver MAY generate incremental header is not set to "no", then the receiver MAY generate incremental
success REPORTs as the chunks are recieved. These can be sent success REPORTs as the chunks are received. These can be sent
periodically and cover all the bytes that have been received so far periodically and cover all the bytes that have been received so far
or they can be sent after a chunk arrives and cover just the part or they can be sent after a chunk arrives and cover just the part
from that chunk. from that chunk.
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", it SHOULD interpret the report in with a namespace field of "000", MUST interpret the report in exactly
exactly the same way it would interpret an MSRP transaction response the same way it would interpret an MSRP transaction response with a
with a response code matching the short-code field. 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 case
the entire message corresponding to that chunk should be aborted, by the entire message corresponding to that chunk should be aborted, by
including the "#" character in the continuation field of the closing. including the "#" character in the continuation field of the closing
sequence.
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 a device that sent a SEND request receives a failure REPORT When a device 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
skipping to change at page 23, line 5 skipping to change at page 23, line 44
8.1 SDP Offer-Answer Exchanges for MSRP Sessions 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.
The general format of an SDP media-line is: An MSRP media-line in the session description is always accompanied
by a mandatory "path" attribute. This attribute contains a space
m=<media> <port> <protocol> <format list> separated list of URLs that must be visited to contact the user agent
advertising this session-description. If more than one URL is
An offered or accepted MSRP media-line MUST have the following value present, the leftmost URL is the first URL that must be visited to
exactly, with the exception that the port field MAY be set to any reach the target resource. (The path list can contain multiple URLs
value. (The port value will be ignored, unless it is zero. to allow for the deployment of gateways or relays in the future.)
According to [3], a user agent that wishes to accept an offer, but MSRP implementations which can accept incoming connections will
not a specific media-line MUST set the port number of that media-line typically only provide a single URL here.
to zero (0) in the response.)
m=message 9 msrp *
While MSRP could theoretically carry any media type, "message" is
appropriate. For MSRP, the port number is always ignored--the
actual port number is provided in an MSRP URL. Instead a dummy
value is used, which is not meaningful if non-zero. The protocol
is always "msrp", and the value of the format list is always a
single asterisk character ("*").
An MSRP media-line is always accompanied by a mandatory "path"
attribute. This attribute contains a space separated list of URLs
that must be visited to contact the user agent advertising this
session-description. If more than one URL is present, the leftmost
URL is the first URL that must be visited to reach the target
resource. (The path list can contain multiple URLs to allow for the
deployment of gateways or relays in the future.) MSRP
implementations which can accept incoming connections will typically
only provide a single URL here.
MSRP media lines MUST also be accompanied by an "accept-types" An MSRP medialine MUST also be accompanied by an "accept-types"
attribute. This attribute contains a list of MIME types which are attribute. This attribute contains a list of MIME types which are
acceptable to the endpoint. acceptable to the endpoint.
A "*" entry in the accept-types attribute indicates that the sender A "*" entry in the accept-types attribute indicates that the sender
may attempt to send content with media types that have not been may attempt to send content with media types that have not been
explicitly listed. Likewise, an entry with an explicit type and a explicitly listed. Likewise, an entry with an explicit type and a
"*" character as the subtype indicates that the sender may attempt to "*" character as the subtype indicates that the sender may attempt to
send content with any subtype of that type. If the receiver receives 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. 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 If not, it will respond with a 415 response. Note that all explicit
skipping to change at page 24, line 38 skipping to change at page 25, line 8
themselves. themselves.
The approach of specifying types that are only allowed inside of The approach of specifying types that are only allowed inside of
containers separately from the primary payload types allows an containers separately from the primary payload types allows an
endpoint to force the use of certain wrappers. For example, a endpoint to force the use of certain wrappers. For example, a
CPIM [12] gateway device may require all messages to be wrapped CPIM [12] gateway device may require all messages to be wrapped
inside message/cpim bodies, but may allow several content types inside message/cpim bodies, but may allow several content types
inside the wrapper. If the gateway were to specify the wrapped inside the wrapper. If the gateway were to specify the wrapped
types in the accept-types attribute, its peer might attempt to use types in the accept-types attribute, its peer might attempt to use
those types without the wrapper. 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 If the recipient of an offer does not understand any of the payload
that using the appropriate mechanism of the rendezvous protocol. types indicated in the offered SDP, it SHOULD indicate that using the
For example, in SIP, it SHOULD return a SIP 488 response. 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 An endpoint MAY indicate the maximum size message they wish to
receive using the max-size a-line attribute. Max-size refers to receive using the max-size a-line attribute. Max-size refers to the
the complete message in octets, not the size of any one chunk. complete message in octets, not the size of any one chunk. Senders
Senders SHOULD NOT exceed the max-size limit for any message sent SHOULD NOT exceed the max-size limit for any message sent in the
in the resulting session. However, the receiver should consider resulting session. However, the receiver should consider max-size
max-size value as a hint. value as a hint.
The formal syntax for these attributes are as follows:
accept-types = accept-types-label ":" format-list accept-types = accept-types-label ":" format-list
accept-types-label = "accept-types" accept-types-label = "accept-types"
accept-wrapped-types = wrapped-types-label ":" format-list accept-wrapped-types = wrapped-types-label ":" format-list
wrapped-types-label = "accept-wrapped-types" wrapped-types-label = "accept-wrapped-types"
format-list = format-entry *( SP format-entry) format-list = format-entry *( SP format-entry)
format-entry = (type "/" subtype) / (type "/" "*") / ("*") format-entry = (type "/" subtype) / (type "/" "*") / ("*")
type = token type = token
subtype = token subtype = token
max-size = max-size-label ":" max-size-value max-size = max-size-label ":" max-size-value
max-size-label = "max-size" max-size-label = "max-size"
max-size-value = 1*(DIGIT) ;max size in octets max-size-value = 1*(DIGIT) ;max size in octets
Note: RFC2327 does not allow the hyphen in att-field, which is
defined as alphanumeric. However, this is expected to be allowed
in an update to that specification, which should be available
shortly.
8.1.1 URL Negotiations 8.1.1 URL Negotiations
Each endpoint in an MSRP session is identified by a URL. These URLs Each endpoint in an MSRP session is identified by a URL. These URLs
are negotiated in the SDP exchange. Each SDP offer or answer MUST are negotiated in the SDP exchange. Each SDP offer or answer MUST
contain one or more MSRP URL in a path attribute. This attribute has contain one or more MSRP URL in a path attribute. This attribute has
the following syntax: the following syntax:
"a=path:" MSRP_URL *(SP MSRP_URL) "a=path:" MSRP-URL *(SP MSRP-URL)
where MSRP_URL is an msrp: or msrps: URL as defined in Section 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 send 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://a.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 9 msrp * m=message 7394 msrp/tcp *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrp://a.example.com:7394/2s93i;tcp a=path:msrp://alice.example.com:7394/2s93i;tcp
The rightmost URI 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 URI 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.1.2 Path Attributes with Multiple URLs
As mentioned previously, this document describes MSRP for As mentioned previously, this document describes MSRP for
peer-to-peer scenarios, that is, when no relays are used. However, peer-to-peer scenarios, that is, when no relays are used. However,
we expect a separate document to describe the use of relays. In we expect a separate document to describe the use of relays. In
order to allow an MSRP device that only implements the core order to allow an MSRP device that only implements the core
specification to interoperate with devices that use relays, this specification to interoperate with devices that use relays, this
skipping to change at page 27, line 8 skipping to change at page 27, line 24
endpoint receives more than one URL in a path header, only the first endpoint receives more than one URL in a path header, only the first
entry is relevant for purposes of resolving the address and port, and entry is relevant for purposes of resolving the address and port, and
establishing the network connection, as it describes the first establishing the network connection, as it describes the first
adjacent hop. 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 Updated SDP Offers 8.1.3 SDP Connection and Media Lines
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 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 "msrp/tcp". 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.4 Example SDP Exchange 8.1.5 Example SDP Exchange
Endpoint A wishes to invite Endpoint B to a MSRP session. A offers Endpoint A wishes to invite Endpoint B to a MSRP session. A offers
the following session description: the following session description:
v=0 v=0
o=usera 2890844526 2890844527 IN IP4 alice.example.com o=usera 2890844526 2890844527 IN IP4 alice.example.com
s= s=
c=IN IP4 alice.example.com c=IN IP4 alice.example.com
t=0 0 t=0 0
m=message 9 msrp * m=message 7394 msrp/tcp *
a=accept-types: message/cpim text/plain text/html a=accept-types: message/cpim text/plain text/html
a=path:msrp://alice.example.com:7394/2s93i9;tcp a=path:msrp://alice.example.com:7394/2s93i9;tcp
B responds with its own URL: B responds with its own URL:
v=0 v=0
o=userb 2890844530 2890844532 IN IP4 bob.example.com o=userb 2890844530 2890844532 IN IP4 bob.example.com
s= s=
c=IN IP4 bob.example.com c=IN IP4 bob.example.com
t=0 0 t=0 0
m=message 9 msrp * m=message 8493 msrp/tcp *
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.5 Connection Negotiation 8.1.6 Connection Negotiation
Previous versions of this document included a mechanism to negotiate Previous versions of this document included a mechanism to negotiate
the direction for any required TCP connection. The mechanism was the direction for any required TCP connection. The mechanism was
loosely based on the COMEDIA [23] work being done in the MMUSIC loosely based on the COMEDIA [23] work being done in the MMUSIC
working group. The primary motivation was to allow MSRP sessions to working group. The primary motivation was to allow MSRP sessions to
succeed in situations where the offerer could not accept connections succeed in situations where the offerer could not accept connections
but the answerer could. For example, the offerer might be behind a but the answerer could. For example, the offerer might be behind a
NAT, while the answerer might have a globally routable address. NAT, while the answerer might have a globally routable address.
The SIMPLE working group chose to remove that mechanism from MSRP, as The SIMPLE working group chose to remove that mechanism from MSRP, as
it added a great deal of complexity to connection management. it added a great deal of complexity to connection management.
Instead, MSRP now specifies a default connection direction. Instead, MSRP now specifies a default connection direction. Namely,
the party that sent the original offer
8.2 MSRP User Experience with SIP 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
skipping to change at page 29, line 21 skipping to change at page 30, line 31
pMSRP = %x4D.53.52.50 ; MSRP in caps pMSRP = %x4D.53.52.50 ; MSRP in caps
transact-id = ident transact-id = ident
method = mSEND / mREPORT / other-method method = mSEND / mREPORT / other-method
mSEND = %x53.45.4e.44 ; SEND in caps mSEND = %x53.45.4e.44 ; SEND in caps
mREPORT = %x52.45.50.4f.52.54; REPORT in caps mREPORT = %x52.45.50.4f.52.54; REPORT in caps
other-method = 1*UPALPHA other-method = 1*UPALPHA
status-code = 3DIGIT ; any code defined in this document status-code = 3DIGIT ; any code defined in this document
; or an extension document ; or an extension document
MSRP_url = msrp-scheme "://" [userinfo "@"] hostport MSRP-URL = msrp-scheme "://" [userinfo "@"] hostport
["/" session-id] ";" transport ["/" session-id] ";" transport
; userinfo as defined in RFC2396, except ; userinfo as defined in RFC2396, except
; limited to unreserved. ; limited to unreserved.
; hostport as defined in RFC3261 ; hostport as defined in RFC3261
; [Todo: update with RFC number for 2396bis] ; [Todo: update with RFC number for 2396bis]
msrp-scheme = "msrp" / "msrps" msrp-scheme = "msrp" / "msrps"
session-id = 1*unreserved ; unreserved as defined in RFC2396 session-id = 1*( unreserved / "+" / "=" / "/" )
; unreserved as defined in RFC2396
transport = "tcp" / ALPHANUM transport = "tcp" / ALPHANUM
headers = To-Path CRLF From-Path CRLF 1*( header CRLF ) headers = To-Path CRLF From-Path CRLF 1*( header CRLF )
header = Message-ID header = Message-ID
/ Report-Success / Success-Report
/ Report-Failure / Failure-Report
/ Byte-Range / Byte-Range
/ Status / Status
/ ext-header / ext-header
To-Path = "To-Path:" SP MSRP-URL *( SP MSRP-URL )
To-Path = "To-Path:" SP MSRP-url *( SP URL ) From-Path = "From-Path:" SP MSRP-URL *( SP MSRP-URL )
From-Path = "From-Path:" SP MSRP-url *( SP URL )
Message-ID = "Message-ID:" SP ident Message-ID = "Message-ID:" SP ident
Report-Success = "Report-Success:" SP ("yes" / "no" ) Success-Report = "Success-Report:" SP ("yes" / "no" )
Report-Failure = "Report-Failure:" 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 = "000" namespace = "000"
text-reason = *(VCHAR / WSP) ; All visible charcters / SP / HTAB text-reason = utf8text
; (defined in RFC2234 CORE)
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
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E
/ %x30-39 / %x41-5A / %x5E-7E) / %x30-39 / %x41-5A / %x5E-7E)
; 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
skipping to change at page 31, line 33 skipping to change at page 32, line 42
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. A 400 response indicates a request was unintelligible.
10.3 403 10.3 403
The action is not allowed The action is not allowed.
10.4 415 10.4 408
A 408 response indicates that a downstream transaction did not
complete in the alloted time. It is never sent by any elements
described in this specification. However, 408 is used in the MSRP
Relay extension; therefore MSRP endpoints may receive it. An
endpoint MUST treat a 408 response in the same manner as it would
treat a local timeout.
10.5 413
A 413 response indicates that the receiver wishes the sender to stop
sending the particular message. Typically, a 413 is sent in response
to a chunk of an undesired message.
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,
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
chunk is interruptible, the sender MUST abort sending the chunk.
10.6 415
A 415 response indicates the SEND request contained a MIME A 415 response indicates the SEND request contained a MIME
content-type that is not understood by the receiver. content-type that is not understood by the receiver.
10.5 426 10.7 423
A 423 response indicates that one of the requested parameters is out
of bounds. It is used by the relay extensions to this document.
10.8 426
A 426 response indicates that the request is only allowed over TLS A 426 response indicates that the request is only allowed over TLS
protected connections. protected connections.
10.6 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.
10.7 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.8 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. already bound to another network 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
skipping to change at page 33, line 14 skipping to change at page 34, line 50
1. Alice constructs a local URL of 1. Alice constructs a local URL of
msrp://alicepc.example.com:7777/iau39;tcp . msrp://alicepc.example.com:7777/iau39;tcp .
Alice->Bob (SIP): INVITE sip:bob@example.com Alice->Bob (SIP): INVITE sip:bob@example.com
v=0 v=0
o=alice 2890844557 2890844559 IN IP4 alicepc.example.com o=alice 2890844557 2890844559 IN IP4 alicepc.example.com
s= s=
c=IN IP4 alicepc.example.com c=IN IP4 alicepc.example.com
t=0 0 t=0 0
m=message 9 msrp * m=message 7777 msrp/tcp *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrp://alicepc.example.com:7777/iau39;tcp a=path:msrp://alicepc.example.com:7777/iau39;tcp
2. Bob listens on port 8888, and sends the following response: 2. Bob listens on port 8888, and sends the following response:
Bob->Alice (SIP): 200 OK Bob->Alice (SIP): 200 OK
v=0 v=0
o=bob 2890844612 2890844616 IN IP4 bob.example.com o=bob 2890844612 2890844616 IN IP4 bob.example.com
s= s=
c=IN IP4 bob.example.com c=IN IP4 bob.example.com
t=0 0 t=0 0
m=message 9 msrp * m=message 8888 msrp/tcp *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrp://bob.example.com:8888/9di4ea;tcp a=path:msrp://bob.example.com:8888/9di4ea;tcp
3. Alice->Bob (SIP): ACK 3. Alice->Bob (SIP): ACK
4. (Alice opens connection to Bob.) Alice->Bob (MSRP): 4. (Alice opens connection to Bob.) Alice->Bob (MSRP):
MSRP d93kswow SEND MSRP d93kswow SEND
To-Path:msrp://bob.example.com:8888/9di4ea;tcp To-Path:msrp://bob.example.com:8888/9di4ea;tcp
From-Path:msrp://alicepc.example.com:7777/iau39;tcp From-Path:msrp://alicepc.example.com:7777/iau39;tcp
skipping to change at page 35, line 17 skipping to change at page 37, line 4
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
Report-Failure: no Failure-Report: no
Report-Success: 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
skipping to change at page 36, line 13 skipping to change at page 37, line 19
-------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
Report-Success: yes Success-Report: yes
Content-Type:text/html Content-Type:text/html
<html><body> <html><body>
<p>Here is that important link... <p>Here is that important link...
<a href="www.example.com/foobar">foobar</a> <a href="www.example.com/foobar">foobar</a>
</p> </p>
</body></html> </body></html>
-------d93kswow$ -------d93kswow$
Bob->Alice (MSRP): Bob->Alice (MSRP):
skipping to change at page 39, line 14 skipping to change at page 40, line 19
| |--INVITE---------------------------------------->| | |--INVITE---------------------------------------->|
| |<---200 OK---------------------------------------| | |<---200 OK---------------------------------------|
|<--200 OK---| | | | | |<--200 OK---| | | | |
|---ACK------------------------------------------------------->| |---ACK------------------------------------------------------->|
|<================MSRP Session================================>| |<================MSRP Session================================>|
| | | | | | | | | | | |
| Hi Romeo, Juliet is | | Hi Romeo, Juliet is |
| with her father now | | with her father now |
| can i take a message?| | can i take a message?|
| | | |
| Tell her to go to confession tommorrow.... | | 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. Headers, and status codes can be defined in standards track RFCs.
There is no registry of headers, methods, or status codes, since the There is no registry of headers, methods, or status codes, since the
number of new elements and total extensions is expected to be very number of new elements and total extensions is expected to be very
small. MSRP does not contain a version number or any negotiation small. MSRP does not contain a version number or any negotiation
mechanism to require or discover new features. If a mechanism to require or discover new features. If a
non-interoperable update or extension occurs in the future, it will non-interoperable update or extension occurs in the future, it will
skipping to change at page 39, line 45 skipping to change at page 41, line 4
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 headers in anticipation of relay or gateway
functionality being added. In addition, msrp: and msrps: URLs can functionality being added. In addition, msrp: and msrps: URLs can
contain parameters which are extensible. contain parameters which are extensible.
13. CPIM compatibility 13. CPIM compatibility
MSRP sessions may go to a gateway to other CPIM [24] compatible MSRP sessions may go to a gateway to other CPIM [24] compatible
protocols. If this occurs, the gateway MUST maintain session state, protocols. If this occurs, the gateway MUST maintain session state,
and MUST translate between the MSRP session semantics and CPIM and MUST translate between the MSRP session semantics and CPIM
semantics that do not include a concept of sessions. Furthermore, semantics, 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 attribute SHOULD encapsulate all instant message bodies in
"message/cpim" wrappers. All MSRP endpoints MUST support the "message/cpim" wrappers. All MSRP endpoints MUST support the
message/cpim type, and SHOULD support the S/MIME features of that message/cpim type, and SHOULD support the S/MIME features of that
format. 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 headers as defined in RFC3862. Such applications SHOULD recognize
the CC header, and MAY recognize the Subject header. Any MSRP the CC header, and MAY recognize the Subject header. Any MSRP
application that recognizes any message/cpim header MUST understand application that recognizes any message/cpim header MUST understand
the NS (name space) header. the NS (name space) header.
All message/cpim body parts send 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 headers. If the message/cpim body part is protected
using S/MIME, then it MUST also include the DateTime header. using S/MIME, then it MUST also include the DateTime header.
The NS, To, and CC headers may occur multiple times. Other headers The NS, To, and CC headers may occur multiple times. Other headers
defined in RFC3862 MUST NOT occur more than once in a given defined in RFC3862 MUST NOT occur more than once in a given
message/cpim body part in an MSRP message. The Require header MAY message/cpim body part in an MSRP message. The Require header MAY
include multiple values. The NS header MAY occur zero or more times, include multiple values. The NS header MAY occur zero or more times,
depending on how many name spaces are being referenced. depending on how many name spaces are being referenced.
Extension headers MAY occur more than once, depending on the Extension headers MAY occur more than once, depending on the
definition of such headers. definition of such headers.
Using message/cpim envelopes are also useful if an MSRP device
wishes to send a message on behalf of some other identity. The
device may add a message/cpim envelope with the appropriate From
header 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. Like many
communications systems, the properties of Integrity and communications systems, the properties of Integrity and
Confidentiality of the exchanged information, along with the Confidentiality of the exchanged information, along with the
possibility of Anonymous communications, and knowing you are possibility of Anonymous communications, and knowing you are
communicating with the correct other party are required. MSRP pushes communicating with the correct other party are required. MSRP pushes
many of the hard problems to SIP when SIP sets up the session, but many of the hard problems to SIP when SIP sets up the session, but
some of the problems remain. Spam and DoS attacks are also very some of the problems remain. Spam and DoS 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 the connected host it transfers. It also needs to provide assurances the connected host
is the host that it meant to connect to and that the connection has is the host that it meant to connect to and that the connection has
not been hijacked. not been hijacked.
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 B, B passes its hostname and a secret to A using
SIP. If the SIP offer or answer is not TLS or S/MIME [26] protected, a rendezvous protocol. Although MSRP requires the use of a
anyone can see this secret. A then connects to the provided host rendezvous protocol with the ability to protect this exchange, there
name and passes the secret in the clear across the connection to B. is no guarantee that the protection will be used all the time. If
A assumes that it is talking to B based on where it sent the SYN such protection is not used, anyone can see this secret. A then
packet and then delivers the secret in plain text across the connects to the provided host name and passes the secret in the clear
connections. B assumes it is talking to A because the host on the across the connection to B. A assumes that it is talking to B based
other end of the connection delivered the secret. An attacker that on where it sent the SYN packet and then delivers the secret in plain
could ACK the SYN packet could insert itself as a man in the middle text across the connections. B assumes it is talking to A because
in the connection. the host on the other end of the connection delivered the secret. An
attacker that could ACK the SYN packet could insert 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 know certificate authority. Furthermore, we assume that from a well know certificate authority. Furthermore, we assume that
the SIP signaling to set up the session is protected with TLS (using the signaling to set up the session is protected by the rendezvous
sips). 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 SIP confidential channel to A. A connects with TLS passed through a confidential channel to A. A connects with TLS to
to B. B presents a valid certificate, so A knows it really is B. B presents a valid certificate, so A knows it really is connected
connected to B. A then delivers the secret provided by B, so that B to B. A then delivers the secret provided by B, so that B can verify
can verify it is connected to A. In this case, a rogue SIP Proxy can it is connected to A. In this case, a rogue SIP Proxy can see the
see the secret in the SIP signaling traffic and could potentially secret in the SIP signaling traffic and could potentially insert
insert itself as a man-in-the-middle. itself as a man-in-the-middle.
Realistically, using TLS is only feasible when connecting to gateways Realistically, using TLS is difficult for peer to peer connections,
or relays , as the types of hosts that end clients use for sending as the types of hosts that end clients use for sending instant
instant messages are unlikely to have a long term stable IP address messages are unlikely to have long term stable IP addresses or DNS
or a stable DNS name that a certificate can bind to. In addition, names that certificate can bind to. In addition, the cost of server
the cost of server certificates from well known certificate certificates from well known certificate authorities is currently
authorities is currently too high for the vast majority of end users expensive enough to discourage their use for each client. While not
to even consider getting one for each client. in scope for this document, using TLS with a DH profile is possible.
The only strong security for connections without relays is achieved TLS becomes much more practical when some form of relay is
using S/MIME. This does not require the actual endpoint to have introduced. Clients can then form TLS connections to relays, which
certificates from a well known certificate authority. The Identity are much more likely to have TLS certificates. While this
[21] and Certificates [22] mechanism with SIP provides S/MIME based specification does not address such relays, they are described by a
companion document [20]. That document makes extensive use of TLS to
protect traffic between clients and relays, and between one relay and
another.
TLS is used to authenticate devices and to provide integrity and
confidentiality for the headers being transported. MSRP elements
MUST implement TLS and MUST also implement the TLS
ClientExtendedHello extended hello information for server name
indication as described in [10]. A TLS cipher-suite of
TLS_RSA_WITH_AES_128_CBC_SHA [13] MUST be supported (other
cipher-suites MAY also be supported).
14.2 S/MIME
The only strong security for non-TLS connections is achieved using
S/MIME.
Since MSRP carries arbitrary MIME content, it can trivially carry
S/MIME protected messages as well. All MSRP implementations MUST
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
context of a session could also be protected using a key-wrapped
shared secret [25] provided in the session setup. MSRP is a binary
protocol and MIME bodies MUST be transfered with a transfer encoding
of binary. If a message is both signed and encrypted, it SHOULD be
signed first, then encrypted. If S/MIME is supported, SHA-1, RSA,
and AES-128 MUST be supported.
This does not actually require the endpoint to have certificates from
a well known certificate authority. When MSRP is used with SIP, the
Identity [21] and Certificates [22] mechanism provides 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 MRSP. The MSRP session exchange keying material that can be used in MRSP. 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 this risk is mitigated if all the MSRP content is connection, but the consequences are mitigated if all the MSRP
encrypted and signed with S/MIME. It is out of scope for this content is encrypted and signed with S/MIME. It is out of scope for
document but thre is nothing stopping the SIP negoatiation of MSRP this document but there is nothing stopping the SIP negotiation of
session from negoatating symetric keying material that is used with MSRP session from negotiating symmetric keying material that is used
S/MIME for intgrity and privacy. Using TLS with a DH profile is also with S/MIME for integrity and privacy.
possible.
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 an 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 the SDP that indicates that her MSRP address is the address of
Tom. Since Alice sent the offer, Alice will initiate a connection to Tom. Since Alice sent the offer, Alice will initiate a connection to
Tom using up resources on Tom's server. Given the huge number of IM Tom using up resources on Tom's server. Given the huge number of IM
clients, and the relatively few TCP connections that most servers clients, and the relatively few TCP connections that most servers
support, this is a fairly straightforward attack. support, this is a fairly straightforward attack.
SIP is attempting to address issues in dealing with spam. The spam SIP is attempting to address issues in dealing with spam. The spam
issue is probably best dealt with at the SIP level when an MSRP issue is probably best dealt with at the SIP level when an MSRP
session is initiated and not at the MSRP level. session is initiated and not at the MSRP level.
TLS is used to authenticate devices and to provide integrity and
confidentiality for the headers being transported. MSRP elements
MUST implement TLS and MUST also implement the TLS
ClientExtendedHello extended hello information for server name
indication as described in [10]. A TLS cipher-suite of
TLS_RSA_WITH_AES_128_CBC_SHA [13] MUST be supported (other
cipher-suites MAY also be supported).
Since MSRP carries arbitrary MIME content, it can trivially carry
S/MIME protected messages as well. All MSRP implementations MUST
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
context of a session could also be protected using a key-wrapped
shared secret [25] provided in the session setup. MSRP is a binary
protocol and MIME bodies MUST be transfered with a transfer encoding
of binary. If a message is both signed and encrypted, it SHOULD be
signed first, then encrypted. If S/MIME is supported, SHA-1, RSA,
and AES-128 MUST be supported.
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 users, and S/MIME is signaling has been set up to a specific end users, 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
skipping to change at page 43, line 36 skipping to change at page 45, line 17
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
attributed to the same sender via different MSRP sessions. For attributed to the same sender via different MSRP sessions. For
example, Alice might be in a conversation with Bob via an MSRP example, Alice might be in a conversation with Bob via an MSRP
session over a TLS protected channel. Alice might then receive a session over a TLS protected channel. Alice might then receive a
different message from Bob over a different session, perhaps with a different message from Bob over a different session, perhaps with a
conference server that asserts Bob's identity in a message/cpim conference server that asserts Bob's identity in a message/cpim
envelope signed by the server. envelope signed by the server.
MSRP does not in any way prohibit multiple simultaneous sessions MSRP does not prohibit multiple simultaneous sessions between the
between the same pair of identities. Nor does it prohibit an same pair of identities. Nor does it prohibit an endpoint sending a
endpoint sending a message on behalf of another identity, such as may message on behalf of another identity, such as may be the case for a
be the case for a conference server. The recipient's endpoint should conference server. The recipient's endpoint should determine its
determine its level of trust of the authenticity of the sender level of trust of the authenticity of the sender independently for
independently for each session. The fact that an endpoint trusts the each session. The fact that an endpoint trusts the authenticity of
authenticity of the sender on any given session should not affect the the sender on any given session should not affect the level of trust
level of trust it assigns for apparently the same sender on a it assigns for apparently the same sender on a different session.
different session.
When MSRP clients from or acquire a certificate, they SHOULD ensure When MSRP clients form or acquire a certificate, they SHOULD ensure
that the subjectAltName has a GeneralName entry of type that the subjectAltName has a GeneralName entry of type
uniformResourceIdentifier for each URI corresponding to this client uniformResourceIdentifier for each URL corresponding to this client
and should always include an "im:" URI as well as a "sip:" URI. It and should always include an "im:" URI. It is fine if the
is fine if the certificate contains other URIs such as an "xmpp:" certificate contains other URIs such as an "sip:" or "xmpp:" URIs.
URI.
MSRP implementors should be aware of a potential attack on MSRP
devices that involves placing very large values in the byte-range
header field, potentially causing the device to allocate very large
memory buffers to hold the message. Implementations SHOULD apply
some degree of sanity checking on byte-range values before allocating
such buffers.
15. IANA Considerations 15. IANA Considerations
15.1 MSRP Port 15.1 MSRP Port
MSRP uses TCP port XYX, to be determined by IANA after this document MSRP uses TCP port XYX, to be determined by IANA after this document
is approved for publication. Usage of this value is described in is approved for publication. Usage of this value is described in
Section 6 Section 6
15.2 MSRP URL Schemes 15.2 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
[Note to RFC Editor: Please replace RFCXXXX in the above [Note to RFC Editor: Please replace RFCXXXX in the above
paragraph with the actual number assigned to this document. paragraph with the actual number assigned to this document.
15.3 SDP Parameters 15.3 SDP Transport Protocol
This document registers the following SDP parameters in the MSRP defines the a new SDP protocol field value "msrp/tcp", which
sdp-parameters registry: should be registered in the sdp-parameters registry under "proto".
This value indicates the MSRP protocol when TCP is used as an
underlying transport.
15.3.1 Accept Types Specifications defining new protocol values must define the rules for
the associated media format namespace. The "msrp/tcp" protocol value
allows only one value in the format field (fmt), which is a single
occurrence of "*". Actual format determination is made using the
"accept-types" and "accept-wrapped-types" attributes.
15.4 SDP Attribute Names
This document registers the following SDP attribute parameter names
in the sdp-parameters registry. These names are to be used in the
SDP att-name field.
15.4.1 Accept Types
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 See Section 8.1. Purpose and Appropriate Values: The "accept-types" attribute contains
a list of MIME content-types that the endpoint is willing to
receive. It may contain zero or more registered MIME types, or
"*" in a space delimited string.
15.3.2 Wrapped Types 15.4.2 Wrapped Types
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 See Section 8.1. Purpose and Appropriate Values: The "accept-wrapped-types" attribute
contains a list of MIME content-types that the endpoint is willing
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
or more registered MIME types, or "*" in a space delimited string.
15.3.3 Max Size 15.4.3 Max Size
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 See Section 8.1. Purpose and Appropriate Values: The "max-size" attribute indicates
the largest message an endpoint wishes to accept. It may take any
numeric value, specified in octets.
15.3.4 Path 15.4.4 Path
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 See Section 8.1.1. Purpose and Appropriate Values: The "path" attribute indicates a
series of MSRP devices that must be visited by messages sent in
the session, including the final endpoint. The attribute contains
one or more MSRP URIs, delimited by the space character.
16. Change History 16. Change History
16.1 draft-ietf-simple-message-sessions-09 16.1 draft-ietf-simple-message-sessions-10
Changed SDP m-line protocol field to "msrp/tcp". Added
requirement to copy the MSRP address and port from the path to the
c and m lines as a courtesy to legacy SDP devices. The path
attribute is still used as previousl specificed.
Changed SDP reference to point to SDP-New draft.
Relaxed the URL session-id syntax to allow (unreserved / "+" / "="
/ "/" ), to make it easier to embed base64 encoded information.
Updated example in overview to have Byte-Range header.
Added 413 response code.
Changed report-failure and report-success to failure-report and
success-report, respectively. Change made to increase parsing
efficiency.
Refined the iana registration section.
Added registration of "msrp" as an sdp proto field value in iana
section.
Moved 408 and 423 from relays document to this draft.
Expanded security considerations to include more discussion of the
difficulties of peer-to-peer TLS, and how relays can help make
that better.
16.2 draft-ietf-simple-message-sessions-09
o Updated retransmission when receiving a failure report. o Updated retransmission when receiving a failure report.
o Added applicability statement. o Added applicability statement.
o Added CPIM application considerations. o Added CPIM application considerations.
o Added language to security considerations about receiving messages o Added language to security considerations about receiving messages
from the same sender over different sessions. from the same sender over different sessions.
o Added 501 response code. o Added 501 response code.
o Various scrubbing of the ABNF o Various scrubbing of the ABNF
o Change resource construction name to session-id in MSRP syntax. o Change resource construction name to session-id in MSRP syntax.
o Added language to define the purpose of msrp URLs. o Added language to define the purpose of msrp URLs.
skipping to change at page 45, line 42 skipping to change at page 48, line 36
o Clarify that userinfo is restricted to unreserved characters, o Clarify that userinfo is restricted to unreserved characters,
which is an additional restriction over the RFC2396 version. which is an additional restriction over the RFC2396 version.
o Consolidated the ABNF for the MSRP URL into the formal syntax o Consolidated the ABNF for the MSRP URL into the formal syntax
section. section.
o Clarified that if an MSRP endpoint receives and SDP offer and does o Clarified that if an MSRP endpoint receives and SDP offer and does
not understand any of the media types, it SHOULD return a SIP 488 not understand any of the media types, it SHOULD return a SIP 488
response, or whatever is appropriate for the rendezvous protocol. response, or whatever is appropriate for the rendezvous protocol.
o Added more text around using message/cpim for identity o Added more text around using message/cpim for identity
attribution. attribution.
16.2 draft-ietf-simple-message-sessions-08 16.3 draft-ietf-simple-message-sessions-08
o Removed DSN section. Removed statements that an error report o Removed DSN section. Removed statements that an error report
SHOULD contain a body. REPORT requests may now contain SHOULD contain a body. REPORT requests may now contain
informational bodies no larger than 2K, but the recipient is free informational bodies no larger than 2K, but the recipient is free
to ignore them. to ignore them.
o Added the "#" value for the continuation-flag to indicate the last o Added the "#" value for the continuation-flag to indicate the last
chunk of an abandoned message. chunk of an abandoned message.
o Added direction that s/mime and cpim envelops must be applied o Added direction that s/mime and cpim envelops must be applied
before chunking. before chunking.
o Added direction to set the last-byte field in byte-range to "*" if o Added direction to set the last-byte field in byte-range to "*" if
there is any chance of interrupting a SEND request. there is any chance of interrupting a SEND request.
o Changed to refer to entire message, instead of a particular MIME o Changed to refer to entire message, instead of a particular MIME
content-type content-type
o Added requirent for the use of UTF-8, and reference to RFC3629 o Added requirement for the use of UTF-8, and reference to RFC3629
o Added requrement to ignore unknown headers. o Added requirement to ignore unknown headers.
o Several ABNF fixes o Several ABNF fixes
o Removed redundant material between normative sections. o Removed redundant material between normative sections.
o Numerous editorial fixes. o Numerous editorial fixes.
16.3 draft-ietf-simple-message-sessions-07 16.4 draft-ietf-simple-message-sessions-07
o Significant re-write to attempt to improve readability. o Significant re-write to attempt to improve readability.
o Added maximum size parameter in accept-types o Added maximum size parameter in accept-types
o Changed the Boundary field to be part of the start-line rather o Changed the Boundary field to be part of the start-line rather
than a header field. than a header field.
o Removed the TR-IDheader, and changed request-response matching to o Removed the TR-IDheader, and changed request-response matching to
be based on the Boundary field value. Responses still contain the be based on the Boundary field value. Responses still contain the
TR-ID header, which must match the Boundary from the request. TR-ID header, which must match the Boundary from the request.
o Removed transport selection from URL scheme and added the "tcp" o Removed transport selection from URL scheme and added the "tcp"
parameter. parameter.
skipping to change at page 46, line 41 skipping to change at page 49, line 35
a payload. a payload.
o removed SRV usage for URL resolution. This is only used for relay o removed SRV usage for URL resolution. This is only used for relay
discovery, and therefore should be moved to the relay draft. discovery, and therefore should be moved to the relay draft.
o Added discussion about late REPORT handling. Asserted that REPORT o Added discussion about late REPORT handling. Asserted that REPORT
requests are always sent in simple mode. requests are always sent in simple mode.
o Removed the dependency on multipart/byteranges for fragmentation. o Removed the dependency on multipart/byteranges for fragmentation.
Incorporated the Byte-Range header into the base MSRP header set. Incorporated the Byte-Range header into the base MSRP header set.
o Removed the VISIT method. Change to use SEND to serve the purpose o Removed the VISIT method. Change to use SEND to serve the purpose
formerly reserved to VISIT. formerly reserved to VISIT.
16.4 draft-ietf-simple-message-sessions-06 16.5 draft-ietf-simple-message-sessions-06
o Changed To and From header names to To-Path and From-Path. Added o Changed To and From header names to To-Path and From-Path. Added
more clarification to path handling, and commentary on how it more clarification to path handling, and commentary on how it
enables relay usage. enables relay usage.
o Changed mechanism for signaling transport and TLS protection into o Changed mechanism for signaling transport and TLS protection into
the MSRP URL, rather than the SDP M-Line. the MSRP URL, rather than the SDP M-Line.
o Removed length field from start line and added Boundary header o Removed length field from start line and added Boundary header
field and Closing field. field and Closing field.
o Added recommendation to fragment any content over 2k. o Added recommendation to fragment any content over 2k.
o Added Rohan's proposal to make offerer connect to answerer. (With o Added Rohan's proposal to make offerer connect to answerer. (With
open issue for more discussion.) open issue for more discussion.)
o Changed To-Path and From-Path usage in responses to indicate the o Changed To-Path and From-Path usage in responses to indicate the
destination and source of the response, rather than merely copy destination and source of the response, rather than merely copy
from the associated request. from the associated request.
o Updated DSN section. Added text on field usage. o Updated DSN section. Added text on field usage.
o Fixed change TR-ID header from version 05 were erroneously o Fixed change TR-ID header from version 05 were erroneously
attributed to 04. attributed to 04.
16.5 draft-ietf-simple-message-sessions-05 16.6 draft-ietf-simple-message-sessions-05
o Changed the use of session URLs. Instead of a single session URL, o Changed the use of session URLs. Instead of a single session URL,
each endpoint is identified by a distinct URL. MSRP requests will each endpoint is identified by a distinct URL. MSRP requests will
put the destination URL in a To header, and the sender URL in a put the destination URL in a To header, and the sender URL in a
From header. From header.
o Changed the SDP exchange of MSRP URLs to handle the URL for each o Changed the SDP exchange of MSRP URLs to handle the URL for each
endpoint. Further, changed the SDP attribute to support a list of endpoint. Further, changed the SDP attribute to support a list of
URLs in each direction. This may be used with relays to exchange URLs in each direction. This may be used with relays to exchange
paths, rather than single URLs. MSRP endpoints must be able to paths, rather than single URLs. MSRP endpoints must be able to
intelligently process such a list if received. This document does intelligently process such a list if received. This document does
not, however, describe how to generate such a list. not, however, describe how to generate such a list.
o Added section for Delivery Status Notification handling, and added o Added section for Delivery Status Notification handling, and added
associated entries into the syntax definition. associated entries into the syntax definition.
o Added content fragmentation section. o Added content fragmentation section.
o Removed recommendation to start separate session for large o Removed recommendation to start separate session for large
transfers. transfers.
o Corrected some mistakes in the syntax definitions. o Corrected some mistakes in the syntax definitions.
o Added Chris Boulton as a co-author for his contribution of the DSN o Added Chris Boulton as a co-author for his contribution of the DSN
text. text.
16.6 draft-ietf-simple-message-sessions-04 16.7 draft-ietf-simple-message-sessions-04
o Removed the direction attribute. Rather than using a comedia o Removed the direction attribute. Rather than using a comedia
styled direction negotiation, we just state that the answerer styled direction negotiation, we just state that the answerer
opens any needed connection. opens any needed connection.
16.7 draft-ietf-simple-message-sessions-03 16.8 draft-ietf-simple-message-sessions-03
o Removed all specification of relays, and all features specific to o Removed all specification of relays, and all features specific to
the use of relays. The working group has chosen to move relay the use of relays. The working group has chosen to move relay
work into a separate effort, in order to advance the base work into a separate effort, in order to advance the base
specification. (The MSRP acronym is unchanged for the sake of specification. (The MSRP acronym is unchanged for the sake of
convenience.) This included removal of the BIND method, all convenience.) This included removal of the BIND method, all
response codes specific to BIND, Digest Authentication, and the response codes specific to BIND, Digest Authentication, and the
inactivity timeout. inactivity timeout.
o Removed text indicating that an endpoint could retry failed o Removed text indicating that an endpoint could retry failed
requests on the same connection. Rather, the endpoint should requests on the same connection. Rather, the endpoint should
skipping to change at page 48, line 4 skipping to change at page 50, line 45
the use of relays. The working group has chosen to move relay the use of relays. The working group has chosen to move relay
work into a separate effort, in order to advance the base work into a separate effort, in order to advance the base
specification. (The MSRP acronym is unchanged for the sake of specification. (The MSRP acronym is unchanged for the sake of
convenience.) This included removal of the BIND method, all convenience.) This included removal of the BIND method, all
response codes specific to BIND, Digest Authentication, and the response codes specific to BIND, Digest Authentication, and the
inactivity timeout. inactivity timeout.
o Removed text indicating that an endpoint could retry failed o Removed text indicating that an endpoint could retry failed
requests on the same connection. Rather, the endpoint should requests on the same connection. Rather, the endpoint should
consider the connection dead, and either signal a reconnection or consider the connection dead, and either signal a reconnection or
end the session. end the session.
o Added text describing subsequent SDP exchanges. Added mandatory o Added text describing subsequent SDP exchanges. Added mandatory
"count" parameter to the direction attribute to allow explicit "count" parameter to the direction attribute to allow explicit
signaling of the need to reconnect. signaling of the need to reconnect.
o Added text to describe the use of send and receive only indicators o Added text to describe the use of send and receive only indicators
in SDP for one-way transfer of large content. in SDP for one-way transfer of large content.
o Added text requiring unique port field values if multiple M-line's o Added text requiring unique port field values if multiple M-line's
exist. exist.
o Corrected a number of editorial mistakes. o Corrected a number of editorial mistakes.
16.8 draft-ietf-simple-message-sessions-02 16.9 draft-ietf-simple-message-sessions-02
o Moved all content type negotiation from the "m"-line format list o Moved all content type negotiation from the "m"-line format list
into "a"-line attributes. Added the accept-types attribute. This into "a"-line attributes. Added the accept-types attribute. This
is due to the fact that the sdp format-list syntax is not is due to the fact that the sdp format-list syntax is not
conducive to encoding MIME content types values. conducive to encoding MIME content types values.
o Added "other-method" construction to the message syntax to allow o Added "other-method" construction to the message syntax to allow
for extensible methods. for extensible methods.
o Consolidated all syntax definitions into the same section. o Consolidated all syntax definitions into the same section.
Cleaned up ABNF for digest challenge and response syntax. Cleaned up ABNF for digest challenge and response syntax.
o Changed the session inactivity timeout to 12 minutes. o Changed the session inactivity timeout to 12 minutes.
o Required support for the SHA1 algorithm. o Required support for the SHA1 algorithm.
o Required support for the message/cpim format. o Required support for the message/cpim format.
o Fixed lots of editorial issues. o Fixed lots of editorial issues.
o Documented a number of open issues from recent list discussions. o Documented a number of open issues from recent list discussions.
16.9 draft-ietf-simple-message-sessions-01 16.10 draft-ietf-simple-message-sessions-01
o Abstract rewritten. o Abstract rewritten.
o Added architectural considerations section. o Added architectural considerations section.
o The m-line format list now only describes the root body part for a o The m-line format list now only describes the root body part for a
request. Contained body part types may be described in the request. Contained body part types may be described in the
"accept-wrapped-types" a-line attribute. "accept-wrapped-types" a-line attribute.
o Added a standard dummy value for the m-line port field. Clarified o Added a standard dummy value for the m-line port field. Clarified
that a zero in this field has normal SDP meaning. that a zero in this field has normal SDP meaning.
o Clarified that an endpoint is globally configured as to whether or o Clarified that an endpoint is globally configured as to whether or
not to use a relay. There is no relay discovery mechanism not to use a relay. There is no relay discovery mechanism
skipping to change at page 49, line 5 skipping to change at page 51, line 46
hash for digest authentication. hash for digest authentication.
o CMS usage replaced with S/MIME. o CMS usage replaced with S/MIME.
o TLS and msrps: usage clarified. o TLS and msrps: usage clarified.
o Session state timeout is now based on SEND activity, rather than o Session state timeout is now based on SEND activity, rather than
BIND and VISIT refreshes. BIND and VISIT refreshes.
o Default port added. o Default port added.
o Added sequence diagrams to the example message flows. o Added sequence diagrams to the example message flows.
o Added discussion of self-signed certificates in the security o Added discussion of self-signed certificates in the security
considerations section. considerations section.
16.10 draft-ietf-simple-message-sessions-00 16.11 draft-ietf-simple-message-sessions-00
o Name changed to reflect status as a work group item. o Name changed to reflect status as a work group item.
o This version no longer supports the use of multiple sessions o This version no longer supports the use of multiple sessions
across a single TCP session. This has several related changes: across a single TCP session. This has several related changes:
There is now a single session URI, rather than a separate one for There is now a single session URL, rather than a separate one for
each endpoint. The session URI is not required to be in requests each endpoint. The session URL is not required to be in requests
other than BIND and VISIT, as the session can be determined based other than BIND and VISIT, as the session can be determined based
on the connection on which it arrives. on the connection on which it arrives.
o BIND and VISIT now create soft state, eliminating the need for the o BIND and VISIT now create soft state, eliminating the need for the
RELEASE and LEAVE methods. RELEASE and LEAVE methods.
o The MSRP URL format was changed to better reflect generic URL o The MSRP URL format was changed to better reflect generic URL
standards. URL comparison and resolution rules were added. SRV standards. URL comparison and resolution rules were added. SRV
usage added. usage added.
o Determination of host and visitor roles now uses a direction o Determination of host and visitor roles now uses a direction
attribute much like the one used in COMEDIA. attribute much like the one used in COMEDIA.
o Format list negotiation expanded to allow a "prefer these formats o Format list negotiation expanded to allow a "prefer these formats
but try anything" semantic but try anything" semantic
o Clarified handling of direction notification failures. o Clarified handling of direction notification failures.
o Clarified signaling associated with session failure due to dropped o Clarified signaling associated with session failure due to dropped
connections. connections.
o Clarified security related motivations for MSRP. o Clarified security related motivations for MSRP.
o Removed MIKEY dependency for session key exchange. Simple usage o Removed MIKEY dependency for session key exchange. Simple usage
of k-lines in SDP, where the SDP exchange is protected end-to-end of k-lines in SDP, where the SDP exchange is protected end-to-end
seems sufficient. seems sufficient.
16.11 draft-campbell-simple-im-sessions-01 16.12 draft-campbell-simple-im-sessions-01
Version 01 is a significant re-write. References to COMEDIA were Version 01 is a significant re-write. References to COMEDIA were
removed, as it was determined that COMEDIA would not allow removed, as it was determined that COMEDIA would not allow
connections to be used bidirectional in the presence of NATs. connections to be used bidirectional in the presence of NATs.
Significantly more discussion of a concrete mechanism has been added Significantly more discussion of a concrete mechanism has been added
to make up for no longer using COMEDIA. Additionally, this draft and to make up for no longer using COMEDIA. Additionally, this draft and
draft-campbell-cpimmsg-sessions (which would have also changed draft-campbell-cpimmsg-sessions (which would have also changed
drastically) have now been combined into this single draft. drastically) have now been combined into this single draft.
17. Contributors and Acknowledgments 17. Contributors and Acknowledgments
skipping to change at page 50, line 9 skipping to change at page 52, line 48
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, and Sam Hartman.
18. References 18. References
18.1 Normative References 18.1 Normative References
[1] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC [1] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
2246, January 1999. RFC 2246, January 1999.
[2] Handley, M. and V. Jacobson, "SDP: Session Description [2] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session
Protocol", RFC 2327, April 1998. Description Protocol",
Internet-Draft draft-ietf-mmusic-sdp-new-23, 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.
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 50, line 38 skipping to change at page 53, line 30
[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 Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August 1997. Content-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", Resource Identifiers (URI): Generic Syntax",
draft-fielding-uri-rfc2396bis-07 (work in progress), September internet-draft draft-fielding-uri-rfc2396bis-07, September
2004. 2004.
[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", RFC T. Wright, "Transport Layer Security (TLS) Extensions",
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
(CPIM): Message Format", RFC 3862, August 2004. (CPIM): Message Format", RFC 3862, August 2004.
[13] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for [13] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer 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", RFC [14] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
3269, November 2003. RFC 3629, November 2003.
18.2 Informational References 18.2 Informational References
[15] Johnston, A. and O. Levin, "Session Initiation Protocol Call [15] 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), Internet-Draft draft-ietf-sipping-cc-conferencing-05, October
October 2004. 2004.
[16] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo, [16] 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.
[17] Sparks, R. and A. Johnston, "Session Initiation Protocol Call [17] Sparks, R. and A. Johnston, "Session Initiation Protocol Call
Control - Transfer", draft-ietf-sipping-cc-transfer-03 (work in Control - Transfer",
progress), October 2004. Internet-Draft draft-ietf-sipping-cc-transfer-03, October 2004.
[18] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and [18] 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.
[19] Mahy, R., "Benefits and Motivation for Session Mode Instant [19] Mahy, R., "Benefits and Motivation for Session Mode Instant
Messaging", draft-mahy-simple-why-session-mode-01 (work in Messaging",
progress), February 2004. Internet-Draft draft-mahy-simple-why-session-mode-01, February
2004.
[20] Jennings, C. and R. Mahy, "Relay Extensions for Message [20] Jennings, C. and R. Mahy, "Relay Extensions for Message
Sessions Relay Protocol (MSRP)", Sessions Relay Protocol (MSRP)",
draft-ietf-simple-msrp-relays-02 (work in progress), October Internet-Draft draft-ietf-simple-msrp-relays-03, February 2005.
2004.
[21] Peterson, J. and C. Jennings, "Enhancements for Authenticated [21] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)", Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-03 (work in progress), September 2004. Internet-Draft draft-ietf-sip-identity-03 , September 2004.
[22] Jennings, C. and J. Peterson, "Certificate Management Service [22] Jennings, C. and J. Peterson, "Certificate Management Service
for SIP", draft-ietf-sipping-certs-00 (work in progress), for SIP", Internet-Draft draft-ietf-sipping-certs-00, October
October 2004. 2004.
[23] Yon, D., "Connection-Oriented Media Transport in SDP", [23] Yon, D., "Connection-Oriented Media Transport in SDP",
draft-ietf-mmusic-sdp-comedia-09 (work in progress), September Internet-Draft draft-ietf-mmusic-sdp-comedia-09, September
2004. 2004.
[24] Peterson, J., "A Common Profile for Instant Messaging (CPIM)", [24] Peterson, J., "A Common Profile for Instant Messaging (CPIM)",
rfc 3860, August 2004. rfc 3860, August 2004.
[25] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, [25] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217,
December 2001. December 2001.
[26] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC [26] Ramsdell, B., "S/MIME Version 3 Message Specification",
2633, June 1999. RFC 2633, June 1999.
[27] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone [27] 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), June Internet-Draft draft-ietf-sipping-early-media-02, June 2004.
2004.
[28] Saint-Andre, P., "Extensible Messaging and Presence Protocol [28] Saint-Andre, P., "Extensible Messaging and Presence Protocol
(XMPP): Instant Messaging and Presence", rfc 3921, October (XMPP): Instant Messaging and Presence", rfc 3921, October
2004. 2004.
[29] Rosenberg, J., "Indicating User Agent Capabilities in the [29] Rosenberg, J., "Indicating User Agent Capabilities in the
Session Initiation Protocol (SIP)", rfc 3840, August 2004. Session Initiation Protocol (SIP)", rfc 3840, August 2004.
Authors' Addresses Authors' Addresses
Ben Campbell (editor) Ben Campbell (editor)
Estacado Systems Estacado Systems
EMail: ben@estacado.net Email: ben@estacado.net
Rohan Mahy (editor) Rohan Mahy (editor)
Airespace Airespace
110 Nortech Parkway 110 Nortech Parkway
San Jose, CA 95134 San Jose, CA 95134
USA USA
EMail: rohan@ekabal.com Email: rohan@ekabal.com
Cullen Jennings (editor) Cullen Jennings (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Dr. 170 West Tasman Dr.
MS: SJC-21/2 MS: SJC-21/2
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 408 421-9990 Phone: +1 408 421-9990
EMail: fluffy@cisco.com Email: fluffy@cisco.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 53, line 41 skipping to change at page 56, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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