One document matched: draft-ietf-fax-gateway-protocol-11.txt
Differences from draft-ietf-fax-gateway-protocol-10.txt
Network Working Group K.Mimura
Internet-Draft: draft-ietf-fax-gateway-protocol-11.txt K.Yokoyama
T.Satoh
C.Kanaide
TOYO Communication Equipment
July 20 2004
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 (2004). 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 January 2005 [Page1]
Internet Draft Internet FAX Gateway Functions July 2004
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 January 2005 [Page2]
Internet Draft Internet FAX Gateway Functions July 2004
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 January 2005 [Page3]
Internet Draft Internet FAX Gateway Functions July 2004
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.
Digital signatures can be used for the user authorization function.
For example, S/MIME is one of the digital signatures.
S/MIME is described in [8][9][10][11][12].
An onramp gateway or a client PC send digital-signed S/MIME Fax
message to the offramp gateway. The function to verify signatures is
required for the offramp gateway. And the signature information is
used for determine authorization.
3.4 Return notice
An offramp gateway SHOULD 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).
An MDN is used for the return notice.
Because of the Fax device is a User Agent.
And the offramp gateway makes return notice in place of the facsimile
device. A disposition-type is set as a processed and
a disposition-modifier is set as an error.
Mimura, et. al. Expires January 2005 [Page4]
Internet Draft Internet FAX Gateway Functions July 2004
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
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@example.com
The procedure for choosing the domain name of an offramp gateway is
defined in Section 4.3 (Relay function).
Mimura, et. al. Expires January 2005 [Page5]
Internet Draft Internet FAX Gateway Functions July 2004
"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
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@example.com
(3) An Internet Fax is sent to an Internet Fax device by the onramp
gateway.
"ifax@example.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.
Mimura, et. al. Expires January 2005 [Page6]
Internet Draft Internet FAX Gateway Functions July 2004
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.
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. OpenPGP [16] can be used for the authorization
instead of the S/MIME. Refer to Section 4.5 (User authorization) for
authentication for an onrampgateway.
S/MIME and OpenPGP are also used for the encryption message.
A signed message is protected from tapping through the network system.
IPsec [17][18][19][20][21] is IP layer encryption protocol. IPsec
cannot protect tapping from MTA. Because of plaintext is remained in
MTA. TLS [22] runs on TCP layer. TLS cannot protect tapping from MTA,
either.
S/MIME and OpenPGP are most suitable for authentication and
encryption of IFax messages.
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.
Mimura, et. al. Expires January 2005 [Page7]
Internet Draft Internet FAX Gateway Functions July 2004
6. References
6.1 Informative groups
[1] L. Masinter, "Terminology and Goals for Internet Fax", RFC 2542,
March 1999.
[21] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document
Roadmap", RFC 2411, November 1998.
6.2 Normative groups
[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 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.
Mimura, et. al. Expires January 2005 [Page8]
Internet Draft Internet FAX Gateway Functions July 2004
[16] J. Callas, L. Donnerhacke, H. Finney, R. Thayer, ,
?gOpenPGP Message Format?h, 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] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[20] Piper, D., "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC 2407, November 1998.
[22] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
7. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Mimura, et. al. Expires January 2005 [Page9]
Internet Draft Internet FAX Gateway Functions July 2004
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: 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
Mimura, et. al. Expires January 2005 [Page10]
Internet Draft Internet FAX Gateway Functions July 2004
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]
Mimura, et. al. Expires January 2005 [Page11]
Internet Draft Internet FAX Gateway Functions July 2004
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
Mimura, et. al. Expires January 2005 [Page12| PAFTECH AB 2003-2026 | 2026-04-23 10:27:59 |