要約

  • RFC 3367は言語、地理、カテゴリーを共通の検索プロパティにしたが、それらを必須条件ではなく「ヒント」と定義した。
  • 問いの形式は相互運用できても、照合方法、順位、関連性の意味は各サービスが握ったままだった。

名前だけでは答えは一つに決まらない

一般名は語句であって、世界で一意な識別子ではない。「Mercury」は惑星、企業、人、製品を指し得るし、同じサービスが一つの名前に複数の記録を結び付けることもある。RFC 3367が扱ったのは、一般名に関連する記録をサービスへ問い合わせる方法という限定された問題だ。サービスの発見や選択、名前の登録や所有権、唯一性は定めていない。CNRPは検索プロトコルであり、命名権威ではなかった。

共通の語彙、個別の判断

問い合わせに渡せるのは名前だけではない。基本プロパティには名前、言語、地理、カテゴリー、結果範囲が含まれた。クライアントはまずServiceQueryを送り、サービスが何を扱えるか確認できる。サービス独自のデータ型を示す余地もある。

しかしRFCはこれらを普遍的な判定基準にはしなかった。「ヒント」とはクライアント側の希望や文脈である。順序で優先度を表せるが、サービスは無視してもよく、最善の照合を試みればよい。異なるプロパティ同士は論理AND、同一プロパティの複数値はORで組み合わされる。それでも、返答が全条件を満たす必要はない。「英語」と「ロンドン」は検索の方向を示しても、条件外の候補をすべて排除するとは限らない。

ここに設計上の核心がある。通信形式は相互運用できても、答えはサービスごとに異なり得る。ある事業者は言語を重視し、別の事業者は弱い手掛かりとして扱うかもしれない。RFCは共通の重み付け式や同点処理を定めなかった。

文字コードは意味を決めない

UTF-8はテキスト交換を可能にし、言語タグは言語を構造的に示す。しかし、表記、文字体系、音訳、名称の違いを同一とみなすかまでは決めない。一般名の同等性や照合規則はサービスと言語に依存すると、RFC 3367は明示した。文字コードが保持するのは文字列であり、その指示対象ではない。

順位付けもサービス側に残る。一つのサービス内なら独自の関連度で並べられるが、別々のサービスの結果をCNRP対応だけで同じ尺度に載せることはできない。関連するRFC 3368のgo: URIは特定のサーバーや記録、または広い問い合わせを表せるが、この役割分担を消し去るものではない。

相互運用性の境界

RFC 3367は希望の表現、能力の確認、属性を組み合わせる大まかな論理を標準化し、意味上の同等性と最終順位を運営者に残した。これは細則の見落としではなく、設計の境界である。共通語彙は異なるシステムの対話を可能にするが、判断まで同一にはしない。

Lu Hengの「稼働するコードを優先する」という見方は、この距離を考える助けになる。ただし、ここで言えるのは限定的だ。仕様は実装が交換できる内容を示し、利用者の体験は実際のサービス動作に左右される。RFCだけでは普及や商業的影響を証明できない。ここでの歴史的な要点は、希望を持ち運べるようにしながら、関連性の判断は各サービスに残したことだ。

出典