IETF Internet fax WG Graham Klyne
Internet draft Integralis Technology Ltd.
1 May 1998
Expires: 1 November 1998
Scenarios for Internet fax capability exchange
<draft-ietf-fax-capability-scenarios-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 made obsolete 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 view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Copyright (C) 1998, The Internet Society
Abstract
The simple mode for Internet fax described in [1] relies on
transmission of documents using a minimum feature set to achieve
interoperability between sender and receiver. Proposals for
extended Internet fax [2,3] aim to provide for transmission of
enhanced documents (e.g. higher resolutions, colour) by employing
mechanisms to identify recipient capabilities to the sender, in the
same fashion as traditional Group 3 fax [4].
This memo describes some of the scenarios for capability exchange
in Internet fax, taking account of the particular nature and goals
of the application [5], with a view to informing the debate over
what mechanisms should be used for this purpose.
Klyne [Page 1]
Internet draft 1 May 1998
Scenarios for Internet fax capability exchange
Table of contents
1. Introduction.............................................2
1.1 Terminology ..........................................3
1.2 Structure of this document ...........................3
1.3 Discussion of this document ..........................3
1.4 Amendment history ....................................4
1.5 Unfinished business ..................................4
2. Capability exchange issues in Internet fax...............4
3. Scenarios................................................5
3.1 User scenarios .......................................6
3.2 Deployment scenarios .................................7
3.3 Traditional facsimile scenarios ......................9
3.3.1 Summary of T.30 DIS frame........................9
3.3.2 Fax polling......................................9
4. Implementation notes.....................................10
4.1 Identification of capabilities .......................10
4.2 Denotation of capabilities ...........................10
4.3 Mechanisms for capability exchange ...................10
5. Security considerations..................................11
6. Copyright................................................12
7. Acknowledgements.........................................12
8. References...............................................12
9. Author's address.........................................15
1. Introduction
The simple mode for Internet fax described in [1] relies on
transmission of documents using a minimum feature set to achieve
interoperability between sender and receiver. Proposals for
extended Internet fax [2,3] aim to provide for transmission of
enhanced documents (e.g. higher resolutions, colour) by employing
mechanisms to identify recipient capabilities to the sender.
Traditional facsimile employs a system of capability
identification, built in to the underlying facsimile transmission
protocol [4], so that documents can be transmitted with quality
greater than is provided by the base format capability common to
all facsimile machines.
A number of suggestions have been made [7,9, and others not
formally published] to provide similar facilities for facsimile
data transmitted using Internet e-mail. But, because Internet
e-mail is quite different to traditional facsimile transmission
technologies, the mechanisms used must be different.
Klyne [Page 2]
Internet draft 1 May 1998
Scenarios for Internet fax capability exchange
This memo describes some of the scenarios for capability exchange
in Internet fax, taking account of the particular nature and goals
of the application [5], with a view to informing the debate about
what mechanisms should be used for this purpose.
1.1 Terminology
Terminology used in this document that is specific to Internet fax
is taken from [5].
1.2 Structure of this document
The main part of this memo addresses the following areas:
Section 2 discusses some of the technical issues that make
provision of traditional facsimile capability identification
somewhat problematic in Internet e-mail, and contrasts the features
of traditional fax transport mechanisms with Internet e-mail that
make this so.
Section 3 describes some scenarios for capability exchange in
Internet fax, from the viewpoints of system users, deployment and
traditional facsimile service offerings.
Section 4 discusses some general concepts that might have a bearing
on how capability identification might be implemented for Internet
fax.
1.3 Discussion of this document
Discussion of this document should take place on the Internet fax
mailing list hosted by the Internet Mail Consortium (IMC):
Please send comments regarding this document to:
ietf-fax@imc.org
To subscribe to this list, send a message with the body 'subscribe'
to "ietf-fax-request@imc.org".
To see what has gone on before you subscribed, please see the
mailing list archive at:
http://www.imc.org/ietf-fax/
To unsubscribe from the ietf-fax mailing list, send a message to
"ietf-fax-request@imc.org" containing the message 'unsubscribe'.
Klyne [Page 3]
Internet draft 1 May 1998
Scenarios for Internet fax capability exchange
1.4 Amendment history
00a 31-Mar-1998
Document initially created.
00b 01-May-1998
Minor updates based on feedback received. Update
references. Extended security considerations section.
1.5 Unfinished business
. Add new scenarios identified by ongoing debate and review.
. Complete the T.30 scenarios with input from T.30 experts.
2. Capability exchange issues in Internet fax
Technical differences between the Internet e-mail SMTP transport
[11] and the facsimile T.30 transmission protocol [4] that tend to
dictate different approaches to capability exchange are:
. SMTP is a store-and-forward protocol, which means that the sender
of a message is generally disengaged from the message transfer
process at the time final delivery is accomplished. T.30, on the
other hand, is a session mode protocol in which the transmitter
of a message is directly involved in the process until final
delivery is accomplished and signalled back to the sender.
(There is a proposal to provide a session mode capability in SMTP
[10], but in its present form even this may be forced to fall
back to store-and-forward mode in some circumstances.)
Because SMTP is a store-and-forward protocol, there may be
arbitrary delays in the transfer of a message
. Being a store-and-forward Internet protocol, SMTP can service
occasionally connected correspondents; thus there is no
requirement or expectation for the ultimate recipient to be
accessible at the time a message is sent. Traditional facsimile,
on the other hand, relies on the fact that telephone devices are
always physically connected to the network and available to
receive calls (except when they are busy).
A related consideration is that SMTP senders do not have to be
concerned with the possibility that the recipient is busy at the
time a message is sent. But the next-hop MTA may be unavailable
for a variety of reasons, so some system of retries is required.
Klyne [Page 4]
Internet draft 1 May 1998
Scenarios for Internet fax capability exchange
. In T.30, the sender of a message connects directly to and
interacts with the receiver. Using SMTP, this is not generally
the case and an indeterminate number of intermediate relays
(MTAs) may be involved in the transmission process. The
capabilities of these intermediate systems is not generally known
or knowable.
. T.30 is a binary protocol; i.e. protocol elements and data are
represented as arbitrary bit streams. SMTP on the other hand is
a text-based protocol, and all protocol elements and data must be
represented in a stream of US-ASCII text; this imposes
restrictions on the way that protocol elements are coded.
(Similar restrictions also apply to the data in SMTP, but these
restrictions are generally made transparent through the use of
MIME transfer encoding of message data.)
. In general, there are significant per-message call setup and
volume-related transmission costs associated with traditional
facsimile. When using SMTP, there are generally no per-message
or volume-related transmission costs. (This is a simplification,
and there are exceptions in both cases, but holds widely enough
to be a good working model.)
. Traditional facsimile calls are placed using a dedicated physical
connection, and while that connection is in use for one message
transfer it cannot be used for any other purpose. SMTP message
transfers can share a physical connection between several
different activities.
This has implications for possible concurrent use of multiple
services or capability acquisition mechanisms.
3. Scenarios
In this section, scenarios are presented from three different
perspectives:
. User scenarios: capability identification scenarios based on the
resulting message transfer behaviour that would be visible to a
user of the system.
. Deployment scenarios: based on the effect that capability
identification has on the way that messages flow through the
network infrastructure.
Klyne [Page 5]
Internet draft 1 May 1998
Scenarios for Internet fax capability exchange
. Traditional facsimile scenarios: based on capability exchange
behaviours which have come to be associated with Group 3
facsimile. This section examines various commonly-used
capability identification mechanisms present in T.30 [4] and
considers their applicability to the Internet e-mail environment.
In all cases, the goal is to provide interoperability between
sender and receiver of a message; i.e. to achieve a message
transfer which can be processed by the recipient, or to advise the
sender that a desired transfer is not possible.
3.1 User scenarios
These scenarios focus on issues of presentation quality, as
evidenced by media features and a recipient's capability to handle
them. Many of the scenarios may extend to non-media capabilities
(e.g. encryption, language).
. Sender wishes to send a simple low-resolution monochrome image,
per "simple mode" [1]. This should always be sent regardless of
any capability exchange mechanisms available or employed.
. Sender wishes to send a high-resolution monochrome image, but the
information content would still be useful if sent at a lower
resolution. No capability information about the receiving system
is known or available. The sender has two options: (a) send the
image at reduced quality only, or (b) send a multipart/alternate
containing full quality and reduced quality [12].
. Sender wishes to send a high-resolution monochrome image, but the
information content would still be useful if sent at a lower
resolution. Capability information of dubious reliability about
the receiving system available, suggesting that the recipient can
handle the full quality. The sender's options are the same as
above, but there is greater reason to send both formats. Sending
the high-quality image only is probably not a good idea (see
security considerations).
. Sender wishes to send a high-resolution monochrome image.
Available and trusted capability information indicates that the
receiving system is known or available to handle this format.
The image can be sent at full quality only.
. Sender has a high quality colour image (e.g. promotional
literature) which needs to be sent at full quality to be of any
use.
In the absence of any capability information, the sender may
either (a) send the message and hope, or (b) take steps to
acquire the receiver's capabilities.
Klyne [Page 6]
Internet draft 1 May 1998
Scenarios for Internet fax capability exchange
Having capability information of dubious reliability indicating
that the recipient can handle the image, the same options are
available but there is probably greater reason to send the image
straight away.
Having capability information of dubious reliability which
indicates that the recipient cannot handle the image, the sender
might follow either of the options suggested above, but possibly
with greater preference for acquiring capabilities before sending
the message. Alternatively, he might give up and not send the
message at all (probably not a good idea).
. Sender has an original document in different formats each
requiring a different set of enhanced recipient capabilities for
optimum display. One of the formats would also provide usable
information to a recipient with minimum capabilities, per [1],
but the other would provide optimum display for a recipient with
the required capabilities. Depending upon available capability
information the sender has options to send (a) the best format,
(b) the not-so-good format which will display with minimum
capabilities, (c) both formats.
In all the above cases, the sender's choice may be modified by the
cost of transmitting the message, which in turn will depend upon
the size of the various possible message formats and the ultimate
destination. For example, he may decline to send a multi-Megabyte
presentation graphic which would incur international offramp
charges without knowing that the recipient could process that data.
3.2 Deployment scenarios
This section discusses deployment scenarios, which have a bearing
on the kind of negotiation or capability identification mechanisms
that could prove useful.
. Corporate mail and Internet fax server with access to corporate
address book and fax offramp systems. Such a system might
conduct authoritative capability identification on behalf of the
users in its address book, with the idea that messages for users
that might be delivered by e-mail or fax transmission can be
handled.
. A combination of SMTP session mode and capability identification
extensions [9, 10] could provide a capability identification
mechanism that operates via the Internet to provide G3 fax like
negotiation.
In this scenario, security concerns about privacy and accuracy of
information are heightened, and these would need be addressed in
some way.
Klyne [Page 7]
Internet draft 1 May 1998
Scenarios for Internet fax capability exchange
. Capabilities can be sent with message disposition notification
(per [7]). Some form of capability information would be available
after a message had been sent to a given destination, but might
become stale if messages are sent infrequently to that recipient.
This has associated security concerns. Addressing the security
concerns discussed in [7] will go some way to addressing these.
. Capabilities can be sent with outgoing messages (e.g. per
[13,14]), to be used in any return message. These, too, can
become stale. Also, for communication between send-only and
receive-only systems, the capability information is of little use
(unless the receiving system can lodge it in some common area for
use by related sending systems).
. Capabilities might be cached on an MTA server which is close to
the recipient of a message and which can be made readily and
immediately available to sending parties. (Information held
closer to the receiving system is likely to be more reliable than
more remote information.)
. Multiple copies (multipart/alternate) could be sent to an
intervening MTA, which could then conduct negotiation on the
sender's behalf to select the best version to deliver.
. Format-converting gateways might be used to accept a variety of
formats which the receiver does not recognize. Declared receiver
capabilities would also include conversion capabilities of the
gateway. This may introduce secondary security concerns if
message integrity/authentication mechanisms are being employed.
. Capability identification can be used for Internet-to-Internet,
Internet-to-GSTN (via an offramp gateway) and GSTN-to-Internet
(via an onramp gateway). In the onramp/offramp cases, capability
information would relate to the gateway's ability to accept data
and pass it on in a form usable by the ultimate addressee, rather
than necessarily indicating the addressee's capabilities.
. Hunt groups: a given recipient address (phine number, etc.) may
connect to any of several receiving systems in a "hunt group".
If different systems in the group have different capabilities, a
possibility exists for capability identification information from
one exchange to cause a sending system to send unusable data in a
subsequent message transmission.
Klyne [Page 8]
Internet draft 1 May 1998
Scenarios for Internet fax capability exchange
3.3 Traditional facsimile scenarios
3.3.1 Summary of T.30 DIS frame
The following paraphrases an analysis of bits in the T.30 DIS frame
with a view to their relevance to capability identification, which
was posted to the IETF-FAX discussion list:
. The DIS bits up to about bit 45 are mainly concerned with
resolution, compression, width and size capabilities etc. Things
like transmission speed and scan line time capabilities are not
relevant in a store and forward environment, but would be dealt
with by the off-ramp transmitter.
Special image characteristics of the receiver cannot be so dealt
with and are best known in advance via negotiations.
Thus, DIS 1-45 are covered by [20], or are irrelevant to Internet
fax capability identification.
. Bits 47-64 deal with polling, sub-addressing, password, non-image
data (including BFT) and alternative negotiation methods.
Polling is discussed in a separate section below.
Sub-addressing can be handled by conversion to the format
described in [16,17] at the onramp and offramp gateways.
Non-image transfer is logically handled by MIME encapsulation
[18,12], though there are some issues about mapping Object Ids
(used by the Group 3 fax binary file envelope T.434 [19]
Security presents some real problems because of the impossibility
of passing a secured message through a gateway (which by the
nature of T.30 and SMTP must convert the data content in some
way) without possessing the relevant security keys.
[[Identify T.30 capability/negotiation options in greater detail,
and relevance to Internet fax operations]]
3.3.2 Fax polling
Polling raises the following issues:
(a) identifying whether or not polling is available (or, strictly
following the Group 3 facsimile model, to determine if data is
available to be polled),
(b) content selection for polled data, and
Klyne [Page 9]
Internet draft 1 May 1998
Scenarios for Internet fax capability exchange
(c) whether or not polling is required and appropriate in the
context of Internet fax (given the alternate methods
available), and the mechanisms appropriate for performing
polling.
It has been noted that although polling is commonly performed with
Group 3 facsimile, it is often used for special applications and
performed using special purpose features rather than the standard
T.30 facilities for this purpose.
4. Implementation notes
To define a deployable system for capability exchange in Internet
fax, the following issues must be addressed:
4.1 Identification of capabilities
The specific capabilities which can be exchanged must be identified
(or at least, some initial set).
The Group 3 facsimile protocol, T.30 [4], defines a number of such
capabilities, identified by bits in the DIS frame and in other
protocol frames.
A number of features related to media type and capability are
identified in [20]. This document has, by design, a high degree of
overlap with media features identified by T.30.
It may be desirable to also provide some higher-level
identification of capabilities, such as general support for
Internet fax.
4.2 Denotation of capabilities
A way to represent capabilities carried within the SMTP protocol
must be defined. The limitations of SMTP suggest that a textual
format should be used (as opposed to the binary formats used for
T.30).
4.3 Mechanisms for capability exchange
Mechanisms for capability exchange (i.e. carrying capability
information between correspondents) fall into two broad categories:
. Connected, using some form of direct client/server enquiry
protocol (e.g. LDAP [15], T.30 frames [4], SMTP capabilities
[9]).
Klyne [Page 10]
Internet draft 1 May 1998
Scenarios for Internet fax capability exchange
. Disconnected, carried by SMTP as message data (e.g. MDN
extensions [7], vCard with message [13,14]).
This does not address the ever-present possibility of using any
kind of out-of-band mechanism to supply information about a
recipient to the sending agent (e.g. user input).
5. Security considerations
The following are primary security concerns for capability exchange
mechanisms:
. Unintentional disclosure of private information through the
announcement of capabilities or user preferences.
. Disruption to system operation caused by accidental or malicious
provision of incorrect capability information.
. Use of a capability identification mechanism might be used to
probe a network (e.g. by identifying specific hosts used, and
exploiting their known weaknesses).
Security considerations relevant to Internet fax are discussed
further in [1,5].
The most contentious security concerns are raised by mechanisms
which automatically send capability identification data in response
to a query from some unknown system. Use of directory services
(based on LDAP [15], etc.) seem to be less problematic because
proper authentication mechanisms are available.
Mechanisms which provide capability information when sending a
message are less contentious, presumably because some intention on
the part of the person whose details are disclosed to communicfate
with the recipient of those details can be inferred. This does
not, however, address spoofed supply of incorrect capability
information.
The use of format converting gateways may prove probelmatic because
such systems would tend to defeat any message integraty and
authenticity checking mechanisms that are employed.
Klyne [Page 11]
Internet draft 1 May 1998
Scenarios for Internet fax capability exchange
6. Copyright
Copyright (C) The Internet Society 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.
7. Acknowledgements
The ideas in this document came from a meeting with particular
contributions from James Rafferty, Larry Masinter, Richard Shockey.
Further ideas have been taken from postings to the IETF-FAX mailing
list.
8. References
[1] "A Simple Mode of Facsimile Using Internet Mail"
K. Toyoda,
H. Ohno
J. Murai, WIDE Project
D. Wing, Cisco
RFC 2305
March 1998
Klyne [Page 12]
Internet draft 1 May 1998
Scenarios for Internet fax capability exchange
[2] "Extended Facsimile Using Internet Mail"
Larry Masinter, Xerox Corporation
Dan Wing, Cisco Systems
Internet draft: <draft-ietf-fax-eifax-00.txt>
Work in progress, March 1998
[3] "Procedures for the Transfer of Facsimile Data via Internet Mail"
D. Crocker, Internet Mail Consortium
Internet draft: <draft-ietf-fax-itudc-00.txt>
Work in progress, October 1997
[4] ITU Recommendation T.30:
"Procedures for document facsimile transmission in the General
Switched Telephone Network"
International Telecommunications Union, 1996
[5] "Terminology and Goals for Internet Fax"
Larry Masinter, Xerox Corporation
Internet draft: <draft-ietf-fax-goals-02.txt>
Work in progress, March 1998
[6] "Extensions to Delivery Status Notifications for Fax"
Dan Wing, Cisco Systems
Internet draft: <draft-ietf-fax-dsn-extensions-00.txt>
Work in progress, November 1997.
[7] "Using Message Disposition Notifications to Indicate Supported
Features"
Dan Wing, Cisco Systems
Internet draft: <draft-ietf-fax-mdn-features-01.txt>
Work in progress, March 1998
[8] "Operational Guidelines for Fax over SMTP"
Larry Masinter, Xerox Corporation
Dan Wing, Cisco Systems
Internet draft: <draft-ietf-fax-operation-00.txt>
Work in progress, March 1998
[9] "SMTP Service Extension for Capabilities Exchange"
Dan Wing,
Neil Joffe, Cisco Systems
Internet draft: <draft-ietf-fax-smtp-capabilities-00.txt>
Work in progress, November 1997
[10] "SMTP Service Extension for Immediate Delivery"
Dan Wing,
Neil Joffe, Cisco Systems
Larry Masinter, Xerox Corporation
Internet draft: <draft-ietf-fax-smtp-session-02.txt>
Work in progress, February 1998
Klyne [Page 13]
Internet draft 1 May 1998
Scenarios for Internet fax capability exchange
[11] RFC 821, "Simple Mail Transfer Protocol"
J. Postel, Information Sciences Institute, University of Southern
California
August 1982.
[12] RFC 2046, "Multipurpose Internet Mail Extensions (MIME)
Part 2: Media types"
N. Freed, Innosoft
N. Borenstein, First Virtual
November 1996.
[13] vCard - The Electronic Business Card Version 2.1
Internet Mail Consortium
URL: <http://www.imc.org/pdi/vcard-21.txt>
September 1996.
[14] vCard MIME Directory Profile
Frank Dawson, Lotus Development Corporation
Tim Howes, Netscape Communications
Internet draft <draft-ietf-asid-mime-vcard-06.txt>
Work in progress: April 1998.
[15] RFC 2251, "Lightweight Directory Access Protocol (v3)"
M. Wahl, Critical Angle Inc.
T. Howes, Netscape Communications Corp.
S. Kille, Isode Limited
December 1997.
[16] RFC 2303, "Minimal PSTN address format in Internet Mail"
C. Allocchio, GARR-Italy
March 1998.
[17] RFC 2304, "Minimal FAX address format in Internet Mail"
C. Allocchio, GARR-Italy
March 1998.
[18] RFC 2045, "Multipurpose Internet Mail Extensions (MIME)
Part 1: Format of Internet message bodies"
N. Freed, Innosoft
N. Borenstein, First Virtual
November 1996.
[19] ITU-T Recommendation T.434,
"Binary file transfer format for the telematic services"
International Telecommunications Union
July 1996
Klyne [Page 14]
Internet draft 1 May 1998
Scenarios for Internet fax capability exchange
[20] "Media Features for Display, Print, and Fax"
Larry Masinter, Xerox Corporation
Koen Holtman, TUE
Andy Mutz, Hewlett Packard
Dan Wing, Cisco Systems
Internet draft: <draft-ietf-conneg-media-features-00.txt>
Work in progress, March 1998
9. Author's address
Graham Klyne
Content Technologies Ltd
Forum 1
Station Road
Theale
Reading, RG7 4RA
United Kingdom
Telephone: +44 118 930 1300
Facsimile: +44 118 930 1301
E-mail: GK@ACM.ORG
Klyne [Page 15]
