RFC4161 日本語訳

Network Working Group                                         K. Mimura
Request for Comments: 4161                                  K. Yokoyama
Category: Informational                                        T. Satoh
                                                            K. Watanabe
                                                             C. Kanaide
                                           TOYO Communication Equipment
                                                            August 2005

Mimuraがコメントのために要求するワーキンググループK.をネットワークでつないでください: 4161年のK.横山カテゴリ: 情報のT.の渡辺C.Kanaideトーヨ通信設備佐藤K.2005年8月

       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).

Copyright(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ファックス)とメールベースのインターネットファックスサービス(i-ファックス)の間の接続性を許容するために、「インターネットファックスゲートウェイ」が必要です。 このドキュメントはインターネットファックスGatewaysの任意の機能性のためのガイドラインを提供します。 このような関係においては、「出口ランプゲートウェイ」はi-ファックスからGSTNファックスまでファクシミリデータ伝送を提供します。 逆もまた同様です、「入口ランプゲートウェイ」はGSTNファックスからi-ファックスまでデータ伝送を提供します。 推薦は本書ではインターネットファックス端末、i-ファックスソフトウェアがインターネットにあるコンピュータ、および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(二元的な利根Multi-頻度)でコピーされたファックス通信、自動ファックス再トランスミッション、誤り、リターン通知、ログ取り扱い、および可能な承認メソッドを入口ランプゲートウェイに下げるためのテクニックをカバーしています。

Mimura, et al.               Informational                      [Page 1]

RFC 4161      Optional Services for Internet Fax Gateways    August 2005

Mimura、他 インターネットのための情報[1ページ]のRFC4161の任意のサービスは2005年8月にファックスでゲートウェイを送ります。

1.  Introduction

1. 序論

   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(二元的な利根Multi-頻度)でコピーされたファックス通信、自動ファックス再トランスミッション、誤り、リターン通知、ログ取り扱い、および可能な承認メソッドを入口ランプゲートウェイに下げるためのテクニックをカバーしています。

   A more detailed definition of onramps and offramps is provided in
   [1].  Recommended behaviors for Internet Fax Gateway functions are
   defined in [15].

入口ランプと出口ランプの、より詳細な定義を[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) インターネットファックスの操作上のモードは[1]のセクション2.5で定義されるように「店とフォワード」です。

   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]で説明されて、定義されるようにゲートウェイ機能に適用されません。

1.1.  Key Words

1.1. キーワード

   The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this
   document are to be interpreted as described in [17].

キーワード“MUST"、“SHOULD"、「」 「5月」は[17]で説明されるように本書では解釈されることになっているべきです。

2.  Optional Services for an Offramp Gateway

2. 出口ランプゲートウェイのための任意のサービス

2.1.  Drop Duplicated GSTN Fax Transmission

2.1. コピーされたGSTNファックス送信を下げてください。

   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

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

Mimura、他 インターネットのための情報[2ページ]のRFC4161の任意のサービスは2005年8月にファックスでゲートウェイを送ります。

   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.

しかしながら、1人以上の受取人を含みますが、同じ最終的なMTAに向けられるメールメッセージ(インターネットファックスのものを含んでいる)の取り扱いは異なる場合があります、MTA構成か特徴によって。 複数の受取人がSMTP封筒[19]にいるただ一つのメッセージはメール輸送システムで最も一般的なケースである傾向がありますが、同じメッセージの複本が伝えられるのは起こるかもしれません、1受取人あたり1つ。 または、最終的なMTAが1受取人あたりのメッセージの別々のコピーを最終的なメールボックスの中に提供するように用意ができているのを起こるかもしれません、異なったendusersの本当のメールボックスにメッセージを提供していると思って。

   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.

したがって、出口ランプゲートウェイが複本に関するインターネットファックスのメールメッセージヘッダー[20]に一緒に、繰り返して記載されている異なったGSTN送付先に提供されることになっているのと同じインターネットファックスメッセージを受け取るのは起こるかもしれません。 そのような場合、出口ランプゲートウェイSHOULDは、同じファックス通信のGSTNの上で同じ受取人として写しか複駆動動力伝達装置を避けるためにテクニックを実装します。

   Here are some possible, but non-exclusive, examples of these
   techniques.

ここに、これらのテクニックのいくつかの可能な、しかし、非排他的な例があります。

2.1.1.  SMTP Envelope Addresses Check

2.1.1. SMTP封筒アドレスはチェックします。

   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.

