RFC3192 日本語訳

Network Working Group                                       C. Allocchio
Request for Comments: 3192                                    GARR-Italy
Obsoletes: 2304                                             October 2001
Updates: 2846
Category: Standards Track

Allocchioがコメントのために要求するワーキンググループC.をネットワークでつないでください: 3192 ガー-イタリアは以下を時代遅れにします。 2304 2001年10月は以下をアップデートします。 2846年のカテゴリ: 標準化過程

              Minimal FAX address format in Internet Mail

インターネットメールにおける最小量のFAXアドレス形式

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Copyright(C)インターネット協会(2001)。 All rights reserved。

Abstract

要約

   This memo describes a simple method of encoding Global Switched
   Telephone Network (GSTN) addresses of facsimile devices in the
   local-part of Internet email addresses.

このメモはインターネットEメールアドレスの地方の部分でファクシミリデバイスのGlobal Switched Telephone Network(GSTN)アドレスをコード化する簡単なメソッドを説明します。

1. Introduction

1. 序論

   As with all Internet mail addresses, the left-hand-side (local-part)
   of an address generated according to this specification, is not to be
   interpreted except by the MTA that is named on the right-hand-side
   (domain).

すべてのように、メールが扱うインターネット(この仕様通りに作られたアドレスの左側(地方の部分))は正しい手のサイド(ドメイン)で命名されるMTA以外に、解釈されないことです。

   Since the very first e-mail to fax gateway objects appeared, a number
   of different methods to specify a fax address as an e-mail address
   have been used by implementors.  Several objectives for this methods
   have been identified, like to enable an e-mail user to send and
   receive faxes from his/her e-mail interface, to allow some kind of
   "fax over e-mail service" transport (possibly reducing the costs of
   GSTN long distance transmissions) while using the existing e-mail
   infrastructure.

ファックスでゲートウェイオブジェクトを送るまさしくその最初のメールが現れて以来、Eメールアドレスとしてファックスアドレスを指定する多くの異なったメソッドが作成者によって使用されています。 このメソッドのためのいくつかの目的が、特定されて、メールユーザが発信するのを可能にするのが好きであり、既存のメールインフラストラクチャを使用している間、ある種の「メールサービスの上のファックス」輸送(ことによるとGSTN長距離の送信について生産費を切り下げる)を許容するためにその人のメールインタフェースからファックスを受け止めます。

   This memo describes the MINIMAL addressing method and standard
   extensions to encode FAX addresses into e-mail addresses, as required
   in reference [13].  The opposite problem, i.e., to allow a
   traditional numeric-only fax device user to access the e-mail
   transport service, is not discussed here.

このメモは、必要に応じて参照[13]でFAXアドレスをEメールアドレスにコード化するためにMINIMALアドレス指定法と標準の拡大について説明します。 反対の問題、すなわち、伝統的な数値だけファックスデバイスユーザがメールにアクセスするのを許容するのと、サービスを輸送して、ここで議論しません。

Allocchio                   Standards Track                     [Page 1]

RFC 3192      Minimal FAX address format in Internet Mail   October 2001

インターネットメール2001年10月のAllocchio Standards Track[1ページ]RFC3192Minimal FAXアドレス形式

   These IANA forms used to register the standard elements defined here
   are given in the "IANA Considerations" chapter (section 7 of this
   document).

「IANA問題」章(このドキュメントのセクション7)でここで定義された標準の要素を登録するのに使用されるこれらのIANA書式を与えます。

   All implementations supporting FAX over e-mail address format MUST
   support this minimal specification.

Eメールアドレス形式でFAXをサポートするすべての実装がこの最小量の仕様をサポートしなければなりません。

1.1 Terminology and Syntax conventions

1.1 用語とSyntaxコンベンション

   In this document the formal definitions are described using ABNF
   syntax, as defined into [7].  We will also use some of the "CORE
   DEFINITIONS" defined in "APPENDIX A - CORE" of that document.  The
   exact meaning of the capitalized words

