draft-ietf-simple-imdn-06.txt   draft-ietf-simple-imdn-07.txt 
SIMPLE E. Burger SIMPLE E. Burger
Internet-Draft BEA Systems, Inc. Internet-Draft BEA Systems, Inc.
Intended status: Standards Track H. Khartabil Intended status: Standards Track H. Khartabil
Expires: July 17, 2008 January 14, 2008 Expires: October 4, 2008 April 2, 2008
Instant Message Disposition Notification Instant Message Disposition Notification
draft-ietf-simple-imdn-06 draft-ietf-simple-imdn-07
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 34 skipping to change at page 1, line 34
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 July 17, 2008. This Internet-Draft will expire on October 4, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
Instant Messaging (IM) refers to the transfer of messages between Instant Messaging (IM) refers to the transfer of messages between
users in real-time. This document provides a mechanism whereby users in real-time. This document provides a mechanism whereby
endpoints can request Instant Message Disposition Notifications endpoints can request Instant Message Disposition Notifications
(IMDN), including delivery, processing, and read notifications, for (IMDN), including delivery, processing, and read notifications, for
page-mode instant messages. page-mode instant messages.
The Common Profile for Instant Messaging (CPIM) data format specified The Common Profile for Instant Messaging (CPIM) data format specified
skipping to change at page 2, line 14 skipping to change at page 2, line 10
to request IMDNs. A new message format is also defined to convey to request IMDNs. A new message format is also defined to convey
IMDNs. IMDNs.
This document also describes how SIP entities behave using this This document also describes how SIP entities behave using this
extension. extension.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Disposition Types . . . . . . . . . . . . . . . . . . . . . . 6 5. Disposition Types . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Processing . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Processing . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Read . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Read . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. New CPIM Header Fields . . . . . . . . . . . . . . . . . . . . 7 6. New CPIM Header Fields . . . . . . . . . . . . . . . . . . . . 7
6.1. CPIM Header Field Namespace . . . . . . . . . . . . . . . 7 6.1. CPIM Header Field Namespace . . . . . . . . . . . . . . . 7
6.2. Disposition-Notification . . . . . . . . . . . . . . . . . 8 6.2. Disposition-Notification . . . . . . . . . . . . . . . . . 8
6.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . . . 8 6.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . . . 8
6.4. Original-To . . . . . . . . . . . . . . . . . . . . . . . 8 6.4. Original-To . . . . . . . . . . . . . . . . . . . . . . . 8
skipping to change at page 2, line 37 skipping to change at page 2, line 33
7. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . . . 9 7. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . . . 9
7.1. IM Sender . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. IM Sender . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1.1. Constructing Instant Messages . . . . . . . . . . . . 9 7.1.1. Constructing Instant Messages . . . . . . . . . . . . 9
7.1.2. Matching IMs with IMDNs . . . . . . . . . . . . . . . 10 7.1.2. Matching IMs with IMDNs . . . . . . . . . . . . . . . 10
7.1.3. Keeping State . . . . . . . . . . . . . . . . . . . . 11 7.1.3. Keeping State . . . . . . . . . . . . . . . . . . . . 11
7.1.4. Aggregation of IMDNs . . . . . . . . . . . . . . . . . 12 7.1.4. Aggregation of IMDNs . . . . . . . . . . . . . . . . . 12
7.2. IM Recipient . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. IM Recipient . . . . . . . . . . . . . . . . . . . . . . . 12
7.2.1. Constructing IMDNs . . . . . . . . . . . . . . . . . . 12 7.2.1. Constructing IMDNs . . . . . . . . . . . . . . . . . . 12
8. Intermediary Behaviour . . . . . . . . . . . . . . . . . . . . 15 8. Intermediary Behaviour . . . . . . . . . . . . . . . . . . . . 15
8.1. Constructing Processing Notifications . . . . . . . . . . 15 8.1. Constructing Processing Notifications . . . . . . . . . . 15
8.2. Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 16 8.2. Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 17
9. Identifying Messages . . . . . . . . . . . . . . . . . . . . . 18 9. Identifying Messages . . . . . . . . . . . . . . . . . . . . . 19
10. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 19 10. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 19
11. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Structure of XML-Encoded IMDN Payload . . . . . . . . . . 20 11.1. Structure of XML-Encoded IMDN Payload . . . . . . . . . . 20
11.1.1. The <message-id> Element . . . . . . . . . . . . . . . 20 11.1.1. The <message-id> Element . . . . . . . . . . . . . . . 21
11.1.2. The <datetime> Element . . . . . . . . . . . . . . . . 20 11.1.2. The <datetime> Element . . . . . . . . . . . . . . . . 21
11.1.3. The <recipient-uri> Element . . . . . . . . . . . . . 20 11.1.3. The <recipient-uri> Element . . . . . . . . . . . . . 21
11.1.4. The <original-recipient-uri> Element . . . . . . . . . 20 11.1.4. The <original-recipient-uri> Element . . . . . . . . . 21
11.1.5. The <subject> Element . . . . . . . . . . . . . . . . 21 11.1.5. The <subject> Element . . . . . . . . . . . . . . . . 21
11.1.6. The <disposition> Element . . . . . . . . . . . . . . 21 11.1.6. The <disposition> Element . . . . . . . . . . . . . . 21
11.1.7. The <status> Element . . . . . . . . . . . . . . . . . 21 11.1.7. The <status> Element . . . . . . . . . . . . . . . . . 21
11.1.8. The <note> Element . . . . . . . . . . . . . . . . . . 21 11.1.8. The <note> Element . . . . . . . . . . . . . . . . . . 22
11.2. MIME Type for IMDN Payload . . . . . . . . . . . . . . . . 21 11.2. MIME Type for IMDN Payload . . . . . . . . . . . . . . . . 22
11.3. The RelaxNG Schema . . . . . . . . . . . . . . . . . . . . 21 11.3. The RelaxNG Schema . . . . . . . . . . . . . . . . . . . . 22
12. Transporting Messages using SIP . . . . . . . . . . . . . . . 25 12. Transporting Messages using SIP . . . . . . . . . . . . . . . 26
12.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 25 12.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 26
12.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 25 12.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 26
12.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 26 12.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 26
12.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 26 12.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 26
12.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 27 12.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 27
13. Transporting Messages using MSRP . . . . . . . . . . . . . . . 28 13. Transporting Messages using MSRP . . . . . . . . . . . . . . . 28
14. Security Considerations . . . . . . . . . . . . . . . . . . . 28 14. Security Considerations . . . . . . . . . . . . . . . . . . . 29
14.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 30 14.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 31
14.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 31 14.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 31
14.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 31 14.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 32
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
15.1. message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 32 15.1. message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 32
15.2. URN Sub-Namespace Registration for 15.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:imdn . . . . . . . . . . . . . . . 33 urn:ietf:params:xml:ns:imdn . . . . . . . . . . . . . . . 33
15.3. Schema Registration . . . . . . . . . . . . . . . . . . . 33 15.3. Schema Registration . . . . . . . . . . . . . . . . . . . 33
15.4. Registration for urn:ietf:params:imdn . . . . . . . . . . 33 15.4. Registration for urn:ietf:params:imdn . . . . . . . . . . 34
15.5. Message/CPIM Header Field Registration . . . . . . . . . . 34 15.5. Message/CPIM Header Field Registration . . . . . . . . . . 34
15.6. Content-Disposition: notification . . . . . . . . . . . . 34 15.6. Content-Disposition: notification . . . . . . . . . . . . 34
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
17.1. Normative References . . . . . . . . . . . . . . . . . . . 34 17.1. Normative References . . . . . . . . . . . . . . . . . . . 35
17.2. Informative References . . . . . . . . . . . . . . . . . . 35 17.2. Informative References . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 37 Intellectual Property and Copyright Statements . . . . . . . . . . 37
1. Introduction 1. Introduction
In many user-to-user message exchange systems, message senders often In many user-to-user message exchange systems, message senders often
wish to know if the human recipient actually received or read a wish to know if the human recipient actually received or read a
message. message.
Electronic Mail [10] deals with this situation with Message Delivery Electronic Mail [RFC2821] deals with this situation with Message
Notifications [11]. After the recipient views the message, her mail Delivery Notifications [RFC3798]. After the recipient views the
user agent generates a Message Delivery Notification, or MDN. The message, her mail user agent generates a Message Delivery
MDN is an e-mail that follows the format prescribed by RFC 3798 [11]. Notification, or MDN. The MDN is an e-mail that follows the format
The fixed format ensures that an automaton can process the message. prescribed by RFC 3798 [RFC3798]. The fixed format ensures that an
automaton can process the message.
Message/CPIM [2] is a message format used to generate instant The common presence and instant messaging (CPIM) format, Message/CPIM
messages. SIP [8] can carry instant messages generated using [RFC3862], is a message format used to generate instant messages.
message/CPIM in SIP MESSAGE requests [9]. The session initiation protocol, SIP [RFC3261], can carry instant
messages generated using message/CPIM in SIP MESSAGE requests
[RFC3428].
This document extends Message/CPIM message format, much like Message This document extends the Message/CPIM message format in much the
Delivery Notifications extends Electronic Mail. This extension same way Message Delivery Notifications extends Electronic Mail.
enables Instant Message Senders to request, create, and send Instant This extension enables Instant Message Senders to request, create,
Message Disposition Notifications (IMDN). This mechanism works for and send Instant Message Disposition Notifications (IMDN). This
page-mode as well as session mode instant messages. This document mechanism works for page-mode as well as session mode instant
only discusses page-mode. Session mode is left for future messages. This document only discusses page-mode. Session mode is
standardisation efforts. left for future standardisation efforts.
IMDNs include positive delivery, negative delivery (i.e. a message IMDNs include positive delivery, negative delivery (i.e., a message
did not get delivered successfully), read notifications as well as did not get delivered successfully), read notifications (i.e., a
processed notifications. By using CPIM header fields, the IMDN message was rendered) as well as processed notifications. By using
request and delivery are abstracted outside the transport protocol CPIM header fields, the IMDN request and delivery are abstracted
allowing interoperability between different IM systems. outside the transport protocol allowing interoperability between
different IM systems.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document refers generically to the sender of a message in the This document refers generically to the sender of a message in the
masculine (he/him/his) and the recipient of the message in the masculine (he/him/his) and the recipient of the message in the
feminine (she/her/hers). This convention is purely for convenience feminine (she/her/hers). This convention is purely for convenience
and makes no assumption about the gender of a message sender or and makes no assumption about the gender of a message sender or
recipient. recipient.
3. Terminology 3. Terminology
o IM: An Instant Message generated using the Message/CPIM format. o IM: An Instant Message generated using the Message/CPIM format.
o IMDN: An Instant Message Disposition Notification generated using o IMDN: An Instant Message Disposition Notification generated using
the Message/CPIM format that carries an IMDN XML document. the Message/CPIM format that carries an IMDN XML document.
o Message: an IM or an IMDN generated using the Message/CPIM format. o Message: an IM or an IMDN generated using the Message/CPIM format.
o IM Sender: An endpoint (User Agent) generating and sending an IM. o IM Sender: An endpoint (User Agent) generating and sending an IM.
Also, the endpoint request IMDNs for an IM. Quite often, the IM Also, the endpoint request IMDNs for an IM. Quite often, the IM
Sender is the IMDN Recipient. However, that is not always the Sender is the IMDN Recipient. However, that is not always the
case, since the IMDN uses the From header in the CPIM message. case, since the IMDN uses the From header in the CPIM message.
That value is often the IM Sender's Address of Record (AoR). This That value is often the IM Sender's Address of Record (AOR). This
address may in fact resolve to different User Agents. address may in fact resolve to different User Agents.
o IM Recipient: An endpoint (User Agent) that receives IMs. The IM o IM Recipient: An endpoint (User Agent) that receives IMs. The IM
Recipient, as the node that presumably renders the IM to the user, Recipient, as the node that presumably renders the IM to the user,
generates and sends delivery IMDNs to IMs, if requested by the IM generates and sends delivery IMDNs to IMs, if requested by the IM
Sender and allowed by the IM Recipient. Sender and allowed by the IM Recipient.
o Endpoint: An IM Sender or an IM Recipient. o Endpoint: An IM Sender or an IM Recipient.
o Intermediary: An entity in the network that is on the path of an o Intermediary: An entity in the network, most often an application
IM to its final destination. Intermediaries also can generate and server, including URI-List servers and Store-and-Forward servers,
send processing IMDNs to IMs, if requested by the IM Sender and that forwards an IM to its final destination. Intermediaries also
allowed by policy. can generate and send processing IMDNs to IMs, if requested by the
IM Sender and allowed by policy.
o Gateway: An intermediary that translates between different IM
systems that use different protocols.
o IMDN Payload: An XML document carrying the disposition o IMDN Payload: An XML document carrying the disposition
notification information. In this specification, it is of MIME notification information. In this specification, it is of MIME
type "message/imdn+xml". type "message/imdn+xml".
o Disposition type: the type of IMDN that can be requested. This o Disposition type: the type of IMDN that can be requested. This
specification defines three, namely "delivery", "processing" and specification defines three, namely "delivery", "processing" and
"read" disposition types. "read" disposition types.
o Transport Protocol Message: A SIP or other protocol message that o Transport Protocol Message: A SIP or other protocol message that
contains an IM or IMDN. contains an IM or IMDN.
4. Overview 4. Overview
skipping to change at page 6, line 20 skipping to change at page 6, line 20
| | | |
| 1. IM requesting IMDN | | 1. IM requesting IMDN |
|-------------------------------------->| |-------------------------------------->|
| | | |
| | | |
| 2. IMDN (disposition) | | 2. IMDN (disposition) |
|<--------------------------------------| |<--------------------------------------|
| | | |
| | | |
Basic IMDN Message Flow
Note that the recipient of an IMDN, in some instances, may not be the Note that the recipient of an IMDN, in some instances, may not be the
IM Sender. This is specifically true for page-mode IMs where the IM Sender. This is specifically true for page-mode IMs where the
Address of Record (AOR) of the IM Sender, that is present in the IM, Address of Record (AOR) of the IM Sender, that is present in the IM,
resolves to a different location or user agent than the IM resolves to a different location or user agent than the IM
originated. For simplicity, the rest of this document assumes that originated. This could happen, for example, if resolving the AOR
the IM Sender and the IMDN Recipient are the same and therefore will results in forking the request to multiple user agents. For
refer to both as the IM Sender. simplicity, the rest of this document assumes that the IM Sender and
the IMDN Recipient are the same and therefore will refer to both as
the IM Sender.
5. Disposition Types 5. Disposition Types
There are three broad categories of disposition states. They are There are three broad categories of disposition states. They are
delivery, processing, and read. Future extensions may introduce delivery, processing, and read.
others.
5.1. Delivery 5.1. Delivery
The delivery notification type indicates whether the IM has been The delivery notification type indicates whether the IM has been
delivered to the IM Recipient or not. The delivery notification type delivered to the IM Recipient or not. The delivery notification type
can have the following states: can have the following states:
o "delivered" to indicate successful delivery. o "delivered" to indicate successful delivery.
o "failed" to indicate failure in delivery. o "failed" to indicate failure in delivery.
o "forbidden" indicate denial for the IM Sender to receive the o "forbidden" indicate denial for the IM Sender to receive the
requested IMDN. The IM Recipient can send the "forbidden" state, requested IMDN. The IM Recipient can send the "forbidden" state,
skipping to change at page 7, line 36 skipping to change at page 7, line 38
user. user.
o "forbidden" indicate denial, by the IM Recipient, for the IM o "forbidden" indicate denial, by the IM Recipient, for the IM
Sender to receive the requested IMDN. Sender to receive the requested IMDN.
o "error" to indicate an error in determining the fate of an IM. o "error" to indicate an error in determining the fate of an IM.
In addition to text, some IMs may contain audio, video, and still In addition to text, some IMs may contain audio, video, and still
images. Therefore, the state "read" includes playing the audio or images. Therefore, the state "read" includes playing the audio or
video file to the user. video file to the user.
Since there is no positive acknowledgement from the user, one cannot Since there is no positive acknowledgement from the user, one cannot
determine a priori the user actually read the IM. Thus, one cannot determine _a priori_ the user actually read the IM. Thus, one cannot
use the protocol described here as a non-repudiation service. use the protocol described here as a non-repudiation service.
6. New CPIM Header Fields 6. New CPIM Header Fields
This specification extends the CPIM data format specified in RFC 3862 This specification extends the CPIM data format specified in RFC 3862
[2]. A new namespace is created as well as a number of new CPIM [RFC3862]. A new name space is created as well as a number of new
header fields. CPIM header fields.
6.1. CPIM Header Field Namespace 6.1. CPIM Header Field Namespace
Per CPIM [2], this specification defines a new namespace for the CPIM Per CPIM [RFC3862], this specification defines a new name space for
extension header fields defined in the following sections. The the CPIM extension header fields defined in the following sections.
namespace is: The name space is:
urn:ietf:params:imdn urn:ietf:params:imdn
As per CPIM [2] requirements, the new header fields defined in the
following sections are prepended, in CPIM messages, by a prefix As per CPIM [RFC3862] requirements, the new header fields defined in
the following sections are prepended, in CPIM messages, by a prefix
assigned to the URN through the NS header field of the CPIM message. assigned to the URN through the NS header field of the CPIM message.
The remaining of this specification always assumes an NS header field The remaining of this specification always assumes an NS header field
like this one: like this one:
NS: imdn <urn:ietf:params:imdn>. NS: imdn <urn:ietf:params:imdn>.
Of course, clients are free to use any prefix and servers must accept Of course, clients are free to use any prefix while servers and
any legal namespace prefix specification. intermediaries must accept any legal name space prefix specification.
6.2. Disposition-Notification 6.2. Disposition-Notification
The IM Sender MUST include the Disposition-Notification header field The IM Sender MUST include the Disposition-Notification header field
to indicate the desire to receive IMDNs from the IM Recipient, for to indicate the desire to receive IMDNs from the IM Recipient, for
that specific IM. This header field is not needed if the IM Sender that specific IM. Section 10 defines the syntax.
does not request an IMDN. Section 10 defines the syntax.
6.3. Message-ID 6.3. Message-ID
The IM Sender MUST include the Message-ID header field in the IM that The IM Sender MUST include the Message-ID header field in the IM that
he wishes to receive an IMDN on. The Message-ID contains a globally he wishes to receive an IMDN on. The Message-ID contains a globally
unique message identifier the IM Sender can use to correlate received unique message identifier the IM Sender can use to correlate received
IMDNs. When the IM Sender receives an IMDN, it can compare its value IMDNs. When the IM Sender receives an IMDN, it can compare its value
with the value of the <message-id> element present in the IMDN with the value of the <message-id> element present in the IMDN
payload. IMDNs also carry this header field. Note that since the payload. IMDNs also carry this header field. Note that since the
IMDN is itself an IM, the Message-ID of the IMDN will be different IMDN is itself an IM, the Message-ID of the IMDN will be different
skipping to change at page 9, line 22 skipping to change at page 9, line 23
headers into corresponding IMDN-Route header fields. Section 10 headers into corresponding IMDN-Route header fields. Section 10
defines the syntax. defines the syntax.
7. Endpoint Behaviour 7. Endpoint Behaviour
7.1. IM Sender 7.1. IM Sender
7.1.1. Constructing Instant Messages 7.1.1. Constructing Instant Messages
An IM is constructed using CPIM Message Format defined in RFC 3862 An IM is constructed using CPIM Message Format defined in RFC 3862
[2]. [RFC3862].
7.1.1.1. Adding a Message-ID Header Field 7.1.1.1. Adding a Message-ID Header Field
If the IM sender requests the reception of IMDNs, the IM sender MUST If the IM sender requests the reception of IMDNs, the IM sender MUST
include a Message-ID header field. The Message-ID field is populated include a Message-ID header field. The Message-ID field is populated
with a value that is unique with at least 32 bits of randomness. with a value that is unique with at least 32 bits of randomness.
This header field enables the IM Sender to match any IMDNs with their This header field enables the IM Sender to match any IMDNs with their
corresponding IMs. corresponding IMs.
7.1.1.2. Adding a DateTime Header Field 7.1.1.2. Adding a DateTime Header Field
skipping to change at page 12, line 9 skipping to change at page 12, line 11
choose to purge the state associated with the sent IM. This is the choose to purge the state associated with the sent IM. This is the
reason for adding the time stamp in the IM and having it returned in reason for adding the time stamp in the IM and having it returned in
the IMDN. This gives the user some opportunity of remembering what the IMDN. This gives the user some opportunity of remembering what
IM was sent. For example if the IMDN indicates that the IM the user IM was sent. For example if the IMDN indicates that the IM the user
sent at 2 p.m. last Thursday was delivered, the user has a chance of sent at 2 p.m. last Thursday was delivered, the user has a chance of
remembering that they sent an IM at 2 p.m. last Thursday. remembering that they sent an IM at 2 p.m. last Thursday.
7.1.4. Aggregation of IMDNs 7.1.4. Aggregation of IMDNs
An IM Sender may send an IM to multiple recipients in one Transport An IM Sender may send an IM to multiple recipients in one Transport
Protocol Message (typically using a URI-List server) and request Protocol Message (typically using a URI-List server
IMDNs. An IM Sender that requested IMDNs MUST be prepared to receive [I-D.ietf-sip-uri-list-message]) and request IMDNs. An IM Sender
multiple aggregated or non-aggregated IMDNs. See Section 8.2 for that requested IMDNs MUST be prepared to receive multiple aggregated
details. or non-aggregated IMDNs. See Section 8.2 for details.
7.2. IM Recipient 7.2. IM Recipient
7.2.1. Constructing IMDNs 7.2.1. Constructing IMDNs
IM recipients examine the contents of the Disposition-Notification IM recipients examine the contents of the Disposition-Notification
header field of the CPIM message to determine if an IMDN must be header field of the CPIM message to determine if the recipient needs
generated for that IM. Disposition-Notification header fields of to generate an IMDN for that IM. Disposition-Notification header
CPIM messages can include one or more values. This implies that IM fields of CPIM messages can include one or more values. IM
recipients may need to generate zero, one, or more IMDNs for that IM, recipients may need to generate zero, one, or more IMDNs for that IM,
for example a delivery notification as well as a read notification. for example a delivery notification as well as a read notification.
In this case, the IM Recipient MUST be able to construct multiple In this case, the IM Recipient MUST be able to construct multiple
IMDNs per IM. An IM Recipient MUST NOT construct more than one IMDN IMDNs per IM. An IM Recipient MUST NOT construct more than one IMDN
per disposition type. That is, it must not generate a delivery per disposition type. That is, it must not generate a delivery
notification indicating "delivered" then followed by a delivery notification indicating "delivered" then followed by a delivery
notification indicating "failed" for the same IM. If the IM Sender notification indicating "failed" for the same IM. If the IM Sender
requested only failure notifications and the IM was successfully requested only failure notifications and the IM was successfully
delivered, then no IMDNs will be generated. delivered, then no IMDNs will be generated. If the IM recipient does
not understand a value of the Disposition-Notification header field,
the IM recipient ignores that value.
The IM Recipient MUST NOT generate "processing" notifications. The IM Recipient MUST NOT generate "processing" notifications.
A Disposition-Notification header field MUST NOT appear in an IMDN A Disposition-Notification header field MUST NOT appear in an IMDN
since it is forbidden to request an IMDN for an IMDN. An IM Sender since it is forbidden to request an IMDN for an IMDN. An IM Sender
MUST ignore a delivery notification request in an IMDN if present. MUST ignore a delivery notification request in an IMDN if present.
The IM Sender MUST NOT send an IMDN for an IMDN. The IM Sender MUST NOT send an IMDN for an IMDN.
An IMDN MUST contain a Message-ID header field. The same rules of An IMDN MUST contain a Message-ID header field. The same rules of
uniqueness for the Message-ID header field that appears in an IM uniqueness for the Message-ID header field that appears in an IM
skipping to change at page 13, line 5 skipping to change at page 13, line 9
An IM may contain an IMDN-Record-Route header field (see Section 8 An IM may contain an IMDN-Record-Route header field (see Section 8
for details). If IMDN-Record-Route header fields appear in the IM, for details). If IMDN-Record-Route header fields appear in the IM,
the IM Recipient constructing the IMDN MUST copy the contents of the the IM Recipient constructing the IMDN MUST copy the contents of the
IMDN-Record-Route header fields into IMDN-Route header fields in the IMDN-Record-Route header fields into IMDN-Route header fields in the
IMDN and maintain the order. The IMDN is then sent to the URI in the IMDN and maintain the order. The IMDN is then sent to the URI in the
top IMDN-Route header field. IMDN-Record-Route header fields do not top IMDN-Route header field. IMDN-Record-Route header fields do not
make sense in an IMDN and therefore MUST NOT be placed in an IMDN. make sense in an IMDN and therefore MUST NOT be placed in an IMDN.
IMDN Recipients MUST ignore it if present. IMDN Recipients MUST ignore it if present.
As stated in CPIM [2], CPIM messages may need to support MIME headers As stated in CPIM [RFC3862], CPIM messages may need to support MIME
other than Content-type. IM Recipients MUST insert a Content- headers other than Content-type. IM Recipients MUST insert a
Disposition header field, set to the value "notification". This Content-Disposition header field, set to the value "notification".
indicates to the IM Sender that the message is an IMDN to an IM it This indicates to the IM Sender that the message is an IMDN to an IM
has earlier sent. it has earlier sent.
7.2.1.1. Constructing Delivery Notifications 7.2.1.1. Constructing Delivery Notifications
The IM Recipient constructs a delivery notification in a similar The IM Recipient constructs a delivery notification in a similar
fashion as an IM, using a CPIM body [2] that carries a Disposition fashion as an IM, using a CPIM body [RFC3862] that carries a
Notification XML document formatted according to the rules specified Disposition Notification XML document formatted according to the
in Section 11. The MIME type of the Disposition Notification XML rules specified in Section 11. The MIME type of the Disposition
document is "message/imdn+xml". Notification XML document is "message/imdn+xml".
Section 10 defines the schema for an IMDN. Section 10 defines the schema for an IMDN.
An example CPIM body of IMDN looks like the following: An example CPIM body of IMDN looks like the following:
From: Bob <im:bob@example.com> From: Bob <im:bob@example.com>
To: Alice <im:alice@example.com> To: Alice <im:alice@example.com>
NS: imdn <urn:ietf:params:imdn> NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: d834jied93rf imdn.Message-ID: d834jied93rf
Content-type: message/imdn+xml Content-type: message/imdn+xml
skipping to change at page 15, line 14 skipping to change at page 15, line 14
8. Intermediary Behaviour 8. Intermediary Behaviour
In this context, intermediaries are application servers (including In this context, intermediaries are application servers (including
URI-List servers and Store-and-Forward server) and gateways. A URI-List servers and Store-and-Forward server) and gateways. A
gateway is a server that translates between different IM systems that gateway is a server that translates between different IM systems that
use different protocols. use different protocols.
A URI-List server may change the IM Recipient address from its own to A URI-List server may change the IM Recipient address from its own to
the address of the final recipient of that IM for every copy it makes the address of the final recipient of that IM for every copy it makes
that it sends to the list members (see [13] for details). In this that it sends to the list members (see
case, if the IM Sender is requesting an IMDN, the intermediary SHOULD [I-D.ietf-sip-uri-list-message] for details). In this case, if the
add an Original-To header field to the IM populating it with the IM Sender is requesting an IMDN, the intermediary SHOULD add an
address that was in the CPIM To header field before it was changed. Original-To header field to the IM populating it with the address
I.e., the Original-To header field is populated with the intermediary that was in the CPIM To header field before it was changed. That is,
address. An intermediary MUST NOT add an Original-To header field if the intermediary populates the Original-To header field with the
one already exists. An intermediary MAY have an administrative intermediary address. Of course, one may configure an intermediary
to restrict it from re-writing or populating the Original-To field.
An intermediary MUST NOT add an Original-To header field if one
already exists. An intermediary MAY have an administrative
configuration to not reveal the original Request-URI, and as such, configuration to not reveal the original Request-URI, and as such,
MAY chose not to add an Original-To header. MUST NOT add an Original-To header.
An intermediary MAY choose to remain on the path of IMDNs for a An intermediary MAY choose to remain on the path of IMDNs for a
specific IM. It can do so by adding a CPIM IMDN-Record-Route header specific IM. It can do so by adding a CPIM IMDN-Record-Route header
field as the top IMDN-Record-Route header field and populating it field as the top IMDN-Record-Route header field and populating it
with its own address. An intermediary that does not support this with its own address. An intermediary that does not support this
extension will obviously not add the IMDN-Record-Route header field. extension will obviously not add the IMDN-Record-Route header field.
This allows IMDNs to traverse directly from the IM Recipient to the This allows IMDNs to traverse directly from the IM Recipient to the
IM Sender even if the IM traversed an intermediary not supporting IM Sender even if the IM traversed an intermediary not supporting
this extension. this extension.
An intermediary receiving an IMDN checks the top IMDN-Route header An intermediary receiving an IMDN checks the top IMDN-Route header
field. If that header field carries the intermediary address, the field. If that header field carries the intermediary address, the
intermediary removes that value and forwards the IMDN to the address intermediary removes that value and forwards the IMDN to the address
indicated in the now top IMDN-Route header field. If no IMDN-Route indicated in the now top IMDN-Route header field. If no additional
header fields are present, the IMDN is forwarded to the address in IMDN-Route header fields are present, the IMDN is forwarded to the
the CPIM To header field. address in the CPIM To header field.
An intermediary MUST remove any information about the final An intermediary MUST remove any information about the final
recipients of a list if the list membership is not disclosed. The recipients of a list if the list membership is not disclosed. The
intermediary does that by removing the <recipient-uri> element and/or intermediary does that by removing the <recipient-uri> element and/or
<original-recipient-uri> element from the body of the IMDN before <original-recipient-uri> element from the body of the IMDN before
forwarding it to the IM Sender. forwarding it to the IM Sender.
8.1. Constructing Processing Notifications 8.1. Constructing Processing Notifications
Intermediaries are the only entities that construct processing Intermediaries are the only entities that construct processing
skipping to change at page 16, line 48 skipping to change at page 17, line 7
</status> </status>
<note lang="en">The IM has been processed</note> <note lang="en">The IM has been processed</note>
</imdn> </imdn>
There are situations where the intermediary cannot know the fate of There are situations where the intermediary cannot know the fate of
an IM. The intermediary in this case generates a processing an IM. The intermediary in this case generates a processing
notification with a <status> value of "error" to indicate so. notification with a <status> value of "error" to indicate so.
8.2. Aggregation of IMDNs 8.2. Aggregation of IMDNs
In this context, URI-List servers are defined as intermediaries. As previously described, URI-List servers are intermediaries.
An intermediary may choose to aggregate IMDNs using local policy for A URI-List server may choose to aggregate IMDNs using local policy
making such a decision or it may send individual IMDNs instead. When for making such a decision or it may send individual IMDNs instead.
a URI-List server receives an IM and decides to aggregate IMDNs, it When a URI-List server receives an IM and decides to aggregate IMDNs,
can wait for a configurable period of time or until all recipients it can wait for a configurable period of time or until all recipients
have sent the IMDN, whichever comes first, before the URI-List server have sent the IMDN, whichever comes first, before the URI-List server
sends an aggregated IMDN. Note that some IMDNs, for example "read" sends an aggregated IMDN. Note that some IMDNs, for example "read"
notifications, may never come due to user settings. It is an notifications, may never come due to user settings. It is an
administrator configuration and an implementation issue how long to administrator configuration and an implementation issue how long to
wait before sending an aggregated IMDN and before a URI-List server wait before sending an aggregated IMDN and before a URI-List server
removes state for that IM. removes state for that IM.
A URI-List server MAY choose to send multiple aggregated IMDNs. A A URI-List server MAY choose to send multiple aggregated IMDNs. A
timer can be started and when it fires, the URI-List server can timer can be started and when it fires, the URI-List server can
aggregate whatever IMDNs it has so far for that IM, send the aggregate whatever IMDNs it has so far for that IM, send the
skipping to change at page 18, line 47 skipping to change at page 19, line 7
<status> <status>
<read/> <read/>
</status> </status>
<note lang="en">The IM was successfully Delivered</note> <note lang="en">The IM was successfully Delivered</note>
</imdn> </imdn>
--imdn-boundary --imdn-boundary
9. Identifying Messages 9. Identifying Messages
Messages are typically carried in a transport protocol like SIP [8]. Messages are typically carried in a transport protocol like SIP
If the payload carried by the transport protocol does not contain any [RFC3261]. If the payload carried by the transport protocol does not
parts of type Message/CPIM then the message is an IM. If the payload contain any parts of type Message/CPIM then the message is an IM. If
contains any parts of type Message/CPIM, and none of those parts the payload contains any parts of type Message/CPIM, and none of
contains a payload that is of type "message/imdn+xml", the message is those parts contains a payload that is of type "message/imdn+xml",
an IM. It is not valid to attempt to carry both an IM and an IMDN in the message is an IM. It is not valid to attempt to carry both an IM
a multipart payload in a single transport protocol message. and an IMDN in a multipart payload in a single transport protocol
message.
A message is identified as a delivery notification by examining its A message is identified as a delivery notification by examining its
contents. The message is a delivery notification if the Content-type contents. The message is a delivery notification if the Content-type
header field present has a value of "message/imdn+xml", the Content- header field present has a value of "message/imdn+xml", the Content-
Disposition header field has a value of "notification", and the Disposition header field has a value of "notification", and the
<disposition> element in that xml body has a sub-element <delivery>. <disposition> element in that xml body has a sub-element <delivery>.
A message is identified as a processing notification or read A message is identified as a processing notification or read
notification in a similar fashion as a delivery notification. The notification in a similar fashion as a delivery notification. The
difference is that the <disposition> element in that xml body has a difference is that the <disposition> element in that xml body has a
sub-element of <processing> and <read> respectively. sub-element of <processing> and <read> respectively.
10. Header Fields Formal Syntax 10. Header Fields Formal Syntax
The following syntax specification uses the message header field The following syntax specification uses the message header field
syntax as described in Section 3 of RFC 3862 [2]. syntax as described in Section 3 of RFC 3862 [RFC3862].
Header field syntax is described without a namespace qualification. Header field syntax is described without a namespace qualification.
Following the rules in RFC 3862 [2], header field names and other Following the rules in RFC 3862 [RFC3862], header field names and
text are case sensitive and MUST be used as given, using exactly the other text are case sensitive and MUST be used as given, using
indicated upper case and lower case letters. exactly the indicated upper case and lower case letters.
Disposition-Notification = Disposition-Notification =
"Disposition-Notification" ": " "Disposition-Notification" ": "
[(notify-req *(COMMA notify-req))] [(notify-req *(COMMA notify-req))]
notify-req = notify-req =
("negative-delivery" / "positive-delivery" / ("negative-delivery" / "positive-delivery" /
"processing" / "read" / Token) *(SEMI disp-notif-params) "processing" / "read" / Token) *(SEMI disp-notif-params)
disp-notify-params = generic-param disp-notify-params = generic-param
skipping to change at page 20, line 9 skipping to change at page 20, line 28
IMDN-Record-Route = IMDN-Record-Route =
"IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">" "IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">"
IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">" IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">"
11. IMDN Format 11. IMDN Format
11.1. Structure of XML-Encoded IMDN Payload 11.1. Structure of XML-Encoded IMDN Payload
An IMDN Payload is an XML document [6] that MUST be well formed and An IMDN Payload is an XML document [XML] that MUST be well formed and
MUST be valid according to schemas, including extension schemas, MUST be valid according to schemas, including extension schemas,
available to the validater and applicable to the XML document. The available to the validater and applicable to the XML document. The
IMDN Payload MUST be based on XML 1.0 and MUST be encoded using IMDN Payload MUST be based on XML 1.0 and MUST be encoded using
UTF-8. UTF-8.
The namespace identifier for elements defined by this specification The namespace identifier for elements defined by this specification
is a URN [4], using the namespace identifier 'ietf' defined by [12] is a URN [URN], using the name space identifier 'ietf' defined by
and extended by [3]. This urn is: urn:ietf:params:xml:ns:imdn. [URN_NS] and extended by [IANA]. This urn is:
urn:ietf:params:xml:ns:imdn.
This namespace declaration indicates the namespace on which the IMDN This name space declaration indicates the name space on which the
is based. IMDN is based.
The root element is <imdn>. The <imdn> element has sub-elements, The root element is <imdn>. The <imdn> element has sub-elements,
namely <message-id>, <datetime>, <recipient-uri>, <original- namely <message-id>, <datetime>, <recipient-uri>, <original-
recipient-uri>, <subject>, <disposition>, <status>, and <note>. recipient-uri>, <subject>, <disposition>, <status>, and <note>.
Those elements are described in details in the following sections. Those elements are described in details in the following sections.
<disposition> and <status> can be extended in the future to include <disposition> and <status> can be extended in the future to include
new sub-elements not defined in this document. Those new elements new sub-elements not defined in this document, as described in
MUST be defined in an RFC. Section 15.3.
11.1.1. The <message-id> Element 11.1.1. The <message-id> Element
The <message-id> element is mandatory according to the XML schema and The <message-id> element is mandatory according to the XML schema and
carries the message id that appeared in the Message-ID header field carries the message id that appeared in the Message-ID header field
of the IM. of the IM.
11.1.2. The <datetime> Element 11.1.2. The <datetime> Element
The <datetime> element is mandatory and carries the date and time the The <datetime> element is mandatory and carries the date and time the
skipping to change at page 25, line 33 skipping to change at page 26, line 11
</define> </define>
</grammar> </grammar>
12. Transporting Messages using SIP 12. Transporting Messages using SIP
12.1. Endpoint Behaviour 12.1. Endpoint Behaviour
12.1.1. Sending Requests 12.1.1. Sending Requests
The IM Sender constructs a SIP MESSAGE request using RFC 3428 [9]. The IM Sender constructs a SIP MESSAGE request using RFC 3428
The Content-type header field indicates the MIME type of the request [RFC3428]. The Content-type header field indicates the MIME type of
payload. When using this extension, the Content-type header field the request payload. When using this extension, the Content-type
MUST be of MIME type "message/cpim" [2] for both IMs and IMDNs. The header field MUST be of MIME type "message/cpim" [RFC3862] for both
IM Sender constructs the payload according to Section 7. IMs and IMDNs. The IM Sender constructs the payload according to
Section 7.
The IM Sender constructs a SIP MESSAGE request to multiple recipients The IM Sender constructs a SIP MESSAGE request to multiple recipients
in a similar manner as a SIP MESSAGE request to a single recipient. in a similar manner as a SIP MESSAGE request to a single recipient.
Multiple-Recipient MESSAGE Requests in SIP [13] describes the Multiple-Recipient MESSAGE Requests in SIP
differences. [I-D.ietf-sip-uri-list-message] describes the differences.
IM senders can remain anonymous. For example, the sender can set the IM senders can remain anonymous. For example, the sender can set the
SIP From header field of the SIP message to an anonymous URI. As SIP From header field of the SIP message to an anonymous URI. As
there is no return address, anonymous IM senders SHOULD NOT request there is no return address, anonymous IM senders SHOULD NOT request
disposition notifications. An IM Recipient can ignore such request disposition notifications. An IM Recipient can ignore such request
if the IM Sender is anonymous. if the IM Sender is anonymous.
12.1.2. Sending Responses 12.1.2. Sending Responses
An endpoint receiving a SIP MESSAGE request constructs a SIP response An endpoint receiving a SIP MESSAGE request constructs a SIP response
according to RFC 3428 [9]. Of course, an endpoint will send a according to RFC 3428 [RFC3428]. Of course, an endpoint will send a
response to the MESSAGE request regardless of the type of message (IM SIP response to the MESSAGE request regardless of the type of message
or IMDN) is has received, or the disposition type it has been asked (IM or IMDN) is has received, or the disposition type it has been
for. asked for.
12.1.3. Receiving Requests 12.1.3. Receiving Requests
12.1.3.1. Instant Message 12.1.3.1. Instant Message
A SIP MESSAGE request is identified as an IM by examining its A SIP MESSAGE request is identified as an IM by examining its
contents according to Section 9. contents according to Section 9.
If an IM Recipient received a SIP MESSAGE request that is an IM that If an IM Recipient received a SIP MESSAGE request that is an IM that
requested a positive-delivery notification, and that IM Recipient has requested a positive-delivery notification, and that IM Recipient has
skipping to change at page 27, line 24 skipping to change at page 27, line 48
examining its contents according to Section 9. examining its contents according to Section 9.
12.1.3.3. Read Notification 12.1.3.3. Read Notification
A SIP MESSAGE request is identified as read notification by examining A SIP MESSAGE request is identified as read notification by examining
its contents according to Section 9. its contents according to Section 9.
12.2. Intermediary Behaviour 12.2. Intermediary Behaviour
In this context, intermediaries include application servers, In this context, intermediaries include application servers,
including URI-List servers, store-and-forward servers, and gateways. including URI-List servers, Store-and-Forward servers, and gateways.
SIP Proxies MUST NOT generate IMDNs but MUST forward them like any SIP Proxies MUST NOT generate IMDNs but MUST forward them like any
other SIP request. other SIP request.
Intermediaries forward a SIP MESSAGE request to multiple recipients Intermediaries forward a SIP MESSAGE request to multiple recipients
according to [13]. according to [I-D.ietf-sip-uri-list-message].
If an intermediary receives an IM, the intermediary examines the If an intermediary receives an IM, the intermediary examines the
body. If the body is of type "message/cpim" the intermediary then body. If the body is of type "message/cpim" the intermediary then
looks for a Disposition-Notification CPIM header field in the looks for a Disposition-Notification CPIM header field in the
message. If the Disposition-Notification CPIM header field has message. If the Disposition-Notification CPIM header field has
either the value "positive-delivery" or "negative-delivery", and, in either the value "positive-delivery" or "negative-delivery", and, in
processing the IM, the intermediary generates a SIP 2xx class processing the IM, the intermediary generates a SIP 2xx class
response to the MESSAGE request, then the intermediary performs the response to the MESSAGE request, then the intermediary performs the
following actions. following actions.
If the Disposition-Notification header field contains a value of If the Disposition-Notification header field contains a value of
"positive-delivery", the intermediary MUST NOT generate a delivery "positive-delivery", the intermediary MUST NOT generate a delivery
notification if it receives a SIP 2xx class response for the sent IM. notification if it receives a SIP 2xx class response for the sent IM.
This is in anticipation of a failure downstream after a 2xx response Just because a downstream entity received a MESSAGE request does not
has been generated. mean the message was relayed to its ultimate destination or was
delivered. Thus, the intermediary cannot say delivery occurred just
because it received a 2xx response.
If the Disposition-Notification header field contains a value of If the Disposition-Notification header field contains a value of
"negative-delivery", the intermediary SHOULD generate a delivery "negative-delivery", the intermediary SHOULD generate a delivery
notification if it receives a SIP 4xx, 5xx or 6xx class final notification if it receives a SIP 4xx, 5xx or 6xx class final
response for the sent IM. If it has received a SIP 2xx class response for the sent IM. If it has received a SIP 2xx class
response followed by a negative-delivery notification, the response followed by a negative-delivery notification, the
intermediary forwards that negative-delivery notification or intermediary forwards that negative-delivery notification or
aggregates it. aggregates it.
If the Disposition-Notification header field contains a value of If the Disposition-Notification header field contains a value of
skipping to change at page 28, line 24 skipping to change at page 28, line 49
The <recipient-uri> element of the XML body is populated with the URI The <recipient-uri> element of the XML body is populated with the URI
of the IM Recipient. of the IM Recipient.
If an intermediary receives a SIP MESSAGE request carrying a positive If an intermediary receives a SIP MESSAGE request carrying a positive
delivery notification or a read notification, it forwards it using delivery notification or a read notification, it forwards it using
the rules in Section 8. the rules in Section 8.
13. Transporting Messages using MSRP 13. Transporting Messages using MSRP
MSRP already provides a built-in mechanism to supply positive and MSRP already provides a built-in mechanism to supply positive and
negative delivery reports. negative delivery reports. These reports do not provide built-in
Read or Processing notifications. However, these notifications in
While MSRP does not provide a built-in Read or Processing session mode are not as useful as they are for page-mode. This is
notification dispositions, those are generally not considered as because the base use case for MSRP is that the recipient user agent
useful information for session IM. This is because the assumption immediately renders SEND requests sequentially, providing the session
behind MSRP is that SEND requests do not reach a mailbox where experience. This is unlike page-mode requests where a user has to
incoming IMs have to be open, but to an application that renders actively read the message. That is, they need to click on a button,
sequentially those incoming IMs, providing the session experience. open a message, and so on to read the message.
This kind of applications has no means of identifying when a user has
read the IM and therefore cannot be useful information for the
sender.
IMDN use cases for MSRP have not been fully explored. If new If new requirements arise in the future determining the need for IMDN
requirements arise in the future determining the need for IMDN in in MSRP, new specifications can be drafted.
MSRP, new specifications can be drafted.
14. Security Considerations 14. Security Considerations
IMDNs provide a fine-grained view of the activity of the IM Recipient IMDNs provide a fine-grained view of the activity of the IM Recipient
and thus deserves particularly careful confidentiality protection so and thus deserves particularly careful confidentiality protection so
that only the intended recipient of the IMDN will receive the IMDN. that only the intended recipient of the IMDN will receive the IMDN.
In most cases, the intended recipient of the IMDN is the IM Sender. In most cases, the intended recipient of the IMDN is the IM Sender.
Since the IM transport protocol carries the IMDN, all security Since the IM transport protocol carries the IMDN, all security
considerations of the underlying IM protocol also apply to the IMDNs. considerations of the underlying IM protocol also apply to the IMDNs.
skipping to change at page 29, line 20 skipping to change at page 29, line 39
unsuspecting endpoint to the user. unsuspecting endpoint to the user.
o A malicious endpoint attempts to flood an IM Sender with IMDNs by o A malicious endpoint attempts to flood an IM Sender with IMDNs by
convincing a URI-List server to send IMDNs to an unsuspecting IM convincing a URI-List server to send IMDNs to an unsuspecting IM
Sender. Sender.
o A malicious node in the network that attempts to modify an IMDN o A malicious node in the network that attempts to modify an IMDN
from an IM Recipient. from an IM Recipient.
o A malicious intermediary attempts to forward an IMDN from an IM o A malicious intermediary attempts to forward an IMDN from an IM
Recipient to the IM Sender, where the IM Recipient would not Recipient to the IM Sender, where the IM Recipient would not
normally forward the IMDN to that IM Sender if the IM Recipient normally forward the IMDN to that IM Sender if the IM Recipient
knew the identity of the IM Sender. knew the identity of the IM Sender.
o A malicious endpoint that attempts to fish for a Request-URI of an o A malicious endpoint that attempts to discover for a Request-URI
endpoint beyond an intermediary, where the endpoint would normally of an endpoint beyond an intermediary, where the endpoint would
wish to keep its identity private from the malicious endpoint. normally wish to keep its identity private from the malicious
endpoint.
o A malicious node in the network that attempts to eavesdrop on IMDN o A malicious node in the network that attempts to eavesdrop on IMDN
traffic to, for example, learn Request-URI or traffic pattern traffic to, for example, learn Request-URI or traffic pattern
information. information.
o A malicious node in the network attempts to stage a denial of o A malicious node in the network attempts to stage a denial of
service attack on an intermediary by requesting a large list service attack on an intermediary by requesting a large list
expansion. expansion.
The protocol cannot protect against attacks that include the The protocol cannot protect against attacks that include the
following: following:
o A malicious intermediary directly revealing the identity of a o A malicious intermediary directly revealing the identity of a
skipping to change at page 30, line 22 skipping to change at page 30, line 44
something bad might have happened. something bad might have happened.
o If the IM is encrypted, the IM Recipient or intermediary MUST o If the IM is encrypted, the IM Recipient or intermediary MUST
encrypt the IMDN body, as an attacker may attempt to discern the encrypt the IMDN body, as an attacker may attempt to discern the
user's activity profile and identity from sniffing IMDNs on the user's activity profile and identity from sniffing IMDNs on the
network. network.
o The two above rules are cumulative. o The two above rules are cumulative.
The IM Recipient or intermediary MUST be capable of accessing the IM The IM Recipient or intermediary MUST be capable of accessing the IM
Sender's public certificate in order to verify the signature in the Sender's public certificate in order to verify the signature in the
IM. IM.
CPIM security considerations [2] apply here, as this is an extension CPIM security considerations [RFC3862] apply here, as this is an
of CPIM. In order to make the IMDN mechanism independent of the extension of CPIM. In order to make the IMDN mechanism independent
transport protocol, the Work Group made the design choice of putting of the transport protocol, the Work Group made the design choice of
routing information into the IMDN application layer payload. One putting routing information into the IMDN application layer payload.
consequence of this choice is it eliminates the possibility of having One consequence of this choice is it eliminates the possibility of
end-to-end encryption. having end-to-end encryption.
An attacker can mount a distributed denial of service attack on a An attacker can mount a distributed denial of service attack on a
node by sending lots of IMs to the node with IMDN requests. Note node by sending lots of IMs to the node with IMDN requests. Note
that this is the same problem as there is without IMDN; IMDN simply that this is the same problem as there is without IMDN; IMDN simply
linearly increases the load on the node under attack. One can linearly increases the load on the node under attack. One can
mitigate, but not eliminate this threat by the endpoint immediately mitigate, but not eliminate this threat by the endpoint immediately
ignoring requests that are not authenticated. ignoring requests that are not authenticated.
Likewise, an attacker can mount a denial of service attack on an Likewise, an attacker can mount a denial of service attack on an
intermediary by asking the intermediary to explode a large list. intermediary by asking the intermediary to explode a large list.
skipping to change at page 32, line 13 skipping to change at page 32, line 35
issuing mechanism through policy or manipulation of their User Agent issuing mechanism through policy or manipulation of their User Agent
Server. Server.
15. IANA Considerations 15. IANA Considerations
15.1. message/imdn+xml MIME TYPE 15.1. message/imdn+xml MIME TYPE
This document registers a new MIME type "message/imdn+xml", and This document registers a new MIME type "message/imdn+xml", and
registers a new XML namespace. registers a new XML namespace.
This specification follows the guidelines of RFC 3023 [5]. This specification follows the guidelines of RFC 3023 [RFC3023].
MIME media type: message MIME media type: message
MIME subtype name: imdn+xml MIME subtype name: imdn+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [5]. specified in RFC 3023 [RFC3023].
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [5]. application/xml as specified in RFC 3023 [RFC3023].
Security considerations: See section 10 of RFC 3023 [5] and Security considerations: See section 10 of RFC 3023 [RFC3023] and
Section 14 of this document. Section 14 of this document.
Interoperability considerations: none. Interoperability considerations: none.
Published specification: This document. Published specification: This document.
Applications which use this media type: This document type is used to Applications which use this media type: This document type is used to
support CPIM based instant messaging. support CPIM based instant messaging.
Additional information: None Additional information: None
skipping to change at page 33, line 8 skipping to change at page 33, line 30
Personal and email address for further information: Hisham Khartabil Personal and email address for further information: Hisham Khartabil
(hisham.khartabil@gmail.com) (hisham.khartabil@gmail.com)
Intended Usage: COMMON Intended Usage: COMMON
Author/change controller: The IETF . Author/change controller: The IETF .
15.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:imdn 15.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:imdn
This section registers a new XML namespace, as per guidelines in the This section registers a new XML namespace, as per guidelines in the
IETF XML Registry [3]. IETF XML Registry [IANA].
URI: The URI for this namespace is urn:ietf:params:xml:ns:imdn. URI: The URI for this namespace is urn:ietf:params:xml:ns:imdn.
Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil
(hisham.khartabil@gmail.com) . (hisham.khartabil@gmail.com) .
15.3. Schema Registration 15.3. Schema Registration
This section registers a new XML schema per the procedures in [3]. This section registers a new XML schema per the procedures in [IANA].
Extensions MUST be standards track documents.
URI: urn:ietf:params:xml:ns:imdn URI: urn:ietf:params:xml:ns:imdn
Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil
(hisham.khartabil@gmail.com) (hisham.khartabil@gmail.com)
The XML for this schema can be found as the sole content of The XML for this schema can be found as the sole content of
Section 11.3. Section 11.3.
15.4. Registration for urn:ietf:params:imdn 15.4. Registration for urn:ietf:params:imdn
skipping to change at page 33, line 42 skipping to change at page 34, line 20
standards track RFCs that update or obsolete RFC XXXX (Specification standards track RFCs that update or obsolete RFC XXXX (Specification
Required). Required).
Repository: http://www.iana.org/assignments/imdn Repository: http://www.iana.org/assignments/imdn
Index value: The index value is a CPIM message IMDN header name, Index value: The index value is a CPIM message IMDN header name,
which may consist of a sequence from a restricted set of US-ASCII which may consist of a sequence from a restricted set of US-ASCII
characters, as defined above. characters, as defined above.
URN Formation: The URI for a header is formed from its name by: URN Formation: The URI for a header is formed from its name by:
a) replacing any non-URN characters (as defined by RFC 2141[4]) a) replacing any non-URN characters (as defined by RFC 2141[URN])
with the corresponding '%hh' escape sequence (per RFC 3986 [7]); with the corresponding '%hh' escape sequence (per RFC 3986
and [RFC2396]); and
b) prepending the resulting string with 'urn:ietf:params:imdn:'. b) prepending the resulting string with 'urn:ietf:params:imdn:'.
Thus, the URI corresponding to the CPIM message IMDN header Thus, the URI corresponding to the CPIM message IMDN header
'Disposition-Notification:' would be 'Disposition-Notification:' would be
'urn:ietf:params:imdn:Disposition-Notification'. 'urn:ietf:params:imdn:Disposition-Notification'.
15.5. Message/CPIM Header Field Registration 15.5. Message/CPIM Header Field Registration
This document registers the following message/cpim header fields in This document registers the following message/cpim header fields in
the imdn fields registry: the imdn fields registry:
skipping to change at page 34, line 40 skipping to change at page 35, line 16
notification the body of the message is a notification according to notification the body of the message is a notification according to
an earlier request for a disposition notification to an instant an earlier request for a disposition notification to an instant
message message
16. Acknowledgements 16. Acknowledgements
The authors would like to thank Paul Kyzivat, Ben Campbell, Adam The authors would like to thank Paul Kyzivat, Ben Campbell, Adam
Roach, Gonzalo Camarillo, Sean Olson, Eva Leppanen, Miguel Garcia, Roach, Gonzalo Camarillo, Sean Olson, Eva Leppanen, Miguel Garcia,
Eric McMurry, Jari Urpalainen, Jon Peterson, and Robert Sparks for Eric McMurry, Jari Urpalainen, Jon Peterson, and Robert Sparks for
their comments and support. their comments and support. In addition, we would like to thank the
Gen-Art reviewer extrodinaire, Spencer Dawkins.
17. References 17. References
17.1. Normative References 17.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant
(CPIM): Message Format", RFC 3862, August 2004. Messaging (CPIM): Message Format", RFC 3862, August 2004.
[3] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. [IANA] Mealling, M., "The IETF XML Registry", RFC 3688,
January 2004.
[4] Moats, R., "The URN Syntax", RFC 2141, May 1997. [URN] Moats, R., "The URN Syntax", RFC 2141, May 1997.
[5] Murata, M., "XML Media Types", RFC 3023, March 1997. [RFC3023] Murata, M., "XML Media Types", RFC 3023, March 1997.
[6] Bray, T., "Extensible Markup Language (XML) 1.0 (Second [XML] Bray, T., "Extensible Markup Language (XML) 1.0 (Second
Edition)", W3C CR CR-xml11-20011006, October 2000. Edition)", W3C CR CR-xml11-20011006, October 2000.
[7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, Resource Identifier (URI): Generic Syntax", STD 66,
January 2005. RFC 3986, January 2005.
17.2. Informative References 17.2. Informative References
[8] Rosenberg et al., J., Shulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg et al., J., Shulzrinne, H., Camarillo, G.,
A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, Johnston, A., Peterson, J., Sparks, R., Handley, M., and
"SIP: Session Initiation Protocol", RFC 3261, June 2002. E. Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[9] Campbell, B., "SIP Extension for Instant Messaging", RFC 3428, [RFC3428] Campbell, B., "SIP Extension for Instant Messaging",
December 2002. RFC 3428, December 2002.
[10] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[11] Hansen, T. and G. Vaudreuil, "Message Disposition [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition
Notification", RFC 3798, May 2004. Notification", RFC 3798, May 2004.
[12] Moats, R., "The URN Namespace for IETF Documents", RFC 2648, [URN_NS] Moats, R., "The URN Namespace for IETF Documents",
August 1999. RFC 2648, August 1999.
[13] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE [I-D.ietf-sip-uri-list-message]
Requests in the Session Initiation Protocol (SIP)", Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient
draft-ietf-sip-uri-list-message-03 (work in progress), MESSAGE Requests in the Session Initiation Protocol
December 2007. (SIP)", draft-ietf-sip-uri-list-message-03 (work in
progress), December 2007.
Authors' Addresses Authors' Addresses
Eric Burger Eric Burger
BEA Systems, Inc. BEA Systems, Inc.
4 Van de Graaff Dr. 4 Van de Graaff Dr.
Burlington, MA 01803 Burlington, MA 01803
USA USA
Phone: +1 781 993 7437 Phone: +1 781 993 7437
skipping to change at page 37, line 44 skipping to change at line 1685
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 79 change blocks. 
195 lines changed or deleted 214 lines changed or added

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