中に与えられたSMTP[19]封筒送付先アドレスを使用する、「通常、」 分野へのRCPTは受信されたメッセージがそのアドレスに提供されるのを保証して、写し配送を避ける最も良いテクニックです。

   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.

出口ランプゲートウェイがそうした、「」 処理の間、まだ利用可能な情報へのRCPT、そして、それはGSTNファックスサービスの上で受取人を決定するのにそれを使用しなければなりません。

2.1.2 Message-ID Check

2.1.2 Message IDチェック

   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.

例えば、出口ランプゲートウェイがどちらかを使用することでメールボックスからのメッセージを検索する場合では、[21]かIMAP[22])を飛び出させてください、ヘッダー「Message ID」というメッセージ。SMTPである、「」 情報へのRCPTが利用可能でない、(([20])が既にメッセージを処理してあるかどうかチェックするのに使用されるかもしれなくて、したがって、出口ランプゲートウェイによって扱われたすべてのGSTN受取人として「再-トランスミッション」を避けるのを見てください。

Mimura, et al.               Informational                      [Page 3]

RFC 4161      Optional Services for Internet Fax Gateways    August 2005

Mimura、他 インターネットのための情報[3ページ]のRFC4161の任意のサービスは2005年8月にファックスでゲートウェイを送ります。

2.2.  Error Handling

2.2. エラー処理

2.2.1.  Recoverable Errors

2.2.1. 回復可能エラー

   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.

これらのすべての誤りによって、出口ランプゲートウェイSHOULDはメッセージを再列に並ばせて、後で「再-トランスミッション」試みを実行します、セクション2.3で指定されるように。

2.2.2.  Non-Recoverable Errors

2.2.2. 非回復可能エラー

   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トランスミッションの間に発生する誤りがおそらく非回復可能であるなら、出口ランプゲートウェイSHOULD NOTは「再-トランスミッション」を試みます、そして、インターネットファックスメッセージ送付者のために適切なエラーコードがある誤りMessage Delivery Notification(MDN)を生成しなければなりません。 非回復可能エラーに関する例は遠く離れた目的地、声の回答の誤差、データモデム回答の誤差、および停止イベント誤りからの遠隔装置、どんな応答のときにも紙の関連の誤り(ジャム、空のトレーなどの)を含んでいません。

2.3.  Automatic Re-Transmission Handling

2.3. 自動再トランスミッション取り扱い

   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:

回復可能な配信障害が起こるなら、SHOULDがそんなに自動的に機能を実装する出口ランプゲートウェイは再びファクシミリデータを送ろうとします。 次に、この機能が実装されるなら:

   - 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;

- どんな誤りリターンも、再試行の最大数が成功なしで完成したときだけ、SHOULDが送られるのに気付きます。

   - if transmission is suspended due to an error, then the subsequent
     transmission attempt SHOULD avoid retransmitting the pages already
     delivered successfully, if any.

- トランスミッションが誤りのため中断するなら、その後のトランスミッション試みSHOULDは、既に首尾よくもしあれば提供されたページを再送するのを避けます。

2.4.  Multiple Return Notice Handling

2.4. 複数のリターン通知取り扱い

   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受取人に受けることができます。 誤り(インターネットファックス送付者はそれらに関して知識があるのを必要とする)が発生したか、またはインターネットファックス送付者が配送通知を要求したなら、出口ランプゲートウェイには、これらの複数のリターン通知を扱う様々な方法があります:

Mimura, et al.               Informational                      [Page 4]

RFC 4161      Optional Services for Internet Fax Gateways    August 2005

Mimura、他 インターネットのための情報[4ページ]のRFC4161の任意のサービスは2005年8月にファックスでゲートウェイを送ります。

   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).

また、Case2が実装されるなら、出口ランプゲートウェイは、別々の成功と失敗通知を送るか、またはただ一つのリターンメモ(例えば、リターン注意あたり10人未満の受取人)単位で扱われたGSTN受取人の数を制限するのを選ぶかもしれません。

2.5.  Handling Transmission Errors for a Return Notice

2.5. リターン通知のための取り扱い伝送エラー

   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:

