Network Working Group D. Crocker, Brandenburg InternetWorking
G. Klyne, Content Technologies
L. Masinter, Xerox
Expiration <9/2001> And others
March 2, 200110/21/99 7:20 AM
Full-mode Fax Profile for Internet Mail: FFPIM
draft-ietf-fax-ffpim-01.txt
Status Of This Memo
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. The list of
Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This document and related documents are discussed on the
IETF Fax mailing list. To join the list, send mail to ietf-
fax-request@imc.org. To contribute to the discussion, send
mail to ietf-fax@imc.org. The archives are at
http://www.imc.org/ietf-fax. The Fax working group charter,
including the current list of group documents, can be found
at http://www.ietf.org/html.charters/fax-charter.html.
Table Of Contents
1. Introduction
2. Content Negotiation
3. Timely Delivery
4. Content Format
5. Security Considerations
6. Acknowledgments
6. Full Copyright Statement
7. Contact
Abstract
Classic facsimile document exchange represents both a set of
technical specifications [T30] and a class of service.
Previous work [RFC2305, RFC2532] 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, timeliness 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 existing and future standards-compliant email
infrastructure and mail user agents, while providing a level
of service that approximates the level 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 (2001). All Rights
Reserved.
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,
timeliness 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 existing and future standards-
compliant email infrastructure and mail user agents, while
providing a level of service that approximates the level
currently enjoyed by fax users.
The new features are designed to be interoperable with the
existing base of mail transfer agents (MTAs) and mail user
agents (MUAs), and take advantage of existing standards for
advanced functionality such as positive delivery
confirmation and disposition notification. The 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.
This specification therefore 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 better version if the recipient requests it.
The specification for this technique is in [CONNEG].
Implementations that are conformant to FFPIM MUST support
content negotiation.
[[[ A concern has been expressed that CONNEG does not
support the full range of fax features. The working
group needs to resolve a) whether there are functional
requirements for complete emulation of fax services
that are not satisfied by the above specification, and
b) what changes are necessary, if the answer to
question a) is æyesÆ. /editor]]]
2.1. ESMTP-based content negotiation
SMTP servers that are able to report capabilities of the
addresses (mailboxes) which they support MAY use the ESMTP
ôCONNEGö option. This allows them to report capabilities of
the receiving station as part of the ESMTP RCTP-TO
interaction.
[[[ This section is intended to assist in the operation
of ôdirectö FFPIM interactions. We need to develop
specifications for the ESMTP ôCONNEGö option. /editor
]]]
3. Timely Disposition
Internet mail is often reliable and speedy. However it
displays a very wide range of variability, depending upon
details such as software implementation, systems operation,
network connectivity and network activity. By contrast,
facsimile systems typically suffer only the fixed delay of
telephone call setup time. The T.30 fax standard includes a
required delivery confirmation; so the sender gets an
immediate, unambiguous report on the status of a
transmission and, possibly, printing. Internet mail
standards include methods of reporting confirmation, but
these are not always supported.
This specification uses a set of capabilities that permits
an originator to request that the email transport system
seek a particular timeliness in delivery and then assures
that the system will report the success or failure of that
request.
The specification for this technique is in [TIMELY].
Implementations that are conformant to FFPIM MUST support
timely disposition.
[[[ A question has been raised about alternative
confirmation behaviors. The working group needs to
resolve a) whether there are functional requirements
for complete emulation of fax services that are not
satisfied by the above specification, and b) what
changes are necessary, if the answer to question a) is
æyesÆ. /editor]]]
[[[ The editor believes that the features provided by
the TIMELY mechanisms EXCEED the related services
provided by the T.30 fax world. /d ]]]
4. Content Format
Support for enhancements to TIFF are included in this
specification. The details for these enhancements are
contained in [TIFF]. Implementations that are conformant to
FFPIM MUST support TIFF enhancements.
[[[ A question has been raised about alternative
confirmation behaviors. The working group needs to
resolve a) whether there are functional requirements
for complete emulation of fax services that are not
satisfied by the above specification, and b) what
changes are necessary, if the answer to question a) is
æyesÆ. /editor ]]]
[[[ The editor suspects that the features provided by
the TIFF specification meets or exceeds the related
services provided by the T.30 fax world. /d ]]]
5. 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.
6. Acknowledgements
[[[ to be done /editor ]]]
7. References
[TIMELY] G. Klyne, et al, draft-ietf-fax-timely-00.txt
[CONNEG] G. Klyne, R. Iwazaki, D. Crocker, ôContent
Negotiation for Facsimile Using Internet Mail ô, draft-ietf-
fax-content-negotiation-00.txt
[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-
02.txt.
[T.30] "Procedures for Document Facsimile Transmission in
the General Switched Telephone Network", ITU-T (CCITT),
Recommendation T.30, July, 1996.
[TIFF] D. Venable, S. Zilles, L. McIntyre, G. Parsons, J.
Rafferty, ôFile Format for Internet Fax ô, draft-ietf-fax-
tiff-fx-06.txt R. Buckley
6. 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.
4. 7. Contact
David H. Crocker Tel: +1.408.246.8253
Brandenburg InternetWorking Fax: +1.408.249.6205
675 Spruce Dr. Email:
Sunnyvale, CA 94086 USA dcrocker@brandenburg.com
Graham Klyne (editor) Tel: +44 118 930 1300
Content Technologies Ltd. Fax: +44 118 930 1301
1220 Parkview, Arlington Email: GK@ACM.ORG
Business Park
Theale, Reading, RG7 4SA, UK
Larry Masinter Tel: +1 650 à
Adobe Systems Fax: +1 650 à
à USA Email: masinter@adobe.com
5. Appendix A û Direct Mode
[[[ Desire to have an FFPIM sender communicate with an FFPIM
receiver directly, so that there are no SMTP (or other)
intermediaries does not require changes to the standard,
except for the addition of the ESMTP CONNEG option. The
remaining features of this mode can be achieved through
proper configuration and operation. A section needs to be
written to explain how system administrators can achieve
this mode. /editor. ]]