path: root/doc/rfc/rfc2542.txt

Network Working Group                                        L. Masinter
Request for Comments: 2542                             Xerox Corporation
Category: Informational                                       March 1999


                 Terminology and Goals for Internet Fax

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   This document defines a number of terms useful for the discussion of
   Internet Fax. In addition, it describes the goals of the Internet Fax
   working group and establishes a baseline of desired functionality
   against which protocols for Internet Fax can be judged. It
   encompasses the goals for all modes of facsimile delivery, including
   'real-time', 'session', and 'store and forward'.  Different levels of
   desirability are indicated throughout the document.

Table of Contents

   1. Introduction ..................................................  2
   2. Definitions and Operational Modes .............................  3
    2.1 User model of fax ...........................................  3
    2.2 Definition of Internet Fax ..................................  4
    2.3 Internet Fax Roles ..........................................  5
    2.4 Internet Fax Devices ........................................  5
    2.5 Operational modes ...........................................  8
   3. Goals for Internet Fax ........................................  8
   4. Operational Goals for Internet Fax ............................  9
    4.1 Functionality ...............................................  9
    4.2 Interoperability ............................................  9
    4.3 Confirmation ................................................ 10
    4.4 Quick Delivery .............................................. 11
    4.5 Capabilities ................................................ 12
    4.6 Simplicity .................................................. 12
    4.7 Security .................................................... 13
    4.8 Reliability ................................................. 14
    4.9 Fax-like use ................................................ 14
    4.10 Legal ...................................................... 15



Masinter                     Informational                      [Page 1]
^L
RFC 2542         Terminology and Goals for Internet Fax       March 1999


   5. Functional Goals for Internet Fax ............................. 15
    5.1 Goals for image data representation ......................... 15
    5.2 Goals for transmission ...................................... 16
    5.3 Goals for addressing ........................................ 16
    5.4 Goals for security .......................................... 17
    5.5 Goals for capability exchange ............................... 17
   6. Security Considerations ....................................... 18
   7. Acknowledgements .............................................. 18
   8. Author's Address .............................................. 18
   9. References .................................................... 19
   10. Full Copyright Statement ..................................... 20

1. Introduction

   Facsimile (Fax) has a long tradition as a telephony application for
   sending a document from one terminal device to another.

   Many mechanisms for sending fax documents over the Internet have been
   demonstrated and deployed and are currently in use. The general
   application of using the Internet for facsimile is called "Internet
   Fax".

   This document defines a number of terms useful for the discussion of
   Internet Fax. In addition, it describes the goals for Internet Fax and
   establishes a baseline of desired functionality against which
   protocols for Internet Fax can be judged. It encompasses the goals for
   all modes of facsimile delivery, including "real-time", "session", and
   "store and forward" (terms defined in Section 2 of this document).

   1.1 Terminology used within this document

   Within this document, different levels of desirability for a protocol
   for Internet Fax are indicated by different priorities, indicated in
   {braces}:

      {1} there is general agreement that this is a critical
          characteristic of any definition of Internet Fax.
      {2} most believe that this is an important characteristic
          of Internet Fax.
      {3} there is general belief that this is a useful feature
          of Internet Fax, but that other factors might override;
          a definition that does not provide this element is
          acceptable.








Masinter                     Informational                      [Page 2]
^L
RFC 2542         Terminology and Goals for Internet Fax       March 1999


   In addition, the following terms are used:

   "service"      An operational service offered by a service provider.
   "application"  A use of systems to perform a particular function.
   "terminal"     The endpoint of a communication application.
   "goal"         An objective of the standarization process.

2. Definitions and Operation Modes

   This section defines some of the basic terms for Internet Fax.

