[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 4161

Network Working Group                                          K.Mimura
Internet-Draft: draft-ietf-fax-gateway-options-06.txt        K.Yokoyama
Intended Category: Informational                                T.Satoh
                                                             K.Watanabe
                                                              C.Kanaide
                                           TOYO Communication Equipment
                                                          April 14 2003



        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 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 (2003).  All Rights Reserved.

Abstract

   An Internet FAX Gateway provides functions which translate a
   facsimile between the general switched telephone network (GSTN) and
   the Internet. This document provides guidelines of optional services
   and examples of an Internet FAX Gateway, with respect to the onramp
   gateway and offramp gateway.

   This document does not intend to specify the actions to which the
   IFax offramp and onramp gateways (defined in [3]) conform.
   This document covers drop duplication, automatic re-transmission,
   error behavior, when sending a return notice, and the keep log for an
   offramp gateway. Also covered are examples of authorization by DTMF
   (Dual Tone Multi-Frequency) and the keep log for an onramp gateway.



Mimura, et. al.            Expires October 2003                  [Page1]

Internet Draft       Guideline of optional services           April 2003
                        for Internet FAX Gateway

Table Of Contents

1. Introduction
1.1 Key words
1.2 Intellectual property
2. Optional Services for an Offramp Gateway
2.1 Drop duplications
2.2 Automatic re-transmission in the occurrence of a delivery error
2.3 Error behavior
2.4 When sending a return notice
2.5 When a transmitting error occurs in a return notice
2.6 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. Author's Address

1. Introduction

   An Internet FAX Gateway can be classified as an offramp gateway and
   onramp gateway. This document provides information on the guidelines
   of optional services and examples of an Internet FAX Gateway. This
   document covers drop duplication, automatic re-transmission, error
   behavior, when sending a return notice, and the keep log for an
   offramp gateway. Also included are examples of authorization by DTMF
   and the keep log for an onramp gateway. A more detailed definition of
   onramps and offramps is provided in [1].

   Information on recommended behaviors for Internet FAX Gateway
   functions are defined in [2].

   The scope of the Internet FAX Gateway defined in this document is
   shown below.

   1) The format of image data is a data format defined by "simple mode"
      in [3].
   2) The operational mode is "store and forward," as defined in Section
      2.5 of [1].

1.1 Key words
   The key words "SHOULD" and "MAY" in this document are to be
   interpreted as described in [4].

1.2 Intellectual property
   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

Mimura, et. al.            Expires October 2003                  [Page2]

Internet Draft       Guideline of optional services           April 2003
                        for Internet FAX Gateway

   rights at <http://www.ietf.org/ipr.html>.

2. Optional Services for an Offramp Gateway

2.1 Drop duplications
   Sometimes overlapped mail is received by an offramp gateway. In such
   cases the offramp gateway is required to drop the overlapped mail.
   The purpose of this is to prevent the offramp gateway from
   transmitting the overlapped facsimile data to a facsimile device over
   the GSTN.

   For example, an MTA (Mail Transfer Agent) is set so that it puts mail
   with a different destination address in one mailbox. Some kinds of
   MTAs copy mail (with the same contents) in one mailbox when the MTA
   receives broadcast mail (mail of more than one destination address).
   Then, the offramp gateway uses POP to receive the mail from the MTA.
   As a result, the offramp gateway receives duplicate mail from the
   MTA.

   Discussion of the duplicate message detection mechanism is entrusted
   to other documents.

2.2 Automatic re-transmission in the occurrence of a delivery error
   An offramp gateway MAY add a function that automatically tries to
   send facsimile data again if delivery failure occurs. If this
   function is added, the retry times and retry interval MAY be
   specified as options by the administrator of the offramp gateway.

   If this function is set, a return notice SHOULD be sent only when the
   specified number of retries has been completed and the last facsimile
   transmission is an error. When transmission is suspended by the
   error, transmission is again started to send an error page on the
   next transmission.

   For example, assume that an offramp gateway is sending a total of
   five pages of facsimile data. But, an error occurs after two pages of
   normal transmission and the transmission is stopped. The offramp
   gateway should re-transmit the facsimile data, beginning with page 3.

