Guidelines for Optional Services for Internet Fax Gateways
RFC 4161
|
| Document |
Type |
|
RFC - Informational
(September 2005; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4161 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Scott Hollenbeck
|
|
Send notices to |
|
(None)
|
Network Working Group K. Mimura
Request for Comments: 4161 K. Yokoyama
Category: Informational T. Satoh
K. Watanabe
C. Kanaide
TOYO Communication Equipment
August 2005
Guidelines for Optional Services for Internet Fax Gateways
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
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 guidelines for the optional functionality of
Internet Fax Gateways. In this context, an "offramp gateway"
provides facsimile data transmission from i-fax to GSTN fax; vice
versa, an "onramp gateway" provides data transmission from 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.
This document supplements the recommendation for minimal features of
an Internet Fax Gateway. In particular, it covers techniques for
dropping duplicated fax messages, automatic fax re-transmission,
error, return notice, and log handling, and possible authorization
methods by DTMF (Dual Tone Multi-Frequency) for onramp gateways.
Mimura, et al. Informational [Page 1]
RFC 4161 Optional Services for Internet Fax Gateways August 2005
1. Introduction
An Internet Fax Gateway can be classified as either an offramp
gateway or an onramp gateway. This document provides guidelines for
optional services and examples of Internet Fax Gateway operations.
In particular, it covers techniques for dropping duplicated fax
messages, automatic fax re-transmission, error, return notice, and
log handling, and possible authorization methods by DTMF (Dual Tone
Multi-Frequency) for onramp gateways.
A more detailed definition of onramps and offramps is provided in
[1]. Recommended behaviors for Internet Fax Gateway functions are
defined in [15].
This document provides recommendations only for the specific cases
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 [16].
This document does not apply to the gateway functions for "real-time
Internet Fax", as described and defined in [18].
1.1. Key Words
The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this
document are to be interpreted as described in [17].
2. Optional Services for an Offramp Gateway
2.1. Drop Duplicated GSTN Fax Transmission
Electronic mail transport agents (MTA) deliver an Internet Fax
message into either the recipient's mailbox or an offramp gateway
mailbox. Hence, the message is retrieved for further action, which
in the case of the offramp gateway, will result in its delivery to
the GSTN fax service.
The offramp gateway mailbox will thus receive all messages which the
gateway will process, regardless of their final, distinct GSTN
destinations. As such, addresses like
Fax=+12224567654@example.com
Fax=+38155234578@example.com
Fax=+3904567437777@example.com
Mimura, et al. Informational [Page 2]
RFC 4161 Optional Services for Internet Fax Gateways August 2005
will all end up in the offramp gateway mailbox corresponding to the
"example.com" domain.
However, the handling of e-mail messages (including those of Internet
Faxes) that contain more than one recipient, but are directed to the
same final MTA, can be different, depending on the MTA configuration
or features. A single message with multiple recipients in the SMTP
envelope [19] is likely to be the most common case on the mail
transport system, but it may happen that multiple copies of the same
message are transmitted, one per recipient. Or it may happen that
Show full document text