本書では公式の定義は、[7]と定義されるようにABNF構文を使用することで説明されます。 また、私たちが中で定義された「コア定義」のいくつかを使用するつもりである、「付録A--、コア、」 そのドキュメントについて。 大文字で書かれた単語の正確な意味

      "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
      "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"

"MUST"、「必須NOT」、「必要であった」“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTであるべきです

   is defined in reference [6].

参照[6]では、定義されます。

   In this document the following new terms are also defined:

また、本書では次の新学期は定義されます:

      I-fax device:
         an I-pstn device type [13] which is able to communicate either
         directly or indirectly with the traditional FAX over GSTN
         service;

I-ファックスデバイス: GSTNサービスの上で直接か間接的に伝統的なFAXとコミュニケートできるI-pstn装置タイプ[13]。

      mta-I-fax:
         the Internet domain name which identifies uniquely an I-fax
         device over the Internet (see also mta-I-pstn in [13]);

mta-I-ファックス: インターネットドメインはインターネットの上で唯一I-ファックスデバイスを特定するものを命名します。(また、[13])でmta-I-pstnを見てください。

      fax-email:
         the complete Internet e-mail address structure which is used to
         transport a FAX address over the Internet e-mail service (see
         also pstn-email in [13]).

ファックスメール: インターネットの上でFAXアドレスを輸送するのに使用される完全なインターネット電子メールアドレス構造はサービスをメールします。(また、[13])でpstn-メールを見てください。

2. Minimal Fax address

2. 最小量のファックスアドレス

   The minimal fax address within e-mail has been defined for
   consistency with reference [13] and it contains two elements: the
   fax-mbox and an optional qualif-type1 element.

メールの中の最小量のファックスアドレスは一貫性のために参照[13]で定義されました、そして、2つの要素を含んでいます: mboxにファックスして、任意のqualif-type1要素。

   More precisely the GSTN minimal address specification requires the
   use of a unique service-selector for each specific application
   (section 2 in [13]).

より正確にGSTNの最小量のアドレス指定はそれぞれの特定のアプリケーションのためのユニークなサービスセレクタを使用に要求します。([13])のセクション2。

   The "service-selector" defined for the fax service is as follows:

ファックスサービスのために定義された「サービスセレクタ」は以下の通りです:

      service-selector = "FAX"

サービスセレクタ=「ファックス」

Allocchio                   Standards Track                     [Page 2]

RFC 3192      Minimal FAX address format in Internet Mail   October 2001

インターネットメール2001年10月のAllocchio Standards Track[2ページ]RFC3192Minimal FAXアドレス形式

   In the syntax for the fax address a qualif-type1 element has been
   defined for support of T.30/T.33 subaddresses (see section 2 of
   [13]).  The use of this element is OPTIONAL, but compliant
   implementations MUST be able to support and correctly interpret it
   when present.  Its definition is as follows:

ファックスアドレスのための構文では、qualif-type1要素はT.30/T.33 subaddressesのサポートのために定義されました。([13])のセクション2を見てください。 この要素の使用がOPTIONALですが、存在しているとき、対応する実装は、それをサポートして、正しく解釈できなければなりません。 定義は以下の通りです:

      qualif-type1 = "/" t33-sep "=" sub-addr

「qualif-type1は」 /と等しく」t33-sepがサブaddrと「等しいです」。

   where

どこ

      t33-sep = "T33S"

t33-sepは「T33S」と等しいです。

      sub-addr = 1*( DIGIT )

サブaddr=1*(ケタ)

   Thus, the minimal specification of a fax in e-mail address is:

したがって、Eメールアドレスのファックスの最小量の仕様は以下の通りです。

      fax-address = fax-mbox [ "/T33S=" sub-addr ]

ファックスアドレスはファックス-mboxと等しいです。[「/T33S=」サブaddr]

      fax-mbox = "FAX=" global-phone

ファックス-mboxは「ファックス=」とグローバルな電話であることで等しいです。

   Notes:

注意:

      For the case of a single subaddress, only numbers are allowed in
      <sub-addr> which is consistent with T.30, T.33, and this document.
      While T.30 and T.33 use SPACE to pad its field, padding isn't
      necessary in the <sub-addr> field defined by this document.