2.3 Error behavior
   Retransmission behavior depends on the kinds of errors.

   In Calling Errors, such as a busy signal, line errors, and so on, the
   offramp gateway can perform retransmission.

   In Connecting Errors, such as a paper error, stop event error - but
   not a Fax error (voice response) - the offramp gateway sends a return
   notice to the sender without any retransmission.
   Thus, Calling Errors can probably be recovered, but Connecting errors
   can rarely be recovered.

Mimura, et. al.            Expires October 2003                  [Page3]

Internet Draft       Guideline of optional services           April 2003
                        for Internet FAX Gateway

2.4 When sending a return notice
   When an offramp gateway receives broadcast mail, there are two ways
   to send a return notice.

   1) An offramp gateway sends a return notice as soon as an error
      occurs.
   2) An offramp gateway sends a return notice after every completion of
      the specified number of transmissions.

   These features should be options selected by the user.

   Example

   The source user is requested to send one facsimile data to 20,000
   addresses, but encounters many errors for more than 1,000 addresses.

   If an offramp gateway sends a return notice as soon as an error
   occurs, the source user would receive more than 1,000 return notices
   from the offramp gateway. But, the source user can receive a return
   notice as soon as one error occurs.

   If the offramp gateway sends one return notice for every ten
   transmissions, the source user would receive only one-tenth of the
   return notices.

2.5 When a transmitting error occurs in a return notice
   When an offramp gateway fails in the transmission of a return notice,
   the Internet FAX Gateway SHOULD process the notice in either of the
   following ways.

   1) When the gateway has a log information preservation function, the
      error information SHOULD be recorded to a log, and processing
      SHOULD end. At this time, the administrator of the gateway system
      SHOULD be notified of these errors using a specific process (for
      example, SMTP).

   2) If the gateway does not have a log information preservation
      function, the administrator SHOULD be told about the failure, and
      processing SHOULD end.

   3) If the gateway has a high hardware capability and sufficient time
      margin, it is a beneficial service to perform the following
      processing. When notice of a result fails in transmission, the
      fixed time interval is vacated, and the output of the notice is
      repeated for a specified number of times. Even if the specified
      number of times continues to fail, the error information is
      recorded to a log, and processing is finished. Also, at this time,
      the administrator of the gateway system SHOULD be notified of
      these errors by a specific process (for example, SMTP).


Mimura, et. al.            Expires October 2003                  [Page4]

Internet Draft       Guideline of optional services           April 2003
                        for Internet FAX Gateway

2.6 Keep log
   An offramp gateway MAY have a function which keeps the information
   listed below as a log. For security and message traces, the Internet
   FAX Gateway MAY use the following format for a system log or event
   log of the Operation System.

   - Date and time when transmit request is received
   - Source address
   - Destination address
   - Date and time when transmitted over the GSTN
   - Date and time when transmission over the GSTN was finished
   - Number of real transmitted pages
   - Byte count of transmitted data
   - Type of data (resolution)
   - Occurrence of errors
   - Number of retries automatically sent
   - Date and time of transmission of delivery notice

   The goal of the log information preservation function is mainly to
   improve security or charge calculation processing.

   When the hardware system is equipped with recording media (HDD, FDD,
   etc.), the log information SHOULD be saved as a log file.

   The following are three opportunities to save log information.

   1) When an offramp gateway receives a distribution demand.
   2) When an offramp gateway starts distribution.
   3) When an offramp gateway ends distribution.

   When the hardware system does not use a recording medium, log
   information cannot be saved locally. In this case, it is desirable
   to use the save function at other PCs using existing network
   communication means, such as a function to save log information as a
   file using Network File System, SMTP, SNMP, or the function to
   periodically print log information.

   To strengthen security, it is desirable to save log information in
   the Internet FAX Gateway using a database system.


3. Optional Services for an Onramp Gateway

3.1 Example of user authorization
   An onramp gateway MAY have a user authorization function to confirm
   that the user is authorized to transmit data. In the case of onramp
   action, there are many methods to send authentication information.
   The method chosen depends on the provider's services. Consequently,
   an example is not described.


Mimura, et. al.            Expires October 2003                  [Page5]

Internet Draft       Guideline of optional services           April 2003
                        for Internet FAX Gateway

