draft-ietf-simple-message-sessions-07.txt   draft-ietf-simple-message-sessions-08.txt 
SIMPLE WG B. Campbell, Ed. SIMPLE WG B. Campbell, Ed.
Internet-Draft Internet-Draft Estacado Systems
Expires: January 16, 2005 R. Mahy Expires: February 23, 2005 R. Mahy, Ed.
C. Jennings C. Jennings, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
July 18, 2004 August 25, 2004
The Message Session Relay Protocol The Message Session Relay Protocol
draft-ietf-simple-message-sessions-07.txt draft-ietf-simple-message-sessions-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with 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 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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 16, 2005. This Internet-Draft will expire on February 23, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
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. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 5
4. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 MSRP Framing and Message Chunking . . . . . . . . . . . . 8 4.1 MSRP Framing and Message Chunking . . . . . . . . . . . . 8
4.2 MSRP Addressing . . . . . . . . . . . . . . . . . . . . . 11 4.2 MSRP Addressing . . . . . . . . . . . . . . . . . . . . . 9
4.3 MSRP Transaction and Report Model . . . . . . . . . . . . 11 4.3 MSRP Transaction and Report Model . . . . . . . . . . . . 9
4.4 MSRP Connection Model . . . . . . . . . . . . . . . . . . 12 4.4 MSRP Connection Model . . . . . . . . . . . . . . . . . . 10
5. MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 15 5.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 13
5.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 16 5.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 14
6. Method-Specific Behavior . . . . . . . . . . . . . . . . . . 16 6. Method-Specific Behavior . . . . . . . . . . . . . . . . . . 14
6.1 Constructing Requests . . . . . . . . . . . . . . . . . . 16 6.1 Constructing Requests . . . . . . . . . . . . . . . . . . 14
6.1.1 Delivering SEND requests . . . . . . . . . . . . . . . 17 6.1.1 Delivering SEND requests . . . . . . . . . . . . . . . 15
6.1.2 Sending REPORT requests . . . . . . . . . . . . . . . 19 6.1.2 Sending REPORT requests . . . . . . . . . . . . . . . 18
6.1.3 Failure REPORT Generation . . . . . . . . . . . . . . 19 6.1.3 Failure REPORT Generation . . . . . . . . . . . . . . 18
6.2 Constructing Responses . . . . . . . . . . . . . . . . . . 20 6.2 Constructing Responses . . . . . . . . . . . . . . . . . . 19
6.3 Receiving Requests . . . . . . . . . . . . . . . . . . . . 21 6.3 Receiving Requests . . . . . . . . . . . . . . . . . . . . 20
6.3.1 Receiving SEND requests . . . . . . . . . . . . . . . 21 6.3.1 Receiving SEND requests . . . . . . . . . . . . . . . 20
6.3.2 Receiving REPORT requests . . . . . . . . . . . . . . 22 6.3.2 Receiving REPORT requests . . . . . . . . . . . . . . 21
7. Using MSRP with SIP . . . . . . . . . . . . . . . . . . . . 22 7. Using MSRP with SIP . . . . . . . . . . . . . . . . . . . . 22
7.1 SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . 22 7.1 SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . 22
7.1.1 URL Negotiations . . . . . . . . . . . . . . . . . . . 25 7.1.1 URL Negotiations . . . . . . . . . . . . . . . . . . . 24
7.1.2 Path Attributes with Multiple URLs . . . . . . . . . . 26 7.1.2 Path Attributes with Multiple URLs . . . . . . . . . . 25
7.1.3 Updated SDP Offers . . . . . . . . . . . . . . . . . . 27 7.1.3 Updated SDP Offers . . . . . . . . . . . . . . . . . . 26
7.1.4 Example SDP Exchange . . . . . . . . . . . . . . . . . 27 7.1.4 Example SDP Exchange . . . . . . . . . . . . . . . . . 26
7.1.5 Connection Negotiation . . . . . . . . . . . . . . . . 28 7.1.5 Connection Negotiation . . . . . . . . . . . . . . . . 27
7.2 MSRP User Experience with SIP . . . . . . . . . . . . . . 28 7.2 MSRP User Experience with SIP . . . . . . . . . . . . . . 27
8. DSN payloads in MSRP REPORT Requests . . . . . . . . . . . . 28 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 28
8.1 Per-Message DSN header usage . . . . . . . . . . . . . . . 28 9. Response Code Descriptions . . . . . . . . . . . . . . . . . 30
8.2 Per-Recipient DSN header usage . . . . . . . . . . . . . . 29 9.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.3 original-envelope-id usage . . . . . . . . . . . . . . . . 29 9.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.4 reporting-mta . . . . . . . . . . . . . . . . . . . . . . 29 9.3 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.5 final-recipient . . . . . . . . . . . . . . . . . . . . . 29 9.4 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.6 action . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.5 426 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.7 status . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.6 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 30 9.7 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
10. Response Code Descriptions . . . . . . . . . . . . . . . . . 32 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.1 Basic IM session . . . . . . . . . . . . . . . . . . . . 31
10.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.2 Chunked Message . . . . . . . . . . . . . . . . . . . . 33
10.3 403 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.3 System Message . . . . . . . . . . . . . . . . . . . . . 33
10.4 415 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.4 Positive Report . . . . . . . . . . . . . . . . . . . . 34
10.5 426 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.5 Forked IM . . . . . . . . . . . . . . . . . . . . . . . 34
10.6 481 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . 37
10.7 506 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 12. CPIM compatibility . . . . . . . . . . . . . . . . . . . . . 37
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 33 13. Security Considerations . . . . . . . . . . . . . . . . . . 38
11.1 Basic IM session . . . . . . . . . . . . . . . . . . . . 33 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 40
11.2 Chunked Message . . . . . . . . . . . . . . . . . . . . 36 14.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . 40
11.3 System Message . . . . . . . . . . . . . . . . . . . . . 36 14.2 MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . 40
11.4 Positive Report . . . . . . . . . . . . . . . . . . . . 37 14.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . 40
11.5 Forked IM . . . . . . . . . . . . . . . . . . . . . . . 37 14.3.1 Accept Types . . . . . . . . . . . . . . . . . . . . 40
12. Extensibility . . . . . . . . . . . . . . . . . . . . . . . 40 14.3.2 Wrapped Types . . . . . . . . . . . . . . . . . . . 40
13. CPIM compatibility . . . . . . . . . . . . . . . . . . . . . 40 14.3.3 Max Size . . . . . . . . . . . . . . . . . . . . . . 41
14. Security Considerations . . . . . . . . . . . . . . . . . . 40 14.3.4 Path . . . . . . . . . . . . . . . . . . . . . . . . 41
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 42 15. Change History . . . . . . . . . . . . . . . . . . . . . . . 41
15.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . 42 15.1 draft-ietf-simple-message-sessions-08 . . . . . . . . . 41
15.2 MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . 42 15.2 draft-ietf-simple-message-sessions-07 . . . . . . . . . 41
15.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . 43 15.3 draft-ietf-simple-message-sessions-06 . . . . . . . . . 42
15.3.1 Accept Types . . . . . . . . . . . . . . . . . . . . 43 15.4 draft-ietf-simple-message-sessions-05 . . . . . . . . . 42
15.3.2 Wrapped Types . . . . . . . . . . . . . . . . . . . 43 15.5 draft-ietf-simple-message-sessions-04 . . . . . . . . . 43
15.3.3 Path . . . . . . . . . . . . . . . . . . . . . . . . 43 15.6 draft-ietf-simple-message-sessions-03 . . . . . . . . . 43
15.4 IANA registration forms for DSN types . . . . . . . . . 43 15.7 draft-ietf-simple-message-sessions-02 . . . . . . . . . 43
15.4.1 IANA registration form for address-type . . . . . . 43 15.8 draft-ietf-simple-message-sessions-01 . . . . . . . . . 44
15.4.2 IANA registration form for MTA-name-type . . . . . . 44 15.9 draft-ietf-simple-message-sessions-00 . . . . . . . . . 44
16. Change History . . . . . . . . . . . . . . . . . . . . . . . 44 15.10 draft-campbell-simple-im-sessions-01 . . . . . . . . . . 45
16.1 draft-ietf-simple-message-sessions-07 . . . . . . . . . 44 16. Contributors and Acknowledgments . . . . . . . . . . . . . . 45
16.2 draft-ietf-simple-message-sessions-06 . . . . . . . . . 44 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
16.3 draft-ietf-simple-message-sessions-05 . . . . . . . . . 45 17.1 Normative References . . . . . . . . . . . . . . . . . . . 45
16.4 draft-ietf-simple-message-sessions-04 . . . . . . . . . 45 17.2 Informational References . . . . . . . . . . . . . . . . . 46
16.5 draft-ietf-simple-message-sessions-03 . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 48
16.6 draft-ietf-simple-message-sessions-02 . . . . . . . . . 46 Intellectual Property and Copyright Statements . . . . . . . 49
16.7 draft-ietf-simple-message-sessions-01 . . . . . . . . . 46
16.8 draft-ietf-simple-message-sessions-00 . . . . . . . . . 47
16.9 draft-campbell-simple-im-sessions-01 . . . . . . . . . . 47
17. Contributors and Acknowledgments . . . . . . . . . . . . . . 47
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
18.1 Normative References . . . . . . . . . . . . . . . . . . . 48
18.2 Informational References . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 50
Intellectual Property and Copyright Statements . . . . . . . 52
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
skipping to change at page 4, line 33 skipping to change at page 4, line 33
messaging that is part of a "session" with a definite start and end messaging that is part of a "session" with a definite start and end
is called session-mode messaging. is called 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 [19]. Session-mode messaging has a number of benefits [20] method [19]. Session-mode messaging has a number of benefits [20]
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 (MSRP), whose sessions can be included in an offer or answer protocol called the Message Session Relay Protocol (MSRP), whose
[3] of a session description (for example, SDP [2]). The exchange is sessions can be included in an offer or answer [3] using the Session
carried by some signaling protocol, such as SIP [4]. This allows a Description Protocol(SDP [2]). The exchange is carried by some
communication user agent to offer a messaging session as one of the signaling protocol, such as SIP [4]. This allows a communication
possible media types in a session. For instance, Alice may want to user agent to offer a messaging session as one of the possible media
communicate with Bob. Alice doesn't know at the moment whether Bob types in a session. For instance, Alice may want to communicate with
has his phone or his IM client handy, but she's willing to use Bob. Alice doesn't know at the moment whether Bob has his phone or
either. She sends an invitation to a session to the address of his IM client handy, but she's willing to use either. She sends an
record she has for Bob, sip:bob@example.com. Her invitation offers invitation to a session to the address of record she has for Bob,
both voice and an IM session. The SIP services at example.com sip:bob@example.com. Her invitation offers both voice and an IM
forward the invitation to Bob at his currently registered clients. session. The SIP services at example.com forward the invitation to
Bob accepts the invitation at his IM client and they begin a threaded Bob at his currently registered clients. Bob accepts the invitation
chat conversation. at his IM client and they begin a threaded chat conversation.
This session model allows message sessions to be integrated into This session model allows message sessions to be integrated into
advanced communications applications with little to no additional advanced communications applications with little to no additional
protocol development. For example, during the above chat session, protocol development. For example, during the above chat session,
Bob decides Alice really needs to be talking to Carol. Bob can Bob decides Alice really needs to be talking to Carol. Bob can
transfer [18] Alice to Carol, introducing them into their own transfer [18] Alice to Carol, introducing them into their own
messaging session. Messaging sessions can then be easily integrated messaging session. Messaging sessions can then be easily integrated
into call-center and dispatch environments utilizing third-party call into call-center and dispatch environments utilizing third-party call
control [17] and conferencing [16] applications. control [17] and conferencing [16] applications.
skipping to change at page 9, line 8 skipping to change at page 9, line 8
chunk. There is also a Byte-Range header in the request that chunk. There is also a Byte-Range header in the request that
indicates the overall position of this chunk inside the complete indicates the overall position of this chunk inside the complete
message. 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$
The receiver uses the value of the Message-ID header to determine
which of multiple chunks belong to the same message. The Message-ID
header MUST have the same value for each chunk in the same message,
and a sender MUST ensure that the message ID is unique for each of
the messages it sends within a particular session.
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)
characters. After the boundary marker, there MUST be a flag
character that is either a "$" (for the last chunk of the message) or
"+" (for chunks other than the last). If the chunk represents the
data that forms the end of the message, the flag MUST be a "$",
otherwise the flag MUST be a "+".
The Byte-Range header value contains a starting value followed by a
"-", an ending value followed by a "/", and finally the total length.
The starting value indicates the index into the message where the
first byte in the current chunk belongs. The index of the first
octet in the complete message is ONE, not zero. The ending value
indicates the location where the last octet belongs. The body MAY
contain less data than is indicated by the end but it MUST NOT
contain more octets than indicated. The length indicates the number
of octets in the complete message. Both the ending value and length
MAY have the value of "*" in some or all of the chunks, to indicate
that they are not specified. If no Byte-Range header is present, the
SEND request MUST be treated as if there was a Byte-Range header
present with a value of "1-*/*".
This chunking mechanism allows a sender to interrupt a chunk part way This chunking mechanism allows a sender to interrupt a chunk part way
through sending it by writing out the boundary termination and the through sending it. The ability to interrupt messages allows
"+" flag to indicate that the end of this chunk is not the end of the multiple sessions to share a TCP connection, and for large messages
complete message. The ability to interrupt messages allows multiple to be sent efficiently while not blocking other messages that share
sessions to share a TCP connection, and for large messages to be sent the same connection.
efficiently while not blocking other messages that share the same
connection.
To insure fairness over a connection, senders MUST NOT send chunks
with a body larger than 2048 octets unless they are prepared to
interrupt them. A sender can use one of the following two strategies
to satisfy this requirement. The sender is STRONGLY RECOMMENDED to
send messages larger than 2048 octets using as few chunks as
possible, interrupting chunks (at least 2048 octets long) when other
traffic is waiting to use the same connection. Alternatively, the
sender MAY simply send chunks in 2048 octet increments until the
final chunk. Note that the former strategy results in markedly more
efficient use of 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 for a complete message. Senders SHOULD NOT
break messages into chunks smaller than 2048 octets, except for the
final chunk of a complete message.
Receivers MUST not assume the chunks will be delivered in order or
that they will receive all the chunks with "+" flags before they
receive the chunk with the "$" flag. In certain cases of connection
failure, it is possible for information to be duplicated. If chunks
data is received that overlaps already received data for the same
message, the last chunk received takes precedence (even though this
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
150, this second chunk will overwrite bytes 50 to 100 of the data
that had already been received. Although other schemes work, this is
the easiest for the receiver and results in consistent behavior
between clients.
The seven "-" before the boundary are used so that the receiver can
search for the value "----", 32 bits at a time to find the probable
location of the boundary. This allows most processors to locate the
boundaries and copy the memory at the same rate that a normal memory
copy could be done. This approach results in a system that is as
fast as framing based on specifying the body length in the headers of
the request, but also allows for the interruption of messages.
The ability to interrupt messages is needed so that TCP connections The ability to interrupt messages is needed so that TCP connections
can be shared. Connection sharing is necessary for "fair" allocation can be shared. Connection sharing is necessary for "fair" allocation
of bandwidth in congestion situations and for allowing MSRP network of bandwidth in congestion situations and for allowing MSRP network
elements that have a very large number of concurrent connections to elements that have a very large number of concurrent connections to
different users. different users.
4.2 MSRP Addressing 4.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
skipping to change at page 11, line 50 skipping to change at page 10, line 29
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 "Report-Success" can have a value of "yes" or "no" and the
"Report-Failure" header can have a value of "yes", "no", or "Report-Failure" header can have a value of "yes", "no", or
"partial". "partial".
If the value of "Report-Failure" is set to "yes", then the sender of The combinations of reporting are needed to meet the various
the request runs a timer. If a 200 response to the transaction is scenarios of currently deployed IM systems. Report-Success might be
not received within 30 seconds from the time the last byte of the "no" in many public systems to reduce load but is used in some
transaction is sent, the element MUST inform the user that the current enterprise systems, such as systems used for securities
request probably failed. If the value is set to "partial", then the trading. A Report-Failure value of "no" is useful for sending system
element sending the transaction does not have to run a timer, but messages such as "the system is going down in 5 minutes" without
MUST inform the user if receives a non-recoverable error response to causing a response explosion to the sender. A Report-Failure of
the transaction. "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
Similarly if the value of the Report-Success header is "yes", then "partial" to reduce the load on the servers caused by 200 OK
the receiving node MUST send a "success" REPORT after the request is responses, but still allow error responses to be sent in many cases.
complete to indicate that the request succeeded. Likewise if the
value is "no", it MUST NOT send a success REPORT.
A consequence of this is that if an MSRP element receives a request
that has the Report-Failure header set to a value of "no", it SHOULD
NOT send any responses to this request, because the element sending
the request would not do anything with the resulting response. If
the value is "partial", it SHOULD NOT send a 200 response to the
request, but SHOULD send a non-200 class response if appropriate.
If no Report-Success header is present in a SEND request, it MUST be
treated the same as a Report-Success header with value of "no". If
no Report-Failure header is present, it MUST be treated the same as a
Report-Failure header with value of "yes". REPORT requests MUST have
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
reporting on. If an MSRP element receives a REPORT for a Message-ID
it does not recognize, it SHOULD silently ignore the REPORT.
Report-Success and Report-Failure MUST NOT be present in a REPORT
request. MSRP nodes MUST NOT send REPORT requests in response to
report requests. MSRP Nodes MUST NOT send MSRP responses to REPORT
requests.
The combinations of reporting may seem overly complex but they are
needed to meet the various scenarios of currently deployed IM
systems. Report-Success might be "no" in many public systems to
reduce load but is used in some current enterprise systems, such as
systems used for securities trading. A Report-Failure value of "no"
is useful for sending system messages such as "the system is going
down in 5 minutes" without causing a response explosion to the
sender. A Report-Failure of "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 "partial" to reduce the load on the servers
caused by 200 OK responses, but still allow error responses to be
sent in many cases.
4.4 MSRP Connection Model 4.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 connection, with the appropriate security URL, it first needs a connection, with the appropriate security
properties, to the host specified in the URL. If the sender already properties, to the host specified in the URL. If the sender already
has such a connection, that is, one associated with the same host, has such a connection, that is, one associated with the same host,
port, and URL scheme, then it SHOULD reuse that connection. port, and URL scheme, then it SHOULD reuse that connection.
When a new MSRP session is created, the convention is that the When a new MSRP session is created, the convention is that the
element that sent the SDP offer MUST immediately issue a SEND request element that sent the SDP offer MUST immediately issue a SEND request
to the answerer. This request MAY have a empty body, or MAY carry to the answerer. This request MAY have a empty body, or MAY carry
content. content.
When a new connection needs to be formed, the element looks at the When a new connection needs to be formed, the element looks at the
URL to decide on the type of connection (TLS, TCP, etc.) then URL to decide on the type of connection (TLS, TCP, etc.) then
connects to the host indicated by the URL, following the URL connects to the host indicated by the URL, following the URL
resolution rules in Section 5.2. For connections using the msrps: resolution rules in Section 5.2. For connections using the msrps:
scheme, the SubjectAltName in the received certificate MUST match the scheme, the SubjectAltName in the received certificate MUST match the
hostname port of the URL and the certificate MUST be valid, including hostname part of the URL and the certificate MUST be valid, including
having a date that is valid and being signed by an acceptable having a date that is valid and being signed by an acceptable
certificate authority. At this point the device that initiated the certificate authority. At this point the device that initiated the
connection can assume that this connection is with the correct host. connection 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 know the identity of the connecting host. When mutual connection can know the identity of the connecting host. When mutual
TLS authentication is not used, the listening device MUST wait until TLS authentication is not used, the listening device MUST wait until
it receives a request on the connection to determine the identity of it receives a request on the connection to determine the identity of
the connecting device. the connecting device.
When the first request arrives, it's 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 that this URL was given to. 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 so, it MUST reject the request with a 506
response. 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 failed any sessions associated with the connection as well. consider failed any sessions associated with the connection as well.
When an endpoint notices such a failure, it SHOULD attempt to When an endpoint notices such a failure, it MAY attempt to re-create
re-create any such sessions using a new SDP exchange. If a any such sessions. If it chooses to do so, it MUST use new SDP
replacement session is successfully created, endpoints MAY attempt to exchange. If a replacement session is successfully created,
resend any content for which delivery on the original session could endpoints MAY attempt to resend any content for which delivery on the
not be confirmed. If it does this, the Message-ID values for the original session could not be confirmed. If it does this, the
resent messages MUST match those used in the initial attempts. If Message-ID values for the resent messages MUST match those used in
the receiving endpoint receives more than one message with the same the initial attempts. If the receiving endpoint receives more than
Message-ID. It SHOULD assume that the messages are duplicates. It one message with the same Message-ID. It SHOULD assume that the
MAY take any action based on that knowledge, but SHOULD NOT present messages are duplicates. It MAY take any action based on that
the duplicate messages to the user without warning of the duplicates. knowledge, but SHOULD NOT present the duplicate messages to the user
without warning of the duplicates.
In this situation, the endpoint MUST choose Message-ID values so that In this situation, the endpoint MUST choose Message-ID values so that
they are unique in the context of both the original session and the they are unique in the context of both the original session and the
replacement session. 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 normal endpoints SHOULD NOT split chunks between sessions under normal
circumstances. circumstances.
If a connection fails, the sender SHOULD attempt to re-setup the URL If a connection fails, the sender SHOULD attempt to re-setup the URL
path using a new offer, for example, in a SIP re-invite or update path using a new offer, for example, in a SIP re-invite or update
[13]. It MUST not assume that the new URLs in the SDP will be the [12]. It MUST not assume that the new URLs in the SDP will be the
same as the old ones. A connection SHOULD not be closed while there same as the old ones. A connection SHOULD not be closed while there
are sessions that are using this connection. are sessions that are using this connection.
5. MSRP URLs 5. MSRP URLs
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
RFC2396 [11], with a scheme of "msrp" or "msrps": RFC2396 [10], with a scheme of "msrp" or "msrps":
MSRP_urls = msrp-scheme "://" [userinfo "@"] hostport ["/" MSRP_urls = msrp-scheme "://" [userinfo "@"] hostport ["/"
resource] ";" transport resource] ";" transport
msrp-scheme = "msrp" / "msrps" msrp-scheme = "msrp" / "msrps"
resource = 1*unreserved resource = 1*unreserved
transport = "tcp" / token transport = "tcp" / ALPHANUM
The constructions for "userinfo", "hostport", and "unreserved" are The constructions for "userinfo", "hostport", and "unreserved" are
detailed in RFC2396 [11]. URLs designating MSRP over TCP MUST detailed in RFC2396 [10]. URLs designating MSRP over TCP MUST
include the "tcp" parameter. If some other transport is used, the include the "tcp" parameter. If some other transport is used, the
"tcp" parameter MUST NOT be present. "tcp" parameter MUST NOT be present.
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" parameter. Documents that provide bindings herein use the "tcp" parameter. Documents that provide bindings
on other transports should define respective parameters for those on other transports should define respective parameters for those
transports. A MSRP URL with multiple, contradictory transports is transports.
invalid, unless some other document specifies meaning for the
particular combination of transport parameters.
An MSRP URL server part identifies a participant in an MSRP session.
If the server part contains a numeric IP address, it MUST also An MSRP URL hostport field identifies a participant in an MSRP
session. If the hostport contains a numeric IP address, it MUST also
contain a port. The resource part identifies a particular session contain a port. The resource part identifies a particular session
the participant. The absence of the resource part indicates a the participant. The absence of the resource part indicates a
reference to an MSRP host device, but does not specifically refer to reference to an MSRP host device, but does not specifically refer to
a particular session resource. a particular session resource.
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 14.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
appropriate. This makes life easier for network administrators who appropriate. This makes life easier for network administrators who
need to manage firewall policy for MSRP. need to manage firewall policy for MSRP.
The server part will typically not contain a userinfo component, but The server part will typically not contain a userinfo component, but
MAY do so to indicate a user account for which the session is valid. MAY do so to indicate a user account for which the session is valid.
Note that this is not the same thing as identifying the session Note that this is not the same thing as identifying the session
itself. If a userinfo component exists, it MUST be constructed only itself. If a userinfo component exists, it MUST be constructed only
skipping to change at page 15, line 40 skipping to change at page 13, line 31
msrp://host.example.com:8493/asfd34;tcp msrp://host.example.com:8493/asfd34;tcp
5.1 MSRP URL Comparison 5.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 exactly.
2. The host part is compared as case insensitive. 2. If the hostpart contains an eplicit IP address, and/or port,
these are compared numerically. Otherwise, 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 an 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 resource part is compared as case sensitive. A URL without a 4. The resource part is compared as case sensitive. A URL without a
resource part is never equivalent to one that includes a resource resource part is never equivalent to one that includes a resource
part. part.
5. URLs with different "transport" parameters never match. Two URLs 5. URLs with different "transport" parameters never match. Two URLs
skipping to change at page 17, line 13 skipping to change at page 15, line 7
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.
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)
characters. After the boundary marker, there MUST be a flag
character that is a "$" (for the last chunk of the complete
message), "#" (for the last chunk of an aborted message), or "+" (for
chunks other than the last). If the chunk represents the data that
forms the end of the complete message, the flag value MUST be a "$".
If sender is abandoning an incomplete message, and intends to send no
further chunks in that message, it MUST be a "#". Otherwise it MUST
be a "+".
If the request contains a body, the sender MUST check the body to If the request contains a body, the sender MUST check the body to
insure that the closing sequence (a CRLF, seven hyphens, and the insure that the closing sequence (a CRLF, seven hyphens, and the
transaction identifier) is not present in the body. If the closing transaction identifier) is not present in the body. If the closing
sequence is present in the body, the sender MUST choose a new sequence is present in the body, the sender MUST choose a new
transaction identifier that is not present in the body, and add the transaction identifier that is not present in the body, and add the
closing sequence, including the "$" or "+" character, and a final closing sequence, including the "$", "#", or "+" character, and a
CRLF. final CRLF.
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. Bodiless requests MUST
contain a closing sequence after the final header. 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 4.4) rules to forward the request over connection management (Section 4.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.
6.1.1 Delivering SEND requests 6.1.1 Delivering SEND requests
skipping to change at page 17, line 45 skipping to change at page 15, line 50
MAY break the complete message into chunks of 2048 octets. It then MAY break the complete message into chunks of 2048 octets. It then
generates a SEND request for each chunk, following the procedures generates a SEND request for each chunk, following the procedures
for constructing requests (Section 6.1). for constructing requests (Section 6.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 Report-Failure and/or Report-Success 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 Report-Failure and Report-Success values in their SEND requests.
If success reports are requested, the sending device MAY wish to run If success reports are requested, i.e. the value of the
a timer of some value that makes sense for it's application and take Report-Success header is "yes", the sending device MAY wish to run a
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
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
transaction is sent, the element MUST inform the user that 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
MUST inform the user if receives a non-recoverable error response to
the transaction.
If no Report-Success header is present in a SEND request, it MUST be
treated the same as a Report-Success header with value of "no". If
no Report-Failure header is present, it MUST be treated the same as a
Report-Failure header with value of "yes". REPORT requests MUST have
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
reporting on. If an MSRP element receives a REPORT for a Message-ID
it does not recognize, it SHOULD silently ignore the REPORT.
Report-Success and Report-Failure MUST NOT be present for any method
other than SEND. MSRP nodes MUST NOT send REPORT requests in
response to report requests. MSRP Nodes MUST NOT send MSRP responses
to REPORT requests.
The Byte-Range header value contains a starting value (range-start)
followed by a "-", an ending value (range-end) followed by a "/", and
finally the total length. The first byte in the message is indicated
by a 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. The range-end field SHOULD indicate the position of the message (that is, a value of one). The range-end field SHOULD
last byte in the body, if known. It MUST take the value of "*" if indicate the position of the last byte in the body, if known. It
the position is unknown, or if the request needs to be interruptible. MUST take the value of "*" if the position is unknown, or if the
The total field SHOULD contain the total size of the message, if request needs to be interruptible. The total field SHOULD contain
known. The total filed MAY contain a "*" if the total size of the the total size of the message, if known. The total field MAY contain
message is not known in advance. All chunks other than the last MUST a "*" if the total size of the message is not known in advance. All
include a "+" character in the continuation field of the closing chunks other than the last MUST include a "+" character in the
line. The final chunk MUST use a "$" character. The sender MUST continuation field of the closing line. The final chunk MUST use a
send all chunks in Byte-Range order. (However,the receiver cannot "$" character if it completes the message, or a "#" if the sender is
assume the requests will be delivered in order, as an intervening aborting the message. The sender MUST send all chunks in Byte-Range
relay may have changed the order.) order. (However, the receiver cannot assume the requests will be
delivered in order, as an intervening relay may have changed the
order.)
If the sender chooses to send a body larger than 2048 octets in a To insure fairness over a connection, senders MUST NOT send chunks
single chunk, the request MUST be constructed so that it can be with a body larger than 2048 octets unless they are prepared to
interrupted. A SEND request is interruptible if it either has no interrupt them. A sender can use one of the following two strategies
Byte-Range header field, or has such a field with a "*" in the to satisfy this requirement. The sender is STRONGLY RECOMMENDED to
last-byte sub-field. send messages larger than 2048 octets using as few chunks as
possible, interrupting chunks (at least 2048 octets long) when other
traffic is waiting to use the same connection. Alternatively, the
sender MAY simply send chunks in 2048 octet increments until the
final chunk. Note that the former strategy results in markedly more
efficient use of 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 for a complete message. Senders SHOULD NOT
break messages into chunks smaller than 2048 octets, except for the
final chunk of a complete message.
A SEND request is interruptible if it either has no Byte-Range header
field, or has such a field with a "*" in the last-byte sub-field.
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 2k MUST be interrupted to send pending
response or REPORT requests. If multiple SEND requests from response 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
connections, 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 it was sent with. An intervening with the same chunk allocation it was sent with. An intervening
relay could possibly break SEND requests into smaller chunks, or relay could possibly break SEND requests into smaller chunks, or
aggregate multiple chunks into larger ones. aggregate multiple chunks into larger ones.
The default disposition of body is "render". If the sender wants The default disposition of body 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 MUST be "binary".
6.1.2 Sending REPORT requests 6.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 Report-Success or Report-Failure 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
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 MAY include a body. If a body is included, it SHOULD REPORT requests will normally not include a body, as the REPORT
be of the DSN MIME type detailed in RFC1894 [8], but MAY be of some request header fields can carry sufficient information in most cases.
other type if the sender of the SEND request indicated support in the However, REPORT requests MAY include a body containing additional
"receipt-type" parameter of the respective Report-Success or information about the status of the assocated SEND request. Such a
Report-Failure header field. This parameter contains the alternative body is informational only, and the sender of the REPORT request
MIME type that SHOULD be used for this particular report. A client SHOULD NOT assume that the recipient pays any attention to the body.
specifying an alternative 'receipt-type' for an MSRP transaction MUST Since REPORT requests are not interruptible, the size of such a body
also be capable of receiving the default format specified in this MUST NOT exceed 2 kilobytes.
RFC1894. Use of the DSN MIME format in MSRP is described in Section
8
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 Report-Success 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 6.1), with a few additional requirements. procedures (Section 6.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.
Positive status reports SHOULD NOT include a payload.
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 Report-Success header field, or contained such a
field with a value of "no". field with a value of "no". That is, if no Report-Success header
field is present, it is treated identically to one with a value of
"no."
6.1.3 Failure REPORT Generation 6.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 Report-Failure 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
send a transaction response with an appropriate error response code. include the appopriate error code in the transaction respons.
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 Report-Failure header
field value of "none", then it MUST NOT send a failure REPORT field value of "no", then it MUST NOT send a failure REPORT request,
request, and SHOULD NOT send an MSRP response. and SHOULD NOT send an MSRP response. If the value is "partial", it
SHOULD NOT send a 200 response to the request, but SHOULD send a
non-200 class response if appropriate.
As stated above, if no Report-Failure header is present, it MUST be
treated the same as a Report-Failure 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 success reports, except the Status header code and reason fields MUST
SHOULD contain appropriate error codes. Any error response code contain appropriate error codes. Any error response code defined in
defined in this specification MAY also be used in failure reports. this specification MAY also be used in failure reports.
Failure REPORT requests MAY contain a payload, using the DSN MIME
type. They MAY contain some other type if allowed by a receipt-type
in the Report-Failure header field.
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
range-end field from the actual body data. range-end field from the actual body data.
Endpoints SHOULD NOT send REPORT requests if they have reason to Endpoints SHOULD NOT send REPORT requests if they have reason to
believe the request will not be delivered. For example, they SHOULD believe the request will not be delivered. For example, they SHOULD
NOT send a REPORT request on a session that is no longer valid. NOT send a REPORT request on a session that is no longer valid.
skipping to change at page 22, line 7 skipping to change at page 21, line 9
forms a virtual buffer to receive the message, keeping track of which forms a virtual buffer to receive the message, keeping track of which
bytes have been received and which are missing. The receiver takes bytes have been received and which are missing. The receiver takes
the data from the request and places it in the appropriate place in the data from the request and places it in the appropriate place in
the buffer. The receiver MUST determine the actual length of each the buffer. The receiver MUST 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.
Receivers MUST not assume the chunks will be delivered in order or
that they will receive all the chunks with "+" flags before they
receive the chunk with the "$" flag. In certain cases of connection
failure, it is possible for information to be duplicated. If chunks
data is received that overlaps already received data for the same
message, the last chunk received takes precedence (even though this
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
150, this second chunk will overwrite bytes 50 to 100 of the data
that had already been received. Although other schemes work, this is
the easiest for the receiver and results in consistent behavior
between clients.
The seven "-" before the boundary are used so that the receiver can
search for the value "----", 32 bits at a time to find the probable
location of the boundary. This allows most processors to locate the
boundaries and copy the memory at the same rate that a normal memory
copy could be done. This approach results in a system that is as
fast as framing based on specifying the body length in the headers of
the request, but also allows for the interruption of messages.
What is done with the body is outside the scope of MSRP and largely What is done with the body is outside the scope of MSRP and largely
determined by the MIME type. The body MAY be rendered after the determined by the MIME Content-Type and Content-Disposition. The
whole message is received or partially rendered as it is being body MAY be rendered after the whole message is received or partially
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, if an unsupported MIME type, the receiver SHOULD send a 415 response, if
allowed by the Report-Failure header field. All MSRP endpoints MUST allowed by the Report-Failure header field. All MSRP endpoints MUST
be able to receive the multipart/mixed and multipart/alternative MIME be able to receive the multipart/mixed and multipart/alternative MIME
types. types.
If the SEND request contained a Report-Success header field with a
value of "yes", and the request is either contains the entire message
or the last chunk needed to complete a message, the receiver MUST
send a success REPORT request back to the sender.
6.3.2 Receiving REPORT requests 6.3.2 Receiving REPORT requests
When an endpoint receives a REPORT request, it may correlate it to When an endpoint receives a REPORT request, it may correlate it to
the original SEND request using the Message-ID and the Byte-Range, if the 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", it SHOULD interpret the report in
skipping to change at page 22, line 47 skipping to change at page 22, line 17
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. the entire message corresponding to that chunk should be aborted.
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.
MSRP Modes MUST NOT send MSRP responses to REPORT requests.
7. Using MSRP with SIP 7. Using MSRP with SIP
7.1 SDP Offer-Answer Exchanges for MSRP Sessions 7.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
skipping to change at page 23, line 25 skipping to change at page 22, line 45
An offered or accepted MSRP media-line MUST have the following value An offered or accepted MSRP media-line MUST have the following value
exactly, with the exception that the port field MAY be set to zero. exactly, with the exception that the port field MAY be set to zero.
(According to [3], a user agent that wishes to accept an offer, but (According to [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 not a specific media-line MUST set the port number of that media-line
to zero (0).) to zero (0).)
m=message 9 msrp * m=message 9 msrp *
While MSRP could theoretically carry any media type, "message" is While MSRP could theoretically carry any media type, "message" is
appropriate. For MSRP, the port number is always ignored--the appropriate. For MSRP, the port number is always ignored--the
actual port number is provided in an MSRP URL. Instead "9" is actual port number is provided in an MSRP URL. Instead a dummy
used, which is an innocuous value which is assigned to the discard value is used, which is always ignored if non-zero. The protocol
port. The protocol is always "msrp", and the value of the format is always "msrp", and the value of the format list is always a
list is always a single asterisk character ("*"). single asterisk character ("*").
An MSRP media-line is always accompanied by a mandatory "path" An MSRP media-line is always accompanied by a mandatory "path"
attribute. This attribute contains a space separated list of URLs attribute. This attribute contains a space separated list of URLs
that must be visited to contact the user agent advertising this that must be visited to contact the user agent advertising this
session-description. If more than one URL is present, the leftmost session-description. If more than one URL is present, the leftmost
URL is the first URL that must be visited to reach the target 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 resource. (The path list can contain multiple URLs to allow for the
deployment of gateways or relays in the future.) MSRP deployment of gateways or relays in the future.) MSRP
implementations which can accept incoming connections will typically implementations which can accept incoming connections will typically
only provide a single URL here. only provide a single URL here.
skipping to change at page 24, line 40 skipping to change at page 24, line 11
This approach does not allow for specifying distinct lists of This approach does not allow for specifying distinct lists of
acceptable wrapped types for different types of containers. If an acceptable wrapped types for different types of containers. If an
endpoint understands a MIME type in the context of one wrapper, it is endpoint understands a MIME type in the context of one wrapper, it is
assumed to understand it in the context of any other acceptable assumed to understand it in the context of any other acceptable
wrappers, subject to any constraints defined by the wrapper types wrappers, subject to any constraints defined by the wrapper types
themselves. themselves.
The approach of specifying types that are only allowed inside of The approach of specifying types that are only allowed inside of
containers separately from the primary payload types allows an containers separately from the primary payload types allows an
endpoint to force the use of certain wrappers. For example, a endpoint to force the use of certain wrappers. For example, a
CPIM [14] gateway device may require all messages to be wrapped CPIM [13] 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.
All types listed in either the accept-types or An endpoint MAY indicate the maximim size message they wish to
accept-wrapped-types attributes MAY include a max-size parameter, receive using the max-size a-line attribute Max-size refers to the
indicating the largest message it is willing to accept of that complete message, not the size of any one chunk. Senders SHOULD
type. Max-size refers to the complete message, not the size of NOT exceed the max-size limit for any message sent in the
any one chunk. Senders MUST NOT exceed the max-size limit, if resulting session. However, the receiver should consider max-size
any, when sending messages of any listed type. If a type is value as a hint.
listed without the parameter, then no preset size limit exists.
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 = ctype [SEMI max-size] format-entry = (type "/" subtype) / (type "/" "*") / ("*")
ctype = (type "/" subtype) / (type "/" "*") / ("*")
type = token type = token
subtype = token subtype = token
max-size = "max" "=" 1*(DIGIT)
max-size = max-size-label ":" max-size-value
max-size-label = "max-size"
max-size-value = 1*(DIGIT)
7.1.1 URL Negotiations 7.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)
skipping to change at page 26, line 12 skipping to change at page 25, line 33
m=message 9 msrp * m=message 9 msrp *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrp://a.example.com:7394/2s93i;tcp a=path:msrp://a.example.com:7394/2s93i;tcp
The rightmost URI in the path attribute MUST identify the endpoint The rightmost URI in the path attribute MUST identify the endpoint
that generated the SDP document, or some other location where that that generated the SDP document, or some other location where that
endpoint wishes to receive requests associated with the session. It endpoint wishes to receive requests associated with the session. It
MUST be assigned for this particular session, and MUST NOT duplicate MUST be assigned for this particular session, and MUST NOT duplicate
any URI in use for any other session in which the endpoint is any URI in use for any other session in which the endpoint is
currently participating. It SHOULD be hard to guess, and protected currently participating. It SHOULD be hard to guess, and protected
from eavesdroppers. This is discussed in more detail in Section 14. from eavesdroppers. This is discussed in more detail in Section 13.
7.1.2 Path Attributes with Multiple URLs 7.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
document must include a few assumptions about how relays work. document must include a few assumptions about how relays work.
skipping to change at page 28, line 40 skipping to change at page 28, line 12
suggest that MSRP endpoints using SIP signaling SHOULD allow a mode suggest that MSRP endpoints using SIP signaling SHOULD allow a mode
where the endpoint quietly accepts the session, and begins displaying where the endpoint quietly accepts the session, and begins displaying
messages. messages.
SIP INVITE requests may be forked by a SIP proxy, resulting in more SIP INVITE requests may be forked by a SIP proxy, resulting in more
than one endpoint receiving the same INVITE. SIP early media [28] than one endpoint receiving the same INVITE. SIP early media [28]
techniques can be used to establish a preliminary session with each techniques can be used to establish a preliminary session with each
endpoint, and canceling the INVITE transaction for any endpoints that endpoint, and canceling the INVITE transaction for any endpoints that
do not send MSRP traffic after some period of time. do not send MSRP traffic after some period of time.
8. DSN payloads in MSRP REPORT Requests 8. Formal Syntax
The format of a default REPORT request payload format the DSN taken
from RFC1894 [8]. Only a minimal subset of fields are relevant for
MSRP, as detailed in the remainder of this section.
8.1 Per-Message DSN header usage
original-envelope-id: See Section 8.3
reporting-mta: See Section 8.4
dsn-gateway: Not Used
received-from-mta: Not Used
arrival-date: Not Used
8.2 Per-Recipient DSN header usage
original-recipient Not Used
final-recipient: See Section 8.5
action: See Section 8.6
status: See Section 8.7
remote-mta: Not Used
diagnostic-code: Not Used
last-attempt-date: Not Used
will-retry-until:Not Used
8.3 original-envelope-id usage
The 'original-envelope-id' field contains a unique identifier which
is used to correlate a DSN report with the originating MSRP
transaction. The entity generating the DSN report MUST insert the
Message-ID value that appeared in the original MSRP request into the
'original-envelope-id' field. This allows a requesting client to
explicitly correlate a REPORT request with the original request.
This correlation is implementation specific and makes no requirements
on clients to hold state for transactions ID's. Information
regarding the original request can be obtained from the DSN MIME type
outlined in [8].
8.4 reporting-mta
The 'reporting-mta-field' MUST follow the guidelines set out in RFC
1894[8]. The 'mta-name-type' from RFC1894[8] MUST use the value of
'msrp-name-type', as defined in Section 15.4 of this specification.
The 'mta-name' value for this field as specified in RFC1894 [8] MUST
equal the MSRP URL representing itself in the context of the session.
8.5 final-recipient
The 'final-recipient-field' MUST follow the guidelines set out in RFC
1894[8]. The 'address-type' from RFC1894 [8] MUST use the value of
'msrp-address-type', as defined in Section 15.4 of this
specification. The 'address-type' value for this field as specified
in RFC1894 [8] MUST equal the final value contained in the MSRP
'To-Path' header from the original request.
8.6 action
The 'action' field MUST follow the guidelines set out in RFC 1894[8].
An MSRP entity constructing a DSN report MUST use the 'delivered'
value for a successful delivery and MUST use the 'failed' value for
an unsuccessful delivery. The other values specified for the
'action' field in RFC 1894[8] MAY be used.
8.7 status
The 'status' field MUST follow the guidelines set out in RFC 1894[8].
An MSRP entity constructing a DSN report MUST represent the MSRP
status code in the correct format detailed in RFC 1894[8] for the
'status' field of a DSN report. An MSRP status code consists of a
three digit number while a DSN status is three digits separated by
'.'. An example would be:
Status: 5.0.0 (unknown permanent failure)
When generating this field the first digit of the MSRP status code
(working from left to right) MUST be placed in the first part of the
'status' DSN field. The second digit MUST be placed in the second
part of the 'status' DSN field. The third digit MUST be placed in
the third part of the 'status' DSN field. An example of a DSN
'status' field value would be:
An MSRP '200' success response would be mapped to:
Status: 2.0.0 (OK)
The MSRP reason phrase mapped to a DSN 'status' field MAY be enclosed
in parentheses if required.
9. Formal Syntax MSRP is a text protocol that uses the UTF-8 [15] transformation
format.
The following syntax specification uses the augmented Backus-Naur The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [6]. Form (BNF) as described in RFC-2234 [6].
msrp-req-or-resp = msrp-request / msrp-response msrp-req-or-resp = msrp-request / msrp-response
msrp-request = req-start headers [content-stuff] end-line msrp-request = req-start headers [content-stuff] end-line
msrp-response = resp-start headers end-line msrp-response = resp-start headers end-line
req-start = pMSRP SP transact-id SP method CRLF req-start = pMSRP SP transact-id SP method CRLF
resp-start = pMSRP SP transact-id SP status-code [SP phrase] CRLF resp-start = pMSRP SP transact-id SP status-code [SP phrase] CRLF
phrase = utf8text phrase = utf8text
pMSRP = %4d.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 = %53.45.4e.44 ; SEND in caps mSEND = %53.45.4e.44 ; SEND in caps
mREPORT = %52.45.50.4f.52.54; REPORT in caps mREPORT = %52.45.50.4f.52.54; REPORT in caps
other-method = 1*UPALPHA other-method = 1*UPALPHA
status-code = 3DIGIT status-code = 3DIGIT
headers = 1*( header CRLF ) headers = 1*( header CRLF )
header = ( To-Path header = ( To-Path
/ From-Path / From-Path
/ Message-ID / Message-ID
/ Report-Success / Report-Success
/ Report-Failure / Report-Failure
/ Byte-Range / Byte-Range
/ Status / Status
/ Mime-Header
/ ext-header ) / ext-header )
To-Path = "To-Path:" SP URL *( SP URL ) To-Path = "To-Path:" SP URL *( SP URL )
From-Path = "From-Path:" SP URL *( SP URL ) From-Path = "From-Path:" SP URL *( SP URL )
Message-ID = "Message-ID:" SP ident Message-ID = "Message-ID:" SP ident
Report-Success = "Report-Success:" SP ("yes" / "no" ) Report-Success = "Report-Success:" SP ("yes" / "no" )
Report-Failure = "Report-Failure:" SP ("yes" / "no" / "partial" ) Report-Failure = "Report-Failure:" 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 short-status [SP text-reason] dUmMy= "Status:" SP namespace SP short-status [SP text-reason]
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*(alphanum / "-" / "." / "!" / "%" token = 1*(%x21 / %xx23-27 / %x2A-2B / %x2D-2E
/ "*" / "_" / "+" / %x30-39 / %x41-5A / %x5E-7E)
quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE
qdtext = SP / HT / %x21 / %x23-5B / %x5D-7E qdtext = SP / HT / %x21 / %x23-5B / %x5D-7E
/ UTF8-NONASCII / UTF8-NONASCII
qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE) qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE)
BACKSLASH = "\" BACKSLASH = "\"
DQUOTE = %x22 DQUOTE = %x22
CRLF = %x0D.0A
HT = %x09
SP = %x20
UPALPHA = %x41-5A
LOWALPHA = %x61-7A
DIGIT = %x30-39
ALPHANUM = LOWALPHA / UPALPHA / DIGIT
Other-Mime-Header = (Content-ID Other-Mime-Header = (Content-ID
/ Content-Description / Content-Description
/ Content-Disposition / Content-Disposition
/ mime-extension-field); / mime-extension-field);
; Content-ID, and Content-Description are defined in RFC2045. ; Content-ID, and Content-Description are defined in RFC2045.
; Content-Disposition is defined in RFC2183 ; Content-Disposition is defined in RFC2183
; MIME-extension-field indicates additional MIME extension ; MIME-extension-field indicates additional MIME extension
; headers as described in RFC2045 ; headers as described in RFC2045
data = *OCTET data = *OCTET
end-line = "-------" transact-id continuation-flag CRLF end-line = "-------" transact-id continuation-flag CRLF
continuation-flag = "+" / "$" continuation-flag = "+" / "$" / "#"
ext-header = hname ":" SP hval CRLF ext-header = hname ":" SP hval CRLF
hname = alpha *token hname = alpha *token
hval = utf8text hval = utf8text
utf8text = *(HT / %x20-7E / UTF8-NONASCII) utf8text = *(HT / %x20-7E / UTF8-NONASCII)
UTF8-NONASCII = %xC0-DF 1UTF8-CONT UTF8-NONASCII = %xC0-DF 1UTF8-CONT
/ %xE0-EF 2UTF8-CONT / %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT / %xF0-F7 3UTF8-CONT
/ %xF8-Fb 4UTF8-CONT / %xF8-Fb 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT / %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF UTF8-CONT = %x80-BF
10. Response Code Descriptions 9. Response Code Descriptions
This section summarizes the semantics of various response codes that This section summarizes the semantics of various response codes that
may be used in MSRP transaction responses. These codes may also be may be used in MSRP transaction responses. These codes may also be
used in the Status header in REPORT requests. used in the Status header in REPORT requests.
10.1 200 9.1 200
The 200 response code indicates a successful transaction. The 200 response code indicates a successful transaction.
10.2 400 9.2 400
A 400 response indicates a request was unintelligible. A 400 response indicates a request was unintelligible.
10.3 403 9.3 403
The action is not allowed The action is not allowed
10.4 415 9.4 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 9.5 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 9.6 481
A 481 response indicates that no session exists for the connection. A 481 response indicates that no session exists for the connection.
10.7 506 9.7 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 10. Examples
11.1 Basic IM session 10.1 Basic IM session
This section shows an example flow for the most common scenario. The This section shows an example flow for the most common scenario. The
example assumes SIP is used to transport the SDP exchange. Details example assumes SIP is used to transport the SDP exchange. Details
of the SIP messages and SIP proxy infrastructure are omitted for the of the SIP messages and SIP proxy infrastructure are omitted for the
sake of brevity. In the example, assume the offerer is sake of brevity. In the example, assume the offerer is
sip:alice@example.com and the answerer is sip:bob@example.com. sip:alice@example.com and the answerer is sip:bob@example.com.
Alice Bob Alice Bob
| | | |
| | | |
|(1) (SIP) INVITE | |(1) (SIP) INVITE |
|----------------------->| |----------------------->|
|(4) (SIP) 200 OK | |(2) (SIP) 200 OK |
|<-----------------------| |<-----------------------|
|(5) (SIP) ACK | |(3) (SIP) ACK |
|----------------------->| |----------------------->|
|(6) (MSRP) SEND | |(4) (MSRP) SEND |
|----------------------->| |----------------------->|
|(7) (MSRP) 200 OK | |(5) (MSRP) 200 OK |
|<-----------------------| |<-----------------------|
|(8) (MSRP) SEND | |(6) (MSRP) SEND |
|<-----------------------| |<-----------------------|
|(9) (MSRP) 200 OK | |(7) (MSRP) 200 OK |
|----------------------->| |----------------------->|
|(10) (SIP) BYE | |(8) (SIP) BYE |
|----------------------->| |----------------------->|
|(11) (SIP) 200 OK | |(9) (SIP) 200 OK |
|<-----------------------| |<-----------------------|
| | | |
| | | |
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
skipping to change at page 34, line 44 skipping to change at page 32, line 19
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 9 msrp *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrp://alicepc.example.com:7777/iau39;tcp a=path:msrp://alicepc.example.com:7777/iau39;tcp
2. Bob listens on port 8888, and sends the following response: 2. Bob listens on port 8888, and sends the following response:
3. 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 9 msrp *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrp://bob.example.com:8888/9di4ea;tcp a=path:msrp://bob.example.com:8888/9di4ea;tcp
4. Alice->Bob (SIP): ACK 3. Alice->Bob (SIP): ACK
5. (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
Message-ID: 12339sdqwer Message-ID: 12339sdqwer
Content-Type:text/plain Content-Type:text/plain
Hi, I'm Alice! Hi, I'm Alice!
-------d93kswow$ -------d93kswow$
6. Bob->Alice (MSRP): 5. Bob->Alice (MSRP):
MSRP d93kswow 200 OK MSRP d93kswow 200 OK
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
-------d93kswow$ -------d93kswow$
7. Bob->Alice (MSRP): 6. Bob->Alice (MSRP):
MSRP dkei38sd SEND MSRP dkei38sd SEND
To-Path:msrp://alice.example.com:7777/iau39;tcp To-Path:msrp://alice.example.com:7777/iau39;tcp
From-Path:msrp://bob.example.com:8888/9di4ea;tcp From-Path:msrp://bob.example.com:8888/9di4ea;tcp
Message-ID: 456 Message-ID: 456
Content-Type:text/plain Content-Type:text/plain
Hi, Alice! I'm Bob! Hi, Alice! I'm Bob!
-------dkei38sd$ -------dkei38sd$
8. Alice->Bob (MSRP): 7. Alice->Bob (MSRP):
MSRP dkei38sd 200 OK MSRP dkei38sd 200 OK
To-Path:msrp://alice.example.com:7777/iau39;tcp To-Path:msrp://alice.example.com:7777/iau39;tcp
From-Path:msrp://bob.example.com:8888/9di4ea;tcp From-Path:msrp://bob.example.com:8888/9di4ea;tcp
-------dkei38sd$ -------dkei38sd$
9. Alice->Bob (SIP): BYE 8. Alice->Bob (SIP): BYE
Alice invalidates local session state. Alice invalidates local session state.
10. Bob invalidates local state for the session. 9. Bob invalidates local state for the session.
Bob->Alice (SIP): 200 OK Bob->Alice (SIP): 200 OK
11.2 Chunked Message 10.2 Chunked Message
For an example of a chunked message, see the example in Section 4.1. For an example of a chunked message, see the example in Section 4.1.
11.3 System Message 10.3 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 Report-Failure: no
Report-Success: no Report-Success: no
Content-Type:text/plain Content-Type:text/plain
The system is going down in 5 minutes This conference will end in 5 minutes
-------d93kswow$ -------d93kswow$
11.4 Positive Report 10.4 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 Report-Success: yes
Content-Type:text/html Content-Type:text/html
skipping to change at page 37, line 32 skipping to change at page 34, line 32
Bob->Alice (MSRP): Bob->Alice (MSRP):
MSRP d93kswow 200 OK MSRP d93kswow 200 OK
To-Path:msrp://alicepc.example.com:7777/iau39;tcp To-Path:msrp://alicepc.example.com:7777/iau39;tcp
From-Path:msrp://bob.example.com:8888/9di4ea;tcp From-Path:msrp://bob.example.com:8888/9di4ea;tcp
-------d93kswow$ -------d93kswow$
Bob->Alice (MSRP): Bob->Alice (MSRP):
MSRP dkei38sd SEND MSRP dkei38sd REPORT
To-Path:msrp://alicepc.example.com:7777/iau39;tcp To-Path:msrp://alicepc.example.com:7777/iau39;tcp
From-Path:msrp://bob.example.com:8888/9di4ea;tcp From-Path:msrp://bob.example.com:8888/9di4ea;tcp
Message-ID: 12339sdqwer Message-ID: 12339sdqwer
Status: 000 200 OK Status: 000 200 OK
-------dkei38sd$ -------dkei38sd$
11.5 Forked IM 10.5 Forked IM
Traditional IM systems generally do a poor job of handling multiple Traditional IM systems generally do a poor job of handling multiple
simultaneous IM clients online for the same person. While some do a simultaneous IM clients online for the same person. While some do a
better job than many existing systems, handling of multiple clients better job than many existing systems, handling of multiple clients
is fairly crude. This becomes a much more significant issue when is fairly crude. This becomes a much more significant issue when
always-on mobile devices are available, but when it is desirable to always-on mobile devices are available, but when it is desirable to
use them only if another IM client is not available. use them only if another IM client is not available.
Using SIP makes rendezvous decisions explicit, deterministic, and Using SIP makes rendezvous decisions explicit, deterministic, and
very flexible; instead "pager-mode" IM systems use implicit very flexible; instead "pager-mode" IM systems use implicit
skipping to change at page 38, line 33 skipping to change at page 35, line 33
From: Juliet <sip:juliet@thecapulets.example.com>;tag=12345 From: Juliet <sip:juliet@thecapulets.example.com>;tag=12345
Call-ID: 09887877 Call-ID: 09887877
CSeq: 772 REGISTER CSeq: 772 REGISTER
The Response contains her Contacts: The Response contains her Contacts:
SIP/2.0 200 OK SIP/2.0 200 OK
To: Juliet <sip:juliet@thecapulets.example.com> To: Juliet <sip:juliet@thecapulets.example.com>
From: Juliet <sip:juliet@thecapulets.example.com>;tag=12345 From: Juliet <sip:juliet@thecapulets.example.com>;tag=12345
Call-ID: 09887877 Call-ID: 09887877
CSeq: 771 REGISTER CSeq: 772 REGISTER
Contact: <sip:juliet@balcony.thecapulets.example.com> Contact: <sip:juliet@balcony.thecapulets.example.com>
;q=0.9;expires=3600 ;q=0.9;expires=3600
Contact: <sip:juliet@chamber.thecapulets.example.com> Contact: <sip:juliet@chamber.thecapulets.example.com>
;q=1.0;expires=3600 ;q=1.0;expires=3600
Contact: <sip:jcapulet@veronamobile.example.net>;q=0.4;expires=3600 Contact: <sip:jcapulet@veronamobile.example.net>;q=0.4;expires=3600
Contact: <sip:nurse@thecapulets.example.com>;q=0.1;expires=3600 Contact: <sip:nurse@thecapulets.example.com>;q=0.1;expires=3600
When Romeo opens his IM program, he selects Juliet and types the When Romeo opens his IM program, he selects Juliet and types the
message "art thou hither?" (instead of "you there?"). His client message "art thou hither?" (instead of "you there?"). His client
sends a SIP invitation to sip:juliet@thecapulets.example.com. The sends a SIP invitation to sip:juliet@thecapulets.example.com. The
Proxy there tries first the balcony and the chamber simultaneously. Proxy there tries first the balcony and the chamber simultaneously.
A client is running on both those systems, both of which setup early A client is running on both those systems, both of which setup early
sessions of MSRP with Romeo's client. The client automatically sends sessions of MSRP with Romeo's client. The client automatically sends
the message over the MSRPS to the two MSPR URIs involved. After a the message over the MSRPS to the two MSRP URIs involved. After a
delay of a several seconds with no reply or activity from Juliet, the delay of a several seconds with no reply or activity from Juliet, the
proxy cancels the invitation at her first two contacts, and forwards proxy cancels the invitation at her first two contacts, and forwards
the invitation on to Juliet's PDA. Since her father is talking to the invitation on to Juliet's PDA. Since her father is talking to
her about her wedding, she selects "Do Not Disturb" on her PDA, which her about her wedding, she selects "Do Not Disturb" on her PDA, which
sends a "Busy Here" response. The proxy then tries the Nurse, who sends a "Busy Here" response. The proxy then tries the Nurse, who
answers and tells Romeo what is going on. answers and tells Romeo what is going on.
Romeo Juliet's Juliet/ Juliet/ Juliet/ Nurse Romeo Juliet's Juliet/ Juliet/ Juliet/ Nurse
Proxy balcony chamber PDA Proxy balcony chamber PDA
skipping to change at page 40, line 10 skipping to change at page 37, line 10
|<--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 tommorrow.... |
12. Extensibility 11. 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. mechanism to require or discover new features. If a
non-interoperable update or extension occurs in the future, it will
be treated as a new protocol, and must describe how its use will be
signaled.
In order to allow extension header fields without breaking
interoperablility, if an MSRP device receives a request or response
containing a header field that it does not understand, it MUST ignore
the header field and process the request or response as if the header
field was not present.
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 12. CPIM compatibility
MSRP sessions may be gatewayed to other CPIM [25]compatible MSRP sessions may be gatewayed to other CPIM [25]compatible
protocols. If this occurs, the gateway MUST maintain session state, protocols. If this occurs, the gateway MUST maintain session state,
and MUST translate between the MSRP session semantics and CPIM and MUST translate between the MSRP session semantics and CPIM
semantics that do not include a concept of sessions. Furthermore, semantics that 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" [7] bodies. Such a gateway MUST SHOULD be wrapped in "message/cpim" [7] bodies. Such a gateway MUST
include "message/cpim" as the first entry in its SDP accept-types include "message/cpim" as the first entry in its SDP accept-types
attribute. MSRP endpoints sending instant messages to a peer that attribute. MSRP endpoints sending instant messages to a peer that
has included 'message/cpim" as the first entry in the accept-types has included 'message/cpim" as the first entry in the accept-types
attribute SHOULD encapsulate all instant message bodies in "message/ attribute SHOULD encapsulate all instant message bodies in "message/
cpim" wrappers. All MSRP endpoints MUST support the message/cpim cpim" wrappers. All MSRP endpoints MUST support the message/cpim
type, and SHOULD support the S/MIME features of that format. type, and SHOULD support the S/MIME features of that format.
14. Security Considerations If a message is to be wrapped in a message/cpim envelope, the
wrapping MUST be done prior to breaking the message into chuncks, if
needed.
13. 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
skipping to change at page 42, line 29 skipping to change at page 39, line 42
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 TLS is used to authenticate devices and to provide integrity and
confidentiality for the headers being transported. MSRP elements confidentiality for the headers being transported. MSRP elements
MUST implement TLS and MUST also implement the TLS MUST implement TLS and MUST also implement the TLS
ClientExtendedHello extended hello information for server name ClientExtendedHello extended hello information for server name
indication as described in [12]. A TLS cipher-suite of indication as described in [11]. A TLS cipher-suite of
TLS_RSA_WITH_AES_128_CBC_SHA [15] MUST be supported (other TLS_RSA_WITH_AES_128_CBC_SHA [14] MUST be supported (other
cipher-suites MAY also be supported). cipher-suites MAY also be supported).
Since MSRP carries arbitrary MIME content, it can trivially carry S/ Since MSRP carries arbitrary MIME content, it can trivially carry S/
MIME protected messages as well. All MSRP implementations MUST MIME protected messages as well. All MSRP implementations MUST
support the multipart/signed MIME type even if they do not support S/ 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 MIME. Since SIP can carry a session key, S/MIME messages in the
context of a session could also be protected using a key-wrapped context of a session could also be protected using a key-wrapped
shared secret [26] provided in the session setup. shared secret [26] provided in the session setup.
15. IANA Considerations 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
needed.
15.1 MSRP Port 14. IANA Considerations
14.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 5 Section 5
15.2 MSRP URL Schemes 14.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 5. Syntax See Section 5.
Character Encoding See Section 5. Character Encoding See Section 5.
Intended Usage See Section 5. Intended Usage See Section 5.
Protocols The Message Session Relay Protocol (MSRP). Protocols The Message Session Relay Protocol (MSRP).
Security Considerations See Section 14. Security Considerations See Section 13.
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 14.3 SDP Parameters
This document registers the following SDP parameters in the This document registers the following SDP parameters in the
sdp-parameters registry: sdp-parameters registry:
15.3.1 Accept Types 14.3.1 Accept Types
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 7.1. Purpose and Appropriate Values See Section 7.1.
15.3.2 Wrapped Types 14.3.2 Wrapped Types
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 7.1. Purpose and Appropriate Values See Section 7.1.
15.3.3 Path 14.3.3 Max Size
Attribute-name: max-size
Long-form Attribute Name Maximum message size.
Type: Media level
Subject to Charset Attribute No
Purpose and Appropriate Values See Section 7.1.
14.3.4 Path
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 7.1.1. Purpose and Appropriate Values See Section 7.1.1.
15.4 IANA registration forms for DSN types 15. Change History
15.4.1 IANA registration form for address-type
This document registers a new 'address-type' for use in conjunction
with RFC1894[8]. The authors request that these values be recorded
in the IANA registry for DSN 'address-type'.
Proposed Address name: msrp-address-type
Syntax: See Section 5
15.4.2 IANA registration form for MTA-name-type
This document registers a new 'MTA-name-type' for use in conjunction
with RFC1894[8]. The authors request that these values be recorded
in the IANA registry for DSN 'MTA-name-type'.
Proposed Address name: msrp-name-type
Syntax: See Section 5 15.1 draft-ietf-simple-message-sessions-08
16. Change History Removed DSN section. Removed statements that an error report
SHOULD contain a body. REPORT requests may now contain
informational bodies no larger than 2K, but the recipient is free
to ignore them.
Added the "#" value for the continuation-flag to indicate the last
chunk of an abandoned message.
Added direction that s/mime and cpim envelops must be applied
before chunking.
Added direction to set the last-byte field in byte-range to "*" if
there is any chance of interrupting a SEND request.
Changed max-size to refer to entire message, instead of a
particular MIME content-type
Added requirent for the use of UTF-8, and reference to RFC3629
Added requrement to ignore unknown headers.
Several ABNF fixes
Removed redundant material between normative sections.
Numerous editorial fixes.
16.1 draft-ietf-simple-message-sessions-07 15.2 draft-ietf-simple-message-sessions-07
Significant re-write to attempt to improve readability. Significant re-write to attempt to improve readability.
Added maximum size parameter in accept-types Added maximum size parameter in accept-types
Changed the Boundary field to be part of the start-line rather Changed the Boundary field to be part of the start-line rather
than a header field. than a header field.
Removed the TR-IDheader, and changed request-response matching to 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.
Removed transport selection from URL scheme and added the "tcp" Removed transport selection from URL scheme and added the "tcp"
parameter. parameter.
Added description of the "simple" mode with no transaction Added description of the "simple" mode with no transaction
responses, and made mode selection dependent on the reporting responses, and made mode selection dependent on the reporting
level requested for a give message. level requested for a give message.
Changed the DSN section to reflect separate request of success and Changed the DSN section to reflect separate request of success and
failure reports. Enhanced REPORT method to be useful even without failure reports. Enhanced REPORT method to be useful even without
a payload. a payload.
removed SRV usage for URL resolution. This is only used for relay 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.
skipping to change at page 44, line 44 skipping to change at page 42, line 22
a payload. a payload.
removed SRV usage for URL resolution. This is only used for relay 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.
Added discussion about late REPORT handling. Asserted that REPORT Added discussion about late REPORT handling. Asserted that REPORT
requests are always sent in simple mode. requests are always sent in simple mode.
Removed the dependency on multipart/byteranges for fragmentation. 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.
Removed the VISIT method. Change to use SEND to serve the purpose Removed the VISIT method. Change to use SEND to serve the purpose
formerly reserved to VISIT. formerly reserved to VISIT.
16.2 draft-ietf-simple-message-sessions-06 15.3 draft-ietf-simple-message-sessions-06
Changed To and From header names to To-Path and From-Path. Added 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.
Changed mechanism for signaling transport and TLS protection into 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.
Removed length field from start line and added Boundary header Removed length field from start line and added Boundary header
field and Closing field. field and Closing field.
Added recommendation to fragment any content over 2k. Added recommendation to fragment any content over 2k.
Added Rohan's proposal to make offerer connect to answerer. (With Added Rohan's proposal to make offerer connect to answerer. (With
open issue for more discussion.) open issue for more discussion.)
Changed To-Path and From-Path usage in responses to indicate the 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.
Updated DSN section. Added text on field usage. Updated DSN section. Added text on field usage.
Fixed change TR-ID header from version 05 were erroneously Fixed change TR-ID header from version 05 were erroneously
skipping to change at page 45, line 17 skipping to change at page 42, line 41
Added recommendation to fragment any content over 2k. Added recommendation to fragment any content over 2k.
Added Rohan's proposal to make offerer connect to answerer. (With Added Rohan's proposal to make offerer connect to answerer. (With
open issue for more discussion.) open issue for more discussion.)
Changed To-Path and From-Path usage in responses to indicate the 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.
Updated DSN section. Added text on field usage. Updated DSN section. Added text on field usage.
Fixed change TR-ID header from version 05 were erroneously Fixed change TR-ID header from version 05 were erroneously
attributed to 04. attributed to 04.
16.3 draft-ietf-simple-message-sessions-05 15.4 draft-ietf-simple-message-sessions-05
Changed the use of session URLs. Instead of a single session URL, 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.
Changed the SDP exchange of MSRP URLs to handle the URL for each 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
skipping to change at page 45, line 29 skipping to change at page 43, line 4
Changed the use of session URLs. Instead of a single session URL, 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.
Changed the SDP exchange of MSRP URLs to handle the URL for each 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.
Added section for Delivery Status Notification handling, and added Added section for Delivery Status Notification handling, and added
associated entries into the syntax definition. associated entries into the syntax definition.
Added content fragmentation section. Added content fragmentation section.
Removed recommendation to start separate session for large Removed recommendation to start separate session for large
transfers. transfers.
Corrected some mistakes in the syntax definitions. Corrected some mistakes in the syntax definitions.
Added Chris Boulton as a co-author for his contribution of the DSN Added Chris Boulton as a co-author for his contribution of the DSN
text. text.
16.4 draft-ietf-simple-message-sessions-04 15.5 draft-ietf-simple-message-sessions-04
Removed the direction attribute. Rather than using a comedia 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.5 draft-ietf-simple-message-sessions-03 15.6 draft-ietf-simple-message-sessions-03
Removed all specification of relays, and all features specific to 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.
Removed text indicating that an endpoint could retry failed 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.
Added text describing subsequent SDP exchanges. Added mandatory 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.
Added text to describe the use of send and receive only indicators 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.
Added text requiring unique port field values if multiple M-line's Added text requiring unique port field values if multiple M-line's
skipping to change at page 46, line 18 skipping to change at page 43, line 42
end the session. end the session.
Added text describing subsequent SDP exchanges. Added mandatory 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.
Added text to describe the use of send and receive only indicators 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.
Added text requiring unique port field values if multiple M-line's Added text requiring unique port field values if multiple M-line's
exist. exist.
Corrected a number of editorial mistakes. Corrected a number of editorial mistakes.
16.6 draft-ietf-simple-message-sessions-02 15.7 draft-ietf-simple-message-sessions-02
Moved all content type negotiation from the "m"-line format list 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.
Added "other-method" construction to the message syntax to allow Added "other-method" construction to the message syntax to allow
for extensible methods. for extensible methods.
Consolidated all syntax definitions into the same section. 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.
Changed the session inactivity timeout to 12 minutes. Changed the session inactivity timeout to 12 minutes.
Required support for the SHA1 algorithm. Required support for the SHA1 algorithm.
Required support for the message/cpim format. Required support for the message/cpim format.
Fixed lots of editorial issues. Fixed lots of editorial issues.
Documented a number of open issues from recent list discussions. Documented a number of open issues from recent list discussions.
16.7 draft-ietf-simple-message-sessions-01 15.8 draft-ietf-simple-message-sessions-01
Abstract rewritten. Abstract rewritten.
Added architectural considerations section. Added architectural considerations section.
The m-line format list now only describes the root body part for a 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.
Added a standard dummy value for the m-line port field. Clarified 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.
Clarified that an endpoint is globally configured as to whether or 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 47, line 4 skipping to change at page 44, line 29
that a zero in this field has normal SDP meaning. that a zero in this field has normal SDP meaning.
Clarified that an endpoint is globally configured as to whether or 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
intrinsic to MSRP. intrinsic to MSRP.
Changed digest algorithm to SHA1. Added TR-ID and S-URI to the Changed digest algorithm to SHA1. Added TR-ID and S-URI to the
hash for digest authentication. hash for digest authentication.
CMS usage replaced with S/MIME. CMS usage replaced with S/MIME.
TLS and msrps: usage clarified. TLS and msrps: usage clarified.
Session state timeout is now based on SEND activity, rather than Session state timeout is now based on SEND activity, rather than
BIND and VISIT refreshes. BIND and VISIT refreshes.
Default port added. Default port added.
Added sequence diagrams to the example message flows. Added sequence diagrams to the example message flows.
Added discussion of self-signed certificates in the security Added discussion of self-signed certificates in the security
considerations section. considerations section.
16.8 draft-ietf-simple-message-sessions-00 15.9 draft-ietf-simple-message-sessions-00
Name changed to reflect status as a work group item. Name changed to reflect status as a work group item.
This version no longer supports the use of multiple sessions 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 URI, rather than a separate one for
each endpoint. The session URI is not required to be in requests each endpoint. The session URI 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.
BIND and VISIT now create soft state, eliminating the need for the BIND and VISIT now create soft state, eliminating the need for the
RELEASE and LEAVE methods. RELEASE and LEAVE methods.
skipping to change at page 47, line 36 skipping to change at page 45, line 12
Format list negotiation expanded to allow a "prefer these formats Format list negotiation expanded to allow a "prefer these formats
but try anything" semantic but try anything" semantic
Clarified handling of direction notification failures. Clarified handling of direction notification failures.
Clarified signaling associated with session failure due to dropped Clarified signaling associated with session failure due to dropped
connections. connections.
Clarified security related motivations for MSRP. Clarified security related motivations for MSRP.
Removed MIKEY dependency for session key exchange. Simple usage 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.9 draft-campbell-simple-im-sessions-01 15.10 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 16. Contributors and Acknowledgments
In addition to the editor, The following people contributed extensive In addition to the editors, The following people contributed
work to this document: Chris Boulton, Cullen Jennings, Paul Kyzivat, extensive work to this document: Chris Boulton, Paul Kyzivat, Orit
Rohan Mahy, Adam Roach, Jonathan Rosenberg, Robert Sparks. Levin, Adam Roach, Jonathan Rosenberg, and Robert Sparks.
The following people contributed substantial discussion and feedback The following people contributed substantial discussion and feedback
to this ongoing effort: Allison Mankin, Jon Peterson, Brian Rosen, to this ongoing effort: Eric Burger, Allison Mankin, Jon Peterson,
Dean Willis, Aki Niemi, Hisham Khartabil, Pekka Pessi, Orit Levin. Brian Rosen, Dean Willis, Aki Niemi, Hisham Khartabil, Pekka Pessi,
and Orit Levin.
18. References 17. References
18.1 Normative References 17.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", RFC
2246, January 1999. 2246, January 1999.
[2] Handley, M. and V. Jacobson, "SDP: Session Description [2] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
skipping to change at page 48, line 34 skipping to change at page 46, line 12
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[7] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging [7] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging
Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in
progress), January 2003. progress), January 2003.
[8] Moore, K. and G. Vaudreuil, "An Extensible Message Format for [8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Delivery Status Notifications", RFC 1894, January 1996.
[9] 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.
[10] Troost, R., Dorner, S. and K. Moore, "Communicating [9] 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.
[11] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform [10] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998. 1998.
[12] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and [11] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and
T. Wright, "Transport Layer Security (TLS) Extensions", RFC T. Wright, "Transport Layer Security (TLS) Extensions", RFC
3546, June 2003. 3546, June 2003.
[13] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE [12] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002. Method", RFC 3311, October 2002.
[14] Atkins, D. and G. Klyne, "Common Presence and Instant [13] Atkins, D. and G. Klyne, "Common Presence and Instant
Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-08 Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-08
(work in progress), January 2003. (work in progress), January 2003.
[15] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for [14] 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.
18.2 Informational References [15] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
3269, November 2003.
17.2 Informational References
[16] Johnston, A. and O. Levin, "Session Initiation Protocol Call [16] Johnston, A. and O. Levin, "Session Initiation Protocol Call
Control - Conferencing for User Agents", Control - Conferencing for User Agents",
draft-ietf-sipping-cc-conferencing-03 (work in progress), draft-ietf-sipping-cc-conferencing-03 (work in progress),
February 2004. February 2004.
[17] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo, [17] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo,
"Best Current Practices for Third Party Call Control in the "Best Current Practices for Third Party Call Control in the
Session Initiation Protocol", draft-ietf-sipping-3pcc-06 (work Session Initiation Protocol", draft-ietf-sipping-3pcc-06 (work
in progress), January 2004. in progress), January 2004.
skipping to change at page 50, line 31 skipping to change at page 48, line 9
(XMPP): Instant Messaging and Presence", draft-ietf-xmpp-im-22 (XMPP): Instant Messaging and Presence", draft-ietf-xmpp-im-22
(work in progress), April 2004. (work in progress), April 2004.
[30] Rosenberg, J., "Indicating User Agent Capabilities in the [30] Rosenberg, J., "Indicating User Agent Capabilities in the
Session Initiation Protocol (SIP)", Session Initiation Protocol (SIP)",
draft-ietf-sip-callee-caps-03 (work in progress), January 2004. draft-ietf-sip-callee-caps-03 (work in progress), January 2004.
Authors' Addresses Authors' Addresses
Ben Campbell (editor) Ben Campbell (editor)
Estacado Systems
EMail: ben@nostrum.com EMail: ben@nostrum.com
Rohan Mahy Rohan Mahy (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
5617 Scotts Valley Drive, Suite 200 5617 Scotts Valley Drive, Suite 200
Scotts Valley, CA 95066 Scotts Valley, CA 95066
USA USA
EMail: rohan@cisco.com EMail: rohan@cisco.com
Cullen Jennings
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
EMail: fluffy@cisco.com EMail: fluffy@cisco.com
Intellectual Property Statement Intellectual Property Statement
 End of changes. 

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