[要約] RFC 5893は、IDNAにおける右から左へのスクリプト（言語）に関する規格です。その目的は、国際化ドメイン名（IDN）のアプリケーションで、右から左へのスクリプトを正しく処理するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) H. Alvestrand, Ed.
Request for Comments: 5893 Google
Category: Standards Track C. Karp
ISSN: 2070-1721 Swedish Museum of Natural History
August 2010
Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)
アプリケーションの国際化されたドメイン名の右から左のスクリプト（IDNA）
Abstract
概要
The use of right-to-left scripts in Internationalized Domain Names (IDNs) has presented several challenges. This memo provides a new Bidi rule for Internationalized Domain Names for Applications (IDNA) labels, based on the encountered problems with some scripts and some shortcomings in the 2003 IDNA Bidi criterion.
国際化されたドメイン名（IDNS）での左右スクリプトの使用は、いくつかの課題を提示しました。このメモは、2003年のIDNA BIDI基準のいくつかのスクリプトといくつかの欠点に遭遇した問題に基づいて、アプリケーション（IDNA）ラベルの国際化ドメイン名（IDNA）ラベルの新しいBIDIルールを提供します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、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/rfc5893.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5893で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Purpose and Applicability . . . . . . . . . . . . . . . . 2
1.2. Background and History . . . . . . . . . . . . . . . . . . 3
1.3. Structure of the Rest of This Document . . . . . . . . . . 3
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Bidi Rule . . . . . . . . . . . . . . . . . . . . . . . . 6
3. The Requirement Set for the Bidi Rule . . . . . . . . . . . . 6
4. Examples of Issues Found with RFC 3454 . . . . . . . . . . . . 9
4.1. Dhivehi . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Yiddish . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Strings with Numbers . . . . . . . . . . . . . . . . . . . 12
5. Troublesome Situations and Guidelines . . . . . . . . . . . . 12
6. Other Issues in Need of Resolution . . . . . . . . . . . . . . 13
7. Compatibility Considerations . . . . . . . . . . . . . . . . . 14
7.1. Backwards Compatibility Considerations . . . . . . . . . . 14
7.2. Forward Compatibility Considerations . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 17
The purpose of this document is to establish a rule that can be applied to Internationalized Domain Name (IDN) labels in Unicode form (U-labels) containing characters from scripts that are written from right to left. It is part of the revised IDNA protocol [RFC5891].
このドキュメントの目的は、右から左に書かれたスクリプトの文字を含むUnicodeフォーム（Uラベル）の国際化ドメイン名（IDN）ラベルに適用できるルールを確立することです。これは、改訂されたIDNAプロトコル[RFC5891]の一部です。
When labels satisfy the rule, and when certain other conditions are satisfied, there is only a minimal chance of these labels being displayed in a confusing way by the Unicode bidirectional display algorithm.
ラベルがルールを満たし、特定の他の条件が満たされている場合、ユニコード双方向ディスプレイアルゴリズムによってこれらのラベルが混乱して表示される可能性は最小限に抑えられます。
The other normative documents in the IDNA2008 document set establish criteria for valid labels, including listing the permitted characters. This document establishes additional validity criteria for labels in scripts normally written from right to left.
IDNA2008ドキュメントセットのその他の規範ドキュメントは、許可された文字のリストを含む有効なラベルの基準を確立します。このドキュメントは、通常右から左に書かれたスクリプトでラベルの追加の妥当性基準を確立します。
This specification is not intended to place any requirements on domain names that do not contain characters from such scripts.
この仕様は、そのようなスクリプトの文字が含まれていないドメイン名に要件を配置することを意図したものではありません。
The "Stringprep" specification [RFC3454], part of IDNA2003, made the following statement in its Section 6 on the Bidi algorithm:
IDNA2003の一部である「StringPrep」仕様[RFC3454]は、Bidiアルゴリズムに関するセクション6で次の声明を作成しました。
3) If a string contains any RandALCat character, a RandALCat character MUST be the first character of the string, and a RandALCat character MUST be the last character of the string.
3) 文字列にrandalcat文字が含まれている場合、randalcat文字は文字列の最初の文字でなければならず、randalcat文字は文字列の最後の文字でなければなりません。
(A RandALCat character is a character with unambiguously right-to-left directionality.)
（Randalcatのキャラクターは、左から左への方向性を明確に持つキャラクターです。）
The reasoning behind this prohibition was to ensure that every component of a displayed domain name has an unambiguously preferred direction. However, this made certain words in languages written with right-to-left scripts invalid as IDN labels, and in at least one case (Dhivehi) meant that all the words of an entire language were forbidden as IDN labels.
この禁止の背後にある理由は、表示されたドメイン名のすべてのコンポーネントが明確に好ましい方向を持っていることを保証することでした。ただし、これにより、左から左のスクリプトで書かれた言語で特定の単語がIDNラベルとして無効になり、少なくとも1つのケース（Dhivehi）では、言語全体のすべての単語がIDNラベルとして禁止されていることがわかりました。
This is illustrated below with examples taken from the Dhivehi and Yiddish languages, as written with the Thaana and Hebrew scripts, respectively.
これは、それぞれThaanaとHebrewの脚本で書かれているように、DhivehiとYiddishの言語から撮影した例で以下に示されています。
RFC 3454 did not explicitly state the requirement to be fulfilled. Therefore, it is impossible to determine whether a simple relaxation of the rule would continue to fulfill the requirement.
RFC 3454は、履行する要件を明示的に述べていませんでした。したがって、ルールの単純な緩和が要件を満たすかどうかを判断することは不可能です。
While this document specifies rules quite different from RFC 3454, most reasonable labels that were allowed under RFC 3454 will also be allowed under this specification (the most important example of non-permitted labels being labels that mix Arabic and European digits (AN and EN) inside an RTL label, and labels that use AN in an LTR label -- see Section 1.4 for terminology), so the operational impact of using the new rule in the updated IDNA specification is limited.
このドキュメントは、RFC 3454とはまったく異なるルールを指定していますが、RFC 3454で許可された最も合理的なラベルもこの仕様の下で許可されます（承認されていないラベルの最も重要な例は、アラビア語とヨーロッパの数字（ANとEN）を組み合わせたラベルです。RTLラベル内の内部、およびLTRラベルで使用するラベル（用語についてはセクション1.4を参照）を参照してください。
Section 2 defines a rule, the "Bidi rule", which can be used on a domain name label to check how safe it is to use in a domain name of possibly mixed directionality. The primary initial use of this rule is as part of the IDNA2008 protocol [RFC5891].
セクション2には、ドメイン名ラベルで使用するルール「Bidiルール」を定義して、おそらく混合方向性のドメイン名で使用するのがどれだけ安全かを確認できます。このルールの主要な初期使用は、IDNA2008プロトコル[RFC5891]の一部です。
Section 3 sets out the requirements for defining the Bidi rule.
セクション3では、BIDIルールを定義するための要件を定めています。
Section 4 gives detailed examples that serve as justification for the new rule.
セクション4では、新しいルールの正当化として役立つ詳細な例を示します。
Section 5 to Section 8 describe various situations that can occur when dealing with domain names with characters of different directionality.
セクション5からセクション8から、異なる方向性の文字を持つドメイン名を扱うときに発生する可能性のあるさまざまな状況について説明します。
Only Section 1.4 and Section 2 are normative.
セクション1.4とセクション2のみが規範的です。
The terminology used to describe IDNA concepts is defined in the Definitions document [RFC5890].
IDNAの概念を説明するために使用される用語は、定義ドキュメント[RFC5890]で定義されています。
The terminology used for the Bidi properties of Unicode characters is taken from the Unicode Standard [Unicode52].
Unicode文字のBidi特性に使用される用語は、Unicode標準[Unicode52]から取得されます。
The Unicode Standard specifies a Bidi property for each character. That property controls the character's behavior in the Unicode bidirectional algorithm [Unicode-UAX9]. For reference, here are the values that the Unicode Bidi property can have:
Unicode標準は、各文字のBidiプロパティを指定します。そのプロパティは、ユニコード双方向アルゴリズム[Unicode-Uax9]でのキャラクターの動作を制御します。参照のために、Unicode Bidiプロパティが持つことができる値は次のとおりです。
o L - Left to right - most letters in LTR scripts
o L-左から右 - LTRスクリプトのほとんどの文字
o R - Right to left - most letters in non-Arabic RTL scripts
o r-右から左 - アラビア語以外のRTLスクリプトのほとんどの文字
o AL - Arabic letters - most letters in the Arabic script
o al-アラビア文字 - アラビア語の脚本のほとんどの文字
o EN - European Number (0-9, and Extended Arabic-Indic numbers)
o en-ヨーロッパ番号（0-9、およびアラビア語とインディック数の拡張）
o ES - European Number Separator (+ and -)
o ES-ヨーロッパ番号セパレーター（および - ）
o ET - European Number Terminator (currency symbols, the hash sign, the percent sign and so on)
o ET-ヨーロッパ番号ターミネーター（通貨記号、ハッシュサイン、パーセントサインなど）
o AN - Arabic Number; this encompasses the Arabic-Indic numbers, but not the Extended Arabic-Indic numbers
o an-アラビア語番号;これにはアラビア語のインドの数が含まれますが、アラビア語の拡張数字は含まれません
o CS - Common Number Separator (. , / : et al)
o CS -Common Number Separator（。、 /：et al）
o NSM - Nonspacing Mark - most combining accents
o NSM -Nonspacing Mark-ほとんどの組み合わせアクセント
o BN - Boundary Neutral - control characters (ZWNJ, ZWJ, and others)
o BN-境界ニュートラル - コントロール文字（ZWNJ、ZWJなど）
o B - Paragraph Separator
o B-段落分離器
o S - Segment Separator
o S-セグメントセパレーター
o WS - Whitespace, including the SPACE character
o WS-スペース文字を含む空白
o ON - Other Neutrals, including @, &, parentheses, MIDDLE DOT o LRE, LRO, RLE, RLO, PDF - these are "directional control characters" and are not used in IDNA labels.
o on- @、＆、、括弧、中間点o lre、lro、rle、rlo、pdfなどの他のニュートラル - これらは「方向制御文字」であり、IDNAラベルでは使用されていません。
In this memo, we use "network order" to describe the sequence of characters as transmitted on the wire or stored in a file; the terms "first", "next", "previous", "beginning", "end", "before", and "after" are used to refer to the relationship of characters and labels in network order.
このメモでは、「ネットワーク順序」を使用して、ワイヤーに送信された、またはファイルに保存されている文字のシーケンスを記述します。「最初」、「次」、「前」、「始まり」、「終了」、「前」という用語は、ネットワークの順序で文字とラベルの関係を参照するために使用されます。
We use "display order" to talk about the sequence of characters as imaged on a display medium; the terms "left" and "right" are used to refer to the relationship of characters and labels in display order.
「ディスプレイ順」を使用して、ディスプレイメディアで画像化された文字のシーケンスについて話します。「左」と「右」という用語は、表示順序で文字とラベルの関係を参照するために使用されます。
Most of the time, the examples use the abbreviations for the Unicode Bidi classes to denote the directionality of the characters; the example string CS L consists of one character of class CS and one character of class L. In some examples, the convention that uppercase characters are of class R or AL, and lowercase characters are of class L is used -- thus, the example string ABC.abc would consist of three right-to-left characters and three left-to-right characters.
ほとんどの場合、この例では、Unicode Bidiクラスの略語を使用して、文字の方向性を示します。例の文字列CS Lは、クラスCSの1つの文字とクラスLの1つの文字で構成されています。いくつかの例では、大文字の文字がクラスRまたはALであり、小文字の文字がクラスLの条約で使用されます。したがって、例は例です。String ABC.ABCは、3つの右から左の文字と3つの左から右の文字で構成されます。
The directionality of such examples is determined by context -- for instance, in the sentence "ABC.abc is displayed as CBA.abc", the first example string is in network order, the second example string is in display order.
このような例の方向性は、コンテキストによって決定されます。たとえば、「abc.abcはcba.abcとして表示されます」という文に、最初の例の文字列はネットワークの順序です。2番目の例の文字列は表示順序です。
The term "paragraph" is used in the sense of the Unicode Bidi specification [Unicode-UAX9]. It means "a block of text that has an overall direction, either left to right or right to left", approximately; see the "Unicode Bidirectional Algorithm" [Unicode-UAX9] for details.
「段落」という用語は、Unicode Bidi仕様[Unicode-Uax9]の意味で使用されます。それは、「左から右または右から左の全体的な方向を持つテキストのブロック」を意味します。詳細については、「Unicode双方向アルゴリズム」[Unicode-Uax9]を参照してください。
"RTL" and "LTR" are abbreviations for "right to left" and "left to right", respectively.
「RTL」と「LTR」は、それぞれ「右から左」と「左から右」の略語です。
An RTL label is a label that contains at least one character of type R, AL, or AN.
RTLラベルは、タイプR、AL、またはANの少なくとも1つの文字を含むラベルです。
An LTR label is any label that is not an RTL label.
LTRラベルは、RTLラベルではないラベルです。
A "Bidi domain name" is a domain name that contains at least one RTL label. (Note: This definition includes domain names containing only dots and right-to-left characters. Providing a separate category of "RTL domain names" would not make this specification simpler, so it has not been done.)
「Bidiドメイン名」は、少なくとも1つのRTLラベルを含むドメイン名です。（注：この定義には、ドットのみと左から左の文字のみを含むドメイン名が含まれています。「RTLドメイン名」の個別のカテゴリを提供すると、この仕様がより簡単になりないため、実行されていません。）
The following rule, consisting of six conditions, applies to labels in Bidi domain names. The requirements that this rule satisfies are described in Section 3. All of the conditions must be satisfied for the rule to be satisfied.
6つの条件で構成される次のルールは、Bidiドメイン名のラベルに適用されます。この規則が満たす要件は、セクション3で説明されています。すべての条件を満たすには、すべての条件を満たす必要があります。
1. The first character must be a character with Bidi property L, R, or AL. If it has the R or AL property, it is an RTL label; if it has the L property, it is an LTR label.
1. 最初のキャラクターは、Bidi Property L、R、またはAlのキャラクターでなければなりません。RまたはALプロパティがある場合、RTLラベルです。Lプロパティがある場合、LTRラベルです。
2. In an RTL label, only characters with the Bidi properties R, AL, AN, EN, ES, CS, ET, ON, BN, or NSM are allowed.
2. RTLラベルでは、BidiプロパティR、Al、An、En、ES、CS、ET、ON、BN、またはNSMを持つ文字のみが許可されています。
3. In an RTL label, the end of the label must be a character with Bidi property R, AL, EN, or AN, followed by zero or more characters with Bidi property NSM.
3. RTLラベルでは、ラベルの終わりは、Bidi Property R、Al、EN、またはANのキャラクターでなければならず、その後にBidi Property NSMのゼロ以上の文字が続きます。
4. In an RTL label, if an EN is present, no AN may be present, and vice versa.
4. RTLラベルでは、ENが存在する場合、存在しない場合があり、その逆も同様です。
5. In an LTR label, only characters with the Bidi properties L, EN, ES, CS, ET, ON, BN, or NSM are allowed.
5. LTRラベルでは、BIDIプロパティL、EN、ES、CS、ET、ON、BN、またはNSMを持つ文字のみが許可されています。
6. In an LTR label, the end of the label must be a character with Bidi property L or EN, followed by zero or more characters with Bidi property NSM.
6. LTRラベルでは、ラベルの端はBidi Property LまたはENのキャラクターでなければならず、その後、Bidi Property NSMのゼロ以上の文字が続きます。
The following guarantees can be made based on the above:
次の保証は、上記に基づいて行うことができます。
o In a domain name consisting of only labels that satisfy the rule, the requirements of Section 3 are satisfied. Note that even LTR labels and pure ASCII labels have to be tested.
o ルールを満たすラベルのみで構成されるドメイン名では、セクション3の要件が満たされます。LTRラベルや純粋なASCIIラベルでさえテストする必要があることに注意してください。
o In a domain name consisting of only LDH labels (as defined in the Definitions document [RFC5890]) and labels that satisfy the rule, the requirements of Section 3 are satisfied as long as a label that starts with an ASCII digit does not come after a right-to-left label.
o LDHラベルのみで構成されるドメイン名（定義ドキュメント[RFC5890]で定義されている）とルールを満たすラベルでは、セクション3の要件は、ASCIIの桁から始まるラベルが付いていない限り満たされます。右から左のラベル。
No guarantee is given for other combinations.
他の組み合わせには保証は与えられません。
This document, unlike RFC 3454 [RFC3454], provides an explicit justification for the Bidi rule, and states a set of requirements for which it is possible to test whether or not the modified rule fulfills the requirement.
このドキュメントは、RFC 3454 [RFC3454]とは異なり、BIDIルールの明示的な正当化を提供し、変更されたルールが要件を満たすかどうかをテストできる一連の要件を述べています。
All the text in this document assumes that text containing the labels under consideration will be displayed using the Unicode bidirectional algorithm [Unicode-UAX9].
このドキュメントのすべてのテキストは、検討中のラベルを含むテキストがUnicode双方向アルゴリズム[Unicode-UAX9]を使用して表示されると想定しています。
The requirements proposed are these:
提案されている要件は次のとおりです。
o Label Uniqueness: No two labels, when presented in display order in the same paragraph, should have the same sequence of characters without also having the same sequence of characters in network order, both when the paragraph has LTR direction and when the paragraph has RTL direction. (This is the criterion that is explicit in RFC 3454). (Note that a label displayed in an RTL paragraph may display the same as a different label displayed in an LTR paragraph and still satisfy this criterion.)
o ラベルの一意性：同じ段落で表示順序で表示された場合、2つのラベルは、段落にLTR方向がある場合とパラグラフがRTL方向を持っているときの両方で、ネットワーク順序で同じ文字シーケンスを持たずに同じ文字のシーケンスを持つ必要があります。。（これはRFC 3454で明示的な基準です）。（RTLの段落に表示されているラベルは、LTR段落に表示されている別のラベルと同じものを表示し、この基準を満たしていることに注意してください。）
o Character Grouping: When displaying a string of labels, using the Unicode Bidi algorithm to reorder the characters for display, the characters of each label should remain grouped between the characters delimiting the labels, both when the string is embedded in a paragraph with LTR direction and when it is embedded in a paragraph with RTL direction.
o 文字グループ化：Unicode Bidiアルゴリズムを使用して表示用の文字を並べ替えるラベルの文字列を表示する場合、各ラベルの文字は、文字列がLTR方向の段落に埋め込まれている場合、ラベルを区切る文字間でグループ化されたままにしておく必要があります。RTL方向の段落に埋め込まれている場合。
Several stronger statements were considered and rejected, because they seem to be impossible to fulfill within the constraints of the Unicode bidirectional algorithm. These include:
いくつかのより強力な声明が考慮され、拒否されました。なぜなら、それらは、単コードの双方向アルゴリズムの制約内で満たすことが不可能であると思われるためです。これらには以下が含まれます：
o The appearance of a label should be unaffected by its embedding context. This proved impossible even for ASCII labels; the label "123-A" will have a different display order in an RTL context than in an LTR context. (This particular example is, however, disallowed anyway.)
o ラベルの外観は、その埋め込みコンテキストによって影響を受ける必要があります。これは、ASCIIラベルでも不可能であることが判明しました。ラベル「123-A」は、LTRコンテキストとは異なる表示順序がRTLコンテキストで異なります。（ただし、この特定の例はとにかく許可されていません。）
o The sequence of labels should be consistent with network order. This proved impossible -- a domain name consisting of the labels (in network order) L1.R2.R3.L4 will be displayed as L1.R3.R2.L4 in an LTR context. (In an RTL context, it will be displayed as L4.R3.R2.L1).
o ラベルのシーケンスは、ネットワークの順序と一致する必要があります。これは不可能であることが判明しました - ラベル（ネットワークの順序で）で構成されるドメイン名L1.R2.R3.L4は、LTRコンテキストでL1.R3.R2.L4として表示されます。（RTLコンテキストでは、L4.R3.R2.L1として表示されます）。
o No two domain names should be displayed the same, even under differing directionality. This was shown to be unsound, since the domain name (in network order) ABC.abc will have display order CBA.abc in an LTR context and abc.CBA in an RTL context, while the domain name (network) abc.ABC will have display order abc.CBA in an LTR context and CBA.abc in an RTL context.
o 異なる方向性の下でも、2つのドメイン名を同じように表示する必要はありません。ドメイン名（ネットワークの順序で）ABC.ABCには、ltrコンテキストでdisplay cba.abc、rtlコンテキストでabc.cbaが表示されるため、これは不健全であることが示されました。ドメイン名（ネットワーク）abc.abcはLTRコンテキストでABC.CBAを表示し、RTLコンテキストでCBA.ABCを表示します。
One possible requirement was thought to be problematic, but turned out to be satisfied by a string that obeys the proposed rules:
考えられる要件の1つは問題があると考えられていましたが、提案されたルールに従う文字列によって満たされることが判明しました。
o The Character Grouping requirement should be satisfied when directional controls (LRE, RLE, RLO, LRO, PDF) are used in the same paragraph (outside of the labels). Because these controls affect presentation order in non-obvious ways, by affecting the "sor" and "eor" properties of the Unicode Bidi algorithm, the conditions above require extra testing in order to figure out whether or not they influence the display of the domain name. Testing found that for the strings allowed under the rule presented in this document, directional controls do not influence the display of the domain name.
o 同じ段落（ラベル以外）で方向性コントロール（LRE、RLE、RLO、LRO、PDF）が使用される場合、文字グループ化の要件を満たす必要があります。これらのコントロールは、Unicode Bidiアルゴリズムの「SOR」および「EOR」特性に影響を与えることにより、非自明な方法でプレゼンテーション順序に影響を与えるため、ドメインの表示に影響を与えるかどうかを把握するために、上記の条件には追加のテストが必要なため名前。テストでは、このドキュメントに示されているルールで許可されている文字列について、方向性コントロールがドメイン名の表示に影響しないことがわかりました。
This is still not stated as a requirement, since it did not seem as important as the stated requirements, but it is useful to know that Bidi domain names where the labels satisfy the rule have this property.
これはまだ要件としては記載されていません。これは、指定された要件ほど重要ではないように思われますが、ラベルがルールを満たしているBidiドメイン名がこのプロパティを持っていることを知ることは有用です。
In the following descriptions, first-level bullets are used to indicate rules or normative statements; second-level bullets are commentary.
以下の説明では、第1レベルの弾丸がルールまたは規範的な声明を示すために使用されます。セカンドレベルの弾丸は解説です。
The Character Grouping requirement can be more formally stated as:
文字グループ化の要件は、より正式に述べることができます。
o Let "Delimiterchars" be a set of characters with the Unicode Bidi properties CS, WS, ON. (These are commonly used to delimit labels -- both the FULL STOP and the space are included. They are not allowed in domain labels.)
o 「DelimiterChars」は、Unicode Bidi Properties CS、WS、ONの文字のセットとします。（これらは一般的にラベルを区切るために使用されます - フルストップとスペースの両方が含まれています。ドメインラベルでは許可されていません。）
* ET, though it commonly occurs next to domain names in practice, is problematic: the context R CS L EN ET (for instance A.a1%) makes the label L EN not satisfy the character grouping requirement.
* ETは、一般的に実際にドメイン名の隣で発生しますが、問題は問題です。コンテキストR CS L EN ET（たとえばA.A1％）は、ラベルがキャラクターのグループ化要件を満たさないようにします。
* ES commonly occurs in labels as HYPHEN-MINUS, but could also be used as a delimiter (for instance, the plus sign). It is left out here.
* ESは一般にラベルでハイフン - マイナスとして発生しますが、区切り文字としても使用できます（たとえば、プラス記号）。ここに残されています。
o Let "unproblematic label" be a label that either satisfies the requirements or does not contain any character with the Bidi properties R, AL, or AN and does not begin with a character with the Bidi property EN. (Informally, "it does not start with a number".)
o 「問題のないラベル」を、要件を満たすか、Bidi Properties R、AL、またはANのキャラクターを含まないラベルとし、Bidi Property ENのキャラクターから始めないようにします。（非公式には、「数字から始まりません」。）
A label X satisfies the Character Grouping requirement when, for any Delimiter Character D1 and D2, and for any label S1 and S2 that is an unproblematic label or an empty string, the following holds true:
ラベルXは、デリミタ文字D1およびD2の場合、および問題のないラベルまたは空の文字列であるラベルS1およびS2の場合、文字グループ化要件を満たします。
If the string formed by concatenating S1, D1, X, D2, and S2 is reordered according to the Bidi algorithm, then all the characters of X in the reordered string are between D1 and D2, and no other characters are between D1 and D2, both if the overall paragraph direction is LTR and if the overall paragraph direction is RTL.
S1、d1、x、d2、およびs2を連結することによって形成された文字列がBidiアルゴリズムに従って再注文された場合、並べ替えられた文字列のxのすべての文字はD1とD2の間であり、D1とD2の間には他の文字はありません。全体の段落方向がLTRである場合、および全体的な段落方向がRTLの場合。
Note that the definition is self-referential, since S1 and S2 are constrained to be "legal" by this definition. This makes testing changes to proposed rules a little complex, but does not create problems for testing whether or not a given proposed rule satisfies the criterion.
S1とS2はこの定義によって「合法」に制限されているため、定義は自己参照的であることに注意してください。これにより、提案されたルールへのテストの変更が少し複雑になりますが、特定の提案されたルールが基準を満たすかどうかをテストするための問題は発生しません。
The "zero-length" case represents the case where a domain name is next to something that isn't a domain name, separated by a delimiter character.
「ゼロ長さ」のケースは、ドメイン名がドメイン名ではないものの隣にある場合、区切り文字によって区切られている場合を表します。
Note about the position of BN: The Unicode bidirectional algorithm specifies that a BN has an effect on the adjoining characters in network order, not in display order, and are therefore treated as if removed during Bidi processing ([Unicode-UAX9], Section 3.3.2, rule X9 and Section 5.3). Therefore, the question of "what position does a BN have after reordering" is not meaningful. It has been ignored while developing the rules here.
BNの位置についての注：ユニコード双方向アルゴリズムは、BNが表示順序ではなくネットワーク順序で隣接する文字に影響を与えるため、Bidi処理中に削除されたかのように扱われることを指定します（[Unicode-Uax9]、セクション3.3.2、ルールX9およびセクション5.3）。したがって、「並べ替え後にBNがどの位置に持っているか」という問題は意味がありません。ここでルールを開発する際には無視されています。
The Label Uniqueness requirement can be formally stated as:
ラベルの一意性要件は、次のように正式に述べることができます。
If two non-identical labels X and Y, embedded as for the test above, displayed in paragraphs with the same directionality, are reordered by the Bidi algorithm into the same sequence of code points, the labels X and Y cannot both be legal.
上記のテストのように埋め込まれた2つの非同一ラベルXとYが同じ方向性の段落に表示されている場合、Bidiアルゴリズムによって同じコードポイントのシーケンスに並べ替えられた場合、ラベルXとYは両方とも合法ではありません。
Dhivehi, the official language of the Maldives, is written with the Thaana script. This script displays some of the characteristics of the Arabic script, including its directional properties, and the indication of vowels by the diacritical marking of consonantal base characters. This marking is obligatory, and both two consecutive vowels and syllable-final consonants are indicated with unvoiced combining marks. Every Dhivehi word therefore ends with a combining mark.
モルディブの公用語であるDhivehiは、Thaanaスクリプトで書かれています。このスクリプトには、その方向性特性を含むアラビア語のスクリプトの特性の一部、および子音の基本文字の異なるマーキングによる母音の兆候が表示されます。このマーキングは義務的であり、2つの連続した母音と音節ファイナルの子音の両方が、無声マークで示されています。したがって、すべてのDhivehiの単語は、結合マークで終わります。
The word for "computer", which is romanized as "konpeetaru", is written with the following sequence of Unicode code points:
「コンピター」としてロマン化された「コンピューター」の言葉は、次のUnicodeコードポイントのシーケンスで書かれています。
U+0786 THAANA LETTER KAAFU (AL)
U 0786 Thaana LetterKaafu（al）
U+07AE THAANA OBOFILI (NSM)
u 07ae thaana obofili（nsm）
U+0782 THAANA LETTER NOONU (AL)
u 0782 thaana retter noonu（al）
U+07B0 THAANA SUKUN (NSM)
u 07b0 thaana sukun（NSM）
U+0795 THAANA LETTER PAVIYANI (AL)
U 0795 Thaana LetterPaviyani（al）
U+07A9 THAANA LETTER EEBEEFILI (AL)
u 07a9 thaana lettereebeefili（al）
U+0793 THAANA LETTER TAVIYANI (AL)
U 0793 Thaana Letter Taviyani（al）
U+07A6 THAANA ABAFILI (NSM)
u 07a6 thaana abafili（nsm）
U+0783 THAANA LETTER RAA (AL)
U 0783 Thaana LetterRaa（al）
U+07AA THAANA UBUFILI (NSM)
u 07aa thaanaubufili（nsm）
The directionality class of U+07AA in the Unicode database [Unicode52] is NSM (Nonspacing Mark), which is not R or AL; a conformant implementation of the IDNA2003 algorithm will say that "this is not in RandALCat" and refuse to encode the string.
Unicodeデータベース[Unicode52]のU 07AAの方向性クラスはNSM（非歩行マーク）であり、RまたはALではありません。IDNA2003アルゴリズムの適合実装では、「これはrandalcatではない」と言われ、文字列のエンコードを拒否します。
Yiddish is one of several languages written with the Hebrew script (others include Hebrew and Ladino). This is basically a consonantal alphabet (also termed an "abjad"), but Yiddish is written using an extended form that is fully vocalic. The vowels are indicated in several ways, one of which is by repurposing letters that are consonants in Hebrew. Other letters are used both as vowels and consonants, with combining marks, called "points", used to differentiate between them. Finally, some base characters can indicate several different vowels, which are also disambiguated by combining marks. Pointed characters can appear in word-final position and may therefore also be needed at the end of labels. This is not an invariable attribute of a Yiddish string and there is thus greater latitude here than there is with Dhivehi.
イディッシュ語は、ヘブライ語の脚本で書かれたいくつかの言語の1つです（他の言語にはヘブライ語とラディーノが含まれます）。これは基本的に子音のアルファベット（「アブジャド」とも呼ばれます）ですが、イディッシュ語は完全にボーカリックの拡張フォームを使用して書かれています。母音はいくつかの方法で示されており、その1つはヘブライ語で子音である文字を再利用することです。他の文字は、母音と子音の両方として使用され、「ポイント」と呼ばれるマークを組み合わせて、それらを区別するために使用されます。最後に、一部のベース文字はいくつかの異なる母音を示すことができますが、これはマークを組み合わせることで曖昧に想定されています。先の尖った文字は、ワードファイナルの位置に表示される可能性があるため、ラベルの最後にも必要になる場合があります。これはイディッシュ語の文字列の不変の属性ではないため、ここにはdhivehiよりも大きな緯度があります。
The organization now known as the "YIVO Institute for Jewish Research" developed orthographic rules for modern Standard Yiddish during the 1930s on the basis of work conducted in several venues since earlier in that century. These are given in, "The Standardized Yiddish Orthography: Rules of Yiddish Spelling" [SYO], and are taken as normatively descriptive of modern Standard Yiddish in any context where that notion is deemed relevant. They have been applied exclusively in all formal Yiddish dictionaries published since their establishment, and are similarly dominant in academic and bibliographic regards.
現在「ユダヤ研究のためのYivo研究所」として知られている組織は、その世紀の初めからいくつかの会場で行われた作業に基づいて、1930年代に現代標準イディッシュ語の正書法のルールを開発しました。これらは、「標準化されたイディッシュ人の正書法：イディッシュ語の綴りの規則」[syo]で与えられており、その概念が関連性と見なされる文脈では、現代の標準的なイディッシュ語を規範的に記述していると見なされます。それらは、設立以来発表されているすべての正式なイディッシュ語辞書にのみ適用されており、同様に学術的および書誌的な見方で支配的です。
It therefore appears appropriate for this repertoire also to be supported fully by IDNA. This presents no difficulty with characters in initial and medial positions, but pointed characters are regularly used in final position as well. All of the characters in the SYO repertoire appear in both marked and unmarked form with one exception: the HEBREW LETTER PE (U+05E4). The SYO only permits this with a HEBREW POINT DAGESH (U+05BC), providing the Yiddish equivalent to the Latin letter "p", or a HEBREW POINT RAFE (U+05BF), equivalent to the Latin letter "f". There is, however, a separate unpointed allograph, the HEBREW LETTER FINAL PE (U+05E3), for the latter character when it appears in final position. The constraint on the use of the SYO repertoire resulting from the proscription of combining marks at the end of RTL strings thus reduces to nothing more, or less, than the equivalent of saying that a string of Latin characters cannot end with the letter "p". It must also be noted that the HEBREW LETTER PE with the HEBREW POINT DAGESH is characteristic of almost all traditional Yiddish orthographies that predate (or remain in use in parallel to) the SYO, being the first pointed character to appear in any of them.
したがって、このレパートリーがIDNAによって完全にサポートされることも適切であると思われます。これは、初期位置と内側の位置のキャラクターに困難はありませんが、尖った文字も最終的な位置でも定期的に使用されます。SYOレパートリーのすべてのキャラクターは、1つの例外を除いて、マークされた形式とマークのないフォームの両方で表示されます。ヘブライ文字PE（U 05E4）。SYOは、これをヘブライ語ポイントDagesh（U 05BC）でのみ許可し、ラテン文字「P」に相当するイディッシュ語、またはラテン文字「F」に相当するヘブライ語ポイントRafe（U 05BF）を提供します。ただし、最終的な位置に表示される後者の文字については、別のポイントされていないアログラフ、ヘブライ文字最終PE（U 05E3）があります。したがって、RTL文字列の終わりにあるマークを組み合わせることの禁止に起因するSYOレパートリーの使用に関する制約は、ラテン語の文字列が文字「P」で終わることができないと言うことに相当するものよりも、それ以上のものではなく、それ以上に減少します。。また、ヘブライ語のポイントデージシュを伴うヘブライ語の文字PEは、syoに先行する（または並行して使用し続けている）ほぼすべての伝統的なイディッシュ語の正書法に特徴的であり、それらのいずれかに現れた最初の尖ったキャラクターであることに注意する必要があります。
A more general instantiation of the basic problem can be seen in the representation of the YIVO acronym. This acronym is written with the Hebrew letters YOD YOD HIRIQ VAV VAV ALEF QAMATS, where HIRIQ and QAMATS are combining points. The Unicode code points are:
基本的な問題のより一般的なインスタンス化は、YIVOの頭字語の表現に見られます。この頭字語は、ヘブライ語の手紙で書かれています。Unicodeコードポイントは次のとおりです。
U+05D9 HEBREW LETTER YOD (R)
u 05d9ヘブライ語の手紙yod（r）
U+05B4 HEBREW POINT HIRIQ (NSM)
u 05b4ヘブライ語ポイントhiriq（nsm）
U+05D5 HEBREW LETTER VAV (R)
u 05d5ヘブライ語文字vav（r）
U+05D0 HEBREW LETTER ALEF (R)
u 05d0ヘブライ語文字alef（r）
U+05B8 HEBREW POINT QAMATS (NSM)
u 05b8ヘブライ語ポイントqamats（nsm）
The directionality class of U+05B8 HEBREW POINT QAMATS in the Unicode database is NSM, which again causes the IDNA2003 algorithm to reject the string.
UnicodeデータベースのU 05B8ヘブライ語ポイントQamatsの方向性クラスはNSMであり、これもIDNA2003アルゴリズムが文字列を拒否します。
It may also be noted that all of the combined characters mentioned above exist in precomposed form at separate positions in the Unicode chart. However, by invoking Stringprep, the IDNA2003 algorithm also rejects those code points, for reasons not discussed here.
また、上記のすべての複合文字が、ユニコードチャートの別々の位置に閉塞された形式で存在することにも注意することもできます。ただし、StringPrepを呼び出すことにより、IDNA2003アルゴリズムもこれらのコードポイントを拒否します。
By requiring that the first or last character of a string be a member of category R or AL, the Stringprep specification [RFC3454] prohibited a string containing right-to-left characters from ending with a number.
文字列の最初または最後の文字がカテゴリRまたはALのメンバーであることを要求することにより、StringPrep仕様[RFC3454]は、左から左の文字を含む文字列が数で終了することを禁止しました。
Consider the strings ALEF 5 (HEBREW LETTER ALEF + DIGIT FIVE) and 5 ALEF. Displayed in an LTR context, the first one will be displayed from left to right as 5 ALEF (with the 5 being considered right to left because of the leading ALEF), while 5 ALEF will be displayed in exactly the same order (5 taking the direction from context). Clearly, only one of those should be permitted as a registered label, but barring them both seems unnecessary.
文字列ALEF 5（ヘブライ文字ALEF DIGIT FIVE）と5 ALEFを考えてみましょう。LTRコンテキストで表示される最初のコンテキストは、5 ALEF（5つは先頭のALEFのために右から左から右に見える）として左から右に表示されますが、5 ALEFはまったく同じ順序で表示されます（5コンテキストからの方向）。明らかに、それらのうちの1つだけが登録されたラベルとして許可されるべきですが、それらを除いて両方とも不要に思えます。
There are situations in which labels that satisfy the rule above will be displayed in a surprising fashion. The most important of these is the case where a label ending in a character with Bidi property AL, AN, or R occurs before a label beginning with a character of Bidi property EN. In that case, the number will appear to move into the label containing the right-to-left character, violating the Character Grouping requirement.
上記のルールを満たすラベルが驚くべき方法で表示される状況があります。これらの中で最も重要なのは、Bidi Property al、An、またはrのキャラクターで終わるラベルが、Bidi Property enのキャラクターから始まるラベルの前に発生する場合です。その場合、数字は右から左の文字を含むラベルに移動し、文字グループの要件に違反します。
If the label that occurs after the right-to-left label itself satisfies the Bidi criterion, the requirements will be satisfied in all cases (this is the reason why the criterion talks about strings containing L in some cases). However, the IDNABIS WG concluded that this could not be required for several reasons:
右から左のラベル自体がBidi基準を満たした後に発生するラベルが、すべての場合に要件が満たされる場合（これが、基準が場合によってはLを含む文字列について話す理由です）。ただし、Idnabis WGは、これはいくつかの理由で必要ではないと結論付けました。
o There is a large current deployment of ASCII domain names starting with digits. These cannot possibly be invalidated.
o 数字から始まるASCIIドメイン名の電流が大きく展開されています。これらを無効にすることはできません。
o Domain names are often constructed piecemeal, for instance, by combining a string with the content of a search list. This may occur after IDNA processing, and thus in part of the code that is not IDNA-aware, making detection of the undesirable combination impossible.
o ドメイン名は、たとえば、文字列と検索リストのコンテンツを組み合わせることにより、断片的に構築されることがよくあります。これはIDNA処理後に発生する可能性があり、したがってIDNAが認識していないコードの一部では、望ましくない組み合わせの検出が不可能になります。
o Even if a label is registered under a "safe" label, there may be a DNAME [RFC2672] with an "unsafe" label that points to the "safe" label, thus creating seemingly valid names that would not satisfy the criterion.
o ラベルが「安全な」ラベルの下に登録されていても、「安全な」ラベルを指す「安全でない」ラベルを備えたDNAME [RFC2672]がある可能性があります。
o Wildcards create the odd situation where a label is "valid" (can be looked up successfully) without the zone owner knowing that this label exists. So an owner of a zone whose name starts with a digit and contains a wildcard has no way of controlling whether or not names with RTL labels in them are looked up in his zone.
o ワイルドカードは、このラベルが存在することを知ってゾーンオーナーが存在することなく、ラベルが「有効」である（正常に調べることができる）という奇妙な状況を作成します。そのため、名前が数字で始まり、ワイルドカードが含まれているゾーンの所有者は、RTLラベルのある名前が彼のゾーンで見上げられるかどうかを制御する方法がありません。
Rather than trying to suggest rules that disallow all such undesirable situations, this document merely warns about the possibility, and leaves it to application developers to take whatever measures they deem appropriate to avoid problematic situations.
このような望ましくない状況をすべて禁止する規則を提案しようとするのではなく、この文書は単に可能性について警告し、問題のある状況を避けるために適切だと思われるあらゆる手段をとるようにアプリケーション開発者に任せます。
This document concerns itself only with the rules that are needed when dealing with domain names with characters that have differing Bidi properties, and considers characters only in terms of their Bidi properties. All other issues with scripts that are written from right to left must be considered in other contexts.
このドキュメントは、Bidiプロパティが異なる文字を持つドメイン名を扱い、Bidiプロパティの観点からのみ文字を考慮するときに必要なルールにのみ関係します。右から左へと書かれたスクリプトに関する他のすべての問題は、他のコンテキストで考慮する必要があります。
One such issue is the need to keep numbers separate. Several scripts are used with multiple sets of numbers -- most commonly they use Latin numbers and a script-specific set of numbers, but in the case of Arabic, there are two sets of "Arabic-Indic" digits involved.
そのような問題の1つは、数字を分離する必要があることです。複数の数字のセットでいくつかのスクリプトが使用されています。最も一般的には、ラテン語数とスクリプト固有の数字セットを使用していますが、アラビア語の場合、「アラビア語」桁の2つのセットが含まれます。
The algorithm in this document disallows occurrences of AN-class characters ("Arabic-Indic digits", U+0660 to U+0669) together with EN-class characters (which includes "European" digits, U+0030 to U+0039 and "extended Arabic-Indic digits", U+06F0 to U+06F9), but does not help in preventing the mixing of, for instance, Bengali digits (U+09E6 to U+09EF) and Gujarati digits (U+0AE6 to U+0AEF), both of which have Bidi class L. A registry or script community that wishes to create rules restricting the mixing of digits in a label will be able to specify these restrictions at the registry level. Some rules are also specified at the protocol level.
このドキュメントのアルゴリズムは、クラスの文字（「アラビア語とインディックの数字」、U 0660からU 0669）の発生を許可しません。DIGITS "、u 06f0からu 06f9）、しかし、たとえば、ベンガルの数字（U 09E6からU 09EF）およびグジャラティの数字（U 0AE6〜U 0AEF）の混合を防ぐのに役立ちません。L.ラベル内の数字の混合を制限するルールを作成したいレジストリまたはスクリプトコミュニティは、レジストリレベルでこれらの制限を指定できます。一部のルールは、プロトコルレベルでも指定されています。
Another set of issues concerns the proper display of IDNs with a mixture of LTR and RTL labels, or only RTL labels.
別の問題セットは、LTRラベルとRTLラベルの混合、またはRTLラベルのみを備えたIDNの適切な表示に関するものです。
It is unrealistic to expect that applications will display domain names using embedded formatting codes between their labels (for one thing, no reliable algorithms for identifying domain names in running text exist); thus, the display order will be determined by the Bidi algorithm. Thus, a sequence (in network order) of R1.R2.ltr will be displayed in the order 2R.1R.ltr in an LTR context, which might surprise someone expecting to see labels displayed in hierarchical order. People used to working with text that mixes LTR and RTL strings might not be so surprised by this. Again, this memo does not attempt to suggest a solution to this problem.
アプリケーションがラベル間に組み込みフォーマットコードを使用してドメイン名を表示することを期待するのは非現実的です（1つには、実行中のテキストでドメイン名を識別する信頼できるアルゴリズムはありません）。したがって、表示順序はBidiアルゴリズムによって決定されます。したがって、R1.r2.ltrのシーケンス（ネットワーク順序で）がLTRコンテキストで2r.1r.ltrの順序で表示されます。LTRとRTLの文字列をミックスするテキストを使用していた人々は、これにそれほど驚かないかもしれません。繰り返しますが、このメモはこの問題の解決策を提案しようとはしていません。
As with any change to an existing standard, it is important to consider what happens with existing implementations when the change is introduced. Some troublesome cases include:
既存の標準の変更と同様に、変更が導入されたときに既存の実装で何が起こるかを考慮することが重要です。厄介なケースには次のものが含まれます。
o An old program used to input the newly allowed label. If the old program checks the input against RFC 3454, some labels will not be allowed, and domain names containing those labels will remain inaccessible.
o 新しく許可されたラベルを入力するために使用される古いプログラム。古いプログラムがRFC 3454に対する入力をチェックした場合、一部のラベルは許可されず、それらのラベルを含むドメイン名はアクセスできません。
o An old program is asked to display the newly allowed label, and checks it against RFC 3454 before displaying. The program will perform some kind of fallback, most likely displaying the label in A-label form.
o 古いプログラムは、新しく許可されたラベルを表示するように求められ、表示する前にRFC 3454に対してチェックします。このプログラムは、ある種のフォールバックを実行し、おそらくA-Labelフォームのラベルを表示します。
o An old program tries to display the newly allowed label. If the old program has code for displaying the last character of a label that is different from the code used to display the characters in the middle of the label, the display may be inconsistent and cause confusion.
o 古いプログラムは、新しく許可されたラベルを表示しようとします。古いプログラムに、ラベルの中央に文字を表示するために使用されるコードとは異なるラベルの最後の文字を表示するためのコードがある場合、ディスプレイは一貫性がなく、混乱を引き起こす可能性があります。
One particular example of the last case is if a program chooses to examine the last character (in network order) of a string in order to determine its directionality, rather than its first. If it finds an NSM character and tries to display the string as if it was a left-to-right string, the resulting display may be interesting, but not useful.
最後のケースの特定の例の1つは、プログラムが最初の方向性ではなく、その方向性を決定するために、文字列の最後の文字（ネットワーク順序で）を調べることを選択した場合です。NSM文字を見つけて、文字列が左から右の文字列であるかのように文字列を表示しようとする場合、結果の表示は興味深いかもしれませんが、有用ではありません。
The editors believe that these cases will have a less harmful impact in practice than continuing to deny the use of words from the languages for which these strings are necessary as IDN labels.
編集者は、これらのケースは、これらの文字列がIDNラベルとして必要な言語からの単語の使用を否定し続けるよりも、実践での有害な影響を与えることがないと考えています。
This specification does not forbid using leading European digits in ASCII-only labels, since this would conflict with a large installed base of such labels, and would increase the scope of the specification from RTL labels to all labels. The harm resulting from this limitation of scope is described in Section 5. Registries and private zone managers can check for this particular condition before they allow registration of any RTL label. Generally, it is best to disallow registration of any right-to-left strings in a zone where the label at the level above begins with a digit.
この仕様は、Ascii-Onlyラベルで主要なヨーロッパの数字を使用することを禁止するものではありません。これは、このようなラベルの大きなインストールベースと競合するため、RTLラベルからすべてのラベルへの仕様の範囲を増加させるためです。この範囲の制限に起因する害は、セクション5で説明されています。レジストリとプライベートゾーンマネージャーは、RTLラベルの登録を許可する前に、この特定の条件を確認できます。一般的に、上記のレベルのラベルが数字で始まるゾーンで、左への権利の文字列の登録を許可するのが最善です。
This text is intentionally specified strictly in terms of the Unicode Bidi properties. The determination that the condition is sufficient to fulfill the criteria depends on the Unicode Bidi algorithm; it is unlikely that drastic changes will be made to this algorithm.
このテキストは、Unicode Bidiプロパティに関して、意図的に厳密に指定されています。条件が基準を満たすのに十分であるという決定は、Unicode Bidiアルゴリズムに依存します。このアルゴリズムに劇的な変更が行われる可能性は低いです。
However, the determination of validity for any string depends on the Unicode Bidi property values, which are not declared immutable by the Unicode Consortium. Furthermore, the behavior of the algorithm for any given character is likely to be linguistically and culturally sensitive, so while it should occur rarely, it is possible that later versions of the Unicode Standard may change the Bidi properties assigned to certain Unicode characters.
ただし、文字列の有効性の決定は、Unicodeコンソーシアムによって不変であると宣言されていないUnicode Bidiプロパティ値に依存します。さらに、特定の文字のアルゴリズムの動作は言語的および文化的に敏感である可能性が高いため、まれに発生するはずですが、Unicode標準の後のバージョンは特定のUnicode文字に割り当てられたBIDIプロパティを変更する可能性があります。
This memo does not propose a solution for this problem.
このメモは、この問題の解決策を提案していません。
The display behavior of mixed-direction text can be extremely surprising to users who are not used to it; for instance, cut and paste of a piece of text can cause the text to display differently at the destination, if the destination is in another directionality context, and adding a character in one place of a text can cause characters some distance from the point of insertion to change their display position. This is, however, not a phenomenon unique to the display of domain names.
混合方向のテキストの表示動作は、慣れていないユーザーにとって非常に驚くべきことです。たとえば、テキストのカットと貼り付けにより、目的地が別の方向性のコンテキストにある場合、テキストが宛先で異なる表示になり、テキストの1つの場所に文字を追加すると、文字が距離からある程度距離を置く可能性があります。ディスプレイ位置を変更するための挿入。ただし、これはドメイン名の表示に固有の現象ではありません。
The new IDNA protocol, and particularly these new Bidi rules, will allow some strings to be used in IDNA contexts that are not allowed today. It is possible that differences in the interpretation of labels between implementations of IDNA2003 and IDNA2008 could pose a security risk, but it is difficult to envision any specific instantiation of this.
新しいIDNAプロトコル、特にこれらの新しいBIDIルールにより、現在は許可されていないIDNAコンテキストでいくつかの文字列を使用できます。IDNA2003とIDNA2008の実装間のラベルの解釈の違いは、セキュリティリスクをもたらす可能性がありますが、これの特定のインスタンス化を想像することは困難です。
Any rational attempt to compute, for instance, a hash over an identifier processed by IDNA would use network order for its computation, and thus be unaffected by the new rules proposed here.
たとえば、IDNAによって処理された識別子に対するハッシュを計算する合理的な試みは、その計算にネットワーク注文を使用し、ここで提案されている新しいルールの影響を受けません。
While it is not believed to pose a problem, if display routines had been written with specific knowledge of the RFC 3454 IDNA prohibitions, it is possible that the potential problems noted under "Backwards Compatibility Considerations" could cause new kinds of confusion.
問題を引き起こすとは考えられていませんが、DisplayルーチンがRFC 3454 IDNA禁止事項の特定の知識を持って書かれていた場合、「後方互換性の考慮事項」で記載されている潜在的な問題が新しい種類の混乱を引き起こす可能性があります。
While the listed editors held the pen, this document represents the joint work and conclusions of an ad hoc design team. In addition to the editors, this consisted of, in alphabetic order, Tina Dam, Patrik Faltstrom, and John Klensin. Many further specific contributions and helpful comments were received from the people listed below, and others who have contributed to the development and use of the IDNA protocols.
リストされている編集者がペンを保持していましたが、このドキュメントは、アドホックデザインチームの共同作業と結論を表しています。編集者に加えて、これはアルファベットの順序で、ティナダム、パトリック・ファルトストローム、ジョン・クレンシンで構成されていました。さらに多くの具体的な貢献と有用なコメントが、以下にリストされている人々や、IDNAプロトコルの開発と使用に貢献した他の人々から受け取られました。
The particular formulation of the Bidi rule in Section 2 was suggested by Matitiahu Allouche.
セクション2のBIDIルールの特定の定式化は、Matitiahu Alloucheによって提案されました。
The team wishes, in particular, to thank Roozbeh Pournader for calling its attention to the issue with the Thaana script, Paul Hoffman for pointing out the need to be explicit about backwards compatibility considerations, Ken Whistler for suggesting the basis of the formalized "Character Grouping" requirement, Mark Davis for commentary, Erik van der Poel for careful review, comments, and verification of the rulesets, Marcos Sanz, Andrew Sullivan, and Pete Resnick for reviews, and Vint Cerf for chairing the working group and contributing massively to getting the documents finished.
チームは、特に、Thaanaスクリプトの問題に注意を喚起してくれたRoozbeh Pournader、Paul Hoffmanが後方互換性の考慮事項について明示的であることを指摘してくれたことを望んでいます。「要件、コメントのためのマーク・デイビス、慎重なレビュー、コメント、ルールセットの検証のためのエリック・ファン・デル・プエル、レビューのためにマルコス・サンツ、アンドリュー・サリバン、ピート・レストニック、ワーキンググループの議長を務め、ヴィントCERFがワーキンググループの議長を務め、ドキュメントが終了しました。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]クレンシン、J。、「アプリケーションの国際化ドメイン名（IDNA）：定義とドキュメントフレームワーク」、RFC 5890、2010年8月。
[Unicode-UAX9] The Unicode Consortium, "Unicode Standard Annex #9: Unicode Bidirectional Algorithm", September 2009, <http://www.unicode.org/reports/tr9/>.
[Unicode-uax9] Unicode Consortium、「Unicode Standard Annex＃9：Unicode Biderectional Algorithm」、2009年9月、<http://www.unicode.org/reports/tr9/>。
[Unicode52] The Unicode Consortium. The Unicode Standard, Version 5.2.0, defined by: "The Unicode Standard, Version 5.2.0", (Mountain View, CA: The Unicode Consortium, 2009. ISBN 978-1-936213-00-9). <http://www.unicode.org/versions/Unicode5.2.0/>.
[Unicode52] Unicodeコンソーシアム。Unicode標準バージョン5.2.0、「Unicode Standard、バージョン5.2.0」、（Mountain View、CA：Unicode Consortium、2009。ISBN 978-1-936213-00-9）で定義されています。<http://www.unicode.org/versions/unicode5.2.0/>。
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.
[RFC2672] Crawford、M。、「非末端DNS名リダイレクト」、RFC 2672、1999年8月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454] Hoffman、P。およびM. Blanchet、「国際化された文字列の準備（「StringPrep」）」、RFC 3454、2002年12月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891]クレンシン、J。、「アプリケーションの国際化ドメイン名（IDNA）：プロトコル」、RFC 5891、2010年8月。
[SYO] "The Standardized Yiddish Orthography: Rules of Yiddish Spelling, 6th ed., New York, ISBN 0-914512-25-0", 1999.
[syo] "標準化されたイディッシュの正書法：Yiddish Spellingの規則、第6版、ニューヨーク、ISBN 0-914512-25-0"、1999。
Authors' Addresses
著者のアドレス
Harald Tveit Alvestrand (editor) Google Beddingen 10 Trondheim, 7014 Norway
Harald Tveit Alvestrand（編集者）Google Beddingen 10 Trondheim、7014 Norway
EMail: harald@alvestrand.no
Cary Karp Swedish Museum of Natural History Frescativ. 40 Stockholm, 10405 Sweden
Cary Karp Swedish自然史博物館Frescativ。40ストックホルム、10405スウェーデン
Phone: +46 8 5195 4055
Fax:
EMail: ck@nic.museum