UsernameCaseMapped

PRECIS (IETF)

[76] PRECIS は、文字列比較等の演算に関する IETF仕様です。

仕様書

演算

[6] 「PRECIS」は、「preparation, enforcement, and comparison of internationalized strings」の意味です >>5

[10] PRECIS文字列に対する次のような演算を扱います。

[18] 執行 (enforcement)
ある文字列に対して、 その文字列が特定の文脈で使うことができるかどうかを決定するため、 特定の文字列クラスプロファイルに関する規則をすべて適用することをいいます >>17
[19] 比較 (comparison)
2つの文字列に対して、 両者が等価 (equivalent) かどうかを決定するため、 特定の文字列クラスプロファイルに関する規則をすべて適用することをいいます >>17
[20] 準備 (preparation)
ある文字列に対して、 特定の文字列クラスプロファイルに関する規則の一部を適用、 あるいは何も適用しないことをいいます >>17, >>54

[47] 準備執行比較について、 どの実体 (サーバークライアントなど) が責任を持つか、 具体的にいつ行うかは、 応用が規定する必要があります >>46

[21] ほとんどの場合、サーバーのような決定権を持つ側は執行する責任があり、 その他のクライアントなどの側は準備だけすれば十分です。 これは次のような理由からとされています。 >>17

[8] PRECIS では、文字列に対する操作の単位を規則 (rule) と呼んでいます。 最低限の規則を文字列クラスと呼び、 それに更に規則を組み合わせたものをプロファイルと呼んでいます。

[49] 応用は、 どのプロトコル要素に対してプロファイルを使うかを規定する必要があります >>46

規則の適用

[52] 文字列クラスプロファイルの規則は、 次の順序で適用しなければなりません >>51

  1. 幅写像規則
  2. 追加写像規則
  3. 大文字・小文字写像規則
  4. 正規化規則
  5. 方向性規則
  6. 挙動的規則
[59] 執行比較はこれをすべて適用する必要がありますが、 準備は (応用の規定に従い) 一部のみ適用すれば足ります。

[61] 実際の各プロファイルは、執行比較準備の後に実行すると規定しています >>60, >>62, >>63, >>66。 これは >>52 の規定と矛盾しています。

[69] しかも準備の時点で UTF-8符号化することになっていて >>60, >>62, >>63, >>66、 その後の処理はバイト列に対して行うことになってしまいます。

[50] 応用は、文字列クラスプロファイルから更に除外する符号位置を (符号位置符号位置特性を使って) 規定できます >>46

[48] プロファイルの追加制限 (>>57) やこの応用の制限 (>>50) は挙動的規則の適用後に更に検査するものと思われます。

[15] なお、 PRECIS の規則を適用する操作は、基本的には不可逆です >>5

[16] 例えば大文字小文字に変換したり、正規化したりすると、 元の状態には復元できないのが普通です。

文字列クラス

[29] 文字列クラス (string class) >>13 は、挙動的規則を定めています。 その他の規則は、文字列クラスプロファイル (>>32) で定めることになります。

挙動的規則

[56] 挙動的規則 (behavioral rule) は、 次の4つを定めるものです >>13

妥当 (valid)
文字列において妥当として扱われる符号位置
文脈的規則必須 (contextual rule required)
文脈的規則 (CONTEXTJ / CONTEXTO) が満たされる時だけ認められると扱われる符号位置
禁止 (disallowed)
文字列から除外される必要がある符号位置
未割当 (unassigned)
応用が使う Unicode の版で未知の符号位置が現れた時の応用の挙動。

文字列クラスの一覧

[14] 次の2つの文字列クラスがあります。

name
名前
cp
割当済み符号位置の挙動
unassigned
未割当の扱い
desc
説明
context
利用される場面
name
IdentifierClass
desc
利用者アカウントvenue (チャット室など)、 情報源 (データフィードなど)、データの集成 (ファイルなど) といったネットワーク上の実体識別したり、番地付けしたりするための、 letter数字や一部の記号の列です。 いろいろなアプリケーションプロトコルでの利用者の混乱を最小化させ、 表現力よりも安全性を優先させることを意図したものです。 >>13
cp
PRECIS導出特性値によります (ID_DIS は「禁止」として扱います)。
unassigned
「禁止」として扱います。 >>13
context
利用者名 (PRECIS)
name
FreeformClass
desc
合言葉や、 装置チャット室の参加者の人間向けのニックネームのような表示要素など、 自由形の文字列に使う、 letter数字記号間隔やその他の文字の列です。 ほとんどどんな Unicode文字も使うことができ、 安全性よりも表現力を優先させることを意図したものです。 >>13
cp
PRECIS導出特性値によります (FREE_PVAL は「妥当」として扱います)。
unassigned
「禁止」として扱います。 >>13
context
合言葉 (PRECIS)

