Лекция 6. Сетевые протоколы

Взаимодействие компьютеров между собой происходит в соответствии со строго

регламентированными правилами. Эти правила определяются в рамках модели сетевого

взаимодействия. При этом, как правило, используется модель OSI - модель

взаимодействия открытых систем (Open System Interconnection Reference Model —

OSI/RM, или ЭМВОС), чтобы помочь поставщикам создавать совместимые сетевые

аппаратные и программные средства. В соответствии с этой моделью выделяются

следующие уровни

1. физический (Physical)

2. канальный (Data Link)

3. сетевой (Network)

4. транспортный (Transport)

5. сеансовый (Session)

6. представления (Presentation)

7. прикладной (Application)

Протоколом называют набор правил, определяющих состав пакета и

последовательность действий на соответствующем уровне.

Интерфейсом называют набор правил, определяющих способ передачи данных

между уровнями.

Стеком протоколов называют упорядоченную совокупность протоколов

нескольких уровней.

7 Прикладной организация доступа к ресурсам сети. Например, получение

файла – FTP (File Transfer Protocol), доступ к терминалу –

Telnet и пр.

6 Представления преобразование данных к удобному для передачи по сети виду

(например, шифрование данных по протоколу SSL - Secure

Socket Layer)

5 Сеансовый идентификация, начало/окончание сеанса передачи, аварийные

режимы.

4 Транспортный сборка всех пакетов в узле назначения

3 Сетевой доставка пакета в узел назначения (адресация, маршрутизация,

проверка целостности данных)

2 Канальный доставка пакета на следующий узел сети (адресация,

обнаружение/исправление ошибок)

1 Физический стандартизация электрических и временных характеристик

сигналов, физических параметров линий связи и разъёмов

Эталонная модель OSI является только моделью. Реальное развитие сети Интернет

основано на стеке протоколовTCP/IP, который основан на четырех уровнях:

2

Уровни OSI Стек TCP/IP

7 Прикладной

Прикладной HTTP, LDAP, Z39.50, ... 6 Представления

5 Сеансовый

4 Транспортный Транспортный TCP, UDP

3 Сетевой Сетевой IP, ARP, ICMP, ....

2 Канальный Физический Ethernet, ATM, ...

1 Физический

Нас будут интересовать протоколы прикладного уровня стека TCP/IP, т.е. три

верхних уровня эталонной модели OSI.

Протокол HTTP

Протокол основан на обмене текстовой информацией. Каждый запрос содержит

стартовую строку, заголовок и данные, отделенные от заголовка пустой строкой.

Тартовые строки различаются для запросов и ответов.

Стартовая строка запроса содержит указание на метод (method), URI, аббревиатуру

протокола и версию протокола:

METHOD URI HTTP/VERSION\r\n

Стартовая строка заканчивается кодами CR LF.

В HTTP могут быть использованы различные методы. Наиболее распространенные:

GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE.

URI указывает на требуемых ресурс.

В качестве VERSION используются 1.0 или 1.1.

Заголовок состоит из последовательности строк вида

Параметр: значение параметра, ...\r\n

Пример запроса:

GET /my/my_page.html HTTP/1.1

Host: www.my_server.org

