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.

Copyright Notice

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

IESG NOTE Abstract

This memo describes a simple method of encoding PSTN 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 PSTN-based GSTN-based services.

このメモは、インターネット電子メイル番地の局所部分local‐partに PSTN 広域電話交換網 (GSTN) 番地 (広く「電話番号」と呼ばれています。) を符号化する単純な方式を、 PSTN GSTN を基にしたサービスへの電子メイル関門に必要な追加標準属性の符号化を認める拡張機構と共に説明します。

1. Introduction

Since the very first e-mail to PSTN GSTN] services gateway appeared, a number of different methods to specify a PSTN GSTN] address as an e-mail address have been used by implementors. Two major objectives for this were 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.

最初期の電子メイルから PSTN GSTN] サービスへの関門が現れてから、 PSTN GSTN] 番地を電子メイル番地として指定する多くの異なる方式が各実装者により使われています。その2つの大きな目的は、 こうした方式には、電子メイル利用者が、自身の電子メイル界面から GSTN サービスに接続可能とするとか、既存の電子メイル基盤を使用しつつ、ある種の「電子メイル上の GSTN サービス」輸送を可能とし、GSTN 遠距離転送の経費を削減するとかのような幾つかの目的があります。

This memo describes the MINIMAL addressing method to encode PSTN 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 PSTN GSTN] device user to access the e-mail transport service, is not discussed here.

このメモは、 PSTN GSTN] 番地を電子メイル番地に符号化するための最小の番地付け方式と、更なる標準要素を定義できるようにするための標準拡張機構を説明します。 反対の問題、つまり旧来の番号のみの PSTN GSTN] 装置利用者が電子メイル輸送サービスに接続することにはここでは触れません。

All implementations supporting this PSTN GSTN] over e-mail service MUST support as a minimum the specification described in this document. The generic complex case of converting the whole entirety PSTN GSTN] 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 GSTN] サービスに対応するすべての実装は、 この文書で説明する仕様に最小限対応しなければなりません。 PSTN GSTN] 番地付け全体を電子メイルに変換する一般的で複雑な場合はこの最小仕様の適用範囲外です。その領域は作業中であり、数々の標準任意選択拡張が定義されることでしょう。

2. Minimal PSTN GSTN address

The minimal specification of a PSTN GSTN address in within an e-mail address is as follows:

電子メールアドレス中の PSTN GSTN 番地の最小指定は次の通り:

• pstn-address = pstn-mbox [ qualif-type1 ]

• 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.

SP (間隔) は service-selector で認められていないことに注意。 service-selector は大文字・小文字を区別しない文字列として取扱わなければならない。

Specifications 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-address 定義を採用する他の仕様は、 係る特定メッセージ・サービスを識別する唯一な大文字・小文字を区別しない service-selector 要素を定義し、 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 these this minimal requirements specification are allowed to ingnore any other non-minimal extensions address element which can be is 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 keyword では SP (間隔) が認められていないことに注意

• string = PCHAR ; note that printable characters are %x20-7E 印字可能文字は %x20-7E であることに注意

As such, all "pstn-address" extensions elements MUST be defined in the "qualif-type1" form at the time of registration with IANA.

このように、すべての pstn-address 拡張要素は IANA に登録する時点で qualif-type1 形式で定義しなければなりません。

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

An "I-pstn device" has, among its characteristics, a unique Internet domain name which identifies it on the Internet 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. ¶ In Within Internet mail, this is the Right Hand Side (RHS) part of the address, i.e., the part on the right of the "@" sign. We For purposes of this document we will call this "mta-I-pstn"

「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 文字列は、 SMTP 規格 (RFC821, RFC1123) の <domain> 指定の要件に適合しなければなりません。 メッセージ内容頭中で使われる domain 文字列は、 関係する規格 (RFC822, RFC 1123) の要件に適合しなければなりません。

Note: in both cases, the standards permit use of "domain names" or "domain literals" in addresses. 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

The complete structure used to transfer a minimal PSTN GSTN 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 refinements which allows the PSTN GSTN number to be identified.

最小 PSTN GSTN 番地をインターネット電子メイル輸送システムで転送するために使う完全な構造は pstn-email と呼びます。この物体は、 RFC 822 および RFC 1123 の addr-spec 構文に適合する電子メイル番地で、幾らかの余分な構造の細分が PSTN GSTN 番号を識別することを可能としています。

• pstn-email = ["""] ["/"] pstn-address ["/"] ["""] "@" mta-I-pstn

Implementors' note: The optional "/" characters can result from translations from other mail transport services gateways (such as some X.400 gateways), where it is also an optional element 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 関門) からの翻訳で使われることがあります。 実装は任意選択の斜線を受け入れなければなりませんが、 これを生成するべきではありません。関門は、インターネット・メイル番地付けに変換するときにこれを落とすことが認められます。関係する規格は、局所部分 (つまり、 pstn-email の @ 文字の左の部分) 全体を囲む任意選択の「引用」文字を正確にいつ追加しなければならないかを定義しています。