出口ランプゲートウェイがリターン通知の伝達に失敗すると、インターネットファックスゲートウェイSHOULDは以下の方法のどちらかで通知を処理します:

   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) リターンは、SHOULDが再列に並ばせられるのに気付きます、そして、配送は後で再試行されました。 再試行試みの数とそれらの時間間隔は出口ランプのゲートウェイ管理者によって構成された特徴であるかもしれません。 これは実装する適した方法です。 しかしながら、すべての「再-トランスミッション」試みが失敗するなら、処理SHOULDはCase2のように続きます。

   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) ゲートウェイに、通知再の列を作りを扱うことができるくらいの能力を持っていませんが、ログ情報保存機能があるなら、エラー情報SHOULDですログに記録されて、SHOULDエンドを処理することである。 このとき、管理者、ゲートウェイシステムSHOULDでは、これらの誤りがa特定のメソッド(例えばメールメッセージで)を使用するのについて通知されてください。

   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) ゲートウェイがそうしないでも、ログ情報保存機能、管理者SHOULDは失敗(例えばメールメッセージで)、および処理SHOULDエンドに関して通知されましたか?

2.6.  Offramp Gateway Log

2.6. 出口ランプゲートウェイログ

   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.

SHOULDがログとして記載されて、ファックスゲートウェイかログで特定に情報を保つ機能にファイルさせる局所的にゲートウェイか離れて存在する出口ランプゲートウェイ。 ファックスゲートウェイかリモートシステムがそうなら、ログファイルとしてメディア、ログ情報SHOULDを記録しながら備えられている状態で保存されてください。 最後の手段として、どんな録音メディアも利用可能でないなら、ログは印刷されるかもしれません。

Mimura, et al.               Informational                      [Page 5]

RFC 4161      Optional Services for Internet Fax Gateways    August 2005

Mimura、他 インターネットのための情報[5ページ]のRFC4161の任意のサービスは2005年8月にファックスでゲートウェイを送ります。

   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

- (最後)の引渡通告書の伝達のインターネットファックスが受け取られている日時--送付者アドレス--受取人アドレス(es)--GSTNの上のトランスミッションのStart日時--終了日とGSTNの上のトランスミッションの時間--ファックス決議が使用した実際に伝えられたページ(実際に伝えられたバイトの数)の数--トランスミッションの間に起こったエラーコード/テキスト--トランスミッション試み(再試行)の数--日時

3.  Optional Services for an Onramp Gateway

3. 入口ランプゲートウェイのための任意のサービス

3.1.  Examples of User Authorization

3.1. ユーザ承認に関する例

   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.

入口ランプゲートウェイで、ユーザ承認は、ユーザがインターネットファックスサービスにファクシミリを伝えるのに権限を与えられると確認するために機能するかもしれません。 例えば、ユーザ承認は、DTMFの近く、または、GSTN発信者番号に基づく地方の承認テーブルを通してユーザIDとパスワードを受け取らせることによって、達成されるかもしれません。 以下の小区分はいくつかの可能な例を出しますが、また、他のメソッドも可能です。

3.1.1.  Authorization via GSTN Caller-ID

3.1.1. GSTN発信番号表示を通した承認

   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発信者番号を使用することです。 利用可能です、事実上、発信者番号がGSTNネットワーク・サービス自体で生成されて、にせの発信者番号を生産するのがかなり難しいなら。 言い換えれば、この認証方法に関連するセキュリティはGSTN発信者番号サービスがそれ自体で安全であるという信用を当てにします。

   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送付者は権限を与えられるかもしれません、完全であるか部分的な(ワイルドカード)マッチを通して。

3.1.2.  Authorization via GSTN Fax "Station ID"

3.1.2. GSTNファックス「駅のID」を通した承認

   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と最後のパスワードを送るかもしれません。

Mimura, et al.               Informational                      [Page 6]

RFC 4161      Optional Services for Internet Fax Gateways    August 2005

Mimura、他 インターネットのための情報[6ページ]のRFC4161の任意のサービスは2005年8月にファックスでゲートウェイを送ります。

   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.

しかしながら、唯一の認証として使用されるなら、呼んでいるGSTNステーションのユーザが、どのストリングを送ったらよいかを決めることができるので、このメソッドは発信者番号1よりあまり安全ではありません、そして、ストリングは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チェックの組み合わせは大いに改良されたレベルのセキュリティをもたらすかもしれません。

3.1.3.  Authorization via DTMF

3.1.3. DTMFを通した承認

   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の上に送られるよう要求することによって、入口ランプゲートウェイはAuthorization機能を実装するかもしれません。 例えば、GSTNの上の接続が確立される直後DTMF情報が送られるよう要求することによって、この機能は達成されるかもしれません、GSTNファックス交渉を始める前に。 しかし、また、他のメソッドも可能です。

3.2.  Onramp Gateway Log

3.2. 入口ランプゲートウェイログ

   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.

