Internet Fax Working Group Larry Masinter INTERNET-DRAFT Xerox Corporation November 19, 1997 10:43AM PST Expires in 6 months draft-ietf-fax-requirements-03.txt Requirements for Internet Fax 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 learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Table of contents: 1. Introduction 2. Operational modes of Facsimile: definitions 3. Devices and Services for Internet Fax a. Onramps and Offramps for Traditional Fax Terminals b. New IFax terminals c. Internet user agent d. Message distribution mechanisms 4. Model for Internet Fax a. Overview b. Data format, transmission, addressing, security, capabilities 5. General Requirements for Internet Fax a. Functionality b. Interoperability c. Confirmation d. Quick Delivery e. Capabilities f. Simplicity g. Security h. Reliability 6. Specific Requirements for Internet Fax a. Requirements for data format b. Requirements for transmission c. Requirements for addressing d. Requirements for security e. Requirements for capability exchange 7. Security Considerations 8. Copyright 9. Author's address 10. References 1. Introduction Facsimile (Fax) has a long tradition of being a telephony application from one terminal device to another, where the terminal device consists of a paper input device (scanner), a paper output device (printer), and a limited amount of processing power. The transmission of data end-to-end is accompanied by negotiation (to ensure that the scanned data can be rendered at the recipient) and confirmation of delivery (to give the sender assurance that the final data has been received and processed.) Over time, facsimile has been extended to allow for PCs connected running software to send and receive fax, to send data other than paper images, as well as many extensions to the basic image model, e.g., recent ITU fax standards for color fax. Other delivery extensions have included sub-addressing (additional signals after the call is established to facilitate automated routing of faxes to desktops or mailboxes), and enhanced features such as fax-back, polling, and even the transfer of binary files. Many mechanisms for sending fax documents over the Internet have been demonstrated and deployed and are currently in use. This document summarizes the requirements for Internet Fax as discussed in the IETF Internet Fax working group. It is an attempt to establish a baseline of agreed-to requirements against which any proposal for Internet Fax can be judged. This document encompasses the requirements for both 'real-time' fax as well as 'store and forward' fax (both terms defined in Section 2). 2. Operational Modes of Facsimile: Definitions The application of facsimile has involved sending a document from one system to another. The parties involved are the sender: the originating terminal the recipient: the destination In the case of 'broadcast fax', there may be several destinations and a single sender, but traditionally this is accomplished by sequentially sending from a single redistribution point. "Session" Internet Fax is defined such that delivery notification is provided to the transmitting terminal prior to disconnection. "Real-time" Internet Fax allows for two (ITU-T based) standard facsimile terminals to engage in a document transmission in a way that all (or as much as practical) of the ITU-T communication protocol is preserved: a) the content and sequence of ITU-T messages is preserved b) the "call duration" at either endpoint is similar to that encountered during a PSTN or ISDN connection "Store and forward" facsimile is defined as the kind of operation where an intermediate agent or sequence of agents are involved in the communication: the sender connects to an agent, and engages in a communication to send the message to the agent. The agent then subsequently contacts the destination (or attempts to, until the destination is available), and delivers the message. These modes are different in the end-user expectation of immediacy, reliability, and in the ease of total compatibility with existing ITU-T standard fax terminals. 3. Context: Devices and Services Many different kinds of devices and services might participate in the transmission of Internet Fax. To describe the interoperability requirements, it is useful to describe the primary kinds of devices. a. Onramps and Offramps for Traditional Fax Terminals A traditional fax terminal has a telephone line connection (PSTN) with a fax modem used to connect over the telephone network. To connect a fax terminal to the Internet requires a _gateway_: a service which offers connections on one side to the PSTN using standard fax signals, and on the other side to the Internet. The standard for Internet Fax may specify only the Internet side of the connection, as the fax signals over PSTN are defined by [T.30]. However, the Internet Fax protocol must accommodate requirements placed by the nature of the gateway service. The service which accepts fax telephone calls and makes an Internet connection is called an 'Internet Fax Onramp', as it provides a way to get onto the Internet from the telephone network. A service which accepts Internet connections and makes fax telephone calls is called an 'Internet Fax Offramp'. The same device may function as an onramp and offramp. The role of Internet Fax is to transport the fax message across the Internet, e.g., with [fax-term]-PSTNfax->[onramp]-Internet Fax->[recipient] [sender]-Internet Fax->[offramp]-PSTNFax->[fax-term] A onramp and/or offramp service may be local to a single fax terminal. For example, the gateway service might exist within a small device which has a telephone interface on one side and a network connection on the other. To the fax machine, it looks like a telephone connection, although it may shunt some or all connections to Internet Fax instead (Such devices are called "Bump-in-cord.") An onramp or offramp service might be offered as part of a local facility. For example, outgoing telephone fax calls through a company telephone PBX could be rerouted through a local onramp. An internet to telephone outbound connection could be part of a "LAN Fax" package. Onramp or offramp services might also be run by service bureaus, offering subscription services; the telephone sender or the recipient might subscribe to the service. The target of an offramp might be a 'hunt group': a set of telephone numbers, each of which have a possibly different fax terminal attached. b. New "IFax" terminals Manufacturers of traditional facsimile devices may offer new devices built out of similar components (scanner, processor, and printer), which offer a similar functionality to a fax device, but which connects to the Internet. These devices might also offer a traditional fax modem capability, or might send documents exclusively through the Internet. Such devices might have a permanent Internet connection (through a LAN connection) or might have occasional connectivity through a (data) modem to an Internet Service Provider via PPP. c. Internet users Normal Internet users with workstations or PCs who engage in messaging should have the capability of sending and receiving fax messages. Fax messages might be received and displayed on the user's screen, or even automatically printed when received, as with traditional fax devices. Similarly, the fax messages originating from the user might be the output of a software application which would normally 'print', or specially constructed fax-sending software, or even from a scanner attached to the user's terminal. This capability might be integrated into existing fax/network fax software or email software, e.g., by the addition of "Ifax Printer Drivers" that would render the document to the appropriate content-type and cause it to be delivered using the Internet Fax protocol. In some cases, the user might have a multi-function peripheral which integrated scanner and printer, and which gave operability similar to that of the stand-alone fax terminal. d. Message distribution mechanisms In Internet messaging, there are a number of components that operate in the infrastructure to perform additional services beyond mail store-and-forward. Interoperability with these components is a consideration for the store and forward profile of Internet Fax. For example, mailing list software accepts mail to a single address and forwards it to a distribution list of many users. Mail archive software creates repositories of searchable messages. Mail firewalls operate at organizational boundaries and scan incoming messages for malicious or harmful mail attachments. Vacation programs send return messages to the senders of messages when the recipient is on vacation and not available to respond. 4. Model for Internet Fax Many different mechanisms for Internet Fax have been proposed and are in use. However, most of the mechanisms have common elements, which are identified in this section. Internet Fax generally consists of using an Internet protocol to transfer of data (the document) from the sender to a recipient, identified by an address. The capabilities of the sender to generate document formats may be known to the recipient, and the capabilities, preferences, and characteristics of the recipient may be known to the sender. Fax messages may be authenticated as to their origin or secured to protect the privacy of the message. In general, then, an Internet Fax standard might specify: a. Data formats: What representations of document images are used, appropriate, required? b. Transmission protocol: How are the data representations (4a) transmitted from sender to recipient? What options are available in that transmission? c. Addressing: How are Internet Fax recipients identified? How is that identification represented in user directories? How are traditional fax terminals addressed? d. Security: How may the authenticity of a message be determined by the recipient? How may the privacy of a message be guaranteed? e. Capabilities: How are the capabilities, preferences, and characteristics of senders and recipients expressed, and communicated to each other? 5. General Requirements for Internet Fax This section lists the required and desirable traits of an Internet Fax protocol. a. Functionality This section lists the basic requirements for Internet Facsimile, as a basis for the requirements of the subsequent sections. It is based on the requirements listed for Internet Fax in the ITU [T.Ifax1] document. It must be possible for a compliant sender to send image information to a compliant recipient. That is, the standard for Internet Fax should be sufficient to guarantee interoperability, nationally and internationally. The requirement for interoperability has strong implications for the protocol design. Interoperability doesn't depend on having the same kind of networking equipment at each end, or on the kind of intervening Internet Protocol network: interoperability should be independent of the nature of the networking link, whether a simple IP-based LAN, an internal private IP networks, or the public Internet. The standard for Internet Fax must be global and have no special features for local operations. (This is normally the case with Internet protocol standards.) While traditionally, facsimile devices will print an incoming message, the requirements for a successful Internet Fax recipient might only be that the recipient's capabilities and characteristics will determine whether the message is printed or displayed. b. Interoperability It is desirable that a standard for Internet Fax allow for the interoperability between the several devices and services listed in section 3. This means that any and all of the devices or systems might send a document, using the protocol specified, to any of the other kinds of devices or systems, and expect the document to arrive and be processed successfully, with high reliability. Overall interoperability requires interoperability for all of the protocol elements: the data formats must be understood, the transport protocol must function, it must be possible to address all manner of terminals, the security mechanism must not require manual operations in devices that are intended for unattended operation, etc. Interoperability with Internet mail agents is a consideration only for store and forward facsimile, since such agents would not be applicable to the real-time delivery of Internet Fax. If Internet Fax is to use the Internet mail transport mechanisms, it is required that it interoperate consistently with the current Internet mail environment, and, in particular, with the non-terminal devices listed in section 3d. If Internet Fax messages might arrive in user's mailboxes, it is required that the protocol interoperate successfully with common user practices for mail messages: storing them in databases, retransmission, forwarding, creation of mail digests, replay of old messages at times long after the original receipt, and replying to messages using non-fax equipment. If Internet Fax requires additions to the operational environment (services, firewall support, gateways, quality of service, protocol extensions), then it is preferable if those additions are useful for other applications than Fax. Features shared with other messaging applications (voice mail, short message service, paging, etc.) are desirable, so as not to require different operational changes for other applications. Many vendors are attempting to build a system of 'universal messaging', in which a user's email, voice mail, facsimile, and other communication mechanisms are integrated, from the user interface point of view, into a single application suite. Ideally, the Internet Fax standard should support such applications, although doing so is not a strong requirement. c. Confirmation Traditional fax applications are often used for important business correspondence, where some amount of assurance is available that the transmitted data was actually received at the intended terminal. In Internet Fax, it should be possible for a sender to request notification of the completion of transmission of the message, and to receive a determinate response as to whether the message was delivered, not delivered, or that no acknowledgement of receipt is possible. Traditionally, fax 'confirmation' has indicated that the message was 'received', e.g., delivered to the output paper tray of the recipient fax device. This is not the same as a confirmation that the message was 'read': that a human had acknowledged that the message was received. Confirmation that the message was read (above and beyond the notification that the message was delivered) is not required. In an email-based store and forward delivery of Internet Fax, where end-points of the transmission are not directly connected, it is still preferable for intermediate points to provide confirmation of the progression of the message; in cases where this kind of delivery confirmation is not available, read receipts may be a useful short-term substitute as a means of providing confirmation of delivery. d. Quick Delivery In many (if not most) cases, fax transmission is used for urgent delivery of documents, with some guarantees that if transmission begins at all, it will complete quickly. Email doesn't normally have this characteristic. Internet Fax should allow the sender of a document to request immediate delivery, if such delivery is possible. For real-time fax delivery, immediate delivery is the norm, since the protocol must guarantee that when the session connecting sender to recipient has terminated, the message has been delivered to the ultimate recipient. It is convenient if the protocol to request quick delivery is the same as, or similar to, the protocol for delayed delivery, so that two separate mechanisms aren't required. It should be possible for the sender of a message to avoid sending the message at all if quick delivery is not available. e. Capabilities: reliable, upgrade possible Traditionally, facsimile has guaranteed interworking between senders and recipients by having a strict method of negotiation of the capabilities between the two devices. The image representation of facsimile originally was a relatively low resolution, but has increasingly offered additional capabilities (higher resolution, color) as options. The use of fax has grown in an evolving world (from 'Group 1' and 'Group 2', to 'Group 3' facsimile) because of two elements: (a) a useful baseline of capabilities that all terminals implemented, and (b) the use of capabilities exchange to go beyond that. To accommodate current use as well as future growth, Internet Fax should have a simple minimum set of required features that will guarantee interoperability, as well as a mechanism by which higher capability devices can be deployed into a network of lower capability devices while ensuring interoperability. If recipients with minimum capabilities were, for example, to merely drop non-minimum messages without warning, the result would be that no non-minimum message could be sent reliably. This situation can be avoided in a variety of ways, e.g., through communication of recipient capabilities or by sending multiple renditions. Even minimum-capability recipients of messages should be required to provide a capability indication in some reliable way, e.g., through a directory entry, determine the capabilities of the recipient with reasonable reliability in advance of transmission, in a reply to a message with multiple renditions, or as an addition to a negative acknowledgement requiring retransmission. On the other hand, for reliability, senders cannot rely on capability information of recipients before transmission. That is, for reliability, senders should have an operational mode which can function when capabilities are not present, even when recipients must always provide capabilities. f. Simplicity Internet Fax should not require terminals to possess a large amount of processing power, and a base level implementation should interoperate, even if it does not offer complex processing. Internet Fax should allow interoperability with fax terminal devices which have limited buffering capabilities and cannot buffer an entire fax message prior to printing, or cannot buffer an entire set of fax pages before beginning transmission of scanned pages. In order to accomplish simplicity, it is possible that different applications (real-time, store and forward) might require different protocols. g. Security: Cause No Harm, Allow for privacy The widespread introduction of Internet Fax must not cause harm, either to its users or to others. It is important, for example, that no automatic mechanism for returning notification of delivery or capabilities of fax recipients by email should expose the users or others to mail loops, bombs, or replicated delivery. Automatic capability exchange based on email may not be sufficiently robust and, without sufficient precautions, might expose users to denial of service attacks, or merely the bad effects of errors on the part of system administrators. Similar considerations apply in these areas to those that have been addressed by work on electronic mail receipt acknowledgements [RECEIPT]. Internet Fax should not, by default, release information that the users consider private, e.g., as might be forthcoming in response to a broadcast requests for capabilities to a company's Internet fax devices. Public recipients of Internet Fax (e.g., public agencies which accept facsimile messages) should not be required to broadcast messages with capability statements to all potential senders in order to receive facsimile messages appropriate for the capabilities of their device. The possibility for "causing harm" which may be created by a combination of facilities (section (3d)) and other features which individually may be viewed as harmless. Thus, the overall operation of a network full of Internet Fax devices must be considered. Interoperation with ITU defined T.30 fax security methods, as well as standard Internet e-mail security methods is desirable. h. Reliability: Avoid inconsistent operations Insofar as there is information about the capabilities of recipients in a store-and-forward message environment, the capabilities and preferences of the recipient must be known by the sender prior to the construction and transmission of the message. Because this information must be accessible by the sender even when the recipient cannot be contacted directly, the sender must access capabilities in some kind of storage mechanism. Most commonly these stored capabilities will be in a directory of some kind. This directory of capabilities is, in fact, a distributed database, and is subject to all of the well-known failure modes of distributed databases. For example, update messages with capability descriptions might be delivered out of order, from old archives, might be lost, non-authenticated capability statements might be spoofed or widely distributed by malicious senders. Unfortunately, the mechanisms by which a distributed database of directory information may be maintained and updated reliably are not yet widely deployed in the Internet environment. Establishing a robust protocol for capability information with asynchronous information requires considerable care. 6. Specific requirements for Internet Fax These requirements for specific elements of Internet Fax are derived from the general requirements described in section 5. a. Requirements for data format Interoperability with Internet Mail or other transmission mechanisms that cause data files to appear in Internet terminal environments implies that Internet Fax should use a format for images that is in wide use. Interoperability with Internet Mail requires that Internet Fax recipients handle those message types that are common in the email environment, including a minimum set of MIME mail formats, including multipart/mixed, message/rfc822. Interoperability with traditional fax terminals requires that the data format be capable of representing all of the standard compression and image representations that are defined for traditional facsimile. In addition, interoperability with 'private use' facsimile messages requires that the standard accommodate arbitrary bit sequences. b. Requirements for transmission It is useful for Internet Fax to work in the context of the current Internet, Intranet, and the combination across firewalls. A single protocol with various extensions is simpler than multiple separate protocols, if there are devices that might require, at different times and for different recipients, different protocols. c. Requirements for addressing Complete interoperability between all of the terminal types in section 3 requires that all of the different kinds of terminals can be addressed. The address of a recipient must give sufficient information to allow the sender to initiate communication. Interoperability with offramps to legacy fax terminals requires that the message contain some way of addressing the final destination of facsimile messages, including telephone numbers, various ISDN addressing modes, and facsimile sub-addresses. Interoperability with Internet Mail requires that it should be possible to address Internet Fax to any email address. For interworking with the rest of the mail transportation network (section 3d), addressing should be handled in the envelope of the email layer rather than in the headers or body, so that normal mail processing methods can be used for Internet Fax. Sending devices might not have local storage for directories of addresses, and addresses might be cumbersome for users to type in. Internet Fax devices might require configuration to locate directories of recipients and their capabilities. The source of a fax message should be clearly identified. The address of the appropriate return message (whether via fax or via email) should be clearly identified in a way that is visible to all manner of recipients. In the case of Internet Fax delivered by email, it should be possible to use the normal 'reply' functions for email to return a message to the sender. Traditionally, it is common for the first page of a fax message sent to a facsimile terminal to contain an (image) representation of the name, address, return number, etc. of the sender of the document. Some legal jurisdictions for facsimile require an identification of the sender on every page. The standard for Internet Fax should cover the issues of sender and recipient identification in the cases where fax messages are re-routed, forwarded, sent through gateways. d. Requirements for Security In order to give Internet Fax users the same assurance of privacy and integrity that is common with telephone-based fax, the Internet Fax standard must specify how secure messages can be sent, in an interoperable fashion. The Internet Fax protocol should encourage the introduction of security features, e.g., by requiring that minimum capability devices still accept signed messages (even if ignoring the signature.) In the case where the sender is responsible for payment for offramp services in a remote location, it may be necessary to provide for authentication of the sender and billing information from the offramp to be negotiated securely. e. Requirements for capabilities Traditional fax supports a wide range of devices, including high resolution ("Superfine"); recent enhancements include methods for color. Fax messaging includes the capability for "non-standard frames", which allow vendors to introduce proprietary data formats. In addition, facsimile supports "binary file transfer": a method of sending arbitrary binary data in a fax message. To support interoperability with these mechanisms, it should be possible to express a wide variety of fax capabilities. Capability support has three elements: expression of the capabilities of the sender (as far as a particular message is concerned), expressing the capabilities of a recipient (in advance of the transmission of the message), and then the protocol by which capabilities are exchanged. The Internet Fax standard must specify a uniform mechanism for capabilities expression. If capabilities are being sent at times other than the time of message transmission, then capabilities should include sufficient information to allow it to be validated, authenticated, etc. The Internet Fax standard may include one or several methods for transmission, storage, or distribution of capabilities. 7. Security Considerations This document lays out several security considerations for Internet Fax. 8. Acknowledgements The author gratefully acknowledges the contributions of Graham Klyne, Vivian Cancio, Dan Wing, Jim Dahmen, Neil Joffe, Mike Lake, Lloyd McIntyre, Richard Shockey, Herman Silbiger and Nadesan Narenthiran for their many valuable comments on earlier drafts. 9. Copyright Copyright (C) The Internet Society, 1997. 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." 9. Author's address Larry Masinter Xerox Corporation 3333 Coyote Hill Road Palo Alto, CA 94304 masinter@parc.xerox.com http://www.parc.xerox.com/masinter Fax: (650) 812-4333 10. References [ITUDC] D. Crocker, "Procedures for the Transfer of Facsimile Data via Internet Mail", Internet Draft, Work in Progress, draft-ietf-fax-itudc-??.txt. [MDN] R. Fajman, "An Extensible Message Format for Message Disposition Notifications", Internet Draft, Work in Progress, draft-ietf-receipt-mdn-??.txt. [MIME] N. Borenstein, and N. Freed, "Multipurpose Internet Mail Extensions", RFC 1521, Bellcore, Innosoft, September 1993. [REPORT] G. Vaudreuil, "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 1892, Octel Network Services, January 1996. [TIFF] L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J. Rafferty, "File Format for Internet Fax", Internet Draft, Work in Progress, draft-ietf-fax-tiffplus-??.txt. [VPIM] G. Vaudreuil, G. Parsons, "Voice Profile for Internet Mail - version 2", Internet Draft, Work in Progress, draft-ema-vpim-??.txt. [WIDE] K. Toyoda, H. Ohno, J. Murai, "WIDE Message-based Fax over the Internet", Internet Draft, Work in Progress, draft-ietf-fax-wide-??.txt. [T.30] ITU-T, Recommendation T.4, Standardization of Group 3 facsimile terminals for document transmission. [T.Ifax1] ITU-T Recommendation T.Ifax1 - Procedures for the transfer of facsimile data via store and forward on the internet. [T.Ifax2] ITU-T Recommendation T.Ifax2 - Procedures for real time Group 3 facsimile communication between terminals using IP networks [T.Ifax3] ITU-T Recommendation T.Ifax3 - Procedures for real time Group 4 facsimile communication between terminals using IP networks