From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4142.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc4142.txt (limited to 'doc/rfc/rfc4142.txt') 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] + -- cgit v1.2.3