draft-ietf-simple-imdn-09.txt   draft-ietf-simple-imdn-10.txt 
SIMPLE E. Burger SIMPLE E. Burger
Internet-Draft Internet-Draft
Intended status: Standards Track H. Khartabil Intended status: Standards Track H. Khartabil
Expires: April 20, 2009 Ericsson Australia Expires: June 12, 2009 Ericsson Australia
October 17, 2008 December 09, 2008
Instant Message Disposition Notification Instant Message Disposition Notification
draft-ietf-simple-imdn-09 draft-ietf-simple-imdn-10
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 20, 2009. This Internet-Draft will expire on June 12, 2009.
Abstract Abstract
Instant Messaging (IM) refers to the transfer of messages between Instant Messaging (IM) refers to the transfer of messages between
users in real-time. This document provides a mechanism whereby users in real-time. This document provides a mechanism whereby
endpoints can request Instant Message Disposition Notifications endpoints can request Instant Message Disposition Notifications
(IMDN), including delivery, processing, and displayed notifications, (IMDN), including delivery, processing, and displayed notifications,
for page-mode instant messages. for page-mode instant messages.
The Common Profile for Instant Messaging (CPIM) data format specified The Common Profile for Instant Messaging (CPIM) data format specified
skipping to change at page 2, line 35 skipping to change at page 2, line 35
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 . . . . . . . . . . . . . . . 11 7.1.2. Matching IMs with IMDNs . . . . . . . . . . . . . . . 11
7.1.3. Keeping State . . . . . . . . . . . . . . . . . . . . 11 7.1.3. Keeping State . . . . . . . . . . . . . . . . . . . . 11
7.1.4. Aggregation of IMDNs . . . . . . . . . . . . . . . . . 12 7.1.4. Aggregation of IMDNs . . . . . . . . . . . . . . . . . 12
7.2. IM Recipient . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. IM Recipient . . . . . . . . . . . . . . . . . . . . . . . 12
7.2.1. Constructing IMDNs . . . . . . . . . . . . . . . . . . 12 7.2.1. Constructing IMDNs . . . . . . . . . . . . . . . . . . 12
8. Intermediary Behaviour . . . . . . . . . . . . . . . . . . . . 15 8. Intermediary Behaviour . . . . . . . . . . . . . . . . . . . . 15
8.1. Constructing Processing Notifications . . . . . . . . . . 16 8.1. Constructing Processing Notifications . . . . . . . . . . 16
8.2. Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 17 8.2. Constructing Delivery Notifications . . . . . . . . . . . 17
8.3. Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 18
9. Identifying Messages . . . . . . . . . . . . . . . . . . . . . 20 9. Identifying Messages . . . . . . . . . . . . . . . . . . . . . 20
10. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 20 10. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 20
11. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Structure of XML-Encoded IMDN Payload . . . . . . . . . . 21 11.1. Structure of XML-Encoded IMDN Payload . . . . . . . . . . 21
11.1.1. The <message-id> Element . . . . . . . . . . . . . . . 22 11.1.1. The <message-id> Element . . . . . . . . . . . . . . . 22
11.1.2. The <datetime> Element . . . . . . . . . . . . . . . . 22 11.1.2. The <datetime> Element . . . . . . . . . . . . . . . . 22
11.1.3. The <recipient-uri> Element . . . . . . . . . . . . . 22 11.1.3. The <recipient-uri> Element . . . . . . . . . . . . . 22
11.1.4. The <original-recipient-uri> Element . . . . . . . . . 23 11.1.4. The <original-recipient-uri> Element . . . . . . . . . 23
11.1.5. The <subject> Element . . . . . . . . . . . . . . . . 23 11.1.5. The <subject> Element . . . . . . . . . . . . . . . . 23
11.1.6. The <delivery-notification>, 11.1.6. The <delivery-notification>,
skipping to change at page 12, line 34 skipping to change at page 12, line 34
example if the IMDN indicates that the IM the user sent at 2 p.m. 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 Protocol Message (typically using a URI-List server
[I-D.ietf-sip-uri-list-message]) and request IMDNs. An IM Sender [I-D.ietf-sip-uri-list-message]) and request IMDNs. An IM Sender
that requested IMDNs MUST be prepared to receive multiple aggregated that requested IMDNs MUST be prepared to receive multiple aggregated
or non-aggregated IMDNs. See Section 8.2 for details. or non-aggregated IMDNs. See Section 8.3 for details.
7.2. IM Recipient 7.2. IM Recipient
7.2.1. Constructing IMDNs 7.2.1. Constructing IMDNs
IM recipients examine the contents of the Disposition-Notification IM recipients examine the contents of the Disposition-Notification
header field of the CPIM message to determine if the recipient needs header field of the CPIM message to determine if the recipient needs
to generate an IMDN for that IM. Disposition-Notification header to generate an IMDN for that IM. Disposition-Notification header
fields of CPIM messages can include one or more values. IM fields of CPIM messages can include one or more values. IM
recipients may need to generate zero, one, or more IMDNs for that IM, recipients may need to generate zero, one, or more IMDNs for that IM,
skipping to change at page 16, line 10 skipping to change at page 16, line 10
Original-To header field to the IM populating it with the address Original-To header field to the IM populating it with the address
that was in the CPIM To header field before it was changed. That is, that was in the CPIM To header field before it was changed. That is,
the intermediary populates the Original-To header field with the the intermediary populates the Original-To header field with the
intermediary address. Of course, one may configure an intermediary intermediary address. Of course, one may configure an intermediary
to restrict it from rewriting or populating the Original-To field. to restrict it from rewriting or populating the Original-To field.
An intermediary MUST NOT add an Original-To header field if one An intermediary MUST NOT add an Original-To header field if one
already exists. An intermediary MAY have an administrative already exists. An intermediary MAY have an administrative
configuration to not reveal the original Request-URI, and as such, configuration to not reveal the original Request-URI, and as such,
MUST NOT add an Original-To header. MUST NOT add an Original-To header.
An intermediary MAY choose to remain on the path of IMDNs for a An IM reply for a page-mode IM is not linked in any way to the
specific IM. It can do so by adding a CPIM IMDN-Record-Route header initial IM and can end up at a diffent user agent from where the
field as the top IMDN-Record-Route header field. The value of this initial IM originated, depending on how the recipient URI gets
field MUST be the intermediary's own address. An intermediary that resolved. Therefore, IM replies may traverse different
does not support this extension will obviously not add the IMDN- intermediaries. An IMDN, on the other hand, needs to traverse the
Record-Route header field. This allows IMDNs to traverse directly same intermediares as the IM itself since those intermediares may be
from the IM Recipient to the IM Sender even if the IM traversed an required to report negative delivery notifications if the IM was not
intermediary not supporting this extension. delivered successfully. Some of those interdemiaries are, for
example, store-and-forward servers that may report that an IM has
been processed and later report that the IM has failed to be
delivered.
For the reasons stated above, an intermediary MAY choose to remain on
the path of IMDNs for a specific IM. It can do so by adding a CPIM
IMDN-Record-Route header field as the top IMDN-Record-Route header
field. The value of this field MUST be the intermediary's own
address. An intermediary that does not support this extension will
obviously not add the IMDN-Record-Route header field. This allows
IMDNs to traverse directly from the IM Recipient to the IM Sender
even if the IM traversed an intermediary not supporting this
extension.
An intermediary receiving an IMDN checks the top IMDN-Route header An intermediary receiving an IMDN checks the top IMDN-Route header
field. If that header field carries the intermediary address, the field. If that header field carries the intermediary address, the
intermediary removes that value and forwards the IMDN to the address intermediary removes that value and forwards the IMDN to the address
indicated in the now top IMDN-Route header field. If no additional indicated in the now top IMDN-Route header field. If no additional
IMDN-Route header fields are present, the IMDN is forwarded to the IMDN-Route header fields are present, the IMDN is forwarded to the
address in the CPIM To header field. address in the CPIM To header field.
An intermediary MUST remove any information about the final An intermediary MUST remove any information about the final
recipients of a list if the list membership is not disclosed. The recipients of a list if the list membership is not disclosed. The
skipping to change at page 17, line 31 skipping to change at page 17, line 44
<status> <status>
<processed/> <processed/>
</status> </status>
</processing-notification> </processing-notification>
</imdn> </imdn>
There are situations where the intermediary cannot know the fate of There are situations where the intermediary cannot know the fate of
an IM. The intermediary in this case generates a processing an IM. The intermediary in this case generates a processing
notification with a <status> value of "error" to indicate so. notification with a <status> value of "error" to indicate so.
8.2. Aggregation of IMDNs 8.2. Constructing Delivery Notifications
Intermediaries MAY construct negative delivery notifications. They
do so only if the IM Sender has requested a "negative-delivery"
notification by including a Disposition-Notification header field
with value "negative-delivery" AND an error was returned for that IM.
The intermediary can create and send "negative-delivery"
notifications indicating that an IM has failed to be delivered. The
intermediary MUST NOT send more than one IMDN for the same
disposition type. I.e., it must not send a "failed" notification
indicating that an IM has failed followed by another IMDN indicating
that an IMDN is "forbidden".
An intermediary constructs a "negative-delivery" notification much
like the IM Recipient. See Section 7.2.1.1 for details.
8.3. Aggregation of IMDNs
As previously described, URI-List servers are intermediaries. As previously described, URI-List servers are intermediaries.
A URI-List server may choose to aggregate IMDNs using local policy A URI-List server may choose to aggregate IMDNs using local policy
for making such a decision or it may send individual IMDNs instead. for making such a decision or it may send individual IMDNs instead.
When a URI-List server receives an IM and decides to aggregate IMDNs, When a URI-List server receives an IM and decides to aggregate IMDNs,
it can wait for a configurable period of time or until all recipients it can wait for a configurable period of time or until all recipients
have sent the IMDN, whichever comes first, before the URI-List server have sent the IMDN, whichever comes first, before the URI-List server
sends an aggregated IMDN. Note that some IMDNs, for example sends an aggregated IMDN. Note that some IMDNs, for example
"displayed" notifications, may never come due to user settings. It "displayed" notifications, may never come due to user settings. It
skipping to change at page 21, line 24 skipping to change at page 21, line 24
Message-ID = "Message-ID" ": " Token Message-ID = "Message-ID" ": " Token
Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">" Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">"
IMDN-Record-Route = IMDN-Record-Route =
"IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">" "IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">"
IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">" IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">"
SEMI = SP ";" SP ; semicolon SEMI = *SP ";" *SP ; semicolon
COMMA = SP "," SP ; comma COMMA = *SP "," *SP ; comma
11. IMDN Format 11. IMDN Format
11.1. Structure of XML-Encoded IMDN Payload 11.1. Structure of XML-Encoded IMDN Payload
An IMDN Payload is an XML document [XML] that MUST be well formed and An IMDN Payload is an XML document [XML] that MUST be well formed and
MUST be valid according to schemas, including extension schemas, MUST be valid according to schemas, including extension schemas,
available to the validater and applicable to the XML document. The available to the validater and applicable to the XML document. The
IMDN Payload MUST be based on XML 1.0 and MUST be encoded using IMDN Payload MUST be based on XML 1.0 and MUST be encoded using
UTF-8. UTF-8.
 End of changes. 9 change blocks. 
17 lines changed or deleted 48 lines changed or added

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