演算 [6] 「PRECIS」は、「pr eparation, e nforcement, and
c omparison of i nternationalized s trings」の意味です >>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] 例えば大文字 を小文字 に変換したり、正規化 したりすると、
元の状態には復元できないのが普通です。
プロファイル [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 [70] Character mapping "rfc7613:non-ASCII-space" (2016-01-04 23:28:24 +09:00 版) https://chars.suikawiki.org/map/rfc7613%3Anon-ASCII-space [71] Character mapping "rfc7700:non-ASCII-space" (2016-01-04 23:29:00 +09:00 版) https://chars.suikawiki.org/map/rfc7700%3Anon-ASCII-space [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
[7] PRECIS は文字集合 や写像 を直接規定するのではなく、
符号位置 の特性 によって定義する形を採っており、
Unicode の改版に追随できる >>5
Stringprep では Unicode 3.2 固定とされていました。[9] 決定方法が規定 とされている一方で、最新の Unicode
に適用した結果が IANA登録簿 に登録される >>5 導出特性値 を参照。[30] stpeter/PrecisMaker
(2016-01-02 23:12:57 +09:00 版)
https://github.com/stpeter/PrecisMaker
[64] RFC 7613 利用者名 (PRECIS) として
UsernameCasePreserved UsernameCaseMapped 合言葉 (PRECIS) として OpaqueString プロファイル を定義しました。
[65] これらは SASLprep を廃止 しその代替として定義されたものですが、
SASLprep とこれらのプロファイル には互換性はありません。[68] RFC 7700 ニックネーム 用のプロファイル として
Nickname
[73] 施行 - Wikipedia
(2016-01-09 19:28:05 +09:00 版)
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)
(2016-03-31 03:20:06 +09:00 版)
https://tools.ietf.org/html/rfc7790
[77] Add document for rfc7700 casemapping by DanielOaks · Pull Request #272 · ircv3/ircv3-specifications
( (2016-12-13 22:50:56 +09:00 ))
https://github.com/ircv3/ircv3-specifications/pull/272
[78] RFC 8146 - Adding Support for Salted Password Databases to EAP-pwd
(2017-04-22 11:18:27 +09:00 )
https://tools.ietf.org/html/rfc8146
[79] RFC 8120 - Mutual Authentication Protocol for HTTP
(2017-04-20 12:04:06 +09:00 )
https://tools.ietf.org/html/rfc8120#section-9