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

(принят и введен в действие Постановлением Госстандарта России от 19.05.1998 № 215)

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

ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ

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

СПРАВОЧНИК

ЧАСТЬ 5

СПЕЦИФИКАЦИИ ПРОТОКОЛА

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

1. Разработан Московским научно-исследовательским центром (МНИЦ) Государственного комитета Российской Федерации по связи и информатизации.

Внесен Техническим комитетом по стандартизации ТК 22 «Информационные технологии».

2. Принят и введен в действие Постановлением Госстандарта России от 19 мая 1998 г. № 215.

Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 9594-5-95 «Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 5. Спецификации протокола».

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

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

• поставляемых от различных изготовителей;
• использующих различные методы административного управления;
• имеющих различные уровни сложности;
• использующих различные технологии.

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

Кроме того, настоящий стандарт определяет сервисные элементы прикладного уровня и прикладные контексты протокола теневой информации справочника (ПТИС) и протокола управления эксплуатационными связями справочника (ПУЭС). ПТИС обеспечивает теневую информацию, хранимую в одном АСС для другого АСС. ПУЭС обеспечивает установление, модификацию и завершение связей между парами АСС при административных взаимоотношениях между АСС (типа теневых или иерархических отношений).

В Приложении A приведен модуль АСН.1 для протокола доступа к справочнику, в Приложении B - модуль АСН.1 для протокола системы справочника, в Приложении C - модуль АСН.1 для протокола теневой информации справочника, в Приложении D - модуль АСН.1 для протокола управления эксплуатационными связями справочника, в Приложении E - модуль АСН.1, который содержит все идентификаторы объектов АСН.1, используемые в настоящем стандарте, и в Приложении F - модуль АСН.1, который содержит все идентификаторы объектов АСН.1, предназначенные для определения типов эксплуатационных связей, используемых в такого типа стандартах.

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

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

ГОСТ 34.971-91 (ИСО 8822-88) Системы обработки информации. Взаимосвязь открытых систем. Определение услуг уровня представления для режима с установлением соединения

ГОСТ 34.981-91 (ИСО 8649-88) Системы обработки информации. Взаимосвязь открытых систем. Определение услуг для сервисного элемента управления ассоциацией (СЭУА)

ГОСТ Р ИСО/МЭК 7498-1-95 Информационная технология. Взаимосвязь открытых систем (ВОС). Базовая эталонная модель. Часть 1. Базовая модель

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

ГОСТ Р ИСО 8326-95 Информационная технология. Взаимосвязь открытых систем. Определение базовых услуг сеансового уровня в режиме с установлением соединения

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

ГОСТ Р ИСО/МЭК 8824-93 Информационная технология. Взаимосвязь открытых систем. Спецификация абстрактно-синтаксической нотации версии один (АСН.1)

ГОСТ Р ИСО/МЭК 9066-1-93 Системы обработки информации. Передача текста. Надежная передача. Часть 1. Модель и определение услуг

ГОСТ Р ИСО/МЭК 9072-1-93 Системы обработки информации. Передача текста. Удаленные операции. Часть 1. Концепции, модель и нотация

ГОСТ Р ИСО/МЭК 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.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) обращение.

АСС — агент системы справочника;

АПС — агент пользователя справочника;

ЛОП — логический объект прикладного уровня;

ПБДП — протокольный блок данных прикладного уровня;

ПДС — протокол доступа к справочнику;

ПК — прикладной контекст;

ПСС — протокол системы справочника;

ПТИС — протокол теневой информации справочника;

ПУИП — протокольная управляющая информация прикладного уровня;

ПУЭС — протокол управления эксплуатационными связями справочника;

СЭП — сервисный элемент прикладного уровня;

СЭУА — сервисный элемент управления ассоциацией;

СЭУО — сервисный элемент удаленных операций;

УУО — услуги удаленных операций.

В настоящем стандарте под понятием «спецификация справочника» следует понимать ГОСТ Р ИСО/МЭК 9594-5, а под понятием «спецификации справочника» — части 1 — 9 ГОСТ Р ИСО/МЭК 9594.

Если элементы списков пронумерованы (в отличие от использования знаков дефиса «-» или букв), то такие элементы должны рассматриваться как шаги процедуры.

Настоящий стандарт определяет операции справочника, используя нотацию удаленных операций, определенных в ГОСТ Р ИСО/МЭК 9072-1.

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) в виде информационного объекта УУО.

dua ROS-OBJECT-CLASS ::= {

INITIATES {dapContract}

ID id-rosObject-dua}

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

    directory    ROS-OBJECT-CLASS ::= {
       RESPONDS  {dapContract}
       ID        id-rosObject-directory}

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

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

    dap-dsa      ROS-OBJECT-CLASS ::= {
       RESPONDS  {dapContract}
       ID        id-rosObject-dapDSA}

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

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

    dsp-dsa      ROS-OBJECT-CLASS ::= {
       BOTH      {dspContract}
       ID        id-rosObject-dspDSA}

Теневые абстрактные услуги определяют теневую информацию между теневым поставщиком АСС и теневым потребителем АСС. Эти услуги проявляются в двух формах и поэтому определяются как два различных контракта. Они определяются в виде информационных объектов УУО (см. 6.5).

Объект «ShadowConsumerContract» выражает вид услуги, в который теневой потребитель объект-УУО класса «initiating-consumer-dsa» является инициатором контракта. Объект-УУО класса «responding-supplier-dsa» является ответчиком в этом контракте.

initiating-consumer-dsa ROS-OBJECT-CLASS ::= {

       INITIATES            {shadowConsumerContract}
       ID                   id-rosObject-initiating ConsumerDSA}

responding-supplier-dsa ROS-OBJECT-CLASS ::= {

       RESPONDS             {shadowConsumerContract}
       ID                   id-rosObject-respondingSupplierDSA}

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

    initiating-supplierMsa  ROS-OBJECT-CLASS ::= {
       INITIATES            {ShadowSupplierContract}
       ID                   id-rosObject-initiatingSupplierDSA}
    responding-consumerMsa  ROS-OBJECT-CLASS ::= {
       RESPONDS             {ShadowSupplierContract}
       ID                   id-rosObject-respondingConsumerDSA}

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

    dop-dsa                 ROS-OBJECT-CLASS ::= {
       BOTH                 {dopContract}
       ID                   id-rosObjectMopDSA}

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

6.3 Контракт и пакеты ПДС

«DapContract» определен в виде информационного объекта класса «CONTRACT».

    dapContract              CONTRACT ::= {
       CONNECTION            dapConnectionPackage

INITIATOR CONSUMER OF {readPackage|searchPackage

|modify Package}

ID id-contract-dap}

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

«DapContract» составлен из пакета соединений «dapConnectionPackage» и трех пакетов управления операциями «readPackage», «searchPackage» и «modifyPackage».

Пакет управления соединением «dapConnectionPackage» определен как информационный объект класса CONNECTION-PACKAGE. Операции соединения и разъединения этого пакета соединений «directoryBind» и «directoryUnbind» определены в ИСО/МЭК 9594-3.

    dapConnectionPackage     CONNECTION-PACKAGE ::= {
       BIND                  directoryBind
       UNBIND                directoryUnBind
       ID                    id-package-dapConnection}

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

    readPackage              OPERATION-PACKAGE ::= {
       CONSUMER INVOKES               {read|compare|abandon}
       ID                             id-package-read}
    searchPackage            OPERATION-PACKAGE ::= {
       CONSUMER INVOKES               {list|search}
       ID                             id-package-search}
    modifyPackage            OPERATION-PACKAGE ::= {
       CONSUMER INVOKES               {addEntry|removeEntry

|modifyEntry|modifyDN}

ID id-package-modify}

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

Поскольку АПС является инициатором «dapContract», он принимает роль потребителя пакетов управления операциями контракта. Это означает, что только АПС может привлечь операции в этом контракте и его реализацию ВОС.

6.4 Контракт и пакеты ПСС

