Applications Area Dan Wing
Internet Draft Cisco Systems
March 10, 1998 Larry Masinter
Expires August 1998 Xerox Corporation
Using Message Disposition Notifications to
Indicate Supported Features
draft-ietf-fax-mdn-features-01.txt
Status of this memo
This document is an Internet-Draft. 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."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
This document describes how Message Disposition Notifications [MDN]
are used to indicate the supported features of a user's Mail User
Agent (MUA). Knowing the supported features of a recipient or the
recipient's MUA allows a sender to generate messages which take
advantage of those features.
Features indicate the MIME content-types are supported by the
Mail User Agent, or finer gradations of features such as
resolution, maximum image size, or software version number.
The representation of features is still under discussion in
the CONNEG working group.
Features are registered using the framework described in [FEATURES].
Wing, Masinter Expires September 1998 [Page 1]
Internet Draft MDNs for Features March 1998
1. Introduction
In an open email environment, such as the Internet, it is not generally
possible to know, a priori, if a recipient will be able to process
certain enhanced forms of a message. Because of this, only 7-bit
text/plain messages can be assumed to be readable by unknown Internet
mail user agents. Even with MIME-aware user agents, some messages
are still not usable by some recipients (for example, a viewer or
a decryption package may be necessary).
Currently, the only method available to indicate the ability
to receive certain file formats is for a human to indicate
this ability out-of-band ("Yes, I can receive PowerPoint"
in an email message or telephone call). Likewise, the only method
available to indicate inability to process a certain file is via a
similar manual method.
Message Disposition Notifications (MDNs) can be used to automate the
sending of recipient features. As most people communicate often
with co-workers, vendors, and collegues, constant exchange of
messages already occurs.
Message Disposition Notifications (MDNs) can be used to exchange
information between mail user agents. This information can indicate
user and system preferences and features, as described in [FEATURES].
Because disposition notifications are communicated end-to-end, they
do not require new infrastructure in the email environment that are
required by other methods of communicating recipient features such as
white page directory entries or SMTP extensions.
1.1. Discussion of this Draft
This draft is being discussed by the IETF FAX working group. To
subscribe to the mailing list, send a message to
ietf-fax-request@imc.org with the line "subscribe" in the body of the
message. Archives are available from http://www.imc.org/ietf-fax.
2. Determining Supported Features
Any request for a disposition notification [MDN] can also cause a
list of features to be sent in that same disposition notification
message.
2.1. Including Features in MDNs
If the receiving user agent decides to send a disposition
Wing, Masinter Expires September 1998 [Page 2]
Internet Draft MDNs for Features March 1998
notification message per [MDN] it can include the new field described
below in the disposition notification message.
To indicate features, the receiving user agent includes the
following new <disposition-notification-content> extension field
[MDN]. The syntax of this new field, using the Augmented BNF of
[ABNF], is:
extension-field = "Features" ":" ttl-value ";"
feature
*( "," [ LWSP ] feature )
ttl-value = seconds ; maximum number of seconds from
; Date: header of this message
; that receiver should believe
; the feature information is
; still accurate
seconds = 1*DIGIT
feature = <as described in [FEATURE]>
Long headers should be folded [RFC822, section 3.1.1].
3. Processing of Feature Information
3.1. TTL value
The TTL value indicates the maximum number of seconds the receiving
system can expect the list of features to be valid. The TTL value is
calculated from the Date: header of the disposition notification
message.
To avoid caching features for excessively long or short periods, the
receiving system may minimize or maximize the TTL value. On a
production system, a lower bound of 5 minutes and an upper bound on
one week would be reasonable.
The receiving system SHOULD update feature information and the
associated TTL whenever new features are obtained.
Originating mail user agents may wish to use expired feature
information, but are encouraged to follow the recommendations
in section 3.3.
3.2. Unlisted features
Wing, Masinter Expires September 1998 [Page 3]
Internet Draft MDNs for Features March 1998
If a sender's mail user agent has cached the features of a certain
recipient, and wishes to send a message which exceeds the
previously-cached list of features for the recipient, originating
mail user agent SHOULD send the message only after informing the
user.
For example, if the following features are cached:
web=mozilla4; tiff=f
and the sender wishes to send application/pdf (which is not
supported by either of the above features), the originating mail user
agent would inform the user that the recipient may not be able to
process the message. A sophisticated mail user agent may
follow the recommendations in section 3.3.
3.3. Unknown Features
If no feature information for a recipient is available, the sender
should send a message that has a reasonable chance of being processed
by a recipient, or send a multipart/alternative message containing
"dumbed-down" versions of the same content.
A message that has a "reasonable chance" should be user configurable,
as what is "reasonable" is dependant on the user's experience,
knowledge of the recipient's software or recipient user's expertise,
and other factors.
4. Security Considerations
In addition to the security considerations discussed in [MDN],
this memo creates other security risks, listed below.
4.1. Disclosure of Preferences
In many cases it is undesirable to disclose certain preferences
for things such as language or accessibility. XXX - more verbage
4.2. Spoofed Feature Information
During the design of mail user agents, it should be remembered
that the cached feature information could be incorrect
due to a malicious MDN. Because of this, the user should be provided
with a mechanism to send a message which exceeds the recipient's
cached features.
4.3. Macro Viruses
Wing, Masinter Expires September 1998 [Page 4]
Internet Draft MDNs for Features March 1998
Macro Viruses [reference?] are a widespread problem among
applications such as word processors and spreadsheets. Knowing which
featuers a user's Mail User Agent supports can assist in a malicious
attack. However, such viruses can be spread easily without such
knowledge by sending multiple messages, and each message infects a
specific application version.
5. Acknowledgments
Thanks to the members of the IETF FAX and CONNEG Working Groups, and
especially to Graham Klyne (Integralis) for their assistance with
the developement of this document.
6. References
[ABNF] Crocker, D., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[FEATURES] IETF Conneg WG, Work in Progress.
[MEDIA-FEATURES] Masinter, L., Holtman, K., and D. Wing, "Media
Features for Display, Print, and Fax", Work in Progress,
Internet Draft, draft-masinter-media-features-02.txt.
[MDN] Fajman, R., "An Extensible Message Format for Message
Disposition Notifications", Work in Progress, Internet Draft,
draft-ietf-receipt-mdn-XX.txt (soon to be Proposed Standard).
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", RFC 822, STD 11, August 1982.
[RFC2045] Freed, N., and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
7. Copyright
Copyright (C) The Internet Society 1998. 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 implmentation 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
Wing, Masinter Expires September 1998 [Page 5]
Internet Draft MDNs for Features March 1998
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.
8. Authors' Addresses
Dan Wing
Cisco Systems, Inc.
101 Cooper Street
Santa Cruz, CA 95060 USA
Phone: +1 408 457 5200
Fax: +1 408 457 5208
EMail: dwing@cisco.com
Larry Masinter
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA 94304 USA
Fax: +1 415 812 4333
EMail: masinter@parc.xerox.com
A. Examples
A.1. MDN with Features Included
This example shows an MDN with the new "Features" field
included.
Date: Fri, 5 Dec 1997 14:03:06 (PST) -0800
Wing, Masinter Expires September 1998 [Page 6]
Internet Draft MDNs for Features March 1998
From: Joe Recipient <Joe_Recipient@hq.cisco.com>>
Message-Id: <19971205.14030618@hq.cisco.com>
Subject: Disposition notification
To: Jane Sender <Jane_Sender@yoyodyne.com>
MIME-Version: 1.0
Content-Type: multipart/report; boundary="NextPart";
report-type=disposition-notification;
--NextPart
Your message sent on Friday, 5 Dec 1997 at 14:00 to
Joe Recipient <Joe_Recipient@hq.cisco.com> with the subject
"Hello there" has been displayed. This is no guarantee
that the message has been read or understood.
--NextPart
Content-Type: message/disposition-notification
Reporting-UA: hq.cisco.com; MultiNet
Original-Recipient: rfc822;Joe_Recipient@cisco.com
Final-Recipient: rfc822;Joe_Recipient@hq.cisco.com
Original-Message-ID: <19971205.140123@yoyodyne.com>
Disposition: manual-action/MDN-sent-manually; displayed
Original-Content-ID: <19971205.140000.813@yoyodyne.com>
Features: web=mozilla4; tiff=faxbw; microsoft=word5,word95,excel
--NextPart
Content-Type: message/rfc822
[original message goes here]
--NextPart--
Wing, Masinter Expires September 1998 [Page 7]
