Network Working Group Request for Comments: 2891 Категория: Standards Track T. Howes (Loudcloud), M. Wahl (Sun Microsystems), A. Anantha (Microsoft) Август 2000 года
Этот документ определяет стандарт протокола Интернет для сообщества Интернет, а также приглашает к обсуждению и подаче предложений по его усовершенствованию. Пожалуйста, сверяйтесь с текущей редакцией "Официальных стандартов протоколов Интернет" (STD 1), чтобы узнать состояние стандартизации и статус этого протокола. Ограничений на распространение данного документа не накладывается.
Copyright (C) The Internet Society (2000). Все права защищены.
В этом документе описываются два расширения LDAPv3 в виде элементов управления для сортировки результатов поиска на стороне сервера. Эти элементы управления позволяют клиенту указывать типы атрибутов и правила соответствия, которые следует использовать серверу при возвращении результатов в ответ на поисковый запрос LDAP, содержащий данные элементы управления. Эти элементы управления могут быть полезны, когда функциональность клиента LDAP ограничена, либо по каким-то иным причинам он не может сортировать результаты, но ему необходимо, чтобы они были отсортированы. Другие допустимые элементы управления поисковыми операциями не определяются в данном расширении.
Определяющие сортировку элементы управления позволяют серверу вернуть результирующий код по результатам выполнения сортировки, независимый от результирующего кода, возвращаемого самой операцией поиска.
Ключевые слова "MUST" (необходимо), "SHOULD" (следует) и "MAY" (возможно) в данном документе должны интерпретироваться так, как описано в BCP 14 [RFC2119].
Данный элемент управления включается в сообщение searchRequest как часть поля controls конструкции LDAPMessage, как определено в разделе 4.1.12 стандарта [LDAPv3].
Поле controlType элемента управления устанавливается в "1.2.840.113556.1.4.473". В поле criticality может (MAY) быть либо TRUE, либо FALSE на усмотрение клиента (при отсутствии подразумевается FALSE). Значением поля controlValue является строка октетов (OCTET STRING), которая представляет собой закодированное в BER значение следующей последовательности SEQUENCE:
SortKeyList ::= SEQUENCE OF SEQUENCE {
attributeType AttributeDescription,
orderingRule [0] MatchingRuleId OPTIONAL,
reverseOrder [1] BOOLEAN DEFAULT FALSE }
Ключи сортировки в последовательности SortKeyList указываются в порядке приоритета их применения от более высокого до более низкого.
Правило соответствия с идентификатором MatchingRuleId, как определено в разделе 4.1.9 стандарта [LDAPv3], должно (SHOULD) быть одним из тех, которые являются валидными для того типа атрибута, к которому оно применяется. Если это не так, сервер вернёт ошибку inappropriateMatching.
Каждый тип атрибута (в поле attributeType) должен присутствовать в последовательности SortKeyList только один раз. Если какой-либо тип атрибута включается в список ключей сортировки несколько раз, серверу следует вернуть ошибку unwillingToPerform в последовательности sortResult элемента управления ответа.
Если поле orderingRule опущено, должно (MUST) быть использовано правило соответствия типа ordering, определённое для применения с данным типом атрибута.
Любая совместимая с требованиями этого документа реализация данного элемента управления должна (MUST) позволять иметь список ключей сортировки с хотя бы одним ключом.
Данный элемент управления включается в сообщение searchResultDone как часть поля controls конструкции LDAPMessage, как определено в разделе 4.1.12 стандарта [LDAPv3].
Поле controlType элемента управления устанавливается в "1.2.840.113556.1.4.474". Поле criticality устанавливается в FALSE (может (MAY) отсутствовать). Значением поля controlValue является строка октетов (OCTET STRING), которая представляет собой закодированное в BER значение следующей последовательности SEQUENCE:
SortResult ::= SEQUENCE {
sortResult ENUMERATED {
success (0), -- результаты отсортированы
operationsError (1), -- внутренний сбой сервера
timeLimitExceeded (3), -- до окончания сортировки
-- превышено ограничение по времени
strongAuthRequired (8), -- отказ вернуть отсортированные
-- результаты по небезопасному
-- протоколу
adminLimitExceeded (11), -- слишком много совпавших записей
-- для сортировки сервером
noSuchAttribute (16), -- нераспознанный тип атрибута
-- в ключе сортировки
inappropriateMatching (18), -- нераспознанное или неподходящее
-- правило соответствия
-- в ключе сортировки
insufficientAccessRights (50), -- отказ вернуть отсортированные
-- результаты данному клиенту
busy (51), -- слишком занят для обработки
-- сортировки
unwillingToPerform (53), -- не в состоянии отсортировать
other (80)
},
attributeType [0] AttributeDescription OPTIONAL }
В элементе управления sortKeyRequestControl определяются один или несколько типов атрибутов и правил соответствия для результатов, возвращаемых в ответ на поисковый запрос. Серверу следует (SHOULD) вернуть все результаты для данного поискового запроса в порядке, определяемом этими ключами сортировки. Если поле reverseOrder установлено в TRUE, то отобранные записи будут представлены в обратном порядке сортировки для указанного ключа.
Существует шесть возможных сценариев, которые могут возникнуть в результате включения элемента управления сортировки в запрос поиска:
unavailableCriticalExtension в сообщении searchResultDone и не отправлять обратно никаких других результатов. Tакое поведение определено в разделе 4.1.12 стандарта [LDAPv3].unavailableCriticalExtension в сообщении searchResultDone; включить элемент управления sortKeyResponseControl в сообщение searchResultDone, и не отправлять обратно никаких найденных в результате поиска записей.success.Клиентское приложение может с уверенностью считать, что результаты поиска отсортированы в порядке, заданном ключами сортировки, если и только если в элементе управления sortKeyResponseControl результирующий код установлен в success. Если сервер не включил элемент управления sortKeyResponseControl в сообщение searchResultDone, клиенту следует (SHOULD) полагать, что элемент управления сортировки был проигнорирован этим сервером.
Если сервер включает элемент управления sortKeyResponseControl в сообщение searchResultDone, то поле sortResult должно быть либо установлено в success, если результаты были отсортированы в соответствии с теми ключами, которые были указаны в элементе управления sortKeyRequestControl, либо установлено в соответствующий код ошибки, отражающей причину, по которой сервер не может отсортировать данные (такой как noSuchAttribute или inappropriateMatching). Опционально, сервер может (MAY) задать в поле attributeType первый тип атрибута из указанных в последовательности SortKeyList, сортировка по которому привела к ошибке. Клиенту следует (SHOULD) проигнорировать поле attributeType, если поле sortResult установлено в success.
Сервер может оказаться не в состоянии отсортировать результаты с использованием указанных ключей сортировки, поскольку он может не распознать один из типов атрибутов, либо правило соответствия, связанное с типом атрибута, может быть неприменимо, либо в результатах поиска может не оказаться ни одного атрибута из указанных типов. Серверы также могут накладывать ограничение на количество ключей, разрешённых в данном элементе управления, например, поддерживать только один ключ.
Серверам, которые осуществляют "сцепление", то есть перенаправление запросов другим серверам LDAP, следует убедиться, что сервер, удовлетворяющий запрос клиента, отсортировал полный набор результатов, перед тем, как отправлять эти результаты обратно.
Если сервер получает запрос с элементом управления сортировки, то клиент ожидает получить в ответ отсортированный набор результатов. Если клиент отправляет запрос с элементом управления сортировки на сервер, который перенаправляет этот запрос по цепочке и получает записи с нескольких серверов, а клиент установил поле criticality расширения сортировки в TRUE, то сервер должен (MUST) объединить и отсортировать эти результаты перед тем, как вернуть их клиенту, либо должен (MUST) вернуть ошибку unwillingToPerform.
В записи, удовлетворяющей критериям поиска, может отсутствовать один или несколько ключей сортировки. В этом случае считается, что запись имеет значение NULL для такого ключа. В данном стандарте NULL рассматривается как значение, большее, чем все остальные действительные значения для такого ключа. Например, если задан только один ключ сортировки, то записи, удовлетворяющие критериям поиска, но не имеющие этого ключа, будут помещены после всех записей, у которых такой ключ есть. Если задан флаг reverseOrder и только один ключ сортировки, то записи, удовлетворяющие критериям поиска, но не имеющие этого ключа, будут помещены ПЕРЕД всеми записями, у которых такой ключ есть.
Если в ключе сортировки указан многозначный атрибут и в записи есть несколько значений для этого атрибута, а также отсутствуют другие элементы управления, которые могут повлиять на порядок сортировки, то серверу следует (SHOULD) использовать наименьшее значение атрибута (в соответствии с правилом ORDERING для этого атрибута).
Когда элемент управления sortKeyRequestControl включается в запрос совместно с элементом управления pagedResultsControl, определённом в документе [LdapPaged], серверу следует посылать сообщения searchResultEntry, отсортированные в соответствии с ключами сортировки, применёнными к полному набору результатов. Серверу не следует просто отсортировать каждую страницу, поскольку в этом случае клиент получит ошибочные результаты.
Последовательность sortKeyList должна присутствовать в каждом сообщении searchRequest для запроса постраничных результатов. Также она не должна меняться в запросах searchRequest для постраничных результатов одного и того же результирующего набора данных. Если сервер отсортировал данные, ему следует (SHOULD) включать элемент управления sortKeyResponseControl в каждое сообщение searchResultDone для каждой страницы. Это позволит клиентам быстро определять, был ли результирующий набор данных отсортирован, не дожидаясь получения всего результирующего набора данных.
Разработчикам и администраторам следует иметь ввиду, что разрешение сортировки результатов может привести к ситуации, когда станет возможным извлечение из заданной службы каталогов большого количества данных, независимо от административных ограничений, накладываемых на максимальное количество возвращаемых записей.
Клиент, желающий получить все записи из службы каталогов, может использовать комбинацию сортировки и обновления поисковых фильтров для извлечения всех имеющихся в базе данных записей в виде небольших результирующих наборов данных, обходя таким образом административные ограничения.
Предотвратить такое поведение можно путём разумного применения администратором разрешений на доступ к записям каталога и интеллектуальной реализации административных ограничений на количество записей, извлекаемых клиентом.
[LDAPv3] Wahl, M, Kille, S. и T. Howes, "Lightweight Directory Access Protocol (v3)", RFC 2251, декабрь 1997 г.
[Bradner97] Bradner, S., "Ключевые слова для обозначения уровня требований в RFC", BCP 14, RFC 2119, март 1997 г.
[LdapPaged] Weider, C., Herron, A., Anantha, A. и T. Howes, "Расширение LDAP в виде элемента управления для манипуляций с простыми постраничными результатами", RFC 2696, сентябрь 1999 г.
Anoop Anantha
Microsoft Corp., 1 Microsoft way, Redmond, WA 98052, USA
Телефон: +1 425 882-8080
EMail: anoopa@microsoft.com
Tim Howes
Loudcloud, Inc., 615 Tasman Dr., Sunnyvale, CA 94089, USA
EMail: howes@loudcloud.com
Mark Wahl
Sun Microsystems, Inc., 8911 Capital of Texas Hwy Suite 4140, Austin, TX 78759, USA
EMail: Mark.Wahl@sun.com
Copyright (C) Internet Society (2000). Все права защищены.
Этот документ и его переводы могут быть скопированы и переработаны в другие документы. Производные работы, комментирующие или иным способом поясняющие данный документ, либо оказывающие помощь в его реализации, могут быть подготовлены, скопированы, опубликованы и распространены, целиком или частями, без каких-либо ограничений, при условии, что указанное выше уведомление об авторском праве и этот параграф будут включены во все такие копии и производные работы. Однако, в этот документ как таковой не может быть внесено каких-либо изменений, таких как удаление уведомления об авторских правах или ссылок на Internet Society или другие организации Интернет, за исключением случаев, когда это требуется для разработки стандартов Интернет (при этом должны быть пройдены процедуры получения авторских прав, определённые в стандартах Интернет), либо когда это требуется при переводе на языки, отличные от английского.
Предоставляемые выше ограниченные права являются бессрочными и не подлежат отзыву Internet Society, его наследниками или правопреемниками.
Этот документ и содержащаяся в нём информация распространяются "КАК ЕСТЬ" и INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБЫЕ ГАРАНТИИ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ ПРИВЕДЁННОЙ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШАЕТ КАКИХ-ЛИБО ПРАВ ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ПРИГОДНОСТИ ДЛЯ КОНКРЕТНЫХ ЦЕЛЕЙ.
Финансирование функций RFC Editor в настоящий момент обеспечивается Internet Society.