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

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

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 <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]