One document matched: draft-ietf-fax-eifax-02.txt

Differences from draft-ietf-fax-eifax-01.txt

Fax Working Group                                         Larry Masinter
Internet Draft                                         Xerox Corporation
August 3, 1998                                                  Dan Wing
Expires January 1999                                       Cisco Systems
draft-ietf-fax-eifax-02.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 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.

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] to accomplish additional features,
   including transmission of enhanced document characteristics (higher
   resolution, color), confirmation of delivery, quick message
   delivery, GSTN billing information, and message confidentiality.
   
   Note: some features in this Internet Draft are being actively
   discussed in the Internet Fax working group and amongst experts in
   both facsimile and email. This document does not represent a final
   consensus of the working group, but is offered as a probable
   resolution of those discussions, based on current directions, as
   the proposals are believed to be consistent with the goals of
   Internet Fax as well as current standards-track directions for
   email protocols.

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.

   To promote interoperability, 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 standards-track
   mechanisms for positive delivery and disposition notifications.
   Thus, 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 describes a protocol suite that satisfies all of the
   required and highly desirable features identified in [GOALS]:

     *  Delivery confirmation (Section 2) (required)
     *  Additional document features (Section 3) (optional)
     *  Quick delivery and confirmation (Section 4) (optional)
     *  Confidentiality (Section 5) (optional)

   A device which supports all of these recommendations is called an
   EIFax (Extended Internet Fax) device.

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

2.  Delivery and Processing Confirmation

2.1.  Background
   
   This section explains the background of delivery confirmation for
   facsimile and Internet mail as a justification for the protocol
   requirements made in section 2.2.

   In traditional facsimile, the sending terminal receives a
   confirmation when the receiving terminal has finished processing
   the incoming fax.
   
   In Internet Mail, the operations of Delivery (to the mailbox) and
   Disposition (to paper or a screen) may be separated in time and
   location.  The confirmation of these two operations are supplied by
   two different standards-track documents, Delivery Status
   Notifications (DSN) [RFC1891, RFC1894] and Message Disposition
   Notifications (MDN) [RFC2298] respectively.
   
   a) how they are requested:
     Delivery status notifications are requested within the SMTP
     protocol using SMTP extensions [RFC1891], while disposition
     notifications are requested by including a
     Disposition-Notification-To header in the message.

   b) when they are reported:
     Delivery status is reported when a message is delivered to some
     repository or end-point under the control of the recipient.
     Disposition notification (MDN) is provided when the message is
     disposed of by the recipient user, either manually or
     automatically.
   
   c) which agent reports them:
     Delivery status is reported by the mail transport mechanism, while
     disposition is reported by the end mail user agent.

   d) what form the reports take:
     Both DSNs and MDNs are sent in a "multipart/report". DSNs use
     "report-type=delivery-status"; MDNs use
     "report-type=disposition-notification".
   
   e) the requirement for notification:
     The standards for MDNs and DSNs differ on the requirement for
     automatically generating them.  The generation of MDNs by any
     recipient is entirely optional, and thus no sender can rely on
     obtaining a MDN from an arbitrary recipient. The generation of some
     kind of DSN (if only a 'relayed' message) is required and a
     standard part of MTA operation.
   
2.2.  Confirmation Requirements 

   This section defines requirements for devices or services that are to
   be considered compliant with the delivery and processing confirmation
   section of this memo.
   
2.2.1.  EIFax Sender Requirements

2.2.1.1.  Delivery Confirmation

   If the sender wishes to receive a delivery confirmation or an
   indication that delivery confirmation is not possible, an EIFax
   sender MUST request a DSN [RFC1891] from its mail submission server
   (MTA) using the RCPT command with the esmtp-keyword NOTIFY and
   including esmtp-keyword SUCCESS.  Other esmtp-keywords such as
   DELAY and FAILURE may also be requested if the sender wishes
   to receive notification of delivery delays or delivery failures).
   
   The envelope-from address provided by the EIFax sender MUST be able
   to receive all types of Delivery Status Notifications [RFC1894] and
   be able to receive delivery failure or delayed delivery message that
   are not in the Delivery Status Notification format [RFC1894].
   
2.2.1.2.  Processing Confirmation

   If an EIFax sender wishes to receive processing confirmation
   and the final recipient is a Mail User Agent, the EIFax sender 
   MUST request an MDN [RFC2298].

   If an EIFax sender wishes to receive processing confirmation
   and the final recipient is a fax offramp implemented as an
   MTA, the fax offramp will generate processing confirmation
   in the absense of an MDN request, so an MDN request is not
   necessary.
   
   If an EIFax sender wishes to receive processing confirmation
   and is unaware of the recipient's implementation, the EIFax sender
   SHOULD request an MDN.
      
   NOTE:  Because a request for an MDN can be silently ignored [section
          2.1 of RFC2298], MDNs MUST NOT be used for delivery
          confirmation, but only be used for confirmation a message was
          processed.
          
   NOTE:  Receipt of an MDN MUST NOT be construed as any indication that
          an MDN will be sent in response to another message requesting
          an MDN.

   The address provided by the EIFax sender on the
   Disposition-Notification-To field MUST be able to receive Message
   Disposition Notifications messages [RFC2298] and be able to receive
   messages that are not in the Message Disposition Notification format
   (due to the existance of legacy systems that utilize the same header
   but do not generate RFC2298-compliant responses).

