Network Working Group K.Mimura
Internet-Draft: draft-ietf-fax-gateway-protocol-01.txt K.Yokoyama
T.Satoh
C.Kanaide
TOYO Communicaion Equipment
Aug 16 2000
Internet FAX Gateway Protocol
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 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 (2000). All Rights Reserved.
Abstract
An Internet FAX Gateway provides functions which translate facsimile
between the general switched telephone network (GSTN) the Internet.
This document provides information on recommended behaviors for Internet
Mimura, Expires Feb 2001 [Page1]
Internet Draft Internet FAX Gateway Protocol Aug 2000
FAX Gateways Protocol. In this context, an Offramp means facsimile data
transmission to the GSTN from the Internet, and onramp means facsimile
data transmission to Internet from the GSTN.
This document covers the delivery-process of the data among equipment
which may include Internet Fax terminals, PCs on the Internet and FAX
terminal on GSTN.
The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this
document are to be interpreted as described in [RFC2119].
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>.
Table Of Contents
1. Introduction
2. Internet FAX Gateway Protocol
3. Offramp Gateway
3.1 Offramp functions
3.2 Return notice
3.2.1 When send return notice
3.2.2 Automatic re-transmission in the delivery error occurrence
3.2.3 Information of return notice
3.3 Keep log
4. Onramp Gateway
4.1 Onramp Functions
4.2 Address designation
4.2.1 Support subaddress
4.3 Relay function
4.4 User authorization
4.5 Keep log
4.6 Return notice
5. Security Considerations
6. References
7. Full Copyright Statement
8. Contact
Mimura, Expires Feb 2001 [Page2]
Internet Draft Internet FAX Gateway Protocol Aug 2000
1. Introduction
An Internet FAX Gateway plays a role of gateway between FAX operations
built on the General Switched Telephone Network (GSTN) and the Internet.
This document defines the potential behavior of devices and applications
which serve this purpose. 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 is provided in
[RFC2542].
2. Internet FAX Gateway Protocol
There are two kinds of gateway functions, which are an onramp gateway and
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 Internet FAX from Internet fax capable devices
which may include an onramp gateway and PC over Internet, then sends
facsimile data to facsimile device over GSTN.
In both case described above, facsimile communication between a gateway
and the Internet is based on [RFC2305].
Protocols which are discussed in this document are shown below,and other
communication protocol should be referred in RFC2305.
1) Communication protocol between onramp gateway and GSTN.
2) Communication protocol between offramp gateway and GSTN.
3) Broadcast, return notice
4) Offramp gateway automatic re-transmission function in the event of
delivery failure.
Mimura, Expires Feb 2001 [Page3]
Internet Draft Internet FAX Gateway Protocol Aug 2000
3. Offramp Gateway
3.1 Offramp functions
An offramp gateway provides a translation function, such that the offramp
gateway receives an Internet FAX and then send facsimile data to the
facsimile devices over GSTN using a standard facsmile protocol [T.30].
The Communication protocol between the offramp gateway and the submitting
Internet fax device will be based on RFC 2305 for standards-based store
and forward operations.
An offramp gateway MUST process the mailbox string and convert it to
a local dial string according to the local dialing rules
By the case an offramp gateway detects dupulicate mail.
Such the case an offramp gateway is required to drop the duplicate mail.
This is to avoid the duplication of the transmission to same facsimile
device over GSTN.
For example, an MTA is set to put the mail of the different address in
the same mail box. Some kinds of MTA copy same mail in one mailbox, when
MTA receives broadcast mail (mail of more than one destination address).
Then an offramp gateway receives mail using POP from the MTA.
As a result, the offramp gateway receives dupulicate mail from MTA.
As for the duplicate message detection mechanism, it is entrusted to other
documents.
3.2 Return notice
An offramp gateway MUST have the function which the offramp gateway send
return notice to the source IFAX device, when a transmitting error
occurred then finished with the facsimile data not transmitted.
In order to put into practice this function, it is necessary to SMTP sender
MTA on offramp gateway.
3.2.1 When send return notice
When a offramp gateway receives broadcast mail, there are two way to send
return notice.
An offramp gateway send return notice as soon as an error occurs.
An offramp gateway send return notice at every finish of specified number
of transmissions.
These features should be selectable by the user.
Mimura, Expires Feb 2001 [Page4]
Internet Draft Internet FAX Gateway Protocol Aug 2000
In the case of the offramp gateway send return notice as soon as an error
occurs. A return notice is received by sender, every time an error
occurres. But sender receives many return notice.
3.2.2 Automatic re-transmission in the delivery error occurrence
An offramp gateway MAY add function, that the offramp gateway
automatically retry and permit to send facsimile data when delivery
failure. If this function is enabled, retry times and retry interval MAY
be specified optionally by administrator of offramp gateway.
This case, return notice SHOULD be sent only when last facsimile
transmission is error after specified retry times are finished.
When the Transmission is suspended by the Error, the Transmission is
started to send at error page on Next transmission .
For example, an offramp gateway is sending total 5 pages facsimile data.
But an error occurs and transmittion is stopped after 2 pages are sent
normarry. The offramp gateway should re-transmit the facsimile data from
page 3.
3.3 keep log
An offramp gateway MAY have the function which following information is
kept as log.
Each dataformat is free.
- Date and time when transmit request received
- Source address
- Destination address
- Date and time when transmit over GSTN
- Date and time when transmission was finished over GSTN
- Number of real transmitted page
- Byte count of transmitted data
- Kind of the data (resolution)
- Existence of error occurrence
- Numbers of automatically retry sending
- Date and time of transmitting delivery notice
Mimura, Expires Feb 2001 [Page5]
Internet Draft Internet FAX Gateway Protocol Aug 2000
4. Onramp Gateway
4.1 Onramp Functions
An onramp gateway MUST have the function that the onramp gateway receive
facsimile data from facsimile device over GSTN, then generated Internet
fax is sent to appropriate IFAX devices or PC by the onramp gateway.
How to transmit data from an onramp gateway to IFAX devices MUST based
on RFC 2305.
4.2 Address designation
An onramp gateway MUST have the function that onramp gateway analyze
destination address from address data sent by facsimile device over GSTN
There are two kinds of the next of address data from FAX device over GSTN.
(1) Immediate address designation
Address data from facsimile device over GSTN specify destination
telephone number directly.
It is used when destination is specified every time.
An onlamp gateway is changed in address to use on the Internet by
adding appropriate offramp domain name after specified facsimile
number
< specified facsimile number>@<appropriate offramp domain name>
As for the way of choosing domain name of offramp gateway,
it is described for 4.3 Relay function.
(2) Indirect address designation
Indirect address number is extracted from the address data from
facsimile device on GSTN, and destination address is looked up with
Onramp gateway by using the address change table and so on from the
indirect address number.
This function is used in the case of transmission to the mail terminal,
transmission to an address to use it well, the multicast transmission
and so on.
Onramp Gateway holds indirect address information by itself.
Or, it is acquired from another server.
Mimura, Expires Feb 2001 [Page6]
Internet Draft Internet FAX Gateway Protocol Aug 2000
Indirect address information contains following information.
- Indirect address number
- The list of the destination facsimile number and the E-mail address
looked up from the indirect address number
How to transfer address data makes DTMF (Dual Tone Multi Frequency)
default.
As for the data format, it follows the following format.
# is used for the completion of the DTMF data.
* is used at the head in the case of the indirect address designation.
Immediate address designation: <destination number>#
Indirect address designation: * < indirect address number >#
example
81355551234# : destination facsimile number 81355551234
*1234# : indirect address number 1234
4.2.1 Support subaddress
An onramp gateway SHOULD supports subaddress.
In the case of immediate address designation, subaddress is analyzed by
using [T.33] protocol.
In the case of indirect address designation, T.33 protocol is not used.
subaddress is looked up by using the address change table and so on from
the indirect address number.
4.3 Relay function
Onramp gateway SHOULD have the function which chooses destination offramp
gateway by analyzing a specified destination facsimile number.
Onramp gateway SHOULD hold relay information of offramp gateway to
realize this function.
Onramp gateway holds the following Offramp gateway relay information.
or, acquires from other server.
- Area number (ex. +81:Japan +813:Tokyo etc)
- Domain name of offramp gateway which copes with an area number
Example of offramp gateway relay information
+81 is sent to offramp gateway domain name is offjpn.domain.co.jp
+1 is sent to offramp gateway domain name is offus.domain.com
Mimura, Expires Feb 2001 [Page7]
Internet Draft Internet FAX Gateway Protocol Aug 2000
4.4 User authorization
Onramp gateway MAY have a user authorization function to confirm that
they are the data that suitable user transmitted.
User authorization is done by using user ID, password extracted from DTMF
(Dual Tone Multi Frequency).
DTMF Data format is shown in the following.
<destination number> * <user ID> * <password> #
(*:separater #:terminater)
* < indirect address number > * <user ID> * <password> #
(fierst*:identify indirest address designation other*:separater
#:terminater)
example
8155551234*81467745523*98765# is detect by DTMF
Each data are extracted as follows, and user authorization is done.
Destination facsimile number : 8155551234
User ID : 81467745523
Password : 98765
4.5 keep log
An onramp gateway MAY have the function that following information is kept
as log.
Each data format is free.
- date and time when transmit request received
- source address
- destination address
- date and time when transmit over GSTN
- date and time when transmission was finished over GSTN
- date and time when transmission over Internet
- number of real transmitted page
- byte count of transmitted data
- kind of the data (resolution)
- existence of error occurrence
- number of automatically retry sending
- date and time of transmitting delivery notice
Mimura, Expires Feb 2001 [Page8]
Internet Draft Internet FAX Gateway Protocol Aug 2000
4.6 return notice
When it has a function that receives and analyzes return notice from
destination,an onramp gateway MAY send delivery status to suitable
facsimile device user on GSTN through the appropriate offramp gateway.
This function is used in accordance with the 4.4 user authorization.
5. Security Considerations
The Security Considerations sections of [RFC2305] applies to this
document.
Further security considerations are introduced by this document, but
they will be described in this section prior to pulication as an RFC.
6. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[RFC2305] Toyoda, K., Ohno, H., Murai, J. and D. Wing, "A Simple Mode
of Facsimile Using Internet Mail", RFC 2305, March 1998.
[RFC2542] L. Masinter, "Terminology and Goals for Internet Fax", RFC 2542,
March 1999.
[T.30] "Procedures for document facsimile transmission in the general
switched telephone network", ITU-T Recommendation T.30,
July, 1996.
[T.33] "Facsimile routing utilizing the subaddress"
ITU recommendation T.33, July, 1996.
Mimura, Expires Feb 2001 [Page9]
Internet Draft Internet FAX Gateway Protocol Aug 2000
7. Full Copyright Statement
Copyright (C) The Internet Society (2000). 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, Expires Feb 2001 [Page10]
Internet Draft Internet FAX Gateway Protocol Aug 2000
8. Contact
K.Mimura
TOYO Communication Equipment CO., LTD.
2-1-1 Koyato, Samukawa-machi, Koza-gun
Kanagawa-pref., Japan
Fax: +81 467 74 3934
Email: mimu@toyocom.co.jp
K.Yokoyama
TOYO Communication Equipment CO., LTD.
2-1-1 Koyato, Samukawa-machi, Koza-gun
Kanagawa-pref., Japan
Fax: +81 467 74 3934
Email: k1@toyocom.co.jp
T.Satoh
TOYO Communication Equipment CO., LTD.
2-1-1 Koyato, Samukawa-machi, Koza-gun
Kanagawa-pref., Japan
Fax: +81 467 74 3934
Email: zsatou@toyocom.co.jp
C.Kanaide
TOYO Communication Equipment CO., LTD.
2-1-1 Koyato, Samukawa-machi, Koza-gun
Kanagawa-pref., Japan
Fax: +81 467 74 3934
Email: kanaide@toyocom.co.jp
Mimura, Expires Feb 2001 [Page11]
Internet Draft Internet FAX Gateway Protocol Aug 2000
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.
Mimura, Expires Feb 2001 [Page12]