Subject: AD comments on draft-ietf-fax-gateway-protocol-06.txt and draft-ietf-fax-gateway-options-04.txt

From: [email-masked]
Date: Mon, 18 Mar 2002 17:53:32 -0800 (PST)

My notes indicate I asked for a last call on these back in November, but it
appears to have gotten lost (quite probably my fault).

I'm actually glad this happened, however, since it gave me a chance to review
this again. And I have number of things that need to be fixed.

Comments on  draft-ietf-fax-gateway-protocol-06.txt

First the easy stuff; all formatting nits of one sort or another:

The last two paragraphs of the Abstract need to be pulled out into separate
sections, e.g. "Requirements notation" and "Notice of Intellectual Property
Claims". These should appear after the introduction.

There appear to be a large number of blank lines separating paragraphs missing
throughout the document:

  Between lines 4-5 of the Abstract
  Between lines 3-4 and 8-9 of Introduction
  Between lines 2-3, 5-6, and 8-9 of section 2
  Between lines 4-5 of section 3.1
  Between lines 4-5 of section 4.1
  Between lines 2-3 of section 4.2.1
  Between the last couple of lines of section 4.2.1
  Between lines 4-5 of section 4.2.2
  Between lines 3-4 and 5-6 of section 4.2.3
  Between lines 3-4, 5-6 of section 4.3
  Between lines 3-4, 7-8 of section 5

Some of these may actually need to be merged into a single paragraph.
Regardless, the formatting is halfway between separate paragraphs and single
paragraphs now, and that's wrong.

The references in this document need to be separated into normative and
informative groups, per recent RFC Editor requirements.

And now for the major item. The security considerations section ends with:

  Further security considerations are introduced by this document, but
  they will be described in this section prior to pulication as an RFC.
   
It is obvious this is problematic, and why. Please fix.

Comments on draft-ietf-fax-gateway-options-04.txt

This document uses RFC 2119 requirements notation even though it is only
informational. In some cases this is OK, however, in this case I find the use
of requirements notation in the context of a list of independent optional
capabilities quite confusing. I therefore suggest that the reference to RFC
2119 be dropped and the use of capitalized words removed.

This document has the same problem with the abstract that the previous
gateway document did -- the IPR notice needs to be moved to a section of its
own after the introduction.

There is a similar lack of appropriate paragraph breaks in this document. This
time it happens in section 1, section 2.5, section 2.6, and section 4. Some
merging of paragraphs may be even more appropriate here instead of having all
the isolated sentences.

The first paragraph of section 2.1 doesn't make sense and needs to be reworded.
Unfortunately I cannot suggest alternative words since I'm not clear on what it
actually should say. There are various other grammar, but none so serious as
this.

				Ned

---

From: Yokoyama <[email-masked]>
Date: Fri, 22 Mar 2002 09:44:13 +0900

Ned-san

Thank you for your comments.
We changed I-Ds in accordance with your comments.
And we attached I-Ds to this mail.
draft-ietf-fax-gateway-protocol-6a.txt is changed from
draft-ietf-fax-gateway-protocol-06.txt
draft-ietf-fax-gateway-options-4a.txt is changed from
draft-ietf-fax-gateway-options-04.txt

> Claims". These should appear after the introduction.

We moved them after 1.Introduction.

> There appear to be a large number of blank lines separating paragraphs missing

We removed a large number of blank lines.

>   they will be described in this section prior to pulication as an RFC.

We removed this sentence.

> 2119 be dropped and the use of capitalized words removed.

We removed the reference to RFC 2119.

> own after the introduction.

We moved Intellectual Property after 1.Introduction,
and removed a large number of blank lines,
and removed last sentence of the security considerations section.

K.Yokoyama
Network Working Group                                          K.Mimura
Internet-Draft: draft-ietf-fax-gateway-protocol-6a.txt      K.Yokoyama
                                                                T.Satoh
                                                              C.Kanaide
                                            TOYO Communicaion Equipment
                                                          March 20 2002

                     Internet FAX Gateway Functions

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 (2001).  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 recommended behaviors for
   Internet FAX Gateways Functions for email-based Internet fax. 
   In this context, an Offramp means facsimile data transmission to the
   GSTN from the Internet, and onramp means facsimile data transmission 
   to Internet from the GSTN. This document covers the delivery-process 
   of the data among equipment which may include Internet Fax terminals,
   PCs on the Internet and FAX terminal on GSTN. 

