RFC: 4511
Оригинал: Lightweight Directory Access Protocol (LDAP): The Protocol
Предыдущие версии: RFC 2251, RFC 2830, RFC 3771
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Pro-LDAP.ru
4.5.1.6. SearchRequest.typesOnly

Индикатор того, должны ли результаты операции Search содержать и описания атрибутов, и значения, либо только описания атрибутов. Установка этого поля в TRUE приведёт к возврату только описаний атрибутов (без значений). Установка этого поля в FALSE приведёт к возврату и описаний атрибутов, и значений.

4.5.1.7. SearchRequest.filter

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

Для формирования комбинаций фильтров могут быть использованы пункты "and", "or" и "not". Как минимум один элемент фильтра должен (MUST) присутствовать при использовании пунктов "and" или "or". Элементы фильтра предназначены для нахождения совпадений значений индивидуальных атрибутов записей в диапазоне поиска.

Примечание для тех, кто занимается реализацией: фильтр "not" является примером поименованного пункта в модуле с неявным именованием. В BER это интерпретируется как явное именование.

Сервер должен (MUST) оценить фильтры в соответствии с трехзначной логикой согласно пункта 7.8.1 стандарта [X.511] (1993). Если коротко, фильтр оценивается как "TRUE", "FALSE" или "Undefined". Если фильтр оценивается как TRUE для конкретной записи, то атрибуты такой записи возвращаются как часть результата операции Search (после проверки на соответствие любым применимым к записи ограничениям контроля доступа). Если фильтр оценивается как FALSE или Undefined, то для этой операции Search запись игнорируется.

Фильтр с пунктом "and" оценивается как TRUE, если все фильтры в наборе SET OF оцениваются как TRUE, и как FALSE, если хотя бы один фильтр оценивается как FALSE; в противном случае такой фильтр оценивается как Undefined. Фильтр с пунктом "or" оценивается как FALSE, если все фильтры в наборе SET OF оцениваются как FALSE, и как TRUE, если хотя бы один фильтр оценивается как TRUE; в противном случае такой фильтр оценивается как Undefined. Фильтр с пунктом "not" оценивается как TRUE, если подвергаемый отрицанию фильтр оценивается как FALSE; как FALSE, если подвергаемый отрицанию фильтр оценивается как TRUE, и как Undefined, если подвергаемый отрицанию фильтр оценивается как Undefined.

Фильтр оценивается как Undefined, когда сервер не в состоянии определить, соответствует ли значение утверждения записи. Возможные примеры:

  • Описание атрибута в фильтрах equalityMatch, substrings, greaterOrEqual, lessOrEqual, approxMatch или extensibleMatch не распознаётся сервером.

  • Запрашиваемое правило соответствия не определено в типе атрибута.

  • Идентификатор MatchingRuleId в фильтре extensibleMatch не распознаётся сервером или не является действительным для данного типа атрибута.

  • Тип запрашиваемого фильтра не реализован.

  • Значение утверждения не верно.

Например, если сервер не распознаёт тип атрибута shoeSize, то каждый из фильтров (shoeSize=*), (shoeSize=12), (shoeSize>=12) и (shoeSize<=12) будет оцениваться как Undefined.

Серверы не должны (MUST NOT) возвращать ошибок, если они не могут распознать описания атрибутов или идентификаторы правил соответствия, определяют неверное значение утверждения или не поддерживают синтаксис утверждения. Дополнительные подробности обработки фильтров приведены в пункте 7.8 стандарта [X.511].

2007 - 2017 © Русские переводы RFC, IETF, ISOC.