2.1 User model of fax and basic operations

   The phrase "traditional facsimile" or "G3Fax" is used to denote
   implementations of [T.30]. Facsimile (fax) is a telephony application
   for sending a document from one terminal device to another.

   The telephone network is often referred to as the Public Switched
   Telephone Network (PSTN) or Global Switched Telephone Network (GSTN).

   Communication over the telephone network is accomplished using
   modems.  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 using fax modems to send
   and receive fax, to send data other than scanned facsimile images. In
   addition, there have been many extensions to the basic image model,
   to allow for additional compression methods and for representation of
   images with grey-scale and color. 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 and polling.

   Typically, the terminal device consists of a paper input device
   (scanner), a paper output device (printer), with (a limited amount
   of) processing power. Traditional facsimile has a simple user
   operational model; the user

      1) inserts paper into a device
      2) dials a number corresponding to the destination
      3) presses the 'start' button on the device
      4) the sending device connects to the receiving device using the
         telephone network
      5) the sending device scans the paper and transmits the image of
         the paper
      6) simultaneously, the remote device receives the transmission and
         prints the image on paper



Masinter                     Informational                      [Page 3]
^L
RFC 2542         Terminology and Goals for Internet Fax       March 1999


      7) upon completion of transmission and successful processing by
         the recipient, the sending user is notified of success

   Although not usually visible to the user, the operation (5) of
   transmission consists of

      5a) negotiation: the capabilities of the recipient are obtained,
          and suitable mutually available parameters for the
          communication are selected
      5b) scanning: creating digitized images of pages of a document
      5c) compression: the image data is encoded using a data
          compression method
      5d) transmission: the data is sent from one terminal to the other

   In addition, the terminiation of operations (5d) and (6) may be
   characterized as consisting of:

      6a) completed delivery: the message has completed transmission
      6b) completed receipt:  the message has been accepted by the
          recipient
      6c) processing and disposition: the message has been processed

   From a protocol perspective, the information conveyed in the
   transmission consists of both "protocol" (control information,
   capabilities, identification) and also "document content".

   The document content consists primarily of the "document image" plus
   additional metadata accompanying the image. The means by which an
   image of a document is encoded within the fax content is the "image
   data representation".

   When the fax has been successfully transmitted, the sender receives a
   "confirmation": an indication that the fax content was delivered.
   This "confirmation" is an internal signal and is not normally visible
   to the sending user, although some error messages are visible, to
   allow a page to be retransmitted.

2.2 Definition of Internet Fax

   The phrase "Internet Fax" is used to denote an application which
   supports an approximation to the user model of fax (Section 2.1), but
   where Internet protocols are used instead of the telephone network
   for (some portion of) the transmission. The exact modes and
   operations of traditional facsimile need not be duplicated exactly.







Masinter                     Informational                      [Page 4]
^L
RFC 2542         Terminology and Goals for Internet Fax       March 1999


2.3 Internet Fax Roles

   Internet Fax is a document transmission mechanism between various
   different devices and roles. Those devices and roles might come in a
   wide variety of configurations. To allow for a wide variety of
   configurations, it is useful to separate out the roles, as they may
   be made available separately or in combination. These roles are:

      * Network scanner
        A device that can scan a paper document and transmit the scanned
        image via the Internet

      * Network printer
        A device that can accept an image transmission via the Internet
        and print the received document automatically

      * Fax onramp gateway
        A device that can accept a facsimile telephone call and
        automatically forward it via the Internet

      * Fax offramp gateway
        A device that can accept a transmission from the Internet and
        forward it to a traditional fax terminal

   In addition, other traditional Internet applications might also
   participate in Internet Fax, including Internet mail users, Web
   browsers, Internet printing hosts.

2.4 Internet Fax Devices

   The Internet Fax roles may be embedded in a variety of combinations
   and configurations within devices and larger applications.  They may
   be combined with other elements, e.g., a traditional T.30 fax device.
   Many different configurations of applications and systems should {2}
   be able to participate in Internet Fax; the specification should not
   unnecessarily restrict the range of devices, applications and
   services that can participate.

   A device that supports Internet Fax might support any combination of
   the roles defined in 2.3.

2.4.1 Gateway devices

   A traditional fax terminal has a telephone line connection (GSTN)
   with a fax modem used to connect over the telephone network. To
   connect a fax terminal to the Internet requires a service which
   offers connections on one side to the GSTN using standard fax
   signals, and on the other side to the Internet. This role might be



