RFC4160 日本語訳

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

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

                   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)インターネット協会(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.

一般Switched Telephone Networkファクシミリサービス(GSTNファックス)とメールベースのインターネットファックスサービス(i-ファックス)の間の接続性に「インターネットファックスゲートウェイ」を許容するのが必要です。 このドキュメントはインターネットファックスGatewaysの機能性のための推薦を提供します。 このような関係においては、「出口ランプゲートウェイ」はi-ファックスからGSTNファックスまでファクシミリデータ伝送を提供します。 逆もまた同様です、「入口ランプゲートウェイ」はデータ伝送フォームGSTNファックスをi-ファックスに供給します。 推薦は本書ではインターネットファックス端末、i-ファックスソフトウェアがインターネットにあるコンピュータ、およびGSTNの上のGSTNファックス端末を含む統合サービスに適用されます。

1.  Introduction

1. 序論

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

インターネットファックスゲートウェイは一般Switched Telephone Networkファクシミリサービス(GSTNファックス)とメールベースのインターネットファックスサービス(i-ファックス)の間に接続性と翻訳を提供します。 このドキュメントはインターネットファックスゲートウェイのお勧めの振舞いを定義します。 「入口ランプ」としてインターネットファックスゲートウェイを分類できます、GSTNファックスからインターネットファックスまで「出口ランプ」としてファクシミリを移すとき、インターネットファックスからGSTNファックスまでファクシミリを移すとき。 i-ファックスサービスの中の「入口ランプ」と「出口ランプ」の、より詳細な定義に関しては、[1]を見てください。

Mimura, et al.               Informational                      [Page 1]

RFC 4160           Internet Fax Gateway Requirements         August 2005

Mimura、他 [1ページ]情報のRFC4160インターネットファックスゲートウェイ要件2005年8月

   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]で説明されます。

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 [5].

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

2.  Internet Fax Gateway Operations

2. インターネットファックスゲートウェイ操作

   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.

入口ランプゲートウェイは、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.

出口ランプゲートウェイは、どんなインターネットのファックスできるデバイス(入口ランプゲートウェイかPCを含むかもしれない)からもインターネットファックスをインターネットの上に受けて、GSTNファックスを生成します。(それは、どんなGSTNファックスデバイスにも送られます)。

   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側面がGSTNファックスデバイスとして機能しますが、[6]で説明されるように。

   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) 入口ランプゲートウェイは、GSTNから受け止められたファックスを変換して、インターネットファックスサービスにそれを送ります。

   2) the offramp gateway converts a fax received from the Internet and
      forwards it to the GSTN fax service.

2) 出口ランプゲートウェイは、インターネットから受け止められたファックスを変換して、GSTNファックスサービスにそれを送ります。

Mimura, et al.               Informational                      [Page 2]

RFC 4160           Internet Fax Gateway Requirements         August 2005

Mimura、他 [2ページ]情報のRFC4160インターネットファックスゲートウェイ要件2005年8月

3.  The Offramp Gateway Operations

3. 出口ランプゲートウェイ操作

   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.

- ユーザ承認。

3.1.  User Authorization

3.1. ユーザ承認

   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.

出口ランプゲートウェイで、ユーザ承認は、ユーザがインターネットファックスをGSTNファックスサービスに送ることができると確認するために機能するかもしれません。

   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メールメッセージとしてインターネットファックスを出口ランプゲートウェイに送るので、ユーザを認証して、権限を与えるのにデジタル署名を使用できます。 S/MIMEはデジタル署名サービスを含んでいるプロトコルに関する1つの例です。 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.

インターネットファックス(入口ランプゲートウェイを含むかもしれない)を送るエージェントはデジタルに署名しているS/MIMEかOpenPGPファックスメッセージを出口ランプゲートウェイに送ります。 そして、出口ランプゲートウェイは、GSTNファックスサービスにファックスを送るためにその人が認可されているかどうか決定するためにユーザの資格証明書を比較します。 承認プロセスが失敗するなら、出口ランプゲートウェイはインターネットファックスの送付者のために誤り配送通知を生成しなければなりません。

3.2.  Addressing

3.2. アドレシング

   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.

インターネットファックスは創始者として受取人として複数のEメールアドレスを含むかもしれません。 GSTNファックスサービスへの推進機能のために、出口ランプゲートウェイは明らかにそれ自体でそうであるそれらのアドレス、すなわち、Eメールアドレスの右側が出口ランプゲートウェイに対応するところのそれらを考えるだけでよいです。

   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.

