WDIFF

draft-ietf-fax-gateway-protocol-11.txt --> draft-ietf-fax-gateway-protocol-12.txt

Internet-Draft: draft-ietf-fax-gateway-protocol-11.txt draft-ietf-fax-gateway-protocol-12.txt K.Yokoyama
T.Satoh
C.Kanaide
TOYO Communication Equipment
July 20 2004
C. Allocchio
Consortium GARR
January 18 2005

Internet FAX Gateway Functions Requirements

Status Of This Memo

This document is an Internet-Draft

By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and is any of which I become aware will be disclosed, in full
conformance accordance with all provisions of Section 10 of RFC2026.
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 obsolete 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 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.

Abstract

An Internet FAX Gateway provides functions which translate facsimile

To allow connectivity between the general switched telephone network (GSTN)
facsimile service (GSTN fax) and the
Internet. e-mail based Internet Fax service
(i-fax) an "Internet FAX Gateway" is required. This document provides information on recommended behaviors
recommendations for the functionality of Internet FAX Gateway functions for email-based Internet Fax. Gateways. In
this context, an offramp means "offramp gateway" provides facsimile data transmission
from i-fax to the GSTN from the Internet, and onramp means facsimile fax; viceversa an "onramp gateway" provides data
transmission form GSTN fax to the Internet from the GSTN. This i-fax. The recommendations in this
document covers apply to the delivery
process of data with equipment which may include integrated service including Internet Fax
terminals, PCs computers with i-fax software on the Internet, and GSTN 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 provides connectivity and translation between Fax
operations built on a
the General Switched Telephone Network (GSTN) facsimile service (GSTN fax) and
the Internet. e-mail based Internet Fax service (i-fax). This document defines
the potential recommended behavior of
devices and applications which support these an Internet Fax Gateway. An Internet Fax operations. Gateways
Gateway can be classified as an onramp, where "onramp", when a facsimile data is translated transferred
from the GSTN fax to the Internet, Internet Fax, and as an offramp, where "offramp", when a facsimile
data
is translated transferred from the Internet Fax to the GSTN. A GSTN fax. For a more detailed
definition of onramps "onramp" and offramps "offramp" within i-fax service, see [1].

This document provides recommendations only for email-based the specific case
hereunder:

1) the operational mode of the Internet Fax is
provided in [1].

Internet FAX Gateway functions for real-time Internet Fax are "store and forward", as
defined in [2]. The scope Section 2.5 of the Internet FAX Gateway defined in this
document is shown below.

1) [1].

2) The format of image data is the data format defined by "simple
mode" in [3].
2) The operational mode is "store and forward",

This document does not apply to the gateway funcions for "real-time
Internet Fax", as described and defined in Section
2.5 of [1]. [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

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

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

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

In both of these cases, facsimile communication between a gateway and the Internet is
based on [3].

The protocols which are discussed 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 are shown below,
and other communication protocols should be referred to in [3]. we will only thus recommend the actions which occur
while

1) The communication protocol between the onramp gateway and converts a fax received from GSTN to forward it
to the
GSTN. Internet Fax service;

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

3. The Offramp Gateway

3.1 Offramp functions operations

An offramp gateway provides a translation function, which is used
when 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 receives MAY have a user authorization function to confirm
that an user is allowed to transmit its Internet Fax and then sends the
facsimile data fax to facsimile devices over the GSTN using fax
service.

