ГОСТ Р ИСО/МЭК МФС 10611-4-95 Информационная технология. Функциональный стандарт. Профили АМН1n. Системы обработки сообщений. Унифицированный обмен сообщениями. Часть 4. Профиль АМН12. Доступ к системе передачи сообщений (с использованием протокола Р3)

ГОСТ Р ИСО/МЭК МФС 10611-4-95

Группа П85

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


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

Функциональный стандарт

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

Часть 4. Профиль АМН12. Доступ к системе передачи сообщений
(с использованием протокола Р3)

Information technology. International standardized profiles AMH1n.
Message handling systems. Common messaging. Part 4. АМН12. MTS access (Р3)

ОКС 35.100
ОКСТУ 4002

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

Предисловие

1 РАЗРАБОТАН Комитетом при Президенте Российской Федерации по политике информатизации и ВНЕСЕН НА УТВЕРЖДЕНИЕ техническим комитетом по стандартизации ТК 22 "Информационная технология"

2 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 24.10.95 N 549

Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК МФС 10611-4-94 "Информационная технология. Международный функциональный стандарт. Профили АМН1n. Системы обработки сообщений. Унифицированный обмен сообщениями. Часть 4. Профиль АМН12. Доступ к системе передачи сообщений (с использованием протокола Р3)"

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

Введение

Введение

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

Одна из наиболее важных ролей функционального стандарта (ФС) состоит в том, чтобы стать основой разработки (организациями кроме ИСО и МЭК) международно признанных тестов и центров тестирования. ФС разрабатываются не просто для "узаконивания" конкретного набора базовых стандартов и факультативных возможностей, но и для того, чтобы способствовать взаимодействию открытых систем. Разработка и широкая приемлемость тестов, основанных на настоящем и других ФС, критически важна для успешного достижения этой цели.

Стандарт ГОСТ Р ИСО/МЭК МФ{FЗ}С 10611 состоит из нескольких частей. Настоящий стандарт является четвертой частью. В ней определен профиль АМН11(Р1). В первой части определено обеспечение услуг системы обработки сообщений (СОС), во второй - спецификация протоколов сервисных элементов управления ассоциацией (СЭУА), надежной передачи (СЭНП), удаленных операций (СЭУО), уровня представления и сеансового уровня для использования в СОС, в третьей - профиль АМН11(Р1) и в пятой - профиль АМН13(Р7).

1 НАЗНАЧЕНИЕ

1.1 Общие положения

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

1.2 Место в таксономии

Настоящий стандарт является четвертой частью многочастевого ФС, идентифицированного в ГОСТ Р ИСО/МЭК ТО 10000-2 как "АМН1. Системы обработки сообщений. Унифицированный обмен сообщениями" (см. также раздел 8.2 ГОСТ Р ИСО/МЭК ТО 10000-1, в котором определены многочастевые ФС).

Настоящий стандарт определяет профиль AMH12 - доступ к СПС (Р3).

Профиль АМН12 может взаимодействовать с любыми профилями Т (см. ГОСТ Р ИСО/МЭК ТО 10000), определяющими услуги транспортного уровня ВОС в режиме установления соединения.

1.3 Сценарий

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

Рисунок 1 - Сценарий АМН12

_______________

* Не входит в предмет рассмотрения настоящего стандарта

Рисунок 1 - Сценарий АМН12

Если профиль АМН12 реализован с использованием Р3, то он охватывает все аспекты абстрактных услуг СПС, как определено в разделе 8 ИСО/МЭК 10021-4.

Протоколы и услуги верхних уровней ВОС, предназначенные для обеспечения функций СОС, охватываемых профилем АМН12, определены в стандартах, перечисленных в таблице 1.

Таблица 1 - Модель профиля АМН12

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

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

Примечание - Ссылки в тексте настоящего стандарта на определенные разделы стандартов ИСО/МЭК должны рассматриваться как ссылки на соответствующие разделы эквивалентных рекомендаций МККТТ (указанных ниже), если не оговорено иное.


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

ГОСТ Р ИСО/МЭК 10000-1-93* Информационная технология. Основы и таксономия функциональных стандартов. Часть 1. Основы
_____________
* Вероятно ошибка оригинала. Следует читать ГОСТ Р ИСО/МЭК ТО 10000-1-93 Информационная технология. Основы и таксономия функциональных стандартов. Часть 1. Основы. - Примечание "КОДЕКС".

ГОСТ Р ИСО/МЭК ТО 10000-2-93 Информационная технология. Основы и таксономия функциональных стандартов. Часть 2. Таксономия профилей

ГОСТ Р ИСО/МЭК МФС 10611-1-95 Информационная технология. Функциональный стандарт. Профили АМН1n. Системы обработки сообщений. Унифицированный обмен сообщениями. Часть 1. Обеспечение услуг систем обработки сообщений

ГОСТ Р ИСО/МЭК МФС 10611-2-95 Информационная технология. Функциональный стандарт. Профили АМН1n. Системы обработки сообщений. Унифицированный обмен сообщениями. Часть 2. Спецификация СЭУО, СЭНП, СЭУА, протоколов уровня представления и сеансового уровня для использования в системах обработки сообщений

