One document matched: draft-ietf-fax-gateway-protocol-13.txt
Differences from draft-ietf-fax-gateway-protocol-12.txt
Network Working Group K.Mimura
Internet-Draft: draft-ietf-fax-gateway-protocol-13.txt K.Yokoyama
T.Satoh
C.Kanaide
TOYO Communication Equipment
C. Allocchio
Consortium GARR
January 18 2005
Internet FAX Gateway Requirements
Status Of This Memo
By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
To allow connectivity between the general switched telephone network
facsimile service (GSTN fax) and the e-mail based Internet Fax service
(i-fax) an "Internet FAX Gateway" is required. This document provides
recommendations for the functionality of Internet FAX Gateways. In
this context, an "offramp gateway" provides facsimile data transmission
from i-fax to GSTN fax; viceversa an "onramp gateway" provides data
transmission form GSTN fax to i-fax. The recommendations in this
document apply to the integrated service including Internet Fax
terminals, computers with i-fax software on the Internet, and GSTN Fax
terminals on the GSTN.
1. Introduction
An Internet FAX Gateway provides connectivity and translation between
the General Switched Telephone Network facsimile service (GSTN fax) and
the e-mail based Internet Fax service (i-fax). This document defines
the recommended behavior of an Internet Fax Gateway. An Internet Fax
Gateway can be classified as "onramp", when a facsimile is transferred
from GSTN fax to the Internet Fax, and as "offramp", when a facsimile
is transferred from Internet Fax to GSTN fax. For a more detailed
definition of "onramp" and "offramp" within i-fax service, see [1].
This document provides recommendations only for the specific case
hereunder:
1) the operational mode of the Internet Fax is "store and forward", as
defined in Section 2.5 of [1].
2) The format of image data is the data format defined by "simple
mode" in [3].
This document does not apply to the gateway funcions for "real-time
Internet Fax", as described and defined in [2]. Additional
recommendations for optional functionality are described in [23].
1.1 Key words
The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this
document are to be interpreted as described in [4].
1.2 Intellectual property
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights in <http://www.ietf.org/ipr.html>.
2. Internet FAX Gateway operations
An onramp gateway receives a facsimile from a GSTN fax device (which
may include an offramp gateway itself), and generates an Internet Fax
over the Internet which is sent to any Internet Fax device.
An offramp gateway receives an Internet Fax over the Internet from
any Internet Fax-capable device (which may include an onramp gateway
or a PC), and generates a GSTN fax which is sent to any GSTN fax device.
In both of these cases, the Internet side of the gateway acts as an
Internet Fax device, as described in [3], while the GSTN side of the
gateway acts as a GSTN fax device, as described in [5].
In this document we will only thus recommend the actions which occur
while
1) the onramp gateway converts a fax received from GSTN to forward it
to the Internet Fax service;
2) the offramp gateway converts a fax received from the Intenret and
forwards it to the GSTN fax service.
3. The Offramp Gateway operations
An offramp gateway MUST, as minimal requirement, perform the
following functions:
- addresses translation/mapping;
- image format conversion;
- error/return notification handling;
and MAY also perform
- user authorization;
3.1 User authorization
An offramp gateway MAY have a user authorization function to confirm
that an user is allowed to transmit its Internet fax to the GSTN fax
service.
As an Internet Fax is sent as a MIME e-mail message until the
offramp gateway, digital signatures can be used to authenticate and
authorize the user. S/MIME is one example of a protocol that includes
digital signature services. S/MIME is described in [8][9][10][11][12].
Other methods to add a digital signature to a mail message (like
OpenPGP [16] [24]) MAY also be used to authenticate and authorize the
user.
The agent sending the Internet Fax (which may include an an onramp
gateway) sends the digitally-signed S/MIME or OpenPGP Fax message to
the offramp gateway. The offramp gateway then compares the credentials
of the user to determine if he/she is authorized to send faxes to
the GSTN fax service. In case the authorization process fails, then
the offramp gateway MUST generate an error delivery notification for
the sender of the Internet Fax.
3.2 Addressing
An Internet fax may contain multiple e-mail addresses, both as
originators, and as recipients. For its forwarding function to GSTN
fax service, an offramp gateway MUST only consider those ones which
are explicitly addressed to itself, i.e. those where the right hand
side of the e-mail address corresponds to the offramp gateway itself.
As addresses on Internet Fax service are e-mail addresses, in order to
reach a destination in GSTN fax service, the offramp gateway MUST
convert e-mail addresses into GSTN addresses.
The GSTN destination address SHOULD normally be encoded inside the
left hand side of the e-mail address, according to [6]. However, an
offramp gateway MAY use locally implemented translation rules to map
left hand side strings into GSTN addresses.
In any case the offramp gateway MUST process the resultant GSTN
address, and convert it to a "local-phone" according to local
dialing rules.
"Global-phone" is defined in Section 2 of [6]. "Local-phone" is
defined in Section 2 of [7]. "Exit-code" is defined in Section 2.1 of
[7].
The offramp gateway SHOULD also have a function to apply translation
to originator and other addresses referred to into the Internet fax
in order to ensure a possible return path from GSTN fax service
into Internet fax destinations, including other offramp gateways.
These functions MUST be compliant with the address handling of
onramp gateways described in this document, section 4.2.
3.2.1 Examples of local dialing rules applied to GSTN destination
addresses
The first example shows how an offramp gateway converts a
"global-phone" to a "local-phone" by removing the "+", recognizing
the international country code "1" as the local one and thus removing
it, and knowing it can directly dial without any exit code:
global-phone: +441164960348
resulting into:
local-phone: 1164960348
The next example shows how an offramp gateway converts a
"global-phone" to "local-phone" by removing the "+", recognizing
the international country code as local, and then adding the
"exit-code" "0" in front of the string:
global-phone: +441164960348
resulting into
local-phone: 01164960348
The next example shows how an offramp gateway converts a
"global-phone" to "local-phone" by removing the "+", recognizing
the international country code as local, and then adding the long
distance "0" in front of the string:
global-phone: +441164960348
resulting into
local-phone: 01164960348
The last example shows how an offramp gateway converts a
"global-phone" to "local-phone" by removing the "+", recognizing
the international country code as non local, and then adding the
local international dialling prefix "00" in front of the string:
global-phone: +441164960348
resulting into
local-phone: 00441164960348
3.2.2 Support for subaddress
An offramp gateway SHOULD support the subaddress. In case a subaddress
is encoded into the left-hand-side of the e-mail address [6], then
it MUST be used by the offramp gateway as specified in T.33 [14] to
reach the final GSTN fax recipient.
3.3 Image format conversion
An offramp gateway MUST convert the file format from TIFF Profile-S
for Internet Fax (defined in [15]) into the GSTN fax image format.
The case of other Internet fax file formats is not considered in
this document.
3.4 Error/return notification handling
An offramp gateway SHOULD have a function which allows it to send a
return notice to the originator Internet fax device (defined in
[3]) when a transmission error occurs over the GSTN fax service and
the facsimile is not delivered to destination. The return notice
MUST be in Message Delivery Notification (MDN) format, delivered
by the offramp gateway over the Internet e-mail transport service
used by Internet fax. The MDN disposition-type MUST be set as
"processed", and the dispoistion-modifier MUST be set as an "error".
If the offramp gateway fails to transmit the MDN, the error information
MAY be recorded to a log, and processing MAY end, or the administrator
of the gateway system MAY be notified of these errors through a specific
method (for example, by sending him/her an e-mail message).
The more complex case of Delivery Status Notification (DSN) requests
handling is not considered in this document.
4. The Onramp Gateway operations
An onramp gateway MUST, as minimal requirement, perform the
following functions:
- addresses translation/mapping;
- image format conversion;
- error/return notification handling.
and MAY also perform
- user authorization;
4.1 User authorization
An onramp gateway MAY have a user authorization function to confirm
that the user is authorized to transmit facsimile into the Internet
fax service. For example, user authorization may be accomplished by
getting a user-ID and password received by DTMF, or via a local
authorization table based on the GSTN caller-ID.
In case the authorization process fails, then the onramp gateway MUST
generate an error message/code for the sender of the GSTN Fax.
4.2 Address translation/mapping
Addresses on Internet Fax service are e-mail addresses, thus a
recipient of an Internet fax might be either an e-mail user,
an Internet fax device with its own recipients/users or an offramp
gateway. The onramp gateway SHOULD have a functionality in order to
receive from GSTN (via DTMF) destination addresses. However, there
are two categories of destination addresses:
- e-mail users and Internet Fax recipient/users;
- real GSTN addresses reached via an offramp gateway.
We define thus "indirect address mapping" the functionality for
the first category, and "direct address mapping" the one for the
second category.
4.2.1 Indirect address mapping
The onramp gateway MAY implement local address mapping mechanisms
(via a table or a directory lookup or similar) which permit
translation from addresses (called "indirect address number") received
from the GSTN fax sending device into e-mail addresses. A single or a
list of e-mail addresses MAY correspond to a single indirect address
number.
Here is one mapping example:
(1) An onramp gateway receives the indirect address number "1234"
from the source GSTN facsimile by DTMF.
1234
(2) The destination address is looked up in the address mapping table.
address mapping table
1234 : ifax@example.com
(3) An Internet Fax is sent to the address ("addr-spec")
ifax@example.com
"Addr-spec" is defined in Section 6.1 of [13].
If the address mapping lookup fails, and error MUST be reported back
to the oriiginating GSTN fax device.
4.2.2 Direct address mapping
If the indirect address mapping specified in 4.2.1 is not implemented
then only "direct address mapping" can be used. The GSTN sending
device SHOULD send the full numeric destination address via DTMF
to the onramp gateway. Direct address mapping can be used also if the
indirect address mapping is implemented.
An example:
(1) An onramp gateway receives the destination telephone number
"441164960348" from the source facsimile by DTMF (Dual Tone
Multi-Frequency).
441164960348
(2) The destination number is encoded as a "global-phone", so "+" is
added at the head of the string.
+441164960348
(3) "FAX=" is added in order to build the "fax-mbox" address item
FAX=+441164960348
(4) The destination address is completed, adding the specification
of the appropriate offramp gateway which is suppoused to handle
the delivery of the fax message to global-phone address.
FAX=+441164960348@example.com
The procedure for choosing the domain name of an offramp gateway is
defined in Section 4.3 (Relay function).
"Global-phone", "fax-mbox", and "fax-address" are defined in Section
2 of [6]. "Mta-I-fax" is defined in Section 3 of [6]. "Fax-email" is
defined in Section 4 of [6].
4.2.3 Sender addresses handling
The onramp gateway SHOULD gather information about the GSTN fax
sender address (for example via Caller-ID, if available), and encode
it as the sender of the Internet fax, using the direct address
mapping (sections 4.2.2 in this document). The sender address SHOULD
be completed using the onramp gateway address, unless the onramp
gateway has available additional information to specify a different
return path.
If the onramp gateway does not have any sender address information,
the Internet fax sender address SHOULD be set either to a "no-reply"
address, or to an appropriate default mailbox.
4.2.4 Support for subaddress
An onramp gateway SHOULD support the subaddress. In the case of
direct address mapping, the subaddress is specified using the
T.33 [14] specification, and encoded as given in [6]. In the case
of indirect address mapping, the subaddress MAY be contained inside
the address mapping table.
4.3 Relay function
The onramp gateway SHOULD provide functionality to choose the
destination offramp gateway by analyzing a destination fax number.
A possible method to expand or acquire information by the onramp
gateway about offramp gateways MAY include keeping cached information
about sender addresses sent by other onramp gateways.
4.4 File format conversion
An onramp gateway MUST convert the file format from a facsimile over
the GSTN to the file format TIFF Profile-S for Internet Fax, as
defined in [15].
4.6 Return notice handling
When an onramp gateway receives and analyzes a return notice from the
Internet fax destination, it MAY have the functionality to send the
delivery status to a suitable facsimile device on the GSTN through an
appropriate offramp gateway. The generated notice sent via GSTN fax
SHOULD contain both the human readable notice information, and the
original delivery codes.
If the onramp gateway fails in the transmission of the return
notice back to GSTN fax service, the information MAY be recorded
into a log, and processing MAY end. As an alternate, the administrator
of the gateway system MAY be notified of these notice with a specific
method (for example by sending an e-mail message to a mailbox).
5. Security Considerations
Refer to Section 3.1 (User authorization) for authentication for an
offramp gateway. OpenPGP [16] [24] can be used to provide authorization
services instead of S/MIME. Refer to Section 4.1 (User authorization)
for authentication for an onramp gateway.
S/MIME and OpenPGP can also be used to encrypt a message. A signed
or encrypted message is protected while transported along the
network; however when a message reach an Internet fax gateway,
either onramp or offramp, this kind of protection cannot be applied
anymore. Security must rely here on trusted operations of the gateway
itself. A gateway might have its own certificate/key to improve
security operations when sending Internet faxes, but as any gateway
it breaks the end to end security pattern of both S/MIME and PGP.
Other security mechanisms, like IPsec [17][18][19][20][21] or TLS [22]
also do not ensure a secure gateway operation.
Denial of Service attacks are beyond the scope of this document.
Host Compromise caused by flaws in the implementation is beyond the
scope of this document.
6. References
6.1 Informative group
[1] L. Masinter, "Terminology and Goals for Internet Fax", RFC2542,
March 1999.
[21] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document
Roadmap", RFC2411, November 1998.
6.2 Normative group
[2] "Procedures for real-time Group 3 facsimile communication over IP
networks", ITU-T Recommendation T.38, June 1998.
[3] K. Toyoda, H. Ohno, J. Murai and D. Wing, "A Simple Mode of
Facsimile Using Internet Mail", RFC 3965, December 2004.
[4] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[5] "Procedures for document facsimile transmission in the general
switched telephone network", ITU-T Recommendation T.30, April
1999.
[6] C. Allocchio, "Minimal FAX address format in Internet Mail", RFC
3192, October 2001.
[7] C. Allocchio, "GSTN Address Element Extensions in E-mail
Services", RFC2846, June 2000.
[8] R. Housley, "Cryptographic Message Syntax", RFC3852, July 2004.
[9] E. Rescorla, "Diffie-Hellman Key Agreement Method", RFC2631,
June 1999.
[10] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Certificate Handling ", RFC3850, June 1999.
[11] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification ", RFC3851, June 1999.
[12] P. Hoffman, "Enhanced Security Services for S/MIME", RFC2634,
June 1999.
[13] D. Crocker, "Standard for the format of ARPA Internet text
messages", STD 11, RFC 822, August 1982.
[14] "Facsimile routing utilizing the subaddress", ITU recommendation
T.33, July 1996.
[15] L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J.
Rafferty, "File Format for Internet Fax", RFC 2301, March 1998.
[16] J. Callas, L. Donnerhacke, H. Finney, R. Thayer, ,
"OpenPGP Message Format", RFC2440, November 1998.
[17] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[18] Kent, S. and R. Atkinson, "IP Authentication Header", RFC2402,
November 1998.
[19] K. Ramakrishnan, S. Floyd, D. Black, "The Addition of Explicit
Congestion Notification (ECN) to IP", RFC3168, September 2001.
[20] Piper, D., "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC 2407, November 1998.
[22] Dierks, T. and C. Allen, "Transport Layer Security (TLS)
Extensions", RFC3456, June 2003.
[23] Mimura et. al., "Guideline of optional services for
Internet FAX Gateway", draft-ietf-fax-gateway-options
[24] Elkins et. al., "MIME Security with OpenPGP", RFC 3156,
August 2001.
7. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
8. Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
9. Author's Address
Katsuhiko Mimura
TOYO Communication Equipment CO., LTD.
2-1-1 Koyato, Samukawa-machi, Koza-gun
Kanagawa, Japan
Fax: +81 467 74 5743
Email: mimu@macroware.co.jp
Keiichi Yokoyama
TOYO Communication Equipment CO., LTD.
2-1-1 Koyato, Samukawa-machi, Koza-gun
Kanagawa, Japan
Fax: +81 467 74 5743
Email: keiyoko@msn.com
Takahisa Satoh
TOYO Communication Equipment CO., LTD.
2-1-1 Koyato, Samukawa-machi, Koza-gun
Kanagawa, Japan
Fax: +81 467 74 5743
Email: zsatou@toyocom.co.jp
Chie Kanaide
TOYO Communication Equipment CO., LTD.
2-1-1 Koyato, Samukawa-machi, Koza-gun
Kanagawa, Japan
Fax: +81 467 74 5743
Email: c-miwa@mail.nissan.co.jp
Claudio Allocchio
Consortium GARR
Viale Palmiro Togliatti 1625
00155 Roma, Italy
Fax: +39 040 3758565
Email: Claudio.Allocchio@garr.it
Revision history
[[[RFC editor: Please remove this section on publication]]]
00a 10-Jul-2000 Initial draft.
01a 16-Aug-2000 Remove next section.
Authentication
Authentication toward Offramp gateway
Option function
Multicasts transmit request
Rename next section
to Relay function from Choice of Offramp gateway
to User authorization from User authentication
to Immediate address designation from Direct
address designation
Section Drop the duplicate mail was moved to a part
of the section Offramp functions.
Corrections and clarifications.
02a 30-Oct-2000 Title is changed from Internet FAX Gateway Protocol
to Internet FAX Gateway Functions
Remove next definition.
Drop duplications for Broadcast
When send return notice
Automatic re-transmission
keep log for offramp gateway
Example of User authorization
keep log for onramp gateway
Rebuild next definition
3.2 Addressing
3.2.1 example of local dialing rules
4.2.1 Immediate address designation
4.2.2 Indirect address designation
4.4 File format conversion
03a 21-Feb-2001 Rebuild next definition
1. 1)
3.4 Return notice
4.6 Return notice
Add next definition
3.3 User authorization
04a 22-May-2001 Rebuild next definition
3.4 Return notice
4.6 Return notice
5. Security Considerations
05a 28-June-2001 Rebuild next definition
Abstract
1. Introduction
4.2 Address designation
Add to References
[2]
06a 19-Septembert-2001 Rebuild next definition
5. Security Considerations
6a 20-March-2002 Corrections and clarifications.
Moved Intellectual Property and keywords
after section 1.
Fixed Security considerations.
07 25-March-2002 Separate 6.References into 6.1 Normative groups
and 6.2 Informative groups.
08 28-March-2002 Changed sentences in 3.3 user authorization,
4.1 Onramp Functions,
4.2 Address designation
and 5 Security Considerations
Rebuild 6. References
09 14-July 2004 Corrections and clarifications.
10 18-July-2004 Rebuild next definition
3.3 User authorization
3.4 Return notice
4.2.1 Immediate address designation
4.2.2 Indirect address designation
4.3 Relay function
5. Security Considerations
11 20-July-2004 6. References
split to Informative and Normative
12 21-Jan-2005 full editorial review
13 23-Feb-2005 Change the example telephone numbers
in Sections 3.2.1 and 4.2.2
Mimura, et. al. Expires January 2005 [Page12
| PAFTECH AB 2003-2026 | 2026-04-23 10:28:00 |