User-Agent: Mozilla/5.0 (X11; U; Linux i686;

ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5

Accept: text/html

Connection: close

3

Для версии 1.1 возможно сохранить сеанс открытым. Для этого должны

присутствовать строки

. . .

Connection: keep-alive

Keep-Alive: 300

. . .

Стартовая строка ответа выглядит так:

HTTP/Версия Код состояния [Пояснение]

Например

HTTP/1.1 200 Ok

Методы HTTP

Метод Краткое описание

OPTIONS

Используется для определения возможностей веб-сервера или параметров соединения для

конкретного ресурса. Предполагается, что запрос клиента может содержать тело сообщения для

указания интересующих его сведений. Формат тела и порядок работы с ним в настоящий момент

не определён. Сервер пока должен его игнорировать. Аналогичная ситуация и с телом в ответе

сервера.

Для того чтобы узнать возможности всего сервера, клиент должен указать в URI звёздочку —

«*». Запросы «OPTIONS * HTTP/1.1» могут также применяться для проверки работоспособности

сервера (аналогично «пингованию») и тестирования на предмет поддержки сервером протокола

HTTP версии 1.1.

Результат выполнения этого метода не кэшируется.

GET

Используется для запроса содержимого указанного ресурса. С помощью метода GET можно

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

информацию о ходе выполнения процесса. Клиент может передавать параметры выполнения

запроса в URI целевого ресурса после символа «?»:

GET /path/resource?param1=value1&m2=value2 HTTP/1.1

Согласно стандарту HTTP, запросы типа GET считаются идемпотентными [4] — многократное

повторение одного и того же запроса GET должно приводить к одинаковым результатам (при

условии, что сам ресурс не изменился за время между запросами). Это позволяет кэшировать

ответы на запросы GET.

Кроме обычного метода GET, различают ещё условный GET и частичный GET. Условные

запросы GET содержат заголовки If-Modified-Since, If-Match, If-Range и подобные. Частичные

GET содержат в запросе Range. Порядок выполнения подобных запросов определён стандартами

отдельно.

HEAD

Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Запрос

HEAD обычно применяется для извлечения метаданных, проверки наличия ресурса (валидация

URL) и чтобы узнать, не изменился ли он с момента последнего обращения.

Заголовки ответа могут кэшироваться. При несовпадении метаданных ресурса с

соответствующей информацией в кэше копия ресурса помечается как устаревшая.

POST

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

посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они

передаются серверу методом POST и он помещает их на страницу. При этом передаваемые

данные (в примере с блогами — текст комментария) включаются в тело запроса. Аналогично с

помощью метода POST обычно загружаются файлы.

В отличие от метода GET, метод POST не считается идемпотентным, то есть многократное

повторение одних и тех же запросов POST может возвращать разные результаты (например,

4

после каждой отправки комментария будет появляться одна копия этого комментария).

При результатах выполнения 200 (Ok) и 204 (No Content) в тело ответа следует включить

сообщение об итоге выполнения запроса. Если был создан ресурс, то серверу следует вернуть

ответ 201 (Created) с указанием URI нового ресурса в заголовке Location.

Сообщение ответа сервера на выполнение метода POST не кэшируется.

PUT

Применяется для загрузки содержимого запроса на указанный в запросе URI. Если по заданному

URI не существовало ресурса, то сервер создаёт его и возвращает статус 201 (Created). Если же

был изменён ресурс, то сервер возвращает 200 (Ok) или 204 (No Content). Сервер не должен

игнорировать некорректные заголовки Content-* передаваемые клиентом вместе с сообщением.

Если какой-то из этих заголовков не может быть распознан или не допустим при текущих

условиях, то необходимо вернуть код ошибки 501 (Not Implemented).

Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI

ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка

передаваемого клиентом содержимого. Используя PUT, клиент предполагает, что загружаемое

содержимое соответствуют находящемуся по данному URI ресурсу.

Сообщения ответов сервера на метод PUT не кэшируются.

PATCH Аналогично PUT, но применяется только к фрагменту ресурса.

DELETE Удаляет указанный ресурс.

TRACE Возвращает полученный запрос так, что клиент может увидеть, что промежуточные сервера

добавляют или изменяют в запросе.

LINK Устанавливает связь указанного ресурса с другими.

UNLINK Убирает связь указанного ресурса с другими.

Каждый сервер обязан поддерживать как минимум методы GET и HEAD. Если

сервер не распознал указанный клиентом метод, то он должен вернуть статус 501 (Not

Implemented). Если серверу метод известен, но он не применим к конкретному ресурсу, то

возвращается сообщение с кодом 405 (Method Not Allowed). В обоих случаях серверу

следует включить в сообщение ответа заголовок Allow со списком поддерживаемых

методов.

Заголовки HTTP

Заголовок Группа Краткое описание

Allow Entity Список методов, применимых к запрашиваемому ресурсу.

Content-Encoding Entity Применяется при необходимости перекодировки содержимого

(например, gzip/deflated).

Content-Language Entity Локализация содержимого (язык(и))

Content-Length Entity Размер тела сообщения (в октетах)

Content-Range Entity Диапазон (используется для поддержания многопоточной

загрузки или дозагрузки)

Content-Type Entity

Указывает тип содержимого (mime-type, например

text/html).Часто включает указание на таблицу символов локали

(charset)

Expires Entity Дата/время, после которой ресурс считается устаревшим.

Используется прокси-серверами

Last-Modified Entity Дата/время последней модификации сущности

5

Cache-Control General Определяет директивы управления механизмами кэширования.

Для прокси-серверов.

Connection General Задает параметры, требуемые для конкретного соединения.

Date General Дата и время формирования сообщения

Pragma General

Используется для специальных указаний, которые могут

(опционально) применяется к любому получателю по всей

цепочке запросов/ответов (например, pragma: no-cache).

Transfer-Encoding General

Задает тип преобразования, применимого к телу сообщения. В

отличие от Content-Encoding этот заголовок распространяется на

все сообщение, а не только на сущность.

Via General

Используется шлюзами и прокси для отображения

промежуточных протоколов и узлов между клиентом и веб-

сервером.

Warning General Дополнительная информация о текущем статусе, которая не

может быть представлена в сообщении.

Accept Request Определяет применимые типы данных, ожидаемых в ответе.

Accept-Charset Request Определяет кодировку символов (charset) для данных,

ожидаемых в ответе.

Accept-Encoding Request Определяет применимые форматы кодирования/декодирования

содержимого (напр, gzip)

Accept-Language Request Применимые языки. Используется для согласования передачи.

Authorization Request Учетные данные клиента, запрашивающего ресурс.

From Request Электронный адрес отправителя

Host Request Имя/сетевой адрес [и порт] сервера. Если порт не указан,

используется 80.

If-Modified-Since Request

Используется для выполнения условных методов (Если-

Изменился...). Если запрашиваемый ресурс изменился, то он

передается с сервера, иначе - из кэша.

Max-Forwards Request Представляет механиз ограничения количества шлюзов и прокси

при использовании методов TRACE и OPTIONS.

Proxy-

Authorization Request

Используется при запросах, проходящих через прокси,

требующие авторизации

Referer Request

Адрес, с которого выполняется запрос. Этот заголовок

отсутствует, если переход выполняется из адресной строки или,

например, по ссылке из js-скрипта.

User-Agent Request Информация о пользовательском агенте (клиенте)

Location Response Адрес перенаправления

Proxy-Authenticate Response Сообщение о статусе с кодом 407.

Server Response Информация о программном обеспечении сервера, отвечающего

на запрос (это может быть как веб- так и прокси-сервер).

Протокол Z39.50

Протокол основан на обмене специальными пакетами (APDU), определенными в

спецификациях ASN.1.

Протокол содержит определения 5 (сеанс) и 6 (представление) уровней модели OSI.

6

Субъекты сетевого взаимодействия

Протокол Z39.50 описывает сетевое взаимодействие субъектов в архитектуре

«клиент-сервер». Однако это взаимодействие несколько отличается от классической

архитектуры «клиент-сервер», в которой инициатором любого запроса может быть только

клиент, а серверу всегда отводится пассивная роль ожидающего и отвечающего. Как будет

видно ниже, в Z39.50 это не всегда так. Может быть поэтому разработчики протокола

изменили терминологию, заменив термины «клиент» и «сервер» на термины «origin» и

«target» соответственно. За редким исключением понятия «клиент»-«origin» и «сервер»-

«target» совпадают.

Для описания логики сетевого взаимодействия в Z39.50 стандартом определены

следующие компоненты:

Origin – компонента, инициирующая сеанс связи Z39.50

Target – компонента, ожидающая открытия сеанса Z39.50

Database user – пользователь данных

Database provider – поставщик данных

Service provider – компонента, принимающая сетевые запросы и ответы

Service user – компонента использующая сетевые запросы и ответы

Client – приложение, включающее origin и database user

Server – приложение, включающее target и database provider

В стандарте описаны четыре сервисных примитива, в терминах которых

формулируются правила сервисных процедур Z39.50:

Request (запрос) – примитив, используемый origin для инициализации его сервис-

провайдером соответствующей сервисной процедуры

Indication (индикация) – примитив, передающейсе в target от сервис-провайдера к

сервис-потребителю

Response (ответ) – примитив, используемый target для инициализации его сервис-

провайдером ответа

Confirmation (уведомление) – примитив, передающийся в origin от сервис-провайдера

к сервис-потребителю.

Последовательность сервисной процедуры может быть проиллюстрирована на

примере запроса Search, инициатором которого является origin:

Origin сервис-потребитель формирует для своего сервис-провайдера запрос

SearchRequest

7

От origin к target по сети пересылается специальный пакет - APDU SearchRequest

Target сервис-провайдер указывает своему сервис-потребителю о поступлении

SearchRequest

Target сервис-потребитель формирует SearchResponse для своего сервис-провайдера

От target к origin пересылается специальный пакет – APDU SearchResponse

Origin сервис-провайдер уведомляет своего сервис-потребителя о SearchResponse

Обычно так выглядят все сервисные процедуры (Init, Search, Present, Delete,

Resource-report, Sort, Scan, Extended-services). Однако есть и такие, в которых роли target и

origin меняются местами. Инициатором процедур (Access-control и Resource-control)

является target!

Все составляющие протокола Z39.50 имеют OID

ANSI-Z39-50-ObjectIdentifier DEFINITIONS ::=

BEGIN

Z39-50 OBJECT IDENTIFIER ::=

{ iso (1) member-body (2) US (840) ANSI-standard-Z39.50 (10003)}

Z39-50-context OBJECT IDENTIFIER ::= {Z39-50 1}

Z39-50-APDU OBJECT IDENTIFIER ::= {Z39-50 2}

Z39-50-attributeSet OBJECT IDENTIFIER ::= {Z39-50 3}

Z39-50-diagnostic OBJECT IDENTIFIER ::= {Z39-50 4}

Z39-50-recordSyntax OBJECT IDENTIFIER ::= {Z39-50 5}

Z39-50-transferSyntax OBJECT IDENTIFIER ::= {Z39-50 6}

Z39-50-resourceReport OBJECT IDENTIFIER ::= {Z39-50 7}

Z39-50-accessControl OBJECT IDENTIFIER ::= {Z39-50 8}

Z39-50-extendedService OBJECT IDENTIFIER ::= {Z39-50 9}

Z39-50-userInfoFormat OBJECT IDENTIFIER ::= {Z39-50 10}

Z39-50-elementSpec OBJECT IDENTIFIER ::= {Z39-50 11}

Z39-50-variantSet OBJECT IDENTIFIER ::= {Z39-50 12}

Z39-50-schema OBJECT IDENTIFIER ::= {Z39-50 13}

Z39-50-tagSet OBJECT IDENTIFIER ::= {Z39-50 14}

Z39-50-negotiation OBJECT IDENTIFIER ::= {Z39-50 15}

Z39-50-query OBJECT IDENTIFIER ::= {Z39-50 16}

END

Типы ADPU

Протоколом предусмотрены следующие типы пакетов для обмена информацией:

PDU ::= CHOICE {

initRequest [20] IMPLICIT InitializeRequest,

initResponse [21] IMPLICIT InitializeResponse,

searchRequest [22] IMPLICIT SearchRequest,

searchResponse [23] IMPLICIT SearchResponse,

presentRequest [24] IMPLICIT PresentRequest,

presentResponse [25] IMPLICIT PresentResponse,

deleteResultSetRequest [26] IMPLICIT DeleteResultSetRequest,

deleteResultSetResponse [27] IMPLICIT DeleteResultSetResponse,

8

accessControlRequest [28] IMPLICIT AccessControlRequest,

accessControlResponse [29] IMPLICIT AccessControlResponse,

resourceControlRequest [30] IMPLICIT ResourceControlRequest,

resourceControlResponse [31] IMPLICIT ResourceControlResponse,

triggerResourceControlRequest [32] IMPLICIT TriggerResourceControlRequest,

resourceReportRequest [33] IMPLICIT ResourceReportRequest,

resourceReportResponse [34] IMPLICIT ResourceReportResponse,

scanRequest [35] IMPLICIT ScanRequest,

scanResponse [36] IMPLICIT ScanResponse,

-- [37] through [42] reserved

sortRequest [43] IMPLICIT SortRequest,

sortResponse [44] IMPLICIT SortResponse,

segmentRequest [45] IMPLICIT Segment,

extendedServicesRequest [46] IMPLICIT ExtendedServicesRequest,

extendedServicesResponse [47] IMPLICIT ExtendedServicesResponse,

close [48] IMPLICIT Close}

Процедура установление сеанса Z39.50

Протокол Z39.50 является протоколом, который ориентирован на постоянное

соединение «origin-target». Сеанс необходим для поддержки target специальных сеансовых

переменных, которые создаются динамически при открытии сеанса и уничтожаются при

его закрытии.

В сеансовых переменных target может хранить всяческую информацию,

касающуюся текущего сеанса: историю запросов, настройки, сведения о пользователе и

т.п. Именно в сеансовых переменных target сохраняет именнованные наборы данных

(NamedResultSet), доступные для использования при повторных запросах.

Общение origin с target вне сеанса возможно только при помощи APDU initRequest,

предназначенного для установления сеанса.

Итак, для установления сеанса связи origin должен послать target APDU initRequest.

Здесь существенно, что посылка такого APDU прерогатива только origin. Посылаемый

APDU должен содержать информацию о клиенте, необходимую для инициализации

сеансовых переменных на сервере, в том числе информацию о его функциональных

возможностях.

Получив APDU initRequest, target проверяет функциональные возможности клиента

и, если они удовлетворительны, создает сеансовый блок переменных и инициализирует их

в соответствии с полученными значениями. Затем в эти переменные заносится

информация о максимально совпадающих функциональных возможностях пары target-

origin для дальнейшего использования. При успешном выполнении описанных процедур

target формирует APDU initResponse, в который помещает некоторую информацию из

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

возможностях, устанавливает в специальном логическом поле result значение TRUE и

отсылает этот APDU клиенту. Если сеанс не удалось по какой-то причине открыть,

9

посылаемый клиенту APDU initResponse содержит в специальном логическом поле result

значение FALSE. Сеансовый блок при этом уничтожается.

Получив APDU initResponse со значением TRUE в поле result, origin устанавливает

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

своих. При этом сеанс связи считается открытым.

О чем и как договариваются субъекты

Как было показано в предыдущей секции, в момент открытия сеанса origin и target

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

функциональным возможностям относятся:

Версия используемого протокола Z39.50

Размер сообщения

Размер записи

Список функций

Имя и пароль пользователя (не обязательно)

Пользовательская информация

Другая информация

Версия используемого протокола Z39.50 – в результате процедуры открытия

сеанса target устанавливает действующей минимальную из своей и полученной в APDU

initRequest и отсылает ее origin в APDU initResponse. Получив APDU initResponse origin

принимает за действующую минимальную из своей и полученной.

Размер сообщения и размер записи – в результате процедуры, описанной выше,

принимаются минимальные размеры.

Список функций – при формировании APDU initRequest origin кодирует свои

допустимые функции в поле options в виде битовой последовательности:

Bit 0 - search

Bit 1 - present

Bit 2 - deleteSet

Bit 3 - resourceReport

Bit 4 - triggerResourceCtrl

Bit 5 - resourceCtrl

Bit 6 - accessCtrl

Bit 7 - scan

Bit 8 - sort

Bit 9 - reserved

Bit 10 - extendedServices

Bit 11 - level-1 Segmentation

Bit 12 - level-2 Segmentation

Bit 13 - concurrentOperation

10

Bit 14 - namedResultSet

Bit 15 - encapsulation

Bit 16 - resultCountInSort

Bit 17 - negotiation

Bit 18 - duplicateDetection

Bit 19 - queryType104

Получив APDU initRequest target сравнивает полученное значение options со своим

и формирует поле options APDU initResponse битовой операцией AND. Получив APDU

initResponse, origin битовой операцией AND со своим значением options и полученным

формирует список действующих в сеансе функций.

Имя и пароль пользователя – в APDU initRequest origin может передать

информацию для аутентификации пользователя. При наличие этой информации target

обязан произвести аутентификацию.

Пользовательская информация – origin в поле userInformationField может

передать дополнительную информацию о клиенте и пользователе.

Другая информация – origin в поле otherInfo может передать, а target вернуть,

дополнительную информацию. В это поле стандартом вкладываются возможности

дополнительного согласования (negotiation). ASN.1 определение поля otherInfo

следующее:

OtherInformation ::= [201] IMPLICIT SEQUENCE OF SEQUENCE{

category [1] IMPLICIT InfoCategory OPTIONAL,

information CHOICE{

characterInfo [2] IMPLICIT InternationalString,

binaryInfo [3] IMPLICIT OCTET STRING,

externallyDefinedInfo [4] IMPLICIT EXTERNAL,

oid [5] IMPLICIT OBJECT IDENTIFIER}}

--

InfoCategory ::= SEQUENCE{

categoryTypeId [1] IMPLICIT OBJECT IDENTIFIER OPTIONAL,

categoryValue [2] IMPLICIT INTEGER}

Т.е. один или несколько раз повторяется структура, называемая otherInfo блок:

SEQUENCE{

category [1] IMPLICIT InfoCategory OPTIONAL,

information CHOICE{

characterInfo [2] IMPLICIT InternationalString,

binaryInfo [3] IMPLICIT OCTET STRING,

externallyDefinedInfo [4] IMPLICIT EXTERNAL,

oid [5] IMPLICIT OBJECT IDENTIFIER}}

Дополнительное согласования (negotiation) может выполняться только если

otherInfo содержит блоки вида:

SEQUENCE{ externallyDefinedInfo [4] IMPLICIT EXTERNAL }

т.е. отсутствует category, а information всегда IMPLICIT EXTERNAL. Следует заметить,

11

что определения negotiation через открытие сеанса было введено в стандарт после его

принятия в 1995 году. Однако именно через этот механизм можно реализовать

согласование кодовых таблиц target и origin, которые столь актуальны для кириллицы.

Переговоры о языке и наборе символов для кириллицы

Разработчики программного обеспечения Z39.50 в России договорились о

поддержке следующего механизма переговоров о выборе языка и набора символов:

Переговоры соответствует стандартному механизму Negotiation при инициализации

сеанса и основаны на спецификациях CharSetandLanguageNegotiation-3.

NegotiationRecordDefinition-charSetandLanguageNegotiation-3

{Z39-50-negotiationRecordDefinition CharSetandLanguageNegotiation-3 (3)}

DEFINITIONS ::= BEGIN

CharSetandLanguageNegotiation ::= CHOICE{

proposal [1] IMPLICIT OriginProposal,

response [2] IMPLICIT TargetResponse}

--

-- For character sets:

-- Origin proposes one, two, or all three of the following, in order of

-- preference:

-- (a) 2022 character sets.

-- (b) 10646 character set.

-- (c) Private character set.

--

-- The target responds with one of (a), (b), or (c), indicating the

-- character set(s) to be supported for all name and message strings.

--

-- If the origin includes (a),

-- the origin proposes:

-- (1) A proposed environment: 7-bit, 8-bit, or no-preference.

-- (2) A set of iso 2022 registration numbers.

-- (3) One or more proposed initial sets of registration numbers,

-- for c0, c1, g0, g1, g2 and g3. These must come from (2).

-- (4) The proposed encoding level.

-- And if the target selects (a), it responds with:

-- (1) A selected environment: 7-bit or 8-bit.

-- (2) A subset of the set of iso 2022 registration numbers proposed

-- by the origin.

-- (3) The initial set of registrations, which must come from (2)

-- but need not be from the set of initial registrations proposed

-- by the origin.

-- (4) The encoding level; less than or equal to that proposed.

--

-- If the origin includes (b),

-- The origin proposes:

-- (1) (optionally) A list of collections (i.e. subsets

-- of characters from the complete 10646 definition).

-- (2) An implementation level.

-- (3) Syntax/form: e.g. ucs-2, ucs-4, utf-8, utf-16.

-- And if the target selects (b), it responds by choosing a subset of the

-- collections proposed by the origin in (1) and an implementation level

-- less than or equal to that proposed by the origin in (2).

--

-- If the origin includes (c), the origin proposes one of the following:

-- (1) A list of private character sets, by one or more object

-- identifiers.

-- (2) A list of private character sets, by an EXTERNAL.

-- (3) An indication to use a private, previously agreed upon

-- character set.

12

-- And if the target selects (c):

-- - If the origin proposed (1), the target should respond with (1), and

-- the list of object identifiers should be a subset of the list that

-- the origin included.

-- - If the origin proposed (2), the target should respond with (2),

-- using the same EXTERNAL definition (but not necessarily the

-- same content) used by the origin.

-- - If the origin proposed (3), the target should respond with (3).

--

-- For Languages:

-- The origin optionally proposes one or more language codes. The target

-- response may include a single language code, which indicates the

-- language to be used for all message strings. The target may include

-- or omit this, whether or not the origin included a proposed set, and

-- the language code indicated need not be from among those proposed.

--

OriginProposal ::= SEQUENCE {

proposedCharSets [1] IMPLICIT SEQUENCE OF CHOICE{

-- Each should occur at most once, and in order of preference

-- (the "order of preference" is the reason why this is

-- "SEQUENCE OF CHOICE" rather than just "SEQUENCE")

iso2022 [1] Iso2022,

iso10646 [2] IMPLICIT Iso10646,

private [3] PrivateCharacterSet} OPTIONAL,

-- proposedCharSets must be omitted

-- if origin proposes version 2

proposedlanguages [2] IMPLICIT SEQUENCE OF LanguageCode OPTIONAL,

recordsInSelectedCharSets [3] IMPLICIT BOOLEAN OPTIONAL

-- default 'false'. See rule 6 above.

}

TargetResponse ::= SEQUENCE{

selectedCharSets [1] CHOICE{

iso2022 [1] Iso2022,

iso10646 [2] IMPLICIT Iso10646,

private [3] PrivateCharacterSet,

none [4] IMPLICIT NULL

-- If selected, no negotiation

-- is assumed to be in force

-- for character sets.

} OPTIONAL,

-- Omitted if and only if proposedCharSets

-- was Omitted in the request.

selectedLanguage [2] IMPLICIT LanguageCode OPTIONAL,

recordsInSelectedCharSets [3] IMPLICIT BOOLEAN OPTIONAL

-- Omitted if and only if 'recordsInSelectedCharSets' was omitted

-- in the request. See rule 6 above.

}

PrivateCharacterSet ::= CHOICE{

viaOid [1] IMPLICIT SEQUENCE OF OBJECT IDENTIFIER,

externallySpecified [2] IMPLICIT EXTERNAL,

previouslyAgreedUpon [3] IMPLICIT NULL}

LanguageCode ::= GeneralString -- from ANSI Z39.53-1994

-- Definition of ISO2022

-- For ISO 2022, the following is negotiated:

-- 1) The environment: 7-bit or 8-bit;

