doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc4142.txt b/doc/rfc/rfc4142.txt
new file mode 100644
index 0000000..9a2b34e
--- /dev/null
+++ b/doc/rfc/rfc4142.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                         D. Crocker
+Request for Comments: 4142                                   Brandenburg
+Category: Standards Track                                       G. Klyne
+                                                            Nine by Nine
+                                                           November 2005
+
+
+            Full-mode Fax Profile for Internet Mail (FFPIM)
+
+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 (2005).
+
+Abstract
+
+   Classic facsimile document exchange represents both a set of
+   technical specifications and a class of service.  Previous work has
+   replicated some of that service class as a profile within Internet
+   mail.  The current specification defines "full mode" carriage of
+   facsimile data over the Internet, building upon that previous work
+   and adding the remaining functionality necessary for achieving
+   reliability and capability negotiation for Internet mail, on a par
+   with classic T.30 facsimile.  These additional features are designed
+   to provide the highest level of interoperability with the
+   standards-compliant email infrastructure and mail user agents, while
+   providing a level of service that approximates what is currently
+   enjoyed by fax users.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crocker & Klyne             Standards Track                     [Page 1]
+
+RFC 4142                         FFPIM                     November 2005
+
+
+Table of Contents
+
+   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2. Content Negotiation  . . . . . . . . . . . . . . . . . . . . . . 3
+      2.1. UA-based Content Negotiation. . . . . . . . . . . . . . . . 3
+      2.2. ESMTP-based Content Negotiation . . . . . . . . . . . . . . 3
+      2.3. Interactions between UA and ESMTP Negotiation Mechanisms. . 4
+   3. Content Format . . . . . . . . . . . . . . . . . . . . . . . . . 4
+   4. Security Considerations  . . . . . . . . . . . . . . . . . . . . 4
+   5. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+      5.1. Normative References. . . . . . . . . . . . . . . . . . . . 5
+      5.2. Informative References. . . . . . . . . . . . . . . . . . . 6
+   A. Direct Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+   B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
+
+1.  Introduction
+
+   This specification defines "full mode" carriage of facsimile data
+   over the Internet, building upon previous work in A Simple Mode of
+   Facsimile Using Internet Mail [RFC3965] and Extended Facsimile Using
+   Internet Mail [RFC2532].  This specification also adds the remaining
+   functionality necessary to achieve reliable and capable negotiation
+   for Internet mail, on par with classic [T30] facsimile.  These
+   additional features are designed to provide the highest level of
+   interoperability with the standards-compliant email infrastructure
+   and mail user agents, while providing a level of service that closely
+   approximates the level of service currently enjoyed by fax users.
+
+   Basic terminology is discussed in [RFC2542].  Implementations that
+   conform to this specification MUST also conform to [RFC3965] and
+   [RFC2532].
+
+   The new features are designed to be interoperable with the existing
+   base of mail transfer agents (MTAs) and mail user agents (MUAs), and
+   to take advantage of existing standards for optional functionality
+   (e.g., positive delivery confirmation and disposition notification).
+   Enhancements described in this document utilize the existing Internet
+   email messaging infrastructure, where possible, instead of creating
+   fax-specific features that are unlikely to be implemented in non-fax
+   messaging software.
+
+   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].
+
+
+
+
+
+
+
+Crocker & Klyne             Standards Track                     [Page 2]
+
+RFC 4142                         FFPIM                     November 2005
+
+
+2.  Content Negotiation
+
+   Classic facsimile service is interactive, such that a sending station
+   can discover the capabilities of the receiving station, prior to
+   sending a facsimile of a document.  This permits the sender to
+   transmit the best quality of facsimile supported by both the sending
+   station and the receiving station.  Internet mail is
+   store-and-forward, with potentially long latency, such that
+   before-the-fact negotiation is problematic.
+
+   Use of a negotiation mechanism permits senders to transfer a richer
+   document form than is permitted when using the safer-but-universal
+   default form.  Without this mechanism, the sender of a document
+   cannot be certain that the receiving station will be able to support
+   the form.
+
+   The capabilities that can be negotiated by an FFPIM participant are
+   specified in [RFC2534] and [RFC2879].  Implementations that are
+   conformant to FFPIM MUST support content negotiation as described
+   there.
+
+2.1.  UA-based Content Negotiation
+
+   One method for exchanging the capabilities information uses a
+   post-hoc technique, which permits an originator to send the best
+   version known to be supported by the recipient, and to also send a
+   better suited version if the recipient requests it.  This mechanism
+   is specified in [RFC3297].  FFPIM implementations MUST support this
+   mechanism.
+
+2.2.  ESMTP-based Content Negotiation
+
+   Another method uses an ESMTP option specified in [RFC4141].  It
+   requires support for content negotiation along the entire path the
+   email travels.  Using this mechanism, receiving ESMTP servers are
+   able to report capabilities of the addresses (mailboxes) they
+   support, and sending email clients are able to signal both permission
+   and constraints on conversions.
+
+   FFPIM participants MAY support this mechanism.
+
+   NOTE: This specification provides for content conversion by
+      unspecified intermediaries.  Use of this mechanism carries
+      significant risk.  Although intermediaries always have the ability
+      to perform damaging transformations, use of this specification
+      could result in more exploitation of that potential and,
+      therefore, more misbehavior.  Use of intermediaries is discussed
+      in [RFC3238].
+
+
+
+Crocker & Klyne             Standards Track                     [Page 3]
+
+RFC 4142                         FFPIM                     November 2005
+
+
+2.3.  Interactions between UA and ESMTP Negotiation Mechanisms
+
+   FFPIM participants must ensure that their use of the UA and ESMTP
+   methods for content negotiation is compatible.  For example, two
+   mechanisms might consult two different repositories of capabilities
+   information, and those repositories might contain different
+   information.  Presumably, this means that at least one of these
+   repositories is inaccurate.  Therefore, the larger problem is one of
+   correctness, rather than synchronization.
+
+   This specification does not require a particular method of using the
+   mechanisms together.
+
+3.  Content Format
+
+   FFPIM allows the transfer of enhanced TIFF data relative to [RFC3965]
+   and [RFC2532].  The details for these enhancements are contained in
+   [RFC3949].  Implementations that are conformant to FFPIM SHOULD
+   support TIFF enhancements.
+
+   It should also be noted that the content negotiation mechanism
+   permits a sender to know the full range of content types that are
+   supported by the recipient.  Therefore, requirements for support of
+   TIFF represent a functional minimum for FFPIM.
+
+4.  Security Considerations
+
+   As this document is an extension of [RFC3965] and [RFC2532], the
+   Security Considerations sections of [RFC3965] and [RFC2532] apply to
+   this document, including discussion of PGP and S/MIME use for
+   authentication and privacy.
+
+   It appears that the mechanisms added by this specification do not
+   introduce new security considerations.  However, the concerns raised
+   in [RFC2532] are particularly salient for these new mechanisms.
+
+   Use of this specification should occur with particular attention to
+   the following security concerns:
+
+   * Negotiation can be used as a denial of service attack.
+
+   * Negotiation may lead to the use of an unsafe data format.
+
+   * Negotiation discloses information and therefore raises privacy
+     concerns.
+
+
+
+
+
+
+Crocker & Klyne             Standards Track                     [Page 4]
+
+RFC 4142                         FFPIM                     November 2005
+
+
+   Use of the ESMTP CONNEG option permits content transformation by an
+   intermediary, along the mail transfer path.  When the contents are
+   encrypted, the intermediary cannot perform the conversion, because it
+   is not expected to have access to the relevant secret keying
+   material.  When the contents are signed, but not encrypted,
+   conversion will invalidate the signature.  Therefore, permission to
+   convert SHOULD NOT normally be used with signed or sealed messages.
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC4141] Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for
+             Content Conversion", RFC 4141, November 2005.
+
+   [RFC3949] Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J.
+             Rafferty, "File Format for Internet Fax", RFC 3949,
+             February 2005.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2532] Masinter, L. and D. Wing, " Extended Facsimile Using
+             Internet Mail", RFC 2532, March 1999.
+
+   [RFC2534] Masinter, L., Wing, D., Mutz, A., and K. Holtman, "Media
+             Features for Display, Print, and Fax", RFC 2534, March
+             1999.
+
+   [RFC2542] Masinter, L., "Terminology and Goals for Internet Fax", RFC
+             2542, March 1999.
+
+   [RFC2879] Klyne, G. and L. McIntyre, "Content Feature Schema for
+             Internet Fax (V2)", RFC 2879, August 2000.
+
+   [RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content
+             Negotiation for Messaging Services based on Email", RFC
+             3297, July 2002.
+
+   [RFC3965] Toyoda, K., Ohno, H., Murai, J., and D. Wing, "A Simple
+             Mode of Facsimile Using Internet Mail", RFC 3965, December
+             2004.
+
+
+
+
+
+
+
+
+
+Crocker & Klyne             Standards Track                     [Page 5]
+
+RFC 4142                         FFPIM                     November 2005
+
+
+5.2.  Informative References
+
+   [RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy
+             Considerations for Open Pluggable Edge Services", RFC 3238,
+             January 2002.
+
+   [T30]     ITU-T (CCITT), "Procedures for Document Facsimile
+             Transmission in the General Switched Telephone Network",
+             Recommendation T.30, July 1996.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crocker & Klyne             Standards Track                     [Page 6]
+
+RFC 4142                         FFPIM                     November 2005
+
+
+Appendix A.  Direct Mode
+
+   Email is a store-and-forward service, typically with highly variable
+   delay between the time a message leaves the sender's realm and the
+   time it arrives in the receiver's realm.  The number of relays
+   between sender and receiver is also unknown and variable.  By
+   contrast, facsimile is generally considered to be direct and
+   immediate.
+
+   An email profile that fully emulates facsimile must solve several
+   different problems.  One is to ensure that the document
+   representation semantics are faithful.  Another is that the
+   interaction between sender and receiver is similar to that of
+   telephony-based facsimile.  In particular, it must ensure the
+   timeliness of the interaction.  The specifications for FFPIM and its
+   predecessors enable email to emulate the former, the information
+   (semantics) activities of facsimile.
+
+   The ESMTP CONNEG option sets the stage for achieving the latter, with
+   email-based facsimile transfer that has interactive negotiations, on
+   a par with telephony-based facsimile.  The key, additional
+   requirement is to achieve timeliness.  Ultimately, timeliness
+   requires configuring sender and receiver email servers to interact
+   directly.  The sender's MTA must directly contact the receiver's MTA.
+   With typical email service configurations, the content and
+   interaction semantics of facsimile can be emulated quite well, but
+   timeliness cannot be assured.
+
+   To achieve direct sending, the originating MTA must not use
+   sending-side intermediaries such as outbound enterprise MTAs.
+   Instead, it must be configured to do transmissions directly to hosts
+   specified in email addresses, based on queries to the public DNS.  To
+   achieve direct receiving, the target MTAs must have DNS A records,
+   without MX records.  That is, they also must be configured not to use
+   intermediaries.
+
+   The sender may then use ESMTP Conneg to determine the capabilities of
+   the receiver.  Afterwards the sender will use the capabilities
+   information to tailor the TIFF message content it sends.
+
+
+
+
+
+
+
+
+
+
+
+
+Crocker & Klyne             Standards Track                     [Page 7]
+
+RFC 4142                         FFPIM                     November 2005
+
+
+Appendix B.  Acknowledgements
+
+   The IETF Fax working group, in collaboration with the IETF and the
+   ITU, has diligently participated in a multi-year effort to produce
+   Internet-based emulation of classic facsimile via email profiles.
+   The effort benefited from the group's willingness to provide an
+   initial, minimal mechanism, and then develop the specification to
+   include more facsimile features as implementation and operation
+   experience was gained.
+
+Authors' Addresses
+
+   Dave Crocker
+   Brandenburg InternetWorking
+   675 Spruce Drive
+   Sunnyvale, CA  94086
+   USA
+
+   Phone: +1.408.246.8253
+   EMail: dcrocker@bbiw.net
+
+
+   Graham Klyne
+   Nine by Nine
+   UK
+
+   Phone:
+   EMail: GK-IETF@ninebynine.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crocker & Klyne             Standards Track                     [Page 8]
+
+RFC 4142                         FFPIM                     November 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Crocker & Klyne             Standards Track                     [Page 9]
+