Masinter                     Informational                      [Page 5]
^L
RFC 2542         Terminology and Goals for Internet Fax       March 1999


   performed by a "relay" (e.g., transmitting T.30 signals over real-
   time controlled TCP connections) or a "gateway" (e.g., translating
   T.30 to TIFF/email).

   With these applications, the role of Internet Fax is to transport the
   fax content across the Internet, e.g., with

[fax-term]-GSTNfax->[onramp]-Internet Fax->[recipient]
                    [sender]-Internet Fax->[offramp]-GSTNFax->[fax-term]

   A onramp and/or offramp application may be local to a single fax
   terminal.  For example, the gateway application 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 might shunt some or all connections
   to Internet Fax instead (Such devices are called "Bump-in-cord.")

   An onramp or offramp application may be a local facility serving many
   fax terminals. 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.

   Onramps and offramps may serve a wider area or broader collection of
   users, e.g., services run by service bureaus, offering subscription
   services; the telephone sender or the recipient might subscribe to
   the service.

   The target of an offramp may be a "hunt group": a set of telephone
   numbers, each of which have a possibly different fax terminal
   attached.

2.4.2 New "Internet Fax" devices

   Manufacturers may offer new devices which support any combination of
   the roles defined in setion 2.3. In particular, a device resembling a
   traditional fax terminal, built out of similar components (scanner,
   processor, and printer), could offer a similar functionality to a
   traditional facsimile terminal, but be designed to connect to the
   Internet rather than, or in addition to, a telephone line connection.

   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.







Masinter                     Informational                      [Page 6]
^L
RFC 2542         Terminology and Goals for Internet Fax       March 1999


2.4.3 Internet hosts

   Internet users using Internet hosts with standard application suites
   must {1} be able to exchange faxes with other participants in
   Internet Fax, with minimum required enhancements to their operating
   environment.

   Interoperability with Internet mail users, either as Internet Fax
   senders or recipients, is highly desirable {2}.

   Internet users might receive faxes over the Internet and display them
   on their screens, or have them automatically printed when received.
   Similarly, the Internet 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 may be input
   directly from a scanner attached to the user's terminal.

   The Internet Fax capability might be integrated into existing
   fax/network fax software or email software, e.g., by the addition of
   printer drivers that would render the document to the appropriate
   content-type and cause it to be delivered using an Internet Fax
   protocol.

   In some cases, the user might have a multi-function peripheral which
   integrated a scanner and printer and which gave operability similar
   to that of the stand-alone fax terminal.

2.4.4 Internet messaging

   In Internet mail, there are a number of components that operate in
   the infrastructure to perform additional functions 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.

2.4.5 Universal messaging

   Many software vendors are now promoting software packages that
   support "universal messaging": a combined communication package that
   combines electronic mail, voice mail, and fax.





Masinter                     Informational                      [Page 7]
^L
RFC 2542         Terminology and Goals for Internet Fax       March 1999


2.5 Operational Modes for Internet Fax

   Facsimile over the Internet can occur in several modes.

   "Store and forward" Internet Fax entails a process of storing the
   entire document at a staging point, prior to transmitting it to the
   next staging point. Store and forward can be directly between sender
   and recipient or can have a series of intermediary staging points.
   The intermediate storage may involve an intermediate agent or
   sequence of agents in the communication.

   "Session" Internet Fax is defined such that delivery notification is
   provided to the transmitting terminal prior to disconnection. Unlike
   "store and forward", there is an expection that direct communication,
   negotiation, and retransmission can take place between the two
   endpoints.

   "Real-time" Internet Fax allows for two [T.30] standard facsimile
   terminals to engage in a document transmission in a way that all of
   the essential elements of the [T.30] communication protocol are
   preserved and there is minimal elongation of the session as compared
   to Group 3 fax over the GSTN.

   These modes are different in the end-user expectation of immediacy,
   reliability, and in the ease of total compatibility with legacy or
   traditional facsimile terminals; the modes may have different
   requirements on operational infrastructure connecting sender and
   recipient.