«dsp Contract» определен как информационный объект класса CONTRACT.

    dspContract              CONTRACT ::= {
       CONNECTION            dspConnectionPackage
       OPERATIONS OF         {chainedReadPackage|chainedSearchPackage

|chainedModifyPackage}

ID id-contractMsp}

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

«DspContract» состоит из пакета управления соединением «dspConnecti-onPackage» и трех пакетов управления операциями «chainedReadPackage», «chainesearchPackage» и «chainedModifyPackage».

Пакет управления соединением «dspConnectionPackage» определен как информационный объект класса CONNECTION-PACKAGE. Он идентичен пакету управления соединением «dapConnectionPackage».

    dspConnectionPackage     CONNECTION-PACKAGE ::= {
       BIND                  dSABind
       UNBIND                dSAUnbind
       ID                    id-package-dspConnection}

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

    chainedReadPackage       OPERATION-PACKAGE ::= {
        OPERATIONS           {chainedRead|chainedCompare

|chainedAbandon}

       ID                    id-package-chainedRead}
    chainedSearchPackage     OPERATION-PACKAGE ::= {
       OPERATIONS            {chainedList|chainedSearch}
       ID                    id-package-chainedSearch}
    chainedModifyPackage     OPERATION-PACKAGE ::= {
       OPERATIONS            {chainedAdd Entry|chainedRemoveEntry

|chainedModifyEntry|chainedModifyDN}

ID id-package-chainedModify}

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

В «dapContract» АСС может принимать роль инициатора, и либо инициирующий, либо отвечающий АСС могут вызвать операции такого контракта.

6.5 Контракты и пакеты ПТИС

«ShadowConsumerContract» и «ShadowSupplierContract» определены как информационные объекты класса CONTRACT.

    shadowConsumerContract   CONTRACT ::= {
       CONNECTION            dispConnectionPackage

INITIATOR CONSUMER OF {shadowConsumerPackage}

       ID                    id-contract-shadowConsumer}
    ShadowSupplierContract   CONTRACT ::= {
       CONNECTION            dispConnectionPackage

RESPONDER CONSUMER OF {shadowSupplierPackage}

ID id-contract-shadowSupplier}

Примечание. Понятия «потребитель» и «поставщик», используемые в нотации для классов CONTRACT и OPERATION-PACKAGE, используются для обозначения двух ролей. В ИСО/МЭК 9594-9 эти роли соответствуют двум понятиям — теневой потребитель и теневой поставщик.

Реализации в ВОС двух видов абстрактных теневых услуг, называемых в совокупности ПТИС, определены в терминах некоторых прикладных контекстов и представлены в 7.2 настоящего стандарта.

Объекты «ShadowConsumerContract» и «ShadowSupplierContract» составлены из общего пакета управления соединением «dispConnectionPackage» и либо пакета управления операциями «shadowConsumerPackage» в первом случае, либо пакета «shadowSupplierPackage» во втором.

Пакет управления соединением «dispConnectionPackage» определен как информационный объект класса CONNECTION-PACKAGE. Он идентичен пакету управления соединением «dapConnectionPackage».

    dispConnectionPackage    CONNECTION-PACKAGE ::= {
       BIND                  dSAShadowBind
       UNBIND                dSAShadowUnbind
       ID                    id-package-dispConnection}

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

    shadowConsumerPackage    OPERATION-PACKAGE ::= {
       CONSUMER INVOKES      {requestShadowUpdate}
       SUPPLIER INVOKES      {updateShadow}
       ID                    id-package-shadowConsumer}
    shadowSupplierPackage    OPERATION-PACKAGE ::= {
       SUPPLIER INVOKES      {coordinateShadowUpdate

|updateShadow}

ID id-package-shadowSupplier}

Поскольку теневой потребитель является инициатором объекта «shadowConsumerContract», то он принимает роль потребителя «shadowConsumerPackage». Это означает, что теневой потребитель вызывает операцию «requestShadowUpdate», а теневой поставщик — операцию «updateShadow».

Поскольку теневой поставщик является инициатором «shadowSuppli-erConsumerContract», то он принимает роль поставщика «shadowSupp-lierPackage». Это означает, что теневой поставщик привлекает операции контракта.

6.6 Контракт и пакеты ПУЭС

«DopContract» определен как информационный объект класса CONTRACT.

    dopContract              CONTRACT ::= {
       CONNECTION            dopConnectionPackage
       OPERATIONS OF         {dopPackage}
       ID                    id-contract-dop}

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

Пакет управления соединением «dopConnectionPackage» определен как информационный объект класса CONNECTION-PACKAGE. Он идентичен пакету управления соединением «dapConnection Package».

    dopConnectionPackage     CONNECTION-PACKAGE ::= {
       BIND                  dSAOperationalBindingManagementBind
       UNBIND                dSAOperationalBindingManagementUnbind
       ID                    id-package-dopConnection}

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

    dopPackage               OPERATION-PACKAGE ::= {
       CONSUMER INVOKES      {establishOperationalBinding

|modifyOperationalBinding

|terminateOperationalBinding}

ID id-package-operationalBindingManagement}

АСС, который может принимать роль инициатора объекта «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.

directoryAccessAbstractSyntax ABSTRACT-SYNTAX ::= {

DAP-PDUs

       IDENTIFIED BY         id-as-directoryAccessAS}
    DAP-PDUs ::=             CHOICE {
       basicRos              ROS {{DAP-InvokeIDSet}, {DAP-Invokable},

{DAP-Returnable}},

       bind                  Bind {directoryBind},
       unbind                Unbind {directoryUnbind}}
    DAP-InvokeIDSet          ::= InvokeID (ALL EXCEPT absent: NULL)
    DAP-Invokable OPERATION  ::= {read|compare|abandon

|list|search

|addEntry|removeEntry

|modifyEntry|modifyDN}

DAP-Returnable OPERATION ::= {read|compare|abandon

|list|search

|addEntry|removeEntry

|modifyEntry|modifyDN}

7.1.2 Абстрактный синтаксис ПСС

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

directorySystemabstractSyntax ABSTRACT-SYNTAX ::= {

DSP-PDUs

       IDENTIFIED BY         id-as-directorySystemAS}
    DSP-PDUs ::=             CHOICE {
       basicRos              ROS {{DSP-InvokeIDSet}, {DSP-Invokable},

{DSP-Returnable}},

       bind                  Bind {dSABind},
       unbind                Unbind {dSAUnbind}}
    DSP-InvokeIDSet          ::= InvokeID (ALL EXCEPT absent: NULL)
    DSP-Invokable OPERATION  ::= {chainedRead|chainedCompare

|chainedAbandon|chainedList

|chainedSearch|chainedAddEntry

|chainedRemoveEntry

|chainedModifyEntry

|chainedModifyDN}

DSP-Returnable OPERATION ::= {chainedRead|chainedCompare

|chainedAbandon|chainedList

|chainedSearch|chainedAddEntry

|chainedRemoveEntry

|chainedModifyEntry

|chainedModifyDN}

7.1.3 Абстрактный синтаксис ПТИС

СЭП справочника реализуют указанные в 6.5 пакеты управления операциями, которые определяются в абстрактном синтаксисе «directoryShadowAbstractSyntax» или «directoryReliableShadow-AbstractSyntax» в зависимости от использования СЭНП в прикладном контексте. Эти два абстрактных синтаксиса определяются в виде информационных объектов класса ABSTRACT-SYNTAX.

directoryShadowAbstractSyntax ABSTRACT-SYNTAX ::= {

DISP-PDUs

IDENTIFIED BY id-as-directoryShadowAS}

directoryReliableShadowAbstractSyntax ABSTRACT-SYNTAX ::= {

Reliable-DISP-PDUs

IDENTIFIED BY id-as-directoryReliableShadowAS}

Кроме того, в контекстах применения СЭНП используется следующий абстрактный синтаксис. Он включает абстрактный синтаксис самого СЭНП и абстрактный синтаксис Bind {dSAShadowBind}, а Unbind {dSAShadowUnbind}.

