Movatterモバイル変換

Network Working Group                                          K. MimuraRequest for Comments: 4160                                   K. YokoyamaCategory: Informational                                         T. Satoh                                                              C. Kanaide                                            TOYO Communication Equipment                                                            C. Allocchio                                                         Consortium GARR                                                             August 2005Internet Fax Gateway RequirementsStatus of This Memo   This memo provides information for the Internet community.  It does   not specify an Internet standard of any kind.  Distribution of this   memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (2005).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; vice versa, 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].Mimura, et al.               Informational                      [Page 1]

RFC 4160           Internet Fax Gateway Requirements         August 2005   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 [4].   This document does not apply to the gateway functions for "real-time   Internet Fax", as described and defined in [3].  Additional   recommendations for optional functionality are described in [24].1.1.  Key Words   The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this   document are to be interpreted as described in [5].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 [4], while the GSTN side of the   gateway acts as a GSTN fax device, as described in [6].   In this document we will only thus recommend the actions that occur   while   1) the onramp gateway converts a fax received from GSTN and forwards      it to the Internet Fax service;   2) the offramp gateway converts a fax received from the Internet and      forwards it to the GSTN fax service.Mimura, et al.               Informational                      [Page 2]

RFC 4160           Internet Fax Gateway Requirements         August 20053.  The Offramp Gateway Operations   An offramp gateway MUST, as a minimal requirement, perform the   following functions:      - address translation/mapping,      - image format conversion, and      - 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 a user is allowed to transmit its Internet Fax to the GSTN fax   service.   Because an Internet Fax is sent as a MIME e-mail message to 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   [9][10][11][12][13].  Other methods of adding a digital signature to   a mail message (such as OpenPGP [17] [25]) MAY also be used to   authenticate and authorize the user.   The agent sending the Internet Fax (which may include 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.  If 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 addresses   which are explicitly itself, i.e., those where the right-hand side of   the e-mail address corresponds to the offramp gateway.   Because addresses on the Internet Fax service are e-mail addresses,   in order to reach a destination in the GSTN fax service, the offramp   gateway MUST convert e-mail addresses into GSTN addresses.Mimura, et al.               Informational                      [Page 3]

RFC 4160           Internet Fax Gateway Requirements         August 2005   The GSTN destination address SHOULD normally be encoded inside the   left-hand side of the e-mail address, according to [7].  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", in accordance with local   dialing rules.   "Global-phone" is defined in Section 2 of [7].  "Local-phone" is   defined in Section 2 of [8].  "Exit-code" is defined inSection 2.1   of [8].   The offramp gateway SHOULD also have a function to apply translation   to originator addresses and other addresses referred to into the   Internet Fax, in order to ensure a possible return path from GSTN fax   service to Internet Fax destinations, including other offramp   gateways.  These functions MUST be compliant with the address   handling of onramp gateways that is described inSection 4.2 of this   document.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 "+" and "44" (recognizing   the international country code is local), and then knowing it can   dial directly without an exit-code:      global-phone:  +441164960348   resulting in:      local-phone:   1164960348   The next example shows how an offramp gateway converts a "global-   phone" to a "local-phone" by removing the "+" and "44" (recognizing   the international country code is local), and then adding the exit-   code "0" in front of the string:      global-phone:   +441164960348   resulting in:      local-phone:   01164960348Mimura, et al.               Informational                      [Page 4]

RFC 4160           Internet Fax Gateway Requirements         August 2005   The next example shows how an offramp gateway converts a "global-   phone" to "local-phone" by removing the "+" and "44" (recognizing the   international country code is local), and then adding the long   distance "0" in front of the string:      global-phone:   +441164960348   resulting in:      local-phone:    01164960348   The last example shows how an offramp gateway converts a "global-   phone" to a "local-phone" by removing the "+", recognizing the   international country code is non-local, and adding the local   international dialing prefix "00" in front of the string:      global-phone:   +441164960348   resulting in:      local-phone:   004411649603483.2.2.  Support for Subaddress   An offramp gateway SHOULD support the subaddress.  If a subaddress is   encoded into the left-hand side of the e-mail address [7], then it   MUST be used by the offramp gateway, as specified in T.33 [15], 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 [16]) into the GSTN fax image format.   Other Internet Fax file formats are not considered in this document.3.4.  Error/Return Notification Handling   An offramp gateway SHOULD have a function that allows it to send a   return notice to the originator Internet Fax device (defined in [4])   when a transmission error occurs over the GSTN fax service and the   facsimile is not delivered to the destination.  The return notice   MUST be in Message Delivery Notification (MDN) format and 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 disposition-modifier MUST be set as an "error".Mimura, et al.               Informational                      [Page 5]