-- 2) a set of registration numbers (from the ISO Register of coded

-- character sets) for graphical and control character sets;

-- 3) g0, g1, g2, g3, c0, c1, the registration numbers of the graphical and

-- control character sets that are initially designated to g0, g1, etc.

-- The origin submits one or more sequences of values for

-- g0, g1, g2, g3, c0, c1 (for each sequence: at least one of

13

-- g0 and g1 must be included; g2 and g3 are optional and

-- may be included only if g1 is included;

-- c0 should be included; and c1 is optional); the target

-- selects one of the proposed sequences.

-- 4) gleft: which of g0, g1, g2 or g3, initially has GL shift status in

-- an 8-bit environment or has shift status in a 7-bit environment; and

-- 5) gright: which of g1, g2 or g3 initially has GR shift status in an

-- 8-bit environment.

Iso2022 ::= CHOICE{

originProposal [1] IMPLICIT SEQUENCE{

proposedEnvironment [0] Environment OPTIONAL,

-- omitted means no preference

proposedSets [1] IMPLICIT SEQUENCE OF INTEGER,

proposedInitialSets [2] IMPLICIT SEQUENCE OF

InitialSet,

proposedLeftAndRight [3] IMPLICIT LeftAndRight},

targetResponse [2] IMPLICIT SEQUENCE{

selectedEnvironment [0] Environment,

selectedSets [1] IMPLICIT SEQUENCE OF INTEGER,

selectedinitialSet [2] IMPLICIT InitialSet,

selectedLeftAndRight [3] IMPLICIT LeftAndRight}}