5. Conclusions

This proposal creates a minimal standard encoding for PSTN GSTN addresses within the global e-mail transport system. and It also defines the standard extension mechanism to be used to introduce specific new elements for GSTN addresses.

この提案は、 PSTN GSTN 番地を大域電子メイル輸送システム中で符号化する最小標準符号化を作成し、ます。また、 GSTN 番地のための特定の新しい要素を導入するために使うことができる標準拡張機構を定義しています。

The proposal requires no changes to is consistent with existing e-mail software. Each specific PSTN GSTN service using this proposal MUST define and register with IANA its own "service-selector" specification and MUST define the eventual other "qualif-type1" elements to be supported needed for its minimal addressing specification specific application. An example of such an application is contained in reference [13].

この提案は、既存の電子メイル・ソフトウェアの変更を必要としていません。 この提案を使う各特定 PSTN GSTN サービスはその service-selector 仕様を定義し、 IANA に登録しなければなりませんし、 その最小番地付け仕様応用に対応するための他の必要な qualif-type1 を定義しなければなりません。 例は RFC2304 にあり含まれています。

6. Security Considerations

This document specifies a means by which PSTN GSTN addresses can be encoded into e-mail addresses. As routing of e-mail messages Since e-mail routing is determined by Domain Name System (DNS) information, a successful attack on this service could force the mail path disseminate tampered information, which causes e-mail messages to be diverted via some particular gateway or message transfer agent MTA or Gateway where mail security can be affected by compromised software the security of the software has been compromised.

この文書は、 PSTN GSTN 番地を電子メイル番地に符号化することができる方法を規定しています。 電子メイル・メッセージの経路制御はドメイン名システム (DNS) 情報データにより決定されるので、このサービス DNS への攻撃が成功すると、偽造した情報を広めて、脆弱ソフトウェアによりメイルの安全がおかされている特定の関門やメッセージ転送エージェントソフトウェアの安全が脆くなっている MTA や関門を介してあるメイル経路を強制する電子メイルを横流しされるようにすることができるでしょう。

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 安全機構がより広く用いられるようになれば、クライアントはメイル経路記録の信頼性と完全性を検証するために安全機構を使用するべきです。

7. IANA Considerations

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

      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 はこの雛形で例として使う仮想の新しい service-selector です。
      foo は登録する新しい値に置換えてください。
      ここに新しい値の短い説明を含めます。
      説明は完全な説明のある標準化過程 RFC または場合によっては他の
      標準化団体の文書の参照を含まなければなりません。
      値の使用は独立実装に完全に十分に定義されていなければなりません。

   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)
     新たな service-selector 引数の使用によって導かれる
     追加の安全に関しての考察をここか参照する標準化過程 RFC
     で定義するべきです。

   Person & email address to contact for further information:

      (fill in contact information)

   INFORMATION TO THE SUBMITTER:

      The accepted registrations will be listed in the "Assigned
      Numbers" series of RFCs.  The information in the registration form
      is freely distributable.
      
      受入れられた登録は「割当て番号」系列の RFC に列挙されます。
      登録書式の情報は自由に配布可能です。

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

   qualif-type1 "keyword" name:

      bar

   qualif-type1 "value" ABNF definition:

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

   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.)

   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")

   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)

   Person & email address to contact for further information:

      (fill in contact information)

   INFORMATION TO THE SUBMITTER:

      The accepted registrations will be listed in the "Assigned
      Numbers" series of RFCs.  The information in the registration form
      is freely distributable.

8. Changes from RFC 2303 specification

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

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

   -  an explicit list of "new terms" with explanations was added to
      section 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;

   -  in section 2.1 the use and meaning of "written-sep" was clarified;

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

   -  section 4.1 was updated to clarify how to generate "pstn-email"
      when more than one subaddress is used;

   -  the Author's Address was updated;

   -  the References list was updated to include RFC 2846 and RFC 2434.

7. 9. Author's Address

   Claudio Allocchio
   INFN-GARR
   c/o 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;
           C=it;A=garr;P=garr;S=Allocchio;G=Claudio;
   Phone:  +39 040 3758523
   Fax:    +39 040 3758565

8. 10. References

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

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

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

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

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

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

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

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

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

   [10] ITU E.164 - Numbering plan for the ISDN era; recommendation
        The International Public Telecommunication Numbering Plan
        E.164/I.331 (August 1991 May 1997).

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

   [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).

   [13] Allocchio, C., "Minimal FAX address format in Internet Mail",
        RFC 2304, March 1998 RFC 3192, October 2001..

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

9. Full Copyright Statement

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

全文は RFCのライセンスを参照。

Acknowledgement

License

RFCのライセンス。

メモ