rtseAndShadowBindingAbstractSyntax ABSTRACT-SYNTAX ::= {

ReliableShadowBinding-PDUs

IDENTIFIED BY id-as-reliableShadowBindingAbstractSyntax}

Типы АСН.1, из которых получены значения абстрактных синтаксисов, определяются путем использования типов параметризации ROS {}, Bind {}, Unbind {}.

    DISP-PDUs                  ::= CHOICE {
       basicRos                ROS {{DISP-InvokeIDSet}, {DISP-Invokable},

{DISP-Returnable}},

       bind                    Bind {dSAShadowBind},
       unbind                  Unbind {dSAShadowUnbind}}
    Reliable-DISP-PDUs         ::= ROS {{DISP-InvokeIDSet},

{DISP-Invokable},

{DISP-Returnable}},

ReliableShadowBinding-PDUs ::= CHOICE {

       rTS                     RTSE-apdus,
       bind                    Bind {dSAShadowBind},
       unbind                  Unbind {dSAShadowUnbind}}
    DISP-InvokeIDSet           ::= InvokeID (ALL EXCEPT absent: NULL)
    DISP-Invokable OPERATION   ::= {requestShadowUpdate

|updateShadow

|coordinateShadowUpdate}

DISP-Returnable OPERATION ::= {requestShadowUpdate

|UpdateShadow

|coordinateShadowUpdate}

7.1.4 Абстрактный синтаксис ПУЭС

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

directoryOperationalBindingManagementAbstractSyntax ABSTRACT-SYNTAX ::=

{

DOP-PDUs

       IDENTIFIED BY         id-as-directoryOperationalBindingManagementAS}
    DOP-PDUs                 ::= CHOICE {
       basicRos              ROS {{DOP-InvokeIDSet}, {DOP-Invokable},

{DOP-Returnable}},

       bind                  Bind {directoryBind},
       unbind                Unbind {directoryUnbind}}
    DOP-InvokeIDSet          ::= InvokeID (ALL EXCEPT absent: NULL)
    DOP-Invokable OPERATION  ::= {establishOperationalBinding

|modifyOperationalBinding

|terminateOperationalBinding}

DOP-Returnable OPERATION ::= {establishOperationalBinding

|modifyOperationalBinding

|terminateOperationalBinding}

7.2 Прикладные контексты справочника

7.2.1 Прикладной контекст доступа к справочнику

«DapContract» реализован как «directoryAccessAC». Этот прикладной контекст определен в виде информационного объекта класса APPLICATION-CONTEXT.

    directoryAccessAC        APPLICATION-CONTEXT ::= {
       CONTRACT                  dapContract
       ESTABLISHED BY            acse
       INFORMATION TRANSFER BY   pData
       ABSTRACT SYNTAXES         {acse-abstract-syntax

|directoryAccessAbstractSyntax}

APPLICATION CONTEXT NAME id-ac-directoryAccessAC}

7.2.2 Прикладной контекст системы справочника

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

    directorySystemAC        APPLICATION-CONTEXT ::= {
       CONTRACT                  dspContract
       ESTABLISHED BY            acse
       INFORMATION TRANSFER BY   pData
       ABSTRACT SYNTAXES         {acse-abstract-syntax

|directoryAccessAbstractSyntax}

APPLICATION CONTEXT NAME id-ac-directorySystemAC}

7.2.3 Прикладной контекст теневого справочника

Если АСС поддерживает ПТИС, он должен поддерживать по крайней мере одну теневую роль: поставщика либо потребителя и, кроме того, один из объектов «shadowSupplierInitiatedAC» или «shadowConsumerInitiatedAC». Если АСС поддерживает «shadowSupplierInitiatedAC» для конкретной роли, то он может факультативно поддерживать для той же роли и «reliableShadowSupplierInitiatedAC». Если АСС поддерживает «shadowConsumerInitiatedAC» для конкретной роли, то он может факультативно поддерживать для той же роли и reliableShadowCon-sumerInitiatedAC».

7.2.3.1 Начальные контексты теневого поставщика

«ShadowSupplierContract» может быть реализован как «shadowSupplierInitiatedAC». Этот прикладной контекст определен в виде информационного объекта класса APPLICATION-CONTEXT.

shadowSupplierInitiatedAC APPLICATION-CONTEXT ::= {

       CONTRACT                  ShadowSupplierContract
       ESTABLISHED BY            acse
       INFORMATION TRANSFER BY   pData
       ABSTRACT SYNTAXES         {acse-abstract-syntax

|directoryShadowSyntax}

APPLICATION CONTEXT NAME id-ac-shadowSupplierInitiatedAC}

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

Вариант такого прикладного контекста, который разрешает использование асинхронных операций, идентифицирован как «id-ac-shadowSupplierInitiatedAsynchronosAC».

«ShadowSupplierContract» может быть факультативно реализован как «reliableShadowSupplier-InitiatedAC». Этот прикладной контекст определен в виде информационного объекта класса APPLICATION-CONTEXT.

reliableShadowSupplierInitiatedAC APPLICATION-CONTEXT ::= {

       CONTRACT                  ShadowSupplierContract
       ESTABLISHED BY            association-by-RTSE
       INFORMATION TRANSFER BY   transfer-by-RTSE
       ABSTRACT SYNTAXES         {reliableShadowBindingAbstractSyntax

|rtse-abstract-syntax

|rtseAndShadowBindingAbstractSyntax}

APPLICATION CONTEXT NAME id-ac-reliableShadowSupplierInitiatedAC}

7.2.3.2 Начальные контексты теневого потребителя

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

shadowConsumerInitiatedAC APPLICATION-CONTEXT ::= {

       CONTRACT                  shadowConsumerContract
       ESTABLISHED BY            acse
       INFORMATION TRANSFER BY   pData
       ABSTRACT SYNTAXES         {acse-syntax I directoryShadowSyntax}
       APPLICATION CONTEXT NAME  id-ac-shadowConsumerInitiatedAC}

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

Вариант такого прикладного контекста, который разрешает использование асинхронных операций, идентифицирован как «id-ac-shadowConsumerInitiatedAsynchronosAC».

Объект «shadowConsumerContract» может быть факультативно реализован как «reliable-ShadowConsumerInitiatedAC». Этот прикладной контекст определен в виде информационного объекта класса APPLICATION CONTEXT.

reliableShadowConsumerInitiatedAC APPLICATION-CONTEXT ::= {

       CONTRACT                  shadowConsumerContract
       ESTABLISHED BY            association-by-RTSE
       INFORMATION TRANSFER BY   transfer-by-RTSE
       ABSTRACT SYNTAXES         {reliableShadowBindingAbstractSyntax

|rtse-abstract-syntax

|rtseAndShadowBindingAbstractSyntax}

APPLICATION CONTEXT NAME id-ac-reliableShadowConsumerInitiatedAC}

7.2.4 Прикладной контекст управления эксплуатационными связями справочника

«DopContract реализован как „directoryOperationalBindingManagementAC“. Этот прикладной контекст определен в виде информационного объекта класса APPLICATION CONTEXT.»

directoryOperationalBindingManagementAC APPLICATION-CONTEXT ::= {

       CONTRACT                  dopContract
       ESTABLISHED BY            acse
       INFORMATION TRANSFER BY   pData
       ABSTRACT SYNTAXES         {acse-abctract-syntax|

directoryOperationalBindingManagementAbstractSyntax}

APPLICATION CONTEXT NAME id-ac-directoryOperationalBindingManagemen

tAC}

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 Коды ошибок для пакетов ПТИС

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

7.4.3 Коды ошибок для пакетов ПУЭС

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

7.5 Версии и правила расширяемости

