ГОСТ Р ИСО/МЭК 9594-5-98

Группа П85

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ


Информационная технология

ВЗАИМОСВЯЗЬ ОТКРЫТЫХ СИСТЕМ

СПРАВОЧНИК

Часть 5

Спецификации протокола

Information technology. Open Systems Interconnection. The directory.
Part 5. Protocol specifications

     
     
ОКС 35.100.70
ОКСТУ 4002

Дата введения 1999-01-01

Предисловие

     
     1 РАЗРАБОТАН Московским научно-исследовательским центром (МНИЦ) Государственного Комитета Российской Федерации по связи и информатизации
     
     ВНЕСЕН Техническим Комитетом по стандартизации ТК 22 "Информационные технологии"
     
     2 ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 19 мая 1998 г. N 215
     
     Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 9594-5-95 "Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 5. Спецификации протокола"
     
     3 ВВЕДЕН ВПЕРВЫЕ
     

Введение

     
     Настоящий стандарт разработан с целью обеспечения взаимосвязи систем обработки информации, предназначенных для предоставления услуг справочника. Совокупность подобных систем вместе с содержащейся в них информацией справочника может рассматриваться как единое целое, называемое справочником. Информация, хранимая справочником и называемая в целом "информационной базой справочника" (ИБС), используется обычно для обеспечения обмена данными между такими объектами, как логические объекты прикладного уровня, персонал, терминалы и дистрибутивные списки.
     
     Справочник играет существенную роль во взаимосвязи открытых систем (ВОС), цель которой состоит в том, чтобы при минимуме технических согласований вне стандартов по ВОС обеспечить взаимосвязь систем обработки информации:
     
     - поставляемых от различных изготовителей;
     
     - использующих различные методы административного управления;
     
     - имеющих различные уровни сложности;
     
     - использующих различные технологии.
     
     Настоящий стандарт определяет сервисные элементы прикладного уровня и прикладной контекст для двух протоколов - протокола доступа к справочнику (ПДС) и протокола системы справочника (ПСС). ПДС обеспечивает доступ к справочнику для осуществления поиска и модификации информации справочника. ПСС обеспечивает сцепление запросов при осуществлении поиска и модификации информации справочника во всех частях распределенной системы справочника, где может храниться информация.
     
     Кроме того, настоящий стандарт определяет сервисные элементы прикладного уровня и прикладные контексты протокола теневой информации справочника (ПТИС) и протокола управления эксплуатационными связями справочника (ПУЭС). ПТИС обеспечивает теневую информацию, хранимую в одном АСС для другого АСС. ПУЭС обеспечивает установление, модификацию и завершение связей между парами АСС при административных взаимоотношениях между АСС (типа теневых или иерархических отношений).
     
     В приложении А приведен модуль АСН.1 для протокола доступа к справочнику, в приложении В - модуль АСН.1 для протокола системы справочника, в приложении С - модуль АСН.1 для протокола теневой информации справочника, в приложении D - модуль АСН.1 для протокола управления эксплуатационными связями справочника, в приложении Е - модуль АСН.1, который содержит все идентификаторы объектов АСН.1, используемые в настоящем стандарте, и в приложении F - модуль АСН.1, который содержит все идентификаторы объектов АСН.1, предназначенные для определения типов эксплуатационных связей, используемых в такого типа стандартах.
     

     1 ОБЛАСТЬ ПРИМЕНЕНИЯ

     
     Настоящий стандарт определяет протокол доступа к справочнику, протокол системы справочника, протокол теневой информации справочника и протокол управления эксплуатационными связями справочника, используемые при выполнении абстрактных услуг, определенных в ИСО/МЭК 9594-3, ИСО/МЭК 9594-4 и ИСО/МЭК 9594-9.
     

     2 НОРМАТИВНЫЕ ССЫЛКИ

     
     В настоящем стандарте использованы ссылки на следующие стандарты:
     
     ГОСТ 34.971-91 (ИСО 8822-88) Системы обработки информации. Взаимосвязь открытых систем. Определение услуг уровня представления для режима с установлением соединения
     
     ГОСТ 34.981-91 (ИСО 8649-88) Системы обработки информации. Взаимосвязь открытых систем. Определение услуг для сервисного элемента управления ассоциацией (СЭУА)
     
     ГОСТ Р ИСО/МЭК 7498-1-95 Информационная технология. Взаимосвязь открытых систем (ВОС). Базовая эталонная модель. Часть 1. Базовая модель
     
     ГОСТ Р ИСО/МЭК 8072-95 Информационная технология. Взаимосвязь открытых систем. Определение услуг транспортного уровня
     
     ГОСТ Р ИСО 8326-95 Информационная технология. Взаимосвязь открытых систем. Определение базовых услуг сеансового уровня в режиме с установлением соединения
     
     ГОСТ Р ИСО/МЭК 8348-96 Информационная технология. Взаимосвязь открытых систем. Определение услуг сетевого уровня*     
_______________
     * В указателе "Государственные стандарты" 2003 г. - ГОСТ Р ИСО 8348/Доп.2-93 Информационная технология. Передача данных. Определение услуг сетевого уровня. Дополнение 2. Адресация на сетевом уровне. - Примечание .
     
     ГОСТ Р ИСО/МЭК 8824-93 Информационная технология. Взаимосвязь открытых систем. Спецификация абстрактно-синтаксической нотации версии один (АСН.1)
     
     ГОСТ Р ИСО/МЭК 9066-1-93 Системы обработки информации. Передача текста. Надежная передача. Часть 1. Модель и определение услуг
     
     ГОСТ Р ИСО/МЭК 9072-1-93 Системы обработки информации. Передача текста. Удаленные операции. Часть 1. Концепции, модель и нотация
     
     ГОСТ Р ИСО/МЭК 9072-2-93 Системы обработки информации. Передача текста. Удаленные операции. Часть 2. Определение услуг*
________________
     * В указателе "Государственные стандарты" 2003 г. - ГОСТ Р ИСО/МЭК 9072-2-93 Системы обработки информации. Передача текста. Удаленные операции. Часть 2. Спецификация протокола. - Примечание .     
     
     ГОСТ Р ИСО/МЭК 9594-7-98 Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 7. Выбранные классы объектов
     
     ИСО/МЭК ПМС 9072-3* Системы обработки информации. Передача текста. Удаленные операции. Часть 3. Реализации ВОС
     
     ИСО/МЭК 9594-2-93* Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 2. Модели
________________
     * Оригиналы стандартов и проектов ИСО/МЭК - во ВНИИКИ Госстандарта России.
     

     ГОСТ Р ИСО/МЭК 9594-3-98 Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 3. Определение абстрактных услуг
     

     ИСО/МЭК 9594-4-93* Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 4. Процедуры распределенных операций
________________
     * Оригиналы стандартов и проектов ИСО/МЭК - во ВНИИКИ Госстандарта России.
     
     ГОСТ Р ИСО/МЭК 9594-6-98 Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 6. Выбранные типы атрибутов
     
     ИСО/МЭК 9594-9-93* Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 9. Дублирование