インターネットファックスサービスに関するアドレスがGSTNファックスサービスで目的地に達するEメールアドレスであるので、出口ランプゲートウェイはGSTNアドレスにEメールアドレスを変換しなければなりません。

Mimura, et al.               Informational                      [Page 3]

RFC 4160           Internet Fax Gateway Requirements         August 2005

Mimura、他 [3ページ]情報のRFC4160インターネットファックスゲートウェイ要件2005年8月

   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の目的地はコード化された内部がEメールアドレスの左側であったならSHOULDを扱います。 しかしながら、出口ランプゲートウェイは、左側ストリングを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.

どのような場合でも、出口ランプゲートウェイは、結果の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.

また、出口ランプゲートウェイSHOULDには、インターネットファックスと呼ばれた創始者アドレスと他のアドレスに翻訳を適用する機能があります、GSTNファックスサービスからインターネットファックスの目的地まで可能なリターンパスを確実にするために、他の出口ランプゲートウェイを含んでいて。 これらの機能は入口ランプゲートウェイのこのドキュメントのセクション4.2で説明されるアドレス取り扱いで対応するに違いありません。

3.2.1.  Examples of Local Dialing Rules Applied to GSTN Destination
        Addresses

3.2.1. GSTN送付先アドレスに適用されたローカルのダイヤルする規則に関する例

   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インチ(国際的な国名略号が地方であると認める)と、次に、直接出口コードなしで以下にダイヤルすることができるのを知っていること」で出口ランプゲートウェイがどう「グローバルな電話」を「地方の電話」に変換するかを示しています。

      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インチ(国際的な国名略号が地方であると認める)と、次に、出口コードを加える、「ストリングの0インチ:」

      global-phone:   +441164960348

グローバルな電話: +441164960348

   resulting in:

もたらします:

      local-phone:   01164960348

地方の電話: 01164960348

Mimura, et al.               Informational                      [Page 4]

RFC 4160           Internet Fax Gateway Requirements         August 2005

Mimura、他 [4ページ]情報のRFC4160インターネットファックスゲートウェイ要件2005年8月

   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:

最後の例が国際的な国名略号が非地方であることを見分けて、接頭語にダイヤルしながら国際的にローカルを言い足して、出口ランプゲートウェイが「+」を取り除くことによって「グローバルな電話」をどう「地方の電話」に変換するかを示している、「ストリングの0インチ:」

      global-phone:   +441164960348

グローバルな電話: +441164960348

   resulting in:

もたらします:

      local-phone:   00441164960348

地方の電話: 00441164960348

3.2.2.  Support for Subaddress

3.2.2. Subaddressのサポート

   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.

SHOULDが「副-アドレス」をサポートする出口ランプゲートウェイ。 「副-アドレス」がEメールアドレス[7]の左側にコード化されるなら、出口ランプゲートウェイでそれを使用しなければなりません、最終的なGSTNファックス受取人に届くようにT.33[15]で指定されるように。

3.3.  Image Format Conversion

3.3. 画像形式変換

   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.

出口ランプゲートウェイはインターネットファックスのためにTIFF Profile-Sからファイル形式を変換しなければなりません。([16])では、GSTNファックス画像形式と定義されます。 他のインターネットファックスファイル形式は本書では考えられません。

3.4.  Error/Return Notification Handling

3.4. 誤り/リターン通知取り扱い

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

出口ランプゲートウェイSHOULDには、それが創始者インターネットファックスデバイスにリターン通知を送ることができる機能があります。([4])では、いつ伝送エラーがGSTNファックスサービスの上に起こって、ファクシミリが送付先に提供されないかを定義しました。 リターン通知は、Message Delivery Notification(MDN)形式にはあるに違いなくて、出口ランプゲートウェイによってインターネットファックスによって使用されるインターネット電子メール輸送サービスの上に提供されます。 MDN気質タイプは「処理される」ようにセットであるに違いありません、そして、「誤り」として気質修飾語を設定しなければなりません。

Mimura, et al.               Informational                      [Page 5]

RFC 4160           Internet Fax Gateway Requirements         August 2005

Mimura、他 [5ページ]情報のRFC4160インターネットファックスゲートウェイ要件2005年8月

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

出口ランプゲートウェイがMDNを伝えないなら、エラー情報が5月の終わりにログ、および処理に記録されるかもしれませんか、または特定のメソッド(例えばメールメッセージで)でゲートウェイシステムの管理者はこれらの誤りについて通知されるかもしれません。

   The more complex case of Delivery Status Notification (DSN) requests
   handling is not considered in this document.

Delivery Status Notification(DSN)要求取り扱いの、より複雑なケースは本書では考えられません。

