view Side-By-Side changes

Network Working Group                                          K.Mimura
Internet-Draft: draft-ietf-fax-gateway-options-07.txt draft-ietf-fax-gateway-options-08.txt        K.Yokoyama
Intended Category: Informational
                                                                T.Satoh
                                                             K.Watanabe
                                                              C.Kanaide
                                           TOYO Communication Equipment
                                                          July 20 2004
                                                        January 21 2005


        Guideline of optional services for Internet FAX Gateway


Status Of This Memo
     
     This document is an Internet-Draft
     
   By submitting this Internet-Draft, we certify that any applicable   patent or other IPR claims of which we are aware have been
   disclosed, and is any of which I become aware will be disclosed, in full
     conformance 
   accordance with all provisions of Section 10 of RFC2026. RFC 3668.   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 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 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 (2004). (2005).  All Rights Reserved.


Abstract


   An Internet FAX Gateway provides functions which translate a
   facsimile?@between

   To allow connectivity between the general switched telephone network (GSTN)
   facsimile service (GSTN fax) and the Internet. e-mail based Internet Fax 
   service (i-fax) an "Internet FAX Gateway" is required. This document
   provides  guidelines of for the optional services
   and examples functionality of an Internet FAX Gateway, with respect 
   Gateways. In this context, an "offramp gateway" provides facsimile
   data transmission from  i-fax to the onramp
   gateway and offramp gateway.


   This GSTN fax; viceversa an "onramp
   gateway" provides data transmission form GSTN fax to i-fax. The 
   recommendations in this document does not intend apply to specify the actions to which integrated service 
   including Internet Fax terminals, computers with i-fax software on
   the
   IFax offramp Internet, and onramp gateways (defined in [3]) conform. GSTN Fax terminals on the GSTN.

   This document supplements the recommendation for minimal features
   of an Internet Fax Gateway. In particular it covers techniques to
   drop duplication, duplicated fax messages, automatic fax re-transmission,
   error behavior, when sending error,
   return notice, notice and the keep log for an
   offramp gateway. Also covered are examples of handling and possible authorization methods 
   by DTMF (Dual Tone Multi-Frequency) and the keep log for an onramp gateway.




Mimura, et. al.           Expires January 2005                 [Page1]


Internet Draft       Guideline of optional services           July 2004
                        for Internet FAX Gateway


Table Of Contents


1. Introduction
1.1 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 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
5.1 Informative groups
5.2 Normative groups
6. Full Copyright Statement
7. Contact gateways.


1. Introduction

   An Internet FAX Gateway can be classified as either an offramp 
   gateway and or an onramp gateway. This document provides information on the guidelines
   of 
   for optional services and examples of an Internet FAX Gateway. This
   document Gateway 
   operations. In particular it covers techniques to drop duplication, duplicated
   fax messages, automatic fax re-transmission, error
   behavior, when sending error, return notice, notice
   and the keep log for an offramp
   gateway. Also included are examples of handling and possible authorization methods by DTMF and the
   keep log (Dual
   Tone Multi-Frequency) for an onramp gateway.  gateways.

   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

   This document provides recommendations only for the specific case
   hereunder:

   1) the operational mode of the Internet FAX Gateway Fax is "store and forward",
      as defined in this document is
   shown below.


   1) Section 2.5 of [1].

   2) The format of image data is a the data format defined by "simple
      mode" in [3].
   2) The operational mode is "store and forward,"
 
   This document does not apply to the gateway functions for 
   "real-time Internet Fax", as described and defined in Section
      2.5 of [1]. [5].

1.1 Intellectual property Key words

   The IETF has been notified of intellectual property rights claimed key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in
   regard this
   document are to some or all of the specification contained be interpreted as described in this
   document. For more information, consult the online list of claimed
   rights at <http://www.ietf.org/ipr.html>.



Mimura, et. al.           Expires January 2005                 [Page2]


Internet Draft       Guideline of optional services           July 2004
                        for Internet FAX Gateway [4].

2. Optional Services for an Offramp Gateway

