One document matched: draft-ietf-fax-fpim-00.txt

                      Fax Profile for 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), 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).  All Rights Reserved.

Table of contents

 1. Introduction
 2. Background
 3. Formats
 4. Addressing
 5. Message headers
 6. Transport
 7. Capabilities
 8. Security
 9. Operational Requirements and Limitations
 10. Security Considerations
 11. Acknowledgements
 14. Copyright
 15. Appendix - Example Fax Message
 16. Authors' Addresses

1.  Introduction

This specification provides for carriage of facsimile data over the
Internet. It employs standard protocols and file formats such as
TCP/IP, SMTP[SMTP], POP3[POP], MIME[MIME], and TIFF[TIFF].  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.

The document [FAXREQ] defines the requirements and desired properties
for facsimile over the Internet.  The facilities proposed here purport
to satisfy the requirements identified in [FAXREQ].

This proposal expands previous proposals [WIDE2] as it deals with
expanded capabilities as well as simple facsimile transmission.  It
defines the behavior of devices that provide gateway functions between
SMTP and traditional fax machines connected to the public switched
telephone network (PSTN), as well as behavior of SMTP sender and
receivers that are exchanging fax images [TIFF]. The specification is
based on previous work in Internet Fax within the IETF and ITU, and
the work of the Voice Profile for Internet Mail group [VPIM].

The Fax Profile of Internet Mail consists of the application of several
existing and proposed Internet Standards to accomlish the task
of sending image data. The profile calls for the use of standards
for:

 - Message formats (section 3)
 - Addressing (section 4)
 - Message headers (section 5)
 - Transport (section 6)
 - Capabilities (Section 7)
 - Security (Section 8)
 - Operational requirements (Section 9)

2. Background

Many fax, printer, and multi-function peripheral manufacturers are
adding network connectivity to their devices.  The complexity of the
IP-based services offered by the network connections is increasing.

Traditionally, images sent between fax machines are transmitted over
the analog telephone network using modems.  As the demand for
networking increases, there is a need for a standard high-quality
digital protocol to transmit images.

2.1 Functional elements of Fax  
  
The functions of a traditional fax device can be separated into
three primary functions:

        scanning
        printing
        transmission
        
Transmission can be further divided into its primary functions:

        capabilities negotiation
        image data transmission
        delivery confirmation

2.2 User Experience of Fax and Email

The primary user experience with fax is:

        immediate delivery
        delivery confirmation
        ease of use
        
The primary user experience with email is:

        delayed delivery
        no delivery confirmation
        ability to reply to sender
        easy to send to multiple recipients

The protocols specified here attempt to reconcile the differences
between the two environments.

2.2 Design Goals

It is a goal of this profile to make as few restrictions and additions
to the existing Internet mail protocols as possible while satisfying
the requirements outlined in [FAXREQ].

This goal is motivated by the desire to increase the accessibility to
digital messaging by enabling the use of proven existing networking
software for rapid development.

This profile is intended to be robust enough to be used in an
environment, such as the global Internet with installed-base gateways
which do not understand MIME, though typical use is expected to be
within corporate intranets.  Full functionality, such as reliable
error messages and binary transport, will require careful selection of
gateways (e.g., via MX records) to be used as forwarding agents.
Nothing in this document precludes use of a general purpose MIME email
packages (such as Eudora, Navigator, Internet Explorer) to read and
compose FPIM messages.  While no special configuration is required to
receive FPIM-compliant messages, some may be required to originate
compliant structures.

3. Formats

Standard Internet mail headers and MIME content packaging also are
used.  Fax offramps 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.

At a minimum, the data format of the facsimile image is based on the
minimum set of TIFF[TIFF]. Rules for the use of TIFF for the
message-based Internet fax application are defined below.

TIFF binary data requires a proper Content-transfer-encoding, using
base64, when the data is transported over channels which do not
support binary transport.

Multiple fax documents may be aggregated within a single Internet mail
message, by using Multipart/mixed.

This section lays out, in detail, the message content types that are
appropriate for the application of fax, and the contexts in which
these formats might be sent. Each of these is explained below.

      Type                   Send?                   Receive?
   image/tiff;application=f should                  must
   image/tiff;application=* may (when appropriate)  should (as appropriate)
   multipart/alternative    may                      must
   message/rfc822           must not                 must
   multipart/signed         may                      must accept,
							 should verify
   multipart/encrypted      may                      may
   message/delivery-status  may			     must
   message/disposition-notification
                            must (when appropriate)  must	
   Multipart/Report         may (when appropriate)   must
   text/plain               should not               should
   multipart/mixed          may                      must