Справочник может быть распределен, и тогда для обслуживания запроса могут взаимодействовать более двух логических объектов прикладного уровня справочника. СЭП справочника могут быть приспособлены к различным изданиям спецификаций услуг справочника, которые могут быть представлены или не представлены различными номерами версий протокола. Номер версии согласуется с последним номером общей версии между двумя непосредственно связанными ЛОП справочника.

Примечание. В настоящее время существует только одна версия каждого протокола справочника. Издания 1988 и 1993 гг. имеют одинаковую версию. Упомянутая выше процедура определена для более позднего издания спецификации справочника как новая версия.

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

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

7.5.1 АПС к АСС

7.5.1.1 Согласование версии

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

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

7.5.1.2 Обработка запроса и ответа

АПС может инициировать запросы, используя самое последнее издание спецификации, запрос которого она поддерживает. Если один или несколько элементов запроса критичны, то АПС должен указывать номер(а) расширения в параметре criticalExtensions.

Примечание. Если информация расширения заменена в типе CHOICE, ENUMERATED или INTEGER (использованный как ENUMERATED), то тип будет существен для соответствующей операции в АСС, реализованном согласно более раннему изданию спецификации. Рекомендуется, чтобы расширение было отмечено как критическое.

При обработке запроса от АПС АСС должен выполнять правила, определенные в 7.5.2.2.

При обработке ответа АПС должен:

a) игнорировать все неизвестные присвоения имен битов в строке битов;

b) игнорировать все неизвестные поименованные номера в типе ENUMERATED или INTEGER, который используется в перечисленном стиле при условии, что номер представлен в виде факультативного элемента SET или SEQUENCE;

c) игнорировать все неизвестные элементы в SET, в конце SEQUENCE или в CHOICE, где CHOICE сам является факультативным элементом SET или SEQUENCE.

Примечание. Реализации могут в качестве локального решения игнорировать определенные дополнительные элементы в ПБД справочника. В частности, некоторые неизвестные поименованные номера и неизвестные CHOICE в обязательных элементах SET и SEQUENCE могут быть проигнорированы, не делая операцию недействительной. Идентификация таких элементов является предметом дальнейшего изучения;

d) не рассматривать получение неизвестных типов атрибутов и их значений как нарушение протокола;

e) факультативно сообщать пользователю неизвестные типы атрибутов и их значения.

7.5.1.3 Правила расширяемости при обработке ошибок

При обработке известного типа ошибки с неизвестными обозначенными проблемами и параметрами АПС должен:

a) не рассматривать получение неизвестных обозначенных проблем и параметров как нарушение протокола (то есть он не должен выдавать RO-Пл-REJECT или прерывать прикладную ассоциацию) и

b) факультативно сообщать пользователю дополнительную информацию об ошибке.

При обработке неизвестного типа ошибки АПС должен:

a) не рассматривать получение неизвестного типа ошибки как нарушение протокола (то есть он не должен выдавать RO-Пл-REJECT или прерывать прикладную ассоциацию) и

7.5.2 АСС к АСС

7.5.2.1 Согласование версии

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

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

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

Примечание. В настоящее время существует только одна версия протокола ПТИС.

При установлении или принятии ассоциации, то есть связки с использованием ПУЭС, согласование версии должно определять все аспекты протокола, относящиеся к обмену между АСС. Согласованная версия не должна ограничивать последующие запросы или ответы в ассоциации.

Примечание. В настоящее время существует только одна версия протокола ПУЭС.

7.5.2.2 Правила расширяемости при обработке операций

Если какой-либо АСС, выполняющий операцию (после завершения присвоения имен) определяет элемент criticalExtensions, семантика которого неизвестна, он должен передать обратно признак unavailableCriticalExtension в виде serviceError или в PartialOutcomeQualifier.

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

В противном случае при обработке ПБД справочника АСС должен:

a) игнорировать все неизвестные присвоения имен битов в строке битов;

b) игнорировать все неизвестные поименованные номера в типе ENUMERATED или типе INTEGER, который используется в перечисленном стиле, при условии, что номер представлен в виде факультативного элемента SET или SEQUENCE;

c) игнорировать все неизвестные элементы в SET, в конце SEQUENCE или в CHOICE, где CHOICE сам является факультативным элементом SET или SEQUENCE.

Примечание. Реализации могут в качестве локального решения игнорировать определенные дополнительные элементы в ПБД справочника. В частности, некоторые неизвестные поименованные номера и неизвестные CHOICE в обязательных элементах SET и SEQUENCE могут быть проигнорированы, не делая операцию недействительной. Идентификация таких элементов является предметом дальнейшего изучения.

7.5.2.3 Правила расширяемости при формировании цепочки

Если ПБД является запросом, АСС должен передавать запрос, содержащий неизвестные типы и значения, любому дополнительному АСС, определенному в результате присвоения имени.

Если ПБД является ответом, АСС должен обрабатывать неизвестные типы и значения, как если бы он обрабатывал известные типы и значения (см. результаты объединения в спецификации справочника на распределенных операциях) и продвигать их к инициирующему АСС или АПС.

7.5.2.4 Правила расширяемости при обработке ошибок

При обработке известного типа ошибок с неизвестными обозначенными проблемами и параметрами АСС:

a) не должен рассматривать получение неизвестных обозначенных проблем и параметров как нарушение протокола (то есть он не должен выдавать УО-Пл-ОТКЛОНЕНИЕ или прерывать прикладную ассоциацию) и

b) может попытаться восстановить соответствующий своему пониманию именно этот тип ошибки или передать эту ошибку (и неизвестные для себя обозначенные проблемы и параметры) следующему соответствующему АСС или АПС.

При обработке неизвестного типа ошибки АСС, который только участвует в формировании цепочки запросов, должен:

a) не рассматривать неизвестный тип ошибки как нарушение протокола (то есть он не должен выдавать УО-Пл-ОТКЛОНЕНИЕ или прерывать прикладную ассоциацию);

b) не пытаться корректировать или восстанавливать ошибки и своих обозначенных проблем и параметров;

c) передавать неизвестный тип ошибки следующему соответствующему АСС или АПС.

При обработке неизвестной ошибки АСС, который коррелирует групповые ответы, должен:

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) для ПУЭС — directoryOperationalBindingManagementAC;

d) для ПТИС — shadowSupplierInitiatedAC или shadowConsumerInitiatedAC.

8.1.1.1.3 Информация пользователя

Преобразование услуги DirectoryBind или DSABind в параметры «информация пользователя» примитива П-АССОЦИАЦИЯ запрос определено ГОСТ Р ИСО/МЭК 9072-1.

8.1.1.1.4 Список определений контекста уровня представления

Инициатор ассоциации должен установить список определений контекста уровня представления в примитиве П-АССОЦИАЦИЯ запрос, который должен содержать абстрактный синтаксис СЭУА (id-as-acse) и один из следующих абстрактных синтаксисов: ПДС (id-as-directoryAccessAS), ПСС (id-as-directorySystemAS), ПУЭС (idws-directoryOperationalBindingManagemetAS) или ПТИС (id-asMirec-toryShadowAS).

8.1.1.1.5 Качество услуг

Этот параметр должен устанавливаться инициатором ассоциации в примитиве П-АССОЦИАЦИЯ запрос и ответчиком ассоциации в примитиве П-АССОЦИАЦИЯ ответ. Параметры «управление расширением» и «оптимизированная диалоговая передача» должны быть установлены в значение «возможность не требуется». Остальные параметры должны быть установлены таким образом, чтобы использовались значения по умолчанию.

8.1.1.1.6 Требования сеансового уровня

Этот параметр должен устанавливаться инициатором ассоциации в примитиве П-АССОЦИАЦИЯ запрос и ответчиком ассоциации в примитиве П-АССОЦИАЦИЯ ответ. Этот параметр устанавливается для определения функциональных блоков «ядро» и «полудуплекс».

8.1.1.1.7 Наименование ЛОП и адрес на уровне представления

Эти параметры должны устанавливаться инициатором и ответчиком ассоциации (наименование ЛОП устанавливается факультативно).

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