RFC 4160           Internet Fax Gateway Requirements         August 2005   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 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:   - address translation/mapping,   - image format conversion, and   - 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 a facsimile to the Internet   fax service.  For example, user authorization may be accomplished by   getting a user-ID and password received by Dual Tone Multi-Frequency   (DTMF), or via a local authorization table based on the GSTN caller-   ID.   If 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 "indirect address mapping" as the functionality for the   first category, and "direct address mapping" as the functionality for   the second category.Mimura, et al.               Informational                      [Page 6]

RFC 4160           Internet Fax Gateway Requirements         August 20054.2.1.  Indirect Address Mapping   The onramp gateway MAY implement local address mapping mechanisms   (via a table, directory lookup, or something similar) that permit   translation from addresses (called "indirect address numbers")   received from the GSTN fax sending device into e-mail addresses.  A   single e-mail address 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 3.4.1 of [14].   If the address mapping lookup fails, an error MUST be reported to the   originating 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   to the onramp gateway via DTMF.  Direct address mapping can also be   used if indirect address mapping is implemented.   An example:   (1) An onramp gateway receives the destination telephone number       "441164960348" from the source facsimile by DTMF.            441164960348Mimura, et al.               Informational                      [Page 7]

RFC 4160           Internet Fax Gateway Requirements         August 2005   (2) The destination number is encoded as a "global-phone", so "+" is       added to 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 supposed to handle the       delivery of the fax message to a global-phone address.            FAX=+441164960348@example.com   The procedure for choosing the domain name of an offramp gateway is   defined inSection 4.3 ("Relay Function").   "Global-phone", "fax-mbox", and "fax-address" are defined inSection2 of [7].  "Mta-I-fax" is defined in Section 3 of [7].  "Fax-email"   is defined in Section 4 of [7].4.2.3.  Sender Address 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 (seeSection 4.2.2 of this document).  The sender address   SHOULD be completed using the onramp gateway address, unless the   onramp gateway has additional information with which 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 to either a "no-reply"   address or 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   [15] specification, and encoded as given in [7].  In the case of   indirect address mapping, the subaddress MAY be contained inside the   address mapping table.Mimura, et al.               Informational                      [Page 8]

RFC 4160           Internet Fax Gateway Requirements         August 20054.3.  Relay Function   The onramp gateway SHOULD provide functionality for choosing the   destination offramp gateway by analyzing a destination fax number.  A   possible method to expand or acquire information from the onramp   gateway about offramp gateways MAY include keeping cached information   about sender addresses that was 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 [16].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 this notice with a specific method   (for example, by sending an e-mail message to a mailbox).5.  Security Considerations   Refer toSection 3.1 ("User Authorization") for authentication for an   offramp gateway.  OpenPGP [17] [25] can be used to provide   authorization services instead of S/MIME.  Refer toSection 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 reaches an Internet Fax Gateway,   either onramp or offramp, this kind of protection cannot be applied   anymore.  Here, security must rely 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 with   any gateway, it breaks the end-to-end security pattern of both S/MIME   and PGP.   Other security mechanisms, like IPsec [18][19][20][21][2] or TLS [23]   also do not ensure a secure gateway operation.Mimura, et al.               Informational                      [Page 9]

