RFC: 4533
Оригинал: The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operatio
Категория: Экспериментальный
Дата публикации:
Автор:
Перевод: pro-ldap.ru

Перевод выполнен участниками проекта. Предложения по улучшению перевода и сообщения об ошибках принимаются на форуме проекта.

Статус документа

В данном документе определён экспериментальный протокол для сообщества Internet. В нём не определяется какого-либо рода стандарт Internet.

Обсуждение и предложения по улучшению приветствуются.

Допускается свободное распространение документа.

Уведомление об авторских правах

Copyright (C) Internet Society (2006).

Уведомление IESG

IESG уведомляет, что обсуждение данной работы изначально проводилось в рабочей группе LDUP. Группа пришла к соглашениям по различным вопросам, и это было задокументировано в RFC 3928, который не является стандартом (статус — предложенный стандарт) и подлежит пересмотру теми, кто собирается реализовывать данные предложения.

Тезисы

В данной спецификации описывается операция синхронизации содержимого каталога, основанного на Lightweight Directory Access Protocol (LDAP). Эта операция позволяет клиенту поддерживать копию фрагмента информационного дерева каталога (Directory Information Tree, DIT). В ней поддерживается как запрос изменений, так и ожидание посылок изменений. Данная операция определяется как расширение операции поиска LDAP.

Содержание

1. Введение

Lightweight Directory Access Protocol (LDAP) [RFC4510] предоставляет механизм, операцию поиска [RFC4511], позволяющую клиенту запросить содержимое каталога, соответствующее комплексному набору утверждений, и сервер, подвергнув этот запрос контролю доступа и проверке по другим ограничениям, вернёт данное содержимое клиенту. Однако, LDAP не предоставляет (несмотря на вынесение на обсуждение многочисленных расширений в этой области) эффективного и действенного механизма для поддержания синхронизированных копий содержимого каталога. В данном документе представлен новый механизм, специально разработанный для удовлетворения требований синхронизации содержимого сложных приложений в области каталогов.

В этом документе определяется операция синхронизации содержимого каталога LDAP (LDAP Content Synchronization Operation), или, для краткости, операция Sync, позволяющая клиенту поддерживать синхронизированную копию фрагмента информационного дерева каталога (Directory Information Tree, DIT). Операция Sync определяется как набор элементов управления и других элементов протокола, расширяющих операцию поиска.

1.1. Предпосылки

В течение нескольких лет выдвигался ряд подходов синхронизации содержимого, которые можно было бы использовать в службах каталогов LDAP. Все эти подходы были неудовлетворительны по одной или нескольким из следующих причин:

  • неспособность обеспечить разумный уровень конвергенции (схождения);

  • неспособность определить, что конвергенция не может быть достигнута (без перезагрузки);

  • необходимость иметь заранее подготовленные соглашения синхронизации;

  • необходимость поддержания на сервере истории изменений, произошедших в содержимом DIT, и/или мета-информации;

  • необходимость поддержания на сервере состояния синхронизации для каждого клиента; и/или

  • порождение чрезмерного количества трафика.

Операция Sync предоставляет конечную конвергенцию синхронизируемого содержимого там, где это возможно, а если такой возможности нет — уведомление о необходимости полной перезагрузки.

Операция Sync не требует заранее подготовленных соглашений синхронизации.

Операция Sync не требует, чтобы серверы поддерживали или использовали какую-либо историю изменений в DIT или в мета-информации. Однако, серверы могут поддерживать и использовать историю изменений в том или ином виде (например, журналы изменений, копии удалённых записей (tombstones), снимки DIT) для снижения количества генерируемых сообщений и уменьшения их размера. Поскольку поддерживать и использовать историю изменений возможно не всегда, данная операция может быть реализована с использованием обычных (на текущий момент) подходов, основанных на состоянии. Операция Sync позволяет варьировать от операции к операции использование подхода, основанного на состоянии, или подхода, основанного на истории, для балансировки размера хранилища истории изменений и количества трафика. Также операция Sync позволяет комбинировать использование подходов, основанных на состоянии и истории.

Операция Sync не требует, чтобы серверы поддерживали состояние синхронизации для каждого клиента. Однако, серверы могут поддерживать и использовать информацию о состоянии для каждого клиента для уменьшения количества генерируемых сообщений и размера таких сообщений.

Механизм синхронизации считается чрезмерно болтливым, если нет разумных ограничений на трафик, порождаемый синхронизацией. Трафик, порождаемый операцией Sync, ограничивается размером изменённых (или новых) записей и количеством неизменённых записей в содержимом каталога. Данная операция разработана таким образом, чтобы избежать пересылок полного содержимого каталога даже в том случае, когда доступной серверу информации об истории изменений недостаточно для определения состояния клиента. Также данная операция разработана так, чтобы избежать передачи выходящей за рамки содержимого каталога информации об истории изменений, поскольку размер этой информации не ограничивается размером содержимого каталога, а также не всегда возможно передавать подобную информацию об истории изменений из соображений безопасности.

Этот документ включает несколько ненормативных приложений, предоставляющих дополнительную информацию для тех, кто занимается реализацией серверов.

1.2. Предназначение

Операция Sync предназначена для использования в приложениях, которым требуется, чтобы в результате синхронизации содержимого была достигнута конвергенция (схождение). По окончании каждого этапа синхронизации в данной операции вся информация, требуемая для построения синхронизированной клиентской копии содержимого, предоставляется клиенту, либо клиент оповещается о том, что необходима полная перезагрузка содержимого. Клиентская копия представляет собой точное отражение содержимого каталога сервера, за исключением временных несоответствий, вызванных обрабатываемыми на сервере конкурентными (или другими) операциями. Временные несоответствия будут разрешены при выполнении последующих операций синхронизации.

Некоторые возможные области применения:

  • Приложения, осуществляющие сервис белых страниц, могут использовать операцию Sync для поддержания текущей копии фрагмента DIT. Пример: почтовый клиент (mail user agent, MUA), использующий операцию Sync для поддержания локальной копии адресной книги предприятия.

  • Инструменты работы с мета-информацией могут использовать операцию Sync для поддержания копии фрагмента DIT.

  • Кэширующие прокси-сервисы могут использовать операцию Sync для поддержания когерентного содержимого кэша.

  • Облегчённая репликация главный-подчинённый (master-slave) между гетерогенными серверами каталогов. Например, операция Sync может быть использована подчинённым сервером для поддержания теневой копии фрагмента DIT. (Примечание: International Telephone Union (ITU) ввёл определение протокола X.500 Directory [X.500] Information Shadowing Protocol (DISP) [X.525], который может использоваться для репликации главный-подчинённый между серверами каталогов. Также существуют другие экспериментальные протоколы репликации LDAP).

Данный протокол не предназначен для использования в приложениях, которым необходима согласованность данных на уровне транзакций.

Поскольку в данном протоколе при внесении изменений передаются все видимые значения изменённых записей содержимого каталога, а не только дельты изменений, он не подходит для приложений или систем с узкой полосой пропускания трафика.

1.3. Обзор

В этом подразделе представлен обзор основных путей использования операции Sync для поддержания синхронизированной клиентской копии фрагмента DIT.

  • Запрос (опрос) изменений: режим refreshOnly.

  • Ожидание посылок изменений: режим refreshAndPersist.

1.3.1. Запрос (опрос) изменений (refreshOnly)

Для получения своей первоначальной клиентской копии клиент выполняет запрос Sync: поисковый запрос с элементом управления Sync Request Control, режим которого задан как refreshOnly. Сервер, также, как это происходит при нормальной операции поиска, возвращает (после контроля доступа и проверок по другим ограничениям) содержимое, удовлетворяющее критериям поиска (база поиска, диапазон, фильтр, атрибуты). Кроме того, с каждой возвращаемой записью сервер предоставляет элемент управления Sync State Control, в котором указано состояние add (необходимость добавить запись). Этот элемент управления содержит универсальный уникальный идентификатор (Universally Unique Identifier, UUID) [UUID] записи [RFC4530]. В отличие от уникального имени (Distinguished Name, DN), которое может со временем меняться, UUID записи неизменен. За первоначальным содержимым следует сообщение SearchResultDone Message с элементом управления Sync Done Control. В элементе управления Sync Done Control имеется синхронизационное куки syncCookie, в котором представлено состояние сессии.

