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

RFC 4511, Страница 49 из 51

C.1.22. Раздел 4.7 (Операция Add)

  • Операция Add приведена в соответствие со стандартом X.511 в том, что при создании записи атрибуты RDN используются вместе с явно перечисленными атрибутами. До этого требовалось, чтобы значения, образующие уникальное имя, присутствовали в списке добавляемых атрибутов.

  • Удалено требование, что атрибут objectClass должен (MUST) быть указан, в связи с тем, что в некоторых типах DSE этот атрибут не требуется. Вместо этого была добавлена общая формулировка, что добавляемая запись должна придерживаться модели данных.

  • Удалена рекомендация по размещению объектов. Об этом говорится в документе по модели данных.

C.1.23. Раздел 4.9 (Операция Modify DN)

  • Установлено требование, чтобы серверы не разыменовывали псевдонимы для операции Modify DN. Оно было добавлено для совместимости с другими операциями и для обеспечения согласованности данных.

  • Операции Modify DN позволено завершаться неудачей при попытке перемещения записи между контекстами именования.

  • Определено, что произойдёт, когда указанные в поле newrdn атрибуты не присутствуют в записи.

C.1.24. Раздел 4.10 (Операция Compare)

  • Определено, что результирующий код compareFalse означает, что сравнение произведено и его результат — false. Существовала путаница, вводящая людей в заблуждение, что при результате сравнения Undefined возвращается код compareFalse.

  • Установлено требование, чтобы серверы не разыменовывали псевдонимы для операции Compare. Оно было добавлено для совместимости с другими операциями и для обеспечения согласованности данных.

C.1.25. Раздел 4.11 (Операция Abandon)

  • Дано разъяснение, что поскольку операция Abandon не возвращает ответа, клентам не следует её использовать, если им важно знать результат.

  • Указано, что нельзя отказаться от выполнения операций Abandon и Unbind.

C.1.26. Раздел 4.12 (Операция Extended)

  • Определено, каким образом должны кодироваться значения операций-расширений Extended, определённые в терминах ASN.1.

  • Добавлены инструкции о том, из чего должна состоять спецификация операции-расширения Extended.

  • Добавлена рекомендация, что серверам следует афишировать поддерживаемые операции-расширения Extended.

C.1.27. Раздел 5.2 (Протоколы передачи)

  • Инструкции, касающиеся отсылок, перенесены в разделы по отсылкам.

Страница 49 из 51

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