ГОСТ Р ИСО/МЭК 10021-6-97
Информационная технология. Передача текста. Системы обмена текстами, ориентированные на сообщения (MOTIS). Часть 6. Спецификации протокола

ГОСТ Р ИСО/МЭК 10021-6-97

Группа П85

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

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

     
ПЕРЕДАЧА ТЕКСТА. СИСТЕМЫ ОБМЕНА ТЕКСТАМИ,
 ОРИЕНТИРОВАННЫЕ НА СООБЩЕНИЯ (MOTIS)

Часть 6. Спецификации протокола

     
Information technology. Text communication.
Message-oriented text interchange systems (MOTIS).
Part 6. Protocol specifications

ОКС 35.240.20
ОКСТУ 4002

Дата введения 1998-07-01

     
Предисловие

1 РАЗРАБОТАН Московским научно-исследовательским центром (МНИЦ) Комитета при Президенте Российской Федерации по политике информатизации

ВНЕСЕН Комитетом при Президенте Российской Федерации по политике информатизации

2 ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 19 августа 1997 г. N 286

Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 10021-6-90 "Информационная технология. Передача текста. Системы обмена текстами, ориентированные на сообщения (MOTIS). Часть 6. Спецификации протокола"

3 ВВЕДЕН ВПЕРВЫЕ

ВВЕДЕНИЕ

ВВЕДЕНИЕ

Настоящая часть ГОСТ Р ИСО/МЭК 10021 - одна из совокупности частей ГОСТ Р ИСО/МЭК 10021 [стандарты по системам обмена текстами, ориентированным на сообщения (MOTIS)]. ГОСТ Р ИСО/МЭК 10021 обеспечивает исчерпывающую спецификацию обработки сообщений, охватывающую любое количество взаимодействующих открытых систем.

ГОСТ Р ИСО/МЭК 10021 состоит из нескольких частей, объединенных общим названием "Информационная технология. Передача текста. Системы обмена текстами, ориентированные на сообщения (MOTIS)":

- Часть 1. Общее описание системы и службы

- Часть 2. Общая архитектура

- Часть 3. Соглашения по определению абстрактных услуг

- Часть 4. Система передачи сообщений: определение абстрактных услуг и процедуры

- Часть 5. Хранилище сообщений: определение абстрактных услуг

- Часть 6. Спецификации протокола

- Часть 7. Система межперсональных сообщений

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

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

Настоящий стандарт подготовлен на основе международного стандарта, разработанного совместно МККТТ и ИСО/МЭК. Эквивалентным документом МККТТ является Рекомендация Х.419 МККТТ.

ГЛАВА ПЕРВАЯ. ВВЕДЕНИЕ

1 НАЗНАЧЕНИЕ

Настоящий стандарт определяет протокол доступа СПС (Р3), используемый между удаленным агентом пользователя и СПС для обеспечения доступа к абстрактным услугам СПС, определенным в ИСО/МЭК 10021-4.

Настоящий стандарт определяет также протокол доступа ХС (Р7), используемый между удаленным агентом-пользователя и хранилищем-сообщений (ХС) для обеспечения доступа к абстрактным услугам ХС, определенным в ГОСТ Р ИСО/МЭК 10021-5.

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

ИСО/МЭК 10021-2 идентифицирует другие стандарты, определяющие другие аспекты систем обработки сообщений.

Во второй главе настоящего стандарта определены протоколы доступа СОС (Р3 и Р7). В разделе 6 приведено общее описание протоколов доступа (Р3 и Р7). В разделе 7 определяется абстрактный синтаксис протокола доступа СПС (Р3), в разделе 8 - абстрактный синтаксис протокола доступа ХС (Р7), в разделе 9 - преобразование протокола доступа СОС в используемые услуги, в разделе 10 - требования к соответствию системных реализаций протоколам доступа СОС.

В третьей главе настоящего стандарта определен протокол передачи СПС (Р1). В разделе 11 приведено общее описание протокола доступа СПС (Р1). В разделе 12 определяется абстрактный синтаксис протокола передачи СПС (Р1), в разделе 13 - преобразование протокола передачи СПС (Р1) в используемые услуги, в разделе 14 - требования к соответствию систем, реализующих протокол передачи СПС (Р1).

В приложении В описаны протокольные правила взаимодействия с реализациями Рекомендации Х.411 (1984), использующими протокол передачи СПС (Р1).

В приложении С перечислены различия между Рекомендацией Х.411 (1984) и настоящим стандартом.

В приложении D перечислены технические различия между текстом Рекомендации Х.419 МККТТ и настоящим стандартом.

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

2.1 Взаимосвязь открытых систем

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

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

ГОСТ 34.973-91 Информационная технология. Взаимосвязь открытых систем. Спецификация абстрактно-синтаксической нотации версии 1 (АСН.1)

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

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

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

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

ИСО/МЭК 9594-2-90 Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 2. Модели

2.2 Системы обработки сообщений

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

ИСО/МЭК 10021-1-90 Информационная технология. Передача текста. Системы обмена текстами, ориентированные на сообщения (MOTIS). Часть 1. Общее описание системы и службы

ИСО/МЭК 10021-2-90 Информационная технология. Передача текста. Системы обмена текстами, ориентированные на сообщения (MOTIS). Часть 2. Общая архитектура

ИСО/МЭК 10021-3-90 Информационная технология. Передача текста. Системы обмена текстами, ориентированные на сообщения (MOTIS). Часть 3. Соглашения по определению абстрактных услуг

ИСО/МЭК 10021-4-90 Информационная технология. Передача текста. Системы обмена текстами, ориентированные на сообщения (MOTIS). Часть 4. Система передачи сообщений. Определение абстрактных услуг и процедуры

ГОСТ Р ИСО/МЭК 10021-5-96 Информационная технология. Передача текста. Системы обмена текстами, ориентированные на сообщения (MOTIS). Часть 5. Хранилище сообщений. Определение абстрактных услуг

ГОСТ Р ИСО/МЭК 10021-7-97 Информационная технология. Передача текста. Системы обмена текстами, ориентированные на сообщения (MOTIS). Часть 7. Система межперсональных сообщений

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

Определения приведены в ИСО/МЭК 10021-2.

4 СОКРАЩЕНИЯ

Сокращения перечислены в ИСО/МЭК 10021-2.

5 СОГЛАШЕНИЯ

В настоящем стандарте используются описательные соглашения, приведенные ниже.

5.1 Термины

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

5.2 Определения абстрактного синтаксиса

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

ГЛАВА ВТОРАЯ. СПЕЦИФИКАЦИИ ПРОТОКОЛОВ ДОСТУПА СИСТЕМ ОБРАБОТКИ СООБЩЕНИЙ

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

6.1 Модель протоколов доступа СОС

В разделе 6 ИСО/МЭК 10021-4 описана абстрактная модель систем передачи сообщений (СПС) и абстрактные услуги СПС, которые она предоставляет своим пользователям-СПС.

В разделе 6 ГОСТ Р ИСО/МЭК 10021-5 описана абстрактная модель хранилища сообщений (ХС) и абстрактные услуги СПС, которые оно обеспечивает своим пользователям-ХС.

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

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

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

Доступ к абстрактным услугам СПС обеспечивается тремя СЭП, каждый из которых поддерживает тип порта, который соединяет в абстрактной модели пользователя-СПС и саму СПС. Сервисный элемент предоставления сообщения (СЭПрС) обеспечивает услуги в порту предоставления; сервисный элемент доставки сообщения (СЭДС) обеспечивает услуги в порту доставки; сервисный элемент управления сообщением (СЭУС) обеспечивает услуги в административном порту. СЭПрС, СЭДС и СЭУС являются асимметричными-СЭП; то есть элементы СЭП пользователя-СЭП действуют в качестве потребителя, а элементы СЭП СПС - в качестве поставщика абстрактных услуг СПС.

Точно так же доступ к абстрактным услугам ХС обеспечивается тремя СЭП: сервисным элементом предоставления сообщения (СЭПрС), обеспечивающим порт-косвенного-предоставления; сервисным элементом поиска сообщений (СЭПсС), обеспечивающим услуги порта поиска, и сервисным элементом управления сообщением (СЭУС), обеспечивающим услуги административного-порта. СЭП пользователя-ХС действует в качестве потребителя, а СЭП ХС - в качестве поставщика абстрактных услуг ХС.

Эти сервисные-элементы-прикладного-уровня, в свою очередь, обеспечиваются другими сервисными-элементами-прикладного-уровня.

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

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

Сервисный элемент управления ассоциацией (СЭУА) обеспечивает установление и разъединение прикладной-ассоциации между парой ЛОП. Ассоциация между пользователем-СПС и СПС может устанавливаться либо пользователем-СПС, либо СПС. Ассоциация между пользоватслем-ХС и ХС может устанавливаться только пользователем-ХС. Разъединить установленную ассоциацию может только ее инициатор.

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

В таблице 1 идентифицированы прикладные-контексты, определенные в настоящем стандарте для протокола доступа СПС и протокола доступа ХС.


Таблица 1 - Прикладные контексты протокола доступа СОС

Прикладной контекст	СЭП обработки сообщений				Обеспечивающие СЭП
	СЭПрС	СЭДС	СЭПсС	СЭУС	СЭУО	СЭНП	СЭУА
Протокол доступа СПС
Доступ-спс	ПТ	ПТ	-	ПТ	Х	-	Х
Форсированный доступ-спс	ПС	ПС	-	ПС	Х	-	Х
Надежный-доступ-спс	ПТ	ПТ	-	ПТ	Х	Х	Х
Форсированный-надежный-доступ-спс	ПС	ПС	-	ПС	Х	Х	Х
Протокол доступа ХС
Доступ-хс	ПТ	-	ПТ	ПТ	Х	-	Х
Надежный -доступ-хс	ПТ	-	ПТ	ПТ	Х	Х	Х
Обозначения: Х - наличие; "-" - отсутствие; ПТ - имеется при инициации со стороны потребителя; ПС - имеется при инициации со стороны поставщика

Если обеспечивается протокол доступа СПС (Р3), то обеспечение прикладных-контекстов доступ-СПС и форсированный-доступ-СПС является обязательным для АПС. Если АПС обеспечивает прикладной-контекст надежный-доступ-СПС, он должен обеспечивать также форсированный-надежный-доступ-СПС, и наоборот. Обеспечение каждого прикладного-контекста протокола доступа СПС (Р3) является факультативным для пользователя-СПС.

Если обеспечивается протокол доступа ХС (Р7), то обеспечение прикладного-контекста доступ-ХС обязательно для ХС, а обеспечение прикладного-контекста надежный-доступ-ХС - факультативно. Обеспечение каждого из прикладных-контекстов протокола доступа ХС (Р7) является факультативной возможностью пользователя-ХС.

На рисунке 1 приведена модель прикладного-контекста между пользователем-СПС и СПС. Роль потребителя СЭП пользователя-СПС и роль поставщика СЭП СПС указана индексами "ПТ" и "ПС" соответственно.

Рисунок 1 - Модель протокола доступа СПС

Рисунок 1 - Модель протокола доступа СПС

Аналогичным образом на рисунке 2 изображена модель прикладного-контекста между пользователем-ХС и ХС.

