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

C.1.8. Раздел 4.1.8 (Атрибут)

  • Определения частичного атрибута (PartialAttribute) и атрибута (Attribute) объединены в одном разделе, и определение атрибута Attribute базируется на определении частичного атрибута PartialAttribute.

C.1.9. Раздел 4.1.10 (Результирующее сообщение)

  • Поле "errorMessage" переименовано в "diagnosticMessage" чтобы можно было посылать в нём описание неошибочных результатов.

  • Некоторая часть информации перенесена в приложение A, и читателям дана ссылка на новое местоположение.

  • Наличие поля matchedDN разрешено и для результирующих кодов, отличных от тех, что перечислены в RFC 2251.

  • Код "strongAuthRequired" переименован в "strongerAuthRequired" для более точной передачи его смысла: данный код часто может быть возвращён, чтобы показать, что для выполнения заданной операции требуется более строгая аутентификация.

C.1.10. Раздел 4.1.11 (Отсылка)

  • Отсылки определены в терминах URI а не URL.

  • Удалено требование, что все URI отсылки должны (MUST) быть одинаково пригодны для одного и того же продолжения операции. Это заявление было неоднозначным и никаких инструкций о том, как его выполнить, не предоставлялось.

  • Добавлено требование, что клиенты не должны (MUST NOT) зацикливаться между серверами.

  • Уточнены инструкции по использованию LDAPURL в отсылках и, в рамках этого, добавлена рекомендация о наличии части scope в LDAPURL.

  • Удалены требования, обязывавшие клиента использовать URL определённым образом для продолжения операции. Они препятствовали совместимости.

C.1.11. Раздел 4.1.12 (Элементы управления)

  • Указано, как должны быть закодированы значения элементов управления, определённые в терминах ASN.1.

  • Отмечено, что поле criticality применяется только к сообщениям запроса (за исключением UnbindRequest), и должно быть проигнорировано при его появлении в сообщениях ответа и UnbindRequest.

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

  • Добавлены формулировки относительно комбинации элементов управления и их упорядочивания в сообщении.

  • Указано, что при неопределённой или неизвестной семантике комбинации элементов управления возвращается ошибка protocolError.

  • В параграфе 8 выражение "сервер должен (MUST) быть готов" изменено на "реализации должны (MUST) быть готовы" для отражения того, что реализации и клиента, и сервера должны уметь обрабатывать подобную ситуацию (разбирать элементы управления).

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