単一の「副-アドレス」に関するケースにおいて、数だけがT.30、T.33、およびこのドキュメントと一致した<サブaddrの>に許容されています。 T.30とT.33は分野を水増しするのにSPACEを使用しますが、詰め物はこのドキュメントによって定義された<のサブaddrの>分野で必要ではありません。

      For the case of multiple subaddresses, T.33 specifies the "#"
      character be used to specify multiple subaddreses.  However, only
      digits are permitted in the <sub-addr> field defined by this
      document.  Refer to section 4.1 in case multiple <sub-addr> per
      per <fax-mbox> need to be specified.

複数の「副-アドレス」に関するケースとして、T.33は「#」キャラクタを指定します。複数のsubaddresesを指定するのが使用されてください。 しかしながら、ケタだけがこのドキュメントによって定義された<のサブaddrの>分野で受入れられます。 指定されるべき<ファックスmboxな>の必要性単位でセクションを4.1が複数の<のサブaddrの>を中にケースに入れる単位参照してください。

   The Minimal supported syntax for global-phone (as described in
   section 2.1 of reference [13]) is:

Minimalはグローバルな電話のために構文をサポートしました。(セクション2.1の参照で説明されるように、[13])は以下の通りです。

   global-phone = "+" 1*( DIGIT / written-sep )

グローバルな電話は「+」 1*と等しいです。(書かれたDIGIT/sep)

   written-sep = ( "-" / "." )

書かれたsep=( "-" / "." )

   Refer to section 2.1 in [13] for other important considerations about
   the global-phone element.

グローバルな電話要素に関する他の重要な問題のための[13]のセクション2.1を参照してください。

2.2 Some examples of a minimal "fax-address"

2.2 最小量の「ファックスアドレス」に関するいくつかの例

   Some examples of minimal fax-address follows:

最小量のファックスアドレスに関するいくつかの例が従います:

Allocchio                   Standards Track                     [Page 3]

RFC 3192      Minimal FAX address format in Internet Mail   October 2001

インターネットメール2001年10月のAllocchio Standards Track[3ページ]RFC3192Minimal FAXアドレス形式

      FAX=+3940226338

ファックスは+3940226338と等しいです。

      FAX=+12027653000/T33S=1387

ファックスは+12027653000/T33S=1387と等しいです。

      FAX=+33-1-88335215

ファックスは+33-1-88335215と等しいです。

   Note:

以下に注意してください。

      the examples shown are just for illustration purposes.

示された例はまさしくイラスト目的のためのものです。

3. The e-mail address of the I-fax device: mta-I-fax

3. I-ファックスデバイスのEメールアドレス: mta-I-ファックス

   An "I-fax device" has, among its characteristics, a unique Internet
   domain name which identifies it on the Internet.  Within Internet
   mail, this is the Right Hand Side (RHS) part of the address, i.e.,
   the part on the right of the "@" sign.  For purposes of this document
   we will call this "mta-I-fax"

「I-ファックスデバイス」は特性の中にインターネットでそれを特定するユニークなインターネットドメイン名を持っています。 インターネット・メールの中では、これはアドレス(すなわち、"@"サインの右の部分)のRight Hand Side(RHS)部分です。 このドキュメントの目的のために、私たちは、これを「mta-I-ファックス」と呼ぶつもりです。

      mta-I-fax = domain

mta-I-ファックスはドメインと等しいです。

   For "domain" strings used in SMTP transmissions, the string MUST
   conform to the requirements of that standards <domain> specifications
   [1], [3].  For "domain" strings used in message content headers, the
   string MUST conform to the requirements of the relevant standards
   [2], [3].

SMTPトランスミッションに使用される「ドメイン」ストリングのために、ストリングはドメイン>仕様[1]([3])をその規格<の要件に従わせなければなりません。 メッセージ内容ヘッダーで使用される「ドメイン」ストリングのために、ストリングは関連規格[2]([3])の要件に一致しなければなりません。

   Note:

