One document matched: draft-burger-simple-imdn-03.txt
Differences from draft-burger-simple-imdn-02.txt
SIMPLE E. Burger
Internet-Draft Brooktrout Technology, Inc.
Expires: August 9, 2006 February 5, 2006
Instant Message Delivery Notification (IMDN) for Common Presence and
Instant Messaging (CPIM)
draft-burger-simple-imdn-03
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 August 9, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
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 Expires August 9, 2006 [Page 1]
Internet-Draft IMDN February 2006
Table of Contents
1. Document Conventions . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 7
5. State Sharing . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Data Elements . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Disposition States . . . . . . . . . . . . . . . . . . . . 10
6.2.1. read . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.2. processed . . . . . . . . . . . . . . . . . . . . . . 10
6.2.3. error . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.4. denied . . . . . . . . . . . . . . . . . . . . . . . . 10
6.3. B2BUAs . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Requesting UAC Behavior . . . . . . . . . . . . . . . . . . . 12
8.1. IMDN Request Generation . . . . . . . . . . . . . . . . . 12
8.1.1. Disposition-Notification . . . . . . . . . . . . . . . 12
8.1.2. List-Action . . . . . . . . . . . . . . . . . . . . . 13
8.1.3. Original-From . . . . . . . . . . . . . . . . . . . . 14
8.1.4. Message-ID . . . . . . . . . . . . . . . . . . . . . . 14
8.1.5. Original-Message-ID . . . . . . . . . . . . . . . . . 15
8.2. IMDN Reception Processing . . . . . . . . . . . . . . . . 15
9. Reporting UAS Operation . . . . . . . . . . . . . . . . . . . 15
9.1. General Operation . . . . . . . . . . . . . . . . . . . . 16
9.2. Recipient is the End User UAS . . . . . . . . . . . . . . 16
9.3. Recipient is a B2BUA . . . . . . . . . . . . . . . . . . . 17
9.3.1. first-recipient . . . . . . . . . . . . . . . . . . . 17
9.3.2. final-recipient . . . . . . . . . . . . . . . . . . . 18
9.3.3. No List-Action Specified . . . . . . . . . . . . . . . 18
9.3.4. Unknown List-Action Specified . . . . . . . . . . . . 18
10. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. disposition . . . . . . . . . . . . . . . . . . . . . . . 19
10.2. original-message-id . . . . . . . . . . . . . . . . . . . 19
10.3. original-recipient-uri . . . . . . . . . . . . . . . . . . 19
10.4. reporting-uas-uri . . . . . . . . . . . . . . . . . . . . 19
10.5. original-recipient . . . . . . . . . . . . . . . . . . . . 19
10.6. disposition-time . . . . . . . . . . . . . . . . . . . . . 19
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Simple End-to-End IMDN Request . . . . . . . . . . . . . . 20
11.2. Gateway Endpoint . . . . . . . . . . . . . . . . . . . . . 21
11.3. List Exploder - Forward . . . . . . . . . . . . . . . . . 21
11.4. List Exploder - Private Forward . . . . . . . . . . . . . 22
11.5. List With Lists . . . . . . . . . . . . . . . . . . . . . 22
11.6. End-to-End Encryption Forwarded . . . . . . . . . . . . . 22
12. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. IMDN CPIM Request . . . . . . . . . . . . . . . . . . . . 22
Burger Expires August 9, 2006 [Page 2]
Internet-Draft IMDN February 2006
12.2. IMDN Document . . . . . . . . . . . . . . . . . . . . . . 22
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
14.1. Normative References . . . . . . . . . . . . . . . . . . . 22
14.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 23
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 26
Burger Expires August 9, 2006 [Page 3]
Internet-Draft IMDN February 2006
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 RFC4234 [3] for all syntax specification uses, other than XML.
Examples and discussion of CPIM headers, for clarity, do not include
the leading name space identifier.
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 Expires August 9, 2006 [Page 4]
Internet-Draft IMDN February 2006
Electronic Mail [12] 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 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 or otherwise disposed the message. The
mechanism by which an instant message user agent determines its user
has read a message is beyond the scope of this document. 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.
The threats in the IMDN system, over and beyond the threats inherent
to CPIM [4] include the following:
Burger Expires August 9, 2006 [Page 5]
Internet-Draft IMDN February 2006
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 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,
we require some level of authentication and integrity protections.
That said, there are circumstances where strong integrity would be
overkill. The presumption is the sender of the IM has and sets the
expectation for the level of protection. The procedures for
integrity protection are as follows.
Burger Expires August 9, 2006 [Page 6]
Internet-Draft IMDN February 2006
o If the Reporting UAS has a certificate, the Reporting UAS MUST
sign the IMDN.
o If the IM is encrypted, the Reporting UAS 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.
o The two above rules are cumulative.
Reporting UAS' MUST be capable of loading a user certificate.
Replay and message insertion attacks are unlikely in an IMDN
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.
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 or financial community.
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
"denied" IMDN is always sent in response to a request for an IMDN.
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
Burger Expires August 9, 2006 [Page 7]
Internet-Draft IMDN February 2006
IMDN body text. The transmission of the IMDN SHOULD be end-to-end
encrypted, if physically possible. If the Originating UAC encrypted
the IM, the Reporting UAS MUST encrypt the IMDN and wrap the result
with 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 always forward 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
(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.
Burger Expires August 9, 2006 [Page 8]
Internet-Draft IMDN February 2006
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 hides 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.
The consensus of the work group is to use intermediary state sharing
as it results in a simpler protocol. The protocol does leave the
potential for future end-to-end state sharing by allowing a token to
be the value of the Disposition-Notification header. The most likely
value for this token is the URI to send the IMDN directly to.
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
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
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 [13] 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 B2BUA
procedures in detail.
Burger Expires August 9, 2006 [Page 9]
Internet-Draft IMDN February 2006
o An indicator to keep the Original Recipient URI private.
o The Message Disposition identifies the eventual disposition of the
message, such as read, deleted, and so on.
o The Disposition Time indicates when the disposition time at the
Reporting UAS.
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 recipient's receipt of the message.
6.2. Disposition States
There are three broad categories of disposition states. They are
read, processed, error, and denied.
6.2.1. read
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
determine a priori the user actually read the message. Thus one MUST
NOT use the protocol described here as a non-repudiation service.
6.2.2. processed
The target URI of the message is a B2BUA. The B2BUA's UAS indicates
it successfully received and expanded or relayed the message.
However, there MUST NOT be further notifications for this message
(see Section 6.3. See Section 8.1.2 for how the Requesting UAS can
drive the generation of the processed notification when List-Action
is first-recipient.
6.2.3. error
The error state indicates there was some processing error that makes
it impossible or unlikely for the user to get the message.
6.2.4. denied
The denied state indicates 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.
Burger Expires August 9, 2006 [Page 10]
Internet-Draft IMDN February 2006
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 [16]. 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 resolves to
the B2BUA UAS. What happens on the other side of the list exploder,
namely, the re-origination of a bunch of messages, nominally 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.
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.
Gateway processing is identical to list exploder processing, in that
this mechanism considers a gateway to be a list exploder with a
single destination.
To ease interpretation of the IMDN at the B2BUA and original
Requesting UAC, the B2BUA MUST preserve the original URI the
Requesting UAC sent the message to. That is, it must carry the value
of the To header in the Original-To CPIM header.
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
namespace.
Burger Expires August 9, 2006 [Page 11]
Internet-Draft IMDN February 2006
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 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 mark a message for disposition notification, the sender MUST
include a Disposition-Notification 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 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, 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
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
Burger Expires August 9, 2006 [Page 12]
Internet-Draft IMDN February 2006
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 syntax of the Disposition-Notification CPIM header is
mdn-request-header = "Disposition-Notification" ":" NULL / token-list
token-list = token-list token / token
For CPIM conferences, a message with a Disposition-Notification
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 a Disposition-Notification
header.
At this time, there are no Disposition-Notification parameters or
tokens defined. Adding Disposition-Notification parameters MUST be
by a Standards Track RFC.
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 request IMDN's
from the subsequent requests and relay the IMDN to
the Requesting UAC.
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.
{other} The Reporting UAS MUST treat unrecognized values for
List-Action as "first-recipient". Definitions for
new values MUST include optional CPIM REQUIRE tags
to ensure interoperability.
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.
Burger Expires August 9, 2006 [Page 13]
Internet-Draft IMDN February 2006
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 populate the Original-From value with 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, and that end-to-end encryption of IMDN's
will work.
If a Requesting UAC wishes to keep her URI private through a B2BUA,
then the Reporting UAC includes the Original-From header, but with a
NULL value.
The syntax of the Original-From is as follows.
original-from-header = "Original-From" ":" SP from-whom
from-whom = "" / from-address
from-address = [ 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 [15] 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.
A Reporting UAC MUST be prepared to handle a Message-ID token of at
least 4095 octets.
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.
Burger Expires August 9, 2006 [Page 14]
Internet-Draft IMDN February 2006
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 as follows.
original-message-id-hdr = "Original-Message-ID" ":" SP token
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. The
Requesting UAC may find it impossible to preserve message state if it
has limited resources or does not have non-volatile memory and then
loses power.
How long to preserve the state is an implementation choice. However,
the Requesting UAC SHOULD keep the state for at least 5 minutes,
unless that is physically impossible due to the characteristics of
the Requesting UAC.
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. This is to prevent IMDN spoofing. Clearly,
if a requesting UAC loses its sent message state, the client may use
a different display strategy in response to apparently unsolicited
IMDN's.
A Requesting UAC MUST NOT issue an IMDN in response to an IMDN, even
if that IMDN incorrectly includes a Disposition-Notification header.
9. Reporting UAS Operation
Burger Expires August 9, 2006 [Page 15]
Internet-Draft IMDN February 2006
9.1. General Operation
When the Reporting UAS receives a CPIM message with a Disposition-
Notification CPIM header, the Reporting UAS SHOULD generate an IMDN.
Security Considerations, Privacy Considerations, and local policy all
may prevent the generation of an IMDN.
The Reporting UAS MUST NOT send more than one 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. Likewise, a B2BUA
receiving a List-Action of first-recipient MUST NOT relay IMDN's from
down-stream UAS's to the original Requesting UAC, as the original
Requesting UAC has asked only for an IMDN from the B2BUA.
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
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
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
processed IMDN, mindful of the privacy considerations enumerated
in Section 4.
Burger Expires August 9, 2006 [Page 16]
Internet-Draft IMDN February 2006
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 SHOULD generate
a denied IMDN, mindful of the privacy considerations enumerated in
Section 4.
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.
If the Reporting UAS has a certificate, it MUST sign the IMDN it
generates using S/MIME [6]. The Reporting UAS MUST be capable of
loading a certificate for signing IMDN's.
If the Requesting UAC encrypts the IM, the Reporting UAS MUST encrypt
the IMDN. For assistance in this task, 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. 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 "processed"
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.
Including a Disposition-Notification header in the forwarded messages
is a matter of local policy. However, if the List-Action is first-
recipient or unspecified, the B2BUA MUST NOT relay down-stream IMDN's
to the original Requesting UAC.
The Reporting UAS MUST use the format and fill in the content of the
IMDN as described in Section 10.
Burger Expires August 9, 2006 [Page 17]
Internet-Draft IMDN February 2006
9.3.2. final-recipient
If the List-Action is "final-recipient", then the B2BUA SHOULD
forward the Message-Disposition 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 "processed" IMDN. In the
former case, local policy will decide whether to return a denied
IMDN, processed IMDN, or not return an IMDN at all.
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.
9.3.3. No List-Action Specified
If there is no List-Action header, or there is a List-Action header
with no value, the Reporting UAS MUST follow the procedures for
first-recipient.
9.3.4. Unknown List-Action Specified
If there is a List-Action header, but the Reporting UAS does not
recognize the value of the List-Action header, the Reporting UAS MUST
follow the procedures for first-recipient.
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 [11].
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.
Burger Expires August 9, 2006 [Page 18]
Internet-Draft IMDN February 2006
10.1. disposition
The Reporting UAS MUST include the message disposition in the
disposition tag.
We use a string value, rather than an attribute value, to enable
future addition of state strings
The value of the disposition tag may take the following values:
read The message was read.
processed The message was processed.
error There was an error processing the message.
denied The Reporting UAS denies reporting the disposition
of the message.
10.2. original-message-id
The Reporting UAS MUST include the value of the Message-ID of the IM
as the value of the original-message-id tag.
10.3. original-recipient-uri
The Reporting UAS MUST include the value of the original message's
Original-From as the value of the original-recipient-uri tag. If the
Reporting UAS specified a NULL Original-From, then the Reporting UAS
MUST return an empty original-recipient-uri value.
10.4. reporting-uas-uri
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. In this case the Reporting
UAS MUST NOT include this tag in the IMDN.
10.5. original-recipient
If there is an Original-To header in the IM, the Reporting UAS MUST
include the value of the Original-To header as the value to the
original-recipient tag.
10.6. disposition-time
The Reporting UAS MUST include the disposition time reflecting when
the reported disposition occured as the value of the disposition-time
tag. The format of the time value MUST follow the format specified
in RFC 3339 [10], using UTC.
Burger Expires August 9, 2006 [Page 19]
Internet-Draft IMDN February 2006
11. Examples
11.1. Simple End-to-End IMDN 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:
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 Expires August 9, 2006 [Page 20]
Internet-Draft IMDN February 2006
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.
11.2. Gateway Endpoint
Happy Path for gateway reporting it forwarded. Same request as
above, but with processed response.
11.3. List Exploder - Forward
Happy Path for forwarding case. Note the different responses, but
with same Original-To and Original-Message-Id.
Burger Expires August 9, 2006 [Page 21]
Internet-Draft IMDN February 2006
11.4. List Exploder - Private Forward
Show no Original-Sender
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 in Section 12.2.
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. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[4] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-13 (work in progress),
December 2005.
Burger Expires August 9, 2006 [Page 22]
Internet-Draft IMDN February 2006
[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] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002.
[11] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
14.2. Informative References
[12] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[13] Jennings, C., "Relay Extensions for the Message Sessions Relay
Protocol (MSRP)", draft-ietf-simple-msrp-relays-06 (work in
progress), December 2005.
[14] Hansen, T. and G. Vaudreuil, "Message Disposition
Notification", RFC 3798, May 2004.
[15] Hansen, T., "Message Tracking Model and Requirements",
RFC 3888, September 2004.
[16] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE
Requests in the Session Initiation Protocol (SIP)",
draft-ietf-sipping-uri-list-message-06 (work in progress),
January 2006.
Appendix A. Contributors
Appendix B. Acknowledgements
Burger Expires August 9, 2006 [Page 23]
Internet-Draft IMDN February 2006
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
wants this done and to work.
Burger Expires August 9, 2006 [Page 24]
Internet-Draft IMDN February 2006
Author's Address
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
Burger Expires August 9, 2006 [Page 25]
Internet-Draft IMDN February 2006
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 (2006). 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 Expires August 9, 2006 [Page 26]
| PAFTECH AB 2003-2026 | 2026-04-23 03:43:58 |