Fax Working Group Dan Wing Internet Draft Cisco Systems August 3, 1998 Expires January 1999 draft-ietf-fax-mdn-multipart-01.txt Extensions to Message Disposition Notifications for Reporting on Multipart/Alternative Messages 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. 1. Abstract This document describes how a Message Disposition Notification can be returned which indicates which part(s) of a multipart/ alternative message the recipient processed. 2. Introduction With the proliferation of attachments, it is often useful for a sender to know which attachements were renderable by a recipient. For multipart/alternative, subsequent messages to the same recipient can suppress unnecessary alternatives if the recipient has successfully processed a certain alternative in a previous message exchange. 2.1. Discussion of this Draft This draft is being discussed on the "ietf-fax" mailing list. To subscribe, 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. 3. Extension to Message Disposition Notifications If a sender is interested in knowing which parts of a multipart/alternative message were usable by the recipient's MUA, the sender MUST include the "Disposition-Notification-To" field in the RFC822 headers (as described in [RFC2298]), and MUST include a "Content-ID" field on each part of the multipart/alternative so the recipient can indicate which part of the multipart/alternative was processed. If the recipient's MUA decides to generate a Message Disposition Notification, it may include the additional fields defined below to indicate which part of the multipart/alternative part(s) were processed. 3.1. Deciding when to generate an MDN The recipient's MUA MUST NOT generate an MDN for parts which were not used by the MUA. For example, in a multipart/alternative only one of the parts is displayed or processed; the other parts are not used and are not included in the MDN. Note this differs from a part that failed processing after an attempt to process. If the recipient's MUA attempted to decode a media type it expected to decode, such as an image/gif when the MUA includes an GIF viewer, but the GIF was corrupted, the MUA should generate an MDN indicating that an error occured while processing that part [MDN-ERROR]. If the corrupted part is enclosed in multipart/alternative, the MUA may attempt to process one of the alternatives, which may cause generation of another MDN. XXX - how to prevent generation of multiple MDNs (which is illegal)? 3.2. Original-Content-ID field The Original-Content-ID indicates which part of a multipart/alternative was processed. The syntax for this field, per the format described in [ABNF], is: extension-field = 1*( ocid CRLF ) ocid = "Original-Content-ID" ":" content-id [ error-indicator ] error-indicator = ";" "error" The token is the Content-ID that was specified in the part that was processed by the MUA. Multiple "Original-Content-ID" fields MUST NOT appear except when there were multiple multipart/alternative content-types in the message. A MUA that receives a message with more than one multipart/alterntives content type may wish to indicate a Disposition of "displayed" or "displayed / error" for various reasons. To allow this, the field can indicate which parts of those multipart/alternatives actually failed. The MUST NOT be present unless the original message contained more than one multipart/alternative content-type. Note if the is present it MAY disagree with the "Disposition:" field of the MDN. 4. Security Considerations In addition to the security considerations described in [MDN], this extention provides additional information to the sender. For example, knowledge of the successful or unsuccessful processing of a cryptographically signed message can tell a sender if the recipient is authenticating messages or simply ignoring the cryptographic signature. 5. Examples 5.1. MDN issued after a mesage was successfully processed This is a multipart/alternative message which contains text/plain, text/enriched [ENRICHED], and text/html [MHTML] media types. The sender requested an MDN in the RFC822 headers, and also requested an MDN on each part of the multipart message by providing a Content-ID for each of those parts. Return-Path: Received: from gw.cisco.com by HQ.Cisco.COM with ESMTP; Fri, 5 Dec 1997 14:02:00 -0800 Received: from yoyodyne.com by gw.cisco.com with SMTP; Fri, 5 Dec 1997 14:01:45 -0800 From: Jane Sender To: Joe Recipient Original-Recipient: rfc822;Joe_Recipient@cisco.com Date: Fri, 5 Dec 1997 14:01:23 -0800 Message-ID: <19971205.140123@yoyodyne.com> MIME-Version: 1.0 Disposition-Notification-To: Jane_Sender@yoyodyne.com Content-Type: multipart/alternative; boundary="ABCDEF" --ABCDEF Content-Type: text/plain Content-ID: <12@yoyodyne.com> This is a test --ABCDEF Content-Type: text/enriched Content-ID: <13@yoyodyne.com> This is a test. --ABCDEF Content-Type: text/html Content-ID: <14@yoyodyne.com> red and green colors This is a test. --ABCDEF-- The recipient's MUA selected the text/enriched part for display and sent the following MDN. Date: Fri, 5 Dec 1997 14:03:06 -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 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: <13@yoyodyne.com> --NextPart-- 5.2. Processing failure This examples shows an MDN generated using the same original message as in section 5.1, but the MUA encountered an error while attempting to process the text/html part: Date: Fri, 5 Dec 1997 14:03:06 -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 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 / error Original-Content-ID: <14@yoyodyne.com>; error --NextPart-- 5.3. Multiple Multipart/alternative Content-types This is a multipart/alternative message which contains two multipart/alternatives: text/plain and text/enriched [ENRICHED] text/ascii and application/ms-word The sender requested an MDN in the RFC822 headers, and also requested an MDN on each part of the multipart message by providing a Content-ID for each of those parts. Return-Path: Received: from gw.cisco.com by HQ.Cisco.COM with ESMTP; Fri, 5 Dec 1997 14:02:00 -0800 Received: from yoyodyne.com by gw.cisco.com with SMTP; Fri, 5 Dec 1997 14:01:45 -0800 From: Jane Sender To: Joe Recipient Original-Recipient: rfc822;Joe_Recipient@cisco.com Date: Fri, 5 Dec 1997 14:01:23 -0800 Message-ID: <19971205.140123@yoyodyne.com> MIME-Version: 1.0 Disposition-Notification-To: Jane_Sender@yoyodyne.com Content-Type: multipart/mixed; boundary="ABCDEF" --ABCDEF Content-Type: multipart/alternative; boundary="Part" --Part Content-Type: text/plain Content-ID: <12@yoyodyne.com> Joe, the document you requested is attached in both Microsoft Word and ASCII formats. --Part Content-Type: text/enriched Content-ID: <13@yoyodyne.com> Joe, the document you requested is attached in both Microsoft Word and ASCII formats. --Part-- --ABCDEF-- Content-Type: multipart/alternative; boundary="123" --123 Content-Type: text/plain Content-ID: <14@yoyodyne.com> In the third fiscal year, profits rose 17.5% for the department... --123 Content-Type: application/ms-word Content-ID: <15@yoyodyne.com> Content-Transfer-Encoding: base64 EJKEJFJEKF18923EJFKEFJEKFEFJEKFJEKJFEKJFKEJFEKJFEJKEJFK --123-- --ABCDEF-- The recipient's MUA selected the text/enriched part and the application/ms-word part for processing, but encountered an error while processing the application/ms-word part. The receiver's MUA is MAY wish to indicate "displayed" MDN or "displayed / error" on the "Disposition:" field. Date: Fri, 5 Dec 1997 14:03:06 -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 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: <13@yoyodyne.com> Original-Content-ID: <15@yoyodyne.com>; error --NextPart-- 6. Acknowledgments XXX 7. References [ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [ENRICHED] P. Resnick, A. Walker, "The text/enriched MIME Content-type", RFC 1523, February 1996. [MDN] R. Fajman, "An Extensible Message Format for Message Disposition Notifications", Internet Draft, Work in Progress, draft-ietf-receipt-mdn-XX.txt (soon to be Proposed Standard) [MDN-ERROR] D. Wing, "Format of Message Delivery Notifications to Indicate Processing Errors", Internet Draft, Work in Progress, draft-ietf-XXX-mdn-error-XX.txt. [MHTML] J. Palme, A. Hopmann, "MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2110, March 1997. 9. Copyright Copyright (C) The Internet Society 1997. 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 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. 10. Author's Address 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