draft-ietf-simple-message-sessions-16.txt   draft-ietf-simple-message-sessions-17.txt 
Network Working Group B. Campbell, Ed. Network Working Group B. Campbell, Ed.
Internet-Draft Estacado Systems Internet-Draft Estacado Systems
Intended status: Standards Track R. Mahy, Ed. Intended status: Standards Track R. Mahy, Ed.
Expires: April 25, 2007 Plantronics Expires: June 9, 2007 Plantronics
C. Jennings, Ed. C. Jennings, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
October 22, 2006 December 6, 2006
The Message Session Relay Protocol The Message Session Relay Protocol
draft-ietf-simple-message-sessions-16 draft-ietf-simple-message-sessions-17
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 April 25, 2007. This Internet-Draft will expire on June 9, 2007.
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 38 skipping to change at page 2, line 38
7.3.2. Receiving REPORT Requests . . . . . . . . . . . . . . 26 7.3.2. Receiving REPORT Requests . . . . . . . . . . . . . . 26
8. Using MSRP with SIP and SDP . . . . . . . . . . . . . . . . . 27 8. Using MSRP with SIP and SDP . . . . . . . . . . . . . . . . . 27
8.1. SDP Connection and Media Lines . . . . . . . . . . . . . 28 8.1. SDP Connection and Media Lines . . . . . . . . . . . . . 28
8.2. URI Negotiations . . . . . . . . . . . . . . . . . . . . 29 8.2. URI Negotiations . . . . . . . . . . . . . . . . . . . . 29
8.3. Path Attributes with Multiple URIs . . . . . . . . . . . 30 8.3. Path Attributes with Multiple URIs . . . . . . . . . . . 30
8.4. Updated SDP Offers . . . . . . . . . . . . . . . . . . . 30 8.4. Updated SDP Offers . . . . . . . . . . . . . . . . . . . 30
8.5. Connection Negotiation . . . . . . . . . . . . . . . . . 31 8.5. Connection Negotiation . . . . . . . . . . . . . . . . . 31
8.6. Content Type Negotiation . . . . . . . . . . . . . . . . 31 8.6. Content Type Negotiation . . . . . . . . . . . . . . . . 31
8.7. Example SDP Exchange . . . . . . . . . . . . . . . . . . 33 8.7. Example SDP Exchange . . . . . . . . . . . . . . . . . . 33
8.8. MSRP User Experience with SIP . . . . . . . . . . . . . . 34 8.8. MSRP User Experience with SIP . . . . . . . . . . . . . . 34
8.9. SDP direction attribute and MSRP . . . . . . . . . . . . 34 8.9. SDP direction attribute and MSRP . . . . . . . . . . . . 35
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 35 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 35
10. Response Code Descriptions . . . . . . . . . . . . . . . . . . 37 10. Response Code Descriptions . . . . . . . . . . . . . . . . . . 38
10.1. 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.1. 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.2. 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.2. 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.3. 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.3. 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.4. 408 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.4. 408 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.5. 413 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.5. 413 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.6. 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.6. 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.7. 423 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.7. 423 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.8. 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.8. 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.9. 501 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.9. 501 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.10. 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 10.10. 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Basic IM Session . . . . . . . . . . . . . . . . . . . . 39 11.1. Basic IM Session . . . . . . . . . . . . . . . . . . . . 39
11.2. Message with XHTML Content . . . . . . . . . . . . . . . 41 11.2. Message with XHTML Content . . . . . . . . . . . . . . . 42
11.3. Chunked Message . . . . . . . . . . . . . . . . . . . . . 42 11.3. Chunked Message . . . . . . . . . . . . . . . . . . . . . 42
11.4. Chunked Message with message/cpim payload . . . . . . . . 42 11.4. Chunked Message with message/cpim payload . . . . . . . . 42
11.5. System Message . . . . . . . . . . . . . . . . . . . . . 43 11.5. System Message . . . . . . . . . . . . . . . . . . . . . 43
11.6. Positive Report . . . . . . . . . . . . . . . . . . . . . 44 11.6. Positive Report . . . . . . . . . . . . . . . . . . . . . 44
11.7. Forked IM . . . . . . . . . . . . . . . . . . . . . . . . 44 11.7. Forked IM . . . . . . . . . . . . . . . . . . . . . . . . 44
12. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 47 12. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 47
13. CPIM Compatibility . . . . . . . . . . . . . . . . . . . . . . 47 13. CPIM Compatibility . . . . . . . . . . . . . . . . . . . . . . 47
14. Security Considerations . . . . . . . . . . . . . . . . . . . 48 14. Security Considerations . . . . . . . . . . . . . . . . . . . 48
14.1. Secrecy of the MSRP URI . . . . . . . . . . . . . . . . . 49 14.1. Secrecy of the MSRP URI . . . . . . . . . . . . . . . . . 49
14.2. Transport Level Protection . . . . . . . . . . . . . . . 49 14.2. Transport Level Protection . . . . . . . . . . . . . . . 49
skipping to change at page 21, line 26 skipping to change at page 21, line 26
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 a The default disposition of messages is to be rendered to the user.
different disposition, it MAY insert a Content-Disposition[9] header If the sender wants a different disposition, it MAY insert a Content-
field. Since MSRP can carry unencoded binary payloads, transfer Disposition[9] header field. Values MAY include any from RFC 2183
encoding is always "binary", and transfer-encoding parameters MUST [9] or the IANA registry it defines. Since MSRP can carry unencoded
NOT be present. binary payloads, transfer encoding is always "binary", and transfer-
encoding parameters MUST NOT be present.
7.1.2. Sending REPORT Requests 7.1.2. Sending REPORT Requests
REPORT requests are similar to SEND requests, except that report REPORT requests are similar to SEND requests, except that report
requests MUST NOT include 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
contain the Message-ID header field from the original SEND request. contain the Message-ID header field from the original SEND request.
If an MSRP element receives a REPORT for a Message-ID it does not If an MSRP element receives a REPORT for a Message-ID it does not
recognize, it SHOULD silently ignore the REPORT. recognize, it SHOULD silently ignore the REPORT.
skipping to change at page 33, line 12 skipping to change at page 33, line 12
appropriate mechanism of the rendezvous protocol. For example, in appropriate mechanism of the rendezvous protocol. For example, in
SIP, it SHOULD return a SIP 488 response. SIP, it SHOULD return a SIP 488 response.
An endpoint MAY indicate the maximum size message they wish to An endpoint MAY indicate the maximum size message they wish to
receive using the max-size a-line attribute. Max-size refers to the receive using the max-size a-line attribute. Max-size refers to the
complete message in octets, not the size of any one chunk. Senders complete message in octets, not the size of any one chunk. Senders
SHOULD NOT exceed the max-size limit for any message sent in the SHOULD NOT exceed the max-size limit for any message sent in the
resulting session. However, the receiver should consider max-size resulting session. However, the receiver should consider max-size
value as a hint. value as a hint.
Media format entries may include parameters. The interpretation of
such parameters varies between media-types. For the purposes of
media-type negotiation, a format-entry with one or more parameters is
assumed to match the same format-entry with no parameters.
The formal syntax for these attributes are as follows: The formal syntax for these attributes are as follows:
accept-types = accept-types-label ":" format-list accept-types = accept-types-label ":" format-list
accept-types-label = "accept-types" accept-types-label = "accept-types"
accept-wrapped-types = wrapped-types-label ":" format-list accept-wrapped-types = wrapped-types-label ":" format-list
wrapped-types-label = "accept-wrapped-types" wrapped-types-label = "accept-wrapped-types"
format-list = format-entry *( SP format-entry) format-list = format-entry *( SP format-entry)
format-entry = (type "/" subtype) / (type "/" "*") / ("*") format-entry = ( ( (type "/" subtype)
/ (type "/" "*") )
*( ";" type-param ) )
/ ("*")
type = token type = token
subtype = token subtype = token
type-param = parm-attribute "=" parm-value
attribute = token
value = token / quoted-string
max-size = max-size-label ":" max-size-value max-size = max-size-label ":" max-size-value
max-size-label = "max-size" max-size-label = "max-size"
max-size-value = 1*(DIGIT) ;max size in octets max-size-value = 1*(DIGIT) ;max size in octets
Figure 8: Attribute Syntax Figure 8: Attribute Syntax
8.7. Example SDP Exchange 8.7. Example SDP Exchange
Endpoint A wishes to invite Endpoint B to an MSRP session. A offers Endpoint A wishes to invite Endpoint B to an MSRP session. A offers
skipping to change at page 55, line 7 skipping to change at page 55, line 7
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. New parameters in this sub-registry must be under MSRP Parameters. New parameters in this sub-registry must be
published in an RFC (either as an IETF submission or RFC Editor published in an RFC (either as an IETF submission or RFC Editor
submission). Its initial population is defined as follows: submission). Its initial population is defined as follows:
To-Path - [RFCXXXX] To-Path - [RFCXXXX]
From-Path - [RFCXXXX] From-Path - [RFCXXXX]
Message-ID - [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 header field: order to register a new MSRP header field:
o The header field name. o The header field name.
o The RFC number in which the method is registered. o The RFC number in which the method is registered.
 End of changes. 13 change blocks. 
18 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/