Table Of Contents

1. Introduction
1.1 Key words
1.2 Intellectual Property

Mimura,                     Expires March 2002                   [Page1]

Internet Draft       Internet FAX Gateway Functions       September 2001

2. Internet FAX Gateway Protocol 
3. Offramp Gateway
3.1 Offramp functions
3.2 Addressing
3.2.1 example of local dialing rules
3.3 User authorization
3.4 Return notice
4. Onramp Gateway
4.1 Onramp Functions
4.2 Address designation
4.2.1 Immediate address designation
4.2.2 Indirect address designation
4.2.3 Support subaddress
4.3 Relay function
4.4 File format conversion
4.5 User authorization
4.6 Return notice
5. Security Considerations
6. References
7. Full Copyright Statement
8. Contact

1. Introduction

   An Internet FAX Gateway plays a role of gateway between FAX
   operations built on the General Switched Telephone Network (GSTN) and
   the Internet. This document defines the potential behavior of devices
   and applications which serve this purpose. Gateways can be classified
   as an Onramp where facsimile data is translated from the GSTN to the 
   Internet and as an Offramp, where facsimile data is translated from
   the Internet to the GSTN. A more detailed definition of onramps and
   offramps for email-based Internet fax is provided in [RFC2542].
   Internet FAX Gateways functions for real-time Internet fax are
   defined in [T.38].
   Scope of Internet FAX Gateway defined in this document is shown
   below.
   1) A format of image data is a data format defined by "Simple Mode" 
      in [RFC2305].
   2) Operational mode is "store and forward" defined in section 2.5 of 
      [RFC2542]

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

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

Mimura,                     Expires March 2002                   [Page2]

Internet Draft       Internet FAX Gateway Functions       September 2001

2. Internet FAX Gateway Protocol

   There are two kinds of gateway functions, which are an onramp gateway
   and offramp gateway. An onramp gateway receives facsimile data from a
   facsimile device over the GSTN, then sends the facsimile data to an 
   Internet fax capable device or application. An offramp gateway
   receives Internet FAX from Internet fax capable devices which may
   include an onramp gateway and PC over Internet, then sends facsimile 
   data to facsimile device over GSTN. In both case described above,
   facsimile communication between a gateway and the 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. Offramp Gateway

3.1 Offramp functions
   An offramp gateway provides a translation function, such that the
   offramp gateway receives an Internet FAX and then send facsimile data
   to the facsimile devices over GSTN using a standard facsmile protocol
   [T.30].The Communication protocol between the offramp gateway and the
   submitting Internet fax device will be based on RFC 2305 for 
   standards-based store and forward operations.

3.2 Addressing
   An offramp gateway MUST process the mailbox string and convert it to
   a "local-phone" according to the local dialing rules.

3.2.1 example of local dialing rules
   This example is an offramp gateway change from "global-phone" to 
   "local-phone" by removing "+" and international country code.

   If an offramp gateway receive next "global-phone".

      +12223334444

   "local-phone" is the string remove "+",international country code "1"
   from "global-phone".
   "local-phone" is 

      2223334444

   Next example is an offramp gateway change from "global-phone" to 
   "local-phone" by removing "+" and international country code then
   "exit-code" "0"is put at head.

   If an offramp gateway receive next "global-phone".

Mimura,                    Expires March 2002                   [Page3]

