RFC 2542

RFC 2542: Terminology and Goals for Internet Fax ✨

Okay bestie, this is RFC 2542, called "Terminology and Goals for Internet Fax" 📠. It's by L. Masinter at Xerox Corporation for the Network Working Group, it's marked as Informational, and it's dated March 1999. The title block has no Obsoletes or Updates line, so it doesn't list any RFCs it replaces or changes. 🎀

Status of this Memo

This memo is here to inform the Internet community 🫶. It does not specify an Internet standard of any kind, and distribution is unlimited 🌸.

Copyright Notice

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

Abstract

This document defines a bunch of terms that are useful for talking about Internet Fax ✨. It also explains the goals of the Internet Fax working group and sets a baseline of the functionality people want, so protocols for Internet Fax have something to be judged against 👑. The goals cover every way a fax can be delivered, including 'real-time', 'session', and 'store and forward'. Different levels of desirability are marked throughout 🦋.

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

   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 🧚

Fax has a long history as a phone-based app for sending a document from one terminal device to another 📠. Lots of ways of sending fax documents over the Internet have been demoed, deployed, and are still in use right now 💻. The general app of using the Internet for facsimile is called "Internet Fax" 🌈.

This document defines a bunch of terms that are useful for talking about Internet Fax 💅. It also describes the goals for Internet Fax and sets a baseline of desired functionality that protocols for Internet Fax can be judged against 🎀. The goals cover every mode 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 an Internet Fax protocol are shown with priorities written 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.

These terms are also 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 mean implementations of [T.30] 💜. Fax is a phone-based app for sending a document from one terminal device to another 📠.

The phone network is often called the Public Switched Telephone Network (PSTN) or the Global Switched Telephone Network (GSTN) 📞.

Communication over the phone network happens using modems 🔥. Data sent end-to-end comes with negotiation (so the scanned data can be rendered by the recipient) and confirmation of delivery (so the sender knows the final data was received and processed) 💖. Over time, fax grew so PCs with fax modems could send and receive fax, and send data other than scanned fax images 🌸. There have also been lots of extensions to the basic image model, for extra compression methods and for showing images in grey-scale and color 🌈. Other delivery extensions include sub-addressing (extra signals sent after the call is set up, to help automatically route faxes to desktops or mailboxes) and fancier features like fax-back and polling 💅.

Usually, the terminal device has a paper input device (a scanner), a paper output device (a printer), and a limited amount of processing power 🖨️. Traditional fax has a super simple user model, where 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

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

Even though the user usually can't see it, step (5), the transmission, is made up 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

The end of operations (5d) and (6) can also be described as:

   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 point of view, the information in a transmission is both "protocol" (control information, capabilities, identification) and "document content" 🧠.

The document content is mainly the "document image" plus extra metadata that comes with the image. The way an image of a document is encoded inside the fax content is called the "image data representation" 🎀.

When a fax has been sent successfully, the sender gets a "confirmation": a signal that the fax content was delivered 💌. This "confirmation" is an internal signal and usually isn't visible to the sending user, although some error messages are visible so a page can be resent 🙈.

2.2 Definition of Internet Fax

The phrase "Internet Fax" is used for an app that supports an approximation of the fax user model (Section 2.1), but where Internet protocols are used instead of the phone network for some or all of the transmission 🌐. The exact modes and operations of traditional fax don't have to be copied exactly ✨.

2.3 Internet Fax Roles

Internet Fax is a document transmission mechanism between lots of different devices and roles 🦋. Those devices and roles can come in all kinds of configurations 🧚. To allow for that, it's useful to separate out the roles, since they can be made available separately or combined 💅. These roles are:

• Network scanner: A device that can scan a paper document and send the scanned image over the Internet 📷.
• Network printer: A device that can accept an image sent over the Internet and print the received document automatically 🖨️.
• Fax onramp gateway: A device that can accept a fax telephone call and automatically forward it over the Internet 🌉.
• Fax offramp gateway: A device that can accept a transmission from the Internet and forward it to a traditional fax terminal 🛣️.

Other traditional Internet apps might also join in on Internet Fax, including Internet mail users, Web browsers, and Internet printing hosts 💻.

2.4 Internet Fax Devices

