[要約] RFC 6912は、DNSのラベルにUnicodeコードポイントを含めるための原則を定めています。その目的は、国際化ドメイン名（IDN）のサポートを向上させ、異なる言語や文字セットを含むドメイン名を正しく処理することです。
Internet Architecture Board (IAB) A. Sullivan
Request for Comments: 6912 Dyn, Inc.
Category: Informational D. Thaler
ISSN: 2070-1721 Microsoft
J. Klensin
O. Kolkman NLnet Labs April 2013
O. Kolkman NLnet Labs 2013年4月
Principles for Unicode Code Point Inclusion in Labels in the DNS
DNSのラベルにUnicodeコードポイントを含めるための原則
Abstract
概要
Internationalized Domain Names in Applications (IDNA) makes available to DNS zone administrators a very wide range of Unicode code points. Most operators of zones should probably not permit registration of U-labels using the entire range. This is especially true of zones that accept registrations across organizational boundaries, such as top-level domains and, most importantly, the root. It is unfortunately not possible to generate algorithms to determine whether permitting a code point presents a low risk. This memo presents a set of principles that can be used to guide the decision of whether a Unicode code point may be wisely included in the repertoire of permissible code points in a U-label in a zone.
アプリケーションの国際化ドメイン名（IDNA）により、DNSゾーン管理者は非常に幅広いUnicodeコードポイントを利用できるようになります。ゾーンのほとんどのオペレーターは、おそらく範囲全体を使用したUラベルの登録を許可すべきではありません。これは、トップレベルドメイン、最も重要なのはルートなど、組織の境界を越えて登録を受け入れるゾーンに特に当てはまります。残念ながら、コードポイントを許可することによるリスクが低いかどうかを判断するアルゴリズムを生成することはできません。このメモは、Unicodeコードポイントをゾーン内のUラベルの許容コードポイントのレパートリーに賢く含めることができるかどうかの決定を導くために使用できる一連の原則を示しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6912.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6912で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. More-Restrictive Rules Going Up the DNS Tree . . . . . . 6
3. Principles Applicable to All Zones . . . . . . . . . . . . . 6
3.1. Longevity Principle . . . . . . . . . . . . . . . . . . . 6
3.2. Least Astonishment Principle . . . . . . . . . . . . . . 6
3.3. Contextual Safety Principle . . . . . . . . . . . . . . . 7
4. Principles Applicable to All Public Zones . . . . . . . . . . 7
4.1. Conservatism Principle . . . . . . . . . . . . . . . . . 7
4.2. Inclusion Principle . . . . . . . . . . . . . . . . . . . 7
4.3. Simplicity Principle . . . . . . . . . . . . . . . . . . 7
4.4. Predictability Principle . . . . . . . . . . . . . . . . 8
4.5. Stability Principle . . . . . . . . . . . . . . . . . . . 8
5. Principle Specific to the Root Zone . . . . . . . . . . . . . 8
5.1. Letter Principle . . . . . . . . . . . . . . . . . . . . 8
6. Confusion and Context . . . . . . . . . . . . . . . . . . . . 9
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. IAB Members at the Time of Approval . . . . . . . . . . . . . 10
11. Informative References . . . . . . . . . . . . . . . . . . . 10
Operators of a DNS zone need to set policies around what Unicode code points are allowed in labels in that zone. Typically there are a number of important goals to consider when constructing such policies. These include, for instance, avoiding possible visual confusability between two labels, avoiding possible confusion between Fully Qualified Domain Names (FQDNs) and IP address literals, accessibility to the disabled (see "Web Content Accessibility Guidelines (WCAG) 2.0" [WCAG20] for some discussion in a web context), and other usability issues.
DNSゾーンのオペレーターは、そのゾーンのラベルで許可されるUnicodeコードポイントに関するポリシーを設定する必要があります。通常、このようなポリシーを構築する際に考慮すべき重要な目標がいくつかあります。これらには、たとえば、2つのラベル間の視覚的な混同の回避、完全修飾ドメイン名（FQDN）とIPアドレスリテラルの混同の回避、無効化へのアクセス（「Webコンテンツアクセシビリティガイドライン（WCAG）2.0」[WCAG20]を参照）が含まれます。 Webコンテキストでの議論）、およびその他のユーザビリティの問題。
This document provides a set of principles that zone operators can use to construct their code point policies in order to improve usability and clarity and thereby reduce confusion.
このドキュメントでは、使いやすさと明確さを向上させ、それによって混乱を減らすために、ゾーンオペレーターがコードポイントポリシーを構築するために使用できる一連の原則を提供します。
This document uses the following terms.
このドキュメントでは、次の用語を使用します。
A-label: an LDH label that starts with "xn--" and meets all the IDNA requirements, with additional restrictions as explained in Section 2.3.2.1 of the IDNA Definitions document [RFC5890].
A-label：「xn--」で始まり、すべてのIDNA要件を満たすLDHラベル。IDNA定義ドキュメント[RFC5890]のセクション2.3.2.1で説明されている追加の制限があります。
Character: a member of a set of elements used for the organization, control, or representation of data. See Section 2 of the Internationalization Terminology document [RFC6365] for more details.
文字：データの編成、制御、または表現に使用される一連の要素のメンバー。詳細については、国際化用語のドキュメント[RFC6365]のセクション2を参照してください。
Language: a way that humans communicate. The use of language occurs in many forms, the most common of which are speech, writing, and signing. See Section 2 of RFC 6365 for more details.
言語：人間がコミュニケーションする方法。言語の使用は多くの形式で行われ、その最も一般的なものはスピーチ、ライティング、および署名です。詳細については、RFC 6365のセクション2をご覧ください。
LDH label: a string consisting of ASCII letters, digits, and the hyphen, with additional restrictions as explained in Section 2.3.1 of RFC 5890.
LDHラベル：ASCII文字、数字、ハイフンで構成される文字列。RFC5890のセクション2.3.1で説明されているように、追加の制限があります。
Public zone: in this document, a DNS zone that accepts registration requests from organizations outside the zone administrator's own organization. (Whether the zone performs delegation is a separate question. What is important is the diversity of the registration-requesting community.) Note that under this definition, the root zone is a public zone, though one that has a unique function in the DNS.
パブリックゾーン：このドキュメントでは、ゾーン管理者自身の組織外の組織からの登録要求を受け入れるDNSゾーン。 （ゾーンが委任を実行するかどうかは別の問題です。重要なのは、登録要求コミュニティの多様性です。）この定義では、ルートゾーンはパブリックゾーンですが、DNSには独自の機能があります。
Rendering: the display of a string of text. See Section 5 of RFC 6365 for more details.
レンダリング：テキストの文字列の表示。詳細については、RFC 6365のセクション5を参照してください。
Script: a set of graphic characters used for the written form of one or more languages. See Section 2 of RFC 6365 for more details.
スクリプト：1つ以上の言語の書面で使用されるグラフィック文字のセット。詳細については、RFC 6365のセクション2をご覧ください。
U-label: a string of Unicode characters that meets all the IDNA requirements and includes at least one non-ASCII character, with additional restrictions as explained in Section 2.3.2.1 of RFC 5890.
Uラベル：すべてのIDNA要件を満たし、少なくとも1つの非ASCII文字を含むUnicode文字列。RFC5890のセクション2.3.2.1で説明されているように、追加の制限があります。
Writing system: a set of rules for using one or more scripts to write a particular language. See Section 2 of RFC 6365 for more details.
書記体系：1つ以上のスクリプトを使用して特定の言語を書くための一連の規則。詳細については、RFC 6365のセクション2をご覧ください。
This memo does not propose a protocol standard, and the use of words such as "should" follow the ordinary English meaning, and not that laid out in [RFC2119].
このメモはプロトコル標準を提案しておらず、「すべき」などの単語の使用は通常の英語の意味に従い、[RFC2119]で規定されているものではありません。
In recent communications [IABCOMM1] [IABCOMM2], the IAB has emphasized the importance of conservatism in allocating labels conforming to IDNA2008 [RFC5890] [RFC5891] [RFC5892] [RFC5893] [RFC5894] [RFC5895] in DNS zones, and especially in the root zone. Traditional LDH labels in the root zone used only alphabetic characters (i.e., ASCII a-z, which under the DNS also match A-Z). Matters are more complicated with U-labels, however. The IAB communications recommended that U-labels permit only code points with a General_Category (gc) of Ll (Lowercase_Letter), Lo (Other_Letter), or Lm (Modifier_Letter), but noted that for practical considerations other code points might be permitted on a case-by-case basis.
最近の通信[IABCOMM1] [IABCOMM2]で、IABは、DNSゾーンで、特に特に、IDA2008 [RFC5890] [RFC5891] [RFC5892] [RFC5893] [RFC5894] [RFC5895]に準拠するラベルを割り当てる際の保守主義の重要性を強調しています。ルートゾーン。ルートゾーンの従来のLDHラベルは、アルファベット文字のみを使用していました（つまり、ASCII a-z。これはDNSの下でもA-Zに一致します）。ただし、Uラベルの方が問題は複雑です。 IAB通信は、UラベルがGeneral_Category（gc）がLl（小文字_文字）、Lo（その他_文字）、またはLm（修飾子_文字）のコードポイントのみを許可することを推奨しましたが、実際の考慮のため、ケースでは他のコードポイントが許可される場合があることに注意してください-ケースバイケース。
The IAB recommendations do, however, leave some issues open that need to be addressed. It is not clear that all code points permitted under IDNA2008 that have a General_Category of Lo or Lm are appropriate for a zone such as the root zone. To take but one example, the code point U+02BC (MODIFIER LETTER APOSTROPHE) has a General_Category of Lm. In practically every rendering (and we are unaware of an exception), U+02BC is indistinguishable from U+2019 (RIGHT SINGLE QUOTATION MARK), which has a General_Category of Pf (Final_Punctuation). U+02BC will also be read by large numbers of people as being the same character as U+0027 (APOSTROPHE), which has a General_Category of Po (Other_Punctuation), and some computer systems may treat U+02BC as U+0027. U+02BC is PROTOCOL VALID (PVALID) under IDNA2008 (see the IDNA Code Points document [RFC5892]), whereas both other code points are DISALLOWED. So, to begin with, it is plain that not every code point with a General_Category of Ll, Lo, or Lm is consistent with the type of conservatism principle discussed in Section 4.1 below or the previous IAB recommendations.
ただし、IABの推奨事項では、対処する必要のあるいくつかの問題が未解決のままになっています。 IDNA2008で許可されているLoまたはLmのGeneral_Categoryを持つすべてのコードポイントが、ルートゾーンなどのゾーンに適していることは明らかではありません。一例を挙げれば、コードポイントU + 02BC（MODIFIER LETTER APOSTROPHE）のGeneral_CategoryはLmです。実質的にすべてのレンダリングで（例外は認識されていません）、U + 02BCは、Pf（Final_Punctuation）のGeneral_Categoryを持つU + 2019（RIGHT SINGLE QUOTATION MARK）と区別できません。 U + 02BCも、PoのGeneral_Category（Other_Punctuation）を持つU + 0027（APOSTROPHE）と同じ文字として多くの人に読み取られ、一部のコンピューターシステムではU + 02BCをU + 0027として扱う場合があります。 U + 02BCはIDNA2008（IDNAコードポイントドキュメント[RFC5892]を参照）の下ではプロトコル有効（PVALID）ですが、他の両方のコードポイントは無効になっています。したがって、まず、General_CategoryがLl、Lo、またはLmであるすべてのコードポイントが、以下のセクション4.1で説明されている保守主義の原則または以前のIABの推奨事項と一致していないことは明らかです。
To make matters worse, some languages are dependent on code points with General_Category Mc (Spacing_Mark) or General_Category Mn (Nonspacing_Mark). This dependency is particularly common in Indic languages, though not exclusive to them. (At the risk of vastly oversimplifying, the overarching issue is mostly the interaction of complex writing systems and the way Unicode works.) To restrict users of those languages to only code points with General_Category of Ll, Lo, or Lm would be extremely limiting. While DNS labels are not words, or sentences, or phrases (as noted in the next steps for IDN [RFC4690]), they are intended to support useful mnemonics. Mnemonics that diverge wildly from the usual conventions are poor ones, because in not following the usual conventions they are not easy to remember. Also, wide divergence from usual conventions, if not well-justified (and especially in a shared namespace like the root), invites political controversy.
さらに悪いことに、一部の言語はGeneral_Category Mc（Spacing_Mark）またはGeneral_Category Mn（Nonspacing_Mark）のコードポイントに依存しています。この依存関係はインド語の言語で特に一般的ですが、それらに限定されません。 （非常に単純化しすぎるリスクがありますが、全体的な問題は主に複雑な書記体系の相互作用とUnicodeの動作方法です。）これらの言語のユーザーをLl、Lo、またはLmのGeneral_Categoryのコードポイントのみに制限することは非常に制限されます。 DNSラベルは単語、文、またはフレーズではありませんが（IDN [RFC4690]の次のステップで説明されているように）、便利なニーモニックをサポートすることを目的としています。通常の規則から大きく逸脱するニーモニックは、通常の規則に従わないと覚えにくいため、貧弱なニーモニックです。また、通常の規則から大きく外れると、正当化されない場合（特にルートのような共有名前空間の場合）は、政治的な論争を招きます。
Many of the issues above turn out to be relevant to all public zones. Moreover, the overall issue of developing a policy for code point permission is common to all zones that accept A-labels or U-labels for registration. As Section 4.3 of the IDNA Protocol document [RFC5891] says, every registry at every level of the DNS is "expected to establish policies about label registrations".
上記の問題の多くは、すべての公共ゾーンに関連することが判明しています。さらに、コードポイントのアクセス許可に関するポリシーの作成に関する全体的な問題は、登録にAラベルまたはUラベルを受け入れるすべてのゾーンに共通です。 IDNAプロトコルドキュメント[RFC5891]のセクション4.3で述べられているように、DNSのすべてのレベルのすべてのレジストリは「ラベル登録に関するポリシーを確立することが期待されています」。
For reasons of sound management, it is not desirable to decide whether to permit a given code point only when an application containing that code point is pending. That approach reduces predictability and is bound to appear subject to special pleas. It is better instead to produce the rules governing acceptance of code points in advance.
適切な管理の理由から、特定のコードポイントを含むアプリケーションが保留中の場合にのみ、そのコードポイントを許可するかどうかを決定することは望ましくありません。このアプローチは予測可能性を低下させ、特別な嘆願の対象となるように見えます。代わりに、コードポイントの受け入れを管理するルールを事前に作成することをお勧めします。
As is evident from the foregoing discussion about the Letter and Mark categories, it is simply not possible to make code point decisions algorithmically. If it were possible to develop such an algorithm, it would already exist: the DNS is hardly unique in needing to impose restrictions on code points while accommodating many different linguistic communities. Nevertheless, new guidelines can be made by starting from overarching principles. These guidelines act more as meta-rules, leading to the establishment of other rules about the inclusion and exclusion of particular code points in labels in a given zone, always based on the list of code points permitted by IDNA.
レターとマークのカテゴリに関する前述の説明から明らかなように、コードポイントをアルゴリズムで決定することは不可能です。このようなアルゴリズムを開発することができれば、すでに存在しています。DNSは、多くの異なる言語コミュニティに対応しながらコードポイントに制限を課す必要があるという点で、ほとんど一意ではありません。それにもかかわらず、包括的なガイドラインから始めることにより、新しいガイドラインを作成できます。これらのガイドラインはメタルールとして機能し、常にIDNAによって許可されたコードポイントのリストに基づいて、特定のゾーンのラベルに特定のコードポイントを含めるか除外するかに関する他のルールを確立します。
A set of principles derived from the above ideas follows in Sections 3 through 5 below. Such principles fall into three categories. Some principles apply to every DNS zone. Some additional principles apply to all public zones, including the root zone. Finally, other principles apply only to the root zone. This means that zones higher in the DNS tree tend to have more restrictive rules (since additional principles apply), and zones lower in the DNS tree tend to have less restrictive rules, since they are used within a more narrow context. In general, the relevant context for a principle is that of the zone, not that of a given subset of the user community; for the root zone, for example, the context is "the entire Internet population".
上記のアイデアから導き出された一連の原則は、以下のセクション3から5に続きます。このような原則は3つのカテゴリに分類されます。いくつかの原則がすべてのDNSゾーンに適用されます。ルートゾーンを含むすべてのパブリックゾーンにいくつかの追加の原則が適用されます。最後に、他の原則はルートゾーンにのみ適用されます。つまり、DNSツリーの上位のゾーンは（追加の原則が適用されるため）より制限の厳しいルールを持つ傾向があり、DNSツリーの下位のゾーンはより狭いコンテキスト内で使用されるため、制限の少ないルールを持つ傾向があります。一般に、原則に関連するコンテキストはゾーンのコンテキストであり、ユーザーコミュニティの特定のサブセットのコンテキストではありません。たとえば、ルートゾーンの場合、コンテキストは「インターネット人口全体」です。
Unicode properties of a code point ought to be stable across the versions of Unicode that users of the zone are likely to have installed. Because it is possible for the properties of a code point to change between Unicode versions, a good way to predict such stability is to ensure that a code point has in fact been stable for multiple successive versions of Unicode. This principle is related to the Stability Principle in Section 4.5.
コードポイントのUnicodeプロパティは、ゾーンのユーザーがインストールしている可能性が高いUnicodeのバージョン間で安定している必要があります。 Unicodeバージョン間でコードポイントのプロパティが変更される可能性があるため、そのような安定性を予測する良い方法は、コードポイントが実際に複数のバージョンのUnicodeに対して安定していることを確認することです。この原則は、セクション4.5の安定性原理に関連しています。
The more diverse the community using the zone, the greater the importance of following this principle. The policy for a leaf zone in the DNS might only require stability across two Unicode versions, whereas a more public zone might require stability across four or more releases before the code point's properties are considered long-lived and stable.
ゾーンを使用するコミュニティが多様化するほど、この原則に従うことの重要性が高くなります。 DNSのリーフゾーンのポリシーでは、2つのUnicodeバージョン間でのみ安定性が必要になる場合がありますが、より多くのパブリックゾーンでは、コードポイントのプロパティが長期間有効で安定していると見なされる前に、4つ以上のリリースで安定性が必要になる場合があります。
Every zone administrator should be sensitive to the likely use of a code point to be permitted, particularly taking into account the population likely to use the zone. Zone administrators should especially consider whether a candidate code point could present difficulty if the code point is encountered outside the usual linguistic circumstances. By the same token, the failure to support a code point that is normal in some linguistic circumstances could be very surprising for users likely to encounter the names in that circumstance.
すべてのゾーン管理者は、特にゾーンを使用する可能性のある人口を考慮に入れて、許可されるコードポイントの使用の可能性に敏感でなければなりません。ゾーン管理者は、コードポイントが通常の言語環境の外で発生した場合に、コードポイント候補が問題を引き起こす可能性があるかどうかを特に検討する必要があります。同様に、一部の言語環境では通常のコードポイントをサポートできないことは、その状況で名前に遭遇する可能性が高いユーザーにとっては非常に驚くべきことです。
Every zone administrator should be sensitive to ways in which a code point that is permitted could be used in support of malicious activity. This is not a completely new problem: the digit 1 and the lowercase letter l are, for instance, easily confused in many contexts. The very large repertoire of code points in Unicode (even just the subset permitted for IDNs) makes the problem somewhat worse, just because of the scale.
すべてのゾーン管理者は、許可されたコードポイントが悪意のあるアクティビティのサポートに使用される可能性がある方法に敏感でなければなりません。これは完全に新しい問題ではありません。たとえば、数字の1と小文字のlは、多くのコンテキストで混同されやすいです。 Unicodeのコードポイントのレパートリーが非常に大きいため（IDNに許可されているサブセットだけでも）、規模のせいで問題が多少悪化します。
Public zones are, by definition, zones that are shared by different groups of people. Therefore, any decision to permit a code point in a public zone (including the root) should be as conservative as practicable. Doubts should always be resolved in favor of rejecting a code point for inclusion rather than in favor of including it, in order to minimize risk.
パブリックゾーンは、定義上、さまざまなグループの人々が共有するゾーンです。したがって、パブリックゾーン（ルートを含む）でコードポイントを許可する決定は、実行可能な限り控えめにする必要があります。リスクを最小限に抑えるには、コードポイントを含めるよりも、コードポイントを含めることを拒否して、疑問を常に解決する必要があります。
Just as IDNA2008 starts from the principle that the Unicode range is excluded, and then adds code points according to derived properties of the code points, so a public zone should only permit inclusion of a code point if it is known to be "safe" in terms of usability and confusability within the context of that zone. The default treatment of a code point should be that it is excluded.
IDNA2008がUnicodeの範囲を除外するという原則から始まり、コードポイントの派生プロパティに従ってコードポイントを追加するのと同じように、パブリックゾーンでは、コードポイントの包含が許可されているのは、コードポイントが「安全」であることがわかっている場合のみです。そのゾーンのコンテキスト内でのユーザビリティと混乱の条件。コードポイントのデフォルトの処理では、コードポイントを除外する必要があります。
The rules for determining whether a code point is to be included should be simple enough that they are readily understood by someone with a moderate background in the DNS and Unicode issues. This principle does not mean that a completely naive person needs to be able to understand the rationale for including a code point, but it does mean that if the reason for inclusion of a very peculiar code point, even a safe one, is too difficult to understand, the code point would not be permitted.
コードポイントを含めるかどうかを決定するためのルールは、DNSとUnicodeの問題について中程度の経歴を持つ人がすぐに理解できるように、単純である必要があります。この原則は、完全にナイーブな人がコードポイントを含める理由を理解できる必要があることを意味しませんが、非常に奇妙なコードポイントを含める理由が安全なものであっても、コードポイントは許可されません。
The meaning of "simple" or "readily understood" is context-dependent. For instance, the root zone has to serve everyone in the world; for practical purposes, this means that the reasons for including a code point need to be comprehensible even to people who cannot use the script where the code point is found. In a zone that permits a constrained subset of Unicode characters (for instance, only those needed to write a single alphabetic language) and that supports a clearly delineated linguistic community (for instance, the speakers of a single language with well-understood written conventions), more complicated rules might be acceptable. Compare this principle with the Least Astonishment Principle in Section 3.2.
「シンプル」または「すぐに理解できる」の意味は、状況によって異なります。たとえば、ルートゾーンは世界中のすべての人にサービスを提供する必要があります。つまり、実際的な目的では、コードポイントが含まれている理由は、コードポイントが見つかったスクリプトを使用できない人でも理解できる必要があります。 Unicode文字の制限されたサブセット（たとえば、単一のアルファベット言語を記述するために必要なもののみ）を許可し、明確に区切られた言語コミュニティ（たとえば、よく理解された表記規則を持つ単一言語の話者）をサポートするゾーン内、より複雑なルールが許容される場合があります。この原則をセクション3.2の最小驚き原則と比較してください。
The rules for determining whether a code point is to be included should be predictable enough that those with the requisite understanding of DNS, IDNA, and Unicode will usually reach the same conclusion. This is not a requirement for algorithmic treatment of code points; as previously noted, that is not possible. Rather, it is to say that the consistent application of professional judgment is likely to yield the same results; combined with the principle in Section 4.1, when results are not predictable, the anomalous code point would not be permitted.
コードポイントを含めるかどうかを決定するためのルールは、DNS、IDNA、およびUnicodeの必要な理解がある人が通常同じ結論に達することができるように十分に予測可能である必要があります。これは、コードポイントのアルゴリズム処理の要件ではありません。前述のとおり、それは不可能です。むしろ、専門家の判断を一貫して適用することで同じ結果が得られる可能性が高いと言えます。セクション4.1の原則と組み合わせると、結果が予測できない場合、異常なコードポイントは許可されません。
Just as in Section 4.3, this principle tends to cause more restriction the more diverse the community using the zone; it is most restrictive for the root zone. This is because what is predictable within a given language community is possibly very surprising across languages.
セクション4.3と同様に、この原則は、ゾーンを使用するコミュニティが多様化するほど、制限を増やす傾向があります。これはルートゾーンに対して最も制限的です。これは、特定の言語コミュニティ内で予測可能なことが言語間で非常に驚くべきことである可能性があるためです。
Once a code point is permitted, it is at least very hard to stop permitting that code point. In public zones (including the root), the list of code points to be permitted should change very slowly, if at all, and usually only in the direction of permitting an addition as time and experience indicate that inclusion of such a code point is both safe and consistent with these principles.
コードポイントが許可されると、そのコードポイントの許可を停止することは少なくとも非常に困難になります。パブリックゾーン（ルートを含む）では、許可されるコードポイントのリストは非常にゆっくりと変更する必要があります。通常、時間と経験から、そのようなコードポイントを含めることは両方とも可能であるため、追加を許可する方向にのみ追加を許可する必要があります。安全でこれらの原則と一致しています。
"Requirements for Internet Hosts - Application and Support" [RFC1123] notes that top-level labels "will be alphabetic". In the absence of widespread agreement about the force of that note, prudence suggests that U-labels in the root zone should exclude code points that are not normally used to write words, or that are in some cases normally used for purposes other than writing words. This is not the same as using Unicode's General_Category to include only letters. It is a restriction that expands the possible class of included code points beyond the Unicode letters, but only expands so far as to include the things that are normally used to create words. Under this principle, code points with (for example) General_Category Mn (Nonspacing_Mark) might be included -- but only those that are used to write words and not (for instance) musical symbols. In addition, such marks should only be used within a label in ways that they would be used when making a word: combinations that would be nonsense when used in a word should also be rejected when tried in DNS labels. This principle should be applied as narrowly as possible; as the next steps for IDN document [RFC4690] says, "While DNS labels may conveniently be used to express words in many circumstances, the goal is not to express words (or sentences or phrases), but to permit the creation of unambiguous labels with good mnemonic value".
「インターネットホストの要件-アプリケーションとサポート」[RFC1123]では、トップレベルのラベルは「アルファベット順」であると記載されています。その注意の力についての広範な合意がない場合、慎重さは、ルートゾーンのUラベルが、通常は単語の記述に使用されない、または場合によっては通常は単語の記述以外の目的で使用されるコードポイントを除外することを示唆しています。これは、UnicodeのGeneral_Categoryを使用して文字のみを含めるのとは異なります。含まれるコードポイントの可能なクラスをUnicode文字を超えて拡張するのは制限ですが、通常は単語の作成に使用されるものだけが含まれるまで拡張されます。この原則の下では、（たとえば）General_Category Mn（Nonspacing_Mark）のコードポイントが含まれる可能性がありますが、（たとえば）音楽記号ではなく、単語の記述に使用されるもののみが含まれます。さらに、そのようなマークは、単語を作成するときに使用される方法でのみラベル内で使用する必要があります。単語で使用すると意味をなさない組み合わせも、DNSラベルで試行すると拒否されます。この原則は可能な限り狭く適用する必要があります。 IDNドキュメント[RFC4690]の次のステップが示すように、「DNSラベルは多くの状況で単語を表現するのに便利に使用できますが、目標は単語（または文やフレーズ）を表現することではなく、明確なラベルの作成を許可することです。良いニーモニック値」。
While many discussions of confusion have focused on characters, e.g., whether two characters are confusable with each other (and under what circumstances), a focus on characters alone could lead to the prohibition of very large numbers of labels, including many that present little risk. Instead, the focus should be on whether one label is confusable with another. For example, if a label contains several characters that are distinct to a particular script, and all of its characters are from that script, it is inherently not confusable with a label from any other script no matter what other characters might appear in it. Another label that lacks those distinguishing characters might be a problem. The notion extends from labels to domain names, in the sense that distinguishing characters used in a higher-level label may set expectations with respect to the characters in the lower-level labels. This expectation might be regarded as a benefit, but it is also a problem, since there is no technical way to require consistent policies in delegated namespaces.
混乱についての多くの議論は文字に焦点を合わせてきましたが、たとえば2つの文字が互いに混同されやすいかどうか（そしてどのような状況下で）、文字だけに焦点を当てると、ほとんどリスクのないラベルを含む非常に多数のラベルの禁止につながる可能性があります。代わりに、1つのラベルが別のラベルと混同されるかどうかに焦点を当てる必要があります。たとえば、ラベルに特定のスクリプトとは異なる複数の文字が含まれていて、そのすべての文字がそのスクリプトからのものである場合、他の文字がどのように表示されても、他のスクリプトのラベルと本質的に混同されません。これらの特徴的な文字が不足している別のラベルが問題になる可能性があります。この概念は、ラベルからドメイン名まで拡張されます。つまり、上位レベルのラベルで使用される文字を区別することにより、下位レベルのラベルの文字に関して期待が設定される可能性があります。この期待は利点と見なされるかもしれませんが、委任された名前空間で一貫したポリシーを要求する技術的な方法がないため、これも問題です。
The principles outlined in this document can be applied when considering any range of Unicode code points for possible inclusion in a DNS zone. It is worth observing that doing anything (especially in light of Section 4.5) implicitly disadvantages communities with a writing system not yet well understood and not represented in the technical and policy communities involved in the discussion. That disadvantage is to be guarded against as much as practical, but is effectively impossible to prevent (while still taking action) in light of imperfect human knowledge.
このドキュメントで概説されている原則は、DNSゾーンに含まれる可能性がある任意の範囲のUnicodeコードポイントを検討するときに適用できます。 （特にセクション4.5に照らして）何かを行うと、まだ十分に理解されておらず、ディスカッションに関与する技術コミュニティやポリシーコミュニティに表されていないライティングシステムによって、コミュニティに暗黙の不利益が生じることは注目に値します。その不利な点は、可能な限り回避する必要がありますが、人間の不完全な知識に照らして（まだ行動を起こしながら）防止することは事実上不可能です。
The principles outlined in this memo are intended to improve usability and clarity and thereby reduce confusion among different labels. While these principles may contribute to reduction of risk, they are not sufficient to provide a comprehensive internationalization policy for zone management.
このメモで概説されている原則は、使いやすさと明確さを改善し、それによって異なるラベル間の混乱を減らすことを目的としています。これらの原則はリスクの低減に貢献するかもしれませんが、ゾーン管理のための包括的な国際化ポリシーを提供するには十分ではありません。
Additional discussion of security considerations can be found in the Unicode Security Considerations [UTR36].
セキュリティに関する考慮事項の詳細については、Unicodeのセキュリティに関する考慮事項[UTR36]を参照してください。
The authors thank the participants in the IAB Internationalization program for the discussion of the ideas in this memo, particularly Marc Blanchet. In addition, Stephane Bortzmeyer, Paul Hoffman, Daniel Kalchev, Panagiotis Papaspiliopoulos, and Vaggelis Segredakis made specific comments.
著者は、このメモのアイデア、特にマークブランシェの議論について、IAB国際化プログラムの参加者に感謝します。さらに、Stephane Bortzmeyer、Paul Hoffman、Daniel Kalchev、Panagiotis Papaspiliopoulos、およびVaggelis Segredakisが具体的なコメントをしました。
Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Alissa Cooper Spencer Dawkins Joel Halpern Russ Housley David Kessens Danny McPherson Jon Peterson Dave Thaler Hannes Tschofenig
バーナードアボバジャリアルコマルクブランシェロスカロンアリッサクーパースペンサードーキンスジョエルハルパーンラスハウズリーデビッドケセンスダニーマクファーソンジョンピーターソンデイブターラーハネスチョーフェニグ
[IABCOMM1] Internet Architecture Board, "IAB Statement: 'The interpretation of rules in the ICANN gTLD Applicant Guidebook'", February 2012, <http://www.iab.org/ documents/correspondence-reports-documents/201/>.
[IABCOMM1]インターネットアーキテクチャボード、「IABステートメント：「ICANN gTLD申請者ガイドブックのルールの解釈」」、2012年2月、<http://www.iab.org/documents/correspondence-reports-documents/201/> 。
[IABCOMM2] Internet Architecture Board, "Response to ICANN questions concerning 'The interpretation of rules in the ICANN gTLD Applicant Guidebook'", March 2012, <http://www.iab.org/ documents/correspondence-reports-documents/201/>.
[IABCOMM2]インターネットアーキテクチャボード、「「ICANN gTLD申請者ガイドブックのルールの解釈」に関するICANNの質問への応答」、2012年3月、<http://www.iab.org/documents/correspondence-reports-documents/201 />。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123] Braden、R。、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006.
[RFC4690] Klensin、J.、Faltstrom、P.、Karp、C。、およびIAB、「Review and Recommendations for Internationalized Domain Names（IDNs）」、RFC 4690、2006年9月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890] Klensin、J。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、2010年8月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891] Klensin、J。、「Internationalized Domain Names in Applications（IDNA）：Protocol」、RFC 5891、2010年8月。
[RFC5892] Faltstrom, P., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, August 2010.
[RFC5892] Faltstrom、P。、「アプリケーションのUnicodeコードポイントと国際化ドメイン名（IDNA）」、RFC 5892、2010年8月。
[RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, August 2010.
[RFC5893] Alvestrand、H。およびC. Karp、「Right-to-Left Scripts for Internationalized Domain Names for Applications（IDNA）」、RFC 5893、2010年8月。
[RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, August 2010.
[RFC5894] Klensin、J。、「アプリケーションの国際化ドメイン名（IDNA）：背景、説明、および理論的根拠」、RFC 5894、2010年8月。
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008", RFC 5895, September 2010.
[RFC5895] Resnick、P。およびP. Hoffman、「アプリケーションの国際化ドメイン名のマッピング文字（IDNA）2008」、RFC 5895、2010年9月。
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, September 2011.
[RFC6365] Hoffman、P。およびJ. Klensin、「IETFの国際化で使用される用語」、BCP 166、RFC 6365、2011年9月。
[UTR36] Davis, M. and M. Suignard, "Unicode Security Considerations", Unicode Technical Report #36, July 2012.
[UTR36] Davis、M.およびM. Suignard、「Unicode Security Considerations」、Unicode Technical Report＃36、2012年7月。
[WCAG20] W3C, "Web Content Accessibility Guidelines (WCAG) 2.0", W3C Recommendation, December 2008, <http://www.w3.org/TR/2008/REC-WCAG20-20081211/>.
[WCAG20] W3C、「Webコンテンツアクセシビリティガイドライン（WCAG）2.0」、W3C勧告、2008年12月、<http://www.w3.org/TR/2008/REC-WCAG20-20081211/>。
Authors' Addresses
著者のアドレス
Andrew Sullivan Dyn, Inc. 150 Dow St Manchester, NH 03101 USA
Andrew Sullivan Dyn、Inc. 150 Dow St Manchester、NH 03101 USA
EMail: asullivan@dyn.com
Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052 USA
だゔぇ てゃぇｒ みｃろそｆｔ おね みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２ うさ
EMail: dthaler@microsoft.com
John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 USA
John C Klensin 1770 Massachusetts Ave、Ste 322 Cambridge、MA 02140 USA
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Olaf Kolkman NLnet Labs Science Park 400 Amsterdam 1098 XH The Netherlands
Olaf Kolkman NLnet Labs Science Park 400アムステルダム1098 XHオランダ
EMail: olaf@NLnetLabs.nl