2.2.2.   EIFax Recipient Requirements

   All EIFax recipients SHOULD implement MDN [RFC2298], and SHOULD
   implement Fax Extensions for DSN and MDN [REPORT-EXTENSIONS],
   and MUST be configurable to silently ignore a request for an MDN
   ([section 2.1 of RFC2298]).

2.2.2.1.  Fax Offramp Requirements

   A "Fax Offramp" is defined as a device that obtains a message
   and connect to a fax machine, communicates using the fax protocol to
   that fax machine, and transmits the message to that fax machine.

2.2.2.1.1.  Fax Offramps Implemented as SMTP Servers

   MUST implement Delivery Status Notifications [RFC1891 through
   RFC1894], and SHOULD implement Fax Extensions for DSN and MDN
   [REPORT-EXTENSIONS].
   
   If a successful DSN was requested and an MDN was requested, the MDN
   SHOULD NOT be sent -- only the DSN needs to be sent.
   
   The offramp MUST NOT use anything but the RFC821 envelope-to field to
   make any decision about the actual telephone number to dial.

2.2.2.1.2.  Fax Offramps Implemented as POP/IMAP Clients

   MUST NOT generate a Delivery Status Notification message [RFC1894].
   
   The offramp MUST NOT use anything but the POP/IMAP username to map to
   a single telephone number.  For example, it MUST NOT use any RFC822
   field or information within the message body or MIME parts to make
   any decision about the telephone number to dial.
   
2.2.3.  EIFax Messaging Infrastructure Requirements

   This section explains the requirements of the SMTP messaging
   infrastructure used by the EIFax 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.2.3.1.  Sender Infrastructure 

   Support for DSN [RFC1891] MUST be provided by the mail submission
   server used by the EIFax sender, and SHOULD/MUST (?) be provided up
   to the mailer responsible for communicating with external (Internet)
   mailers.
   
2.2.3.2.  Receiver Infrastructure 

   Support for DSN [RFC1891] SHOULD/MUST (?) be provided by the external
   (Internet-accessible) mailer, and SHOULD/MUST (?) be provided by each
   mailer between the external mailer and the EIFax recipient.


3. Additional document capabilities

   Section 4 of [RFC2305] only allows sending the minimum subset
   of TIFF for Facsimile "unless the sender has prior knowledge
   of otehr TIFF fields or values supported by the recipient."
   
   Various methods for the sender to aquire such knowledge have
   been proposed:
   
     1.  Sender manual configuration
     2.  Message Disposition Notification Extension
     3.  Capabilities in Directory

3.1 Sender manual configuration

   One way a sender can send a document which exceeds the minimum
   subset allowed by [RFC 2305] is for the user controlling the sender
   to manually override the default settings, at least for particular
   recipients.
   
   If there were well-known configurations with combined capabilities,
   those capabilities could be described in the sender's user
   interface. For example, a vendor or trade association could create
   a profile of recipient capabilities that would describe an extended
   set of TIFF features and image sizes, and then the sender could
   manually be configured to send such files if the user controlling
   the sender knows of the recipient capabilities.

   For example, a trade association could create a profile named
   "SuperInterFax", which would signify the ability to accept TIFF
   profiles M, P, and F and any TIFF resolution and media size.
   With this profile, a user could manually decide to send a
   "SuperInterFax" to an address that was advertised to accept
   this profile.

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

3.2 Message Disposition Notification Extension

   As outlined in section 2.2.1, an EIFax sender MAY request a Message
   Disposition Notification.
   
   If the recipient supports responding to such a message, and the
   recipient authorizes responding to the MDN request, the recipient's
   MDN MAY contain information describing the recipient's capabilities
   as described in [MDN-FEATURES].
 
   EIFax senders MAY retain a local cache of information about the
   features supported by recipients.  When an EIFax device sends a
   message to a specific recipient, it MAY use cached information to
   determine the recipient's capabilities to handle extended document
   features such as defined in [MDN-FEATURES].

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

4. Quick Delivery and Confirmation

   [SESSION] describes a method by which delivery confirmation may be
   delivered quickly if there is a direct connection between sender
   and recipient. EIFax devices SHOULD implement
   [SESSION]. Intermediate MTAs, e.g., as part of firewalls, MAY also
   act as [SESSION] gateways, allowing for immediate delivery, with
   fallback to store-and-forward.
   
   EIFax devices MAY implement standard Internet mail routing using
   the domain name system [RFC974]. EIFax devices MAY be SMTP
   recipients registered as the primary mail exchanger for their
   domain.  This combination will allow the sending EIFax device to
   communicate directly with the recipient device.

5. Security

   Many uses of Internet Fax require greater security; the requirements
   for security are discussed in [GOALS]. EIFax supports security by
   providing for secured content and connections.
   