Для АПС (или АСС), устанавливающего ассоциацию с АСС, к которому он обращается, эти параметры могут быть получены из значения атрибута AccessPoint в Continuation Reference.

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

8.1.1.2 Unbind в П-РАЗЪЕДИНЕНИЕ

Услуги Directory Unbind, DSAUnbind, DSAShadowUnbind или DSADOPUnbind преобразуются в услугу СЭУА П-РАЗЪЕДИНЕНИЕ. Использование параметров услуги П-РАЗЪЕДИНЕНИЕ описано в следующем подпункте.

8.1.1.2.1 Результат

8.1.1.3 Использование услуг П-ПРЕРЫВАНИЕ и П-Пс-ПРЕРЫВАНИЕ

Прикладной процесс является пользователем услуг СЭУА П-ПРЕРЫВАНИЕ и П-Пс-ПРЕРЫВАНИЕ.

8.1.2 Преобразование в СЭУО

Услуги СЭП справочника преобразуются в услуги СЭУО УО-ПРИВЛЕЧЕНИЕ, УО-РЕЗУЛЬТАТ, УО-ОШИБКА, УО-Пл-ОТКЛОНЕНИЕ и УО-Пс-ОТКЛОНЕНИЕ. Преобразование нотации абстрактного синтаксиса сервисных элементов прикладного уровня справочника в услуги СЭУО осуществляется в соответствии с ГОСТ Р ИСО/МЭК 9072-1.

8.2 Прикладные контексты, содержащие СЭНП

В этом подразделе определено преобразование прикладных контекстов ПТИС, содержащих СЭНП, в используемые услуги. Обеспечение этого преобразования определяется заявкой о соответствии этим прикладным контекстам. СЭНП определен в ГОСТ Р ИСО/МЭК 9066-1.

8.2.1 Преобразование в услуги НП-ОТКРЫТИЕ и НП-ЗАКРЫТИЕ

Ниже определяется преобразование услуг DSAShadowBind и DSAShadowUnbind в услуги СЭНП НП-ОТКРЫТИЕ и НП-ЗАКРЫТИЕ.

8.2.1.1 Преобразование DSAShadowBind в НП-ОТКРЫТИЕ

Услуга DSAShadowBind преобразуется в услугу СЭНП НП-ОТКРЫТИЕ. Использование параметров услуги НП-ОТКРЫТИЕ описывается ниже.

8.2.1.1.1 Режим

Этот параметр должен устанавливаться инициатором ассоциации в примитиве НП-ОТКРЫТИЕ запрос и иметь значение «нормальный режим».

8.2.1.1.2 Имя прикладного контекста

Инициатор ассоциации должен предлагать в примитиве НП-ОТКРЫТИЕ запрос либо прикладной контекст reliableShadowSupplierInitiatedAC, либо прикладной контекст reliable-ShadowConsumerInitiatedAC.

8.2.1.1.3 Данные пользователя

Преобразование операции связки в параметре «данные пользователя» примитива НП-ОТКРЫТИЕ запрос определено в ГОСТ Р ИСО/МЭК 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 c).

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-specificHierarchicalBindingID или их комбинации. АСС, претендующий на соответствие атрибуту 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.

o) Соответствие базовому управлению доступом.

p) Соответствие упрощенному управлению доступом.

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 и reliableShadowConsumerInitiatedAC.

Реализация АСС должна как минимум обеспечивать либо shadowSupplierInitiatedAC, либо shadowConsumerInitiatedAC. Если АСС поддерживает shadowSupplierInitiatedAC, он может факультативно поддерживать reliableShadowSupplierInitiatedAC. Если АСС поддерживает shadowConsumerInitiatedAC, он может факультативно поддерживать reliableShadowConsumerInitiatedAC;

b) уровень(и) защиты, соответствие которому(ым) заявлено (отсутствует, простая, строгая);

c) в какой степени обеспечивается UnitOfReplication, в частности, какая (при наличии) из следующих факультативных особенностей обеспечивается:

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) уровень(и) защиты, соответствие которому(ым) заявлено (отсутствует, простая, строгая);

c) способность АСС действовать в качестве вторичного теневого поставщика (то есть участвовать во вторичном затенении в качестве промежуточного АСС);

d) способность АСС обеспечивать затенение перекрывающихся блоков, подлежащих копированию.

9.4.2 Статические требования

АСС должен:

a) обеспечивать прикладной(ые) контекст(ы), соответствие которому(ым) заявлено, как определено их абстрактным синтаксисом в разделе 7;

b) обеспечивать эксплуатационные атрибуты modifyTimestamp и createTimestamp, если обеспечиваются перекрывающиеся блоки, подлежащие копированию;

c) обеспечивать сервисное управление copyShallDo.

9.4.3 Динамические требования

АСС должен:

a) соответствовать преобразованиям в используемые услуги, определенные в разделе 8 настоящего стандарта;

b) соответствовать процедурам, определенным ИСО/МЭК 9594-9, относительно ПТИС.

Приложение A (обязательное)

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

В данном Приложении приведены определения всех типов и значений АСН.1, содержащихся в настоящем стандарте, в виде модуля АСН.1 «DirectoryAccessProtocol».

DirectoryAccessProtocol {joint-iso-ccitt ds{5} module{1} dap{11} 2}

DEFINITIONS ::=

BEGIN - EXPORTS AII -

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

-- услуг справочника.

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

FROM Remote-Operations-Information-Objects

{joint-iso-ccitt remote-operations(4) informationObjects(5)

version(0)}

ROS{}, Bind{}, Unbindg{}, InvokeID

FROM Remote-Operations-Generic-ROS-PDUs

{joint-iso-ccitt remote-operations(4) generic-ROS-PDUs(6)

version1(0)}

APPLICATION-CONTEXT

FROM Remote-Operations-Information-Objects-extension

{joint-iso-ccitt remote-operations(4) informationObjects-

extension(8) version1(0)}

acse, pData

FROM Remote-Operations-Realisations

{joint-isowcitt remote-operations(4) realisations(8)

version1(0)}

acse-abstract-syntax

FROM Remote-Operations-Abstract-Syntaxes

{joint-iso-ccitt remote-operations(4) remoteOperationsAbstract-

Syntaxes(12) version1(0)}

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

-- Прикладной контекст --

    directoryAccessAC             APPLICATION-CONTEXT ::= {
       CONTRACT                   dapContract
       ESTABLISHED BY             acse
       INFORMATION TRANSFER BY    pData
       ABSTRACT SYNTAXES          {acse-abstract-syntax I

directoryAccessAbstractSyntax}

APPLICATION-CONTEXT NAME id-ac-directoryAccessAC}

-- Объекты-УУО --

    dua                           ROS-OBJECT-CLASS ::= {
    INITIATES                     {dapContract}
       ID                         id-rosObject-dua}
    directory                     ROS-OBJECT-CLASS ::= {
       RESPONDS                   {dapContract}
       ID                         id-rosObject-directory}
    dap-dsa                       ROS-OBJECT-CLASS ::= {
       RESPONDS                   {dapContract}
       ID                         id-rosObject-dapDSA}

-- Контракты --

    dapContract                   CONTRACT ::= {
       CONNECTION                 dapConnectionPackage
       INITIATOR CONSUMER OF      {readPackage|searchPackage

|modifyPackage}

ID id-contract-dap}

-- Пакет управления соединением --

    dapConnectionPackage          CONNECTION-PACKAGE ::= {
       BIND                       directoryBind
       UNBIND                     directoryUnbind
       ID                         id-package-dapConnection}

-- Пакет чтения --

    readPackage                   OPERATION-PACKAGE ::= {
       CONSUMER INVOKES           {read|compare|abandon}
       ID                         id-package-read}

-- Пакет поиска --

    searchPackage                 OPERATION-PACKAGE ::= {
       CONSUMER INVOKES           {list|search}
       ID                         id-package-search}

