One document matched: draft-burger-simple-imdn-02.txt
Differences from draft-burger-simple-imdn-01.txt
SIMPLE E. Burger
Internet-Draft Brooktrout Technology, Inc.
Expires: April 26, 2006 H. Khartabil
Telio
October 23, 2005
Instant Message Delivery Notification (IMDN) for Common Presence and
Instant Messaging (CPIM) Messages
draft-burger-simple-imdn-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a mechanism for instant message delivery
notification (IMDN) in the CPIM (Common Presence and Instant
Messaging) environment. The mechanism follows the procedures of
ESMTP message delivery notification (MDN).
Burger & Khartabil Expires April 26, 2006 [Page 1]
Internet-Draft IMDN October 2005
Table of Contents
1. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 4
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 6
5. State Sharing . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Data Elements . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Disposition States . . . . . . . . . . . . . . . . . . . . 9
6.3. B2BUAs . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Requesting UAC Behavior . . . . . . . . . . . . . . . . . . . 12
8.1. IMDN Request Generation . . . . . . . . . . . . . . . . . 12
8.1.1. Disposition-Notification-To . . . . . . . . . . . . . 12
8.1.2. List-Action . . . . . . . . . . . . . . . . . . . . . 14
8.1.3. Original-From . . . . . . . . . . . . . . . . . . . . 14
8.1.4. Message-ID . . . . . . . . . . . . . . . . . . . . . . 15
8.1.5. Original-Message-ID . . . . . . . . . . . . . . . . . 15
8.2. IMDN Reception Processing . . . . . . . . . . . . . . . . 15
9. Reporting UAS Operation . . . . . . . . . . . . . . . . . . . 16
9.1. General Operation . . . . . . . . . . . . . . . . . . . . 16
9.2. Recipient is the End User UAS . . . . . . . . . . . . . . 16
9.3. Recipient is a B2BUA . . . . . . . . . . . . . . . . . . . 17
9.3.1. No List-Action or first-recipient . . . . . . . . . . 17
9.3.2. final-recipient . . . . . . . . . . . . . . . . . . . 18
10. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 18
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Simple End-to-End Read Request . . . . . . . . . . . . . . 19
11.2. Gateway Endpoint . . . . . . . . . . . . . . . . . . . . . 20
11.3. List Exploder - Forward . . . . . . . . . . . . . . . . . 20
11.4. List Exploder - Consolidate . . . . . . . . . . . . . . . 21
11.5. List With Lists . . . . . . . . . . . . . . . . . . . . . 21
11.6. End-to-End Encryption Forwarded . . . . . . . . . . . . . 21
12. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. IMDN CPIM Request . . . . . . . . . . . . . . . . . . . . 21
12.2. IMDN Document . . . . . . . . . . . . . . . . . . . . . . 21
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
14.1. Normative References . . . . . . . . . . . . . . . . . . . 21
14.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 22
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Burger & Khartabil Expires April 26, 2006 [Page 2]
Internet-Draft IMDN October 2005
1. Document Conventions
This document refers generically to the sender of a 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
and makes no assumption about the gender of a message sender or
recipient.
In this document, the term "CPIM header" refers to the message
metadata headers encapsulated in a Message/CPIM object [1].
The term "IM" refers to Instant Message.
The term "Requesting UAC" is the User Agent Client that sends the
message the user would like a disposition notification for.
The term "Reporting UAS" is the User Agent Server that sends the
disposition notification back to the Requesting UAC.
The term "B2BUA" refers to a Back-to-Back User Agent. IM B2BUA's
implement gateways and list exploders, amongst other functions.
If you missed it in the title, the term "IMDN" is an Instant Message
Delivery Notification. The IMDN indicates the disposition of the
message after the message is available to the recipient.
NOTE: Text like this, offset from the margin and starting with the
word "NOTE:", is not normative and present only for discussion or
explanation purposes.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [2].
This document uses the augmented Backus-Naur Form (BNF) as described
in RFC2234 [3] for all syntax specification uses, other than XML.
Examples and discussion of CPIM headers, for clarity, do not include
the leading name space identifer.
2. Introduction
In many user-to-user message exchange systems, message senders often
wish to know if the human recipient actually read a message. Most
messaging protocols, including CPIM sessions [4], ensure reliable
delivery of a message to the recipient. However, they cannot report
when a human user actually reads the message.
Burger & Khartabil Expires April 26, 2006 [Page 3]
Internet-Draft IMDN October 2005
Electronic Mail [11] deals with this situation with message delivery
notifications [5]. After the recipient views the message, her mail
user agent generates a message delivery notification, or MDN. The
MDN is an e-mail that follows the format prescribed by RFC2298 [5].
The fixed format ensures that an automaton can process the message.
Even though a MDN is a normal e-mail message, a MDN cannot request a
receipt, in order to prevent notification loops.
The mechanism by which an instant message user agent determines its
user has read a message is beyond the scope of this document.
However, there are many problems that are important to consider. An
appendix to this document enumerates a number of these issues.
The mechanism described here uses a CPIM header to indicate an IMDN
request. By using a CPIM header, we abstract the request outside the
transport protocol. This enhances interoperability between different
IM systems because the request is at the message level, not transport
level. Likewise, the mechanism does not rely on session-mode versus
pager-mode or SIP transport or any particular SIP or other response
codes.
Since the security and privacy considerations have a tremendous
influence on a number of design decisions that may at first seem
counter-intuitive, the Privacy Considerations (Section 4) and
Security Considerations (Section 3) sections appear in the front of
this document.
The basic protocol flow is as follows. A message sender marks a
message for disposition notification. At a certain point in time,
the recipient's instant message user agent determines the recipient
has read the message, deleted the message, or otherwise disposed the
message. At that point, the recipient's instant message user agent
automatically generates a notification message to the sender. This
notification message is the Instant Message Disposition Notification
(IMDN).
Note there are numerous circumstances under which the instant message
user agent may not send a notification. The following sections
describe some of these situations.
3. Security Considerations
All of the security issues raised in RFC2298 [5] apply here. For
review, they are forgery and denial of service attacks,
confidentiality, and non-repudiation. Note that signing CPIM
messages helps in this respect.
Burger & Khartabil Expires April 26, 2006 [Page 4]
Internet-Draft IMDN October 2005
The threats in the IMDN system, over and beyond the threats inherent
to CPIM [4] include the following:
o A malicious endpoint attempts to send messages to a user that
would normally not wish to receive messages from that endpoint by
convincing the IMDN system to "bounce" an IMDN from an
unsuspecting endpoint to the user.
o A malicious endpoint attempts to flood a user with IMDNs by
convincing a B2BUA list exploder to send IMDN responses to an
unsuspecting user.
o A malicious node in the network that attempts to modify an IMDN
from a Reporting UAS.
o A malicious B2BUA attempts to forward an IMDN from a Reporting UAS
to the Recipient UAC, where the Reporting UAS would not normally
forward the IMDN to that Recipient UAC if the identity of the
Reporting UAS knew the identity of the Recipient UAC.
o A malicious endpoint that attempts to fish for a Request-URI of a
UAS beyond a B2BUA, where the UAS would normally wish to keep its
identity private from the malicious endpoint.
o A malicious node in the network that attempts to eavesdrop on IMDN
traffic to, for example, learn Request-URI or traffic pattern
information.
o A malicious node in the network attempts to stage a denial of
service attack on a B2BUA by requesting a large list expansion
with a request for consolidated for IMDN processing.
Attacks the protocol cannot protect against include the following:
o A malicious B2BUA directly revealing the identity of a downstream
UAS that would not normally wish its identity revealed to such a
UAS. Keeping such information private is a B2BUA implementation
issue.
o A malicious Reporting UAS that alters the time of the report.
There is no protocol mechanism for ensuring the UAS does not lie
about the time or purposely holds an IMDN for transmission to make
it appear the user disposed of a message later than they actually
did.
o A deletion attack on an IMDN. This is a trade-off between privacy
and security. The privacy considerations allow the Reporting UAS
to silently ignore an IMDN request. Any mechanism that would
reliably indicate that a malicious node deleted a Reporting UAS'
message would also serve the purpose of detecting a Reporting UAS
that chose not to issue an IMDN.
To combat eavesdropping, modification, and man-in-the-middle attacks,
one MUST encrypt the IMDN body, as an attacker may attempt to discern
the user's activity profile and identity from sniffing IMDNs on the
network.
Replay and message insertion attacks are unlikely in an IMDN
Burger & Khartabil Expires April 26, 2006 [Page 5]
Internet-Draft IMDN October 2005
environment, as the Message-ID cannot be identical within a given
session, and the Requesting UAC has the ability to maintain the state
of Message-ID's sent for later correlation. Moreover, the instant
message itself MUST have the Message-ID sent securely to remove the
possibility of an eavesdropper learning the Message-ID.
Probably the greatest network threat is a denial of service attack.
An attacker may setup a denial of service attack to an unsuspecting
endpoint by sending lots of messages to many instant message user
agents, requesting those user agents to send their IMDNs to the
attacked node. This is why one SHOULD NOT send IMDNs to a user other
than the one that sent the message. Moreover, the Reporting UAS MUST
authenticate the node that made the IMDN request (either the
Requesting UAC or a B2BUA) to enable reliable tracing of attacks. In
addition, this holds true for B2BUA's the forward requests. Namely,
the B2BUA MUST authenticate the UAC making the request, as well as
provide authentication to the UAS. It is important to note the text
mentions UAC and UAS, as one can have cascading B2BUAs.
To combat surreptitious delivery of messages by embedding them in
IMDN's, as is done today by spammers using MDN's, an IMDN MUST NOT
include a copy of the original message.
An attacker can mount a distributed denial of service attack on a
node by sending lots of messages to the node with IMDN requests.
Note that this is the same problem as there is without IMDN; IMDN
simply linearly increases the load on the node under attack. One can
mitigate, but not eliminate this threat by the UAS immediately
ignoring requests that are not authenticated.
Likewise, an attacker can mount a denial of service attack on a B2BUA
by asking the B2BUA to explode a large list and to direct the B2BUA
to consolidate the IMDN's from the targets of the list.
4. Privacy Considerations
As suggested by RFC2298 [5], it is strongly RECOMMENDED that the user
agent obtain the user's consent before sending an IMDN.
Circumstances where the user agend does not ask for the user's
consent include instant messaging systems that, for regulatory
reasons, are required to issue an IMDN, such as in the healthcare
field.
A user agent can obtain such consent by a prompt or dialog box on a
per-message basis, globally through the user's setting of a
preference, or other, user-configurable mechanism. The user might
also indicate globally that IMDNs are never to be sent or that a
Burger & Khartabil Expires April 26, 2006 [Page 6]
Internet-Draft IMDN October 2005
"denied" IMDN is always sent in response to a request for an IMDN.
A user sending a message through a B2BUA may not wish to have their
address revealed, yet still wish to receive IMDNs. In this case the
Requesting UAC indicates to the B2BUA to keep the Requesting UAC's
address private. In this case, the B2BUA MUST remove all references
to the Requesting UAC and, as well, MUST indicate to the Reporting
UAS that the Requesting UAC's address is private. THIS IS WHY
B2BUA'S MUST RELAY RESPONSES.
Recipient systems SHOULD NOT automatically send IMDNs if the URI in
the Disposition-Notification-To header differs from the address of
the sender. Recipient systems MUST use reliable mechanisms for
authenticating the sender, such as from the underlying transport
protocol. Recipient systems MUST NOT rely on unsigned information in
the CPIM message, such as the From header.
Recipient systems SHOULD obtain confirmation from the user, or not
send an IMDN, if it cannot reliably determine the sender's address.
The reason for not automatically sending an IMDN is to reduce the
possibility of IMDN bombing a third party.
On a related note, the protocol MUST enable the recipient of the IM
to keep the message disposition private. That is, only the sender is
able to read the IMDN body text. Thus either the transmission of the
IMDN MUST be end-to-end encrypted or the body of the IMDN MUST be
encrypted with, for example, S/MIME [6].
5. State Sharing
One of the design questions for the IMDN design is where to store
message state. This becomes a question when we introduce B2BUA's.
If there were no B2BUA's, then the Reporting UAS simply sends the
IMDN directly to the sender, and the sender retains the state of
messages sent that are awaiting IMDN's. However, since we have
B2BUA's, we have a choice. One option is for the Requesting UAC to
record the state of messages sent and have stateless B2BUA's.
Another option is for intermediary B2BUAs to record the state of
messages sent, and simply always forwarding IMDN's back to the
immediately preceding message requestor.
The trade-offs are as follows:
o End-to-End State Sharing
* Pro: The actual recipient sends the IMDN directly to the actual
sender. It is quite likely the path may be different. For
example, while the request may traverse a list exploder
Burger & Khartabil Expires April 26, 2006 [Page 7]
Internet-Draft IMDN October 2005
(B2BUA), the IMDN's will go directly to the sender.
* Pro: With the Reporting UAS sending the report directly to the
Requesting UAC, it is possible to keep the disposition private
with respect to intermediaries.
* Pro: Only the endpoints share state. Network failures do not
impact IMDN delivery. Users should know when their user agent
fails and can act accordingly.
* Pro: No matter what, the Requesting UAC should store state for
messages is sends and has an interest in correlating IMDN's.
There is no additional burden to the network or user agent.
* Pro: The Reporting UAS knows the direct recipient of the IMDN,
so it can use more sophisticated algorithms to decide if or
what kind of IMDN to generate. Of course, a B2BUA can always
hide the true recipient of an IMDN by requesting the report on
its own behalf, as it is a full UAC. However, the Reporting
UAS can chose not to release information to untrusted B2BUA's.
* Con: Slightly more complex protocol, and requires authenticated
hop-by-hop transport to combat spam and man-in-the-middle
attacks.
* Con: Devices with limited resources and a high likelihood of
total failure, such as a mobile phone, will lose their IMDN
request state on total failure.
o Intermediary State Sharing
* Pro: Supports endpoints with limited resources or a high
likelihood of total failure, so long as all messages go through
a B2BUA that records state.
* Pro: Simpler protocol: IMDN's always go to the "last" user
agent up the relay chain.
* Pro: The B2BUA can chose to hide a recipient's IMDN reply to
address, yet still let the Reporting UAS issue an IMDN the
B2BUA will forward to the Requesting UAC.
NOTE: Is this important? It is saying that I am sending an
IM to someone who I do not want to let talk back to me.
That does not really fit the model of IM, does it?
* Con: Asking the B2BUA to take the role of IMDN forwarder means
the Requesting UAC loses any chance of getting end-to-end
IMDN's.
* Con: B2BUA's will have a tremendous amount of state to store,
especially given their location in the network.
NOTE: There are probably others, but I can't think of them now.
6. Overview
6.1. Data Elements
The data elements required for IMDN include elements that help
correlate notifications with messages, indicate whether or not to
Burger & Khartabil Expires April 26, 2006 [Page 8]
Internet-Draft IMDN October 2005
generate a notification message, and, of course, the disposition of
the message itself.
The following list enumerates the data elements of the IMDN in
detail.
o A protocol data element that indicates an IMDN request, and where
to send the IMDN to. Allowing the IMDN to go to a different
address than the sender enables, for example in SIMPLE, the From:
to be "sip:info@example.com" but have the IMDN to go to
"sip:agent23@example.com".
o The Original Message Identifier uniquely identifies the original
message. Currently there is no unique message identifier in CPIM.
Thus we will define one in this document.
o The Reporting UAS identifies the UAS generating the IMDN. The
reporting UAS might not be the "sender" of the IMDN, as there may
be relays [12] between the Reporting UAS and the requesting UAC.
o The Original Recipient URI identifies the original URI the
requesting UAC sent the message to. This may not be the same as
the Reporting UAS, as message delivery to the original URI may
have resulted in a list expansion. Section 6.3 describes list
procedures in detail.
o The Message Disposition identifies the eventual disposition of the
message, such as read, deleted, and so on.
NOTE: There is no Date or Delivered element, as that would be a
totally content-free, because of the lack of accuracy and veracity
of the data. First, the accuracy of the date / time stamp would
depend on the Reporting UAS' clock being synchronized. Second,
there is absolutely no way to ensure the veracity of the reported
time. The user can always hack their clock to change the reported
time. Moreover, most of the IM transport protocols have a concept
of tranmit time. Lastly, CPIM itself has a message time stamp.
Thus the recipient has some clue as to when the Reporting UAS sent
the IMDN.
The Requesting UAC needs to indicate to the Reporting UAS to generate
an IMDN. The Requesting UAC can indicate whether list exploders or
gateways should report on their receipt of the message or report on
the actual end recipients receipt of the message.
6.2. Disposition States
There are three broad categories of disposition states. They are
read, successfully processed, and failed.
The "read" state is straightforward. The read state indicates the
Recipient's UAS displayed the message to the user.
Since there is no positive acknowledgement from the user, one cannot
Burger & Khartabil Expires April 26, 2006 [Page 9]
Internet-Draft IMDN October 2005
determine a priori the user actually read the message. Thus one MUST
NOT use the protocol described here as a non-repudiation service.
The successfully processed states are as follows.
deleted The UAS deleted the message. This could be automatic,
based on policy, or manually done by the user.
NOTE: MDN [13] additionally indicated whether the
deletion was manual or automatic. Is this of use
for us in the IMDN case?
expanded The target URI of the message is a list exploder or
gateway. The UAS is indicating it successfully received
and expanded or relayed the message. However, there MUST
NOT be further notifications for this message (see
Section 6.3.
Error states are "error" and "denied".
error There was some processing error that makes it impossible or
unlikely for the user to get the message.
denied The target URI does not allow notifications. This could be
for any reason, including a general policy to not send
notifications, denying notifications to the particular sender, or
by user direction on a per-message basis. For privacy reasons,
the UAS MUST NOT give the reason for denial.
6.3. B2BUAs
The IMDN framework presented here supports back-to-back user agents
(B2BUAs) that forward message requests. This models most approaches
for list expansion, including SIP URI lists [15]. It also models
most gateway mechanisms.
When a user sends a message to a B2BUA URI, there are two options for
interpreting "delivery". One option is to consider the message
delivered to the list exploder URI itself. This is a strict
interpretation of "delivery", as the list exploder URI is a UAS in
itself. What happens on the other side of the list exploder, namely,
the re-origination of a bunch of messages related to the first
message, has no relation in a protocol sense to the original message.
The other option is to consider the message delivered to the ultimate
recipients of the list. On the one hand, this is what users expect,
especially if the list is emulating a chat room. On the other hand,
this could result in a storm of responses, which the user does not
want.
Unlike the e-mail situation, we can specify explicit behavior. This
means adding a directive indicating the reporting mode. The
reporting mode is either "final-recipient", indicating a report
Burger & Khartabil Expires April 26, 2006 [Page 10]
Internet-Draft IMDN October 2005
request for every final destination or "consolidate". The default is
final-recipient.
If the B2BUA will consolidate responses, it simply originates a new
(set of) message(s), setting the recipient of the report to itself.
The IMDN protocol machinery described here encourages end-to-end
taransmission of the IMDN. However, a B2BUA is free to receive IMDN
reports instead of the Requesting UAC. By definition, the B2BUA can
terminate the Requesting UAC's IMDN request and generate a new IMDN
request, in the B2BUA's role as a UAC.
If the B2BUA will be forwarding an IMDN from a downstream endpoint,
it will encapsulate the IMDN. This enables signatures over the
original message. Moreover, since the end system has the Original
From URI, it has the potential to encrypt the IMDN using, for
example, S/MIME [6], for the original sender, resulting in end-to-end
security.
The consolidate request has the B2BUA batch the individual IMDNs and
passes them in a single IMDN. The final system request forwards the
IMDNs as the B2BUA receives them. How long to wait for batching is a
local matter at the B2BUA.
NOTE TO SELF: For the case where we have Message-Disposition-To,
since the Message-Id is globally unique, and should be
cryptographically random, the sending UAC at least has the
possibility of discriminating between IMDN that relate to a real
message request and just random or mis-directed (storm) messages.
The decision to honor the "consolidate" directive is a local
matter. The B2BUA reject the request if local policy prevents
IMDN consolidation. The B2BUA MUST reject the request in the same
manner it would reject a list expansion request.
NOTE: Should consolidation, if we keep it in the protocol, be a
negotiable entity? Maybe a Requires: in the UAC request?
Gateway processing is identical to list exploder processing, in that
this mechanism considers a gateway to be a list exploder with a
single destination.
7. Namespace
Per CPIM [1], IMDN uses a namespace for the CPIM headers. The
namespace is
urn:ietf:params:cpim-headers:imdn
All of the header definitions in this document refer to this
Burger & Khartabil Expires April 26, 2006 [Page 11]
Internet-Draft IMDN October 2005
namespace.
NOTE: If one does not specify the name space in one's CPIM
message, YOU WILL NOT GET THE BEHAVIOR DESCRIBED IN THIS DOCUMENT.
8. Requesting UAC Behavior
8.1. IMDN Request Generation
To request the generation of an IMDN, the Requesting UAC MUST include
the Disposition-Notification-To and Message-ID headers. The
Requesting UAC MAY also include a List-Action header to provide down-
stream B2BUA's with the user's desire for IMDN reporting by the final
target of B2BUA expansion or the B2BUA itself. B2BUA's SHOULD
include the Original-From header, with the value of the inbound From
header, unless privacy considerations require the B2BUA to not
transmit the Original-From header. Likewise, B2BUA's SHOULD copy the
value of the inbound Message-ID into the outbound Original-Message-Id
header.
If the Requesting UAC insists on the possibility of an IMDN being
generated, the UAC MUST include the "Require: imdn.Message-
Disposition-To" header, where "imdn" is a reference to the name space
(the "NS" header). While this ensures the Reporting UAS is capable
of generating an IMDN, there is no guarantee that it actually will
generate an IMDN. See the Privacy Considerations (Section 4) section
for more discussion on this point.
8.1.1. Disposition-Notification-To
To mark a message for disposition notification, the sender MUST
include a Disposition-Notification-To CPIM header in the CPIM part of
the request.
If the sender requires a notification, the message MUST include a
CPIM Require header requiring the processing of the Disposition-
Notification-To CPIM header. Note that if the Recipient UAS does not
support IMDN, then the UAS will reject the message. In addition, the
Recipient UAS SHOULD NOT display the message.
If the sender does not require Disposition-Notification-To, and the
recipient's instant message user agent does not support IMDN, then
even though the recipient may read the message, the sender will not
receive a notification report.
Note that the choice of including a Require header is entirely a
local matter to the sender. Some instant messaging user agents may
Burger & Khartabil Expires April 26, 2006 [Page 12]
Internet-Draft IMDN October 2005
make this a per-receipt request option. Another opinion is the
Requesting UAC should never use the Require header to improve
interoperability with non-IMDN clients. However, in that case the
sender will not know if his message had no report because the
recipient did not read it or if the recipient's UAS was simply
unaware of IMDN. Thus the decision to use the Require header is
entirely outside the scope of this document.
The sender can request a delivery notification or a failure
notification.
The sender indicates where the Reporting UAS is to send the IMDN as a
URI value to the Disposition-Notification-To header.
NOTE: MDN [13] in the e-mail world allows for the disposition
reports to go to a destination other than the sending UAC. One
reason for this is that SMTP re-writing could obscure the sender
and list exploders, acting as back-to-back mail user agents, also
obscure the sender address. Moreover, it is quite useful for
message tracking [14]. On the other hand, specifying an arbitrary
address to get messages, especially in the case of a list
exploder, is a major opportunity for a distributed attack on a
host. See the Security Considerations (Section 3) section for
more discussion on this topic.
The syntax of the Disposition-Notification-To CPIM header is
mdn-request-header = "Disposition-Notification-To" ":"
SP notify-URI [ param-list ]
param-list = param-list param / param
param = ";" token
notify-URI = URI
The notify-URI is the destination URI for the IMDN. Typically, this
will be the reverse path for the instant message session. Another
sensible value is a session at the sender's terminal that collects
disposition notifications.
See the Security Considerations section for other permissible values
of the notify-URI.
For CPIM conferences, a message with a Disposition-Notification-To
header will result in all recipients performing IMDN processing. If
this is not desirable, the sending system MUST send multiple messages
with the appropriate requests (IMDN or not).
Systems sending an IMDN MUST NOT include the Disposition-
Notification-To header.
Burger & Khartabil Expires April 26, 2006 [Page 13]
Internet-Draft IMDN October 2005
At this time, there are no Disposition-Notification-To parameters
defined.
8.1.2. List-Action
If the user sends a message to a B2BUA, such as a list expander or
gateway, the Requesting UAC MAY include a List-Action header. The
List-Action header indicates how the B2BUA should handle IMDN
generation.
Values for List-Action are:
final-recipient This is a request for the B2BUA to have the
Reporting UAS send the IMDN directly to the
Requesting UAC (the Disposition-Notification-To
URI).
first-recipient This is a request for the B2BUA to generate an IMDN
for the B2BUA's receipt of the message. That is,
the disposition reflects the B2BUA's processing of
the message, not any down-stream messages.
NOTE: The last version of this document had a "consolidate"
request. This request had the B2BUA consolidate IMDN's from the
exploded list and then have the B2BUA send a single IMDN to the
Requesting UAC. However, this introduces a lot of protocol
complexity, such as how long the B2BUA waits for responses. For
now, I've punted this capability. I can bring back the text if
this is an important function.
If the Requesting UAC does not specify List-Action, the default List-
Action is first-recipient.
The syntax of the List-Action header is as follows.
list-action-hdr = "List-Action" ":" SP list-actions
list-actions = "final-recipient"
/ "first-recipient"
/ token
8.1.3. Original-From
A Requesting UAC MAY include its From identifier as the value to the
Original-From header. If there is no Original-From header, the value
of the From header is used. If there is no Original-From header in
the message, a B2BUA MUST use the From identifier from the inbound
message. If there is an Original-From header in the message, a B2BUA
MUST pass the Original-From header to the recipient URI(s). This
ensures that notifications from lists of lists will work.
The syntax of the Original-From is as follows.
Burger & Khartabil Expires April 26, 2006 [Page 14]
Internet-Draft IMDN October 2005
original-from-header = "Original-From" ":" SP
[ Formal-name ] "<" URI ">"
RFC3862 [1] section 4.1 defines "Formal-name".
8.1.4. Message-ID
A UAC MUST include a globally unique Message-ID. It is necessary for
the Message-ID to be unique to the UAC in order for the UAC to be
able to exactly correlate IMDN's with the messages they refer to. It
will be necessary for the Message-ID to be globally unique in order
to support frameworks such as message tracking [14] in the future.
Since it is easy enough to make the Message-ID globally unique now,
we mandate it here so that message tracking will be easier in the
future.
The syntax of the Message-ID is as follows.
message-id-hdr = "Message-ID" ":" SP token
A B2BUA generates new messages, and thus the Message-ID will be new.
8.1.5. Original-Message-ID
Since a B2BUA generates new messages, and thus new Message-ID's, we
need a mechanism for the Reporting UAS to insert the appropriate
Message-ID in the IMDN. To do this, a B2BUA inserts an Original-
Message-ID header with the value of the Message-ID. If there is
already an Original-Message-ID header, then the B2BUA MUST preserve
the value in the outbound request, unless the request forbids it.
The request may forbid it if, for example, the List-Action is first-
recipient. If there is no Original-Message-ID present in a message
delivered to a B2BUA for subsequent forwarding, the B2BUA MUST copy
the value of the Message-ID header of the inbound message to be the
value of the Original-Message-ID header of the outbound message(s).
The syntax of the Original-Message-ID is identical to the syntax of
the Message-ID.
8.2. IMDN Reception Processing
Once a Requesting UAC sends a message with an IMDN request, it SHOULD
preserve the message context, principally the Message-ID, and other
user-identifiable information, such as the message subject or
content. Without preservation of the message context, the Requesting
UAC will not be able to correlate the IMDN with the outbound request.
How long to preserve the state is an implementation choice. However,
the Requesting UAC SHOULD keep the state for at least 5 minutes.
Burger & Khartabil Expires April 26, 2006 [Page 15]
Internet-Draft IMDN October 2005
It is RECOMMENDED that a Requesting UAC not notify the user if the
Requesting UAC receives an IMDN that does not correlate to a message
the Requesting UAC sent.
If a first IMDN has a Disposition-Notification-To header, the
Requesting UAC MUST NOT issue a second IMDN in response to the first
IMDN.
9. Reporting UAS Operation
9.1. General Operation
When the Reporting UAS receives a CPIM message with a Disposition-
Notification-To CPIM header, the Reporting UAS SHOULD generate an
IMDN. Security Considerations, Privacy Considerations, and local
policy may prevent the generation of an IMDN.
The Reporting UAS MUST NOT send more than one final IMDN in response
to an IMDN request. That is, once an IMDN has been issued on behalf
of a recipient, no further IMDNs may be issued on behalf of that
recipient, even if another disposition is performed on the message.
For example, if the user reads and then deletes the message, the UAS
will send a single read notification. The delete operation in this
case will not generate an additional IMDN.
A system receiving an instant message disposition notification MUST
NOT generate a message disposition notification in response to that
notification, even if the request includes a Disposition-
Notification-To header.
A system sending an IMDN MUST NOT include the Disposition-
Notification-To header.
A CPIM message that requests an IMDN but does not include the
required Message-ID header is malformed and the UAS MUST reject the
request using the appropriate protocol mechanism for rejecting a
malformed request.
NOTE: We could be helpful here and create a new SIP result code
for this situation. We can do that if needed.
The Reporting UAS MUST copy the incoming CPIM Subject: header as the
IMDN CPIM Subject: header.
9.2. Recipient is the End User UAS
If the recipient of a CPIM message with a well-formed IMDN request is
the end-user user agent server, then
Burger & Khartabil Expires April 26, 2006 [Page 16]
Internet-Draft IMDN October 2005
o If the user read the message, then the UAS SHOULD generate a read
IMDN, mindful of the privacy considerations enumerated in
Section 4.
o If the UAS automatically deleted the message, or the user deleted
the message without reading it, then the UAS SHOULD generate a
deleted IMDN, mindful of the privacy considerations enumerated in
Section 4.
o If the UAS' policy is to deny IMDN to the requestor, or if the
user requests a denial report to the UAC, the UAS MUST generate a
denied IMDN.
o If the UAS' policy is to ignore IMDN requests, or the user
requests the supression of a given IMDN report, the UAS MUST
silently ignore the IMDN request.
The UAS SHOULD sign the IMDN it generates using S/MIME [6]. The UAS
MAY encrypt the IMDN, knowing the URI of the endpoint requesting the
IMDN is in the Original-From header.
The Reporting UAS MUST use the format and fill in the content of the
IMDN as described in Section 10.
9.3. Recipient is a B2BUA
If the Recipient UAS is a back-to-back user agent (B2BUA), such as a
list exploder or messaging gateway, then the action taken depends on
the value of List-Action. If there is no List-Action header, or the
UAS does not understand the value of the List-Action header, the UAS
takes the "first-recipient" action.
9.3.1. No List-Action or first-recipient
If the List-Action is "first-recipient" or there is no List-Action
specified, then the Recipient UAS issues an IMDN using the following
procedures.
o If the B2BUA forwards the message, it SHOULD return an "expanded"
IMDN, mindful of the privacy considerations enumerated in
Section 4.
o If there was an error processing the message, the B2BUA SHOULD
return an "error" IMDN, mindful of the privacy considerations
enumerated in Section 4.
When forwarding the message, the B2BUA MUST NOT use the Disposition-
Notification-To value of the inbound request. Including a
Disposition-Notification-To header in the forwarded messages is a
matter of local policy.
The Reporting UAS MUST use the format and fill in the content of the
IMDN as described in Section 10.
Burger & Khartabil Expires April 26, 2006 [Page 17]
Internet-Draft IMDN October 2005
9.3.2. final-recipient
If the List-Action is "final-recipient", then the B2BUA SHOULD
forward the Message-Disposition-To and List-Action headers to down-
stream destinations. One condition where the B2BUA might not forward
these headers is where the B2BUA knows the down-stream destination
will not honor or is not capable of honoring the IMDN request. In
the latter case, the B2BUA SHOULD return an "expanded" IMDN. In the
former case, local policy will decide whether to return a denied
IMDN, expanded IMDN, or not return an IMDN at all. Likewise, if the
B2BUA knows it needs to keep the identity of the Requesting UAC
private, it will insert its own address for the Disposition-
Notification-To header, and regenerate a new IMDN to the Requesting
UAC.
When the B2BUA receives an IMDN from the Reporting UAS, the B2BUA
will encapsulate the IMDN from the downstream UAS and send the
response to the UAC that generated the upstream request. The B2BUA
MUST verify the Original-Message-ID header matches a Message-ID of a
previous incoming request.
How long to keep the Message-ID state is a local matter. We
RECOMMEND it be at least 5 minutes.
If the B2BUA receives an IMDN that does not match an existing
Message-ID, the B2BUA MUST discard the IMDN.
10. IMDN Format
The IMDN is an XML [7] document. The document MUST be well formed
and MUST be valid according to the schema presented in Section 12.2.
The namespace identifier for elements defined by this specification
is a URN [8], using the namespace identifier 'ietf' as defined by
IETF URN Namespace [9] and extended by the IETF XML Registry [10].
The URN is
urn:ietf:params:xml:ns:imdn
The root element is <imdn>. The disposition tag takes the value
described in Section 6.2.
The Reporting UAS MUST include the value of the original message's
Message-ID as the value of the message-id tag.
The Reporting UAS SHOULD include its URI in the reporting-uas-uri
tag. One condition where the Reporting UAS will not include its URI
is if it wants to keep its URI private.
Burger & Khartabil Expires April 26, 2006 [Page 18]
Internet-Draft IMDN October 2005
The Reporting UAS SHOULD include the original recipient as the value
of the original-recipient tag.
The Reporting UAS MUST include the message disposition in the
disposition tag.
11. Examples
11.1. Simple End-to-End Read Request
Request
From: Eric Burger <im:eburger@example.com>
To: Hisham Khartabil <im:hisham.khartabil@example.net>
DateTime: 2005-10-18T09:27:22-5
Subject: Did you get this?
NS: imdn <urn:ietf:params:cpim-headers:imdn>
imdn.Disposition-Notification-To: eburger@example.com
imdn.Message-ID: 1542af3e8b@eburger@example.com
Content-type: text/xml; charset=utf-8
Content-ID: <1542af3e8b-12@eburger@example.com>
<body>
Did you get this message?
</body>
Response
Burger & Khartabil Expires April 26, 2006 [Page 19]
Internet-Draft IMDN October 2005
From: Hisham Khartabil <im:hisham.khartabil@example.net>
To: <im:eburger@example.com>
DateTime: 2005-10-18T09:30:18+1
Subject: Did you get this?
NS: imdn <urn:ietf:params:cpim-headers:imdn>
imdn.Message-ID: latida27@stuff@example.net
Content-type: multipart/signed; boundary=next;
micalg=sha1;
protocol=application/pkcs7-signature
--next
Content-type: application/imdn+xml; charset=utf-8
<imdn>
<disposition>read</disposition>
<reporting-uas-uri>
im:hisham.khartabil@example.net
</reporting-uas-uri>
<original-recipient-uri>
im:hisham.khartabil@example.net
</original-recipient-uri>
<original-message-id>
1542af3e8b@eburger@example.com
</original-message-id>
</imdn>
--next
Content-type: application/pkcs7-signature
{signature stuff}
:
:
--next--
Note the IMDN plaintext would not have the CRLF's in the data
elements. We do that here simply for readability. Likewise, the
IMDN plaintext would be encrypted.
NOTE TO SELF: Put in real encryption parameters soon.
11.2. Gateway Endpoint
Happy Path for gateway reporting it forwarded.
11.3. List Exploder - Forward
Happy Path for forwarding case
Burger & Khartabil Expires April 26, 2006 [Page 20]
Internet-Draft IMDN October 2005
11.4. List Exploder - Consolidate
Show Wrapped Responses
11.5. List With Lists
Show wrapped, wrapped responses.
11.6. End-to-End Encryption Forwarded
Gateway scenario where Reporting UAS encrypts IMDN document for read
only by Requesting UAC.
12. Formal Syntax
12.1. IMDN CPIM Request
TODO: collect syntax from above.
12.2. IMDN Document
Coming soon.
13. IANA Considerations
URN name in IETF namespace: urn:ietf:params:cpim-headers:imdn
IMDN schema
14. References
14.1. Normative References
[1] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging
(CPIM): Message Format", RFC 3862, August 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[4] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-12 (work in progress),
October 2005.
Burger & Khartabil Expires April 26, 2006 [Page 21]
Internet-Draft IMDN October 2005
[5] Fajman, R., "An Extensible Message Format for Message
Disposition Notifications", RFC 2298, March 1998.
[6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Certificate Handling", RFC 3850,
July 2004.
[7] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E.
Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)",
W3C REC REC-xml-20040204, February 2004.
[8] Moats, R., "URN Syntax", RFC 2141, May 1997.
[9] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[10] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
14.2. Informative References
[11] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[12] Jennings, C., "Relay Extensions for the Message Sessions Relay
Protocol (MSRP)", draft-ietf-simple-msrp-relays-05 (work in
progress), July 2005.
[13] Hansen, T. and G. Vaudreuil, "Message Disposition
Notification", RFC 3798, May 2004.
[14] Hansen, T., "Message Tracking Model and Requirements",
RFC 3888, September 2004.
[15] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE
Requests in the Session Initiation Protocol (SIP)",
draft-ietf-sipping-uri-list-message-03 (work in progress),
April 2005.
Appendix A. Contributors
Appendix B. Acknowledgements
Thanks go to Ben Campbell for continuously prodding me. Thanks also
to Hisham for the relay idea and threatening some text to force me
back to the task. Dean kept reminding me that 3GPP really, really
Burger & Khartabil Expires April 26, 2006 [Page 22]
Internet-Draft IMDN October 2005
wants this done and to work.
Burger & Khartabil Expires April 26, 2006 [Page 23]
Internet-Draft IMDN October 2005
Authors' Addresses
Eric Burger
Brooktrout Technology, Inc.
18 Keewaydin Dr.
Salem, NH 03079-2839
USA
Phone: +1 603 890 7587
Fax: +1 603 457 5944
Email: eburger@brooktrout.com
Hisham Khartabil
Telio
P.O. Box 1203 Vika
Oslo
Norway
Phone: +47 2167 3544
Email: hisham.khartabil@telio.no
Burger & Khartabil Expires April 26, 2006 [Page 24]
Internet-Draft IMDN October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Burger & Khartabil Expires April 26, 2006 [Page 25]
| PAFTECH AB 2003-2026 | 2026-04-23 03:46:13 |