PRECIS (IETF)

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

仕様書

[3] RFC 7564 - PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols (2015-12-21 04:49:41 +09:00 版) https://tools.ietf.org/html/rfc7564
[55] RFC Errata Report » RFC Editor (2016-01-03 15:25:30 +09:00 版) https://www.rfc-editor.org/errata_search.php?rfc=7564
[54] Preparation and Comparison of Internationalized Strings (PRECIS) Parameters (2015-12-18 04:08:22 +09:00 版) https://www.iana.org/assignments/precis-parameters/precis-parameters.xhtml
[60] RFC 7613 - Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords (2015-10-23 06:11:01 +09:00 版) https://tools.ietf.org/html/rfc7613#section-3.2
[62] RFC 7613 - Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords (2015-10-23 06:11:01 +09:00 版) https://tools.ietf.org/html/rfc7613#section-3.3
[63] RFC 7613 - Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords (2015-10-23 06:11:01 +09:00 版) https://tools.ietf.org/html/rfc7613#section-4.2
[66] RFC 7700 - Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames (2016-01-01 00:50:37 +09:00 版) https://tools.ietf.org/html/rfc7700
[67] RFC Errata Report » RFC Editor (2016-01-04 22:45:26 +09:00 版) https://www.rfc-editor.org/errata_search.php?rfc=7700

演算

[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

[22] クライアントはメモリーや処理能力が劣っているかもしれませんが、サーバーは十分な能力を持つのが普通です。
[23] クライアント側はそもそも利用者に入力させる文字を制限するのが簡単です。
[24] 番地や識別子で使える文字について決定権を持つのはサーバーです。
[25] クライアントが適切に文字列を生成することは (特にセキュリティーに関わる場面では) 信用できません。

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

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

規則の適用

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

幅写像規則
追加写像規則
大文字・小文字写像規則
正規化規則
方向性規則
挙動的規則

[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 Type が Wide や Narrow の符号位置を、分解写像へと写像するものです。 >>31

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

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

[80] 関連: 文字幅

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

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

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

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

正規化規則

[41] 正規化規則 (normalization rule) は、適用する正規化を NFC、NFD、NFKC、NFKD から指定するものです >>31。

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

[43] 正規化しないという選択肢はなさそうです。正規化は、一部(だけ)の漢字の旧字体が新字体に置換されるなどの破壊的操作です。人間可読の文字列に適用するのは好ましくないと考えられています。正規化つまり PRECIS は一般的な文字列には適用できません。

方向性規則

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

[45] PRECIS は、 Unicode の bidi アルゴリズムの他には広く受け入れられ実装されている安全な表示の方法はないとして、具体的な方向性の規則は定義していません。 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-8、 JID 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。

歴史

Stringprep から PRECIS へ

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

Stringprep も参照。

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

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

[144] RFC 6885 - Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS) (2013-07-29 10:54:24 +09:00 版) http://tools.ietf.org/html/rfc6885

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

PRECIS の開発

[141] draft-ietf-precis-problem-statement-02 - Stringprep Revision Problem Statement ( (2011-04-01 08:20:57 +09:00 版)) http://tools.ietf.org/search/draft-ietf-precis-problem-statement-02

[112] draft-ietf-precis-mappings-08 - Mapping characters for PRECIS classes (2014-12-30 20:53:58 +09:00 版) 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 (2015-03-03 17:06:31 +09:00 版) 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 (2015-03-03 17:19:07 +09:00 版) 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 (2015-02-24 08:26:08 +09:00 版) https://tools.ietf.org/html/draft-ietf-precis-framework-23

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

[151] stpeter/precis-framework (2015-03-22 21:14:12 +09:00 版) 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 ともされています。