Applications Area                              Kiyoshi Toyoda
INTERNET-DRAFT                                  Hiroyuki Ohno
Dec 21, 1997                                        Jun Murai
Expires June 1998                                WIDE Project
                                                     Dan Wing
                                                        cisco



                Facsimile over Internet Mail

               <draft-ietf-fax-service-01.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 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),
ftp.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, 1998).  All Rights
Reserved.


SUMMARY

This specification provides for "simple mode" carriage of
facsimile data over the Internet.  Extensions to this
document will follow.  The current specification employs
standard protocols and file formats such as TCP/IP, Internet
mail protocols [1, 2, 3], MIME [4, 16, 17], and TIFF for Fax
[5,6].  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
for Fax data.  The specification facilitates communication
among existing facsimile devices, Internet mail agents, and
the gateways which connect them.

The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in
this document are to be interpreted as described in [7].



  SCOPE

This specification defines a message-based facsimile service
over the Internet.  It describes a minimum set of
capabilities, taking into account those of a typical
facsimile devices and PCs that can generate fax data.

A G3Fax device has substantial restrictions due to
specifications in the standards, such as for timers. This
specification defines 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 the facsimile service that is
operated over the public switched telephone network, so that
gateways between the facsimile service and Internet mail can
operate 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.


1.1 Services

A fax-capable device that uses T.30 [8] and the public
switched telephone network (PSTN) is called a "G3Fax device"
in this specification.  An "IFax device" is compatible with
T.30 and is Internet capable.  A message can be sent to an
IFax device using  an Internet mail address. A message can be
sent to a G3Fax device  using an Internet mail address; the
message is forwarded via an IFax offramp gateway. A G3Fax
device is a terminal that uses T.30 and the PSTN.


1.2 Cases

This specification provides for communication between each of
the following combinations:

Internet mail            =>   Network printer
Internet mail            =>   Offramp gateway (forward to
                              G3Fax)
Network scanner          =>   Network printer
Network scanner          =>   Offramp gateway (forward to
                              G3Fax)
Network scanner          =>   Internet mail
Onramp gateway(from      =>   Network printer
G3Fax)
Onramp gateway(from      =>   Offramp gateway (forward to
G3Fax)                        G3Fax)
Onramp gateway(from      =>   Internet mail
G3Fax)

Onramp gateways pose a special problem with respect to
addressing, since the G3Fax service which originates a
document does not have a standard mechanism capable of
generating Internet mail addresses.  This specification
presumes that individual onramp services will satisfy the
requirement for generation of valid Internet mail addresses
but does not consider the mechanism(s) to be used.



  COMMUNICATION PROTOCOLS

The set of conventions necessary to achieve facsimile-
compatible service covers basic data transport, document data
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

This section describes mechanisms involved in the transport
between IFAX devices.

2.1.1     Relaying

Data transfer MAY be achieved using standard Internet mail
transfer mechanisms[1, 3]  The format of addresses MUST
conform to the RFC 821 <addr-spec> and RFC 822 <mailbox>
Internet mail standards [1, 2, 3].

2.1.2     Gateway

A gateway translates between dissimilar environments.  For
IFax, a gateway connects between Internet mail and the
T.30/PSTN fax service.  Gateways can service multiple
T.30/PSTN fax service users or can service only one.  In the
former case, they serve as an "mail transfer agent" and in
the latter as a "mail user agent".

An onramp is a gateway which connects from T.30/PSTN fax to
Internet mail.  An offramp is a gateway which connects from
Internet mail to T.30/PSTN fax.

This specification describes the Internet mail service
portion of offramp addressing, confirmation and failure
notification.  Details are provided in later sections.
Onramps are required to generate valid Internet mail address,
header and MIME formats and to conform to the content
requirements specified here.  No other consideration to
onramp gateways is provided.

2.1.3     Mailbox protocols

Offramp gateways that serve multiple users SHOULD use SMTP;
gateways that only serve a single mail recipient MAY use a
mailbox access protocol such as POP or IMAP [9, 10].


2.2 Formats

2.2.1     Headers

IFax devices MUST be compliant with RFC 822 and its updates,
which define the format of mail headers.  The header of an
IFax message SHOULD include Message-ID and MUST include all
required fields, such as DATE and FROM [2].

2.2.2     MIME

IFax devices MUST be compliant with MIME [4], except as noted
in appendix A.

2.2.3     Content

The data format of the facsimile image is based on the
minimum set of the F profile of TIFF for Fax[6].   Rules for
the use of TIFF for Fax, for the message-based Internet fax
application, are defined later.

2.2.4     Multipart

A single multi-page document SHOULD be sent as a single multi-
page TIFF file, even though recipients MUST process
multipart/mixed containing multiple TIFF files. If multipart
content is present and processing of any part fails, then
IFax fails the entire message, per [Processing failure]
below.


2.3 Error Handling

2.3.1     Delivery failure

In the event of delivery failure, the recipient MUST generate
a failure message, which SHOULD be in the format of a DSN.
[14,15]

     NOTE:  Internet mail transported via SMTP MUST contain a
     MAIL FROM address appropriate for delivery of return
     notices [Also see section 5.2.6]