2.1 Drop duplications
   Sometimes overlapped duplicated GSTN fax transmission

   Electronic mail is received by transport agents (MTA) deliver an offramp gateway. In such
   cases Internet fax
   message either into the recipient's or an offramp gateway mailbox;
   hence the message is required to drop retrieved for further action, which in the overlapped mail.
   The purpose case 
   of this is the offramp gateway, will result in its delivery to prevent the GSTN fax 
   service.
   
   The offramp gateway from
   transmitting mailbox will thus receive all messages which
   the overlapped facsimile data to a facsimile device over gateway shall process, regardless of their final distinct GSTN
   destination. As such, addresses like

     Fax=+12224567654@example.com
     Fax=+38155234578@example.com
     Fax=+3904567437777@example.com

   will all end up into the GSTN.


   For example, an MTA (Mail Transfer Agent) is set so that it puts mail
   with a different destination address in one mailbox. When offramp gateway mailbox corresponding to
   the MTA
   receives broadcast mail (mail "example.com" domain. 

   The handling of e-mail messages (including Internet fax ones) 
   containing more than one destination address),
   some kinds of MTAs copy recipient, but directed to the mail same final
   MTA can however be different, depending on the MTA configuration or
   features: a single message with multiple recipients in one mailbox. Then, the offramp
   gateway uses POP SMTP
   envelope [6] is likely to receive the mail from be the MTA. As a result, most common case on the
   offramp gateway receives duplicate mail from the MTA.


   Discussion 
   transport system, but it may happen that multiple copies of the duplicate
   same message detection mechanism are transmitted, one per each recipient. Or it may
   happen that the final MTA is entrusted set to other documents.


2.2 Automatic re-transmission in the occurrence of deliver a delivery separate copy of the
   message per each recipient into the final mailbox, supposing it is
   delivering messages to real separate end user's mailboxes. 

   It may thus happen that the offramp gateway receives multiple 
   copies of the same Internet fax message, to be delivered to 
   different GSTN destinations, all listed together, and repeatedly, 
   into the e-mail message headers [7] of the Internet fax. In such 
   cases, the offramp gateway SHOULD implement techniques to avoid 
   duplicate or even multiple transmission over GSTN of the same fax 
   message to the same recipient.

   Here are some possible, but non-exclusive examples of these 
   techniques.

2.1.1 SMTP envelope addresses check

   Using the SMTP [6] envelope destination address given as "RCPT TO"
   field is usually the best technique to ensure that a received
   message must be delivered to that address, and to avoid duplicate
   deliveries. 

   If the offramp gateway has the "RCPT TO" information still 
   available during processing, then it MUST use it to determine the 
   recipients over GSTN fax service.

2.1.2 Message-ID check

   If the SMTP "RCPT TO" information is not available, for example
   in the case the offramp gateway retrieves messages from its mailbox
   using either POP [8] or IMAP [9] protocols, the message header
   "Message-ID" (see [7]) MAY be used to check if a message has 
   already been processed, and hence avoid retransmission to all its
   GSTN  recipients handled by the offramp gateway.

2.2 Error handling

2.2.1 Recoverable errors

   Recoverable errors happening during GSTN transmission are those
   where there is good chance that the error may not occur at the next
   attempt. This category includes "busy signal", "no line/carrier 
   signal", etc.

   For all these errors, the offramp gateway SHOULD re-queue the 
   message and perform a retransmission attempt later on, as specified
   in section 2.3

2.2.2 Non-recoverable errors

   If the error occurring during GSTN transmission is likely to be a
   non recoverable one, such as for example remote device paper 
   related errors (jam, empty tray, ...), no response from remote 
   destination, voice response, data modem response, or a stop event
   error, the offramp gateway SHOULD NOT attempt retransmission, and
   an error Message Delivery Notification (MDN) with appropriate error
   codes MUST be generated for the Internet fax message sender.

