Network Working Group K.Mimura Internet-Draft: draft-ietf-fax-gateway-protocol-00.txt K.Yokoyama T.Satoh C.Kanaide TOYO Communicaion Equipment July 2000 Internet FAX Gateway Protocol 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 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract An Internet FAX Gateway incorporates the facsimile on general switched telephone network (GSTN) into Internet by translating data and protocol between them. This document specifies an Internet FAX Gateway Protocol, especially describes behavior of offramp/onramp gateway making reference to neither authentication nor security, where offramp means facsimile data transmission to GSTN from Internet, and onramp means facsimile data transmission to Internet from GSTN. Behavior of offramp/onramp covers the delivery-process of the data among equipments including IFAX terminal, PC on Internet and FAX terminal on GSTN. Mimura, Expires July 2000 [Page1] Internet Draft Internet FAX Gateway Protocol July 2000 The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [RFC2119]. Table Of Contents 1. Introduction 2. Internet FAX Gateway Protocol 3. Offramp Gateway 3.1 Offramp functions 3.2 drop the duplicate mail 3.3 return notice 3.3.1 When send return notice 3.3.2 Automatic re-transmission in the delivery error occurrence 3.3.3 Information of return notice 3.4 Authentication 3.5 keep log 4. Onramp Gateway 4.1 Onramp Functions 4.2 Address designation 4.2.1 Support subaddress 4.3 Choice of Offramp gateway 4.4 User authentication 4.5 Authentication toward Offramp gateway 4.6 keep log 4.7 Option function 4.8 return notice 4.9 Multicasts transmit request 5. Security Considerations 6. Acknowledgments 7. Full Copyright Statement 8. Contact Mimura, Expires July 2000 [Page2] Internet Draft Internet FAX Gateway Protocol July 2000 1. Introduction An Internet FAX Gateway play a role of the gateway between FAX network built on GSTN and Internet. An Internet FAX Gateway Protocol is implemented for this purpose and is classified in offramp and onramp, where offramp means direction of transmission from Internt to GSTN and onramp means the opposite direction against offramp. In these protocols, there are 3 latent subjects as follows. 1) What is appropriate architecture to implement multicast function and how to notify the acknowledgement. 2) How to implement the function of automatic re-transmission when transmission error is occurred. 3) How to specify the destination address at onramp process. This document outlines offramp / onramp protocols, and also specifies how these protocols are correlated with 3 subjects described above. The solution on these problem is beyond the scope of this document. 2. Internet FAX Gateway Protocol To realize onramp and offramp, gateway needs two kind of gateway function, which is onramp gateway and offramp gateway. An onramp gateway receives facsimile data from facsimile device over GSTN, then send Internet FAX to IFAX and / or PC over Internet including offramp gateway. An offramp gateway receives Internet FAX from IFAX devices including onramp gateway and PC over Internet, then send facsimile data to facsimile device over GSTN. In both case described above, data communication between a gateway and 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. 3) Multicast, return notice 4) Offramp gateway automatically retry to send facsimile data when delivery failure Mimura, Expires July 2000 [Page3] Internet Draft Internet FAX Gateway Protocol July 2000 3. Offramp Gateway 3.1 Offramp functions An offramp gateway MUST have the function, that offramp gateway receive Internet FAX from IFAX devices include PC over Internet, then send facsimile data to the facsimile devices over GSTN. Communication protocol between offramp gateway and destination IFAX device MUST be based on RFC 2305. 3.2 drop the duplicate mail An offramp gateway MUST drop the duplicate mail by confirming whether Message-ID is the same as old one. This is to avoid the duplication of the transmission to same facsimile device over GSTN. 3.3 return notice An offramp gateway SHOULD 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. In order to put into practice this function, it is necessary to SMTP sender MTA on offramp gateway. 3.3.1 When send return notice Transmitting time to facsimile terminal over GSTN from offramp gateway changes by the case. Transmitting time changes by the performance of FAX and the circuit condition. It is important when to transmit return notice in the multi-cast transmission. When a onramp gateway received Internet FAX which specify multiple destination facsimile devices (multicast request), there are two methods to send return notice from the onramp gateway to the source IFAX device. The onramp gateway send return notice, when every time an error occurs. Or send return notice at the end together This SHOULD be able to select by user. In the 1st method, Sender can take in the timely Delivery reports in each 1 address from Offramp gateway. But the burst traffic is occurred when it has a lot of Errors. So, source user receives return notice of the number witch is equal to the number of the error. In the worst case, source user receives return notice of the number witch is the same as the number of the addresses. Mimura, Expires July 2000 [Page4] Internet Draft Internet FAX Gateway Protocol July 2000 In the 2nd method, the little traffic is occurred to be able to describe a lot of error in the one delivery report. But, Sender has to wait for take in the delivery report until a set of delivery is finished. This SHOULD be realized by using of draft-ietf-fax-content-negotiation-01.txt which specify ability exchange . 3.3.2 Automatic re-transmission in the delivery error occurrence An offramp gateway MAY add function, that the offramp gateway automatically retry and permit to send facsimile data when delivery failure. If this function is enabled, retry times and retry interval MAY be specified optionally by administrator of offramp gateway. This case, return notice SHOULD be sent only when last facsimile transmission is error after specified retry times are finished. When the Transmission is suspended by the Error, the Transmission is started to send at error page on Next transmission . 3.3.3 Information of return notice The following information must be contained at least in return notice. - Transmission start time - Destination dial - Number of total pages - Number of real transmitted page - Cause of error An offramp gateway adds the following information, when it have the function of automatically transmission retry. - number of retry times - Transmission retry start time 3.4 Authentication An offramp gateway SHOULD provide the authentication function to judge whether the received E-mail is sent by appropriate source IFAX device. How to certify is optional to use E-mail authentication system (S/MIME, Signature by PGP ,others) Mimura, Expires July 2000 [Page5] Internet Draft Internet FAX Gateway Protocol July 2000 3.5 keep log An offramp gateway MAY have the function which following information is kept as log. Each dataformat is free. - Date and time when transmit request received - Source address - Destination address - Date and time when transmit over GSTN - Date and time when transmission was finished over GSTN - Number of real transmitted page - Byte count of transmitted data - Kind of the data (resolution) - Existence of error occurrence - Numbers of automatically retry sending - Date and time of transmitting delivery notice 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. Sending to the device on Internet for E-mail data , the onramp gateway should set From field or Replay-To field for the following sentences. < the numbers of sender > @ < Domain name of onramp gateway > We can use for the Return notice from destination function by this setting. 4.2 Address designation An onramp gateway MUST 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. (1) Direct address designation Address data from facsimile device over GSTN specify destination telephone number directly. It is used when destination is specified every time. Mimura, Expires July 2000 [Page6] Internet Draft Internet FAX Gateway Protocol July 2000 An onlamp gateway is changed in address to use on the Internet by adding appropriate offramp domain name after specified facsimile number < specified facsimile number>@ As for the way of choosing domain name of offramp gateway, it is described for 5.3 choice of offramp gateway. (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 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 the mail terminal, transmission to an address to use it well, the multicast transmission and so on. Onramp Gateway holds indirect address information by itself. Or, it is acquired from another server. Indirect address information contains information on lowest and under. - Indirect address number - The list of the destination facsimile number and the E-mail address looked up from the indirect address number When user authentication is necessary, the next information is included, regardless of the direct address designation or the indirect address designation. - User ID - Password How to transfer address data makes DTMF (Dual Tone Multi Frequency) default. As for the data format, it follows the following format. # is used for the completion of the DTMF data. * is used for separator. * is used at the head in the case of the indirect address designation. Direct address designation: # It is specified as follows when user authentication is necessary. * * # Indirect address designation: * < indirect address number ># * < indirect address number > * * # Source facsimile number can be used for the user ID number A password number is at least four-digit progression, and must not contain #, *. Mimura, Expires July 2000 [Page7] Internet Draft Internet FAX Gateway Protocol July 2000 example 81355551234üö üF destination facsimile number 81355551234 *1234# : indirect address number 1234 *36*817476554*12345# : indirect address number 36, User ID 817476554, Password 12345 4.2.1 Support subaddress An onramp gateway SHOULD supports subaddress. In the case of direct 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 Choice of Offramp gateway Onramp gateway SHOULD have the function which chooses destination offramp gateway by analyzing a specified destination facsimile number. Onramp gateway SHOULD hold course information of offramp gateway to realize this function. Onramp gateway holds the following Offramp gateway course 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 course 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 (* of this case shows a progression of the option size.) (ex 81* : 81355551234, 81441117890, etc) 4.4 User authentication Onramp gateway should have a user authentication function to confirm that they are the data that suitable user transmitted. User authentication is done by using user ID, password extracted from DTMF (Dual Tone Multi Frequency). DTMF Data format is shown in the following. * * # (*:separater #:terminater) Mimura, Expires July 2000 [Page8] Internet Draft Internet FAX Gateway Protocol July 2000 * < indirect address number > * * # (fierst*:identify indirest address designation other*:separater #:terminater) example 8155551234*81467745523*98765# is detect by DTMF Each data are extracted as follows, and user authentication is done. Destination facsimile number : 8155551234 User ID : 81467745523 Password : 98765 4.5 Authentication toward Offramp gateway Onramp gateway should provide the function, which transmits necessary information to do authentication toward offramp gateway, when offramp request send. As for the authentication data of this case, the exchange ability method specified with draft-ietf-fax-content-negotiation-01.txt is delivered to Offramp gateway. But, it is not it until this limit when Onramp gateway and Offramp gateway are on the same machine. Necessary information is the following so that Offramp gateway may do authentication. - User ID - Password When a password is enciphered, the above two data are enciphered with a form to show in the following for security. At this time, the following information is given, too. - Encipherment form - public key 4.6 keep log An onramp gateway MAY have the function that following information is kept as log. Each data format is free. - date and time when transmit request received - source address - destination address - date and time when transmit over GSTN - date and time when transmission was finished over GSTN - date and time when transmission over Internet - number of real transmitted page - byte count of transmitted data Mimura, Expires July 2000 [Page9] Internet Draft Internet FAX Gateway Protocol July 2000 - kind of the data (resolution) - existence of error occurrence - number of automatically retry sending - date and time of transmitting delivery notice 4.7 Option function Onramp gateway can provide various option functions for facsimile device user on GSTN by adding an option number at the end of the DTMF data. A data format at this time is following either. * < user ID> * *