Environment ::= CHOICE{

sevenBit [1] IMPLICIT NULL,

eightBit [2] IMPLICIT NULL}

InitialSet::= SEQUENCE{

g0 [0] IMPLICIT INTEGER OPTIONAL,

g1 [1] IMPLICIT INTEGER OPTIONAL,

-- one of g0 and g1 must be included

g2 [2] IMPLICIT INTEGER OPTIONAL,

g3 [3] IMPLICIT INTEGER OPTIONAL,

--g2 and/or g3 may be included

-- only if g1 was included

c0 [4] IMPLICIT INTEGER,

c1 [5] IMPLICIT INTEGER OPTIONAL}

LeftAndRight ::= SEQUENCE{

gLeft [3] IMPLICIT INTEGER{

g0 (0),

g1 (1),

g2 (2),

g3 (3)},

gRight [4] IMPLICIT INTEGER{

g1 (1),

g2 (2),

g3 (3)} OPTIONAL}

-- Definition of Iso10646

--

-- The 10646 object identifier looks like:

-- 1.0.10646.1.implementationLevel.repertoireSubset.arc1.arc2. ....

--

-- (The second '1' is for "part 1" of 10646.)

--

-- ImplementationLevel is 1-3

--

-- repertoireSubset is 0 or 1, for 'all' or 'collections'.

