[要約] RFC 2303は、インターネットメールで使用される最小限のPSTNアドレス形式に関する規格です。このRFCの目的は、PSTNアドレスをメールアドレスとして使用する際の標準化と相互運用性の向上です。
Network Working Group C. Allocchio
Request for Comments: 2303 GARR-Italy
Category: Standards Track March 1998
Minimal PSTN address format in Internet Mail
インターネットメールの最小PSTNアドレス形式
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 (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
IESG NOTE
IESGノート
This memo describes a simple method of encoding PSTN addresses 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 PSTN-based services.
このメモは、インターネットメールアドレスのローカル部分でPSTNアドレスをエンコードする簡単な方法と、PSTNベースのサービスへのメールゲートウェイに必要な追加の標準属性のエンコードを可能にする拡張メカニズムについて説明しています。
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 PSTN services gateway appeared, a number of different methods to specify a PSTN address as an e-mail address have been used by implementors. Two major objectives for this were
PSTNサービスゲートウェイへの最初の電子メールが登場して以来、PSTNアドレスを電子メールアドレスとして指定するさまざまな方法が、実装者によって使用されてきました。このための2つの主要な目的は
- enable an e-mail user to access these services from his/her e-mail interface;
- 電子メールユーザーが自分の電子メールインターフェイスからこれらのサービスにアクセスできるようにします。
- enable some kind of "PSTN over e-mail service" transport, to reduce the costs of PSTN long distance transmissions, and use the existing e-mail infrastructure.
- ある種の「PSTN over e-mail service」トランスポートを有効にして、PSTN長距離伝送のコストを削減し、既存の電子メールインフラストラクチャを使用します。
This memo describes the MINIMAL addressing method to encode PSTN 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 PSTN device user to access the e-mail transport service, is not discussed here.
このメモは、PSTNアドレスを電子メールアドレスにエンコードするためのMINIMALアドレッシング方式と、さらに標準的な要素を定義できるようにする標準の拡張メカニズムについて説明しています。反対の問題、つまり従来の数値のみのPSTNデバイスユーザーが電子メール転送サービスにアクセスできるようにすることについては、ここでは説明しません。
All implementations supporting this PSTN over e-mail service MUST support as a minimum the specification described in this document. The generic complex case of converting the whole PSTN addressing into e-mail is out of scope in this minimal specification: there is some work in progress in the field, where also a number of standard optional extensions are being defined.
電子メールサービスを介してこのPSTNをサポートするすべての実装は、このドキュメントで説明されている仕様を最低限サポートする必要があります。 PSTNアドレッシング全体を電子メールに変換する一般的な複雑なケースは、この最小限の仕様では範囲外です。この分野では進行中の作業がいくつかあり、標準のオプションの拡張機能もいくつか定義されています。
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 capitalised words
このドキュメントでは、正式な定義は、[7]で定義されているABNF構文を使用して説明されています。また、そのドキュメントの「付録A-コア」で定義されている「コアの定義」の一部を使用します。大文字の単語の正確な意味
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"
「必須」、「必須」、「必須」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」
is defined in reference [6].
参考文献[6]で定義されています。
The minimal specification of a PSTN address in e-mail address is as follows:
電子メールアドレスでのPSTNアドレスの最小仕様は次のとおりです。
pstn-address = pstn-mbox [ qualif-type1 ]
pstn-address = pstn-mbox [qualif-type1]
pstn-mbox = service-selector "=" global-phone
pstn-mbox = service-selector "=" global-phone
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.
Specifications adopting the "pstn-address" definition MUST define a unique case insensitive "service-selector" element to identify the specific messaging service involved.
「pstn-address」定義を採用する仕様では、関係する特定のメッセージングサービスを識別するために、一意の大文字と小文字を区別しない「service-selector」要素を定義する必要があります。
These specifications MUST also define which minimal "qualif-type1" extensions, if any, MUST be supported for the specified service.
これらの仕様は、指定されたサービスに対してサポートされる必要がある最小の「qualif-type1」拡張も定義する必要があります。
Implementations confirming to these minimal requirements specification are allowed to ingnore any other non-minimal extensions address element which can be present in the "pstn-address". However, conforming implementations MUST preserve all "qualif-type1" address elements they receive.
これらの最小要件の仕様を確認する実装では、「pstn-address」に存在する可能性がある他の非最小拡張アドレス要素を無視できます。ただし、準拠する実装は、受信するすべての「qualif-type1」アドレス要素を保持する必要があります。
The generic "qualif-type1" element is defined as:
一般的な「qualif-type1」要素は次のように定義されます。
qualif-type1 = "/" keyword "=" string
keyword = 1*( DIGIT / ALPHA / "-" )
; note that SP (space) is not allowed in keyword
string = PCHAR ; note that printable characters are %x20-7E
string = PCHAR;印刷可能な文字は％x20-7Eであることに注意してください
As such, all "pstn-address" extensions elements MUST be defined in the "qualif-type1" form.
そのため、「pstn-address」拡張要素はすべて「qualif-type1」形式で定義する必要があります。
We now define the minimal supported syntax for global-phone:
次に、グローバル電話でサポートされる最小限の構文を定義します。
global-phone = "+" 1*( DIGIT , written-sep )
written-sep = ( "-" / "." )
The use of other dialling schemas for PSTN numbers (like private numbering plans or local dialling conventions) is also allowed. However, this does not preclude nor remove the minimal compulsory requirement to support the "global-phone" syntax as defined above.
PSTN番号の他のダイヤルスキーマ（プライベート番号計画やローカルダイヤル規則など）の使用も許可されています。ただし、これは、上記で定義された「グローバル電話」構文をサポートするための最小限の必須要件を排除または削除するものではありません。
Any non "global-phone" dialling schema MUST NOT use the leading "+" between the "=" sign and the dialling string. The "+" sign is strictly reserved for the standard "global-phone" syntax.
「global-phone」以外のダイヤリングスキーマでは、「=」記号とダイヤリング文字列の間に「+」を使用してはなりません。 「+」記号は、標準の「グローバル電話」構文用に厳密に予約されています。
Note: The specification of these different dialling schemas is out of scope for this minimal specification.
注：これらのさまざまなダイヤリングスキーマの仕様は、この最小限の仕様の範囲外です。
User specification of PSTN e-mail addresses will be facilitated if they can insert these separators between dial elements like digits etc. For this reason we allow them in the syntax the written-sep element.
PSTN電子メールアドレスのユーザー指定は、数字などのダイヤル要素の間にこれらの区切り文字を挿入できる場合に容易になります。このため、私たちは、書かれたsep要素の構文でそれらを許可します。
Implementors' note: Use of the written-sep elements is allowed, but not recommended. Any occurences of written-sep elements in a pstn-mbox MUST be ignored by all conformant implementations. User Agents SHOULD remove written-sep elements before submitting messages to the Message Transport System.
実装者のメモ：書いた9月要素の使用は許可されていますが、推奨されていません。 pstn-mbox内の書き込まれたsep要素の発生は、すべての適合実装によって無視される必要があります。ユーザーエージェントは、メッセージトランスポートシステムにメッセージを送信する前に、書かれたsep要素を削除する必要があります（SHOULD）。
VOICE=+3940226338
VOICE = + 3940226338
FAX=+12027653000/T33S=6377
SMS=+33-1-88335215
SMS = + 33-1-88335215
An "I-pstn device" has an e-mail address, or to be more exact, a name which enables a mail system to identify it on the e-mail global system.
「I-pstnデバイス」には、電子メールアドレス、より正確には、メールシステムが電子メールグローバルシステム上でそれを識別できるようにする名前があります。
In Internet mail, this is the Right Hand Side (RHS) part of the address, i.e. the part on the right of the "@" sign. We will call this "mta-I-pstn"
インターネットメールでは、これはアドレスの右側（RHS）の部分、つまり「@」記号の右側の部分です。これを「mta-I-pstn」と呼びます
mta-I-pstn = domain
For "domain" strings used in SMTP transmissions, the string MUST conform to the requirements of that standard's <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: in both cases, the standards permit use of "domain names" or "domain literals" in addresses.
注：どちらの場合も、標準ではアドレスに「ドメイン名」または「ドメインリテラル」を使用できます。
The complete structure used to transfer a minimal PSTN address over the Internet e-mail transport system is called "pstn-email". This object is a an e-mail address which conforms to RFC822 [2] and RFC1123 [3] "addr-spec" syntax, with some extra structure which allows the PSTN number to be identified.
インターネット電子メールトランスポートシステムを介して最小PSTNアドレスを転送するために使用される完全な構造は、「pstn-email」と呼ばれます。このオブジェクトは、RFC822 [2]およびRFC1123 [3]の「addr-spec」構文に準拠した電子メールアドレスであり、PSTN番号を識別できるようにする追加の構造を備えています。
pstn-email = ["/"] pstn-address ["/"] "@" mta-I-pstn
Implementors' note: The optional "/" characters can result from other mail transport services gateways, where it is also 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.
実装者メモ：オプションの「/」文字は、他のメール転送サービスゲートウェイからも発生する可能性があり、オプションの要素でもあります。実装はオプションのスラッシュを受け入れなければならない（MUST）が、それらを生成してはならない（SHOULD NOT）。ゲートウェイは、インターネットメールアドレスに変換するときにそれらを取り除くことができます。
It is essential to remind that "pstn-address" element MUST strictly follow the "quoting rules" spcified in the relevant standards [2], [3].
「pstn-address」要素は、関連する規格[2]、[3]で指定されている「引用規則」に厳密に従う必要があることを思い出してください。
In case a particular service requires multiple subaddresses (in any form defined by the specific standard specification for that service), and these subaddresses need to be given on the same "pstn-mbox", multiple "pstn-email" elements will be used.
特定のサービスが複数のサブアドレス（そのサービスの特定の標準仕様で定義されている任意の形式）を必要とし、これらのサブアドレスを同じ "pstn-mbox"で指定する必要がある場合、複数の "pstn-email"要素が使用されます。
Implementors' note: The UA could accept multiple subaddress elements for the same global-phone, but it must generate multiple "pstn-mbox" elements when passing the message to the MTA.
実装者のメモ：UAは同じグローバル電話の複数のサブアドレス要素を受け入れることができますが、メッセージをMTAに渡すときに複数の「pstn-mbox」要素を生成する必要があります。
VOICE=+3940226338@worldvoice.com
FAX=+1.202.7653000/T33S=6377@faxserv.org
/SMS=+33-1-88335215/@telecom.com
This proposal creates a minimal standard encoding for PSTN addresses within the global e-mail transport system and defines the standard extension mechanism to be used to introduce specific new elements.
この提案は、グローバルな電子メールトランスポートシステム内のPSTNアドレスの最小限の標準エンコーディングを作成し、特定の新しい要素を導入するために使用される標準の拡張メカニズムを定義します。
The proposal requires no changes to existing e-mail software. Each specific PSTN service using this proposal MUST define its own "service-selector" specification and MUST define the eventual other "qualif-type1" elements to be supported for its minimal addressing specification. An example is in reference [13].
この提案では、既存の電子メールソフトウェアを変更する必要はありません。この提案を使用する特定の各PSTNサービスは、独自の「サービスセレクタ」仕様を定義する必要があり、その最小アドレッシング仕様でサポートされる他の最終的な「qualif-type1」要素を定義する必要があります。例は参考文献[13]にあります。
This document specifies a means by which PSTN addresses can be encoded into e-mail addresses. As routing of e-mail messages is determined by Domain Name System (DNS) information, a successful attack on this service could force the mail path via some particular gateway or message transfer agent where mail security can be affected by compromised software.
このドキュメントでは、PSTNアドレスを電子メールアドレスにエンコードする方法を指定します。電子メールメッセージのルーティングはドメインネームシステム（DNS）情報によって決定されるため、このサービスに対する攻撃が成功すると、特定のゲートウェイまたはメッセージ転送エージェントを経由してメールパスが強制され、メールのセキュリティが侵害されたソフトウェアの影響を受ける可能性があります。
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]がより広く導入されると、クライアントはそれらのメカニズムを使用して、メールルーティングレコードの信頼性と整合性を検証する必要があります（SHOULD）。
Claudio Allocchio Sincrotrone Trieste SS 14 Km 163.5 Basovizza I 34012 Trieste Italy
Claudio Allocchio Sincrotrone Trieste SS 14 Km 163.5 Basovizza I 34012トリエステイタリア
RFC822: Claudio.Allocchio@elettra.trieste.it
X.400: C=it;A=garr;P=Trieste;O=Elettra;
S=Allocchio;G=Claudio;
Phone: +39 40 3758523
Fax: +39 40 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", RFC 1123, October 1989.
[3] Braden、R.、「インターネットホストの要件-アプリケーションとサポート」、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。および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。およびC. Kaufman、「ドメインネームシステムセキュリティ拡張機能」、RFC 2065、1997年1月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[6] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、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-メッセージ処理サービス：対人メッセージングサービスとテレファックスサービス間の相互通信。勧告F.423（1992年8月）
[10] ITU E.164 - Numbering plan for the ISDN era; recommendation E.164/I.331 (August 1991)
[10] ITU E.164-ISDN時代の番号計画。勧告E.164 / I.331（1991年8月）
[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-Universal Personal Telecommunication（UPT）：Access Devices Dual Tone Multi Frequency（DTMF）センダー用音響カップリング、ハンドセット電話のマイク（1995年3月）
[13] Allocchio, C., " Minimal FAX address format in Internet Mail", RFC 2304, March 1998.
[13] Allocchio、C。、「インターネットメールの最小限のFAXアドレス形式」、RFC 2304、1998年3月。
[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）：Mapping between X.400 and RFC 822 / MIME」、RFC 2156、1998年1月。
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。