doc: Add RFC documents

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]
+