draft-ietf-simple-imdn-05.txt   draft-ietf-simple-imdn-06.txt 
SIMPLE E. Burger SIMPLE E. Burger
Internet-Draft BEA Systems, Inc. Internet-Draft BEA Systems, Inc.
Intended status: Standards Track H. Khartabil Intended status: Standards Track H. Khartabil
Expires: June 30, 2008 December 28, 2007 Expires: July 17, 2008 January 14, 2008
Instant Message Disposition Notification Instant Message Disposition Notification
draft-ietf-simple-imdn-05 draft-ietf-simple-imdn-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 30, 2008. This Internet-Draft will expire on July 17, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
Instant Messaging (IM) refers to the transfer of messages between Instant Messaging (IM) refers to the transfer of messages between
users in real-time. This document provides a mechanism whereby users in real-time. This document provides a mechanism whereby
endpoints can request Instant Message Disposition Notifications endpoints can request Instant Message Disposition Notifications
(IMDN), including delivery, processing and read notifications, for (IMDN), including delivery, processing, and read notifications, for
page-mode instant messages. page-mode instant messages.
The Common Profile for Instant Messaging (CPIM) data format specified The Common Profile for Instant Messaging (CPIM) data format specified
in RFC 3862 is extended with new header fields that enable endpoints in RFC 3862 is extended with new header fields that enable endpoints
to request IMDNs. A new message format is also defined to convey to request IMDNs. A new message format is also defined to convey
IMDNs. IMDNs.
This document also describes how SIP entities behave using this This document also describes how SIP entities behave using this
extension. extension.
skipping to change at page 2, line 35 skipping to change at page 2, line 35
6.5. IMDN-Record-Route . . . . . . . . . . . . . . . . . . . . 8 6.5. IMDN-Record-Route . . . . . . . . . . . . . . . . . . . . 8
6.6. IMDN-Route . . . . . . . . . . . . . . . . . . . . . . . . 9 6.6. IMDN-Route . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . . . 9 7. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . . . 9
7.1. IM Sender . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. IM Sender . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1.1. Constructing Instant Messages . . . . . . . . . . . . 9 7.1.1. Constructing Instant Messages . . . . . . . . . . . . 9
7.1.2. Matching IMs with IMDNs . . . . . . . . . . . . . . . 10 7.1.2. Matching IMs with IMDNs . . . . . . . . . . . . . . . 10
7.1.3. Keeping State . . . . . . . . . . . . . . . . . . . . 11 7.1.3. Keeping State . . . . . . . . . . . . . . . . . . . . 11
7.1.4. Aggregation of IMDNs . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 14 8. Intermediary Behaviour . . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . . . . 18 9. Identifying Messages . . . . . . . . . . . . . . . . . . . . . 18
10. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 19 10. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 19
11. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Structure of XML-Encoded IMDN Payload . . . . . . . . . . 19 11.1. Structure of XML-Encoded IMDN Payload . . . . . . . . . . 20
11.1.1. The <message-id> Element . . . . . . . . . . . . . . . 20 11.1.1. The <message-id> Element . . . . . . . . . . . . . . . 20
11.1.2. The <datetime> Element . . . . . . . . . . . . . . . . 20 11.1.2. The <datetime> Element . . . . . . . . . . . . . . . . 20
11.1.3. The <recipient-uri> Element . . . . . . . . . . . . . 20 11.1.3. The <recipient-uri> Element . . . . . . . . . . . . . 20
11.1.4. The <original-recipient-uri> Element . . . . . . . . . 20 11.1.4. The <original-recipient-uri> Element . . . . . . . . . 20
11.1.5. The <subject> Element . . . . . . . . . . . . . . . . 20 11.1.5. The <subject> Element . . . . . . . . . . . . . . . . 21
11.1.6. The <disposition> Element . . . . . . . . . . . . . . 21 11.1.6. The <disposition> Element . . . . . . . . . . . . . . 21
11.1.7. The <status> Element . . . . . . . . . . . . . . . . . 21 11.1.7. The <status> Element . . . . . . . . . . . . . . . . . 21
11.1.8. The <note> Element . . . . . . . . . . . . . . . . . . 21 11.1.8. The <note> Element . . . . . . . . . . . . . . . . . . 21
11.2. MIME Type for IMDN Payload . . . . . . . . . . . . . . . . 21 11.2. MIME Type for IMDN Payload . . . . . . . . . . . . . . . . 21
11.3. The RelaxNG Schema . . . . . . . . . . . . . . . . . . . . 21 11.3. The RelaxNG Schema . . . . . . . . . . . . . . . . . . . . 21
12. Transporting Messages using SIP . . . . . . . . . . . . . . . 25 12. Transporting Messages using SIP . . . . . . . . . . . . . . . 25
12.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 25 12.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 25
12.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 25 12.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 25
12.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 25 12.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 26
12.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 26 12.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 26
12.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 27 12.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 27
13. Transporting Messages using MSRP . . . . . . . . . . . . . . . 28 13. Transporting Messages using MSRP . . . . . . . . . . . . . . . 28
14. Security Considerations . . . . . . . . . . . . . . . . . . . 28 14. Security Considerations . . . . . . . . . . . . . . . . . . . 28
14.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 30 14.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 30
14.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 31 14.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 31
14.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 31 14.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 31
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
15.1. message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 32 15.1. message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 32
15.2. URN Sub-Namespace Registration for 15.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:imdn . . . . . . . . . . . . . . . 32 urn:ietf:params:xml:ns:imdn . . . . . . . . . . . . . . . 33
15.3. Schema Registration . . . . . . . . . . . . . . . . . . . 33 15.3. Schema Registration . . . . . . . . . . . . . . . . . . . 33
15.4. Registration for urn:ietf:params:imdn . . . . . . . . . . 33 15.4. Registration for urn:ietf:params:imdn . . . . . . . . . . 33
15.5. Message/CPIM Header Field Registration . . . . . . . . . . 33 15.5. Message/CPIM Header Field Registration . . . . . . . . . . 34
15.6. Content-Disposition: notification . . . . . . . . . . . . 34 15.6. Content-Disposition: notification . . . . . . . . . . . . 34
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
17.1. Normative References . . . . . . . . . . . . . . . . . . . 34 17.1. Normative References . . . . . . . . . . . . . . . . . . . 34
17.2. Informative References . . . . . . . . . . . . . . . . . . 35 17.2. Informative References . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 37 Intellectual Property and Copyright Statements . . . . . . . . . . 37
1. Introduction 1. Introduction
skipping to change at page 4, line 23 skipping to change at page 4, line 23
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 RFC3798 [11]. MDN is an e-mail that follows the format prescribed by RFC3798 [11].
The fixed format ensures that an automaton can process the message. The fixed format ensures that an automaton can process the message.
Message/CPIM [2] is a message format used to generate instant Message/CPIM [2] is a message format used to generate instant
messages. SIP [8] can carry instant messages generated using messages. SIP [8] can carry instant messages generated using
message/CPIM in SIP MESSAGE requests [9]. message/CPIM in SIP MESSAGE requests [9].
This document extends Message/CPIM message format, much like Message This document extends Message/CPIM message format, much like Message
Delivery Notifications extends Electronic Mail. This extension Delivery Notifications extends Electronic Mail. This extension
enables Instant Message Senders to request, create and send Instant enables Instant Message Senders to request, create, and send Instant
Message Disposition Notifications (IMDN). This mechanism works for Message Disposition Notifications (IMDN). This mechanism works for
page-mode as well as session mode instant messages. This document page-mode as well as session mode instant messages. This document
only discusses page-mode. Session mode is left for future only discusses page-mode. Session mode is left for future
standardisation efforts. standardisation efforts.
IMDNs include positive delivery, negative delivery (i.e. a message IMDNs include positive delivery, negative delivery (i.e. a message
did not get delivered successfully), read notifications as well as did not get delivered successfully), read notifications as well as
processed notifications. By using CPIM header fields, the IMDN processed notifications. By using CPIM header fields, the IMDN
request and delivery are abstracted outside the transport protocol request and delivery are abstracted outside the transport protocol
allowing interoperability between different IM systems. allowing interoperability between different IM systems.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1]. document are to be interpreted as described in RFC 2119 [1].
This document refers generically to the sender of a message in the This document refers generically to the sender of a message in the
masculine (he/him/his) and the recipient of the message in the masculine (he/him/his) and the recipient of the message in the
feminine (she/her/hers). This convention is purely for convenience feminine (she/her/hers). This convention is purely for convenience
and makes no assumption about the gender of a message sender or and makes no assumption about the gender of a message sender or
recipient. recipient.
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
skipping to change at page 6, line 31 skipping to change at page 6, line 31
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 IM, Address of Record (AOR) of the IM Sender, that is present in the IM,
resolves to a different location or user agent than the IM resolves to a different location or user agent than the IM
originated. For simplicity, the rest of this document assumes that originated. For simplicity, the rest of this document assumes that
the IM Sender and the IMDN Recipient are the same and therefore will the IM Sender and the IMDN Recipient are the same and therefore will
refer to both as the IM Sender. refer to both 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 for the IM Sender to receive the o "forbidden" indicate denial for the IM Sender to receive the
requested IMDN. The IM Recipient can send the "forbidden" state, requested IMDN. The IM Recipient can send the "forbidden" state,
but usually it is an intermediary that sends the message if one but usually it is an intermediary that sends the message if one
configures it to do so. For example, it is possible the configures it to do so. For example, it is possible the
administrator has disallowed IMDNs. administrator has disallowed IMDNs.
o "error" to indicate an error in determining the fate of an IM. o "error" to indicate an error in determining the fate of an IM.
5.2. Processing 5.2. Processing
The processing notification type indicates that an IM has been The processing notification type indicates that an intermediary has
processed by an intermediary. The processing notification type can processed an IM. The processing notification type can have the
have the following states: following states:
o "processed" is a general state of the IM indicating that the o "processed" is a general state of the IM indicating that the
intermediary has performed its task on the IM. intermediary has performed its task on the IM.
o "stored" state indicates that the IM has been stored by the o "stored" state indicates that the intermediary stored the IM for
intermediary for later delivery. later delivery.
o "forbidden" indicate denial for the IM Sender to receive the o "forbidden" indicate denial for the IM Sender to receive the
requested IMDN. The "forbidden" state is sent by an intermediary requested IMDN. The "forbidden" state is sent by an intermediary
that is configured to do so. For example, the administrator has that is configured to do so. For example, the administrator has
disallowed IMDNs. disallowed IMDNs.
o "error" to indicate an error in determining the fate of an IM. o "error" to indicate an error in determining the fate of an IM.
5.3. Read 5.3. Read
The read notification type indicates whether the IM Recipient The read notification type indicates whether the IM Recipient
rendered the IM to the user or not. The read notification type can rendered the IM to the user or not. The read notification type can
have the following states: have the following states:
o "read" is a state indicating that the IM has been rendered to the o "read" is a state indicating that the IM has been rendered to the
user. user.
o "forbidden" indicate denial, by the IM Recipient, for the IM o "forbidden" indicate denial, by the IM Recipient, for the IM
Sender to receive the requested IMDN. Sender to receive the requested IMDN.
o "error" to indicate an error in determining the fate of an IM. o "error" to indicate an error in determining the fate of an IM.
In addition to text, some IMs may contain audio, video and still In addition to text, some IMs may contain audio, video, and still
images. Therefore, the state "read" includes playing the audio or images. Therefore, the state "read" includes playing the audio or
video file to the user. video file to the user.
Since there is no positive acknowledgement from the user, one cannot Since there is no positive acknowledgement from the user, one cannot
determine a priori the user actually read the IM. Thus, one cannot determine a priori the user actually read the IM. Thus, one cannot
use the protocol described here as a non-repudiation service. 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
skipping to change at page 12, line 43 skipping to change at page 12, line 44
A Disposition-Notification header field MUST NOT appear in an IMDN A Disposition-Notification header field MUST NOT appear in an IMDN
since it is forbidden to request an IMDN for an IMDN. An IM Sender since it is forbidden to request an IMDN for an IMDN. An IM Sender
MUST ignore a delivery notification request in an IMDN if present. MUST ignore a delivery notification request in an IMDN if present.
The IM Sender MUST NOT send an IMDN for an IMDN. The IM Sender MUST NOT send an IMDN for an IMDN.
An IMDN MUST contain a Message-ID header field. The same rules of An IMDN MUST contain a Message-ID header field. The same rules of
uniqueness for the Message-ID header field that appears in an IM uniqueness for the Message-ID header field that appears in an IM
apply to an IMDN. The Message-ID header field in the IMDN is apply to an IMDN. The Message-ID header field in the IMDN is
different and unrelated to the one in the IM. different and unrelated to the one in the IM.
An IM may contain a IMDN-Record-Route header field (see Section 8 for An IM may contain an IMDN-Record-Route header field (see Section 8
details). If IMDN-Record-Route header fields appear in the IM, the for details). If IMDN-Record-Route header fields appear in the IM,
IM Recipient constructing the IMDN MUST copy the contents of the the IM Recipient constructing the IMDN MUST copy the contents of the
IMDN-Record-Route header fields into IMDN-Route header fields in the IMDN-Record-Route header fields into IMDN-Route header fields in the
IMDN and maintain the order. The IMDN is then sent to the URI in the IMDN and maintain the order. The IMDN is then sent to the URI in the
top IMDN-Route header field. IMDN-Record-Route header fields do not top IMDN-Route header field. IMDN-Record-Route header fields do not
make sense in an IMDN and therefore MUST NOT be placed in an IMDN. make sense in an IMDN and therefore MUST NOT be placed in an IMDN.
IMDN Recipients MUST ignore it if present. IMDN Recipients MUST ignore it if present.
As stated in CPIM [2], CPIM messages may need to support MIME headers As stated in CPIM [2], CPIM messages may need to support MIME headers
other than Content-type. IM Recipients MUST insert a Content- other than Content-type. IM Recipients MUST insert a Content-
Disposition header field, set to the value "notification". This Disposition header field, set to the value "notification". This
indicates to the IM Sender that the message is an IMDN to an IM it indicates to the IM Sender that the message is an IMDN to an IM it
skipping to change at page 14, line 45 skipping to change at page 15, line 9
to ignore any IMDN requests and not to send any IMDNs. An IM to ignore any IMDN requests and not to send any IMDNs. An IM
recipient may not wish to let a sender know she read, or did not recipient may not wish to let a sender know she read, or did not
read, a particular message. Likewise, she may not want anyone to read, a particular message. Likewise, she may not want anyone to
know if she reads messages. This could be on a per-message, per- know if she reads messages. This could be on a per-message, per-
sender, or programmed policy choice. sender, or programmed policy choice.
8. Intermediary Behaviour 8. Intermediary Behaviour
In this context, intermediaries are application servers (including In this context, intermediaries are application servers (including
URI-List servers and Store-and-Forward server) and gateways. A URI-List servers and Store-and-Forward server) and gateways. A
gateway is a server the translates between different IM systems that gateway is a server that translates between different IM systems that
use different protocols. use different protocols.
A URI-List server may change the IM Recipient address from its own to A URI-List server may change the IM Recipient address from its own to
the address of the final recipient of that IM for every copy it makes the address of the final recipient of that IM for every copy it makes
that it sends to the list members (see [13] for details). In this that it sends to the list members (see [13] for details). In this
case, if the IM Sender is requesting an IMDN, the intermediary SHOULD case, if the IM Sender is requesting an IMDN, the intermediary SHOULD
add an Original-To header field to the IM populating it with the add an Original-To header field to the IM populating it with the
address that was in the CPIM To header field before it was changed. address that was in the CPIM To header field before it was changed.
I.e., the Original-To header field is populated with the intermediary I.e., the Original-To header field is populated with the intermediary
address. An intermediary MUST NOT add an Original-To header field if address. An intermediary MUST NOT add an Original-To header field if
skipping to change at page 19, line 7 skipping to change at page 19, line 20
contents. The message is a delivery notification if the Content-type contents. The message is a delivery notification if the Content-type
header field present has a value of "message/imdn+xml", the Content- header field present has a value of "message/imdn+xml", the Content-
Disposition header field has a value of "notification", and the Disposition header field has a value of "notification", and the
<disposition> element in that xml body has a sub-element <delivery>. <disposition> element in that xml body has a sub-element <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.
Note a message of type multipart/mixed can be a notification if it
includes a part of type message/imdn+xml.
10. Header Fields Formal Syntax 10. Header Fields Formal Syntax
The following syntax specification uses the message header field The following syntax specification uses the message header field
syntax as described in Section 3 of RFC3862 [2]. syntax as described in Section 3 of RFC3862 [2].
Header field syntax is described without a namespace qualification. Header field syntax is described without a namespace qualification.
Following the rules in RFC3862 [2], header field names and other text Following the rules in RFC 3862 [2], header field names and other
are case sensitive and MUST be used as given, using exactly the text are case sensitive and MUST be used as given, using exactly the
indicated upper case and lower case letters. indicated upper case and lower case letters.
Disposition-Notification = Disposition-Notification =
"Disposition-Notification" ": " "Disposition-Notification" ": "
[(notify-req *(COMMA notify-req))] [(notify-req *(COMMA notify-req))]
notify-req = notify-req =
("negative-delivery" / "positive-delivery" / ("negative-delivery" / "positive-delivery" /
"processing" / "read" / Token) *(SEMI disp-notif-params) "processing" / "read" / Token) *(SEMI disp-notif-params)
disp-notify-params = generic-param disp-notify-params = generic-param
skipping to change at page 19, line 42 skipping to change at page 20, line 9
IMDN-Record-Route = IMDN-Record-Route =
"IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">" "IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">"
IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">" IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">"
11. IMDN Format 11. IMDN Format
11.1. Structure of XML-Encoded IMDN Payload 11.1. Structure of XML-Encoded IMDN Payload
An IMDN Payload is an XML document [6] that MUST be well-formed and An IMDN Payload is an XML document [6] that MUST be well formed and
MUST be valid according to schemas, including extension schemas, MUST be valid according to schemas, including extension schemas,
available to the validater and applicable to the XML document. The available to the validater and applicable to the XML document. The
IMDN Payload MUST be based on XML 1.0 and MUST be encoded using IMDN Payload MUST be based on XML 1.0 and MUST be encoded using
UTF-8. UTF-8.
The namespace identifier for elements defined by this specification The namespace identifier for elements defined by this specification
is a URN [4], using the namespace identifier 'ietf' defined by [12] is a URN [4], using the namespace identifier 'ietf' defined by [12]
and extended by [3]. This urn is: urn:ietf:params:xml:ns:imdn. and extended by [3]. This urn is: urn:ietf:params:xml:ns:imdn.
This namespace declaration indicates the namespace on which the IMDN This namespace declaration indicates the namespace on which the IMDN
skipping to change at page 25, line 35 skipping to change at page 25, line 44
The Content-type header field indicates the MIME type of the request The 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
IM Sender constructs the payload according to Section 7. IM Sender constructs the payload according to Section 7.
The IM Sender constructs a SIP MESSAGE request to multiple recipients The IM Sender constructs a SIP MESSAGE request to multiple recipients
in a similar manner as a SIP MESSAGE request to a single recipient. in a similar manner as a SIP MESSAGE request to a single recipient.
Multiple-Recipient MESSAGE Requests in SIP [13] describes the Multiple-Recipient MESSAGE Requests in SIP [13] describes the
differences. differences.
Due to the fact that IM senders can remain anonymous, e.g., by IM senders can remain anonymous. For example, the sender can set the
setting the SIP From header field of the SIP message to an anonymous SIP From header field of the SIP message to an anonymous URI. As
URI, anonymous IM senders are cannot request disposition there is no return address, anonymous IM senders SHOULD NOT request
notifications. Therefore, anonymous IM senders SHOULD NOT request
disposition notifications. An IM Recipient can ignore such request disposition notifications. An IM Recipient can ignore such request
if the IM Sender is anonymous. if the IM Sender is anonymous.
12.1.2. Sending Responses 12.1.2. Sending Responses
An endpoint receiving a SIP MESSAGE request constructs a SIP response An endpoint receiving a SIP MESSAGE request constructs a SIP response
according to RFC3428 [9]. Of course, an endpoint will send a according to RFC3428 [9]. Of course, an endpoint will send a
response to the MESSAGE request regardless of the type of message (IM response to the MESSAGE request regardless of the type of message (IM
or IMDN) is has received, or the disposition type it has been asked or IMDN) is has received, or the disposition type it has been asked
for. for.
skipping to change at page 27, line 25 skipping to change at page 27, line 31
12.2. Intermediary Behaviour 12.2. Intermediary Behaviour
In this context, intermediaries include application servers, In this context, intermediaries include application servers,
including URI-List servers, store-and-forward servers, and gateways. including URI-List servers, store-and-forward servers, and gateways.
SIP Proxies MUST NOT generate IMDNs but MUST forward them like any SIP Proxies MUST NOT generate IMDNs but MUST forward them like any
other SIP request. other SIP request.
Intermediaries forward a SIP MESSAGE request to multiple recipients Intermediaries forward a SIP MESSAGE request to multiple recipients
according to [13]. according to [13].
If an intermediary receives a SIP 2xx class response to a SIP MESSAGE If an intermediary receives an IM, the intermediary examines the
request that is an IM, it examines if the body is of type "message/ body. If the body is of type "message/cpim" the intermediary then
cpim". If so, it checks the CPIM header to see if there is the looks for a Disposition-Notification CPIM header field in the
header field Disposition-Notification with a value "positive- message. If the Disposition-Notification CPIM header field has
delivery" and/or "negative-delivery". If so, it MUST send a delivery either the value "positive-delivery" or "negative-delivery", and, in
notification after receiving a transactional final response for the processing the IM, the intermediary generates a SIP 2xx class
IM. response to the MESSAGE request, then the intermediary performs the
following actions.
If the Disposition-Notification header field contains a value of If the Disposition-Notification header field contains a value of
"positive-delivery", the intermediary MUST NOT generate a delivery "positive-delivery", the intermediary MUST NOT generate a delivery
notification if it receives a SIP 2xx class response for the sent IM. notification if it receives a SIP 2xx class response for the sent IM.
This is in anticipation of a failure downstream after a 2xx response This is in anticipation of a failure downstream after a 2xx response
has been generated. has been generated.
If the Disposition-Notification header field contains a value of If the Disposition-Notification header field contains a value of
"negative-delivery", the intermediary SHOULD generate a delivery "negative-delivery", the intermediary SHOULD generate a delivery
notification if it receives a SIP 4xx, 5xx or 6xx class final notification if it receives a SIP 4xx, 5xx or 6xx class final
skipping to change at page 29, line 4 skipping to change at page 29, line 11
Since the IM transport protocol carries the IMDN, all security Since the IM transport protocol carries the IMDN, 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
to IM include the following: to IM include the following:
o A malicious endpoint attempts to send messages to a user that o A malicious endpoint attempts to send messages to a user that
would normally not wish to receive messages from that endpoint by would normally not wish to receive messages from that endpoint by
convincing the IMDN system to "bounce" an IMDN from an convincing the IMDN system to "bounce" an IMDN from an
unsuspecting endpoint to the user. unsuspecting endpoint to the user.
o A malicious endpoint attempts to flood an IM Sender with IMDNs by
o A malicious endpoint attempts to flood a IM Sender with IMDNs by
convincing a URI-List server to send IMDNs to an unsuspecting IM convincing a URI-List server to send IMDNs to an unsuspecting IM
Sender. Sender.
o A malicious node in the network that attempts to modify an IMDN o A malicious node in the network that attempts to modify an IMDN
from a IM Recipient. from an IM Recipient.
o A malicious intermediary attempts to forward an IMDN from an IM o A malicious intermediary attempts to forward an IMDN from an IM
Recipient to the IM Sender, where the IM Recipient would not Recipient to the IM Sender, where the IM Recipient would not
normally forward the IMDN to that IM Sender if the IM Recipient normally forward the IMDN to that IM Sender if the IM Recipient
knew the identity of the IM Sender. knew the identity of the IM Sender.
o A malicious endpoint that attempts to fish for a Request-URI of an o A malicious endpoint that attempts to fish for a Request-URI of an
endpoint beyond an intermediary , where the endpoint would endpoint beyond an intermediary, where the endpoint would normally
normally wish to keep its identity private from the malicious wish to keep its identity private from the malicious endpoint.
endpoint.
o A malicious node in the network that attempts to eavesdrop on IMDN o A malicious node in the network that attempts to eavesdrop on IMDN
traffic to, for example, learn Request-URI or traffic pattern traffic to, for example, learn Request-URI or traffic pattern
information. information.
o A malicious node in the network attempts to stage a denial of o A malicious node in the network attempts to stage a denial of
service attack on an intermediary by requesting a large list service attack on an intermediary by requesting a large list
expansion. expansion.
The protocol cannot protect against attacks that include the The protocol cannot protect against attacks that include the
following: following:
o A malicious intermediary directly revealing the identity of a o A malicious intermediary directly revealing the identity of a
skipping to change at page 29, line 39 skipping to change at page 29, line 44
revealed. Keeping such information private is an intermediary revealed. Keeping such information private is an intermediary
implementation issue. implementation issue.
o A malicious IM Recipient that alters the time of the IMDN. There o A malicious IM Recipient that alters the time of the IMDN. There
is no protocol mechanism for ensuring that the IM Recipient does is no protocol mechanism for ensuring that the IM Recipient does
not lie about the time or purposely holds an IMDN for transmission not lie about the time or purposely holds an IMDN for transmission
to make it appear that the user read an IM later than they to make it appear that the user read an IM later than they
actually did. actually did.
o A deletion attack on an IMDN. This is a trade-off between privacy o A deletion attack on an IMDN. This is a trade-off between privacy
and security. The privacy considerations allow the IM Recipient and security. The privacy considerations allow the IM Recipient
to silently ignore an IMDN request. Any mechanism that would to silently ignore an IMDN request. Any mechanism that would
reliably indicate that a malicious node deleted a IM Recipient's reliably indicate that a malicious node deleted an IM Recipient's
IMDN would also serve the purpose of detecting a IM Recipient that IMDN would also serve the purpose of detecting an IM Recipient
chose not to issue an IMDN. that chose not to issue an IMDN.
To combat eavesdropping, modification, and man-in-the-middle attacks, To combat eavesdropping, modification, and man-in-the-middle attacks,
we require some level of authentication and integrity protections. we require some level of authentication and integrity protections.
That said, there are circumstances where strong integrity would be That said, there are circumstances where strong integrity would be
overkill. The presumption is the IM Sender has and sets the overkill. The presumption is the IM Sender has and sets the
expectation for the level of protection. The procedures for expectation for the level of protection. The procedures for
integrity protection are as follows. integrity protection are as follows.
o If the IM Recipient has a certificate, it MUST sign the IMDN. o If the IM Recipient has a certificate, it MUST sign the IMDN.
Signing the IMDN provides integrity protection. While an Signing the IMDN provides integrity protection. While an
intermediary can replace the IMDN body, the IM Sender (the intermediary can replace the IMDN body, the IM Sender (the
skipping to change at page 30, line 17 skipping to change at page 30, line 22
something bad might have happened. something bad might have happened.
o If the IM is encrypted, the IM Recipient or intermediary MUST o If the IM is encrypted, the IM Recipient or intermediary MUST
encrypt the IMDN body, as an attacker may attempt to discern the encrypt the IMDN body, as an attacker may attempt to discern the
user's activity profile and identity from sniffing IMDNs on the user's activity profile and identity from sniffing IMDNs on the
network. network.
o The two above rules are cumulative. o The two above rules are cumulative.
The IM Recipient or intermediary MUST be capable of accessing the IM The IM Recipient or intermediary MUST be capable of accessing the IM
Sender's public certificate in order to verify the signature in the Sender's public certificate in order to verify the signature in the
IM. IM.
CPIM security considerations [2] apply here as this is an extension CPIM security considerations [2] apply here, as this is an extension
of CPIM. In order to make the IMDN mechanism independent of the of CPIM. In order to make the IMDN mechanism independent of the
transport protocol, the Work Group made the design choice of putting transport protocol, the Work Group made the design choice of putting
routing information into the IMDN application layer payload. One routing information into the IMDN application layer payload. One
consequence of this choice is it eliminates the possibility of having consequence of this choice is it eliminates the possibility of having
end-to-end encryption. end-to-end encryption.
An attacker can mount a distributed denial of service attack on a An attacker can mount a distributed denial of service attack on a
node by sending lots of IMs to the node with IMDN requests. Note node by sending lots of IMs to the node with IMDN requests. Note
that this is the same problem as there is without IMDN; IMDN simply that this is the same problem as there is without IMDN; IMDN simply
linearly increases the load on the node under attack. One can linearly increases the load on the node under attack. One can
skipping to change at page 30, line 50 skipping to change at page 31, line 7
part of it that is included in the signature (like adding an part of it that is included in the signature (like adding an
Original-To header field to the CPIM header fields), MUST consume the Original-To header field to the CPIM header fields), MUST consume the
IM and create a new copy of it that the intermediary signs itself. IM and create a new copy of it that the intermediary signs itself.
IMDNs may be forged as easily as ordinary IMs. Endpoints and IMDNs may be forged as easily as ordinary IMs. Endpoints and
intermediaries that wish to make automatic use of IMDNs should take intermediaries that wish to make automatic use of IMDNs should take
appropriate precautions to minimize the potential damage from denial- appropriate precautions to minimize the potential damage from denial-
of-service attacks. Security threats related to forged IMDNs include of-service attacks. Security threats related to forged IMDNs include
the sending of a falsified IMDN when the indicated disposition of the the sending of a falsified IMDN when the indicated disposition of the
IM has not actually occurred. For example, read notification could IM has not actually occurred. For example, read notification could
be forged to indicate that a IM Recipient has read the IM. be forged to indicate that an 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
skipping to change at page 31, line 39 skipping to change at page 31, line 44
the URI-list server MAY reject the IM. the URI-list server MAY reject the IM.
It is possible for a list server to not understand IMDN. IM It is possible for a list server to not understand IMDN. IM
Recipients may note the To is a list name and not the IM Recipient's Recipients may note the To is a list name and not the IM Recipient's
name. In this case, the IM Recipient can take the appropriate action name. In this case, the IM Recipient can take the appropriate action
if it wishes to keep its identity private. if it wishes to keep its identity private.
An unencrypted IMDN could reveal confidential information about an An unencrypted IMDN could reveal confidential information about an
encrypted IM. The same level of security applied to an IM MUST be encrypted IM. The same level of security applied to an IM MUST be
applied to its IMDNs. For example, if an IM is signed and encrypted, applied to its IMDNs. For example, if an IM is signed and encrypted,
and IMDN must also be signed and encrypted. the IMDN must 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. Moreover, the IM Recipient may bypass the IMDN
manner by the IM Recipient. issuing mechanism through policy or manipulation of their User Agent
Server.
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 [5]. This specification follows the guidelines of RFC3023 [5].
skipping to change at page 33, line 38 skipping to change at page 33, line 43
Required). Required).
Repository: http://www.iana.org/assignments/imdn Repository: http://www.iana.org/assignments/imdn
Index value: The index value is a CPIM message IMDN header name, Index value: The index value is a CPIM message IMDN header name,
which may consist of a sequence from a restricted set of US-ASCII which may consist of a sequence from a restricted set of US-ASCII
characters, as defined above. characters, as defined above.
URN Formation: The URI for a header is formed from its name by: URN Formation: The URI for a header is formed from its name by:
a) replacing any non-URN characters (as defined by RFC 2141[4]) a) replacing any non-URN characters (as defined by RFC 2141[4])
with the corresponding '%hh' escape sequence (per RFC 2396 [7]); with the corresponding '%hh' escape sequence (per RFC 3986 [7]);
and and
b) prepending the resulting string with 'urn:ietf:params:imdn:'. b) prepending the resulting string with 'urn:ietf:params:imdn:'.
Thus, the URI corresponding to the CPIM message IMDN header Thus, the URI corresponding to the CPIM message IMDN header
'Disposition-Notification:' would be 'Disposition-Notification:' would be
'urn:ietf:params:imdn:Disposition-Notification'. 'urn:ietf:params:imdn:Disposition-Notification'.
15.5. Message/CPIM Header Field Registration 15.5. Message/CPIM Header Field Registration
This document registers the following message/cpim header fields in This document registers the following message/cpim header fields in
skipping to change at page 36, line 4 skipping to change at page 36, line 16
Eric Burger Eric Burger
BEA Systems, Inc. BEA Systems, Inc.
4 Van de Graaff Dr. 4 Van de Graaff Dr.
Burlington, MA 01803 Burlington, MA 01803
USA USA
Phone: +1 781 993 7437 Phone: +1 781 993 7437
Fax: +1 603 457 5933 Fax: +1 603 457 5933
Email: eric.burger@bea.com Email: eric.burger@bea.com
Hisham Khartabil Hisham Khartabil
Melbourne Melbourne
Australia Australia
Phone: +61 416 108 890 Phone: +61 416 108 890
Email: hisham.khartabil@gmail.com Email: hisham.khartabil@gmail.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 37 change blocks. 
59 lines changed or deleted 57 lines changed or added

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