Рисунок 2 - Модель протокола доступа ХС

Рисунок 2 - Модель протокола доступа ХС

6.2 Услуги, обеспечиваемые протоколом доступа СПС

Протокол доступа СПС (Р3) охватывает следующие операции, которые обеспечивают услуги, определенные в ИСО/МЭК 10021-4:

Связка-СПС и развязка-СПС

а) Связка-СПС

б) Развязка-СПС

Сервисный элемент предоставления сообщения (СЭПрС)

в) предоставление-сообщения

г) предоставление-зонда

д) аннулирование-задержанной-доставки

е) управление-предоставлением

Сервисный элемент доставки сообщения (СЭДС)

ж) доставка-сообщения

и) отчет-о-доставке

к) управление-доставкой

Сервисный элемент управления сообщением (СЭУС)

л) регистрация

м) изменение-удостоверения-личности.

6.3 Услуги, обеспечиваемые протоколом доступа ХС

Протокол доступа ХС (Р7) охватывает следующие операции, которые обеспечивают услуги, определенные в ГОСТ Р ИСО/МЭК 10021-5:

Связка-ХС и развязка-ХС

а) Связка-ХС

б) Развязка-ХС

Сервисный элемент предоставления сообщения (СЭПрС)

в) предоставление-сообщения

г) предоставление-зонда

д) аннулирование-задержанной-доставки

е) управление-предоставлением

Сервисный элемент поиска сообщения (СЭПсС)

ж) суммирование

и) перечисление

к) извлечение

л) удаление

м) регистрация-ХС

н) изменение

Сервисный элемент управления сообщением (СЭУС)

п) регистрация

р) изменение-удостоверения-личности.

6.4 Использование нижерасположенных услуг

Протоколы доступа СОС используют нижерасположенные услуги в соответствии с нижеизложенным.

6.4.1 Использование услуг СЭУО

Сервисный элемент удаленных операций (СЭУО) определен в ГОСТ Р ИСО/МЭК 9072-1.

СЭУО обеспечивает парадигм запрос/ответ удаленных операций.

Элементы СЭПрС, СЭДС, СЭПсС и СЭУС являются единственными пользователями услуг СЭУО УО-ПРИВЛЕЧЕНИЕ, УО-РЕЗУЛЬТАТ, УО-ОШИБКА, УО-Пл-ОТКЛОНЕНИЕ и УО-Пс-ОТКЛОНЕНИЕ.

Удаленные операции протокола доступа СПС (Р3) и протокола доступа ХС (Р7) являются операциями (асинхронными) класса 2.

6.4.2 Использование услуг СЭНП

Сервисный элемент надежной передачи (СЭНП) определен в ГОСТ Р ИСО/МЭК 9066-1.

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

Определены альтернативные прикладные-контексты с СЭНП и без него для обеспечения протоколов доступа СОС.

СЭНП используется в нормальном режиме. Использование нормального режима СЭНП предполагает использование нормального режима СЭУА и нормального режима услуг-уровня-представления.

Если СЭНП включен в прикладной-контекст, то операции связка-СПС и развязка-СПС (связка-ХС и развязка-ХС) протокола доступа СОС являются единственными пользователями услуг СЭНП НП-ОТКРЫТИЕ и НП-ЗАКРЫТИЕ. Элемент СЭУО является единственным пользователем услуг СЭНП НП-ПЕРЕДАЧА, НП-ЗАПРОС-ПОЛНОМОЧИЙ, НП-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ, НП-Пс-ПРЕРЫВАНИЕ и НП-Пл-ПРЕРЫВАНИЕ.

6.4.3 Использование услуг СЭУА

Сервисный элемент управления ассоциацией (СЭУА) определен в ГОСТ 34.981.

СЭУА обеспечивает управление прикладной-ассоциации (установлением, разъединением, прерыванием) между ЛОП.

Если СЭНП не включен в прикладной-контекст, то операции связка-СПС и развязка-СПС (связка-ХС и развязка-ХС) протокола доступа СОС являются единственными пользователями услуг П-АССОЦИАЦИЯ и П-РАЗЪЕДИНЕНИЕ элемента СЭУА в нормальном режиме. Элемент СЭУО является пользователем услуг СЭУО П-ПРЕРЫВАНИЕ и П-Пс-ПРЕРЫВАНИЕ.

Если СЭНП включен в прикладной-контекст, то СЭНП является единственным пользователем услуг СЭУА П-АССОЦИАЦИЯ, П-РАЗЪЕДИНЕНИЕ, П-ПРЕРЫВАНИЕ и П-Пс-ПРЕРЫВАНИЕ. Использование нормального режима СЭНП предполагает использование нормального режима СЭУА и нормального режима услуг-уровня-представления.

6.4.4 Использование услуг-уровня-представления

Услуги-уровня-представления определены в ГОСТ 34.971.

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

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

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

Если СЭНП не включен в прикладной-контекст, то СЭУО является единственным пользователем услуги уровня-представления Пк-ДАННЫЕ.

Если СЭНП включен в прикладной-контекст, то СЭНП является единственным пользователем услуг-уровня-представления Пк-НАЧАЛО-АКТИВНОСТИ, Пк-ДАННЫЕ, Пк-МЛАДШАЯ-СИНХРОНИЗАЦИЯ, Пк-КОНЕЦ-АКТИВНОСТИ, Пк-ПРЕРЫВАНИЕ-АКТИВНОСТИ, Пк-АННУЛИРОВАНИЕ-АКТИВНОСТИ, Пк-Пл-ОТЧЕТ-ОБ-ОСОБОМ-СЛУЧАЕ, Пк-ВОЗОБНОВЛЕНИЕ-АКТИВНОСТИ, Пк-Пс-ОТЧЕТ-ОБ-ОСОБОМ-СЛУЧАЕ, Пк-ЗАПРОС-ПОЛНОМОЧИЙ и Пк-ПРЕДОСТАВЛЕНИЕ-УПРАВЛЕНИЯ. Использование нормального режима СЭНП предполагает использование нормального режима СЭУА и нормального режима услуг-уровня-представления.

7 ОПРЕДЕЛЕНИЕ АБСТРАКТНОГО СИНТАКСИСА ПРОТОКОЛА ДОСТУПА СПС

Абстрактный-синтаксис протокола доступа СПС (Р3) определен на рисунке 3.

Абстрактный синтаксис протокола доступа СПС (Р3) определен с использованием абстрактно-синтаксической нотации АСН.1, определенной в ГОСТ 34.973, и нотации удаленных операций, определенной в ГОСТ Р ИСО/МЭК 9072-1.

Определение абстрактного синтаксиса протокола доступа СПС (Р3) состоит из следующих основных частей:

- Пролог - объявления экспорта из модуля "доступ протокола СПС" (Р3) и импорта в этот модуль (рисунок 3, лист 1).

- Прикладные контексты - определения прикладных-контекстов, которые могут использоваться между пользователями-СПС и самой СПС (рисунок 3, листы 1 и 2).

- Сервисный элемент предоставления сообщения - определения сервисного элемента предоставления сообщений (СЭПрС), его удаленных операций и ошибок (рисунок 3, лист 3).

- Сервисный элемент доставки сообщения - определения сервисного элемента доставки сообщений (СЭДС), его удаленных операций и ошибок (рисунок 3, лист 4).

- Сервисный элемент управления сообщением - определения сервисного элемента управления сообщениями (СЭУС), его удаленных операций и ошибок (рисунок 3, лист 4).