Internet Draft       Internet FAX Gateway Functions      September 2001

      +81355556666

   "local-phone" is the string remove "+",international country code
   "81" then "exit-code" "0" is put at head from "global-phone"
   "local-phone" is

      0355556666

   "global-phone" defined in section 2. of [RFC2304]
   "local-phone" defined in section 2. of [RFC2846]
   "exit-code" defined in section 2.1 of [RFC2846]

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

   The example of the user authorization function at the time of 
   Offramp gateway is shown below.

  1) Encipherment of user authorization and facsimile data is performed 
     by the existing SMTP, such as S/MIME and X-Header, using the
     possible security technique.

  2) The distribution demand from the user who permitted use of the 
     Internet Fax Gateway is received using the user authorization
     function and E-mail transmitting function of WWW. 

3.4 Return notice
   An offramp gateway MUST 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.

   When the offramp gateway fails in transmission of the return notice,
   The error information MAY be recorded to a log and processing MAY
   be ended, or the administrator of a gateway system MAY be notified
   of these errors information with a certain means (for example, SMTP).  
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.

4.2 Address designation
   An onramp gateway SHOULD have the function that onramp gateway
   analyze destination address from address data sent by facsimile
   device over GSTN.

Mimura,                     Expires March 2002                   [Page4]

Internet Draft       Internet FAX Gateway Functions       September 2001

   There are two kinds of the next of address data from FAX device over
   GSTN.

4.2.1 Immediate address designation
   Address data from facsimile device over GSTN specify destination
   number directly. It is used when destination is specified every time.

   Example

   (1) An onramp gateway receive destination telephone number
        "12223334444" from source facsimile by DTMF.

          12223334444

   (2) Destination number is used as "global-phone", "+" is added before
       it.

          +12223334444

   (3) "FAX=" is added at the head of "global-phone" to change
        "global-phone" into "fax-mbox".

           FAX=+12223334444

   (4) With this example "fax-mbox" is used as "fax-address".
       "Fax-email" is made by adding "@" and appropriate offramp domain
       "mta-I-fax" behind "fax-address".

          FAX=[email-masked]

       As for the way of choosing domain name of offramp gateway,
       it is defined in 4.3 Relay function.

   "global-phone" "fax-mbox" "fax-address" defined in section 2.of
   [RFC2304]. "mta-I-fax" defined in section 3.of [RFC2304]. "fax-email"
   defined in section 4. of [RFC2304]

4.2.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 
   an 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 mail terminal, transmission to an address to use 
   it well, the multicast transmission and so on.
    
   An onramp Gateway holds indirect address information by itself.
   Or, it is acquired from another server.
   Indirect address information contains following information.
   - Indirect address number
   - The list of the destination facsimile number and the E-mail address
     looked up from the indirect address number.

Mimura,                     Expires March 2002                   [Page5]

Internet Draft       Internet FAX Gateway Functions       September 2001

   Example

   (1) An onramp gateway receive Indirect address number "1234" from
       source facsimile by DTMF.

          1234

   (2) Destination address "addr-spec" is looked up by using the address 
       change table.

          address change table
          1234 : [email-masked]

   (3) Internet FAX is sent to an Internet FAX device 
       "[email-masked]" by an onramp gateway.

   "addr-spec" defined in section 6.1 of [RFC822]

4.2.3 Support subaddress
   An onramp gateway SHOULD supports subaddress.In the case of immediate
   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 Relay function
   Onramp gateway SHOULD have the function which chooses destination
   offramp gateway by analyzing a specified destination facsimile
   number. Onramp gateway SHOULD hold relay information of offramp
   gateway to realize this function. Onramp gateway holds the following 
   Offramp gateway relay 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 relay 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

4.4 File format conversion
   An onramp gateway MUST counvert file format from an facsimile over 
   GSTN to file format TIFF Profile-S for Internet Fax defined in 
   [RFC2301].

4.5 User authorization
   Onramp gateway MAY have a user authorization function to confirm
   that they are the data that suitable user transmitted.
   For example, User authorization is done by using user ID, password 
   extracted from DTMF (Dual Tone Multi Frequency).

Mimura,                     Expires March 2002                   [Page6]

Internet Draft       Internet FAX Gateway Functions       September 2001