The Internet Fax roles can be packed into lots of combinations and configurations, inside devices and bigger apps 🎀. They can also be combined with other elements, e.g., a traditional T.30 fax device 📠. Lots of different setups of apps and systems should {2} be able to take part in Internet Fax 🫶. The spec should not unnecessarily restrict the range of devices, apps, 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 connects to the phone network through a phone line (GSTN) with a fax modem 📞. To connect a fax terminal to the Internet, you need a service that connects to the GSTN on one side using standard fax signals, and to the Internet on the other side 🌐. This role might be done by a "relay" (e.g., sending T.30 signals over real-time controlled TCP connections) or by a "gateway" (e.g., translating T.30 to TIFF/email) 🦋. With these apps, the job of Internet Fax is to carry the fax content across the Internet, e.g., with

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

okay so an onramp and/or offramp app can be local to a single fax terminal 📠✨ like, the gateway app might live inside a tiny device with a phone interface on one side and a network connection on the other 🔌. to the fax machine it looks like a regular telephone connection 📞, even though the device might shunt some or all connections over to Internet Fax instead 💅 (these are called "Bump-in-cord." 🎀)

an onramp or offramp can also be a local facility that serves a bunch of fax terminals at once 🏢. for example, outgoing fax calls going through a company telephone PBX could get rerouted through a local onramp 🔀. an internet-to-telephone outbound connection could be part of a "LAN Fax" package 🖨️💕

onramps and offramps can serve a much wider area or a bigger crowd too 🌍, like services run by service bureaus that offer subscriptions 💳. the telephone sender or the recipient might be the one who subscribes 🫶

the target of an offramp might be a "hunt group" 🎯: a set of telephone numbers, where each one has a possibly different fax terminal attached 📠🌸

2.4.2 New "Internet Fax" devices

manufacturers might offer brand new devices that support any combination of the roles defined in section 2.3 🧚✨ especially a device that looks like a traditional fax terminal and is built from similar parts (a scanner, a processor, and a printer) 🖨️. it could do pretty much what a traditional fax terminal does, but it's designed to connect to the Internet rather than, or in addition to, a telephone line 🌈

these devices might have a permanent Internet connection through a LAN connection 🔗, or they might only get occasional connectivity through a (data) modem to an Internet Service Provider 📡

2.4.3 Internet hosts

Internet users on 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, whether they're Internet Fax senders or recipients, is highly desirable {2} 💌

users on the Internet might receive faxes over the Internet and see them on their screens 👀, or have them automatically printed when they arrive 🖨️. on the flip side, Internet Fax messages from the user might be the output of a software app that would normally print 📄, or specially built fax-sending software 🛠️, or they might come straight from a scanner attached to the user's terminal 📷

Internet Fax could get built into existing fax/network fax software or email software 📧✨ for example by adding printer drivers that render a document to the right content-type and deliver it using an Internet Fax protocol 🦋

in some cases, a user might have a multi-function peripheral that combines a scanner and a printer 🖨️, giving them similar operability to a stand-alone fax terminal 💅

2.4.4 Internet messaging

in Internet mail, there are a bunch of components that run in the infrastructure to do extra jobs beyond store-and-forward 🏗️. interoperating with these is a consideration for the store and forward profile of Internet Fax 🎀. for example, mailing list software accepts mail sent to one address and forwards it to a distribution list of many users 📬. mail archive software builds searchable repositories of messages 🔍. mail firewalls sit at organizational boundaries and scan incoming messages for malicious or harmful mail attachments 🛡️. vacation programs send return messages to senders when the recipient is away and can't respond 🏖️🌴

2.4.5 Universal messaging

lowkey, a lot of software vendors are now promoting "universal messaging" 📱💬: one combined communication package that bundles electronic mail, voice mail, and fax all together 📠📧📞 iconic 👑

2.5 Operational Modes for Internet Fax

facsimile over the Internet can happen in several modes 🦋

"Store and forward" Internet Fax means the entire document gets stored at a staging point before it's sent on to the next staging point 📦. store and forward can go directly between sender and recipient, or it can have a series of intermediary staging points 🔁. the intermediate storage might involve an intermediate agent or a chain of agents in the communication 🧚

"Session" Internet Fax is defined so that delivery notification is provided to the transmitting terminal before disconnection 🔔. unlike "store and forward," there's an expectation that direct communication, negotiation, and retransmission can take place between the two endpoints 🤝💜

