Summary

  • RFC 2377 предложила компоненты dc из DNS и существующие uid, чтобы не создавать новый мировой реестр, но прямо предупредила: UID в форме email может не быть действующим ящиком; приложение должно проверить отдельный атрибут mail.
  • Домен UID и путь DN могли различаться, одинаковые DN могли находиться на независимых серверах, а сам DN не находил и не аутентифицировал LDAP-службу.

Координация уже была оплачена

X.500 давал иерархию и делегирование, однако традиционные имена через страны, регионы и юридические названия организаций требовали тяжёлой регистрации. Обычные имена людей сталкивались. Информационная и добровольная RFC 2377 предложила в 1998 году превратить acme.com в dc=acme,dc=com, а листья называть через uid или cn.

DNS, номера сотрудников, handles и идентификаторы RFC 822 уже имели административные области. Их повторное использование устраняло второй глобальный реестр. Но оно не создавало универсальную личность или единое мировое дерево.

Знак знак at не подтверждал доставку

Для человека можно было выбрать «distinguished» почтовый идентификатор как UID. Однако организация могла выдать такую форму всем сотрудникам, хотя некоторые не имели настоящего ящика.

Поэтому RFC требовала не считать uid mailbox и проверять mail. UID выбирал запись. mail утверждал маршрут связи. SMTP позже давал свидетельства маршрутизации и доставки. Аутентификация и авторизация оставались отдельными решениями.

Домены могли расходиться намеренно

uid=external-mailbox-shaped-identifier разрешалось поместить под dc=mis,dc=acme,dc=com. Путь DIT мог выражать контроль доступа или разделение, сохраняя внешний идентификатор. Перестройка каталога не должна была менять почту.

Следовательно, часть после знак at не создавала авторитетный DN, а DN не раскрывал текущий ящик. Соединённые dc должны были образовывать зарегистрированное DNS-имя для предотвращения конфликтов. Регистрация не аутентифицировала LDAP-сервер, организацию или человека.

DN не был адресом сервера

RFC 2247 задала обратимое отображение домена в чистый dc-DN, но не поиск LDAP-сервера. Недоверенный сервер мог заявить о неделегированных naming contexts.

RFC 2377 ожидала слабо связанные острова. Referrals соединяли общий DN namespace, а LDAP URL добавлял host и port для перехода между островами. Независимые операторы могли хранить разные объекты с одним DN для одного реального субъекта.

Имя не заменяло поиск: uid мог строить RDN, но cn оставался важен для обнаружения и отображения. Публичные DNS-имена могли также выдать структуру ветвей, скрытых ACL.

RFC 4519 позже закрепила определения uid, dc, dcObject и uidObject. Точная схема всё равно не превращала UID в ящик, учётные данные или подтверждённую личность.

Повторно использовать имя, но не его власть

Слои реальности Lu Heng разделяют DNS-делегирование, структурированный DN, строку, UID, mail, LDAP URL, аутентифицированный ответ, ACL и доставку. Running-Code Primacy требует наблюдать реальные системы. Minimum Initial Specification показывает достоинство плана: минимальная общая конвенция без закрытия локальных решений.