[要約] RFC 3696は、名前のチェックと変換のためのアプリケーション技術に関するガイドラインです。このRFCの目的は、有効な名前の形式を確認し、必要に応じて変換するための手法を提供することです。
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.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
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.
多くのインターネットアプリケーションは、部分情報からトップレベルのドメイン（またはその他のドメイン名ラベル）を推定するように設計されています。新しいトップレベルのドメイン、特に非カントリーコードのドメインの導入は、これらのアプリケーションで使用されるいくつかの方法に欠陥を明らかにしています。これらの欠陥により、アプリケーションのユーザーが完全なインターネットにアクセスすることがより困難または不可能になります。このメモでは、使用された手法のいくつかについて説明し、ドメイン名環境が進化するにつれて、マイナスの影響を最小限に抑えるためのガイダンスを提供します。このドキュメントは、該当するルールの概要を1つの場所で一緒に描き、実際の標準への参照を提供します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Restrictions on domain (DNS) names . . . . . . . . . . . . . . 3
3. Restrictions on email addresses . . . . . . . . . . . . . . . 5
4. URLs and URIs . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. URI syntax definitions and issues . . . . . . . . . . . 7
4.2. The HTTP URL . . . . . . . . . . . . . . . . . . . . . . 8
4.3. The MAILTO URL . . . . . . . . . . . . . . . . . . . . . 9
4.4. Guessing domain names in web contexts . . . . . . . . . 11
5. Implications of internationalization . . . . . . . . . . . . . 11
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 15
10. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16
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.
ユーザーインターフェイスの設計者は、インターネットアプリケーションへのインターフェイスへの設計者は、インターネットツール自体に渡す前に、有効性のユーザーが提供する値を調べることが有用であることがよくあります。このタイプのテストは、構文チェックまたはドメイン名、電子メールアドレス、または「Webアドレス」（URLまたは拡張されたURIフォーム（セクション4を参照））への他のルールのアプリケーションを含む最も一般的に関与します。プロトコル自体から利用できる場合よりもユーザー。値に関するローカル妥当性テストは、バックオフィス処理プログラムの効率を改善し、プロトコル自体の負荷を減らすためにも考えられています。確かに、それらは、できるだけ早くエラーを検出する方が良いという確立された原則と一致しています。
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.
ただし、テストは正しくまたは少なくとも安全に行う必要があります。プロトコルと一致しない基準が適用された場合、ユーザーは不便になり、住所やサイトはいくつかのグループにアクセスできなくなり、ビジネスとコミュニケーションの機会が失われます。近年の経験は、構文テストがしばしば誤って実行されることが多く、トップレベルのドメイン名のテストが時代遅れのリストと規則を使用して適用されることを示しています。これらの誤ったテストのほとんどは、適用される基準の正確な定義を便利に見つけることができない結果であると仮定します。このドキュメントは、該当するルールの概要を1つの場所で一緒に描き、実際の標準への参照を提供します。これらの基準には何も追加しません。情報をよりアクセスしやすい形式にまとめるだけです。
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.
以下のセクションでは、ドメイン名、メールアドレス、およびURLについて説明します。
The authoritative definitions of the format and syntax of domain names appear in RFCs 1035 [RFC1035], 1123 [RFC1123], and 2181 [RFC2181].
ドメイン名の形式と構文の権威ある定義は、RFCS 1035 [RFC1035]、1123 [RFC1123]、および2181 [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.
任意の文字、またはビットの組み合わせ（オクテットとして）は、DNS名で許可されています。ただし、ほとんどのアプリケーションで必要とされる優先フォームがあります。この優先フォームは、トップレベルのドメインまたはTLDの名前で許可されている唯一のフォームです。一般に、これはTLDに登録されているほとんどのセカンドレベルの名前で許可される唯一のフォームでもありますが、ユーザーが通常見ない名前の一部は他のルールに従います。ホストの命名（つまり、「ホスト名」ルール）の元のArpanetルールから派生し、許可されている文字の後、「LDHルール」としておそらくよりよく説明されています。LDHルールは、更新されたように、ドメイン名を構成するラベル（期間で区切られた単語または文字列）は、ASCII [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.
非文字のオクテットでラベルを表現する必要がある場合、またはラベルに期間を埋め込む必要がある場合、エスケープシーケンスを利用するというメカニズムがあります。RFC 1035 [RFC1035]が必要な場合は相談する必要があります（電子メールやWebを含む最も一般的なアプリケーションでは、一般に逃げ出した文字列が許可されません）。ASCII以外のキャラクターでは特別なエンコードが利用可能になりました。セクション5の簡単な説明をご覧ください。
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.
他のホストまたはシステムを参照するほとんどのインターネットアプリケーションは、「完全に認定された」ドメイン名、つまりTLD名を含むルートにつながるすべてのラベルを含むものを含むと想定しています。これらの完全に資格のあるドメイン名は、ドメイン名解像度プロトコル自体またはリモートシステムのいずれかに渡されます。その結果、アプリケーションで使用され、リソースを見つけると言われたDNS名と主張されていると、一般に少なくとも1つの期間（「。」）文字が含まれている必要があります。そうでないものは、追加情報を提供するために無効であるか、申請を要求するものです。もちろん、この原則は、アプリケーションの目的がTLDの名前を処理または照会することである場合、適用されません。DNS仕様では、ルート、例えば「A.B.C」や「A.B.C.」を示すために、後続の期間を使用することもできます。同等ですが、後者はより明確であり、アプリケーションに受け入れられる必要があります。この規則は、TLD名が直接参照されている場合に特に重要です。たとえば、「.com」は、そのトップレベルのドメイン「com」を参照するための一般的な用語となっています。「com」がトップレベルのドメイン名であることを示しているため、DNSについて話すのは厳密かつ技術的に正しいでしょう。
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.
有効なTLD名が実際に存在することを確認するために、「1つ以上の期間」テストを超えてアプリケーションの長い歴史があります。彼らは、名前の形式にいくつかのヒューリスティックを適用するか、有効な名前のローカルリストに相談することにより、これを行いました。歴史的なヒューリスティックはもはや効果的ではありません。ローカルリストを保持する場合、数年前よりも最新の状態を保つために、はるかに多くの努力を払う必要があります。
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.
ヒューリスティックは、DNSが最初に展開されたため、すべてのトップレベルドメイン名が2、3、または4文字の長さであるという観察に基づいていました。すべての2文字の名前は「国コード」ドメインに関連付けられており、特定のラベル（いくつかの初期の例外を除く）が、国および同様のエンティティのコードのISOリストから引き出されました[IS3166]。3文字の名前は「一般的な」TLDであり、その機能は国固有のものではなく、4文字のTLD、インフラストラクチャドメイン「ARPA」が1つありました。[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.
1990年代半ば以前には、有効なトップレベルドメイン名のリストがまれに変更されました。新しい国コードは徐々に、そしてインターネットが拡大するにつれてより迅速に追加されましたが、「int」の確立の間に一般的なドメインのリストはまったく変わりませんでした。1988年のドメインと2000年のICANNの新しい汎用TLDの割り当て。一部のアプリケーション開発者は、任意の2文字のドメイン名がTLDとして有効であると仮定して応答しましたが、ジェネリックTLDのリストは修正され、局所的に保持されてテストできます。これらの仮定のいくつかは、ICANNが新しいトップレベルのドメインを割り当て始めたときに変更されました。ISO3166-1テーブル[ISO.3166.1988]に表示されない1つの2文字のドメインは暫定的に承認され、新しいドメインは3、4で作成されました。、および6つの文字コードでさえ。
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.
2003年の第1四半期の時点で、有効な非国のトップレベルのドメインのリストは、.aero、.biz、.com、.coop、.edu、.gov、.info、.int、.mil、。博物館、.name、.net、.org、.pro、および.arpa。ICANNは定期的にそのリストを拡張することが期待されるため、ここに表示されるリストはテストで使用しないでください。代わりに、トップレベルのドメイン名をテストしてフィルタリングするシステムは、IANA [DomainList]が公開したリストをポーリングすることにより、TLDのローカルテーブル（「汎用」と国コード関連の両方）を定期的に更新する必要があります。より良い戦略が「少なくとも1つの期間」テストを行い、LDHの適合性（見かけのTLD名が全数ではないことを検証することを含む）を含む、そしてDNSを使用してドメイン名を決定するために、より良い戦略が今である可能性があります有効なTLD名のローカルリストを維持しようとするのではなく、妥当性。
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.
DNSラベルの長さは63オクター以下です。これは実際に保存されている形式です。ASCII以外のラベルがエンコードされた「Punycode」フォームに変換されている場合（セクション5を参照）、そのフォームの長さは、収容できる実際の文字（元の文字セット）の数を制限する場合があります。完全で完全に資格のあるドメイン名は、255オクテットを超えてはなりません。
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.
不完全な情報が提供されたときに正しいドメイン名を推測するためのいくつかの追加のメカニズムがWebで使用するために開発され、セクション4.4で説明されています。
Reference documents: RFC 2821 [RFC2821] and RFC 2822 [RFC2822]
参照文書：RFC 2821 [RFC2821]およびRFC 2822 [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.
現代のメールアドレスは、「ドメインパーツ」（完全に資格のあるドメイン名）から分離された「ローカルパーツ」（ "@"）によって構成されています。ドメイン部分の構文は、前のセクションの構文に対応しています。そのセクションで特定された懸念は、フィルタリングと名前のリストについても、電子メールのコンテキストで使用されるドメイン名にも適用されます。ドメイン名は、四角い括弧内のIPアドレスに置き換えることもできますが、そのフォームは、テストとトラブルシューティングの目的を除いて強く落胆しています。
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
正確なルールは、コントロール文字を含むASCII文字が引用されている、または引用された文字列に表示される可能性があるということです。引用が必要な場合、バックスラッシュ文字を使用して、次の文字を引用します。例えば
Abc\@def@example.com
abc \@def@example.com
is a valid form of an email address. Blank spaces may also appear, as in
電子メールアドレスの有効な形式です。空白のスペースも表示される場合があります
Fred\ Bloggs@example.com
fred \ bloggs@example.com
The backslash character may also be used to quote itself, e.g.,
バックスラッシュ文字は、それ自体を引用するためにも使用できます。
Joe.\\Blow@example.com
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
"abc@def"@example.com
"Fred Bloggs"@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.
上記の最初の2つの例の代替形式です。これらの引用フォームはめったに推奨されず、実際には珍しいことですが、上記のように、電子メールアドレスを処理しているアプリケーションでサポートする必要があります。特に、引用されたフォームは、他のシステムやコンテキストからの遷移に関連するアドレスのコンテキストでしばしば表示されます。これらの移行要件は依然として発生しており、ユーザーが提供する電子メールアドレスを受け入れるシステムは、そのアドレスがレガシーシステムに関連付けられているかどうかを「知る」ことができないため、アドレスフォームを受け入れて電子メール環境に渡す必要があります。
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
期間（ "）も表示される場合がありますが、ローカル部分を開始または終了するために使用されない場合もありません。また、2つ以上の連続した期間が表示される場合もありません。別の点で、AT-Sign（ "@"）、Backslash、Double Quote、Comma、またはSquare Brackets以外のASCIIグラフィック（印刷）文字は、引用せずに表示される場合があります。除外された文字のリストのいずれかが表示される場合、それらを引用する必要があります。などのフォーム
user+mailbox@example.com
customer/department=shipping@example.com
$A12345@example.com
$ a12345@example.com
!def!xyz%abc@example.com
_somename@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.
構文の制限に加えて、電子メールアドレスに長さの制限があります。その制限は、「ローカルパーツ」（「@」の前）で最大64文字（オクテット）、ドメインパーツ（「@」の後）で最大255文字（オクテット）です。文字。電子メールを処理するシステムは、めったに遭遇することはありませんが、それほど長いアドレスを処理するために準備する必要があります。
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.
URLの構文（均一なリソースロケーター）は[RFC1738]で指定されています。より一般的な「URI」（均一なリソース識別子）の構文は[RFC2396]で指定されています。URI構文は非常に一般的であり、使用されている「スキーム」（「http」、「ftp」、「mailto」などのタイプに応じてかなりのバリエーションが許可されています。RFC 2396の一般的な構文ルールを使用して構文チェックを実行することは可能ですが、それらは十分に一般的です - 基本的には、スキーム名と「スキーム固有の部分」の分離をコロン（ "："）で指定し、一部を除外します使用する場合は逃げなければならない文字 - ほとんど重要なフィルタリングまたは検証能力を提供しません。
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.
以下のキャラクターは多くのURIで予約されています - それらはURI意図の目的に使用するか、エンコードする必要があります。一部の特定のスキームは、これらの制限を拡大または緩和する場合があります（「Webページ」および電子メールに適用されるURLについては、次のセクションを参照してください）、または特定のURIコンポーネントパーツにのみ適用します。
; / ? : @ & = + $ , ?
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]のセクション2.4.1を参照してください。URIスキーム自体の区切り文字として使用されない限り、任意のキャラクターはオプションでこの方法でエンコードされる場合があります。URI構文をテストしているシステムは、これらのエンコーディングがスキーム名自体を除くURIの任意のコンポーネントに表示されるように準備する必要があります。
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.
「一般的なURI」構文が指定され、より制限的ですが、URI文字列をテストするために使用するには、使用中の特定のスキームがその構文に従うかどうかを知る必要があります。したがって、URIを確認または検証する予定のアプリケーションは、通常、スキーム名を識別し、スキーム固有のテストを適用する必要があります。それらの2つのルール - HTTP [RFC1738]とMailTo [RFC2368] URLは以下で説明しますが、非常に正確なチェックを行う、またはユーザーに警告するのではなく特定の構文を拒否するアプリケーションの著者です。正確な構文と関係については、関連するスキーム決定文書を参照する必要があります。
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 URLは、スキーム名、ホスト名（ドメイン名またはIPアドレスとして表現）、およびオプションのポート番号、およびオプションでパス、検索パーツ、およびフラグメント識別子で構成されています。これらは、それぞれコロンとホスト名、コロン、スラッシュ、疑問符、およびハッシュマーク（ "＃"）に先行する2つのスラッシュによって分離されています。だから私たちは持っています
http://host:port/path?search#fragment
http://host/path/
http://host/path/
http://host/path#fragment
http://host/path?search
http://host
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.
パスおよび検索部品内に予約されており、エンコードする必要があります。これらの最初のものは、階層を指定するために、エンコードされていないもので使用され、パス内でよく使用されます。
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.
Mailtoは、コンテンツがメールアドレスであるURLタイプです。上記のセクション3で説明したメールアドレス形式のいずれかをエンコードするために使用できます。また、URLの本文内に複数のアドレスとヘッダー（件名など）を含めることもサポートできます。Mailtoは、RFC 2368 [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).
MailTo URLのテキストを受け入れる、または検証する際には、有効な電子メールアドレスをエンコードするために使用できるが、メールアドレスにはメールアドレスが含まれるため、メールアドレスをメールURLにコピーするだけでは不十分であることに注意することが重要です。URLSで無効な、または使用している使用を行っている文字の数。アドレスがURL形式にマッピングされた場合、上記のセクション4.1で概説されているように、これらの文字はエンコードする必要があります。逆に、Mailto URLのアドレスは、一般に、電子メールのコンテキストに直接コピーすることはできません。これは、デコディングを逆転させるために電子メールプログラムがほとんどないためです（そして、そうすることはプロトコル違反として解釈される可能性があります）。
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:
次の文字は、与えられた特定の定義された意味を持つMailTo URLSにのみ表示される場合があります。それらが電子メールアドレスに表示される場合（つまり、他の目的のために）、エンコードする必要があります。
: The colon in "mailto:"
：「Mailto：」のコロン
< > # " % { } | \ ^ ~ `
These characters are "unsafe" in any URL, and must always be encoded.
これらの文字は、どのURLでも「安全ではない」ものであり、常にエンコードする必要があります。
The following characters must also be encoded if they appear in a MAILTO URL
次の文字は、メールのURLに表示される場合もエンコードする必要があります
? & = Used to delimit headers and their values when these are encoded into URLs.
？＆=これらがURLにエンコードされている場合、ヘッダーとその値を区切るために使用されます。
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
表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. 逃げる必要がある電子メールアドレスには表示されない文字はないため、Mailto URLの本文はメールアドレスと同じです。
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. 実際、「」文字が郵便のURLで逃げる必要があるかどうかについては、いくつかの不確実性があります（標準は正確には明確ではありません）。ただし、アドレス仕様の文字はオプションでエンコードされる場合があるため、おそらくエンコードする方が安全です。
3. The "/" character is generally reserved in URLs, and must be encoded as %2F.
3. 「/」文字は一般にURLで予約されており、％2Fとしてエンコードする必要があります。
4. Neither the "$" nor the "_" character are given any special interpretation in MAILTO URLs, so need not be encoded.
4. 「$」も「_」文字も、郵便のURLに特別な解釈が与えられていないため、エンコードする必要はありません。
5. While the "!" character has no special interpretation, the "%" character is used to introduce encoded sequences and hence it must always be encoded.
5. 「！」キャラクターには特別な解釈がなく、「％」文字はエンコードされたシーケンスを導入するために使用されるため、常にエンコードする必要があります。
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.
いくつかのWebブラウザは、完全なURLの代わりに入力として不完全なドメイン名を使用できるようにするプラクティスを採用しています。これにより、たとえば、ユーザーが「Microsoft」と入力し、ブラウザに入力を「http://www.microsoft.com/」と解釈できるようにしました。他のブラウザバージョンはさらに進んでおり、一連のヒューリスティックを通じてDNS名を作成し、各バリエーションをテストしてDNSに表示されるかどうかを確認し、意図したドメイン名として見つかった最初のバージョンを確認しようとしています。それでも、他の人は、期間がない場合、または参照が失敗した場合に検索エンジンを自動的に呼び出します。これらのアプローチのいずれかを使用する場合、ブラウザがTLDの完全なリストを認識することがしばしば重要です。不完全なリストが使用されている場合、完全なドメイン名がそのように認識されない場合があり、システムはそれらを完全に異なる名前に変えようとする場合があります。たとえば、「emple.aero」は「aero」以来、完全に資格のある名前です。TLD名です。しかし、システムが「エアロ」をTLD名として認識していない場合、「emple.aero.com」と「www.example.aero.com」を調べようとする可能性があります（そして、失敗するか、間違っているのを見つけますhost）、ユーザーがサプリした名前を単純に検索するのではなく。
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.
上記のセクション2で説明したように、トップレベルのドメイン名のリストをローカルで「知り」ようとするソフトウェアに関連する危険があります。これらの名前を推測するヒューリスティックは、その状況のもう1つの例です。リストが最新で慎重に使用されている場合、それらが組み込まれているシステムは、少なくとも一部のユーザーにより簡単で魅力的な経験を提供する場合があります。しかし、間違ったホストを見つける、またはその名前が正確に知られている場合でもホストを見つけることができないことは、いかなる方法でも悪い経験を構成します。
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].
より一般的には、追加情報を追加することにより、ドメイン名を「完了」しようとする試みで悪い経験がありました。これらの問題は、RFC 1535 [RFC1535]で詳細に説明されています。
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.
IETFは、DNSに国際化された（つまり非ASCII）名前をエンコードすることを許可することを目的とする一連の提案（[RFC3490] - [RFC3492]）を採用しています。主要な基準、および一般的にグループは「IDNA」として知られています。DNSに保存されている実際の文字列はエンコードされた形式です。ラベルは、文字「xn-」から始まり、エンコードされた文字列が続きます。アプリケーションは、エンコードされたフォームを受け入れて処理するために準備する必要があります（これらの文字列は「LDHルール」（セクション2を参照）と一致しているため、個別の問題を提起しないでください）とローカル、潜在的にその他のキャラクターの使用をローカルに使用します。システムと状況。
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.
IDNA仕様は、名前またはエンコードされた文字列を検証するために使用される正確なプロセスについて説明します。このプロセスは十分に複雑であるため、特にUnicodeまたはその他のコード化された文字セットで直接記述されたラベルのバージョンのショートカットまたはヒューリスティックは、故障して問題を引き起こす可能性があります。特に、文字列は、通常の種類の構文またはセマンティックルールで検証することはできません。構文の妥当性は、特定の関数を実行した結果に関してのみ定義されます。
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.
プロトコル自体によって課される制限に加えて、多くのドメインは、どの非ASCII名を登録することを許可するかについてのルールを実装しています（例えば[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.
ただし、1つのクイックローカルテストは合理的かもしれません。この執筆時点で、DNSには2つのキャラクターから始まるラベルのインスタンスがあり、2つのキャラクターが「xn」ではない2つのハイフンが続く必要はありません（、もちろん、上または小文字のいずれか）。このようなラベルの文字列は、表示されている場合、おそらく誤っているか、時代遅れであり、少なくともユーザーに警告することは合理的かもしれません。
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.
IETFなどで継続的な作業があり、電子メールアドレスを含む他のプロトコルで使用するための国際化された形式を定義しています。これらのフォームは、ASCIIの識別子の既存のルールに準拠している場合と適合しない場合があります。評価者やフィルターを設計する人は、それが密接に動作することを監視する必要があります。
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.
アプリケーションがユーザーから文字列を受け入れ、最終的にプロトコルのためにAPIに渡すと、プロトコル自体で必要とされないいかなる方法でもテストまたはフィルタリングの望ましさが熱く議論されます。文字列をコンポーネントに分割する必要がある場合、または他の方法で解釈する必要がある場合、そのプロセスを検証するのに少なくとも十分なテストを行う必要があります。例えば、手付かずに渡すことができるドメイン名または電子メールアドレス、どのものが有効であり、より複雑な決定を必要としないものを把握しようとすることの適切性、正確なものを正確に作成する方法の考慮を含むべきものを含むものテストし、最新のものを変更して進化させる情報を保持します。時代遅れの情報を含むテストは、潜在的な特派員や顧客にとって非常にイライラする可能性があり、望ましい関係に害を及ぼす可能性があります。
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.
このドキュメントは単に既存の標準の要件を要約するだけなので、新しいセキュリティの問題は導入されません。ただし、ドキュメントの動機付けをする手法の多くは、独自の重要なセキュリティ上の懸念を引き起こしています。ドメイン名、電子メールアドレス、またはURIの有効なフォームを拒否することは、多くの場合、それらのエンティティのユーザーへのサービスを拒否します。さらに悪いことに、不完全なアドレス、またはその他の文字列が与えられたときのユーザーの意図を推測すると、間違ったターゲットが見つかり、返された場合、プライバシーまたは参照の正確性が妥協する可能性があります。セキュリティの観点からは、最適な動作はおそらく推測することはなく、代わりにユーザーに必要なものを正確に指定できるようにすることです。そのポジションが許容可能なユーザーエクスペリエンスとのトレードオフを伴う場合、適切な判断を使用する必要があり、それが認識されているトレードオフであるという事実を使用する必要があります。
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.
一部のキャラクターは、一部のシステムで特別なまたは特権的な意味を持っています（つまり、UNIXで）。必要に応じて、アプリケーションは地元で逃げるように注意する必要があります。同様に、それらは有効であり、リモートサイトがそれらを使用することを選択した場合、そのような理由により、インターネットプロトコルを介して送信されたときにローカルで禁止されたり、逃げたりするべきではありません。
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.
ローカルチェックの存在では、リモートチェックをバイパスすることはできません。これは単一のマシンに適用できることに注意してください。特に、地元のMTAは、地元のMUAが地元の重要な特殊文字を適切に逃げたと想定すべきではありません。
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、およびRFC編集者からの有益なコメントと、SITAからのこの作品の部分的なサポートについて、彼の感謝を表明したいと考えています。もちろん、エラーの責任は著者に残ります。
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.
このテーマに関する最初のインターネットドラフトは2003年2月に投稿されました。この文書は2003年6月20日にRFCエディターに提出され、8月19日に改訂版に戻り、2003年9月5日に再提出されました。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123] Braden、R.、ed。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[RFC1535] Gavron, E., "A Security Problem and Proposed Correction With Widely Deployed DNS Software", RFC 1535, October 1993.
[RFC1535] Gavron、E。、「セキュリティ問題と広く展開されたDNSソフトウェアによる修正の提案」、RFC 1535、1993年10月。
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738] Berners-Lee、T.、Masinter、L。およびM. McCahill、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz、R。およびR. Bush、「DNS仕様の説明」、RFC 2181、1997年7月。
[RFC2368] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
[RFC2368] Hoffman、P.、Masinter、L。およびJ. Zawinski、「The Mailto URL Scheme」、RFC 2368、1998年7月。
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396] Berners-Lee、T.、Fielding、R。and L. Masinter、「Uniform Resource Identiers（URI）：Generic Syntax」、RFC 2396、1998年8月。
[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.
[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、1999年6月。
[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821] Klensin、J.、ed。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、P.、ed。、「インターネットメッセージフォーマット」、RFC 2822、2001年4月。
[RFC3490] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[RFC3491] Hoffman、P。およびM. Blanchet、「NamePrep：Internationalized Domain Name（IDN）のStringPrepプロファイル」、RFC 3491、2003年3月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492] Costello、A。、「Punycode：Applications（IDNA）の国際化ドメイン名のUnicodeのブートストリングエンコーディング」、RFC 3492、2003年3月。
[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.
[ASCII] American National Standards Institute（以前の米国標準研究所）、「情報交換のための米国コード」、ANSI X3.4-1968。ANSI X3.4-1968は、わずかな変更で新しいバージョンに置き換えられましたが、1968年のバージョンはインターネットにとって決定的なままです。
[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
[domainlist]インターネットが割り当てられた数字の権限（IANA）、現在のトップレベルドメインの無題のアルファベット順リスト。http://data.iana.org/tld/tlds-alpha-by-domain.txt ftp://data.iana.org/tld/tlds-alpha-by-domain.txt
[ISO.3166.1988] International Organization for Standardization, "Codes for the representation of names of countries, 3rd edition", ISO Standard 3166, August 1988.
[ISO.3166.1988]国際標準化機関、「国の名前の表現のためのコード、第3版」、ISO Standard 3166、1988年8月。
[JET] Konishi, K., et al., "Internationalized Domain Names Registration and Administration Guideline for Chinese, Japanese and Korean", Work in Progress.
[Jet] Konishi、K.、et al。、「国際化されたドメイン名登録および中国語、日本、韓国語の管理ガイドライン」、進行中の作業。
[RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994.
[RFC1591] Postel、J。、「ドメイン名システム構造と委任」、RFC 1591、1994年3月。
[RegRestr] Klensin, J., "Registration of Internationalized Domain Names: Overview and Method", Work in Progress, February 2004.
[Regrestr] Klensin、J。、「国際化されたドメイン名の登録：概要と方法」、Work in Progress、2004年2月。
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
ジョンCクレンシン1770マサチューセッツアベニュー、＃322ケンブリッジ、マサチューセッツ州02140 USA
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
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.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となりますが、著者はすべての権利を保持しています。
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.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78および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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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は、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。