ИСО/МЭК 10021-1:1990* Информационная технология. Передача текста. Системы обмена текстами, ориентированные на сообщения. Часть 1. Общее описание услуг [см. также рекомендации МККТТ Х.400(1988)]

_______________

* До прямого применения данного документа в качестве государственного стандарта распространение его осуществляет секретариат ТК 22 "Информационная технология".

ИСО/МЭК 10021-2:1990* Информационная технология. Передача текста. Системы обмена текстами, ориентированные на сообщения. Часть 2. Общая архитектура [см. также рекомендацию МККТТ Х.402(1988)]

_______________

* До прямого применения данного документа в качестве государственного стандарта распространение его осуществляет секретариат ТК 22 "Информационная технология".

ИСО/МЭК 10021-4:1990* Информационная технология. Передача текста. Системы передачи текста, ориентированные на сообщения. Часть 4. Системы передачи сообщений. Определение абстрактных услуг и процедуры [см. также рекомендации МККТТ X.411(1988)]

_______________

* До прямого применения данного документа в качестве государственного стандарта распространение его осуществляет секретариат ТК 22 "Информационная технология".

ИСО/МЭК 10021-6:1990* Информационная технология. Передача текста. Системы передачи текста, ориентированные на сообщения. Часть 6. Спецификация протокола [см. также рекомендацию МККТТ Х.419(1988)]

_______________

* До прямого применения данного документа в качестве государственного стандарта распространение его осуществляет секретариат ТК 22 "Информационная технология".

Рекомендация МККТТ X.400(1988). Система обработки сообщений и общее описание услуг

Рекомендация МККТТ X.402(1988). Система обработки сообщений. Общая архитектура

Рекомендация МККТТ X.411(1988). Система обработки сообщений. Система передачи сообщений. Определение абстрактных услуг и процедуры

Рекомендация МККТТ Х.419(1988). Система обработки сообщений. Спецификация протоколов

Руководство для разработчика СОС, версия 8, март 1992 г. (Специальная согласительная группа МККТТ по системам обработки сообщений и СРГ по обмену сообщениями ИСО/МЭК СТК1/ПК18/РГ4).

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

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

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

3.1 Общие понятия

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

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

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

3.2 Классификация видов обеспечения

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

3.2.1 Статические возможности

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

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

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

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

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


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

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

Не входит в предмет рассмотрения (Н/Р) - элемент не входит в предмет рассмотрения настоящего стандарта - т.е. не может быть объектом аттестационного тестирования ФС.

Не используется (-) - элемент не используется в конкретном контексте, в котором применима эта классификация.

3.2.2 Динамическое поведение

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

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


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

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

Примечание - Признано, что в некоторых реализациях в подобных случаях может потребоваться исключить даже статические возможности, однако подобные ситуации не входят в предмет рассмотрения настоящего стандарта. Таким образом, любые элементы, определенные в настоящем стандарте как исключенные (И), с точки зрения статических возможностей определяются также как не входящие в предмет рассмотрения (Н/Р).

4 СОКРАЩЕНИЯ

5 СООТВЕТСТВИЕ

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

5.1 Заявка соответствия

Для каждой реализации, претендующей на соответствие профилю АМН12, определяемому в настоящем стандарте, должна быть представлена заявка о соответствии реализации протоколу (ЗСРП), в которой констатируется наличие или отсутствие обеспечения каждой факультативной возможности, идентифицированной в настоящей части ГОСТ Р ИСО/МЭК МФС 10611.

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

5.2 Соответствие СОС

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

Реализации, соответствующие профилю АМН12 согласно настоящему стандарту, должны реализовывать все обязательные обеспечиваемые возможности (О или О-), идентифицированные в качестве базовых требований в приложении А, и должно быть указано, какие факультативные возможности (Ф) реализованы. Они должны также обеспечивать соответствующие элементы услуг СОС и процедуры, как это определено в ГОСТ Р ИСО/МЭК МФС 10611-1, согласно назначению этого профиля и той ролью (т.е. АПС или пользователь СПС), для которой заявлено соответствие.

Реализации, соответствующие профилю АМН12 согласно настоящему стандарту, должны констатировать наличие или отсутствие обеспечения факультативных функциональных групп согласно ГОСТ Р ИСО/МЭК МФС 10611-1, которые используются в рамках этого профиля и в той роли (т.е. АПС или пользователь СПС), для которой заявлено соответствие. Для каждой функциональной группы, для которой заявляется обеспечение, реализация должна выполнять все обязательно обеспечиваемые возможности (О или О-), идентифицированные для этой функциональной группы в приложении А, и должно быть указано, какие факультативные возможности (Ф) реализованы. Она должна также обеспечивать соответствующие элементы услуг СОС и процедуры, определенные в ГОСТ Р ИСО/МЭК МФС 10611-1, согласно назначению этого профиля и той роли (т.е. АПС или пользователь СПС), для которой заявлено соответствие.

