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>@<appropriate offramp domain name>

       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: <destination number>#
      It is specified as follows when user authentication is necessary.

      <destination number> * <User ID>* <password>#

      Indirect address designation: * < indirect address number >#

      * < indirect address number > * <User ID> * <Password>#

      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.

   <destination number> * <user ID> * <password> #
   (*:separater #:terminater)

Mimura,                     Expires July 2000                     [Page8]
Internet Draft         Internet FAX Gateway Protocol             July 2000

   * < indirect address number > * <user ID> * <password> #
   (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.

   <desitination number> * < user ID> * <password> * <option number> #
   * < indirect address number > * < user ID> * <password> * <option number>#
   <desitination number> * <option number> #
   * < indirect address number > * <option number> #

   example
   8155551234*23456*876*015# is detected by DTMF
   Destination facsimile number : 8155551234
   user ID : 23456
   password : 9876
   Option number : 015
                   (for example , It is interpreted with the requirement
                   of transmitting after five hours.)




4.8 return notice


   When it has a function that receives and analyzes return notice from
   destination,
   Onramp gateway MAY send delivery status to suitable facsimile device user
   on GSTN.
   This function is used in accordance with the 5.4 user authentication.
   In order to put into practice this function, it is necessary to SMTP
   receiver MTA on onramp gateway.




4.9 Multicasts transmit request


   Onramp gateway can specify destination of maximum 99 by specifying it in
   To: or c: field by 1 mail.
   But, destination beyond 100 SHULD NOT be specified in 1 mail.
   And, address SHOULD NOT be specified whit BCC:.
   How to specify address in this case it SHOULD be indirect address
   designation (5.2 2).
   An onramp gateway that has the function which takes out a transmitting
   request beyond 100 address at the same time by 5.2(2) indirect address
   designation, SHOULD have the function which transmits the mail of the

Mimura,                     Expires July 2000                    [Page10]
Internet Draft         Internet FAX Gateway Protocol             July 2000

   necessary number by dividing the number of the addresses of 1 mail by the
   maximum 99 address, when a transmitting request beyond 100 address is
   taken.

   example
   When the transmitting requirement of 1000 address is taken out by the
   indirect address designation.

   The 10 mail of 99 address and 1 mail of 10 addresses is transmitted.
   (99*10 + 10*1=1000)
   Because the problem of traffic occurs, 1000 mail of 1 address isn't
   encouraged to transmit in this paper.
   (For example, the thing when it has 1000 huge Tiff files transmitted is
   presumed.)






5. Security Considerations


   The Security Considerations sections of [RFC2305] applies to this
   document.






6. Acknowledgments


   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement
             Levels", RFC 2119, March 1997.

   [RFC2305] Toyoda, K., Ohno, H., Murai, J. and  D. Wing, "A Simple Mode
             of Facsimile Using Internet Mail", RFC 2305, March 1998.


















Mimura,                     Expires July 2000                    [Page11]
Internet Draft         Internet FAX Gateway Protocol             July 2000


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 July 2000                    [Page12]
Internet Draft         Internet FAX Gateway Protocol             July 2000


8. Contact


   K.Mimura
   TOYO Communication Equipment CO., LTD.
   2-1-1 Koyato, Samukawa-machi, Koza-gun
   Kanagawa-pref., Japan
   Fax: +81 467 74 3934
   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 3934
   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 3934
   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 3934
   Email: kanaide@toyocom.co.jp
























Mimura,                     Expires July 2000                    [Page13]