-- The arcs are present only if repertoireSubset is 'collections',

-- in which case arc1, arc2, etc., are the

-- identifiers of collections of character repertoires.

--

-- There is a second 10646 oid, for specifying syntax/form:

-- 1.0.10646.1.0.form

--

14

-- (The second '0' represents "transfer syntax".)

--

-- where values of form include:

-- 2: ucs-2

-- 4: ucs-4

-- 5: utf-16

-- 8: utf-8

Iso10646 ::= SEQUENCE{

collections [1] IMPLICIT OBJECT IDENTIFIER OPTIONAL,

--oid of form 1.0.10646.1.implementationLevel

-- .repertoireSubset.arc1.arc2. ....

-- Target to choose a subset of the collections

-- proposed by the origin, and an implementation level

-- less than or equal to that proposed.

--

-- when 'collections' is omitted,

-- 'implementationLevel' defaults to 3.

--

encodingLevel [2] IMPLICIT OBJECT IDENTIFIER

-- oid of form 1.0.10646.1.0.form

-- where value of 'form' is 2, 4, 5, or 8

-- for ucs-2, ucs-4, utf-16, utf-8

}

END

Для фиксации набора символов в структуре

PrivateCharacterSet ::= CHOICE{

viaOid [1] IMPLICIT SEQUENCE OF OBJECT IDENTIFIER,

externallySpecified [2] IMPLICIT EXTERNAL,

previouslyAgreedUpon [3] IMPLICIT NULL}

используется частное внешнее определение (EXTERNAL):

ExternalCodePageDefinition

DEFINITIONS ::= BEGIN

CodePage ::= IMPLICIT OCTET STRING {

dos ('dos'),

win ('win'),

koi ('koi'),

iso ('iso'),

mac ('mac'),

uni ('uni') }

END

Процедура выбора выбора языка и набора символов выглядит следующим образом:

Origin в APDU InitRequest в одном из вложений поля OtherInformation -

externallyDefinedInfo посылает структуру CharSetandLanguageNegotiation-3, в которой

определены требуемый язык и требуемый PrivateCharacterSet. Естественно, при этом в

поле options APDU InitRequest должен быть установлен Bit 17.

Target при условии поддержки этого механизма анализирует содержимое структур и в

APDU InitResponse отсылает свои предложения по языку и набору символов.

Переговоры считаются удачными, если origin считает полученные предложения

приемлимыми. При установленном флаге recordsInSelectedCharSets в true все записи

15

target отсылает origin в выбранном наборе символов.

Закрытие сеанса

Для закрытия сеанса по инициативе origin он должен послать APDU close и

получить в ответ от target такой же APDU.

Как видно из определения, закрывая сеанс, origin может потребовать отчет по

использованным ресурсам, а target при этом может этот отчет включить в APDU. Кроме

этого указывается в поле CloseReason причина закрытия сеанса.

Следует особо отметить, что инициатором APDU close может быть не только origin,

но и target. Эта особенность отличает APDU close от других. Причина этого проста: может

возникнуть ситуация, когда сервер вынужден закрыть сеанс или все сеансы для

корректной работы, например, при выключении администратором аппаратуры сервера.

ASN.1 представление initRequest и initResponse

ASN.1 представления APDU initRequest и initResponse приведены ниже.

InitializeRequest ::= SEQUENCE{

referenceId ReferenceId OPTIONAL,

protocolVersion ProtocolVersion,

options Options,

preferredMessageSize [5] IMPLICIT INTEGER,

exceptionalRecordSize [6] IMPLICIT INTEGER,

idAuthentication [7] ANY OPTIONAL, -- see note below

implementationId [110] IMPLICIT InternationalString OPTIONAL,

implementationName [111] IMPLICIT InternationalString OPTIONAL,

implementationVersion [112] IMPLICIT InternationalString OPTIONAL,

userInformationField [11] EXTERNAL OPTIONAL,

otherInfo OtherInformation OPTIONAL}

--Note:

-- For idAuthentication, the type ANY is retained

-- for compatibility with earlier versions.

-- For interoperability, the following is recommended:

-- IdAuthentication [7] CHOICE{

-- open VisibleString,

-- idPass SEQUENCE {

-- groupId [0] IMPLICIT InternationalString OPTIONAL,

-- userId [1] IMPLICIT InternationalString OPTIONAL,

-- password [2] IMPLICIT InternationalString OPTIONAL },

-- anonymous NULL,

-- other EXTERNAL

-- May use access control formats for 'other'. See Appendix 7 ACC.

--

InitializeResponse ::= SEQUENCE{

referenceId ReferenceId OPTIONAL,

protocolVersion ProtocolVersion,

options Options,

preferredMessageSize [5] IMPLICIT INTEGER,

exceptionalRecordSize [6] IMPLICIT INTEGER,

result [12] IMPLICIT BOOLEAN,

-- relect = FALSE; Accept = TRUE

implementationId [110] IMPLICIT InternationalString OPTIONAL,

implementationName [111] IMPLICIT InternationalString OPTIONAL,

implementationVersion [112] IMPLICIT InternationalString OPTIONAL,

userInformationField [11] EXTERNAL OPTIONAL,

otherInfo OtherInformation OPTIONAL}

16

-- Begin auxiliary definitions for Init PDUs

ProtocolVersion ::= [3] IMPLICIT BIT STRING{

version-1 (0),

-- This bit should always be set, but does not

-- correspond to any Z39.50 version.

version-2 (1),

-- "Version 2 supported."

-- This bit should always be set.

version-3 (2) -- "Version 3 supported."

-- Values higher than 'version-3' should be ignored. Both the Initialize

-- request and Initialize Response APDUs include a value string

-- corresponding to the supported versions. The highest common version is

-- selected for use. If there are no versions in common, "Result" in the

-- Init Response should indicate "reject."

-- Note: Versions 1 and 2 are identical. Systems supporting version 2

-- should indicate support for version 1 as well, for interoperability with

-- systems that indicate support for version 1 only (e.g. ISO 10163-1991

-- implementations).

}

Options ::= [4] IMPLICIT BIT STRING{

search (0),

present (1),

delSet (2),

resourceReport (3),

triggerResourceCtrl (4),

resourceCtrl (5),

accessCtrl (6),

scan (7),

sort (8),

-- (9) (reserved)

extendedServices (10),

level-1Segmentation (11),

level-2Segmentation (12),

concurrentOperations (13),

namedResultSets (14)}

-- end auxiliary definitions for Init PDUs

Протокол LDAP

В общей модели, принятой данным протоколом, один из клиентов взаимодействует

с одним из серверов. В этой модели, клиент передает протокольный запрос, описывающий

операцию, которую должен выполнить сервер. Сервер отвечает за выполнение

необходимых операций в каталоге. По завершении операции сервер обычно возвращает

клиенту отклик, содержащий соответствующую информацию.

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

обрабатывается независимо, оставляя каталог в непротиворечивом состоянии.

Хотя серверы должны присылать отклики, всякий раз, когда такие отклики

определяются в протоколе, не задается никаких требований синхронизации клиентов или

серверов. Запросы и отклики при нескольких операциях между клиентом и сервером

могут следовать в любом порядке. Если необходимо, синхронность поведения может

контролироваться приложениями клиента. Базовые протокольные операции могут быть

поставлены в соответствие субнабору операций X.500.

17

Однако, не существует четкого соотношения между LDAP-операциями и

операциями протокола X.500 доступа к каталогу DAP. LDAP является упрощенной

версией DAP. Реализации сервера работают как шлюз по отношению к каталогам X.500 и

может потребоваться несколько DAP-запросов, чтобы реализовать один запрос LDAP.

Операционный протокольный обмен осуществляется на уровне обмена

сообщениями LDAP. Когда транспортное соединение закрывается, любые незавершенные

операции уровня LDAP-сообщений прекращаются (когда это возможно) или завершаются

без передачи отклика (если прерывание невозможно). Когда транспортное соединение

закрыто, клиент не должен полагать, что любая незавершенная операция обновления

завершилась успешно или вообще не выполнена.

Протокол описан с использованием стандарта ASN.1 (Abstract Syntax Notation One)

и базовых правил кодирования (BER). В протоколе с самого начала предусмотрены

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

протокольную версию поддерживает сервер, считывая атрибут 'supportedLDAPVersion' с

корневой DSE (Distinguished Service Entry) [RFC4512].

Протокол содержит определения 5 (сеанс), 6 (представление) и 7 (приложения)

уровней модели OSI.

Для целей протокольных обменов все протокольные операции вкладываются в

общий конверт 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) –

