Internet Fax Gateway Requirements
draft-ietf-fax-gateway-protocol-13

Network Working Group                                          K.Mimura
Internet-Draft: draft-ietf-fax-gateway-protocol-13.txt       K.Yokoyama
                                                                T.Satoh
                                                              C.Kanaide
                                           TOYO Communication Equipment
                                                           C. Allocchio
                                                        Consortium GARR
                                                        January 18 2005

                     Internet FAX Gateway Requirements

Status Of This Memo

 
   By submitting this Internet-Draft, we certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   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 obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

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

Abstract

   To allow connectivity between the general switched telephone network
   facsimile service (GSTN fax) and the e-mail based Internet Fax service
   (i-fax) an "Internet FAX Gateway" is required. This document provides
   recommendations for the functionality of Internet FAX Gateways. In
   this context, an "offramp gateway" provides facsimile data transmission
   from  i-fax to GSTN fax; viceversa an "onramp gateway" provides data 
   transmission form GSTN fax to i-fax. The recommendations in this
   document apply to the integrated service including Internet Fax
   terminals, computers with i-fax software on the Internet, and GSTN Fax
   terminals on the GSTN.

1. Introduction

   An Internet FAX Gateway provides connectivity and translation between
   the General Switched Telephone Network facsimile service (GSTN fax) and
   the e-mail based Internet Fax service (i-fax). This document defines 
   the recommended behavior of an Internet Fax Gateway. An Internet Fax
   Gateway can be classified as "onramp", when a facsimile is transferred
   from GSTN fax to the Internet Fax, and as "offramp", when a facsimile
   is transferred from Internet Fax to GSTN fax. For a more detailed
   definition of "onramp" and "offramp" within i-fax service, see [1].

   This document provides recommendations only for the specific case
   hereunder:

   1) the operational mode of the Internet Fax is "store and forward", as
      defined in Section 2.5 of [1].

   2) The format of image data is the data format defined by "simple
      mode" in [3].
 
   This document does not apply to the gateway funcions for "real-time
   Internet Fax", as described and defined in [2].  Additional 
   recommendations for optional functionality are described in [23].

1.1 Key words

   The key words "MUST", "SHOULD", "SHOULD NOT", 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
   rights in <http://www.ietf.org/ipr.html>.

2. Internet FAX Gateway operations

   An onramp gateway receives a facsimile from a GSTN fax device (which
   may include an offramp gateway itself), and generates an Internet Fax
   over the Internet which is sent to any Internet Fax device.

   An offramp gateway receives an Internet Fax over the Internet from
   any Internet Fax-capable device (which may include an onramp gateway
   or a PC), and generates a GSTN fax which is sent to any GSTN fax device.

   In both of these cases, the Internet side of the gateway acts as an
   Internet Fax device, as described in [3], while the GSTN side of the
   gateway acts as a GSTN fax device, as described in [5].

   In this document we will only thus recommend the actions which occur
   while

   1) the onramp gateway converts a fax received from GSTN to forward it
      to the Internet Fax service;

   2) the offramp gateway converts a fax received from the Intenret and
      forwards it to the GSTN fax service.

3. The Offramp Gateway operations

   An offramp gateway MUST, as minimal requirement, perform the
   following functions:

   - addresses translation/mapping;
   - image format conversion;
   - error/return notification handling;

   and MAY also perform

   - user authorization;

3.1 User authorization

   An offramp gateway MAY have a user authorization function to confirm
   that an user is allowed to transmit its Internet fax to the GSTN fax
   service.

   As an Internet Fax is sent as a MIME e-mail message until the
   offramp gateway, digital signatures can be used to authenticate and
   authorize the user. S/MIME is one example of a protocol that includes
   digital signature services. S/MIME is described in [8][9][10][11][12].
   Other methods to add a digital signature to a mail message (like
   OpenPGP [16] [24]) MAY also be used to authenticate and authorize the
   user.

   The agent sending the Internet Fax (which may include an an onramp
   gateway) sends the digitally-signed S/MIME or OpenPGP Fax message to
   the offramp gateway. The offramp gateway then compares the credentials
   of the user to determine if he/she is authorized to send faxes to
   the GSTN fax service. In case the authorization process fails, then
   the offramp gateway MUST generate an error delivery notification for
   the sender of the Internet Fax.