SHOULDがログとして記載されて、ファックスゲートウェイかログで特定に情報を保つ機能にファイルさせる局所的にゲートウェイか離れて存在する入口ランプゲートウェイ。 ファックスゲートウェイかリモートシステムがそうなら、ログファイルとしてメディア、ログ情報SHOULDを記録しながら備えられている状態で保存されてください。 最後の手段として、どんな録音メディアも利用可能でないなら、ログは印刷されるかもしれません。

   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からのトランスミッションの終了日と時間--ファックス決議が使用した実際に容認されたページ(実際に容認されたバイトの数)の数--送付者アドレス(利用可能であるなら)--受取人アドレス(es)--インターネットファックスが送られる日時--インターネットファックス送信の間に起こったエラーコード/テキスト--トランスミッション試み(再試行)の数--(最後)の引渡通告書の伝達の日時からトランスミッションの日時を始めてください。

Mimura, et al.               Informational                      [Page 7]

RFC 4161      Optional Services for Internet Fax Gateways    August 2005

Mimura、他 インターネットのための情報[7ページ]のRFC4161の任意のサービスは2005年8月にファックスでゲートウェイを送ります。

4.  Security Considerations

4. セキュリティ問題

   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(「ユーザ承認」)を参照してください。 セクション3.1.2で説明されるようにはっきりとユーザIDとパスワードを送るのは、特に、高いセキュリティ危険を引き起こすことができて、その結果、NOT RECOMMENDEDです。

   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.

また[7][8]かTLS[9]がするIPsec[4][5][6]が安全なゲートウェイ操作を確実にしないような他のセキュリティー対策。

   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.

サービス不能攻撃はこのドキュメントの範囲を超えています。 実装における欠点によって引き起こされたホスト感染はこのドキュメントの範囲を超えています。

5.  Acknowledgments

5. 承認

   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(共同体のガー(イタリア))をありがとうございます。

6.  References

6. 参照

6.1.  Informative References

6.1. 有益な参照

   [1]  Masinter, L., "Terminology and Goals for Internet Fax", RFC
        2542, March 1999.

[1] より多くのMasinterに、L.と、「インターネットファックスの用語と目標」(RFC2542)は1999を行進させます。

   [2]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
        July 2004.

[2]Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、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メッセージ・フォーマット」、RFC2440、1998年11月。

   [4]  Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.

[4] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。

Mimura, et al.               Informational                      [Page 8]

RFC 4161      Optional Services for Internet Fax Gateways    August 2005

Mimura、他 インターネットのための情報[8ページ]のRFC4161の任意のサービスは2005年8月にファックスでゲートウェイを送ります。

   [5]  Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
        November 1998.

[5] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。

   [6]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
        Explicit Congestion Notification (ECN) to IP", RFC 3168,
        September 2001.

[6]Ramakrishnan、K.、フロイド、S.、およびD.黒、「明白な混雑通知のIPへの追加(電子証券取引ネットワーク)」、RFC3168(2001年9月)。

   [7]  Piper, D., "The Internet IP Security Domain of Interpretation
        for ISAKMP", RFC 2407, November 1998.

[7] パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。

   [8]  Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document
        Roadmap", RFC 2411, November 1998.

[8] セイヤーとR.とDoraswamy、N.とR.グレン、「IPセキュリティドキュメント道路地図」、RFC2411、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.、ニストロム、M.、Hopwood(D.、ミッケルセン、J.、およびT.ライト)は「層のセキュリティ(TLS)拡大を輸送します」、RFC3546、2003年6月。

   [10] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME
        Security with OpenPGP", RFC 3156, August 2001.

2001年8月の[10] エルキンズとM.とデルTortoとD.とレヴィエン、R.とT.Roessler、「OpenPGPがあるMIMEセキュリティ」RFC3156。

   [11] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631,
        June 1999.

