Internet Fax Working Group                                Larry Masinter
Internet Draft                                         Xerox Corporation
October 16, 1998                                                Dan Wing
Expires March 1999                                         Cisco Systems
draft-ietf-fax-eifax-07.txt


                 Extended Facsimile Using Internet Mail

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).

   This draft is a product of the IETF Internet 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.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   This document describes extensions to "Simple Mode of Facsimile Using
   Internet Mail" [RFC2305] and describes additional features, including
   transmission of enhanced document characteristics (higher resolution,
   color) and confirmation of delivery and processing.

   These additional features are designed to provide the highest level
   of interoperability with the existing and future standards-compliant
   email infrastructure and mail user agents, while providing a level of
   service that approximates the level currently enjoyed by fax users.



Masinter, Wing             Expires March 1999                  [Page 1]


Internet Draft           Extended Internet Fax              October 1998



1.  Introduction

   This document notes a number of enhancements to the "Simple Mode of
   Facsimile Using Internet Mail" [RFC2305] that may be combined to
   create an extended mode of facsimile using Internet mail.

   The new features are designed to be interoperable with the existing
   base of mail transfer agents (MTAs) and mail user agents (MUAs),
   and take advantage of existing standards for advanced functionality
   such as positive delivery confirmation and disposition notification.
   The enhancements described in this document utilize the messaging
   infrastructure, where possible, instead of creating fax-specific
   features which are unlikely to be implemented in non-fax messaging
   software.

   This document standardizes two features described in its companion
   document, [GOALS]:

     *  Delivery confirmation (Section 2) (required)
     *  Additional document features (Section 3) (optional)

1.1.  Definition of terms

   The term "processing" indicates the ability to successfully render or
   transmit the contents of the message to a printer, display device, or
   fax machine.

   The term "recipient" indicates the device which performs the
   processing function.  For example, a recipient could be implemented
   as a traditional Mail User Agent on a PC, a standalone device which
   retrieves mail using POP3 or IMAP, an SMTP server which prints
   incoming messages (similar to an LPR server).

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.2.  GSTN Fax Gateways ("onramp"/"offramp")

   The behavior of gateways from GSTN fax to SMTP ("onramps") and from
   SMTP to GSTN fax ("offramps") are not described in this document.
   However, such gateways SHOULD have the behavior characteristics of
   senders and recipients as described in this document.

2.  Delivery and Processing Confirmation

   In traditional GSTN-based realtime facsimile, the receiving terminal



Masinter, Wing             Expires March 1999                  [Page 2]


Internet Draft           Extended Internet Fax              October 1998


   acknowledges successful receipt and processing of every page [T.30].

   In Internet Mail, the operations of Delivery (to the mailbox) and
   Disposition (to paper or a screen) may be separated in time (due to
   store and forwarding of messages) and location (due to separation of
   delivery agent (MTA) and user agent (MUA)).  The confirmation of
   these two operations are supplied by two different standards-track
   mechanisms:  Delivery Status Notifications (DSN) [RFC1891, RFC1894]
   and Message Disposition Notifications (MDN) [RFC2298], respectively.

   This section defines requirements for devices or services that are to
   be considered compliant with this document.

2.1.  Sender Requirements

   A delivery failure message (in the format described by [RFC1894] or
   otherwise) may be sent to the envelope-from address specified by the
   sender.  Thus, the envelope-from address supplied by the sender MUST
   be able to properly handle such delivery failure messages.

2.1.1.  Delivery Confirmation

   If the sender desires delivery confirmation, the sender MUST request
   Delivery Status Notification by including the the esmtp-keyword
   NOTIFY with the esmtp-value SUCCESS [section 5.1 of RFC1891].