________________
     * Оригиналы стандартов и проектов ИСО/МЭК - во ВНИИКИ Госстандарта России.
     

     3 ОПРЕДЕЛЕНИЯ

     
     3.1 В настоящем стандарте используются следующие термины, определенные в ГОСТ Р ИСО/МЭК 7498-1:
     
     a) абстрактный синтаксис;
     
     b) прикладной контекст;
     
     c) логический объект прикладного уровня;
     
     d) прикладной процесс;
     
     e) управляющая информация протокола прикладного уровня;
     
     f) протокольный блок данных прикладного уровня;
     
     g) сервисный элемент прикладного уровня.
     
     3.2 В настоящем стандарте используются следующие термины, определенные в ГОСТ Р ИСО/МЭК 9072-1:
     
     a) пакет управления соединением;
     
     b) контракт, контракт ассоциации;
     
     c) ошибка;
     
     d) операция;
     
     e) пакет управления операциями;
     
     f) объект-УУО.
     
     3.3 В настоящем стандарте используются следующие термины, определенные в ИСО/МЭК 9594-2:
     
     a) справочник;
     
     b) пользователь (справочника);
     
     c) агент системы справочника;
     
     d) агент пользователя справочника.
     
     3.4 В настоящем стандарте используются следующие термины, определенные в ИСО/МЭК 9594-4:
     
     a) сцепление;
     
     b) обращение.
     

     4 СОКРАЩЕНИЯ

     5 СОГЛАШЕНИЯ

     
     В настоящем стандарте под понятием "спецификация справочника" следует понимать ГОСТ Р ИСО/МЭК 9594-5, а под понятием "спецификации справочника" - части 1-9 ГОСТ Р ИСО/МЭК 9594.
     
     Если элементы списков пронумерованы (в отличие от использования знаков дефиса "-" или букв), то такие элементы должны рассматриваться как шаги процедуры.
     
     Настоящий стандарт определяет операции справочника, используя нотацию удаленных операций, определенных в ГОСТ Р ИСО/МЭК 9072-1.
     

     6 ОБЩЕЕ ОПИСАНИЕ ПРОТОКОЛА

     
     6.1 Удаленные операции - спецификация и реализация в ВОС
     
     В ГОСТ Р ИСО/МЭК 9072-1 определено несколько классов информационных объектов, которые используются в спецификациях протоколов прикладного уровня, основанных на услугах удаленных операций (УУО) для различных протоколов справочника, определенных в настоящем стандарте. Ряд таких классов используется в данном и в последующих разделах. Методы спецификации, предусмотренные в ГОСТ Р ИСО/МЭК 9072-1, используются для определения родового протокола между объектами. При реализации протокола прикладного уровня ВОС концепции, изложенные в ГОСТ Р ИСО/МЭК 9072-1, преобразуются в концепции ГОСТ Р ИСО/МЭК 9072-2 и ИСО/МЭК ПМС 9072-3.
     
     Класс ROS-OBJECT-CLASS используется для определения ряда общих возможностей набора объектов-УУО в понятиях контрактов (ассоциации), которые они обеспечивают, выполняя роль отправителей и/или ответчиков. Если объект-УУО реализован с использованием услуг обмена данными в ВОС, то он преобразуется в прикладной процесс, а контракт - в прикладной контекст. В таких спецификациях справочника понятие "абстрактная услуга" используется для обращения к контракту ассоциации УУО, а протокол прикладного уровня ВОС - для обращения к реализации контракта между двумя открытыми системами, использующими услуги обмена данными в ВОС.
     
     Класс OPERATION-PACKAGE используется для определения набора операций, которые могут быть привлечены объектом-УУО, выполняющим роль "потребителя", либо набора операций, которые могут быть привлечены объектом-УУО, выполняющим роль "поставщика", либо набора операций, которые могут быть привлечены обоими указанными объектами-УУО. При использовании услуг обмена данными ВОС пакет управления операциями реализуется в виде сервисного элемента прикладного уровня (СЭП).
     
     Класс CONNECTION-PACKAGE используется для определения операций соединения и разъединения, используемых при установлении и освобождении ассоциации. При использовании услуг обмена данными ВОС пакет управления соединением реализуется в виде процедур, использующих услуги сервисного элемента управления ассоциацией.
     
     Класс CONTRACT используется для определения контракта ассоциации в понятиях пакета управления соединениями и одного или нескольких пакетов управления операциями. При определении контрактов, в которых инициатор ассоциации, ответчик ассоциации или любой из них могут принимать роль потребителя, пакеты идентифицируются. При использовании услуг обмена данными ВОС контракт реализуется как прикладной контекст.
     
     Класс APPLICATION-CONTEXT используется для определения статических аспектов прикладного контекста. К ним относятся контракт, реализуемый через прикладной контекст, услуги ВОС, устанавливающие и освобождающие ассоциацию, услуги ВОС, обеспечивающие передачу информации для взаимодействий контрактов, а также используемый абстрактный синтаксис.
     
     Класс ABSTRACT-SYNTAX, построенный на основе АСН.1, используется для определения и присвоения идентификатора объекта типу АСН.1, значения которого включают абстрактный синтаксис.
     
     Протоколы прикладного уровня ВОС, определенные в настоящем стандарте как ПДС, ПСС, ПТИС и ПУЭС, это протоколы, обеспечивающие взаимосвязь между двумя прикладными процессами. В среде ВОС эта взаимосвязь представляется в виде обмена данными между двумя логическими объектами прикладного уровня (ЛОП), использующими услуги уровня представления. Функция ЛОП обеспечивается набором сервисных элементов прикладного уровня. Взаимодействие между ЛОП описано в понятиях использования ими услуг, предоставляемых сервисными элементами прикладного уровня. Все услуги, обеспечиваемые сервисными элементами прикладного уровня справочника, содержатся в одном ЛОП.
     
     Сервисный элемент удаленных операций (СЭУО) поддерживает парадигму запрос-ответ операции. СЭП справочника обеспечивают функцию преобразования абстрактно-синтаксической нотации пакетов управления операциями в услуги, предоставляемые УУО. Сервисный элемент управления ассоциацией (СЭУА) поддерживает установление и освобождение ассоциации прикладного уровня между двумя ЛОП. Ассоциации между АПС и АСС могут быть установлены только АПС. Освободить ассоциацию может только ее инициатор.
     
     Для надежной передачи протокольных блоков данных прикладного уровня (ПБДП) в ПТИС факультативно может быть использован сервисный элемент надежной передачи (СЭНП).
     
     6.2 Объекты-УУО и контракты справочника
     
     ИСО/МЭК 9594-3 определяет абстрактные услуги между АПС и справочником, который обеспечивает пункт доступа для поддержки пользователя, обращающегося к услугам справочника.
     
     Класс "dua" объекта-УУО описывает АПС, который является экземпляром этого класса, в виде инициатора контракта "dapContract". В таких спецификациях справочника на этот контракт ссылаются как на абстрактную услугу справочника. Класс "dua" определен (см. 6.3) в виде информационного объекта УУО.
     

     
     Класс "directory" объекта-УУО описывает поставщика абстрактных услуг справочника. Этот поставщик является ответчиком "darContract".
     

     
     Далее справочник моделируется, как показано на рисунке 1, где АПС представлен агентом АСС, который обеспечивает конкретный пункт доступа. ИСО/МЭК 9594-4 определяет взаимодействия между двумя АСС в пределах справочника, чтобы поддерживать сцепленные запросы пользователя.
     

