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