1.3.2. Ожидание посылок изменений (refreshAndPersist)
Опрос изменений может быть дорогостоящим с точки зрения потребляемых ресурсов сервера, клиента и сети. Режим refreshAndPersist позволяет выполнять активные обновления изменённых в содержимом каталога записей.
При выборе режима refreshAndPersist клиент запрашивает, чтобы сервер посылал обновления записей, которые изменились после того, как было установлено состояние первоначального обновления содержимого каталога. Вместо того, чтобы отправить сообщение SearchResultDone Message как в режиме опроса, сервер посылает клиенту сообщение Sync Info Message, показывающее, что стадия обновления (refresh stage) завершена, а затем входит в стадию непрерывного обслуживания (persist stage). После получения сообщения Sync Info Message клиент будет конструировать синхронизированную копию, как это описано в разделе 1.3.1.
Сервер затем может отправлять уведомления об изменениях как результат оригинального поискового запроса Sync, выполнение которого теперь происходит непрерывно на сервере. Для записей, добавляемых в то содержимое каталога, которое было возвращено клиенту, сервер посылает сообщение SearchResultEntry Message (с атрибутами) с элементом управления Sync State Control, в котором указано состояние add. Для записей, удаляемых из содержимого каталога, сервер посылает сообщение SearchResultEntry Message без атрибутов и с элементом управления Sync State Control, в котором указано состояние delete. Для записей, изменяемых в том содержимом каталога, которое было возвращено клиенту, сервер посылает сообщение SearchResultEntry Message (с атрибутами) с элементом управления Sync State Control, в котором указано состояние modify.
При изменении записи посылаются все (изменённые и неизменённые) атрибуты, принадлежащие содержимому каталога.
Обратите внимание, что переименование записи DIT может привести к изменению с состоянием add, если при переименовании запись попадает в содержимое каталога, к изменению с состоянием delete, если при переименовании запись выходит за рамки содержимого каталога, и к изменению с состоянием modify, если запись остаётся в содержимом каталога. Также обратите внимание, что модификация записи DIT может привести к изменению в содержимом каталога с состоянием add, delete или modify.
После получения уведомления об изменении клиент обновляет свою копию содержимого каталога.
Если сервер во время стадии непрерывного обслуживания захочет обновить syncCookie, он может включить syncCookie в любой возвращаемый элемент управления Sync State Control или сообщение Sync Info Message.
Данная операция продолжается до тех пор, пока не будет отменена клиентом [RFC3909] или прекращена сервером. При этом для предоставления нового syncCookie к сообщению SearchResultDone Message должен быть присоединён элемент управления Sync Done Control.
1.4. Соглашения
Ключевые слова "MUST" (необходимо), "MUST NOT" (недопустимо), "REQUIRED" (требуется), "SHALL" (нужно), "SHALL NOT" (не нужно), "SHOULD" (следует), "SHOULD NOT" (не следует), "RECOMMENDED" (рекомендуется), "MAY" (возможно) и "OPTIONAL" (необязательно) в данном документе должны интерпретироваться так, как описано в BCP 14 [RFC2119].
Элементы протокола описываются с помощью ASN.1 [X.680] с неявными тэгами. Термин "закодирован BER" означает, что элемент должен быть закодирован с помощью Basic Encoding Rules [X.690] с соблюдением ограничений, подробно описанных в разделе 5.1 [RFC4511].