One document matched: draft-ietf-fax-gateway-protocol-00.txt
Network Working Group K.Mimura
Internet-Draft: draft-ietf-fax-gateway-protocol-00.txt K.Yokoyama
T.Satoh
C.Kanaide
TOYO Communicaion Equipment
July 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 incorporates the facsimile on general switched
telephone network (GSTN) into Internet by translating data and protocol
between them.
This document specifies an Internet FAX Gateway Protocol, especially
describes behavior of offramp/onramp gateway making reference to neither
authentication nor security, where offramp means facsimile data
transmission to GSTN from Internet, and onramp means facsimile data
transmission to Internet from GSTN.
Behavior of offramp/onramp covers the delivery-process of the data among
equipments including IFAX terminal, PC on Internet and FAX terminal on
GSTN.
Mimura, Expires July 2000 [Page1]
Internet Draft Internet FAX Gateway Protocol July 2000
The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this
document are to be interpreted as described in [RFC2119].
Table Of Contents
1. Introduction
2. Internet FAX Gateway Protocol
3. Offramp Gateway
3.1 Offramp functions
3.2 drop the duplicate mail
3.3 return notice
3.3.1 When send return notice
3.3.2 Automatic re-transmission in the delivery error occurrence
3.3.3 Information of return notice
3.4 Authentication
3.5 keep log
4. Onramp Gateway
4.1 Onramp Functions
4.2 Address designation
4.2.1 Support subaddress
4.3 Choice of Offramp gateway
4.4 User authentication
4.5 Authentication toward Offramp gateway
4.6 keep log
4.7 Option function
4.8 return notice
4.9 Multicasts transmit request
5. Security Considerations
6. Acknowledgments
7. Full Copyright Statement
8. Contact
Mimura, Expires July 2000 [Page2]
Internet Draft Internet FAX Gateway Protocol July 2000
1. Introduction
An Internet FAX Gateway play a role of the gateway between FAX network
built on GSTN and Internet. An Internet FAX Gateway Protocol is
implemented for this purpose and is classified in offramp and onramp,
where offramp means direction of transmission from Internt to GSTN and
onramp means the opposite direction against offramp. In these protocols,
there are 3 latent subjects as follows.
1) What is appropriate architecture to implement multicast function and
how to notify the acknowledgement.
2) How to implement the function of automatic re-transmission
when transmission error is occurred.
3) How to specify the destination address at onramp process.
This document outlines offramp / onramp protocols, and also specifies
how these protocols are correlated with 3 subjects described above.
The solution on these problem is beyond the scope of this document.
2. Internet FAX Gateway Protocol
To realize onramp and offramp, gateway needs two kind of gateway function,
which is onramp gateway and offramp gateway.
An onramp gateway receives facsimile data from facsimile device over GSTN,
then send Internet FAX to IFAX and / or PC over Internet including offramp
gateway. An offramp gateway receives Internet FAX from IFAX devices
including onramp gateway and PC over Internet, then send facsimile data
to facsimile device over GSTN.
In both case described above, data communication between a gateway and
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) Multicast, return notice
4) Offramp gateway automatically retry to send facsimile data when
delivery failure
Mimura, Expires July 2000 [Page3]
Internet Draft Internet FAX Gateway Protocol July 2000
3. Offramp Gateway
3.1 Offramp functions
An offramp gateway MUST have the function, that offramp gateway receive
Internet FAX from IFAX devices include PC over Internet, then send
facsimile data to the facsimile devices over GSTN.
Communication protocol between offramp gateway and destination IFAX
device MUST be based on RFC 2305.
3.2 drop the duplicate mail
An offramp gateway MUST drop the duplicate mail by confirming whether
Message-ID is the same as old one.
This is to avoid the duplication of the transmission to same facsimile
device over GSTN.
3.3 return notice
An offramp gateway SHOULD 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.3.1 When send return notice
Transmitting time to facsimile terminal over GSTN from offramp gateway
changes by the case. Transmitting time changes by the performance of FAX
and the circuit condition. It is important when to transmit return notice
in the multi-cast transmission.
When a onramp gateway received Internet FAX which specify multiple
destination facsimile devices (multicast request), there are two methods
to send return notice from the onramp gateway to the source IFAX device.
The onramp gateway send return notice, when every time an error occurs.
Or send return notice at the end together This SHOULD be able to select
by user.
In the 1st method, Sender can take in the timely Delivery reports in each
1 address from Offramp gateway. But the burst traffic is occurred when
it has a lot of Errors. So, source user receives return notice of the number
witch is equal to the number of the error. In the worst case, source user
receives return notice of the number witch is the same as the number of
the addresses.
Mimura, Expires July 2000 [Page4]
Internet Draft Internet FAX Gateway Protocol July 2000
In the 2nd method, the little traffic is occurred to be able to describe
a lot of error in the one delivery report. But, Sender has to wait for
take in the delivery report until a set of delivery is finished.
This SHOULD be realized by using of
draft-ietf-fax-content-negotiation-01.txt which specify ability
exchange .
3.3.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 .
3.3.3 Information of return notice
The following information must be contained at least in return notice.
- Transmission start time
- Destination dial
- Number of total pages
- Number of real transmitted page
- Cause of error
An offramp gateway adds the following information, when it have the
function of automatically transmission retry.
- number of retry times
- Transmission retry start time
3.4 Authentication
An offramp gateway SHOULD provide the authentication function to judge
whether the received E-mail is sent by appropriate source IFAX device.
How to certify is optional to use E-mail authentication system
(S/MIME, Signature by PGP ,others)
Mimura, Expires July 2000 [Page5]
Internet Draft Internet FAX Gateway Protocol July 2000
3.5 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
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.
Sending to the device on Internet for E-mail data , the onramp gateway
should set From field or Replay-To field for the following sentences.
< the numbers of sender > @ < Domain name of onramp gateway >
We can use for the Return notice from destination function by this setting.
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) Direct address designation
Address data from facsimile device over GSTN specify destination
telephone number directly.
It is used when destination is specified every time.
Mimura, Expires July 2000 [Page6]
Internet Draft Internet FAX Gateway Protocol July 2000
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 5.3 choice of offramp gateway.
(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 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.
Indirect address information contains information on lowest and
under.
- Indirect address number
- The list of the destination facsimile number and the E-mail
address looked up from the indirect address number
When user authentication is necessary, the next information is
included, regardless of the direct address designation or the indirect
address designation.
- User ID
- Password
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 for separator.
* is used at the head in the case of the indirect address designation.
Direct address designation: <destination number>#
It is specified as follows when user authentication is necessary.
<destination number> * <User ID>* <password>#
Indirect address designation: * < indirect address number >#
* < indirect address number > * <User ID> * <Password>#
Source facsimile number can be used for the user ID number
A password number is at least four-digit progression, and must not
contain #, *.
Mimura, Expires July 2000 [Page7]
Internet Draft Internet FAX Gateway Protocol July 2000
example
81355551234üö üF destination facsimile number 81355551234
*1234# : indirect address number 1234
*36*817476554*12345# : indirect address number 36,
User ID 817476554,
Password 12345
4.2.1 Support subaddress
An onramp gateway SHOULD supports subaddress.
In the case of direct 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 Choice of Offramp gateway
Onramp gateway SHOULD have the function which chooses destination offramp
gateway by analyzing a specified destination facsimile number.
Onramp gateway SHOULD hold course information of offramp gateway to
realize this function.
Onramp gateway holds the following Offramp gateway course 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 course 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
(* of this case shows a progression of the option size.)
(ex 81* : 81355551234, 81441117890, etc)
4.4 User authentication
Onramp gateway should have a user authentication function to confirm that
they are the data that suitable user transmitted.
User authentication 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)
Mimura, Expires July 2000 [Page8]
Internet Draft Internet FAX Gateway Protocol July 2000
* < 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 authentication is done.
Destination facsimile number : 8155551234
User ID : 81467745523
Password : 98765
4.5 Authentication toward Offramp gateway
Onramp gateway should provide the function, which transmits necessary
information to do authentication toward offramp gateway, when offramp
request send.
As for the authentication data of this case, the exchange ability method
specified with draft-ietf-fax-content-negotiation-01.txt is delivered
to Offramp gateway.
But, it is not it until this limit when Onramp gateway and Offramp gateway
are on the same machine.
Necessary information is the following so that Offramp gateway may do
authentication.
- User ID
- Password
When a password is enciphered, the above two data are enciphered with a
form to show in the following for security.
At this time, the following information is given, too.
- Encipherment form
- public key
4.6 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
Mimura, Expires July 2000 [Page9]
Internet Draft Internet FAX Gateway Protocol July 2000
- kind of the data (resolution)
- existence of error occurrence
- number of automatically retry sending
- date and time of transmitting delivery notice
4.7 Option function
Onramp gateway can provide various option functions for facsimile device
user on GSTN by adding an option number at the end of the DTMF data.
A data format at this time is following either.
<desitination number> * < user ID> * <password> * <option number> #
* < indirect address number > * < user ID> * <password> * <option number>#
<desitination number> * <option number> #
* < indirect address number > * <option number> #
example
8155551234*23456*876*015# is detected by DTMF
Destination facsimile number : 8155551234
user ID : 23456
password : 9876
Option number : 015
(for example , It is interpreted with the requirement
of transmitting after five hours.)
4.8 return notice
When it has a function that receives and analyzes return notice from
destination,
Onramp gateway MAY send delivery status to suitable facsimile device user
on GSTN.
This function is used in accordance with the 5.4 user authentication.
In order to put into practice this function, it is necessary to SMTP
receiver MTA on onramp gateway.
4.9 Multicasts transmit request
Onramp gateway can specify destination of maximum 99 by specifying it in
To: or c: field by 1 mail.
But, destination beyond 100 SHULD NOT be specified in 1 mail.
And, address SHOULD NOT be specified whit BCC:.
How to specify address in this case it SHOULD be indirect address
designation (5.2 2).
An onramp gateway that has the function which takes out a transmitting
request beyond 100 address at the same time by 5.2(2) indirect address
designation, SHOULD have the function which transmits the mail of the
Mimura, Expires July 2000 [Page10]
Internet Draft Internet FAX Gateway Protocol July 2000
necessary number by dividing the number of the addresses of 1 mail by the
maximum 99 address, when a transmitting request beyond 100 address is
taken.
example
When the transmitting requirement of 1000 address is taken out by the
indirect address designation.
The 10 mail of 99 address and 1 mail of 10 addresses is transmitted.
(99*10 + 10*1=1000)
Because the problem of traffic occurs, 1000 mail of 1 address isn't
encouraged to transmit in this paper.
(For example, the thing when it has 1000 huge Tiff files transmitted is
presumed.)
5. Security Considerations
The Security Considerations sections of [RFC2305] applies to this
document.
6. Acknowledgments
[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.
Mimura, Expires July 2000 [Page11]
Internet Draft Internet FAX Gateway Protocol July 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 July 2000 [Page12]
Internet Draft Internet FAX Gateway Protocol July 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 July 2000 [Page13]
| PAFTECH AB 2003-2026 | 2026-04-23 10:30:52 |