One document matched: draft-ietf-fax-eifax-05.txt
Differences from draft-ietf-fax-eifax-04.txt
Internet Fax Working Group Larry Masinter
Internet Draft Xerox Corporation
September 30, 1998 Dan Wing
Expires March 1999 Cisco Systems
draft-ietf-fax-eifax-05.txt
Extended Facsimile Using Internet Mail
Status of this memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
This draft is a product of the IETF Internet Fax working group. To
subscribe to the mailing list, send a message to
ietf-fax-request@imc.org with the line "subscribe" in the body of the
message. Archives are available from http://www.imc.org/ietf-fax.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
This document describes extensions to 'Simple Mode of Facsimile Using
Internet Mail' [RFC2305] and provides 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.
Masinter, Wing Expires January 1999 [Page 1]
Internet Draft Extended Internet Fax September 1998
1. Introduction
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 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 two features described in its companion
document, [GOALS]:
* Delivery confirmation (Section 2) (required)
* Additional document features (Section 3) (optional)
1.1. Definition of terms
The term "processing" indicates the ability to successfully render or
successfully transmit the contents of the message to a printer, on a
display device, or to a fax machine.
The term "recipient" indicates the device which processes the content
of the mail message and renders it to the user by transmitting it to
a remote fax machine, printer, displaying it on a terminal. For
example, a recipient could be implemented as a traditional Mail User
Agent on a PC, a standalone device which retreives 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
Masinter, Wing Expires January 1999 [Page 2]
Internet Draft Extended Internet Fax September 1998
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
these two operations are supplied by two different standards-track
documents: Delivery Status Notifications (DSN) [RFC1891, RFC1894]
and Message Disposition Notifications (MDN) [RFC2298], respectively.
This section defines requirements for devices or services that are to
be considered compliant with the delivery and processing confirmation
section of this memo.
2.1. Sender Requirements
A delivery failure message (in a non-standard format or in the format
described by [RFC1894]) 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.
2.1.1. Delivery Confirmation
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 [section 5.1 of RFC1891].
2.1.2. Processing Confirmation
If the sender desires processing confirmation, the sender MUST
request Message Disposition Notification using the method described
in section 2 of [RFC2298].
Because a recipient can always silently ignore a request
for an MDN [section 2.1 of RFC2298]:
* 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
always responded to MDNs in the past.
The address provided by the sender on the Disposition-Notification-To
field MUST be able to receive Message Disposition Notifications
messages [RFC2298] and 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
Masinter, Wing Expires January 1999 [Page 3]
Internet Draft Extended Internet Fax September 1998
Disposition-Notification-To field).
2.2. Recipient Requirements
Recipients in compliance with this document SHOULD implement MDN
[RFC2298], and SHOULD implement Offramp Gateway Extensions for DSN
and MDN [REPORT-EXTENSIONS].
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 section 5.
2.2.1. MDN Recipient Requirements
Recipients MUST be configurable to silently ignore a request for an
MDN ([section 2.1 of RFC2298]).
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, but a recipient MAY generate an unsolicited
MDN (sent to the envelope-from (Return-Path:) address) to indicate
processing failure following the rules in the above paragraph.
2.2.2. Recipients using Mailbox Access Protocols
A recipient using [POP3] or [IMAP4] to retrieve its mail is not
allowed to generate a Delivery Status Notification message [RFC1894].
The recipient MUST NOT use anything but the POP/IMAP username to map
to a single destination. For example, using any RFC822 field or
information within the message body or MIME parts to make a decision
about the destination is not permitted.
2.3. Messaging Infrastructure Requirements
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.
2.3.1. Sender Infrastructure
Masinter, Wing Expires January 1999 [Page 4]
Internet Draft Extended Internet Fax September 1998
For the sender's infrastructure to provide conformance with
this document, support for DSN [RFC1891] MUST be provided by the mail
submission server [SUBMIT] used by the sender and MUST be provided
up to the mailer responsible for communicating with external
(Internet) mailers.
Also see section 5.1 of this document.
2.3.2. Receiver Infrastructure
Support for DSN [RFC1891] 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 [RFC1891].
3. Additional document capabilities
Section 4 of [RFC2305] only allows sending 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 SHOULD indicate which features and values from among
those available in [FAX-SCHEMA] are supported using one of the
mechanisms defined below.
Three methods for the sender to acquire such knowledge are
permitted:
1. Sender manual configuration
2. Capabilities in Directory
3. Capabilities returned in MDN or DSN
In any implementation it possible for a locally-stored
cache of capabilities to 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 section 4.1 of this
document.
3.1. Sender manual configuration
One way a sender can send a document which exceeds the minimum
subset allowed by [RFC2305] 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.
Masinter, Wing Expires January 1999 [Page 5]
Internet Draft Extended Internet Fax September 1998
While awkward and not automatic, this mechanism reflects the current
state of deployment of configuration for extended capabilities to
ordinary Internet email users.
3.2. Capabilities in Directory
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.
3.3. Capabilities Returned in MDN or DSN
As outlined in section 2 of this document, a sender may request a
positive DSN or an MDN.
If the recipient implements [REPORTING-EXTENSIONS], 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 section 3.2), and the information is acquired
automatically (unlike section 3.1).
4. Security Considerations
As this document is an extension of [RFC2305], the Security
Considerations section of [RFC2305] applies to this document.
The following additional security considerations are introduced by
the new features described in this document.
4.1. Inaccurate Capabilities Information
Inaccurate capability information (section 3) 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, it SHOULD be manually confirmed by a user
before it is automatically used.
Masinter, Wing Expires January 1999 [Page 6]
Internet Draft Extended Internet Fax September 1998
4.2. Forged MDNs or DSNs
Forged DSNs or MDNs, as described in [RFC1892, RFC1894, RFC2298]
can provide incorrect information to a sender.
5. Implementation Notes
This section contains notes to implementors.
5.1. Submit mailer does not support DSN
In some installations the generally available submit server may not
support DSNs. In such circumstances, it may be useful for the sender
to implement [RFC974] mail routing as well as additional submission
server functions [SUBMIT] so that the installation is not constrained
by limitations of the incumbent submission server.
5.2. Recipient Recommendations
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 [RFC1893bis] status code of 5.6.--???-TBD-????--. This status code
may be returned in response to the end-of-mail-data indicator if the
MTA supports [RFC2034], or after message reception by generating a
delivery failure DSN ("bounce").
Note: Because DSN bounces are not requested by the sender and are
not 'approved' by the receiver, DSNs can provide a more robust
mechanism than performing this function in the MUA using MDNs.
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" [RFC2298].
6. Acknowledgements
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: Vivian Cancio, Richard Coles, David Crocker, Ned Freed,
Masinter, Wing Expires January 1999 [Page 7]
Internet Draft Extended Internet Fax September 1998
Graham Klyne, MAEDA Toru, Geoff Marshall, Keith Moore, George Pajari,
James Rafferty, Mike Ruhl, Richard Shockey, Brian Stafford, and
Greg Vaudreuil.
7. References
[FAX-SCHEMA] L. McIntyre, G. Klyne, "Content feature schema for
Internet fax", Internet Draft, Work in Progress,
draft-ietf-fax-feature-schema-XX.txt.
[GOALS] L. Masinter, "Terminology and Goals for Internet Fax",
Internet Draft, Work in Progress, draft-ietf-fax-goals-XX.txt,
LAST CALL.
[REPORT-EXTENSIONS] D. Wing, "Offramp Gateway Extensions to DSN and
MDN", Internet Draft, Work in Progress,
draft-ietf-fax-reporting-extensions-XX.txt.
[RFC1891] K. Moore, "SMTP Service Extensions for Delivery Status
Notifications", RFC 1891, January 1996.
[RFC1893bis] G. Vaudreuil, "Enhanced Mail System Status Codes",
Internet Draft, Work in Progress, (update to RFC 1893).
[RFC1894] K. Moore, G. Vaudreuil, "An Extensible Message Format for
Delivery Status Notifications", RFC 1894, January 1996.
[RFC2034] N. Freed, "SMTP Service Extension for Returning Enhanced
Error Codes", RFC 2034, October 1996.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2298] R. Fajman, "An Extensible Message Format for Message
Disposition Notifications", RFC 2298, March 1998.
[RFC2305] K. Toyoda, H. Ohno, J. Murai, D. Wing, "A Simple Mode of
Facsimile Using Internet Mail", RFC 2305, March 1998.
[RFC974] C. Partridge. "Mail routing and the domain system", RFC 974,
January 1986.
[SUBMIT] R. Gellens, J. Klensin, "Message Submission", Internet
Draft, Work in Progress, draft-gellens-submit-XX.txt.
8. Authors' Addresses
Larry Masinter
Masinter, Wing Expires January 1999 [Page 8]
Internet Draft Extended Internet Fax September 1998
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA 94304 USA
Fax: +1 415 812 4333
EMail: masinter@parc.xerox.com
Dan Wing
Cisco Systems, Inc.
101 Cooper Street
Santa Cruz, CA 95060 USA
Phone: +1 831 457 5200
Fax: +1 831 457 5208
EMail: dwing@cisco.com
9. Copyright
Copyright (C) The Internet Society 1998. 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 Expires January 1999 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 05:48:47 |