RFC 4160           Internet Fax Gateway Requirements         August 2005   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.  References6.1.  Informative References   [1]  Masinter, L., "Terminology and Goals for Internet Fax",RFC2542, March 1999.   [2]  Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document        Roadmap",RFC 2411, November 1998.6.2.  Normative References   [3]  "Procedures for real-time Group 3 facsimile communication over        IP networks", ITU-T Recommendation T.38, June 1998.   [4]  Toyoda, K., Ohno, H., Murai, J., and D. Wing, "A Simple Mode of        Facsimile Using Internet Mail",RFC 3965, December 2004.   [5]  Bradner, S., "Key words for use in RFCs to Indicate Requirement        Levels",BCP 14,RFC 2119, March 1997.   [6] "Procedures for document facsimile transmission in the general        switched telephone network", ITU-T Recommendation T.30, April        1999.   [7]  Allocchio, C., "Minimal FAX address format in Internet Mail",RFC 3192, October 2001.   [8]  Allocchio, C., "GSTN Address Element Extensions in E-mail        Services",RFC 2846, June 2000.   [9]  Housley, R., "Cryptographic Message Syntax (CMS)",RFC 3852,        July 2004.   [10] Rescorla, E., "Diffie-Hellman Key Agreement Method",RFC 2631,        June 1999.   [11] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions        (S/MIME) Version 3.1 Certificate Handling",RFC 3850, July 2004.   [12] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions        (S/MIME) Version 3.1 Message Specification",RFC 3851, July        2004.Mimura, et al.               Informational                     [Page 10]

RFC 4160           Internet Fax Gateway Requirements         August 2005   [13] Hoffman, P., "Enhanced Security Services for S/MIME",RFC 2634,        June 1999.   [14] Resnick, P., "Internet Message Format",RFC 2822, April 2001.   [15] "Facsimile routing utilizing the subaddress", ITU recommendation        T.33, July 1996.   [16] Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J.        Rafferty, "File Format for Internet Fax",RFC 3949, February        2005.   [17] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP        Message Format",RFC 2440, November 1998.   [18] Kent, S. and R. Atkinson, "Security Architecture for the        Internet Protocol",RFC 2401, November 1998.   [19] Kent, S. and R. Atkinson, "IP Authentication Header",RFC 2402,        November 1998.   [20] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of        Explicit Congestion Notification (ECN) to IP",RFC 3168,        September 2001.   [21] Piper, D., "The Internet IP Security Domain of Interpretation        for ISAKMP",RFC 2407, November 1998.   [23] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and        T. Wright, "Transport Layer Security (TLS) Extensions",RFC3546, June 2003.   [24] Mimura, K., Yokoyama, K., Satoh, T., Watanabe, K., and C.        Kanaide, "Guidelines for Optional Services for Internet Fax        Gateways",RFC 4161, August 2005.   [25] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME        Security with OpenPGP",RFC 3156, August 2001.Mimura, et al.               Informational                     [Page 11]

RFC 4160           Internet Fax Gateway Requirements         August 2005Authors' Addresses   Katsuhiko Mimura   TOYO Communication Equipment CO., LTD.   2-1-1 Koyato, Samukawa-machi, Koza-gun   Kanagawa, Japan   Fax: +81 467 74 5743   EMail: mimu@miyabi-labo.net   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@t-ns.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: icemilk77@yahoo.co.jp   Claudio Allocchio   Consortium GARR   Viale Palmiro Togliatti 1625   00155 Roma, Italy   Fax: +39 040 3758565   EMail: Claudio.Allocchio@garr.itMimura, et al.               Informational                     [Page 12]

RFC 4160           Internet Fax Gateway Requirements         August 2005Full Copyright Statement   Copyright (C) The Internet Society (2005).   This document is subject to the rights, licenses and restrictions   contained inBCP 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.Intellectual Property   The IETF takes no position regarding the validity or scope of any   Intellectual Property Rights 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; nor does it represent that it has   made any independent effort to identify any such rights.  Information   on the procedures with respect to rights in RFC documents can be   found inBCP 78 andBCP 79.   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this   specification can be obtained from the IETF on-line IPR repository athttp://www.ietf.org/ipr.   The IETF invites any interested party to bring to its attention any   copyrights, patents or patent applications, or other proprietary   rights that may cover technology that may be required to implement   this standard.  Please address the information to the IETF at ietf-   ipr@ietf.org.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Mimura, et al.               Informational                     [Page 13]