2.1.2.  Processing Confirmation

   If the sender desires processing confirmation, the sender MUST
   request Message Disposition Notification using the method described
   in section 2 of [RFC2298].

   Because a recipient may silently ignore a request for an MDN [section
   2.1 of RFC2298] at any time:
     *  MDNs MUST NOT be used for delivery confirmation, but are only
        useful for disposition ("processing") notification.
     *  the sender MUST NOT assume the recipient will respond to an MDN
        request in a subsequent message, even if the recipient has
        done so in the past.

   The address provided by the sender on the Disposition-Notification-To
   field MUST be able to receive Message Disposition Notifications
   messages [RFC2298] and SHOULD be able to receive messages that are
   not in the Message Disposition Notification format (due to the
   existence of legacy systems that generate non-RFC2298-compliant
   responses to the Disposition-Notification-To field).

2.2.   Recipient Requirements



Masinter, Wing             Expires March 1999                  [Page 3]


Internet Draft           Extended Internet Fax              October 1998


   Recipients SHOULD implement Message Disposition Notifications
   [RFC2298] and SHOULD indicate supported media features in
   DSN and MDN messages per [REPORT-EXTENSIONS].

   If the recipient is an SMTP server, it behaves as part of the
   receiver infrastructure and is therefore subject to the "Receiver
   Infrastructure" requirements of this document.

   See also "Recipient Recommendations" in section 5.

2.2.1.  MDN Recipient Requirements

   Recipients MUST be configurable to silently ignore a request for an
   MDN ([section 2.1 of RFC2298]).

   If the recipient is an automated message processing system which is
   not associated with a person, the device MAY be configurable to
   always respond to MDN requests, but in all cases MUST be configurable
   to never generate MDNs.

   A recipient MUST NOT generate an unsolicited MDN to indicate
   successful processing.  A recipient MAY generate an unsolicited MDN
   (sent to the envelope-from (Return-Path:) address) to indicate
   processing failure, but subject to the [RFC2298] requirement that it
   MUST always be possible for an operator to disable unsolicited MDN
   generation.

2.2.2.  Recipients using Mailbox Access Protocols

   A recipient using [POP3] or [IMAP4] to retrieve its mail MUST NOT
   generate a Delivery Status Notification message [RFC1894].

   The recipient MUST NOT use the RFC822 "To:" fields, "Cc:" fields,
   "Bcc:" fields, or any other fields containing header recipient
   information to determine the ultimate destination mailbox or
   addressee, and SHOULD NOT use other RFC822 or MIME fields for making
   such determinations.

2.3.  Messaging Infrastructure Requirements

   This section explains the requirements of the SMTP messaging
   infrastructure used by the sender and receiver.  This infrastructure
   is commonly provided by the ISP or a company's internal mailers but
   can actually be provided by another organization with appropriate
   service contracts.

2.3.1.  Sender Infrastructure




Masinter, Wing             Expires March 1999                  [Page 4]


Internet Draft           Extended Internet Fax              October 1998


   Support for DSN [RFC1891] MUST be provided by the mail submission
   server [SUBMIT] used by the sender and MUST be provided up to the
   mailer responsible for communicating with external (Internet)
   mailers.

   Also see section 5.1 of this document.

2.3.2.  Receiver Infrastructure

   Support for DSN [RFC1891] MUST be provided by the external
   (Internet-accessible) mailer, and MUST be provided by each mailer
   between the external mailer and the recipient.  If the recipient is
   implemented as an SMTP server it MUST also support DSN [RFC1891].

3.  Additional document capabilities

   Section 4 of "A Simple Mode of Facsimile Using Internet Mail"
   [RFC2305] allows sending only the minimum subset of TIFF for
   Facsimile "unless the sender has prior knowledge of other TIFF fields
   or values supported by the recipient."

   If support for any additional feature of TIFF for facsimile, as
   described by "File Format for Internet Fax" [RFC2301], are supported
   by a recipient, the recipient SHOULD indicate support for those
   additional features using the mechanism described in section 3.2 or
   3.3 of this document.

   A sender SHOULD be able to recognize and process the feature
   tags as defined in [FAX-SCHEMA] when reviewing the capabilities
   presented by a potential recipient.  The capability matching rules
   indicated there (by reference to [CONNEG-FEATURE-SYNTAX]) allow for
   the introduction of new features that may be unrecognized by older
   implementations.

   Three methods for the sender to acquire such knowledge are
   permitted:

     1.  Sender manual configuration
     2.  Capabilities in Directory
     3.  Capabilities returned in MDN or DSN

   An implementation may cache capabilities locally and lose
   synchronization with the recipient's actual capabilities.  A
   mechanism should be provided to allow the sender to override the
   locally-stored cache of capabilities.  Also note section 4.1 of this
   document.

