要約

  • RFC 2345は、DNSの管理や名称の権利争いとは別に、既知の会社名からウェブ情報を探す問題だけを扱った実験仕様だった。
  • 会社名の綴り、略称、異表記をどう照合するかはサーバー側の裁量であり、照合が正しいかどうかは仕様の対象外だった。
  • 応答行はURLと自由な表示名だけで、法人番号、法域、出典、検証日、信頼度、ドメイン支配の根拠を持たなかった。
  • 実演システムは候補を採点し、上位十件に切り詰め、一件だけなら自動で開いたため、画面上の一意性や順位は完全性を意味しなかった。
  • 信頼できる結論には、法人、ドメイン登録とDNS、ページの真正性、そして実際のサービス結果を段階ごとに確かめる必要がある。

仕様が解こうとしたのは「どこを見るか」だった

ウェブ初期には、会社名が分かれば www.会社名.com のようなアドレスを推測できるという期待があった。ところが、短い名称は国や業種を越えて重複する。商号、ブランド、製品名は一致しない。.com 以外にもサイトは広がった。

RFC 2345は、当時ひとまとめに語られがちだった問題を三つに分けた。ドメイン管理の方針、名称に対する権利、そして通常の会社名から関連情報を見つけることだ。提案は三番目だけを対象にした。

この限定は重要である。検索結果が便利でも、商標争いを裁くものではない。DNSの委任を変更するものでもない。会社名に対する法的権利を決めるものでもない。検索の一行を身元証明として扱えば、仕様が分けた問題を再び混同してしまう。

WHOISの簡潔さを借りた

交換手順はきわめて小さかった。クライアントはTCPポート43へ接続し、一行を送り、一行以上の応答を受け取る。送信が終わるとサーバーが接続を閉じる。RFC 954のWHOISと同じ、人が読める一問一答の骨格である。

RFC 2345では、入力は会社名と思われる文字列だった。通常の出力は、最初にURL、その後に空白、続いて会社名の表示文字列を置いた。URLに空白が含まれないという前提により、複雑な構文解析を避けられた。

ただし、同じ封筒を使うことと、同じ判断をすることは別である。二つのサービスが同じプロトコルに従いながら、異なる資料、異なる照合規則、異なる候補順位を使うことは可能だった。

名前は法人を一意にしない

仕様は、何を会社名と解釈するか、どの綴りや略称を受け入れるかをサーバーに委ねた。しかも、ある文字列を特定企業に一致させた判断が正しいかどうかは、仕様の範囲外だと明記した。

大文字と小文字を無視する規則はあったが、それは同一性確認ではない。同名企業は存在する。親会社、子会社、商品が同じブランドを用いる。改称後も旧名が残る。別の文字体系からの転写には複数の形がある。法人種別を示す語を取り除けば検索しやすくなる一方、別会社を区別する情報まで失われる。

したがって、照合結果が示すのは「このサービスがこの文字列をこのレコードに結び付けた」ことである。法人が一意に確定したことではない。

応答の会社名も証明書ではない

URLの後ろに置かれる会社名欄も、厳密な意味を与えられていなかった。名称だけでもよく、所在地や業種を加えてもよく、サービス側が選ぶ別の説明を含めてもよかった。目的は利用者がURLを選びやすくすることだった。

そこには法域、会社登録番号、根拠資料、編集責任者、確認日、信頼度、異議申立て、変更履歴を格納する標準欄がない。表示された組織とドメインの関係が、所有、委任、代理運営、販売契約、単なる編集推定のどれなのかも分からない。

構造を減らしたからこそ実装しやすかった。しかし、構造とともに証拠の範囲も削られていた。

URLは場所であって権原ではない

RFC 1738はURLを、インターネット上の資源を特定しアクセスするための簡潔な文字列表現として説明した。同じ文書は、ある時点で一つの対象を指したURLが、後にも同じ対象を指す一般的保証はないと注意している。

検索結果のドメインは、表示企業本人、親会社、制作会社、販売代理店、ホスティング事業者、または無関係の主体が登録しているかもしれない。正規サイトでも別ドメインへ転送されることがある。かつて正しかった関係が更新されずに残ることもある。

RFC 2345自身も、変換サーバーが偽装されれば誤ったURLが返る危険を挙げた。対策として証明書、署名、その他の真正性表示を注意深く見るよう求めた。つまり、マッピング行だけでは真正性が足りないと理解されていた。

RFC 1591も、ドメイン登録が商標上の地位を与えないとした。登録関係さえ示さないディレクトリー行から、名称の権利を推定する余地はさらに小さい。

一件だけという表示が確信を生んだ

一行だけ返った場合、クライアントは確認を求めてもよいし、利用者がURLを直接入力したかのように開いてもよいとされた。実演クライアントは、一件だけなら追加操作なしで既定ブラウザーを起動した。

しかし、その一件は一つのデータベース、一つの照合方法、一つの時点での一件にすぎない。新しい会社が未収録かもしれない。別表記が候補を隠したかもしれない。正規化が別法人をまとめたかもしれない。別の提供者なら複数の候補を返すかもしれない。

自動遷移は操作を速くした。判断の正しさを高めたわけではない。

上位十件は全件ではない

文書に記載された実演サーバーは、Dun & Bradstreetから提供された約20万9千件の会社データを持っていた。十件以上が見つかった場合、返すのは上位十件だけだった。クライアントは得点順に二件から十件を表示した。

得点の意味や計算方法はプロトコルで標準化されていない。第一位は中立的な真実ではなく、提供者の評価関数による順位である。画面に十一件目がないことは、候補が存在しない証拠ではない。

Not found も同様に限定的だ。その文字列が当該データベースに一致しなかったことを示すだけで、会社やウェブサイトの不存在を示さない。

実演環境には追加や訂正の仕組みがなく、データの正確性について責任を負わず、会社が掲載されていない可能性も認めていた。訂正経路がなければ、欠落は長く残り得る。

品質は通信形式の外で作られた

RFC 2345は、結果の品質が基礎ディレクトリーと、その構築に投入された編集・調査作業に依存すると述べた。どちらもプロトコルの対象ではなかった。

正しく区切られた応答が古い情報を運ぶことはある。キャッシュは応答時間を縮める一方、古い誤りを素早く再生することもある。逆に、厳密に確認されたディレクトリーも同じ簡素な形式を使える。

両者を区別するには、出典、適用時点、照合方法、競合資料、更新方針、訂正窓口を調べなければならない。プロトコルの正しさは「サーバーが何を返したか」を示す。情報の正しさには「なぜそう返したか」が必要である。

提供者の選択も証拠の一部だった

仕様は単一提供者を求めず、提供者登録制度も必要としなかった。クライアントがサーバーを選べることを望ましいとした。

複数提供者は、地域や言語に合わせた改善を可能にする。同時に、同じ入力が異なる候補、順位、未検出結果を生み得る。提供者名、時刻、正確な入力、データ版を欠く結果記録は、出所が不足している。

市場が良いサービスを選別するという期待は、個々の応答に真正性を付与する仕組みではなかった。

ページを開いてもサービスはまだ証明されない

会社とURLの関係が正しくても、利用者の目的は達成済みとは限らない。DNS解決、通信経路、TLSの文脈、転送先、ページ管理主体を確かめる必要がある。さらに商品、問い合わせ、取引、サポートが実際に機能するかを観測しなければならない。

公式サイトが終了済みのサービスを掲載していることもある。フォームが表示されても送信に失敗することもある。一回の成功は将来の継続性を保証しない。

ディレクトリーは次に見る場所を示した。企業の身元、技術的支配、サービス結果は別々の受領証だった。