2.3.2     Processing failure

Devices with limited capabilities might be unable to process
the content of a message.  If this occurs it is important to
ensure that the message is not lost without any notice.
Notice MAY be provided in any appropriate fashion.



  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 G3Fax Devices

G3Fax devices are accessed via an IFAX offramp gateway, which
performs any required telephone dial-up.


3.3 Address Formats for Offramps

When a G3Fax device is identified by a telephone number, the
G3Fax device's entire address, including the number and
offramp host reference MUST be contained within standard
Internet mail transport fields, such as RCPT TO and MAIL FROM
[1].  The address MAY be contained within message content
fields, such as <authentic> and <destination> [2] as
appropriate.

The telephone number format SHOULD conform with [11,12].



  IMAGE FILE FORMAT

IFax devices MUST be able to read and write minimum set TIFF
files, per the rules for creating minimum set TIFF files
defined in the F profile of TIFF for Fax [6], which is also
compatible with the specification in [5].

A sender SHOULD NOT use TIFF fields and values beyond the
minimum subset of TIFF for Fax unless the sender has prior
knowledge of other TIFF fields or values supported by the
recipient.  The mechanism for determining capabilities of
recipients is beyond the scope of this document.



  SECURITY CONSIDERATIONS


5.1 General Directive

This specification is based on use of existing Internet mail.
Any security to be provided MUST be part of the Internet
security infrastructure, rather than creating new mechanisms
or using other mechanisms outside of the Internet
infrastructure.


5.2 Threats and Problems

Both Internet mail and G3Fax standards and operational
services have their own set of threats and countermeasures.
This section attends only to the set of additional threats
which ensue from integrating the two services. This section
reviews relevant concerns about Internet mail for IFax
environments, as well as considering the potential problems
which can result of integrating the existing G3Fax service
with Internet mail.

5.2.1     Spoofed sender

The actual sender of the message might not be the same as
that specified in the Sender or From fields of the message
content headers or the Mail From transport header.

In a tightly constrained environment, sufficient physical and
software controls may be able to ensure prevention of this
problem. The usual solution is through encryption-based
authentication, either for the channel or associated with the
object, as discussed below.

5.2.2     Cost to dialout

In addition to the cost of email (CPU cycles and disk),
offramp fax causes an outdial which often has a direct cost.
Techniques for establishing authorization of the sender are
essential to offramp facsimile services which are not funded
through advertising, public funds, or other mechanisms not
tied to the limitation of access.

Due to the cost of dialout, unsolicited email which causes an
outdial can be especially problematic.

Offramp gateways SHOULD provide the ability to authorize
senders in some manner to prevent unauthorized use of the
offramp. There are no standard techniques for authorization
using Internet protocols.

Typical solutions use simple authentication of the originator
to establish and verify their identity and then check the
identity against a private authorization table.

Originator authentication entails the use of weak or strong
mechanisms, such as cleartext keywords or encryption-based
data-signing, respectively, to determine and validate the
identify of the sender and assess permissions accordingly.

Other control mechanisms which are common include source
filtering and originator authentication.  Source filtering
entails offramp gateway verification of the host or network
originating the message and permitting or prohibiting
relaying accordingly.

5.2.3     PSTN authorization information

Confidential information about the sender necessary to dial a
G3Fax recipient, such as sender's calling card authorization
number, might be disclosed to the G3Fax recipient (on the
cover page), such as through parameters encoded in the G3Fax
recipients address in the To: or CC: fields.

Senders SHOULD be provided with a method of preventing such
disclosure.  As with mechanisms for handling unsolicited
faxes, there are not yet standard mechanisms for protecting
such information.  Out-of-band communication of authorization
information or use of encrypted data in special fields are
the available non-standard techniques.

Typically authorization needs to be associated to specific
senders and specific messages, in order to prevent a "replay"
attack which causes and earlier authorization to enable a
later dial-out by a different (and unauthorized) sender.  A
non-malicious example of such a replay would be to have an
email recipient reply to all original recipients -- including
an offramp IFax recipient -- and have the original sender's
authorization cause the reply to be sent.

5.2.4     Sender accountability

In many countries, there is a legal requirement that the
"sender" be disclosed on a fax message.  Email From addresses
are trivial to fake, so that using only the MAIL FROM [1] or
>From [2] header is not sufficient.

Offramps SHOULD provide a cover page notice or "for
complaints please call ...." field specifying the telephone
number to call when there is a problem.

The G3Fax recipient SHOULD be provided with sufficient
information which permits tracing the originator of the IFax
message.  Such information might include the contents of the
MAIL FROM, From, Sender and Reply-To headers, as well as
Message-Id and Received headers.

5.2.5     Message disclosure

Users of G3Fax devices have an expectation of a level of
message privacy which is higher than the level provided by
Internet mail without security enhancements.

This expectation of privacy by G3Fax users SHOULD be
preserved as much as possible.

Sufficient physical and software control may be acceptable in
constrained environments.  The usual mechanism for ensuring
data confidentially entail encryption, as discussed below.

