draft-ietf-simple-message-sessions-14.txt   draft-ietf-simple-message-sessions-15.txt 
Network Working Group B. Campbell, Ed. Network Working Group B. Campbell, Ed.
Internet-Draft Estacado Systems Internet-Draft Estacado Systems
Expires: August 29, 2006 R. Mahy, Ed. Expires: December 26, 2006 R. Mahy, Ed.
SIP Edge, LLC Plantronics
C. Jennings, Ed. C. Jennings, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
February 25, 2006 June 24, 2006
The Message Session Relay Protocol The Message Session Relay Protocol
draft-ietf-simple-message-sessions-14 draft-ietf-simple-message-sessions-15
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 29, 2006. This Internet-Draft will expire on December 26, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes the Message Session Relay Protocol, a This document describes the Message Session Relay Protocol, a
protocol for transmitting a series of related instant messages in the protocol for transmitting a series of related instant messages in the
context of a session. Message sessions are treated like any other context of a session. Message sessions are treated like any other
skipping to change at page 2, line 18 skipping to change at page 2, line 18
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability of MSRP . . . . . . . . . . . . . . . . . . . . 5 3. Applicability of MSRP . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
5. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. MSRP Framing and Message Chunking . . . . . . . . . . . . 9 5.1. MSRP Framing and Message Chunking . . . . . . . . . . . . 9
5.2. MSRP Addressing . . . . . . . . . . . . . . . . . . . . . 10 5.2. MSRP Addressing . . . . . . . . . . . . . . . . . . . . . 10
5.3. MSRP Transaction and Report Model . . . . . . . . . . . . 10 5.3. MSRP Transaction and Report Model . . . . . . . . . . . . 10
5.4. MSRP Connection Model . . . . . . . . . . . . . . . . . . 12 5.4. MSRP Connection Model . . . . . . . . . . . . . . . . . . 12
6. MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 15 6.1. MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 15
6.2. Resolving MSRP Host Device . . . . . . . . . . . . . . . 15 6.2. Resolving MSRP Host Device . . . . . . . . . . . . . . . 16
7. Method-Specific Behavior . . . . . . . . . . . . . . . . . . . 16 7. Method-Specific Behavior . . . . . . . . . . . . . . . . . . . 16
7.1. Constructing Requests . . . . . . . . . . . . . . . . . . 16 7.1. Constructing Requests . . . . . . . . . . . . . . . . . . 16
7.1.1. Sending SEND Requests . . . . . . . . . . . . . . . . 18 7.1.1. Sending SEND Requests . . . . . . . . . . . . . . . . 18
7.1.2. Sending REPORT Requests . . . . . . . . . . . . . . . 20 7.1.2. Sending REPORT Requests . . . . . . . . . . . . . . . 21
7.1.3. Generating Success Reports . . . . . . . . . . . . . . 21 7.1.3. Generating Success Reports . . . . . . . . . . . . . . 21
7.1.4. Generating Failure Reports . . . . . . . . . . . . . . 21 7.1.4. Generating Failure Reports . . . . . . . . . . . . . . 22
7.2. Constructing Responses . . . . . . . . . . . . . . . . . 22 7.2. Constructing Responses . . . . . . . . . . . . . . . . . 23
7.3. Receiving Requests . . . . . . . . . . . . . . . . . . . 23 7.3. Receiving Requests . . . . . . . . . . . . . . . . . . . 24
7.3.1. Receiving SEND Requests . . . . . . . . . . . . . . . 23 7.3.1. Receiving SEND Requests . . . . . . . . . . . . . . . 24
7.3.2. Receiving REPORT Requests . . . . . . . . . . . . . . 25 7.3.2. Receiving REPORT Requests . . . . . . . . . . . . . . 26
8. Using MSRP with SIP and SDP . . . . . . . . . . . . . . . . . 26 8. Using MSRP with SIP and SDP . . . . . . . . . . . . . . . . . 27
8.1. SDP Connection and Media Lines . . . . . . . . . . . . . 27 8.1. SDP Connection and Media Lines . . . . . . . . . . . . . 27
8.2. URL Negotiations . . . . . . . . . . . . . . . . . . . . 27 8.2. URL Negotiations . . . . . . . . . . . . . . . . . . . . 28
8.3. Path Attributes with Multiple URLs . . . . . . . . . . . 28 8.3. Path Attributes with Multiple URLs . . . . . . . . . . . 29
8.4. Updated SDP Offers . . . . . . . . . . . . . . . . . . . 29 8.4. Updated SDP Offers . . . . . . . . . . . . . . . . . . . 30
8.5. Connection Negotiation . . . . . . . . . . . . . . . . . 30 8.5. Connection Negotiation . . . . . . . . . . . . . . . . . 30
8.6. Content Type Negotiation . . . . . . . . . . . . . . . . 30 8.6. Content Type Negotiation . . . . . . . . . . . . . . . . 31
8.7. Example SDP Exchange . . . . . . . . . . . . . . . . . . 32 8.7. Example SDP Exchange . . . . . . . . . . . . . . . . . . 32
8.8. MSRP User Experience with SIP . . . . . . . . . . . . . . 32 8.8. MSRP User Experience with SIP . . . . . . . . . . . . . . 33
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 33 8.9. SDP direction attribute and MSRP . . . . . . . . . . . . 34
10. Response Code Descriptions . . . . . . . . . . . . . . . . . . 35 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 34
10. Response Code Descriptions . . . . . . . . . . . . . . . . . . 36
10.1. 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.1. 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.2. 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.2. 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.3. 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.3. 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.4. 408 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.4. 408 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.5. 413 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.5. 413 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.6. 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.6. 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.7. 423 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.7. 423 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.8. 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.8. 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.9. 501 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.9. 501 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.10. 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.10. 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
11.1. Basic IM Session . . . . . . . . . . . . . . . . . . . . 37 11.1. Basic IM Session . . . . . . . . . . . . . . . . . . . . 38
11.2. Message with XHTML Content . . . . . . . . . . . . . . . 40 11.2. Message with XHTML Content . . . . . . . . . . . . . . . 41
11.3. Chunked Message . . . . . . . . . . . . . . . . . . . . . 40 11.3. Chunked Message . . . . . . . . . . . . . . . . . . . . . 41
11.4. System Message . . . . . . . . . . . . . . . . . . . . . 40 11.4. System Message . . . . . . . . . . . . . . . . . . . . . 41
11.5. Positive Report . . . . . . . . . . . . . . . . . . . . . 41 11.5. Positive Report . . . . . . . . . . . . . . . . . . . . . 42
11.6. Forked IM . . . . . . . . . . . . . . . . . . . . . . . . 41 11.6. Forked IM . . . . . . . . . . . . . . . . . . . . . . . . 42
12. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 45 12. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 45
13. CPIM Compatibility . . . . . . . . . . . . . . . . . . . . . . 45 13. CPIM Compatibility . . . . . . . . . . . . . . . . . . . . . . 45
14. Security Considerations . . . . . . . . . . . . . . . . . . . 46 14. Security Considerations . . . . . . . . . . . . . . . . . . . 46
14.1. Transport Level Protection . . . . . . . . . . . . . . . 46 14.1. Transport Level Protection . . . . . . . . . . . . . . . 46
14.2. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . 48 14.2. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . 48
14.3. Using TLS in Peer to Peer Mode . . . . . . . . . . . . . 48 14.3. Using TLS in Peer to Peer Mode . . . . . . . . . . . . . 48
14.4. Other Security Concerns . . . . . . . . . . . . . . . . . 50 14.4. Other Security Concerns . . . . . . . . . . . . . . . . . 50
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
15.1. MSRP Method Names . . . . . . . . . . . . . . . . . . . . 52 15.1. MSRP Method Names . . . . . . . . . . . . . . . . . . . . 52
15.2. MSRP Header Fields . . . . . . . . . . . . . . . . . . . 52 15.2. MSRP Header Fields . . . . . . . . . . . . . . . . . . . 52
15.3. MSRP Status Codes . . . . . . . . . . . . . . . . . . . . 52 15.3. MSRP Status Codes . . . . . . . . . . . . . . . . . . . . 52
15.4. MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 53 15.4. MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 53
15.5. MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . 53 15.5. MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . 53
15.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . 53 15.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . 53
15.7. SDP Attribute Names . . . . . . . . . . . . . . . . . . . 53 15.7. SDP Attribute Names . . . . . . . . . . . . . . . . . . . 53
15.7.1. Accept Types . . . . . . . . . . . . . . . . . . . . . 53 15.7.1. Accept Types . . . . . . . . . . . . . . . . . . . . . 53
15.7.2. Wrapped Types . . . . . . . . . . . . . . . . . . . . 54 15.7.2. Wrapped Types . . . . . . . . . . . . . . . . . . . . 54
15.7.3. Max Size . . . . . . . . . . . . . . . . . . . . . . . 54 15.7.3. Max Size . . . . . . . . . . . . . . . . . . . . . . . 54
15.7.4. Path . . . . . . . . . . . . . . . . . . . . . . . . . 54 15.7.4. Path . . . . . . . . . . . . . . . . . . . . . . . . . 54
16. Contributors and Acknowledgments . . . . . . . . . . . . . . . 54 16. Contributors and Acknowledgments . . . . . . . . . . . . . . . 55
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
17.1. Normative References . . . . . . . . . . . . . . . . . . 55 17.1. Normative References . . . . . . . . . . . . . . . . . . 55
17.2. Informational References . . . . . . . . . . . . . . . . 56 17.2. Informational References . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58
Intellectual Property and Copyright Statements . . . . . . . . . . 59 Intellectual Property and Copyright Statements . . . . . . . . . . 59
1. Introduction 1. Introduction
A series of related instant messages between two or more parties can A series of related instant messages between two or more parties can
be viewed as part of a "message session", that is, a conversational be viewed as part of a "message session", that is, a conversational
skipping to change at page 5, line 29 skipping to change at page 5, line 29
the complete message is called a "chunk". the complete message is called a "chunk".
3. Applicability of MSRP 3. Applicability of MSRP
MSRP is not designed for use as a standalone protocol. MSRP MUST be MSRP is not designed for use as a standalone protocol. MSRP MUST be
used only in the context of a rendezvous mechanism meeting the used only in the context of a rendezvous mechanism meeting the
following requirements: following requirements:
The rendezvous mechanism MUST provide both MSRP URLs associated The rendezvous mechanism MUST provide both MSRP URLs associated
with an MSRP session to each of the participating endpoints. The with an MSRP session to each of the participating endpoints. The
rendezvous mechanism MUST implement mechanisms to provide these rendezvous mechanism MUST implement mechanisms to protect the
URLs securely - they MUST NOT be made available to an untrusted confidentiality of these URLs - they MUST NOT be made available to
third party or be easily discoverable. an untrusted third party or be easily discoverable.
The rendezvous mechanism MUST provide mechanisms for the The rendezvous mechanism MUST provide mechanisms for the
negotiation of any supported MSRP extensions that are not negotiation of any supported MSRP extensions that are not
backwards compatible. backwards compatible.
The rendezvous mechanism MUST be able to natively transport im: The rendezvous mechanism MUST be able to natively transport im:
URIs or automatically translate im: URIs [26] into the addressing URIs or automatically translate im: URIs [26] into the addressing
identifiers of the rendezvous protocol. identifiers of the rendezvous protocol.
To use a rendezvous mechanism with MSRP, an RFC must be prepared To use a rendezvous mechanism with MSRP, an RFC MUST be prepared
describing how it exchanges MSRP URLs and meets these requirements describing how it exchanges MSRP URLs and meets these requirements
listed here. This document provides such a description for the use listed here. This document provides such a description for the use
of MSRP in the context of SIP and SDP. of MSRP in the context of SIP and SDP.
SIP meets these requirements for a rendezvous mechanism. The MSRP SIP meets these requirements for a rendezvous mechanism. The MSRP
URLs are exchanged using SDP in an offer/answer exchange via SIP. URLs are exchanged using SDP in an offer/answer exchange via SIP.
The exchanged SDP can also be used to negotiate MSRP extensions. The exchanged SDP can also be used to negotiate MSRP extensions.
This SDP can be secured using any of the mechanisms available in SIP, This SDP can be secured using any of the mechanisms available in SIP,
including using the sips mechanism to ensure transport security including using the sips mechanism to ensure transport security
across intermediaries and S/MIME for end-to-end protection of the SDP across intermediaries and S/MIME for end-to-end protection of the SDP
entity. SIP can carry arbitrary URIs (including im: URIs) in the body. SIP can carry arbitrary URIs (including im: URIs) in the
Request-URI, and procedures are available to map im: URIs to sip: or Request-URI, and procedures are available to map im: URIs to sip: or
sips: URIs. It is expected that initial deployments of MSRP will use sips: URIs. It is expected that initial deployments of MSRP will use
SIP as its rendezvous mechanism. SIP as its rendezvous mechanism.
4. Protocol Overview 4. Protocol Overview
MSRP is a text-based, connection-oriented protocol for exchanging MSRP is a text-based, connection-oriented protocol for exchanging
arbitrary (binary) MIME[8] content, especially instant messages. arbitrary (binary) MIME[8] content, especially instant messages.
This section is a non-normative overview of how MSRP works and how it This section is a non-normative overview of how MSRP works and how it
is used with SIP. is used with SIP.
skipping to change at page 7, line 6 skipping to change at page 7, line 6
of audio or video media is set up. One SIP user agent (Alice) sends of audio or video media is set up. One SIP user agent (Alice) sends
the other (Bob) a SIP invitation containing an offered session- the other (Bob) a SIP invitation containing an offered session-
description which includes a session of MSRP. The receiving SIP user description which includes a session of MSRP. The receiving SIP user
agent can accept the invitation and include an answer session- agent can accept the invitation and include an answer session-
description which acknowledges the choice of media. Alice's session description which acknowledges the choice of media. Alice's session
description contains an MSRP URL that describes where she is willing description contains an MSRP URL that describes where she is willing
to receive MSRP requests from Bob, and vice-versa. (Note: Some lines to receive MSRP requests from Bob, and vice-versa. (Note: Some lines
in the examples are removed for clarity and brevity.) in the examples are removed for clarity and brevity.)
Alice sends to Bob: Alice sends to Bob:
INVITE sip:bob@atlanta.example.com SIP/2.0 INVITE sip:bob@biloxi.example.com SIP/2.0
To: <sip:bob@biloxi.example.com> To: <sip:bob@biloxi.example.com>
From: <sip:alice@atlanta.example.com>;tag=786 From: <sip:alice@atlanta.example.com>;tag=786
Call-ID: 3413an89KU Call-ID: 3413an89KU
Content-Type: application/sdp Content-Type: application/sdp
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
m=message 7654 TCP/MSRP * m=message 7654 TCP/MSRP *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrp://atlanta.example.com:7654/jshA7we;tcp a=path:msrp://atlanta.example.com:7654/jshA7we;tcp
skipping to change at page 7, line 32 skipping to change at page 7, line 32
Call-ID: 3413an89KU Call-ID: 3413an89KU
Content-Type: application/sdp Content-Type: application/sdp
c=IN IP4 biloxi.example.com c=IN IP4 biloxi.example.com
m=message 12763 TCP/MSRP * m=message 12763 TCP/MSRP *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrp://biloxi.example.com:12763/kjhd37s2s2;tcp a=path:msrp://biloxi.example.com:12763/kjhd37s2s2;tcp
Alice sends to Bob: Alice sends to Bob:
ACK sip:bob@atlanta.example.com SIP/2.0 ACK sip:bob@biloxi SIP/2.0
To: <sip:bob@biloxi.example.com>;tag=087js To: <sip:bob@biloxi.example.com>;tag=087js
From: <sip:alice@atlanta.example.com>;tag=786 From: <sip:alice@atlanta.example.com>;tag=786
Call-ID: 3413an89KU Call-ID: 3413an89KU
MSRP defines two request types, or methods. SEND requests are used MSRP defines two request types, or methods. SEND requests are used
to deliver a complete message or a chunk (a portion of a complete to deliver a complete message or a chunk (a portion of a complete
message), while REPORT requests report on the status of a previously message), while REPORT requests report on the status of a previously
sent message, or a range of bytes inside a message. When Alice sent message, or a range of bytes inside a message. When Alice
receives Bob's answer, she checks to see if she has an existing receives Bob's answer, she checks to see if she has an existing
connection to Bob. If not, she opens a new connection to Bob using connection to Bob. If not, she opens a new connection to Bob using
skipping to change at page 9, line 34 skipping to change at page 9, line 34
discussed in more detail in Section 5.4. discussed in more detail in Section 5.4.
5. Key Concepts 5. Key Concepts
5.1. MSRP Framing and Message Chunking 5.1. MSRP Framing and Message Chunking
Messages sent using MSRP can be very large and can be delivered in Messages sent using MSRP can be very large and can be delivered in
several SEND requests, where each SEND request contains one chunk of several SEND requests, where each SEND request contains one chunk of
the overall message. Long chunks may be interrupted in mid- the overall message. Long chunks may be interrupted in mid-
transmission to ensure fairness across shared transport connections. transmission to ensure fairness across shared transport connections.
To support this, MSRP uses a boundary based framing mechanism. The To support this, MSRP uses a boundary-based framing mechanism. The
start line of an MSRP request contains a unique identifier that is start line of an MSRP request contains a unique identifier that is
also used to indicate the end of the request. Included at the end of also used to indicate the end of the request. Included at the end of
the end-line, there is a flag that indicates whether this is the last the end-line, there is a flag that indicates whether this is the last
chunk of data for this message or whether the message will be chunk of data for this message or whether the message will be
continued in a subsequent chunk. There is also a Byte-Range header continued in a subsequent chunk. There is also a Byte-Range header
field in the request that indicates the overall position of this field in the request that indicates that the overall position of this
chunk inside the complete message. chunk inside the complete message.
For example, the following snippet of two SEND requests demonstrates For example, the following snippet of two SEND requests demonstrates
a message that contains the text "abcdEFGH" being sent as two chunks. a message that contains the text "abcdEFGH" being sent as two chunks.
MSRP dkei38sd SEND MSRP dkei38sd SEND
Message-ID: 456 Message-ID: 456
Byte-Range: 1-4/8 Byte-Range: 1-4/8
Content-Type: text/plain Content-Type: text/plain
skipping to change at page 10, line 28 skipping to change at page 10, line 28
EFGH EFGH
-------dkei38ia$ -------dkei38ia$
This chunking mechanism allows a sender to interrupt a chunk part of This chunking mechanism allows a sender to interrupt a chunk part of
the way through sending it. The ability to interrupt messages allows the way through sending it. The ability to interrupt messages allows
multiple sessions to share a TCP connection, and for large messages multiple sessions to share a TCP connection, and for large messages
to be sent efficiently while not blocking other messages that share to be sent efficiently while not blocking other messages that share
the same connection, or even the same MSRP session. Any chunk that the same connection, or even the same MSRP session. Any chunk that
is larger than 2048 octets MUST be interruptible. While MSRP would is larger than 2048 octets MUST be interruptible. While MSRP would
be simpler to implement if each MSRP session used its own TCP be simpler to implement if each MSRP session used its own TCP
connection, that approach would circumvent the congestion avoidance connection, there are compelling reasons to conserve connection. For
features of TCP. example, the TCP peer may be a relay device that connects to many
other peers. Such a device will scale better if each peer does not
create a large number of connections.
The chunking mechanism only applies to the SEND method, as it is the The chunking mechanism only applies to the SEND method, as it is the
only method used to transfer message content. only method used to transfer message content.
5.2. MSRP Addressing 5.2. MSRP Addressing
MSRP entities are addressed using URLs. The MSRP URL schemes are MSRP entities are addressed using URLs. The MSRP URL schemes are
defined in Section 6. The syntax of the To-Path and From-Path header defined in Section 6. The syntax of the To-Path and From-Path header
fields each allow for a list of URLs. This was done to allow the fields each allow for a list of URLs. This was done to allow the
protocol to work with relays, which are defined in a separate protocol to work with relays, which are defined in a separate
skipping to change at page 11, line 45 skipping to change at page 11, line 48
messages such as "the system is going down in 5 minutes" without messages such as "the system is going down in 5 minutes" without
causing a response explosion to the sender. A Failure-Report of causing a response explosion to the sender. A Failure-Report of
"yes" is used by many systems that wish to notify the user if the "yes" is used by many systems that wish to notify the user if the
message failed. A Failure-Report of "partial" is a way to report message failed. A Failure-Report of "partial" is a way to report
errors other than timeouts. The timeout error reporting requires the errors other than timeouts. The timeout error reporting requires the
sending hop to run a timer and the receiving hop to send an sending hop to run a timer and the receiving hop to send an
acknowledgment to stop the timer. Some systems don't want the acknowledgment to stop the timer. Some systems don't want the
overhead of doing this. "Partial" allows them to choose not to do overhead of doing this. "Partial" allows them to choose not to do
so, but still allows error responses to be sent in many cases. so, but still allows error responses to be sent in many cases.
The "partial" value allows a compromise between no reporting of The term "partial" denotes the fact that the hop-by-hop
failures, and reporting all failures. For example, with acknowledgment mechanism that would be required if with a Failure-
Report value of "yes" is not invoked. Thus, each device uses only
"part" of the set of error detection tools available to them.
This allows a compromise between no reporting of failures at all,
and reporting every possible failure. For example, with
"partial", an sending device does not have to keep transaction "partial", an sending device does not have to keep transaction
state around waiting for a positive acknowledgment. But it still state around waiting for a positive acknowledgment. But it still
allows devices to report other types of errors. For example, the allows devices to report other types of errors. The receiving
receiving device could still report a policy violation such as an device could still report a policy violation such as an
unacceptable content-type, or an ICMP error trying to connect to a unacceptable content-type, or an ICMP error trying to connect to a
downstream device. downstream device.
5.4. MSRP Connection Model 5.4. MSRP Connection Model
When an MSRP endpoint wishes to send a request to a peer identified When an MSRP endpoint wishes to send a request to a peer identified
by an MSRP URL, it first needs a transport connection, with the by an MSRP URL, it first needs a transport connection, with the
appropriate security properties, to the host specified in the URL. appropriate security properties, to the host specified in the URL.
If the sender already has such a connection, that is, one associated If the sender already has such a connection, that is, one associated
with the same host, port, and URL scheme, then it SHOULD reuse that with the same host, port, and URL scheme, then it SHOULD reuse that
connection. connection.
When a new MSRP session is created, the offerer MUST act as the When a new MSRP session is created, the initiating endpoint MUST act
"active" endpoint, meaning that it is responsible for opening the as the "active" endpoint, meaning that it is responsible for opening
transport connection to the answerer, if a new connection is the transport connection to the answerer, if a new connection is
required. However, this requirement MAY be weakened if standardized required. However, this requirement MAY be weakened if standardized
mechanisms for negotiating the connection direction become available, mechanisms for negotiating the connection direction become available,
and is implemented by both parties to the connection. and is implemented by both parties to the connection.
Likewise, the active endpoint MUST immediately issue a SEND request. Likewise, the active endpoint MUST immediately issue a SEND request.
This initial SEND request MAY have a body if the sender has content This initial SEND request MAY have a body if the sender has content
to send, or it MAY have no body at all. to send, or it MAY have no body at all.
The first SEND request serves to bind a connection to an MSRP The first SEND request serves to bind a connection to an MSRP
session from the perspective of the passive endpoint. If the session from the perspective of the passive endpoint. If the
connection is not authenticated with TLS, and the active endpoint connection is not authenticated with TLS, and the active endpoint
did not send an immediate request, the passive endpoint would have did not send an immediate request, the passive endpoint would have
no way to determine who had connected, and would not be able to no way to determine who had connected, and would not be able to
safely send any requests towards the active party until after the safely send any requests towards the active party until after the
active party sends its first request. active party sends its first request.
When an element needs to form a new connection, it looks at the URL When an element needs to form a new connection, it looks at the URL
to decide on the type of connection (TLS, TCP, etc.) then connects to to decide on the type of connection (TLS, TCP, etc.) then connects to
the host indicated by the URL, following the URL resolution rules in the host indicated by the URL, following the URL resolution rules in
Section 6.2. Connections using the msrps: scheme MUST use TLS. The Section 6.2. Connections using the "msrps" scheme MUST use TLS. The
SubjectAltName in the received certificate MUST match the hostname SubjectAltName in the received certificate MUST match the hostname
part of the URL and the certificate MUST be valid, including having a part of the URL and the certificate MUST be valid, including having a
date that is valid and being signed by an acceptable certificate date that is valid and being signed by an acceptable certificate
authority. At this point the device that initiated the connection authority. At this point the device that initiated the connection
can assume that this connection is with the correct host. can assume that this connection is with the correct host.
The rules on certificate name matching and CA signing MAY be relaxed
when using TLS peer-to-peer. In this case, a mechanism to ensure
that the peer used a correct certificate MUST be used. See
Section 14.3 for details.
If the connection used mutual TLS authentication, and the TLS client If the connection used mutual TLS authentication, and the TLS client
presented a valid certificate, then the element accepting the presented a valid certificate, then the element accepting the
connection can immediately know the identity of the connecting host. connection can immediately know the identity of the connecting host.
When mutual TLS authentication is not used, the listening device MUST When mutual TLS authentication is not used, the listening device MUST
wait until it receives a request on the connection, at which time it wait until it receives a request on the connection, at which time it
infers the identity of the connecting device from the associated infers the identity of the connecting device from the associated
session description. session description.
When the first request arrives, its To-Path header field should When the first request arrives, its To-Path header field should
contain a URL that the listening element provided in the SDP for a contain a URL that the listening element provided in the SDP for a
skipping to change at page 14, line 7 skipping to change at page 14, line 16
If an endpoint attempts to re-create a failed session in this manner, If an endpoint attempts to re-create a failed session in this manner,
it MUST NOT assume that the MSRP URLs in the SDP will be the same as it MUST NOT assume that the MSRP URLs in the SDP will be the same as
the old ones. the old ones.
A connection SHOULD NOT be closed while there are sessions associated A connection SHOULD NOT be closed while there are sessions associated
with it. with it.
6. MSRP URLs 6. MSRP URLs
URLs using the MSRP and MSRPS schema are used to identify a session URLs using the "msrp" and "msrps" schema are used to identify a
of instant messages at a particular MSRP device. MSRP URLs are session of instant messages at a particular MSRP device. MSRP URLs
ephemeral; an MSRP device will generally use a different MSRP URL for are ephemeral; an MSRP device will generally use a different MSRP URL
each distinct session. An MSRP URL generally has no meaning outside for each distinct session. An MSRP URL generally has no meaning
of the associated session. outside of the associated session.
An MSRP URL follows a subset of the URL syntax in Appendix A of An MSRP URL follows a subset of the URL syntax in Appendix A of
RFC3986 [10], with a scheme of "msrp" or "msrps". The syntax is RFC3986 [10], with a scheme of "msrp" or "msrps". The syntax is
described in Section 9. described in Section 9.
The constructions for "userinfo", and "unreserved" are detailed in The constructions for "userinfo", and "unreserved" are detailed in
RFC3986 [10]. In order to allow IPV6 addressing, the construction RFC3986 [10]. In order to allow IPV6 addressing, the construction
for hostport is that used for SIP in RFC3261. URLs designating MSRP for hostport is that used for SIP in RFC3261. URLs designating MSRP
over TCP MUST include the "tcp" transport parameter. over TCP MUST include the "tcp" transport parameter.
skipping to change at page 14, line 34 skipping to change at page 14, line 43
bindings on other transports should define respective parameters bindings on other transports should define respective parameters
for those transports. for those transports.
An MSRP URL hostport field identifies a participant in a particular An MSRP URL hostport field identifies a participant in a particular
MSRP session. If the hostport contains a numeric IP address, it MUST MSRP session. If the hostport contains a numeric IP address, it MUST
also contain a port. The session-id part identifies a particular also contain a port. The session-id part identifies a particular
session of the participant. The absence of the session-id part session of the participant. The absence of the session-id part
indicates a reference to an MSRP host device, but does not indicates a reference to an MSRP host device, but does not
specifically refer to a particular session. specifically refer to a particular session.
A scheme of "msrps" indicates the underlying connection MUST be A scheme of "msrps" indicates that the underlying connection MUST be
protected with TLS. protected with TLS.
MSRP has an IANA registered recommended port defined in Section 15.4. MSRP has an IANA-registered recommended port defined in Section 15.4.
This value is not a default, as the URL negotiation process described This value is not a default, as the URL negotiation process described
herein will always include explicit port numbers. However, the URLs herein will always include explicit port numbers. However, the URLs
SHOULD be configured so that the recommended port is used whenever SHOULD be configured so that the recommended port is used whenever
appropriate. This makes life easier for network administrators who appropriate. This makes life easier for network administrators who
need to manage firewall policy for MSRP. need to manage firewall policy for MSRP.
The hostport will typically not contain a userinfo component, but MAY The hostport will typically not contain a userinfo component, but MAY
do so to indicate a user account for which the session is valid. do so to indicate a user account for which the session is valid.
Note that this is not the same thing as identifying the session Note that this is not the same thing as identifying the session
itself. If a userinfo component exists, it MUST be constructed only itself. If a userinfo component exists, it MUST be constructed only
skipping to change at page 15, line 19 skipping to change at page 15, line 28
The following is an example of a typical MSRP URL: The following is an example of a typical MSRP URL:
msrp://host.example.com:8493/asfd34;tcp msrp://host.example.com:8493/asfd34;tcp
6.1. MSRP URL Comparison 6.1. MSRP URL Comparison
MSRP URL comparisons MUST be performed according to the following MSRP URL comparisons MUST be performed according to the following
rules: rules:
1. The scheme must match. Scheme comparison is case insensitive. 1. The scheme MUST match. Scheme comparison is case insensitive.
2. If the hostpart contains an explicit IP address, and/or port, 2. If the hostpart contains an explicit IP address, and/or port,
these are compared for address and port equivalence. Otherwise, these are compared for address and port equivalence. Otherwise,
hostpart is compared as a case insensitive character string. hostpart is compared as a case insensitive character string.
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. A URL with an explicit port is never equivalent to exactly. A URL with an explicit port is never equivalent to
another with no port specified. another with no port specified.
4. The session-id part is compared as case sensitive. A URL without 4. The session-id part is compared as case sensitive. A URL without
a session-id part is never equivalent to one that includes one. a session-id part is never equivalent to one that includes one.
5. URLs with different "transport" parameters never match. Two URLs 5. URLs with different "transport" parameters never match. Two URLs
that are identical except for transport are not equivalent. The that are identical except for transport are not equivalent. The
transport parameter is case-insensitive. transport parameter is case-insensitive.
skipping to change at page 16, line 40 skipping to change at page 16, line 51
identifier and uses this and the method name to create an MSRP identifier and uses this and the method name to create an MSRP
request start line. Next, the sender places the target URL in a To- request start line. Next, the sender places the target URL in a To-
Path header field, and the sender's URL in a From-Path header field. Path header field, and the sender's URL in a From-Path header field.
If multiple URLs are present in the To-Path, the leftmost is the 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 first URL visited; the rightmost URL is the last URL visited. The
processing then becomes method specific. Additional method-specific processing then becomes method specific. Additional method-specific
header fields are added as described in the following sections. header fields are added as described in the following sections.
After any method-specific header fields are added, processing After any method-specific header fields are added, processing
continues to handle a body, if present. If the request has a body, continues to handle a body, if present. If the request has a body,
it must contain a Content-Type header field. It may contain other it MUST contain a Content-Type header field. It may contain other
MIME-specific header fields. The Content-Type header field MUST be MIME-specific header fields. The Content-Type header field MUST be
the last field in the message header section. The body MUST be the last field in the message header section. The body MUST be
separated from the header fields with an extra CRLF. separated from the header fields with an extra CRLF.
Non-SEND requests are not intended to carry message content, and are Non-SEND requests are not intended to carry message content, and are
therefore not interruptible. Non-SEND request bodies MUST NOT be therefore not interruptible. Non-SEND request bodies MUST NOT be
larger than 10240 octets. larger than 10240 octets.
Although this document does not discuss any particular usage of Although this document does not discuss any particular usage of
bodies in non-SEND requests, they may be useful in the future for bodies in non-SEND requests, they may be useful in the future for
skipping to change at page 17, line 15 skipping to change at page 17, line 26
large enough for most of such applications, but small enough to large enough for most of such applications, but small enough to
avoid the fairness issues caused by sending arbitrarily large avoid the fairness issues caused by sending arbitrarily large
content in non-interruptible method bodies. content in non-interruptible method bodies.
A request with no body MUST NOT include a Content-Type header field. A request with no body MUST NOT include a Content-Type header field.
Note that, if no body is present, no extra CRLF will be present Note that, if no body is present, no extra CRLF will be present
between the header section and the end-line. between the header section and the end-line.
Requests with no bodies are useful when a client wishes to send Requests with no bodies are useful when a client wishes to send
"traffic", but does not wish to send content to be rendered to the "traffic", but does not wish to send content to be rendered to the
peer user. For example, the offerer must send a SEND request peer user. For example, the active endpoint sends a SEND request
immediately upon establishing a connection. If it has nothing to immediately upon establishing a connection. If it has nothing to
say at the moment, it can send a request with no body. Bodiless say at the moment, it can send a request with no body. Bodiless
requests may also be used in certain applications to keep NAT requests may also be used in certain applications to keep NAT
bindings alive, etc. bindings alive, etc.
Bodiless requests are distinct from requests with empty bodies. A Bodiless requests are distinct from requests with empty bodies. A
request with an empty body will have a Content-Type header field request with an empty body will have a Content-Type header field
value, and will generally be rendered to the recipient according value, and will generally be rendered to the recipient according
to the rules for that type. to the rules for that type.
The end-line that terminates the request MUST be composed of seven The end-line that terminates the request MUST be composed of seven
"-" (minus sign) characters, the transaction ID as used in the start "-" (minus sign) characters, the transaction ID as used in the start
line, and a flag character. If a body is present, the end-line must line, and a flag character. If a body is present, the end-line MUST
be preceded by a CRLF that is not part of the body. If the chunk be preceded by a CRLF that is not part of the body. If the chunk
represents the data that forms the end of the complete message, the represents the data that forms the end of the complete message, the
flag value MUST be a "$". If sender is aborting an incomplete flag value MUST be a "$". If the sender is aborting an incomplete
message, and intends to send no further chunks in that message, it message, and intends to send no further chunks in that message, it
MUST be a "#". Otherwise it MUST be a "+". MUST be a "#". Otherwise it MUST be a "+".
If the request contains a body, the sender MUST ensure that the end- If the request contains a body, the sender MUST ensure that the end-
line (seven hyphens, the transaction identifier, and a continuation line (seven hyphens, the transaction identifier, and a continuation
flag) is not present in the body. If the end-line is present in the flag) is not present in the body. If the end-line is present in the
body, the sender MUST choose a new transaction identifier that is not body, the sender MUST choose a new transaction identifier that is not
present in the body, and add a CRLF if needed, and the end-line, present in the body, and add a CRLF if needed, and the end-line,
including the "$", "#", or "+" character. including the "$", "#", or "+" character.
Some implementations may choose to scan for the closing sequence as Some implementations may choose to scan for the closing sequence as
they send the body, and if it is encountered, simply interrupt the they send the body, and if it is encountered, simply interrupt the
chunk at that point and start a new transaction with a different chunk at that point and start a new transaction with a different
transaction identifier to carry the rest of the body. Other transaction identifier to carry the rest of the body. Other
implementation may choose to scan the data an ensure that the body implementation may choose to scan the data an ensure that the body
does not contain the transaction identifier before they start sending does not contain the transaction identifier before they start sending
the transaction. the transaction.
Finally, requests which have no body MUST NOT contain a Content-Type Finally, requests which have no body MUST NOT contain a Content-Type
header field or any other MIME specific header field. Requests header field or any other MIME-specific header field. Requests
without bodies MUST contain a end-line after the final header field. without bodies MUST contain a end-line after the final header field.
Once a request is ready for delivery, the sender follows the Once a request is ready for delivery, the sender follows the
connection management (Section 5.4) rules to forward the request over connection management (Section 5.4) rules to forward the request over
an existing open connection or create a new connection. an existing open connection or create a new connection.
7.1.1. Sending SEND Requests 7.1.1. Sending SEND Requests
When an endpoint has a message to deliver, it first generates a new When an endpoint has a message to deliver, it first generates a new
Message-ID. This ID MUST be globally unique. If necessary, it Message-ID. This ID MUST be globally unique. If necessary, it
skipping to change at page 18, line 40 skipping to change at page 18, line 52
Each chunk of a message MUST contain a Message-ID header field Each chunk of a message MUST contain a Message-ID header field
containing the Message-ID. If the sender wishes non-default status containing the Message-ID. If the sender wishes non-default status
reporting, it MUST insert a Failure-Report and/or Success-Report reporting, it MUST insert a Failure-Report and/or Success-Report
header field with an appropriate value. All chunks of the same header field with an appropriate value. All chunks of the same
message MUST use the same Failure-Report and Success-Report values in message MUST use the same Failure-Report and Success-Report values in
their SEND requests. their SEND requests.
If success reports are requested, i.e. the value of the Success- If success reports are requested, i.e. the value of the Success-
Report header field is "yes", the sending device MAY wish to run a Report header field is "yes", the sending device MAY wish to run a
timer of some value that makes sense for its application and take timer of some value that makes sense for its application and take
action if a success Report is not received in this time. There is no action if a success report is not received in this time. There is no
universal value for this timer. For many IM applications, it may be universal value for this timer. For many IM applications, it may be
2 minutes while for some trading systems it may be under a second. 2 minutes while for some trading systems it may be under a second.
Regardless of whether such a timer is used, if the success report has Regardless of whether such a timer is used, if the success report has
not been received by the time the session is ended, the device SHOULD not been received by the time the session is ended, the device SHOULD
inform the user. inform the user.
If the value of "Failure-Report" is set to "yes", then the sender of If the value of "Failure-Report" is set to "yes", then the sender of
the request runs a timer. If a 200 response to the transaction is the request runs a timer. If a 200 response to the transaction is
not received within 30 seconds from the time the last byte of the not received within 30 seconds from the time the last byte of the
transaction is sent, or submitted to the operating system for transaction is sent, or submitted to the operating system for
sending, the element MUST inform the user that the request probably sending, the element MUST inform the user that the request probably
failed. If the value is set to "partial", then the element sending failed. If the value is set to "partial", then the element sending
the transaction does not have to run a timer, but MUST inform the the transaction does not have to run a timer, but MUST inform the
user if it receives a non-recoverable error response to the user if it receives a non-recoverable error response to the
transaction. transaction.
The treatment of timers for success reports and failure reports is
intentionally inconsistent. An explicit timeout value makes sense
for failure reports since such reports will usually refer to a
message "chunk" which is acknowledged on a hop-by-hop basis. This
is not the case for success reports, which are end-to-end and may
refer to the entire message content, which can be arbitrarily
large.
If no Success-Report header field is present in a SEND request, it If no Success-Report header field is present in a SEND request, it
MUST be treated the same as a Success-Report header field with value MUST be treated the same as a Success-Report header field with value
of "no". If no Failure-Report header field is present, it MUST be of "no". If no Failure-Report header field is present, it MUST be
treated the same as a Failure-Report header field with value of treated the same as a Failure-Report header field with value of
"yes". If an MSRP endpoint receives a REPORT for a Message-ID it "yes". If an MSRP endpoint receives a REPORT for a Message-ID it
does not recognize, it SHOULD silently ignore the REPORT. does not recognize, it SHOULD silently ignore the REPORT.
Success-Report and Failure-Report header fields MUST NOT be present
in REPORT requests. MSRP nodes MUST NOT send REPORT requests in
response to REPORT requests. MSRP Nodes MUST NOT send MSRP responses
to REPORT requests.
The Byte-Range header field value contains a starting value (range- The Byte-Range header field value contains a starting value (range-
start) followed by a "-", an ending value (range-end) followed by a start) followed by a "-", an ending value (range-end) followed by a
"/", and finally the total length. The first octet in the message "/", and finally the total length. The first octet in the message
has a position of one, rather than a zero. has a position of one, rather than a zero.
The first chunk of the message SHOULD, and all subsequent chunks MUST The first chunk of the message SHOULD, and all subsequent chunks MUST
include a Byte-Range header field. The range-start field MUST include a Byte-Range header field. The range-start field MUST
indicate the position of the first byte in the body in the overall indicate the position of the first byte in the body in the overall
message (for the first chunk this field will have a value of one). message (for the first chunk this field will have a value of one).
The range-end field SHOULD indicate the position of the last byte in The range-end field SHOULD indicate the position of the last byte in
the body, if known. It MUST take the value of "*" if the position is the body, if known. It MUST take the value of "*" if the position is
unknown, or if the request needs to be interruptible. The total unknown, or if the request needs to be interruptible. The total
field SHOULD contain the total size of the message, if known. The field SHOULD contain the total size of the message, if known. The
total field MAY contain a "*" if the total size of the message is not total field MAY contain a "*" if the total size of the message is not
known in advance. The sender MUST send all chunks in Byte-Range known in advance. The sender MUST send all chunks in Byte-Range
order. (However, the receiver cannot assume the requests will be order. (However, the receiver cannot assume that the requests will
delivered in order, as intervening relays may have changed the be delivered in order, as intervening relays may have changed the
order.) order.)
There are some circumstances where an endpoint may choose to send an
empty SEND request. For the sake of consistency, a Byte-Range header
field referring to nonexistent or zero-length content MUST still have
a range-start value of 1. For example, "1-0/0"
To ensure fairness over a connection, senders MUST NOT send chunks To ensure fairness over a connection, senders MUST NOT send chunks
with a body larger than 2048 octets unless they are prepared to with a body larger than 2048 octets unless they are prepared to
interrupt them (meaning that any chunk with a body of greater than interrupt them (meaning that any chunk with a body of greater than
2048 octets will have a "*" character in the range-end field). A 2048 octets will have a "*" character in the range-end field). A
sender can use one of the following two strategies to satisfy this sender can use one of the following two strategies to satisfy this
requirement. The sender is STRONGLY RECOMMENDED to send messages requirement. The sender is STRONGLY RECOMMENDED to send messages
larger than 2048 octets using as few chunks as possible, interrupting larger than 2048 octets using as few chunks as possible, interrupting
chunks (at least 2048 octets long) only when other traffic is waiting chunks (at least 2048 octets long) only when other traffic is waiting
to use the same connection. Alternatively, the sender MAY simply to use the same connection. Alternatively, the sender MAY simply
send chunks in 2048 octet increments until the final chunk. Note send chunks in 2048 octet increments until the final chunk. Note
skipping to change at page 20, line 29 skipping to change at page 20, line 49
sent over the same connection, the device SHOULD implement some sent over the same connection, the device SHOULD implement some
scheme to alternate between them such that each concurrent request scheme to alternate between them such that each concurrent request
gets a chance to send some fair portion of data at regular intervals gets a chance to send some fair portion of data at regular intervals
suitable to the application. suitable to the application.
The sender MUST NOT assume that a message is received by the peer The sender MUST NOT assume that a message is received by the peer
with the same chunk allocation with which it was sent. An with the same chunk allocation with which it was sent. An
intervening relay could possibly break SEND requests into smaller intervening relay could possibly break SEND requests into smaller
chunks, or aggregate multiple chunks into larger ones. chunks, or aggregate multiple chunks into larger ones.
The default disposition of bodies is "render". If the sender wants The default disposition of bodies is "render". If the sender wants a
different disposition, it MAY insert a Content-Disposition[9] header different disposition, it MAY insert a Content-Disposition[9] header
field. Since MSRP can carry unencoded binary payloads, transfer field. Since MSRP can carry unencoded binary payloads, transfer
encoding is always "binary", and transfer-encoding parameters MUST encoding is always "binary", and transfer-encoding parameters MUST
NOT be present. NOT be present.
7.1.2. Sending REPORT Requests 7.1.2. Sending REPORT Requests
REPORT requests are similar to SEND requests, except that report REPORT requests are similar to SEND requests, except that report
requests MUST NOT include Success-Report or Failure-Report header requests MUST NOT include Success-Report or Failure-Report header
fields, and MUST contain a Status header field. REPORT requests MUST fields, and MUST contain a Status header field. REPORT requests MUST
skipping to change at page 21, line 7 skipping to change at page 21, line 27
An MSRP endpoint MUST be able to generate success REPORT requests. An MSRP endpoint MUST be able to generate success REPORT requests.
REPORT requests will normally not include a body, as the REPORT REPORT requests will normally not include a body, as the REPORT
request header fields can carry sufficient information in most cases. request header fields can carry sufficient information in most cases.
However, REPORT requests MAY include a body containing additional However, REPORT requests MAY include a body containing additional
information about the status of the associated SEND request. Such a information about the status of the associated SEND request. Such a
body is informational only, and the sender of the REPORT request body is informational only, and the sender of the REPORT request
SHOULD NOT assume that the recipient pays any attention to the body. SHOULD NOT assume that the recipient pays any attention to the body.
REPORT requests are not interruptible. REPORT requests are not interruptible.
Success-Report and Failure-Report header fields MUST NOT be present
in REPORT requests. MSRP nodes MUST NOT send REPORT requests in
response to REPORT requests. MSRP Nodes MUST NOT send MSRP responses
to REPORT requests.
7.1.3. Generating Success Reports 7.1.3. Generating Success Reports
An endpoint MUST send a success report if it successfully receives a When an endpoint receives a message in one or more chunks that
SEND request which contained a Success-Report value of "yes" and contain a Success-Reports value of "true", it MUST send a success
either contains a complete message, or contains the last chunk needed report or reports covering all bytes that are received successfully.
to complete the message. This request is sent following the normal The success reports are sent in the form of REPORT requests,
procedures (Section 7.1), with a few additional requirements. following the normal procedures (Section 7.1), with a few additional
requirements.
The endpoint inserts a To-Path header field containing the From-Path The receiver MAY wait until it receives the last chunk of a message,
value from the original request, and a From-Path header field and send a success report that covers the complete message.
containing the URL identifying itself in the session. The endpoint Alternately, it MAY generate incremental success REPORTs as the
then inserts a Status header field with a namespace of "000", a chunks are received. These can be sent periodically and cover all
short-status of "200" and an implementation defined comment phrase. the bytes that have been received so far, or they can be sent after a
It also inserts a Message-ID header field containing the value from chunk arrives and cover just the part from that chunk.
the original request.
The namespace field denotes the context of the short-status field. It is helpful to think of a success REPORT as reporting on a
The namespace value of "000" means the short-status should be particular range of bytes, rather than on a particular chunk sent
by a client. The sending client cannot depend on the Byte-Range
header field in a given success report matching that of a
particular SEND request. For example, an intervening MSRP relay
may break chunks into smaller chunks, or aggregate multiple chunks
into larger ones.
A side effect of this is, even if no relay is used, the receiving
client may report on byte ranges that do not exactly match those
in the original chunks sent by the sender. It can wait until all
bytes in a message are received and report on the whole, it can
report as it receives each chunk, or it can report on any other
received range.
Reporting on ranges smaller than the entire message contents
allows certain improved user experiences for the sender. For
example, a sending client could display incremental status
information showing which ranges of bytes have been acknowledged
by the receiver.
However, the choice on whether to report incrementally is entirely
up to the receiving client. There is no mechanism for the sender
to assert its desire to receive incremental reports or not. Since
the presence of a relay can cause the receiver to see a very
different chunk allocation than the sender, such a mechanism would
be of questionable value.
When generating a REPORT request, the endpoint inserts a To-Path
header field containing the From-Path value from the original
request, and a From-Path header field containing the URL identifying
itself in the session. The endpoint then inserts a Status header
field with a namespace of "000", a status-code of "200" and an
implementation-defined comment phrase. It also inserts a Message-ID
header field containing the value from the original request.
The namespace field denotes the context of the status-code field.
The namespace value of "000" means the status-code should be
interpreted in the same way as the matching MSRP transaction interpreted in the same way as the matching MSRP transaction
response code. If a future specification uses the short-status response code. If a future specification uses the status-code
field for some other purpose, it MUST define a new namespace field field for some other purpose, it MUST define a new namespace field
value. value.
The endpoint MUST NOT send a success report for a SEND request that The endpoint MUST NOT send a success report for a SEND request that
either contained no Success-Report header field, or contained such a either contained no Success-Report header field, or contained such a
field with a value of "no". That is, if no Success-Report header field with a value of "no". That is, if no Success-Report header
field is present, it is treated identically to one with a value of field is present, it is treated identically to one with a value of
"no." "no."
7.1.4. Generating Failure Reports 7.1.4. Generating Failure Reports
If an MSRP endpoint receives a SEND request that it cannot process If an MSRP endpoint receives a SEND request that it cannot process
for some reason, and the Failure-Report header field either was not for some reason, and the Failure-Report header field either was not
present in the original request, or had a value of "yes", it SHOULD present in the original request, or had a value of "yes", it SHOULD
simply include the appropriate error code in the transaction simply include the appropriate error code in the transaction
response. However, there may be situations where the error cannot be response. However, there may be situations where the error cannot be
determined quickly, such as when the endpoint is a gateway that must determined quickly, such as when the endpoint is a gateway that waits
wait for a downstream network to indicate an error. In this for a downstream network to indicate an error. In this situation, it
situation, it MAY send a 200 OK response to the request, and then MAY send a 200 OK response to the request, and then send a failure
send a failure REPORT request when the error is detected. REPORT request when the error is detected.
If the endpoint receives a SEND request with a Failure-Report header If the endpoint receives a SEND request with a Failure-Report header
field value of "no", then it MUST NOT send a failure REPORT request, field value of "no", then it MUST NOT send a failure REPORT request,
and MUST NOT send a transaction response. If the value is "partial", and MUST NOT send a transaction response. If the value is "partial",
it MUST NOT send a 200 transaction response to the request, but it MUST NOT send a 200 transaction response to the request, but
SHOULD send an appropriate non-200 class response if a failure SHOULD send an appropriate non-200 class response if a failure
occurs. occurs.
As stated above, if no Failure-Report header field is present, it As stated above, if no Failure-Report header field is present, it
MUST be treated the same as a Failure-Report header field with value MUST be treated the same as a Failure-Report header field with value
skipping to change at page 23, line 22 skipping to change at page 24, line 32
behavior.) behavior.)
Finally, the endpoint inserts a From-Path header field containing the Finally, the endpoint inserts a From-Path header field containing the
URL that identifies it in the context of the session, followed by the URL that identifies it in the context of the session, followed by the
end-line after the last header field. The response MUST be end-line after the last header field. The response MUST be
transmitted back on the same connection on which the original request transmitted back on the same connection on which the original request
arrived. arrived.
7.3. Receiving Requests 7.3. Receiving Requests
The receiving endpoint must first check the URL in the To-Path to The receiving endpoint MUST first check the URL in the To-Path to
make sure the request belongs to an existing session. When the make sure the request belongs to an existing session. When the
request is received, the To-Path will have exactly one URL, which request is received, the To-Path will have exactly one URL, which
MUST map to an existing session that is associated with the MUST map to an existing session that is associated with the
connection on which the request arrived. If this is not true, then connection on which the request arrived. If this is not true, then
the receiver MUST generate a 481 error and ignore the request. Note the receiver MUST generate a 481 error and ignore the request. Note
that if the Failure-Report header field had a value of "no", then no that if the Failure-Report header field had a value of "no", then no
error report would be sent. error report would be sent.
Further request processing by the receiver is method specific. Further request processing by the receiver is method specific.
skipping to change at page 24, line 12 skipping to change at page 25, line 20
that the chunk that has a termination character of "$" defines the that the chunk that has a termination character of "$" defines the
total length of the message. total length of the message.
It is technically illegal for the sender to prematurely interrupt It is technically illegal for the sender to prematurely interrupt
a request that had anything other than "*" in the last-byte a request that had anything other than "*" in the last-byte
position of the Byte-Range header field. But having the receiver position of the Byte-Range header field. But having the receiver
calculate a chunk length based on actual content adds resilience calculate a chunk length based on actual content adds resilience
in the face of sender errors. Since this should never happen with in the face of sender errors. Since this should never happen with
compliant senders, this only has a SHOULD strength. compliant senders, this only has a SHOULD strength.
Receivers MUST not assume the chunks will be delivered in order or Receivers MUST not assume that the chunks will be delivered in order
that they will receive all the chunks with "+" flags before they or that they will receive all the chunks with "+" flags before they
receive the chunk with the "$" flag. In certain cases of connection receive the chunk with the "$" flag. In certain cases of connection
failure, it is possible for information to be duplicated. If chunk failure, it is possible for information to be duplicated. If chunk
data is received that overlaps already received data for the same data is received that overlaps already received data for the same
message, the last chunk received SHOULD take precedence (even though message, the last chunk received SHOULD take precedence (even though
this may not have been the last chunk transmitted). For example, if this may not have been the last chunk transmitted). For example, if
bytes 1 to 100 were received and a chunk arrives that contains bytes bytes 1 to 100 were received and a chunk arrives that contains bytes
50 to 150, this second chunk will overwrite bytes 50 to 100 of the 50 to 150, this second chunk will overwrite bytes 50 to 100 of the
data that had already been received. Although other schemes work, data that had already been received. Although other schemes work,
this is the easiest for the receiver and results in consistent this is the easiest for the receiver and results in consistent
behavior between clients. behavior between clients.
skipping to change at page 25, line 6 skipping to change at page 26, line 16
determined by the MIME Content-Type and Content-Disposition. The determined by the MIME Content-Type and Content-Disposition. The
body MAY be rendered after the whole message is received or partially body MAY be rendered after the whole message is received or partially
rendered as it is being received. rendered as it is being received.
If the SEND request contained a Content-Type header field indicating If the SEND request contained a Content-Type header field indicating
an unsupported MIME type, and the Failure-Report value is not "no", an unsupported MIME type, and the Failure-Report value is not "no",
the receiver MUST generate a response with a status code of 415. All the receiver MUST generate a response with a status code of 415. All
MSRP endpoints MUST be able to receive the multipart/mixed [15] and MSRP endpoints MUST be able to receive the multipart/mixed [15] and
multipart/alternative [15] MIME types. multipart/alternative [15] MIME types.
If the Success-Report header field was set to "yes", then when a If the Success-Report header field was set to "yes", the receiver
complete message has been received, the receiver MUST send a success must construct and send one or more success reports, as described in
REPORT with a byte range covering the whole message. If the Success- Section 7.1.3.
Report header field is set to "yes", then the receiver MAY generate
incremental success REPORTs as the chunks are received. These can be
sent periodically and cover all the bytes that have been received so
far, or they can be sent after a chunk arrives and cover just the
part from that chunk.
It is helpful to think of a success REPORT as reporting on a
particular range of bytes, rather than on a particular chunk sent
by a client. The sending client cannot depend on the Byte-Range
header field in a given success report matching that of a
particular SEND request. For example, an intervening MSRP relay
may break chunks into smaller chunks, or aggregate multiple chunks
into larger ones.
A side effect of this is, even if no relay is used, the receiving
client may report on byte ranges that do not exactly match those
in the original chunks sent by the sender. It can wait until all
bytes in a message are received and report on the whole, it can
report as it receives each chunk, or it can report on any other
received range.
Reporting on ranges smaller than the entire message contents
allows certain improved user experiences for the sender. For
example, a sending client could display incremental status
information showing which ranges of bytes have been acknowledged
by the receiver.
However, the choice on whether to report incrementally is entirely
up to the receiving client. There is no mechanism for the sender
to assert its desire to receive incremental reports or not. Since
the presence of a relay can cause the receiver to see a very
different chunk allocation than the sender, such a mechanism would
be of questionable value.
7.3.2. Receiving REPORT Requests 7.3.2. Receiving REPORT Requests
When an endpoint receives a REPORT request, it correlates it to the When an endpoint receives a REPORT request, it correlates it to the
original SEND request using the Message-ID and the Byte-Range, if original SEND request using the Message-ID and the Byte-Range, if
present. If it requested success reports, then it SHOULD keep enough present. If it requested success reports, then it SHOULD keep enough
state about each outstanding sent message so that it can correlate state about each outstanding sent message so that it can correlate
REPORT requests to the original messages. REPORT requests to the original messages.
An endpoint that receives a REPORT request containing a Status header An endpoint that receives a REPORT request containing a Status header
field with a namespace field of "000" MUST interpret the report in field with a namespace field of "000" MUST interpret the report in
exactly the same way it would interpret an MSRP transaction response exactly the same way it would interpret an MSRP transaction response
with a response code matching the short-code field. with a response code matching the status-code field.
It is possible to receive a failure report or a failure transaction It is possible to receive a failure report or a failure transaction
response for a chunk that is currently being delivered. In this response for a chunk that is currently being delivered. In this
case, the entire message corresponding to that chunk SHOULD be case, the entire message corresponding to that chunk SHOULD be
aborted, by including the "#" character in the continuation field of aborted, by including the "#" character in the continuation field of
the end-line. the end-line.
It is possible that an endpoint will receive a REPORT request on a It is possible that an endpoint will receive a REPORT request on a
session that is no longer valid. The endpoint's behavior if this session that is no longer valid. The endpoint's behavior if this
happens is a matter of local policy. The endpoint is not required to happens is a matter of local policy. The endpoint is not required to
take any steps to facilitate such late delivery, i.e. it is not take any steps to facilitate such late delivery, i.e. it is not
expected to keep a connection active in case late REPORTs might expected to keep a connection active in case late REPORTs might
arrive. arrive.
When an endpoint that sent a SEND request receives a failure REPORT When an endpoint that sent a SEND request receives a failure REPORT
indicating that a particular byte range was not received, it MUST indicating that a particular byte range was not received, it MUST
treat the session as failed. If it wishes to recover, it MUST first treat the session as failed. If it wishes to recover, it MUST first
re-negotiate the URLs at the signaling level then resend that range re-negotiate the URLs at the signaling level then resend that range
of bytes of the message on the resulting new session. of bytes of the message on the resulting new session.
MSRP nodes MUST NOT send MSRP REPORT requests in responses to other MSRP nodes MUST NOT send MSRP REPORT requests in response to other
REPORT requests. REPORT requests.
8. Using MSRP with SIP and SDP 8. Using MSRP with SIP and SDP
MSRP sessions will typically be initiated using the Session MSRP sessions will typically be initiated using the Session
Description Protocol (SDP) [2] via the SIP offer/answer mechanism Description Protocol (SDP) [2] via the SIP offer/answer mechanism
[3]. [3].
This document defines a handful of new SDP parameters to set up MSRP This document defines a handful of new SDP parameters to set up MSRP
sessions. These are detailed below and in the IANA Considerations sessions. These are detailed below and in the IANA Considerations
section. section.
An MSRP media-line (that is, a media-line proposing MSRP) in the An MSRP media-line (that is, a media-line proposing MSRP) in the
session description is accompanied by a mandatory "path" attribute. session description is accompanied by a mandatory "path" attribute.
This attribute contains a space-separated list of URLs that must be This attribute contains a space-separated list of URLs to be visited
visited to contact the user agent advertising this session- to contact the user agent advertising this session-description. If
description. If more than one URL is present, the leftmost URL is more than one URL is present, the leftmost URL is the first URL to be
the first URL that must be visited to reach the target resource. visited to reach the target resource. (The path list can contain
(The path list can contain multiple URLs to allow for the deployment multiple URLs to allow for the deployment of gateways or relays in
of gateways or relays in the future.) MSRP implementations that can the future.) MSRP implementations that can accept incoming
accept incoming connections without the need for relays will connections without the need for relays will typically only provide a
typically only provide a single URL here. single URL here.
An MSRP media line is also accompanied by an "accept-types" An MSRP media line is also accompanied by an "accept-types"
attribute, and optionally an "accept-wrapped-types" attribute. These attribute, and optionally an "accept-wrapped-types" attribute. These
attributes are used to specify the MIME types that are acceptable to attributes are used to specify the MIME types that are acceptable to
the endpoint. the endpoint.
8.1. SDP Connection and Media Lines 8.1. SDP Connection and Media Lines
The format of an SDP connection-line takes the following format: An SDP connection-line takes the following format:
c=<network type> <address type> <connection address> c=<network type> <address type> <connection address>
The network type and address type fields are used as normal for SDP. The network type and address type fields are used as normal for SDP.
The connection address field MUST be set to the IP address or fully The connection address field MUST be set to the IP address or fully
qualified domain name from the MSRP URL identifying the endpoint in qualified domain name from the MSRP URL identifying the endpoint in
its path attribute. its path attribute.
The general format of an SDP media-line is: The general format of an SDP media-line is:
m=<media> <port> <protocol> <format list> m=<media> <port> <protocol> <format list>
An offered or accepted media-line for MSRP over TCP MUST include a An offered or accepted media-line for MSRP over TCP MUST include a
protocol field value of "TCP/MSRP", or "TCP/TLS/MSRP" for TLS. The protocol field value of "TCP/MSRP", or "TCP/TLS/MSRP" for TLS. The
media field value MUST be "message". The format list field MUST be media field value MUST be "message". The format list field MUST be
set to "*". set to "*".
The port field value MUST match the port value used in the endpoint's The port field value MUST match the port value used in the endpoint's
MSRP URL in the path attribute, except that, as described in [3], a MSRP URL in the path attribute, except that, as described in [3], a
user agent that wishes to accept an offer, but not a specific media- user agent that wishes to accept an offer, but not a specific media-
line MUST, set the port number of that media-line to zero (0) in the line, MUST set the port number of that media-line to zero (0) in the
response. Since MSRP allows multiple sessions to share the same TCP response. Since MSRP allows multiple sessions to share the same TCP
connection, multiple m-lines in a single SDP document may share the connection, multiple m-lines in a single SDP document may share the
same port field value; MSRP devices MUST NOT assume any particular same port field value; MSRP devices MUST NOT assume any particular
relationship between m-lines on the sole basis that they have relationship between m-lines on the sole basis that they have
matching port field values. matching port field values.
MSRP devices do not use the c-line address field, or the m-line MSRP devices do not use the c-line address field, or the m-line
port and format list fields to determine where to connect. port and format list fields to determine where to connect.
Rather, they use the attributes defined in this specification. Rather, they use the attributes defined in this specification.
The connection information is copied to the c-line and m-line for The connection information is copied to the c-line and m-line for
skipping to change at page 28, line 6 skipping to change at page 28, line 35
Each endpoint in an MSRP session is identified by a URL. These URLs Each endpoint in an MSRP session is identified by a URL. These URLs
are negotiated in the SDP exchange. Each SDP offer or answer that are negotiated in the SDP exchange. Each SDP offer or answer that
proposes MSRP MUST contain a path attribute containing one or more proposes MSRP MUST contain a path attribute containing one or more
MSRP URLs. The path attribute is used in an SDP a-line, and has the MSRP URLs. The path attribute is used in an SDP a-line, and has the
following syntax: following syntax:
path = path-label ":" path-list path = path-label ":" path-list
path-label = "path" path-label = "path"
path-list= MSRP-URL *(SP MSRP-URL) path-list= MSRP-URL *(SP MSRP-URL)
where MSRP-URL is an msrp: or msrps: URL as defined in Section 6. where MSRP-URL is an "msrp" or "msrps" URL as defined in Section 6.
MSRP URLs included in an SDP offer or answer MUST include explicit MSRP URLs included in an SDP offer or answer MUST include explicit
port numbers. port numbers.
An MSRP device uses the URL to determine a host address, port, An MSRP device uses the URL to determine a host address, port,
transport, and protection level when connecting, and to identify the transport, and protection level when connecting, and to identify the
target when sending requests and responses. target when sending requests and responses.
The offerer and answerer each selects a URL to represent itself and The offerer and answerer each selects a URL to represent itself and
sends it to the peer device in the SDP document. Each device stores sends it to the peer device in the SDP document. Each device stores
the path value received from the peer and uses that value as the the path value received from the peer and uses that value as the
skipping to change at page 29, line 29 skipping to change at page 30, line 9
never introduce a relay, they need to be able to interoperate with never introduce a relay, they need to be able to interoperate with
other endpoints that do use relays. Therefore, they MUST be prepared other endpoints that do use relays. Therefore, they MUST be prepared
to receive more than one URL in the SDP path attribute. When an to receive more than one URL in the SDP path attribute. When an
endpoint receives more than one URL in a path attribute, only the endpoint receives more than one URL in a path attribute, only the
first entry is relevant for purposes of resolving the address and first entry is relevant for purposes of resolving the address and
port, and establishing the network connection, as it describes the port, and establishing the network connection, as it describes the
first adjacent hop. first adjacent hop.
If an endpoint puts more than one URL in a path attribute, the final If an endpoint puts more than one URL in a path attribute, the final
URL in the path attribute (the peer URL) identifies the session, and URL in the path attribute (the peer URL) identifies the session, and
must not duplicate the URL of any other session in which the endpoint MUST not duplicate the URL of any other session in which the endpoint
is currently participating. Uniqueness requirements for other is currently participating. Uniqueness requirements for other
entries in the path attribute are out of scope for this document. entries in the path attribute are out of scope for this document.
8.4. Updated SDP Offers 8.4. Updated SDP Offers
MSRP endpoints may sometimes need to send additional SDP exchanges MSRP endpoints may sometimes need to send additional SDP exchanges
for an existing session. They may need to send periodic exchanges for an existing session. They may need to send periodic exchanges
with no change to refresh state in the network, for example, SIP with no change to refresh state in the network, for example, SIP
session timers or the SIP UPDATE[23] request. They may need to session timers or the SIP UPDATE[23] request. They may need to
change some other stream in a session without affecting the MSRP change some other stream in a session without affecting the MSRP
skipping to change at page 30, line 38 skipping to change at page 31, line 21
sender may attempt to send content with media types that have not sender may attempt to send content with media types that have not
been explicitly listed. Likewise, an entry with an explicit type and been explicitly listed. Likewise, an entry with an explicit type and
a "*" character as the subtype indicates that the sender may attempt a "*" character as the subtype indicates that the sender may attempt
to send content with any subtype of that type. If the receiver 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 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 does so. If not, it will respond with a 415 response. Note that all
explicit entries SHOULD be considered preferred over any non-listed explicit entries SHOULD be considered preferred over any non-listed
types. This feature is needed as, otherwise, the list of formats for types. This feature is needed as, otherwise, the list of formats for
rich IM devices may be prohibitively large. rich IM devices may be prohibitively large.
This specification requires the support of certain data formats.
Mandatory formats MUST be signaled like any other, either explicitly
or by the use of a "*".
The accept-types attribute may include container types, that is, MIME The accept-types attribute may include container types, that is, MIME
formats that contain other types internally. If compound types are formats that contain other types internally. If compound types are
used, the types listed in the accept-types attribute may be used both 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. as the root payload, or may be wrapped in a listed container type.
Any container types MUST also be listed in the accept-types Any container types MUST also be listed in the accept-types
attribute. attribute.
Occasionally an endpoint will need to specify a MIME body type that Occasionally an endpoint will need to specify a MIME body type that
can only be used if wrapped inside a listed container type. can only be used if wrapped inside a listed container type.
skipping to change at page 33, line 22 skipping to change at page 34, line 5
should take precedence. should take precedence.
SIP INVITE requests may be forked by a SIP proxy, resulting in more SIP INVITE requests may be forked by a SIP proxy, resulting in more
than one endpoint receiving the same INVITE. SIP early media [28] than one endpoint receiving the same INVITE. SIP early media [28]
techniques can be used to establish a preliminary session with each techniques can be used to establish a preliminary session with each
endpoint so the initial message(s) are displayed on each endpoint, endpoint so the initial message(s) are displayed on each endpoint,
and canceling the INVITE transaction for any endpoints that do not and canceling the INVITE transaction for any endpoints that do not
send MSRP traffic after some period of time, so that they cease send MSRP traffic after some period of time, so that they cease
receiving MSRP traffic from the inviter. receiving MSRP traffic from the inviter.
8.9. SDP direction attribute and MSRP
SDP defines a number of attributes that modify the direction of media
flows. These are the "sendonly", "recvonly", "inactive", and
"sendrecv" attributes.
If a "sendonly" or "recvonly" attribute modifies an MSRP media
description line, the attribute indicates the direction of MSRP SEND
requests that contain regular message payloads. Unless otherwise
specified, these attributes do not affect the direction of other
types of requests, such as REPORT. SEND requests that contain some
kind of control or reporting protocol rather than regular message
payload (e.g., IMDN reports) should be generated according to the
protocol rules as if no direction attribute were present.
9. Formal Syntax 9. Formal Syntax
MSRP is a text protocol that uses the UTF-8 [14] transformation MSRP is a text protocol that uses the UTF-8 [14] transformation
format. format.
The following syntax specification uses the augmented Backus-Naur The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [6]. Form (BNF) as described in RFC-2234 [6].
msrp-req-or-resp = msrp-request / msrp-response msrp-req-or-resp = msrp-request / msrp-response
msrp-request = req-start headers [content-stuff] end-line msrp-request = req-start headers [content-stuff] end-line
skipping to change at page 37, line 33 skipping to change at page 38, line 28
already bound to another network connection. The sender should cease already bound to another network connection. The sender should cease
sending messages for that session on this connection. sending messages for that session on this connection.
11. Examples 11. Examples
11.1. Basic IM Session 11.1. Basic IM Session
This section shows an example flow for the most common scenario. The This section shows an example flow for the most common scenario. The
example assumes SIP is used to transport the SDP exchange. Details example assumes SIP is used to transport the SDP exchange. Details
of the SIP messages and SIP proxy infrastructure are omitted for the of the SIP messages and SIP proxy infrastructure are omitted for the
sake of brevity. In the example, assume the offerer is sake of brevity. In the example, assume that the offerer is
sip:alice@example.com and the answerer is sip:bob@example.com. sip:alice@example.com and the answerer is sip:bob@example.com.
Alice Bob Alice Bob
| | | |
| | | |
|(1) (SIP) INVITE | |(1) (SIP) INVITE |
|----------------------->| |----------------------->|
|(2) (SIP) 200 OK | |(2) (SIP) 200 OK |
|<-----------------------| |<-----------------------|
|(3) (SIP) ACK | |(3) (SIP) ACK |
skipping to change at page 40, line 8 skipping to change at page 41, line 8
Alice invalidates local session state. Alice invalidates local session state.
9. Bob invalidates local state for the session. 9. Bob invalidates local state for the session.
Bob->Alice (SIP): 200 OK Bob->Alice (SIP): 200 OK
11.2. Message with XHTML Content 11.2. Message with XHTML Content
MSRP dsdfoe38sd SEND MSRP dsdfoe38sd SEND
To-Path: msrp://alice.atlanta.com:7777/iau39;tcp To-Path: msrp://alice.example.com:7777/iau39;tcp
From-Path: msrp://bob.atlanta.com:8888/9di4ea;tcp From-Path: msrp://bob.example.com:8888/9di4ea;tcp
Message-ID: 456 Message-ID: 456
Content-Type: application/xhtml+xml Content-Type: application/xhtml+xml
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html <!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"_http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd_"> "_http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd_">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head> <head>
<title>FY2005 Results</title> <title>FY2005 Results</title>
skipping to change at page 41, line 13 skipping to change at page 42, line 13
-------d93kswow$ -------d93kswow$
11.5. Positive Report 11.5. Positive Report
Alice->Bob (MSRP): Alice->Bob (MSRP):
MSRP d93kswow SEND MSRP d93kswow SEND
To-Path: msrp://bob.example.com:8888/9di4ea;tcp To-Path: msrp://bob.example.com:8888/9di4ea;tcp
From-Path: msrp://alicepc.example.com:7777/iau39;tcp From-Path: msrp://alicepc.example.com:7777/iau39;tcp
Message-ID: 12339sdqwer Message-ID: 12339sdqwer
Byte-Range: 1-106/106
Success-Report: yes Success-Report: yes
Failure-Report: no Failure-Report: no
Content-Type: text/html Content-Type: text/html
<html><body> <html><body>
<p>Here is that important link... <p>Here is that important link...
<a href="www.example.com/foobar">foobar</a> <a href="http://www.example.com/foobar">foobar</a>
</p> </p>
</body></html> </body></html>
-------d93kswow$ -------d93kswow$
Bob->Alice (MSRP): Bob->Alice (MSRP):
MSRP dkei38sd REPORT MSRP dkei38sd REPORT
To-Path: msrp://alicepc.example.com:7777/iau39;tcp To-Path: msrp://alicepc.example.com:7777/iau39;tcp
From-Path: msrp://bob.example.com:8888/9di4ea;tcp From-Path: msrp://bob.example.com:8888/9di4ea;tcp
Message-ID: 12339sdqwer Message-ID: 12339sdqwer
Byte-Range: 1-106/106
Status: 000 200 OK Status: 000 200 OK
-------dkei38sd$ -------dkei38sd$
11.6. Forked IM 11.6. Forked IM
Traditional IM systems generally do a poor job of handling multiple Traditional IM systems generally do a poor job of handling multiple
simultaneous IM clients online for the same person. While some do a simultaneous IM clients online for the same person. While some do a
better job than many existing systems, handling of multiple clients better job than many existing systems, handling of multiple clients
is fairly crude. This becomes a much more significant issue when is fairly crude. This becomes a much more significant issue when
always-on mobile devices are available, but it is desirable to use always-on mobile devices are available, but it is desirable to use
them only if another IM client is not available. them only if another IM client is not available.
Using SIP makes rendezvous decisions explicit, deterministic, and Using SIP makes rendezvous decisions explicit, deterministic, and
very flexible. In contrast, "page-mode" IM systems use implicit very flexible. In contrast, "page-mode" IM systems use implicit
implementation-specific decisions which IM clients cannot influence. implementation-specific decisions which IM clients cannot influence.
With SIP session mode messaging, rendezvous decisions can be under With SIP session-mode messaging, rendezvous decisions can be under
control of the client in a predictable, interoperable way for any control of the client in a predictable, interoperable way for any
host that implements callee capabilities [30]. As a result, host that implements callee capabilities [30]. As a result,
rendezvous policy is managed consistently for each address of record. rendezvous policy is managed consistently for each address of record.
The following example shows Juliet with several IM clients where she The following example shows Juliet with several IM clients where she
can be reached. Each of these has a unique SIP Contact and MSRP can be reached. Each of these has a unique SIP Contact and MSRP
session. The example takes advantage of SIP's capability to "fork" session. The example takes advantage of SIP's capability to "fork"
an invitation to several Contacts in parallel, in sequence, or in an invitation to several Contacts in parallel, in sequence, or in
combination. Juliet has registered from her chamber, the balcony, combination. Juliet has registered from her chamber, the balcony,
her PDA, and as a last resort, you can leave a message with her her PDA, and as a last resort, you can leave a message with her
Nurse. Juliet's contacts are listed below. The q-values express Nurse. Juliet's contacts are listed below. The q-values express
relative preference (q=1.0 is the highest preference). relative preference (q=1.0 is the highest preference).
The example uses REGISTER to learn of Juliet's registered
contacts. This does not constitute an endorsement of that
approach; it is used here to avoid cluttering the example with too
many SIP details. A more realistic application would be the use a
SIP proxy or redirect server for this purpose.
We query for a list of Juliet's contacts by sending a REGISTER:
REGISTER sip:thecapulets.example.com SIP/2.0
To: Juliet <sip:juliet@thecapulets.example.com>
From: Romeo <sip:romeo@montague.example.com>;tag=12345
Via: SIP/2.0/UDP romeospc.example.com:5060;branch=z9hG4bKnashds7
Call-ID: 09887877
Max-Forwards=70
CSeq: 772 REGISTER
The Response contains her Contacts:
SIP/2.0 200 OK
To: Juliet <sip:juliet@thecapulets.example.com>
From: Juliet <sip:juliet@thecapulets.example.com>;tag=12345
Via: SIP/2.0/UDP romeospc.example.com:5060;branch=z9hG4bKnashds7
Call-ID: 09887877
CSeq: 772 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
When Romeo opens his IM program, he selects Juliet and types the When Romeo opens his IM program, he selects Juliet and types the
message "art thou hither?" (instead of "you there?"). His client message "art thou hither?" (instead of "you there?"). His client
sends a SIP invitation to sip:juliet@thecapulets.example.com. The sends a SIP invitation to sip:juliet@thecapulets.example.com. The
proxy there tries first the balcony and the chamber simultaneously. proxy there tries first the balcony and the chamber simultaneously.
A client is running on both those systems, both of which set up early A client is running on each of those systems, both of which set up
sessions of MSRP with Romeo's client. The client automatically sends early sessions of MSRP with Romeo's client. The client automatically
the message over MSRPS to the two MSRP URIs involved. After a delay sends the message over MSRP to the two MSRP URIs involved. After a
of a several seconds with no reply or activity from Juliet, the proxy delay of a several seconds with no reply or activity from Juliet, the
cancels the invitation at her first two contacts, and forwards the proxy cancels the invitation at her first two contacts, and forwards
invitation on to Juliet's PDA. Since her father is talking to her the invitation on to Juliet's PDA. Since her father is talking to
about her wedding, she selects "Do Not Disturb" on her PDA, which her about her wedding, she selects "Do Not Disturb" on her PDA, which
sends a "Busy Here" response. The proxy then tries the Nurse, who sends a "Busy Here" response. The proxy then tries the Nurse, who
answers and tells Romeo what is going on. answers and tells Romeo what is going on.
Romeo Juliet's Juliet/ Juliet/ Juliet/ Nurse Romeo Juliet's Juliet/ Juliet/ Juliet/ Nurse
Proxy balcony chamber PDA Proxy balcony chamber PDA
| | | | | | | | | | | |
|--INVITE--->| | | | | |--INVITE--->| | | | |
| |--INVITE--->| | | | | |--INVITE--->| | | |
| |<----180----| | | | | |<----180----| | | |
skipping to change at page 45, line 15 skipping to change at page 45, line 15
12. Extensibility 12. Extensibility
MSRP was designed to be only minimally extensible. New MSRP Methods, MSRP was designed to be only minimally extensible. New MSRP Methods,
header fields, and status codes can be defined in standards track header fields, and status codes can be defined in standards track
RFCs. MSRP does not contain a version number or any negotiation RFCs. MSRP does not contain a version number or any negotiation
mechanism to require or discover new features. If an extension is mechanism to require or discover new features. If an extension is
specified in the future that requires negotiation, the specification specified in the future that requires negotiation, the specification
will need to describe how the extension is to be negotiated in the will need to describe how the extension is to be negotiated in the
encapsulating signaling protocol. If a non-interoperable update or encapsulating signaling protocol. If a non-interoperable update or
extension occurs in the future, it will be treated as a new protocol, extension occurs in the future, it will be treated as a new protocol,
and must describe how its use will be signaled. and MUST describe how its use will be signaled.
In order to allow extension header fields without breaking In order to allow extension header fields without breaking
interoperability, if an MSRP device receives a request or response interoperability, if an MSRP device receives a request or response
containing a header field that it does not understand, it MUST ignore containing a header field that it does not understand, it MUST ignore
the header field and process the request or response as if the header the header field and process the request or response as if the header
field was not present. If an MSRP device receives a request with an field was not present. If an MSRP device receives a request with an
unknown method, it MUST return a 501 response. unknown method, it MUST return a 501 response.
MSRP was designed to use lists of URLs instead of a single URL in the MSRP was designed to use lists of URLs instead of a single URL in the
To-Path and From-Path header fields in anticipation of relay or To-Path and From-Path header fields in anticipation of relay or
gateway functionality being added. In addition, msrp: and msrps: gateway functionality being added. In addition, "msrp" and "msrps"
URLs can contain parameters that are extensible. URLs can contain parameters that are extensible.
13. CPIM Compatibility 13. CPIM Compatibility
MSRP sessions may go to a gateway to other CPIM [26] compatible MSRP sessions may go to a gateway to other CPIM [26] compatible
protocols. If this occurs, the gateway MUST maintain session state, protocols. If this occurs, the gateway MUST maintain session state,
and MUST translate between the MSRP session semantics and CPIM and MUST translate between the MSRP session semantics and CPIM
semantics, which do not include a concept of sessions. Furthermore, semantics, which do not include a concept of sessions. Furthermore,
when one endpoint of the session is a CPIM gateway, instant messages when one endpoint of the session is a CPIM gateway, instant messages
SHOULD be wrapped in "message/cpim" [12] bodies. Such a gateway MUST SHOULD be wrapped in "message/cpim" [12] bodies. Such a gateway MUST
skipping to change at page 46, line 21 skipping to change at page 46, line 21
The NS, To, and CC header fields may occur multiple times. Other The NS, To, and CC header fields may occur multiple times. Other
header fields defined in RFC3862 MUST NOT occur more than once in a header fields defined in RFC3862 MUST NOT occur more than once in a
given message/cpim body part in an MSRP message. The Require header given message/cpim body part in an MSRP message. The Require header
field MAY include multiple values. The NS header field MAY occur field MAY include multiple values. The NS header field MAY occur
zero or more times, depending on how many name spaces are being zero or more times, depending on how many name spaces are being
referenced. referenced.
Extension header fields MAY occur more than once, depending on the Extension header fields MAY occur more than once, depending on the
definition of such header fields. definition of such header fields.
Using message/cpim envelopes are also useful if an MSRP device Using message/cpim envelopes is also useful if an MSRP device
wishes to send a message on behalf of some other identity. The wishes to send a message on behalf of some other identity. The
device may add a message/cpim envelope with the appropriate From device may add a message/cpim envelope with the appropriate From
header field value. header field value.
14. Security Considerations 14. Security Considerations
Instant Messaging systems are used to exchange a variety of sensitive Instant Messaging systems are used to exchange a variety of sensitive
information ranging from personal conversations, to corporate information ranging from personal conversations, to corporate
confidential information, to account numbers and other financial confidential information, to account numbers and other financial
trading information. IM is used by individuals, corporations, and trading information. IM is used by individuals, corporations, and
skipping to change at page 48, line 39 skipping to change at page 48, line 39
messages sent over MSRP. The connection can still be hijacked since messages sent over MSRP. The connection can still be hijacked since
the secret is sent in clear text to the other end of the TCP the secret is sent in clear text to the other end of the TCP
connection, but the consequences are mitigated if all the MSRP connection, but the consequences are mitigated if all the MSRP
content is encrypted and signed with S/MIME. Although out of scope content is encrypted and signed with S/MIME. Although out of scope
for this document, the SIP negotiation of MSRP session can negotiate for this document, the SIP negotiation of MSRP session can negotiate
symmetric keying material to be used with S/MIME for integrity and symmetric keying material to be used with S/MIME for integrity and
privacy. privacy.
14.3. Using TLS in Peer to Peer Mode 14.3. Using TLS in Peer to Peer Mode
TLS can be used with a self signed certificate as long as there is a TLS can be used with a self-signed certificate as long as there is a
mechanism for both sides to ascertain that the other side used the mechanism for both sides to ascertain that the other side used the
correct certificate. When used with SDP and SIP, the correct correct certificate. When used with SDP and SIP, the correct
certificate can be verified by passing a fingerprint of the certificate can be verified by passing a fingerprint of the
certificate in the SDP and ensuring that the SDP has suitable certificate in the SDP and ensuring that the SDP has suitable
integrity protection. When SIP is used to transport the SDP, the integrity protection. When SIP is used to transport the SDP, the
integrity can be provided by the SIP Identity mechanism[16]. The integrity can be provided by the SIP Identity mechanism[16]. The
rest of this section describes the details of this approach. rest of this section describes the details of this approach.
If self-signed certificates are used, the content of the If self-signed certificates are used, the content of the
subjectAltName attribute inside the certificate MAY use the uniform subjectAltName attribute inside the certificate MAY use the uniform
resource identifier (URI) of the user. In SIP, this URI of the user resource identifier (URI) of the user. In SIP, this URI of the user
is the User's Address of Record (AOR). This is useful for debugging is the User's Address of Record (AOR). This is useful for debugging
purposes only and is not required to bind the certificate to one of purposes only and is not required to bind the certificate to one of
the communication endpoints. Unlike normal TLS operations in this the communication endpoints. Unlike normal TLS operations in this
protocol, when doing peer to peer TLS, the subjectAltName is not an protocol, when doing peer-to-peer TLS, the subjectAltName is not an
important component of the certificate verification. If the endpoint important component of the certificate verification. If the endpoint
is also able to make anonymous sessions, a distinct, unique is also able to make anonymous sessions, a distinct, unique
certificate MUST be used for this purpose. For a client that works certificate MUST be used for this purpose. For a client that works
with multiple users, each user SHOULD have its own certificate. with multiple users, each user SHOULD have its own certificate.
Because the generation of public/private key pairs is relatively Because the generation of public/private key pairs is relatively
expensive, endpoints are not required to generate certificates for expensive, endpoints are not required to generate certificates for
each session. each session.
A certificate fingerprint is the output of a one-way hash function A certificate fingerprint is the output of a one-way hash function
computed over the distinguished encoding rules (DER) form of the computed over the distinguished encoding rules (DER) form of the
certificate. The endpoint MUST use the certificate fingerprint certificate. The endpoint MUST use the certificate fingerprint
attribute as specified in [17] and MUST include this in the SDP. The attribute as specified in [17] and MUST include this in the SDP. The
certificate presented during the TLS handshake needs to match the certificate presented during the TLS handshake needs to match the
fingerprint exchanged via the SDP and if the fingerprint does not fingerprint exchanged via the SDP and if the fingerprint does not
match the hashed certificate then the endpoint MUST tear down the match the hashed certificate then the endpoint MUST tear down the
media session immediately. media session immediately.
When using SIP, the integrity of the fingerprint can be ensured When using SIP, the integrity of the fingerprint can be ensured
through the SIP Identity mechanism [16]. When a client wishes to use through the SIP Identity mechanism [16]. When a client wishes to use
SIP to set up a secure MSRP session with another endpoint it sends an SIP to set up a secure MSRP session with another endpoint it sends an
offer in a SIP message to the other endpoint. This offer includes, SDP offer in a SIP message to the other endpoint. This offer
as part of the SDP payload, the fingerprint of the certificate that includes, as part of the SDP payload, the fingerprint of the
the endpoint wants to use. The SIP message containing the offer is certificate that the endpoint wants to use. The SIP message
sent to the offerer's sip proxy which will add an identity header containing the offer is sent to the offerer's SIP proxy which will
according to the procedures outlined in [16]. When the far endpoint add an Identity header according to the procedures outlined in [16].
receives the SIP message it can verify the identity of the sender When the far endpoint receives the SIP message it can verify the
using the identity header. Since the identity header is a digital identity of the sender using the Identity header. Since the Identity
signature across several SIP headers, in addition to the body or header is a digital signature across several SIP headers, in addition
bodies of the SIP message, the receiver can also be certain that the to the body or bodies of the SIP message, the receiver can also be
message has not been tampered with after the digital signature was certain that the message has not been tampered with after the digital
added to the SIP message. signature was added to the SIP message.
An example of SDP with a fingerprint attribute is shown in the An example of SDP with a fingerprint attribute is shown in the
following figure. Note the fingerprint is shown spread over two following figure. Note the fingerprint is shown spread over two
lines due to formatting consideration but should all be on one line. lines due to formatting consideration but should all be on one line.
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
m=message 7654 TCP/TLS/MSRP * m=message 7654 TCP/TLS/MSRP *
a=accept-types:text/plain a=accept-types:text/plain
a=path:msrp://atlanta.example.com:7654/jshA7we;tcp a=path:msrps://atlanta.example.com:7654/jshA7we;tcp
a=fingerprint:SHA-1 \ a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
14.4. Other Security Concerns 14.4. Other Security Concerns
MSRP cannot be used as an amplifier for DoS attacks, but it can be MSRP cannot be used as an amplifier for DoS attacks, but it can be
used to form a distributed attack to consume TCP connection resource used to form a distributed attack to consume TCP connection resources
on servers. The attacker, Mallory, sends a SIP INVITE with no offer on servers. The attacker, Mallory, sends a SIP INVITE with no offer
to Alice. Alice returns a 200 with an offer and Mallory returns an to Alice. Alice returns a 200 with an offer and Mallory returns an
answer with SDP indicating that his MSRP address is the address of answer with SDP indicating that his MSRP address is the address of
Tom. Since Alice sent the offer, Alice will initiate a connection to Tom. Since Alice sent the offer, Alice will initiate a connection to
Tom using up resources on Tom's server. Given the huge number of IM Tom using up resources on Tom's server. Given the huge number of IM
clients, and the relatively few TCP connections that most servers clients, and the relatively few TCP connections that most servers
support, this is a fairly straightforward attack. support, this is a fairly straightforward attack.
SIP is attempting to address issues in dealing with spam. The spam SIP is attempting to address issues in dealing with spam. The spam
issue is probably best dealt with at the SIP level when an MSRP issue is probably best dealt with at the SIP level when an MSRP
skipping to change at page 51, line 46 skipping to change at page 51, line 46
some degree of sanity checking on byte-range values before allocating some degree of sanity checking on byte-range values before allocating
such buffers. such buffers.
15. IANA Considerations 15. IANA Considerations
This specification instructs IANA to create a new registry for MSRP This specification instructs IANA to create a new registry for MSRP
parameters. The MSRP Parameter registry is a container for sub- parameters. The MSRP Parameter registry is a container for sub-
registries. This section further introduces sub-registries for MSRP registries. This section further introduces sub-registries for MSRP
method names, status codes, and header field names. method names, status codes, and header field names.
Additionally, Section 15.4 through Section 15.7 register new
parameters in existing IANA registries.
[NOTE TO IANA/RFC Editor: Please replace all occurrences of RFCXXXX [NOTE TO IANA/RFC Editor: Please replace all occurrences of RFCXXXX
in this section with the actual number assigned to this document.] in this section with the actual number assigned to this document.]
15.1. MSRP Method Names 15.1. MSRP Method Names
This specification establishes the Method sub-registry under MSRP This specification establishes the Method sub-registry under MSRP
Parameters and initiates its population as follows: Parameters and initiates its population as follows. New parameters
in this sub-registry must be published in an RFC (either as an IETF
submission or RFC Editor submission).
SEND - [RFCXXXX] SEND - [RFCXXXX]
REPORT - [RFCXXXX] REPORT - [RFCXXXX]
The following information must be provided in an RFC publication in The following information MUST be provided in an RFC publication in
order to register a new MSRP Method: order to register a new MSRP Method:
The method name. The method name.
The RFC number in which the method is registered. The RFC number in which the method is registered.
15.2. MSRP Header Fields 15.2. MSRP Header Fields
This specification establishes the header field-Field sub-registry This specification establishes the header field-Field sub-registry
under MSRP Parameters. Its initial population is defined as follows: under MSRP Parameters. New parameters in this sub-registry must be
published in an RFC (either as an IETF submission or RFC Editor
submission). Its initial population is defined as follows:
To-Path - [RFCXXXX] To-Path - [RFCXXXX]
From-Path - [RFCXXXX] From-Path - [RFCXXXX]
Success-Report - [RFCXXXX] Success-Report - [RFCXXXX]
Failure-Report - [RFCXXXX] Failure-Report - [RFCXXXX]
Byte-Range - [RFCXXXX] Byte-Range - [RFCXXXX]
Status - [RFCXXXX] Status - [RFCXXXX]
The following information must be provided in an RFC publication in The following information MUST be provided in an RFC publication in
order to register a new MSRP Method: order to register a new MSRP header field:
The header field name. The header field name.
The RFC number in which the method is registered. The RFC number in which the method is registered.
15.3. MSRP Status Codes 15.3. MSRP Status Codes
This specification establishes the Status-Code sub-registry under This specification establishes the Status-Code sub-registry under
MSRP Parameters. Its initial population is defined in Section 10. MSRP Parameters. New parameters in this sub-registry must be
It takes the following format: published in an RFC (either as an IETF submission or RFC Editor
submission). Its initial population is defined in Section 10. It
takes the following format:
Code [RFC Number] Code [RFC Number]
The following information must be provided in an RFC publication in The following information MUST be provided in an RFC publication in
order to register a new MSRP Method: order to register a new MSRP status code:
The status code number. The status code number.
The RFC number in which the method is registered. The RFC number in which the method is registered.
15.4. MSRP Port 15.4. MSRP Port
MSRP uses TCP port XYZ. Usage of this value is described in MSRP uses TCP port XYZ. Usage of this value is described in
Section 6. Section 6.
[NOTE TO IANA/RFC Editor: Please replace XYZ in this section with the [NOTE TO IANA/RFC Editor: Please replace XYZ in this section with the
skipping to change at page 55, line 4 skipping to change at page 55, line 9
Subject to Charset Attribute: No Subject to Charset Attribute: No
Purpose and Appropriate Values: The "path" attribute indicates a Purpose and Appropriate Values: The "path" attribute indicates a
series of MSRP devices that must be visited by messages sent in series of MSRP devices that must be visited by messages sent in
the session, including the final endpoint. The attribute contains the session, including the final endpoint. The attribute contains
one or more MSRP URIs, delimited by the space character. one or more MSRP URIs, delimited by the space character.
16. Contributors and Acknowledgments 16. Contributors and Acknowledgments
In addition to the editors, the following people contributed In addition to the editors, the following people contributed
extensive work to this document: Chris Boulton, Paul Kyzivat, Orit extensive work to this document: Chris Boulton, Paul Kyzivat, Orit
Levin, Adam Roach, Jonathan Rosenberg, and Robert Sparks. Levin, Hans Persson, Adam Roach, Jonathan Rosenberg, and Robert
Sparks.
The following people contributed substantial discussion and feedback The following people contributed substantial discussion and feedback
to this ongoing effort: Eric Burger, Allison Mankin, Jon Peterson, to this ongoing effort: Eric Burger, Allison Mankin, Jon Peterson,
Brian Rosen, Dean Willis, Aki Niemi, Hisham Khartabil, Pekka Pessi, Brian Rosen, Dean Willis, Aki Niemi, Hisham Khartabil, Pekka Pessi,
Miguel Garcia, Peter Ridler, Sam Hartman, and Jean Mahoney. Miguel Garcia, Peter Ridler, Sam Hartman, and Jean Mahoney.
17. References 17. References
17.1. Normative References 17.1. Normative References
skipping to change at page 56, line 28 skipping to change at page 56, line 32
[15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", rfc 2046, Extensions (MIME) Part Two: Media Types", rfc 2046,
November 1996. November 1996.
[16] Peterson, J. and C. Jennings, "Enhancements for Authenticated [16] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)", Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-06 (work in progress), October 2005. draft-ietf-sip-identity-06 (work in progress), October 2005.
[17] Lennox, J., "Connection-Oriented Media Transport over the [17] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", draft-ietf-mmusic-comedia-tls-05 Description Protocol (SDP)", draft-ietf-mmusic-comedia-tls-06
(work in progress), September 2005. (work in progress), March 2006.
17.2. Informational References 17.2. Informational References
[18] Johnston, A. and O. Levin, "Session Initiation Protocol Call [18] Johnston, A. and O. Levin, "Session Initiation Protocol Call
Control - Conferencing for User Agents", Control - Conferencing for User Agents",
draft-ietf-sipping-cc-conferencing-07 (work in progress), draft-ietf-sipping-cc-conferencing-07 (work in progress),
June 2005. June 2005.
[19] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, [19] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
"Best Current Practices for Third Party Call Control in the "Best Current Practices for Third Party Call Control in the
Session Initiation Protocol", RFC 3725, April 2004. Session Initiation Protocol", RFC 3725, April 2004.
[20] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation [20] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation
Protocol Call Control - Transfer", Protocol Call Control - Transfer",
draft-ietf-sipping-cc-transfer-05 (work in progress), draft-ietf-sipping-cc-transfer-06 (work in progress),
July 2005. March 2006.
[21] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and [21] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002. Instant Messaging", RFC 3428, December 2002.
[22] Jennings, C., Mahy, R., and A. , "Relay Extensions for Message [22] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for
Sessions Relay Protocol (MSRP)", Message Sessions Relay Protocol (MSRP)",
draft-ietf-simple-msrp-relays-07 (work in progress), draft-ietf-simple-msrp-relays-07 (work in progress),
February 2006. February 2006.
[23] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE [23] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002. Method", RFC 3311, October 2002.
[24] Jennings, C. and J. Peterson, "Certificate Management Service [24] Jennings, C. and J. Peterson, "Certificate Management Service
for SIP", draft-ietf-sipping-certs-02 (work in progress), for SIP", draft-ietf-sipping-certs-03 (work in progress),
July 2005. March 2006.
[25] Yon, D. and G. Camarillo, "Connection-Oriented Media Transport [25] Yon, D. and G. Camarillo, "Connection-Oriented Media Transport
in SDP", rfc 4145, September 2005. in SDP", rfc 4145, September 2005.
[26] Peterson, J., "A Common Profile for Instant Messaging (CPIM)", [26] Peterson, J., "A Common Profile for Instant Messaging (CPIM)",
rfc 3860, August 2004. rfc 3860, August 2004.
[27] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, [27] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217,
December 2001. December 2001.
skipping to change at page 58, line 17 skipping to change at page 58, line 17
Ben Campbell (editor) Ben Campbell (editor)
Estacado Systems Estacado Systems
17210 Campbell Road 17210 Campbell Road
Suite 250 Suite 250
Dallas, TX 75252 Dallas, TX 75252
USA USA
Email: ben@estacado.net Email: ben@estacado.net
Rohan Mahy (editor) Rohan Mahy (editor)
SIP Edge, LLC Plantronics
345 Encincal Street
Santa Cruz, CA
USA
Email: rohan@ekabal.com Email: rohan@ekabal.com
Cullen Jennings (editor) Cullen Jennings (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Dr. 170 West Tasman Dr.
MS: SJC-21/2 MS: SJC-21/2
San Jose, CA 95134 San Jose, CA 95134
USA USA
 End of changes. 89 change blocks. 
227 lines changed or deleted 258 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/