RFC3191 日本語訳
3191 Minimal GSTN address format in Internet Mail. C. Allocchio. October 2001. (Format: TXT=24235 bytes) (Obsoletes RFC2303) (Updates RFC2846) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Allocchio Request for Comments: 3191 GARR-Italy Obsoletes: 2303 October 2001 Updates: 2846 Category: Standards Track
Allocchioがコメントのために要求するワーキンググループC.をネットワークでつないでください: 3191 ガー-イタリアは以下を時代遅れにします。 2303 2001年10月は以下をアップデートします。 2846年のカテゴリ: 標準化過程
Minimal GSTN address format in Internet Mail
インターネットメールにおける最小量のGSTNアドレス形式
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 (commonly called "telephone numbers") in the local-part of Internet email addresses, along with an extension mechanism to allow encoding of additional standard attributes needed for email gateways to GSTN-based services.
このメモはGSTNベースのサービスへのメールゲートウェイに必要である追加標準の属性がコード化されるのを許容する拡張機能に伴うインターネット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 an MTA that handles messages for the domain given in the right-hand-side.
与えられたドメインへのメッセージを扱うMTA以外に、すべてで解釈されないように、メールが扱うインターネット(この仕様通りに作られたアドレスの左側(地方の部分))がことである右の手では、面があってください。
Since the very first e-mail to GSTN services gateway appeared, a number of different methods to specify a GSTN 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 access GSTN services from his/her e-mail interface, to allow some kind of "GSTN over e-mail service" transport (possibly reducing the costs of GSTN long distance transmissions) while using the existing e-mail infrastructure.
GSTNサービスゲートウェイへのまさしくその最初のメールが現れて以来、EメールアドレスとしてGSTNアドレスを指定する多くの異なったメソッドが作成者によって使用されています。 その人のメールからのサービスがメールユーザがGSTNにアクセスするのを可能にするために連結するようにこのメソッドのためのいくつかの目的が、既存のメールインフラストラクチャを使用している間、ある種の「メールサービスの上のGSTN」輸送(ことによるとGSTN長距離の送信について生産費を切り下げる)を許容するために特定されました。
Allocchio Standards Track [Page 1] RFC 3191 Minimal GSTN address format in Internet Mail October 2001
インターネットメール2001年10月のAllocchio Standards Track[1ページ]RFC3191Minimal GSTNアドレス形式
This memo describes the MINIMAL addressing method to encode GSTN addresses into e-mail addresses and the standard extension mechanism to allow definition of further standard elements. The opposite problem, i.e., to allow a traditional numeric-only GSTN device user to access the e-mail transport service, is not discussed here.
このメモは、さらなる標準の要素の定義を許すためにGSTNアドレスをEメールアドレスにコード化するMINIMALアドレス指定法と標準の拡張機能について説明します。 反対の問題、すなわち、伝統的な数値だけGSTNデバイスユーザがメールにアクセスするのを許容するのと、サービスを輸送して、ここで議論しません。
The IANA registration templates which MUST be used to register any standard element defined according to this specification are given in the "IANA Considerations" chapter (section 7 of this document).
「IANA問題」章(このドキュメントのセクション7)でこの仕様通りに定義されたどんな標準の要素も登録するのに使用しなければならないIANA登録テンプレートを与えます。
All implementations supporting this GSTN over e-mail service MUST support as a minimum the specification described in this document. The generic complex case of converting the entirety of GTSN addressing into e-mail is out of scope in this minimal specification.
メールサービスの上でこのGSTNをサポートするすべての実装が最小限として本書では説明された仕様をサポートしなければなりません。 GTSNアドレシングの全体をメールに変換するジェネリックの複雑なケースがこの最小量の仕様に範囲の外にあります。
1.1 Terminology and Syntax conventions
1.1 用語とSyntaxコンベンション
In this document the formal definitions are described using ABNF syntax, as defined into [7]. This memo also uses 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-pstn device:
a device which has an Internet domain name and it is able to
communicate either directly or indirectly with the GSTN
network;
I-pstnデバイス: インターネットドメイン名とそれを持っているデバイスは直接か間接的にGSTNネットワークとコミュニケートできます。
mta-I-pstn:
the Internet domain name which identifies uniquely an I-pstn
device over the Internet;
mta-I-pstn: インターネットの上で唯一I-pstnデバイスを特定するインターネットドメイン名。
pstn-email:
the complete Internet e-mail address structure which is used to
transport a GSTN address over the Internet e-mail service.
pstn-メール: インターネット電子メールサービスの上でGSTNアドレスを輸送するのに使用される完全なインターネット電子メールアドレス構造。
2. Minimal GSTN address
2. 最小量のGSTNアドレス
The minimal specification of a GSTN address within an e-mail address is as follows:
Eメールアドレスの中のGSTNアドレスの最小量の仕様は以下の通りです:
Allocchio Standards Track [Page 2] RFC 3191 Minimal GSTN address format in Internet Mail October 2001
インターネットメール2001年10月のAllocchio Standards Track[2ページ]RFC3191Minimal GSTNアドレス形式
pstn-address = pstn-mbox [ qualif-type1 ]
pstn-アドレスはpstn-mboxと等しいです。[qualif-type1]
pstn-mbox = service-selector "=" global-phone
サービスpstn-mbox=セレクタはグローバルな電話と「等しいです」。
service-selector = 1*( DIGIT / ALPHA / "-" )
; note that SP (space) is not allowed in
; service-selector.
; service-selector MUST be handled as a case
; INSENSITIVE string by implementations.
サービスセレクタ=1*(DIGIT/アルファー/「-」)。 そのSP(スペース)が許容されていないことに注意してください。 サービスセレクタ。 ; ケースとしてサービスセレクタを扱わなければなりません。 実装によるINSENSITIVEストリング。
Other specifications adopting the "pstn-address" definition MUST define and register with IANA a unique case insensitive "service-selector" element to identify the specific messaging service involved.
「pstn-アドレス」定義を採用する他の仕様は、サービスがかかわった特定のメッセージングを特定するためにユニークな大文字と小文字を区別しない「サービスセレクタ」要素にIANAを定義して、ともに記名しなければなりません。
These specifications and registrations MUST also define which minimal "qualif-type1" extensions, if any, MUST be supported for the specified messaging service.
また、これらの仕様と登録証明書は最小量でどれを定義しなければならないか。「指定されたメッセージングサービスのためにもしあればqualif-type1"拡張子をサポートしなければなりません」。
Implementations confirming to this minimal requirements specification are allowed to ignore any other non-minimal extensions address element which is present in the "pstn-address". However, conforming implementations MUST preserve all "qualif-type1" address elements they receive.
最小量の要件仕様がいかなる他の非最小量の拡大も無視できるとこれに確認する実装が「pstn-アドレス」に存在している要素を扱います。 しかしながら、実装を従わせると、すべての「彼らが受け取るqualif-type1"アドレス要素」が保存されなければなりません。
The generic "qualif-type1" element is defined as:
ジェネリック、「qualif-type1"要素は以下と定義されます」。
qualif-type1 = "/" keyword "=" string
「qualif-type1は」 /と等しい」というキーワード「=」ストリング
keyword = 1*( DIGIT / ALPHA / "-" )
; note that SP (space) is not allowed in keyword
キーワードは1*(DIGIT/アルファー/「-」)と等しいです。 SP(スペース)がキーワードに許容されていないことに注意してください。
string = PCHAR
; note that printable characters are %x20-7E
=PCHARを結んでください。 印刷可能なキャラクタがx20-7E%であることに注意してください。
As such, all "pstn-address" extension elements MUST be defined in the "qualif-type1" form at the time of registration with IANA.
そういうものとして、「IANAとの登録時点のqualif-type1"フォーム」ですべての「pstn-アドレス」拡大要素を定義しなければなりません。
2.1 Minimal "global-phone" definition
2.1 最小量の「グローバルな電話」定義
The purpose of global-phone element is to represent standard E.164 numeric addresses [10] within a syntax for electronic mail addressing that is compliant with standard e-mail specifications given in [1] and [2].
グローバルな電話要素の目的は[1]と[2]で標準のメール仕様を与えていて対応である電子メールアドレシングのために構文の中に標準のE.164数値アドレス[10]を表すことです。
Allocchio Standards Track [Page 3] RFC 3191 Minimal GSTN address format in Internet Mail October 2001
インターネットメール2001年10月のAllocchio Standards Track[3ページ]RFC3191Minimal GSTNアドレス形式
The minimal supported syntax for global-phone element is as follows:
グローバルな電話要素のための最小量のサポートしている構文は以下の通りです:
global-phone = "+" 1*( DIGIT / written-sep )
グローバルな電話は「+」 1*と等しいです。(書かれたDIGIT/sep)
written-sep = ( "-" / "." )
書かれたsep=( "-" / "." )
The use of other dialing schemes for GSTN numbers (like private numbering plans or local dialing conventions) is also allowed. However, this does not preclude nor remove the mandatory requirement for support to the "global-phone" syntax within the minimal GSTN address format.
また、他のダイヤルする体系のGSTN番号(個人的な付番プランや地方のダイヤルするコンベンションのような)の使用は許されています。 しかしながら、これは、最小量のGSTNアドレス形式の中で「グローバルな電話」構文にサポートのための義務的な要件を排除して、取り除きません。
Any other dialing schemes MUST NOT use the leading "+" defined here between the "=" sign and the dialing string. The "+" sign is strictly reserved for the standard "global-phone" syntax.
体系にダイヤルするいかなる他のも「=」サインとダイヤルするストリングの間でここで定義された主な「+」を使用してはいけません。 「+」サインは標準の「グローバルな電話」構文のために厳密に控え目です。
Note:
以下に注意してください。
The specification of alternate dialing schemas is out of scope for
this minimal specification.
この最小量の仕様のための範囲の外にschemasにダイヤルする補欠の仕様があります。
This document also permits the use of written-sep elements in order to improve human readability of GSTN e-mail addresses. The written-sep are elements which can be placed between dial elements such as digits etc.
また、このドキュメントは、GSTN Eメールアドレスの人間の読み易さを改良するために書かれたsep要素の使用を可能にします。 書かれたsepはケタなどのダイヤル要素の間に置くことができる要素です。
Implementors' note:
作成者の注意:
Use of the written-sep elements is allowed, but not recommended
for transmission. Any occurrences of written-sep elements in a
pstn-mbox MUST be ignored by all conformant implementations.
書かれたsep要素の使用は、許容されていますが、トランスミッションのために推薦されません。 すべてのconformant実装でpstn-mboxでの書かれたsep要素のどんな発生も無視しなければなりません。
2.2 The minimal "pstn-address" examples
2.2 最小量の「pstn-アドレス」の例
Some examples of minimal pstn-address are:
最小量のpstn-アドレスに関するいくつかの例は以下の通りです。
VOICE=+3940226338
声は+3940226338と等しいです。
FAX=+12027653000/T33S=6377
ファックスは+12027653000/T33S=6377と等しいです。
SMS=+33-1-88335215
SMSは+33-1-88335215と等しいです。
Note:
以下に注意してください。
these examples are given as illustrations only; they do not
necessarily represent valid pstn-addresses.
これらの例はイラストだけとして出されます。 彼らは必ず有効なpstn-アドレスを表すというわけではありません。
Allocchio Standards Track [Page 4] RFC 3191 Minimal GSTN address format in Internet Mail October 2001
インターネットメール2001年10月のAllocchio Standards Track[4ページ]RFC3191Minimal GSTNアドレス形式
3. The e-mail address of the I-pstn device: mta-I-pstn
3. I-pstnデバイスのEメールアドレス: mta-I-pstn
An "I-pstn 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-pstn"
「I-pstnデバイス」は特性の中にインターネットでそれを特定するユニークなインターネットドメイン名を持っています。 インターネット・メールの中では、これはアドレス(すなわち、"@"サインの右の部分)のRight Hand Side(RHS)部分です。 このドキュメントの目的のために、私たちは、この"mta-I-pstn"と呼ぶつもりです。
mta-I-pstn = domain
mta-I-pstnはドメインと等しいです。
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 pstn-email
4. pstn-メール
The complete structure used to transfer a minimal GSTN address over the Internet e-mail transport system is called "pstn-email". This object is a an e-mail address which conforms to [2] and [3] "addr-spec" syntax, with structure refinements which allows the GSTN number to be identified.
最小量のGSTNアドレスをインターネット電子メール輸送システムの上に移すのに使用される完全な構造は「pstn-メール」と呼ばれます。 このオブジェクトは[2]に従うEメールアドレスと[3]「addr-仕様」構文です、GSTN番号が特定されるのを許容する構造気品で。
pstn-email = ["""] ["/"] pstn-address ["/"] ["""] "@" mta-I-pstn
pstn-メールが等しい、[「「「]、[「/」]pstnアドレス[「/」]、[「「「]、「@」 mta-I-pstn」
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
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
pstn-email) MUST be added.
含まれていて、」 キャラクタが翻訳から別に結果になることができる「任意」/がそうしたゲートウェイ(いくつかのX.400ゲートウェイなどの)を輸送する、」 /、」 随意的な要素として。 実装は任意のスラッシュを受け入れなければなりませんが、SHOULD NOTはそれらを生成します。 インターネット・メールアドレシングに変えるとき、ゲートウェイはそれらを全部はぎ取ることができます。 関連規格[2]、[3]は、ちょうどいつ全体の地方の部分(すなわち、pstn-メールへの"@"キャラクタの左の部分)の任意の「引用文」キャラクタ周辺を加えなければならないかを定義します。
4.1 Multiple subaddresses
4.1 複数の「副-アドレス」
There are some instances in GSTN applications where multiple subaddresses are used. On the other hand in e-mail practice a separate and unique e-mail address is always used for each recipient.
GSTNアプリケーションにはいくつかのインスタンスが複数の「副-アドレス」が使用されているところにあります。 他方では、メール習慣では、別々の、そして、ユニークなEメールアドレスは各受取人にいつも使用されます。
Allocchio Standards Track [Page 5] RFC 3191 Minimal GSTN address format in Internet Mail October 2001
インターネットメール2001年10月のAllocchio Standards Track[5ページ]RFC3191Minimal GSTNアドレス形式
In the event a particular GSTN service requires multiple subaddresses (in any form defined by the standard specification for that GSTN service) that are associated with the same "pstn-mbox", then the use of multiple "pstn-email" elements is REQUIRED.
イベントでは、特定のGSTNサービスは同じ"pstn-mbox"に関連している複数の「副-アドレス」(そのGSTNサービスのための標準の仕様で定義されたどんな書式でのも)を必要とします、そして、複数の「pstn-メール」要素の使用はREQUIREDです。
Implementors' note:
作成者の注意:
The UA may accept multiple subaddress elements for the same
global-phone, but it MUST generate multiple "pstn-mbox" elements
when submitting the message to the MTA.
UAは同じグローバルな電話のために複数の「副-アドレス」要素を受け入れるかもしれませんが、MTAにメッセージを提出するとき、それは複数の"pstn-mbox"要素を生成しなければなりません。
4.2 Some examples of minimal "pstn-email" addresses
4.2 最小量の「pstn-メール」アドレスに関するいくつかの例
Some examples of minimal pstn-email addresses follows:
最小量のpstn-Eメールアドレスに関するいくつかの例が従います:
VOICE=+3940226338@worldvoice.com
声の=+ 3940226338@worldvoice.com
FAX=+1.202.7653000/T33S=6377@faxserv.org
ファックス=+1.202.7653000/T33Sは 6377@faxserv.org と等しいです。
/SMS=+33-1-88335215/@telecom.com
/SMS=+ 33-1-88335215/@telecom.com
Note:
以下に注意してください。
these examples are given as illustrations only; they do not
necessarily represent valid pstn-addresses.
これらの例はイラストだけとして出されます。 彼らは必ず有効なpstn-アドレスを表すというわけではありません。
5. Conclusions
5. 結論
This proposal creates a minimal standard encoding for GSTN addresses within the global e-mail transport system. It also defines the standard extension mechanism to be used to introduce new elements for GSTN addresses.
この提案はGSTNのためにグローバルなメール輸送システムの中でアドレスをコード化する最小量の規格を作成します。 また、それは、GSTNアドレスのために新しい要素を紹介するのに使用されるために標準の拡張機能を定義します。
The proposal is consistent with existing e-mail standards. Each specific GSTN service using this proposal MUST define and register with IANA its own "service-selector" specification and MUST define and register the eventual other "qualif-type1" elements needed for its specific application. An example of such an application is contained in reference [13].
提案は既存のメール規格と一致しています。 この提案を使用するそれぞれの特定のGSTNサービスは、最後の他の「特定のアプリケーションに必要であるqualif-type1"要素」をそれ自身の「サービスセレクタ」仕様をIANAに定義して、登録しなければならなくて、定義して、登録しなければなりません。 そのようなアプリケーションに関する例は参照[13]に含まれています。
6. Security Considerations
6. セキュリティ問題
This document specifies a means by which GSTN 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.
このドキュメントはGSTNアドレスをEメールアドレスにコード化できる手段を指定します。 メールルーティングがドメインネームシステム(DNS)データで決定するので、DNSに対するうまくいっている攻撃はいじられた情報を広めるかもしれません。(それは、ソフトウェアのセキュリティが感染されたいくらかのMTAかゲートウェイを通して紛らされるべきメールメッセージを引き起こします)。
Allocchio Standards Track [Page 6] RFC 3191 Minimal GSTN address format in Internet Mail October 2001
インターネットメール2001年10月のAllocchio Standards Track[6ページ]RFC3191Minimal GSTNアドレス形式
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問題
As the service-selector and qualif-type1 elements values are extensible, they MUST be registered with IANA.
サービスセレクタとqualif-type1要素として、値が広げることができる、IANAにそれらを登録しなければなりません。
To register a service-selector or a qualif-type1 element, the registration form templates given in 7.1 and 7.2 MUST be used. Any new registration MUST fulfill the "Specification Required" criteria, as defined in RFC 2434, section 2 [16]:
サービスセレクタかqualif-type1要素を登録するために、7.1と7.2で与えられた登録用紙テンプレートを使用しなければなりません。 どんな新規登録もRFC2434、セクション2[16]で定義されるように「仕様が必要である」という評価基準を満たさなければなりません:
"Specification Required - Values and their meaning MUST be
documented in an RFC or other permanent and readily available
reference, in sufficient detail so that interoperability between
independent implementations is possible."
「仕様Required--RFCか他の永久的で容易に利用可能な参照に値とそれらの意味を記録しなければなりません、詳細に十分な独立している実装の間の相互運用性は可能です。」
IANA MUST NOT accept registrations which are not supplemented by a Specification as defined above and which are not fully specified according to the template forms given in 7.1 and 7.2. In case of need for further consultation about accepting a new registration, IANA SHOULD refer to the Application Area Director to be directed to the appropriate "expert" individual or IETF Working Group.
IANA MUST NOTは上で定義されるようにSpecificationによって補われないで、7.1と7.2で与えられたテンプレート書式によると、完全に指定されるというわけではない登録証明書を受け入れます。 必要な場合は新規登録を受け入れることに関するさらなる相談について、IANA SHOULDは、適切な「専門」の個人かIETF作業部会に向けられるためにApplication Areaディレクターについて言及します。
After successful registration, IANA should publish the registered new element in the appropriate on-line IANA WEB site, and include it into the updates of the "Assigned Numbers" RFC series.
うまくいっている登録の後に、IANAは適切なオンラインIANA WEBサイトで登録された新しい要素を発行して、「規定番号」RFCシリーズのアップデートにそれを含めるはずです。
This section (including 7.1 and 7.2) updates the ones contained in [15].
このセクション(7.1と7.2を含んでいる)は[15]に含まれたものをアップデートします。
7.1 IANA Registration form template for new values of GSTN
address service-selector
7.1 GSTNアドレスサービスセレクタの新しい値のためのIANA Registrationフォームテンプレート
To: IANA@iana.org Subject: Registration of new values for the GSTN address service-selector specifier "foo"
To: IANA@iana.org Subject: GSTNアドレスサービスセレクタ特許説明書の作成書"foo"のための新しい値の登録
Allocchio Standards Track [Page 7] RFC 3191 Minimal GSTN address format in Internet Mail October 2001
インターネットメール2001年10月のAllocchio Standards Track[7ページ]RFC3191Minimal GSTNアドレス形式
service-selector name:
サービスセレクタ名:
foo
foo
Description of Use:
使用の記述:
foo - ("foo" is a fictional new service-selector used in this
template as an example, it is to be replaced with the new value
being registered. Include a short description of the use of the
new value here. This MUST include reference to Standard Track
RFCs and eventually to other Standard Bodies documents for the
complete description; the use of the value must be defined
completely enough for independent implementation).
foo、-("foo"が例としてこのテンプレートで使用される、作り事の新しいサービスセレクタである、それは示される新しい値に取り替えられることになっています。 ここで新しい値の使用の短い記述を含めてください。 これは、Standard Track RFCsに指示するものを含めなければならなくて、結局、完全ために他のStandard Bodiesに記述を記録します。 独立している実装のために値の使用を十分完全に定義しなければなりません。).
Security Considerations:
セキュリティ問題:
(Any additional security considerations that may be introduced by
use of the new service-selector parameter should be defined here
or in the reference Standards Track RFCs)
(新しいサービスセレクタパラメタの使用で紹介されるどんな追加担保問題もここか参照Standards Track RFCsで定義されるべきです)
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
(fill in contact information)
(問い合わせ先における中詰め)
INFORMATION TO THE SUBMITTER:
SUBMITTERへの情報:
The accepted registrations will be listed in the "Assigned
Numbers" series of RFCs. The information in the registration form
is freely distributable.
受け入れられた登録証明書はRFCsの「規定番号」シリーズで記載されるでしょう。 登録用紙の情報は自由に配置可能です。
7.2 IANA Registration form template for new values of GSTN
address qualif-type1 keyword and value
7.2 GSTNアドレスqualif-type1キーワードと価値の新しい値のためのIANA Registrationフォームテンプレート
To: IANA@iana.org Subject: Registration of new values for the GSTN address qualif-type1 element "bar"
To: IANA@iana.org Subject: GSTNアドレスqualif-type1要素「バー」への新しい値の登録
qualif-type1 "keyword" name:
qualif-type1「キーワード」名:
bar
バー
qualif-type1 "value" ABNF definition:
qualif-type1「値」ABNF定義:
abnf - ("abnf" MUST define the ABNF form of the qualif-type1
value. The ABNF specification MUST be self-contained, using as
basic elements the tokens given in specification [4]. To avoid
any duplication (when appropriate), it MUST also use any already
ABNF仕様は自己充足的であるに違いありません、基本要素として仕様[4]で与えられたトークンを使用して。"abnf"はqualif-type1価値のABNF書式を定義しなければなりません。abnf--、(また、どんな重複(適切であるときに)も避けるために、それは既にいずれも使用しなければなりません。
Allocchio Standards Track [Page 8] RFC 3191 Minimal GSTN address format in Internet Mail October 2001
インターネットメール2001年10月のAllocchio Standards Track[8ページ]RFC3191Minimal GSTNアドレス形式
registered non-basic token from other qualif-type1 elements, i.e.,
it MUST use the same non-basic token name and then repeat its
identical ABNF definition from basic tokens.
他のqualif-type1要素からの登録された非基本的なトークン、すなわち、それは同じ非基本的なトークン名を使用して、次に、基本的なトークンから同じABNF定義を繰り返さなければなりません。
Description of Use:
使用の記述:
bar - ("bar" is a fictional description for a new qualif-type1
element used in this template as an example. It is to be replaced
by the real description of qualif-type1 element being registered.
Include a short description of the use of the new qualif-type1
here. This MUST include reference to Standards Track RFCs and
eventually to other Standard Bodies documents for the complete
description; the use of the value MUST be defined completely
enough for independent implementation.)
バー、-(「バー」は例としてこのテンプレートで使用される新しいqualif-type1要素のための作り事の記述です。 登録されていて、それはqualif-type1要素の本当の記述に取り替えられることになっています。 ここで新しいqualif-type1の使用の短い記述を含めてください。 これは、Standards Track RFCsに指示するものを含めなければならなくて、結局、完全ために他のStandard Bodiesに記述を記録します。 独立している実装のために値の使用を十分完全に定義しなければなりません。)
Use Restriction:
制限を使用してください:
(If the new qualif-type1 elements is meaningful only for a
specific set of service-element, you MUST specify here the list of
allowed service-element types. If there is no restriction, then
specify the keyword "none")
(特定のセットのサービス要素だけに、新しいqualif-type1要素が重要であるなら、あなたはここで許容サービス要素型のリストを指定しなければなりません。 制限が全くなければ、「なにも」というキーワードを指定してください。)
Security Considerations:
セキュリティ問題:
(Any additional security considerations that may be introduced by
use of the new service-selector parameter should be defined here
or in the reference Standards Track RFCs)
(新しいサービスセレクタパラメタの使用で紹介されるどんな追加担保問題もここか参照Standards Track RFCsで定義されるべきです)
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
(fill in contact information)
(問い合わせ先における中詰め)
INFORMATION TO THE SUBMITTER:
SUBMITTERへの情報:
The accepted registrations will be listed in the "Assigned
Numbers" series of RFCs. The information in the registration form
is freely distributable.
受け入れられた登録証明書はRFCsの「規定番号」シリーズで記載されるでしょう。 登録用紙の情報は自由に配置可能です。
8. Changes from RFC 2303 specification
8. RFC2303仕様からの変化
Although there are no technical or major changes from RFC 2303 specification, this section briefly describes where updates and clarifications were introduced:
2303年のRFC仕様からのどんな技術的であるか主要な変化もありませんが、このセクションは、アップデートと明確化がどこで導入されたかを簡潔に説明します:
Allocchio Standards Track [Page 9] RFC 3191 Minimal GSTN address format in Internet Mail October 2001
インターネットメール2001年10月のAllocchio Standards Track[9ページ]RFC3191Minimal GSTNアドレス形式
- 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変数名は変えられませんでした。
- it was made clear that "GSTN addresses" correspond, in common
language, to "telephone numbers" and that the "global-phone" is a
representation of E.164 numeric addresses;
- 「GSTNアドレス」が対応することが明らかにされました、共通語で「電話番号」とそれに、「グローバルな電話」はE.164数値アドレスの表現です。
- an explicit list of "new terms" with explanations was added to
section 1.1;
- 説明がある「新学期」の明白なリストはセクション1.1に追加されました。
- the fact that any other specification adopting the "pstn-address"
definition MUST register with IANA the new "service-selector" and
"qualif-type1" elements was made explicit throughout the document;
the relevant mechanism to be used was added in section 7 "IANA
considerations" (including the IANA Registration form templates);
this is also consistent with RFC 2846;
- 「pstn-アドレス」定義を採用するいかなる他の仕様も新しい「サービスセレクタ」をIANAに登録しなければならないという事実と「qualif-type1"要素をドキュメント中で明白にしました」。 使用されるべき関連メカニズムは「IANA問題」というセクション7で加えられました(IANA Registrationフォームテンプレートを含んでいて)。 また、これもRFC2846と一致しています。
- in section 2.1 the use and meaning of "written-sep" was clarified;
- セクション2.1では、「書かれたsep」の使用と意味ははっきりさせられました。
- in section 4., the quoting rules of the "pstn-address" and their
practical use was made explicit both in the definition of
pstn-email" and in the Implementors' note;
- 「セクション4.では、「pstn-アドレス」の引用規則とそれらの実用をpstn-メールの定義で両方の、明白にし」てImplementorsが注意するコネ。
- section 4.1 was updated to clarify how to generate "pstn-email"
when more than one subaddress is used;
- 1つ以上の「副-アドレス」が使用されているとき、「pstn-メール」を生成する方法をはっきりさせるためにセクション4.1をアップデートしました。
- the Author's Address was updated;
- AuthorのAddressをアップデートしました。
- the References list was updated to include RFC 2846 and RFC 2434.
- RFC2846とRFC2434を含むようにReferencesリストをアップデートしました。
Allocchio Standards Track [Page 10] RFC 3191 Minimal GSTN address format in Internet Mail October 2001
インターネットメール2001年10月のAllocchio Standards Track[10ページ]RFC3191Minimal GSTNアドレス形式
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 11] RFC 3191 Minimal GSTN address format in Internet Mail October 2001
インターネットメール2001年10月のAllocchio Standards Track[11ページ]RFC3191Minimal GSTNアドレス形式
[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 FAX address format in Internet Mail",
RFC 3192, October 2001.
[13]Allocchio、C.、「インターネットメールにおける最小量のFAXアドレス形式」、RFC3192、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月。
[16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[16]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
Allocchio Standards Track [Page 12] RFC 3191 Minimal GSTN address format in Internet Mail October 2001
インターネットメール2001年10月のAllocchio Standards Track[12ページ]RFC3191Minimal GSTNアドレス形式
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 13]
Allocchio標準化過程[13ページ]
一覧
スポンサーリンク