3.1. Image data: image/tiff

The baseline format that all FPIM devices MUST accept for image data
is the minimum 'F' profile of image/tiff, as defined in [TIFF]. FPIM
servers SHOULD use image/tiff;application=F for image data when no
other capabilities are known.

Senders MAY use other applications of [TIFF] when it is known to
correspond to the capabilities of the recipient. Recipients SHOULD
accept other applications of tiff when it corresponds to the
capabilities of the device.

3.2  multipart/alternative

In order to allow for the upgrade of facsimile messages to different
capabilities, even when the recipients capabilities are unknown, fax
recipients MUST accept multipart/alternative, and process the message
for an acceptable type. Limited memory recipients may find processing
other than the first acceptable type to be difficult.

A sender MAY send a multipart/alternative that contains any media
types intermixed, as long as one of the parts is allowable.

Similarly, a recipient MUST accept multipart/alternative, as long as
one of the parts is acceptable.

3.3  message/rfc822

Fax messages may be stored by users and forward to other Internet Fax
user agents, e.g., through anInternet fax machine, fax offramp, or a
normal SMTP mailbox.  Because of this, fax offramps and Internet Fax
devices must be able to process message/rfc822.

3.4  multipart/signed, multipart/encrypted

In order to promote the use of authentication technology, recipients
MUST accept signed messages, even if the signature block for the
message is merely discarded. Senders SHOULD also use MIME message
security.

In order to promote the use of authentication technology, recipients
SHOULD accept encrypted messages. Senders SHOULD be capable of sending
encrypted messages.

3.5  message/delivery-status, message/disposition-notification,
   multipart/report

Message delivery notification is provided by sending a return message
to the original sender. FPIM devices must send message notifications
when appropriate, and must be able to recieve them.

Message delivery notifications are wrapped in multipart/report MIME
types. Similarly, FPIM devices must send message notifications when
appropriate, and must be able to recieve them.

3.6  text/plain

Fax senders should not send plain text messages, at least to nominal
fax recipients. However, in the normal email environment, the
prevalence of text/plain;charset=US-ASCII as the baseline format for
Internet mail means that recipients that reject simple text messages
may not be able to properly function. A fax recipient MAY initially
accept a text message and then forward it on to another recipient that
is more capable, but in all cases, text messages should not be
discarded as unread.

3.7 multipart/mixed