3.2 Addressing
   
   An Internet fax may contain multiple e-mail addresses, both as 
   originators, and as recipients. For its forwarding function to GSTN
   fax service, an offramp gateway MUST only consider those ones which 
   are explicitly addressed to itself, i.e. those where the right hand
   side of the e-mail address corresponds to the offramp gateway itself.

   As addresses on Internet Fax service are e-mail addresses, in order to
   reach a destination in GSTN fax service, the offramp gateway MUST
   convert e-mail addresses into GSTN addresses. 

   The GSTN destination address SHOULD normally be encoded inside the
   left hand side of the e-mail address, according to [6]. However, an
   offramp gateway MAY use locally implemented translation rules to map
   left hand side strings into GSTN addresses.  

   In any case the offramp gateway MUST process the resultant GSTN
   address, and convert it to a "local-phone" according to local
   dialing rules. 

   "Global-phone" is defined in Section 2 of [6]. "Local-phone" is
   defined in Section 2 of [7]. "Exit-code" is defined in Section 2.1 of
   [7].

   The offramp gateway SHOULD also have a function to apply translation
   to originator and other addresses referred to into the Internet fax
   in order to ensure a possible return path from GSTN fax service 
   into Internet fax destinations, including other offramp gateways.
   These functions MUST be compliant with the address handling of
   onramp gateways described in this document, section 4.2.
   
3.2.1 Examples of local dialing rules applied to GSTN destination
      addresses

   The first example shows how an offramp gateway converts a
   "global-phone" to a "local-phone" by removing the "+", recognizing
   the international country code "1" as the local one and thus removing
   it, and knowing it can directly dial without any exit code:

      global-phone:  +441164960348

   resulting into:

      local-phone:   1164960348

   The next example shows how an offramp gateway converts a
   "global-phone" to "local-phone" by removing the "+", recognizing
   the international country code as local, and then adding the 
   "exit-code" "0" in front of the string:

      global-phone:   +441164960348

   resulting into

       local-phone:   01164960348

   The next example shows how an offramp gateway converts a
   "global-phone" to "local-phone" by removing the "+", recognizing
   the international country code as local, and then adding the long
   distance "0" in front of the string:

      global-phone:   +441164960348

   resulting into

       local-phone:   01164960348

   The last example shows how an offramp gateway converts a
   "global-phone" to "local-phone" by removing the "+", recognizing
   the international country code as non local, and then adding the
   local international dialling prefix "00" in front of the string:

      global-phone:   +441164960348

   resulting into

       local-phone:   00441164960348

3.2.2 Support for subaddress

   An offramp gateway SHOULD support the subaddress. In case a subaddress
   is encoded into the left-hand-side of the e-mail address [6], then
   it MUST be used by the offramp gateway as specified in T.33 [14] to
   reach the final GSTN fax recipient.

3.3 Image format conversion

   An offramp gateway MUST convert the file format from TIFF Profile-S
   for Internet Fax (defined in [15]) into the GSTN fax image format.
   The case of other Internet fax file formats is not considered in
   this document.

3.4 Error/return notification handling

   An offramp gateway SHOULD have a function which allows it to send a 
   return notice to the originator Internet fax device (defined in
   [3]) when a transmission error occurs over the GSTN fax service and
   the facsimile is not delivered to destination. The return notice
   MUST be in Message Delivery Notification (MDN) format, delivered
   by the offramp gateway over the Internet e-mail transport service
   used by Internet fax. The MDN disposition-type MUST be set as 
   "processed", and the dispoistion-modifier MUST be set as an "error".

   If the offramp gateway fails to transmit the MDN, the error information
   MAY be recorded to a log, and processing MAY end, or the administrator
   of the gateway system MAY be notified of these errors through a specific
   method (for example, by sending him/her an e-mail message).

   The more complex case of Delivery Status Notification (DSN) requests
   handling is not considered in this document.