3. Goals for Internet Fax

   Facsimile over the Internet must define the mechanisms by which a
   document is transmitted from a sender to a recipient, and must {1}
   specify the following elements:

      - Transmission protocol: what Internet protocol(s) and extensions
        are used?  What options are available in that transmission?

      - Data formats: what image data representation(s) are used,
        appropriate, required, within the transmission protocol? What
        other data representations are supported?

      - Addressing: How are Internet Fax recipients identified? How may
        recipient identification be represented in user directories? How
        are traditional fax terminals addressed?






Masinter                     Informational                      [Page 8]
^L
RFC 2542         Terminology and Goals for Internet Fax       March 1999


      - Capabilities: The capabilities of the sender to generate
        different kinds of image data representations may be known to
        the recipient, and the capabilities, preferences, and
        characteristics of the recipient may be known to the sender. How
        are the capabilities, preferences, and characteristics of
        senders and recipients expressed, and communicated to each
        other?

      - Security: Faxes may be authenticated as to their origin, or
        secured to protect the privacy of the message.  How may the
        authenticity of a fax be determined by the recipient?  How may
        the privacy of a message be guaranteed?

   Specific goals for these elements are described in section 5.

4. Operational Goals for Internet Fax

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

4.1 Functionality

   Traditionally, images sent between fax machines are transmitted over
   the global switched telephone network. An Internet Fax protocol must
   {1} provide for a method to accomplish the most commonly used
   features of traditional fax using only Internet protocols. It is
   desirable {3} for Internet Fax to support all standard features and
   modes of standard facsimile.

4.2 Interoperability

   It is essential {1} that Internet Fax support interoperability
   between most of the devices and applications listed in section 2, and
   desirable {3} to support all of them. To "support interoperability"
   means that a compliant sender attempting to send to a compliant
   recipient will not fail because of incompatibility.

   Overall interoperability requires {1} interoperability for all of the
   protocol elements: the image data representations 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, and so forth.

   Interoperability with Internet mail user agents is a requirement {1}
   only for the "store-and-forward" facsimile, although it would be
   useful {3} for "session" and "real-time" modes of delivery of
   Internet Fax.



Masinter                     Informational                      [Page 9]
^L
RFC 2542         Terminology and Goals for Internet Fax       March 1999


   The requirement for interoperability has strong implications for the
   protocol design. Interoperability must not {1} depend on having the
   same kind of networking equipment at each end.

   As with most Internet application protocols, interoperability must
   {1} 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 {1} be "global": that
   is, a single specification which does not have or require special
   features of the transport mechanism for local operations.

   If Internet Fax is to use the Internet mail transport mechanisms, it
   must {1} interoperate consistently with the current Internet mail
   environment, and, in particular, with the non-terminal devices listed
   in section 2.4.4.  If Internet Fax messages might arrive in user's
   mailboxes, it is required {1} 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.

   It is desirable {3} that the Internet Fax standard support and
   facilitate universal messaging systems described in section 2.4.5.

   If Internet Fax requires additions to the operational environment
   (services, firewall support, gateways, quality of service, protocol
   extensions), then it is preferable {3} 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 {3}, so as not to require different operational changes for
   other applications.

4.3 Confirmation

   In almost all applications of traditional fax, it is considered very
   important that the user can get an assurance that the transmitted
   data was received by a terminal at the address dialed by the user.

   This goal translates to the Internet environment. The 'Internet Fax'
   application must {1} define the mechanisms by which a sender may
   request notification of the completion of transmission of the
   message, and receive a determinate response as to whether the message
   was delivered, not delivered, or that no confirmation of delivery is
   possible.

   Originally, fax "confirmation" implied that the message was received
   and processed, e.g., delivered to the output paper tray of the
   recipient fax device.  In reality, this implication was relying upon