Controls ::= SEQUENCE OF control Control

18

Control ::= SEQUENCE {

controlType LDAPOID,

criticality BOOLEAN DEFAULT FALSE,

controlValue OCTET STRING OPTIONAL }

LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [RFC4512]

МessageID запроса должен иметь ненулевое значение, отличное от messageID

любого другого активного запроса в рамках текущей сессии LDAP. Нулевое значение

зарезервировано для сообщений уведомления.

Клиент обычно инкрементирует счетчик при возникновении любого запроса.

Клиент не должен посылать запрос с тем же messageID, что и более ранний запрос

той же самой сессии, если только он не уверен, что сервер уже не обслуживает этот более

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

ситуация становится неоднозначной.

Bind Request Protocol Op 01100000 0x60 [APPLICATION 0]

Bind Response Protocol Op 01100001 0x61 [APPLICATION 1]

Unbind Request Protocol Op 01000010 0x42 [APPLICATION 2]

Search Request Protocol Op 01100011 0x63 [APPLICATION 3]

Search Result Entry Protocol Op 01100100 0x64 [APPLICATION 4]

Search Result Done Protocol Op 01100101 0x65 [APPLICATION 5]

Modify Request Protocol Op 01100110 0x66 [APPLICATION 6]

Modify Response Protocol Op 01100111 0x67 [APPLICATION 7]

Add Request Protocol Op 01101000 0x68 [APPLICATION 8]

Add Response Protocol Op 01101001 0x69 [APPLICATION 9]

Delete Request Protocol Op 01001010 0x4a [APPLICATION 10]

Delete Response Protocol Op 01101011 0x6b [APPLICATION 11]

Modify DN Request Protocol Op 01101100 0x6c [APPLICATION 12]

Modify DN Response Protocol Op 01101101 0x6d [APPLICATION 13]

Compare Request Protocol Op 01101110 0x6e [APPLICATION 14]

Compare Response Protocol Op 01101111 0x6f [APPLICATION 15]

Abandon Request Protocol Op 01010000 0x50 [APPLICATION 16]

Search Result Reference Protocol Op 01110011 0x73 [APPLICATION 19]

Extended Request Protocol Op 01110111 0x77 [APPLICATION 23]

Extended Response Protocol Op 01111000 0x78 [APPLICATION 24]

Intermediate Response Protocol Op 01111001 0x79 [APPLICATION 25]

19

LDAPResult является структурным элементом, используемым в протоколе для того,

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

запросов серверы возвращают отклики, содержащие элементы, найденные в LDAPResult,

чтобы индицировать конечное состояние протокольного запроса.

LDAPResult ::= SEQUENCE {

resultCode ENUMERATED {

success (0),

operationsError (1),

protocolError (2),

timeLimitExceeded (3),

sizeLimitExceeded (4),

compareFalse (5),

compareTrue (6),

authMethodNotSupported (7),

strongerAuthRequired (8),

-- 9 зарезервировано --

referral (10),

adminLimitExceeded (11),

unavailableCriticalExtension (12),

confidentialityRequired (13),

saslBindInProgress (14),

noSuchAttribute (16),

undefinedAttributeType (17),

inappropriateMatching (18),

constraintViolation (19),

attributeOrValueExists (20),

invalidAttributeSyntax (21),

-- 22-31 не используется --

noSuchObject (32),

aliasProblem (33),

invalidDNSyntax (34),

-- 35 reserved for undefined isLeaf --

aliasDereferencingProblem (36),

-- 37-47 не используется --

inappropriateAuthentication (48),

invalidCredentials (49),

insufficientAccessRights (50),

busy (51),

unavailable (52),

unwillingToPerform (53),

loopDetect (54),

-- 55-63 не используется --

namingViolation (64),

objectClassViolation (65),

notAllowedOnNonLeaf (66),

notAllowedOnRDN (67),

entryAlreadyExists (68),

objectClassModsProhibited (69),

-- 70 зарезервировано для CLDAP --

affectsMultipleDSAs (71),

-- 72-79 не используется --

other (80),

... },

matchedDN LDAPDN,

diagnosticMessage LDAPString,

referral [3] Referral OPTIONAL }

LDAPDN ::= LDAPString -- Constrained to <distinguishedName> [RFC4514]

LDAPString ::= OCTET STRING -- UTF-8 encoded, [ISO10646] characters

Нумерация resultCode является гибкой, как это определено в разделе 3.8 [RFC4520].

20

Сообщения, соответствующие кодам результата, приведены в приложении A. Если сервер

детектирует несколько ошибок для одной операции, возвращается только один результат.

Сервер должен вернуть результирующий код, который наилучшим образом характеризует

природу встретившейся ошибки.

Поле diagnosticMessage этого структурного элемента может, по выбору сервера,

использоваться для возврата строки, содержащей текстовое, читаемое человеком

диагностическое сообщение, которое дает данные, разъясняющие значение resultCode.

Если сервер решит не использовать текстовое сообщение, diagnosticMessage должно быть

пустым.

Для определенных кодов результата (обычно, но необязательно noSuchObject,

aliasProblem, invalidDNSyntax и aliasDereferencingProblem), поле matchedDN делается

равным (субъект управления доступом) имени последней записи (объекта или

псевдонима). Это имя используется для выявления адресуемого объекта.

Это будет усеченной формой предоставления имени или, если псевдоним был

разыменован в ходе локализации ввода, полученным в результате именем. В противном

случае поле matchedDN должно быть пустым.

Операция Bind

Функцией операции Bind является разрешение обмена аутентификационной

информацией между клиентом и сервером. Операция Bind должна восприниматься как

операция аутентификации. Семантика аутенификации и безопасности этой операции

представлена в [RFC4513].

Запрос Bind определен следующим образом:

BindRequest ::= [APPLICATION 0] SEQUENCE {

version INTEGER (1 .. 127),

name LDAPDN,

authentication AuthenticationChoice }

AuthenticationChoice ::= CHOICE {

simple [0] OCTET STRING,

-- 1 и 2 reserved

sasl [3] SaslCredentials,

... }

SaslCredentials ::= SEQUENCE {

mechanism LDAPString,

credentials OCTET STRING OPTIONAL }

Полями BindRequest являются:

version: номер версии протокола, используемый слоем сообщений LDAP.

Процедуры согласования использования определенной версии не существует.

Клиент устанавливает это поле равным желательной версии протокола. Если

21

