One document matched: draft-burger-simple-imdn-00.txt
Network Work Group E. Burger
Internet Draft SnowShore Networks, Inc.
Document: draft-burger-simple-imdn-00.txt
Category: Standards Track February 23, 2003
Expires: August 23, 2003
Instant Message Delivery Notification (IMDN) for
Common Presence and Instant Messaging (CPIM) Messages
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
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 MDN. This document also includes a brief discussion of the
differences between ESMTP and CPIM MDN.
Burger Internet Draft - Expires August 2003 1
IMDN February 2003
Table of Contents
1. Conventions used in this document..................................2
2. Introduction.......................................................2
3. Operation..........................................................3
3.1. Disposition notification Marking (Sender)........................3
3.2. Disposition Notification Processing (Receiver)...................4
3.2.1. Recipient Permission Guidelines (Non-Normative)................4
4. Format of an IMDN..................................................5
4.1. MDN Fields Used in an IMDN.......................................5
4.2. MDN Disposition Field in IMDN....................................5
4.3. MDN Disposition Types in IMDN....................................5
4.4. Extension Fields.................................................6
5. Formal Syntax......................................................6
6. Security Considerations............................................6
7. References.........................................................6
8. Contributors.......................................................7
9. Acknowledgments....................................................7
10. Author's Address..................................................7
1. Conventions used in this document
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 as described
by [1].
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 RFC-2119 [2].
2. Introduction
In most any user-to-user message passing 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 [4] 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. The
Burger Internet Draft - Expires August 2003 2
IMDN February 2003
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 issues that are important to consider. An
appendix to this document enumerates a number of these issues.
This document describes a mechanism that is appropriate for any CPIM
transport mechanism and scenario. The mechanism depends on abstract
CPIM [6] and does not rely on session-mode versus pager-mode or SIP
transport.
3. Operation
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. Disposition notification Marking (Sender)
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's instant
message user agent does not support IMDN, then the instant message
user agent will reject the message. In addition, the instant
message user agent 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
even make this a per-receipt request option. That decision is
entirely outside the scope of this document.
The syntax of the Disposition-Notification-To CPIM header is
Burger Internet Draft - Expires August 2003 3
IMDN February 2003
mdn-request-header = "Disposition-Notification-To" ":" notify-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 message MUST NOT mark the notification
message for IMDN.
3.2. Disposition Notification Processing (Receiver)
The receipt of a CPIM message with a Disposition-Notification-To
CPIM header indicates the request for an IMDN.
The recipient instant message user agent MUST NOT send more than one
IMDN in response to an IMDN request. That is, 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.
A system receiving an instant message disposition notification MUST
NOT generate a message disposition notification in response to the
first notification.
A CPIM message that contains a Disposition-Notification-To header
SHOULD also have a MsgID transport header as specified in [CPIMMSG].
This will permit automatic correlation of MDNs with original
messages by user agents.
3.2.1. Recipient Permission Guidelines (Non-Normative)
As suggested by RFC2298, 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
the Disposition-Notification-To header differs from the address of
the sender. Recipient systems SHOULD use reliable mechanisms for
Burger Internet Draft - Expires August 2003 4
IMDN February 2003
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.
4. Format of an IMDN
The format of an IMDN is identical to the format of a MDN, as
specified by RFC2298. As a CPIM message, the receiver puts the IMDN
in a Message/CPIM wrapper.
4.1. MDN Fields Used in an IMDN
Reporting-UA Same
MDN-Gateway Not Used
Original-Recipient Same, Transport Appropriate
Final-recipient Same
Original-Message-ID Transport Appropriate MsgID
Disposition See 4.2
Disposition Modes Same
Disposition Types See 4.3
Disposition Modifiers Same
Failure, Error and Warning
Same
Extension Fields See 4.4
4.2. MDN Disposition Field in IMDN
Action-mode Same
Sending-mode Same
Disposition-type One of "displayed", "denied", "failed"
Disposition-modifier Same; "mailbox-terminated" for account
Inactive
Disposition-modifier-extension
Same
4.3. MDN Disposition Types in IMDN
Displayed Same
Dispatched Same
Processed Same
Deleted Not Used
Denied Same
Failed Same
Burger Internet Draft - Expires August 2003 5
IMDN February 2003
4.4. Extension Fields
Extension fields SHOULD be registered. The use of "X-" and "x-" is
strongly NOT RECOMMENDED.
5. Formal Syntax
The formal syntax of this mechanism is identical to RFC2298, with
the difference that the target of the Disposition-Notification-To is
a URI, not mailbox.
6. 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
[7], 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.
7. References
1 Atkins, D. and Klyne, G., " Common Presence and Instant
Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-08.txt,
January 9, 2003, work in progress.
Burger Internet Draft - Expires August 2003 6
IMDN February 2003
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
3 Campbell, B., Rosenberg, J., and Peterson, J., "Instant Message
Transport Sessions using the CPIM Message Format", draft-
campbell-simple-cpimmsg-sessions-00, October 25, 2002, work in
progress.
4 RFC2822
5 Fajman, R., "An Extensible Message Format for Message Disposition
Notifications", RFC 2298, March 1998.
6 Crocker, D., et. al., "Common Presence and Instant Messaging
(CPIM)", draft-ietf-impp-cpim-03, August 14, 2002, work in
progress.
7 Rescorla, E. and Korver, B., "Guidelines for Writing RFC Text on
Security Considerations", draft-iab-sec-cons-03.txt, January
2003, work in progress.
8. Contributors
9. Acknowledgments
Thanks go to Robert Sparks for getting me started on this document.
Much of this document is lifted directly from RFC2298, which itself
has RFC1894 as its basis. Thus I stand on the shoulders of Roger
Fajman, Keith Moore, and Greg Vaudrueil. However, I will take full
credit for any errors, omissions, misinterpretations, and the like.
10. Author's Address
Eric Burger
SnowShore Networks, Inc.
285 Billerica Rd.
Chelmsford, MA 01824-4120
USA
Phone: +1 978/367-8400
Email: e.burger@ieee.org
Burger Internet Draft - Expires August 2003 7
IMDN February 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. This
document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS 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.
Acknowledgement
The Internet Society currently provides funding for the RFC Editor
function.
SnowShore Networks, Inc. is a member of the Internet Society.
urger Internet Draft - Expires August 2003 8
| PAFTECH AB 2003-2026 | 2026-04-23 03:50:54 |