Кратко

  • RFC 3383 назначил разным пространствам LDAP разные правила: Standards Action, экспертную проверку, Specification Required, очерёдность, эксперимент и частное использование.
  • Запись в реестре доказывала координацию, но не реализацию или безопасность. Её сила состояла в связи идентификатора со спецификацией, владельцем и процедурой изменения.

Две реализации могут присвоить одному числу разные результаты. Пакет останется синтаксически правильным, поэтому обычная ошибка декодирования не остановит обмен. Каждая сторона прочтёт известное ей значение и получит собственный смысл. Коллизия возникнет не в байтах, а в договорённости.

RFC 3383 был опубликован в сентябре 2002 года как BCP 64. LDAP уже позволял добавлять операции, расширять существующие операции и schema. Документ описал, как идентификаторы этих новшеств должны входить в общее употребление, чтобы расширяемость не разрушала совместимость.

Единой очереди одобрения не появилось. Типы сообщений, обнаруживаемые механизмы, коды результата, способы аутентификации, дескрипторы OID и опции AttributeDescription имели разный ущерб от столкновения. Им требовалась разная строгость.

Спецификация элемента IETF могла получить один OID-узел в Internet Directory Numbers после Expert Review с Specification Required. Затем она самостоятельно назначала подчинённые OID без обращения к IANA за каждым листом. Центральный реестр защищал ветвь, а локальные решения оставались в определяющем документе.

Другие разработчики использовали правильно делегированные OID, включая Private Enterprise Numbers. Для ранних версий рекомендовался экспериментальный узел. Это отделяло временный код от окончательной публикации; экспериментальный OID не должен был переходить в опубликованную спецификацию.

Controls и extensions, объявляемые через Root DSE, могли регистрироваться по First Come First Served с Specification Required. Механизм Standards Track требовал Standards Action. Публичное техническое описание обеспечивало обнаруживаемость смысла, но не превращалось от этого в стандарт.

Политики нельзя читать как рейтинг качества. О́чередность не проверяет безопасность. Наличие спецификации не подтверждает консенсус. Standards Action не доказывает развёртывание. Каждое правило определяет только условия занятия конкретного пространства.

OID descriptors были короткими именами без учёта регистра; один OID мог иметь несколько имён. Имя с дефисом на конце резервировало семейство. x- означало нерегистрируемое Private Use, e- — эксперимент с простой регистрацией, остальные дескрипторы проходили Expert Review.

Опции AttributeDescription использовали сходное деление. Префикс сообщал об области координации. Частное имя могло быть полезно внутри организации, но не получало мировой уникальности или публичной документации автоматически.

Для resultCode диапазон 0–1023 требовал Standards Action, 1024–4095 — Expert Review с Specification Required, 4096–16383 — First Come First Served и слова e-. Значения от 16384 и слова x- относились к нерегистрируемому Private Use.

Методы аутентификации следовали тем же диапазонам и помечались COMMON, LIMITED USE или OBSOLETE. Без открытой спецификации метод не мог стать COMMON. Новая запись не могла сразу быть OBSOLETE. Категория описывала предполагаемое применение, а не измеряла распространение.

Новый LDAP message type требовал Standards Action. Расширяемые сообщения уменьшали потребность менять основную оболочку, но не устраняли её. Вмешательство в верхний выбор протокола требовало большей координации, чем частный опыт.

Directory Systems Names перестали принимать новые записи, поскольку LDAPv3 использовал OID descriptors и другой синтаксис. Старый список LDAPv2 следовало оставить открытым для исторического поиска. Закрытие распределения не означало уничтожение свидетельств.

Экспертная проверка включала двухнедельное публичное обсуждение заполненной формы. Исправление формы запускало срок заново. Участники могли возражать; эксперт одобрял и пересылал запрос либо отказывал, а решение допускало обжалование. Запросы по очерёдности шли прямо в IANA.

Правило определяло и владельца. IESG считался владельцем значений Standards Action, заявители — значений Expert Review и First Come First Served. Изменения проходили условия, сопоставимые с новой регистрацией. Если владелец не мог или не хотел исправить запись, IESG мог принять управление.

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

Шаблоны требовали идентификатор, описание, спецификацию, контакт, автора или контролёра изменений, применение и комментарии. Голое число предотвращает лишь аккуратное повторное назначение. Оно не объясняет смысл и не называет того, кто вправе его исправить.

RFC 2434 дал общую терминологию, позже обновлённую RFC 8126. Современные страницы IANA LDAP Parameters подтверждают продолжение публичного реестра, но не неизменность формы с 2002 года и не наличие активной реализации каждого пункта.

RFC 3377 помещал работу в LDAPv3 своего времени. RFC 2251, RFC 2252 и RFC 2255 давали контекст протокола, schema и URL, а RFC 4510 позднее описал пересмотренный набор. Эта история документов не является статистикой внедрения.

Долговечным решением стала разная цена входа. Полная стандартизация каждого эксперимента остановила бы опыты. Свободное занятие общих значений перенесло бы цену на будущие сбои. Экспериментальные и частные области оставили свободу, но не обещали глобального смысла.

Через минимальную начальную спецификацию Lu Heng видны границы решения: определить разделы, политики, формы, владельцев и ремонт, не предрешая все расширения. Его слои реальности отделяют распределение, регистрацию, спецификацию, код, эксплуатацию и результат. Запись IANA относится к одному слою.

RFC 3383 превратил расширяемость в длительное хранение ответственности. Идентификатор давал место, политика задавала условия входа, реестр оставлял доступными смысл, владельца и путь исправления после завершения назначения.

Источники