Рисунок 3 (Лист 1) - Определение абстрактного синтаксиса протокола доступа СПС (Р3)

	MTSAccessProtocol {joint-iso-ccitt mhs-motis(6) protocols(0) modules(0) mts-access-protocol(1)}
	DEFINITIONS IMPLICIT TAGS :: =
	BEGIN
			- - Пролог
	EXPORTS
			- - Сервисные элементы прикладного уровня
			mSSE, mDSE, mASE;
	IMPORTS
			- - Сервисные элементы прикладного уровня и прикладные контексты
			APPLICATION-SERVICE-ELEMENT, APPLICATION-CONTEXT, aCSE
				FROM Remote-Operations-Notation-extension { joint-iso-ccitt
					remote-operations(4) notation-extension(2) }
			rTSE
				FROM Reliable-Transfer-APDUs { joint-iso-ccitt reliable-trans-
				fer(3) apdus(0) }
			- - Параметры абстрактных услуг СПС
			MTsBind, MTSUnbind, MessageSubmission, ProbeSubmission, CancelDeferredDelivery, SubmissionControl, MessageDelivery, ReportDelivery, DeliveryControl, Register, ChangeCredentials, SubmissionControlViolated, ElementOfServiceNotSubscribed, DeferredDeliveryCancellationRejected, Originatorlnvalid, RecipientImproperlySpecified, MessageSubmissionIdentifierInvalid, InconsistentRequest, SecurityError, UnsupportedCriticalFunction, RemoteBindError, DeliveryControlViolated, ControlViolatesRegistration, RegisterRejected, NewCredentialsUnacceptable, OldCredentialsIncorrectlySpecified
				FROM MTSAbstractService { joint-iso-ccitt mhs-motis(6) mts(3)
						modules(0) mts-abstract-service(1)}
			- - Объектные идентификаторы
			id-ac-mts-access, id-ac-mts-forced-access, id-ac-mts-reliable-access, id-ac-mts-forced-reliable-access,
			id-as-acse, id-as-msse, id-as-mdse, id-as-mrse, id-as-mase, id-as-mts, id-as-mts-rtse, id-ase-msse, id-ase-mdse, id-ase-mase
				FROM MHSProtocoIObjectIdentifiers { joint-iso-ccitt mhs-motis(6) protocols(0)
				- - Прикладные контексты без СЭНП - - Инициировано пользователем-СПС
				mts-access APPLICATION-CONTEXT
							APPLICATION SERVICE ELEMENTS {aCSE}
							BIND MTSBind
							UNBIND MTSUnbind
							REMOTE OPERATIONS {rOSE}
							UNITIATOR CONSUMER OF {mSSE, mDSE mASE}
							ABSTRACT SYNTAXES {
								id-as-acse,	- - of ACSE
								id-as-msse,	- - of MSSE, including ROSE
								id-as-mdse,	- - of MDSE, including ROSE
								id-as-mase,	- - of MASE, including ROSE
								id-as-mts	- - of MTSBind and MTSUnbind - -}
		:: = id-ac-mts-access

Рисунок 3 (Лист 1) - Определение абстрактного синтаксиса протокола доступа СПС (Р3)

Рисунок 3, лист 2

	- - Инициировано СПС
	mts-forced-access APPLICATION-CONTEXT
			APPLICATION SERVICE ELEMENTS {aCSE}
			BIND MTSBind
			UNBIND MTSUnbind
			REMOTE OPERATIONS {rOSE}
			RESPONDER CONSUMER OF {mSSE, mDSE, mASE}
			ABSTRACT SYNTAXES {
				id-as-acse,	- - СЭУА
				id-as-msse,	- - СЭПрС, включая СЭУО
				id-as-mdse,	- - СЭДС, включая СЭУО
				id-as-mase,	- - СЭУС, включая СЭУО
				id-as-mts	- - СПССвязка и СПСРазвязка - -}
		: : = id-ас-mts-forced-access

- - Прикладные контексты, содержащие СЭНП нормального режима

- - Инициировано пользователем-СПС

	mts-reliable-access APPLICATION-CONTEXT
		APPLICATION SERVICE ELEMENTS {aCSE, rTSE}
		BIND MTSBind
		UNBIND MTSUnbind
		REMOTE OPERATIONS {rOSE}
		UNITIATOR CONSUMER OF {mSSE, mDSE, mASE}
		ABSTRACT SYNTAXES {
				id-as-acse,	- - of ACSE
				id-as-msse,	- - of MSSE, including ROSE
				id-as-mdse,	- - of MDSE, including ROSE
				id-as-mase,	- - of MASE, including ROSE
				id-as-mts-rtse	- - of MTSBind and MTSUnbind including RTSE - -}
			: : = id-ac-mts-reliable-access

- - Инициировано СПС

	mts-forced-reliable-access APPLICATION-CONTEXT
		APPLICATION SERVICE ELEMENTS {aCSE, rTSE)
		BIND MTSBind
		UNBIND MTSUnbind
		REMOTE OPERATIONS {rOSE}
		RESPONDER CONSUMER OF {mSSE, mDSE, mASE}
		ABSTRACT SYNTAXES {
				id-as-acse,	- - СЭУА
				id-as-msse,	- - СЭПрС, включая СЭУО
				id-as-mdse,	- - СЭДС, включая СЭУО
				id-as-mase,	- - СЭУС, включая СЭУО
				id-as-mts-rtse	- - СПССвязка и СПСРазвязка, включая СЭНП- -}
			:: = id-ac-mts-forced-reliable-access

Рисунок 3, лист 2

Рисунок 3, лист 3

	- - Сервисный элемент предоставления сообщения
	mSSE APPLICATION-SERVICE-ELEMENT
		CONSUMER INVOKES {
			message-submission,
			probe-submission,
			cancel-deferred-delivery}
		SUPPLIER INVOKES {
			submission-control}
		:: = id-ase-msse
	- - Удаленные операции
	message-submission MessageSubmission :: = 3
	probe-submission ProbeSubmission :: = 4
	cancel-deferred-delivery CancelDeferredDelivery :: = 7
	submission-control SubmissionControl :: = 2

- - Удаленные ошибки submission-control-violated SubmissionControlViolated :: = 1 element-of-service-not-subscribed ElementOfServiceNotSubscribed :: = 4 deferred-delivery-cancellation-rejected DeferredDeliveryCancellationRejected :: = 8 originator-invalid Onginatorlnvalid :: = 2 recipient-improperly-specified RecipientImproperlySpecified :: = 3 message-submission-identifier-invalid MessageSubmissionIdentifierInvalid :: = 7 inconsistent-request InconsistentRequest :: = 11 security-error SecurityError :: = 12 unsupported-critical-function UnsupportedCriticalFunction :: = 13 remote-bind-error RemoteBindError :: = 15

Рисунок 3, лист 3

	- - Сервисный элемент доставки сообщения
	mDSE APPLICATION-SERVICE-ELEMENT
		CONSUMER INVOKES {
			delivery-control }
		SUPPLIER INVOKES {
			message-delivery,
			report-delivery}
		:: = id-ase-mdse

- - Удаленные операции

message-delivery MessageDelivery :: = 5

report-delivery ReportDelivery :: = 6

delivery-control DeliveryControl :: = 2

- - Удаленные ошибки

delivery-control-violated DeliveryControlViolated :: = 1

control-violates-registration ControlViolatesRegistration :: = 14

- - security-error :: = 12, defined in Part 4

- - unsupported-critical-function :: = 13, defined in Part 4

- - Сервисный элемент управления сообщением

mASE APPLICATION-SERVICE-ELEMENT

	CONSUMER INVOKES {
		register,
		change-credentials}
	SUPPLIER INVOKES {
		change-credentials}
	:: = id-ase-mase

- - Удаленные операции

register Register :: = 1

change-credentials ChangeCredentials :: = 8

- - Удаленные ошибки

register-rejected RegisterRejected :: = 10

new-credentials-unacceptable NewCredentialsUnacceptable :: = 6

old-credentials-incorrectly-specified OldCredentialsIncorrectlySpecified :: = 5

END - - of MTSAccessProtocol

Рисунок 3, лист 4

8 ОПРЕДЕЛЕНИЕ АБСТРАКТНОГО СИНТАКСИСА ПРОТОКОЛА ДОСТУПА ХС

Абстрактный-синтаксис протокола доступа ХС (Р7) определен на рисунке 4.

Абстрактный синтаксис протокола доступа ХС (Р7) определен с использованием абстрактно-синтаксической нотации АСН.1, определенной в ГОСТ 34.973, и нотации удаленных операций, определенной в ГОСТ Р ИСО/МЭК 9072-1.

Определение абстрактного синтаксиса протокола доступа ХС (Р7) состоит из следующих основных частей:

- Пролог - объявления экспорта из модуля "протокол доступа ХС" (Р3) и импорта в этот модуль (рисунок 4).

- Прикладные контексты - определения прикладных-контекстов, которые могут использоваться между пользователями-ХС и самой ХС (рисунок 4).

- Сервисный элемент поиска сообщений - определение сервисного элемента поиска сообщений (СЭПсС), его удаленных операций и ошибок (рисунок 4).

Рисунок 4 (Лист 1) - Определение абстрактного синтаксиса протокола доступа ХС (Р7)

MSAccessProtocol {joint-iso-ccitt mhs-motis(6) protocols(0) modules(0) ms-access-protocol(2)}

DEFINITIONS IMPLICIT TAGS :: =

BEGIN

- - Пролог
EXPORTS
		mRSE;
IMPORTS
	- - Сервисные элементы прикладного уровня и прикладные контексты
	APPLICATION-SERVICE-ELEMENT, APPLICATION-CONTEXT, aCSE
			FROM Remote-Operations-Notation-extension { joint-iso-ccitt remote-
			operations(4) notation-extension(2)}
	rTSE
			FROM Reliable-Transfer-APDUs {joint-iso-ccitt reliable-transfer(3) apdus(0)}
	mSSE, mASE
				FROM MTSAccessProtocol {joint-iso-ccitt mhs-motis(6) protocols(0) modules(0) mts-access-protocol(1)}

- - Параметры абстрактных услуг ХС
MSBind, MSUnbind, Summarize, List, Fetch, Delete, Register-MS, Alert, AttributeError, AutoActionRequestError, DeleteError, FetchRestrictionError, RangeError, SecurityError, ServiceError, SequenceNumberError
	FROM MSAbstractService {joint-iso-ccitt mhs-motis(6) ms(4) modules(0) abstract-service(1)}
- - Объектные идентификаторы
id-ac-ms-access, id-ac-ms-reliable-access, id-as-acse, id-as-msse, id-as-mrse, id-as-mase, id-as-ms, id-as-ms-rtse,
id-ase-mrse
	FROM MHSProtocolObjectIdentifiers {joint-iso-ccitt mhs-motis(6) ms(4) modules(0) object-identifiers(0)};

Рисунок 4 (Лист 1) - Определение абстрактного синтаксиса протокола доступа ХС (Р7)

Рисунок 4, лист 2

- - Прикладкой контекст без СЭНП
ms-access APPLICATION-CONTEXT
	APPLICATION SERVICE ELEMENTS {aCSE}
	BIND MSBind
	UNBIND MSUnbind
	REMOTE OPERATIONS {rOSE}
	UNITIATOR CONSUMER OF {mSSE, mRSE, mASE}
	ABSTRACT SYNTAXES {
		id-as-acse,	- - of ACSE
		id-as-msse,	- - of MSSE, including ROSE
		id-as-mrse,	- - of MRSE, including ROSE
		id-as-mase,	- - of MASE, including ROSE
		id-as-ms	- - of MSBind and MSUnbind - -}
	:: = id-ac-ms-access

- - Прикладной контекст, содержащий СЭНП
ms-reliable-access APPLICATION-CONTEXT
	APPLICATION SERVICE ELEMENTS {aCSE, rTSE)
	BIND MSBind
	UNBIND MSUnbind
	REMOTE OPERATIONS {rOSE}
	INITIATOR CONSUMER OF {mSSE, mRSE, mASE}
	ABSTRACT SYNTAXES {
		id-as-acse,	- - СЭУА
		id-as-msse,	- - СЭПрС, включая СЭУО
		id-as-mrse,	- - СЭПсС, включая СЭУО
		id-as-mase,	- - СЭУС, включая СЭУО
		id-as-ms-rtse	- - ХССвязка и ХСРазвязка - -}
	:: = id-ac-ms-reliable-access

- - Сервисный элемент поиска сообщения
mRSE APPLICATION-SERVICE-ELEMENT
	CONSUMER INVOKES {
		summarize,
		list,
		fetch,
		delete,
		register-MS}
	SUPPLIER INVOKES {
		alert}
	:: = id-ase-mrse

- - Удаленные операции

summarize Summarize:: = 20

list List :: = 21

fetch Fetch :: = 22

delete Delete :: = 23

register-ms Register-MS :: = 24

alert Alert :: = 25

Рисунок 4, лист 2

Рисунок 4, лист 3

- - Удаленные ошибки

attribute-error AttributeError :: = 21

auto-action-request-error AutoActionRequestError :: = 22

delete-error DeleteError :: = 23

fetch-restriction-error FetchRestrictionError :: = 24

range-error RangeError :: = 25

security-error SecurityError :: = 26

service-error ServiceError:: = 27

sequence-number-error SequenceNumberError :: = 28

END - - протокола Доступа ХС

Рисунок 4, лист 3

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

В данном разделе определяется преобразование протоколов доступа СОС в используемые услуги.

В подразделе 9.1 определяется преобразование в используемые услуги для тех прикладных-контекстов, где отсутствует СЭНП. В подразделе 9.2 определено преобразование протокола в используемые услуги для тех прикладных-контекстов, в которых имеется СЭНП.

9.1 Прикладные протоколы при отсутствии СЭНП

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

9.1.1 Преобразование в СЭУА

В этом подразделе определяется преобразование услуг абстрактной-связки (связка-СПС или связка-ХС) и абстрактной-развязки (развязка-СПС и развязка-ХС) в услуги СЭУА в нормальном режиме для тех прикладных-контекстов, где отсутствует СЭНП. Элемент СЭУА определен в ГОСТ 34.981.

9.1.1.1 Абстрактная-связка - в Пк-АССОЦИАЦИЯ

Услуга абстрактная-связка преобразуется в услугу СЭУА Пк-АССОЦИАЦИЯ. Использование параметров услуги Пк-АССОЦИАЦИЯ рассматривается в следующих подразделах.

9.1.1.1.1 Режим

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

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

Инициатор ассоциации должен предложить один из контекстов, определенных в настоящем стандарте, при котором в примитиве Пк-АССОЦИАЦИЯ запрос отсутствует СЭНП (см. таблицу 1).

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

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

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

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

Список определений контекста уровня представления для каждого абстрактного-синтаксиса включен в прикладной-контекст. В определение-контекста-уровня-представления входит идентификатор-контекста-уровня-представления и имя-абстрактного-синтаксиса для СЭП. Каждый поименованный абстрактный синтаксис для СЭПрС, СЭДС, СЭПсС и СЭУС включает в себя ПБДП СЭУО.

В разделах 7 и 8 определены абстрактные-синтаксисы, входящие в состав прикладных-контекстов.

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

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

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

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

а) ядро;

