[要約] RFC 8264は、国際化された文字列の準備、強制、比較を行うためのPRECISフレームワークに関するものです。このRFCの目的は、アプリケーションプロトコルでの国際化された文字列の処理を効果的に行うためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 8264 Jabber.org
Obsoletes: 7564 M. Blanchet
Category: Standards Track Viagenie
ISSN: 2070-1721 October 2017
PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols
PRECISフレームワーク：アプリケーションプロトコルでの国際化された文字列の準備、適用、比較
Abstract
概要
Application protocols using Unicode code points in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode code points and thus is more agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 7564.
プロトコル文字列でUnicodeコードポイントを使用するアプリケーションプロトコルは、さまざまなプロトコルスロットに配置された文字列（アドレスや識別子など）に国際化ルールを適用し、有効な比較操作（認証や承認など）を実行するために、そのような文字列を適切に処理する必要があります。 ）。このドキュメントでは、Unicodeコードポイントのプロパティに依存する方法でアプリケーションプロトコルが国際化文字列（「PRECIS」）の準備、適用、および比較を実行できるようにするフレームワークを定義し、Unicodeのバージョンに関してより機敏です。その結果、このフレームワークは、国際化された文字列の処理に対して、以前のフレームワークであるStringprep（RFC 3454）よりも持続可能なアプローチを提供します。このドキュメントはRFC 7564を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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 https://www.rfc-editor.org/info/rfc8264.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8264で入手できます。
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
(https://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.
このドキュメントの発行。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Preparation, Enforcement, and Comparison . . . . . . . . . . 6
4. String Classes . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. IdentifierClass . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Valid . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Contextual Rule Required . . . . . . . . . . . . . . 10
4.2.3. Disallowed . . . . . . . . . . . . . . . . . . . . . 10
4.2.4. Unassigned . . . . . . . . . . . . . . . . . . . . . 10
4.2.5. Examples . . . . . . . . . . . . . . . . . . . . . . 11
4.3. FreeformClass . . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. Valid . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.2. Contextual Rule Required . . . . . . . . . . . . . . 12
4.3.3. Disallowed . . . . . . . . . . . . . . . . . . . . . 12
4.3.4. Unassigned . . . . . . . . . . . . . . . . . . . . . 12
4.3.5. Examples . . . . . . . . . . . . . . . . . . . . . . 12
4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Profiles Must Not Be Multiplied beyond Necessity . . . . 14
5.2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2.1. Width Mapping Rule . . . . . . . . . . . . . . . . . 15
5.2.2. Additional Mapping Rule . . . . . . . . . . . . . . . 15
5.2.3. Case Mapping Rule . . . . . . . . . . . . . . . . . . 16
5.2.4. Normalization Rule . . . . . . . . . . . . . . . . . 16
5.2.5. Directionality Rule . . . . . . . . . . . . . . . . . 17
5.3. A Note about Spaces . . . . . . . . . . . . . . . . . . . 18
6. Applications . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. How to Use PRECIS in Applications . . . . . . . . . . . . 18
6.2. Further Excluded Characters . . . . . . . . . . . . . . . 20
6.3. Building Application-Layer Constructs . . . . . . . . . . 20
7. Order of Operations . . . . . . . . . . . . . . . . . . . . . 21
8. Code Point Properties . . . . . . . . . . . . . . . . . . . . 21
9. Category Definitions Used to Calculate Derived Property . . . 24
9.1. LetterDigits (A) . . . . . . . . . . . . . . . . . . . . 25
9.2. Unstable (B) . . . . . . . . . . . . . . . . . . . . . . 25
9.3. IgnorableProperties (C) . . . . . . . . . . . . . . . . . 25
9.4. IgnorableBlocks (D) . . . . . . . . . . . . . . . . . . . 25
9.5. LDH (E) . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.6. Exceptions (F) . . . . . . . . . . . . . . . . . . . . . 25
9.7. BackwardCompatible (G) . . . . . . . . . . . . . . . . . 25
9.8. JoinControl (H) . . . . . . . . . . . . . . . . . . . . . 26
9.9. OldHangulJamo (I) . . . . . . . . . . . . . . . . . . . . 26
9.10. Unassigned (J) . . . . . . . . . . . . . . . . . . . . . 26
9.11. ASCII7 (K) . . . . . . . . . . . . . . . . . . . . . . . 26
9.12. Controls (L) . . . . . . . . . . . . . . . . . . . . . . 27
9.13. PrecisIgnorableProperties (M) . . . . . . . . . . . . . . 27
9.14. Spaces (N) . . . . . . . . . . . . . . . . . . . . . . . 27
9.15. Symbols (O) . . . . . . . . . . . . . . . . . . . . . . . 27
9.16. Punctuation (P) . . . . . . . . . . . . . . . . . . . . . 27
9.17. HasCompat (Q) . . . . . . . . . . . . . . . . . . . . . . 28
9.18. OtherLetterDigits (R) . . . . . . . . . . . . . . . . . . 28
10. Guidelines for Designated Experts . . . . . . . . . . . . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
11.1. PRECIS Derived Property Value Registry . . . . . . . . . 29
11.2. PRECIS Base Classes Registry . . . . . . . . . . . . . . 29
11.3. PRECIS Profiles Registry . . . . . . . . . . . . . . . . 30
12. Security Considerations . . . . . . . . . . . . . . . . . . . 32
12.1. General Issues . . . . . . . . . . . . . . . . . . . . . 32
12.2. Use of the IdentifierClass . . . . . . . . . . . . . . . 33
12.3. Use of the FreeformClass . . . . . . . . . . . . . . . . 33
12.4. Local Character Set Issues . . . . . . . . . . . . . . . 33
12.5. Visually Similar Characters . . . . . . . . . . . . . . 33
12.6. Security of Passwords . . . . . . . . . . . . . . . . . 35
13. Interoperability Considerations . . . . . . . . . . . . . . . 36
13.1. Coded Character Sets . . . . . . . . . . . . . . . . . . 36
13.2. Dependency on Unicode . . . . . . . . . . . . . . . . . 37
13.3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 37
13.4. Unicode Versions . . . . . . . . . . . . . . . . . . . . 37
13.5. Potential Changes to Handling of Certain Unicode Code
Points . . . . . . . . . . . . . . . . . . . . . . . . . 37
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
14.1. Normative References . . . . . . . . . . . . . . . . . . 38
14.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Changes from RFC 7564 . . . . . . . . . . . . . . . 43
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
Application protocols using Unicode code points [Unicode] in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode code points and thus is more agile with respect to versions of Unicode. (Note: PRECIS is restricted to Unicode and does not support any other coded character set [RFC6365].)
プロトコル文字列でUnicodeコードポイント[Unicode]を使用するアプリケーションプロトコルは、さまざまなプロトコルスロット（アドレスや識別子など）に配置された文字列に国際化規則を適用し、有効な比較操作（たとえば、認証または許可）。このドキュメントでは、Unicodeコードポイントのプロパティに依存する方法でアプリケーションプロトコルが国際化文字列（「PRECIS」）の準備、適用、および比較を実行できるようにするフレームワークを定義し、Unicodeのバージョンに関してより機敏です。 （注：PRECISはUnicodeに制限されており、他のコード化文字セット[RFC6365]をサポートしていません。）
As described in the PRECIS problem statement [RFC6885], many IETF protocols have used the Stringprep framework [RFC3454] as the basis for preparing, enforcing, and comparing protocol strings that contain Unicode code points, especially code points outside the ASCII range [RFC20]. The Stringprep framework was developed during work on the original technology for internationalized domain names (IDNs), here called "IDNA2003" [RFC3490], and Nameprep [RFC3491] was the Stringprep profile for IDNs. At the time, Stringprep was designed as a general framework so that other application protocols could define their own Stringprep profiles. Indeed, a number of application protocols defined such profiles.
PRECIS問題ステートメント[RFC6885]で説明されているように、多くのIETFプロトコルは、Unicodeコードポイント、特にASCII範囲外のコードポイント[RFC20]を含むプロトコル文字列を準備、適用、比較するための基礎としてStringprepフレームワーク[RFC3454]を使用しています。 。 Stringprepフレームワークは、国際化ドメイン名（IDN）の元の技術（ここでは "IDNA2003" [RFC3490]と呼ばれる）の開発中に開発され、Nameprep [RFC3491]はIDNのStringprepプロファイルでした。当時、Stringprepは、他のアプリケーションプロトコルが独自のStringprepプロファイルを定義できるように、一般的なフレームワークとして設計されました。実際、多くのアプリケーションプロトコルがこのようなプロファイルを定義しています。
After the publication of [RFC3454] in 2002, several significant issues arose with the use of Stringprep in the IDN case, as documented in the IAB's recommendations regarding IDNs [RFC4690] (most significantly, Stringprep was tied to Unicode version 3.2). Therefore, the newer IDNA specifications, here called "IDNA2008" [RFC5890] [RFC5891] [RFC5892] [RFC5893] [RFC5894], no longer use Stringprep and Nameprep. This migration away from Stringprep for IDNs prompted other "customers" of Stringprep to consider new approaches to the preparation, enforcement, and comparison of internationalized strings, as described in [RFC6885].
2002年の[RFC3454]の公開後、IDNに関するIABの推奨事項[RFC4690]で文書化されているように、IDNケースでのStringprepの使用にいくつかの重要な問題が発生しました（最も重要なのは、StringprepがUnicodeバージョン3.2に関連付けられていたためです）。したがって、ここでは「IDNA2008」と呼ばれる新しいIDNA仕様[RFC5890] [RFC5891] [RFC5892] [RFC5893] [RFC5894]は、StringprepとNameprepを使用しなくなりました。 [RFC6885]で説明されているように、Stringprep for IDNからのこの移行により、Stringprepの他の「顧客」は国際化された文字列の準備、適用、比較への新しいアプローチを検討するようになりました。
This document defines a framework for a post-Stringprep approach to the preparation, enforcement, and comparison of internationalized strings in application protocols, based on several principles:
このドキュメントでは、いくつかの原則に基づいて、アプリケーションプロトコルでの国際化された文字列の準備、適用、比較へのStringprep後のアプローチのフレームワークを定義します。
1. Define a small set of string classes that specify the Unicode code points appropriate for common application-protocol constructs (where possible, maintaining compatibility with IDNA2008 to help ensure a more consistent user experience).
1. 一般的なアプリケーションプロトコル構成に適切なUnicodeコードポイントを指定する文字列クラスの小さなセットを定義します（可能な場合、IDNA2008との互換性を維持して、より一貫したユーザーエクスペリエンスを保証します）。
2. Define each PRECIS string class in terms of Unicode code points and their properties so that an algorithm can be used to determine whether each code point or character category is (a) valid, (b) allowed in certain contexts, (c) disallowed, or (d) unassigned.
2. アルゴリズムを使用して各コードポイントまたは文字カテゴリが（a）有効であるか、（b）特定のコンテキストで許可されているか、（c）許可されていないか、または判断できるように、各PRECIS文字列クラスをUnicodeコードポイントとそのプロパティの観点から定義します。 （d）未割り当て。
3. Use an "inclusion model" such that a string class consists only of code points that are explicitly allowed, with the result that any code point not explicitly allowed is forbidden.
3. 「包含モデル」を使用して、文字列クラスが明示的に許可されているコードポイントのみで構成され、明示的に許可されていないコードポイントは禁止されます。
4. Enable application protocols to define profiles of the PRECIS string classes if necessary (addressing matters such as width mapping, case mapping, Unicode normalization, and directionality), but strongly discourage the multiplication of profiles beyond necessity in order to avoid violations of the "Principle of Least Astonishment".
4. アプリケーションプロトコルが必要に応じてPRECIS文字列クラスのプロファイルを定義できるようにします（幅のマッピング、大文字と小文字のマッピング、Unicodeの正規化、方向性などの問題に対処します）が、「原理の違反を回避するために、必要以上にプロファイルの乗算を行わないようにしてください。最小の驚き」。
It is expected that this framework will yield the following benefits:
このフレームワークは、次の利点をもたらすことが期待されています。
o Application protocols will be more agile with regard to Unicode versions (recognizing that complete agility cannot be realized in practice).
o アプリケーションプロトコルは、Unicodeバージョンに関してより俊敏になります（実際には、完全な俊敏性は実現できないことを認識しています）。
o Implementers will be able to share code point tables and software code across application protocols, most likely by means of software libraries.
o 実装者は、アプリケーションポイント全体でコードポイントテーブルとソフトウェアコードを共有できるようになります。
o End users will be able to acquire more accurate expectations about the code points that are acceptable in various contexts. Given this more uniform set of string classes, it is also expected that copy/paste operations between software implementing different application protocols will be more predictable and coherent.
o エンドユーザーは、さまざまなコンテキストで許容されるコードポイントについて、より正確な期待を獲得できます。このより均一な文字列クラスのセットを考えると、異なるアプリケーションプロトコルを実装するソフトウェア間のコピー/貼り付け操作がより予測可能で一貫性のあるものになることも期待されます。
Whereas the string classes define the "baseline" code points for a range of applications, profiling enables application protocols to apply the string classes in ways that are appropriate for common constructs such as usernames [RFC8265], opaque strings such as passwords [RFC8265], and nicknames [RFC8266]. Profiles are responsible for defining the handling of right-to-left code points as well as various mapping operations of the kind also discussed for IDNs in [RFC5895], such as case preservation or lowercasing, Unicode normalization, mapping of certain code points to other code points or to nothing, and mapping of fullwidth and halfwidth code points.
文字列クラスは一連のアプリケーションの「ベースライン」コードポイントを定義しますが、プロファイリングにより、アプリケーションプロトコルはユーザー名[RFC8265]、パスワード[RFC8265]などの一般的な構成に適した方法で文字列クラスを適用できます。とニックネーム[RFC8266]。プロファイルは、右から左へのコードポイントの処理と、[RFC5895]でIDNについても説明されている種類のさまざまなマッピング操作（大文字と小文字の保持または小文字化、Unicodeの正規化、特定のコードポイントのその他へのマッピングなど）の定義を担当します。コードポイントまたは何もない、および全幅と半幅のコードポイントのマッピング。
When an application applies a profile of a PRECIS string class, it transforms an input string (which might or might not be conforming) into an output string that definitively conforms to the profile. In particular, this document focuses on the resulting ability to achieve the following objectives:
アプリケーションは、PRECIS文字列クラスのプロファイルを適用すると、入力文字列（準拠している場合とそうでない場合がある）を、プロファイルに確実に準拠する出力文字列に変換します。特に、このドキュメントでは、次の目的を達成するために得られる能力に焦点を当てています。
a. Enforcing all the rules of a profile for a single output string to check whether the output string conforms to the rules of the profile and thus determine if a string can be included in a protocol slot, communicated to another entity within a protocol, stored in a retrieval system, etc.
a. 単一の出力文字列にプロファイルのすべてのルールを適用して、出力文字列がプロファイルのルールに準拠しているかどうかを確認し、プロトコルスロットに文字列を含めることができるかどうか、プロトコル内の別のエンティティと通信して、検索システムなど
b. Comparing two output strings to determine if they are equivalent, typically through octet-for-octet matching to test for
b. 2つの出力文字列を比較して、それらが同等であるかどうかを判断します。通常、テストするオクテットとオクテットのマッチングにより
"bit-string identity" (e.g., to make an access decision for purposes of authentication or authorization as further described in [RFC6943]).
「ビット文字列ID」（たとえば、[RFC6943]でさらに説明されているように、認証または許可の目的でアクセス決定を行うため）。
The opportunity to define profiles naturally introduces the possibility of a proliferation of profiles, thus potentially mitigating the benefits of common code and violating user expectations. See Section 5 for a discussion of this important topic.
プロファイルを定義する機会は当然、プロファイルの急増の可能性をもたらします。そのため、一般的なコードの利点を軽減し、ユーザーの期待に反する可能性があります。この重要なトピックの説明については、セクション5を参照してください。
In addition, it is extremely important for protocol designers and application developers to understand that the transformation of an input string to an output string is rarely reversible. As one relatively simple example, case mapping would transform an input string of "StPeter" to an output string of "stpeter", thus leading to a loss of information about the capitalization of the first and third characters. Similar considerations apply to other forms of mapping and normalization.
さらに、入力文字列から出力文字列への変換が可逆的であることはまれであることを理解することは、プロトコル設計者およびアプリケーション開発者にとって非常に重要です。比較的単純な例の1つとして、ケースマッピングでは、「StPeter」の入力文字列を「stpeter」の出力文字列に変換するため、最初と3番目の文字の大文字化に関する情報が失われます。同様の考慮事項が他の形式のマッピングと正規化にも適用されます。
Although this framework is similar to IDNA2008 and includes by reference some of the character categories defined in [RFC5892], it defines additional character categories to meet the needs of common application protocols other than DNS.
このフレームワークはIDNA2008に似ており、[RFC5892]で定義されている文字カテゴリの一部が参照により含まれていますが、DNS以外の一般的なアプリケーションプロトコルのニーズを満たすために追加の文字カテゴリが定義されています。
The character categories and calculation rules defined under Sections 8 and 9 are normative and apply to all Unicode code points. The code point table that results from applying the character categories and calculation rules to the latest version of Unicode can be found in an IANA registry (see Section 11).
セクション8および9で定義された文字カテゴリと計算規則は規範的であり、すべてのUnicodeコードポイントに適用されます。文字カテゴリと計算ルールを最新バージョンのUnicodeに適用した結果のコードポイントテーブルは、IANAレジストリにあります（セクション11を参照）。
Many important terms used in this document are defined in [RFC5890], [RFC6365], [RFC6885], and [Unicode]. The terms "left-to-right" (LTR) and "right-to-left" (RTL) are defined in Unicode Standard Annex #9 [UAX9].
このドキュメントで使用される多くの重要な用語は、[RFC5890]、[RFC6365]、[RFC6885]、および[Unicode]で定義されています。 「左から右」（LTR）および「右から左」（RTL）という用語は、Unicode Standard Annex＃9 [UAX9]で定義されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document distinguishes between three different actions that an entity can take with regard to a string: o Enforcement entails applying all of the rules specified for a particular string class, or profile thereof, to a single input string, for the purpose of checking whether the string conforms to all of the rules and thus determining if the string can be used in a given protocol slot.
このドキュメントでは、文字列に関してエンティティが実行できる3つの異なるアクションを区別します。o実施は、特定の文字列クラスまたはそのプロファイルに指定されたすべてのルールを単一の入力文字列に適用することを伴い、文字列はすべてのルールに準拠しているため、特定のプロトコルスロットで文字列を使用できるかどうかを決定します。
o Comparison entails applying all of the rules specified for a particular string class, or profile thereof, to two separate input strings, for the purpose of determining if the two strings are equivalent.
o 比較では、2つの文字列が等しいかどうかを判別するために、特定の文字列クラスまたはそのプロファイルに指定されたすべてのルールを2つの別々の入力文字列に適用します。
o Preparation primarily entails ensuring that the code points in a single input string are allowed by the underlying PRECIS string class, and sometimes also entails applying one or more of the rules specified for a particular string class or profile thereof. Preparation can be appropriate for constrained devices that can to some extent restrict the code points in a string to a limited repertoire of characters but that do not have the processing power or onboard memory to perform operations such as Unicode normalization. However, preparation does not ensure that an input string conforms to all of the rules for a string class or profile thereof.
o 準備には、基本的に、単一の入力文字列のコードポイントが基盤となるPRECIS文字列クラスによって許可されていることを確認する必要があり、特定の文字列クラスまたはそのプロファイルに指定された1つ以上のルールを適用する必要がある場合もあります。準備は、文字列のコードポイントを限られた文字のレパートリーにある程度制限できるが、処理能力またはオンボードメモリがなく、Unicodeの正規化などの操作を実行できない制約のあるデバイスに適しています。ただし、準備では、入力文字列が文字列クラスまたはそのプロファイルのすべての規則に準拠していることは保証されません。
Note: The term "preparation" as used in this specification and related documents has a much more limited scope than it did in Stringprep; it essentially refers to a kind of preprocessing of an input string, not the actual operations that apply internationalization rules to produce an output string (here termed "enforcement") or to compare two output strings (here termed "comparison").
注：この仕様と関連ドキュメントで使用されている「準備」という用語の範囲は、Stringprepで使用されたものよりもはるかに限定されています。これは基本的に、入力文字列の前処理の一種であり、国際化ルールを適用して出力文字列を生成する（ここでは「強制」と呼ぶ）か、2つの出力文字列を比較する（ここでは「比較」と呼ぶ）のではありません。
In most cases, authoritative entities such as servers are responsible for enforcement, whereas subsidiary entities such as clients are responsible only for preparation. The rationale for this distinction is that clients might not have the facilities (in terms of device memory and processing power) to enforce all the rules regarding internationalized strings (such as width mapping and Unicode normalization), although they can more easily limit the repertoire of characters they offer to an end user. By contrast, it is assumed that a server would have more capacity to enforce the rules, and in any case a server acts as an authority regarding allowable strings in protocol slots such as addresses and endpoint identifiers. In addition, a client cannot necessarily be trusted to properly generate such strings, especially for security-sensitive contexts such as authentication and authorization.
ほとんどの場合、サーバーなどの権限のあるエンティティは実施の責任を負いますが、クライアントなどの補助エンティティは準備のみを担当します。この区別の理論的根拠は、クライアントが（デバイスメモリと処理能力の観点から）国際化された文字列に関するすべてのルール（幅のマッピングやUnicodeの正規化など）を適用する機能を持っていない可能性があることです。エンドユーザーに提供する文字。対照的に、サーバーにはルールを適用するためのより多くの容量があると想定されており、いずれの場合もサーバーは、アドレスやエンドポイント識別子などのプロトコルスロット内の許容文字列に関する権限として機能します。さらに、クライアントは、特に認証や承認などのセキュリティが重要なコンテキストでは、そのような文字列を適切に生成することを必ずしも信頼できるわけではありません。
Starting in 2010, various "customers" of Stringprep began to discuss the need to define a post-Stringprep approach to the preparation and comparison of internationalized strings other than IDNs. This community analyzed the existing Stringprep profiles and also weighed the costs and benefits of defining a relatively small set of Unicode code points that would minimize the potential for user confusion caused by visually similar code points (and thus be relatively "safe") vs. defining a much larger set of Unicode code points that would maximize the potential for user creativity (and thus be relatively "expressive"). As a result, the community concluded that most existing uses could be addressed by two string classes:
2010年から、Stringprepのさまざまな「顧客」は、IDN以外の国際化された文字列の準備と比較のためのStringprep後のアプローチを定義する必要性について議論し始めました。このコミュニティは、既存のStringprepプロファイルを分析し、視覚的に類似したコードポイントによって引き起こされるユーザーの混乱の可能性を最小限に抑える（したがって比較的「安全」な）対定義する比較的小さなUnicodeコードポイントのセットを定義することのコストと利点を比較検討しました。ユーザーの創造性の可能性を最大化する（したがって比較的「表現力のある」）Unicodeコードポイントのはるかに大きなセット。その結果、コミュニティは、既存のほとんどの用途は2つの文字列クラスで対処できると結論付けました。
IdentifierClass: a sequence of letters, numbers, and some symbols that is used to identify or address a network entity such as a user account, a venue (e.g., a chat room), an information source (e.g., a data feed), or a collection of data (e.g., a file); the intent is that this class will minimize user confusion in a wide variety of application protocols, with the result that safety has been prioritized over expressiveness for this class.
IdentifierClass：文字、数字、およびユーザーアカウント、場所（チャットルームなど）、情報源（データフィードなど）などのネットワークエンティティの識別またはアドレス指定に使用されるいくつかの記号データのコレクション（ファイルなど）。その目的は、このクラスがさまざまなアプリケーションプロトコルでのユーザーの混乱を最小限に抑え、その結果、このクラスの表現力よりも安全性が優先されることです。
FreeformClass: a sequence of letters, numbers, symbols, spaces, and other code points that is used for free-form strings, including passwords as well as display elements such as human-friendly nicknames for devices or for participants in a chat room; the intent is that this class will allow nearly any Unicode code point, with the result that expressiveness has been prioritized over safety for this class. Note well that protocol designers, application developers, service providers, and end users might not understand or be able to enter all of the code points that can be included in the FreeformClass (see Section 12.3 for details).
FreeformClass：文字、数字、記号、スペース、およびパスワードなどの自由形式の文字列に使用される一連のコードポイント、およびデバイスやチャットルームの参加者の人にわかりやすいニックネームなどの表示要素。その目的は、このクラスがほぼすべてのUnicodeコードポイントを許可することです。その結果、このクラスの安全性よりも表現力が優先されます。プロトコル設計者、アプリケーション開発者、サービスプロバイダー、およびエンドユーザーは、FreeformClassに含めることができるすべてのコードポイントを理解できないか、入力できない場合があることに注意してください（詳細については、セクション12.3を参照）。
Future specifications might define additional PRECIS string classes, such as a class that falls somewhere between the IdentifierClass and the FreeformClass. At this time, it is not clear how useful such a class would be. In any case, because application developers are able to define profiles of PRECIS string classes, a protocol needing a construct between the IdentifierClass and the FreeformClass could define a restricted profile of the FreeformClass if needed.
将来の仕様では、IdentifierClassとFreeformClassの間にあるクラスなど、追加のPRECIS文字列クラスを定義する可能性があります。現時点では、そのようなクラスがどれほど役立つかは明らかではありません。いずれの場合でも、アプリケーション開発者はPRECIS文字列クラスのプロファイルを定義できるため、IdentifierClassとFreeformClassの間の構成を必要とするプロトコルは、必要に応じてFreeformClassの制限付きプロファイルを定義できます。
The following subsections discuss the IdentifierClass and FreeformClass in more detail, with reference to the dimensions described in Section 5 of [RFC6885]. Each string class is defined by the following behavioral rules: Valid: Defines which code points are treated as valid for the string.
次のサブセクションでは、[RFC6885]のセクション5で説明されているディメンションを参照しながら、IdentifierClassとFreeformClassについて詳しく説明します。各文字列クラスは、次の動作規則によって定義されます。有効：文字列に対して有効として扱われるコードポイントを定義します。
Contextual Rule Required: Defines which code points are treated as allowed only if the requirements of a contextual rule are met (i.e., either CONTEXTJ or CONTEXTO as originally defined in the IDNA2008 specifications).
必要なコンテキストルール：コンテキストルールの要件（つまり、IDNA2008仕様で最初に定義されたCONTEXTJまたはCONTEXTOのいずれか）が満たされた場合にのみ、許可として扱われるコードポイントを定義します。
Disallowed: Defines which code points need to be excluded from the string.
禁止：文字列から除外する必要があるコードポイントを定義します。
Unassigned: Defines application behavior in the presence of code points that are unknown (i.e., not yet designated) for the version of Unicode used by the application.
未割り当て：アプリケーションで使用されるUnicodeのバージョンで不明な（つまり、まだ指定されていない）コードポイントがある場合のアプリケーションの動作を定義します。
This document defines the valid, contextual rule required, disallowed, and unassigned rules for the IdentifierClass and FreeformClass. As described under Section 5, profiles of these string classes are responsible for defining the width mapping, additional mapping, case mapping, normalization, and directionality rules.
このドキュメントでは、IdentifierClassおよびFreeformClassの有効なコンテキストルールが必要であり、許可されておらず、割り当てられていないルールを定義します。セクション5で説明したように、これらの文字列クラスのプロファイルは、幅のマッピング、追加のマッピング、大文字と小文字のマッピング、正規化、および方向性のルールを定義する責任があります。
Most application technologies need strings that can be used to refer to, include, or communicate protocol strings like usernames, filenames, data feed identifiers, and chat room names. We group such strings into a class called "IdentifierClass" having the following features.
ほとんどのアプリケーションテクノロジーには、ユーザー名、ファイル名、データフィード識別子、チャットルーム名などのプロトコル文字列を参照、含める、または通信するために使用できる文字列が必要です。そのような文字列を、次の機能を持つ「IdentifierClass」と呼ばれるクラスにグループ化します。
o Code points traditionally used as letters and numbers in writing systems, i.e., the LetterDigits ("A") category first defined in [RFC5892] and listed here under Section 9.1.
o 従来、書記体系で文字と数字として使用されていたコードポイント。つまり、[RFC5892]で最初に定義され、ここでセクション9.1にリストされているLetterDigits（ "A"）カテゴリ。
o Code points in the range U+0021 through U+007E, i.e., the (printable) ASCII7 ("K") category defined under Section 9.11. These code points are "grandfathered" into PRECIS and thus are valid even if they would otherwise be disallowed according to the property-based rules specified in the next section.
o U + 0021からU + 007Eの範囲のコードポイント、つまりセクション9.11で定義された（印刷可能な）ASCII7（ "K"）カテゴリ。これらのコードポイントはPRECISに「拡大」されているため、次のセクションで指定するプロパティベースのルールに従って許可されない場合でも有効です。
Note: Although the PRECIS IdentifierClass reuses the LetterDigits category from IDNA2008, the range of code points allowed in the IdentifierClass is wider than the range of code points allowed in IDNA2008. The main reason is that IDNA2008 applies the Unstable ("B") category (Section 9.2) before the LetterDigits
注：PRECIS IdentifierClassはIDNA2008のLetterDigitsカテゴリーを再利用しますが、IdentifierClassで許可されるコードポイントの範囲は、IDNA2008で許可されるコードポイントの範囲よりも広いです。主な理由は、IDNA2008がLetterDigitsの前に不安定（「B」）カテゴリ（セクション9.2）を適用することです
category, thus disallowing uppercase code points, whereas the IdentifierClass does not apply the Unstable category.
したがって、大文字のコードポイントは許可されませんが、IdentifierClassはUnstableカテゴリを適用しません。
o A number of code points from the Exceptions ("F") category defined under Section 9.6.
o セクション9.6で定義された例外（ "F"）カテゴリのコードポイントの数。
o Joining code points, i.e., the JoinControl ("H") category defined under Section 9.8.
o コードポイントの結合、つまりセクション9.8で定義されたJoinControl（ "H"）カテゴリ。
o Old Hangul Jamo code points, i.e., the OldHangulJamo ("I") category defined under Section 9.9.
o Old Hangul Jamoコードポイント、つまり、セクション9.9で定義されたOldHangulJamo（ "I"）カテゴリ。
o Control code points, i.e., the Controls ("L") category defined under Section 9.12.
o コントロールコードポイント、つまりセクション9.12で定義されているコントロール（ "L"）カテゴリ。
o Ignorable code points, i.e., the PrecisIgnorableProperties ("M") category defined under Section 9.13.
o 無視できるコードポイント、つまりセクション9.13で定義されたPrecisIgnorableProperties（ "M"）カテゴリ。
o Space code points, i.e., the Spaces ("N") category defined under Section 9.14.
o スペースコードポイント、つまりセクション9.14で定義されたスペース（ "N"）カテゴリ。
o Symbol code points, i.e., the Symbols ("O") category defined under Section 9.15.
o シンボルコードポイント、つまりセクション9.15で定義されたシンボル（「O」）カテゴリ。
o Punctuation code points, i.e., the Punctuation ("P") category defined under Section 9.16.
o 句読点コードポイント、つまりセクション9.16で定義されている句読点（「P」）カテゴリ。
o Any code point that is decomposed and recomposed into something other than itself under Unicode Normalization Form KC, i.e., the HasCompat ("Q") category defined under Section 9.17. These code points are disallowed even if they would otherwise be valid according to the property-based rules specified in the previous section.
o Unicode正規化形式KC、つまりセクション9.17で定義されているHasCompat（「Q」）カテゴリの下で分解され、それ自体以外の何かに再構成されるコードポイント。これらのコードポイントは、前のセクションで指定されたプロパティベースのルールに従って有効でない場合でも許可されません。
o Letters and digits other than the "traditional" letters and digits allowed in IDNs, i.e., the OtherLetterDigits ("R") category defined under Section 9.18.
o IDNで許可されている「従来の」文字と数字以外の文字と数字、つまりセクション9.18で定義されているOtherLetterDigits（ "R"）カテゴリ。
Any code points that are not yet designated in the Unicode coded character set are considered unassigned for purposes of the IdentifierClass, and such code points are to be treated as disallowed. See Section 9.10.
Unicodeコード化文字セットでまだ指定されていないコードポイントは、IdentifierClassのために割り当てられていないと見なされ、そのようなコードポイントは許可されていないものとして扱われます。セクション9.10を参照してください。
As described in the Introduction to this document, the string classes do not handle all issues related to string preparation and comparison (such as case mapping); instead, such issues are handled at the level of profiles. Examples for profiles of the IdentifierClass can be found in [RFC8265] (the UsernameCaseMapped and UsernameCasePreserved profiles).
このドキュメントの概要で説明したように、文字列クラスは文字列の準備と比較（ケースマッピングなど）に関連するすべての問題を処理するわけではありません。代わりに、そのような問題はプロファイルのレベルで処理されます。 IdentifierClassのプロファイルの例は、[RFC8265]（UsernameCaseMappedおよびUsernameCasePreservedプロファイル）にあります。
Some application technologies need strings that can be used in a free-form way, e.g., as a password in an authentication exchange (see [RFC8265]) or a nickname in a chat room (see [RFC8266]). We group such things into a class called "FreeformClass" having the following features.
一部のアプリケーションテクノロジーでは、認証交換のパスワード（[RFC8265]を参照）やチャットルームのニックネーム（[RFC8266]を参照）など、自由形式で使用できる文字列が必要です。そのようなものを「FreeformClass」と呼ばれるクラスにグループ化し、以下の機能を備えています。
Security Warning: As mentioned, the FreeformClass prioritizes expressiveness over safety; Section 12.3 describes some of the security hazards involved with using or profiling the FreeformClass.
セキュリティ警告：前述のように、FreeformClassは安全性よりも表現力を優先します。セクション12.3では、FreeformClassの使用またはプロファイリングに関連するセキュリティ上の危険性について説明しています。
Security Warning: Consult Section 12.6 for relevant security considerations when strings conforming to the FreeformClass, or a profile thereof, are used as passwords.
セキュリティ警告：FreeformClassまたはそのプロファイルに準拠する文字列をパスワードとして使用する場合は、関連するセキュリティの考慮事項についてセクション12.6を参照してください。
o Traditional letters and numbers, i.e., the LetterDigits ("A") category first defined in [RFC5892] and listed here under Section 9.1.
o 従来の文字と数字、つまり[RFC5892]で最初に定義され、ここでセクション9.1にリストされているLetterDigits（ "A"）カテゴリ。
o Code points in the range U+0021 through U+007E, i.e., the (printable) ASCII7 ("K") category defined under Section 9.11.
o U + 0021からU + 007Eの範囲のコードポイント、つまりセクション9.11で定義された（印刷可能な）ASCII7（ "K"）カテゴリ。
o Space code points, i.e., the Spaces ("N") category defined under Section 9.14.
o スペースコードポイント、つまりセクション9.14で定義されたスペース（ "N"）カテゴリ。
o Symbol code points, i.e., the Symbols ("O") category defined under Section 9.15.
o シンボルコードポイント、つまりセクション9.15で定義されたシンボル（「O」）カテゴリ。
o Punctuation code points, i.e., the Punctuation ("P") category defined under Section 9.16.
o 句読点コードポイント、つまりセクション9.16で定義されている句読点（「P」）カテゴリ。
o Any code point that is decomposed and recomposed into something other than itself under Unicode Normalization Form KC, i.e., the HasCompat ("Q") category defined under Section 9.17.
o Unicode正規化形式KC、つまりセクション9.17で定義されているHasCompat（「Q」）カテゴリの下で分解され、それ自体以外の何かに再構成されるコードポイント。
o Letters and digits other than the "traditional" letters and digits allowed in IDNs, i.e., the OtherLetterDigits ("R") category defined under Section 9.18.
o IDNで許可されている「従来の」文字と数字以外の文字と数字、つまりセクション9.18で定義されているOtherLetterDigits（ "R"）カテゴリ。
o A number of code points from the Exceptions ("F") category defined under Section 9.6.
o セクション9.6で定義された例外（ "F"）カテゴリのコードポイントの数。
o Joining code points, i.e., the JoinControl ("H") category defined under Section 9.8.
o コードポイントの結合、つまりセクション9.8で定義されたJoinControl（ "H"）カテゴリ。
o Old Hangul Jamo code points, i.e., the OldHangulJamo ("I") category defined under Section 9.9.
o Old Hangul Jamoコードポイント、つまり、セクション9.9で定義されたOldHangulJamo（ "I"）カテゴリ。
o Control code points, i.e., the Controls ("L") category defined under Section 9.12.
o コントロールコードポイント、つまりセクション9.12で定義されているコントロール（ "L"）カテゴリ。
o Ignorable code points, i.e., the PrecisIgnorableProperties ("M") category defined under Section 9.13.
o 無視できるコードポイント、つまりセクション9.13で定義されたPrecisIgnorableProperties（ "M"）カテゴリ。
Any code points that are not yet designated in the Unicode coded character set are considered unassigned for purposes of the FreeformClass, and such code points are to be treated as disallowed.
Unicodeコード化文字セットでまだ指定されていないコードポイントは、FreeformClassのために割り当てられていないと見なされ、そのようなコードポイントは許可されていないものとして扱われます。
As described in the Introduction to this document, the string classes do not handle all issues related to string preparation and comparison (such as case mapping); instead, such issues are handled at the level of profiles. Examples for profiles of the FreeformClass can be found in [RFC8265] (the OpaqueString profile) and [RFC8266] (the Nickname profile).
このドキュメントの概要で説明したように、文字列クラスは文字列の準備と比較（ケースマッピングなど）に関連するすべての問題を処理するわけではありません。代わりに、そのような問題はプロファイルのレベルで処理されます。 FreeformClassのプロファイルの例は、[RFC8265]（OpaqueStringプロファイル）および[RFC8266]（ニックネームプロファイル）にあります。
The following table summarizes the differences between the IdentifierClass and the FreeformClass (i.e., the disposition of a code point as valid, contextual rule required, disallowed, or unassigned), depending on its PRECIS category.
次の表は、PRECISカテゴリに応じて、IdentifierClassとFreeformClassの違い（つまり、コードポイントの処理が有効であり、コンテキストルールが必要である、許可されていない、または割り当てられていない）をまとめたものです。
+===============================+=================+===============+
| CATEGORY | IDENTIFIERCLASS | FREEFORMCLASS |
+===============================+=================+===============+
| (A) LetterDigits | Valid | Valid |
+-------------------------------+-----------------+---------------+
| (B) Unstable | [N/A (unused)] |
+-------------------------------+-----------------+---------------+
| (C) IgnorableProperties | [N/A (unused)] |
+-------------------------------+-----------------+---------------+
| (D) IgnorableBlocks | [N/A (unused)] |
+-------------------------------+-----------------+---------------+
| (E) LDH | [N/A (unused)] |
+-------------------------------+-----------------+---------------+
| (F) Exceptions | Contextual | Contextual |
| | Rule Required | Rule Required |
+-------------------------------+-----------------+---------------+
| (G) BackwardCompatible | [Handled by IDNA Rules] |
+-------------------------------+-----------------+---------------+
| (H) JoinControl | Contextual | Contextual |
| | Rule Required | Rule Required |
+-------------------------------+-----------------+---------------+
| (I) OldHangulJamo | Disallowed | Disallowed |
+-------------------------------+-----------------+---------------+
| (J) Unassigned | Unassigned | Unassigned |
+-------------------------------+-----------------+---------------+
| (K) ASCII7 | Valid | Valid |
+-------------------------------+-----------------+---------------+
| (L) Controls | Disallowed | Disallowed |
+-------------------------------+-----------------+---------------+
| (M) PrecisIgnorableProperties | Disallowed | Disallowed |
+-------------------------------+-----------------+---------------+
| (N) Spaces | Disallowed | Valid |
+-------------------------------+-----------------+---------------+
| (O) Symbols | Disallowed | Valid |
+-------------------------------+-----------------+---------------+
| (P) Punctuation | Disallowed | Valid |
+-------------------------------+-----------------+---------------+
| (Q) HasCompat | Disallowed | Valid |
+-------------------------------+-----------------+---------------+
| (R) OtherLetterDigits | Disallowed | Valid |
+-------------------------------+-----------------+---------------+
Table 1: Comparative Disposition of Code Points
表1：コードポイントの処理の比較
This framework document defines the valid, contextual rule required, disallowed, and unassigned rules for the IdentifierClass and the FreeformClass. A profile of a PRECIS string class MUST define the width mapping, additional mapping (if any), case mapping, normalization, and directionality rules. A profile MAY also restrict the allowable code points above and beyond the definition of the relevant PRECIS string class (but MUST NOT add as valid any code points that are disallowed by the relevant PRECIS string class). These matters are discussed in the following subsections.
このフレームワークドキュメントは、IdentifierClassとFreeformClassの有効なコンテキストルールが必要であり、許可されておらず、割り当てられていないルールを定義します。 PRECIS文字列クラスのプロファイルは、幅のマッピング、追加のマッピング（存在する場合）、ケースのマッピング、正規化、および方向性のルールを定義する必要があります。プロファイルは、関連するPRECIS文字列クラスの定義を超えて、許容されるコードポイントを制限することもできます（ただし、関連するPRECIS文字列クラスによって許可されていないコードポイントを有効なものとして追加してはなりません）。これらの事項については、次のサブセクションで説明します。
Profiles of the PRECIS string classes are registered with the IANA as described under Section 11.3. Profile names use the following convention: they are of the form "Profilename of BaseClass", where the "Profilename" string is a differentiator and "BaseClass" is the name of the PRECIS string class being profiled; for example, the profile used for opaque strings such as passwords is the OpaqueString profile of the FreeformClass [RFC8265].
PRECIS文字列クラスのプロファイルは、セクション11.3で説明されているようにIANAに登録されます。プロファイル名は次の規則を使用します。「Profilename of BaseClass」の形式です。「Profilename」文字列は差別化要因であり、「BaseClass」はプロファイル対象のPRECIS文字列クラスの名前です。たとえば、パスワードなどの不透明な文字列に使用されるプロファイルは、FreeformClass [RFC8265]のOpaqueStringプロファイルです。
The risk of profile proliferation is significant because having too many profiles will result in different behavior across various applications, thus violating what is known in user interface design as the "Principle of Least Astonishment".
プロファイルが多すぎると、さまざまなアプリケーションで異なる動作が発生し、ユーザーインターフェースの設計で「最小驚きの原則」として知られているものに違反するため、プロファイルが急増するリスクは重大です。
Indeed, we already have too many profiles. Ideally, we would have at most two or three profiles. Unfortunately, numerous application protocols exist with their own quirks regarding protocol strings. Domain names, email addresses, instant messaging addresses, chat room names, user nicknames or display names, filenames, authentication identifiers, passwords, and other strings already exist in the wild and need to be supported in existing application protocols such as DNS, SMTP, the Extensible Messaging and Presence Protocol (XMPP), Internet Relay Chat (IRC), NFS, the Internet Small Computer System Interface (iSCSI), the Extensible Authentication Protocol (EAP), and the Simple Authentication and Security Layer (SASL) [RFC4422], among others.
実際、すでにプロファイルが多すぎます。理想的には、最大2つまたは3つのプロファイルを持つことになります。残念ながら、プロトコル文字列に関して独自の癖がある多数のアプリケーションプロトコルが存在します。ドメイン名、電子メールアドレス、インスタントメッセージングアドレス、チャットルーム名、ユーザーのニックネームまたは表示名、ファイル名、認証識別子、パスワード、およびその他の文字列はすでに存在しており、DNS、SMTPなどの既存のアプリケーションプロトコルでサポートされる必要があります。 Extensible Messaging and Presence Protocol（XMPP）、Internet Relay Chat（IRC）、NFS、Internet Small Computer System Interface（iSCSI）、Extensible Authentication Protocol（EAP）、およびSimple Authentication and Security Layer（SASL）[RFC4422] 、とりわけ。
Nevertheless, profiles must not be multiplied beyond necessity.
それにもかかわらず、プロファイルは必要以上に乗算してはなりません。
To help prevent profile proliferation, this document recommends sensible defaults for the various options offered to profile creators (such as width mapping and Unicode normalization). In addition, the guidelines for designated experts provided under Section 10 are meant to encourage a high level of due diligence regarding new profiles.
プロファイルの急増を防ぐために、このドキュメントでは、プロファイル作成者に提供されるさまざまなオプション（幅マッピングやUnicode正規化など）に適切なデフォルトを推奨しています。さらに、セクション10で提供される指定された専門家向けのガイドラインは、新しいプロファイルに関する高度なデューデリジェンスを促進することを目的としています。
The width mapping rule of a profile specifies whether width mapping is performed on a string and how the mapping is done. Typically, such mapping consists of mapping fullwidth and halfwidth code points, i.e., code points with a Decomposition Type of Wide or Narrow, to their decomposition mappings; as an example, "０" (FULLWIDTH DIGIT ZERO, U+FF10) would be mapped to "0" (DIGIT ZERO U+0030).
プロファイルの幅マッピングルールは、文字列に対して幅マッピングを実行するかどうか、およびマッピングの方法を指定します。通常、このようなマッピングは、全幅および半幅のコードポイント、つまり、分解タイプがWideまたはNarrowのコードポイントを分解マッピングにマッピングすることで構成されます。例として、「０」（FULLWIDTH DIGIT ZERO、U + FF10）は「0」（DIGIT ZERO U + 0030）にマッピングされます。
The normalization form specified by a profile (see below) has an impact on the need for width mapping. Because width mapping is performed as a part of compatibility decomposition, a profile employing either Normalization Form KD (NFKD) or Normalization Form KC (NFKC) does not need to specify width mapping. However, if Unicode Normalization Form C (NFC) is used (as is recommended), then the profile needs to specify whether to apply width mapping; in this case, width mapping is in general RECOMMENDED because allowing fullwidth and halfwidth code points to remain unmapped to their compatibility variants would violate the "Principle of Least Astonishment". For more information about the concept of width in East Asian scripts within Unicode, see Unicode Standard Annex #11 [UAX11].
プロファイル（下記参照）で指定された正規化フォームは、幅マッピングの必要性に影響を与えます。幅マッピングは互換性分解の一部として実行されるため、正規化形式KD（NFKD）または正規化形式KC（NFKC）を使用するプロファイルでは、幅マッピングを指定する必要はありません。ただし、Unicode正規化形式C（NFC）が使用されている場合（推奨）、プロファイルは幅マッピングを適用するかどうかを指定する必要があります。この場合、全幅と半幅のコードポイントを互換バリアントにマッピングしないでおくことを許可すると、「最小驚きの原則」に違反するため、幅マッピングは一般的に推奨されます。 Unicode内の東アジア文字の幅の概念の詳細については、Unicode Standard Annex＃11 [UAX11]を参照してください。
Note: Because the East Asian width property is not guaranteed to be stable by the Unicode Standard (see <http://unicode.org/policies/stability_policy.html> for details), the results of applying a given width mapping rule might not be consistent across different versions of Unicode.
注：東アジアの幅プロパティは、Unicode標準（詳細については<http://unicode.org/policies/stability_policy.html>を参照）では安定していることが保証されていないため、特定の幅マッピングルールを適用した結果は、 Unicodeの異なるバージョン間で一貫している。
The additional mapping rule of a profile specifies whether additional mappings are performed on a string, such as:
プロファイルの追加のマッピングルールは、次のような文字列に対して追加のマッピングを実行するかどうかを指定します。
o Mapping of delimiter code points (such as '@', ':', '/', '+', and '-').
o 区切りコードポイントのマッピング（ '@'、 '：'、 '/'、 '+'、 '-'など）。
o Mapping of special code points (e.g., non-ASCII space code points to SPACE (U+0020) or control code points to nothing).
o 特別なコードポイントのマッピング（ASCII以外のスペースコードポイントがSPACE（U + 0020）を指している、または制御コードポイントが何も指していません）。
The PRECIS mappings document [RFC7790] describes such mappings in more detail.
PRECISマッピングドキュメント[RFC7790]は、そのようなマッピングをより詳細に説明しています。
The case mapping rule of a profile specifies whether case mapping (instead of case preservation) is performed on a string and how the mapping is applied (e.g., mapping uppercase and titlecase code points to their lowercase equivalents).
プロファイルのケースマッピングルールは、文字列に対してケースマッピング（ケース保持の代わりに）が実行されるかどうか、およびマッピングがどのように適用されるか（たとえば、大文字とタイトルケースのコードポイントが対応する小文字を指す）を指定します。
If case mapping is desired (instead of case preservation), it is RECOMMENDED to use the Unicode toLowerCase() operation defined in the Unicode Standard [Unicode]. In contrast to the Unicode toCaseFold() operation, the toLowerCase() operation is less likely to violate the "Principle of Least Astonishment", especially when an application merely wishes to convert uppercase and titlecase code points to their lowercase equivalents while preserving lowercase code points. Although the toCaseFold() operation can be appropriate when an application needs to compare two strings (such as in search operations), in general few application developers and even fewer users understand its implications, so toLowerCase() is almost always the safer choice.
ケースのマッピングが必要な場合（ケースを保持するのではなく）、Unicode標準[Unicode]で定義されているUnicode toLowerCase()オペレーションを使用することをお勧めします。 UnicodeのtoCaseFold()操作とは対照的に、toLowerCase()操作は、特にアプリケーションが大文字とタイトルケースのコードポイントを小文字のコードポイントを保持しながら同等の小文字に変換したい場合に、「最小驚きの原則」に違反する可能性が低くなります。 。 toCaseFold()操作は、アプリケーションが2つの文字列を比較する必要がある場合（検索操作など）に適していますが、一般に、アプリケーション開発者は少なく、その意味を理解するユーザーは少ないため、toLowerCase()がほとんど常に安全な選択です。
Note: Neither toLowerCase() nor toCaseFold() is designed to handle various language-specific issues, such as the character "ı" (LATIN SMALL LETTER DOTLESS I, U+0131) in several Turkic languages. The reader is referred to the PRECIS mappings document [RFC7790], which describes these issues in greater detail.
注：toLowerCase()もtoCaseFold()も、いくつかのチュルク語の文字「ı」（ラテン語の小文字DOTLESS I、U + 0131）など、さまざまな言語固有の問題を処理するようには設計されていません。読者は、これらの問題をより詳細に説明するPRECISマッピングドキュメント[RFC7790]を参照されます。
In order to maximize entropy and minimize the potential for false accepts, it is NOT RECOMMENDED for application protocols to map uppercase and titlecase code points to their lowercase equivalents when strings conforming to the FreeformClass, or a profile thereof, are used in passwords; instead, it is RECOMMENDED to preserve the case of all code points contained in such strings and then perform case-sensitive comparison. See also the related discussion in Section 12.6 of this document and in [RFC8265].
エントロピーを最大化し、誤った受け入れの可能性を最小限に抑えるために、パスワードでFreeformClassまたはそのプロファイルに準拠する文字列を使用する場合、大文字とタイトルケースのコードポイントを同等の小文字にマッピングすることは、アプリケーションプロトコルでは推奨されません。代わりに、そのような文字列に含まれるすべてのコードポイントの大文字と小文字を保持し、大文字と小文字を区別して比較することをお勧めします。このドキュメントのセクション12.6と[RFC8265]の関連する説明も参照してください。
The normalization rule of a profile specifies which Unicode Normalization Form (D, KD, C, or KC) is to be applied (see Unicode Standard Annex #15 [UAX15] for background information).
プロファイルの正規化ルールは、どのUnicode正規化フォーム（D、KD、C、またはKC）を適用するかを指定します（背景情報については、Unicode Standard Annex＃15 [UAX15]を参照してください）。
In accordance with [RFC5198], Normalization Form C (NFC) is RECOMMENDED.
[RFC5198]に従って、正規化形式C（NFC）が推奨されます。
Protocol designers and application developers need to understand that certain Unicode normalization forms, especially NFKC and NFKD, can result in significant loss of information in various circumstances and that these circumstances can depend on the language and script of the strings to which the normalization forms are applied. Extreme care should be taken when specifying the use of these normalization forms.
プロトコル設計者とアプリケーション開発者は、特定のUnicode正規化形式、特にNFKCとNFKDがさまざまな状況で情報を大幅に失う可能性があり、これらの状況は正規化形式が適用される文字列の言語とスクリプトに依存する可能性があることを理解する必要があります。 。これらの正規化形式の使用を指定するときは、細心の注意を払う必要があります。
The directionality rule of a profile specifies how to treat strings containing what are often called "right-to-left" (RTL) code points (see Unicode Standard Annex #9 [UAX9]). RTL code points come from scripts that are normally written from right to left and are considered by Unicode to, themselves, have right-to-left directionality. Some strings containing RTL code points also contain "left-to-right" (LTR) code points, such as ASCII numerals, as well as code points without directional properties. Consequently, such strings are known as "bidirectional strings".
プロファイルの方向性規則は、「右から左」（RTL）コードポイントと呼ばれることが多いものを含む文字列の処理方法を指定します（Unicode Standard Annex＃9 [UAX9]を参照）。 RTLコードポイントは、通常は右から左に記述され、Unicodeによってそれ自体が右から左の方向性を持つと見なされるスクリプトから取得されます。 RTLコードポイントを含む一部の文字列には、ASCII数値などの "左から右"（LTR）コードポイントや、方向プロパティのないコードポイントも含まれます。したがって、このような文字列は「双方向文字列」と呼ばれます。
Presenting bidirectional strings in different layout systems (e.g., a user interface that is configured to handle primarily an RTL script vs. an interface that is configured to handle primarily an LTR script) can yield display results that, while predictable to those who understand the display rules, are counterintuitive to casual users. In particular, the same bidirectional string (in PRECIS terms) might not be presented in the same way to users of those different layout systems, even though the presentation is consistent within any particular layout system. In some applications, these presentation differences might be considered problematic and thus the application designers might wish to restrict the use of bidirectional strings by specifying a directionality rule. In other applications, these presentation differences might not be considered problematic (this especially tends to be true of more "free-form" strings) and thus no directionality rule is needed.
さまざまなレイアウトシステム（たとえば、主にRTLスクリプトを処理するように構成されているユーザーインターフェイスと主にLTRスクリプトを処理するように構成されているインターフェイス）で双方向文字列を提示すると、表示を理解している人には予測可能な表示結果が得られますルールは、カジュアルなユーザーには直感的ではありません。特に、プレゼンテーションが特定のレイアウトシステム内で一貫していても、同じ双方向文字列（PRECIS用語で）は、これらの異なるレイアウトシステムのユーザーに同じ方法で表示されない場合があります。一部のアプリケーションでは、これらの表示の違いが問題と見なされる可能性があるため、アプリケーション設計者は、方向性ルールを指定して双方向文字列の使用を制限したい場合があります。他のアプリケーションでは、これらの表示の違いは問題とは見なされない可能性があり（これは特に、より「自由形式」の文字列に当てはまる傾向があります）、方向性ルールは必要ありません。
The PRECIS framework does not directly address how to deal with bidirectional strings across all string classes and profiles nor does it define any new directionality rules, because at present there is no widely accepted and implemented solution for the safe display of arbitrary bidirectional strings beyond the Unicode bidirectional algorithm [UAX9]. Although rules for management and display of bidirectional strings have been defined for domain name labels and similar identifiers through the "Bidi Rule" specified in the IDNA2008 specification on right-to-left scripts [RFC5893], those rules are quite restrictive and are not necessarily applicable to all bidirectional strings.
Unicodeを超えて任意の双方向文字列を安全に表示するための広く受け入れられ実装されているソリューションは現在ないため、PRECISフレームワークは、すべての文字列クラスとプロファイルで双方向文字列を処理する方法を直接扱っておらず、新しい方向性ルールも定義していません。双方向アルゴリズム[UAX9]。双方向文字列の管理と表示に関するルールは、右から左へのスクリプト[RFC5893]のIDNA2008仕様で指定されている「Bidiルール」によってドメイン名ラベルと同様の識別子に定義されていますが、これらのルールはかなり制限的であり、必ずしもそうではありませんすべての双方向文字列に適用できます。
The authors of a PRECIS profile might believe that they need to define a new directionality rule of their own. Because of the complexity of the issues involved, such a belief is almost always misguided, even if the authors have done a great deal of careful research into the challenges of displaying bidirectional strings. This document strongly suggests that profile authors who are thinking about defining a new directionality rule should think again and instead consider using the "Bidi Rule" [RFC5893] (for profiles based on the IdentifierClass) or following the Unicode bidirectional algorithm [UAX9] (for profiles based on the FreeformClass or in situations where the IdentifierClass is not appropriate).
PRECISプロファイルの作成者は、独自の新しい方向性ルールを定義する必要があると信じているかもしれません。関係する問題は複雑であるため、たとえ双方向の文字列を表示するという課題について著者が綿密な調査を行ったとしても、そのような考えはほとんど常に見当違いです。このドキュメントでは、新しい方向性ルールの定義を検討しているプロファイル作成者がもう一度考え直して、代わりに「Bidiルール」[RFC5893]（IdentifierClassに基づくプロファイルの場合）またはUnicode双方向アルゴリズム[UAX9]（ FreeformClassに基づくプロファイル、またはIdentifierClassが適切でない状況でのプロファイル）。
With regard to the IdentifierClass, the consensus of the PRECIS Working Group was that spaces are problematic for many reasons, including the following:
IdentifierClassに関して、PRECISワーキンググループのコンセンサスは、以下を含む多くの理由でスペースに問題があるということでした。
o Many Unicode code points are confusable with SPACE (U+0020).
o 多くのUnicodeコードポイントは、スペース（U + 0020）と混同されます。
o Even if non-ASCII space code points are mapped to SPACE (U+0020), space code points are often not rendered in user interfaces, leading to the possibility that a human user might consider a string containing spaces to be equivalent to the same string without spaces.
o 非ASCIIのスペースコードポイントがSPACE（U + 0020）にマップされている場合でも、スペースコードポイントはユーザーインターフェイスでレンダリングされないことが多く、人間のユーザーがスペースを含む文字列を同じ文字列と同等であると見なす可能性がありますスペースなし。
o In some locales, some devices are known to generate a code point other than SPACE (U+0020), such as ZERO WIDTH JOINER (U+200D), when a user performs an action like pressing the space bar on a keyboard.
o 一部のロケールでは、ユーザーがキーボードのスペースバーを押すなどのアクションを実行すると、ZERO WIDTH JOINER（U + 200D）など、SPACE（U + 0020）以外のコードポイントを生成するデバイスが知られています。
One consequence of disallowing space code points in the IdentifierClass might be to effectively discourage their use within identifiers created in newer application protocols; given the challenges involved with properly handling space code points (especially non-ASCII space code points) in identifiers and other protocol strings, the PRECIS Working Group considered this to be a feature, not a bug.
IdentifierClassでスペースコードポイントを許可しないことの1つの結果は、新しいアプリケーションプロトコルで作成された識別子内での使用を効果的に阻止することです。識別子やその他のプロトコル文字列でスペースコードポイント（特に非ASCIIスペースコードポイント）を適切に処理することに伴う課題を考慮して、PRECISワーキンググループはこれをバグではなく機能と見なしました。
However, the FreeformClass does allow spaces; this in turn enables application protocols to define profiles of the FreeformClass that are more flexible than any profiles of the IdentifierClass. In addition, as explained in Section 6.3, application protocols can also define application-layer constructs containing spaces.
ただし、FreeformClassではスペースを使用できます。これにより、アプリケーションプロトコルは、IdentifierClassのどのプロファイルよりも柔軟なFreeformClassのプロファイルを定義できます。さらに、セクション6.3で説明されているように、アプリケーションプロトコルは、スペースを含むアプリケーションレイヤー構造も定義できます。
Although PRECIS has been designed with applications in mind, internationalization is not suddenly made easy through the use of PRECIS. Indeed, because it is extremely difficult for protocol designers and application developers to do the right thing for all users when supporting internationalized strings, often the safest option is to support only the ASCII range [RFC20] in various protocol slots. This state of affairs is unfortunate but is the direct result of the complexities involved with human languages (e.g., the vast number of code points, scripts, user communities, and rules with their inevitable exceptions), which kinds of strings application developers and their users wish to support, the wide range of devices that users employ to access services enabled by various Internet protocols, and so on.
PRECISはアプリケーションを考慮して設計されていますが、PRECISの使用によって国際化が突然容易になるわけではありません。実際、国際化された文字列をサポートする場合、プロトコル設計者とアプリケーション開発者がすべてのユーザーに対して正しいことを行うことは非常に難しいため、多くの場合、最も安全なオプションは、さまざまなプロトコルスロットでASCII範囲[RFC20]のみをサポートすることです。この状況は残念ですが、人間の言語に関わる複雑さ（例：膨大な数のコードポイント、スクリプト、ユーザーコミュニティ、および不可避の例外を伴うルール）、文字列アプリケーションの開発者とユーザーの種類の直接的な結果ですユーザーがさまざまなインターネットプロトコルによって可能になるサービスにアクセスするために使用する幅広いデバイスなどをサポートしたい。
Despite these significant challenges, application and protocol developers sometimes persevere in attempting to support internationalized strings in their systems. These developers need to think carefully about how they will use the PRECIS string classes, or profiles thereof, in their applications. This section provides some guidelines to application developers (and to expert reviewers of application-protocol specifications).
これらの重要な課題にもかかわらず、アプリケーションとプロトコルの開発者は、システムで国際化された文字列をサポートしようと頑張ることがあります。これらの開発者は、アプリケーションでPRECIS文字列クラスまたはそのプロファイルをどのように使用するかについて慎重に検討する必要があります。このセクションでは、アプリケーション開発者（およびアプリケーションプロトコル仕様の専門家レビューア）にいくつかのガイドラインを提供します。
o Don't define your own profile unless absolutely necessary (see Section 5.1). Existing profiles have been designed for wide reuse. It is highly likely that an existing profile will meet your needs, especially given the ability to specify further excluded code points (Section 6.2) and to build application-layer constructs (see Section 6.3).
o どうしても必要な場合を除いて、独自のプロファイルを定義しないでください（セクション5.1を参照）。既存のプロファイルは、広く再利用できるように設計されています。特に、除外されるコードポイントをさらに指定したり（セクション6.2）、アプリケーションレイヤー構造を構築したりすることで（セクション6.3を参照）、既存のプロファイルがニーズを満たす可能性が高くなります。
o Do specify:
o 指定してください：
* Exactly which entities are responsible for preparation, enforcement, and comparison of internationalized strings (e.g., servers or clients).
* 国際化された文字列（サーバーやクライアントなど）の準備、適用、比較を担当するエンティティはどれですか。
* Exactly when those entities need to complete their tasks (e.g., a server might need to enforce the rules of a profile before allowing a client to gain network access).
* これらのエンティティがタスクを完了する必要がある正確なタイミング（たとえば、サーバーがクライアントにネットワークアクセスを許可する前にプロファイルのルールを適用する必要がある場合があります）。
* Exactly which protocol slots need to be checked against which profiles (e.g., checking the address of a message's intended recipient against the UsernameCaseMapped profile [RFC8265] of the IdentifierClass or checking the password of a user against the OpaqueString profile [RFC8265] of the FreeformClass).
* どのプロファイルスロットをどのプロファイルに対してチェックする必要があるか（たとえば、メッセージの目的の受信者のアドレスをIdentifierClassのUsernameCaseMappedプロファイル[RFC8265]に対してチェックするか、ユーザーのパスワードをFreeformClassのOpaqueStringプロファイル[RFC8265]に対してチェックする） 。
See [RFC8265] and [RFC7622] for definitions of these matters for several applications.
いくつかのアプリケーションのこれらの問題の定義については、[RFC8265]および[RFC7622]を参照してください。
An application protocol that uses a profile MAY specify particular code points that are not allowed in relevant slots within that application protocol, above and beyond those excluded by the string class or profile.
プロファイルを使用するアプリケーションプロトコルは、文字列クラスまたはプロファイルによって除外されたものを超えて、そのアプリケーションプロトコル内の関連スロットで許可されていない特定のコードポイントを指定してもよい（MAY）。
That is, an application protocol MAY do either of the following:
つまり、アプリケーションプロトコルは次のいずれかを実行できます。
1. Exclude specific code points that are allowed by the relevant string class.
1. 関連する文字列クラスで許可されている特定のコードポイントを除外します。
2. Exclude code points matching certain Unicode properties (e.g., math symbols) that are included in the relevant PRECIS string class.
2. 関連するPRECIS文字列クラスに含まれている特定のUnicodeプロパティ（数学記号など）に一致するコードポイントを除外します。
As a result of such exclusions, code points that are defined as valid for the PRECIS string class or profile will be defined as disallowed for the relevant protocol slot.
このような除外の結果、PRECIS文字列クラスまたはプロファイルに対して有効であると定義されているコードポイントは、関連するプロトコルスロットでは許可されていないと定義されます。
Typically, such exclusions are defined for the purpose of backward compatibility with legacy formats within an application protocol. These are defined for application protocols, not profiles, in order to prevent multiplication of profiles beyond necessity (see Section 5.1).
通常、このような除外は、アプリケーションプロトコル内のレガシーフォーマットとの下位互換性を目的として定義されます。これらは、必要以上にプロファイルが増加するのを防ぐために、プロファイルではなくアプリケーションプロトコル用に定義されています（セクション5.1を参照）。
Sometimes, an application-layer construct does not map in a straightforward manner to one of the PRECIS string classes or a profile thereof. Consider, for example, the "simple username" construct in SASL [RFC4422]. Depending on the deployment, a simple username might take the form of a user's full name (e.g., the user's personal name followed by a space and then the user's family name). Such a simple username cannot be defined as an instance of the IdentifierClass or a profile thereof, because space code points are not allowed in the IdentifierClass; however, it could be defined using a space-separated sequence of IdentifierClass instances, as in the following ABNF [RFC5234] from [RFC8265]:
場合によっては、アプリケーション層の構造が、PRECIS文字列クラスの1つまたはそのプロファイルに直接マッピングされないことがあります。たとえば、SASL [RFC4422]の「単純なユーザー名」構成を考えてみましょう。デプロイメントによっては、単純なユーザー名はユーザーのフルネーム（たとえば、ユーザーの個人名、スペース、ユーザーの姓）の形式を取る場合があります。 IdentifierClassではスペースコードポイントを使用できないため、このような単純なユーザー名をIdentifierClassまたはそのプロファイルのインスタンスとして定義することはできません。ただし、[RFC8265]の次のABNF [RFC5234]のように、スペースで区切られたIdentifierClassインスタンスのシーケンスを使用して定義できます。
username = userpart *(1*SP userpart)
userpart = 1*(idpoint)
;
; an "idpoint" is a Unicode code point that
; can be contained in a string conforming to
; the PRECIS IdentifierClass
;
Similar techniques could be used to define many application-layer constructs, say of the form "user@domain" or "/path/to/file".
同様の手法を使用して、たとえば「user @ domain」または「/ path / to / file」の形式のように、多くのアプリケーション層構造を定義できます。
To ensure proper comparison, the rules specified for a particular string class or profile MUST be applied in the following order:
適切に比較するには、特定の文字列クラスまたはプロファイルに指定されたルールを次の順序で適用する必要があります。
1. Width Mapping Rule
1. 幅マッピングルール
2. Additional Mapping Rule
2. 追加のマッピングルール
3. Case Mapping Rule
3. ケースマッピングルール
4. Normalization Rule
4. 正規化ルール
5. Directionality Rule
5. 方向性ルール
6. Behavioral rules for determining whether a code point is valid, allowed under a contextual rule, disallowed, or unassigned
6. コードポイントが有効であるか、コンテキストルールで許可されているか、許可されていないか、割り当てられていないかを判断するための動作ルール
As already described, the width mapping, additional mapping, case mapping, normalization, and directionality rules are specified for each profile, whereas the behavioral rules are specified for each string class. Some of the logic behind this order is provided under Section 5.2.1 (see also the PRECIS mappings document [RFC7790]). In addition, this order is consistent with IDNA2008, and with both IDNA2003 and Stringprep before then, for the purpose of enabling code reuse and of ensuring as much continuity as possible with the Stringprep profiles that are obsoleted by several PRECIS profiles.
すでに説明したように、幅のマッピング、追加のマッピング、大文字と小文字のマッピング、正規化、および方向性のルールはプロファイルごとに指定されますが、動作のルールは文字列クラスごとに指定されます。この順序の背後にあるロジックのいくつかは、セクション5.2.1で提供されています（PRECISマッピングドキュメント[RFC7790]も参照）。さらに、この順序は、コードの再利用を可能にし、複数のPRECISプロファイルによって廃止されたStringprepプロファイルとの継続性を可能な限り確保するために、IDNA2008、およびそれ以前のIDNA2003とStringprepの両方と一致しています。
Because of the order of operations specified here, applying the rules for any given PRECIS profile is not necessarily an idempotent procedure (e.g., under certain circumstances, such as when Unicode Normalization Form KC is used, performing Unicode normalization after case mapping can still yield uppercase characters for certain code points). Therefore, an implementation SHOULD apply the rules repeatedly until the output string is stable; if the output string does not stabilize after reapplying the rules three (3) additional times after the first application, the implementation SHOULD terminate application of the rules and reject the input string as invalid.
ここで指定された操作の順序のため、特定のPRECISプロファイルにルールを適用することは必ずしもべき等の手順ではありません（たとえば、Unicode正規化形式KCが使用される場合など、特定の状況下では、大文字と小文字のマッピング後にUnicode正規化を実行しても大文字が生成される特定のコードポイントの文字）。したがって、実装は、出力文字列が安定するまでルールを繰り返し適用する必要があります（SHOULD）。最初の適用からさらに3回ルールを再適用しても出力文字列が安定しない場合、実装はルールの適用を終了し、入力文字列を無効として拒否する必要があります（SHOULD）。
In order to implement the string classes described above, this document does the following: 1. Reviews and classifies the collections of code points in the Unicode coded character set by examining various code point properties.
上記の文字列クラスを実装するために、このドキュメントでは次のことを行います。1.さまざまなコードポイントプロパティを調べて、Unicodeコード化文字セットのコードポイントのコレクションを確認および分類します。
2. Defines an algorithm for determining a derived property value, which can depend on the string class being used by the relevant application protocol.
2. 関連するアプリケーションプロトコルで使用されている文字列クラスに依存する可能性がある派生プロパティ値を決定するためのアルゴリズムを定義します。
This document is not intended to specify precisely how derived property values are to be applied in protocol strings. That information is the responsibility of the protocol specification that uses or profiles a PRECIS string class from this document. The value of the property is to be interpreted as follows.
このドキュメントは、派生プロパティ値がプロトコル文字列にどのように適用されるかを正確に指定することを意図していません。その情報は、このドキュメントのPRECIS文字列クラスを使用またはプロファイルするプロトコル仕様の責任です。プロパティの値は次のように解釈されます。
PROTOCOL VALID Those code points that are allowed to be used in any PRECIS string class (currently, IdentifierClass and FreeformClass). The abbreviated term "PVALID" is used to refer to this value in the remainder of this document.
PROTOCOL VALID PRECIS文字列クラス（現在、IdentifierClassおよびFreeformClass）での使用が許可されているコードポイント。この文書の残りの部分では、この値を指すために「PVALID」という略語が使用されています。
SPECIFIC CLASS PROTOCOL VALID Those code points that are allowed to
be used in specific string classes. In the remainder of this
document, the abbreviated term *_PVAL is used, where * = (ID |
FREE), i.e., either "FREE_PVAL" for the FreeformClass or "ID_PVAL"
for the IdentifierClass. In practice, the derived property
ID_PVAL is not used in this specification, because every ID_PVAL
code point is PVALID.
CONTEXTUAL RULE REQUIRED Some characteristics of the code point, such as its being invisible in certain contexts or problematic in others, require that it not be used in a string unless specific other code points or properties are present in the string. As in IDNA2008, there are two subdivisions of CONTEXTUAL RULE REQUIRED: the first for Join_controls (called "CONTEXTJ") and the second for other code points (called "CONTEXTO"). A string MUST NOT contain any characters whose validity is context-dependent, unless the validity is positively confirmed by a contextual rule. To check this, each code point identified as CONTEXTJ or CONTEXTO in the "PRECIS Derived Property Value" registry (Section 11.1) MUST have a non-null rule. If such a code point is missing a rule, the string is invalid. If the rule exists but the result of applying the rule is negative or inconclusive, the proposed string is invalid. The most notable of the CONTEXTUAL RULE REQUIRED code points are the Join Control code points ZERO WIDTH JOINER (U+200D) and ZERO WIDTH NON-JOINER (U+200C), which have a derived property value of CONTEXTJ. See Appendix A of [RFC5892] for more information.
必要なコンテキストルール特定のコンテキストでは表示されない、他のコンテキストでは問題になるなど、コードポイントの一部の特性では、他の特定のコードポイントまたはプロパティが文字列に存在しない限り、文字列で使用しないようにする必要があります。 IDNA2008と同様に、必要なCONTEXTUAL RULEには2つのサブディビジョンがあります。1つはJoin_controls（ "CONTEXTJ"と呼ばれます）用で、もう1つは他のコードポイント（ "CONTEXTO"と呼ばれます）用です。文字列には、有効性がコンテキストルールによって明確に確認されない限り、有効性がコンテキスト依存である文字を含めてはなりません（MUST NOT）。これを確認するには、 "PRECIS Derived Property Value"レジストリ（セクション11.1）でCONTEXTJまたはCONTEXTOとして識別されている各コードポイントにnull以外のルールが必要です。そのようなコードポイントにルールがない場合、文字列は無効です。ルールは存在するが、ルールの適用結果が否定的または決定的でない場合、提案された文字列は無効です。 CONTEXTUAL RULE REQUIREDコードポイントの中で最も注目に値するのは、結合制御コードポイントのZERO WIDTH JOINER（U + 200D）およびZERO WIDTH NON-JOINER（U + 200C）で、CONTEXTJの派生プロパティ値があります。詳細については、[RFC5892]の付録Aをご覧ください。
DISALLOWED Those code points that are not permitted in any PRECIS string class.
DISALLOWED PRECIS文字列クラスで許可されていないコードポイント。
SPECIFIC CLASS DISALLOWED Those code points that are not to be
included in one of the string classes but that might be permitted
in others. In the remainder of this document, the abbreviated
term *_DIS is used, where * = (ID | FREE), i.e., either "FREE_DIS"
for the FreeformClass or "ID_DIS" for the IdentifierClass. In
practice, the derived property FREE_DIS is not used in this
specification, because every FREE_DIS code point is DISALLOWED.
UNASSIGNED Those code points that are not designated (i.e., are unassigned) in the Unicode Standard.
UNASSIGNED Unicode標準で指定されていない（つまり、割り当てられていない）コードポイント。
The algorithm to calculate the value of the derived property is as follows (implementations MUST NOT modify the order of operations within this algorithm, because doing so would cause inconsistent results across implementations):
派生プロパティの値を計算するアルゴリズムは次のとおりです（実装すると、このアルゴリズム内の操作の順序を変更してはなりません。変更すると、実装間で結果に一貫性がなくなります）。
If .cp. .in. Exceptions Then Exceptions(cp);
Else If .cp. .in. BackwardCompatible Then BackwardCompatible(cp);
Else If .cp. .in. Unassigned Then UNASSIGNED;
Else If .cp. .in. ASCII7 Then PVALID;
Else If .cp. .in. JoinControl Then CONTEXTJ;
Else If .cp. .in. OldHangulJamo Then DISALLOWED;
Else If .cp. .in. PrecisIgnorableProperties Then DISALLOWED;
Else If .cp. .in. Controls Then DISALLOWED;
Else If .cp. .in. HasCompat Then ID_DIS or FREE_PVAL;
Else If .cp. .in. LetterDigits Then PVALID;
Else If .cp. .in. OtherLetterDigits Then ID_DIS or FREE_PVAL;
Else If .cp. .in. Spaces Then ID_DIS or FREE_PVAL;
Else If .cp. .in. Symbols Then ID_DIS or FREE_PVAL;
Else If .cp. .in. Punctuation Then ID_DIS or FREE_PVAL;
Else DISALLOWED;
The value of the derived property calculated can depend on the string class; for example, if an identifier used in an application protocol is defined as profiling the PRECIS IdentifierClass then a space character such as SPACE (U+0020) would be assigned to ID_DIS, whereas if an identifier is defined as profiling the PRECIS FreeformClass then the character would be assigned to FREE_PVAL. For the sake of brevity, the designation "FREE_PVAL" is used herein, instead of the longer designation "ID_DIS or FREE_PVAL". In practice, the derived properties ID_PVAL and FREE_DIS are not used in this specification, because every ID_PVAL code point is PVALID and every FREE_DIS code point is DISALLOWED.
計算された派生プロパティの値は、文字列クラスによって異なります。たとえば、アプリケーションプロトコルで使用される識別子がPRECIS IdentifierClassのプロファイリングとして定義されている場合、SPACE（U + 0020）などのスペース文字がID_DISに割り当てられますが、識別子がPRECIS FreeformClassのプロファイリングとして定義されている場合、文字FREE_PVALに割り当てられます。簡潔にするために、ここでは、「ID_DISまたはFREE_PVAL」という長い表記の代わりに、「FREE_PVAL」という表記を使用します。すべてのID_PVALコードポイントはPVALIDであり、すべてのFREE_DISコードポイントはDISALLOWEDであるため、実際には、派生プロパティID_PVALおよびFREE_DISはこの仕様では使用されません。
Use of the name of a rule (such as "Exceptions") implies the set of code points that the rule defines, whereas the same name as a function call (such as "Exceptions(cp)") implies the value that the code point has in the Exceptions table.
ルールの名前（「例外」など）の使用は、ルールが定義するコードポイントのセットを意味しますが、関数呼び出しと同じ名前（「例外（cp）」など）は、コードポイントが示す値を意味します例外テーブルにあります。
The mechanisms described here allow determination of the value of the property for future versions of Unicode (including code points added after Unicode 5.2 or 7.0, depending on the category, because some categories mentioned in this document are simply pointers to IDNA2008 and therefore were defined at the time of Unicode 5.2). Changes in Unicode properties that do not affect the outcome of this process therefore do not affect this framework. For example, a code point can have its Unicode General_Category value change from So to Sm, or from Lo to Ll, without affecting the algorithm results. Moreover, even if such changes were to result, the BackwardCompatible list (Section 9.7) can be adjusted to ensure the stability of the results.
ここで説明するメカニズムにより、Unicodeの将来のバージョン（カテゴリに応じて、Unicode 5.2または7.0の後に追加されたコードポイントを含む）のプロパティの値を決定できます。 Unicode 5.2の時代）。したがって、このプロセスの結果に影響しないUnicodeプロパティの変更は、このフレームワークには影響しません。たとえば、コードポイントでは、アルゴリズムの結果に影響を与えることなく、Unicode General_Categoryの値をSoからSmに、またはLoからLlに変更できます。さらに、このような変更が発生した場合でも、BackwardCompatibleリスト（セクション9.7）を調整して、結果の安定性を確保できます。
The derived property obtains its value based on a two-step procedure:
派生プロパティは、2段階の手順に基づいてその値を取得します。
1. Code points are placed in one or more character categories either (1) based on core properties defined by the Unicode Standard or (2) by treating the code point as an exception and addressing the code point based on its code point value. These categories are not mutually exclusive.
1. コードポイントは、（1）Unicode標準で定義されたコアプロパティに基づいて、または（2）コードポイントを例外として扱い、そのコードポイント値に基づいてコードポイントをアドレス指定することにより、1つ以上の文字カテゴリに配置されます。これらのカテゴリは相互に排他的ではありません。
2. Set operations are used with these categories to determine the values for a property specific to a given string class. These operations are specified under Section 8.
2. セット操作はこれらのカテゴリで使用され、特定の文字列クラスに固有のプロパティの値を決定します。これらの操作はセクション8で指定されています。
Note: Unicode property names and property value names might have short abbreviations, such as "gc" for the General_Category property and "Ll" for the Lowercase_Letter property value of the gc property.
注：Unicodeのプロパティ名とプロパティ値の名前には、General_Categoryプロパティの「gc」や、gcプロパティのLowercase_Letterプロパティ値の「Ll」などの短い省略形がある場合があります。
In the following specification of character categories, the operation that returns the value of a particular Unicode code point property for a code point is designated by using the formal name of that property (from the Unicode PropertyAliases.txt file [PropertyAliases] followed by "(cp)" for "code point". For example, the value of the General_Category property for a code point is indicated by General_Category(cp).
次の文字カテゴリの仕様では、コードポイントの特定のUnicodeコードポイントプロパティの値を返す操作は、そのプロパティの正式な名前（Unicode PropertyAliases.txtファイル[PropertyAliases]の後に "（ cp） "for" code point "。たとえば、コードポイントのGeneral_Categoryプロパティの値はGeneral_Category（cp）で示されます。
The first ten categories (A-J) shown below were previously defined for IDNA2008 and are referenced from [RFC5892] to ease the understanding of how PRECIS handles various code points. Some of these categories are reused in PRECIS, and some of them are not;
以下に示す最初の10個のカテゴリ（A〜J）は、以前IDNA2008に対して定義されたものであり、PRECISがさまざまなコードポイントを処理する方法を理解しやすくするために[RFC5892]から参照されています。これらのカテゴリの一部はPRECISで再利用され、一部は再利用されません。
however, the lettering of categories is retained to prevent overlap and to ease implementation of both IDNA2008 and PRECIS in a single software application. The next eight categories (K-R) are specific to PRECIS.
ただし、カテゴリのレタリングは、重複を防ぎ、単一のソフトウェアアプリケーションでIDNA2008とPRECISの両方の実装を容易にするために保持されています。次の8つのカテゴリ（K-R）はPRECISに固有です。
This category is defined in Section 2.1 of [RFC5892] and is included by reference for use in PRECIS.
このカテゴリは[RFC5892]のセクション2.1で定義されており、PRECISで使用するために参照として含まれています。
This category is defined in Section 2.2 of [RFC5892]. However, it is not used in PRECIS.
このカテゴリは、[RFC5892]のセクション2.2で定義されています。ただし、PRECISでは使用されません。
This category is defined in Section 2.3 of [RFC5892]. However, it is not used in PRECIS.
このカテゴリは、[RFC5892]のセクション2.3で定義されています。ただし、PRECISでは使用されません。
Note: See the PrecisIgnorableProperties ("M") category below for a more inclusive category used in PRECIS identifiers.
注：PRECIS識別子で使用されるより包括的なカテゴリについては、以下のPrecisIgnorableProperties（ "M"）カテゴリを参照してください。
This category is defined in Section 2.4 of [RFC5892]. However, it is not used in PRECIS.
このカテゴリは、[RFC5892]のセクション2.4で定義されています。ただし、PRECISでは使用されません。
This category is defined in Section 2.5 of [RFC5892]. However, it is not used in PRECIS.
このカテゴリは、[RFC5892]のセクション2.5で定義されています。ただし、PRECISでは使用されません。
Note: See the ASCII7 ("K") category below for a more inclusive category used in PRECIS identifiers.
注：PRECIS識別子で使用されるより包括的なカテゴリについては、以下のASCII7（ "K"）カテゴリを参照してください。
This category is defined in Section 2.6 of [RFC5892] and is included by reference for use in PRECIS.
このカテゴリは[RFC5892]のセクション2.6で定義されており、PRECISで使用するために参照として含まれています。
This category is defined in Section 2.7 of [RFC5892] and is included by reference for use in PRECIS.
このカテゴリは[RFC5892]のセクション2.7で定義されており、PRECISで使用するために参照として含まれています。
Note: Management of this category is handled via the processes specified in [RFC5892]. At the time of this writing (and also at the time that RFC 5892 was published), this category consisted of the empty set; however, that is subject to change as described in RFC 5892.
注：このカテゴリの管理は、[RFC5892]で指定されたプロセスを介して処理されます。この記事の執筆時点（およびRFC 5892が公開された時点）では、このカテゴリは空のセットで構成されていました。ただし、RFC 5892で説明されているように、変更される可能性があります。
This category is defined in Section 2.8 of [RFC5892] and is included by reference for use in PRECIS.
このカテゴリは[RFC5892]のセクション2.8で定義されており、PRECISで使用するために参照として含まれています。
Note: In particular, the code points ZERO WIDTH JOINER (U+200D) and ZERO WIDTH NON-JOINER (U+200C) are necessary to produce certain combinations of characters in certain scripts (e.g., Arabic, Persian, and Indic scripts), but if used in other contexts, they can have consequences that violate the "Principle of Least Astonishment". Therefore, these code points are allowed only in contexts where they are appropriate, specifically where the relevant rule (CONTEXTJ or CONTEXTO) has been defined. See [RFC5892] and [RFC5894] for further discussion.
注：特に、特定のスクリプト（アラビア語、ペルシャ語、インド語のスクリプトなど）で特定の文字の組み合わせを生成するには、コードポイントZERO WIDTH JOINER（U + 200D）およびZERO WIDTH NON-JOINER（U + 200C）が必要です。しかし、他の状況で使用された場合、「最小驚きの原則」に違反する結果をもたらす可能性があります。したがって、これらのコードポイントは、適切なコンテキスト、特に関連するルール（CONTEXTJまたはCONTEXTO）が定義されているコンテキストでのみ許可されます。詳細については、[RFC5892]と[RFC5894]を参照してください。
This category is defined in Section 2.9 of [RFC5892] and is included by reference for use in PRECIS.
このカテゴリは[RFC5892]のセクション2.9で定義されており、PRECISで使用するために参照として含まれています。
Note: Exclusion of these code points results in disallowing certain archaic Korean syllables and in restricting supported Korean syllables to preformed, modern Hangul characters.
注：これらのコードポイントを除外すると、特定の古い韓国語の音節が禁止され、サポートされている韓国語の音節が、事前に作成された現代のハングル文字に制限されます。
This category is defined in Section 2.10 of [RFC5892] and is included by reference for use in PRECIS.
このカテゴリは[RFC5892]のセクション2.10で定義されており、PRECISで使用するために参照として含まれています。
This PRECIS-specific category consists of all printable, non-space code points from the 7-bit ASCII range. By applying this category, the algorithm specified under Section 8 exempts these code points from other rules that might be applied during PRECIS processing, on the assumption that these code points are in such wide use that disallowing them would be counterproductive.
このPRECIS固有のカテゴリは、7ビットのASCII範囲のすべての印刷可能な非スペースコードポイントで構成されています。このカテゴリを適用することにより、セクション8で指定されたアルゴリズムは、PRECIS処理中に適用される可能性のある他のルールからこれらのコードポイントを除外します。
K: cp is in {0021..007E}
This PRECIS-specific category consists of all control code points, such as LINE FEED (U+000A).
このPRECIS固有のカテゴリは、LINE FEED（U + 000A）などのすべての制御コードポイントで構成されています。
L: Control(cp) = True
This PRECIS-specific category is used to group code points that are discouraged from use in PRECIS string classes.
このPRECIS固有のカテゴリは、PRECIS文字列クラスでの使用が推奨されないコードポイントをグループ化するために使用されます。
M: Default_Ignorable_Code_Point(cp) = True or
Noncharacter_Code_Point(cp) = True
The definition for Default_Ignorable_Code_Point can be found in the DerivedCoreProperties.txt file [DerivedCoreProperties].
Default_Ignorable_Code_Pointの定義は、DerivedCoreProperties.txtファイル[DerivedCoreProperties]にあります。
Note: In general, these code points are constructs such as so-called "soft hyphens", certain joining code points, various specialized code points for use within Unicode itself (e.g., language tags and variation selectors), and so on. Disallowing these code points in PRECIS reduces the potential for unexpected results in the use of internationalized strings.
注：一般に、これらのコードポイントは、いわゆる「ソフトハイフン」、特定の結合コードポイント、Unicode自体で使用するためのさまざまな特殊コードポイント（言語タグやバリエーションセレクターなど）などの構成要素です。 PRECISでこれらのコードポイントを禁止すると、国際化された文字列の使用で予期しない結果が生じる可能性が低くなります。
This PRECIS-specific category is used to group code points that are spaces.
このPRECIS固有のカテゴリは、スペースであるコードポイントをグループ化するために使用されます。
N: General_Category(cp) is in {Zs}
This PRECIS-specific category is used to group code points that are symbols.
このPRECIS固有のカテゴリは、シンボルであるコードポイントをグループ化するために使用されます。
O: General_Category(cp) is in {Sm, Sc, Sk, So}
This PRECIS-specific category is used to group code points that are punctuation.
このPRECIS固有のカテゴリは、句読点であるコードポイントをグループ化するために使用されます。
P: General_Category(cp) is in {Pc, Pd, Ps, Pe, Pi, Pf, Po}
This PRECIS-specific category is used to group any code point that is decomposed and recomposed into something other than itself under Unicode Normalization Form KC.
このPRECIS固有のカテゴリーは、Unicode正規化フォームKCの下で分解され、それ自体以外のものに再構成されるコードポイントをグループ化するために使用されます。
Q: toNFKC(cp) != cp
Typically, this category is true of code points that are "compatibility decomposable characters" as defined in the Unicode Standard.
通常、このカテゴリは、Unicode規格で定義されている「互換性分解可能文字」であるコードポイントに当てはまります。
The toNFKC() operation returns the code point in Normalization Form KC. For more information, see Unicode Standard Annex #15 [UAX15].
toNFKC()オペレーションは、正規化形式KCでコードポイントを返します。詳細については、Unicode Standard Annex＃15 [UAX15]を参照してください。
This PRECIS-specific category is used to group code points that are letters and digits other than the "traditional" letters and digits grouped under the LetterDigits ("A") category (see Section 9.1).
このPRECIS固有のカテゴリは、「従来の」文字と数字以外の文字と数字であるコードポイントを、LetterDigits（ "A"）カテゴリにグループ化するために使用されます（セクション9.1を参照）。
R: General_Category(cp) is in {Lt, Nl, No, Me}
Experience with internationalization in application protocols has shown that protocol designers and application developers usually do not understand the subtleties and trade-offs involved with internationalization and that they need considerable guidance in making reasonable decisions with regard to the options before them.
アプリケーションプロトコルの国際化の経験から、プロトコル設計者とアプリケーション開発者は通常、国際化に伴う微妙さとトレードオフを理解しておらず、それらの前のオプションに関して合理的な決定を行うにはかなりのガイダンスが必要であることがわかっています。
Therefore:
したがって：
o Protocol designers are strongly encouraged to question the assumption that they need to define new profiles, because existing profiles are designed for wide reuse (see Section 5 for further discussion).
o 既存のプロファイルは広く再利用できるように設計されているため、プロトコル設計者は、新しいプロファイルを定義する必要があるという仮定に疑問を呈することを強くお勧めします（詳細については、セクション5を参照）。
o Those who persist in defining new profiles are strongly encouraged to clearly explain a strong justification for doing so and to publish a stable specification that provides all of the information described under Section 11.3.
o 新しいプロファイルの定義に固執する人は、そうすることの正当な理由を明確に説明し、セクション11.3で説明されているすべての情報を提供する安定した仕様を公開することを強くお勧めします。
o The designated experts for profile registration requests ought to seek answers to all of the questions provided under Section 11.3 and ought to encourage applicants to provide a stable specification documenting the profile (even though the registration policy for PRECIS profiles is "Expert Review" and a stable specification is not strictly required).
oプロファイル登録リクエストに指定されたエキスパートは、セクション11.3で提供されるすべての質問に対する回答を求め、プロファイルを文書化した安定した仕様を提供するよう申請者に奨励する必要があります（PRECISプロファイルの登録ポリシーは「エキスパートレビュー」であり、安定した仕様は厳密には必要ありません）。
o Developers of applications that use PRECIS are strongly encouraged to apply the guidelines provided under Section 6 and to seek out the advice of the designated experts or other knowledgeable individuals in doing so.
o PRECISを使用するアプリケーションの開発者は、セクション6で提供されるガイドラインを適用し、指定された専門家またはその他の知識のある個人の助言を求めることを強くお勧めします。
o All parties are strongly encouraged to help prevent the multiplication of profiles beyond necessity, as described under Section 5.1, and to use PRECIS in ways that will minimize user confusion and insecure application behavior.
o すべての関係者は、セクション5.1で説明されているように、必要以上にプロファイルが増加するのを防ぎ、ユーザーの混乱と安全でないアプリケーションの動作を最小限に抑える方法でPRECISを使用することを強くお勧めします。
Internationalization can be difficult and contentious; designated experts, profile registrants, and application developers are strongly encouraged to work together in a spirit of good faith and mutual understanding to achieve rough consensus on profile registration requests and the use of PRECIS in particular applications. They are also encouraged to bring additional expertise into the discussion if that would be helpful in adding perspective or otherwise resolving issues.
国際化は困難で論争になりがちです。指定された専門家、プロファイル登録者、およびアプリケーション開発者は、プロファイル登録要求と特定のアプリケーションでのPRECISの使用について大まかなコンセンサスを達成するために、誠意と相互理解の精神で協力することを強くお勧めします。また、パースペクティブの追加や問題の解決に役立つ場合は、ディスカッションに専門知識を追加することをお勧めします。
IANA has created and now maintains the "PRECIS Derived Property Value" registry (<https://www.iana.org/assignments/precis-tables/>), which records the derived properties for each version of Unicode released starting from version 6.3. The derived property value is to be calculated in cooperation with a designated expert [RFC8126] according to the rules specified under Sections 8 and 9.
IANAは、「PRECIS Derived Property Value」レジストリ（<https://www.iana.org/assignments/precis-tables/>）を作成し、維持しています。これは、バージョン6.3からリリースされたUnicodeの各バージョンの派生プロパティを記録します。派生プロパティ値は、セクション8および9で指定されたルールに従って、指定された専門家[RFC8126]と協力して計算されます。
The IESG is to be notified if backward-incompatible changes to the table of derived properties are discovered or if other problems arise during the process of creating the table of derived property values or during Expert Review. Changes to the rules defined under Sections 8 and 9 require IETF Review.
IESGは、派生プロパティのテーブルに対する下位互換性のない変更が発見された場合、または派生プロパティ値のテーブルの作成プロセス中またはエキスパートレビュー中に他の問題が発生した場合に通知されます。セクション8および9で定義されたルールの変更には、IETFレビューが必要です。
Note: IANA is requested to not make further updates to this registry until it receives notice from the IESG that the issues described in [IAB-Statement] and Section 13.5 of this document have been settled.
注：IANAは、このドキュメントの[IAB-Statement]とセクション13.5で説明されている問題が解決したことをIESGから通知を受けるまで、このレジストリをさらに更新しないように要求されます。
IANA has created the "PRECIS Base Classes" registry (<https://www.iana.org/assignments/precis-parameters/>). In accordance with [RFC8126], the registration policy is "RFC Required".
IANAは「PRECIS Base Classes」レジストリ（<https://www.iana.org/assignments/precis-parameters/>）を作成しました。 [RFC8126]に従い、登録ポリシーは「RFC必須」です。
The registration template is as follows:
登録テンプレートは次のとおりです。
Base Class: [the name of the PRECIS string class]
基本クラス：[PRECIS文字列クラスの名前]
Description: [a brief description of the PRECIS string class and its intended use, e.g., "A sequence of letters, numbers, and symbols that is used to identify or address a network entity."]
説明：[PRECIS文字列クラスとその使用目的の簡単な説明。たとえば、「ネットワークエンティティの識別またはアドレス指定に使用される文字、数字、および記号のシーケンス」]
Reference: [the RFC number]
参照：[RFC番号]
The initial registrations are as follows:
初期登録は次のとおりです。
Base Class: FreeformClass Description: A sequence of letters, numbers, symbols, spaces, and other code points that is used for free-form strings. Specification: Section 4.3 of RFC 8264
基本クラス：FreeformClass説明：自由形式の文字列に使用される文字、数字、記号、スペース、およびその他のコードポイントのシーケンス。仕様：RFC 8264のセクション4.3
Base Class: IdentifierClass Description: A sequence of letters, numbers, and symbols that is used to identify or address a network entity. Specification: Section 4.2 of RFC 8264
基本クラス：IdentifierClass説明：ネットワークエンティティの識別またはアドレス指定に使用される文字、数字、および記号のシーケンス。仕様：RFC 8264のセクション4.2
IANA has created the "PRECIS Profiles" registry (<https://www.iana.org/assignments/precis-parameters/>) to identify profiles that use the PRECIS string classes. In accordance with [RFC8126], the registration policy is "Expert Review". This policy was chosen in order to ease the burden of registration while ensuring that "customers" of PRECIS receive appropriate guidance regarding the sometimes complex and subtle internationalization issues related to profiles of PRECIS string classes.
IANAは、PRECIS文字列クラスを使用するプロファイルを識別するために、「PRECISプロファイル」レジストリ（<https://www.iana.org/assignments/precis-parameters/>）を作成しました。 [RFC8126]に従い、登録ポリシーは「エキスパートレビュー」です。このポリシーは、PRECISの「お客様」がPRECIS文字列クラスのプロファイルに関連する複雑で微妙な国際化の問題に関する適切なガイダンスを受け取ることを保証しながら、登録の負担を軽減するために選択されました。
The registration template is as follows:
登録テンプレートは次のとおりです。
Name: [the name of the profile]
名前：[プロファイルの名前]
Base Class: [which PRECIS string class is being profiled]
基本クラス：[どのPRECIS文字列クラスがプロファイルされているか]
Applicability: [the specific protocol elements to which this profile applies, e.g., "Usernames in security and application protocols."]
適用範囲：[このプロファイルが適用される特定のプロトコル要素、たとえば「セキュリティおよびアプリケーションプロトコルのユーザー名」]
Replaces: [the Stringprep profile that this PRECIS profile replaces, if any]
Replaces：[存在する場合、このPRECISプロファイルが置き換えるStringprepプロファイル]
Width Mapping Rule: [the behavioral rule for handling of width, e.g., "Map fullwidth and halfwidth code points to their compatibility variants."]
幅マッピングルール：[幅を処理するための動作ルール。たとえば、「全幅と半幅のコードポイントを互換バリアントにマップします。」]
Additional Mapping Rule: [any additional mappings that are required or recommended, e.g., "Map non-ASCII space code points to SPACE (U+0020)."]
追加のマッピングルール：[必要な、または推奨される追加のマッピング。たとえば、「非ASCIIスペースコードポイントをSPACE（U + 0020）にマップします。」]
Case Mapping Rule: [the behavioral rule for handling of case, e.g., "Apply the Unicode toLowerCase() operation."]
ケースマッピングルール：[ケースを処理するための動作ルール。たとえば、「UnicodeのtoLowerCase()操作を適用します。」]
Normalization Rule: [which Unicode normalization form is applied, e.g., "NFC"]
正規化ルール：[適用されるUnicode正規化形式、たとえば「NFC」]
Directionality Rule: [the behavioral rule for handling of right-to-left code points, e.g., "The 'Bidi Rule' defined in RFC 5893 applies."]
方向性ルール：[右から左へのコードポイントを処理するための動作ルール。たとえば、「RFC 5893で定義されている「Bidiルール」が適用されます。」
Enforcement: [which entities enforce the rules, and when that enforcement occurs during protocol operations]
実施：[どのエンティティがルールを実施するか、およびその実施がプロトコル操作中にいつ発生するか]
Specification: [a pointer to relevant documentation, such as an RFC or Internet-Draft]
仕様：[RFCやInternet-Draftなどの関連ドキュメントへのポインタ]
In order to request a review, the registrant shall send a completed template to the <precis@ietf.org> list or its designated successor.
レビューを要求するために、登録者は完成したテンプレートを<precis@ietf.org>リストまたはその指定された後継者に送信するものとします。
Factors to focus on while defining profiles and reviewing profile registrations include the following:
プロファイルを定義し、プロファイル登録を確認する際に注意すべき要素には、次のものがあります。
o Would an existing PRECIS string class or profile solve the problem? If not, why not? (See Section 5.1 for related considerations.)
o 既存のPRECIS文字列クラスまたはプロファイルで問題が解決しますか？そうでない場合、なぜそうではないのですか？ （関連する考慮事項については、セクション5.1を参照してください。）
o Is the problem being addressed by this profile well defined?
o このプロファイルで対処されている問題は明確に定義されていますか？
o Does the specification define what kinds of applications are involved and the protocol elements to which this profile applies?
o 仕様には、関連するアプリケーションの種類と、このプロファイルが適用されるプロトコル要素が定義されていますか？
o Is the profile clearly defined?
o プロファイルは明確に定義されていますか？
o Is the profile based on an appropriate dividing line between user interface (culture, context, intent, locale, device limitations, etc.) and the use of conformant strings in protocol elements?
o プロファイルは、ユーザーインターフェイス（カルチャ、コンテキスト、インテント、ロケール、デバイス制限など）とプロトコル要素での適合文字列の使用の間の適切な境界線に基づいていますか？
o Are the width mapping, case mapping, additional mapping, normalization, and directionality rules appropriate for the intended use?
o 幅のマッピング、大文字と小文字のマッピング、追加のマッピング、正規化、および方向性のルールは、使用目的に適していますか？
o Does the profile explain which entities enforce the rules and when such enforcement occurs during protocol operations?
o プロファイルは、どのエンティティがルールを実施するか、およびそのような実施がプロトコル操作中にいつ発生するかを説明していますか？
o Does the profile reduce the degree to which human users could be surprised or confused by application behavior (the "Principle of Least Astonishment")?
o プロファイルは、人間のユーザーがアプリケーションの動作に驚いたり混乱したりする度合いを減らしますか（「最小驚きの原則」）。
o Does the profile introduce any new security concerns such as those described under Section 12 of this document (e.g., false accepts for authentication or authorization)?
o このプロファイルは、このドキュメントのセクション12で説明されているような新しいセキュリティ上の懸念をもたらしますか（たとえば、認証または承認の誤った受け入れ）？
If input strings that appear "the same" to users are programmatically considered to be distinct in different systems or if input strings that appear distinct to users are programmatically considered to be "the same" in different systems, then users can be confused. Such confusion can have security implications, such as the false accepts and false rejects discussed in [RFC6943] (the terms "false positives" and "false negatives" are used in that document). One starting goal of work on the PRECIS framework was to limit the number of times that users are confused (consistent with the "Principle of Least Astonishment"). Unfortunately, this goal has been difficult to achieve given the large number of application protocols already in existence. Despite these difficulties, profiles should not be multiplied beyond necessity (see Section 5.1). In particular, designers of application protocols should think long and hard before defining a new profile instead of using one that has already been defined, and if they decide to define a new profile then they should clearly explain their reasons for doing so.
ユーザーに「同じ」と思われる入力文字列がプログラムによって異なるシステムで異なると見なされる場合、またはユーザーに区別されると思われる入力文字列がプログラムで異なるシステムで「同じ」と見なされる場合、ユーザーは混乱する可能性があります。そのような混乱は、[RFC6943]で説明されている誤った受け入れや誤った拒否など、セキュリティに影響を与える可能性があります（このドキュメントでは、「偽陽性」と「偽陰性」という用語が使用されています）。 PRECISフレームワークに関する作業の最初の目標の1つは、ユーザーが混乱する回数を制限することでした（「最小驚きの原則」と一致しています）。残念ながら、すでに存在する多数のアプリケーションプロトコルを考えると、この目標を達成することは困難でした。これらの困難にもかかわらず、プロファイルは必要以上に乗算されるべきではありません（セクション5.1を参照）。特に、アプリケーションプロトコルの設計者は、既に定義されているプロファイルを使用するのではなく、新しいプロファイルを定義する前に十分に検討する必要があります。新しいプロファイルを定義する場合は、その理由を明確に説明する必要があります。
The security of applications that use this framework can depend in part on the proper preparation, enforcement, and comparison of internationalized strings. For example, such strings can be used to make authentication and authorization decisions, and the security of an application could be compromised if an entity providing a given string is connected to the wrong account or online resource based on different interpretations of the string (again, see [RFC6943]).
このフレームワークを使用するアプリケーションのセキュリティは、国際化された文字列の適切な準備、適用、および比較に一部依存する場合があります。たとえば、そのような文字列は認証と承認の決定に使用でき、特定の文字列を提供するエンティティが文字列の異なる解釈に基づいて間違ったアカウントまたはオンラインリソースに接続されている場合、アプリケーションのセキュリティが侵害される可能性があります（ここでも、 [RFC6943]を参照してください）。
Specifications of application protocols that use this framework are strongly encouraged to describe how internationalized strings are used in the protocol, including the security implications of any false accepts and false rejects that might result from various enforcement and comparison operations. For some helpful guidelines, refer to [RFC6943], [RFC5890], [UTR36], and [UTS39].
このフレームワークを使用するアプリケーションプロトコルの仕様では、プロトコルで国際化された文字列がどのように使用されるかを説明することを強くお勧めします。いくつかの役立つガイドラインについては、[RFC6943]、[RFC5890]、[UTR36]、および[UTS39]を参照してください。
Strings that conform to the IdentifierClass, and any profile thereof, are intended to be relatively safe for use in a broad range of applications, primarily because they include only letters, digits, and "grandfathered" non-space code points from the ASCII range; thus, they exclude spaces, code points with compatibility equivalents, and almost all symbols and punctuation marks. However, because such strings can still include so-called "confusable code points" (see Section 12.5), protocol designers and implementers are encouraged to pay close attention to the security considerations described elsewhere in this document.
IdentifierClassとそのプロファイルに準拠する文字列は、主に文字、数字、ASCII範囲の「祖先」の非スペースコードポイントのみが含まれるため、幅広いアプリケーションでの使用が比較的安全であることが意図されています。したがって、スペース、互換性のある同等のコードポイント、およびほとんどすべての記号と句読点は除外されます。ただし、そのような文字列には、いわゆる「混乱しやすいコードポイント」（セクション12.5を参照）を含めることができるため、プロトコル設計者および実装者は、このドキュメントの他の場所で説明されているセキュリティに関する考慮事項に細心の注意を払うことをお勧めします。
Strings that conform to the FreeformClass, and many profiles thereof, can include virtually any Unicode code point. This makes the FreeformClass quite expressive, but also problematic from the perspective of possible user confusion. Protocol designers are hereby warned that the FreeformClass contains code points they might not understand, and they are encouraged to profile the IdentifierClass wherever feasible; however, if an application protocol requires more code points than are allowed by the IdentifierClass, protocol designers are encouraged to define a profile of the FreeformClass that restricts the allowable code points as tightly as possible. (The PRECIS Working Group considered the option of allowing "superclasses" as well as profiles of PRECIS string classes but decided against allowing superclasses to reduce the likelihood of security and interoperability problems.)
FreeformClassおよびその多くのプロファイルに準拠する文字列には、事実上すべてのUnicodeコードポイントを含めることができます。これにより、FreeformClassは非常に表現力豊かになりますが、ユーザーの混乱の可能性の観点からも問題が生じます。プロトコル設計者は、FreeformClassに理解できないコードポイントが含まれていることを警告し、可能な限りIdentifierClassをプロファイルすることをお勧めします。ただし、アプリケーションプロトコルがIdentifierClassで許可されているよりも多くのコードポイントを必要とする場合、プロトコル設計者は、許可されるコードポイントをできるだけ厳しく制限するFreeformClassのプロファイルを定義することをお勧めします。 （PRECISワーキンググループは、「スーパークラス」とPRECIS文字列クラスのプロファイルを許可するオプションを検討しましたが、スーパークラスがセキュリティと相互運用性の問題の可能性を減らすことを許可しないことにしました。）
When systems use local character sets other than ASCII and Unicode, this specification leaves the problem of converting between the local character set and Unicode up to the application or local system. If different applications (or different versions of one application) implement different rules for conversions among coded character sets, they could interpret the same name differently and contact different application servers or other network entities. This problem is not solved by security protocols, such as Transport Layer Security (TLS) [RFC5246] and SASL [RFC4422], that do not take local character sets into account.
システムがASCIIおよびUnicode以外のローカル文字セットを使用する場合、この仕様では、ローカル文字セットとUnicode間の変換の問題がアプリケーションまたはローカルシステムに残ります。異なるアプリケーション（または1つのアプリケーションの異なるバージョン）がコード化文字セット間の変換に関する異なるルールを実装する場合、それらは同じ名前を異なる方法で解釈し、異なるアプリケーションサーバーまたは他のネットワークエンティティに接続する可能性があります。この問題は、トランスポート層セキュリティ（TLS）[RFC5246]やSASL [RFC4422]などのローカル文字セットを考慮しないセキュリティプロトコルでは解決されません。
Some code points are visually similar and thus can cause confusion among humans. Such characters are often called "confusable characters" or "confusables".
一部のコードポイントは視覚的に類似しているため、人間の間で混乱を引き起こす可能性があります。このような文字は、「混乱しやすい文字」または「混乱しやすい文字」と呼ばれることがよくあります。
The problem of confusable characters is not necessarily caused by the use of Unicode code points outside the ASCII range. For example, in some presentations and to some individuals the string "ju1iet" (spelled with DIGIT ONE (U+0031) as the third character) might appear to be the same as "juliet" (spelled with LATIN SMALL LETTER L (U+006C)), especially on casual visual inspection. This phenomenon is sometimes called "typejacking".
混乱しやすい文字の問題は、ASCII範囲外のUnicodeコードポイントの使用が原因であるとは限りません。たとえば、プレゼンテーションや個人によっては、文字列「ju1iet」（3番目の文字としてDIGIT ONE（U + 0031）が付いている）は「juliet」（ラテン小文字L（U +が付いている）と同じように見えるかもしれません。 006C））、特にカジュアルな目視検査。この現象は「タイプジャッキング」と呼ばれることもあります。
However, the problem is made more serious by introducing the full range of Unicode code points into protocol strings. A well-known example is confusion between "а" CYRILLIC SMALL LETTER A (U+0430) and "a" LATIN SMALL LETTER A (U+0061). As another example, the characters "ᏚᎢᎵᏋᎢᏋᏒ" (U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2) from the Cherokee block look similar to the ASCII code points representing "STPETER" as they might appear when presented using a "creative" font family. Confusion among such characters is perhaps not unexpected, given that the alphabetic writing systems involved all bear a family resemblance or historical lineage. Perhaps more surprising is confusion among characters from disparate writing systems, such as "O" (LATIN CAPITAL LETTER O, U+004F), "0" (DIGIT ZERO, U+0030), "໐" (LAO DIGIT ZERO, U+0ED0), "ዐ" (ETHIOPIC SYLLABLE PHARYNGEAL A, U+12D0), and other graphemes that have the appearance of open circles. And the reader needs to be aware that the foregoing represent merely a small sample of characters that are confusable in Unicode.
ただし、プロトコル文字列にすべてのUnicodeコードポイントを導入することで、問題はさらに深刻になります。よく知られている例は、「а」キリル小文字A（U + 0430）と「a」ラテン小文字A（U + 0061）の混同です。別の例として、チェロキーブロックの文字「ᏚᎢᎵᏋᎢᏋᏒ」（U + 13DA U + 13A2 U + 13B5 U + 13AC U + 13A2 U + 13AC U + 13D2）は、「STPETER」を表すASCIIコードポイントに似ています。 「クリエイティブ」フォントファミリーを使用して表示すると表示されます。含まれるアルファベットの書記体系はすべて家族の類似性または歴史的血統を持っていることを考えると、そのようなキャラクター間の混乱はおそらく予期せぬものではありません。 「O」（ラテン大文字O、U + 004F）、「0」（DIGIT ZERO、U + 0030）、「LA」（LAO DIGIT ZERO、U +）など、異なる書記体系の文字間の混乱がおそらくもっと驚くでしょう。 0ED0）、 "ዐ"（ETHIOPIC SYLLABLE PHARYNGEAL A、U + 12D0）、および白丸のように見えるその他の書記素。そして、読者は、前述のものがUnicodeで混同される文字のほんの一部のサンプルを表すことを認識する必要があります。
In some instances of confusable characters, it is unlikely that the average human could tell the difference between the real string and the fake string. (Indeed, there is no programmatic way to distinguish with full certainty which is the fake string and which is the real string; in some contexts, the string formed of Cherokee code points might be the real string and the string formed of ASCII code points might be the fake string.) Because PRECIS-compliant strings can contain almost any properly encoded Unicode code point, it can be relatively easy to fake or mimic some strings in systems that use the PRECIS framework. The fact that some strings are easily confused introduces security vulnerabilities of the kind that have also plagued the World Wide Web, specifically the phenomenon known as phishing.
混同しやすい文字のいくつかの例では、平均的な人間が実際の文字列と偽の文字列の違いを見分けることができるとは考えられません。 （確かに、偽の文字列と実際の文字列を完全に確実に区別するプログラム的な方法はありません。状況によっては、チェロキー語コードポイントで構成される文字列が実際の文字列であり、ASCIIコードポイントで構成される文字列がPRECIS準拠の文字列には、適切にエンコードされたほぼすべてのUnicodeコードポイントを含めることができるため、PRECISフレームワークを使用するシステムでは、一部の文字列を比較的簡単に偽造または模倣できます。一部の文字列が簡単に混乱するという事実は、World Wide Webを悩ませている種類のセキュリティ脆弱性、特にフィッシングと呼ばれる現象を引き起こします。
Despite the fact that some specific suggestions about identification and handling of confusable characters appear in the Unicode Security Considerations [UTR36] and the Unicode Security Mechanisms [UTS39], it is also true (as noted in [RFC5890]) that "there are no comprehensive technical solutions to the problems of confusable characters." Because it is impossible to map visually similar characters without a great deal of context (such as knowing the font families used), the PRECIS framework does nothing to map similar- looking characters together, nor does it prohibit some characters because they look like others.
Unicodeのセキュリティに関する考慮事項[UTR36]とUnicodeのセキュリティメカニズム[UTS39]には、紛らわしい文字の識別と処理に関するいくつかの特定の提案があるにもかかわらず、（[RFC5890]に記載されているように）「包括的なものがないことも事実です。混乱しやすいキャラクターの問題に対する技術的な解決策。」使用されているフォントファミリを知っているなど、多くのコンテキストがないと視覚的に類似した文字をマッピングすることは不可能であるため、PRECISフレームワークは、類似した文字を一緒にマッピングすることはありません。
Nevertheless, specifications for application protocols that use this framework are strongly encouraged to describe how confusable characters can be abused to compromise the security of systems that use the protocol in question, along with any protocol-specific suggestions for overcoming those threats. In particular, software implementations and service deployments that use PRECIS-based technologies are strongly encouraged to define and implement consistent policies regarding the registration, storage, and presentation of visually similar characters. The following recommendations are appropriate:
それでも、このフレームワークを使用するアプリケーションプロトコルの仕様では、問題のプロトコルを使用するシステムのセキュリティを危険にさらすために、混同しやすい文字がどのように悪用されるか、およびそれらの脅威を克服するためのプロトコル固有の提案を説明することが強く推奨されます。特に、PRECISベースのテクノロジーを使用するソフトウェアの実装とサービスの展開では、視覚的に類似した文字の登録、保存、および表示に関する一貫したポリシーを定義および実装することが強く推奨されます。次の推奨事項が適切です。
1. An application service SHOULD define a policy that specifies the scripts or blocks of code points that the service will allow to be registered (e.g., in an account name) or stored (e.g., in a filename). Such a policy SHOULD be informed by the languages and scripts that are used to write registered account names; in particular, to reduce confusion, the service SHOULD forbid registration or storage of strings that contain code points from more than one script and SHOULD restrict registrations to code points drawn from a very small number of scripts (e.g., scripts that are well understood by the administrators of the service, to improve manageability).
1. アプリケーションサービスは、サービスが登録（アカウント名など）や保存（ファイル名など）を許可されるスクリプトまたはコードポイントのブロックを指定するポリシーを定義する必要があります（SHOULD）。そのようなポリシーは、登録されたアカウント名を書き込むために使用される言語とスクリプトによって通知される必要があります。特に、混乱を減らすために、サービスは複数のスクリプトからのコードポイントを含む文字列の登録または保存を禁止し、ごく少数のスクリプト（たとえば、サービスの管理者（管理性を向上させるため）。
2. User-oriented application software SHOULD define a policy that specifies how internationalized strings will be presented to a human user. Because every human user of such software has a preferred language or a small set of preferred languages, the software SHOULD gather that information either explicitly from the user or implicitly via the operating system of the user's device.
2. ユーザー指向のアプリケーションソフトウェアは、国際化された文字列が人間のユーザーにどのように提示されるかを指定するポリシーを定義する必要があります（SHOULD）。そのようなソフトウェアのすべての人間のユーザーは優先言語または少数の優先言語セットを持っているため、ソフトウェアはユーザーから明示的に、またはユーザーのデバイスのオペレーティングシステムを介して暗黙的にその情報を収集する必要があります。
The challenges inherent in supporting the full range of Unicode code points have in the past led some to hope for a way to programmatically negotiate more restrictive ranges based on locale, script, or other relevant factors; to tag the locale associated with a particular string; etc. As a general-purpose internationalization technology, the PRECIS framework does not include such mechanisms.
Unicodeコードポイントの全範囲をサポートすることに固有の課題は、過去に、ロケール、スクリプト、またはその他の関連要因に基づいて、より制限的な範囲をプログラムでネゴシエートする方法を希望するようになりました。特定の文字列に関連付けられたロケールにタグを付ける。汎用の国際化テクノロジーとして、PRECISフレームワークにはそのようなメカニズムは含まれていません。
Two goals of passwords are to maximize the amount of entropy and to minimize the potential for false accepts. These goals can be achieved in part by allowing a wide range of code points and by ensuring that passwords are handled in such a way that code points are not compared aggressively. Therefore, it is NOT RECOMMENDED for application protocols to profile the FreeformClass for use in passwords in a way that removes entire categories (e.g., by disallowing symbols or punctuation). Furthermore, it is NOT RECOMMENDED for application protocols to map uppercase and titlecase code points to their lowercase equivalents in such strings; instead, it is RECOMMENDED to preserve the case of all code points contained in such strings and to compare them in a case-sensitive manner.
パスワードの2つの目標は、エントロピーの量を最大化することと、誤った受け入れの可能性を最小化することです。これらの目標は、広範囲のコードポイントを許可し、コードポイントが積極的に比較されないようにパスワードが処理されるようにすることで、部分的に達成できます。したがって、アプリケーションプロトコルがカテゴリ全体を削除する方法で（たとえば、記号または句読点を禁止することによって）パスワードで使用するためにFreeformClassをプロファイルすることは推奨されません。さらに、アプリケーションプロトコルが大文字とタイトルケースのコードポイントをそのような文字列内の対応する小文字にマッピングすることはお勧めしません。代わりに、そのような文字列に含まれるすべてのコードポイントの大文字と小文字を保持し、大文字と小文字を区別して比較することをお勧めします。
That said, software implementers need to be aware that there exist trade-offs between entropy and usability. For example, allowing a user to establish a password containing "uncommon" code points might make it difficult for the user to access a service when using an unfamiliar or constrained input device.
とはいえ、ソフトウェア実装者は、エントロピーと使いやすさの間にトレードオフが存在することを認識する必要があります。たとえば、「一般的ではない」コードポイントを含むパスワードをユーザーが設定できるようにすると、ユーザーが馴染みのない、または制約のある入力デバイスを使用しているときに、サービスにアクセスすることが難しくなる場合があります。
Some application protocols use passwords directly, whereas others reuse technologies that themselves process passwords (one example of such a technology is SASL [RFC4422]). Moreover, passwords are often carried by a sequence of protocols with backend authentication systems or data storage systems such as RADIUS [RFC2865] and the Lightweight Directory Access Protocol (LDAP) [RFC4510]. Developers of application protocols are encouraged to look into reusing these profiles instead of defining new ones, so that end-user expectations about passwords are consistent no matter which application protocol is used.
一部のアプリケーションプロトコルはパスワードを直接使用しますが、他のアプリケーションプロトコルはそれ自体がパスワードを処理するテクノロジーを再利用します（そのようなテクノロジーの1つの例はSASL [RFC4422]です）。さらに、パスワードは多くの場合、RADIUS [RFC2865]やライトウェイトディレクトリアクセスプロトコル（LDAP）[RFC4510]などのバックエンド認証システムまたはデータストレージシステムを備えた一連のプロトコルによって運ばれます。アプリケーションプロトコルの開発者は、新しいプロファイルを定義するのではなく、これらのプロファイルを再利用することを検討することをお勧めします。これにより、使用するアプリケーションプロトコルに関係なく、パスワードに対するエンドユーザーの期待が一貫します。
In protocols that provide passwords as input to a cryptographic algorithm such as a hash function, the client will need to perform proper preparation of the password before applying the algorithm, because the password is not available to the server in plaintext form.
パスワードをハッシュ関数などの暗号化アルゴリズムへの入力として提供するプロトコルでは、クライアントはアルゴリズムを適用する前にパスワードの適切な準備を行う必要があります。これは、パスワードがプレーンテキスト形式でサーバーから利用できないためです。
Further discussion of password handling can be found in [RFC8265].
パスワード処理のさらなる議論は[RFC8265]で見つけることができます。
It is known that some existing applications and systems do not support the full Unicode coded character set, or even any characters outside the ASCII repertoire [RFC20]. If two (or more) applications or systems need to interoperate when exchanging data (e.g., for the purpose of authenticating the combination of a username and password), naturally they will need to have in common at least one coded character set and the repertoire of characters being exchanged (see [RFC6365] for definitions of these terms). Establishing such a baseline is a matter for the application or system that uses PRECIS, not for the PRECIS framework.
既存のアプリケーションやシステムの中には、完全なUnicodeコード化文字セットや、ASCIIレパートリー[RFC20]以外の文字をサポートしていないものがあることがわかっています。 2つ（またはそれ以上）のアプリケーションまたはシステムがデータ交換時に相互運用する必要がある場合（たとえば、ユーザー名とパスワードの組み合わせを認証する目的で）、当然、それらには少なくとも1つのコード化文字セットとレパートリーが必要です。交換される文字（これらの用語の定義については[RFC6365]を参照）このようなベースラインの確立は、PRECISフレームワークではなく、PRECISを使用するアプリケーションまたはシステムの問題です。
The only coded character set supported by PRECIS is Unicode. If an application or system does not support Unicode or uses a different coded character set [RFC6365], then the PRECIS rules cannot be applied to that application or system.
PRECISでサポートされている唯一のコード化文字セットはUnicodeです。アプリケーションまたはシステムがUnicodeをサポートしていないか、別のコード化文字セット[RFC6365]を使用している場合、PRECISルールをそのアプリケーションまたはシステムに適用することはできません。
Although strings that are consumed in PRECIS-based application protocols are often encoded using UTF-8 [RFC3629], the exact encoding is a matter for the application protocol that uses PRECIS, not for the PRECIS framework or for specifications that define PRECIS string classes or profiles thereof.
PRECISベースのアプリケーションプロトコルで使用される文字列は、多くの場合UTF-8 [RFC3629]を使用してエンコードされますが、正確なエンコーディングは、PRECISフレームワークやPRECIS文字列クラスを定義する仕様ではなく、PRECISを使用するアプリケーションプロトコルの問題です。そのプロファイル。
It is extremely important for protocol designers and application developers to understand that various changes can occur across versions of the Unicode Standard, and such changes can result in instability of PRECIS categories. The following are merely a few examples:
プロトコル設計者とアプリケーション開発者は、Unicode標準のバージョン間でさまざまな変更が発生する可能性があることを理解することが非常に重要であり、そのような変更はPRECISカテゴリを不安定にする可能性があります。以下はほんの数例です。
o As described in [RFC6452], between Unicode 5.2 (current at the time IDNA2008 was originally published) and Unicode 6.0, three code points underwent changes in their GeneralCategory, resulting in modified handling, depending on which version of Unicode is available on the underlying system.
o [RFC6452]で説明されているように、Unicode 5.2（IDNA2008が最初に公開された時点）とUnicode 6.0の間で、3つのコードポイントのGeneralCategoryが変更され、基盤となるシステムで使用できるUnicodeのバージョンに応じて処理が変更されました。
o The HasCompat() categorization of a given input string could change if, for example, the string includes a precomposed character that was added in a recent version of Unicode.
o 特定の入力文字列のHasCompat()カテゴリは、たとえば、文字列に最近のバージョンのUnicodeで追加された構成済み文字が含まれている場合に変更される可能性があります。
o The East Asian width property, which is used in many PRECIS width mapping rules, is not guaranteed to be stable across Unicode versions.
o 多くのPRECIS幅マッピングルールで使用される東アジアの幅プロパティは、Unicodeバージョン間で安定しているとは限りません。
As part of the review of Unicode 7.0 for IDNA, a question was raised about a newly added code point that led to a re-analysis of the normalization rules used by IDNA and inherited by this document (Section 5.2.4). Some of the general issues are described in [IAB-Statement] and pursued in more detail in [IDNA-Unicode].
IDNAのUnicode 7.0のレビューの一部として、IDNAで使用され、このドキュメントに継承された正規化ルールの再分析につながる新しく追加されたコードポイントについての質問が提起されました（セクション5.2.4）。一般的な問題のいくつかは、[IAB-Statement]で説明されており、[IDNA-Unicode]でより詳細に追求されています。
At the time of this writing, these issues have yet to be settled. However, implementers need to be aware that this specification is likely to be updated in the future to address these issues. The potential changes include but might not be limited to the following:
この記事の執筆時点では、これらの問題はまだ解決されていません。ただし、実装者は、これらの問題に対処するために、この仕様が将来更新される可能性があることを認識する必要があります。潜在的な変更には、以下が含まれますが、これらに限定されるわけではありません。
o The range of code points in the LetterDigits category (Sections 4.2.1 and 9.1) might be narrowed.
o LetterDigitsカテゴリ（セクション4.2.1および9.1）のコードポイントの範囲が狭くなる可能性があります。
o Some code points with special properties that are now allowed might be excluded.
o 現在許可されている特別なプロパティを持つ一部のコードポイントは除外される場合があります。
o More additional mapping rules (Section 5.2.2) might be defined.
o さらに追加のマッピングルール（セクション5.2.2）が定義される場合があります。
o Alternative normalization methods might be added.
o 別の正規化方法が追加される場合があります。
As described in Section 11.1, until these issues are settled, it is reasonable for the IANA to apply the same precautionary principle described in [IAB-Statement] to the "PRECIS Derived Property Value" registry as is applied to the "IDNA Parameters" registry <https://www.iana.org/assignments/idna-tables/>: that is, to not make further updates to the registry.
セクション11.1で説明されているように、これらの問題が解決するまで、IANAは[IAB-Statement]で説明されている予防原則を「PRECIS Derived Property Value」レジストリに「IDNAパラメータ」レジストリに適用されるのと同じように適用するのが妥当です。 <https://www.iana.org/assignments/idna-tables/>：つまり、これ以上レジストリを更新しません。
Nevertheless, implementations and deployments are unlikely to encounter significant problems as a consequence of these issues or potential changes if they follow the advice given in this specification to use the more restrictive IdentifierClass whenever possible or, if using the FreeformClass, to allow only a restricted set of code points, particularly avoiding code points whose implications they do not understand.
それにもかかわらず、実装とデプロイメントは、これらの問題または潜在的な変更の結果として、これらの問題または潜在的な変更の結果として重大な問題に遭遇する可能性は低いです。可能な場合は常により制限的なIdentifierClassを使用するか、FreeformClassを使用する場合は制限されたセットのみを許可する場合特にコードポイントの影響が理解されていないコードポイントの回避。
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/info/rfc20>.
[RFC20] Cerf、V。、「ネットワーク交換用のASCII形式」、STD 80、RFC 20、DOI 10.17487 / RFC0020、1969年10月、<https://www.rfc-editor.org/info/rfc20>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, <https://www.rfc-editor.org/info/rfc5198>.
[RFC5198] Klensin、J。およびM. Padlipsky、「ネットワークインターチェンジのUnicode形式」、RFC 5198、DOI 10.17487 / RFC5198、2008年3月、<https://www.rfc-editor.org/info/rfc5198>。
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, DOI 10.17487/RFC6365, September 2011, <https://www.rfc-editor.org/info/rfc6365>.
[RFC6365] Hoffman、P。およびJ. Klensin、「IETFの国際化で使用される用語」、BCP 166、RFC 6365、DOI 10.17487 / RFC6365、2011年9月、<https://www.rfc-editor.org/info / rfc6365>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[Unicode] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[Unicode] Unicodeコンソーシアム、「The Unicode Standard」、<http://www.unicode.org/versions/latest/>。
[DerivedCoreProperties] The Unicode Consortium, "DerivedCoreProperties-10.0.0.txt", Unicode Character Database, March 2017, <http://www.unicode.org/Public/UCD/latest/ucd/ DerivedCoreProperties.txt>.
[DerivedCoreProperties] Unicodeコンソーシアム、「DerivedCoreProperties-10.0.0.txt」、Unicode Character Database、2017年3月、<http://www.unicode.org/Public/UCD/latest/ucd/ DerivedCoreProperties.txt>。
[Err4568] RFC Errata, Erratum ID 4568, RFC 7564, <https://www.rfc-editor.org/errata/eid4568>.
[Err4568] RFC Errata、Erratum ID 4568、RFC 7564、<https://www.rfc-editor.org/errata/eid4568>。
[IAB-Statement] Internet Architecture Board, "IAB Statement on Identifiers and Unicode 7.0.0", February 2015, <https://www.iab.org/documents/ correspondence-reports-documents/2015-2/ iab-statement-on-identifiers-and-unicode-7-0-0/>.
[IAB-Statement] Internet Architecture Board、「IAB Statement on Identifiers and Unicode 7.0.0」、2015年2月、<https://www.iab.org/documents/communication-reports-documents/2015-2/iab-statement -on-identifiers-and-unicode-7-0-0 />。
[IDNA-Unicode] Klensin, J. and P. Faltstrom, "IDNA Update for Unicode 7.0.0", Work in Progress, draft-klensin-idna-5892upd-unicode70-04, March 2015.
[IDNA-Unicode] Klensin、J.およびP. Faltstrom、「IDNA Update for Unicode 7.0.0」、Work in Progress、draft-klensin-idna-5892upd-unicode70-04、2015年3月。
[PropertyAliases] The Unicode Consortium, "PropertyAliases-10.0.0.txt", Unicode Character Database, February 2017, <http://www.unicode.org/Public/UCD/latest/ucd/ PropertyAliases.txt>.
[PropertyAliases] Unicodeコンソーシアム、「PropertyAliases-10.0.0.txt」、Unicode Character Database、2017年2月、<http://www.unicode.org/Public/UCD/latest/ucd/ PropertyAliases.txt>。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-editor.org/info/rfc2865>.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、DOI 10.17487 / RFC2865、2000年6月、<https：/ /www.rfc-editor.org/info/rfc2865>。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, DOI 10.17487/RFC3454, December 2002, <https://www.rfc-editor.org/info/rfc3454>.
[RFC3454] Hoffman、P.およびM. Blanchet、「Preparation of Internationalized Strings（ "stringprep"）」、RFC 3454、DOI 10.17487 / RFC3454、2002年12月、<https://www.rfc-editor.org/info/ rfc3454>。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, DOI 10.17487/RFC3490, March 2003, <https://www.rfc-editor.org/info/rfc3490>.
[RFC3490] Faltstrom、P.、Hoffman、P。、およびA. Costello、「Internationalizing Domain Names in Applications（IDNA）」、RFC 3490、DOI 10.17487 / RFC3490、2003年3月、<https：//www.rfc-editor .org / info / rfc3490>。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, DOI 10.17487/RFC3491, March 2003, <https://www.rfc-editor.org/info/rfc3491>.
[RFC3491] Hoffman、P.およびM. Blanchet、「Nameprep：国際化ドメイン名（IDN）のStringprepプロファイル」、RFC 3491、DOI 10.17487 / RFC3491、2003年3月、<https://www.rfc-editor.org / info / rfc3491>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https://www.rfc-editor.org/info/ rfc3629>。
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, <https://www.rfc-editor.org/info/rfc4422>.
[RFC4422]メルニコフ、A。、エド。 K. Zeilenga編、「Simple Authentication and Security Layer（SASL）」、RFC 4422、DOI 10.17487 / RFC4422、2006年6月、<https://www.rfc-editor.org/info/rfc4422>。
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, DOI 10.17487/RFC4510, June 2006, <https://www.rfc-editor.org/info/rfc4510>.
[RFC4510] Zeilenga、K。、編、「Lightweight Directory Access Protocol（LDAP）：Technical Specification Road Map」、RFC 4510、DOI 10.17487 / RFC4510、2006年6月、<https://www.rfc-editor.org/ info / rfc4510>。
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, DOI 10.17487/RFC4690, September 2006, <https://www.rfc-editor.org/info/rfc4690>.
[RFC4690] Klensin、J.、Faltstrom、P.、Karp、C。、およびIAB、「レビューおよび国際化ドメイン名（IDN）の推奨事項」、RFC 4690、DOI 10.17487 / RFC4690、2006年9月、<https：// www.rfc-editor.org/info/rfc4690>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<https://www.rfc-editor.org/info / rfc5246>。
[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>。
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008", RFC 5895, DOI 10.17487/RFC5895, September 2010, <https://www.rfc-editor.org/info/rfc5895>.
[RFC5895] Resnick、P。およびP. Hoffman、「アプリケーションの国際化ドメイン名のマッピング文字（IDNA）2008」、RFC 5895、DOI 10.17487 / RFC5895、2010年9月、<https://www.rfc-editor.org / info / rfc5895>。
[RFC6452] Faltstrom, P., Ed. and P. Hoffman, Ed., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0", RFC 6452, DOI 10.17487/RFC6452, November 2011, <https://www.rfc-editor.org/info/rfc6452>.
[RFC6452] Faltstrom、P.、Ed。およびP.ホフマン編、「アプリケーションのUnicodeコードポイントと国際化ドメイン名（IDNA）-Unicode 6.0」、RFC 6452、DOI 10.17487 / RFC6452、2011年11月、<https://www.rfc-editor.org / info / rfc6452>。
[RFC6885] Blanchet, M. and A. Sullivan, "Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS)", RFC 6885, DOI 10.17487/RFC6885, March 2013, <https://www.rfc-editor.org/info/rfc6885>.
[RFC6885] Blanchet、M。およびA. Sullivan、「国際化された文字列（PRECIS）の準備と比較のためのStringprepの改訂と問題の説明」、RFC 6885、DOI 10.17487 / RFC6885、2013年3月、<https：//www.rfc -editor.org/info/rfc6885>。
[RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 2013, <https://www.rfc-editor.org/info/rfc6943>.
[RFC6943] Thaler、D。、編、「セキュリティ上の目的での識別子比較の問題」、RFC 6943、DOI 10.17487 / RFC6943、2013年5月、<https://www.rfc-editor.org/info/rfc6943>。
[RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 7564, DOI 10.17487/RFC7564, May 2015, <https://www.rfc-editor.org/info/rfc7564>.
[RFC7564] Saint-Andre、P。およびM. Blanchet、「PRECIS Framework：Preparation、Enforcement、and Comparison of Internationalized Strings in Application Protocols」、RFC 7564、DOI 10.17487 / RFC7564、2015年5月、<https：// www。 rfc-editor.org/info/rfc7564>。
[RFC7622] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Address Format", RFC 7622, DOI 10.17487/RFC7622, September 2015, <https://www.rfc-editor.org/info/rfc7622>.
[RFC7622] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Address Format」、RFC 7622、DOI 10.17487 / RFC7622、2015年9月、<https://www.rfc-editor.org/info/ rfc7622>。
[RFC7790] Yoneya, Y. and T. Nemoto, "Mapping Characters for Classes of the Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS)", RFC 7790, DOI 10.17487/RFC7790, February 2016, <https://www.rfc-editor.org/info/rfc7790>.
[RFC7790] Yoneya、Y。およびT. Nemoto、「準備、施行、および国際化文字列の比較（PRECIS）のクラスの文字のマッピング」、RFC 7790、DOI 10.17487 / RFC7790、2016年2月、<https：// www .rfc-editor.org / info / rfc7790>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 8265, DOI 10.17487/RFC8265, October 2017, <https://www.rfc-editor.org/info/rfc8265>.
[RFC8265] Saint-Andre、P。およびA. Melnikov、「ユーザー名とパスワードを表す国際化された文字列の準備、適用、比較」、RFC 8265、DOI 10.17487 / RFC8265、2017年10月、<https：//www.rfc- editor.org/info/rfc8265>。
[RFC8266] Saint-Andre, P., "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames", RFC 8266, DOI 10.17487/RFC8266, October 2017, <https://www.rfc-editor.org/info/rfc8266>.
[RFC8266] Saint-Andre、P。、「ニックネームを表す国際化された文字列の準備、施行、比較」、RFC 8266、DOI 10.17487 / RFC8266、2017年10月、<https://www.rfc-editor.org/info/ rfc8266>。
[UAX11] Unicode Standard Annex #11, "East Asian Width", edited by Ken Lunde. An integral part of The Unicode Standard, <http://unicode.org/reports/tr11/>.
[UAX11] Unicode標準付属書＃11、「東アジアの幅」、Ken Lundeによる編集。 Unicode標準の不可欠な部分である<http://unicode.org/reports/tr11/>。
[UAX15] Unicode Standard Annex #15, "Unicode Normalization Forms", edited by Mark Davis and Ken Whistler. An integral part of The Unicode Standard, <http://unicode.org/reports/tr15/>.
[UAX15]マークデイビスとケンウィスラーによって編集されたUnicode標準付属書＃15、「Unicode Normalization Forms」。 Unicode標準の不可欠な部分である<http://unicode.org/reports/tr15/>。
[UAX9] Unicode Standard Annex #9, "Unicode Bidirectional Algorithm", edited by Mark Davis, Aharon Lanin, and Andrew Glass. An integral part of The Unicode Standard, <http://unicode.org/reports/tr9/>.
[UAX9] Unicode標準付属書＃9、「Unicode双方向アルゴリズム」、Mark Davis、Aharon Lanin、Andrew Glassにより編集。 Unicode標準の不可欠な部分である<http://unicode.org/reports/tr9/>。
[UTR36] Unicode Technical Report #36, "Unicode Security Considerations", edited by Mark Davis and Michel Suignard, <http://unicode.org/reports/tr36/>.
[UTR36] Unicodeテクニカルレポート＃36、「Unicodeのセキュリティに関する考慮事項」、Mark DavisおよびMichel Suignardによる編集、<http://unicode.org/reports/tr36/>。
[UTS39] Unicode Technical Standard #39, "Unicode Security Mechanisms", edited by Mark Davis and Michel Suignard, <http://unicode.org/reports/tr39/>.
[UTS39] Unicode技術標準＃39、「Unicode Security Mechanisms」、Mark DavisおよびMichel Suignardにより編集、<http://unicode.org/reports/tr39/>。
The following changes were made from [RFC7564].
[RFC7564]から次の変更が行われました。
o Recommended the Unicode toLowerCase() operation over the Unicode toCaseFold() operation in most PRECIS applications.
o ほとんどのPRECISアプリケーションで、Unicode toCaseFold()操作よりもUnicode toLowerCase()操作を推奨しました。
o Clarified the meaning of "preparation", and described the motivation for including it in PRECIS.
o 「準備」の意味を明確にし、それをPRECISに含める動機を説明しました。
o Updated references.
o 更新された参照。
See [RFC7564] for a description of the differences from [RFC3454].
[RFC3454]との違いの説明については[RFC7564]を参照してください。
Acknowledgements
謝辞
Thanks to Martin Duerst, William Fisher, John Klensin, Christian Schudt, and Sam Whited for their feedback. Thanks to Sam Whited also for submitting [Err4568].
Martin Duerst、William Fisher、John Klensin、Christian Schudt、Sam Whitedのフィードバックに感謝します。 [Err4568]を提出してくれたSam Whitedにも感謝します。
See [RFC7564] for acknowledgements related to the specification that this document supersedes.
このドキュメントが優先する仕様に関連する謝辞については、[RFC7564]を参照してください。
Some algorithms and textual descriptions have been borrowed from [RFC5892]. Some text regarding security has been borrowed from [RFC5890], [RFC8265], and [RFC7622].
いくつかのアルゴリズムとテキストによる説明は、[RFC5892]から借用されました。セキュリティに関する一部のテキストは、[RFC5890]、[RFC8265]、および[RFC7622]から借用されました。
Authors' Addresses
著者のアドレス
Peter Saint-Andre Jabber.org P.O. Box 787 Parker, CO 80134 United States of America
Peter Saint-Andre Jabber.org P.O. Box 787 Parker、CO 80134アメリカ合衆国
Phone: +1 720 256 6756
Email: stpeter@jabber.org
URI: https://www.jabber.org/
Marc Blanchet Viagenie 246 Aberdeen Québec, QC G1R 2E1 Canada
Marc Blanchet Viagenie 246 Aberdeen Quebec、QC G1R 2E1 Canada
Email: Marc.Blanchet@viagenie.ca
URI: http://www.viagenie.ca/