以下に注意してください。

      the use of "domain names" or "domain literals" is permitted in
      addresses in both the SMTP envelope and message header fields.

「ドメイン名」か「ドメインリテラル」の使用は両方のSMTP封筒とメッセージヘッダーフィールドにおけるアドレスで受入れられます。

4. The fax-email

4. ファックスメール

   The complete structure used to transfer a minimal FAX address over
   the Internet e-mail transport system is called "fax-email".  This
   object is a an e-mail address which conforms to [2] and [3]
   "addr-spec" syntax, with structure refinements which allows the FAX
   number to be identified.

最小量のFAXアドレスをインターネット電子メール輸送システムの上に移すのに使用される完全な構造は「ファックスメール」と呼ばれます。 このオブジェクトは[2]に従うEメールアドレスと[3]「addr-仕様」構文です、FAX番号が特定されるのを許容する構造気品で。

   fax-email = ["""] ["/"] fax-address ["/"] ["""] "@" mta-I-fax

ファックスメールが等しい、[「「「]、[「/」]ファックスアドレス[「/」]、[「「「]、「@」 mta-I-ファックス」

   Implementors' note:

作成者の注意:

      The optional "/" characters can result from translations from
      other transport gateways (such as some X.400 gateways) which have
      included the "/" as an optional element.  Implementations MUST
      accept the optional slashes but SHOULD NOT generate them.
      Gateways are allowed to strip them off when converting to Internet

含まれていて、」 キャラクタが翻訳から別に結果になることができる「任意」/がそうしたゲートウェイ(いくつかのX.400ゲートウェイなどの)を輸送する、」 /、」 随意的な要素として。 実装は任意のスラッシュを受け入れなければなりませんが、SHOULD NOTはそれらを生成します。 インターネットに変えるとき、ゲートウェイはそれらを全部はぎ取ることができます。

Allocchio                   Standards Track                     [Page 4]

RFC 3192      Minimal FAX address format in Internet Mail   October 2001

インターネットメール2001年10月のAllocchio Standards Track[4ページ]RFC3192Minimal FAXアドレス形式

      mail addressing.  The relevant standard [2], [3] define exactly
      when the optional "quotes" characters surrounding the entire local
      part (i.e., the part on the left of the "@" character into the
      fax-email) MUST be added.

アドレシングを郵送してください。 関連規格[2]、[3]は、ちょうどいつ全体の地方の部分(すなわち、ファックスメールへの"@"キャラクタの左の部分)の任意の「引用文」キャラクタ周辺を加えなければならないかを定義します。

4.1 Multiple subaddresses

4.1 複数の「副-アドレス」

   There are some instances in GSTN applications where multiple
   subaddresses are used: T.33 subaddresses in fax service are one of
   these cases.  In e-mail practice a separate and unique e-mail address
   is always used for each recipient; as such, if multiple T.33
   subaddresses are present, the use of multiple "fax-email" elements is
   REQUIRED.

GSTNアプリケーションにはいくつかのインスタンスが複数の「副-アドレス」が使用されているところにあります: ファックスサービスのT.33 subaddressesはこれらのケースの1つです。 メール習慣では、別々の、そして、ユニークなEメールアドレスは各受取人にいつも使用されます。 そういうものとして、複数のT.33 subaddressesが存在しているなら、複数の「ファックスメール」要素の使用はREQUIREDです。

   Implementors' note:

作成者の注意:

      The UA MAY accept multiple subaddress elements for the same
      global-phone, but it MUST generate multiple "fax-mbox" elements
      when submitting the message to the MTA.

UA MAYは同じグローバルな電話のために複数の「副-アドレス」要素を受け入れますが、MTAにメッセージを提出するとき、それは複数の「ファックス-mbox」要素を生成しなければなりません。

4.2 Some examples of minimal "fax-email"

4.2 最小量の「ファックスメール」に関するいくつかの例

      Some examples of minimal fax-email addresses follows:

最小量のファックスEメールアドレスに関するいくつかの例が従います:

      FAX=+3940226338@faxworld.org