-- Пакет модификации --

    modifyPackage                 OPERATION-PACKAGE ::= {
       CONSUMER INVOKES           {addEntry|removeEntry|modifyEntry|modifyD

N}

ID id-package-modify}

-- Абстрактный синтаксис --

directoryAccessAbstractSyntax ABSTRACT-SYNTAX ::= {

DAP-PDUs

       IDENTIFIED BY              id-as-MirectoryAccessAS
    DAP-PDUs                      CHOICE ::= {
       basicRos                   ROS {{DAP-InvokeIDSet}   {DAP-Invokable},

{DAP-Returnable}},

       bind                       Bind {directoryBind},
       unbind                     Unbind {directoryUnbind}}

DAP-InvokeIDSet ::= {Invokeid (ALL EXCEPT absent: NULL)

|addEntry|removeEntry

DAP-Returnable OPERATION ::= {read|compare|abandon

|list|search

|addEntry|removeEntry

|modifyEntry|modifyDN}

    --  Коды удаленных операций --
    id-opcode-read                              Code ::=           local: 1
    id-opcode-compare                           Code ::=           local: 2
    id-opcode-abandon                           Code ::=           local: 3
    id-opcode-list                              Code ::=           local: 4
    id-opcode-search                            Code ::=           local: 5
    id-opcode-addEntry                          Code ::=           local: 6
    id-opcode-removeEntry                       Code ::=           local: 7
    id-opcode-modifyEntry                       Code ::=           local: 8
    id-opcode-modifyDN                          Code ::=           local: 9

-- Коды ошибок удаленных операций --

    id-errcode-attribute Error                  Code ::=           local: 1
    id-errcode-nameError                        Code ::=           local: 2
    id-errcode-serviceError                     Code ::=           local: 3
    id-errcode-referral                         Code ::=           local: 4
    id-errcode-abandoned                        Code ::=           local: 5
    id-errcode-security Error                   Code ::=           local: 6
    id-errcode-abandonFailed                    Code ::=           local: 7
    id-errcode-updateError                      Code ::=           local: 8

-- Коды удаленных ошибок для ПСС --

id-errcode-dsaReferral Code ::= local: 9

END

Приложение B (обязательное)

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

В данном Приложении приведены определения всех типов и значений АСН.1, содержащихся в настоящем стандарте, в виде модуля АСН.1 «DirectorySystemProtocol».

DirectorySystemProtocol {joint-iso-ccitt ds{5} module{1} dsp{12} 2}

DEFINITIONS ::=

BEGIN

-- EXPORTS AII --

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

-- услуг справочника.

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)

version1(0)}

ROS{}, Bind{}, Unbind{}, InvokeID

FROM Remote-Operations-Generic-ROS-PDUs

{joint-iso-ccitt remote-operations(4) generic-ROS-PDUs(6)

version1(0)}

APPLICATION-CONTEXT

FROM Remote-Operations-Information-Objects-extension

{joint-iso-ccitt remote-operations(4) informationObjects-

extension(8) version1(0)}

acse, pData

FROM Remote-Operations-Realisations

{joint-iso-ccitt remote-operations(4) realisations(8)

version1(0)}

acse-abstract-syntax

FROM Remote-Operations-Abstract-Syntaxes

{joint-iso-ccitt remote-operations(4) remoteOperationsAbstract-

Syntaxes(12) version1(0)}

    id-ac-directorySystemAC,   id-rosObject-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

-- Прикладной контекст --

    directorySystemAC             APPLICATION-CONTEXT ::= {
       CONTRACT                   dspContract
       ESTABLISHED BY             acse
       INFORMATION TRANSFER BY    pData
       ABSTRACT SYNTAXES          {acse-abstract-syntax

|directoryAccessAbstractSyntax}

APPLICATION-CONTEXT NAME id-ac-directorySystemAC}

-- Объекты-УУО --

    dsp-dsa                       ROS-OBJECT-CLASS ::= {
       BOTH                       {dspContract}
       ID                         id-rosObject-dspDSA}

-- Контракты --

    dspContract                   CONTRACT ::= {
       CONNECTION                 dspConnectionPackage
       OPERATIONS OF              {chainedReadPackage

|chainedSearchPackage

|chainedModifyPackage}

ID id-contract-dsp}

-- Пакет управления соединением --

    dspConnectionPackage          CONNECTION-PACKAGE ::= {
       BIND                       dSABind
       UNBIND                     dSAUnbind
       ID                         id-package-dspConnection}

-- Сцепленный пакет чтения --

    chainedReadPackage            OPERATION-PACKAGE ::= {
       OPERATIONS                 {chainedRead|chainedCompare

|chainedAbandon}

ID id-package-chainedRead}

-- Сцепленный пакет поиска --

    chainedSearchPackage          OPERATION-PACKAGE ::= {
       OPERATIONS                 {chainedList|chainedSearch}

chainedModify Package OPERATION-PACKAGE :: = {

|chainedModifyEntry|chainedModifyDN}

ID id-package-chainedModify}

-- Абстрактный синтаксис --

directorySystemAbstractSyntax ABSTRACT-SYNTAX ::= {

DSP-PDUs

       IDENTIFIED BY              id-as-directorySystemAS}
    DSP-PDUs ::=                  CHOICE {
       basicRos                   ROS {{DSP-InvokeIDSet},  {DSP-Invokable},

{DSP-Returnable}},

       bind                       Bind {dSABind},
       unbind                     Unbind {dSAUnbind}}

DSP-InvokeIDSet ::= {InvokeID (ALL EXCEPT absent: NULL)

DSP-Invokable OPERATION ::= {chainedRead|chainedCompare

|chainedAbandon|chainedList

|chained Search|chainedAddEntry

|chainedRemoveEntry

|chainedModifyEntry|

|chainedModifyDN}

DSP-Returnable OPERATION ::= {chainedRead|chainedCompare

|chainedAbandon

|chainedList|chainedSearch

|chainedAddEntry

|chainedRemoveEntry|

chainedModifyEntry

|chainedModifyDN}

END

Приложение C (обязательное)

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

В данном Приложении приведены определения всех соответствующих типов и значений АСН.1, содержащихся в настоящем стандарте, в виде модуля АСН.1 «DirectoryInformationShadowProtocol».

DirectoryInformationShadowProtocol {joint-iso-ccitt ds(5) module(1)

disp(16) 2}

DEFINITIONS ::=

BEGIN

= EXPORTS AII =

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

-- услуг справочника.

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) version1(0)}

acse, pData, association-by-RTSE, transfer-by-RTSE

FROM Remote-Operations-Realisations

{joint-iso-ccitt remote-operations(4) realisations(8) version1(0)}

acsee-abstract-syntax, rtse-abstract-syntax

FROM Remote-Operations-Abstract-Syntaxes

{joint-iso-ccitt remote-operations(4) remoteOperationsAbstract

Syntaxes(12) version1(0)}

id-ac-shadowSupplierInitiatedAC, id-ac-shadowConsumerInitiatedAC, id-

ac-reliableShadowSupplierInitiatedAC, id-ac-reliableShadowConsumerInitiated

AC

    id-rosObject-initiatingConsumerDSA,    id-rosObject-responding-Supplier
DSA,   id-rosObject-initiatingSupplierDSA,  id-rosObject-respondingConsumer
DSA,  id-contract-shadowConsumer,  id-contract-shadowSupplier,  id-package-

dispConnection

    id-package-shadowConsumer,  id-package-shadowSupplier,  id-as-directory
ShadowAS,   id-as-directoryReliableShadowAS,    id-as-reliableShadowBinding

AbstractSyntax

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)} ;

