One document matched: draft-ietf-fax-gateway-options-01.txt
Differences from draft-ietf-fax-gateway-options-00.txt
Network Working Group K.Mimura
Internet-Draft: draft-ietf-fax-gateway-options-01 .txt K.Yokoyama
Intended Category: Informational T.Satoh
K.Watanabe
C.Kanaide
TOYO Communicaion Equipment
Feb 21 2001
Guideline of optional services for Internet FAX Gateway
Status Of This Memo
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts. Internet-Drafts are draft
documents valid for a maximum of six months and may be
updated, replaced, or obsolete by other documents at any
time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2001). 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 guideline of optional services
and some examples for an Internet FAX Gateway classified as an onramp
gateway and an offramp gateway.
So this document does not intend to specify the actions that ifax offramp
and onramp Gateways conform to.
Mimura, Expires Aug 2001 [Page1]
Internet Draft Guideline of optional services Feb 2001
for Internet FAX Gateway
This document covers Drop Duplication, Automatic re-transmission,
Error Behavior, When send return notice, Keep log, for an offramp gateway.
Example of authorization by DTMF, Keep log, for an onramp gateway.
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. Optional services for an offramp gateway
2.1 Drop Duplications
2.2 Automatic re-transmission in the delivery error occurrence
2.3 Error Behavior
2.4 When send return notice
2.5 When a transmitting error occurred in return notice
2.6 keep log
3. Optional services for an onramp Gateway
3.1 Example of User authorization
3.2 keep log
4. Security Considerations
5. References
6. Full Copyright Statement
7. Contact
1. Introduction
An Internet FAX Gateway can be classified as an offramp gateway and an
onramp gateway.
This document provides information on guideline of optional services
and some examples for Internet FAX Gateway.
This document covers Drop Duplication, Automatic re-transmission,
Error Behavior, When send return notice, Keep log, for an offramp gateway.
Example of authorization by DTMF, Keep log, for an onramp gateway.
A more detailed definition of onramps and offramps is provided in
[RFC2542].
Information on recommended behaviors for Internet FAX Gateways Functions
defined in [draft-ietf-fax-gateway-protocol-03].
Mimura, Expires Aug 2001 [Page2]
Internet Draft Guideline of optional services Feb 2001
for Internet FAX Gateway
Scope of Internet FAX Gateway defined in this document is shown
below.
1) A format of image data is a data format defined by "Simple Mode"
in [RFC2305].
2) Operational mode is "store and forward" defined in section 2.5 of
[RFC2542]
2. Optional services for an offramp gateway
2.1 Drop Duplications
By the case an offramp gateway detects duplicate 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 duplicate mail from MTA.
As for the duplicate message detection mechanism, it is entrusted to other
documents.
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 transmission is stopped after 2 pages are sent
normally. The offramp gateway should re-transmit the facsimile data from
page 3.
Mimura, Expires Aug 2001 [Page3]
Internet Draft Guideline of optional services Feb 2001
for Internet FAX Gateway
2.3 Error Behavior
Retransmission behavior depends on the kind the Errors.
In Calling Errors, such as Busy, Line errors and so on.
An offramp gateway do Retransmission.
In Connecting Errors, such as Paper Error, Stop Event error,
not FAX error (Voice Response).
An offramp gateway send the Return notice to sender without any
retransmission.
That is why Calling Errors probably be recovered, but Connecting
errors can hardly be recoverd.
2.4 When send return notice
When an 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.
EXAMPLE
The source user requested to send to 20000 address, and had a lot of
errors over 1000 address.
If an offramp gateway send return notice as soon as an error occurs,
the source user receive over 1000 return notice from an offramp
gateway. but, the source user can receive return notice as soon as
error occurrence.
If an offramp gateway send return notice every time transmission is
finished 10 times, the source user received return notice of 1/10
of the number.
Mimura, Expires Aug 2001 [Page4]
Internet Draft Guideline of optional services Feb 2001
for Internet FAX Gateway
2.5 When a transmitting error occurred in return notice
When an offramp gateway fails in transmission of return notice,
The Internet Fax Gateway SHOULD process either of the following.
When a log information preservation function is in a gateway,
An error information SHOULD be recorded to a log and processing SHOULD
be ended. At this time, the administrator of a gateway system SHOULD
be notified of these errors information with a certain means
(for example, SMTP).
The case where there is no log information preservation function
in a gateway ,
An administrator SHOULD be told about failure and processing SHOULD
be ended.
If the capability which the hardware of a gateway has is high and
there is a time margin, it is good service to perform the following
processing.
When it fails in transmission of the notice of a result,
A fixed time interval is vacated.
And notice output operation is repeated as a result of the number of
times of specification.
The number time of specification times -- even if it repeats, when failing,
An error information is recorded to a log and processing is finished.
Also at this time, as for these errors information, the administrator of
the gateway system SHOULD be notified with a certain means
(for example, SMTP).
Mimura, Expires Aug 2001 [Page5]
Internet Draft Guideline of optional services Feb 2001
for Internet FAX Gateway
2.6 keep log
An offramp gateway MAY have the function which 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
- 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
The log information preservation function aims at mainly becoming
a help of security or Charge calculation processing.
When the hardware system equipped with some recording media
(HDD, FDD, etc.)is used, the log information SHOULD be saved as
a log file.
The opportunity which saves log information can consider three of
the following.
1) When an offramp gateway receives a distribution demand.
2) When an offramp gateway starts distribution.
3) When an offramp gateway ends distribution.
When the hardware system without a certain recording medium is used,
log information cannot be saved locally. In this case, it is desirable
to hold the function saved at other PCs using the existing network
communication means, such as a function to save log information as
a file using a Network File System, and SMTP, SNMP, or the function
printed out periodically.
In order to strengthen security, it is desirable to save log information
in the Internet Fax Gateway using a database system.
Mimura, Expires Aug 2001 [Page6]
Internet Draft Guideline of optional services Feb 2001
for Internet FAX Gateway
3. Optional services for an onramp Gateway
3.1 Example of User authorization
Onramp gateway MAY have a user authorization function to confirm that
they are the data that suitable user transmitted.
Example of user "authorization" by "DTMF", GSTN user might send "user-ID",
"password" data after destination "gstn-phone"
(Dual Tone Multi Frequency).
DTMF Data format is shown in the following.
"*" is separater, "#" is terminater.
gstn-phone defined in section 2 of [RFC2846].
DTMF defined in section 2.1 of [RFC2846].
authorization = 1*DTMF
authorization = gstn-phone "*" user-ID "*" password "#"
user-ID = 1*( DIGIT / "A" / "B" / "C" / "D" )
password = 1*( DIGIT / "A" / "B" / "C" / "D" )
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
3.2 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 Aug 2001 [Page7]
Internet Draft Guideline of optional services Feb 2001
for Internet FAX Gateway
The log information preservation function aims at mainly becoming
a help of security or Charge calculation processing.
When the hardware system equipped with some recording media
(HDD, FDD, etc.)is used, the log information SHOULD be saved as
a log file.
The opportunity which saves log information can consider three of
the following.
1) When an onramp gateway receives a distribution demand.
2) When an onramp gateway starts distribution.
3) When an onramp gateway ends distribution.
When the hardware system without a certain recording medium is used,
log information cannot be saved locally. In this case, it is desirable
to hold the function saved at other PCs using the existing network
communication means, such as a function to save log information as
a file using a Network File System, and SMTP, SNMP, or the function
printed out periodically.
In order to strengthen security, it is desirable to save log information
in the Internet Fax Gateway using a database system.
4. 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 publication as an RFC.
5. 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.
[RFC2846] C. Allocchio "GSTN Address Element Extensions in E-mail
Services",RFC 2846, June 2000.
[draft-ietf-fax-gateway-protocol-02] K.Mimura, K.Yokoyama, T.Satoh,
C.Kanaide "Internet FAX Gateway Functions",
Internet-Draft, Oct 30 2000
Mimura, Expires Aug 2001 [Page8]
Internet Draft Guideline of optional services Feb 2001
for Internet FAX Gateway
6. 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 Aug 2001 [Page9]
Internet Draft Guideline of optional services Feb 2001
for Internet FAX Gateway
7. 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
K.Watanabe
TOYO Communication Equipment CO., LTD.
2-1-1 Koyato, Samukawa-machi, Koza-gun
Kanagawa-pref., Japan
Fax: +81 467 74 3934
Email: knabe@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 Aug 2001 [Page10]
Internet Draft Guideline of optional services Feb 2001
for Internet FAX Gateway
Revision history
00a 31-Oct-2000 Initial draft.
01a 21-Feb-2001 Rebuild next definition
2.6 keep log
3.2 keep log
Added next definition
2.5 When a transmitting error occurred in return notice
Mimura, Expires Aug 2001 [Page11]
| PAFTECH AB 2003-2026 | 2026-04-23 11:05:32 |