Кратко

  • RFC 1485 задал ориентированное на человека строковое представление уже известного Distinguished Name X.500, чтобы структура ASN.1 могла пройти через бумагу или почту.
  • Однозначный разбор не означал канонической строки: разделители, раскладка, дескрипторы либо OID, кавычки и резервное кодирование допускали несколько корректных текстов для одного DN.
  • Восстановленный DN ещё не доказывал существование и свежесть записи, равенство, реальную личность, аутентификацию, авторизацию или результат действия.

Имя после почтового переноса

Длинную строку из старого сообщения легко принять за повреждённую: один клиент разложил компоненты по строкам и поставил точки с запятой, другой показал их через запятые. Но внешнее различие могло быть предусмотренным способом представить одну и ту же последовательность Relative Distinguished Names.

RFC 1485 решал задачу перехода из структурированного мира X.500 в человеческий текст. В протоколе Distinguished Name был ключом записи и имел представление ASN.1. Визитная карточка и письмо требовали иной формы — читаемой, но обратимой.

Это не был алгоритм поиска. RFC 1484 принимал предполагаемое удобное имя и искал кандидатов DN. RFC 1485 начинал после выбора DN. Догадка пользователя, сериализация структуры, запрос каталога и проверка личности оставались разными событиями.

Иерархия внутри знаков

DN складывается из RDN вдоль пути Directory Information Tree. В представлении RFC 1485 сначала шла более конкретная часть, затем широкие контексты. = связывал тип атрибута и значение. Запятая или точка с запятой разделяла RDN. + объединял несколько пар AttributeTypeAndValue в одном многозначном RDN.

Замена плюса запятой меняла структуру: два утверждения одной ступени превращались в две последовательные ступени. Тип атрибута также нельзя было просто опустить. Строка несла типы, значения, группировку и порядок, а не только удобную подпись.

При этом спецификация допускала разные раскладки. Можно было выбрать компактную строку или более привлекательные строки с точками с запятой. Обязательным был восстановимый DN, а не единый рисунок страницы.

Самая некрасивая форма защищала неизвестное

Запятые, кавычки, крайние и повторные пробелы внутри значения требовали кавычек и экранирования, чтобы данные не стали грамматикой. Неизвестный тип атрибута можно было записать числовым точечным OID. Для значения без удобной экранной формы предусматривалось шестнадцатеричное BER-кодирование.

Документ называл последний вариант некрасивым и ожидал его преимущественно в патологических случаях. Но именно он делал представление общим. Синтаксис только для знакомых красивых значений потерял бы будущий или частный атрибут при встрече с неподготовленным интерфейсом.

Сохранение не равно пониманию. Парсер может вернуть OID и байты, хотя приложение не знает схемы, правила показа и сравнения. Честный интерфейс сохраняет неизвестное, не выдавая его за уже истолкованное.

Однозначность работала в одном направлении

Из корректной строки должен был получаться определённый DN. Обратное утверждение — будто у каждого DN есть единственная строка — из этого не следовало. Разные разделители и раскладки уже создавали варианты. Тип мог выводиться знакомым дескриптором или OID; экранирование и кодирование тоже зависели от сериализатора.

Позднейшая линия стандартов уточнила границу. RFC 1779 сменил RFC 1485. RFC 2253 описал UTF-8-представление LDAPv3, а RFC 4514 заменил его. RFC 4514 прямо не определяет канонической строки DN и допускает альтернативные преобразования, если результат разбирается. Равенство задаётся distinguishedNameMatch, а не сравнением исходного текста.

Это не перенос поздней формулировки в документ 1993 года, а точная оценка его результата: обратимая сериализация вместо единственного официального написания.

Изображение, байты, дерево разбора и совпадение

Снимок экрана подтверждает глифы. Архив письма может подтвердить байты и обработку кодировки. Парсер подтверждает восстановленные RDN. Каталог сравнивает значения по схеме. Эти свидетельства связаны, но не заменяют друг друга.

RFC 4512 помещает типы, синтаксисы, matching rules и DN в информационную модель LDAP. RFC 4517 задаёт синтаксисы и правила сопоставления. RFC 4518 описывает подготовку интернационализированных строк: отображение, нормализацию, запрещённые символы и двунаправленный текст.

Одинаковый вид не гарантирует одинаковых кодовых точек или структуры, а разные тексты могут обозначать равные DN. Безусловное приведение регистра, обрезание пробелов или замена OID догаданным ярлыком способны создать ложное слияние либо разделение.

Действительность каталога начиналась после разбора

RFC 1309 описывал распределённую среду X.500: DUA, DSA, контексты имён, chaining, referrals и реплики. Строка RFC 1485 не фиксировала это состояние. DN мог стать входом запроса, но не являлся квитанцией ответа.

Успешный разбор не доказывал, что запись существовала в нужный момент, реплика была свежей, а контроль доступа не скрыл атрибуты. Найденная запись тоже не аутентифицировала человека, не подтверждала управление сервисом и не разрешала действие.

Раздел безопасности RFC 1485 сообщал, что вопросы безопасности не обсуждаются. Нельзя приписывать грамматике конфиденциальность, целостность или защиту от подмены, которых она не определяла.

Historic не означает исчезновение

Карточка RFC Editor сейчас помечает RFC 1485 как Historic. RFC 3494 был частью перевода технической спецификации LDAPv2 в исторический статус. Преемники уточнили UTF-8, экранирование, дескрипторы и равенство.

Смена стандарта не очищает почту, конфигурации, журналы и резервные копии. Старые строки могут пережить парсеры и реестры, которые их создали; современные программы могут прочитать их иначе. Статус говорит о нормативной линии, а не доказывает отсутствие артефактов в работающих системах.

Доверие требует нескольких квитанций

Рассуждения Heng Lu о приоритете работающего кода, локальности будущего решения и слоях реальности помогают сохранить масштаб RFC. Общая грамматика обеспечивала обмен; сериализатор выбирал вид; парсер возвращал структуру; оператор каталога владел состоянием; системы идентификации и приложения принимали последующие решения.

Полная цепочка хранит исходный структурированный DN, сериализованные байты, транспортные преобразования, версии программ и реестра, результат разбора, схему и правило равенства, снимок каталога, версию записи, аутентификацию, авторизацию и итог. Фраза «имя всё доказало» незаконно сжимает эти слои.

RFC 1485 сделал формальное имя переносимым. Его более глубокий урок — не переносить вместе с именем полномочия, которых строке никто не выдавал.

Источники