draft-ietf-simple-imdn-07.txt   draft-ietf-simple-imdn-08.txt 
SIMPLE E. Burger SIMPLE E. Burger
Internet-Draft BEA Systems, Inc. Internet-Draft
Intended status: Standards Track H. Khartabil Intended status: Standards Track H. Khartabil
Expires: October 4, 2008 April 2, 2008 Expires: April 20, 2009 Ericsson Australia
October 17, 2008
Instant Message Disposition Notification Instant Message Disposition Notification
draft-ietf-simple-imdn-07 draft-ietf-simple-imdn-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 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 October 4, 2008. This Internet-Draft will expire on April 20, 2009.
Abstract Abstract
Instant Messaging (IM) refers to the transfer of messages between Instant Messaging (IM) refers to the transfer of messages between
users in real-time. This document provides a mechanism whereby users in real-time. This document provides a mechanism whereby
endpoints can request Instant Message Disposition Notifications endpoints can request Instant Message Disposition Notifications
(IMDN), including delivery, processing, and read notifications, for (IMDN), including delivery, processing, and displayed notifications,
page-mode instant messages. for page-mode instant messages.
The Common Profile for Instant Messaging (CPIM) data format specified The Common Profile for Instant Messaging (CPIM) data format specified
in RFC 3862 is extended with new header fields that enable endpoints in RFC 3862 is extended with new header fields that enable endpoints
to request IMDNs. A new message format is also defined to convey to request IMDNs. A new message format is also defined to convey
IMDNs. IMDNs.
This document also describes how SIP entities behave using this This document also describes how SIP entities behave using this
extension. extension.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Disposition Types . . . . . . . . . . . . . . . . . . . . . . 6 5. Disposition Types . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Processing . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Processing . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Read . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Display . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. New CPIM Header Fields . . . . . . . . . . . . . . . . . . . . 7 6. New CPIM Header Fields . . . . . . . . . . . . . . . . . . . . 7
6.1. CPIM Header Field Namespace . . . . . . . . . . . . . . . 7 6.1. CPIM Header Field Namespace . . . . . . . . . . . . . . . 7
6.2. Disposition-Notification . . . . . . . . . . . . . . . . . 8 6.2. Disposition-Notification . . . . . . . . . . . . . . . . . 8
6.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . . . 8 6.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . . . 8
6.4. Original-To . . . . . . . . . . . . . . . . . . . . . . . 8 6.4. Original-To . . . . . . . . . . . . . . . . . . . . . . . 9
6.5. IMDN-Record-Route . . . . . . . . . . . . . . . . . . . . 8 6.5. IMDN-Record-Route . . . . . . . . . . . . . . . . . . . . 9
6.6. IMDN-Route . . . . . . . . . . . . . . . . . . . . . . . . 9 6.6. IMDN-Route . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . . . 9 7. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . . . 9
7.1. IM Sender . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. IM Sender . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1.1. Constructing Instant Messages . . . . . . . . . . . . 9 7.1.1. Constructing Instant Messages . . . . . . . . . . . . 9
7.1.2. Matching IMs with IMDNs . . . . . . . . . . . . . . . 10 7.1.2. Matching IMs with IMDNs . . . . . . . . . . . . . . . 11
7.1.3. Keeping State . . . . . . . . . . . . . . . . . . . . 11 7.1.3. Keeping State . . . . . . . . . . . . . . . . . . . . 11
7.1.4. Aggregation of IMDNs . . . . . . . . . . . . . . . . . 12 7.1.4. Aggregation of IMDNs . . . . . . . . . . . . . . . . . 12
7.2. IM Recipient . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. IM Recipient . . . . . . . . . . . . . . . . . . . . . . . 12
7.2.1. Constructing IMDNs . . . . . . . . . . . . . . . . . . 12 7.2.1. Constructing IMDNs . . . . . . . . . . . . . . . . . . 12
8. Intermediary Behaviour . . . . . . . . . . . . . . . . . . . . 15 8. Intermediary Behaviour . . . . . . . . . . . . . . . . . . . . 15
8.1. Constructing Processing Notifications . . . . . . . . . . 15 8.1. Constructing Processing Notifications . . . . . . . . . . 16
8.2. Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 17 8.2. Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 17
9. Identifying Messages . . . . . . . . . . . . . . . . . . . . . 19 9. Identifying Messages . . . . . . . . . . . . . . . . . . . . . 20
10. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 19 10. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 20
11. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Structure of XML-Encoded IMDN Payload . . . . . . . . . . 20 11.1. Structure of XML-Encoded IMDN Payload . . . . . . . . . . 21
11.1.1. The <message-id> Element . . . . . . . . . . . . . . . 21 11.1.1. The <message-id> Element . . . . . . . . . . . . . . . 22
11.1.2. The <datetime> Element . . . . . . . . . . . . . . . . 21 11.1.2. The <datetime> Element . . . . . . . . . . . . . . . . 22
11.1.3. The <recipient-uri> Element . . . . . . . . . . . . . 21 11.1.3. The <recipient-uri> Element . . . . . . . . . . . . . 22
11.1.4. The <original-recipient-uri> Element . . . . . . . . . 21 11.1.4. The <original-recipient-uri> Element . . . . . . . . . 23
11.1.5. The <subject> Element . . . . . . . . . . . . . . . . 21 11.1.5. The <subject> Element . . . . . . . . . . . . . . . . 23
11.1.6. The <disposition> Element . . . . . . . . . . . . . . 21 11.1.6. The <delivery-notification>,
11.1.7. The <status> Element . . . . . . . . . . . . . . . . . 21 <processing-notification> and
11.1.8. The <note> Element . . . . . . . . . . . . . . . . . . 22 <display-notification> Elements . . . . . . . . . . . 23
11.2. MIME Type for IMDN Payload . . . . . . . . . . . . . . . . 22 11.1.7. The <status> Element . . . . . . . . . . . . . . . . . 23
11.3. The RelaxNG Schema . . . . . . . . . . . . . . . . . . . . 22 11.1.8. MIME Type for IMDN Payload . . . . . . . . . . . . . . 23
12. Transporting Messages using SIP . . . . . . . . . . . . . . . 26 11.1.9. The RelaxNG Schema . . . . . . . . . . . . . . . . . . 23
12.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 26 12. Transporting Messages using SIP . . . . . . . . . . . . . . . 27
12.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 26 12.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 27
12.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 26 12.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 27
12.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 26 12.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 28
12.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 27 12.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 28
13. Transporting Messages using MSRP . . . . . . . . . . . . . . . 28 12.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 29
14. Security Considerations . . . . . . . . . . . . . . . . . . . 29 13. Transporting Messages using MSRP . . . . . . . . . . . . . . . 30
14.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 31 14. Security Considerations . . . . . . . . . . . . . . . . . . . 31
14.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 31 14.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 32 14.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 33
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 14.3. IMDN as a Certified Delivery Service . . . . . . . . . . . 34
15.1. message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 32 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
15.2. URN Sub-Namespace Registration for 15.1. message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 34
urn:ietf:params:xml:ns:imdn . . . . . . . . . . . . . . . 33 15.2. XML Registration . . . . . . . . . . . . . . . . . . . . . 35
15.3. Schema Registration . . . . . . . . . . . . . . . . . . . 33 15.3. Registration for urn:ietf:params:imdn . . . . . . . . . . 35
15.4. Registration for urn:ietf:params:imdn . . . . . . . . . . 34 15.4. Content-Disposition: notification . . . . . . . . . . . . 36
15.5. Message/CPIM Header Field Registration . . . . . . . . . . 34 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
15.6. Content-Disposition: notification . . . . . . . . . . . . 34 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 17.1. Normative References . . . . . . . . . . . . . . . . . . . 37
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 17.2. Informative References . . . . . . . . . . . . . . . . . . 37
17.1. Normative References . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
17.2. Informative References . . . . . . . . . . . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 37
1. Introduction 1. Introduction
In many user-to-user message exchange systems, message senders often In many user-to-user message exchange systems, message senders often
wish to know if the human recipient actually received or read a wish to know if the human recipient actually received a message or
message. has the message displayed.
Electronic Mail [RFC2821] deals with this situation with Message Electronic Mail [RFC2821] offers a solution to this need with Message
Delivery Notifications [RFC3798]. After the recipient views the Delivery Notifications [RFC3798]. After the recipient views the
message, her mail user agent generates a Message Delivery message, her mail user agent generates a Message Delivery
Notification, or MDN. The MDN is an e-mail that follows the format Notification, or MDN. The MDN is an e-mail that follows the format
prescribed by RFC 3798 [RFC3798]. The fixed format ensures that an prescribed by RFC 3798 [RFC3798]. The fixed format ensures that an
automaton can process the message. automaton can process the message.
The common presence and instant messaging (CPIM) format, Message/CPIM The common presence and instant messaging (CPIM) format, Message/CPIM
[RFC3862], is a message format used to generate instant messages. [RFC3862], is a message format used to generate instant messages.
The session initiation protocol, SIP [RFC3261], can carry instant The session initiation protocol, SIP [RFC3261], can carry instant
messages generated using message/CPIM in SIP MESSAGE requests messages generated using message/CPIM in SIP MESSAGE requests
[RFC3428]. [RFC3428].
This document extends the Message/CPIM message format in much the This document extends the Message/CPIM message format in much the
same way Message Delivery Notifications extends Electronic Mail. same way Message Delivery Notifications extends Electronic Mail.
This extension enables Instant Message Senders to request, create, This extension enables Instant Message Senders to request, create,
and send Instant Message Disposition Notifications (IMDN). This and send Instant Message Disposition Notifications (IMDN). This
mechanism works for page-mode as well as session mode instant mechanism works for page-mode as well as session mode instant
messages. This document only discusses page-mode. Session mode is messages. This document only discusses page-mode. Session mode is
left for future standardisation efforts. left for future standardisation efforts.
IMDNs include positive delivery, negative delivery (i.e., a message This specification defines three categories of disposition types,
did not get delivered successfully), read notifications (i.e., a "delivery", "processing", and "displayed". Specific disposition
message was rendered) as well as processed notifications. By using types provide more detailed information. For example, the "delivery"
CPIM header fields, the IMDN request and delivery are abstracted category includes "delivered" to indicate successful delivery and
outside the transport protocol allowing interoperability between "failed" to indicate failure in delivery.
different IM systems.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document refers generically to the sender of a message in the This document refers generically to the sender of a message in the
masculine (he/him/his) and the recipient of the message in the masculine (he/him/his) and the recipient of the message in the
feminine (she/her/hers). This convention is purely for convenience feminine (she/her/hers). This convention is purely for convenience
skipping to change at page 5, line 33 skipping to change at page 5, line 33
server, including URI-List servers and Store-and-Forward servers, server, including URI-List servers and Store-and-Forward servers,
that forwards an IM to its final destination. Intermediaries also that forwards an IM to its final destination. Intermediaries also
can generate and send processing IMDNs to IMs, if requested by the can generate and send processing IMDNs to IMs, if requested by the
IM Sender and allowed by policy. IM Sender and allowed by policy.
o Gateway: An intermediary that translates between different IM o Gateway: An intermediary that translates between different IM
systems that use different protocols. systems that use different protocols.
o IMDN Payload: An XML document carrying the disposition o IMDN Payload: An XML document carrying the disposition
notification information. In this specification, it is of MIME notification information. In this specification, it is of MIME
type "message/imdn+xml". type "message/imdn+xml".
o Disposition type: the type of IMDN that can be requested. This o Disposition type: the type of IMDN that can be requested. This
specification defines three, namely "delivery", "processing" and specification defines three categories of disposition types,
"read" disposition types. "delivery", "processing", and "display".
o Transport Protocol Message: A SIP or other protocol message that o Transport Protocol Message: A SIP or other protocol message that
contains an IM or IMDN. contains an IM or IMDN.
4. Overview 4. Overview
The diagram below shows the basic protocol flow. An IM Sender The diagram below shows the basic protocol flow. An IM Sender
creates an IM, adds IMDN request information the IM Sender is creates an IM, adds IMDN request information the IM Sender is
interested in receiving and then sends the IM. At a certain point in interested in receiving and then sends the IM. At a certain point in
time, the IM Recipient or an intermediary determines that the user or time, the IM Recipient or an intermediary determines that the user or
application has received, did not receive, read, or otherwise application has received, did not receive, displayed, or otherwise
disposed the IM. The mechanism by which an IM Recipient determines disposed the IM. The mechanism by which an IM Recipient determines
its user has read an IM is beyond the scope of this document. At its user has read an IM is beyond the scope of this document. At
that point, the IM Recipient or intermediary automatically generates that point, the IM Recipient or intermediary automatically generates
a notification message to the IM Sender. This notification message a notification message to the IM Sender. This notification message
is the Instant Message Disposition Notification (IMDN). is the Instant Message Disposition Notification (IMDN).
+--------------+ +--------------+ +--------------+ +--------------+
| IM Sender | | IM Recipient | | IM Sender | | IM Recipient |
|IMDN Recipient| | IMDN Sender | |IMDN Recipient| | IMDN Sender |
+--------------+ +--------------+ +--------------+ +--------------+
skipping to change at page 6, line 22 skipping to change at page 6, line 22
|-------------------------------------->| |-------------------------------------->|
| | | |
| | | |
| 2. IMDN (disposition) | | 2. IMDN (disposition) |
|<--------------------------------------| |<--------------------------------------|
| | | |
| | | |
Basic IMDN Message Flow Basic IMDN Message Flow
Note that the recipient of an IMDN, in some instances, may not be the Note the recipient of an IMDN, in some instances, may not be the IM
IM Sender. This is specifically true for page-mode IMs where the Sender. This is specifically true for page-mode IMs where the
Address of Record (AOR) of the IM Sender, that is present in the IM, Address of Record (AOR) of the IM Sender, that is present in the IM,
resolves to a different location or user agent than the IM resolves to a different location or user agent than the IM
originated. This could happen, for example, if resolving the AOR originated. This could happen, for example, if resolving the AOR
results in forking the request to multiple user agents. For results in forking the request to multiple user agents. For
simplicity, the rest of this document assumes that the IM Sender and 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 IMDN Recipient are the same and therefore will refer to both as
the IM Sender. the IM Sender.
5. Disposition Types 5. Disposition Types
There are three broad categories of disposition states. They are There are three broad categories of disposition states. They are
delivery, processing, and read. delivery, processing, and display.
5.1. Delivery 5.1. Delivery
The delivery notification type indicates whether the IM has been The delivery notification type indicates whether the IM has been
delivered to the IM Recipient or not. The delivery notification type delivered to the IM Recipient or not. The delivery notification type
can have the following states: can have the following states:
o "delivered" to indicate successful delivery. o "delivered" to indicate successful delivery.
o "failed" to indicate failure in delivery. o "failed" to indicate failure in delivery.
o "forbidden" indicate denial for the IM Sender to receive the o "forbidden" indicate denial for the IM Sender to receive the
requested IMDN. The IM Recipient can send the "forbidden" state, requested IMDN. The IM Recipient can send the "forbidden" state,
skipping to change at page 7, line 22 skipping to change at page 7, line 22
o "processed" is a general state of the IM indicating that the o "processed" is a general state of the IM indicating that the
intermediary has performed its task on the IM. intermediary has performed its task on the IM.
o "stored" state indicates that the intermediary stored the IM for o "stored" state indicates that the intermediary stored the IM for
later delivery. later delivery.
o "forbidden" indicate denial for the IM Sender to receive the o "forbidden" indicate denial for the IM Sender to receive the
requested IMDN. The "forbidden" state is sent by an intermediary requested IMDN. The "forbidden" state is sent by an intermediary
that is configured to do so. For example, the administrator has that is configured to do so. For example, the administrator has
disallowed IMDNs. disallowed IMDNs.
o "error" to indicate an error in determining the fate of an IM. o "error" to indicate an error in determining the fate of an IM.
5.3. Read 5.3. Display
The read notification type indicates whether the IM Recipient The display notification type indicates whether the IM Recipient
rendered the IM to the user or not. The read notification type can rendered the IM to the user or not. The display notification type
have the following states: can have the following states:
o "read" is a state indicating that the IM has been rendered to the o "displayed" is a state indicating that the IM has been rendered to
user. the user.
o "forbidden" indicate denial, by the IM Recipient, for the IM o "forbidden" indicate denial, by the IM Recipient, for the IM
Sender to receive the requested IMDN. Sender to receive the requested IMDN.
o "error" to indicate an error in determining the fate of an IM. o "error" to indicate an error in determining the fate of an IM.
In addition to text, some IMs may contain audio, video, and still In addition to text, some IMs may contain audio, video, and still
images. Therefore, the state "read" includes playing the audio or images. Therefore, the state "displayed" includes the start of
video file to the user. rendering the audio or video file to the user.
Since there is no positive acknowledgement from the user, one cannot Since there is no positive acknowledgement from the user, one cannot
determine _a priori_ the user actually read the IM. Thus, one cannot determine the user actually read the IM. Thus, one cannot use the
use the protocol described here as a non-repudiation service. protocol described here as a service to prove someone actually read
the IM.
6. New CPIM Header Fields 6. New CPIM Header Fields
This specification extends the CPIM data format specified in RFC 3862 This specification extends the CPIM data format specified in RFC 3862
[RFC3862]. A new name space is created as well as a number of new [RFC3862]. A new name space is created as well as a number of new
CPIM header fields. CPIM header fields.
6.1. CPIM Header Field Namespace 6.1. CPIM Header Field Namespace
Per CPIM [RFC3862], this specification defines a new name space for Per CPIM [RFC3862], this specification defines a new name space for
skipping to change at page 8, line 29 skipping to change at page 8, line 31
The IM Sender MUST include the Disposition-Notification header field The IM Sender MUST include the Disposition-Notification header field
to indicate the desire to receive IMDNs from the IM Recipient, for to indicate the desire to receive IMDNs from the IM Recipient, for
that specific IM. Section 10 defines the syntax. that specific IM. Section 10 defines the syntax.
6.3. Message-ID 6.3. Message-ID
The IM Sender MUST include the Message-ID header field in the IM that The IM Sender MUST include the Message-ID header field in the IM that
he wishes to receive an IMDN on. The Message-ID contains a globally he wishes to receive an IMDN on. The Message-ID contains a globally
unique message identifier the IM Sender can use to correlate received unique message identifier the IM Sender can use to correlate received
IMDNs. When the IM Sender receives an IMDN, it can compare its value IMDNs. Because the Message-ID is used by the sender to correlate
with the value of the <message-id> element present in the IMDN IMDNs with their respective IMs, the Message-ID MUST be selected so
payload. IMDNs also carry this header field. Note that since the that:
IMDN is itself an IM, the Message-ID of the IMDN will be different
than the Message-ID of the original IM. Section 10 defines the o There is a minimal chance of any two Message-IDs accidentally
syntax. colliding within the time period within which an IMDN might be
received.
o It is prohibitive for an attacker who has seen one or more valid
Message-IDs to generate additional valid Message-IDs.
The first requirement is a correctness requirement to ensure correct
matching by the sender. The second requirement prevents off-path
attackers from forging IMDNs. In order to meet both of these
requirements, it is RECOMMENDED that Message-IDs be generated using a
cryptographically secure pseudorandom number generator and contain at
least 64 bits of randomness, thus reducing the chance of a successful
guessing attack to n/2^64, where n is the number of outstanding valid
messages.
When the IM Sender receives an IMDN, it can compare its value with
the value of the <message-id> element present in the IMDN payload.
IMDNs also carry this header field. Note that since the IMDN is
itself an IM, the Message-ID of the IMDN will be different than the
Message-ID of the original IM. Section 10 defines the syntax.
6.4. Original-To 6.4. Original-To
An intermediary MAY insert an Original-To header field to the IM. An intermediary MAY insert an Original-To header field to the IM.
The value of the Original-To field MUST be the address of the IM The value of the Original-To field MUST be the address of the IM
Receiver. The IM Recipient uses this header to indicate the original Receiver. The IM Recipient uses this header to indicate the original
IM address in the IMDNs. The IM Recipient does this by populating IM address in the IMDNs. The IM Recipient does this by populating
the <original-recipient-uri> element in the IMDN. The intermediary the <original-recipient-uri> element in the IMDN. The intermediary
MUST insert this header if the intermediary changes the CPIM To MUST insert this header if the intermediary changes the CPIM To
header field value. The header field MUST NOT appear more than once header field value. The header field MUST NOT appear more than once
in an IM. The intermediary MUST NOT change this header field value in an IM. The intermediary MUST NOT change this header field value
if it is already present. Section 10 defines the syntax. if it is already present. Section 10 defines the syntax.
6.5. IMDN-Record-Route 6.5. IMDN-Record-Route
An intermediary MAY insert an IMDN-Record-Route header field to the An intermediary MAY insert an IMDN-Record-Route header field to the
IM. The value of the IMDN-Record-Route header field MUST be the IM. This enables the intermediary to receive and process the IMDN on
address of the intermediary. Multiple IMDN-Record-Route header its way back to the IM Sender. The value of the IMDN-Record-Route
fields can appear in an IM. Section 10 defines the syntax. header field MUST be the address of the intermediary. Multiple IMDN-
Record-Route header fields can appear in an IM. Section 10 defines
the syntax.
6.6. IMDN-Route 6.6. IMDN-Route
The IMDN-Route header field provides routing information by including The IMDN-Route header field provides routing information by including
one or more addresses where to route the IMDN. An intermediary that one or more addresses where to route the IMDN. An intermediary that
needs the IMDN to flow back through the same intermediary MUST add needs the IMDN to flow back through the same intermediary MUST add
the IMDN-Record-Route header. When the IM Recipient creates the the IMDN-Record-Route header. When the IM Recipient creates the
corresponding IMDN, the IM Recipient copies the IMDN-Record-Route corresponding IMDN, the IM Recipient copies the IMDN-Record-Route
headers into corresponding IMDN-Route header fields. Section 10 headers into corresponding IMDN-Route header fields. Section 10
defines the syntax. defines the syntax.
skipping to change at page 9, line 28 skipping to change at page 9, line 50
7.1. IM Sender 7.1. IM Sender
7.1.1. Constructing Instant Messages 7.1.1. Constructing Instant Messages
An IM is constructed using CPIM Message Format defined in RFC 3862 An IM is constructed using CPIM Message Format defined in RFC 3862
[RFC3862]. [RFC3862].
7.1.1.1. Adding a Message-ID Header Field 7.1.1.1. Adding a Message-ID Header Field
If the IM sender requests the reception of IMDNs, the IM sender MUST If the IM sender requests the reception of IMDNs, the IM sender MUST
include a Message-ID header field. The Message-ID field is populated include a Message-ID header field. This header field enables the IM
with a value that is unique with at least 32 bits of randomness. Sender to match any IMDNs with their corresponding IMs. See
This header field enables the IM Sender to match any IMDNs with their Section 6.3 for Message-ID uniqueness requirements.
corresponding IMs.
7.1.1.2. Adding a DateTime Header Field 7.1.1.2. Adding a DateTime Header Field
Some devices are not able to retain state over long periods. For Some devices are not able to retain state over long periods. For
example, mobile devices may have memory limits or battery limits. example, mobile devices may have memory limits or battery limits.
These limits may mean these devices may not be able to, or may chose These limits may mean these devices may not be able to, or may chose
not to, keep sent messages for the purposes of correlating IMDNs with not to, keep sent messages for the purposes of correlating IMDNs with
sent IMs. To make some use of IMDN in this case, we add a time stamp sent IMs. To make some use of IMDN in this case, we add a time stamp
to the IM to indicate when the user sent the message. The IMDN to the IM to indicate when the user sent the message. The IMDN
returns this time stamp to enable the user to correlate the IM with returns this time stamp to enable the user to correlate the IM with
the IMDN at the human level. We use the DateTime CPIM header field the IMDN at the human level. We use the DateTime CPIM header field
for this purpose. Thus, if the IM Sender would like an IMDN, the IM for this purpose. Thus, if the IM Sender would like an IMDN, the IM
Sender MUST include the DateTime CPIM header field. Sender MUST include the DateTime CPIM header field.
7.1.1.3. Adding a Disposition-Notification Header Field 7.1.1.3. Adding a Disposition-Notification Header Field
The Disposition-Notification conveys the type of disposition The Disposition-Notification conveys the type of disposition
notification requested by the IM sender. There are three types of notification requested by the IM sender. There are three types of
disposition notification: delivery, processing, and read. The disposition notification: delivery, processing, and display. The
delivery notification is further subdivided into failure and success delivery notification is further subdivided into failure and success
delivery notifications. An IM Sender requests failure delivery delivery notifications. An IM Sender requests failure delivery
notification by including a Disposition-Notification header field notification by including a Disposition-Notification header field
with value "negative-delivery". Similarly, a success notification is with value "negative-delivery". Similarly, a success notification is
requested by including a Disposition-Notification header field with requested by including a Disposition-Notification header field with
value "positive-delivery". The IM Send can request both types of value "positive-delivery". The IM Send can request both types of
delivery notifications for the same IM. delivery notifications for the same IM.
The IM Sender can request a processing notification by including a The IM Sender can request a processing notification by including a
Disposition-Notification header field with value "processing". Disposition-Notification header field with value "processing".
The IM Sender can also request a read notification. The IM Sender The IM Sender can also request a display notification. The IM Sender
MUST include a Disposition-Notification header field with the value MUST include a Disposition-Notification header field with the value
"read" to request a read request. "display" to request a display IMDN.
The absence of this header field or the presence of the header field The absence of this header field or the presence of the header field
with an empty value indicates that the IM Sender is not requesting with an empty value indicates that the IM Sender is not requesting
any IMDNs. Disposition-Notification header field values are comma any IMDNs. Disposition-Notification header field values are comma
separated. The IM Sender MAY request more than one type of IMDN for separated. The IM Sender MAY request more than one type of IMDN for
a single IM. a single IM.
Future extensions may define other disposition notifications not Future extensions may define other disposition notifications not
defined in this document. defined in this document.
Section 10 describes the formal syntax for the Disposition- Section 10 describes the formal syntax for the Disposition-
Notification header field. The following is an example CPIM body of Notification header field. The following is an example CPIM body of
an IM where the IM Sender requests positive and negative delivery an IM where the IM Sender requests positive and negative delivery
notifications, but neither read notification nor processing notifications, but neither display notification nor processing
notifications: notifications:
From: Alice <im:alice@example.com> From: Alice <im:alice@example.com>
To: Bob <im:bob@example.com> To: Bob <im:bob@example.com>
NS: imdn <urn:ietf:params:imdn> NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: 34jk324j imdn.Message-ID: 34jk324j
DateTime: 2006-04-04T12:16:49-05:00 DateTime: 2006-04-04T12:16:49-05:00
imdn.Disposition-Notification: positive-delivery, negative-delivery imdn.Disposition-Notification: positive-delivery, negative-delivery
Content-type: text/plain Content-type: text/plain
Content-length: 12 Content-length: 12
skipping to change at page 11, line 45 skipping to change at page 12, line 18
Clearly, if an IM Sender loses its sent items state, for example, the Clearly, if an IM Sender loses its sent items state, for example, the
user deletes items from the "Send Items" box, the client may use a user deletes items from the "Send Items" box, the client may use a
different display strategy in response to apparently unsolicited different display strategy in response to apparently unsolicited
IMDNs. IMDNs.
This specification also does not mandate an IM Sender to run any This specification also does not mandate an IM Sender to run any
timers waiting for an IMDN. There are no time limits associated with timers waiting for an IMDN. There are no time limits associated with
when IMDNs may be received. when IMDNs may be received.
IMDNs may legitimately never be received. Likewise, the recipient IMDNs may legitimately never be received, so the time between the
may take a long time to actually read the message, so the time sending of an IM and the generation and ultimate receipt of the IMDN
between the sending of an IM and the generation and ultimate receipt may simply take a very long time. Some clients may choose to purge
of the IMDN may simply take a very long time. Some clients may the state associated with the sent IM. This is the reason for adding
choose to purge the state associated with the sent IM. This is the the time stamp in the IM and having it returned in the IMDN. This
reason for adding the time stamp in the IM and having it returned in gives the user some opportunity of remembering what IM was sent. For
the IMDN. This gives the user some opportunity of remembering what example if the IMDN indicates that the IM the user sent at 2 p.m.
IM was sent. For example if the IMDN indicates that the IM the user last Thursday was delivered, the user has a chance of remembering
sent at 2 p.m. last Thursday was delivered, the user has a chance of that they sent an IM at 2 p.m. last Thursday.
remembering that they sent an IM at 2 p.m. last Thursday.
7.1.4. Aggregation of IMDNs 7.1.4. Aggregation of IMDNs
An IM Sender may send an IM to multiple recipients in one Transport An IM Sender may send an IM to multiple recipients in one Transport
Protocol Message (typically using a URI-List server Protocol Message (typically using a URI-List server
[I-D.ietf-sip-uri-list-message]) and request IMDNs. An IM Sender [I-D.ietf-sip-uri-list-message]) and request IMDNs. An IM Sender
that requested IMDNs MUST be prepared to receive multiple aggregated that requested IMDNs MUST be prepared to receive multiple aggregated
or non-aggregated IMDNs. See Section 8.2 for details. or non-aggregated IMDNs. See Section 8.2 for details.
7.2. IM Recipient 7.2. IM Recipient
7.2.1. Constructing IMDNs 7.2.1. Constructing IMDNs
IM recipients examine the contents of the Disposition-Notification IM recipients examine the contents of the Disposition-Notification
header field of the CPIM message to determine if the recipient needs header field of the CPIM message to determine if the recipient needs
to generate an IMDN for that IM. Disposition-Notification header to generate an IMDN for that IM. Disposition-Notification header
fields of CPIM messages can include one or more values. IM fields of CPIM messages can include one or more values. IM
recipients may need to generate zero, one, or more IMDNs for that IM, recipients may need to generate zero, one, or more IMDNs for that IM,
for example a delivery notification as well as a read notification. for example a delivery notification as well as a display
In this case, the IM Recipient MUST be able to construct multiple notification. In this case, the IM Recipient MUST be able to
IMDNs per IM. An IM Recipient MUST NOT construct more than one IMDN construct multiple IMDNs per IM. An IM Recipient MUST NOT construct
per disposition type. That is, it must not generate a delivery more than one IMDN per disposition type. That is, it must not
notification indicating "delivered" then followed by a delivery generate a delivery notification indicating "delivered" then followed
notification indicating "failed" for the same IM. If the IM Sender by a delivery notification indicating "failed" for the same IM. If
requested only failure notifications and the IM was successfully the IM Sender requested only failure notifications and the IM was
delivered, then no IMDNs will be generated. If the IM recipient does successfully delivered, then no IMDNs will be generated. If the IM
not understand a value of the Disposition-Notification header field, recipient does not understand a value of the Disposition-Notification
the IM recipient ignores that value. header field, the IM recipient ignores that value.
The IM Recipient MUST NOT generate "processing" notifications. The IM Recipient MUST NOT generate "processing" notifications.
A Disposition-Notification header field MUST NOT appear in an IMDN A Disposition-Notification header field MUST NOT appear in an IMDN
since it is forbidden to request an IMDN for an IMDN. An IM Sender since it is forbidden to request an IMDN for an IMDN. An IM Sender
MUST ignore a delivery notification request in an IMDN if present. MUST ignore a delivery notification request in an IMDN if present.
The IM Sender MUST NOT send an IMDN for an IMDN. The IM Sender MUST NOT send an IMDN for an IMDN.
An IMDN MUST contain a Message-ID header field. The same rules of An IMDN MUST contain a Message-ID header field. The same rules of
uniqueness for the Message-ID header field that appears in an IM uniqueness for the Message-ID header field that appears in an IM
skipping to change at page 13, line 9 skipping to change at page 13, line 29
An IM may contain an IMDN-Record-Route header field (see Section 8 An IM may contain an IMDN-Record-Route header field (see Section 8
for details). If IMDN-Record-Route header fields appear in the IM, for details). If IMDN-Record-Route header fields appear in the IM,
the IM Recipient constructing the IMDN MUST copy the contents of the the IM Recipient constructing the IMDN MUST copy the contents of the
IMDN-Record-Route header fields into IMDN-Route header fields in the IMDN-Record-Route header fields into IMDN-Route header fields in the
IMDN and maintain the order. The IMDN is then sent to the URI in the IMDN and maintain the order. The IMDN is then sent to the URI in the
top IMDN-Route header field. IMDN-Record-Route header fields do not top IMDN-Route header field. IMDN-Record-Route header fields do not
make sense in an IMDN and therefore MUST NOT be placed in an IMDN. make sense in an IMDN and therefore MUST NOT be placed in an IMDN.
IMDN Recipients MUST ignore it if present. IMDN Recipients MUST ignore it if present.
If there is no IMDN-Record-Route header field, the IM Recipient MUST
send the IMDN to the URI in the From header field.
As stated in CPIM [RFC3862], CPIM messages may need to support MIME As stated in CPIM [RFC3862], CPIM messages may need to support MIME
headers other than Content-type. IM Recipients MUST insert a headers other than Content-type. IM Recipients MUST insert a
Content-Disposition header field, set to the value "notification". Content-Disposition header field, set to the value "notification".
This indicates to the IM Sender that the message is an IMDN to an IM This indicates to the IM Sender that the message is an IMDN to an IM
it has earlier sent. it has earlier sent.
7.2.1.1. Constructing Delivery Notifications 7.2.1.1. Constructing Delivery Notifications
The IM Recipient constructs a delivery notification in a similar The IM Recipient constructs a delivery notification in a similar
fashion as an IM, using a CPIM body [RFC3862] that carries a fashion as an IM, using a CPIM body [RFC3862] that carries a
skipping to change at page 13, line 36 skipping to change at page 14, line 14
From: Bob <im:bob@example.com> From: Bob <im:bob@example.com>
To: Alice <im:alice@example.com> To: Alice <im:alice@example.com>
NS: imdn <urn:ietf:params:imdn> NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: d834jied93rf imdn.Message-ID: d834jied93rf
Content-type: message/imdn+xml Content-type: message/imdn+xml
Content-Disposition: notification Content-Disposition: notification
Content-length: ... Content-length: ...
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<imdn xlmns="urn:ietf:params:xml:ns:imdn"> <imdn xmlns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id> <message-id>34jk324j</message-id>
<datetime>2006-04-04T12:16:49-05:00</datetime> <datetime>2008-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri> <recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri> <original-recipient-uri
im:bob@example.com >im:bob@example.com</original-recipient-uri>
</original-recipient-uri> <delivery-notification>
<disposition>
<delivery/>
</disposition>
<status> <status>
<delivered/> <delivered/>
</status> </status>
<note lang="en">The IM was successfully Delivered</note> </delivery-notification>
</imdn> </imdn>
7.2.1.2. Constructing Read Notifications 7.2.1.2. Constructing Display Notifications
The IM Recipient constructs a read notification in a similar fashion The IM Recipient constructs a display notification in a similar
as the delivery notification. See Section 7.2.1.1 for details. fashion as the delivery notification. See Section 7.2.1.1 for
details.
Section 10 defines the schema for an IMDN. Section 10 defines the schema for an IMDN.
An example looks like the following: An example looks like the following:
From: Bob <im:bob@example.com> From: Bob <im:bob@example.com>
To: Alice <im:alice@example.com> To: Alice <im:alice@example.com>
NS: imdn <urn:ietf:params:imdn> NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: dfjkleriou432333 imdn.Message-ID: dfjkleriou432333
Content-type: message/imdn+xml Content-type: message/imdn+xml
Content-Disposition: notification Content-Disposition: notification
Content-length: ... Content-length: ...
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<imdn xlmns="urn:ietf:params:xml:ns:imdn"> <imdn xmlns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id> <message-id>34jk324j</message-id>
<datetime>2006-04-04T12:16:49-05:00</datetime> <datetime>2008-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri> <recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri> <original-recipient-uri
im:bob@example.com >im:bob@example.com</original-recipient-uri>
</original-recipient-uri> <display-notification>
<disposition>
<read/>
</disposition>
<status> <status>
<read/> <displayed/>
</status> </status>
<note lang="en">The IM has been read</note> </display-notification>
</imdn> </imdn>
There are situations where the IM Recipient cannot determine if or There are situations where the IM Recipient cannot determine if or
when the IM has been read. The IM Recipient in this case generates a when the IM has been displayed. The IM Recipient in this case
read notification with a <status> value of "error" to indicate an generates a display notification with a <status> value of "error" to
internal error by the server. Note that the IM Recipient may choose indicate an internal error by the server. Note that the IM Recipient
to ignore any IMDN requests and not to send any IMDNs. An IM may choose to ignore any IMDN requests and not to send any IMDNs. An
recipient may not wish to let a sender know she read, or did not IM recipient may not wish to let a sender know if a particular
read, a particular message. Likewise, she may not want anyone to message has been displayed to her or not. This could be on a per-
know if she reads messages. This could be on a per-message, per- message, per-sender, or programmed policy choice.
sender, or programmed policy choice.
8. Intermediary Behaviour 8. Intermediary Behaviour
In this context, intermediaries are application servers (including In this context, intermediaries are application servers (including
URI-List servers and Store-and-Forward server) and gateways. A URI-List servers and Store-and-Forward server) and gateways. A
gateway is a server that translates between different IM systems that gateway is a server that translates between different IM systems that
use different protocols. use different protocols.
A URI-List server may change the IM Recipient address from its own to A URI-List server may change the IM Recipient address from its own to
the address of the final recipient of that IM for every copy it makes the address of the final recipient of that IM for every copy it makes
that it sends to the list members (see that it sends to the list members (see
[I-D.ietf-sip-uri-list-message] for details). In this case, if the [I-D.ietf-sip-uri-list-message] for details). In this case, if the
IM Sender is requesting an IMDN, the intermediary SHOULD add an IM Sender is requesting an IMDN, the intermediary SHOULD add an
Original-To header field to the IM populating it with the address Original-To header field to the IM populating it with the address
that was in the CPIM To header field before it was changed. That is, that was in the CPIM To header field before it was changed. That is,
the intermediary populates the Original-To header field with the the intermediary populates the Original-To header field with the
intermediary address. Of course, one may configure an intermediary intermediary address. Of course, one may configure an intermediary
to restrict it from re-writing or populating the Original-To field. to restrict it from rewriting or populating the Original-To field.
An intermediary MUST NOT add an Original-To header field if one An intermediary MUST NOT add an Original-To header field if one
already exists. An intermediary MAY have an administrative already exists. An intermediary MAY have an administrative
configuration to not reveal the original Request-URI, and as such, configuration to not reveal the original Request-URI, and as such,
MUST NOT add an Original-To header. MUST NOT add an Original-To header.
An intermediary MAY choose to remain on the path of IMDNs for a An intermediary MAY choose to remain on the path of IMDNs for a
specific IM. It can do so by adding a CPIM IMDN-Record-Route header specific IM. It can do so by adding a CPIM IMDN-Record-Route header
field as the top IMDN-Record-Route header field and populating it field as the top IMDN-Record-Route header field. The value of this
with its own address. An intermediary that does not support this field MUST be the intermediary's own address. An intermediary that
extension will obviously not add the IMDN-Record-Route header field. does not support this extension will obviously not add the IMDN-
This allows IMDNs to traverse directly from the IM Recipient to the Record-Route header field. This allows IMDNs to traverse directly
IM Sender even if the IM traversed an intermediary not supporting from the IM Recipient to the IM Sender even if the IM traversed an
this extension. intermediary not supporting this extension.
An intermediary receiving an IMDN checks the top IMDN-Route header An intermediary receiving an IMDN checks the top IMDN-Route header
field. If that header field carries the intermediary address, the field. If that header field carries the intermediary address, the
intermediary removes that value and forwards the IMDN to the address intermediary removes that value and forwards the IMDN to the address
indicated in the now top IMDN-Route header field. If no additional indicated in the now top IMDN-Route header field. If no additional
IMDN-Route header fields are present, the IMDN is forwarded to the IMDN-Route header fields are present, the IMDN is forwarded to the
address in the CPIM To header field. address in the CPIM To header field.
An intermediary MUST remove any information about the final An intermediary MUST remove any information about the final
recipients of a list if the list membership is not disclosed. The recipients of a list if the list membership is not disclosed. The
skipping to change at page 16, line 28 skipping to change at page 17, line 13
An example looks like the following: An example looks like the following:
Content-type: Message/CPIM Content-type: Message/CPIM
From: Bob <im:bob@example.com> From: Bob <im:bob@example.com>
To: Alice <im:alice@example.com> To: Alice <im:alice@example.com>
Content-type: message/imdn+xml Content-type: message/imdn+xml
Content-Disposition: notification Content-Disposition: notification
Content-length: ... Content-length: ...
<imdn> <?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id> <message-id>34jk324j</message-id>
<datetime>2006-04-04T12:16:49-05:00</datetime> <datetime>2008-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri> <recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri> <original-recipient-uri
im:bob@example.com >im:bob@example.com</original-recipient-uri>
</original-recipient-uri> <processing-notification>
<disposition>
<processing/>
</disposition>
<status> <status>
<processed/> <processed/>
</status> </status>
<note lang="en">The IM has been processed</note> </processing-notification>
</imdn> </imdn>
There are situations where the intermediary cannot know the fate of There are situations where the intermediary cannot know the fate of
an IM. The intermediary in this case generates a processing an IM. The intermediary in this case generates a processing
notification with a <status> value of "error" to indicate so. notification with a <status> value of "error" to indicate so.
8.2. Aggregation of IMDNs 8.2. Aggregation of IMDNs
As previously described, URI-List servers are intermediaries. As previously described, URI-List servers are intermediaries.
A URI-List server may choose to aggregate IMDNs using local policy A URI-List server may choose to aggregate IMDNs using local policy
for making such a decision or it may send individual IMDNs instead. for making such a decision or it may send individual IMDNs instead.
When a URI-List server receives an IM and decides to aggregate IMDNs, When a URI-List server receives an IM and decides to aggregate IMDNs,
it can wait for a configurable period of time or until all recipients it can wait for a configurable period of time or until all recipients
have sent the IMDN, whichever comes first, before the URI-List server have sent the IMDN, whichever comes first, before the URI-List server
sends an aggregated IMDN. Note that some IMDNs, for example "read" sends an aggregated IMDN. Note that some IMDNs, for example
notifications, may never come due to user settings. It is an "displayed" notifications, may never come due to user settings. It
administrator configuration and an implementation issue how long to is an administrator configuration and an implementation issue how
wait before sending an aggregated IMDN and before a URI-List server long to wait before sending an aggregated IMDN and before a URI-List
removes state for that IM. server removes state for that IM.
A URI-List server MAY choose to send multiple aggregated IMDNs. A A URI-List server MAY choose to send multiple aggregated IMDNs. A
timer can be started and when it fires, the URI-List server can timer can be started and when it fires, the URI-List server can
aggregate whatever IMDNs it has so far for that IM, send the aggregate whatever IMDNs it has so far for that IM, send the
aggregated IMDN and restart the timer for the next batch. This is aggregated IMDN and restart the timer for the next batch. This is
needed for scenarios where the IM Sender has requested more than one needed for scenarios where the IM Sender has requested more than one
IMDN for a specific IM, for example, delivery notifications as well IMDN for a specific IM, for example, delivery notifications as well
as read notifications, or when the URI-List server is short on as display notifications, or when the URI-List server is short on
resources and chooses to prioritise forwarding IMs over IMDNs. resources and chooses to prioritise forwarding IMs over IMDNs.
A second timer can be running and when it fires, the state of the IM A second timer can be running and when it fires, the state of the IM
is deleted. In this case, the URI-List server consumes any IMDNs is deleted. In this case, the URI-List server consumes any IMDNs
that might arrive after that time. that might arrive after that time.
Please note the references to timers in the above paragraphs are not Please note the references to timers in the above paragraphs are not
normative and are only present to help describe one way one might normative and are only present to help describe one way one might
implement aggregation. implement aggregation.
skipping to change at page 18, line 13 skipping to change at page 19, line 18
imdn.Message-ID: d834jied93rf imdn.Message-ID: d834jied93rf
Content-type: multipart/mixed; Content-type: multipart/mixed;
boundary="imdn-boundary" boundary="imdn-boundary"
Content-Disposition: notification Content-Disposition: notification
Content-length: ... Content-length: ...
--imdn-boundary --imdn-boundary
Content-type: message/imdn+xml Content-type: message/imdn+xml
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<imdn xlmns="urn:ietf:params:xml:ns:imdn"> <imdn xmlns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id> <message-id>34jk324j</message-id>
<datetime>2006-04-04T12:16:49-05:00</datetime> <datetime>2008-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri> <recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri> <original-recipient-uri
im:bob@example.com >im:bob@example.com</original-recipient-uri>
</original-recipient-uri> <delivery-notification>
<disposition>
<delivery/>
</disposition>
<status> <status>
<delivered/> <delivered/>
</status> </status>
<note lang="en">The IM was successfully Delivered</note> </delivery-notification>
</imdn> </imdn>
--imdn-boundary --imdn-boundary
Content-type: message/imdn+xml Content-type: message/imdn+xml
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<imdn xlmns="urn:ietf:params:xml:ns:imdn"> <imdn xmlns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id> <message-id>34jk324j</message-id>
<datetime>2006-04-04T12:16:49-05:00</datetime> <datetime>2008-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri> <recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri> <original-recipient-uri
im:bob@example.com >im:bob@example.com</original-recipient-uri>
</original-recipient-uri> <display-notification>
<disposition>
<read/>
</disposition>
<status> <status>
<read/> <displayed/>
</status> </status>
<note lang="en">The IM was successfully Delivered</note> </display-notification>
</imdn> </imdn>
--imdn-boundary --imdn-boundary
9. Identifying Messages 9. Identifying Messages
Messages are typically carried in a transport protocol like SIP Messages are typically carried in a transport protocol like SIP
[RFC3261]. If the payload carried by the transport protocol does not [RFC3261]. If the payload carried by the transport protocol does not
contain any parts of type Message/CPIM then the message is an IM. If contain any parts of type Message/CPIM then the message is an IM. If
the payload contains any parts of type Message/CPIM, and none of the payload contains any parts of type Message/CPIM, and none of
those parts contains a payload that is of type "message/imdn+xml", those parts contains a payload that is of type "message/imdn+xml",
the message is an IM. It is not valid to attempt to carry both an IM the message is an IM. It is not valid to attempt to carry both an IM
and an IMDN in a multipart payload in a single transport protocol and an IMDN in a multipart payload in a single transport protocol
message. message.
A message is identified as a delivery notification by examining its A message is identified as a delivery notification by examining its
contents. The message is a delivery notification if the Content-type contents. The message is a delivery notification if the Content-type
header field present has a value of "message/imdn+xml", the Content- header field present has a value of "message/imdn+xml", the Content-
Disposition header field has a value of "notification", and the Disposition header field has a value of "notification", and the
<disposition> element in that xml body has a sub-element <delivery>. <delivery-notification> element appears in that xml body.
A message is identified as a processing notification or read A message is identified as a processing notification or display
notification in a similar fashion as a delivery notification. The notification in a similar fashion as a delivery notification. The
difference is that the <disposition> element in that xml body has a difference is that for a processing notification, the <processing-
sub-element of <processing> and <read> respectively. notification> element appears in the xml body. For a display
notification, the <display-notification> element appears in the xml
body.
10. Header Fields Formal Syntax 10. Header Fields Formal Syntax
The following syntax specification uses the message header field The following syntax specification uses the message header field
syntax as described in Section 3 of RFC 3862 [RFC3862]. syntax as described in Section 3 of RFC 3862 [RFC3862].
Header field syntax is described without a name space qualification. Header field syntax is described without a name space qualification.
Following the rules in RFC 3862 [RFC3862], header field names and Following the rules in RFC 3862 [RFC3862], header field names and
other text are case sensitive and MUST be used as given, using other text are case sensitive and MUST be used as given, using
exactly the indicated upper case and lower case letters. exactly the indicated upper case and lower case letters.
Disposition-Notification = Disposition-Notification =
"Disposition-Notification" ": " "Disposition-Notification" ": "
[(notify-req *(COMMA notify-req))] [(notify-req *(COMMA notify-req))]
notify-req = notify-req =
("negative-delivery" / "positive-delivery" / ("negative-delivery" / "positive-delivery" /
"processing" / "read" / Token) *(SEMI disp-notif-params) "processing" / "display" / Token) *(SEMI disp-notify-params)
disp-notify-params = generic-param disp-notify-params = Ext-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 ">"
IMDN-Record-Route = IMDN-Record-Route =
"IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">" "IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">"
IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">" IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">"
SEMI = SP ";" SP ; semicolon
COMMA = SP "," SP ; comma
11. IMDN Format 11. IMDN Format
11.1. Structure of XML-Encoded IMDN Payload 11.1. Structure of XML-Encoded IMDN Payload
An IMDN Payload is an XML document [XML] that MUST be well formed and An IMDN Payload is an XML document [XML] that MUST be well formed and
MUST be valid according to schemas, including extension schemas, MUST be valid according to schemas, including extension schemas,
available to the validater and applicable to the XML document. The available to the validater and applicable to the XML document. The
IMDN Payload MUST be based on XML 1.0 and MUST be encoded using IMDN Payload MUST be based on XML 1.0 and MUST be encoded using
UTF-8. UTF-8.
The schema allows qualified extension elements in several positions
other than the "urn:ietf:params:xml:ns:imdn" namespace. To maintain
forwards compatibility (newer instance documents can be used by
existing consumers) the new specifications MUST NOT extend the
allowable content of this specification. The backwards compatibility
(existing instance documents can also be used by updated new
consumers) MAY break if there are conflicts with the existing
qualified names of extension elements and possible new
specifications. The IETF MAY specify new extension elements within
the "sub-namespace" of "urn:ietf:params:xml:ns:" for this message/
imdn+xml MIME type.
Possible future specifications can add new element definitions with
the combine="interleave" pattern. When multiple new elements of this
type are then allowed, the new definition MUST contain the
<oneOrMore> cardinality. Also the new specification MUST then re-
define either the "anyIMDN" extension, or the individual extension
points which reference it, so that the new element definitions do not
match with this redefined, and more limited pattern.
The name space identifier for elements defined by this specification The name space identifier for elements defined by this specification
is a URN [URN], using the name space identifier 'ietf' defined by is a URN [URN], using the name space identifier 'ietf' defined by
[URN_NS] and extended by [IANA]. This urn is: [URN_NS] and extended by [IANA]. This urn is:
urn:ietf:params:xml:ns:imdn. urn:ietf:params:xml:ns:imdn.
This name space declaration indicates the name space on which the This name space declaration indicates the name space on which the
IMDN is based. IMDN is based.
The root element is <imdn>. The <imdn> element has sub-elements, The root element is <imdn>. The <imdn> element has sub-elements,
namely <message-id>, <datetime>, <recipient-uri>, <original- namely <message-id>, <datetime>, <recipient-uri>, <original-
recipient-uri>, <subject>, <disposition>, <status>, and <note>. recipient-uri>, <subject>, and one of <delivery-notification>,
Those elements are described in details in the following sections. <processing-notification> or <display-notification>. A <status> also
appears as a sub-element of <delivery-notification>, <processing-
notification> and <display-notification>. The elements are described
in details in the following sections.
<disposition> and <status> can be extended in the future to include <imdn>, can be extended in the future to include new disposition
new sub-elements not defined in this document, as described in notification types or other elements, as described in Section 11.1.9.
Section 15.3.
11.1.1. The <message-id> Element 11.1.1. The <message-id> Element
The <message-id> element is mandatory according to the XML schema and The <message-id> element is mandatory according to the XML schema and
carries the message id that appeared in the Message-ID header field carries the message id that appeared in the Message-ID header field
of the IM. of the IM.
11.1.2. The <datetime> Element 11.1.2. The <datetime> Element
The <datetime> element is mandatory and carries the date and time the The <datetime> element is mandatory and carries the date and time the
skipping to change at page 21, line 32 skipping to change at page 23, line 14
11.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 original recipient. It MUST be present if the IM carried the of the original recipient. It MUST be present if the IM carried the
Original-To header field. This information is obtained from the Original-To header field. This information is obtained from the
Original-To header field of the IM. Original-To header field of the IM.
11.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. If present it MUST cary the text
the Subject header field, if any. This allows for a human level and, if present, language attribute, that was in the Subject header
correlation between an IM and an IMDN. field, if any. This allows for a human level correlation between an
IM and an IMDN. If there are more than one Subject header fields in
an IM, selecting any one of them to place in the IMDN payload
<subject> element will suffice. The sender then needs to compare
Subject header fields until a match or not match is determined.
11.1.6. The <disposition> Element 11.1.6. The <delivery-notification>, <processing-notification> and
<display-notification> Elements
The <disposition> element is mandatory and carries the disposition The appearance of one of the <delivery-notification>, <processing-
type that the IM Sender requested and is being reported. It can notification> and <display-notification> elements is mandatory and
carry one of the sub-elements <delivery>, <processing>, <read> or any carries the disposition type that the IM Sender requested and is
other future extension. being reported. It carries the sub-element <status>.
11.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. For disposition disposition request. For notification type <delivery-notification>,
type <delivery>, it can carry one of the sub-elements <delivered>, it can carry one of the sub-elements <delivered>, <failed>,
<failed>, <forbidden> or <error>. For disposition type <read>, it <forbidden> or <error>. For notification type <display-
can carry one of the sub-elements <read>, <forbidden> or <error>. notification>, it can carry one of the sub-elements <displayed>,
For disposition type <processing>, it can carry one of the sub- <forbidden> or <error>. For notification type <processing-
elements <processed>, <stored>, <forbidden> or <error>. <forbidden> notification>, it can carry one of the sub-elements <processed>,
means the disposition was denied. <error> means internal server <stored>, <forbidden> or <error>. <forbidden> means the disposition
error. It can also carry any other future extension. was denied. <error> means internal server error. It can also be
extended to carry any other status extension.
11.1.8. The <note> Element
The <note> element is optional and carries a human readable text. It
has the "lang" attribute that indicates the language the text is
written in.
11.2. MIME Type for IMDN Payload 11.1.8. MIME Type for IMDN Payload
The MIME type for the IMDN Payload is "message/imdn+xml". The IMDN The MIME type for the IMDN Payload is "message/imdn+xml". The IMDN
MUST identify the payload as MIME type "message/imdn+xml" in the MUST identify the payload as MIME type "message/imdn+xml" in the
Content-type header field. Content-type header field.
11.3. The RelaxNG Schema 11.1.9. The RelaxNG Schema
<?xml version="1.0" encoding="UTF-8"?>
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<grammar <grammar
xmlns="http://relaxng.org/ns/structure/1.0" xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"
ns="urn:ietf:params:xml:ns:imdn"> ns="urn:ietf:params:xml:ns:imdn">
<start> <start>
<element name="imdn"> <element name="imdn">
<element name="message-id"> <element name="message-id">
skipping to change at page 22, line 41 skipping to change at page 24, line 24
<element name="datetime"> <element name="datetime">
<data type="string"/> <data type="string"/>
</element> </element>
<optional> <optional>
<element name="recipient-uri"> <element name="recipient-uri">
<data type="anyURI"/> <data type="anyURI"/>
</element> </element>
<element name="original-recipient-uri"> <element name="original-recipient-uri">
<data type="anyURI"/> <data type="anyURI"/>
</element> </element>
<optional>
<element name="subject"> <element name="subject">
<data type="string"/> <data type="string"/>
</element> </element>
</optional> </optional>
</optional>
<choice> <choice>
<ref name="deliveryNotification"/> <ref name="deliveryNotification"/>
<ref name="readNotification"/> <ref name="readNotification"/>
<ref name="processingNotification"/> <ref name="processingNotification"/>
<zeroOrMore>
<empty/> <empty/>
</zeroOrMore>
</choice> </choice>
<ref name="note"/> <ref name="imdnExtension"/>
<zeroOrMore>
<ref name="Extension"/>
</zeroOrMore>
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</element> </element>
</start> </start>
<define name="deliveryNotification"> <define name="deliveryNotification">
<element name="disposition"> <element name="delivery-notification">
<element name="delivery">
<empty/>
</element>
</element>
<element name="status"> <element name="status">
<choice> <choice>
<element name="delivered"> <element name="delivered">
<empty/> <empty/>
</element> </element>
<element name="failed"> <element name="failed">
<empty/> <empty/>
</element> </element>
<ref name="commonDispositionStatus"></ref> <ref name="commonDispositionStatus"></ref>
<zeroOrMore>
<ref name="Extension"/>
</zeroOrMore>
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</choice> </choice>
<ref name="deliveryExtension"/>
</element>
</element> </element>
</define> </define>
<define name="readNotification"> <define name="readNotification">
<element name="disposition"> <element name="read-notification">
<element name="read">
<empty/>
</element>
</element>
<element name="status"> <element name="status">
<choice> <choice>
<element name="read"> <element name="read">
<empty/> <empty/>
</element> </element>
<ref name="commonDispositionStatus"></ref> <ref name="commonDispositionStatus"></ref>
<zeroOrMore>
<ref name="Extension"/>
</zeroOrMore>
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</choice> </choice>
<ref name="readExtension"/>
</element>
</element> </element>
</define> </define>
<define name="processingNotification"> <define name="processingNotification">
<element name="disposition"> <element name="processing-notification">
<element name="processing">
<empty/>
</element>
</element>
<element name="status"> <element name="status">
<choice> <choice>
<element name="processed"> <element name="processed">
<empty/> <empty/>
</element> </element>
<element name="stored"> <element name="stored">
<empty/> <empty/>
</element> </element>
<ref name="commonDispositionStatus"></ref> <ref name="commonDispositionStatus"></ref>
<zeroOrMore>
<ref name="Extension"/>
</zeroOrMore>
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</choice> </choice>
<ref name="processingExtension"/>
</element>
</element> </element>
</define> </define>
<define name="commonDispositionStatus"> <define name="commonDispositionStatus">
<choice> <choice>
<element name="forbidden"> <element name="forbidden">
<empty/> <empty/>
</element> </element>
<element name="error"> <element name="error">
<empty/> <empty/>
</element> </element>
</choice>
</define>
<!-- <imdn> extension point for the extension schemas to add
new definitions with the combine="interleave" pattern.
Extension schemas should add proper cardinalities,
i.e. <zeroOrMore> enclosed e.g. with the new element
if multiple new elements are allowed, and <optional>
if a single new element is allowed -->
<define name="imdnExtension">
<zeroOrMore> <zeroOrMore>
<ref name="Extension"/> <ref name="anyIMDN"/>
</zeroOrMore> </zeroOrMore>
</define>
<!-- delivery-notification <status> extension point -->
<define name="deliveryExtension">
<zeroOrMore> <zeroOrMore>
<ref name="anyIMDN"/> <ref name="anyIMDN"/>
</zeroOrMore> </zeroOrMore>
</choice>
</define> </define>
<define name="note"> <!-- read-notification <status> extension point -->
<element name="note"> <define name="readExtension">
<optional> <zeroOrMore>
<attribute> <ref name="anyIMDN"/>
<name ns="http://www.w3.org/XML/1998/namespace"> </zeroOrMore>
lang
</name>
<data type="language"/>
</attribute>
</optional>
<data type="string"/>
</element>
</define> </define>
<define name="Extension"> <!-- processing-notification <status> extension point -->
<empty/> <define name="processingExtension">
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</define> </define>
<!-- wildcard definition for complex elements (of mixed type)
unqualified or qualified in the imdn namespace.
Extension schemas MUST redefine this or the
individual previous definitions which use this definition.
In other words, the extension schema MUST reduce the
allowable content in order to maintain deterministic
and unambiquous schemas with the interleave pattern. -->
<define name="anyIMDN"> <define name="anyIMDN">
<element> <element>
<anyName> <anyName>
<except> <except>
<nsName ns="urn:ietf:params:xml:ns:imdn"/> <nsName ns="urn:ietf:params:xml:ns:imdn"/>
<nsName ns=""/> <nsName ns=""/>
</except> </except>
</anyName> </anyName>
<mixed> <ref name="anyExtension"/>
</element>
</define>
<!-- the rest of the "anyIMDN" wildcard definition -->
<define name="anyExtension">
<zeroOrMore> <zeroOrMore>
<choice> <choice>
<attribute> <attribute>
<anyName/> <anyName/>
</attribute> </attribute>
<ref name="anyIMDN"/> <ref name="any"/>
</choice>
</zeroOrMore>
</define>
<!-- wildcard type for complex elements (of mixed type)
without any namespace or content restrictions -->
<define name="any">
<element>
<anyName/>
<zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<text/>
<ref name="any"/>
</choice> </choice>
</zeroOrMore> </zeroOrMore>
</mixed>
</element> </element>
</define> </define>
</grammar> </grammar>
12. Transporting Messages using SIP 12. Transporting Messages using SIP
12.1. Endpoint Behaviour 12.1. Endpoint Behaviour
12.1.1. Sending Requests 12.1.1. Sending Requests
skipping to change at page 26, line 26 skipping to change at page 28, line 13
Section 7. Section 7.
The IM Sender constructs a SIP MESSAGE request to multiple recipients The IM Sender constructs a SIP MESSAGE request to multiple recipients
in a similar manner as a SIP MESSAGE request to a single recipient. in a similar manner as a SIP MESSAGE request to a single recipient.
Multiple-Recipient MESSAGE Requests in SIP Multiple-Recipient MESSAGE Requests in SIP
[I-D.ietf-sip-uri-list-message] describes the differences. [I-D.ietf-sip-uri-list-message] describes the differences.
IM senders can remain anonymous. For example, the sender can set the IM senders can remain anonymous. For example, the sender can set the
SIP From header field of the SIP message to an anonymous URI. As SIP From header field of the SIP message to an anonymous URI. As
there is no return address, anonymous IM senders SHOULD NOT request there is no return address, anonymous IM senders SHOULD NOT request
disposition notifications. An IM Recipient can ignore such request disposition notifications. An IM Recipient MAY ignore such request
if the IM Sender is anonymous. if the IM Sender is anonymous.
12.1.2. Sending Responses 12.1.2. Sending Responses
An endpoint receiving a SIP MESSAGE request constructs a SIP response An endpoint receiving a SIP MESSAGE request constructs a SIP response
according to RFC 3428 [RFC3428]. Of course, an endpoint will send a according to RFC 3428 [RFC3428]. Of course, an endpoint will send a
SIP response to the MESSAGE request regardless of the type of message SIP response to the MESSAGE request regardless of the type of message
(IM or IMDN) is has received, or the disposition type it has been (IM or IMDN) is has received, or the disposition type it has been
asked for. asked for.
skipping to change at page 27, line 21 skipping to change at page 29, line 8
any internal timers fire waiting for a response). The negative- any internal timers fire waiting for a response). The negative-
delivery notification is constructed according to Section 7.2.1.1. delivery notification is constructed according to Section 7.2.1.1.
The message is then placed as the payload in a SIP MESSAGE request. The message is then placed as the payload in a SIP MESSAGE request.
If an IM Recipient received a SIP MESSAGE request that is an IM that If an IM Recipient received a SIP MESSAGE request that is an IM that
requested a negative-delivery notification, and the IM Recipient has requested a negative-delivery notification, and the IM Recipient has
constructed and sent an non-2xx final response, it MUST NOT generate constructed and sent an non-2xx final response, it MUST NOT generate
a negative-delivery notification. a negative-delivery notification.
If an IM Recipient received a SIP MESSAGE request that is an IM that If an IM Recipient received a SIP MESSAGE request that is an IM that
requested a read notification, and that IM Recipient has constructed requested a display notification, and that IM Recipient has
and sent a SIP 2xx class response, it MAY generate a read constructed and sent a SIP 2xx class response, it MAY generate a
notification after making sure that the IM has been presented to the display notification after making sure that the IM has been presented
user or application. It is outside the scope of this document how to the user or application. It is outside the scope of this document
such determination can be made. Note that the option to send a read how a determination can be made whether the IM has been read. Note
notification or not can be left to the user. An application may that the option to send a display notification or not can be left to
allow a user to configure such choice. The IM Recipient constructs the user. An application may allow a user to configure such choice.
the read notification according to Section 7.2.1.2. The IM Recipient The IM Recipient constructs the display notification according to
places the message as the payload in a SIP MESSAGE request. Section 7.2.1.2. The IM Recipient places the message as the payload
in a SIP MESSAGE request.
For IMDNs, the IM Recipient populates the SIP Request-URI and the SIP For IMDNs, the IM Recipient populates the SIP Request-URI and the SIP
To header field using the address that appeared in the SIP From To header field using the address that appeared in the SIP From
header field in the IM. header field in the IM.
12.1.3.2. Delivery Notification 12.1.3.2. Delivery Notification
A SIP MESSAGE request is identified as delivery notification by A SIP MESSAGE request is identified as delivery notification by
examining its contents according to Section 9. examining its contents according to Section 9.
12.1.3.3. Read Notification 12.1.3.3. Display Notification
A SIP MESSAGE request is identified as read notification by examining A SIP MESSAGE request is identified as display notification by
its contents according to Section 9. examining its contents according to Section 9.
12.2. Intermediary Behaviour 12.2. Intermediary Behaviour
In this context, intermediaries include application servers, In this context, intermediaries include application servers,
including URI-List servers, Store-and-Forward servers, and gateways. including URI-List servers, Store-and-Forward servers, and gateways.
SIP Proxies MUST NOT generate IMDNs but MUST forward them like any SIP Proxies MUST NOT generate IMDNs but MUST forward them like any
other SIP request. other SIP request.
Intermediaries forward a SIP MESSAGE request to multiple recipients Intermediaries forward a SIP MESSAGE request to multiple recipients
according to [I-D.ietf-sip-uri-list-message]. according to [I-D.ietf-sip-uri-list-message].
skipping to change at page 28, line 43 skipping to change at page 30, line 33
after it has forwarded or stored the IM. The rest of the procedures after it has forwarded or stored the IM. The rest of the procedures
in Section 8.1 apply. in Section 8.1 apply.
The procedure for generating such IMDN is the same as that of an IM The procedure for generating such IMDN is the same as that of an IM
Recipient (Section 7.2.1.1). 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 IM Recipient. of the IM Recipient.
If an intermediary receives a SIP MESSAGE request carrying a positive If an intermediary receives a SIP MESSAGE request carrying a positive
delivery notification or a read notification, it forwards it using delivery notification or a display notification, it forwards it using
the rules in Section 8. the rules in Section 8.
13. Transporting Messages using MSRP 13. Transporting Messages using MSRP
MSRP already provides a built-in mechanism to supply positive and MSRP [RFC4975] already provides a built-in mechanism to supply
negative delivery reports. These reports do not provide built-in positive and negative delivery reports. These reports do not provide
Read or Processing notifications. However, these notifications in built-in Display or Processing notifications. However, these
session mode are not as useful as they are for page-mode. This is notifications in session mode are not as useful as they are for page-
because the base use case for MSRP is that the recipient user agent mode. This is because the base use case for MSRP is that the
immediately renders SEND requests sequentially, providing the session recipient user agent immediately renders SEND requests sequentially,
experience. This is unlike page-mode requests where a user has to providing the session experience. This is unlike page-mode requests
actively read the message. That is, they need to click on a button, where a user has to actively initiate the display of the message.
open a message, and so on to read the message. That is, they need to click on a button, open a message, and so on to
read the message.
If new requirements arise in the future determining the need for IMDN If new requirements arise in the future determining the need for IMDN
in MSRP, new specifications can be drafted. in MSRP, new specifications can be drafted.
14. Security Considerations 14. Security Considerations
IMDNs provide a fine-grained view of the activity of the IM Recipient IMDNs provide a fine-grained view of the activity of the IM Recipient
and thus deserves particularly careful confidentiality protection so and thus deserves particularly careful confidentiality protection so
that only the intended recipient of the IMDN will receive the IMDN. that only the intended recipient of the IMDN will receive the IMDN.
In most cases, the intended recipient of the IMDN is the IM Sender. In most cases, the intended recipient of the IMDN is the IM Sender.
skipping to change at page 29, line 33 skipping to change at page 31, line 24
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 an IM Sender with IMDNs by o A malicious endpoint attempts to flood an IM Sender with IMDNs by
convincing a URI-List server to send IMDNs to an unsuspecting IM convincing a URI-List server to send IMDNs to an unsuspecting IM
Sender. Sender.
o A malicious intermediary or node attempts to flood a target node
with IMDNs by inserting the target's address in the From field or
IMDN-Record-Route field
o A malicious node in the network that attempts to modify an IMDN o A malicious node in the network that attempts to modify an IMDN
from an IM Recipient. from an IM Recipient.
o A malicious intermediary attempts to forward an IMDN from an IM o A malicious intermediary attempts to forward an IMDN from an IM
Recipient to the IM Sender, where the IM Recipient would not Recipient to the IM Sender, where the IM Recipient would not
normally forward the IMDN to that IM Sender if the IM Recipient normally forward the IMDN to that IM Sender if the IM Recipient
knew the identity of the IM Sender. knew the identity of the IM Sender.
o A malicious endpoint that attempts to discover for a Request-URI o A malicious endpoint that attempts to discover for a Request-URI
of an endpoint beyond an intermediary, where the endpoint would of an 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.
skipping to change at page 30, line 12 skipping to change at page 32, line 4
The protocol cannot protect against attacks that include the The protocol cannot protect against attacks that include the
following: following:
o A malicious intermediary directly revealing the identity of a o A malicious intermediary directly revealing the identity of a
downstream endpoint that would not normally wish its identity downstream endpoint that would not normally wish its identity
revealed. Keeping such information private is an intermediary revealed. Keeping such information private is an intermediary
implementation issue. implementation issue.
o A malicious IM Recipient that alters the time of the IMDN. There o A malicious IM Recipient that alters the time of the IMDN. There
is no protocol mechanism for ensuring that the IM Recipient does is no protocol mechanism for ensuring that the IM Recipient does
not lie about the time or purposely holds an IMDN for transmission not lie about the time or purposely holds an IMDN for transmission
to make it appear that the user read an IM later than they to make it appear that the IM was displayed to the user read later
actually did. than it actually did.
o A deletion attack on an IMDN. This is a trade-off between privacy o A deletion attack on an IMDN. This is a trade-off between privacy
and security. The privacy considerations allow the IM Recipient and security. The privacy considerations allow the IM Recipient
to silently ignore an IMDN request. Any mechanism that would to silently ignore an IMDN request. Any mechanism that would
reliably indicate that a malicious node deleted an IM Recipient's reliably indicate that a malicious node deleted an IM Recipient's
IMDN would also serve the purpose of detecting an IM Recipient IMDN would also serve the purpose of detecting an IM Recipient
that chose not to issue an IMDN. that chose not to issue an IMDN.
To combat eavesdropping, modification, and man-in-the-middle attacks, To combat eavesdropping, modification, and man-in-the-middle attacks,
we require some level of authentication and integrity protections. we require some level of authentication and integrity protections.
That said, there are circumstances where strong integrity would be That said, there are circumstances where strong integrity would be
skipping to change at page 31, line 10 skipping to change at page 32, line 50
One consequence of this choice is it eliminates the possibility of One consequence of this choice is it eliminates the possibility of
having end-to-end encryption. having end-to-end encryption.
An attacker can mount a distributed denial of service attack on a An attacker can mount a distributed denial of service attack on a
node by sending lots of IMs to the node with IMDN requests. Note node by sending lots of IMs to the node with IMDN requests. Note
that this is the same problem as there is without IMDN; IMDN simply that this is the same problem as there is without IMDN; IMDN simply
linearly increases the load on the node under attack. One can linearly increases the load on the node under attack. One can
mitigate, but not eliminate this threat by the endpoint immediately mitigate, but not eliminate this threat by the endpoint immediately
ignoring requests that are not authenticated. ignoring requests that are not authenticated.
One way to address the potential for a malicious node to use the IMDN
system to anonomize attacks is to log all IMDN requests on the IM
Recipient User Agent. This allows for tracking of attacks, if only
after they occur. Note this also puts a burden on the IM Recipient
User Agent host. Limited User Agents may not be able to preserve
much of a log.
Likewise, an attacker can mount a denial of service attack on an Likewise, an attacker can mount a denial of service attack on an
intermediary by asking the intermediary to explode a large list. intermediary by asking the intermediary to explode a large list.
The following security considerations apply when using IMDNs: The following security considerations apply when using IMDNs:
14.1. Forgery 14.1. Forgery
IMs can be forged. To protect against that, an IM can be signed. An IMs can be forged. To protect against that, an IM can be signed. An
intermediary that receives a signed message and needs to modify any intermediary that receives a signed message and needs to modify any
part of it that is included in the signature (like adding an part of it that is included in the signature (like adding an
Original-To header field to the CPIM header fields), MUST consume the Original-To header field to the CPIM header fields), MUST consume the
IM and create a new copy of it that the intermediary signs itself. IM and create a new copy of it that the intermediary signs itself.
IMDNs may be forged as easily as ordinary IMs. Endpoints and IMDNs may be forged as easily as ordinary IMs. Endpoints and
intermediaries that wish to make automatic use of IMDNs should take intermediaries that wish to make automatic use of IMDNs should take
appropriate precautions to minimize the potential damage from denial- appropriate precautions to minimize the potential damage from denial-
of-service attacks. Security threats related to forged IMDNs include of-service attacks. Security threats related to forged IMDNs include
the sending of a falsified IMDN when the indicated disposition of the the sending of a falsified IMDN when the indicated disposition of the
IM has not actually occurred. For example, read notification could IM has not actually occurred. For example, display notification
be forged to indicate that an IM Recipient has read the IM. could be forged to indicate that an IM has been displayed to the
Unsolicited IMDNs is also another form of forgery. Recipient. Unsolicited IMDNs is also another form of forgery.
14.2. Confidentiality 14.2. Confidentiality
There may be cases where an IM Recipient does not wish to reveal the There may be cases where an IM Recipient does not wish to reveal the
information that he has received or in fact read the IM. In this information that he has received or in fact read the IM. In this
situation, it is acceptable for the IM Recipient to silently ignore situation, it is acceptable for the IM Recipient to silently ignore
requests for an IMDN. It is strongly RECOMMENDED that the IM requests for an IMDN. It is strongly RECOMMENDED that the IM
Recipient obtain the user's consent before sending an IMDN. Recipient obtain the user's consent before sending an IMDN.
Circumstances where the IM Recipient does not ask for the user's Circumstances where the IM Recipient does not ask for the user's
consent include IM systems that, for regulatory reasons, are required consent include IM systems that, for regulatory reasons, are required
skipping to change at page 32, line 11 skipping to change at page 34, line 10
There are situations where a user sends an IM and requests IMDNs to a There are situations where a user sends an IM and requests IMDNs to a
list whose member information is not disclosed. In this situation, list whose member information is not disclosed. In this situation,
the user will learn of the list members. Therefore, in this case, the user will learn of the list members. Therefore, in this case,
the URI-List server MUST remove any information about list members. the URI-List server MUST remove any information about list members.
If the number of members in the list is also not disclosed, the URL- If the number of members in the list is also not disclosed, the URL-
List server MUST only deliver one aggregated IMDN. Alternatively, List server MUST only deliver one aggregated IMDN. Alternatively,
the URI-list server MAY reject the IM. the URI-list server MAY reject the IM.
It is possible for a list server to not understand IMDN. IM It is possible for a list server to not understand IMDN. IM
Recipients may note the To is a list name and not the IM Recipient's Recipients may note the To header field is a list name and not the IM
name. In this case, the IM Recipient can take the appropriate action Recipient's name. In this case, the IM Recipient can take the
if it wishes to keep its identity private. appropriate action if it wishes to keep its identity private.
An unencrypted IMDN could reveal confidential information about an An unencrypted IMDN could reveal confidential information about an
encrypted IM. The same level of security applied to an IM MUST be encrypted IM. The same level of security applied to an IM MUST be
applied to its IMDNs. For example, if an IM is signed and encrypted, applied to its IMDNs. For example, if an IM is signed and encrypted,
the IMDN must be signed and encrypted. the IMDN must be signed and encrypted.
14.3. Non-Repudiation 14.3. IMDN as a Certified Delivery Service
IMDNs cannot be relied on as a guarantee that an IM was or was not IMDNs cannot be relied on as a guarantee that an IM was or was not
seen by the user. Even if IMDNs are not actively forged, they may be seen by the user. Even if IMDNs are not actively forged, they may be
lost in transit. Moreover, the IM Recipient may bypass the IMDN lost in transit. Moreover, the IM Recipient may bypass the IMDN
issuing mechanism through policy or manipulation of their User Agent issuing mechanism through policy or manipulation of their User Agent
Server. Server.
15. IANA Considerations 15. IANA Considerations
15.1. message/imdn+xml MIME TYPE 15.1. message/imdn+xml MIME TYPE
skipping to change at page 33, line 27 skipping to change at page 35, line 27
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@gmail.com) (hisham.khartabil@gmail.com)
Intended Usage: COMMON Intended Usage: COMMON
Author/change controller: The IETF . Author/change controller: The IETF .
15.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:imdn 15.2. XML Registration
This section registers a new XML name space, as per guidelines in the This section registers a new XML name space and schema, as per
IETF XML Registry [IANA]. guidelines in the IETF XML Registry [IANA].
URI: The URI for this name space is urn:ietf:params:xml:ns:imdn. URI: The URI for this name space is urn:ietf:params:xml:ns:imdn.
Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil XML: The schema for this name space is in Section 11.1.9 above.
(hisham.khartabil@gmail.com) .
15.3. Schema Registration
This section registers a new XML schema per the procedures in [IANA].
Extensions MUST be standards track documents.
URI: urn:ietf:params:xml:ns:imdn
Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil
(hisham.khartabil@gmail.com) (hisham.khartabil@gmail.com) .
The XML for this schema can be found as the sole content of
Section 11.3.
15.4. Registration for urn:ietf:params:imdn 15.3. Registration for urn:ietf:params:imdn
Registry name: imdn Registry name: imdn
Specification: RFC XXXX. Additional values may be defined by Specification: RFC XXXX. Additional values may be defined by a
standards track RFCs that update or obsolete RFC XXXX (Specification Standards Action [RFC2434] that updates or obsoletes RFC XXXX.
Required).
Repository: http://www.iana.org/assignments/imdn Repository: [RFC EDITOR: fill in by IANA]
Index value: The index value is a CPIM message IMDN header name, Index value: The index value is a CPIM message IMDN header name,
which may consist of a sequence from a restricted set of US-ASCII which may consist of a sequence from a restricted set of US-ASCII
characters, as defined above. characters, as defined above.
URN Formation: The URI for a header is formed from its name by: URN Formation: The URI for a header is formed from its name by:
a) replacing any non-URN characters (as defined by RFC 2141[URN]) a) replacing any non-URN characters (as defined by RFC 2141[URN])
with the corresponding '%hh' escape sequence (per RFC 3986 with the corresponding '%hh' escape sequence (per RFC 3986
[RFC2396]); and [RFC2396]); and
b) prepending the resulting string with 'urn:ietf:params:imdn:'. b) prepending the resulting string with 'urn:ietf:params:imdn:'.
Thus, the URI corresponding to the CPIM message IMDN header Thus, the URI corresponding to the CPIM message IMDN header
'Disposition-Notification:' would be 'Disposition-Notification:' would be
'urn:ietf:params:imdn:Disposition-Notification'. 'urn:ietf:params:imdn:Disposition-Notification'.
15.5. Message/CPIM Header Field Registration Initial values;
This document registers the following message/cpim header fields in
the imdn fields registry:
Disposition-Notification - [RFCXXXX]
Message-ID - [RFCXXXX]
Original-To - [RFCXXXX] (preamble)
IMDN-Record-Route - [RFCXXXX] +--------------------------+---------------------+
| Index Value | Reference |
+--------------------------+---------------------+
| Disposition-Notification | RFCXXXX Section 6.2 |
| Message-ID | RFCXXX Section 6.3 |
| Original-To | RFCXXX Section 6.4 |
| IMDN-Record-Route | RFCXXX Section 6.5 |
| IMDN-Route | RFCXXX Section 6.6 |
+--------------------------+---------------------+
IMDN-Route - [RFCXXXX] (postamble)
15.6. Content-Disposition: notification 15.4. Content-Disposition: notification
This document registers one new Content-Disposition header field This document registers one new Content-Disposition header field
"disposition-types": notification. The authors request that this "disposition-types": notification. The authors request that this
value be recorded in the IANA registry for Content-Dispositions. value be recorded in the IANA registry for Mail Content Dispositions.
Descriptions of this "disposition-types", including motivation and Descriptions of this "disposition-types", including motivation and
examples, are given in Section 7.2.1.1 and Section 9. examples, are given in Section 7.2.1.1 and Section 9.
Short descriptions suitable for the IANA registry are: Short descriptions suitable for the IANA registry are:
notification the body of the message is a notification according to notification the body of the message is a notification according to
an earlier request for a disposition notification to an instant an earlier request for a disposition notification to an instant
message message
16. Acknowledgements 16. Acknowledgements
The authors would like to thank Paul Kyzivat, Ben Campbell, Adam Special thanks to Jari Urpalainen for the thorough review and
Roach, Gonzalo Camarillo, Sean Olson, Eva Leppanen, Miguel Garcia, suggestions for the RelaxNG Schema.
Eric McMurry, Jari Urpalainen, Jon Peterson, and Robert Sparks for
The authors would also like to thank Paul Kyzivat, Ben Campbell, Adam
Roach, Gonzalo Camarillo, Frank Ellermann, Sean Olson, Eva Leppanen,
Miguel Garcia, Eric McMurry, Jon Peterson, and Robert Sparks for
their comments and support. In addition, we would like to thank the their comments and support. In addition, we would like to thank the
Gen-Art reviewer extrodinaire, Spencer Dawkins. Gen-Art reviewer extrodinaire, Spencer Dawkins.
17. References 17. References
17.1. Normative References 17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant
Messaging (CPIM): Message Format", RFC 3862, August 2004. Messaging (CPIM): Message Format", RFC 3862, August 2004.
[IANA] Mealling, M., "The IETF XML Registry", RFC 3688, [IANA] Mealling, M., "The IETF XML Registry", RFC 3688,
January 2004. January 2004.
[URN] Moats, R., "The URN Syntax", RFC 2141, May 1997. [URN] Moats, R., "The URN Syntax", RFC 2141, May 1997.
[RFC3023] Murata, M., "XML Media Types", RFC 3023, March 1997. [RFC3023] Murata, M., "XML Media Types", RFC 3023, March 1997.
skipping to change at page 36, line 12 skipping to change at page 38, line 5
[RFC3428] Campbell, B., "SIP Extension for Instant Messaging", [RFC3428] Campbell, B., "SIP Extension for Instant Messaging",
RFC 3428, December 2002. RFC 3428, December 2002.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition
Notification", RFC 3798, May 2004. Notification", RFC 3798, May 2004.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[URN_NS] Moats, R., "The URN Namespace for IETF Documents", [URN_NS] Moats, R., "The URN Namespace for IETF Documents",
RFC 2648, August 1999. RFC 2648, August 1999.
[I-D.ietf-sip-uri-list-message] [I-D.ietf-sip-uri-list-message]
Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient
MESSAGE Requests in the Session Initiation Protocol MESSAGE Requests in the Session Initiation Protocol
(SIP)", draft-ietf-sip-uri-list-message-03 (work in (SIP)", draft-ietf-sip-uri-list-message-03 (work in
progress), December 2007. progress), December 2007.
Authors' Addresses Authors' Addresses
Eric Burger Eric Burger
BEA Systems, Inc. New Hampshire
4 Van de Graaff Dr.
Burlington, MA 01803
USA USA
Phone: +1 781 993 7437 Phone:
Fax: +1 603 457 5933 Fax: +1 603 457 5933
Email: eric.burger@bea.com Email: eburger@standardstrack.com
Hisham Khartabil Hisham Khartabil
Ericsson Australia
Melbourne Melbourne
Australia Australia
Phone: +61 416 108 890 Phone: +61 416 108 890
Email: hisham.khartabil@gmail.com Email: hisham.khartabil@gmail.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
 End of changes. 132 change blocks. 
353 lines changed or deleted 405 lines changed or added

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