4.  The Onramp Gateway Operations

4. 入口ランプゲートウェイ操作

   An onramp gateway MUST, as minimal requirement, perform the following
   functions:

最小量の要件として、入口ランプゲートウェイは以下の機能を実行しなければなりません:

   - address translation/mapping,
   - image format conversion, and
   - error/return notification handling,

- そして、翻訳/マッピング--画像形式が変換であると扱ってください、--誤り/リターン通知取り扱い

   and MAY also perform

そして、また、働くかもしれません。

   - user authorization.

- ユーザ承認。

4.1.  User Authorization

4.1. ユーザ承認

   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.

入口ランプゲートウェイで、ユーザ承認は、ユーザがインターネットファックスサービスにファクシミリを伝えるのに権限を与えられると確認するために機能するかもしれません。 例えば、ユーザ承認はDual利根Multi-頻度(DTMF)の近く、または、ベースの地方の承認テーブルを通して受け取られたユーザIDとパスワードがオンになるのによるGSTN訪問者の優れたIDであるかもしれません。

   If the authorization process fails, then the onramp gateway MUST
   generate an error message/code for the sender of the GSTN Fax.

承認プロセスが失敗するなら、入口ランプゲートウェイはGSTNファックスの送付者のためにエラーメッセージ/コードを生成しなければなりません。

4.2.  Address Translation/Mapping

4.2. アドレス変換/マッピング

   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:

インターネットファックスサービスに関するアドレスがEメールアドレスである、その結果、インターネットファックスの受取人は、メールユーザ、それ自身の受取人/ユーザがいるインターネットファックスデバイス、または出口ランプゲートウェイであるかもしれません。 入口ランプゲートウェイSHOULDには、機能性が、GSTN(DTMFを通した)送付先アドレスから受信するためにあります。 しかしながら、送付先アドレスの2つのカテゴリがあります:

      - e-mail users and Internet Fax recipient/users
      - real GSTN addresses reached via an offramp gateway

- Eメールの利用者とインターネットFAX受信者/ユーザ--出口ランプゲートウェイを通して達した本当の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番目のカテゴリのための機能性として「直接アドレスマッピング」を定義します。

Mimura, et al.               Informational                      [Page 6]

RFC 4160           Internet Fax Gateway Requirements         August 2005

Mimura、他 [6ページ]情報のRFC4160インターネットファックスゲートウェイ要件2005年8月

4.2.1.  Indirect Address Mapping

4.2.1. 間接的なアドレス・マッピング

   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.

入口ランプゲートウェイはGSTNファックス送付デバイスからEメールアドレスに受け取られたアドレス(「間接アドレス番号」と呼ばれる)からの翻訳を可能にするメカニズム(テーブル、ディレクトリルックアップ、または何か同様のものを通した)を写像するローカルアドレスを実装するかもしれません。 ただ一つのEメールアドレスかメール・アドレスのリストがただ一つの間接アドレス番号に対応するかもしれません。

   Here is one mapping example:

ここに、1つのマッピングの例があります:

   (1) An onramp gateway receives the indirect address number "1234"
       from the source GSTN facsimile by DTMF.

(1) 入口ランプゲートウェイは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-仕様」)

            ifax@example.com

ifax@example.com

   "Addr-spec" is defined in Section 3.4.1 of [14].

「Addr-仕様」は[14]についてセクション3.4.1で定義されます。

   If the address mapping lookup fails, an error MUST be reported to the
   originating GSTN fax device.

アドレス・マッピングルックアップが失敗するなら、起因しているGSTNファックスデバイスに誤りを報告しなければなりません。

4.2.2.  Direct Address Mapping

4.2.2. 直接アドレスマッピング

   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送付デバイスSHOULDはDTMFを通して完全な数値送付先アドレスを入口ランプゲートウェイに送ります。 また、間接的なアドレス・マッピングが実装されるなら、直接アドレスマッピングを使用できます。

   An example:

例:

   (1) An onramp gateway receives the destination telephone number
       "441164960348" from the source facsimile by DTMF.

(1) 入口ランプゲートウェイはDTMFでソースファクシミリから目的地電話番号「441164960348」を受け取ります。

            441164960348

441164960348

Mimura, et al.               Informational                      [Page 7]

RFC 4160           Internet Fax Gateway Requirements         August 2005

Mimura、他 [7ページ]情報のRFC4160インターネットファックスゲートウェイ要件2005年8月

   (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) 「ファックス=」は、「ファックス-mbox」アドレス項目を造るために加えられます。

            FAX=+441164960348

ファックスは+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=+441164960348@example.com