-- Прикладной контекст --

    shadowSupplierInitiatedAC         APPLICATION-CONTEXT ::= {
       CONTRACT                       ShadowSupplierContract
       ESTABLISHED BY                 acse
       INFORMATION TRANSFER BY        pData
       ABSTRACT SYNTAXES              {rtse-abstract-syntax|

directoryShadowSyntax}

       APPLICATION-CONTEXT NAME       id-ac-shadowSupplierInitiatedAC}
    shadowConsumerInitiatedAC         APPLICATION-CONTEXT ::= {
       CONTRACT                       shadowConsumerContract
       ESTABLISHED BY                 acse
       INFORMATION TRANSFER BY        pData
       ABSTRACT SYNTAXES              {acse-syntax|directoryShadowSyntax}
       APPLICATION-CONTEXT NAME       id-ac-shadowConsumerInitiatedAC}
    reliableShadowSupplierInitiated   ACAPPLICATION-CONTEXT ::= {
       CONTRACT                       ShadowSupplierContract
       ESTABLISHED BY                 association-by-RTSE
       INFORMATION TRANSFER BY        transfer-by-RTSE
       ABSTRACT SYNTAXES              {reliableShadowBindingAbstractSyntax

|rtse-abstract-syntax

|rtseAndShadowBindingAbstractSyntax}

APPLICATION-CONTEXT NAME id-ac-reliableShadowSupplierInitiated

AC}

