One document matched: draft-ietf-fax-implementers-guide-03.txt
Differences from draft-ietf-fax-implementers-guide-02.txt
IETF Fax Working Group Vivian Cancio
Internet Draft Xerox Corporation
Category: Work-in-progress Mike Moldovan
Intended Category: Informational G3Nova Technology, Inc.
Hiroshi Tamura
Ricoh Company, LTD.
Dan Wing
Cisco Systems
21 September 2000
Expires: March 2001
Implementers Guide for Facsimile Using Internet Mail
<draft-ietf-fax-implementers-guide-03.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 is intended for the implementers of software which uses email
to send to facsimiles using RFC 2305 and 2532.
This is an informational document and its guidelines do not supersede the
referenced documents.
Cancio, Moldovan, Tamura, Wing Work-in-progress [Page 1]
Internet draft Implementers Guide 21 September 2000
Table of contents
1. Introduction
1.1 Organization of this document
1.2 Convention of this document
1.3 Discussion of this document
2. Terminology
3. Implementation Issues Specific to Simple Mode
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 Specific to Extended Mode
4.1 Multipart-alternative
4.2 Correlation of MDN with Original Message
4.3 Correlation of DSN with Original Message
4.4 Extended Mode Receivers
4.4.1 Confirmation of receipt and processing from UA Clients
4.4.1.1 Discrepancies in MDN [9] Interpretation
4.4.1.2 Disposition-Type: "dispatched"
4.4.1.3 "Subject" of MDN in Success and Failure Cases
4.4.1.4 "Body" of MDN in Success and Failure Cases
4.4.2 Extended Mode Receivers that are MTAs (or ESMTP servers)
4.4.2.1 Success Case Example
4.4.2.2 Failure Case Example 1
4.4.2.3 Failure Case Example 2
4.4.3 Extended Mode Receivers that are POP3/IMAP4
4.4.3.1 Success Case Example
4.4.3.2 Failure Case Example
4.4.4 Receiving Multiple TIFF-FX Attachments
5. Implementation Issues the File Format
5.1 IFD Placement in TIFF file & Profile-S Constraints
5.2 Precautions for implementers of RFC 2301 [4]
5.2.1 TIFF Readers: Be Cautious with Headers
5.2.2 TIFF Writers: Be Cautious in use of IFD
5.2.3 IFD Entry Errors
5.2.4 Strip Errors
5.2.5 Image Errors
5.2.6 Profile Specific Errors
6. Implementation Issues for Internet Fax Addressing
7. Security considerations
8. Acknowledgements
9. References
10. Authors' addresses
Full copyright statement
Revision history
Cancio, Moldovan, Tamura, Wing Work-in-progress [Page 2]
Internet draft Implementers Guide 21 September 2000
1. Introduction
This document clarifies published RFCs which standardize facsimile
communications using Internet Email. The intent is to prevent implementations
that deviate in such a way as to cause interoperability problems.
1.1 Organization of this document
See Section 2 for terminology.
a) Simple mode clarifications
b) Extended mode clarifications
c) File format clarifications
d) Fax Addressing Clarifications
e) Open implementation issues
1.2. Convention of this document
[[[Editorial comments from authors are embedded in triple brackets
and will be removed before publication]]]
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/
2. Terminology
Simple Mode - RFC 2305, "A Simple Mode of Facsimile Using Internet Mail" [2]
Extended Mode - RFC 2532, "Extended Facsimile Using Internet Mail" [3]
TIFF-FX - RFC 2301, "File Format for Internet Fax" [4]
UA - User Agent
DSN - Delivery Status Notification [7]
MDN - Message Disposition Notification [9]
In examples: - "C:" is used to indicates lines sent by the client, and
"S:" to indicate those sent by the server.
MTA - Message Transfer Agent
Cancio, Moldovan, Tamura, Wing Work-in-progress [Page 3]
Internet draft Implementers Guide 21 September 2000
3. Implementation Issues Specific to Simple Mode
3.1 Simple Mode Fax Senders
3.1.1 Multipart/alternative
Although a requirement of MIME compliance (see RFC 2046, Section 5.1.4), some
email client implementations are not capable of correctly processing messages
with a MIME Content-Type of "multipart/alternative". If a sender is unsure if
the recipient is able to correctly process a message with a Content-Type of
"multipart/alternative", the sender should assume the worst and not use this
MIME Content-Type.
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. In order for such devices to correctly process
only one part of a multipart/alternative message, such devices may simply use
the first process-able part of a multipart/alternative message. This is viable
because the parts within a multipart/alternative are always sent in least-
fidelity to most-fidelity order.
This behavior means that even if subsequent, higher-fidelity parts may have been
process-able they will not be used.
This behavior can cause user dissatisfaction because when two high-fidelity
but low-memory devices are used with each other, the lowest-fidelity part of
the multipart/alternative will be processed.
The solution to this problem is for the sender to determine the capability of
the recipient and send only high fidelity. However a mechanism to determine the
recipient capabilities priorto an initial message sent to the recipient doesn't
yet exist on the Internet.
After an initial message is sent, the Extended Mode mechanism described in RFC
2532 [3], Section 3.3 enables a recipient to include its capabilities in a
delivery and/or a disposition notification: in a DSN if the recipient device is
an RFC 2532/ESMTP [3] compliant server or in an MDN if the recipient is only an
UA.
Cancio, Moldovan, Tamura, Wing Work-in-progress [Page 4]
Internet draft Implementers Guide 21 September 2000
4. Implementation Issues Specific to Extended Mode
4.1 Multipart/Alternative
Sections 3.1.1 and 3.2.1 are also applicable to this mode.
4.2. Correlation of MDN with Original Message
To re-iterate a paragraph from section 2.1, RFC 2298 [9], it is
included here:
A message that contains a Disposition-Notification-To header SHOULD
also contain a Message-ID header as specified in RFC 822 [10]. This
will permit automatic correlation of MDNs with original messages by
user agents.
4.3 Correlation of DSN with Original Message
Similar to the requirement to correlate an MDN, above, DSNs also need to be
correlated. This is best done using the ENVID parameter in the "MAIL"
command. See Sections 3 and 5.4 of RFC 1891 [5] for details.
4.4 Extended Mode Receivers
Confirmation that the facsimile image (TIFF-FX attachment) was delivered and
successfully processed is an important aspect of the extended mode of facsimile
using Internet mail.
4.4.1 Confirmation of receipt and processing from UA Clients
When a message is received with the "Disposition-Notification-To" header and the
receiver has determined if the message is process-able, it may generate a:
a) Negative MDN in case of error, or
b) Positive MDN if requested by the sender.
The advantage of receiving a requested MDN acknowledgement from an Extended Mode
recipient is the indication of success or failure to process the TIFF-FX file
attachment that was sent. The attachment constitutes the facsimile message and
not the body-content of the message. Therefore an Extended Mode sender would
expect, and it is recommended that the Extended Mode receiver will acknowledge
(with an MDN) the success or failure to decode and process the TIFF file
attachment.
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.
Cancio, Moldovan, Tamura, Wing Work-in-progress [Page 5]
Internet draft Implementers Guide 21 September 2000
4.4.1.1 Discrepancies in MDN [9] Interpretation
An Extended Mode sender must be aware that RFC 2298 [9] does not make a
distinction between the success or failure to decode the body-content part of
the message, from the success or failure to decode a file attachment.
Consequently MDNs may be received which do not reflect the success or failure to
decode the attached TIFF-FX file, but rather to decode the body-content part of
the message.
4.4.1.2 Disposition-Type: "dispatched".
The receiver of an MDN request, if it is also an a RFC 2532 compliant device
that automatically prints the received Internet mail messages and attachments,
or forwards the attachment via GSTN fax, should respond with a "disposition-
type: dispatched" when the received message is successfully processed. This
recommendation adheres to the definition in RFC 2298 [9] and helps to
distinguish the returned MDNs for proper handling.
4.4.1.3 "Subject" of MDN in Success and Failure Cases
Because legacy e-mail applications do not parse the machine-readable headers, e-
mail users depend on the human-readable parts of the MDN to recognize the type
of acknowledgement that is received. For the sake of consistency and to help
users visually distinguish a DSN from an MDN returned notification, it is
suggested that the text 'disposition' be used for MDNs in the 'Subject' field.
Example:
Subject: Disposition Notification (MDN) - Successful or
Subject: Disposition Notification (MDN) û Failure
4.4.1.4 "Body" of MDN in Success and Failure Cases
If the receiver of an MDN request is also an RFC 2532 [3] compliant device that
automatically prints the received Internet mail messages and attachments, or
forwards the attachment via GSTN fax, for consistency the following text is
suggested for the body of the message.
In case of success:
"This is a Return Receipt for the mail that you sent to [above, or below, or
here address, etc]. The message and attached file[s] may have been printed,
faxed or saved. This is no guarantee that the message has been read or
understood".
In case if failure:
"This is a Return Receipt for the mail that you sent to [above, or below, or
here address, etc]. An error occurred while attempting to decode the attached
file[s].
[[[Include details on error; and maybe recognize language (of sender) in headers
to send above text in appropriate language. From D.W.]]]
Cancio, Moldovan, Tamura, Wing Work-in-progress [Page 6]
Internet draft Implementers Guide 21 September 2000
4.4.2 Extended Mode Receivers that are MTAs (or ESMTP servers)
It is strongly encouraged that SMTP server-based implementations should
implement "SMTP Service Extension for Returning Enhanced Error Codes" [6]. This
standard is easy to implement and it allows detailed standardized success and
error indications to be returned to the sender by the submitting MTA.
The following examples are provided as illustration only. They should not be
interpreted as limiting the protocol or the DSN form. If the examples conflict
with the definitions in the standards (RFC 1891/1893/1894/2034), the standards
take precedence and the examples in this documents should not be used.
4.4.2.1 Success Case Example
In the following example the sender <jean@water.line.com> sends a message to
receiver <ifax@copper.point.com> which is an ESMTP server and the receiver
successfully decodes the message.
SMTP Sequence:
S: 220 copper.point.com SMTP service ready
C: EHLO water.line.com
S: 250-copper.point.com
S: 250-DSN
S: 250 ENHANCEDSTATUSCODES
C: MAIL FROM:<jean@water.line.com> RET=HDRS ENVID=MM123456
S: 250 2.1.0 Originator <jean@water.line.com> ok
C: RCPT TO:<ifax@copper.point.com> NOTIFY=SUCCESS,FAILURE ORCPT=rfc822;
ifax@copper.point.com
S: 250 2.1.5 Recipient <ifax@copper.point.com> ok
C: DATA
S: 354 Send message, ending in <CRLF>.<CRLF>
...
...[[[Replace 'dots' with actual data. From D.W.]]]
...
...
S: 250 2.0.0 Message accepted
C: QUIT
S: 221 2.0.0 Goodbye
Cancio, Moldovan, Tamura, Wing Work-in-progress [Page 7]
Internet draft Implementers Guide 21 September 2000
DSN (to jean@water.line.com):
Date: Mon, 12 Dec 1999 19:01:57 +0900
From: postmaster@copper.point.com
Message-ID: <19991212190157.01234@copper.point.com>
To: jean@water.line.com
Subject: Delivery Notification (DSN)
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary=JUK199912121854870001
--JUK199912121854870001
Content-type: text/plain;
Your message (id MM123456) was successfully delivered to
ifax@copper.point.com.
--JUK199912121854870001
Content-type: message/delivery-status
Reporting-MTA: dns; copper.point.com
Original-Envelope-ID: MM123456
Final-Recipient: rfc822;ifax@copper.point.com
Action: delivered
Status: 2.1.5 (Destination address valid)
Diagnostic-Code: smtp; 250 2.1.5 Recipient <ifax@copper.point.com> ok
--JUK199912121854870001
Content-type: message/rfc822
(headers of returned message go here)
[[[Replace with actual header data. From D.W.]]]
--JUK199912121854870001--
Cancio, Moldovan, Tamura, Wing Work-in-progress [Page 8]
Internet draft Implementers Guide 21 September 2000
4.4.2.2 Failure Case Example 1
In this example the receiver determines it is unable to decode the attached TIFF
file AFTER it has received the SMTP message. The receiver then sends a 'failure'
DSN.
SMTP Sequence:
This is the same as the case a). After the sequence, a decode error occurs at
the receiver, so instead of a 'success' DSN, a 'failure' DSN is sent.
DSN(to jean@water.line.com):
Date: Mon, 12 Dec 1999 19:31:20 +0900
From: postmaster@copper.point.com
Message-ID: <19991212193120.87652@copper.point.com>
To: jean@water.line.com
Subject: Delivery Notification (DSN) - Failure
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary=JUK199912121934240002
--JUK199912121934240002
Content-type: text/plain;
Your message (id MM123456) to ifax@copper.point.com resulted in an error
in attempt to decode the attached file.
--JUK199912121934240002
Content-type: message/delivery-status
Reporting-MTA: dns; copper.point.com
Original-Envelope-ID: MM123456
Final-Recipient: rfc822;ifax@copper.point.com
Action: Failed
Status: 5.6.1 (Media not supported)
Diagnostic-Code: smtp; 554 5.6.1 Decode error
--JUK199912121934240002
Content-type: message/rfc822
(headers of returned message go here)
[[[Replace with actual header data. From D.W.]]]
--JUK199912121934240002--
Cancio, Moldovan, Tamura, Wing Work-in-progress [Page 9]
Internet draft Implementers Guide 21 September 2000
4.4.2.3 Failure Case Example 2
In this example the receiver determines it is unable to decode the attached TIFF
file BEFORE it accepts the SMTP transmission. [[[It should be noted that the
results could be the same if instead the receiver could not decode the 'body
content' of the message. D.W. & V.C.]]]
SMTP sequence:
S: 220 copper.point.com SMTP service ready
C: EHLO water.line.com
S: 250-copper.point.com
S: 250-DSN
S: 250 ENHANCEDSTATUSCODES
C: MAIL FROM:<jean@water.line.com> RET=HDRS ENVID=MM123456
S: 250 2.1.0 Originator <jean@water.line.com> ok
C: RCPT TO:<ifax@copper.point.com> NOTIFY=SUCCESS,FAILURE ORCPT=rfc822;
ifax@copper.point.com
S: 250 2.1.5 Recipient <ifax@copper.point.com> ok
C: DATA
S: 354 Send message, ending in <CRLF>.<CRLF>
...
... (the attached file cannot be decoded by receiver)
... [[[Replace 'dots' with actual data. From D.W.]]]
...
C: .
S: 554 5.6.1 Media not supported
C: QUIT
S: 221 2.0.0 Goodbye
DSN:
Note: In this case, the previous MTA generates the DSN that is forwarded to
the original sender. The receiving MTA has not accepted delivery and therefore
can not generate a DSN.
4.4.3 Extended Mode Receivers that are POP3/IMAP4
NOTE: There are no new definitions here in this document. The definitions
of disposition-types and disposition-modifiers are defined in
RFC 2298[9]. This section provides examples on how POP3/IMAP4 devices
may use the already defined values.
Cancio, Moldovan, Tamura, Wing Work-in-progress [Page 10]
Internet draft Implementers Guide 21 September 2000
These examples are provided as illustration only. They should not be interpreted
as limiting the protocol or the MDN form. If the examples conflict with the
definitions in the MDN [9] standard, the standard takes precedence and the
examples in this documents should not be used.
4.4.3.1 Success Case Example
If the original sender receives an MDNs which has "displayed", "dispatched" or
"processed" disposition-type without disposition-modifier, the receiver may have
possibly received or decoded the attached TIFF-FX file that it sent. It does not
guarantee that the receiver displays, prints or saves the attached TIFF-FX file
See Section 4.4.1.1, Discrepancies in MDN Interpretation.
NOTE: This example does not include the third component of the MDN.
Date: 14 Dec 1999 17:48:44 +0900
From: ken_recipient@bronze.dot.com
Message-ID: <19991214174844.98765@silver.dot.com>
Subject: Disposition Notification (MDN)
To: mary@silver.dot.com
Mime-Version: 1.0
Content-Type: multipart/report; report-type=disposition-notification;
boundary="61FD1001_IFAX"
--61FD1001_IFAX
Content-Type: text/plain
This is a Return Receipt for the mail that you sent to
"ken_recipient@bronze.dot.com". The message and attached files may
have been printed, faxed or saved. This is no guarantee that the
message has been read or understood.
--61FD1001_IFAX
Content-Type: message/disposition-notification
Reporting-UA: ken-ifax.bronze.dot.com; barmail 1999.10
Original-Recipient: rfc822;ken_recipient@bronze.dot.com
Final-Recipient: rfc822;ken_recipient@bronze.dot.com
Original-Message-ID: <19991214174010O.mary@silver.dot.com>
Disposition: automatic-action/MDN-send-automatically; dispatched
--61FD1001_IFAX--
Cancio, Moldovan, Tamura, Wing Work-in-progress [Page 11]
Internet draft Implementers Guide 21 September 2000
4.4.3.2 Failure Case Example
If the original sender receives an MDN with an "error" or "warning"
disposition-modifier, it is possible that the receiver could not receive or
decode the attached TIFF-FX file. Currently there is no mechanism to associate
the disposition-type with the handling of the main content body of the message
or the attached TIFF-FX file.
Date: 14 Dec 1999 19:48:44 +0900
From: ken_recipient@bronze.dot.com
Message-ID: <19991214194844.67325@silver.dot.com>
Subject: Disposition Notification (MDN)
To: mary@silver.dot.com
Mime-Version: 1.0
Content-Type: multipart/report; report-type=disposition-notification;
boundary="84FD1011_IFAX"
--84FD1011_IFAX
Content-Type: text/plain
This is a Return Receipt for the mail that you sent to
"ken_recipient@bronze.dot.com". A decoding error occurred
in the attached file.
--84FD1011_IFAX
Content-Type: message/disposition-notification
Reporting-UA: ken-ifax.bronze.dot.com; barmail 1999.10
Original-Recipient: rfc822;ken_recipient@bronze.dot.com
Final-Recipient: rfc822;ken_recipient@bronze.dot.com
Original-Message-ID: <199912141823123.mary@silver.dot.com>
Disposition: automatic-action/MDN-send-automatically; processed/error
--84FD1011_IFAX
Content-Type: message/rfc822
[original message goes here]
--84FD1011_IFAX--
Cancio, Moldovan, Tamura, Wing Work-in-progress [Page 12]
Internet draft Implementers Guide 21 September 2000
4.4.4 Receiving Multiple TIFF-FX Attachments
A received email message could contain multiple TIFF-FX attachments and each
distinct TIFF-FX file may use different encoding and/or resolution. A received
email message could include TIFF-FX attachment and non-TIFF-FX attachments.
There is currently no mechanism to identify, in a returned notification, the
attachments that were successfully decoded from those that could not be decoded.
If the Extended Mode recipient is unable to decode any of the attached files, it
is recommended that the Extended Mode recipient return a decoding error.
5. Implementation Issues Specific to the File Format
5.1 IFD Placement in TIFF file & Profile S Constraints
Low memory devices, which support resolutions greater than the
required Profile-S, may be memory-constrained such that those
devices cannot properly handle arbitrary placement of TIFF IFDs
within a TIFF file.
To interoperate with a receiver that is constrained, it is strongly
recommended that senders always place the IFD at the beginning of
the TIFF-FX file when using any of the Profiles defined in RFC 2301.
5.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
were encountered during interoperability testing and is provided so
that implementers of TIFF readers and writers can take precautionary
measures.
a) Although Profile S of TIFF-FX [4] specifies that files should
be in little-endian order, during testing it was found that
some common TIFF writers create big-endian files. If possible,
the TIFF reader should be coded to handle big-endian files.
TIFF writers should always create little-endian files to be
compliant with the standard and to allow interoperation with
memory-constrained devices;
b) Bytes 0-1 of the Image File Header are supposed to be set to "II"
(4949h) or "MM" (4d4dh) to indicate the byte order. During
testing, other values were encountered. Readers should be coded
to exit gracefully if the byte order field contain values other
than "II" or "MM", and writers should ensure the correct value
is used;
Cancio, Moldovan, Tamura, Wing Work-in-progress [Page 13]
Internet draft Implementers Guide 21 September 2000
c) Bytes 2-3 of the Image File Header are the "magic number" and are
supposed to be equal to 42 (2Ah). Readers should be coded to exit
gracefully if the magic number is a different value, and writers
should ensure the correct value is used;
d) Readers should be coded to correctly handle the first and
subsequent IFD offsets do not point beyond the end of the
TIFF-FX file, and writers should not point the IFD offset
beyond the end of the file;
e) Readers should be coded to handle the first IFD offset being on a
non-word boundary, and writers should create the first IFD offset
on a word boundary;
f) Readers and writers should be careful to correctly handle IFDs
with other TIFF profile data such as strip image data and
header data.
g) Some readers have difficulties with IFDs in certain locations.
If possible, such reader implementations should be corrected
and TIFF writers should take extra precautions to not place
IFDs in these positions: IFD at the end of the profile, IFD
intercalated with another IFD data like XResolution, DateTime,
or strip image data.
h) Some readers do not support child IFDs. Child IFDs should
not be created by TIFF writers.
i) Some readers do not recognize the GlobalParametersIFD. The
GlobalParametersIFD should not be created by TIFF writers.
5.2.3 IFD Entry Errors
Implementers should make sure when generating a TIFF profile that:
a) All entries exist. Missing entries make it impossible to read
the image data.
b) Tags will not have two types of data (for example SHORT or
LONG).
c) Tags do not have the wrong type of data (for example RATIONAL
instead of SRATIONAL).
d) The count of type is correct for a specified tag (it is not null
and the matches the tag ID)
e) Tags appear in the right order in the IFD.
Cancio, Moldovan, Tamura, Wing Work-in-progress [Page 14]
Internet draft Implementers Guide 21 September 2000
f) Tags as PageNumber or ImageLayer have values that match the
number of IFDs or the image data.
g) Tags are unique within an IFD.
5.2.4 Strip Errors
Implementers should make sure when generating a TIFF profile that:
a) Strip data is not overlapped with another file data
b) The strip offset does not point outside file
c) The strip length is not null or the strip offset + strip length
does not point outside file
d) There is only one bit order (not more) specified for data storing.
5.2.5 Image Errors
a) Implementers should be cautious when generating a TIFF profile
that the type of image tags and the data from the strip data
match. For example, if in case of a black and white image the
PhotometricInterpretation tag value is 0 (bit 0 means white) the
image will appear inverted.
b) Implementers should be cautious when generating a TIFF profile
that for the special color spaces (ITULAB, YCBCR, CMYK) the
parameters used for transformations are correct and compliant to
the specification.
c) Implementers should make sure when generating a TIFF profile
that the tag values for XPosition and YPosition are correct.
5.2.6 Profile Specific Errors
a) Implementers should make sure when generating a TIFF profile
that all combinations of tag values are correct. Special
attention should be given to the sets: XResolution, YResolution
and ImageWidth and PhotometricInterpretation, SamplesPerPixel,
and BitsPerSample.
b) Implementers should make sure when generating a TIFF Profile M
that the compression used for the layers is correct. Typical
errors are for the Mask layer not be compressed with a black and
white compression and the Background and Foreground layer not to
be compressed with a color compression.
Cancio, Moldovan, Tamura, Wing Work-in-progress [Page 15]
Internet draft Implementers Guide 21 September 2000
6. Implementation Issues for Internet Fax Addressing
The GSTN addresses in e-mail addresses specifications (currently RFC2303 [12],
RFC2304 [13] and RFC2846 [14]) require the use of the "=" and "+" characters
inside the local-part (see RFC822 [10]) and forward-path and reverse-path (see
RFC821 [11]) of the address. In these fields the "=" and "+" characters are
allowed and thus they MUST NOT be encoded in any way. Also other message headers
fields extensions (like Original-Recipient, see RFC2298 [9]) allows these
characters which thus MUST NOT be encoded.
However GSTN addresses can also appear in other fields, and in particular inside
ESMTP parameters as esmtp-value (see RFC1869 [15]; the ORCPT parameter (see
RFC1891 [5]) is one of such cases. When the "=" and "+" characters in GSTN
addresses appear as esmtp-value, they MUST be encoded as hexchar (see RFC1891
[5]).
In particular, the same GSTN address could require different behavior inside the
same ESMTP command line:
RCPT TO:<FAX=+390408565@faxmail.com> ORCPT=FAX+3D+2B290408565@fxmail.com
7. Security considerations
With regards to this document, Sections 5 in RFC 2305 [2] and Section 4 in
RFC 2532 [3] apply.
8. Acknowledgements
he authors gratefully acknowledge the following persons who contributed or
made comments on earlier versions of this memo:
Claudio Allocchio, Richard Coles, Ryuji Iwazaki, Graham Klyne, James Rafferty,
and Kensuke Yamada.
9. References
[1] RFC 2542, "Terminology and Goals for Internet Fax",
Masinter, L.,
March 1999.
[2] RFC 2305, "A Simple Mode of Facsimile Using Internet Mail",
Toyoda, K., Ohno, H., Murai, J. and Wing, D.,
March 1998.
[3] RFC 2532, "Extended Facsimile Using Internet Mail",
Masinter, L. and Wing, D.
March 1999.
Cancio, Moldovan, Tamura, Wing Work-in-progress [Page 16]
Internet draft Implementers Guide 21 September 2000
[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 1891 "SMTP Service Extension for Delivery Status Notification",
Moore, K.,
January 1996.
[6] RFC 1893 "Enhanced Mail System Status Codes",
Vaudreuil, G.,
January 1996.
[7] RFC 1894 "An Extensible Message Format for Delivery Status Notifications",
Moore, K., Vaudreuil, G.,
January 1996.
[8] RFC 2034 "SMTP Service Extension for Returning Enhanced Error Codes",
Freed, N.,
October 1996.
[9] RFC 2298 "An Extensible Message Format for Message Disposition
Notifications", Fajman, R.
March 1998.
[10] RFC 822 "Standard for the Format of ARPA Internet Text Messages",
Crocker. D.,
August 1982.
[11] RFC 821 "A Simple Mail Transfer Protocol",
Postel, D.,
August 1982.
[12] RFC 2303 "Minimal PSTN address format in Internet Mail",
Allocchio, C.
March 1998
[13] RFC 2304 "Minimal FAX address format in Internet Mail",
Allocchio, C.
March 1998
[14] RFC 2846 "GSTN Address Element Extensions in E-mail Services",
Allocchio, C.
June 2000
[15] RFC 1869 "SMTP Service Extensions",
Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker, D.
November 1995
Cancio, Moldovan, Tamura, Wing Work-in-progress [Page 17]
Internet draft Implementers Guide 21 September 2000
10. 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
Email: 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
Email: mmoldovan@g3nova.com
Hiroshi Tamura
Ricoh Company, LTD.
2446 Toda, Atsugi City,
Kanagawa-Pref., 243-0023 Japan
Telephone: +81-46-228-1743
Facsimile: +81-46-228-7500
Email: tamura@toda.ricoh.co.jp
Dan Wing
Cisco Systems, Inc.
101 Cooper Street
Santa Cruz, CA 95060 USA
Telephone: +1 831 457 5200
Facsimile: +1 831 457 5208
EMail: dwing@cisco.com
Cancio, Moldovan, Tamura, Wing Work-in-progress [Page 18]
Internet draft Implementers Guide 21 September 2000
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.
Cancio, Moldovan, Tamura, Wing Work-in-progress [Page 19]
Internet draft Implementers Guide 21 September 2000
Revision history
[[[RFC editor: Please remove this section on publication]]]
Version 2
1) Changed first sentence of 4.4.1.1
2) Added Sections: 4.4.1.2, 4.4.1.3, 4.4.1.4, 4.4.2.1, 4.4.2.2, 4.4.2.3,
4.4.3.1, 4.4.3.2 and 4.4.4
3) Deleted Sections: 6 and 7
4) Changed heading of Section 4.4.1
5) In examples: replaced ifax@water.line.com
with ifax@copper.point.com as well as other editorial changes
in the examples through the document.
6) In examples: changed text in subject field of DSN
7) In examples: changed text in subject field of MDN
8) In examples: changed text in text field of MDN
9) Reworded text through out the document
10) Replaced heading in 5.2.1 [to "TIFF Readers: Be Cautious with Headers"]
11) " " 5.2.2 [to "TIFF Writers: Be Cautious in use of IFD"]
Version 3
1) Section 5.2.1 and 5.2.2 were merged into 5.2; some of the
Paragraphs in Section 5 were reworded for clarity.
2) The RFC 821 was added to the Reference section.
3) The Reference section format was modified for consistency.
4) A new Section 6 was added.
5) References [9], [10], [11], [12], [13], [14] & [15] were added in Section 6.
6) Description of [12], [13], [14] & [15] was added to the Reference section
| PAFTECH AB 2003-2026 | 2026-04-23 09:45:07 |