3. Модель протокола
Общей моделью для данного протокола является та, при которой клиенты выполняют операции протокола на серверах. В этой модели клиент передаёт запрос протокола, описывающий ту операцию, которая должна быть выполнена, на сервер. После этого уже сервер является ответственным за выполнение необходимой операции (операций) в каталоге. Обычно по завершению операции сервер возвращает клиенту, выполнявшему запрос, ответ, содержащий соответствующие данные.
Как правило, операции протокола не зависят одна от другой. Каждая операция обрабатывается как атомарное действие, оставляющее каталог в целостном состоянии.
Хотя серверы должны возвращать ответы всякий раз, когда они определены в протоколе, не выдвигается требований синхронного поведения ни со стороны клиентов, ни со стороны серверов. В общем случае для нескольких операций обмен запросами и ответами между клиентом и сервером может происходить в любом порядке. При необходимости синхронное поведение может быть проконтролировано клиентскими приложениями.
Основные операции протокола, определённые в этом документе, могут быть отображены в подмножество абстрактной службы каталогов (Directory Abstract Service) X.500 (1993) [X.511]. Тем не менее, не существует взаимно-однозначного соответствия между операциями LDAP и операциями Directory Access Protocol (DAP) X.500. Реализации сервера, выступающей в роли шлюза к каталогам X.500, может потребоваться выполнить несколько запросов DAP для обработки одного запроса LDAP.
3.1. Взаимосвязь между операциями и уровнем сообщений LDAP
Обмен операциями протокола происходит на уровне сообщений LDAP. При закрытии транспортного соединения любые незавершённые операции на уровне сообщений LDAP отбрасываются (если это возможно), либо завершаются без передачи ответа (когда отказаться от их выполнения невозможно). Также, при закрытии транспортного соединения, клиент не должен (MUST NOT) подразумевать, что любые незавершившиеся операции обновления были выполнены успешно или неуспешно.
4. Элементы протокола
Протокол описан с использованием Abstract Syntax Notation One ([ASN.1]) и передаётся с использованием подмножества ASN.1 Basic Encoding Rules ([BER]). В разделе 5 определяется, каким образом кодируются и передаются элементы протокола.
В целях поддержки будущих расширений данного протокола, расширяемость подразумевается там, где это разрешено в ASN.1 (то есть, расширяемыми являются типы sequence, set, choice и enumerated). Кроме того, типы ASN.1, которые являются явно расширяемыми, о чём говорится в [RFC4520], были снабжены многоточием (...). Из-за такой подразумеваемой расширяемости клиенты и серверы должны (MUST) (если не указано иное) игнорировать компоненты SEQUENCE, теги которых они не могут распознать.
Для изменений протокола, кроме тех, которые являются расширениями описанных здесь механизмов, требуется другой номер версии. Клиент указывает используемый им номер версии в составе запроса BindRequest, описанного в разделе 4.2. Если клиент не посылает Bind, сервер должен (MUST) подразумевать, что клиент использует версию 3 или выше.
Клиент может попытаться определить поддерживаемую сервером версию протокола путём прочтения атрибута 'supportedLDAPVersion' записи root DSE (DSA-Specific Entry) [RFC4512].
4.1. Общие элементы
В этом разделе описывается формат блока данных протокола "Конверт сообщения LDAP" (LDAPMessage envelope Protocol Data Unit (PDU)), а также определения типов данных, которые используются в операциях протокола.