Network Working Group D. Crocker Internet-Draft: draft-ietf-fax-itudc- Internet Mail 00.txt Consortium Expiration <4/98> October 24, 1997 PROCEDURES FOR THE TRANSFER OF FACSIMILE DATA VIA INTERNET MAIL STATUS OF THIS MEMO This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). INTRODUCTION NOTE: The distribution of this document to the IETF Fax WG was authorized by Study Group 8. The information herein is made available for use by the Fax WG. The material is copyright ITU-T and is not for further publication. This document is based on a draft which received an affirmative "determination" at the October, 1997 meeting of ITU Study Group 8. This version tunes and corrects some portions of that document, as well as creating an alternate organization and separating some control and value-added functions from the core process of sending a facsimile document. One of the goals of the reorganization is to facilitate use for simple facsimile over the Internet, possibly even compatible with the work being done by the IETF Fax working group, while still permitting use for the more advanced features desired by some constituencies of the ITU Study Group. ITU - Telecommunication Standadization Sector Temporary Document Study Group 8 Geneva, 7- 16 October 1997 Question: 4/8 SOURCE*: Internet Society TITLE: PROPOSED REVISION OF NEW DRAFT PROCEDURES FOR THE TRANSFER OF FACSIMILE DATA VIA INTERNET MAIL ________ Based on discussons with the author of TD 2128, the enclosed document attempts a reorganization and revision of TD 2128 to improve interworking with Internet mail end users and to simplify the specification and distinction between Simple and Basic Internet Fax services. The enclosed revised copy of TD2128 includes the following changes: 1. Revised list of References to include additional RFC specifications 2. Revision of document structure to distinguish Basic and Simple Internet fax within the main body of the document 3. Revision of Basic Internet Fax to form a functional core service. 4. Revision of specification for Simple Internet Fax to build upon the specification of Simple Internet Fax 5. Addition of sections for Internet mail addressing, tailored for use with Internet Fax. 6. Addition of sections for Internet mail message headers, to specify the headers required for use with Internet Fax. 7. Addition of section specifying delivery confirmation through use of existing Internet mail standards. 8. Revision of specification for exchange of capabilities, to use separate MIME type during a message exchange without other facsimile data. 9. Inclusion of annotations for opportunities to incorporate IETF RFCs by reference. INTERNATIONAL TELECOMMUNICATIONS Draft UNION Recommendatio n TELECOMMUNICATION T.Ifax1 STANDARDISATIZATION SECTOR STUDY PERIOD 1997 - 2000 October 1997 Original: English only PROCEDURES FOR THE TRANSFER OF FACSIMILE DATA VIA STORE AND FORWARD ON THE INTERNET CONTENTS: 1. SUMMARY AND SCOPE 7 2. INTRODUCTION AND BACKGROUND 7 3. REFERENCES 7 4. DEFINITIONS AND ABBREVIATIONS 8 5. SIMPLE INTERNET FAX 8 5.1 REASON FOR SIMPLE STORE AND FORWARD FACSIMILE 8 5.2 ADDRESSING 9 5.3 MESSAGE STRUCTURE 9 5.4 MESSAGE HEADERS 10 5.4.1 DATE: 10 5.4.2 FROM: 10 5.4.3 TO: AND CC: 10 5.4.4 MESSAGE-ID: 10 6. BASIC INTERNET FAX 10 6.1 ADDRESSING 10 6.2 MESSAGE STRUCTURE 10 6.3 MESSAGE HEADERS 11 7. CONFIRMATION OF RECEIPT 11 8. EXCHANGE OF CAPABILITIES 12 8.1.1 G3: SENDER'S CAPABILITIES 13 8.1.2 X"0A" G3: SENDER'S FACSIMILE TELEPHONE NUMBER1 3 8.1.3 X"0B" G3: NSF SIGNAL 13 8.1.4 X"0C" G3: NSS SIGNAL 13 8.1.5 X"0D" G3: NSC SIGNAL 13 8.1.6 G4 CAPABILITIES 13 9. FACSIMILE POLLING 13 9.1 MIME LABEL FOR DOCUMENT-RETRIEVAL BODY-PART 14 9.2 FORMAT OF THE DOCUMENT-RETRIEVAL BODY-PART 14 9.2.1 X"0F" G3: SELECTIVE POLL 14 9.2.2 G3: PASSWORD 14 9.2.3 G3: DTC 14 ANNEX A: TIFF-F FORMAT 16 A.1 REFERENCES, DEFINITIONS AND ABBREVIATIONS 16 A.2 TIFF 16 A.2.1 REFERENCES, DEFINITIONS AND ABBREVIATIONS 16 A.3 MIME LABELLING 16 A.4 TIFF-F 16 A.4.1 IFD AND IMAGE DATA 16 A.4.2 FACSIMILE CAPABILITIES 20 (XRESOLUTION,YRESOLUTION) = (200,200) IS CONSIDERED AS EQUIVALENT TO (204,196) 20 ANNEX B: TIFF-FX FORMAT 21 B.1 MIME LABELLING 21 B.2 TIFF-FX 21 B.3 COPY OF THE CONTENTS OF GENEVA OCTOBER 7-16 TEMPORARY DOCUMENT TD 2100 TO GO HERE. 21 APPENDIX A: SAMPLE TRANSACTIONS 22 APPENDIX B - A MULTIPART EXAMPLE 30 _1. Summary and scope This Recommendation: a) defines procedures that enable facsimile data to be transferred via Internet Email. b) supports the requirements of F.IFax. c) defines a method for identifying the capabilities of the remote equipment. d) defines a method for providing positive or negative acknowledgement of receipt. e) does not require changes to current ITU facsimile Recommendations. f) does not require changes to current IETF internet standards. g) does not require terminals to have multi-page memory. h) permits extensive interworking between facsimile and Internet mail users and facilities, sharing common services where possible and isolated facsimile-specific functions 2. Introduction and Background F.IFax, defines the service requirement for both real-time and store and forward facsimile over the Internet. For store and forward facsimile this Recommendation defines addressing, MIME encapsulation of document components and data formats for those components.. Store and forward facsimile uses Internet mail standard protocols for posting, relaying and delivery of store and forward facsimile document. It requires no changes to Internet standards or to ITU Facsimile Recommendations. Such an approach leads to a system that can be used universally without changes to Internet servers or other intermediate systems between the sender and the recipient and which permits interworking between facsimile store and forward users and users of general Internet mail. 3. References The following ITU-T Recommendations, and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; all users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. Internet RFC (Request For Comments) documents are available via http://ds.internic.net/ds/dspg/intdoc.html. 1. ITU-T T.30: Procedures for document facsimile transmission in the general switched telephone network 2. ITU-T T.4: Standardization of Group 3 facsimile apparatus for document transmission 3. ITU-T T.6: Facsimile coding schemes and coding control functions for Group 4 facsimile apparatus 4. ITU-T T.50: International Reference Alphabet (IRA) 5. ITU-T E.164: Numbering plan for the ISDN era 6. ITU-T F.IFax: Internet facsimile: operations and definition of service 7. ISO 8601:1988: Data elements and interchange formats representation of dates and times 8. ISO 2111: Data Communications - basic mode control procedures - code independent information transfer 9. RFC 822: Standard for the format of ARPA Internet text messages 10. RFC 821: Simple Mail Transfer Protocol 11. RFC-2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies 12. RFC-2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 13. RFC-2047: MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text 14. RFC-2048: Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures 15. RFC-2049: Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples 16. RFC-1725: Post Office Protocol Version 3 17. ITU-T T.563: Terminal characteristics for Group 4 facsimile apparatus 18. RFC 1123: Requirements for Internet Hosts -- Application and Support 19. RFC-1891 SMTP Service Extension for Delivery Status Notifications 20. RFC-1894 An Extensible Message Format for Delivery Status Notifications 4. Definitions and abbreviations All abbreviations are as per documents ITU-T T.30 and ITU- F.IFax unless specifically stated otherwise. G3 Group 3 facsimile G4 Group 4 facsimile Relay terminal A receiving system capable of relaying the received facsimile to one or more Group 3 or Group 4 facsimile terminals Email Electronic Mail IETF Internet Engineering Task Force IMAP Internet Mail Access Protocol version 4 MIME Multipurpose Internet Mail Extensions POP3 Post Office Protocol version 3 RFC Request For Comment (Draft IETF standard) SMTP Simple Mail Transfer Protocol TIFF Tagged Image File Format UTC Coordinated Universal Time: Time scale, based on the second (SI) IP Internet Protocol TCP Transmission Control Protocol In the descriptions below the following formats are used to represent octet values: X"nn" hexadecimal B"nnnnnnnn" binary: X"A3" = B"10100011" nnnn nnnn ITU format as bits are received: X"A3" = B"10100011" = 1100 0101 5. Simple Internet Fax 5.1 Reason for simple store and forward facsimile This mode is designed so that a facsimile terminal sends and receives the facsimile document as an image attached to an Email. 5.2 Addressing (This sub-section may be replaced by RFC citation, if the current IETF specification for facsimile addressing is published in a sufficiently timely fashion.) Specification of store and forward facsimile senders and recipients is accomplished by the use existing Internet mail addressing mechanisms and standards. Those mechanisms are tailored for store and forward facsimile through a compatible profile, which encodes the information required to refer to a facsimile terminal and the store and forward relay which connects that terminal to the Internet mail service. simple-fax-mbox = "FAX=" ( global-phone / local- phone ) global-phone = "+" digit-string local-phone = digit-string digit-string = 1*(DIGIT / "-" / ".") 5.3 Message structure The structure of an Internet mail message containing a facsimile is: Table 1/T.IFax - Simple store and forward facsimile Format DESCRIPTI NOTE ON Email 1 envelope Email 2 header Image 3 Data Notes: 1. Envelope information specifies the list of destinations to which the message is currently being sent, as well as the address of the agent which posted the message, and any other transfer-specific information which applies to the current transfer of the message. Normally this information is carried via SMTP (Reference 10, 18) commands. 2. This contains all normal end-to-end Internet mail message header fields such as "To:", "From:", "CC:", "BCC:", "Reply to:" etc., as documented in (References 9, 18) and extensions. 3. The body of the email is a MIME part which contains one or more pages of image data in the format defined in Annex A. 4. Some terminals may transmit character coded information with or without image data using Multipart/mixed. It is recommended that a terminal supporting the format defined here be designed to process such mixed content email; however it is outside the specification of this annex. 5.4 Message headers The following standard Internet mail headers are required for facsimile store and forward: 5.4.1 Date: This contains the date and time of message posting 5.4.2 From: This specifies the originator (author) of the message 5.4.3 To: and CC: These list the primary and secondary recipients, respectively, for the message. The lists can be a mixture of general Internet mail addresses and Internet mail addresses tailored for use by facsimile store and forward, as defined in Section 5.1. 5.4.4 Message-ID: This is a unique string which identifyies the message 6. Basic Internet Fax 6.1 Addressing (This sub-section may be replaced by RFC citation, if the current IETF specification for facsimile addressing is published in a sufficiently timely fashion.) basic-fax-mbox = simple-fax-mbox [ sub-sep sub-addr ] [ post-sep post-dial] sub-sep = sub-addr = ; This contains the contents of the T.30 SUB FIF. post-sep = post-dial = 6.2 Message structure The structure of an Email message containing a Basic facsimile store and forward message is the same as for Simple Internet Fax, with the addition of support for binary file data using standard MIME structuring and labelling: Table 2/T.IFax - Basic Store and forward facsimile Format DESCRIPTI NOTE ON Email 1 envelope Email 2 header Image 3 Data Binary 4 File Data Notes: 1. This is the same as for Simple Internet Fax. 2. This is the same as for Simple Internet Fax. 3. The body of the email is a MIME part which contains one or more pages of image data in the format defined in Annex B. 4. This MIME part contains other binary file data using any of the formats acceptable for facsimile. 5. Where possible the content types for binary files should be the same as those already existing. Where no suitable content type exists it will be necessary to apply for a new content type after consultation with the IETF. This paragraph needs detailed specification of the alignment between BFT and MIME types.) 6. Binary file parts and image data parts may be interleaved in any order. 6.3 Message headers Message headers are the same as for Basic Internet fax. 7. Confirmation of receipt Senders of facsimile store and forward may request delivery confirmation. Existing Internet mail Delivery Service Notification (DSN) (Reference 19, 20) mechanisms shall be used. Facsimile store and forward recipients which receive a DSN request must return a delivery service notice, upon successful delivery of the facsimile. For the purposes of facsimile store and forward relay devices, the DSN shall be issued upon receipt of the confirmation message from the target facsimile station. For the purposes of Internet mail recipients, the DSN shall be issued according the standard rules specified for DSNs. 8. Exchange of capabilities Facsimile store and forward participants may wish to communicate their capabilities prior to sending a facsimile. A special MIME Content-Type is defined for this purpose, in place of the Image Data MIME body-part present in a facsimile message. In all other respects the capabilities message shall conform to requirements for Simple or Basic Internet Facsimile. The sending system must make use of the "Capabilities Request" message type to obtain the capabilities of the recipient. This can be done as part of a first facsimile transmission or as a special transmission using the ITU header alone with no image or binary data. The sending system should store the recipient's capabilities for use during future transmissions. The sender of any message using the procedures defined in this Recommendation shall be free to use any valid facsimile capabilities during its first call to other equipment. If the receiving equipment can process the data transmitted it will send back an acknowledgement of successful reception otherwise it will send back an acknowledgement indicating "Capabilities mismatch". 8.1 MIME label for exchange of capabilities body part The MIME label is: Content-Type: application/fax-poll (NB: this section may also be expressed in ASN.1 notation following an editorial update from those desiring such notation): The MIME label is: Content-Type:application/fax-capabilities 8.2 Format of exchange of capabilities body-part The Application/Fax-Capabilities MIME part contains the following data (NB: this section may also be expressed in ASN.1 notation following an editorial update from those desiring such notation): 3/T.IFax: Exchange of Capabilities Body-Part Description Mandato Repeata Field ry ble Type DIS: G3 sender's Yes1 No X"09" capabilities TSI: G3 sender's No No X"0A" facsimile number NSF: G3 NSF signal No No X"0B" NSS: G3 NSS signal No No X"0C" NSC: G3 NSS signal No No X"0D" G4 capabilities Yes2 No X"12" Notes: 1 For Group 3 only 2 For Group 4 only All fields within the ITU header part have the following format: Field type Data length Data Field type (1 octet) Data length (2 octets: low octet/high octet order) Data (Of defined length) The desirability of an extension method for this format is to be studied and, if it is felt necessary, a method is to be added to this draft Recommendation. The following field types are allocated: 8.2.1 G3: Sender's capabilities This contains the contents of the T.30 DIS FIF. It is present in all messages and identifies the capabilities of the sender. 8.2.2 X"0A" G3: Sender's facsimile telephone number This contains the contents of the T.30 TSI FIF. 8.2.3 X"0B" G3: NSF signal This contains the contents of the T.30 NSF FIF. 8.2.4 X"0C" G3: NSS signal This contains the contents of the T.30 NSS FIF. 8.2.5 X"0D" G3: NSC signal This contains the contents of the T.30 NSC FIF. 8.2.6 G4 capabilities This contains Group 4 applications capability data as defined in T.563 Appendix II. The sender of any message using the procedures defined in this Recommendation shall be free to use any valid facsimile capabilities during its first call to other equipment. If the receiving equipment can process the data transmitted it will send back an acknowledgement of successful reception otherwise it will send back an acknowledgement indicating "Capabilities mismatch". 9. Facsimile polling Facsimile store and forward participants may wish to poll a destination facsimile station, to request return transmission of one or more fax documents. A special MIME Content-Type is defined for this purpose, in place of the Image Data MIME body- part present in a facsimile message. In all other respects the capabilities message shall conform to requirements for Simple or Basic Internet Facsimile. The sender of any message using the procedures defined in this Recommendation shall be free to request any facsimile document. If the receiving equipment can process the data transmitted it will send back the requested document(s); otherwise it will send back an acknowledgement indicating "Document(s) unavailable". 9.1 MIME label for Document-Retrieval body-part The MIME label is: Content-Type: application/fax-poll (NB: this section may also be expressed in ASN.1 notation following an editorial update from those desiring such notation): 9.2 Format of the Document-Retrieval body-part The ITU header MIME part contains the following data (NB: this section may also be expressed in ASN.1 notation following an editorial update from those desiring such notation): Table 2/T.IFax: ITU Header Format Description Mandato Repeata Field ry ble Type SEP: G3 selective No Yes X"0F" poll PWD: G3 password No Yes X"10" DTC: G3 polling No No X"11" request Notes: 1 Where known 2 For Group 3 only 3 For Group 4 only All fields within the ITU header part have the following format: Field type Data length Data Field type (1 octet) Data length (2 octets: low octet/high octet order) Data (Of defined length) The desirability of an extension method for this format is to be studied and, if it is felt necessary, a method is to be added to this draft Recommendation. The following field types are allocated: 9.2.1 X"0F" G3: Selective poll This contains the contents of the T.30 SEP FIF. 9.2.2 G3: Password This contains the contents of the T.30 PWD FIF. 9.2.3 G3: DTC This contains the contents of the T.30 DTC FIF. This is used for a non-selective poll or turnaround poll. Annex A: TIFF-F format (This annex forms an integral part of this Recommendation) Editorial consideration will be given to reconciling Annex A and Annex B. A.1 References, definitions and abbreviations IFD : Image File directory (See main body of this Recommendation for other references, definitions and abbreviations) A.2 TIFF (This annex forms an integral part of this Recommendation) Editorial consideration will be given to reconciling Annex A and Annex B. A.2.1 References, definitions and abbreviations TIFF: "The TIFF 6.0 specification dated June 3, 1992 specification © 1986-1988, 1992 Adobe Systems Incorporated. All Rights Reserved" This Annex is not a complete definition of TIFF but is, instead, a use of a particular TIFF specification referenced. This annex includes a definition of an extension to TIFF to meet the requirements of facsimile. Under the terms of the letter dated September 19th 1997 from Adobe Systems Incorporated to the Director if the ITU-T Adobe grants a license to use the TIFF specification as the basis for an ITU Recommendation. Detailed terms are contained within the letter which is available from the ITU. (See main body of this Recommendation for other references, definitions and abbreviations) A.3 MIME labelling The email body part which contains the TIFF-F file shall be preceded by the following indicator. Content-type: Image/TIFF (specific type/subtype & parameter details need to be reconciled with IETF documents currently in Working Group Last Call.) TIFF creates binary data which shall may need MIME Content- Transfer-Encoding, such as Base64, for carriage through Internet mail relay systems. Hence is may be necessary to convert the binary data to MIME base64 format and to follow the Content-Type MIME header with: Content-Transfer-Encoding: base64 A.4 TIFF-F (This sub-section may be replaced by RFC citation, if the current IETF specification for TIFF-F is published in a sufficiently timely fashion.) In this section a minimum set of TIFF features is described. A.4.1 IFD and image data Flexibility of positioning IFD and image data in a TIFF data stream is constrained in the format defined in this annex. The three elements of a TIFF file: Header, IFD and Image data; shall appear as shown in Fig, Annex A.1/T.IFax. Header information shall be at the beginning of the file and IFD and Image data shall follow in pairs according to page order. A pair of IFD and Image data shall correspond to one page of the facsimile document. Fig. Annex A.1/T.IFax - Sequence of Header, IFD and image data The fixed values used in the Header field are described in Table Annex A-1/T.IFax. Table Annex A.1/T.IFax - Header Off Value set Descripti on 0 Byte 0x4949 Order 2 42 0x2A 4 Offset of 1st 0x00000 IFD 008 The structure of an IFD is described in Table Annex A.2/T.IFax along with coding samples.