Кратко

  • RFC 1558 дал бинарному LDAP Filter текстовую префиксную запись. Скобки, &, |, !, сравнения и * задавали исполняемую структуру.
  • Фильтр оставался одним полем SearchRequest. База, область, политика псевдонимов, лимиты, правила сопоставления, контроль доступа и последовательность результатов требовали отдельных свидетельств.
  • RFC 1960, RFC 2254 и RFC 4515 уточнили статус, LDAPv3, UTF-8 и экранирование октетов. RFC 1558 имел статус Informational и не обсуждал безопасность; он не доказывает инцидент, внедрение или современную уязвимость.

Граница между значением и операцией

В RFC 1558 запись (cn=Babs Jensen) означает равенство, а (!(cn=Tim Howes)) — отрицание. Более длинный пример (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*))) строит дерево из AND, OR, равенства и подстроки. Читаемые знаки определяют ветвление, а не комментируют его.

Особенно важна *. В attr=* она проверяет наличие атрибута. В (o=univ*of*mich*) разделяет части шаблона. Если звёздочка должна быть данными, документ 1993 года предписывает поставить перед ней обратную косую черту. Почти одинаковая строка способна задать иной набор кандидатов.

Datatracker и карточка RFC Editor фиксируют декабрь 1993 года и статус Informational: документ не задавал интернет-стандарт. Текстовая копия служит отдельной сверкой, а реестр исправлений отделяет errata. Раздел безопасности прямо говорил, что вопросы безопасности не рассматриваются. Нельзя выдавать RFC за отчёт об атаке, утечке или уязвимом продукте.

Одна строка не описывала весь поиск

RFC 1487 уже включал BER Filter в SearchRequest вместе с baseObject, scope, политикой разыменования псевдонимов, ограничениями размера и времени, выбором типов или значений и списком атрибутов. RFC 1488 задавал строковые формы значений своей эпохи. RFC 1558 стандартизировал человеческую поверхность Filter, а не всю операцию.

С другой базой тот же предикат рассматривает другую часть дерева. wholeSubtree шире singleLevel; псевдонимы могут добавить путь; лимит может оборвать выдачу; список атрибутов меняет запрашиваемые данные. Сопоставление видимой строки не воспроизводит эти решения.

Современный RFC 4511 и его официальная запись различают TRUE, FALSE и Undefined. Только TRUE допускает возврат записи, причём под контролем доступа. Неизвестный атрибут, неподходящее правило сопоставления или неверное assertion value могут дать Undefined. Синтаксический успех не является семантическим.

Результат тоже состоит из событий: ноль или больше SearchResultEntry и SearchResultReference, затем SearchResultDone. Ссылка отмечает неисследованную область, а значения могут отсутствовать из-за запроса или политики. Совпадение, возврат, полнота, аутентификация, авторизация и последующее действие — разные квитанции.

Преемники уточнили работу с октетами

RFC 1960 сохранил префиксную форму и заменил RFC 1558 в статусе Proposed Standard; это отражено в его карточке. Затем его сменил RFC 2254.

RFC 2254 добавил расширенное сопоставление LDAPv3 и контекст UTF-8, а специальные октеты представлял обратной косой чертой и двумя шестнадцатеричными цифрами. Официальная запись сохраняет эту ступень.

Действующий RFC 4515, связанный со своей статусной страницей, требует экранировать октеты *, (, ), обратной косой черты и NUL и формировать корректный UTF-8. В (cn=*\2a*) внешние звёздочки — операторы подстроки, а \2a — буквальная звёздочка.

Если журнал хранит только отображение и теряет октеты, версию экранирования и дерево, восстановить роль символа невозможно. Точность кодирования стала частью точности доказательства.

Читаемость не передавала полномочия

Общая форма была полезна: конфигурацию стало легче проверять, шаблоны — переносить, BER перестал быть единственным окном. Но этот тонкий контракт не определял содержимое каталога, схему, базу, доступ и использование ответа.

Идея Heng Lu о минимальной начальной спецификации и локальных будущих решениях помогает удержать границу. Running-Code Primacy переносит проверку к реально работавшим парсеру и серверу. Слои реальности разделяют строку, дерево, BER, оценку, доступ, ответ и действие приложения.

Источники не называют инцидента или нынешнего продукта, не подтверждают раскрытие данных и не измеряют внедрение. Цепочка RFC — документальная эволюция, а не всеобщая миграционная квитанция. RFC 1558 сделал Filter видимым, но не превратил видимость в вердикт.

Источники