draft-ietf-simple-imdn-01.txt   draft-ietf-simple-imdn-02.txt 
SIMPLE E. Burger SIMPLE E. Burger
Internet-Draft Cantata Technology Internet-Draft Cantata Technology
Intended status: Informational H. Khartabil Intended status: Informational H. Khartabil
Expires: April 16, 2007 Telio Expires: May 31, 2007 Telio
October 13, 2006 November 27, 2006
Instant Message Disposition Notification Instant Message Disposition Notification
draft-ietf-simple-imdn-01 draft-ietf-simple-imdn-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 16, 2007. This Internet-Draft will expire on May 31, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Instant Messaging (IM) refers to the transfer of messages between Instant Messaging (IM) refers to the transfer of messages between
users in real-time. 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 12 skipping to change at page 2, line 12
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 headers that enable endpoints to in RFC 3862 is extended with new headers that enable endpoints to
request IMDNs. A new message format is also defined to convey IMDNs. request IMDNs. A new message format is also defined to convey IMDNs.
This document also describes how SIP and MSRP entities behave using This document also describes how SIP and MSRP entities behave using
this extension. this extension.
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 Namespace . . . . . . . . . . . . . . . . . . 7 6.1 CPIM Header Namespace . . . . . . . . . . . . . . . . . . . 7
6.2. Disposition-Notification . . . . . . . . . . . . . . . . . 8 6.2 Disposition-Notification . . . . . . . . . . . . . . . . . 8
6.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . . . 8 6.3 Message-ID . . . . . . . . . . . . . . . . . . . . . . . . 8
6.4. Original-To . . . . . . . . . . . . . . . . . . . . . . . 8 6.4 Original-To . . . . . . . . . . . . . . . . . . . . . . . . 8
6.5. IMDN-Record-Route . . . . . . . . . . . . . . . . . . . . 8 6.5 IMDN-Record-Route . . . . . . . . . . . . . . . . . . . . . 8
6.6. IMDN-Route . . . . . . . . . . . . . . . . . . . . . . . . 8 6.6 IMDN-Route . . . . . . . . . . . . . . . . . . . . . . . . 8
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. Aggregation of IMDNs . . . . . . . . . . . . . . . . . 10 7.1.3 Aggregation of IMDNs . . . . . . . . . . . . . . . . . 10
7.1.4. Keeping State . . . . . . . . . . . . . . . . . . . . 11 7.1.4 Keeping State . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 17
10. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 17 10 Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 17
11. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 18 11 IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Structure of XML-Encoded IMDN Payload . . . . . . . . . . 18 11.1 Structure of XML-Encoded IMDN Payload . . . . . . . . . . . 18
11.1.1. The <message-id> Element . . . . . . . . . . . . . . . 18 11.1.1 The <message-id> Element . . . . . . . . . . . . . . . 18
11.1.2. The <datetime> Element . . . . . . . . . . . . . . . . 19 11.1.2 The <datetime> Element . . . . . . . . . . . . . . . . 19
11.1.3. The <recipient-uri> Element . . . . . . . . . . . . . 19 11.1.3 The <recipient-uri> Element . . . . . . . . . . . . . . 19
11.1.4. The <original-recipient-uri> Element . . . . . . . . . 19 11.1.4 The <original-recipient-uri> Element . . . . . . . . . 19
11.1.5. The <subject> Element . . . . . . . . . . . . . . . . 19 11.1.5 The <subject> Element . . . . . . . . . . . . . . . . . 19
11.1.6. The <disposition> Element . . . . . . . . . . . . . . 19 11.1.6 The <disposition> Element . . . . . . . . . . . . . . . 19
11.1.7. The <status> Element . . . . . . . . . . . . . . . . . 19 11.1.7 The <status> Element . . . . . . . . . . . . . . . . . 19
11.1.8. The <note> Element . . . . . . . . . . . . . . . . . . 20 11.1.8 The <note> Element . . . . . . . . . . . . . . . . . . 20
11.2. MIME Type for IMDN Paylaod . . . . . . . . . . . . . . . . 20 11.2 MIME Type for IMDN Paylaod . . . . . . . . . . . . . . . . 20
11.3. The RelaxNG Schema . . . . . . . . . . . . . . . . . . . . 20 11.3 The RelaxNG Schema . . . . . . . . . . . . . . . . . . . . 20
12. Transporting Messages using SIP . . . . . . . . . . . . . . . 23 12 Transporting Messages using SIP . . . . . . . . . . . . . . . 23
12.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 24 12.1 Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 24
12.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 24 12.1.1 Sending Requests . . . . . . . . . . . . . . . . . . . 24
12.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 24 12.1.2 Sending Responses . . . . . . . . . . . . . . . . . . . 24
12.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 24 12.1.3 Receiving Requests . . . . . . . . . . . . . . . . . . 24
12.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 25 12.2 Intermediary Behaviour . . . . . . . . . . . . . . . . . . 25
13. Transporting Messages using MSRP . . . . . . . . . . . . . . . 26 13 Transporting Messages using MSRP . . . . . . . . . . . . . . . 26
13.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 26 14 Security Considerations . . . . . . . . . . . . . . . . . . . 26
13.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 26 14.1 Forgery . . . . . . . . . . . . . . . . . . . . . . . . . . 28
13.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 27 14.2 Confidentiality . . . . . . . . . . . . . . . . . . . . . . 29
13.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 27 14.3 Non-Repudiation . . . . . . . . . . . . . . . . . . . . . . 29
13.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 27 15 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
14. Security Considerations . . . . . . . . . . . . . . . . . . . 28 15.1 message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 30
14.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 30 15.2 URN Sub-Namespace Registration for
14.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 30 urn:ietf:params:xml:ns:imdn . . . . . . . . . . . . . . . . 31
14.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 31 15.3 Schema Registration . . . . . . . . . . . . . . . . . . . . 31
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 15.4 Message/CPIM Header Field registration . . . . . . . . . . 31
15.1. message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 31 15.5 Content-Disposition: notification . . . . . . . . . . . . . 31
15.2. URN Sub-Namespace Registration for 16 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
urn:ietf:params:xml:ns:imdn . . . . . . . . . . . . . . . 32 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
15.3. Schema Registration . . . . . . . . . . . . . . . . . . . 32 17.1 Normative References . . . . . . . . . . . . . . . . . . . 32
15.4. Message/CPIM Header Field registration . . . . . . . . . . 32 17.2 Informative References . . . . . . . . . . . . . . . . . . 32
15.5. Content-Disposition: notification . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 Intellectual Property and Copyright Statements . . . . . . . . . . 34
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
17.1. Normative References . . . . . . . . . . . . . . . . . . . 33
17.2. Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 35
1. Introduction 1 Introduction
In many user-to-user message exchange systems, message senders often In many user-to-user message exchange systems, message senders often
wish to know if the human recipient actually received or read a wish to know if the human recipient actually received or read a
message. message.
Electronic Mail [12] deals with this situation with Message Delivery Electronic Mail [12] deals with this situation with Message Delivery
Notifications [13]. After the recipient views the message, her mail Notifications [13]. After the recipient views the message, her mail
user agent generates a Message Delivery Notification, or MDN. The user agent generates a Message Delivery Notification, or MDN. The
MDN is an e-mail that follows the format prescribed by RFC2298 [13]. MDN is an e-mail that follows the format prescribed by RFC2298 [13].
The fixed format ensures that an automaton can process the message. The fixed format ensures that an automaton can process the message.
skipping to change at page 4, line 37 skipping to change at page 4, line 37
delivery (i.e. a message did not get delivered successfully), read delivery (i.e. a message did not get delivered successfully), read
notifications as well as processed notifications. By using CPIM notifications as well as processed notifications. By using CPIM
headers, the IMDN request and delivery are abstracted outside the headers, the IMDN request and delivery are abstracted outside the
transport protocol allowing interoperability between different IM transport protocol allowing interoperability between different IM
systems. Likewise, the mechanism does not rely on session-mode systems. Likewise, the mechanism does not rely on session-mode
versus page-mode. versus page-mode.
This document also describes how SIP and MSRP entities behave using This document also describes how SIP and MSRP entities behave using
this extension. this extension.
2. Conventions 2 Conventions
In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED', In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED',
'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY',
and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] and and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] and
indicate requirement levels for compliant implementations. indicate requirement levels for compliant implementations.
3. 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
skipping to change at page 5, line 32 skipping to change at page 5, line 32
disposition notification information. It is always of MIME type disposition notification information. It is always of MIME type
"message/imdn+xml". "message/imdn+xml".
o Disposition type: the type of IMDN that can be requested. This o Disposition type: the type of IMDN that can be requested. This
specification defines three, namely "delivery", "processing" and specification defines three, namely "delivery", "processing" and
"read" disposition types. "read" disposition types.
o Transport Protocol Message: An IM or an IMDN wrapped in a o Transport Protocol Message: An IM or an IMDN wrapped in a
transport protocol like SIP or MSRP. transport protocol like SIP or MSRP.
4. Overview 4 Overview
The basic protocol flow is depicted in the diagram below. An IM The basic protocol flow is depicted in the diagram below. An IM
Sender creates an IM, adds to it IMDN request information it is Sender creates an IM, adds to it IMDN request information it is
interested in receiving, then sends its. At a certain point in time, interested in receiving, then sends its. At a certain point in time,
the IM Recipient or an intermediary determines that the user or the IM Recipient or an intermediary determines that the user or
application has received, did not receive or has read the IM or application has received, did not receive or has read the IM or
otherwise disposed the IM. The mechanism by which an IM Recipient otherwise disposed the IM. The mechanism by which an IM Recipient
determines its user has read an IM is beyond the scope of this determines its user has read an IM is beyond the scope of this
document. At that point, the IM Recipient or intermediary document. At that point, the IM Recipient or intermediary
automatically generates a notification message to the IM Sender. automatically generates a notification message to the IM Sender.
skipping to change at page 6, line 28 skipping to change at page 6, line 28
| | | |
Note that the recipient of an IMDN, in some instances, may not be the Note that the recipient of an IMDN, in some instances, may not be the
IM Sender. This is specifically true for page-mode IMs where the IM Sender. This is specifically true for page-mode IMs where the
Address of Record (AOR) of the IM Sender, that is present in the Address of Record (AOR) of the IM Sender, that is present in the
IMDN, resolves to a different location to where the IM originated. IMDN, resolves to a different location to where the IM originated.
For simplicity, the rest of this document assumes that the IM Sender For simplicity, the rest of this document assumes that the IM Sender
and the IMDN Recipient are the same and therefore will refer to both and the IMDN Recipient are the same and therefore will refer to both
as the IM Sender. as the IM Sender.
5. Disposition Types 5 Disposition Types
There are three broad categories of disposition states. They are There are three broad categories of disposition states. They are
delivery, processing and read. Future extensions may introduce delivery, processing and read. Future extensions may introduce
others. others.
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 by the IM Recipient for the IM Sender o "forbidden" indicate denial by the IM Recipient for the IM Sender
to receive the requested IMDN. 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.
5.2. Processing 5.2 Processing
The processing notification type indicates that an IM has been The processing notification type indicates that an IM has been
processed by an intermediary. The processing notification type can processed by an intermediary. The processing notification type can
have the following states: have the following states:
o "processed" is a general state of the IM indicating it has been o "processed" is a general state of the IM indicating it has been
processed. processed.
o "stored" state indicates that the IM has been stored by the o "stored" state indicates that the IM has been stored by the
intermediary for later delivery. intermediary for later delivery.
o "forbidden" indicate denial by the IM Recipient for the IM Sender o "forbidden" indicate denial by the IM Recipient for the IM Sender
to receive the requested IMDN. 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.
5.3. Read 5.3 Read
The read notification type indicates whether the IM Recipient The read notification type indicates whether the IM Recipient
displayed the IM to the user or not. The read notification type can displayed the IM to the user or not. The read notification type can
have the following states: have the following states:
o "read" is a state indicating that the IM has been read. o "read" is a state indicating that the IM has been read.
o "forbidden" indicate denial by the IM Recipient for the IM Sender o "forbidden" indicate denial by the IM Recipient for the IM Sender
to receive the requested IMDN. 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.
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 MUST determine a priori that the user actually read the IM. Thus one MUST
NOT use the protocol described here as a non-repudiation service. NOT use the protocol described here as a non-repudiation service.
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
headers. headers.
6.1. CPIM Header Namespace 6.1 CPIM Header 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 headers defined in the following sections. The namespace extension headers defined in the following sections. The namespace
is: urn:ietf:params:cpim-headers:imdn As per CPIM [2] requirements, is: urn:ietf:params:cpim-headers:imdn As per CPIM [2] requirements,
the new headers defined in the following sections are prepended by the new headers defined in the following sections are prepended by
the string "imdn." in CPIM messages. the string "imdn." in CPIM messages.
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
The Message-ID header field contains a globally unique message The Message-ID header field contains a globally unique message
identifier that is used by the IM Sender to correlate received IMDNs identifier that is used by the IM Sender to correlate received IMDNs
by comparing its value with the value of the <message-id> element by comparing its value with the value of the <message-id> element
present in the IMDN payload. This header field is mandatory with present in the IMDN payload. This header field is mandatory with
sending an IM and requesting an IMDN. IMDNs also carry this header sending an IM and requesting an IMDN. IMDNs also carry this header
field. The syntax is defined in Section 10. field. The syntax is defined in Section 10.
6.4. Original-To 6.4 Original-To
The Original-To header field is sometimes added to an IM by an The Original-To header field is sometimes added to an IM by an
intermediary and populated with of the address of the IM Sender. It intermediary and populated with of the address of the IM Sender. It
is used by the IM Recipient to indicate in the IMDNs (by populating is used by the IM Recipient to indicate in the IMDNs (by populating
the <original-recipient-uri> element) the original address the IM was the <original-recipient-uri> element) the original address the IM was
sent to. This header is mandatory if the intermediary changes the sent to. This header is mandatory if the intermediary changes the
CPIM To header field value. The header MUST NOT appear more than CPIM To header field value. The header MUST NOT appear more than
once in an IM. The header field value MUST NOT be changed by an once in an IM. The header field value MUST NOT be changed by an
intermediary if it was already present. The syntax is defined in intermediary if it was already present. The syntax is defined in
Section 10. Section 10.
6.5. IMDN-Record-Route 6.5 IMDN-Record-Route
Intermediaries have the capability of indicating that IMDNs should be Intermediaries have the capability of indicating that IMDNs should be
sent through it (otherwise, IMDNs will not visit the intermediary). sent through it (otherwise, IMDNs will not visit the intermediary).
An intermediary that request IMDNs to be sent through itself adds an An intermediary that request IMDNs to be sent through itself adds an
IMDN-Record-Route header field to the IM. The value of the IMDN- IMDN-Record-Route header field to the IM. The value of the IMDN-
Record-Route header field is set to the address of that intermediary. Record-Route header field is set to the address of that intermediary.
Multiple IMDN-Record-Route header fields can appear in an IM. The Multiple IMDN-Record-Route header fields can appear in an IM. The
syntax is defined in Section 10. syntax is defined in Section 10.
6.6. IMDN-Route 6.6 IMDN-Route
The IMDN-Route header field provides routing information by including The IMDN-Route header field provides routing information by including
one or more addresses where an IMDN must be routed through. On one or more addresses where an IMDN must be routed through. On
creating an IMDN, an IM recipient copies the contents of the IMDN- creating an IMDN, an IM recipient copies the contents of the IMDN-
Record-Route present in the IM into the IMDN-Route of the IMDN. Record-Route present in the IM into the IMDN-Route of the IMDN.
Multiple IMDN-Route header fields can appear in an IMDN. The syntax Multiple IMDN-Route header fields can appear in an IMDN. The syntax
is defined in Section 10. is defined in Section 10.
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 RFC 3862 [2]. The Content-type header An IM is constructed using RFC 3862 [2]. The Content-type header
field indicates the MIME type of the request payload. field indicates the MIME type of the request payload.
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
In this specification, the IM Sender can request two types of In this specification, the IM Sender can request two types of
delivery notifications: a failure delivery notification and a success delivery notifications: a failure delivery notification and a success
delivery notification. An IM Sender requests failure delivery delivery notification. 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
be requested for the same IM. be requested for the same IM.
skipping to change at page 10, line 27 skipping to change at page 10, line 27
To: Bob <im:bob@example.com> To: Bob <im:bob@example.com>
NS: imdn <urn:ietf:params:cpim-headers:imdn> NS: imdn <urn:ietf:params:cpim-headers: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
An IM Sender matches an IMDN to an IM by matching the Message-ID An IM Sender matches an IMDN to an IM by matching the Message-ID
header field value in the IM with the <message-id> element value in header field value in the IM with the <message-id> element value in
the body of the IMDN. If the IM was delivered to multiple the body of the IMDN. If the IM was delivered to multiple
recipients, the IM Sender uses the <recipient-uri> element or the recipients, the IM Sender uses the <recipient-uri> element or the
<original-recipient-uri> element in the XML body of the IMDN it <original-recipient-uri> element in the XML body of the IMDN it
received to identify the IM Recipient (IMDN Sender). received to identify the IM Recipient (IMDN Sender).
7.1.3. Aggregation of IMDNs 7.1.3 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. It MAY choose to either get one IMDN from each IM Recipient IMDNs. It MAY choose to either get one IMDN from each IM Recipient
individually or get an aggregated IMDN (the URI-List server individually or get an aggregated IMDN (the URI-List server
aggregates the IMDNs and send the one or more aggregated IMDNs). The aggregates the IMDNs and send the one or more aggregated IMDNs). The
IM Sender requests aggregation by adding the Disposition-Notification IM Sender requests aggregation by adding the Disposition-Notification
header field parameter "aggregate". The absence of such a parameter header field parameter "aggregate". The absence of such a parameter
indicates that the IM Sender does not wish for IMDNs to be indicates that the IM Sender does not wish for IMDNs to be
aggregated. Aggregation can be requested per disposition type. For aggregated. Aggregation can be requested per disposition type. For
skipping to change at page 11, line 19 skipping to change at page 11, line 19
An IM Sender that requested an aggregated IMDN MUST be prepared to An IM Sender that requested an aggregated IMDN MUST be prepared to
receive multiple aggregated or non-aggregated IMDNs. See Section 8.2 receive multiple aggregated or non-aggregated IMDNs. See Section 8.2
for details. for details.
An IM Sender MUST be prepared to receive aggregated IMDNs even if it An IM Sender MUST be prepared to receive aggregated IMDNs even if it
did not request the URI-List server to do so. See again Section 8.2 did not request the URI-List server to do so. See again Section 8.2
for details. Note that the "aggregate" parameter is a hint for for details. Note that the "aggregate" parameter is a hint for
intermediaries and does not require the intermediaries to aggregate intermediaries and does not require the intermediaries to aggregate
IMDNs. IMDNs.
7.1.4. Keeping State 7.1.4 Keeping State
This specification does not mandate the IM Sender to keep state for a This specification does not mandate the IM Sender to keep state for a
sent IM. sent IM.
Once an IM Sender sends an IM containing an IMDN request, it MAY Once an IM Sender sends an IM containing an IMDN request, it MAY
preserve the IM context, principally the Message-ID, and other user- preserve the IM context, principally the Message-ID, and other user-
identifiable information such as the IM subject or content, and date identifiable information such as the IM subject or content, and date
and time it was sent. Without preservation of the IM context, the IM and time it was sent. Without preservation of the IM context, the IM
Sender will not be able to correlate the IMDN with the IM it sent. Sender will not be able to correlate the IMDN with the IM it sent.
The IM Sender may find it impossible to preserve IM state if it has The IM Sender may find it impossible to preserve IM state if it has
skipping to change at page 12, line 11 skipping to change at page 12, line 11
IMDNs may legitimately never be received. On the other hand, and IMDNs may legitimately never be received. On the other hand, and
IMDN may simply take a very long time. Some clients may choose to IMDN may simply take a very long time. Some clients may choose to
purge the state associated with the sent IM. This is the reason for purge the state associated with the sent IM. This is the reason for
adding the time stamp in the IM and having it returned in the IMDN. 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.2. IM Recipient 7.2 IM Recipient
7.2.1. Constructing IMDNs 7.2.1 Constructing IMDNs
IM recipients examine the contents of the Disposition-Notification IM recipients examine the contents of the Disposition-Notification
header field of the CPIM message to determine if an IMDN must be header field of the CPIM message to determine if an IMDN must be
generated for that IM. Disposition-Notification header fields of generated for that IM. Disposition-Notification header fields of
CPIM messages can include one or more values. This implies that IM CPIM messages can include one or more values. This implies that IM
recipients may need to generate zero, one, or more IMDNs for that IM, recipients may need to generate zero, one, or more IMDNs for that IM,
for example a delivery notification as well as a read notification. for example a delivery notification as well as a read notification.
In this case the IM Recipient MUST be able to construct multiple In this case the IM Recipient MUST be able to construct multiple
IMDNs per IM. An IM Recipient MUST NOT construct more than one IMDN IMDNs per IM. An IM Recipient MUST NOT construct more than one IMDN
per disposition type. I.e. It must not, for example, generate a per disposition type. I.e. It must not, for example, generate a
skipping to change at page 12, line 47 skipping to change at page 12, line 47
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. apply to an IMDN.
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 address in IMDN and maintain the order. The IMDN is then sent to the address in
the top IMDN-Route header field. the top IMDN-Route header field.
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 RFC 3862 [2]. For delivery notifications, the Content-type using RFC 3862 [2]. For delivery notifications, the Content-type
MUST be of type "message/imdn+xml". It is an XML document. The MUST be of type "message/imdn+xml". It is an XML document. The
schema is described Section 11. The delivery notification MUST schema is described Section 11. The delivery notification MUST
contain a Content-Disposition header field with value "notification". contain a Content-Disposition header field with 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.
An example looks like the following: An example looks like the following:
skipping to change at page 13, line 35 skipping to change at page 13, line 35
<original-recipient-uri>im:bob@example.com</original-recipient-uri> <original-recipient-uri>im:bob@example.com</original-recipient-uri>
<disposition> <disposition>
<delivery/> <delivery/>
</disposition> </disposition>
<status> <status>
<delivered/> <delivered/>
</status> </status>
<note lang="en">The IM was successfully Delivered</note> <note lang="en">The IM was successfully Delivered</note>
</imdn> </imdn>
7.2.1.2. Constructing Read Notifications 7.2.1.2 Constructing Read Notifications
A read notification is constructed in a similar fashion as the 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:
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>
skipping to change at page 14, line 34 skipping to change at page 14, line 34
<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. internal error by the server.
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.
An intermediary that forwards an IM MAY change the recipient address An intermediary that forwards an IM MAY change the recipient address
in the CPIM To header field when forwarding (for example, a URI-List in the CPIM To header field when forwarding (for example, a URI-List
server changes the IM Recipient address from its own to the address server changes the IM Recipient address from its own to the address
of the final recipient of that IM for every copy it makes to be sent of the final recipient of that IM for every copy it makes to be sent
to the list members). In this case, the intermediary MUST add an to the list members). In this case, the intermediary MUST 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
skipping to change at page 15, line 24 skipping to change at page 15, line 24
indicated in the now top IMDN-Route header. If no IMDN-Route headers indicated in the now top IMDN-Route header. If no IMDN-Route headers
are present, the IMDN is forwarded to the address in the To header are present, the IMDN is forwarded to the address in the To header
field. field.
An intermediary MUST remove any information about the final An intermediary MUST remove any information about the final
recipients of a list if the list membership is not disclosed. The recipients of a list if the list membership is not disclosed. The
intermediary does that by removing the <recipient-uri> element and/or intermediary does that by removing the <recipient-uri> element and/or
<original-recipient-uri> element from the body of the IMDN before <original-recipient-uri> element from the body of the IMDN before
forwarding it to the IM Sender. forwarding it to the IM Sender.
8.1. Constructing Processing Notifications 8.1 Constructing Processing Notifications
Intermediaries are the only entities that construct processing Intermediaries are the only entities that construct processing
notifications. They do so only if the IM Sender has requested a notifications. They do so only if the IM Sender has requested a
processing notification by including a Disposition-Notification processing notification by including a Disposition-Notification
header field with value "processing". header field with value "processing".
The intermediary can create and send processing notifications The intermediary can create and send processing notifications
indicating that an IM has been processed or stored. The intermediary indicating that an IM has been processed or stored. The intermediary
MUST NOT send more than one IMDN for the same disposition type. I.e. MUST NOT send more than one IMDN for the same disposition type. I.e.
It must not send a processing notification indicating that an IM is It must not send a processing notification indicating that an IM is
skipping to change at page 16, line 31 skipping to change at page 16, line 31
<status> <status>
<processed/> <processed/>
</status> </status>
<note lang="en">The IM has been processed</note> <note lang="en">The IM has been processed</note>
</imdn> </imdn>
There are situations where the intermediary cannot know the fate of There are situations where the intermediary cannot know the fate of
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.
When a URI-List server receives an IM, it needs to examine When a URI-List server receives an IM, it needs to examine
Disposition-Notification header fields. If an IMDN request contains Disposition-Notification header fields. If an IMDN request contains
the "aggregate" parameter, the URI-List server MUST wait for a the "aggregate" parameter, the URI-List server MUST wait for a
configurable period of time or until all recipients have sent the configurable period of time or until all recipients have sent the
IMDN (whichever comes first) before the URI-List server sends an IMDN (whichever comes first) before the URI-List server sends an
aggregated IMDN. Note that some IMDNs, for example read aggregated IMDN. Note that some IMDNs, for example read
notifications, may never come due to user settings. It is an notifications, may never come due to user settings. It is an
skipping to change at page 17, line 22 skipping to change at page 17, line 22
also choose to ignore an aggregation request and send individual also choose to ignore an aggregation request and send individual
IMDNs instead. IMDNs instead.
The aggregated IMDN is constructed using the multipart/mixed MIME The aggregated IMDN is constructed using the multipart/mixed MIME
type and including all the received IMDNs as message/imdn+xml as type and including all the received IMDNs as message/imdn+xml as
individual payloads. individual payloads.
There are scenarios where an intermediary needs to generate IMDNs, There are scenarios where an intermediary needs to generate IMDNs,
see Section 12.2 for further details. see Section 12.2 for further details.
9. Identifying Messages 9 Identifying Messages
Messages are typically carried in a transport protocol like SIP [9]. Messages are typically carried in a transport protocol like SIP [9].
The message is an IM if the content-type header field present in it The message is an IM if the content-type header field present in it
has a value that is NOT "message/imdn+xml". has a value that is NOT "message/imdn+xml".
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 header field present has a value of "message/imdn+xml", the type header field present has a value of "message/imdn+xml", the
Content-Disposition header field has a value of "notification", and Content-Disposition header field has a value of "notification", and
the <disposition> element in that xml body has a sub-element the <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 syntax as The following syntax specification uses the message header syntax as
described in Section 3 of RFC3862 [2]. described in Section 3 of RFC3862 [2].
Header syntax is described without a namespace qualification. Header syntax is described without a namespace qualification.
Following the rules in RFC3862 [2], header names and other text are Following the rules in RFC3862 [2], header names and other text are
case sensitive and MUST be used as given, using exactly the indicated case sensitive and MUST be used as given, using exactly the indicated
upper-case and lower-case letters. upper-case and lower-case letters.
Disposition-Notification = Disposition-Notification =
skipping to change at page 18, line 21 skipping to change at page 18, line 21
disp-notify-params = "aggregate" / generic-param disp-notify-params = "aggregate" / generic-param
Message-ID = "Message-ID" ": " Token Message-ID = "Message-ID" ": " Token
Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">" Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">"
IMDN-Record-Route = "IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">" IMDN-Record-Route = "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 [7] 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 [5]
and extended by [3]. This urn is: urn:ietf:params:xml:ns:imdn. and extended by [3]. This urn is: urn:ietf:params:xml:ns:imdn.
skipping to change at page 18, line 47 skipping to change at page 18, line 47
The root element is <imdn>. The <imdn> element has sub-elements, The root element is <imdn>. The <imdn> element has sub-elements,
namely <message-id>, <datetime>, <recipient-uri>, <original- namely <message-id>, <datetime>, <recipient-uri>, <original-
recipient-uri>, <subject>, <disposition>, <status>, and <note>. recipient-uri>, <subject>, <disposition>, <status>, and <note>.
Those elements are described in details in the following sections. Those elements are described in details in the following sections.
<disposition> and <status> can be extended in the future to include <disposition> and <status> can be extended in the future to include
new sub-elements not defined in this document. Those new elements new sub-elements not defined in this document. Those new elements
MUST be defined in an RFC. MUST be defined in an RFC.
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
IM was sent (not the IMDN). This information is obtained from the IM was sent (not the IMDN). This information is obtained from the
DateTime header field of the IM. DateTime header field of the IM.
11.1.3. The <recipient-uri> Element 11.1.3 The <recipient-uri> Element
The <recipient-uri> element is optional and carries the URI of the The <recipient-uri> element is optional and carries the URI of the
final recipient. This information is obtained from the To header final recipient. This information is obtained from the To header
field of the IM. field of the IM.
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 and carries the text that was in
the Subject header field, if any. This allows for a human level the Subject header field, if any. This allows for a human level
correlation between an IM and an IMDN. correlation between an IM and an IMDN.
11.1.6. The <disposition> Element 11.1.6 The <disposition> Element
The <disposition> element is mandatory and carries the disposition The <disposition> element is mandatory and carries the disposition
type that the IM Sender requested and is being reported. It can type that the IM Sender requested and is being reported. It can
carry one of the sub-elements <delivery>, <processing>, <read> or any carry one of the sub-elements <delivery>, <processing>, <read> or any
other future extension. other future extension.
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 in the <disposition> element. For disposition
type <delivery>, it can carry one of the sub-elements <delivered>, type <delivery>, it can carry one of the sub-elements <delivered>,
<failed>, <forbidden> or <error>. For disposition type <read>, it <failed>, <forbidden> or <error>. For disposition type <read>, it
can carry one of the sub-elements <read>, <forbidden> or <error>. can carry one of the sub-elements <read>, <forbidden> or <error>.
For disposition type <processing>, it can carry one of the sub- For disposition type <processing>, it can carry one of the sub-
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 Paylaod
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"
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">
skipping to change at page 23, line 47 skipping to change at page 23, line 47
</attribute> </attribute>
<ref name="anyIMDN"/> <ref name="anyIMDN"/>
</choice> </choice>
</zeroOrMore> </zeroOrMore>
</mixed> </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
A SIP MESSAGE request is constructed using RFC 3428 [10]. The A SIP MESSAGE request is constructed using RFC 3428 [10]. The
Content-type header field indicates the MIME type of the request Content-type header field indicates the MIME type of the request
payload. When using this extension, the Content-type header field payload. When using this extension, the Content-type header field
MUST be of MIME type "message/cpim" [2] for both 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 [15]. differences are indicated in [15].
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 [10]. Of course, an endpoint will send a according to RFC3428 [10]. Of course, an endpoint will send a
response to the MESSAGE request regardless of 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
12.1.3.1. Instant Message 12.1.3.1 Instant Message
A SIP MESSAGE request is identified as an IM by examining its A SIP MESSAGE request is identified as an IM by examining its
contents according to Section 9. contents according to Section 9.
If an IM Recipient received a SIP MESSAGE request that is an IM that If an IM Recipient received a SIP MESSAGE request that is an IM that
requested a positive-delivery notification, and that IM Recipient has requested a positive-delivery notification, and that IM Recipient has
constructed and sent a SIP 2xx class response, it MAY generate a constructed and sent a SIP 2xx class response, it MAY generate a
positive-delivery notification after making sure that the IM has been positive-delivery notification after making sure that the IM has been
delivered to the user or application (a GW, for example, can generate delivered to the user or application (a GW, for example, can generate
a 2xx response before it has been guaranteed that the final recipient a 2xx response before it has been guaranteed that the final recipient
skipping to change at page 25, line 21 skipping to change at page 25, line 21
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.
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 [15]. to [15].
If an intermediary generates a SIP 2xx class response to a SIP If an intermediary generates a SIP 2xx class response to a SIP
skipping to change at page 26, line 27 skipping to change at page 26, line 27
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
13.1. Endpoint Behaviour
13.1.1. Sending Requests
MSRP Relays MUST NOT generate IMDNs.
An MSRP SEND request is constructed using [11]. The content-type
header field indicates the MIME type of the request payload. When
using this extension, the content-type header field MUST be of MIME
type "message/cpim" [2] for both IMs and IMDNs. The payload is
constructed according to Section 7.
MSRP has built in delivery reports and therefore does not require
delivery notifications as defined in this specification. Read
notifications and any future defined IMDN dispositions, however, are
still relevant. Therefore, an IM Sender MUST NOT create MSRP SEND
requests requiring a positive-delivery notification or a negative-
delivery notification.
For SEND requests that are IMDNs, the IM Recipient MUST NOT request a
delivery report (an MSRP REPORT to a SEND request). I.e. It MUST
populate the request with a Failure-Report header field with the
value "no" and with a Success-Report header field with value "no" (or
alternatively leave out that header field since it defaults to "no").
The IM Recipient also MUST NOT request an IMDN for a SEND request
that is an IMDN.
An MSRP SEND request to multiple recipients is constructed in a
similar manner as a SEND request to a single recipient. The
differences are indicated in [14].
13.1.2. Sending Responses
An endpoint receiving an MSRP SEND request constructs an MSRP
response according to [11] if needed. Section 7.2 of [11] describes
when to send and when not to send an MSRP response. For SEND
requests that are IMDNs, a response MUST NOT be generated. This is
not a special case; for SEND requests that contain a Failure-Report
header field with the value "no" and a Success-Report header field
with value "no" the IM Sender does not need to start a timer and the
IM Recipient does not send a transactional response.
13.1.3. Receiving Requests
13.1.3.1. Instant Message
An MSRP SEND request is identified as an IM by examining its contents
according to Section 9.
13.1.3.2. Read Report
An MSRP SEND request is identified as read notification by examining
its contents according to Section 9. The IM Sender MUST ignore any
requests for read notification, or any kind of IMDNs for an IMDN.
13.2. Intermediary Behaviour
In this context, application servers (including conference servers IMDN is not generally applicable to MSRP. MSRP already provides a
and Store-and-Forward server) and gateways are defined as built-in mechanism to supply positive and negatie delivery reports.
intermediaries. MSRP Relays MUST NOT generate IMDNs but MUST relay
them.
An MSRP SEND request to multiple recipients is forwarded according to While MSRP does not provide a built-in Read or Processing
[14]. notification dispositions, those are generally not considered as
useful information session IM. This is because the assumption behind
MSRP is that SEND requests do not reach a mailbox where incoming IMs
have to be open, but to an application that renders sequentially
those incoming IMs, providing the session experience. This kind of
applications has no means of identifying when a user has read the IM
and therefore cannot useful information for the sender.
MSRP has built in delivery reports and therefore does not require If new requirements arise in the future determining the need for IMDN
delivery notifications as defined in this specification. An MSRP in MSRP, new specifications can be drafted.
intermediary MUST NOT generate IMDNs. A Store-and-Forwards server
(the equivalent of a voice-mail server) can send stored session IMs
to their destination and forward the request for read notifications,
if any. The read notification most likely has to be an aggregated
read notification for all the IMs that were stored for that session,
and the aggregation has to be done at the IM Recipient. It is
unknown at this point how a MSRP store-and-forward server
communicates with the recipient in order to send the IMs. This is
outside the scope of this document and is left as a future exercise.
14. Security Considerations 14 Security Considerations
IMDNs provide a fine-grained view of the activity of the IM Recipient IMDNs provide a fine-grained view of the activity of the IM Recipient
and thus deserves particularly careful confidentiality protection so and thus deserves particularly careful confidentiality protection so
that only the intended recipient of the IMDN will receive the IMDN that only the intended recipient of the IMDN will receive the IMDN
(in most cases, the intended recipient of the IMDN is the IM Sender). (in most cases, the intended recipient of the IMDN is the IM Sender).
Since IMDNs are carried by using the IM protocol itself, all security Since IMDNs are carried by using the IM protocol itself, all security
considerations of the underlying IM protocol also apply to the IMDNs. considerations of the underlying IM protocol also apply to the IMDNs.
The threats in the IMDN system, over and beyond the threats inherent The threats in the IMDN system, over and beyond the threats inherent
skipping to change at page 30, line 14 skipping to change at page 28, line 47
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 and intermediary by asking the intermediary to explode a large list and
to direct the intermediary to aggregate the IMDNs from the targets of to direct the intermediary to aggregate the IMDNs from the targets of
the list. the 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 to the CPIM headers), MUST consume the IM and Original-To header to the CPIM headers), MUST consume the IM and
create a new copy of it that the intermediary signs itself. 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, read notification could
be forged to indicate that a IM Recipient has read the IM. be forged to indicate that a IM Recipient has read the IM.
Unsolicited IMDNs is also another form of forgery. 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
to issue an IMDN, such as in the health care field or financial to issue an IMDN, such as in the health care field or financial
community. community.
skipping to change at page 31, line 14 skipping to change at page 29, line 47
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.
An unencrypted IMDN could reveal confidential information about an An unencrypted IMDN could reveal confidential information about an
encrypted IM. It is a MUST that the same level of security applied encrypted IM. It is a MUST that the same level of security applied
to an IM to be applied to its IMDNs. For example, if an IM is signed to an IM to be applied to its IMDNs. For example, if an IM is signed
and encrypted, and IMDN must also be signed and encrypted. and encrypted, and IMDN must also be signed and encrypted.
14.3. Non-Repudiation 14.3 Non-Repudiation
IMDNs cannot be relied on as a guarantee that an IM was or was not IMDNs cannot be relied on as a guarantee that an IM was or was not
seen by the user. Even if IMDNs are not actively forged, they may be seen by the user. Even if IMDNs are not actively forged, they may be
lost in transit. The IMDN issuing mechanism may be bypassed in some lost in transit. The IMDN issuing mechanism may be bypassed in some
manner by the IM Recipient. manner by the IM Recipient.
15. IANA Considerations 15 IANA Considerations
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 [6].
MIME media type: message MIME media type: message
MIME subtype name: imdn+xml MIME subtype name: imdn+xml
skipping to change at page 32, line 20 skipping to change at page 31, line 5
Macintosh file type code: "TEXT" Macintosh file type code: "TEXT"
Personal and email address for further information: Hisham Khartabil Personal and email address for further information: Hisham Khartabil
(hisham.khartabil@telio.no) (hisham.khartabil@telio.no)
Intended Usage: COMMON Intended Usage: COMMON
Author/change controller: The IETF . Author/change controller: The IETF .
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@telio.no) .
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@telio.no)
The XML for this schema can be found as the sole content of The XML for this schema can be found as the sole content of
Section 11.3. Section 11.3.
15.4. Message/CPIM Header Field registration 15.4 Message/CPIM Header Field registration
This document registers the following message/cpim header fields in This document registers the following message/cpim header fields in
the cpim-headers registry: the cpim-headers registry:
Disposition-Notification - [RFCXXXX] Disposition-Notification - [RFCXXXX]
Message-ID - [RFCXXXX] Message-ID - [RFCXXXX]
Original-To - [RFCXXXX] Original-To - [RFCXXXX]
IMDN-Record-Route - [RFCXXXX] IMDN-Record-Route - [RFCXXXX]
IMDN-Route - [RFCXXXX]. IMDN-Route - [RFCXXXX].
15.5. Content-Disposition: notification 15.5 Content-Disposition: notification
This document registers one new Content-Disposition header This document registers one new Content-Disposition header
"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. Short
descriptions suitable for the IANA registry are: notification the descriptions suitable for the IANA registry are: notification the
body of the message is a notification according to an earlier request body of the message is a notification according to an earlier request
for a disposition notification to an instant message 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 and Roach, Gonzalo Camarillo, Sean Olson, Eva Leppanen, Miguel Garcia,
Eric McMurry for their comments and support. Eric McMurry and Jari Urpalainen 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.
 End of changes. 75 change blocks. 
215 lines changed or deleted 149 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/