RFC 3191

RFC 3191

Minimal PSTN GSTN address format in Internet Mail インターネット・メイル中の最小 PSTN GSTN 番地書式

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.

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 を基にしたサービスへの電子メイル関門に必要な追加標準属性の符号化を認める拡張機構と共に説明します。

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 を除き、解釈されません。

1. Introduction

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 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 遠距離転送の経費を削減するとかのような幾つかの目的があります。

  • 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 サービスに接続可能とする
  • ある種の「電子メイル上の PSTN サービス」輸送を可能とし、 PSTN 遠距離転送の経費を削減し、既存の電子メイル基盤を使用する

ことです。

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] 装置利用者が電子メイル輸送サービスに接続することにはここでは触れません。

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 登録雛形は「IANA に関して」の章 (この文書の第7章) にあります。

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] 番地付け全体を電子メイルに変換する一般的で複雑な場合はこの最小仕様の適用範囲外です。その領域は作業中であり、数々の標準任意選択拡張が定義されることでしょう。

1.1 Terminology and Syntax conventions

In this document the formal definitions are described using ABNF syntax, as defined into [7]. We will This memo also use some of the "CORE DEFINITIONS" defined in "APPENDIX A - CORE" of that document. The exact meaning of the capitalised words

この文書では、正式な定義は RFC2234 で定義されている ABNF 構文を使って説明します。このメモでは、 RFC 2234 の「附属書 (APPENDIX) A — 中核 (CORE) 」 で定義されている「中核定義 (CORE DEFINITIONS) 」 の幾つかも使います。大文字語

"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"

is defined in reference [6].

の正確な意味は RFC2119 で定義されています。

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;

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 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 (間隔) が認められていないことに注意

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 形式で定義しなければなりません

2.1 Minimal "global-phone" definition

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

global-phone 要素の目的は、標準 E.164 数値番地を電子メイル仕様書 RFC821, RFC822 の標準電子メイル指定に適合する電子メイル番地付け構文で表現することです。

We now define the The minimal supported syntax for global-phone element is as follows:

いま、 global-phone 要素の最小対応構文を次のように定義します:

  • global-phone = "+" 1*( DIGIT , / written-sep )
  • written-sep = ( "-" / "." )

The use of other dialling schemas for PSTN GSTN] numbers (like private numbering plans or local dialling conventions) is also allowed. However, this does not preclude nor remove the minimal compulsory mandatory requirement to for support to the "global-phone" syntax as defined above within the minimal GSTN address format.

PSTN GSTN] の他のダイヤル方式 (私的番号付け計画や局所ダイヤル記法など) の使用も認めます。しかし、これは上で定義した、最小 GSTN 番地書式中の global-phone 構文に対応するという最小義務強制要件を除外も削除もしません。

Any non "global-phone" other dialling schema MUST NOT use the leading "+" defined here between the "=" sign and the dialling string. The "+" sign is strictly reserved for the standard "global-phone" syntax.

いかなるglobal-phone 他のダイヤル方式も、ここで定義した = 記号とダイヤル文字列の間に先導 + を使ってはなりません+ 記号は、標準 global-phone 構文のために厳格に予約します。

Note: The specification of these different alternate 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 電子メイル番地の利用者指定は、数字その他のダイヤル要素の間に分離子を挿入することができると促進されます。 この理由から、 written-sep 要素を構文で認めています。

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 電子メイル番地の人間可読性の向上のために written-sep 要素を使うことも認めています。 written-sep は数字などのダイヤル要素の間に置くことのできる要素です。

Implementors' note: Use of the written-sep elements is allowed, but not recommended for transmission. 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.

実装者に注意: written-sep 要素の使用は認められていますが、転送には推奨されていません。 pstn-mbox 内の written-sep 要素の出現を、すべての適合実装が無視しなければなりません利用者エージェントは、メッセージメッセージ転送システム提出する前に written-sep 要素を削除するべきです

2.2 Some examples of a minimal "pstn-address" The minimal "pstn-address" examples

  • VOICE=+3940226338
  • FAX=+12027653000/T33S=6377
  • SMS=+33-1-88335215

Note: these examples are given as illustrations only; they do not necessarily represent valid pstn-addresses.

注意: これらの例は、単なる例です。必ずしも妥当な pstn-address ではありません。

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@ 文字の左の部分) 全体を囲む任意選択の「引用」文字を正確にいつ追加しなければならないかを定義しています。

It is essential to remind that "pstn-address" element MUST strictly follow the "quoting rules" spcified in the relevant standards [2], [3].

pstn-address 要素が関係する規格で規定された 「引用規則」に厳密に従わなければならないことを頭に入れておくことが重要です。

4.1 Multiple subaddresses

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 要素を使います。

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. 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 応用には、複数の部分番地を使う実現値があります。 他方電子メイルの慣習では、各受信者に常に別々の固有の電子メイル番地を使います。 特定の GSTN サービスが (その GSTN サービスの規格仕様で定義された任意の書式で) 同じ pstn-mbox に関連付けられた複数の部分番地を必要とするときには、複数の pstn-email 要素を使用することが必要です

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

実装者に注意: UA は同じ global-phone に複数の部分番地要素を受け入れることができますても構いませんが、 UA は MTA にメッセージを渡す提出する時には複数の pstn-mbox 要素を生成しなければなりません

4.2 Some examples of minimal "pstn-email" addresses

Some examples of minimal pstn-email addresses follows:

最小 pstn-email 番地の例を幾つか次に挙げます:

  • VOICE=+3940226338@worldvoice.com
  • FAX=+1.202.7653000/T33S=6377@faxserv.org
  • /SMS=+33-1-88335215/@telecom.com

Note: these examples are given as illustrations only; they do not necessarily represent valid pstn-addresses.

注意: これらの例は単なる例です。必ずしも妥当な pstn-address ではありません。

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

As the service-selector and qualif-type1 elements values are extensible, they MUST be registered with IANA.

service-selector 要素および 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]:

service-selector または qualif-type1 の値を登録するためには、7.1 および 7.2 の登録書式雛形を使わなければなりません。 新しい登録は RFC2434 2章で定義された「仕様書が必要」適合条件を満たさなければなりません

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

仕様書が必要
値とその意味は、 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 は、上で定義した仕様書で補充されていない登録ならびに7.1および7.2の雛形書式に従って完全に記述されていない登録を受入れてはなりません。 新しい登録を受入れるのに更に相談が必要な場合は、 IANA は適当な「専門家」の個人または IETF 作業部会の指示を受けるべく応用領域長を指すべきです

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 を含みます。) は RFC2846 にあるものを更新します。

7.1 IANA Registration form template for new values of GSTN address service-selector

   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 に列挙されます。
      登録書式の情報は自由に配布可能です。

7.2 IANA Registration form template for new values of GSTN address qualif-type1 keyword and value

   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.

]INS]

* 8. Changes from RFC 2303 specification

> Although there are no technical or major changes from RFC 2303
specification, this section briefly describes where updates and
clarifications were introduced:

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

]INS]

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

[15] Allocchio, C. "GSTN address element extensions in e-mail services", RFC 2846, June 2000.

[16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society.

メモ