Чтобы запросить изменения для своей клиентской копии, клиент снова выполняет операцию Sync с возвращённым в предыдущий раз syncCookie. Сервер, также, как это происходит при нормальной операции поиска, определяет, какое содержимое должно быть возвращено в том случае, если бы это была нормальная операция поиска. Однако, используя syncCookie как индикатор того, какое содержимое было отправлено клиенту в прошлый раз, сервер посылает копии изменившихся записей с элементом управления Sync State Control, в котором указано состояние add. Для каждой изменённой записи отправляются все принадлежащие содержимому каталога атрибуты (изменённые и неизменённые).

Сервер может выполнить какую-либо из двух или сразу обе различные синхронизационные фазы, отличающиеся друг от друга тем, каким образом синхронизируются удалённые из содержимого каталога записи: фаза наличия (present phase) и фаза удаления (delete phase). Если сервер на стадии обновления использует только одну фазу, она помечается как окончательная посылкой сообщения SearchResultDone Message с элементом управления Sync Done Control. Фаза наличия идентифицируется путём установки в элементе управления Sync Done Control значения refreshDeletes в FALSE. Фаза удаления идентифицируется установкой значения refreshDeletes в TRUE. За фазой наличия может следовать фаза удаления. Эти две фазы отделяются друг от друга сообщением refreshPresent Sync Info Message, у которого значение refreshDone установлено в FALSE. В случае, когда используются обе фазы, фаза наличия применяется для приведения клиентской копии в состояние, с которого может начаться последующая фаза удаления.

В фазе наличия сервер отправляет пустую запись (то есть запись без атрибутов) с элементом управления Sync State Control, в котором указано состояние present, для каждой неизменённой записи.

Фаза удаления может применяться, когда сервер способен достоверно определить, каких записей из прежней клиентской копии больше нет в содержимом каталога, и количество таких записей меньше или равно количеству неизменённых записей. В режиме удаления сервер отправляет пустую запись с элементом управления Sync State Control, в котором указано состояние delete, для каждой записи, не присутствующей больше в содержимом каталога, вместо того, чтобы возвращать пустую запись с состоянием present для каждой присутствующей записи.

Сервер может посылать сообщения syncIdSet Sync Info Message, содержащие набор UUID либо неизменённых записей, присутствующих в содержимом каталога, либо удалённых записей, вместо того, чтобы отправлять несколько индивидуальных сообщений. Если значение refreshDeletes в syncIdSet установлено в FALSE, в наборе syncUUIDs содержатся UUID неизменённых записей, присутствующих в содержимом каталога; если значение refreshDeletes в syncIdSet установлено в TRUE, в наборе syncUUIDs содержатся UUID записей, которых больше нет в содержимом каталога. В syncIdSet может быть включено необязательное куки для представления состояния содержимого каталога после того, как будет синхронизировано присутствие или отсутствие записей, содержащихся в наборе syncUUIDs.

Синхронизированная копия фрагмента DIT конструируется клиентом.

Если в syncDoneValue значение refreshDeletes установлено в FALSE, новая копия включает в себя все изменённые записи, возвращённые повторной операцией Sync, а также все неизменённые записи, идентифицированные повторной операцией Sync как находящиеся в наличии, содержимое которых было предоставлено предыдущей операцией Sync. Неизменённые записи, не идентифицированные как находящиеся в наличии, удаляются из содержимого каталога клиента. Они могут быть либо удалены, либо перемещены, либо как-то иначе выведены за пределы содержимого каталога.

Если в syncDoneValue значение refreshDeletes установлено в TRUE, новая копия включает в себя все изменённые записи, возвращённые повторной операцией Sync, а также все остальные записи предыдущей копии за исключением тех, которые идентифицированы как удалённые из содержимого каталога.

По прошествии времени клиент может выполнить повторный запрос (опрос) изменений данной синхронизированной клиентской копии.

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].

2. Элементы операции Sync

Операция Sync определяется как расширение операции поиска LDAP [RFC4511], где пользовательский агент каталога (directory user agent, DUA или клиент) посылает сообщение SearchRequest Message с элементом управления Sync Request Control, системный агент каталога (directory system agent, DSA или сервер) отвечает нулём или более сообщений SearchResultEntry Message, каждое из которых содержит элемент управления Sync State Control; нулём или более сообщений SearchResultReference Message, каждое из которых содержит элемент управления Sync State Control; нулём или более сообщений Sync Info Intermediate Response Message; и сообщением SearchResultDone Message с элементом управления Sync Done Control.

Для того, чтобы клиенты могли определить, поддерживает ли сервер данную операцию, серверам, осуществляющим данную операцию, следует (SHOULD) публиковать 1.3.6.1.4.1.4203.1.9.1.1 в качестве значения атрибута 'supportedControl' [RFC4512] в корне своей DSA-specific entry (DSE). Сервер может (MAY) избрать тактику афиширования данного расширения только в том случае, когда клиент авторизован (имеет право) использовать его.

2.1. Общие элементы ASN.1

2.1.1. syncUUID

Тип данных syncUUID — строка октетов (OCTET STRING), содержащая 128-битный (16-октетный) универсальный уникальный идентификатор (Universally Unique Identifier, UUID) [UUID].

syncUUID ::= OCTET STRING (SIZE(16))
     -- constrained to UUID

2.1.2. syncCookie

syncCookie — введённая для удобства обозначения формулировка, указывающая на то, что, хотя тип syncCookie кодируется как строка октетов (OCTET STRING), его значение — непрозрачная величина, содержащая информацию о синхронизационной сессии и её состоянии. Как правило, информация о сессии включает в себя хэш операционных параметров, которые по требованию сервера нельзя изменять, а информация о состоянии синхронизации включает в себя порядковый номер подтверждения (журнала), порядковый номер изменения или отметку времени. Для удобства описания термин "нет куки" ("no cookie") указывает либо на нулевой куки, либо на куки с предварительно проинициализированным состоянием синхронизации.

syncCookie ::= OCTET STRING

2.2. Sync Request Control

Sync Request Control — элемент управления LDAP [RFC4511], в котором controlType — идентификатор объекта 1.3.6.1.4.1.4203.1.9.1.1, а controlValue — строка октетов (OCTET STRING), содержащая syncRequestValue, закодированное BER. Поле criticality элемента управления — либо TRUE, либо FALSE.

syncRequestValue ::= SEQUENCE {
    mode ENUMERATED {
        -- 0 unused
        refreshOnly       (1),
        -- 2 reserved
        refreshAndPersist (3)
    },
    cookie     syncCookie OPTIONAL,
    reloadHint BOOLEAN DEFAULT FALSE
}

Элемент управления Sync Request Control может применяться только для сообщений SearchRequest Message.

2.3. Sync State Control

Sync State Control — элемент управления LDAP [RFC4511], в котором controlType — идентификатор объекта 1.3.6.1.4.1.4203.1.9.1.2, а controlValue — строка октетов (OCTET STRING), содержащая syncStateValue, закодированное BER. criticality — FALSE.

syncStateValue ::= SEQUENCE {
    state ENUMERATED {
        present (0),
        add (1),
        modify (2),
        delete (3)
    },
    entryUUID syncUUID,
    cookie    syncCookie OPTIONAL
}

Элемент управления Sync State Control может применяться только для сообщений SearchResultEntry Message и SearchResultReference Message.

2.4. Sync Done Control

Sync Done Control — элемент управления [RFC4511], в котором controlType — идентификатор объекта 1.3.6.1.4.1.4203.1.9.1.3, а controlValue содержит syncDoneValue, закодированное BER. criticality — FALSE (и, следовательно, отсутствует).

syncDoneValue ::= SEQUENCE {
    cookie          syncCookie OPTIONAL,
    refreshDeletes  BOOLEAN DEFAULT FALSE
}

Элемент управления Sync Done Control может применяться только для сообщений SearchResultDone Message.

2.5. Sync Info Message