б) дуплекс.

9.1.1.2 Абстрактная-развязка - в Пк-РАЗЪЕДИНЕНИЕ

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

9.1.1.2.1 Результат

Этот параметр должен иметь значение "подтверждение".

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

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

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

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

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

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

9.2.1 Преобразование в НП-ОТКРЫТИЕ и НП-ЗАКРЫТИЕ

В этом подразделе определяется преобразование услуг абстрактной-связки (связка-СПС и связка-ХС) и абстрактной-развязки (развязка-СПС и развязка-ХС) в услуги СЭНП НП-ОТКРЫТИЕ и НП-ЗАКРЫТИЕ в нормальном режиме работы.

9.2.1.1 Преобразование абстрактной-связки в НП-ОТКРЫТИЕ

Услуга абстрактной-связки преобразуется в услугу СЭНП НП-ОТКРЫТИЕ. Использование параметров услуги НП-ОТКРЫТИЕ рассмотрено в следующих подразделах.

9.2.1.1.1 Режим

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

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

Инициатор ассоциации должен предлагать один из тех прикладных-контекстов, определенных в настоящем стандарте, которые в примитиве НП-ОТКРЫТИЕ запрос содержат СЭНП нормального режима (см. таблицу 1).

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

Преобразование операции-связки услуги абстрактная-связка в параметр данные-пользователя примитива НП-ОТКРЫТИЕ запрос определено в ГОСТ Р ИСО/МЭК 9072-1.

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

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

Список определений контекста уровня представления содержит определение-контекста-уровня-представления для каждого абстрактного-синтаксиса, входящего в прикладной контекст. Определение-контекста-уровня-представления содержит идентификатор-контекста-уровня-представления и имя-абстрактного-синтаксиса СЭП. Каждый поименованный абстрактный-синтаксис элементов СЭПрС, СЭДС, СЭПсС и СЭУС содержит ПБДП СЭУО. Поименованный абстрактный-синтаксис СЭНП содержит абстрактный-синтаксис операции-связки услуги абстрактной-связки.

В разделах 7 и 8 настоящего стандарта определены абстрактные-синтаксисы, входящие в прикладные-контексты.

9.2.1.2 Преобразование абстрактной-развязки в НП-ЗАКРЫТИЕ

Услуга абстрактная-развязка преобразуется в услугу СЭНП НП-ЗАКРЫТИЕ.

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

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

СЭУО является пользователем услуг СЭНП НП-ПЕРЕДАЧА, НП-ЗАПРОС-ПОЛНОМОЧИЙ, НП-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ, НП-Пс-ПРЕРЫВАНИЕ и НП-Пл-ПРЕРЫВАНИЕ. Использование услуг СЭНП элементом СЭУО определено в ГОСТ Р ИСО/МЭК 9072-2.

9.2.2.1 Управление полномочиями

ГОСТ Р ИСО/МЭК 9072-2 определяет использование элементом СЭУО услуг СЭНП НП-ЗАПРОС-ПОЛНОМОЧИЙ и НП-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ для управления полномочиями.


Таблица 2 - Приоритеты удаленных операций

Приоритет	СЭПрС	СЭДС	СЭПвС	СЭУС
0	Разъединение ассоциации
1	УО-Пл-ОТКЛОНЕНИЕ УО-ОШИБКА
2	УО-РЕЗУЛЬТАТ
3	Управление-предоставлением	Управление-доставкой
4	Предоставление-сообщения (срочный)	Доставка-сообщения (срочный)	Сигнализация состояния
5	Предоставление-зонда	Доставка-отчета	Регистрация ХС Суммирование Список Извлечение Аннулирование	Регистрация Изменение- удостоверений-личности
6	Предоставление-сообщения (нормальный)	Доставка-сообщения (нормальный)
7	Предоставление-сообщения (несрочный)	Доставка-сообщения

В таблице 2 определены значения параметра "приоритет" услуги НП-ЗАПРОС-ПОЛНОМОЧИЙ, используемой элементом СЭУО для запроса полномочий.

Приоритет "ноль" является наивысшим приоритетом и зарезервирован для действий инициатора ассоциации по ее разъединению.

Приоритет "единица" используется элементом СЭУО для ПБДП УООТ и ПБДП УООШ с целью обеспечения услуг СЭУО УО-Пл-ОТКЛОНЕНИЕ и УО-ОШИБКА.

Приоритет "два" используется СЭУО для ПБДП УОРЗ с целью обеспечения услуги СЭУО УО-РЕЗУЛЬТАТ.

Приоритет от трех до семи должен использоваться для ПБДП УОПВ с целью обеспечения услуги УО-ПРИВЛЕЧЕНИЕ при выполнении удаленных операций протокола доступа СОС. При выполнении удаленной операции, в аргументы которой входит сообщение, приоритет. ПБДП УОПВ определяется как функция приоритета сообщения - срочный, нормальный или несрочный.

10 СООТВЕТСТВИЕ

Система (АП, ХС или АПС), претендующая на свое соответствие протоколам доступа СОС, определенным в настоящем стандарте, должна отвечать требованиям, приведенным в подразделах 10.1, 10.2 и 10.3.

10.1 Требования к заявке

Должно быть заявлено следующее:

а) тип системы, соответствие которой заявляется (АП, ХС, АПС или АПС/ХС);

б) прикладные-контексты, определенные во второй главе настоящего стандарта, соответствие которым заявляется.

Может быть заявлено соответствие либо протоколу доступа СПС (Р3), либо протоколу доступа ХС (Р7), либо тому и другому. В таблице 3 классифицировано обеспечение прикладных-контекстов, необходимых для соответствия протоколу доступа СПС (Р3). В таблице 4 классифицировано обеспечение прикладных-контекстов, необходимых для соответствия протоколу доступа ХС (Р7).


Таблица 3 - Требования к соответствию протоколам доступа СПС

Прикладной контекст	АПС	Пользователь-СПС
Протокол доступа СПС
Доступ-спс	Обязательно	Факультативно
Форсированный-доступ-спс	Обязательно	Факультативно
Надежный-доступ-спс	Факультативно (см. примечание)	Факультативно
Форсированный-надежный-доступ-спс	Факультативно (см. примечание)	Факультативно

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


Таблица 4 - Требования к соответствию протокола доступа ХС

Прикладной контекст	ХС	Пользователь-ХС
Протокол доступа ХС
Доступ-ХС	Обязательно	Факультативно
Надежный-доступ-ХС	Факультативно	Факультативно

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

Система должна:

а) соответствовать определению(ям) протоколов доступа СОС, определенных в разделах 7 и 8 настоящего стандарта, требуемых теми прикладными-контекстами, соответствие которым заявлено.

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

Система должна:

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

б) соответствовать использованию нижерасположенных услуг, определенных в 6.4 настоящего стандарта.

ГЛАВА ТРЕТЬЯ. СПЕЦИФИКАЦИЯ ПРОТОКОЛА ПЕРЕДАЧИ СИСТЕМЫ ПЕРЕДАЧИ СООБЩЕНИЙ

11 ОБЩЕЕ ОПИСАНИЕ ПРОТОКОЛА ПЕРЕДАЧИ СПС

11.1 Модель

В разделе 10 ИСО/МЭК 10021-4 приведена уточненная модель системы передачи сообщений (СПС), впервые представленная в разделе 6 ИСО/МЭК 10021-4 с целью показать, что объект СПС содержит совокупность объектов агент-передачи-сообщений (АПС), которые взаимодействуют для формирования СПС и обеспечивают абстрактные-услуги СПС ее пользователям.

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

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

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

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

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

Сервисный элемент управления ассоциацией (СЭУА) обеспечивает установление и разъединение ассоциации между двумя ЛОП. Ассоциации между АПС могут устанавливаться любым АПС. Разъединить ассоциацию может только ее инициатор.

Сочетание элементов СЭПС, СЭНП и СЭУА образует прикладной-контекст прикладной-ассоциации.

На рисунке 5 приведена модель прикладного-контекста между АПС.

Рисунок 5 - Модель протокола передачи СПС

Рисунок 5 - Модель протокола передачи СПС

Таблица 5 - Прикладные контексты протокола передачи СПС

Прикладной контекст	Р1	Режим СЭНП
Передача-спс	Р1 1988	Нормальный
Протокол-передачи-спс	Р1 1988	Х.410 - 1984
Протокол-передачи-спс-1984	P1 1984	Х.410 - 1984

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

- АПС типа А способен на взаимодействие со всеми другими АПС, претендующими на соответствие настоящему стандарту, но не взаимодействует с АПС в РУ, претендующими на соответствие Рекомендации Х.419 МККТТ, если те АПС не реализуют прикладной контекст передача-спс. Это пригодно для внутрирегиональной связи и непосредственной связи с АПС в других РУ, претендующих на соответствие настоящему стандарту (типичный РУЧП), но не для непосредственной связи с РУ, которые претендуют только на соответствие Рекомендации Х.411 МККТТ 1984 или только на минимальное соответствие требованиям Рекомендации Х.419 МККТТ 1988 (типичный РАУ).

- АПС типа В имеет возможности взаимодействия на уровне АПС типа А и, кроме того, он способен на взаимодействие с любым РУ (типичный РАУ), претендующим на соответствие Рекомендации Х.419 МККТТ.

- АПС типа С располагает, помимо возможностей взаимодействия на уровнях АПС типа А и АПС типа В, способностью взаимодействия с РУ, реализующих Рекомендации серии Х.400 МККТТ 1984.

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

Протокол-передачи-спс определен с целью обеспечения взаимодействий между реализациями, которые обеспечивают расширенный набор функций 1988 через системы, получившие минимальное развитие относительно соответствия Рекомендации Х.411 1984. Протокол-передачи-спс обеспечивает управляемую прозрачность получивших развитие систем для расширений 1988. Протокол-передачи-спс обеспечивается элементом СЭНП в режиме Х.410-1984. Обеспечение протокола-передачи-спс не требуется для АПС типа А, но обязательно для АПС типа В и АПС типа С для соответствия настоящему стандарту. Заметим, что обеспечение протокола-передачи-спс является обязательным для соответствия Рекомендации Х.419 МККТТ.

Протокол-передачи-спс-1984 определен для взаимодействия с реализациями, соответствующими Рекомендации Х.411 1984. В этом прикладном-контексте абстрактный-синтаксис СЭПС ограничен определениями Рекомендации Х.411 1984. Эти ограничения идентифицируются подчеркиваниями в расширениях 1988 абстрактного синтаксиса СЭПС при определении модуля АСН.1 в ИСО/МЭК 10021-4. Эти изменения перечислены также в приложении С настоящего стандарта для ссылок на них. Протокол-передачи-спс-1984 обеспечивается СЭПС в режиме Х.410-1984. Обеспечение протокола-передачи-спс-1984 не требуется для АПС типа А и АПС типа В, но является обязательным для АПС типа С для соответствия настоящему стандарту. Заметим, что обеспечение протокола-передачи-спс-1984 является обязательным для соответствия Рекомендации Х.419 МККТТ.