сервер не поддерживает специфицированную версию, он должен послать отклик

BindResponse, где в resultCode записывается protocolError.

name: если поле не пусто, имя объекта Directory, с которым клиент хочет

взаимодействовать. Это поле может принимать нулевое значение (строка нулевой длины)

для целей анонимных соединений ([RFC4513], раздел 5.1) или при использовании SASL

[RFC4422] аутентификации ([RFC4513], раздел 5.2). Когда сервер пытается локализовать

именованный объект, он не должен выполнять разыменование псевдонима.

authentication: Информация, используемая при аутентификации. Этот тип является

расширяемым, как это определено в разделе 3.7 [RFC4520]. Серверы, которые не

поддерживают выбора, предоставляемого клиентом, возвращают BindResponse с кодом

resultCode равным authMethodNotSupported.

Текстовые пароли (состоящие из символов определенного символьного набора и

кодировки) передаваемые серверу с использованием простого AuthenticationChoice

должны передаваться в виде UTF-8. Перед передачей клиенты должны подготовить

текстовый пароль в виде строк запроса с привлечением профайла SASLprep [RFC4013]

алгоритма [RFC3454]. Пароли, содержащие другие данные (такие как произвольные

октеты) не должны модифицироваться. Определение того, является ли пароль текстовым,

решается клиентом локально.

Перед обработкой BindRequest, все незавершенные операции должны быть либо

завершены, либо прерваны. Сервер может либо ждать завершения операций, либо

прервать их. Сервер затем продолжает аутентифицировать клиента в одношаговом или

многошаговом процессе Bind. Каждый шаг требует от сервера посылки BindResponse,

чтобы отразить состояние аутентификации.

После посылки BindRequest, клиенты не должны посылать новые LDAP PDU до тех,

пор пока не получат BindResponse. Аналогично, серверы не должны обрабатывать или

реагировать на запросы в ходе обработки BindRequest.

Если клиент не выполнил операцию bind перед посылкой запроса и получает

operationsError, он может послать BindRequest. Если это также потерпит неудачу или

клиент решит не осуществлять bind в ходе текущей LDAP-сессии, он может завершить

сессию, заново ее перезапустить, и начать с посылки BindRequest. Это поможет

взаимодействовать с серверами, работающими с другими версиями LDAP.

Клиенты могут послать несколько запросов Bind, чтобы изменить

аутентификационные ассоциации и уровень безопасности или чтобы завершить

многоэтапный процесс Bind. Аутентификации от предыдущих Bind при этом будут

игнорироваться.

22

Для некоторых механизмов аутентификации SASL, может быть необходимо для

клиента отправить BindRequest несколько раз ([RFC4513], раздел 5.2). Клиенты не

должны запускать операции между двумя Bind-запросами, выполненными как часть

многошагового Bind.

Клиент может абортировать согласование SASL-соединения путем посылки

BindRequest с другим значением поля механизма SaslCredentials, или AuthenticationChoice.

Если клиент посылает BindRequest со значением поля sasl-мехнизм равным пустой

строке, сервер должен прислать BindResponse со значением resultCode равным

authMethodNotSupported. Это позволит клиенту абортировать согласование, если он хочет

попытаться снова запустить тот же механизм SASL.

Отклик Bind (BindResponse) определен следующим образом.

BindResponse ::= [APPLICATION 1] SEQUENCE {

COMPONENTS OF LDAPResult,

serverSaslCreds [7] OCTET STRING OPTIONAL }

BindResponse представляет собой индикацию сервером состояния запроса

аутентификации клиента.

Успешная операция Bind индицируется откликом BindResponse с результирующим

кодом resultCode, указывающим на успех. В противном случае соответствующий код

результата устанавливается в BindResponse. Для BindResponse, может использоваться код

результата protocolError, чтобы индицировать, что номер версии, использованный

клиентом, не поддерживается.

Если клиент поучает BindResponse, где resultCode имеет значение protocolError, это

предполагает, что сервер не поддерживает эту версию LDAP. В то время как клиент

может быть способен продолжать работу с другой версией этого протокола (который

может требовать или нет повторного установления транспортного соединения),

механизмы реализации такой возможности в данном документе не рассматриваются.

Клиенты, которые неспособны или не хотят продолжать операцию, должны завершить

LDAP-сессию.

Поле ServerSaslCreds используется в качестве части механизма SASL bind, чтобы

позволить клиенту аутентифицировать сервер, с которым он обменивается данными, или

выполнить аутентификацию по схеме "запрос-отклик". Если клиент реализует соединение

с простым выбором, или серверу не нужен механизм SASL для отправки данных клиенту,

тогда это поле не следует включать в BindResponse.

Операция Unbind

Функцией операции Unbind является завершение сессии LDAP. Операция Unbind

23

не является противоположностью операции Bind, как это может показаться из названия.

Названия этих операций являются историческими. Операция Unbind следовало бы назвать

"завершить" ("quit"). Операция Unbind определена как:

UnbindRequest ::= [APPLICATION 2] NULL

Клиент, после передачи UnbindRequest, и сервер после получения UnbindRequest,

должны корректным образом прервать сессию LDAP.

В следующем примере показана кодировка для запроса на связывание с простой

аутентификацией для пользователя «uid=jdoe,ou=People,dc=example,dc=com» с паролем

secret123, также с идентификатором сообщения один и без элементов управления

запросом:

30 39 – LDAPMessage начало

02 01 01 - идентификатор сообщения (целое значение 1)

60 34 – bindRequest - запроса на связывание

02 01 03 - версия протокола LDAP (целое значение 3)

04 24 75 69 64 3d 6a 64 6f 65 - DN связывания (36-байт)

2c 6f 75 3d 50 65 6f 70

6c 65 2c 64 63 3d 65 78

61 6d 70 6c 65 2c 64 63

3d 63 6f 6d

80 09 73 65 63 72 65 74 31 32 33 - пароль "secret123"

Ответ bindResponse - это просто LDAPResult с типом 0x61 . Предполагая, что

сервер вернул успешный ответ без DN, диагностического сообщения, URL-адресов

ссылок или элементов управления, он будет закодирован следующим образом:

30 0c - LDAPMessage начало

02 01 01 - идентификатор сообщения (целое значение 1)

61 07 - bindResponse

0a 01 00 - код результата успеха (нумерованное значение 0)

04 00 - нет сопоставленного DN (0-байт)

04 00 - Нет диагностического сообщения (0-байт)

Незапрошенное уведомление

Незапрошенное уведомление представляет собой LDAPMessage, посланное

сервером клиенту, которое не является откликом на какое-либо сообщение LDAPMessage,

полученное сервером. Эта операция используется для уведомления об экстраординарной

ситуации в сервере или в ходе LDAP-сессии между клиентом и сервером. Уведомление

является по своей природе рекомендательным, и сервер не ожидает какой-либо реакции со

стороны клиента.

Незапрошенное уведомление структурировано как LDAPMessage, в котором

24

messageID равен нулю а протокольная операция соответствует выбору extendedResp,

использующему тип ExtendedResponse. Поле responseName ExtendedResponse всегда

содержит LDAPOID, который уникален для этого уведомления.

Протокол SRU

Протокол SRU разработан как простая альтернатива протоколу Z39.50. Протокол

является расширением протокола HTTP. Протокольные процедуры могут выполняться

HTTP методами GET или POST.

Пример заголовка для GET:

GET /lcdb?version=1.2&operation=searchRetrieve&query=dinosaur HTTP/1.1

Host: lx2.loc.gov:210

Пример заголовка для POST:

POST /lcdb HTTP/1.1

Host: lx2.loc.gov:210

Content-type: application/x-www-form-urlencoded; charset=utf-8

Content-length: 51

version=1.1&operation=searchRetrieve&query=dinosaur

Существует возможность использовать SRU посредством SOAP. Раньше это

называлось протоколом SRW, затем решили, что правильнее называть SRU via SOAP.

Обычный пакет запроса SOAP

POST /StockQuote HTTP/1.1

Host: www.stockquoteserver.com

Content-Type: text/xml; charset="utf-8"

Content-Length: nnnn

SOAPAction: "Some-URI"

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m="Some-URI"> <symbol>DIS</symbol> </m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Для SRU via SOAP (SRW) выглядит так

POST /lcdb HTTP/1.1

Host: lx2.loc.gov:210

Content-Type: text/xml; charset="utf-8"

Content-Length: nnnn

SOAPAction: ""

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP:Body> <SRW:searchRetrieveRequest xmlns:SRW="http://www.loc.gov/zing/srw/">

25

<SRW:version>1.1</SRW:version> <SRW:query>dinosaur</SRW:query> <SRW:startRecord>1</SRW:startRecord> <SRW:maximumRecords>1</SRW:maximumRecords> <SRW:recordSchema>info:srw/schema/1/mods-v3.0</SRW:recordsSchema> </SRW:searchRetrieveRequest> </SOAP:Body> </SOAP:Envelope>

Ответ вкладывается в обычный SOAP ответ:

HTTP/1.1 200 OK

Content-Type: text/xml; charset="utf-8"

Content-Length: nnnn

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> <SOAP-ENV:Body> <!-- место для данных --> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

в виде SRU ответа

<zs:searchRetrieveResponse xmlns:zs="http://www.loc.gov/zing/srw/"> <zs:version>1.1</zs:version> <zs:numberOfRecords>2650</zs:numberOfRecords> <zs:records> <zs:record> <zs:recordSchema>dc</zs:recordSchema> <zs:recordPacking>xml</zs:recordPacking> <zs:recordData> <srw_dc:dc xmlns:srw_dc="info:srw/schema/1/dc-schema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="info:srw/schema/1/dc-schema http://www.loc.gov/standards/sru/resources/dc-schema.xsd"> <title xmlns="http://purl.org/dc/elements/1.1/"> 3-D dinosaur adventure. </title> . . . . </srw_dc:dc> </zs:recordData> <zs:recordPosition>1</zs:recordPosition> </zs:record> . . . . </zs:records> </zs:searchRetrieveResponse>

Таким образом, запросы SRU передаются через URL (GET), имя базы данных

фигурирует в виде элемента URL. В качестве параметров запроса могут выступать

следующие

Название

параметра

Обязательность Комментарий

operation all: M searchRetrieve, scan, explain

version all: M Версия протокола: 1.1, 1.2, 2.0

26

query sr:M, sc:-, ex:- Строка запроса CQL

scanClause sr:-, sc:M, ex:- Указание на просматриваемый индекс

responsePosition sr:-, sc:O, ex:- Положение терма в получаемом списке

startRecord sr:O, sc:-, ex:- Номер первой возвращаемой записи

maximumRecords sr:O, sc:-, ex:- Количество возвращаемых записей

maximumTerms sr:-, sc:O, ex:- Количество возвращаемых значений индекса

recordPacking sr:O, sc:-, ex:O Формат записей (xml, text)

recordSchema sr:O, sc:-, ex:- схема представления записей

resultsetTTL sr:O, sc:-, ex:- Время жизни результата поиска в секундах

stylesheet sr:O, sc:O, ex:O Указание XSLT для преобразования ответа

extraRequestData sr:O, sc:O, ex:O Дополнительные параметры

Ответ SRU зависит от типа операции и может содержать элементы записей, термов

и их параметров, а также дублирование параметров запроса. В качестве примера ниже

приведен пример ответа для операции explain:

<sru:explainResponse xmlns:sru="http://www.loc.gov/zing/srw/"> <sru:version>1.1</sru:version> <sru:record> <sru:recordPacking>XML</sru:recordPacking> <sru:recordSchema>http://explain.z3950.org/dtd/2.1/</sru:recordSchema> <sru:recordData> <zr:explain xmlns:zr="http://explain.z3950.org/dtd/2.1/"> <zr:serverInfo protocol="SRU" version="1.2" transport="http" method="GET POST SOAP"> <zr:host>myserver.com</zr:host> <zr:port>80</zr:port> <zr:database>cgi/mysru</zr:database> </zr:serverInfo> <zr:databaseInfo> <title lang="en" primary="true">SRU Test Database</title> </zr:databaseInfo> <zr:indexInfo> <zr:set name="dc" identifier="info:srw/cql-context-set/1/dc-v1.1"/> <zr:index> <zr:map> <zr:name set="dc">title</zr:name> </zr:map> </zr:index> </zr:indexInfo> <zr:schemaInfo> <zr:schema name="dc" identifier="info:srw/schema/1/dc-v1.1"> <zr:title>Simple Dublin Core</zr:title> </zr:schema> </zr:schemaInfo> <zr:configInfo> <zr:default type="numberOfRecords">1</zr:default> <zr:setting type="maximumRecords">50</zr:setting> <zr:supports type="proximity"/>

27

</zr:configInfo> </zr:explain> </sru:recordData> </sru:record> </sru:explainResponse>

Протокол OAI-PMH

Протокол OAI-PMH (The Open Archives Initiative Protocol for Metadata Harvesting)

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

протокол SRU (GET), но не может выступать как его альтернатива, т.к. не содержит

функций для поиска информации.

Приведенная ниже таблица содержит описание параметров OAI-PMH

Название

параметра

Обязательность Комментарий

verb

all: M

Identify

ListSets

ListMetadataFormats

ListIdentifiers

ListRecords

GetRecord

set Указание на набор данных

identifier Идентификатор записи

metadataPrefix Указание на схему данных

from Нижняя граница метки времени (datestamp)

until Верхняя граница метки времени (datestamp)

resumptionToken Номер первой возвращаемой записи

Пример запроса:

http://arXiv.org/oai2?

verb=GetRecord&identifier=oai:arXiv.org:cs/0112017&metadataPrefix=oai_dc

Пример ответа:

<?xml version="1.0" encoding="UTF-8"?> <OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd"> <responseDate>2002-02-08T08:55:46Z</responseDate> <request verb="GetRecord" identifier="oai:arXiv.org:cs/0112017" metadataPrefix="oai_dc">http://arXiv.org/oai2</request> <GetRecord> <record> <header>

28

<identifier>oai:arXiv.org:cs/0112017</identifier> <datestamp>2001-12-14</datestamp> <setSpec>cs</setSpec> <setSpec>math</setSpec> </header> <metadata> <oai_dc:dc xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/ http://www.openarchives.org/OAI/2.0/oai_dc.xsd"> <dc:title> Using Structural Metadata to Localize Experience of Digital Content </dc:title> <dc:creator>Dushay, Naomi</dc:creator> <dc:subject>Digital Libraries</dc:subject> <dc:description> With the increasing technical sophistication of both information consumers and providers, there is increasing demand for more meaningful experiences of digital information. We present a framework that separates digital object experience, or rendering, from digital object storage and manipulation, so the rendering can be tailored to particular communities of users. </dc:description> <dc:description> Comment: 23 pages including 2 appendices, 8 figures </dc:description> <dc:date>2001-12-14</dc:date> </oai_dc:dc> </metadata> </record> </GetRecord> </OAI-PMH>