Masinter                     Informational                     [Page 10]
^L
RFC 2542         Terminology and Goals for Internet Fax       March 1999


   a signal produced by the receiving terminal that the incoming page
   had been inspected and was determined to be of reasonable (or
   unacceptable) quality, via an unspecified algorithm.

   In later devices which support error correction mode, the ECM method
   (per [T.30]) enabled error checking via a specific algorithm,
   providing a more exact indication that the bits within the compressed
   image were not corrupted during transmission.  With the addition of
   memory buffering, PC-based fax modems and the more common use of
   error correction mode, traditional fax confirmation still implies
   some assurance of processability; (e.g., a fax modem would not be
   able to receive an incoming fax if it required compression mechanisms
   that were not supported) without reporting on whether the image has
   been printed or viewed.

   Consequently, the fax confirmation is not the same as a confirmation
   that the message was "read": that a human had confirmed that the
   message was received. It is desirable {3}, but not required, that
   Internet Fax support confirmation that a message has been read (above
   and beyond the confirmation that the message has been delivered).

4.4 Quick Delivery

   In many cases, fax transmission is used for delivery of documents
   where there is a strong user requirement for timeliness, with some
   guarantees that if transmission begins at all, it will complete
   quickly. For example, it is a common practice to fax documents for
   discussion to other participants in a telephone conference call prior
   to the call.

   Internet Fax should {2} allow the sender of a document to request
   immediate delivery, if such delivery is possible. In such cases, it
   should {2} be possible for the sender of a message to avoid sending
   the message at all, if quick delivery is not available for a
   particular recipient.

   It is desirable {3} to have the protocol for requesting quick
   delivery be the same as, or similar to, the protocol for delayed
   delivery, so that two separate mechanisms are not required.

   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.







Masinter                     Informational                     [Page 11]
^L
RFC 2542         Terminology and Goals for Internet Fax       March 1999


4.5 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 {2} 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.

   The exchange of capabilities in Internet Fax should {2} be robust. To
   accomplish this, recipients should {2} be encouraged to provide
   capabilities, even while senders must {1} have a way to send messages
   to recipients whose capabilities are unknown.

   Even minimum-capability recipients of messages should {2} be required
   to provide a capability indication in some reliable way. This might
   be accomplished by providing an entry in a directory service, by
   offering automatic or semi-automatic replies, or by sending some
   indication of 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 {2} have an operational mode which can
   function when capabilities are not present, even when recipients must
   always provide capabilities.

4.6 Simplicity

   Internet Fax should not {2} require terminals to possess a large
   amount of processing power, and a base level implementation must {1}
   interoperate, even if it does not offer complex processing.



Masinter                     Informational                     [Page 12]
^L
RFC 2542         Terminology and Goals for Internet Fax       March 1999


   Internet Fax should {2} allow interoperability with recipient 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.

   Different operational modes (real-time, session, store and forward)
   might use different protocols, in order to preserve the simplicity of
   each.

   It is preferable {3} to make as few restrictions and additions to
   existing protocols as possible while satisfying the other
   requirements.  It is important {2} that it be possible to use
   Internet Fax end-to-end in the current Internet environment without
   any changes to the existing infrastucture, although some features may
   require adoption of existing standards.

4.7 Security: Cause No Harm, Allow for privacy

   The widespread introduction of Internet Fax must {1} not cause harm,
   either to its users or to others. For example, an automatic mechanism
   for returning notification of delivery or capabilities of fax
   recipients by email must {1} not expose the users or others to mail
   loops, bombs, or replicated delivery. Automatic capability exchange
   based on email might 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 [RFC 2298].

   Internet Fax should {2} 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 {2} 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" might be created by a combination
   of facilities and other features which individually may be viewed as
   harmless. Thus, the overall operation of a network full of Internet
   Fax devices must {1} be considered.

   Interoperation with ITU defined T.30 fax security methods, as well as
   standard Internet e-mail security methods is desirable {3}.





Masinter                     Informational                     [Page 13]
^L
RFC 2542         Terminology and Goals for Internet Fax       March 1999


4.8 Reliability

   The Internet Fax protocol should {2} operate reliably over a variety
   of configurations and situations.

   In particular, operations which rely on time-delayed information
   might result in inconsistent information, and the protocol should be
   robust even in such situations.

   For example, in a store-and-forward message environment, the
   capabilities and preferences of a fax recipient might be used by the
   sender to construct an appropriate message, e.g., sending a color fax
   to a color device but a black and white fax to a device that does not
   have color capability. However, the information about recipient
   capabilities must be accessible to the sender even when the recipient
   cannot be contacted directly. Thus, the sender must access recipient
   capabilities in some kind of storage mechanism, e.g., a directory.  A
   directory of recipient capabilities is a kind of distributed
   database, and would be 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. The
   Internet Fax protocol should {2} be robust in these situations;
   messages should {2} not be lost or misprocessed even when the
   sender's knowledge of recipient capabilities are wrong, and robust
   mechanisms for delivery of recipient capabilities should {2} be used.

