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

Differences from draft-ietf-fax-requirements-02.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