[要約] RFC 8266は、国際化されたニックネームを準備、適用、比較するための手順を定義しています。その目的は、異なる言語や文字セットを使用するユーザー間でのニックネームの一貫性を確保することです。
Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 8266 Jabber.org
Obsoletes: 7700 October 2017
Category: Standards Track
ISSN: 2070-1721
Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames
ニックネームを表す国際化文字列の準備、施行、比較
Abstract
概要
This document describes methods for handling Unicode strings representing memorable, human-friendly names (called "nicknames", "display names", or "petnames") for people, devices, accounts, websites, and other entities. This document obsoletes RFC 7700.
このドキュメントでは、人、デバイス、アカウント、ウェブサイト、およびその他のエンティティの覚えやすい人間にわかりやすい名前（「ニックネーム」、「表示名」、または「ペットネーム」と呼ばれる）を表すUnicode文字列を処理する方法について説明します。このドキュメントはRFC 7700を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8266.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8266で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Nickname Profile . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Preparation . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Enforcement . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Comparison . . . . . . . . . . . . . . . . . . . . . . . 6
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Use in Application Protocols . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6.1. Authentication and Authorization . . . . . . . . . . . . 9
6.2. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 10
6.3. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 10
6.4. Visually Similar Characters . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Changes from RFC 7700 . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
A number of technologies and applications provide the ability for a person to choose a memorable, human-friendly name in a communications context or to set such a name for another entity such as a device, account, contact, or website. Such names are variously called "nicknames" (e.g., in chat room applications), "display names" (e.g., in Internet mail), or "petnames" (see [PETNAME-SYSTEMS]); for consistency, these are all called "nicknames" in this document.
数多くのテクノロジーとアプリケーションが、人が記憶に残る、人にやさしい名前を通信コンテキストで選択したり、デバイス、アカウント、連絡先、Webサイトなどの別のエンティティにそのような名前を設定する機能を提供します。このような名前は、「ニックネーム」（チャットルームアプリケーションなど）、「表示名」（インターネットメールなど）、または「ペットネーム」（[PETNAME-SYSTEMS]を参照）と呼ばれます。一貫性を保つため、このドキュメントではこれらをすべて「ニックネーム」と呼びます。
Nicknames are commonly supported in technologies for textual chat rooms, such as:
ニックネームは通常、次のようなテキストチャットルームのテクノロジでサポートされています。
o Internet Relay Chat (IRC) [RFC2811]
o インターネットリレーチャット（IRC）[RFC2811]
o The Message Session Relay Protocol (MSRP) [RFC4975] [RFC7701]
o メッセージセッションリレープロトコル（MSRP）[RFC4975] [RFC7701]
o Centralized Conferencing (XCON) [RFC5239] [XCON-SYSTEM]
o 集中会議（XCON）[RFC5239] [XCON-SYSTEM]
o The Extensible Messaging and Presence Protocol (XMPP) [RFC6120] [XEP-0045]
o Extensible Messaging and Presence Protocol（XMPP）[RFC6120] [XEP-0045]
Recent chat room technologies also allow internationalized nicknames because they support code points from outside the ASCII range [RFC20], typically by means of the Unicode coded character set [Unicode]. Although such nicknames tend to be used primarily for display purposes, they are sometimes used for programmatic purposes as well (e.g., kicking users out of a chat room or avoiding nickname conflicts).
最近のチャットルームテクノロジーでは、ASCII範囲外[RFC20]からのコードポイントをサポートするため、国際化されたニックネームも使用できます。これは、通常、Unicodeコード化文字セット[Unicode]を使用します。このようなニックネームは、主に表示目的で使用される傾向がありますが、プログラムの目的でも使用されることがあります（たとえば、ユーザーをチャットルームから追い出す、またはニックネームの競合を回避する）。
A similar usage enables a person to set their own preferred display name or to set a preferred display name for another user (e.g., the "display-name" construct in the Internet message format [RFC5322] and the <nick/> element in XMPP [XEP-0172]).
同様の使用法により、ユーザーは自分の優先表示名を設定したり、別のユーザーの優先表示名を設定したりできます（たとえば、インターネットメッセージ形式[RFC5322]の「display-name」構成とXMPPの<nick />要素） [XEP-0172]）。
Memorable, human-friendly names are also used in contexts other than personal messaging, such as names for devices (e.g., in a network visualization application), websites (e.g., for bookmarks in a web browser), accounts (e.g., in a web interface for a list of payees in a bank account), people (e.g., in a contact list application), and the like.
覚えやすい、人にやさしい名前は、デバイスの名前（例：ネットワーク可視化アプリケーション）、Webサイト（例：Webブラウザーのブックマーク）、アカウント（例：Web内）など、パーソナルメッセージング以外のコンテキストでも使用されます。銀行口座の受取人のリスト）、（連絡先リストアプリケーションの）人などのインターフェイス。
The rules specified in this document can be applied in all of the foregoing contexts.
このドキュメントで指定されているルールは、前述のすべてのコンテキストに適用できます。
It is important to understand that a nickname is a personally memorable name or handle for something that has a more stable, underlying identity, such as a URI or a file path. To ensure secure operation of applications that use nicknames, authentication and authorization decisions MUST be made on the basis of the thing's identity, not its nickname.
ニックネームは、個人的に覚えやすい名前、またはURIやファイルパスなど、より安定した基盤となるIDを持つハンドルであることを理解することが重要です。ニックネームを使用するアプリケーションの安全な操作を保証するために、認証と承認の決定は、ニックネームではなくモノのIDに基づいて行われる必要があります。
To increase the likelihood that memorable, human-friendly names will work in ways that make sense for typical users throughout the world, this document defines rules for handling nicknames in terms of the preparation, enforcement, and comparison of internationalized strings (PRECIS) framework specification [RFC8264].
覚えやすい、人にやさしい名前が世界中の一般的なユーザーにとって意味のある方法で機能する可能性を高めるために、このドキュメントでは、国際化文字列（PRECIS）フレームワーク仕様の準備、適用、比較に関してニックネームを処理するためのルールを定義します[RFC8264]。
Many important terms used in this document are defined in [RFC8264], [RFC6365], and [Unicode].
このドキュメントで使用される多くの重要な用語は、[RFC8264]、[RFC6365]、および[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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The following rules apply within the Nickname profile of the PRECIS FreeformClass defined in the PRECIS framework specification [RFC8264].
以下のルールは、PRECISフレームワーク仕様[RFC8264]で定義されているPRECIS FreeformClassのニックネームプロファイル内で適用されます。
1. Width Mapping Rule: There is no width mapping rule (such a rule is not necessary because width mapping is performed as part of normalization using Normalization Form KC (NFKC) as specified below).
1. 幅マッピングルール：幅マッピングルールはありません（幅マッピングは、下で指定されている正規化形式KC（NFKC）を使用した正規化の一部として実行されるため、このようなルールは必要ありません）。
2. Additional Mapping Rule: The additional mapping rule consists of the following sub-rules.
2. 追加のマッピングルール：追加のマッピングルールは、次のサブルールで構成されます。
a. Map any instances of non-ASCII space to SPACE (U+0020); a non-ASCII space is any Unicode code point having a general category of "Zs", naturally with the exception of SPACE (U+0020). (The inclusion of only ASCII space prevents confusion with various non-ASCII space code points, many of which are difficult to reproduce across different input methods.)
a. 非ASCIIスペースのインスタンスをSPACE（U + 0020）にマップします。非ASCIIスペースとは、スペース（U + 0020）を除いて、「Z」の一般的なカテゴリを持つ任意のUnicodeコードポイントです。 （ASCIIスペースのみを含めることで、ASCII以外のさまざまなスペースコードポイントとの混乱を防ぐことができます。その多くは、さまざまな入力方法で再現するのが困難です。）
b. Remove any instances of the ASCII space character at the beginning or end of a nickname (e.g., "stpeter " is mapped to "stpeter").
b. ニックネームの先頭または末尾にあるASCIIスペース文字のインスタンスを削除します（たとえば、「stpeter」は「stpeter」にマップされます）。
c. Map interior sequences of more than one ASCII space character to a single ASCII space character (e.g., "St Peter" is mapped to "St Peter").
c. 複数のASCIIスペース文字の内部シーケンスを単一のASCIIスペース文字にマップします（たとえば、「St Peter」は「St Peter」にマップされます）。
3. Case Mapping Rule: Apply the Unicode toLowerCase() operation, as defined in the Unicode Standard [Unicode]. In applications that prohibit conflicting nicknames, this rule helps to reduce the possibility of confusion by ensuring that nicknames differing only by case (e.g., "stpeter" vs. "StPeter") would not be presented to a human user at the same time. (As explained below, this is typically appropriate only for comparison, not for enforcement.)
3. ケースマッピングルール：Unicode標準[Unicode]で定義されているように、Unicode toLowerCase()操作を適用します。ニックネームの競合を禁止するアプリケーションでは、このルールは、大文字と小文字だけが異なるニックネーム（「stpeter」と「StPeter」など）が人間のユーザーに同時に表示されないようにすることで、混乱の可能性を減らすのに役立ちます。 （以下で説明するように、これは通常、比較のためだけに適切であり、強制ではありません。）
4. Normalization Rule: Apply Unicode Normalization Form KC. Because NFKC is more "aggressive" in finding matches than other normalization forms (in the terminology of Unicode, it performs both canonical and compatibility decomposition before recomposing code points), this rule helps to reduce the possibility of confusion by increasing the number of code points that would match; for example, the character "Ⅳ" (ROMAN NUMERAL FOUR, U+2163) would match the combination of "I" (LATIN CAPITAL LETTER I, U+0049) and "V" (LATIN CAPITAL LETTER V, U+0056).
4.正規化ルール：Unicode正規化フォームKCを適用します。 NFKCは他の正規化形式（Unicodeの用語では、コードポイントを再構成する前に正規分解と互換性分解の両方を実行します）よりも一致を見つけるのに「積極的」であるため、このルールはコードポイントの数を増やすことで混乱の可能性を減らすのに役立ちますそれは一致します。たとえば、文字「Ⅳ」（ローマ数字4、U + 2163）は、「I」（ラテン大文字I、U + 0049）と「V」（ラテン大文字V、U + 0056）の組み合わせに一致します。
5. Directionality Rule: There is no directionality rule. The "Bidi Rule" (defined in [RFC5893]) and similar rules are unnecessary and inapplicable to nicknames, because it is perfectly acceptable for a given nickname to be presented differently in different layout systems (e.g., a user interface that is configured to handle primarily a right-to-left script versus an interface that is configured to handle primarily a left-to-right script), as long as the presentation is consistent in any given layout system.
5. 方向性ルール：方向性ルールはありません。 「Bidiルール」（[RFC5893]で定義）および類似のルールは不要であり、ニックネームに適用できません。これは、特定のニックネームを異なるレイアウトシステム（たとえば、プレゼンテーションが特定のレイアウトシステムで一貫している限り、主に右から左へのスクリプトと、主に左から右へのスクリプトを処理するように構成されたインターフェイス）。
Implementation experience has shown that applying the rules for the Nickname profile is not an idempotent procedure for all code points. Therefore, an implementation SHOULD apply the rules repeatedly until the output string is stable; if the output string does not stabilize after reapplying the rules three (3) additional times after the first application, the implementation SHOULD terminate application of the rules and reject the input string as invalid.
実装経験から、ニックネームプロファイルのルールの適用は、すべてのコードポイントに対してべき等の手順ではないことがわかっています。したがって、実装は、出力文字列が安定するまでルールを繰り返し適用する必要があります（SHOULD）。最初の適用からさらに3回ルールを再適用しても出力文字列が安定しない場合、実装はルールの適用を終了し、入力文字列を無効として拒否する必要があります（SHOULD）。
An entity that prepares an input string for subsequent enforcement according to this profile MUST ensure that the string consists only of Unicode code points that conform to the FreeformClass string class defined in [RFC8264].
このプロファイルに従って後続の実施のために入力文字列を準備するエンティティは、文字列が[RFC8264]で定義されているFreeformClass文字列クラスに準拠するUnicodeコードポイントのみで構成されていることを確認する必要があります。
An entity that performs enforcement according to this profile MUST prepare an input string as described in Section 2.2 and MUST also apply the following rules specified in Section 2.1 in the order shown:
このプロファイルに従って施行を実行するエンティティは、セクション2.2で説明されているように入力文字列を準備しなければならず、セクション2.1で指定されている次のルールを、示されている順序で適用する必要があります。
1. Additional Mapping Rule 2. Normalization Rule
1. 追加のマッピングルール2.正規化ルール
Note: An entity SHOULD apply the Case Mapping Rule only during comparison.
注：エンティティは、比較時にのみケースマッピングルールを適用する必要があります。
After all of the foregoing rules have been enforced, the entity MUST ensure that the nickname is not zero bytes in length (this is done after enforcing the rules to prevent applications from mistakenly omitting a nickname entirely, because when internationalized strings are accepted a non-empty sequence of characters can result in a zero-length nickname after canonicalization).
前述のすべてのルールが適用された後、エンティティはニックネームの長さが0バイトではないことを確認する必要があります（これは、アプリケーションがニックネームを誤って完全に省略しないようにするルールを適用した後に行われます。空の文字シーケンスは、正規化後に長さがゼロのニックネームになる可能性があります）。
The result of the foregoing operations is an output string that conforms to the Nickname profile. Until an implementation produces such an output string, it MUST NOT treat the string as conforming (in particular, it MUST NOT assume that an input string is conforming before the enforcement operation has been completed).
前述の操作の結果は、ニックネームプロファイルに準拠した出力文字列になります。実装がそのような出力文字列を生成するまで、文字列を準拠しているものとして処理してはなりません（特に、強制操作が完了する前に入力文字列が準拠していると仮定してはなりません）。
An entity that performs comparison of two strings according to this profile MUST prepare each input string as specified in Section 2.2 and MUST apply the following rules specified in Section 2.1 in the order shown:
このプロファイルに従って2つの文字列の比較を実行するエンティティは、セクション2.2で指定されているように各入力文字列を準備しなければならず、セクション2.1で指定されている次のルールを示されている順序で適用する必要があります。
1. Additional Mapping Rule 2. Case Mapping Rule 3. Normalization Rule
1. 追加のマッピングルール2.ケースマッピングルール3.正規化ルール
The two strings are to be considered equivalent if and only if they are an exact octet-for-octet match (sometimes called "bit-string identity").
2つの文字列は、オクテットとオクテットが完全に一致する場合（「ビット文字列ID」と呼ばれることもある）に限り、同等と見なされます。
Until an implementation determines whether two strings are to be considered equivalent, it MUST NOT treat them as equivalent (in particular, it MUST NOT assume that two input strings are equivalent before the comparison operation has been completed).
実装が2つの文字列を同等と見なすかどうかを決定するまで、それらを同等と見なしてはなりません（特に、比較演算が完了する前に、2つの入力文字列が同等であると想定してはなりません）。
The following examples illustrate a small number of nicknames that are consistent with the format defined above, along with the output string resulting from application of the PRECIS rules for comparison purposes (note that the characters "<" and ">" are used to delineate the actual nickname and are not part of the nickname strings).
次の例は、上記で定義されたフォーマットと一致する少数のニックネームと、比較のためのPRECISルールの適用から得られる出力文字列を示しています（文字「<」と「>」は、実際のニックネームであり、ニックネーム文字列の一部ではありません）。
+---------------------------+-------------------------------------+
| # | Nickname | Output for Comparison |
+---------------------------+-------------------------------------+
| 1 | <Foo> | <foo> |
+---------------------------+-------------------------------------+
| 2 | <foo> | <foo> |
+---------------------------+-------------------------------------+
| 3 | <Foo Bar> | <foo bar> |
+---------------------------+-------------------------------------+
| 4 | <foo bar> | <foo bar> |
+---------------------------+-------------------------------------+
| 5 | <Σ> | σ (GREEK SMALL LETTER SIGMA, |
| | | U+03C3) |
+---------------------------+-------------------------------------+
| 6 | <σ> | σ (GREEK SMALL LETTER SIGMA, |
| | | U+03C3) |
+---------------------------+-------------------------------------+
| 7 | <ς> | ς (GREEK SMALL LETTER FINAL SIGMA, |
| | | U+03C2) |
+---------------------------+-------------------------------------+
| 8 | <ϔ> | ϋ (GREEK SMALL LETTER UPSILON |
| | | WITH DIALYTIKA, U+03CB) |
+---------------------------+-------------------------------------+
| 9 | <∞> | ∞ (INFINITY, U+221E) |
+---------------------------+-------------------------------------+
| 10 | <Richard Ⅳ> | <richard iv> |
+---------------------------+-------------------------------------+
Table 1: A Sample of Legal Nicknames
表1：法的なニックネームの例
Regarding examples 5, 6, and 7: applying the Unicode toLowerCase() operation to the character "Σ" (GREEK CAPITAL LETTER SIGMA, U+03A3) results in the character "σ" (GREEK SMALL LETTER SIGMA, U+03C3); however, the toLowerCase() operation does not modify the character "ς" (GREEK SMALL LETTER FINAL SIGMA, U+03C2). Therefore, the comparison operation defined in Section 2.4 would result in matching of the nicknames in examples 5 and 6 but not the nicknames in examples 5 and 7 or 6 and 7.
例5、6、7について：UnicodeのtoLowerCase()操作を文字「Σ」（ギリシャ語の大文字のシグマ、U + 03A3）に適用すると、文字「σ」（ギリシャ語の小文字のシグマ、U + 03C3）になります。ただし、toLowerCase()操作では文字「ς」は変更されません（ギリシャ語の小文字の最終シグマ、U + 03C2）。したがって、セクション2.4で定義されている比較操作では、例5と6のニックネームは一致しますが、例5と7または6と7のニックネームは一致しません。
Regarding example 8: this is an instance where applying the rules for the Nickname profile is not an idempotent procedure (see Section 2.1). In particular:
例8に関して：これは、ニックネームプロファイルのルールの適用がべき等の手順ではない場合です（セクション2.1を参照）。特に：
1. Applying toLowerCase() to the character "ϔ" (GREEK UPSILON WITH DIARESIS AND HOOK SYMBOL, U+03D4) results in no changes, and applying NFKC to that character results in the character "Ϋ" (GREEK CAPITAL LETTER UPSILON WITH DIALYTIKA, U+03AB).
1. toLowerCase()を文字 "ϔ"（ギリシャ語のUPSILON WITH DIARESIS AND HOOK SYMBOL、U + 03D4）に適用しても変更は発生せず、NFKCをその文字に適用すると文字 "Ϋ"（ギリシャ語の大文字UPSILON WITH DIALYTIKA、U）が適用されます。 + 03AB）。
2. Applying toLowerCase() to "Ϋ" (GREEK CAPITAL LETTER UPSILON WITH DIALYTIKA, U+03AB) results in the character "ϋ" (GREEK SMALL LETTER UPSILON WITH DIALYTIKA, U+03CB), and applying NFKC to that character results in no changes.
2. toLowerCase()を "Ϋ"（ギリシャ語の大文字のUPSILON WITH DIALYTIKA、U + 03AB）に適用すると、文字 "ϋ"（ギリシャ語の小文字のUPSILON WITH DIALYTIKA、U + 03CB）が適用され、その文字にNFKCを適用しても変更されません。
Regarding example 9: symbol characters such as "∞" (INFINITY, U+221E) are allowed by the PRECIS FreeformClass and thus can be used in nicknames.
例9について： "∞"（INFINITY、U + 221E）などの記号文字は、PRECIS FreeformClassで許可されているため、ニックネームで使用できます。
Regarding example 10: applying the Unicode toLowerCase() operation to the character "Ⅳ" (ROMAN NUMERAL FOUR, U+2163) results in the character "ⅳ" (SMALL ROMAN NUMERAL FOUR, U+2173), and applying NFKC to the character "ⅳ" (SMALL ROMAN NUMERAL FOUR, U+2173) results in the characters "i" (LATIN SMALL LETTER I, U+0069) and "v" (LATIN SMALL LETTER V, U+0076).
例10について：UnicodeのtoLowerCase()操作を文字 "Ⅳ"（ROMAN NUMERAL FOUR、U + 2163）に適用すると、文字 "ⅳ"（SMALL ROMAN NUMERAL FOUR、U + 2173）が生成され、NFKCが文字に適用されます。 "ⅳ"（小文字ローマ数字4、U + 2173）は、文字 "i"（ラテン小文字I、U + 0069）および "v"（ラテン小文字V、U + 0076）になります。
This specification defines only the PRECIS-based rules for handling of nickname strings. It is the responsibility of an application protocol (e.g., MSRP, XCON, or XMPP) or application definition to specify the protocol slots in which nickname strings can appear, the entities that are expected to enforce the rules governing nickname strings, and the point during protocol processing or interface handling when the rules need to be enforced. See Section 6 of [RFC8264] for guidelines about using PRECIS profiles in applications.
この仕様では、ニックネーム文字列を処理するためのPRECISベースのルールのみを定義しています。ニックネーム文字列を表示できるプロトコルスロット、ニックネーム文字列を管理するルールを適用することが期待されるエンティティ、およびポイントを指定するのは、アプリケーションプロトコル（MSRP、XCON、XMPPなど）またはアプリケーション定義の責任ですルールを適用する必要がある場合のプロトコル処理またはインターフェース処理。アプリケーションでのPRECISプロファイルの使用に関するガイドラインについては、[RFC8264]のセクション6を参照してください。
Above and beyond the PRECIS-based rules specified here, application protocols can also define application-specific rules governing nickname strings (rules regarding the minimum or maximum length of nicknames, further restrictions on allowable code points or character ranges, safeguards to mitigate the effects of visually similar characters, etc.).
ここで指定されたPRECISベースのルールに加えて、アプリケーションプロトコルは、ニックネーム文字列を管理するアプリケーション固有のルール（ニックネームの最小または最大長に関するルール、許容コードポイントまたは文字範囲に関するさらなる制限、影響を緩和するための保護手段）も定義できます。視覚的に類似した文字など）。
Naturally, application protocols can also specify rules governing the actual use of nicknames in applications (reserved nicknames, authorization requirements for using nicknames, whether certain nicknames can be prohibited, handling of duplicates, the relationship between nicknames and underlying identifiers such as SIP URIs or Jabber IDs, etc.).
当然、アプリケーションプロトコルは、アプリケーションでのニックネームの実際の使用を管理するルールも予約できます（予約されたニックネーム、ニックネームを使用するための許可要件、特定のニックネームを禁止できるかどうか、重複の処理、ニックネームとSIP URIやJabberなどの基礎となる識別子の関係） IDなど）。
Entities that enforce the rules specified in this document are encouraged to be liberal in what they accept by following this procedure:
このドキュメントで指定されているルールを適用するエンティティは、次の手順に従って、受け入れるものに寛大であることが推奨されます。
1. Where possible, map characters (e.g., through width mapping, additional mapping, case mapping, or normalization) and accept the mapped string.
1. 可能な場合は、文字をマッピングし（幅マッピング、追加のマッピング、大文字と小文字のマッピング、正規化など）、マッピングされた文字列を受け入れます。
2. If mapping is not possible (e.g., because a character is disallowed in the FreeformClass), reject the string.
2. マッピングが不可能な場合（たとえば、FreeformClassでは文字が許可されていないため）、文字列を拒否します。
IANA has added the following entry to the "PRECIS Profiles" registry:
IANAは、「PRECISプロファイル」レジストリに次のエントリを追加しました。
Name: Nickname.
名前：ニックネーム。
Base Class: FreeformClass.
基本クラス：FreeformClass。
Applicability: Nicknames or display names in messaging and text conferencing technologies; petnames for devices, accounts, and people; and other uses of nicknames, display names, or petnames.
適用範囲：メッセージングおよびテキスト会議テクノロジにおけるニックネームまたは表示名。デバイス、アカウント、および人物のペットの名前。愛称のニックネーム、表示名、その他の用途。
Replaces: None.
置き換え：なし。
Width Mapping Rule: None (handled via NFKC).
幅マッピングルール：なし（NFKCで処理）。
Additional Mapping Rule: Map non-ASCII space characters to SPACE (U+0020), strip leading and trailing space characters, and map interior sequences of multiple space characters to a single instance of SPACE (U+0020).
追加のマッピング規則：非ASCIIスペース文字をSPACE（U + 0020）にマップし、先頭と末尾のスペース文字を取り除き、複数のスペース文字の内部シーケンスをSPACEの単一インスタンス（U + 0020）にマップします。
Case Mapping Rule: Map uppercase and titlecase code points to lowercase using the Unicode toLowerCase() operation.
ケースマッピングルール：Unicode toLowerCase()オペレーションを使用して、大文字とタイトルケースのコードポイントを小文字にマッピングします。
Normalization Rule: NFKC.
正規化ルール：NFKC。
Directionality Rule: None.
方向性ルール：なし。
Enforcement: To be specified by applications.
実施：アプリケーションによって指定されます。
Specification: RFC 8266.
仕様：RFC 8266。
It is important to understand that a nickname is a personally memorable name or handle for something that has a more stable, underlying identity, such as a URI or a file path. To ensure secure operation of applications that use nicknames, authentication and authorization decisions MUST be made on the basis of the thing's identity, not its nickname.
ニックネームは、個人的に覚えやすい名前、またはURIやファイルパスなど、より安定した基盤となるIDを持つハンドルであることを理解することが重要です。ニックネームを使用するアプリケーションの安全な操作を保証するために、認証と承認の決定は、ニックネームではなくモノのIDに基づいて行われる必要があります。
The security considerations described in [RFC8264] apply to the FreeformClass string class used in this document for nicknames.
[RFC8264]で説明されているセキュリティの考慮事項は、このドキュメントでニックネームに使用されているFreeformClass文字列クラスに適用されます。
The security considerations described in [UTS39] apply to the use of Unicode code points in nicknames.
[UTS39]で説明されているセキュリティの考慮事項は、ニックネームでのUnicodeコードポイントの使用に適用されます。
[RFC8264] describes some of the security considerations related to visually similar characters, also called "confusable characters" or "confusables", and provides some examples of such characters.
[RFC8264]では、視覚的に類似した文字に関連するセキュリティ上の考慮事項について説明します。これは、「混乱する文字」または「混乱する文字」とも呼ばれ、そのような文字の例をいくつか示します。
Although the mapping rules defined in Section 2 of this document are designed, in part, to reduce the possibility of confusion about nicknames, this document does not provide more-detailed recommendations regarding the handling of visually similar characters, such as those provided in [UTS39].
このドキュメントのセクション2で定義されたマッピングルールは、ニックネームに関する混乱の可能性を減らすために部分的に設計されていますが、このドキュメントでは、[UTS39 ]。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010, <https://www.rfc-editor.org/info/rfc5893>.
[RFC5893]アルベストランド、H。、エド。およびC. Karp、「Right-to-Left Scripts for Internationalized Domain Names for Applications（IDNA）」、RFC 5893、DOI 10.17487 / RFC5893、2010年8月、<https://www.rfc-editor.org/info/rfc5893 >。
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, DOI 10.17487/RFC6365, September 2011, <https://www.rfc-editor.org/info/rfc6365>.
[RFC6365] Hoffman、P。およびJ. Klensin、「IETFの国際化で使用される用語」、BCP 166、RFC 6365、DOI 10.17487 / RFC6365、2011年9月、<https://www.rfc-editor.org/info / rfc6365>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8264] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 8264, DOI 10.17487/RFC8264, October 2017, <https://www.rfc-editor.org/info/rfc8264>.
[RFC8264] Saint-Andre、P。およびM. Blanchet、「PRECIS Framework：Preparation、Enforcement、and Comparison of Internationalized Strings in Application Protocols」、RFC 8264、DOI 10.17487 / RFC8264、2017年10月、<https：// www。 rfc-editor.org/info/rfc8264>。
[Unicode] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[Unicode] Unicodeコンソーシアム、「The Unicode Standard」、<http://www.unicode.org/versions/latest/>。
[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/>。
[Err4570] RFC Errata, Erratum ID 4570, RFC 7700, <https://www.rfc-editor.org/errata/eid4570>.
[Err4570] RFC Errata、Erratum ID 4570、RFC 7700、<https://www.rfc-editor.org/errata/eid4570>。
[PETNAME-SYSTEMS] Stiegler, M., "An Introduction to Petname Systems", updated June 2010, February 2005, <http://www.skyhunter.com/marcs/petnames/ IntroPetNames.html>.
[PETNAME-SYSTEMS] Stiegler、M。、「An Introduction to Petname Systems」、2010年6月、2005年2月更新、<http://www.skyhunter.com/marcs/petnames/ IntroPetNames.html>。
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/info/rfc20>.
[RFC20] Cerf、V。、「ネットワーク交換用のASCII形式」、STD 80、RFC 20、DOI 10.17487 / RFC0020、1969年10月、<https://www.rfc-editor.org/info/rfc20>。
[RFC2811] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, DOI 10.17487/RFC2811, April 2000, <https://www.rfc-editor.org/info/rfc2811>.
[RFC2811] Kalt、C。、「インターネットリレーチャット：チャネル管理」、RFC 2811、DOI 10.17487 / RFC2811、2000年4月、<https://www.rfc-editor.org/info/rfc2811>。
[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, DOI 10.17487/RFC4975, September 2007, <https://www.rfc-editor.org/info/rfc4975>.
[RFC4975] Campbell、B.、Ed。、Mahy、R.、Ed。、and C. Jennings、Ed。、 "The Message Session Relay Protocol（MSRP）"、RFC 4975、DOI 10.17487 / RFC4975、September 2007、< https://www.rfc-editor.org/info/rfc4975>。
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, DOI 10.17487/RFC5239, June 2008, <https://www.rfc-editor.org/info/rfc5239>.
[RFC5239] Barnes、M.、Boulton、C。、およびO. Levin、「集中型会議のためのフレームワーク」、RFC 5239、DOI 10.17487 / RFC5239、2008年6月、<https://www.rfc-editor.org/ info / rfc5239>。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、DOI 10.17487 / RFC5322、2008年10月、<https://www.rfc-editor.org/info/rfc5322>。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC6120] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Core」、RFC 6120、DOI 10.17487 / RFC6120、2011年3月、<https://www.rfc-editor.org/info/rfc6120 >。
[RFC7700] Saint-Andre, P., "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames", RFC 7700, DOI 10.17487/RFC7700, December 2015, <https://www.rfc-editor.org/info/rfc7700>.
[RFC7700] Saint-Andre、P。、「ニックネームを表す国際化された文字列の準備、施行、比較」、RFC 7700、DOI 10.17487 / RFC7700、2015年12月、<https://www.rfc-editor.org/info/ rfc7700>。
[RFC7701] Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi-party Chat Using the Message Session Relay Protocol (MSRP)", RFC 7701, DOI 10.17487/RFC7701, December 2015, <https://www.rfc-editor.org/info/rfc7701>.
[RFC7701] Niemi、A.、Garcia-Martin、M。、およびG. Sandbakken、「メッセージセッションリレープロトコル（MSRP）を使用したマルチパーティチャット」、RFC 7701、DOI 10.17487 / RFC7701、2015年12月、<https： //www.rfc-editor.org/info/rfc7701>。
[XCON-SYSTEM] Barnes, M., Boulton, C., and S. Loreto, "Chatrooms within a Centralized Conferencing (XCON) System", Work in Progress, draft-boulton-xcon-session-chat-08, July 2012.
[XCON-SYSTEM] Barnes、M.、Boulton、C。、およびS. Loreto、「集中会議（XCON）システム内のチャットルーム」、作業中、draft-boulton-xcon-session-chat-08、2012年7月。
[XEP-0045] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, September 2017, <https://xmpp.org/extensions/xep-0045.html>.
[XEP-0045] Saint-Andre、P。、「マルチユーザーチャット」、XSF XEP 0045、2017年9月、<https://xmpp.org/extensions/xep-0045.html>。
[XEP-0172] Saint-Andre, P. and V. Mercier, "User Nickname", XSF XEP 0172, March 2012, <https://xmpp.org/extensions/xep-0172.html>.
[XEP-0172] Saint-Andre、P。およびV. Mercier、「User Nickname」、XSF XEP 0172、2012年3月、<https://xmpp.org/extensions/xep-0172.html>。
The following changes were made from [RFC7700].
[RFC7700]から次の変更が行われました。
o Addressed [Err4570] by removing the directionality rule from Sections 2.3 and 2.4.
o セクション2.3および2.4から方向性ルールを削除することにより、[Err4570]に対処しました。
o In accordance with working group discussions and updates to [RFC8264], removed the use of the Unicode toCaseFold() operation in favor of the Unicode toLowerCase() operation.
o ワーキンググループの議論と[RFC8264]の更新に従い、Unicode toLowerCase()操作を優先して、Unicode toCaseFold()操作の使用を削除しました。
o Clarified several editorial matters.
o いくつかの編集上の問題を明確にしました。
o Updated references.
o 更新された参照。
Acknowledgements
謝辞
Thanks to William Fisher for his implementation feedback, especially regarding idempotence.
特にべき等に関するウィリアム・フィッシャーの実装フィードバックをありがとう。
Thanks to Sam Whited for his feedback and for submitting [Err4570].
彼のフィードバックと[Err4570]を提出してくれたSam Whitedに感謝します。
See [RFC7700] for acknowledgements related to the specification that this document supersedes.
このドキュメントが優先する仕様に関連する謝辞については、[RFC7700]を参照してください。
Author's Address
著者のアドレス
Peter Saint-Andre Jabber.org P.O. Box 787 Parker, CO 80134 United States of America
Peter Saint-Andre Jabber.org P.O. Box 787 Parker、CO 80134アメリカ合衆国
Phone: +1 720 256 6756
Email: stpeter@jabber.org
URI: https://www.jabber.org/