4.9 User Experience

   The primary user experience with fax is:

      immediate delivery
      delivery confirmation
      ease of use

   The primary user experience with email is:

      delayed delivery
      no delivery confirmation
      ability to reply to sender
      easy to send to multiple recipients

   An Internet Fax standard should {2} attempt to reconcile the
   differences between the two environments.






Masinter                     Informational                     [Page 14]
^L
RFC 2542         Terminology and Goals for Internet Fax       March 1999


4.10 Legal

   An Internet Fax standard should {2} accomodate the legal requirements
   for facsimile, and attempt to support functionality similar to that
   legally required even for devices that do not operate over the public
   switched telephone network.

   The United States Federal Communication Commission regulations
   (applicable only within the USA) state:

      Identification Required on Fax Messages

      The FCC's rules require that any message sent to a fax machine
      must clearly mark on the first page or on each page of the
      message:

        *     the date and time the transmission is sent;
        *     the identity of the sender; and
        *     the telephone number of the sender or of the sending fax
              machine.

      All fax machines manufactured on or after December 20, 1992 and
      all facsimile modem boards manufactured on or after December 13,
      1995 must have the capability to clearly mark such identifying
      information on the first page or on each page of the
      transmission."

5. Functional Goals for Internet Fax

   These goals for specific elements of Internet Fax follow from the
   operational goals described in section 4.

5.1 Goals for image and other data representations

   Interoperability with Internet Mail or other transmission mechanisms
   that cause data files to appear in Internet terminal environments
   requires {1} that Internet Fax use a format for images that is in
   wide use.

   Interoperability with Internet Mail requires {2} that Internet Fax
   recipients handle those message types that are common in the email
   environment, including a minimum set of MIME mail formats.

   Interoperability with traditional fax terminals requires {1} that the
   data format be capable of representing the commonly used compression
   mechanisms defined for traditional facsimile; support for _all_
   standard formats defined for traditional facsimile is highly
   desirable {2}. In addition, interoperability with 'private use'



Masinter                     Informational                     [Page 15]
^L
RFC 2542         Terminology and Goals for Internet Fax       March 1999


   facsimile messages suggests {3} that the standard accommodate
   arbitrary bit sequences.

5.2 Goals for transmission

   It is necessary {1} that Internet Fax to work in the context of the
   current Internet, Intranet, and the combination across firewalls.

   A single protocol with various extensions is preferable {3} to
   multiple separate protocols, if there are devices that might require,
   at different times and for different recipients, different protocols.

5.3 Goals for addressing

   Interoperability with the terminal types in section 2 requires {1}
   the ability to address each of the kinds of recipient devices.  The
   address of a recipient must give sufficient information to allow the
   sender to initiate communication.

   Interoperability with offramps to legacy fax terminals requires {1}
   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 {1} that it be possible
   to address Internet Fax to any email address.  Interworking with
   Internet mail also requires {1} that the addressing is in the email
   addressing headers, including mail transport envelope [RFC1123] and
   RFC822 headers, as appropriate. The information must {1} appear
   nowhere else.

   Sending devices might not have local storage for directories of
   addresses, and addresses might be cumbersome for users to type in.
   For these reasons, Internet Fax devices may require configuration to
   locate directories of recipients and their capabilities.

   The source of a fax message must {1} be clearly identified. The
   address of the appropriate return message (whether via fax or via
   email) should {2} 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 {2} 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 {2}



Masinter                     Informational                     [Page 16]
^L
RFC 2542         Terminology and Goals for Internet Fax       March 1999


   cover the issues of sender and recipient identification in the cases
   where fax messages are re-routed, forwarded, sent through gateways.