4.6 Return notice
   When an onramp gateway receives and analyzes return notice from
   destination, an onramp gateway MAY have the means that delivery
   status is sent to suitable facsimile device user on GSTN through the
   appropriate offramp gateway.

   When an onramp gateway fails in transmission of the return notice,
   The error information MAY be recorded to a log and processing MAY
   be ended, or the administrator of a gateway system MAY be notified
   of these errors information with a certain means (for example, SMTP).

5. Security Considerations

   Offramp and Onramp gateway MAY have a user authorization
   function to confirm that they are the data that suitable user
   transmitted. Encryption of  facsimile data could be performed by the 
   existing SMTP, using the possible security technique.

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

6. References 

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

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

   [RFC2301] L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons,
             J. Rafferty, "File Format for Internet Fax",RFC2301, 
             March 1998

   [RFC2304] C. Allocchio.,"Minimal FAX address format in Internet Mail"
             , RFC 2304, March 1998.

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

   [T.30] "Procedures for document facsimile transmission in the general
          switched telephone network", ITU-T Recommendation T.30,
          April 1999.

Mimura,                     Expires March 2002                   [Page7]

Internet Draft       Internet FAX Gateway Functions       September 2001

   [T.33] "Facsimile routing utilizing the subaddress"
          ITU recommendation T.33, July, 1996.

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

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.

8. Contact
   
   Katsuhiko Mimura
   TOYO Communication Equipment CO., LTD.
   2-1-1 Koyato, Samukawa-machi, Koza-gun
   Kanagawa-pref., Japan
   Fax: +81 467 74 5743
   Email: [email-masked]

   Keiichi Yokoyama
   TOYO Communication Equipment CO., LTD.
   2-1-1 Koyato, Samukawa-machi, Koza-gun
   Kanagawa-pref., Japan
   Fax: +81 467 74 5743
   Email: [email-masked]

Mimura,                     Expires March 2002                   [Page8]

Internet Draft       Internet FAX Gateway Functions       September 2001

   Takahisa Satoh
   TOYO Communication Equipment CO., LTD.
   2-1-1 Koyato, Samukawa-machi, Koza-gun
   Kanagawa-pref., Japan
   Fax: +81 467 74 5743
   Email: [email-masked]

   Chie Kanaide
   TOYO Communication Equipment CO., LTD.
   2-1-1 Koyato, Samukawa-machi, Koza-gun
   Kanagawa-pref., Japan
   Fax: +81 467 74 5743
   Email: [email-masked]

Revision history

  [[[RFC editor: Please remove this section on publication]]]

  00a  10-Jul-2000  Initial draft.
  01a  16-Aug-2000  Remove next section.
                       Authentication
                       Authentication toward Offramp gateway
                       Option function
                       Multicasts transmit request
                    Rename next section
                       to Relay function from Choice of Offramp gateway
                       to User authorization from User authentication
                       to Immediate address designation from Direct
                       address designation

                    Section Drop the duplicate mail was moved to a part
                    of the section Offramp functions.
                    Corrections and clarifications.
02a  30-Oct-2000  Title is changed from Internet FAX Gateway Protodol
                  to Internet FAX Gateway Functions
                  Remove next definition.
                       Drop duplications for Broadcast
                       When send return notice
                       Automatic re-transmission
                       keep log for offramp gateway
                       Example of User authorization 
                       keep log for onramp gateway
                    Rebuild next definition
                       3.2 Addressing
                       3.2.1 example of local dialing rules
                       4.2.1 Immediate address designation
                       4.2.2 Indirect address designation
                       4.4 File format conversion

Mimura,                     Expires March 2002                   [Page9]

Internet Draft       Internet FAX Gateway Functions       September 2001

03a  21-Feb-2001 Rebuild next definition
                       1.  1)
                       3.4 Return notice
                       4.6 Return notice
                 Add next definition
                       3.3 User authorization
04a  22-May-2001 Rebuild next definition
                       3.4 Return notice
                       4.6 Return notice
                       5. Security Considerations
05a 28-June-2001 Rebuild next definition
                       Abstract   
                       1. Introduction
                       4.2 Address designation
                 Add to References
                       [T.38]      
06a 19-Septembert-2001 Rebuild next definition
                       5. Security Considerations
