INTERNET-DRAFT Protocol for Terminal Mode 14 February 2001 IETF fax WG Toru Maeda, CANON Inc. Internet draft 14 February 2001 Expires: August 2001 Protocol for Terminal Mode 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. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C) The Internet Society 2000. All Rights Reserved. Abstract This proposal describes a protocol which was proposed in ITU-T SG16 meeting on November 2000 at Geneva, for Terminal Mode. The Terminal Mode supports the transfer of image data, capabilities exchange and confirmation for Store and Forward internet fax terminals having limited memory and small CPU power. Terminal Mode also supports all features of Group 3 facsimile on the Internet using T.30 signals in capability exchange. Maeda ü@ü@ü@ Internet draft [Page 1] INTERNET-DRAFT Protocol for Terminal Mode 14 February 2001 NOTE: This is an early, preliminary version of specification, indicating a possible way to achieve the protocol for Terminal Mode Internet fax. The content is rough, and the intent at this time is to indicate the outline of a mechanism. Please address comments to major structural and semantic issues. Discussion of this document Please send comments to: . To subscribe: send a message with the body 'subscribe' to . The mailing list archive is at: . Table of contents 1. Abstract.................................................3 2. Discussion...............................................3 3. Proposal.................................................4 4. Acknowledgements.........................................7 5. References................................. .............7 6. Authors' addresses...................... . ..............7 Full copyright statement....................................8 Maeda ü@ü@ü@ Internet draft [Page 2] INTERNET-DRAFT Protocol for Terminal Mode 14 February 2001 1. ABSTRACT T.37 Terminal Mode was proposed in Q4/8 Rapporteur's meeting at Gaithersburg on June 2000. The Terminal Mode supports the transfer of image data, capabilities exchange and confirmation for Store and Forward internet fax terminals having limited memory and small CPU power. Terminal Mode also supports all features of Group 3 facsimile on the Internet using T.30 signals in capability exchange. The proposal is updated version of Terminal Mode which is revised based on the results of the discussion at Gaithersburg. 2. Discussion T.37 Terminal Mode which supports the transfer of image data, capabilities exchange and confirmation for Store and Forward internet fax terminals having limited memory and small CPU power, was proposed in Q.4 Rapportures meeting on June 2000. The Terminal Mode extents Internet fax capabilities to enable all features of Group 3 facsimile to be supported on the Internet using T.30 signals in capability exchange. (1) Confirmation Mandatory MDN response, notification of success/failure of document processing and page by page status. (2) Capabilities exchange Support capabilities expression to enable G3FAX features using T.30 signals, and enable all features of Group 3 facsimile on the Internet. (3) Easy implementation for embedded fax terminal based on G3FAX system There were technical issues at the Gaithersburg meeting, the document describes solutions as follows. (1) requirements of DCS DCS may be used for double sided printing. ü@ (2) possibility of deletion of new header by MTA Some MTA may delete the new headers for Terminal Mode or MDN/DSN message by setting under some MTA management reason. It is required to send communication to IETF that it is requested to people operating MTA, that MTA will not delete the new headers and MDN/DSN message during mail transfer for Internet Fax Terminal Mode. (3) email text of polling message using DTC At polling, the polling requester may not put any text message, the sender must process the TIFF multipart without text part in Internet fax Terminal Mode. Maeda ü@ü@ü@ Internet draft [Page 3] INTERNET-DRAFT Protocol for Terminal Mode 14 February 2001 (4) response email to polling request. At polling, the sender sends a mail with MDN responding polling request, image and MDN request, the recipient must process the received mail with MDN, image data and MDN request in Internet fax Terminal Mode. There will be no MDN loop because of using DTC and DCS signals within the message. (5) The new header is required to register to IANA The headers will be registered to IANA under the registration procedure in RFC2434. In IETF WG's history, it is difficult to include fax-specific information in MDN and DSN for Internet fax Simple Mode and EIFAX. Because there are lots of applications based upon mail standard. Terminal Mode communicates only to the terminal working in Internet FAX Terminal Mode but not to an e-mail client which does not support Internet FAX Terminal Mode. Messages defined for Terminal Mode should not be send to the email client not working in Internet fax Terminal Mode, so it is able to use fax-specific information in MDN and DSN for Terminal Mode. 3. Proposal Proposed Amendment to ITU-T Recommendation T.37 for Terminal Mode Summary This amendment adds support for the Terminal Mode of Internet fax to Recommendation T.37. The additional functionality includes support for the transmission and reception of additional TIFF image formats, capabilities exchange and acknowledgement of receipt for small memory IFAX devices. 1) Add Section 6.x Terminal Mode : Sec. 6.x Terminal Mode Terminal Mode supports the transfer of image data, capabilities exchange and acknowledgement of receipt for small memory IFAX devices, per the requirements of Recommendation F.185. Sec. 6.x.1 Procedures for Terminal Mode Procedures for Terminal Mode are defined in section 6.x.2 and 6.x.3, unless stated otherwise in Table X. A functional summary and related references for Terminal Mode are included in the table. Maeda ü@ü@ü@ Internet draft [Page 4] INTERNET-DRAFT Protocol for Terminal Mode 14 February 2001 Table x/T.37 Functional summary of procedures for Terminal mode +----------------+-----------------------------------------------------+ |Addressing | Procedures: RFC 2305 Section 3 | | | Email: RFC 822 | | | Offramp: RFC 2303, RFC 2304 | +----------------+-----------------------------------------------------+ |Image format | TIFF Profiles: RFC 2301 | +----------------+-----------------------------------------------------+ |Acknowledgement | Delivery Confirmation: RFC 1891, Delivery Status | |of receipt | Notification (DSN) | | | Processing Confirmation: RFC 2298, Message | | | Disposition Notification (MDN)| | | and T.37 Section 6.x.4 | +----------------+-----------------------------------------------------+ |Capabilities | Capabilities Format: T.37 Section 6.x.3 | |exchange | Capabilities Mechanism: T.37 Section 6.x.2 | +----------------+-----------------------------------------------------+ |Transport | ESMTP: RFC 1869 | +----------------+-----------------------------------------------------+ |Mailbox Access | POP3: RFC 1939 IMAP4: RFC 2060 | +----------------+-----------------------------------------------------+ Sec. 6.x.2 Capabilities Mechanism for Terminal Mode To send capabilities from recipient and to send capabilities and commands from transmitter, the new header is defined. Capabilities of the transmitter are expressed as DIS signal and others, and commands to the recipient are expressed DCS signals and others. To implement polling, DTC signals and others are used. Signals and meaning of FIF bits in Terminal Mode are identical to G3FAX. fax-features = "Fax-T30-Features" ":" t30-signal-tags The are defined in Section 6.X.3. Sec. 6.x.3 Capabilities Format for Terminal Mode The t30-signal-tags syntax to send recipient capabilities and transmitters capabilities, commands and polling request in Terminal Mode is defined as follows. t30-signal-tags = t30-parameter *( ";" t30-parameter ) t30-parameter = t30-fcf "=" t30-fif t30-fcf = "NSF" / "CIS" / "DIS" / "TSI" / "SUB" / "SID" / "DCS" / "NSS" / "CSI" / "SEP" / "PWD" / "DTC" / "NSC" / extent-fcf t30-fif = 1*hexchar hexchar = 2*2xchar xchar = hexadecimal digits extent-fcf = Maeda ü@ü@ü@ Internet draft [Page 5] INTERNET-DRAFT Protocol for Terminal Mode 14 February 2001 t30-parameter; Value of t30-fif is the FIF corresponding to FCF in T.30. FIF is expressed in hex decimal expression of Octets instead of bit string in T.30. First Octet placed left end. LSB in the Octet is the first transmitting FIF bit in T.30. note: RFC 2045 defines; extent-fcf = token token := 1* Sec. 6.x.3.1 Capabilities Format for Recipient Value of t30-fcf is the name of FCF defined in T.30 such as NSF, CSI, and/or DIS. Sec. 6.x.3.2 Command and Capabilities Format for Transmitter Value of t30-fcf is the name of FCF defined in T.30 such as NSS, TSI, SUB, SID, DCS, NSF, CSI, DIS, NSC, CIS, SEP, PWD and/or DTC. Note: (1) DCS will be used for transmitting senders command such as double side printing. (2) Some MTA may delete the new headers or MDN/DSN message. It is strongly requested to people operating MTA, that MTA will not delete the new headers and MDN/DSN message during mail transfer for Internet Fax Terminal Mode. (3) At polling, the polling requester may not put text message, the sender must ignore the text message when the requester send it. (4) At polling, the sender sends a mail with MDN responding polling request, image and MDN request, the recipient must process the received mail with MDN, image data and MDN request in Internet fax Terminal Mode. (5) These headers defined in the section will be registered to IANA under the registration procedure written in RFC2434. Sec. 6.x.4 Fax processing confirmation for Terminal Mode The recipient must response MDN request in Terminal Mode. MDN extension field: Fax-Report: Fax-Results = code ; Fax-Pages = received page number ; Fax-Errorpage = error page number Maeda ü@ü@ü@ Internet draft [Page 6] INTERNET-DRAFT Protocol for Terminal Mode 14 February 2001 Note: (1) The field defined in the section will be registered to IANA under the registration procedure written in RFC2434. 4. Acknowledgements The author would like to thank the ITU-T old SG8 members and the ITU-T new SG16 members for their contributions. 5. References [1] T.37 Procedure for the transfer of facsimile data via store-and-forward on the Internet [2] T.37 Amendment 1 Full Mode 6. Authors' addresses Toru Maeda CANON Inc. 3-30-2 Shimomaruko, Ohtaku,Tokyo Japan Telephone: +81 3 3758 2111 Facsimile: +81 3 3575 8205 E-mail: maeda.toru@canon.co.jo Maeda ü@ü@ü@ Internet draft [Page 7] INTERNET-DRAFT Protocol for Terminal Mode 14 February 2001 Full copyright statement Copyright (C) The Internet Society 2000. 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. Maeda ü@ü@ü@ Internet draft [Page 8]