rfc2532.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                        L. Masinter
Request for Comments: 2532                             Xerox Corporation
Category: Standards Track                                        D. Wing
                                                           Cisco Systems
                                                              March 1999


                 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 Notice

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

Abstract

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

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



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
   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 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]

RFC 2532                 Extended Internet Fax                March 1999


   these two operations are supplied by two different standards-track
   mechanisms: 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 this document.

2.1.  Sender Requirements

   Because delivery failure may occur (over disk quota, user no longer
   exists, malconfigured mailer), a delivery failure message (in the
   format described by [RFC1894] 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.

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 ([RFC2298] section 2) when
   sending the message itself.

   Because a recipient may silently ignore a request for an MDN (section
   2.1 of [RFC2298]) 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 [RFC2298] 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 (section
   2.1 of [RFC2298]).




Masinter & Wing             Standards Track                     [Page 3]

RFC 2532                 Extended Internet Fax                March 1999


2.2.   Recipient Requirements

   Recipients SHOULD implement Message Disposition Notifications
   [RFC2298] and SHOULD indicate supported media features in DSN and MDN
   messages per [RFC2530].

   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.  A recipient MAY generate an unsolicited MDN
   (sent to the envelope-from (Return-Path:) address) to indicate
   processing failure, but subject to the [RFC2298] requirement that it
   MUST always be possible for an operator to disable unsolicited MDN
   generation.

2.2.2.  Recipients Using Mailbox Access Protocols

   A recipient using POP3 [RFC1939] or IMAP4 [RFC2060] to retrieve its
   mail MUST NOT generate a Delivery Status Notification message
   [RFC1894] 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 RFC822 "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 RFC822 or MIME fields for making
   such determinations.









Masinter & Wing             Standards Track                     [Page 4]

RFC 2532                 Extended Internet Fax                March 1999


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

   Support for DSN [RFC1891] MUST be provided by the mail submission
   server [RFC2476] 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 "A Simple Mode of Facsimile Using Internet Mail"
   [RFC2305] 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 RFC 2301, in addition to profile S.  A recipient
   which supports additional profiles SHOULD indicate this support as
   per section 3.2 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 [RFC2531] when reviewing the capabilities presented by a
   potential recipient.  The capability matching rules indicated there
   (by reference to [RFC2533]) 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 [RFC2305]) and a higher quality
   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 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 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.

   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.







Masinter & Wing             Standards Track                     [Page 6]