Internet DRAFT - draft-ietf-fax-wide
draft-ietf-fax-wide
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
<draft-ietf-fax-wide-00.txt>
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
