Applications Area Kiyoshi Toyoda INTERNET-DRAFT Hiroyuki Ohno July 28, 1997 Jun Murai Expires January 1998 WIDE Project WIDE Message-based Fax over the Internet 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 InternetDrafts. 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). SUMMARY This specification provides for carriage of facsimile data over the Internet, to be used by WIDE. It employs standard protocols and file formats such as TCP/IP, SMTP[1](/POP3[7]), MIME[2], and TIFF[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 data. 1 SCOPE A fax-capable device which 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. The specification of message-based fax over the Internet should be standardized according to the minimum requirements possible, taking into account the capabilities of a fax machines and PCs which can generate fax data. 2 COMMUNICATION PROTOCOLS This specification provides for support of fax over the Internet as a tailored use of Internet mail. Any system conforming to this specification will also be able to interact with normal Internet mail systems. 2.1 Transport Data transfer is achieved using SMTP for transmission. 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. The format of the facsimile image should be based on TIFF-F (see reference [3]), but in an embedded system the specification of TIFF-F is not fully supported, due to hardware limitations. Therefore a constrained version of TIFF is supported, as described below. TIFF creates binary data so that proper Content-transfer- encoding, such as using base 64, 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.2 Addressing Classic Fax Devices (accessed via an IFAX gateway) Classic fax devices are accessed via telephone dial-up, by an IFAX device. 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 2.2.1 Addressing ABNF The ABNF specification for the syntax is: Relay-Address = FAX-number "@" IFAX-domain-name FAX-number = 1*( DIGIT / pause ) pause = "-" ; pause 2.2.2 Examples IFAX to G3FAX(12345678): 12345678@ifax.aaa.bbb.co.jp 3 TIFF FORMAT 3.1 Sequence of IFD and Image Data Image/Tiff is subset of TIFF-F, because implementation is constrained by hardware cost. Normaly, Fax hardware does not have enough memory to process full specification of TIFF-F. So, sequnece of IFD and image data must be determined as below. +-----------------------+ | Header | +-----------------------+ +---| IFD |----+ | +-----------------------+ | +-> | Image Data | | Data Offset | (page 1) | | +-----------------------+ <--+ | IFD | Next IFD +-----------------------+ | Image Data | | (page 2) | +-----------------------+ | : | | : | Figure 3.1 TIFF(Tag Image File Format) Structure In Figure 3.1, after a header IFD (Image File Directory) and Image Data (1 page) becomes a pair, then it is repeated. IFD of each page is described before Image Data because Tags of each page can be transmitted before all pages of Image Data are scanned. The content of Header is shown in figure 3.2. +--------+-------------------+--------+--------------------+ | Offset | Description | Type | Value | +--------+-------------------+--------+--------------------+ | 0 | Byte Order | Short | 0x4949:Intel X86 | +--------+-------------------+--------+--------------------+ | 2 | Version | Short | 42 | +--------+-------------------+--------+--------------------+ | 4 | Offset of 0th IFD | Long | 0x 0000 0008 | +--------+-------------------+--------+--------------------+ NOTE: Short : 16 bits Long : 32 bits Figure 3.2: Image File Header Intel X86 is adopted for Byte Order. This is appropriate because Intel X86 has been adopted by many personal computers at present. 3.2 Capability There is no negotiation before sending. So, the mandatory capability specified by the G3FAX standard must be predetermined. Hence the following capabilities must be supported for reception. If IFAX receives a TIFF image which is not supported, it should return an error message to the originator. Compression 3 MH Resolution 2 inch Fill 0rder 2 LSB first Image Width 1728 dot (A4, letter, legal) XResolution 204 YResolution 98 / 196 T4Options 0:MH, not byte-aligned EOL 4:MH, byte-aligned EOL 4 Notification A receiving agent MAY provide Delivery Status Notification, i.e. DSN [5]/[6], because Notification is useful. But storage devices such as Flash-ROM, HDD, etc. are required in order to store the information. And it increases the cost and complexity of hardware and product lifecycle. Thus, Notification is beyond the scope of this specification. 5 Security On authentication and security, further research of security on e- mail (MIME) and the authentication is expected. For example, S/MIME and PGP-MIME are proposed as the secure messaging methods. There will be many implementations and many experiments/evaluations of encryption/certification of messages. 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)- Class F Network Working Group Internet Draft, January 31,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. 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