В таблице 6 обобщены характеристики взаимодействия сочетаний прикладных-контекстов, допустимые требованиями соответствия стандартов ИСО/МЭК и Рекомендаций МККТТ. Допустимые сочетания приведены в таблице 7.


Таблица 6 - Взаимодействие между СОТОС ИСО/МЭК и Х.400 МККТТ

СОТОС	МККТТ
	Х.400 (1984)	Х.400 (1988)
		Реализация, исключающая ПК передача-спс	Реализация, включающая ПК передача-спс
AПС типа А	Н	Н	Д
АПС типа В	Н	Д	Д
АПС типа С	Д	Д	Д
Обозначения: Д - взаимодействие гарантировано; Н - взаимодействие не гарантировано.

11.2 Услуги, обеспечиваемые протоколом передачи СПС

Протокол передачи СПС (Р1) обеспечивает следующие услуги, определенные в ИСО/МЭК 10021-4:

Связка-СПС и развязка-СПС

а) связка-СПС;

б) развязка-СПС;

Сервисный элемент передачи сообщений (СЭПС)

в) передача сообщения;

г) передача-зонда;

д) передача-отчета.

11.3 Использование нижерасположенных услуг

Протокол передачи СПС (Р1) использует нижерасположенные услуги изложенным ниже способом.

11.3.1 Использование услуг СЭНП

Сервисный элемент надежной передачи (СЭНП) определен в ГОСТ Р ИСО/МЭК 9066-1.

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

Услуги СЭНП используются для обеспечения протокола передачи СПС (Р1). Обеспечение СЭНП в режиме Х.410-1984 не требуется для АПС типа А, но обязательно для АПС типа В и АПС типа С. Заметим, что в Рекомендации Х.419 МККТТ обеспечение СЭНП в нормальном режиме обязательно, а обеспечение СЭНП в режиме Х.410-1984 факультативно.

Использование нормального режима работы СЭНП предполагает использование нормального режима СЭУА и нормального режима услуг-уровня-представления. Использование режима Х.410-1984 СЭНП предполагает использование режима Х.410-1984 СЭУА и режима Х.410-1984 услуг-уровня-представления.

Протокол передачи СПС (Р1) является единственным пользователем услуг СЭНП НП-ОТКРЫТИЕ, НП-ЗАКРЫТИЕ, НП-ПЕРЕДАЧА, НП-ЗАПРОС-ПОЛНОМОЧИЙ, НП-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ, НП-Пс-ПРЕРЫВАНИЕ и НП-Пл-ПРЕРЫВАНИЕ.

11.3.2 Использование услуг СЭУА

Сервисный элемент управления ассоциацией (СЭУА) определен в ГОСТ 34.981.

СЭУА обеспечивает управление прикладными-ассоциациями (установлением, разъединением, прерыванием) между ЛОП.

СЭНП является единственным пользователем услуг СЭУА Пк-АССОЦИАЦИЯ, Пк-РАЗЪЕДИНЕНИЕ, Пк-ПРЕРЫВАНИЕ и Пк-Пс-ПРЕРЫВАНИЕ. Использование нормального режима СЭНП предполагает использование нормального режима СЭУА и нормального режима услуг-уровня-представления. Использование режима Х.410-1984 СЭНП предполагает использование режима Х.410-1984 СЭУА и режима Х.410-1984 услуг-уровня-представления.

11.3.3 Использование услуг-уровня-представления

Услуги-уровня-представления определены в ГОСТ 34.971.

Уровень представления координирует представление (синтаксис) семантик прикладного уровня, которыми необходимо обмениваться.

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

В режиме Х.410-1984 для нижерасположенного соединения-уровня-представления используется единственный контекст-уровня-прсдставления по умолчанию. Контекст-уровня-представления включает один абстрактный-синтаксис для всех СЭП, входящих в прикладной-контекст (т.е. СЭПС, СЭНП и СЭУА).

Адресация на уровне представления не используется для протокола передачи сообщений (Р1) в режиме Х.410-1984.

СЭУА является единственным пользователем услуг-уровня-представления Пр-СОЕДИНЕНИЕ, Пр-РАЗЪЕДИНЕНИЕ, Пр-Пл-ПРЕРЫВАНИЕ, Пр-Пс-ПРЕРЫВАНИЕ.

СЭНП является единственным пользователем услуг-уровня-представления Пр-НАЧАЛО-АКТИВНОСТИ, Пр-ДАННЫЕ, Пр-МЛАДШАЯ-СИНХРОНИЗАЦИЯ, Пр-КОНЕЦ-АКТИВНОСТИ, Пр-ПРЕРЫВАНИЕ-АКТИВНОСТИ, Пр-АННУЛИРОВАНИЕ-АКТИВНОСТИ, Пр-Пл-ОТЧЕТ-ОБ-ОСОБОМ-СЛУЧАЕ, Пр-ВОЗОБНОВЛЕНИЕ-АКТИВНОСТИ, Пр-Пс-ОТЧЕТ-ОБ-ОСОБОМ-СЛУЧАЕ, Пр-ЗАПРОС-ПОЛНОМОЧИЙ, Пр-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ. Использование нормального режима СЭНП предполагает использование нормального режима СЭУА и использование нормального режима услуг-уровня-представления. Использование режима Х.410-1984 СЭНП предполагает использование режима Х.410-1984 СЭУА и режима Х.410-1984 услуг-уровня-представления.

11.4 Установление и разъединение ассоциаций

Ассоциации между двумя АПС создаются в соответствии с двусторонними соглашениями, охватывающими следующие вопросы:

а) максимальное число ассоциаций, которые могут существовать одновременно;

б) использование монологовой или двунаправленной поочередной ассоциации;

в) используемый прикладной-контекст;

г) АПС, ответственный за установление ассоциации;

д) постоянное установление ассоциации либо ее установление и разъединение по требованию.

12 ОПРЕДЕЛЕНИЕ АБСТРАКТНОГО СИНТАКСИСА ПРОТОКОЛА ПЕРЕДАЧИ СПС

Абстракгный-синтаксис протокола передачи СПС (Р1) определен на рисунке 6.

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

Определение абстраетного-синтаксиса протокола передачи СПС (Р1) состоит из следующих составных частей (см. рисунок 6):

- Пролог, объявления экспорта из модуля протокола передачи СПС (Р1) и импорта в этот модуль.

- Прикладные-контексты: определения прикладных-контекстов, используемых между АПС.

- Сервисный элемент передачи сообщений: определения сервисного элемента передачи сообщений (СЭПС).

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

MTSTransferProtocol {joint-iso-ccitt mhs-motis(6) protocols(0) modules(0) transfer-protocol(3) }
DEFINITIONS IMPLICIT TAGS :: =
BEGIN
- - Пролог
EXPORTS;
IMPORTS
	- - Сервисные элементы прикладного уровня и прикладные контексты
	APPLICATION-SERVICE-ELEMENT, APPLICATION-CONTEXT, aCSE
				FROM Remote-Operations-Notation-extension {joint-iso-ccitt remote- operations(4)notation-extension(2)}
	rTSE
				FROM Reliable-Transfer-APDUs {joint-iso-ccitt reliable-transfer(3) apdus(0)}
- - Параметры абстрактных услуг порта передачи АПС
MTABind, MTAUnbind, Message, Probe, Report,
				FROM MTAAbstractService {joint-iso-ccitt mhs-motis(6) mts(3) modules (0) mta-abstract-service(2)}
- - Объектные идентификаторы
id-ac-mts-tiansfer, id-as-acse, id-as-mta-rtse, id-as-mtse, id-ase-mtse
				FROM MHSProtocolObjectIdentifiers {joint-iso-ccitt mhs-motis(6) protocols(0) modules(0) object-identifiers(0)}
- - Прикладной контекст, содержащий СЭНП нормального режима
mts-transfer APPLICATION-CONTEXT
				APPLICATION SERVICE ELEMENTS {aCSE, rTSE; mTSE}
				BIND MTABind
				UNBIND MTAUnbind
				ABSTRACT SYNTAXES {
					id-as-acse, - - СЭУА
					id-as-mts-rtse, - - АПССвязка и АПСРазвязка, включая СЭНП
						id-as-mtse - - СЭПС - -}
				:: = id-ac-mts-transfer
- - Прикладной контекст, содержащий СЭНП режима Х.410-1984
mts-transfer-protocol INTEGER :: = 12
- - Прикладной контекст для взаимодействия с протоколом Р1 1984
mts-transfer-protocol-1984 INTEGER :: = 1
- - Сервисный элемент передачи сообщения
mTSE APPLICATION-SERVICE-ELEMENT
			:: = id-ase-mtse
- - Протокольные блоки данных прикладного уровня СПС
MTS-APDU :: = CHOICE {
		message [0] Message,
		probe [2] Probe,
		report [1] Report}
END - - протокола Передачи СПС

Рисунок 6 - Определение абстрактного синтаксиса протокола передачи СПС (Р1)

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

В этом разделе определяется преобразование протокола передачи СПС (Р1) в используемые услуги.

В подразделе 13.1 определяется преобразование протокола передачи СПС (Р1) в используемые услуги прикладных-контекстов, содержащих СЭНП режима Х.410-1984. В подразделе 13.2 определяется преобразование протокола передачи СПС (Р1) в используемые услуги прикладных-контекстов, содержащих СЭНП нормального режима.

13.1 Преобразование в СЭНП режима Х.410-1984

В этом разделе определяется преобразование протокола передачи СПС (Р1) в используемые услуги для прикладных-контекстов, включающих СЭНП в режиме Х.410-1984. Обеспечение этого преобразования не требуется для АПС типа А, но обязательно для АПС типа В и АПС типа С для соответствия настоящему стандарту.

В 13.1.1 определяется преобразование услуг связка-АПС и развязка-АПС в услуги СЭНП режима Х.410-1984 НП-ОТКРЫТИЕ и НП-ЗАКРЫТИЕ. В 13.1.2 определяется преобразование услуг передача-сообщения, передача-зонда и передача-отчета в услугу СЭНП НП-ПЕРЕДАЧА. В 13.1.3 описано управление полномочиями с использованием услуг СЭНП НП-ЗАПРОС-ПОЛНОМОЧИЙ и НП-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ. В 13.1.4 определяется использование услуги СЭНП НП-Пс-ПРЕРЫВАНИЕ. В 13.1.5 определяется использование услуги СЭНП НП-Пл-ПРЕРЫВАНИЕ, которая не используется в режиме Х.410-1984.

13.1.1 Преобразование в НП-ОТКРЫТИЕ и НП-ЗАКРЫТИЕ

В этом подразделе определяется преобразование услуг АПС-связка и АПС-развязка в услуги СЭНП режима Х.410-1984 НП-ОТКРЫТИЕ и НП-ЗАКРЫТИЕ.

13.1.1.1 Связка-АПС в НП-ОТКРЫТИЕ

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

13.1.1.1.1 Прикладной-протокол