Sync Info Message — это промежуточное ответное сообщение LDAP (LDAP Intermediate Response Message) [RFC4511], в котором responseName — идентификатор объекта 1.3.6.1.4.1.4203.1.9.1.4, а responseValue содержит syncInfoValue, закодированное BER. criticality — FALSE (и, следовательно, отсутствует).

syncInfoValue ::= CHOICE {
    newcookie      [0] syncCookie,
    refreshDelete  [1] SEQUENCE {
        cookie         syncCookie OPTIONAL,
        refreshDone    BOOLEAN DEFAULT TRUE
    },
    refreshPresent [2] SEQUENCE {
        cookie         syncCookie OPTIONAL,
        refreshDone    BOOLEAN DEFAULT TRUE
    },
    syncIdSet      [3] SEQUENCE {
        cookie         syncCookie OPTIONAL,
        refreshDeletes BOOLEAN DEFAULT FALSE,
        syncUUIDs      SET OF syncUUID
    }
}

2.6. Результирующие коды Sync

Определены следующие LDAP resultCode [RFC4511]:

e-syncRefreshRequired (4096)

3. Синхронизация содержимого каталога

Операция Sync вызывается при посылке клиентом сообщения SearchRequest Message с элементом управления Sync Request Control.

Отсутствие куки, либо куки с состоянием инициализации синхронизации, указывает на то, что это запрос первоначального содержимого каталога, а наличие куки, представляющего собой состояние клиентской копии, указывает на то, что это запрос обновления содержимого каталога. Сессии синхронизации обсуждаются в разделе 3.1. Определение содержимого каталога обсуждается в разделе 3.2.

Режим — либо refreshOnly, либо refreshAndPersist. Режимы refreshOnly и refreshAndPersist обсуждаются, соответственно, в разделах 3.3 и 3.4. Режим refreshOnly состоит только из стадии обновления, а режим refreshAndPersist состоит из стадии обновления и следующей за ней стадии непрерывного обслуживания.

3.1. Сессия синхронизации

Последовательность операций Sync, в которой последнее куки, возвращённое сервером для одной операции, предоставляется клиентом в следующей операции, считается принадлежащей одной и той же сессии синхронизации.

Клиент должен (MUST) указывать одни и те же параметры управления содержимым каталога (смотрите раздел 3.5) в каждом поисковом запросе в рамках сессии. Клиенту следует (SHOULD) также выполнять каждый запрос Sync в рамках сессии с одними и теми же учётными данными аутентификации и авторизации, а также с эквивалентными параметрами целостности и защиты. Если сервер не распознает куки запроса, либо запрос выполняется с отличными учётными данными или неэквивалентными параметрами защиты, серверу нужно (SHALL) вернуть первоначальное содержимое каталога как в случае непредоставления куки, либо вернуть пустое содержимое с результирующим кодом LDAP e-syncRefreshRequired. Решение о том, возвращать ли первоначальное содержимое или пустое содержимое с результирующим кодом e-syncRefreshRequired, может (MAY) быть основано на reloadHint в элементе управления Sync Request Control, полученном от клиента. Если сервер распознает куки запроса как представляющее собой пустое состояние или состояние инициализации синхронизации клиентской копии, ему нужно (SHALL) вернуть первоначальное содержимое каталога.

Сессия синхронизации может охватывать несколько сессий LDAP между клиентом и сервером. Клиенту следует (SHOULD) выполнять каждый запрос Sync в рамках сессии к одному и тому же серверу. (Примечание: Соображения теневых копий обсуждаются в разделе 6).

3.2. Определение содержимого каталога

Предоставляемое содержимое каталога определяется параметрами поискового запроса, как это описано в [RFC4511], а также, возможно, другими элементами управления. В каждом запросе Sync в рамках сессии следует (SHOULD) использовать одни и те же параметры содержимого. Если запрашивается различное содержимое и сервер не желает или не может обработать запрос, серверу нужно (SHALL) вернуть первоначальное содержимое каталога как в случае, когда куки не было предоставлено, либо вернуть пустое содержимое с результирующим кодом LDAP e-syncRefreshRequired. Решение о том, возвращать ли первоначальное содержимое или пустое содержимое с результирующим кодом e-syncRefreshRequired, может (MAY) быть основано на reloadHint в элементе управления Sync Request Control, полученном от клиента.

Содержимое не обязательно должно включать в себя все записи и отсылки, которые были бы возвращены при нормальной операции поиска, а для тех записей, которые вошли в содержимое, не обязательно должны быть возвращены все атрибуты, которые были бы возвращены при нормальном поиске. Когда сервер не желает или не может предоставить синхронизацию какого-либо атрибута для набора записей, сервер должен (MUST) рассматривать все фильтры соответствия компонентов по этим атрибутам как неопределённые (Undefined) и не должен (MUST NOT) возвращать такие атрибуты в ответных сообщениях SearchResultEntry.

Серверам следует (SHOULD) поддерживать синхронизацию для всех неколлективных пользовательских атрибутов всех записей.

Сервер также может возвращать отсылки для продолжения операции на другие серверы или на самого себя. Последнее разрешено, поскольку сервер может разделять содержащиеся в нём записи в отдельные контексты синхронизации.

Клиент может воспользоваться всеми или некоторыми из этих продолжений операции, выполняя каждое их них как отдельную сессию синхронизации содержимого каталога.

3.3. Режим refreshOnly

Запрос Sync с режимом refreshOnly и без куки является запросом первоначального содержимого каталога. Запрос Sync с режимом refreshOnly и с куки, представляющим собой состояние синхронизации, является запросом обновлений содержимого каталога.

3.3.1. Запрос первоначального содержимого каталога

После получения такого запроса сервер предоставляет первоначальное содержимое каталога с помощью нуля или более сообщений SearchResultEntry Message и SearchResultReference Message, за которыми следует сообщение SearchResultDone Message.

Каждое сообщение SearchResultEntry Message должно (SHALL) включать элемент управления Sync State Control с состоянием add, entryUUID, содержащий UUID данной записи, и не включать куки. Каждое сообщение SearchResultReference Message должно (SHALL) включать элемент управления Sync State Control с состоянием add, entryUUID, содержащий UUID связанный с отсылкой (обычно это UUID связанного объекта именованной отсылки [RFC3296]), и не включать куки. Сообщение SearchResultDone Message должно (SHALL) включать элемент управления Sync Done Control, у которого refreshDeletes установлено в FALSE.

Значение success в resultCode указывает, что операция завершилась успешно. В противном случае результирующий код в этом поле указывает на характер сбоя. Сервер может вернуть результирующий код e-syncRefreshRequired на запрос первоначального содержимого каталога (если это можно сделать безопасным образом), когда он в силу различных причин не может выполнить операцию. Установка reloadHint в FALSE в сообщении SearchRequest Message говорит о том, что это запрос первоначального содержимого каталога.

Если операция завершена успешно, следует (SHOULD) вернуть куки, представляющее собой состояние синхронизации текущей клиентской копии, для использования в последующих операциях Sync.

3.3.2. Запрос обновлений содержимого каталога

После получения такого запроса сервер предоставляет обновление содержимого каталога с помощью нуля или более сообщений SearchResultEntry Message и SearchResultReference Message, за которыми следует сообщение SearchResultDone Message.

От сервера требуется (REQUIRED):

  1. предоставить последовательность сообщений, необходимых для конечной конвергенции клиентской копии содержимого каталога к серверной копии,

  2. рассматривать данный запрос как запрос первоначального содержимого каталога (то есть игнорировать куки или состояние синхронизации, представляемое в этом куки),

  3. показать, что инкрементная конвергенция невозможна, путём возврата e-syncRefreshRequired,

  4. возвращать resultCode, отличный от успешного или e-syncRefreshRequired.

Операция Sync может состоять из отдельной фазы наличия, отдельной фазы удаления, либо из фазы наличия, за которой следует фаза удаления.

В обоих фазах для каждой записи или отсылки, добавленной в содержимое или изменённой с момента указанной в куки предыдущей операции Sync, сервер возвращает сообщения SearchResultEntry Message или SearchResultReference Message соответственно, каждое с элементом управления Sync State Control, в котором присутствуют состояние add, entryUUID, содержащий UUID записи или отсылки, и не присутствует куки. Каждое сообщение SearchResultEntry Message представляет собой текущее состояние изменённой записи. Каждое сообщение SearchResultReference Message представляет собой текущее состояние изменённой отсылки.