[27] RFC 7564 は、 IETF の議論の結果としてこの2つの文字列クラスを規定していますが、 将来これ以外の文字列クラスを定義する可能性も排除はしていません >>13

[26] IANA登録簿 >>54 も用意されています >>53

[144]特性値を持つ符号位置の一覧が >>141>>140 にあります。 JSON 形式のデータファイルが >>142 (説明が >>143) にあります。

プロファイル

[32] PRECIS文字列クラスプロファイル (profile) は、 文字列クラスに更に規則を追加するものです。

[28] プロファイルは、幅写像規則追加写像規則 (あれば)、 大文字・小文字写像規則正規化規則方向性規則を定義しなければなりません >>31

[57] プロファイルは、認められる文字を更に制限することができます >>31

[58] しかし、文字列クラスで禁止されている符号位置を認めてはなりません >>31

写像規則

[34] 幅写像規則 (width mapping rule) は、 文字列に対して幅写像を適用するかどうかとどのように写像するかを規定するものです。 普通は、 Decomposition TypeWideNarrow符号位置を、 分解写像へと写像するものです。 >>31

[35] NFKCNFKD の場合は互換分解の一部として幅写像が行われるので、 プロファイルで規定する必要はありません。 >>31

[36] NFC を使う場合、普通は幅写像を使うべきです >>31

[37] 追加写像規則 (additional mapping rule) は、 文字列中の区切り文字 (@, :, /, +, - など) や特殊文字 (非ASCII間隔U+0020制御文字 → なしなど) について追加の写像を行うかどうかを規定するものです >>31

[38] 大文字・小文字写像規則 (case mapping rule) は、 文字列に大文字・小文字の写像を適用するかどうかやどう写像するかを規定するものです。 >>31

[39] 写像する場合には、 UnicodeDefault Case Folding を使うべきです >>31

[40] FreeformClass やそのプロファイル合言葉に使う場合は、 大文字titlecase小文字に変換するべきではなく、 元の大文字小文字の区別を保存するべきです >>31

正規化規則

[41] 正規化規則 (normalization rule) は、 適用する正規化NFCNFDNFKCNFKD から指定するものです >>31

[42] NFC を使うべきです >>31

[43] 正規化しないという選択肢はなさそうです。

方向性規則

[44] 方向性規則 (directionality rule) は、 RTL 文字を含む文字列をどう扱うかを規定するものです >>31

[45] PRECIS は、 Unicodebidi アルゴリズムの他には広く受け入れられ実装されている安全な表示の方法はないとして、 具体的な方向性の規則は定義していません。 IDNA2008 (RFC 5893) はドメイン名用の Bidi Ruleを定義しており、 必要ならば (新たに定義するのではなく) それを使うことを強く提案 (strongly suggest) しています。 応用によって新たな規則が必要だと思われるとしても、問題が複雑なので誤った判断であることが多いとして、 再考を促しています。 >>31

プロファイルの一覧

[72] 次のプロファイルが定義されています。

name
プロファイル名
width
幅写像規則
addmap
追加写像規則
case
大文字・小文字写像規則
norm
正規化規則
dir
方向性規則
behavior
挙動的規則
context
利用される場面
note
備考
name
UsernameCaseMapped >>60
width
(準備執行比較) 全角文字半角文字UAX #11 分解写像適用
addmap
なし
case
(執行比較) Default Case Folding
norm
(執行比較) NFC
dir
(執行比較) RFC 5893 Bidi Rule
behavior
(準備執行比較) IdentifierClass
context
利用者名 (PRECIS)JID localpart
note
>>61
name
UsernameCasePreserved >>62
width
(準備執行比較) 全角文字半角文字UAX #11 分解写像適用
addmap
なし
case
なし
norm
(執行比較) NFC
dir
(執行比較) RFC 5893 Bidi Rule
behavior
(準備執行比較) IdentifierClass
context
利用者名 (PRECIS)基本認証 UTF-8ダイジェスト認証 UTF-8
note
>>61
name
OpaqueString >>63
width
なし
addmap
(執行比較) 非ASCII間隔ASCII間隔 (>>70)
case
なし
norm
(執行比較) NFC
dir
なし
behavior
(準備執行比較) FreeformClass
context
合言葉 (PRECIS)基本認証 UTF-8ダイジェスト認証 UTF-8JID resourcepart
note
>>61
name
Nickname >>66, >>67
width
なし
addmap
(執行比較) 非ASCII間隔ASCII間隔 (>>71)、 先頭と末尾のASCII間隔除去、 連続したASCII間隔ASCII間隔1つに
case
(比較) Default Case Folding
norm
(執行比較) NFKC
dir
なし
behavior
(準備執行比較) FreeformClass

[33] プロファイルには、 IANA登録簿 >>54 があります >>31, >>53

関連

[74] RFC 4790 と若干用途がかぶっているようですが、関係は特に規定されていません。

歴史

