rfc2532.txt

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


RFC 2532                 Extended Internet Fax                March 1999


   If the recipient implements [RFC2530], 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).

3.3.1.  Restrictions and Recommendations

   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 [RFC2305]) [RFC2531].  This allows a sender to
   determine that the recipient is compliant with this Extended
   Facsimile Using Internet Mail specification.

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,
   there SHOULD be a mechanism to allow the cached information to be
   ignored or overridden if necessary.

4.2.  Forged MDNs or DSNs

   Forged DSNs or MDNs, as described in [RFC1892, RFC1894, RFC2298] can
   provide incorrect information to a sender.





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


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 [RFC2476] 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 [RFC1893] 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 [RFC2034], 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" [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:





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, George
   Pajari, James Rafferty, Mike Ruhl, Richard Shockey, Brian Stafford,
   and Greg Vaudreuil.

7.  References

   [RFC2533] Klyne, G., "A Syntax for Describing Media Feature Sets",
             RFC 2533, March 1999.

   [RFC2531] McIntyre, L. and G. Klyne, "Content Feature Schema for
             Internet Fax", RFC 2531, March 1999.

   [RFC2530] Wing, D., "Indicating Supported Media Features Using
             Extensions to DSN and MDN", RFC 2530, March 1999.

   [RFC1891] Moore, K. "SMTP Service Extensions for Delivery Status
             Notifications", RFC 1891, January 1996.

   [RFC1893] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
             1893, January 1996.

   [RFC1894] Moore, K. and G. Vaudreuil, "An Extensible Message Format
             for Delivery Status Notifications", RFC 1894, January 1996.

   [RFC2034] Freed, N, "SMTP Service Extension for Returning Enhanced
             Error Codes", RFC 2034, October 1996.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2298] Fajman, R., "An Extensible Message Format for Message
             Disposition Notifications", RFC 2298, March 1998.

   [RFC2301] McIntyre, L., Zilles, S., Buckley, R., Venable, D.,
             Parsons, G. and J. Rafferty, "File Format for Internet
             Fax", RFC 2301, March 1998.

   [RFC2305] Toyoda, K., Ohno, H., Murai, J. and  D. Wing, "A Simple
             Mode of Facsimile Using Internet Mail", RFC 2305, March
             1998.

   [RFC974]  Partridge. C.,  "Mail routing and the domain system", STD
             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", RFC
             2542, March 1999.

   [T.30]    "Procedures for Document Facsimile Transmission in the
             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 - Version
             4Rev1", RFC 2060, December 1996.







































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


8. Authors' Addresses

   Larry Masinter
   Xerox Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, CA 94304  USA

   Fax:    [phone]
   EMail:  [e-mail]

   Dan Wing
   Cisco Systems, Inc.
   101 Cooper Street
   Santa Cruz, CA 95060  USA

   Phone:  [phone]
   Fax:    [phone]
   EMail:  [e-mail]

































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


9.  Full Copyright Statement

   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]