2.3 Automatic re-transmission handling

   An offramp gateway MAY add SHOULD implement a function that automatically 
   tries to send facsimile data again if recoverable delivery failure 
   occurs. If this function is added, implemented, then:

    - the retry times and retry interval MAY be specified as options
      by the administrator of the offramp gateway.


   If this function is set, a gateway;

    - any error return notice SHOULD be sent only when the
   specified number of 
      retries has been completed and the last facsimile
   transmission is an error. When without success;

    - if transmission is suspended by the
   error, transmission is again started due 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, error, then the 
      subsequent transmission attempt SHOULD avoid retransmitting the
      pages already delivered successfully, if any.

2.4 Multiple return notice handling

   An 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 receive an Internet fax for delivery to the sender without any retransmission.


   Thus, Calling Errors can probably be recovered, but Connecting
   multiple GSTN recipients. If errors
   can rarely be recovered.




Mimura, et. al.           Expires January 2005                 [Page3] occur, thus requiring to 
   inform the Internet Draft       Guideline of optional services           July 2004
                        for fax sender about them, or if the Internet FAX Gateway


2.4 When sending return notice 
   When an fax 
   sender himself requested delivery notifications, then the offramp 
   gateway receives broadcast mail, there are two ways has various possibilities to send a handle these multiple return notice. 
   notices:

   1) An an offramp gateway sends a return notice as soon as an error
      occurs. or
      a successful delivery occurs, per single GSTN recipient;

   2) An an offramp gateway gathers all information about the message,
      but sends a return notice only after every completion of
      the specified all or a number of transmissions.


   These features should be options selected by the user.


   Example


   The source user GSTN 
      recipients have been handled (successfully or not);

   If case 2 is requested implemented, then the offramp gateway MAY choose also
   to send one facsimile data separate successful and failure notices, or to 20,000
   addresses, but encounters many errors for more than 1000 addresses.


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


   If limit the offramp gateway sends one
   number of GSTN recipients handled per single return notice note, for every ten
   transmissions, the source user would receive only one-tenth of the
   example no more than 10 recipients per return notices. note.

2.5 When a transmitting error occurs in Handling transmission errors for 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. ways:

   1) When the gateway has a log information preservation function, the
      error information return notices SHOULD be recorded to a log, re-queued, and processing
      SHOULD delivery retried 
      later. The number of retry attempts and the time interval among
      then MAY be a feature configured by the offramp gateway 
      administrator. This is preferred method to implement; however,
      if all the retransmission attempts fails, processing SHOULD
      continue as in case 2;

   2) if the gateway does not have enough capabilities to handle notice
      re-queuing, but 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 method (for
      example, SMTP). 


   2)
      example by sending him an e-mail message). 

   3) If the gateway does not even have a log information preservation
      function, the administrator SHOULD be told notified about the failure,
      for example via an e-mail message, and processing SHOULD end. 


   3) If the 

2.6 Offramp gateway has log

   An offramp gateway SHOULD have a high hardware capability and sufficient time
      margin, it is function which keeps information 
   listed as a beneficial service log, either specific to perform the following
      processing. When notice of a result fails in transmission, fax gateway, or inside some 
   other log file existing locally on the
      fixed time interval is vacated, and gateway itself or remotely.
   If the output of fax gateway or the notice is
      repeated for remote system are equipped with a specified number of times. Even if the specified
      number of times continues to fail, recording
   media the error log 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 saved as a specific process (for example, SMTP). 



Mimura, et. al.           Expires January 2005                 [Page4]


Internet Draft       Guideline of optional services           July 2004
                        for Internet FAX Gateway


2.6 Keep log
   An offramp gateway MAY have file. As a function which keeps last
   resort, if no recording media are available, the log MAY be printed.

   The information listed below as a log. For security and message traces, the Internet
   FAX Gateway MAY use in the following format for a system log or event log of MAY be the Operation System. following:

   - Date and time when transmit request the Internet fax is received
   - Source Sender address
   - Destination address Recipient address(es)
   - Date Start date and time when transmitted of transmission over the GSTN
   - Date End date and time when of transmission over the GSTN was finished
   - Number of real actually transmitted pages
   - Byte count Number of actually transmitted data
   - Type of data (resolution) bytes
   - Occurrence of errors Fax resolution used
   - Number Error codes/text occurred during transmission
   - Number of retries automatically sent transmission attempts (retries)
   - Date and time of transmission of the (eventual) delivery notice


   The goal