3.1.  Sender manual configuration



Masinter, Wing             Expires March 1999                  [Page 5]


Internet Draft           Extended Internet Fax              October 1998


   One way a sender can send a document which exceeds the minimum subset
   allowed by [RFC2305] is for the user controlling the sender to
   manually override the default settings, usually on a per-recipient
   basis.  For example, during transmission a user could indicate the
   recipient is capable of receiving high resolution images or color
   images.

   While awkward and not automatic, this mechanism reflects the current
   state of deployment of configuration for extended capabilities to
   ordinary Internet email users.

3.2.  Capabilities in Directory

   A future direction for enhanced document features is to create a
   directory structure of recipient capabilities, deployed, for example,
   through LDAP or DNS. The directory would provide a mechanism by which
   a sender could determine a recipient's capabilities before message
   construction or transmission, using a directory lookup. Such
   mechanisms are not defined in this document.

   There is active investigation within the IETF to develop a solution
   to this problem, which would resolve a wide range of issues with
   store-and-forward messaging.

3.3.  Capabilities Returned in MDN or DSN

   As outlined in section 2 of this document, a sender may request a
   positive DSN or an MDN.

   If the recipient implements [REPORT-EXTENSIONS], the DSN or MDN that
   is returned can contain information describing the recipient's
   capabilities.  The sender can use this information for subsequent
   communications with that recipient.

   The advantage of this approach is that additional infrastructure is
   not required (unlike section 3.2), and the information is acquired
   automatically (unlike section 3.1).

4. Security Considerations

   As this document is an extension of [RFC2305], the Security
   Considerations section of [RFC2305] applies to this document.

   The following additional security considerations are introduced by
   the new features described in this document.

4.1.  Inaccurate Capabilities Information




Masinter, Wing             Expires March 1999                  [Page 6]


Internet Draft           Extended Internet Fax              October 1998


   Inaccurate capability information (section 3) could cause a denial of
   service.  The capability information could be inaccurate due to many
   reasons, including compromised or improperly configured directory
   server, improper manual configuration of sender, compromised DNS, or
   spoofed MDN.  If a sender is using cached capability information,
   there SHOULD be a mechanism to allow the cached information to be
   ignored or overridden if necessary.

4.2.  Forged MDNs or DSNs

   Forged DSNs or MDNs, as described in [RFC1892, RFC1894, RFC2298]
   can provide incorrect information to a sender.

5.  Implementation Notes

   This section contains notes to implementors.

5.1.  Submit mailer does not support DSN

   In some installations the generally available submit server may not
   support DSNs.  In such circumstances, it may be useful for the sender
   to implement [RFC974] mail routing as well as additional submission
   server functions [SUBMIT] so that the installation is not constrained
   by limitations of the incumbent submission server.

5.2.  Recipient Recommendations

   To provide a high degree of reliability, it is desirable for
   the sender to know that a recipient could not process a message.
   The inability to successfully process a message may be detectable
   by the recipient's MTA or MUA.

   If the recipient's MTA determines the message cannot be processed,
   the recipient's MTA is strongly encouraged to reject the message with
   a [RFC1893] status code of 5.6.1.  This status code may be returned
   in response to the end-of-mail-data indicator if the MTA supports
   reporting of enhanced error codes [RFC2034], or after message
   reception by generating a delivery failure DSN ("bounce").

   Note:  Providing this functionality in the MTA, via either of the
          two mechanisms described above, is superior to providing the
          function using MDNs because MDNs must be requested by the
          sender (and the request may, at any time, be ignored by
          the receiver).  Message rejection performed by the MTA can
          always occur without the sender requesting such behavior
          and without the receiver circumventing the behavior.

   If the message contains an MDN request and the recipient's MUA