Этот параметр должен обеспечиваться инициатором ассоциации примитива НП-ОТКРЫТИЕ запрос и должен иметь значение протокол-передачи-спс (целое значение "12") или протокол-передачи-спс-1984 (целое значение "1").

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

Значение этого типа, определенное в разделе АРГУМЕНТ услуги связка-АПС, преобразуется инициатором ассоциации в параметр данные-пользователя примитива НП-ОТКРЫТИЕ запрос.

Если ответчик ассоциации обеспечивает параметр "результат" примитива НП-ОТКРЫТИЕ ответ в значении "принято", то значение типа, определенное в разделе РЕЗУЛЬТАТ услуги связка-АПС, преобразуется в параметр данные-пользователя примитива НП-ОТКРЫТИЕ ответ.

В случае ошибки ответчик ассоциации обеспечивает параметр "результат" примитива НП-ОТКРЫТИЕ ответ в значении "отклонено (устойчивое состояние)" или "отклонено (неустойчивое состояние)". При значении "отклонено (устойчивое состояние)" параметр данные-пользователя примитива НП-ОТКРЫТИЕ ответ должен иметь значение либо ошибка-аутентификации, либо неприемлемый-режим-диалога.

13.1.1.1.3 Режим

Этот параметр должен обеспечиваться инициатором ассоциации в примитиве НП-ОТКРЫТИЕ запрос и должен иметь значение "режим Х.410-1984".

13.1.1.2 Развязка-АПС в НП-ЗАКРЫТИЕ

Развязка-АПС преобразуется в услугу НП-ЗАКРЫТИЕ СЭНП. В режиме Х.410-1984 услуга НП-ЗАКРЫТИЕ не имеет параметров.

13.1.2 Преобразование в ПН-ПЕРЕДАЧА

Услуги передача-сообщения, передача-зонда и передача-отчета преобразуются в услугу СЭНП НП-ПЕРЕДАЧА.

Элемент СЭПС может выдавать примитив НП-ПЕРЕДАЧА запрос только в том случае, если он владеет полномочиями (см. 13.1.3) и если нет невыданного примитива НП-ПЕРЕДАЧА подтверждение.

Использование параметров услуги НП-ПЕРЕДАЧА рассмотрено в следующих подразделах.

13.1.2.1 ПБДП

Значение ПБДП-СПС должно преобразовываться передающим в параметр ПБДП примитива НП-ПЕРЕДАЧА запрос.

Для услуги передача-сообщения ПБДП-СПС - это сообщение. Для услуги передача-зонда ПБДП-СПС - это зонд. Для услуги передача-отчет ПБДП-СПС - это отчет.

13.1.2.2 Время-передачи

Значение этого параметра определяется локальными правилами передающего. Оно может иметь отношение к приоритету ПБДП (см. 13.1.3.1.1).

13.1.3 Управление полномочиями

В этом разделе описывается управление полномочиями путем использования услуг СЭНП НП-ЗАПРОС-ПОЛНОМОЧИЙ и НП-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ.

СЭПС должен овладеть полномочиями прежде, чем он сможет использовать услугу НП-ПЕРЕДАЧА для передачи сообщения, зонда или отчета.

СЭПС, не владеющий полномочиями, может выдать примитив НП-ЗАПРОС-ПОЛНОМОЧИЙ запрос, параметр "приоритет" которого отражает наивысший приоритет ПБДП, ожидающего передачи.

СЭПС, владеющий полномочиями, может выдать примитив НП-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ, если он не имеет больше ПБДП для передачи. Он должен выдать примитив НП-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ запрос в ответ на примитив НП-ЗАПРОС-ПОЛНОМОЧИЙ, если он не имеет больше ПБДП для передачи, с приоритетом равным или более высоким приоритета, указанного в примитиве НП-ЗАПРОС-ПОЛНОМОЧИЙ индикация. Если у него еще остаются для передачи ПБДП более низкого приоритета, он может затем выдать примитив НП-ЗАПРОС-ПОЛНОМОЧИЙ запрос, у которого параметр "приоритет" отражает наивысший приоритет ПБДП, ожидающего передачи.

13.1.3.1 Использование услуги НП-ЗАПРОС-ПОЛНОМОЧИЙ

СЭПС выдает примитив НП-ЗАПРОС-ПОЛНОМОЧИЙ запрос для запроса полномочий. Он может выдавать его только в том случае, если он еще не владеет полномочиями.

Если инициатор ассоциации обеспечил параметру диалогово-режима значение "монолог", а параметру начальных полномочий значение "инициатор-ассоциации", то услуга НП-ЗАПРОС-ПОЛНОМОЧИЙ не должна использоваться.

Использование параметра услуги НП-ЗАПРОС-ПОЛНОМОЧИЙ рассмотрено в следующем подразделе.

13.1.3.1.1 Приоритет

Значение параметра "приоритет" обеспечивается СЭПС, запрашивающим полномочия, и оно отражает ПБДП самого высокого приоритета из всех ПБДП, ожидающих передачи.

Приоритет "ноль" является наивысшим приоритетом и зарезервирован для действий разъединения ассоциации ее инициатором.

Приоритет "единица" должен назначаться сообщениям, у которых поле "приоритет" (определенное в 8.2.1.1.1.8 ИСО/МЭК 10021-4) имеет значение "срочно". Приоритет "единица" должен назначаться также зондам и отчетам.

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

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

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

13.1.3.2 Использование услуги НП-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ

СЭПС выдает примитив НП-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ запрос для передачи полномочий своему партнеру. Он может сделать это только в том случае, если он владеет полномочиями.

Если инициатор ассоциации обеспечил параметру "режим-диалога" значение "монолог", а параметру "начальные-полномочия" значение "инициатор-ассоциации", то услуга НП-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ не должна использоваться.

Услуга НП-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ не имеет параметров.

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

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

Услуга НП-Пс-ПРЕРЫВАНИЕ информирует прикладной-процесс о том, что прикладная-ассоциация не может дальше поддерживаться (например, из-за невозможности восстановления).

Услуга НП-Пс-ПРЕРЫВАНИЕ не имеет параметров.

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

Услуга СЭНП НП-Пл-ПРЕРЫВАНИЕ отсутствует в режиме Х.410-1984.

13.2 Преобразование в СЭНП нормального режима

В этом подразделе определяется преобразование протокола передачи (Р1) в используемые услуги для прикладных-контекстов, содержащих СЭНП нормального режима. Обеспечение этого преобразования обязательно для соответствия настоящему стандарту.

В 13.2.1 определяется преобразование услуг связка-АПС и развязка-АПС в услуги СЭНП нормального режима НП-ОТКРЫТИЕ и НП-ЗАКРЫТИЕ. В 13.2.2 определяется преобразование услуг передача-сообщения, передача-зонда и передача-отчета в услугу СЭНП НП-ПЕРЕДАЧА. В 13.2.3 описывается управление полномочиями с использованием услуг СЭНП НП-ЗАПРОС-ПОЛНОМОЧИЙ и НП-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ. В 13.2.4 определяется использование услуги СЭНП НП-Пс-ПРЕРЫВАНИЕ. В 13.2.5 описано использование услуги СЭНП НП-Пс-ПРЕРЫВАНИЕ.

13.2.1 Преобразование в НП-ОТКРЫТИЕ и НП-ЗАКРЫТИЕ

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

13.2.1.1 Связка-АПС в НП-ОТКРЫТИЕ

Услуга связка-АПС преобразуется в услугу СЭНП НП-ОТКРЫТИЕ. Использование параметров услуги НП-ОТКРЫТИЕ рассматривается в следующих подразделах.

13.2.1.1.1 Режим

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

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

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

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

Преобразование операции-связки услуги связка-АПС в параметр данные-пользователя примитива НП-ОТКРЫТИЕ запрос определено в ГОСТ Р ИСО/МЭК 9072-1.

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

Инициатор ассоциации обеспечивает список определений контекста уровня представления в примитиве НП-ОТКРЫТИЕ запрос.

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

В разделе 12 определяются абстрактные-синтаксисы, входящие в прикладной-контекст.

13.2.1.2 Развязка-АПС в НП-ЗАКРЫТИЕ

Развязка-АПС преобразуется в услугу СЭНП НП-ЗАКРЫТИЕ.

В нормальном режиме никаких параметров услуги НП-ЗАКРЫТИЕ не используется.

13.2.2 Преобразование в НП-ПЕРЕДАЧА

Услуги передача-сообщения, передача-зонда и передача-отчета преобразуются в услугу СЭНП НП-ПЕРЕДАЧА.

Преобразование этих услуг в услугу НП-ПЕРЕДАЧА в нормальном режиме аналогично преобразованию в режиме Х.410-1984, определенному в 13.1.2.

13.2.3 Управление полномочиями

СЭПС должен овладеть полномочиями прежде, чем он сможет использовать услугу НП-ПЕРЕДАЧА для передачи сообщения, зонда или отчета.

Управление полномочиями в нормальном режиме аналогично управлению полномочиями в режиме Х.410-1984, определенному в 13.1.3.

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

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

Услуга НП-Пс-ПРЕРЫВАНИЕ обеспечивает информирование прикладного-процесса о том, что прикладная ассоциация не может больше поддерживаться (например, из-за невозможности восстановления).

Услуга НП-Пс-ПРЕРЫВАНИЕ не имеет параметров.

Заметим, что использование услуги НП-Пс-ПРЕРЫВАНИЕ в нормальном режиме аналогично использованию этой услуги в режиме Х.410-1984.

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

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

Услуга НП-Пл-ПРЕРЫВАНИЕ позволяет прикладному-процессу прервать прикладную-ассоциацию. Услуга НП-Пл-ПРЕРЫВАНИЕ может быть запрошена либо инициатором, либо ответчиком ассоциации.

В нормальном режиме никакие параметры услуги НП-Пл-ПРЕРЫВАНИЕ не используются.

Заметим, что услуга НП-Пл-ПРЕРЫВАНИЕ отсутствует в режиме Х.410-1984.

14 СООТВЕТСТВИЕ

РУ, претендующий на соответствие протоколу передачи СПС (Р1), определенному в настоящем стандарте, должен соответствовать требованиям подразделов 14.1, 14.2 и 14.3.

14.1 Требование к заявке

Должно констатироваться следующее:

а) прикладные-контексты, определенные в главе 3 настоящего стандарта, соответствие которым заявляется;

б) какой из режимов обеспечивается: монолог, двунаправленный-поочередный либо монолог и двунаправленный-поочередный диалоговый;

в) роль, которую может выполнять в ассоциации РУ: в качестве инициатора, ответчика либо того и другого.

В таблице 7 приведена классификация обеспечения прикладных-контекстов, требуемых для соответствия протоколу передачи СПС (Р1) для каждого типа АПС.


Таблица 7 - Требования к соответствию протоколу передачи СПС

Прикладной коктекст	Тип АПС
	А	В	С
Протокол передачи СПС
Передача-спс	О	О	О
Протокол-передачи-спс	Ф	О	О
Протокол-передачи-спс-1984	Ф	Ф	О
Обозначения: О - обязательно; Ф - факультативно.

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

АПС должен:

а) соответствовать определению абстрактного-синтаксиса протокола передачи СПС (Р1), определенного в разделе 12 настоящего стандарта.

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

