Extended Facsimile Using Internet Mail
RFC - Proposed Standard
(March 1999; No errata)
No shepherd assigned
RFC 2532 (Proposed Standard)
||Send notices to
Network Working Group L. Masinter
Request for Comments: 2532 Xerox Corporation
Category: Standards Track D. Wing
Extended Facsimile Using Internet Mail
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document describes extensions to "Simple Mode of Facsimile Using
Internet Mail" [RFC2305] and describes additional features, including
transmission of enhanced document characteristics (higher resolution,
color) and confirmation of delivery and processing.
These additional features are designed to provide the highest level
of interoperability with the existing and future standards-compliant
email infrastructure and mail user agents, while providing a level of
service that approximates the level currently enjoyed by fax users.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights in <http://www.ietf.org/ipr.html>.
This document notes a number of enhancements to the "Simple Mode of
Facsimile Using Internet Mail" [RFC2305] that may be combined to
create an extended mode of facsimile using Internet mail.
The new features are designed to be interoperable with the existing
base of mail transfer agents (MTAs) and mail user agents (MUAs), and
take advantage of existing standards for advanced functionality such
as positive delivery confirmation and disposition notification. The
Masinter & Wing Standards Track [Page 1]
RFC 2532 Extended Internet Fax March 1999
enhancements described in this document utilize the messaging
infrastructure, where possible, instead of creating fax-specific
features which are unlikely to be implemented in non-fax messaging
This document standardizes the following two features.
* Delivery confirmation (Section 2) (required)
* Additional document features (Section 3) (optional)
These features are fully described in another document titled
"Terminology and Goals for Internet Fax" [RFC2542].
1.1. Definition of Terms
The term "processing" indicates the action of rendering or
transmitting the contents of the message to a printer, display
device, or fax machine.
The term "processing confirmation" is an indication by the recipient
of a message that it is able to process the contents of that message.
The term "recipient" indicates the device which performs the
processing function. For example, a recipient could be implemented
as a traditional Mail User Agent on a PC, a standalone device which
retrieves mail using POP3 or IMAP, an SMTP server which prints
incoming messages (similar to an LPR server).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2. GSTN Fax Gateways ("onramp"/"offramp")
The behavior of gateways from GSTN fax to SMTP ("onramps") and from
SMTP to GSTN fax ("offramps") are not described in this document.
However, such gateways SHOULD have the behavior characteristics of
senders and recipients as described in this document.
2. Delivery and Processing Confirmation
In traditional GSTN-based realtime facsimile, the receiving terminal
acknowledges successful receipt and processing of every page [T.30].
In Internet Mail, the operations of Delivery (to the mailbox) and
Disposition (to paper or a screen) may be separated in time (due to
store and forwarding of messages) and location (due to separation of
delivery agent (MTA) and user agent (MUA)). The confirmation of
Masinter & Wing Standards Track [Page 2]
Show full document text