[要約] RFC 6885は、国際化された文字列の準備と比較のためのStringprepの改訂と問題の声明をまとめたものです。その目的は、国際化された文字列の正規化と比較のための一貫した手法を提供することです。
Internet Engineering Task Force (IETF) M. Blanchet
Request for Comments: 6885 Viagenie
Category: Informational A. Sullivan
ISSN: 2070-1721 Dyn, Inc.
March 2013
Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS)
国際化された文字列（PRECIS）の準備と比較のためのStringprepの改訂と問題の説明
Abstract
概要
If a protocol expects to compare two strings and is prepared only for those strings to be ASCII, then using Unicode code points in those strings requires they be prepared somehow. Internationalizing Domain Names in Applications (here called IDNA2003) defined and used Stringprep and Nameprep. Other protocols subsequently defined Stringprep profiles. A new approach different from Stringprep and Nameprep is used for a revision of IDNA2003 (called IDNA2008). Other Stringprep profiles need to be similarly updated, or a replacement of Stringprep needs to be designed. This document outlines the issues to be faced by those designing a Stringprep replacement.
プロトコルが2つの文字列を比較することを期待し、それらの文字列のみがASCIIになるように準備されている場合、それらの文字列でUnicodeコードポイントを使用するには、何らかの方法で準備する必要があります。アプリケーション（ここではIDNA2003と呼ばれます）の国際化ドメイン名は、StringprepとNameprepを定義して使用しました。その後、他のプロトコルでStringprepプロファイルが定義されました。 StringprepおよびNameprepとは異なる新しいアプローチがIDNA2003（IDNA2008と呼ばれる）のリビジョンに使用されます。他のStringprepプロファイルも同様に更新する必要があるか、Stringprepの代替品を設計する必要があります。このドキュメントでは、Stringprepの代替を設計する人が直面する問題について概説します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc6885.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6885で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Stringprep Profiles Limitations . . . . . . . . . . . . . . . 6
5. Major Topics for Consideration . . . . . . . . . . . . . . . . 8
5.1. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1.1. Types of Identifiers . . . . . . . . . . . . . . . . . 8
5.1.2. Effect of Comparison . . . . . . . . . . . . . . . . . 8
5.2. Dealing with Characters . . . . . . . . . . . . . . . . . 9
5.2.1. Case Folding, Case Sensitivity, and Case
Preservation . . . . . . . . . . . . . . . . . . . . . 9
5.2.2. Stringprep and NFKC . . . . . . . . . . . . . . . . . 9
5.2.3. Character Mapping . . . . . . . . . . . . . . . . . . 10
5.2.4. Prohibited Characters . . . . . . . . . . . . . . . . 10
5.2.5. Internal Structure, Delimiters, and Special
Characters . . . . . . . . . . . . . . . . . . . . . . 10
5.2.6. Restrictions Because of Glyph Similarity . . . . . . . 11
5.3. Where the Data Comes from and Where It Goes . . . . . . . 11
5.3.1. User Input and the Source of Protocol Elements . . . . 11
5.3.2. User Output . . . . . . . . . . . . . . . . . . . . . 12
5.3.3. Operations . . . . . . . . . . . . . . . . . . . . . . 12
6. Considerations for Stringprep Replacement . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. Informative References . . . . . . . . . . . . . . . . . . . . 15
Appendix A. Classification of Stringprep Profiles . . . . . . . . 19
Appendix B. Evaluation of Stringprep Profiles . . . . . . . . . . 19
B.1. iSCSI Stringprep Profile: RFC 3720, RFC 3721, RFC 3722 . . 19
B.2. SMTP/POP3/ManageSieve Stringprep Profiles: RFC 4954,
RFC 5034, RFC 5804 . . . . . . . . . . . . . . . . . . . . 21
B.3. IMAP Stringprep Profiles for Usernames: RFC 4314, RFC
5738 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
B.4. IMAP Stringprep Profiles for Passwords: RFC 5738 . . . . . 26
B.5. Anonymous SASL Stringprep Profiles: RFC 4505 . . . . . . . 28
B.6. XMPP Stringprep Profiles for Nodeprep: RFC 3920 . . . . . 30
B.7. XMPP Stringprep Profiles for Resourceprep: RFC 3920 . . . 31
B.8. EAP Stringprep Profiles: RFC 3748 . . . . . . . . . . . . 33
Internationalizing Domain Names in Applications (here called IDNA2003) [RFC3490] [RFC3491] [RFC3492] and [RFC3454] describes a mechanism for encoding Unicode labels that make up the Internationalized Domain Names (IDNs) as standard DNS labels. The labels were processed using a method called Nameprep [RFC3491] and Punycode [RFC3492]. That method was specific to IDNA2003 but is generalized as Stringprep [RFC3454]. The general mechanism is used by other protocols with similar needs but with different constraints than IDNA2003.
アプリケーションのドメイン名の国際化（ここではIDNA2003）[RFC3490] [RFC3491] [RFC3492]および[RFC3454]は、国際化ドメイン名（IDN）を標準DNSラベルとして構成するUnicodeラベルをエンコードするメカニズムについて説明しています。ラベルは、Nameprep [RFC3491]およびPunycode [RFC3492]と呼ばれる方法を使用して処理されました。その方法はIDNA2003に固有でしたが、Stringprep [RFC3454]として一般化されています。一般的なメカニズムは、同様のニーズを持つ他のプロトコルで使用されますが、IDNA2003とは制約が異なります。
Stringprep defines a framework within which protocols define their Stringprep profiles. Some known IETF specifications using Stringprep are listed below:
Stringprepは、プロトコルがStringprepプロファイルを定義するフレームワークを定義します。 Stringprepを使用したいくつかの既知のIETF仕様を以下に示します。
o The Nameprep profile [RFC3490] for use in Internationalized Domain Names (IDNs);
o 国際化ドメイン名（IDN）で使用するNameprepプロファイル[RFC3490]。
o The Inter-Asterisk eXchange (IAX) using Nameprep [RFC5456];
o Nameprep [RFC5456]を使用したInter-Asterisk eXchange（IAX）。
o NFSv4 [RFC3530] and NFSv4.1 [RFC5661];
o NFSv4 [RFC3530]およびNFSv4.1 [RFC5661];
o The Internet Small Computer System Interface (iSCSI) profile [RFC3722] for use in iSCSI names;
o iSCSI名で使用するためのInternet Small Computer System Interface（iSCSI）プロファイル[RFC3722]。
o The Extensible Authentication Protocol (EAP) [RFC3748];
o 拡張認証プロトコル（EAP）[RFC3748];
o The Nodeprep and Resourceprep profiles [RFC3920] (which was obsoleted by [RFC6120]) for use in the Extensible Messaging and Presence Protocol (XMPP), and the XMPP to Common Presence and Instant Messaging (CPIM) mapping [RFC3922] (the latter of these relies on the former);
o NodeprepおよびResourceprepプロファイル[RFC3920]（[RFC6120]によって廃止）、およびExtensible Messaging and Presence Protocol（XMPP）、およびXMPPからCommon Presence and Instant Messaging（CPIM）へのマッピング[RFC3922]（後者の後者）これらは前者に依存しています。
o The Internationalized Resource Identifier (IRI) and URI in XMPP [RFC5122];
o XMPP [RFC5122]の国際化リソース識別子（IRI）およびURI。
o The Policy MIB profile [RFC4011] for use in the Simple Network Management Protocol (SNMP);
o 簡易ネットワーク管理プロトコル（SNMP）で使用するポリシーMIBプロファイル[RFC4011]。
o Transport Layer Security (TLS) [RFC4279];
o トランスポート層セキュリティ（TLS）[RFC4279];
o The Lightweight Directory Access Protocol (LDAP) profile [RFC4518] for use with LDAP [RFC4511] and its authentication methods [RFC4513];
o LDAP [RFC4511]およびその認証方法[RFC4513]で使用するためのライトウェイトディレクトリアクセスプロトコル（LDAP）プロファイル[RFC4518]。
o PKIX subject identification using LDAPprep [RFC4683];
o LDAPprepを使用したPKIXサブジェクト識別[RFC4683];
o PKIX Certificate Revocation List (CRL) using LDAPprep [RFC5280];
o LDAPprepを使用したPKIX証明書失効リスト（CRL）[RFC5280];
o The Simple Authentication and Security Layer (SASL) [RFC4422] and SASLprep profile [RFC4013] for use in SASL;
o SASLで使用するためのSimple Authentication and Security Layer（SASL）[RFC4422]およびSASLprepプロファイル[RFC4013]。
o Plain SASL using SASLprep [RFC4616];
o SASLprepを使用したプレーンSASL [RFC4616];
o SMTP Auth using SASLprep [RFC4954];
o SASLprepを使用したSMTP認証[RFC4954];
o The Post Office Protocol (POP3) Auth using SASLprep [RFC5034];
o SASLprepを使用したPost Office Protocol（POP3）認証[RFC5034];
o TLS Secure Remote Password (SRP) using SASLprep [RFC5054];
o SASLprep [RFC5054]を使用したTLSセキュアリモートパスワード（SRP）;
o SASL Salted Challenge Response Authentication Mechanism (SCRAM) using SASLprep [RFC5802];
o SASLprepを使用したSASLソルトチャレンジレスポンス認証メカニズム（SCRAM）[RFC5802];
o Remote management of Sieve using SASLprep [RFC5804];
o SASLprep [RFC5804]を使用したSieveのリモート管理。
o The Network News Transfer Protocol (NNTP) using SASLprep [RFC4643];
o SASLprepを使用したネットワークニュース転送プロトコル（NNTP）[RFC4643];
o IMAP4 using SASLprep [RFC4314];
o SASLprepを使用したIMAP4 [RFC4314];
o The trace profile [RFC4505] for use with the SASL ANONYMOUS mechanism;
o SASL ANONYMOUSメカニズムで使用するトレースプロファイル[RFC4505]。
o Internet Application Protocol Collation Registry [RFC4790];
o インターネットアプリケーションプロトコル照合レジストリ[RFC4790];
o The unicode-casemap Unicode Collation [RFC5051].
o unicode-casemap Unicode Collation [RFC5051]。
However, a review (see [78PRECIS]) of these protocol specifications found that they are very similar and can be grouped into a short number of classes. Moreover, many reuse the same Stringprep profile, such as the SASL one.
しかし、これらのプロトコル仕様のレビュー（[78PRECIS]を参照）は、それらが非常に類似しており、少数のクラスにグループ化できることを発見しました。さらに、SASLのプロファイルのように、多くは同じStringprepプロファイルを再利用します。
IDNA2003 was replaced because of some limitations described in [RFC4690]. The new IDN specification, called IDNA2008 [RFC5890], [RFC5891], [RFC5892], [RFC5893] was designed based on the considerations found in [RFC5894]. One of the effects of IDNA2008 is that Nameprep and Stringprep are not used at all. Instead, an algorithm based on Unicode properties of code points is defined. That algorithm generates a stable and complete table of the supported Unicode code points for each Unicode version. This algorithm uses an inclusion-based approach, instead of the exclusion-based approach of Stringprep/Nameprep. That is, IDNA2003 created an explicit list of excluded or mapped-away characters; anything in Unicode 3.2 that was not so listed could be assumed to be allowed under the protocol.
IDNA2003は、[RFC4690]で説明されているいくつかの制限のために置き換えられました。 IDNA2008 [RFC5890]、[RFC5891]、[RFC5892]、[RFC5893]と呼ばれる新しいIDN仕様は、[RFC5894]にある考慮事項に基づいて設計されました。 IDNA2008の効果の1つは、NameprepとStringprepがまったく使用されないことです。代わりに、コードポイントのUnicodeプロパティに基づくアルゴリズムが定義されています。このアルゴリズムは、各UnicodeバージョンでサポートされているUnicodeコードポイントの安定した完全なテーブルを生成します。このアルゴリズムは、Stringprep / Nameprepの除外ベースのアプローチではなく、包含ベースのアプローチを使用します。つまり、IDNA2003は除外またはマッピングされた文字の明示的なリストを作成しました。このようにリストされていないUnicode 3.2のすべては、プロトコルで許可されていると想定できます。
IDNA2008 begins instead from the assumption that code points are disallowed and then relies on Unicode properties to derive whether a given code point actually is allowed in the protocol.
IDNA2008は、コードポイントが許可されていないという前提から始まり、Unicodeプロパティに依存して、特定のコードポイントがプロトコルで実際に許可されているかどうかを導出します。
This document lists the shortcomings and issues found by protocols listed above that defined Stringprep profiles. It also lists the requirements for any potential replacement of Stringprep.
このドキュメントでは、上記のプロトコルで検出されたStringprepプロファイルを定義した欠点と問題を示します。また、Stringprepの潜在的な置き換えの要件も示します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 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」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document uses various internationalization terms, which are defined and discussed in [RFC6365].
このドキュメントでは、[RFC6365]で定義および説明されているさまざまな国際化用語を使用しています。
Additionally, this document defines the following keyword:
さらに、このドキュメントでは次のキーワードを定義しています。
PRECIS: Preparation and Comparison of Internationalized Strings
PRECIS：国際化文字列の準備と比較
A single Unicode code point in this memo is denoted by "U+" followed by four to six hexadecimal digits, as used in [Unicode61], Appendix A.
このメモの単一のUnicodeコードポイントは、[Unicode61]の付録Aで使用されているように、4〜6桁の16進数が後に続く「U +」で示されます。
During IETF 77 (March 2010), a BOF discussed the current state of the protocols that have defined Stringprep profiles [NEWPREP]. The main conclusions from that discussion were as follows:
IETF 77（2010年3月）の間に、BOFはStringprepプロファイル[NEWPREP]を定義したプロトコルの現在の状態について議論しました。その議論からの主な結論は以下の通りでした：
o Stringprep is bound to Version 3.2 of Unicode. Stringprep has not been updated to new versions of Unicode. Therefore, the protocols using Stringprep are stuck at Unicode 3.2, and their specifications need to be updated to support new versions of Unicode.
o StringprepはUnicodeバージョン3.2にバインドされています。 Stringprepは新しいバージョンのUnicodeに更新されていません。したがって、Stringprepを使用するプロトコルはUnicode 3.2のままであり、新しいバージョンのUnicodeをサポートするように仕様を更新する必要があります。
o The protocols would like to not be bound to a specific version of Unicode, but rather have better Unicode version agility in the way of IDNA2008. This is important partly because it is usually impossible for an application to require Unicode 3.2; the application gets whatever version of Unicode is available on the host.
o プロトコルは、特定のバージョンのUnicodeに拘束されるのではなく、IDNA2008の方法でUnicodeバージョンの俊敏性を高めたいと考えています。アプリケーションがUnicode 3.2を必要とすることは通常不可能であるため、これは重要なことです。アプリケーションは、ホストで使用可能なUnicodeのバージョンを取得します。
o The protocols require better bidirectional support (bidi) than currently offered by Stringprep.
o プロトコルには、現在Stringprepで提供されているものよりも優れた双方向サポート（bidi）が必要です。
o If the protocols are updated to use a new version of Stringprep or another framework, then backward compatibility is an important requirement. For example, Stringprep normalization is based on and profiles may use Unicode Normalization Form KC (NFKC) [UAX15], while IDNA2008 mostly uses Unicode Normalization Form C (NFC) [UAX15].
o 新しいバージョンのStringprepまたは別のフレームワークを使用するようにプロトコルを更新する場合、下位互換性は重要な要件です。たとえば、Stringprep正規化はに基づいており、プロファイルはUnicode正規化形式KC（NFKC）[UAX15]を使用できますが、IDNA2008は主にUnicode正規化形式C（NFC）[UAX15]を使用します。
o Identifiers are passed between protocols. For example, the same username string of code points may be passed between SASL, XMPP, LDAP, and EAP. Therefore, a common set of rules or classes of strings are preferred over specific rules for each protocol. Without real planning in advance, many Stringprep profiles reuse other profiles, so this goal was accomplished by accident with Stringprep.
o 識別子はプロトコル間で渡されます。たとえば、SASL、XMPP、LDAP、EAPの間で同じコードポイントのユーザー名文字列を渡すことができます。したがって、各プロトコルの特定のルールよりも、ルールの共通セットまたは文字列のクラスが優先されます。多くのStringprepプロファイルは事前の実際の計画なしに他のプロファイルを再利用するため、この目標はStringprepで偶然に達成されました。
Protocols that use Stringprep profiles use strings for different purposes:
Stringprepプロファイルを使用するプロトコルは、さまざまな目的で文字列を使用します。
o XMPP uses a different Stringprep profile for each part of the XMPP address Jabber Identifier (JID): a localpart, which is similar to a username and used for authentication; a domainpart, which is a domain name; and a resourcepart, which is less restrictive than the localpart.
o XMPPは、XMPPアドレスJabber Identifier（JID）の各部分に異なるStringprepプロファイルを使用します。ローカル部分は、ユーザー名に似ており、認証に使用されます。ドメイン名であるdomainpart。そして、ローカルパートよりも制限が少ないリソースパート。
o iSCSI uses a Stringprep profile for the names of protocol participants (called initiators and targets). The iSCSI Qualified Name (IQN) format of iSCSI names contains a reversed DNS domain name.
o iSCSIは、プロトコル参加者（イニシエーターおよびターゲットと呼ばれる）の名前にStringprepプロファイルを使用します。 iSCSI名のiSCSI修飾名（IQN）形式には、逆引きされたDNSドメイン名が含まれています。
o SASL and LDAP use a Stringprep profile for usernames.
o SASLとLDAPは、ユーザー名にStringprepプロファイルを使用します。
o LDAP uses a set of Stringprep profiles.
o LDAPは一連のStringprepプロファイルを使用します。
The apparent judgement of the BOF attendees [NEWPREP] was that it would be highly desirable to have a replacement of Stringprep, with similar characteristics to IDNA2008. That replacement should be defined so that the protocols could use internationalized strings without a lot of specialized internationalization work, since internationalization expertise is not available in the respective protocols or working groups. Accordingly, the IESG formed the PRECIS working group to undertake the task.
BOFの参加者[NEWPREP]の明らかな判断は、IDNA2008と同様の特徴を持つStringprepの交換が非常に望ましいということでした。それぞれのプロトコルやワーキンググループでは国際化の専門知識を利用できないため、プロトコルが国際化された文字列を専門の国際化作業なしで使用できるように、その置換を定義する必要があります。したがって、IESGはPRECISワーキンググループを結成して、このタスクに着手しました。
Notwithstanding the desire evident in [NEWPREP] and the chartering of a working group, IDNA2008 may be a poor model for what other protocols ought to do, because it is designed to support an old protocol that is designed to operate on the scale of the entire Internet. Moreover, IDNA2008 is intended to be deployed without any change to the base DNS protocol. Other protocols may aim at deployment in more local environments, or may have protocol version negotiation built in.
[NEWPREP]で明らかな要望とワーキンググループの設立にもかかわらず、IDNA2008は、全体の規模で動作するように設計された古いプロトコルをサポートするように設計されているため、他のプロトコルが行うべきことには不十分なモデルになる可能性があります。インターネット。さらに、IDNA2008は、基本DNSプロトコルを変更せずに展開することを目的としています。その他のプロトコルは、よりローカルな環境での展開を目的としている場合や、プロトコルバージョンのネゴシエーションが組み込まれている場合があります。
This section provides an overview of major topics that a Stringprep replacement needs to address. The headings correspond roughly with categories under which known Stringprep-using protocol RFCs have been evaluated. For the details of those evaluations, see Appendix A.
このセクションでは、Stringprepの置き換えで対処する必要がある主要なトピックの概要を説明します。見出しは、既知のStringprepを使用するプロトコルRFCが評価されたカテゴリにほぼ対応しています。これらの評価の詳細については、付録Aを参照してください。
Following [ID-COMP], it is possible to organize identifiers into three classes in respect of how they may be compared with one another:
[ID-COMP]に続いて、識別子を比較する方法に関して、識別子を3つのクラスに編成することができます。
Absolute Identifiers: Identifiers that can be compared byte-by-byte for equality.
絶対識別子：バイトごとに等しいかどうかを比較できる識別子。
Definite Identifiers: Identifiers that have a well-defined comparison algorithm on which all parties agree.
明確な識別子：すべての関係者が同意する明確に定義された比較アルゴリズムを持つ識別子。
Indefinite Identifiers: Identifiers that have no single comparison algorithm on which all parties agree.
不明確な識別子：すべての関係者が同意する単一の比較アルゴリズムを持たない識別子。
Definite Identifiers include cases like the comparison of Unicode code points in different encodings: they do not match byte for byte but can all be converted to a single encoding which then does match byte for byte. Indefinite Identifiers are sometimes algorithmically comparable by well-specified subsets of parties. For more discussion of these categories, see [ID-COMP].
明確な識別子には、さまざまなエンコーディングでのUnicodeコードポイントの比較などのケースが含まれます。これらはバイトごとに一致しませんが、すべてバイトごとに一致する単一のエンコーディングに変換できます。不明確な識別子は、明確に指定されたパーティのサブセットによってアルゴリズム的に比較できる場合があります。これらのカテゴリの詳細については、[ID-COMP]を参照してください。
The section on treating the existing known cases, Appendix A, uses the categories above.
既存の既知のケースの処理に関するセクション、付録Aでは、上記のカテゴリを使用しています。
The three classes of comparison style outlined in Section 5.1.1 may have different effects when applied. It is necessary to evaluate the effects if a comparison results in a false positive or a false negative, especially in terms of the consequences to security and usability.
セクション5.1.1で概説されている3つの比較スタイルのクラスは、適用したときに異なる効果をもたらす可能性があります。比較の結果、特にセキュリティとユーザビリティへの影響に関して、誤検知または誤検知が発生した場合の影響を評価する必要があります。
This section outlines a range of issues having to do with characters in the target protocols, the ways in which IDNA2008 might be a good analogy to other protocols, and ways in which it might be a poor one.
このセクションでは、ターゲットプロトコルの文字に関するさまざまな問題、IDNA2008が他のプロトコルとよく似ている可能性がある方法、およびIDNA2008がそうでない可能性がある方法について概説します。
In IDNA2003, labels are always mapped to lowercase before the Punycode transformation. In IDNA2008, there is no mapping at all: input is either a valid U-label or it is not. At the same time, uppercase characters are by definition not valid U-labels, because they fall into the Unstable category (category B) of [RFC5892].
IDNA2003では、ラベルは常にPunycode変換の前に小文字にマップされます。 IDNA2008では、マッピングはまったくありません。入力は有効なUラベルであるか、そうではありません。同時に、大文字は[RFC5892]の不安定なカテゴリ（カテゴリB）に分類されるため、定義上、有効なUラベルではありません。
If there are protocols that require case be preserved, then the analogy with IDNA2008 will break down. Accordingly, existing protocols are to be evaluated according to the following criteria:
大文字と小文字の区別が必要なプロトコルがある場合、IDNA2008との類似性は崩れます。したがって、既存のプロトコルは次の基準に従って評価されます。
1. Does the protocol use case folding? For all blocks of code points or just for certain subsets?
1. プロトコルは大文字小文字変換を使用しますか？コードポイントのすべてのブロックについて、または特定のサブセットについてのみ？
2. Is the system or protocol case-sensitive?
2. システムまたはプロトコルでは大文字と小文字が区別されますか？
3. Does the system or protocol preserve case?
3. システムまたはプロトコルは大文字と小文字を区別しますか？
Stringprep profiles may use normalization. If they do, they use NFKC [UAX15] (most profiles do). It is not clear that NFKC is the right normalization to use in all cases. In [UAX15], there is the following observation regarding Normalization Forms KC and KD: "It is best to think of these Normalization Forms as being like uppercase or lowercase mappings: useful in certain contexts for identifying core meanings, but also performing modifications to the text that may not always be appropriate." In general, it can be said that NFKC is more aggressive about finding matches between code points than NFC. For things like the spelling of users' names, NFKC may not be the best form to use. At the same time, one of the nice things about NFKC is that it deals with the width of characters that are otherwise similar, by canonicalizing half-width to full-width. This mapping step can be crucial in practice. A replacement for Stringprep depends on analyzing the different use profiles and considering whether NFKC or NFC is a better normalization for each profile.
Stringprepプロファイルは正規化を使用する場合があります。使用する場合は、NFKC [UAX15]を使用します（ほとんどのプロファイルが使用します）。 NFKCがすべてのケースで使用するのに適切な正規化であることは明らかではありません。 [UAX15]には、正規化形式KCとKDに関する次の観察があります。「これらの正規化形式は大文字または小文字のマッピングのように考えるのが最善です。特定のコンテキストでは、コアの意味を識別するだけでなく、常に適切であるとは限らないテキスト。」一般に、NFKCはNFCよりもコードポイント間の一致の検索に積極的であると言えます。ユーザーの名前のスペルなどについては、NFKCが最適な形式ではない場合があります。同時に、NFKCの良い点の1つは、半角を全角に正規化することで、他の点では類似している文字の幅を処理できることです。このマッピング手順は、実際には非常に重要です。 Stringprepの代替は、さまざまな使用プロファイルの分析と、NFKCまたはNFCが各プロファイルのより良い正規化であるかどうかを検討することに依存しています。
For the purposes of evaluating an existing example of Stringprep use, it is helpful to know whether it uses no normalization, NFKC, or NFC.
Stringprepの既存の使用例を評価する目的で、正規化、NFKC、またはNFCを使用していないかどうかを知ることは役に立ちます。
Along with the case mapping issues raised in Section 5.2.1, there is the question of whether some characters are mapped either to other characters or to nothing during Stringprep. [RFC3454], Section 3, outlines a number of characters that are mapped to nothing, and also permits Stringprep profiles to define their own mappings.
セクション5.2.1で発生したケースマッピングの問題に加えて、一部の文字がStringprep中に他の文字にマッピングされるのか、何にもマッピングされないのかという問題があります。 [RFC3454]、セクション3では、何にもマッピングされない多数の文字の概要を説明し、Stringprepプロファイルで独自のマッピングを定義することもできます。
Along with case folding and other character mappings, many protocols have characters that are simply disallowed. For example, control characters and special characters such as "@" or "/" may be prohibited in a protocol.
大文字小文字の折りたたみやその他の文字マッピングに加えて、多くのプロトコルには、単に許可されない文字があります。たとえば、制御文字や、「@」や「/」などの特殊文字は、プロトコルで禁止されている場合があります。
One of the primary changes of IDNA2008 is in the way it approaches Unicode code points, using the new inclusion-based approach (see Section 1).
IDNA2008の主な変更点の1つは、新しい包含ベースのアプローチを使用して、Unicodeコードポイントにアプローチする方法にあります（セクション1を参照）。
Because of the default assumption in IDNA2008 that a code point is not allowed by the protocol, it has more than one class of "allowed by the protocol"; this is unlike IDNA2003. While some code points are disallowed outright, some are allowed only in certain contexts. The reasons for the context-dependent rules have to do with the way some characters are used. For instance, the ZERO WIDTH JOINER and ZERO WIDTH NON-JOINER (ZWJ, U+200D and ZWNJ, U+200C) are allowed with contextual rules because they are required in some circumstances, yet are considered punctuation by Unicode and would therefore be DISALLOWED under the usual IDNA2008 derivation rules. The goal of IDNA2008 is to provide the widest repertoire of code points possible and consistent with the traditional DNS "LDH" (letters, digits, hyphen) rule (see [RFC0952]), trusting to the operators of individual zones to make sensible (and usually more restrictive) policies for their zones.
IDNA2008のデフォルトでは、コードポイントはプロトコルで許可されていないと想定されているため、「プロトコルで許可」のクラスは複数あります。これはIDNA2003とは異なります。完全に許可されていないコードポイントもありますが、特定のコンテキストでのみ許可されているコードポイントもあります。コンテキスト依存のルールの理由は、一部の文字の使用方法に関係しています。たとえば、ZERO WIDTH JOINERおよびZERO WIDTH NON-JOINER（ZWJ、U + 200DおよびZWNJ、U + 200C）は、状況によっては必須であるが、Unicodeでは句読点と見なされるため、禁止されるため、コンテキストルールで許可されます。通常のIDNA2008派生ルールの下。 IDNA2008の目標は、可能な限り広い範囲のコードポイントのレパートリーを提供し、従来のDNS "LDH"（文字、数字、ハイフン）ルール（[RFC0952]を参照）に準拠して、個々のゾーンのオペレーターに賢明なものにすることです（およびそれらのゾーンに対する通常はより制限的なポリシー。
IDNA2008 has a special problem with delimiters, because the delimiter "character" in the DNS wire format is not really part of the data. In DNS, labels are not separated exactly; instead, a label carries with it an indicator that says how long the label is. When the label is displayed in presentation format as part of a fully qualified domain name, the label separator FULL STOP, U+002E (.) is used to break up the labels. But because that label separator does not travel with the wire format of the domain name, there is no way to encode a different, "internationalized" separator in IDNA2008.
DNSワイヤ形式の区切り文字「文字」は実際にはデータの一部ではないため、IDNA2008には区切り文字に関する特別な問題があります。 DNSでは、ラベルは正確に区切られていません。代わりに、ラベルにはラベルの長さを示すインジケーターが付いています。ラベルが完全修飾ドメイン名の一部としてプレゼンテーション形式で表示される場合、ラベルの区切り記号FULL STOP、U + 002E（。）を使用してラベルを分割します。ただし、そのラベルセパレーターはドメイン名のワイヤ形式で移動しないため、IDNA2008で別の「国際化された」セパレーターをエンコードする方法はありません。
Other protocols may include characters with similar special meaning within the protocol. Common characters for these purposes include FULL STOP, U+002E (.); COMMERCIAL AT, U+0040 (@); HYPHEN-MINUS, U+002D (-); SOLIDUS, U+002F (/); and LOW LINE, U+005F (_). The mere inclusion of such a character in the protocol is not enough for it to be considered similar to another protocol using the same character; instead, handling of the character must be taken into consideration as well.
他のプロトコルには、プロトコル内で同様の特別な意味を持つ文字が含まれる場合があります。これらの目的の一般的な文字には、FULL STOP、U + 002E（。）があります。 COMMERCIAL AT、U + 0040（@）;ハイフンマイナス、U + 002D（-）; SOLIDUS、U + 002F（/）; LOW LINE、U + 005F（_）。プロトコルにそのような文字を含めるだけでは、同じ文字を使用する別のプロトコルに類似していると見なされるには不十分です。代わりに、文字の処理も考慮する必要があります。
An important issue to tackle here is whether it is valuable to map to or from these special characters as part of the Stringprep replacement. In some locales, the analogue to FULL STOP, U+002E is some other character, and users may expect to be able to substitute their normal stop for FULL STOP, U+002E. At the same time, there are predictability arguments in favor of treating identifiers with FULL STOP, U+002E in them just the way they are treated under IDNA2008.
ここで取り組むべき重要な問題は、Stringprep置換の一部としてこれらの特殊文字にマッピングするか、これらの特殊文字からマッピングすることが価値があるかどうかです。一部のロケールでは、FULL STOP、U + 002Eに類似したものが他の文字であり、ユーザーは通常の停止をFULL STOP、U + 002Eに置き換えることができると期待する場合があります。同時に、IDをIDNA2008で処理するのと同じように、IDをFULL STOP、U + 002Eで処理することを支持する予測可能性の議論があります。
Homoglyphs are similarly (or identically) rendered glyphs of different code points. For DNS names, homoglyphs may enable phishing. If a protocol requires some visual comparison by end-users, then the issue of homoglyphs is to be considered. In the DNS context, these issues are documented in [RFC5894] and [RFC4690]. However, IDNA2008 does not have a mechanism to deal with them, trusting DNS zone operators to enact sensible policies for the subset of Unicode they wish to support, given their user community. A similar policy/protocol split may not be desirable in every protocol.
ホモグリフは、異なる（またはまったく同じ）レンダリングされた異なるコードポイントのグリフです。 DNS名の場合、ホモグリフはフィッシングを有効にする可能性があります。プロトコルでエンドユーザーによる視覚的な比較が必要な場合は、ホモグリフの問題を検討する必要があります。 DNSのコンテキストでは、これらの問題は[RFC5894]および[RFC4690]で文書化されています。ただし、IDNA2008にはそれらに対処するメカニズムがなく、DNSゾーンオペレーターがユーザーコミュニティを前提として、サポートするUnicodeのサブセットに対して賢明なポリシーを制定することを信頼しています。同様のポリシー/プロトコル分割は、すべてのプロトコルで望ましいとは限りません。
Some protocol elements are provided by users, and others are not. Those that are not may presumably be subject to greater restrictions, whereas those that users provide likely need to permit the broadest range of code points. The following questions are helpful:
プロトコル要素には、ユーザーが提供するものと提供しないものがあります。ユーザーが提供するものはおそらくより広い範囲のコードポイントを許可する必要があるのに対し、そうでないものはおそらくより大きな制限を受ける可能性があります。次の質問が役立ちます。
1. Do users input the strings directly?
1. ユーザーは文字列を直接入力しますか？
2. If so, how? (keyboard, stylus, voice, copy-paste, etc.)
2. もしそうなら、どうですか？ （キーボード、スタイラス、音声、コピー、貼り付けなど）
3. Where do we place the dividing line between user interface and protocol? (see [RFC5895])
3. ユーザーインターフェイスとプロトコルの境界線はどこに配置しますか？ （[RFC5895]を参照）
Just as only some protocol elements are expected to be entered directly by users, only some protocol elements are intended to be consumed directly by users. It is important to know how users are expected to be able to consume the protocol elements, because different environments present different challenges. An element that is only ever delivered as part of a vCard remains in machine-readable format, so the problem of visual confusion is not a great one. Is the protocol element published as part of a vCard, a web directory, on a business card, or on "the side of a bus"? Do users use the protocol element as an identifier (which means that they might enter it again in some other context)? (See also Section 5.2.6.)
一部のプロトコル要素のみがユーザーによって直接入力されることが期待されるのと同様に、一部のプロトコル要素のみがユーザーによって直接消費されることが意図されています。さまざまな環境ではさまざまな課題が発生するため、ユーザーがプロトコル要素を使用できると期待される方法を理解することが重要です。 vCardの一部としてのみ配信される要素は機械可読形式のままであるため、視覚的な混乱の問題は大きな問題ではありません。プロトコル要素は、vCard、Webディレクトリ、名刺、または「バスの側面」の一部として公開されていますか？ユーザーはプロトコル要素を識別子として使用しますか（つまり、他のコンテキストで再度入力する可能性があります）？ （セクション5.2.6も参照してください。）
Some strings are useful as part of the protocol but are not used as input to other operations (for instance, purely informative or descriptive text). Other strings are used directly as input to other operations (such as cryptographic hash functions), or are used together with other strings to (such as concatenating a string with some others to form a unique identifier).
一部の文字列は、プロトコルの一部としては役立ちますが、他の操作への入力としては使用されません（たとえば、純粋に情報を与えるテキストまたは説明的なテキスト）。他の文字列は、他の操作（暗号化ハッシュ関数など）への入力として直接使用されるか、他の文字列と一緒に使用されます（文字列を他の文字列と連結して一意の識別子を形成するなど）。
Strings often have a similar function in different protocols. For instance, many different protocols contain user identifiers or passwords. A single profile for all such uses might be desirable.
文字列は多くの場合、異なるプロトコルで同様の機能を持っています。たとえば、多くの異なるプロトコルには、ユーザー識別子またはパスワードが含まれています。このようなすべての用途に単一のプロファイルが望ましい場合があります。
Often, a string in a protocol is effectively a protocol element from another protocol. For instance, different systems might use the same credentials database for authentication.
多くの場合、プロトコル内の文字列は、別のプロトコルのプロトコル要素です。たとえば、異なるシステムが認証に同じ資格情報データベースを使用する場合があります。
A Stringprep replacement that does anything more than just update Stringprep to the latest version of Unicode will probably entail some changes. It is important to identify the willingness of the protocol-using community to accept backwards-incompatible changes. By the same token, it is important to evaluate the desire of the community for features not available under Stringprep.
StringprepをUnicodeの最新バージョンに更新する以外のことを行うStringprepの置き換えには、おそらくいくつかの変更が伴います。プロトコルを使用するコミュニティが、下位互換性のない変更を受け入れる意欲を特定することが重要です。同様に、Stringprepでは使用できない機能に対するコミュニティの要望を評価することが重要です。
IDNA2008 uses an algorithm to derive the validity of a Unicode code point for use under IDNA2008. It does this by using the properties of each code point to test its validity.
IDNA2008はアルゴリズムを使用して、IDNA2008で使用するUnicodeコードポイントの有効性を導き出します。これは、各コードポイントのプロパティを使用して、その有効性をテストすることによって行われます。
This approach depends crucially on the idea that code points, once valid for a protocol profile, will not later be made invalid. That is not a guarantee currently provided by Unicode. Properties of code points may change between versions of Unicode. Rarely, such a change could cause a given code point to become invalid under a protocol profile, even though the code point would be valid with an earlier version of Unicode. This is not merely a theoretical possibility, because it has occurred [RFC6452].
このアプローチは、コードポイントがプロトコルプロファイルで有効になると、後で無効にならないという考え方に大きく依存しています。これは現在Unicodeによって提供されている保証ではありません。コードポイントのプロパティは、Unicodeのバージョン間で異なる場合があります。まれに、そのような変更により、コードポイントが以前のバージョンのUnicodeで有効であっても、特定のコードポイントがプロトコルプロファイルで無効になる可能性があります。 [RFC6452]が発生したため、これは単なる理論的な可能性ではありません。
Accordingly, as in IDNA2008, a Stringprep replacement that intends to be Unicode version agnostic will need to work out a mechanism to address cases where incompatible changes occur because of new Unicode versions.
したがって、IDNA2008の場合と同様に、UnicodeバージョンにとらわれないStringprep置換は、新しいUnicodeバージョンが原因で互換性のない変更が発生する場合に対処するメカニズムを解決する必要があります。
The above suggests the following guidance:
上記は、次のガイダンスを示唆しています。
o A Stringprep replacement should be defined.
o Stringprep置換を定義する必要があります。
o The replacement should take an approach similar to IDNA2008 (e.g., by using properties of code points instead of whitelisting of code points), in that it enables better Unicode agility.
o 置き換えでは、IDNA2008と同様のアプローチ（コードポイントのホワイトリストの代わりにコードポイントのプロパティを使用するなど）を使用する必要があります。これにより、Unicodeの俊敏性が向上します。
o Protocols share similar characteristics of strings. Therefore, defining internationalization preparation algorithms for the smallest set of string classes may be sufficient for most cases, providing coherence among a set of related protocols or protocols where identifiers are exchanged.
o プロトコルは文字列の同様の特性を共有します。したがって、ほとんどの場合、文字列クラスの最小セットに対して国際化準備アルゴリズムを定義するだけで十分であり、関連するプロトコルのセットまたは識別子が交換されるプロトコル間の一貫性を提供します。
o The sets of string classes need to be evaluated according to the considerations that make up the headings in Section 5
o 文字列クラスのセットは、セクション5の見出しを構成する考慮事項に従って評価する必要があります
o It is reasonable to limit scope to Unicode code points and rule the mapping of data from other character encodings outside the scope of this effort.
o スコープをUnicodeコードポイントに制限し、この取り組みの範囲外にある他の文字エンコーディングからのデータのマッピングをルール化することは妥当です。
o The replacement ought to at least provide guidance to applications using the replacement on how to handle protocol incompatibilities resulting from changes to Unicode. In an ideal world, the Stringprep replacement would handle the changes automatically, but it appears that such automatic handling would require magic and cannot be expected.
o 置き換えは、Unicodeへの変更に起因するプロトコルの非互換性を処理する方法について、置き換えを使用するアプリケーションに少なくともガイダンスを提供する必要があります。理想的な世界では、Stringprepの置換は変更を自動的に処理しますが、そのような自動処理には魔法が必要であり、期待することはできないようです。
o Compatibility within each protocol between a technique that is Stringprep-based and the technique's replacement has to be considered very carefully.
o Stringprepベースの手法とその手法の置き換えとの間の各プロトコル内の互換性は、非常に慎重に検討する必要があります。
Existing deployments already depend on Stringprep profiles. Therefore, a replacement must consider the effects of any new strategy on existing deployments. By way of comparison, it is worth noting that some characters were acceptable in IDNA labels under IDNA2003, but are not protocol-valid under IDNA2008 (and conversely); disagreement about what to do during the transition has resulted in different approaches to mapping. Different implementers may make different decisions about what to do in such cases; this could have interoperability effects. It is necessary to trade better support for different linguistic environments against the potential side effects of backward incompatibility.
既存のデプロイメントはすでにStringprepプロファイルに依存しています。したがって、交換では、既存の展開に対する新しい戦略の影響を考慮する必要があります。比較として、IDNA2003ではIDNAラベルで一部の文字が許容されていたが、IDNA2008ではプロトコルとして有効ではない（およびその逆）ことに注意する必要があります。移行中に何をすべきかについての意見の相違により、マッピングへのさまざまなアプローチが生じました。そのような場合に何をすべきかについては、実装者が異なれば決定が異なる場合があります。これは相互運用性に影響を与える可能性があります。下位の非互換性の潜在的な副作用に対して、異なる言語環境に対するより良いサポートを交換する必要があります。
This document merely states what problems are to be solved and does not define a protocol. There are undoubtedly security implications of the particular results that will come from the work to be completed. Moreover, the Stringprep Security Considerations [RFC3454] Section applies. See also the analysis in the subsections of Appendix B, below.
このドキュメントでは、解決すべき問題を説明するだけで、プロトコルを定義していません。完成する作業から得られる特定の結果には、間違いなくセキュリティ上の影響があります。さらに、Stringprepのセキュリティに関する考慮事項[RFC3454]セクションが適用されます。以下の付録Bのサブセクションの分析も参照してください。
This document is the product of the PRECIS IETF Working Group, and participants in that working group were helpful in addressing issues with the text.
このドキュメントは、PRECIS IETFワーキンググループの成果物であり、そのワーキンググループの参加者は、テキストに関する問題の解決に役立ちました。
Specific contributions came from David Black, Alan DeKok, Simon Josefsson, Bill McQuillan, Alexey Melnikov, Peter Saint-Andre, Dave Thaler, and Yoshiro Yoneya.
具体的な貢献は、David Black、Alan DeKok、Simon Josefsson、Bill McQuillan、Alexey Melnikov、Peter Saint-Andre、Dave Thaler、Yoshiro Yoneyaによるものです。
Dave Thaler provided the "buckets" insight in Section 5.1.1, central to the organization of the problem.
Dave Thalerは、問題の編成の中核となるセクション5.1.1で「バケット」の洞察を提供しました。
Evaluations of Stringprep profiles that are included in Appendix B were done by David Black, Alexey Melnikov, Peter Saint-Andre, and Dave Thaler.
付録Bに含まれているStringprepプロファイルの評価は、David Black、Alexey Melnikov、Peter Saint-Andre、およびDave Thalerによって行われました。
[78PRECIS] Blanchet, M., "PRECIS Framework", Proceedings of IETF 78, July 2010, <http://www.ietf.org/proceedings/78/ slides/precis-2.pdf>.
[78PRECIS]ブランシェ、M。、「PRECISフレームワーク」、IETF 78の議事録、2010年7月、<http://www.ietf.org/proceedings/78/slides/precis-2.pdf>。
[ID-COMP] Thaler, D., Ed., "Issues in Identifier Comparison for Security Purposes", Work in Progress, March 2013.
[ID-COMP] Thaler、D.、Ed。、「セキュリティ上の目的のための識別子比較の問題」、進行中の作業、2013年3月。
[NEWPREP] "Newprep BoF Meeting Minutes", March 2010, <http://www.ietf.org/proceedings/77/minutes/ newprep.txt>.
[NEWPREP]「Newprep BoF Meeting Minutes」、2010年3月、<http://www.ietf.org/proceedings/77/minutes/ newprep.txt>。
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985.
[RFC0952] Harrenstien、K.、Stahl、M。、およびE. Feinler、「DoD Internet host table specification」、RFC 952、1985年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454] Hoffman、P.およびM. Blanchet、「Preparation of Internationalized Strings（ "stringprep"）」、RFC 3454、2002年12月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、Hoffman、P。、およびA. Costello、「Internationalizing Domain Names in Applications（IDNA）」、RFC 3490、2003年3月。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[RFC3491] Hoffman、P.およびM. Blanchet、「Nameprep：国際化ドメイン名（IDN）のStringprepプロファイル」、RFC 3491、2003年3月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492] Costello、A。、「Punycode：A Bootstring encoding for Unicode for Internationalized Domain Names in Applications（IDNA）」、RFC 3492、2003年3月。
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC3530] Shepler、S.、Callaghan、B.、Robinson、D.、Thurlow、R.、Beame、C.、Eisler、M。、およびD. Noveck、「Network File System（NFS）version 4 Protocol」、 RFC 3530、2003年4月。
[RFC3722] Bakke, M., "String Profile for Internet Small Computer Systems Interface (iSCSI) Names", RFC 3722, April 2004.
[RFC3722] Bakke、M。、「インターネットスモールコンピュータシステムインターフェイス（iSCSI）名の文字列プロファイル」、RFC 3722、2004年4月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、「Extensible Authentication Protocol（EAP）」、RFC 3748、2004年6月。
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004.
[RFC3920] Saint-Andre、P。、編、「Extensible Messaging and Presence Protocol（XMPP）：Core」、RFC 3920、2004年10月。
[RFC3922] Saint-Andre, P., "Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)", RFC 3922, October 2004.
[RFC3922] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）to Common Presence and Instant Messaging（CPIM）」、RFC 3922、2004年10月。
[RFC4011] Waldbusser, S., Saperia, J., and T. Hongal, "Policy Based Management MIB", RFC 4011, March 2005.
[RFC4011] Waldbusser、S.、Saperia、J。、およびT. Hongal、「Policy Based Management MIB」、RFC 4011、2005年3月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013] Zeilenga、K。、「SASLprep：Stringprep Profile for User Names and Passwords」、RFC 4013、2005年2月。
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
[RFC4279] Eronen、P。およびH. Tschofenig、「トランスポート層セキュリティ（TLS）の事前共有鍵暗号スイート」、RFC 4279、2005年12月。
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005.
[RFC4314] Melnikov、A。、「IMAP4 Access Control List（ACL）Extension」、RFC 4314、2005年12月。
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422] Melnikov、A。およびK. Zeilenga、「Simple Authentication and Security Layer（SASL）」、RFC 4422、2006年6月。
[RFC4505] Zeilenga, K., "Anonymous Simple Authentication and Security Layer (SASL) Mechanism", RFC 4505, June 2006.
[RFC4505] Zeilenga、K。、「匿名の単純な認証およびセキュリティ層（SASL）メカニズム」、RFC 4505、2006年6月。
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J。、「ライトウェイトディレクトリアクセスプロトコル（LDAP）：プロトコル」、RFC 4511、2006年6月。
[RFC4513] Harrison, R., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[RFC4513]ハリソンR.、「ライトウェイトディレクトリアクセスプロトコル（LDAP）：認証方法とセキュリティメカニズム」、RFC 4513、2006年6月。
[RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation", RFC 4518, June 2006.
[RFC4518] Zeilenga、K。、「Lightweight Directory Access Protocol（LDAP）：Internationalized String Preparation」、RFC 4518、2006年6月。
[RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, August 2006.
[RFC4616] Zeilenga、K。、「The PLAIN Simple Authentication and Security Layer（SASL）Mechanism」、RFC 4616、2006年8月。
[RFC4643] Vinocur, J. and K. Murchison, "Network News Transfer Protocol (NNTP) Extension for Authentication", RFC 4643, October 2006.
[RFC4643] Vinocur、J。およびK.マーチソン、「認証のためのネットワークニュース転送プロトコル（NNTP）拡張機能」、RFC 4643、2006年10月。
[RFC4683] Park, J., Lee, J., Lee, H., Park, S., and T. Polk, "Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)", RFC 4683, October 2006.
[RFC4683] Park、J.、Lee、J.、Lee、H.、Park、S。、およびT. Polk、「Internet X.509 Public Key Infrastructure Subject Identification Method（SIM）」、RFC 4683、2006年10月。
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006.
[RFC4690] Klensin、J.、Faltstrom、P.、Karp、C。、およびIAB、「Review and Recommendations for Internationalized Domain Names（IDNs）」、RFC 4690、2006年9月。
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet Application Protocol Collation Registry", RFC 4790, March 2007.
[RFC4790]ニューマン、C。、デュエルスト、M。、およびA.グルブランドセン、「インターネットアプリケーションプロトコル照合レジストリ」、RFC 4790、2007年3月。
[RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.
[RFC4954] Siemborski、R。およびA. Melnikov、「認証用のSMTPサービス拡張」、RFC 4954、2007年7月。
[RFC5034] Siemborski, R. and A. Menon-Sen, "The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism", RFC 5034, July 2007.
[RFC5034] Siemborski、R。およびA. Menon-Sen、「Post Office Protocol（POP3）Simple Authentication and Security Layer（SASL）Authentication Mechanism」、RFC 5034、2007年7月。
[RFC5051] Crispin, M., "i;unicode-casemap - Simple Unicode Collation Algorithm", RFC 5051, October 2007.
[RFC5051] Crispin、M。、「i; unicode-casemap-Simple Unicode Collation Algorithm」、RFC 5051、2007年10月。
[RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, "Using the Secure Remote Password (SRP) Protocol for TLS Authentication", RFC 5054, November 2007.
[RFC5054] Taylor、D.、Wu、T.、Mavrogiannopoulos、N。、およびT. Perrin、「Using the Secure Remote Password（SRP）Protocol for TLS Authentication」、RFC 5054、2007年11月。
[RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", RFC 5122, February 2008.
[RFC5122] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）の国際化リソース識別子（IRI）およびUniform Resource Identifiers（URIs）」、RFC 5122、2008年2月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[RFC5456] Spencer, M., Capouch, B., Guy, E., Miller, F., and K. Shumard, "IAX: Inter-Asterisk eXchange Version 2", RFC 5456, February 2010.
[RFC5456] Spencer、M.、Capouch、B.、Guy、E.、Miller、F。、およびK. Shumard、「IAX：Inter-Asterisk eXchange Version 2」、RFC 5456、2010年2月。
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, January 2010.
[RFC5661] Shepler、S.、Eisler、M。、およびD. Noveck、「Network File System（NFS）Version 4 Minor Version 1 Protocol」、RFC 5661、2010年1月。
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010.
[RFC5802]ニューマン、C。、メノンセン、A。、メルニコフ、A。、およびN.ウィリアムズ、「ソルトチャレンジレスポンス認証メカニズム（SCRAM）SASLおよびGSS-APIメカニズム」、RFC 5802、2010年7月。
[RFC5804] Melnikov, A. and T. Martin, "A Protocol for Remotely Managing Sieve Scripts", RFC 5804, July 2010.
[RFC5804] Melnikov、A。およびT. Martin、「A Sieve Scripts Remotely Manageing for Sieve Scripts」、RFC 5804、2010年7月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890] Klensin、J。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、2010年8月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891] Klensin、J。、「Internationalized Domain Names in Applications（IDNA）：Protocol」、RFC 5891、2010年8月。
[RFC5892] Faltstrom, P., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, August 2010.
[RFC5892] Faltstrom、P。、「アプリケーションのUnicodeコードポイントと国際化ドメイン名（IDNA）」、RFC 5892、2010年8月。
[RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, August 2010.
[RFC5893] Alvestrand、H。およびC. Karp、「Right-to-Left Scripts for Internationalized Domain Names for Applications（IDNA）」、RFC 5893、2010年8月。
[RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, August 2010.
[RFC5894] Klensin、J。、「アプリケーションの国際化ドメイン名（IDNA）：背景、説明、および理論的根拠」、RFC 5894、2010年8月。
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008", RFC 5895, September 2010.
[RFC5895] Resnick、P。およびP. Hoffman、「アプリケーションの国際化ドメイン名のマッピング文字（IDNA）2008」、RFC 5895、2010年9月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Core」、RFC 6120、2011年3月。
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, September 2011.
[RFC6365] Hoffman、P。およびJ. Klensin、「IETFの国際化で使用される用語」、BCP 166、RFC 6365、2011年9月。
[RFC6452] Faltstrom, P. and P. Hoffman, "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0", RFC 6452, November 2011.
[RFC6452] Faltstrom、P。およびP. Hoffman、「アプリケーションのUnicodeコードポイントと国際化ドメイン名（IDNA）-Unicode 6.0」、RFC 6452、2011年11月。
[UAX15] "Unicode Standard Annex #15: Unicode Normalization Forms", UAX 15, September 2009.
[UAX15]「Unicode Standard Annex＃15：Unicode Normalization Forms」、UAX 15、2009年9月。
[Unicode61] The Unicode Consortium. The Unicode Standard, Version 6.1.0, (Mountain View, CA: The Unicode Consortium, 2012. ISBN 978-1-936213-02-3). <http://www.unicode.org/versions/Unicode6.1.0/>.
[Unicode61] Unicodeコンソーシアム。 Unicode Standard、バージョン6.1.0（Mountain View、CA：The Unicode Consortium、2012。ISBN978-1-936213-02-3）。 <http://www.unicode.org/versions/Unicode6.1.0/>。
A number of the known cases of Stringprep use were evaluated during the preparation of this document. The known cases are here described in two ways. The types of identifiers the protocol uses is first called out in the ID type column (from Section 5.1.1) using the short forms "a" for Absolute, "d" for Definite, and "i" for Indefinite. Next, there is a column that contains an "i" if the protocol string comes from user input, an "o" if the protocol string becomes user-facing output, "b" if both are true, and "n" if neither is true.
このドキュメントの作成中に、Stringprepの既知の使用例がいくつか評価されました。ここでは、既知のケースを2つの方法で説明します。プロトコルが使用する識別子のタイプは、最初にIDタイプ列（セクション5.1.1から）で、絶対形式の場合は「a」、定形式の場合は「d」、不定形式の場合は「i」を使用して呼び出されます。次に、プロトコル文字列がユーザー入力からのものである場合は「i」、プロトコル文字列がユーザー向けの出力になる場合は「o」、両方がtrueの場合は「b」、どちらでもない場合は「n」を含む列があります。本当。
+------+--------+-------+
| RFC | IDtype | User? |
+------+--------+-------+
| 3722 | a | b |
| 3748 | - | - |
| 3920 | a,d | b |
| 4505 | a | i |
| 4314 | a,d | b |
| 4954 | a,d | b |
| 5034 | a,d | b |
| 5804 | a,d | b |
+------+--------+-------+
Table 1
表1
This section is a summary of evaluation of Stringprep profiles that was done to get a good understanding of the usage of Stringprep. This summary is by no means normative nor the actual evaluations themselves. A template was used for reviewers to get a coherent view of all evaluations.
このセクションは、Stringprepの使用法をよく理解するために行われたStringprepプロファイルの評価の概要です。この要約は、決して規範的でも実際の評価自体でもありません。レビューアがすべての評価の一貫したビューを取得するために、テンプレートが使用されました。
Description: An iSCSI session consists of an initiator (i.e., host or server that uses storage) communicating with a target (i.e., a storage array or other system that provides storage). Both the iSCSI initiator and target are named by iSCSI names. The iSCSI Stringprep profile is used for iSCSI names.
説明：iSCSIセッションは、ターゲット（ストレージアレイまたはストレージを提供するその他のシステム）と通信するイニシエーター（ストレージを使用するホストまたはサーバー）で構成されます。 iSCSIイニシエーターとターゲットの両方にiSCSI名が付けられます。 iSCSI Stringprepプロファイルは、iSCSI名に使用されます。
How it is used: iSCSI initiators and targets (see above). They can also be used to identify SCSI ports (these are software entities in the iSCSI protocol, not hardware ports) and iSCSI logical units (storage volumes), although both are unusual in practice.
使用方法：iSCSIイニシエーターとターゲット（上記を参照）。これらは、SCSIポート（これらはハードウェアポートではなく、iSCSIプロトコルのソフトウェアエンティティです）およびiSCSI論理ユニット（ストレージボリューム）の識別にも使用できますが、どちらも実際には珍しいものです。
What entities create these identifiers? Generally, a human user (1) configures an automated system (2) that generates the names. Advance configuration of the system is required due to the embedded use of external unique identifier (from the DNS or IEEE).
これらの識別子を作成するエンティティは何ですか？一般に、人間のユーザー（1）は、名前を生成する自動システム（2）を構成します。 （DNSまたはIEEEからの）外部固有IDの組み込み使用のため、システムの事前構成が必要です。
How is the string input in the system? Keyboard and copy-paste are common. Copy-paste is common because iSCSI names are long enough to be problematic for humans to remember, causing use of email, sneaker-net, text files, etc., to avoid mistype mistakes.
システムでの文字列入力はどうですか？キーボードとコピー＆ペーストは一般的です。 iSCSI名は人間が覚えるのに問題になるほど長く、タイプミスを回避するために電子メール、スニーカーネット、テキストファイルなどを使用するため、コピーと貼り付けが一般的です。
Where do we place the dividing line between user interface and protocol? The iSCSI protocol requires that all internationalization string preparation occur in the user interface. The iSCSI protocol treats iSCSI names as opaque identifiers that are compared byte-by-byte for equality. iSCSI names are generally not checked for correct formatting by the protocol.
ユーザーインターフェイスとプロトコルの境界線はどこに配置しますか？ iSCSIプロトコルでは、すべての国際化文字列の準備がユーザーインターフェイスで行われる必要があります。 iSCSIプロトコルは、iSCSI名を不透明な識別子として扱い、バイトごとに比較されます。 iSCSI名は通常、プロトコルによる正しいフォーマットについてチェックされません。
What entities enforce the rules? There are no iSCSI-specific enforcement entities, although the use of unique identifier information in the names relies on DNS registrars and the IEEE Registration Authority.
どのエンティティがルールを施行しますか？名前に一意の識別子情報を使用することはDNSレジストラとIEEE Registration Authorityに依存していますが、iSCSI固有の実施エンティティはありません。
Comparison: Byte-by-byte.
比較：バイトごと。
Case Folding, Sensitivity, Preservation: Case folding is required for the code blocks specified in RFC 3454, Table B.2. The overall iSCSI naming system (UI + protocol) is case-insensitive.
ケースの折りたたみ、機密性、保持：RFC 3454、表B.2で指定されているコードブロックには、ケースの折りたたみが必要です。全体的なiSCSIネーミングシステム（UI +プロトコル）は大文字と小文字を区別しません。
What is the impact if the comparison results in a false positive? Potential access to the wrong storage.
比較の結果が偽陽性になった場合、どのような影響がありますか？間違ったストレージへの潜在的なアクセス。
- If the initiator has no access to the wrong storage, an authentication failure is the probable result.
- イニシエーターが間違ったストレージにアクセスできない場合、認証の失敗が原因である可能性があります。
- If the initiator has access to the wrong storage, the resulting misidentification could result in use of the wrong data and possible corruption of stored data.
- イニシエーターが誤ったストレージにアクセスした場合、誤認の結果、誤ったデータが使用され、保存されたデータが破損する可能性があります。
What is the impact if the comparison results in a false negative? Denial of authorized storage access.
比較の結果が偽陰性になった場合、どのような影響がありますか？許可されたストレージアクセスの拒否。
What are the security impacts? iSCSI names may be used as the authentication identities for storage systems. Comparison problems could result in authentication problems, although note that authentication failure ameliorates some of the false positive cases.
セキュリティへの影響は何ですか？ iSCSI名は、ストレージシステムの認証IDとして使用できます。比較の問題により認証の問題が発生する可能性がありますが、認証の失敗により誤検出の一部が改善されることに注意してください。
Normalization: NFKC, as specified by RFC 3454.
正規化：RFC 3454で指定されているNFKC。
Mapping: Yes, as specified by Table B.1 in RFC 3454.
マッピング：はい、RFC 3454の表B.1で指定されています。
Disallowed Characters: Only the following characters are allowed: - ASCII dash, dot, colon - ASCII lowercase letters and digits - Unicode lowercase characters as specified by RFC 3454. All other characters are disallowed.
使用できない文字：次の文字のみ使用できます：-ASCIIダッシュ、ドット、コロン-ASCII小文字と数字-RFC 3454で指定されているUnicode小文字。他のすべての文字は使用できません。
Which other strings or identifiers are these most similar to? None -- iSCSI names are unique to iSCSI.
これらに最も類似している他の文字列または識別子はどれですか？なし-iSCSI名はiSCSIに固有です。
Are these strings or identifiers sometimes the same as strings or identifiers from other protocols? No.
これらの文字列または識別子は、他のプロトコルの文字列または識別子と同じである場合がありますか？番号。
Does the identifier have internal structure that needs to be respected? Yes. ASCII dot, dash, and colon are used for internal name structure. These are not reserved characters, in that they can occur in the name in locations other than those used for structuring purposes (e.g., only the first occurrence of a colon character is structural, others are not).
識別子には、尊重する必要のある内部構造がありますか？はい。 ASCIIのドット、ダッシュ、およびコロンは、内部の名前構造に使用されます。これらは予約文字ではありません。構造化の目的で使用される場所以外の場所で名前に使用される可能性があります（たとえば、コロン文字の最初の出現のみが構造的であり、その他はそうではありません）。
How are users exposed to these strings? How are they published? iSCSI names appear in server and storage system configuration interfaces. They also appear in system logs.
ユーザーはこれらの文字列にどのようにさらされますか？それらはどのように公開されますか？ iSCSI名は、サーバーおよびストレージシステムの構成インターフェイスに表示されます。システムログにも表示されます。
Is the string / identifier used as input to other operations? Effectively, no. The rarely used port and logical unit names involve concatenation, which effectively extends a unique iSCSI name for a target to uniquely identify something within that target.
文字列/識別子は他の操作への入力として使用されていますか？事実上、違います。まれに使用されるポートおよび論理ユニット名には連結が含まれます。これは、ターゲットの一意のiSCSI名を効果的に拡張して、そのターゲット内の何かを一意に識別します。
How much tolerance for change from existing Stringprep approach? Good tolerance; the community would prefer that internationalization experts solve internationalization problems.
既存のStringprepアプローチからの変更に対する許容度はどれくらいですか？良好な耐性;コミュニティは、国際化の専門家が国際化の問題を解決することを望んでいます。
How strong a desire for change (e.g., for Unicode agility)? Unicode agility is desired, in principle, as long as nothing significant breaks.
変更に対する欲求（たとえば、Unicodeの俊敏性）はどれほど強いですか？ Unicodeの俊敏性は、重大な障害が発生しない限り、原則として望ましいものです。
B.2. SMTP/POP3/ManageSieve Stringprep Profiles: RFC 4954, RFC 5034, RFC 5804
B.2. SMTP / POP3 / ManageSieve Stringprepプロファイル：RFC 4954、RFC 5034、RFC 5804
Description: Authorization identity (user identifier) exchanged during SASL authentication: AUTH (SMTP/POP3) or AUTHENTICATE (ManageSieve) command.
説明：SASL認証中に交換される許可ID（ユーザーID）：AUTH（SMTP / POP3）またはAUTHENTICATE（ManageSieve）コマンド。
How It's Used: Used for proxy authorization, e.g., to [lawfully] impersonate a particular user after a privileged authentication.
使い方：プロキシ認証に使用されます。たとえば、特権認証後に特定のユーザーに[合法的に]偽装する場合などです。
Who Generates It: - Typically generated by email system administrators using some tools/conventions, sometimes from some backend database. - In some setups, human users can register their own usernames (e.g., webmail self-registration).
誰が生成するか-通常、電子メールシステム管理者がいくつかのツール/規則を使用して生成します。バックエンドデータベースから生成されることもあります。 -一部の設定では、人間のユーザーが自分のユーザー名を登録できます（例：ウェブメールの自己登録）。
User Input Methods: - typing or selecting from a list - copy and paste - voice input - in configuration files or on the command line
ユーザー入力方法：-リストからの入力または選択-コピーおよび貼り付け-音声入力-構成ファイルまたはコマンドライン
Enforcement: Rules enforced by server / add-on service (e.g., gateway service) on registration of account.
施行：アカウントの登録時にサーバー/アドオンサービス（ゲートウェイサービスなど）によって施行されるルール。
Comparison Method: "Type 1" (byte-for-byte) or "Type 2" (compare by a common algorithm that everyone agrees on (e.g., normalize and then compare the result byte-by-byte).
比較方法：「タイプ1」（バイト単位）または「タイプ2」（誰もが同意する一般的なアルゴリズムで比較します（たとえば、結果をバイトごとに正規化して比較します）。
Case Folding, Sensitivity, Preservation: Most likely case-sensitive. Exact requirements on case-sensitivity/case-preservation depend on a specific implementation, e.g., an implementation might treat all user identifiers as case-insensitive (or case-insensitive for US-ASCII subset only).
ケースの折りたたみ、感度、保存：ほとんどの場合、大文字と小文字が区別されます。大文字と小文字の区別/保持に関する厳密な要件は、特定の実装に依存します。たとえば、実装では、すべてのユーザー識別子を大文字と小文字を区別しない（またはUS-ASCIIサブセットのみ大文字と小文字を区別しない）として扱う場合があります。
Impact of Comparison: False positives: an unauthorized user is allowed email service access (login). False negatives: an authorized user is denied email service access.
比較の影響：誤検知：権限のないユーザーがメールサービスへのアクセス（ログイン）を許可されます。偽陰性：承認されたユーザーはメールサービスへのアクセスを拒否されます。
Normalization: NFKC (as per RFC 4013).
正規化：NFKC（RFC 4013による）。
Mapping: (see Section 2 of RFC 4013 for the full list) Non-ASCII spaces are mapped to space, etc.
マッピング：（完全なリストについては、RFC 4013のセクション2を参照）非ASCIIスペースはスペースなどにマッピングされます。
Disallowed Characters: (see Section 2 of RFC 4013 for the full list) Unicode Control characters, etc.
使用できない文字：（完全なリストについては、RFC 4013のセクション2を参照）Unicode制御文字など
String Classes: Simple username. See Section 2 of RFC 4013 for details on restrictions. Note that some implementations allow spaces in these. While implementations are not required to use a specific format, an authorization identity frequently has the same format as an email address (and Email Address Internationalization (EAI) email address in the future), or as a left hand side of an email address. Note: whatever is recommended for SMTP/POP/ ManageSieve authorization identity should also be used for IMAP authorization identities, as IMAP/POP3/SMTP/ManageSieve are frequently implemented together.
文字列クラス：単純なユーザー名。制限の詳細については、RFC 4013のセクション2をご覧ください。一部の実装では、これらにスペースを使用できることに注意してください。実装は特定の形式を使用する必要はありませんが、承認IDは、多くの場合、電子メールアドレス（および将来の電子メールアドレス国際化（EAI）電子メールアドレス）または電子メールアドレスの左側と同じ形式になります。注：IMAP / POP3 / SMTP / ManageSieveは頻繁に一緒に実装されるため、SMTP / POP / ManageSieve許可IDに推奨されるものはすべてIMAP許可IDにも使用する必要があります。
Internal Structure: None
内部構造：なし
User Output: Unlikely, but possible. For example, if it is the same as an email address.
ユーザー出力：可能性は低いですが、可能です。たとえば、メールアドレスと同じ場合。
Operations: Sometimes concatenated with other data and then used as input to a cryptographic hash function.
操作：他のデータと連結され、暗号化ハッシュ関数への入力として使用される場合があります。
How much tolerance for change from existing Stringprep approach? Not sure.
既存のStringprepアプローチからの変更に対する許容度はどれくらいですか？わからない。
Background Information: In RFC 5034, when describing the POP3 AUTH command:
背景情報：RFC 5034で、POP3 AUTHコマンドを説明する場合：
The authorization identity generated by the SASL exchange is a simple username, and SHOULD use the SASLprep profile (see [RFC4013]) of the StringPrep algorithm (see [RFC3454]) to prepare these names for matching. If preparation of the authorization identity fails or results in an empty string (unless it was transmitted as the empty string), the server MUST fail the authentication.
SASL交換によって生成される認証IDは単純なユーザー名であり、StringPrepアルゴリズム（[RFC3454]を参照）のSASLprepプロファイル（[RFC4013]を参照）を使用して、これらの名前を照合する準備を行う必要があります。承認IDの準備が失敗した場合、または空の文字列になった場合（空の文字列として送信された場合を除く）、サーバーは認証に失敗する必要があります。
In RFC 4954, when describing the SMTP AUTH command:
RFC 4954で、SMTP AUTHコマンドを説明する場合：
The authorization identity generated by this [SASL] exchange is a "simple username" (in the sense defined in [SASLprep]), and both client and server SHOULD (*) use the [SASLprep] profile of the [StringPrep] algorithm to prepare these names for transmission or comparison. If preparation of the authorization identity fails or results in an empty string (unless it was transmitted as the empty string), the server MUST fail the authentication.
この[SASL]交換によって生成された承認IDは（[SASLprep]で定義されている意味で）「単純なユーザー名」であり、クライアントとサーバーの両方が（*）[StringPrep]アルゴリズムの[SASLprep]プロファイルを使用して準備する必要があります（*）伝送または比較のためのこれらの名前。承認IDの準備が失敗した場合、または空の文字列になった場合（空の文字列として送信された場合を除く）、サーバーは認証に失敗する必要があります。
(*) Note: Future revision of this specification may change this requirement to MUST. Currently, the SHOULD is used in order to avoid breaking the majority of existing implementations.
（*）注：この仕様の将来の改訂により、この要件が必須に変更される可能性があります。現在、SHOULDは、既存の実装の大部分を壊さないようにするために使用されます。
In RFC 5804, when describing the ManageSieve AUTHENTICATE command:
RFC 5804で、ManageSieve AUTHENTICATEコマンドを説明する場合：
The authorization identity generated by this [SASL] exchange is a "simple username" (in the sense defined in [SASLprep]), and both client and server MUST use the [SASLprep] profile of the [StringPrep] algorithm to prepare these names for transmission or comparison. If preparation of the authorization identity fails or results in an empty string (unless it was transmitted as the empty string), the server MUST fail the authentication.
この[SASL]交換によって生成された認証IDは「（シンプルなユーザー名）」であり（[SASLprep]で定義されている意味）、クライアントとサーバーの両方が[StringPrep]アルゴリズムの[SASLprep]プロファイルを使用して、これらの名前を準備する必要があります。伝送または比較。承認IDの準備が失敗した場合、または空の文字列になった場合（空の文字列として送信された場合を除く）、サーバーは認証に失敗する必要があります。
Evaluation Note: These documents have 2 types of strings (usernames and passwords), so there are two separate templates.
評価上の注意：これらのドキュメントには2種類の文字列（ユーザー名とパスワード）があるため、2つの別個のテンプレートがあります。
Description: "username" parameter to the IMAP LOGIN command, identifiers in IMAP Access Control List (ACL) commands. Note that any valid username is also an IMAP ACL identifier, but IMAP ACL identifiers can include other things like the name of a group of users.
説明：IMAP LOGINコマンドの「username」パラメーター、IMAPアクセス制御リスト（ACL）コマンドの識別子。有効なユーザー名はIMAP ACL識別子でもありますが、IMAP ACL識別子には、ユーザーグループの名前など、他のものを含めることができます。
How It's Used: Used for authentication (Usernames), or in IMAP Access Control Lists (Usernames or Group names).
使用方法：認証（ユーザー名）、またはIMAPアクセス制御リスト（ユーザー名またはグループ名）で使用されます。
Who Generates It: - Typically generated by email system administrators using some tools/conventions, sometimes from some backend database. - In some setups, human users can register own usernames (e.g., webmail self-registration).
誰が生成するか-通常、電子メールシステム管理者がいくつかのツール/規則を使用して生成します。バックエンドデータベースから生成されることもあります。 -一部の設定では、人間のユーザーが自分のユーザー名を登録できます（ウェブメールの自己登録など）。
User Input Methods: - typing or selecting from a list - copy and paste - voice input - in configuration files or on the command line
ユーザー入力方法：-リストからの入力または選択-コピーおよび貼り付け-音声入力-構成ファイルまたはコマンドライン
Enforcement: Rules enforced by server / add-on service (e.g., gateway service) on registration of account.
施行：アカウントの登録時にサーバー/アドオンサービス（ゲートウェイサービスなど）によって施行されるルール。
Comparison Method: "Type 1" (byte-for-byte) or "Type 2" (compare by a common algorithm that everyone agrees on (e.g., normalize and then compare the result byte-by-byte).
比較方法：「タイプ1」（バイト単位）または「タイプ2」（誰もが同意する一般的なアルゴリズムで比較します（たとえば、結果をバイトごとに正規化して比較します）。
Case Folding, Sensitivity, Preservation: Most likely case-sensitive. Exact requirements on case-sensitivity/case-preservation depend on a specific implementation, e.g., an implementation might treat all user identifiers as case-insensitive (or case-insensitive for US-ASCII subset only).
ケースの折りたたみ、感度、保存：ほとんどの場合、大文字と小文字が区別されます。大文字と小文字の区別/保持に関する厳密な要件は、特定の実装に依存します。たとえば、実装では、すべてのユーザー識別子を大文字と小文字を区別しない（またはUS-ASCIIサブセットのみ大文字と小文字を区別しない）として扱う場合があります。
Impact of Comparison: False positives: an unauthorized user is allowed IMAP access (login), privileges improperly granted (e.g., access to a specific mailbox, ability to manage ACLs for a mailbox). False negatives: an authorized user is denied IMAP access, unable to use granted privileges (e.g., access to a specific mailbox, ability to manage ACLs for a mailbox).
比較の影響：誤検知：許可されていないユーザーには、IMAPアクセス（ログイン）、不適切に付与された特権（特定のメールボックスへのアクセス、メールボックスのACLを管理する機能など）が許可されます。偽陰性：承認されたユーザーはIMAPアクセスを拒否され、付与された特権（特定のメールボックスへのアクセス、メールボックスのACLを管理する機能など）を使用できません。
Normalization: NFKC (as per RFC 4013)
正規化：NFKC（RFC 4013による）
Mapping: (see Section 2 of RFC 4013 for the full list) Non-ASCII spaces are mapped to space.
マッピング：（完全なリストについてはRFC 4013のセクション2を参照）非ASCIIスペースはスペースにマッピングされます。
Disallowed Characters: (see Section 2 of RFC 4013 for the full list) Unicode Control characters, etc.
使用できない文字：（完全なリストについては、RFC 4013のセクション2を参照）Unicode制御文字など
String Classes: Simple username. See Section 2 of RFC 4013 for details on restrictions. Note that some implementations allow spaces in these. While IMAP implementations are not required to use a specific format, an IMAP username frequently has the same format as an email address (and EAI email address in the future), or as a left hand side of an email address. Note: whatever is recommended for the IMAP username should also be used for ManageSieve, POP3 and SMTP authorization identities, as IMAP/POP3/ SMTP/ManageSieve are frequently implemented together.
文字列クラス：単純なユーザー名。制限の詳細については、RFC 4013のセクション2をご覧ください。一部の実装では、これらにスペースを使用できることに注意してください。 IMAP実装は特定の形式を使用する必要はありませんが、IMAPユーザー名は、多くの場合、電子メールアドレス（および将来のEAI電子メールアドレス）または電子メールアドレスの左側と同じ形式です。注：IMAP / POP3 / SMTP / ManageSieveは頻繁に一緒に実装されるため、IMAPユーザー名に推奨されるものはすべてManageSieve、POP3、およびSMTP承認IDにも使用する必要があります。
Internal Structure: None.
内部構造：なし。
User Output: Unlikely, but possible. For example, if it is the same as an email address, access control lists (e.g. in IMAP ACL extension), both when managing membership and listing membership of existing access control lists. Often shows up as mailbox names (under Other Users IMAP namespace).
ユーザー出力：可能性は低いですが、可能です。たとえば、メールアドレスと同じ場合は、既存のアクセス制御リストのメンバーシップを管理するときとメンバーシップをリストするときの両方で、アクセス制御リスト（IMAP ACL拡張など）を使用します。多くの場合、メールボックス名として表示されます（他のユーザーのIMAP名前空間の下）。
Operations: Sometimes concatenated with other data and then used as input to a cryptographic hash function.
操作：他のデータと連結され、暗号化ハッシュ関数への入力として使用される場合があります。
How much tolerance for change from existing Stringprep approach? Not sure. Non-ASCII IMAP usernames are currently prohibited by IMAP (RFC 3501). However, they are allowed when used in IMAP ACL extension.
既存のStringprepアプローチからの変更に対する許容度はどれくらいですか？わからない。 ASCII以外のIMAPユーザー名は、現在IMAP（RFC 3501）によって禁止されています。ただし、IMAP ACL拡張で使用する場合は許可されます。
Description: "Password" parameter to the IMAP LOGIN command.
説明：IMAP LOGINコマンドの「パスワード」パラメーター。
How It's Used: Used for authentication (Passwords).
使用方法：認証（パスワード）に使用されます。
Who Generates It: Either generated by email system administrators using some tools/conventions, or specified by the human user.
誰が生成するか：いくつかのツール/規則を使用して電子メールシステム管理者が生成するか、人間のユーザーが指定します。
User Input Methods: - typing or selecting from a list - copy and paste - voice input - in configuration files or on the command line
ユーザー入力方法：-リストからの入力または選択-コピーおよび貼り付け-音声入力-構成ファイルまたはコマンドライン
Enforcement: Rules enforced by server / add-on service (e.g., gateway service or backend database) on registration of account.
実施：アカウントの登録時にサーバー/アドオンサービス（ゲートウェイサービスやバックエンドデータベースなど）によって実施されるルール。
Comparison Method: "Type 1" (byte-for-byte).
比較方法：「タイプ1」（バイト単位）。
Case Folding, Sensitivity, Preservation: Most likely case-sensitive.
ケースの折りたたみ、感度、保存：ほとんどの場合、大文字と小文字が区別されます。
Impact of Comparison: False positives: an unauthorized user is allowed IMAP access (login). False negatives: an authorized user is denied IMAP access.
比較の影響：誤検知：権限のないユーザーにIMAPアクセス（ログイン）が許可されます。偽陰性：承認されたユーザーはIMAPアクセスを拒否されます。
Normalization: NFKC (as per RFC 4013).
正規化：NFKC（RFC 4013による）。
Mapping: (see Section 2 of RFC 4013 for the full list) Non-ASCII spaces are mapped to space.
マッピング：（完全なリストについてはRFC 4013のセクション2を参照）非ASCIIスペースはスペースにマッピングされます。
Disallowed Characters: (see Section 2 of RFC 4013 for the full list) Unicode Control characters, etc.
使用できない文字：（完全なリストについては、RFC 4013のセクション2を参照）Unicode制御文字など
String Classes: Currently defined as "simple username" (see Section 2 of RFC 4013 for details on restrictions); however, this is likely to be a different class from usernames. Note that some implementations allow spaces in these. Password in all email related protocols should be treated in the same way. Same passwords are frequently shared with web, IM, and etc. applications.
文字列クラス：現在「単純なユーザー名」として定義されています（制限の詳細については、RFC 4013のセクション2を参照）。ただし、これはユーザー名とは異なるクラスである可能性があります。一部の実装では、これらにスペースを使用できることに注意してください。すべての電子メール関連プロトコルのパスワードは同じ方法で処理する必要があります。同じパスワードがWeb、IMなどのアプリケーションで頻繁に共有されます。
Internal Structure: None.
内部構造：なし。
User Output: Text of email messages (e.g. in "you forgot your password" email messages), web page / directory, side of the bus / in ads -- possible.
ユーザー出力：メールメッセージのテキスト（「パスワードを忘れた」メールメッセージなど）、ウェブページ/ディレクトリ、バスの側/広告内-可能です。
Operations: Sometimes concatenated with other data and then used as input to a cryptographic hash function. Frequently stored as is, or hashed.
操作：他のデータと連結され、暗号化ハッシュ関数への入力として使用される場合があります。頻繁にそのまま保存されるか、ハッシュ化されます。
How much tolerance for change from existing Stringprep approach? Not sure. Non-ASCII IMAP passwords are currently prohibited by IMAP (RFC 3501); however, they are likely to be in widespread use.
既存のStringprepアプローチからの変更に対する許容度はどれくらいですか？わからない。非ASCII IMAPパスワードは現在IMAP（RFC 3501）によって禁止されています。ただし、広く使用されている可能性があります。
Background Information: RFC 5738, Section 5 ("UTF8=USER Capability"):
背景情報：RFC 5738、セクション5（ "UTF8 = USER Capability"）：
If the "UTF8=USER" capability is advertised, that indicates the server accepts UTF-8 user names and passwords and applies SASLprep [RFC4013] to both arguments of the LOGIN command. The server MUST reject UTF-8 that fails to comply with the formal syntax in RFC 3629 [RFC3629] or if it encounters Unicode characters listed in Section 2.3 of SASLprep RFC 4013 [RFC4013].
「UTF8 = USER」機能がアドバタイズされている場合、それはサーバーがUTF-8ユーザー名とパスワードを受け入れ、SASLprep [RFC4013]をLOGINコマンドの両方の引数に適用することを示します。サーバーは、RFC 3629 [RFC3629]の正式な構文に準拠していないか、SASLprep RFC 4013 [RFC4013]のセクション2.3に記載されているUnicode文字を検出した場合、UTF-8を拒否する必要があります。
RFC 4314, Section 3 ("Access control management commands and responses"):
RFC 4314、セクション3（「アクセス制御管理コマンドと応答」）：
Servers, when processing a command that has an identifier as a parameter (i.e., any of SETACL, DELETEACL, and LISTRIGHTS commands), SHOULD first prepare the received identifier using "SASLprep" profile [SASLprep] of the "stringprep" algorithm [Stringprep]. If the preparation of the identifier fails or results in an empty string, the server MUST refuse to perform the command with a BAD response. Note that Section 6 recommends additional identifier's verification steps.
サーバーは、パラメーターとして識別子を持つコマンド（つまり、SETACL、DELETEACL、およびLISTRIGHTSコマンドのいずれか）を処理する場合、最初に、「stringprep」アルゴリズム[Stringprep]の「SASLprep」プロファイル[SASLprep]を使用して、受信した識別子を準備する必要があります。 。識別子の準備が失敗した場合、または空の文字列になった場合、サーバーはBAD応答でコマンドを実行することを拒否する必要があります。セクション6では、追加の識別子の検証手順を推奨しています。
RFC 4314, Section 6 ("Security Considerations"):
RFC 4314、セクション6（「セキュリティに関する考慮事項」）：
This document relies on [SASLprep] to describe steps required to perform identifier canonicalization (preparation). The preparation algorithm in SASLprep was specifically designed such that its output is canonical, and it is well-formed. However, due to an anomaly [PR29] in the specification of Unicode normalization, canonical equivalence is not guaranteed for a select few character sequences. Identifiers prepared with SASLprep can be stored and returned by an ACL server. The anomaly affects ACL manipulation and evaluation of identifiers containing the selected character sequences. These sequences, however, do not appear in well-formed text. In order to address this problem, an ACL server MAY reject identifiers containing sequences described in [PR29] by sending the tagged BAD response. This is in addition to the requirement to reject identifiers that fail SASLprep preparation as described in Section 3.
このドキュメントは、[SASLprep]に依存して、識別子の正規化（準備）を実行するために必要な手順を説明します。 SASLprepの準備アルゴリズムは、その出力が標準的で、整形式であるように特別に設計されました。ただし、Unicode正規化の仕様の異常[PR29]が原因で、一部の文字シーケンスでは正規の等価性が保証されません。 SASLprepで準備された識別子は、ACLサーバーによって格納および返されます。この異常は、ACLの操作と、選択した文字シーケンスを含む識別子の評価に影響します。ただし、これらのシーケンスは整形式のテキストでは表示されません。この問題に対処するために、ACLサーバーは、タグ付けされたBAD応答を送信することにより、[PR29]で説明されているシーケンスを含む識別子を拒否してもよい（MAY）。これは、セクション3で説明されているSASLprepの準備に失敗した識別子を拒否する要件に追加されます。
Description: RFC 4505 defines a "trace" field:
説明：RFC 4505は「トレース」フィールドを定義しています。
Comparison: this field is not intended for comparison (only used for logging)
比較：このフィールドは比較用ではありません（ログ記録にのみ使用されます）
Case folding; case-sensitivity, preserve case: No case folding/ case-sensitive
ケース折りたたみ;大文字と小文字を区別、大文字と小文字を保持：大文字と小文字を区別しない/大文字と小文字を区別
Do users input the strings directly? Yes. Possibly entered in configuration UIs, or on a command line. Can also be stored in configuration files. The value can also be automatically generated by clients (e.g., a fixed string is used, or a user's email address).
ユーザーは文字列を直接入力しますか？はい。構成UIまたはコマンドラインで入力した可能性があります。設定ファイルに保存することもできます。この値は、クライアントが自動的に生成することもできます（たとえば、固定文字列が使用されたり、ユーザーの電子メールアドレスが使用されたりします）。
How users input strings? Keyboard/voice, stylus (pick from a list). Copy-paste - possibly.
ユーザーはどのように文字列を入力しますか？キーボード/音声、スタイラス（リストから選択）。コピー＆ペースト-おそらく。
Normalization: None.
正規化：なし。
Disallowed Characters: Control characters are disallowed. (See Section 3 of RFC 4505).
使用できない文字：制御文字は使用できません。 （RFC 4505のセクション3をご覧ください）。
Which other strings or identifiers are these most similar to? RFC 4505 says that the trace "should take one of two forms: an Internet email address, or an opaque string that does not contain the '@' (U+0040) character and that can be interpreted by the system administrator of the client's domain". In practice, this is a free-form text, so it belongs to a different class from "email address" or "username".
これらに最も類似している他の文字列または識別子はどれですか？ RFC 4505によると、トレースは「インターネット電子メールアドレス、または '@'（U + 0040）文字を含まず、クライアントのドメインのシステム管理者が解釈できる不透明な文字列のいずれかでなければなりません」 」実際には、これは自由形式のテキストであるため、「メールアドレス」や「ユーザー名」とは異なるクラスに属しています。
Are these strings or identifiers sometimes the same as strings or identifiers from other protocols (e.g., does an IM system sometimes use the same credentials database for authentication as an email system)? Yes: see above. However, there is no strong need to keep them consistent in the future.
これらの文字列または識別子は、他のプロトコルの文字列または識別子と同じである場合がありますか（たとえば、IMシステムは、メールシステムと認証に同じ資格情報データベースを使用する場合があります）？はい：上記を参照してください。ただし、将来的に一貫性を保つ必要はありません。
How are users exposed to these strings, how are they published? No. However, the value can be seen in server logs.
ユーザーはこれらの文字列にどのようにさらされ、どのように公開されますか？いいえ。ただし、値はサーバーログに表示されます。
Impacts of false positives and false negatives: False positive: a user can be confused with another user. False negative: two distinct users are treated as the same user. But note that the trace field is not authenticated, so it can be easily falsified.
誤検知と誤検知の影響：誤検知：ユーザーが別のユーザーと混同される可能性があります。偽陰性：2人の異なるユーザーが同じユーザーとして扱われます。ただし、トレースフィールドは認証されないため、簡単に改ざんされる可能性があることに注意してください。
Tolerance of changes in the community: The community would be flexible.
コミュニティの変化への耐性：コミュニティは柔軟です。
Delimiters: No internal structure, but see comments above about frequent use of email addresses.
区切り文字：内部構造はありませんが、電子メールアドレスの頻繁な使用に関する上記のコメントを参照してください。
Background Information: RFC 4505, Section 2 ("The Anonymous Mechanism"):
背景情報：RFC 4505、セクション2（「匿名メカニズム」）：
The mechanism consists of a single message from the client to the server. The client may include in this message trace information in the form of a string of [UTF-8]-encoded [Unicode] characters prepared in accordance with [StringPrep] and the "trace" stringprep profile defined in Section 3 of this document. The trace information, which has no semantical value, should take one of two forms: an Internet email address, or an opaque string that does not contain the '@' (U+0040) character and that can be interpreted by the system administrator of the client's domain. For privacy reasons, an Internet email address or other information identifying the user should only be used with permission from the user.
このメカニズムは、クライアントからサーバーへの単一のメッセージで構成されます。クライアントは、このメッセージに、[StringPrep]およびこのドキュメントのセクション3で定義されている「トレース」stringprepプロファイルに従って作成された[UTF-8]エンコード[Unicode]文字の文字列の形式でトレース情報を含めることができます。意味的な値を持たないトレース情報は、インターネット電子メールアドレス、または '@'（U + 0040）文字を含まず、システム管理者が解釈できる不透明な文字列のいずれかの形式を取る必要があります。クライアントのドメイン。プライバシー上の理由から、インターネットメールアドレスまたはユーザーを特定するその他の情報は、ユーザーの許可を得た場合にのみ使用してください。
RFC 4505, Section 3 ('The "trace" Profile of "Stringprep"'): This section defines the "trace" profile of [StringPrep]. This profile is designed for use with the SASL ANONYMOUS Mechanism. Specifically, the client is to prepare the <message> production in accordance with this profile.
RFC 4505、セクション3（「Stringprepの「トレース」プロファイル」）：このセクションでは、[StringPrep]の「トレース」プロファイルを定義します。このプロファイルは、SASL ANONYMOUSメカニズムで使用するように設計されています。具体的には、クライアントはこのプロファイルに従って<message>プロダクションを準備します。
The character repertoire of this profile is Unicode 3.2 [Unicode].
このプロファイルの文字レパートリーは、Unicode 3.2 [Unicode]です。
No mapping is required by this profile.
このプロファイルではマッピングは必要ありません。
No Unicode normalization is required by this profile.
このプロファイルでは、Unicodeの正規化は必要ありません。
The list of unassigned code points for this profile is that provided in Appendix A of [StringPrep]. Unassigned code points are not prohibited.
このプロファイルに割り当てられていないコードポイントのリストは、[StringPrep]の付録Aに記載されています。割り当てられていないコードポイントは禁止されていません。
Characters from the following tables of [StringPrep] are prohibited:
次の[StringPrep]の表の文字は禁止されています。
- C.2.1 (ASCII control characters) - C.2.2 (Non-ASCII control characters) - C.3 (Private use characters) - C.4 (Non-character code points) - C.5 (Surrogate codes) - C.6 (Inappropriate for plain text) - C.8 (Change display properties are deprecated) - C.9 (Tagging characters)
- C.2.1（ASCII制御文字）-C.2.2（非ASCII制御文字）-C.3（私用文字）-C.4（非文字コードポイント）-C.5（サロゲートコード）-C. 6（プレーンテキストには不適切）-C.8（表示プロパティの変更は非推奨）-C.9（文字のタグ付け）
No additional characters are prohibited.
追加の文字は禁止されていません。
This profile requires bidirectional character checking per Section 6 of [StringPrep].
このプロファイルでは、[StringPrep]のセクション6に従って双方向文字チェックが必要です。
Description: Localpart of JabberID ("JID"), as in:
localpart@domainpart/resourcepart
How It's Used:
- Usernames (e.g., stpeter@jabber.org)
- Chatroom names (e.g., precis@jabber.ietf.org)
- Publish-subscribe nodes
- Bot names
Who Generates It: - Typically, end users via an XMPP client - Sometimes created in an automated fashion
誰が生成するか-通常、XMPPクライアントを介したエンドユーザー-自動化された方法で作成されることもあります。
User Input Methods: - typing - copy and paste - voice input - clicking a URI/IRI
ユーザー入力方法：-入力-コピーして貼り付け-音声入力-URI / IRIをクリック
Enforcement: Rules enforced by server / add-on service (e.g., chatroom service) on registration of account, creation of room, etc.
施行：サーバー/アドオンサービス（チャットルームサービスなど）によってアカウントの登録、部屋の作成などに施行されるルール
Comparison Method: "Type 2" (common algorithm)
比較方法：「タイプ2」（共通アルゴリズム）
Case Folding, Sensitivity, Preservation: - Strings are always folded to lowercase - Case is not preserved
大文字、小文字、区別、保持：-文字列は常に小文字に変換されます-大文字は保持されません
Impact of Comparison: False positives: - unable to authenticate at server (or authenticate to wrong account) - add wrong person to buddy list - join the wrong chatroom - improperly grant privileges (e.g., chatroom admin) - subscribe to wrong pubsub node - interact with wrong bot - allow communication with blocked entity
比較の影響：誤検知：-サーバーで認証できない（または間違ったアカウントで認証する）-バディリストに間違った人を追加する-間違ったチャットルームに参加する-不適切に特権を付与する（例：チャットルーム管理者）-間違ったpubsubノードにサブスクライブする-対話する間違ったボット-ブロックされたエンティティとの通信を許可
False negatives: - unable to authenticate - unable to add someone to buddy list - unable to join desired chatroom - unable to use granted privileges (e.g., chatroom admin) - unable to subscribe to desired pubsub node - unable to interact with desired bot - disallow communication with unblocked entity
偽陰性：-認証できない-誰かをバディリストに追加できない-目的のチャットルームに参加できない-付与された特権を使用できない（例：チャットルーム管理者）-目的のpubsubノードにサブスクライブできない-目的のボットと対話できない-許可しないブロックされていないエンティティとの通信
Normalization: NFKC
正規化：NFKC
Mapping: Spaces are mapped to nothing
マッピング：スペースは何にもマッピングされていません
Disallowed Characters: ",&,',/,:,<,>,@
String Classes: - Often similar to generic username - Often similar to localpart of email address - Sometimes same as localpart of email address
文字列クラス：-一般的なユーザー名によく似ている-電子メールアドレスのローカルパートによく似ている-電子メールアドレスのローカルパートと同じである場合がある
Internal Structure: None
内部構造：なし
User Output: - vCard - email signature - web page / directory - text of message (e.g., in a chatroom)
ユーザー出力：-vCard-メールの署名-Webページ/ディレクトリ-メッセージのテキスト（チャットルームなど）
Operations: Sometimes concatenated with other data and then used as input to a cryptographic hash function
操作：時々他のデータと連結され、暗号化ハッシュ関数への入力として使用されます
Description:
- Resourcepart of JabberID ("JID"), as in:
localpart@domainpart/resourcepart
- Typically free-form text
How It's Used:
- Device / session names (e.g., stpeter@jabber.org/Home)
- Nicknames (e.g., precis@jabber.ietf.org/StPeter)
Who Generates It: - Often human users via an XMPP client - Often generated in an automated fashion by client or server
誰が生成するか-多くの場合、XMPPクライアントを介して人間のユーザー-クライアントまたはサーバーによって自動化された方法で生成されることが多い
User Input Methods: - typing - copy and paste - voice input - clicking a URI/IRI
ユーザー入力方法：-入力-コピーして貼り付け-音声入力-URI / IRIをクリック
Enforcement: Rules enforced by server / add-on service (e.g., chatroom service) on account login, joining a chatroom, etc.
施行：サーバー/アドオンサービス（チャットルームサービスなど）がアカウントログイン、チャットルームへの参加などに施行するルール
Comparison Method: "Type 2" (byte-for-byte)
比較方法：「タイプ2」（バイト単位）
Case Folding, Sensitivity, Preservation: - Strings are never folded - Case is preserved
ケースの折りたたみ、感度、保持：-文字列は折りたたまれません-ケースは保持されます
Impact of Comparison: False positives: - interact with wrong device (e.g., for file transfer or voice call) - interact with wrong chatroom participant - improperly grant privileges (e.g., chatroom moderator) - allow communication with blocked entity False negatives: - unable to choose desired chatroom nickname - unable to use granted privileges (e.g., chatroom moderator) - disallow communication with unblocked entity
比較の影響：誤検知：-誤ったデバイスとのやり取り（ファイル転送や音声通話など）-誤ったチャットルーム参加者とのやり取り-権限の不適切な付与（チャットルームモデレーターなど）-ブロックされたエンティティとの通信の許可偽陰性：-できません目的のチャットルームニックネームを選択-付与された権限を使用できない（例：チャットルームモデレーター）-ブロックされていないエンティティとの通信を許可しない
Normalization: NFKC
正規化：NFKC
Mapping: Spaces are mapped to nothing
マッピング：スペースは何にもマッピングされていません
Disallowed Characters: None
許可されていない文字：なし
String Classes: Basically a free-form identifier
文字列クラス：基本的に自由形式の識別子
Internal Structure: None
内部構造：なし
User Output: - text of message (e.g., in a chatroom) - device names often not exposed to human users
ユーザー出力：-メッセージのテキスト（チャットルームなど）-人間のユーザーには公開されていないことが多いデバイス名
Operations: Sometimes concatenated with other data and then used as input to a cryptographic hash function
操作：時々他のデータと連結され、暗号化ハッシュ関数への入力として使用されます
Description: RFC 3748, Section 5, references Stringprep, but the WG did not agree with the text (was added by IESG) and there are no known implementations that use Stringprep. The main problem with that text is that the use of strings is a per-method concept, not a generic EAP concept and so RFC 3748 itself does not really use Stringprep, but individual EAP methods could. As such, the answers to the template questions are mostly not applicable, but a few answers are universal across methods. The list of IANA registered EAP methods is at <http://www.iana.org/assignments/eap-numbers/eap-numbers.xml>.
説明：RFC 3748、セクション5、はStringprepを参照していますが、WGはテキストに同意しなかったため（IESGによって追加されました）、Stringprepを使用する既知の実装はありません。そのテキストの主な問題は、文字列の使用がメソッドごとの概念であり、一般的なEAPの概念ではないため、RFC 3748自体は実際にはStringprepを使用しませんが、個々のEAPメソッドは使用できます。そのため、テンプレートの質問に対する回答はほとんど当てはまりませんが、いくつかの回答はメソッド全体に共通です。 IANAに登録されているEAPメソッドのリストは、<http://www.iana.org/assignments/eap-numbers/eap-numbers.xml>にあります。
Comparison Methods: n/a (per-method)
比較方法：n / a（メソッドごと）
Case Folding, Case-Sensitivity, Case Preservation: n/a (per-method)
ケースの折りたたみ、大文字と小文字の区別、ケースの保持：n / a（メソッドごと）
Impact of comparison: A false positive results in unauthorized network access (and possibly theft of service if some else is billed). A false negative results in lack of authorized network access (no connectivity).
比較の影響：誤検知の結果、不正なネットワークアクセスが発生します（他に請求されている場合はサービスが盗まれる可能性があります）。偽陰性の結果、承認されたネットワークアクセスがありません（接続なし）。
User input: n/a (per-method)
ユーザー入力：n / a（メソッドごと）
Normalization: n/a (per-method)
正規化：なし（メソッドごと）
Mapping: n/a (per-method)
マッピング：なし（メソッドごと）
Disallowed characters: n/a (per-method)
使用できない文字：n / a（メソッドごと）
String classes: Although some EAP methods may use a syntax similar to other types of identifiers, EAP mandates that the actual values must not be assumed to be identifiers usable with anything else.
文字列クラス：一部のEAPメソッドは、他の種類の識別子と同様の構文を使用する場合がありますが、EAPでは、実際の値は他のもので使用できる識別子であると想定してはなりません。
Internal structure: n/a (per-method)
内部構造：なし（メソッドごと）
User output: Identifiers are never human displayed except perhaps as they're typed by a human.
ユーザー出力：おそらく人間が入力した場合を除いて、識別子が人間に表示されることはありません。
Operations: n/a (per-method) Community considerations: There is no resistance to change for the base EAP protocol (as noted, the WG didn't want the existing text). However, actual use of Stringprep, if any, within specific EAP methods may have resistance. It is currently unknown whether any EAP methods use Stringprep.
操作：該当なし（メソッドごと）コミュニティの考慮事項：基本EAPプロトコルの変更に対する抵抗はありません（前述のように、WGは既存のテキストを望んでいませんでした）。ただし、特定のEAPメソッド内でStringprepを実際に使用すると、抵抗が生じる可能性があります。現在、EAPメソッドでStringprepを使用するかどうかは不明です。
Authors' Addresses
著者のアドレス
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://viagenie.ca
Andrew Sullivan Dyn, Inc. 150 Dow St Manchester, NH 03101 U.S.A.
Andrew Sullivan Dyn、Inc.150 Dow St Manchester、NH 03101 U.S.A.
EMail: asullivan@dyn.com