[要約] RFC 3192は、インターネットメールでの最小FAXアドレス形式に関するガイドラインです。このRFCの目的は、FAXアドレスの一貫性と相互運用性を確保するための標準化を提供することです。
Network Working Group C. Allocchio
Request for Comments: 3192 GARR-Italy
Obsoletes: 2304 October 2001
Updates: 2846
Category: Standards Track
Minimal FAX address format in Internet Mail
インターネットメールの最小限のFAXアドレス形式
Status of this 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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
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.
このメモは、インターネット電子メールアドレスのローカルパートにあるファクシミリデバイスのグローバルスイッチ付き電話ネットワーク（GSTN）アドレスをエンコードする簡単な方法について説明しています。
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.
Gatewayオブジェクトへの最初の電子メールが登場したため、電子メールアドレスとしてFAXアドレスを指定するためのさまざまな方法が、実装者によって使用されています。この方法のいくつかの目的が特定されています。電子メールユーザーが電子メールインターフェイスからファックスを送信および受信できるようにして、何らかの「ファックスオーバー電子メールサービス」トランスポートを許可します（コストを削減する可能性があります既存の電子メールインフラストラクチャを使用している間、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.
このメモでは、参照に必要な最小限のアドレス指定方法と標準拡張機能について、FAXアドレスを電子メールアドレスにエンコードすることを説明しています[13]。逆の問題、つまり、従来の数値のみの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フォームは、「IANAの考慮事項」章（このドキュメントのセクション7）に記載されています。
All implementations supporting FAX over e-mail address format MUST support this minimal specification.
電子メールアドレス形式を介したFAXをサポートするすべての実装は、この最小限の仕様をサポートする必要があります。
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"
「必須」、「必須」、「必須」、「shall」、「shall "、" should "、" nove "、" becommented "、" may "、" optional "
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ファックスデバイス：I-PSTNデバイスタイプ[13]は、GSTNサービスを介した従来のFAXと直接または間接的に通信できます。
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-EMAIL：インターネット電子メールサービスでFAXアドレスを輸送するために使用される完全なインターネット電子メールアドレス構造（[13]のPSTN-EMAILも参照）。
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.
電子メール内の最小FAXアドレスは、参照[13]との一貫性のために定義されており、Fax-MboxとオプションのQualif-Type1要素の2つの要素が含まれています。
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:
FAXサービスで定義されている「サービスセレクター」は次のとおりです。
service-selector = "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:
FAXアドレスの構文では、T.30/T.33サブアドレスのサポートのためにQualif-Type1要素が定義されています（[13]のセクション2を参照）。この要素の使用はオプションですが、準拠した実装は、存在するときにそれをサポートし、正しく解釈できる必要があります。その定義は次のとおりです。
qualif-type1 = "/" t33-sep "=" sub-addr
qualif-type1 = "/" t33-sep "=" sub-addr
where
ただし
t33-sep = "T33S"
sub-addr = 1*( DIGIT )
Thus, the minimal specification of a fax in e-mail address is:
したがって、電子メールアドレスのFAXの最小限の仕様は次のとおりです。
fax-address = fax-mbox [ "/T33S=" sub-addr ]
fax-address = fax-mbox ["/t33s =" sub-addr]
fax-mbox = "FAX=" global-phone
fax-mbox = "fax ="グローバルフォン
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、およびこのドキュメントと一致する<sub-Addr>で数値のみが許可されます。T.30とT.33はスペースを使用してそのフィールドを埋めますが、このドキュメントで定義された<sub-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は「＃」文字を使用して複数のサブアドレスを指定します。ただし、このドキュメントで定義された<sub-addr>フィールドでは、数字のみが許可されています。<fax-mbox>あたりの複数の<sub-addr>の場合は、セクション4.1を参照してください。指定する必要があります。
The Minimal supported syntax for global-phone (as described in section 2.1 of reference [13]) is:
グローバルフォンの最小限のサポートされた構文（参照[13]のセクション2.1で説明されている）は次のとおりです。
global-phone = "+" 1*( DIGIT / written-sep )
written-sep = ( "-" / "." )
Refer to section 2.1 in [13] for other important considerations about the global-phone element.
グローバルフォン要素に関する他の重要な考慮事項については、[13]のセクション2.1を参照してください。
Some examples of minimal fax-address follows:
最小限のファックスアドレスの例が次のとおりです。
FAX=+3940226338
FAX = 3940226338
FAX=+12027653000/T33S=1387
FAX=+33-1-88335215
FAX = 33-1-88335215
Note:
注記：
the examples shown are just for illustration purposes.
示されている例は、単にイラストの目的です。
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-Faxデバイス」には、その特性の中で、インターネット上でそれを識別する独自のインターネットドメイン名があります。インターネットメール内では、これはアドレスの右側（RHS）の部分、つまり「@」記号の右側の部分です。このドキュメントの目的のために、これを「MTA-Iファックス」と呼びます
mta-I-fax = domain
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送信で使用される「ドメイン」文字列の場合、文字列はその標準<domain>仕様[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エンベロープとメッセージヘッダーフィールドの両方のアドレスで許可されています。
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アドレスを転送するために使用される完全な構造は、「Fax-Email」と呼ばれます。このオブジェクトは、[2]および[3]「addr-spec」構文に準拠する電子メールアドレスであり、FAX番号を識別できる構造の改良となります。
fax-email = ["""] ["/"] fax-address ["/"] ["""] "@" mta-I-fax
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 fax-email) MUST be added.
オプションの「/」文字は、オプションの要素として「/」を含む他のトランスポートゲートウェイ（X.400ゲートウェイなど）の翻訳から生じる可能性があります。実装は、オプションのスラッシュを受け入れる必要がありますが、生成されないでください。ゲートウェイは、インターネットメールアドレス指定に変換するときにそれらを取り除くことができます。関連する標準[2]、[3]は、オプションの「引用」文字がローカルパーツ全体（つまり、「@」文字の左側の部分をFax-Emailに描く）を囲む「引用」文字を正確に追加する必要があることを正確に定義します。
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アプリケーションには、複数のサブアドレスが使用されるいくつかのインスタンスがあります。FAXサービスのT.33サブアドレスは、これらのケースの1つです。電子メールの練習では、各受信者に常に独立した一意の電子メールアドレスが使用されます。そのため、複数のt.33サブアドレスが存在する場合、複数の「ファックス」要素の使用が必要です。
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は、同じグローバルフォンの複数のサブアドレス要素を受け入れる場合がありますが、MTAにメッセージを送信するときに複数の「FAX-MBOX」要素を生成する必要があります。
Some examples of minimal fax-email addresses follows:
最小限のFAX-EMAILアドレスの例が次のとおりです。
FAX=+3940226338@faxworld.org
FAX=+12027653000/T33S=1387@faxworld.org
/FAX=+33-1-88335215/@faxworld.org
Note:
注記：
the examples shown are just for illustration purposes.
示されている例は、単にイラストの目的です。
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アドレスの最小限の標準エンコードを作成します。この提案は、既存の電子メール標準と一致しています。
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アドレスを電子メールアドレスにエンコードできる手段を指定します。電子メールルーティングはドメイン名システム（DNS）データによって決定されるため、DNSへの攻撃の成功は改ざんされた情報を広める可能性があり、これにより、ソフトウェアのセキュリティが侵害されているMTAまたはGatewayを介して電子メールメッセージが転用されます。
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サーバーの妥協、（b）クライアントのDNSクエリに対する偽造応答の生成、（c）無関係なクエリに応じて誤った「追加情報」を返す。クライアントは、メールルーティングが権威ある回答のみに基づいていることを確認する必要があります。DNSセキュリティメカニズム[5]がより広く展開されると、クライアントはそれらのメカニズムを使用して、メールルーティングレコードの信頼性と整合性を検証する必要があります。
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].
「FAX」サービスセレクターと「T33S」Qualif-Type1要素のIANA登録フォームは、ここで定義されています。これらのフォームは、[15]で定義された以前の登録フォームを更新します。
To: IANA@iana.org Subject: Registration of updated values for the GSTN address service-selector specifier "FAX"
宛先：iana@iana.org件名：GSTNアドレスサービスセレクター仕様の更新値の登録「FAX」
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アドレスがインターネットFAXデバイスまたはOnramp/Offramp Fax Gatewayのいずれかを指すことを指定します。
For a complete description refer to RFC 3192 and RFC 3191.
完全な説明については、RFC 3192およびRFC 3191を参照してください。
Security Considerations:
セキュリティ上の考慮事項：
See the Security Consideration section of RFC 3192.
RFC 3192のセキュリティ検討セクションを参照してください。
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Claudio Allocchio
INFN-GARR
c/o Sincrotrone Trieste
SS 14 Km 163.5 Basovizza
I 34012 Trieste
Italy
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
To: IANA@iana.org Subject: Registration of updated values for the GSTN address qualif-type1 element "T33S"
宛先：iana@iana.org件名：GSTNアドレスの更新値の登録qualif-type1要素「T33S」
qualif-type1 "keyword" name:
qualif-type1 "キーワード"名：
T33S
T33S
qualif-type1 "value" ABNF definition:
qualif-type1 "value" abnf定義：
sub-addr = 1*( DIGIT )
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月）」で説明されている数値のみのオプションのFAXサブアドレス要素を指定するために使用されます。さらに詳細な説明は、RFC 3192で入手できます。
Use Restriction:
制限を使用：
The use of "T33S" is restricted to "FAX" service-selector, is it has no meaning outside the fax service.
「T33」の使用は、「FAX」サービスセレクターに制限されています。これは、FAXサービス以外の意味がないことです。
Security Considerations:
セキュリティ上の考慮事項：
See the Security Consideration section of RFC 3192.
RFC 3192のセキュリティ検討セクションを参照してください。
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Claudio Allocchio
INFN-GARR
c/o Sincrotrone Trieste
SS 14 Km 163.5 Basovizza
I 34012 Trieste
Italy
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
Although there are no major or technical changes from RFC 2304 specification, this section briefly describes where updates and clarifications were introduced:
RFC 2304仕様からの主要なまたは技術的な変更はありませんが、このセクションでは、更新と明確化が導入された場所について簡単に説明します。
- 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.
- テレフォニーシステムが「単一/少数の」パブリックオペレーターのパラダイムにこれ以上適合しないというケースを考慮して、古い定義「PSTN-パブリックスイッチド電話ネットワーク」は、より適切な「GSTN - グローバルスイッチド電話ネットワーク」に変更されました。ただし、以前の仕様と一致し続けるために、ABNF変数名は変更されませんでした。
- section 7 "IANA Considerations" and the IANA registration forms for the "FAX" "service-selector" and for the "T33S" "qualif-type1" elements were added;
- セクション7「IANAの考慮事項」とIANA登録フォームは、「FAX」「サービスセレクター」と「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サブアドレスが存在する場合、それらを処理する方法を明確にするために、より明確に説明されました（セクション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では、「Fax-Address」の引用ルールとそれらの実用的な使用は、「Fax-Email」の定義と実装者のメモの両方で明示的になりました。
- the Author's Address was updated;
- 著者の住所が更新されました。
- the References list was updates to substitute ITU E.164 (1991) with ITU E.164 (1997).
- 参照リストは、ITU E.164（1997）を使用して、ITU E.164（1991）を代用するための更新でした。
Claudio Allocchio INFN-GARR c/o Sincrotrone Trieste SS 14 Km 163.5 Basovizza I 34012 Trieste Italy
Claudio Allocchio infn-garr c/o sincrotrone Trieste ss 14 km 163.5 Basovizza I 34012 Trieste Italy
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
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[1] Postel、J。、「Simple Mail Transfer Protocol」、STD 10、RFC 821、1982年8月。
[2] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[2] Crocker、D。、「ARPAインターネットテキストメッセージの形式の標準」、STD 11、RFC 822、1982年8月。
[3] Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123, October 1989.
[3] Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[4] Malamud, C. and M. Rose, "Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures", RFC 1528, October 1993.
[4] Malamud、C。and M. Rose、「TPC.intサブドメインの操作の原則：リモート印刷 - 技術手順」、RFC 1528、1993年10月。
[5] Eastlake, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.
[5] Eastlake、D。and C. Kaufman、「ドメイン名システムセキュリティ拡張機能」、RFC 2065、1997年1月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications", RFC 2234, November 1997.
[7] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強」、RFC 2234、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-メッセージ処理サービス：対人メッセージングサービスとTelefaxサービスの間の相互通信。推奨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月）。
[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 -ETS 300,380-ユニバーサルパーソナルテレコミュニケーション（UPT）：アクセスデバイスデュアルトーンマルチ周波数（DTMF）センダーハンドセット電話のマイクへの音響カップリング（1995年3月）。
[13] Allocchio, C., "Minimal GSTN address format in Internet Mail", RFC 3191, October 2001.
[13] Allocchio、C。、「インターネットメールの最小GSTNアドレス形式」、RFC 3191、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。、「Mixer（Mime Internet X.400 Enhanced Relay）：X.400とRFC 822/MIMEの間のマッピング」、RFC 2156、1998年1月。
[15] Allocchio, C., "GSTN address element extensions in e-mail services", RFC 2846, June 2000.
[15] Allocchio、C。、「電子メールサービスのGSTNアドレス要素拡張機能」、RFC 2846、2000年6月。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
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.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
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エディター機能の資金は現在、インターネット協会によって提供されています。