One document matched: draft-burger-simple-imdn-01.txt
Differences from draft-burger-simple-imdn-00.txt
SIMPLE E. Burger
Internet-Draft Brooktrout Technology, Inc.
Expires: January 18, 2006 July 17, 2005
Instant Message Delivery Notification (IMDN) for Common Presence and
Instant Messaging (CPIM) Messages
draft-burger-simple-imdn-01
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 January 18, 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 Expires January 18, 2006 [Page 1]
Internet-Draft IMDN July 2005
Table of Contents
1. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Data Elements . . . . . . . . . . . . . . . . . . . . . . 4
3.2 B2BUAs . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Disposition States . . . . . . . . . . . . . . . . . . . . 6
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Disposition Notification Marking (Sender) . . . . . . . . 7
4.1.1 Disposition-Notification . . . . . . . . . . . . . . . 7
4.1.2 List-Action . . . . . . . . . . . . . . . . . . . . . 9
4.1.3 Original-From . . . . . . . . . . . . . . . . . . . . 9
4.1.4 Message-ID . . . . . . . . . . . . . . . . . . . . . . 10
4.1.5 Original-Message-ID . . . . . . . . . . . . . . . . . 10
4.2 Disposition Notification Processing (Receiver) . . . . . . 10
4.2.1 Recipient is End User UAS . . . . . . . . . . . . . . 11
4.2.2 Recipient is B2BUA . . . . . . . . . . . . . . . . . . 11
5. Format of an IMDN . . . . . . . . . . . . . . . . . . . . . . 13
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1 Simple End-to-End Read Request . . . . . . . . . . . . . . 14
8.2 Gateway Endpoint . . . . . . . . . . . . . . . . . . . . . 14
8.3 List Exploder - Forward . . . . . . . . . . . . . . . . . 15
8.4 List Exploder - Consolidate . . . . . . . . . . . . . . . 15
8.5 List With Lists . . . . . . . . . . . . . . . . . . . . . 15
8.6 End-to-End Encryption Forwarded . . . . . . . . . . . . . 15
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1 IMDN CPIM Request . . . . . . . . . . . . . . . . . . . . 15
9.2 IMDN Document . . . . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1 Normative References . . . . . . . . . . . . . . . . . . . 16
11.2 Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 18
Burger Expires January 18, 2006 [Page 2]
Internet-Draft IMDN July 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.
If you missed it in the title, the term "IMDN" is an Instand 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].
2. Introduction
In most any user-to-user message exchange system, message senders
often wish to know if the human recipient actually read a message.
Most messaging protocols, including CPIM sessions [3], ensure
reliable delivery of a message to the recipient. However, they
cannot report when a human user actually reads the message.
Electronic Mail [5] deals with this situation with message delivery
notifications [4]. 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 [4].
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
Burger Expires January 18, 2006 [Page 3]
Internet-Draft IMDN July 2005
user has read a message is beyond the scope of this document.
However, there are many issues that are important to consider. An
appendix to this document enumerates a number of these issues.
The mechansim 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, 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.
3. Overview
A message sender marks the message for disposition notification. At
a certain point in time, the recipient's instant message user agent
determines the recipient has read the message. At that point, the
recipient's instant message user agent automatically generates a
notification message to the sender. This document calls this
notification the Instant Message Disposition Notification (IMDN).
Note there are numerous circumstances under which the instant message
user agent may not send a notification. See the Security
Considerations section below for more information.
3.1 Data Elements
There is a small set of data elements that any IMDN system needs.
The data elements include some 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 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 [6] 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 3.2 describes list
procedures in detail.
Burger Expires January 18, 2006 [Page 4]
Internet-Draft IMDN July 2005
o The Original From URI identifies the URI of the sender of the
original message. The IMDN machinery needs this information in
B2BUA situations such as list expansion and IM gateways.
o The Message Disposition identifies the eventual disposition of the
message, such as read, deleted, and so on.
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.
3.2 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 [9]. 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 are in the lucky situation that we
can specify explicit behavior. This means adding a directive
indicating the reporting mode. The reporting mode is either "final-
recipient", indicating a report request for every final destination;
"consolidate", indicating the list exploder is responsible for
consolidating notifications to the user; or "request-URI", indicating
the list exploder is the target of the disposition notification
request. The default is request-URI.
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 for the original
sender, end-to-end.
The consolidate request has the B2BUA batch the individual IMDNs and
Burger Expires January 18, 2006 [Page 5]
Internet-Draft IMDN July 2005
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: The previous version of this draft used the Disposition-
Notification-To mechanism from MDN. This enabled the actual
recipients to directly notify the sender, reducing the burden on
list exploders. Upon reflection, Hisham's thought of having the
list exploder service relaying reports has a benefit that could be
a drawback. The benefit is the list exploder can decide whether a
given recipient in a list is "private". That is, their existence
in the list is hidden. If there is a private destination, the
list exploder knows not to generate IMDNs for that destination or
to hide the destination's URI. The drawback is it is up to the
list exploder to keep the information private, not the user agent
server in question. Moreover, there cannot be easy end-to-end
encryption of the report. Moreover, the list exploder may not be
trusted by the UAS, whereas we assume the UAS is under control of
the recipient that wishes to remain private. For now, I'll float
Hisham's way. We can easily resurrect the Disposition-
Notification-To mechanics.
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.
Gateway processing is identical to list exploder processing, in that
this mechanism considers a gateway to be a list exploder with a
single destination.
3.3 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
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.
Burger Expires January 18, 2006 [Page 6]
Internet-Draft IMDN July 2005
deleted The UAS deleted the message. This could be automatic,
based on policy, or manually, done by the user.
NOTE: MDN [7] 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 3.2.
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.
4. Operation
4.1 Disposition Notification Marking (Sender)
There are two headers the Requesting UAC can include in a CPIM
message that he would like an IMDN generated for. They are
Disposition-Notification and List-Action.
4.1.1 Disposition-Notification
NOTE: Earlier verisons of this draft used the Disposition-
Notification-To marking. The "To" is the key difference. MDN [7]
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 [8].
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.
For simplicity, we have taken out this functionality for now.
Returning it would be the subject of list discussion.
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
Burger Expires January 18, 2006 [Page 7]
Internet-Draft IMDN July 2005
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
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.
NOTE: Having an explicit "don't notify me" request does not make
sense. Simply do not include a Disposition-Notification header in
the request.
NOTE: What is the rationale for having separate error or read
reports? I'm having trouble thinking of anything but a set of
bizarre corner cases for a message that was successfully delivered
to a UAS that then cannot be rendered to the user. Clearly, we're
asking for a read receipt, so we will take it. What is the use
case for an error report that does NOT report on a read, but only
on the delete or failure? That is a MEANINGLESS request. This is
because the sender cannot differentiate between a message that was
read, is sitting in an inbox, or UAS failure.
Because of these issues, there are no parameters to the
Disposition-Notification header.
The syntax of the Disposition-Notification CPIM header is
mdn-request-header = "Disposition-Notification" ":" SP token
token = NULL / extension-token
extension-token = token
Systems sending an IMDN MUST NOT include the Disposition-Notification
header.
Burger Expires January 18, 2006 [Page 8]
Internet-Draft IMDN July 2005
4.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.
If the List-Action is "final-recipient", the B2BUA SHOULD request
IMDNs from each actual recipient. The B2BUA will then relay the
responses to the Requesting UAC.
Situations where the lB2BUA will not forward the IMDN request include
private list members for list expanders and messaging systems that do
not support read receipts for gateways.
If the List-Action is "consolidate", the B2BUA is responsible for
consolidating notifications into a single IMDN. Each IMDN report
gets included in the IMDN report element.
If the List-Action is "request-URI", then the list expander or
gateway SHOULD return the appropriate status. Note the appropriate
status MUST NOT be "read", as the end user will not have read the
message at the time the gateway or list exploder receives the
message.
Situations where the list exploder or gateway will not generate an
IMDN include when local policy forbids the generation of an IMDN.
The default List-Action is "request-URI".
The syntax of the List-Action header is as follows.
list-action-hdr = "List-Action" ":" SP list-actions
list-actions = "final-recipient"
/ "consolidate"
/ "request-URI"
/ token
4.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.
Burger Expires January 18, 2006 [Page 9]
Internet-Draft IMDN July 2005
Original-From has the identical syntax as the From header specified
in CPIM [1].
4.1.4 Message-ID
A Requesting 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 [8] 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.
4.1.5 Original-Message-ID
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). If there is
an Original-Message-ID present in the inbound message, the B2BUA MUST
use the same value in the outbound message.
The syntax of the Original-Message-ID is identical to the syntax of
the Message-ID.
4.2 Disposition Notification Processing (Receiver)
The receipt of a CPIM message with a Disposition-Notification CPIM
header indicates the request for an IMDN.
The Recipient 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.
A system receiving an instant message disposition notification MUST
NOT generate a message disposition notification in response to that
notification.
Burger Expires January 18, 2006 [Page 10]
Internet-Draft IMDN July 2005
A system sending an IMDN MUST NOT include the Disposition-
Notification header.
A CPIM message that requests Disposition-Notification 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.
We could be helpful here and create a new SIP result code for this
situation. We can do that later.
IMDN generation depends on whether the recipient of the IMDN request
is the end-user's UAS or if it is a gateway or list exploder UAS.
If there is a value to the Disposition-Notification, the UAS MUST
ignore it. If a future extension leverages a value and depends on
the UAS understanding it, the UAC MUST use a Require CPIM header.
4.2.1 Recipient is 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 6.
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 6.
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. They UAS MAY encrypt the
IMDN, knowing the URI of the endpoint requesting the IMDN is in the
Original-From header.
4.2.2 Recipient is 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 "request-URI" action.
Burger Expires January 18, 2006 [Page 11]
Internet-Draft IMDN July 2005
4.2.2.1 request-URI
If the List-Action is "request-URI", 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 6.
o If there was an error processing the message, the B2BUA SHOULD
return an error IMDN, mindful of the privacy considerations
enumerated in Section 6.
The IMDN in this case refers to the UAS part of the B2BUA. Thus
there is no IMDN encapsulation. Signing and encryption are the same
as for a simple UAS.
4.2.2.2 final-recipient
If the List-Action is "final-recipient", then the B2BUA SHOULD
forward the Message-Disposition and List-Action headers to the 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 with an
"expanded" status. In the former case, local policy will decide
whether to return a denied IMDN, expanded IMDN, or not return an IMDN
at all.
NOTE: This is an example of the peril of not having the end system
communicate directly with the Requesting UAC. The end system
knows the policy for returning an IMDN (denied, expanded, ignore).
The situation we have here assumes there is a trust relationship
between the end system and the B2BUA.
When the B2BUA receives an IMDN from the downstream 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.
4.2.2.3 consolidate
If the List-Action is "consolidate", the B2BUA waits a locally
defined time period to collect IMDN responses from the downstream
Burger Expires January 18, 2006 [Page 12]
Internet-Draft IMDN July 2005
UASs. If the time period expires or the B2BUA collects all of the
responses, the B2BUA encapsulates all of the responses and forwards
the responses to the upstream UAC.
5. Format of an IMDN
NOTE: It makes much more sense to have the IMDN document simply be
headers. The current fashion is XML, and bending to fashion, I've
got an XML definition of the IMDN. Of course, it is the elements
that are important; we can work out encoding later. That said,
what is the value of the IMDN being in XML? The argument that a
CPIM endpoint will have an XML parser is not valid. For example,
a gateway does not need an XML parser to operate. However, it
does need a header-colon-value parser. Since we are using CPIM,
we get namespaces for headers, if that is what you wanted to use
XML for. Clearly, this is an object for discussion on the list.
In addition, since the possible values of the data elements are
pretty well-known, we use attributes to the imdn element, rather
than have a bunch of sub-elements. This might be considered
abuse, but it does highlight the point.
Clearly, if it is the will of the group to stick with XML and to
not abuse attributes, I'll fix up the schema.
The root element is <imdn>. The disposition attribute takes the
value described above.
The Reporting UAS MUST include the Message-ID as the value of the
original-message-ID attribute.
The Reporting UAS SHOULD include its URI in the reporting-uas-uri
attribute. One condition where the Reporting UAS will not include
its URI is if it wants to keep its URI private.
If the Reporting UAS is a B2BUA, and the UAS is consolidating or
forwarding a downstream IMDN, the Reporting UAS includes the
forwarded report(s) as the value of the <imdn> tag.
6. Privacy Considerations
As suggested by RFC2298 [4], it is strongly RECOMMENDED that the user
agent obtain the user's consent before sending an IMDN. This consent
could be obtained for each message through some sort of prompt or
dialog box, or globally through the user's setting of a preference.
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.
Recipient systems SHOULD NOT automatically send IMDNs if the URI in
Burger Expires January 18, 2006 [Page 13]
Internet-Draft IMDN July 2005
the Disposition-Notification-To header differs from the address of
the sender. Recipient systems SHOULD use reliable mechanisms for
determining the sender's address, such as from the underlying
transport protocol. Recipient systems SHOULD 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.
7. Security Considerations
All of the security issues raised in RFC2298 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.
To combat eavesdropping, modification, and man-in-the-middle attacks
[ ], one SHOULD consider encrypting IMDNs, as an attacker may attempt
to discern the user's activity profile from sniffing IMDNs on the
network.
Replay and message insertion attacks are unlikely in an IMDN
environment, as the MsgID cannot be identical within a given session.
There is no effective protection for a deletion attack on an IMDN.
Probably the greatest network threat is a denial of service attack.
An attacker may setup a denial of service attack to a third party by
sending lots of messages to many instant message user agents, with
notification requests all being forwarded to the attacked node. This
is why one SHOULD NOT send IMDNs to a user other than the one that
sent the message. Likewise, an attacker could 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.
8. Examples
8.1 Simple End-to-End Read Request
The Happy Path.
8.2 Gateway Endpoint
Happy Path for gateway reporting it forwarded.
Burger Expires January 18, 2006 [Page 14]
Internet-Draft IMDN July 2005
8.3 List Exploder - Forward
Happy Path for forwarding case
8.4 List Exploder - Consolidate
Show Wrapped Responses
8.5 List With Lists
Show wrapped, wrapped responses.
8.6 End-to-End Encryption Forwarded
Gateway scenario where Reporting UAS encrypts IMDN document for read
only by Requesting UAC.
9. Formal Syntax
9.1 IMDN CPIM Request
TODO: collect syntax from above.
Burger Expires January 18, 2006 [Page 15]
Internet-Draft IMDN July 2005
9.2 IMDN Document
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:parms:xml:ns:imdn"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="imdn">
<xs:complexType mixed="true">
<xs:attribute name="disposition" use="required">
<xs:annotation>
<xs:documentation>
The range of disposition is "read", "deleted", "expanded", "error",
or "denied". We do not do a restriction to make it easy to extend
the values in the future.
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="reporting-uas-uri" type="xs:anyURI"
use="optional"/>
<xs:attribute name="original-recipient-uri" type="xs:anyURI"
use="optional"/>
<xs:attribute name="original-message-id" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
</xs:schema>
10. IANA Considerations
TODO
11. References
11.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] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-10 (work in progress),
February 2005.
Burger Expires January 18, 2006 [Page 16]
Internet-Draft IMDN July 2005
[4] Fajman, R., "An Extensible Message Format for Message
Disposition Notifications", RFC 2298, March 1998.
11.2 Informative References
[5] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[6] Jennings, C. and R. Mahy, "Relay Extensions for the Message
Sessions Relay Protocol (MSRP)",
draft-ietf-simple-msrp-relays-04 (work in progress), June 2005.
[7] Hansen, T. and G. Vaudreuil, "Message Disposition Notification",
RFC 3798, May 2004.
[8] Hansen, T., "Message Tracking Model and Requirements", RFC 3888,
September 2004.
[9] 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.
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
Appendix A. Contributors
Appendix B. Acknowledgements
Thanks go to Ben Campbell for continuously prodding me. Thanks also
to Hisham for the relay idea and threating 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 January 18, 2006 [Page 17]
Internet-Draft IMDN July 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 Expires January 18, 2006 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-23 03:27:53 |