Internet Fax Working Group                             Larry Masinter
INTERNET-DRAFT                                      Xerox Corporation
November 16, 1997                                 Expires in 6 months


                   Requirements for Internet Fax
                <draft-ietf-fax-requirements-02.txt>

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

Table of contents:
 0. Introduction
 1. Context: Devices and Services
   a. Onramp and offramp for traditional fax terminal
   b. New IFAX terminals
   c. Internet user agent
   d. Message distribution mechanisms
 2. Model for Internet Fax
   a. Overview
   b. File format, transmission, addressing, security, capabilities
 3. General Requirements for Internet Fax
   a. Interoperability: integrate all devices
   b. Confirmation: ability to request a confirmation
   c. Quick Delivery: ability to ask for immediate delivery
   d. Capabilities: reliable, upgrade possible
   e. Simplicity: basic possible
   f. Security: Cause no harm, allow for privacy
   g. Reliability: avoid inconsistent operations
 4. Specific Requirements for Internet Fax
   a. Requirements for file format
   b. Requirements for transmission
   c. Requirements for addressing
   d. Requirements for security
   e. Requirements for capability exchange
 5. Security Considerations
 6. Copyright
 7. Author's address
 8. References

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

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.

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

or
                    [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, which presents what seems to be a telephone network
interface. (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.

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

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 subsequently be delivered using the
specified 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 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.

. 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 a file 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. File formats:
   What (MIME) representations of document images are used, appropriate,
   required?
b. Transmission protocol:
  How are the data representations (2a) 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?

. Requirements for Internet Fax

This section lists the required and desirable traits of an Internet
Fax protocol.

a. Interoperability

It is desirable that a standard for Internet Fax allow for the
interoperability of all of the kinds of devices and services listed in
section 1. This means that any and all of the devices or system may
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. Interoperability is
required for all of the protocol elements: the file 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.

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 1.d.  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.

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.

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

Traditionally, the confirmation for fax has been that the message was
'printed': delivered to the output paper tray of the recipient fax
device. This delivery confirmation is not the same as a confirmation
that the message was 'read': that a human had acknowledged that the
message was received. There is no requirement for returning
confirmation of message reading.

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

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.

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

Internet Fax should not require fax terminals to support all
capabilities, but it is required that deployment of a minimal set of
requirements not prevent the introduction of devices with higher
capabilities. For example, if recipients with minimum capabilities
were 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 through communication of
recipient capabilities or by sending multiple renditions, but the
standard for Internet Fax must require that even minimum-capability
recipients of messages 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 an acknowledgement of a message with multiple
renditions, or as an addition to a negative acknowledgement requiring
retransmission.

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

f. 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 acknowledgements of receipt or
capabilities of fax recipients 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 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.

g. 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 asyncronous information
requires considerable care.

. Specific requirements for Internet Fax

These requirements for specific elements of Internet Fax are derived
from the general requirements described in section 3.

a. Requirements for file format

Internet Fax should use a format for images that is in wide use, that
can represent all of the standard compression and image
representations that are defined for traditional facsimile.  Internet
fax should require that 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.

b. Requirements for transmission

A single protocol with various extensions is preferred over having
multiple separate protocols.

c. Requirements for addressing

It should be possible to address Internet Fax to any email address.
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.

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. Even the most minimum-capability Internet
fax recipient should be capable of receiving a signed message.

e. Requirements for capabilities

To handle NSF-style fax capabilities, and the future potential
of interoperability of Internet Fax, media types other than those
normally associated with fax should be deployed.

. Security Considerations

This document lays out several security considerations for Internet
Fax.

. 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 implmentation 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."


. Author's address

Larry Masinter
Xerox Corporation
 Coyote Hill Road
Palo Alto, CA 94304
masinter@parc.xerox.com
http://www.parc.xerox.com/masinter
Fax: (650) 812-4333

. References


[RECIEPT]
[T.30]