Internet Fax Working Group Larry Masinter Internet Draft Xerox Corporation October 6, 1998 Dan Wing Expires March 1999 Cisco Systems draft-ietf-fax-eifax-06.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 provides 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 in compliance with this document SHOULD implement MDN [RFC2298], and SHOULD implement Offramp Gateway Extensions for DSN and MDN [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:" field 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 Support for DSN [RFC1891] MUST be provided by the mail submission server [SUBMIT] used by the sender and MUST be provided up to the Masinter, Wing Expires March 1999 [Page 4]
Internet Draft Extended Internet Fax October 1998 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 [RFC2305] only 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." A recipient SHOULD indicate which features and values from among those available in [FAX-SCHEMA] are supported using one of the mechanisms defined below. 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 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. Masinter, Wing Expires March 1999 [Page 5]
Internet Draft Extended Internet Fax October 1998 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 [REPORTING-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 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. 4.2. Forged MDNs or DSNs Forged DSNs or MDNs, as described in [RFC1892, RFC1894, RFC2298] Masinter, Wing Expires March 1999 [Page 6]
Internet Draft Extended Internet Fax October 1998 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 [RFC1893bis] status code of 5.6.--???-TBD-????--. 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: Because DSN bounces are not requested by the sender and are not 'approved' by the receiver, DSNs can provide a more robust mechanism than performing this function in the MUA using MDNs. If the message contains an MDN request and the recipient's MUA 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. Masinter, Wing Expires March 1999 [Page 7]
Internet Draft Extended Internet Fax October 1998 7. References [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. [RFC2298] R. Fajman, "An Extensible Message Format for Message Disposition Notifications", RFC 2298, 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 Masinter, Wing Expires March 1999 [Page 8]
Internet Draft Extended Internet Fax October 1998 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 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 9]