"Real-time" Internet Fax lets two [T.30] standard facsimile terminals send a document in a way where all of the essential elements of the [T.30] communication protocol are preserved 🫶, and the session stays minimally stretched out compared to Group 3 fax over the GSTN ⏱️✨

these modes are different in what the end user expects in terms of immediacy and reliability 💀, and in how easily they stay fully compatible with legacy or traditional fax terminals 📠. they may also have different requirements on the operational infrastructure that connects the sender and recipient 🌸

3. Goals for Internet Fax 🎯

facsimile over the Internet MUST {1} define the mechanisms by which a document gets sent from a sender to a recipient 💌. it has to 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, or required within the transmission protocol? What other data representations are supported? 🖼️
• Addressing: How are Internet Fax recipients identified? How might recipient identification be represented in user directories? How are traditional fax terminals addressed? 📬
• Capabilities: the sender's ability to generate different kinds of image data representations may be known to the recipient, and the recipient's capabilities, preferences, and characteristics 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 can the recipient determine the authenticity of a fax? How can 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 go over the global switched telephone network 📞. an Internet Fax protocol MUST {1} provide 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 🫶. "support interoperability" means that a compliant sender trying to send to a compliant recipient won't fail because of incompatibility 💖

overall interoperability requires {1} interoperability for all of the protocol elements 👑: the image data representations have to be understood, the transport protocol has to function, it has to be possible to address all manner of terminals, the security mechanism must not require manual operations on devices meant 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 🦋

the requirement for interoperability has strong implications for 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 that's a simple IP-based LAN, an internal private IP network, or the public Internet 🏠. the standard for Internet Fax MUST {1} be "global" 🌍: a single specification that doesn't have or require special features of the transport mechanism for local operations 💅

if Internet Fax is going 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 users' mailboxes, it is REQUIRED {1} that the protocol interoperate successfully with common user practices for mail messages 💌: storing them in databases, retransmission, forwarding, creating mail digests, replaying old messages 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 the universal messaging systems described in section 2.4.5 💜

if Internet Fax needs 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 besides Fax 🌸. features shared with other messaging applications (voice mail, short message service, paging, and so on) are desirable {3}, so other applications don't need different operational changes 🧚💖

4.3 Confirmation ✨

Okay so in almost every use of traditional fax, people really want an assurance that their document actually reached a machine at the number they dialed 📠💖. That's the whole vibe.

Internet Fax has to bring that energy over too 🦋. The Internet Fax application MUST {1} define the mechanisms that let a sender ask to be notified when transmission of the message is complete, and then get a clear answer back: delivered, not delivered, or no confirmation of delivery is possible. No mystery answers allowed 💅.

Originally, fax "confirmation" meant the message was received and processed, like it actually came out of the recipient's output paper tray 🖨️. Lowkey, though, that was based on a signal from the receiving terminal saying the incoming page had been looked at and was judged to be of reasonable (or unacceptable) quality, using an algorithm that was never specified 🙈.

Later devices that support error correction mode got a more exact check. The ECM method (per [T.30]) used a specific algorithm for error checking, so you got a stronger indication that the bits in the compressed image weren't corrupted during transmission 🔥. Then came memory buffering, PC-based fax modems, and everyone using error correction mode. Traditional fax confirmation still implies some assurance of processability (for example, a fax modem couldn't receive an incoming fax if it needed compression mechanisms it didn't support) 🧚. It just doesn't tell you whether the image was printed or viewed.

So fax confirmation is NOT the same thing as a message being "read," meaning a human actually confirmed they got it 👀. It is desirable {3}, but not required, that Internet Fax support confirmation that a message has been read (on top of confirmation that it was delivered) 🌸.

4.4 Quick Delivery ⚡

Fax gets used a lot for documents where timing really matters, with a strong sense that once a transmission starts, it finishes quickly 🏃‍♀️. Like, a super common move is faxing discussion docs to everyone on a conference call right before the call starts 📞✨.

Internet Fax SHOULD {2} let a sender ask for immediate delivery, when that's possible. In those cases, the sender SHOULD {2} be able to skip sending the message entirely if quick delivery isn't available for a particular recipient 💀.

It is desirable {3} for the request for quick delivery to use the same protocol as delayed delivery, or something very similar, so you don't end up needing two separate mechanisms 🧩.

For real-time fax, immediate delivery is the norm 👑. The protocol MUST guarantee that once the session connecting sender and recipient has ended, the message has been delivered to the ultimate recipient 🫶.