ファックス=+ 3940226338@faxworld.org

      FAX=+12027653000/T33S=1387@faxworld.org

ファックスは+12027653000/T33S= 1387@faxworld.org と等しいです。

      /FAX=+33-1-88335215/@faxworld.org

/ファックス=+ 33-1-88335215/@faxworld.org

   Note:

以下に注意してください。

      the examples shown are just for illustration purposes.

示された例はまさしくイラスト目的のためのものです。

5. Conclusion

5. 結論

   This proposal creates a minimal standard encoding for FAX addresses
   within the global e-mail transport system.  The proposal is
   consistent with existing e-mail standards.

この提案はFAXのためにグローバルなメール輸送システムの中でアドレスをコード化する最小量の規格を作成します。 提案は既存のメール規格と一致しています。

6. Security Considerations

6. セキュリティ問題

   This document specifies a means by which FAX addresses can be encoded
   into e-mail addresses.  Since e-mail routing is determined by Domain
   Name System (DNS) data, a successful attack to DNS could disseminate
   tampered information, which causes e-mail messages to be diverted via
   some MTA or Gateway where the security of the software has been
   compromised.

このドキュメントはFAXアドレスをEメールアドレスにコード化できる手段を指定します。 メールルーティングがドメインネームシステム(DNS)データで決定するので、DNSに対するうまくいっている攻撃はいじられた情報を広めるかもしれません。(それは、ソフトウェアのセキュリティが感染されたいくらかのMTAかゲートウェイを通して紛らされるべきメールメッセージを引き起こします)。

Allocchio                   Standards Track                     [Page 5]

RFC 3192      Minimal FAX address format in Internet Mail   October 2001

インターネットメール2001年10月のAllocchio Standards Track[5ページ]RFC3192Minimal FAXアドレス形式

   There are several means by which an attacker might be able to deliver
   incorrect mail routing information to a client.  These include: (a)
   compromise of a DNS server, (b) generating a counterfeit response to
   a client's DNS query, (c) returning incorrect "additional
   information" in response to an unrelated query.  Clients SHOULD
   ensure that mail routing is based only on authoritative answers.
   Once DNS Security mechanisms [5] become more widely deployed, clients
   SHOULD employ those mechanisms to verify the authenticity and
   integrity of mail routing records.

攻撃者が不正確なメールルーティング情報をクライアントに提供できるかもしれないいくつかの手段があります。 これらは: (a) DNSサーバ、クライアントのDNS質問(関係ない質問に対応して不正確な「追加情報」を返す(c))へのにせの応答を生成する(b)の感染。 クライアントSHOULDは、メールルーティングが正式の答えだけに基づいているのを確実にします。 DNS Securityメカニズム[5]がいったん広くより配布されるようになると、クライアントSHOULDは、メールルーティング記録の信憑性と保全について確かめるのにそれらのメカニズムを使います。

7. IANA Considerations

7. IANA問題

   The IANA registration forms for "FAX" service-selector and "T33S"
   qualif-type1 elements are defined here.  These forms update the
   previous registration forms defined in [15].

「ファックス」サービスセレクタと「T33S」qualif-type1要素のためのIANA登録用紙はここで定義されます。 これらのフォームは[15]で定義された前の登録用紙をアップデートします。

7.1 IANA Registration form for updated value of GSTN
    address service-selector "FAX"

7.1 IANA RegistrationはGSTNアドレスサービスセレクタ「ファックス」のアップデートされた値のために形成します。

   To: IANA@iana.org
   Subject: Registration of updated values for the GSTN address
   service-selector specifier "FAX"

To: IANA@iana.org Subject: GSTNアドレスサービスセレクタ特許説明書の作成書「ファックス」のためのアップデートされた値の登録

   service-selector name:

サービスセレクタ名:

      FAX

ファックス

   Description of Use:

使用の記述:

      FAX - specify that the GSTN address refers either to an
      Internet Fax device, or an onramp/offramp Fax gateway.