6a  20-March-2002 Corrections and clarifications.
                   Moved Intellectual Property and keywords 
                   after section 1.
                   Fixed Security considerations.

Mimura,                     Expires March 2002                  [Page10]

Network Working Group                                          K.Mimura
Internet-Draft: draft-ietf-fax-gateway-options-4a.txt       K.Yokoyama
Intended Category: Informational                                T.Satoh
                                                             K.Watanabe
                                                              C.Kanaide
                                            TOYO Communicaion Equipment
                                                          March 20 2001

        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 (2001).  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.

   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.

Mimura,                     Expires March 2002                   [Page1]

Internet Draft       Guideline of optional services       September 2001
                        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 delivery error occurrence
2.3 Error Behavior
2.4 When send return notice
2.5 When a transmitting error occurred in 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. 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-06].

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

 1) A format of image data is a data format defined by "Simple Mode" 
    in [RFC2305].
 2) Operational mode is "store and forward" defined in section 2.5 of 
    [RFC2542]

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

Mimura,                     Expires March 2002                   [Page2]

Internet Draft       Guideline of optional services       September 2001
                        for Internet FAX Gateway

2. Optional services for an offramp gateway

2.1 Drop Duplications
   By the case an offramp gateway detects duplicate 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 duplicate 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 transmission is stopped after 2 pages
   are sent normally. The offramp gateway should re-transmit the
   facsimile data from page 3.

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.

Mimura,                     Expires March 2002                   [Page3]

Internet Draft       Guideline of optional services       September 2001
                        for Internet FAX Gateway

   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.

2.5 When a transmitting error occurred in return notice
   When an offramp gateway fails in transmission of return notice,
   The Internet Fax Gateway SHOULD process either of the following.

   When a log information preservation function is in a gateway,An error
   information SHOULD be recorded to a log and processing SHOULD be
   ended. At this time, the administrator of a gateway system SHOULD be
   notified of these errors information with a certain means
   (for example, SMTP). 

   The case where there is no log information preservation function
   in a gateway, An administrator SHOULD be told about failure and
   processing SHOULD be ended. 

   If the capability which the hardware of a gateway has is high and 
   there is a time margin, it is good service to perform the following 
   processing. When it fails in transmission of the notice of a result,
   A fixed time interval is vacated. And notice output operation is
   repeated as a result of the number of times of specification. The
   number time of specification times -- even if it repeats, when
   failing,An error information is recorded to a log and processing is
   finished. Also at this time, as for these errors information, the 
   administrator of the gateway system SHOULD be notified with a certain
   means(for example, SMTP). 

2.6 keep log

   An offramp gateway MAY have the function which following
   information is kept as log. For security and message trace, The 
   Internet FAX gateway MAY use the format of a system log or an event
   log of the Operation System.

Mimura,                     Expires March 2002                   [Page4]

Internet Draft       Guideline of optional services       September 2001
                        for Internet FAX Gateway

   - 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

   The log information preservation function aims at mainly becoming
   a help of security or Charge calculation processing.

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

   The opportunity which saves log information can consider three of 
   the following.
   
   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 without a certain recording medium is used, 
   log information cannot be saved locally.In this case, it is desirable   to hold the function saved at other PCs using the existing network 
   communication means, such as a function to save log information as 
   a file using a Network File System, and SMTP, SNMP, or the function 
   printed out periodically. 

   In order 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
   Onramp gateway MAY have a user authorization function to confirm that
   they are the data that suitable user transmitted. In the case of
   Onramp action,there are a lot of methods to send authentication
   information and it depends on a provider's services. So,an example is
   not described. 

3.2 keep log
   An onramp gateway MAY have the function that following information is
   kept as log. For security and message trace, The Internet FAX gateway
   MAY use the format of a system log or an event log of the Operation
   System.

Mimura,                     Expires March 2002                   [Page5]

Internet Draft       Guideline of optional services       September 2001
                        for Internet FAX Gateway

   - 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

   The log information preservation function aims at mainly becoming
   a help of security or Charge calculation processing.

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

   The opportunity which saves log information can consider three of the
   following.
   
   1) When an onramp gateway receives a distribution demand.
   2) When an onramp gateway starts distribution.
   3) When an onramp gateway ends distribution.

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

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