Рисунок 1 - Взаимодействия справочника

     
     
     Объект "directory" представлен в виде набора взаимодействующих АСС. Каждый АСС, включающий "directory", является элементом класса "dap-dsa". Объект "dap-dsa" выполняет роль ответчика в "dapContract".
     

     
     Кроме взаимодействия с АПС, агенты системы справочника могут взаимодействовать с любым другим объектом для решения различных задач. При таких взаимодействиях должно быть определено число контрактов и объектов-УУО, отражающих способ участия АСС в этих контрактах. Любой реальный АСС может служить примером одного или нескольких таких объектов-УУО АСС.
     
     В общем случае взаимодействия между АСС, необходимые для обеспечения абстрактных услуг справочника при наличии распределенной ИБС, определены как "dspContract". АСС, который участвует в этом контракте, определен как объект-УУО класса "dsp-dsa". Контракт, на который ссылаются в этих спецификациях справочника, определен как абстрактная услуга АСС. АСС определен в виде информационного объекта УУО (см. 6.4).
     

     
     Теневые абстрактные услуги определяют теневую информацию между теневым поставщиком АСС и теневым потребителем АСС. Эти услуги проявляются в двух формах и поэтому определяются как два различных контракта. Они определяются в виде информационных объектов УУО (см. 6.5).
     
     Объект "ShadowConsumerContract" выражает вид услуги, в который теневой потребитель объект-УУО класса "initiating-consumer-dsa" является инициатором контракта. Объект-УУО класса "responding-supplier-dsa" является ответчиком в этом контракте.
     

     Объект "ShadowSupplierContract" выражает форму услуги, в которой теневой поставщик объекта-УУО класса "initiating-supplierdsa" является инициатором контракта.  Объект-ROS класса "responding-consumer-dsa" является ответчиком в этом контракте.

     Взаимодействия между двумя АСС для управления набором эксплуатационных связей определены как "dopContract".
 

     АСС, который участвует в этом контракте, определен как объект-УУО класса "dop-dsa". Этот контракт определен в виде информационного объекта УУО (см. 6.6).
     
     6.3 Контракт и пакеты ПДС
     
     "DapContract" определен в ввиде информационного объекта класса "CONTRACT".

     
     Если АПС и АСС из различных открытых систем взаимодействуют между собой, то такой контракт ассоциации может быть реализован в виде протокола прикладного уровня ВОС, на который в таких спецификациях справочника ссылаются как на протокол доступа к справочнику (ПДС). Определение этого протокола в понятиях прикладного контекста ВОС представлено в 7.2 настоящего стандарта.
     
     "DapContract" составлен из пакета соединений "dapConnectionPackage" и трех пакетов управления операциями "readPackage", "searchPackage" и "modifyPackage".
     
     Пакет управления соединением "dapConnectionPackage" определен как информационный объект класса CONNECTION-PACKAGE. Операции соединения и разъединения этого пакета соединений "directoryBind" и "directoryUnbind" определены в ИСО/МЭК 9594-3.
     

     
     Пакеты управления операциями "read Package", "searchPackage" и "modifyPackage" определены как информационные объекты класса OPERATION-PACKAGE. Операции таких пакетов управления операциями определены в ИСО/МЭК 9594-3.
     

     
     Примечание - Если эти пакеты реализованы в виде СЭП, они используются для создания прикладных контекстов, определенных в настоящем стандарте. Они не ставят своей задачей служить основой для заявки о соответствии отдельному СЭП или любой комбинации СЭП.
     
     
     Поскольку АПС является инициатором "dapContract", он принимает роль потребителя пакетов управления операциями контракта. Это означает, что только АПС может привлечь операции в этом контракте и его реализацию ВОС.
     
     6.4 Контракт и пакеты ПСС
     
     "dsp Contract" определен как информационный объект класса CONTRACT.
     

     
     Если две ACC из различных открытых систем взаимодействуют между собой, то такой контракт ассоциации реализуется как протокол прикладного уровня ВОС, на который в таких спецификациях ссылаются как на протокол системы справочника (ПСС). Определение этого протокола в терминах прикладного контекста ВОС представлено в 7.2 настоящего стандарта.
     
     "DspContract" состоит из пакета управления соединением "dspConnecti-onPackage" и трех пакетов управления операциями "chainedReadPackage", "chainesearchPackage" и "chainedModifyPackage".
     
     Пакет управления соединением "dspConnectionPackage" определен как информационный объект класса CONNECTION-PACKAGE. Он идентичен пакету управления соединением "dapConnectionPackage".
     

     
     Пакеты управления операциями "chainedReadPackage", "chainedSearchPackage" и "chainedModifyPackage" определены как информационные объекты класса OPERATION-PACKAGE. Операции таких пакетов управления операциями определены в ИСО/МЭК 9594-4.
     

     
     Примечание - Если эти пакеты реализованы в виде СЭП, они используются для создания прикладных контекстов, определенных в настоящем стандарте. Они не ставят своей задачей служить основой для заявки о соответствии отдельному СЭП или любой комбинации СЭП.
     
     
     В "dapContract" ACC может принимать роль инициатора, и либо инициирующий, либо отвечающий АСС могут вызвать операции такого контракта.
     
     6.5 Контракты и пакеты ПТИС
     
     "ShadowConsumerContract" и "shadowSupplierContract" определены как информационные объекты класса CONTRACT.
     

     
     Примечание - Понятия "потребитель" и "поставщик", используемые в нотации для классов CONTRACT и OPERATION-PACKAGE, используются для обозначения двух ролей. В ИСО/МЭК 9594-9 эти роли соответствуют двум понятиям - теневой потребитель и теневой поставщик.
     
     
     Реализации в ВОС двух видов абстрактных теневых услуг, называемых в совокупности ПТИС, определены в терминах некоторых прикладных контекстов и представлены в 7.2 настоящего стандарта.
     
     Объекты "ShadowConsumerContract" и "shadowSupplierContract" составлены из общего пакета управления соединением "dispConnectionPackage" и либо пакета управления операциями "shadowConsumerPackage" в первом случае, либо пакета "shadowSupplierPackage" во втором.
     
     Пакет управления соединением "dispConnectionPackage" определен как информационный объект класса CONNECTION-PACKAGE. Он идентичен пакету управления соединением "dapConnectionPackage".
     

     
     Пакеты управления операциями "shadowConsumerPackage" и "shadowSupplierPackage" определены как информационные объекты класса "OPERATION-PACKAGE". Операции таких пакетов управления операциями определены в ИСО/МЭК 9594-9.
     

     
     Поскольку теневой потребитель является инициатором объекта "ShadowConsumerContract", то он принимает роль потребителя "shadowConsumerPackage". Это означает, что теневой потребитель вызывает операцию "requestShadowUpdate", а теневой поставщик - операцию "updateShadow".
     
     Поскольку теневой поставщик является инициатором "shadowSuppli-erConsumerContract", то он принимает роль поставщика "shadowSupp-lierPackage". Это означает, что теневой поставщик привлекает операции контракта.
     
     6.6 Контракт и пакеты ПУЭС
     

     
     Если две АСС из различных открытых систем взаимодействуют между собой, то такой контракт ассоциации реализуется как протокол прикладного уровня ВОС, на который в таких спецификациях ссылаются как на протокол управления эксплуатационными связями (ПУ-ЭС). Определение этого протокола в понятиях прикладного контекста ВОС приведено в 7.2 настоящего стандарта.
     
     Пакет управления соединением "dopConnectionPackage" определен как информационный объект класса CONNECTION-PACKAGE. Он идентичен пакету управления соединением "dapConnectionPackage".
     

     
     Пакет управления операциями "dopPackage" определен как информационный объект класса OPERATION-PACKAGE. Операции таких пакетов управления операциями определены в ИСО/МЭК 9594-2.
     

     
     АСС, который может принимать роль инициатора объекта "dopContract", зависит от ролей, которые АСС может выполнять при административном управлении эксплуатационной(ыми) связью(ями), использующем операции этого контракта. Привлекать операции "dopContract" может только инициатор. С этим контрактом возможно несколько административно управляемых типов эксплуатационных связей, если только роли АСС для различных типов совместимы (например, АСС принимает роль А при любом типе связи).
     
     6.7 Использование нижерасположенных услуг
     
     Протоколы ПДС, ПСС, ПУЭС и ПТИС могут использовать нижерасположенные услуги, как описано ниже.
     
     6.7.1 Использование услуг СЭУО
     
     Сервисный элемент удаленных операций определен в ГОСТ Р ИСО/МЭК 9072-2.
     
     СЭУО поддерживает парадигму запрос-ответ удаленных операций.
     
     СЭП справочника являются пользователями услуг СЭУО УО-ПРИВЛЕЧЕНИЕ, УО-РЕЗУЛЬТАТ, УО-ОШИБКА, УО-Пл-ОТКЛОНЕНИЕ и УО-Пс-ОТКЛОНЕНИЕ
     
     Удаленные операции ПДС и ПСС выполняются в асинхронном режиме. Поскольку АПС является потребителем ПДС, то выбор операций может осуществляться синхронным способом.
     
     Удаленные операции ПТИС должны обеспечиваться синхронными операциями и факультативно могут обеспечиваться асинхронными операциями.
     
     Удаленные операции ПУЭС выполняются в асинхронном режиме.
     
     6.7.2 Использование услуг СЭНП
     
     Сервисный элемент надежной передачи (СЭНП) определен в ИСО/МЭК 9066-1.
     
     СЭНП обеспечивает надежную передачу ПБДП. СЭНП гарантирует, что каждый ПБДП полностью передается только один раз, а об особых случаях отправитель предупреждается. При нарушениях обмена данными и отказе оконечной системы СЭНП восстанавливает и минимизирует количество повторных передач, необходимых для восстановления.
     
     Для обеспечения ПТИС определены альтернативные прикладные контексты с СЭНП и без него.
     
     СЭНП используется в нормальном режиме. Использование нормального режима СЭНП подразумевает использование нормального режима СЭУА и нормального режима услуг уровня представления.
     
     Если СЭНП включен в прикладной контекст, услуга УО-СВЯЗКА преобразуется в услугу СЭНП НП-ОТКРЫТИЕ, а услуга УО-РАЗВЯЗКА - в услугу СЭНП НП-ЗАКРЫТИЕ. Базовые услуги СЭУО являются единственным пользователем услуг СЭНП НП-ПЕРЕДАЧА, НП-ЗАПРОС-ПОЛНОМОЧИЙ, НП-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ, НП-Пс-ПРЕРЫВАНИЕ и НП-Пл-ПРЕРЫВАНИЕ.
     

     6.7.3 Использование услуг СЭУА
     
     Сервисный элемент управления ассоциацией (СЭУА) определен в ГОСТ 34.981.
     
     СЭУА обеспечивает управление (установление, освобождение, аварийное прекращение работы) прикладных ассоциаций между ЛОП.
     
     Если СЭНП включен в прикладной контекст, то он является единственным пользователем услуг СЭУА П-АССОЦИАЦИЯ, П-РАЗЪЕДИНЕНИЕ, П-ПРЕРЫВАНИЕ и П-Пс-ПРЕРЫВАНИЕ.
     
     Если СЭНП не включен в прикладной контекст, услуги УО-СВЯЗКА и УО-РАЗВЯЗКА являются единственными пользователями услуг СЭУА П-АССОЦИАЦИЯ и П-РАЗЪЕДИНЕНИЕ. Прикладной процесс использует услуги СЭУА П-ПРЕРЫВАНИЕ и П-Пс-ПРЕРЫВАНИЕ.
     
     Получение П-ПРЕРЫВАНИЕ или П-Пс-ПРЕРЫВАНИЕ по ассоциации, поддерживающей ПДС, завершает всю обработку запроса. Кроме определенных условий, описанных в ИСО/МЭК 9594-4, это также справедливо для ПСС. Пользователь справочника является ответственным за подтверждение выполнения требуемых модификаций в ИБС.
     
     Получение П-ПРЕРЫВАНИЕ или П-Пс-ПРЕРЫВАНИЕ по ассоциации, поддерживающей ПТИС, описано в ИСО/МЭК 9594-9.
     
     Получение П-ПРЕРЫВАНИЕ или П-Пс-ПРЕРЫВАНИЕ по ассоциации, поддерживающей ПУЭС, описано в ИСО/МЭК 9594-4.
     
     6.7.4 Использование услуг уровня представления
     
     Услуги уровня представления определены в ГОСТ 34.971.
     
     Уровень представления координирует представление (синтаксис) семантики прикладного уровня, которая должна быть заменена.
     
     В нормальном режиме для каждого абстрактного синтаксиса, включенного в прикладной контекст, используется различный контекст уровня представления.
     
     СЭУА является единственным пользователем услуг Пр-СОЕДИНЕНИЕ, Пр-РАЗЪЕДИНЕНИЕ, Пр-Пл-ПРЕРЫВАНИЕ и Пр-Пс-ПРЕРЫВАНИЕ уровня представления.
     
     Если СЭНП включен в прикладной контекст, то он является единственным пользователем следующих услуг уровня представления: Пр-НАЧАЛО-АКТИВНОСТИ, Пр-КОНЕЦ-АКТИВНОСТИ, Пр-ПРЕРЫВАНИЕ-АКТИВНОСТИ, Пр-АННУЛИРОВАНИЕ-АКТИВНОСТИ, Пр-ВОЗОБНОВЛЕНИЕ-АКТИВНОСТИ, Пр-ДАННЫЕ, Пр-МЛАДШАЯ-СИНХРОНИЗАЦИЯ, Пр-Пл-ОСОБОЕ-СООБЩЕНИЕ, Пр-Пс-ОСОБОЕ-СООБЩЕНИЕ, Пр-ЗАПРОС-ПОЛНОМОЧИЙ и Пр-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ.
     
     Если СЭНП не включен в прикладной контекст, СЭУА является единственным пользователем услуги уровня представления Пр-ДАННЫЕ.
     

     Контекст уровня представления, устанавливаемый по умолчанию, восстановление контекста и административное управление контекстом не используются.
     
     6.7.5 Использование услуг нижерасположенного уровня
     
     Услуги сеансового уровня определены в ГОСТ Р ИСО 8326.
     
     Сеансовый уровень структурирует диалог потока информации между оконечными системами.
     
     Если СЭНП включен в прикладной контекст, то уровень представления использует следующие функциональные блоки сеансового уровня: "ядро", "полудуплекс", "особые сообщения", "младшая синхронизация" и "управление активностью".
     
     Если СЭНП не включен в прикладной контекст, уровнем представления используются функциональные блоки сеансового уровня: "ядро" и "полудуплекс".
     
     Услуги транспортного уровня определены в ГОСТ Р ИСО/МЭК 8072. Транспортный уровень обеспечивает межконцевую прозрачную передачу данных по соединению нижерасположенного сетевого уровня.
     
     Выбор класса услуг транспортного уровня, используемых сеансовым уровнем, зависит от требований, предъявляемых к мультиплексированию и восстановлению от ошибок. Обеспечение класса 0 протокола транспортного уровня (отсутствие мультиплексирования) обязательна. Услуга срочной передачи данных транспортного уровня не используется.
     
     Обеспечение других классов протокола факультативно. Класс с мультиплексированием может быть использован при мультиплексировании ПДС или ПСС и других протоколов по одному и тому же соединению сетевого уровня. Класс с восстановлением при ошибках может быть выбран по соединению сетевого уровня с недопустимым коэффициентом необнаруженных ошибок.
     
     Нижерасположенный сетевой уровень, поддерживающий услуги сетевого уровня ВОС, определен в ГОСТ Р ИСО/МЭК 8348.
     
     Адресация на сетевом уровне определена также в ГОСТ Р ИСО/МЭК 8348 (адресация пунктов доступа к услугам сетевого уровня).
     

     7 АБСТРАКТНЫЙ СИНТАКСИС ПРОТОКОЛА СПРАВОЧНИКА

     
     7.1 Абстрактные синтаксисы
     
     Два абстрактных синтаксиса, используемые в протоколах справочника, определены в других стандартах. Абстрактный синтаксис СЭУА "acse-abstract-syntax" необходим для установления ассоциации. Абстрактный синтаксис СЭНП "rtse-abstract-syntax" используется для ПТИС факультативно.
     
     Тип АСН.1, из которого получены значения абстрактных синтаксисов, определяется путем использования типов параметризации ROS { }, Bind { }, Unbind { }, которые определены в ГОСТ Р ИСО/МЭК 9072-1.
     
     Эти абстрактные синтаксисы, как и определенные ниже, должны (как минимум) кодироваться в соответствии с базовыми правилами кодирования АСН.1.
     
     7.1.1 Абстрактный синтаксис ПДС
     
     СЭП справочника, реализующие указанные в 6.3 пакеты управления операциями, используют единственный абстрактный синтаксис "directoryAccessAbstractSyntax". Он определяется в виде информационного объекта класса ABSTRACT-SYNTAX.
     

     
     7.1.2 Абстрактный синтаксис ПСС
     
     СЭП справочника, реализующие указанные в 6.4 пакеты управления операциями, используют единственный абстрактный синтаксис "directorySystembstractSyntax". Он определяется в виде информационного объекта класса ABSTRACT-SYNTAX.
     

     
     7.1.3 Абстрактный синтаксис ПТИС
     
     СЭП справочника реализуют указанные в 6.5 пакеты управления операциями, которые определяются в абстрактном синтаксисе "directoryShadowAbstractSyntax" или "directoryReliableShadowAbstractSyntax" в зависимости от использования СЭНП в прикладном контексте. Эти два абстрактных синтаксиса определяются в виде информационных объектов класса ABSTRACT-SYNTAX.
     

     
     Кроме того, в контекстах применения СЭНП используется следующий абстрактный синтаксис. Он включает абстрактный синтаксис самого СЭНП и абстрактный синтаксис Bind {dSAShadowBind}, a Unbind {dSAShadowUnbind}.
     
     rtseAndShadowBindingAbstractSyntax ABSTRACT-SYNTAX : : = {
     
          ReliableShadowBinding-PDUs
     
          IDENTIFIED BY          id-as-reliableShadowBindingAbstractSyntax }
     
     Типы АСН.1, из которых получены значения абстрактных синтаксисов, определяются путем использования типов параметризации ROS { }, Bind { }, Unbind { }.
     

     
     7.1.4 Абстрактный синтаксис ПУЭС
     
     СЭП справочника, который реализует указанный в 6.5 пакет управления операциями, использует абстрактный синтаксис "directoryOperationalBindingManagementAbstractSyntax". Абстрактный синтаксис определяется в виде информационного объекта класса ABSTRACT-SYNTAX.
     
     directoryOperationalBindingManagementAbstractSyntax ABSTRACT-SYNTAX : : = {
     

     
     7.2 Прикладные контексты справочника
     
     7.2.1 Прикладной контекст доступа к справочнику
     
     "DapContract" реализован как "directoryAccessAC". Этот прикладной контекст определен в виде информационного объекта класса APPLICATION-CONTEXT.
     

     
     7.2.2 Прикладной контекст системы справочника
     
     "DspContract" реализован как "directorySystemAC". Этот прикладной контекст определен в виде информационного объекта класса APPLICATION-CONTEXT.
     

     
     7.2.3 Прикладной контекст теневого справочника
     
     Если АСС поддерживает ПТИС, он должен поддерживать по крайней мере одну теневую роль: поставщика либо потребителя и, кроме того, один из объектов "shadowSupplierInitiatedAC" или "shadowConsumerInitiatedAC". Если АСС поддерживает "shadowSupplierInitiatedAC" для конкретной роли, то он может факультативно поддерживать для той же роли и "reliableShadowSupplierInitiatedAC". Если АСС поддерживает "shadowConsumerInitiatedAC" для конкретной роли, то он может факультативно поддерживать для той же роли и "reliableShadowConsumerInitiatedAC".
     
     7.2.3.1 Начальные контексты теневого поставщика
     
     "ShadowSupplierContract" может быть реализован как "shadowSupplierInitiatedAC". Этот прикладной контекст определен в виде информационного объекта класса APPLICATION-CONTEXT.
     

     
     Этот прикладной контекст требует применения только синхронных операций.
     
     Вариант такого прикладного контекста, который разрешает использование асинхронных операций, идентифицирован как "id-ac-shadowSupplierInitiatedAsynchronosAC".
     
     "ShadowSupplierContract" может быть факультативно реализован как "reliableShadowSupplierInitiatedAC". Этот прикладной контекст определен в виде информационного объекта класса APPLICATION-CONTEXT.
     

     
     7.2.3.2 Начальные контексты теневого потребителя
     
     Объект "shadowConsumerContract" может быть реализован как "shadowConsumerInitiatedAC". Этот прикладной контекст определен в виде информационного объекта класса APPLICATION-CONTEXT.
     

     
     Этот прикладной контекст требует применения только синхронных операций.
     
     Вариант такого прикладного контекста, который разрешает использование асинхронных операций, идентифицирован как "id-ac-shadowConsumerInitiatedAsynchronosAC".
     
     Объект "shadowConsumerContract" может быть факультативно реализован как "reliableShadowConsumerInitiatedAC". Этот прикладной контекст определен в виде информационного объекта класса APPLICATION-CONTEXT.
     

     
     7.2.4 Прикладной контекст управления эксплуатационными связями справочника
     
     "DopContract" реализован как "directoryOperationalBindingManagementAC". Этот прикладной контекст определен в виде информационного объекта класса APPLICATION CONTEXT.
     

     
     7.3 Коды операций
     
     7.3.1 Коды операций для пакетов ПДС и ПСС
     
     Следующие коды операций используются пакетами управления операциями ПДС и ПСС:
     

     
     7.3.2 Коды операций для пакетов ПТИС
     
     Следующие коды операций используются пакетами управления операциями ПТИС:
     

     
     7.3.3 Коды операций для пакетов ПУЭС
     
     Следующие коды операций используются пакетами управления операциями ПУЭС:
     

     
     7.4 Коды ошибок
     
     7.4.1 Коды ошибок для пакетов ПДС и ПСС
     
     Пакеты управления операциями ПДС и ПСС используют следующие коды ошибок: "id-errcode-referral" - только в ПДС; "id-opcode-dsaRereferral" - только в ПСС.
     
     7.4.2 Коды ошибок для пакетов ПТИС
     
     Пакеты управления операциями ПТИС используют следующие коды ошибок:
     
     id-errcode-shadowError                           Code : : = local : 1
     
     7.4.3 Коды ошибок для пакетов ПУЭС
     
     Пакеты управления операциями ПУЭС используют следующие коды ошибок:
     
     id-err-operationalBindingError                 Code : : = local : 100
     
     7.5 Версии и правила расширяемости
     
     Справочник может быть распределен, и тогда для обслуживания запроса могут взаимодействовать более двух логических объектов прикладного уровня справочника. СЭП справочника могут быть приспособлены к различным изданиям спецификаций услуг справочника, которые могут быть представлены или не представлены различными номерами версий протокола. Номер версии согласуется с последним номером общей версии между двумя непосредственно связанными ЛОП справочника.
     
     Примечание - В настоящее время существует только одна версия каждого протокола справочника. Издания 1988 и 1993 гг. имеют одинаковую версию. Упомянутая выше процедура определена для более позднего издания спецификации справочника как новая версия.
     
     
     АПС может выдать запрос, как определено в самом последнем издании спецификации справочника, в которой был реализован АСС. Использование определенных ниже правил расширяемости таково, что запрос должен быть передан соответствующему АСС, который должен отвечать на него независимо от изданий других участвующих АСС. Отвечающий АСС должен функционировать как определено ниже.
     
     Примечание - Промежуточный АСС, который только сцепляет запрос, может выбрать для рассмотрения определенные элементы ПБДП справочника, необходимые для выполнения своей функции, например, присвоение имени.
     
     
     7.5.1 АПС к АСС
     
     7.5.1.1 Согласование версии
     

     При принятии ассоциации, то есть при связке с использованием ПДС, согласование версии должно влиять только на двухпунктовые аспекты протокола, имеющие отношение к обмену между АПС и соответствующим АСС, с которым связан данный АСС. Согласованная версия не должна ограничивать последующие запросы или ответы в ассоциации.
     
     Примечание - Других каких-либо двухпунктовых аспектов ПДС, которые в настоящее время указывались бы различными версиями протокола, не существует.
     
     
     7.5.1.2 Обработка запроса и ответа
     
     АПС может инициировать запросы, используя самое последнее издание спецификации, запрос которого она поддерживает. Если один или несколько элементов запроса критичны, то АПС должен указывать номер(а) расширения в параметре criticalExtensions.
     
     Примечание - Если информация расширения заменена в типе CHOICE, ENUMERATED или INTEGER (использованный как ENUMERATED), то тип будет существен для соответствующей операции в АСС, реализованном согласно более раннему изданию спецификации. Рекомендуется, чтобы расширение было отмечено как критическое.
     
     
     При обработке запроса от АПС АСС должен выполнять правила, определенные в 7.5.2.2.
     
     При обработке ответа АПС должен:
     
     а) игнорировать все неизвестные присвоения имен битов в строке битов;
     
     b) игнорировать все неизвестные поименованные номера в типе ENUMERATED или INTEGER, который используется в перечисленном стиле при условии, что номер представлен в виде факультативного элемента SET или SEQUENCE;
     
     c) игнорировать все неизвестные элементы в SET, в конце SEQUENCE или в CHOICE, где CHOICE сам является факультативным элементом SET или SEQUENCE.
     
     Примечание - Реализации могут в качестве локального решения игнорировать определенные дополнительные элементы в ПБД справочника. В частности, некоторые неизвестные поименованные номера и неизвестные CHOICE в обязательных элементах SET и SEQUENCE могут быть проигнорированы, не делая операцию недействительной. Идентификация таких элементов является предметом дальнейшего изучения;
     
     

     d) не рассматривать получение неизвестных типов атрибутов и их значений как нарушение протокола;
     
     е) факультативно сообщать пользователю неизвестные типы атрибутов и их значения.
     
     7.5.1.3 Правила расширяемости при обработке ошибок
     
     При обработке известного типа ошибки с неизвестными обозначенными проблемами и параметрами АПС должен:
     
     a) не рассматривать получение неизвестных обозначенных проблем и параметров как нарушение протокола (то есть он не должен выдавать RO-Пл-REJECT или прерывать прикладную ассоциацию) и
     
     b) факультативно сообщать пользователю дополнительную информацию об ошибке.
     
     При обработке неизвестного типа ошибки АПС должен:
     
     a) не рассматривать получение неизвестного типа ошибки как нарушение протокола (то есть он не должен выдавать RO-Пл-REJECT или прерывать прикладную ассоциацию) и
     
     b) факультативно сообщать пользователю об ошибке.
     
     7.5.2 АСС к АСС
     
     7.5.2.1 Согласование версии
     
     При установлении или принятии ассоциации, то есть связки с использованием ПСС, согласование версии должно влиять только на те двухпунктовые аспекты протокола, которые относятся к обмену между АСС. Согласованная версия не должна ограничивать последующие запросы или ответы в ассоциации.
     
     Примечание - Не существует двухпунктовых аспектов ПСС, которые в настоящее время обозначены различными версиями протокола.
     
     
     При установлении или принятии ассоциации, то есть связки с использованием ПТИС, согласование версии должно определять все аспекты протокола, имеющие отношение к обмену между АСС.
     
     Примечание - В настоящее время существует только одна версия протокола ПТИС.
     
     
     При установлении или принятии ассоциации, то есть связки с использованием ПУЭС, согласование версии должно определять все аспекты протокола, относящиеся к обмену между АСС. Согласованная версия не должна ограничивать последующие запросы или ответы в ассоциации.
     
     Примечание - В настоящее время существует только одна версия протокола ПУЭС.
     
     

     7.5.2.2 Правила расширяемости при обработке операций
     
     Если какой-либо АСС, выполняющий операцию (после завершения присвоения имен) определяет элемент criticalExtensions, семантика которого неизвестна, он должен передать обратно признак unavailableCriticalExtension в виде serviceError или в PartialOutcomeQualifier.
     
     Примечание - При получении строки criticalExtensions с одним или несколькими нулевыми значениями это указывает на то, что расширения, соответствующие значениям, не представлены в операции или некритичны. Наличие нулевых значений в строке criticalExtensions не должно быть выведено как наличие или отсутствие соответствующего расширения в ПБДП.
     
     
     В противном случае при обработке ПБД справочника АСС должен:
     
     a) игнорировать все неизвестные присвоения имен битов в строке битов;
     
     b) игнорировать все неизвестные поименованные номера в типе ENUMERATED или типе INTEGER, который используется в перечисленном стиле, при условии, что номер представлен в виде факультативного элемента SET или SEQUENCE;
     
     с) игнорировать все неизвестные элементы в SET, в конце SEQUENCE или в CHOICE, где CHOICE сам является факультативным элементом SET или SEQUENCE.
     
     Примечание - Реализации могут в качестве локального решения игнорировать определенные дополнительные элементы в ПБД справочника. В частности, некоторые неизвестные поименованные номера и неизвестные CHOICE в обязательных элементах SET и SEQUENCE могут быть проигнорированы, не делая операцию недействительной. Идентификация таких элементов является предметом дальнейшего изучения.
     
     
     7.5.2.3 Правила расширяемости при формировании цепочки
     
     Если ПБД является запросом, АСС должен передавать запрос, содержащий неизвестные типы и значения, любому дополнительному АСС, определенному в результате присвоения имени.
     
     Если ПБД является ответом, АСС должен обрабатывать неизвестные типы и значения, как если бы он обрабатывал известные типы и значения (см. результаты объединения в спецификации справочника на распределенных операциях) и продвигать их к инициирующему АСС или АПС.
     
     7.5.2.4 Правила расширяемости при обработке ошибок
     

     При обработке известного типа ошибок с неизвестными обозначенными проблемами и параметрами АСС:
     
     a) не должен рассматривать получение неизвестных обозначенных проблем и параметров как нарушение протокола (то есть он не должен выдавать УО-Пл-ОТКЛОНЕНИЕ или прерывать прикладную ассоциацию) и
     
     b) может попытаться восстановить соответствующий своему пониманию именно этот тип ошибки или передать эту ошибку (и неизвестные для себя обозначенные проблемы и параметры) следующему соответствующему АСС или АПС.
     
     При обработке неизвестного типа ошибки АСС, который только участвует в формировании цепочки запросов, должен:
     
     а) не рассматривать неизвестный тип ошибки как нарушение протокола (то есть он не должен выдавать УО-Пл-ОТКЛОНЕНИЕ или прерывать прикладную ассоциацию);
     
     b) не пытаться корректировать или восстанавливать ошибки и своих обозначенных проблем и параметров;
     
     с) передавать неизвестный тип ошибки следующему соответствующему АСС или АПС.
     
     При обработке неизвестной ошибки АСС, который коррелирует групповые ответы, должен:
     
     a) не рассматривать неизвестный тип ошибки как нарушение протокола (то есть он не должен выдавать УО-Пл-ОТКЛОНЕНИЕ или прерывать прикладную ассоциацию);
     
     b) не пытаться корректировать или восстанавливать ошибки и своих обозначенных проблем и параметров;
     
     c) занести неизвестную ошибку в PartialOutcomeQualifier и
     
     d) продолжить корреляцию результатов в обычном режиме.
     

     8 ПРЕОБРАЗОВАНИЕ В ИСПОЛЬЗУЕМЫЕ УСЛУГИ

     
     Этот раздел определяет преобразование ПДС, ПСС, ПУЭС и ПТИС в используемые услуги. Преобразование ПДС, ПСС и ПУЭС, а также тех прикладных контекстов ПТИС, которые не содержат СЭНП, определено в 8.1. Преобразование прикладных контекстов ПТИС, использующих СЭНП, определено в 8.2.
     
     8.1 Прикладные контексты, не использующие СЭНП
     
     В этом подразделе определяется преобразование прикладных контекстов ПДС, а также тех прикладных контекстов ПТИС, которые не содержат СЭНП, в используемые услуги.
     
     8.1.1 Преобразование в СЭУА
     
     Ниже определяется преобразование услуг (DirectoryBind, DSABind, DSAShadowBind или DSADOPBind) и (DirectoryUnbind, DSAUnbind, DSAShadowUnbind или DSADOPUnbind) в услуги СЭУА. СЭУА определен в ГОСТ 34.981.
     
     8.1.1.1 Преобразование Bind в П-АССОЦИАЦИЯ
     
     Услуги DirectoryBind, DSABind, DSAShadowBind или DSADOPBind преобразуются в услугу СЭУА П-АССОЦИАЦИЯ. Использование параметров услуги П-АССОЦИАЦИЯ уточняется в следующих подпунктах.
     
     8.1.1.1.1 Режим
     
     Этот параметр должен устанавливаться инициатором ассоциации в примитиве П-АССОЦИАЦИЯ запрос и иметь значение "нормальный режим".
     
     8.1.1.1.2 Имя прикладного контекста
     
     Инициатор ассоциации должен предоставлять один из следующих прикладных контекстов:
     
     a) для ПДС - directoryAccessAC;
     
     b) для ПСС - directorySystemAC;
     
     c) для ПУЭС - directoryOperationalBindihgManagementAC;
     
     d) для ПТИС - shadowSupplierlnitiatedAC или shadowConsumerlnitiatedAC.
     
     8.1.1.1.3 Информация пользователя  
     
     Преобразование услуги DirectoryBind или DSABind в параметры "информация пользователя" примитива П-АССОЦИАЦИЯ запрос определено ГОСТ Р ИСО/МЭК 9072-1.
     
     8.1.1.1.4 Список определений контекста уровня представления
     
     Инициатор ассоциации должен установить список определений контекста уровня представления в примитиве П-АССОЦИАЦИЯ запрос, который должен содержать абстрактный синтаксис СЭУА (id-as-acse) и один из следующих абстрактных синтаксисов: ПДС (id-as-directoryAccessAS), ПСС (id-as-directorySystemAS), ПУЭС (idws-directoryOperationalBindingManagementAS) или ПТИС (id-asMirec-toryShadowAS).
     
     8.1.1.1.5 Качество услуг
     

     Этот параметр должен устанавливаться инициатором ассоциации в примитиве П-АССОЦИАЦИЯ запрос и ответчиком ассоциации в примитиве П-АССОЦИАЦИЯ ответ. Параметры "управление расширением" и "оптимизированная диалоговая передача" должны быть установлены в значение "возможность не требуется". Остальные параметры должны быть установлены таким образом, чтобы использовались значения по умолчанию.
     
     8.1.1.1.6 Требования сеансового уровня
     
     Этот параметр должен устанавливаться инициатором ассоциации в примитиве П-АССОЦИАЦИЯ запрос и ответчиком ассоциации в примитиве П-АССОЦИАЦИЯ ответ. Этот параметр устанавливается для определения функциональных блоков "ядро" и "полудуплекс".
     
     8.1.1.1.7 Наименование ЛОП и адрес на уровне пpедставления
     
     Эти параметры должны устанавливаться инициатором и ответчиком ассоциации (наименование ЛОП устанавливается факультативно).
     
     Для АПС, устанавливающего ассоциацию по начальному запросу, эти параметры могут быть получены из локально хранимой информации.
     
     Для АПС (или АСС), устанавливающего ассоциацию с АСС, к которому он обращается, эти параметры могут быть получены из значения атрибута AccessPoint в Continuation Reference.
     
     Для АСС, устанавливающего ассоциацию, этот параметр может быть получен из известной ему информации, то есть из внешнего указателя.
     
     8.1.1.2 Unbind в П-РАЗЪЕДИНЕНИЕ
     
     Услуги DirectoryUnbind, DSAUnbind, DSAShadowUnbind или DSADOPUnbind преобразуются в услугу СЭУА П-РАЗЪЕДИНЕНИЕ. Использование параметров услуги П-РАЗЪЕДИНЕНИЕ описано в следующем подпункте.
     
     8.1.1.2.1 Результат
     
     Этот параметр должен иметь значение "подтверждение".
     
     8.1.1.3 Использование услуг П-ПРЕРЫВАНИЕ и П-Пс-ПРЕРЫВАНИЕ
     
     Прикладной процесс является пользователем услуг СЭУА П-ПРЕРЫВАНИЕ и П-Пс-ПРЕРЫВАНИЕ.
     
     8.1.2 Преобразование в СЭУО
     
     Услуги СЭП справочника преобразуются в услуги СЭУО УО-ПРИВЛЕЧЕНИЕ, УО-РЕЗУЛЬТАТ, УО-ОШИБКА, УО-Пл-ОТКЛОНЕНИЕ и УО-Пс-ОТКЛОНЕНИЕ. Преобразование нотации абстрактного синтаксиса сервисных элементов прикладного уровня справочника в услуги СЭУО осуществляется в соответствии с ГОСТ Р ИСО/МЭК 9072-1.
     
     8.2 Прикладные контексты, содержащие СЭНП
     

     В этом подразделе определено преобразование прикладных контекстов ПТИС, содержащих СЭНП, в используемые услуги. Обеспечение этого преобразования определяется заявкой о соответствии этим прикладным контекстам. СЭНП определен в ГОСТ Р ИСО/МЭК 9066-1.
     
     8.2.1 Преобразование в услуги НП-ОТКРЫТИЕ и НП-3АКРЫТИЕ
     
     Ниже определяется преобразование услуг DSAShadowBind и DSAShadowUnbind в услуги СЭНП НП-ОТКРЫТИЕ и НП-ЗАКРЫТИЕ.
     
     8.2.1.1 Преобразование DSAShadowBind в НП-ОТКРЫТИЕ
     
     Услуга DSAShadowBind преобразуется в услугу СЭНП НП-ОТКРЫТИЕ. Использование параметров услуги НП-ОТКРЫТИЕ описывается ниже.
     
     8.2.1.1.1 Режим
     
     Этот параметр должен устанавливаться инициатором ассоциации в примитиве НП-ОТКРЫТИЕ запрос и иметь значение "нормальный режим".
     
     8.2.1.1.2 Имя прикладного контекста
     
     Инициатор ассоциации должен предлагать в примитиве НП-ОТКРЫТИЕ запрос либо прикладной контекст reliableShadowSupplierInitiatedAC, либо прикладной контекст reliableShadowConsumerInitiatedAC.
     
     8.2.1.1.3 Данные пользовaтеля
     
     Преобразование операции связки в параметре "данные пользователя" примитива НП-ОТКРЫТИЕ запрос определено в ГОСТ Р ИСО/МЭК 9072-1.
     
     8.2.1.1.4 Список определений контекста уровня представления
     
     Инициатор ассоциации должен установить список определений контекста уровня представления в примитиве НП-ОТКРЫТИЕ запрос, который должен содержать абстрактный синтаксис СЭУА (id-as-acse) и абстрактный синтаксис ПТИС, включающий СЭНП (id-as-directoryReliableShadowAS).
     
     8.2.1.1.5 Начальный цикл
     
     Этот параметр должен быть установлен инициатором ассоциации в примитиве НП-ОТКРЫТИЕ запрос и должен быть равен значению "association-initiator".
     
     8.2.1.1.6 Наименование ЛОП и адрес на уровне представления
     
     Эти параметры должны устанавливаться инициатором и ответчиком ассоциации НП-ОТКРЫТИЕ (наименование ЛОП устанавливается факультативно).
     
     8.2.1.2 Преобразование DSAShadowUnbind в НП-ЗАКРЫТИЕ
     
     Услуга DSAShadowUnbind преобразуется в услугу СЭНП НП-ЗАКРЫТИЕ.
     

     8.2.2 Преобразование в СЭУО
     
     Услуги ShadowSupplierASE и shadowConsumerASE преобразуются в услуги СЭУО УО-ПРИВЛЕЧЕНИЕ, УО-РЕЗУЛЬТАТ, УО-ОШИБКА, УО-Пл-ОТКЛОНЕНИЕ и УО-Пс-ОТКЛОНЕНИЕ. Преобразование нотации абстрактного синтаксиса таких СЭП ПТИС в услуги СЭУО осуществляется в соответствии с ГОСТ Р ИСО/МЭК 9072-1.
     
     СЭУО является пользователем услуг СЭНП НП-ПЕРЕДАЧА, НП-ЗАПРОС-ПОЛНОМОЧИЙ, НП-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ, НП-Пс-ПРЕРЫВАНИЕ и НП-Пл-ПРЕРЫВАНИЕ. Использование услуг СЭНП СЭУО определено в ГОСТ Р ИСО/МЭК 9072-2.
     
     8.2.2.1 Управление полномочиями
     
     ГОСТ Р ИСО/МЭК 9072-2 определяет использование сервисным элементом удаленных операций услуг СЭНП НП-ЗАПРОС-ПОЛНОМОЧИЙ и НП-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ для управления полномочиями.
     
     Параметр "приоритет" услуги НП-ЗАПРОС-ПОЛНОМОЧИЙ, используемой сервисным элементом удаленных операций для запроса полномочий, имеет значение:
     
     ноль - наивысший приоритет, зарезервированный для освобождения ассоциации инициатором;
     
     единица - используется СЭУО для обеспечения своих услуг УО-Пл-ОТКЛОНЕНИЕ и УО-ОШИБКА;
     
     два - используется СЭУО для обеспечения своей услуги УО-РЕЗУЛЬТАТ;
     
     три - используется СЭУО для обеспечения своей услуги УО-ПРИВЛЕЧЕНИЕ.
     

     9 СООТВЕТСТВИЕ

     
     В этом разделе устанавливаются требования к соответствию настоящему стандарту.
     
     9.1 Требования к соответствию, предъявляемые АПС
     
     Реализация АПС, претендующая на соответствие настоящему стандарту, должна удовлетворять требованиям 9.1.1-9.1.3.
     
     9.1.1 Требования к заявке
     
     Должно быть указано следующее:
     
     a) операции прикладного контекста directoryAccessAC, которые способен привлечь АПС и соответствие которым заявлено;
     
     b) уровень(и) защиты, соответствие которому(ым) заявлено (отсутствует, простая, строгая);
     
     c) расширения, перечисленные в таблице 7.3.1 ИСО/МЭК 9594-3, которые АПС способен инициировать и соответствие которым заявлено.
     
     9.1.2 Статические требования
     
     АПС должен:
     
     a) обладать способностью обеспечивать прикладной контекст directoryAccessAC, определенный его абстрактным синтаксисом в разделе 7;
     
     b) выполнять расширения, соответствие которым заявлено в 9.1.1 с).
     
     9.1.3 Динамические требования
     
     АПС должен:
     
     a) соответствовать преобразованию в используемые услуги, определенные в разделе 8;
     
     b) соблюдать правила процедур расширения, определенные в 7.5.1.
     
     9.2 Требования к соответствию, предъявляемые АСС
     
     Реализация АСС, претендующая на соответствие настоящему стандарту, должна удовлетворять требованиям 9.2.1-9.2.3.
     
     9.2.1 Требования к заявке
     
     Должно быть указано следующее.
     
     a) Прикладные контексты, соответствие которым заявлено: directoryAccessAC, directorySystemAC, directoryOperationalBindingManagementAC или их комбинации. АСС, претендующий на соответствие атрибуту directoryOperationalBindingManagementAC в обеспечение иерархических эксплуатационных связей, должен обеспечивать также directorySystemAC. Если сведения об АСС рассредоточены, что вызывает необходимость обращаться к АСС, расположенным в других АСС вне своего собственного административного региона справочника (АРС), должно быть заявлено соответствие атрибуту directorySystemAC.
     
     Примечание - Прикладной контекст не должен разделяться, за исключением указанного здесь разделения; в частности, не должно заявляться соответствие конкретным операциям.
     

     
     b) Эксплуатационные типы связей, соответствие которым заявлено - shadowOperationalBindingID, specificHierarchicalBindingID, non-specificHierarchicaIBindingID или их комбинации. АСС, претендующий на соответствие атрибуту shadowOperationalBindingID, должен поддерживать один или несколько прикладных контекстов теневых поставщиков и/или теневых потребителей, указанных в 9.3 и 9.4.
     
     c) Способность АСС функционировать в качестве АСС первого уровня, как определено в ИСО/МЭК 9594-4.
     
     d) Обеспечение режима сцепления операций согласно ИСО/МЭК 9594-4, если заявлено соответствие прикладному контексту directorySystemAC.
     
     e) Уровень(и) защиты, соответствие которому(ым) заявлено (отсутствует, простая, строгая).
     
     f) Выбранные типы атрибута, определенные в ИСО/МЭК 9594-6, и любые другие типы атрибутов, соответствие которым заявлено, а также соответствие атрибутов, основанных на синтаксисе directoryString, выбору UNIVERSAL STRING.
     
     g) Выбранные классы объектов, определенные в ГОСТ Р ИСО/МЭК 9594-7, и любые другие классы объектов, соответствие которым заявлено.
     
     h) Расширения, перечисленные в таблице 7.3.1 ИСО/МЭК 9594-3, при которых АСС способен быть отвечающим, соответствие которому заявлено.
     
     i) Соответствие общим атрибутам согласно 8.8 ИСО/МЭК 9594-2 и 7.6, 7.8.2, 9.2.2 ИСО/МЭК 9594-3.
     
     j) Соответствие иерархическим атрибутам согласно 7.6, 7.8.2 и 9.2.2 ИСО/МЭК 9594-3.
     
     k) Типы эксплуатационных атрибутов, определенные в ИСО/МЭК 9594-2, и любые другие типы эксплуатационных атрибутов, соответствие которым заявлено.
     
     l) Соответствие для передачи псевдонимов согласно 7.7.1 ИСО/МЭК 9594-3.
     
     m) Соответствие выдаче указания о том, что передача информации записи завершена согласно 7.7.6 ИСО/МЭК 9594-3.
     
     n) Соответствие модификации атрибута класса объекта с точки зрения добавлений и/или перемещений значений, идентифицирующих вспомогательные классы объектов согласно 11.3.2.
     
     о) Соответствие базовому управлению доступом.
     
     р) Соответствие упрощенному управлению доступом.
     

     q) Способность АСС осуществлять административное управление подсхемой своей части ДИС согласно ИСО/МЭК 9594-2.
     
     Примечание - Способности административного управления подсхемой не должны разделяться; в частности, не должна заявляться способность административного управления конкретными определениями подсхемами.
     
     
     r) Выбранные поименованные связи, определенные в ГОСТ Р ИСО/МЭК 9594-7, и любые другие поименованные связи, соответствие которым заявлено.
     
     s) Способность АСС к административному управлению общими атрибутами согласно ИСО/МЭК 9594-2.
     
     9.2.2 Статические требования
     
     АСС должен:
     
     a) поддерживать прикладные контексты, соответствие которым заявлено, согласно определению их абстрактного синтаксиса в разделе 7;
     
     b) поддерживать информационную структуру, определенную абстрактным синтаксисом ИСО/МЭК 9594-2;
     
     c) соответствовать требованиям минимальных сведений, определенным в ИСО/МЭК 9594-4;
     
     d) обеспечивать требования корневого контекста согласно ИСО/МЭК 9594-4, если заявлено соответствие АСС первого уровня;
     
     e) обеспечивать типы атрибутов, соответствие которым заявлено, согласно их абстрактному синтаксису;
     
     f) обеспечивать классы объектов, соответствие которым заявлено согласно их абстрактному синтаксису;
     
     g) обеспечивать расширения, соответствие которым заявлено в 9.2.1h;
     
     h) осуществлять административное управление подсхемой, если заявлено соответствие такой способности согласно ИСО/МЭК 9594-2;
     
     i) выполнять соответствующие процедуры, определенные в 7.6, 7.8.2 и 9.2.2 ИСО/МЭК 9594-3, если заявлено соответствие общим атрибутам;
     
     j) выполнять соответствующие процедуры, определенные в 7.6, 7.8.2 и 9.2.2 ИСО/МЭК 9594-3, если заявлено соответствие иерархическим атрибутам;
     
     k) поддерживать типы эксплуатационных атрибутов, соответствие которым заявлено;
     
     l) сохранять элементы информации управления доступом, отвечающих определениям базового управления доступом, если заявлено соответствие базовому управлению доступом;
     
     m) сохранять элементы информации управления доступом, отвечающих определениям упрощенного управления доступом, если заявлено соответствие упрощенному управлению доступом.
     

     9.2.3 Динамические требования
     
     АСС должен:
     
     a) соответствовать преобразованию в используемые услуги, определенные в разделе 8 настоящего стандарта;
     
     b) соответствовать процедурам распределенных операций справочника при обращении к нему согласно ИСО/МЭК 9594-4;
     
     c) соответствовать процедурам ИСО/МЭК 9594-4, относящимся к режиму обращения ПДС, если заявлено соответствие прикладному контексту directoryAccessAC;
     
     d) соответствовать режиму обращения при взаимодействии согласно ИСО/МЭК 9594-4, если заявлено соответствие прикладному контексту directorySystemAC;
     
     e) соответствовать режиму сцепления при взаимодействии согласно ИСО/МЭК 9594-4, если заявлено соответствие режиму сцепления при взаимодействии.
     
     Примечание - В этом случае необходимо только, чтобы АСС был способен привлекать операции directorySystemAC;
     
     
     f) соблюдать правила процедур расширяемости, определенные в 7.5.2;
     
     g) обладать возможностью защиты информации в пределах АСС в соответствии с процедурами базового управления доступом, если заявлено соответствие базовому управлению доступом;
     
     h) обладать возможностью защиты информации в пределах АСС в соответствии с процедурами упрощенного управления доступом, если заявлено соответствие упрощенному управлению доступом;
     
     i) соответствовать процедурам, определенным в ИСО/МЭК 9594-9 и ИСО/МЭК 9594-2 относительно ПЭУС, если заявлено соответствие атрибуту shadowOperationalBindingID;
     
     j) соответствовать процедурам, определенным в ИСО/МЭК 9594-9 и ИСО/МЭК 9594-2 относительно конкретных иерархических эксплуатационных связей, если заявлено соответствие атрибуту specificHierarchicalBindingID;
     
     k) соответствовать процедурам, определенным в ИСО/МЭК 9594-9 и ИСО/МЭК 9594-2 относительно неопределенных иерархических эксплуатационных связей, если заявлено соответствие атрибуту non-specificHierarchicalBindingID.
     
     9.3 Требования соответствия, предъявляемые теневым поставщиком
     
     Реализация АСС, претендующая на соответствие настоящему стандарту и выступающая в роли теневого поставщика, должна удовлетворять требованиям 9.3.1-9.3.3.
     

     9.3.1 Требования к заявке
     
     Должно быть указано следующее:
     
     a) прикладной(ые) контекст(ы), соответствие которому(ым) заявлено как для теневого поставщика: shadowSupplierInitiatedAC, shadowConsumerInitiatedAC, reliableShadowSupplierInitiatedAC и reIiableShadowConsumerInitiatedAC.
     
     Реализация АСС должна как минимум обеспечивать либо shadowSupplierInitiatedAC, либо shadowConsumerInitiatedAC. Если АСС поддерживает shadowSupplierInitiatedAC, он может факультативно поддерживать reliableShadowSupplierInitiatedAC. Если АСС поддерживает shadowConsumerInitiatedAC, он может факультативно поддерживать reliableShadowConsumerInitiatedAC;
     
     b) уровень(и) защиты, соответствие которому(ым) заявлено (отсутствует, простая, строгая);
     
     c) в какой степени обеспечивается UnitOfReplication, в частности, какая (при наличии) из следующих факультативных особенностей обеспечивается:
     
     - фильтрование записи на ObjectClass;
     
     - выбор/исключение атрибутов с помощью AttributeSelection;
     
     - включение сведений подчиненного в область для копирования;
     
     - включение расширенных сведений дополнительно к сведениям подчиненного.
     
     9.3.2 Статические требования
     
     АСС должен:
     
     a) обеспечивать прикладной(ые) контекст(ы), соответствие которому(ым) заявлено согласно определениям в их абстрактном синтаксисе в разделе 7;
     
     b) обеспечивать эксплуатационные атрибуты modifyTimestamp и createTimestamp.
     
     9.3.3 Динамические требования
     
     АСС должен:
     
     a) соответствовать преобразованиям в используемые услуги, определенные в разделе 8 настоящего стандарта;
     
     b) соответствовать процедурам, определенным ИСО/МЭК 9594-9 относительно ПТИС.
     
     9.4 Требования к соответствию, предъявляемые теневым потребителем
     
     Реализация АСС, претендующая на соответствие настоящему стандарту и являющаяся теневым потребителем, должна удовлетворять требованиям, перечисленным в 9.4.1-9.4.3.
     
     9.4.1 Требования к заявке
     
     Должно быть указано следующее:
     

     a) прикладной(ые) контекст(ы), соответствие которому(ым) заявлено как для теневого поставщика: shadowSupplierInitiatedAC, shadowConsumerInitiatedAC, reliableShadowSupplierInitiatedAC и reliableShadowConsumerInitiatedAC.
     
     Реализация АСС как минимум должна обеспечивать либо shadowSupplierInitiatedAC, либо shadowConsumerInitiatedAC. Если АСС обеспечивает shadowSupplierInitiatedAC, он может факультативно обеспечивать reliableShadowSupplierInitiatedAC. Если АСС обеспечивает shadowConsumerInitiatedAC, он может факультативно обеспечивать reliableShadowConsumerInitiatedAC;
     
     b) уровень(и) защиты, соответствие которому(ым) заявлено (отсутствует, простая, строгая);
     
     с) способность АСС действовать в качестве вторичного теневого поставщика (то есть участвовать во вторичном затенении в качестве промежуточного АСС);
     
     d) способность АСС обеспечивать затенение перекрывающихся блоков, подлежащих копированию.
     
     9.4.2 Статические требования
     
     АСС должен:
     
     a) обеспечивать прикладной(ые) контекст(ы), соответствие которому(ым) заявлено, как определено их абстрактным синтаксисом в разделе 7;
     
     b) обеспечивать эксплуатационные атрибуты modifyTimestamp и createTimestamp, если обеспечиваются перекрывающиеся блоки, подлежащие копированию;
     
     c) обеспечивать сервисное управление copyShallDo.
     
     9.4.3 Динамичеcкие требования
     
     АСС должен:
     
     a) соответствовать преобразованиям в используемые услуги, определенные в разделе 8 настоящего стандарта;
     
     b) соответствовать процедурам, определенным ИСО/МЭК 9594-9, относительно ПТИС.
     

