draft-ietf-simple-imdn-03.txt   draft-ietf-simple-imdn-04.txt 
SIMPLE E. Burger SIMPLE E. Burger
Internet-Draft BEA Systems, Inc. Internet-Draft BEA Systems, Inc.
Expires: August 9, 2007 H. Khartabil Intended status: Standards Track H. Khartabil
February 5, 2007 Expires: November 16, 2007 May 15, 2007
Instant Message Disposition Notification Instant Message Disposition Notification
draft-ietf-simple-imdn-03 draft-ietf-simple-imdn-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 9, 2007. This Internet-Draft will expire on November 16, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Instant Messaging (IM) refers to the transfer of messages between Instant Messaging (IM) refers to the transfer of messages between
users in real-time. This document provides a mechanism whereby users in real-time. This document provides a mechanism whereby
endpoints can request Instant Message Disposition Notifications endpoints can request Instant Message Disposition Notifications
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Disposition Types . . . . . . . . . . . . . . . . . . . . . . 6 5. Disposition Types . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Processing . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Processing . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Read . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Read . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. New CPIM header fields . . . . . . . . . . . . . . . . . . . . 7 6. New CPIM Header Fields . . . . . . . . . . . . . . . . . . . . 7
6.1. CPIM header field Namespace . . . . . . . . . . . . . . . 8 6.1. CPIM Header Field Namespace . . . . . . . . . . . . . . . 8
6.2. Disposition-Notification . . . . . . . . . . . . . . . . . 8 6.2. Disposition-Notification . . . . . . . . . . . . . . . . . 8
6.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . . . 8 6.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . . . 8
6.4. Original-To . . . . . . . . . . . . . . . . . . . . . . . 8 6.4. Original-To . . . . . . . . . . . . . . . . . . . . . . . 8
6.5. IMDN-Record-Route . . . . . . . . . . . . . . . . . . . . 8 6.5. IMDN-Record-Route . . . . . . . . . . . . . . . . . . . . 8
6.6. IMDN-Route . . . . . . . . . . . . . . . . . . . . . . . . 9 6.6. IMDN-Route . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . . . 9 7. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . . . 9
7.1. IM Sender . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. IM Sender . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1.1. Constructing Instant Messages . . . . . . . . . . . . 9 7.1.1. Constructing Instant Messages . . . . . . . . . . . . 9
7.1.2. Matching IMs with IMDNs . . . . . . . . . . . . . . . 10 7.1.2. Matching IMs with IMDNs . . . . . . . . . . . . . . . 10
7.1.3. Keeping State . . . . . . . . . . . . . . . . . . . . 11 7.1.3. Keeping State . . . . . . . . . . . . . . . . . . . . 11
7.1.4. Aggregation of IMDNs . . . . . . . . . . . . . . . . . 11 7.1.4. Aggregation of IMDNs . . . . . . . . . . . . . . . . . 11
7.2. IM Recipient . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. IM Recipient . . . . . . . . . . . . . . . . . . . . . . . 12
7.2.1. Constructing IMDNs . . . . . . . . . . . . . . . . . . 12 7.2.1. Constructing IMDNs . . . . . . . . . . . . . . . . . . 12
8. Intermediary Behaviour . . . . . . . . . . . . . . . . . . . . 14 8. Intermediary Behaviour . . . . . . . . . . . . . . . . . . . . 14
8.1. Constructing Processing Notifications . . . . . . . . . . 15 8.1. Constructing Processing Notifications . . . . . . . . . . 15
8.2. Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 16 8.2. Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 16
9. Identifying Messages . . . . . . . . . . . . . . . . . . . . . 17 9. Identifying Messages . . . . . . . . . . . . . . . . . . . . . 19
10. header fields Formal Syntax . . . . . . . . . . . . . . . . . 17 10. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 19
11. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Structure of XML-Encoded IMDN Payload . . . . . . . . . . 18 11.1. Structure of XML-Encoded IMDN Payload . . . . . . . . . . 20
11.1.1. The <message-id> Element . . . . . . . . . . . . . . . 19 11.1.1. The <message-id> Element . . . . . . . . . . . . . . . 20
11.1.2. The <datetime> Element . . . . . . . . . . . . . . . . 19 11.1.2. The <datetime> Element . . . . . . . . . . . . . . . . 20
11.1.3. The <recipient-uri> Element . . . . . . . . . . . . . 19 11.1.3. The <recipient-uri> Element . . . . . . . . . . . . . 20
11.1.4. The <original-recipient-uri> Element . . . . . . . . . 19 11.1.4. The <original-recipient-uri> Element . . . . . . . . . 21
11.1.5. The <subject> Element . . . . . . . . . . . . . . . . 19 11.1.5. The <subject> Element . . . . . . . . . . . . . . . . 21
11.1.6. The <disposition> Element . . . . . . . . . . . . . . 19 11.1.6. The <disposition> Element . . . . . . . . . . . . . . 21
11.1.7. The <status> Element . . . . . . . . . . . . . . . . . 19 11.1.7. The <status> Element . . . . . . . . . . . . . . . . . 21
11.1.8. The <note> Element . . . . . . . . . . . . . . . . . . 20 11.1.8. The <note> Element . . . . . . . . . . . . . . . . . . 21
11.2. MIME Type for IMDN Paylaod . . . . . . . . . . . . . . . . 20 11.2. MIME Type for IMDN Payload . . . . . . . . . . . . . . . . 21
11.3. The RelaxNG Schema . . . . . . . . . . . . . . . . . . . . 20 11.3. The RelaxNG Schema . . . . . . . . . . . . . . . . . . . . 21
12. Transporting Messages using SIP . . . . . . . . . . . . . . . 24 12. Transporting Messages using SIP . . . . . . . . . . . . . . . 25
12.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 24 12.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 25
12.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 24 12.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 25
12.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 24 12.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 26
12.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 24 12.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 26
12.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 25 12.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 27
13. Transporting Messages using MSRP . . . . . . . . . . . . . . . 26 13. Transporting Messages using MSRP . . . . . . . . . . . . . . . 28
14. Security Considerations . . . . . . . . . . . . . . . . . . . 27 14. Security Considerations . . . . . . . . . . . . . . . . . . . 28
14.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 29 14.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 30
14.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 29 14.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 31
14.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 30 14.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 31
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
15.1. message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 30 15.1. message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 32
15.2. URN Sub-Namespace Registration for 15.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:imdn . . . . . . . . . . . . . . . 31 urn:ietf:params:xml:ns:imdn . . . . . . . . . . . . . . . 32
15.3. Schema Registration . . . . . . . . . . . . . . . . . . . 31 15.3. Schema Registration . . . . . . . . . . . . . . . . . . . 33
15.4. Message/CPIM header field registration . . . . . . . . . . 31 15.4. Registration for urn:ietf:params:imdn . . . . . . . . . . 33
15.5. Content-Disposition: notification . . . . . . . . . . . . 32 15.5. Message/CPIM Header Field Registration . . . . . . . . . . 33
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 15.6. Content-Disposition: notification . . . . . . . . . . . . 34
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
17.1. Normative References . . . . . . . . . . . . . . . . . . . 32 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
17.2. Informative References . . . . . . . . . . . . . . . . . . 32 17.1. Normative References . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 17.2. Informative References . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 37
1. Introduction 1. Introduction
In many user-to-user message exchange systems, message senders often In many user-to-user message exchange systems, message senders often
wish to know if the human recipient actually received or read a wish to know if the human recipient actually received or read a
message. message.
Electronic Mail [10] deals with this situation with Message Delivery Electronic Mail [10] deals with this situation with Message Delivery
Notifications [11]. After the recipient views the message, her mail Notifications [11]. After the recipient views the message, her mail
user agent generates a Message Delivery Notification, or MDN. The user agent generates a Message Delivery Notification, or MDN. The
MDN is an e-mail that follows the format prescribed by RFC2298 [11]. MDN is an e-mail that follows the format prescribed by RFC3798 [11].
The fixed format ensures that an automaton can process the message. The fixed format ensures that an automaton can process the message.
Message/CPIM [2] is a message format used to generate instant Message/CPIM [2] is a message format used to generate instant
messages. SIP [8] can carry instant messages generated using messages. SIP [8] can carry instant messages generated using
message/CPIM in SIP MESSAGE requests [9]. message/CPIM in SIP MESSAGE requests [9].
This document extends Message/CPIM message format (much like Message This document extends Message/CPIM message format (much like Message
Delivery Notifications [11] extends Electronic Mail [10]) to enable Delivery Notifications extends Electronic Mail) to enable Instant
Instant Message Senders to request, create and send Instant Message Message Senders to request, create and send Instant Message
Disposition Notifications (IMDN) for a page-mode as well as session Disposition Notifications (IMDN). This mechanism works for a page-
mode instant messages. IMDNs include positive delivery, negative mode as well as session mode instant messages. This document only
delivery (i.e. a message did not get delivered successfully), read discusses page-mode. Session mode is left as future standardisation
notifications as well as processed notifications. By using CPIM efforts.
header fields, the IMDN request and delivery are abstracted outside
the transport protocol allowing interoperability between different IM IMDNs include positive delivery, negative delivery (i.e. a message
systems. Likewise, the mechanism does not rely on session-mode did not get delivered successfully), read notifications as well as
versus page-mode. processed notifications. By using CPIM header fields, the IMDN
request and delivery are abstracted outside the transport protocol
allowing interoperability between different IM systems.
2. Conventions 2. Conventions
In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED', The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] and document are to be interpreted as described in RFC-2119 [1].
indicate requirement levels for compliant implementations.
3. Terminology 3. Terminology
o IM: An Instant Message generated using the Message/CPIM format. o IM: An Instant Message generated using the Message/CPIM format.
o IMDN: An Instant Message Disposition Notification generated using o IMDN: An Instant Message Disposition Notification generated using
the Message/CPIM format that carries a IMDN XML document. the Message/CPIM format that carries a IMDN XML document.
o Message: an IM or an IMDN generated using the Message/CPIM format. o Message: an IM or an IMDN generated using the Message/CPIM format.
o IM Sender: An endpoint (User Agent) generating and sending an IM. o IM Sender: An endpoint (User Agent) generating and sending an IM.
It is also the endpoint that requests IMDNs for an IM. Quite It is also the endpoint that requests IMDNs for an IM. Quite
often, the IM Sender is the IMDN Recipient, but that is not always often, the IM Sender is the IMDN Recipient, but that is not always
true since an IM Sender's Address of Record (AoR) placed in the IM true since an IM Sender's Address of Record (AoR) placed in the IM
and in turn used in the IMDN may in fact resolve to different User and in turn used in the IMDN may in fact resolve to different User
Agents. This is a limitation due to the nature of page-mode IMs. Agents. This is an artifact of the nature of page-mode IMs.
o IM Recipient: An endpoint (User Agent) that receives IMs. It is o IM Recipient: An endpoint (User Agent) that receives IMs. It is
also the endpoint that generates and sends IMDNs to IMs, if also the endpoint that generates and sends IMDNs to IMs, if
requested by the IM Sender. requested by the IM Sender.
o Endpoint: An IM Sender or an IM Recipient. o Endpoint: An IM Sender or an IM Recipient.
o Intermediary: An entity in the network that is on the path of an o Intermediary: An entity in the network that is on the path of an
IM to its final destination. IM to its final destination.
skipping to change at page 7, line 45 skipping to change at page 7, line 45
o "error" to indicate an error in determining the fate of an IM. o "error" to indicate an error in determining the fate of an IM.
Some IMs may in fact be audio, video or still images. Therefore, the Some IMs may in fact be audio, video or still images. Therefore, the
state "read" includes playing the audio or video file to the user. state "read" includes playing the audio or video file to the user.
Since there is no positive acknowledgement from the user, one cannot Since there is no positive acknowledgement from the user, one cannot
determine a priori that the user actually read the IM. Thus one determine a priori that the user actually read the IM. Thus one
cannot use the protocol described here as a non-repudiation service. cannot use the protocol described here as a non-repudiation service.
6. New CPIM header fields 6. New CPIM Header Fields
This specification extends the CPIM data format specified in RFC 3862 This specification extends the CPIM data format specified in RFC 3862
[2]. A new namespace is created as well as a number of new CPIM [2]. A new namespace is created as well as a number of new CPIM
header fields. header fields.
6.1. CPIM header field Namespace 6.1. CPIM Header Field Namespace
Per CPIM [2], this specification defines a new namespace for the CPIM Per CPIM [2], this specification defines a new namespace for the CPIM
extension header fields defined in the following sections. The extension header fields defined in the following sections. The
namespace is: namespace is:
urn:ietf:params:cpim-header fields:imdn urn:ietf:params:imdn
As per CPIM [2] requirements, the new header fields defined in the As per CPIM [2] requirements, the new header fields defined in the
following sections are prepended, in CPIM messages, by a prefix following sections are prepended, in CPIM messages, by a prefix
assigned to the URN through the NS header field field of the CPIM assigned to the URN through the NS header field of the CPIM message.
message. The remaining of this specification always assumes an NS The remaining of this specification always assumes an NS header field
header field field like this one: like this one:
NS: imdn <urn:ietf:params:cpim-header fields:imdn>. NS: imdn <urn:ietf:params:imdn>.
6.2. Disposition-Notification 6.2. Disposition-Notification
The Disposition-Notification header field is used by the IM Sender to The Disposition-Notification header field is used by the IM Sender to
indicate the desire to receive IMDNs, from the IM Recipient, for that indicate the desire to receive IMDNs, from the IM Recipient, for that
specific IM. This header field is not needed if the IM Sender does specific IM. This header field is not needed if the IM Sender does
not request an IMDN. The syntax is defined in Section 10. not request an IMDN. The syntax is defined in Section 10.
6.3. Message-ID 6.3. Message-ID
skipping to change at page 9, line 29 skipping to change at page 9, line 29
7. Endpoint Behaviour 7. Endpoint Behaviour
7.1. IM Sender 7.1. IM Sender
7.1.1. Constructing Instant Messages 7.1.1. Constructing Instant Messages
An IM is constructed using CPIM Message Format defined in RFC 3862 An IM is constructed using CPIM Message Format defined in RFC 3862
[2]. [2].
7.1.1.1. Adding a Message-ID header field 7.1.1.1. Adding a Message-ID Header Field
If the IM sender requests the reception of IMDNs, the IM sender MUST If the IM sender requests the reception of IMDNs, the IM sender MUST
include a Message-ID header field. The Message-ID field is populated include a Message-ID header field. The Message-ID field is populated
with a value that is unique with 32 bits of randomness. This header with a value that is unique with 32 bits of randomness. This header
field enables the IM Sender to match any IMDNs with their field enables the IM Sender to match any IMDNs with their
corresponding IMs. corresponding IMs.
7.1.1.2. Adding a DateTime header field 7.1.1.2. Adding a DateTime Header Field
Some devices may not implement the concept of "Sent Items" box and Some devices may not implement the concept of "Sent Items" box and
therefore no information about an IM is stored. It is therefore therefore no information about an IM is stored. It is therefore
necessary to add a time stamp in the IM to indicate when it was sent. necessary to add a time stamp in the IM to indicate when it was sent.
This time stamp is returned in the IMDN in order to enable the user This time stamp is returned in the IMDN in order to enable the user
to correlate the IM with the IMDN at the human level. The DateTime to correlate the IM with the IMDN at the human level. The DateTime
header field is used for this purpose. The IM MUST contain a header field is used for this purpose. The IM MUST contain a
DateTime header field if an IMDN is requested. DateTime header field if an IMDN is requested.
7.1.1.3. Adding a Disposition-Notification header field 7.1.1.3. Adding a Disposition-Notification Header Field
The Disposition-Notification conveys the type of disposition The Disposition-Notification conveys the type of disposition
notification requested by the IM sender. There are three types of notification requested by the IM sender. There are three types of
disposition notification: delivery, processing, and read. The disposition notification: delivery, processing, and read. The
delivery notification is further subdivided into failure and success delivery notification is further subdivided into failure and success
delivery notifications. An IM Sender requests failure delivery delivery notifications. An IM Sender requests failure delivery
notification by including a Disposition-Notification header field notification by including a Disposition-Notification header field
with value "negative-delivery". Similarly, a success notification is with value "negative-delivery". Similarly, a success notification is
requested by including a Disposition-Notification header field with requested by including a Disposition-Notification header field with
value "positive-delivery". Both types of delivery notifications can value "positive-delivery". Both types of delivery notifications can
skipping to change at page 10, line 21 skipping to change at page 10, line 21
The IM Sender can request a processing notification by including a The IM Sender can request a processing notification by including a
Disposition-Notification header field with value "processing". Disposition-Notification header field with value "processing".
The IM Sender can also request a read notification. It is requested The IM Sender can also request a read notification. It is requested
by including a Disposition-Notification header field with value by including a Disposition-Notification header field with value
"read". "read".
The absence of this header field or the presence of the header field The absence of this header field or the presence of the header field
with empty value indicates that the IM Sender is not requesting any with empty value indicates that the IM Sender is not requesting any
IMDNs. The Disposition-Notification header fields can be comma IMDNs. The Disposition-Notification header field values can be comma
separated. The IM Sender MAY request more than one type of IMDN for separated. The IM Sender MAY request more than one type of IMDN for
a single IM. a single IM.
Future extension may define other disposition notifications not Future extension may define other disposition notifications not
defined in this document. defined in this document.
The formal syntax of the Disposition-Notification header field can be The formal syntax of the Disposition-Notification header field can be
found in Section 10. The following is an example CPIM body of an IM found in Section 10. The following is an example CPIM body of an IM
where the IM Sender requests positive and negative delivery where the IM Sender requests positive and negative delivery
notifications, but not read notification nor processing notifications, but not read notification nor processing
notifications: notifications:
From: Alice <im:alice@example.com> From: Alice <im:alice@example.com>
To: Bob <im:bob@example.com> To: Bob <im:bob@example.com>
NS: imdn <urn:ietf:params:cpim-header fields:imdn> NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: 34jk324j imdn.Message-ID: 34jk324j
DateTime: 2006-04-04T12:16:49-05:00 DateTime: 2006-04-04T12:16:49-05:00
imdn.Disposition-Notification: positive-delivery, negative-delivery imdn.Disposition-Notification: positive-delivery, negative-delivery
Content-type: text/plain Content-type: text/plain
Content-length: 12 Content-length: 12
Hello World Hello World
7.1.2. Matching IMs with IMDNs 7.1.2. Matching IMs with IMDNs
skipping to change at page 11, line 51 skipping to change at page 11, line 51
adding the time stamp in the IM and having it returned in the IMDN. adding the time stamp in the IM and having it returned in the IMDN.
This gives the user some opportunity of remembering what IM was sent. This gives the user some opportunity of remembering what IM was sent.
For example if the IMDN indicates that the IM the user sent at 2 p.m. For example if the IMDN indicates that the IM the user sent at 2 p.m.
last Thursday was delivered, the user has a chance of remembering last Thursday was delivered, the user has a chance of remembering
that they sent an IM at 2 p.m. last Thursday. that they sent an IM at 2 p.m. last Thursday.
7.1.4. Aggregation of IMDNs 7.1.4. Aggregation of IMDNs
An IM Sender may send an IM to multiple recipients in one Transport An IM Sender may send an IM to multiple recipients in one Transport
Protocol Message (typically using a URI-List server) and request Protocol Message (typically using a URI-List server) and request
IMDNs. An IM Sender that requested an IMDNs MUST be prepared to IMDNs. An IM Sender that requested IMDNs MUST be prepared to receive
receive multiple aggregated or non-aggregated IMDNs. See Section 8.2 multiple aggregated or non-aggregated IMDNs. See Section 8.2 for
for details. details.
7.2. IM Recipient 7.2. IM Recipient
7.2.1. Constructing IMDNs 7.2.1. Constructing IMDNs
IM recipients examine the contents of the Disposition-Notification IM recipients examine the contents of the Disposition-Notification
header field of the CPIM message to determine if an IMDN must be header field of the CPIM message to determine if an IMDN must be
generated for that IM. Disposition-Notification header fields of generated for that IM. Disposition-Notification header fields of
CPIM messages can include one or more values. This implies that IM CPIM messages can include one or more values. This implies that IM
recipients may need to generate zero, one, or more IMDNs for that IM, recipients may need to generate zero, one, or more IMDNs for that IM,
skipping to change at page 12, line 28 skipping to change at page 12, line 28
IMDNs per IM. An IM Recipient MUST NOT construct more than one IMDN IMDNs per IM. An IM Recipient MUST NOT construct more than one IMDN
per disposition type. I.e. It must not, for example, generate a per disposition type. I.e. It must not, for example, generate a
delivery notification indicating "delivered" then followed by a delivery notification indicating "delivered" then followed by a
delivery notification indicating "failed" for the same IM. If the IM delivery notification indicating "failed" for the same IM. If the IM
Sender requested only failure notifications and the IM was Sender requested only failure notifications and the IM was
successfully delivered, then no IMDNs will be generated. successfully delivered, then no IMDNs will be generated.
The IM Recipient MUST NOT generate "processing" notifications. The IM Recipient MUST NOT generate "processing" notifications.
Disposition-Notification header field MUST NOT appear in an IMDN Disposition-Notification header field MUST NOT appear in an IMDN
since it does not make sense and is therefore forbidden to request an since it is forbidden to request an IMDN for an IMDN. IM Sender MUST
IMDN for an IMDN. IM Sender MUST ignore it if present. The IM ignore it if present. The IM Sender MUST NOT send an IMDN to an
Sender MUST NOT send an IMDN to an IMDN. IMDN.
An IMDN MUST contain a Message-ID header field. The same rules of An IMDN MUST contain a Message-ID header field. The same rules of
uniqueness for the Message-ID header field that appears in an IM uniqueness for the Message-ID header field that appears in an IM
apply to an IMDN. The Message-ID header field in the IMDN is apply to an IMDN. The Message-ID header field in the IMDN is
different and unrelated to the one in the IM. different and unrelated to the one in the IM.
An IM may contain a IMDN-Record-Route header field (see Section 8 for An IM may contain a IMDN-Record-Route header field (see Section 8 for
details). If IMDN-Record-Route header fields appear in the IM, the details). If IMDN-Record-Route header fields appear in the IM, the
IM Recipient constructing the IMDN MUST copy the contents of the IM Recipient constructing the IMDN MUST copy the contents of the
IMDN-Record-Route header fields into IMDN-Route header fields in the IMDN-Record-Route header fields into IMDN-Route header fields in the
IMDN and maintain the order. The IMDN is then sent to the URI in the IMDN and maintain the order. The IMDN is then sent to the URI in the
top IMDN-Route header field. IMDN-Record-Route header fields do not top IMDN-Route header field. IMDN-Record-Route header fields do not
make sense in an IMDN and therefore SHOULD NOT be placed in an IMDN. make sense in an IMDN and therefore SHOULD NOT be placed in an IMDN.
IMDN Recipients SHOULD ignore it if present.
The CPIM Content-Disposition header field must be set to the value The CPIM Content-Disposition header field must be set to the value
"notification". This indicates to the IM Sender that the message is "notification". This indicates to the IM Sender that the message is
an IMDN to an IM it has earlier sent. an IMDN to an IM it has earlier sent.
7.2.1.1. Constructing Delivery Notifications 7.2.1.1. Constructing Delivery Notifications
A delivery notification is constructed in a similar fashion as an IM, A delivery notification is constructed in a similar fashion as an IM,
using a CPIM body [2] that carries a Disposition Notification XML using a CPIM body [2] that carries a Disposition Notification XML
document formatted according to the rules specified in Section 11. document formatted according to the rules specified in Section 11.
The MIME type of the Disposition Notification XML document is The MIME type of the Disposition Notification XML document is
"message/imdn+xml". "message/imdn+xml".
An example CPIM body of IMDN looks like the following: An example CPIM body of IMDN looks like the following:
From: Bob <im:bob@example.com> From: Bob <im:bob@example.com>
To: Alice <im:alice@example.com> To: Alice <im:alice@example.com>
NS: imdn <urn:ietf:params:cpim-header fields:imdn> NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: d834jied93rf imdn.Message-ID: d834jied93rf
Content-type: message/imdn+xml Content-type: message/imdn+xml
Content-Disposition: notification Content-Disposition: notification
Content-length: ... Content-length: ...
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<imdn xlmns="urn:ietf:params:xml:ns:imdn"> <imdn xlmns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id> <message-id>34jk324j</message-id>
<datetime>2006-04-04T12:16:49-05:00</datetime> <datetime>2006-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri> <recipient-uri>im:bob@example.com</recipient-uri>
skipping to change at page 14, line 7 skipping to change at page 14, line 7
7.2.1.2. Constructing Read Notifications 7.2.1.2. Constructing Read Notifications
A read notification is constructed in a similar fashion as the A read notification is constructed in a similar fashion as the
delivery notification. See Section 7.2.1.1 for details. delivery notification. See Section 7.2.1.1 for details.
An example looks like the following: An example looks like the following:
From: Bob <im:bob@example.com> From: Bob <im:bob@example.com>
To: Alice <im:alice@example.com> To: Alice <im:alice@example.com>
NS: imdn <urn:ietf:params:cpim-header fields:imdn> NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: dfjkleriou432333 imdn.Message-ID: dfjkleriou432333
Content-type: message/imdn+xml Content-type: message/imdn+xml
Content-Disposition: notification Content-Disposition: notification
Content-length: ... Content-length: ...
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<imdn xlmns="urn:ietf:params:xml:ns:imdn"> <imdn xlmns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id> <message-id>34jk324j</message-id>
<datetime>2006-04-04T12:16:49-05:00</datetime> <datetime>2006-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri> <recipient-uri>im:bob@example.com</recipient-uri>
skipping to change at page 14, line 32 skipping to change at page 14, line 32
</disposition> </disposition>
<status> <status>
<read/> <read/>
</status> </status>
<note lang="en">The IM has been read</note> <note lang="en">The IM has been read</note>
</imdn> </imdn>
There are situations where the IM Recipient cannot determine if or There are situations where the IM Recipient cannot determine if or
when the IM has been read. The IM Recipient in this case generates a when the IM has been read. The IM Recipient in this case generates a
read notification with a <status> value of "error" to indicate an read notification with a <status> value of "error" to indicate an
internal error by the server. An example of this is when a SIP stack internal error by the server. Note that the IM Recipient may choose
with built in IMDN support is talking to an IM application and the IM to ignore any IMDN requests and not to send any IMDNs. An example of
application never returned indicating that it has displayed the IM to this is when a SIP stack with built in IMDN support is talking to an
the user. IM application and the IM application never returned indicating that
it has displayed the IM to the user.
8. Intermediary Behaviour 8. Intermediary Behaviour
In this context, application servers (including URI-List servers and In this context, application servers (including URI-List servers and
Store-and-Forward server) and gateways are defined as intermediaries. Store-and-Forward server) and gateways are defined as intermediaries.
A gateway is a server the translates between different IM systems A gateway is a server the translates between different IM systems
that different protocols. that use different protocols.
A URI-List server may change the IM Recipient address from its own to A URI-List server may change the IM Recipient address from its own to
the address of the final recipient of that IM for every copy it makes the address of the final recipient of that IM for every copy it makes
to be sent to the list members (see [12] for details). In this case, to be sent to the list members (see [13] for details). In this case,
the intermediary MUST add an Original-To header field to the IM if the IM Sender is requesting an IMDN, the intermediary MUST add an
populating it with the address that was in the CPIM To header field Original-To header field to the IM populating it with the address
before it was changed. I.e. The Original-To header field is that was in the CPIM To header field before it was changed. I.e.
populated with the intermediary address. An intermediary MUST NOT The Original-To header field is populated with the intermediary
add an Original-To header field if one already exists. address. An intermediary MUST NOT add an Original-To header field if
one already exists.
An intermediary MAY choose to remain on the path of IMDNs for a An intermediary MAY choose to remain on the path of IMDNs for a
specific IM. It can do so by adding a CPIM IMDN-Record-Route header specific IM. It can do so by adding a CPIM IMDN-Record-Route header
field as the top IMDN-Record-Route header field and populating it field as the top IMDN-Record-Route header field and populating it
with its own address. An intermediary that does not support this with its own address. An intermediary that does not support this
extension will obviously not add the IMDN-Record-Route header field. extension will obviously not add the IMDN-Record-Route header field.
This allows IMDNs to traverse directly from the IM Recipient to the This allows IMDNs to traverse directly from the IM Recipient to the
IM Sender even if the IM traversed an intermediary not supporting IM Sender even if the IM traversed an intermediary not supporting
this extension. this extension.
skipping to change at page 16, line 39 skipping to change at page 16, line 39
an IM. The intermediary in this case generates a processing an IM. The intermediary in this case generates a processing
notification with a <status> value of "error" to indicate so. notification with a <status> value of "error" to indicate so.
8.2. Aggregation of IMDNs 8.2. Aggregation of IMDNs
In this context, URI-List servers are defined as intermediaries. In this context, URI-List servers are defined as intermediaries.
An intermediary may choose to aggregate IMDNs using local policy for An intermediary may choose to aggregate IMDNs using local policy for
making such a decision or it may send individual IMDNs instead. When making such a decision or it may send individual IMDNs instead. When
a URI-List server receives an IM and decides to aggregate IMDNs, it a URI-List server receives an IM and decides to aggregate IMDNs, it
waits for a configurable period of time or until all recipients have can wait for a configurable period of time or until all recipients
sent the IMDN (whichever comes first) before the URI-List server have sent the IMDN (whichever comes first) before the URI-List server
sends an aggregated IMDN. Note that some IMDNs, for example read sends an aggregated IMDN. Note that some IMDNs, for example read
notifications, may never come due to user settings. It is an notifications, may never come due to user settings. It is an
administrator configuration and an implementation issue how long to administrator configuration and an implementation issue how long to
wait before sending an aggregated IMDN and before a URI-List server wait before sending an aggregated IMDN and before a URI-List server
removes state for that IM. removes state for that IM.
A URI-List server MAY choose to send multiple aggregated IMDNs. A A URI-List server MAY choose to send multiple aggregated IMDNs. A
timer can be started and when it fires, the URI-List server can timer can be started and when it fires, the URI-List server can
aggregate whatever IMDNs it has so far for that IM, send the aggregate whatever IMDNs it has so far for that IM, send the
aggregated IMDN and restart the timer for the next batch. This is aggregated IMDN and restart the timer for the next batch. This is
needed for scenarios where the IM Sender has requested more than one needed for scenarios where the IM Sender has requested more than one
IMDN for a specific IM, for example, delivery notifications as well IMDN for a specific IM, for example, delivery notifications as well
as read notifications, or when the URI-List server is short on as read notifications, or when the URI-List server is short on
resources and chooses to prioritise forwarding IMs over IMDNs. resources and chooses to prioritise forwarding IMs over IMDNs.
A second timer can be running and when it fires, the state of the IM A second timer can be running and when it fires, the state of the IM
is deleted. In this case, the URI-List server consumes any IMDNs is deleted. In this case, the URI-List server consumes any IMDNs
that might arrive after that time. that might arrive after that time.
Please note that the references to timers in the above paragraphs are
not normative and are only present to help describe one way
aggregation might be implemented.
A URI-List server MAY aggregate IMDNs for the case where the list A URI-List server MAY aggregate IMDNs for the case where the list
membership information is not disclosed. There may be scenarios membership information is not disclosed. There may be scenarios
where the URI-List server starts sending aggregated IMDNs and switch where the URI-List server starts sending aggregated IMDNs and switch
to indivdual ones or visa versa. A timer firing so ofter may in fact to individual ones or visa versa. A timer firing so often may in
have that effect. fact have that effect.
The aggregated IMDN is constructed using the multipart/mixed MIME The aggregated IMDN is constructed using the multipart/mixed MIME
type and including all the received IMDNs as message/imdn+xml as type and including all the received IMDNs as message/imdn+xml as
individual payloads. individual payloads.
There are scenarios where an intermediary needs to generate IMDNs, Below is an example of aggregated IMDNs.
see Section 12.2 for further details.
From: Bob <im:bob@example.com>
To: Alice <im:alice@example.com>
NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: d834jied93rf
Content-type: multipart/mixed;
boundary="imdn-boundary"
Content-Disposition: notification
Content-length: ...
--imdn-boundary
Content-type: message/imdn+xml
<?xml version="1.0" encoding="UTF-8"?>
<imdn xlmns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2006-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri>
im:bob@example.com</original-recipient-uri>
<disposition>
<delivery/>
</disposition>
<status>
<delivered/>
</status>
<note lang="en">The IM was successfully Delivered</note>
</imdn>
--imdn-boundary
Content-type: message/imdn+xml
<?xml version="1.0" encoding="UTF-8"?>
<imdn xlmns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2006-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri>
im:bob@example.com</original-recipient-uri>
<disposition>
<read/>
</disposition>
<status>
<read/>
</status>
<note lang="en">The IM was successfully Delivered</note>
</imdn>
--imdn-boundary
9. Identifying Messages 9. Identifying Messages
Messages are typically carried in a transport protocol like SIP [8]. Messages are typically carried in a transport protocol like SIP [8].
The message is an IM if the content-type header field field present If the payload carried by the transport protocol does not contain any
in it has a value that is NOT "message/imdn+xml". parts of type Message/CPIM then the message is an IM. If the payload
contains any parts of type Message/CPIM, and none of 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 and an IMDN in
a multipart payload in a single transport protocol message.
A message is identified as a delivery notification by examining its A message is identified as a delivery notification by examining its
contents. The message is a delivery notification if: the Content- contents. The message is a delivery notification if the Content-type
type header field present has a value of "message/imdn+xml", the header field present has a value of "message/imdn+xml", the Content-
Content-Disposition header field field has a value of "notification", Disposition header field has a value of "notification", and the
and the <disposition> element in that xml body has a sub-element <disposition> element in that xml body has a sub-element <delivery>.
<delivery>.
A message is identified as a processing notification or read A message is identified as a processing notification or read
notification in a similar fashion as a delivery notification. The notification in a similar fashion as a delivery notification. The
difference is that the <disposition> element in that xml body has a difference is that the <disposition> element in that xml body has a
sub-element of <processing> and <read> respectively. sub-element of <processing> and <read> respectively.
10. header fields Formal Syntax 10. Header Fields Formal Syntax
The following syntax specification uses the message header field The following syntax specification uses the message header field
syntax as described in Section 3 of RFC3862 [2]. syntax as described in Section 3 of RFC3862 [2].
header field syntax is described without a namespace qualification. Header field syntax is described without a namespace qualification.
Following the rules in RFC3862 [2], header field names and other text Following the rules in RFC3862 [2], header field names and other text
are case sensitive and MUST be used as given, using exactly the are case sensitive and MUST be used as given, using exactly the
indicated upper-case and lower-case letters. indicated upper-case and lower-case letters.
Disposition-Notification = Disposition-Notification =
"Disposition-Notification" ": " [(notify-req *(COMMA notify-req))] "Disposition-Notification" ": "
[(notify-req *(COMMA notify-req))]
notify-req = notify-req =
("negative-delivery" / "positive-delivery" / ("negative-delivery" / "positive-delivery" /
"processing" / "read" / Token) *(SEMI disp-notif-params) "processing" / "read" / Token) *(SEMI disp-notif-params)
disp-notify-params = generic-param disp-notify-params = generic-param
Message-ID = "Message-ID" ": " Token Message-ID = "Message-ID" ": " Token
Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">" Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">"
skipping to change at page 18, line 20 skipping to change at page 20, line 4
"processing" / "read" / Token) *(SEMI disp-notif-params) "processing" / "read" / Token) *(SEMI disp-notif-params)
disp-notify-params = generic-param disp-notify-params = generic-param
Message-ID = "Message-ID" ": " Token Message-ID = "Message-ID" ": " Token
Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">" Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">"
IMDN-Record-Route = IMDN-Record-Route =
"IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">" "IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">"
IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">" IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">"
11. IMDN Format 11. IMDN Format
11.1. Structure of XML-Encoded IMDN Payload 11.1. Structure of XML-Encoded IMDN Payload
An IMDN Payload is an XML document [7] that MUST be well-formed and An IMDN Payload is an XML document [6] that MUST be well-formed and
MUST be valid according to schemas, including extension schemas, MUST be valid according to schemas, including extension schemas,
available to the validater and applicable to the XML document. The available to the validater and applicable to the XML document. The
IMDN Payload MUST be based on XML 1.0 and MUST be encoded using IMDN Payload MUST be based on XML 1.0 and MUST be encoded using
UTF-8. UTF-8.
The namespace identifier for elements defined by this specification The namespace identifier for elements defined by this specification
is a URN [4], using the namespace identifier 'ietf' defined by [5] is a URN [4], using the namespace identifier 'ietf' defined by [12]
and extended by [3]. This urn is: urn:ietf:params:xml:ns:imdn. and extended by [3]. This urn is: urn:ietf:params:xml:ns:imdn.
This namespace declaration indicates the namespace on which the IMDN This namespace declaration indicates the namespace on which the IMDN
is based. is based.
The root element is <imdn>. The <imdn> element has sub-elements, The root element is <imdn>. The <imdn> element has sub-elements,
namely <message-id>, <datetime>, <recipient-uri>, <original- namely <message-id>, <datetime>, <recipient-uri>, <original-
recipient-uri>, <subject>, <disposition>, <status>, and <note>. recipient-uri>, <subject>, <disposition>, <status>, and <note>.
Those elements are described in details in the following sections. Those elements are described in details in the following sections.
skipping to change at page 20, line 12 skipping to change at page 21, line 43
elements <processed>, <stored>, <forbidden> or <error>. <forbidden> elements <processed>, <stored>, <forbidden> or <error>. <forbidden>
means the disposition was denied. <error> means internal server means the disposition was denied. <error> means internal server
error. It can also carry any other future extension. error. It can also carry any other future extension.
11.1.8. The <note> Element 11.1.8. The <note> Element
The <note> element is optional and carries a human readable text. It The <note> element is optional and carries a human readable text. It
has the "lang" attribute that indicates the language the text is has the "lang" attribute that indicates the language the text is
written in. written in.
11.2. MIME Type for IMDN Paylaod 11.2. 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.3. The RelaxNG Schema
<?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"
skipping to change at page 24, line 19 skipping to change at page 25, line 47
12.1.1. Sending Requests 12.1.1. Sending Requests
A SIP MESSAGE request is constructed using RFC 3428 [9]. The A SIP MESSAGE request is constructed using RFC 3428 [9]. The
Content-type header field indicates the MIME type of the request Content-type header field indicates the MIME type of the request
payload. When using this extension, the Content-type header field payload. When using this extension, the Content-type header field
MUST be of MIME type "message/cpim" [2] for both IMs and IMDNs. The MUST be of MIME type "message/cpim" [2] for both IMs and IMDNs. The
payload is constructed according to Section 7. payload is constructed according to Section 7.
A SIP MESSAGE request to multiple recipients is constructed in a A SIP MESSAGE request to multiple recipients is constructed in a
similar manner as a SIP MESSAGE request to a single recipient. The similar manner as a SIP MESSAGE request to a single recipient. The
differences are indicated in [12]. differences are indicated in [13].
12.1.2. Sending Responses 12.1.2. Sending Responses
An endpoint receiving a SIP MESSAGE request constructs a SIP response An endpoint receiving a SIP MESSAGE request constructs a SIP response
according to RFC3428 [9]. Of course, an endpoint will send a according to RFC3428 [9]. Of course, an endpoint will send a
response to the MESSAGE request regardless of they type of message response to the MESSAGE request regardless of they 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.
12.1.3. Receiving Requests 12.1.3. Receiving Requests
skipping to change at page 24, line 51 skipping to change at page 26, line 35
generate a 2xx response before it has been guaranteed that the final generate a 2xx response before it has been guaranteed that the final
recipient has actually received the IM). The positive-delivery recipient has actually received the IM). The positive-delivery
notification is constructed according to Section 7.2.1.1. The notification is constructed according to Section 7.2.1.1. The
message is then placed as the payload in a SIP MESSAGE request. 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, and that IM Recipient has constructed requested a negative-delivery, and that IM Recipient has constructed
and sent a 2xx class response, it SHOULD generate a negative-delivery and sent a 2xx class response, it SHOULD generate a negative-delivery
notification if it learnt that the final recipient or application did notification if it learnt that the final recipient or application did
not receive the IM (a gateway, for example, can generate a 2xx not receive the IM (a gateway, for example, can generate a 2xx
response before it has been guaranteed that the final recipient has response before it has an error response from downstream or before
actually received the IM). The negative-delivery notification is any internal timers fire waiting for a response). The negative-
constructed according to Section 7.2.1.1. The message is then placed delivery notification is constructed according to Section 7.2.1.1.
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 read notification, and that IM Recipient has constructed
and sent a SIP 2xx class response, it MAY generate a read and sent a SIP 2xx class response, it MAY generate a read
notification after making sure that the IM has been presented to the notification after making sure that the IM has been presented to the
user or application. It is outside the scope of this document how user or application. It is outside the scope of this document how
such determination can be made. Note that the option to send a read such determination can be made. Note that the option to send a read
notification or not can be left to the user. An application may notification or not can be left to the user. An application may
allow a user to configure such choice. The read notification is allow a user to configure such choice. The read notification is
constructed according to Section 7.2.1.2. The message is then placed constructed according to Section 7.2.1.2. The message is then placed
as the payload in a SIP MESSAGE request. as the payload in a SIP MESSAGE request.
For IMDNs, the SIP Request-URI and the SIP To header field are For IMDNs, the SIP Request-URI and the SIP To header field are
populated using the address that appeared in the SIP From header populated using the address that appeared in the SIP From header
field field in the IM. field in the IM.
12.1.3.2. Delivery Notification 12.1.3.2. Delivery Notification
A SIP MESSAGE request is identified as delivery notification by A SIP MESSAGE request is identified as delivery notification by
examining its contents according to Section 9. examining its contents according to Section 9.
12.1.3.3. Read Notification 12.1.3.3. Read Notification
A SIP MESSAGE request is identified as read notification by examining A SIP MESSAGE request is identified as read notification by examining
its contents according to Section 9. its contents according to Section 9.
12.2. Intermediary Behaviour 12.2. Intermediary Behaviour
In this context, application servers (including URI-List servers and In this context, application servers (including URI-List servers and
Store-and-Forward server) and gateways are defined as intermediaries. Store-and-Forward server) and gateways are defined as intermediaries.
SIP Proxies MUST NOT generate IMDNs but MUST forward them like any SIP Proxies MUST NOT generate IMDNs but MUST forward them like any
other sip request. other sip request.
A SIP MESSAGE request to multiple recipients is forwarded according A SIP MESSAGE request to multiple recipients is forwarded according
to [12]. to [13].
If an intermediary generates a SIP 2xx class response to a SIP If an intermediary generates a SIP 2xx class response to a SIP
MESSAGE request it has received that is an IM, it examines if the MESSAGE request it has received that is an IM, it examines if the
body was of type "message/cpim". If so, it checks if there is the body was of type "message/cpim". If so, it checks the CPIM header to
header field Disposition-Notification with a value "positive- see if there is the header field Disposition-Notification with a
delivery" and/or "negative-delivery". If so, it MUST send a delivery value "positive-delivery" and/or "negative-delivery". If so, it MUST
notification after receiving a transactional final response for the send a delivery notification after receiving a transactional final
IM. response for the IM.
If the Disposition-Notification header field contains a value of If the Disposition-Notification header field contains a value of
"positive-delivery", the intermediary MUST NOT generate a delivery "positive-delivery", the intermediary MUST NOT generate a delivery
notification if it receives a SIP 2xx class response for the sent IM. notification if it receives a SIP 2xx class response for the sent IM.
This is in anticipation of a failure downstream after a 2xx response This is in anticipation of a failure downstream after a 2xx response
has been generated. has been generated.
If the Disposition-Notification header field contains a value of If the Disposition-Notification header field contains a value of
"negative-delivery", the intermediary SHOULD generate a delivery "negative-delivery", the intermediary SHOULD generate a delivery
notification if it receives a SIP 4xx, 5xx or 6xx class final notification if it receives a SIP 4xx, 5xx or 6xx class final
response for the sent IM. If it has received a SIP 2xx class response for the sent IM. If it has received a SIP 2xx class
response followed by a negative-delivery notification, the response followed by a negative-delivery notification, the
intermediary forwards that negative-delivery notification or intermediary forwards that negative-delivery notification or
aggragates it. aggregates it.
If the Disposition-Notification header field contains a value of If the Disposition-Notification header field contains a value of
"processing", the intermediary MAY generate a processing notification "processing", the intermediary MAY generate a processing notification
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 read notification, it forwards it using
the rules in Section 8. the rules in Section 8.
13. Transporting Messages using MSRP 13. Transporting Messages using MSRP
MSRP already provides a built-in mechanism to supply positive and MSRP already provides a built-in mechanism to supply positive and
negatie delivery reports. negative delivery reports.
While MSRP does not provide a built-in Read or Processing While MSRP does not provide a built-in Read or Processing
notification dispositions, those are generally not considered as notification dispositions, those are generally not considered as
useful information for session IM. This is because the assumption useful information for session IM. This is because the assumption
behind MSRP is that SEND requests do not reach a mailbox where behind MSRP is that SEND requests do not reach a mailbox where
incoming IMs have to be open, but to an application that renders incoming IMs have to be open, but to an application that renders
sequentially those incoming IMs, providing the session experience. sequentially those incoming IMs, providing the session experience.
This kind of applications has no means of identifying when a user has This kind of applications has no means of identifying when a user has
read the IM and therefore cannot be useful information for the read the IM and therefore cannot be useful information for the
sender. sender.
skipping to change at page 28, line 14 skipping to change at page 29, line 45
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 the IM Recipient does not is no protocol mechanism for ensuring that the IM Recipient does
lie about the time or purposely holds an IMDN for transmission to not lie about the time or purposely holds an IMDN for transmission
make it appear that the user read an IM later than they actually to make it appear that the user read an IM later than they
did. actually did.
o A deletion attack on an IMDN. This is a trade-off between privacy o A deletion attack on an IMDN. This is a trade-off between privacy
and security. The privacy considerations allow the IM Recipient and security. The privacy considerations allow the IM Recipient
to silently ignore an IMDN request. Any mechanism that would to silently ignore an IMDN request. Any mechanism that would
reliably indicate that a malicious node deleted a IM Recipient's reliably indicate that a malicious node deleted a IM Recipient's
IMDN would also serve the purpose of detecting a IM Recipient that IMDN would also serve the purpose of detecting a IM Recipient that
chose not to issue an IMDN. chose not to issue an IMDN.
To combat eavesdropping, modification, and man-in-the-middle attacks, To combat eavesdropping, modification, and man-in-the-middle attacks,
we require some level of authentication and integrity protections. we require some level of authentication and integrity protections.
skipping to change at page 28, line 42 skipping to change at page 30, line 25
o If the IM Recipient has a certificate, it MUST sign the IMDN. o If the IM Recipient has a certificate, it MUST sign the IMDN.
o If the IM is encrypted, the IM Recipient or intermediary MUST o If the IM is encrypted, the IM Recipient or intermediary MUST
encrypt the IMDN body, as an attacker may attempt to discern the encrypt the IMDN body, as an attacker may attempt to discern the
user's activity profile and identity from sniffing IMDNs on the user's activity profile and identity from sniffing IMDNs on the
network. network.
o The two above rules are cumulative. o The two above rules are cumulative.
The IM Recipient or intermediary MUST be capable of loading a user The IM Recipient or intermediary MUST be capable of accessing the IM
certificate. Sender's public certificate in order to verify the signature in the
IM.
An attacker can mount a distributed denial of service attack on a An attacker can mount a distributed denial of service attack on a
node by sending lots of IMs to the node with IMDN requests. Note node by sending lots of IMs to the node with IMDN requests. Note
that this is the same problem as there is without IMDN; IMDN simply that this is the same problem as there is without IMDN; IMDN simply
linearly increases the load on the node under attack. One can linearly increases the load on the node under attack. One can
mitigate, but not eliminate this threat by the endpoint immediately mitigate, but not eliminate this threat by the endpoint immediately
ignoring requests that are not authenticated. ignoring requests that are not authenticated.
Likewise, an attacker can mount a denial of service attack on an Likewise, an attacker can mount a denial of service attack on an
intermediary by asking the intermediary to explode a large list. intermediary by asking the intermediary to explode a large list.
skipping to change at page 30, line 22 skipping to change at page 32, line 10
lost in transit. The IMDN issuing mechanism may be bypassed in some lost in transit. The IMDN issuing mechanism may be bypassed in some
manner by the IM Recipient. manner by the IM Recipient.
15. IANA Considerations 15. IANA Considerations
15.1. message/imdn+xml MIME TYPE 15.1. message/imdn+xml MIME TYPE
This document registers a new MIME type "message/imdn+xml", and This document registers a new MIME type "message/imdn+xml", and
registers a new XML namespace. registers a new XML namespace.
This specification follows the guidelines of RFC3023 [6]. This specification follows the guidelines of RFC3023 [5].
MIME media type: message MIME media type: message
MIME subtype name: imdn+xml MIME subtype name: imdn+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [6]. specified in RFC 3023 [5].
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [6]. application/xml as specified in RFC 3023 [5].
Security considerations: See section 10 of RFC 3023 [6] and Security considerations: See section 10 of RFC 3023 [5] and
Section 14 of this document. Section 14 of this document.
Interoperability considerations: none. Interoperability considerations: none.
Published specification: This document. Published specification: This document.
Applications which use this media type: This document type is used to Applications which use this media type: This document type is used to
support SIP based instant messaging. support CPIM based instant messaging.
Additional information: None Additional information: None
Magic number: None Magic number: None
File extension: .cl or .xml File extension: .cl or .xml
Macintosh file type code: "TEXT" Macintosh file type code: "TEXT"
Personal and email address for further information: Hisham Khartabil Personal and email address for further information: Hisham Khartabil
(hisham.khartabil@telio.no) (hisham.khartabil@gmail.com)
Intended Usage: COMMON Intended Usage: COMMON
Author/change controller: The IETF . Author/change controller: The IETF .
15.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:imdn 15.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:imdn
This section registers a new XML namespace, as per guidelines in the This section registers a new XML namespace, as per guidelines in the
IETF XML Registry [3]. IETF XML Registry [3].
URI: The URI for this namespace is urn:ietf:params:xml:ns:imdn. URI: The URI for this namespace is urn:ietf:params:xml:ns:imdn.
Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil
(hisham.khartabil@telio.no) . (hisham.khartabil@gmail.com) .
15.3. Schema Registration 15.3. Schema Registration
This section registers a new XML schema per the procedures in [3]. This section registers a new XML schema per the procedures in [3].
URI: urn:ietf:params:xml:ns:imdn URI: urn:ietf:params:xml:ns:imdn
Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil
(hisham.khartabil@telio.no) (hisham.khartabil@gmail.com)
The XML for this schema can be found as the sole content of The XML for this schema can be found as the sole content of
Section 11.3. Section 11.3.
15.4. Message/CPIM header field registration 15.4. Registration for urn:ietf:params:imdn
Registry name: imdn
Specification: RFC XXXX. Additional values may be defined by
standards track RFCs that update or obsolete RFC XXXX (Specification
Required).
Repository: http://www.iana.org/assignments/imdn
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
characters, as defined above.
URN Formation: The URI for a header is formed from its name by:
a) replacing any non-URN characters (as defined by RFC 2141[4])
with the corresponding '%hh' escape sequence (per RFC 2396 [7]);
and
b) prepending the resulting string with 'urn:ietf:params:imdn:'.
Thus, the URI corresponding to the CPIM message IMDN header
'Disposition-Notification:' would be
'urn:ietf:params:imdn:Disposition-Notification'.
15.5. Message/CPIM Header Field Registration
This document registers the following message/cpim header fields in This document registers the following message/cpim header fields in
the cpim-header fields registry: the imdn fields registry:
Disposition-Notification - [RFCXXXX] Disposition-Notification - [RFCXXXX]
Message-ID - [RFCXXXX] Message-ID - [RFCXXXX]
Original-To - [RFCXXXX] Original-To - [RFCXXXX]
IMDN-Record-Route - [RFCXXXX] IMDN-Record-Route - [RFCXXXX]
IMDN-Route - [RFCXXXX]. IMDN-Route - [RFCXXXX].
15.5. Content-Disposition: notification 15.6. Content-Disposition: notification
This document registers one new Content-Disposition header field This document registers one new Content-Disposition header field
"disposition-types": notification. The authors request that this "disposition-types": notification. The authors request that this
values be recorded in the IANA registry for Content-Dispositions. values be recorded in the IANA registry for Content-Dispositions.
Descriptions of this "disposition-types", including motivation and Descriptions of this "disposition-types", including motivation and
examples, are given in Section 7.2.1.1 and Section 9. Short examples, are given in Section 7.2.1.1 and Section 9.
descriptions suitable for the IANA registry are: notification the
body of the message is a notification according to an earlier request Short descriptions suitable for the IANA registry are:
for a disposition notification to an instant message
notification the body of the message is a notification according to
an earlier request for a disposition notification to an instant
message
16. Acknowledgements 16. Acknowledgements
The authors would like to thank Paul Kyzivat, Ben Campbell, Adam The authors would like to thank Paul Kyzivat, Ben Campbell, Adam
Roach, Gonzalo Camarillo, Sean Olson, Eva Leppanen, Miguel Garcia, Roach, Gonzalo Camarillo, Sean Olson, Eva Leppanen, Miguel Garcia,
Eric McMurry and Jari Urpalainen for their comments and support. Eric McMurry, Jari Urpalainen and Robert Sparks for their comments
and support.
17. References 17. References
17.1. Normative References 17.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging [2] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging
(CPIM): Message Format", RFC 3862, August 2004. (CPIM): Message Format", RFC 3862, August 2004.
[3] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. [3] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
[4] Moats, R., "The URN Syntax", RFC 2141, May 1997. [4] Moats, R., "The URN Syntax", RFC 2141, May 1997.
[5] Moats, R., "The URN Namespace for IETF Documents", RFC 2648, [5] Murata, M., "XML Media Types", RFC 3023, March 1997.
August 1999.
[6] Murata, M., "XML Media Types", RFC 3023, March 1997.
[7] Bray, T., "Extensible Markup Language (XML) 1.0 (Second [6] Bray, T., "Extensible Markup Language (XML) 1.0 (Second
Edition)", W3C CR CR-xml11-20011006, October 2000. Edition)", W3C CR CR-xml11-20011006, October 2000.
[7] Berners-Lee, T., Fielding, R., and L. Masinter, "URI: Generic
Syntax", RFC 3023, August 1998.
17.2. Informative References 17.2. Informative References
[8] Rosenberg et al., J., Shulzrinne, H., Camarillo, G., Johnston, [8] Rosenberg et al., J., Shulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler,
"SIP: Session Initiation Protocol", RFC 3261, June 2002. "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[9] Campbell, B., "SIP Extension for Instant Messaging", RFC 3428, [9] Campbell, B., "SIP Extension for Instant Messaging", RFC 3428,
December 2002. December 2002.
[10] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [10] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[11] Fajman, R., "An Extensible Message Format for Message [11] Hansen, T. and G. Vaudreuil, "Message Disposition
Disposition Notifications", RFC 2298, March 1998. Notification", RFC 3798, May 2004.
[12] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE [12] Moats, R., "The URN Namespace for IETF Documents", RFC 2648,
August 1999.
[13] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE
Requests in SIP", draft-ietf-sip-uri-list-message-01.txt, Requests in SIP", draft-ietf-sip-uri-list-message-01.txt,
January 2007. January 2007.
Authors' Addresses Authors' Addresses
Eric Burger Eric Burger
BEA Systems, Inc. BEA Systems, Inc.
4 Van de Graaff Dr. 4 Van de Graaff Dr.
Burlington, MA 01803 Burlington, MA 01803
USA USA
 End of changes. 70 change blocks. 
154 lines changed or deleted 250 lines changed or added

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