summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3249.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3249.txt')
-rw-r--r--doc/rfc/rfc3249.txt1179
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc3249.txt b/doc/rfc/rfc3249.txt
new file mode 100644
index 0000000..f1864e2
--- /dev/null
+++ b/doc/rfc/rfc3249.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group V. Cancio
+Request for Comments: 3249 Xerox Corporation
+Category: Informational M. Moldovan
+ G3 Nova Technology, Inc.
+ H. Tamura
+ Ricoh Company, LTD.
+ D. Wing
+ Cisco Systems
+ September 2002
+
+
+ Implementers Guide for Facsimile Using Internet Mail
+
+Status of this Memo
+
+ 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 (2002). All Rights Reserved.
+
+Abstract
+
+ This document is intended for the implementers of software that use
+ email to send to facsimiles using RFC 2305 and 2532. This is an
+ informational document and its guidelines do not supersede the
+ referenced documents.
+
+Table of Contents
+
+ 1. Introduction .................................................. 2
+ 1.1 Organization of this document ................................ 2
+ 1.2 Discussion of this document .................................. 2
+ 2. Terminology ................................................... 3
+ 3. Implementation Issues Specific to Simple Mode ................. 3
+ 3.1 Simple Mode Fax Senders ...................................... 3
+ 3.1.1 Multipart-alternative ...................................... 3
+ 3.2 Simple Mode Fax Receivers .................................... 4
+ 3.2.1 Multipart-alternative and Storage Capacity ................. 4
+ 4. Implementation Issues Specific to Extended Mode ............... 4
+ 4.1 Multipart-alternative ........................................ 4
+ 4.2 Correlation of MDN with Original Message ..................... 4
+ 4.3 Correlation of DSN with Original Message ..................... 5
+ 4.4 Extended Mode Receivers ...................................... 5
+ 4.4.1 Confirmation of receipt and processing from User Agents .... 5
+ 4.4.1.1 Discrepancies in MDN [9] Interpretation .................. 5
+
+
+
+Cancio, et. al. Informational [Page 1]
+
+RFC 3249 Implementers Guide for Facsimile September 2002
+
+
+ 4.4.1.2 Disposition-Type and body of message in MDN .............. 6
+ 4.4.2 "Subject" of MDN and DSN in Success and Failure Cases ...... 6
+ 4.4.3 Extended Mode Receivers that are MTAs (or ESMTP servers) ... 7
+ 4.4.3.1 Success Case Example ..................................... 7
+ 4.4.3.2 Failure Case Example 1 ................................... 9
+ 4.4.3.3 Failure Case Example 2 ................................... 10
+ 4.4.4 Extended Mode Receivers that are POP3/IMAP4 ................ 11
+ 4.4.4.1 Success Case Example ..................................... 11
+ 4.4.4.2 Failure Case Example ..................................... 12
+ 4.4.5 Receiving Multiple Attachments ............................. 13
+ 5. Implementation Issues Specific to the File Format ............. 13
+ 5.1 IFD Placement & Profile-S Constraints ........................ 13
+ 5.2 Precautions for implementers of RFC 2301 [4] ................. 14
+ 5.2.1 Errors encountered during interoperability testing ......... 14
+ 5.2.2 Color Gamut Considerations ................................. 14
+ 5.2.3 File format Considerations ................................. 15
+ 5.2.3.1 Considerations for greater reader flexibility ............ 15
+ 5.2.3.2 Error considerations ..................................... 16
+ 5.3 Content-Type for the file format ............................. 17
+ 6. Implementation Issues for Internet Fax Addressing ............. 17
+ 7. Security Considerations ....................................... 18
+ 8. Acknowledgements .............................................. 18
+ 9. References .................................................... 18
+ 10. Authors' Addresses ........................................... 20
+ 11. Full Copyright Statement ..................................... 21
+
+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
+
+ This document contains four sections that clarify, in order, the
+ handling of simple mode fax messages, extended mode fax messages, the
+ file format, and the internet addressing of fax recipients.
+
+ See Section 2 for terminology.
+
+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
+
+
+
+Cancio, et. al. Informational [Page 2]
+
+RFC 3249 Implementers Guide for Facsimile September 2002
+
+
+ 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
+
+ The following terms are used throughout this document:
+
+ DSN - RFC 1894, "An Extensible Message Format for
+ Delivery Status Notifications" [7]
+ Extended Mode - RFC 2532, "Extended Facsimile Using
+ Internet Mail" [3]
+ MDN - RFC 2298, "An Extensible Message Format for
+ Message Disposition Notifications" [9]
+ Simple Mode - RFC 2305, "A Simple Mode of Facsimile
+ Using Internet Mail" [2]
+ TIFF - profile S or F of "File Format for Internet Fax" [4]
+ delivered as "image/tiff"
+ TIFF-FX - other profiles sent as "image/tiff-fx"
+
+ In examples, "C:" is used to indicate lines sent by the client, and
+ "S:" to indicate those sent by the server.
+
+3. Implementation Issues Specific to Simple Mode
+
+ Issues specific to Simple Mode [2] are described below:
+
+3.1 Simple Mode Fax Senders
+
+3.1.1 Multipart/alternative
+
+ Although a requirement of MIME compliance (16, 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.
+
+
+
+
+
+
+
+
+
+
+Cancio, et. al. Informational [Page 3]
+
+RFC 3249 Implementers Guide for Facsimile September 2002
+
+
+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 part of a
+ multipart/alternative message it is capable of processing.
+
+ This behavior means that even if subsequent, higher-fidelity parts
+ could have been processed, 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 parts.
+ However, a mechanism to determine the recipient capabilities prior to
+ 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 a User Agent.
+
+4. Implementation Issues Specific to Extended Mode
+
+ Issues specific to Extended Mode [3] fax are described below. Note
+ that any Extended Mode device also needs to consider issues specific
+ to Simple Mode (Section 3 of this document).
+
+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]:
+
+ 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.
+
+
+
+
+Cancio, et. al. Informational [Page 4]
+
+RFC 3249 Implementers Guide for Facsimile September 2002
+
+
+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 (attachment) was delivered and
+ successfully processed is an important aspect of the extended mode of
+ the facsimile using Internet mail. This section describes
+ implementation issues with several types of confirmations.
+
+4.4.1 Confirmation of receipt and processing from User Agents
+
+ When a message is received with the "Disposition-Notification-To"
+ header and the receiver has determined whether the message can be
+ processed, it may generate a:
+
+ a) Negative MDN in case of error, or
+
+ b) Positive MDN in case of success
+
+ The purpose of receiving a requested MDN acknowledgement from an
+ Extended Mode recipient is the indication of success or failure to
+ process the file attachment that was sent. The attachment, not the
+ body, constitutes the facsimile message. Therefore an Extended Mode
+ sender would expect, and it is recommended that the Extended Mode
+ receiver send (with an MDN), an acknowledgement of the success or
+ failure to decode and process the file attachment.
+
+ Implementers of the Extended Mode [3] should be consistent in the
+ feedback provided to senders in the form of error codes and/or
+ failure/success messages.
+
+4.4.1.1 Discrepancies in MDN [9] Interpretation
+
+ An Extended Mode sender must be aware that RFC 2298 [9] does not
+ distinguish between the success or failure to decode the body-content
+ part of the message and 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 file, but rather to
+ decode the body-content part of the message.
+
+
+
+
+
+
+
+
+Cancio, et. al. Informational [Page 5]
+
+RFC 3249 Implementers Guide for Facsimile September 2002
+
+
+4.4.1.2 Disposition-Type and body of message in MDN
+
+ If the receiver of an MDN request is an RFC 2532 compliant device
+ that automatically prints the received Internet mail messages and
+ attachments, or forwards the attachment via GSTN fax, it should, in
+ the case of success:
+
+ a) Use a "disposition-type" of "dispatched" (with no "disposition-
+ modifier") in the MDN, and
+
+ b) Use text similar to the following in the body of the message:
+
+ "This is a Return Receipt for the mail that you sent to [above, or
+ below, or this address, etc]. The message and attached files[s]
+ may have been printed, faxed or saved. This is no guarantee that
+ the message has been read or understood".
+
+ and in the case of failure:
+
+ a) Use a "disposition-type" of "processed" and disposition-modifier
+ of "error", and
+
+ b) Use text similar to the following in the body of the message:
+
+ "This is a Return Receipt for the mail that you sent to [above, or
+ below, or this address, etc]. An error occurred while attempting
+ to decode the attached file[s]".
+
+ This recommendation adheres to the definition in RFC 2298 [9] and
+ helps to distinguish the returned MDNs for proper handling.
+
+ Implementers may wish to consider sending messages in the language of
+ the sender (by utilizing a header field from the original message) or
+ including multiple languages, by using multipart/alternative for the
+ text portion of the MDN.
+
+4.4.2 "Subject" of MDN and DSN 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.
+
+ Examples:
+
+ MDN:
+ Subject: Your message was processed successfully. (MDN)
+ Subject: Your message has been rejected. (MDN)
+
+
+
+
+Cancio, et. al. Informational [Page 6]
+
+RFC 3249 Implementers Guide for Facsimile September 2002
+
+
+ DSN:
+ Subject: Your message was delivered successfully. (DSN)
+ Subject: Your message could not be delivered. (DSN)
+ Subject: Your message is delayed. (DSN)
+
+4.4.3 Extended Mode Receivers that are MTAs (or ESMTP servers)
+
+ SMTP server-based implementations are strongly encouraged to
+ implement the "SMTP Service Extension for Returning Enhanced Error
+ Codes" [8]. 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[5]/1893[6]/1894[7]/2034[8]), the standards take precedence.
+
+4.4.3.1 Success Case Example
+
+ In the following example the sender <jean@example.com> sends a
+ message to the receiver <ifax@example.net> which is an ESMTP server
+ and the receiver successfully decodes the message.
+
+ example.com
+ +-------+
+ | Mail |
+ | User |
+ | Agent |
+ +-------+
+ |
+ V
+ +----------+ +--------+ +---------+
+ | Mail + | Mail | | Mail |
+ |Submission|----->|Transfer|---->|Transfer |
+ | Agent | | Agent | | Agent |
+ +----------+ +--------+ +---------+
+
+ example.org example.net
+
+
+
+
+
+
+
+
+
+
+
+
+Cancio, et. al. Informational [Page 7]
+
+RFC 3249 Implementers Guide for Facsimile September 2002
+
+
+ SMTP Sequence:
+
+ S: 220 example.net SMTP service ready
+ C: EHLO example.org
+ S: 250-example.net
+ S: 250-DSN
+ S: 250 ENHANCEDSTATUSCODES
+ C: MAIL FROM:<jean@example.com> RET=HDRS ENVID=MM123456
+ S: 250 2.1.0 Originator <jean@example.com> ok
+ C: RCPT TO:<ifax@example.net> NOTIFY=SUCCESS,FAILURE \
+ ORCPT=rfc822;ifax@example.net
+ S: 250 2.1.5 Recipient <ifax@example.net> ok
+ C: DATA
+ S: 354 Send message, ending in <CRLF>.<CRLF>
+ C:
+ C: [Message goes here.]
+ C:
+ C: .
+ S: 250 2.0.0 Message accepted
+ C: QUIT
+ S: 221 2.0.0 Goodbye
+
+ DSN (to jean@example.com):
+
+ Date: Mon, 12 Dec 1999 19:01:57 +0900
+ From: postmaster@example.net
+ Message-ID: <19991212190157.01234@example.net>
+ To: jean@example.com
+ Subject: Your message was delivered successfully. (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@example.net.
+
+ --JUK199912121854870001
+ Content-type: message/delivery-status
+
+
+
+
+
+
+
+
+
+
+Cancio, et. al. Informational [Page 8]
+
+RFC 3249 Implementers Guide for Facsimile September 2002
+
+
+ Reporting-MTA: dns; example.net
+ Original-Envelope-ID: MM123456
+ Final-Recipient: rfc822;ifax@example.net
+ Action: delivered
+ Status: 2.1.5 (Destination address valid)
+ Diagnostic-Code: smtp; 250 2.1.5
+ Recipient <ifax@example.net> ok
+
+ --JUK199912121854870001
+ Content-type: message/rfc822
+
+ [headers of returned message go here.]
+
+ --JUK199912121854870001--
+
+4.4.3.2 Failure Case Example 1
+
+ In this example, the receiver determines it is unable to decode the
+ attached file AFTER it has received the SMTP message. The receiver
+ then sends a 'failure' DSN.
+
+ example.com
+ +-------+
+ | Mail |
+ | User |
+ | Agent |
+ +-------+
+ |
+ V
+ +----------+ +--------+ +---------+
+ | Mail + | Mail | | Mail |
+ |Submission|----->|Transfer|---->|Transfer |
+ | Agent | | Agent | | Agent |
+ +----------+ +--------+ +---------+
+ example.org example.net
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+Cancio, et. al. Informational [Page 9]
+
+RFC 3249 Implementers Guide for Facsimile September 2002
+
+
+ DSN (to jean@example.com):
+
+ Date: Mon, 12 Dec 1999 19:31:20 +0900
+ From: postmaster@example.net
+ Message-ID: <19991212193120.87652@example.net>
+ To: jean@example.com
+ Subject: Your message could not be delivered. (DSN)
+ 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@example.net resulted in an
+ error while attempting to decode the attached file.
+
+ --JUK199912121934240002
+ Content-type: message/delivery-status
+
+ Reporting-MTA: dns; example.net
+ Original-Envelope-ID: MM123456
+ Final-Recipient: rfc822;ifax@example.net
+ 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.]
+
+ --JUK199912121934240002--
+
+4.4.3.3 Failure Case Example 2
+
+ In this example, the receiver determines it is unable to decode the
+ attached file BEFORE it accepts the SMTP transmission.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cancio, et. al. Informational [Page 10]
+
+RFC 3249 Implementers Guide for Facsimile September 2002
+
+
+ SMTP sequence:
+
+ S: 220 example.net SMTP service ready
+ C: EHLO example.org
+ S: 250-example.net
+ S: 250-DSN
+ S: 250 ENHANCEDSTATUSCODES
+ C: MAIL FROM:<jean@example.com> RET=HDRS ENVID=MM123456
+ S: 250 2.1.0 Originator <jean@example.com> ok
+ C: RCPT TO:<ifax@example.net> NOTIFY=SUCCESS,FAILURE \
+ ORCPT=rfc822;ifax@example.net
+ S: 250 2.1.5 Recipient <ifax@example.net> ok
+ C: DATA
+ S: 354 Send message, ending in <CRLF>.<CRLF>
+ C:
+ C: [Message goes here.]
+ C:
+ 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.4 Extended Mode Receivers that are POP3/IMAP4
+
+ NOTE: This document does not define new disposition-types or
+ disposition-modifiers. Those used below are defined in RFC
+ 2298[9]. This section provides examples on how POP3/IMAP4 devices
+ may use the already defined values.
+
+ 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 MDN [9] standard, the standard takes
+ precedence.
+
+4.4.4.1 Success Case Example
+
+ If the original sender receives an MDN which has "displayed",
+ "dispatched" or "processed" disposition-type without disposition-
+ modifier, the receiver may have received or decoded the attached file
+ that it sent. The MDN does not guarantee that the receiver displays,
+ prints or saves the attached file. See Section 4.4.1.1,
+ Discrepancies in MDN Interpretation.
+
+
+
+Cancio, et. al. Informational [Page 11]
+
+RFC 3249 Implementers Guide for Facsimile September 2002
+
+
+ NOTE: This example does not include the third component of the
+ MDN.
+
+ Date: 14 Dec 1999 17:48:44 +0900
+ From: ken_recipient@example.com
+ Message-ID: <19991214174844.98765@example.com>
+ Subject: Your message was processed successfully. (MDN)
+ To: mary@example.net
+ 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@example.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.example.com; barmail 1999.10
+ Original-Recipient: rfc822;ken_recipient@example.com
+ Final-Recipient: rfc822;ken_recipient@example.com
+ Original-Message-ID: <19991214174010O.mary@example.net>
+ Disposition: automatic-action/MDN-sent-automatically; dispatched
+
+ --61FD1001_IFAX--
+
+4.4.4.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 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 file.
+
+ Date: 14 Dec 1999 19:48:44 +0900
+ From: ken_recipient@example.com
+ Message-ID: <19991214194844.67325@example.com>
+ Subject: Your message has been rejected. (MDN)
+ To: mary@example.net
+ Mime-Version: 1.0
+ Content-Type: multipart/report;
+ report-type=disposition-notification; boundary="84FD1011_IFAX"
+
+
+
+
+Cancio, et. al. Informational [Page 12]
+
+RFC 3249 Implementers Guide for Facsimile September 2002
+
+
+ --84FD1011_IFAX
+ Content-Type: text/plain
+
+ This is a Return Receipt for the mail that you sent to
+ "ken_recipient@example.com". An error occurred while attempting
+ to decode the attached file[s]".
+
+ --84FD1011_IFAX
+ Content-Type: message/disposition-notification
+
+ Reporting-UA: ken-ifax.example.com; barmail 1999.10
+ Original-Recipient: rfc822;ken_recipient@example.com
+ Final-Recipient: rfc822;ken_recipient@example.com
+ Original-Message-ID: <199912141823123.mary@example.net>
+ Disposition: automatic-action/MDN-sent-automatically;
+ processed/error
+
+ --84FD1011_IFAX
+ Content-Type: message/rfc822
+
+ [original message goes here]
+
+ --84FD1011_IFAX--
+
+4.4.5 Receiving Multiple Attachments
+
+ A received email message could contain multiple attachments and each
+ distinct attachment could use TIFF or TIFF-FX with different
+ encodings or resolutions, and these could be mixed with other file
+ types.
+
+ There is currently no mechanism to identify, in a returned MDN, 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 for the entire message.
+
+5. Implementation Issues Specific to the File Format
+
+5.1 IFD Placement & Profile-S Constraints
+
+ a) An IFD is required, by TIFF 6.0, to begin on a word boundary,
+ however, there is ambiguity with regard to the defined size of a
+ word. A word should be interpreted as a 2-byte quantity. This
+
+
+
+
+
+Cancio, et. al. Informational [Page 13]
+
+RFC 3249 Implementers Guide for Facsimile September 2002
+
+
+ recommendation is based on examination of Figure 1 and the
+ definition of IFD Entry, Bytes 8-11, found in Section 2 of TIFF
+ 6.0.
+
+ b) 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 image file when using any of the Profiles defined
+ in [4].
+
+5.2 Precautions for implementers of RFC 2301 [4]
+
+5.2.1 Errors encountered during interoperability testing
+
+ The TIFF/RFC 2301 [4] errors listed below were encountered during
+ interoperability testing and are provided so that implementers of
+ TIFF readers and writers can take precautionary measures.
+
+ a) Although Profile S of TIFF [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 handle
+ cases where the byte order field contains values other than "II"
+ or "MM", and writers should ensure the correct value is used.
+
+5.2.2 Color Gamut Considerations
+
+ The ITULAB encoding (PhotometricInterpretation = 10) allows choosing
+ a gamut range for L*a*b* (see the TIFF field Decode), which in turn
+ provides a way to place finer granularity on the integer values
+ represented in this colorspace. But consequently, an inadequate
+ gamut choice may cause a loss in the preservation of colors that
+ don't fall within the space of colors bounded by the gamut. As such,
+ it is worth commenting on this.
+
+
+
+
+
+
+Cancio, et. al. Informational [Page 14]
+
+RFC 3249 Implementers Guide for Facsimile September 2002
+
+
+ The ITULAB default gamut, L [0,100] a [-85,85] b [-75,125], was
+ chosen to accommodate most scan devices, which are typically acquired
+ from a hardcopy source. It wasn't chosen to deal with the range of
+ color from camera input or sRGB monitor data. In fact, when dealing
+ with images from the web and other display oriented sources, the
+ color range for a scanned hardcopy may likely be inadequate. It is
+ important to use a gamut that matches the source of the image data.
+
+ The following guidelines are recommended:
+
+ 1. When acquiring input from a printed hardcopy source, without
+ modification, the ITU-T Recommendation T.42 default ITULAB gamut
+ should be appropriate.
+
+ 2. For an sRGB source, the ITU-T Recommendation T.42 default ITULAB
+ gamut is not appropriate. A more appropriate gamut to consider
+ is: L [0,100], a [-88,99] and b [-108.8,95.2]. These may be
+ realized by using the following Decode values for 8-bit data:
+ (0/1, 100/1, -22440/255, 25245/255, -27744/255, 24276/255).
+
+ 3. If the range of L*a*b* value can be precomputed efficiently before
+ converting to ITULAB, then you may get the best result by picking
+ a gamut that is custom to this range.
+
+5.2.3 File format Considerations
+
+ Implementers should make sure of the contents in the following two
+ sections.
+
+5.2.3.1 Considerations for greater reader flexibility
+
+ a) Readers are able to handle cases where IFD offsets point beyond
+ the end of the file, while writers ensure that the IFD offset does
+ not point beyond the end of the file.
+
+ b) Readers are able to handle the first IFD offset being on a non-
+ word boundary, while writers ensure that the first IFD offset is
+ on a word boundary.
+
+ c) Readers are flexible and able to accommodate: IFDs that are not
+ presented in ascending page order; IFDs that are not placed at a
+ location that precedes the image which the IFD describes; next IFD
+ offsets that precede the current IFD, the current IFDs' field
+ data, or the current IFDs' image data. Writers on the other hand
+ should generate files with IFDs presented in ascending page order;
+ IFDs placed at a location that precedes the image which the IFD
+ describes; the next IFD should always follow the current IFD and
+ all of its data.
+
+
+
+Cancio, et. al. Informational [Page 15]
+
+RFC 3249 Implementers Guide for Facsimile September 2002
+
+
+ d) Writers generate tags with the appropriate type of data (for
+ example RATIONAL instead of SRATIONAL). Readers are flexible with
+ those types of misrepresentations that may be readily accommodated
+ (for example SHORT instead of LONG) and lead to enhanced
+ robustness.
+
+ e) The appropriate count is associated with the tags (it is not 0 and
+ matches the tag requirement), while readers are flexible with
+ these types of misrepresentations, which may be readily
+ accommodated and lead to enhanced robustness.
+
+ f) Tags appear in the correct order in the IFD and readers are
+ flexible with these types of misrepresentations.
+
+5.2.3.2 Error considerations
+
+ a) Readers only accept files with bytes 2-3 of the Image File Header
+ equal to 42 (2Ah), the "magic number", as being valid TIFF or
+ TIFF-FX files, while writers only generate files with the
+ appropriate magic number.
+
+ b) Files are not generated with missing field entries, and readers
+ reject any such files.
+
+ c) The PageNumber value is based on the order within the Primary IFD
+ chain. The ImageLayer values are based on the layer order and the
+ image order within the layer respectively. Readers may reject the
+ pages where the PageNumber or ImageLayer values are not consistent
+ with the number of Primary IFDs, number of layers or number of
+ images within the layers.
+
+ d) Tags are unique within an IFD and readers may reject pages where
+ this is not the case.
+
+ e) Strip data does not overlap other file data and the reader may
+ error appropriately.
+
+ f) The strip offset does not point outside the file, under these
+ conditions readers may reject the page where this is the case.
+
+ g) The strip offset + StripByteCounts does not point outside the
+ file, under these conditions the reader may error appropriately.
+
+ h) Only one endian order is used within the file otherwise the
+ rendered file will be corrupted.
+
+
+
+
+
+
+Cancio, et. al. Informational [Page 16]
+
+RFC 3249 Implementers Guide for Facsimile September 2002
+
+
+ i) Tag values are consistent with the data contained within the image
+ strip. For example, a bi-level black mark on a white background
+ image strip with a PhotometricInterpretation tag value of "1" (bit
+ value of "0" means black) will result in the rendering of the
+ image as white marks on a black background (reverse video).
+
+ j) For the special color spaces (ITULAB, YCBCR, CMYK), the parameters
+ used for transformations are correct and compliant with the
+ specification.
+
+ k) The XPosition and YPosition values are consistent with the
+ horizontal and vertical offsets of the top-left of the IFD from
+ the top-left of the Primary IFD, in units of the resolution. To
+ do otherwise results in misplacement of the rendered image.
+
+ l) All combinations of tag values are correct, with special attention
+ being given to the sets: XResolution, YResolution and ImageWidth;
+ PhotometricInterpretation, SamplesPerPixel, and BitsPerSample.
+ Any appropriate combinations will likely result in image
+ distortion or an inability to render the image.
+
+ m) The appropriate Compression types are used for the image layers
+ within a Profile M file, such as a bi-level coder for the mask
+ layers (i.e. odd numbered layers) and multi-level (color) coders
+ for the background and foreground layers. Readers should reject
+ files where this is not true.
+
+5.3 Content-Type for the file format
+
+ The content-type "image/tiff" should only be used for Profiles S and
+ F. Some existing implementations based on [4] may use "image/tiff"
+ for other Profiles. However, this usage is now deprecated. Instead,
+ the content-type "image/tiff-fx", whose registration is being defined
+ in [17] should be used.
+
+ To maximize interworking with devices that are only capable of
+ rendering Profile S or F, "image/tiff" SHOULD be used when
+ transporting Profile S or F.
+
+6. Implementation Issues for Internet Fax Addressing
+
+ The "+" and "=" characters are valid within message headers, but must
+ be encoded within some ESMTP commands, most notably ORCPT [5].
+ Implementations must take special care that ORCPT (and other ESMTP
+ values) are properly encoded.
+
+
+
+
+
+
+Cancio, et. al. Informational [Page 17]
+
+RFC 3249 Implementers Guide for Facsimile September 2002
+
+
+ For example, the following header is valid as-is:
+
+ To: Home Fax <FAX=+390408565@example.com>
+
+ but when used with ORCPT, the "=" and "+" must be encoded like this:
+
+ RCPT TO:<FAX=+390408565@example.com> \
+ ORCPT=FAX+3D+2B390408565@example.com
+
+ Note the "=" and "+" are valid inside the forward-path, but must be
+ encoded when used within the esmtp value.
+
+ See [5] for details on this encoding.
+
+7. Security Considerations
+
+ With regards to this document, Sections 5 in RFC 2305 [2] and Section
+ 4 in RFC 2532 [3] apply.
+
+8. Acknowledgements
+
+ The 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, Kensuke Yamada, Jutta Degener and Lloyd McIntyre.
+
+9. References
+
+ [1] Masinter, L., "Terminology and Goals for Internet Fax", RFC
+ 2542, March 1999.
+
+ [2] Toyoda, K., Ohno, H., Murai, J. and D. Wing, "A Simple Mode of
+ Facsimile Using Internet Mail", RFC 3205, March 1998.
+
+ [3] Masinter, L. and D. Wing, "Extended Facsimile Using Internet
+ Mail", RFC 2532, March 1999.
+
+ [4] McIntyre, L., Zilles, S., Buckley, R., Venable, D., Parsons, G.
+ and J. Rafferty, "File Format for Internet Fax", RFC 2301,
+ March 1998.
+
+ [5] Moore, K., "SMTP Service Extension for Delivery Status
+ Notification", RFC 1891, January 1996.
+
+ [6] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
+ January 1996.
+
+
+
+
+
+Cancio, et. al. Informational [Page 18]
+
+RFC 3249 Implementers Guide for Facsimile September 2002
+
+
+ [7] Moore, K. and G. Vaudreuil, "An Extensible Message Format for
+ Delivery Status Notifications", RFC 1894, January 1996.
+
+ [8] Freed, N., "SMTP Service Extension for Returning Enhanced Error
+ Codes", RFC 2034, October 1996.
+
+ [9] Fajman, R., "An Extensible Message Format for Message
+ Disposition Notifications", RFC 2298, March 1998.
+
+ [10] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, August 1982.
+
+ [11] Postel, J., "A Simple Mail Transfer Protocol", STD 10, RFC 821,
+ August 1982.
+
+ [12] Allocchio, C., "Minimal GSTN address format in Internet Mail",
+ RFC 3191, October 2001.
+
+ [13] Allocchio, C., "Minimal FAX address format in Internet Mail",
+ RFC 3192, October 2001.
+
+ [14] Allocchio, C., "GSTN Address Element Extensions in E-mail
+ Services", RFC 2846, June 2000
+
+ [15] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,
+ D., "SMTP Service Extensions", RFC 2846, November 1995
+
+ [16] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part Two: Media Types", RFC 2046, November
+ 1996
+
+ [17] McIntyre, L., Parsons, G. and J. Rafferty, "Tag Image File
+ Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type
+ Registration", RFC 3250, September 2002.
+
+ [18] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
+ 2001.
+
+ [19] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
+
+
+
+
+
+
+
+
+
+
+
+
+Cancio, et. al. Informational [Page 19]
+
+RFC 3249 Implementers Guide for Facsimile September 2002
+
+
+10. Authors' Addresses
+
+ Vivian Cancio
+ 103 Cuesta Drive
+ Los Altos, CA 94022
+
+ Phone: +1-650-948-3135
+ EMail: vcancio@pacbell.net
+
+
+ Mike Moldovan
+ G3 Nova Technology Inc.
+ 5743 Corsa Avenue, Suite 122
+ Westlake Village, CA 91362
+
+ Phone: (818) 865-6600 Ext.113
+ EMail: mmoldovan@g3nova.com
+
+
+ Hiroshi Tamura
+ Ricoh Company, LTD.
+ 1-3-6 Nakamagome, Ohta-ku
+ Tokyo 143-8555 Japan
+
+ Phone: +81-3-3777-8124
+ Fax: +81-3-5742-8859
+ EMail: tamura@toda.ricoh.co.jp
+
+
+ Dan Wing
+ Cisco Systems, Inc.
+ 170 W. Tasman Drive
+ San Jose, CA 95134-1706 USA
+
+ Phone: +1-408-525-5314
+ Fax: +1-408-527-8083
+ EMail: dwing@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cancio, et. al. Informational [Page 20]
+
+RFC 3249 Implementers Guide for Facsimile September 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cancio, et. al. Informational [Page 21]
+