ПРИЛОЖЕНИЕ А
(обязательное)

ПРОТОКОЛ ДОСТУПА К СПРАВОЧНИКУ В АСН.1

     
     В данном приложении приведены определения всех типов и значений АСН.1, содержащихся в настоящем стандарте, в виде модуля АСН.1 "DirectoryAccessProtocol".
     
     DirectoryAccessProtocol fjoint-iso-ccitt ds{5} module{1} dap{11} 2}
     
     DEFINITIONS : : =
     
     BEGIN
     
     - EXPORTS All -
     

     
     IMPORTS
     
     directoryAbstractService, protocolObjectIdentifiers
     
          FROM UsefulDefinitions {joint-iso-ccitt ds(5) module(1)
     
                         usefulDefinitions(0) 2}
     
     ROS-OBJECT-CLASS, CONTRACT, OPERATION-PACKAGE, CONNECTION-PACKAGE, Code, OPERATION
     

     
id-acDirectoryAccessAC, id-rosObject4ua, id-rosObject-directory, id-rosObject-dapDSA, ideontract4ap, id-package-dapConnection, id-package-read, id-package-search, id-package-modify, id-as-directoryAccessAS
     
     FROM ProtocolObjectIdentifiers protocolObjectIdentifiers
     
directoryBind, directoryUnbind, read, compare, abandon, list, search, addEntry, removeEntry, modifyEntry, modifyDN
     
     FROM DirectoryAbstractService directoryAbstractService
     
     - - Прикладной контекст - -

     
