要約

  • RFC 3982は、空の値に対してprivateとdeniedを分けた。前者は内容が決して公開されない可能性、後者は現在のアクセス水準ではポリシー上開示されないことを示した。
  • 値が返る場合も、specialAccessとdoNotRedistributeによって、特別に閲覧できることと、その値を再配布できることを別の判断として残した。

レジストリ・クライアントが連絡先欄を空白で描画する。利用者は「登録されていない」と理解し、調査を打ち切る。しかしサーバーが伝えたかったのは「この認証水準には開示しない」だったかもしれない。空欄は忠実な表示に見えるが、理由を捨てた瞬間に誤った証拠になる。

RFC 3982は、その理由を機械可読な結果に含めた。RFC Editorのステータス記録、エラッタ、IETFのDatatracker履歴は、2005年1月の標準化文書を記録している。これはIRISのドメイン・レジストリ型であり、ドメイン、ホスト、連絡先、レジストラ、登録機関を構造化された問い合わせと結果で表した。

その前提は要件文書にあった。RFC 3707とそのステータス、エラッタ、Datatracker記録は、運用者のポリシーに応じた細かなアクセス水準を妨げないことを要求した。値を返せない場合には、説明なしの完全省略、認可不足、認可とは別のプライバシー制約を表現できなければならない。値を返す場合には、「再配布しない」と「特別アクセスを付与」の両方を、同時にも付けられなければならなかった。

比較対象はWHOISである。RFC 3912とステータス、エラッタ、Datatracker履歴は、TCP 43番ポートにテキスト要求を送り、テキスト応答を受け取る方式を記述した。同文書は、強いセキュリティ、アクセス制御、完全性、機密性が欠けると明記している。実装が人間向けの注意書きを返すことはできても、パーサーやキャッシュが欠落理由を保存するための共通フィールド構造はなかった。

RFC 3982の3.2.1節では、いくつかの結果型にプライバシー・ラベルが付く。該当要素は内容を持つことも、nilまたは空の内容で存在することもできる。内容なしで存在する場合、少なくとも一つの真偽属性が必要だった。privateは、内容が決して公開されない可能性があるため存在しないことを示す。deniedは、現在のアクセス水準ではポリシーが開示を許さないことを示す。

この差は再試行の意味を変える。privateなら、より強い資格情報を提示しても開示されるとは限らない。deniedなら、別の役割や認証水準が結果を変える可能性がある。どちらも「データベースに値がない」とは言っていない。要素そのものが省略された場合は、標準化された説明もない。

内容がある要素には別の二属性を付けられた。specialAccessは特別なアクセス権によって値が提供されたことを示し、doNotRedistributeはその内容を再配布してはならないことを示す。前者は受領の根拠、後者は受領後の扱いである。同時に付けられる設計は、閲覧許可が転送許可ではないことをはっきりさせた。

この意味は変換処理で簡単に失われる。XMLから文字列だけを取り出せば属性が落ちる。nilを空文字列にすれば、非公開と拒否と未登録が同じになる。特別アクセスで得た値を共有検索基盤へ複製すれば、値は正確でも配布範囲は誤る。フォーマット上の成功が、統制上の失敗を隠す。

ただし、ラベル自体は強制装置ではない。RFC 3981とそのステータスは、IRIS中核に権限拒否や権限確認の制御を置きながら、認証と機密性をアプリケーション・トランスポートに委ねた。RFC 3983とそのステータスはBEEPへの対応付けを定めた。RFC 3982の属性は暗号化せず、利用者を認証せず、コピーを物理的に止めず、法律上の義務を単独で作らない。ポリシー判断を失わずに伝えるための語彙だった。

同じ問題は後のRDAPでも現れた。RFC 9083とステータス、エラッタ、Datatracker履歴はJSON応答モデルを定義する。RFC 9537とステータス、エラッタ、IETF記録は、明示的な墨消し拡張を追加した。

RFC 9537は、フィールドがない理由として「データが存在しない」と「クライアントに権限がない」を区別する必要を明記する。削除、空値、部分値、置換値という四つの方法を示し、対象フィールド、方法、理由を記録できる。XXXXのような一般的な置換文字列は、形式を壊し、信頼できない合図になるため認めない。また、墨消しの合図そのものがデータの存在を漏らす場合があり、そのときは合図を省けるとする。

公式資料はRFC 3982からRFC 9537への直接の系譜を証明していない。その関係を作り上げる必要はない。重要なのは、同じ観測上の問題が残ったことだ。空白だけでは、存在しないのか、隠されたのか、拒否されたのかが分からない。値だけでは、通常公開なのか、特別な条件で受け取ったのかが分からない。

現代の実装が受け取るべき教訓は、古いXMLを復活させることではない。値、欠落理由、アクセス文脈、再配布制約を別々の情報として最後まで保つことだ。画面が何も表示しないなら、何も知らないことと、見せられないことを混同してはならない。画面が値を表示するなら、その値を受け取った権限がどこまで続くのかも同じ強さで示す必要がある。

出典