Internet DRAFT - draft-ietf-fax-scenerios
draft-ietf-fax-scenerios
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 02:23:04 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 11 Nov 1997 20:32:00 GMT
ETag: "2ed9a7-47dd-3468c0c0"
Accept-Ranges: bytes
Content-Length: 18397
Connection: close
Content-Type: text/plain
Applications Area Dan Wing
Internet Draft Cisco Systems, Inc.
November 11, 1997
Expires May 1998
Scenerios for Delivery of FAX messages over SMTP
draft-ietf-fax-scenerios-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 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 Notice
Copyright (C) The Internet Society (1997). All Rights Reserved.
1. Abstract
This document describes various fax-over-SMTP implementation and
deployment scenerios and some of the problems inherient with various
solutions.
Most of these scenerios have been described and discussed on the
IETF-FAX mailing list.
Wing Expires May 1998 [Page 1]
Internet Draft Scenerios for FAX over SMTP November 1997
2. Table of Contents
1. Abstract
2. Table of Contents
3. Introduction
3.1. Definitions
3.2. Discussion of this Draft
4. Scenerios
4.1. Onramp: Legacy FAX to SMTP
4.1.1. Redialer
4.1.2. FAX Replacement
4.2. Offramp: SMTP to Legacy FAX
4.3. Combinations
4.3.1. Legacy to Legacy
4.3.2. SMTP to SMTP
5. Interaction of fax with existing SMTP infrastructure
5.1. Large messages
5.2. Firewalls
5.3. Gateways to non-SMTP mail systems
5.4. Intermittent connection to the Internet
5.5. Streaming
5.5.1. Streaming and message authentication
5.6. Delays
5.6.1 Transmission delays
5.6.2. Read delays
5.6.3. Delivery receipts
5.6.4. Capabilities exchange
5.6.4. Use of NOTIFY=DELAY
6. Security Considerations
7. Acknowledgments
8. References
9. Copyright
10. Author's Address
3. Introduction
Many possible scenerios exist for fax-over-SMTP. Perhaps most important
is the ability to receive from, and send to, a legacy fax machine which
is connected to the PSTN. In addition it is desirable to send a fax
image between two users on email.
This document describes how an onramp and offramp device might function
with the existing SMTP infrastructure, especially when these devices
cannot perform normal "storing" of email as part of SMTP "store and
forward" messaging.
Onramp and offramp devices might be implemented as part of a
Wing Expires May 1998 [Page 2]
Internet Draft Scenerios for FAX over SMTP November 1997
multitasking server, such as Unix or Windows NT, with an integrated SMTP
client/server, disk drive, and directory, dialplan, and alias lookup
functions. Onramp and offramp boxes might also be implemented inside
fax machines, multifunction devices, or might be "bump-in-the-wire"
devices and have no disk drive (to minimize cost and increase MTBF).
This document is a companion to the "Requirements for Internet Fax"
[FAQ-REQ] document.
3.1. Definitions
This document uses several terms which aren't in common use.
onramp: A device which receives an incoming fax call, translates the
fax image to TIFF-F, and can send the message to an SMTP server. An
onramp can be diskless and have limited memory capacity.
offramp: A device which receives an SMTP message in TIFF-F format and
calls a fax machine, translates the TIFF-F message to a fax image, and
transmits the fax image to the remote fax machine. An offramp can be
diskless and have limited memory capacity.
PSTN: Public Switched Telephone Network.
redialer: A "bump-in-the-cord" device which sits between a fax machine
and the PSTN and dials a pre-programmed number whenever the fax
machine dials a number. When the remote system answers, the redialer
sends the remote system the phone numbers that were originally sent by
the fax machine.
TIFF-F: File format for interchange of FAX images, described in
[TIFF-F].
3.2. Discussion of this Draft
This draft is being discussed on the "ietf-fax" mailing list. To
subscribe, send a message to:
ietf-fax-request@imc.org
with the line:
subscribe
in the body of the message. Archives are available from
http://www.imc.org/ietf-fax.
4. Scenerios
Wing Expires May 1998 [Page 3]
Internet Draft Scenerios for FAX over SMTP November 1997
Three primary scenerios are discussed.
a. Onramp: Legacy fax to SMTP
b. Offramp: SMTP to legacy fax
c. Combinations
4.1. Onramp: Legacy FAX to SMTP
Several scenerios exist for causing the transmission from a legacy
fax machine to be sent through SMTP. Once the transmission is an
SMTP message, the message can then be sent to another fax machine
or to a user's SMTP mailbox.
4.1.1. Redialer
This situation would normally occur if the sender (who owns the legacy
fax machine) joins a service which delivers FAXes to a user's mailbox.
This might be useful to provide a familiar user experience to the
sender
[legacy fax] -> [redialer] -> [PSTN] -> [onramp] -> [SMTP]
Redialer boxes are made by manufacturers like [MITEL] and [TELKOM].
4.1.2. FAX Replacement
Here the recipient has replaced their fax machine with an onramp.
This might be done to automate fax distribution via T.30 subaddresses,
a human, , or other methods to decide the ultimate desination of an
incoming fax.
[legacy fax] -> [PSTN] -> [onramp] -> [SMTP]
4.2. Offramp: SMTP to Legacy FAX
An SMTP message can be sent to a legacy fax device via an offramp. This
offramp could be on-premisis, built into a mailer, or could be a service
provided by an Internet Service Provider.
[SMTP] -> [offramp] -> [PSTN] -> [legacy fax]
Wing Expires May 1998 [Page 4]
Internet Draft Scenerios for FAX over SMTP November 1997
4.3. Combinations
The above scenerios can be combined to provide other delivery scenerios.
4.3.1. Legacy to Legacy
By combining a solution from section 3.1 with 3.2, it is possible to
deliver from legacy fax to legacy fax.
4.3.2. SMTP to SMTP
By making the onramp device a PC running normal messaging software (such
as Netscape, IE, or Eudora), and the offramp a normal SMTP/POP server,
you can send a fax image from one SMTP user to another SMTP user.
5. Interaction of fax with existing SMTP infrastructure
5.1. Large messages
[HOST-REQ] stipulates that a mail transfer agent (MTA) must support
a maximum message size of at least 64Kb, but encourages implementors
to not impose a limit if at all possible.
Messages larger than 64K bytes MAY be truncated or returned to the
sender.
Implementations should consider solutions, such as message/partial
[MIME-TYPES], to send messages in small enough parts to be transported
by mailers that impose a size limit. As fax offramps must be presented
with the message in its entirety:
1. The FAX offramp can be implemented as a POP3/IMAP4 client with
support for message/partial (which requires the fax offramp know, a
priori, which 'users' it must check mail for), or,
2. an MTA 'close' to the fax offramp must reassemble the message prior
to presenting it to the fax offramp.
[MIME-FAQ] also mentions large messages:
"3.10) What's ESMTP, and how does it affect MIME?
ESMTP (Extended Simple Mail Transfer Protocol) is a mechanism
by which extensions to "traditional" (RFC 821) SMTP can be
Wing Expires May 1998 [Page 5]
Internet Draft Scenerios for FAX over SMTP November 1997
negotiated by client and server. The mechanism (RFC 1869) is
open-ended; so far two extensions have been defined.
Message size declaration (RFC 1870) offers a graceful way for
servers to limit the size of message they are prepared to
accept. (With SMTP, the only possibility is for the server
to discard the message after it has been sent in its
entirety. There is no way for the client to know that it was
the size of the message that caused the problem.)
When a message is returned to the user as being too large to
deliver, one possible approach might be to fragment the
message using the MIME Message/Partial mechanism, and
resubmit it.
Depending on the exact reason for the "too large" rejection,
this may or may not be a good idea. For example, the
limitation may reflect the recipient's disk quota, in which
case the fragmented message will not be fully deliverable
either.
The possibility of fragmentation should, therefore, be left
to the user's discretion (not performed automatically by the
SMTP client)."
[...]
5.2. Firewalls
Companies deploy firewalls to protect their internal networks from
external networks, such as the Internet or other companies which are
connected to their internal networks.
Many firewalls impose restrictions on SMTP messages, as described
in [FIREWALL-REQ].
Some firewall packages lack support for Delivery Status Notifications
[SMTP-DSN], which Internet FAX intends to use for end-to-end delivery
confirmation.
However, as [MDN] is done with SMTP headers (and not
5.3. Gateways to non-SMTP mail systems
With delivery of faxes as normal SMTP messages, these messages must be
able to be transferred to non-SMTP mail systems, such as X.400, and
proprietary mail systems such as Lotus cc:Mail, Microsoft Exchange,
Wing Expires May 1998 [Page 6]
Internet Draft Scenerios for FAX over SMTP November 1997
and DEC All-In-One.
5.4. Intermittent connection to the Internet
POP3/IMAP - require knowing telephone number (as username) for login
TURN, ETRN, [OD-RELAY].
5.5. Streaming
5.5.1. Streaming and message authentication
FAX onramp and offramp devices aren't expected to have a disk drive,
and thus must stream their fax (and SMTP) data. Message authentication
methods such as [PGP-MIME] and [SMIME] provide the signature at the
end the message, which is too late for an offramp device to determine
that a message has failed authentication.
5.6. Delays
Today, fax provides immediate delivery. When a fax is being
transmitted, users know the fax is being printed on the remote end, and
often times users will call the recipient to tell them "the document
is on your fax machine".
Delays over SMTP are common, and some of them are enumerated below.
5.6.1 Transmission delays
SMTP causes arbitrary transmission delays which are entirely dependent
on the availability of an MTA in the SMTP 'path', the availability
of the recipient's SMTP server which stores the message in the user's
mailbox, and network outages, among other factors.
5.6.2. Read delays
Today, most users read their mail using products such as Netscape,
Internet Explorer, and Eudora. These products use the POP3 protocol to
read messages, and SMTP to send messages. New versions of these
products support IMAP4, a replacement for POP3.
Currently, there is no mechanism for an SMTP server to indicate
Wing Expires May 1998 [Page 7]
Internet Draft Scenerios for FAX over SMTP November 1997
new mail has been received. Instead, the email software continually
polls the POP server, typically every 5 to 10 minutes, to check for new
mail.
While users can usually configure their mail readers to check for mail
more often, and can always force the mail reader to check for new
messages by clicking a button on the user interface, users are not
informed immediately when a new message arrives. This delay causes
many people to erroneously believe that SMTP has an additional 5-10
minute "delay", and this belief will likely carry over to delivery
of fax messages to user's SMTP mailboxes.
Users that only check mail occasionally (because of a non-permanent
connection to the Internet, for example) will not receive messages
immediately.
5.6.3. Delivery receipts
A delivery receipt (either generated by [DSN] or [MDN]) is subject to
the same delays as a normal SMTP message. Thus if a message takes, on
average, 3 minutes to be delivered to the recipient, the receipt should
be expected to take at least 3 minutes to be sent to the originator of
the message.
5.6.4. Capabilities exchange
The delays described above would also occur with SMTP-based
capabilities exchange as described in [ITU-FAX].
5.6.4. Use of NOTIFY=DELAY
[SMTP-DSN] provides a mechanism (NOTIFY=DELAY) which allows a sender to
request a DSN if a message is "delayed".
However, each SMTP implementation is free to decide on the definition of
"delayed", thus such a request may not be useful unless the sender is
aware of the definition of a "delayed" message by all MTAs in the SMTP
6. Security Considerations
Security considerations are not (yet) described in this memo.
Wing Expires May 1998 [Page 8]
Internet Draft Scenerios for FAX over SMTP November 1997
7. Acknowledgments
XXX
8. References
[SMTP-DSN]
K. Moore, "SMTP Service Extension for Delivery Status
Notifications", RFC 1891, January 1996.
[FIREWALL-REQ]
N. Freed, K. Carosso, "An Internet Firewall Transparency
Requirement", Internet Draft, Work in Progress,
draft-freed-firewall-req-??.txt.
[FAX-PROFILE]
unknown, "FAX Profile for Internet Mail", Internet Draft, Work in
Progress, draft-ietf-fax-profile-??.txt
[FAX-REQ]
L. Masinter, "Requirements for Internet FAX", Internet Draft,
Work in Progress, draft-ietf-fax-requirements-??.txt.
[HOST-REQ]
R. Braden, "Requirements for Internet Hosts -- Application and
Support", STD-3, RFC 1123, October 1989.
[ITU-FAX]
D. Crocker, "PROCEDURES FOR THE TRANSFER OF FACSIMILE DATA VIA
INTERNET MAIL", Internet Draft, Work in Progress,
draft-ietf-fax-itudc-??.txt.
[MAIL]
D. Crocker, "Standard for the Format of ARPA Internet Text
Messages", STD-10, RFC 822, August 1982.
[MDN]
R. Fajman, "An Extensible Message Format for Message Disposition
Notifications", Internet Draft, Work in Progress,
draft-ietf-receipt-mdn-??.txt.
[MIME-FAQ]
"comp.mail.mime frequently asked questions list",
ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/mime-faq/part3
[MIME-TYPES]
N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions
Wing Expires May 1998 [Page 9]
Internet Draft Scenerios for FAX over SMTP November 1997
(MIME) Part Two: Media Types", RFC 2046, November 1996.
[MITEL]
Mitel Enterprises, http://www.mitel.com
[OD-RELAY]
R. Gellens, "On-Demand Mail Relay", Internet Draft, Work in
Progress, draft-gellens-on-demand-??.txt.
[PGP-MIME]
M. Elkins, "MIME Security with Pretty Good Privacy (PGP)",
RFC2015, October 1996.
[SMIME]
S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka,
"S/MIME Message Specification", Internet Draft, Work in Progress,
draft-dusse-smime-msg-??.txt.
[SMTP]
J. Postel, "SIMPLE MAIL TRANSFER PROTOCOL", STD-10, RFC 821,
August 1982.
[SMTP-EXT]
J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP
Service Extensions", STD-10, RFC 1869, November 1995.
[SMTP-ENH-ERR]
N. Freed, "SMTP Service Extension for Returning Enhanced Error
Codes", RFC 2034, October 1996.
[TIFF-F]
G. Parsons, J. Rafferty, "Tag Image File Format (TIFF) -
Application F", Internet Draft, Work In Progress,
draft-ietf-fax-tiff-??.txt.
9. 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
Wing Expires May 1998 [Page 10]
Internet Draft Scenerios for FAX over SMTP November 1997
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.
10. Author's Address
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
Wing Expires May 1998 [Page 11]