FAX--GSTNアドレスがインターネットファックスデバイス、または入口ランプ/出口ランプファックスゲートウェイについて言及すると指定してください。

      For a complete description refer to RFC 3192 and RFC 3191.

完全な記述について、RFC3192とRFC3191を参照してください。

   Security Considerations:

セキュリティ問題:

      See the Security Consideration section of RFC 3192.

RFC3192のSecurity Consideration部を見てください。

   Person & email address to contact for further information:

詳細のために連絡する人とEメールアドレス:

   Claudio Allocchio
   INFN-GARR
   c/o Sincrotrone Trieste
   SS 14 Km 163.5 Basovizza
   I 34012 Trieste
   Italy

クラウディオAllocchio INFN-ガー気付SincrotroneトリエステSS14km163.5Basovizza I34012トリエステイタリア

Allocchio                   Standards Track                     [Page 6]

RFC 3192      Minimal FAX address format in Internet Mail   October 2001

インターネットメール2001年10月のAllocchio Standards Track[6ページ]RFC3192Minimal FAXアドレス形式

   RFC2822: Claudio.Allocchio@garr.it
   X.400:   C=it;A=garr;P=garr;S=Allocchio;G=Claudio;
   Phone:   +39 040 3758523
   Fax:     +39 040 3758565

RFC2822: Claudio.Allocchio@garr.it X.400: C=それ; A=garr; P=garr; S=Allocchio; Gはクラウディオと等しいです。 以下に電話をしてください。 +39 040 3758523Fax: +39 040 3758565

7.2 IANA Registration form for updated value of GSTN
    address qualit-type1 keyword "T33S" and value

7.2 IANA RegistrationはGSTNアドレスqualit-type1キーワード「T33S」と価値のアップデートされた値のために形成します。

   To: IANA@iana.org
   Subject: Registration of updated values for the GSTN address
   qualif-type1 element "T33S"

To: IANA@iana.org Subject: GSTNアドレスqualif-type1要素「T33S」のためのアップデートされた値の登録

   qualif-type1 "keyword" name:

qualif-type1「キーワード」名:

      T33S

T33S

   qualif-type1 "value" ABNF definition:

qualif-type1「値」ABNF定義:

      sub-addr = 1*( DIGIT )

サブaddr=1*(ケタ)

   Description of Use:

使用の記述:

      T33S is used to specify the numeric only optional fax sub-address
      element described in "ITU T.33 - Facsimile routing utilizing the
      subaddress; recommendation T.33 (July, 1996)".  Further detailed
      description is available in RFC 3192.

T33Sは「ITU T.33--「副-アドレス」を利用するルーティングを電送するところ」で説明された唯一の任意のファックスサブアドレス要素に数値を指定するのに使用されます。 「推薦T.33(1996年7月)。」 さらなる詳述はRFC3192で利用可能です。

   Use Restriction:

制限を使用してください:

      The use of "T33S" is restricted to "FAX" service-selector, is it
      has no meaning outside the fax service.

「T33S」の使用は、サービスセレクタを「ファックスする」ために制限されて、ファックスサービスの外に意味でないのを持っているということです。

   Security Considerations:

セキュリティ問題:

      See the Security Consideration section of RFC 3192.

RFC3192のSecurity Consideration部を見てください。

   Person & email address to contact for further information:

詳細のために連絡する人とEメールアドレス:

      Claudio Allocchio
      INFN-GARR
      c/o Sincrotrone Trieste
      SS 14 Km 163.5 Basovizza
      I 34012 Trieste
      Italy

クラウディオAllocchio INFN-ガー気付SincrotroneトリエステSS14km163.5Basovizza I34012トリエステイタリア

Allocchio                   Standards Track                     [Page 7]

RFC 3192      Minimal FAX address format in Internet Mail   October 2001

インターネットメール2001年10月のAllocchio Standards Track[7ページ]RFC3192Minimal FAXアドレス形式

      RFC2822: Claudio.Allocchio@garr.it
      X.400:   C=it;A=garr;P=garr;S=Allocchio;G=Claudio;
      Phone:   +39 040 3758523
      Fax:     +39 040 3758565

