要約

  • RFC 3383 は LDAP の全拡張を一つの審査へ押し込まず、Standards Action、専門家審査、Specification Required、先着順、実験、私用を衝突リスクに応じて使い分けた。
  • 登録は実装や安全性の証明ではない。公開仕様、責任者、審査経路、変更管理と識別子を結ぶ調整記録だった。

同じ整数を二つの実装が別々の resultCode に使えば、符号化は正常でも意味は一致しない。受信側はエラーを出さず、自分が知る意味で処理してしまうかもしれない。識別子空間が広いだけでは、この衝突を防げない。

2002 年 9 月に BCP 64 として公開された RFC 3383 は、LDAP の拡張性を継続的な管理問題として扱った。LDAP は新しい操作、既存操作の拡張、schema の追加を許していた。必要だったのは、発明を止めずに共有名を二重占有させない入口だった。

文書は一律の登録キューを作らなかった。message type、発見可能な protocol mechanism、result code、authentication method、OID descriptor、AttributeDescription option は、衝突したときの影響が異なる。したがって入口の摩擦も異なった。

IETF が開発する要素は、Internet Directory Numbers の下に一つの OID arc を申請できた。Expert Review with Specification Required を経て枝を得た後は、仕様自身が配下の OID を割り当てられた。IANA は枝同士を調整し、各仕様は自分の局所的な木を管理する。

IETF 外の開発者は、Private Enterprise Number を含む正当に委任された OID を使えた。作業中の実装には実験 OID が勧められた。早期コードが最終仕様の値を先取りしないためであり、実験 OID は公開仕様に残すものではなかった。

Root DSE で発見できる control や extension には、First Come First Served with Specification Required という比較的軽い経路があった。ただし Standards Track mechanism は Standards Action を必要とした。公開技術説明を要求することと、標準化を要求することは別だった。

先着順は品質保証ではない。Specification Required は IETF 標準を意味しない。Standards Action も配備を証明しない。各方針は、特定の共有空間に値を入れる前に必要な公開性と審査だけを定める。

OID descriptor は数値 OID の短い名称で、大文字小文字を区別しなかった。一つの OID に複数名を付けられ、末尾がハイフンの名前は一族を予約できた。x- は登録できない Private Use、e- は先着順の実験、その他は Expert Review だった。

AttributeDescription option も似た区分を持った。接頭辞は見た目の習慣ではなく、調整範囲を表した。x- の値は組織内で有用でも、世界的な一意性や公開仕様を自動的には得ない。

resultCode の数値範囲は政策をさらに明瞭にした。0 から 1023 は Standards Action、1024 から 4095 は Expert Review with Specification Required、4096 から 16383 は先着順と e- keyword、16384 以上と x- keyword は登録対象外の Private Use だった。

authentication method は同じ範囲に加え、COMMON、LIMITED USE、OBSOLETE を記録した。公開仕様がなければ COMMON にできず、新規登録を OBSOLETE として始めることもできなかった。ただし COMMON は普及率の測定値ではなく、想定用途の分類だった。

新しい LDAP message type は Standards Action を必要とした。拡張可能な message が存在したため、最上位の型を増やす必要は少なくなったが、ゼロではない。基本 envelope を変える値には、私的実験より高い調整コストが置かれた。

古い Directory Systems Names 登録簿は新規受付を終了した。LDAPv2 の distinguished name 文字列表現で使われ、LDAPv3 は異なる構文の OID descriptor を採用したからだ。しかし既存一覧は歴史資料として公開を続けるべきだとされた。閉鎖は削除ではない。

Expert Review は完成した template を二週間公開する手続きだった。申請を修正すれば期間はやり直しとなり、参加者は異議を述べられた。専門家は承認して IESG へ送るか拒否し、判断には appeal の道があった。先着順は完成した template を IANA へ直接送った。

所有者も政策に結び付いた。Standards Action の値は IESG が所有者と見なされ、専門家審査や先着順の値は申請者が担った。更新には新規登録と同じ制約がかかる。所有者が必要な修正をできない、または拒む場合、IESG は管理を引き受けられた。

第三者の重大な異議は、所有者が変更に同意しなくても、Expert Review 後に comment として登録へ付加できた。登録簿は最終値だけでなく、合意できなかった事実も保存できた。

付録の template は identifier、description、specification、contact、author または change controller、usage、comments を要求した。番号だけでは、意味を読む場所も、修正を頼む相手も分からない。登録の価値は番号と説明責任を結び付けることにあった。

RFC 2434 は当時の一般的な登録方針を与え、RFC 8126 が後に更新した。現在の IANA LDAP Parameters は登録簿が生きている証拠だが、2002 年から全項目が不変だった証拠でも、全登録が実装された証拠でもない。

RFC 3377 は当時の LDAPv3 技術仕様の位置を示す。RFC 2251、RFC 2252、RFC 2255 は protocol、schema、URL extension の背景であり、RFC 4510 は後の改訂版をまとめた。これは文書の系譜であって採用調査ではない。

持続した設計原理は、危険に応じた摩擦である。全実験に正式標準を求めれば試行を止める。全共有値を無審査で配れば、将来の相互運用障害へ費用を先送りする。実験・私用空間は逃げ道を残しつつ、公共の意味と混同しない印を持った。

Lu Heng の最小初期仕様という視点では、未来の拡張を先に決めず、区分、方針、template、所有者、修復経路だけを整えた点が重要になる。現実レイヤーの視点では、割当、登録、仕様、実装、配備、成功結果は別々である。登録行は調整レイヤーの証拠でしかない。

RFC 3383 は、拡張性を保管責任へ変えた。識別子が場所を与え、方針が公共空間への参入条件を定め、登録簿が意味、責任者、修正経路を割当後も見つけられる状態に保った。

出典