One document matched: draft-ietf-fax-gateway-options-00.txt

Network Working Group                                          K.Mimura
Internet-Draft: draft-ietf-fax-gateway-options-00 .txt       K.Yokoyama
Intended Category: Informational                                T.Satoh
                                                             K.Watanabe
                                                              C.Kanaide
                                            TOYO Communicaion Equipment
                                                            Oct 31 2000



        Guideline of optional services for Internet FAX Gateway



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 provides functions which translate facsimile
   between the general switched telephone network (GSTN) the Internet.
   This document provides information on guideline of optional services
   and some examples for an Internet FAX Gateway classified as an onramp
   gateway and an offramp gateway.
   So this document does not intend to specify the actions that ifax offramp
   and onramp Gateways conform to.


Mimura,                     Expires Apr 2001                      [Page1]

Internet Draft       Guideline of optional services             Oct 2000
                        for Internet FAX Gateway


   This document covers Drop Duplication, Automatic re-transmission,
   Error Behavior, When send return notice, Keep log, for an offramp gateway.
   Example of authorization by DTMF, Keep log, for an onramp gateway.


   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 <http://www.ietf.org/ipr.html>.



Table Of Contents

1. Introduction
2. Optional services for an offramp gateway
2.1 Drop Duplications
2.2 Automatic re-transmission in the delivery error occurrence
2.3 Error Behavior
2.4 When send return notice
2.5 keep log
3. Optional services for an onramp Gateway
3.1 Example of User authorization
3.2 keep log
4. Security Considerations
5. References
6. Full Copyright Statement
7. Contact



1. Introduction

   An Internet FAX Gateway can be classified as an offramp gateway and an
   onramp gateway.
   This document provides information on guideline of optional services
   and some examples for Internet FAX Gateway.
   This document covers Drop Duplication, Automatic re-transmission,
   Error Behavior, When send return notice, Keep log, for an offramp gateway.
   Example of authorization by DTMF, Keep log, for an onramp gateway.

   A more detailed definition of onramps and offramps is provided in 
   [RFC2542].

   Information on recommended behaviors for Internet FAX Gateways Functions
   defined in [draft-ietf-fax-gateway-protocol-02].

Mimura,                     Expires Apr 2001                      [Page2]

Internet Draft       Guideline of optional services             Oct 2000
                        for Internet FAX Gateway


   Scope of Internet FAX Gateway defined in this document is shown
   below.

   1) Data mode is "simple mode" defined in [RFC2305]
   2) Operational mode is "store and forward" defined in [RFC2542]



2. Optional services for an offramp gateway


2.1 Drop Duplications

   By the case an offramp gateway detects dupulicate mail.
   Such the case an offramp gateway is required to drop the duplicate mail.
   This is to avoid the duplication of the transmission to same facsimile 
   device over GSTN.

   For example, an MTA is set to put the mail of the different address in 
   the same mail box. Some kinds of MTA copy same mail in one mailbox, when 
   MTA receives broadcast mail (mail of more than one destination address).
   Then an offramp gateway receives mail using POP from the MTA.
   As a result, the offramp gateway receives dupulicate mail from MTA.

   As for the duplicate message detection mechanism, it is entrusted to other
   documents.



2.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 .

   For example, an offramp gateway is sending total 5 pages facsimile data.
   But an error occurs and transmittion is stopped after 2 pages are sent
   normarry. The offramp gateway should re-transmit the facsimile data from
   page 3.






Mimura,                     Expires Apr 2001                      [Page3]

Internet Draft       Guideline of optional services             Oct 2000
                        for Internet FAX Gateway


2.3 Error Behavior

   Retransmission behavior depends on the kind the Errors.

   In Calling Errors, such as Busy, Line errors and so on.
   An offramp gateway do Retransmission.

   In Connecting Errors, such as Paper Error, Stop Event error,
   not FAX error (Voice Response).
   An offramp gateway send the Return notice to sender without any
   retransmission.

   That is why Calling Errors probably be recovered, but Connecting
   errors can hardly be recoverd.



2.4 When send return notice

   When an offramp gateway receives broadcast mail, there are two way to send
   return notice.
   An offramp gateway send return notice as soon as an error occurs.

   An offramp gateway send return notice at every finish of specified number 
   of transmissions.

   These features should be selectable by the user.



   EXAMPLE

   The source user requested to send to 20000 address, and had a lot of
   errors over 1000 address.

   If an offramp gateway send return notice as soon as an error occurs,
   the source user receive over 1000 return notice from an offramp 
   gateway. but, the source user can receive return notice as soon as
   error occurrence.

   If an offramp gateway send return notice every time transmission is 
   finished 10 times, the source user received return notice of 1/10
   of the number.







Mimura,                     Expires Apr 2001                      [Page4]

Internet Draft       Guideline of optional services             Oct 2000
                        for Internet FAX Gateway


2.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



3. Optional services for an onramp Gateway


3.1 Example of User authorization

   Onramp gateway MAY have a user authorization function to confirm that 
   they are the data that suitable user transmitted.

   Example of user "authorization" by "DTMF", GSTN user might send "user-ID",
   "password" data after destination "gstn-phone"
   (Dual Tone Multi Frequency).
   DTMF Data format is shown in the following.
   "*" is separater, "#" is terminater.
   gstn-phone defined in section 2 of [RFC2846].
   DTMF defined in section 2.1 of [RFC2846].

   authorization = 1*DTMF
   authorization = gstn-phone "*" user-ID "*" password "#"
   user-ID = 1*( DIGIT / "A" / "B" / "C" / "D" )
   password = 1*( DIGIT / "A" / "B" / "C" / "D" )

   example
   8155551234*81467745523*98765# is detect by DTMF
   Each data are extracted as follows, and user authorization is done.
   Destination facsimile number : 8155551234
   User ID : 81467745523
   Password : 98765


Mimura,                     Expires Apr 2001                      [Page5]

Internet Draft       Guideline of optional services             Oct 2000
                        for Internet FAX Gateway


3.2 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
   - kind of the data (resolution)
   - existence of error occurrence
   - number of automatically retry sending
   - date and time of transmitting delivery notice



4. Security Considerations

   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.



5. References 
     
   [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.

   [RFC2542] L. Masinter, "Terminology and Goals for Internet Fax", RFC 2542,
             March 1999.

   [RFC2846] C. Allocchio "GSTN Address Element Extensions in E-mail
             Services",RFC 2846, June 2000.

   [draft-ietf-fax-gateway-protocol-02] K.Mimura, K.Yokoyama, T.Satoh,
             C.Kanaide "Internet FAX Gateway Functions",
             Internet-Draft, Oct 30 2000



Mimura,                     Expires Apr 2001                      [Page6]

Internet Draft       Guideline of optional services             Oct 2000
                        for Internet FAX Gateway


6. 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 Apr 2001                     [Page7]

Internet Draft       Guideline of optional services             Oct 2000
                        for Internet FAX Gateway


7. 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

   K.Watanabe
   TOYO Communication Equipment CO., LTD.
   2-1-1 Koyato, Samukawa-machi, Koza-gun
   Kanagawa-pref., Japan
   Fax: +81 467 74 3934
   Email: knabe@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 Apr 2001                     [Page8]