В фазе наличия для каждой записи, которая не была изменена с момента предыдущей операции Sync, возвращается пустое сообщение SearchResultEntry, в котором поле objectName отражает текущий DN записи, поле attributes пусто, а в элементе управления Sync State Control присутствует состояние present, entryUUID, содержащий UUID записи, и не присутствует куки. Для каждой отсылки, которая не была изменена с момента предыдущей операции Sync, возвращается пустое сообщение SearchResultReference, содержащее пустую последовательность LDAPURL (SEQUENCE OF LDAPURL), с элементом управления Sync State Control, в котором присутствуют состояние present, entryUUID, содержащий UUID записи, и не присутствует куки. Для записей и отсылок, не присутствующих более в содержимом каталога, никаких сообщений не отправляется.

Несколько пустых записей с элементом управления Sync State Control с состоянием present следует (SHOULD) объединять в одно или несколько сообщений Sync Info Messages со значением syncIdSet, в котором поле refreshDeletes установлено в FALSE. Поле syncUUIDs содержит набор UUID записей и отсылок, неизменённых с момента последней операции Sync. Поле syncUUIDs может быть пустым. Сообщение Sync Info Message со значением syncIdSet может содержать куки, представляющее собой состояние содержимого каталога после выполнения синхронизации записей, входящих в данный набор.

В фазе удаления для каждой записи, которой больше нет в содержимом каталога, сервер возвращает сообщение SearchResultEntry, в котором поле objectName отражает бывший DN записи или является пустым, поле attributes пусто, а в элементе управления Sync State Control присутствует состояние delete, entryUUID, содержащий UUID удалённой записи, и не присутствует куки. Для каждой отсылки, которой больше нет в содержимом каталога, возвращается сообщение SearchResultReference, содержащее пустую последовательность LDAPURL (SEQUENCE OF LDAPURL), с элементом управления Sync State Control, в котором присутствуют состояние delete, entryUUID, содержащий UUID удалённой записи, и не присутствует куки.

Несколько пустых записей с элементом управления Sync State Control с состоянием delete следует (SHOULD) объединять в одно или несколько сообщений Sync Info Messages со значением syncIdSet, в котором поле refreshDeletes установлено в TRUE. Поле syncUUIDs содержит набор UUID записей и отсылок, которые были удалены из содержимого каталога с момента последней операции Sync. Поле syncUUIDs может быть пустым. Сообщение Sync Info Message со значением syncIdSet может содержать куки, представляющее собой состояние содержимого каталога после выполнения синхронизации записей, входящих в данный набор.

Когда за фазой наличия следует фаза удаления, эти две фазы разделяются сообщением Sync Info Message, содержащим значение syncInfoValue, установленное в refreshPresent, в которое может входить куки, представляющее собой состояние каталога после выполнения фазы наличия. Данное значение refreshPresent содержит поле refreshDone, которое в режиме refreshOnly операции Sync всегда установлено в FALSE, поскольку за этим сообщением следует фаза удаления.

Если операция Sync состоит только из одной фазы, эта фаза (какая бы она ни была) и, следовательно, операция Sync в целом помечается как оконченная посылкой сообщения SearchResultDone Message с элементом управления Sync Done Control, которому следует (SHOULD) содержать куки, представляющее собой состояние каталога после выполнения данной операции Sync. Этот элемент управления Sync Done Control содержит поле refreshDeletes, установленное в FALSE для фазы наличия и в TRUE для фазы удаления.

Если операция Sync состоит из фазы наличия, за которой следует фаза удаления, такая операция Sync помечается как оконченная по завершении фазы удаления посылкой сообщения SearchResultDone Message с элементом управления Sync Done Control, которому следует (SHOULD) содержать куки, представляющее собой состояние каталога после выполнения данной операции Sync. Этот элемент управления Sync Done Control содержит поле refreshDeletes, установленное в TRUE.

Клиент может указать, что он предпочитает получить первоначальное содержимое каталога (путём установки поля reloadHint в TRUE), либо получить результирующий код (resultCode) e-syncRefreshRequired (путём установки поля reloadHint в FALSE, и, следовательно, при его отсутствии), в случае, если сервер решит, что достижение конечной конвергенции путём продолжения текущего потока инкрементной синхронизации невозможно или неэффективно.

Значение success результирующего кода (resultCode) говорит о том, что данная операция завершилась успешно. Значение e-syncRefreshRequired результирующего кода (resultCode) говорит о том, что необходимо полное или частичное обновление. В остальных случаях результирующий код указывает на характер сбоя. В элементе управления Sync Done Control предоставляется куки, используемое в последующих операциях Sync для инкрементной синхронизации.

3.4. Режим refreshAndPersist

Запрос Sync с режимом refreshAndPersist представляет собой запрос первоначального содержимого каталога, либо запрос обновления каталога (во время стадии обновления), за которым следует посылка уведомлений об изменениях (во время стадии непрерывного обслуживания).

3.4.1. Стадия обновления (refresh Stage)

Обновление содержимого каталога предоставляется также, как описано в разделе 3.3, за исключением того, что на успешное завершение обновления содержимого указывает отправка сообщения Sync Info Message с одной из двух последовательностей refreshDelete или refreshPresent, в которых значение refreshDone установлено в TRUE, вместо сообщения SearchResultDone Message с результирующим кодом success. В этом сообщении Sync Info Message следует (SHOULD) вернуть куки, представляющее собой состояние содержимого каталога после окончания стадии обновления операции Sync.

3.4.2. Стадия непрерывного обслуживания (persist Stage)

Уведомления об изменениях предоставляются во время стадии непрерывного обслуживания.

При внесении изменений в DIT, сервер уведомляет клиента об изменении содержимого каталога. Изменения DIT могут быть вызваны тем, что записи и отсылки были добавлены в содержимое, удалены из содержимого, либо модифицированы в содержимом каталога. Изменения DIT могут быть также вызваны тем, что отсылки были добавлены, удалены или модифицированы в содержимом каталога.

Если изменения DIT вызваны тем, что запись была добавлена в содержимое каталога, сервер выдаёт сообщение SearchResultEntry Message, представляющее собой эту запись в том виде, в котором она представлена в содержимом каталога. Сообщение должно (SHALL) включать в себя элемент управления Sync State Control с состоянием add, entryUUID, содержащим UUID данной записи, и необязательным куки.

Если изменения DIT вызваны тем, что отсылка была добавлена в содержимое каталога, сервер выдаёт сообщение SearchResultReference Message, представляющее собой эту отсылку в содержимом каталога. Сообщение должно (SHALL) включать в себя элемент управления Sync State Control с состоянием add, entryUUID, содержащим ассоциированный с данной отсылкой UUID, и необязательным куки.

Если изменения DIT вызваны тем, что запись была модифицирована в содержимом каталога, сервер выдаёт сообщение SearchResultEntry Message, представляющее собой эту запись в том виде, в котором она представлена в содержимом каталога. Сообщение должно (SHALL) включать в себя элемент управления Sync State Control с состоянием modify, entryUUID, содержащим UUID данной записи, и необязательным куки.

Если изменения DIT вызваны тем, что отсылка была модифицирована в содержимом каталога, сервер выдаёт сообщение SearchResultReference Message представляющее собой эту отсылку в содержимом каталога. Сообщение должно (SHALL) включать в себя элемент управления Sync State Control с состоянием modify, entryUUID, содержащим ассоциированный с данной отсылкой UUID, и необязательным куки.

Если изменения DIT вызваны тем, что запись была удалена из содержимого каталога, сервер выдаёт сообщение SearchResultEntry Message без атрибутов. Сообщение должно (SHALL) включать в себя элемент управления Sync State Control с состоянием delete, entryUUID, содержащим UUID данной записи, и необязательным куки.

