Summary

  • RFC 2377 は、新しい世界規模の登録制度を避けるため DNS 由来の dc と既存の uid を提案したが、メール形の UID が有効なメールボックスとは限らず、別の mail 属性を確認すべきだと明記した。
  • UID のドメインと DN の経路は一致しなくてもよく、同じ DN が独立サーバーに存在し得た。DN だけでは LDAP サービスの所在も認証も証明できない。

既存の登録をもう一度使う

X.500 は階層と委任を備えていたが、国・地域・法的組織名に沿う従来の命名は重かった。法人名は長く、common name は衝突し、新たな登録機関は利用されにくかった。1998 年の RFC 2377 は Informational な任意案として、acme.com を dc=acme,dc=com にし、その下を uid または cn で名付けた。

DNS や社員番号、handle、RFC 822 識別子には、すでに管理範囲と重複回避の仕組みがあった。提案の価値は二つ目の世界的レジストリを作らない点にある。既存ラベルを普遍的身元へ格上げする計画ではなかった。

アットマーク は配送証明にならない

人の UID には、選ばれた「distinguished」メール識別子が便利だとされた。しかし組織は、実メールボックスを持たない一部の人にも同じ形式の一意な別名を配ることがあった。

そこで文書は明確に警告する。uid をメールボックスと仮定せず、mail 属性を調べよ、と。UID はディレクトリ文脈でエントリを選ぶ。mail は連絡先を主張する。SMTP の経路と配送、セッション認証、アクセス許可はさらに別の証拠である。アットマークはそれらを生成しない。

二つのドメインは意図して離せた

uid=external-mailbox-shaped-identifier を dc=mis,dc=acme,dc=com の下に置くことも許された。DN の経路は ACL や分割のために設計し、UID は外部の安定した識別子を保てる。ディレクトリ再編の都合でメールアドレスを変えなくてよい。

したがって アットマーク の右側から権威ある DN を組み立てることも、DN から現在のメールを推測することもできない。dc の連結結果は登録済み DNS 名である必要があったが、それが防ぐのは命名衝突である。LDAP サーバー、組織、配下の人物を認証するわけではない。

DN はエンドポイントではない

RFC 2247 は DNS 名と純粋な dc DN の可逆変換を定義した一方、ドメインから LDAP サーバーを探す方法は定義しなかった。信頼できないサーバーが委任されていない naming context を名乗る危険も述べた。

RFC 2377 が想定したのは疎結合の「島」である。同じ DN 名前空間のサーバーは referral でつながり、島をまたぐ際には LDAP URL が host、port、DN を組み合わせる。endpoint は DN の外にある証拠だった。

競合するサービス提供者の下で単一の世界 DIT は現実的でないとも判断した。独立運用のサーバーは、同じ現実対象について同一 DN かつ異なる属性のオブジェクトを持ち得る。属性集合と現実対象の対応を作るのはアプリケーションである。

命名と検索も別だ。RDN に uid を使っても、cn は人物の検索と表示に重要だった。さらに公開 DNS から、ACL で browse を隠した DIT 構造を推測できる場合もある。

RFC 4519 は後に uid、dc、dcObject、uidObject の定義を確定した。schema の明確化は、UID をメールボックスや認証済み人物に変えなかった。

名前は借りても権威は借りない

Lu Heng の現実レイヤーで見れば、DNS 委任、構造化 DN、表示文字列、UID、mail、LDAP URL、認証応答、ACL 判断、配送結果は別々の記録だ。Running-Code Primacy は実サーバーの応答を要求する。Minimum Initial Specification は当初案の強さを説明する。共同作業に必要な最小慣行を置き、将来とローカル判断を閉じなかった。