[要約] 要約：RFC 4160は、インターネットファックスゲートウェイの要件に関する規格です。 目的：インターネットファックスゲートウェイの機能と要件を定義し、効果的なファックス通信を実現するためのガイドラインを提供することを目的としています。
Network Working Group K. Mimura
Request for Comments: 4160 K. Yokoyama
Category: Informational T. Satoh
C. Kanaide
TOYO Communication Equipment
C. Allocchio
Consortium GARR
August 2005
Internet Fax Gateway Requirements
インターネットファックスゲートウェイの要件
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).
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 recommendations for the 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 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.
一般的な切り替えの電話ネットワークファクシミリサービス（GSTN FAX）と電子メールベースのインターネットファックスサービス（Iファックス）間の接続を可能にするには、「インターネットファックスゲートウェイ」が必要です。このドキュメントは、インターネットファックスゲートウェイの機能に関する推奨事項を提供します。これに関連して、「Offramp Gateway」は、I-FaxからGSTN Faxへのファクシミリデータ送信を提供します。その逆の場合、「Onramp Gateway」は、I-FaxにGSTN FAXのデータ送信フォームを提供します。このドキュメントの推奨事項は、インターネットFAX端子、インターネット上のIファックスソフトウェアを備えたコンピューター、GSTN上のGSTN FAX端子を含む統合サービスに適用されます。
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].
インターネットFAXゲートウェイは、一般的なスイッチの電話ネットワークファクシミリサービス（GSTN FAX）と電子メールベースのインターネットFAXサービス（I-Fax）の間の接続と翻訳を提供します。このドキュメントは、インターネットFAXゲートウェイの推奨動作を定義します。インターネットファックスゲートウェイは、「Onramp」、ファクシミリがGSTNファックスからインターネットファックスに転送される場合、およびファクシミリがインターネットファックスからGSTNファックスに転送される場合、「オフランプ」として分類できます。Iファックスサービス内の「Onramp」と「Offramp」のより詳細な定義については、[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].
1) インターネットファックスの運用モードは、[1]のセクション2.5で定義されているように、「ストアアンドフォワード」です。
2) The format of image data is the data format defined by "simple mode" in [4].
2) 画像データの形式は、[4]の「シンプルモード」で定義されるデータ形式です。
This document does not apply to the gateway functions for "real-time Internet Fax", as described and defined in [3]. Additional recommendations for optional functionality are described in [24].
このドキュメントは、[3]で説明および定義されているように、「リアルタイムインターネットファックス」のゲートウェイ関数には適用されません。オプションの機能に関する追加の推奨事項は、[24]で説明されています。
The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [5].
このドキュメントの「必須」、「すべき」、「すべきではない」、「すべきでない」、「可能性」は、[5]で説明されているように解釈されるべきです。
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.
Onramp Gatewayは、GSTNファックスデバイス（オフランプゲートウェイ自体を含む場合がある）からファクシミリを受け取り、インターネット上にインターネットファックスを生成し、インターネットファックスデバイスに送信されます。
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.
Offramp Gatewayは、インターネットファックス対応デバイス（Onramp GatewayまたはPCを含む場合がある）からインターネット上のインターネットファックスを受け取り、GSTN Faxデバイスに送信されるGSTN FAXを生成します。
In both of these cases, the Internet side of the gateway acts as an Internet Fax device, as described in [4], while the GSTN side of the gateway acts as a GSTN fax device, as described in [6].
これらの両方のケースでは、[4]で説明されているように、ゲートウェイのインターネット側はインターネットファックスデバイスとして機能しますが、ゲートウェイのGSTN側は[6]で説明されているようにGSTNファックスデバイスとして機能します。
In this document we will only thus recommend the actions that occur while
このドキュメントでは、したがって、発生するアクションをお勧めします
1) the onramp gateway converts a fax received from GSTN and forwards it to the Internet Fax service;
1) Onramp Gatewayは、GSTNから受信したFAXを変換し、インターネットFAXサービスに転送します。
2) the offramp gateway converts a fax received from the Internet and forwards it to the GSTN fax service.
2) Offramp Gatewayは、インターネットから受信したFAXを変換し、GSTNファックスサービスに転送します。
An offramp gateway MUST, as a minimal requirement, perform the following functions:
オフランプゲートウェイは、最小限の要件として、次の機能を実行する必要があります。
- address translation/mapping, - image format conversion, and - error/return notification handling
- アドレス変換/マッピング、 - 画像形式変換、およびエラー/返信通知処理
and MAY also perform
また、実行することもできます
- user authorization.
- ユーザー承認。
An offramp gateway MAY have a user authorization function to confirm that a user is allowed to transmit its Internet Fax to the GSTN fax service.
Offramp Gatewayには、ユーザーがインターネットファックスをGSTN FAXサービスに送信できることを確認するユーザー認証機能を持つ場合があります。
Because an Internet Fax is sent as a MIME e-mail message to 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 [9][10][11][12][13]. Other methods of adding a digital signature to a mail message (such as OpenPGP [17] [25]) MAY also be used to authenticate and authorize the user.
インターネットファックスはMIME電子メールメッセージとしてOfframp Gatewayに送信されるため、デジタル署名を使用してユーザーを認証および承認することができます。S/MIMEは、デジタル署名サービスを含むプロトコルの一例です。S/MIMEは[9] [10] [11] [12] [13]で説明されています。メールメッセージ（OpenPGP [17] [25]など）にデジタル署名を追加する他の方法は、ユーザーを認証および承認するためにも使用できます。
The agent sending the Internet Fax (which may include 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. If the authorization process fails, then the offramp gateway MUST generate an error delivery notification for the sender of the Internet Fax.
インターネットファックスを送信するエージェント（Onramp Gatewayを含む場合があります）は、デジタル署名S/MIMEまたはOpenPGP FaxメッセージをOfframp Gatewayに送信します。Offramp Gatewayは、ユーザーの資格情報を比較して、GSTN FaxサービスにFAXを送信する権限があるかどうかを判断します。承認プロセスが失敗した場合、Offramp Gatewayは、インターネットFAXの送信者のエラー配信通知を生成する必要があります。
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 addresses which are explicitly itself, i.e., those where the right-hand side of the e-mail address corresponds to the offramp gateway.
インターネットファックスには、創始者として、および受信者としての複数の電子メールアドレスが含まれる場合があります。GSTN Faxサービスへの転送機能の場合、Offramp Gatewayは、明示的にそれ自体であるアドレス、つまり電子メールアドレスの右側がOfframp Gatewayに対応するアドレスのみを考慮する必要があります。
Because addresses on the Internet Fax service are e-mail addresses, in order to reach a destination in the GSTN fax service, the offramp gateway MUST convert e-mail addresses into GSTN addresses.
インターネットFAXサービスのアドレスは電子メールアドレスであるため、GSTN FAXサービスの目的地に到達するために、Offramp Gatewayは電子メールアドレスをGSTNアドレスに変換する必要があります。
The GSTN destination address SHOULD normally be encoded inside the left-hand side of the e-mail address, according to [7]. However, an offramp gateway MAY use locally implemented translation rules to map left-hand side strings into GSTN addresses.
[7]によると、GSTN宛先アドレスは通常、電子メールアドレスの左側の内側にエンコードする必要があります。ただし、Offramp Gatewayは、ローカルに実装された翻訳ルールを使用して、左側の文字列をGSTNアドレスにマッピングする場合があります。
In any case, the offramp gateway MUST process the resultant GSTN address and convert it to a "local-phone", in accordance with local dialing rules.
いずれにせよ、Offramp Gatewayは、結果のGSTNアドレスを処理し、ローカルダイヤルルールに従って「ローカルフォン」に変換する必要があります。
"Global-phone" is defined in Section 2 of [7]. "Local-phone" is defined in Section 2 of [8]. "Exit-code" is defined in Section 2.1 of [8].
「グローバルフォン」は[7]のセクション2で定義されています。「ローカル」は[8]のセクション2で定義されています。「出口コード」は、[8]のセクション2.1で定義されています。
The offramp gateway SHOULD also have a function to apply translation to originator addresses and other addresses referred to into the Internet Fax, in order to ensure a possible return path from GSTN fax service to Internet Fax destinations, including other offramp gateways. These functions MUST be compliant with the address handling of onramp gateways that is described in Section 4.2 of this document.
Offramp Gatewayには、GSTN Faxサービスから他のOfframpゲートウェイを含むインターネットファックスの目的地への可能なリターンパスを確保するために、インターネットFAXに参照される他のアドレスアドレスへの翻訳を適用する機能も必要です。これらの機能は、このドキュメントのセクション4.2で説明されているOnrampゲートウェイのアドレス処理に準拠する必要があります。
The first example shows how an offramp gateway converts a "global-phone" to a "local-phone" by removing the "+" and "44" (recognizing the international country code is local), and then knowing it can dial directly without an exit-code:
最初の例は、「グローバルフォン」を「グローバルフォン」を「ローカルフォン」に変換する方法を「」と「44」（国際国のコードを認識すること）を削除し、それからそれがなくても直接ダイヤルできることを知る方法を示しています。exit-code：
global-phone: +441164960348
グローバルフォン：441164960348
resulting in:
その結果：
local-phone: 1164960348
ローカル：1164960348
The next example shows how an offramp gateway converts a "global-phone" to a "local-phone" by removing the "+" and "44" (recognizing the international country code is local), and then adding the exit-code "0" in front of the string:
次の例は、「グローバルフォン」を「グローバルフォン」を「ローカルフォン」に変換する方法を「」と「44」（国際国のコードを認識する）を削除し、exit-code "を追加する方法0を示しています。「文字列の前：
global-phone: +441164960348
グローバルフォン：441164960348
resulting in:
その結果：
local-phone: 01164960348
ローカルフォン：01164960348
The next example shows how an offramp gateway converts a "global-phone" to "local-phone" by removing the "+" and "44" (recognizing the international country code is local), and then adding the long distance "0" in front of the string:
次の例は、「グローバルフォン」を「グローバルフォン」を「ローカルフォン」に変換する方法を「」と「44」（国際国コードを認識する）を削除し、次に長距離「0」を追加する方法を示しています。文字列の前：
global-phone: +441164960348
グローバルフォン：441164960348
resulting in:
その結果：
local-phone: 01164960348
ローカルフォン：01164960348
The last example shows how an offramp gateway converts a "global-phone" to a "local-phone" by removing the "+", recognizing the international country code is non-local, and adding the local international dialing prefix "00" in front of the string:
最後の例は、オフランプゲートウェイが「グローバルフォン」を「ローカルフォン」に削除して「ローカルフォン」に変換する方法を示しています。文字列の：
global-phone: +441164960348
グローバルフォン：441164960348
resulting in:
その結果：
local-phone: 00441164960348
地元の電話：00441164960348
An offramp gateway SHOULD support the subaddress. If a subaddress is encoded into the left-hand side of the e-mail address [7], then it MUST be used by the offramp gateway, as specified in T.33 [15], to reach the final GSTN fax recipient.
オフランプゲートウェイは、サブアドレスをサポートする必要があります。サブアドレスが電子メールアドレス[7]の左側にエンコードされている場合、T.33 [15]で指定されているように、最終的なGSTN FAXレシピエントに到達するために、Offramp Gatewayで使用する必要があります。
An offramp gateway MUST convert the file format from TIFF Profile-S for Internet Fax (defined in [16]) into the GSTN fax image format. Other Internet Fax file formats are not considered in this document.
Offramp Gatewayは、インターネットFAX（[16]で定義）のTIFFプロファイルSからファイル形式をGSTN Faxイメージ形式に変換する必要があります。このドキュメントでは、他のインターネットファックスファイル形式は考慮されていません。
An offramp gateway SHOULD have a function that allows it to send a return notice to the originator Internet Fax device (defined in [4]) when a transmission error occurs over the GSTN fax service and the facsimile is not delivered to the destination. The return notice MUST be in Message Delivery Notification (MDN) format and 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 disposition-modifier MUST be set as an "error".
Offramp Gatewayには、GSTN Faxサービスで送信エラーが発生し、FACSIMILEが宛先に配信されない場合に、Originator Internet Faxデバイス（[4]で定義）に返信通知を送信できる関数が必要です。返品通知は、メッセージ配信通知（MDN）形式であり、インターネットFAXが使用するインターネット電子メールトランスポートサービスを介してOfframp Gatewayによって配信されなければなりません。MDNの処分型を「処理」として設定する必要があり、処分モジー剤は「エラー」として設定する必要があります。
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 an e-mail message).
Offramp GatewayがMDNの送信に失敗した場合、エラー情報がログに記録され、処理が終了する場合があります。または、ゲートウェイシステムの管理者に特定のメソッドを介してこれらのエラーを通知される場合があります（たとえば、Eメールメッセージ）。
The more complex case of Delivery Status Notification (DSN) requests handling is not considered in this document.
このドキュメントでは、より複雑な配信ステータス通知（DSN）要求の処理は考慮されていません。
An onramp gateway MUST, as minimal requirement, perform the following functions:
Onrampゲートウェイは、最小限の要件として、次の機能を実行する必要があります。
- address translation/mapping, - image format conversion, and - error/return notification handling,
- アドレス変換/マッピング、 - 画像形式変換、および - エラー/返信通知処理、
and MAY also perform
また、実行することもできます
- user authorization.
- ユーザー承認。
An onramp gateway MAY have a user authorization function to confirm that the user is authorized to transmit a facsimile to the Internet fax service. For example, user authorization may be accomplished by getting a user-ID and password received by Dual Tone Multi-Frequency (DTMF), or via a local authorization table based on the GSTN caller-ID.
Onramp Gatewayには、ユーザーがファクシミリをインターネットFAXサービスに送信することを許可されていることを確認するユーザー認証機能を持つ場合があります。たとえば、ユーザーの承認は、デュアルトーンマルチ周波数（DTMF）で受信したユーザーIDとパスワードを取得するか、GSTN Caller-IDに基づくローカル認証テーブルを介して実行される場合があります。
If the authorization process fails, then the onramp gateway MUST generate an error message/code for the sender of the GSTN Fax.
承認プロセスが失敗した場合、OnrampゲートウェイはGSTNファックスの送信者のエラーメッセージ/コードを生成する必要があります。
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:
インターネットファックスサービスのアドレスは電子メールアドレスです。したがって、インターネットファックスの受信者は、電子メールユーザー、独自の受信者/ユーザーを備えたインターネットファックスデバイス、またはオフランプゲートウェイのいずれかです。Onramp Gatewayには、GSTN（DTMF経由）の宛先アドレスから受信するために機能を備えている必要があります。ただし、宛先アドレスには2つのカテゴリがあります。
- e-mail users and Internet Fax recipient/users - real GSTN addresses reached via an offramp gateway
- 電子メールユーザーとインターネットファックス受信者/ユーザー - オフランプゲートウェイを介して到達した実際のGSTNアドレス
We define "indirect address mapping" as the functionality for the first category, and "direct address mapping" as the functionality for the second category.
「間接的なアドレスマッピング」を最初のカテゴリの機能として定義し、2番目のカテゴリの機能として「直接アドレスマッピング」を定義します。
The onramp gateway MAY implement local address mapping mechanisms (via a table, directory lookup, or something similar) that permit translation from addresses (called "indirect address numbers") received from the GSTN fax sending device into e-mail addresses. A single e-mail address or a list of e-mail addresses MAY correspond to a single indirect address number.
Onramp Gatewayは、GSTN Fax送信デバイスから受信したアドレスからの翻訳を電子メールアドレスに送信するアドレスからの翻訳を可能にするローカルアドレスマッピングメカニズム（テーブル、ディレクトリルックアップ、または同様のものを介して）を実装する場合があります。単一の電子メールアドレスまたは電子メールアドレスのリストは、単一の間接アドレス番号に対応できます。
Here is one mapping example:
これが1つのマッピング例です。
(1) An onramp gateway receives the indirect address number "1234" from the source GSTN facsimile by DTMF.
(1) Onramp Gatewayは、DTMFによるソースGSTNファクシミリから間接的なアドレス番号「1234」を受け取ります。
1234
1234
(2) The destination address is looked up in the address mapping table.
(2) 宛先アドレスは、アドレスマッピングテーブルで検索されます。
address mapping table 1234 : ifax@example.com
アドレスマッピング表1234：ifax@example.com
(3) An Internet Fax is sent to the address ("addr-spec")
(3) インターネットファックスがアドレスに送信されます（ "addr-spec"）
ifax@example.com
ifax@example.com
"Addr-spec" is defined in Section 3.4.1 of [14].
「ADDR-SPEC」は[14]のセクション3.4.1で定義されています。
If the address mapping lookup fails, an error MUST be reported to the originating GSTN fax device.
アドレスマッピングルックアップが失敗した場合、発信するGSTN FAXデバイスにエラーを報告する必要があります。
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 to the onramp gateway via DTMF. Direct address mapping can also be used if indirect address mapping is implemented.
4.2.1で指定された間接アドレスマッピングが実装されていない場合、「直接アドレスマッピング」のみを使用できます。GSTN送信デバイスは、DTMFを介して完全な数値宛先アドレスをOnrampゲートウェイに送信する必要があります。間接的なアドレスマッピングが実装されている場合、直接アドレスマッピングも使用できます。
An example:
例：
(1) An onramp gateway receives the destination telephone number "441164960348" from the source facsimile by DTMF.
(1) Onramp Gatewayは、DTMFによるソースファクシミリから目的地の電話番号「441164960348」を受け取ります。
441164960348
441164960348
(2) The destination number is encoded as a "global-phone", so "+" is added to the head of the string.
(2) 宛先番号は「グローバルフォン」としてエンコードされるため、「弦のヘッドに「」が追加されます。
+441164960348
441164960348
(3) "FAX=" is added in order to build the "fax-mbox" address item
(3) 「Fax =」は、「Fax-Mbox」アドレス項目を構築するために追加されます
FAX=+441164960348
FAX = 441164960348
(4) The destination address is completed, adding the specification of the appropriate offramp gateway, which is supposed to handle the delivery of the fax message to a global-phone address.
(4) 宛先アドレスが完了し、適切なオフランプゲートウェイの仕様が追加されます。これは、グローバルフォンアドレスへのFAXメッセージの配信を処理することになっています。
FAX=+441164960348@example.com
The procedure for choosing the domain name of an offramp gateway is defined in Section 4.3 ("Relay Function").
オフランプゲートウェイのドメイン名を選択する手順は、セクション4.3（「リレー関数」）で定義されています。
"Global-phone", "fax-mbox", and "fax-address" are defined in Section 2 of [7]. "Mta-I-fax" is defined in Section 3 of [7]. "Fax-email" is defined in Section 4 of [7].
「グローバルフォン」、「Fax-Mbox」、および「Fax-Address」は[7]のセクション2で定義されています。「MTA-Iファックス」は[7]のセクション3で定義されています。「Fax-Email」は[7]のセクション4で定義されています。
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 (see Section 4.2.2 of this document). The sender address SHOULD be completed using the onramp gateway address, unless the onramp gateway has additional information with which to specify a different return path.
Onramp Gatewayは、GSTN Fax Senderアドレスに関する情報（たとえば、Caller-ID、利用可能な場合は介して）を収集し、直接アドレスマッピングを使用して、インターネットFAXの送信者としてエンコードする必要があります（このドキュメントのセクション4.2.2を参照）。Onramp Gatewayに異なるリターンパスを指定する追加情報がない限り、Onramp Gatewayアドレスを使用して送信者アドレスを完了する必要があります。
If the onramp gateway does not have any sender address information, the Internet Fax sender address SHOULD be set to either a "no-reply" address or an appropriate default mailbox.
Onramp Gatewayに送信者アドレス情報がない場合、インターネットFAX Senderアドレスを「修正なし」アドレスまたは適切なデフォルトのメールボックスのいずれかに設定する必要があります。
An onramp gateway SHOULD support the subaddress. In the case of direct address mapping, the subaddress is specified using the T.33 [15] specification, and encoded as given in [7]. In the case of indirect address mapping, the subaddress MAY be contained inside the address mapping table.
Onrampゲートウェイは、サブアドレスをサポートする必要があります。直接アドレスマッピングの場合、サブアドレスはt.33 [15]仕様を使用して指定され、[7]で示されているようにエンコードされます。間接的なアドレスマッピングの場合、サブアドレスはアドレスマッピングテーブル内に含まれる場合があります。
The onramp gateway SHOULD provide functionality for choosing the destination offramp gateway by analyzing a destination fax number. A possible method to expand or acquire information from the onramp gateway about offramp gateways MAY include keeping cached information about sender addresses that was sent by other onramp gateways.
Onramp Gatewayは、宛先ファックス番号を分析して、宛先オフランプゲートウェイを選択する機能を提供する必要があります。Offramp Gatewaysに関するOnramp Gatewayから情報を拡張または取得する可能性のある方法には、他のOnrampゲートウェイによって送信された送信者アドレスに関するキャッシュされた情報を保持することが含まれます。
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 [16].
Onrampゲートウェイは、[16]で定義されているように、GSTN上のファクシミリからファイル形式のTIFFプロファイルSにインターネットファックスのファイル形式に変換する必要があります。
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.
Onramp GatewayがインターネットFAXの宛先から返品通知を受信して分析すると、適切なOfframpゲートウェイを介して配信ステータスをGSTN上の適切なファクシミリデバイスに送信する機能がある場合があります。GSTN Faxを介して送信された生成された通知には、人間が読める通知情報と元の配信コードの両方を含める必要があります。
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 this notice with a specific method (for example, by sending an e-mail message to a mailbox).
Onramp GatewayがGSTN FAXサービスに戻る返信通知の送信に失敗した場合、情報はログに記録され、処理が終了する場合があります。代替として、ゲートウェイシステムの管理者は、特定の方法でこの通知を通知することができます（たとえば、メールボックスに電子メールメッセージを送信することにより）。
Refer to Section 3.1 ("User Authorization") for authentication for an offramp gateway. OpenPGP [17] [25] can be used to provide authorization services instead of S/MIME. Refer to Section 4.1 ("User Authorization") for authentication for an onramp gateway.
オフランプゲートウェイの認証については、セクション3.1（「ユーザー認証」）を参照してください。OpenPGP [17] [25]を使用して、S/MIMEの代わりに承認サービスを提供できます。Onrampゲートウェイの認証については、セクション4.1（「ユーザー認証」）を参照してください。
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 reaches an Internet Fax Gateway, either onramp or offramp, this kind of protection cannot be applied anymore. Here, security must rely 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 with any gateway, it breaks the end-to-end security pattern of both S/MIME and PGP.
S/MIMEおよびOpenPGPを使用してメッセージを暗号化することもできます。ネットワークに沿って輸送されている間、署名または暗号化されたメッセージが保護されています。ただし、メッセージがオンランプまたはオフランプのいずれかのインターネットFAXゲートウェイに到達すると、この種の保護はもはや適用できません。ここでは、セキュリティはゲートウェイ自体の信頼できる操作に依存する必要があります。ゲートウェイには、インターネットファックスを送信する際にセキュリティ操作を改善するための独自の証明書/キーがある場合がありますが、Gatewayと同様に、S/MIMEとPGPの両方のエンドツーエンドのセキュリティパターンを破ります。
Other security mechanisms, like IPsec [18][19][20][21][2] or TLS [23] also do not ensure a secure gateway operation.
IPSEC [18] [19] [20] [21] [2]またはTLS [23]のような他のセキュリティメカニズムも、安全なゲートウェイ操作を保証しません。
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.
サービス拒否攻撃は、このドキュメントの範囲を超えています。実装の欠陥によって引き起こされるホストの妥協は、このドキュメントの範囲を超えています。
[1] Masinter, L., "Terminology and Goals for Internet Fax", RFC 2542, March 1999.
[1] Masinter、L。、「インターネットファックスの用語と目標」、RFC 2542、1999年3月。
[2] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[2] Thayer、R.、Doraswamy、N。、およびR. Glenn、「IP Security Document Roadmap」、RFC 2411、1998年11月。
[3] "Procedures for real-time Group 3 facsimile communication over IP networks", ITU-T Recommendation T.38, June 1998.
[3] 「IPネットワークを介したリアルタイムグループ3ファクシミリ通信の手順」、ITU-T推奨T.38、1998年6月。
[4] Toyoda, K., Ohno, H., Murai, J., and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 3965, December 2004.
[4] Toyoda、K.、Ohno、H.、Murai、J。、およびD. Wing、「インターネットメールを使用したファクシミリの単純なモード」、RFC 3965、2004年12月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[6] "Procedures for document facsimile transmission in the general switched telephone network", ITU-T Recommendation T.30, April 1999.
[6] 「一般的な切り替えの電話ネットワークにおけるドキュメントファクシミリ送信の手順」、ITU-Tの推奨T.30、1999年4月。
[7] Allocchio, C., "Minimal FAX address format in Internet Mail", RFC 3192, October 2001.
[7] Allocchio、C。、「インターネットメールの最小ファックスアドレス形式」、RFC 3192、2001年10月。
[8] Allocchio, C., "GSTN Address Element Extensions in E-mail Services", RFC 2846, June 2000.
[8] Allocchio、C。、「電子メールサービスのGSTNアドレス要素拡張機能」、RFC 2846、2000年6月。
[9] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[9] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 3852、2004年7月。
[10] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[10] Rescorla、E。、「Diffie-Hellman Key Asmational Method」、RFC 2631、1999年6月。
[11] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[11] Ramsdell、B。、「セキュア/多目的インターネットメール拡張機能（S/MIME）バージョン3.1証明書処理」、RFC 3850、2004年7月。
[12] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[12] Ramsdell、B。、「Secure/Multipurpose Internet Mail拡張機能（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[13] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[13] Hoffman、P。、「S/MIMEの強化されたセキュリティサービス」、RFC 2634、1999年6月。
[14] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[14] Resnick、P。、「インターネットメッセージフォーマット」、RFC 2822、2001年4月。
[15] "Facsimile routing utilizing the subaddress", ITU recommendation T.33, July 1996.
[15] 「サブアドレスを利用したファクシミリルーティング」、ITU勧告T.33、1996年7月。
[16] Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J. Rafferty, "File Format for Internet Fax", RFC 3949, February 2005.
[16] Buckley、R.、Venable、D.、McIntyre、L.、Parsons、G。、およびJ. Rafferty、「Internet Faxのファイル形式」、RFC 3949、2005年2月。
[17] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[17] Callas、J.、Donnerhacke、L.、Finney、H。、およびR. Thayer、「OpenPGPメッセージ形式」、RFC 2440、1998年11月。
[18] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[18] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[19] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[19] Kent、S。およびR. Atkinson、「IP Authentication Header」、RFC 2402、1998年11月。
[20] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[20] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[21] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[21] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[23] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003.
[23] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J。、およびT. Wright、「Transport Layer Security（TLS）Extensions」、RFC 3546、2003年6月。
[24] Mimura, K., Yokoyama, K., Satoh, T., Watanabe, K., and C. Kanaide, "Guidelines for Optional Services for Internet Fax Gateways", RFC 4161, August 2005.
[24] Mimura、K.、横山、K。、Satoh、T.、Watanabe、K。、およびC. Kanaide、「インターネットファックスゲートウェイのオプションサービスのガイドライン」、RFC 4161、2005年8月。
[25] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[25] Elkins、M.、Del Torto、D.、Levien、R。、およびT. Roessler、「OpenPGPのMIMEセキュリティ」、RFC 3156、2001年8月。
Authors' Addresses
著者のアドレス
Katsuhiko Mimura TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa, Japan
魚島mimura toyo通信機器Co。、Ltd。2-1-1 Koyato、Samukawa-Machi、Koza-Gun Kanagawa、日本
Fax: +81 467 74 5743
EMail: mimu@miyabi-labo.net
Keiichi Yokoyama TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa, Japan
横林ya馬toyo通信機器Co。、Ltd。2-1-1 Koyato、Samukawa-Machi、Koza-Gun Kanagawa、日本
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
Takahisa Satoh Toyo Communication Equipment Co。、Ltd。2-1-1 Koyato、Samukawa-Machi、Koza-Gun Kanagawa、日本
Fax: +81 467 74 5743
EMail: zsatou@t-ns.co.jp
Chie Kanaide TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa, Japan
Chie Kanaide Toyo Communication Equipment Co。、Ltd。2-1-1 Koyato、Samukawa-Machi、Koza-Gun Kanagawa、日本
Fax: +81 467 74 5743
EMail: icemilk77@yahoo.co.jp
Claudio Allocchio Consortium GARR Viale Palmiro Togliatti 1625 00155 Roma, Italy
Claudio Allocchio Consortium Garr Viale Palmiro Togliatti 1625 00155ローマ、イタリア
Fax: +39 040 3758565
EMail: Claudio.Allocchio@garr.it
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。