ПРИЛОЖЕНИЕ В
(обязательное)

ПРОТОКОЛ СИСТЕМЫ СПРАВОЧНИКА В АСН.1

     
     В данном приложении приведены определения всех типов и значений АСН.1, содержащихся в настоящем стандарте, в виде модуля АСН.1 "DirectorySystemProtocol".
     
     DirectorySystemProtocol {joint-iso-ccift ds{5} module{1} dsp{12} 2}
     
     DEFINITIONS : : =
     
     BEGIN
     
     - - EXPORTS AH - -
               

     
      IMPORTS

     distributedOperations, protocolObjectIdentifiers
     
          FROM UsefulDefinitions {joint-iso-ccitt ds(5) module(1) usefulDefinitions(0) 2}
     
ROS-OBJECT-CLASS, CONTRACT, OPERATION-PACKAGE, CONNECTION-PACKAGE, Code, OPERATION
     
     FROM Remote-Operations-Information-Objects
     
            {joint-iso-ccitt remote-operations(4) informationObjects(5) version 1(0)}
     
ROS{}, Bind{}, Unbind{}, InvokelD
     
     FROM Remote-Operations-Generic-ROS-PDUs
     
     {joint-iso-ccitt remote-operations(4) generic-ROS-PDUs (6) version 1(0)}
     
 APPLICATION-CONTEXT
     
     FROM Remote-Operations-Information-Objects-extension {joint-iso-ccitt remote-operations(4) informationObjects-extension(8) version 1(0)}

