[要約] RFC 7564は、国際化された文字列の準備、強制、比較を行うためのPRECISフレームワークについての規格です。その目的は、アプリケーションプロトコルでの国際化文字列の正確な処理を確保することです。
Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 7564 &yet
Obsoletes: 3454 M. Blanchet
Category: Standards Track Viagenie
ISSN: 2070-1721 May 2015
PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols
PRECISフレームワーク：アプリケーションプロトコルでの国際化された文字列の準備、適用、比較
Abstract
概要
Application protocols using Unicode characters 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 characters and thus is 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 3454.
プロトコル文字列にUnicode文字を使用するアプリケーションプロトコルは、さまざまなプロトコルスロット（アドレスや識別子など）に配置された文字列に国際化ルールを適用し、有効な比較操作（認証や承認など）を実行するために、そのような文字列を適切に処理する必要があります。 。このドキュメントは、アプリケーションプロトコルがUnicode文字のプロパティに依存する方法で国際化された文字列（「PRECIS」）の準備、適用、および比較を実行できるようにするフレームワークを定義し、Unicodeのバージョンに関して俊敏です。その結果、このフレームワークは、国際化された文字列の処理に対して、以前のフレームワークであるStringprep（RFC 3454）よりも持続可能なアプローチを提供します。このドキュメントはRFC 3454を廃止します。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7564.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7564で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................7
3. Preparation, Enforcement, and Comparison ........................7
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 .........................................11
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
5. Profiles .......................................................13
5.1. Profiles Must Not Be Multiplied beyond Necessity ..........13
5.2. Rules .....................................................14
5.2.1. Width Mapping Rule .................................14
5.2.2. Additional Mapping Rule ............................14
5.2.3. Case Mapping Rule ..................................14
5.2.4. Normalization Rule .................................15
5.2.5. Directionality Rule ................................15
5.3. A Note about Spaces .......................................16
6. Applications ...................................................17
6.1. How to Use PRECIS in Applications .........................17
6.2. Further Excluded Characters ...............................18
6.3. Building Application-Layer Constructs .....................18
7. Order of Operations ............................................19
8. Code Point Properties ..........................................20
9. Category Definitions Used to Calculate Derived Property ........22
9.1. LetterDigits (A) ..........................................23
9.2. Unstable (B) ..............................................23
9.3. IgnorableProperties (C) ...................................23
9.4. IgnorableBlocks (D) .......................................23
9.5. LDH (E) ...................................................23
9.6. Exceptions (F) ............................................23
9.7. BackwardCompatible (G) ....................................23
9.8. JoinControl (H) ...........................................24
9.9. OldHangulJamo (I) .........................................24
9.10. Unassigned (J) ...........................................24
9.11. ASCII7 (K) ...............................................24
9.12. Controls (L) .............................................24
9.13. PrecisIgnorableProperties (M) ............................24
9.14. Spaces (N) ...............................................25
9.15. Symbols (O) ..............................................25
9.16. Punctuation (P) ..........................................25
9.17. HasCompat (Q) ............................................25
9.18. OtherLetterDigits (R) ....................................25
10. Guidelines for Designated Experts .............................26
11. IANA Considerations ...........................................27
11.1. PRECIS Derived Property Value Registry ...................27
11.2. PRECIS Base Classes Registry .............................27
11.3. PRECIS Profiles Registry .................................28
12. Security Considerations .......................................29
12.1. General Issues ...........................................29
12.2. Use of the IdentifierClass ...............................30
12.3. Use of the FreeformClass .................................30
12.4. Local Character Set Issues ...............................31
12.5. Visually Similar Characters ..............................31
12.6. Security of Passwords ....................................33
13. Interoperability Considerations ...............................34
13.1. Encoding .................................................34
13.2. Character Sets ...........................................34
13.3. Unicode Versions .........................................34
13.4. Potential Changes to Handling of Certain Unicode
Code Points ..............................................34
14. References ....................................................35
14.1. Normative References .....................................35
14.2. Informative References ...................................36
Acknowledgements ..................................................40
Authors' Addresses ................................................40
Application protocols using Unicode characters [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 characters and thus is agile with respect to versions of Unicode.
プロトコル文字列でUnicode文字[Unicode]を使用するアプリケーションプロトコルは、さまざまなプロトコルスロット（アドレスや識別子など）に配置された文字列に国際化規則を適用し、有効な比較操作（認証など）を実行するために、そのような文字列を適切に処理する必要があります。または承認）。このドキュメントは、アプリケーションプロトコルがUnicode文字のプロパティに依存する方法で国際化された文字列（「PRECIS」）の準備、適用、および比較を実行できるようにするフレームワークを定義し、Unicodeのバージョンに関して俊敏です。
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 characters, especially characters 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 characters (i.e., specific "code points") appropriate for common application protocol constructs.
1. 一般的なアプリケーションプロトコル構成に適したUnicode文字（つまり、特定の「コードポイント」）を指定する文字列クラスの小さなセットを定義します。
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 agile with regard to Unicode versions.
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 characters 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 [PRECIS-Users-Pwds], opaque strings such as passwords [PRECIS-Users-Pwds], and nicknames [PRECIS-Nickname]. Profiles are responsible for defining the handling of right-to-left characters 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 characters to other characters or to nothing, and mapping of fullwidth and halfwidth characters.
文字列クラスは一連のアプリケーションの「ベースライン」コードポイントを定義しますが、プロファイリングにより、アプリケーションプロトコルはユーザー名[PRECIS-Users-Pwds]、パスワードなどの不透明な文字列などの一般的な構成に適した方法で文字列クラスを適用できます[PRECIS-Users-Pwds]、およびニックネーム[PRECIS-Nickname]。プロファイルは、右から左への文字の処理のほか、[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 (e.g., to 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 "bit-string identity" (e.g., to make an access decision for purposes of authentication or authorization as further described in [RFC6943]).
b. 2つの出力文字列を比較して、それらが同等であるかどうかを判断します。通常、「ビット文字列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 "stpeter", and information about the capitalization of the first and third characters would be lost. 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.
セクション8および9で定義された文字カテゴリと計算規則は規範的であり、すべてのUnicodeコードポイントに適用されます。文字カテゴリと計算ルールを最新バージョンのUnicodeに適用した結果のコードポイントテーブルは、IANAレジストリにあります。
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]で定義されています。
As of the date of writing, the version of Unicode published by the Unicode Consortium is 7.0 [Unicode7.0]; however, PRECIS is not tied to a specific version of Unicode. The latest version of Unicode is always available [Unicode].
執筆日現在、Unicode Consortiumによって公開されているUnicodeのバージョンは7.0 [Unicode7.0]です。ただし、PRECISは特定のバージョンのUnicodeに関連付けられていません。 Unicodeの最新バージョンは常に利用可能です[Unicode]。
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 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
This document distinguishes between three different actions that an entity can take with regard to a string:
このドキュメントでは、文字列に関してエンティティが実行できる3つの異なるアクションを区別しています。
o Enforcement entails applying all of the rules specified for a particular string class or profile thereof to an individual string, for the purpose of determining if the string can be used in a given protocol slot.
o 施行では、特定の文字列クラスまたはそのプロファイルに指定されたすべてのルールを個々の文字列に適用し、特定のプロトコルスロットで文字列を使用できるかどうかを判断します。
o Comparison entails applying all of the rules specified for a particular string class or profile thereof to two separate strings, for the purpose of determining if the two strings are equivalent.
o 比較では、2つの文字列が等しいかどうかを判断するために、特定の文字列クラスまたはそのプロファイルに指定されたすべてのルールを2つの別々の文字列に適用します。
o Preparation entails only ensuring that the characters in an individual string are allowed by the underlying PRECIS string class.
o 準備では、個々の文字列の文字が、基盤となるPRECIS文字列クラスで許可されていることを確認するだけです。
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 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 characters that would minimize the potential for user confusion caused by visually similar characters (and thus be relatively "safe") vs. defining a much larger set of Unicode characters 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 chatroom), 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 characters 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 chatroom; the intent is that this class will allow nearly any Unicode character, 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 characters 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:
次のサブセクションでは、[RFC6885]のセクション5で説明されているディメンションを参照しながら、IdentifierClassとFreeformClassについて詳しく説明します。各文字列クラスは、次の動作規則によって定義されます。
Valid: Defines which code points are treated as valid for the string.
有効：文字列に対して有効として扱われるコードポイントを定義します。
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).
必要なコンテキストルール：コンテキストルールの要件（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 mappings, 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 chatroom 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 characters allowed in the IdentifierClass is wider than the range of characters allowed in IDNA2008. The main reason is that IDNA2008 applies the Unstable category before the LetterDigits category, thus disallowing uppercase characters, whereas the IdentifierClass does not apply the Unstable category.
注：PRECIS IdentifierClassはIDNA2008のLetterDigitsカテゴリーを再利用しますが、IdentifierClassで許可される文字の範囲は、IDNA2008で許可される文字の範囲よりも広いです。主な理由は、IDNA2008がLetterDigitsカテゴリの前にUnstableカテゴリを適用するため、大文字が許可されないのに対し、IdentifierClassはUnstableカテゴリを適用しないためです。
o A number of characters from the Exceptions ("F") category defined under Section 9.6 (see Section 9.6 for a full list).
o セクション9.6で定義されている例外（ "F"）カテゴリの文字数（完全なリストについては、セクション9.6を参照）。
o Joining characters, i.e., the JoinControl ("H") category defined under Section 9.8.
o 結合文字、つまりセクション9.8で定義されたJoinControl（ "H"）カテゴリ。
o Old Hangul Jamo characters, i.e., the OldHangulJamo ("I") category defined under Section 9.9.
o 古いハングルジャモ文字、つまり、セクション9.9で定義されたオールドハングルジャモ（「I」）カテゴリ。
o Control characters, i.e., the Controls ("L") category defined under Section 9.12.
o 制御文字。つまり、セクション9.12で定義されている制御（「L」）カテゴリ。
o Ignorable characters, i.e., the PrecisIgnorableProperties ("M") category defined under Section 9.13.
o 無視できる文字、つまりセクション9.13で定義されているPrecisIgnorableProperties（ "M"）カテゴリ。
o Space characters, i.e., the Spaces ("N") category defined under Section 9.14.
o スペース文字、つまりセクション9.14で定義されているスペース（ "N"）カテゴリ。
o Symbol characters, i.e., the Symbols ("O") category defined under Section 9.15.
o シンボル文字、つまり、セクション9.15で定義されたシンボル（「O」）カテゴリ。
o Punctuation characters, i.e., the Punctuation ("P") category defined under Section 9.16.
o 句読点文字、つまりセクション9.16で定義されている句読点（「P」）カテゴリ。
o Any character that has a compatibility equivalent, 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 同等の互換性を持つ任意の文字、つまり、セクション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 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 [PRECIS-Users-Pwds] (the UsernameCaseMapped and UsernameCasePreserved profiles).
このドキュメントの概要で説明したように、文字列クラスは文字列の準備と比較（ケースマッピングなど）に関連するすべての問題を処理するわけではありません。代わりに、そのような問題はプロファイルのレベルで処理されます。 IdentifierClassのプロファイルの例は、[PRECIS-Users-Pwds]（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 [PRECIS-Users-Pwds]) or a nickname in a chatroom (see [PRECIS-Nickname]). We group such things into a class called "FreeformClass" having the following features.
一部のアプリケーションテクノロジーでは、認証交換のパスワード（[PRECIS-Users-Pwds]を参照）またはチャットルームのニックネーム（[PRECIS-Nickname]を参照）など、自由形式で使用できる文字列が必要です。そのようなものを「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 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 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 Any character that has a compatibility equivalent, i.e., the HasCompat ("Q") category defined under Section 9.17.
o 同等の互換性を持つ任意の文字、つまり、セクション9.17で定義されているHasCompat（ "Q"）カテゴリ。
o Space characters, i.e., the Spaces ("N") category defined under Section 9.14.
o スペース文字、つまりセクション9.14で定義されているスペース（ "N"）カテゴリ。
o Symbol characters, i.e., the Symbols ("O") category defined under Section 9.15.
o シンボル文字、つまり、セクション9.15で定義されたシンボル（「O」）カテゴリ。
o Punctuation characters, i.e., the Punctuation ("P") category defined under Section 9.16.
o 句読点文字、つまりセクション9.16で定義されている句読点（「P」）カテゴリ。
o A number of characters from the Exceptions ("F") category defined under Section 9.6 (see Section 9.6 for a full list).
o セクション9.6で定義されている例外（ "F"）カテゴリの文字数（完全なリストについては、セクション9.6を参照）。
o Joining characters, i.e., the JoinControl ("H") category defined under Section 9.8.
o 結合文字、つまりセクション9.8で定義されたJoinControl（ "H"）カテゴリ。
o Old Hangul Jamo characters, i.e., the OldHangulJamo ("I") category defined under Section 9.9.
o 古いハングルジャモ文字、つまり、セクション9.9で定義されたオールドハングルジャモ（「I」）カテゴリ。
o Control characters, i.e., the Controls ("L") category defined under Section 9.12.
o 制御文字。つまり、セクション9.12で定義されている制御（「L」）カテゴリ。
o Ignorable characters, 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 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 [PRECIS-Users-Pwds] (the OpaqueString profile) and [PRECIS-Nickname] (the Nickname profile).
このドキュメントの概要で説明したように、文字列クラスは文字列の準備と比較（ケースマッピングなど）に関連するすべての問題を処理するわけではありません。代わりに、そのような問題はプロファイルのレベルで処理されます。 FreeformClassのプロファイルの例は、[PRECIS-Users-Pwds]（OpaqueStringプロファイル）および[PRECIS-Nickname]（ニックネームプロファイル）にあります。
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 mappings (if any), case mapping, normalization, and directionality rules. A profile MAY also restrict the allowable characters 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 of the FreeformClass used for opaque strings such as passwords is the OpaqueString profile [PRECIS-Users-Pwds].
PRECIS文字列クラスのプロファイルは、セクション11.3で説明されているようにIANAに登録されます。プロファイル名は次の規則を使用します。「Profilename of BaseClass」の形式です。「Profilename」文字列は差別化要因であり、「BaseClass」はプロファイル対象のPRECIS文字列クラスの名前です。たとえば、パスワードなどの不透明な文字列に使用されるFreeformClassのプロファイルは、OpaqueStringプロファイル[PRECIS-Users-Pwds]です。
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, chatroom nicknames, filenames, authentication identifiers, passwords, and other strings are already out there 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), among others.
実際、すでにプロファイルが多すぎます。理想的には、最大2つまたは3つのプロファイルを持つことになります。残念ながら、プロトコル文字列に関して独自の癖がある多数のアプリケーションプロトコルが存在します。ドメイン名、電子メールアドレス、インスタントメッセージングアドレス、チャットルームのニックネーム、ファイル名、認証識別子、パスワード、およびその他の文字列はすでに一般に公開されており、DNS、SMTP、Extensible Messaging and Presenceなどの既存のアプリケーションプロトコルでサポートする必要があります。プロトコル（XMPP）、インターネットリレーチャット（IRC）、NFS、インターネットスモールコンピューターシステムインターフェイス（iSCSI）、拡張認証プロトコル（EAP）、および簡易認証およびセキュリティレイヤー（SASL）など。
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 the characters of a string, and how the mapping is done. Typically, such mapping consists of mapping fullwidth and halfwidth characters, 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 DIGIT ZERO (U+0030).
プロファイルの幅マッピングルールは、文字列の文字に対して幅マッピングを実行するかどうか、およびマッピングの方法を指定します。通常、このようなマッピングは、全角文字と半角文字、つまりワイドまたはナローの分解タイプのコードポイントを分解マッピングにマッピングすることで構成されます。例として、FULLWIDTH DIGIT ZERO（U + FF10）は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 characters 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]を参照してください。
The additional mapping rule of a profile specifies whether additional mappings are performed on the characters of a string, such as:
プロファイルの追加のマッピングルールは、次のような文字列の文字に対して追加のマッピングを実行するかどうかを指定します。
Mapping of delimiter characters (such as '@', ':', '/', '+',
and '-')
Mapping of special characters (e.g., non-ASCII space characters to ASCII space or control characters to nothing).
特殊文字のマッピング（ASCII以外のスペース文字からASCIIスペースへのマッピング、または制御文字からなしへのマッピングなど）。
The PRECIS mappings document [PRECIS-Mappings] describes such mappings in more detail.
PRECISマッピングドキュメント[PRECIS-Mappings]では、そのようなマッピングについて詳しく説明しています。
The case mapping rule of a profile specifies whether case mapping (instead of case preservation) is performed on the characters of a string, and how the mapping is applied (e.g., mapping uppercase and titlecase characters to their lowercase equivalents).
プロファイルのケースマッピングルールは、文字列の文字に対してケースマッピング（ケース保持の代わりに）が実行されるかどうか、およびマッピングがどのように適用されるかを指定します（たとえば、大文字とタイトル文字を対応する小文字にマッピングします）。
If case mapping is desired (instead of case preservation), it is RECOMMENDED to use Unicode Default Case Folding as defined in the Unicode Standard [Unicode] (at the time of this writing, the algorithm is specified in Chapter 3 of [Unicode7.0]).
ケースのマッピングが必要な場合（ケースを保持するのではなく）、Unicode標準[Unicode]で定義されているUnicodeのデフォルトのケースの折りたたみを使用することをお勧めします（この執筆時点では、アルゴリズムは[Unicode7.0 ]）。
Note: Unicode Default Case Folding is not designed to handle various localization issues (such as so-called "dotless i" in several Turkic languages). The PRECIS mappings document [PRECIS-Mappings] describes these issues in greater detail and defines a "local case mapping" method that handles some locale-dependent and context-dependent mappings.
注：Unicodeデフォルトのケースフォールディングは、さまざまなローカリゼーションの問題（いくつかのTurkic言語でのいわゆる「ドットレスi」など）を処理するようには設計されていません。 PRECISマッピングドキュメント[PRECIS-Mappings]は、これらの問題を詳細に説明し、一部のロケール依存およびコンテキスト依存マッピングを処理する「ローカルケースマッピング」メソッドを定義しています。
In order to maximize entropy and minimize the potential for false positives, 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 and in [PRECIS-Users-Pwds].
エントロピーを最大化し、誤検出の可能性を最小化するために、FreeformClassまたはそのプロファイルに準拠する文字列がパスワードで使用される場合、大文字とタイトルケースのコードポイントを対応する小文字にマッピングすることは、アプリケーションプロトコルでは推奨されません。代わりに、そのような文字列に含まれるすべてのコードポイントの大文字と小文字を保持し、大文字と小文字を区別して比較することをお勧めします。セクション12.6および[PRECIS-Users-Pwds]の関連する説明も参照してください。
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標準付属文書＃15 [UAX15]を参照してください）。
In accordance with [RFC5198], normalization form C (NFC) is RECOMMENDED.
[RFC5198]に従って、正規化形式C（NFC）が推奨されます。
The directionality rule of a profile specifies how to treat strings containing what are often called "right-to-left" (RTL) characters (see Unicode Standard Annex #9 [UAX9]). RTL characters 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 characters also contain "left-to-right" (LTR) characters, such as numerals, as well as characters without directional properties. Consequently, such strings are known as "bidirectional strings".
プロファイルの方向性規則は、「右から左」（RTL）文字と呼ばれることが多い文字を含む文字列の処理方法を指定します（Unicode Standard Annex＃9 [UAX9]を参照）。 RTL文字は、通常は右から左に記述され、Unicodeによってそれ自体が右から左の方向性を持つと見なされるスクリプトから取得されます。 RTL文字を含む一部の文字列には、数字などの「左から右」（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 counter-intuitive 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, and does not define any new directionality rules, since 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.
PRECISフレームワークは、すべての文字列クラスとプロファイルにわたって双方向文字列を処理する方法に直接対処せず、新しい方向性ルールを定義していません。現在のところ、任意の双方向文字列を安全に表示するための広く受け入れられ実装されているソリューションがないためです。 Unicode双方向アルゴリズム[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 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 characters are confusable with ASCII space.
o 多くのUnicode文字はASCIIスペースと混同されます。
o Even if non-ASCII space characters are mapped to ASCII space (U+0020), space characters 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以外のスペース文字がASCIIスペース（U + 0020）にマップされている場合でも、スペース文字はユーザーインターフェイスでレンダリングされないことが多く、人間のユーザーがスペースを含む文字列を同じ文字列と同等であると見なす可能性がありますスペース。
o In some locales, some devices are known to generate a character other than ASCII space (such as ZERO WIDTH JOINER, U+200D) when a user performs an action like hitting the space bar on a keyboard.
o 一部のロケールでは、ユーザーがキーボードのスペースバーを押すなどのアクションを実行すると、一部のデバイスがASCIIスペース以外の文字（ZERO WIDTH JOINER、U + 200Dなど）を生成することが知られています。
One consequence of disallowing space characters 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 characters (especially non-ASCII space characters) 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, which 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. Application developers still need to give some thought to 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はアプリケーションを考慮して設計されていますが、PRECISの使用によって国際化が突然容易になるわけではありません。アプリケーション開発者は、アプリケーションで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 characters (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 [PRECIS-Users-Pwds] of the IdentifierClass, or checking the password of a user against the OpaqueString profile [PRECIS-Users-Pwds] of the FreeformClass).
* どのプロトコルスロットをどのプロファイルに対してチェックする必要があるか（たとえば、メッセージの目的の受信者のアドレスをIdentifierClassのUsernameCaseMappedプロファイル[PRECIS-Users-Pwds]に対してチェックするか、OpaqueStringプロファイル[PRECISに対してユーザーのパスワードをチェックする-Users-Pwds]のFreeformClassを参照）。
See [PRECIS-Users-Pwds] and [XMPP-Addr-Format] for definitions of these matters for several applications.
複数のアプリケーションのこれらの問題の定義については、[PRECIS-Users-Pwds]および[XMPP-Addr-Format]を参照してください。
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 characters 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 base string classes or a profile thereof. Consider, for example, the "simple user name" construct in the Simple Authentication and Security Layer (SASL) [RFC4422]. Depending on the deployment, a simple user name 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 user name cannot be defined as an instance of the IdentifierClass or a profile thereof, since space characters 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 [PRECIS-Users-Pwds]:
場合によっては、アプリケーション層の構成要素が、基本文字列クラスの1つまたはそのプロファイルに直接マッピングされないことがあります。たとえば、Simple Authentication and Security Layer（SASL）[RFC4422]の「simple user name」構成について考えてみます。展開によっては、単純なユーザー名がユーザーのフルネーム（たとえば、ユーザーの個人名、スペース、ユーザーの姓）の形式を取る場合があります。 IdentifierClassではスペース文字を使用できないため、そのような単純なユーザー名をIdentifierClassまたはそのプロファイルのインスタンスとして定義することはできません。ただし、次のABNF [RFC5234] [PRECIS-Users-Pwds]のように、スペースで区切られたIdentifierClassインスタンスのシーケンスを使用して定義できます。
username = userpart *(1*SP userpart)
userpart = 1*(idbyte)
;
; an "idbyte" is a byte used to represent a
; UTF-8 encoded Unicode code point that can be
; contained in a string that conforms 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 [PRECIS-Mappings]).
すでに説明したように、幅のマッピング、追加のマッピング、大文字と小文字のマッピング、正規化、および方向性のルールはプロファイルごとに指定されますが、動作のルールは文字列クラスごとに指定されます。この順序の背後にあるロジックの一部は、セクション5.2.1で提供されています（PRECISマッピングドキュメント[PRECIS-Mappings]も参照）。
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 character set by examining various code point properties.
1. さまざまなコードポイントプロパティを調べて、Unicode文字セットのコードポイントのコレクションを確認および分類します。
2. Defines an algorithm for determining a derived property value, which can vary depending 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" or "ID_PVAL". In practice, the
derived property ID_PVAL is not used in this specification, since
every ID_PVAL code point is PVALID.
CONTEXTUAL RULE REQUIRED Some characteristics of the character, such as its being invisible in certain contexts or problematic in others, require that it not be used in labels unless specific other characters or properties are present. As in IDNA2008, there are two subdivisions of CONTEXTUAL RULE REQUIRED -- the first for Join_controls (called "CONTEXTJ") and the second for other characters (called "CONTEXTO"). A character with the derived property value CONTEXTJ or CONTEXTO MUST NOT be used unless an appropriate rule has been established and the context of the character is consistent with that rule. The most notable of the CONTEXTUAL RULE REQUIRED characters are the Join Control characters U+200D ZERO WIDTH JOINER and U+200C ZERO WIDTH NON-JOINER, which have a derived property value of CONTEXTJ. See Appendix A of [RFC5892] for more information.
必要なコンテキストルール特定のコンテキストでは表示されない、他のコンテキストでは問題が発生するなど、特定の文字やプロパティが存在しない限り、ラベルで使用しないようにする必要があります。 IDNA2008の場合と同様に、CONTEXTUAL RULE REQUIREDには2つのサブディビジョンがあります。1つ目はJoin_controls（ "CONTEXTJ"と呼ばれます）用で、もう1つは他の文字（ "CONTEXTO"と呼ばれます）用です。派生プロパティ値CONTEXTJまたはCONTEXTOを持つ文字は、適切なルールが確立されておらず、文字のコンテキストがそのルールと一致していない限り、使用してはなりません（MUST NOT）。 CONTEXTUAL RULE REQUIREDの最も注目すべき文字は、結合制御文字U + 200D ZERO WIDTH JOINERおよびU + 200C ZERO WIDTH NON-JOINERであり、これらは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"
or "ID_DIS". In practice, the derived property FREE_DIS is not
used in this specification, since 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, since 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 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, since every ID_PVAL code point is PVALID and every FREE_DIS code point is DISALLOWED.
計算された派生プロパティの値は、文字列クラスによって異なります。たとえば、アプリケーションプロトコルで使用される識別子がPRECIS IdentifierClassのプロファイリングとして定義されている場合、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 characters added after Unicode 5.2 or 7.0 depending on the category, since 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 character can have its Unicode General_Category value (at the time of this writing, see Chapter 4 of [Unicode7.0]) 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値（この記事の執筆時点では[Unicode7.0]の第4章を参照）をSoからSm、またはLoからLlに変更できます。さらに、このような変更が発生した場合でも、BackwardCompatibleリスト（セクション9.7）を調整して、結果の安定性を確保できます。
The derived property obtains its value based on a two-step procedure:
派生プロパティは、2段階の手順に基づいてその値を取得します。
1. Characters 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 character 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 ） ""コードポイント "。たとえば、コードポイントの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 characters. Some of these categories are reused in PRECIS, and some of them are not; 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.
以下に示す最初の10カテゴリ（A〜J）は、以前IDNA2008に対して定義されたものであり、PRECISがさまざまな文字を処理する方法を理解しやすくするために[RFC5892]から参照されています。これらのカテゴリの一部は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で使用するために参照として含まれています。
This category is defined in Section 2.9 of [RFC5892] and is included by reference for use in PRECIS.
このカテゴリは[RFC5892]のセクション2.9で定義されており、PRECISで使用するために参照として含まれています。
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 characters from the 7-bit ASCII range. By applying this category, the algorithm specified under Section 8 exempts these characters 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 counter-productive.
このPRECIS固有のカテゴリは、7ビットASCII範囲のすべての印刷可能なスペース以外の文字で構成されています。このカテゴリを適用することにより、セクション8で指定されたアルゴリズムは、これらの文字をPRECIS処理中に適用される可能性のある他のルールから除外します。
K: cp is in {0021..007E}
This PRECIS-specific category consists of all control characters.
このPRECIS固有のカテゴリーは、すべての制御文字で構成されています。
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]にあります。
This PRECIS-specific category is used to group code points that are space characters.
この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 characters.
このPRECIS固有のカテゴリは、句読文字であるコードポイントをグループ化するために使用されます。
P: General_Category(cp) is in {Pc, Pd, Ps, Pe, Pi, Pf, Po}
This PRECIS-specific category is used to group code points that have compatibility equivalents as explained in the Unicode Standard (at the time of this writing, see Chapters 2 and 3 of [Unicode7.0]).
このPRECIS固有のカテゴリは、Unicode標準で説明されているように互換性のあるコードポイントをグループ化するために使用されます（この執筆時点では、[Unicode7.0]の第2章と第3章を参照）。
Q: toNFKC(cp) != cp
The toNFKC() operation returns the code point in normalization form KC. For more information, see Section 5 of Unicode Standard Annex #15 [UAX15].
toNFKC()オペレーションは、コードポイントをKCの正規化形式で返します。詳細については、Unicode Standard Annex＃15 [UAX15]のセクション5を参照してください。
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) class (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 tradeoffs 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, since 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 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プロファイルの登録ポリシーはExpert Reviewであり、安定した仕様はそうではありません）厳密に必須）。
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 that records the derived properties for the versions of Unicode that are released after (and including) version 7.0. The derived property value is to be calculated in cooperation with a designated expert [RFC5226] according to the rules specified under Sections 8 and 9.
IANAは、バージョン7.0以降にリリースされたバージョンのUnicodeの派生プロパティを記録する「PRECIS Derived Property Value」レジストリを作成して維持しています。派生プロパティ値は、セクション8および9で指定されたルールに従って、指定された専門家[RFC5226]と協力して計算されます。
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レビューが必要です。
IANA has created the "PRECIS Base Classes" registry. In accordance with [RFC5226], the registration policy is "RFC Required".
IANAは「PRECIS Base Classes」レジストリを作成しました。 [RFC5226]に従い、登録ポリシーは「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文字列クラスとその使用目的の簡単な説明。たとえば、「ネットワークエンティティの識別またはアドレス指定に使用される文字、数字、および記号のシーケンス」]
Specification: [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 7564.
基本クラス：FreeformClass。説明：自由形式の文字列に使用される文字、数字、記号、スペース、およびその他のコードポイントのシーケンス。仕様：RFC 7564のセクション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 7564.
基本クラス：IdentifierClass。説明：ネットワークエンティティの識別またはアドレス指定に使用される文字、数字、および記号のシーケンス。仕様：RFC 7564のセクション4.2。
IANA has created the "PRECIS Profiles" registry to identify profiles that use the PRECIS string classes. In accordance with [RFC5226], 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プロファイル」レジストリを作成しました。 [RFC5226]に従い、登録ポリシーは「エキスパートレビュー」です。このポリシーは、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., "Localparts in XMPP addresses."]
適用範囲：[このプロファイルが適用される特定のプロトコル要素。たとえば、「XMPPアドレスのローカルパーツ」]
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 characters to their compatibility variants."]
幅マッピングルール：[幅を処理するための動作ルール。例：「全角文字と半角文字を互換性のあるバリアントにマップします。」]
Additional Mapping Rule: [any additional mappings that are required or recommended, e.g., "Map non-ASCII space characters to ASCII space."]
追加のマッピングルール：[必須または推奨される追加のマッピング。たとえば、「非ASCIIスペース文字をASCIIスペースにマップします。」]
Case Mapping Rule: [the behavioral rule for handling of case, e.g., "Unicode Default Case Folding"]
ケースマッピングルール：[ケースを処理するための動作ルール、たとえば「Unicodeのデフォルトのケースフォールディング」]
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 mappings, 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 positives 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 positives and false negatives discussed in [RFC6943]. 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, application protocol designers 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 positives and false negatives 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 characters from the ASCII range; thus, they exclude spaces, characters with compatibility equivalents, and almost all symbols and punctuation marks. However, because such strings can still include so-called confusable characters (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 character. 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 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.
FreeformClassおよびその多くのプロファイルに準拠する文字列には、事実上すべてのUnicode文字を含めることができます。これにより、FreeformClassは非常に表現力豊かになりますが、ユーザーの混乱の可能性の観点からも問題が生じます。プロトコル設計者は、FreeformClassに理解できないコードポイントが含まれていることをここに警告し、可能な限りIdentifierClassをプロファイルすることをお勧めします。ただし、アプリケーションプロトコルがIdentifierClassで許可されているよりも多くのコードポイントを必要とする場合、プロトコル設計者は、許可されるコードポイントをできるだけ厳しく制限するFreeformClassのプロファイルを定義することをお勧めします。
(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.)
（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 the Simple Authentication and Security Layer (SASL) [RFC4422], that do not take local character sets into account.
システムがASCIIおよびUnicode以外のローカル文字セットを使用する場合、この仕様では、ローカル文字セットとUnicode間の変換の問題がアプリケーションまたはローカルシステムに残ります。異なるアプリケーション（または1つのアプリケーションの異なるバージョン）がコード化文字セット間の変換に関する異なるルールを実装する場合、それらは同じ名前を異なる方法で解釈し、異なるアプリケーションサーバーまたは他のネットワークエンティティに接続する可能性があります。この問題は、トランスポート層セキュリティ（TLS）[RFC5246]や単純認証およびセキュリティ層（SASL）[RFC4422]などのローカル文字セットを考慮しないセキュリティプロトコルでは解決されません。
Some characters 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. For 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 characters "STPETER" as they might appear when presented using a "creative" font family.
ただし、プロトコル文字列にすべてのUnicodeコードポイントを導入することで、問題はさらに深刻になります。たとえば、チェロキーブロックの文字U + 13DA U + 13A2 U + 13B5 U + 13AC U + 13A2 U + 13AC U + 13D2は、「クリエイティブ」を使用して表示されると表示される可能性があるため、ASCII文字「STPETER」に似ています。フォントファミリー。
In some examples 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 characters might be the real string and the string formed of ASCII characters 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 characters 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 characters from more than one script and SHOULD restrict registrations to characters 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）。そのようなポリシーは、登録されたアカウント名を書き込むために使用される言語とスクリプトによって通知される必要があります。特に、混乱を減らすために、サービスは複数のスクリプトからの文字を含む文字列の登録または保存を禁止し（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. Furthermore, because most languages are typically represented by a single script or a small set of scripts, and because most scripts are typically contained in one or more blocks of characters, the software SHOULD warn the user when presenting a string that mixes characters from more than one script or block, or that uses characters outside the normal range of the user's preferred language(s). (Such a recommendation is not intended to discourage communication across different communities of language users; instead, it recognizes the existence of such communities and encourages due caution when presenting unfamiliar scripts or characters to human users.)
2.ユーザー指向のアプリケーションソフトウェアは、国際化された文字列が人間のユーザーにどのように提示されるかを指定するポリシーを定義する必要があります（SHOULD）。そのようなソフトウェアのすべての人間のユーザーは優先言語または少数の優先言語を持っているので、ソフトウェアはユーザーから明示的に、またはユーザーのデバイスのオペレーティングシステムを介して暗黙的にその情報を収集する必要があります。さらに、ほとんどの言語は通常、単一のスクリプトまたは小さなスクリプトセットで表され、ほとんどのスクリプトは通常1つ以上の文字ブロックに含まれているため、複数の文字を混合した文字列を提示すると、ソフトウェアはユーザーに警告する必要があります（SHOULD）。 1つのスクリプトまたはブロック、またはユーザーの優先言語の通常の範囲外の文字を使用するもの。 （このような推奨事項は、言語ユーザーのさまざまなコミュニティ間のコミュニケーションを妨げることを意図したものではありません。代わりに、そのようなコミュニティの存在を認識し、不慣れなスクリプトや文字を人間のユーザーに提示する場合は十分な注意を促します。）
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 positives. 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 tradeoffs 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 the Simple Authentication and Security Layer [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つの例は、Simple Authentication and Security Layer [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, since the password is not available to the server in plaintext form.
パスワードをハッシュ関数などの暗号化アルゴリズムへの入力として提供するプロトコルでは、クライアントはアルゴリズムを適用する前にパスワードを適切に準備する必要があります。これは、パスワードがプレーンテキスト形式でサーバーから利用できないためです。
Further discussion of password handling can be found in [PRECIS-Users-Pwds].
パスワード処理の詳細については、[PRECIS-Users-Pwds]を参照してください。
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.
PRECISベースのアプリケーションプロトコルで使用される文字列は、多くの場合UTF-8 [RFC3629]を使用してエンコードされますが、正確なエンコーディングは、PRECISフレームワークではなく、PRECISを使用するアプリケーションプロトコルの問題です。
It is known that some existing systems are unable to support the full Unicode character set, or even any characters outside the ASCII range. If two (or more) applications need to interoperate when exchanging data (e.g., for the purpose of authenticating a username or password), they will naturally need to have in common at least one coded character set (as defined by [RFC6365]). Establishing such a baseline is a matter for the application protocol that uses PRECIS, not for the PRECIS framework.
既存のシステムの中には、完全なUnicode文字セットや、ASCII範囲外の文字をサポートできないものがあることがわかっています。 （たとえば、ユーザー名またはパスワードを認証する目的で）データを交換するときに2つ（またはそれ以上）のアプリケーションが相互運用する必要がある場合、当然、少なくとも1つのコード化文字セット（[RFC6365]で定義）を共有する必要があります。このようなベースラインの確立は、PRECISフレームワークではなく、PRECISを使用するアプリケーションプロトコルの問題です。
Changes to the properties of Unicode code points can occur as the Unicode Standard is modified from time to time. For example, three code points underwent changes in their GeneralCategory between Unicode 5.2 (current at the time IDNA2008 was originally published) and Unicode 6.0, as described in [RFC6452]. Implementers might need to be aware that the treatment of these characters differs depending on which version of Unicode is available on the system that is using IDNA2008 or PRECIS. Other such differences might arise between the version of Unicode current at the time of this writing (7.0) and future versions.
Unicode規格が随時変更されると、Unicodeコードポイントのプロパティが変更される可能性があります。たとえば、[RFC6452]で説明されているように、Unicode 5.2（IDNA2008が最初に公開された時点で現在）とUnicode 6.0の間のGeneralCategoryで3つのコードポイントが変更されました。実装者は、IDNA2008またはPRECISを使用しているシステムで使用可能なUnicodeのバージョンによって、これらの文字の扱いが異なることに注意する必要があります。このような執筆時点での現在のユニコードのバージョン（7.0）と将来のバージョンの間で、他のそのような違いが生じる可能性があります。
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 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 the following:
執筆時点では、これらの問題はまだ解決されていません。ただし、実装者は、これらの問題に対処するために、この仕様が将来更新される可能性があることを認識する必要があります。潜在的な変更には次のものがあります。
o The range of characters in the LetterDigits category (Sections 4.2.1 and 9.1) might be narrowed.
o LetterDigitsカテゴリー（セクション4.2.1および9.1）の文字の範囲が狭くなる可能性があります。
o Some characters 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 別の正規化方法が追加される場合があります。
Nevertheless, implementations and deployments that are sensitive to the advice given in this specification are unlikely to encounter significant problems as a consequence of these issues or potential changes -- specifically, the advice to use the more restrictive IdentifierClass whenever possible or, if using the FreeformClass, to allow only a restricted set of characters, particularly avoiding characters whose implications they do not actually understand.
それにもかかわらず、この仕様で与えられたアドバイスに敏感な実装と配備は、これらの問題や潜在的な変更の結果として重大な問題に遭遇する可能性は低いです。 、制限された文字セットのみを許可します。特に、その意味が実際に理解されていない文字は避けます。
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC20] Cerf、V。、「ネットワーク交換用のASCII形式」、STD 80、RFC 20、DOI 10.17487 / RFC0020、1969年10月、<http://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, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://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, <http://www.rfc-editor.org/info/rfc5198>.
[RFC5198] Klensin、J。およびM. Padlipsky、「Network InterchangeのUnicode形式」、RFC 5198、DOI 10.17487 / RFC5198、2008年3月、<http://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, <http://www.rfc-editor.org/info/rfc6365>.
[RFC6365] Hoffman、P。およびJ. Klensin、「IETFの国際化で使用される用語」、BCP 166、RFC 6365、DOI 10.17487 / RFC6365、2011年9月、<http://www.rfc-editor.org/info / rfc6365>。
[Unicode] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[Unicode] Unicodeコンソーシアム、「The Unicode Standard」、<http://www.unicode.org/versions/latest/>。
[Unicode7.0] The Unicode Consortium, "The Unicode Standard, Version 7.0.0", (Mountain View, CA: The Unicode Consortium, 2014 ISBN 978-1-936213-09-2), <http://www.unicode.org/versions/Unicode7.0.0/>.
[Unicode7.0] Unicodeコンソーシアム、「The Unicode Standard、Version 7.0.0 "、（Mountain View、CA：The Unicode Consortium、2014 ISBN 978-1-936213-09-2）、<http：// www。 unicode.org/versions/Unicode7.0.0/>。
[DerivedCoreProperties] The Unicode Consortium, "DerivedCoreProperties-7.0.0.txt", Unicode Character Database, February 2014, <http://www.unicode.org/Public/UCD/latest/ucd/ DerivedCoreProperties.txt>.
[DerivedCoreProperties] Unicodeコンソーシアム、「DerivedCoreProperties-7.0.0.txt」、Unicode Character Database、2014年2月、<http://www.unicode.org/Public/UCD/latest/ucd/ DerivedCoreProperties.txt>。
[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/correspondence-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月。
[PRECIS-Mappings] Yoneya, Y. and T. Nemoto, "Mapping characters for PRECIS classes", Work in Progress, draft-ietf-precis-mappings-10, May 2015.
[PRECIS-Mappings]米屋、Y、およびT.ネモト、「PRECISクラスの文字のマッピング」、作業中、draft-ietf-precis-mappings-10、2015年5月。
[PRECIS-Nickname] Saint-Andre, P., "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames", Work in Progress, draft-ietf-precis-nickname-17, April 2015.
[PRECIS-Nickname] Saint-Andre、P。、「ニックネームを表す国際化された文字列の準備、施行、比較」、進行中の作業、draft-ietf-precis-nickname-17、2015年4月。
[PRECIS-Users-Pwds] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", Work in Progress, draft-ietf-precis-saslprepbis-17, May 2015.
[PRECIS-Users-Pwds] Saint-Andre、P。およびA. Melnikov、「ユーザー名とパスワードを表す国際化された文字列の準備、施行、比較」、作業中、draft-ietf-precis-saslprepbis-17、2015年5月。
[PropertyAliases] The Unicode Consortium, "PropertyAliases-7.0.0.txt", Unicode Character Database, November 2013, <http://www.unicode.org/Public/UCD/latest/ucd/ PropertyAliases.txt>.
[PropertyAliases] Unicodeコンソーシアム、「PropertyAliases-7.0.0.txt」、Unicode Character Database、2013年11月、<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, <http://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月、<http：/ /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, <http://www.rfc-editor.org/info/rfc3454>.
[RFC3454] Hoffman、P.およびM. Blanchet、「Preparation of Internationalized Strings（ "stringprep"）」、RFC 3454、DOI 10.17487 / RFC3454、2002年12月、<http://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, <http://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月、<http：//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, <http://www.rfc-editor.org/info/rfc3491>.
[RFC3491] Hoffman、P。およびM. Blanchet、「Nameprep：国際化ドメイン名（IDN）のStringprepプロファイル」、RFC 3491、DOI 10.17487 / RFC3491、2003年3月、<http://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, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<http://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, <http://www.rfc-editor.org/info/rfc4422>.
[RFC4422] Melnikov、A.、Ed。およびK. Zeilenga、Ed。、 "Simple Authentication and Security Layer（SASL）"、RFC 4422、DOI 10.17487 / RFC4422、June 2006、<http：//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, <http://www.rfc-editor.org/info/rfc4510>.
[RFC4510] Zeilenga、K。、編、「ライトウェイトディレクトリアクセスプロトコル（LDAP）：技術仕様ロードマップ」、RFC 4510、DOI 10.17487 / RFC4510、2006年6月、<http://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, <http://www.rfc-editor.org/info/rfc4690>.
[RFC4690] Klensin、J.、Faltstrom、P.、Karp、C。、およびIAB、「レビューおよび国際化ドメイン名（IDN）の推奨事項」、RFC 4690、DOI 10.17487 / RFC4690、2006年9月、<http：// www.rfc-editor.org/info/rfc4690>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http：//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, <http://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月、<http://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, <http://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月、<http://www.rfc-editor.org/info/ rfc5890>。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <http://www.rfc-editor.org/info/rfc5891>.
[RFC5891] Klensin、J。、「Internationalized Domain Names in Applications（IDNA）：Protocol」、RFC 5891、DOI 10.17487 / RFC5891、2010年8月、<http://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, <http://www.rfc-editor.org/info/rfc5892>.
[RFC5892] Faltstrom、P。、編、「アプリケーションのUnicodeコードポイントと国際化ドメイン名（IDNA）」、RFC 5892、DOI 10.17487 / RFC5892、2010年8月、<http://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, <http://www.rfc-editor.org/info/rfc5893>.
[RFC5893] Alvestrand、H.、Ed。、C。Karp、「Right-to-Left Scripts for Internationalized Domain Names for Applications（IDNA）」、RFC 5893、DOI 10.17487 / RFC5893、2010年8月、<http：// 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, <http://www.rfc-editor.org/info/rfc5894>.
[RFC5894] Klensin、J。、「アプリケーションの国際化ドメイン名（IDNA）：背景、説明、および理論的根拠」、RFC 5894、DOI 10.17487 / RFC5894、2010年8月、<http://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, <http://www.rfc-editor.org/info/rfc5895>.
[RFC5895] Resnick、P。およびP. Hoffman、「アプリケーションの国際化ドメイン名のマッピング文字（IDNA）2008」、RFC 5895、DOI 10.17487 / RFC5895、2010年9月、<http://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, <http://www.rfc-editor.org/info/rfc6452>.
[RFC6452] Faltstrom、P。、編、およびP. Hoffman、編、「アプリケーションのUnicodeコードポイントと国際化ドメイン名（IDNA）-Unicode 6.0」、RFC 6452、DOI 10.17487 / RFC6452、2011年11月、< http://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, <http://www.rfc-editor.org/info/rfc6885>.
[RFC6885] Blanchet、M。およびA. Sullivan、「国際化された文字列（PRECIS）の準備と比較のためのStringprepの改訂と問題の説明」、RFC 6885、DOI 10.17487 / RFC6885、2013年3月、<http：//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, <http://www.rfc-editor.org/info/rfc6943>.
[RFC6943] Thaler、D。、編、「セキュリティ上の目的での識別子比較の問題」、RFC 6943、DOI 10.17487 / RFC6943、2013年5月、<http://www.rfc-editor.org/info/rfc6943>。
[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", 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/>。
[XMPP-Addr-Format] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Address Format", Work in Progress, draft-ietf-xmpp-6122bis-22, May 2015.
[XMPP-Addr-Format] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Address Format」、Work in Progress、draft-ietf-xmpp-6122bis-22、May 2015。
Acknowledgements
謝辞
The authors would like to acknowledge the comments and contributions of the following individuals during working group discussion: David Black, Edward Burns, Dan Chiba, Mark Davis, Alan DeKok, Martin Duerst, Patrik Faltstrom, Ted Hardie, Joe Hildebrand, Bjoern Hoehrmann, Paul Hoffman, Jeffrey Hutzelman, Simon Josefsson, John Klensin, Alexey Melnikov, Takahiro Nemoto, Yoav Nir, Mike Parker, Pete Resnick, Andrew Sullivan, Dave Thaler, Yoshiro Yoneya, and Florian Zeitz.
著者は、ワーキンググループディスカッション中に次の個人のコメントと貢献を認めたいと思います：David Black、Edward Burns、Dan Chiba、Mark Davis、Alan DeKok、Martin Duerst、Patrik Faltstrom、Ted Hardie、Joe Hildebrand、Bjoern Hoehrmann、Paulホフマン、ジェフリーハッツェルマン、サイモンジョセフソン、ジョンクレンシン、アレクセイメルニコフ、ネモカタカヒロ、ヨアフニル、マイクパーカー、ピートレズニック、アンドリューサリバン、デイブターラー、米谷芳郎、フロリアンツァイツ。
Special thanks are due to John Klensin and Patrik Faltstrom for their challenging feedback and detailed reviews.
難しいフィードバックと詳細なレビューを提供してくれたJohn KlensinとPatrik Faltstromに特に感謝します。
Charlie Kaufman, Tom Taylor, and Tim Wicinski reviewed the document on behalf of the Security Directorate, the General Area Review Team, and the Operations and Management Directorate, respectively.
Charlie Kaufman、Tom Taylor、およびTim Wicinskiは、それぞれセキュリティ総局、一般地域レビューチーム、および運用総局と総局を代表してこの文書をレビューしました。
During IESG review, Alissa Cooper, Stephen Farrell, and Barry Leiba provided comments that led to further improvements.
IESGのレビュー中に、アリッサクーパー、スティーブンファレル、バリーレイバは、さらなる改善につながるコメントを提供しました。
Some algorithms and textual descriptions have been borrowed from [RFC5892]. Some text regarding security has been borrowed from [RFC5890], [PRECIS-Users-Pwds], and [XMPP-Addr-Format].
いくつかのアルゴリズムとテキストによる説明は、[RFC5892]から借用されました。セキュリティに関する一部のテキストは、[RFC5890]、[PRECIS-Users-Pwds]、および[XMPP-Addr-Format]から借用されました。
Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for employing him during his work on earlier draft versions of this document.
Peter Saint-Andreは、このドキュメントの以前のドラフトバージョンでの作業中に彼を採用したCisco Systems、Inc.を認めたいと思います。
Authors' Addresses
著者のアドレス
Peter Saint-Andre &yet
ピーターサンタンドレ＆まだ
EMail: peter@andyet.com
URI: https://andyet.com/
Marc Blanchet Viagenie 246 Aberdeen Quebec, QC G1R 2E1 Canada
Marc Blanchet Viagenie 246 Aberdeen Quebec、QC G1R 2E1 Canada
EMail: Marc.Blanchet@viagenie.ca
URI: http://www.viagenie.ca/