Messages forwarded my mail user agents are sent as multipart/mixed
with the entire original message enclosed in a message/rfc822 content
type and the annotation as a separate text/* or image/tiff body part.

4. Addressing

The mechanism by which a user specifies a fax address is outside
the scope of this specification, but one might imagine using
a URL to specify the the destination. Using a URL would allow
facsimile profiles for other transport protocols, e.g., IPP [IPP],
or HTTP's POST [HTTP], while the Fax Profile for Internet Mail
would use a 'mailto' URL.

This specification only describes email addresses for Internet Fax.

4.1  Classic Email Destinations

Messages being sent to normal Internet mail recipients will
use standard Internet mail addresses, without additional
constraints.

4.2  Classic Fax Devices (accessed via a Fax Offramp)

Classic fax devices may be accessed via telephone dial-up from an
Internet Fax offramp. 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.

The specification for the syntax of FAX-number is defined by "PSTN and
fax address in e-mail services"[CLAUDIO].

4.3 Special addresses

Special addresses are provided for compatibility with the conventions
of Internet mail.  These addresses do not use numeric local addresses,
both to conform to current Internet practice and to avoid conflict
with existing numeric addressing plans.

4.3.1 postmaster@domain

[RFC822] requires special mailbox named "postmaster" MUST exist on all
systems.  For a fax offramp, this address could be mapped to the phone
number of a local fax machine, or the offramp's printer.

This mailbox is particularly likely to receive text messages.

4.3.2 non-mail-user@domain

If a reply to a message is not possible, then the special address
"non-mail-user" must be used as the originator's address.  This
special address is used as a token to indicate an unreachable
originator. For compatibility with the installed base of mail user
agents, implementations that generate this special address MUST send a
non-delivery notification for reply messages sent to the undeliverable
address.  The status code for such NDN's is 5.1.1 "Mailbox does not
exist".

4.4 From/Reply Address for Fax Onramps

Fax onramps that serve multiple users or locations must be able to
synthesize a valid "From" address, to allow the recipient of a fax to
identify the sender and possibly to reply, to accept errors, etc.  If
generating a valid "From" address is impossible (caller-ID
unavailable), the special address "non-mail-user" MUST be used as the
"From" address.

5. Message Headers

Embedding messages in Internet Mail require the standard message
headers for RFC822 and MIME messages. These standards are not repeated
here, but the minimum headers needed for a compliant implementation
are listed.

Internet messages contain a header information block.  This header
block contains information required to identify the sender, the list
of recipients, the message send time, and other information intended
for user presentation.  Except for specialized gateway and mailing
list cases, headers do not indicate delivery options for the transport
of messages.

Exploder lists are noted for modifying or adding to the headers of
messages that pass through them.  FPIM systems MUST be able to accept
and ignore headers that are not defined here.

  From, To, Subject, MIME-Version, Content-Type,
  Content-Transfer-Encoding, Date, Message-ID, Reply-To

5.1 From

The From header indicates the originator's (fully qualified) email
address.

The From address is likely to be used for replies by email users.
However, if the From address contains <non-mail-user@domain>, the user
SHOULD NOT be offered the option to reply, nor should notifications be
sent to this address.

5.2  To

The To header contains the recipient's fully-qualified domain address.

     Example:

	To: fax=+12145551213@mycompany.com

If present, the addresses in the To header MAY be used for a reply
message to all recipients. Note that the "To" address may not be the
same as the delivery address of the recipient, e.g., for messages that
are forward through mailing lists, mail forwarding programs, etc.

5.3  Date

The Date header contains the date, time, and time zone in which the
message was sent by the originator, as specified in [DRUMS].

The sending system MUST report the time the message was sent. If the
FPIM sender is relaying a message from a system which does not provide
a timestamp, the time of arrival at the FPIM system SHOULD be used as
the date.

5.4 Received

The Received header contains trace information added to the beginning
of a message by Mail Transfer Agents.  This is the only header
permitted to be added by an MTA.  Information in this header is useful
for debugging.

A compliant system MUST add Received headers when acting as a gateway
and MUST NOT remove any.  These headers MAY be ignored or deleted when
the message is received at the final destination (from [RFC822]).

Fax offramps MAY cause the Received headers of incoming messages to be
printed in the outgoing fax messages, e.g., as a configuration option,
when the headers do not match, upon first receipt of a message from a
given source, when the transmission is not signed or authenticated, or
as a matter of course.

5.5  Subject

The subject field is often provided by email systems and can be used
by fax offramps if automatic cover page generation is being performed.

Fax onramps SHOULD insert a generic subject header, including the word
"Fax", for the benefit of text-capable recipients.

Fax offramps MAY include a printed representation of the subject line
in the generated cover sheet of a message.

5.6  Disposition-Notification-To

This message header is specified in [MDN]. Sending of the response
when a message is received is as specified in that standard.

5.7  Notification Messages

MDN: Receipt Notification messages MUST only be sent only if the MDN
header is present, and typically after the user or fax machine has
initiated the notification by some action (like viewing or printing
the message).

DSN: DSN messages may be positive or negative, and indicate delivery
at the server or receipt by the client.

It is recommended that systems that do not support the DSN
notification format, or, if they do support DSN but didn't receive a
NOTIFY=FAILURE request, SHOULD still send a DSN-formatted delivery
failure message.

6. 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.

Section 6.1 explains the use of SMTP for Fax; section 6.2 lists a
number of extensions for ESMTP that are recommended for fax, and
Section 6.3 describes other transport protocols that may be used for
fax messaging.  

6.1 Standard SMTP protocol elements

6.1.1 MAIL FROM

This indicates where errors (bounces) are to be sent.  Note that this
doesn't necessarily have any relationship to the "From:" or "Sender:"
headers.

The MAIL FROM is converted to a Return-path header by the final
delivering SMTP server.  If present, it contains the address from the
MAIL FROM parameter of the ESMTP exchange to which error messages MUST
be sent (see [DRPT] for additional details).  Note that if the
Return-path is null ("<>"), e.g. no path, a notification MUST NOT be
sent.  If the Return path address is not available (either from this
header or the MAIL FROM parameter) the Sender or From addresses may be
used to deliver notifications.

6.1.2  RCPT TO

This is the actual recipient.  Note that this doesn't necessarily
have any relationship to the "To:" or "CC:" message headers.

6.2 ESMTP extensions

The following ESMTP [ESMTP] extensions are allowed or recommended.
This section discusses each extension.

  Extension                              status
  ---------------                      -----------
  Pipelining [PIPE]                    recommended
  Binary MIME [BINARY]                 recommended
  Size estimates [SIZE]                allowed
  Delivery notifications [DSN]         recommended (to request)
  Capabilities request/response [CAPS] recommended
  Immediate delivery [SESSION]         recommended
  Checkpoint/Restart [CHECK]           allowed

Note that no STMP extensions are required, and that ordinary SMTP is
allowed.

6.2.1 Pipelining

The pipelining feature may reduce the initial setup time of an
Internet Fax transmission, because some of the command responses need
not be delayed.

6.2.2 Binary MIME

Binary MIME is recommended as a way of reducing the overhead
of base64 encoding of TIFF images.

6.2.3 Size estimates

The use of the [SIZE] extension is recommended as a way of avoiding
sending a message that is too large through a mail gateway. The
conventional means of splitting large messages into smaller
message/partial components seems to be not as useful for Internet
Fax. The sending application might instead split a single fax
into multiple messages.

6.2.4 Delivery notifications

A sending agent MAY request Delivery Service Notification [DSN]
 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.

6.2.5 Capability request

The capability extensions in [CAPS] allow an ESMTP server to tell the
sending ESMTP implementation about the format capabilities of various
recipients. This allows efficient transfer of appropriate data. It is
only useful when the ESMTP server is able to access direct and
up-to-date information about the recipient; its use is recommended
in that situation. Senders SHOULD attempt to request capabilities
if they are able to generate documents in multiple formats.

6.2.6 Immediate delivery

The SESSION draft allows for immediate delivery end-to-end when there
are live connections between sender and recipient.  It is most
appropriate when sender and recipient are both connected directly to
the Internet. Its use is recommended.

6.2.7 Checkpoint/Restart

The checkpoint/restart features of ESMTP would help onramps keep
connections alive. This extension is allowed, but its utility
is uncertain.

6.3 Other transport mechanisms

The use of client/server desktop mailbox protocols like IMAP or POP to
retrieve FPIM messages from a message store is possible without any
special modifications to this specification.  Email clients (and web
browsers) typically have a table for mapping from MIME type to
displaying application.  The image/tiff and content can be configured
so that they invoke the correct viewer for rendering.

7. Capabilities

Knowing the capabilities, preferences and characteristics of
recipients is useful to a sender in preparing an appropriate message.

This specification lays out a method for describing capabilities,
and protocols for making the capabilities available to recipients.

7.1 Capabilities descriptions

In general, it is useful to know several orthoganal aspects of
facsimile recipients: paper size, image resolution, data formats,
compression schemes. It is desirable to allow page description
languages such as application/pdf or application/postscript as
facsimile messages. Thus, capabilities are expressed using
a combination of media type and feature types.

Fax recipients are assumed to accept all media types listed
as "MUST ACCEPT" in section 3. This includes application F
of TIFF.

Other media types are acceptable using the feature notation
in [features]. A recipients capabilities are identified by a
sequence of feature tags.

This draft defines the feature of 'TIFF' with a value taken
from the list of allowable feature types, e.g., TIFF=M for
TIFF application M. 

7.2 message/capabilities

A delivery status notification may be extended to include
a capabilities statement for the recipients, of the form
  Capabilities-for: <email address of recipient>
  Date: <date capabilities were validated>
  Expires: <date capabilities should be considered no longer valid>
  Features: <list of features>
  Types: <list of Internet media types>

7.3 Mechanisms for publishing capabilities

Senders may maintain a directory of recipient addresses
and their corresponding capabilities. The mechanisms for
update of those directories are many, but this profile
defines the following:

7.3.1 As part of DSN

Any failure of a message should result in a reply message which
includes a message/capabilities component.

7.3.1 Using the CAPABILITIES SMTP extension

This delivers fax recipients capabilities directly

7.3.2 As part of RR record of recipient's RHS

A capabilities statement may be obtained directly from DNS.
This is useful when the offramp has high capabilities (e.g.,
is willing to downgrade), and does not add round trip times.

8. Security

Security of fax messaging can be obtained by several methods.  Using
authenticated connections between sender and offramp, using S/MIME or
PGP messages with multipart/signed & multipart/encrypted.

9. Operational Requirements and Limitations

This section describes operational requirements for several elements
and agents, and the limitations expected for such devices.

9.1  Fax onramp requirements

A fax onramp provides a service of accepting a PSTN fax telephone
call, and forwarding the fax via the (E)SMTP protocol, as outlined
herein. In order to meet the timeouts of PSTN fax, it is necessary
either that the onramp be able to store and guarantee complete delivery
of the message at a later time, or else that the next hop SMTP server
provide a positive response of message receipt within the timeout
interval.

In practice, this requirement means that the onramp's next hop must
respond to the end-of-mail data (which is "." if using normal DATA, or
BDAT LAST if using BDAT from [CHUNK]) within the nominal T.30
timeouts [T.30], believed to be 30 seconds.

9.2 Fax Offramp requirements
 
Must implement [DSN, MDN], and must implement [FAX-DSN].
 
9.3 IFax sender limitations

Internet fax machines usually act as an integrated Message User Agent,
often only collecting telephone numbers from the user, but sometimes
having a full alphanumeric keypad allowing entering usernames (looked
up in a database) or a normal email address;

Internet fax machines are not expected to contain a disk drive or
sufficient memory to buffer many pages of document images, e.g.,
to hold the document until confirmation is available.

9.4 Limitations of Internet Mail

The following are limitations of Internet Mail agents that were considered
in designing this protocol.

9.4.1 number of recipients

Some Internet Mail implementations may limit the number of recipients
allowed for a single message; a redistribution agent for Internet Fax
may not be able to queue a large number of outgoing fax messages, with
the limit even possibly being a single recipient.  However, ESMTP
currently does not provide a mechanism for indicating the number of
supported recipients.

If an SMTP server has reached its limit for maximum number of
recipients, it should respond with a 4xx reply code which allows the
SMTP client to retry sending later.

9.4.2 limitations on message size

Some Internet Mail transfer agents may have a limit on the maximum
message length, and may be unable to transfer long documents.  This
protocol does not limit the maximum message length.  Implementors
should understand that some mailers will be unable to accept
excessively long messages.  A mechanism is defined in [SIZE] to
declare the maximum message size supported.

9.4.3 Limitations on quick delivery and confirmation

In many configurations of Internet Mail, the SMTP server does not
handle final delivery to the recipient, but to some shared message
repository.  Thus, any available configurations, 'delivery' is weaker
than that expected for fax.

SMTP delivery is usually not immediate, and confirmation of delivery
(if any) is also not immediate.  SMTP cannot, in general, guarantee to
provide confirmation or non-confirmation of delivery. (Extensions to
SMTP may allow immediate delivery.)

There is no mechanism to regenerate lost confirmation messages,
ven when such facilities are deployed.

10. Security Considerations

The requirements for security in Internet Fax are enumerated in [FAXREQ],
and are addressed here:
  No unsolicited confirmation messages
  Messages may be signed and encrypted
  Traffic between SMTP servers can be encrypted, SMTP sessions
    can be authenticated.


11. References

  [8BIT] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP
  Service Extension for 8bit-MIMEtransport", RFC 1426, United Nations
  University, Innosoft International, Inc., Dover Beach Consulting,
  Inc., Network Management Associates, Inc., The Branch Office, February
  1993.

  [ANTI] A. Vaha-Sipila, "URLs for Telephony", Internet Draft, Work in
  Progress, draft-antti-telephony-url-??.txt.

  [BINARY] G. Vaudreuil, "SMTP Service Extensions for Transmission of
  Large and Binary MIME Messages", RFC 1830, Octel Network Services,
  October 1995.

  [CAPS] D. Wing, N. Joffe, "SMTP Service Extension for Capabilities
  Exchange", Internet Draft, Work in Progress,
  draft-ietf-fax-smtp-capabilities-??.txt.

  [CHECK] D. Crocker, N. Freed, A. Cargille, "SMTP Service Extension for
  Checkpoint/Restart", RFC1845, September 1995.

  [CLAUDIO] C. Allocchio, "PSTN and fax address format in e-mail
  services", Internet Draft, Work in Progress,
  draft-ietf-fax-addressing-??.txt.

  [DSN] K. Moore, "SMTP Service Extensions for Delivery Status
  Notifications", RFC 1891, University of Tennessee, January 1996.

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

  [ESMTP] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP
  Service Extensions", RFC 1869, United Nations University, Innosoft
  International, Inc., Dover Beach Consulting, Inc., Network Management
  Associates, Inc., The Branch Office, November 1995.

  [FAXREQ] L. Masinter, "Requirements for Internet Fax", Internet Draft,
  Work in Progress, draft-ietf-fax-requirements-??.txt.

  [FAX-DSN] D. Wing, "Extensions to Delivery Status Notifications for Fax", 
  Internet Draft, Work in Progress, draft-ietf-fax-dsn-extensions-??.txt

  [ITUDC] D. Crocker, "Procedures for the Transfer of Facsimile Data via
  Internet Mail", Internet Draft, Work in Progress,
  draft-ietf-fax-itudc-??.txt.

  [MDN] R. Fajman, "An Extensible Message Format for Message Disposition
  Notifications", Internet Draft, Work in Progress,
  draft-ietf-receipt-mdn-??.txt.

  [MIME] N. Borenstein, and N. Freed, "Multipurpose Internet Mail
  Extensions", RFC 1521, Bellcore, Innosoft, September 1993.

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

  [NOTIFY] K. Moore, G. Vaudreuil, "An Extensible Message Format for
  Delivery Status Notifications", RFC 1894, University of Tennessee,
  Octel Network Services, January 1996.

  [PIPE] N. Freed, A. Cargille, "SMTP Service Extension for Command
  Pipelining", RFC 1854, October 1995.

  [REPORT] G. Vaudreuil, "The Multipart/Report Content Type for the
  Reporting of Mail System Administrative Messages", RFC 1892, Octel
  Network Services, January 1996.

  [SESSION] N. Joffe, D. Wing, L. Masinter, "SMTP Service Extension for
  Immediate Delivery", Internet Draft, Work in Progress,
  draft-ietf-fax-smtp-session-??.txt.

  [SIZE] J. Klensin, N. Freed, K. Moore, "SMTP Service Extensions for
  Message Size Declaration", RFC 1870, United Nations University,
  Innosoft International, Inc., November 1995.

  [SMTP] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821,
  USC/Information Sciences Institute, August 1982.

  [SUBMISSION] R. Gellens, H. Alvestrand, "Message Submission and
  Relay", Internet Draft, Work in Progress, draft-gellens-submit-??.txt.

  [TIFF-F] G. Parsons, J. Rafferty, "Tag Image File Format (TIFF) -
  Application F", Internet Draft, Work in Progress,
  draft-ietf-fax-tiff-??.txt.

  [TIFF] L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons,
  J. Rafferty, "File Format for Internet Fax", Internet Draft, Work in
  Progress, draft-ietf-fax-tiffplus-??.txt.

  [VPIM]  G. Vaudreuil, G. Parsons, "Voice Profile for Internet Mail -
  version 2", Internet Draft, Work in Progress, draft-ema-vpim-??.txt.

  [WIDE] K. Toyoda, H. Ohno, J. Murai, "WIDE Message-based Fax over the
  Internet", Internet Draft, Work in Progress,
  draft-ietf-fax-wide-??.txt.

  [RFC1893] Ehanced status codes.

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

   [WIDE2] K.Toyoda, H. Ohno, J. Murai, "Facsimile over Internet
   Mail", <draft-ietf-fax-service-00.txt>, November 1997.

13. Acknowledgments

Many thanks to Graham Klyne, who provided a number of careful reviews
of this document. This document is based on the work of various other
authors, including Make Lake and Dave Crocker, who supplied [T.IFax1],
Kiyoshi Toyoda, Hiroyuki Ohno, Jun Murai, who supplied [WIDE2], and
G. Vaudreuil and G. Parsons, who supplied [VPIM].

14. Copyright

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

15. Appendix - Example Fax Message

   The following message is a full-featured, all-options-enabled message
   addressed to two recipients.

     To: 2145551212@vm1.mycompany.com
     To: "Parsons, Glenn, W." 2145551234@VM1.mycompany.com
     From: "Vaudreuil, Greg" 2175552345@VM2.mycompany.com
     Date: Mon, 26 Aug 93 10:20:20 CST
     MIME-Version: 1.0
     ...


16. Authors' Addresses

Larry Masinter
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA 94304  USA
Fax:    +1 415 812 4333
EMail:  masinter@parc.xerox.com


Dan Wing
Cisco Systems, Inc.
101 Cooper Street
Santa Cruz, CA 95060  USA
Phone: +1 408 457 5200
Fax:   +1 408 457 5208
EMail: dwing@cisco.com