Если изменения DIT вызваны тем, что отсылка была удалена из содержимого каталога, сервер выдаёт сообщение SearchResultReference Message с пустой последовательностью LDAPURL (SEQUENCE OF LDAPURL). Сообщение должно (SHALL) включать в себя элемент управления Sync State Control с состоянием delete, entryUUID, содержащим ассоциированный с данной отсылкой UUID, и необязательным куки.

Несколько пустых записей с элементом управления Sync State Control с состоянием delete следует (SHOULD) объединять в одно или несколько сообщений Sync Info Message со значением syncIdSet, в котором поле refreshDeletes установлено в TRUE. Поле syncUUIDs содержит набор UUID записей и отсылок, которые были удалены из содержимого каталога. Сообщение Sync Info Message со значением syncIdSet может содержать куки, представляющее собой состояние содержимого каталога после выполнения синхронизации записей, входящих в данный набор.

С каждым из этих сообщений сервер может предоставить новое куки для использования в последующих операциях Sync. Кроме того, сервер также может возвращать сообщения Sync Info Message типа newCookie для предоставления нового куки. Клиенту следует (SHOULD) использовать самое новое (последнее) полученное им от сервера куки в последующих операциях Sync.

3.5. Параметры поискового запроса

Как отмечалось в разделе 3.1, клиенту следует (SHOULD) указывать одни и те же параметры управления содержимым каталога в каждом поисковом запросе в рамках сессии. Все поля сообщения SearchRequest Message, за исключением sizeLimit и timeLimit, считаются параметрами управления содержимым каталога.

3.5.1. baseObject

Как и в случае нормальной операции поиска, стадии обновления и непрерывного обслуживания не изолированы от изменений DIT. Возможно, что запись, на которую ссылается baseObject, удалена, переименована или перемещена. Возможно также, объект-псевдоним, используемый для нахождения записи, на которую ссылается baseObject изменился таким образом, что baseObject ссылается на другую запись.

Если во время выполнения операции Sync DIT было обновлено таким образом, что baseObject больше не ссылается на какую-либо запись, либо таким образом, что изменилась запись, на которую ссылается baseObject, серверу нужно (SHALL) вернуть соответствующий неуспешный результирующий код, такой как noSuchObject, aliasProblem, aliasDereferencingProblem, referral или e-syncRefreshRequired.

3.5.2. derefAliases

Данная операция не поддерживает разрешение псевдонимов во время поиска. Клиенту нужно (SHALL) указывать neverDerefAliases или derefFindingBaseObj для параметра derefAliases в SearchRequest. Серверу нужно (SHALL) рассматривать другие значения (такие как derefInSearching, derefAlways) как ошибки протокола.

3.5.3. sizeLimit

sizeLimit применяется только к записям (независимо от их состояния с элементе управления Sync State Control), возвращаемым во время операции в режиме refreshOnly или стадии обновления операции в режиме refreshAndPersist.

3.5.4. timeLimit

Для операции Sync в режиме refreshOnly timeLimit применяется ко всей операции. Для операции в режиме refreshAndPersist timeLimit применяется только к стадии обновления, включая генерацию сообщения Sync Info Message со значением refreshDone, установленным в TRUE.

3.5.5. filter

Клиенту следует (SHOULD) избегать определения фильтров, которые применяются к значениям атрибутов, поскольку вероятнее всего они будут рассматриваться сервером как атрибуты, содержащие мета-информацию. Смотрите раздел 4.

3.6. objectName

Операция Sync использует значения entryUUID, предоставляемые в элементе управления Sync State Control, в качестве первичных ключей для записей. Клиент должен (MUST) использовать эти entryUUID для сопоставления сообщений синхронизации.

В некоторых случаях возвращаемый DN может не отражать текущего DN записи. В частности, когда запись удаляется из содержимого каталога, сервер может предоставить пустое DN, если он не желает раскрывать текущее DN записи (или, при удалении из DIT, последнее DN записи).

Также имейте в виду, что DN записи может рассматриваться как мета-информация (смотрите раздел 4.1).

3.7. Отмена операции Sync

Серверы должны (MUST) реализовывать операцию отмены LDAP (LDAP Cancel Operation) [RFC3909] и поддерживать отмену незавершившихся операций Sync согласно приведённому описанию.

Для отмены незавершившейся операции Sync клиент вызывает операцию отмены LDAP [RFC3909].

Если в какой-то момент времени сервер приходит в состояние, когда он не желает или не может продолжать обработку операции Sync, ему нужно (SHALL) вернуть сообщение SearchResultDone с неуспешным результирующим кодом resultCode, указывающим причину прекращения данной операции.

Кем бы ни было инициировано такое прекращение операции (клиентом или сервером), сервер может предоставить в элементе управления Sync Done Control куки для использования в последующих операциях Sync.

3.8. Требование выполнения обновления

Для того, чтобы добиться синхронизации с конечной конвергенцией (схождением), сервер может прервать данную операцию Sync в стадии обновления или непрерывного обслуживания путём возврата клиенту результирующего кода e-syncRefreshRequired. Если при этом не было предоставлено куки, требуется полное обновление содержимого каталога. Если в этом ответе было предоставлено куки, представляющее собой состояние синхронизации, требуется инкрементное обновление содержимого каталога.

Для получения полного обновления клиент выдает новый запрос синхронизации без куки. Для получения инкрементного обновления клиент выдает новый запрос синхронизации с предоставленным ему куки.

В целях обеспечения конечной конвергенции сервер может избрать предоставление полной копии на стадии обновления (то есть проигнорировать куки или состояние синхронизации, представленное в куки) вместо предоставления инкрементного обновления.

Выбор между возвратом первоначального содержимого каталога и возвратом результирующего кода e-syncRefreshRequired может основываться на поле reloadHint в элементе управления Sync Request Control, полученном от клиента.

Если операция Sync находится в стадии непрерывного обслуживания, сервер возвращает результирующий код e-syncRefreshRequired чтобы указать, что клиенту необходимо выполнить новую операцию Sync для получения синхронизированной копии содержимого каталога. Если при этом не было предоставлено куки, требуется полное обновление содержимого каталога. Если в этом ответе было предоставлено куки, представляющее собой состояние синхронизации, требуется инкрементное обновление содержимого каталога.

Сервер также может вернуть e-syncRefreshRequired, если он определил, что обновление будет более эффективно, чем отправка всех сообщений, требуемых для конвергенции.

Имейте ввиду, что клиент может получить одно или несколько сообщений SearchResultEntry Message, SearchResultReference Message и/или Sync Info Message перед тем, как он получит сообщение SearchResultDone Message с результирующим кодом e-syncRefreshRequired.

3.9. Соображения уменьшения трафика

Сервер должен (MUST) обеспечить, чтобы количество сообщений, генерируемых для обновления содержимого каталога клиента, не превышало количества записей, находящихся в этом содержимом. Хотя для серверов не выдвигается никаких требований по поддержанию информации об истории изменений, если на сервере имеется история изменений в объёме, достаточном для того, чтобы позволить ему достоверно определить, какие записи из предыдущей клиентской копии не присутствуют больше в содержимом каталога, и если количество таких записей меньше или равно количеству неизменённых записей, серверу следует (SHOULD) генерировать сообщения об удалении записей вместо сообщений о наличии записей (смотрите раздел 3.3.2).

Когда количества поддерживаемой на сервере информации об истории изменений недостаточно для обслуживания клиентов, которые редко выполняют операцию Sync в режиме refreshOnly, вполне вероятно, что к моменту повторного подключения таких клиентов у данного сервера будет неполная информация об истории изменений (например, в связи с её усечением).

Серверу не следует (SHOULD NOT) прибегать к полной перезагрузке, если информации об истории изменений недостаточно для генерации сообщений об удалении записей. Для приведения клиентской копии в текущее состояние серверу следует (SHOULD) генерировать либо только сообщения о наличии записей, либо сообщения о наличии записей, за которыми следуют сообщения об удалении записей. В последнем случае сообщения о наличии записей приводят клиентскую копию в состояние, покрываемое хранящейся на сервере информацией об истории изменений.

Серверу следует (SHOULD) поддерживать информацию (текущую или историческую) о состоянии, такую как отметка времени последнего изменения содержимого каталога в целом, достаточную для того, чтобы определить, что с момента предоставления обновления содержимого каталога не было сделано никаких изменений в этом содержимом, и, если изменений не было сделано, генерировать ноль сообщений об удалении записей вместо сообщений о наличии записей.