4. Security Considerations

   Offramp and Onramp gateway MAY have a user authorization function to 
   confirm that they are the data that suitable user transmitted
   Encryption of  facsimile data could be performed by the existing
   SMTP, using the possible security technique.

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

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

Mimura,                     Expires March 2002                   [Page6]

Internet Draft       Guideline of optional services       September 2001
                        for Internet FAX Gateway

   [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-06] K.Mimura, K.Yokoyama, T.Satoh,
             C.Kanaide "Internet FAX Gateway Functions",
             Internet-Draft, August 17 2001

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.

7. Contact
   
   Katsuhiko Mimura
   TOYO Communication Equipment CO., LTD.
   2-1-1 Koyato, Samukawa-machi, Koza-gun
   Kanagawa-pref., Japan
   Fax: +81 467 74 5743
   Email: [email-masked]

Mimura,                     Expires March 2002                   [Page7]

Internet Draft       Guideline of optional services       September 2001
                        for Internet FAX Gateway

   Keiichi Yokoyama
   TOYO Communication Equipment CO., LTD.
   2-1-1 Koyato, Samukawa-machi, Koza-gun
   Kanagawa-pref., Japan
   Fax: +81 467 74 5743
   Email: [email-masked]

   Takahisa Satoh
   TOYO Communication Equipment CO., LTD.
   2-1-1 Koyato, Samukawa-machi, Koza-gun
   Kanagawa-pref., Japan
   Fax: +81 467 74 5743
   Email: [email-masked]

   Ken Watanabe
   TOYO Communication Equipment CO., LTD.
   2-1-1 Koyato, Samukawa-machi, Koza-gun
   Kanagawa-pref., Japan
   Fax: +81 467 74 5743
   Email: [email-masked]

   Chie Kanaide
   TOYO Communication Equipment CO., LTD.
   2-1-1 Koyato, Samukawa-machi, Koza-gun
   Kanagawa-pref., Japan
   Fax: +81 467 74 5743
   Email: [email-masked]

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

Mimura,                     Expires March 2002                   [Page8]

---

From: Claudio Allocchio <[email-masked]>
Date: Fri, 22 Mar 2002 06:33:06 +0100

Thank you!

remember to submit the new drafts to [email-masked], too, as 
soon as you get all the eventual further comments from the mailing list.

thanks again!

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                        Project Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

     PGP Key: http://security.fi.infn.it/cgi-bin/spgpk.pl?KeyId=0C5C2A09

---

From: Hiroshi Tamura <[email-masked]>
Date: Fri, 22 Mar 2002 16:41:46 +0900 (JST)

Yokoyama-san,

There seems to be a few things you do not answer for Ned's comment.
If not, please correct.

--
Hiroshi Tamura, Co-chair of IETF-FAX WG
E-mail: [email-masked]

---

From: Yokoyama <[email-masked]>
Date: Mon, 25 Mar 2002 11:47:08 +0900

Tamura-san,

Thank you for your comment.
We corrected I-D as follows.

draft-ietf-fax-gateway-protocol-6b.txt is changed from
draft-ietf-fax-gateway-protocol-6a.txt
draft-ietf-fax-gateway-options-4b.txt is changed from
draft-ietf-fax-gateway-options-4a.txt

> > informative groups, per recent RFC Editor requirements.

At draft-ietf-fax-gateway-protocol-6b.txt
We separated 6. References into 6.1 normative groups and 6.2 Informative groups.
and arranged references again.

> > actually should say. There are various other grammar, but none so serious as

At draft-ietf-fax-gateway-options-4b.txt
We reworded First paragraph of section 2.1.

--
K.Yokoyama

Network Working Group                                          K.Mimura
Internet-Draft: draft-ietf-fax-gateway-protocol-6b.txt      K.Yokoyama
                                                                T.Satoh
                                                              C.Kanaide
                                            TOYO Communicaion Equipment
                                                          March 25 2002