ファックス=+ 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].

「グローバルな電話」、「ファックス-mbox」、および「ファックスアドレス」は[7]のセクション2で定義されます。 「Mta-I-ファックス」は[7]のセクション3で定義されます。 「ファックスメール」は[7]のセクション4で定義されます。

4.2.3.  Sender Address Handling

4.2.3. 送付者アドレス取り扱い

   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.

入口ランプゲートウェイSHOULDはGSTNファックス送付者アドレス(例えば発信番号表示で利用可能であるなら)に関して情報を収集して、インターネットファックスの送付者としてそれをコード化します、直接アドレスマッピングを使用して(この.2通のセクション4.2ドキュメントを見てください)。 送付者は完成した使用が入口ランプゲートウェイアドレスであったならSHOULDを扱います、入口ランプゲートウェイに異なったリターンパスを指定する追加情報がない場合。

   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.

入口ランプゲートウェイがそうしないなら、何か送付者アドレス情報、インターネットファックス送付者アドレスSHOULDは「回答がありません」アドレスか適切なデフォルトメールボックスのどちらかに用意ができていましたか?

4.2.4.  Support for Subaddress

4.2.4. Subaddressのサポート

   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.

SHOULDが「副-アドレス」をサポートする入口ランプゲートウェイ。 直接アドレスマッピングの場合では、「副-アドレス」は、[7]で与えるようにT.33[15]仕様を使用することで指定されて、コード化されます。 間接的なアドレス・マッピングの場合では、「副-アドレス」はアドレス変換テーブルの中に含まれるかもしれません。

Mimura, et al.               Informational                      [Page 8]

RFC 4160           Internet Fax Gateway Requirements         August 2005

Mimura、他 [8ページ]情報のRFC4160インターネットファックスゲートウェイ要件2005年8月

4.3.  Relay Function

4.3. リレー機能

   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.

入口ランプゲートウェイSHOULDは目的地ファックス番号を分析することによって目的地出口ランプゲートウェイを選ぶための機能性を提供します。 出口ランプゲートウェイの周りで入口ランプゲートウェイから情報を広げるか、または取得する可能なメソッドは、他の入口ランプゲートウェイによって送られた送付者アドレスのキャッシュされた情報を保つのを含むかもしれません。

4.4.  File Format Conversion

4.4. ファイル・フォーマット変換

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

入口ランプゲートウェイはインターネットファックスのためにGSTNの上のファクシミリからファイル形式TIFF Profile-Sまでファイル形式を変換しなければなりません、[16]で定義されるように。

4.6.  Return Notice Handling

4.6. リターン通知取り扱い

   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.

入口ランプゲートウェイがインターネットファックスの目的地からのリターン通知を受け取って、分析するとき、それには、適切な出口ランプゲートウェイを通してGSTNの上の適当なファクシミリデバイスに配送状態を送る機能性があるかもしれません。 GSTNファックスSHOULDを通して送られた発生している通知は人間読み込み可能な通知情報と元の配送コードの両方を含んでいます。

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

入口ランプゲートウェイがリターン通知の伝達にGSTNファックスサービスに失敗して戻すなら、情報は5月の終わりにログ、および処理に記録されるかもしれません。 補欠として、特定のメソッド(例えばメールメッセージをメールボックスに送ることによって)でゲートウェイシステムの管理者はこの通知について通知されるかもしれません。

5.  Security Considerations

5. セキュリティ問題

   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(「ユーザ承認」)を参照してください。 S/MIMEの代わりに承認サービスを提供するのにOpenPGP[17][25]を使用できます。 入口ランプゲートウェイのための認証についてセクション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を使用できます。 署名しているか暗号化されたメッセージはネットワークに沿って輸送されている間、保護されます。 しかしながら、メッセージがそれ以上インターネットファックスゲートウェイ(入口ランプか出口ランプのどちらか)に達するとき、この種類の保護を適用できません。 ここで、セキュリティはゲートウェイ自体の信じられた操作に依存しなければなりません。 インターネットファックスを送るとき、ゲートウェイにはセキュリティ操作を改良するそれ自身の証明書/キーがあるかもしれませんが、どんなゲートウェイのようにも、それは終わりから終わりへのセキュリティS/MIMEとPGPの両方のパターンを破ります。

   Other security mechanisms, like IPsec [18][19][20][21][2] or TLS [23]
   also do not ensure a secure gateway operation.

また[21][2]かTLS[23]がするIPsec[18][19][20]が安全なゲートウェイ操作を確実にしないような他のセキュリティー対策。

Mimura, et al.               Informational                      [Page 9]