Серверу не следует (SHOULD NOT) использовать информацию об истории изменений, если её использование не уменьшает количества трафика синхронизации или если её использование может привести к раскрытию конфиденциальной информации, которую не разрешено получать клиенту.

Тем, кто занимается разработкой сервера, следует также рассмотреть вопросы уменьшения трафика, охватывающие несколько операций Sync в рамках сессии. Как сказано в разделе 3.8, сервер может вернуть e-syncRefreshRequired если он определил, что перезагрузка будет более эффективна, чем продолжение посылки обновлений в рамках текущей операции. Если поле reloadHint в элементе управления Sync Request установленов в TRUE, сервер может инициировать перезагрузку, не давая клиенту указания запросить перезагрузку.

Серверу следует (SHOULD) передавать новое куки достаточно часто, чтобы избежать передачи уже предоставленной клиенту информации. Даже когда изменения DIT не приводят к передаче сведений по синхронизации содержимого каталога, может быть полезно предоставить новое куки с помощью сообщения Sync Info Message. Однако серверу следует (SHOULD) избегать перегрузки клиента или сети сообщениями Sync Info Message.

Во время стадии непрерывного обслуживания серверу следует (SHOULD) объединять несколько исходящих сообщений с изменениями одной и той же записи. Сервер может (MAY) задержать генерацию сообщения об обновлении записи в ожидании последующих изменений той же записи, которые можно будет объединить. Длительность задержки должна быть достаточно большой, чтобы объединить запросы на обновления, следующие один за другим, но и не слишком большой, чтобы временные расхождения, вызванные такой задержкой, своевременно корректировались.

Для уменьшения количества трафика синхронизации серверу следует (SHOULD) использовать сообщения Sync Info Message с syncIdSet при наличии нескольких сообщений удаления или наличия.

Также имейте ввиду, что может быть много клиентов, заинтересованных в получении какого-либо конкретного изменения каталога, и попытка сервера обслужить сразу всех таких клиентов может вызвать перегрузку в сети. Вопросы перегрузки становятся ещё более острыми, когда изменение требует передачи большого объёма данных каждому заинтересованному клиенту. Те, кто занимается разработкой, а также развёртыванием серверов, должны предпринимать шаги для предотвращения сетевых перегрузок и управления ими.

3.10. Объединение (мультиплексирование) операций

Модель протокола LDAP [RFC4511] позволяет объединять операции в рамках одной сессии LDAP. Клиентам не следует (SHOULD NOT) поддерживать несколько сессий LDAP с одним и тем же сервером. Серверам следует (SHOULD) обеспечить, чтобы ответы от одновременно обрабатываемых операций справедливо чередовались.

Клиентам следует (SHOULD) объединять операции Sync, наборы результатов которых в значительной степени перекрывают друг друга. Это позволяет избежать необходимости возвращать несколько сообщений, по одному для каждой перекрывающейся сессии, для внесения изменений в записи, попадающие в такое перекрытие.

Клиентам не следует (SHOULD NOT) объединять операции Sync, наборы результатов которых в значительной степени не перекрывают друг друга. Такой подход гарантирует, что распространение действий событий, требующих возвращения ответа e-syncRefreshRequired, можно будет ограничить на минимально возможное число наборов результатов.

4. О мета-информации

4.1. DN записи

Так как DN записи строится из его относительного DN (RDN) и DN родительской записи, оно часто рассматривается как мета-информация.

Несмотря на то, что переименование записи или перемещение её к новой вышестоящей записи приводит к изменению DN записи, само по себе такое изменение не должно (SHOULD NOT) приводить к посылке синхронизационных сообщений для этой записи. Однако, когда переименование или перемещение записи может послужить причиной добавления или удаления записи из содержимого каталога, соответствующие синхронизационные сообщения должны быть сгенерированы, чтобы указать на это клиенту.

Когда сервер рассматривает DN записи как мета-информацию, ему нужно (SHALL):

  • либо считать, что все MatchingRuleAssertion [RFC4511] установлены в TRUE, если найдено совпадение со значением какого-либо атрибута из записи; в противном случае считать, что все они установлены в Undefined,

  • либо считать все MatchingRuleAssertion с dnAttributes, установленным TRUE, как Undefined.

Последний вариант предложен для удобства реализации сервера.

4.2. Операционные атрибуты

Там, где значения операционного атрибута определяются значениями, не являющимися частью той же записи, в которой он присутствует, данному операционному атрибуту не следует (SHOULD NOT) поддерживать синхронизацию тех (то есть внешних) операционных атрибутов.

Например, на серверах, реализующих модель subschema X.501 [X.501], серверам не следует поддерживать синхронизацию атрибута subschemaSubentry, поскольку его значение определяется значениями, содержащимися и администрируемыми в подзаписях subschema.

В качестве контрпримера, серверы, реализующие псевдонимы [RFC4512][X.501], могут поддерживать синхронизацию атрибута aliasedObjectName, поскольку его значения содержатся и администрируются как часть записей-псевдонимов.

Серверам следует (SHOULD) поддерживать синхронизацию следующих операционных атрибутов: createTimestamp, modifyTimestamp, creatorsName, modifiersName [RFC4512]. Серверы могут (MAY) поддерживать синхронизацию других операционных атрибутов.

4.3. Коллективные атрибуты

Коллективный атрибут — это "пользовательский атрибут, чьи значения одинаковы для каждого члена коллекции записей" [X.501]. Использование коллективных атрибутов в LDAP обсуждается в [RFC3671].

Модификация коллективного атрибута, как правило, влияет на содержимое нескольких записей, являющихся членами коллекции. Неэффективно включать в область видимости значения коллективных атрибутов в записях коллекции, поскольку одна модификация коллективного атрибута требует передачи нескольких сообщений SearchResultEntry (по одному для каждой записи из коллекции, подвергнувшейся модификации).

Серверам не следует (SHOULD NOT) синхронизировать коллективные атрибуты, фигурирующие в записях какой-либо коллекции. Серверы могут (MAY) поддерживать синхронизацию коллективных атрибутов, фигурирующих в подзаписях коллективных атрибутов.

4.4. Контроль доступа и другие виды административного контроля

Обычно записи подвергаются контролю доступа и другим видам административного контроля. Часть информации о том, будет ли политика распространяться на конкретную запись, может содержаться в самой записи, но часто информация о политике содержится в других местах (в вышестоящих записях, в подзаписях, в записи root DSE, в конфигурационных файлах, и т.д.). Поэтому изменения информации о политике создают трудности в достижении конечной конвергенции во время инкрементной синхронизации.

Там, где непрактично или неосуществимо генерировать изменения содержимого каталога, произошедшие в результате изменения информации о политике, серверы могут вернуть результирующий код e-syncRefreshRequired, или рассматривать операцию Sync как запрос первоначального содержимого каталога (то есть проигнорировать куки или состояние синхронизации, представленное в этом куки).

5. Интеграция с другими элементами управления

Операция Sync может быть использована с:

  • элементом управления ManageDsaIT Control [RFC3296]

  • элементом управления Subentries Control [RFC3672]

как описано ниже. Операция Sync может быть использована с другими расширениями LDAP, как описано в других документах.

5.1. Элемент управления ManageDsaIT Control

Элемент управления ManageDsaIT Control [RFC3296] указывает, что операция выполняется над данным DSA Information Tree, и потому, по отношению к этой операции, отсылки и другие специальные записи следует рассматривать как записи-объекты.

5.2. Элемент управления Subentries Control

Элемент управления Subentries Control используется с операцией поиска "для управления видимостью записей и подзаписей, попадающих в поисковый диапазон" [RFC3672]. При использовании с операцией Sync, элемент управления Subentries и другие факторы (диапазон поиска, фильтр и т.п.) используются для определения того, входит ли запись или подзапись в синхронизируемое содержимое каталога.

6. О теневых каталогах

