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 view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (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 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 = 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 > Message-Id: <19971205.14030618@hq.cisco.com> Subject: Disposition notification To: Jane Sender 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 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]