要約

  • RFC 2079 は大文字小文字を区別する複数値属性 labeledURI と、既存の X.500／LDAP 項目に追加できる補助クラス labeledURIObject を定義した。
  • 未符号化の空白が URI と任意ラベルを分けた。複数値は関連する別資源にも、同一資源の別ロケーションにもなり得たが、その違いを示す型はなかった。
  • URI の格納は到達性、最新性、権威、等価性の証明ではない。ラベルも信頼済み HTML ではなく、RFC はそのまま挿入しないよう警告した。

1997 年には、URL を LDAP や X.500 に入れる試みがすでに複数存在した。RFC 2079 の役割はリンクそのものの発明ではない。異なる実装が同じ属性と同じ値の形を認識できるよう、共有点を定めることだった。

値の先頭には当時 RFC 1738 に従う URL を置き、その後ろに空白と人向けラベルを置けた。URL 内の空白は符号化が必要だったため、最初の未符号化空白が明確な境界になった。クライアントは自然言語を理解せずに切り分けられた。

複数値は関係の未確定を残した

RFC は、複数値が通常は項目に関係する異なる資源を表す一方、同じ資源の異なる場所を表すこともあるとした。人物ページと写真は別資源であり、主サイトとミラーは別ロケーションである。ところが同じ構造の中に「写真」「ミラー」「正本」「保管」「代替」といった機械可読の役割はない。

ラベルは種類や大きさを示す助けにはなっても、文法を持たない。「公式」「最新版」という表現は書き手の主張であって検証結果ではない。サーバーが示せるのは、既知属性として値が付いた事実までであり、宛先の管理者が関係を認めたことや、二つの値が代替可能であることではない。

後の RFC 3986 は URI 比較を段階として説明した。文字列が完全に同じなら等価と判断できるが、異なる文字列でも構文やスキーム固有の正規化後に同じ資源を指す場合がある。したがって厳密な文字保存は記録性を高めるが、資源同一性をすべて決めるものではない。

付加可能性は権限の付加ではなかった

labeledURIObject は top から派生した補助クラスで、必須属性を増やさず labeledURI を許可した。既存項目の主要クラスを作り直さずに追加でき、他のクラスが属性を直接採用することもできた。

RFC 2798 は後者を選び、inetOrgPerson の任意属性として個人ホームページ例を示した。RFC 3383 は属性と補助クラスを LDAP 記述子表に掲載した。これは再利用と参照先の固定を示すが、リンク先の状態や普及率を示さない。

RFC 3296 は LDAP の下位参照に同じ値形式を使ったが、用途固有の規則を追加した。ref はラベルを使わず、参照応答から区切りとラベルを外し、複数値の各 URI を利用した。また保持サーバーに参照整合性を検証させないことを推奨した。一般形式を具体的動作にするには、別の規定が必要だったのである。

表示は新しい実行判断だった

ラベルは人向けだった。RFC 2079 は当時のクライアント間差異から非 ASCII 文字を避けるよう勧め、X.500 の文字表現と HTML エスケープを区別した。そしてラベルを HTML にそのまま入れると、悪意あるタグがページ全体の読者を惑わせ得ると警告した。

保存した文字を返すことと、画面上で実行可能な形にすることは同じではない。クライアントはエスケープ、実際の宛先表示、クリック可能化を決める。さらにリンク先では、リダイレクト、所有者変更、期限切れ、内容差し替え、スキーム固有動作が発生する。

証拠は、項目、属性値、URI とラベルの分離、複数値、主張された関係、主張者、取得結果、宛先の由来と鮮度、安全な表示、後続判断に分ける必要がある。形式が正しいことは、この連鎖の一部にすぎない。

属性名を一つにしても意味は一つにならない

初期案には labeledURL があった。RFC 2079 は URI 用と URL 用の二属性より一属性を選び、古い名称を非推奨にした。ただし移行期のクライアントのため定義は残した。

共有語彙は小さくなったが、既存値が消えたわけでも、移行完了が証明されたわけでもない。関係型も追加されず、URI という広い名称が各スキームを交換可能にしたわけでもない。

歴史的な教訓は限定的だからこそ有用である。ポインターの付け方を共有すれば交換は可能になる。しかし、その理由、現在の状態、隣の言葉に置くべき信頼までは共有されない。

出典