5.1  Content

   To secure the contents of the message itself, EIFax devices SHOULD
   implement S/MIME [SMIME] or PGP-MIME [PGPMIME] or both; these
   systems are based on the security framework for MIME [MIME-SECURE].

5.1.1 Authentication
 
   EIFax devices SHOULD use the multipart/signed MIME type using
   S/MIME or PGP-MIME signed messages. An EIFax SHOULD sign each
   message with the identity of the originating user or with the
   identity of the originating machine or service. An EIFax sender MAY
   choose its method of signing a message. An EIFax recipient SHOULD
   verify the signature of all received messages and indicate in any
   particular way whether the message is unsigned, signed with an
   unverifiable signature, signed with a signature that does not
   verify, or signed with a verified signature.
   
5.1.2 Privacy

   Using the methods of [MIME-SECURE], an EIFax device MAY use either
   S/MIME [SMIME] or PGP-MIME [PGPMIME] to envelope the content of a
   document. Enveloping MAY be applied either before or after signing.

   Enveloped data should only be sent if the recipient's capability to
   decode the enveloped data is known. 

5.2  Connections

   To secure the connection itself, including the envelope itself, EIFax
   devices should implement [AUTH] or IPSsec [IPSEC].

5.3 When to use security

   The capability to perform secure transfer is discovered by a sender
   either through a manual process or by discovering the public key of
   the recipient. Senders may unilaterally send multipart/signed
   documents using the signature method of their choice.
   
6. Security considerations

   [RFC2305] describes the security environment of facsimile and the
   considerations. This memo extends the requirements of RFC 2305 to
   specifically recommend the use of both PGP and S/MIME.
   
   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, it SHOULD be manually confirmed by a user
   before it is automatically used.

7.  Implementation Notes

7.1  POP Clients and Message Disposition Notifications

   If multiple POP clients are accessing the same mailbox the POP
   clients MUST be configurable to leave mail on server (LMOS).  This is
   because the MDN specification permits only one response [section 2.1,
   RFC2298], and beacuse POP doesn't include a mechanism to indicate if
   an MDN has already been generated by a POP client.
   
8.  Acknowledgements

   The authors would like to acknowledge the following contributors
   to this specification, in alphabetical order:
   
     Vivian Cancio, Xerox
     David Crocker, Brandenburg Consulting
     Ned Freed, Innosoft
     Graham Klyne, Integralis Ltd.
     Geoff Marshall, ___
     Keith Moore, University of Tennessee
     George Pajari, Faximum Software Inc.
     James Rafferty, Human Communications
     Richard Shockey, ___
     Brian Stafford, Office Logic
     Maeda Toru, Canon
     

9.  References

   [AUTH] J. Myers, "SMTP Service Extension for Authentication",
   draft-myers-smtp-auth-11.txt, Internet Draft, Work in Progress,
   February 1998.

   [REPORT-EXTENSIONS] D. Wing, "Fax Extensions to DSN and MDN" Internet
   Draft, Work in Progress, draft-ietf-fax-report-extensions.txt.
   
   [MDN-FEATURES] L. Masinter and D. Wing, "Using Message Disposition
   Notifications to Indicate Supported Features", Internet Draft, Work
   in Progress, draft-ietf-fax-mdn-features-01.txt, March 1998.

   [MEDIA] "Media Features for Display, Print, and Fax", L. Masinter, K.
   Holtman, A. Mutz, D. Wing, Internet Draft, Work in Progress,
   draft-ietf-conneg-media-features-00.txt, March 1998.
   
   [FEATURES] K. Holtman, A. Mutz, T. Hardie, "Feature Tag Registration
   Procedures", Internet Draft, Work in Progress,
   draft-ietf-conneg-feature-reg-00.txt, March 1998.
 
   [GOALS] L. Masinter, "Terminology and Goals for Internet Fax",
   Internet Draft, Work in Progress, draft-ietf-fax-goals-02.txt, March
   1998.
 
   [RFC1825] R. Atkinson, "Security Architecture for the Internet
   Protocol", RFC 1825, Naval Research Laboratory, August 1995.

   [RFC1847] "Security Multiparts for MIME: Multipart/Signed and
   Multipart/Encrypted", RFC 1847, October 1995.

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

   [RFC1894] K. Moore, G. Vaudreuil, "An Extensible Message Format for
   Delivery Status Notifications", RFC 1894, January 1996
 
   [RFC2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)",
   RFC2015, October 1996.

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, March 1997.
 
   [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.

   [SESSION] N. Joffe, D. Wing, L. Masinter, "SMTP Service Extension for
   Immediate Delivery", Internet Draft, Work in Progress,
   draft-ietf-fax-smtp-session-02.txt, Feb 1998.

   [SMIME] B. Ramsdell. "S/MIME Version 3 Message Specification",
   Internet Draft, Work in Progress, draft-ietf-smime-msg-04.txt, May
   1998.
 

10. 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
   Phone: +1 408 457 5200
   Fax:   +1 408 457 5208
   EMail: dwing@cisco.com

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