RFC 4160           Internet Fax Gateway Requirements         August 2005

Mimura、他 [9ページ]情報のRFC4160インターネットファックスゲートウェイ要件2005年8月

   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.

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

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]  Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document
        Roadmap", RFC 2411, November 1998.

[2] セイヤーとR.とDoraswamy、N.とR.グレン、「IPセキュリティドキュメント道路地図」、RFC2411、1998年11月。

6.2.  Normative References

6.2. 引用規格

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

[3] 「IPネットワークの上のリアルタイムのGroup3ファクシミリ通信のための手順」、ITU-T Recommendation 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] 豊田、K.、大野、H.、村井、J.、およびD.は飛んで行きます、「ファクシミリの簡単なモードはインターネットメールを使用し」て、RFC3965、2004年12月。

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

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

   [6] "Procedures for document facsimile transmission in the general
        switched telephone network", ITU-T Recommendation T.30, April
        1999.

[6] 「一般的な切り換えられた電話網におけるドキュメントファクシミリ伝送のための手順」、ITU-T Recommendation T.30、1999年4月。

   [7]  Allocchio, C., "Minimal FAX address format in Internet Mail",
        RFC 3192, October 2001.

[7]Allocchio、C.、「インターネットメールにおける最小量のFAXアドレス形式」、RFC3192、2001年10月。

   [8]  Allocchio, C., "GSTN Address Element Extensions in E-mail
        Services", RFC 2846, June 2000.

[8]Allocchio、C.、「メールサービスにおけるGSTNアドレス要素拡張子」、RFC2846、2000年6月。

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

[9]Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、2004年7月。

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

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

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

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

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

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

Mimura, et al.               Informational                     [Page 10]

RFC 4160           Internet Fax Gateway Requirements         August 2005

Mimura、他 [10ページ]情報のRFC4160インターネットファックスゲートウェイ要件2005年8月

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

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

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

[14] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、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] バックリーとR.とヴェナブルとD.とマッキンタイヤとL.とパーソンズ、G.とJ.Rafferty、「インターネットファックスのためのファイル形式」RFC3949(2005年2月)。

   [17] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP
        Message Format", RFC 2440, November 1998.

[17] カラスとJ.とDonnerhackeとL.とフィニー、H.とR.セイヤー、「OpenPGPメッセージ・フォーマット」、RFC2440、1998年11月。

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

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

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

[19] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、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.、フロイド、S.、およびD.黒、「明白な混雑通知のIPへの追加(電子証券取引ネットワーク)」、RFC3168(2001年9月)。

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

[21] パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、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] ブレーク-ウィルソン、S.、ニストロム、M.、Hopwood(D.、ミッケルセン、J.、およびT.ライト)は「層のセキュリティ(TLS)拡大を輸送します」、RFC3546、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.、佐藤、T.、渡辺、K.、およびC.Kanaide、「インターネットのための任意のサービスのためのガイドラインはファックスでゲートウェイを送ります」、RFC4161、2005年8月。

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

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

Mimura, et al.               Informational                     [Page 11]

RFC 4160           Internet Fax Gateway Requirements         August 2005

Mimura、他 [11ページ]情報のRFC4160インターネットファックスゲートウェイ要件2005年8月

Authors' Addresses

作者のアドレス

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

克彦Mimuraトーヨ通信設備CO Ltd.2-1-1Koyato、寒川-machi、神奈川、古座-銃の日本

   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, Japan

Keiichi横山トーヨ通信設備CO Ltd.2-1-1Koyato、寒川-machi、神奈川、古座-銃の日本

   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, Japan

Takahisa佐藤トーヨ通信設備CO Ltd.2-1-1Koyato、寒川-machi、神奈川、古座-銃の日本

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

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

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

知恵Kanaideトーヨ通信設備CO Ltd.2-1-1Koyato、寒川-machi、神奈川、古座-銃の日本

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

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

   Claudio Allocchio
   Consortium GARR
   Viale Palmiro Togliatti 1625
   00155 Roma, Italy

クラウディオ・Allocchio共同体のガー・ビアール・Palmiroトリアッティ1625 00155・ローマ(イタリア)

   Fax: +39 040 3758565
   EMail: Claudio.Allocchio@garr.it

Fax: +39 040 3758565 メール: Claudio.Allocchio@garr.it

Mimura, et al.               Informational                     [Page 12]

RFC 4160           Internet Fax Gateway Requirements         August 2005

Mimura、他 [12ページ]情報のRFC4160インターネットファックスゲートウェイ要件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 13]

Mimura、他 情報[13ページ]