АПС должен:

а) соответствовать процедурам распределенных операций СПС, определенных в ИСО/МЭК 10021-4;

б) соответствовать преобразованию в услуги, определенные в разделе 13 настоящего стандарта, требуемого прикладными контекстами, которые обеспечены типом АПС, для которого заявлено соответствие; обеспечение преобразования в услуги СЭНП в нормальном режиме обязательно для всех типов АПС, а в услуги СЭНП в режиме X.410-1984 обязательно для АПС типа В и АПС типа С;

в) соответствие правилам взаимодействия с РУ, соответствующим Рекомендации Х.411 (1984), определено в приложении В настоящего стандарта, если заявлено соответствие АПС типа С;

г) соответствие использованию нижерасположенных услуг определено в 11.3 настоящего стандарта.

ПРИЛОЖЕНИЕ А (обязательное). СПРАВОЧНОЕ ОПРЕДЕЛЕНИЕ ОБЪЕКТНЫХ ИДЕНТИФИКАТОРОВ ПРОТОКОЛА СОС

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

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

Все объектные идентификаторы, которые присвоены в настоящем стандарте, присваиваются в данном приложении. Однако данное приложение не является определительным для всех присвоений. Другие определительные присвоения содержатся в модулях основного текста настоящего стандарта, в данном приложении даны ссылки на них.


MHSProtocolObjectIdentifiers { joint-iso-ccitt mhs-motis(6) protocols(0) modules(0) object-identifiers(0)}

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

- - Пролог

- - Экспортирует все

IMPORTS - - ничего - -;

- - Протоколы СОС

id-mhs-protocols OBJECT IDENTIFIER ::= { joint-iso-ccitt mhs-motis(6) protocols(0)} - -
not definitive

- - Классифицирует объектные идентификаторы

id-mod OBJECT IDENTIFIER ::= {id-mhs-protocols 0}	- - модули
id-ac OBJECT IDENTIFIER ::= {id-mhs-protocols 1}	- - прикладные контексты
id-as OBJECT IDENTIFIER ::= {id-mhs-protocols 2}	- - абстрактные синтаксисы
id-ase OBJECT IDENTIFIER ::= {id-mhs-protocols 3}	- - сервисные элементы прикладного уровня

- - Модули

id-mod-object-identifiers OBJECT IDENTIFIER ::= {id-mod 0}	- - не определительный
id-mod-mts-access-protocol OBJECT IDENTIFIER ::= {id-mod 1}	- - не определительный
id-mod-ms-access-protocol OBJECT IDENTIFIER ::= {id-mod 2}	- - не определительный
id-mod-mts-transfer-protocol OBJECT IDENTIFIER ::= {id-mod 3}	- - не определительный

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

- - Протокол доступа СПС

id-ac-mts-access OBJECT IDENTIFIER ::= {id-ас 0}

id-ac-mts-forced-access OBJECT IDENTIFIER ::= {id-ас 1}

id-ac-mts-reliable-access OBJECT IDENTIFIER ::= {id-ac 2}

id-ac-mts-forced-reliable-access OBJECT IDENTIFIER ::= {id-ac 3}

Определение абстрактного синтаксиса объектных идентификаторов протоколов СОС

Рисунок А.1, лист 1

- - Протокол доступа ХС

id-ac-ms-access OBJECT IDENTIFIER ::= {id-ас 4}

id-ac-ms-reliable-access OBJECT IDENTIFIER ::= {id-ас 5}


- - Протокол, передачи СПС

id-ac-mts-transfer OBJECT IDENTIFIER ::= {id-ac-6}


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

id-as-acse OBJECT IDENTIFIER ::= { joint-iso-ccitt association-control (2) abstract-syntax (1) opdus (0) version 1 (1)}

id-as-msse OBJECT IDENTIFIER ::= {id-as 1}

id-as-mdse OBJECT IDENTIFIER ::= {id-as 2}

id-as-mrse OBJECT IDENTIFIER ::= {id-as 5}

id-as-mase OBJECT IDENTIFIER ::= {id-as 6}

id-as-mtse OBJECT IDENTIFIER ::= {id-as 7}

id-as-mts-rtse OBJECT IDENTIFIER ::= {id-as 8}

id-as-ms OBJECT IDENTIFIER ::= {id-as 9}

id-as-ms-rtse OBJECT IDENTIFIER ::= {id-as 10}

id-as-mts OBJECT IDENTIFIER ::= {id-as 11}


- - Сервисные элементы прикладного уровня

id-ase-msse OBJECT IDENTIFIER ::= {id-ase 0}

id-ase-mdse OBJECT IDENTIFIER ::= {id-ase 1}

id-ase-mrse OBJECT IDENTIFIER ::= {id-ase 2}

id-ase-mase OBJECT IDENTIFIER ::= {id-ase 3}

id-ase-mtse OBJECT IDENTIFIER ::= {id-ase 4}


END - - объектныхИдентификаторовПротоколаСОС

Рисунок А.1, лист 2

ПРИЛОЖЕНИЕ В (обязательное). ВЗАИМОДЕЙСТВИЕ С СИСТЕМАМИ 1984

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

В данном приложении определяются правила, которым должны подчиняться АПС, претендующие на соответствие АПС типа С настоящему стандарту (далее - "системы 1988"), при взаимодействии с реализациями, соответствующими Рекомендации Х.411 (1984) (далее - "системы 1984"), использующими протокол передачи СПС (Р1).

В подразделе B.1 определяются правила установления ассоциаций, которым должна подчиняться система 1988 при взаимодействии с системой 1984.

В подразделе В.2 определяются правила, которым должна подчиняться система 1988 при передаче ПБДП-СПС в систему 1984.

В подразделе В.3 определяются правила, которым должна подчиняться система 1988 при передаче ПБДП-СПС из системы 1984.

Примечание - Поскольку Рекомендация Х.411 (1984) определяет взаимодействия на границе РАУ, то правила взаимодействия, приводимые в данном приложении, применимы только на этой границе.


К универсальному классу типов АСН.1 добавлены дополнительные типы относительно определенных в Рекомендации Х.409 (1984). Следовательно спецификации действительной замены для типа ЛЮБОЙ расширены. Заметим, что системы 1984 могут оказаться неспособными обработать расширенные универсальные типы. Однако такие поля, предназначенные для систем 1984, должны быть ограничены универсальными типами, определенными в Рекомендации Х.409 (1984).

Правила базового кодирования АСН.1 обеспечивают более высокую гибкость, чем Рекомендация Х.409 (1984) для больших форматов октетов длины. Первые позволяют использовать более длинные октеты, чем минимально необходимо, тогда как указанная Рекомендация не обеспечивает этого. Следовательно при взаимодействии с системой 1984 необходимо соблюдать эти ограничения и использовать меньшее возможное число октетов при отсутствии ведущего октета в значении 0.

B.1 Установление ассоциации

В этом подразделе определяются ограничения, которые должна выполнять система 1988 относительно связки-АПС при установлении ассоциации с системой 1984. Относительно развязки-АПС ограничений нет.

Протокол-передачи-спс-1984, определенный в разделе 12 настоящего стандарта, должен использоваться для совместимости с системой 1984.

B.1.1 Удостоверения личности инициатора/ответчика

На эти элементы не налагается ограничений, поскольку в Рекомендации Х.411 (1984) определено, что каждый из соответствующих элементов должен иметь тип ЛЮБОЙ. Заметим, однако, что система 1984 будет ограниченно использовать эти элементы при взаимодействии с системами 1988, как изложено выше.

В.1.2 Контекст-защиты

Этот факультативный элемент не должен генерироваться системой 1988 при взаимодействии с системой 1984. Заметим, что система 1984 не может вырабатывать этот элемент.

В.1.3 Ошибка-связки

Значение неприемлемый-контекст-защиты ошибки связки не должно генерироваться системой 1988.

В.2 Правила передачи в системы 1984

В этом подразделе определяются правила взаимодействия, которые должна выполнять система 1988 при передаче ПБДП-СПС системе 1984. Передача ПБДП-СПС системой, соответствующей ГОСТ Р ИСО/МЭК 10021-4, в систему, соответствующую Рекомендации Х.411 (1984), называется снижением. Эти правила выражаются в понятиях действий, которые должна выполнять система 1988 над каждым протокольным элементом протокола передачи СПС (Р1).

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

Если одно или несколько правил могут привести к безуспешности снижения, то АПС будет выполнять те же действия, что и в случае безуспешности передачи (см. раздел 14 ИСО/МЭК 10021-4).

Примечание - Возможная или фактическая потеря информации, обусловленная применением этих правил, может повлиять на стратегию маршрутизации АПС.


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

В.2.1 Расширения

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

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

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

В.2.2 Порегиональная двусторонняя информация

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

В противном случае порегиональная-двусторонняя-информация должна оставаться неизменной.

В.2.3 Трассовая-информация/субъектная - промежуточная-трассовая-информация

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

В противном случае трассовая-информация или субъектная-промежуточная-трассовая-информация должна остаться неизменной.

В.2.4 Имя-отправителя/имя-адресата-отчета

Если имя-отправителя на конверте-передачи-сообщения или на конверте-передачи-зонда либо имя-адресата-отчета на конверте-передачи-отчета не могут быть снижены в соответствии с правилами для имени-ОП (см. В.2.7), снижение будет безуспешным.

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

В.2.5 Поля на-получателя передачи-сообщения или -зонда

Если имя-получателя в полях-на-получателя конверта-передачи-сообщения или конверта-передачи-зонда не могут быть снижены в соответствии с правилами, заданными для имени-ОП (см. В.2.7), либо при наличии какого-либо поля-расширения-на-получателя, помеченного как критичное-при-передаче или критичное-при-доставке, то:

а) если соответствующий элемент ответственность имеет значение ответственный, снижение будет безуспешным;

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

Примечание - Правила снижения предполагают, что элемент раскрытие-получателей не является критичным-при-передаче и критичным-при доставке.

8.2.6 Поля-на-получателя передачи-отчета

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

8.2.7 Имя-ОП

Имя-ОП должно снижаться путем удаления справочного-имени (при его наличии) и снижения адреса-ОП (см. В.2.8).

В.2.8 Адрес-ОП

Если адрес-ОП содержит какие-либо атрибуты, закодированные как телетексные строки и как распечатываемые строки, то телетексные строки следует удалить.

Если адрес-ОП является цифровым-адресом-ОП или терминальным-адресом-ОП, содержащим имя-частного-региона, то такой адрес-ОП не может быть снижен.

Если адрес-ОП является терминальным-адресом-ОП, который содержит:

а) имя-страны, имя-административного-региона, адрес-сети и, факультативно, региональные-атрибугы и ничего другого, то этот адрес-ОП должен остаться неизменным;

б) адрес-сети, факультативно, терминальный-идентификатор и ничего другого, то этот адрес-ОП должен остаться неизменным;

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

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

Если после применения указанных выше правил адрес-ОП все еще содержит какие-либо атрибуты-расширения, то такой адрес-ОП не может быть снижен.

В.2.9 Типы-кодированной-информации

