#?SuikaWiki/0.9
'''Minimal [DEL[PSTN]] [INS[GSTN]] address format in Internet Mail [INS[インターネット・メイル中の最小 [DEL[PSTN]] [INS[GSTN]] 番地書式]]'''
-Network Working Group                                     
-Request for Comments: [DEL[2303]] [INS[3191]]
-[INS[Obsoletes: 2303]]
-[INS[Updates: 2846]]
-Category: Standards Track                                   
- C. Allocchio
- GARR-Italy
- [DEL[March 1998]] [INS[October 2001]]

*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 ([DEL[1998]] [INS[2001]]).  All Rights Reserved.

*[DEL[IESG NOTE]] [INS[Abstract]]
> This memo describes a simple method of encoding [DEL[PSTN]] [INS[Global Switched Telephone Network (GSTN)]] addresses [INS[(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 [DEL[PSTN-based]] [INS[GSTN-based]] services.

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

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

* 1. Introduction
[INS[
> 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 を除き、解釈されません。
]INS]

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

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

[DEL[
>
- 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 遠距離転送の経費を削減し、既存の電子メイル基盤を使用する

ことです。
]DEL]

> This memo describes the MINIMAL addressing method to encode [DEL[PSTN]] [INS[GSTN]
addresses into e-mail addresses and the standard extension mechanism
to allow definition of further standard elements. The opposite
problem, i.e.[INS[,]] to allow a traditional numeric-only [DEL[PSTN]] [INS[GSTN] device user to
access the e-mail transport service, is not discussed here.

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

[INS[
> 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章) にあります。
]INS]

> All implementations supporting this [DEL[PSTN]] [INS[GSTN] over e-mail service MUST
support as a minimum the specification described in this document.
The generic complex case of converting the [DEL[whole]] [INS[entirety]] [DEL[PSTN]] [INS[GSTN] addressing into
e-mail is out of scope in this minimal specification[DEL[: there is some work in progress in the field, where also a number of standard optional extensions are being defined]].

この電子メイル上の [DEL[PSTN]] [INS[GSTN] サービスに対応するすべての実装は、
この文書で説明する仕様に最小限対応しなければ'''なりません'''。 [DEL[PSTN]] [INS[GSTN] 番地付け全体を電子メイルに変換する一般的で複雑な場合はこの最小仕様の適用範囲外です。[DEL[その領域は作業中であり、数々の標準任意選択拡張が定義されることでしょう。]]

** [INS[1.1 Terminology and Syntax conventions]]

> In this document the formal definitions are described using ABNF
syntax, as defined into [7]. [DEL[We will]] [INS[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]]
構文を使って説明します。[INS[このメモでは、]] RFC 2234 の「[RUBYB[附属書] [APPENDIX]] A ― [RUBYB[中核] [CORE]]」
で定義されている「[RUBYB[中核定義] [CORE DEFINITIONS]]」
の幾つかも使います。大文字語

>> "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED",  "MAY", "OPTIONAL"
> is defined in reference [6].

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

[INS[
> 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 番地をインターネット電子メイル・サービス上で輸送するために使用する完全インターネット電子メイル構造。
]INS]

*2. Minimal [DEL[PSTN]] [INS[GSTN] address
> The minimal specification of a [DEL[PSTN]] [INS[GSTN] address [DEL[in]] [INS[within an]] e-mail address is as follows:

[DEL[PSTN]] [INS[GSTN] 番地の電子メイル番地での最小仕様は次の通り:

>
- pstn-address = pstn-mbox  [ qualif-type1 ]
>
- pstn-mbox = service-selector "=" global-phone
>
- service-selector = 1*( DIGIT / ALPHA / "-" )
[PRE[
                         ; note that SP (space) is not allowed in
                         ; service-selector.
                         ; service-selector MUST be handled as a case
                         ; INSENSITIVE string by implementations.
]PRE]

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

> [DEL[Specifications]] [INS[Other specifications]] adopting the "pstn-address" definition MUST define [INS[and register with IANA]] a
unique case insensitive "service-selector" element to identify the
specific messaging service involved.

[CODE(ABNF)[pstn-address]] 定義を採用する[INS[他の]]仕様は、
係る特定メッセージ・サービスを識別する唯一な大文字・小文字を区別しない
[CODE(ABNF)[service-selector]] 要素を定義し[INS[、 IANA に登録し]]なければ'''なりません'''。

> These specifications [INS[and registrations]] MUST also define which minimal "qualif-type1"
extensions, if any, MUST be supported for the specified [INS[messaging]] service.

その仕様[INS[と登録]]は、最小 [CODE(ABNF)[qualif-type1]] 拡張があるなら、
特定[INS[メッセージ・]]サービスについてどの拡張に対応しなければ'''ならない'''かも定義しなければ'''なりません'''。

> Implementations confirming to [DEL[these]] [INS[this]] minimal requirements
specification are allowed to i[DEL[n]]gnore any other non-minimal extensions
address element which [DEL[can be]] [INS[is]] present in the "pstn-address". However,
conforming implementations MUST preserve all "qualif-type1" address
elements they receive.

その最小要件仕様に沿った実装は、 [CODE(ABNF)[pstn-address]]
に現れ[DEL[得]]る他の非最小拡張番地要素を無視することが認められます。
しかし、そのような実装は、受信したすべての [CODE(ABNF)[qualif-type1]]
番地を保持しなければ'''なりません'''。

> The generic "qualif-type1" element is defined as:

一般 [CODE(ABNF)[qualif-type1]] 要素は次の通り定義します:

>
- qualif-type1 = "/" keyword "=" string
>
- keyword = 1*( DIGIT / ALPHA / "-" )
; note that SP (space) is not allowed in keyword [INS[[CODE(ABNF)[keyword]] では [CODE(ABNF)[SP]] (間隔) が認められていないことに注意]]
>
- string = PCHAR
; note that printable characters are %x20-7E [INS[[[印字可能文字]]は [CODE(ABNF)[%x20-7E]] であることに注意]]

> As such, all "pstn-address" extension[DEL[s]] elements MUST be defined in
the "qualif-type1" form [INS[at the time of registration with IANA]].

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

** 2.1 Minimal "global-phone" definition

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

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

> [DEL[We now define the]] [INS[The]] minimal supported syntax for global-phone [INS[element is as follows]]:

[DEL[いま、]] [CODE(ABNF)[global-phone]] [INS[要素]]の最小対応構文を次のように定義します:

>
-      global-phone = "+" 1*( DIGIT [DEL[,]] [INS[/]] written-sep )
>
-      written-sep = ( "-" / "." )

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

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

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

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

> Note:
The specification of [DEL[these different]] [INS[alternate]] dialling schemas is out of
scope for this minimal specification.

注意: [DEL[そのような異なる]][INS[代替]]ダイヤル方式の仕様はこの最小仕様の適用範囲外です。

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

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

> Implementors' note:
Use of the written-sep elements is allowed, but not recommended [INS[for transmission]].
Any occurences of written-sep elements in a pstn-mbox MUST be
ignored by all conformant implementations. [DEL[User Agents SHOULD remove written-sep elements before submitting messages to the Message Transport System.]]

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

**2.2 [DEL[Some examples of a minimal "pstn-address"]] [INS[The minimal "pstn-address" examples]]
>
-      VOICE=+3940226338
-      FAX=+12027653000/T33S=6377
-      SMS=+33-1-88335215

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

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

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

「I‐pstn 装置」は[DEL[電子メイル番地、より正確にはメイル・システムが大域電子メイル・システムでその装置を識別することができる名前]][INS[その性質上、インターネット上でその装置を識別する唯一インターネット・ドメイン名]]を持っています。 [DEL[¶]] インターネット・メイルでは、これは番地の右側部分 (RHS),
つまり [CODE[@]] 記号の右側の部分です。[INS[この文書の目的のためには]]これを [CODE(ABNF)[mta-I-pstn]] と呼ぶことにします。

>
-      mta-I-pstn = domain

> For "domain" strings used in SMTP transmissions, the string MUST
conform to the requirements of that standard[DEL[']]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 転送で使われる [CODE(ABNF)[domain]] 文字列は、
SMTP 規格 ([[RFC821]], [[RFC1123]]) の [CODE(ABNF)[<[[domain]]>]] 指定の要件に適合しなければ'''なりません'''。
メッセージ内容頭中で使われる [CODE(ABNF)[domain]] 文字列は、
関係する規格 ([[RFC822]], RFC 1123) の要件に適合しなければ'''なりません'''。

> Note: [DEL[in both cases, the standards permit use of "domain names" or "domain literals" in addresses.]] [INS[the use of "domain names" or "domain literals" is permitted in addresses in both the SMTP envelope and message header fields.]]

注意: [DEL[いずれの場合]] [INS[SMTP [[封筒]]でもメッセージ[[頭欄]]]]でも、規格は番地中で「[[ドメイン名]]」または
「[[ドメイン表記]]」の使用を認めています。

*4. The pstn-email
> The complete structure used to transfer a minimal [DEL[PSTN]] [INS[GSTN]] address over
the Internet e-mail transport system is called "pstn-email". This
object is a an e-mail address which conforms to [DEL[RFC822]] [2] and [DEL[RFC1123]] [3] "addr-spec" syntax, with [DEL[some extra]] structure [INS[refinements]] which
allows the [DEL[PSTN]] [INS[GSTN]] number to be identified.

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

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

> Implementors' note:
The optional "/" characters can result from [INS[translations from]] other [DEL[mail]] transport [DEL[services]] gateways [INS[(such as some X.400 gateways)]][DEL[, where it is also an optional element]] [INS[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. [INS[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.]]

実装者に注意: 任意選択の [CODE(char)[/]] 文字は、[DEL[やはり]] [INS[[CODE(char)[/]] を]]任意選択要素として[INS[含む]]他の[DEL[メイル]]輸送[DEL[サービス]]関門 [INS[(例えば [[X.400]] 関門) からの翻訳]]で使われることがあります。
実装は任意選択の斜線を受け入れなければ'''なりません'''が、
これを生成する'''べきではありません'''。関門は、インターネット・メイル番地付けに変換するときにこれを落とすことが認められます。[INS[関係する規格は、局所部分 (つまり、 [CODE(ABNF)[pstn-email]] の [CODE(char)[@]] 文字の左の部分) 全体を囲む任意選択の「引用」文字を正確にいつ追加しなければ'''ならない'''かを定義しています。]]

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

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

**4.1 Multiple subaddresses
[DEL[
> 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.

特定サービスが (そのサービスの特定規格仕様で定義されている任意の書式で) 
複数の部分番地を必要としている場合で、その部分番地を同じ [CODE(ABNF)[pstn-mbox]]
に与える必要がある時には、複数の [CODE(ABNF)[pstn-email]]
要素を使います。
]DEL]

[INS[
> 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 サービスの規格仕様で定義された任意の書式で) 同じ [CODE(ABNF)[pstn-mbox]] に関連付けられた複数の部分番地を必要とするときには、複数の [CODE(ABNF)[pstn-email]] 要素を使用することが'''必要です'''。
]INS]

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

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

** 4.2 Some examples of [INS[minimal]] "pstn-email" [INS[addresses]]
[INS[
> Some examples of minimal pstn-email addresses follows:

最小 [CODE(ABNF)[pstn-email]] 番地の例を幾つか次に挙げます:
]INS]

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

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

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

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

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

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

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

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

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

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

* [INS[7. IANA Considerations]]
[INS[
> As the service-selector and qualif-type1 elements values are
extensible, they MUST be registered with IANA.

[CODE(ABNF)[service-selector]] 要素および [CODE(ABNF)[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]:

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

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

   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[受入れられた登録は「割当て番号」系列の RFC に列挙されます。]]
      [INS[登録書式の情報は自由に配布可能です。]]
]PRE]

** 7.2 IANA Registration form template for new values of GSTN address qualif-type1 keyword and value
[PRE[
   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]

* [INS[8. Changes from RFC 2303 specification]]
[INS[
> 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]

* [DEL[7.]] [INS[9.]] Author's Address
>
[PRE[
   Claudio Allocchio
   [INS[INFN-GARR]]
   [INS[c/o]] Sincrotrone Trieste
   SS 14 Km 163.5 Basovizza
   I 34012 Trieste
   Italy

   RFC822: Claudio.Allocchio@elettra.trieste.it
   X.400:  [DEL[C=it;A=garr;P=Trieste;O=Elettra;S=Allocchio;G=Claudio;]]
           [INS[C=it;A=garr;P=garr;S=Allocchio;G=Claudio;]]
   Phone:  +39 [INS[0]]40 3758523
   Fax:    +39 [INS[0]]40 3758565
]PRE]

* [DEL[8.]] [INS[10.]] References
[PRE[
   [1]  Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
        August 1982.

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

   [3]  Braden, R., "Requirements for Internet hosts - application and
        support", [INS[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", [INS[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)[INS[.]]

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

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

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

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

   [13] Allocchio, C., "Minimal FAX address format in Internet Mail",
        [DEL[RFC 2304, March 1998]] [INS[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.
]PRE]

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

* [DEL[9.]]  Full Copyright Statement
> Copyright (C) The Internet Society ([DEL[1998]] [INS[2001]]).  All Rights Reserved.

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

*[INS[Acknowledgement]]
[INS[
> Funding for the RFC Editor function is currently provided by the
Internet Society.
]INS]

* メモ