この文書はRFC3696の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group J. Klensin
Request for Comments: 3696 February 2004
Category: Informational
Application Techniques for Checking and Transformation of Names
名前の検査と変換のアプリケーション技法
Status of this Memo
この文書の状態
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
このメモはインターネット共同体のための情報を供給します。これはインター
ネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
概要
Many Internet applications have been designed to deduce top-level
domains (or other domain name labels) from partial information. The
introduction of new top-level domains, especially non-country-code
ones, has exposed flaws in some of the methods used by these
applications. These flaws make it more difficult, or impossible, for
users of the applications to access the full Internet. This memo
discusses some of the techniques that have been used and gives some
guidance for minimizing their negative impact as the domain name
environment evolves. This document draws summaries of the applicable
rules together in one place and supplies references to the actual
standards.
多くのインターネットアプリケーションが部分的情報から最上位ドメイン
（あるいは他のドメイン名ラベル）を推論するよう意図されました。新しい
最上位ドメイン、特に非国コード、の導入はこれらのアプリケーションの使
う技法のある欠陥をあばきました。これらの欠陥は、アプリケーションのユー
ザの完全なインターネットアクセスをより難しくするか、あるいは不可能に
します。この文書では使われた技法のいくつかを論じ、そしてドメイン名環
境が進展する時の打撃的な影響を最小にするためのあるガイドラインを与え
ます。この文書はアプリケーション規則のまとめを１箇所で行い、実際の標
準の参照を供給します。
Table of Contents
目次
1. Introduction
1. はじめに
2. Restrictions on domain (DNS) names
2. ドメイン（ＤＮＳ）名の制限
3. Restrictions on email addresses
3. 電子メールアドレスの制限
4. URLs and URIs
4. ＵＲＬとＵＲＩ
4.1. URI syntax definitions and issues
4.1. ＵＲＩ構文定義と問題
4.2. The HTTP URL
4.2. ＨＴＴＰ ＵＲＬ
4.3. The MAILTO URL
4.3. ＭＡＩＬＴＯ ＵＲＬ
4.4. Guessing domain names in web contexts
4.4. ウェブ環境でのドメイン名推測
5. Implications of internationalization
5. 国際化の意味
6. Summary
6. 要約
7. Security Considerations
7. セキュリティの考察
8. Acknowledgements
8. 謝辞
9. References
9. 参考文献
9.1. Normative References
9.1. 参照する参考文献
9.2. Informative References
9.2. 有益な参考文献
10. Author's Address
10. 著者のアドレス
11. Full Copyright Statement
11. 著作権表示全文
1. Introduction
1. はじめに
Designers of user interfaces to Internet applications have often
found it useful to examine user-provided values for validity before
passing them to the Internet tools themselves. This type of test,
most commonly involving syntax checks or application of other rules
to domain names, email addresses, or "web addresses" (URLs or,
occasionally, extended URI forms (see Section 4)) may enable better-
quality diagnostics for the user than might be available from the
protocol itself. Local validity tests on values are also thought to
improve the efficiency of back-office processing programs and to
reduce the load on the protocols themselves. Certainly, they are
consistent with the well-established principle that it is better to
detect errors as early as possible.
インターネットアプリケーションのユーザーインタフェースの設計者は、し
ばしば、インターネットツールに渡す前にユーザの供給した値の正当性を調
べることが有用であることを見いだしました。この種の検査、一般的にはド
メイン名や電子メールアドレスや「ウェブアドレス」（ＵＲＬや、時折、拡
張されたＵＲＩ形式（４章参照））の文法検査やアプリケーションの他の規
則は、プロトコル自信が可能なものより、ユーザのためのより良い品質の診
断を可能にするかもしれません。値に対するローカル適合検査は後方部門処
理プログラムの効率を改善し、プロトコル自身の負荷を減らすと思われます。
確かに、これらは、可能な限り早くエラーを検出することがより良い、とい
う確立した原則と一致しています。
The tests must, however, be made correctly or at least safely. If
criteria are applied that do not match the protocols, users will be
inconvenienced, addresses and sites will effectively become
inaccessible to some groups, and business and communications
opportunities will be lost. Experience in recent years indicates
that syntax tests are often performed incorrectly and that tests for
top-level domain names are applied using obsolete lists and
conventions. We assume that most of these incorrect tests are the
result of the inability to conveniently locate exact definitions for
the criteria to be applied. This document draws summaries of the
applicable rules together in one place and supplies references to the
actual standards. It does not add anything to those standards; it
merely draws the information together into a form that may be more
accessible.
しかし検査は、正確に、少なくとも安全にされなくてはなりません。もしプ
ロトコルに整合しない基準が適用されるなら、ユーザに迷惑をかけ、アドレ
スとサイトがあるグループで効率的にアクセスできなくなり、ビジネスと通
信機会が失われるでしょう。最近の経験は、構文検査がしばしば間違って行
われ、そして最上位ドメイン名の検査で時代遅れのリストと慣習を使った検
査が適用されていることを示します。我々はこれらの正しくないテストの大
部分は、適用に適切な基準の正確な定義を突き止める能力がない結果である
と想定します。この文書は適用される規則を要約し、実際の標準への参照を
供給します。これは標準に何も加えません；これはただ情報をよりアクセス
可能な形式にします。
Many experts on Internet protocols believe that tests and rules of
these sorts should be avoided in applications and that the tests in
the protocols and back-office systems should be relied on instead.
Certainly implementations of the protocols cannot assume that the
data passed to them will be valid. Unless the standards specify
particular behavior, this document takes no position on whether or
not the testing is desirable. It only identifies the correct tests
to be made if tests are to be applied.
インターネットプロトコルの多くの専門家が、これらの種類の検査と規則は
アプリケーションで避けるべきで、プロトコルと後方部門システムでのテス
トに頼るべきと信じます。確かにプロトコルの実装は手渡されたデータが正
当であろうと想定することができません。標準が特定の行動を指定しないな
ら、この文書は、検査が望ましいかどうかについて、中立です。これはただ、
もし検査をする場合に、行うべき正しい検査を認識するだけです。
The sections that follow discuss domain names, email addresses, and
URLs.
以下の章はドメイン名と電子メールアドレスとＵＲＬを論じます。
2. Restrictions on domain (DNS) names
2. ドメイン（ＤＮＳ）名の制限
The authoritative definitions of the format and syntax of domain
names appear in RFCs 1035 [RFC1035], 1123 [RFC1123], and 2181
[RFC2181].
フォーマットの正式な定義とドメイン名の構文はＲＦＣ１０３５[RFC1035]
とＲＦＣ１１２３[RFC1123]とＲＦＣ２１８１[RFC2181]に現われます。
Any characters, or combination of bits (as octets), are permitted in
DNS names. However, there is a preferred form that is required by
most applications. This preferred form has been the only one
permitted in the names of top-level domains, or TLDs. In general, it
is also the only form permitted in most second-level names registered
in TLDs, although some names that are normally not seen by users obey
other rules. It derives from the original ARPANET rules for the
naming of hosts (i.e., the "hostname" rule) and is perhaps better
described as the "LDH rule", after the characters that it permits.
The LDH rule, as updated, provides that the labels (words or strings
separated by periods) that make up a domain name must consist of only
the ASCII [ASCII] alphabetic and numeric characters, plus the hyphen.
No other symbols or punctuation characters are permitted, nor is
blank space. If the hyphen is used, it is not permitted to appear at
either the beginning or end of a label. There is an additional rule
that essentially requires that top-level domain names not be all-
numeric.
どんな文字やビット（オクテットとして）の組合せがＤＮＳ名で認められま
す。しかしながら、たいていのアプリケーションで必要とされる望ましい形
式があります。この望ましい形式は最上位ドメインやＴＬＤの名前で認めら
れる唯一のものでした。通常ユーザに見られないある名前が他の規則に従う
が、一般にたいていのＴＬＤの第２レベルで名前登録が認められる唯一の形
式です。これはオリジナルのＡＲＰＡＮＥＴ規則のホスト命名から生じ（す
なわち「ホスト名」規則）、そして許された文字は「ＬＤＨ規則」として記
述されます。更新されたＬＤＨ規則は、ドメイン名のラベル（ピリオドで分
割された単語あるいは文字列）がＡＳＣＩＩ[ASCII]アルファベットと数字文
字とハイフンだけから成り立たなければならないことを規定します。他の記
号や句読点文字が認められず、スペースも同様です。もしハイフンが使われ
るなら、それは初めやラベルの終わりで現われるのを許されません。本質的
に最上位ドメイン名は全て数字ではないことを要求する追加規則があります。
When it is necessary to express labels with non-character octets, or
to embed periods within labels, there is a mechanism for keying them
in that utilizes an escape sequence. RFC 1035 [RFC1035] should be
consulted if that mechanism is needed (most common applications,
including email and the Web, will generally not permit those escaped
strings). A special encoding is now available for non-ASCII
characters, see the brief discussion in Section 5.
非文字オクテットをラベルで表現する時や、ラベル内にピリオドを埋め込む
必要がある時、エスケープ・シーケンスを利用して入力するメカニズムがあ
ります。もしそのメカニズムが必要なら、ＲＦＣ１０３５[RFC1035]を調べ
るべきです（電子メールとウェブを含め、たいていの一般的アプリケーショ
ンが、一般にエスケープ文字列を許可しないでしょう）。特別なコーディン
グが今非ＡＳＣＩＩ文字で利用可能です、５章の短い議論を見てください。
Most internet applications that reference other hosts or systems
assume they will be supplied with "fully-qualified" domain names,
i.e., ones that include all of the labels leading to the root,
including the TLD name. Those fully-qualified domain names are then
passed to either the domain name resolution protocol itself or to the
remote systems. Consequently, purported DNS names to be used in
applications and to locate resources generally must contain at least
one period (".") character. Those that do not are either invalid or
require the application to supply additional information. Of course,
this principle does not apply when the purpose of the application is
to process or query TLD names themselves. The DNS specification also
permits a trailing period to be used to denote the root, e.g.,
"a.b.c" and "a.b.c." are equivalent, but the latter is more explicit
and is required to be accepted by applications. This convention is
especially important when a TLD name is being referred to directly.
For example, while ".COM" has become the popular terminology for
referring to that top-level domain, "COM." would be strictly and
technically correct in talking about the DNS, since it shows that
"COM" is a top-level domain name.
他のホストやシステムを参照するたいていのインターネットアプリケーショ
ンは「完全指定」ドメイン名、すなわち、ＴＬＤ名を含めルートまでの全て
のラベルを含むもの、が供給されると想定します。それらの完全指定ドメイ
ン名は、遠隔システムか、ドメイン名解決プロトコルに手渡されます。従っ
て、アプリケーションで使われ、一般に資源の場所を突き止めるためのＤＮ
Ｓ名が少なくとも１つのピリオド(".")文字を含んでいなくてはなりません。
ピリオドがなければ、無効か、アプリケーションに追加情報の供給を要求し
ます。もちろんこの原則は、アプリケーションの目的がＴＬＤ名を処理する
か、問合せる際には適用されません。ＤＮＳ仕様はルートを示す末尾のピリ
オドを許し、例えば"a.b.c"と"a.b.c."は等価で、後者はよりより明確で、ア
プリケーションが受け入れるように要求されます。この習慣は、ＴＬＤ名が
直接参照されている時に、特に重要です。例えば、".COM"は最上位ドメイン
を言うのに広く使われる用語であるが、"COM"が最上位ドメインなので、
"COM."がＤＮＳで言う場合に厳密に技術的に正しいいでしょう。
There is a long history of applications moving beyond the "one or
more periods" test in an attempt to verify that a valid TLD name is
actually present. They have done this either by applying some
heuristics to the form of the name or by consulting a local list of
valid names. The historical heuristics are no longer effective. If
one is to keep a local list, much more effort must be devoted to
keeping it up-to-date than was the case several years ago.
「１つ以上のピリオド」試験以上に、正当なＴＬＤ名が実際に存在している
ことを確かめる試みの、アプリケーションの長い歴史があります。それらは
名前形式にヒューリスティックな手法を適用するか、正当な名前のローカル
リストを調べることでします。歴史的なヒューリスティックはもう効果的で
はありません。もしローカルリストを保持するなら、最新状態に維持するた
めに、数年前より多くの努力が必要に違いありません。
The heuristics were based on the observation that, since the DNS was
first deployed, all top-level domain names were two, three, or four
characters in length. All two-character names were associated with
"country code" domains, with the specific labels (with a few early
exceptions) drawn from the ISO list of codes for countries and
similar entities [IS3166]. The three-letter names were "generic"
TLDs, whose function was not country-specific, and there was exactly
one four-letter TLD, the infrastructure domain "ARPA." [RFC1591].
However, these length-dependent rules were conventions, rather than
anything on which the protocols depended.
ヒューリスティックは、ＤＮＳが最初に実装されてから、すべての最上位ド
メイン名の長さが２文字か３文字か４文字であるという観察に基づきます。
すべての２文字の名前は、（初期の少数の例外以外は）ＩＳＯの国と類似の
項目のコードのリスト[IS3166]からの「国コード」ドメインです。３文字名
はその機能が国固有でない「一般」ＴＬＤで、４文字ＴＬＤは正確に１つ、
基礎構造ドメイン"ARPA."があります[RFC1591]。しかしながら、これらの長
さに依存する規則は、プロトコルの事情ではなく、習慣でした。
Before the mid-1990s, lists of valid top-level domain names changed
infrequently. New country codes were gradually, and then more
rapidly, added as the Internet expanded, but the list of generic
domains did not change at all between the establishment of the "INT."
domain in 1988 and ICANN's allocation of new generic TLDs in 2000.
Some application developers responded by assuming that any two-letter
domain name could be valid as a TLD, but the list of generic TLDs was
fixed and could be kept locally and tested. Several of these
assumptions changed as ICANN started to allocate new top-level
domains: one two-letter domain that does not appear in the ISO 3166-1
table [ISO.3166.1988] was tentatively approved, and new domains were
created with three, four, and even six letter codes.
１９９０年代中ごろまで、正当な最上位ドメイン名のリストの変化は稀でし
た。インターネットの拡大に従って追加された新しい国コードは次第にそし
て加速的に追加されましたが、１９８８年の"INT."の設立からＩＣＡＮＮが
２０００年に新しい一般ＴＬＤを追加するまで、一般ドメインのリストは変
りませんでした。あるアプリケーション開発者は任意の２文字ドメイン名は
ＴＬＤとして正しいが、一般ＴＬＤのリストは固定でローカルに維持と検査
できると想定しました。これらの仮定のいくつかは、ＩＣＡＮＮが新しい最
上位ドメインを割り当て始めた時に変化しました：ＩＳＯ３１６６-１表
[ISO.3166.1988]に現われない１つの２文字のドメインが試験的に認められ、
新しいドメインが３文字と４文字と、６文字でも作られました。
As of the first quarter of 2003, the list of valid, non-country,
top-level domains was .AERO, .BIZ, .COM, .COOP, .EDU, .GOV, .INFO,
.INT, .MIL, .MUSEUM, .NAME, .NET, .ORG, .PRO, and .ARPA. ICANN is
expected to expand that list at regular intervals, so the list that
appears here should not be used in testing. Instead, systems that
filter by testing top-level domain names should regularly update
their local tables of TLDs (both "generic" and country-code-related)
by polling the list published by IANA [DomainList]. It is
likely that the better strategy has now become to make the "at least
one period" test, to verify LDH conformance (including verification
that the apparent TLD name is not all-numeric), and then to use the
DNS to determine domain name validity, rather than trying to maintain
a local list of valid TLD names.
２００３年の第１四半期の時点で正当な国コードでない最上位ドメインのリ
ストは.AEROと.BIZと.COMと.COOPと.EDUと.GOVと.INFOと.INTと.MILと
.MUSEUMと.NAMEと.NETと.ORGと.PROと.ARPAでした。ＩＣＡＮＮは一定間隔で
そのリストを拡大することを期待され、それで存在リストを検査で使うべき
ではありません。その代わりに、最上位ドメイン名の試験でフィルタするシ
ステムが、規則的にＩＡＮＡの公表したリスト[DomainList]を調べることで、
（共に「一般」と国コード関連の）ＴＬＤのローカルなテーブルを更新する
べきです。よい戦略は、「少なくとも１つのピリオド」検査をし、（ＴＬＤ
名が全て数字でないことの検査を含め）ＬＤＨ適合を検査し、そして次に、
ＴＬＤ検査のためのローカルリストを維持するのではなく、ドメイン名の正
当性を決定するためにＤＮＳを使うことです。
A DNS label may be no more than 63 octets long. This is in the form
actually stored; if a non-ASCII label is converted to encoded
"punycode" form (see Section 5), the length of that form may restrict
the number of actual characters (in the original character set) that
can be accommodated. A complete, fully-qualified, domain name must
not exceed 255 octets.
ＤＮＳラベルは６３オクテット以下かもしれません。これは実際に保管され
る形にあります；もし非ＡＳＣＩＩラベルがコード化された「プニコード」
形式（５章参照）に変換されるなら、その形式の長さは受入れできる実際の
（元の文字セットでの）文字数を限定するかもしれません。完全で、完全指
定された、ドメイン名が２５５のオクテットを超えてはなりません。
Some additional mechanisms for guessing correct domain names when
incomplete information is provided have been developed for use with
the web and are discussed in Section 4.4.
不完全な情報が供給される時、ある正しいドメイン名を推測するための追加
のメカニズムが、ウェブで使用のために開発され、４.４章で論じられます。
3. Restrictions on email addresses
3. 電子メールアドレスの制限
Reference documents: RFC 2821 [RFC2821] and RFC 2822 [RFC2822]
参照文書：ＲＦＣ２８２１[RFC2821]とＲＦＣ２８２２[RFC2822]。
Contemporary email addresses consist of a "local part" separated from
a "domain part" (a fully-qualified domain name) by an at-sign ("@").
The syntax of the domain part corresponds to that in the previous
section. The concerns identified in that section about filtering and
lists of names apply to the domain names used in an email context as
well. The domain name can also be replaced by an IP address in
square brackets, but that form is strongly discouraged except for
testing and troubleshooting purposes.
現代の電子メールアドレスはアットマーク("@")で分離された、「ローカル
部分」と「ドメイン部分」（完全指定ドメイン名）から成り立ちます。ドメ
イン部の構文は前の章のに対応します。前の章で示したのドメイン名に適用
するフィルタと名前リストの懸念は、電子メールでも当てはまります。ドメ
イン名は角カッコでＩＰアドレスに置き換えできます、しかしその形式は試
験と修理の目的以外には薦められません。
The local part may appear using the quoting conventions described
below. The quoted forms are rarely used in practice, but are
required for some legitimate purposes. Hence, they should not be
rejected in filtering routines but, should instead be passed to the
email system for evaluation by the destination host.
ローカル部は下記の引用で現われるかもしれません。引用形式は実際はめっ
たに使われませんが、ある正しい目的で必要とされます。それ故に、フィル
タルーチンで拒絶ぜず、宛先ホストでの評価のために電子メールシステムに
渡されるべきです。
The exact rule is that any ASCII character, including control
characters, may appear quoted, or in a quoted string. When quoting
is needed, the backslash character is used to quote the following
character. For example
正確な規則は制御文字を含む任意のＡＳＣＩＩ文字が、引用や引用文字列で
現われるかもしれないということです。引用が必要な時、バックスラッシュ
文字は次の文字を引用するために使われます。例えば、
Abc\@def@example.com
is a valid form of an email address. Blank spaces may also appear,
as in
は電子メールアドレスの正当な書式です。空白スペースが、
Fred\ Bloggs@example.com
The backslash character may also be used to quote itself, e.g.,
のように、同じく現われるかもしれません。バックスラッシュ文字は自分自
身を引用するために使われるかもしれません、例えば、
Joe.\\Blow@example.com
In addition to quoting using the backslash character, conventional
double-quote characters may be used to surround strings. For example
バックスラッシュ文字を使った引用のほかに、従来の二重引用符文字が文字
列部を囲むために使われるかもしれません。例えば、
"Abc@def"@example.com
"Fred Bloggs"@example.com
are alternate forms of the first two examples above. These quoted
forms are rarely recommended, and are uncommon in practice, but, as
discussed above, must be supported by applications that are
processing email addresses. In particular, the quoted forms often
appear in the context of addresses associated with transitions from
other systems and contexts; those transitional requirements do still
arise and, since a system that accepts a user-provided email address
cannot "know" whether that address is associated with a legacy
system, the address forms must be accepted and passed into the email
environment.
は最初の２つの例の代わりの形式です。これらの引用形式はめったに推薦さ
ず、そして実際は異常ですが、上で論じられるように、電子メールアドレス
を処理しているアプリケーションでサポートされなくてはなりません。特に、
引用形式は他システムとの移行と結び付いたアドレス環境でしばしば現われ
ます；それらの過渡的な必要条件はまだ起こりえます、そしてユーザが供給
する電子メールアドレスを受入れるシステムは、そのアドレスが旧式なシス
テムと結び付けられるかどうか「知る」ことができないので、アドレス形式
は電子メール環境下で受け入れて、渡されなければなりません。
Without quotes, local-parts may consist of any combination of
alphabetic characters, digits, or any of the special characters
引用文無し、ローカル部は任意のアルファベット文字、数字、任意の特別な
文字
! # $ % & ' * + - / = ? ^ _ ` . { | } ~
period (".") may also appear, but may not be used to start or end the
local part, nor may two or more consecutive periods appear. Stated
differently, any ASCII graphic (printing) character other than the
at-sign ("@"), backslash, double quote, comma, or square brackets may
appear without quoting. If any of that list of excluded characters
are to appear, they must be quoted. Forms such as
の結合からなるかもしれません。ピリオド(".")も現れるかも知れませんが、
ローカル部の先頭や終わりや２つ以上の連続では現われないかもしれません。
違いを言うと、アットマーク("@")とバックスラッシュとダブルクォートと
コンマと角カッコ以外のＡＳＣＩＩ図形（印刷可能）が引用なしであらわれ
るかもしれません。もし除去文字リストのどれかが現われるなら、それらは
引用されなくてはなりません。
user+mailbox@example.com
customer/department=shipping@example.com
$A12345@example.com
!def!xyz%abc@example.com
_somename@example.com
are valid and are seen fairly regularly, but any of the characters
listed above are permitted. In the context of local parts,
apostrophe ("'") and acute accent ("`") are ordinary characters, not
quoting characters. Some of the characters listed above are used in
conventions about routing or other types of special handling by some
receiving hosts. But, since there is no way to know whether the
remote host is using those conventions or just treating these
characters as normal text, sending programs (and programs evaluating
address validity) must simply accept the strings and pass them on.
のような形式は正当で、そしてかなり規則的に見られますが、上でリストアッ
プされた文字のどれでも認められます。ローカル部環境で、アポストロフィ
("'")とアクセント("`")は普通の文字で、引用文字ではありません。上にリ
ストアップされた文字のいくつかは、ある受信ホストによりルーティングや
他の種類の特別扱いの規則に使われます。けれども、遠隔のホストがそれら
の規則を使っているか、標準テキストとしてこれらの文字を扱っているかど
うか知る方法がないので、送信プログラム（とアドレス正当性評価プログラ
ム）は単純に文字列を受け入れ、渡さなくてはなりません。
In addition to restrictions on syntax, there is a length limit on
email addresses. That limit is a maximum of 64 characters (octets)
in the "local part" (before the "@") and a maximum of 255 characters
(octets) in the domain part (after the "@") for a total length of 320
characters. Systems that handle email should be prepared to process
addresses which are that long, even though they are rarely
encountered.
制限のほかに、構文で、電子メールアドレス長に限界があります。その限界
はローカル部（"@"の前）で６４文字（オクテット）と、ドメイン部（"@"の
後に）で２５５文字（オクテット）と、合計長の３２０文字です。電子メー
ルを処理するシステムは、めったに出会われないが、長いアドレスを処理す
る用意ができるべきです。
4. URLs and URIs
4. ＵＲＬとＵＲＩ
4.1. URI syntax definitions and issues
4.1. ＵＲＩ構文定義と問題
The syntax for URLs (Uniform Resource Locators) is specified in
[RFC1738]. The syntax for the more general "URI" (Uniform Resource
Identifier) is specified in [RFC2396]. The URI syntax is extremely
general, with considerable variations permitted according to the type
of "scheme" (e.g., "http", "ftp", "mailto") that is being used.
While it is possible to use the general syntax rules of RFC 2396 to
perform syntax checks, they are general enough --essentially only
specifying the separation of the scheme name and "scheme specific
part" with a colon (":") and excluding some characters that must be
escaped if used-- to provide little significant filtering or
validation power.
ＵＲＬ（一様資源ロケータ）の構文は[RFC1738]で指定されます。より一般
的な「ＵＲＩ」（一様資源識別子）の構文は[RFC2396]で指定されます。Ｕ
ＲＩ構文は非常に一般的で、使われている「スキーマ」（例えば"http"と
"ftp"と"mailto"）の種類に従って認めらるなりの相違があります。構文検
査を行うためにＲＦＣ２３９６の一般的な構文規則を使うのは可能であるが、
それらは一般にフィルタや検査力が強くありません−本質的にこれはスキー
マ名と「スキーマ固有部」の区切りをコロン(":")とし、使う場合にエスケー
プするいくつかの文字を指定するだけです。
The following characters are reserved in many URIs -- they must be
used for either their URI-intended purpose or must be encoded. Some
particular schemes may either broaden or relax these restrictions
(see the following sections for URLs applicable to "web pages" and
electronic mail), or apply them only to particular URI component
parts.
以下の文字は多くのＵＲＩで予約されます−これらはＵＲＩの意図した目的
で使うか、またはコード化されなくてはなりません。いくつかの特定のスキー
マは制限を広げるか緩め（「ウェブページ」と電子メールに適用できるＵＲ
Ｌは次章を見てください）、あるいは特定のＵＲＩ要素にだけ適用するかも
しれません。
; / ? : @ & = + $ , ?
In addition, control characters, the space character, the double-
quote (") character, and the following special characters
さらに、制御文字とスペース文字とダブルクォート文字(")と以下の特別な文
字は、一般に禁じられ、下に論じられるように避けるかエスケープしなけれ
ばなりません。
< > # %
are generally forbidden and must either be avoided or escaped, as
discussed below.
The colon after the scheme name, and the percent sign used to escape
characters, are specifically reserved for those purposes, although
":" may also be used elsewhere in some schemes.
スキーマ名の後のコロンと文字をエスケープするパーセント記号は、この目
的で特別に予約されます、":"はあるスキーマで他のところに使われるかもし
れません。
When it is necessary to encode these, or other, characters, the
method used is to replace it with a percent-sign ("%") followed by
two hexidecimal digits representing its octet value. See section
2.4.1 of [RFC2396] for an exact definition. Unless it is used as a
delimiter of the URI scheme itself, any character may optionally be
encoded this way; systems that are testing URI syntax should be
prepared for these encodings to appear in any component of the URI
except the scheme name itself.
これらや他の文字ををコード化する必要がある場合に使われるのは、これを
パーセント記号と２桁のオクテット値を表す１６進数で置き換える方法です。
正確な定義は[RFC2396]の２.４.１章を見てください。ＵＲＩスキーマで区
切り記号として用いられなければ、任意の文字がこの方法でコード化できま
す；ＵＲＩ文法を検査するシステムは、スキーマ名以外の任意のＵＲＩ要素
でコード化が現れるのに対応しているべきです。
A "generic URI" syntax is specified and is more restrictive, but
using it to test URI strings requires that one know whether or not
the particular scheme in use obeys that syntax. Consequently,
applications that intend to check or validate URIs should normally
identify the scheme name and then apply scheme-specific tests. The
rules for two of those -- HTTP [RFC1738] and MAILTO [RFC2368] URLs --
are discussed below, but the author of an application which intends
to make very precise checks, or to reject particular syntax rather
than just warning the user, should consult the relevant scheme-
definition documents for precise syntax and relationships.
「一般ＵＲＩ」構文が指定され、そしてより制限されますが、ＵＲＩ文字列
を検査するためにこれを使うには、使用された特定のスキーマがその構文に
従うかどうかを知る必要があります。従って、正しいＵＲＩの検査か検証を
意図するアプリケーションは、スキーマ名を認識し、スキーマ固有の検査を
適用すべきです。それらのうちの２つ規則−ＨＴＴＰ[RFC1738]とＭＡＩＬ
ＴＯ[RFC2368]−は下で論じられますが、しかし非常に正確な検査やユーザ
に警告せずに特定の構文を拒否するアプリケーションの作者は、正確な構文
論と関係について、関連するスキーマの定義文書を調べるべきです。
4.2. The HTTP URL
4.2. ＨＴＴＰ ＵＲＬ
Absolute HTTP URLs consist of the scheme name, a host name (expressed
as a domain name or IP address), and optional port number, and then,
optionally, a path, a search part, and a fragment identifier. These
are separated, respectively, by a colon and the two slashes that
precede the host name, a colon, a slash, a question mark, and a hash
mark ("#"). So we have
絶対ＨＴＴＰ ＵＲＬがスキーマ名と（ドメイン名やＩＰアドレスで表される）
ホスト名とオプションのポート番号と、オプションのパスと検索部と分割識
別子から成り立ちます。これらはホスト名の前のコロンと２つのスラッシュ
と、コロンと、スラッシュと、疑問符と、ハッシュマーク("#")で区切られま
す。それで
http://host:port/path?search#fragment
http://host/path/
http://host/path#fragment
http://host/path?search
http://host
and other variations on that form. There is also a "relative" form,
but it almost never appears in text that a user might, e.g., enter
into a form. See [RFC2616] for details.
とこの形式の他の表現があります。同じく「相対的」形式があります、しか
し、ユーザが入力するように思われないので、テキストでは多分現れません。
詳細は[RFC2616]を見てください。
The characters
文字
/ ; ?
are reserved within the path and search parts and must be encoded;
the first of these may be used unencoded, and is often used within
the path, to designate hierarchy.
はパスと検索部で予約でありコード化されなくてはなりません；最初のはコー
ド化されずに使われ、しばしばパスで階層を指名するために使われます。
4.3. The MAILTO URL
4.3. ＭＡＩＬＴＯ ＵＲＬ
MAILTO is a URL type whose content is an email address. It can be
used to encode any of the email address formats discussed in Section
3 above. It can also support multiple addresses and the inclusion of
headers (e.g., Subject lines) within the body of the URL. MAILTO is
authoritatively defined in RFC 2368 [RFC2368]; anyone expecting to
accept and test multiple addresses or mail header or body formats
should consult that document carefully.
ＭＡＩＬＴＯは内容が電子メールアドレスであるＵＲＬタイプです。これは
上記３章で論じられた電子メールアドレスフォーマットをコード化するため
に使うことができます。これはＵＲＬ本体内に多数のアドレスとヘッダ（例
えば、題名行）を含める事をサポートできます。ＭＡＩＬＴＯはＲＦＣ２３
６８[RFC2368]で正式に定義されます；多数のアドレスやメールヘッダや本体
フォーマットを受入れてテストすることを期待するなら、慎重にこの文書を
調べるべきです。
In accepting text for, or validating, a MAILTO URL, it is important
to note that, while it can be used to encode any valid email address,
it is not sufficient to copy an email address into a MAILTO URL since
email addresses may include a number of characters that are invalid
in, or have reserved uses for, URLs. Those characters must be
encoded, as outlined in Section 4.1 above, when the addresses are
mapped into the URL form. Conversely, addresses in MAILTO URLs
cannot, in general, be copied directly into email contexts, since few
email programs will reverse the decodings (and doing so might be
interpreted as a protocol violation).
ＭＡＩＬＴＯ ＵＲＬのテキストを受入れるか有効にするため、これが正当な
電子メールアドレスをコード化するために使うことができるが、電子メール
アドレスが無効文字やＵＲＬに使用するために予約されている文字を含むか
もしれないので、電子メールアドレスをＭＡＩＬＴＯ ＵＲＬにコピーするだ
けでは十分でない事に気づいてください。これらの文字は、アドレスをＵＲ
Ｌ形式に変換するときに、上記４.１章で概説されるように、コード化されな
くてはなりません。逆に、ほとんどの電子メールプログラムがデコードを無
効にしないだろうから（無効にするにはプロトコル違反と解釈されるかもし
れません）、ＭＡＩＬＴＯ ＵＲＬのアドレスが、一般に、直接電子メール環
境にコピーできません。
The following characters may appear in MAILTO URLs only with the
specific defined meanings given. If they appear in an email address
(i.e., for some other purpose), they must be encoded:
次の文字は与えられた特定の定義された意味でだけＭＡＩＬＴＯ ＵＲＬに
現われるかもしれません。もしこれらが電子メールアドレスに（に何か他の
目的で）現われるなら、コード化されなくてはなりません：
: The colon in "mailto:"
"mailto:"のコロン
< > # " % { } | \ ^ ~ `
These characters are "unsafe" in any URL, and must always be
encoded.
これらの文字はどんなＵＲＬででも「危険」で、常にコード化されなくて
はなりません。
The following characters must also be encoded if they appear in a
MAILTO URL
次の文字も、もしＭＡＩＬＴＯ ＵＲＬに現われるなら、コード化されなくて
はなりません。
? & =
Used to delimit headers and their values when these are encoded
into URLs.
これらがＵＲＬにコード化される時、限定的なヘッダと値で使います。
Some examples may be helpful:
いくつかの例が助けになるかもしれません：
+-------------------------+-----------------------------+-----------+
| Email address | MAILTO URL | Notes |
+-------------------------+-----------------------------+-----------+
| Joe@example.com | mailto:joe@example.com | 1 |
| | | |
| user+mailbox@example | mailto: | 2 |
| .com | user%2Bmailbox@example | |
| | .com | |
| | | |
| customer/department= | mailto:customer%2F | 3 |
| shipping@example.com | department=shipping@example | |
| | .com | |
| | | |
| $A12345@example.com | mailto:$A12345@example | 4 |
| | .com | |
| | | |
| !def!xyz%abc@example | mailto:!def!xyz%25abc | 5 |
| .com | @example.com | |
| | | |
| _somename@example.com | mailto:_somename@example | 4 |
| | .com | |
+-------------------------+-----------------------------+-----------+
Table 1
Notes on Table
表のノート
1. No characters appear in the email address that require escaping,
so the body of the MAILTO URL is identical to the email address.
1. エスケープの必要な文字が電子メールアドレスに現われません、それで
ＭＡＩＬＴＯ ＵＲＬ本体の電子メールアドレスとまったく同じです。
2. There is actually some uncertainty as to whether or not the "+"
characters requires escaping in MAILTO URLs (the standards are
not precisely clear). But, since any character in the address
specification may optionally be encoded, it is probably safer to
encode it.
2. ＭＡＩＬＴＯ ＵＲＬ"+"文字にエスケープが必要かどうかは実際に明確
ではありませんある（標準が厳密に明確ではない）。けれども、アドレ
ス仕様の文字はオプションでコード化されるかもしれないので、コード
化するのは恐らくより安全です。
3. The "/" character is generally reserved in URLs, and must be
encoded as %2F.
3. "/"文字はＵＲＬで一般に予約で、%2Fにコード化されなくてはなりませ
ん。
4. Neither the "$" nor the "_" character are given any special
interpretation in MAILTO URLs, so need not be encoded.
4. ＭＡＩＬＴＯ ＵＲＬで"$"も"_"も特別な解釈がなく、コード化される必
要がありません。
5. While the "!" character has no special interpretation, the "%"
character is used to introduce encoded sequences and hence it
must always be encoded.
5. "!"文字は特別な解釈を持たないが、"%"文字はコード化列の始まりなの
でコード化されなければならない。
4.4. Guessing domain names in web contexts
4.4. ウェブ環境でのドメイン名推測
Several web browsers have adopted a practice that permits an
incomplete domain name to be used as input instead of a complete URL.
This has, for example, permitted users to type "microsoft" and have
the browser interpret the input as "http://www.microsoft.com/".
Other browser versions have gone even further, trying to build DNS
names up through a series of heuristics, testing each variation in
turn to see if it appears in the DNS, and accepting the first one
found as the intended domain name. Still, others automatically
invoke search engines if no period appears or if the reference fails.
If any of these approaches are to be used, it is often critical that
the browser recognize the complete list of TLDs. If an incomplete
list is used, complete domain names may not be recognized as such and
the system may try to turn them into completely different names. For
example, "example.aero" is a fully-qualified name, since "AERO." is a
TLD name. But, if the system doesn't recognize "AERO" as a TLD name,
it is likely to try to look up "example.aero.com" and
"www.example.aero.com" (and then fail or find the wrong host), rather
than simply looking up the user-supplied name.
いくつかのウェブブラウザが、完全なＵＲＬの代わりの入力に、不完全なド
メイン名を用いるのを許す規則を採用しました。これは、例えば、ユーザが
"microsoft"をタイプし、ブラウザが入力を"http://www.microsoft.com/"
と解釈するのを許しました。他のブラウザバージョンがさらに進め、一連の
発見的手法を通してＤＮＳ名を構築しようとし、様々な変形をＤＮＳに現わ
れるか順に試し、見つかった最初のを意図したドメイン名として受け入れま
した。まだ、他の自動機能も、もしピリオドが現われないか、あるいはもし
参照に失敗するなら、自動的にサーチ・エンジンを呼び出します。もしこれ
らの方法のいずれかが使われるなら、ブラウザがＴＬＤの完全なリストを認
識することはしばしば重要です。もし不完全なリストが使われるなら、完全
なドメイン名が認識されないかもしれず、システムはそれを完全に異なる名
前に変えようとするかもしれません。例えば"example.aero"は"AERO."がＴ
ＬＤなので、完全指定名です。しかし、もしシステムが"AERO"をＴＬＤ名と
認識しないなら、ユーザが供給した名前を単純に調べるより、
"example.aero.com"と"www.example.aero.com"を調べる可能性が高いです
（そして失敗するか、間違ったホストを見つけます）。
As discussed in Section 2 above, there are dangers associated with
software that attempts to "know" the list of top-level domain names
locally and take advantage of that knowledge. These name-guessing
heuristics are another example of that situation: if the lists are
up-to-date and used carefully, the systems in which they are embedded
may provide an easier, and more attractive, experience for at least
some users. But finding the wrong host, or being unable to find a
host even when its name is precisely known, constitute bad
experiences by any measure.
そしてその知識を利用しようと試みるソフトウェアと関連した脅威がありま
す。これらの名前を推測する発見的手法は他の状況の例です：もしリストが
最新であり、慎重に使われ、それらが埋め込まれたシステムは、少なくとも
あるユーザにより容易でより魅力的な体験を提供するかもしれません。けれ
ども間違ったホストを見つけるか、名前が正確に知られている時にもホスト
を見つけることが不可能なら、どんな意味でも悪い経験です。
More generally, there have been bad experiences with attempts to
"complete" domain names by adding additional information to them.
These issues are described in some detail in RFC 1535 [RFC1535].
上記２章で論じられるように、ローカルに最上位ドメイン名リストを「知り」、
さらに一般に、追加情報を加えることでドメイン名を「完成」する試みに、
悪い経験があります。これらの問題はＲＦＣ１５３５[RFC1535]でいくらか詳
しく記述されます。
5. Implications of internationalization
5. 国際化の意味
The IETF has adopted a series of proposals ([RFC3490] - [RFC3492])
whose purpose is to permit encoding internationalized (i.e., non-
ASCII) names in the DNS. The primary standard, and the group
generically, are known as "IDNA". The actual strings stored in the
DNS are in an encoded form: the labels begin with the characters
"xn--" followed by the encoded string. Applications should be
prepared to accept and process the encoded form (those strings are
consistent with the "LDH rule" (see Section 2) so should not raise
any separate issues) and the use of local, and potentially other,
characters as appropriate to local systems and circumstances.
ＩＥＴＦはＤＮＳで国際化コーディング（すなわち、非ＡＳＣＩＩ）名を許
す目的の一連の提案（[RFC3490] - [RFC3492]）を採用しました。主要な標準
とグループは属性的に、「ＩＤＮＡ」として知られています。ＤＮＳに蓄積
された実際の文字列はコード化された形式です：ラベルは"xn--"で始まりコー
ド化文字が続きます。アプリケーションはコード化形式（これらの文字列は
「ＬＨＤ規則」（２章参照）に従い、それで他の問題を起こしません）の受
け入れ処理し、そしてローカルシステムと状況で適切なローカル文字、と潜
在的に他、を使用する用意が出来ているべきです。
The IDNA specification describes the exact process to be used to
validate a name or encoded string. The process is sufficiently
complex that shortcuts or heuristics, especially for versions of
labels written directly in Unicode or other coded character sets, are
likely to fail and cause problems. In particular, the strings cannot
be validated with syntax or semantic rules of any of the usual sorts:
syntax validity is defined only in terms of the result of executing a
particular function.
ＩＤＮＡ仕様は名前かコード化文字列の有効性検査をするために使われる正
確なプロセスを記述しました。処理は、特に直接ユニコードや他のコード文
字集合で書かれたラベルのバージョンでショートカットや発見的手法が失敗
し問題を起こす可能性が高いぐらい、十分に複雑です。特に、文字列は構文
や一般的な種類の意味の規則で妥当性検査をすることができません：構文正
当性は特定の機能を実行した結果に関してだけ定義されます。
In addition to the restrictions imposed by the protocols themselves,
many domains are implementing rules about just which non-ASCII names
they will permit to be registered (see, e.g., [JET], [RegRestr]).
This work is still relatively new, and the rules and conventions are
likely to be different for each domain, or at least each language or
script group. Attempting to test for those rules in a client program
to see if a user-supplied name might possibly exist in the relevant
domain would almost certainly be ill-advised.
プロトコル自身によって課された制限のほかに、多くのドメインがどの非Ａ
ＳＣＩＩ名の登録を許すかの規則を実行します（例えば[JET]や[RegRestr]
参照）。この仕事はまだ比較的新しく、そして規則と習慣はそれぞれのドメ
インや、少なくともそれぞれの言語やスクリプトグループ毎に異なる可能性
が高いです。ユーザによって供給された名前が適切なドメインで存在するか
を見るクライアントプログラムで、これらの規則の検査を行う試みはほとん
ど確実に無分別であるでしょう。
One quick local test however, may be reasonable: as of the time of
this writing, there should be no instances of labels in the DNS that
start with two characters, followed by two hyphens, where the two
characters are not "xn" (in, of course, either upper or lower case).
Such label strings, if they appear, are probably erroneous or
obsolete, and it may be reasonable to at least warn the user about
them.
しかしながら、すばやいローカル試験が合理的かもしれません：この著作時
点で、２文字から始まり２つのハイフンが続き、２つの文字が"xn"でないラ
ベルがあるべきでありません（もちろん、大文字でも小文字でもです）。こ
のようなラベル文字列は、もしそれが現われるなら、恐らく誤りか時代遅れ
です、それでそれらについてユーザに警告することは少なくとも合理的かも
しれません。
There is ongoing work in the IETF and elsewhere to define
internationalized formats for use in other protocols, including email
addresses. Those forms may or may not conform to existing rules for
ASCII-only identifiers; anyone designing evaluators or filters should
watch that work closely.
電子メールアドレスを含め、他のプロトコルで使用する国際化フォーマット
を定義する、ＩＥＴＦで進行中の仕事があります。これらの形式はＡＳＣＩ
Ｉのみの識別子の既存の規則に従うかもしれないし、そうでないかもしれま
せん；評価やフィルタを設計する人は注意深くその仕事を見るべきです。
6. Summary
6. 要約
When an application accepts a string from the user and ultimately
passes it on to an API for a protocol, the desirability of testing or
filtering the text in any way not required by the protocol itself is
hotly debated. If it must divide the string into its components, or
otherwise interpret it, it obviously must make at least enough tests
to validate that process. With, e.g., domain names or email
addresses that can be passed on untouched, the appropriateness of
trying to figure out which ones are valid and which ones are not
requires a more complex decision, one that should include
considerations of how to make exactly the correct tests and to keep
information that changes and evolves up-to-date. A test containing
obsolete information, can be extremely frustrating for potential
correspondents or customers and may harm desired relationships.
アプリケーションがユーザから文字列を受け入れ、そして最終的にプロトコ
ルＡＰＩに渡す時、プロトコル自身が要求しないテキスト検査やフィルタリ
ングの望ましさが激しく議論されます。もし文字列を要素に分けるか、ある
いは解釈しなければならないなら、少なくとも明らかに検証処理の十分な検
査をしなければなりません。例えば、変更せずに渡す事が出来るドメイン名
や電子メールアドレスで、どれが正しくどれが正しくないかを理解する適切
な試みは、より複雑な決定を要求し、人はどうやって厳密に正確な検査をし、
どうやって変化と進展する情報を更新するかの、考慮をするべきです。古い
情報での検査は、通信者や顧客を非常に失望させる可能性があり、望ましい
関係を傷つけるかもしれません。
7. Security Considerations
7. セキュリティの考察
Since this document merely summarizes the requirements of existing
standards, it does not introduce any new security issues. However,
many of the techniques that motivate the document raise important
security concerns of their own. Rejecting valid forms of domain
names, email addresses, or URIs often denies service to the user of
those entities. Worse, guessing at the user's intent when an
incomplete address, or other string, is given can result in
compromises to privacy or accuracy of reference if the wrong target
is found and returned. From a security standpoint, the optimum
behavior is probably to never guess, but instead, to force the user
to specify exactly what is wanted. When that position involves a
tradeoff with an acceptable user experience, good judgment should be
used and the fact that it is a tradeoff recognized.
この文書はただ既存の標準の必要条件を要約するだけなので、新しいセキュ
リティ問題を起こしません。しかしながら、文書の動機になったテクニック
の多くは、それら自身が重大なセキュリティの懸念を生じます。ドメイン名
や電子メールアドレスやＵＲＩの正しい形式の拒絶は、それらの項目のユー
ザのサービスを妨害します。最悪、不完全なアドレスや他の文字列が与えら
れる時に、ユーザの意図を推測して、もし間違った相手を見つけて返される
なら、プライバシや参照の正確さに問題を生じえます。セキュリティの見地
から、最適な行動は恐らく決して推測しないことですが、しかしその代わり
に、ユーザは正確に何が必要か明示することを強いるはずです。その姿勢が
許容できるユーザ経験のトレードオフに関係する時、良い判断が使われるべ
きで、それがトレードオフであると認識されるべきです。
Some characters have special or privileged meanings on some systems
(i.e., ` on Unix). Applications should be careful to escape those
locally if necessary. By the same token, they are valid, and should
not be disallowed locally, or escaped when transmitted through
Internet protocols, for such reasons if a remote site chooses to use
them.
ある文字があるシステム上で特別か特権を与えられた意味を持ちます（例え
ば、ＵＮＩＸ上での ` ）。アプリケーションは慎重に、もし必要なら、ロー
カルにこれらをエスケープするべきです。もし遠隔サイトが使用するなら、
インターネット・プロトコルで転送する時、このような理由で、有効なこの
トークンをローカルに拒絶したりエスケープするべきではありません。
The presence of local checking does not permit remote checking to be
bypassed. Note that this can apply to a single machine; in
particular, a local MTA should not assume that a local MUA has
properly escaped locally-significant special characters.
ローカル検査の存在は、遠隔検査の迂回を認めません。これがひとつのマシ
ンに当てはまることに注意してください；特に、ローカルＭＴＡはローカル
ＭＵＡが正確にローカルに意味を持つ特別な文字をエスケープすると想定す
るべきではありません。
8. Acknowledgements
8. 謝辞
The author would like to express his appreciation for helpful
comments from Harald Alvestrand, Eric A. Hall, and the RFC Editor,
and for partial support of this work from SITA. Responsibility for
any errors remains, of course, with the author.
著者はHarald AlvestrandとEric A.HallとＲＦＣ編集者からの助けになるコ
メントと、ＳＩＴＡからの仕事の部分的なサポートを評価したいです。誤り
の責任は、もちろん、著者にあります。
The first Internet-Draft on this subject was posted in February 2003.
The document was submitted to the RFC Editor on 20 June 2003,
returned for revisions on 19 August, and resubmitted on 5 September
2003.
この話題の最初のインターネットドラフトは２００３年２月に提出されまし
た。文書は２００３年６月２０日にＲＦＣエディタに提出され、８月１９日
に修正のために返されて、そして２００３年９月５日に再提出されました。
9. References
9. 参考文献
9.1. Normative References
9.1. 参照する参考文献
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, October
1989.
[RFC1535] Gavron, E., "A Security Problem and Proposed
Correction With Widely Deployed DNS Software", RFC
1535, October 1993.
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill,
"Uniform Resource Locators (URL)", RFC 1738, December
1994.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2368] Hoffman, P., Masinter, L. and J. Zawinski, "The
mailto URL scheme", RFC 2368, July 1998.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter,
"Uniform Resource Identifiers (URI): Generic Syntax",
RFC 2396, August 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
June 1999.
[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol",
RFC 2821, April 2001.
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC
2822, April 2001.
[RFC3490] Faltstrom, P., Hoffman, P. and A. Costello,
"Internationalizing Domain Names in Applications
(IDNA)", RFC 3490, March 2003.
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Profile for Internationalized Domain Names (IDN)",
RFC 3491, March 2003.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of
Unicode for Internationalized Domain Names in
Applications (IDNA)", RFC 3492, March 2003.
[ASCII] American National Standards Institute (formerly
United States of America Standards Institute), "USA
Code for Information Interchange", ANSI X3.4-1968.
ANSI X3.4-1968 has been replaced by newer versions
with slight modifications, but the 1968 version
remains definitive for the Internet.
[DomainList] Internet Assigned Numbers Authority (IANA), Untitled
alphabetical list of current top-level domains.
http://data.iana.org/TLD/tlds-alpha-by-domain.txt
ftp://data.iana.org/TLD/tlds-alpha-by-domain.txt
9.2. Informative References
9.2. 有益な参考文献
[ISO.3166.1988] International Organization for Standardization,
"Codes for the representation of names of countries,
3rd edition", ISO Standard 3166, August 1988.
[JET] Konishi, K., et al., "Internationalized Domain Names
Registration and Administration Guideline for
Chinese, Japanese and Korean", Work in Progress.
[RFC1591] Postel, J., "Domain Name System Structure and
Delegation", RFC 1591, March 1994.
[RegRestr] Klensin, J., "Registration of Internationalized
Domain Names: Overview and Method", Work in Progress,
February 2004.
10. Author's Address
10. 著者のアドレス
John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
11. Full Copyright Statement
11. 著作権表示全文
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
著作権（Ｃ）インターネット学会（２００４）。この文書はＢＣＰ７８に含
まれる権利と許可と制限の適用を受け、そしてこの中に明らかにされる以外
は著者がすべての権利を維持します。
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
者が代表するか貢献者を後援する組織（もしあれば）とインターネット学会
とインターネット技術標準化タスクフォースは、明確にも暗黙にも、この情
報の使用が権利の侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、全ての保証を拒否します。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/iprにあるＩＥＴＦオンラインＩＰＲ
貯蔵庫で得られます。
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
ＩＥＴＦは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
めます。どうかietf-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。