Stringprep から PRECIS へ

[1] IDNA2003 や、その他の識別子等を扱う IETF の各種プロトコルは、 RFC 3454 Stringprep によって Unicode 文字列正規化を行っていました。

Stringprep も参照。

[2] しかし StringprepUnicode 3.2 に固定されその後改版できずに放置されているなど、 色々な問題を抱えていました。 IDNA2008Stringprep を放棄して独自路線に進みました。 (もっともその路線は市場には支持されず、 Stringprep を別の形で拡張した UTS #46 が使われているわけですが...)

[145] RFC 6885Stringprepプロファイルとその問題点をまとめたものです。 StringprepUnicode 3.2 に固定されているなど問題があり IDNA2008Stringprep を使わなくなりましたが、 新しいプロトコルは改版可能であるなど DNS とは事情が異なるとして、それとは別の方法で Stringprep を改良する必要があると指摘し、プロファイルの用法を分析しています。

[146] これを踏まえて IETF では「Preparation and Comparison of Internationalized Strings」を略して「PRECIS」 と称し、 Stringprep を改訂するべく PRECIS WG を設置しました。

PRECIS の開発

[141] draft-ietf-precis-problem-statement-02 - Stringprep Revision Problem Statement ( ( 版)) <http://tools.ietf.org/search/draft-ietf-precis-problem-statement-02>

[112] draft-ietf-precis-mappings-08 - Mapping characters for PRECIS classes ( 版) <https://tools.ietf.org/html/draft-ietf-precis-mappings-08>

[147] draft-ietf-precis-nickname-16 - Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames ( 版) <https://tools.ietf.org/html/draft-ietf-precis-nickname-16>

[148] draft-ietf-precis-saslprepbis-14 - Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords ( 版) <https://tools.ietf.org/html/draft-ietf-precis-saslprepbis-14>

[149] draft-ietf-precis-framework-23 - PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols ( 版) <https://tools.ietf.org/html/draft-ietf-precis-framework-23>

[150] JPRSの米谷嘉朗がIETF PRECISワーキンググループの共同議長に就任 / 株式会社日本レジストリサービス(JPRS) ( 版) <http://jprs.co.jp/press/2010/100615.html>

[151] stpeter/precis-framework ( 版) <https://github.com/stpeter/precis-framework>

RFC 7564

[4] 2015年に PRECIS 全体を規定する RFC 7564 が出版され、 RFC 3454廃止されました。 引き続き同年中に各種プロファイルが出版されています。

[11] 前身の Stringprep はいくつかの文字集合写像を定義した上で、 応用ごとにどれを利用するか決定し、「プロファイル」 とする形を採っていました。

[12] それに対して PRECIS は、文字列クラスを少数定義しており、 応用は必要に応じてそれに規則を追加してプロファイルとすることも認められてはいるものの、 応用ごとにプロファイルをどんどん増やしていくのは驚き最小の原則違反であるから非推奨 (discouraged) であり禁止 (must not) する >>5, >>31, >>46 としています。原則として文字列クラスを共用とすることで、 ライブラリーのような形で応用間で符号位置の表を共用できる >>5 とされています。利用者もいろいろな文脈でどの文字が使えるか正確に予測できる >>5 ともされています。

[7] PRECIS文字集合写像を直接規定するのではなく、 符号位置特性によって定義する形を採っており、 Unicode の改版に追随できる >>5 とされています。

Stringprep では Unicode 3.2 固定とされていました。
[9] 決定方法が規定とされている一方で、最新の Unicode に適用した結果が IANA登録簿に登録される >>5 こととされています。 導出特性値を参照。

[30] stpeter/PrecisMaker ( 版) <https://github.com/stpeter/PrecisMaker>

[64] RFC 7613利用者名 (PRECIS) として UsernameCasePreservedUsernameCaseMapped合言葉 (PRECIS) として OpaqueString の3つのプロファイルを定義しました。

[65] これらは SASLprep廃止しその代替として定義されたものですが、 SASLprep とこれらのプロファイルには互換性はありません。

[68] RFC 7700ニックネーム用のプロファイルとして Nickname を定義しました。

[73] 施行 - Wikipedia ( 版) <https://ja.wikipedia.org/wiki/%E6%96%BD%E8%A1%8C>

[75] RFC 7790 - Mapping Characters for Classes of the Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS) ( 版) <https://tools.ietf.org/html/rfc7790>

[77] Add document for rfc7700 casemapping by DanielOaks · Pull Request #272 · ircv3/ircv3-specifications ( ()) <https://github.com/ircv3/ircv3-specifications/pull/272>

[78] RFC 8146 - Adding Support for Salted Password Databases to EAP-pwd () <https://tools.ietf.org/html/rfc8146>

[79] RFC 8120 - Mutual Authentication Protocol for HTTP () <https://tools.ietf.org/html/rfc8120#section-9>