draft-ietf-simple-imdn-00.txt   draft-ietf-simple-imdn-01.txt 
SIMPLE E. Burger SIMPLE E. Burger
Internet-Draft Cantata Technology Internet-Draft Cantata Technology
Expires: November 27, 2006 H. Khartabil Intended status: Informational H. Khartabil
Telio Expires: April 16, 2007 Telio
May 26, 2006 October 13, 2006
Instant Message Disposition Notification Instant Message Disposition Notification
draft-ietf-simple-imdn-00 draft-ietf-simple-imdn-01
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 35 skipping to change at page 1, line 35
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 27, 2006. This Internet-Draft will expire on April 16, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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. users in real-time. This document provides a mechanism whereby
endpoints can request Instant Message Disposition Notifications
(IMDN), including delivery, processing and read notifications, for
page-mode as well as session mode instant messages.
This document extends Message/CPIM message format to enable endpoints The Common Profile for Instant Messaging (CPIM) data format specified
to request, create and send IM Disposition Notifications (IMDN), in RFC 3862 is extended with new headers that enable endpoints to
including delivery and read notifications, for page-mode as well as request IMDNs. A new message format is also defined to convey IMDNs.
session mode instant messages. This document also describes how SIP
and MSRP entities behave using this extension. This document also describes how SIP and MSRP entities behave using
this extension.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Disposition States . . . . . . . . . . . . . . . . . . . . 5 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. delivered . . . . . . . . . . . . . . . . . . . . . . 5 5. Disposition Types . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. read . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Endpoints Behaviour . . . . . . . . . . . . . . . . . . . . . 5 5.2. Processing . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Constructing Instant Messages . . . . . . . . . . . . . . 5 5.3. Read . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Constructing IMDNs . . . . . . . . . . . . . . . . . . . . 6 6. New CPIM Header Fields . . . . . . . . . . . . . . . . . . . . 7
4.2.1. Constructing Delivery Notification . . . . . . . . . . 7 6.1. CPIM Header Namespace . . . . . . . . . . . . . . . . . . 7
4.2.2. Constructing Read Notification . . . . . . . . . . . . 8 6.2. Disposition-Notification . . . . . . . . . . . . . . . . . 8
4.3. Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 8 6.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Keeping State . . . . . . . . . . . . . . . . . . . . . . 9 6.4. Original-To . . . . . . . . . . . . . . . . . . . . . . . 8
5. Intermediary Behaviour . . . . . . . . . . . . . . . . . . . . 9 6.5. IMDN-Record-Route . . . . . . . . . . . . . . . . . . . . 8
5.1. Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 10 6.6. IMDN-Route . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Identifying Messages . . . . . . . . . . . . . . . . . . . . . 11 7. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . . . 9
7. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. IM Sender . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. CPIM Header Namespace . . . . . . . . . . . . . . . . . . 11 7.1.1. Constructing Instant Messages . . . . . . . . . . . . 9
7.2. Disposition-Notification . . . . . . . . . . . . . . . . . 12 7.1.2. Matching IMs with IMDNs . . . . . . . . . . . . . . . 10
7.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1.3. Aggregation of IMDNs . . . . . . . . . . . . . . . . . 10
7.4. Original-To . . . . . . . . . . . . . . . . . . . . . . . 12 7.1.4. Keeping State . . . . . . . . . . . . . . . . . . . . 11
7.5. Really-From . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. IM Recipient . . . . . . . . . . . . . . . . . . . . . . . 12
7.6. Really-To . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2.1. Constructing IMDNs . . . . . . . . . . . . . . . . . . 12
8. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 12 8. Intermediary Behaviour . . . . . . . . . . . . . . . . . . . . 14
9. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Constructing Processing Notifications . . . . . . . . . . 15
9.1. Structure of XML-Encoded imdn . . . . . . . . . . . . . . 13 8.2. Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 16
9.1.1. The <message-id> Element . . . . . . . . . . . . . . . 13 9. Identifying Messages . . . . . . . . . . . . . . . . . . . . . 17
9.1.2. The <datetime> Element . . . . . . . . . . . . . . . . 13 10. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 17
9.1.3. The <recipient-uri>; Element . . . . . . . . . . . . . 14 11. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1.4. The <original-recipient-uri>; Element . . . . . . . . 14 11.1. Structure of XML-Encoded IMDN Payload . . . . . . . . . . 18
9.1.5. The <subject>; Element . . . . . . . . . . . . . . . . 14 11.1.1. The <message-id> Element . . . . . . . . . . . . . . . 18
9.1.6. The <disposition> Element . . . . . . . . . . . . . . 14 11.1.2. The <datetime> Element . . . . . . . . . . . . . . . . 19
9.1.7. The <status> Element . . . . . . . . . . . . . . . . . 14 11.1.3. The <recipient-uri> Element . . . . . . . . . . . . . 19
9.1.8. The <note> Element . . . . . . . . . . . . . . . . . . 14 11.1.4. The <original-recipient-uri> Element . . . . . . . . . 19
9.2. MIME Type for imdn Document . . . . . . . . . . . . . . . 14 11.1.5. The <subject> Element . . . . . . . . . . . . . . . . 19
9.3. The XML Schema . . . . . . . . . . . . . . . . . . . . . . 15 11.1.6. The <disposition> Element . . . . . . . . . . . . . . 19
10. Transporting Message/CPIM messages using SIP . . . . . . . . . 15 11.1.7. The <status> Element . . . . . . . . . . . . . . . . . 19
10.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 15 11.1.8. The <note> Element . . . . . . . . . . . . . . . . . . 20
10.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 15 11.2. MIME Type for IMDN Paylaod . . . . . . . . . . . . . . . . 20
10.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 15 11.3. The RelaxNG Schema . . . . . . . . . . . . . . . . . . . . 20
10.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 15 12. Transporting Messages using SIP . . . . . . . . . . . . . . . 23
10.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 16 12.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 24
11. Transporting Message/CPIM messages using MSRP . . . . . . . . 17 12.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 24
11.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 17 12.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 24
11.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 17 12.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 24
11.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 18 12.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 25
11.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 18 13. Transporting Messages using MSRP . . . . . . . . . . . . . . . 26
11.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 18 13.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 26
12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 13.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 26
12.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 21 13.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 27
12.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 21 13.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 27
12.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 22 13.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 27
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 14. Security Considerations . . . . . . . . . . . . . . . . . . . 28
13.1. message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 22 14.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 30
13.2. URN Sub-Namespace Registration for 14.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 30
urn:ietf:params:xml:ns:imdn . . . . . . . . . . . . . . . 23 14.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 31
13.3. Schema Registration . . . . . . . . . . . . . . . . . . . 23 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
13.4. Message/CPIM Header Field registration . . . . . . . . . . 23 15.1. message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 31
13.5. Content-Disposition: notification . . . . . . . . . . . . 24 15.2. URN Sub-Namespace Registration for
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 urn:ietf:params:xml:ns:imdn . . . . . . . . . . . . . . . 32
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 15.3. Schema Registration . . . . . . . . . . . . . . . . . . . 32
15.1. Normative References . . . . . . . . . . . . . . . . . . . 24 15.4. Message/CPIM Header Field registration . . . . . . . . . . 32
15.2. Informative References . . . . . . . . . . . . . . . . . . 24 15.5. Content-Disposition: notification . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 27 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
17.1. Normative References . . . . . . . . . . . . . . . . . . . 33
17.2. Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 35
1. Introduction 1. Introduction
In many user-to-user message exchange systems, message senders often In many user-to-user message exchange systems, message senders often
wish to know if the human recipient actually received or read a wish to know if the human recipient actually received or read a
message. message.
Electronic Mail [12] deals with this situation with Message Delivery Electronic Mail [12] deals with this situation with Message Delivery
Notifications [13]. After the recipient views the message, her mail Notifications [13]. 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 RFC2298 [13]. MDN is an e-mail that follows the format prescribed by RFC2298 [13].
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 [9] can carry instant messages generated using messages. SIP [9] can carry instant messages generated using
message/CPIM in SIP MESSAGE requests [10]. The MSRP [11] SEND message/CPIM in SIP MESSAGE requests [10]. The MSRP [11] SEND
message can also be used to carry Message/CPIM messages. request can also be used to carry Message/CPIM messages.
This document extends Message/CPIM message format to enable endpoints This document extends Message/CPIM message format (much like Message
to request, create and send Instant Message Disposition Notifications Delivery Notifications [13] extends Electronic Mail [12]) to enable
(IMDN) for a page-mode as well as session mode instant messages. Instant Message Senders to request, create and send Instant Message
IMDNs include positive delivery and read notifications as well as Disposition Notifications (IMDN) for a page-mode as well as session
negative delivery notifications (i.e. a message did not get delivered mode instant messages. IMDNs include positive delivery, negative
successfully). By using a CPIM headers, the IMDN request and delivery (i.e. a message did not get delivered successfully), read
delivery are abstracted outside the transport protocol allowing notifications as well as processed notifications. By using CPIM
interoperability between different IM systems. Likewise, the headers, the IMDN request and delivery are abstracted outside the
mechanism does not rely on session-mode versus pager-mode. transport protocol allowing interoperability between different IM
systems. Likewise, the mechanism does not rely on session-mode
versus page-mode.
This document also describes how SIP and MSRP entities behave using This document also describes how SIP and MSRP entities behave using
this extension. this extension.
2. Conventions 2. Conventions
In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED', In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED',
'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY',
and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] and and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] and
indicate requirement levels for compliant implementations. indicate requirement levels for compliant implementations.
3. Overview 3. Terminology
The basic protocol flow is as follows. A message sender marks a o IM: An Instant Message generated using the Message/CPIM format.
message for disposition notification. At a certain point in time,
the recipient user agent or an intermediary determines the recipient o IMDN: An Instant Message Disposition Notification generated using
has received, did not receive or has read the message or otherwise the Message/CPIM format that carries a IMDN XML document.
disposed the message. The mechanism by which an instant message user
agent determines its user has read a message is beyond the scope of o Message: an IM or an IMDN generated using the Message/CPIM format.
this document. At that point, the recipient user agent or
intermediary automatically generates a notification message to the o IM Sender: An endpoint (User Agent) generating and sending an IM.
sender. This notification message is the Instant Message Disposition It is also the endpoint that requests IMDNs for an IM. Quite
often, the IM Sender is the IMDN Recipient, but that is not always
true.
o IM Recipient: An endpoint (User Agent) that receives IMs. It is
also the endpoint that generates and sends IMDNs to IMs, if
requested by the IM Sender.
o Endpoint: An IM Sender or an IM Recipient.
o Intermediary: An entity in the network that is on the path of an
IM to its final destination.
o IMDN Payload or XML Document: An XML document carrying the
disposition notification information. It is always of MIME type
"message/imdn+xml".
o Disposition type: the type of IMDN that can be requested. This
specification defines three, namely "delivery", "processing" and
"read" disposition types.
o Transport Protocol Message: An IM or an IMDN wrapped in a
transport protocol like SIP or MSRP.
4. Overview
The basic protocol flow is depicted in the diagram below. An IM
Sender creates an IM, adds to it IMDN request information it is
interested in receiving, then sends its. At a certain point in time,
the IM Recipient or an intermediary determines that the user or
application has received, did not receive or has read the IM or
otherwise 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 that point, the IM Recipient or intermediary
automatically generates a notification message to the IM Sender.
This notification message is the Instant Message Disposition
Notification (IMDN). Notification (IMDN).
3.1. Disposition States +--------------+ +--------------+
| IM Sender | | IM Recipient |
|IMDN Recipient| | IMDN Sender |
+--------------+ +--------------+
| |
| |
| 1. IM requesting IMDN |
|-------------------------------------->|
| |
| |
| 2. IMDN (disposition) |
|<--------------------------------------|
| |
| |
There are two broad categories of disposition states. They are Note that the recipient of an IMDN, in some instances, may not be the
delivered and read. Future extensions may introduce others 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
IMDN, resolves to a different location to where the IM originated.
For simplicity, the rest of this document assumes that the IM Sender
and the IMDN Recipient are the same and therefore will refer to both
as the IM Sender.
3.1.1. delivered 5. Disposition Types
The "delivered" state indicates whether the Recipient has received There are three broad categories of disposition states. They are
the instant message or not (positive or negative delivery). delivery, processing and read. Future extensions may introduce
others.
3.1.2. read 5.1. Delivery
The "read" state indicates whether the Recipient displayed the The delivery notification type indicates whether the IM has been
instant message to the user or not. delivered to the IM Recipient or not. The delivery notification type
can have the following states:
o "delivered" to indicate successful delivery.
o "failed" to indicate failure in delivery.
o "forbidden" indicate denial by the IM Recipient for the IM Sender
to receive the requested IMDN.
o "error" to indicate an error in determining the fate of an IM.
5.2. Processing
The processing notification type indicates that an IM has been
processed by an intermediary. The processing notification type can
have the following states:
o "processed" is a general state of the IM indicating it has been
processed.
o "stored" state indicates that the IM has been stored by the
intermediary for later delivery.
o "forbidden" indicate denial by the IM Recipient for the IM Sender
to receive the requested IMDN.
o "error" to indicate an error in determining the fate of an IM.
5.3. Read
The read notification type indicates whether the IM Recipient
displayed the IM to the user or not. The read notification type can
have the following states:
o "read" is a state indicating that the IM has been read.
o "forbidden" indicate denial by the IM Recipient for the IM Sender
to receive the requested IMDN.
o "error" to indicate an error in determining the fate of an IM.
Since there is no positive acknowledgement from the user, one cannot Since there is no positive acknowledgement from the user, one cannot
determine a priori the user actually read the message. Thus one MUST determine a priori that the user actually read the IM. Thus one MUST
NOT use the protocol described here as a non-repudiation service. NOT use the protocol described here as a non-repudiation service.
4. Endpoints Behaviour 6. New CPIM Header Fields
4.1. Constructing Instant Messages 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
headers.
A Message/CPIM formatted instant message is constructed using RFC 6.1. CPIM Header Namespace
3862 [2]. The content-type header field indicates the MIME type of
the request payload.
In this extension, the Message/CPIM IM MAY contain a Message-ID Per CPIM [2], this specification defines a new namespace for the CPIM
header field if an IMDN is requested. The Message-ID field is extension headers defined in the following sections. The namespace
populated with a value that is unique in space and time. This header is: urn:ietf:params:cpim-headers:imdn As per CPIM [2] requirements,
field enables the message sender to match any notifications with the new headers defined in the following sections are prepended by
their corresponding IMs. This header need not be present if the the string "imdn." in CPIM messages.
instant message sender is not requesting any IMDNs or if no state of
any kind is kept for an IM.
The recipient on an IMDN may not be the same user agent that sent the 6.2. Disposition-Notification
instant message. This is specifically true for page-mode instant
messages where the Address of Record (AOR) of the IM sender present
in the IMDN resolves to a different location to where the IM
originated. Also, some devices may not implement the concept of
"Sent Items" box and therefore no information about an IM is stored.
It is therefore necessary to add a time stamp in the IM to indicate
when it was sent in order to enable the human user to correlate the
IM with the IMDN. This time stamp is returned in the IMDN in order
to enable the user to correlate the IM with the IMDN at the human
level. The message/CPIM DateTime header field is used for this
purpose. The message/CPIM IM MUST contain a DateTime header field if
an IMDN is requested.
In this specification, the sender can request two types of delivery The Disposition-Notification header field is used by the IM Sender to
notifications: a failure delivery notification and a success delivery indicate the desire to receive IMDNs, from the IM Recipient, for that
notification. A failure delivery notification is requested by specific IM. This header field is not needed if the IM Sender does
including a Disposition-Notification header field with value not request an IMDN. The syntax is defined in Section 10.
"negative-delivery". Similarly, a success notification is requested
by including a Disposition-Notification header field with value
"positive-delivery". Both types of notifications can be requested
for the same message.
The sender can also request a read notification. It is requested by 6.3. Message-ID
including a Disposition-Notification header field with value "read".
The Message-ID header field contains a globally unique message
identifier that is used by the IM Sender to correlate received IMDNs
by comparing its value with the value of the <message-id> element
present in the IMDN payload. This header field is mandatory with
sending an IM and requesting an IMDN. IMDNs also carry this header
field. The syntax is defined in Section 10.
6.4. Original-To
The Original-To header field is sometimes added to an IM by an
intermediary and populated with of the address of the IM Sender. It
is used by the IM Recipient to indicate in the IMDNs (by populating
the <original-recipient-uri> element) the original address the IM was
sent to. This header is mandatory if the intermediary changes the
CPIM To header field value. The header MUST NOT appear more than
once in an IM. The header field value MUST NOT be changed by an
intermediary if it was already present. The syntax is defined in
Section 10.
6.5. IMDN-Record-Route
Intermediaries have the capability of indicating that IMDNs should be
sent through it (otherwise, IMDNs will not visit the intermediary).
An intermediary that request IMDNs to be sent through itself adds an
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
The IMDN-Route header field provides routing information by including
one or more addresses where an IMDN must be routed through. On
creating an IMDN, an IM recipient copies the contents of the IMDN-
Record-Route present in the IM into the IMDN-Route of the IMDN.
Multiple IMDN-Route header fields can appear in an IMDN. The syntax
is defined in Section 10.
7. Endpoint Behaviour
7.1. IM Sender
7.1.1. Constructing Instant Messages
An IM is constructed using RFC 3862 [2]. The Content-type header
field indicates the MIME type of the request payload.
7.1.1.1. Adding a Message-ID Header Field
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
with a value that is unique with 32 bits of randomness. This header
field enables the IM Sender to match any IMDNs with their
corresponding IMs.
7.1.1.2. Adding a DateTime Header Field
Some devices may not implement the concept of "Sent Items" box and
therefore no information about an IM is stored. It is therefore
necessary to add a time stamp in the IM to indicate when it was sent.
This time stamp is returned in the IMDN in order to enable the user
to correlate the IM with the IMDN at the human level. The DateTime
header field is used for this purpose. The IM MUST contain a
DateTime header field if an IMDN is requested.
7.1.1.3. Adding a Disposition-Notification Header Field
In this specification, the IM Sender can request two types of
delivery notifications: a failure delivery notification and a success
delivery notification. An IM Sender requests failure delivery
notification by including a Disposition-Notification header field
with value "negative-delivery". Similarly, a success notification is
requested by including a Disposition-Notification header field with
value "positive-delivery". Both types of delivery notifications can
be requested for the same IM.
The IM Sender can request a processing notification by including a
Disposition-Notification header field with value "processing".
The IM Sender can also request a read notification. It is requested
by including a Disposition-Notification header field with value
"read".
The absence of this header or the presence of the header with empty The absence of this header or the presence of the header with empty
value indicates that the sender is not requesting any IMDNs. This value indicates that the IM Sender is not requesting any IMDNs. The
aids receivers of instant messages that do not support this feature. Disposition-Notification header fields can be comma separated.
The Disposition-Notification header fields can be comma separated.
Future extension may define other disposition notifications not Future extension may define other disposition notifications not
defined in this document. The IM sender MAY request more than one defined in this document. The IM Sender MAY request more than one
kind of IMDN for a single IM. type of IMDN for a single IM.
The formal syntax of the Disposition-Notification header field can be The formal syntax of the Disposition-Notification header field can be
found in Section 8. The following in an example Message/CPIM instant found in Section 10. The following in an example IM where the IM
message where the user requests positive and negative delivery Sender requests positive and negative delivery notifications, but not
notifications, but not read notification: read notification nor processing notifications:
Content-type: Message/CPIM Content-type: Message/CPIM
From: Alice <im:alice@example.com> From: Alice <im:alice@example.com>
To: Bob <im:bob@example.com> To: Bob <im:bob@example.com>
Message-ID: 34jk324j NS: imdn <urn:ietf:params:cpim-headers:imdn>
imdn.Message-ID: 34jk324j
DateTime: 2006-04-04T12:16:49-05:00 DateTime: 2006-04-04T12:16:49-05:00
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
4.2. Constructing IMDNs 7.1.2. Matching IMs with IMDNs
As indicated earlier, an endpoint sending an IM may choose to request An IM Sender matches an IMDN to an IM by matching the Message-ID
more than one type of IMDN for a single IM, For example a delivery header field value in the IM with the <message-id> element value in
notification as well as a read notification. In this case the the body of the IMDN. If the IM was delivered to multiple
endpoint constructing IMDNs MUST be able to construct multiple IMDNs recipients, the IM Sender uses the <recipient-uri> element or the
per IM. <original-recipient-uri> element in the XML body of the IMDN it
received to identify the IM Recipient (IMDN Sender).
Disposition-Notification header MUST NOT appear in a Message/CPIM 7.1.3. Aggregation of IMDNs
message that represents an IMDN since it does not make sense and is
therefore forbidden to request an IMDN for an IMDN. The recipient of
the IMDN MUST ignore it if present.
An IMDN SHOULD NOT contain a Message-ID header field since it is used An IM Sender may send an IM to multiple recipients in one Transport
for matching an instant message with its IMDNs and no IMDNs are ever Protocol Message (typically using a URI-List server) and request
requested for IMDNs. The recipient of the IMDN MUST ignore the IMDNs. It MAY choose to either get one IMDN from each IM Recipient
Message-ID header field if present. individually or get an aggregated IMDN (the URI-List server
aggregates the IMDNs and send the one or more aggregated IMDNs). The
IM Sender requests aggregation by adding the Disposition-Notification
header field parameter "aggregate". The absence of such a parameter
indicates that the IM Sender does not wish for IMDNs to be
aggregated. Aggregation can be requested per disposition type. For
example, a IM Sender can request delivery notification to be
aggregated but read notifications to be sent individually. For
example:
If Really-From header fields appear in the IM, the endpoint Disposition-Notification: positive-delivery;aggregate, read
constructing the IMDN MUST copy the contents of the Really-From The following is an example of an IM Sender requesting aggregation of
header fields into Really-To header fields in the IMDN and maintain both positive delivery notifications and read notifications:
the order. The IMDN is then sent to the address in the top Really-To
header field.
4.2.1. Constructing Delivery Notification Disposition-Notification: positive-delivery;aggregate, read;aggregate
A delivery notification is constructed in a similar fashion as an An IM Sender that requested an aggregated IMDN MUST be prepared to
instant message, using RFC 3862 [2]. For delivery notifications, the receive multiple aggregated or non-aggregated IMDNs. See Section 8.2
content-type MUST be of type "message/imdn+xml". It is an XML for details.
document. The schema is described Section 9. The delivery
notification MUST contain a Content-Disposition header field with An IM Sender MUST be prepared to receive aggregated IMDNs even if it
value "notification". This indicates to the receiver that the did not request the URI-List server to do so. See again Section 8.2
contents of the message are a notification according to an earlier for details. Note that the "aggregate" parameter is a hint for
request for an IMDN to an instant message. intermediaries and does not require the intermediaries to aggregate
IMDNs.
7.1.4. Keeping State
This specification does not mandate the IM Sender to keep state for a
sent IM.
Once an IM Sender sends an IM containing an IMDN request, it MAY
preserve the IM context, principally the Message-ID, and other user-
identifiable information such as the IM subject or content, and date
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.
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
power.
There is, however, the concept of "Sent Items" box in an application
that stores sent IMs. This "Sent Items" box has the necessary
information and may have a fancy user interface indicating the state
of a sent IM. Unique Message-ID for this purpose proves to be
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
items from the "Sent Items" box as she pleases or as the memory on
the device reaches capacity.
Clearly, if an IM Sender loses its sent items state (user deletes
items from the "Send Items" box), the client may use a different
display strategy in response to apparently unsolicited IMDNs.
This specification also does not mandate an IM Sender to run any
timers waiting for an IMDN. There are no time limits associated with
when IMDNs may be received.
IMDNs may legitimately never be received. On the other hand, and
IMDN may simply take a very long time. Some clients may choose to
purge the state associated with the sent IM. This is the reason for
adding the time stamp in the IM and having it returned in the IMDN.
This gives the user some opportunity of remembering what IM was sent.
For example if the IMDN indicates that the IM the user 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.2. IM Recipient
7.2.1. Constructing IMDNs
IM recipients examine the contents of the Disposition-Notification
header field of the CPIM message to determine if an IMDN must be
generated for that IM. Disposition-Notification header fields of
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,
for example a delivery notification as well as a read notification.
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
per disposition type. I.e. It must not, for example, generate a
delivery notification indicating "delivered" then followed by a
delivery notification indicating "failed" for the same IM. If the IM
Sender requested only failure notifications and the IM was
successfully delivered, then no IMDNs will be generated.
The IM Recipient MUST NOT generate processing notifications.
Disposition-Notification header MUST NOT appear in an IMDN since it
does not make sense and is therefore forbidden to request an IMDN for
an IMDN. IM Sender MUST ignore it if present. The IM Sender MUST
NOT send an IMDN to an IMDN.
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
apply to an IMDN.
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
IM Recipient constructing the IMDN MUST copy the contents of 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 address in
the top IMDN-Route header field.
7.2.1.1. Constructing Delivery Notifications
A delivery notification is constructed in a similar fashion as an IM,
using RFC 3862 [2]. For delivery notifications, the Content-type
MUST be of type "message/imdn+xml". It is an XML document. The
schema is described Section 11. The delivery notification MUST
contain a Content-Disposition header field with value "notification".
This indicates to the IM Sender that the message is an IMDN to an IM
it has earlier sent.
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>
NS: imdn <urn:ietf:params:cpim-headers:imdn>
imdn.Message-ID: d834jied93rf
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>bob@example.com</recipient-uri> <recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri>bob@example.com</original-recipient-uri> <original-recipient-uri>im:bob@example.com</original-recipient-uri>
<disposition>delivery</disposition> <disposition>
<status>success</status> <delivery/>
<note lang="en">The message was successfully Delivered</note> </disposition>
<status>
<delivered/>
</status>
<note lang="en">The IM was successfully Delivered</note>
</imdn> </imdn>
4.2.2. Constructing Read Notification 7.2.1.2. Constructing Read Notifications
A read notification is constructed in a similar fashion as the A read notification is constructed in a similar fashion as the
delivery notification. See Section 4.2.1 for details. 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>
NS: imdn <urn:ietf:params:cpim-headers:imdn>
imdn.Message-ID: dfjkleriou432333
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>bob@example.com</recipient-uri> <recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri>bob@example.com</original-recipient-uri> <original-recipient-uri>im:bob@example.com</original-recipient-uri>
<disposition>read</disposition> <disposition>
<status>success</status> <read/>
<note lang="en">The message has been read</note> </disposition>
<status>
<read/>
</status>
<note lang="en">The IM has been read</note>
</imdn> </imdn>
There are situations where the recipient user agent cannot determine There are situations where the IM Recipient cannot determine if or
if or when the message has been read. The recipient user agent in when the IM has been read. The IM Recipient in this case generates a
this case generates a read notification with a <status> value of read notification with a <status> value of "error" to indicate an
"error" to indicate an internal error by the server. internal error by the server.
4.3. Aggregation of IMDNs
An endpoint may send an instant message to multiple recipients in one 8. Intermediary Behaviour
transport protocol message (typically using a URI-List server) and
request IMDNs. If it does so, it MAY choose to either get one IMDN
from each recipient individually or get an aggregated IMDN (the URI-
List server aggregates the IMDNs and send the one aggregated IMDN).
The endpoint does so by adding the Disposition-Notification header
field parameter "aggregate". The absence of such a parameter
indicates that the endpoint does not want IMDNs aggregated.
Aggregation can be done per IMDN requested. For example, a IM sender
can request delivery notification to be aggregated but read reports
to be sent individually. For example:
Disposition-Notification: positive-delivery;aggregate, read In this context, application servers (including URI-List servers and
An endpoint that requested an aggregated IMDN MUST be prepared to Store-and-Forward server) and gateways are defined as intermediaries.
receive multiple aggregated IMDNs. See Section 5.1 for details.
An endpoint MUST be prepared to receive aggregated IMDNs even if it An intermediary that forwards an IM MAY change the recipient address
did not request the URI-List server to do so. See again Section 5.1 in the CPIM To header field when forwarding (for example, a URI-List
for details. Note that the "aggregate" parameter is a hint for server changes the IM Recipient address from its own to the address
intermediaries and does not require the intermediaries to aggregate of the final recipient of that IM for every copy it makes to be sent
IMDNs. to the list members). In this case, the intermediary MUST add an
Original-To header field to the IM populating it with the address
that was in the To header field before it was changed. I.e. The
Original-To header is populated with the intermediary address. An
intermediary MUST NOT add an Original-To header field if one already
exists.
4.4. Keeping State 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
field as the top IMDN-Record-Route header and populating it with its
own address. An intermediary that does not support this extension
will obviously not add the IMDN-Record-Route header. This allows
IMDNs to traverse directly from the IM Recipient to the IM Sender
even if the IM traversed an intermediary not supporting this
extension.
This specification does not mandate the sender of an IM to keep state An intermediary receiving an IMDN checks the top IMDN-Route header
for a sent IM. field. If that header field carries the intermediary address, the
intermediary pops that header and forwards the IMDN to the address
indicated in the now top IMDN-Route header. If no IMDN-Route headers
are present, the IMDN is forwarded to the address in the To header
field.
Once an endpoint sends an instant message with an IMDN request, it An intermediary MUST remove any information about the final
MAY preserve the message context, principally the Message-ID, and recipients of a list if the list membership is not disclosed. The
other user-identifiable information such as the message subject or intermediary does that by removing the <recipient-uri> element and/or
content, and date and time it was sent. Without preservation of the <original-recipient-uri> element from the body of the IMDN before
message context, the Requesting endpoint will not be able to forwarding it to the IM Sender.
correlate the IMDN with the outbound IM. The Requesting endpoint may
find it impossible to preserve message state if it has limited
resources or does not have non-volatile memory and then loses power.
There is, however, the concept of "Sent Items" box in an application 8.1. Constructing Processing Notifications
that stores sent messages. This "Sent Items" box has the necessary
information and may have a fancy user interface indicating the state
of a sent message. Unique Message-ID for this purpose proves to be
useful. How long to keep items in the "Sent Items" 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 the device
reaches capacity.
Clearly, if a requesting endpoint loses its sent items state (user Intermediaries are the only entities that construct processing
deletes items from the "Send Items" box, the client may use a notifications. They do so only if the IM Sender has requested a
different display strategy in response to apparently unsolicited processing notification by including a Disposition-Notification
IMDN's. header field with value "processing".
This specification also does not mandate an IM sender to run any The intermediary can create and send processing notifications
timers waiting for an IMDN. There are no time limits associated with indicating that an IM has been processed or stored. The intermediary
when disposition notifications may be received. MUST NOT send more than one IMDN for the same disposition type. I.e.
It must not send a processing notification indicating that an IM is
being "processed" followed by another IMDN indicating that the same
IM is "stored".
5. Intermediary Behaviour A processing notification is constructed in a similar fashion as the
delivery notification. See Section 7.2.1.1 for details.
In this context, application servers (including URI-List servers and An example looks like the following:
Store-and-Forward server) and gateways are defined as intermediaries.
An intermediary that forwards an IM may change the recipient address Content-type: Message/CPIM
in the CPIM To header field when forwarding (for example, a URI-List
server change the recipient address from its own to the address of
the final recipient of that message). In this case, the intermediary
MUST add a CPIM Original-To header to the CPIM message populating it
with the address of the sender.
An intermediary MAY choose to remain on the path of IMDNs for a From: Bob <im:bob@example.com>
specific IM. It can do so by adding a CPIM Really-From header field To: Alice <im:alice@example.com>
as the top Really-From header and populating it with its own address. Content-type: message/imdn+xml
This works well with intermediaries that don't support this extension Content-Disposition: notification
in that IMDNs would therefore traverse directly from receiver to Content-length: ...
sender or to intermediaries that do support the extension.
An intermediary receiving an IMDN checks the top Really-To header <imdn>
field. If that header field carries the intermediary address, the <message-id>34jk324j</message-id>
intermediary pops that header and forwards the IMDN to the address <datetime>2006-04-04T12:16:49-05:00</datetime>
indicated in the now top Really-To header. <recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri>im:bob@example.com</original-recipient-uri>
<disposition>
<processing/>
</disposition>
<status>
<processed/>
</status>
<note lang="en">The IM has been processed</note>
</imdn>
An intermediary MUST remove any information about the final There are situations where the intermediary cannot know the fate of
recipients of a list if the list membership is not disclosed. The an IM. The intermediary in this case generates a processing
intermediary does that by removing the <recipient-uri> element from notification with a <status> value of "error" to indicate so.
the body of the IMDN before forwarding it to the IM sender.
5.1. 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.
When a URI-List server receives an instant message, it needs to When a URI-List server receives an IM, it needs to examine
examine Disposition-Notification header fields. If an IMDN request Disposition-Notification header fields. If an IMDN request contains
contains the "aggregate" parameter, the URI-List server MUST wait for the "aggregate" parameter, the URI-List server MUST wait for a
a configurable period of time or until all recipients have sent the configurable period of time or until all recipients have sent the
IMDN (whichever comes first) before the URI-List server sends an IMDN (whichever comes first) before the URI-List server sends an
aggregated IMDN. Note that some IMDNs, for example read 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. A URI-List server may choose to send removes state for that IM.
multiple aggregated IMDNs even if the requester asked for one
aggregated IM. A 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 aggregated IMDN and restart the timer for the next batch.
This is needed for scenarios where the IM sender has requested more
than one IMDN for a specific IM, for example, delivery notifications
as well as read notifications, or when the URI-List server is short
on resources and chooses to prioritise forwarding IMs over IMDNs. 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 that
might arrive after that time.
A URI-List server MAY aggregate IMDNs even if the IM sender did not A URI-List server MAY choose to send multiple aggregated IMDNs even
request from it to do so. This is to handle the case where the list if the requester asked for one aggregated IM. A timer can be started
membership information is not disclosed. and when it fires, the URI-List server can aggregate whatever IMDNs
it has so far for that IM, send the aggregated IMDN and restart the
timer for the next batch. This is needed for scenarios where the IM
Sender has requested more than one IMDN for a specific IM, for
example, delivery notifications as well as read notifications, or
when the URI-List server is short on resources and chooses to
prioritise forwarding IMs over IMDNs. 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 that might arrive after that time.
A URI-List server MAY aggregate IMDNs even if the IM Sender did not
request it to do so. This is to handle the case where the list
membership information is not disclosed. The URI-List server MAY
also choose to ignore an aggregation request and send individual
IMDNs instead.
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.
There are scenarios where an intermediary needs to generate IMDNs, There are scenarios where an intermediary needs to generate IMDNs,
see Section 10.2 for further details. see Section 12.2 for further details.
6. Identifying Messages
Message/CPIM messages are typically carried in a transport protocol
like SIP [9]. In the case of a "message/cpim" body in the request of
the transport protocol, the message is an instant message if the
content-type header field present in the message/cpim body has a
value that is NOT "message/imdn+xml".
A Message/CPIM message is identified as a delivery notification by
examining its contents. In the case of a message/cpim body, the
message is a delivery notification if: the content-type header field
present in the message/cpim body has a value of "message/imdn+xml",
the Content-Disposition header field has a value of "notification",
and the <disposition> element in that xml body has a value of
"delivery". An endpoint matches a delivery notification to an
instant message by matching the Message-ID header field value with
the <message-id> element value in the body of the delivery
notification. If the message was delivered to multiple recipients,
the <recipient-uri> element or the <original-recipient-uri> element
in the XML body is used to identify the recipient.
A Message/CPIM message request is identified as a read notification
and is matched to an instant message in a similar fashion as a
delivery notification. The difference is that the <disposition>
element in that xml body has a value of "read".
7. Header Fields
7.1. CPIM Header Namespace
Per CPIM [2], IMDN uses a namespace for the CPIM headers. The
namespace is
urn:ietf:params:cpim-headers:imdn
All of the header definitions in this document refer to this
namespace.
7.2. Disposition-Notification
The Disposition-Notification header field is a Message/CPIM extension
that is used by the instant message sender to indicate the request to
receive IMDNs for that specific IM. This header field is optional
and is not needed if the IM sender does not request an IMDN. The
syntax is defined in Section 8.
7.3. Message-ID
The Message-ID header field is a Message/CPIM extension that is used
by the instant message sender to correlate received IMDNs by
comparing its value with the value of the <message-id> element
present in the IMDN payload. This header field is optional. The
syntax is defined in Section 8.
7.4. Original-To
The Original-To header field is a Message/CPIM extension that is
added to an IM by an intermediary. It is used by the instant message
recipient to indicate in the IMDNs (by populating the <original-
recipient-uri> element) the original address the IM was sent to.
This header is mandatory if the intermediary changes the CPIM To
header field value. The syntax is defined in Section 8.
7.5. Really-From 9. Identifying Messages
The Really-From header field is a Message/CPIM extension that is Messages are typically carried in a transport protocol like SIP [9].
added to an IM by an intermediary in order to indicate that it wants The message is an IM if the content-type header field present in it
the IMDN to be sent to it. The syntax is defined in Section 8. has a value that is NOT "message/imdn+xml".
Multiple Really-From headers can appear in an IM
7.6. Really-To A message is identified as a delivery notification by examining its
contents. The message is a delivery notification if: the Content-
type header field present has a value of "message/imdn+xml", the
Content-Disposition header field has a value of "notification", and
the <disposition> element in that xml body has a sub-element
<delivery>.
The Really-To header field is a Message/CPIM extension that is added A message is identified as a processing notification or read
to an IMDN by an endpoint by copying the contents of te Really- From notification in a similar fashion as a delivery notification. The
header that appeared in the IM. This header is used by the endpoint difference is that the <disposition> element in that xml body has a
and intermediaries to route IMDNs to the final destination. The sub-element of <processing> and <read> respectively.
syntax is defined in Section 8. Multiple Really-From headers can
appear in an IMDN.
8. Header Fields Formal Syntax 10. Header Fields Formal Syntax
The following syntax specification uses the message header syntax as The following syntax specification uses the message header syntax as
described in Section 3 of RFC3862 [2]. described in Section 3 of RFC3862 [2].
Header syntax is described without a namespace qualification.
Following the rules in RFC3862 [2], header names and other text are
case sensitive and MUST be used as given, using exactly the indicated
upper-case and lower-case letters.
Disposition-Notification = Disposition-Notification =
"Disposition-Notification" ": " [(notify-req *(COMMA notify-req))] "Disposition-Notification" ": " [(notify-req *(COMMA notify-req))]
notify-req = ("negative-delivery" / "positive-delivery" / "read" / Token) *(SEMI disp-notif-params) notify-req =
("negative-delivery" / "positive-delivery" /
"processing" / "read" / Token) *(SEMI disp-notif-params)
disp-notify-params = "aggregate" / generic-param disp-notify-params = "aggregate" / 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 ">"
Really-From = "Really-From" ": " [ Formal-name ] "<" URI ">" IMDN-Record-Route = "IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">"
Really-From = "Really-To" ": " [ Formal-name ] "<" URI ">" IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">"
9. IMDN Format 11. IMDN Format
9.1. Structure of XML-Encoded imdn 11.1. Structure of XML-Encoded IMDN Payload
An IMDN is an XML document [7] that MUST be well-formed and MUST be An IMDN Payload is an XML document [7] that MUST be well-formed and
valid according to schemas, including extension schemas, available to MUST be valid according to schemas, including extension schemas,
the validater and applicable to the XML document. The imdn documents available to the validater and applicable to the XML document. The
MUST be based on XML 1.0 and MUST be encoded using UTF-8. IMDN Payload MUST be based on XML 1.0 and MUST be encoded using
UTF-8.
The namespace identifier for elements defined by this specification The namespace identifier for elements defined by this specification
is a URN [4], using the namespace identifier 'ietf' defined by [5] is a URN [4], using the namespace identifier 'ietf' defined by [5]
and extended by [3]. This urn is: urn:ietf:params:xml:ns:imdn. and extended by [3]. This urn is: urn:ietf:params:xml:ns:imdn.
This namespace declaration indicates the namespace on which the IMDN This namespace declaration indicates the namespace on which the IMDN
is based on. is based.
The root element is <imdn>. The <imdn> element has sub-elements, The root element is <imdn>. The <imdn> element has sub-elements,
namely <message-id>, <datetime>, <recipient-uri>, <original- namely <message-id>, <datetime>, <recipient-uri>, <original-
recipient-uri>, <subject>, <disposition>, <status>, <note>. Those recipient-uri>, <subject>, <disposition>, <status>, and <note>.
elements are described in details in the following sections. Those elements are described in details in the following sections.
9.1.1. The <message-id> Element <disposition> and <status> can be extended in the future to include
new sub-elements not defined in this document. Those new elements
MUST be defined in an RFC.
The <message-id> element is optional according to the XML schema and 11.1.1. The <message-id> Element
The <message-id> element is mandatory according to the XML schema and
carries the message id that appeared in the Message-ID header field carries the message id that appeared in the Message-ID header field
of the IM, if any. This element is mandatory if the IM contained a of the IM.
Message-ID header field.
9.1.2. The <datetime> Element 11.1.2. The <datetime> Element
The <datetime> element is mandatory and carries the date and time the The <datetime> element is mandatory and carries the date and time the
IM was sent (not the IMDN). This information is obtained from the IM was sent (not the IMDN). This information is obtained from the
Message/CPIM DateTime header field of the IM. DateTime header field of the IM.
9.1.3. The <recipient-uri>; Element 11.1.3. The <recipient-uri>; Element
The <recipient-uri> element is optional and carries the URI of the The <recipient-uri> element is optional and carries the URI of the
final recipient. This information is obtained from the To header final recipient. This information is obtained from the To header
field of the IM. field of the IM.
9.1.4. The <original-recipient-uri>; Element 11.1.4. The <original-recipient-uri>; Element
The <original-recipient-uri> element is optional and carries the URI The <original-recipient-uri> element is optional and carries the URI
of the final recipient. It MUST be present if the IM carried the of the original recipient. It MUST be present if the IM carried the
CPIM Original-To header field. This information to populate this Original-To header field. This information is obtained from the
element is obtained from the Original-To header field of the IM. Original-To header field of the IM.
9.1.5. The <subject>; Element 11.1.5. The <subject>; Element
The <subject> element is optional and carries the text that was in The <subject> element is optional and carries the text that was in
the Message/cpim Subject header field. This allows for a human level the Subject header field, if any. This allows for a human level
correlation between an IM and an IMDN. correlation between an IM and an IMDN.
9.1.6. The <disposition> Element 11.1.6. The <disposition> Element
The <disposition> is element mandatory and carries the disposition The <disposition> element is mandatory and carries the disposition
type that the IM sender requested and is being reported. I can carry type that the IM Sender requested and is being reported. It can
the values "delivery", "read" and any other future extension. carry one of the sub-elements <delivery>, <processing>, <read> or any
other future extension.
9.1.7. The <status> Element 11.1.7. The <status> Element
The <status> element is mandatory and carries the result of the The <status> element is mandatory and carries the result of the
disposition request in the <disposition> element. It can carry the disposition request in the <disposition> element. For disposition
values "success" to mean the disposition was successful, "failure" to type <delivery>, it can carry one of the sub-elements <delivered>,
mean the disposition fail, "forbidden" to mean the disposition was <failed>, <forbidden> or <error>. For disposition type <read>, it
denied, "error" to mean internal server error, and any other future can carry one of the sub-elements <read>, <forbidden> or <error>.
extension. For disposition type <processing>, it can carry one of the sub-
elements <processed>, <stored>, <forbidden> or <error>. <forbidden>
means the disposition was denied. <error> means internal server
error. It can also carry any other future extension.
9.1.8. The <note> Element 11.1.8. The <note> Element
The <note> element is optional and carries a human readable text. It The <note> element is optional and carries a human readable text. It
has the "lang" attribute that indicates the language the text is has the "lang" attribute that indicates the language the text is
written in. written in.
9.2. MIME Type for imdn Document 11.2. MIME Type for IMDN Paylaod
The MIME type for the imdn document is "message/imdn+xml". The SIP The MIME type for the IMDN Payload is "message/imdn+xml". The IMDN
[9] MESSAGE request [10] or the MSRP SEND request [11] that is used MUST identify the payload as MIME type "message/imdn+xml" in the
to carry the IMDN that also carries payload type information MUST Content-type header field.
identify the payload as MIME type "message/imdn+xml" in the Content-
Type header field.
9.3. The XML Schema 11.3. The RelaxNG Schema
10. Transporting Message/CPIM messages using SIP <?xml version="1.0" encoding="UTF-8"?>
<grammar
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"
ns="urn:ietf:params:xml:ns:imdn">
10.1. Endpoint Behaviour <start>
<element name="imdn">
<element name="message-id">
<data type="token"/>
</element>
<element name="datetime">
<data type="string"/>
</element>
<optional>
<element name="recipient-uri">
<data type="anyURI"/>
</element>
<element name="original-recipient-uri">
<data type="anyURI"/>
</element>
<element name="subject">
<data type="string"/>
</element>
</optional>
<choice>
<ref name="deliveryNotification"/>
<ref name="readNotification"/>
<ref name="processingNotification"/>
<zeroOrMore>
<empty/>
</zeroOrMore>
</choice>
<ref name="note"/>
<zeroOrMore>
<ref name="Extension"/>
</zeroOrMore>
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</element>
</start>
10.1.1. Sending Requests <define name="deliveryNotification">
<element name="disposition">
<element name="delivery">
<empty/>
</element>
</element>
<element name="status">
<choice>
<element name="delivered">
<empty/>
</element>
<element name="failed">
<empty/>
</element>
<ref name="commonDispositionStatus"></ref>
<zeroOrMore>
<ref name="Extension"/>
</zeroOrMore>
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</choice>
</element>
</define>
<define name="readNotification">
<element name="disposition">
<element name="read">
<empty/>
</element>
</element>
<element name="status">
<choice>
<element name="read">
<empty/>
</element>
<ref name="commonDispositionStatus"></ref>
<zeroOrMore>
<ref name="Extension"/>
</zeroOrMore>
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</choice>
</element>
</define>
<define name="processingNotification">
<element name="disposition">
<element name="processing">
<empty/>
</element>
</element>
<element name="status">
<choice>
<element name="processed">
<empty/>
</element>
<element name="stored">
<empty/>
</element>
<ref name="commonDispositionStatus"></ref>
<zeroOrMore>
<ref name="Extension"/>
</zeroOrMore>
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</choice>
</element>
</define>
<define name="commonDispositionStatus">
<choice>
<element name="forbidden">
<empty/>
</element>
<element name="error">
<empty/>
</element>
<zeroOrMore>
<ref name="Extension"/>
</zeroOrMore>
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</choice>
</define>
<define name="note">
<element name="note">
<optional>
<attribute>
<name ns="http://www.w3.org/XML/1998/namespace">lang</name>
<data type="language"/>
</attribute>
</optional>
<data type="string"/>
</element>
</define>
<define name="Extension">
<empty/>
</define>
<define name="anyIMDN">
<element>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:imdn"/>
<nsName ns=""/>
</except>
</anyName>
<mixed>
<zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<ref name="anyIMDN"/>
</choice>
</zeroOrMore>
</mixed>
</element>
</define>
</grammar>
12. Transporting Messages using SIP
12.1. Endpoint Behaviour
12.1.1. Sending Requests
A SIP MESSAGE request is constructed using RFC 3428 [10]. The A SIP MESSAGE request is constructed using RFC 3428 [10]. The
content-type header field indicates the MIME type of the request 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 Instant Messages and MUST be of MIME type "message/cpim" [2] for both IMs and IMDNs. The
IMDNs. The payload is constructed according to Section 4. payload is constructed according to Section 7.
A SIP MESSAGE request to multiple recipients is constructed in a A SIP MESSAGE request to multiple recipients is constructed in a
similar manner as a SIP MESSAGE request to a single recipient. The similar manner as a SIP MESSAGE request to a single recipient. The
differences are indicated in [15]. differences are indicated in [15].
10.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 [10]. Of course, an endpoint will send a according to RFC3428 [10]. Of course, an endpoint will send a
response to the MESSAGE request regardless of the IMDN it has been response to the MESSAGE request regardless of they type of message
asked for or the type of MESSAGE request it has received (instant (IM or IMDN) is has received, or the disposition type it has been
message or IMDN). asked for.
10.1.3. Receiving Requests 12.1.3. Receiving Requests
10.1.3.1. Instant Message 12.1.3.1. Instant Message
A SIP MESSAGE request is identified as an instant message by A SIP MESSAGE request is identified as an IM by examining its
examining its contents according to Section 6. contents according to Section 9.
If an endpoint received a SIP MESSAGE request that is carrying an IM If an IM Recipient received a SIP MESSAGE request that is an IM that
and that contains a Messge/CPIM payload that requested a positive- requested a positive-delivery notification, and that IM Recipient has
delivery notification, and that endpoint has constructed and sent a constructed and sent a SIP 2xx class response, it MAY generate a
SIP 2xx class response, it MAY generate a positive-delivery positive-delivery notification after making sure that the IM has been
notification after making sure that the instant message has been
delivered to the user or application (a GW, for example, can generate delivered to the user or application (a GW, for example, can generate
a 2xx response before it has been guaranteed that the final recipient a 2xx response before it has been guaranteed that the final recipient
has actually received the message). The positive-delivery has actually received the IM). The positive-delivery notification is
notification is constructed according to Section 4.2.1. The message/ constructed according to Section 7.2.1.1. The message is then placed
cpim message is then placed as the payload in a SIP MESSAGE request. as the payload in a SIP MESSAGE request.
If an endpoint received a SIP MESSAGE request that contains a Messge/ If an IM Recipient received a SIP MESSAGE request that is an IM that
CPIM payload that requested a negative-delivery, and that endpoint requested a negative-delivery, and that IM Recipient has constructed
has constructed and sent a 2xx class response, it SHOULD generate a and sent a 2xx class response, it SHOULD generate a negative-delivery
negative-delivery notification if it learnt that the final recipient notification if it learnt that the final recipient or application did
or application did not receive the instant message (a GW, for not receive the IM (a GW, for example, can generate a 2xx response
example, can generate a 2xx response before it has been guaranteed before it has been guaranteed that the final recipient has actually
that the final recipient has actually received the message). The received the IM). The negative-delivery notification is constructed
negative-delivery notification is constructed according to according to Section 7.2.1.1. The message is then placed as the
Section 4.2.1. The message/cpim message is then placed as the
payload in a SIP MESSAGE request. payload in a SIP MESSAGE request.
If an endpoint received a SIP MESSAGE request that requested a If an IM Recipient received a SIP MESSAGE request that is an IM that
negative-delivery notification, and the endpoint has constructed and requested a negative-delivery notification, and the IM Recipient has
sent an error response, it MUST NOT generate a negative-delivery constructed and sent an error response, it MUST NOT generate a
notification. negative-delivery notification.
If an endpoint received a SIP MESSAGE request that is an IM and that If an IM Recipient received a SIP MESSAGE request that is an IM that
contains a Messge/CPIM payload that requested a read notification, requested a read notification, and that IM Recipient has constructed
and that endpoint has constructed and sent a SIP 2xx class response, and sent a SIP 2xx class response, it MAY generate a read
it MAY generate a read notification after making sure that the notification after making sure that the IM has been presented to the
instant message has been presented to the user or application. It is user or application. It is outside the scope of this document how
outside the scope of this document how a determination can be made. such determination can be made. Note that the option to send a read
Note that the option to send a read notification or not can be left notification or not can be left to the user. An application may
to the user. An application may allow a user to configure such allow a user to configure such choice. The read notification is
choice. The read notification is constructed according to constructed according to Section 7.2.1.2. The message is then placed
Section 4.2.2. The message/cpim message is then placed as the as the payload in a SIP MESSAGE request.
payload in a SIP MESSAGE request.
10.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 6. examining its contents according to Section 9.
10.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 6. its contents according to Section 9.
10.2. Intermediary Behaviour 12.2. Intermediary Behaviour
In this context, application servers (including URI-List servers and In this context, application servers (including URI-List servers and
Store-and-Forward server) and gateways are defined as intermediaries. Store-and-Forward server) and gateways are defined as intermediaries.
SIP Proxies MUST NOT generate IMDNs but MUST forward then 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 A SIP MESSAGE request to multiple recipients is forwarded according
to [15]. to [15].
If an intermediary generates a SIP 2xx class response to a SIP If an intermediary generates a SIP 2xx class response to a SIP
MESSAGE request it has received that is an instant message, it MESSAGE request it has received that is an IM, it examines if the
examines if the body was of type "message/cpim". If so, it checks if body was of type "message/cpim". If so, it checks if there is the
there is the header field Disposition-Notification with a value header field Disposition-Notification with a value "positive-
"positive-delivery" and/or "negative-delivery". If so, it MUST send delivery" and/or "negative-delivery". If so, it MUST send a delivery
a delivery notification after receiving a transactional response for notification after receiving a transactional final response for the
the instant message. 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 notification if it receives a SIP 2xx class response for the sent IM.
instant message. This is in anticipation of a failure downstream This is in anticipation of a failure downstream after a 2xx response
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 MUST generate a delivery "negative-delivery", the intermediary SHOULD generate a delivery
notification if it receives a SIP 4xx, 5xx or 6xx class final notification if it receives a SIP 4xx, 5xx or 6xx class final
response for the sent instant message or if it has received a SIP 2xx response for the sent IM or if it has received a SIP 2xx class
class response followed by a negative-delivery notification. The response followed by a negative-delivery notification.
generation of such IMDN is the same procedure as that for an endpoint
(Section 4.2.1). If the Disposition-Notification header field contains a value of
"processing", the intermediary MAY generate a processing notification
after it has forwarded or stored the IM. The rest of the procedures
in Section 8.1 apply.
The procedure for generating such IMDN is the same as that of an IM
Recipient (Section 7.2.1.1).
The <recipient-uri> element of the XML body is populated with the URI The <recipient-uri> element of the XML body is populated with the URI
of the instant message recipient. of the IM Recipient.
If an intermediary receives a SIP MESSAGE request carrying a read If an intermediary receives a SIP MESSAGE request carrying a positive
notification, it statelessly forwards it. delivery notification or a read notification, it forwards it using
the rules in Section 8.
11. Transporting Message/CPIM messages using MSRP 13. Transporting Messages using MSRP
11.1. Endpoint Behaviour 13.1. Endpoint Behaviour
11.1.1. Sending Requests 13.1.1. Sending Requests
MSRP Relays MUST NOT generate IMDNs. MSRP Relays MUST NOT generate IMDNs.
An MSRP SEND request is constructed using [11]. The content-type An MSRP SEND request is constructed using [11]. The content-type
header field indicates the MIME type of the request payload. When header field indicates the MIME type of the request payload. When
using this extension, the content-type header field MUST be of MIME using this extension, the content-type header field MUST be of MIME
type "message/cpim" [2] for both Instant Messages and IMDNs. The type "message/cpim" [2] for both IMs and IMDNs. The payload is
payload is constructed according to Section 4. constructed according to Section 7.
MSRP has built in delivery reports and therefore does not require MSRP has built in delivery reports and therefore does not require
delivery notifications as defined in this specification. Read delivery notifications as defined in this specification. Read
notifications and any future defined IMDN dispositions, however, as notifications and any future defined IMDN dispositions, however, are
still relevant. Therefore, an endpoint MUST NOT create MSRP SEND still relevant. Therefore, an IM Sender MUST NOT create MSRP SEND
requests requiring a positive-delivery notification or a negative- requests requiring a positive-delivery notification or a negative-
delivery notification. delivery notification.
For SEND requests that are IMDNs, the sender MUST NOT request a For SEND requests that are IMDNs, the IM Recipient MUST NOT request a
delivery report (an MSRP REPORT to a SEND request). I.e. It MUST delivery report (an MSRP REPORT to a SEND request). I.e. It MUST
populate the request with a Failure-Report header field with the populate the request with a Failure-Report header field with the
value "no" and with a Success-Report header field with value "no" (or value "no" and with a Success-Report header field with value "no" (or
alternatively leave out that header field since it defaults to "no"). alternatively leave out that header field since it defaults to "no").
The sender also MUST NOT request an IMDN for a SEND request that is The IM Recipient also MUST NOT request an IMDN for a SEND request
an IMDN. that is an IMDN.
An MSRP SEND request to multiple recipients is contracted in a An MSRP SEND request to multiple recipients is constructed in a
similar manner as a SEND request to a single recipient. The similar manner as a SEND request to a single recipient. The
differences are indicated in [14]. differences are indicated in [14].
11.1.2. Sending Responses 13.1.2. Sending Responses
An endpoint receiving an MSRP SEND request constructs an MSRP An endpoint receiving an MSRP SEND request constructs an MSRP
response according to [11] if needed. Section 7.2 of [11] describes response according to [11] if needed. Section 7.2 of [11] describes
when to send and when not to send an MSRP response. For SEND when to send and when not to send an MSRP response. For SEND
requests that are IMDNs, a response MUST NOT be generated. This is requests that are IMDNs, a response MUST NOT be generated. This is
not a special case; for SEND requests that contain a Failure-Report not a special case; for SEND requests that contain a Failure-Report
header field with the value "no" and a Success-Report header field header field with the value "no" and a Success-Report header field
with value "no" the sender does not need to start a timer and the with value "no" the IM Sender does not need to start a timer and the
receiver does not send a transactional response. IM Recipient does not send a transactional response.
11.1.3. Receiving Requests 13.1.3. Receiving Requests
11.1.3.1. Instant Message 13.1.3.1. Instant Message
An MSRP SEND request is identified as an instant message by examining An MSRP SEND request is identified as an IM by examining its contents
its contents according to Section 6. according to Section 9.
11.1.3.2. Read Report 13.1.3.2. Read Report
An MSRP SEND request is identified as read notification by examining An MSRP SEND request is identified as read notification by examining
its contents according to Section 6. The receiver MUST ignore any its contents according to Section 9. The IM Sender MUST ignore any
requests for read notification, or any kind of IMDNs for an IMDN. requests for read notification, or any kind of IMDNs for an IMDN.
11.2. Intermediary Behaviour 13.2. Intermediary Behaviour
In this context, application servers (including conference servers In this context, application servers (including conference servers
and Store-and-Forward server) and gateways are defined as and Store-and-Forward server) and gateways are defined as
intermediaries. MSRP Relays MUST NOT generate IMDNs but MUST relay intermediaries. MSRP Relays MUST NOT generate IMDNs but MUST relay
them. them.
An MSRP SEND request to multiple recipients is forwarded according to An MSRP SEND request to multiple recipients is forwarded according to
[14]. [14].
MSRP has built in delivery reports and therefore does not require MSRP has built in delivery reports and therefore does not require
delivery notifications as defined in this specification. An MSRP delivery notifications as defined in this specification. An MSRP
intermediary MUST NOT generate IMDNs. A Store-and-Forwards server intermediary MUST NOT generate IMDNs. A Store-and-Forwards server
(the equivalent of a voicemail server) can send stored session IMs to (the equivalent of a voice-mail server) can send stored session IMs
their destination and forward the request for read notifications, if to their destination and forward the request for read notifications,
any. The read notification most likely has to be an aggregated read if any. The read notification most likely has to be an aggregated
notification for all the IMs that were stored for that session, and read notification for all the IMs that were stored for that session,
the aggregation has to be done at the endpoint. It is unknown at and the aggregation has to be done at the IM Recipient. It is
this point how a MSRP store-and-forward server communicates with the unknown at this point how a MSRP store-and-forward server
recipient in order to send the IMs. This is outside the scope of communicates with the recipient in order to send the IMs. This is
this document and is left as a future exercise. outside the scope of this document and is left as a future exercise.
12. Security Considerations 14. Security Considerations
Instant Message IMDNs provide a fine-grained view of the activity of IMDNs provide a fine-grained view of the activity of the IM Recipient
the entity receiving the IM and thus deserves particularly careful and thus deserves particularly careful confidentiality protection so
confidentiality protection so that only the intended recipient of the that only the intended recipient of the IMDN will receive the IMDN
IMDN will receive the IMDN message (in most cases, the intended (in most cases, the intended recipient of the IMDN is the IM Sender).
recipient of the IMDN is the sender of the IM).
Since the IMDN messages are carried by using the IM protocol itself, Since IMDNs are carried by using the IM protocol itself, all security
all security considerations of the underlying IM protocol also apply considerations of the underlying IM protocol also apply to the IMDNs.
to the IMDN messages.
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 user 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 convincing a URI-List server to send IMDNs to an unsuspecting IM
user. 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 Reporting endpoint. from a IM Recipient.
o A malicious intermediary attempts to forward an IMDN from a o A malicious intermediary attempts to forward an IMDN from an IM
Reporting endpoint to the Requesting endpoint, where the Reporting Recipient to the IM Sender, where the IM Recipient would not
endpoint would not normally forward the IMDN to that Requesting normally forward the IMDN to that IM Sender if the IM Recipient
endpoint if the Reporting endpoint knew the identity of the knew the identity of the IM Sender.
Requesting endpoint.
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 with a request for aggregated IMDN processing. expansion with a request for aggregated IMDN processing.
Attacks the protocol cannot protect against include the following: The protocol cannot protect against attacks that include the
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
issue implementation issue. implementation issue.
o A malicious Reporting endpoint that alters the time of the report. o A malicious IM Recipient that alters the time of the IMDN. There
There is no protocol mechanism for ensuring the endpoint does not is no protocol mechanism for ensuring the IM Recipient does not
lie about the time or purposely holds an IMDN for transmission to lie about the time or purposely holds an IMDN for transmission to
make it appear the user disposed of a message later than they make it appear that the user read an IM later than they actually
actually did. 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 Reporting and security. The privacy considerations allow the IM Recipient
endpoint to silently ignore an IMDN request. Any mechanism that to silently ignore an IMDN request. Any mechanism that would
would reliably indicate that a malicious node deleted a Reporting reliably indicate that a malicious node deleted a IM Recipient's
endpoint's IMDN would also serve the purpose of detecting a IMDN would also serve the purpose of detecting a IM Recipient that
Reporting endpoint 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 sender of the IM 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 Reporting endpoint has a certificate, it MUST sign the o If the IM Recipient has a certificate, it MUST sign the IMDN.
IMDN.
o If the IM is encrypted, the Reporting endpoint MUST encrypt the o If the IM is encrypted, the IM Recipient or intermediary MUST
IMDN body, as an attacker may attempt to discern the user's encrypt the IMDN body, as an attacker may attempt to discern the
activity profile and identity from sniffing IMDNs on the network. user's activity profile and identity from sniffing IMDNs on the
network.
o The two above rules are cumulative. o The two above rules are cumulative.
The reporting endpoint MUST be capable of loading a user certificate. The IM Recipient or intermediary MUST be capable of loading a user
certificate.
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 messages to the node with IMDN requests. node by sending lots of IMs to the node with IMDN requests. Note
Note that this is the same problem as there is without IMDN; IMDN that this is the same problem as there is without IMDN; IMDN simply
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 a B2BUA Likewise, an attacker can mount a denial of service attack on an
by asking the B2BUA to explode a large list and to direct the B2BUA intermediary by asking the intermediary to explode a large list and
to consolidate the IMDN's from the targets of the list. to direct the intermediary to aggregate the IMDNs from the targets of
the list.
The following security considerations apply when using message IMDNs: The following security considerations apply when using IMDNs:
12.1. Forgery 14.1. Forgery
Message IMDNs may be forged as easily as ordinary Instant Message. IMs can be forged. To protect against that, an IM can be signed. An
User agents and intermediaries that wish to make automatic use of intermediary that receives a signed message and needs to modify any
IMDNs should take appropriate precautions to minimize the potential part of it that is included in the signature (like adding an
damage from denial-of-service attacks. Security threats related to Original-To header to the CPIM headers), MUST consume the IM and
forged message IMDNs include the sending of a falsified IMDN when the create a new copy of it that the intermediary signs itself.
indicated disposition of the message has not actually occurred. For
example, read notification could be forged to indicate that a IM
recipient has read the instant message. Unsolicited IMDNs is also
another form of forgery.
12.2. Confidentiality IMDNs may be forged as easily as ordinary IMs. Endpoints and
intermediaries that wish to make automatic use of IMDNs should take
appropriate precautions to minimize the potential damage from denial-
of-service attacks. Security threats related to forged IMDNs include
the sending of a falsified IMDN when the indicated disposition of the
IM has not actually occurred. For example, read notification could
be forged to indicate that a IM Recipient has read the IM.
Unsolicited IMDNs is also another form of forgery.
There may be cases where an instant message recipient does not wish 14.2. Confidentiality
to reveal the information that he has received or in fact read the
instant message. In this situation, it is acceptable for the UA to
silently ignore requests for an IMDN. It is strongly RECOMMENDED
that the user agent obtain the user's consent before sending an IMDN.
Circumstances where the user agent does not ask for the user's
consent include instant messaging systems that, for regulatory
reasons, are required to issue an IMDN, such as in the health care
field or financial community.
A user agent can obtain such consent by a prompt or dialog box on a There may be cases where an IM Recipient does not wish to reveal the
per-message basis, globally through the user's setting of a information that he has received or in fact read the IM. In this
preference, or other, user-configurable mechanism. The user might situation, it is acceptable for the IM Recipient to silently ignore
also indicate globally that IMDNs are never to be sent or that a requests for an IMDN. It is strongly RECOMMENDED that the IM
"forbidden" IMDN status is always sent in response to a request for Recipient obtain the user's consent before sending an IMDN.
an IMDN. Circumstances where the IM Recipient does not ask for the user's
consent include IM systems that, for regulatory reasons, are required
to issue an IMDN, such as in the health care field or financial
community.
There are situations where a user sends an IM and requesting IMDNs to An IM Recipient can obtain such consent by a prompt or dialog box on
a list who's member information is not disclosed. In this situation, a per-IM basis, globally through the user's setting of a preference,
the sender will learn of the list members. The URI-List server MUST or other, user-configurable mechanism. The user might also indicate
only deliver one aggregated IMDN. Alternatively, the list server MAY globally that IMDNs are never to be sent or that a "forbidden" IMDN
reject the IM. 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
list who's member information is not disclosed. In this situation,
the user will learn of the list members. Therefore, in this case,
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-
List server MUST only deliver one aggregated IMDN. Alternatively,
the URI-list server MAY reject the IM.
An unencrypted IMDN could reveal confidential information about an An unencrypted IMDN could reveal confidential information about an
encrypted instant message. It is a MUST that the same level of encrypted IM. It is a MUST that the same level of security applied
security applied to an IM to be applied to its IMDNs. For example, to an IM to be applied to its IMDNs. For example, if an IM is signed
if an IM is signed and encrypted, and IMDN must also be signed and and encrypted, and IMDN must also be signed and encrypted.
encrypted.
12.3. Non-Repudiation 14.3. Non-Repudiation
Message IMDNs cannot be relied on as a guarantee that an instant IMDNs cannot be relied on as a guarantee that an IM was or was not
message was or was not seen by the recipient. Even if IMDNs are not seen by the user. Even if IMDNs are not actively forged, they may be
actively forged, they may be lost in transit. The IMDN issuing lost in transit. The IMDN issuing mechanism may be bypassed in some
mechanism may be bypassed in some manner by the recipient on the IM. manner by the IM Recipient.
.
13. IANA Considerations 15. IANA Considerations
13.1. message/imdn+xml MIME TYPE 15.1. message/imdn+xml MIME TYPE
This document registers a new MIME type "message/imdn+xml", and This document registers a new MIME type "message/imdn+xml", and
registers a new XML namespace. registers a new XML namespace.
This specification follows the guidelines of RFC3023 [6]. This specification follows the guidelines of RFC3023 [6].
MIME media type: message MIME media type: message
MIME subtype name: imdn+xml MIME subtype name: imdn+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [6]. specified in RFC 3023 [6].
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [6]. application/xml as specified in RFC 3023 [6].
Security considerations: See section 10 of RFC 3023 [6] and Security considerations: See section 10 of RFC 3023 [6] and
Section 12 of this document. Section 14 of this document.
Interoperability considerations: none. Interoperability considerations: none.
Published specification: This document. Published specification: This document.
Applications which use this media type: This document type has been Applications which use this media type: This document type is used to
used to support SIP and MSRP based instant messaging. support SIP and MSRP based instant messaging.
Additional information: None Additional information: None
Magic number: None Magic number: None
File extension: .cl or .xml File extension: .cl or .xml
Macintosh file type code: "TEXT" Macintosh file type code: "TEXT"
Personal and email address for further information: Hisham Khartabil Personal and email address for further information: Hisham Khartabil
(hisham.khartabil@telio.no) (hisham.khartabil@telio.no)
Intended Usage: COMMON Intended Usage: COMMON
Author/change controller: The IETF . Author/change controller: The IETF .
13.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:imdn 15.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:imdn
This section registers a new XML namespace, as per guidelines in the This section registers a new XML namespace, as per guidelines in the
IETF XML Registry [3]. IETF XML Registry [3].
URI: The URI for this namespace is urn:ietf:params:xml:ns:imdn. URI: The URI for this namespace is urn:ietf:params:xml:ns:imdn.
Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil
(hisham.khartabil@telio.no) . (hisham.khartabil@telio.no) .
13.3. Schema Registration 15.3. Schema Registration
This section registers a new XML schema per the procedures in [3]. This section registers a new XML schema per the procedures in [3].
URI: urn:ietf:params:xml:ns:imdn URI: urn:ietf:params:xml:ns:imdn
Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil
(hisham.khartabil@telio.no) (hisham.khartabil@telio.no)
The XML for this schema can be found as the sole content of The XML for this schema can be found as the sole content of
Section 9.3. . Section 11.3.
13.4. Message/CPIM Header Field registration 15.4. 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 cpim-headers registry: the cpim-headers registry:
Disposition-Notification - [RFCXXXX] Disposition-Notification - [RFCXXXX]
Message-ID - [RFCXXXX] Message-ID - [RFCXXXX]
Original-To - [RFCXXXX]. Original-To - [RFCXXXX]
IMDN-Record-Route - [RFCXXXX]
13.5. Content-Disposition: notification IMDN-Route - [RFCXXXX].
content-disposition notification . 15.5. Content-Disposition: notification
14. Acknowledgements This document registers one new Content-Disposition header
"disposition-types": notification. The authors request that this
values be recorded in the IANA registry for Content-Dispositions.
Descriptions of this "disposition-types", including motivation and
examples, are given in Section 7.2.1.1 and Section 9. Short
descriptions suitable for the IANA registry are: notification the
body of the message is a notification according to an earlier request
for a disposition notification to an instant message
The author would like to thank Paul Kyzivat, Ben Campbell, Adam Roach 16. Acknowledgements
and Gonzalo Camarillo for their comments and support.
15. References The authors would like to thank Paul Kyzivat, Ben Campbell, Adam
Roach, Gonzalo Camarillo, Sean Olson, Eva Leppanen, Miguel Garcia and
Eric McMurry for their comments and support.
15.1. Normative References 17. 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] Moats, R., "The URN Namespace for IETF Documents", RFC 2648, [5] Moats, R., "The URN Namespace for IETF Documents", RFC 2648,
August 1999. August 1999.
[6] Murata, M., "XML Media Types", RFC 3023, March 1997. [6] Murata, M., "XML Media Types", RFC 3023, March 1997.
[7] Bray, T., "Exensible Markup Language (XML) 1.0 (Second [7] 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.
[8] Ramsdell, B., "S/MIME Version 3 Message Specification", [8] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633, June 1999. RFC 2633, June 1999.
15.2. Informative References 17.2. Informative References
[9] Rosenberg et al., J., Shulzrinne, H., Camarillo, G., Johnston, [9] 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.
[10] Campbell, B., "SIP Extension for Instant Messaging", RFC 3428, [10] Campbell, B., "SIP Extension for Instant Messaging", RFC 3428,
December 2002. December 2002.
[11] Campbell, B., "The Message Session Relay Protocol", [11] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-10, February 2005. draft-ietf-simple-message-sessions-15, June 2006.
[12] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [12] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[13] Fajman, R., "An Extensible Message Format for Message [13] Fajman, R., "An Extensible Message Format for Message
Disposition Notifications", RFC 2298, March 1998. Disposition Notifications", RFC 2298, March 1998.
[14] Niemi, A., "Multi-part IM Sessions Using MSRP", [14] Niemi, A., "Multi-part IM Sessions Using MSRP",
draft-niemi-simple-chat-04, February 2006. draft-niemi-simple-chat-04, February 2006.
[15] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE [15] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE
Requests in SIP", draft-ietf-sipping-uri-list-message-02, Requests in SIP", draft-ietf-sip-uri-list-message-00.txt,
November 2004. September 2006.
Authors' Addresses Authors' Addresses
Eric Burger Eric Burger
Cantata Technology Cantata Technology
18 Keewaydin Dr. 18 Keewaydin Dr.
Salem, NH 03079-2839 Salem, NH 03079-2839
USA USA
Phone: +1 603 890 7587 Phone: +1 603 890 7587
Fax: +1 603 457 5944 Fax: +1 603 457 5944
Email: eburger@brooktrout.com Email: eburger@cantata.com
Hisham Khartabil Hisham Khartabil
Telio Telio
P.O. Box 1203 Vika P.O. Box 1203 Vika
Oslo Oslo 0110
Norway Norway
Phone: +47 2167 3544 Phone: +47 2167 3544
Email: hisham.khartabil@telio.no Email: hisham.khartabil@telio.no
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 27, line 29 skipping to change at page 35, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 190 change blocks. 
627 lines changed or deleted 1045 lines changed or added

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