Как сказано в [RFC4511], некоторые серверы могут содержать теневые копии записей, которые могут использоваться для выдачи ответов на поисковые запросы и запросы сравнения. Такие серверы могут также поддерживать запросы синхронизации содержимого каталога. В этом разделе обсуждаются соображения для тех, кто занимается реализацией и развёртыванием операции Sync в теневых каталогах.

Даже если клиент знает о существовании нескольких серверов, которые в равной степени могут быть использованы для получения содержимого определённого каталога, клиенту не следует (SHOULD NOT) считать, что каждый из таких серверов в равной степени способен продолжить сессию синхронизации содержимого каталога. Как указано в разделе 3.1, клиенту следует (SHOULD) выполнять каждый запрос Sync в рамках сессии Sync к одному и тому же серверу.

Однако, посредством перенаправления доменных имён или IP-адресов, либо используя другие техники, несколько физических серверов могут быть представлены клиенту как один логический сервер. Только серверы, которые в равной степени способны поддерживать операцию Sync и содержать одинаково полные копии записей, должны получать возможность выступать как один логический сервер. В частности, каждому физическому серверу из тех, что выступают как один логический сервер, следует (SHOULD) быть в равной степени способным продолжить синхронизацию содержимого каталога на основании куки, предоставленного любым другим из этих физических серверов без необходимости полной перезагрузки. Поскольку стандартного механизма поддержания теневых копий каталогов LDAP не существует, спецификация того, как самостоятельно реализовать серверы, в равной степени способные поддерживать синхронизацию (так же как и точное определение термина "в равной степени способные") оставлены для рассмотрения в будущих документах.

Имейте в виду, что серверу может быть не легко достоверно определить, какое содержимое каталога было предоставлено клиенту другим сервером, особенно в теневых средах, где разрешено объединение теневых событий. Для таких серверов может быть неприемлемым использование фазы удаления, обсуждаемой в разделе 3.3.2.

7. О безопасности

В целях поддержания синхронизированной копии содержимого каталога, клиент, как описано выше, производит удаление информации из своей копии содержимого каталога. Однако, клиент может хранить сведения, полученные из предоставленной ему сервером информации, отдельно от своей копии содержимого каталога, используемой для синхронизации. Управление подобным хранилищем сведений выходит за рамки данного документа. Серверы должны соблюдать осторожность, чтобы не раскрывать информацию из содержимого каталога и/или об этом содержимом клиентам, не авторизованным на получение таких сведений.

Если информация, предоставляемая серией операций Sync в режиме refreshOnly, аналогична той, что предоставляется серией операций поиска, то в стадии непрерывного обслуживания может быть раскрыта дополнительная информация. Клиент получает возможность различить информацию о конкретной последовательности операций обновления, вызвавших изменение содержимого каталога.

Тем, кто занимается реализацией, следует принимать меры предосторожности против злонамеренного содержимого куки, в том числе плохо сформированных куки или надлежаще сформированных куки, используемых с различного рода ассоциациями безопасности и/или пропусками, посредством которых производится попытка получения неавторизованного доступа к информации. Для выявления фальсификации серверы могут включать в куки цифровые подписи.

Операция Sync может быть объектом прямых атак типа "отказ от обслуживания". Тем, кто занимается реализацией, следует принимать меры защиты для обеспечения того, чтобы не было злоупотреблений этой операцией. Серверы могут внедрять контроль доступа и другие ограничения на использование этой операции.

Имейте ввиду, что даже небольшое обновление в каталоге может вызвать генерацию значительного количества трафика для клиентов, использующих эту операцию. Пользователь может злоупотреблять своими привилегиями на обновление для организации косвенного отказа от обслуживания этих клиентов, других клиентов, и/или участков сети. Серверу следует предусматривать меры защиты для обеспечения того, чтобы не было злоупотреблений операциями обновления.

Тем, кто занимается реализацией этого (или любого другого) расширения LDAP, следует иметь ввиду общие соображения безопасности LDAP [RFC4510].

8. Регистрация в IANA

IANA осуществила регистрацию описанных ниже значений [RFC4520].

8.1. Идентификатор объекта

Для использования в данной спецификации OpenLDAP Foundation назначил [ASSIGN] ответвление OID 1.3.6.1.4.1.4203.1.9.1 из выделенного ему IANA пространства частного предприятия [PRIVATE].

8.2. Механизм протокола LDAP

IANA зарегистрировала описанный в данном документе механизм протокола LDAP.

Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: 1.3.6.1.4.1.4203.1.9.1.1
Description: LDAP Content Synchronization Control
Person & email address to contact for further information: Kurt Zeilenga <[email protected]
>
Usage: Control
Specification: RFC 4533
Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi
Comments: none

8.3. Результирующие коды LDAP

IANA зарегистрировала описанный в данном документе результирующий код LDAP.

Subject: LDAP Result Code Registration
Person & email address to contact for further information: Kurt Zeilenga <[email protected]
>
Result Code Name: e-syncRefreshRequired (4096)
Specification: RFC 4533
Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi
Comments: none

9. Благодарности

В данном документе многое позаимствовано из протокола обновления клиента LDAP (LDAP Client Update Protocol [RFC3928]), который является детищем рабочей группы LDUP IETF. Данный документ также извлёк некоторую пользу из работ Persistent Search [PSEARCH], Triggered Search [TSEARCH] и Directory Synchronization [DIRSYNC]. Также кое-что в этом документе было позаимствовано из "Lightweight Directory Access Protocol (v3)" [RFC2251].

10. Нормативные документы

[RFC2119] Bradner, S., «Ключевые слова для обозначения уровня требований в RFC», BCP 14, RFC 2119, март 1997 г.
[RFC3296] Zeilenga, K., «Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories», RFC 3296, июль 2002 г.
[RFC3671] Zeilenga, K., «Collective Attributes in the Lightweight Directory Access Protocol (LDAP)», RFC 3671, декабрь 2003 г.
[RFC3672] Zeilenga, K., «Subentries in the Lightweight Directory Access Protocol (LDAP)», RFC 3672, декабрь 2003 г.
[RFC3909] Zeilenga, K., «Lightweight Directory Access Protocol (LDAP) Cancel Operation», RFC 3909, октябрь 2004 г.
[RFC4510] Zeilenga, K., Ed., «Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map», RFC 4510, июнь 2006 г.
[RFC4511] Под редакцией Sermersheim, J., «LDAP: Определение протокола», RFC 4511, июнь 2006 г.
[RFC4512] Zeilenga, K., «Lightweight Directory Access Protocol (LDAP): Directory Information Models», RFC 4512, июнь 2006 г.
[RFC4530] Zeilenga, K., «Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute», RFC 4530, июнь 2006 г.
[UUID] International Organization for Standardization (ISO), «Information technology — Open Systems Interconnection — Remote Procedure Call», ISO/IEC 11578:1996
[X.501] International Telecommunication Union — Telecommunication Standardization Sector, «The Directory — Models», X.501(1993) (also ISO/IEC 9594-2:1994).
[X.680] International Telecommunication Union — Telecommunication Standardization Sector, «Abstract Syntax Notation One (ASN.1) — Specification of Basic Notation», X.680(1997) (also ISO/IEC 8824-1:1998).
[X.690] International Telecommunication Union — Telecommunication Standardization Sector, «Specification of ASN.1 encoding rules: Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER)», X.690(1997) (also ISO/IEC 8825-1:1998).

11. Информативные документы

[RFC2251] Wahl, M., Howes, T. и S. Kille, «Lightweight Directory Access Protocol (v3)», RFC 2251, декабрь 1997.
[RFC3928] Megginson, R., Ed., Smith, M., Natkovich, O. и J. Parham, «Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP)», RFC 3928, октябрь 2004.
[RFC4520] Zeilenga, K., «Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)», BCP 64, RFC 4520, июнь 2006.
[PRIVATE] IANA, «Private Enterprise Numbers», http://www.iana.org/assignments/enterprise-numbers.
[ASSIGN] OpenLDAP Foundation, «OpenLDAP OID Delegations», http://www.openldap.org/foundation/oid-delegate.txt.
[X.500] International Telecommunication Union — Telecommunication Standardization Sector, «The Directory — Overview of concepts, models and services», X.500(1993) (also ISO/IEC 9594-1:1994).
[X.525] International Telecommunication Union — Telecommunication Standardization Sector, «The Directory: Replication», X.525(1993).
[DIRSYNC] Armijo, M., «Microsoft LDAP Control for Directory Synchronization».
[PSEARCH] Smith, M., et al., «Persistent Search: A Simple LDAP Change Notification Mechanism», работы продолжаются.
[TSEARCH] Wahl, M., «LDAPv3 Triggered Search Control», работы продолжаются.

