Applications Area Dan Wing Internet Draft Cisco Systems February 27, 1998 Larry Masinter Expires August 1998 Xerox Corporation Using Message Disposition Notifications to Indicate Supported Features draft-ietf-fax-mdn-features-00.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 Message Disposition Notifications [MDN] is used to send the supported features of a user's Mail User Agent. The original sender can use this information to send enhanced messages to the recipient. Features might indicate which formats the Mail User Agent can present to the user as MIME types, or finer gradations of features such as resolution or maximum image size. Features are registered using the framework described in [FEATURES]. 1. Introduction In any open email environment, such as the Internet, it is impossible Wing, Masinter Expires August 1998 [Page 1] Internet Draft MDNs for Features February 1998 to know, a priori, if a recipient will be able to process certain messages. Because of this, only 7-bit text/plain messages is assumed to be readable by any mail user agents (both MIME-aware and non-MIME-aware). 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 capabilities. 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]. Disposition notifications are a function of mail user agents, and do not require deployment or support of new infrastructure (such as LDAP servers) or extensions to SMTP. 1.1. Discussion of this Draft This draft is being discussed on the "ietf-medfree" mailing list, which is for the IETF's Conneg (Content Negotiation) Working Group. To subscribe, send a message to ietf-medfree-request@imc.org with the line "subscribe" in the body of the message. Archives are available from http://www.imc.org/ietf-medfree. 2. Determining Supported Features Any request for a disposition notification [MDN] can also cause capabilities information 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 notification message per [MDN] it can include the new field described below in the disposition notification message. To indicate capabilities, the receiving user agent includes the following new extension field [MDN]. The syntax of this new field, using the Augmented BNF of Wing, Masinter Expires August 1998 [Page 2] Internet Draft MDNs for Features February 1998 [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 can cache the ; capabilities information seconds = 1*DIGIT feature = 3. Processing of Capability Information 3.1. TTL value The TTL value indicates the maximum number of seconds the receiving system is permitted to use the capabilities information, which is calculated from the Date: header of the disposition notification message. The receiving system may minimize and maximize this value within reason. The receiving system is encouraged to update capabilities information (and its associated TTL) whenever new capabilities are obtained. 3.2. Unlisted features If a sender 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, sender SHOULD NOT send the message. For example, if the following features are cached: web=mozilla4; tiff=f and the sender wishes to send application/acrobat (which is not supported by either of the above features), the sender SHOULD inform the user that the recipient may not be able to process the message and allow the user to send a message which can be processed. 3.3. Unknown capabilities If the TTL (section 3.1) has expired, or no capabilites information for the recipient is available, the sender can make no assumptions Wing, Masinter Expires August 1998 [Page 3] Internet Draft MDNs for Features February 1998 about the recipient's capabilities. In this case, the sender should send a message that has a reasonable chance of being processed by a recipient. This minimum will likely 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. Macro Viruses 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. Examples 5.1. MDN with Capabilities included This example shows an MDN with the new "Features" field included. Date: Fri, 5 Dec 1997 14:03:06 (PST) -0800 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 Wing, Masinter Expires August 1998 [Page 4] Internet Draft MDNs for Features February 1998 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=f; microsoft=word5,word95,excel --NextPart Content-Type: message/rfc822 [original message goes here] --NextPart-- 6. Acknowledgments XXX 7. 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) [RFC2045] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. 8. 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 August 1998 [Page 5] Internet Draft MDNs for Features February 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. 9. 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 Wing, Masinter Expires August 1998 [Page 6]