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

Differences from draft-ietf-fax-eifax-00.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)
     *  GSTN billing information (Section 5) (optional)
     *  Confidentiality (Section 6) (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 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  EIFax requirements

   This section defines requirements for devices that are to be
   considered EIFax compliant.
   
2.2.1 EIFax Sender Requirements

   An EIFax sender MUST request successful DSN (NOTIFY=SUCCESS) from
   the mail transfer agent to which the message is being submitted, if
   that transfer agent supports DSN.

   An EIFax sender (or, more precisely, the return address supplied by
   the EIFax sender) MUST be prepared to accept and display to the
   sending user the various states of DSN that will be returned,
   including the possibility that the message was relayed to a MTA
   that does not support DSN, as well as receiving a status message
   that is not in DSN format.
   
   An EIFax sender MAY also request MDNs, using the mechanism
   described in Section 2 of [RFC2298].

2.2.2  EIFax Recipient Requirements

   An EIFax message may be received by software compliant with this
   document, or may be received by software that provides fewer
   features such as a legacy MTA or MUA.
   
   An EIFax recipient that acts as a SMTP server MUST support
   [RFC1891]. Other EIFax recipients that perform the function of a
   MTA SHOULD also support the sending of delivery status
   notifications.
   
   All delivery status notifications generated by an EIFax recipient
   MUST be in the format described in [RFC1894].

   An EIFax recipient that performs message disposition SHOULD support
   the return of Message Disposition Notifications [RFC2298] following
   the guidelines for generation of MDNs in that document. While a
   user agent is "free to silently ignore" a request for a message
   disposition notification ([RFC 2298] section 2.1), in the case of
   a network printer which automatically prints messages it receives
   or an offramp gateway which automatically forwards such messages,
   the delivery status "dispatched" combined with disposition mode
   "automatic-action" SHOULD be sent.

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. GSTN Billing Information

   [RFC2305] recommends that an offramp gateway servicing multiple
   mailboxes use SMTP as its protocol.

   To provide billing information for the offramp service back to the
   originator of a message, the offramp gateway SHOULD implement
   [DSN-EXTENSIONS].

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

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

6.2  Connections

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

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

8. References

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

   [DSN-EXTENSIONS] D. Wing. "Extensions to Delivery Status
   Notifications for Fax", Internet Draft, Work in Progress, November,
   1997.
   
   [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.
 
9. 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.
   170 West Tasman Drive
   San Jose, CA 95134-1619
   Phone: +1 408 526 4000
   Fax:   +1 408 457 5208
   EMail: dwing@cisco.com
   
10. 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.