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).
著作権（C）インターネット協会（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.
一般的には電話網ファクシミリサービス（GSTNファックス）と電子メールベースのインターネットFAXサービスを（I-FAX）スイッチ間の接続を許可するには、「インターネットのファックスゲートウェイ」が必要です。このドキュメントはインターネットファックスゲートウェイのオプション機能のためのガイドラインを提供します。この文脈において、「オフランプゲートウェイは」GSTNファックスにI-FAXのファクシミリデータの送信を提供します。逆に、「オンランプゲートウェイが」I-FAXにGSTNファックスからのデータ送信を提供します。このドキュメントの推奨事項は、インターネットFAX端末、インターネット上のI-FAXソフトウェアを搭載したコンピュータ、およびGSTN上の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.
このドキュメントはインターネットファックスゲートウェイの最小限の機能のための勧告を補足します。特に、重複ファックスメッセージをドロップするための技術、自動ファックス再送信、エラー、復帰通知、及び取り扱いを記録し、オンランプゲートウェイのDTMF（デュアルトーン多重周波数）によって可能な認証方式を覆います。
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.
インターネットファックスゲートウェイは、オフランプゲートウェイまたはオンランプゲートウェイのいずれかに分類することができます。この文書では、オプションサービスおよびインターネットファックスゲートウェイの操作の例のためのガイドラインを提供します。特に、重複ファックスメッセージをドロップするための技術、自動ファックス再送信、エラー、復帰通知、及び取り扱いを記録し、オンランプゲートウェイのDTMF（デュアルトーン多重周波数）によって可能な認証方式を覆います。
A more detailed definition of onramps and offramps is provided in [1]. Recommended behaviors for Internet Fax Gateway functions are defined in [15].
onrampsとオフランプのより詳細な定義は、[1]に提供されます。インターネットファックスゲートウェイ機能のための推奨動作は、[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].
[1]のセクション2.5で定義されるように1）インターネットファクスの動作モードは、「ストアアンドフォワード」です。
2) The format of image data is the data format defined by "simple mode" in [16].
2）画像データのフォーマットは、[16]の「シンプルモード」によって定義されるデータ形式です。
This document does not apply to the gateway functions for "real-time Internet Fax", as described and defined in [18].
説明及び[18]で定義されるように、この文書では、「リアルタイムインターネットファクス」のゲートウェイ機能には適用されません。
The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [17].
キーワード「MUST」、「SHOULD」、「SHOULD NOT」、および本書では[17]に記載されているように解釈されるべきである、「MAY」。
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.
電子メール転送エージェント（MTA）受信者のメールボックスまたはオフランプゲートウェイメールボックスのいずれかにインターネットファクスメッセージを配信。したがって、メッセージは、オフランプゲートウェイの場合には、GSTNファックスサービスへの送達をもたらすさらなるアクションのために検索されます。
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
オフランプゲートウェイメールボックスは、このようにかかわらず、最終的な、別個GSTN先のゲートウェイが処理するすべてのメッセージを受信します。そのため、同じように対処
Fax=+12224567654@example.com Fax=+38155234578@example.com Fax=+3904567437777@example.com
ふぁｘ＝＋１２２２４５６７６５４＠えぁｍｐぇ。こｍ ふぁｘ＝＋３８１５５２３４５７８＠えぁｍｐぇ。こｍ ふぁｘ＝＋３９０４５６７４３７７７７＠えぁｍｐぇ。こｍ
will all end up in the offramp gateway mailbox corresponding to the "example.com" domain.
すべての「example.com」ドメインに対応するオフランプゲートウェイメールボックスになってしまいます。
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 the final MTA is set to deliver a separate copy of the message per recipient into the final mailbox, supposing it is delivering messages to real mailboxes of distinct endusers.
しかし、複数の受信者が含まれている（インターネットファクスのものを含む）、電子メールメッセージの処理が、同じ最終MTAに向けられているが、MTAの構成や機能に応じて、異なる場合があります。 SMTPエンベロープ内の複数の受信者を有する単一のメッセージ[19]メール転送システムで最も一般的なケースである可能性が高いが、同じメッセージの複数のコピーが、受信者ごとに1つずつ送信されることが起こり得ます。それとも、それが明確なエンドユーザの実際のメールボックスにメッセージを配信している想定し、最終的にMTAが、最終的なメールボックスに受信者ごとにメッセージのコピーを個別に提供するために設定されていることが起こり得ます。
Thus, it may happen that the offramp gateway receives multiple copies of the same Internet Fax message that is to be delivered to different GSTN destinations, which are listed together and repeatedly in the e-mail message headers [20] of the Internet Fax. In such cases, the offramp gateway SHOULD implement techniques to avoid duplicate or multiple transmission over GSTN of the same fax message to the same recipient.
これにより、オフランプゲートウェイは、インターネットファックスの電子メールメッセージのヘッダーに一緒に繰り返し記載されている異なるGSTN先、[20]に送達される同一のインターネットファックスメッセージの複数のコピーを受信することが起こり得ます。このような場合には、オフランプゲートウェイは、同一の受信者に同じファックスメッセージのGSTN上重複または複数の伝送を回避するための技術を実装する必要があります。
Here are some possible, but non-exclusive, examples of these techniques.
ここではこれらの技術の一部、可能性が、非排他的な例です。
Using the SMTP [19] envelope destination address given in the "RCPT TO" field is usually the best technique to ensure that a received message is delivered to that address, and to avoid duplicate deliveries.
フィールド「TO RCPT」で与えられたSMTPを使用した[19]封筒の宛先アドレスは、通常、受信したメッセージがそのアドレスに配信されていることを確実にするために、重複配達を避けるために、最善の手法です。
If the offramp gateway has the "RCPT TO" information still available during processing, then it MUST use it to determine the recipients over GSTN fax service.
オフランプゲートウェイは、処理中に、まだ入手可能な情報「TO RCPT」を持っている場合、それはGSTNファックスサービス経由の受信者を決定するためにそれを使用しなければなりません。
If the SMTP "RCPT TO" information is not available (for example, in the case where the offramp gateway retrieves messages from its mailbox using either POP [21] or IMAP [22]), the message header "Message-ID" (see [20]) MAY be used to check if a message has already been processed, and hence avoid retransmission to all its GSTN recipients handled by the offramp gateway.
SMTP情報が利用できない「RCPTが」場合（例えば、オフランプゲートウェイはPOP [21]またはIMAPのいずれかを使用してメールボックスからメッセージを取得する場合には[22]）、メッセージヘッダ「メッセージID」（参照[20]）メッセージがすでに処理されたかどうかを確認し、ひいてはオフランプゲートウェイによって処理されるすべてのGSTNの受信者に再送信を回避するために使用されるかもしれません。
Recoverable errors that happen during GSTN transmission are those where there is good chance that the error may not occur at the next attempt. This category includes "busy signal", "no line/carrier signal", etc.
GSTNの送信中に起こる回復可能エラーは、エラーは次の試行で発生していないことを良いチャンスがあるものです。このカテゴリには、「ビジー信号」、「ノーライン/キャリア信号」などが含まれます
For all these errors, the offramp gateway SHOULD re-queue the message and perform a retransmission attempt later on, as specified in Section 2.3.
すべてのこれらのエラーの場合は、オフランプゲートウェイは、セクション2.3で指定されるように、メッセージを再キューイングし、後で再試行を実行する必要があります。
If the error that occurs during GSTN transmission is likely non-recoverable, the offramp gateway SHOULD NOT attempt retransmission, and an error Message Delivery Notification (MDN) with appropriate error codes MUST be generated for the Internet Fax message sender. Examples of non-recoverable errors include paper-related errors (such as a jam, an empty tray, etc.) at a remote device, no response from a remote destination, voice response errors, data modem response errors, and stop event errors.
GSTN伝送中に発生するエラーは、おそらく回復不能である場合は、オフランプゲートウェイは、再送信を試みてはならず、適切なエラー・コードとエラーメッセージ配信通知（MDN）は、インターネットファックスメッセージの送信者に対して生成されなければなりません。回復不能なエラーの例は、リモートデバイス、リモート宛先からの応答なし、音声応答エラー、データモデム応答エラーで（などジャム、空トレイ、など）紙関連のエラーを含む、イベントのエラーを停止します。
An offramp gateway SHOULD implement a function that automatically tries to send facsimile data again if recoverable delivery failure occurs. If this function is implemented, then:
オフランプゲートウェイは自動的に回復可能な配信障害が発生した場合、再度ファクシミリデータを送信しようとする機能を実装する必要があります。この機能が実装されている場合は、次のようになります。
- the retry times and retry interval MAY be specified as options by the administrator of the offramp gateway;
- リトライ回数およびオフランプゲートウェイの管理者がオプションとして指定することができる間隔を再試行します。
- any error return notice SHOULD be sent only when the maximum number of retries has been completed without success;
- 再試行の最大数は成功せずに完了した場合にのみ、任意のエラーリターン通知を送ってください。
- if transmission is suspended due to an error, then the subsequent transmission attempt SHOULD avoid retransmitting the pages already delivered successfully, if any.
- 送信がエラーにより中断された場合、その後の送信の試行があれば、すでに正常に配信ページを再送信することは避けてください。
An offramp gateway can receive an Internet Fax for delivery to multiple GSTN recipients. If errors occur, which require the Internet Fax sender to be informed about them, or if the Internet Fax sender requested delivery notifications, then the offramp gateway has various ways to handle these multiple return notices:
オフランプゲートウェイは、複数のGSTNの受信者への配信のためのインターネットファクスを受信することができます。エラーはインターネットファクス送信者を必要とする、発生した場合は、それらについて通知する、またはインターネットファクス送信者が配信通知を要求した場合、その後、オフランプゲートウェイは、これらの複数の戻り通知を処理するためのさまざまな方法があります：
1) An offramp gateway sends a return notice as soon as an error or a successful delivery occurs, per single GSTN recipient.
1）オフランプゲートウェイは、エラーとすぐに復帰通知を送信するか、成功した送達は、単一GSTN受取人ごとに、発生しました。
2) An offramp gateway gathers all information about the message, but sends a return notice only after all or a number of GSTN recipients have been handled (successfully or not).
2）オフランプゲートウェイは、メッセージに関するすべての情報を収集し、だけ結局復帰通知を送信するかGSTN受信者の数）が正常か否かを判定する（処理されています。
If Case 2 is implemented, then the offramp gateway MAY also choose to send separate success and failure notices, or to limit the number of GSTN recipients handled per single return note (for example, no more than 10 recipients per return note).
ケース2が実装されている場合、その後オフランプゲートウェイは、別々の成功および失敗通知を送信することを選択し得るか、または（例えば、リターンノート当たりせいぜい10の受信者）は、単一のリターンノートごとに取り扱わGSTN受信者の数を制限します。
When an offramp gateway fails in the transmission of a return notice, the Internet Fax Gateway SHOULD process the notice in either of the following ways:
オフランプゲートウェイが復帰通知の送信に失敗した場合、インターネットファックスゲートウェイは、次のいずれかの方法で通知を処理する必要があります。
1) The return notices SHOULD be re-queued, and delivery retried later. The number of retry attempts and the time interval between them MAY be a feature configured by the offramp gateway administrator. This is the preferred method to implement; however, if all the retransmission attempts fail, processing SHOULD continue as in Case 2.
1）復帰通知を再キューイングされ、そして送達は後で再試行されるべきです。再試行の数とそれらの間の時間間隔は、オフランプゲートウェイ管理者によって構成特徴であり得ます。これが実現する好ましい方法です。すべての再送信の試行が失敗した場合ただし、処理は、ケース2のように続けるべきです。
2) If the gateway does not have enough capabilities to handle notice re-queuing, but has a log information preservation function, the error information SHOULD be recorded to a log, and processing SHOULD end. At this time, the administrator of the gateway system SHOULD be notified of these errors using a specific method (for example, by an e-mail message).
2）ゲートウェイが通知の再キューイングを処理するのに十分な能力を有するが、ログ情報保存機能を有していない場合、エラー情報がログに記録されるべきで、処理を終了する必要があります。このとき、ゲートウェイシステムの管理者は、（例えば、電子メールメッセージによって）特定のメソッドを使用してこれらのエラーを通知する必要があります。
3) If the gateway does not even have a log information preservation function, the administrator SHOULD be notified about the failure (for example, via an e-mail message), and processing SHOULD end.
ゲートウェイがあっても、ログ情報の保存機能を持っていない場合3）、管理者）が電子メールメッセージを介して、例えば、（失敗について通知する必要があり、処理が終了します。
An offramp gateway SHOULD have a function that keeps information listed as a log, either specific to the fax gateway or in a log file that exists locally on the gateway or remotely. If the fax gateway or the remote system are equipped with recording media, the log information SHOULD be saved as a log file. As a last resort, if no recording media are available, the log MAY be printed.
オフランプゲートウェイは、FAXゲートウェイに特異的またはローカルゲートウェイにまたはリモートに存在するログファイルのいずれかで、ログとして記載されている情報を保持する機能を有しているべきです。ファックスゲートウェイまたはリモートシステムは、記録媒体が装備されている場合、ログ情報をログファイルとして保存する必要があります。何の記録メディアが利用できない場合は最後の手段として、ログを印刷することができます。
The information listed in the log MAY be the following:
ログに記載されている情報は、以下であってもよいです。
- Date and time when the Internet Fax is received - Sender address - Recipient address(es) - Start date and time of transmission over GSTN - End date and time of transmission over GSTN - Number of actually transmitted pages - Number of actually transmitted bytes - Fax resolution used - Error codes/text that occurred during transmission - Number of transmission attempts (retries) - Date and time of transmission of the (eventual) delivery notice
- 日付とインターネットファクスを受信した時 - 送信者アドレス - 受信者のアドレス（複数可） - GSTN上の送信の日付と時刻を開始 - GSTN上での伝送の終了日と時間 - 実際に送信ページ数 - 実際に送信されたバイト数 - 使用されるファックス解像度 - 伝送中に発生したエラーコード/テキスト - 送信試行（リトライ）の数 - 日付と（最終的な）送達通知の送信時
An onramp gateway MAY have a user authorization function to confirm that the user is authorized to transmit a facsimile into the Internet fax service. For example, user authorization may be accomplished by getting a user ID and password received by DTMF, or via a local authorization table based on the GSTN caller-ID. The following subsections give some possible examples, but other methods are also possible.
オンランプゲートウェイは、ユーザーがインターネットFAXサービスにファクシミリを送信するために許可されていることを確認するために、ユーザ認証機能を有していてもよいです。例えば、ユーザ認証は、またはGSTNの発信者IDに基づいてローカル許可テーブルを介してDTMFによって受信したユーザIDとパスワードを取得することによって達成することができます。以下のサブセクションでは、いくつかの可能な例を与えるが、他の方法も可能です。
The most simple method to authenticate and authorize a GSTN fax service user is to use the GSTN caller-ID. If available, in fact, the caller-ID is generated by the GSTN network service itself, and it is quite difficult to produce fake caller-IDs. In other words, the security related to this authentication method relies on the confidence that the GSTN caller-ID service is secure by itself.
GSTNファックスサービスのユーザーを認証し、認可するための最も簡単な方法は、GSTNの発信者IDを使用することです。可能な場合は、実際には、発信者IDは、GSTNネットワークサービス自体によって生成され、偽の発信者IDを生成することは非常に困難です。言い換えれば、この認証方法に関連するセキュリティはGSTN発信者IDサービスは、それ自体で安全であるという確信に依存しています。
The GSTN sender MAY be authorized via a lookup into a table managed by the onramp gateway administrator, via complete or partial (wildcard) matches.
GSTNの送信者は、完全または部分的な（ワイルドカード）の試合を経て、オンランプゲートウェイの管理者が管理するテーブルにルックアップから認可されるかもしれません。
During the initial GSTN fax service negotiation, the sender fax can send various information to the onramp gateway, including the "station ID" alphanumeric string. This string MAY be used to transmit authentication and authorization information for subsequent lookup by the onramp gateway. Thus, user ID and an eventual password MAY be sent inside this string.
初期GSTNファックスサービスネゴシエーション中に、送信者のファックスは、「駅ID」英数文字列を含む、オンランプゲートウェイに様々な情報を送信することができます。この文字列は、オンランプゲートウェイによるその後の検索のための認証および承認情報を送信するために使用されるかもしれません。このように、ユーザーIDとパスワード、最終的には、この文字列内で送信されるかもしれません。
However, if used as the only authentication, this method is much less secure than the caller-ID one because the user of the calling GSTN station can decide which string to send, and the string travels in clear form over the GSTN. Given this security warning, this method allows more flexibility to the GSTN user: in fact, it is not tied to a single GSTN fax terminal, and authorization can be obtained from anywhere, provided the sender has the possibility to configure the "station ID" on the device being used.
唯一の認証として使用する場合は、この方法はあまり安全な発信者ID 1呼び出しGSTNステーションのユーザーが送信するためにどの文字列を決めることができるためよりも、文字列はGSTN上をクリアフォームに進みます。このセキュリティ警告を考えると、このメソッドはGSTNユーザに、より柔軟性を可能に：実際には、それは単一のGSTNファックス端末に縛られず、認証がどこからでも得ることができ、送信者を提供する「駅ID」を設定する可能性がありますデバイス上で使用されています。
A combination of caller-ID and station ID checks MAY, on the other hand, result in a greatly improved level of security.
発信者IDとステーションIDチェックの組み合わせが、一方、セキュリティの大幅に改善レベルをもたらすことができます。
An onramp gateway MAY implement the Authorization function by requesting that a user ID and password information are sent over GSTN via DTMF. For example, this function MAY be accomplished by requesting that the DTMF information is sent immediately after the connection over GSTN is established, before starting the GSTN fax negotiation; but other methods are also possible.
オンランプゲートウェイは、ユーザーIDとパスワードの情報は、DTMF経由GSTNを介して送信されることを要求することにより、認証機能を実装してもよいです。たとえば、この機能はGSTNを介した接続がGSTNファックスネゴシエーションを開始する前に、確立された後にDTMF情報がすぐに送信されることを要求することにより達成することができます。しかし、他の方法も可能です。
An onramp gateway SHOULD have a function that keeps information listed as a log, either specific to the fax gateway or in a log file that exists locally on the gateway or remotely. If the fax gateway or the remote system are equipped with recording media, the log information SHOULD be saved as a log file. As a last resort, if no recording media are available, the log MAY be printed.
オンランプゲートウェイは、FAXゲートウェイに特異的またはローカルゲートウェイにまたはリモートに存在するログファイルのいずれかで、ログとして記載されている情報を保持する機能を有しているべきです。ファックスゲートウェイまたはリモートシステムは、記録媒体が装備されている場合、ログ情報をログファイルとして保存する必要があります。何の記録メディアが利用できない場合は最後の手段として、ログを印刷することができます。
The information listed in the log MAY be the following:
ログに記載されている情報は、以下であってもよいです。
- Start date and time of transmission from GSTN - End date and time of transmission from GSTN - Number of actually received pages - Number of actually received bytes - Fax resolution used - Sender address (if available) - Recipient address(es) - Date and time when the Internet Fax is sent - Error codes/text that occurred during Internet Fax transmission - Number of transmission attempts (retries) - Date and time of transmission of the (eventual) delivery notice
- GSTNからの送信の日付と時刻を開始 - GSTNからの送信の終了日と時間 - 実際に受信したページの数 - 実際に受信したバイト数 - 使用ファックスの解像度 - 送信者アドレス（使用可能な場合） - 受信者のアドレス（複数可） - 日付と時間インターネットファクスが送信される - インターネットファクス送信時に発生したエラーコード/テキスト - 送信試行回数（リトライ） - （最終的な）配達通知の送信の日付と時刻
Refer to Section 3.1 ("User Authorization") for authentication for an onramp gateway. In particular, sending user IDs and passwords in clear, as described in Section 3.1.2, can pose high security risks, and thus is NOT RECOMMENDED.
オンランプゲートウェイの認証のためのセクション3.1（「ユーザー認証」）を参照。具体的には、明確にユーザーIDとパスワードを送信し、セクション3.1.2で説明したように、高いセキュリティリスクをもたらすことができますので、お勧めしません。
S/MIME [2][11][12][13][14] and OpenPGP [3][10] can also be used to encrypt an Internet Fax 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. In this situation, 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 OpenPGP.
S / MIME [2] [11] [12] [13] [14]とのOpenPGP [3] [10]また、インターネットファクスメッセージを暗号化するために使用することができます。ネットワークに沿って搬送しながら、署名または暗号化されたメッセージは、保護されています。メッセージはインターネットファックスゲートウェイ、オンランプまたはオフランプのいずれかに到達したときただし、保護のこの種は、もはや適用することはできません。このような状況では、セキュリティゲートウェイ自体の信頼された操作に依存しなければなりません。ゲートウェイは、任意のゲートウェイと同じように、それはS / MIMEとOpenPGPの両方のエンドツーエンドのセキュリティパターンを壊し、インターネットファクスを送信するときに、セキュリティ・オペレーションを改善するために、独自の証明書/鍵を持っていますが、可能性があります。
Other security mechanisms, like IPsec [4][5][6][7][8] or TLS [9] also do not ensure a secure gateway operation.
IPsecのような他のセキュリティメカニズム、[4] [5] [6] [7] [8]またはTLS [9]また、セキュアゲートウェイの動作を保証するものではありません。
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.
DoS攻撃は、このドキュメントの範囲を超えています。実装の欠陥に起因するホストの妥協点は、このドキュメントの範囲を超えています。
Thanks to Claudio Allocchio (Consortium GARR, Italy) for its final review of this document, and for contributing the authorization and security sections of this document.
このドキュメントの最終的なレビューのためにクラウディオAllocchio（コンソーシアムGARR、イタリア）に、この文書の承認及びセキュリティセクションに貢献してくれてありがとう。
[1] Masinter, L., "Terminology and Goals for Internet Fax", RFC 2542, March 1999.
[1] Masinter、L.、 "用語およびインターネットファックスの目標"、RFC 2542、1999年3月を。
[2] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[2] Housley氏、R.、 "暗号メッセージ構文（CMS）"、RFC 3852、2004年7月。
[3] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[3]カラス、J.、Donnerhacke、L.、フィニー、H.、およびR.セイヤー、 "OpenPGPのメッセージフォーマット"、RFC 2440、1998年11月。
[4] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[4]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[5] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[5]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[6] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[6] "IPに明示的輻輳通知の添加（ECN）" ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月を。
[7] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[7]パイパー、D.、 "ISAKMPのための解釈のインターネットIPセキュリティー領域"、RFC 2407、1998年11月。
[8] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[8]セイヤー、R.、Doraswamy、N.、およびR.グレン、 "IPセキュリティドキュメントロードマップ"、RFC 2411、1998年11月。
[9] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003.
[9]ブレイク・ウィルソン、S.、Nystrom、M.、ホップウッド、D.、ミケルセン、J.、およびT.ライト、 "トランスポート層セキュリティ（TLS）の拡張"、RFC 3546、2003年6月。
[10] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[10]エルキンズ、M.、デルTorto、D.、Levien、R.、およびT.レスラー、 "OpenPGPのとMIMEセキュリティ"、RFC 3156、2001年8月。
[11] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[11]レスコラ、E.、 "ディフィー・ヘルマン鍵共有方法"、RFC 2631、1999年6月。
[12] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[12] Ramsdell、B.は、RFC 3850、2004年7月、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1証明書の取り扱い"。
[13] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[13] Ramsdell、B.、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様"、RFC 3851、2004年7月。
[14] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[14]ホフマン、P.、RFC 2634、1999年6月、 "S / MIMEのためのセキュリティサービスの強化"。
[15] Mimura, K., Yokoyama, K., Satoh, T., Kanaide, C., and C. Allocchio, "Internet Fax Gateway Requirements", RFC 4160, August 2005.
[15]三村、K.、横山、K.、佐藤、T.、Kanaide、C.、及びC. Allocchio、 "インターネットファクスゲートウェイ要件"、RFC 4160、2005年8月。
[16] Toyoda, K., Ohno, H., Murai, J., and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 3965, December 2004.
[16]豊田、K.、大野、H.、村井、J.、およびD.翼、 "インターネットメールを使用するファクシミリのシンプルモード"、RFC 3965、2004年12月。
[17] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[17]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[18] "Procedures for real-time Group 3 facsimile communication over IP networks", ITU-T Recommendation T.38, June 1998.
[18]、ITU-T勧告T.38、1998年6月 "IPネットワーク上のリアルタイムグループ3ファクシミリ通信のための手順"。
[19] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[19] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[20] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[20]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[21] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[21]マイヤーズ、J.とM.ローズ、 "ポストオフィスプロトコル - バージョン3"、STD 53、RFC 1939、1996年5月。
[22] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003.
[22]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。
Authors' Addresses
著者のアドレス
Katsuhiko Mimura TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa-pref., Japan
かつひこ みむら とよ こっむにかちおん えくいｐめんｔ こ。、 ＬＴＤ。 ２ー１ー１ こやと、 さむかわーまち、 こざーぐん かながわーｐれｆ。、 じゃぱん
Fax: +81 467 74 5743 EMail: mimu@miyabi-labo.net
ファックス：+81 467 74 5743 Eメール：mimu@miyabi-labo.net
Keiichi Yokoyama TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa-pref., Japan
けいいち よこやま とよ こっむにかちおん えくいｐめんｔ こ。、 ＬＴＤ。 ２ー１ー１ こやと、 さむかわーまち、 こざーぐん かながわーｐれｆ。、 じゃぱん
Fax: +81 467 74 5743 EMail: keiyoko@msn.com
ファックス：+81 467 74 5743 Eメール：keiyoko@msn.com
Takahisa Satoh TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa-pref., Japan
たかひさ さとｈ とよ こっむにかちおん えくいｐめんｔ こ。、 ＬＴＤ。 ２ー１ー１ こやと、 さむかわーまち、 こざーぐん かながわーｐれｆ。、 じゃぱん
Fax: +81 467 74 5743 EMail: zsatou@t-ns.co.jp
ファックス：+81 467 74 5743 Eメール：zsatou@t-ns.co.jp
Ken Watanabe TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa-pref., Japan
けん わたなべ とよ こっむにかちおん えくいｐめんｔ こ。、 ＬＴＤ。 ２ー１ー１ こやと、 さむかわーまち、 こざーぐん かながわーｐれｆ。、 じゃぱん
Fax: +81 467 74 5743 EMail: knabe@ad.cyberhome.ne.jp
ファックス：+81 467 74 5743 Eメール：knabe@ad.cyberhome.ne.jp
Chie Kanaide TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa-pref., Japan
ちえ かないで とよ こっむにかちおん えくいｐめんｔ こ。、 ＬＴＤ。 ２ー１ー１ こやと、 さむかわーまち、 こざーぐん かながわーｐれｆ。、 じゃぱん
Fax: +81 467 74 5743 EMail: icemilk77@yahoo.co.jp
ファックス：+81 467 74 5743 Eメール：icemilk77@yahoo.co.jp
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。