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) быть готовы" для отражения того, что реализации и клиента, и сервера должны уметь обрабатывать подобную ситуацию (разбирать элементы управления).