要約

  • CLDAPはUDPと限定された操作によって、小さなディレクトリー照会の接続コストを減らした。その一方で、信頼性、再試行、応答の鮮度は個々の運用環境に委ねられた。
  • RFC 3352は単一の失敗原因を断定せず、特に完全性と機密性の保護がないことなど複数の「可能な理由」を記録し、実験を続けながらRFC 1798をHistoricに移すよう勧告した。

短い照会と、狭い適用範囲

RFC 1798は実務上の問いから始まる。ディレクトリー項目ひとつから属性を少し読むだけなのに、接続やセッションを確立する費用が検索そのものを上回る場合がある。CLDAPはLDAPのメッセージ構造を利用しつつ、UDPなどのコネクションレスな転送を使い、操作を限定する設計だった。RFCの例では照会は4パケット、サーバーとディレクトリーが近い場合やキャッシュが効く場合は2パケットになる。これは交換手順の説明であり、性能ベンチマークではない。

仕様はCLDAPをDAPやLDAPの一般的な代替ではなく、補完と位置づけた。データグラムは失われ得るため、タイムアウトと再試行はクライアントが選ぶ。RFCは特定のアルゴリズムを義務づけなかった。キャッシュは遅延を減らすが、RFC 1798が説明するDAP経路にはキャッシュ無効化の仕組みもdontUseCopy制御もなかった。速度を得る代わりに、許容するデータの古さと再試行方法が運用者側の判断となった。RFC 1798

セキュリティ境界はさらに明確だった。CLDAPには要求の認証機能がない。RFC 1798の編集注記は、資格情報を追加する案が検討されたものの、接続レスの利点を相殺しかねない追加コストを理由に採用されなかったと記録する。認証付きのディレクトリーアクセスを必要とする用途にCLDAPは適さない、と同RFCは明記した。このトレードオフは後から発見されたのではなく、最初の仕様に書かれていた。

2003年の記録が示すもの

RFC 3352は2003年3月に公表され、1995年6月のRFC 1798を振り返った。CLDAPはその7年間にインターネットで広く展開されなかった、と記している。これはRFC著者による当時の評価であり、定量的な設置数調査でも、実装が一つもなかった証明でも、現在の利用状況の測定でもない。

列挙されるのは証明済みの因果順位ではなく、複数の「考えられる理由」だ。機能が匿名・読み取り専用で結果も小さいこと、完全性と機密性の保護がないこと、国際化と拡張性の不足、独立開発された実装が複数存在しないこと。小さな応答で十分な用途はあり得る。しかし、保護しにくく、拡張しにくく、複数実装の間で確かめにくいインターフェースは、共有契約として長く維持しづらい。RFC 3352はどの弱点が最大だったか、すべての運用で同じ問題が起きたかを実証していない。RFC 3352

文書の保守にも問題があった。規範的参照の中に旧版X.500やRFC 1487など、すでに陳腐化した仕様が残っており、更新しなければRFC 1798をStandards Trackに維持できないとRFC 3352は述べる。1997年に設置されたLDAP Extensionsワーキンググループは、CLDAPを更新しないまま活動を終えようとしており、当時、CLDAPを更新する標準化作業も残っていなかった。

勧告はRFC 1798をHistoricに移すことであって、後継プロトコルを発行することではない。無接続のディレクトリーアクセスへの関心は続いていたが、特に安全性について実験が必要だった、とRFC 3352は述べる。LDAP-over-UDPの草案にも触れるが、それは作業中の草案であり、代替標準ではない。RFC 1777が定めたLDAPv2をHistoricに移したRFC 3494は別の措置だ。RFC 3352が退役させたのはCLDAPの仕様であって、LDAP全体ではない。後のLDAPv3文書は技術的な対照を与えるが、各CLDAP製品が何を実行したかまでは証明しない。

Historicは削除命令ではない

Historicは、標準記録における文書の扱いを示す。ラベルだけでサーバーがアンインストールされるわけでも、古いローカル環境が無効になるわけでも、すべての運用者が使用をやめたと証明できるわけでもない。RFC 3352は移行の勧告を示し、安全性に関する節では退役がインターネットの安全性に影響しないと述べる。後者も著者の評価であり、CLDAPが安全だった証拠でも、個別のリスクが皆無だった証拠でもない。

この事例は単に「古いプロトコル」の話ではなく、仕様のライフサイクルを示している。CLDAPは接続確立という目に見える費用を削ったが、保護、損失、鮮度、応答サイズ、その後の改訂は未解決のまま残った。当時の記録からは、そうした制約を解く改訂経路や複数の独立実装が育っているとは判断されなかった。Historicへの移行は限界を記録したが、勧告を普及や全停止と同一視しなかった。

ここでは、Heng Luの「最小初期仕様」と「稼働コード優先」を、出典を明示した編集上の視点として用いる。これはIETFの調査結果ではない。RFC 1798が定めたこと、RFC 3352が運用経験から得たと記したこと、個々の運用者がその後も実行したかもしれないことを分けて考えるための問いである。現存する資料から設置数、特定製品の挙動、移行日時を推測してはならない。

参照資料

主要記録：RFC 3352本文、RFC Editor、Datatracker；元の仕様と周辺文書：RFC 1798本文、RFC Editor、RFC 1777、RFC 3377、RFC 3494、RFC 4510、RFC 4511、RFC 4513、RFC 2026。編集上の視点として明示した資料：Heng LuのNote 64とNote 65。