3. Optional Services for an Onramp Gateway

3.1 Examples of the log information preservation user authorization

   An onramp gateway MAY have a user authorization function is mainly to
   improve security or charge calculation processing.


   When confirm
   that the hardware system user is equipped with recording media (HDD, FDD,
   etc.), authorized to transmit facsimile into the log information SHOULD Internet
   fax service. For example, user authorization may be saved as accomplished by
   getting a log file. user-ID and password received by DTMF, or via a local
   authorization table based on the GSTN caller-ID. The following 
   sub-sections give some possible examples, but other methods are three opportunities also
   possible.

3.1.1 Authorization via GSTN caller-ID

   The most simple method to save log information.


   1) When an offramp gateway receives authenticate and authorize a distribution demand.
   2) When an offramp GSTN fax
   service user is by using the GSTN caller-ID. If available, in fact,
   the caller-ID is generated by the GSTN network service itself, and
   it is quite difficult to produce fake ones. In other words, the
   security related to this authentication method rely on the confidence
   that the GSTN caller-ID service is secure by itself.

   The GSTN sender MAY be authorized via a lookup into a table managed
   by the onramp gateway starts distribution.
   3) When an offramp administrator, both via complete or partial
   (wildcard) matches.

3.1.2 Authorization via GSTN fax "station ID"

   During the initial GSTN fax service negotiation, the sender fax
   can send to the onramp gateway ends distribution.


   When various information, including the hardware system does not use a recording medium, log
   "station ID" alphanumeric string. This string MAY thus be used to
   transmit authentication and authorization information cannot for subsequent
   lookup by the onramp gateway. Thus user-id and an eventual password
   MAY be saved locally. In sent inside this case, it string.

   If used as the only authentication, this method is desirable
   to use however much less
   secure than the save function at other PCs using existing network
   communication means, such caller-ID one, as a function the user of the calling GSTN station
   can decide which string to save log information as a
   file using Network File System, SMTP, SNMP, or send, and the function string itself travels in
   clear form over the GSTN. Given this security warning, this method
   however allows more flexibility to
   periodically print log information. 


   To strengthen security, the GSTN user: in fact it is desirable not
   tied to save log information a single GSTN fax terminal, and authorization can be obtained
   from anywhere, provided the sender has the possibility to configure
   the "station ID" on the device being used. 

   A combination of caller-ID and station ID check MAY, on the other
   hand, result in
   the Internet FAX Gateway using a database system. 


3. Optional Services for an Onramp Gateway


3.1 Example of user authorization greatly improved level of security.

3.1.3 Authorization via DTMF

   An onramp gateway MAY have a user authorization implement the Authorization function to confirm by
   requesting that the a user is authorized to transmit data. In the case of onramp
   action, there ID and password information are many methods to sent over
   GSTN via DTMF. For example, this function MAY be accomplished 
   requesting this DTMF information is send authentication information.
   The method chosen depends on just after the provider's services. Consequently,
   an example connection 
   over GSTN is not described. 




Mimura, et. al.           Expires January 2005                 [Page5]


Internet Draft       Guideline of optional services           July 2004
                        for Internet FAX Gateway established, before starting the GSTN fax negotiation,
   but other methods are also possible.

