Network Working Group K.Mimura Internet-Draft: draft-ietf-fax-gateway-protocol-05.txt K.Yokoyama T.Satoh C.Kanaide TOYO Communicaion Equipment June 28 2001 Internet FAX Gateway Functions Status Of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 obsolete 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. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract An Internet FAX Gateway provides functions which translate facsimile between the general switched telephone network (GSTN) the Internet. This document provides information on recommended behaviors for Mimura, Expires Dec 2001 [Page1] Internet Draft Internet FAX Gateway Functions June 2001 Internet FAX Gateways Functions for email-based Internet fax. In this context, an Offramp means facsimile data transmission to the GSTN from the Internet, and onramp means facsimile data transmission to Internet from the GSTN. This document covers the delivery-process of the data among equipment which may include Internet Fax terminals, PCs on the Internet and FAX terminal on GSTN. The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [RFC2119]. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights in . Table Of Contents 1. Introduction 2. Internet FAX Gateway Protocol 3. Offramp Gateway 3.1 Offramp functions 3.2 Addressing 3.2.1 example of local dialing rules 3.3 User authorization 3.4 Return notice 4. Onramp Gateway 4.1 Onramp Functions 4.2 Address designation 4.2.1 Immediate address designation 4.2.2 Indirect address designation 4.2.3 Support subaddress 4.3 Relay function 4.4 File format conversion 4.5 User authorization 4.6 Return notice 5. Security Considerations 6. References 7. Full Copyright Statement 8. Contact Mimura, Expires Dec 2001 [Page2] Internet Draft Internet FAX Gateway Functions June 2001 1. Introduction An Internet FAX Gateway plays a role of gateway between FAX operations built on the General Switched Telephone Network (GSTN) and the Internet. This document defines the potential behavior of devices and applications which serve this purpose. Gateways can be classified as an Onramp where facsimile data is translated from the GSTN to the Internet and as an Offramp, where facsimile data is translated from the Internet to the GSTN. A more detailed definition of onramps and offramps for email-based Internet fax is provided in [RFC2542]. Internet FAX Gateways functions for real-time Internet fax are defined in [T.38]. Scope of Internet FAX Gateway defined in this document is shown below. 1) A format of image data is a data format defined by "Simple Mode" in [RFC2305]. 2) Operational mode is "store and forward" defined in section 2.5 of [RFC2542] 2. Internet FAX Gateway Protocol There are two kinds of gateway functions, which are an onramp gateway and offramp gateway. An onramp gateway receives facsimile data from a facsimile device over the GSTN, then sends the facsimile data to an Internet fax capable device or application. An offramp gateway receives Internet FAX from Internet fax capable devices which may include an onramp gateway and PC over Internet, then sends facsimile data to facsimile device over GSTN. In both case described above, facsimile communication between a gateway and the Internet is based on [RFC2305]. Protocols which are discussed in this document are shown below, and other communication protocol should be referred in RFC2305. 1) Communication protocol between onramp gateway and GSTN. 2) Communication protocol between offramp gateway and GSTN. Mimura, Expires Dec 2001 [Page3] Internet Draft Internet FAX Gateway Functions June 2001 3. Offramp Gateway 3.1 Offramp functions An offramp gateway provides a translation function, such that the offramp gateway receives an Internet FAX and then send facsimile data to the facsimile devices over GSTN using a standard facsmile protocol [T.30]. The Communication protocol between the offramp gateway and the submitting Internet fax device will be based on RFC 2305 for standards-based store and forward operations. 3.2 Addressing An offramp gateway MUST process the mailbox string and convert it to a "local-phone" according to the local dialing rules. 3.2.1 example of local dialing rules This example is an offramp gateway change from "global-phone" to "local-phone" by removing "+" and international country code. If an offramp gateway receive next "global-phone". +12223334444 "local-phone" is the string remove "+",international country code "1" from "global-phone". "local-phone" is 2223334444 Next example is an offramp gateway change from "global-phone" to "local-phone" by removing "+" and international country code then "exit-code" "0"is put at head. If an offramp gateway receive next "global-phone". +81355556666 "local-phone" is the string remove "+",international country code "81" then "exit-code" "0" is put at head from "global-phone" "local-phone" is 0355556666 Mimura, Expires Dec 2001 [Page4] Internet Draft Internet FAX Gateway Functions June 2001 "global-phone" defined in section 2. of [RFC2304] "local-phone" defined in section 2. of [RFC2846] "exit-code" defined in section 2.1 of [RFC2846] 3.3 User authorization Offramp gateway MAY have a user authorization function to confirm that they are the data that suitable user transmitted. The example of the user authorization function at the time of Offramp gateway is shown below. 1) Encipherment of user authorization and facsimile data is performed by the existing SMTP, such as S/MIME and X-Header, using the possible security technique. 2) The distribution demand from the user who permitted use of the Internet Fax Gateway is received using the user authorization function and E-mail transmitting function of WWW. 3.4 Return notice An offramp gateway MUST have the function which the offramp gateway send return notice to the source IFAX device, when a transmitting error occurred then finished with the facsimile data not transmitted. When the offramp gateway fails in transmission of the return notice, The error information MAY be recorded to a log and processing MAY be ended, or the administrator of a gateway system MAY be notified of these errors information with a certain means (for example, SMTP). Mimura, Expires Dec 2001 [Page5] Internet Draft Internet FAX Gateway Functions June 2001 4. Onramp Gateway 4.1 Onramp Functions An onramp gateway MUST have the function that the onramp gateway receive facsimile data from facsimile device over GSTN, then generated Internet fax is sent to appropriate IFAX devices or PC by the onramp gateway. How to transmit data from an onramp gateway to IFAX devices MUST based on RFC 2305. 4.2 Address designation An onramp gateway SHOULD have the function that onramp gateway analyze destination address from address data sent by facsimile device over GSTN. There are two kinds of the next of address data from FAX device over GSTN. 4.2.1 Immediate address designation Address data from facsimile device over GSTN specify destination number directly. It is used when destination is specified every time. Example (1) An onramp gateway receive destination telephone number "12223334444" from source facsimile by DTMF. 12223334444 (2) Destination number is used as "global-phone", "+" is added before it. +12223334444 (3) "FAX=" is added at the head of "global-phone" to change "global-phone" into "fax-mbox". FAX=+12223334444 (4) With this example "fax-mbox" is used as "fax-address". "Fax-email" is made by adding "@" and appropriate offramp domain "mta-I-fax" behind "fax-address". Mimura, Expires Dec 2001 [Page6] Internet Draft Internet FAX Gateway Functions June 2001 FAX=+12223334444@offdomain.com As for the way of choosing domain name of offramp gateway, it is defined in 4.3 Relay function. "global-phone" "fax-mbox" "fax-address" defined in section 2.of [RFC2304] "mta-I-fax" defined in section 3. of [RFC2304] "fax-email" defined in section 4. of [RFC2304] 4.2.2 Indirect address designation Indirect address number is extracted from the address data from facsimile device on GSTN, and destination address is looked up with an onramp gateway by using the address change table and so on from the indirect address number. This function is used in the case of transmission to the mail terminal, transmission to an address to use it well, the multicast transmission and so on. An onramp Gateway holds indirect address information by itself. Or, it is acquired from another server. Indirect address information contains following information. - Indirect address number - The list of the destination facsimile number and the E-mail address looked up from the indirect address number. Example (1) An onramp gateway receive Indirect address number "1234" from source facsimile by DTMF. 1234 (2) Destination address "addr-spec" is looked up by using the address change table. address change table 1234 : ifax@ifdomain.com (3) Internet FAX is sent to an Internet FAX device "ifax@ifdomain.com" by an onramp gateway. "addr-spec" defined in section 6.1 of [RFC822] Mimura, Expires Dec 2001 [Page7] Internet Draft Internet FAX Gateway Functions June 2001 4.2.3 Support subaddress An onramp gateway SHOULD supports subaddress. In the case of immediate address designation, subaddress is analyzed by using [T.33] protocol. In the case of indirect address designation, T.33 protocol is not used. Subaddress is looked up by using the address change table and so on from the indirect address number. 4.3 Relay function Onramp gateway SHOULD have the function which chooses destination offramp gateway by analyzing a specified destination facsimile number. Onramp gateway SHOULD hold relay information of offramp gateway to realize this function. Onramp gateway holds the following Offramp gateway relay information. or, acquires from other server. - Area number (ex. +81:Japan +813:Tokyo etc) - Domain name of offramp gateway which copes with an area number Example of offramp gateway relay information +81 is sent to offramp gateway domain name is offjpn.domain.co.jp +1 is sent to offramp gateway domain name is offus.domain.com 4.4 File format conversion An onramp gateway MUST counvert file format from an facsimile over GSTN to file format TIFF Profile-S for Internet Fax defined in [RFC2301]. 4.5 User authorization Onramp gateway MAY have a user authorization function to confirm that they are the data that suitable user transmitted. For example, User authorization is done by using user ID, password extracted from DTMF (Dual Tone Multi Frequency). Mimura, Expires Dec 2001 [Page8] Internet Draft Internet FAX Gateway Functions June 2001 4.6 Return notice When an onramp gateway receives and analyzes return notice from destination, an onramp gateway MAY have the means that delivery status is sent to suitable facsimile device user on GSTN through the appropriate offramp gateway. When an onramp gateway fails in transmission of the return notice, The error information MAY be recorded to a log and processing MAY be ended, or the administrator of a gateway system MAY be notified of these errors information with a certain means (for example, SMTP). 5. Security Considerations Offramp and Onramp gateway MAY have a user authorization function to confirm that they are the data that suitable user transmitted. Encryption of facsimile data is performed by the existing SMTP, such as S/MIME, using the possible security technique. The Security Considerations sections of [RFC2305] applies to this document. Further security considerations are introduced by this document, but they will be described in this section prior to pulication as an RFC. 6. References [RFC822] Crocker, D., " Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2301] L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J. Rafferty, "File Format for Internet Fax",RFC2301, March 1998 [RFC2304] C. Allocchio.,"Minimal FAX address format in Internet Mail" , RFC 2304, March 1998. [RFC2305] Toyoda, K., Ohno, H., Murai, J. and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 2305, March 1998. [RFC2542] L. Masinter, "Terminology and Goals for Internet Fax", RFC 2542, March 1999. Mimura, Expires Dec 2001 [Page9] Internet Draft Internet FAX Gateway Functions June 2001 [RFC2846] C. Allocchio "GSTN Address Element Extensions in E-mail Services",RFC 2846, June 2000. [T.30] "Procedures for document facsimile transmission in the general switched telephone network", ITU-T Recommendation T.30, April 1999. [T.33] "Facsimile routing utilizing the subaddress" ITU recommendation T.33, July, 1996. [T.38] "Procedures for real-time Group 3 facsimile communication over IP networks", ITU-T Recommendation T.38, June, 1998. 7. 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. Mimura, Expires Dec 2001 [Page10] Internet Draft Internet FAX Gateway Functions June 2001 8. Contact K.Mimura TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa-pref., Japan Fax: +81 467 74 5743 Email: mimu@toyocom.co.jp K.Yokoyama TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa-pref., Japan Fax: +81 467 74 5743 Email: k1@toyocom.co.jp T.Satoh TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa-pref., Japan Fax: +81 467 74 5743 Email: zsatou@toyocom.co.jp C.Kanaide TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa-pref., Japan Fax: +81 467 74 5743 Email: kanaide@toyocom.co.jp Mimura, Expires Dec 2001 [Page11] Internet Draft Internet FAX Gateway Functions June 2001 Revision history [[[RFC editor: Please remove this section on publication]]] 00a 10-Jul-2000 Initial draft. 01a 16-Aug-2000 Remove next section. Authentication Authentication toward Offramp gateway Option function Multicasts transmit request Rename next section to Relay function from Choice of Offramp gateway to User authorization from User authentication to Immediate address designation from Direct address designation Section Drop the duplicate mail was moved to a part of the section Offramp functions. Corrections and clarifications. 02a 30-Oct-2000 Title is changed from Internet FAX Gateway Protodol to Internet FAX Gateway Functions Remove next definition. Drop duplications for Broadcast When send return notice Automatic re-transmission keep log for offramp gateway Example of User authorization keep log for onramp gateway Rebuild next definition 3.2 Addressing 3.2.1 example of local dialing rules 4.2.1 Immediate address designation 4.2.2 Indirect address designation 4.4 File format conversion 03a 21-Feb-2001 Rebuild next definition 1. 1) 3.4 Return notice 4.6 Return notice Add next definition 3.3 User authorization 04a 22-May-2001 Rebuild next definition 3.4 Return notice 4.6 Return notice 5. Security Considerations 05a 28-June-2001 Rebuild next definition Abstract 1. Introduction 4.2 Address designation Add to References [T.38] Mimura, Expires Dec 2001 [Page12]