要約

  • RFC 3987はUnicodeで読める識別子を導入したが、正規化を第三者の万能な書換権にはしなかった。
  • 作成時の準備、転送用URI写像、局所比較、名前検証、到達結果には別々の証拠が要る。

RFC 3987は2005年1月、IRIをURIとは別の補完的なプロトコル要素として定義した。ステータス、正誤表、Datatrackerに残る狙いは、URIの定義を変更せず、Unicode文字列から機能的に対応するURIへの決定的な写像を用意することだった。

ここで重要なのは、決定的な写像と同一性判定が別物だという点である。元のIRI、UTF-8やUTF-16のオクテット列、パーセント符号化されたURI、比較用キー、名前解決結果、アプリケーション応答は、同じ処理列に属しても同じ証拠ではない。

RFC 3986のステータス、正誤表、履歴は、URI比較が目的ごとの段階を持つことを示す。RFC 3987では、単純比較でさえバイト列比較ではない。同じ文字列をUTF-8とUTF-16で格納すればビットは異なるため、共通の文字符号化形式へ変換し、コードポイントごとに比べる。

しかし、その前にIRIをURIへ写像してはならない。RFC 3987は、写像が余分な偽の同値関係を作り得るため、文字単位の比較関数では禁止すると明記した。転送互換のための変換を識別子の等価関数へ流用してはいけない。識別子として使われる可能性があるIRIを転送途中で変更すべきでない、という結論もここから出る。

Unicode正規化には適切な時点がある。紙や既知の非Unicode符号から取り込むときはNFCにそろえる。すでにUTF-8やUTF-16で表現されたIRIをURIへ写像する手順では、改めて正規化しない。作成者にはNFCが推奨される一方、既存列の扱いが分からない第三者が任意に正規化することは不適切とされた。

RFC 5198とステータス、正誤表、Datatrackerは、ネットワーク文字列でNFCが比較を容易にし、割当済み文字の正規形に安定性が期待できる理由を説明する。これは一貫した作成と交換を支える。受信済み識別子の原形を中間者が捨ててよいという意味ではない。

パーセント符号化の差をそろえる場合も同じである。特定の局所比較では、URIへ変換し、エスケープの差や16進文字の大小を整えられる。値を別の処理へ渡すなら、RFC 3987は原形保存を必須にする。比較用インデックスと監査原本を一列に統合してはならない。

比較が証明できる範囲にも限界がある。選んだ規則の下で二つのIRIが同値だとは言えても、異なる文字列が異なる資源を指すとは断定できない。同じ所有者が複数の名前で同じ資源を提供できるからだ。逆に、表示が似ているだけでは同値性も権限も証明しない。

ホスト名には後のIDNA2008が加わる。RFC 5890、ステータス、正誤表、履歴は、表示用U-label、ASCIIのA-label、登録、検索を分けた。RFC 5891のステータス、正誤表、履歴は検証と往復対称性を定める。読めるラベルはDNS登録や解決の領収書ではない。

RFC 5895、ステータス、正誤表、履歴は入力写像をUI側へ置く。大文字小文字、全角半角、かな入力、音声、コピーでは適切な配慮が異なる。文書自身が一つの万能写像アルゴリズムを否定している。

RFC 3987の歴史的な強さは、国際化を一回の変換に見せなかったことにある。原文字列を保持し、符号化を記録し、写像と比較の目的を明示し、schemeとIDNAの規則を別に適用し、解決と利用結果を後段で受け取る。人が読める名前は入口を広げた。原形の保存は、その入口で誰が何を渡したのかを将来も説明可能にした。

出典