3.2 Keep log
   An onramp gateway MAY have a function that keeps information as a
   log. For security and message traces, the Internet FAX gateway MAY
   use the following format of a system log or event log of the
   Operation System.

   - Date and time when transmission request was received
   - Source address
   - Destination address
   - Date and time of transmission over the GSTN
   - Date and time when transmission over the GSTN was finished
   - Date and time of transmission over the Internet
   - Number of real transmitted pages
   - Byte count of transmitted data
   - Type of data (resolution)
   - Occurrence of errors
   - Number of retries sent automatically
   - Date and time of transmission of delivery notice

   The purpose of the log information preservation function is mainly to
   improve security or charge calculation processing.

   When the hardware system is equipped with recording media (HDD, FDD,
   etc.), the log information SHOULD be saved as a log file.

   The following are three possible opportunities to save log
   information.

   1) When an onramp gateway receives a distribution demand.
   2) When an onramp gateway starts distribution.
   3) When an onramp gateway ends distribution.

   When a hardware system without a recording medium is used, log
   information cannot be saved locally. In this case, it is desirable to
   use a function that saves at other PCs using existing network
   communication means, such as a function to save log information as a
   file using Network File System, SMTP, SNMP, or a function that
   periodically prints log information.

   In order to strengthen security, it is desirable to save log
   information in the Internet FAX Gateway using a database system.

4. Security Considerations

   An offramp and onramp gateway MAY have a user authorization function
   to confirm that they are authorized to transmit facsimile data.
   Encryption of facsimile data could be performed by the existing SMTP,
   using an available security technique.

   The security consideration sections of [3] apply to this document.

Mimura, et. al.            Expires October 2003                  [Page6]

Internet Draft       Guideline of optional services           April 2003
                        for Internet FAX Gateway

5. References

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

   [2] K. Mimura, K. Yokoyama, T. Satoh, C. Kanaide, "Internet FAX
       Gateway Functions", draft-ietf-fax-gateway-protocol-09.txt, April
       2003.

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

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


6. Full Copyright Statement

   Copyright (C) The Internet Society (2003). 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, et. al.            Expires October 2003                  [Page7]

Internet Draft       Guideline of optional services           April 2003
                        for Internet FAX Gateway

7. Author's Address

   Katsuhiko Mimura
   TOYO Communication Equipment CO., LTD.
   2-1-1 Koyato, Samukawa-machi, Koza-gun
   Kanagawa, Japan
   Fax: +81 467 74 5743
   Email: mimu@macroware.co.jp

   Keiichi Yokoyama
   TOYO Communication Equipment CO., LTD.
   2-1-1 Koyato, Samukawa-machi, Koza-gun
   Kanagawa, Japan
   Fax: +81 467 74 5743
   Email: yokoyama@macroware.co.jp

   Takahisa Satoh
   TOYO Communication Equipment CO., LTD.
   2-1-1 Koyato, Samukawa-machi, Koza-gun
   Kanagawa, Japan
   Fax: +81 467 74 5743
   Email: zsatou@toyocom.co.jp

   Ken Watanabe
   TOYO Communication Equipment CO., LTD.
   2-1-1 Koyato, Samukawa-machi, Koza-gun
   Kanagawa, Japan
   Fax: +81 467 74 5743
   Email: knabe@toyocom.co.jp

   Chie Kanaide
   TOYO Communication Equipment CO., LTD.
   2-1-1 Koyato, Samukawa-machi, Koza-gun
   Kanagawa, Japan
   Fax: +81 467 74 5743
   Email: c-miwa@mail.nissan.co.jp

Revision history

00a  31-Oct-2000  Initial draft.
01a  21-Feb-2001 Rebuild next definition
                  2.6 keep log
                  3.2 keep log
                 Added next definition
                 2.5 When a transmitting error occurred in return notice
02a  22-May-2001  Rebuild next definition
                  2.6 keep log
                  3.2 keep log
                  4. Security Considerations


Mimura, et. al.            Expires October 2003                  [Page8]

Internet Draft       Guideline of optional services           April 2003
                        for Internet FAX Gateway

03a  28-June-2001 Rebuild next definition
                  3.1 Example of User authorization
04a  19-September-2001 Rebuild next definition
                  4. Security Considerations
4a   20-March-2002 Corrections and clarifications.
                   Dropped reference to RFC2119.
                   Moved Intellectual Property after section 1.
                   Fixed Security considerations.
4b   25-March-2002 Reword first paragraph of section 2.1
                   Arrange 5. References again.
06   14-April-2003 Corrections and clarifications.








































Mimura, et. al.            Expires October 2003                  [Page9]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/