4. The Onramp Gateway operations

   An onramp gateway MUST, as minimal requirement, perform the
   following functions:

   - addresses translation/mapping;
   - image format conversion;
   - error/return notification handling.

   and MAY also perform

   - user authorization;

4.1 User authorization

   An onramp gateway MAY have a user authorization function to confirm
   that the user is authorized to transmit facsimile into the Internet
   fax service. For example, user authorization may be accomplished by
   getting a user-ID and password received by DTMF, or via a local
   authorization table based on the GSTN caller-ID.
  
   In case the authorization process fails, then the onramp gateway MUST
   generate an error message/code for the sender of the GSTN Fax.

4.2 Address translation/mapping

   Addresses on Internet Fax service are e-mail addresses, thus a 
   recipient of an Internet fax might be either an e-mail user,
   an Internet fax device with its own recipients/users or an offramp
   gateway. The onramp gateway SHOULD have a functionality in order to
   receive from GSTN (via DTMF) destination addresses. However, there
   are two categories of destination addresses: 

     - e-mail users and Internet Fax recipient/users;
     - real GSTN addresses reached via an offramp gateway.

   We define thus "indirect address mapping" the functionality for
   the first category, and "direct address mapping" the one for the
   second category.

4.2.1 Indirect address mapping

   The onramp gateway MAY implement local address mapping mechanisms
   (via a table or a directory lookup or similar) which permit 
   translation from addresses (called "indirect address number") received
   from the GSTN fax sending device into e-mail addresses. A single or a 
   list of e-mail addresses MAY correspond to a single indirect address 
   number.

   Here is one mapping example:

   (1) An onramp gateway receives the indirect address number "1234"
       from the source GSTN facsimile by DTMF.

          1234

   (2) The destination address is looked up in the address mapping table.

          address mapping table
          1234 : ifax@example.com

   (3) An Internet Fax is sent to the address ("addr-spec")

         ifax@example.com

   "Addr-spec" is defined in Section 6.1 of [13]. 

   If the address mapping lookup fails, and error MUST be reported back
   to the oriiginating GSTN fax device.

4.2.2 Direct address mapping

   If the indirect address mapping specified in 4.2.1 is not implemented
   then only "direct address mapping" can be used. The GSTN sending
   device SHOULD send the full numeric destination address via DTMF 
   to the onramp gateway. Direct address mapping can be used also if the
   indirect address mapping is implemented.

   An example:

   (1) An onramp gateway receives the destination telephone number
       "441164960348" from the source facsimile by DTMF (Dual Tone
       Multi-Frequency).

          441164960348

   (2) The destination number is encoded as a "global-phone", so "+" is
       added at the head of the string.

          +441164960348

   (3) "FAX=" is added in order to build the "fax-mbox" address item

          FAX=+441164960348

   (4) The destination address is completed, adding the specification
       of the appropriate offramp gateway which is suppoused to handle
       the delivery of the fax message to global-phone address.

          FAX=+441164960348@example.com

   The procedure for choosing the domain name of an offramp gateway is
   defined in Section 4.3 (Relay function).

   "Global-phone", "fax-mbox", and "fax-address" are defined in Section
   2 of [6]. "Mta-I-fax" is defined in Section 3 of [6]. "Fax-email" is
   defined in Section 4 of [6].

4.2.3 Sender addresses handling

   The onramp gateway SHOULD gather information about the GSTN fax
   sender address (for example via Caller-ID, if available), and encode
   it as the sender of the Internet fax, using the direct address
   mapping (sections 4.2.2 in this document). The sender address SHOULD
   be completed using the onramp gateway address, unless the onramp
   gateway has available additional information to specify a different
   return path.

   If the onramp gateway does not have any sender address information,
   the Internet fax sender address SHOULD be set either to a "no-reply"
   address, or to an appropriate default mailbox.

