Applications Area Larry Masinter INTERNET-DRAFT Xerox Corporation November 4, 1997 Expires in 6 months 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 InternetDrafts. 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). 0. Introduction and Overview 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 (to give the sender some 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. Many mechanisms for sending fax documents over the Internet have been demonstrated and deployed. This document attempts to summarize the many discussions in the Internet Fax working group concerning requirements, and to establish a baseline of agreed-to requirements against which any proposal for Internet Fax can be judged. It is the work of the author, but intended to be considered for moving forward as the consensus view of the IETF Fax Working Group. As such, comments and counter-proposals are requested. Summary of requirements: 1. Interoperability: integrate with email 2. Confirmation: ability to request a confirmation 3. Quick Delivery: ability to ask for immediate delivery 4. Capabilities: reliable, upgrade possible 5. Simplicity: basic possible 6. Security: Cause no harm, allow for privacy 7. Reliability: avoid inconsistent operations 1. Interoperability It is desirable that a standard for Internet Fax allow for the interoperability of many kinds of terminal types. There are three primary terminal types considered for Internet Fax. 1a. 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. A standard for Internet Fax may address only the Internet side of the connection, as the fax signals over PSTN are defined by T.30. However, the Internet Fax protocol must accomodate requirements placed by the nature of the gateway service. A gateway which accepts fax telephone calls and makes an Internet connection is called an 'Internet Fax onramp'. A gateway which accepts Internet connections and makes fax telephone calls is called an 'Internet Fax offramp'. [fax-term]-PSTNfax->[onramp]-Internet Fax->[recipient] [sender]-Internet Fax->[offramp]-PSTNFax->[fax-term] The gateway function may be local to a single fax terminal (a "bump in the cord" device), to a local area network or local facility (a PBX extension), or be offered by an Internet Service Provider (ISP). 1b. 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. 1c. Internet user Normal Internet users with workstations or PCs who engage in messaging should have the capability of sending and receiving fax messages through the use of their ordinary software. 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. 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. 1d. Mail processing systems If Internet Fax is to use the Internet mail transport mechanisms, it is important that it interoperate consistently with the deployed mail environment. Internet Mail operates not only end-to-end, but also with mailing list maintenance programs, mail archiving programs, mail firewalls which scan incoming mail attachments for malicious viruses, etc. Internet Fax software should not be disruptive in such an environment and preferably should interoperate well. 2. Confirmation Traditional fax applications are often used for important business correspondence, where some amount of assurance is available that the transmitted data was actually recieved at the intended terminal. In Internet Fax, it should be possible for a sender to request acknowledgement of the completion of transmission of the message, and to receive a determinate response as to whether the message was delivered, not deliveried, or that confirmation was denied. 3. 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. The Internet Fax standard should allow the sender of a document to request immediate delivery, and to have a mechanism for accomplishing that, and to avoid sending a document only to accomplish indeterminate delivery times. 4. 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 offered higher resolution, and color capabilities as options. The standard for Internet fax should not require fax terminals to support all capabilities, but there should be a mechanism by which transmission can be reliably accomplished. This might be because there is a facility by which the sender might determine the capabilities of the recipient with reasonable reliability in advance of transmission, by sending multiple renditions, or by relying on negative acknowledgement and retransmission. 5. Simplicity The Internet Fax standard 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. The Internet Fax standard 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. 6. Security: Cause No Harm, Allow for privacy The widespread introduction of any standard mechanism for Internet Fax must not cause harm, either to its users or to others. It is important, for example, that no automatic mechanism for returning acknowledgements of receipt or capabilities of fax recipients expose the users or others to mail loops, bombs, or replicated delivery. Similar considerations apply in these areas to those that have been addressed by work on electronic mail receipt acknowledgements [RECEIPT]. Automatic capability exchange based on email is not robust and may expose its users to denial of service attacks, or merely the bad effects of errors on the part of system administrators. While manual configuration and confirmation are awkward, the alternative (exposing users to unreliable or disruptive operations) is less acceptable. If a request for capabilities is sent via email, then the rules for responding to it have the same requirements as the rules for read receipts: only with the recipient's explicit confirmation. Protocols should not subject users to release of private information, such as might be accomplished by broadcast requests for capabilities to a company's Internet fax devices. Public recipients of Internet Fax should not be required to broadcast capability statements in order to receive quality faxes. Interoperation with ITU defined T.30 fax security methods, as well as standard Internet e-mail security methods is desirable. 7. 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, but an asyncronous and delayed distribution of capability information is not robust. 8. References [] <>