As per Relevance of the word standards, we have this rfc below:
Network Working Group L.
Request for Comments: 2532 Xerox
Category: Standards Track D.
Cisco
March 1999
Extended Facsimile Using Internet
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document describes extensions to "Simple Mode of Facsimile
Internet Mail" [RFC2305] and describes additional features,
transmission of enhanced document characteristics (higher resolution
color) and confirmation of delivery and processing
These additional features are designed to provide the highest
of interoperability with the existing and future standards-
email infrastructure and mail user agents, while providing a level
service that approximates the level currently enjoyed by fax users
The IETF has been notified of intellectual property rights claimed
regard to some or all of the specification contained in
document. For more information consult the online list of
rights in .
1.
This document notes a number of enhancements to the "Simple Mode
Facsimile Using Internet Mail" [RFC2305] that may be combined
create an extended mode of facsimile using Internet mail
The new features are designed to be interoperable with the
base of mail transfer agents (MTAs) and mail user agents (MUAs),
take advantage of existing standards for advanced functionality
as positive delivery confirmation and disposition notification.
Masinter & Wing Standards Track [Page 1]
RFC 2532 Extended Internet Fax March 1999
enhancements described in this document utilize the
infrastructure, where possible, instead of creating fax-
features which are unlikely to be implemented in non-fax
software
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
"Terminology and Goals for Internet Fax" [RFC2542].
1.1. Definition of
The term "processing" indicates the action of rendering
transmitting the contents of the message to a printer,
device, or fax machine
The term "processing confirmation" is an indication by the
of a message that it is able to process the contents of that message
The term "recipient" indicates the device which performs
processing function. For example, a recipient could be
as a traditional Mail User Agent on a PC, a standalone device
retrieves mail using POP3 or IMAP, an SMTP server which
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
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
SMTP to GSTN fax ("offramps") are not described in this document
However, such gateways SHOULD have the behavior characteristics
senders and recipients as described in this document
2. Delivery and Processing
In traditional GSTN-based realtime facsimile, the receiving
acknowledges successful receipt and processing of every page [T.30].
In Internet Mail, the operations of Delivery (to the mailbox)
Disposition (to paper or a screen) may be separated in time (due
store and forwarding of messages) and location (due to separation
delivery agent (MTA) and user agent (MUA)). The confirmation
Masinter & Wing Standards Track [Page 2]
RFC 2532 Extended Internet Fax March 1999
these two operations are supplied by two different standards-
mechanisms: Delivery Status Notifications (DSN) [RFC1891, RFC1894]
and Message Disposition Notifications (MDN) [RFC2298], respectively
This section defines requirements for devices or services that are
be considered compliant with this document
2.1. Sender
Because delivery failure may occur (over disk quota, user no
exists, malconfigured mailer), a delivery failure message (in
format described by [RFC1894] or otherwise) may be sent to
envelope-from address specified by the sender. Thus, the envelope
from address supplied by the sender MUST be able to properly
such delivery failure messages
2.1.1. Delivery
If the sender desires delivery confirmation, the sender MUST
Delivery Status Notification by including the the esmtp-
NOTIFY with the esmtp-value SUCCESS (section 5.1 of [RFC1891]).
2.1.2. Processing
If the sender desires processing confirmation, the sender
request Message Disposition Notification ([RFC2298] section 2)
sending the message itself
Because a recipient may silently ignore a request for an MDN (
2.1 of [RFC2298]) at any time
* MDNs MUST NOT be used for delivery confirmation, but are
useful for disposition ("processing") notification
* the sender MUST NOT assume the recipient will respond to an
request in a subsequent message, even if the recipient has
so in the past
The address provided by the sender on the Disposition-Notification-
field MUST be able to receive Message Disposition
messages [RFC2298] and SHOULD be able to receive messages that
not in the Message Disposition Notification format (due to
existence of legacy systems that generate non-RFC2298-
responses to the Disposition-Notification-To field).
Disposition-Notification-To address and the envelope-from
SHOULD match to allow automated responses to MDN requests (
2.1 of [RFC2298]).
Masinter & Wing Standards Track [Page 3]
RFC 2532 Extended Internet Fax March 1999
2.2. Recipient
Recipients SHOULD implement Message Disposition
[RFC2298] and SHOULD indicate supported media features in DSN and
messages per [RFC2530].
If the recipient is an SMTP server, it behaves as part of
receiver infrastructure and is therefore subject to the "
Infrastructure" requirements of this document
See also "Recipient Recommendations" in section 5.
2.2.1. MDN Recipient
Recipients MUST be configurable to silently ignore a request for
MDN (section 2.1 of [RFC2298]).
If the recipient is an automated message processing system which
not associated with a person, the device MAY be configurable
always respond to MDN requests, but in all cases MUST be
to never generate MDNs
A recipient MUST NOT generate an unsolicited MDN to
successful processing. A recipient MAY generate an unsolicited
(sent to the envelope-from (Return-Path:) address) to
processing failure, but subject to the [RFC2298] requirement that
MUST always be possible for an operator to disable unsolicited
generation
2.2.2. Recipients Using Mailbox Access
A recipient using POP3 [RFC1939] or IMAP4 [RFC2060] to retrieve
mail MUST NOT generate a Delivery Status Notification
[RFC1894] because such a notification, if it was requested,
have already been issued by the MTA on delivery to the POP3 or IMAP
message store
The recipient MUST NOT use the RFC822 "To:" fields, "Cc:" fields
"Bcc:" fields, or any other fields containing header
information to determine the ultimate destination mailbox
addressee, and SHOULD NOT use other RFC822 or MIME fields for
such determinations
Masinter & Wing Standards Track [Page 4]
RFC 2532 Extended Internet Fax March 1999
2.3. Messaging Infrastructure
This section explains the requirements of the SMTP
infrastructure used by the sender and receiver. This
is commonly provided by the ISP or a company's internal mailers
can actually be provided by another organization with
service contracts
2.3.1. Sender
Support for DSN [RFC1891] MUST be provided by the mail
server [RFC2476] used by the sender and MUST be provided up to
mailer responsible for communicating with external (Internet
mailers
Also see section 5.1 of this document
2.3.2. Receiver
Support for DSN [RFC1891] MUST be provided by the
(Internet-accessible) mailer, and MUST be provided by each
between the external mailer and the recipient. If the recipient
implemented as an SMTP server it MUST also support DSN [RFC1891].
3. Additional Document
Section 4 of "A Simple Mode of Facsimile Using Internet Mail
[RFC2305] allows sending only the minimum subset of TIFF
Facsimile "unless the sender has prior knowledge of other TIFF
or values supported by the recipient."
A recipient MAY support any or all (or any combination) of the
profiles defined in RFC 2301, in addition to profile S. A
which supports additional profiles SHOULD indicate this support
per section 3.2 or 3.3 of this document. As a consequence, a
MAY use those additional TIFF profiles when sending to a
with the corresponding capabilities
A sender SHOULD be able to recognize and process the feature tags
defined in [RFC2531] when reviewing the capabilities presented by
potential recipient. The capability matching rules indicated
(by reference to [RFC2533]) allow for the introduction of
features that may be unrecognized by older implementations
A sender MAY send a message containing both the minimum subset
TIFF for Facsimile (as specified in [RFC2305]) and a higher
TIFF using multipart/alternative
Masinter & Wing Standards Track [Page 5]
RFC 2532 Extended Internet Fax March 1999
Three methods for the sender to acquire such knowledge are described
1. Sender manual
2. Capabilities in
3. Capabilities returned in MDN or
Method (3) SHOULD be used
An implementation may cache capabilities locally and
synchronization with the recipient's actual capabilities.
mechanism SHOULD be provided to allow the sender to override
locally-stored cache of capabilities. Also note section 4.1 of
document
3.1. Sender Manual
One way a sender can send a document which exceeds the minimum
allowed by [RFC2305] is for the user controlling the sender
manually override the default settings, usually on a per-
basis. For example, during transmission a user could indicate
recipient is capable of receiving high resolution images or
images
While awkward and not automatic, this mechanism reflects the
state of deployment of configuration for extended capabilities
ordinary Internet email users
3.2. Capabilities in
A future direction for enhanced document features is to create
directory structure of recipient capabilities, deployed, for example
through LDAP or DNS. The directory would provide a mechanism by
a sender could determine a recipient's capabilities before
construction or transmission, using a directory lookup.
mechanisms are not defined in this document
There is active investigation within the IETF to develop a
to this problem, which would resolve a wide range of issues
store-and-forward messaging
3.3. Capabilities Returned in MDN or
As outlined in section 2 of this document, a sender may request
positive DSN or an MDN
Masinter & Wing Standards Track [Page 6]
RFC 2532 Extended Internet Fax March 1999
If the recipient implements [RFC2530], the DSN or MDN that
returned can contain information describing the recipient'
capabilities. The sender can use this information for
communications with that recipient
The advantage of this approach is that additional infrastructure
not required (unlike section 3.2), and the information is
automatically (unlike section 3.1).
3.3.1. Restrictions and
A sender MUST NOT send a message with no processable content
attempt to elicit an MDN/DSN capability response. Doing so with
message with no processable content (such as a message
only a request for capabilities or a blank message) will confuse
recipient not already designed to understand the semantics of such
message
A recipient SHOULD indicate the profiles and features supported,
if the recipient supports only Tiff Profile S (the minimum set
fax as defined by [RFC2305]) [RFC2531]. This allows a sender
determine that the recipient is compliant with this
Facsimile Using Internet Mail specification
4. Security
As this document is an extension of [RFC2305], the
Considerations section of [RFC2305] applies to this document
The following additional security considerations are introduced
the new features described in this document
4.1. Inaccurate Capabilities
Inaccurate capability information (section 3) could cause a denial
service. The capability information could be inaccurate due to
reasons, including compromised or improperly configured
server, improper manual configuration of sender, compromised DNS,
spoofed MDN. If a sender is using cached capability information
there SHOULD be a mechanism to allow the cached information to
ignored or overridden if necessary
4.2. Forged MDNs or
Forged DSNs or MDNs, as described in [RFC1892, RFC1894, RFC2298]
provide incorrect information to a sender
Masinter & Wing Standards Track [Page 7]
RFC 2532 Extended Internet Fax March 1999
5. Implementation
This section contains notes to implementors
5.1. Submit Mailer Does Not Support
In some installations the generally available submit server may
support DSNs. In such circumstances, it may be useful for the
to implement [RFC974] mail routing as well as additional
server functions [RFC2476] so that the installation is
constrained by limitations of the incumbent submission server
5.2. Recipient
To provide a high degree of reliability, it is desirable for
sender to know that a recipient could not process a message.
inability to successfully process a message may be detectable by
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
a [RFC1893] status code of 5.6.1. This status code may be
in response to the end-of-mail-data indicator if the MTA
reporting of enhanced error codes [RFC2034], or after
reception by generating a delivery failure DSN ("bounce").
Note: Providing this functionality in the MTA, via either of
two mechanisms described above, is superior to providing
function using MDNs because MDNs must generally be
by the sender (and the request may, at any time, be ignored
the receiver). Message rejection performed by the MTA
always occur without the sender requesting such behavior
without the receiver circumventing the behavior
If the message contains an MDN request and the recipient's
determines the message cannot be processed, the recipient's MUA
strongly encouraged to repond to an MDN request and indicate
processing failed with the disposition-type "processed"
"displayed" and disposition-modifier "error" or "warning" [RFC2298].
6.
The authors would like to acknowledge the members of the
Internet Fax working group, and especially the following
who provided assistance and input during the development of
document
Masinter & Wing Standards Track [Page 8]
RFC 2532 Extended Internet Fax March 1999
Vivian Cancio, Richard Coles, David Crocker, Ned Freed, Graham Klyne
MAEDA Toru, Geoff Marshall, Lloyd McIntyre, Keith Moore,
Pajari, James Rafferty, Mike Ruhl, Richard Shockey, Brian Stafford
and Greg Vaudreuil
7.
[RFC2533] Klyne, G., "A Syntax for Describing Media Feature Sets",
RFC 2533, March 1999.
[RFC2531] McIntyre, L. and G. Klyne, "Content Feature Schema
Internet Fax", RFC 2531, March 1999.
[RFC2530] Wing, D., "Indicating Supported Media Features
Extensions to DSN and MDN", RFC 2530, March 1999.
[RFC1891] Moore, K. "SMTP Service Extensions for Delivery
Notifications", RFC 1891, January 1996.
[RFC1893] Vaudreuil, G., "Enhanced Mail System Status Codes",
1893, January 1996.
[RFC1894] Moore, K. and G. Vaudreuil, "An Extensible Message
for Delivery Status Notifications", RFC 1894, January 1996.
[RFC2034] Freed, N, "SMTP Service Extension for Returning
Error Codes", RFC 2034, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2298] Fajman, R., "An Extensible Message Format for
Disposition Notifications", RFC 2298, March 1998.
[RFC2301] McIntyre, L., Zilles, S., Buckley, R., Venable, D.,
Parsons, G. and J. Rafferty, "File Format for
Fax", RFC 2301, March 1998.
[RFC2305] Toyoda, K., Ohno, H., Murai, J. and D. Wing, "A
Mode of Facsimile Using Internet Mail", RFC 2305,
1998.
[RFC974] Partridge. C., "Mail routing and the domain system",
14, RFC 974, January 1986.
[RFC2476] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
December 1998.
Masinter & Wing Standards Track [Page 9]
RFC 2532 Extended Internet Fax March 1999
[RFC2542] Masinter, L., "Terminology and Goals for Internet Fax",
2542, March 1999.
[T.30] "Procedures for Document Facsimile Transmission in
General Switched Telephone Network", ITU-T (CCITT),
Recommendation T.30, July, 1996.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996.
[RFC2060] Crispin, M., "Internet Message Access Protocol -
4Rev1", RFC 2060, December 1996.
Masinter & Wing Standards Track [Page 10]
RFC 2532 Extended Internet Fax March 1999
8. Authors'
Larry
Xerox Palo Alto Research
3333 Coyote Hill
Palo Alto, CA 94304
Fax: +1 650 812 4333
EMail: masinter@parc.xerox.
Dan
Cisco Systems, Inc
101 Cooper
Santa Cruz, CA 95060
Phone: +1 831 457 5200
Fax: +1 831 457 5208
EMail: dwing@cisco.
Masinter & Wing Standards Track [Page 11]
RFC 2532 Extended Internet Fax March 1999
9. Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Masinter & Wing Standards Track [Page 12]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