5.2.6     Non private mailboxes

With email, bounces (delivery failures) are typically
returned to the sender and not to a publicly-accessible email
account or printer.  With fax, bounces do not typically
occur.  However, with IFax, a bounce could be sent elsewhere
(see section [Delivery Failure]), such as a local system
administrator's account, publicly-accessible account, or an
IFax printer (see also [Traffic Analysis]).

5.2.7     Traffic analysis

Eavesdropping of senders and recipients is easier on the
Internet than PSTN.  Note that message object encryption does
not prevent traffic analysis, but channel security can help
to frustrate attempts at traffic analysis.


5.3 Security Techniques

There are two, basic approaches to encryption-based security
which support authentication and privacy:

5.3.1     Channel security

As with all email, an IFax message can be viewed as it
traverses internal networks or the Internet itself.

Virtual Private Networks (VPN) which make use of encrypted
tunnels, such as via IPSec technology [18] or transport layer
security, can be used to prevent eavesdropping of a message
as it traverses such networks.   It also provides some
protection against traffic analysis, as described above.

5.3.2     Object security

As with all email, an IFax message can be viewed while it
resides on, or while it is relayed through, an intermediate
Mail Transfer Agent.

Message encryption, such as PGP-MIME [13], can be used to
provide end-to-end encryption.



  REFERENCES

[]       Postel, J. "Simple Mail Transfer Protocol", STD xx,
          RFC 821, August 1982.

[]       Crocker, D., "Standard for the Format of ARPA
          Internet Text Messages", STD 11, RFC 822, August
          l982.

[]       Braden, R., 1123 "Requirements for Internet hosts -
          application and support", RFC 1123, October 1989.

[]       Borenstein, N., and N. Freed, "MIME (Multipurpose
          Internet mail Extension) Part One: Mechanisms for
          Specifying and Describing the Format of Internet
          Message Bodies", RFC 2049, November 1996.

[]       Parsons, G. and Rafferty, J. "Tag Image File
          Format(TIFF)-Application F", RFC XXXX, January 1998

[]       McIntyre, L., Zilles, S, et al. "File Format for
          Internet Fax", RFC XXXX, January 1998.

[]       S. Bradner, "Key words for use in RFCs to Indicate
          Requirement Levels", RFC 2119, March 1997.

[]       ITU-T (CCITT), "Procedures for Document Facsimile
          Transmission in the General Switched Telephone
          Network", ITU-T (CCITT), Recommendation T.30, July,
          1996

 []       J. Myers, M. Rose, "Post Office Protocol - Version
          3", STD 53, RFC 1939, May 1996.

[]      Crispin, M., "Internet Message Access Protocol
          Version 4/Rev1". RFC 2060, December 1996.

[]      C. Allocchio, "Minimal PSTN address format for
          Internet mail". RFC XXXX, January 1998.

[]      C. Allocchio "Minimal fax address format for
          Internet mail". RFC XXXX, January 1998.

[]      Elkins, M., "MIME Security with Pretty Good Privacy
          (PGP)". RFC 2015, October 1996.

[]      Moore, K. & Vaudreuil , G., "An Extensible Message
          Format for Delivery Status Notifications". RFC
          1894, January 1996.

[]      K. Moore, "SMTP Service Extension for Delivery
          Status Notifications", RFC 1891, January 1996

[]      Freed, N., and N. Borenstein, "Multipurpose
          Internet Mail Extensions (MIME) Part Two: Media
          Types", RFC 2046,  Innosoft, First Virtual
          Holdings, November 1996.

[]      Moore, K., "Multipurpose Internet Mail Extensions
          (MIME) Part Three: Representation of Non-ASCII Text
          in Internet Message Headers", RFC 2047, University
          of Tennessee, November 1996.

[]      Atkinson, R., "Security Architecture for the
          Internet Protocol", RFC 1825, Naval Research
          Laboratory, August 1995.





  ACKNOWLEDGEMENTS

This specification was produced by the Internet Engineering
Task Force Fax Working Group, over the course of more than
one year’s online and face-to-face discussions.  As with all
IETF efforts, many people contributed to the final product.

Active for this document were: Steve Huston, Jeffrey Perry,
Greg Vaudreuil, Richard Shockey, Charles Wu, Graham Klyne,
Robert A. Rosenberg, Larry Masinter, Dave Crocker, Herman
Silbiger, James Rafferty.



  AUTHORS' 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
 Endo, Fujisawa
Kanagawa 252 Japan
Fax: +81 466 49 1101
EMail: jun@wide.ad.jp




  FULL COPYRIGHT STATEMENT

Copyright (C) The Internet Society (1997, 1998).  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.



 APPENDIX A:  Exceptions to MIME

*    IFax senders are NOT REQUIRED to be able to send
     text/plain messages (RFC 2049 requirement 4), although IFax
     recipients are required to accept such messages, and to
     process them.

*    IFax recipients are NOT REQUIRED to offer to put results
     in  a file.

*    IFax recipients MAY directly print/fax  the received
     message rather  than "display" it, as indicated in RFC 2049.