Базовые типы-кодированной-информации, указанные объектными идентификаторами, должны быть преобразованы в соответствующий бит в базовых-типах-кодированной-информации, а объектные идентификаторы должны быть удалены.

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

Любые не-базовые-параметры, кроме параметров типов факс-4-класс-1 и смешанный-режим, не должны изменяться. Параметры для типов факс-4-класс-1 и смешанный-режим могут преобразовываться в соответствии с правилами, приведенными в Рекомендациях Т.73 (1984), Т.400, Т.501 и Т.503; если оно невозможно, снижение будет безуспешным.

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

В.2.10 Тип-содержимого и содержимое

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

Если тип-содержимого в сообщении указан объектным идентификатором, он должен быть преобразован в целое число внешнее вместо объектного идентификатора. Объектный идентификатор и содержимое должны быть объединены в значение типа ВНЕШНИЙ, и это значение должно быть содержимым нового содержимого. Объектный идентификатор должен быть прямым-указателем типа ВНЕШНИЙ, а содержимое СТРОКИ ОКТЕТОВ содержимого должно быть его выровненным-по-октетам кодом. Кодирование СТРОКИ ОКТЕТОВ содержимого должно соответствовать базовым правилам кодирования АСН.1.

Если тип-содержимого зонда указан объектным идентификатором, снижение будет безуспешным.

Тип-содержимого отчета должен удаляться. Возвращенное-содержимое должно оставаться неизменным.

В.3 Правила приема из систем 1984

В этом подразделе определяются правила взаимодействия, которые должна соблюдать система 1988 при приеме ПБДП-СПС из системы 1984.

Для многих элементов протокола передачи СПС (Р1) определены ограничения на размеры. При условии соблюдения этих ограничений системой 1984 правильно закодированные ПБДП-СПС, полученные из системы 1984, также будут соответствовать протоколу передачи СПС (Р1) 1988. Следовательно система 1988 не требует никаких особых действий.

В.4 Нерегулярности службы

Использование переадресации и списка распределения в существующих региональных границах 1988/1984 может привести к некоторым нерегулярностям, которые перечислены ниже:

- получатели могут оказаться не в состоянии уведомить о получении ими сообщения по причине расширения СР или переадресации;

- при пересечении сообщением региона 1984 предыстория расширения и предыстория переадресации теряются. Это может привести к преждевременному обнаружению шага маршрутизации и к безуспешному результату переадресации или расширения. Заметим, что с этой проблемой может столкнуться только СР с совместимым адресом О/П 1984;

- АПС 1984 могут выдавать уведомления отправителю сообщения вместо их переадресации обратно по маршруту расширения СР;

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

ПРИЛОЖЕНИЕ С (справочное). РАЗЛИЧИЯ МЕЖДУ ПРОТОКОЛАМИ СОС 1984 И 1988

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

В данном приложении определены различия между протоколом доступа СПС (Р3) и протоколом передачи СПС (Р1), определенными в настоящем стандарте, и протоколами Р3 и Р1, определенными в Рекомендации Х.411 (1984). Различия в изложении протоколов здесь не рассматриваются.

Различия определены в понятиях добавлений или других изменений протокольных элементов, имеющихся в Р3 и Р1 и определенных в Рекомендации Х.411 (1984). Эти различия более точно указаны в определениях абстрактного синтаксиса в ИСО/МЭК 10021-4.

В подразделе C.1 определены различия в протоколе доступа СПС (Р3). В подразделе С.2 определены дополнительные различия в протоколе передачи СПС (Р1).

C.1 Различия в протоколе доступа СПС (Р3)

В этом подразделе определены различия между протоколом доступа СПС (Р3), определенным в настоящем стандарте, и протоколом Р3, определенным в Рекомендации Х.411 (1984).

С.1.1 Ограничения на размеры

Ограничения на предельные значения длины типов строк, число элементов в типах НАБОР или ПОСЛЕДОВАТЕЛЬНОСТЬ и диапазон значений типа ЦЕЛОЕ наложены на все параметры, определенные в Рекомендации Х.411 (1984), за исключением содержимого сообщения.

Примечание - Действительные значения ограничений не являются обязательной частью ИСО/МЭК 10021-4.

С.1.2 Изменения фундаментальных типов

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

С.1.2.1 Имя-ОП

В имя-ОП добавлены два новых факультативных параметра.

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

Вторым является справочное-имя, определенное в ИСО/МЭК 9594-2.

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

С.1.2.2 Тип-содержимого

Добавлена факультативная возможность идентификации типа-содержимого объектным идентификатором вместо целого числа. Это более предпочтительный метод идентификации нового типа-содержимого, и присвоение нового целочисленного значения нежелательно. Для выбора целого числа определены три новых значения: неопределенное, внешнее и межперсональные-сообщения-1988.

С.1.2.3 Типы-кодированной-информации

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

Определение не-базовых-параметров для типов факс-4-класс-1 и смешанный режим изменено в том, что ранее приведенное в Рекомендации Т.73 (1984) определение заменено на определение, приведенное в Рекомендациях Т.400, Т.501 и Т.503, и в том, что в нем теперь используется явное тегирование вместо неявного.

С.1.2.4 Содержимое

Для содержимого сообщения сохранен тип СТРОКА ОКТЕТОВ. Если тип-содержимого идентифицируется целочисленным значением внешнее, то такое содержимое называется внешним-содержимым. Значением СТРОКИ ОКТЕТОВ для внешнего-содержимого должен быть код ВНЕШНЕЕ АСН.1.

С.1.3 Расширения

Большая часть расширений абстрактных услуг СПС, определенных в ИСО/МЭК 10021-4, в протоколе сопровождается добавлением отдельного нового параметра расширения на конвертах и в результатах операций. Если никаких расширений не требуется, этот параметр отсутствует. Он может иметь место:

- в конверте-предоставления-сообщения по принципу на-сообщение и на-получателя;

- в результате-предоставления-сообщения;

- в конверте-предоставления-зонда по принципу на-зонд и на-получателя;

- в результате-доставки-зонда;

- в результате-доставки-сообщения и

- в конверте-доставки-отчета по принципу на-отчет и на-получателя.

С.1.4 Связка

В Рекомендации Х.411 (1984) обмен удостоверениями личности типа ЛЮБОЙ выполняется с использованием аргумента и результата операции связки. Тип ЛЮБОЙ ограничен в настоящем стандарте с целью выбора простых-удостоверений-личности (строка МК5 или СТРОКА ОКТЕТОВ) или строгих-удостоверений-личности, основанных на криптографических методах.

В аргумент добавлен факультативный параметр с целью спецификации контекста-защиты. Добавлены новые виды ошибок для указания неприемлемого-контекста-защиты.

C.1.5 Предоставление-сообщения

Параметры исходные-типы-кодированной-информации и явное-преобразование в конверте-предоставление-сообщения переведены в статус факультативных.

Добавлены две новых ошибки: несовместимый-запрос и ошибка-защиты.

С.1.6 Предоставление-зонда

Аналогично предоставлению-сообщения, см. С.1.5.

С.1.7 Аннулирование-задержанной-доставки

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

С.1.8 Управление-предоставлением

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

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

Добавлена ошибка: ошибка-защиты.

С.1.9 Доставка-сообщения

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

Эта операция сделана подтверждаемой путем добавления раздела РЕЗУЛЬТАТ, который содержит два факультативных параметра защиты: сертификат-получателя и подтверждение-доставки.

Добавлена одна новая ошибка: ошибка-защиты.

С.1.10 Доставка-отчета

В конверте-доставка-отчета добавлено 2 новых факультативных параметра: тип-содержимого и исходные-типы-кодированной-информации исходного сообщения.

Определено 5 новых кодов-причины-недоставки и 35 новых кодов-диагностики-недоставки.

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

Операция сделана подтверждаемой путем добавления раздела РЕЗУЛЬТАТ (где не передаются никакие параметры).

Добавлена новая ошибка: ошибка-защиты.

С.1.11 Управление-защитой

К аргументу добавлено 2 новых факультативных параметра управления: допустимые-типы-защиты и допустимый-контекст-защиты.

К результату добавлен факультативный параметр ожидающие-типы-содержимого.

Добавлены 2 новые ошибки: регистрация-нарушения-управления и ошибка-защиты.

C.1.12 Регистрация

К аргументу добавлены 2 новых параметра: типы-доставляемого-содержимого и метки-и-переадресация.

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

C.1.13 Изменение-удостоверений личности

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

С.2 Различия в протоколах передачи СПС (Р1)

В этом подразделе определены различия между протоколом передачи СПС (Р1), определенным в настоящем стандарте, и протоколом Р1, определенным в Рекомендации Х.411 (1984).

Перечисленные ниже изменения протокола передачи СПС (Р1) те же, что и определенные для протокола доступа СПС (Р3): ограничения размера (см. C.1.1), изменения фундаментальных типов (см. С.1.2) и связки (см. С.1.4).

В следующих подразделах подробно рассмотрены другие изменения протокола передачи СПС (Р1).

С.2.1 Поля расширения

Новый параметр расширения используется для включения большинства расширений абстрактных-услуг в протокол передачи СПС (Р1) (см. С.1.3). Этот параметр отсутствует, если расширения не требуются. Он может иметь место:

- в конверте-передачи-сообщения по принципу на-сообщение или на-получателя;

- в конверте-передачи-зонда по принципу на-зонд или на-получателя;

- в конверте-передачи-отчета;

- в содержимом-лередачи-отчета по принципу на-отчет или на-получателя.

С.2.2 Другие отличия

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

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

К элементам трассовая-информация добавлен факультативный параметр другие-действия. Этот новый параметр содержит 2 указателя: переадресовано для информирования о том, что сообщение было переадресовано РУ; расширено для информирования о том, что РУ расширил список распределения.

ПРИЛОЖЕНИЕ D (справочное). РАЗЛИЧИЯ МЕЖДУ ТЕКСТОМ РЕКОМЕНДАЦИИ Х.419 МККТТ И НАСТОЯЩИМ СТАНДАРТОМ

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

В данном приложении определяются технические различия между текстом Рекомендации Х.419 МККТТ и настоящим стандартом.

К этим различиям относятся следующие:

1) В Рекомендации Х.419 МККТТ содержатся обязательные требования к соответствию для обеспечения взаимодействия с реализациями Рекомендации Х.411 (1984) МККТТ, использующими протокол передачи СПС (Р1). В настоящем стандарте возможность взаимодействия с системами 1984 не требуется для АПС типа А и АПС типа В, но обязательна для АПС типа С.

2) В Рекомендации Х.419 МККТТ обеспечение преобразования протокола передачи СПС (Р1) в СЭНП режима Х.410-1984 является обязательным требованием соответствия, а обеспечение преобразования в СЭНП нормального режима - факультативным. В настоящем стандарте обеспечение преобразования в СЭНП нормального режима является обязательным, а обеспечение преобразования в СЭНП режима Х.410-1984 не требуется для АПС типа А, но обязательно для АПС типа В и АПС типа С.

Примечание - Взаимодействие между реализациями обобщено в таблице 6 настоящего стандарта

3) В Рекомендации Х.419 МККТТ содержатся требования по обеспечению услуг нижерасположенных уровней. В настоящем стандарте эти требования отсутствуют.