[1] stringprep は、 IETF の規格で文字列の正規化を行うために定義された枠組みです。 IDN などの識別子で使われています。
[3] Stringprep の処理は大きく4段階に分かれます。実装はこの順番に処理しなければなりません >>2 2.。この処理の入力は処理対象の文字列であり、 出力は処理結果の文字列か、または誤りのいずれかです。 (誤りかつ文字列が返されることはありません。 >>2 5.、6.)
[53] >>54 と >>55 では文字列の長さが増減することがあり、実装はこれに備えなければなりません >>2 2.。
[5] RFC 3454 は Unicode 3.2 に基づいています。 基本的に RFC 3454 とそれに基づくプロファイルは Unicode 3.2 に基づき設計されることになります。 RFC 3454 は新しい版の Unicode で使うことが想定されていないと明確に述べています >>2 1.2。
[48] RFC 3454 は新しい版の Unicode に対応した新しい版のプロファイルを作ってもプロファイルを使うプロトコルを全面改訂したりしなくて済むように、 写像表などの非互換変更を禁じたり、 未定義符号位置の処理に関する規定 (>>4) を設けたりしています。
[49] Stringprep のプロファイルは、利用する文字レパートリを選択しなければなりません >>2 1.2。 ただし、現在規定されているのは Unicode 3.2 レパートリ >>2 A. のみで、他の選択肢はありません。
[50] 文字レパートリは固定されたものではなく、将来の改訂で文字が追加されることがあります >>2 1.2。
[52] Unicode 3.2 文字レパートリにおける未定義の符号位置の一覧も RFC で定義されています >>2 A.。実装は Unicode 3.2 の仕様ではなく、この RFC の一覧に基づいて処理しなければなりません >>2 A., >>2 7.。
[118] 特定の Stringprep である符号位置がどう処理されるかにより、 符号位置は次の4つのカテゴリーのいずれかに分類できます >>2 7.1。
[123] IDNA2008 もこれと似た導出特性値という概念を規定していますが、 IDNA2008 では Unicode の特性から直接的に定義されていて、ここでの分類とは大きく異なります。
[59] Stringprep で使用する写像表はプロファイル毎に規定します。
[60] 基本的には Stringprep 仕様で予め定義された表を使うべきですが、 必要なら独自に定義しても構いません。 >>2 3.
[62] B.1 Commonly mapped to nothing http://tools.ietf.org/html/rfc3454#appendix-B.1
[63] この表は、SOFT HYPHEN、ZERO WIDTH JOINER、
異体字選択子など、含まれていてもいなくても同じ識別子とみなされるべき >>2 3.1
文字を零文字に置き換える (削除する) ものです。
[64] B.2 Mapping for case-folding used with NFKC http://tools.ietf.org/html/rfc3454#appendix-B.2
[66] B.3 Mapping for case-folding used with no normalization http://tools.ietf.org/html/rfc3454#appendix-B.3
[67] この写像表は、正規化しない場合のための大文字から小文字に変換するものです >>2 3.2。
[72] この写像表は Unicode 3.2 の CaseFolding-3.txt に基づいています >>2 3.2。
[68] 大文字・小文字不区別としたい場合には、附属書B.2 (>>62) または附属書B.3 (>>64) を使って写像するべきです >>2 3.2。
[70] しかし独自の写像表を使いたいのなら、 UTR #21 に基づくべきであり、 大文字から小文字に変換するべきです。 CaseFolding.txt に基づいて写像表を作るべきであり、完全な大文字・小文字の写像 を使う (状態 C, F, I を使う) べきです。 >>2 3.2
[71] NFKC を使うなら、 UTR #21 では写像されてなくても処理が必要な文字があるため、 注意が必要です。 (一部のギリシャ文字と多くのラテン文字を含む記号が該当します。) これは、
... という方法で求められます。 >>2 3.2
[142] Unicode の正規化形には冪等性に関する不具合がありました。この不具合は訂正 #5 で修正されていますが、それまでは正規化形の実装に2通りの可能性がありました。
[143] Perlモジュール Unicode::Stringprep は、
Stringprep の正規化によってこの2通りの実装方法での差異が生じる列を検出した場合、
失敗として扱います。 >>14
[74] Stringprep で使用する禁止文字の表はプロファイル毎に規定します。
[75] C.1.1 ASCII space characters http://tools.ietf.org/html/rfc3454#appendix-C.1.1
[77] C.1.2 Non-ASCII space characters http://tools.ietf.org/html/rfc3454#appendix-C.1.2
[79] C.2.1 ASCII control characters http://tools.ietf.org/html/rfc3454#appendix-C.2.1
[80] C.2.2 Non-ASCII control characters http://tools.ietf.org/html/rfc3454#appendix-C.2.2
[83] C.3 Private use http://tools.ietf.org/html/rfc3454#appendix-C.3
[85] C.4 Non-character code points http://tools.ietf.org/html/rfc3454#appendix-C.4
[93] PropList.txt >>2 5.4 に基づいているとみられます。
[87] C.5 Surrogate codes http://tools.ietf.org/html/rfc3454#appendix-C.5
[89] C.6 Inappropriate for plain text http://tools.ietf.org/html/rfc3454#appendix-C.6
[90] C.7 Inappropriate for canonical representation http://tools.ietf.org/html/rfc3454#appendix-C.7
[91] C.8 Change display properties or are deprecated http://tools.ietf.org/html/rfc3454#appendix-C.8
[92] C.9 Tagging characters http://tools.ietf.org/html/rfc3454#appendix-C.9
[99] bidi 処理によって ltr と rtl が混在することによる混乱を避けるため、 bidi 的に文字が適当に並べられていることをチェックします。 このチェックはプロファイルにより省略して構いません >>2 6.。
[100] チェックを行う場合、文字列は次の条件をすべて満たさなければなりません >>2 6.。
[108] RFC には附属書に RandALCat文字と LCat文字の一覧が含まれていますが、 他の表とは違って、 Unicode 3.2 の元のデータでなくこの表を使わなければならないとは明記されていません。 単なるミスなのか何か意図があるのかは不明です。
[109] IDNA2008 は、この条件だと最後の文字が結合文字となる場合をカバーしきれておらず、 本来認められるべき文字列であっても排除されてしまうと指摘しています。 そのため代わりに bidi規則を規定しています。
... は禁止されますが、
... は認められます >>2 6.。
[4] まだ文字が割当てられておらず、将来割当てられるかもしれない符号位置についての規定もあります。
[12] Stringprep のプロファイルを適用する文字列は大別して 蓄積文字列と照会の2種類があります >>2 7.。 蓄積文字列はデータベースに登録する項目名のようなもので、 照会はデータベースから項目を取出すために指定する項目名のようなものです。
[113] より新しい版の Unicode で文字が割り当てられると、 それに伴い未定義だった時と正規化の結果が変わってしまうことがあります。 また、写像表や禁止文字も拡充されることがあるでしょう。その時に、 古い版でもし蓄積文字列に未定義の符号位置が含まれていると、 新しい版で Stringprep を適用した結果アクセスできなくなってしまう危険性があります。
[13] IDNA2003 には AllowUnassigned フラグが規定されています。 Nameprep において未定義の符号位置をどう扱うかはこのフラグに依存します。基本的に登録では偽 (蓄積文字列)、lookup では真 (照会) とします。
[36] プロファイルは、次のものを含んでいなければなりません >>2 1.2。
[32] 関係する2つのプロファイルがそれぞれ別々のプロファイルを使っていると、 文字列をどう正規化するか、何が認められるかが違っているため、 相互運用が難しくなります。ですから、新しいプロファイルを無闇に作らず、 既存のプロファイルを流用するよう、強く求められています >>2 1.2。
[35] Stringprep はプロファイル間でできるだけ表を共有することを意図しており、 従ってプロファイルが独自に表を作ることもできるとはいえ、 極力 Stringprep 仕様で定義されている表の組み合わせに依ることが望ましいです >>2 1.2。
[33] プロファイルにおいてできるだけ多くの文字を利用可能としたい場合、 可能な限り、文字の利用を禁止するのではなく他の文字に変換することを選ぶべきです。 >>2 1.2
[34] Stringprep によって文字関係の規格の逝かれているところを「修正」 することもあるいはできるかもしれませんが、それは行うべきではありません >>2 1.2。
[6] Stringprep のプロファイルには IETF合意が必要 >>2 10. であり、 IESG評価が必要 >>2 10. であり、 RFC 化されて IANA に登録されなければなりません >>2 1.2。
[114] 新しい版の文字レパートリに対応した新しい版のプロファイルでは U カテゴリーだった符号位置を D、MN、AO に変更して構いません。 しかし、 AO、MN、D だった符号位置を他のカテゴリーに変更してはなりません >>2 7.1。
ANONYMOUS[157] RFC 4518 は LDAP 用のプロファイルを定義しています。 このプロファイルは stringprep の前や後の処理を含めて規定しています。
[161] Map より前に転符号化を行います。これは Unicode 文字列へと変換する操作です。
[162] Map は、 RFC 3454 の表を使わずに独自の表 (>>163) を使っています。 RFC 3454
の表と若干の出入りがある他、 RFC 3454 で禁止に分類されている文字が除去されたり、
U+0020 に写像されたりします。
[165] Map に case folding (RFC 3454 表 B.2) が含まれるか否かは、 比較方法により変わります。
[164] Prohibit は、 RFC 3454 の表の他に U+FFFD も含まれています。
また RFC 3454 の表A.1 (Unicode 3.2 時点での未定義符号位置) も含まれています
(つまり蓄積文字列 (>>110) に相当します)。 >>167 は禁止される符号位置の一覧です。
[166] 処理の最後に Insignificant Character Handling >>163, >>171 を行います。 これには次の3種類があり、比較方法によりいずれかを選択します。
[168] ここで間隔とは、 SPACE
であって直後に結合文字がないものをいいます。 >>158
[169] ここでハイフンとは、いくつかの文字 (>>170) の直後に結合文字が来ないものをいいます >>158。
[155] >>19 は GNU Libidn で実装されています。 >>19 は >>153、>>154 を経て RFC 4518 となっています。
[150] しかし必要性が不明瞭なのに Stringprep 本家と似て非なるものを制定することになるとは、 この時点で既に技術開発としての Stringprep 族は破綻していたと言わざるを得ませんね。
[151] プロトコルによって細部は違っても全体的な処理の流れは同じだから共通化しようというのが stringprep のはずだったのに、そのフレームワークに合わない改変をするしかなくなって、 しかもそのバリエーションを包含できる stringprep の新版ではなくて、 似て非なる別規格を作ることになったのですから。
[8] RFC 3722 6.1. の表 (共通入力機構不適切文字):
| 符号位置 | 文字名称 |
|---|---|
U+3002 | IDEOGRAPHIC FULL STOP |
[26] RFC 3722 6.2. の表 (禁止済み ASCII 文字):
| 符号位置 |
|---|
U+0000〜U+002C |
U+002F |
U+003B〜U+0040 |
U+005B〜U+0060 |
U+007B〜U+007F |
[9] RFC 3920 / RFC 6122 A.5. の表:
U+0022 | QUOTATION MARK |
U+0026 | AMPERSAND |
U+0027 | APOSTROPHE |
U+002F | SOLIDUS |
U+003A | COLON |
U+003C | LESS-THAN SIGN |
U+003E | GREATER-THAN SIGN |
U+0040 | COMMERTIAL AT |
[18] Nameprep and IDNA Test Vectors http://www.gnu.org/software/libidn/draft-josefsson-idn-test-vectors.html
[20] Savannah Git Hosting - libidn.git/tree - tests/ http://git.savannah.gnu.org/gitweb/?p=libidn.git;a=tree;f=tests
[180] IETF は IDNA と共に Stringprep を開発し、 そのプロファイルである Nameprep を IDNA で用いることとしました。
[181] Stringprep は RFC 3454 として出版されました。
[28] IDNA2003 は Stringprep のプロファイルである Nameprep を使っていましたが、 IDNA2008 は Nameprep を使わずにすべて独自に定義しています。 Nameprep と IDNA2008 にはまったく互換性がありません。
[29] IDNA2008 の RFC では、他の Stringprep を使う応用であるセキュリティ系プロトコルとは要件が異なり (ドメイン名は分かりやすいことが重要だが合言葉は分かりにくいことが重要)、 共通の仕組みを用いることは必ずしも好ましくないと指摘しています。
[145] RFC 6885 は Stringprep のプロファイルとその問題点をまとめたものです。 Stringprep は Unicode 3.2 に固定されているなど問題があり IDNA2008 は Stringprep を使わなくなりましたが、 新しいプロトコルは改版可能であるなど DNS とは事情が異なるとして、それとは別の方法で Stringprep を改良する必要があると指摘し、プロファイルの用法を分析しています。
[146] IETF では「Preparation and Comparison of Internationalized Strings」を略して「PRECIS」 と称しており、 Stringprep の改訂のために PRECIS WG を設けています。
[182] RFC 3454 は PRECIS の RFC 7564 の出版に伴い廃止されています。
[141] RFC 7613 は利用者名や合言葉のための PRECIS プロファイルを規定しています。
[147] RFC 7613 は RFC 4013 SASLprep を廃止しています >>112。 ただし従来の SASLprep を用いる応用は、明示的に改訂しない限り、 PRECIS に自動的に移行するわけではない >>112 とされています。
[14] Unicode::Stringprep - search.cpan.org ( ( 版)) http://search.cpan.org/dist/Unicode-Stringprep/lib/Unicode/Stringprep.pm
[17] GNU Libidn は >>16、>>19 に対応しているらしいです。
[10] なんか >>7 と同じ表が既に存在しているしorz
Stringprep Profiles http://nameprep.org/stringprep.html
[15] http://search.cpan.org/dist/Unicode-Stringprep/lib/Unicode/Stringprep.pm#CAVEATS
* Section 2.4 of [RFC4282] required mappings that are language
specific and that are nearly impossible for intermediate nodes to
perform correctly without information about that language.
* Section 2.4 of [RFC4282] requires normalization of usernames,
which may conflict with local system or administrative
requirements.
* The recommendations in Section 2.4 of [RFC4282] for treatment of
bidirectional characters have proven to be unworkable.
* The prohibition of the use of unassigned code points in
Section 2.4 of [RFC4282] effectively prohibits support for new
scripts.
* No Authentication, Authorization, and Accounting (AAA) client,
proxy, or server has implemented any of the requirements in
Section 2.4 of [RFC4282], among other sections.
[179] NAI は RFC 4282 時代に Stringprep を採用していましたが、 RFC 7542 は >>178 の通り、これが機能しなかったとして、 ただの NFC に変更しています。 PRECIS も使っていません。
[148] RFC 8146 - Adding Support for Salted Password Databases to EAP-pwd () https://tools.ietf.org/html/rfc8146
[149] draft-irtf-cfrg-augpake-08 - Augmented Password-Authenticated Key Exchange (AugPAKE) () https://tools.ietf.org/html/draft-irtf-cfrg-augpake-08