Network Working Group D. Crocker, Brandenburg InternetWorking G. Klyne, Content Technologies L. Masinter, Xerox Expiration <9/2001> And others March 2, 200110/21/99 7:20 AM Full-mode Fax Profile for Internet Mail: FFPIM draft-ietf-fax-ffpim-01.txt Status Of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document and related documents are discussed on the IETF Fax mailing list. To join the list, send mail to ietf- fax-request@imc.org. To contribute to the discussion, send mail to ietf-fax@imc.org. The archives are at http://www.imc.org/ietf-fax. The Fax working group charter, including the current list of group documents, can be found at http://www.ietf.org/html.charters/fax-charter.html. Table Of Contents 1. Introduction 2. Content Negotiation 3. Timely Delivery 4. Content Format 5. Security Considerations 6. Acknowledgments 6. Full Copyright Statement 7. Contact Abstract Classic facsimile document exchange represents both a set of technical specifications [T30] and a class of service. Previous work [RFC2305, RFC2532] 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, timeliness and capability negotiation for Internet mail that is on a par with classic T.30 facsimile. 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 . Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. 1. Introduction The current specification defines ôfull modeö carriage of facsimile data over the Internet, building upon previous work [RFC2305, RFC2532] and adding the remaining functionality necessary for achieving reliability, timeliness and capability negotiation for Internet mail that is on a par with classic T.30 facsimile. 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 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 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]. 2. Content Negotiation Classic facsimile service is interactive, so 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 that is supported by both the sending station and the receiving station. Internet mail is store-and-forward, with potentially long latency, so that before-the-fact negotiation is problematic. This specification therefore uses a post-hoc technique that permits an originator to send the best version known by the originator to be supported by the recipient and then to send a better version if the recipient requests it. The specification for this technique is in [CONNEG]. Implementations that are conformant to FFPIM MUST support content negotiation. [[[ A concern has been expressed that CONNEG does not support the full range of fax features. The working group needs to resolve a) whether there are functional requirements for complete emulation of fax services that are not satisfied by the above specification, and b) what changes are necessary, if the answer to question a) is æyesÆ. /editor]]] 2.1. ESMTP-based content negotiation SMTP servers that are able to report capabilities of the addresses (mailboxes) which they support MAY use the ESMTP ôCONNEGö option. This allows them to report capabilities of the receiving station as part of the ESMTP RCTP-TO interaction. [[[ This section is intended to assist in the operation of ôdirectö FFPIM interactions. We need to develop specifications for the ESMTP ôCONNEGö option. /editor ]]] 3. Timely Disposition Internet mail is often reliable and speedy. However it displays a very wide range of variability, depending upon details such as software implementation, systems operation, network connectivity and network activity. By contrast, facsimile systems typically suffer only the fixed delay of telephone call setup time. The T.30 fax standard includes a required delivery confirmation; so the sender gets an immediate, unambiguous report on the status of a transmission and, possibly, printing. Internet mail standards include methods of reporting confirmation, but these are not always supported. This specification uses a set of capabilities that permits an originator to request that the email transport system seek a particular timeliness in delivery and then assures that the system will report the success or failure of that request. The specification for this technique is in [TIMELY]. Implementations that are conformant to FFPIM MUST support timely disposition. [[[ A question has been raised about alternative confirmation behaviors. The working group needs to resolve a) whether there are functional requirements for complete emulation of fax services that are not satisfied by the above specification, and b) what changes are necessary, if the answer to question a) is æyesÆ. /editor]]] [[[ The editor believes that the features provided by the TIMELY mechanisms EXCEED the related services provided by the T.30 fax world. /d ]]] 4. Content Format Support for enhancements to TIFF are included in this specification. The details for these enhancements are contained in [TIFF]. Implementations that are conformant to FFPIM MUST support TIFF enhancements. [[[ A question has been raised about alternative confirmation behaviors. The working group needs to resolve a) whether there are functional requirements for complete emulation of fax services that are not satisfied by the above specification, and b) what changes are necessary, if the answer to question a) is æyesÆ. /editor ]]] [[[ The editor suspects that the features provided by the TIFF specification meets or exceeds the related services provided by the T.30 fax world. /d ]]] 5. Security Considerations As this document is an extension of [RFC2305] and [RFC2532], the Security Considerations sections of [RFC2305] and [RFC2532] applies 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. 6. Acknowledgements [[[ to be done /editor ]]] 7. References [TIMELY] G. Klyne, et al, draft-ietf-fax-timely-00.txt [CONNEG] G. Klyne, R. Iwazaki, D. Crocker, ôContent Negotiation for Facsimile Using Internet Mail ô, draft-ietf- fax-content-negotiation-00.txt [RFC2305] Toyoda, K., Ohno, H., Murai, J. and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 2305, March 1998. Under revision, as draft-ietf-fax-service-v2- 02.txt. [T.30] "Procedures for Document Facsimile Transmission in the General Switched Telephone Network", ITU-T (CCITT), Recommendation T.30, July, 1996. [TIFF] D. Venable, S. Zilles, L. McIntyre, G. Parsons, J. Rafferty, ôFile Format for Internet Fax ô, draft-ietf-fax- tiff-fx-06.txt R. Buckley 6. Full Copyright Statement Copyright (C) The Internet Society (2001). 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. 4. 7. Contact David H. Crocker Tel: +1.408.246.8253 Brandenburg InternetWorking Fax: +1.408.249.6205 675 Spruce Dr. Email: Sunnyvale, CA 94086 USA dcrocker@brandenburg.com Graham Klyne (editor) Tel: +44 118 930 1300 Content Technologies Ltd. Fax: +44 118 930 1301 1220 Parkview, Arlington Email: GK@ACM.ORG Business Park Theale, Reading, RG7 4SA, UK Larry Masinter Tel: +1 650 à Adobe Systems Fax: +1 650 à à USA Email: masinter@adobe.com 5. Appendix A û Direct Mode [[[ Desire to have an FFPIM sender communicate with an FFPIM receiver directly, so that there are no SMTP (or other) intermediaries does not require changes to the standard, except for the addition of the ESMTP CONNEG option. The remaining features of this mode can be achieved through proper configuration and operation. A section needs to be written to explain how system administrators can achieve this mode. /editor. ]]