RFC2822: Claudio.Allocchio@garr.it X.400: C=それ; A=garr; P=garr; S=Allocchio; Gはクラウディオと等しいです。 以下に電話をしてください。 +39 040 3758523Fax: +39 040 3758565

8. Changes since RFC 2304 specification

8. RFC2304仕様以来の変化

   Although there are no major or technical changes from RFC 2304
   specification, this section briefly describes where updates and
   clarifications were introduced:

2304年のRFC仕様からのどんな主要であるか技術的な変化もありませんが、このセクションは、アップデートと明確化がどこで導入されたかを簡潔に説明します:

   -  considering the case that telephony systems do not conform any
      more to the "single/few" Public Operator paradigm, the old
      definition "PSTN - Public Switched Telephone Network" was changed
      into the more adequate "GSTN - Global Switched Telephone Network"
      one.  However, in order to remain consistent with the previous
      specification, the ABNF variables names were not changed.

- 電話技術システムがもう「単一であるかわずかな」Public Operatorパラダイム、古い定義に従わせないケースを考える場合「PSTN--公衆は電話網を切り換えた」、 より適切に変えた、「GSTN--グローバルな切り換えられた電話は」 1つをネットワークでつなぎます。 しかしながら、前の仕様と一致していたままで残るために、ABNF変数名は変えられませんでした。

   -  section 7 "IANA Considerations" and the IANA registration forms
      for the "FAX" "service-selector" and for the "T33S" "qualif-type1"
      elements were added;

- 「IANA問題」というセクション7とIANA登録は「ファックス」「サービスセレクタ」のために形成されます、そして、「T33S」に関して、「qualif-type1"要素は加えられました」。

   -  an explicit list of "new terms" with explanations was added to
      section 1.1;

- 説明がある「新学期」の明白なリストはセクション1.1に追加されました。

   -  the case when multiple T.33 subaddresses are present was described
      more explicitly in order to clarify how to handle them (section
      4.1);

- 複数のT.33 subaddressesが存在しているとき、ケースは彼ら(セクション4.1)を扱う方法をはっきりさせるために、より明らかに説明されました。

   -  in section 3 the language describing "mta-I-fax" was updated to
      better describe its relationship with an Internet Mail address;

- セクション3では、インターネットメールアドレスとの関係について、よりよく説明するために「mta-I-ファックス」について説明する言語をアップデートしました。

   -  in section 4., the quoting rules of the "fax-address" and their
      practical use was made explicit both in the definition of "fax-
      email" and in the Implementors' note;

- セクション4.では、「ファックスアドレス」の引用規則とそれらの実用を「ファックスメール」の定義とImplementorsの注意で明白にしました。

   -  the Author's Address was updated;

- AuthorのAddressをアップデートしました。

   -  the References list was updates to substitute ITU E.164 (1991)
      with ITU E.164 (1997).

- ReferencesリストはITU E.164(1997)と共にITU E.164(1991)を代入する最新版でした。

Allocchio                   Standards Track                     [Page 8]

RFC 3192      Minimal FAX address format in Internet Mail   October 2001

インターネットメール2001年10月のAllocchio Standards Track[8ページ]RFC3192Minimal FAXアドレス形式

9. Author's Address

9. 作者のアドレス

   Claudio Allocchio
   INFN-GARR
   c/o Sincrotrone Trieste
   SS 14 Km 163.5 Basovizza
   I 34012 Trieste
   Italy

クラウディオAllocchio INFN-ガー気付SincrotroneトリエステSS14km163.5Basovizza I34012トリエステイタリア

   RFC2822: Claudio.Allocchio@garr.it
   X.400:   C=it;A=garr;P=garr;S=Allocchio;G=Claudio;
   Phone:   +39 040 3758523
   Fax:     +39 040 3758565

RFC2822: Claudio.Allocchio@garr.it X.400: C=それ; A=garr; P=garr; S=Allocchio; Gはクラウディオと等しいです。 以下に電話をしてください。 +39 040 3758523Fax: +39 040 3758565

10. References

10. 参照

   [1]  Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
        August 1982.