acse, pData
     
     FROM Remote-Operations-Realisations
     
     {joint-iso-ccitt remote-operations(4) realisations(8) version 1(0)}
     
acse-abstract-syntax
     
     FROM Remote-Operations-Abstract-Syntaxes
     
     {joint-iso-ccitt remote-operations(4) remoteOperationsAbstractSyntaxes(12) versionl(0)}
     
id-ac-directorySystemAC, id-rpsObject-dspDSA, id-contract-dsp, id-package-dspConnection, id-package-chainedRead, id-package-chainedSearch, id-package-chainedModify, id-as-directorySystemAS
     
     FROM ProtocolObjectIdentifiers protocolObjectIdentifiers
     
dSABind, dSAUnbind, chainedRead, chainedCompare, chainedAbandon, chainedList, chainedSearch, chainedAddEntry, chainedRemoveEntry, chainedModifyEntry, chainedModifyDN

     FROM DistributedOperations distributedOperations

     
ПРИЛОЖЕНИЕ С
(обязательное)

ПРОТОКОЛ ТЕНЕВОЙ ИНФОРМАЦИИ СПРАВОЧНИКА В АСН.1

     
     В данном приложении приведены определения всех соответствующих типов и значений АСН. 1, содержащихся в настоящем стандарте, в виде модуля АСН.1 "DirectoryInformationShadowProtocol".
     
     DirectoryInformationShadowProtocol {joint-iso-ccitt ds(5) module(1) disp(16) 2}
     
     DEFINITIONS : : =
     
     BEGIN
     
     = EXPORTS All =
          

          
     IMPORTS
     
     directoryShadowAbstractService, protocolObjectIdentifiers
     
     FROM UsefulDefinitions {joint-iso-ccitt ds(5) module(1) usefulDefinitions(0) 2}
     