Masinter, Wing             Expires March 1999                  [Page 7]


Internet Draft           Extended Internet Fax              October 1998


   determines the message cannot be processed, the recipient's MUA is
   strongly encouraged to repond to an MDN request and indicate that
   processing failed with the disposition-type "processed" or
   "displayed" and disposition-modifier "error" or "warning" [RFC2298].

6.  Acknowledgements

   The authors would like to acknowledge the members of the IETF
   Internet Fax working group, and especially the following contributors
   who provided assistance and input during the development of this
   document:  Vivian Cancio, Richard Coles, David Crocker, Ned Freed,
   Graham Klyne, MAEDA Toru, Geoff Marshall, Keith Moore, George Pajari,
   James Rafferty, Mike Ruhl, Richard Shockey, Brian Stafford, and
   Greg Vaudreuil.

7.  References

   [CONNEG-FEATURE-SYNTAX] G. Klyne, "A syntax for describing media
   feature sets", Internet Draft, Work in Progress,
   draft-ietf-conneg-feature-syntax-XX.txt.

   [FAX-SCHEMA] L. McIntyre, G. Klyne, "Content feature schema for
   Internet fax", Internet Draft, Work in Progress,
   draft-ietf-fax-feature-schema-XX.txt.

   [GOALS] L. Masinter, "Terminology and Goals for Internet Fax",
   Internet Draft, Work in Progress, draft-ietf-fax-goals-XX.txt,
   LAST CALL.

   [REPORT-EXTENSIONS] D. Wing, "Offramp Gateway Extensions to DSN and
   MDN", Internet Draft, Work in Progress,
   draft-ietf-fax-reporting-extensions-XX.txt.

   [RFC1891] K. Moore, "SMTP Service Extensions for Delivery Status
   Notifications", RFC 1891, January 1996.

   [RFC1893bis] G. Vaudreuil, "Enhanced Mail System Status Codes",
   Internet Draft, Work in Progress, (update to RFC 1893).

   [RFC1894] K. Moore, G. Vaudreuil, "An Extensible Message Format for
   Delivery Status Notifications", RFC 1894, January 1996.

   [RFC2034] N. Freed, "SMTP Service Extension for Returning Enhanced
   Error Codes", RFC 2034, October 1996.

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, March 1997.




Masinter, Wing             Expires March 1999                  [Page 8]


Internet Draft           Extended Internet Fax              October 1998


   [RFC2298] R. Fajman, "An Extensible Message Format for Message
   Disposition Notifications", RFC 2298, March 1998.

   [RFC2301] L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons,
   J. Rafferty, "File Format for Internet Fax", RFC 2301, March 1998.

   [RFC2305] K. Toyoda, H. Ohno, J. Murai, D. Wing, "A Simple Mode of
   Facsimile Using Internet Mail", RFC 2305, March 1998.

   [RFC974] C. Partridge. "Mail routing and the domain system", RFC 974,
   January 1986.

   [SUBMIT] R. Gellens, J. Klensin, "Message Submission", Internet
   Draft, Work in Progress, draft-gellens-submit-XX.txt.

8. Authors' Addresses

   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


   Dan Wing
   Cisco Systems, Inc.
   101 Cooper Street
   Santa Cruz, CA 95060  USA

   Phone:  +1 831 457 5200
   Fax:    +1 831 457 5208
   EMail:  dwing@cisco.com

9. 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 implementation 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



Masinter, Wing             Expires March 1999                  [Page 9]


Internet Draft           Extended Internet Fax              October 1998


   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.





































Masinter, Wing             Expires March 1999                 [Page 10]