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)
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.
国際化ドメイン名（IDNの）で右から左へのスクリプトの使用は、いくつかの課題を提示しました。このメモは2003 IDNA Bidiの基準でいくつかのスクリプトで発生した問題や、いくつかの欠点に基づくアプリケーション（IDNA）ラベルの国際化ドメイン名のための新しい双方向のルールを提供します。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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の形で国際化ドメイン名（IDN）のラベル（U-ラベル）に適用することができ、ルールを確立することです。これは、改訂された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.
ラベルは、ルールを満たし、そして他の特定の条件が満たされた場合、唯一のUnicode双方向表示アルゴリズムによって混乱のように表示されているこれらのラベルの最小の可能性がある場合。
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:
「文字列準備」仕様[RFC3454]は、IDNA2003の一部は、双方向アルゴリズム上の第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.
文字列がどのRandALCat文字が含まれている場合は3）、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つの場合（ディベヒ語）は、全言語のすべての単語は、IDNラベルとして禁止されたことを意味しました。
This is illustrated below with examples taken from the Dhivehi and Yiddish languages, as written with the Thaana and Hebrew scripts, respectively.
それぞれ、ターナ文字およびヘブライ語スクリプトで記述されたように、これは、ディベヒ語とイディッシュ言語から採取した例で以下に示されています。
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を参照）、その更新IDNA仕様で新しいルールを使用しての動作への影響は限られています。
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節では、それはおそらく混合方向のドメイン名に使用することがいかに安全にチェックするためにドメイン名をラベルに使用することができ、「双方向のルール」を、ルールを定義します。このルールの一次最初の使用はIDNA2008プロトコル[RFC5891]の一部としてです。
Section 3 sets out the requirements for defining the Bidi rule.
第3節では、双方向のルールを定義するための要件を設定します。
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.
セクション8に第5節では、異なる方向の文字でドメイン名を扱う際に発生する可能性のあるさまざまな状況を説明しています。
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文字の双方向特性のために使用される用語は、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標準は、各文字の双方向のプロパティを指定します。このプロパティは、Unicode双方向アルゴリズム[ユニコード-UAX9]内の文字の動作を制御します。参考のため、ここではUnicodeの双方向プロパティを持つことができる値は次のとおりです。
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
AL O - アラビア語の文字 - アラビア語スクリプトの中で最も手紙
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 - 共通番号セパレータ（/：ら）
o NSM - Nonspacing Mark - most combining accents
O NSM - 非スペーシングマーク - ほとんどの組み合わせのアクセント
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
WS O - 空白文字を含む空白、
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 - その他@を含む中性粒子、及び、括弧、LRE、LRO、RLE、RLO、PDF O MIDDLE DOT - これらは、 "方向制御文字" であり、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の双方向クラスの省略形を使用します。従って、例えば - CS LクラスCSの一文字及びいくつかの例では、クラスLの一つの文字から構成例列、大文字はクラスR又はAlである、そして小文字は、クラスLであることが慣例が使用されています文字列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.
用語「段落」はユニコード双方向仕様[ユニコードUAX9]の意味で使用されています。それはおよそ、「右または左へ右へ左どちらかの全体的な方向性を持っているテキストのブロックを、」意味します。詳細については、 "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の少なくとも一つの文字を含むラベルです。
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.)
「双方向ドメイン名」は、少なくとも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つの条件からなる、双方向のドメイン名のラベルに適用されます。ルールを満足するために、このルールを満たすには、セクション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.最初の文字は、双方向性の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.
RTLラベル2.は、双方向特性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.
RTLラベル3.、ラベルの端部は、双方向性NSMとのゼロ以上の文字が続く双方向性R、AL、EN、またはANの文字でなければなりません。
4. In an RTL label, if an EN is present, no AN may be present, and vice versa.
RTLラベル4. ENが存在する場合、何のANは、存在しない、またはその逆もできます。
5. In an LTR label, only characters with the Bidi properties L, EN, ES, CS, ET, ON, BN, or NSM are allowed.
LTRラベル5.は、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のラベルでは、ラベルの最後には、双方向プロパティNSMとゼロ以上の文字が続く双方向プロパティーのLまたはENの文字でなければなりません。
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.
ASCIIの数字で始まるラベルが後に来ていないとして、OのみLDHラベル（定義文書[RFC5890]で定義される）とルールを満たすラベルで構成されるドメイン名では、第3節の要件は限り満たされています右から左のラベル。
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]とは異なり、双方向ルールの明示的な正当化を提供し、変更されたルールが要求を満たすかどうかをテストすることが可能であるための要件のセットを述べています。
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双方向アルゴリズム[ユニコード-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文字グループ：ラベルの文字列を表示する場合、表示のための文字を並べ替えるためにユニコード双方向アルゴリズムを用いて、各ラベルの文字がラベルを区切り文字の間にグループ化されたままであるべきであり、両方の文字列が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:
彼らは、Unicode双方向アルゴリズムの制約の中で果たすことは不可能であるように見えるので、いくつかの強力なステートメントは、考慮され、拒否されました。これらは、次のとおりです。
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はますが、ドメイン名（ネットワーク順で）のでABC.abcは、RTLコンテキストでLTRコンテキストとabc.CBAの表示順序CBA.abcを有するであろう、不健全であることが示されましたRTLコンテキストでLTRコンテキストとCBA.abcで表示順序abc.CBAを持っています。
One possible requirement was thought to be problematic, but turned out to be satisfied by a string that obeys the proposed rules:
一つの可能な要件は、問題があると思ったが、提案された規則に従った文字列によって満たされることが判明しました。
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.
指向制御（LRE、RLE、RLO、LRO、PDF）は、（ラベルの外）、同段落で使用される場合、O要求をグループ化文字が満たさなければなりません。これらのコントロールは非自明な方法で提示順序に影響を与えるので、「SOR」とUnicode双方向アルゴリズムの「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.
それは述べた要件と同様に重要でいないようでしたので、これはまだ、要件として明記されていないが、ラベルがルールを満たす双方向のドメイン名は、このプロパティを持っていることを知っておくと便利です。
In the following descriptions, first-level bullets are used to indicate rules or normative statements; second-level bullets are commentary.
以下の説明では、第一レベルの箇条書きは、規則または規定文を示すために使用されます。セカンドレベルの箇条書きが解説されています。
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プロパティーCS、WS、ONと文字の集合とします。 （これらは、一般的にラベルを区切るために使用されている - FULL STOPと空間の両方が含まれている彼らは、ドメインのラベルでは許可されません。）
* 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に、それは一般的に、実際にドメイン名の隣に発生しても、問題がある：コンテキスト（％A.A1例えば）R CS L EN ETは、ラベルL ENが要件をグループ化する文字を満たしています。
* 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プロパティーR、AL、またはANとの任意の文字が含まれていないと双方向財産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は双方向アルゴリズムに従って並べ替えている連結することによって形成された文字列は、次いで並べ替えた文字列に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ではない表示順でネットワーク順に隣接する文字に影響を及ぼし、したがって双方向処理（[ユニコードUAX9]、セクション3.3中に除去された場合のように扱われることを指定します0.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.
上記のように、同じ方向での段落で表示されたテスト用として埋め込ま二つの非同一のラベルX及びYは、コード・ポイントの同じシーケンスに双方向アルゴリズムによって並べ替えられている場合、ラベルの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.
ディベヒ語、モルディブの公用語は、ターナ文字スクリプトで書かれています。このスクリプトは、その方向性、及び子音ベース文字のマーキング発音区別によって母音の表示を含むアラビア語スクリプトの特性のいくつかを、表示します。マーキングこれは必須であり、2つの連続する母音と音節最終子音の両方が無声結合マークで示されています。すべてのディベヒ語は、したがって、組み合わせマークで終わります。
The word for "computer", which is romanized as "konpeetaru", is written with the following sequence of Unicode code points:
「konpeetaru」とローマ字れる「コンピュータ」の語は、Unicodeコードポイントの次の順序で書き込まれます。
U+0786 THAANA LETTER KAAFU (AL)
文字U 0786タナカーフ（波）
U+07AE THAANA OBOFILI (NSM)
U + 07AEターナ文字OBOFILI（NSM）
U+0782 THAANA LETTER NOONU (AL)
文字U 0782タナヌン（波）
U+07B0 THAANA SUKUN (NSM)
U 07 B 0タナ東距（真実）
U+0795 THAANA LETTER PAVIYANI (AL)
文字U 0795タナpaviyani（波）
U+07A9 THAANA LETTER EEBEEFILI (AL)
U + 07A9ターナ文字LETTER EEBEEFILI（AL）
U+0793 THAANA LETTER TAVIYANI (AL)
U + 0793ターナ文字LETTER（AL）
U+07A6 THAANA ABAFILI (NSM)
U + 07A6 Hoboriin Filii（NSM）
U+0783 THAANA LETTER RAA (AL)
手紙U 0783タナ生（波）
U+07AA THAANA UBUFILI (NSM)
U + 07AA月LIM（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データベース内のU + 07AAの指向クラスは、[Unicode52] RまたはALないNSM（ノンスペーシングマーク）です。 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.
イディッシュ語、ヘブライ語スクリプト（他の人がヘブライ語とラディノが含まれる）と書かれたいくつかの言語の一つです。これは基本的に（また、「アブジャド」と呼ばれる）子音のアルファベットですが、イディッシュ語は完全に母音である拡張形式を使用して書かれています。母音は、ヘブライ語で子音である文字を再利用することによるものであるそのうちの一つ、いくつかの方法で示されています。他の文字は、それらを区別するために使用される「ポイント」と呼ばれるマークを、組み合わせると、母音と子音の両方として使用されています。最後に、いくつかの基地文字もマークを組み合わせることにより、非曖昧化された、いくつかの異なる母音を示すことができます。尖った文字は単語最終的な位置に表示することができ、したがって、また、ラベルの最後に必要になる場合があります。これは、イディッシュ語の文字列の不変の属性ではなく、ディベヒ語であり、ここでより大きな自由度が存在します。
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
今、「YIVOユダヤ調査研究所」として知られている組織は、その世紀の早いので、いくつかの会場で行われ、作業に基づき、1930年代に近代的な標準イディッシュ語用正投影ルールを開発しました。これらは標準化「、で与えられています
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.
イディッシュ語正書法：イディッシュ語スペルチェックのルール」[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によって完全にサポートされるように、このレパートリーのための適切な表示されます。これは、初期および中間位置の文字とは困難を提示していないが、とがった文字は、定期的にだけでなく、最終的な位置で使用されています。 HEBREW LETTER PE（U + 05E4）：SYOレパートリー内のすべての文字は、1つの例外を除いて、両方のマークとマークされていない形で現れます。 SYOは、ラテン文字「F」に相当するラテン文字「P」、又はHEBREW POINTレイフ（U + 05BF）にイディッシュ等価を提供語、ヘブライ語POINT DAGESH（U + 05BC）でこれを可能にします。それが最終位置に表示され、後者の文字の別unpointed異書体ヘブライLETTER FINAL PE（U + 05E3）が、しかし、そこです。 RTL文字列の末尾の組み合わせマークの禁止に起因するSYOレパートリーの使用上の制約は、このようにラテン文字の文字列は、文字「P」で終わることができないと言うのと同等よりも、より多くの、またはより少ない何も削減します。またHEBREW POINT DAGESHとHEBREW LETTER 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ユダヤ調査研究所の頭字語の表現で見ることができます。この頭字語は、ヘブライ語の文字HIRIQとQAMATSポイントを結合さYOD YOD HIRIQ VAV VAV ALEF QAMATS、と書かれています。 Unicodeコードポイントは以下のとおりです。
U+05D9 HEBREW LETTER YOD (R)
U + 05D9 HEBREW LETTER YOD（R）
U+05B4 HEBREW POINT HIRIQ (NSM)
U + 05B4 HEBREW POINT HIRIQ（NSM）
U+05D5 HEBREW LETTER VAV (R)
U + 05D5 HEBREW LETTER VAV（R）
U+05D0 HEBREW LETTER ALEF (R)
U + 05D0 HEBREW LETTER ALEF（R）
U+05B8 HEBREW POINT QAMATS (NSM)
U + 05B8 HEBREW POINT 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 HEBREW POINT QAMATSの指向クラスが再び文字列を拒否するIDNA2003アルゴリズムを引き起こすNSM、です。
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のメンバーであることを要求することにより、文字列準備仕様[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（HEBREW LETTER ALEF + DIGIT FIVE）と5 ALEFを考えてみましょう。 5 ALEFが正確に同じ順序で表示される一方LTRコンテキストで表示、最初のものは5取る（（5ため主要ALEFの右から左に考慮されていると）5 ALEFように左から右に表示されます文脈から方向）。明らかに、これらの一方のみが登録したラベルとして許可されなければならないが、それら除けば両方が不必要と思われます。
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プロパティーENの文字で始まる前に、双方向プロパティAL、AN、またはRの文字で終わるラベルが発生した場合です。その場合は、数が要件をグループ化文字に違反し、右から左へ文字を含むラベルに移動することが表示されます。
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:
右から左にラベル自体は双方向の基準を満たした後に発生するラベル場合は、要件が（これは基準がいくつかのケースでは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プロパティーが異なるしている文字でドメイン名を扱う際に必要とされているルールで自身を懸念、そして唯一の彼らの双方向性の点で文字を考慮します。右から左に書かれたスクリプトとの他のすべての問題は、他のコンテキストで考慮されなければなりません。
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 + 0039に、「ヨーロッパ」の数字が含まれて（一緒にEN-クラスの文字と（U + 0669に「アラビア語 - インド数字」、U + 0660）AN-クラスの文字の出現を禁止U + 0030と「拡張アラビアインド数字」、U + U + 06F9と06F0）が、例えば、U + 09EFに、ベンガル語の数字（U + 09E6）での混合を防止するのに役立たないとグジャラート数字（U + 0AE6 Uに双方向クラスL.レジストリレベルでこれらの制限を指定することができますラベルに数字の混合を制限するルールを作成したいレジストリまたはスクリプトのコミュニティを持っているどちらも+ 0AEF）、。いくつかのルールは、プロトコルレベルで指定されています。
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.
アプリケーションが（一つには、テキストを実行するには、ドメイン名を識別するための信頼できるアルゴリズムが存在しない）、そのラベルの間に埋め込まれフォーマッティングコードを使用して、ドメイン名が表示されますことを期待するのは非現実的です。従って、表示順は、双方向アルゴリズムによって決定されるであろう。このように、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に対してそれをチェックしています。プログラムは、最も可能性の高いラベルの形式でラベルを表示する、フォールバックのいくつかの種類を実行します。
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.
プログラムではなく、その最初のものより、その方向性を決定するために、文字列の（ネットワーク順で）最後の文字を検査することを選択した場合最後の場合の特定の一例です。それは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.
これは、このような標識の大規模なインストールベースと競合する、およびすべてのラベルにRTLラベルからの仕様の範囲を増加させるので、この仕様では、ASCIIのみのラベルにヨーロッパの主要数字を使用して禁止していません。スコープのこの制限により生じる害は、彼らがどんなRTLラベルの登録を許可する前に、この特定の条件をチェックすることができ、セクション5.レジストリとプライベートゾーンマネジャーに記載されています。一般的に、それはレベルのラベルは上記の数字で始まるゾーン内の任意の右から左への文字列の登録を禁止するのが最善です。
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の双方向性の点で厳密に指定されています。状態が基準を満たすのに十分であることが決定は、Unicode双方向アルゴリズムに依存します。急激な変化は、このアルゴリズムに行われることはほとんどありません。
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の双方向プロパティの値に依存します。さらに、任意の文字のためのアルゴリズムの動作は、それはほとんど発生しませんしばらくして、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.
混合方向テキストの表示動作がそれに慣れていないユーザーに非常に驚くべきことができます。先が別の方向性のコンテキストにある場合、テキストは、先に異なっ表示させることができ、およびテキストの一つの場所に文字を追加するとの観点から文字にいくつかの距離を引き起こす可能性があり、たとえば、切断され、テキストの一部のペーストその表示位置を変更するための挿入。しかし、これは、ドメイン名の表示に固有のものではない現象です。
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プロトコル、および特にこれらの新しい双方向のルールは、いくつかの文字列が今日で許可されていません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.
表示ルーチンは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.
記載されている編集者がペンを開催しますが、このドキュメントは、アドホック設計チームの共同作業と結論を表しています。編集者に加えて、これはアルファベット順で、ティナダム、パトリックFaltstrom、そしてジョン・クレンシン、から構成されていました。多くの更なる具体的な貢献と有益なコメントは、IDNAプロトコルの開発と利用に貢献してきた、下記の人々、そして他の人から受け取りました。
The particular formulation of the Bidi rule in Section 2 was suggested by Matitiahu Allouche.
第2の双方向ルールの特定の製剤は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.
チームの願いは、具体的には、ターナ文字スクリプトの問題への注意を喚起するためRoozbeh Pournaderに感謝し、ポール・ホフマンは、必要性を指摘するために後方互換性に関する考慮事項の明示されるように、ケンウィスラー正式な「文字のグループ化の基礎を示唆ためワーキンググループの議長となっに大量に貢献するため、「レビューのための解説のための要件、マーク・デイビス、慎重に検討、コメント、およびルールセットの検証のためのエリックのファンデPoel、マルコス・サンス、アンドリュー・サリバン、とピート・レズニック、およびヴィントン・サーフ文書は終了しました。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890] Klensin、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/>.
[ユニコード-UAX9]のUnicodeコンソーシアム、 "Unicode規格附属書＃9：Unicodeの双方向アルゴリズム"、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標準、バージョン5.2.0"、（カリフォルニア州マウンテンビュー：ユニコードコンソーシアム、2009年ISBN 978-1-936213-00-9）によって定義されたUnicode標準、バージョン5.2.0、。 <http://www.unicode.org/versions/Unicode5.2.0/>。
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.
[RFC2672]クロフォード、M.、 "非ターミナルDNS名リダイレクション"、RFC 2672、1999年8月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454]ホフマン、P.及びM.ブランシェ、 "国際化された文字列の調製（" 文字列準備 "）"、RFC 3454、2002年12月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891] Klensin、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] "標準化されたイディッシュ語正書法：イディッシュ語スペルチェック、第6版、ニューヨーク、ISBN 0-914512-25-0のルール"、1999年。
Authors' Addresses
著者のアドレス
Harald Tveit Alvestrand (editor) Google Beddingen 10 Trondheim, 7014 Norway
ハラルド・トバイット・アルベストランド（エディタ）グーグルBeddingen 10トロンハイムノルウェー7014
EMail: harald@alvestrand.no
メールアドレス：harald@alvestrand.no
Cary Karp Swedish Museum of Natural History Frescativ. 40 Stockholm, 10405 Sweden
自然史Frescativのキャリー・カープスウェーデンの博物館。 40ストックホルム、スウェーデン10405
Phone: +46 8 5195 4055 Fax: EMail: ck@nic.museum
電話：+46 8 5195 4055ファックス：Eメール：ck@nic.museum