One document matched: draft-ietf-fax-mdn-multipart-01.txt

Differences from draft-ietf-fax-mdn-multipart-00.txt

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 <content-id> 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 <ocid> field can indicate which parts of those
   multipart/alternatives actually failed.  The <error-indicator> MUST
   NOT be present unless the original message contained more than one
   multipart/alternative content-type.  Note if the <error-indicator> 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: <Jane_Sender@yoyodyne.com>
     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 <Jane_Sender@yoyodyne.com>
     To: Joe Recipient <Joe_Recipient@cisco.com>
     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 <bold>test</bold>.
     
     --ABCDEF
     Content-Type: text/html
     Content-ID: <14@yoyodyne.com>
     
     <IMG SRC="/images/redgreen.gif" ALT="red and green colors">
     This is a <bold>test</bold>.
     
     --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 <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: <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 <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 / 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: <Jane_Sender@yoyodyne.com>
     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 <Jane_Sender@yoyodyne.com>
     To: Joe Recipient <Joe_Recipient@cisco.com>
     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
     <italics>Microsoft Word</italics> 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 <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: <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