ROS-OBJECT-CLASS, CONTRACT, OPERATION-PACKAGE, CONNECTION-PACKAGE, Code, OPERATION
     
     FROM Remote-Operations-Information-Objects
     
     {joint-iso-ccitt remote-operations(4) informationObjects(5) version 1(0)}
     
ROS{}, Bind{}, Unbind{}, InvokeID
     
     FROM Remote-Operations-Generic-ROS-PDUs
     
     {joint-iso-ccitt remote-operations(4) generic-ROS-PDUs (6) version 1(0)}
     
APPLICATION-CONTEXT
     
     FROM Remote-Operations-Information-Objects-extension
     
          {joint-iso-ccitt remote-operations(4) informationObjects-extension (8) version 1(0)}
     
acse, pData, association-by-RTSE, transfer-by-RTSE

     FROM Remote-Operations-Realisations
     
         {joint-iso-ccitt remote-operations(4) realisations(8) version 1(0)}
     
acsee-abstract-syntax, rtse-abstract-syntax
     
     FROM Remote-Operations-Abstract-Syntaxes
     
     {joint-iso-ccitt remote-operations(4) remoteOperationsAbstractSyntaxes( 12) version 1(0)}
     
id-ac-shadowSupplierInitiatedAC, id-ac-shadowConsumerInitiatedAC, id-ac-reliableShadowSupplierInitiatedAC, id-ac-reliableShadowConsumerInitiatedAC
     

