One document matched: draft-ietf-fax-implementers-guide-00.txt
Implementers Guide for Facsimile Using Internet Mail
<draft-ietf-fax-implementers-guide-00.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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.
[[INTENDED STATUS: This memo provides information for the Internet
community. It does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.]]
Copyright Notice
Copyright (C) The Internet Society 1999. All Rights Reserved.
Abstract
This document provides guidelines to follow for the implementers of
facsimile communications using Internet Email described in RFCs
listed in the Reference section of this document. References [1-5].
This guidelines do not supersede the referenced documents and its
intention is only to clarify.
Cancio, Moldovan Work-in-progress [Page 1]
Internet draft Implementers Guide 21 October 1999
Table of contents
1. Introduction
1.1 Organization of this document
1.2 Discussion of this document
2. Terminology
3. Implementation Issues for RFC 2305
(Simple Mode of Internet Fax)
3.1 Simple Mode Fax Senders
3.1.1 Multipart-alternative
3.2 Simple Mode Fax Receivers
3.2.1 Multipart-alternative and Storage Capacity
4. Implementation Issues for RFC 2301
(File Format for Internet Fax)
4.1 IFD Placement in TIFF file & Profile-S Constraints
4.2 Precautions for implementers of RFC 2301 [4]
4.2.1 Typical Header Errors
4.2.2 Typical IFD Errors
4.2.3 IFD Entry Errors
4.2.4 Strip Errors
4.2.5 Image Errors
4.2.6 Profile Specific Errors
5. Implementation Issues for Internet Fax Addressing
5.1 Conventional email addresses
5.2 Internet Fax Offramp Addresses Per RFC 2303/3204
6. Implementation Issues for RFC 2532
(Extended Facsimile using Internet Mail)
6.1 Extended Mode Senders
6.1.1 Multipart-alternative
6.1.2 Correlation of MDN with Original Message
6.2.3 Correlation of DSN with Original Message
6.2 Extended Mode Receivers
6.2.1 Multipart-alternative
6.2.2 Confirmation of receipt and processing
6.2.2.1 Discrepancies in MDN [7] Interpretation
6.2.2.2 Extended Mode Receivers which are MTAs
(or ESMTP servers)
6.2.2.3 Extended Mode Receivers which are POP3/IMAP4
7. Known Open Implementation Issues
7.1 Email and Traditional Facsimile Headers
7.2 Simple Mode
7.3 Extended Mode
8. Security considerations
9. Acknowledgements
10. References
11. Authors' addresses
Full copyright statement
Revision history
Cancio, Moldovan Work-in-progress [Page 2]
Internet draft Implementers Guide 21 October 1999
1. Introduction
These guidelines intent to clarifies any potential vagueness that may
exist in the published documents that describe facsimile communications
using Internet Email. The intention is to prevent misinterpretations of
the text and to ensure interoperability and consistency in error
indicators. The series of RFCs in question consist of a simple and an
extended mode of using Internet email protocols to transport facsimile
images; and the file format that envelopes the facsimile image.
1.1 Organization of this document
TBD
1.2. Convention of this document
[[[Editorial comments from authors are embedded in triple brackets
and will be removed before publication]]]
1.2 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/
2. Terminology
Simple Mode - Refers to RFC 2305, "A Simple Mode of Facsimile
Using Internet Mail"
Extended Mode - Refers to RFC 2532, "Extended Facsimile using
Internet Mail"
TIFF-FX - Refers to RFC 2301, "File Format for Internet fax"
3. Implementation Issues for RFC 2305
(A Simple Mode of Facsimile Using Internet Mail)
TBD
Cancio, Moldovan Work-in-progress [Page 3]
Internet draft Implementers Guide 21 October 1999
3.1 Simple Mode Fax Senders
3.1.1 Multipart-alternative
Legacy (old) email client implementations may not be capable of
processing 'multipart-alternative'. If a sender is unsure if the
recipient complies with the MIME requirements, the sender should
assume the worst and not use content-types which have known
problems with such non-compliant implementations. Specifically,
multi-part/alternative SHOULD be avoided in situations where the
recipient is not known to properly support multipart/alternative.
[[[Note: How does a sender's client application know this information?]]]
TBD
3.2 Simple Mode Fax Receivers
3.2.1 Multipart-alternative and Storage Capacity
Devices with little storage capacity are unable to cache previous
parts of a multipart/alternative message. To maintain the required
MIME compliance when receiving multipart/alternative, such devices with
little storage capacity MAY choose to simply use the first processable
part of a multipart/alternative message and ignore subsequent parts
even if they were processable by the device.
[[[Note: Is this a warning? or the MAY is acceptable behaviour?]]]
4. Implementation Issues for RFC 2301 (File Format for Internet Fax)
4.1 IFD Placement in TIFF file & Profile S Constraints
Low memory devices may not be able handle arbitrary placement of TIFF IFDs within a TIFF file, while capable of supporting resolutions higher than that required by Profile-S.
To help the sender adjust to potential recipient's limitation, and bypass the constraints imposed on the resolution by Profile-S, it is strongly recommended to always place the IFD at the beginning of the TIFF-FX file when using any of the Profiles defined in RFC 2301.
4.2 Precautions for implementers of RFC 2301 [4]
Interoperability testing of the File Format for Internet Fax [4] yielded useful information that may help developers avoid the same mistakes.
The following compiled list of TIFF/RFC 2301 [4] errors where encountered during interoperability testing and is provided so that implementers can take precautionary measures.
Cancio, Moldovan Work-in-progress [Page 4]
Internet draft Implementers Guide 21 October 1999
4.2.1 Typical Header Errors
a) The byte order (bytes 0-1 of the Image File Header) may be not equal to
"II"(4949h) or "MM"(4D4Dh). For a TIFF profile this information is
essential.
b) There are some difficulties to generate a TIFF profile with BIGENDIAN
order (bytes 0-1 equal to 4D4Dh). Also the reader may have the
difficulties to read data in this case.
c) The "magic number" (bytes 2-3 of the Image File Header) may not be equal
to 42 (2Ah).
d) The first IFD offset points outside file.
e) The first IFD offset is not on a word boundary.
4.2.2 Typical IFD Errors
a) Second or third IFD offset points outside file.
b) IFDs are overlapped with another TIFF profile data (e.g. strip image data
or header data).
c) Readers have difficulties to handle different kinds of TIFF profiles with
the following IFD position: IFD at the end of the profile, IFD
intercalated with another IFD data (XResolution, DateTime, strip image
data).
d) If the profile has child IFDs, there is a high probability that readers
will have trouble accessing all the child IFDs (e.g. some application do
not recognize the GlobalParametersIFD; for a M profile with many child
IFDs, these IFDs may be chained to the next IFD offsets or may be pointed
by the data of from the SubIFD entry).
4.2.3 IFD Entry Errors
a) Some required entries do not exist and this makes impossible to read the
image data.
b) Some tags may have two types of data (for example SHORT or LONG).
c) Some tags may have a wrong type of data (for example RATIONAL instead of
SRATIONAL. Also the count of type may be wrong for a specified tag.
d) The count of type may be wrong (null or a value not that does not match
the tag ID)
e) Tags that appear in a wrong order in the IFD (not in ascending order).
f) Tags as PageNumber or ImageLayer may have values that do not match the
number of IFDs or the image data. The same thing for the tags from IFDs
with global parameters.
g) The uniqueness of tags inside of IFD is another condition that is not
always respected. In this case the reader may have the difficulties to
determine the real value needed to read and display the image.
4.2.4 Strip Errors
a) Strip data is overlapped with another file data.
b) Strips may be located wherever in the file so sometimes it is difficult
to access this image data.
c) The strip offset points outside file
d) The strip length is null or strip offset + strip length points outside
file
e) There are two bit orders for storing
Cancio, Moldovan Work-in-progress [Page 5]
Internet draft Implementers Guide 21 October 1999
4.2.5 Image Errors
a) Often there is a difference between the type of image and the data from
the strip data. (E.g. in case of a B&W image, the
PhotometricInterpretation tag value is 0 (bit 0 means white) and the
image will appear inverted).
b) For the special color spaces (ITULAB, YCBCR, CMYK) the parameters used
for transformations are sometimes incorrect and not compliant to the
specification.
c) The tag values for XPosition and YPosition are sometimes bad
4.2.6 Profile Specific Errors
a) Invalid combination of tag values. E.g. the combination between the
values of XResolution, YResolution and ImageWidth . The same thing for
Compression, PhotometricInterpretation, SamplesPerPixel, and
BitsPerSample.
b) For Profile M the compression used for the layers may be incorrect. For
example the Mask layer may not be compressed with a black and white
compression and the Background and Foreground layer may be not compressed
with a color compression
5. Implementation Issues for Internet Fax Addressing
5.1 Conventional email addresses
TBD
5.2 Internet Fax Offramp Addresses Per RFC 2303/3204
TBD
[[[Note: Status codes to use in MDN or DSN?
a) Sender not authorized to used of offramp?
b) Error in phone number - fatal or temporary, etc?]]]
6. Implementation Issues for RFC 2532
(Extended Facsimile using Internet Mail)
6.1 Extended Mode Senders
6.1.1 Multipart-alternative
Same as Section 3.1.1.
6.1.2 Correlation of MDN with Original Message
If the sending client application requests a MDN, it SHOULD generate
and insert a unique Message_ID in the header. A Message_ID generated
by the client is not altered by successive MTAs in the path, and
subsequently it can be used to correlate the received MDN with the
original message.
Cancio, Moldovan Work-in-progress [Page 6]
Internet draft Implementers Guide 21 October 1999
6.1.3 Correlation of DSN with Original Message
If the ESMTP sender requests a DSN, it SHOULD use the ENVID parameter in
"MAIl FROM: command in order to correlate the received DSN with the
original message. RFC 1891 Sections 3 and 5.4.
6.2 Extended Mode Receivers
6.2.1 Multipart-alternative and Storage Capacity
Same as Section 3.2.1
6.2.2 Confirmation of receipt and processing
Confirmation or feedback from the receiver, that the facsimile image
(TIFF attachment) was delivered and successfully processed is an
important aspect of the extended mode of facsimile using Internet mail.
Implementers of the Extended Mode [3] should provide consistency in
the feedback provided to senders in the form of error codes and/or failure/successful messages.
6.2.2.1 Discrepancies in MDN [7] Interpretation
The value of receiving an acknowledgement of 'processability' from
a Extended Mode recipient is the success or failure to process the
TIFF file attachment. The attachment constitutes the facsimile
message and not the body-content of the message. Therefore a
Extended Mode sender would expect, and it is recommended, that the
Extended Mode receiver responds with a MDN to indicates the success
or failure to decode and process the TIFF-FX file attachment.
An Extended Mode sender must be aware that RFC 2298 [7] does not make
this distinction and consequently MDNs may be received which do not
associate the feedback information to the attached TIFF-FX file but
to the body-content part of the message.
In the future, new reply codes for DSN and MDN may be created to
clearly communicate the distinction between acknowledging the
body-content of the message and the attachment to the message.
6.2.2.2 Extended Mode Receivers which are MTAs (or ESMTP servers)
For this case, RFC 2532 strongly encourages and this guidelines
strongly recommends the implementation of RFC 2034 [5], "SMTP Service
Extension for Returning Enhanced Error Codes". It is easy to implement
and allows detailed errors to be returned to the sender if the ESMTP
server replies to any command (MAIL FROM, RCPT TO , ".", etc.) with an
error code.
Cancio, Moldovan Work-in-progress [Page 7]
Internet draft Implementers Guide 21 October 1999
a) After receiver determines that attachment was process-able a
Positive Completion reply is returned: Action: Delivered (Successful)
b) Receiver determines that attachment was not process-able:
- A Positive Completion [RFC 821] reply is returned to MTA
(Reply Code 250 after receiving CRLF+, CRLF). Action: Failed
- A DSN is generated and returned with Enhanced Error Code: Status 5.6.1
[[[ Another status code may be possible?
X.6.0 Other undefined Media error
X.6.1 Media not supported
X.6.2 Conversion required but not supported
X.6.3 Conversion with loss performed
X.6.4 Conversion with loss performed
X.6.5 Conversion failed
Any Diagnostic-Codes?
]]]
c) Receiver determines that attachment was not process-able
before complete message is received:
- A Permanent Negative Completion [RFC 821] reply is returned
to MTA (Reply Code 554 after receiving CRLF+, CRLF).
- The submitting MTA generates the DSN
d) Same as c) but both the receiver and the submitting MTA support
RFC 2034 [5]
- A Permanent Negative Completion [RFC 821] reply is returned
to submitting MTA (Reply Code 554 5.6.1 xxxx after receiving
CRLF+, CRLF).
- The submitting MTA generates the DSN as follows:
Action: Failed
Diagnostic-Code: smtp; 554 xxxxx
Status: 5.6.1
[[[Needs more discussion]]]
6.2.2.3 Extended Mode Receivers which are POP3/IMAP4
After receiver determines that attachment was process-able it
may respond with:
disposition-type = "displayed", "dispatched", or "processed"
a) For embedded devices or software mail clients which are
RFC 2532 compliant recipients, the following response MAY
apply to the TIFF-FX attachment itself: "dispatched" or
"processed".
[[[Note: Can we advise "processed"]]]
b) For embedded devices or software mail clients which are
RFC 2532 compliant recipients, the following response MAY
apply to the body-content itself: "dispatched" or "processed".
[[[Note: Can we advise "dispatched"]]]
Cancio, Moldovan Work-in-progress [Page 8]
Internet draft Implementers Guide 21 October 1999
c) For software mail clients the following response generally
RFC 2532 compliant recipients, the following response MAY
applies to the body-content itself:
"displayed", "dispatched" or "processed".
[[[Note: Can we resolve ambiguity?]]]
d) Use of Decode-Error or Warning
disposition-type = "processed" or "displayed"
dissipation-modifier = "error" or "warning"
Error: XXX-Error happened
or
Warning: XXX happened
For embedded devices: "processed/error" or "processed/warning"
For software mail clients: "displayed/error" or "displayed/warning"
[[[Note: Not decided clearly]]]
7. Known Open Implementation Issues
7.1 Email and Traditional Facsimile Headers
In reference to the TIFF Encoded images generated in the general case where the end to end transmission is all Internet mail and there is no onramp or offramp to the GSTN.
Should senders rasterize the classic time/date, page number or CSID data into the TIFF page image before the SMTP transmission to preserve the "look and feel" and general end user expectations of what a "fax" looks like?
7.2 Simple Mode
TBD
7.3 Extended Mode
TBD
8. Security considerations
TBD
9. Acknowledgements
The authors gratefully acknowledge the following persons who
contributed or made comments on earlier versions of this memo:
Hiroshi Tamura, Ryuji Iwazaki, Graham Klyne, Dan Wing, and James Rafferty.
Cancio, Moldovan Work-in-progress [Page 9]
Internet draft Implementers Guide 21 October 1999
10. References
[1] RFC 2542, "Terminology and Goals for Internet Fax"
Larry Masinter, Xerox Corporation
March 1999.
[2] RFC 2305, "A Simple Mode of Facsimile Using Internet Mail"
Toyoda, K., Ohno, H., Murai, J. and D. Wing
March 1998.
[3] RFC 2532, "Extended Facsimile Using Internet Mail"
Larry Masinter, Xerox Corporation
Dan Wing, Cisco Systems
March 1999.
[4] RFC 2301 "File Format for Internet Fax", McIntyre, L., Zilles,
S., Buckley, R., Venable, D., Parsons, G. and J. Rafferty,
March 1998.
[5] RFC 2034 "SMTP Service Extension for Returning Enhanced Error
Codes", N. Freed,
October 1996
[6] RFC 1893 "Enhanced Mail System Status Codes", Vaudreuil, G.,
January 1996
[7] RFC 2298 "An Extensible Message Format for Message Disposition
Notifications", Fajman, R.
March 1998
11. Authors' addresses
Vivian Cancio
Xerox Corporation
Mailstop PAHV-211
3400 Hillview Ave.
Palo Alto, CA 94304 USA
Telephone: +1-650-813-7591
Facsimile: +1-650-845-2341
E-mail: Vivian.Cancio@pahv.xerox.com
Mike Moldovan
G3 Nova Technology, Inc.
2794 Queens Way
Thousand Oaks, CA 91362 USA
Telephone: +1-805-245-4625
Facsimile: +1-805-245-4214
E-mail: mmoldovan@g3nova.com
Cancio, Moldovan Work-in-progress [Page 10]
Internet draft Implementers Guide 21 October 1999
Full copyright statement
Copyright (C) The Internet Society 1999. 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.
Revision history
[[[RFC editor: Please remove this section on publication]]]
| PAFTECH AB 2003-2026 | 2026-04-23 15:08:31 |