Status Of This Memo

Copyright Notice

Abstract

Table Of Contents

1. Introduction
1.1 Key words

3. Offramp Gateway
3.1 Offramp functions
3.2 Addressing
6.1 normative groups
6.2 informative groups

1. Introduction

   offramps for email-based Internet fax is provided in [1].
   defined in [2].
      in [3].
      [1]

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

   on [3].

   Protocols which are discussed in this document are shown below, and
   other communication protocol should be referred in [3].

3. Offramp Gateway

3.1 Offramp functions
   An offramp gateway provides a translation function, such that the
   offramp gateway receives an Internet FAX and then send facsimile data
   to the facsimile devices over GSTN using a standard facsmile protocol
   [5].The Communication protocol between the offramp gateway and the
   submitting Internet fax device will be based on [3] for
   standards-based store and forward operations.

3.2 Addressing

      +12223334444

      2223334444

      +81355556666

      0355556666

   "global-phone" defined in section 2. of [a]
   "local-phone" defined in section 2. of [b]
   "exit-code" defined in section 2.1 of [b]

3.3 User authorization

3.4 Return notice

4.1 Onramp Functions
   IFAX devices MUST based on [3].

4.2 Address designation

   Example

          12223334444

          +12223334444

           FAX=+12223334444

   "global-phone" "fax-mbox" "fax-address" defined in section 2.of
   [a]. "mta-I-fax" defined in section 3.of [a]. "fax-email"
   defined in section 4. of [a]

   Example

          1234

          address change table
          1234 : [email-masked]

   "addr-spec" defined in section 6.1 of [c]

4.2.3 Support subaddress
   An onramp gateway SHOULD supports subaddress.In the case of immediate
   address designation, subaddress is analyzed by using [6] protocol.
   In the case of indirect address designation, [6] protocol is not
   used.Subaddress is looked up by using the address change table and so
   on from the indirect address number.

4.3 Relay function

   [7].

4.5 User authorization

4.6 Return notice

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

6. References 

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

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

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

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

   [5] "Procedures for document facsimile transmission in the general
          switched telephone network", ITU-T Recommendation T.30,
          April 1999.

   [6] "Facsimile routing utilizing the subaddress"
          ITU recommendation T.33, July, 1996.

   [7] L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons,
             J. Rafferty, "File Format for Internet Fax",RFC2301, 
             March 1998

6.2 Informative groups
   [a] C. Allocchio.,"Minimal FAX address format in Internet Mail"
             , RFC 2304, March 1998.

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

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

8. Contact
   
   Katsuhiko Mimura

   Keiichi Yokoyama

   Takahisa Satoh

   Chie Kanaide

Revision history

                       [2]      
6b  25-March-2002 Seaprate 6.References into 6.1 Normative groups
                  and 6.2 Informative groups.

Network Working Group                                          K.Mimura
Internet-Draft: draft-ietf-fax-gateway-options-4b.txt       K.Yokoyama
Intended Category: Informational                                T.Satoh
                                                             K.Watanabe
                                                              C.Kanaide
                                            TOYO Communicaion Equipment
                                                          March 25 2002

Status Of This Memo

Copyright Notice

Abstract

Table Of Contents

1. Introduction

1. Introduction

   [1].

   Information on recommended behaviors for Internet FAX Gateways
   Functions defined in [2].

    in [3].
    [1]

2.1 Drop Duplications
   By the case the mail which overlapped is sometimes received with an
   offramp gateway. Such the case an offramp gateway is required to drop
   the overlapped mail. It is to avoid that an offramp gateway transmits
   the overlapped facsimile data to an facsimile device over GSTN.

2.3 Error Behavior

   EXAMPLE

2.6 keep log

   

3.2 keep log

   

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

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",
             Internet-Draft, August 17 2001

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

7. Contact
   
   Katsuhiko Mimura

   Keiichi Yokoyama

   Takahisa Satoh

   Ken Watanabe

   Chie Kanaide

Revision history

4b   25-March-2002 Reword first paragraph of section 2.1
                   Arrange 5. References again.