要約

  • RFC 3151は公開識別子を空白正規化し、構造区切りと予約文字を決定的なurn:publicid:表記へ移した。正しい変換は名前の変換を証明するだけで、所有者や資源を検証しない。
  • 語彙的同値は厳格で、正規化後のURNが文字列として同一な場合に限られた。同じ名前でもカタログ、取得バイト、アプリの挙動は異なり得た。
  • 解決はカタログ、ローカルパス、組み込み知識、キャッシュなど複数の文脈に残り、選択、写像、取得、解析、結果には別々の受領証が必要だった。

URIの形に入れることが課題だった

XML外部実体にはsystem identifierとpublic identifierがあった。前者は定義上URIで、歴史的にはローカルな場所を示すことが多い。後者は文字列だが、SGML以来、より広域で永続的な名前として扱われた。

XSLTやXML Schemaなどが外部識別子にURIを求めると、既存の公開名は欄に収まらない。RFC 3151は既設カタログを捨てず、publicidという正式URN名前空間で古い文字列を運べるようにした。

URIらしい外見は権威の昇格ではない。一意性も永続性も元の公開識別子から継承する。未登録所有者は登録済みにならず、弱い命名方針も直らない。

文書はInformationalで、Internet Standardを定めないと明記した。例は教育用で実在を保証しない。変換例はアルゴリズムの証拠であり、登録、配備、到達性の証拠ではなかった。

正規化は比較のために履歴を一部捨てた

転写前に、空白、タブ、復帰、改行の連続を一つの空白へまとめ、先頭と末尾を除いた。RFCはこの処理が済んでいることを前提にした。

インデントだけが違う二つの原記録は同じ正規化名になり得る。比較は安定するが、URNだけ残せば元の配置は復元できない。原文字列、文字コード、正規化結果、規則版を別に保存すべき理由である。

正規化空白は+になる。連続空白は先に畳まれるので、それ由来の連続プラスは現れない。原文に本物の+があれば%2Bになる。見た目の近さに反して、一方は空白、他方は字面文字の証拠である。

最終URNだけの記録では、処理順序や失われた情報を監査できない。

構造は残しても正しさを認証しない

Formal Public Identifierは、所有者、公開テキスト種別、記述、言語または指示列、任意の表示版を持つ構造化部分集合だった。多くは//で欄を区切り、内部に::を使った。

RFC 3151は//を:へ、::を;へ移した。完全なSGML文法を理解せずに構造の輪郭を残すためである。文字列が正しいFPIか判断する仕事は範囲外だった。

したがって出力のコロンは、正規化源に二重スラッシュがあった証拠にはなるが、所有者登録や構文妥当性の証明ではない。

字面のコロンは%3A、単独スラッシュは%2F、セミコロンは%3Bとなり、アポストロフィ、疑問符、番号記号、パーセントにも転義がある。置換の位置と順序が実装証拠になる。

往復試験で正規化名の保存は確かめられるが、割当や解決は確かめられない。

同じ文字列は同じ内容を意味しなかった

同値規則は小さい。正規化後、URNが語彙的に同一な場合に限って同値だった。大文字小文字の畳み込み、所有者別名、意味的な欄比較はない。

二つの名前を一つのファイルへ写すローカルカタログは、名前空間で両者を同一にしない。逆に同一URNも、別のカタログ列、基底URI、ファイルシステム、キャッシュに会えば違う内容を返し得る。

一つの資源が複数公開識別子を持つことも許された。名前同一、写像同一、バイト同一、動作同一は別の検査である。

後のRFC 3986やRFC 8141はURI/URN史を更新したが、過去のカタログ結果や3151の同値規則を遡及変更しない。

所有者の弱さも名前空間へ運ばれた

登録所有者を持つFPIには一意性が求められた。非公式名や未登録所有者のFPIは一意かもしれず、そうでないかもしれない。統一執行方針はなかった。

永続性も元の名前に従う。登録所有者は比較的強い基盤でも、可用性や内容を保証しない。ドメイン名を使うIDN所有者方式は、少なくともドメイン名の永続性の弱点を継承した。

URN接頭辞は、弱い割当を修理せず、カタログを維持せず、表現を固定しない。公開識別子のない資源には、まず元の規則で名前を作り、その後で転写する必要があった。

所有者、登録状態、割当方針、時刻を保存し、文字列の外見から権威を推測してはならない。

解決はローカルな選択のまま残った

RFCはOASISカタログ、構成要素からローカルパスへの写像、プログラムが知る固定集合、キャッシュなどを挙げた。単一の世界的リゾルバは定義しなかった。

カタログ順序、rewrite、基底URI、マウント、ネットワーク、キャッシュ鮮度が対象を変える。規則命中は対象選択の受領証であって、取得成功の証明ではない。

取得したバイトとハッシュ、パーサーと実体方針、診断、アプリ結果が続く。resolved=trueではこれらを監査できない。

検証機構は指定されなかった。追加のsecurity considerationsがないという記述も、所有者、カタログ、キャッシュ、内容を認証しない。正確なエンコーダーが古いローカルファイルへ正確に導くことはある。

実行結果が完全な名前を訂正する

完全なURNが第一カタログで古いDTDへ写り、ファイルが開き、解析も成功することがある。構文は全部正しくても、アプリが必要とする版ではない。

別の機械は同じURNから別のDTDを選べる。キャッシュは所有者方針変更後も旧対象を持てる。組み込み表はネット資源消失後も成功を返せる。

RFC 3151は転写について権威を持つ。実行コードは、どのリゾルバ、どの規則、どのバイト、どの結果かを決める。後者を前者の証明にしてはならない。

歴史的成果は限定が明確だったことにある。古い名前は場所のふりをせずURI世界へ入った。しかし構文の境界を越えても、資源への旅は終わらなかった。

出典