draft-ietf-simple-message-sessions-04.txt   draft-ietf-simple-message-sessions-05.txt 
SIMPLE Working Group B. Campbell SIMPLE Working Group B. Campbell
Internet-Draft J. Rosenberg Internet-Draft J. Rosenberg
Expires: September 29, 2004 R. Sparks Expires: October 11, 2004 R. Sparks
dynamicsoft dynamicsoft
P. Kyzivat P. Kyzivat
Cisco Systems Cisco Systems
March 31, 2004 C. Boulton
Ubiquity Software Corporation
April 12, 2004
The Message Session Relay Protocol The Message Session Relay Protocol
draft-ietf-simple-message-sessions-04 draft-ietf-simple-message-sessions-05
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 36
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 http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. 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 September 29, 2004. This Internet-Draft will expire on October 11, 2004.
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 mechanism for transmitting a series of Instant Messages within a
session. MSRP sessions are managed using the Session Description session. MSRP sessions are managed using the Session Description
Protocol (SDP) offer/answer model carried by a signaling protocol Protocol (SDP) offer/answer model carried by a signaling 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation for Session-mode Messaging . . . . . . . . . . 4 2. Motivation for Session-mode Messaging . . . . . . . . . . 4
3. Scope of this Document . . . . . . . . . . . . . . . . . . 5 3. Scope of this Document . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6
5. Architectural Considerations . . . . . . . . . . . . . . . 7 5. Architectural Considerations . . . . . . . . . . . . . . . 7
5.1 Transferring Large Content . . . . . . . . . . . . . . . . 7
6. SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . 7 6. SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . 7
6.1 Use of the SDP M-line . . . . . . . . . . . . . . . . . . 8 6.1 Use of the SDP M-line . . . . . . . . . . . . . . . . . . 7
6.2 The Accept Types Attribute . . . . . . . . . . . . . . . . 8 6.2 The Accept Types Attribute . . . . . . . . . . . . . . . . 8
6.3 MIME Wrappers . . . . . . . . . . . . . . . . . . . . . . 9 6.3 MIME Wrappers . . . . . . . . . . . . . . . . . . . . . . 8
6.4 URL Negotiations . . . . . . . . . . . . . . . . . . . . . 10 6.4 URL Negotiations . . . . . . . . . . . . . . . . . . . . . 9
6.5 Path Attributes with Multiple URLs . . . . . . . . . . . . 11 6.5 Path Attributes with Multiple URLs . . . . . . . . . . . . 10
6.6 Updated SDP Offers . . . . . . . . . . . . . . . . . . . . 11 6.6 Updated SDP Offers . . . . . . . . . . . . . . . . . . . . 11
6.7 Example SDP Exchange . . . . . . . . . . . . . . . . . . . 12 6.7 Example SDP Exchange . . . . . . . . . . . . . . . . . . . 11
6.8 Connection Negotiation . . . . . . . . . . . . . . . . . . 12 6.8 Connection Negotiation . . . . . . . . . . . . . . . . . . 12
6.9 Negotiation of Delivery Status Notifications . . . . . . . 13 7. The Message Session Relay Protocol . . . . . . . . . . . . 12
7. The Message Session Relay Protocol . . . . . . . . . . . . 13 7.1 MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1 MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 13
7.1.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 14 7.1.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 13
7.1.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 14 7.1.3 The msrps URL Scheme . . . . . . . . . . . . . . . . . . . 14
7.1.3 The msrps URL Scheme . . . . . . . . . . . . . . . . . . . 15 7.2 Connection Managment . . . . . . . . . . . . . . . . . . . 14
7.2 Connection Managment . . . . . . . . . . . . . . . . . . . 15
7.3 MSRP messages . . . . . . . . . . . . . . . . . . . . . . 15 7.3 MSRP messages . . . . . . . . . . . . . . . . . . . . . . 15
7.4 MSRP Transactions . . . . . . . . . . . . . . . . . . . . 16 7.4 MSRP Transactions . . . . . . . . . . . . . . . . . . . . 16
7.5 MSRP Sessions . . . . . . . . . . . . . . . . . . . . . . 17 7.5 MSRP Sessions . . . . . . . . . . . . . . . . . . . . . . 17
7.5.1 Initiating an MSRP session . . . . . . . . . . . . . . . . 17 7.5.1 Initiating an MSRP session . . . . . . . . . . . . . . . . 17
7.5.2 Handling VISIT requests . . . . . . . . . . . . . . . . . 19 7.5.2 Handling VISIT requests . . . . . . . . . . . . . . . . . 19
7.5.3 Sending Instant Messages on a Session . . . . . . . . . . 19 7.5.3 Sending Instant Messages on a Session . . . . . . . . . . 19
7.5.4 Ending a Session . . . . . . . . . . . . . . . . . . . . . 20 7.5.4 Ending a Session . . . . . . . . . . . . . . . . . . . . . 20
7.5.5 Managing Session State and Connections . . . . . . . . . . 21 7.5.5 Managing Session State and Connections . . . . . . . . . . 21
7.6 Delivery Status Notifications . . . . . . . . . . . . . . 22 7.6 Delivery Status Notification . . . . . . . . . . . . . . . 22
7.7 Method Descriptions . . . . . . . . . . . . . . . . . . . 22 7.6.1 Endpoint DSN Request . . . . . . . . . . . . . . . . . . . 22
7.7.1 SEND . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.6.2 DSN generation . . . . . . . . . . . . . . . . . . . . . . 23
7.7.2 VISIT . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.6.3 Receiving positive DSN . . . . . . . . . . . . . . . . . . 24
7.8 Response Code Descriptions . . . . . . . . . . . . . . . . 22 7.6.4 Receiving negative DSN . . . . . . . . . . . . . . . . . . 24
7.8.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.6.5 DSN headers in MSRP . . . . . . . . . . . . . . . . . . . 24
7.8.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.7 Message Fragmentation . . . . . . . . . . . . . . . . . . 24
7.8.3 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.7.1 MSRP Usage of message/byteranges . . . . . . . . . . . . . 24
7.8.4 426 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.8 Method Descriptions . . . . . . . . . . . . . . . . . . . 25
7.8.5 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.8.1 SEND . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.8.6 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.8.2 VISIT . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.9 Header Field Descriptions . . . . . . . . . . . . . . . . 23 7.8.3 REPORT . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.9.1 TR-ID . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.9 Response Code Descriptions . . . . . . . . . . . . . . . . 26
7.9.2 To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.9.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.9.3 From . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.9.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.9.4 Content-Type . . . . . . . . . . . . . . . . . . . . . . . 24 7.9.3 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8. Example . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.9.4 426 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . 27 7.9.5 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 27 7.9.6 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.2 MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . . 27 7.10 Header Field Descriptions . . . . . . . . . . . . . . . . 26
9.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.10.1 TR-ID . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.2.2 Character Encoding . . . . . . . . . . . . . . . . . . . . 27 7.10.2 To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.2.3 Intended Usage . . . . . . . . . . . . . . . . . . . . . . 27 7.10.3 From . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.2.4 Protocols . . . . . . . . . . . . . . . . . . . . . . . . 27 7.10.4 Content-Type . . . . . . . . . . . . . . . . . . . . . . . 27
9.2.5 Security Considerations . . . . . . . . . . . . . . . . . 27 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.2.6 Relevant Publications . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . 30
9.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 28 9.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 30
9.3.1 Accept Types . . . . . . . . . . . . . . . . . . . . . . . 28 9.2 MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . . 30
9.3.2 Wrapped Types . . . . . . . . . . . . . . . . . . . . . . 28 9.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.3.3 Path . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.2.2 Character Encoding . . . . . . . . . . . . . . . . . . . . 30
10. Security Considerations . . . . . . . . . . . . . . . . . 28 9.2.3 Intended Usage . . . . . . . . . . . . . . . . . . . . . . 30
10.1 TLS and the MSRPS Scheme . . . . . . . . . . . . . . . . . 28 9.2.4 Protocols . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1.1 Sensitivity of the Session URL . . . . . . . . . . . . . . 29 9.2.5 Security Considerations . . . . . . . . . . . . . . . . . 30
10.1.2 End to End Protection of IMs . . . . . . . . . . . . . . . 30 9.2.6 Relevant Publications . . . . . . . . . . . . . . . . . . 30
10.1.3 CPIM compatibility . . . . . . . . . . . . . . . . . . . . 30 9.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 31
10.1.4 PKI Considerations . . . . . . . . . . . . . . . . . . . . 31 9.3.1 Accept Types . . . . . . . . . . . . . . . . . . . . . . . 31
11. Changes from Previous Draft Versions . . . . . . . . . . . 31 9.3.2 Wrapped Types . . . . . . . . . . . . . . . . . . . . . . 31
11.1 draft-ietf-simple-message-sessions-04 . . . . . . . . . . 31 9.3.3 Path . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.2 draft-ietf-simple-message-sessions-03 . . . . . . . . . . 32 10. Security Considerations . . . . . . . . . . . . . . . . . 31
11.3 draft-ietf-simple-message-sessions-02 . . . . . . . . . . 32 10.1 TLS and the MSRPS Scheme . . . . . . . . . . . . . . . . . 31
11.4 draft-ietf-simple-message-sessions-01 . . . . . . . . . . 32 10.1.1 Sensitivity of the Session URL . . . . . . . . . . . . . . 32
11.5 draft-ietf-simple-message-sessions-00 . . . . . . . . . . 33 10.1.2 End to End Protection of IMs . . . . . . . . . . . . . . . 33
11.6 draft-campbell-simple-im-sessions-01 . . . . . . . . . . . 33 10.1.3 CPIM compatibility . . . . . . . . . . . . . . . . . . . . 33
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . 34 10.1.4 PKI Considerations . . . . . . . . . . . . . . . . . . . . 34
Normative References . . . . . . . . . . . . . . . . . . . 34 11. Changes from Previous Draft Versions . . . . . . . . . . . 34
Informational References . . . . . . . . . . . . . . . . . 34 11.1 draft-ietf-simple-message-sessions-04 . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 35 11.2 draft-ietf-simple-message-sessions-03 . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . 37 11.3 draft-ietf-simple-message-sessions-02 . . . . . . . . . . 35
11.4 draft-ietf-simple-message-sessions-01 . . . . . . . . . . 35
11.5 draft-ietf-simple-message-sessions-00 . . . . . . . . . . 36
11.6 draft-campbell-simple-im-sessions-01 . . . . . . . . . . . 37
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . 37
Normative References . . . . . . . . . . . . . . . . . . . 37
Informational References . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . 40
1. Introduction 1. Introduction
The MESSAGE [10] extension to SIP [2] allows SIP to be used to The MESSAGE [12] extension to SIP [2] allows SIP to be used to
transmit instant messages. Instant messages sent using the MESSAGE transmit instant messages. Instant messages sent using the MESSAGE
method are normally independent of each other. This approach is often method are normally independent of each other. This approach is often
called page-mode messaging, since it follows a model similar to that called page-mode messaging, since it follows a model similar to that
used by many two-way pager devices. Page-mode messaging makes sense used by many two-way pager devices. Page-mode messaging makes sense
for instant message exchanges where a small number of messages occur. for instant message exchanges where a small number of messages occur.
Endpoints may treat page-mode messages as if they took place in an Endpoints may treat page-mode messages as if they took place in an
imaginative session, but there is no formal relationship between one imaginative session, but there is no formal relationship between one
message and another. message and another.
There are also applications in which it is useful for instant There are also applications in which it is useful for instant
skipping to change at page 5, line 30 skipping to change at page 5, line 30
of session initiation. This key can be used to protect each message of session initiation. This key can be used to protect each message
that is part of the session. This requires only symmetric key that is part of the session. This requires only symmetric key
operations for each subsequent IM, and no additional certificate operations for each subsequent IM, and no additional certificate
exchanges are required after the initial exchange. The establishment exchanges are required after the initial exchange. The establishment
of the session key can be done using standard techniques that apply of the session key can be done using standard techniques that apply
to voice and video, in addition to instant messaging. to voice and video, in addition to instant messaging.
Finally, SIP devices can treat message sessions like any other media 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. Any SIP feature that can be applied to other sorts of media
sessions can equally apply to message sessions. For example, sessions can equally apply to message sessions. For example,
conferencing [12], third party call control [13], call transfer [14], conferencing [14], third party call control [15], call transfer [16],
QoS integration [15], and privacy [16] can all be applied to message QoS integration [17], and privacy [18] can all be applied to message
sessions. sessions.
Messaging sessions can also reduce the overhead in each individual Messaging sessions can also reduce the overhead in each individual
message. In page-mode, each message needs to include all of the SIP 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 that are mandated by RFC 3261 [2]. However, many of these
headers are not needed once a context is established for exchanging headers are not needed once a context is established for exchanging
messages. As a result, messaging session mechanisms can be designed messages. As a result, messaging session mechanisms can be designed
with significantly less overhead. with significantly less overhead.
3. Scope of this Document 3. Scope of this Document
skipping to change at page 7, line 13 skipping to change at page 7, line 13
B->A (MSRP): 200 OK B->A (MSRP): 200 OK
B->A (MSRP): SEND (msrp://A/123) B->A (MSRP): SEND (msrp://A/123)
A->B (MSRP): 200 OK A->B (MSRP): 200 OK
5. Architectural Considerations 5. Architectural Considerations
There are a number of considerations that, if handled in a reasonable There are a number of considerations that, if handled in a reasonable
fashion, will allow more effective use of the protocols described in fashion, will allow more effective use of the protocols described in
this document. this document.
5.1 Transferring Large Content
MSRP endpoints may attempt to send very long messages in a session.
For example, most commercial instant messaging systems have a file
transfer feature. Since MSRP does not impose message size limits,
there is nothing to prevent endpoints from transferring files over
it.
An analysis of whether it makes sense to do this, rather than sending
such content over FTP, HTTP, or some other such protocol, is beyond
the scope of this document. However, implementers should be aware of
the impact of sending very large messages over MSRP. The primary
impact is, since MSRP is sent over TCP, is that any additional
messages that the sender wishes to send will be blocked until the
large transfer is complete. This includes responses to messages sent
by the peer. Therefore, any SEND transactions initiated by the peer
are likely to time out, even though they are received without
problems.
Further, there is no way to abort the sending of a very large message
before it is complete. For the sake of efficiency, the framing
mechanism in MSRP is very simple. There is no clean way to recover
framing if the complete message is not sent.
These issues can be mitigated greatly if the endpoint simply
establishes a separate session for the transfer. This allows the
transfer to be sent without interfering with any instant messages
being sent on other sessions. Further, the endpoint can abort the
transfer by simply tearing down the transfer session. Therefore, if a
peer wishes to send very large content, it SHOULD establish a
dedicated session for that purpose. It should also indicate that the
dedicated session is send only, so that the receiving endpoint does
not attempt to send content back along the same session.
6. SDP Offer-Answer Exchanges for MSRP Sessions 6. SDP Offer-Answer Exchanges for MSRP Sessions
MSRP sessions will typically be initiated using the Session MSRP sessions will typically be initiated using the Session
Description Protocol (SDP) [1] offer-answer mechanism, carried in the Description Protocol (SDP) [1] offer-answer mechanism, carried in the
Session Initiation Protocol (SIP) [2] or any other protocol Session Initiation Protocol (SIP) [2] or any other protocol
supporting it. supporting it.
6.1 Use of the SDP M-line 6.1 Use of the SDP M-line
The SDP "m"-line takes the following form: The SDP "m"-line takes the following form:
skipping to change at page 10, line 43 skipping to change at page 10, line 8
The answerer will use the offered URL(s) to resolve the host address The answerer will use the offered URL(s) to resolve the host address
and port when connecting, and to identify the target when sending and port when connecting, and to identify the target when sending
messages. For MSRP sessions, the address field in the C-line is not messages. For MSRP sessions, the address field in the C-line is not
relevant, and MUST be ignored. The port field in the M-line MUST be relevant, and MUST be ignored. The port field in the M-line MUST be
ignored if non-zero. Zero values have the usual meaning for SDP. ignored if non-zero. Zero values have the usual meaning for SDP.
Both offerer and answerer store the path values received from the Both offerer and answerer store the path values received from the
peer. For a given endpoint, the local URL is the URL that the peer. For a given endpoint, the local URL is the URL that the
endpoint put into a path attribute value to send to its peer. The endpoint put into a path attribute value to send to its peer. The
remote URL is the URL received from the peer. If the path attribute peer URL is the URL received from the peer. If the path attribute
received from the peer contains more than one URL, then the remote received from the peer contains more than one URL, then the peer URL
URL is the first one. The remote path is the entire path attribute is the last entry, while the first entry is the connection URL. If
value received from the peer. only one entry is present, then it is both the peer and connection
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 following example shows an SDP offer with a session URL of
"msrp://a.example.com:7394/2s93i" "msrp://a.example.com:7394/2s93i"
v=0 v=0
o=someuser 2890844526 2890844527 IN IP4 alice.example.com o=someuser 2890844526 2890844527 IN IP4 alice.example.com
s= s=
c=IN IP4 alice.example.com m=message 9999 msrp/tcp * c=IN IP4 alice.example.com m=message 9999 msrp/tcp *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrp://a.example.com:7394/2s93i a=path:msrp://a.example.com:7394/2s93i
The first URI in the path attribute MUST identify the endpoint that The first URI in the path attribute MUST identify the endpoint that
generated the SDP document, or some other location where that generated the SDP document, or some other location where that
endpoint wishes to receive messages associated with the session. If endpoint wishes to receive messages associated with the session. If
skipping to change at page 11, line 33 skipping to change at page 10, line 47
As mentioned previously, this document describes MSRP for As mentioned previously, this document describes MSRP for
peer-to-peer scenarios, that is, when no relays are used. However, we peer-to-peer scenarios, that is, when no relays are used. However, we
expect a separate document to describe the use of relays in the near expect a separate document to describe the use of relays in the near
future. The path attribute supports lists of URLs in order to future. The path attribute supports lists of URLs in order to
facilitate that work. For peer-to-peer session, a path attribute will facilitate that work. For peer-to-peer session, a path attribute will
contain exactly one URL, describing an endpoint. This means that contain exactly one URL, describing an endpoint. This means that
endpoints that only implement this specification will never send more endpoints that only implement this specification will never send more
than one URL in a path attribute, but MUST be prepared to receive than one URL in a path attribute, but MUST be prepared to receive
more than one. When an endpoint receives more than one URL in a path more than one. When an endpoint receives more than one URL in a path
header, only the first entry is relevant for purposes of resolving header, only the first entry is relevant for purposes of resolving
the address and port, and establishing the network connection. the address and port, and establishing the network connection, thus
the term connection URL.
If an endpoint puts more than one URL in a path attribute, final URL If an endpoint puts more than one URL in a path attribute, final URL
in the path attribute MUST exhibit the uniqueness properties in the path (the peer URL) attribute MUST exhibit the uniqueness
described above. Uniqueness requirements for other entries in the properties described above. Uniqueness requirements for other entries
attribute are out of scope for this document. in the attribute are out of scope for this document.
6.6 Updated SDP Offers 6.6 Updated SDP Offers
To do: Revisit this section based on new connection management rules To do: Revisit this section based on new connection management rules
MSRP endpoints may sometimes need to send additional SDP exchanges MSRP endpoints may sometimes need to send additional SDP exchanges
for an existing session. They may need to send periodic exchanges for an existing session. They may need to send periodic exchanges
with no change to refresh state in the network, for example, SIP with no change to refresh state in the network, for example, SIP
timers. They may need to change some other stream in a session timers. They may need to change some other stream in a session
without affecting the MSRP stream, or they may need to change an MSRP without affecting the MSRP stream, or they may need to change an MSRP
skipping to change at page 12, line 41 skipping to change at page 12, line 9
m=message 9999 msrp/tcp * m=message 9999 msrp/tcp *
a=accept-types:message/cpim text/plain a=accept-types:message/cpim text/plain
a=path:msrp://bob.example.com:8493/si438ds a=path:msrp://bob.example.com:8493/si438ds
A may now send IMs to B by executing SEND transactions. A may now send IMs to B by executing SEND transactions.
6.8 Connection Negotiation 6.8 Connection Negotiation
Previous versions of this document included a mechanism to negotiate Previous versions of this document included a mechanism to negotiate
the direction for any required TCP connection. The mechanism was the direction for any required TCP connection. The mechanism was
loosely based on COMEDIA [18]work being done in the MMUSIC working loosely based on COMEDIA [20]work being done in the MMUSIC working
group. The primary motivation was to allow MSRP sessions to succeed group. The primary motivation was to allow MSRP sessions to succeed
in situations where the offerer could not accpet connections but the in situations where the offerer could not accpet connections but the
answerer could. For example, the offerer might be behind a NAT, while answerer could. For example, the offerer might be behind a NAT, while
the answerer might have a globally routable address. the answerer might have a globally routable address.
The SIMPLE working group chose to remove that mechanism from MSRP for The SIMPLE working group chose to remove that mechanism from MSRP for
a number of reasons: a number of reasons:
It added a great deal of complexity to session creation. It added a great deal of complexity to session creation.
The work in MSRP had begun to diverge from the work in MMUSIC. The work in MSRP had begun to diverge from the work in MMUSIC.
skipping to change at page 13, line 4 skipping to change at page 12, line 20
group. The primary motivation was to allow MSRP sessions to succeed group. The primary motivation was to allow MSRP sessions to succeed
in situations where the offerer could not accpet connections but the in situations where the offerer could not accpet connections but the
answerer could. For example, the offerer might be behind a NAT, while answerer could. For example, the offerer might be behind a NAT, while
the answerer might have a globally routable address. the answerer might have a globally routable address.
The SIMPLE working group chose to remove that mechanism from MSRP for The SIMPLE working group chose to remove that mechanism from MSRP for
a number of reasons: a number of reasons:
It added a great deal of complexity to session creation. It added a great deal of complexity to session creation.
The work in MSRP had begun to diverge from the work in MMUSIC. The work in MSRP had begun to diverge from the work in MMUSIC.
There was a lack of successful implementation experience of the There was a lack of successful implementation experience of the
COMEDIA work. COMEDIA work.
6.9 Negotiation of Delivery Status Notifications
To Do.
7. The Message Session Relay Protocol 7. The Message Session Relay Protocol
The Message Session Relay Protocol (MSRP) is a text based, message The Message Session Relay Protocol (MSRP) is a text based, message
oriented protocol for the transfer of instant messages in the context oriented protocol for the transfer of instant messages in the context
of a session. MSRP uses the UTF8 character set. of a session. MSRP uses the UTF8 character set.
MSRP messages MUST be sent over a reliable, congestion-controlled, MSRP messages MUST be sent over a reliable, congestion-controlled,
connection-oriented transport protocol. This document specifies the connection-oriented transport protocol. This document specifies the
use of MSRP over TCP. Other documents may specify bindings for other use of MSRP over TCP. Other documents may specify bindings for other
such protocols. such protocols.
7.1 MSRP URLs 7.1 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 [4], with a scheme of "msrp":
msrp_url = "msrp" ":" "//" [userinfo] hostport ["/' resource] msrp_url = "msrp://" [userinfo "@"] hostport ["/" resource]
resource = 1*unreserved resource = 1*unreserved
The constructions for "userinfo", "hostport", and "unreserved" are The constructions for "userinfo", "hostport", and "unreserved" are
detailed in RFC2396 [4]. detailed in RFC2396 [4].
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 the contain a port. The resource part identifies a particular session the
participant. The absence of the resource part indicates a reference participant. The absence of the resource part indicates a reference
to an MSRP host device, but does not specifically refer to a to an MSRP host device, but does not specifically refer to a
skipping to change at page 15, line 39 skipping to change at page 14, line 49
7.1.3 The msrps URL Scheme 7.1.3 The msrps URL Scheme
The "msrps" URL Scheme indicates that each hop MUST be secured with The "msrps" URL Scheme indicates that each hop MUST be secured with
TLS. Otherwise, it is used identically as an MSRP URL, except that a TLS. Otherwise, it is used identically as an MSRP URL, except that a
MSRPS URL MUST NOT be considered equivalent to an MSRP URL. The MSRPS MSRPS URL MUST NOT be considered equivalent to an MSRP URL. The MSRPS
scheme is further discussed in Section 10. scheme is further discussed in Section 10.
7.2 Connection Managment 7.2 Connection Managment
When an MSRP endpoint receives an SDP offer, and intends to accept When an MSRP endpoint receives an SDP offer, and intends to accept
it, it MUST establish a connection device described by the remote it, it MUST establish a connection device described by the connection
URL, if one does not already exist. If it already has a connection URL, if a connection does not already exist. If it already has a
associated with another session for which the peer URL host part connection associated with another session for which the connection
matches the host part of the remote URL, it SHOULD use the that URL host part matches the host part of the connection URL for this
connection, instead. Once connected, the answerer MUST send a VISIT session, it SHOULD use the that connection, instead. Once connected,
request to associate the new session with the connection, prior to the answerer MUST send a VISIT request to associate the new session
sending the SDP answer. with the connection, prior to sending the SDP answer.
Either endpoint MAY tear down a connection when it no longer has any Either endpoint MAY tear down a connection when it no longer has any
active or proposed sessions associated with the connection. active or proposed sessions associated with the connection.
7.3 MSRP messages 7.3 MSRP messages
MSRP messages are either requests or responses. Requests and MSRP messages are either requests or responses. Requests and
responses are distinguished from one another by the first line. The responses are distinguished from one another by the first line. The
first line of a Request takes the form of the request-start entry 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 below. Likewise, the first line of a response takes the form of
skipping to change at page 16, line 19 skipping to change at page 15, line 30
msrp-message = request-start/response-start *(header CRLF) msrp-message = request-start/response-start *(header CRLF)
[CRLF body] [CRLF body]
request-start = "MSRP" SP length SP Method CRLF request-start = "MSRP" SP length SP Method CRLF
response-start = "MSRP" SP length SP Status-Code SP response-start = "MSRP" SP length SP Status-Code SP
Reason CRLF Reason CRLF
length = 1*DIGIT ; the length of the message, length = 1*DIGIT ; the length of the message,
; exclusive of the start line. ; exclusive of the start line.
Method = SEND / VISIT / other-method Method = SEND / VISIT / other-method
other-method = token other-method = token
header = Transaction-ID / Session-URL / Content-Types header = Tran-ID / Session-URL / Content-Types /
From / To / Message-Receipt / Receipt-ID /
Byte-Range
Status-Code = 200 ;Success Status-Code = 200 ;Success
/ 400 ;Bad Request / 400 ;Bad Request
/ 403 ;Forbidden / 403 ;Forbidden
/ 415 ;Unsupported Content Type / 415 ;Unsupported Content Type
/ 426 ;Upgrade Required / 426 ;Upgrade Required
/ 481 ;No session / 481 ;No session
/ 506 ;duplicate session / 506 ;duplicate session
Reason = token ; Human readable text describing status Reason = token ; Human readable text describing status
Transaction-ID = "Tr-ID" ":" token Tran-ID = "Tr-ID" ":" token
Content-Type = "Content-Type" ":" quoted-string
Content-Type = "Content-Type" ":" media-type
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
parameter = attribute "=" value
attribute = token
value = token | quoted-string
To = "To" ":" msrp_url *(SP msrp_url) To = "To" ":" msrp_url *(SP msrp_url)
From = "From" ":" msrp_url From = "From" ":" msrp_url
Message-Receipt = "Message-Receipt" ":" message-receipt-spec
( SEMI receipt-type )
message-receipt-spec = "negative" / "none" / "all"
receipt-type = "receipt-type" "=" alt-receipt-type
alt-receipt-type = r-type SLASH r-subtype *(SEMI r-parameter)
r-type = discrete-type / composite-type
discrete-type = "text" / "image" / "audio" / "video"
/ "application" / extension-token
composite-type = "message" / "multipart" / extension-token
extension-token = ietf-token / x-token
ietf-token = token
x-token = "x-" token
r-subtype = extension-token / iana-token
iana-token = token
r-parameter = r-attribute "=" r-value
r-attribute = token
r-value = token / quoted-string
Receipt-ID = "Receipt-ID" ":" token
Byte-Range = "Byte-Range" ":" byte-range-spec
byte-range-spec = first-byte "-" last-byte
first-byte = 1*DIGIT
last-byte = 1*DIGIT
All requests and responses MUST contain at least a TR-ID header All requests and responses MUST contain at least a TR-ID header
field. All requests must also contain the To and From header fields. field. All requests must also contain the To and From header fields.
Messages MAY contain other fields, depending on the method or Messages MAY contain other fields, depending on the method or
response code. response code.
7.4 MSRP Transactions 7.4 MSRP Transactions
An MSRP transaction consists of exactly one request and one response. An MSRP transaction consists of exactly one request and one response.
A response matches a transaction if it share the same TR-ID value, A response matches a transaction if it share the same TR-ID value,
and arrives on the same connection on which the transaction was sent. and arrives on the same connection on which the transaction was sent.
skipping to change at page 17, line 49 skipping to change at page 17, line 50
The offerer puts its local URL into the path attribute, as The offerer puts its local URL into the path attribute, as
described in Section 6.4. This URL becomes the offerer's local described in Section 6.4. This URL becomes the offerer's local
path. path.
4. Send the SDP offer using the normal processing for the signaling 4. Send the SDP offer using the normal processing for the signaling
protocol. protocol.
If the answerer chooses to participate, it MUST perform the following If the answerer chooses to participate, it MUST perform the following
steps: steps:
1. Parse the first URL from the offered path attribute. We will 1. Parse the first URL from the offered path attribute, to be the
refer to this URL as the remote URL. The full path attribute connection URL. The full path attribute value will be the
value will be the answerer's remote path. If the path only answerer's remote path. If the path only contained a single URL
contained a single URL entry, then the remote URL and the remote entry, then the connection URL and the remote path are identical.
path are identical.
2. Determine if it has any existing connection that is associated 2. Determine if it has any existing connection that is associated
with a peer URL host part that matches that of the remote URL, with a connection URL host part that matches that of the
and with a transport protocol matching that from the M-line. If connection URL for this session, and with a transport protocol
one exists, the answerer SHOULD use it for the new session rather matching that from the M-line. If one exists, the answerer SHOULD
than establishing a new connection. use it for the new session rather than establishing a new
connection.
[Open Issue: Should we discuss situations when an endpoint may [Open Issue: Should we discuss situations when an endpoint may
want to intentially not share a connection?] want to intentially not share a connection?]
3. If no appropriate connection already exists, determine the host 3. If no appropriate connection already exists, determine the host
address and port from the remote URL, following the procedures in address and port from the peer URL, following the procedures in
section Section 7.1, and connect using the transport protocol section Section 7.1, and connect using the transport protocol
from the M-line. from the M-line.
4. Construct a MSRP URL . This URL MUST resolve to the the answerer. 4. Construct a MSRP URL . This URL MUST resolve to the the answerer.
This URL becomes the answerer's local URL. This URL becomes the answerer's local URL.
5. Construct a VISIT request, which MUST contain the following 5. Construct a VISIT request, which MUST contain the following
information: information:
1. An To header field containing the remote URL. 1. An To header field containing the remote URL.
skipping to change at page 19, line 36 skipping to change at page 19, line 37
change session state in any way. change session state in any way.
7.5.3 Sending Instant Messages on a Session 7.5.3 Sending Instant Messages on a Session
Once a MSRP session has been established, either endpoint may send Once a MSRP session has been established, either endpoint may send
instant messages to its peer using the SEND method. When an endpoint instant messages to its peer using the SEND method. When an endpoint
wishes to do so, it MUST construct a SEND request according to the wishes to do so, it MUST construct a SEND request according to the
following process: following process:
1. Insert a To header field containing the remote path. Note that 1. Insert a To header field containing the remote path. Note that
this is the full remote path, not just the remote URL. this is the full remote path, not just the connection or peer
URL.
2. Insert a From header field containing the local URL. 2. Insert a From header field containing the local URL.
3. Insert the message payload in the body, and the media type in the 3. Insert the message payload in the body, and the media type in the
Content-Type header field. The media type MUST match one of the Content-Type header field. The media type MUST match one of the
types in the format list negotiated in the SDP exchange. If a "*" types in the format list negotiated in the SDP exchange. If a "*"
was present in the accept-types attribute, then the media type was present in the accept-types attribute, then the media type
SHOULD match one of the explicitly listed entries, but MAY be any SHOULD match one of the explicitly listed entries, but MAY be any
other arbitrary value. other arbitrary value.
skipping to change at page 22, line 4 skipping to change at page 22, line 9
protocol. protocol.
It would be nice to allow sessions to be recovered after a It would be nice to allow sessions to be recovered after a
connection failure, perhaps by allowing the active endpoint to connection failure, perhaps by allowing the active endpoint to
reconnect, and send a new VISIT request. However, this approach reconnect, and send a new VISIT request. However, this approach
creates a race condition between the time that the hosting device creates a race condition between the time that the hosting device
notices the failed connection, and the time that the endpoint notices the failed connection, and the time that the endpoint
tries to recover the session. If the endpoint attempts to tries to recover the session. If the endpoint attempts to
reconnect prior to the hosting device noticing the failure, the reconnect prior to the hosting device noticing the failure, the
hosting device will interpret the recovery attempt as a conflict. hosting device will interpret the recovery attempt as a conflict.
The only way around this would be to force the hosting device to The only way around this would be to force the hosting device to
do a liveness check on the original connection, which would create 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 a lot of complexity and overhead that do not seem to be worth the
trouble. trouble.
Open Issue: Is this still an issue with shared connections? Open Issue: Is this still an issue with shared connections?
7.6 Delivery Status Notifications 7.6 Delivery Status Notification
To Do. Delivery Status Notification (DSN)[10] provides an extensible MIME
content-type that is used to convey both positive and negative status
of messages in the network. This functionality is extremely useful
for MSRP sessions that traverse a relay device. Relay support is
considered out of scope for this specification and will be included
in a separate specification. This section will only cover
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 which MUST be negotiated during the SDP offer/answer
exchange.
7.7 Method Descriptions 7.6.1 Endpoint DSN Request
An endpoint that wishes to be informed of message delivery/failure
needs to request such information. This is achieved by including an
MSRP Receipt-Request header in the request. The header can equal one
of three values:
negative: Indicates the client only requires failure delivery 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
only used in MSRP SEND requests. Future extensions to this
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
'negative'. An example of this header would be:
Message-Receipt: negative
The default DSN MIME type is detailed in RFC 1894[10]. It is
possible for MSRP endpoints to use a different format if required.
This can be achieved by including a 'receipt-type' parameter in the
Message-Receipt header. This parameter contains the alternative MIME
type that SHOULD be used for this particular receipt transaction.
The value included in this header MUST equal a value negotiated
during the SDP offer/answer exchange.
Open Issue: If we negotiate this in the SDP, that also means the
format would be legal for normal messages. Is this okay? Also, I
assume that if we negotiated "*" in the sdp, then any format would be
legal? Do we even need this to be extensible?
Open Issue: Is the RFC1894 the right thing to use? Do we need to add
further verbiage on the format beyond the reference to the RFC?
7.6.2 DSN generation
An MSRP endpoint implementing this specification SHOULD be able to
generate positive delivery status of MSRP requests. On receiving an
MSRP request containing a Message-Receipt header with a value of
TRUE, the endpoint will carry out normal MSRP response generation and
MUST generate an MSRP REPORT request using the following procedures:
1. Insert a To header containing the From value from the original
request.
2. Insert a From header containing the To value from the original
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. Insert the TR-ID value that appeared in the original MSRP request
into the Receipt-ID header. This allows a requesting client to
explicitly correlate a REPORT request with the original request.
This correlation is implementation specific and makes no
requirements on clients to hold state for transactions ID's.
Information regarding the original request can be obtained from
the DSN MIME type outlined in [10].
6. If the associated SEND request contained a chunk, that is, used
the "message/byteranges" fromat, insert an MSRP Byte-Range header
containing the value from the Content-range header field. It is
possible that an intermediary device may have broken the MSRP
SEND request into chunks without the knowledge of the sending
client.
7.6.3 Receiving positive DSN
An MSRP endpoint implementing this specification MUST be able to
receive positive delivery status of MSRP requests.
7.6.4 Receiving negative DSN
An MSRP endpoint implementing this specification MUST be able to
receive negative delivery status of MSRP requests.
7.6.5 DSN headers in MSRP
To Do - Define meaning + relevance of DSN headers.
7.7 Message Fragmentation
MSRP devices MAY break large content into fragments, and send each
fragment in a separate SEND request. Each fragment 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/byterange like
any other MIME type? I assume no, as we want to allow relays to
fragment messages, and relays are not privy to the content-types
negotiated for a session.
Although relays are not in scope for this document, we expect that
relays will be able to introduce fragmentation, as well as change the
fragmentation of previously fragemented messages. Therefore, all MSRP
endpoints MUST be able to receive fragmented messages.
7.7.1 MSRP Usage of message/byteranges
The "message/byteranges" type allows multiple ranges in a single
document. However, MSRP devices MUST NOT include more than one byte
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 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
length, it SHOULD put that length into instance-length. The device
MAY place a "*" in instance-length if it does not have such
knowledge.
Similarly, if the device has a priori knowledge of the number of
bytes in a byte range, it SHOULD place the last bype position in
last-byte-pos. Otherwise, it MAY use a "*". If "*" is present, the
recipient MUST determine the last-byte-position through normal
request framing and body processing. An MSRP device MUST put the
initial byte position in first-byte-pos.
7.8 Method Descriptions
This section summarizes the purpose of each MSRP method. All MSRP This section summarizes the purpose of each MSRP method. All MSRP
messages MUST contain the TR-ID, From, and To header fields. All messages MUST contain the TR-ID, From, and To header fields. All
messages MUST contain a length field in the start line that indicates messages MUST contain a length field in the start line that indicates
the overall length of the request, including any body, but not the overall length of the request, including any body, but not
including the start line itself. Additional requirements exist including the start line itself. Additional requirements exist
depending on the individual method. depending on the individual method.
7.7.1 SEND 7.8.1 SEND
The SEND method is used by both the host and visitor endpoints to The SEND method is used by both the host and visitor endpoints to
send instant messages to its peer endpoint. A SEND request MUST send instant messages to its peer endpoint. A SEND request MUST
contain a To header field containing the sender's remote path, and a contain a To header field containing the sender's remote path, and a
From header field containing the sender's local URL. SEND requests From header field containing the sender's local URL. SEND requests
SHOULD contain a MIME body part. The body MUST be of a media type 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 included in the format list negotiated in the SDP exchange. If a body
is present, the request MUST contain a Content-Type header field is present, the request MUST contain a Content-Type header field
identifying the media type of the body. identifying the media type of the body.
To Do: We plan to expand the use of MIME headers to allow any To Do: We plan to expand the use of MIME headers to allow any
standard MIME header in a SEND request. This is not included in 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 this version for the sake of getting the draft out as soon as
possible, but will follow soon. possible, but will follow soon.
7.7.2 VISIT 7.8.2 VISIT
The visiting endpoint uses the VISIT method to associate a network The visiting endpoint uses the VISIT method to associate a network
connection with the session state at the hosting device. A VISIT connection with the session state at the hosting device. A VISIT
request MUST include a To header including the sender's remote URL, request MUST include a To header including the sender's connection
and a From header field containing the sender's local URL. URL, and a From header field containing the sender's local URL.
7.8 Response Code Descriptions 7.8.3 REPORT
Report is used by an endpoint/relay to convey message delivery status
7.9 Response Code Descriptions
This section summarizes the various response codes. Except where This section summarizes the various response codes. Except where
noted, all responses MUST contain a TR-ID header field matching the noted, all responses MUST contain a TR-ID header field matching the
TR-ID header field of the original request, and To and From headers TR-ID header field of the original request, and To and From headers
matching those of the original request. matching those of the original request.
7.8.1 200 7.9.1 200
The 200 response code indicates a successful transaction. The 200 response code indicates a successful transaction.
7.8.2 400 7.9.2 400
A 400 response indicates a request was unintelligible. A 400 response indicates a request was unintelligible.
7.8.3 415 7.9.3 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.
7.8.4 426 7.9.4 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.
7.8.5 481 7.9.5 481
A 481 response indicates that no session exists for the connection. A 481 response indicates that no session exists for the connection.
7.8.6 506 7.9.6 506
A 506 response indicates that a VISIT request occurred in which the A 506 response indicates that a VISIT request occurred in which the
To header indicates a local path that is already associated with To header indicates a local path that is already associated with
another connection. A 506 response MUST NOT be returned in response another connection. A 506 response MUST NOT be returned in response
to any method other than VISIT. to any method other than VISIT.
7.9 Header Field Descriptions 7.10 Header Field Descriptions
This section summarizes the various header fields. MSRP header fields This section summarizes the various header fields. MSRP header fields
are single valued; that is, they MUST NOT occur more than once in a are single valued; that is, they MUST NOT occur more than once in a
particular request or response. particular request or response.
7.9.1 TR-ID 7.10.1 TR-ID
The TR-ID header field contains a transaction identifier used to map 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 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. among all values used by a given endpoint inside a given session.
MSRP elements MUST NOT assume any additional semantics for TR-ID. MSRP elements MUST NOT assume any additional semantics for TR-ID.
7.9.2 To 7.10.2 To
The To header field is used to indicate the sender's remote path. All The To header field is used to indicate the sender's remote path. All
MSRP requests MUST contain a To header field. MSRP requests MUST contain a To header field.
7.9.3 From 7.10.3 From
The From header field is used to indicate the sender's local URL. All The From header field is used to indicate the sender's local URL. All
MSRP requests MUST contain a From header field. MSRP requests MUST contain a From header field.
7.9.4 Content-Type 7.10.4 Content-Type
The Content-Type header field is used to indicate the MIME media type The Content-Type header field is used to indicate the MIME media type
of the body. Content-Type MUST be present if a body is present. of the body. Content-Type MUST be present if a body is present.
To Do: The work group has agreed to allow the use of any standard To Do: The work group has agreed to allow the use of any standard
MIME header. This is not reflected in this version, but will be in MIME header. This is not reflected in this version, but will be in
a shortly forthcoming one. a shortly forthcoming one.
8. Example 8. Example
skipping to change at page 30, line 37 skipping to change at page 33, line 37
end-to-end protection of message sessions SHOULD exchange symmetric end-to-end protection of message sessions SHOULD exchange symmetric
keys in SDP k-lines, and use secret key encryption on for each MSRP keys in SDP k-lines, and use secret key encryption on for each MSRP
message. When symmetric keys are present in the SDP, the offer-answer message. When symmetric keys are present in the SDP, the offer-answer
exchange MUST be protected from eavesdropping and tampering using the exchange MUST be protected from eavesdropping and tampering using the
appropriate facilities of the signaling protocol. For example, if the appropriate facilities of the signaling protocol. For example, if the
signaling protocol is SIP, the SDP exchange MUST be protected using signaling protocol is SIP, the SDP exchange MUST be protected using
S/MIME. S/MIME.
10.1.3 CPIM compatibility 10.1.3 CPIM compatibility
MSRP sessions may be gatewayed to other CPIM [17]compatible MSRP sessions may be gatewayed to other CPIM [19]compatible
protocols. If this occurs, the gateway MUST maintain session state, protocols. If this occurs, the gateway MUST maintain session state,
and MUST translate between the MSRP session semantics and CPIM and MUST translate between the MSRP session semantics and CPIM
semantics that do not include a concept of sessions. Furthermore, semantics that do not include a concept of sessions. Furthermore,
when one endpoint of the session is a CPIM gateway, instant messages when one endpoint of the session is a CPIM gateway, instant messages
SHOULD be wrapped in "message/cpim" [5] bodies. Such a gateway MUST SHOULD be wrapped in "message/cpim" [5] bodies. Such a gateway MUST
include "message/cpim" as the first entry in its SDP accept-types include "message/cpim" as the first entry in its SDP accept-types
attribute. MSRP endpoints sending instant messages to a peer that has attribute. MSRP endpoints sending instant messages to a peer that has
included 'message/cpim" as the first entry in the accept-types included 'message/cpim" as the first entry in the accept-types
attribute SHOULD encapsulate all instant message bodies in "message/ attribute SHOULD encapsulate all instant message bodies in "message/
cpim" wrappers. All MSRP endpoints MUST support the message/cpim cpim" wrappers. All MSRP endpoints MUST support the message/cpim
skipping to change at page 31, line 51 skipping to change at page 34, line 51
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 skeleton sections for Delivery Status Notification handling Added section for Delivery Status Notification handling, and added
and negotiation. associated entries into the syntax definition.
Added content fragmentation section.
Removed recommendation to start separate session for large
transfers.
Corrected some mistakes in the syntax definitions.
Added Chris Boulton as a co-author for his contribution of the DSN
text.
11.2 draft-ietf-simple-message-sessions-03 11.2 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 work the use of relays. The working group has chosen to move relay work
into a separate effort, in order to advance the base 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.
skipping to change at page 34, line 25 skipping to change at page 37, line 34
[1] Handley, M. and V. Jacobson, "SDP: Session Description [1] 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., [2] 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 / [3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
Presence Protocol Requirements", RFC 2779, February 2000. Presence Protocol Requirements", RFC 2779, February 2000.
[4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Identifiers (URL): Generic Syntax", RFC 2396, August 1998. Resource Identifiers (URL): Generic Syntax", RFC 2396, August
1998.
[5] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging [5] 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 [6] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[7] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC [7] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
2633, June 1999. 2633, June 1999.
[8] Chown, P., ""Advanced Encryption Standard (AES) Ciphersuites for [8] Chown, P., ""Advanced Encryption Standard (AES) Ciphersuites
Transport Layer Security (TLS)", RFC 3268, June 2002. for Transport Layer Security (TLS)", RFC 3268, June 2002.
[9] Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 [9] Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001. (SHA1)", RFC 3174, September 2001.
[10] Moore, K. and G. Vaudreuil, "An Extensible Message Format for
Delivery Status Notifications", RFC 1894, January 1996.
[11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
Informational References Informational References
[10] Campbell, B. and J. Rosenberg, "Session Initiation Protocol [12] Campbell, B. and J. Rosenberg, "Session Initiation Protocol
Extension for Instant Messaging", RFC 3428, September 2002. Extension for Instant Messaging", RFC 3428, September 2002.
[11] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, [13] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC "RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996. 1889, January 1996.
[12] Mahy, R., Campbell, B., Sparks, R., Rosenberg, J., Petrie, D. [14] Mahy, R., Campbell, B., Sparks, R., Rosenberg, J., Petrie, D.
and A. Johnston, "A Multi-party Application Framework for SIP", and A. Johnston, "A Multi-party Application Framework for SIP",
draft-ietf-sipping-cc-framework-02 (work in progress), May draft-ietf-sipping-cc-framework-02 (work in progress), May
2003. 2003.
[13] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo, [15] 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-04 (work
in progress), June 2003. in progress), June 2003.
[14] Sparks, R. and A. Johnston, "Session Initiation Protocol Call [16] 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-01 (work in
progress), February 2003. progress), February 2003.
[15] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of [17] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of
Resource Management and Session Initiation Protocol (SIP)", RFC Resource Management and Session Initiation Protocol (SIP)", RFC
3312, October 2002. 3312, October 2002.
[16] Peterson, J., "A Privacy Mechanism for the Session Initiation [18] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323 , November 2002. Protocol (SIP)", RFC 3323 , November 2002.
[17] Peterson, J., "A Common Profile for Instant Messaging (CPIM)", [19] Peterson, J., "A Common Profile for Instant Messaging (CPIM)",
draft-ietf-impp-im-04 (work in progress), August 2003. draft-ietf-impp-im-04 (work in progress), August 2003.
[18] Yon, D., "Connection-Oriented Media Transport in SDP", [20] 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.
Authors' Addresses Authors' Addresses
Ben Campbell Ben Campbell
dynamicsoft dynamicsoft
5100 Tennyson Parkway 5100 Tennyson Parkway
Suite 1200 Suite 1200
Plano, TX 75024 Plano, TX 75024
skipping to change at page 37, line 4 skipping to change at page 39, line 37
EMail: rsparks@dynamicsoft.com EMail: rsparks@dynamicsoft.com
Paul Kyzivat Paul Kyzivat
Cisco Systems Cisco Systems
Mail Stop LWL3/12/2 Mail Stop LWL3/12/2
900 Chelmsford St. 900 Chelmsford St.
Lowell, MA 01851 Lowell, MA 01851
EMail: pkyzivat@cisco.com EMail: pkyzivat@cisco.com
Chris Boulton
Ubiquity Software Corporation
Langstone Park
Newport, South Wales NP18 2LH
EMail: cboulton@ubiquity.net
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 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; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
 End of changes. 

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