draft-ietf-simple-imdn-04.txt   draft-ietf-simple-imdn-05.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: November 16, 2007 May 15, 2007 Expires: June 30, 2008 December 28, 2007
Instant Message Disposition Notification Instant Message Disposition Notification
draft-ietf-simple-imdn-04 draft-ietf-simple-imdn-05
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 November 16, 2007. This Internet-Draft will expire on June 30, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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
skipping to change at page 2, line 21 skipping to change at page 2, line 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . 8 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
6.5. IMDN-Record-Route . . . . . . . . . . . . . . . . . . . . 8 6.5. IMDN-Record-Route . . . . . . . . . . . . . . . . . . . . 8
6.6. IMDN-Route . . . . . . . . . . . . . . . . . . . . . . . . 9 6.6. IMDN-Route . . . . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . 14 8. Intermediary Behaviour . . . . . . . . . . . . . . . . . . . . 14
8.1. Constructing Processing Notifications . . . . . . . . . . 15 8.1. Constructing Processing Notifications . . . . . . . . . . 15
8.2. Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 16 8.2. Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 16
9. Identifying Messages . . . . . . . . . . . . . . . . . . . . . 19 9. Identifying Messages . . . . . . . . . . . . . . . . . . . . . 18
10. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 19 10. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 19
11. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Structure of XML-Encoded IMDN Payload . . . . . . . . . . 20 11.1. Structure of XML-Encoded IMDN Payload . . . . . . . . . . 19
11.1.1. The <message-id> Element . . . . . . . . . . . . . . . 20 11.1.1. The <message-id> Element . . . . . . . . . . . . . . . 20
11.1.2. The <datetime> Element . . . . . . . . . . . . . . . . 20 11.1.2. The <datetime> Element . . . . . . . . . . . . . . . . 20
11.1.3. The <recipient-uri> Element . . . . . . . . . . . . . 20 11.1.3. The <recipient-uri> Element . . . . . . . . . . . . . 20
11.1.4. The <original-recipient-uri> Element . . . . . . . . . 21 11.1.4. The <original-recipient-uri> Element . . . . . . . . . 20
11.1.5. The <subject> Element . . . . . . . . . . . . . . . . 21 11.1.5. The <subject> Element . . . . . . . . . . . . . . . . 20
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 . . . . . . . . . . . . . . . . . . 21
11.2. MIME Type for IMDN Payload . . . . . . . . . . . . . . . . 21 11.2. MIME Type for IMDN Payload . . . . . . . . . . . . . . . . 21
11.3. The RelaxNG Schema . . . . . . . . . . . . . . . . . . . . 21 11.3. The RelaxNG Schema . . . . . . . . . . . . . . . . . . . . 21
12. Transporting Messages using SIP . . . . . . . . . . . . . . . 25 12. Transporting Messages using SIP . . . . . . . . . . . . . . . 25
12.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 25 12.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 25
12.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 25 12.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 25
12.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 26 12.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 25
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 . . . . . . . . . . . . . . . . . . . 28
14.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 30 14.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 30
14.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 31 14.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 31
14.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 31 14.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 31
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
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
skipping to change at page 4, line 21 skipping to change at page 4, line 21
Electronic Mail [10] deals with this situation with Message Delivery Electronic Mail [10] deals with this situation with Message Delivery
Notifications [11]. After the recipient views the message, her mail Notifications [11]. After the recipient views the message, her mail
user agent generates a Message Delivery Notification, or MDN. The user agent generates a Message Delivery Notification, or MDN. The
MDN is an e-mail that follows the format prescribed by RFC3798 [11]. MDN is an e-mail that follows the format prescribed by RFC3798 [11].
The fixed format ensures that an automaton can process the message. The fixed format ensures that an automaton can process the message.
Message/CPIM [2] is a message format used to generate instant Message/CPIM [2] is a message format used to generate instant
messages. SIP [8] can carry instant messages generated using messages. SIP [8] can carry instant messages generated using
message/CPIM in SIP MESSAGE requests [9]. message/CPIM in SIP MESSAGE requests [9].
This document extends Message/CPIM message format (much like Message This document extends Message/CPIM message format, much like Message
Delivery Notifications extends Electronic Mail) to enable Instant Delivery Notifications extends Electronic Mail. This extension
Message Senders to request, create and send Instant Message enables Instant Message Senders to request, create and send Instant
Disposition Notifications (IMDN). This mechanism works for a page- Message Disposition Notifications (IMDN). This mechanism works for
mode as well as session mode instant messages. This document only page-mode as well as session mode instant messages. This document
discusses page-mode. Session mode is left as future standardisation only discusses page-mode. Session mode is left for future
efforts. 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 as well as
processed notifications. By using CPIM header fields, the IMDN processed notifications. By using CPIM header fields, the IMDN
request and delivery are abstracted outside the transport protocol request and delivery are abstracted outside the transport protocol
allowing interoperability between different IM systems. 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 [1].
3. Terminology This document refers generically to the sender of a 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
and makes no assumption about the gender of a message sender or
recipient.
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 a 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.
It is also the endpoint that requests IMDNs for an IM. Quite Also, the endpoint request IMDNs for an IM. Quite often, the IM
often, the IM Sender is the IMDN Recipient, but that is not always Sender is the IMDN Recipient. However, that is not always the
true since an IM Sender's Address of Record (AoR) placed in the IM case, since the IMDN uses the From header in the CPIM message.
and in turn used in the IMDN may in fact resolve to different User That value is often the IM Sender's Address of Record (AoR). This
Agents. This is an artifact of the nature of page-mode IMs. 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. It is Recipient, as the node that presumably renders the IM to the user,
also the endpoint that generates and sends IMDNs to IMs, if generates and sends delivery IMDNs to IMs, if requested by the IM
requested by the IM Sender. 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 that is on the path of an
IM to its final destination. IM to its final destination. Intermediaries also can generate and
send processing IMDNs to IMs, if requested by the IM Sender and
allowed by policy.
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
The basic protocol flow is depicted in the diagram below. An IM The diagram below shows the basic protocol flow. An IM Sender
Sender creates an IM, adds IMDN request information the IM Sender is creates an IM, adds IMDN request information the IM Sender is
interested in receiving, then sends IM. At a certain point in time, interested in receiving and then sends the IM. At a certain point in
the IM Recipient or an intermediary determines that the user or time, the IM Recipient or an intermediary determines that the user or
application has received, did not receive, read, or otherwise application has received, did not receive, read, or otherwise
disposed the IM. The mechanism by which an IM Recipient determines disposed the IM. The mechanism by which an IM Recipient determines
its user has read an IM is beyond the scope of this document. At its user has read an IM is beyond the scope of this document. At
that point, the IM Recipient or intermediary automatically generates that point, the IM Recipient or intermediary automatically generates
a notification message to the IM Sender. This notification message a notification message to the IM Sender. This notification message
is the Instant Message Disposition Notification (IMDN). is the Instant Message Disposition Notification (IMDN).
+--------------+ +--------------+ +--------------+ +--------------+
| IM Sender | | IM Recipient | | IM Sender | | IM Recipient |
|IMDN Recipient| | IMDN Sender | |IMDN Recipient| | IMDN Sender |
skipping to change at page 6, line 22 skipping to change at page 6, line 22
|-------------------------------------->| |-------------------------------------->|
| | | |
| | | |
| 2. IMDN (disposition) | | 2. IMDN (disposition) |
|<--------------------------------------| |<--------------------------------------|
| | | |
| | | |
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 Address of Record (AOR) of the IM Sender, that is present in the IM,
IMDN, resolves to a different location or user agent to where the IM resolves to a different location or user agent than the IM
originated. For simplicity, the rest of this document assumes that originated. For simplicity, the rest of this document assumes that
the IM Sender and the IMDN Recipient are the same and therefore will the IM Sender and the IMDN Recipient are the same and therefore will
refer to both as the IM Sender. 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. Future extensions may introduce
others. others.
skipping to change at page 6, line 39 skipping to change at page 6, line 39
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. Future extensions may introduce
others. 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 "forbidden" state can be sent by the IM requested IMDN. The IM Recipient can send the "forbidden" state,
Recipient but is mainly sent by an intermediary that is configured but usually it is an intermediary that sends the message if one
to do so. For example, the administrator has disallowed IMDNs. configures it to do so. For example, it is possible the
administrator has disallowed IMDNs.
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.
5.2. Processing 5.2. Processing
The processing notification type indicates that an IM has been The processing notification type indicates that an IM has been
processed by an intermediary. The processing notification type can processed by an intermediary. The processing notification type can
have the following states: have the following states:
o "processed" is a general state of the IM indicating that the o "processed" is a general state of the IM indicating that the
intermediary has performed its task on the IM. intermediary has performed its task on the IM.
o "stored" state indicates that the IM has been stored by the o "stored" state indicates that the IM has been stored by the
intermediary for later delivery. intermediary for later 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 "forbidden" state is sent by an intermediary requested IMDN. The "forbidden" state is sent by an intermediary
that is configured to do so. For example, the administrator has that is configured to do so. For example, the administrator has
disallowed IMDNs. disallowed IMDNs.
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.
5.3. Read 5.3. Read
The read notification type indicates whether the IM Recipient The read notification type indicates whether the IM Recipient
rendered the IM to the user or not. The read notification type can rendered the IM to the user or not. The read notification type can
have the following states: have the following states:
o "read" is a state indicating that the IM has been rendered to the
o "read" is a state indicating that the IM has been displayed or user.
played to the 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.
Some IMs may in fact be audio, video or still images. Therefore, the In addition to text, some IMs may contain audio, video and still
state "read" includes playing the audio or video file to the user. images. Therefore, the state "read" includes playing the audio or
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 that the user actually read the IM. Thus one determine a priori the user actually read the IM. Thus, one cannot
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 [2]. A new namespace is created as well as a number of new CPIM
header fields. 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 [2], this specification defines a new namespace for the CPIM
skipping to change at page 8, line 12 skipping to change at page 8, line 4
[2]. A new namespace is created as well as a number of new CPIM [2]. A new namespace is created as well as a number of new CPIM
header fields. 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 [2], this specification defines a new namespace for the CPIM
extension header fields defined in the following sections. The extension header fields defined in the following sections. The
namespace is: namespace is:
urn:ietf:params:imdn urn:ietf:params:imdn
As per CPIM [2] requirements, the new header fields defined in the As per CPIM [2] requirements, the new header fields defined in the
following sections are prepended, in CPIM messages, by a prefix 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
any legal namespace prefix specification.
6.2. Disposition-Notification 6.2. Disposition-Notification
The Disposition-Notification header field is used by the IM Sender to The IM Sender MUST include the Disposition-Notification header field
indicate the desire to receive IMDNs, from the IM Recipient, for that to indicate the desire to receive IMDNs from the IM Recipient, for
specific IM. This header field is not needed if the IM Sender does that specific IM. This header field is not needed if the IM Sender
not request an IMDN. The syntax is defined in Section 10. does not request an IMDN. Section 10 defines the syntax.
6.3. Message-ID 6.3. Message-ID
The Message-ID header field contains a globally unique message The IM Sender MUST include the Message-ID header field in the IM that
identifier that is used by the IM Sender to correlate received IMDNs he wishes to receive an IMDN on. The Message-ID contains a globally
by comparing its value with the value of the <message-id> element unique message identifier the IM Sender can use to correlate received
present in the IMDN payload. This header field is MANDATORY when IMDNs. When the IM Sender receives an IMDN, it can compare its value
sending an IM and requesting an IMDN. IMDNs also carry this header with the value of the <message-id> element present in the IMDN
field. The syntax is defined in Section 10. 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
than the Message-ID of the original IM. Section 10 defines the
syntax.
6.4. Original-To 6.4. Original-To
The Original-To header field is sometimes added to an IM by an An intermediary MAY insert an Original-To header field to the IM.
intermediary and populated with the address of the IM Receiver. It The value of the Original-To field MUST be the address of the IM
is used by the IM Recipient to indicate in the IMDNs (by populating Receiver. The IM Recipient uses this header to indicate the original
the <original-recipient-uri> element) the original address the IM was IM address in the IMDNs. The IM Recipient does this by populating
sent to. This header field is mandatory if the intermediary changes the <original-recipient-uri> element in the IMDN. The intermediary
the CPIM To header field value. The header field MUST NOT appear MUST insert this header if the intermediary changes the CPIM To
more than once in an IM. The header field value MUST NOT be changed header field value. The header field MUST NOT appear more than once
by an intermediary if it was already present. The syntax is defined in an IM. The intermediary MUST NOT change this header field value
in Section 10. if it is already present. Section 10 defines the syntax.
6.5. IMDN-Record-Route 6.5. IMDN-Record-Route
Intermediaries have the capability of indicating that IMDNs should be An intermediary MAY insert an IMDN-Record-Route header field to the
sent through it (otherwise, IMDNs will not visit the intermediary). IM. The value of the IMDN-Record-Route header field MUST be the
address of the intermediary. Multiple IMDN-Record-Route header
An intermediary that request IMDNs to be sent through itself adds an fields can appear in an IM. Section 10 defines the syntax.
IMDN-Record-Route header field to the IM. The value of the IMDN-
Record-Route header field is set to the address of that intermediary.
Multiple IMDN-Record-Route header fields can appear in an IM. The
syntax is defined in Section 10.
6.6. IMDN-Route 6.6. IMDN-Route
The IMDN-Route header field provides routing information by including The IMDN-Route header field provides routing information by including
one or more addresses where an IMDN must be routed through. On one or more addresses where to route the IMDN. An intermediary that
creating an IMDN, an IM recipient copies the contents of the IMDN- needs the IMDN to flow back through the same intermediary MUST add
Record-Route present in the IM into the IMDN-Route of the IMDN. the IMDN-Record-Route header. When the IM Recipient creates the
Multiple IMDN-Route header fields can appear in an IMDN. The syntax corresponding IMDN, the IM Recipient copies the IMDN-Record-Route
is defined in Section 10. headers into corresponding IMDN-Route header fields. Section 10
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]. [2].
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 32 bits of randomness. This header with a value that is unique with at least 32 bits of randomness.
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
Some devices may not implement the concept of "Sent Items" box and Some devices are not able to retain state over long periods. For
therefore no information about an IM is stored. It is therefore example, mobile devices may have memory limits or battery limits.
necessary to add a time stamp in the IM to indicate when it was sent. These limits may mean these devices may not be able to, or may chose
This time stamp is returned in the IMDN in order to enable the user not to, keep sent messages for the purposes of correlating IMDNs with
to correlate the IM with the IMDN at the human level. The DateTime sent IMs. To make some use of IMDN in this case, we add a time stamp
header field is used for this purpose. The IM MUST contain a to the IM to indicate when the user sent the message. The IMDN
DateTime header field if an IMDN is requested. returns this time stamp to enable the user to correlate the IM with
the IMDN at the human level. We use the DateTime CPIM header field
for this purpose. Thus, if the IM Sender would like an IMDN, the IM
Sender MUST include the DateTime CPIM header field.
7.1.1.3. Adding a Disposition-Notification Header Field 7.1.1.3. Adding a Disposition-Notification Header Field
The Disposition-Notification conveys the type of disposition The Disposition-Notification conveys the type of disposition
notification requested by the IM sender. There are three types of notification requested by the IM sender. There are three types of
disposition notification: delivery, processing, and read. The disposition notification: delivery, processing, and read. The
delivery notification is further subdivided into failure and success delivery notification is further subdivided into failure and success
delivery notifications. An IM Sender requests failure delivery delivery notifications. An IM Sender requests failure delivery
notification by including a Disposition-Notification header field notification by including a Disposition-Notification header field
with value "negative-delivery". Similarly, a success notification is with value "negative-delivery". Similarly, a success notification is
requested by including a Disposition-Notification header field with requested by including a Disposition-Notification header field with
value "positive-delivery". Both types of delivery notifications can value "positive-delivery". The IM Send can request both types of
be requested for the same IM. delivery notifications for the same IM.
The IM Sender can request a processing notification by including a The IM Sender can request a processing notification by including a
Disposition-Notification header field with value "processing". Disposition-Notification header field with value "processing".
The IM Sender can also request a read notification. It is requested The IM Sender can also request a read notification. The IM Sender
by including a Disposition-Notification header field with value MUST include a Disposition-Notification header field with the value
"read". "read" to request a read request.
The absence of this header field or the presence of the header field The absence of this header field or the presence of the header field
with empty value indicates that the IM Sender is not requesting any with an empty value indicates that the IM Sender is not requesting
IMDNs. The Disposition-Notification header field values can be comma any IMDNs. Disposition-Notification header field values are comma
separated. The IM Sender MAY request more than one type of IMDN for separated. The IM Sender MAY request more than one type of IMDN for
a single IM. a single IM.
Future extension may define other disposition notifications not Future extensions may define other disposition notifications not
defined in this document. defined in this document.
The formal syntax of the Disposition-Notification header field can be Section 10 describes the formal syntax for the Disposition-
found in Section 10. The following is an example CPIM body of an IM Notification header field. The following is an example CPIM body of
where the IM Sender requests positive and negative delivery an IM where the IM Sender requests positive and negative delivery
notifications, but not read notification nor processing notifications, but neither read notification nor processing
notifications: notifications:
From: Alice <im:alice@example.com> From: Alice <im:alice@example.com>
To: Bob <im:bob@example.com> To: Bob <im:bob@example.com>
NS: imdn <urn:ietf:params:imdn> NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: 34jk324j imdn.Message-ID: 34jk324j
DateTime: 2006-04-04T12:16:49-05:00 DateTime: 2006-04-04T12:16:49-05:00
imdn.Disposition-Notification: positive-delivery, negative-delivery imdn.Disposition-Notification: positive-delivery, negative-delivery
Content-type: text/plain Content-type: text/plain
Content-length: 12 Content-length: 12
Hello World Hello World
skipping to change at page 11, line 7 skipping to change at page 11, line 5
7.1.2. Matching IMs with IMDNs 7.1.2. Matching IMs with IMDNs
An IM Sender matches an IMDN to an IM by matching the Message-ID An IM Sender matches an IMDN to an IM by matching the Message-ID
header field value in the IM with the <message-id> element value in header field value in the IM with the <message-id> element value in
the body of the IMDN. If the IM was delivered to multiple the body of the IMDN. If the IM was delivered to multiple
recipients, the IM Sender uses the <recipient-uri> element and the recipients, the IM Sender uses the <recipient-uri> element and the
<original-recipient-uri> element in the XML body of the IMDN it <original-recipient-uri> element in the XML body of the IMDN it
received to determine if the IM was sent to multiple recipients and received to determine if the IM was sent to multiple recipients and
to identify the IM Recipient that sent the IMDN. to identify the IM Recipient that sent the IMDN.
An IM Sender can determine an IMDN is a disposition notification by
noting the Content-Disposition in the IMDN is "notification". This
does mean the IM Sender MUST understand the Content-Disposition MIME
header in CPIM messages.
7.1.3. Keeping State 7.1.3. Keeping State
This specification does not mandate the IM Sender to keep state for a This specification does not mandate the IM Sender to keep state for a
sent IM. sent IM.
Once an IM Sender sends an IM containing an IMDN request, it MAY Once an IM Sender sends an IM containing an IMDN request, it MAY
preserve the IM context, principally the Message-ID, and other user- preserve the IM context, principally the Message-ID, and other user-
identifiable information such as the IM subject or content, and date identifiable information such as the IM subject or content, and date
and time it was sent. Without preservation of the IM context, the IM and time it was sent. Without preservation of the IM context, the IM
Sender will not be able to correlate the IMDN with the IM it sent. Sender will not be able to correlate the IMDN with the IM it sent.
The IM Sender may find it impossible to preserve IM state if it has The IM Sender may find it impossible to preserve IM state if it has
limited resources or does not have non-volatile memory and then loses limited resources or does not have non-volatile memory and then loses
power. power.
There is, however, the concept of "Sent Items" box in an application There is, however, the concept of "Sent Items" box in an application
that stores sent IMs. This "Sent Items" box has the necessary that stores sent IMs. This "Sent Items" box has the necessary
information and may have a fancy user interface indicating the state information and may have a fancy user interface indicating the state
of a sent IM. Unique Message-ID for this purpose proves to be of a sent IM. A unique Message-ID for this purpose proves to be
useful. The length of time for items to remain in the "Sent Items" useful. The length of time for items to remain in the "Sent Items"
box is a user choice. The user is usually free to keep or delete box is a user choice. The user is usually free to keep or delete
items from the "Sent Items" box as she pleases or as the memory on items from the "Sent Items" box as she pleases or as the memory on
the device reaches capacity. the device reaches capacity.
Clearly, if an IM Sender loses its sent items state (user deletes Clearly, if an IM Sender loses its sent items state, for example, the
items from the "Send Items" box), the client may use a different user deletes items from the "Send Items" box, the client may use a
display strategy in response to apparently unsolicited IMDNs. different display strategy in response to apparently unsolicited
IMDNs.
This specification also does not mandate an IM Sender to run any This specification also does not mandate an IM Sender to run any
timers waiting for an IMDN. There are no time limits associated with timers waiting for an IMDN. There are no time limits associated with
when IMDNs may be received. when IMDNs may be received.
IMDNs may legitimately never be received. On the other hand, and IMDNs may legitimately never be received. Likewise, the recipient
IMDN may simply take a very long time. Some clients may choose to may take a long time to actually read the message, so the time
purge the state associated with the sent IM. This is the reason for between the sending of an IM and the generation and ultimate receipt
adding the time stamp in the IM and having it returned in the IMDN. of the IMDN may simply take a very long time. Some clients may
This gives the user some opportunity of remembering what IM was sent. choose to purge the state associated with the sent IM. This is the
For example if the IMDN indicates that the IM the user sent at 2 p.m. reason for adding the time stamp in the IM and having it returned in
last Thursday was delivered, the user has a chance of remembering the IMDN. This gives the user some opportunity of remembering what
that they sent an IM at 2 p.m. last Thursday. 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
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) and request
IMDNs. An IM Sender that requested IMDNs MUST be prepared to receive IMDNs. An IM Sender that requested IMDNs MUST be prepared to receive
multiple aggregated or non-aggregated IMDNs. See Section 8.2 for multiple aggregated or non-aggregated IMDNs. See Section 8.2 for
details. 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 an IMDN must be
generated for that IM. Disposition-Notification header fields of generated for that IM. Disposition-Notification header fields of
CPIM messages can include one or more values. This implies that IM CPIM messages can include one or more values. This implies that 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. I.e. It must not, for example, generate a per disposition type. That is, it must not generate a delivery
delivery notification indicating "delivered" then followed by a notification indicating "delivered" then followed by a delivery
delivery notification indicating "failed" for the same IM. If the IM notification indicating "failed" for the same IM. If the IM Sender
Sender requested only failure notifications and the IM was requested only failure notifications and the IM was successfully
successfully delivered, then no IMDNs will be generated. delivered, then no IMDNs will be generated.
The IM Recipient MUST NOT generate "processing" notifications. The IM Recipient MUST NOT generate "processing" notifications.
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. IM Sender MUST since it is forbidden to request an IMDN for an IMDN. An IM Sender
ignore it if present. The IM Sender MUST NOT send an IMDN to an MUST ignore a delivery notification request in an IMDN if present.
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
apply to an IMDN. The Message-ID header field in the IMDN is apply to an IMDN. The Message-ID header field in the IMDN is
different and unrelated to the one in the IM. different and unrelated to the one in the IM.
An IM may contain a IMDN-Record-Route header field (see Section 8 for An IM may contain a IMDN-Record-Route header field (see Section 8 for
details). If IMDN-Record-Route header fields appear in the IM, the details). If IMDN-Record-Route header fields appear in the IM, the
IM Recipient constructing the IMDN MUST copy the contents of 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 SHOULD NOT be placed in an IMDN. make sense in an IMDN and therefore MUST NOT be placed in an IMDN.
IMDN Recipients SHOULD ignore it if present. IMDN Recipients MUST ignore it if present.
The CPIM Content-Disposition header field must be set to the value As stated in CPIM [2], CPIM messages may need to support MIME headers
"notification". This indicates to the IM Sender that the message is other than Content-type. IM Recipients MUST insert a Content-
an IMDN to an IM it has earlier sent. Disposition header field, set to the value "notification". This
indicates to the IM Sender that the message is an IMDN to an IM it
has earlier sent.
7.2.1.1. Constructing Delivery Notifications 7.2.1.1. Constructing Delivery Notifications
A delivery notification is constructed in a similar fashion as an IM, The IM Recipient constructs a delivery notification in a similar
using a CPIM body [2] that carries a Disposition Notification XML fashion as an IM, using a CPIM body [2] that carries a Disposition
document formatted according to the rules specified in Section 11. Notification XML document formatted according to the rules specified
The MIME type of the Disposition Notification XML document is in Section 11. The MIME type of the Disposition Notification XML
"message/imdn+xml". document is "message/imdn+xml".
An example CPIM body of IMDN looks like the following: Section 10 defines the schema for an IMDN.
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
Content-Disposition: notification Content-Disposition: notification
Content-length: ... Content-length: ...
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<imdn xlmns="urn:ietf:params:xml:ns:imdn"> <imdn xlmns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id> <message-id>34jk324j</message-id>
<datetime>2006-04-04T12:16:49-05:00</datetime> <datetime>2006-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri> <recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri> <original-recipient-uri>
im:bob@example.com</original-recipient-uri> im:bob@example.com
</original-recipient-uri>
<disposition> <disposition>
<delivery/> <delivery/>
</disposition> </disposition>
<status> <status>
<delivered/> <delivered/>
</status> </status>
<note lang="en">The IM was successfully Delivered</note> <note lang="en">The IM was successfully Delivered</note>
</imdn> </imdn>
7.2.1.2. Constructing Read Notifications 7.2.1.2. Constructing Read Notifications
A read notification is constructed in a similar fashion as the The IM Recipient constructs a read notification in a similar fashion
delivery notification. See Section 7.2.1.1 for details. as the delivery notification. See Section 7.2.1.1 for details.
An example looks like the following: Section 10 defines the schema for an IMDN.
An example 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: dfjkleriou432333 imdn.Message-ID: dfjkleriou432333
Content-type: message/imdn+xml Content-type: message/imdn+xml
Content-Disposition: notification Content-Disposition: notification
Content-length: ... Content-length: ...
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<imdn xlmns="urn:ietf:params:xml:ns:imdn"> <imdn xlmns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id> <message-id>34jk324j</message-id>
<datetime>2006-04-04T12:16:49-05:00</datetime> <datetime>2006-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri> <recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri> <original-recipient-uri>
im:bob@example.com</original-recipient-uri> im:bob@example.com
</original-recipient-uri>
<disposition> <disposition>
<read/> <read/>
</disposition> </disposition>
<status> <status>
<read/> <read/>
</status> </status>
<note lang="en">The IM has been read</note> <note lang="en">The IM has been read</note>
</imdn> </imdn>
There are situations where the IM Recipient cannot determine if or There are situations where the IM Recipient cannot determine if or
when the IM has been read. The IM Recipient in this case generates a when the IM has been read. The IM Recipient in this case generates a
read notification with a <status> value of "error" to indicate an read notification with a <status> value of "error" to indicate an
internal error by the server. Note that the IM Recipient may choose internal error by the server. Note that the IM Recipient may choose
to ignore any IMDN requests and not to send any IMDNs. An example of to ignore any IMDN requests and not to send any IMDNs. An IM
this is when a SIP stack with built in IMDN support is talking to an recipient may not wish to let a sender know she read, or did not
IM application and the IM application never returned indicating that read, a particular message. Likewise, she may not want anyone to
it has displayed the IM to the user. know if she reads messages. This could be on a per-message, per-
sender, or programmed policy choice.
8. Intermediary Behaviour 8. Intermediary Behaviour
In this context, application servers (including URI-List servers and In this context, intermediaries are application servers (including
Store-and-Forward server) and gateways are defined as intermediaries. URI-List servers and Store-and-Forward server) and gateways. A
A gateway is a server the translates between different IM systems gateway is a server the translates between different IM systems that
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
to be sent to the list members (see [13] for details). In this case, that it sends to the list members (see [13] for details). In this
if the IM Sender is requesting an IMDN, the intermediary MUST add an case, if the IM Sender is requesting an IMDN, the intermediary SHOULD
Original-To header field to the IM populating it with the address add an Original-To header field to the IM populating it with the
that was in the CPIM To header field before it was changed. I.e. address that was in the CPIM To header field before it was changed.
The Original-To header field is populated with the intermediary I.e., the Original-To header field is populated with the intermediary
address. An intermediary MUST NOT add an Original-To header field if address. An intermediary MUST NOT add an Original-To header field if
one already exists. one already exists. An intermediary MAY have an administrative
configuration to not reveal the original Request-URI, and as such,
MAY chose not to 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 pops 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 IMDN-Route
header fields are present, the IMDN is forwarded to the address in header fields are present, the IMDN is forwarded to the address in
the CPIM To header field. 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
notifications. They do so only if the IM Sender has requested a notifications. They do so only if the IM Sender has requested a
"processing" notification by including a Disposition-Notification "processing" notification by including a Disposition-Notification
header field with value "processing". header field with value "processing".
The intermediary can create and send "processing" notifications The intermediary can create and send "processing" notifications
indicating that an IM has been processed or stored. The intermediary indicating that an IM has been processed or stored. The intermediary
MUST NOT send more than one IMDN for the same disposition type. I.e. MUST NOT send more than one IMDN for the same disposition type.
It must not send a "processing" notification indicating that an IM is I.e., it must not send a "processing" notification indicating that an
being "processed" followed by another IMDN indicating that the same IM is being "processed" followed by another IMDN indicating that the
IM is "stored". same IM is "stored".
A "processing" notification is constructed in a similar fashion as An intermediary constructs a "processing" notification in a similar
the delivery notification. See Section 7.2.1.1 for details. fashion as the delivery notification. See Section 7.2.1.1 for
details.
An example looks like the following: An example looks like the following:
Content-type: Message/CPIM Content-type: Message/CPIM
From: Bob <im:bob@example.com> From: Bob <im:bob@example.com>
To: Alice <im:alice@example.com> To: Alice <im:alice@example.com>
Content-type: message/imdn+xml Content-type: message/imdn+xml
Content-Disposition: notification Content-Disposition: notification
Content-length: ... Content-length: ...
<imdn> <imdn>
<message-id>34jk324j</message-id> <message-id>34jk324j</message-id>
skipping to change at page 16, line 18 skipping to change at page 16, line 19
To: Alice <im:alice@example.com> To: Alice <im:alice@example.com>
Content-type: message/imdn+xml Content-type: message/imdn+xml
Content-Disposition: notification Content-Disposition: notification
Content-length: ... Content-length: ...
<imdn> <imdn>
<message-id>34jk324j</message-id> <message-id>34jk324j</message-id>
<datetime>2006-04-04T12:16:49-05:00</datetime> <datetime>2006-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri> <recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri> <original-recipient-uri>
im:bob@example.com</original-recipient-uri> im:bob@example.com
</original-recipient-uri>
<disposition> <disposition>
<processing/> <processing/>
</disposition> </disposition>
<status> <status>
<processed/> <processed/>
</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
skipping to change at page 16, line 40 skipping to change at page 16, line 42
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. In this context, URI-List servers are defined as intermediaries.
An intermediary may choose to aggregate IMDNs using local policy for An intermediary may choose to aggregate IMDNs using local policy for
making such a decision or it may send individual IMDNs instead. When making such a decision or it may send individual IMDNs instead. When
a URI-List server receives an IM and decides to aggregate IMDNs, it a URI-List server receives an IM and decides to aggregate IMDNs, it
can wait for a configurable period of time or until all recipients 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
aggregated IMDN and restart the timer for the next batch. This is aggregated IMDN and restart the timer for the next batch. This is
needed for scenarios where the IM Sender has requested more than one needed for scenarios where the IM Sender has requested more than one
IMDN for a specific IM, for example, delivery notifications as well IMDN for a specific IM, for example, delivery notifications as well
as read notifications, or when the URI-List server is short on as read notifications, or when the URI-List server is short on
resources and chooses to prioritise forwarding IMs over IMDNs. resources and chooses to prioritise forwarding IMs over IMDNs.
A second timer can be running and when it fires, the state of the IM A second timer can be running and when it fires, the state of the IM
is deleted. In this case, the URI-List server consumes any IMDNs is deleted. In this case, the URI-List server consumes any IMDNs
that might arrive after that time. that might arrive after that time.
Please note that the references to timers in the above paragraphs are Please note the references to timers in the above paragraphs are not
not normative and are only present to help describe one way normative and are only present to help describe one way one might
aggregation might be implemented. implement aggregation.
A URI-List server MAY aggregate IMDNs for the case where the list A URI-List server MAY aggregate IMDNs for the case where the list
membership information is not disclosed. There may be scenarios membership information is not disclosed. There may be scenarios
where the URI-List server starts sending aggregated IMDNs and switch where the URI-List server starts sending aggregated IMDNs and switch
to individual ones or visa versa. A timer firing so often may in to individual ones or visa versa. A timer firing so often may in
fact have that effect. fact have that effect.
The aggregated IMDN is constructed using the multipart/mixed MIME The aggregated IMDN is constructed using the multipart/mixed MIME
type and including all the received IMDNs as message/imdn+xml as type and including all the received IMDNs as message/imdn+xml as
individual payloads. individual payloads.
skipping to change at page 18, line 23 skipping to change at page 17, line 47
--imdn-boundary --imdn-boundary
Content-type: message/imdn+xml Content-type: message/imdn+xml
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<imdn xlmns="urn:ietf:params:xml:ns:imdn"> <imdn xlmns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id> <message-id>34jk324j</message-id>
<datetime>2006-04-04T12:16:49-05:00</datetime> <datetime>2006-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri> <recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri> <original-recipient-uri>
im:bob@example.com</original-recipient-uri> im:bob@example.com
</original-recipient-uri>
<disposition> <disposition>
<delivery/> <delivery/>
</disposition> </disposition>
<status> <status>
<delivered/> <delivered/>
</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
Content-type: message/imdn+xml Content-type: message/imdn+xml
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<imdn xlmns="urn:ietf:params:xml:ns:imdn"> <imdn xlmns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id> <message-id>34jk324j</message-id>
<datetime>2006-04-04T12:16:49-05:00</datetime> <datetime>2006-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri> <recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri> <original-recipient-uri>
im:bob@example.com</original-recipient-uri> im:bob@example.com
</original-recipient-uri>
<disposition> <disposition>
<read/> <read/>
</disposition> </disposition>
<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
skipping to change at page 19, line 26 skipping to change at page 19, line 7
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.
Note a message of type multipart/mixed can be a notification if it
includes a part of type message/imdn+xml.
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 RFC3862 [2]. syntax as described in Section 3 of RFC3862 [2].
Header field syntax is described without a namespace qualification. Header field syntax is described without a namespace qualification.
Following the rules in RFC3862 [2], header field names and other text Following the rules in RFC3862 [2], header field names and other text
are case sensitive and MUST be used as given, using exactly the are case sensitive and MUST be used as given, using exactly the
indicated upper-case and lower-case letters. 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
Message-ID = "Message-ID" ": " Token Message-ID = "Message-ID" ": " Token
Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">" Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">"
skipping to change at page 25, line 39 skipping to change at page 25, line 24
</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
A SIP MESSAGE request is constructed using RFC 3428 [9]. The The IM Sender constructs a SIP MESSAGE request using RFC 3428 [9].
Content-type header field indicates the MIME type of the request The Content-type header field indicates the MIME type of the request
payload. When using this extension, the Content-type header field payload. When using this extension, the Content-type header field
MUST be of MIME type "message/cpim" [2] for both IMs and IMDNs. The MUST be of MIME type "message/cpim" [2] for both IMs and IMDNs. The
payload is constructed according to Section 7. IM Sender constructs the payload according to Section 7.
A SIP MESSAGE request to multiple recipients is constructed in a The IM Sender constructs a SIP MESSAGE request to multiple recipients
similar manner as a SIP MESSAGE request to a single recipient. The in a similar manner as a SIP MESSAGE request to a single recipient.
differences are indicated in [13]. Multiple-Recipient MESSAGE Requests in SIP [13] describes the
differences.
Due to the fact that IM senders can remain anonymous, e.g., by
setting the SIP From header field of the SIP message to an anonymous
URI, anonymous IM senders are cannot request disposition
notifications. Therefore, anonymous IM senders SHOULD NOT request
disposition notifications. An IM Recipient can ignore such request
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 RFC3428 [9]. Of course, an endpoint will send a according to RFC3428 [9]. Of course, an endpoint will send a
response to the MESSAGE request regardless of they type of message response to the MESSAGE request regardless of the type of message (IM
(IM or IMDN) is has received, or the disposition type it has been or IMDN) is has received, or the disposition type it has been asked
asked for. 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
constructed and sent a SIP 2xx class response, it MAY generate a constructed and sent a SIP 2xx class response, it MAY generate a
positive-delivery notification after making sure that the IM has been positive-delivery notification after making sure that the IM has been
delivered to the user or application (a gateway, for example, can delivered to the user or application. A gateway, for example, can
generate a 2xx response before it has been guaranteed that the final generate a 2xx response before the final recipient received the IM.
recipient has actually received the IM). The positive-delivery The IM Recipient constructs a positive-delivery notification
notification is constructed according to Section 7.2.1.1. The according to Section 7.2.1.1. The IM Recipient places the message as
message is then placed as the payload in a SIP MESSAGE request. the payload in a SIP MESSAGE request.
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 negative-delivery, and that IM Recipient has constructed requested a negative-delivery, and that IM Recipient has constructed
and sent a 2xx class response, it SHOULD generate a negative-delivery and sent a 2xx class response, it SHOULD generate a negative-delivery
notification if it learnt that the final recipient or application did notification if it learnt that the final recipient or application did
not receive the IM (a gateway, for example, can generate a 2xx not receive the IM (a gateway, for example, can generate a 2xx
response before it has an error response from downstream or before response before it has an error response from downstream or before
any internal timers fire waiting for a response). The negative- any internal timers fire waiting for a response). The negative-
delivery notification is constructed according to Section 7.2.1.1. delivery notification is constructed according to Section 7.2.1.1.
The message is then placed as the payload in a SIP MESSAGE request. The message is then placed as the payload in a SIP MESSAGE request.
skipping to change at page 26, line 52 skipping to change at page 26, line 44
constructed and sent an non-2xx final response, it MUST NOT generate constructed and sent an non-2xx final response, it MUST NOT generate
a negative-delivery notification. a negative-delivery notification.
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 read notification, and that IM Recipient has constructed requested a read notification, and that IM Recipient has constructed
and sent a SIP 2xx class response, it MAY generate a read and sent a SIP 2xx class response, it MAY generate a read
notification after making sure that the IM has been presented to the notification after making sure that the IM has been presented to the
user or application. It is outside the scope of this document how user or application. It is outside the scope of this document how
such determination can be made. Note that the option to send a read such determination can be made. Note that the option to send a read
notification or not can be left to the user. An application may notification or not can be left to the user. An application may
allow a user to configure such choice. The read notification is allow a user to configure such choice. The IM Recipient constructs
constructed according to Section 7.2.1.2. The message is then placed the read notification according to Section 7.2.1.2. The IM Recipient
as the payload in a SIP MESSAGE request. places the message as the payload in a SIP MESSAGE request.
For IMDNs, the SIP Request-URI and the SIP To header field are For IMDNs, the IM Recipient populates the SIP Request-URI and the SIP
populated using the address that appeared in the SIP From header To header field using the address that appeared in the SIP From
field in the IM. header field in the IM.
12.1.3.2. Delivery Notification 12.1.3.2. Delivery Notification
A SIP MESSAGE request is identified as delivery notification by A SIP MESSAGE request is identified as delivery notification by
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, application servers (including URI-List servers and In this context, intermediaries include application servers,
Store-and-Forward server) and gateways are defined as intermediaries. 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.
A SIP MESSAGE request to multiple recipients is forwarded according Intermediaries forward a SIP MESSAGE request to multiple recipients
to [13]. according to [13].
If an intermediary generates a SIP 2xx class response to a SIP If an intermediary receives a SIP 2xx class response to a SIP MESSAGE
MESSAGE request it has received that is an IM, it examines if the request that is an IM, it examines if the body is of type "message/
body was of type "message/cpim". If so, it checks the CPIM header to cpim". If so, it checks the CPIM header to see if there is the
see if there is the header field Disposition-Notification with a header field Disposition-Notification with a value "positive-
value "positive-delivery" and/or "negative-delivery". If so, it MUST delivery" and/or "negative-delivery". If so, it MUST send a delivery
send a delivery notification after receiving a transactional final notification after receiving a transactional final response for the
response for the IM. IM.
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 This is in anticipation of a failure downstream after a 2xx response
has been generated. has been generated.
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
skipping to change at page 28, line 43 skipping to change at page 28, line 36
sender. sender.
IMDN use cases for MSRP have not been fully explored. If new IMDN use cases for MSRP have not been fully explored. If new
requirements arise in the future determining the need for IMDN in requirements arise in the future determining the need for IMDN 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 IMDNs are carried by using the IM protocol itself, 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.
The threats in the IMDN system, over and beyond the threats inherent The threats in the IMDN system, over and beyond the threats inherent
to IM include the following: to IM include the following:
o A malicious endpoint attempts to send messages to a user that o A malicious endpoint attempts to send messages to a user that
would normally not wish to receive messages from that endpoint by would normally not wish to receive messages from that endpoint by
convincing the IMDN system to "bounce" an IMDN from an convincing the IMDN system to "bounce" an IMDN from an
unsuspecting endpoint to the user. unsuspecting endpoint to the user.
o A malicious endpoint attempts to flood a IM Sender with IMDNs by o A malicious endpoint attempts to flood a 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 a IM Recipient. from a 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 fish for a Request-URI of an
endpoint beyond an intermediary , where the endpoint would endpoint beyond an intermediary , where the endpoint would
normally wish to keep its identity private from the malicious normally wish to keep its identity private from the malicious
endpoint. 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
downstream endpoint that would not normally wish its identity downstream endpoint that would not normally wish its identity
revealed. Keeping such information private is an intermediary revealed. Keeping such information private is an intermediary
implementation issue. implementation issue.
o A malicious IM Recipient that alters the time of the IMDN. There o A malicious IM Recipient that alters the time of the IMDN. There
is no protocol mechanism for ensuring that the IM Recipient does is no protocol mechanism for ensuring that the IM Recipient does
not lie about the time or purposely holds an IMDN for transmission not lie about the time or purposely holds an IMDN for transmission
to make it appear that the user read an IM later than they to make it appear that the user read an IM later than they
actually did. actually did.
o A deletion attack on an IMDN. This is a trade-off between privacy o A deletion attack on an IMDN. This is a trade-off between privacy
and security. The privacy considerations allow the IM Recipient and security. The privacy considerations allow the IM Recipient
to silently ignore an IMDN request. Any mechanism that would to silently ignore an IMDN request. Any mechanism that would
reliably indicate that a malicious node deleted a IM Recipient's reliably indicate that a malicious node deleted a IM Recipient's
IMDN would also serve the purpose of detecting a IM Recipient that IMDN would also serve the purpose of detecting a IM Recipient that
chose not to issue an IMDN. chose not to issue an IMDN.
To combat eavesdropping, modification, and man-in-the-middle attacks, To combat eavesdropping, modification, and man-in-the-middle attacks,
we require some level of authentication and integrity protections. we require some level of authentication and integrity protections.
That said, there are circumstances where strong integrity would be That said, there are circumstances where strong integrity would be
skipping to change at page 30, line 15 skipping to change at page 29, line 49
reliably indicate that a malicious node deleted a IM Recipient's reliably indicate that a malicious node deleted a IM Recipient's
IMDN would also serve the purpose of detecting a IM Recipient that IMDN would also serve the purpose of detecting a IM Recipient that
chose not to issue an IMDN. chose not to issue an IMDN.
To combat eavesdropping, modification, and man-in-the-middle attacks, To combat eavesdropping, modification, and man-in-the-middle attacks,
we require some level of authentication and integrity protections. we require some level of authentication and integrity protections.
That said, there are circumstances where strong integrity would be That said, there are circumstances where strong integrity would be
overkill. The presumption is the IM Sender has and sets the overkill. The presumption is the IM Sender has and sets the
expectation for the level of protection. The procedures for expectation for the level of protection. The procedures for
integrity protection are as follows. integrity protection are as follows.
o If the IM Recipient has a certificate, it MUST sign the IMDN. o If the IM Recipient has a certificate, it MUST sign the IMDN.
Signing the IMDN provides integrity protection. While an
intermediary can replace the IMDN body, the IM Sender (the
recipient of the IMDN) can validate the signature and note the
IMDN does not come directly from the IM Receiver. This is not a
problem if the IM Sender trusts the intermediary. Likewise, an
IMDN in response to a signed IM without a signature indicates
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
of CPIM. In order to make the IMDN mechanism independent of the
transport protocol, the Work Group made the design choice of putting
routing information into the IMDN application layer payload. One
consequence of this choice is it eliminates the possibility of 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 31, line 29 skipping to change at page 31, line 24
to issue an IMDN, such as in the health care field or financial to issue an IMDN, such as in the health care field or financial
community. community.
An IM Recipient can obtain such consent by a prompt or dialog box on An IM Recipient can obtain such consent by a prompt or dialog box on
a per-IM basis, globally through the user's setting of a preference, a per-IM basis, globally through the user's setting of a preference,
or other, user-configurable mechanism. The user might also indicate or other, user-configurable mechanism. The user might also indicate
globally that IMDNs are never to be sent or that a "forbidden" IMDN globally that IMDNs are never to be sent or that a "forbidden" IMDN
status is always sent in response to a request for an IMDN. status is always sent in response to a request for an IMDN.
There are situations where a user sends an IM and requests IMDNs to a There are situations where a user sends an IM and requests IMDNs to a
list who's member information is not disclosed. In this situation, list whose member information is not disclosed. In this situation,
the user will learn of the list members. Therefore, in this case, the user will learn of the list members. Therefore, in this case,
the URI-List server MUST remove any information about list members. the URI-List server MUST remove any information about list members.
If the number of members in the list is also not disclosed, the URL- If the number of members in the list is also not disclosed, the URL-
List server MUST only deliver one aggregated IMDN. Alternatively, List server MUST only deliver one aggregated IMDN. Alternatively,
the URI-list server MAY reject the IM. the URI-list server MAY reject the IM.
It is possible for a list server to not understand IMDN. IM
Recipients may note the To is a list name and not the IM Recipient's
name. In this case, the IM Recipient can take the appropriate action
if it wishes to keep its identity private.
An unencrypted IMDN could reveal confidential information about an An unencrypted IMDN could reveal confidential information about an
encrypted IM. It is a MUST that the same level of security applied encrypted IM. The same level of security applied to an IM MUST be
to an IM to be applied to its IMDNs. For example, if an IM is signed applied to its IMDNs. For example, if an IM is signed and encrypted,
and encrypted, and IMDN must also be signed and encrypted. and IMDN must also be signed and encrypted.
14.3. Non-Repudiation 14.3. Non-Repudiation
IMDNs cannot be relied on as a guarantee that an IM was or was not IMDNs cannot be relied on as a guarantee that an IM was or was not
seen by the user. Even if IMDNs are not actively forged, they may be seen by the user. Even if IMDNs are not actively forged, they may be
lost in transit. The IMDN issuing mechanism may be bypassed in some lost in transit. The IMDN issuing mechanism may be bypassed in some
manner by the IM Recipient. manner by the IM Recipient.
15. IANA Considerations 15. IANA Considerations
skipping to change at page 34, line 6 skipping to change at page 34, line 4
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:
Disposition-Notification - [RFCXXXX] Disposition-Notification - [RFCXXXX]
Message-ID - [RFCXXXX] Message-ID - [RFCXXXX]
Original-To - [RFCXXXX] Original-To - [RFCXXXX]
IMDN-Record-Route - [RFCXXXX] IMDN-Record-Route - [RFCXXXX]
IMDN-Route - [RFCXXXX]. IMDN-Route - [RFCXXXX]
15.6. Content-Disposition: notification 15.6. Content-Disposition: notification
This document registers one new Content-Disposition header field This document registers one new Content-Disposition header field
"disposition-types": notification. The authors request that this "disposition-types": notification. The authors request that this
values be recorded in the IANA registry for Content-Dispositions. value be recorded in the IANA registry for Content-Dispositions.
Descriptions of this "disposition-types", including motivation and Descriptions of this "disposition-types", including motivation and
examples, are given in Section 7.2.1.1 and Section 9. examples, are given in Section 7.2.1.1 and Section 9.
Short descriptions suitable for the IANA registry are: Short descriptions suitable for the IANA registry are:
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 and Robert Sparks for their comments Eric McMurry, Jari Urpalainen, Jon Peterson, and Robert Sparks for
and support. their comments and support.
17. References 17. References
17.1. Normative References 17.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging [2] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging
(CPIM): Message Format", RFC 3862, August 2004. (CPIM): Message Format", RFC 3862, August 2004.
[3] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. [3] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
[4] Moats, R., "The URN Syntax", RFC 2141, May 1997. [4] Moats, R., "The URN Syntax", RFC 2141, May 1997.
[5] Murata, M., "XML Media Types", RFC 3023, March 1997. [5] Murata, M., "XML Media Types", RFC 3023, March 1997.
[6] Bray, T., "Extensible Markup Language (XML) 1.0 (Second [6] 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, "URI: Generic [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Syntax", RFC 3023, August 1998. Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
17.2. Informative References 17.2. Informative References
[8] Rosenberg et al., J., Shulzrinne, H., Camarillo, G., Johnston, [8] Rosenberg et al., J., Shulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler,
"SIP: Session Initiation Protocol", RFC 3261, June 2002. "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[9] Campbell, B., "SIP Extension for Instant Messaging", RFC 3428, [9] Campbell, B., "SIP Extension for Instant Messaging", RFC 3428,
December 2002. December 2002.
[10] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [10] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[11] Hansen, T. and G. Vaudreuil, "Message Disposition [11] 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, [12] Moats, R., "The URN Namespace for IETF Documents", RFC 2648,
August 1999. August 1999.
[13] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE [13] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE
Requests in SIP", draft-ietf-sip-uri-list-message-01.txt, Requests in the Session Initiation Protocol (SIP)",
January 2007. 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
 End of changes. 118 change blocks. 
250 lines changed or deleted 282 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/