Реализации, соответствующие профилю АМН12 согласно настоящему стандарту, должны указывать тот (те) прикладной(ые) контекст(ы) протокола Р3, для которого(ых) заявлено соответствие.

5.3 Соответствие нижерасположенным уровням

Реализации, соответствующие профилю АМН12 согласно настоящему стандарту, должны также удовлетворять требованиям ГОСТ Р ИСО/МЭК МФС 10611-2 согласно прикладному(ым) контексту(ам) протокола Р3, для которого(ых) заявлено соответствие.

ПРИЛОЖЕНИЕ А (обязательное). ФОРМА ЗАЯВКИ О СООТВЕТСТВИИ РЕАЛИЗАЦИИ ФУНКЦИОНАЛЬНОМУ СТАНДАРТУ (ЗСРФС) ДЛЯ ПРОФИЛЯ АМН12

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

_______________

* Пользователям настоящего стандарта не требуется разрешение Госстандарта России на полное или частичное воспроизведение, тиражирование и распространение формы ЗСРФС.


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

В разделе A.1 определены базовые требования к соответствию профилю АМН12, а в разделе А.2 - требования, дополняющие те, которые определены в A.1, для каждой из факультативных функциональных групп, если заявлено соответствие такой функциональной группе. В разделе А.3 приводится дополнительная информация по обеспечению некоторых аспектов реализации при наличии специфических требований, не включенных в ГОСТ Р ИСО/МЭК МФС 10611. Все три раздела должны быть соответствующим образом заполнены.

В каждой таблице колонка "Базовый стандарт" отражает уровень обеспечения, требуемый для соответствия базовому стандарту, а колонка "Профиль" отражает уровень обеспечения, удовлетворяющий требованиям настоящего ФС (используя классификацию и нотацию, определенные в 3.2).

Колонка "Обеспечение" предназначена для заполнения поставщиком реализации как изложено ниже:

Д - элемент или функциональная возможность обеспечивается полностью (т.е. удовлетворяются требования "О" классификации и уровня обеспечения профиля);

Д - элемент или функциональная возможность обеспечивается минимально (т.е. удовлетворяются требования "О-" классификации уровня обеспечения профиля);

Н - элемент или функциональная возможность не обеспечивается;

ниже приводится следующая квалификация поведения при получении такого элемента:

НА - элемент аннулируется/игнорируется;

НО - БФД отклоняется (с соответствующей индикацией ошибки в необходимых случаях);

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

А.0 Идентификация реализации

A.0.1 Идентификация ЗСРП

А.0.2 Идентификация тестируемой реализации (ТР)

А.0.3 Идентификация поставщика

А.0.4 Идентификация протокола

А.0.5 Тип реализации

Примечание - Для каждого типа реализации, соответствие которого заявляется, должна заполняться отдельная ЗСРП.

А.0.6 Констатация глобального соответствия

А.0.7 Заявка о соответствии профилю

A.1 Базовые требования

A.1.1 Обеспеченные прикладные контексты

А.1.2 Обеспеченные операции

А.1.2.1 Связка и развязка

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

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

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

A.1.2.4 Сервисный элемент административного управления сообщениями (СЭАС)

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

А.1.3 Аргументы/результаты операции

А.1.3.1 Связка-СПС

У1 - если АПС представляет собой инициатора, то "О" иначе "-".

У2 - если пользователь СПС представляет собой инициатора, то "О" иначе "-".

A.1.3.2 ПредоставлениеСообщений

У1 - если обеспечивается в конверте предоставление сообщения, то "О" иначе "-".

А.1.3.3 ПредоставлениеЗонда

У1 - если обеспечивается в конверте предоставление зонда, то "О" иначе "-".

А.1.3.4 АннулированиеЗадержаннойДоставки

А.1.3.5 УправлениеПредоставлением

А.1.3.6 ДоставкаСообщения

А.1.3.7 ДоставкаОтчета

У1 - если обеспечивается в конверте предоставление сообщения, то "О" иначе "-".

А.1.3.8 УправлениеДоставкой

А.1.3.9 Журнал

A.1.3.10 ИзменениеУдостоверенияЛичности

А.1.4 КонвертПредоставленияСообщения

О1 - требуется только способность генерировать значение "запрещенный".

А.1.5 КонвертПредоставленияЗонда

О1 - требуется только способность генерировать значение "запрещенный".

А.1.6 КонвертДоставкаСообщения

А.1.7 КонвертДоставкиОтчета

У1 - если обеспечивается в конверте представления сообщения, то "О" иначе "Н/Р".

А.1.8 Общие типы данных

А.1.9 Расширенные типы данных

A.1.10 Имена О/П

У1 - если обеспечивается ЭУ "обозначение получателя справочным именем", то "О" иначе, если присутствует также адрес О/П, то "О-" иначе "Ф".*
________________
* Текст соответствует оригиналу. - Примечание "КОДЕКС".

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

Примечание - Классификация атрибута для АПС в виде "О" означает только то, что его присутствие требуется для формы адреса О/П

А.1.10.1 Мнемонический адрес О/П

А.1.10.2 Цифровой адрес О/П

А.1.10.3 Терминальный адрес О/П