Network Working Group                                      C. Allocchio
Request for Comments: 2304                                   GARR-Italy
Category: Standards Track                                    March 1998
        

Minimal FAX address format in Internet Mail

インターネットメールの最小限のFAXアドレス形式

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 (C) The Internet Society (1998). All Rights Reserved.

Copyright（C）The Internet Society（1998）。全著作権所有。

This memo describes a simple method of encoding PSTN addresses of facsimile devices in the local-part of Internet email addresses.

このメモは、ファクシミリデバイスの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 fax gateway objects appeared, a number of different methods to specify a fax address as an e-mail address have been used by implementors. Two major objectives for this were

FAXゲートウェイオブジェクトへの最初の電子メールが登場して以来、FAXアドレスを電子メールアドレスとして指定するさまざまな方法が、実装者によって使用されてきました。このための2つの主要な目的は

- enable an e-mail user to send faxes from his/her e-mail interface;

- 電子メールユーザーが自分の電子メールインターフェイスからFAXを送信できるようにします。

- enable some kind of "fax over e-mail service" transport, to reduce the costs of fax transmissions, and use the existing e-mail infrastructure.

- FAX送信のコストを削減し、既存のEメールインフラストラクチャを使用するために、ある種の「Fax over Eメールサービス」トランスポートを有効にします。

This memo describes the MINIMAL addressing method and standard extensions to encode FAX addresses in 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アドレスを電子メールアドレスにエンコードするためのMINIMALアドレス指定方法と標準拡張機能について説明しています。反対の問題、つまり従来の数値のみのファックスデバイスユーザーが電子メール転送サービスにアクセスできるようにすることについては、ここでは説明しません。

All implementations supporting this FAX over e-mail address format MUST support as a minimum the specification described in this document. The generic complex case of converting the whole PSTN addressing in 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.

電子メールアドレス形式でこのFAXをサポートするすべての実装は、このドキュメントで説明されている仕様を最低限サポートする必要があります。電子メールの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 "service-selector" defined in section 2 of reference [13] for the fax service is:

参考資料[13]のセクション2で定義されているFAXサービスの「サービスセレクター」は、次のとおりです。

      service-selector = "FAX"
        

The minimal addressing for the fax service also requires support for a "qualif-type1" element (see section 2 of reference [13]). This element is an OPTIONAL element of the fax address, but its support, when present, is REQUIRED:

FAXサービスの最小限のアドレス指定では、「qualif-type1」要素のサポートも必要です（参照[13]のセクション2を参照）。この要素はFAXアドレスのOPTIONAL要素ですが、そのサポートが存在する場合は必須です。

      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-address = fax-mbox [ "/T33S=" sub-addr ]
        

      fax-mbox = "FAX=" global-phone
        

Note: See section 4.1 in case multiple sub-addr per fax-mbox need to be specified.

注：fax-mboxごとに複数のサブアドレスを指定する必要がある場合は、セクション4.1を参照してください。

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

グローバル電話でサポートされる最小の構文（セクションリファレンス[13]で説明）は次のとおりです。

   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）。

FAX=+3940226338

FAX = + 3940226338

      FAX=+12027653000/T33S=1387
        

FAX=+33-1-88335215

FAX = + 33-1-88335215

An "I-fax 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-faxデバイス」には、電子メールアドレス、より正確には、メールシステムが電子メールグローバルシステム上でそれを識別できるようにする名前があります。

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-fax

インターネットメールでは、これはアドレスの右側（RHS）の部分、つまり「@」記号の右側の部分です。これをmta-I-faxと呼びます

      mta-I-fax = 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 FAX address over the Internet e-mail transport system is called "fax-email". This object is an e-mail address which conforms to RFC822 [2] and RFC1123 [3] "addr-spec" syntax, with some extra structure which allows the FAX number to be identified.

最小限のFAXアドレスをインターネットの電子メール転送システムで転送するために使用される完全な構造は、「ファックス電子メール」と呼ばれます。このオブジェクトは、RFC822 [2]およびRFC1123 [3]の「addr-spec」構文に準拠した電子メールアドレスであり、FAX番号を識別できるようにする追加の構造を備えています。

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

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 "fax-address" element MUST strictly follow the "quoting rules" spcified in the relevant standards [2], [3]

「fax-address」要素は、関連する規格で指定されている「引用規則」に厳密に従う必要があることを思い出してください[2]、[3]。

In case a particular service requires multiple T.33 subaddresses, and these subaddresses need to be given on the same "fax-mbox", multiple "fax-email" elements will be used.

特定のサービスが複数のT.33サブアドレスを必要とし、これらのサブアドレスを同じ「fax-mbox」で指定する必要がある場合、複数の「fax-email」要素が使用されます。

Implementors' note: The UA could accept multiple subaddress elements for the same global-phone, but it must generate multiple "fax-mbox" elements when passing the message to the MTA.

実装者のメモ：UAは同じグローバル電話の複数のサブアドレス要素を受け入れることができますが、メッセージをMTAに渡すときに複数の「fax-mbox」要素を生成する必要があります。

      FAX=+3940226338@faxworld.org
        

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

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

This proposal creates a minimal standard encoding for FAX addresses within the global e-mail transport system. The proposal requires no changes to existing e-mail software.

この提案では、グローバルな電子メールトランスポートシステム内でFAXアドレスの最小限の標準エンコーディングを作成します。この提案では、既存の電子メールソフトウェアを変更する必要はありません。

This document specifies a means by which FAX 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.

このドキュメントでは、FAXアドレスを電子メールアドレスにエンコードする方法を指定します。電子メールメッセージのルーティングはドメインネームシステム（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）。

7. Author's Address

7. 著者のアドレス

   Claudio Allocchio
   Sincrotrone Trieste
   SS 14 Km 163.5 Basovizza
   I 34012 Trieste
   Italy
   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. 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", 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. and 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 2303, March 1998.

[13] Allocchio, C.、「インターネットメールの最小限のFAXアドレス形式」、RFC 2303、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.

このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。