5.4 Goals for Security

   Users typically use GSTN-based fax for confidential document
   transmission, assuming a similar or higher level of confidentiality
   and protection from both deliberate and inadvertent eavesdropping as
   holds for telephone conversations; the higher level of
   confidentiality arising from the requirement for non-standard
   equipment to intercept and interpret an overheard fax transmission.

   Similarly, in traditional fax there is an expectation (and, in some
   contexts, a legally recognized assurance) that the received fax is
   unaltered from the document originally transmitted.

   It is important {2} that Internet Fax give users a level of assurance
   for privacy and integrity that is as good or better than that
   available for telephone-based fax.  The Internet Fax standard should
   {2} specify how secure messages can be sent, in an interoperable
   fashion. The Internet Fax protocol should {2} 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 is desirable {3} to provide for
   authentication and authorization of the sender, as well as enable
   billing related information from the offramp to be transferred
   securely.

5.5 Goals for capabilities exchange

   Traditional fax supports a wide range of devices, including high
   resolution ("Superfine"); recent enhancements include methods for
   color and a variety of compression mechanisms. 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 {2} 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



Masinter                     Informational                     [Page 17]
^L
RFC 2542         Terminology and Goals for Internet Fax       March 1999


   capabilities are exchanged.

   The Internet Fax standard should {2} specify a uniform mechanism for
   capabilities expression. If capabilities are being sent at times
   other than the time of message transmission, then capabilities should
   {2} include sufficient information to allow it to be validated,
   authenticated, etc.

   The Internet Fax standard may {3} include one or several methods for
   transmission, storage, or distribution of capabilities.

   A request for capability information, if sent to a recipient at any
   time other than the immediate time of delivery of the message, should
   {2} clearly identify the sender, the recipient whose capabilities are
   being requested, and the time of the request. Som kind of signature
   would be useful, too.

   A capability assertion (sent from recipient to sender) should {2}
   clearly identify the recipient and some indication of the date/time
   or range of validity of the information inside. To be secure,
   capability assertions should {2} be protected against interception
   and the substitution of valid data by invalid data.

6. Security Considerations

   This document describes the goals for the Internet Fax protocol,
   including the security goals. An Internet Fax protocol must {1}
   address the security goals and provide adequate measures to provide
   users with expected security features.

7. 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, Nadesan Narenthiran,
   George Pajari and Dave Crocker for their valuable comments on this
   document.

8. Author's Address

   Larry Masinter
   Xerox Corporation
   3333 Coyote Hill Road
   Palo Alto, CA 94304

   http://www.parc.xerox.com/masinter
   Fax: (650) 812-4333
   EMail: masinter@parc.xerox.com



Masinter                     Informational                     [Page 18]
^L
RFC 2542         Terminology and Goals for Internet Fax       March 1999


9. References

   [T.30]    "Procedures for Document Facsimile Transmission in the
             General Switched Telephone Network", ITU-T (CCITT),
             Recommendation T.30, July, 1996.

   [F.185]   "Internet facsimile: Guidelines for the support of the
             communication of facsimile documents", ITU-T (CCITT),
             Recommendation F.185, 1998.

   [T.37]    "Procedures for the transfer of facsimile data via store-
             and-forward on the Internet", ITU-T (CCITT), Recommendation
             T.37, 1998.

   [T.38]    "Procedures for real time Group 3 facsimile communication
             between terminals using IP Networks", ITU-T (CCITT),
             Recommendation T.38, 1998.

   [RFC2305] Toyoda, K., Ohno, H., Murai, J. and D. Wing, "A Simple Mode
             of Facsimile Using Internet Mail", RFC 2305, March 1998.

   [RFC2298] Fajman, R., "An Extensible Message Format for Message
             Disposition Notifications", RFC 2298, March 1998.

   [RFC1123] Braden, R., "Requirements for Internet hosts - Application
             and Support", STD 3, RFC 1123, October 1989.

























Masinter                     Informational                     [Page 19]
^L
RFC 2542         Terminology and Goals for Internet Fax       March 1999


10.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  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.
























Masinter                     Informational                     [Page 20]
^L