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

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

4.1.1. Конверт сообщения

В целях обмена сообщениями протокола, все операции протокола инкапсулируются в общий конверт LDAPMessage, который определяется так:

LDAPMessage ::= SEQUENCE {
     messageID       MessageID,
     protocolOp      CHOICE {
          bindRequest           BindRequest,
          bindResponse          BindResponse,
          unbindRequest         UnbindRequest,
          searchRequest         SearchRequest,
          searchResEntry        SearchResultEntry,
          searchResDone         SearchResultDone,
          searchResRef          SearchResultReference,
          modifyRequest         ModifyRequest,
          modifyResponse        ModifyResponse,
          addRequest            AddRequest,
          addResponse           AddResponse,
          delRequest            DelRequest,
          delResponse           DelResponse,
          modDNRequest          ModifyDNRequest,
          modDNResponse         ModifyDNResponse,
          compareRequest        CompareRequest,
          compareResponse       CompareResponse,
          abandonRequest        AbandonRequest,
          extendedReq           ExtendedRequest,
          extendedResp          ExtendedResponse,
          ...,
          intermediateResponse  IntermediateResponse },
     controls       [0] Controls OPTIONAL }
MessageID ::= INTEGER (0 .. maxInt)
maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --

Тип ASN.1 Controls (элементы управления) определён в разделе 4.1.11.

Назначение LDAPMessage — предоставить конверт, содержащий общие поля, требуемые во всех обменах сообщениями протокола. В настоящий момент общими полями являются только messageID и controls.

Если сервер получает от клиента LDAPMessage, в котором конструкция LDAPMessage SEQUENCE не может быть распознана, либо messageID не может быть разобран, либо значение в поле protocolOp не распознаётся как запрос, либо обнаружено, что закодированная структура или длина полей данных некорректны, то серверу следует (SHOULD) вернуть Notice of Disconnection (Уведомление об отключении), описанное в разделе 4.4.1, с результирующим кодом resultCode, установленным в protocolError, после чего он должен (MUST) немедленно завершить сессию LDAP как описано в разделе 5.3.

В остальных случаях, когда клиент или сервер не могут разобрать LDAP PDU, им следует (SHOULD) немедленно завершить сессию LDAP (раздел 5.3), если дальнейшее взаимодействие (в том числе предоставление уведомления) было бы пагубным. В противном случае реализации сервера должны (MUST) возвращать соответствующий ответ на запрос, с кодом resultCode, установленным в protocolError.

4.1.1.1. MessageID

Все конверты LDAPMessage, инкапсулирующие ответы, содержат значение messageID соответствующего запросного LDAPMessage.

MessageID запроса должно (MUST) иметь ненулевое значение, отличное от messageID любого другого запроса в течение одной и той же сессии LDAP. Нулевое значение зарезервировано для сообщений незапрошенных уведомлений (unsolicited notification message).

Обычно клиенты при каждом запросе увеличивают счётчик на единицу.

Клиенту недопустимо (MUST NOT) посылать запрос с тем же messageID, что и в предыдущих запросах, в рамках одной и той же сессии LDAP, за исключением тех случаев, когда есть возможность определить, что эти предыдущие запросы больше не обслуживаются сервером (например, после получения финального ответа, либо при выполнении очередного Bind). В противном случае поведение не определено. Также имейте ввиду, что операция Abandon и успешно сброшенные операции не посылают ответов.

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

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