reliableShadowConsumerlnitiatedAC APPLICATION-CONTEXT ::= {

       CONTRACT                       shadowConsumerContract
       ESTABLISHED BY                 association-by-RTSE
       INFORMATION TRANSFER BY        transfer-by-RTSE
       ABSTRACT SYNTAXES              {reliableShadowBindingAbstractSyntax

|rtse-abstract-syntax

|rtseAndShadowBindingAbstractSyntax

APPLICATION-CONTEXT NAME id-ac-reliableShadowConsumerInitiated

AC}

-- Объекты-УУО --

    initiating-consumer-dsa           ROS-OBJECT-CLASS ::= {
       INITIATES                      {shadowConsumerContract}
       ID                             id-rosObject-initiatingConsumerDSA}
    responding-supplier-dsa           ROS-OBJECT-CLASS ::= {
       RESPONDS                       {shadowConsumerContract}
       ID                             id-rosObject-respondingSupplierDSA}
    initiating-supplier-dsa           ROS-OBJECT-CLASS ::= {
       INITIATES                      {ShadowSupplierContract}
       ID                             id-rosObject-initiatingSupplierDSA}
    responding-consumcr-dsa           ROS-OBJECT-CLASS ::= {
       RESPONDS                       {shadowSupplierContract}
       ID                             id-rosObject-respondingConsumerDSA}

-- Контракты --

    shadowConsumerContract            CONTRACT ::= {
       CONNECTION                     dispConnectionPackage
       INITIATOR CONSUMER OF          {shadowConsumerPackage}
       ID                             id-contract-shadowConsumer}
    shadowSupplierContract            CONTRACT ::= {
       CONNECTION                     dispConnectionPackage
       RESPONDER CONSUMER OF          {shadowSupplierPackage}
       ID                             id-contract-shadowSupplier}

-- Пакет управления соединением --

    dispConnectionPackage             CONNECTION-PACKAGE ::= {
       BIND                           dSAShadowBind
       UNBIND                         dSAShadowUnbind
       ID                             id-package-dispConnection}

-- Пакеты --

    shadowConsumerPackage             OPERATION-PACKAGE ::= {
       CONSUMER INVOKES               {requestShadowUpdate}
       SUPPLIER INVOKES               {updateShadow}
       ID                             id-package-shadowConsumer}
    shadowSupplierPackage             OPERATION-PACKAGE ::= {
       SUPPLIER INVOKES               {coordinateShadowUpdate

|updateShadow}

ID id-package-shadowSupplier}

-- Абстрактный синтаксис --

directoryShadowAbstractSyntax ABSTRACT-SYNTAX ::= {

DISP-PDUs

IDENTIFIED BY id-as--directoryShadowAS}

directoryReliableShadowAbstractSyntax ABSTRACT-SYNTAX ::= {

Reliable-DISP-PDUs

       IDENTIFIED BY                  id-as-directoryReliableShadowAS }
    rtseAnd ShadowBindingAbstractSyntax   ABSTRACT-SYNTAX ::= {

ReliableShadowBinding-PDUs

IDENTIFIED BY id-as-reliableShadowBindingAbstractSy

ntax}

DISP-PDUs ::= CHOICE {

       unbind                         Unbind {dSAShadowUnbind}}

    Reliable-DISP-PDUs ::=            ROS {{DISP-InvokeIDSet},

    ReliableShadowBinding-PDUs :: =   CHOICE {

       rTS                            RTSE-apdus,

       bind                           Bind {dSAShadowBind},
       unbind                         Unbind {dSAShadowUnbind}}
    DISP-InvokeIDSet                  Invokeid (ALL EXCEPT absent: NULL)
    DISP-Invokable                    OPERATION ::= {requestShadowUpdate

|UpdateShadow

|coordinateShadowUpdate}

DISP-Returnable OPERATION ::= {requestShadowUpdate

|updateShadow

|coordinateShadowUpdate

-- Коды удаленных операций --

    id-opcode-requestShadowUpdate               Code ::=           local: 1
    id-opcode-updateShadow                      Code ::=           local: 2
    id-pcode-coordinateShadowUpdate             Code ::=           local: 3

-- Коды ошибок удаленных операций --

id-errcode-ShadowError Code ::= local: 1

Приложение D (обязательное)

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

В данном Приложении приведены определения всех соответствующих типов и значений АСН.1, содержащихся в настоящем стандарте, в виде модуля АСН.1 «DirectoryOperationalBindingManagementProtocol».

DirectoryOperationalBindingManagementProtocol {joint-iso-ccitt ds(5)

module(1) dop(17) 2}

DEFINITIONS ::=

BEGIN

-- EXPORTS AII --

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

-- услуг справочника.

IMPORTS

protocolObjectIdentifiers, directoryAbstractService, opBinding

Management

FROM UsefulDefinitions {joint-iso-ccitt ds(5) module(1) useful

Definitions(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)

version1(0)}

acse, pData

FROM Remote-Operations-Realisations

{joint-iso-ccitt remote-operations(4) realisations(8) version1(0)}

acse-abstract-syntax

FROM Remote-Operations-Abstract-Syntaxes

{joint-iso-ccitt remote-operations(4) remoteOperationsAbstract

Syntaxes(12) version1(0)}

id-ac-directoryOperationalBindingManagementAC, id-rosObject-dopDSA,

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

id-package-operationalBindingManagement,

id-as-directoryOperationalBindingManagementAS

FROM ProtocolObjectIdentifiers protocolObjectIdentifiers

    establishOperationalBinding,     modifyOperationalBinding,    terminate
OperationalBinding,   dSAOperationalBindingManagementBind,   dSAOperational

BindingManagementUnbind

FROM OperationalBindingManagement opBindingManagement;

-- Прикладной контекст --

directoryOperationalBindingManagementAC APPLICATION-CONTEXT ::= {

       CONTRACT                       dopContract
       ESTABLISHED BY                 acse
       INFORMATION TRANSFER BY        pData
       ABSTRACT SYNTAXES              {acse-abstract-syntax|

directoryOperationalBindingManagement

AbstractSyntax}

APPLICATION-CONTEXT NAME id-ac-directoryOperationalBindingMana

gementAC}

-- Объекты УУО --

    dop-dsa                           ROS-OBJECT-CLASS ::= {
       BOTH                           {dopContract}
       ID                             id-rosObject-dopDSA }

-- Контракты --

    dopContract                       CONTRACT ::= {
       CONNECTION                     dopConnectionPackage
       INITIATOR CONSUMER OF          {dopPackage}
       ID                             id-contract-dop

-- Пакет управления соединением --

    dopConnectionPackage              CONNECTION-PACKAGE ::= {
       BIND                           dSAOperationalBindingManagementBind
       UNBIND                         dSAOperationalBindingManagementUnbind
       ID                             id-package-dopConnection}

-- Пакеты --

    dopPackage                        OPERATION-PACKAGE ::= {
       CONSUMER INVOKES               {establishOperationalBinding

|modifyOperationalBinding

|terminateOperationalBinding}

ID id-package-OperationalBindingManageme

nt

-- Абстрактный синтаксис --

directoryOperationalBindingManagementAbstractSyntax ABSTRACT-SYNTAX ::=

{

DOP-PDUs

IDENTIFIED BY id-as-directoryOperationalBindingMana

gementAS}

    DOP-PDUs :: =                     CHOICE {
       basicRos                       ROS     {{DOP-InvokeIDSet},     {DOP-

Invokable}, {DOP-Returnable}},

       bind                           Bind {directoryBind},
       unbind                         Unbind {directoryUnbind}}
    DOP-InvokeIDSet ::=               InvokeID (ALL EXCEPT absent: NULL)
    DOP-Invokable OPERATION ::=       {establishOperationalBinding

|modifyOperationalBinding

|terminateOperationalBinding}

    id-op-establishOperationalBinding           Code ::=         local: 100

    id-op-modifyOperationalBinding              Code ::=         local: 102

    id-op-terminateOperationalBinding           Code ::=         local: 101

-- Коды ошибок удаленных операций --

id-err-operationalBindingError Code ::= local: 100

END

Приложение E (обязательное)

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

В данном Приложении приведены все идентификаторы объектов АСН.1, присвоенные в настоящем стандарте, в виде модуля АСН.1 «ProtocolObjectIdentifiers».

ProtocolObjectIdentifiers {joint-iso-ccitt ds(5) module(1) protocol

ObjectIdentifiers(4) 2}

DEFINITIONS ::=

BEGIN

-- EXPORTS AII --

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

-- услуг справочника.

IMPORTS

id-rosObject, id-contract, id-package, id-ac, id-as

FROM Usefuldefinitions {joint-iso-ccitt ds(5) module(1) usefulDefini

tions(0) 2}

-- Объекты УУО --

  id-rosObject-dua                   OBJECTIDENTIFIER ::= {id-rosObject 1}
  id-rosObject-directory             OBJECTIDENTIFIER ::= {id-rosObject 2}
  id-rosObject-dapDSA                OBJECTIDENTIFIER ::= {id-rosObject 3}
  id-rosObject-dspDSA                OBJECTIDENTIFIER ::= {id-rosObject 4}
  id-rosObject-dopDSA                OBJECTIDENTIFIER ::= {id-rosObject 7}

id-rosObject-initiatingConsumerDSA OBJECTIDENTIFIER ::= {id-rosObject 8}

id-rosObject-respondingSupplierDSA OBJECTIDENTIFIER ::= {id-rosObject 9}

id-rosObject-initiatingSupplierDSA OBJECTIDENTIFIER ::= {id-rosObject 10}

id-rosObject-respondingConsumerDSA OBJECTIDENTIFIER ::= {id-rosObject 11}

-- Контракты --

  id-contract-dap                    OBJECTIDENTIFIER ::= {id-contract 1}
  id-contract-dsp                    OBJECTIDENTIFIER ::= {id-contract 2}
  id-contract-shadowConsumer         OBJECTIDENTIFIER ::= {id-contract 3}
  id-contract-shadowSupplier         OBJECTIDENTIFIER ::= {id-contract 4}
  id-contract-dop                    OBJECTIDENTIFIER ::= {id-contract 5}

-- Пакеты --

  id-package-read                    OBJECTIDENTIFIER ::= {id-package 1}
  id-package-search                  OBJECTIDENTIFIER ::= {id-package 2}
  id-package-modify                  OBJECTIDENTIFIER ::= {id-package 3}
  id-package-chainedRead             OBJECTIDENTIFIER ::= {id-package 4}
  id-package-chainedSearch           OBJECTIDENTIFIER ::= {id-package 5}
  id-package-chainedModify           OBJECTIDENTIFIER ::= {id-package 6}
  id-package-shadowConsumer          OBJECTIDENTIFIER ::= {id-package 7}
  id-package-shadowSupplier          OBJECTIDENTIFIER ::= {id-package 8}

id-package-operationalBinding

  Management                         OBJECTIDENTIFIER ::= {id-package 9}
  id-package-dapConnection           OBJECTIDENTIFIER ::= {id-package 10}
  id-package-dspConnection           OBJECTIDENTIFIER ::= {id-package 11}
  id-package-dispConnection          OBJECTIDENTIFIER ::= {id-package 12}
  id-package-dopConnection           OBJECTIDENTIFIER ::= {id-package 13}

-- Прикладной контекст --

  id-ac-directoryAccessAC            OBJECT IDENTIFIER ::= {id-ac 1}
  id-ac-directorySystemAC            OBJECT IDENTIFIER ::= {id-ac 2}

id-ac-directoryOperationalBinding

  ManagementAC                       OBJECT IDENTIFIER ::= {id-ac 3}
  id-ac-shadowConsumerInitiatedAC    OBJECT IDENTIFIER ::= {id-ac 4}
  id-ac-shadowSupplierInitiatedAC    OBJECT IDENTIFIER ::= {id-ac 5}

id-ac-reliableShadowSupplier

InitiatedAC OBJECT IDENTIFIER ::= {id-ac 6}

id-ac-reliableShadowConsumer

InitiatedAC OBJECT IDENTIFIER ::= {id-ac 7}

id-ac-shadowSupplierInitiated

AsynchronousAC OBJECT IDENTIFIER ::= {id-ac 8}

id-ac-shadowConsumerInitiated

AsynchronousAC OBJECT IDENTIFIER ::= {id-ac 9} - ASEs {obsolete} -

• id-ase-readASE OBJECT IDENTIFIER ::= {id-ase 1}
• id-ase-searchASE OBJECT IDENTIFIER ::= {id-ase 2}
• id-ase-modifyASE OBJECT IDENTIFIER ::= {id-ase 3}
• id-ase-chainedReadASE OBJECT IDENTIFIER ::= {id-ase 4}
• id-ase-chainedSearchASE OBJECT IDENTIFIER ::= {id-ase 5}
• id-ase-chainedModifyASE OBJECT IDENTIFIER ::= {id-ase 6}
• id-ase-operationalBinding

ManagementASE OBJECT IDENTIFIER ::= {id-ase 7}

• id-ase-shadowConsumerASE OBJECT IDENTIFIER ::= {id-ase 8}
• id-ase-shadowSupplierASE OBJECT IDENTIFIER ::= {id-ase 9}

-- Абстрактный синтаксис --

  id-as-directoryAccessAS            OBJECT IDENTIFIER ::= {id-as 1}
  id-as-directorySystemAS            OBJECT IDENTIFIER ::= {id-as 2}
  id-as-directoryShadowAS            OBJECT IDENTIFIER ::= {id-as 3}

id-as-directoryOperationalBinding

  ManagementAS                       OBJECT IDENTIFIER ::= {id-as 4}
  id-as-directoryReliableShadowAS    OBJECT IDENTIFIER ::= {id-as 5}

id-as-reliableShadowBinding

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

В данном Приложении приведены в виде модуля АСН.1 «DirectoryOperationalBindingTypes» все присвоенные идентификаторы объектов АСН.1, предназначенные для определения типов эксплуатационных связей, реализуемых в настоящем стандарте.

DirectoryOperationalBinding Types

{joint-iso-ccitt ds(5) module(1) directoryOperationalBindingTypes

(25) 2}

DEFINITIONS ::=

BEGIN

-- EXPORTS AII --

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

-- услуг справочника.

IMPORTS

id-ob

FROM Usefuldefinitions {joint-iso-ccitt ds(5) module(1) useful

Definitions(0) 2};

    id-op-binding-shadow                    OBJECT IDENTIFIER ::= {id-ob 1}
    id-op-binding-hierarchical              OBJECT IDENTIFIER ::= {id-ob 2}

id-op-binding-non-specific-hierarchical OBJECT IDENTIFIER ::= {id-ob 3}

END