4.5 Capabilities: reliable, upgrade possible 🎀

Traditional facsimile has always guaranteed that senders and recipients can talk to each other, because it uses a strict way of negotiating capabilities between the two devices 🤝. The image format started out pretty low-res, but it has gradually added extra options like higher resolution and color 🌈.

Fax grew through an evolving world, from 'Group 1' and 'Group 2' all the way to 'Group 3' facsimile, for two reasons: (a) a baseline set of capabilities that every terminal implemented, and (b) capabilities exchange, which let devices go beyond that baseline 💜.

To handle what's happening now and what's coming later, Internet Fax SHOULD {2} have a simple minimum set of required features that guarantees interoperability, plus a mechanism that lets higher-capability devices get deployed into a network of lower-capability devices without breaking interoperability ✨. If recipients with minimum capabilities just dropped non-minimum messages without warning, then no non-minimum message could ever be sent reliably 😭. There are a few ways to avoid that, like communicating recipient capabilities or sending multiple renditions 🦋.

The capabilities exchange in Internet Fax SHOULD {2} be robust 💪. To make that happen, recipients SHOULD {2} be encouraged to provide capabilities, while senders MUST {1} still have a way to send messages to recipients whose capabilities are unknown 🙌.

Even minimum-capability recipients SHOULD {2} be required to provide a capability indication in some reliable way 🍓. That could happen through an entry in a directory service, through automatic or semi-automatic replies, or by sending some indication in a reply to a message with multiple renditions, or as an addition to a negative acknowledgement that asks for retransmission 📬.

On the other hand, senders cannot rely on a recipient's capability information before transmission if they want reliability 🫠. So for reliability, senders SHOULD {2} have an operational mode that works when capabilities aren't present, even though recipients MUST always provide capabilities 🌸.

4.6 Simplicity 🧸

Internet Fax SHOULD NOT {2} require terminals to have a ton of processing power, and a base-level implementation MUST {1} interoperate even if it doesn't offer complex processing 💅.

Internet Fax SHOULD {2} allow interoperability with recipient devices that have limited buffering. Some of them can't buffer an entire fax message before printing, or can't buffer the whole set of pages before they start sending scanned pages 🖨️.

Different operational modes (real-time, session, store and forward) might use different protocols, so that each one stays simple 🧚.

It is preferable {3} to add as few restrictions and additions to existing protocols as possible while still meeting the other requirements 🦋. It is important {2} that Internet Fax can be used end-to-end on today's Internet without changing the existing infrastructure, although some features might need existing standards to be adopted 🌈.

4.7 Security: Cause No Harm, Allow for privacy 🔐

The widespread introduction of Internet Fax MUST {1} NOT cause harm, to its users or to anyone else 🚫. For example, an automatic way of sending delivery notifications or recipient capabilities back by email MUST {1} NOT expose users or others to mail loops, bombs, or replicated delivery 📧💣. Automatic capability exchange based on email might not be robust enough, and without serious precautions it could expose users to denial of service attacks, or just the bad effects of mistakes made by system administrators 😬. Similar concerns apply to the areas already covered by work on electronic mail receipt acknowledgements [RFC 2298] 💜.

Internet Fax SHOULD {2} NOT, by default, release information that users consider private. An example is answering a broadcast request for capabilities from a company's Internet fax devices 🙈. Public recipients of Internet Fax (like public agencies that accept fax messages) SHOULD {2} NOT be required to broadcast capability statements to every potential sender just so they can receive fax messages that fit their device's capabilities 🏛️.

"Causing harm" can come from a mix of features that each look harmless on their own 🌀. So 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} 🔒.

4.8 Reliability 🛡️

The Internet Fax protocol SHOULD {2} operate reliably across a variety of configurations and situations 💖.

In particular, operations that depend on time-delayed information might end up with inconsistent information, so the protocol SHOULD be robust even in those situations 🧠.

Here's an example. In a store-and-forward message environment, the sender might use a fax recipient's capabilities and preferences to build an appropriate message, like sending a color fax to a color device but a black-and-white fax to a device without color 🎨. However, the information about recipient capabilities MUST be accessible to the sender even when the recipient can't be contacted directly 📡. So the sender MUST access recipient capabilities through some kind of storage mechanism, like a directory 📚. A directory of recipient capabilities is a kind of distributed database, which means it's exposed to all the well-known failure modes of distributed databases 😵‍💫. For example, update messages with capability descriptions might arrive out of order, come from old archives, get lost, or be spoofed or widely spread by malicious senders if the capability statements aren't authenticated 👻. 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 is wrong, and robust mechanisms for delivering recipient capabilities SHOULD {2} be used 🫶.