As an Internet Fax is sent as a standard
facsimile protocol [5]. The communication protocol between MIME e-mail message until the
offramp gateway 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 submitting Internet Fax device will be based
on [3] (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 standards-based store and forward operations.
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 mailbox string 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: +12223334444

resulting into:

local-phone: 2223334444

The first next example shows how an offramp gateway changes converts 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 "+", recognizing
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 as local, and then adding the
"exit-code" "0" in front of the string:

global-phone: +81355556666

resulting into

local-phone: 0355556666

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

If the string:

global-phone: +41227675566

resulting into

local-phone: 02267635566

The last example shows how an offramp gateway receives the converts a
"global-phone"

+81355556666

The to "local-phone" is the string remaining after by removing "+" and the "+", recognizing
the international country code "81". The "exit-code" "0" is as non local, and then put at
the head of the string, so that adding 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
local international dialling prefix "00" in Section 2.1 front of
[7].

3.3 User authorization the string:

global-phone: +441272276755

resulting into

local-phone: 00441272276755

3.2.2 Support for subaddress

An offramp gateway MAY have a user authorization function to confirm
that SHOULD support the subaddress. In case a user subaddress
is allowed to transmit data.

Digital signatures can be used for encoded into the user authorization function.
For example, S/MIME is one left-hand-side 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 e-mail address [6], then
it MUST be used by the offramp gateway. The function gateway as specified in T.33 [14] to verify signatures is
required for
reach the final GSTN fax recipient.

3.3 Image format conversion

An offramp gateway. And gateway MUST convert the signature information is
used file format from TIFF Profile-S
for determine authorization. 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 Return notice Error/return notification handling

An offramp gateway SHOULD have a function which allows the offramp
gateway it to send a
return notice to the source IFax originator Internet fax device (defined in
[3]) when a transmission error occurs over the GSTN fax service and
the facsimile data is not
transmitted.

When 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 return notice, 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 process
method (for example, SMTP).

An MDN by sending him/her an e-mail message).

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

4. The Onramp Gateway operations

An onramp gateway MUST, as minimal requirement, perform the return notice.
Because of
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 Fax device user is authorized to transmit facsimile into the Internet
fax service. For example, user authorization may be accomplished by
getting a User Agent.
And user-ID and password received by DTMF, or via a local
authorization table based on the offramp GSTN caller-ID.

In case the authorization process fails, then the onramp gateway makes return notice in place MUST
generate an error message/code for the sender of the facsimile
device. A disposition-type is set as a processed and GSTN Fax.

4.2 Address translation/mapping

Addresses on Internet Fax service are e-mail addresses, thus a disposition-modifier is set as
recipient of an error.

Mimura, et. al. Expires January 2005 [Page4] Internet Draft fax might be either an e-mail user,
an Internet FAX Gateway Functions July 2004

4. Onramp Gateway

4.1 Onramp functions
An fax device with its own recipients/users or an offramp
gateway. The onramp gateway MUST SHOULD have a function that allows 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
to receive facsimile data 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 a facsimile device over the GSTN, and

then send the generated Internet Fax to the appropriate IFax devices GSTN fax sending device into e-mail addresses. A single or PC via mail transfer agents. The transmission a
list of data from the
onramp gateway e-mail addresses MAY correspond to IFax devices MUST based on [3].

4.2 Address designation a single indirect address
number.

Here is one mapping example:

(1) An onramp gateway SHOULD have a function that allows receives the onramp
gateway to analyze indirect address number "1234"
from the source GSTN facsimile by DTMF.

1234

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

address mapping table
1234 : ifax@example.com

(3) An Internet Fax is sent
by the facsimile device over to the GSTN. If a GSTN number address ("addr-spec")

ifax@example.com

"Addr-spec" is
transmitted as part of the local portion defined in Section 6.1 of [13].

If the email address, it
SHOULD address mapping lookup fails, and error MUST be in reported back
to the global-phone format. There are two kinds of oriiginating GSTN fax device.

4.2.2 Direct address
data needed next from the Fax device over the GSTN. They are mapping

If the
immediate address designation and indirect address designation. mapping specified in 4.2.1 Immediate address designation
Immediate address designation is not implemented
then only "direct address data from a facsimile device
over the mapping" can be used. The GSTN that specifies sending
device SHOULD send the full numeric destination number directly. It is address via DTMF
to the onramp gateway. Direct address mapping can be used when also if the destination
indirect address mapping is specified every time.

Example implemented.

An 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 encoded 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". build the "fax-mbox" address item

FAX=+12223334444

(4) In this example "fax-mbox" is used as "fax-address". "Fax-email" The destination address is formed by completed, adding "@" and the specification
of the appropriate offramp domain
"mta-I-fax" behind "fax-address". gateway which is suppoused to handle
the delivery of the fax message to global-phone 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 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

4.2.3 Sender addresses handling

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 SHOULD gather information about the indirect GSTN fax
sender address number. This function is used for
transmission to a mail terminal, transmission to an often-used
address, multicast transmission, (for example via Caller-ID, if available), and so on.

An onramp gateway keeps the indirect address information. Or, encode
it is
acquired from another server. Indirect address information contains as the following information.

- Indirect address number
- The list sender of the destination facsimile number and e-mail address,
which is looked up in Internet fax, using the direct address change table
mapping (sections 4.2.2 in this document). The sender address SHOULD
be completed using the indirect
address number.