id-rosObject-initiatingConsumerDSA, id-rosObject-responding-SupplierDSA, id-rosObject-initiatingSupplierDSA, id-rosObject-respondingConsumerDSA, id-contract-shadowConsumer, id-contract-shadowSupplier, id-package-dispConnection
     
id-package-shadowConsumer, id-package-shadowSupplier, id-as-directoryShadowAS, id-as-directoryReliableShadowAS, id-as-reliableShadowBindingAbstractSyntax
     
     FROM ProtocolObjectIdentifiers protocolObjectIdentifiers
     
dSAShadowBind, dSAShadowUnbind, requestShadowUpdate, updateShadow, coordinateShadowUpdate
     
     FROM DirectoryShadowAbstractService directoryShadowAbstractService RTSE-apdus
     
     FROM Reliable-Transfer-APDUs {joint-iso-ccitt
     
     reliable-transfer(3) apdus(0) }
     

     

ПРИЛОЖЕНИЕ D
(обязательное)

ПРОТОКОЛ АДМИНИСТРАТИВНОГО УПРАВЛЕНИЯ ЭКСПЛУАТАЦИОННЫМИ
СВЯЗЯМИ СПРАВОЧНИКА В АСН.1

     
     В данном приложении приведены определения всех соответствующих типов и значений АСН.1, содержащихся в настоящем стандарте, в виде модуля АСН.1 "DirectoryOperationalBindingManagementProtocol".
     
     DirectoryOperationalBindingManagementProtocol {joint-iso-ccitt ds(5) module(1) dop(17) 2}
     
     DEFINITIONS : : =
     
     BEGIN
     
     - - EXPORTS AII - -
          

  
      IMPORTS
     
     protocolObjectIdentifiers, directoryAbstractService, opBindingManagement
     
     FROM UsefulDefinitions {joint-iso-ccitt ds(5) module(l) usefulDefinitions(0) 2}
     
     directoryBind, directoryUnBind
     
          FROM DirectoryAbstractService directoryAbstractService
     
ROS-OBJECT-CLASS, CONTRACT, OPERATION-PACKAGE, CONNECTION-PACKAGE, Code,
     
     FROM Remote-Operations-Information-Objects
     
     {joint-iso-ccitt remote-operations(4) informationObjects(5) version 1(0)}
     
ROS{}, Bind{}, Unbind{}, InvokeID
     
     FROM Remote-Operations-generic-ROS-PDUs
     
     {joint-iso-ccitt remote-operations(4) generic-ROS-PDUs (6) version 1(0)}
     
 APPLICATION-CONTEXT
     
     FROM Remote-Operations-Information-Objects-extension
     
     {joint-iso-ccitt remote-operations(4) informationObject-extension(8) versionl(0)}
     
acse, pData
     
     FROM Remote-Operations-Realisations
     
     {joint-iso-ccitt remote-operations(4) realisations(8) version 1(0)}
     
acse-abstract-syntax
     
     FROM Remote-Operations-Abstract-Syntaxes
     
     {joint-iso-ccitt remote-operations(4) remoteOperationsAbstractSyntaxes(12) version 1(0)}
     
id-ac-directoryOperationalBindingManagementAC, id-rosObject-dopDSA,

id-contract-dop, id-package-dopConnection,

id-package-operationalBindingManagement,

id-as-directoryOperationalBindingManagementAS
     
     FROM ProtocolObjectIdentifiers protocolObjectIdentifiers
     
establish Operational Binding, modify Operational Binding, terminateOperationalBinding, dSAOperationalBindingManagementBind, dSAOperationalBindingManagementUnbind
     
     FROM OperationalBindingManagement opBindingManagement;
     

     
ПРИЛОЖЕНИЕ Е
(обязательное)

ЭТАЛОННОЕ ОПРЕДЕЛЕНИЕ ИДЕНТИФИКАТОРОВ ОБЪЕКТОВ ПРОТОКОЛА

     
     В данном приложении приведены все идентификаторы объектов АСН.1, присвоенные в настоящем стандарте, в виде модуля АСН.1 "ProtocolObjectIdehtifiers".
     
     ProtocolObjectIdentifiers {joint-iso-ccitt ds(5) module(1) protocolObjectldentifiers(4) 2}
     
     DEFINITIONS : : =
     
     BEGIN
     
     - -EXPORTS All - -
     
     

       
     IMPORTS
     
     id-rosObject, id-contract, id-package, id-ас, id-as
     
     FROM Usefuldefinitions {joint-iso-ccitt ds(5) module(1) usefulDefinitions(0) 2}
      

ПРИЛОЖЕНИЕ F
 (справочное)

ТИПЫ ЭКСПЛУАТАЦИОННЫХ СВЯЗЕЙ СПРАВОЧНИКА

     
     В данном приложении приведены в виде модуля ACH.1 "DirectoryOperationalBindingTypes" все присвоенные идентификаторы объектов АСН.1, предназначенные для определения типов эксплуатационных связей, реализуемых в настоящем стандарте.
     
     DirectoryOperationalBinding Types
     
          {joint-iso-ccitt ds(5) module(1) directoryOperationalBindingTypes(25) 2}
     
     DEFINITIONS : : =
     
     BEGIN
     
     - - EXPORTS All - -
     
- - Определенные в этом модуле типы и значения экспортируются для использования в других модулях АСН.1,
- - содержащихся в спецификациях справочника, и другими прикладными программами, которые будут, в
- - свою очередь, использовать их для доступа к услугам справочника. Другие прикладные программы могут
- - использовать их для своих собственных целей, но это не препятствует расширениям и модификациям,
- - необходимым при обслуживании или усовершенствовании услуг справочника.

     IMPORTS

                        id-ob
     
     FROM Usefuldefinitions {joint-iso-ccitt ds(5) module(1) usefulDefinitions(0) 2};
     

         
           
     
Текст документа сверен по:
официальное издание
М.: ИПК Издательство стандартов, 1998