4.9 User Experience ✨

The main user experience with fax is:

• immediate delivery
• delivery confirmation
• ease of use

The main 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} try to reconcile the differences between these two environments 🌉.

4.10 Legal ⚖️

An Internet Fax standard SHOULD {2} accommodate the legal requirements for facsimile, and try to support functionality similar to what's legally required, even for devices that don't operate over the public switched telephone network 📜.

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

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 ✨

Okay so, if Internet Fax wants to play nice with Internet Mail (or any other transport that makes data files show up in Internet terminal environments), it REQUIRES {1} that it use an image format that's in wide use. 💖

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

Interop with traditional fax terminals requires {1} that the data format can represent the commonly used compression mechanisms defined for traditional facsimile. Supporting all standard formats defined for traditional facsimile is highly desirable {2}. And for 'private use' facsimile messages, interop suggests {3} that the standard accommodate arbitrary bit sequences. 🧚

5.2 Goals for transmission 🚀

It is necessary {1} that Internet Fax work in the context of the current Internet, the 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 different protocols at different times and for different recipients. 🌸

5.3 Goals for addressing 📬

Interop with the terminal types in section 2 requires {1} the ability to address each of the kinds of recipient devices. A recipient's address MUST give enough information for the sender to start communicating. 💌

Interop with offramps to legacy fax terminals requires {1} that the message contain some way of addressing the final destination of facsimile messages. That includes telephone numbers, various ISDN addressing modes, and facsimile sub-addresses. 📞

Interop 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 live in the email addressing headers, including the mail transport envelope [RFC1123] and RFC822 headers, as appropriate. The information MUST {1} appear nowhere else. 🙈

Sending devices might not have local storage for address directories, and addresses can be a total pain to type in. Because of that, 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 for the appropriate return message (whether via fax or via email) SHOULD {2} be clearly identified in a way that's visible to all manner of recipients. For Internet Fax delivered by email, it SHOULD {2} be possible to use the normal 'reply' functions for email to send a message back to the sender. 💅

Traditionally, the first page of a fax sent to a facsimile terminal usually has an (image) representation of the sender's name, address, return number, and so on. Some legal jurisdictions for facsimile even require the sender to be identified on every page. The Internet Fax standard SHOULD {2} cover sender and recipient identification in cases where fax messages are re-routed, forwarded, or sent through gateways. 🗺️

5.4 Goals for Security 🔐

Users typically use GSTN-based fax for confidential document transmission. They assume a similar or higher level of confidentiality and protection from both deliberate and accidental eavesdropping as they get with telephone conversations. The extra confidentiality comes from the fact that intercepting and interpreting an overheard fax transmission requires non-standard equipment. 🕵️‍♀️

In the same way, traditional fax comes with an expectation (and, in some contexts, a legally recognized assurance) that the received fax is unaltered from the document originally sent. 📄

It is important {2} that Internet Fax give users a level of assurance for privacy and integrity that is as good as or better than what telephone-based fax offers. 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, for example by requiring that minimum-capability devices still accept signed messages (even if they ignore the signature). 🦋

Where the sender is responsible for paying for offramp services in a remote location, it is desirable {3} to provide for authentication and authorization of the sender. It's also desirable {3} to let billing information from the offramp 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 also has "non-standard frames," which let vendors introduce proprietary data formats. On top of that, 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: expressing the capabilities of the sender (as far as a particular message is concerned), expressing the capabilities of a recipient (ahead of the message being sent), and then the protocol by which capabilities are exchanged. 🔄

The Internet Fax standard SHOULD {2} specify a uniform mechanism for expressing capabilities. If capabilities are sent at times other than when the message is transmitted, then capabilities SHOULD {2} include enough information to allow them to be validated, authenticated, and so on. 🪪

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 message delivery, SHOULD {2} clearly identify the sender, the recipient whose capabilities are being requested, and the time of the request. Some 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 against valid data being swapped out for invalid data. 🛡️

6. Security Considerations 🔐

Okay bestie, this section is SERIOUS. No skipping!

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 so users get the security features they expect. 😭

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

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.

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