Network Working Group K.Mimura
Internet-Draft: draft-ietf-fax-gateway-protocol-09.txt K.Yokoyama
T.Satoh
C.Kanaide
TOYO Communication Equipment
April 14 2003
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 (2003). All Rights Reserved.
Abstract
An Internet FAX Gateway provides functions which translate facsimile
between the general switched telephone network (GSTN) and the
Internet. This document provides information on recommended behaviors
for Internet FAX Gateway 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 the Internet from the GSTN. This document covers the delivery
process of data with equipment which may include Internet Fax
terminals, PCs on the Internet, and Fax terminals on the GSTN.
Table Of Contents
1. Introduction
1.1 Key words
1.2 Intellectual property
2. Internet FAX Gateway Protocol
Mimura, et. al. Expires October 2003 [Page1]
Internet Draft Internet FAX Gateway Functions April 2003
3. Offramp Gateway
3.1 Offramp functions
3.2 Addressing
3.2.1 Examples 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
6.1 Informative groups
6.2 Normative groups
7. Full Copyright Statement
8. Author's Address
1. Introduction
An Internet FAX Gateway plays the role of gateway between Fax
operations built on a General Switched Telephone Network (GSTN) and
the Internet. This document defines the potential behavior of
devices and applications which support these Fax operations. 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 [1].
Internet FAX Gateway functions for real-time Internet Fax are defined
in [2]. The scope of the Internet FAX Gateway defined in this
document is shown below.
1) The format of image data is the data format defined by "simple
mode" in [3].
2) The operational mode is "store and forward", as defined in Section
2.5 of [1].
1.1 Key words
The key words "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
Mimura, et. al. Expires October 2003 [Page2]
Internet Draft Internet FAX Gateway Functions April 2003
document. For more information consult the online list of claimed
rights in <http://www.ietf.org/ipr.html>.
2. Internet FAX Gateway Protocol
There are two kinds of gateway functions: an onramp gateway and an
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 an Internet Fax over the Internet from Internet Fax-capable
devices, which may include an onramp gateway and a PC, then sends the
facsimile data to a facsimile device over the GSTN. In both of these
cases, facsimile communication between a gateway and the Internet is
based on [3].
The protocols which are discussed in this document are shown below,
and other communication protocols should be referred to in [3].
1) The communication protocol between the onramp gateway and the
GSTN.
2) The communication protocol between the offramp gateway and the
GSTN.
3. Offramp Gateway
3.1 Offramp functions
An offramp gateway provides a translation function, which is used
when the offramp gateway receives an Internet Fax and then sends the
facsimile data to facsimile devices over the GSTN using a standard
facsimile 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
An offramp gateway MUST process the mailbox string and convert it to
a "local-phone" according to local dialing rules.
3.2.1 Examples of local dialing rules
The first example shows how an offramp gateway changes a
"global-phone" to a "local-phone" by removing "+" and the
international country code.
If an offramp gateway receives the "global-phone"
+12223334444
The "local-phone" is the string remaining after removing "+" and the
international country code "1" from "global-phone". Therefore,
"local-phone" is
2223334444
Mimura, et. al. Expires October 2003 [Page3]
Internet Draft Internet FAX Gateway Functions April 2003
The next example shows how an offramp gateway changes a
"global-phone" to "local-phone" by removing "+" and the international
country code. Then, the "exit-code" "0" is put at the head of the
string.
If the offramp gateway receives the "global-phone"
+81355556666
The "local-phone" is the string remaining after removing "+" and the
international country code "81". The "exit-code" "0" is then put at
the head of the string, so that the result from "global-phone"
indirectly and "local-phone" directly is
0355556666
"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].
3.3 User authorization
An offramp gateway MAY have a user authorization function to confirm
that a user is allowed to transmit data.
An example of the user authorization function for the offramp gateway
is shown below.
1) Enciphering of the user authorization and facsimile data is
performed by the existing SMTP, such as S/MIME, using an available
security technique. S/MIME is described in [8][9][10][11][12].
2) The distribution demand from the user who is permitted to use the
Internet FAX Gateway is received using the user authorization
function and e-mail transmitting function of the WWW.
3.4 Return notice
An offramp gateway MUST have a function which allows the offramp
gateway to send a return notice to the source IFax device (defined in
[3]) when a transmission error occurs and the facsimile data is not
transmitted.
When the offramp gateway fails to transmit the return notice, 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 process (for example, SMTP).
4. Onramp Gateway
4.1 Onramp functions
An onramp gateway MUST have a function that allows the onramp gateway
to receive facsimile data from a facsimile device over the GSTN, and
Mimura, et. al. Expires October 2003 [Page4]
Internet Draft Internet FAX Gateway Functions April 2003
then send the generated Internet Fax to the appropriate IFax devices
or PC via mail transfer agents. The transmission of data from the
onramp gateway to IFax devices MUST based on [3].
4.2 Address designation
An onramp gateway SHOULD have a function that allows the onramp
gateway to analyze the destination address from the address data sent
by the facsimile device over the GSTN. If a GSTN number is
transmitted as part of the local portion of the email address, it
SHOULD be in the global-phone format. There are two kinds of address
data needed next from the Fax device over the GSTN. They are the
immediate address designation and indirect address designation.
4.2.1 Immediate address designation
Immediate address designation is address data from a facsimile device
over the GSTN that specifies the destination number directly. It is
used when the destination is specified every time.
Example
(1) An onramp gateway receives the destination telephone number
"12223334444" from the source facsimile by DTMF (Dual Tone
Multi-Frequency).
12223334444
(2) The destination number is used as a "global-phone", so "+" is
added at the head of the string.
+12223334444
(3) "FAX=" is added at the head of "global-phone" in order to change
"global-phone" into "fax-mbox".
FAX=+12223334444
(4) In this example "fax-mbox" is used as "fax-address". "Fax-email"
is formed by adding "@" and the appropriate offramp domain
"mta-I-fax" behind "fax-address".
FAX=+12223334444@offdomain.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.2 Indirect address designation
The indirect address number is extracted from the address data from
Mimura, et. al. Expires October 2003 [Page5]
Internet Draft Internet FAX Gateway Functions April 2003
the facsimile device on the GSTN, and the onramp gateway looks up the
destination address by using the address change table, and so on,
from the indirect address number. This function is used for
transmission to a mail terminal, transmission to an often-used
address, multicast transmission, and so on.
An onramp gateway keeps the indirect address information. Or, it is
acquired from another server. Indirect address information contains
the following information.
- Indirect address number
- The list of the destination facsimile number and e-mail address,
which is looked up in the address change table using the indirect
address number.
Example
(1) An onramp gateway receives the indirect address number "1234"
from the source facsimile by DTMF.
1234
(2) The destination address "addr-spec" is looked up in the address
change table.
address change table
1234 : ifax@ifdomain.com
(3) An Internet Fax is sent to an Internet Fax device by the onramp
gateway.
"ifax@ifdomain.com"
"Addr-spec" is defined in Section 6.1 of [13].
4.2.3 Support subaddress
An onramp gateway SHOULD support the subaddress. In the case of
immediate address designation, the subaddress is analyzed using the
T.33 [14] protocol. In the case of indirect address designation, the
T.33 protocol is not used; the subaddress is looked up using the
address change table, and so on, from the indirect address number.
4.3 Relay function
The onramp gateway SHOULD have a function which chooses the
destination offramp gateway by analyzing a specified destination
facsimile number. The onramp gateway SHOULD keep the relay
information of the offramp gateway to carry out this function. The
onramp gateway keeps the following offramp gateway relay information,
or acquires it from another server.
Mimura, et. al. Expires October 2003 [Page6]
Internet Draft Internet FAX Gateway Functions April 2003
- Area number (ex. +81:Japan +813:Tokyo etc)
- Domain name of offramp gateway which comes with an area number
An example of offramp gateway relay information
+81 is sent to the offramp gateway. The domain name is
offjpn.domain.co.jp
+1 is sent to the offramp gateway. The domain name is
offus.domain.com
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.5 User authorization
An onramp gateway MAY have a user authorization function to confirm
that the user is authorized to transmit data.
For example, user authorization is performed through a user ID and
password extracted from DTMF.
4.6 Return notice
When an onramp gateway receives and analyzes a return notice from the
destination, an onramp gateway MAY have the means to send the
delivery status to a suitable facsimile device user on the GSTN
through an appropriate offramp gateway.
When an onramp gateway fails in the transmission of the return
notice, 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 with a specific process (for example, SMTP).
5. Security Considerations
Refer to Section 3.3 (User authorization) for authentication for an
offramp gateway. Refer to Section 4.5 (User authorization) for
authentication for an onramp gateway.
The security consideration sections of [3] apply to this document.
6. References
6.1 Informative groups
[1] L. Masinter, "Terminology and Goals for Internet Fax", RFC 2542,
March 1999.
6.2 Normative groups
[2] "Procedures for real-time Group 3 facsimile communication over IP
networks", ITU-T Recommendation T.38, June 1998.
Mimura, et. al. Expires October 2003 [Page7]
Internet Draft Internet FAX Gateway Functions April 2003
[3] K. Toyoda, H. Ohno, J. Murai and D. Wing, "A Simple Mode of
Facsimile Using Internet Mail", RFC 2305, March 1998.
[4] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[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", RFC 2846, June 2000.
[8] R. Housley, "Cryptographic Message Syntax", RFC2630, June 1999.
[9] E. Rescorla, "Diffie-Hellman Key Agreement Method", RFC 2631,
June 1999.
[10] B. Ramsdell, "S/MIME Version 3 Certificate Handling", RFC 2632,
June 1999.
[11] B. Ramsdell, "S/MIME Version 3 Message Specification", RFC 2633,
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.
7. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Mimura, et. al. Expires October 2003 [Page8]
Internet Draft Internet FAX Gateway Functions April 2003
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. Author's Address
Katsuhiko Mimura
TOYO Communication Equipment CO., LTD.
2-1-1 Koyato, Samukawa-machi, Koza-gun
Kanagawa, Japan
Fax: +81 467 74 5743
Email: mimu@macroware.co.jp
Keiichi Yokoyama
TOYO Communication Equipment CO., LTD.
2-1-1 Koyato, Samukawa-machi, Koza-gun
Kanagawa, Japan
Fax: +81 467 74 5743
Email: yokoyama@macroware.co.jp
Takahisa Satoh
TOYO Communication Equipment CO., LTD.
2-1-1 Koyato, Samukawa-machi, Koza-gun
Kanagawa, Japan
Fax: +81 467 74 5743
Email: zsatou@toyocom.co.jp
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
Mimura, et. al. Expires October 2003 [Page9]
Internet Draft Internet FAX Gateway Functions April 2003
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
Mimura, et. al. Expires October 2003 [Page10]
Internet Draft Internet FAX Gateway Functions April 2003
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-April-2003 Corrections and clarifications.
Mimura, et. al. Expires October 2003 [Page11]