[11] レスコラ、E.、「ディフィー-ヘルマンの主要な協定メソッド」、RFC2631、1999年6月。

   [12] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
        (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.

Ramsdell(B.)が「/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1証明書取り扱いであると機密保護する」[12]、RFC3850、2004年7月。

   [13] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
        (S/MIME) Version 3.1 Message Specification", RFC 3851, July
        2004.

Ramsdell(B.)が「/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様であると機密保護する」[13]、RFC3851、2004年7月。

   [14] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634,
        June 1999.

[14] ホフマン、P.、「S/MIMEのための警備の強化サービス」、RFC2634、1999年6月。

6.2.  Normative References

6.2. 引用規格

   [15] Mimura, K., Yokoyama, K., Satoh, T., Kanaide, C., and C.
        Allocchio, "Internet Fax Gateway Requirements", RFC 4160, August
        2005.

[15]MimuraとK.と横山とK.と佐藤とT.とKanaide、C.とC.Allocchio、「インターネットファックスゲートウェイ要件」、RFC4160、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.は飛んで行きます、「ファクシミリの簡単なモードはインターネットメールを使用し」て、RFC3965、2004年12月。

   [17] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[17] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [18] "Procedures for real-time Group 3 facsimile communication over
        IP networks", ITU-T Recommendation T.38, June 1998.

[18] 「IPネットワークの上のリアルタイムのGroup3ファクシミリ通信のための手順」、ITU-T Recommendation T.38、1998年6月。

Mimura, et al.               Informational                      [Page 9]

RFC 4161      Optional Services for Internet Fax Gateways    August 2005

Mimura、他 インターネットのための情報[9ページ]のRFC4161の任意のサービスは2005年8月にファックスでゲートウェイを送ります。

   [19] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
        2001.

[19]Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。

   [20] Resnick, P., "Internet Message Format", RFC 2822, April 2001.

[20] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。

   [21] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
        53, RFC 1939, May 1996.

[21] マイアーズ、J.、およびM.ローズ、「郵便局は議定書を作ります--バージョン3インチ、STD53、RFC1939、1996年5月。」

   [22] Crispin, M., "Internet Message Access Protocol - Version 4rev1",
        RFC 3501, March 2003.

[22] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」

Mimura, et al.               Informational                     [Page 10]

RFC 4161      Optional Services for Internet Fax Gateways    August 2005

Mimura、他 インターネットのための情報[10ページ]のRFC4161の任意のサービスは2005年8月にファックスでゲートウェイを送ります。

Authors' Addresses

作者のアドレス

   Katsuhiko Mimura
   TOYO Communication Equipment CO., LTD.
   2-1-1 Koyato, Samukawa-machi, Koza-gun
   Kanagawa-pref., Japan

克彦Mimuraトーヨ通信設備CO Ltd.2-1-1Koyato(寒川-machi)が神奈川-prefを古座で銃撃する、日本

   Fax: +81 467 74 5743
   EMail: mimu@miyabi-labo.net

Fax: +81 467 74 5743はメールされます: mimu@miyabi-labo.net

   Keiichi Yokoyama
   TOYO Communication Equipment CO., LTD.
   2-1-1 Koyato, Samukawa-machi, Koza-gun
   Kanagawa-pref., Japan

Keiichi横山トーヨ通信設備CO Ltd.2-1-1Koyato(寒川-machi)が神奈川-prefを古座で銃撃する、日本

   Fax: +81 467 74 5743
   EMail: keiyoko@msn.com

Fax: +81 467 74 5743はメールされます: keiyoko@msn.com

   Takahisa Satoh
   TOYO Communication Equipment CO., LTD.
   2-1-1 Koyato, Samukawa-machi, Koza-gun
   Kanagawa-pref., Japan

Takahisa佐藤トーヨ通信設備CO Ltd.2-1-1Koyato(寒川-machi)が神奈川-prefを古座で銃撃する、日本

   Fax: +81 467 74 5743
   EMail: zsatou@t-ns.co.jp

Fax: +81 467 74 5743はメールされます: zsatou@t-ns.co.jp

   Ken Watanabe
   TOYO Communication Equipment CO., LTD.
   2-1-1 Koyato, Samukawa-machi, Koza-gun
   Kanagawa-pref., Japan

渡辺健トーヨ通信設備CO Ltd.2-1-1Koyato(寒川-machi)が神奈川-prefを古座で銃撃する、日本

   Fax: +81 467 74 5743
   EMail: knabe@ad.cyberhome.ne.jp

Fax: +81 467 74 5743はメールされます: knabe@ad.cyberhome.ne.jp

   Chie Kanaide
   TOYO Communication Equipment CO., LTD.
   2-1-1 Koyato, Samukawa-machi, Koza-gun
   Kanagawa-pref., Japan

知恵Kanaideトーヨ通信設備CO Ltd.2-1-1Koyato(寒川-machi)が神奈川-prefを古座で銃撃する、日本

   Fax: +81 467 74 5743
   EMail: icemilk77@yahoo.co.jp

Fax: +81 467 74 5743はメールされます: icemilk77@yahoo.co.jp

Mimura, et al.               Informational                     [Page 11]

RFC 4161      Optional Services for Internet Fax Gateways    August 2005

Mimura、他 インターネットのための情報[11ページ]のRFC4161の任意のサービスは2005年8月にファックスでゲートウェイを送ります。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Mimura, et al.               Informational                     [Page 12]

Mimura、他 情報[12ページ]