[1] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。

   [2]  Crocker, D., "Standard for the Format of ARPA Internet Text
        Messages", STD 11, RFC 822, August 1982.

[2] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。

   [3]  Braden, R., "Requirements for Internet hosts - application and
        support", STD 3, RFC 1123, October 1989.

[3] ブレーデンと、R.と、「インターネット・ホスト--アプリケーションのための要件とサポート」、STD3、RFC1123、10月1989日

   [4]  Malamud, C. and M. Rose, "Principles of Operation for the
        TPC.INT Subdomain: Remote Printing -- Technical Procedures", RFC
        1528, October 1993.

[4] マラマッド、C.、およびM.が上昇した、「TPC.INTサブドメインのための操作のプリンシプルズ:」 「リモートである、印刷--技術的な手順、」、RFC1528、10月1993日

   [5]  Eastlake, D. and C. Kaufman, "Domain Name System Security
        Extensions", RFC 2065, January 1997.

[5] イーストレークとD.とC.コーフマン、「ドメインネームシステムセキュリティ拡大」、RFC2065、1997年1月。

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

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

   [7]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications", RFC 2234, November 1997.

[7] クロッカーとD.とP.Overell、「構文仕様のための増大しているBNF」、RFC2234、1997年11月。

   [8]  ITU F.401 - Message Handling Services: Naming and Addressing for
        Public Message Handling Service; recommendation F.401 (August
        1992).

[8]ITU F.401--メッセージ通信処理サービス: 命名と公共のメッセージハンドリングのためにサービスを扱います。 推薦F.401(1992年8月)。

   [9]  ITU F.423 - Message Handling Services: Intercommunication
        Between the Interpersonal Messaging Service and the Telefax
        Service; recommendation F.423 (August 1992).

[9]ITU F.423--メッセージ通信処理サービス: 個人間のメッセージサービスとテレファックスサービスの間の相互通信。 推薦F.423(1992年8月)。

   [10] ITU E.164 - The International Public Telecommunication Numbering
        Plan E.164/I.331 (May 1997).

[10]ITU E.164--国際公共の電気通信付番プランE.164/I.331(1997年5月)。

Allocchio                   Standards Track                     [Page 9]

RFC 3192      Minimal FAX address format in Internet Mail   October 2001

インターネットメール2001年10月のAllocchio Standards Track[9ページ]RFC3192Minimal FAXアドレス形式

   [11] ITU T.33 - Facsimile routing utilizing the subaddress;
        recommendation T.33 (July 1996).

[11]ITU T.33--「副-アドレス」を利用するルーティングを電送してください。 推薦T.33(1996年7月)。

   [12] ETSI I-ETS 300,380 - Universal Personal Telecommunication (UPT):
        Access Devices Dual Tone Multi Frequency (DTMF) sender for
        acoustical coupling to the microphone of a handset telephone
        (March 1995).

[12]ETSI I-ETS300,380--普遍的な個人的な電気通信(UPT): 音響のカップリングのために受話器電話(1995年3月)のマイクロホンにDevices Dual利根Multi Frequency(DTMF)送付者にアクセスしてください。

   [13] Allocchio, C., "Minimal GSTN address format in Internet Mail",
        RFC 3191, October 2001.

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

   [14] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
        between X.400 and RFC 822/MIME", RFC 2156, January 1998.

[14]Kille、S.、「ミキサー(パントマイムインターネットX.400はリレーを機能アップしました):」 「X.400とRFC822/の間でMIMEを写像します」、RFC2156、1998年1月。

   [15] Allocchio, C., "GSTN address element extensions in e-mail
        services", RFC 2846, June 2000.

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

Allocchio                   Standards Track                    [Page 10]

RFC 3192      Minimal FAX address format in Internet Mail   October 2001

インターネットメール2001年10月のAllocchio Standards Track[10ページ]RFC3192Minimal FAXアドレス形式

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Copyright(C)インターネット協会(2001)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Allocchio                   Standards Track                    [Page 11]

Allocchio標準化過程[11ページ]