HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 02:23:05 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 19 Nov 1997 18:35:00 GMT ETag: "2ed9a8-2bb1-34733154" Accept-Ranges: bytes Content-Length: 11185 Connection: close Content-Type: text/plain Applications Area Kiyoshi Toyoda INTERNET-DRAFT Hiroyuki Ohno Nov 12, 1997 Jun Murai Expires May 1998 WIDE Project Facsimile over Internet Mail STATUS OF THIS MEMO This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Copyright (C) The Internet Society (1997). All Rights Reserved. SUMMARY This specification provides for carriage of facsimile data over the Internet. It employs standard protocols and file formats such as TCP/IP, SMTP[1], POP3[7], MIME[2], and TIFF- F[3]. It can send images not only to other Internet-aware fax devices but also to Internet-native systems, such as PCs with common email readers which can handle MIME mail and TIFF-F data. 1 SCOPE A fax-capable device which uses T.30 and the public switched telephone network, but is also Internet capable is called an IFAX device. An IFAX device has an e-mail address. This specification provides for communication between each of the following combinations: * IFAX and Internet mail host (personal computer or work station) * Two IFAX devices * IFAX and G3FAX (i.e. ITU-T Group 3 FAX[4]) via an IFAX relay. * Internet mail host and G3FAX via an IFAX relay A classic fax device (e.g., G3FAX) has substantial restrictions due to specifications in the standards, such as for timers. This specification of message-based fax over the Internet satisfies a minimum set of requirements, taking into account the capabilities of a fax machines and PCs which can generate fax data. In reality, this specification creates a profile for Internet mail, rather than creating a distinct "facsimile over the Internet" service. The semantics resulting from the profile are designed to be compatible with T.30 facsimile service, so that gateways between facsimile and Internet mail can provide that service with very high fidelity. The reason for developing this capability as an email profile is to permit interworking amongst facsimile and email users. For example it is intended that existing email users be able to send normal messages to lists of users, including facsimile-based recipients, and that other email recipients shall be able to reply to the original and continue to include facsimile recipients. Similarly it is intended that existing email software work without modification and not be required to process new, or different data structures, beyond what is normal for Internet mail users. Existing email service standards are used, rather than replicating mechanisms which are more tailored to existing facsimile standards, to ensure this compatibility with existing email service. 2 COMMUNICATION PROTOCOLS The set of conventions necessary to achieve facsimile- compatible service cover basic data transport, data document formats, message (document) addressing, delivery confirmation, and message security. In this section, the first 4 are covered. The remainder are covered in following sections, along with additional details for addressing and formats. 2.1 Transport Data transfer is achieved using any acceptable Internet mail transfer mechanism. The typical choice is SMTP, especially between organizations across the Internet. As for all Internet mail, delivery can be effected using SMTP, POP or IMAP, as appropriate for a local configuration. For delivery to classic fax devices via a gateway, Internet mail delivery refers to transport to the gateway, rather than transport to the final, classic fax device. Addressing conforms to Internet mail standards. For referencing destinations which are not classic Internet mail mailboxes, additional mailbox coding conventions are required and are described below. 2.2 Formats Standard Internet mail headers and MIME content packaging also are used. IFAX gateways may choose to use the contents of the RFC822 headers to form a cover page, in addition to any cover page included in the document body. Unique message identification is achieved with the standard RFC822 Message-ID header. The data format of the facsimile image is based on the minimum set of TIFF-F[3]. Rules for the use of TIFF-F for the message-based Internet fax application are defined later. TIFF-F creates binary data so that proper Content-transfer- encoding using base64, is necessary when the data are transported over channels which do not support pure binary. Multiple fax documents may be aggregated within a single Internet mail message, by using Multipart/mixed. 2.3 Confirmation A sending agent MAY request Delivery Service Notification (DSN [5]/[6]), since this is a natural part of existing facsimile service and is a standard part of Internet mail. A receiving agent SHOULD correctly process a DSN request which accompanies a facsimile-related message. For such messages, a DSN SHOULD be generated by an email recipient according to the standard rules for DSNs. If an offramp gateway supports DSN, it SHOULD generate one upon receipt of a fax delivery confirmation issued by the receiving facsimile device. 3 Addressing 3.1 Classic Email Destinations Messages being sent to normal Internet mail recipients will use standard Internet mail addresses, without additional constraints. 3.2 Classic Fax Devices (accessed via an IFAX gateway) Classic fax devices are accessed via telephone dial-up, by an IFAX device. A number of different addressing schemes are feasible for processing by an IFAX offramp gateway. This specification provides for only one, to have a single, simple convention. However this is not intended to preclude use of others schemes which are acceptable by private conventions and which may be candidates for standardization in the future. The Internet mail address for such a device MUST encode the name of the IFAX gateway and the telephone number to be called. The destination fax telephone number is in the local-part (left-hand side) of the address. The name of the gateway is in the domain name (right-hand-side) of the address. An Internet mail address for a classic fax device to be accessed by an IFAX gateway is in the form: FAX-number@IFAX-domain-name The ABNF specification for the syntax of FAX-number is defined by "PSTN and fax address in e-mail services"[8]. 4 TIFF FORMAT Message-based Internet Fax applications MUST be able to read and write minimum set TIFF-F files, per the rules for creating minimum set TIFF-F files defined in TIFF-F. Internet fax applications MAY also support TIFF-F field values that go beyond the minimum set, but not all TIFF-F readers will support these values. 5 Security This specification permits the use of existing Internet mail. Any security to be provided is provided as part of the Internet mail infrastructure. However, existing facsimile service carries a strong expectation of basic privacy. As a consequence, the sender of IFax MAY request data privacy. The state of Internet standards, deployment and use for security technology permits a number of different implementations which can provide adequate degrees of privacy. Existing facsimile service does not carry any mechanism for authentication, however it does permit non-authenticated identification of senders. The From: field string shall be used for this purpose. 6 REFERENCES [1] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, University of Delaware, August l982. [2] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extension) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore and Innosoft, September 1993. [3] Glenn Parsons, James Rafferty, "Tag Image File Format(TIFF)-Application F", Network Working Group Internet Draft, September 18,1997 [4] ITU-T (CCITT), Recommendations T.4 and T.30 [5] K. Moore, "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996 [6] K. Moore, G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996 [7] J. Myers, M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. [8] C. Allocchio "PSTN and fax address format in e- mail services", Network Working Group Internet Draft, November 1997 7 Author's Addresses Kiyoshi Toyoda Matsushita Graphic Communication Systems, Inc. 2-3-8 Shimomeguro, Meguro-ku Tokyo 153 Japan Fax: +81 3 5434 7166 EMail: ktoyoda@rdmg.mgcs.mei.co.jp Hiroyuki Ohno Tokyo Institute of Technology 2-12-1 O-okayama, Meguro-ku Tokyo 152 Japan FAX: +81 3 5734 2754 EMail: hohno@is.titech.ac.jp Jun Murai Keio University 5322 Endo, Fujisawa Kanagawa 252 Japan Fax: +81 466 49 1101 EMail: jun@wide.ad.jp 8 Full Copyright Statement Copyright (C) The Internet Society (date). 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.