Приложение A. Соображения по реализациям, основанным на CSN

Данное приложение приводится сугубо в информационных целях; оно не является нормативной частью технической спецификации операции синхронизации содержимого каталога LDAP.

В данном приложении обсуждаются соображения по реализации операции синхронизации содержимого каталога LDAP на сервере, связанные с методами, основанными на порядковом номере изменения (Change Sequence Number, CSN).

Методы, основанные на порядковом номере изменения, предназначены для использования на серверах, которые не ведут информацию об истории изменений, произведённых в каталоге (например, журналы изменений, снимки состояния), и, следовательно, должны опираться на текущее состояние каталога и минимальную информацию о состоянии синхронизации, полученную из Sync-куки. Серверам, поддерживающим информацию об истории изменений, следует рассматривать другие методы, использующие эту информацию об истории.

Порядковый номер изменения фактически является отметкой времени, которая имеет достаточную детализацию для того, чтобы точно определить взаимоотношения первенства по времени между двумя обновлениями одного и того же объекта. Порядковые номера изменения не следует путать с порядковыми номерами подтверждения (Commit Sequence Number) или номерами записей журнала подтверждений (Commit Log Record Number). Порядковый номер подтверждения позволяет определить каким образом два подтверждения изменения (одного и того же или разных объектов) соотносятся друг с другом по времени. Порядок подтверждения изменений различных записей может отличаться от ассоциированных с этими записями порядковых номеров изменений. Далее в этом приложении под термином CSN подразумевается порядковый номер изменения (Change Sequence Number).

В рассматриваемых методах сервер поддерживает не только CSN для каждой записи каталога (entry CSN), но также и значение, которое мы называем CSN контекста (context CSN). CSN контекста — это наибольший зафиксированный CSN записи, не превосходящий любой из остающихся неразрешёнными (неподтверждёнными) CSN записей, для всех записей в контексте каталога. Значение CSN контекста используется в значениях syncCookie в качестве индикатора состояния синхронизации.

Операции поиска не изолированы от отдельных операций обновления каталога. Также нельзя предполагать, что отдельные операции обновления будут производиться с какой-либо закономерностью. Поэтому нельзя считать, что возвращаемое содержимое включает в себя все соответствующие изменения, порядковый номер изменения которых меньше или равен наибольшему CSN записи в контексте. Содержимое включает в себя все соответствующие изменения, чей порядковый номер изменения меньше или равен CSN контекста перед началом процесса поиска. Содержимое также может включать в себя любое подмножество изменений, чей порядковый номер изменения больше CSN контекста перед началом процесса поиска, но меньше или равен CSN контекста по окончании процесса поиска. Содержимое не включает в себя каких-либо изменений, CSN которых больше чем CSN контекста по окончании процесса поиска.

Простая реализация сервера может использовать для индикации состояния значение CSN контекста перед началом процесса поиска. Подобная реализация будет встраивать это значение во все возвращаемые SyncCookie. Мы будем называть это CSN куки. При запросе обновления сервер будет просто генерировать сообщения об изменении для всех записей в содержимом каталога, чьи CSN больше чем предоставленный CSN куки, а также генерировать сообщения о наличии для всех остальных записей в содержимом каталога. Однако, если текущий CSN контекста совпадает с CSN куки, серверу следует вместо этого генерировать ноль сообщений об изменении и ноль сообщений об удалении, а также установить индикатор refreshDeletes в TRUE, поскольку каталог не был изменён.

В реализации должно также учитываться влияние изменения мета-информации, способной воздействовать на то, как будет определяться содержимое каталога, например, контроля доступа. Один из методов состоит в том, чтобы сервер поддерживал CSN мета-информации, распространяющей влияние на контекст в целом, или CSN мета-информации. Этот CSN мета-информации будет обновляться тогда, когда изменяется мета-информация, воздействующая на то, каким образом будет определяться содержимое каталога. Если значение такого CSN мета-информации больше чем CSN куки, серверу следует проигнорировать куки и рассматривать запрос как запрос первоначального содержимого каталога.

Кроме того, серверы могут рассмотреть вопрос поддержания некоторой информации об истории изменений отдельно для каждой сессии, чтобы уменьшить количество сообщений, которые требуется передать в ходе инкрементных обновлений. В частности, сервер может сохранять информацию о записях, по той или иной причине не попадающих более в область рассмотрения не подключенной в настоящий момент сессии синхронизации, и в дальнейшем использовать эту информацию для генерации сообщений об удалении вместо сообщений о наличии записей.

При усечении информации об истории изменений, CSN последней записи, удалённой из информации об истории изменений, может быть сохранён как CSN усечения информации об истории изменений. Такой CSN усечения может быть использован для определения возможности синхронизации клиентской копии из содержимого информации об истории изменений путём его сравнения с состоянием синхронизации, содержащимся в предоставляемом клиентом куки.

При большом количестве сессий, возможно, имеет смысл вести подобную информацию об истории изменений только для избранных клиентов. Кроме того, использующим такой подход серверам необходимо следить за потреблением ресурсов для обеспечения разумной работы сервера и защиты от злоупотреблений. Может быть целесообразно ограничить использование такого режима работы какой-либо политикой.

Адреса авторов

Kurt D. Zeilenga, OpenLDAP Foundation, EMail: [email protected]

Jong Hyuk Choi, IBM Corporation, EMail: [email protected]

Полное заявление авторских прав

Copyright (C) Internet Society (2006).

На этот документ распространяются права, лицензии и ограничения, содержащиеся в BCP 78 и в www.html-editor.org/copyright.html, и, за исключением случаев, изложенных в нем, авторы сохраняют все свои права.

Это документ и содержащаяся в нём информация распространяются "КАК ЕСТЬ" и АВТОР ДОКУМЕНТА, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН/ОНА ПРЕДСТАВЛЯЕТ, ИЛИ КОТОРОЙ ОН/ОНА СПОНСИРУЕТСЯ (ЕСЛИ ТАКОВЫЕ ИМЕЮТСЯ), INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБЫЕ ГАРАНТИИ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ ПРИВЕДЁННОЙ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШАЕТ КАКИХ-ЛИБО ПРАВ ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ПРИГОДНОСТИ ДЛЯ КОНКРЕТНЫХ ЦЕЛЕЙ.

Интеллектуальная собственность

IETF не занимает никакой позиции относительно действительности или области действия каких-либо прав на интеллектуальную собственность или других прав, которые могут заявляться как относящиеся к реализации или использованию технологий, описанных в данном документе, либо в подтверждении которых могут или не могут быть доступны какие-либо лицензии; кроме того, IETF не заявляет о том, что она будет предпринимать какие-либо независимые усилия по выявлению подобных прав. Информацию по процедурам в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии поданных в секретариат IETF заявлений о правах на интеллектуальную собственность (Intellectual Property Rights, IPR), а также какие-либо документы, подтверждающие лицензию и предназначенные для предоставления доступа к ним, либо результаты попыток получения генеральных лицензий или разрешений на пользование подобными правами собственности могут быть получены теми, кто занимается реализацией, или пользователями данной спецификации из он-лайн репозитория IPR IETF по адресу http://www.ietf.org/ipr.

IETF просит всех заинтересованных лиц довести до её сведения любые авторские права, патенты или патентные заявки, либо другие права собственности, которые могут касаться технологий данного стандарта и могут потребоваться для его реализации. Пожалуйста, направляйте информацию в IETF по адресу [email protected]

Признание заслуг

Финансирование функций RFC Editor обеспечивается IETF Administrative Support Activity (IASA).

Перевод выполнен участниками проекта. Предложения по улучшению перевода и сообщения об ошибках принимаются на форуме проекта.

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