3.2 Keep Onramp gateway log

   An onramp gateway MAY SHOULD have a function that which keeps information 
   listed as a
   log. For security and message traces, log, either specific to the fax gateway, or inside some 
   other log file existing locally on the Internet FAX gateway MAY
   use itself or remotely.
   If the following format of a fax gateway or the remote system are equipped with a recording
   media the log or event information SHOULD be saved as a log of file. As a last
   resort, if no recording media are available, the
   Operation System.


   - Date and time when transmission request was received
   - Source address
   - Destination address
   - Date and time of transmission over log MAY be printed.

   The information listed in the GSTN log MAY be the following:

   - Date Start date and time when of transmission over the from GSTN was finished
   - Date End date and time of transmission over the Internet from GSTN
   - Number of real transmitted actually received pages
   - Byte count Number of transmitted data actually received bytes
   - Type of data (resolution) Fax resolution used
   - Occurrence of errors Sender address (if available)
   - Recipient address(es)
   - Date and time when the Internet fax is sent
   - Error codes/text occurred during Internet fax transmission
   - Number of retries sent automatically transmission attempts (retries)
   - Date and time of transmission of the (eventual) delivery notice


   The purpose of the log information preservation function is mainly


4. Security Considerations

   Refer to
   improve Section 3.1 (User authorization) for authentication for an
   onramp gateway. In particular, sending the user IDs and password in 
   clear, as described in section 3.1.2 can pose high security or charge calculation processing.


   When the hardware system risks,
   and thus is equipped with recording media (HDD, FDD,
   etc.), the log information SHOULD NOT RECOMMENDED.

   S/MIME [10][19][20][21][22] ]and OpenPGP [11] [18] can also be saved as a log file. 


   The following are three possible opportunities used
   to save log
   information.


   1) When encrypt an onramp gateway receives Internet fax message. A signed or encrypted message is
   protected while transported along the network; however when a distribution demand.
   2) When an onramp gateway starts distribution.
   3) When message
   reach an Internet fax gateway, either onramp gateway ends distribution.


   When a hardware system without a recording medium is used, log
   information or offramp, this kind 
   of protection 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 applied anymore. Security must rely here on 
   trusted operations of the gateway itself. A gateway might have its
   own certificate/key to save log information improve security operations when sending 
   Internet faxes, but as a
   file using Network File System, SMTP, SNMP, or a function that
   periodically prints log information. 


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


4. Security Considerations


   An offramp end to end security
   pattern of both S/MIME and onramp gateway MAY have OpenPGP.

   Other security mechanisms, like IPsec [12][13][14][15][16] or TLS [17]
   also do not ensure a user authorization function
   to confirm that they secure gateway operation.

   Denial of Service attacks are authorized to transmit facsimile data.
   Encryption beyond the scope of facsimile data could be performed this document.
   Host Compromise caused by flaws in the existing SMTP,
   using an available security technique.


   The security consideration sections implementation is beyond the 
   scope of [3] apply to this document.


Mimura, et. al.           Expires January 2005                 [Page6]


Internet Draft       Guideline of optional services           July 2004
                        for Internet FAX Gateway 


5. References 

5.1 Informative groups group

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

   [10] R. Housley, "Cryptographic Message Syntax", RFC3852, July 2004.

   [11] J. Callas, L. Donnerhacke, H. Finney, R. Thayer, ,
        "OpenPGP Message Format", RFC2440, November 1998.

   [12] Kent, S. and R. Atkinson, "Security Architecture for the 
        Internet Protocol", RFC 2401, November 1998.

   [13] Kent, S. and R. Atkinson, "IP Authentication Header", RFC2402,
        November 1998.

   [14] K. Ramakrishnan, S. Floyd, D. Black, "The Addition of Explicit
        Congestion Notification (ECN) to IP", RFC3168, September 2001.

   [15] Piper, D., "The Internet IP Security Domain of Interpretation 
        for ISAKMP", RFC 2407, November 1998.

   [16] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document 
        Roadmap", RFC2411, November 1998.

   [17] Dierks, T. and C. Allen, "Transport Layer Security (TLS) 
        Extensions", RFC3456, June 2003.

   [18] Elkins et. al., "MIME Security with OpenPGP", RFC 3156,
        August 2001.

   [19] E. Rescorla, "Diffie-Hellman Key Agreement Method", RFC2631,
       June 1999.

   [20] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions 
        (S/MIME) Version 3.1 Certificate Handling ", RFC3850, June 1999.

   [21] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions
        (S/MIME) Version 3.1 Message Specification ", RFC3851, June 1999.

   [22] P. Hoffman, "Enhanced Security Services for S/MIME", RFC2634,
        June 1999.