4.2.4 Support for subaddress

   An onramp gateway SHOULD support the subaddress. In the case of
   direct address mapping, the subaddress is specified using the
   T.33 [14] specification, and encoded as given in [6]. In the case 
   of indirect address mapping, the subaddress MAY be contained inside
   the address mapping table.

4.3 Relay function

   The onramp gateway SHOULD provide functionality to choose the
   destination offramp gateway by analyzing a destination fax number.
   A possible method to expand or acquire information by the onramp 
   gateway about offramp gateways MAY include keeping cached information
   about sender addresses sent by other onramp gateways.

4.4 File format conversion

   An onramp gateway MUST convert the file format from a facsimile over
   the GSTN to the file format TIFF Profile-S for Internet Fax, as
   defined in [15].

4.6 Return notice handling

   When an onramp gateway receives and analyzes a return notice from the
   Internet fax destination, it MAY have the functionality to send the
   delivery status to a suitable facsimile device on the GSTN through an
   appropriate offramp gateway. The generated notice sent via GSTN fax
   SHOULD contain both the human readable notice information, and the
   original delivery codes.

   If the onramp gateway fails in the transmission of the return
   notice back to GSTN fax service,  the information MAY be recorded
   into a log, and processing MAY end. As an alternate, the administrator
   of the gateway system MAY be notified of these notice with a specific
   method (for example by sending an e-mail message to a mailbox).

5. Security Considerations

   Refer to Section 3.1 (User authorization) for authentication for an
   offramp gateway. OpenPGP [16] [24] can be used to provide authorization
   services instead of S/MIME. Refer to Section 4.1 (User authorization)
   for authentication for an onramp gateway.

   S/MIME and OpenPGP can also be used to encrypt a message. A signed
   or encrypted message is protected while transported along the
   network; however when a message reach an Internet fax gateway,
   either onramp or offramp, this kind of protection cannot be applied
   anymore. Security must rely here on trusted operations of the gateway
   itself. A gateway might have its own certificate/key to improve
   security operations when sending Internet faxes, but as any gateway
   it breaks the end to end security pattern of both S/MIME and PGP.

   Other security mechanisms, like IPsec [17][18][19][20][21] or TLS [22]
   also do not ensure a secure gateway operation.

   Denial of Service attacks are beyond the scope of this document.
   Host Compromise caused by flaws in the implementation is beyond the 
   scope of this document. 

6. References

6.1 Informative group

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

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

6.2 Normative group

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

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

   [4] S. Bradner, "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] C. Allocchio, "Minimal FAX address format in Internet Mail", RFC
       3192, October 2001.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   [23] Mimura et. al., "Guideline of optional services for 
        Internet FAX Gateway", draft-ietf-fax-gateway-options

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

7. Intellectual Property Statement
   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.
   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.
8. Full Copyright Statement
     
   Copyright (C) The Internet Society (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 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 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.

9. 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: keiyoko@msn.com

   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

   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

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

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 Protocol
                  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
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
                       [2]

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.
07  25-March-2002 Separate 6.References into 6.1 Normative groups
                  and 6.2 Informative groups.
08  28-March-2002 Changed sentences in 3.3 user authorization,
                  4.1 Onramp Functions,
                  4.2 Address designation
                  and 5 Security Considerations
                  Rebuild 6. References
09  14-July 2004 Corrections and clarifications.
10  18-July-2004  Rebuild next definition
                  3.3 User authorization
                  3.4 Return notice
                  4.2.1 Immediate address designation
                  4.2.2 Indirect address designation
                  4.3 Relay function
                  5. Security Considerations
11  20-July-2004  6. References 
                  split to Informative and Normative
12  21-Jan-2005   full editorial review
13  23-Feb-2005   Change the example telephone numbers 
                  in Sections 3.2.1 and 4.2.2

Mimura, et. al.            Expires January 2005                 [Page12