Network Working Group D. Crocker
Internet-Draft: Brandenburg InternetWorking
Expiration <9/2004> G. Klyne
Nine By Nine
March 11, 2004
Full-mode Fax Profile for Internet Mail: FFPIM
(draft-ietf-fax-ffpim-03.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), nic.nordu.net (Europe), munnari.oz.au (Pacific
Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US
West Coast).
ABSTRACT
Classic facsimile document exchange represents both a set of
technical specifications and a class of service. Previous
work has replicated some of that service class as a profile
within Internet mail. The current specification defines
ôfull modeö carriage of facsimile data over the Internet,
building upon that previous work and adding the remaining
functionality necessary for achieving reliability and
capability negotiation for Internet mail, on a par with
classic T.30 facsimile. These additional features are
designed to provide the highest level of interoperability
with the standards-compliant email infrastructure and mail
user agents, while providing a level of service that
approximates what is currently enjoyed by fax users.
The IETF has been notified of intellectual property rights
claimed in regard to some or all of the specification
contained in this document. For more information, consult
the online list of claimed rights in
<http://www.ietf.org/ipr.html>.
COPYRIGHT NOTICE
Copyright (C) The Internet Society (2004). All Rights
Reserved.
TABLE OF CONTENTS
1. Introduction
2. Content Negotiation
2.1. UA-based content negotiation
2.2. ESMTP-based content negotiation
2.3. Interactions between UA and ESMTP negotiation
mechanisms
3. Content Format
4. Security Considerations
5. References
Appendix A û Direct Mode
Appendix B û Acknowledgements
Appendix C û Contact
Appendix D û Full Copyright Statement
1. INTRODUCTION
The current specification defines ôfull modeö carriage of
facsimile data over the Internet, building upon previous
work [RFC2305, RFC2532] and adding the remaining
functionality necessary for achieving reliability and
capability negotiation for Internet mail that is on a par
with classic T.30 facsimile. These additional features are
designed to provide the highest level of interoperability
with the standards-compliant email infrastructure and mail
user agents, while providing a level of service that closely
approximates the level of service currently enjoyed by fax
users.
Basic terminology is discussed in [RFC2542].
Implementations which conform to this specification MUST
also conform to [RFC2305] and [RFC2532].
The new features are designed to be interoperable with the
existing base of mail transfer agents (MTAs) and mail user
agents (MUAs), and to take advantage of existing standards
for optional functionality, such as positive delivery
confirmation and disposition notification. Enhancements
described in this document utilize the existing Internet
email messaging infrastructure, where possible, instead of
creating fax-specific features that are unlikely to be
implemented in non-fax messaging software.
The key words ôMUSTö, ôMUST NOTö, ôREQUIREDö, ôSHALLö,
ôSHALL NOTö, ôSHOULDö, SHOULD NOTö, ôRECOMMENDEDö, ôMAYö,
and ôOPTIONALö in this document are to be interpreted as
described in [RFC2119].
2. CONTENT NEGOTIATION
Classic facsimile service is interactive, so that a sending
station can discover the capabilities of the receiving
station, prior to sending a facsimile of a document. This
permits the sender to transmit the best quality of facsimile
that is supported by both the sending station and the
receiving station. Internet mail is store-and-forward, with
potentially long latency, so that before-the-fact
negotiation is problematic.
Use of a negotiation mechanism permits senders to transfer a
richer document form than is permitted when using the safer-
but-universal default form. Without this mechanism, the
sender of a document cannot be certain that the receiving
station will support be able to support the form.
The capabilities that can be negotiated by an FFPIM
participant are specified in [RFC2534, RFC2879].
Implementations that are conformant to FFPIM MUST support
content negotiation as described there.
2.1. UA-based content negotiation
One method of exchanging capabilities information uses a
post-hoc technique that permits an originator to send the
best version known by the originator to be supported by the
recipient and then to send a version that is better suited
to the recipient if the recipient requests it. This
mechanism is specified in [RFC3297]. FFPIM implementations
MUST support this mechanism.
2.2. ESMTP-based content negotiation
Another method uses an ESMTP option specified in [SMTNEG].
It requires support for content negotiation along the entire
path that the email travels. Using this mechanism,
receiving ESMTP servers are able to report capabilities of
the addresses (mailboxes) that they support.
FFPIM participants MAY support this mechanism.
2.3. Interactions between UA and ESMTP negotiation mechanisms
FFPIM participants must ensure that their use of the UA and
ESMTP methods for content negotiation is compatible. For
example, the two mechanisms might consult two different
repositories of capabilities information, and those
repositories might contain different information. Presumably
this means that at least one of the repositories is
inaccurate, so the larger problem is one of correctness,
rather than synchronization.
This specification does not require a particular method of
using the mechanisms together.
3. CONTENT FORMAT
FFPIM allows the transfer of enhanced TIFF data relative to
[RFC2305, RFC2532]. The details for these enhancements are
contained in [TIFFFX]. Implementations that are conformant
to FFPIM SHOULD support TIFF enhancements.
It should also be noted that the content negotiation
mechanism permits a sender to know the full range of content
types that are supported by the recipient. Therefore,
requirements for support of TIFF represent a functional
minimum for FFPIM.
4. SECURITY CONSIDERATIONS
As this document is an extension of [RFC2305] and [RFC2532],
the Security Considerations sections of [RFC2305] and
[RFC2532] applies to this document, including discussion of
PGP and S/MIME use for authentication and privacy.
It appears that the mechanisms added by this specification
do not introduce new security considerations, however the
concerns raised in [RFC2532] are particularly salient for
these new mechanisms.
Use of this specification should occur with particular
attention to the following security concerns:
* Negotiation can be used as a denial of service attack
* Negotiating may lead to the use of an unsafe data format
* Negotiation discloses information and therefore raises
privacy concerns
5. REFERENCES
[RFC2305] Toyoda, K., Ohno, H., Murai, J. and D. Wing,
"A Simple Mode of Facsimile Using Internet Mail",
RFC 2305, March 1998. (Under revision, as draft-
ietf-fax-service-v2.)
[RFC2532] Masinter, L., Wing, D., ôExtended Facsimile Using
Internet Mailö, RFC 2532, March 1999.
[RFC2534] Masinter, L., Holtman, K., Mutz, A. and D. Wing, "
Media Features for Display, Print, and Fax", RFC
2534, March 1999.
[RFC2542] L. Masinter, L, ôTerminology and Goals for
Internet Faxö, RFC2542, March 1999
[RFC2879] McIntyre, L. and G. Klyne, "Content Feature
Schema for Internet Fax", RFC 2531, August 2000
[RFC3297] G. Klyne, R. Iwazaki, D. Crocker, ôContent
Negotiation for Messaging Services based on Email
ô, RFC 3297
[SMTNEG] Toyoda, K., Crocker, D. " SMTP and MIME Extensions
For Content Conversion", draft-ietf-fax-esmtp-
conneg
[T.30] "Procedures for Document Facsimile Transmission in
the General Switched Telephone Network", ITU-T
(CCITT), Recommendation T.30, July, 1996.
[TIFFFX] D. Venable, S. Zilles, L. McIntyre, G. Parsons, J.
Rafferty, R. Buckley, ôFile Format for Internet
Fax ô,draft-ietf-fax-tiff-fx-13.txt
APPENDIX A û DIRECT MODE
Email is a store-and-forward service, typically with delay
between the time a message leaves the sender's realm and the
time it arrives in the receiver's realm. The number of
relays between sender and receiver is also unknown and
variable. By contrast, facsimile is generally perceived as
direct and immediate.
An email profile that fully emulates facsimile must solve
several different problems. One is to ensure that the
document representation semantics are faithful. Another is
that the interaction between sender and receiver is similar
to that of telephony-based facsimile. In particular it must
ensure the timeliness of the interaction. The specifications
for FFPIM and its predecessors create the ability to have
email emulate the information (semantics) activities of
facsimile.
The ESMTP CONNEG option sets the stage for achieving email-
based facsimile transfer that has interactive negotiations
that are on a par with telephony-based facsimile. The key,
additional requirement is to achieve timeliness.
Ultimately, this requires configuring sender and receiving
email servers to interact directly. That is, the sender's
MTA must directly contact the receiver's MTA. With typical
email service configurations, the content and interaction
semantics of facsimile can be emulated quite well, but the
timeliness cannot be assured.
To achieve direct sending, the originating MTA must be
configured to do transmissions to hosts specified in email
addresses, based on DNS queries. To achieve direct
receiving, the target MTAs must have DNS A records without
MX records. That is, they must be configured to use no
intermediaries.
The sender may then use ESMTP Conneg to determine the
capabilities of the receiver. Afterwards the sender will
use the capabilities information to tailor the TIFF message
content that it sends.
APPENDIX B û ACKNOWLEDGEMENTS
The IETF Fax working group has diligently participated in a
multi-year effort to produce Internet-based emulation of
classic facsimile via email profiles, as collaboration
between the IETF and the ITU. The effort benefited from the
group's willingness to provide an initial, minimal
mechanism, and then grow the specification to include more
facsimile features, as implementation and operations
experience was gained.
APPENDIX C û CONTACT
David H. Crocker Tel: +1.408.246.8253
Brandenburg InternetWorking Email:
675 Spruce Dr. dcrocker@brandenburg.com
Sunnyvale, CA 94086 USA
Graham Klyne Email: GK-
Nine by Nine IETF@ninebynine.org
UK http://www.ninebynine.net/
APPENDIX D û FULL COPYRIGHT STATEMENT
Copyright (C) The Internet Society (2001). 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.