draft-ietf-simple-message-sessions-06.txt   draft-ietf-simple-message-sessions-07.txt 
SIMPLE WG B. Campbell, Ed.
SIMPLE Working Group B. Campbell (Ed.) Internet-Draft
Internet-Draft dynamicsoft Expires: January 16, 2005 R. Mahy
Expires: November 15, 2004 May 17, 2004 C. Jennings
Cisco Systems, Inc.
July 18, 2004
The Message Session Relay Protocol The Message Session Relay Protocol
draft-ietf-simple-message-sessions-06 draft-ietf-simple-message-sessions-07.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
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 November 15, 2004. This Internet-Draft will expire on January 16, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document describes the Message Session Relay Protocol (MSRP), a This document describes the Message Session Relay Protocol (MSRP), a
mechanism for transmitting a series of Instant Messages within a protocol for transmitting a series of related instant messages in the
session. MSRP sessions are managed using the Session Description context of a session. Message sessions are treated like any other
Protocol (SDP) offer/answer model carried by a signaling 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation for Session-mode Messaging . . . . . . . . . . . 4 2. Introduction and Background . . . . . . . . . . . . . . . . 4
3. Scope of this Document . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 6 4. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . 8
5. SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . . 7 4.1 MSRP Framing and Message Chunking . . . . . . . . . . . . 8
5.1 Use of the SDP M-line . . . . . . . . . . . . . . . . . . 7 4.2 MSRP Addressing . . . . . . . . . . . . . . . . . . . . . 11
5.2 The Accept Types Attribute . . . . . . . . . . . . . . . . 7 4.3 MSRP Transaction and Report Model . . . . . . . . . . . . 11
5.3 MIME Wrappers . . . . . . . . . . . . . . . . . . . . . . 8 4.4 MSRP Connection Model . . . . . . . . . . . . . . . . . . 12
5.4 URL Negotiations . . . . . . . . . . . . . . . . . . . . . 9 5. MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.5 Path Attributes with Multiple URLs . . . . . . . . . . . . 10 5.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 15
5.6 Updated SDP Offers . . . . . . . . . . . . . . . . . . . . 11 5.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 16
5.7 Example SDP Exchange . . . . . . . . . . . . . . . . . . . 11 6. Method-Specific Behavior . . . . . . . . . . . . . . . . . . 16
5.8 Connection Negotiation . . . . . . . . . . . . . . . . . . 12 6.1 Constructing Requests . . . . . . . . . . . . . . . . . . 16
6. The Message Session Relay Protocol . . . . . . . . . . . . . 12 6.1.1 Delivering SEND requests . . . . . . . . . . . . . . . 17
6.1 MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1.2 Sending REPORT requests . . . . . . . . . . . . . . . 19
6.1.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . 13 6.1.3 Failure REPORT Generation . . . . . . . . . . . . . . 19
6.1.2 Resolving MSRP Host Device . . . . . . . . . . . . . . 14 6.2 Constructing Responses . . . . . . . . . . . . . . . . . . 20
6.2 Connection Direction . . . . . . . . . . . . . . . . . . . 14 6.3 Receiving Requests . . . . . . . . . . . . . . . . . . . . 21
6.3 MSRP Messages . . . . . . . . . . . . . . . . . . . . . . 15 6.3.1 Receiving SEND requests . . . . . . . . . . . . . . . 21
6.3.1 Message Framing . . . . . . . . . . . . . . . . . . . 17 6.3.2 Receiving REPORT requests . . . . . . . . . . . . . . 22
6.3.2 Message Examples . . . . . . . . . . . . . . . . . . . 18 7. Using MSRP with SIP . . . . . . . . . . . . . . . . . . . . 22
6.4 MSRP Transactions . . . . . . . . . . . . . . . . . . . . 19 7.1 SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . 22
6.5 MSRP Sessions . . . . . . . . . . . . . . . . . . . . . . 19 7.1.1 URL Negotiations . . . . . . . . . . . . . . . . . . . 25
6.5.1 Initiating an MSRP session . . . . . . . . . . . . . . 19 7.1.2 Path Attributes with Multiple URLs . . . . . . . . . . 26
6.5.2 Handling the initial request . . . . . . . . . . . . . 21 7.1.3 Updated SDP Offers . . . . . . . . . . . . . . . . . . 27
6.5.3 Sending Instant Messages on a Session . . . . . . . . 21 7.1.4 Example SDP Exchange . . . . . . . . . . . . . . . . . 27
6.5.4 Ending a Session . . . . . . . . . . . . . . . . . . . 23 7.1.5 Connection Negotiation . . . . . . . . . . . . . . . . 28
6.5.5 Managing Session State and Connections . . . . . . . . 23 7.2 MSRP User Experience with SIP . . . . . . . . . . . . . . 28
6.6 Delivery Status Notification . . . . . . . . . . . . . . . 24 8. DSN payloads in MSRP REPORT Requests . . . . . . . . . . . . 28
6.6.1 Endpoint DSN Request . . . . . . . . . . . . . . . . . 24 8.1 Per-Message DSN header usage . . . . . . . . . . . . . . . 28
6.6.2 DSN generation . . . . . . . . . . . . . . . . . . . . 25 8.2 Per-Recipient DSN header usage . . . . . . . . . . . . . . 29
6.6.3 Receiving positive DSN . . . . . . . . . . . . . . . . 26 8.3 original-envelope-id usage . . . . . . . . . . . . . . . . 29
6.6.4 Receiving negative DSN . . . . . . . . . . . . . . . . 26 8.4 reporting-mta . . . . . . . . . . . . . . . . . . . . . . 29
6.6.5 DSN headers in MSRP . . . . . . . . . . . . . . . . . 26 8.5 final-recipient . . . . . . . . . . . . . . . . . . . . . 29
6.7 Message Fragmentation . . . . . . . . . . . . . . . . . . 28 8.6 action . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.7.1 MSRP Usage of message/byteranges . . . . . . . . . . . 28 8.7 status . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.8 Method Descriptions . . . . . . . . . . . . . . . . . . . 29 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 30
6.8.1 SEND . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. Response Code Descriptions . . . . . . . . . . . . . . . . . 32
6.8.2 VISIT . . . . . . . . . . . . . . . . . . . . . . . . 29 10.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.8.3 REPORT . . . . . . . . . . . . . . . . . . . . . . . . 30 10.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.9 Response Code Descriptions . . . . . . . . . . . . . . . . 30 10.3 403 . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.9.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . 30 10.4 415 . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.9.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . 30 10.5 426 . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.9.3 415 . . . . . . . . . . . . . . . . . . . . . . . . . 30 10.6 481 . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.9.4 426 . . . . . . . . . . . . . . . . . . . . . . . . . 30 10.7 506 . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.9.5 481 . . . . . . . . . . . . . . . . . . . . . . . . . 30 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.9.6 506 . . . . . . . . . . . . . . . . . . . . . . . . . 30 11.1 Basic IM session . . . . . . . . . . . . . . . . . . . . 33
6.10 Header Field Descriptions . . . . . . . . . . . . . . . 30 11.2 Chunked Message . . . . . . . . . . . . . . . . . . . . 36
6.10.1 TR-ID . . . . . . . . . . . . . . . . . . . . . . . 31 11.3 System Message . . . . . . . . . . . . . . . . . . . . . 36
6.10.2 Message-ID . . . . . . . . . . . . . . . . . . . . . 31 11.4 Positive Report . . . . . . . . . . . . . . . . . . . . 37
6.10.3 To-Path . . . . . . . . . . . . . . . . . . . . . . 31 11.5 Forked IM . . . . . . . . . . . . . . . . . . . . . . . 37
6.10.4 From-Path . . . . . . . . . . . . . . . . . . . . . 31 12. Extensibility . . . . . . . . . . . . . . . . . . . . . . . 40
6.10.5 Boundary . . . . . . . . . . . . . . . . . . . . . . 31 13. CPIM compatibility . . . . . . . . . . . . . . . . . . . . . 40
6.10.6 Closing . . . . . . . . . . . . . . . . . . . . . . 31 14. Security Considerations . . . . . . . . . . . . . . . . . . 40
6.10.7 Content-Type . . . . . . . . . . . . . . . . . . . . 32 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 42
7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 32 15.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . 42
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34 15.2 MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . 42
8.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 34 15.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . 43
8.2 MSRP URL Schema . . . . . . . . . . . . . . . . . . . . . 34 15.3.1 Accept Types . . . . . . . . . . . . . . . . . . . . 43
8.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . 34 15.3.2 Wrapped Types . . . . . . . . . . . . . . . . . . . 43
8.2.2 Character Encoding . . . . . . . . . . . . . . . . . . 34 15.3.3 Path . . . . . . . . . . . . . . . . . . . . . . . . 43
8.2.3 Intended Usage . . . . . . . . . . . . . . . . . . . . 35 15.4 IANA registration forms for DSN types . . . . . . . . . 43
8.2.4 Protocols . . . . . . . . . . . . . . . . . . . . . . 35 15.4.1 IANA registration form for address-type . . . . . . 43
8.2.5 Security Considerations . . . . . . . . . . . . . . . 35 15.4.2 IANA registration form for MTA-name-type . . . . . . 44
8.2.6 Relevant Publications . . . . . . . . . . . . . . . . 35 16. Change History . . . . . . . . . . . . . . . . . . . . . . . 44
8.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 35 16.1 draft-ietf-simple-message-sessions-07 . . . . . . . . . 44
8.3.1 Accept Types . . . . . . . . . . . . . . . . . . . . . 35 16.2 draft-ietf-simple-message-sessions-06 . . . . . . . . . 44
8.3.2 Wrapped Types . . . . . . . . . . . . . . . . . . . . 35 16.3 draft-ietf-simple-message-sessions-05 . . . . . . . . . 45
8.3.3 Path . . . . . . . . . . . . . . . . . . . . . . . . . 35 16.4 draft-ietf-simple-message-sessions-04 . . . . . . . . . 45
8.4 IANA registration forms for DSN types . . . . . . . . . . 36 16.5 draft-ietf-simple-message-sessions-03 . . . . . . . . . 45
8.4.1 IANA registration form for address-type . . . . . . . 36 16.6 draft-ietf-simple-message-sessions-02 . . . . . . . . . 46
8.4.2 IANA registration form for MTA-name-type . . . . . . . 36 16.7 draft-ietf-simple-message-sessions-01 . . . . . . . . . 46
9. Security Considerations . . . . . . . . . . . . . . . . . . 36 16.8 draft-ietf-simple-message-sessions-00 . . . . . . . . . 47
9.1 TLS and the MSRPS Scheme . . . . . . . . . . . . . . . . . 36 16.9 draft-campbell-simple-im-sessions-01 . . . . . . . . . . 47
9.1.1 Sensitivity of Session URLs . . . . . . . . . . . . . 37 17. Contributors and Acknowledgments . . . . . . . . . . . . . . 47
9.1.2 End to End Protection of IMs . . . . . . . . . . . . . 38 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
9.1.3 CPIM compatibility . . . . . . . . . . . . . . . . . . 38 18.1 Normative References . . . . . . . . . . . . . . . . . . . 48
9.1.4 PKI Considerations . . . . . . . . . . . . . . . . . . 38 18.2 Informational References . . . . . . . . . . . . . . . . . 49
10. Changes from Previous Draft Versions . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 50
10.1 draft-ietf-simple-message-sessions-06 . . . . . . . . . 39 Intellectual Property and Copyright Statements . . . . . . . 52
10.2 draft-ietf-simple-message-sessions-05 . . . . . . . . . 39
10.3 draft-ietf-simple-message-sessions-04 . . . . . . . . . 40
10.4 draft-ietf-simple-message-sessions-03 . . . . . . . . . 40
10.5 draft-ietf-simple-message-sessions-02 . . . . . . . . . 40
10.6 draft-ietf-simple-message-sessions-01 . . . . . . . . . 41
10.7 draft-ietf-simple-message-sessions-00 . . . . . . . . . 41
10.8 draft-campbell-simple-im-sessions-01 . . . . . . . . . . 42
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
13.1 Normative References . . . . . . . . . . . . . . . . . . . 42
13.2 Informational References . . . . . . . . . . . . . . . . . 43
Author's Address . . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . 45
1. Introduction
The MESSAGE [12] extension to SIP [2] allows SIP to be used to
transmit instant messages. Instant messages sent using the MESSAGE
method are normally independent of each other. This approach is
often called page-mode messaging, since it follows a model similar to
that used by many two-way pager devices. Page-mode messaging makes
sense for instant message exchanges where a small number of messages
occur. Endpoints may treat page-mode messages as if they took place
in an imaginative session, but there is no formal relationship
between one message and another.
There are also applications in which it is useful for instant
messages to be formally associated in a session. For example, a user
may wish to join a text conference, participate in the conference for
some period of time, then leave the conference. This usage is
analogous to regular media sessions that are typically initiated,
managed, and terminated using SIP. We commonly refer to this model
as session-mode messaging.
One of the primary purposes of SIP and SDP (Section 5) is the
management of media sessions. Session-mode messaging can be thought
of as a media session like any other. This document describes the
motivations for session-mode messaging, the Message Session Relay
Protocol, and the use of the SDP offer/answer mechanism for managing
MSRP session.
2. Motivation for Session-mode Messaging
Message sessions offer several advantages over page-mode messages.
For message exchanges that include more than a small number of
message transactions, message sessions offer a way to remove
messaging load from intervening SIP proxies. For example, a minimal
session setup and tear-down requires one INVITE/ACK transaction, and
one BYE transaction, for a total of 5 SIP messages. Normal SIP
request routing allows for all but the initial INVITE transaction to
bypass any intervening proxies that do not specifically request to be
in the path for future requests. Session-mode messages never cross
the SIP proxies themselves.
Each page-mode message involves a complete SIP transaction, that is,
a request and a response. Any page-mode message exchange that
involves more than 2 MESSAGE requests will generate more SIP requests
than a minimal session initiation sequence. Since MESSAGE is
normally used outside of a SIP dialog, these requests will typically
traverse the entire proxy network between the endpoints.
Due to network congestion concerns, the MESSAGE method has
significant limitations in message size, a prohibition against
overlapping requests, etc. Much of this has been required because of
perceived limitations in the congestion-avoidance features of SIP
itself. Work is in progress to mitigate these concerns.
However, session-mode messages are always sent over reliable,
congestion-safe transports. Therefore, there are no restrictions on
message sizes. There is no requirement to wait for acknowledgement
before sending another message, so that message transactions can be
overlapped.
Message sessions allow greater efficiency for secure message
exchanges. The SIP MESSAGE request inherits the S/MIME features of
SIP, allowing a message to be signed and/or encrypted. However, this
approach requires public key operations for each message. With
session-mode messaging, a session key can be established at the time
of session initiation. This key can be used to protect each message
that is part of the session. This requires only symmetric key
operations for each subsequent IM, and no additional certificate
exchanges are required after the initial exchange. The establishment
of the session key can be done using standard techniques that apply
to voice and video, in addition to instant messaging.
Finally, SIP devices can treat message sessions like any other media
sessions. Any SIP feature that can be applied to other sorts of
media sessions can equally apply to message sessions. For example,
conferencing [14], third party call control [15], call transfer [16],
QoS integration [17], and privacy [18] can all be applied to message
sessions.
Messaging sessions can also reduce the overhead in each individual
message. In page-mode, each message needs to include all of the SIP
headers that are mandated by RFC 3261 [2]. However, many of these
headers are not needed once a context is established for exchanging
messages. As a result, messaging session mechanisms can be designed
with significantly less overhead.
3. Scope of this Document
This document describes the use of MSRP between endpoints. It does 1. Conventions
not specify the use of intermediaries, nor does it prohibit such use.
We expect an extension to this specification to define MSRP
intermediaries and their use.
This document describes the use of MSRP over TCP. MSRP may be used The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
over other congestion-controlled protocols such as SCTP. However, "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
the specific bindings for other such protocols are outside the scope document are to be interpreted as described in RFC-2119 [5].
of this document.
4. Protocol Overview This document consistently refers to a "message" as a complete unit
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
the complete message is called a "chunk".
The Message Session Relay Protocol (MSRP) provides a mechanism for 2. Introduction and Background
transporting session-mode messages between endpoints. MSRP uses
connection oriented, reliable network transport protocols only. It
can operate in the presence of many NAT and firewall environments, as
it allows participants to positively associate message sessions with
specific connections, and does not depend upon connection source
address, which may be obscured by NATs.
MSRP uses the following primitives: A series of related textual messages between two or more parties can
be viewed as part of a session with a definite start and end. This
is in contrast to individual messages each sent completely
independently. The SIMPLE Working Group describes messaging schemes
that only track individual messages as "page-mode" messages, whereas
messaging that is part of a "session" with a definite start and end
is called session-mode messaging.
SEND: Used to send message content from one endpoint to another. Page-mode messaging is enabled in SIMPLE via the SIP [4]MESSAGE
method [19]. Session-mode messaging has a number of benefits [20]
over page-mode messaging however, such as explicit rendezvous,
tighter integration with other media types, direct client-to-client
operation, and brokered privacy and security.
VISIT: Used by an endpoint to establish a session association to the This document defines a session-oriented instant message transport
host endpoint. protocol (MSRP), whose sessions can be included in an offer or answer
[3] of a session description (for example, SDP [2]). The exchange is
carried by some signaling protocol, such as SIP [4]. This allows a
communication user agent to offer a messaging session as one of the
possible media types in a session. For instance, Alice may want to
communicate with Bob. Alice doesn't know at the moment whether Bob
has his phone or his IM client handy, but she's willing to use
either. She sends an invitation to a session to the address of
record she has for Bob, sip:bob@example.com. Her invitation offers
both voice and an IM session. The SIP services at example.com
forward the invitation to Bob at his currently registered clients.
Bob accepts the invitation at his IM client and they begin a threaded
chat conversation.
REPORT Used to carry MSRP message report/receipt information. This session model allows message sessions to be integrated into
advanced communications applications with little to no additional
protocol development. For example, during the above chat session,
Bob decides Alice really needs to be talking to Carol. Bob can
transfer [18] Alice to Carol, introducing them into their own
messaging session. Messaging sessions can then be easily integrated
into call-center and dispatch environments utilizing third-party call
control [17] and conferencing [16] applications.
Assume A is an endpoint that wishes to establish a message session, 3. Protocol Overview
and B is the endpoint invited by A. A invites B to participate in a
message session by sending a URL. This URL is temporary, and must
not duplicate any URL that A has offered for other active sessions.
B then responds to the invitation with a URL of its own. This MSRP is a text-based, connection-oriented protocol for exchanging
informs A that B has accepted the session, and will accept messages arbitrary (binary) MIME content, especially instant messages. This
at that URL. A connects to B, and sends a request to establish the section is a non-normative overview of how MSRP works and how it is
session. A and B may now exchange messages using SEND requests on used with SIP.
the connection. Each party targets such requests to the peer's URL.
When either party wishes to end the session, it informs its peer MSRP sessions are typically arranged using SIP the same way a session
using the appropriate mechanism of the chosen signaling protocol, of audio or video media is setup. One SIP user agent (Alice) sends
such as a SIP BYE request. the other (Bob) a SIP invitation containing an offer
session-description which includes a session of MSRP. The receiving
SIP user agent can accept the invitation and include an answer
session-description which acknowledges the choice of media. Alice's
session description contains an MSRP URL that describes where she is
willing to receive MSRP requests from Bob, and vice-versa. (Note:
Some lines in the examples are removed for clarity and brevity.)
Alice sends to Bob:
The end to end case looks something like the following. (Note that INVITE sip:alice@atlanta.example.com SIP/2.0
the example shows a logical flow only; syntax will come later in this To: <sip:bob@biloxi.example.com>
document.) From: <sip:alice@atlanta.example.com>;tag=786
Call-ID: 3413an89KU
Content-Type: application/sdp
A->B (SDP): offer (msrp://A/123) c=IN IP4 10.1.1.1
B->A (SDP): answer(msrp://B/456) m=message 9 msrp *
A->B (TCP) connect a=accept-types:text/plain
A->B (MSRP): SEND (msrp://B/456) a=path:msrp://atlanta.example.com:7654/jshA7we;tcp
B->A (MSRP): 200 OK
B->A (MSRP): SEND (msrp://A/123)
A->B (MSRP): 200 OK
5. SDP Offer-Answer Exchanges for MSRP Sessions Bob sends to Alice:
MSRP sessions will typically be initiated using the Session SIP/2.0 200 OK
Description Protocol (SDP) [1] offer-answer mechanism, carried in the To: <sip:bob@biloxi.example.com>;tag=087js
Session Initiation Protocol (SIP) [2] or any other protocol From: <sip:alice@atlanta.example.com>;tag=786
supporting it. Call-ID: 3413an89KU
Content-Type: application/sdp
5.1 Use of the SDP M-line c=IN IP4 10.2.2.2
m=message 9 msrp *
a=accept-types:text/plain
a=path:msrp://biloxi.example.com:12763/kjhd37s2s2;tcp
The SDP "m"-line takes the following form: Alice sends to Bob:
m=<media> <port> <protocol> <format list> ACK sip:alice@atlanta.example.com SIP/2.0
To: <sip:bob@biloxi.example.com>;tag=087js
From: <sip:alice@atlanta.example.com>;tag=786
Call-ID: 3413an89KU
For non-RTP media sessions, The media field specifies the top level MSRP defines two request types, or methods. SEND requests are used
MIME media type for the session. For MSRP sessions, the media field to deliver a complete message or a chunk (a portion of a complete
MUST have the value of "message". The port field is normally not message), while REPORT requests report on the status of an earlier
used, and MAY be set to any value chosen by the endpoint. A port SEND request. When Alice receives Bob's answer, she checks to see if
field value of zero has the standard SDP meaning. Non-zero values she has an existing connection to Bob. If not, she opens a new
MUST not be repeated in other MSRP m-lines in the same SDP document. connection to Bob using the URL he provided in the SDP. Alice then
delivers a SEND request to Bob with her initial message, and Bob
replies indicating that Alice's request was received successfully.
The protocol field is used only to designate MSRP. The underlying MSRP a786hjs2 SEND
transport protocol is determined in the MSRP URL, as described below. To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp
Therefore, the protocol field MUST take the value of "msrp". From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp
Message-ID: 87652
Content-Type: text/plain
The format list list is ignored for MSRP. This is because MSRP Hey Bob, are you there?
formats are specified as MIME content types, which are not convenient -------a786hjs2$
to encode in the SDP format list syntax. Instead, the allowed
formats are negotiated using "a"-line attributes. For MSRP sessions,
the format list SHOULD contain a "*" character, and nothing else.
The port field in the M-line is not used to determine the port to MSRP a786hjs2 200 OK
which to connect. Rather, the actual port is determined by the the To-Path: msrp://atlanta.example.com:7654/jshA7we;tcp
MSRP URL (Section 6.1) in the path attribute. However, a port value From-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp
of zero has the normal SDP meaning. Message-ID: 87652
-------a786hjs2$
The following example illustrates an m-line for a message session, Alice's request begins with the MSRP start line, which contains a
where the endpoint is willing to accept root payloads of message/ transaction identifier that is also used as a final boundary marker.
cpim, plain text or HTML. The second two types could either be Next she includes the path of URLs to the destination in the To-Path
presented as the root body, or could be contained within message/cpim header, and her own URL in the From-Path header. In this typical
bodies. case there is just one "hop", so there is only one URL in each path
header field. She also includes a message ID which she can use to
correlate responses and status reports with the original message.
Next she puts the actual content. Finally she closes the request
with an end line: seven hyphens, the transaction identifier /
boundary marker and a "$" to indicate this request contains the end
of a complete message.
m=message 9999 msrp * If Alice wants to deliver a very large message, she can split the
message into chunks and deliver each chunk in a separate SEND
request. The message ID corresponds to the whole message, so the
receiver can also use it to reassemble the message and tell which
chunks belong with which message. Chunking is described in more
detail in Section 4.1.
5.2 The Accept Types Attribute Alice can also specify what type of reporting she would like in
response to her request. If Alice requests positive
acknowledgements, Bob sends a REPORT request to Alice confirming the
delivery of her complete message. This is especially useful if Alice
sent a series of SEND request containing chunks of a single message.
More on requesting types of reports and errors is described in
Section 4.3.
MSRP can carry any MIME encoded payload. Endpoints specify MIME Alice and Bob generally choose their MSRP URLs in such a way that is
content types that they are willing to receive in the accept types difficult to guess the exact URL. Alice and Bob can reject requests
"a"-line attribute. This attribute has the following syntax: to URLs they are not expecting to service, and can correlate the
specific URL with the probable sender. Alice and Bob can also use
TLS [1] to provide channel security over this hop. To receive MSRP
requests over a TLS protected connection, Alice or Bob could
advertise URLs with the "msrps" scheme instead of "msrp."
accept-types = accept-types-label ":" format-list This document specifies MSRP behavior only peer-to-peer session, that
accept-types-label = "accept-types" is, for a single hop. But is designed with the expectation that MSRP
format-list = format-entry *( SP can carry URLs for nodes on the far side of gateways or relays. For
format-entry) format-entry = (type "/" subtype) / ("*") this reason, a URL with the "msrps" scheme makes no assertion about
type = token the security properties of other hops, just the next hop.
subtype = token
SDP offers for MSRP sessions MUST include an accept-types attribute. MSRP URLs are discussed in more detail in Section 5.
SDP answers MUST also include the attribute, which MUST contain
either the same list as in the offer or a subset of that list.
A "*" entry in the accept-types attribute indicates that the sender An adjacent pair of busy MSRP nodes (for example two gateways) can
may attempt to send messages with media types that have not been easily have several sessions, and exchange traffic for several
explicitly listed. If the receiver is able to process the media simultaneous users. The nodes can use existing connections to carry
type, it does so. If not, it will respond with a 415. Note that all new traffic with the same destination host, port, transport protocol,
explicit entries SHOULD be considered preferred over any non-listed and scheme. MSRP nodes can keep track of how many sessions are using
types. This feature is needed as, otherwise, the list of formats for a particular connection and close these connections when no sessions
rich IM devices may be prohibitively large. have used them for some period of time. Connection management is
discussed in more detail in Section 4.4.
The accept-types attribute may include container types, that is, mime 4. Key Concepts
formats that contain other types internally. If compound types are
used, the types listed in the accept-types attribute may be used both
as the root payload, or may be wrapped in a listed container type.
(Note that the container type MUST also be listed in the accept-types
attribute.)
5.3 MIME Wrappers 4.1 MSRP Framing and Message Chunking
The MIME content-types in the accept-types attribute will often Messages sent using MSRP can be very large and can be delivered in
include container types; that is, types that contain other types. several SEND requests, where each SEND request contains one chunk of
For example, "message/cpim" or "multipart/mixed." Occasionally an the overall message. To support this, MSRP uses a boundary based
endpoint will need to specify a MIME body type that can only be used framing mechanism. The header of an MSRP request contains a unique
if wrapped inside a listed container type. boundary string that is used to indicate the end of the request.
Following the boundary string at the end of the body data, there is a
flag that indicates whether this is the last chunk of data for this
message or whether the message will be continued in a subsequent
chunk. There is also a Byte-Range header in the request that
indicates the overall position of this chunk inside the complete
message.
Endpoints MAY specify MIME types that are only allowed to be wrapped For example, the following snippet of two SEND requests demonstrates
inside compound types using the "accept-wrapped-types" attribute in a message that contains the text "abcdEFGH" being sent as two chunks.
an SDP a-line. This attribute has the following syntax:
accept-wrapped-types = wrapped-types-label ":" format-list MSRP dkei38sd SEND
wrapped-types-label = "accept-wrapped-types" ` Message-ID: 456
Byte-Range: 1-4/8
Content-Type: "text/plain"
The format-list element has the identical syntax as defined for the abcd
accept-types attribute. The semantics for this attribute are -------dkei38sd+
identical to those of the accept-types attribute, with the exception
that the specified types may only be used when wrapped inside
containers. Only types listed in accept-types may be used as the
"root" type for the entire body. Since any type listed in
accept-types may be used both as a root body, and wrapped in other
bodies, format entries from the m-line SHOULD NOT be repeated in this
attribute.
This approach does not allow for specifying distinct lists of MSRP dkei38ia SEND
acceptable wrapped types for different types of containers. If an Message-ID: 456
endpoint understands a MIME type in the context of one wrapper, it is Byte-Range: 5-8/8
assumed to understand it in the context of any other acceptable Content-Type: "text/plain"
wrappers, subject to any constraints defined by the wrapper types
themselves.
The approach of specifying types that are only allowed inside of EFGH
containers separately from the primary payload types allows an -------dkei38ia$
endpoint to force the use of certain wrappers. For example, a
CPIM gateway device may require all messages to be wrapped inside
message/cpim bodies, but may allow several content types inside
the wrapper. If the gateway were to specify the wrapped types in
the accept-types attribute, its peer could choose to use those
types without the wrapper.
5.4 URL Negotiations 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.
Each endpoint in an MSRP session is identified by a URL. These URLs The boundary marker that terminates the body MUST be preceded by a
are negotiated in the SDP exchange. Each SDP offer or answer MUST CRLF that is not part of the body and then seven "-" (minus sign)
contain one or more MSRP URL in a path attribute. This attribute has characters. After the boundary marker, there MUST be a flag
the following syntax: 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 "+".
a=path ":" MSRP_URL *(SP MSRP_URL) 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-*/*".
where MSRP_URL is an MSRP or MSRPS URL as defined in Section 6.1. This chunking mechanism allows a sender to interrupt a chunk part way
MSRP URLs included in an SDP offer or answer MUST include an explicit through sending it by writing out the boundary termination and the
port number. "+" flag to indicate that the end of this chunk is not the end of the
complete message. The ability to interrupt messages allows multiple
sessions to share a TCP connection, and for large messages to be sent
efficiently while not blocking other messages that share the same
connection.
A device uses the URL to determine a host address and port when To insure fairness over a connection, senders MUST NOT send chunks
connecting, and to identify the target when sending messages. For with a body larger than 2048 octets unless they are prepared to
MSRP sessions, the address field in the C-line is not relevant, and interrupt them. A sender can use one of the following two strategies
MUST be ignored. The port field in the M-line MUST be ignored if to satisfy this requirement. The sender is STRONGLY RECOMMENDED to
non-zero. Zero values have the usual meaning for SDP. 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 device will further use the URL to determine the transport Receivers MUST not assume the chunks will be delivered in order or
protocol, and whether to use TLS. This information is encoded in the that they will receive all the chunks with "+" flags before they
URL scheme. 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.
Both offerer and answerer store the path values received from the The seven "-" before the boundary are used so that the receiver can
peer. For a given endpoint, the local URL is the URL that the search for the value "----", 32 bits at a time to find the probable
endpoint put into a SDP path attribute to represent itself. The peer location of the boundary. This allows most processors to locate the
URL is the URL sent by the peer to represent itself. If the path boundaries and copy the memory at the same rate that a normal memory
attribute received from the peer contains more than one URL, then the copy could be done. This approach results in a system that is as
peer URL is the rightmost, while the leftmost entry represents the fast as framing based on specifying the body length in the headers of
adjacent hop. If only one entry is present, then it is both the peer the request, but also allows for the interruption of messages.
and adjacent URL. The remote path is the entire path attribute value
received from the peer.
The following example shows an SDP offer with a session URL of The ability to interrupt messages is needed so that TCP connections
"msrp://a.example.com:7394/2s93i" can be shared. Connection sharing is necessary for "fair" allocation
of bandwidth in congestion situations and for allowing MSRP network
elements that have a very large number of concurrent connections to
different users.
v=0 4.2 MSRP Addressing
o=someuser 2890844526 2890844527 IN IP4 alice.example.com
s=
c=IN IP4 alice.example.com m=message 9999 msrp *
a=accept-types:text/plain
a=path:msrp://a.example.com:7394/2s93i
The rightmost URI in the path attribute MUST identify the endpoint MSRP entities are addressed using URLs. The MSRP URL schemes are
that generated the SDP document, or some other location where that defined in Section 5. The syntax of the To-Path and From-Path
endpoint wishes to receive messages associated with the session. It headers allow for a list of URLs. This was done to allow the
MUST MUST be a temporary URL assigned just for this particular protocol to work with gateways or relays defined in the future, to
session, and MUST NOT duplicate any URL in use for any other session provide a complete path to the end recipient. When two MSRP nodes
in which the endpoint is currently participating. Further, it SHOULD communicate directly they need only one URL in the To-Path list and
be hard to guess, and protected from eavesdroppers. This will be one URL in the From-Path list.
discussed in more detail in Section 9.
5.5 Path Attributes with Multiple URLs 4.3 MSRP Transaction and Report Model
As mentioned previously, this document describes MSRP for A sender sends MSRP requests to a receiver. The receiver MUST
peer-to-peer scenarios, that is, when no relays are used. However, quickly accept or reject the request. If the receiver initially
we expect a separate document to describe the use of relays in the accepted the request, it still may then do things that take
near future. In order to allow an MSRP device that only implements significant time to succeed or fail. For example, if the receiver is
the core specification to interoperate with devices that use relays, an MSRP to XMPP [29] gateway, it may forward the message over XMPP.
this document must include a few assumptions about how relays work. The XMPP side may later indicate that the request did not work. At
this point, the MSRP receiver may need to indicate that the request
did not succeed. There are two important concepts here: first, the
hop by hop delivery of the request may succeed or fail; second, the
end result of the request may be successfully processed or not. The
first type of status is referred to as "transaction status" and may
be returned in response to a request. The second type of status is
referred to as "request status" and may be returned in a REPORT
transaction.
An endpoint that uses one or more relays will indicate that by The original sender of a request can indicate if they wish to receive
putting a URL for each device in the relay chain into the SDP path reports for requests that fail, and can independently indicate if
attribute. The final entry would point to the endpoint itself. The they wish to receive reports for requests that succeed. A receiver
other entries would indicate each proposed relay, in order. The only sends a success REPORT if it knows that the request succeeded,
first entry would point to the first relay in the chain; that is, the and the sender requested a success report. A receiver only sends a
relay to which the peer device, or a relay operation on its behalf, failure REPORT if the request failed and the sender requested failure
should connect. reports.
Endpoints that do not wish to insert a relay, including those that do This document describes the behavior of MSRP endpoints. MSRP
not support relays at all, will put exactly one URL into the path relays or gateways are likely to have additional conditions that
attribute. This URL represents both the endpoint for the session, indicate a failure REPORT should be sent, such as the failure to
and the connection point. receive a positive response from the next hop.
While endpoints that implement only this specification will never Two header fields control the sender's desire to receive reports.
introduce a relay, they will need to be able to interoperate with The header "Report-Success" can have a value of "yes" or "no" and the
other endpoints that do use relays. Therefore, they MUST be prepared "Report-Failure" header can have a value of "yes", "no", or
to receive more than one URL in the SDP path attribute. When an "partial".
endpoint receives more than one URL in a path header, only the first
entry is relevant for purposes of resolving the address and port, and
establishing the network connection, as it describes the first
adjacent hop.
If an endpoint puts more than one URL in a path attribute, the final If the value of "Report-Failure" is set to "yes", then the sender of
URL in the path (the peer URL) attribute MUST exhibit the uniqueness the request runs a timer. If a 200 response to the transaction is
properties described above. Uniqueness requirements for other not received within 30 seconds from the time the last byte of the
entries in the attribute are out of scope for this document. 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.
5.6 Updated SDP Offers Similarly if the value of the Report-Success header is "yes", then
the receiving node MUST send a "success" REPORT after the request is
complete to indicate that the request succeeded. Likewise if the
value is "no", it MUST NOT send a success REPORT.
To do: Revisit this section based on new connection management rules 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.
MSRP endpoints may sometimes need to send additional SDP exchanges If no Report-Success header is present in a SEND request, it MUST be
for an existing session. They may need to send periodic exchanges treated the same as a Report-Success header with value of "no". If
with no change to refresh state in the network, for example, SIP no Report-Failure header is present, it MUST be treated the same as a
timers. They may need to change some other stream in a session Report-Failure header with value of "yes". REPORT requests MUST have
without affecting the MSRP stream, or they may need to change an MSRP the same Message-ID header value as the request they are reporting
stream without affecting some other stream. 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.
If either party wish to send an SDP document that changes nothing at Report-Success and Report-Failure MUST NOT be present in a REPORT
all, then it MUST have the same o-line version as in the previous request. MSRP nodes MUST NOT send REPORT requests in response to
exchange. report requests. MSRP Nodes MUST NOT send MSRP responses to REPORT
requests.
5.7 Example SDP Exchange 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.
Endpoint A wishes to invite Endpoint B to a MSRP session. A offers 4.4 MSRP Connection Model
the following session description:
v=0 When MSRP wishes to send a request to a peer identified by an MSRP
o=usera 2890844526 2890844527 IN IP4 alice.example.com URL, it first needs a connection, with the appropriate security
s= properties, to the host specified in the URL. If the sender already
c=IN IP4 alice.example.com t=0 0 has such a connection, that is, one associated with the same host,
m=message 9999 msrp * port, and URL scheme, then it SHOULD reuse that connection.
a=accept-types: message/cpim text/plain text/html
a=path:msrp://alice.example.com:7394/2s93i9
B responds with its own URL: When a new MSRP session is created, the convention is that the
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
content.
v=0 When a new connection needs to be formed, the element looks at the
o=userb 2890844530 2890844532 IN IP4 bob.example.com URL to decide on the type of connection (TLS, TCP, etc.) then
s= connects to the host indicated by the URL, following the URL
c=IN IP4 dontlookhere resolution rules in Section 5.2. For connections using the msrps:
t=0 0 scheme, the SubjectAltName in the received certificate MUST match the
m=message 9999 msrp * hostname port of the URL and the certificate MUST be valid, including
a=accept-types:message/cpim text/plain having a date that is valid and being signed by an acceptable
a=path:msrp://bob.example.com:8493/si438ds certificate authority. At this point the device that initiated the
connection can assume that this connection is with the correct host.
A immediately sends some MSRP traffic: Either a VISIT request (if it If the connection used mutual TLS authentication, and the TLS client
has no immediate content to send) or a SEND request (if it does have presented a valid certificate, then the element accepting the
immediate content.) Afterwards, A and B may now exchange IMs by connection can know the identity of the connecting host. When mutual
executing SEND transactions. TLS authentication is not used, the listening device MUST wait until
it receives a request on the connection to determine the identity of
the connecting device.
5.8 Connection Negotiation When the first request arrives, it's To-Path header field should
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
in the received request, and determines which session it matches. If
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
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
on another connection. If so, it MUST reject the request with a 506
response.
Previous versions of this document included a mechanism to negotiate If it were legal to have multiple connections associated with the
the direction for any required TCP connection. The mechanism was same session, a security problem would exist. If the initial SEND
loosely based on COMEDIA [20]work being done in the MMUSIC working request is not protected, an eavesdropper might learn the URL, and
group. The primary motivation was to allow MSRP sessions to succeed use it to insert messages into the session via a different
in situations where the offerer could not accept connections but the connection.
answerer could. For example, the offerer might be behind a NAT,
while the answerer might have a globally routable address.
The SIMPLE working group chose to remove that mechanism from MSRP, as If a connection fails for any reason, then an MSRP endpoint MUST
it added a great deal of complexity to connection management. consider failed any sessions associated with the connection as well.
Instead, MSRP now specifies default connection directions. When an endpoint notices such a failure, it SHOULD attempt to
re-create any such sessions using a new SDP exchange. If a
replacement session is successfully created, endpoints MAY attempt to
resend any content for which delivery on the original session could
not be confirmed. If it does this, the Message-ID values for the
resent messages MUST match those used in the initial attempts. If
the receiving endpoint receives more than one message with the same
Message-ID. It SHOULD assume that the messages are duplicates. It
MAY take any action based on that knowledge, but SHOULD NOT present
the duplicate messages to the user without warning of the duplicates.
6. The Message Session Relay Protocol 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
replacement session.
The Message Session Relay Protocol (MSRP) is a text based, message When endpoints create a new session in this fashion, the chunks for a
oriented protocol for the transfer of instant messages in the context given logical message MAY be split across the sessions. However,
of a session. MSRP uses the UTF8 character set. endpoints SHOULD NOT split chunks between sessions under normal
circumstances.
MSRP messages MUST be sent over a reliable, congestion-controlled, If a connection fails, the sender SHOULD attempt to re-setup the URL
connection-oriented transport protocol. This document specifies the path using a new offer, for example, in a SIP re-invite or update
use of MSRP over TCP. Other documents may specify bindings for other [13]. It MUST not assume that the new URLs in the SDP will be the
such protocols. same as the old ones. A connection SHOULD not be closed while there
are sessions that are using this connection.
6.1 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 [4], with a scheme of "msrp": RFC2396 [11], with a scheme of "msrp" or "msrps":
msrp_url = msrp-scheme "://" [userinfo "@"] hostport ["/" MSRP_urls = msrp-scheme "://" [userinfo "@"] hostport ["/"
resource] resource] ";" transport
msrp-scheme = "msrp" / "msrps" / "smsrp" / "smsrps" msrp-scheme = "msrp" / "msrps"
resource = 1*unreserved resource = 1*unreserved
transport = "tcp" / token
The constructions for "userinfo", "hostport", and "unreserved" are The constructions for "userinfo", "hostport", and "unreserved" are
detailed in RFC2396 [4]. detailed in RFC2396 [11]. URLs designating MSRP over TCP MUST
include the "tcp" parameter. If some other transport is used, the
"tcp" parameter MUST NOT be present.
Since this document only specifies MSRP over TCP, all MSRP URLs
herein use the "tcp" parameter. Documents that provide bindings
on other transports should define respective parameters for those
transports. A MSRP URL with multiple, contradictory transports is
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. An MSRP URL server part identifies a participant in an MSRP session.
If the server part contains a numeric IP address, it MUST also If the server part 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.
The underlying transport protocol and the protection level (that is, A scheme of "msrps" indicates the underlying connection MUST be
whether TLS is used) is determined by the URL scheme: protected with TLS.
msrp MSRP over TCP without TLS.
msrps MSRP over TCP with TLS.
smsrp MSRP over SCTP without TLS.
smsrps MSRP over SCTP with TLS.
This document only describes the binding for MSRP over TCP. The
schema for SCTP are reserved herein, but binding MSRP to SCTP is
out of scope for this document.
MSRP has an IANA registered recommended port defined in Section 8.1. MSRP has an IANA registered recommended port defined in Section 15.1.
This value is not a default, as the URL process described herein will This value is not a default, as the URL negotiation process described
always explicitly resolve a port number. However, the URLs SHOULD be herein will always include explicit port numbers. However, the URLs
configured so that the recommended port is used whenever appropriate. SHOULD be configured so that the recommended port is used whenever
This makes life easier for network administrators who need to manage appropriate. This makes life easier for network administrators who
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, MUST be constructed only itself. If a userinfo component exists, it MUST be constructed only
from "unreserved" characters, to avoid a need for escape processing. from "unreserved" characters, to avoid a need for escape processing.
Escaping MUST NOT be used in an MSRP URL. Furthermore, a userinfo Escaping MUST NOT be used in an MSRP URL. Furthermore, a userinfo
part MUST NOT contain password information. part MUST NOT contain password information.
The following is an example of a typical MSRP URL: The following is an example of a typical MSRP URL:
msrp://host.example.com:8493/asfd34 msrp://host.example.com:8493/asfd34;tcp
6.1.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 schema must match exactly. 1. The scheme must match exactly.
2. The host part is compared as case insensitive. 2. The host part is compared as case insensitive.
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 insensitive. A URL without 4. The resource part is compared as case sensitive. A URL without a
a resource part is never equivalent to one that includes a resource part is never equivalent to one that includes a resource
resource part. part.
5. Userinfo parts are not considered for URL comparison. 5. URLs with different "transport" parameters never match. Two URLs
that are identical except for transport are not equivalent.
6. Userinfo parts are not considered for URL comparison.
Path normalization is not relevant for MSRP URLs. Escape Path normalization is not relevant for MSRP URLs. Escape
normalization is not required, since the relevant parts are limited normalization is not required, since the relevant parts are limited
to unreserved characters. to unreserved characters.
6.1.2 Resolving MSRP Host Device 5.2 Resolving MSRP Host Device
An MSRP host device is identified by the server part of an MSRP URL. An MSRP host device is identified by the server part of an MSRP URL.
If the server part contains a numeric IP address and port, they MUST If the server part contains a numeric IP address and port, they MUST
be used as listed. be used as listed.
If the server part contains a host name and a port, the connecting If the server part contains a host name and a port, the connecting
device MUST determine a host address by doing an A or AAAA DNS query, device MUST determine a host address by doing an A or AAAA DNS query,
and use the port as listed. and use the port as listed.
skipping to change at page 14, line 38 skipping to change at page 16, line 34
order the records were presented. order the records were presented.
This process assumes that the connection port is always known This process assumes that the connection port is always known
prior to resolution. This is always true for the MSRP URL uses prior to resolution. This is always true for the MSRP URL uses
described in this document, that is, URLs always created and described in this document, that is, URLs always created and
consumed by automata, rather than by humans. The introduction of consumed by automata, rather than by humans. The introduction of
relays may create situations where this is not the case. For relays may create situations where this is not the case. For
example, the MSRP URL that a user enters into a client to example, the MSRP URL that a user enters into a client to
configure it to use a relay may be intended to be easily configure it to use a relay may be intended to be easily
remembered and communicated by humans, and therefore is likely to remembered and communicated by humans, and therefore is likely to
omit the port. Therefore, the relay specification may describe omit the port. Therefore, the relay specification [21] may
additional steps to resolve the port number. describe additional steps to resolve the port number.
6.2 Connection Direction
When SIP is used as the signaling protocol, the device sending the
initial request to communicate is responsible for opening the
connection. In most cases, the device sends an offer in an INVITE or
UPDATE request, and gets a response in a 2xx or 18x response. In
this case, the inviter opens a connection after receiving the
response. This can be done in parallel to sending an ACK request.
Another, less common scenario is when the inviter sends an INVITE
request with no offer, and the invitee sends an offer in the
response. In this case, the inviter opens the connection after it
receives the offer. It waits for successful connection prior to
sending the answer in the SIP ACK request.
Open Issue: The delayed offer is not likely to work in SIP, as the
invitee is almost certainly to propose RTP rather than MSRP. We
either need to do more work to specify how an endpoint that
supports both handles a delayed offer, or remove any reference to
this.
Other signaling protocols may use other approaches. Unless specific
behavior is specified for a particular signaling protocol, the
offerer is always responsible for opening the connection.
Open Issue: Should we put in a hook to allow SDP extensions to be
used to determine connection direction? For example, if COMEDIA
evolves to a point where it is workable for MSRP, why not allow
using it?
In all cases, the connecting endpoint connects to the device and port
indicated by the connection URL, using the protocol and protection
level specified by the URL scheme. If it determines that it already
has a connection associated with a URL that has a matching scheme,
host part, and port, it SHOULD reuse that connection rather than
opening a new one. Once a connection has succeeded, or the decision
to reuse a connection has been made, the connecting device MUST
immediately send an MSRP request in the context of the new session.
This message allows the device accepting the connection to associate
the MSRP session with the connection. This MAY be a SEND request, if
the device has content to send immediately, or a VISIT request.
Open Issue: We are still discussing whether the offerer or the
answerer should be responsible for connecting.
Either endpoint MAY tear down a connection when it no longer has any
active or proposed sessions associated with the connection.
6.3 MSRP Messages
MSRP messages are either requests or responses. Requests and
responses are distinguished from one another by the first line. The
first line of a Request takes the form of the request-start entry
below. Likewise, the first line of a response takes the form of
response-start. The syntax for an MSRP message is as follows:
msrp-message = request-start/response-start *(header CRLF)
[CRLF body] Closing
request-start = "MSRP" SP Method CRLF
response-start = "MSRP" SP Status-Code SP
Reason CRLF
Method = SEND / VISIT / other-method
other-method = 1*(ALPHA)
header = Tran-ID / Message-ID/ Session-URL / Content-Types /
From-Path / To-Path / Message-Receipt / Receipt-ID /
Byte-Range / Boundary
Status-Code = 200 ;Success MSRP devices MAY use other methods for discovering other such
/ 400 ;Bad Request devices, when appropriate. For example, MSRP endpoints may use other
/ 403 ;Forbidden mechanisms to discover relays, which are beyond the scope of this
/ 415 ;Unsupported Content Type document.
/ 426 ;Upgrade Required
/ 481 ;No session
/ 506 ;duplicate session
/ other-status ; extension codes
other-status = 3(NUM)
Reason = token ; Human readable text describing status 6. Method-Specific Behavior
Tran-ID = "Tr-ID" ":" token
Message-ID = "Message-ID" ":" token
Boundary = "Boundary" ":" 0*65(bchars) bcharsnospace 6.1 Constructing Requests
bcharsnospace= DIGIT / ALPHA / "'" / "(" / ")" /
"+" / "_" / "," / "-" / "." /
"/" / ":" / "=" / "?"
bchars = bcharsnospace / " "
Closing = "-------" Boundary Continue-Flag CRLF ; Boundary must match Boundary header field value To form a new request, the sender creates a unique transaction
Continue-Flag = "+" / "$" identifier and uses this and the method name to create an MSRP
request start line. Next, the sender places the target path in a
To-Path header, and the sender's URL in a From-Path header. If
multiple URLs are present in the To-Path, the leftmost is the first
URL visited; the rightmost URL is the last URL visited. The
processing then becomes method specific. Additional method-specific
headers are added as described in the following sections.
Content-Type = "Content-Type" ":" media-type After any method-specific headers are added, processing continues to
media-type = type "/" subtype *( ";" parameter ) handle a body, if present. A body in a Non-SEND request MUST NOT be
type = token longer than 2048 octets. If the request has a body, it must contain
subtype = token a Content-Type header field. It may contain other MIME specific
parameter = attribute "=" value headers. The Content-Type header MUST be the last header line. The
attribute = token body MUST be separated from the headers with an extra CRLF.
value = token | quoted-string
To-Path = "To-Path" ":" msrp_url *(SP msrp_url) If the request contains a body, the sender MUST check the body to
From-Path = "From-Path" ":" msrp_url *(SP msrp_url) insure that the closing sequence (a CRLF, seven hyphens, and the
transaction identifier) is not present in the body. If the closing
sequence is present in the body, the sender MUST choose a new
transaction identifier that is not present in the body, and add the
closing sequence, including the "$" or "+" character, and a final
CRLF.
Message-Receipt = "Message-Receipt" ":" message-receipt-spec ( SEMI receipt-type ) Finally, requests which have no body MUST NOT contain a Content-Type
message-receipt-spec = "negative" / "none" / "all" header or any other MIME specific header. Bodiless requests MUST
receipt-type = "receipt-type" "=" media-type; <media-type> is detailed in [RFC3261] contain a closing sequence after the final header.
Byte-Range = "Byte-Range" ":" byte-range-spec Once a request is ready for delivery, the sender follows the
byte-range-spec = first-byte "-" last-byte connection management (Section 4.4) rules to forward the request over
first-byte = 1*DIGIT an existing open connection or create a new connection.
last-byte = 1*DIGIT
Receipt-ID = "Receipt-ID" ":" token
All requests and responses MUST contain at least a TR-ID header 6.1.1 Delivering SEND requests
field. All requests must also contain the To-Path and From-Path,
Message-ID, and Boundary header fields, as well as the Closing field.
Messages MAY contain other fields, depending on the method or
response code.
6.3.1 Message Framing When an endpoint has a message to deliver, it first generates a new
unique Message-ID. This ID MUST be unique within the scope of the
session. If the message is larger than 2048 octets in length, it
either generates an interruptible chunk (which is RECOMMENDED), or it
MAY break the complete message into chunks of 2048 octets. It then
generates a SEND request for each chunk, following the procedures
for constructing requests (Section 6.1).
MSRP messages are framed using the Boundary header field value. The Each chunk MUST contain a Message-ID header field containing the
Boundary header field contains a boundary string. The Closing field Message-ID. If the sender wishes non-default status reporting, it
contains the same boundary string with a prefix of "-------" (seven MUST insert a Report-Failure and/or Report-Success header field with
hyphens) and single character suffix representing a continuation an appropriate value. All chunks of the same message MUST use the
flag. same Report-Failure and Report-Success values in their SEND requests.
The closing field is constructed to allow for simple high speed If success reports are requested, the sending device MAY wish to run
parsing. The use of seven hyphens forces for of them to be aligned a timer of some value that makes sense for it's application and take
on a 32 bit boundary. A parser can quickly scan for the closing by action if a success Report is not received in this time. There is no
looking for a 32 bit value equivalent to "----". Once this word is universal value for this timer. For many IM applications, it may be
found, the scanner can carefully check and see if this is the 2 minutes while for some trading systems it may be under a second.
boundary it is looking for or just some random data. The boundary Regardless of whether such a timer is used, if the success report has
string SHOULD have at least 16 bits of randomness in it. For not been received by the time the session is ended, the device SHOULD
example, a valid boundary would be "Boundary:6ea7" where the 6ea7 was inform the user.
a randomly chosen four digit hexadecimal number. This reduces the
chance of the boundary string colliding with content data.
The boundary string MUST NOT occur inside the body itself. The The first chunk of the message SHOULD, and all subsequent chunks MUST
sender MUST ensure that a collision does not occur. include a Byte-Range header field. The range-start field MUST
indicate the position of the first byte in the body in the overall
message. The range-end field SHOULD indicate the position of the
last byte in the body, if known. It MUST take the value of "*" if
the position is unknown, or if the request needs to be interruptible.
The total field SHOULD contain the total size of the message, if
known. The total filed MAY contain a "*" if the total size of the
message is not known in advance. All chunks other than the last MUST
include a "+" character in the continuation field of the closing
line. The final chunk MUST use a "$" character. The sender MUST
send all chunks in Byte-Range order. (However,the receiver cannot
assume the requests will be delivered in order, as an intervening
relay may have changed the order.)
Since the message fragmentation section (Section 6.7) of this If the sender chooses to send a body larger than 2048 octets in a
document says that large content should be sent in parcels, it single chunk, the request MUST be constructed so that it can be
should always be possible to check for boundary collisions prior interrupted. A SEND request is interruptible if it either has no
to sending a parcel. Even in the case of streaming content, where Byte-Range header field, or has such a field with a "*" in the
the sender does not have all of the content prior to sending the last-byte sub-field.
first message, the chunk size should be small enough so that it is
practical to check each chunk for collisions prior to sending.
The MSRP boundary strings are distinct and independent from any MIME A SEND request is interrupted while a body is in the process of being
boundaries that may exist in the message body. For example, if the written to the connection by simply noting how much of the message
body is of a multipart type, the MIME headers will include a has already been written to the connection, then writing out the
multipart boundary. This multipart boundary MUST NOT be the same boundary string to end the chunk. It can then be resumed in a
string used in the MSRP Boundary header field. another chunk with the same Message-ID and a Byte-Range header range
start field containing the position of the first byte after the
interruption occurred.
The Closing field contains both the message boundary string and the SEND requests larger than 2k MUST be interrupted to send pending
Continuation-Flag. The Continuation-Flag indicates whether the response or REPORT requests. If multiple SEND requests from
entire content has been sent or not. Normally, the flag takes the different sessions are concurrently being sent over the same
value of "$" (dollar sign) to indicate that all content has been connections, the device SHOULD implement some scheme to alternate
sent, or "+" to indicate that there is additional content that has between them such that each concurrent request gets a chance to send
not yet been sent. some fair portion of data at regular intervals suitable to the
application.
The term "content" in this context means a complete logical instant The sender MUST NOT assume that a message is received by the peer
message, from the perspective of the user. The content could be a with the same chunk allocation it was sent with. An intervening
short text message, a long file transfer, etc. The logical instant relay could possibly break SEND requests into smaller chunks, or
message does not necessarily correspond one-to-one with a physical aggregate multiple chunks into larger ones.
MSRP message. For example, a video message may be one logical
instant message from the users' perspective, but it will generally be
sent as a series of parcels. Each parcel would be sent as the
payload in one physical MSRP SEND request. All the requests except
the final one would contain "+" in the continuation-flag to indicate
that the content is not complete. The final message would contain
"$" to indicate that complete content has been sent.
The sender MUST NOT include a completion-flag of "+" if the payload The default disposition of body is "render". If the sender wants
MIME type does not support content fragmentation. different disposition, it MAY insert a Content-Disposition header.
Since MSRP is a binary protocol, transfer encoding MUST be "binary".
6.3.2 Message Examples 6.1.2 Sending REPORT requests
The following is an example MSRP message sending a text payload: REPORT requests are similar to SEND requests, except that report
requests MUST NOT include Report-Success or Report-Failure header
fields, and MUST contain a Status header field. REPORT requests MUST
contain the Message-ID header from the original SEND request.
MSRP SEND An MSRP endpoint MUST be able to generate success REPORT requests.
Boundary: dkei38sd
To-Path:msrp://alice.atlanta.com:7777/iau39
From-Path:msrp://bob.atlanta.com:8888/9di4ea
TR-ID: 456
Message-ID: 456
Content-Type: "text/plain"
Hi, Alice! I'm Bob! REPORT requests MAY include a body. If a body is included, it SHOULD
-------dkei38sd$ be of the DSN MIME type detailed in RFC1894 [8], but MAY be of some
other type if the sender of the SEND request indicated support in the
"receipt-type" parameter of the respective Report-Success or
Report-Failure header field. This parameter contains the alternative
MIME type that SHOULD be used for this particular report. A client
specifying an alternative 'receipt-type' for an MSRP transaction MUST
also be capable of receiving the default format specified in this
RFC1894. Use of the DSN MIME format in MSRP is described in Section
8
The following is an example of an MSRP message containing a MIME type An endpoint MUST send a success report if it successfully receives a
that uses an internal boundary (not to be confused with the MSRP SEND request which contained a Report-Success value of "yes", and
boundary): either contains a complete message, or contains the last chunk needed
to complete the message. This request is sent following the normal
procedures (Section 6.1), with a few additional requirements.
MSRP SEND The endpoint inserts a To-Path header field containing the From-Path
Boundary:a38sdo To-Path:msrp://bob.atlanta.com:8888/9di4ea value from the original request, and a From-Path header containing
From-Path:msrp:alice.atlanta.com:7777/iau39 the URL identifying itself in the session. The endpoint then inserts
TR-ID: 456 a Status header field with a namespace of "000", a short-status of
Message-ID: 456 "200" and a relevant Reason phrase, and a Message-ID header field
Content-Type: multipart/byteranges;boundary=abcde containing the value from the original request.
--abcde Positive status reports SHOULD NOT include a payload.
Content-Type: image/jpeg
Content-range: bytes 0-*/50270
[large jpg file]
--abcde--
-------a38sdo$
6.4 MSRP Transactions The endpoint MUST NOT send a success report for a SEND request that
either contained no Report-Success header field, or contained such a
field with a value of "no".
An MSRP transaction consists of exactly one request and one response. 6.1.3 Failure REPORT Generation
A response matches a transaction if the following are true:
It shares the same TR-ID value. If an MSRP endpoint receives a SEND request that it cannot process
It is received on the same connection on which the request was for some reason, and the Report-Failure header either was not present
sent. in the original request, or had a value of "yes", it SHOULD simply
The To-Path has a single entry, which matches the response send a transaction response with an appropriate error response code.
recipient's local URI for the session. 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
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
request when the error is detected.
Endpoints MUST select TR-ID header field values in requests so that If the endpoint receives a SEND request with a Report-Failure header
they are not repeated by the same endpoint in scope of the given field value of "none", then it MUST NOT send a failure REPORT
session. TR-ID values SHOULD be globally unique. The TR-ID space of request, and SHOULD NOT send an MSRP response.
each endpoint is independent of that of its peer. Endpoints MUST NOT
infer any semantics from the TR-ID header field beyond what is stated
above. In particular, TR-ID values are not required to follow any
sequence.
MSRP Transactions complete when a response is received, or after a Construction of failure REPORT requests is identical to that for
timeout interval expires with no response. Endpoints MUST treat such success reports, except the Status header code and reason fields
timeouts in exactly the same way they would treat a 500 response. SHOULD contain appropriate error codes. Any error response code
The timeout interval SHOULD be 30 seconds, but other values may be defined in this specification MAY also be used in failure reports.
established as a matter of local policy. 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.
6.5 MSRP Sessions 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
actual range being reported on. It can take the range-start and
total values from the original SEND request, but MUST calculate the
range-end field from the actual body data.
AN MSRP session is a context in which a series of instant messages Endpoints SHOULD NOT send REPORT requests if they have reason to
are exchanged, using SEND requests. A session has two endpoints, believe the request will not be delivered. For example, they SHOULD
identified by MSRP URLs. NOT send a REPORT request on a session that is no longer valid.
6.5.1 Initiating an MSRP session This section only describes failure report generation behavior for
MSRP endpoints. Relay behavior is beyond the scope of this
document, and will be considered in a separate document. We
expect failure reports to be more commonly generated by relays
than by endpoints.
When an endpoint wishes to engage a peer in a message session, it 6.2 Constructing Responses
invites the peer to communicate using an SDP offer, carried over SIP
or some other protocol supporting the SDP offer/answer model. For
the purpose of this document, we will refer to the endpoint choosing
to initiate communication as the offerer, and the peer being invited
as the answerer.
Under normal circumstances, the answerer MUST be prepared to accept If an MSRP endpoint receives a request that either contains a
a connection from the offerer. Report-Failure header value of "yes", or does not contain a
Report-Failure header field at all, it MUST immediately generate a
response. Likewise, if an MSRP endpoint receives a request that
contains a Report-Failure header value of "partial", and the receiver
is unable to process the request, it SHOULD immediately generate a
response.
The offerer MUST perform the following steps: To construct the response, the endpoint first creates the response
start-line, inserting appropriate response code and reason fields.
The transaction identifier in the response start line MUST match the
transaction identifier from the original request.
1. Construct a MSRP URL to serve as the local URL. The endpoint then inserts an appropriate To-Path header field. If
the request triggering the response was a SEND request, the To-Path
header field is formed by copying the last (right-most) URI in the
From-Path header field of the request. (Unlike other methods,
responses to SEND requests are returned only to the previous hop.)
For responses to all other requests, the To-Path header field
contains the full path back to the original sender. This full path
is generated by taking the list of URLs from the From-Path of the
original request, reversing the list, and writing the reversed list
into the To-Path of the response. (Legal REPORT requests do not
request responses, so this specification doesn't exercise the
behavior described above, however we expect that extensions for
gateways and relays will need such behavior.)
2. Construct an SDP offer as described in Section 5, including the Finally, the endpoint inserts a From-Path header field containing the
list of allowed IM payload formats in the accept-types attribute. URL that identifies it in the context of the session, followed by the
The offerer puts its local URL into the path attribute, as closing sequence after the last header field. The response MUST be
described in Section 5.4. This URL becomes the offerer's local transmitted back on the same connection on which the original request
path. arrived.
3. Send the SDP offer using the normal processing for the signaling 6.3 Receiving Requests
protocol.
If the answerer chooses to participate, it MUST perform the following The receiving endpoint must first check the URL in the To-Path to
steps: make sure the request belongs to an existing session. When the
request is received, the To-Path will have exactly one URL, which
MUST map to an existing session that is associated with the
connection on which the request arrived. If this is not true, and
the request contained a Report-Failure header value of "no", then the
receiver SHOULD quietly ignore the request. If the Report-Failure
header is not present, or had any other value, then the receiver MUST
return a 481 response.
1. Store the contents of the offered sdp path attribute as the Further request processing by the receiver is method specific.
remote path for he session.
2. Construct a MSRP URL that resolves to itself. Save this as the 6.3.1 Receiving SEND requests
local URL for the session.
3. Listen for a connection on the transport, address, and port When the receiving endpoint receives a SEND request, it first
described by the local URL. determines if it contains a complete message, or a chunk from a
larger message. If the request contains no Byte-Range header, or
contains one with a range-start value of "1", and the closing line
continuation flag has a value of "$", then the request contained the
entire message. Otherwise, the receiver looks at the Message-ID
value to associate chunks together into the original message. It
forms a virtual buffer to receive the message, keeping track of which
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 buffer. The receiver MUST determine the actual length of each
chunk by inspecting the payload itself; it is possible the body is
shorter than the range-end field indicates. This can occur if the
sender interrupted a SEND request unexpectedly. It is worth nothing
that the chunk that has a termination character of "$" defines the
total length of the message.
4. Send a SDP answer via the signaling protocol, according to the What is done with the body is outside the scope of MSRP and largely
following rules: determined by the MIME type. The body MAY be rendered after the
whole message is received or partially rendered as it is being
received.
1. The C-line is copied unmodified from the offer. If the SEND request contained a Content-Type header field indicating
an unsupported MIME type, the receiver SHOULD send a 415 response, if
allowed by the Report-Failure header field. All MSRP endpoints MUST
be able to receive the multipart/mixed and multipart/alternative MIME
types.
2. The accept-types attribute contains the SEND payload media If the SEND request contained a Report-Success header field with a
types that the answerer is willing to accept. The value of "yes", and the request is either contains the entire message
accept-types attribute in the answer MUST be either the same or the last chunk needed to complete a message, the receiver MUST
as that of the offer, or a subset. send a success REPORT request back to the sender.
3. The path attribute contains the answerer's local URL. 6.3.2 Receiving REPORT requests
Again, this document assumes that no relays are introduced. If When an endpoint receives a REPORT request, it may correlate it to
the answerer were to introduce one or more relay, it would add the the original SEND request using the Message-ID and the Byte-Range, if
appropriate URLs to the path attribute in the SDP answer. It present. If it requested success reports, then it SHOULD keep enough
would not need to listen for a connection, as the first relay in state about each outstanding sent message so that it can correlate
its path would have that honor. REPORT requests to the original messages.
When the offerer receives the answer, it MUST perform the following An endpoint that receives a REPORT request containing a Status header
steps: with a namespace field of "000", it SHOULD interpret the report in
exactly the same way it would interpret an MSRP transaction response
with a response code matching the short-code field.
1. Save the path attribute contents from the SDP answer as the It is possible to receive a failure report or a failure transaction
remote path. response for a chunk that is currently being delivered. In this case
the entire message corresponding to that chunk should be aborted.
2. Designate the first entry in the remote path as the adjacent-hop It is possible that an endpoint will receive a REPORT request on a
URL. 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
take any steps to facilitate such late delivery, i.e. it is not
expected to keep a connection active in case late REPORTs might
arrive.
3. Check to see if a connection already exists that is associated 7. Using MSRP with SIP
with URL that matches the scheme, host part, and port of the
adjacent-hop URL. If such a connection exists, the device SHOULD
reuse it, rather than opening a new connection.
4. If no matching connection exists, attempt to open a connection to 7.1 SDP Offer-Answer Exchanges for MSRP Sessions
the adjacent hop using the transport, address, port, and
protection mode designated by the adjacent-hop URL.
5. If the connection succeeds, or if a connection is reused, MSRP sessions will typically be initiated using the Session
immediately send a MSRP request to the opposite peer. This Description Protocol (SDP) [2] via the SIP offer-answer mechanism
SHOULD be a visit request, but MAY be a SEND request if the [3].
endpoint has legitimate content to send.
6.5.2 Handling the initial request This document defines a handful of new SDP parameters to setup MSRP
sessions. These are detailed below and in the IANA Considerations
section.
An MSRP device that accepts a network connection will receive an The general format of an SDP media-line is:
immediate MSRP request from the connecting endpoint. This may be a
SEND or VISIT request. When an endpoint receives such a request, it
MUST perform the following procedures:
1. Check if state exists for a session with a local URL that matches m=<media> <port> <protocol> <format list>
the To-Path header field value of the VISIT request. If so, and
if no previous request has been received for that URL on a
different connection, then return a 200 response, and save state
associating the first URL in the From-Path header field with the
connection on which the request was received .
2. If the state exists, and a matching request has occurred on a An offered or accepted MSRP media-line MUST have the following value
different connection, return a 506 response and do not change exactly, with the exception that the port field MAY be set to zero.
session state in any way. (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
to zero (0).)
3. If no matching state exists, return a 481 response, and do not m=message 9 msrp *
change session state in any way.
6.5.3 Sending Instant Messages on a Session While MSRP could theoretically carry any media type, "message" is
appropriate. For MSRP, the port number is always ignored--the
actual port number is provided in an MSRP URL. Instead "9" is
used, which is an innocuous value which is assigned to the discard
port. The protocol is always "msrp", and the value of the format
list is always a single asterisk character ("*").
Once a MSRP session has been established, either endpoint may send An MSRP media-line is always accompanied by a mandatory "path"
instant messages to its peer using the SEND method. When an endpoint attribute. This attribute contains a space separated list of URLs
wishes to do so, it MUST construct a SEND request according to the that must be visited to contact the user agent advertising this
following process: session-description. If more than one URL is present, the leftmost
URL is the first URL that must be visited to reach the target
resource. (The path list can contain multiple URLs to allow for the
deployment of gateways or relays in the future.) MSRP
implementations which can accept incoming connections will typically
only provide a single URL here.
1. Insert a To-Path header field containing the path to the opposite MSRP media lines MUST also be accompanied by an "accept-types"
endpoint, in order from left to right. attribute. This attribute contains a list of MIME types which are
acceptable to the endpoint.
2. Insert a From-Path header field containing the local URL. A "*" entry in the accept-types attribute indicates that the sender
may attempt to send content with media types that have not been
explicitly listed. Likewise, an entry with an explicit type and a
"*" character as the subtype indicates that the sender may attempt to
send content with any subtype of that type. If the receiver receives
an MSRP request and is able to process the media type, it does so.
If not, it will respond with a 415 response. Note that all explicit
entries SHOULD be considered preferred over any non-listed types.
3. Insert the message payload in the body, and the media type in the This feature is needed as, otherwise, the list of formats for rich IM
Content-Type header field. The media type MUST match one of the devices may be prohibitively large.
types in the format list negotiated in the SDP exchange. If a
"*" was present in the accept-types attribute, then the media
type SHOULD match one of the explicitly listed entries, but MAY
be any other arbitrary value.
4. Set the TR-ID and Message-ID header fields to a unique value. The accept-types attribute may include container types, that is, MIME
The sender MAY set these fields to the same value. formats that contain other types internally. If compound types are
used, the types listed in the accept-types attribute may be used both
as the root payload, or may be wrapped in a listed container type.
Any container types MUST also be listed in the accept-types
attribute.
5. Send the request on the connection associated with the session. Occasionally an endpoint will need to specify a MIME body type that
can only be used if wrapped inside a listed container type.
6. If a 2xx response code is received, the transaction was Endpoints MAY specify MIME types that are only allowed when wrapped
successful. inside compound types using the "accept-wrapped-types" attribute in
an SDP a-line.
7. If a 415 response is received, this indicates the recipient is The semantics for accept-wrapped-types are identical to those of the
unable or unwilling to process the media type. The sender SHOULD accept-types attribute, with the exception that the specified types
NOT attempt to send that particular media type again in the may only be used when wrapped inside containers. Only types listed
context of this session. in the accept-types attribute may be used as the "root" type for the
entire body. Since any type listed in accept-types may be used both
as a root body, and wrapped in other bodies, format entries from
accept-types SHOULD NOT be repeated in this attribute.
8. If any other response code is received, or if the transaction This approach does not allow for specifying distinct lists of
times out, the endpoint SHOULD assume the session has failed, acceptable wrapped types for different types of containers. If an
either tear down the session, or attempt to re-establish the endpoint understands a MIME type in the context of one wrapper, it is
session by sending an updated SDP offer proposing a new assumed to understand it in the context of any other acceptable
connection. If a new connection is established, the endpoint MAY wrappers, subject to any constraints defined by the wrapper types
choose to resend the content on the new connection. themselves.
Open Issue: Do we need to create a duplicate mechanism to suppress The approach of specifying types that are only allowed inside of
duplicate messages when a new connection is established in this containers separately from the primary payload types allows an
fashion? mechanism? List consensus seems to indicate we do. We endpoint to force the use of certain wrappers. For example, a
may need to specify that the tr-id space spans a sequence of CPIM [14] gateway device may require all messages to be wrapped
connections if they are associated with same stream, and of inside message/cpim bodies, but may allow several content types
course, specify what it means for a stream to span connections. inside the wrapper. If the gateway were to specify the wrapped
types in the accept-types attribute, its peer might attempt to use
those types without the wrapper.
All types listed in either the accept-types or
accept-wrapped-types attributes MAY include a max-size parameter,
indicating the largest message it is willing to accept of that
type. Max-size refers to the complete message, not the size of
any one chunk. Senders MUST NOT exceed the max-size limit, if
any, when sending messages of any listed type. If a type is
listed without the parameter, then no preset size limit exists.
When an endpoint receives a SEND request, it MUST perform the accept-types = accept-types-label ":" format-list
following steps. accept-types-label = "accept-types"
accept-wrapped-types = wrapped-types-label ":" format-list
wrapped-types-label = "accept-wrapped-types"
format-list = format-entry *( SP format-entry)
format-entry = ctype [SEMI max-size]
ctype = (type "/" subtype) / (type "/" "*") / ("*")
type = token
subtype = token
max-size = "max" "=" 1*(DIGIT)
1. Check that it has state for a session with a local URL matching 7.1.1 URL Negotiations
the To-Path value. If no matching session exists, return a 481
response.
2. Determine that it understands the media type in the body, if any Each endpoint in an MSRP session is identified by a URL. These URLs
exists. 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
the following syntax:
3. If it does, return a 200 response and render the message to the "a=path:" MSRP_URL *(SP MSRP_URL)
user. The method of rendering is a matter of local policy. If
the message contained no body at all, the endpoint should quietly
ignore it.
4. If it does not understand the media type, return a 415 response. where MSRP_URL is an msrp: or msrps: URL as defined in Section 5.
The endpoint MUST NOT return a 415 response for any media type MSRP URLs included in an SDP offer or answer MUST include explicit
for which it indicated support in the SDP exchange. port numbers.
6.5.4 Ending a Session An MSRP device uses the URL to determine a host address, port,
transport, and protection level when connecting, and to identify the
target when sending requests and responses.
When either endpoint in an MSRP session wishes to end the session, it The offerer and answerer each selects a URL to represent itself, and
first signals its intent using the normal processing for the send it to the peer device in the SDP document. Each device stores
signaling protocol. For example, in SIP, it would send a BYE request the path value received from the peer, and uses that value as the
to the peer. After agreeing to end the session, the host endpoint target for requests inside the resulting session. If the path
MUST release any resources acquired as part of the session. attribute received from the peer contains more than one URL, then the
target URL is the rightmost, while the leftmost entry represents the
adjacent hop. If only one entry is present, then it is both the peer
and adjacent hop URL. The target path is the entire path attribute
value received from the peer.
Each peer MUST destroy all local state for the session. This The following example shows an SDP offer with a session URL of
involves completely removing the state entry for the session and "msrp://a.example.com:7394/2s93i;tcp"
invalidating the session URL.
If no other sessions are using the connection, the endpoint that v=0
opened it SHOULD tear it down. However, the passive party MAY tear o=alice 2890844526 2890844527 IN IP4 alice.example.com
down an unused connection after a locally configured timeout period. s=
c=IN IP4 alice.example.com
m=message 9 msrp *
a=accept-types:text/plain
a=path:msrp://a.example.com:7394/2s93i;tcp
When an endpoint chooses to close a session, it may have SEND The rightmost URI in the path attribute MUST identify the endpoint
transactions outstanding. For example, it may have send SEND that generated the SDP document, or some other location where that
requests to which it has not yet received a response, or it may have endpoint wishes to receive requests associated with the session. It
received SEND requests that to which it has not responded. Once an MUST be assigned for this particular session, and MUST NOT duplicate
endpoint has decided to close the connection, it SHOULD wait for such any URI in use for any other session in which the endpoint is
outstanding transactions to complete. It SHOULD NOT generate any new currently participating. It SHOULD be hard to guess, and protected
SEND transactions, and it MAY choose not to respond to any new SEND from eavesdroppers. This is discussed in more detail in Section 14.
requests that are received after it decides to close the session. It
SHOULD not respond to any new messages that arrive after it signals
its intent to close the session.
When an endpoint is signaled of its peer's intent to close a session, 7.1.2 Path Attributes with Multiple URLs
it SHOULD NOT initiate any more SEND requests. It SHOULD wait for
any outstanding transactions that it initiated to complete, and it
SHOULD attempt respond to any open SEND transactions received prior
to being signaled.
It is not possible to completely eliminate the chance of a session As mentioned previously, this document describes MSRP for
terminating with incomplete SEND transactions. When this occurs, the peer-to-peer scenarios, that is, when no relays are used. However,
endpoint SHOULD clearly inform the user that the messages may not we expect a separate document to describe the use of relays. In
have been delivered. order to allow an MSRP device that only implements the core
specification to interoperate with devices that use relays, this
document must include a few assumptions about how relays work.
6.5.5 Managing Session State and Connections An endpoint that uses one or more relays will indicate that by
putting a URL for each device in the relay chain into the SDP path
attribute. The final entry would point to the endpoint itself. The
other entries would indicate each proposed relay, in order. The
first entry would point to the first relay in the chain; that is, the
relay to which the peer device, or a relay operation on its behalf,
should connect.
A MSRP session is represented by state at each endpoint, identified Endpoints that do not wish to insert a relay, including those that do
by the local URL and remote path. An active session also has an not support relays at all, will put exactly one URL into the path
associated network connection. attribute. This URL represents both the endpoint for the session,
and the connection point.
If the connection fails for any reason, the device MUST invalidate While endpoints that implement only this specification will never
the session state for all sessions using the connection. Once a introduce a relay, they will need to be able to interoperate with
connection is dropped, any associated session state MUST NOT be other endpoints that do use relays. Therefore, they MUST be prepared
reused. If an endpoint wishes to continue to communicate after to receive more than one URL in the SDP path attribute. When an
detecting a connection failure, it MAY initiate a new SDP exchange to endpoint receives more than one URL in a path header, only the first
negotiate a new session URL. Otherwise, it SHOULD attempt to tear entry is relevant for purposes of resolving the address and port, and
down the session using the rules of the signaling protocol. establishing the network connection, as it describes the first
adjacent hop.
It would be nice to allow sessions to be recovered after a If an endpoint puts more than one URL in a path attribute, the final
connection failure, perhaps by allowing the active endpoint to URL in the path (the peer URL) attribute MUST exhibit the uniqueness
reconnect, and send a new VISIT request. However, this approach properties described above. Uniqueness requirements for other
creates a race condition between the time that the hosting device entries in the attribute are out of scope for this document.
notices the failed connection, and the time that the endpoint
tries to recover the session. If the endpoint attempts to
reconnect prior to the hosting device noticing the failure, the
hosting device will interpret the recovery attempt as a conflict.
The only way around this would be to force the hosting device to
do a liveness check on the original connection, which would create
a lot of complexity and overhead that do not seem to be worth the
trouble.
6.6 Delivery Status Notification 7.1.3 Updated SDP Offers
Delivery Status Notification (DSN)[10] provides an extensible MIME MSRP endpoints may sometimes need to send additional SDP exchanges
content-type that is used to convey both positive and negative status for an existing session. They may need to send periodic exchanges
of messages in the network. This functionality is extremely useful with no change to refresh state in the network, for example, SIP
for MSRP sessions that traverse a relay device. Relay support is Session Timers. They may need to change some other stream in a
considered out of scope for this specification and will be included session without affecting the MSRP stream, or they may need to change
in a separate specification. This section will only cover an MSRP stream without affecting some other stream.
functionality required by non-relay aware endpoints for basic MSRP
operation. An MSRP endpoint MUST be capable of performing the DSN
operations described in this specification and SHOULD support the DSN
MIME type outlined. An MSRP endpoint MAY use an alternative payload
for reporting message status using the procedures outlined in this
specification.
6.6.1 Endpoint DSN Request Either peer may initiate an updated exchange at any time. The
endpoint that sends the new offer assumes the role of offerer for all
purposes. The answerer MUST respond with a path attribute that
represents a valid path to itself at the time of the updated
exchange. This new path may be the same as its previous path, but
may be different. The new offerer MUST NOT assume that the peer will
answer with the same path it used previously.
An endpoint that wishes to be informed of message delivery/failure If either party wishes to send an SDP document that changes nothing
needs to request such information. This is achieved by including an at all, then it MUST have the same o-line as in the previous
MSRP Receipt-Request header in the request. The header can equal one exchange.
of three values:
negative: Indicates the client only requires failure delivery 7.1.4 Example SDP Exchange
report.
none: Indicates the client requires no delivery reports.
all: Indicates the client requires both positive and negative
delivery reports.
Within the scope of this specification the Receipt-Request header is Endpoint A wishes to invite Endpoint B to a MSRP session. A offers
only used in MSRP SEND requests. Future extensions to this the following session description:
specification MAY use the mechanism described in this document for
delivery/failure status notification of other MSRP requests.
The default value for this header if not present in a request is v=0
'negative'. An example of this header would be: o=usera 2890844526 2890844527 IN IP4 alice.example.com
s=
c=IN IP4 alice.example.com
t=0 0
m=message 9 msrp *
a=accept-types: message/cpim text/plain text/html
a=path:msrp://alice.example.com:7394/2s93i9;tcp
Message-Receipt: negative B responds with its own URL:
The default DSN MIME type is detailed in RFC 1894[10]. It is v=0
possible for MSRP endpoints to use a different format if required. o=userb 2890844530 2890844532 IN IP4 bob.example.com
This can be achieved by including a 'receipt-type' parameter in the s=
Message-Receipt header. This parameter contains the alternative MIME c=IN IP4 bob.example.com
type that SHOULD be used for this particular receipt transaction. A t=0 0
client specifying an alternative 'receipt-type' for an MSRP m=message 9 msrp *
transaction MUST also be capable of receiving the default format a=accept-types:message/cpim text/plain
specified in this document. This allows intermediaries, such as MSRP a=path:msrp://bob.example.com:8493/si438ds;tcp
relays, to generate failure reports when MSRP transaction failure
occurs.
6.6.2 DSN generation 7.1.5 Connection Negotiation
An MSRP endpoint implementing this specification SHOULD be able to Previous versions of this document included a mechanism to negotiate
generate positive delivery status of MSRP requests. On receiving an the direction for any required TCP connection. The mechanism was
MSRP request containing a Message-Receipt header with a value of loosely based on the COMEDIA [24]work being done in the MMUSIC
'all', the endpoint will carry out normal MSRP response generation working group. The primary motivation was to allow MSRP sessions to
and MUST generate an MSRP REPORT request using the following succeed in situations where the offerer could not accept connections
procedures: but the answerer could. For example, the offerer might be behind a
NAT, while the answerer might have a globally routable address.
1. Insert a To header containing the From value from the original The SIMPLE working group chose to remove that mechanism from MSRP, as
request. it added a great deal of complexity to connection management.
2. Insert a From header containing the To value from the original Instead, MSRP now specifies a default connection direction.
request.
3. Insert the message status payload in the body of the request. If
the default DSN MIME type from DSN[10] is used then the MSRP
Content-Type header MUST use the value multipart/report. The
relevance of DSN headers in MSRP can be found in section 7.6.5.
An alternative MIME type MAY be used but MUST be specified in the
Content-Type header. Negative DSN generation is considered out
of the scope of this document and will be covered in a separate
MSRP relay document.
4. Insert a new transaction ID (TR-ID).
5. (Optional) Insert an MSRP Byte-Range header containing the value
from 'multipart/byteranges' MIME header Content-range from the
payload of a chunked message. It is possible that an entity
downstream may decide to break up an MSRP SEND message and send
it in separate chunks. The originating client would be
transparent to this operation but would need to be informed if a
DSN only represents part of the request.
6.6.3 Receiving positive DSN 7.2 MSRP User Experience with SIP
An MSRP endpoint implementing this specification MUST be able to In typical SIP applications, when an endpoint receives an INVITE
receive positive delivery status of MSRP requests. request, it alerts the user, and waits for user input before
responding. This is analogous to the typical telephone user
experience, where the callee "answers" the call.
6.6.4 Receiving negative DSN In contrast, the typical user experience for instant messaging
applications is that the initial received message is immediately
displayed to the user, without waiting for the user to "join" the
conversation. Therefore, the principle of least surprise would
suggest that MSRP endpoints using SIP signaling SHOULD allow a mode
where the endpoint quietly accepts the session, and begins displaying
messages.
An MSRP endpoint implementing this specification MUST be able to SIP INVITE requests may be forked by a SIP proxy, resulting in more
receive negative delivery status of MSRP requests. than one endpoint receiving the same INVITE. SIP early media [28]
techniques can be used to establish a preliminary session with each
endpoint, and canceling the INVITE transaction for any endpoints that
do not send MSRP traffic after some period of time.
6.6.5 DSN headers in MSRP 8. DSN payloads in MSRP REPORT Requests
The format of a default DSN report is taken from RFC 1894[10]. Only The format of a default REPORT request payload format the DSN taken
a minimal subset of fields are used, as detailed in the remainder of from RFC1894 [8]. Only a minimal subset of fields are relevant for
this section. MSRP, as detailed in the remainder of this section.
6.6.5.1 Per-Message DSN header usage 8.1 Per-Message DSN header usage
original-envelope-id: See Section 6.6.5.3 original-envelope-id: See Section 8.3
reporting-mta: See Section 6.6.5.4 reporting-mta: See Section 8.4
dsn-gateway: Not Used dsn-gateway: Not Used
received-from-mta: Not Used received-from-mta: Not Used
arrival-date: Not Used arrival-date: Not Used
6.6.5.2 Per-Recipient DSN header usage 8.2 Per-Recipient DSN header usage
original-recipient Not Used original-recipient Not Used
final-recipient: See Section 6.6.5.5 final-recipient: See Section 8.5
action: See Section 6.6.5.6 action: See Section 8.6
status: See Section 6.6.5.7 status: See Section 8.7
remote-mta: Not Used remote-mta: Not Used
diagnostic-code: Not Used diagnostic-code: Not Used
last-attempt-date: Not Used last-attempt-date: Not Used
will-retry-until:Not Used will-retry-until:Not Used
6.6.5.3 original-envelope-id usage 8.3 original-envelope-id usage
The 'original-envelope-id' field contains a unique identifier which The 'original-envelope-id' field contains a unique identifier which
is used to correlate a DSN report with the originating MSRP is used to correlate a DSN report with the originating MSRP
transaction. The entity generating the DSN report MUST insert the transaction. The entity generating the DSN report MUST insert the
Message-ID value that appeared in the original MSRP request into the Message-ID value that appeared in the original MSRP request into the
'original-envelope-id' field. This allows a requesting client to 'original-envelope-id' field. This allows a requesting client to
explicitly correlate a REPORT request with the original request. explicitly correlate a REPORT request with the original request.
This correlation is implementation specific and makes no requirements This correlation is implementation specific and makes no requirements
on clients to hold state for transactions ID's. Information on clients to hold state for transactions ID's. Information
regarding the original request can be obtained from the DSN MIME type regarding the original request can be obtained from the DSN MIME type
outlined in [10]. outlined in [8].
6.6.5.4 reporting-mta 8.4 reporting-mta
The 'reporting-mta-field' MUST follow the guidelines set out in RFC The 'reporting-mta-field' MUST follow the guidelines set out in RFC
1894[10]. The 'mta-name-type' from RFC1894[10] MUST use the value of 1894[8]. The 'mta-name-type' from RFC1894[8] MUST use the value of
'msrp-name-type', as defined in section 9 of this specification. The 'msrp-name-type', as defined in Section 15.4 of this specification.
'mta-name' value for this field as specified in RFC1894 [10] MUST The 'mta-name' value for this field as specified in RFC1894 [8] MUST
equal an MSRP URL representing itself. equal the MSRP URL representing itself in the context of the session.
6.6.5.5 final-recipient 8.5 final-recipient
The 'final-recipient-field' MUST follow the guidelines set out in RFC The 'final-recipient-field' MUST follow the guidelines set out in RFC
1894[10]. The 'address-type' from RFC1894 [10] MUST use the value of 1894[8]. The 'address-type' from RFC1894 [8] MUST use the value of
'msrp-address-type', as defined in section 9 of this specification. 'msrp-address-type', as defined in Section 15.4 of this
The 'address-type' value for this field as specified in RFC1894 [10] specification. The 'address-type' value for this field as specified
MUST equal the value contained in the MSRP 'To' header from the in RFC1894 [8] MUST equal the final value contained in the MSRP
original request being reported on. 'To-Path' header from the original request.
6.6.5.6 action 8.6 action
The 'action' field MUST follow the guidelines set out in RFC The 'action' field MUST follow the guidelines set out in RFC 1894[8].
1894[10]. An MSRP entity constructing a DSN report MUST use the An MSRP entity constructing a DSN report MUST use the 'delivered'
'delivered' value for a successful delivery and MUST use the 'failed' value for a successful delivery and MUST use the 'failed' value for
value for an un-successful delivery. The other values specified for an unsuccessful delivery. The other values specified for the
the 'action' field in RFC 1894[10] MAY be used. 'action' field in RFC 1894[8] MAY be used.
6.6.5.7 status 8.7 status
The 'status' field MUST follow the guidelines set out in RFC The 'status' field MUST follow the guidelines set out in RFC 1894[8].
1894[10]. An MSRP entity constructing a DSN report MUST represent An MSRP entity constructing a DSN report MUST represent the MSRP
the MSRP status code in the correct format detailed in RFC 1894[10] status code in the correct format detailed in RFC 1894[8] for the
for the 'status' field of a DSN report. An MSRP status code consists 'status' field of a DSN report. An MSRP status code consists of a
of a three digit number while a DSN status is three digits separated three digit number while a DSN status is three digits separated by
by '.'. An example would be: '.'. An example would be:
Status: 5.0.0 (unknown permanent failure) Status: 5.0.0 (unknown permanent failure)
When generating this field the first digit of the MSRP status code 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 (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 '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 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 the third part of the 'status' DSN field. An example of a DSN
'status' field value would be: 'status' field value would be:
An MSRP '200' success response would be mapped to: An MSRP '200' success response would be mapped to:
Status: 2.0.0 (OK) Status: 2.0.0 (OK)
skipping to change at page 28, line 18 skipping to change at page 30, line 41
the third part of the 'status' DSN field. An example of a DSN the third part of the 'status' DSN field. An example of a DSN
'status' field value would be: 'status' field value would be:
An MSRP '200' success response would be mapped to: An MSRP '200' success response would be mapped to:
Status: 2.0.0 (OK) Status: 2.0.0 (OK)
The MSRP reason phrase mapped to a DSN 'status' field MAY be enclosed The MSRP reason phrase mapped to a DSN 'status' field MAY be enclosed
in parentheses if required. in parentheses if required.
6.7 Message Fragmentation 9. Formal Syntax
MSRP devices SHOULD break large content into fragments, and send each The following syntax specification uses the augmented Backus-Naur
fragment in a separate SEND request. A message fragment sent in this Form (BNF) as described in RFC-2234 [6].
way is known as a "parcel". Large content is defined to be anything
larger than 2K bytes. Each parcel is encapsulated using the
"message/byteranges" MIME type, defined in RFC2616 [11], to correlate
parts of the message. The definition of large is determined by local
policy. MSRP endpoints MUST be capable of receiving and processing
fragmented messages.
Open Issue: Do we want to negotiate the use of message/byteranges msrp-req-or-resp = msrp-request / msrp-response
like any other MIME type? I assume no, as we want to allow relays msrp-request = req-start headers [content-stuff] end-line
to fragment messages, and relays are not privy to the msrp-response = resp-start headers end-line
content-types negotiated for a session.
Although relays are not in scope for this document, we expect that req-start = pMSRP SP transact-id SP method CRLF
relays will be able to introduce fragmentation, as well as change the resp-start = pMSRP SP transact-id SP status-code [SP phrase] CRLF
fragmentation of previously fragmented messages. Therefore, all MSRP phrase = utf8text
endpoints MUST be able to receive fragmented messages.
6.7.1 MSRP Usage of message/byteranges pMSRP = %4d.53.52.50 ; MSRP in caps
transact-id = ident
method = mSEND / mREPORT / other-method
mSEND = %53.45.4e.44 ; SEND in caps
mREPORT = %52.45.50.4f.52.54; REPORT in caps
The "message/byteranges" type allows multiple ranges in a single other-method = 1*UPALPHA
document. However, MSRP devices MUST NOT include more than one byte status-code = 3DIGIT
range in a single request. Although the HTTP usage for a document
containing a single byte range indicates putting the "Content-Range"
header in a header field, rather than in the body itself,
"Content-Range" MUST NOT appear as an MSRP header field.
Open Issue: How much of the message/byteranges specification headers = 1*( header CRLF )
should we explain or copy forward? Copying too much obscures the
fact that rfc2616 is the normative definition, but it may be
helpful to have more context here.
If the MSRP device has a priori knowledge of the overall content header = ( To-Path
length, it SHOULD put that length into instance-length. The device / From-Path
MAY place a "*" in instance-length if it does not have such / Message-ID
knowledge. / Report-Success
/ Report-Failure
/ Byte-Range
/ Status
/ Mime-Header
/ ext-header )
Similarly, if the device has a priori knowledge of the number of To-Path = "To-Path:" SP URL *( SP URL )
bytes in a byte range, it SHOULD place the last byte position in From-Path = "From-Path:" SP URL *( SP URL )
last-byte-pos. Otherwise, it MAY use a "*". If "*" is present, the Message-ID = "Message-ID:" SP ident
recipient MUST determine the last-byte-position through normal Report-Success = "Report-Success:" SP ("yes" / "no" )
request framing and body processing. An MSRP device MUST put the Report-Failure = "Report-Failure:" SP ("yes" / "no" / "partial" )
initial byte position in first-byte-pos. Byte-Range = "Byte-Range:" SP range-start "-" range-end "/" total
range-start = 1*DIGIT
range-end = 1*DIGIT / "*"
total = 1*DIGIT / "*"
Status = "Status:" SP namespace SP short-status [SP text-reason]
6.8 Method Descriptions ident = alphanum 3*31ident-char
ident-char = alphanum / "." / "-" / "+" / "%" / "="
This section summarizes the purpose of each MSRP method. All MSRP content-stuff = *(Other-Mime-Header CRLF)
messages MUST contain the TR-ID, From-Path, To-Path, and Boundary Content-Type 2CRLF data CRLF
header fields, as well as a Closing field. Additional requirements
exist depending on the individual method.
6.8.1 SEND Content-Type = "Content-Type:" SP media-type
media-type = type "/" subtype *( ";" gen-param )
type = token
subtype = token
The SEND method is used by both the host and visitor endpoints to gen-param = pname [ "=" pval ]
send instant messages to its peer endpoint. A SEND request MUST pname = token
contain a To-Path header field containing the sender's remote path, a pval = token / quoted-string
From-Path header field containing the sender's local URL, and a
Message-ID header field. SEND requests SHOULD contain a MIME body
part. The body MUST be of a media type included in the format list
negotiated in the SDP exchange. If a body is present, the request
MUST contain a Content-Type header field identifying the media type
of the body.
To Do: We plan to expand the use of MIME headers to allow any token = 1*(alphanum / "-" / "." / "!" / "%"
standard MIME header in a SEND request. This is not included in / "*" / "_" / "+"
this version for the sake of getting the draft out as soon as
possible, but will follow soon.
6.8.2 VISIT quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE
qdtext = SP / HT / %x21 / %x23-5B / %x5D-7E
/ UTF8-NONASCII
qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE)
BACKSLASH = "\"
DQUOTE = %x22
The visiting endpoint uses the VISIT method to associate a network Other-Mime-Header = (Content-ID
connection with the session state at the listening device. A VISIT / Content-Description
request MUST include a To-Path header including the sender's remote / Content-Disposition
path, and a From-Path header field containing the sender's local URL. / mime-extension-field);
This purpose can also be served by a SEND request, if the sender has ; Content-ID, and Content-Description are defined in RFC2045.
immediate content to send. ; Content-Disposition is defined in RFC2183
; MIME-extension-field indicates additional MIME extension
; headers as described in RFC2045
Open Issue: There is overlap between SEND and VISIT as currently data = *OCTET
defined. We should consider either removing VISIT entirely and end-line = "-------" transact-id continuation-flag CRLF
just use an empty SEND request, or we should always require VISIT. continuation-flag = "+" / "$"
(This would not apply to a endpoint connecting to its own relay.)
6.8.3 REPORT ext-header = hname ":" SP hval CRLF
hname = alpha *token
hval = utf8text
Report is used by an endpoint or relay to convey message delivery utf8text = *(HT / %x20-7E / UTF8-NONASCII)
status
6.9 Response Code Descriptions UTF8-NONASCII = %xC0-DF 1UTF8-CONT
/ %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT
/ %xF8-Fb 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF
This section summarizes the various response codes. Except where 10. Response Code Descriptions
noted, all responses MUST contain a TR-ID header field matching the
TR-ID header field of the original request, and To-Path and From-Path
headers matching those of the original request.
6.9.1 200 This section summarizes the semantics of various response codes that
may be used in MSRP transaction responses. These codes may also be
used in the Status header in REPORT requests.
10.1 200
The 200 response code indicates a successful transaction. The 200 response code indicates a successful transaction.
6.9.2 400 10.2 400
A 400 response indicates a request was unintelligible. A 400 response indicates a request was unintelligible.
6.9.3 415 10.3 403
The action is not allowed
10.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.
6.9.4 426 10.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.
6.9.5 481 10.6 481
A 481 response indicates that no session exists for the connection. A 481 response indicates that no session exists for the connection.
6.9.6 506 10.7 506
A 506 response indicates that a VISIT request occurred in which the
To-Path header indicates a local path that is already associated with
another connection. A 506 response MUST NOT be returned in response
to any method other than VISIT.
6.10 Header Field Descriptions
This section summarizes the various header fields. MSRP header
fields are single valued; that is, they MUST NOT occur more than once
in a particular request or response.
6.10.1 TR-ID
The TR-ID header field contains a transaction identifier used to map
a response to the corresponding request. A TR-ID value MUST be
unique among all values used by a given endpoint inside a given
session. MSRP elements MUST NOT assume any additional semantics for
TR-ID.
6.10.2 Message-ID
The Message-ID header field contains a message identifier used to map
a delivery status notification to the corresponding request. TR-ID
cannot be used for this purpose, as it may change between hops if
relays are involved. A Message-ID value MUST be unique among all
values used by a given endpoint inside a given session. MSRP
elements MUST NOT assume any additional semantics for Message-ID.
The Message-ID value MAY be the same as the original TR-ID value.
6.10.3 To-Path
The To-Path header field is used to indicate the sender's remote
path. All MSRP requests MUST contain a To-Path header field.
6.10.4 From-Path
The From-Path header field is used to indicate the sender's local
URL. All MSRP requests MUST contain a From-Path header field.
6.10.5 Boundary
The Boundary header field contains the boundary string that is used
to terminate the message. This string MUST have at least 16 bits of
randomness. This string MUST NOT be duplicated anywhere else in the
message. The Boundary header field is mandatory for all MSRP
messages, and SHOULD be the first header field in the message.
6.10.6 Closing
The Closing field contains the same boundary string that was
originally listed in the Boundary header field, as well as the
Continuation-Flag field. The Closing field MUST occur at the end of
each MSRP message. If the message content has been sent completely,
the Interrupt-Flag field value MUST be ""$ (dollar sign). If there
is further content to send as part of the "logical" instant message,
this field value MUST be "+". (plus sign.)
6.10.7 Content-Type
The Content-Type header field is used to indicate the MIME media type A 506 response indicates that a request arrived on a session which is
of the body. Content-Type MUST be present if a body is present. already bound to another network connection.
To Do: The work group has agreed to allow the use of any standard 11. Examples
MIME header. This is not reflected in this version, but will be
in a shortly forthcoming one.
7. Example 11.1 Basic IM session
This section shows an example message flow for the most common This section shows an example flow for the most common scenario. The
scenario. The example assumes SIP is used to transport the SDP example assumes SIP is used to transport the SDP exchange. Details
exchange. Details of the SIP messages and SIP proxy infrastructure of the SIP messages and SIP proxy infrastructure are omitted for the
are omitted for the sake of brevity. In the example, assume the sake of brevity. In the example, assume the offerer is
offerer is sip:alice@atlanta.com and the answerer is sip:alice@example.com and the answerer is sip:bob@example.com.
sip:bob@biloxi.com.
Alice Bob Alice Bob
| | | |
| | | |
|(1) (SIP) INVITE | |(1) (SIP) INVITE |
|----------------------->| |----------------------->|
|(4) (SIP) 200 OK | |(4) (SIP) 200 OK |
|<-----------------------| |<-----------------------|
|(5) (SIP) ACK | |(5) (SIP) ACK |
|----------------------->| |----------------------->|
skipping to change at page 32, line 48 skipping to change at page 34, line 30
|(9) (MSRP) 200 OK | |(9) (MSRP) 200 OK |
|----------------------->| |----------------------->|
|(10) (SIP) BYE | |(10) (SIP) BYE |
|----------------------->| |----------------------->|
|(11) (SIP) 200 OK | |(11) (SIP) 200 OK |
|<-----------------------| |<-----------------------|
| | | |
| | | |
1. Alice constructs a local URL of 1. Alice constructs a local URL of
msrp://alicepc.atlanta.com:7777/iau39 and listens for a msrp://alicepc.example.com:7777/iau39;tcp .
connection on TCP port 7777.
Alice->Bob (SIP): INVITE sip:bob@example.com
Alice->Bob (SIP): INVITE sip:bob@biloxi.com
v=0 v=0
o=alice 2890844557 2890844559 IN IP4 host.anywhere.com o=alice 2890844557 2890844559 IN IP4 alicepc.example.com
s= s=
c=IN IP4 fillername c=IN IP4 alicepc.example.com
t=0 0 t=0 0
m=message 9999 msrp * m=message 9 msrp *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrp://alicepc.atlanta.com:7777/iau39 a=path:msrp://alicepc.example.com:7777/iau39;tcp
2. Bob->Alice (SIP): 200 OK 2. Bob listens on port 8888, and sends the following response:
3. Bob->Alice (SIP): 200 OK
v=0 v=0
o=bob 2890844612 2890844616 IN IP4 host.anywhere.com o=bob 2890844612 2890844616 IN IP4 bob.example.com
s= s=
c=IN IP4 ignorefield c=IN IP4 bob.example.com
t=0 0 t=0 0
m=message 9999 msrp * m=message 9 msrp *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrp://bob.atlanta.com:8888/9di4ea a=path:msrp://bob.example.com:8888/9di4ea;tcp
3. Alice->Bob (SIP): ACK 4. Alice->Bob (SIP): ACK
4. (Alice opens connection to Bob. This may occur in parallel with 5. (Alice opens connection to Bob.) Alice->Bob (MSRP):
the previous step.) Alice->Bob (MSRP):
MSRP SEND MSRP d93kswow SEND
Boundary: d93kswow To-Path:msrp://bob.example.com:8888/9di4ea;tcp
To-Path:msrp://bob.atlanta.com:8888/9di4ea From-Path:msrp://alicepc.example.com:7777/iau39;tcp
From-Path:msrp://alicepc.atlanta.com:7777/iau39 Message-ID: 12339sdqwer
TR-ID: 123 Content-Type:text/plain
Message-ID: 123
Content-Type: "text/plain"
Hi, I'm Alice! Hi, I'm Alice!
-------d93kswow$ -------d93kswow$
5. Bob->Alice (MSRP): 6. Bob->Alice (MSRP):
MSRP 200 OK MSRP d93kswow 200 OK
Boundary: 839s9ed To-Path:msrp://bob.example.com:8888/9di4ea;tcp
To-Path:msrp://bob.atlanta.com:8888/9di4ea From-Path:msrp://alicepc.example.com:7777/iau39;tcp
From-Path:msrp://alicepc.atlanta.com:7777/iau39 -------d93kswow$
TR-ID: 123
-------839s9ed$
6. Bob->Alice (MSRP): 7. Bob->Alice (MSRP):
MSRP SEND MSRP dkei38sd SEND
Boundary: dkei38sd To-Path:msrp://alice.example.com:7777/iau39;tcp
To-Path:msrp://alice.atlanta.com:7777/iau39 From-Path:msrp://bob.example.com:8888/9di4ea;tcp
From-Path:msrp://bob.atlanta.com:8888/9di4ea
TR-ID: 456
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$
7. Alice->Bob (MSRP): 8. Alice->Bob (MSRP):
MSRP 200 OK MSRP dkei38sd 200 OK
Boundary: diw3ids To-Path:msrp://alice.example.com:7777/iau39;tcp
To-Path:msrp://alice.atlanta.com:7777/iau39 From-Path:msrp://bob.example.com:8888/9di4ea;tcp
From-Path:msrp://bob.atlanta.com:8888/9di4ea -------dkei38sd$
TR-ID: 456
-------diw3ids$
8. Alice->Bob (SIP): BYE 9. Alice->Bob (SIP): BYE
Alice invalidates local session state. Alice invalidates local session state.
9. Bob invalidates local state for the session. 10. Bob invalidates local state for the session.
Bob->Alice (SIP): 200 OK Bob->Alice (SIP): 200 OK
8. IANA Considerations 11.2 Chunked Message
8.1 MSRP Port For an example of a chunked message, see the example in Section 4.1.
MSRP uses TCP port XYX, to be determined by IANA after this document 11.3 System Message
is approved for publication. Usage of this value is described in
Section 6.1
8.2 MSRP URL Schema Sysadmin->Alice (MSRP):
This document defines the URL schema of "msrp" "msrps", "smsrp", and MSRP d93kswow SEND
"smsrps". To-Path:msrp://alicepc.example.com:8888/9di4ea;tcp
From-Path:msrp://example.com:7777/iau39;tcp
Message-ID: 12339sdqwer
Report-Failure: no
Report-Success: no
Content-Type:text/plain
The system is going down in 5 minutes
-------d93kswow$
8.2.1 Syntax 11.4 Positive Report
See Section 6.1. Alice->Bob (MSRP):
8.2.2 Character Encoding MSRP d93kswow SEND
To-Path:msrp://bob.example.com:8888/9di4ea;tcp
From-Path:msrp://alicepc.example.com:7777/iau39;tcp
Message-ID: 12339sdqwer
Report-Success: yes
Content-Type:text/html
See Section 6.1. <html><body>
<p>Here is that important link...
<a href="www.example.com/foobar">foobar</a>
</p>
</body></html>
-------d93kswow$
8.2.3 Intended Usage Bob->Alice (MSRP):
See Section 6.1. MSRP d93kswow 200 OK
To-Path:msrp://alicepc.example.com:7777/iau39;tcp
From-Path:msrp://bob.example.com:8888/9di4ea;tcp
-------d93kswow$
8.2.4 Protocols Bob->Alice (MSRP):
The Message Session Relay Protocol (MSRP). MSRP dkei38sd SEND
To-Path:msrp://alicepc.example.com:7777/iau39;tcp
From-Path:msrp://bob.example.com:8888/9di4ea;tcp
Message-ID: 12339sdqwer
Status: 000 200 OK
-------dkei38sd$
8.2.5 Security Considerations 11.5 Forked IM
See Section 9. Traditional IM systems generally do a poor job of handling multiple
simultaneous IM clients online for the same person. While some do a
better job than many existing systems, handling of multiple clients
is fairly crude. This becomes a much more significant issue when
always-on mobile devices are available, but when it is desirable to
use them only if another IM client is not available.
8.2.6 Relevant Publications Using SIP makes rendezvous decisions explicit, deterministic, and
very flexible; instead "pager-mode" IM systems use implicit
implementation-specific decisions which IM clients cannot influence.
RFCXXXX With SIP session mode messaging rendezvous decisions can be under
control of the client in a predictable, interoperable way for any
host that implements callee capabilities [30]. As a result,
rendezvous policy is managed consistently for each address of record.
[Note to RFC Editor: Please replace RFCXXXX in the above paragraph The following example shows Juliet with several IM clients where she
with the actual number assigned to this document. can be reached. Each of these has a unique SIP Contact and MSRP
session. The example takes advantage of SIP's capability to "fork"
an invitation to several Contacts in parallel, in sequence, or in
combination. Juliet has registered from her chamber, the balcony,
her PDA, and as a last resort, you can leave a message with her
Nurse. Juliet's contacts are listed below. The q-values express
relative preference (q=1.0 is the highest preference).
8.3 SDP Parameters We query for a list of Juliet's contacts by sending a REGISTER:
This document registers the following SDP parameters in the REGISTER sip:thecapulets.example.com SIP/2.0
sdp-parameters registry: To: Juliet <sip:juliet@thecapulets.example.com>
From: Juliet <sip:juliet@thecapulets.example.com>;tag=12345
Call-ID: 09887877
CSeq: 772 REGISTER
8.3.1 Accept Types The Response contains her Contacts:
Attribute-name: accept-types SIP/2.0 200 OK
Long-form Attribute Name Acceptable MIME Types To: Juliet <sip:juliet@thecapulets.example.com>
Type: Media level From: Juliet <sip:juliet@thecapulets.example.com>;tag=12345
Subject to Charset Attribute No Call-ID: 09887877
Purpose and Appropriate Values See Section 5.2. CSeq: 771 REGISTER
Contact: <sip:juliet@balcony.thecapulets.example.com>
;q=0.9;expires=3600
Contact: <sip:juliet@chamber.thecapulets.example.com>
;q=1.0;expires=3600
Contact: <sip:jcapulet@veronamobile.example.net>;q=0.4;expires=3600
Contact: <sip:nurse@thecapulets.example.com>;q=0.1;expires=3600
8.3.2 Wrapped Types When Romeo opens his IM program, he selects Juliet and types the
message "art thou hither?" (instead of "you there?"). His client
sends a SIP invitation to sip:juliet@thecapulets.example.com. The
Proxy there tries first the balcony and the chamber simultaneously.
A client is running on both those systems, both of which setup early
sessions of MSRP with Romeo's client. The client automatically sends
the message over the MSRPS to the two MSPR URIs involved. After a
delay of a several seconds with no reply or activity from Juliet, the
proxy cancels the invitation at her first two contacts, and forwards
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
sends a "Busy Here" response. The proxy then tries the Nurse, who
answers and tells Romeo what is going on.
Attribute-name: accept-wrapped-types Romeo Juliet's Juliet/ Juliet/ Juliet/ Nurse
Long-form Attribute Name Acceptable MIME Types Inside Wrappers Proxy balcony chamber PDA
Type: Media level
Subject to Charset Attribute No
Purpose and Appropriate Values See Section 5.3.
8.3.3 Path | | | | | |
|--INVITE--->| | | | |
| |--INVITE--->| | | |
| |<----180----| | | |
|<----180----| | | | |
|---PRACK---------------->| | | |
|<----200-----------------| | | |
|<===Early MSRP Session==>| art thou hither? | |
| | | | | |
| |--INVITE---------------->| | |
| |<----180-----------------| | |
|<----180----| | | | |
|---PRACK----------------------------->| | |
|<----200------------------------------| | |
|<========Early MSRP Session==========>| art thou hither? |
| | | | | |
| | | | | |
| | .... Time Passes .... | | |
| | | | | |
| | | | | |
| |--CANCEL--->| | | |
| |<---200-----| | | |
| |<---487-----| | | |
| |----ACK---->| | | |
| |--CANCEL---------------->| | |
| |<---200------------------| | |
| |<---487------------------| | |
| |----ACK----------------->| | |
| |--INVITE---------------------------->| romeo wants
| | | | | to IM w/ you
| |<---486 Busy Here--------------------| |
| |----ACK----------------------------->| |
| | | | | |
| |--INVITE---------------------------------------->|
| |<---200 OK---------------------------------------|
|<--200 OK---| | | | |
|---ACK------------------------------------------------------->|
|<================MSRP Session================================>|
| | | | | |
| Hi Romeo, Juliet is |
| with her father now |
| can i take a message?|
| |
| Tell her to go to confession tommorrow.... |
Attribute-name: path 12. Extensibility
Long-form Attribute Name MSRP URL Path
Type: Media level
Subject to Charset Attribute No
Purpose and Appropriate Values See Section 5.4.
8.4 IANA registration forms for DSN types MSRP was designed to be only minimally extensible. New MSRP Methods,
Headers, and status codes can be defined in standards track RFCs.
There is no registry of headers, methods, or status codes, since the
number of new elements and total extensions is expected to be very
small. MSRP does not contain a version number or any negotiation
mechanism to require or discover new features.
8.4.1 IANA registration form for address-type 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
functionality being added. In addition, msrp: and msrps: URLs can
contain parameters which are extensible.
This document registers a new 'address-type' for use in conjunction 13. CPIM compatibility
with RFC1894[10]. The authors request that these values be recorded
in the IANA registry for DSN 'address-type'.
Proposed Address name: msrp-address-type MSRP sessions may be gatewayed to other CPIM [25]compatible
protocols. If this occurs, the gateway MUST maintain session state,
and MUST translate between the MSRP session semantics and CPIM
semantics that do not include a concept of sessions. Furthermore,
when one endpoint of the session is a CPIM gateway, instant messages
SHOULD be wrapped in "message/cpim" [7] bodies. Such a gateway MUST
include "message/cpim" as the first entry in its SDP accept-types
attribute. MSRP endpoints sending instant messages to a peer that
has included 'message/cpim" as the first entry in the accept-types
attribute SHOULD encapsulate all instant message bodies in "message/
cpim" wrappers. All MSRP endpoints MUST support the message/cpim
type, and SHOULD support the S/MIME features of that format.
Syntax: See Section 6.1 14. Security Considerations
8.4.2 IANA registration form for MTA-name-type Instant Messaging systems are used to exchange a variety of sensitive
information ranging from personal conversations, to corporate
confidential information, to account numbers and other financial
trading information. IM is used by individuals, corporations, and
governments for communicating important information. Like many
communications systems, the properties of Integrity and
Confidentiality of the exchanged information, along with the
possibility of Anonymous communications, and knowing you are
communicating with the correct other party are required. MSRP pushes
many of the hard problems to SIP when SIP sets up the session, but
some of the problems remain. Spam and DoS attacks are also very
relevant to IM systems.
This document registers a new 'MTA-name-type' for use in conjunction MSRP needs to provide confidentiality and integrity for the messages
with RFC1894[10]. The authors request that these values be recorded it transfers. It also needs to provide assurances the connected host
in the IANA registry for DSN 'MTA-name-type'. is the host that it meant to connect to and that the connection has
not been hijacked.
Proposed Address name: msrp-name-type When using only TCP connections, MSRP security is fairly weak. If
host A is contacting B, B passes its hostname and a secret to A using
SIP. If the SIP offer or answer is not TLS or S/MIME [27] protected,
anyone can see this secret. A then connects to the provided host
name and passes the secret in the clear across the connection to B.
A assumes that it is talking to B based on where it sent the SYN
packet and then delivers the secret in plain text across the
connections. B assumes it is talking to A because the host on the
other end of the connection delivered the secret. An attacker that
could ACK the SYN packet could insert itself as a man in the middle
in the connection.
Syntax: See See Section 6.1 When using TLS connections, the security is significantly improved.
We assume that the host accepting the connection has a certificate
from a well know certificate authority. Furthermore, we assume that
the SIP signaling to set up the session is protected with TLS (using
sips). In this case, when host A contacts host B, the secret is
passed through a SIP confidential channel to A. A connects with TLS
to B. B presents a valid certificate, so A knows it really is
connected to B. A then delivers the secret provided by B, so that B
can verify it is connected to A. In this case, a rogue SIP Proxy can
see the secret in the SIP signaling traffic and could potentially
insert itself as a man-in-the-middle.
9. Security Considerations Realistically, using TLS is only feasible when connecting to gateways
or relays , as the types of hosts that end clients use for sending
instant messages are unlikely to have a long term stable IP address
or a stable DNS name that a certificate can bind to. In addition,
the cost of server certificates from well known certificate
authorities is currently too high for the vast majority of end users
to even consider getting one for each client.
There are a number of security considerations for MSRP, some of which The only real security for connections without relays is achieved
are mentioned elsewhere in this document. This section discusses using S/MIME. This does not require the actual endpoint to have
those further, and introduces some new ones. certificates from a well known certificate authority. The Identity
[22] and Certificates [23] mechanism with SIP provides S/MIME based
delivery of a secret between A and B. No SIP intermediary except the
explicitly trusted authentication service (one per user) can see the
secret. The S/MIME encryption of the SDP can also be used by SIP to
exchange keying material that can be used in MRSP. The MSRP session
can then use S/MIME with this keying material to encrypt and sign
messages sent over MSRP. The connection can still be hijacked since
the secret is sent in clear text to the other end of the TCP
connection, but this risk is mitigated if all the MSRP content is
encrypted and signed with S/MIME.
9.1 TLS and the MSRPS Scheme MSRP can not be used as an amplifier for DoS attacks, but it can be
used to form a distributed attack to consume TCP connection resource
on servers. The attacker, Eve, sends an SIP INVITE with no offer to
Alice. Alice returns a 200 with an offer and Eve returns an answer
with the SDP that indicates that her MSRP address is the address of
Tom. Since Alice sent the offer, Alice will initiate a connection to
Tom using up resources on Tom's server. Given the huge number of IM
clients, and the relatively few TCP connections that most servers
support, this is a fairly straightforward attack.
All MSRP devices must support TLS, with at least the SIP is attempting to address issues in dealing with spam. The spam
TLS_RSA_WITH_AES_128_CBC_SHA [8] cipher suite. Other cipher suites issue is probably best dealt with at the SIP level when an MSRP
MAY be supported. session is initiated and not at the MSRP level.
MSRP does not define a separate TCP port for TLS connections. This TLS is used to authenticate devices and to provide integrity and
means that all MSRP server devices, that is, all devices that listen confidentiality for the headers being transported. MSRP elements
for TCP connections, MUST be prepared to handle both TLS and plain MUST implement TLS and MUST also implement the TLS
text connections on the same port. When a device accepts a TCP ClientExtendedHello extended hello information for server name
connection, it MUST watch for the TLS handshake messages to determine indication as described in [12]. A TLS cipher-suite of
if a particular connection uses TLS. If the first data received is TLS_RSA_WITH_AES_128_CBC_SHA [15] MUST be supported (other
not part of a start TLS request, the device ceases to watch for the cipher-suites MAY also be supported).
TLS handshake until it reads the entire message. Once the message
has been completely received, the device resumes watching for the
start TLS message.
Any MSRP device MAY refuse to accept a given request over a non-TLS Since MSRP carries arbitrary MIME content, it can trivially carry S/
connection by returning a 426 response. MIME protected messages as well. All MSRP implementations MUST
support the multipart/signed MIME type even if they do not support S/
MIME. Since SIP can carry a session key, S/MIME messages in the
context of a session could also be protected using a key-wrapped
shared secret [26] provided in the session setup.
MSRP devices acting in the role of TCP client MAY perform a TLS 15. IANA Considerations
handshake at any time, as long as the request occurs between MSRP
messages. The endpoint MUST NOT send a start TLS request in the
middle of an MSRP message.
The working group considered only requiring the endpoint to watch 15.1 MSRP Port
for a TLS handshake at the beginning of the session. However, the
endpoint should be able to determine if a new message is a start
TLS request or an MSRP request by only reading ahead three bytes.
Therefore, the working group chose to allow a session to switch to
TLS in mid-stream, as long as the switch occurs between MRSP
messages.
There have since been proposals that we only allow start-tls at MSRP uses TCP port XYX, to be determined by IANA after this document
connection time. Do we have a consensus here one way or the is approved for publication. Usage of this value is described in
other? Section 5
The "msrps" and "smsrps" URI schema indicates that the connection 15.2 MSRP URL Schemes
MUST be protected with TLS.
Relay handling of "msrps" and "smsrps" are beyond the scope of This document defines the URL schemes of "msrp" and "msrps".
this document. However, any relay specification MUST explicitly
specify this.
MSRP requests for "msrps" URLs MUST be sent over TLS protected Syntax See Section 5.
connections. If a device receives a request for a "msrps" or Character Encoding See Section 5.
"smsrps" URL over an unprotected connection, it MUST reject the Intended Usage See Section 5.
request with a 426 response. Protocols The Message Session Relay Protocol (MSRP).
Security Considerations See Section 14.
Relevant Publications RFCXXXX
[Note to RFC Editor: Please replace RFCXXXX in the above
paragraph with the actual number assigned to this document.
9.1.1 Sensitivity of Session URLs 15.3 SDP Parameters
The URLs sent in the SDP offer/answer exchange for a MSRP session are This document registers the following SDP parameters in the
used by the endpoints to identify each other. If an attacker were sdp-parameters registry:
able to acquire the session URL, either by guessing it or by
eavesdropping, there is a window of opportunity in which the attacker
could hijack the session connecting and sending a MSRP request to the
listening device before the legitimate peer. Because of this
sensitivity, these URLs SHOULD be constructed in a way to make them
difficult to guess, and should be sufficiently random so that it is
unlikely to be reused. All mechanisms used to transport these URLs
SHOULD be protected from eavesdroppers and man-in-the-middle attacks.
Therefore a MSRP device MUST support the use of TLS for all MSRP 15.3.1 Accept Types
messages. Further, MSRP connections SHOULD actually be protected
with TLS. Further, an MSRP endpoint MUST be capable of using the
security features of the signaling protocol in order to protect the
SDP exchange and SHOULD actually use them on all such exchanges.
End-to-end protection schemes SHOULD be preferred over hop-by-hop
schemes for protection of the SDP exchange.
9.1.2 End to End Protection of IMs Attribute-name: accept-types
Long-form Attribute Name Acceptable MIME Types
Type: Media level
Subject to Charset Attribute No
Purpose and Appropriate Values See Section 7.1.
Instant messages can contain very sensitive information. As a 15.3.2 Wrapped Types
result, as specified in RFC 2779 [3], instant messaging protocols
need to provide for encryption, integrity and authentication of
instant messages. Therefore MSRP endpoints MUST support the
end-to-end encryption and integrity of bodies sent via SEND requests
using Secure MIME (S/MIME) [7].
Note that while each protected body could use separate keying Attribute-name: accept-wrapped-types
material, this is inefficient in that it requires an independent Long-form Attribute Name Acceptable MIME Types Inside Wrappers
public key operation for each message. Endpoints wishing to invoke Type: Media level
end-to-end protection of message sessions SHOULD exchange symmetric Subject to Charset Attribute No
keys in SDP k-lines, and use secret key encryption on for each MSRP Purpose and Appropriate Values See Section 7.1.
message. When symmetric keys are present in the SDP, the
offer-answer exchange MUST be protected from eavesdropping and
tampering using the appropriate facilities of the signaling protocol.
For example, if the signaling protocol is SIP, the SDP exchange MUST
be protected using S/MIME.
9.1.3 CPIM compatibility 15.3.3 Path
MSRP sessions may be gatewayed to other CPIM [19]compatible Attribute-name: path
protocols. If this occurs, the gateway MUST maintain session state, Long-form Attribute Name MSRP URL Path
and MUST translate between the MSRP session semantics and CPIM Type: Media level
semantics that do not include a concept of sessions. Furthermore, Subject to Charset Attribute No
when one endpoint of the session is a CPIM gateway, instant messages Purpose and Appropriate Values See Section 7.1.1.
SHOULD be wrapped in "message/cpim" [5] bodies. Such a gateway MUST
include "message/cpim" as the first entry in its SDP accept-types
attribute. MSRP endpoints sending instant messages to a peer that
has included 'message/cpim" as the first entry in the accept-types
attribute SHOULD encapsulate all instant message bodies in "message/
cpim" wrappers. All MSRP endpoints MUST support the message/cpim
type, and SHOULD support the S/MIME features of that format.
9.1.4 PKI Considerations 15.4 IANA registration forms for DSN types
Several aspects of MSRP will benefit from being used in the context 15.4.1 IANA registration form for address-type
of a public key infrastructure. For example, the MSRPS scheme
allows, and even encourages, TLS connections between endpoint
devices. And while MSRP allows for a symmetric session key to
protect all messages in a session, it is most likely that session key
itself would be exchanged in a signaling protocol such as SIP. Since
that key is extremely sensitive, its exchange would also need to be
protected. In SIP, the preferred mechanism for this would be S/MIME,
which would also benefit from a PKI.
However, all of these features may be used without PKI. Each This document registers a new 'address-type' for use in conjunction
endpoint could instead use self signed certificates. This will, of with RFC1894[8]. The authors request that these values be recorded
course, be less convenient than with a PKI, in that there would be no in the IANA registry for DSN 'address-type'.
certificate authority to act as a trusted introducer. Peers would be
required to exchange certificates prior to securely communicating.
Since, at least for the immediate future, any given MSRP Proposed Address name: msrp-address-type
implementation is likely to communicate with at least some peers that Syntax: See Section 5
do not have a PKI available, MSRP implementations SHOULD support the
use of self-signed certificates, and SHOULD support the ability to
configure lists of trusted certificates.
To Do: Add text discussion the use of TLS certificates in more 15.4.2 IANA registration form for MTA-name-type
detail.
10. Changes from Previous Draft Versions 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'.
This section to be deleted prior to publication as an RFC Proposed Address name: msrp-name-type
10.1 draft-ietf-simple-message-sessions-06 Syntax: See Section 5
16. Change History
16.1 draft-ietf-simple-message-sessions-07
Significant re-write to attempt to improve readability.
Added maximum size parameter in accept-types
Changed the Boundary field to be part of the start-line rather
than a header field.
Removed the TR-IDheader, and changed request-response matching to
be based on the Boundary field value. Responses still contain the
TR-ID header, which must match the Boundary from the request.
Removed transport selection from URL scheme and added the "tcp"
parameter.
Added description of the "simple" mode with no transaction
responses, and made mode selection dependent on the reporting
level requested for a give message.
Changed the DSN section to reflect separate request of success and
failure reports. Enhanced REPORT method to be useful even without
a payload.
removed SRV usage for URL resolution. This is only used for relay
discovery, and therefore should be moved to the relay draft.
Added discussion about late REPORT handling. Asserted that REPORT
requests are always sent in simple mode.
Removed the dependency on multipart/byteranges for fragmentation.
Incorporated the Byte-Range header into the base MSRP header set.
Removed the VISIT method. Change to use SEND to serve the purpose
formerly reserved to VISIT.
16.2 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 section--changes from version 05 were erroneously Fixed change TR-ID header from version 05 were erroneously
attributed to 04. attributed to 04.
10.2 draft-ietf-simple-message-sessions-05 16.3 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
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
skipping to change at page 40, line 20 skipping to change at page 45, line 38
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.
10.3 draft-ietf-simple-message-sessions-04 16.4 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.
10.4 draft-ietf-simple-message-sessions-03 16.5 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 40, line 48 skipping to change at page 46, line 18
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.
10.5 draft-ietf-simple-message-sessions-02 16.6 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 alogorithm. 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.
10.6 draft-ietf-simple-message-sessions-01 16.7 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
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.
10.7 draft-ietf-simple-message-sessions-00 16.8 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 42, line 17 skipping to change at page 47, line 36
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.
10.8 draft-campbell-simple-im-sessions-01 16.9 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.
11. Contributors 17. Contributors and Acknowledgments
In addition to the editor, The following people contributed extensive In addition to the editor, The following people contributed extensive
work to this document: work to this document: Chris Boulton, Cullen Jennings, Paul Kyzivat,
Rohan Mahy, Adam Roach, Jonathan Rosenberg, Robert Sparks.
Chris Boulton
Cullen Jennings
Paul Kyzivat
Rohan Mahy
Adam Roach
Jonathan Rosenberg
Robert Sparks
12. Acknowledgments
The following people contributed substantial discussion and feedback The following people contributed substantial discussion and feedback
to this ongoing effort: to this ongoing effort: Allison Mankin, Jon Peterson, Brian Rosen,
Allison Mankin Jon Peterson Brian Rosen Dean Willis Dean Willis, Aki Niemi, Hisham Khartabil, Pekka Pessi, Orit Levin.
Aki Niemi Hisham Khartabil Pekka Pessi Orit Levin
13. References 18. References
13.1 Normative References 18.1 Normative References
[1] Handley, M. and V. Jacobson, "SDP: Session Description [1] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[2] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Presence Protocol Requirements", RFC 2779, February 2000. Levels", BCP 14, RFC 2119, March 1997.
[4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Resource Identifiers (URL): Generic Syntax", RFC 2396, August Specifications: ABNF", RFC 2234, November 1997.
1998.
[5] 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.
[6] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for [8] Moore, K. and G. Vaudreuil, "An Extensible Message Format for
specifying the location of services (DNS SRV)", RFC 2782, Delivery Status Notifications", RFC 1894, January 1996.
February 2000.
[7] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC [9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
2633, June 1999. Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[8] Chown, P., ""Advanced Encryption Standard (AES) Ciphersuites [10] Troost, R., Dorner, S. and K. Moore, "Communicating
for Transport Layer Security (TLS)", RFC 3268, June 2002. Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August 1997.
[9] Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 [11] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
(SHA1)", RFC 3174, September 2001. Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[10] Moore, K. and G. Vaudreuil, "An Extensible Message Format for [12] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and
Delivery Status Notifications", RFC 1894, January 1996. T. Wright, "Transport Layer Security (TLS) Extensions", RFC
3546, June 2003.
[11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., [13] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- Method", RFC 3311, October 2002.
HTTP/1.1", RFC 2616, June 1999.
13.2 Informational References [14] Atkins, D. and G. Klyne, "Common Presence and Instant
Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-08
(work in progress), January 2003.
[12] Campbell, B. and J. Rosenberg, "Session Initiation Protocol [15] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Extension for Instant Messaging", RFC 3428, September 2002. Transport Layer Secur ity (TLS)", RFC 3268, June 2002.
[13] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 18.2 Informational References
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[14] Mahy, R., Campbell, B., Sparks, R., Rosenberg, J., Petrie, D. [16] Johnston, A. and O. Levin, "Session Initiation Protocol Call
and A. Johnston, "A Multi-party Application Framework for SIP", Control - Conferencing for User Agents",
draft-ietf-sipping-cc-framework-02 (work in progress), May draft-ietf-sipping-cc-conferencing-03 (work in progress),
2003. February 2004.
[15] 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-04 (work Session Initiation Protocol", draft-ietf-sipping-3pcc-06 (work
in progress), June 2003. in progress), January 2004.
[16] Sparks, R. and A. Johnston, "Session Initiation Protocol Call [18] Sparks, R. and A. Johnston, "Session Initiation Protocol Call
Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in Control - Transfer", draft-ietf-sipping-cc-transfer-02 (work in
progress), February 2003. progress), February 2004.
[17] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of [19] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and
Resource Management and Session Initiation Protocol (SIP)", RFC D. Gurle, "Session Initiation Protocol (SIP) Extension for
3312, October 2002. Instant Messaging", RFC 3428, December 2002.
[18] Peterson, J., "A Privacy Mechanism for the Session Initiation [20] Mahy, R., "Benefits and Motivation for Session Mode Instant
Protocol (SIP)", RFC 3323 , November 2002. Messaging", draft-mahy-simple-why-session-mode-00 (work in
progress), February 2004.
[19] Peterson, J., "A Common Profile for Instant Messaging (CPIM)", [21] Mahy, R. and C. Jennings, "Relays for the Message Session Relay
draft-ietf-impp-im-04 (work in progress), August 2003. Protocol (MSRP)", draft-ietf-simple-msrp-relays-01.txt (work in
progress), July 2004.
[20] Yon, D., "Connection-Oriented Media Transport in SDP", [22] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-02 (work in progress), May 2004.
[23] Jennings, C. and J. Peterson, "Certificate Management Service
for SIP", draft-jennings-sipping-certs-03 (work in progress),
May 2004.
[24] Yon, D., "Connection-Oriented Media Transport in SDP",
draft-ietf-mmusic-sdp-comedia-05 (work in progress), March draft-ietf-mmusic-sdp-comedia-05 (work in progress), March
2003. 2003.
Author's Address [25] Peterson, J., "A Common Profile for Instant Messaging (CPIM)",
draft-ietf-impp-im-04 (work in progress), August 2003.
Ben Campbell [26] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217,
dynamicsoft December 2001.
5100 Tennyson Parkway
Suite 1200
Plano, TX 75024
EMail: bcampbell@dynamicsoft.com [27] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
2633, June 1999.
[28] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone
Generation in the Session Initiation Protocol (SIP)",
draft-ietf-sipping-early-media-02 (work in progress), June
2004.
[29] Saint-Andre, P., "Extensible Messaging and Presence Protocol
(XMPP): Instant Messaging and Presence", draft-ietf-xmpp-im-22
(work in progress), April 2004.
[30] Rosenberg, J., "Indicating User Agent Capabilities in the
Session Initiation Protocol (SIP)",
draft-ietf-sip-callee-caps-03 (work in progress), January 2004.
Authors' Addresses
Ben Campbell (editor)
EMail: ben@nostrum.com
Rohan Mahy
Cisco Systems, Inc.
5617 Scotts Valley Drive, Suite 200
Scotts Valley, CA 95066
USA
EMail: rohan@cisco.com
Cullen Jennings
Cisco Systems, Inc.
170 West Tasman Dr.
MS: SJC-21/2
San Jose, CA 95134
USA
EMail: fluffy@cisco.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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