5.2 Normative groups group

   [2] K. Mimura, K. Yokoyama, T. Satoh, C. Kanaide, "Internet FAX
       Gateway Functions", draft-ietf-fax-gateway-protocol-11.txt, July
       2004. Requirements", draft-ietf-fax-gateway-protocol, 
       January 2005.

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

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

   [5] "Procedures for real-time Group 3 facsimile communication over IP
       networks", ITU-T Recommendation T.38, June 1998.

   [6] Postel, J. "Simple Mail Transfer Protocol", STD 10, RFC 821,
       August 1982.

   [7] Crocker, D., "Standard for the format of ARPA Internet text
        messages", STD 11, RFC 822, August 1982.

   [8] Myers, J., Rose, M. "Post Office Protocol - Version 3", RFC1939,
       May 1996

   [9] Crispin, M. "Internet Message Access Protocol - Version 4rev1",
       RFC3501, March 1998. 2003.


6. Full Copyright Intellectual Property Statement


   Copyright (C)
   The Internet Society (2004). All Rights Reserved.


   This document and translations IETF takes no position regarding the validity or scope of it may any   intellectual property or other rights that might be copied and furnished claimed to
   others, and derivative works that comment on or otherwise explain it
   or assist in its   pertain to the implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction use of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, technology described in   this document itself may or the extent to which any license under such rights   might or might not be modified in available; neither does it represent that it   has made any effort to identify any way, such as by removing rights.  Information on the copyright notice or references   IETF's procedures with respect to the Internet Society or other
   Internet organizations, except as needed rights in standards-track and   standards-related documentation can be found in BCP-11.  Copies of   claims of rights made available for the purpose publication and any assurances of
   developing Internet standards, in which case   licenses to be made available, or the procedures result of an attempt made to   obtain a general license or permission for
   copyrights defined in the Internet Standards process must be
   followed, use of such   proprietary rights by implementors or as required users of this specification can   be obtained from the IETF Secretariat.   The IETF invites any interested party to translate it into languages bring to its attention any   copyrights, patents or patent applications, or other than
   English.


   The limited permissions granted above are perpetual and will not proprietary   rights which may cover technology that may be
   revoked by required to practice   this standard.  Please address the information to the IETF Executive   Director.

7. Full Copyright Statement

   Copyright (C) The Internet Society or its successors or assigns. (2005). This document is subject   to the rights, licenses and restrictions contained in BCP 78, and   except as set forth therein, the authors retain all their rights.
   This document and the information contained herein is are provided on an   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET   ENGINEERING TASK FORCE DISCLAIMS DISCLAIM 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 January 2005                 [Page7]


Internet Draft       Guideline
8. Acknowledgments

   Thanks to Claudio Allocchio (Consortium GARR, Italy) for its final
   review of optional services           July 2004 this document, and for Internet FAX Gateway


7. Contact contributing the authorization
   and security sections of this document.

9. Author's Address
   
   Katsuhiko Mimura
   TOYO Communication Equipment CO., LTD.
   2-1-1 Koyato, Samukawa-machi, Koza-gun
   Kanagawa-pref., 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-pref., Japan
   Fax: +81 467 74 5743
   Email:keiyoko@msn.com

   Takahisa 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

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
















Mimura, et. al.           Expires January 2005                 [Page8]


Internet Draft       Guideline of optional services           July 2004
                        for Internet FAX Gateway

   Claudio Allocchio
   Consortium GARR
   Viale Palmiro Togliatti 1625
   00155 Roma, Italy
   Fax: +39 040 3758565
   Email: Claudio.Allocchio@garr.it













Revision history (to be deleted before publication)


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
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   25-July 2004 Corrections and clarifications.
07   20-July-2004  5. References 
                  split to Informative and Normative
08   21-Jan-2005  Full review/rewrite to clean up language
                  and address IESG "Discuss".



























Mimura, et. al.           Expires January 2005                 [Page9]

----