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

Differences from draft-ietf-fax-requirements-00.txt

		   Requirements for Internet Fax
 	        <draft-ietf-fax-requirements-01.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).

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

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. It is an
attempt to establish a baseline of agreed-to requirements against
which any proposal for Internet Fax can be judged.

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
   file format, transmission, addressing, 
    
 3. Requirements
   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
 3. Model for Internet Fax


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

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

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.

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. For example, 'listserv' software processes mail to
large distribution lists of 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.

2. 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 avoids using a
document transmission 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?

3. 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 listed, to any of the other kinds
of devices or systems, and expect the document to arrive and be
processed successfully, with high reliability. Interoperability
requires interoperability 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 deployed mail
environment, and, in particular, with the non-terminal devices listed
in 1d.  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 best 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 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.

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.

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.

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.

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

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

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

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.

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.

4. Security Considerations

This document lays out several security considerations for Internet
Fax. However, it does not consider the requirements for privacy
and authentication.

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


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

7. References

[RECIEPT]