Example

(1) An onramp gateway receives address, unless the indirect address number "1234"
from onramp
gateway has available additional information to specify a different
return path.

If the source facsimile by DTMF.

1234

(2) The destination onramp gateway does not have any sender address "addr-spec" is looked up in information,
the address
change table.

address change table
1234 : ifax@example.com

(3) An Internet Fax is sent fax sender address SHOULD be set either to a "no-reply"
address, or 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 appropriate default mailbox.

4.2.4 Support for subaddress

An onramp gateway SHOULD support the subaddress. In the case of
immediate
direct address designation, mapping, the subaddress is analyzed specified using the
T.33 [14] protocol. specification, and encoded as given in [6]. In the case
of indirect address designation, the
T.33 protocol is not used; mapping, the subaddress is looked up using the
address change table, and so on, from MAY be contained inside
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. mapping table.

4.3 Relay function

The onramp gateway keeps SHOULD provide functionality to choose the following
destination offramp gateway relay information, by analyzing a destination fax number.
A possible method to expand or acquires it from another server. 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.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 handling

When an onramp gateway receives and analyzes a return notice from the
Internet fax destination, an onramp gateway it MAY have the means functionality to send the
delivery status to a suitable facsimile device user on the GSTN through an
appropriate offramp gateway.

When an 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,
notice back to GSTN fax service, the error information MAY be recorded to
into a log, and processing MAY end, or end. As an alternate, the administrator
of the gateway system MAY be notified of these errors notice with a specific process
method (for example, SMTP). example by sending an e-mail message to a mailbox).

5. Security Considerations

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

S/MIME and OpenPGP are can also be used for the encryption to encrypt a message. A signed
or encrypted message is protected from tapping through while transported along the network system.
IPsec [17][18][19][20][21] is IP layer encryption protocol. IPsec
cannot protect tapping from MTA. Because
network; however when a message reach an Internet fax gateway,
either onramp or offramp, this kind of plaintext is remained in
MTA. TLS [22] runs on TCP layer. TLS protection cannot protect tapping from MTA,
either. 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 OpenPGP are most suitable for authentication and
encryption of IFax messages. 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.

Mimura, et. al. Expires January 2005 [Page7]

Internet Draft Internet FAX Gateway Functions July 2004

6. References

6.1 Informative groups group

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

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

6.2 Normative groups 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 2305, March 1998. 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", RFC 2846, RFC2846, June 2000.

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

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

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

[11] B. Ramsdell, "S/MIME "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3 3.1 Message Specification", RFC 2633, 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.

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
"OpenPGP Message Format?h, 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] Kent, K. Ramakrishnan, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998. 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, "The TLS Protocol Version 1.0", "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 2246, January 1999. 3156,
August 2001.

7. Full Copyright Intellectual Property Statement

This document and translations IETF takes no position regarding the validity or scope of it may any
intellectual property or other rights that might be copied and furnished claimed to
others, and derivative works that comment on or otherwise explain it
or assist in its
pertain to the implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction use of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, technology described in
this document itself may or the extent to which any license under such rights
might or might not be modified in available; neither does it represent that it
has made any effort to identify any way, such as by removing rights. Information on the copyright notice or references
IETF's procedures with respect to the Internet Society or other

Internet organizations, except as needed rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for the purpose publication and any assurances of
developing Internet standards, in which case
licenses to be made available, or the procedures result of an attempt made to
obtain a general license or permission for
copyrights defined in the Internet Standards process must be
followed, use of such
proprietary rights by implementors or as required users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to translate it into languages bring to its attention any
copyrights, patents or patent applications, or other than
English.

The limited permissions granted above are perpetual and will not proprietary
rights which may cover technology that may be
revoked by required to practice
this standard. Please address the information to the IETF Executive
Director.

8. Full Copyright Statement

Copyright (C) The Internet Society or its successors or assigns. (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 is 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 DISCLAIMS 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.

Mimura, et. al. Expires January 2005 [Page9]

Internet Draft Internet FAX Gateway Functions July 2004

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

Mimura, et. al. Expires January 2005 [Page10]

Internet Draft Internet FAX Gateway Functions July 2004

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]

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
12 21-Jan-2005 full editorial review

Mimura, et. al. Expires January 2005 [Page12

----