From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3249.txt | 1179 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1179 insertions(+) create mode 100644 doc/rfc/rfc3249.txt (limited to 'doc/rfc/rfc3249.txt') 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 sends a + message to the receiver 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: RET=HDRS ENVID=MM123456 + S: 250 2.1.0 Originator ok + C: RCPT TO: NOTIFY=SUCCESS,FAILURE \ + ORCPT=rfc822;ifax@example.net + S: 250 2.1.5 Recipient ok + C: DATA + S: 354 Send message, ending in . + 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 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: RET=HDRS ENVID=MM123456 + S: 250 2.1.0 Originator ok + C: RCPT TO: NOTIFY=SUCCESS,FAILURE \ + ORCPT=rfc822;ifax@example.net + S: 250 2.1.5 Recipient ok + C: DATA + S: 354 Send message, ending in . + 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 + + but when used with ORCPT, the "=" and "+" must be encoded like this: + + RCPT TO: \ + 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] + -- cgit v1.2.3