2532
PROPOSED STANDARD
Extended Facsimile Using Internet Mail
Authors: L. Masinter, D. Wing
Date: March 1999
Area: app
Working Group: fax
Stream: IETF
Abstract
This document describes extensions to "Simple Mode of Facsimile Using Internet Mail", and describes additional features, including transmission of enhanced document characteristics (higher resolution, color) and confirmation of delivery and processing. [STANDARDS-TRACK]
RFC 2532
PROPOSED STANDARD
Network Working Group L. Masinter
Request for Comments: 2532 Xerox Corporation
Category: Standards Track D. Wing
Cisco Systems
March 1999
<span class="h1">Extended Facsimile Using Internet Mail</span>
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 Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This document describes extensions to "Simple Mode of Facsimile Using
Internet Mail" [<a href="./rfc2305" title=""A Simple Mode of Facsimile Using Internet Mail"">RFC2305</a>] 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 <<a href="http://www.ietf.org/ipr.html">http://www.ietf.org/ipr.html</a>>.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document notes a number of enhancements to the "Simple Mode of
Facsimile Using Internet Mail" [<a href="./rfc2305" title=""A Simple Mode of Facsimile Using Internet Mail"">RFC2305</a>] 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
<span class="grey">Masinter & Wing Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc2532">RFC 2532</a> Extended Internet Fax March 1999</span>
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
software.
This document standardizes the following two features.
* Delivery confirmation (<a href="#section-2">Section 2</a>) (required)
* Additional document features (<a href="#section-3">Section 3</a>) (optional)
These features are fully described in another document titled
"Terminology and Goals for Internet Fax" [<a href="./rfc2542" title=""Terminology and Goals for Internet Fax"">RFC2542</a>].
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Definition of Terms</span>
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 [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. GSTN Fax Gateways ("onramp"/"offramp")</span>
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.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Delivery and Processing Confirmation</span>
In traditional GSTN-based realtime facsimile, the receiving terminal
acknowledges successful receipt and processing of every page [<a href="#ref-T.30" title=""Procedures for Document Facsimile Transmission in the General Switched Telephone Network"">T.30</a>].
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
<span class="grey">Masinter & Wing Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc2532">RFC 2532</a> Extended Internet Fax March 1999</span>
these two operations are supplied by two different standards-track
mechanisms: Delivery Status Notifications (DSN) [RFC1891, <a href="./rfc1894">RFC1894</a>]
and Message Disposition Notifications (MDN) [<a href="./rfc2298" title=""An Extensible Message Format for Message Disposition Notifications"">RFC2298</a>], respectively.
This section defines requirements for devices or services that are to
be considered compliant with this document.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Sender Requirements</span>
Because delivery failure may occur (over disk quota, user no longer
exists, malconfigured mailer), a delivery failure message (in the
format described by [<a href="./rfc1894" title=""An Extensible Message Format for Delivery Status Notifications"">RFC1894</a>] or otherwise) may be sent to the
envelope-from address specified by the sender. Thus, the envelope-
from address supplied by the sender MUST be able to properly handle
such delivery failure messages.
<span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a>. Delivery Confirmation</span>
If the sender desires delivery confirmation, the sender MUST request
Delivery Status Notification by including the the esmtp-keyword
NOTIFY with the esmtp-value SUCCESS (<a href="./rfc1891#section-5.1">section 5.1 of [RFC1891]</a>).
<span class="h4"><a class="selflink" id="section-2.1.2" href="#section-2.1.2">2.1.2</a>. Processing Confirmation</span>
If the sender desires processing confirmation, the sender MUST
request Message Disposition Notification (<a href="./rfc2298#section-2">[RFC2298] section 2</a>) when
sending the message itself.
Because a recipient may silently ignore a request for an MDN (<a href="./rfc2298#section-2.1">section</a>
<a href="./rfc2298#section-2.1">2.1 of [RFC2298]</a>) at any time:
* MDNs MUST NOT be used for delivery confirmation, but are only
useful for disposition ("processing") notification.
* the sender MUST NOT assume the recipient will respond to an MDN
request in a subsequent message, even if the recipient has done
so in the past.
The address provided by the sender on the Disposition-Notification-To
field MUST be able to receive Message Disposition Notifications
messages [<a href="./rfc2298" title=""An Extensible Message Format for Message Disposition Notifications"">RFC2298</a>] and SHOULD be able to receive messages that are
not in the Message Disposition Notification format (due to the
existence of legacy systems that generate non-RFC2298-compliant
responses to the Disposition-Notification-To field). The
Disposition-Notification-To address and the envelope-from address
SHOULD match to allow automated responses to MDN requests (<a href="./rfc2298#section-2.1">section</a>
<a href="./rfc2298#section-2.1">2.1 of [RFC2298]</a>).
<span class="grey">Masinter & Wing Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc2532">RFC 2532</a> Extended Internet Fax March 1999</span>
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Recipient Requirements</span>
Recipients SHOULD implement Message Disposition Notifications
[<a href="./rfc2298" title=""An Extensible Message Format for Message Disposition Notifications"">RFC2298</a>] and SHOULD indicate supported media features in DSN and MDN
messages per [<a href="./rfc2530" title=""Indicating Supported Media Features Using Extensions to DSN and MDN"">RFC2530</a>].
If the recipient is an SMTP server, it behaves as part of the
receiver infrastructure and is therefore subject to the "Receiver
Infrastructure" requirements of this document.
See also "Recipient Recommendations" in <a href="#section-5">section 5</a>.
<span class="h4"><a class="selflink" id="section-2.2.1" href="#section-2.2.1">2.2.1</a>. MDN Recipient Requirements</span>
Recipients MUST be configurable to silently ignore a request for an
MDN (<a href="./rfc2298#section-2.1">section 2.1 of [RFC2298]</a>).
If the recipient is an automated message processing system which is
not associated with a person, the device MAY be configurable to
always respond to MDN requests, but in all cases MUST be configurable
to never generate MDNs.
A recipient MUST NOT generate an unsolicited MDN to indicate
successful processing. A recipient MAY generate an unsolicited MDN
(sent to the envelope-from (Return-Path:) address) to indicate
processing failure, but subject to the [<a href="./rfc2298" title=""An Extensible Message Format for Message Disposition Notifications"">RFC2298</a>] requirement that it
MUST always be possible for an operator to disable unsolicited MDN
generation.
<span class="h4"><a class="selflink" id="section-2.2.2" href="#section-2.2.2">2.2.2</a>. Recipients Using Mailbox Access Protocols</span>
A recipient using POP3 [<a href="./rfc1939" title=""Post Office Protocol - Version 3"">RFC1939</a>] or IMAP4 [<a href="./rfc2060" title=""Internet Message Access Protocol - Version 4Rev1"">RFC2060</a>] to retrieve its
mail MUST NOT generate a Delivery Status Notification message
[<a href="./rfc1894" title=""An Extensible Message Format for Delivery Status Notifications"">RFC1894</a>] because such a notification, if it was requested, would
have already been issued by the MTA on delivery to the POP3 or IMAP4
message store.
The recipient MUST NOT use the <a href="./rfc822">RFC822</a> "To:" fields, "Cc:" fields,
"Bcc:" fields, or any other fields containing header recipient
information to determine the ultimate destination mailbox or
addressee, and SHOULD NOT use other <a href="./rfc822">RFC822</a> or MIME fields for making
such determinations.
<span class="grey">Masinter & Wing Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc2532">RFC 2532</a> Extended Internet Fax March 1999</span>
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Messaging Infrastructure Requirements</span>
This section explains the requirements of the SMTP messaging
infrastructure used by the sender and receiver. This infrastructure
is commonly provided by the ISP or a company's internal mailers but
can actually be provided by another organization with appropriate
service contracts.
<span class="h4"><a class="selflink" id="section-2.3.1" href="#section-2.3.1">2.3.1</a>. Sender Infrastructure</span>
Support for DSN [<a href="./rfc1891" title=""SMTP Service Extensions for Delivery Status Notifications"">RFC1891</a>] MUST be provided by the mail submission
server [<a href="./rfc2476" title=""Message Submission"">RFC2476</a>] used by the sender and MUST be provided up to the
mailer responsible for communicating with external (Internet)
mailers.
Also see <a href="#section-5.1">section 5.1</a> of this document.
<span class="h4"><a class="selflink" id="section-2.3.2" href="#section-2.3.2">2.3.2</a>. Receiver Infrastructure</span>
Support for DSN [<a href="./rfc1891" title=""SMTP Service Extensions for Delivery Status Notifications"">RFC1891</a>] MUST be provided by the external
(Internet-accessible) mailer, and MUST be provided by each mailer
between the external mailer and the recipient. If the recipient is
implemented as an SMTP server it MUST also support DSN [<a href="./rfc1891" title=""SMTP Service Extensions for Delivery Status Notifications"">RFC1891</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Additional Document Capabilities</span>
<a href="#section-4">Section 4</a> of "A Simple Mode of Facsimile Using Internet Mail"
[<a href="./rfc2305" title=""A Simple Mode of Facsimile Using Internet Mail"">RFC2305</a>] allows sending only the minimum subset of TIFF for
Facsimile "unless the sender has prior knowledge of other TIFF fields
or values supported by the recipient."
A recipient MAY support any or all (or any combination) of the TIFF
profiles defined in <a href="./rfc2301">RFC 2301</a>, in addition to profile S. A recipient
which supports additional profiles SHOULD indicate this support as
per <a href="#section-3.2">section 3.2</a> or 3.3 of this document. As a consequence, a sender
MAY use those additional TIFF profiles when sending to a recipient
with the corresponding capabilities.
A sender SHOULD be able to recognize and process the feature tags as
defined in [<a href="./rfc2531" title=""Content Feature Schema for Internet Fax"">RFC2531</a>] when reviewing the capabilities presented by a
potential recipient. The capability matching rules indicated there
(by reference to [<a href="./rfc2533" title=""A Syntax for Describing Media Feature Sets"">RFC2533</a>]) allow for the introduction of new
features that may be unrecognized by older implementations.
A sender MAY send a message containing both the minimum subset of
TIFF for Facsimile (as specified in [<a href="./rfc2305" title=""A Simple Mode of Facsimile Using Internet Mail"">RFC2305</a>]) and a higher quality
TIFF using multipart/alternative.
<span class="grey">Masinter & Wing Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc2532">RFC 2532</a> Extended Internet Fax March 1999</span>
Three methods for the sender to acquire such knowledge are described:
1. Sender manual configuration
2. Capabilities in Directory
3. Capabilities returned in MDN or DSN
Method (3) SHOULD be used.
An implementation may cache capabilities locally and lose
synchronization with the recipient's actual capabilities. A
mechanism SHOULD be provided to allow the sender to override the
locally-stored cache of capabilities. Also note <a href="#section-4.1">section 4.1</a> of this
document.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Sender Manual Configuration</span>
One way a sender can send a document which exceeds the minimum subset
allowed by [<a href="./rfc2305" title=""A Simple Mode of Facsimile Using Internet Mail"">RFC2305</a>] is for the user controlling the sender to
manually override the default settings, usually on a per-recipient
basis. For example, during transmission a user could indicate the
recipient is capable of receiving high resolution images or color
images.
While awkward and not automatic, this mechanism reflects the current
state of deployment of configuration for extended capabilities to
ordinary Internet email users.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Capabilities in Directory</span>
A future direction for enhanced document features is to create a
directory structure of recipient capabilities, deployed, for example,
through LDAP or DNS. The directory would provide a mechanism by which
a sender could determine a recipient's capabilities before message
construction or transmission, using a directory lookup. Such
mechanisms are not defined in this document.
There is active investigation within the IETF to develop a solution
to this problem, which would resolve a wide range of issues with
store-and-forward messaging.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Capabilities Returned in MDN or DSN</span>
As outlined in <a href="#section-2">section 2</a> of this document, a sender may request a
positive DSN or an MDN.
<span class="grey">Masinter & Wing Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc2532">RFC 2532</a> Extended Internet Fax March 1999</span>
If the recipient implements [<a href="./rfc2530" title=""Indicating Supported Media Features Using Extensions to DSN and MDN"">RFC2530</a>], the DSN or MDN that is
returned can contain information describing the recipient's
capabilities. The sender can use this information for subsequent
communications with that recipient.
The advantage of this approach is that additional infrastructure is
not required (unlike <a href="#section-3.2">section 3.2</a>), and the information is acquired
automatically (unlike <a href="#section-3.1">section 3.1</a>).
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>. Restrictions and Recommendations</span>
A sender MUST NOT send a message with no processable content to
attempt to elicit an MDN/DSN capability response. Doing so with a
message with no processable content (such as a message containing
only a request for capabilities or a blank message) will confuse a
recipient not already designed to understand the semantics of such a
message.
A recipient SHOULD indicate the profiles and features supported, even
if the recipient supports only Tiff Profile S (the minimum set for
fax as defined by [<a href="./rfc2305" title=""A Simple Mode of Facsimile Using Internet Mail"">RFC2305</a>]) [<a href="./rfc2531" title=""Content Feature Schema for Internet Fax"">RFC2531</a>]. This allows a sender to
determine that the recipient is compliant with this Extended
Facsimile Using Internet Mail specification.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
As this document is an extension of [<a href="./rfc2305" title=""A Simple Mode of Facsimile Using Internet Mail"">RFC2305</a>], the Security
Considerations section of [<a href="./rfc2305" title=""A Simple Mode of Facsimile Using Internet Mail"">RFC2305</a>] applies to this document.
The following additional security considerations are introduced by
the new features described in this document.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Inaccurate Capabilities Information</span>
Inaccurate capability information (<a href="#section-3">section 3</a>) could cause a denial of
service. The capability information could be inaccurate due to many
reasons, including compromised or improperly configured directory
server, improper manual configuration of sender, compromised DNS, or
spoofed MDN. If a sender is using cached capability information,
there SHOULD be a mechanism to allow the cached information to be
ignored or overridden if necessary.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Forged MDNs or DSNs</span>
Forged DSNs or MDNs, as described in [RFC1892, <a href="./rfc1894">RFC1894</a>, <a href="./rfc2298">RFC2298</a>] can
provide incorrect information to a sender.
<span class="grey">Masinter & Wing Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc2532">RFC 2532</a> Extended Internet Fax March 1999</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Implementation Notes</span>
This section contains notes to implementors.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Submit Mailer Does Not Support DSN</span>
In some installations the generally available submit server may not
support DSNs. In such circumstances, it may be useful for the sender
to implement [<a href="./rfc974" title=""Mail routing and the domain system"">RFC974</a>] mail routing as well as additional submission
server functions [<a href="./rfc2476" title=""Message Submission"">RFC2476</a>] so that the installation is not
constrained by limitations of the incumbent submission server.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Recipient Recommendations</span>
To provide a high degree of reliability, it is desirable for the
sender to know that a recipient could not process a message. The
inability to successfully process a message may be detectable by the
recipient's MTA or MUA.
If the recipient's MTA determines the message cannot be processed,
the recipient's MTA is strongly encouraged to reject the message with
a [<a href="./rfc1893" title=""Enhanced Mail System Status Codes"">RFC1893</a>] status code of 5.6.1. This status code may be returned
in response to the end-of-mail-data indicator if the MTA supports
reporting of enhanced error codes [<a href="./rfc2034" title=""SMTP Service Extension for Returning Enhanced Error Codes"">RFC2034</a>], or after message
reception by generating a delivery failure DSN ("bounce").
Note: Providing this functionality in the MTA, via either of the
two mechanisms described above, is superior to providing the
function using MDNs because MDNs must generally be requested
by the sender (and the request may, at any time, be ignored by
the receiver). Message rejection performed by the MTA can
always occur without the sender requesting such behavior and
without the receiver circumventing the behavior.
If the message contains an MDN request and the recipient's MUA
determines the message cannot be processed, the recipient's MUA is
strongly encouraged to repond to an MDN request and indicate that
processing failed with the disposition-type "processed" or
"displayed" and disposition-modifier "error" or "warning" [<a href="./rfc2298" title=""An Extensible Message Format for Message Disposition Notifications"">RFC2298</a>].
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Acknowledgements</span>
The authors would like to acknowledge the members of the IETF
Internet Fax working group, and especially the following contributors
who provided assistance and input during the development of this
document:
<span class="grey">Masinter & Wing Standards Track [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc2532">RFC 2532</a> Extended Internet Fax March 1999</span>
Vivian Cancio, Richard Coles, David Crocker, Ned Freed, Graham Klyne,
MAEDA Toru, Geoff Marshall, Lloyd McIntyre, Keith Moore, George
Pajari, James Rafferty, Mike Ruhl, Richard Shockey, Brian Stafford,
and Greg Vaudreuil.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
[<a id="ref-RFC2533">RFC2533</a>] Klyne, G., "A Syntax for Describing Media Feature Sets",
<a href="./rfc2533">RFC 2533</a>, March 1999.
[<a id="ref-RFC2531">RFC2531</a>] McIntyre, L. and G. Klyne, "Content Feature Schema for
Internet Fax", <a href="./rfc2531">RFC 2531</a>, March 1999.
[<a id="ref-RFC2530">RFC2530</a>] Wing, D., "Indicating Supported Media Features Using
Extensions to DSN and MDN", <a href="./rfc2530">RFC 2530</a>, March 1999.
[<a id="ref-RFC1891">RFC1891</a>] Moore, K. "SMTP Service Extensions for Delivery Status
Notifications", <a href="./rfc1891">RFC 1891</a>, January 1996.
[<a id="ref-RFC1893">RFC1893</a>] Vaudreuil, G., "Enhanced Mail System Status Codes", <a href="./rfc1893">RFC</a>
<a href="./rfc1893">1893</a>, January 1996.
[<a id="ref-RFC1894">RFC1894</a>] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", <a href="./rfc1894">RFC 1894</a>, January 1996.
[<a id="ref-RFC2034">RFC2034</a>] Freed, N, "SMTP Service Extension for Returning Enhanced
Error Codes", <a href="./rfc2034">RFC 2034</a>, October 1996.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC2298">RFC2298</a>] Fajman, R., "An Extensible Message Format for Message
Disposition Notifications", <a href="./rfc2298">RFC 2298</a>, March 1998.
[<a id="ref-RFC2301">RFC2301</a>] McIntyre, L., Zilles, S., Buckley, R., Venable, D.,
Parsons, G. and J. Rafferty, "File Format for Internet
Fax", <a href="./rfc2301">RFC 2301</a>, March 1998.
[<a id="ref-RFC2305">RFC2305</a>] Toyoda, K., Ohno, H., Murai, J. and D. Wing, "A Simple
Mode of Facsimile Using Internet Mail", <a href="./rfc2305">RFC 2305</a>, March
1998.
[<a id="ref-RFC974">RFC974</a>] Partridge. C., "Mail routing and the domain system", STD
14, <a href="./rfc974">RFC 974</a>, January 1986.
[<a id="ref-RFC2476">RFC2476</a>] Gellens, R. and J. Klensin, "Message Submission", <a href="./rfc2476">RFC 2476</a>,
December 1998.
<span class="grey">Masinter & Wing Standards Track [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc2532">RFC 2532</a> Extended Internet Fax March 1999</span>
[<a id="ref-RFC2542">RFC2542</a>] Masinter, L., "Terminology and Goals for Internet Fax", <a href="./rfc2542">RFC</a>
<a href="./rfc2542">2542</a>, March 1999.
[<a id="ref-T.30">T.30</a>] "Procedures for Document Facsimile Transmission in the
General Switched Telephone Network", ITU-T (CCITT),
Recommendation T.30, July, 1996.
[<a id="ref-RFC1939">RFC1939</a>] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, <a href="./rfc1939">RFC 1939</a>, May 1996.
[<a id="ref-RFC2060">RFC2060</a>] Crispin, M., "Internet Message Access Protocol - Version
4Rev1", <a href="./rfc2060">RFC 2060</a>, December 1996.
<span class="grey">Masinter & Wing Standards Track [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc2532">RFC 2532</a> Extended Internet Fax March 1999</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Authors' Addresses</span>
Larry Masinter
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA 94304 USA
Fax: +1 650 812 4333
EMail: [email protected]
Dan Wing
Cisco Systems, Inc.
101 Cooper Street
Santa Cruz, CA 95060 USA
Phone: +1 831 457 5200
Fax: +1 831 457 5208
EMail: [email protected]
<span class="grey">Masinter & Wing Standards Track [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc2532">RFC 2532</a> Extended Internet Fax March 1999</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Full Copyright Statement</span>
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 & Wing Standards Track [Page 12]
Annotations
Select text to annotate