[要約] RFC 8228は、バリアントラベルをサポートするラベル生成ルールセット（LGRs）の設計に関するガイダンスです。その目的は、異なる言語やスクリプトのバリアントラベルを効果的にサポートするためのルールセットの設計に役立つことです。
Internet Engineering Task Force (IETF) A. Freytag
Request for Comments: 8228 August 2017
Category: Informational
ISSN: 2070-1721
Guidance on Designing Label Generation Rulesets (LGRs) Supporting Variant Labels
バリアントラベルをサポートするラベル生成ルールセット（LGR）の設計に関するガイダンス
Abstract
概要
Rules for validating identifier labels and alternate representations of those labels (variants) are known as Label Generation Rulesets (LGRs); they are used for the implementation of identifier systems such as Internationalized Domain Names (IDNs). This document describes ways to design LGRs to support variant labels. In designing LGRs, it is important to ensure that the label generation rules are consistent and well behaved in the presence of variants. The design decisions can then be expressed using the XML representation of LGRs that is defined in RFC 7940.
識別子ラベルとそれらのラベル（バリアント）の代替表現を検証するためのルールは、ラベル生成ルールセット（LGR）として知られています。これらは、国際化ドメイン名（IDN）などの識別子システムの実装に使用されます。このドキュメントでは、バリアントラベルをサポートするLGRを設計する方法について説明します。 LGRの設計では、ラベル生成ルールが一貫しており、バリアントが存在する場合でも適切に動作することを確認することが重要です。次に、RFC 7940で定義されているLGRのXML表現を使用して、設計の決定を表現できます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。 Internet Engineering Steering Group（IESG）による公開が承認されています。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション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/rfc8228.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8228で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Variant Relations . . . . . . . . . . . . . . . . . . . . . . 4
3. Symmetry and Transitivity . . . . . . . . . . . . . . . . . . 5
4. A Word on Notation . . . . . . . . . . . . . . . . . . . . . 5
5. Variant Mappings . . . . . . . . . . . . . . . . . . . . . . 6
6. Variant Labels . . . . . . . . . . . . . . . . . . . . . . . 7
7. Variant Types and Label Dispositions . . . . . . . . . . . . 7
8. Allocatable Variants . . . . . . . . . . . . . . . . . . . . 8
9. Blocked Variants . . . . . . . . . . . . . . . . . . . . . . 9
10. Pure Variant Labels . . . . . . . . . . . . . . . . . . . . . 10
11. Reflexive Variants . . . . . . . . . . . . . . . . . . . . . 11
12. Limiting Allocatable Variants by Subtyping . . . . . . . . . 12
13. Allowing Mixed Originals . . . . . . . . . . . . . . . . . . 14
14. Handling Out-of-Repertoire Variants . . . . . . . . . . . . . 15
15. Conditional Variants . . . . . . . . . . . . . . . . . . . . 16
16. Making Conditional Variants Well Behaved . . . . . . . . . . 18
17. Variants for Sequences . . . . . . . . . . . . . . . . . . . 19
18. Corresponding XML Notation . . . . . . . . . . . . . . . . . 21
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
20. Security Considerations . . . . . . . . . . . . . . . . . . . 23
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
21.1. Normative References . . . . . . . . . . . . . . . . . . 23
21.2. Informative References . . . . . . . . . . . . . . . . . 23
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
Label Generation Rulesets (LGRs) that define the set of permissible labels may be applied to identifier systems that rely on labels, such as the Domain Name System (DNS) [RFC1034] [RFC1035]. To date, LGRs have mostly been used to define policies for implementing Internationalized Domain Names (IDNs) using IDNA2008 [RFC5890] [RFC5891] [RFC5892] [RFC5893] [RFC5894] in the DNS. This document aims to discuss the generation of LGRs for such circumstances, but the techniques and considerations here are almost certainly applicable to a wider range of internationalized identifiers.
許可されるラベルのセットを定義するラベル生成ルールセット（LGR）は、ドメインネームシステム（DNS）[RFC1034] [RFC1035]などのラベルに依存する識別子システムに適用できます。現在まで、LGRは主に、DNSでIDNA2008 [RFC5890] [RFC5891] [RFC5892] [RFC5893] [RFC5894]を使用して国際化ドメイン名（IDN）を実装するためのポリシーを定義するために使用されています。このドキュメントは、このような状況でのLGRの生成について説明することを目的としていますが、ここでの技法と考慮事項は、ほぼ確実に、より広範な国際化識別子に適用できます。
In addition to determining whether a given label is eligible, LGRs may also define the condition under which alternate representations of these labels, so-called "variant labels", may exist and their status (disposition). In the most general sense, variant labels are typically labels that are either visually or semantically indistinguishable from another label in the context of the writing system or script supported by the LGR. Unlike merely similar labels, where there may be a measurable degree of similarity, variant labels considered here represent a form of equivalence in meaning or appearance. What constitutes an appropriate variant in any writing system or given context, particularly in the DNS, is assumed to have been determined ahead of time and therefore is not a subject of this document.
LGRは、特定のラベルが適格かどうかを判断するだけでなく、これらのラベルの代替表現、いわゆる「バリアントラベル」が存在する条件とそのステータス（性質）も定義します。最も一般的な意味では、バリアントラベルは通常、LGRでサポートされている書記体系またはスクリプトのコンテキストでは、視覚的または意味的に別のラベルと区別できないラベルです。測定可能な程度の類似性が存在する可能性のある単なる類似のラベルとは異なり、ここで考慮されるバリアントラベルは、意味または外観における同等の形式を表します。書記法や特定のコンテキスト、特にDNSで適切なバリアントを構成するものは、事前に決定されていると想定されるため、このドキュメントの主題ではありません。
Once identified, variant labels are typically delegated to some entity together with the applied-for label, or permanently reserved, based on the disposition derived from the LGR. Correctly defined, variant labels can improve the security of an LGR, yet successfully defining variant rules for an LGR so that the result is well behaved is not always trivial. This document describes the basic considerations and constraints that must be taken into account and gives examples of what might be use cases for different types of variant specifications in an LGR.
識別されると、バリアントラベルは通常、LGRから導出された後処理に基づいて、適用されるラベルと一緒に一部のエンティティに委任されるか、永続的に予約されます。正しく定義されたバリアントラベルは、LGRのセキュリティを向上させることができますが、LGRのバリアントルールを正常に定義できるため、結果が適切に動作します。このドキュメントでは、考慮しなければならない基本的な考慮事項と制約について説明し、LGRのさまざまなタイプのバリアント仕様のユースケースの例を示します。
This document does not address whether variants are an appropriate means to solve any given issue or the basis on which they should be defined. It is intended to explain in more detail the effects of various declarations and the trade-offs in making design choices. It implicitly assumes that any LGR will be expressed using the XML representation defined in [RFC7940] and therefore conforms to any requirements stated therein. Purely for clarity of exposition, examples in this document use a more compact notation than the XML syntax defined in [RFC7940]. However, the reader is expected to have some familiarity with the concepts described in that RFC (see Section 4).
このドキュメントでは、バリアントが特定の問題を解決するための適切な手段であるかどうか、またはそれらを定義する必要がある根拠については触れていません。設計の選択を行う際のさまざまな宣言とトレードオフの影響をより詳細に説明することを目的としています。 LGRは[RFC7940]で定義されたXML表現を使用して表現されるため、そこに記載されている要件に準拠していると暗黙的に想定しています。説明を明確にするために、このドキュメントの例では、[RFC7940]で定義されているXML構文よりも簡潔な表記法を使用しています。ただし、読者はそのRFCで説明されている概念にある程度の知識があることが期待されます（セクション4を参照）。
The user of any identifier system, such as the DNS, interacts with it in the context of labels; variants are experienced as variant labels, i.e., two (or more) labels that are functionally "same as" under the conventions of the writing system used, even though their code point sequences are different. An LGR specification, on the other hand, defines variant mappings between code points and, only in a secondary step, derives the variant labels from these mappings. For a discussion of this process, see [RFC7940].
DNSなどの識別子システムのユーザーは、ラベルのコンテキストでそれと対話します。バリアントは、バリアントラベルとして使用されます。つまり、コードポイントシーケンスが異なっていても、使用されている書記体系の規則に従って機能的に「同じ」である2つ（またはそれ以上）のラベルです。一方、LGR仕様は、コードポイント間のバリアントマッピングを定義し、2次ステップでのみ、これらのマッピングからバリアントラベルを導出します。このプロセスの説明については、[RFC7940]を参照してください。
The designer of an LGR can control whether some or all of the variant labels created from an original label should be allocatable, i.e., available for allocation (to the original applicant), or whether some or all of these labels should be blocked instead, i.e., remain not allocatable (to anyone). This document describes how this choice of label disposition is accomplished (see Section 7).
LGRの設計者は、元のラベルから作成されたバリアントラベルの一部またはすべてを割り当て可能にする（つまり、元の申請者に割り当てる）か、またはこれらのラベルの一部またはすべてを代わりにブロックするかを制御できます。 、（誰にでも）割り当て可能ではありません。このドキュメントでは、このラベル配置の選択方法について説明します（セクション7を参照）。
The choice of desired label disposition would be based on the expectations of the users of the particular zone; it is not the subject of this document. Likewise, this document does not address the possibility of an LGR defining custom label dispositions. Instead, this document suggests ways of designing an LGR to achieve the selected design choice for handling variants in the context of the two standard label dispositions: "allocatable" and "blocked".
希望するラベルの配置の選択は、特定のゾーンのユーザーの期待に基づいています。このドキュメントの主題ではありません。同様に、このドキュメントでは、LGRがカスタムラベルの処理を定義する可能性については触れていません。代わりに、このドキュメントでは、「割り当て可能」と「ブロック」の2つの標準ラベル配置のコンテキストでバリアントを処理するために選択された設計選択を実現するLGRの設計方法を提案します。
The information in this document is based on operational experience gained in developing LGRs for a wide number of languages and scripts using RFC 7940. This information is provided here as a benefit to the wider community. It does not alter or change the specification found in RFC 7940 in any way.
このドキュメントの情報は、RFC 7940を使用してさまざまな言語とスクリプトのLGRを開発する際に得られた運用経験に基づいています。この情報は、より広いコミュニティへのメリットとしてここに提供されています。 RFC 7940にある仕様を変更または変更することはありません。
A variant relation is fundamentally a "same as" relation; in other words, it is an equivalence relation. Now, the strictest sense of "same as" would be equality, and for any equality, we have both symmetry
バリアントリレーションは、基本的に「同じ」リレーションです。つまり、同値関係です。今、「と同じ」の最も厳密な意味は平等であり、どんな平等でも、私たちは両方の対称性を持っています
A = B => B = A
and transitivity
と推移性
A = B and B = C => A = C
The variant relation with its functional sense of "same as" must really satisfy the same constraint. Once we say A is the "same as" B, we also assert that B is the "same as" A. In this document, the symbol "~" means "has a variant relation with". Thus, we get
「同じ」という機能的意味を持つバリアント関係は、実際に同じ制約を満たす必要があります。 Aが「同じ」Bであると言うと、Bも「同じ」Aであると断言します。このドキュメントでは、記号「〜」は「とバリアント関係がある」ことを意味します。したがって、
A ~ B => B ~ A
Likewise, if we make the same claim for B and C (B ~ C), then we get A ~ C, because if B is the "same as" both A and C, then A must be the "same as" C:
同様に、BとC（B〜C）について同じ主張をすると、A〜Cが得られます。これは、BがAとCの両方と「同じ」である場合、Aは「同じ」Cでなければならないためです。
A ~ B and B ~ C => A ~ C
Not all potential relations between labels constitute equivalence, and those that do not are not transitive and may not be symmetric. For example, the degree to which labels are confusable is not transitive: two labels can be confusingly similar to a third without necessarily being confusable with each other, such as when the third one has a shape that is "in between" the other two. In contrast, a relation based on identical or effectively identical appearance would meet the criterion of transitivity, and we would consider it a variant relation. Examples of variant relations include other forms of equivalence, such as semantic equivalence.
ラベル間のすべての潜在的な関係が同値を構成するわけではありません。また、ラベルの関係は推移的ではなく、対称的ではない場合があります。たとえば、ラベルが混乱しやすい程度は推移的ではありません。2番目のラベルが他の2つのラベルの「間にある」形状を持っている場合など、2つのラベルは必ずしも互いに混乱していなくても、3番目のラベルと紛らわしく似ている場合があります。対照的に、同一または実質的に同一の外観に基づく関係は推移性の基準を満たし、バリアント関係と見なします。バリアント関係の例には、意味的同値などの他の形式の同値が含まれます。
Using [RFC7940], a set of mappings could be defined that is neither symmetric nor transitive; such a specification would be formally valid. However, a symmetric and transitive set of mappings is strongly preferred as a basis for an LGR, not least because of the benefits from an implementation point of view; for example, if all mappings are symmetric and transitive, it greatly simplifies the check for collisions between labels with variants. For this reason, we will limit the discussion in this document to those relations that are symmetric and transitive. Incidentally, it is often straightforward to verify mechanically whether an LGR is symmetric and/or transitive and to compute any mappings required to make it so (but see Section 15).
[RFC7940]を使用すると、対称的でも推移的でもない一連のマッピングを定義できます。このような仕様は正式に有効になります。ただし、対称で推移的なマッピングのセットは、特に実装の観点からの利点があるため、LGRの基礎として強く推奨されます。たとえば、すべてのマッピングが対称的で推移的である場合、バリアントを持つラベル間の衝突のチェックが大幅に簡略化されます。このため、このドキュメントでの説明は、対称的で推移的な関係に限定します。ちなみに、LGRが対称的または推移的であるかどうかを機械的に確認し、それを行うために必要なマッピングを計算することは簡単です（ただし、セクション15を参照）。
[RFC7940] defines an XML schema for Label Generation Rulesets in general and variant code points and sequences in particular (see Section 18). That notation is rather verbose and can easily obscure salient features to anyone not trained to read XML. For this reason, this document uses a symbolic shorthand notation in presenting the examples for discussion. This shorthand is merely a didactic tool for presentation and is not intended as an alternative to or replacement for the XML syntax that is used in formally specifying an LGR under [RFC7940].
[RFC7940]は、一般的なラベル生成ルールセット、特にバリアントコードポイントとシーケンスのXMLスキーマを定義しています（セクション18を参照）。この表記はかなり冗長であり、XMLを読み取るように訓練されていない人には、目立つ機能を簡単に不明瞭にする可能性があります。このため、このドキュメントでは、ディスカッションの例を示す際に記号による簡略表記を使用しています。この略記は単に提示のための教訓的なツールであり、[RFC7940]の下でLGRを正式に指定する際に使用されるXML構文の代替または代替として意図されていません。
When it comes time to capture the LGR in a formal definition, the notation used for any of the examples in this document can be converted to the XML format as described in Section 18.
LGRを正式な定義で取り込むときが来たら、このドキュメントの例で使用されている表記法を、セクション18で説明されているXML形式に変換できます。
So far, we have treated variant relations as simple "same as" relations, ignoring that each relation representing equivalence would consist of a symmetric pair of reciprocal mappings. In this document, the symbol "-->" means "maps to".
これまで、等価関係を表す各関係が対称マッピングの相互マッピングで構成されることを無視して、バリアント関係を単純な「同じ」関係として扱いました。このドキュメントでは、記号「->」は「マップ先」を意味します。
A ~ B => A --> B, B --> A
In an LGR, these mappings are not defined directly between labels but between code points (or code point sequences; see Section 17). In the transitive case, given
LGRでは、これらのマッピングはラベル間ではなくコードポイント（またはコードポイントシーケンス、セクション17を参照）間で直接定義されていません。推移的なケースでは、
A ~ B => A --> B, B --> A
A ~ C => A --> C, C --> A
we also get
私たちも得る
B ~ C => B --> C, C --> B
for a total of six possible mappings. Conventionally, these are listed in tables in order of the source code point, like so:
合計6つの可能なマッピング。従来、次のように、これらはソースコードポイントの順にテーブルにリストされています。
A --> B
A --> C
B --> A
B --> C
C --> A
C --> B
As we can see, A, B, and C can each be mapped two ways.
ご覧のとおり、A、B、Cはそれぞれ2つの方法でマッピングできます。
To create a variant label, each code point in the original label is successively replaced by all variant code points defined by a mapping from the original code point. For a label AAA (the letter "A" three times), the variant labels (given the mappings from the transitive example above) would be
バリアントラベルを作成するには、元のラベルの各コードポイントを、元のコードポイントからのマッピングで定義されたすべてのバリアントコードポイントに順次置き換えます。ラベルAAA（文字 "A"が3回）の場合、バリアントラベル（上記の推移的な例のマッピングがある場合）は次のようになります。
AAB ABA ABB BAA BAB BBA BBB AAC ... CCC
お父さんまたはお父さん... CCC
So far, we have merely defined what the variant labels are, but we have not considered their possible dispositions. In the next section, we discuss how to set up the variant mappings so that some variant labels are mutually exclusive (blocked), but some may be allocated to the same applicant as the original label (allocatable).
これまでのところ、バリアントラベルとは何かを定義しただけですが、考えられる性質を考慮していません。次のセクションでは、バリアントマッピングを設定して、一部のバリアントラベルを相互に排他的（ブロック）にする方法について説明しますが、一部は元のラベルと同じ申請者に割り当てることができます（割り当て可能）。
Assume we wanted to allow a variant relation between code points O and A, and perhaps between O and B or O and C as well. Assuming transitivity, this would give us:
コードポイントOとAの間、およびおそらくOとBまたはOとCの間のバリアント関係を許可したいと仮定します。推移性を仮定すると、これにより次のようになります。
O ~ A ~ B ~ C
Now, further assume that we would like to distinguish the case where someone applies for OOO from the case where someone applies for the label ABC. In this case, we would like to allocate only the applied-for label OOO, but in the latter case, we would like to also allow the allocation of either the label OOO or the variant label ABC, or both, but not of any of the other possible variant labels, like OAO, BCO, or the like. (A real-world example might be the case where O represents an unaccented letter, while A, B, and C might represent various accented forms of the same letter. Because unaccented letters are a common fallback, there might be a desire to allocate an unaccented label as a variant, but not the other way around.)
ここで、さらに、誰かがOOOを申請する場合と、誰かがラベルABCを申請する場合とを区別したいとします。この場合、適用されたラベルOOOのみを割り当てますが、後者の場合は、ラベルOOOまたはバリアントラベルABC、あるいはその両方の割り当ても許可しますが、いずれの割り当ても許可しません。 OAO、BCOなどの他の可能なバリアントラベル。 （実際の例では、Oがアクセントなしの文字を表し、A、B、およびCが同じ文字のさまざまなアクセント付き形式を表す場合があります。アクセントなしの文字は一般的なフォールバックであるため、アクセント記号のないラベルをバリアントとして使用しますが、その逆はできません）。
How would we specify such a distinction? The answer lies in labeling the mappings A --> O, B --> O, and C --> O with the type "allocatable" and the mappings O --> A, O --> B, and O --> C with the type "blocked". In this document, the symbol "x-->" means "maps with type blocked", and the symbol "a-->" means "maps with type allocatable". Thus:
そのような区別をどのように指定しますか？答えは、マッピングA-> O、B-> O、C-> Oにタイプ「割り当て可能」とマッピングO-> A、O-> B、O-をラベル付けすることです。 >「ブロック」タイプのC。このドキュメントでは、記号「x->」は「タイプがブロックされたマップ」を意味し、記号「a->」は「タイプが割り当て可能なマップ」を意味します。したがって：
O x--> A O x--> B O x--> C A a--> O B a--> O C a--> O
お ｘーー＞ あ お ｘーー＞ Ｂ お ｘーー＞ Ｃ あ あーー＞ お Ｂ あーー＞ お Ｃ あーー＞ お
When we generate all permutations of labels, we use mappings with different types depending on which code points we start from. The set of all permuted variant labels would be the same, but the disposition of the variant label depends on which label we start from (we call that label the "original" or "applied-for" label).
ラベルのすべての順列を生成するとき、開始するコードポイントに応じて、異なるタイプのマッピングを使用します。並べ替えられたすべてのバリアントラベルのセットは同じですが、バリアントラベルの処理は、開始するラベルによって異なります（そのラベルを「オリジナル」または「適用された」ラベルと呼びます）。
In creating an LGR with variants, all variant mappings should always be labeled with a type ([RFC7940] does not formally require a type, but any well-behaved LGR would be fully typed). By default, these types correspond directly to the dispositions for variant labels, with the most restrictive type determining the disposition of the variant label. However, as we shall see later, it is sometimes useful to assign types from a wider array of values than the final dispositions for the labels and then define explicitly how to derive label dispositions from them.
バリアントを含むLGRを作成する場合、すべてのバリアントマッピングは常にタイプでラベル付けする必要があります（[RFC7940]は正式にタイプを必要としませんが、正常に動作するLGRは完全にタイプされます）。デフォルトでは、これらのタイプはバリアントラベルの後処理に直接対応し、最も限定的なタイプがバリアントラベルの後処理を決定します。ただし、後で説明するように、ラベルの最終的な配置よりも広い値の配列から型を割り当て、それらからラベルの配置を導き出す方法を明示的に定義することが役立つ場合があります。
If we start with AAA and use the mappings from Section 7, the permutation OOO will be the result of applying the mapping A a--> O at each code point. That is, only mappings with type "a" (allocatable) were used. To know whether we can allocate both the label OOO and the original label AAA, we track the types of the mappings used in generating the label.
AAAから始めて、セクション7のマッピングを使用する場合、順列OOOは、各コードポイントでマッピングA a-> Oを適用した結果になります。つまり、タイプ "a"（割り当て可能）のマッピングのみが使用されました。ラベルOOOと元のラベルAAAの両方を割り当てることができるかどうかを知るために、ラベルの生成に使用されるマッピングのタイプを追跡します。
We record the variant types for each of the variant mappings used in creating the permutation in an ordered list. Such an ordered list of variant types is called a "variant type list". In running text, we often show it enclosed in square brackets. For example, [a x -] means the variant label was derived from a variant mapping with the "a" variant type in the first code point position, "x" in the second code point position, and the original code point in the third position ("-" means "no variant mapping").
順列を作成する際に使用されたバリアントマッピングごとに、バリアントタイプを順序付きリストに記録します。このようなバリアント型の順序付きリストは、「バリアント型リスト」と呼ばれます。実行中のテキストでは、角括弧で囲まれて表示されることがよくあります。たとえば、[ax-]は、バリアントラベルが最初のコードポイント位置に「a」バリアントタイプ、2番目のコードポイント位置に「x」、3番目の位置に元のコードポイントを含むバリアントマッピングから派生したことを意味します。 （「-」は「バリアントマッピングなし」を意味します）。
For our example permutation, we get the following variant type list (brackets dropped):
この順列の例では、次のバリアント型リスト（角括弧は削除されます）を取得します。
AAA --> OOO : a a a
From the variant type list, we derive a "variant type set", denoted by curly braces, that contains an unordered set of unique variant types in the variant type list. For the variant type list for the given permutation, [a a a], the variant type set is { a }, which has a single element "a".
バリアントタイプリストから、中括弧で示される「バリアントタイプセット」を導出します。これには、バリアントタイプリスト内の一意のバリアントタイプの順序付けされていないセットが含まれます。指定された順列[a a a]のバリアントタイプリストの場合、バリアントタイプセットは{a}であり、単一の要素 "a"を持っています。
Deciding whether to allow the allocation of a variant label then amounts to deriving a disposition for the variant label from the variant type set created from the variant mappings that were used to create the label. For example, the derivation
バリアントラベルの割り当てを許可するかどうかの決定は、ラベルの作成に使用されたバリアントマッピングから作成されたバリアントタイプセットからバリアントラベルの後処理を導出することになります。たとえば、導出
if "all variants" = "a" => set label disposition to "allocatable"
would allow OOO to be allocated, because the types of all variant mappings used to create that variant label from AAA are "a".
AAAからバリアントラベルを作成するために使用されるすべてのバリアントマッピングのタイプは「a」であるため、OOOを割り当てることができます。
The "all-variants" condition is tolerant of an extra "-" in the variant set (unlike the "only-variants" condition described in Section 10). So, had we started with AOA, OAA, or AAO, the variant set for the permuted variant OOO would have been { a - } because in each case one of the code points remains the same code point as the original. The "-" means that because of the absence of a mapping O --> O, there is no variant type for the O in each of these labels.
「すべてのバリアント」条件は、バリアントセットの余分な「-」を許容します（セクション10で説明されている「唯一のバリアント」条件とは異なります）。したがって、AOA、OAA、またはAAOから始めた場合、置換されたバリアントOOOのバリアントセットは{a-}になります。どちらの場合も、コードポイントの1つが元のコードポイントと同じままであるためです。 「-」は、マッピングO-> Oがないため、これらの各ラベルにOのバリアントタイプがないことを意味します。
The "all-variants" = "a" condition ignores the "-", so using the derivation from above, we find that OOO is an allocatable variant for each of the labels AOA, OAA, or AAO.
"all-variants" = "a"条件は "-"を無視するため、上記の派生を使用して、OOAはラベルAOA、OAA、またはAAOのそれぞれに割り当て可能なバリアントであることがわかります。
Allocatable variant labels, especially large numbers of allocatable variants per label, incur a certain cost to users of the LGR. A well-behaved LGR will minimize the number of allocatable variants.
割り当て可能なバリアントラベル、特にラベルごとに多数の割り当て可能なバリアントは、LGRのユーザーに一定のコストをもたらします。適切に動作するLGRは、割り当て可能なバリアントの数を最小限に抑えます。
Blocked variants are not available to another registrant. They therefore protect the applicant of the original label from someone else registering a label that is the "same as" under some user-perceived metric. Blocked variants can be a useful tool even for scripts for which no allocatable labels are ever defined.
ブロックされたバリアントは、別の登録者は利用できません。したがって、それらは、ユーザーが認識しているメトリックの下で「同じ」であるラベルを登録している誰かから元のラベルの申請者を保護します。ブロックされたバリアントは、割り当て可能なラベルが定義されていないスクリプトの場合でも便利なツールです。
If we start with OOO and use the mappings from Section 7, the permutation AAA will have been the result of applying only mappings with type "blocked", and we cannot allocate the label AAA, only the original label OOO. This corresponds to the following derivation:
OOOから始めて、セクション7のマッピングを使用する場合、置換AAAはタイプ「blocked」のマッピングのみを適用した結果であり、ラベルAAAを割り当てることはできず、元のラベルOOOのみを割り当てます。これは次の派生に対応します。
if "any variants" = "x" => set label disposition to "blocked"
Additionally, to prevent allocating ABO as a variant label for AAA, we need to make sure that the mapping A --> B has been defined with type "blocked", as in
また、ABOをAAAのバリアントラベルとして割り当てないようにするには、次のように、マッピングA-> Bがタイプ「blocked」で定義されていることを確認する必要があります。
A x--> B
A x-> B
so that
そのため
AAA --> ABO: - x a.
AAA-> ABO：-x a。
Thus, the set {x a} contains at least one "x" and satisfies the derivation of a blocked disposition for ABO when AAA is applied for.
したがって、セット{x a}は少なくとも1つの「x」を含み、AAAが適用されたときにABOのブロックされた処理の導出を満たします。
If an LGR results in a symmetric and transitive set of variant labels, then the task of determining whether a label or its variants collide with another label or its variants can be implemented very efficiently. Symmetry and transitivity imply that sets of labels that are mutual variants of each other are disjoint from all other such sets. Only labels within the same set can be variants of each other. Identifying the variant set can be an O(1) operation, and enumerating all variants is not necessary.
LGRが対称的で推移的なバリアントラベルのセットをもたらす場合、ラベルまたはそのバリアントが別のラベルまたはそのバリアントと衝突するかどうかを決定するタスクは、非常に効率的に実装できます。対称性と推移性は、相互の相互変形であるラベルのセットが、他のすべてのそのようなセットから切り離されていることを意味します。同じセット内のラベルのみが相互のバリアントになることができます。バリアントセットの識別はO（1）操作である可能性があり、すべてのバリアントを列挙する必要はありません。
Now, if we wanted to prevent allocation of AOA when we start from AAA, we would need a rule disallowing a mix of original code points and variant code points; this is easily accomplished by use of the "only-variants" qualifier, which requires that the label consist entirely of variants and that all the variants are from the same set of types.
ここで、AAAから開始するときにAOAの割り当てを防止したい場合は、元のコードポイントとバリアントコードポイントの混在を許可しないルールが必要になります。これは、 "only-variants"修飾子を使用して簡単に実行できます。これには、ラベルが完全にバリアントで構成され、すべてのバリアントが同じタイプのセットからのものである必要があります。
if "only-variants" = "a" => set label disposition to "allocatable"
The two code points A in AOA are not arrived at by variant mappings, because the code points are unchanged and no variant mappings are defined for A --> A. So, in our example, the set of variant mapping types is
AOAの2つのコードポイントAは、バリアントマッピングでは到達しません。コードポイントは変更されておらず、A-> Aのバリアントマッピングが定義されていないため、この例では、バリアントマッピングタイプのセットは
AAA --> AOA: - a -
but unlike the "all-variants" condition, "only-variants" requires a variant type set { a } corresponding to a variant type list [a a a] (no - allowed). By adding a final derivation
ただし、「all-variants」条件とは異なり、「only-variants」には、バリアントタイプリスト[a a a]に対応するバリアントタイプセット{a}が必要です（許可されていません）。最終派生を追加することにより
else if "any-variants" = "a" => set label disposition to "blocked"
and executing that derivation only on any remaining labels, we disallow AOA when starting from AAA but still allow OOO.
残りのラベルでのみその派生を実行すると、AAAからの開始時にAOAは許可されませんが、OOOは許可されます。
Derivation conditions are always applied in order, with later derivations only applying to labels that did not match any earlier conditions, as indicated by the use of "else" in the last example. In other words, they form a cascade.
最後の例で「else」を使用して示されているように、派生条件は常に順番に適用され、後の派生は以前の条件に一致しなかったラベルにのみ適用されます。つまり、カスケードを形成します。
But what if we started from AOA? We would expect the original label OOO to be allocatable, but, using the mappings from Section 7, the variant type set would be
しかし、AOAから始めた場合はどうでしょうか。元のラベルOOOは割り当て可能であると予想しますが、セクション7のマッピングを使用すると、バリアントタイプセットは次のようになります。
AOA --> OOO: a - a
because the middle O is unchanged from the original code point. Here is where we use a reflexive mapping. Realizing that O is the "same as" O, we can map it to itself. This is normally redundant, but adding an explicit reflexive mapping allows us to specify a disposition on that mapping:
中央のOは元のコードポイントから変更されていないためです。ここで、再帰マッピングを使用します。 Oは「同じ」Oであることを認識し、それをそれ自体にマッピングできます。これは通常冗長ですが、明示的な再帰マッピングを追加すると、そのマッピングの性質を指定できます。
O a--> O
お あーー＞ お
With that, the variant type list for AOA --> OOO becomes:
これにより、AOA-> OOOのバリアントタイプリストは次のようになります。
AOA --> OOO: a a a
and the label OOO again passes the derivation condition
ラベルOOOは再び派生条件を渡します
if "only-variants" = "a" => set label disposition to "allocatable"
as desired. This use of reflexive variants is typical whenever derivations with the "only-variants" qualifier are used. If any code point uses a reflexive variant, a well-behaved LGR would specify an appropriate reflexive variant for all code points.
望んだ通りに。この "再帰バリアント"の使用は、 "only-variants"修飾子を使用した派生が使用される場合は常に一般的です。コードポイントが再帰バリアントを使用する場合、正常に動作するLGRは、すべてのコードポイントに適切な再帰バリアントを指定します。
As we have seen, the number of variant labels can potentially be large, due to combinatorics. Sometimes it is possible to divide variants into categories and to stipulate that only variant labels with variants from the same category should be allocatable. For some LGRs, this constraint can be implemented by a rule that disallows code points from different categories to occur in the same allocatable label. For other LGRs, the appropriate mechanism may be dividing the allocatable variants into subtypes.
これまで見てきたように、組み合わせ論のため、バリアントラベルの数は潜在的に大きくなる可能性があります。バリアントをカテゴリに分割し、同じカテゴリのバリアントを持つバリアントラベルのみを割り当て可能にするように規定することが可能な場合があります。一部のLGRでは、この制約は、異なるカテゴリのコードポイントが同じ割り当て可能なラベルで発生することを禁止するルールによって実装できます。他のLGRの場合、適切なメカニズムは、割り当て可能なバリアントをサブタイプに分割することです。
To recap, in the standard case, a code point C can have (up to) two types of variant mappings
要約すると、標準的なケースでは、コードポイントCは（最大で）2種類のバリアントマッピングを持つことができます。
C x--> X C a--> A
C x-> X C a-> A
where a--> means a variant mapping with type "allocatable" and x--> means "blocked". For the purpose of the following discussion, we name the target code point with the corresponding uppercase letter.
ここで、a->は「割り当て可能」タイプのバリアントマッピングを意味し、x->は「ブロック」を意味します。以下の説明のために、ターゲットコードポイントに対応する大文字の名前を付けます。
Subtyping allows us to distinguish among different types of allocatable variants. For example, we can define three new types: "s", "t", and "b". Of these, "s" and "t" are mutually incompatible, but "b" is compatible with either "s" or "t" (in this case, "b" stands for "both"). A real-world example for this might be variant mappings appropriate for "simplified" or "traditional" Chinese variants, or appropriate for both.
サブタイピングにより、割り当て可能なバリアントのさまざまなタイプを区別できます。たとえば、「s」、「t」、「b」の3つの新しいタイプを定義できます。これらのうち、「s」と「t」は相互に互換性がありませんが、「b」は「s」または「t」と互換性があります（この場合、「b」は「両方」を表します）。これの実際の例は、「簡体字」または「伝統的」な中国の変種、または両方に適した変種のマッピングです。
With subtypes defined as above, a code point C might have (up to) four types of variant mappings
上記のようにサブタイプが定義されている場合、コードポイントCには、最大4つのタイプのバリアントマッピングが含まれる可能性があります。
C x--> X C s--> S C t--> T C b--> B
C x-> X C s-> S C t-> T C b-> B
and explicit reflexive mappings of one of these types
これらのタイプの1つの明示的再帰マッピング
C s--> C C t--> C C b--> C
C s-> C C t-> C C b-> C
As before, all mappings must have one and only one type, but each code point may map to any number of other code points.
以前と同様に、すべてのマッピングは1つのタイプのみを持つ必要がありますが、各コードポイントは他の任意の数のコードポイントにマッピングできます。
We define the compatibility of "b" with "t" or "s" by our choice of derivation conditions as follows
「b」と「t」または「s」の互換性は、派生条件の選択によって次のように定義されます。
if "any-variants" = "x" => blocked
else if "only-variants" = "s" or "b" => allocatable
else if "only-variants" = "t" or "b" => allocatable
else if "any-variants" = "s" or "t" or "b" => blocked
An original label of four code points
4つのコードポイントのオリジナルラベル
CCCC
CCCC
may have many variant labels, such as this example listed with its corresponding variant type list:
この例のように、対応するバリアントタイプリストとともにリストされた多くのバリアントラベルがある場合があります。
CCCC --> XSTB : x s t b
This variant label is blocked because to get from C to B required x-->. (Because variant mappings are defined for specific source code points, we need to show the starting label for each of these examples, not merely the code points in the variant label.) The variant label
CからBに移動するにはx->が必要なため、このバリアントラベルはブロックされます。 （バリアントマッピングは特定のソースコードポイントに対して定義されているため、バリアントラベルのコードポイントだけでなく、これらの各例の開始ラベルを表示する必要があります。）バリアントラベル
CCCC --> SSBB : s s b b
is allocatable, because the variant type list contains only allocatable mappings of subtype "s" or "b", which we have defined as being compatible by our choice of derivations. The actual set of variant types {s, b} has only two members, but the examples are easier to follow if we list each type. The label
バリアント型リストにはサブタイプ「s」または「b」の割り当て可能なマッピングのみが含まれるため、割り当て可能です。これは、派生の選択によって互換性があると定義されています。バリアント型の実際のセット{s、b}には2つのメンバーしかありませんが、各型をリストすると、例を理解しやすくなります。ラベル
CCCC --> TTBB : t t b b
is again allocatable, because the variant type set {t, b} contains only allocatable mappings of the mutually compatible allocatable subtypes "t" or "b". In contrast,
バリアント型セット{t、b}には相互に互換性のある割り当て可能なサブタイプ "t"または "b"の割り当て可能なマッピングのみが含まれているため、これも割り当て可能です。対照的に、
CCCC --> SSTT : s s t t
is not allocatable, because the type set contains incompatible subtypes "t" and "s" and thus would be blocked by the final derivation.
タイプセットには互換性のないサブタイプ "t"と "s"が含まれているため、最終的な派生によってブロックされるため、は割り当て可能ではありません。
The variant labels
バリアントラベル
CCCC --> CSBB : c s b b
CCCC --> CTBB : c t b b
are only allocatable based on the subtype for the C --> C mapping, which is denoted here by "c" and (depending on what was chosen for the type of the reflexive mapping) could correspond to "s", "t", or "b".
C-> Cマッピングのサブタイプに基づいてのみ割り当て可能であり、ここでは「c」で示され、（再帰マッピングのタイプに選択されたものに応じて）「s」、「t」、または「b」。
If the subtype is "s", the first of these two labels is allocatable; if it is "t", the second of these two labels is allocatable; if it is "b", both labels are allocatable.
サブタイプが「s」の場合、これら2つのラベルの最初のラベルは割り当て可能です。 「t」の場合、これら2つのラベルの2番目は割り当て可能です。 「b」の場合、両方のラベルを割り当てることができます。
So far, the scheme does not seem to have brought any huge reduction in allocatable variant labels, but that is because we tacitly assumed that C could have all three types of allocatable variants "s", "t", and "b" at the same time.
これまでのところ、このスキームでは割り当て可能なバリアントラベルが大幅に削減されたようには見えませんが、これは、Cが3つのタイプの割り当て可能なバリアント「s」、「t」、および「b」をすべて同時。
In a real-world example, the types "s", "t", and "b" are assigned so that each code point C normally has, at most, one non-reflexive variant mapping labeled with one of these subtypes, and all other mappings would be assigned type "x" (blocked). This holds true for most code points in existing tables (such as those used in current IDN Top-Level Domains (TLDs)), although certain code points have exceptionally complex variant relations and may have an extra mapping.
実際の例では、タイプ "s"、 "t"、および "b"が割り当てられているため、各コードポイントCには通常、最大でこれらのサブタイプの1つでラベル付けされた1つの非再帰バリアントマッピングがあり、すべての他のマッピングにはタイプ "x"（ブロック）が割り当てられます。これは、既存のテーブルのほとんどのコードポイント（現在のIDNトップレベルドメイン（TLD）で使用されているものなど）にも当てはまりますが、特定のコードポイントには非常に複雑なバリアント関係があり、追加のマッピングがある場合があります。
If the desire is to allow original labels (but not variant labels) that are s/t mixed, then the scheme needs to be slightly refined to distinguish between reflexive and non-reflexive variants. In this document, the symbol "r-n" means "a reflexive (identity) mapping of type 'n'". The reflexive mappings of the preceding section thus become:
元のラベル（バリアントラベルではなく）をs / t混合することを許可する場合は、スキーマを少し洗練して、再帰的バリアントと非再帰的バリアントを区別する必要があります。このドキュメントでは、記号「r-n」は「タイプ「n」の再帰的（アイデンティティ）マッピング」を意味します。したがって、前のセクションの再帰マッピングは次のようになります。
C r-s--> C C r-t--> C C r-b--> C
C r-s-> C C r-t-> C C r-b-> C
With this convention, and redefining the derivations
この規則を使用して、派生を再定義します
if "any-variants" = "x" => blocked else if "only-variants" = "s" or "r-s" or "b" or "r-b" => allocatable else if "only-variants" = "t" or "r-t" or "b" or "r-b" => allocatable else if "any-variants" = "s" or "t" or "b" => blocked else => allocatable any labels that contain only reflexive mappings of otherwise mixed type (in other words, any mixed original label) now fall through, and their disposition is set to "allocatable" in the final derivation.
if "any-variants" = "x" =>ブロックされているelse if "only-variants" = "s"または "rs"または "b"または "rb" =>割り当て可能else if "only-variants" = "t"または "rt"または "b"または "rb" => "any-variants" = "s"または "t"または "b"の場合に割り当て可能else =>ブロックされたelse =>他の再帰マッピングのみを含むラベルを割り当て可能混合タイプ（つまり、混合された元のラベル）が失敗し、最終的な派生でその配置が「割り当て可能」に設定されます。
In a well-behaved LGR, it is preferable to explicitly define the derivation for allocatable labels instead of using a fall through. In the derivation above, code points without any variant mappings fall through and become allocatable by default if they are part of an original label. Especially in a large repertoire, it can be difficult to identify which code points are affected. Instead, it is preferable to mark them with their own reflexive mapping type "neither" or "r-n".
適切に動作するLGRでは、フォールスルーを使用するのではなく、割り当て可能なラベルの派生を明示的に定義することをお勧めします。上記の派生では、バリアントマッピングのないコードポイントは、元のラベルの一部である場合、デフォルトで通過し、割り当て可能になります。特に大きなレパートリーでは、影響を受けるコードポイントを特定するのが難しい場合があります。代わりに、独自の再帰マッピングタイプ「どちらでもない」または「r-n」でそれらをマークすることをお勧めします。
C r-n--> C
C e-n-> C
With that, we can change
それで、私たちは変えることができます
else => allocatable
else =>割り当て可能
to
と
else if "only-variants" = "r-s" or "r-t" or "r-b" or "r-n"
=> allocatable
else => invalid
This makes the intent more explicit, and by ensuring that all code points in the LGR have a reflexive mapping of some kind, it is easier to verify the correct assignment of their types.
これにより、意図がより明確になり、LGR内のすべてのコードポイントに何らかの再帰的マッピングがあることを確認することで、型の正しい割り当てを確認しやすくなります。
At first, it may seem counterintuitive to define variants that map to code points that are not part of the repertoire. However, for zones for which multiple LGRs are defined, there may be situations where labels valid under one LGR should be blocked if a label under another LGR is already delegated. This situation can arise whether or not the repertoires of the affected LGRs overlap and, where repertoires overlap, whether or not the labels are both restricted to the common subset.
最初は、レパートリーの一部ではないコードポイントにマップするバリアントを定義するのは直観に反するように思えるかもしれません。ただし、複数のLGRが定義されているゾーンでは、別のLGRの下のラベルがすでに委任されている場合、1つのLGRの下で有効なラベルをブロックする必要がある状況があります。この状況は、影響を受けるLGRのレパートリーが重複しているかどうか、およびレパートリーが重複している場合に、ラベルが両方とも共通のサブセットに制限されているかどうかに関係なく発生します。
In order to handle this exclusion relation through definition of variants, it is necessary to be able to specify variant mappings to some code point X that is outside an LGR's repertoire, R:
バリアントの定義を通じてこの除外関係を処理するには、LGRのレパートリーRの外にあるコードポイントXへのバリアントマッピングを指定できる必要があります。
C x--> X : where C = elementOf(R) and X != elementOf(R)
Because of symmetry, it is necessary to also specify the inverse mapping in the LGR:
対称性のため、LGRで逆マッピングも指定する必要があります。
X x--> C : where X != elementOf(R) and C = elementOf(R)
This makes X a source of variant mappings, and it becomes necessary to identify X as being outside the repertoire, so that any attempt to apply for a label containing X will lead to a disposition of "invalid", just as if X had never been listed in the LGR. The mechanism to do this uses reflexive variants but with a new type of reflexive mapping of "out-of-repertoire-var", shown as "r-o-->":
これにより、Xはバリアントマッピングのソースになり、Xをレパートリーの外にあるものとして識別することが必要になるため、Xを含むラベルを適用しようとすると、まるでXがこれまでになかったかのように、「無効」という性質が生じますLGRに記載されています。これを行うメカニズムは、再帰バリアントを使用しますが、「r-o->」として示される「out-of-repertoire-var」の新しいタイプの再帰マッピングを使用します。
X r-o--> X
Ｘ ｒーおーー＞ Ｘ
This indicates X != elementOf(R), as long as the LGR is provided with a suitable derivation, so that any label containing "r-o-->" is assigned a disposition of "invalid", just as if X was any other code point not part of the repertoire. The derivation used is:
これは、X！= elementOf（R）を示します。ただし、LGRに適切な派生が提供されている限り、「ro->」を含むラベルには、「X」が他のコードと同じように「無効」の後処理が割り当てられます。ポイントはレパートリーの一部ではありません。使用される派生は次のとおりです。
if "any-variant" = "out-of-repertoire-var" => invalid
It is inserted ahead of any other derivation of the "any-variant" kind in the chain of derivations. As a result, instead of the minimum two symmetric variants, for any out-of-repertoire variants, there are a minimum of three variant mappings defined:
これは、派生のチェーン内で「任意のバリアント」の種類の他の派生の前に挿入されます。その結果、レパートリー外のバリアントの場合、最小2つの対称バリアントの代わりに、最低3つのバリアントマッピングが定義されます。
C x--> X X x--> C X r-o--> X
C x-> X X x-> C X r-o-> X
where C = elementOf(R) and X != elementOf(R).
ここで、C = elementOf（R）およびX！= elementOf（R）です。
Because no variant label with any code point outside the repertoire could ever be allocated, the only logical choice for the non-reflexive mappings to out-of-repertoire code points is "blocked".
レパートリー外のコードポイントを持つバリアントラベルを割り当てることはできないため、レパートリー外のコードポイントへの非再帰的マッピングの唯一の論理的な選択肢は「ブロック」されます。
Variant mappings are based on whether code points are "same as" to the user. In some writing systems, code points change shape based on where they occur in the word (positional forms). Some code points have matching shapes in some positions but not in others. In such cases, the variant mapping exists only for some possible positions or, more generally, only for some contexts. For other contexts, the variant mapping does not exist.
バリアントマッピングは、コードポイントがユーザーと「同じ」かどうかに基づいています。一部の書記体系では、コードポイントは、単語内の出現位置（位置形式）に基づいて形状が変化します。一部のコードポイントは、一部の位置に一致する形状を持っていますが、他の位置にはありません。このような場合、バリアントマッピングは、一部の可能な位置に対してのみ存在します。より一般的には、一部のコンテキストに対してのみ存在します。他のコンテキストでは、バリアントマッピングは存在しません。
For example, take two code points that have the same shape at the end of a label (or in final position) but not in any other position. In that case, they are variants only when they occur in the final position, something we indicate like this:
たとえば、ラベルの最後（または最終位置）で同じ形状を持ち、他の位置ではない2つのコードポイントを考えます。その場合、それらは最終位置にある場合にのみバリアントであり、次のように示します。
final: C --> D
In cursively connected scripts, like Arabic, a code point may take its final form when next to any following code point that interrupts the cursive connection, not just at the end of a label. (We ignore the isolated form to keep the discussion simple; if included, "final" might be "final-or-isolate", for example).
アラビア語のように筆記体で接続されたスクリプトでは、ラベルの末尾だけでなく、筆記体の接続を中断する後続のコードポイントの横にある場合、コードポイントは最終的な形をとることがあります。 （議論を単純にするために、分離されたフォームは無視します。たとえば、「final」は「final-or-isolate」になる場合があります）。
From symmetry, we expect that the mapping D --> C should also exist only when the code point D is in final position. (Similar considerations apply to transitivity.)
対称性から、コードポイントDが最終位置にある場合にのみ、マッピングD-> Cも存在するはずです。 （同様の考慮事項が推移性に適用されます。）
Sometimes a code point has a final form that is practically the same as that of some other code point while sharing initial and medial forms with another.
コードポイントの最終的なフォームは、他のコードポイントと実質的に同じで、初期フォームと中間フォームを別のコードポイントと共有する場合があります。
final: C --> D
!final: C --> E
Here, the case where the condition is the opposite of final is shown as "!final".
ここでは、finalと逆の場合を「！final」と表示しています。
Because shapes differ by position, when a context is applied to a variant mapping, it is treated independently from the same mapping in other contexts. This extends to the assignment of types. For example, the mapping C --> F may be "allocatable" in final position but "blocked" in any other context:
形状は位置によって異なるため、コンテキストがバリアントマッピングに適用されると、他のコンテキストの同じマッピングとは独立して扱われます。これは、型の割り当てにまで及びます。たとえば、マッピングC-> Fは最終位置では「割り当て可能」であるが、他のコンテキストでは「ブロック」される可能性があります。
final: C a--> F
!final: C x--> F
Now, the type assigned to the forward mapping is independent of the reverse symmetric mapping or any transitive mappings. Imagine a situation where the symmetric mapping is defined as F a--> C, that is, all mappings from F to C are "allocatable":
これで、順方向マッピングに割り当てられたタイプは、逆対称マッピングや推移的マッピングから独立しています。対称マッピングがF a-> Cとして定義されている状況を想像してください。つまり、FからCへのすべてのマッピングは「割り当て可能」です。
final: F a--> C
!final: F a-->C
Why not simply write F a--> C? Because the forward mapping is divided by context. Adding a context makes the two forward variant mappings distinct, and that needs to be accounted for explicitly in the reverse mappings so that human and machine readers can easily verify symmetry and transitivity of the variant mappings in the LGR. (This is true even though the two opposite contexts of "final" and "!final" should together cover all possible cases.)
単にF a-> Cと書いてみませんか？フォワードマッピングはコンテキストによって分割されるためです。コンテキストを追加すると、2つのフォワードバリアントマッピングが区別され、人間と機械の読者がLGRのバリアントマッピングの対称性と推移性を簡単に確認できるように、リバースマッピングで明示的に考慮する必要があります。 （ "final"と "！final"の2つの反対のコンテキストがすべての可能なケースをカバーする必要がある場合でも、これは当てはまります。）
To ensure that LGR with contextual variants is well behaved, it is best to always use "fully qualified" variant mappings that always agree in the names of the context rules for forward and reverse mappings. It is also necessary to ensure that no label can match more than one context for the same mapping. Using mutually exclusive contexts, such as "final" and "!final", is an easy way to ensure that.
コンテキストバリアントを含むLGRが適切に動作するようにするには、フォワードマッピングとリバースマッピングのコンテキストルールの名前が常に一致する「完全修飾」バリアントマッピングを常に使用することをお勧めします。また、同じマッピングのラベルが複数のコンテキストに一致しないようにする必要もあります。 "final"や "！final"などの相互に排他的なコンテキストを使用すると、簡単に確認できます。
However, it is not always necessary to define dual or multiple contexts that together cover all possible cases. For example, here are two contexts that do not cover all possible positional contexts:
ただし、すべての可能なケースをカバーするデュアルまたはマルチコンテキストを定義する必要は必ずしもありません。たとえば、考えられるすべての位置コンテキストを網羅していない2つのコンテキストを次に示します。
final: C --> D initial: C --> D.
最終：C-> D初期：C-> D
A well-behaved LGR using these two contexts would define all symmetric and transitive mappings involving C, D, and their variants consistently in terms of the two conditions "final" and "initial" and ensure that both cannot be satisfied at the same time by some label.
これらの2つのコンテキストを使用する適切に動作するLGRは、C、D、およびそれらのバリアントを含むすべての対称および推移的マッピングを、「最終」および「初期」という2つの条件に関して一貫して定義し、両方が同時に満たすことができないようにします。いくつかのラベル。
In addition to never defining the same mapping with two contexts that may be satisfied by the same label, a well-behaved LGR never combines a variant mapping with a context with the same variant mapping without a context:
同じラベルで満たされる可能性がある2つのコンテキストで同じマッピングを決して定義しないことに加えて、行儀の良いLGRは、バリアントマッピングとコンテキストのない同じバリアントマッピングのコンテキストを決して組み合わせません。
context: C --> D
C --> D
Inadvertent mixing of conditional and unconditional variants can be detected and flagged by a parser, but verifying that two formally distinct contexts are never satisfied by the same label would depend on the interaction between labels and context rules, which means that it will be up to the LGR designer to ensure that the LGR is well behaved.
条件付きバリアントと無条件バリアントの不注意による混合は、パーサーによって検出およびフラグ付けできますが、2つの形式的に異なるコンテキストが同じラベルで満たされないことの確認は、ラベルとコンテキストルールの間の相互作用に依存します。つまり、 LGRデザイナーが、LGRが適切に動作することを確認します。
A well-behaved LGR never assigns conditions on a reflexive variant, as that is effectively no different from having a context on the code point itself; the latter is preferred.
正常に動作するLGRは、コードポイント自体にコンテキストを持つことと実質的に違いがないため、再帰バリアントに条件を割り当てません。後者が好ましい。
Finally, for symmetry to work as expected, the context must be defined such that it is satisfied for both the original code point in the context of the original label and for the variant code point in the variant label. In other words, the context should be "stable under variant substitution" anywhere in the label.
最後に、対称性が期待どおりに機能するためには、元のラベルのコンテキストの元のコードポイントとバリアントラベルのバリアントコードポイントの両方が満たされるようにコンテキストを定義する必要があります。言い換えると、コンテキストはラベルのどこでも「バリアント置換の下で安定」である必要があります。
Positional contexts usually satisfy this last condition; for example, a code point that interrupts a cursive connection would likely share this property with any of its variants. However, as it is possible in principle to define other kinds of contexts, it is necessary to make sure that the LGR is well behaved in this aspect at the time the LGR is designed.
通常、定位置コンテキストはこの最後の条件を満たします。たとえば、筆記体接続を中断するコードポイントは、このプロパティをそのバリアントと共有する可能性があります。ただし、他の種類のコンテキストを定義することは原則として可能であるため、LGRの設計時に、この側面でLGRが適切に動作することを確認する必要があります。
Due to the difficulty in verifying these constraints mechanically, it is essential that an LGR designer document the reasons why the LGR can be expected to meet them and the details of the techniques used to ensure that outcome. This information should be found in the description element of the LGR.
これらの制約を機械的に検証することは困難であるため、LGRがLGRに適合することが期待できる理由とその結果を確実にするために使用される手法の詳細をLGR設計者が文書化することが不可欠です。この情報は、LGRのdescription要素にあります。
In summary, conditional contexts can be useful for some cases, but additional care must be taken to ensure that an LGR containing conditional contexts is well behaved. LGR designers would be well advised to avoid using conditional contexts and to prefer unconditional rules whenever practical, even though it will doubtlessly reduce the number of labels practically available.
要約すると、条件付きコンテキストはいくつかの場合に役立ちますが、条件付きコンテキストを含むLGRが適切に動作するように、さらに注意が必要です。 LGRの設計者は、実際に使用できるラベルの数が確実に減少する場合でも、条件付きコンテキストの使用を避け、実用的な場合は常に無条件ルールを優先することをお勧めします。
Variant mappings can be defined between sequences or between a code point and a sequence. For example, one might define a "blocked" variant between the sequence "rn" and the code point "m" because they are practically indistinguishable in common UI fonts.
バリアントマッピングは、シーケンス間またはコードポイントとシーケンス間で定義できます。たとえば、シーケンス「rn」とコードポイント「m」の間に「ブロックされた」バリアントを定義する場合があります。それらは一般的なUIフォントでは事実上区別できないためです。
Such variants are no different from variants defined between single code points, except if a sequence is defined such that there is a code point or shorter sequence that is a prefix (initial subsequence) and both it and the remainder are also part of the repertoire. In that case, it is possible to create duplicate variants with conflicting dispositions.
そのようなバリアントは、単一のコードポイント間で定義されたバリアントと同じです。ただし、シーケンスがコードポイントまたは接頭辞（最初のサブシーケンス）である短いシーケンスが存在するように定義され、それと残りの両方もレパートリーの一部である場合を除きます。その場合、処理が競合するバリアントが重複して作成される可能性があります。
The following shows such an example resulting in conflicting reflexive variants:
以下は、競合する再帰バリアントが発生するそのような例を示しています。
A a--> C AB x--> CD
あ あーー＞ Ｃ あＢ ｘーー＞ ＣＤ
where AB is a sequence with an initial subsequence of A. For example, B might be a combining code point used in sequence AB. If B only occurs in the sequence, there is no issue, but if B also occurs by itself, for example:
ここで、ABは最初のサブシーケンスがAのシーケンスです。たとえば、BはシーケンスABで使用される結合コードポイントです。 Bがシーケンスでのみ発生する場合、問題はありませんが、Bが単独で発生する場合は、たとえば次のようになります。
B a--> D
B a-> D
then a label "AB" might correspond to either {A}{B}, that is, the two code points, or {AB}, the sequence, where the curly braces show the sequence boundaries as they would be applied during label validation and variant mapping.
次に、ラベル「AB」は、{A} {B}、つまり2つのコードポイント、または{AB}のシーケンスに対応します。中括弧は、ラベルの検証中に適用されるシーケンスの境界を示します。バリアントマッピング。
A label AB would then generate the "allocatable" variant label {C}{D} and the "blocked" variant label {CD}, thus creating two variant labels with conflicting dispositions.
次に、ラベルABは「割り当て可能な」バリアントラベル{C} {D}と「ブロックされた」バリアントラベル{CD}を生成し、処理が競合する2つのバリアントラベルを作成します。
For the example of a blocked variant between "m" and "rn" (and vice versa), there is no issue as long as "r" and "n" do not have variant mappings of their own, so that there cannot be multiple variant labels for the same input. However, it is preferable to avoid ambiguities altogether where possible.
"m"と "rn"の間（およびその逆）のブロックされたバリアントの例では、 "r"と "n"が独自のバリアントマッピングを持たない限り問題はありません。同じ入力のバリアントラベル。ただし、可能な場合はあいまいさを完全に回避することをお勧めします。
The easiest way to avoid an ambiguous segmentation into sequences is by never allowing both a sequence and all of its constituent parts simultaneously as independent parts of the repertoire, for example, by not defining B by itself as a member of the repertoire.
シーケンスへのあいまいなセグメンテーションを回避する最も簡単な方法は、シーケンスとそのすべての構成部分の両方をレパートリーの独立した部分として同時に許可しないことです。たとえば、B自体をレパートリーのメンバーとして定義しないことです。
Sequences are often used for combining sequences that consist of a base character B followed by one or more combining marks C. By enumerating all sequences in which a certain combining mark is expected and by not listing the combining mark by itself in the LGR, the mark cannot occur outside of these specifically enumerated contexts. In cases where enumeration is not possible or practicable, other techniques can be used to prevent ambiguous segmentation, for example, a context rule on code points that disallows B preceding C in any label except as part of a predefined sequence or class of sequences. The details of such techniques are outside the scope of this document (see [RFC7940] for information on context rules for code points).
シーケンスは、ベース文字Bとそれに続く1つ以上の結合マークCで構成されるシーケンスの結合によく使用されます。特定の結合マークが期待されるすべてのシーケンスを列挙し、LGRに結合マークを単独でリストしないことにより、マークこれらの具体的に列挙されたコンテキストの外では発生できません。列挙が不可能または実用的でない場合は、他の手法を使用して、あいまいなセグメンテーションを防ぐことができます。たとえば、事前定義されたシーケンスまたはシーケンスのクラスの一部として以外のラベルでBの前のCを許可しないコードポイントのコンテキストルール。このような手法の詳細は、このドキュメントの範囲外です（コードポイントのコンテキストルールについては、[RFC7940]を参照してください）。
The XML format defined in [RFC7940] corresponds fairly directly to the notation used for variant mappings in this document. (There is no notation in the RFC for variant type sets). In an LGR document, a simple member of a repertoire that does not have any variants is listed as:
[RFC7940]で定義されているXML形式は、このドキュメントのバリアントマッピングに使用される表記法にかなり直接対応しています。 （RFCには、バリアントタイプセットの表記はありません）。 LGRドキュメントでは、バリアントを持たないレパートリーの単純なメンバーは次のようにリストされます。
<char cp="nnnn" />
where nnnn is the [UNICODE] code point value in the standard uppercase hexadecimal notation padded to at least 4 digits and without leading "U+". For a code point sequence of length 2, the XML notation becomes:
ここで、nnnnは、標準の大文字の16進表記の[UNICODE]コードポイント値で、先頭に「U +」を付けずに4桁以上埋め込まれています。長さが2のコードポイントシーケンスの場合、XML表記は次のようになります。
<char cp="uuuu vvvvv" />
Variant mappings are defined by nesting <var> elements inside the
<char> element. For example, a variant relation of type "blocked"
C x--> X
C x-> X
is expressed as
として表現されます
<char cp="nnnn">
<var cp="mmmm" type="blocked" />
</char>
where "x-->" identifies a "blocked" type. (Other types include "a-->" for "allocatable", for example. Here, nnnn and mmmm are the [UNICODE] code point values for C and X, respectively. Either C or X could be a code point sequence or a single code point.
「x->」は「ブロックされた」タイプを示します。 （たとえば、他のタイプには、「割り当て可能」の「a->」が含まれます。ここで、nnnnおよびmmmmは、それぞれCおよびXの[UNICODE]コードポイント値です。CまたはXは、コードポイントシーケンスまたは単一のコードポイント。
A reflexive mapping is specified the same way, except that it always uses the same code point value for both the <char> and <var> element, for example:
再帰マッピングは、<char>要素と<var>要素の両方に常に同じコードポイント値を使用することを除いて、同じ方法で指定されます。次に例を示します。
X r-o--> X
Ｘ ｒーおーー＞ Ｘ
would correspond to
に対応する
<char cp="nnnn"><var cp="nnnn" type="out-of-repertoire-var" /></char>
Multiple <var> elements may be nested inside a single <char> element, but their "cp" values must be distinct (unless attributes for context rules are present and the combination of "cp" value and context attributes are distinct).
複数の<var>要素を単一の<char>要素内にネストできますが、それらの「cp」値は異なる必要があります（コンテキストルールの属性が存在し、「cp」値とコンテキスト属性の組み合わせが異なる場合を除く）。
<char cp="nnnn">
<var cp="kkkk" type="allocatable" />
<var cp="mmmm" type="blocked" />
</char>
A set of conditional variants like
のような条件付きバリアントのセット
final: C a--> K
!final: C x--> K
would correspond to
に対応する
<var cp="kkkk" when="final" type="allocatable" />
<var cp="kkkk" not-when="final" type="blocked" />
where the string "final" references a name of a context rule. Context rules are defined in [RFC7940]; they conceptually correspond to regular expressions. The details of how to create and define these rules are outside the scope of this document. If the label matches the context defined in the rule, the variant mapping is valid and takes part in further processing. Otherwise, it is invalid and ignored. Using the "not-when" attribute inverts the sense of the match. The two attributes are mutually exclusive.
文字列「final」は、コンテキストルールの名前を参照します。コンテキストルールは[RFC7940]で定義されています。概念的には正規表現に対応しています。これらのルールを作成および定義する方法の詳細は、このドキュメントの範囲外です。ラベルがルールで定義されたコンテキストと一致する場合、バリアントマッピングは有効であり、以降の処理に参加します。それ以外の場合は、無効で無視されます。 「not-when」属性を使用すると、一致の意味が逆になります。 2つの属性は相互に排他的です。
A derivation of a variant label disposition
バリアントラベルディスポジションの派生
if "only-variants" = "s" or "b" => allocatable
is expressed as
として表現されます
<action disp="allocatable" only-variants= "s b" />
Instead of using "if" and "else if", the <action> elements implicitly form a cascade, where the first action triggered defines the disposition of the label. The order of action elements is thus significant.
「if」と「else if」を使用する代わりに、<action>要素は暗黙的にカスケードを形成し、最初にトリガーされるアクションがラベルの配置を定義します。したがって、アクション要素の順序は重要です。
For the full specification of the XML format, see [RFC7940].
XML形式の完全な仕様については、[RFC7940]を参照してください。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
As described in [RFC7940], variants may be used as a tool to reduce certain avenues of attack in security-relevant identifiers by allowing certain labels to be "mutually exclusive or registered only to the same user". However, if indiscriminately designed, variants may themselves contribute to risks to the security or usability of the identifiers, whether resulting from an ambiguous definition or from allowing too many allocatable variants per label.
[RFC7940]で説明されているように、バリアントは、特定のラベルを「相互に排他的または同じユーザーのみに登録」できるようにすることで、セキュリティ関連の識別子における攻撃の特定の手段を減らすツールとして使用できます。ただし、無差別に設計した場合、あいまいな定義に起因する場合でも、ラベルごとに割り当て可能なバリアントが多すぎる場合でも、バリアント自体が識別子のセキュリティや使いやすさのリスクにつながる可能性があります。
The information in this document is intended to allow the reader to design a specification of an LGR that is "well behaved" with respect to variants; as used here, this term refers to an LGR that is predictable in its effects to the LGR author (and reviewer) and more reliable in its implementation.
このドキュメントの情報は、読者がバリアントに関して「適切に動作する」LGRの仕様を設計できるようにすることを目的としています。ここで使用されているように、この用語はLGRの作成者（およびレビューアー）への影響が予測可能であり、その実装がより信頼できるLGRを指します。
A well-behaved LGR is not merely one that can be expressed in [RFC7940], but, in addition, it actively avoids certain edge cases not prevented by the schema, such as those that would result in ambiguities in the specification of the intended disposition for some variant labels. By applying the additional considerations introduced in this document, including adding certain declarations that are optional under the schema and may not alter the results of processing a label, such an LGR becomes easier to review and its implementations easier to verify.
正常に動作するLGRは、[RFC7940]で表現できるものだけではなく、意図された処理の仕様にあいまいさをもたらすような、スキーマによって防止されない特定のエッジケースを積極的に回避します。一部のバリアントラベル。このドキュメントで紹介されている追加の考慮事項を適用することにより、スキーマの下でオプションであり、ラベルの処理結果を変更しない可能性がある特定の宣言を追加することにより、そのようなLGRを確認しやすくなり、その実装を検証しやすくなります。
It should be noted that variants are an important part, but only a part, of an LGR design. There are many other features of an LGR that this document does not touch upon. Also, the question of whether to define variants at all, or what labels are to be considered variants of each other, is not addressed here.
バリアントはLGR設計の重要な部分ですが、一部にすぎないことに注意してください。 LGRには、このドキュメントでは触れない他の多くの機能があります。また、バリアントを定義するかどうか、またはどのラベルが互いのバリアントと見なされるかについての質問は、ここでは扱いません。
[RFC7940] Davies, K. and A. Freytag, "Representing Label Generation Rulesets Using XML", RFC 7940, DOI 10.17487/RFC7940, August 2016, <https://www.rfc-editor.org/info/rfc7940>.
[RFC7940] Davies、K.およびA. Freytag、「Representing Label Generation Rulesets Using XML」、RFC 7940、DOI 10.17487 / RFC7940、2016年8月、<https://www.rfc-editor.org/info/rfc7940>。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<https://www.rfc-editor.org/info/rfc1034>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<https://www.rfc-editor.org/info/rfc1035>。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>.
[RFC5890] Klensin、J。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、DOI 10.17487 / RFC5890、2010年8月、<https://www.rfc-editor.org/info/ rfc5890>。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-editor.org/info/rfc5891>.
[RFC5891] Klensin、J。、「Internationalized Domain Names in Applications（IDNA）：Protocol」、RFC 5891、DOI 10.17487 / RFC5891、2010年8月、<https://www.rfc-editor.org/info/rfc5891>。
[RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, DOI 10.17487/RFC5892, August 2010, <https://www.rfc-editor.org/info/rfc5892>.
[RFC5892] Faltstrom、P。、編、「アプリケーションのUnicodeコードポイントと国際化ドメイン名（IDNA）」、RFC 5892、DOI 10.17487 / RFC5892、2010年8月、<https://www.rfc-editor.org / info / rfc5892>。
[RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010, <https://www.rfc-editor.org/info/rfc5893>.
[RFC5893]アルベストランド、H。、エド。およびC. Karp、「Right-to-Left Scripts for Internationalized Domain Names for Applications（IDNA）」、RFC 5893、DOI 10.17487 / RFC5893、2010年8月、<https://www.rfc-editor.org/info/rfc5893 >。
[RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010, <https://www.rfc-editor.org/info/rfc5894>.
[RFC5894] Klensin、J。、「アプリケーションの国際化ドメイン名（IDNA）：背景、説明、および理論的根拠」、RFC 5894、DOI 10.17487 / RFC5894、2010年8月、<https://www.rfc-editor.org/ info / rfc5894>。
[UNICODE] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[UNICODE] Unicodeコンソーシアム、「The Unicode Standard」、<http://www.unicode.org/versions/latest/>。
Acknowledgments
謝辞
Contributions that have shaped this document have been provided by Marc Blanchet, Ben Campbell, Patrik Faltstrom, Scott Hollenbeck, Mirja Kuehlewind, Sarmad Hussain, John Klensin, Alexey Melnikov, Nicholas Ostler, Michel Suignard, Andrew Sullivan, Wil Tan, and Suzanne Woolf.
このドキュメントを形作る寄稿は、マークブランシェ、ベンキャンベル、パトリックファルストレム、スコットホレンベック、ミルジャキュールウィンド、サーマドフセイン、ジョンクレンシン、アレクセイメリニコフ、ニコラスオストラー、ミシェルスィナード、アンドリューサリバン、ウィルタン、スザンヌウルフによって提供されました。
Author's Address
著者のアドレス
Asmus Freytag
アスムス・フレイタグ
Email: asmus@unicode.org