allgosts.ru35.240 Применение информационных технологий35 ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ

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

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

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


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

Группа П85


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


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


ПЕРЕДАЧА ТЕКСТА

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


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


Information technology. Text communication.
Message-oriented text interchange systems (MOTIS).
Part 7. Interpersonal messaging system



ОКС 35.240.20
ОКСТУ 4002

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



Предисловие

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

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

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

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

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

Введение

Введение


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

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

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

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

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

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

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

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

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

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

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

Глава первая. ВВЕДЕНИЕ

1 НАЗНАЧЕНИЕ


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

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

Архитектурные и общие основы обработки сообщений определены и в некоторых других стандартах. ИСО/МЭК 10021-2 также определяет эти документы.

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

Аттестационные требования приведены в разделе 22.

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


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

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

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

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

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-6-97 Информационная технология. Передача текста. Системы обмена текстами, ориентированные на сообщения (MOTIS). Часть 6. Спецификации протокола

2.3 Системы справочника

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

2.4 Коды языков

ИСО 639-88* Коды для представления наименований языков
______________
* До прямого применения данного нормативного документа в качестве государственного стандарта распространение его осуществляет секретариат ТК 22.

2.5 Наборы символов

ИСО 2375-85* Обработка данных. Процедура регистрации управляющих последовательностей символов
______________
* До прямого применения данного нормативного документа в качестве государственного стандарта распространение его осуществляет секретариат ТК 22.

ИСО 8859-1-87* Обработка информации. 8-битные однобайтовые наборы графических кодированных символов. Часть 1. Латинский алфавит номер 1
______________
* До прямого применения данного нормативного документа в качестве государственного стандарта распространение его осуществляет секретариат ТК 22.

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


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

4 СОКРАЩЕНИЯ


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

5 СОГЛАШЕНИЯ


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

5.1 АСН.1

В настоящем стандарте используются для указанных целей следующие описательные соглашения, основанные на АСН.1:

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

б) для определения функциональных объектов межперсональных сообщений - макрокоманды OBJECT и REFINE ИСО/МЭК 10021-3;

в) для определения абстрактных услуг межперсональных сообщений - макрокоманды PORT, ABSTRACT-OPERATION и ABSTRACT-ERROR ИСО/МЭК 10021-3;

г) для определения расширений заголовков - макрокоманда HEADING-EXTENSION пункта 7.2.17;

д) для определения расширенных типов основной части - макрокоманда EXTENDED-BODY-PART-TYPE пункта 7.3.12;

е) для определения атрибутов ХС - макрокоманда ATTRIBUTE ИСО/МЭК 9594-2.

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


Таблица 1 - Использование нотации АСН.1

Рассматриваемый вопрос

Описание

Справочный материал

Объектные идентификаторы

-

Приложение D

Абстрактные информационные объекты

Глава 2

Приложение Е

Функциональные объекты

Разделы 10, 11, 16

Приложение F

Абстрактные услуги

Разделы 12, 13

Приложение G

Расширения заголовков

Приложение А

Приложение Н

Расширенные типы части тела

Приложение В

Приложение I

Атрибуты хранилища сообщений

Приложение С

Приложение J

Верхние границы

-

Приложение К



При обнаружении различий в описании АСН.1 и в справочном материале указывается ошибка спецификации.

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

Примечания

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

2 Использование макрокоманд ABSTRACT-OPERATION и ABSTRACT-ERROR, образованных из соответствующих поименованных макрокоманд удаленных операций, не означает, что привлечение абстрактных операций и ошибок и выдача соответствующих отчетов осуществляются через границу между открытыми системами. Тот факт, что абстрактные операции и ошибки посредством их описания фактически могут быть привлечены через СЭУО с использованием этих макрокоманд и при минимальных дополнительных спецификациях, не имеет значения в данном контексте.

5.2 Ранги

В настоящем стандарте используется концепция рангов в соответствии с ИСО/МЭК 10021-2.

5.3 Термины

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

Термины, означающие имена собственные, пишутся с прописной буквы, термины общего характера со строчной.

Глава вторая. АБСТРАКТНЫЕ ИНФОРМАЦИОННЫЕ ОБЪЕКТЫ

6 ОБЩЕЕ ОПИСАНИЕ


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

InformationObject : : = CHOICE {

ipm

[0]

IPM,

ipn

[1]

IPN }


В данной главе рассмотрены следующие вопросы:

а) межперсональные сообщения;

б) межперсональные уведомления.

Примечания

1 В данной части такие слова, как "отправитель" и "получатель" предполагают тот факт, что МПС и МПУ передаются между пользователями в виде содержимого сообщений (см. раздел 20). Эти слова отражают, следовательно, роли пользователей и СР, выполняемые в процессе таких передач.

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

3 МПС или МПУ дают различные оценки своему собственному трансмитталу (например, относительно отправителя содержащего его сообщения). Кроме того, МПУ оценивает трансмиттал того МПС, ответом на которое он служит. Все эти оценки неподтверждаемы.

7 МЕЖПЕРСОНАЛЬНЫЕ СООБЩЕНИЯ


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

IPM : : = SEQUENCE {

heading

Heading,

body

Body }


Оно состоит из следующих компонентов:

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

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

Body : : = SEQUENCE OF BodyPart

Структура МПС показана на рисунке 1.

Рисунок 1 - Межперсональное сообщение

Рисунок 1 - Межперсональное сообщение



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

Примечание - МПС может относиться к деловым документам. Фактически понятия "заголовок" и "тело" прибегают к такой аналогии.

7.1 Типы компонентов полей заголовка

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

7.1.1 Идентификатор МПС

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

IPMIdentifier : : = [APPLICATION 11] SET {

user

ORAddress OPTIONAL,

user-relative-identifier

Local IPMIdentifier }


Идентификатор МПС имеет следующие компоненты:

а) пользователь (Ф) - идентифицирует пользователя, отправляющего МПС. Один из адресов О/П пользователя. Отсутствие этого компонента нежелательно.

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

Local IPMIdentifier : : = PrintableString

(SIZE (0 ..ub-Iocal-ipm-identifier))


Примечание - "11" в идентификаторе МПС - это только тег прикладного масштаба АСН.1, присвоенный настоящим стандартом.

7.1.2 Определитель получателя

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

ReciрientSрecifier : : = SET {

recipient

[0]

ORDescriptor,

notification-requests

[1]

NotificationRequests DEFAULT {},

reply-requested

[2]

BOOLEAN DEFAULT FALSE }

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

а) получатель (О) - идентифицирует рассматриваемого предпочтительного получателя. Дескриптор О/П.

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

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

NotificationRequests : : = BIT SDTRING {

rn

(0),

nrn

(1),

ipm-return

(2) }


Этот компонент может предполагать любое из следующих значений одновременно, за исключением того, что значение rn не должно выбираться, если только не выбрано nrn:

I) rn - запрошено уведомление о приеме в ситуации, предписанной в разделе 8.

II) nrn - запрошено уведомление о неприеме в ситуации, предписанной в разделе 8.

III) ipm-return - запрошен возврат МПС в любом уведомлении-о-неприеме.

в) запрошен-ответ (ПУ ложно) - определяет, запрошен ли ответ предпочтительного получателя, назначенного принимающим компонентом. Булево.

Ответ - это одно МПС, посылаемое в ответ на другое МПС. Пользователь может отвечать на МПС даже в том случае, если на него не запрошен ответ и даже если он не относится к предпочтительным получателям МПС. Более того, пользователь, от которого запрошен ответ, может воздержаться от ответа.

7.1.3 Дескриптор О/П

Дескриптор О/П представляет собой информационный элемент, который идентифицирует пользователя или СР.

ORDescriptor : : = SET {

formal-name

ORName OPTIONAL,

free-form-name

[0]

Free-Form-Name OPTIONAL,

telephone-number

[1]

TelephoneNumber OPTIONAL }


Дескриптор О/П имеет следующие компоненты:

а) формальное-имя (У) - идентифицирует рассматриваемого пользователя или СР. Одно из имен О/П.

Этот условный компонент должен иметь место только в том случае, если удовлетворяется один или несколько следующих критериев:

I) Компонент имя-свободной-формы отсутствует.

II) Дескриптор О/П имеется в поле заголовка ответ получателей.

III) Дескриптором О/П является компонент получателя в определителе получателя и условия, установленные в 7.1.2 подпункте а, удовлетворяются.

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

FreeFormName : : = TeletexString (SIZE (0..ub-free-form-nаmе))

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

TelephoneNumber : : = PrintableString (SIZE (0..ub-telephone-number))

Примечание - В каждом из перечисленных ниже полей заголовка может быть один или несколько дескрипторов О/П: отправитель, полномочные пользователи, получатели копии, получатели "слепой" копии и получатели ответа. Кроме того, дескриптор О/П может иметь место также в следующих полях уведомления (см. раздел 8): отправитель МПУ и предпочтительный получатель МПС.

7.2 Поля заголовка

Ниже определены и описаны поля, имеющиеся в заголовке МПС.

Heading : : = SET {

this-IPM

ThislPMField,

originator

[0]

OriginatorField OPTIONAL,

authorizing-users

[1]

AuthorizingUsersFieId OPTIONAL,

primary-recipients

[2]

Primary RecipientsField DEFAULT{},

copy-recipients

[3]

CopyRecipientsFields DEFAULT {},

blind-copy-recipients

[4]

BlindCopyRecipientsField OPTIONAL

replied-to-IPM

[5]

RepliedToIPMField OPTIONAL,

obsoleted-IPMs

[6]

ObsoletedIPMsField DEFAULT {},

related-IPMs

[7]

RelatedIPMsField DEFAULT {},

subject

[8]

EXPLICIT SubjectField OPTIONAL,

expiry-time

[9]

ExpiryTimeFieId OPTIONAL,

reply-time

[10]

reply-timeField OPTIONAL,

reply-recipients

[11]

ReplyRecipientsField OPTIONAL,

importance

[12]

ImportanceField DEFAULT normal,

sensitivity

[13]

SensitivityFieId OPTIONAL,

auto-forwarded

[14]

AutoForwardedFieId DEFAULT FALSE,

extensions

[15]

ExtensionsField DEFAULT{}}


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

7.2.1 Данное МПС

Поле заголовка данное МПС (О) идентифицирует МПС. Оно содержит идентификатор МПС.

ThisIPMField : : = IPMIdentifier

7.2.2 Отправитель

Поле заголовка отправитель (Ф) идентифицирует отправителя МПС. Оно содержит дескриптор O/П.

OriginatorField : : = ORDescriptor

7.2.3 Полномочные пользователи

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

AuthorizingUsersFieId : : = SEQUENCE OF AuthorizingUsersFieId

AuthorizingUsersFieId : : = ORDescriptor

Полномочным пользователем является пользователь, который либо индивидуально, либо совместно с другими пользователями уполномочен инициировать МПС. Слову "уполномочен" настоящий стандарт не дает точного определения; его смысл определяется пользователями.

Условное поле должно иметь место только в том случае, если полномочными пользователями являются не только отправители МПС.

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

7.2.4 Основные получатели

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

PrimaryRecipientsField : : = SEQUENCE OF PrimaryRecipients-Subfield

PrimaryRecipientsSubfield : : = RecipientSpecifier

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

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

7.2.5 Получатели копии

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

CopyRecipientsField : : = SEQUENCE OF CopyRecipientsSubfield

CopyRecipientsSubfield : : = RecipientSpecifier

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

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

7.2.6 Получатели слепой копии

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

BlindCopyRecipientsField : : = SEQUENCE OFBlindCopyRecipients-Subfield

BlindCopyRecipientsSubfieId : : = RecipientSpecifier

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

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

7.2.7 Ответ на МПС

Поле заголовка ответ на МПС (У) идентифицирует то МПС, на которое данное МПС является ответом. Оно содержит идентификатор МПС.

RepliedToIPMField : : = IPMIdentifier

Это условное поле должно иметь место, только в том случае, если МПС является ответом.

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

7.2.8 Устарелые МПС

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

ObsoIetedIPMsField : : = SEQUENCE OF ObsoletedIPMsSubfield

ObsoletedIPMsSubfield : : = IPMIdentifier

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

7.2.9 Родственные МПС

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

ReIatedIPMsFieId : : = SEQUENCE OF RelatedIPMsSubfield

ReIatedIPMsSubfield : : = IPMIdentifier

Слово "родственные" не имеет точного определения в настоящем стандарте, его смысл определяется пользователями.

Примечания

1 Родственным МПС может быть, например, МПС, рассматриваемое в теле текущего МПС.

2 В контексте продвижения следует различать продвигающее и продвигаемое МПС. Это поле должно указывать, какое из этих двух МПС является родственным для текущего МПС.

7.2.10 Субъект

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

SubjectField : : = TeletexString(SIZE(0..ub-subject-field))

7.2.11 Истекшее время

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

ExpiryTimeField : : = Time

7.2.12 Время ответа

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

ReplyTimeField : : = Time

7.2.13 Получатели ответа

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

Reply RecipientsField : : = SEQUENCE OF ReplyRecipientsSubfield

ReplyRecipientsSubfield : : = ORDescriptor

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

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

7.2.14 Важность

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

ImportanceField : : = ENUMERATED {

low

(0),

normal

(1),

high

(2) }


Перечисленные значения не определяются настоящим стандартом; их смысл определяется пользователями.

7.2.15 Чувствительность

Поле заголовка "чувствительность" (У) идентифицирует чувствительность полномочных пользователей к МПС.

SensitivityField : : = ENUMERATED {

personal

(1),

private

(2),

company-confidential

(3) }


Это поле может принимать одно из следующих значений:

а) персональная - МПС передается предпочтительным получателям как отдельным лицам, а не их профессиональным возможностям;

б) частная - МПС не должно передаваться никому другому, кроме предпочтительных получателей;

в) конфиденциальная-для-компании - МПС содержит информацию, которая должна быть обработана в соответствии с определенными компанией процедурами.

Это условное поле должно иметь место только в том случае, если МПС является чувствительным.

7.2.16 Автопродвижение

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

AutoForwardedField : : = BOOLEAN

7.2.17 Расширения

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

ExtensionsField : : = SET OF HeadingExtension

HeadingExtension : : = SEQUENCE{

type

OBJECT IDENTIFIER,

value

ANY DEFINED BY type DEFAULT NULL

NULL}


Каждое расширение имеет следующие компоненты:

а) тип (О) - идентифицирует семантику и ограничивает абстрактный синтаксис компонента значение. Объектный идентификатор.

б) значение (ПУ ноль) - информационный элемент, абстрактный синтаксис которого ограничен только компонентом. Тип "любой".

Компоненты типа всех расширений в поле расширений должны быть различными. Не каждое определенное расширение должно быть представлено в этом поле.

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

Каждое расширение должно определяться с помощью следующих макрокоманд:

HEADING-EXTENSION MACRO : : =

BEGIN

TYPE NOTATION : : = "VALUE" type lempty

VALUE NOTATION : : = value (VALUE OBJECT IDENTIFIER)


END

Каждая нотация типа макрокоманды идентифицирует тип данных, для которого компонент "значение" расширения должен быть ограничен. Если ни один из типов в явном виде не определен, предполагается нулевое значение.

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

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

7.3 Типы частей тела

Ниже определены и описаны те типы частей тела, которые могут иметь место в теле МПС.

BodyPart : : = CHOICE {

ia5-text

[0]

IA5TextBodyPart,

voice

[2]

VoiceBodyPart,

g3-facsimile

[3]

G3FacsimileBodyPart,

g4-class1

[4]

G4Class1BodyPart,

teletex

[5]

TeletexBodyPart,

videotex

[6]

VideotexBodyPart,

encrypted

[8]

EncryptedBodyPart,

message

[9]

MessageBodyPart,

mixed-mode

[11]

MixedModeBodyPart,

bilaterally-defined

[14]

BilaterallyDefinedBodyPart,

nationally-defined

[7]

NationallyDefinedBodyPart,

externally-defined

[15]

ExternallyDefinedBodyPart}


Части тела некоторых определенных ниже типов имеют два компонента: параметры и данные. Компонент параметры (О) содержит последовательность информационных элементов, которые описывают те информационные объекты, которые представлены в части тела и которые обычно являются параметрами формата и управления. Компонент данные (О) сам является информационным объектом.

Примечания

1 В Рекомендации Х.420 (1984) МККТТ специфичные-для контекста теги 1 и 10 означают телексные и просто форматируемые части тела документа соответственно, которые не имеют дальнейших определений. Следовательно, эти теги отсутствуют в части тела.

2 В некоторых случаях МПС при прохождении между пользователями может подвергаться преобразованию. Такое событие трансмиттала может изменить тип части тела.

7.3.1 Текст МК5

Часть тела текст МК5 представляет текст МК5. Она состоит из параметров и данных.

IA5TextBodyPart : : = SEQUENCE {

parameters

IA5TextParameters,

data

IA5TextData}


IA5TextParameters : : = SET {

repertoire

[0] Repertoire DEFAULT ia5}


IA5TextData : : = IA5String

Компонент "параметры" содержит следующие параметры:

а) репертуар (ПУ МК5) - идентифицирует набор знаков, которым ограничен компонент "данные".

Repertoire : : = ENUMERATED {

ita2

(2),

ia5

(5)}


Этот параметр может иметь одно из следующих значений:

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

II) МК5: Компонент "данные" может быть получен при полном наборе знаков МК.

Компонент "данные" представляет собой текст, строку МК5. Он может иметь строки любой длины. При каждом физическом изображении этого компонента (например, выводе на дисплей или распечатке для пользователя) весь текст (а не только его часть) должен быть взаимосвязан (например, линии могут свертываться, но не должны усекаться).

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

7.3.2 Речь

Часть тела речь представляет собой разговор. Она содержит параметры и данные.

VoiceBodyPart : : = SEQUENCE {

parameters

VoiceParameters,

data

VoiceData}


VoiceParameters : : = SET--для дальнейшего изучения

VoiceData : : = BIT STRING--для дальнейшего изучения

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

7.3.3 Г3 факсимиле

Часть тела Г3 факсимиле представляет собой изображение группы 3 факсимиле. Она содержит параметры и данные.

G3FacsimileBodyPart : : = SEQUENCE {

parameters

G3FacsimileParameters,

data

G3FacsimileData}


G3FacsimileParameters : : = SET {

number-of-pages

[0] INTEGER OPTIONAL,

non-basic-parameters

[1] G3FacsimiIeNonBasicParametersOPTIONAL}


G3FacsimileData : : = SEQUENCE OF BIT STRING

Компонент "параметры" охватывает следующие параметры:

а) число-страниц (Ф) - идентифицирует число страниц данных группы 3 факсимиле в компоненте "данные". Неотрицательное целое.

б) не-базовые параметры (У): идентифицирует не-базовые параметры (НБП) группы 3 факсимиле, которые характеризуют компонент "данные". Дескриптор НБП Г3.

Этот условный параметр должен иметь место в том случае, если тело содержит две или более частей Г3 факсимиле.

Компонент "данные" представляет собой факсимильное изображение, последовательность битовых строк, каждая из которых кодирует отдельную страницу факсимильных данных группы 3 в соответствии с требованиями Рекомендаций Т.4 и Т.30.

Примечания

1 Компонент "число-страниц" идентифицирует число элементов последовательности, которые образуют компонент "данные" и, таким образом, является избыточным.

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

7.3.4 Г4 класс 1

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

G4Class1BodyPart : : = SEQUENCE OF ProtocolElement

7.3.5 Телетекс

Часть тела телетекс представляет собой телетексный документ. Она содержит параметры и данные.

TeletexBodyPart : : = SEQUENCE {

parameters

TeletexParameters,

data

TeletexData}


TeletexParameters : : = SET {

number-of-pages

[0] INTEGER OPTIONAL,

telex-compatible

[1] BOOLEAN DEFAULT FALSE,

non-basic-parameters

[2] TeletexNonBasicParameters OPTIONAL}


TeletextData : : = SEQUENCE OF TeletexString

Компонент "параметры" содержит следующие параметры:

а) число-страниц (Ф) - идентифицирует число страниц телетексного текста, содержащегося в компоненте "данные". Не-отрицательное целое число.

б) совместимый-с-телексом (ПУ ложно) - определяет, является ли документ в компоненте данные телексно-совместимым. Булева переменная.

Если этот параметр имеет значение истинно, то каждая телексная строка в компоненте "данные" должна быть ограничена набором знаков МТК2. Ни одна строка не должна иметь длину, превышающую 69 знаков.

в) не-базовые параметры (У) - идентифицирует те НБП телетекса, которые характеризуют компонент "данные". Дескриптор телетексных НБП.

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

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

Примечания

1 Компонент "число-страниц" идентифицирует число элементов последовательности, которые образуют компонент "данные" и является, таким образом, избыточным.

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

7.3.6 Видеотекс

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

VideotexBodyPart : : = SEQUENCE {

parameters

VideotexParameters,

data

VideotexData}


VideotexParameters : : = SET {

syntax

[0] VideotexSyntax OPTIONAL}


VideotexData : : = VideotexString

Компонент "параметры" содержит следующие параметры:

а) синтаксис (Ф) - идентифицирует синтаксис компонента "данные". При отсутствии этого параметра синтаксис должен рассматриваться неопределенным.

VideotexSyntax : : = INTEGER {

ids

(0),

data-syntax1

(1),

data-syntax2

(2),

data-syntax3

(3)}


Этот параметр может иметь одно из следующих значений, каждое из которых обозначает, как показано ниже, один из видеотексных синтаксисов, определенных в Рекомендациях Т.100 и Т.101:

I) идс: синтаксис ИДС;

II) синтаксис-данных 1: синтаксис данных 1;

III) синтаксис-данных 2: синтаксис данных 2;

IV) синтаксис-данных 3: синтаксис данных 3.

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

7.3.7 Зашифрованное

Часть тела зашифрованное представляет результат шифрования части тела, тип которой определен настоящим стандартом. Она имеет параметры и данные.

EncryptedBodyPart : : = SEQUENCE {

parameters

EncryptedParameters,

data

EncryptedData }


EncryptedParameters : : = SET -- для дальнейшего изучения

EncryptedData : : = BIT STRING -- для дальнейшего изучения

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

Компонент "данные" представляет собой зашифрованную часть тела, битовую строку. Биты этой битовой строки должны зашифровывать значение данных типа (АСН.1) части тела, закодированной в соответствии с базовыми правилами кодирования ГОСТ 34.974.

7.3.8 Сообщение

Часть тела сообщение представляет собой МПС, а также, факультативно, конверт его доставки. Она имеет параметры и данные.

MessageBodyPart : : = SEQUENCE {

parameters

MessageParameters,

data

MessageData }


MessageParameters : : = SET {

delivery-time

[0] MessageDeliveryTime OPTIONAL,

delivery-envelope

[1] OtherMessageDeliveryFields OPTIONAL }


MessageData : : = IPM

Компонент "параметры" содержит следующие параметры:

а) время-доставки (Ф) - дата и время, в которое было доставлено МПС. Наличие этого компонента при отсутствии компонента "конверт-доставки" нежелательно.

б) конверт-доставки (Ф) - поля доставки другого сообщения МПС. Наличие этого компонента при отсутствии компонента "конверт-доставки" нежелательно.

Компонентом "данные" является МПС.

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

Примечания

1 Вопрос возможного включения в будущем идентификатора сообщения в компонент "параметры" подлежит дальнейшему изучению. Его отсутствие в настоящее время обеспечивает совместимость с Рекомендацией Х.420 (1984).

2 Подлинность (в любом смысле) МПС и предполагаемого конверта доставки части тела "сообщение" не может быть подтверждена.

7.3.9 Смешанный-режим

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

MixedModeBodyPart : : = SEQUENCE OF ProtocoIElement

7.3.10 Определяемые двусторонним соглашением

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

BilateraIIyDefinedBodyPart : : = OCTET STRING

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

7.3.11 Национально определяемые

Часть тела национально определяемые представляет собой информационный объект, семантика и абстрактный синтаксис которого определяются в национальном масштабе страной, идентифицированной путем двустороннего соглашения между отправителем МПС и его потенциальными получателями. Она содержит переменную "любое".

NationalIyDefinedBodyPart : : = ANY

Примечания

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

2 Использование этого типа части тела нежелательно. Она хронологически предшествует части тела "внешне определяемый тип" и оставлена для обеспечения обратной совместимости с Рекомендацией Х.420 (1984). Часть тела "внешне определяемый тип" обеспечивает такие же или более широкие возможности, и его использование более предпочтительно. Например, благодаря такому использованию можно четко отличать части тела, определенные разными странами.

7.3.12 Внешне определяемая

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

ExternalIyDefinedBodyPart : : = SEQUENCE {

parameters

ExternaIIyDefinedParameters,

data

ExternaIIyDefinedData }


ExternaIlyDefinedParameters : : = EXTERNAL

ExternaIIyDefinedData : : = EXTERNAL

Компоненты "параметры" и "данные" являются внешними (см. раздел 32 ГОСТ 34.973). Должны иметь место те их компоненты, на которые они прямо ссылаются, а компоненты, на которые они ссылаются косвенно, и дескриптор-значения-данных должны отсутствовать.

Основываясь на части тела "внешне определяемые", все типы части тела подразделяются на два следующих важных класса:

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

Все базовые типы части тела определены в настоящем стандарте;

б) расширенный - некоторые внешне определяемые части тела, ограниченные до какого-нибудь одного значения компонента, на который дана прямая ссылка в компоненте "данные" этой части тела. Обозначается объектным идентификатором.

Некоторые (но не обязательно все) расширенные типы части тела определены в приложении В настоящего стандарта.

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

EXTENDED-BODY-PART-TYPE MACRO : : =

BEGIN

TYPE NOTATION

: : = Parameters Data

VALUE NOTATION

: : = value (VALUE OBJECT IDENTIFIER)

Parameters : : =

"PARAMETERS" type "IDENTIFIER" "BY" value
(OBJECT IDENTIFIER) | empty

Data

: : =

"DATA" type


END

Пример нотации типа макрокоманды определяет посредством его раздела ПАРАМЕТРЫ тип значения данных, который представлен компонентом "параметры" такой (внешне определенной) части тела (внешней), и объектный идентификатор, который представлен в компоненте "прямая-ссылка" этого компонента "параметры". Отсутствие компонента "параметры" предполагается отсутствием такого раздела. Пример нотации типа определяет также посредством его раздела ДАННЫЕ тип значения данных, представленных компонентом "данные" такой части тела (внешней).

Пример нотации значения макрокоманды определяет объектный идентификатор, представленный в виде компонента "прямая ссылка" компонента "данные" такой (внешне определенной) части тела. Объектный идентификатор определяет правила кодирования части тела. Те части тела, типы которых определяет настоящий стандарт, должны кодироваться с использованием базовых правил кодирования АСН.1.

Примечания

1 Внешне определяемая часть тела позволяет обмениваться информацией объектам всех видов, каждый из которых однозначно и недвусмысленно идентифицирован. Эта идентификация полагается на указанный выше компонент "прямая ссылка", который представляет собой объектный идентификатор. Объектные идентификаторы можно легко получить, например, национальным комитетам или частным организациям.

2 Если внешне определяемая часть тела имеет компонент "параметры", то объектный идентификатор в его компоненте "прямая-ссылка" размещается в то же время и тем же уполномоченным по присвоению имен, что и компонент "прямая-ссылка" компонента "данные".

3 Подобно частям тела других типов внешне определяемая часть тела может подвергаться преобразованиям. Однако спецификация алгоритмов преобразования не входит в предмет рассмотрения рекомендации Х.408.

4 Базовая часть тела существует только по чисто историческим причинам, хронологически предшествуя внешне определяемому типу части тела.

8 МЕЖПЕРСОНАЛЬНЫЕ УВЕДОМЛЕНИЯ


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

IPN : : = SET {

-- общие поля -- COMPONENTS OF Commonfields,

choice [0] CHOICE {

non-receipt-fields

[0] NonReceiptFields,

receipt-fields

[1] ReceiptFields }}


МПУ может принимать одну из следующих форм:

а) уведомление о неприеме (УНП) - МПУ, в котором отправителю сообщается о безуспешности получения, приема или о задержке приема МПС.

NRN : : = IPN -- с выбранными полями неприема

б) уведомление о приеме (УП) - МПУ, в котором отправителю сообщается о приеме МПС.

RN : : = INP -- с выбранными полями приема

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

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

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

МПУ содержит набор информационных элементов, называемых полями уведомления (или полями), каждый из которых относится к одному из следующих классов:

а) общее поле - поле уведомления, применимое и к УНП и к УП;

б) поле неприема - поле уведомления, применимое только к УНП;

в) поле приема - поле уведомления, применимое только к УП.

Структура МПУ изображена на рисунке 2.

Рисунок 2 - Межперсональное уведомление

Рисунок 2 - Межперсональное уведомление


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

8.1 Общие поля

Общие поля определены и описаны ниже.

Commonfields : : = SET {

subject-ipm

SubjectIPMField,

ipn-originator

(1) IPNOriginatorField OPTIONAL,

ipm-preferred-recipient

(2) IPMPreferredRecipientField OPTIONAL,

conversion-eits

ConversionEITsFieId OPTIONAL }

8.1.1 Субъектное МПС

Общее поле субъектное МПС (О) идентифицирует субъектное МПС. Оно содержит идентификатор МПС.

SubjectIPMField : : = IPMIdentifier

8.1.2 Отправитель МПУ

Общее поле отправитель МПУ (Ф) идентифицирует отправителя МПУ. Оно содержит дескриптор ОП.

IPNOriginatorField : : = ORDescriptor

Если отправителем МПУ является предпочтительный получатель субъектного МПС, то указанный выше дескриптор ОП должен быть точно таким же, как и значение компонента "получатель" определителя субъектного получателя.

8.1.3 Предпочтительный получатель МПС

Общее поле предпочтительный получатель МПС (У) идентифицирует предпочтительного получателя субъектного МПС, который после операции доставки стал отправителем МПУ (альтернативный, член (СР) или заменитель получателя). Он содержит дескриптор ОП.

IPMPreferredRecipientsField : : ORDescriptor

Указанный выше дескриптор ОП должен быть точно таким же, как и значение компонента "получатель" определителя субъектного получателя.

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

8.1.4 Преобразуемые ТКИ

Общее поле преобразуемые ТКИ (У) идентифицирует ТКИ субъектного МПС при доставке отправителю МПУ. Оно содержит дескриптор ТКИ.

ConversionEITsFieId : : = EncodedInformationTypes

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

8.2 Поля неприема

Поля неприема определены и описаны ниже.

NonReceiptFields : : = SET {

non-receipt-resson

[0]

NonReceiptRessonField,

discard-resson

[1]

DiscardRessonField OPTIONAL,

auto-forward-comment

[2]

AutoForwardCommentField OPTIONAL,

returned-ipm

[3]

ReturnedIPMField OPTIONAL }

8.2.1 Причина неприема

Поле неприема причина неприема (О) указывает, почему отправитель УНП не принял субъектное МПС (хотя оно и было доставлено ему).

NonReceiptReasonField : : = ENUMERATED {

ipm-discarded

(0),

ipm-auto-forwarded

(1) }


Это поле может принимать одно из следующих значений:

а) мпс-аннулировано - МПС было аннулировано. Этот случай поясняется далее полем причина аннулирования.

б) мпс-автоматически-продвинуто - МПС было автоматически продвинуто. Этот случай поясняется далее полем комментарий-автопродвижения.

8.2.2 Причина аннулирования

Поле неприема причина аннулирования (У) указывает, почему субъектное МПС было аннулировано (после его доставки отправителю УНП и перед его приемом).

DiscardReassonField : : = ENUMERATED {

ipm-expired

(0),

ipm-obsoleted

(1),

user-subcription-terminated

(2) }


Это поле может принимать одно из следующих значений:

а) мпс-истекло - действовало автоаннулирование, истекшие МПС были аннулированы и достигнуто время, идентифицированное полем заголовка "время субъектного МПС истекло".

б) мпс-устарело - действовало автоаннулирование, устаревшие МПС были аннулированы и поле заголовка "устаревшие МПС" другого МПС, доставленное отправителю УНП, идентифицирует субъектное МПС.

в) абонирование-пользователя-закончилось - абонирование межперсональных сообщений отправителем УНП закончилось.

Это условное поле должно иметь место только в том случае, если поле "причина неприема" имеет значение мпс-аннулировано.

8.2.3 Комментарий автопродвижения

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

AutoForwardCommentField : : = AutoForwardComment

AutoForwardComment : : = PrintableString

(SIZE (0 . . ub-auto-forward-comment))

Это поле должно иметь точно такое же значение, что и аргумент комментарий-автопродвижения абстрактной операции изменение автопродвижения, в результате которой субъектное МПС автоматически продвинулось.

Это условное поле должно иметь место только в том случае, если поле "причина неприема" имеет значение автопродвижение-МПС и обеспечен аргумент "комментарий автопродвижения".

8.2.4 Возвращенное МПС

Поле неприема возвращенное МПС (У) представляет собой в точности субъектное МПС.

ReturnedIPMField : : = IPM

Это условное поле должно иметь место только в том случае, если среди значений компонента "запросы-уведомления" определителя субъектного получателя имеется значение возврат-МПС и если субъектное МПС не подверглось преобразованию при доставке отправителю УНП.

8.3 Поля приема

Поля приема определены и описаны ниже.

ReceiрtField : : = SET {

receipt-time

[0] ReceiptTimeFieId,

acknowledgment-mode

[1] AcknowIedgmentModeField DEFAULT manual,

suppl-receipt-info

[2] SupplReceiptInfoField DEFAULT " "}

8.3.1 Время приема

Поле приема время приема (О) определяет, когда отправитель УП получил субъектное МПС. Оно содержит дату и время.

ReceiptTimeField : : = Time

8.3.2 Режим подтверждения

Поле приема режим подтверждения (ПУ ручной) определяет способ, которым было выдано УП.

AcknowledgmentModeField : : = ENUMERATED {

manual

(0),

automatic

(1))


Это поле может принимать одно из следующих значений:

а) ручной - УП было отправлено с помощью абстрактной операции отправка УП.

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

8.3.3 Дополнительная информация о приеме

Поле приема дополнительная информация о приеме (Ф) содержит дополнительную информацию о приеме субъектного МПС отправителем УП. Оно содержит распечатываемую строку.

SupplReceiptInfoField : : = Supplelementarylnformation

Глава третья. ОПРЕДЕЛЕНИЕ АБСТРАКТНЫХ УСЛУГ

9 ОБЩЕЕ ОПИСАНИЕ


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

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

а) типы первичных объектов,

б) типы первичных портов,

в) абстрактные операции,

г) абстрактные ошибки,

д) прочие возможности.

10 ТИПЫ ПЕРВИЧНЫХ ОБЪЕКТОВ


Функциональная среда, в которой происходит обмен межперсональными сообщениями, моделируется в виде абстрактного объекта, который в дальнейшем рассматривается как функциональная среда межперсональных сообщений (ФСМС).

ipme OBJECT

: : = id-ot-ipme


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

ipme-refinment REFINE ipme AS

ipms

origination

[S]

PAIRED WITH ipms-user

reception

[S]

PAIRED WITH ipms-user

management

[S]

PAIRED WITH ipms-user

ipms-user RECURRING

: : = id-ref-primary


Эти объекты, находящиеся в меньшем числе, рассматриваются как первичные объекты межперсональных сообщений. К ним относится отдельный центральный объект - система межперсональных сообщений (СМПС) и большое число периферийных объектов, называемых пользователями системы межперсональных сообщений (пользователями СМПС).

Структура ФСМС изображена на рисунке 3.

Рисунок 3 - Функциональная среда межперсональных сообщений

Рисунок 3 - Функциональная среда межперсональных сообщений

Ниже определены и описаны первичные типы объектов. Типы портов, с помощью которых осуществляется их обмен, рассматриваются в разделе 11.

10.1 Пользователь системы межперсональных сообщений

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

iрms-user OBJECT

PORTS {

origination

[C],

reception

[C],

management

[C] }

: : = id-ot-ipms-user


ФСМПС охватывает любое число пользователей СМПС.

Примечания

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

2 Для краткости далее в настоящем стандарте вместо "пользователь СМПС" применяется термин "пользователь".

10.2 Система межперсональных сообщений

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

ipms OBJECT

PORTS {

origination

[S],

reception

[S],

management

[S] }

: : = id-ot-ipms


ФСМПС содержит в точности одну СМПС.

11 ПЕРВИЧНЫЕ ТИПЫ ПОРТОВ


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

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

11.1 Отправка

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

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

11.2 Прием

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

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

11.3 Административное управление

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

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

12 АБСТРАКТНЫЕ ОПЕРАЦИИ


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

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

Примечания

1 Абстрактные услуги СМПС не привлекают операций абстрактной связки и абстрактной развязки.

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

3 Цель определения абстрактных услуг СМПС состоит не в том, чтобы предписать пользовательские интерфейсы реализации частей СМПС, а скорее, для пояснения смысла и целевого использования информационных объектов, рассматриваемых во второй главе. Пользовательский интерфейс не должен обеспечивать команды однозначного соответствия абстрактным операциям этих услуг и даже не ставит своей целью распределить работу между пользователем и СМПС, как это делают услуги. Также модель определения абстрактных услуг не предусматривает возможности, предоставляемые хранилищем сообщений.

4 В разделе 16 проводится разложение СМПС на объекты, к числу которых относится СПС. В данном подразделе этот факт отражен включением различных определяемых СПС информационных элементов в состав абстрактных услуг СМПС.

12.1 Абстрактные операции отправки

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

origination PORT

CONSUMER INVOKES {

OriginateProbe,

OriginateIPM,

OriginateRN}

: : = id-pt-origination

12.1.1 Отправка зонда

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

OriginateProbe : : = ABSTRACT-OPERATION

ARGUMENT SET {

envelope

[0]

ProbeSubmissionEnvelope,

content

[1]

IPM}

RESULT SET {

submission-identifier

[0]

ProbeSubmissionIdentifier,

submission-time

[1]

ProbeSubmissionTime}

ERRORS {

SubcriptionError,

RecipientImproperlySpecified}


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

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

I) Желательные факультативные возможности на-сообщение (т.е. указатели на-сообщение и расширения).

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

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

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

1) идентификатор-предоставления (О) - идентификатор предоставления зонда, который СПС присваивает зонду;

2) время-предоставления (О) - дата и время непосредственного предоставления зонда.

12.1.2 Отправка МПС

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

OriginateIPM : : = ABSTRACT-OPERATION

ARGUMENT SET {

envelope

[0]

MessageSubmissionEnvelope,

content

[1]

IPM}

RESULT SET {

submission-identifier

[0]

MessageSubmissionIdentifier,

submission-time

[1]

MessageSubmissionTime}

ERRORS {

SubcriptionError,

RecipientImproperIySpecified)


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

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

I) Желательные факультативные возможности на-сообщение (т.е. приоритет, указатели на-сообщение, время задержанной доставки и расширения).

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

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

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

1) идентификатор-предоставления (О) - идентификатор предоставления сообщения, который СПС присваивает предоставлению;

2) время-предоставления (О) - дата и время непосредственного предоставления сообщения.

12.1.3 Отправка УП

Абстрактная операция отправка УП отправляет сообщение, содержимым которого является УП.

OriginateRN : : = ABSTRACT-OPERATION

ARGUMENT SET {

envelope

[0]

MessageSubmissionEnvelope,

content

[1]

RN }

RESULT SET {

submission-identifier

[0]

MessageSubmissionIdentifier,

submission-time

[1]

MessageSubmissionTime}

ERRORS {

SubcriptionError,

RecipientImproperlySpecified}


УП должно отправляться только фактическим получателем субъектного МПС, от которого запрошено УП посредством компонента запросы-уведомления определителя субъектного получателя субъектного МПС.

Пользователь не должен получать ранее отправленное УП в ответ на субъектное МПС посредством либо текущей абстрактной операции, либо автоподтверждения.

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

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

I) Желательные факультативные возможности на-сообщение (т.е. приоритет, указатели на-сообщение и расширения). Неявное преобразование должно быть запрещено с приоритетом субъектного МПС.

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

б) содержимое (О) - отправляемое УП.

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

1) идентификатор-предоставления (О) - идентификатор предоставления сообщения, который СПС присваивает данному предоставлению;

2) время-предоставления (О) - дата и время непосредственного предоставления сообщения.

12.2 Абстрактные операции приема

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

reception PORT

SUPPLIER INVOKES {

ReceiverReport,

ReceiverIPM,

ReceiverRN,

ReceiverNRN }

: : = id-pt-reception


Примечания

1 Будучи абстрактно определенной, СМПС не имеет памяти для принимаемых сообщений, поскольку ее наличие или отсутствие не влияет на возможности пользователя взаимодействовать с другими пользователями. Таким образом, обеспечение памяти - это локальный вопрос.

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

12.2.1 Прием отчета

Абстрактная операция прием отчета принимает отчет.

ReceiveReport : : = ABSTRACT-OPERATION

ARGUMENT SET {

envelope

[0] ReportDeliveryEnvelope,

undelivered-object

[1] InformationObject OPTIONAL}

RESULT

ERRORS {}


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

а) зонд, относящийся к сообщению, содержимым которого было МПС, отправленное абстрактной операцией "отправка зонда";

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

в) сообщение, содержимым которого было УП, отправленное абстрактной операцией "отправка УП" или автоподтверждением.

г) сообщение, содержимым которого было МПС, отправленное абстрактной операцией "отправка МПС" или автопродвижение.

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

1) конверт (О) - конверт доставки отчета, структура которого определяет абстрактную услугу СПС;

2) недоставленный объект (У) - содержимое сообщения, о статусе которого выдается отчет МПС или МПУ.

Если отчет был обусловлен предыдущим привлечением абстрактной операции "отправка зонда", этот условный аргумент должен отсутствовать. Если отчет был обусловлен предыдущим привлечением абстрактной операции "отправка МПС", этот аргумент должен иметь место только в том случае, если возврат содержимого был запрошен. В противном случае (т.е. если отчет был обусловлен МПУ) этот аргумент должен отсутствовать.

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

12.2.2 Прием МПС

Абстрактная операция прием МПС принимает сообщение, содержимым которого является МПС.

ReceiveIPM : : = ABSTRACT-OPERATION

ARGUMENT SET {

envelope

[0]

MessageDeIiveryEnvelope,

content

[1]

IPM}

RESULT

ERRORS {}


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

а) конверт (О) - конверт доставки сообщения;

б) содержимое (О) - МПС, которое является содержимым сообщения.

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

12.2.3 Прием УП

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

ReceiveRN : : = ABSTRACT-OPERATION

ARGUMENT SET {

envelope

[0]

MessageDeIiveryEnvelope,

content

[1]

RN}

RESULT

ERRORS {}


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

а) конверт (О) - конверт доставки сообщения;

б) содержимое (О) - УП, которое является содержимым сообщения.

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

12.2.4 Прием УНП

Абстрактная операция прием УНП принимает сообщение, содержимым которого является УНП. Это УНП обусловлено отправкой МПС посредством абстрактной операции "отправка МПС".

ReceiveNRN : : = ABSTRACT-OPERATION

ARGUMENT SET {

envelope

[0] MessageDeliveryEnvelope,

content

[1] NRN }

RESULT

ERRORS {}


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

а) конверт (О) - конверт доставки сообщения;

б) содержимое (О) - УНП, которое является содержимым сообщения.

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

12.3 Абстрактные операции управления

Эти абстрактные операции, доступные в порту управления, привлекаются пользователем и выполняются СМПС.

management PORT

CONSUMER INVOKES {

ChangeAutoDiscard,

ChangeAutoAcknowledgment,

ChangeAutoForwarding}


: : = id-pt-management

12.3.1 Изменение автоаннулирования

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

ChangeAutoDiscard : : = ABSTRACT-OPERATION

ARGUMENT SET {

auto-discard-expired-IPMs [0] BOOLEAN,

auto-discard-obsolete-IPMs [1] BOOLEAN }

RESULT

ERRORS {}


При автоаннулировании МПС СМПС отправляет от имени пользователя УНП только в том случае, если уведомление запрошено им с помощью компонента запросы-уведомления определителя субъектного получателя.

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

а) автоаннулирование-истекших-МПС (О) - следует или нет аннулировать истекшее МПС; булева переменная;

б) аннулирование-устаревших-МПС (О) - следует или нет аннулировать устаревшее МПС; булева переменная.

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

12.3.2 Изменение автоподтверждения

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

ChangeAutoAcknowledgment : : = ABSTRACT-OPERATION

ARGUMENT SET {

auto-acknowledgment-IPMs [0] BOOLEAN,

auto-acknowledgment-suppl-receipt-info [1]

Supplementarylnformation OPTIONAL }

RESULT

ERRORS {

SubscriptionError}


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

а) автоподтверждение-МПС (О) - следует или нет автоматически подтверждать МПС; булева переменная;

б) автоподтверждение-обеспеченной-информации-о-приеме (У) - поле приема "обеспеченная-информация-о-приеме" каждого УП, обусловленного автоподтверждением.

Этот условный аргумент должен иметь место только в том случае, если аргумент автоподтверждение-МПС имеет значение истинно.

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

12.3.3 Изменение автопродвижения

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

ChangeAutoForwarding : : = ABSTRACT-OPERATION

ARGUMENT SET {

auto-forward-IPMs

[0]

BOOLEAN,

auto-forward-recipients

[1]

SEQUENCE OF ORName OPTIONAL,

auto-forward-heading

[2]

Heading OPTIONAL,

auto-forward-comment

[3]

AutoForwardComment OPTIONAL }

RESULT

ERRORS {

SubscriptionError,

RecipientImproperlySpecified}


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

Когда СМПС продвигает МПС, она отправляет УНП от имени пользователя только в том случае, если уведомление было запрошено им посредством компонента запросы-уведомления определителя субъектного получателя.

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

а) автопродвижение-МПС (О) - следует ли подвергать МПС автопродвижению; булева переменная;

б) получатели-автопродвижения (У) - пользователи или СР, к которым должны автоматически продвигаться МПС; последовательность имен О/П.

Этот условный аргумент должен иметь место только в том случае, если аргумент "автопродвижение МПС" имеет значение истинно.

в) заголовок-автопродвижения (У) - заголовок, который должен использоваться для каждого автоматически продвигаемого МПС; его поле "заголовок автопродвижения" должно иметь значение истинно;

Этот условный аргумент должен иметь место только в том случае, если аргумент "автопродвижение МПС" имеет значение истинно.

г) комментарий-автопродвижения (У) - значение, которое должно обеспечиваться как поле неприема "комментарий автопродвижения" каждого УНП, передаваемого отправителю автоматически продвинутого МПС.

Этот условный аргумент должен иметь место только в том случае, если аргумент "автопродвижение МПС" имеет значение истинно.

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

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

13 АБСТРАКТНЫЕ ОШИБКИ


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

Примечание - Приводимое ниже описание набора абстрактных ошибок является, скорее, иллюстративным, чем исчерпывающим.

13.1 Ошибка абонирования

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

SubscriptionError : : = ABSTRACT-ERROR

PARAMETER SET {

problem [0] SubcriptionProbIem}


Эта абстрактная ошибка имеет следующие параметры:

а) проблема (О) - возникла проблема, связанная с абонированием.

SubcriptionProblem : : = ENUMERATED {

ipms-eos-not-subcribed

(0),

mts-eos-not-subcribed

(1) }


Этот параметр может принимать одно из следующих значений:

I) эс-СМПС-не-абонирован - элемент службы СМПС не абонирован.

II) эс-СПС-не-абонирован - элемент службы СПС не абонирован.

13.2 Неправильно определен получатель

Абстрактная ошибка неправильно определен получатель сообщает, что одно или несколько имен О/П, представленные в виде аргументов абстрактной операции, выполнение которой прервано, либо в виде компонентов ее аргументов, недействительны.

Эта абстрактная операция определяется абстрактной службой СПС.

14 ПРОЧИЕ ВОЗМОЖНОСТИ


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

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

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

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

в) Административное управление - возможности административного порта ХС и СПС.

г) Поиск - возможности порта поиска ХС.

Кроме перечисленного и в качестве локального решения СМПС может обеспечить пользователям дополнительные возможности, которые не определяются и не ограничиваются настоящим стандартом. К этим возможностям относятся возможности справочника.

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

Глава четвертая. ОБЕСПЕЧЕНИЕ АБСТРАКТНЫХ УСЛУГ

15 ОБЩЕЕ ОПИСАНИЕ


В этой главе определяется, каким образом СМПС представляет пользователям абстрактные услуги, и рассматриваются следующие вопросы:

а) вторичные типы объектов;

б) вторичные типы портов;

в) операции агента пользователя;

г) операции хранилища сообщений;

д) содержимое сообщений;

е) реализация порта;

ж) соответствие.

16 ВТОРИЧНЫЕ ТИПЫ ОБЪЕКТОВ


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

ipms-refinement REFINE ipms AS

mTS

submission

[S]

PAIRED WITH ipms-ua, ipms-ms

delivery

[S]

PAIRED WITH ipms-ua, ipms-ms

administration

[S]

PAIRED WITH ipms-ua, ipms-ms

ipms-ua RECURRING

origination

[S]

VISIBLE

recertion

[S]

VISIBLE

management

[S]

VISIBLE

ipms-ms RECURRING

submission

[S]

PAIRED WITH ipms-ua

retrieval

[S]

PAIRED WITH ipms-ua

administration

[S]

PAIRED WITH ipms-ua

tlma RECURRING

origination

[S]

VISIBLE

recertion

[S]

VISIBLE

management

[S]

VISIBLE

tlxau RECURRING

origination

[S]

VISIBLE

recertion

[S]

VISIBLE

management

[S]

VISIBLE

pdau RECURRING

recertion

[S]

VISIBLE

: : = id-ref-secondary


Эти более мелкие объекты называются вторичными объектами межперсональных сообщений. К ним относятся один центральный объект - СПС и большое число периферийных объектов системы межперсональных сообщений: агенты пользователя системы межперсональных сообщений (АП СМПС), хранилища сообщений системы межперсональных сообщений (ХС СМПС), агенты телематической службы (АТЛМ), телексные модули доступа (МДТЛК) и МДФД.

Структура СМПС показана на рисунке 4. Как видно из рисунка, АП СМПС, АТЛМ, МДТЛК и МДФД представляют собой инструменты, с помощью которых СМПС предоставляет пользователям абстрактные услуги СМПС.

Рисунок 4 - Система межперсональных сообщений

Рисунок 4 - Система межперсональных сообщений



Ниже определены и описаны эти вторичные типы объектов. Типы портов, через которые они взаимодействуют, рассмотрены в разделе 17.

Примечания

1 Приведенная выше детализация охватывает всевозможные взаимосвязи всех возможных объектов. В ней игнорируется возможное отсутствие объектов конкретного типа (например, МДФД) и конкретные логические конфигурации ХС СМПС. Последние определены в ИСО/МЭК 10021-2.

2 Рекомендация Т.330 эффективно распространяет абстрактные услуги системы межперсональных сообщений на определяемые ею смешанные порты, не показанные на рисунке 4. См. примечание в 16.3.

3 СМПС обеспечивает порты импорта и экспорта. Однако поскольку эти порты формально не определены в ИСО/МЭК 10021-4, они не включены в приведенную выше формальную детализацию.

16.1 Агент пользователя системы межперсональных сообщений

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

ipms-ua OBJECTS

PORTS {

origination

[S],

recertion

[S],

management

[S],

submission

[C],

delivery

[C],

retrieval

[C],

administration

[C] }


: : = id-ot-ipms-ua

СМПС может содержать любое количество АП СМПС.

Примечание - Далее в настоящем стандарте вместо "АП СМПС" для краткости используется термин "АП".

16.2 Хранилище сообщений системы межперсональных сообщений

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

ipms-ms OBJECT

PORTS {

submission

[S],

retrieval

[S],

administration

[S],

submission

[C],

delivery

[C],

administration

[C] }


: : = id-ot-ipms-ms

СМПС может содержать любое число ХС СМПС.

Примечание - Далее в настоящем стандарте вместо термина "ХС СМПС" для краткости используется термин "ХС".

16.3 Агент телематической службы

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

tlma OBJECT

PORTS {

origination

[S],

recertion

[S],

management

[S],

miscellanea

[S] }


: : = id-ot-tlma

СМПС может содержать любое число АТЛМ.

Примечания

1 АТЛМ использует порты импорта и экспорта. Поскольку оба эти вида портов формально не определены в ИСО/МЭК 10021-4, они не включены в приведенное выше формальное определение АТЛМ.

2 Комбинированный порт АТЛМ определен в рекомендации Т.330 МККТТ. В своем общем виде, рассматриваемом в настоящем стандарте, он не является частью абстрактных услуг СМПС. Он, скорее, воплощает возможности, доступные только для пользователя АТЛМ. По этой причине далее в настоящем стандарте он более не рассматривается и не включен в формализованное уточнение СМПС, приведенное в разделе 16.

16.4 Телексный модуль доступа

Телексный модуль доступа (МДТЛК) представляет собой МД, который помогает любому числу косвенных пользователей участвовать в передаче межперсональных сообщений из телексного оконечного оборудования. Он помогает им отправлять, получать либо отправлять и получать сообщения, содержащие объекты, типы которых определены во второй главе.

tlхau OBJECT

PORTS {

origination

[S],

recertion

[S],

management

[S] }


: : = id-ot-tlxau

СМПС может содержать любое число МДТЛК.

Примечание - МДТЛК содержит порты импорта и экспорта. Поскольку они формально не определены в ИСО/МЭК 10021-4, они не включены в приведенное выше формальное определение МДТЛК.

16.5 Модуль доступа физической доставки

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

PORTS {

recertion

[S] }


: : = id-ot-pdau

СМПС содержит любое число МДФД.

Примечание - МДФД содержит порты импорта и экспорта. Поскольку эти порты формально не определены в ИСО/МЭК 10021-4, они не включены в приведенное выше формальное определение МДФД.

16.6 Система передачи сообщений

В данном контексте СПС передает информационные объекты, типы которых определены во второй главе, между АП, ХС, АТЛК и МД.

СМПС содержит одну СПС.

17 ВТОРИЧНЫЕ ТИПЫ ОБЪЕКТОВ


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

Функциональные возможности, обеспечиваемые одним портом предоставления, одним портом поиска и одним административным портом, образуют абстрактную службу ХС. Она определена в ГОСТ Р ИСО/МЭК 10021-5.

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

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

17.1 Предоставление

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

ХС обеспечивает для своего АП один порт предоставления.

СПС обеспечивает по одному порту предоставления для каждого АП, который не имеет ХС, и для каждого ХС.

17.2 Доставка

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

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

17.3 Поиск

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

ХС обеспечивает для своего АП один порт поиска.

17.4 Административное управление

В данном контексте административный порт - это средство, с помощью которого АП изменяет информацию относительно себя или своего пользователя в файле своего ХС; либо АП или ХС изменяет подобную информацию в файле СПС.

ХС обеспечивает один административный порт для своего АП.

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

17.5 Импорт

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

СПС обеспечивает по одному порту импорта для каждого АП (или АТЛМ).

17.6 Экспорт

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

СПС обеспечивает по одному порту экспорта для каждого АП (или АТЛМ).

18 ОПЕРАЦИИ АГЕНТА ПОЛЬЗОВАТЕЛЯ


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

Правила, которые регулируют работу АП (и ХС), рассматриваются в данном разделе. Операции АТЛМ и МД не входят в предмет рассмотрения настоящего стандарта.

Примечания

1 Исторически сложилось так, что ГОСТ Р ИСО/МЭК 10021, который определяет абстрактные услуги СМПС, определяет также способ, которым АП (и ХС), но не АТЛМ или МД, обеспечивает их.

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

18.1 Переменные

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

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

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

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

18.2 Рабочие характеристики операций отправки

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

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

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

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

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

18.2.1 Отправка зонда

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

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

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

I) Имя-отправителя - имя О/П пользователя АП.

II) Тип-содержимого, длина-содержимого и исходные-типы-кодированной-информации - определяются из аргумента "содержимое" отправки зонда в соответствии с подразделами 20.2-20.4.

Ill) Идентификатор-содержимого - наличие или отсутствие определяется локальным решением.

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

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

1) Идентификатор-предоставления - результат "идентификатор-предоставления-зонда" операции "предоставление зонда".

2) Время-предоставления - результат "время-предоставления-зонда" операции "предоставление зонда".

Примечания

1 АП должен игнорировать все свойства аргумента "содержимое" операции "отправка зонда", кроме упомянутых выше.

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

18.2.2 Отправка СМПС

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

Аргументы предоставления сообщения следующие:

а) конверт - к компонентам этого аргумента, образующим поля на-сообщение, должны относиться перечисленные ниже; явно не указанные ниже аргументы должны определяться аргументом конверта отправляемого МПС:

I) Имя-отправителя - имя О/П пользователя АП.

II) Тип-содержимого и исходные-типы-кодированной-информации - определяются из аргумента "содержимое" отправляемого МПС в соответствии с 20.2 и 20.4 соответственно.

Ill) Идентификатор-содержимого - наличие или отсутствие определяется локальным решением.

Компоненты этого аргумента, образующие поля на-получателя, должны определяться аргументом "конверт" отправляемого МПС.

б) содержимое - определяется, исходя из аргумента "содержимое" отправляемого МПС (идентифицируемого как МПС) в соответствии с 20.1.

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

Результатом отправки МПС должен быть один из следующих:

1) Идентификатор-предоставления - результат предоставления сообщения "идентификатор-предоставления-сообщения".

2) Время-предоставления - результат предоставления сообщения "время-предоставления-сообщения".

Примечания

1 Способ использования агентом пользователя результата предоставления сообщения "идентификатор-содержимого" является локальным вопросом.

2 Включение результата предоставления сообщения "расширения" в число результатов отправки МПС - предмет дальнейшего изучения.

18.2.3 Отправка УП

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

Аргументами предоставления сообщения должны быть следующие:

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

I) Имя-отправителя - имя О/П пользователя АП.

II) Тип-содержимого и исходные-типы-кодированной-информации - определяются из аргумента "содержимое" отправляемого УП в соответствии с 20.2 и 20.4 соответственно.

III) Идентификатор-содержимого - наличие или отсутствие определяется локальным решением.

IV) Время-задержанной-доставки - отсутствует.

Компоненты этого аргумента, образующие поля на-получателя, должны определяться аргументом "конверт" отправляемого УП.

б) содержимое - определяется, исходя из аргумента "содержимое" отправляемого УП (идентифицируемого как УП) в соответствии с 20.1.

Результатом отправки УП должен быть один из следующих:

1) Идентификатор-предоставления - результат предоставления сообщения "идентификатор-предоставления-сообщения".

2) Время-предоставления - результат предоставления сообщения "время-предоставления-сообщения".

Примечания

1 Способ использования агентом пользователя результата предоставления сообщения "идентификатор-содержимого" является локальным вопросом.

2 Включение результата предоставления сообщения "расширения" в число результатов отправки УП - предмет дальнейшего изучения.

18.3 Рабочие характеристики операций управления

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

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

18.3.1 Изменение автоаннулирования

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

а) автоаннулирование-истекших-МПС - булева переменная, которая указывает, действует или нет автоаннулирование относительно истекших МПС;

б) автоаннулирование-устаревших-МПС - булева переменная, которая указывает, действует или нет автоаннулирование относительно устаревших МПС.

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

18.3.2 Изменение автоподтверждения

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

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

б) автоподтверждение-информации-о-приеме - поле "информация-о-приеме" каждого УП, обусловленное автоподтверждением.

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

18.3.3 Изменение автопродвижения

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

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

б) получатели-автопродвижения - последовательность имен О/П, которые идентифицируют пользователей и СР, к которым происходит автопродвижение МПС;

в) заголовок-автопродвижения - заголовок каждого продвигаемого МПС, обусловленного автопродвижением. Его поле автопродвижения имеет значение "истинно";

г) комментарий-автопродвижения - поле неприема "комментарий автопродвижения" каждого УНП, передаваемое отправителю автоматически продвинутого МПС.

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

18.4 Привлечение операций приема

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

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

а) доставка отчета;

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

Примечание - Абстрактная операция "отчет" порта приема не имеет ошибок.

18.4.1 Прием отчета

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

а) конверт - аргумент "конверт" доставки отчета;

б) недоставленный-объект - определяется из аргумента "возвращенное содержимое" доставки отчета в соответствии с 20.1.

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

18.4.2 Прием МПС

Всякий раз, когда СПС привлекает в порту доставки АП операцию "доставка сообщения" и ее аргумент "содержимое", закодированный в МПС в соответствии с 20.1, АП должен привлекать абстрактную операцию "прием МПС" с перечисленными ниже аргументами при условии, что данное сообщение не является объектом ни автопродвижения, ни автоаннулирования (см. 18.5):

а) конверт - аргумент "конверт" доставки сообщения;

б) содержимое - определяется из аргумента "содержимое" доставки сообщения в соответствии с 20.1 (но не помечаемый более как МПС).

18.4.3 Прием УП

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

а) конверт - аргумент "конверт" доставки сообщения;

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

18.4.4 Прием УНП

Всякий раз, когда СПС привлекает в порту доставки АП операцию "доставка сообщения" и ее аргумент "содержимое", закодированный в УНП в соответствии с 20.1, АП должен привлекать абстрактную операцию "прием УНП" с перечисленными ниже аргументами:

а) конверт - аргумент "конверт" доставки сообщения;

б) содержимое - определяется из аргумента "содержимое" доставки сообщения в соответствии с 20.1 (но не помечаемый более как УНП).

18.5 Внутренние процедуры

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

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

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

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

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

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

а) СПС передала сообщение к АП путем привлечения операции "прием МПС" в порту доставки АП;

б) АП не передал сообщение пользователю путем привлечения операции "прием МПС" в порту приема пользователя;

с) сообщение содержит МПС (а не МПУ).

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

18.5.1 Автоаннулирование

АП должен подвергнуть автоаннулированию каждое рассматриваемое в качестве кандидата сообщение, относительно содержимого которого соблюдено любое из следующих условий:

а) переменная автоаннулирование-истекшего-МПС имеет значение истинно, а дата и время, указанные полем "время истечения МПС", прошли;

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

18.5.1.1 Аннулирование МПС

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

18.5.1.2 Структура УНП

АП должен создавать УНП только в том случае, если УНП запрошено посредством компонента запросы-уведомления определителя субъектного получателя МПС.

УНП должно иметь общие поля, предписанные при автопродвижении (см. 18.5.2.1).

УНП должно иметь следующие поля приема:

а) причина-неприема - значение мпс-аннулировано.

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

в) комментарий-автопродвижения - отсутствует.

г) возвращаемое-МПС - если возврат МПС запрошен посредством компонента запросы-уведомления его определителя субъектного получателя, а компонент преобразованные-типы-кодированной-информации аргумента "конверт" доставки сообщения отсутствует, МПС возвращается. В противном случае МПС отсутствует.

18.5.1.3 Предоставление УНП

АП должен предоставлять указанное УНП (при его наличии) путем привлечения операции предоставления сообщения. Его аргумент "конверт" должен соответствовать предписанному для автоподтверждения (см. 18.5.2.2), а его аргумент "содержимое", определяемый из УНП, должен соответствовать 20.1.

18.5.2 Автоподтверждение

АП должен подвергать автоподтверждению каждую кандидатуру сообщения, содержимое которого удовлетворяет следующим условиям:

а) переменная автоподтверждения имеет значение истинно, и МПС запрашивает УП от пользователя АП посредством компонента запросы-уведомления определителя субъектного получателя МПС.

АП должен автоматически подтверждать каждое такое сообщение в соответствии с нижеизложенным.

18.5.2.1 Создание УП

АП должен создавать УП.

УП должно иметь следующие общие поля:

а) субъектное МПС - поле заголовка МПС "данное МПС".

б) отправитель МПС - наличие или отсутствие - локальный вопрос (разумеется, в соответствии с 8.1.2).

в) предпочтительный получатель МПС - компонент "получатель" определителя субъектного получателя МПС, если только его компонент формальное-имя не является именем О/П пользователя АП, в случае чего это поле должно быть опущено.

г) преобразованные ТКИ - компонент преобразованные-типы-кодированной-информации аргумента "конверт" доставки сообщения.

УП должен иметь следующие поля приема:

а) время-приема - текущие дата и время;

б) режим-подтверждения - автоматическое значение;

в) дополнительная информация о приеме - переменная автоподтверждение-дополнительной-информации-о-приеме.

18.5.2.2 Предоставление УП

АП должен предоставлять УП путем привлечения операции "предоставление сообщения" со следующими аргументами:

а) конверт - компоненты этого аргумента должны соответствовать предписанным рабочим характеристикам абстрактной операции "отправка УП", за исключением следующего:

I) Приоритет - определяется аргументом "конверт" доставки сообщения.

II) Указатели-на-сообщение - локальный вопрос, за исключением того, что среди специфицированных значений должно быть значение "преобразование запрещено".

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

б) содержимое - определяется из УП в соответствии с 20.1.

18.5.3 Автопродвижение

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

АП должен автоматически продвигать каждое такое сообщение в соответствии с нижеизложенным.

18.5.3.1 Предотвращение циклов

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

АП должен создавать продвигаемое МПС (у которого поле заголовка автопродвижения имеет значение истинно) только в том случае, если компонент имя-получателя компонента "параметры МПС" соответствует имени О/П пользователя АП.

Примечание - Описанное выше автопродвижение МПС такого рода может образовать "цикл" автопродвижения.

18.5.3.2 Формирование МПС

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

Эта часть тела сообщения должна иметь следующие компоненты:

а) параметры - аргумент "конверт" доставки сообщения;

б) данные - МПС, подлежащее автопродвижению.

18.5.3.3 Предоставление МПС

АП должен предоставить сформированное им МПС до привлечения операции предоставления сообщения со следующими аргументами:

а) конверт - этот аргумент должен иметь следующие компоненты:

I) имя-отправителя - имя О/П пользователя АП;

II) тип-содержимого и исходные-типы-кодированной-информации - определяются из МПС в соответствии с 20.2 и 20.4;

III) идентификатор-содержимого - его спецификация или отсутствие решается на уровне локального вопроса;

IV) приоритет - определяется аргументом "конверт" доставки сообщения;

V) указатели-на-сообщение и расширения - локальный вопрос;

VI) время-доставки-сообщения - отсутствует;

VII) поля-на-получателя - их компоненты имя-получателя должны быть именами О/П, образующими переменную получатели-автопродвижения; наличие других компонентов - локальный вопрос;

б) содержимое - определяется из МПС в соответствии с 20.1.

18.5.3.4 Формирование УНП

АП должен формировать УНП только в том случае, если оно запрошено компонентом запросы-уведомления определителя получателя субъекта продвигаемого МПС.

УНП должно иметь общие поля, предписанные для параметров автопродвижения.

УНП должно иметь следующие поля приема:

а) причина-неприема - значение автопродвигаемого МПС;

б) причина-аннулирования - отсутствует;

в) комментарий-автопродвижения - переменная автопродвижения;

г) возвращенное-МПС - если возврат МПС запрошен компонентом запросы-уведомления его определителя получателя субъекта, а компонент преобразованные-типы-кодированной-информации отсутствует - это МПС. В противном случае это поле отсутствует.

18.5.3.5 Предоставление УНП

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

19 ОПЕРАЦИИ ХРАНИЛИЩА СООБЩЕНИЙ


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

19.1 Создание информационных объектов

ХС СМПС должно удовлетворять следующим требованиям относительно обслуживаемых ею информационных объектов:

а) ХС должно обслуживать отдельный информационный объект для каждого МПС (сообщения, содержащего МПС) либо доставляемого ей МПУ;

б) ХС должно обслуживать в виде отдельного информационного объекта не только каждое продвигающее МПС (сообщение, содержащее МПС, относящееся к подпункту а), но и каждое продвигаемое МПС (сообщение, содержащееся в МПС) (рекурсивным образом);

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

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

19.2 Обслуживание атрибутов

ХС СМПС должно удовлетворять следующим требованиям относительно атрибутов ХС:

а) для каждого хранимого МПС или МПУ ХС должно обеспечивать атрибуты, определенные в приложении А;

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

I) новое - никакие значения атрибутов не передаются к АП;

II) перечисленное - по меньшей мере, значение одного атрибута передано к АП и, по меньшей мере, одна часть тела не передана;

III) обработано - все части тела переданы АП;

в) для каждого хранимого МПУ ХС должно обеспечить следующий смысл атрибута состояние-ХС:

I) новое - никакие значения атрибутов не передаются АП;

II) перечисленное - по меньшей мере, значение одного атрибута передано АП и, по меньшей мере, один атрибут, кроме "возвращенное МПУ", не передан;

III) обработано - все атрибуты, кроме, возможно, возвращенного МПС, переданы АП;

г) атрибут состояние-ХС должен отражать текущее состояние до привлечения абстрактной операции, которая изменяет его значение;

д) атрибут тип-содержимого каждого МПС (сообщения, содержащего МПС) или МПУ, доставленного в ХС, должен иметь значение ид-тес-р2-1984 или ид-тес-р2-1988 (см. приложение D) в зависимости от типа содержимого доставленного сообщения (см. 20.2).

19.3 Уведомление о неприеме

При аннулировании МПС в процессе выполнения абстрактной операции "аннулирование" абстрактной услуги ХС хранилище сообщений должно предоставить УНП в случае, если оно запрошено и атрибут МПС "состояние-ХС" имеет значение перечислено.

19.4 Автопродвижение

ХС СМПС должно выполнять действие автопродвижение в соответствии с 18.5.3 ГОСТ Р ИСО/МЭК 10021-5. Оно использует компонент другие-параметры аргумента регистрация-автопродвижения абстрактной операции "регистрация ХС" абстрактной услуги ХС. Тип данных компонента другие-параметры определяется следующим образом:

Forwardedlnfo : : = SET {

auto-forwarding-comment [0] AutoForwardComment OPTIONAL,

cover-note [1] IA5TextBodyPart OPTIONAL,

this-ipm-prefix [2] PrintableString (SIZE

(1 ..ub-iрm-identifier-suffix)) OPTIONAL)


Кроме того, ХС должно удовлетворять следующим требованиям:

а) предоставлять УНП, даже если оно хранит копию продвигаемого МПС;

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

в) извлекать покрывающие-записи (при их наличии) для включения в продвигаемое МПС из компонента другие-параметры;

г) формировать префикс к компоненту идентификатор-соответствующего-пользователя данного поля МПС заголовка продвигаемого МПС в форме префикс-данного-мпс (при его наличии).

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

19.5 Ручное продвижение

СМПС должна обеспечивать ручное автопродвижение сообщения, используя расширение запроса-продвижения в соответствии с 6.6 ГОСТ Р ИСО/МЭК 10021-5. Пользователь ХС СМПС может предоставлять МПС, включая заголовок и тело сообщения с использованием операции предоставления сообщения, и осуществлять идентификацию, используя расширение запроса-продвижения для сообщения, которое уже содержится в ХС и которое подлежит объединению с телом предоставленного сообщения для продвижения к получателю сообщения. После этого тело предоставленного сообщения и продвигаемое сообщение объединяются путем включения продвигаемого сообщения в виде части тела сообщения в тело предоставленного сообщения.

20 СОДЕРЖИМОЕ СООБЩЕНИЯ


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

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

Примечание - Обозначение "Р2" отражает тот исторический факт, что это был второй по счету разработанный протокол обработки сообщений.

20.1 Содержимое

Вторичный объект, который предоставляет сообщение, содержащее МПС или МПУ, должен обеспечивать в виде октетов строки октетов, образующей содержимое сообщения, результат кодирования ИнформационногоОбъекта, рассмотренного во второй главе, в соответствии с базовыми правилами кодирования по ГОСТ 34.974.

20.2 Тип содержимого

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

Если МПС или МПУ удовлетворяют всем перечисленным ниже ограничениям, целое число 2 должно определять следующее:

I) В заголовке (МПС) отсутствует поле расширения.

II) В теле (МПС) отсутствуют внешне определяемые части тела.

III) В элементе параметров любой части тела видеотекса (МПС) отсутствует синтаксический член.

IV) Каждый компонент МПС или МПУ, который является значением типа данных, определенного в виде части абстрактной услуги МПС, удовлетворяет ограничениям Рекомендации Х.411 (1984) МККТТ.

Рассматриваемые типы - это те типы, которые перечислены в разделе IMPORTS модуля АСН.1, определенного в приложении Е. Рассматриваемые ограничения подробно рассмотрены в приложении ГОСТ Р ИСО/МЭК 10021-6.

V) Элемент данных любой части тела сообщения (МПС) удовлетворяет тем же ограничениям (рекурсивно).

В противном случае должно быть определено целое число 22.

Примечания

1 Протокол содержимого сообщения (рассматриваемый здесь), обозначенный целым числом 2, идентичен протоколу, определенному рекомендацией Х.420 (1984) МККТТ (поясняемому версией 6 Руководства разработчика серии Х.400), за исключением того, что тип части тела "простой форматируемый документ", определенный во втором, отсутствует в первом.

2 Целое число 2 предпочтительнее относительно числа 22 с точки зрения ускорения взаимодействия между системами, соответствующими настоящему стандарту, и системами, соответствующими (только) рекомендации Х.420 (1984) МККТТ.

3 СПС не осуществляет преобразований протоколов содержимого сообщений. Тем самым она не выполняет преобразования между Р2, определяемым только настоящим стандартом (и обозначаемым целым числом 22), и Р2, определяемым как настоящим стандартом, так и рекомендацией Х.420 (1984) МККТТ (и обозначаемым целым числом 2).

20.3 Длина содержимого

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

20.4 Типы кодированной информации

Вторичный объект, который предоставляет сообщения, содержащие МПС или МПУ, должен определять базовые типы кодированной информации (ТКИ) и не-базовые параметры (НБП) сообщения следующим образом.

В случае МПУ базовые ТКИ должны быть неспецифицированными.

В случае МПС базовые ТКИ и НБП должны определяться в соответствии со следующими правилами:

а) многочастевые тела - базовые ТКИ (при их наличии) и НБП (при их наличии) сообщения должны охватывать логическое объединение базовых ТКИ и НБП отдельных частей тела МПС соответственно;

б) часть тела сообщения (продвигаемая) - базовые ТКИ (при их наличии) и НБП (при их наличии) части тела сообщения должны быть базовыми ТКИ и НБП продвигаемого сообщения;

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

Любая другая расширенная часть тела должна обрабатываться следующим образом. При наличии соответствия типу одного или нескольких внешне определенных ТКИ они должны быть определены. В противном случае должен указываться неопределенный ТКИ. В любом случае НБП должны быть определены;

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

д) зашифрованная часть тела - влияние зашифрованной части тела на базовые ТКИ и НБП должно быть определено в процессе дальнейшего изучения.


Таблица 2 - Базовые ТКИ и НБП межперсональных сообщений

Тип части тела

Базовый ТКИ

НБП

Текст МК5

Текст МК5

-

Речь

Речь

-

Факсимиле Г3

Факсимиле Г3

Факсимиле Г3

Г4 класс 1

Г4 класс 1

Г4 класс 1/смешанный режим

Телетекс

Телетекс

Телетекс

Видеотекс

Видеотекс

-

Зашифрованное сообщение

(См. текст)

(См. текст)

Смешанный режим

Смешанный режим

Г4 класс 1/смешанный режим

Двусторонне определяемый

Не определено

-

Национально определяемый

Не определено

-

Внешне определяемый

(См. текст)

(См. текст)

21 РЕАЛИЗАЦИЯ ПОРТОВ


Способ, которым ХС или СПС конкретно реализует обеспечиваемые ими вторичные порты, определен в ГОСТ Р ИСО/МЭК 10021-6.

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

Примечания

1 Интерфейс пользователя АП относится к локальному вопросу. Возможен широкий набор используемых интерфейсов, например, широкий набор устройств ввода-вывода.

2 Способ, которым АТЛМ реализует свои первичные порты, определен в Рекомендации Т.330 МККТТ.

3 МД обеспечивает свои первичные порты с помощью конкретной системы связи, к которой этот МД обеспечивает доступ.

22 СООТВЕТСТВИЕ


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

22.1 Отправка в сравнении с приемом

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

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

Примечание - Фактически МДФД не выполняет никаких операций при отправке, поскольку он не является поставщиком порта отправки.

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

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

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

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

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

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

АП СМПС, ХС СМПС, АТЛМ или МД должны удовлетворять следующим статическим требованиям:

а) АП СМПС, ХС СМПС, АТЛМ или МД должны реализовывать поля заголовка и расширения заголовка, а также типы базовых и расширенных частей тела, соответствие которым он заявляет;

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

в) АП СМПС, ХС СМПС, АТЛМ или АП должны конкретно реализовывать свои абстрактные порты в соответствии с разделом 21.

г) АП СМПС или ХС СМПС должны быть способны предоставлять и воспринимать доставку сообщений обоих типов содержимого, рассмотренных в 20.2. АТЛМ или АП должен обеспечивать как импорт, так и экспорт таких сообщений.

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

АП СМПС, ХС СМПС, АТЛМ или МД должны удовлетворять следующим динамическим требованиям:

а) АП СМПС или ХС СМПС должны удовлетворять правилам операций, определяемым в разделах 18 и 19 соответственно;

б) АП СМПС, ХС СМПС, АТЛМ или МД должны предоставлять и воспринимать доставку сообщений, содержимое которых соответствует определенному в разделе 20;

в) АП СМПС, ХС СМПС, АТЛМ или МД должны регистрировать в СПС свои возможности воспринимать доставку сообщений с обоими типами содержимого, определенными в 20.2.

ПРИЛОЖЕНИЕ А (обязательное). РАСШИРЕНИЯ ЗАГОЛОВКА

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


Данное приложение определяет все (определенные к настоящему времени) расширения заголовка.

А.1 Некомплектная копия

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

Incomplete-copy HEADING-EXTENSION

: : = id-hex-incomplete-copy


Если это расширение отсутствует в поле заголовка расширения, следует считать, что все части тела присутствуют.

А.2 Языки

Расширение заголовка языки идентифицирует языки, используемые в сочетании поля и тела заголовка объекта МПС. Это расширение состоит из набора (от нуля до нескольких) распечатываемых строк, каждая из которых составлена двузначным языковым кодом, определенным в ИСО 639.

languages HEADING-EXTENSION

VALUE SET OF Language

: : = id-hеx-languages


Language : : = PrintableString (SIZE (2 . . 2))

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

ПРИЛОЖЕНИЕ В (обязательное). РАСШИРЕННЫЕ ТИПЫ ЧАСТИ ТЕЛА

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


Данное приложение определяет ряд расширенных типов части тела. Некоторые являются эквивалентными по отношению к типам базовой части тела.

B.1 Эквиваленты типов базовой части тела

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

ia5-text-body-part EXTENDED-BODY-PART-TYPE

PARAMETERS IA5TextParameters IDENTIFIED BY id-ep-ia5-text

DATA

IA5TextData

: : = id-et-ia5-text


voice-body-part EXTENDED-BODY-PART-TYPE

PARAMETERS VoiceParameters IDENTIFIED BY id-ep-voice

DATA

VoicеData

: : = id-et-voice


g3-facsimile-body-part EXTENDED-BODY-PART-TYPE

PARAMETERS G3FacsimileParameters IDENTIFIED BY id-ep-g3-facsimile

DATA

G3FacsimileData

: : = id-et-g3-facsimile


g4-classl-body-part EXTENDED-BODY-PART-TYPE

DATA

G4Class1BodyPart

: : = id-et-g4-class1


teletex-body-part EXTENDED-BODY-PART-TYPE

PARAMETERS TeletexParameters IDENTIFIED BY id-ep-teletex

DATA

TeletexData

: : = id-et-teletex


videotex-body-part EXTENDED-BODY-PART-TYPE

PARAMETERS VideotexParameters IDENTIFIED BY id-ep-videotex

DATA

VideotexData

: : = id-et-videotex


encrypted-body-part EXTENDED-BODY-PART-TYPE

PARAMETERS EncryptedParameters IDENTIFIED BY id-ep-encrypted

DATA

Encrypted Data

: : = id-et-encrypted


message-body-part EXTENDED-BODY-PART-TYPE

PARAMETERS MessageParameters IDENTIFIED BY id-ep-message

DATA

MеssageData

: : = id-et-mеssage


mixed-mode-body-part EXTENDED-BODY-PART-TYPE

DATA

MixedModeBodyPart

: : = id-et-mixed-mode


bilaterally-defined-body-part EXTENDED-BODY-PART-TYPE

DATA

BilaterallyDefinedBodyPart

: : = id-et-bilaterally-defined


nationally-defined-body-part EXTENDED-BODY-PART-TYPE

DATA

NationallyDefinedBodyPart

: : = id-et-nationally-defined


B.2 Общий текст

Общий текст, расширяющий часть тела, представляет собой символический текст общего характера. Он включает компонент "параметры" и компонент "данные".

general-tеxt-body-part EXTENDED-BODY-PART-TYPE

PARAMETERS GеneralTеxtParamеters IDENTIFIED BY id-ep-general-text

DATA

GeneralTextData


: : = id-еt-general-text

GeneralTextParameters : : = SET {

g0-designator

[0]

CharacterSetDesignator

OPTIONAL,

g1-designator

[1]

CharacterSetDesignator

OPTIONAL,

g2-designator

[2]

CharacterSetDesignator

OPTIONAL,

g3-designator

[3]

CharacterSetDesignator

OPTIONAL,

c0-designator

[4]

CharacterSetDesignator

OPTIONAL,

с1-designator

[5]

CharacterSetDesignator

OPTIONAL}


GeneralTextDate : : = GeneralString

Компонент "параметры" содержит обозначения наборов G0, G1, G2, G3, С0 и С1, которые могут присутствовать в компоненте "данные". Каждое обозначение набора символов представлено управляющей последовательностью, определенной в записи этого набора символов, зарегистрированного согласно ИСО 2375.

При отсутствии обозначений G0 и С0 предполагается использование наборов символов, зарегистрированных с регистрационными номерами 2 и 1 соответственно. Отсутствие других обозначений предполагает, что соответствующий набор не определен.

CharactеrSetDesignator : : = GeneralString (SIZE (3 . . 5))

Компонент "данные" содержит одну общую строку. Не должны использоваться наборы G и С, кроме тех, которые определены в компоненте "параметры".

Каждая общая строка должна кодироваться с использованием 8-битового кодирования (7-битовое не используется).

Строка в пределах компонента "данных" может иметь любую длину. Когда же компонент отображается (например, выводится на экран или печатается для пользователя), должно быть передано все (предпочтительнее, чем только часть) содержимое текста (например, строки могут быть свернуты, но не должны быть укорочены).

Для расширения типа части тела внешне определяемый ТКИ определяется (см. 20.4 подпункт в) следующим образом. Один ТКИ, определяемый для каждого набора G или С компонента "параметры", идентифицируется явно или неявно. Он помечается объектным идентификатором, приписанным к этому набору символов.

Данное приложение определяет порядок регистрации полномочий для объектного идентификатора следующим образом. Все объектные идентификаторы определяются в качестве непосредственного разрешения под одной общей вершиной, представляющей регистрацию полномочий (id-cs-eit-authority). Компонент объектный идентификатор, идентифицирующий набор символов, представляемый в виде листа (вершиной дерева, не имеющей дочерних вершин), является регистрационным номером этого набора символов, присвоенного в соответствии с ИСО 2375.

Пример - Внешне определяемыми ТКИ для латинского алфавита номер 1 (ИСО 8859-1) являются {id-cs-eit-authority 6} для набора G0 и {id-cs-eit-authority 100} для набора G1.

Примечания

1 По умолчанию для обозначения наборов символов G0 и С0 используются те же средства, которые предусмотрены базовыми правилами кодирования АСН.1 (ГОСТ 34.974) для общей строки.

2 Базовые правила кодирования предусматривают, чтобы управляющие последовательности для обозначения наборов символов G1, G2, G3 и С1 были подобны используемым в рамках кодирования общей строки. Наборы G в таком случае вызываются с использованием управляющих функций блокировки или одиночного сдвига.

ПРИЛОЖЕНИЕ С (обязательное). АТРИБУТЫ ХРАНИЛИЩА СООБЩЕНИЙ

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


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

В данном приложении определяются атрибуты ХС, специфичные для межперсональных сообщений.

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


Таблица C.1 - Сводный перечень атрибутов ХС

Атрибут

Н

З

СО

МПС

УНП

УП

СП

СМ

Режим подтверждения

О

Ф

-

-

О

Да

Нет

Полномочные пользователи

М

Ф

У

-

-

Да

Нет

Комментарий автопродвижения

О

Ф

-

У

-

Да

Нет

Автопродвижение

О

Ф

У

-

-

Да

Да

Двусторонне определяемые части тела

М

Ф

У

-

-

Нет

Нет

Получатели слепой копии

М

Ф

У

-

-

Да

Нет

Тело

О

О

О

-

-

Нет

Нет

Преобразованные ТКИ

М

Ф

-

У

У

Да

Нет

Получатели копии

М

Ф

У

-

-

Да

Нет

Причина аннулирования

О

Ф

-

У

-

Да

Да

Зашифрованные части тела

М

Ф

У

-

-

Нет

Нет

Зашифрованные данные

М

Ф

У

-

-

Нет

Нет

Зашифрованные параметры

М

Ф

У

-

-

Нет

Нет

Истекшее время

О

Ф

У

-

-

Да

Нет

Типы расширенной части тела

М

Ф

У

-

-

Да

Да

Части тела факсимиле Г3

М

Ф

У

-

-

Нет

Нет

Данные факсимиле Г3

М

Ф

У

-

-

Нет

Нет

Параметры факсимиле Г3

М

Ф

У

-

-

Нет

Нет

Части тела Г4 класс 1

М

Ф

У

-

-

Нет

Нет

Заголовок

О

О

О

-

-

Нет

Нет

Части тела текст МК5

М

Ф

У

-

-

Нет

Нет

Данные текст МК5

М

Ф

У

-

-

Нет

Нет

Параметры

М

Ф

У

-

-

Нет

Нет

Важность

О

Ф

У

-

-

Да

Да

Некомплектная копия

О

Ф

У

-

-

Да

Нет

Тип элемента МПС

О

О

О

О

О

Да

Да

Предпочтительный получатель МПС

О

Ф

-

У

У

Да

Нет

Конспект МПС

О

Ф

О

-

-

Нет

Нет

Отправитель МПС

О

Ф

-

У

У

Да

Нет

Языки

М

Ф

У

-

-

Да

Нет

Части тела сообщения

М

Ф

У

-

-

Нет

Нет

Данные сообщения

М

Ф

У

-

-

Нет

Нет

Параметры сообщения

М

Ф

У

-

-

Нет

Нет

Части тела смешанного режима

М

Ф

У

-

-

Нет

Нет

Национально определяемые части тела

М

Ф

У

-

-

Нет

Нет

Причина неприема

О

Ф

-

О

-

Да

Да

Запросчики УНП

М

Ф

У

-

-

Да

Нет

Устарелые МПС

М

Ф

У

-

-

Да

Нет

Отправитель

О

Ф

У

-

-

Да

Нет

Основные получатели

М

Ф

У

-

-

Да

Нет

Время приема

О

Ф

-

-

О

Да

Нет

Родственные МПС

М

Ф

У

-

-

Да

Нет

Ответ-на-МПС

О

Ф

У

-

-

Да

Нет

Получатели ответа

М

Ф

У

-

-

Да

Нет

Запросчики ответа

М

Ф

У

-

-

Да

Нет

Время ответа

О

Ф

У

-

-

Да

Нет

Возвращенное МПС

О

Ф

-

У

-

Да

Нет

Запросчики УП

М

Ф

У

-

-

Да

Нет

Чувствительность

О

Ф

У

-

-

Да

Да

Субъект

О

Ф

У

-

-

Да

Нет

Субъектное МПС

О

О

-

О

О

Да

Нет

Дополнительная информация о приеме

О

Ф

-

-

У

Да

Нет

Части тела телетекса

М

Ф

У

-

-

Нет

Нет

Данные телетекса

М

Ф

У

-

-

Нет

Нет

Параметры телетекса

М

Ф

У

-

-

Нет

Нет

Данное МПС

О

О

О

-

-

Да

Нет

Части тела видеотекс

М

Ф

У

-

-

Нет

Нет

Параметры видеотекса

М

Ф

У

-

-

Нет

Нет

Части тела речь

М

Ф

У

-

-

Нет

Нет

Данные речи

М

Ф

У

-

-

Нет

Нет

Параметры речи

М

Ф

У

-

-

Нет

Нет

Обозначения:

З - одно/многозначное;

СО - степень обязательности для ХС и доступа к АП;

Н - наличие в элементе доставленного сообщения;

СП - доступен для списка, предупреждений;

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



C.1 Суммарные атрибуты

Некоторые атрибуты содержат суммарный перечень информационных объектов межперсональных сообщений. Эти атрибуты определены и описаны ниже.

C.1.1 Тип элемента МПС

Атрибут тип элемента МПС идентифицирует тип информационного объекта.

ipm-empty-type ATTRIBUTE

WITH ATTRIBUTE-SYNTAX IPMEntryType

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-sat-ipm-entry-type


IPMEntryType : : = ENUMERATED {

ipm

(0),

rn

(1),

nrn

(2)


Тип элемента МПС может принимать одно из следующих значений:

а) мпс - информационным объектом является МПС;

б) уп - информационным объектом является УП;

в) унп - информационным объектом является УНП.

ХС, обеспечивающее эти атрибуты, должно поддерживать их для хранимого у себя информационного объекта только в том случае, если этот объект является сообщением, содержимым которого является МПС или МПУ.

С.1.2 Конспект МПС

Атрибут конспект МПС обеспечивает структуру, характеристики, размер и статус обработки МПС на уровне отдельных частей тела.

ipm-synopsis ATTRIBUTE

WITH ATTRIBUTE-SYNTAX IPMSynopsis

SINGLE VALUE

: : = id-sat-ipm-synopsis


Конспект МПС содержит конспект каждой из его частей тела. Эти конспекты введены в той последовательности, в которой представлены части тела.

IPMSynopsis : : = SEQUENCE OF BodyPartSynopsis

Конспект части тела принимает одну из двух форм в зависимости от того, является ли эта часть тела сообщением данного типа. Это позволяет охватить конспектом продвигаемого МПС части тела каждого продвинутого СПС (рекурсивно), а также части тела самого продвигаемого СПС.

BodyPartSynopsis : : = CHOICE {

message

[0] MessageBodyPartSynopsis,

non-message

[1] NonMessageBodyPartSynopsis}


MessfgeBodyPartSynopsis : : = SEQUENCE {

number

[0] SequenceNumber,

synopsis

[1] IPMSynopsis}


NonMessageBodyPartSynopsis : : = SEQUENCE {

type

[0] OBJECT IDENTIFIER,

parameters

[1] ExternallyDefinedParameters,

size

[2] INTEGER,

processed

[3] BOOLEAN DEFAULT FALSE}


Конспект части тела сообщения имеет следующие компоненты:

а) номер (О) - порядковый номер, который ХС назначило элементу, представляющему данную часть тела сообщения;

б) конспект (О) - конспект МПС, формирующий содержимое сообщения, которое представляет данная часть тела.

Конспект части тела, тип которого отличается от типа сообщения, имеет следующие компоненты (считается, что при таком конспекте данная часть тела должна относиться к внешне определяемому типу независимо от того, передается она в таком виде в ХС или нет; см. приложение В):

а) тип (О) - часть тела расширенного типа, т.е. компонент "непосредственная-ссылка" компонента "данные" части тела.

б) параметры (О) - формат и параметры управления части тела, т.е. компонент "параметры" части тела. Любое значение.

в) размер (О) - длина в октетах кода компонента "код" компонента "данные" части тела при соблюдении базовых правил кодирования ГОСТ 34.974. Если эти правила допускают несколько кодов компонента (например, элементарный и сложный), размер может отражать любой из них. Целое число.

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

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

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

С.2 Атрибуты заголовка

Некоторые атрибуты образуются из заголовка МПС. Эти атрибуты определены и описаны ниже.

С.2.1 Заголовок

Атрибут заголовок является заголовком (полным) МПС.

heading ATTRIBUTE

WITH ATTRIBUTE-SYNTAX Heading

SINGLE VALUE

: : = id-hat-hеading


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

С.2.2 Анализ заголовка

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

rn-requestors ATTRIBUTE

WITH ATTRIBUTE-SYNTAX ORDescriptor

MATCHES FOR EQUALITY

MULTY VALUE

: : = id-hat-rn-requestors


nrn-requestors ATTRIBUTE

WITH ATTRIBUTE-SYNTAX ORDescriptor

MATCHES FOR EQUALITY

MULTY VALUE

: : = id-hat-nrn-requestors


reply-requestors ATTRIBUTE

WITH ATTRIBUTE-SYNTAX ORDescriptor

MATCHES FOR EQUALITY

MULTY VALUE

: : = id-hat-reply-requestors


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

С.2.3 Поля заголовка

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

this-ipm ATTRIBUTE

WITH ATTRIBUTE-SYNTAX ThisIPMField

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-hat-this-ipm

originator ATTRIBUTE

WITH ATTRIBUTE-SYNTAX OriginatorField

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-hat-originator


replied-to-IPM ATTRIBUTE

WITH ATTRIBUTE-SYNTAX RepliedToIPMField

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-hat-replied-to-IPM


subject ATTRIBUTE

WITH ATTRIBUTE-SYNTAX SubjectField

MATCHES FOR EQUALITY SUBSTRINGS

SINGLE VALUE

: : = id-hat-subject


expiry-time ATTRIBUTE

WITH ATTRIBUTE-SYNTAX ExpiryTimeField

MATCHES FOR EQUALITY ORDERING

SINGLE VALUE

: : = id-hat-expiry-time


reply-time ATTRIBUTE

WITH ATTRIBUTE-SYNTAX ReplyTimeField

MATCHES FOR EQUALITY ORDERING

SINGLE VALUE

: : = id-hat-reply-time


importance ATTRIBUTE

WITH ATTRIBUTE-SYNTAX Importance Field

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-hat-importance


sensitivity ATTRIBUTE

WITH ATTRIBUTE-SYNTAX SensitivityField

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-hat-sensitivity


auto-forwarded ATTRIBUTE

WITH ATTRIBUTE-SYNTAX AutoForwardedField

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-hat-auto-forwarded


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

С.2.4 Подполя заголовка

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

authorizing-users ATTRIBUTE

WITH ATTRIBUTE-SYNTAX AuthorizingUsersSubField

MATCHES FOR EQUALITY

MULTY VALUE

: : = id-hat-authorizing-users


primary-recipients ATTRIBUTE

WITH ATTRIBUTE-SYNTAX PrimaryRecipientsSubField

MATCHES FOR EQUALITY

MULTY VALUE

: : = id-hat-primary-recipients


copy-recipients ATTRIBUTE

WITH ATTRIBUTE-SYNTAX CopyRecipientsSubField

MATCHES FOR EQUALITY

MULTY VALUE

: : = id-hat-copy-recipients


bling-copy-recipients ATTRIBUTE

WITH ATTRIBUTE-SYNTAX BlindCopyRecipientsSubField

MATCHES FOR EQUALITY

MULTY VALUE

: : = id-hat-blind-copy-recipients


obsolеtеd-IPMs ATTRIBUTE

WITH ATTRIBUTE-SYNTAX ObsoletedIPMsSubField

MATCHES FOR EQUALITY

MULTY VALUE

: : = id-hat-obsoleted-IPMs


relatеd-IPMs ATTRIBUTE

WITH ATTRIBUTE-SYNTAX RelatedIPMsSubField

MATCHES FOR EQUALITY

MULTY VALUE

: : = id-hat-related-IPMs


reply-recipients ATTRIBUTE

WITH ATTRIBUTE-SYNTAX ReplyRecipientsSubField

MATCHES FOR EQUALITY

MULTY VALUE

: : = id-hat-reply-recipients


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

С.2.5 Расширение заголовка

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

incomplete-copy ATTRIBUTE

WTTH ATTRIBUTE-SYNTAX IncompleteCopyExtensionValue

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-hat-incomplete-copy


languages ATTRIBUTE

WITH ATTRIBUTE-SYNTAX Language

MATCHES FOR EQUALITY

MULTY VALUE

: : = id-hat-languages


XC, обеспечивающее один из этих атрибутов, должно поддерживать его для хранимого у себя информационного объекта только в том случае, если этот объект является сообщением, содержимым которого является МПС, чей заголовок содержит расширение, имя которого указывает этот атрибут. В случае атрибута "язык" XC должно обеспечивать по одному значению атрибута для каждого языка, который идентифицирует расширение.

С.3 Атрибуты тела

Некоторые атрибуты образуются из тела МПС. Эти атрибуты определены и описаны ниже.

С.3.1 Тело

Атрибут тело является телом (целым) МПС.

body ATTRIBUTE

WITH ATTRIBUTE-SYNTAX Body

SINGLE VALUE

: : = id-bat-body


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

С.3.2 Базовые части тела

Некоторые атрибуты содержат имена базовых типов частей тела и за единственным исключением используют такие части тела в качестве их значений.

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

ia5-text-body-parts ATTRIBUTE

WITH ATTRIBUTE-SYNTAX IA5TextBodyPart

MULTY VALUE

: : = id-bat-ia5-text-body-parts


voice-body-parts ATTRIBUTE

WITH ATTRIBUTE-SYNTAX VoiceBodyPart

MULTY VALUE

: : = id-bat-voice-body-parts


g3-facsimile-body-parts ATTRIBUTE

WITH ATTRIBUTE-SYNTAX G3FacsimileBodyPart

MULTY VALUE

: : = id-bat-g3-facsimile-body-parts


g4-class1-body-parts ATTRIBUTE

WITH ATTRIBUTE-SYNTAX G4Class1BodyPart

MULTY VALUE

: : = id-bat-g4-class1-body-parts


teletex-body-parts ATTRIBUTE

WITH ATTRIBUTE-SYNTAX TeletexBodyPart

MULTY VALUE

: : = id-bat-teletex-body-parts


videotex-body-parts ATTRIBUTE

WITH ATTRIBUTE-SYNTAX VideotexBodyPart

MULTY VALUE

: : = id-bat-videotex-body-parts


encrypted-body-parts ATTRIBUTE

WITH ATTRIBUTE-SYNTAX EncryptedBodyPart

MULTY VALUE

: : = id-bat-encrypted-body-parts


message-body-parts ATTRIBUTE

WITH ATTRIBUTE-SYNTAX SequenceNumber

MULTY VALUE

: : = id-bat-message-body-parts


mixed-mode-body-parts ATTRIBUTE

WITH ATTRIBUTE-SYNTAX MixedModeBodyPart

MULTY VALUE

: : = id-bat-mixed-mode-body-parts


bilaterally-defined-body-parts ATTRIBUTE

WITH ATTRIBUTE-SYNTAX BilateriallyDefinedBodyPart

MULTY VALUE

: : = id-bat-bilaterally-defined-body-parts


nationally-defined-body-parts ATTRIBUTE

WITH ATTRIBUTE-SYNTAX NationallyDefinedBodyPart

MULTY VALUE

: : = id-bat-nationally-defined-body-parts


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

С.3.3 Компоненты параметров основной части тела

Некоторые атрибуты имеют имена типов базовой части тела и используют компоненты "параметры" таких частей тела в качестве своих значений.

ia5-tеxt-parameters ATTRIBUTE

WITH ATTRIBUTE-SYNTAX lA5TextParameters

MULTY VALUE

: : = id-bat-ia5-text-parameters


voice-parameters ATTRIBUTE

WITH ATTRIBUTE-SYNTAX VoiceParameters

MULTY VALUE

: : = id-bat-voice-parameters


g3-facsimile-parameters ATTRIBUTE

WITH ATTRIBUTE-SYNTAX G3FacsimiIeParameters

MULTY VALUE

: : = id-bat-g3-facsimilе-parameters


teletеx-parametеrs ATTRIBUTE

WITH ATTRIBUTE-SYNTAX TeletexParameters

MULTY VALUE

: : = id-bat-tеlеtex-parameters


videotex-parameters ATTRIBUTE

WITH ATTRIBUTE-SYNTAX VideotexParameters

MULTY VALUE

: : = id-bat-vidеotеx-paramеtеrs


message-parameters ATTRIBUTE

WITH ATTRIBUTE-SYNTAX MessageParameters

MULTY VALUE

: : = id-bat-mеssage-parameters


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

С.3.4 Компоненты "данные" базовой части тела

Некоторые атрибуты имеют имена типов базовой части тела и используют компоненты "данные" таких частей тела в качестве своих значений.

ia5-text-data ATTRIBUTE

WITH ATTRIBUTE-SYNTAX IA5TextData

MULTY VALUE

: : = id-bat-ia5-text-data


voice-data ATTRIBUTE

WITH ATTRIBUTE-SYNTAX VoiceData

MULTY VALUE

: : = id-bat-voicе-data


g3-facsimile-data ATTRIBUTE

WITH ATTRIBUTE-SYNTAX G3FacsimiIeData

MULTY VALUE

: : = id-bat-g3-facsimilе-data


teletex-data ATTRIBUTE

WITH ATTRIBUTE-SYNTAX TeletexData

MULTY VALUE

: : = id-bat-tеletex-data


videotex-data ATTRIBUTE

WITH ATTRIBUTE-SYNTAX VideotexData

MULTY VALUE

: : = id-bat-videotеx-data


message-data ATTRIBUTE

WITH ATTRIBUTE-SYNTAX MessageData

MULTY VALUE

: : = id-bat-mеssage-data


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

С.3.5 Типы расширенной части тела

Атрибут "типы расширенной части тела" идентифицирует типы расширенной части тела, представленные в МПС.

extended-body-parts ATTRIBUTE

WITH ATTRIBUTE-SYNTAX OBJECT IDENTIFIER

MATCHES FOR EQUALITY

MULTY VALUE

: : = id-bat-extended-body-parts


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

Примечание - Каждое значение этого атрибута соответствует одному из атрибутов, описываемых в С.3.6.

С.3.6 Расширенные части тела

Некоторые атрибуты, непоименованные, имеют в качестве своих значений кодированные компоненты внешних элементов ACH.1 (см. 7.3.12), которые образуют компоненты данных внешне определяемых частей тела.

Каждому типу расширенной части тела соответствуют два атрибута. Первый атрибут обозначается объектным идентификатором, который является компонентом прямой-ссылки (см. 7.3.12) внешнего элемента, образующего компонент "данные" части тела этого типа. Содержимым этого первого типа является компонент "данные". Второй атрибут обозначен объектным идентификатором, т.е. компонентом прямой-ссылки внешнего элемента, образующего компонент "параметры" части тела этого типа. Содержимым этого второго атрибута является этот компонент "параметры".

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

Примечания

1 Атрибуты расширенной части тела практически невозможно пронумеровать, поскольку невозможно пронумеровать расширенные части тела.

2 Атрибут типов расширенной части тела (см. С.3.5) определяет атрибуты расширенной части тела для конкретного МПС.

С.4 Атрибуты уведомления

Некоторые атрибуты образуются из МПС. Эти атрибуты определены и описаны ниже.

С.4.1 Общие поля

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

subject-ipm ATTRIBUTE

WITH ATTRIBUTE-SYNTAX SubjectIPMFieId

MATCHES FOR EQUALITY SUBSTRINGS

SINGLE VALUE

: : = id-nat-subject-ipm


ipn-originator ATTRIBUTE

WITH ATTRIBUTE-SYNTAX IPNOriginatorField

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-nat-ipn-originator


ipn-preferred-recipients ATTRIBUTE

WITH ATTRIBUTE-SYNTAX IPNPreferredRecipientsField

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-nat-ipn-preferred-recipients


conversion-eits ATTRIBUTE

WITH ATTRIBUTE-SYNTAX MS-EITs

MATCHES FOR EQUALITY

MULTY VALUE

: : = id-nat-conversion-eits


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

С.4.2 Поля неприема

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

non-recеipt-reason ATTRIBUTE

WITH ATTRIBUTE-SYNTAX NonReceiptReasonField

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-nat-non-receipt-reason


discard-reason ATTRIBUTE

WITH ATTRIBUTE-SYNTAX DiscardReasonField

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-nat-discard-reason


auto-forward-comment ATTRIBUTE

WITH ATTRIBUTE-SYNTAX AutoForwardCommentField

MATCHES FOR EQUALITY SUBSTRING

SINGLE VALUE

auto-forward-comment ATTRIBUTE


returned-IPM ATTRIBUTE

WITH ATTRIBUTE-SYNTAX ReturnedField

SINGLE VALUE

: : = id-nat-returned-ipm


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

С.4.3 Поля приема

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

receipt-time ATTRIBUTE

WITH ATTRIBUTE-SYNTAX ReceiptTimeField

MATCHES FOR EQUALITY ORDERING

SINGLE VALUE

: : = id-nat-receipt-time


acknowledgment ATTRIBUTE

WITH ATTRIBUTE-SYNTAX AcknowledgmentModeField

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-nat-acknowledgment-mode


suppl-receipt-info ATTRIBUTE

WITH ATTRIBUTE-SYNTAX SupplReceiptInfoFieId

MATCHES FOR EQUALITY SUBSTRING

SINGLE VALUE

: : = id-nat-suppl-rеceipt-info


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

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

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


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

Все присвоения объектных идентификаторов настоящего стандарта приведены в данном приложении. Это приложение является определительным для всех модулей АСН.1 и самого применения СМПС. Определительные присвоения для АСН.1 содержатся в самих модулях; прочие ссылки на них содержатся в разделах IMPORT. Присвоение для СМПС является фиксированным.

IMPSObjectIdentifiers {joint-iso-ccitt

mhs-motis(6) ipms(1) modulеs(0) object-identifiers(0)}

DEFINITIONS IMPLICIT TAGS : : =

BEGIN

-- Пролог

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

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

ID : : = OBJECT IDENTIFIER

-- Межперсональные сообщения (не определительные)

id-ipms ID : : = { joint-iso-ccitt mhs-motis(6) ipms(1)} -- не определительное

-- Категории

id-mod

ID : : = {id-ipms 0}

- - модули; не определительное

id-ot

ID : : = {id-ipms1}

- - типы объектов

id-pt

ID : : = {id-ipms 2}

- - типы портов

id-ref

ID : : = {id-ipms 3}

- - уточнения

id-et

ID : : = {id-ipms 4}

- - типы расширенной части тела

id-hex

ID : : = {id-ipms 5}

- - расширения заголовка

id-sat

ID : : = {id-ipms 6}

- - суммарные атрибуты

id-hat

ID : : = {id-ipms 7}

- - атрибуты заголовка

id-bat

ID : : = {id-ipms 8}

- - атрибуты тела

id-nat

ID : : = {id-ipms 9}

- - атрибуты уведомления

id-mсt

ID : : = {id-ipms 10}

- - типы содержимого сообщения

id-ep

ID : : = {id-ipms 11}

- - параметры расширенной части тела

-- Модули

id-mod-object-identifiers

ID : : = {id-mod 0}

- - не определительный

id-mod-functional-objects

ID : : = {id-mod 1}

- - не определительный

id-mod-information-objects

ID : : = {id-mod 2}

- - не определительный

id-mod-abstract-sеrvice

ID : : = {id-mod 3}

- - не определительный

id-mod-heading-еxtеnsions

ID : : = {id-mod 6}

- - не определительный

id-mod-extended-body-part-types

ID : : = {id-mod 7}

- - не определительный

id-mod-messagе-store-attributes

ID : : = {id-mod 8}

- - не определительный

id-mod-upper-bounds

ID : : = {id-mod 10}

- - не определительный

-- Типы объектов

id-ot-ipme

ID : : = {id-ot 0}

id-ot-ipms-user

ID : : = {id-ot 1}

id-ot-ipms

ID : : = {id-ot 2}

id-ot-ipms-ua

ID : : = {id-ot 3}

id-ot-ipms-ms

ID : : = {id-ot 4}

id-ot-tlma

ID : : = {id-ot 5}

id-ot-tlxau

ID : : = {id-ot 6}

id-ot-pdau

ID : : = {id-ot 7}

-- Типы портов

id-pt-origination

ID : := {id-pt 0}

id-pt-reception

ID : : = {id-pt 1}

id-pt-managеment

ID : : = {id-pt 2}

-- Уточнения

id-ref-primary

ID : : = {id-rеf 0}

id-ref-secondary

ID : : = {id-ref 1}

-- Типы расширенной части телa

id-et-ia5-text

ID : : = {id-et 0}

id-et-voice

ID : : = {id-et 1}

id-et-g3-facsimile

ID : : = {id-et 2}

id-et-g4-class1

ID : : = {id-et 3}

id-et-teletex

ID : : = {id-et 4}

id-et-videotex

ID : : = {id-et 5}

id-et-encrypted

ID : : = {id-et 6}

id-et-message

ID : : = {id-et 7}

id-et-mixed-mode

ID : : = {id-et 8}

id-et-bilaterally-defined

ID : : = {id-et 9}

id-et-nationally-defined

ID : : = {id-et 10}

-- Расширения заголовка

id-hex-incomplete-copy

ID : : = {id-hex 0}

id-hex-languages

ID : : = {id-hex 1}

-- Суммарные атрибуты

id-sat-ipm-entry-type

ID : : = {id-sat 0}

id-sat-ipm-synopsis

ID : : = {id-sat 1}

-- Атрибуты заголовка

id-hat-heading

ID : : = {id-hat 0}

id-hat-this-ipm

ID : : = {id-hat 1}

id-hat-originator

ID : : = {id-hat 2}

id-hat-replied-to-IPM

ID : : = {id-hat 3}

id-hat-subject

ID : : = {id-hat 4}

id-hat-expiry-time

ID : : = {id-hat 5}

id-hat-reply-time

ID : : = {id-hat 6}

id-hat-importance

ID : : = {id-hat 7}

id-hat-sеnsitivity

ID : : = {id-hat 8}

id-hat-auto-forwarded

ID : : = {id-hat 9}

id-hat-authorizing-users

ID : : = {id-hat 10}

id-hat-primary-recipients

ID : : = {id-hat 11}

id-hat-copy-recipients

ID : : = {id-hat 12}

id-hat-blind-copy-recipients

ID : : = {id-hat 13}

id-hat-obsoleted-IPMs

ID : : = {id-hat 14}

id-hat-related-IPMs

ID : : = {id-hat 15}

id-hat-reply-rеcipients

ID : : = {id-hat 16}

id-hat-incomplеte-copy

ID : : = {id-hat 17}

id-hat-languages

ID : : = {id-hat 18}

id-hat-rn-requеstors

ID : : = {id-hat 19}

id-hat-nrn-requestors

ID : : = {id-hat 20}

id-hat-rеply-rеquеstors

ID : : = {id-hat 21}

-- Атрибуты тела

id-bat-body

ID : : = {id-bat 0}

id-bat-ia5-text-body-parts

ID : : = {id-bat 1}

id-bat-voice-body-parts

ID : : = {id-bat 2}

id-bat-g3-facsimile-body-parts

ID : : = {id-bat 3}

id-bat-g4-class1-body-parts

ID : : = {id-bat 4}

id-bat-teletex-body-parts

ID : : = {id-bat 5}

id-bat-vidеotеx-body-parts

ID : : = {id-bat 6}

id-bat-encryptеd-body-parts

ID : : = {id-bat 7}

id-bat-message-body-parts

ID : : = {id-bat 8}

id-bat-mixed-mode-body-parts

ID : : = {id-bat 9}

id-bat-bilaterally-dеfined-body-parts

ID : : = {id-bat 10}

id-bat-nationally-defined-body-parts

ID : : = {id-bat 11}

id-bat-extended-body-part-types

ID : : = {id-bat 12}

id-bat-ia5-text-parameters

ID : : = {id-bat 13}

id-bat-voice-parameters

ID : : = {id-bat 14}

id-bat-g3-facsimile-parameters

ID : : = {id-bat 15}

id-bat-teletex-parameters

ID : : = {id-bat 16}

id-bat-videotex-parameters

ID : : = {id-bat 17}

id-bat-encrypted-parameters

ID : : = {id-bat 18}

id-bat-message-parameters

ID : : = {id-bat 19}

id-bat-ia5-text-data

ID : : = {id-bat 20}

id-bat-voice-data

ID : : = {id-bat 21}

id-bat-g3-facsimile-data

ID : : = {id-bat 22}

id-bat-teletex-data

ID : : = {id-bat 23}

id-bat-videotex-data

ID : : = {id-bat 24}

id-bat-encrypted-data

ID : : = {id-bat 25}

id-bat-message-data

ID : : = {id-bat 26}

-- Атрибуты уведомления

id-nat-subject-ipm

ID : : = {id-nat 0}

id-nat-ipn-originator

ID : : = {id-nat 1}

id-nat-ipm-preferred-recipient

ID : : = {id-nat 2}

id-nat-conversion-eits

ID : : = {id-nat 3}

id-nat-non-receipt-reason

ID : : = {id-nat 4}

id-nat-discard-reason

ID : : = {id-nat 5}

id-nat-auto-forward-comment

ID : : = {id-nat 6}

id-nat-returned-ipm

ID : : = {id-nat 7}

id-nat-receipt-time

ID : : = {id-nat 8}

id-nat-acknowledgment-mode

ID : : = {id-nat 9}

id-nat-suppl-receipt-info

ID : : = {id-nat 10}

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

id-mct-p2-1984 ID : : = {id-mct 0} - - Р2 1984

id-mct-p2-1988 ID : : = {id-mct 1} - - Р2 1988

-- Параметры расширенной части тела

id-ep-ia5-text

ID : : = {id-ep 0}

id-ep-voice

ID : : = {id-ep 1}

id-ep-g3-facsimile

ID : : = {id-ep 2}

id-ep-teletex

ID : : = {id-ep 4}

id-ep-videotex

ID : : = {id-ep 5}

id-ep-encrypted

ID : : = {id-ep 6}

id-ep-message

ID : : = {id-ep 7}

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

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


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


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

IPMSInformationObjects {joint-iso-ccitt

mhs-motis(6) ipms(1) modules(0) information-objects(2)}


DEFINITIONS IMPLICIT TAGS : : =

BEGIN

-- Пролог

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

IMPORTS

- - Верхние границы СМПС

ub-auto-forward-comment, ub-free-form-name, ub-ipm-idеntifiеr-suffix,

ub-local-imp-identifier, ub-subject-field, ub-telephone-number

- - - -

FROM IPMSUpperBounds {joint-iso-ccitt

mhs-motis(6) ipms(1) modules(0) upper-bounds (10)}

- - DTAМ

ProtocolElement

- - - -

FROM dTAM

- - Абстрактные услуги СПС

Encodedlnformation Types, G3FacsimileNonBasicParameters,
MessageDeliveryTime, ORAddress, ORName,
OtherMessageDeliveryFields, Supplementarylnformation, TeletexNonBasicParameters,

- - - -

FROM MTSAbstractService {joint-iso-ccitt

mhs-motis(6) mts(3) modules(0) mts-abstract-service(1)};


Time : : = UTCTime

- - Информационный объект

InformationObject : : = CHOICE {

ipm

[0] IPM,

ipn

[1] IPN}


- - МПС

IPM : : = SEQUENCE {

heading

Heading,

body

Body}

- - Заголовок

Heading : : = SET {

this-IPM

ThisIPMField,

originator

[0]

OriginatorFieId OPTIONAL,

authorizing-users

[1]

AuthorizingUsersField OPTIONAL,

primary-recipients

[2]

PrimaryRecipientsFieId DEFAULT {},

copy-recipients

[3]

CopyRecipientsField DEFAULT {},

blind-copy-recipients

[4]

BlindCopyRecipiеntsField OPTIONAL,

replied-to-IPM

[5]

RepliedToIPMFieId OPTIONAL,

obsoleted-IPMs

[6]

ObsoletedIPMsField DEFAULT {},

reIated-IPMs

[7]

ReIatedIPMsField DEFAULT {},

subject

[8]

EXPLICIT SubjectField OPTIONAL,

expiry-time

[9]

ExpiryTimeField OPTIONAL,

reply-time

[10]

RеplyTimeField OPTIONAL,

reply-recipients

[11]

RepIyRecipientsField OPTIONAL,

importance

[12]

ImportanceField DEFAULT normal,

sensitivity

[13]

SеnsitivityField OPTIONAL,

auto-forwarded

[14]

AutoForwardedField DEFAULT FALSE,

extensions

[15]

ExtensionsField DEFAULT {}}


- - Типы содержимого заголовка

IPMIdenlifier : : = [APPLICATION 11] SET {

user

ORAddress OPTIONAL,

user-relative-identifier

LocalIPMIdentifier}


LocalIPMIdentifier : : = PrintabIeString

(SIZE (0 . . local-imp-identifier))


RecipientSpecifier : : = SET {

recipient

[0]

ORDescriptor,

notification-requests

[1]

NotificationRequests DEFAULT {},

reply-requested

[2]

BOOLEAN DEFAULT FALSE}


NotificationRequests : : = BIT STRING {

rn(0),

nrn(1),

ipm-return(2)}


ORDescriptor : : = SET {

formal-name

ORName OPTIONAL,

free-form-name

[0]

FreeFormName OPTIONAL,

telephone-number

[1]

TelephoneNumber OPTIONAL}


FreeFormName : : = TeletexString (SIZE (0 . . ub-free-form-name))

TelephoneNumber : : = PrintableString (SIZE (0 . . ub-telephone-number))

- - Поле заголовка данного МПС

This IPMField : : = IPMIdentifier

- - Поле заголовка отправителя

OriginatorField : : = ORDescriptor

- - Поле заголовка полномочных пользователей

AuthorizingUsersField : : = SEQUENCE OF AuthorizingUsersSubfield

AuthorizingUsersSubfield : : = ORDescriptor

- - Поле заголовка основных получателей

PrimaryRecipientsField : : = SEQUENCE OF PrimaryRecipientsSubfield

PrimaryRecipientsSubfield : : = RecipientSpecifier

- - Поле заголовка получателей копии

Copy Recipients Field : : = SEQUENCE OF CopyRecipientsSubfield

CopyRecipientsSubfield : : = RecipientSpecifier

- - Поле заголовка получателей "слепой" копии

BlindCopyRecipientsField : : = SEQUENCE OF BlindCopyRecipientsSubfield

BlindCopyRecipientsSubfield : : = RecipientSpecifier

- - Ответ на поле заголовка МПС

RepliedToIPMField : : = IPMIdentifier

- - Поле заголовка устарелых МПС

ObsoletedIPMsField : : = SEQUENCE OF ObsoletedIPMsSubfield

ObsolеtеdIPMsSubfield : : = IPMIdentifier

- - Поле заголовка взаимосвязанных МПС

RelatedIPMsField : : = SEQUENCE OF RelatedIPMsSubfield

RelatedIPMsSubfield : : = IPMIdentifier

- - Поле заголовка подполя

SubjectField : : = TeletеxString (SIZE (0 . . ub-subject-field))

- - Поле заголовка истекшего времени

Expiry-TimeField : : = Time

- - Поле заголовка времени ответа

ReplyTimeField : : = Time

- - Поле заголовка получателей ответа

ReplyRecipientsField : : = SEQUENCE OF ReplyRecipientsSubfield

ReplyRecipientsSubfield : : = ORDescriptor

- - Поле заголовка важности

ImportanceField : : = ENUMERATED {

low

(0),

normal

(1),

high

(2)}


-- Поле заголовка чувствительности

SensitivityField : : = ENUMERATED {

personal

(1),

private

(2),

company-confidential

(3)}


- - Поле заголовка автопродвижения

AutoForwardedField : : = BOOLEAN

- - Поле заголовка расширений

ExtеnsionsField : : = SET OF HeadingExtension

HeadingExtension : : = SEQUENCE {

type

OBJECT IDENTIFIER,

value

ANY DEFINED BY type DEFAULT NULL NULL}


HEADING-EXTENSION MACRO : : =

BEGIN

TYPE NOTATION : : = "VALUE" type | empty

VALUE NOTATION : : = value (VALUE OBJECT IDENTIFIER)


END

- - Тело

Body : : = SEQUENCE OF BodyPart

BodyPart : : = CHOICE {

ia5-text

[0]

IA5TextBodyPart,

voice

[2]

VoiceBodyPart,

g3-facsimile

[3]

G3FacsimileBodyPart,

g4-class1

[4]

G4Class1BodyPart,

teletex

[5]

TeletexBodyPart,

videotex

[6]

VideotexBodyPart,

encrypted

[8]

EncryptedBodyPart,

message

[9]

MessageBodyPart,

mixed-mode

[11]

MixedModeBodyPart,

bilaterally-defined

[14]

BilaterallyDefinedBodyPart,

nationally-defined

[7]

NationallyDefinedBodyPart,

еxternally-defined

[15]

ExternallyDefinedBodyPart }


- - Часть тела текст МК5

IA5TextBodyPart : : = SEQUENCE {

parameters

IA5TextParameters,

data

IA5TextData }


IA5TextParameters : : = SET {

repertoire

[0] Repertoire DEFAULT ia5 }


IA5TextData : : = IA5String

Repertoire : : = ENUMERATED {

ita2 (2),

ia5 (5) }


- - Часть тела речи

VoiceBodyPart : : = SEQUENCE {

parameters

VoiceParameters,

data

VoiceData }


Voice Parameters : : = SET -- для дальнейшего изучения

VoiceData : : = BIT STRING -- для дальнейшего изучения

- - Часть тела факсимиле 3

G3FacsimileBodyPart : : = SEQUENCE {

parameters

G3FacsimileParameters,

data

G3FacsimileData }


G3FacsimiIeParameters : : = SET {

number-of-pages

[0] INTEGER OPTIONAL,

non-basic-parameters

[1] G3FacsimileNonBasicParameters OPTIONAL}


G3FacsimileData : : = SEQUENCE OF BIT STRING

- - Часть тела факсимиле 4 класс 1 и смешанного режима

G4Class1BodyPart : : = SEQUENCE OF ProtocolElement

MixedModeBodyPart : : = SEQUENCE OF ProtocolElement

- - Часть тела телекса

TeletexBodyPart : : = SEQUENCE {

parameters

TeletexParameters,

data

TeletexData }

TeletexParameters : : = SET {

number-of-pages

[0] INTEGER OPTIONAL,

telex-compatible

[1] BOOLEN DEFAULT FALSE,

non-basic-parameters

[2] TeletexNonBasicParameters OPTIONAL}


TeletexData : : = SEQUENCE OF TeletexString

- - Часть тела видеотекса

VideotexBodyPart : : = SEQUENCE {

parameters

VideotexParameters,

data

VideotexData }

VideotexParameters : : = SET {

syntax

[0] VideotexSyntax OPTIONAL

VideotexSyntax : : = INTEGER

ids

(0),

data-syntax1

(1),

data-syntax2

(2),

data-syntax3

(3) }


VideotexData : : = VideotexString

-- Зашифрованная часть тела

EncryptedBodyPart : : = SEQUENCE {

parameters

EncryptedParameters,

data

EncryptedData }


EncryptedParameters : : = SET -- для дальнейшего изучения

EncryptedData : : = BIT STRING -- для дальнейшего изучения

-- Часть тела сообщения

MessageBodyPart : : = SEQUENCE {

parameters

Message Parameters,

data

Message Data }


Message Parameters : : = SET {

delivery-time

[0] MessageDeliveryTime OPTIONAL

delivery-envelope

[1] OtherMessageDeliveryFields OPTIONAL }


MessageData : : = IPM

-- Двусторонне определяемая часть тела

BilaterallyDefinedBodyPart : : = OCTET STRING

-- Национально определяемая часть тела

NationallyDefinedBodyPart : : = ANY

-- Внешне определяемая часть тела

ExternalIyDefinedBodyPart : : = SEQUENCE {

parameters [0]

ExternallyDefinedParameters OPTIONAL,

data

ExternallyDefinedData }


ExternallyDefinedParameters : : = EXTERNAL

ExternallyDefinedData : : = EXTERNAL

EXTENDED-BODY-PART-TYPE MACRO : : =

BEGIN

TYPE NOTATION

: : = Parameters Data

VALUE NOTATION

: : = value (VALUE OBJECT IDENTIFIER)

Parameters

: : = "PARAMETERS" type

"IDENTIFIED" "BY" valye

(OBJECT IDENTIFIER) | empty

Data

: : = "DATA" type


END

- - МПУ

IPN : : = SET {

- - common-fields - COMPONENTS OF CommonFields,

choice [0] CHOICE {

non-receipt-fields

[0]

NonReceiptFields,

receipt-fields

[1]

ReceiptFields }}


RN : : = IPN -- с выбранными полями получателя

NRN : : = IPN -- с невыбранными полями получателя

CommonFields : : = SET {

subject-ipn

SubjectIPNFields,

ipn-originator

[1] IPNOriginatorField OPTIONAL,

ipn-preferred-recipient

[2] IPNPrеferredRecipientField OPTIONAL,

conversion-eits

ConversionEITsField OPTIONAL }


NonReceiptFields : : = SET {

non-receipt-reason

[0] NonReceiptReasonFieId,

discard-reason

[1] DiscardReasonField OPTIONAL,

auto-forward-comment

[2] AutoForwardCommentField OPTIONAL,

returned-ipm

[3] ReturnedIPNField OPTIONAL }


ReceiptFields : : = SET {

receipt-time

[0] RecipientTimeField,

acknowledgment-mode

[1] AcknowledgmentModeField DEFAULT manual,

suppl-receipt-info

[2] SupplReceiptInfoField DEFAULT " " }


- - Общие поля

SubjectIPMFieId : : = IPMIdentifier

IPMOriginatorField : : = ORDescriptor

IPMPreferredRecipientField : : = ORDescriptor

ConversionEITsField : : = EncodedInformationTypes

- - Поля неприема

NonReceiptReasonFieId : : = ENUMERATED {

ipm-discarded

(0),

ipm-auto-forwarded

(1) }


DiscardReasonField : : = ENUMERATED {

ipm-expired

(0),

ipm-obsoleted

(1),

user-subscription-terminated

(2) }


AutoForwardCommentField : : = AutoForwardComment

AutoForwardComment : : = PrintableString

(SIZE (0 . . ub-auto-forward-comment))

ReturnedIPMField : : = IPM

- - Поля приема

ReceiptTimeField : : = Time

AcknowledgmentModeField : : = ENUMERATED {

manual

(0),

automatic

(1) }


SupplReceiptInfoField / : : = SupplementaryInformation

- - Реализация хранилища сообщений

Forwardedlnfo : : = SET {

auto-forwarding-comment [0]

AutoForwardComment OPTIONAL,


cover-note [1]

IA5TextBodyPart OPTIONAL,


this-ipm-prefix [2]

PrintableString (SIZE (1..ub-ipm-identifier-suffix))

OPTIONAL }


END - - информационныхОбъектовСМПС

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

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


В данном приложении, которое дополняет разделы 10, 11 и 16 настоящего стандарта, приведены для справочных целей функциональные объекты межперсональных сообщений. Здесь использованы макрокоманды OBJECT и REFINE по ИСО/МЭК 10021-3.

IPMFunctionalObjects {joint-iso-ccitt

mhs-motis(6) moduIes(0) functional-objects(1) }

DEFINITIONS IMPLICIT TAGS : : =

BEGIN

- - Пролог

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

IMPORTS

- - Абстрактные услуги СМПС

management, origination, reception

- - - -

FROM IPMSAbstractService { joint-iso-ccitt

mhs-motis(6) ipms(1) modules(0) abstract-service(3)}

- - Объектные идентификаторы СМПС

id-ot-ipme, id-ot-ipms, id-ot-ipms-ms, id-ot-ipms-ua,

id-ot-ipms-user, id-ot-pdau, id-ot-tima, id-ot-tlxau,

id-ref-primary, id-ref-secondary

- - - -

FROM IPMSObjectldentifiers {joint-iso-ccitt

mhs-motis(6) ipms(1) modules(0) object-identifiers(0)}

- - Абстрактные услуги АТЛМ

miscellanea

- - - -

FROM TLMAAbsService {ccitt

recommendation(0) t(20) 330 tlmaabsservice(0) }

- - Абстрактные услуги XC

retrieval

- - - -

FROM MSAbstractService {joint-iso-ccitt

mhs-motis(6) ms(4) moduIes(0) abstract-service(1) }

- - Абстрактные услуги СПС

administration, delivery, mTS, submission

- - - -

FROM MTSAbstractService {joint-iso-ccitt

mhs-motis(6) mts(3) modules(0) mts-abstract-service(1) }

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

OBJECT, REFINE

- - - -

FROM AbstractServiceNotation {joint-iso-ccitt

mhs-motis(6) asdc(2) modules(0) notation(1) }


-- Объектный тип "корень"

ipme OBJECT

: : = id-ot-ipmе

- - Первичное уточнение

ipme-refinement REFINE ipme AS

ipms

origination

[S]

PAIRED WITH ipms-user

reception

[S]

PAIRED WITH ipms-user

management

[S]

PAIRED WITH ipms-user


ipms-user RECURRING

: : = id-ref-primary

- - Первичные типы объектов

ipms-user OBJECT

PORTS {

origination

[C],

reception

[C],

management

[C] }


: : = id-ot-ipms-user

ipms OBJECT

PORTS {

origination

[S],

reception

[S],

management

[S] }


: : = id-ot-ipms

- - Вторичное уточнение

ipms-refinement REFINE ipms AS

mTS

submission

[S]

PAIRED WITH ipms-ua, ipms-ms

delivery

[S]

PAIRED WITH ipms-ua, ipms-ms

administration

[S]

PAIRED WITH ipms-ua, ipms-ms


ipms-ua RECURRING

origination

[S]

VISIBLE

reception

[S]

VISIBLE

management

[S]

VISIBLE


ipms-ms RECURRING

submission

[S]

PAIRED WITH ipms-ua

retrieval

[S]

PAIRED WITH ipms-ua

administration

[S]

PAIRED WITH ipms-ua


tlma RECURRING

origination

[S]

VISIBLE

reception

[S]

VISIBLE

management

[S]

VISIBLE


tlxau RECURRING

origination

[S]

VISIBLE

reception

[S]

VISIBLE

management

[S]

VISIBLE


pdau RECURRING

reception

[S]

VISIBLE


: : = id-ref-sеcondary

- - Вторичные объекты

ipms-ua OBJECT

PORTS {

origination

[S],

reception

[S],

management

[S],

submission

[C],

delivery

[C],

retrieval

[C],

administration

[C] }

: : = id-ot-ipms-ua


ipms-ms OBJECT

PORTS {

submission

[S],

retrieval

[S],

administration

[S],

submission

[C],

delivery

[C],

administration

[C],

: : = id-ot-ipms-ms


tlma OBJECT

PORTS {

origination

[S],

reception

[S],

management

[S],

miscellanea

[S] }

: : = id-ot-tlma

tlxau OBJECT

PORTS {

origination

[S],

reception

[S],

management

[S] }

: : = id-ot-tlxau


pdau OBJECT

PORTS {

reception

[S]

: : = id-ot-pdau


END -- функциональныхОбъектовСМПС

ПРИЛОЖЕНИЕ G (обязательное). ОПРЕДЕЛЕНИЕ АБСТРАКТНЫХ УСЛУГ ДЛЯ СПРАВОЧНЫХ ЦЕЛЕЙ

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


В данном приложении, которое дополняет разделы 12 и 13 настоящего стандарта, приведены для справочных целей определения абстрактных услуг СМПС. Здесь используются макрокоманды PORT, ABSTRACT-OPERATION и ABSTRACT-ERROR по ИСО/МЭК 10021-3.

IPMSAbstractService {joint-iso-ccitt

mhs-motis(6) ipms(1) modules(0) abstract-service (3) }

DEFINITIONS IMPLICIT TAGS : : =

BEGIN

- - Пролог

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

IMPORTS

- - Информационные объекты СМПС

AutoForwardComment, Heading, IPM, NRN, RN

- - - -

FROM IPMSInformationObjects {joint-iso-ccitt

mhs-motis(6) ipms(1) moduIes(0)

information-objects(2) }

- - Объектные идентификаторы СМПС

id-pt-management, id-pt-origination, id-pt-reception

- - - -

FROM IPMSObjectsIdentifiers {joint-iso-ccitt

mhs-motis(6) ipms(1) modules(0)

objects-identifiers(0) }

- - Абстрактные услуги СПС

MessageDelivery Envelope, Message SubmissionEnvelope,

MessageSubmissionIdentifiers, MessageSubmissionTime,

ProbeSubmissionEnvelope, ProbeSubmissionIdentifier,

ProbeSubmissionTime, RecipientImproperlySpecified,

ReportDeliveryEnvelope,

- - - -

FROM MTSAbstractService {joint-iso-ccitt

mhs-motis(6) mts(3) modules(0)

mts-abstract-service(1) }

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

ABSTRACT-ERROR, ABSTRACT-OPERATION, PORT

- - -

FROM AbstractServiceNotation {joint-iso-ccitt

mhs-motis(6) asdc(2) modules(0)

notation(1) };


Time : : = UTCTime

- - Порты

origination PORT

CONSUMER INVOKES {

Originate Probe,

OriginateIPM,

OriginateRN }

: : = id-pt-origination


reception PORT

SUPPLIER INVOKES {

ReceiveReport,

ReceiveIPM,

ReceiveRN,

ReceiveNRN }

: : = id-pt-reception


management PORT

CONSUMER INVOKES {

ChangeAutoDiscard,

ChangeAutoAcknowledgment,

ChangeAutoForwarding }

: : = id-pt-management


- - Абстрактные операции отправителя

OriginateProbe : : = ABSTRACT-OPERATION

ARGUMENT SET {

envelope

[0] ProbeSubmissionEnvelope,

content

[1] IPM }

RESULT SET {

submission-identifier

[0]

ProbeSubmissionIdentifier,

submission-time

[1]

ProbeSubmissionTime }

ERRORS {

SubscriptionError,

RecipientImproperlySpecified}


OriginateIPM : : = ABSTRACT-OPERATION

ARGUMENT SET {

envelope

[0]

MessageSubmissionEnvelope,

content

[1]

IPM }

RESULT SET {

submission-identifier

[0]

MessageSubmissionIdentifier,

submission-time

[1]

MessageSubmissionTime}

ERROR {

SubscriptionError,

RecipientImproperIySpecifled }


OriginateRN : : = ABSTRACT-OPERATION

ARGUMENT SET {

envelope

[0]

MessageSubmissionEnvelope,

content

[1]

RN }

RESULT SET {

submission-identifier

[0]

MessageSubmissionIdentifier,

submission-time

[1]

MessageSubmissionTime}

ERROR {

SubscriptionError,

RecipientImproperIySpecifled }


- - Абстрактные операции получателя

ReceiptReport : : = ABSTRACT-OPERATION

ARGUMENT SET {

envelope

[0]

ReportDeliveryEnvelope,

undelivered-object

[1]

InformationObject OPTIONAL }

RESULT

ERRORS {}


ReceiveIPM : : = ABSTRACT-OPERATION

ARGUMENT SET {

envelope

[0]

MessageDeliveryEnvelope,

content

[1]

IPM }

RESULT

ERRORS {}


ReceiveRN : : = ABSTRACT-OPERATION

ARGUMENT SET {

envelope

[0]

MessageDeliveryEnvelope,

content

[1]

RN }

RESULT

ERRORS {}


ReceiveNRN : : = ABSTRACT-OPERATION

ARGUMENT SET {

envelope

[0]

MessageDeliveryEnvelope,

content

[1]

NRN }

RESULT

ERRORS {}


- - Абстрактные операции управления

ChangeAutoDiscard : : = ABSTRACT-OPERATION

ARGUMENT SET {

auto-discard-expired-IPMs

[0]

BOOLEAN,

auto-discard-obsolete-IPMs

[1]

BOOLEAN }

RESULT

ERRORS {}


ChangeAutoAcknowledgement : : = ABSTRACT-OPERATION

ARGUMENT SET {

auto-acknowIedge-IPMs

[0]

BOOLEAN,

auto-acknowledge-suppl-receipt-info

Supplementarylnformation }

[1]

RESULT

ERRORS }

SubscriptionError }


ChangeAutoForwarding : : = ABSTRACT-OPERATION

ARGUMENT SET {

auto-forward-IPMs

[0]

BOOLEAN,

auto-forward-recipients

[1]

SEQUENCE OF ORName
OPTIONAL,

auto-forward-heading

[2]

Heading OPTIONAL,

auto-forward-comment

[3]

AutoForwardComment
OPTIONAL }

RESULT

ERRORS {

SubscriptionError,

RecipientImproperIySpecified }


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

SubscriptionError : : = ABSTRACT-ERROR

PARAMETER SET {

problem

[0]

SubscriptionProblem }


Subscription Problem : : = ENUMERATED {

ipms-eos-not-subscribed

(0),

mts-eos-not-subscribed

(1) }


END -- абстрактныхУслугСМПС

ПРИЛОЖЕНИЕ Н (обязательное). ОПРЕДЕЛЕНИЕ РАСШИРЕНИЙ ЗАГОЛОВКА ДЛЯ СПРАВОЧНЫХ ЦЕЛЕЙ

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


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

IPMSHeadingExtensions {joint-iso-ccitt

mhs-motis(6) ipms(1) modules(0) heading-extensions(6)}


DEFINITIONS IMPLICIT TAGS : : =

BEGIN

- - Пролог

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

IMPORTS

-- Информационные объекты СМПС

HEADING-EXTENSION

- - - -

FROM IPMSInformationObjects {joint-iso-ccitt

mhs-motis(6) ipms(1) modules(0) information-objects(2)};

- - Объектные идентификаторы СМПС

id-hex-incomplete-copy, id-hex-languages

- - - -

FROM IPMSObjectsIdentifiers {joint-iso-ccitt

mhs-motis(6) ipms(1) modules(0) objects-identifiers(0)};


- - Некомплектная копия

Incomplete copy HEADING-EXTENSION

: : = id-hex-incomplete-copy


IncompleteCopy : : = NULL

- - Языки

languages HEADING-EXTENSION

VALUE SET OF Language

: : = id-hex-languages


Language : : = PrintableString (SIZE (2 . . 2))

END - - расширенийЗаголовка СМПС

ПРИЛОЖЕНИЕ I (обязательное). ОПРЕДЕЛЕНИЕ РАСШИРЕННЫХ ТИПОВ ЧАСТЕЙ ТЕЛА ДЛЯ СПРАВОЧНЫХ ЦЕЛЕЙ

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


В данном приложении, которое дополняет приложение В настоящего стандарта, приведены для справочных целей определения некоторых расширенных типов частей тела.

IPMSExtendedBodyPartTypes {joint-iso-ccitt

mhs-motis(6) ipms(1) modules(0) extended-body-part-types(7)}

DEFINITIONS IMPLICIT TAGS : : =

BEGIN

- - Пролог

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

IMPORTS

- - Информационные объекты СМПС

BilaterallyDefinedBodyPart, EncryptedData,

EncryptedParameters, EXTENDED-BODY-PART-TYPE,

G3FacsimileData,

G3FacsimileParameters, G4Class1BodyPart, IA5TextData,

IA5TextParameters, MessageData, MessageParameters,

MixedModeBodyPart, NationallyDefinedBodyPart,

TeletexData,

TeletexParameters, VideotexData, VideotexParameters,

VoiceData, VoiceParameters.

- - - -

FROM IPMSInformationObjects {joint-iso-ccitt

mhs-motis(6) ipms(1) moduIes(0) information-objects(2)}

- - Объектные идентификаторы СМПС

id-ep-encrypted,

id-ep-g3-facsimile,

id-ep-ia5-text,

id-ep-message,

id-ep-teletex,

id-ep-videotex,

id-ep-voice,

id-et-bilaterally-defined, id-et-encrypted, id-et-g3-facsimile,

id-et-g4-class1, id-et-ia5-text, id-et-message,

id-et-g4-class1, id-et-ia5-text, id-et-message,

id-et-mixed-mode, id-et-nationally-defined, id-et-teletex,

id-et-videotex, id-et-voice

- - - -

FROM IPMSObjectsIdentifiers {joint-iso-ccitt

mhs-motis(6) ipms(1) moduIes(0) objects-identifiers(0)}


- - Расширенная часть тела текст МК5

ia5-text-body-part EXTENDED-BODY-PART-TYPE

PARAMETERS

IA5TextParameters IDENTIFIED BY id-ep-ia5-text

DATA

IA5TextData

: : = id-et-ia5-text


- - Расширенная часть тела речь

voice-body-part EXTENDED-BODY-PART-TYPE

PARAMETERS

VoiceParametersIDENTIFIED BY id-ep-voice

DATA

VoiceData

: : = id-et-voice


- - Расширенная часть тела факсимиле 3

g3-facsimile-body-part EXTENDED-BODY-PART-TYPE

PARAMETERS

G3FacsimileParameters IDENTIFIED BY id-ep-g3-facsimile

DATA

G3FacsimileDATA

: : = id-et-g3-facsimile


- - Расширенная часть тела факсимиле 4 класс 1

g4-class1-body-part EXTENDED-BODY-PART-TYPE

DATA

G4Class1BodyPart

: : = id-et-g4-class1


- - Расширенная часть тела телетекса

teletex-body-part EXTENDED-BODY-PART-TYPE

PARAMETERS

TeletexParameters IDENTIFIED BY id-ep-teletex

DATA

TeletexData

: : = id-et-teletex

- - Расширенная часть тела видеотекса

videotex-body-part EXTENDED-BODY-PART-TYPE

PARAMETERS

VideotexParameters IDENTIFIED BY id-ep-videotex

DATA

VideotexData

: : = id-et-videotex


- - Расширенная часть тела зашифрованных данных

encrypted-body-part EXTENDED-BODY-PART-TYPE

PARAMETERS

EncryptedParameters IDENTIFIED BY id-ep-encrypted

DATA

EncryptedData

: : = id-et-encrypted


- - Расширенная часть тела сообщения

message-body-part EXTENDED-BODY-PART-TYPE

PARAMETERS

MessageParameters IDENTIFIED BY id-ep-message

DATA

MessageData

: : = id-et-message


- - Расширенная часть тела смешанного режима

mixed-mode-body-part EXTENDED-BODY-PART-TYPE

DATA MixedModeBodyPart

: : = id-et-mixed-mode


- - Расширенная двусторонне определяемая часть тела

bilaterally-defined-body-part EXTENDED-BODY-PART-TYPE

DATA BilaterallyDefinedBodyPart

: : = id-et-bilaterally-defined


- - Расширенная национально определяемая часть тела

nationally-defined-body-part EXTENDED-BODY-PART-TYPE

DATA NationallyDefinedBodyPart

: : = id-et-nationally-defined


END - - типовРасширеннойЧастиТелаСМПС

ПРИЛОЖЕНИЕ J (обязательное). ОПРЕДЕЛЕНИЕ АТРИБУТОВ ХРАНИЛИЩА СООБЩЕНИЙ ДЛЯ СПРАВОЧНЫХ ЦЕЛЕЙ

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


В данном приложении, которое дополняет приложение С настоящего стандарта, приведены для справочных целей определения атрибутов ХС, специфичных для межперсональных сообщений. Здесь используется макрокоманда ATTRIBUTE по ИСО/МЭК 9594-2.

IPMSMessageStoreAttributes {joint-iso-ccitt

mhs-motis(6) ipms(1) modules(0) message-store-attributes(8)}

DEFINITIONS IMPLICIT TAGS : : =

BEGIN

- - Пролог

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

IMPORTS

- - Расширения заголовка СМПС

IncompleteCopy, Language

- - - -

FROM IPMSHeadingExtensions {joint-iso-ccitt

mhs-motis(6) ipms(1) modules(0) heading-extensions(6) }

- - Информационные объекты СМПС

AcknowledgmentModeField, AuthorizingUsersSubfield,

AutoForwardCommentField, AutoForwardedField,

BilaterallyDefinedBodyPart, BlindCopyRecipientsSubfield, Body,

ConversionEITsField, CopyRecipientsSubfield,

DiscardReasonField, EncryptedBodyPart, EncryptedData,

EncryptedParameters, ExpiryTimeField,

ExternallyDefinedParameters, G3FacsimileBodyPart,

G3FacsimileData, G3FacsimileParameters, G4Class1BodyPart,

Heading, IA5TextBodyPart, IA5TextData, IA5TextParameters,

ImportanceField, IPMPreferredRecipientField,

IPNOriginatorField, MessageBodyPart, MessageData,

MessageParameters, MixedModeBodyPart,

NationallyDefinedBodyPart, NonReceiptReasonField,

ObsoletedIPMsSubfield, ORDescriptor, OriginatorField,

Primary RecipientsSubfield, ReceiptTimeField,

RelatedIPMsSubfield, RepliedToIPMField,

ReplyRecipientsSubfield, ReplyTimeField, ReturnedIPMField,

SensitivityField, SubjectField, SubjectIPMField,

SupplReceiptInfoField, TeletexBodyPart, TeletexData,

TeletexParameters, ThislPMField, VideotexBodyPart,

VideotexData, VideotexParameters, VoiceBodyPart, VoiceData,

VoiceParameters

- - - -

FROM IPMSInformationObjects {joint-iso-ccitt

mhs-motis(6) ipms(1) modules(0) information-objects(2)}

- - Объектные идентификаторы СМПС

id-bat-bilaterally-defined-body-parts, id-bat-body,

id-bat-encrypted-body-parts, id-bat-encrypted-data,

id-bat-encrypted-parameters, id-bat-extended-body-part-types,

id-bat-g3-facsimile-body-parts, id-bat-g3-facsimile-data,

id-bat-g3-facsimile-parameters, id-bat-g4-class1-body-parts,

id-bat-ia5-text-body-parts, id-bat-ia5-text-data,

id-bat-ia5-text-parameters, id-bat-message-body-parts,

id-bat-message-data, id-bat-message-parameters,

id-bat-mixed-mode-body-parts,

id-bat-nationally-defined-body-parts,

id-bat-teletex-body-parts, id-bat-teletex-data,

id-bat-teletex-parameters, id-bat-videotex-body-parts,

id-bat-videotex-data, id-bat-videotex-parameters,

id-bat-voice-body-parts, id-bat-voice-data,

id-bat-voice-parameters, id-hat-authorizing-users,

id-hat-auto-forwarded, id-hat-blind-copy-recipients,

id-hat-copy-recipients, id-hat-expiry-time, id-hat-heading,

id-hat-importance, id-hat-incomplete-copy, id-hat-languages,

id-hat-nrn-requestors, id-hat-obsoleted-IPMs,

id-hat-originator, id-hat-primary-recipients,

id-hat-related-IPMs, id-hat-replied-to-IPM,

id-hat-reply-recipients, id-hat-reply-requestors,

id-hat-reply-time, id-hat-rn-requestors, id-hat-sensitivity,

id-hat-subject, id-hat-this-ipm, id-nat-acknowledgment-mode,

id-nat-auto-forward-comment, id-nat-conversion-eits,

id-nat-discard-reason, id-nat-ipm-preferred-recipient,

id-nat-ipn-originator, id-nat-non-receipt-reason,

id-nat-receipt-time, id-nat-returned-ipm, id-nat-subject-ipm,

id-nat-suppl-receipt-info, id-sat-ipm-entry-type,

id-sat-ipm-synopsis

- - - -

FROM IPMSObjectldentifiers {joint-iso-ccitt

mhs-motis(6) ipms(1) modules(0) object-identifiers(0) }

- - Абстрактные услуги ХС

MS-EITs, SequenceNumber

- - - -

FROM MSAbstractService {joint-iso-ccitt

mhs-motis(6) ms(4) modules(0) abstract-service (1) }

- - Абстрактные услуги СПС

EncodedInformationTypes

- - - -

FROM MTSAbstractService {joint-iso-ccitt

mhs-motis(6) mts(3) modules(0) mts-abstract-service(1) };

- - Основы информации справочника

ATTRIBUTE

- - - -

FROM InformationFramework {joint-iso-ccitt

ds(5) modules(1) informationFramework(1) };


Time : : = UTCTime

- - СУММАРНЫЕ АТРИБУТЫ

- - Тип входа МПС

ipm-entry-type ATTRIBUTE

WITH ATTRIBUTE-SYNTAX IMPEntryType

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-sat-ipm-entry-type


IPMEntryType : : = ENUMERATED {

ipm

(0),

rn

(1),

nrn

(2) }

- - Конспект МПС

ipm-synopsis ATTRIBUTE

WITH ATTRIBUTE-SYNTAX IPMSynopsis

SINGLE VALUE

: : = id-sat-ipm-synopsis


IPMSynopsis : : = SEQUENCE OF BodyPartSynopsis

BodyPartSynopsis : : = CHOICE {

message

[0]

MessageBodyPartSynopsis,

non-message

[1]

NonMessageBodyPartSynopsis }


MessageBodyPartSynopsis : : = SEQUENCE {

number

[0]

SequenceNumber,

synopsis

[1]

IPMSynopsis }

NonMessageBodyPartSynopsis : : = SEQUENCE {

type

[0]

OBJECT IDENTIFIER,

parameters

[1]

ExternallyDefinedParameters,

size

[2]

INTEGER,

processed

[3]

BOOLEAN DEFAULT FALSE }


- - АТРИБУТЫ ЗАГОЛОВКА

- - Заголовок

heading ATTRIBUTE

WITH ATTRIBUTE-SYNTAX Heading

SINGLE VALUE

: : = id-hat-heading


- - Анализ заголовка

rn-requestors ATTRIBUTE

WITH ATTRIBUTE-SYNTAX ORDescriptor

MATCHES FOR EQUALITY

MULTI VALUE

: : = id-hat-rn-requestors


nrn-requestors ATTRIBUTE

WITH ATTRIBUTE-SYNTAX ORDescriptor

MATCHES FOR EQUALITY

MULTI VALUE

: : = id-hat-nrn-requestors


reply-requestors ATTRIBUTE

WITH ATTRIBUTE-SYNTAX ORDescriptor

MATCHES FOR EQUALITY

MULTI VALUE

: : = id-hat-reply-requestors


- - Поля заголовка

this-ipm ATTRIBUTE

WITH ATTRIBUTE-SYNTAX ThisIPMField

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-hat-this-ipm


originator ATTRIBUTE

WITH ATTRIBUTE-SYNTAX OriginatorFieId

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-hat-originator


replied-to-IPM ATTRIBUTE

WITH ATTRIBUTE-SYNTAX RepIiedToIPMFieId

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-hat-replied-to-IPM


subject ATTRIBUTE

WITH ATTRIBUTE-SYNTAX SubjectField

MATCHES FOR EQUALITY SUBSTRINGS

SINGLE VALUE

: : = id-hat-subject


expiry-time ATTRIBUTE

WITH ATTRIBUTE-SYNTAX ExpiryTimeFieId,

MATCHES FOR EQUALITY ORDERING

SINGLE VALUE

: : = id-hat-expiry-time


reply-time ATTRIBUTE

WITH ATTRIBUTE-SYNTAX ReplyTimeField

MATCHES FOR EQUALITY ORDERING

SINGLE VALUE

: : = id-hat-reply-time


importance ATTRIBUTE

WITH ATTRIBUTE-SYNTAX ImportanceFieId

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-hat-importance


sensitivity ATTRIBUTE

WITH ATTRIBUTE-SYNTAX SensitivityField

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-hat-sensitivity


auto-forwarded ATTRIBUTE

WITH ATTRIBUTE-SYNTAX AutoForwardedField

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-hat-auto-forward


- - Подполя заголовка

authorizing-users ATTRIBUTE

WITH ATTRIBUTE-SYNTAX Authorizing-UsersSubfield

MATCHES FOR EQUALITY

MULTI VALUE

: : = id-hat-authorizing-users


primary-recipients ATTRIBUTE

WITH ATTRIBUTE-SYNTAX PrimaryRecipientsSubfield

MATCHES FOR EQUALITY

MULTI VALUE

: : = id-hat-primary-recipients


copy-reсipients ATTRIBUTE

WITH ATTRIBUTE-SYNTAX CopyRecipientsSubfieId

MATCHES FOR EQUALITY

MULTI VALUE

: : = id-hat-copy-recipients


blind-copy-recipients ATTRIBUTE

WITH ATTRIBUTE-SYNTAX BlindCopyRecipientsSubfieId

MATCHES FOR EQUALITY

MULTI VALUE

: : = id-hat-blind-copy-recipients


obsoIeted-IPMs ATTRIBUTE

WITH ATTRIBUTE-SYNTAX ObsoletedIPMsSubfield

MATCHES FOR EQUALITY

MULTI VALUE

: : = id-hat-obsoleted-IPMs


related-IPMs ATTRIBUTE

WITH ATTRIBUTE-SYNTAX RelatedIPMsSubfield

MATCHES FOR EQUALITY

MULTI VALUE

: : = id-hat-related-IPMs


reply-recipients ATTRIBUTE

WITH ATTRIBUTE-SYNTAX ReplyRecipientsSubfield

MATCHES FOR EQUALITY

MULTI VALUE

: : = id-hat-reply-recipients


- - Расширения заголовка

incomplete-copy ATTRIBUTE

WITH ATTRIBUTE-SYNTAX IncompleteCopy

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-hat-incomplete-copy


languages ATTRIBUTE

WITH ATTRIBUTE-SYNTAX Language

MATCHES FOR EQUALITY

MULTI VALUE

: : = id-hat-languages


- - АТРИБУТЫ ТЕЛА

- - Тело

body ATTRIBUTE

WITH ATTRIBUTE-SYNTAX Body

SINGLE VALUE

: : = id-bat-body


- - Базовые части тела

ia5-text-body-parts ATTRIBUTE

WITH ATTRIBUTE-SYNTAX IA5TextBodyParts

MULTI VALUE

: : = id-bat-ia5-text-body-parts


voice-body-parts ATTRIBUTE

WITH ATTRIBUTE-SYNTAX VoiceBodyPart

MULTI VALUE

: : = id-bat-voice-body-parts


g3-facsimile-body-parts ATTRIBUTE

WITH ATTRIBUTE-SYNTAX G3FacsimileBodyPart

MULTI VALUE

: : = id-bat-g3-facsimile-body-parts


g4-class1-body-parts ATTRIBUTE

WITH ATTRIBUTE-SYNTAX G4Class1BodyPart

MULTI VALUE

: : = id-bat-g4-class1-body-parts


teletex-body-parts ATTRIBUTE

WITH ATTRIBUTE-SYNTAX TeletexBodyPart

MULTI VALUE

: : = id-bat-teletex-body-parts


videotex-body-parts ATTRIBUTE

WITH ATTRIBUTE-SYNTAX VideotexBodyPart

MULTI VALUE

: : = id-bat-videotex-body-parts


encrypted-body-parts ATTRIBUTE

WITH ATTRIBUTE-SYNTAX EncryptedBodyPart

MULTI VALUE

: : = id-bat-encrypted-body-parts


message-body-parts ATTRIBUTE

WITH ATTRIBUTE-SYNTAX SequenceNumber

MULTI VALUE

: : = id-bat-message-body-parts


mixed-mode-body-parts ATTRIBUTE

WITH ATTRIBUTE-SYNTAX MixedModeBodyPart

MULTI VALUE

: : = id-bat-mixed-mode-body-parts


bilaterally-defined-body-parts ATTRIBUTE

WITH ATTRIBUTE-SYNTAX BilaterallyDefinedBodyPart

MULTI VALUE

: : = id-bat-bilaterally-defined-body-parts


nationally-defined-body-parts ATTRIBUTE

WITH ATTRIBUTE-SYNTAX NationallyDefinedBodyPart

MULTI VALUE

: : = id-bat-nationally-defined-body-parts


- - Компонент "параметры базовой части тела"

ia5-text-parameters ATTRIBUTE

WITH ATTRIBUTE-SYNTAX IA5TextParameters

MULTI VALUE

: : = id-bat-ia5-text-parameters


voice-parameters ATTRIBUTE

WITH ATTRIBUTE-SYNTAX VoiceParameters

MULTI VALUE

: : = id-bat-voice-parameters


g3-facsimile-parameters ATTRIBUTE

WITH ATTRIBUTE-SYNTAX G3FacsimileParameters

MULTI VALUE

: : = id-bat-g3-facsimile-parameters


teletex-parameters ATTRIBUTE

WITH ATTRIBUTE-SYNTAX TeletexParameters

MULTI VALUE

: : = id-bat-teletex-parameters


videotex-parameters ATTRIBUTE

WITH ATTRIBUTE-SYNTAX VideotexParameters

MULTI VALUE

: : = id-bat-videotex-parameters


encrypted-parameters ATTRIBUTE

WITH ATTRIBUTE-SYNTAX EncryptedParameters

MULTI VALUE

: : = id-bat-encrypted-parameters


message-parameters ATTRIBUTE

WITH ATTRIBUTE-SYNTAX Message Parameters

MULTI VALUE

: : = id-bat-message-parameters


- - Компоненты "данные базовой части тела"

ia5-data ATTRIBUTE

WITH ATTRIBUTE-SYNTAX IA5TextData

MULTI VALUE

: : = id-bat-ia5-text-data


voice-data ATTRIBUTE

WITH ATTRIBUTE-SYNTAX VoiceData

MULTI VALUE

: : = id-bat-voice-data


g3-facsimile-data ATTRIBUTE

WITH ATTRIBUTE-SYNTAX G3FacsimiIeData

MULTI VALUE

: : = id-bat-g3-facsimile-data


teletex-data ATTRIBUTE

WITH ATTRIBUTE-SYNTAX TeletexData

MULTI VALUE

: : = id-bat-teletex-data


videotex-data ATTRIBUTE

WITH ATTRIBUTE-SYNTAX VideotexData

MULTI VALUE

: : = id-bat-videotex-data


encrypted-data ATTRIBUTE

WITH ATTRIBUTE-SYNTAX EncryptedData

MULTI VALUE

: : = id-bat-encrypted-data


message-data ATTRIBUTE

WITH ATTRIBUTE-SYNTAX MessageData

MULTI VALUE

: : = id-bat-message-data


- - Типы расширенной части тела

extendеd-body-part-types ATTRIBUTE

WITH ATTRIBUTE-SYNTAX OBJECT IDENTIFIER

MATCHES FOR EQUALITY

MULTI VALUE

: : = id-bat-extended-body-part-types


- - Расширенные части тела

- - (Эти атрибуты невозможно пронумеровать, см. С.3.6)

- - АТРИБУТЫ УВЕДОМЛЕНИЯ

- - Общие поля

subject-ipm ATTRIBUTE

WITH ATTRIBUTE-SYNTAX SubjectIPMFieId

MATCHES FOR EQUALITY SUBSTRINGS

SINGLE VALUE

: : = id-nat-subject-ipm


ipn-originator ATTRIBUTE

WITH ATTRIBUTE-SYNTAX IPNOriginatorField

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-nat-ipn-originator


ipm-preferred-recipient ATTRIBUTE

WITH ATTRIBUTE-SYNTAX IPMPreferredRecipientField

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-nat-ipm-preferred-recipient


conversion-eits ATTRIBUTE

WITH ATTRIBUTE-SYNTAX MS-EITs

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-nat-conversion-eits


- - Поля неприема

non-receipt-reason ATTRIBUTE

WITH ATTRIBUTE-SYNTAX NonReceiptReasonField

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-nat-non-receipt-reason


discard-reason ATTRIBUTE

WITH ATTRIBUTE-SYNTAX DiscardReasonField

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-nat-discard-reason


auto-forward-comment ATTRIBUTE

WITH ATTRIBUTE-SYNTAX AutoForwardCommentFieId

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-nat-auto-forward-comment


returned-ipm ATTRIBUTE

WITH ATTRIBUTE-SYNTAX RеturnedIPMField

SINGLE VALUE

: : = id-nat-returned-IPM


- - Поля приема

receipt-time ATTRIBUTE

WITH ATTRIBUTE-SYNTAX ReceiptTimeField

MATCHES FOR EQUALITY ORDERING

SINGLE VALUE

: : = id-nat-receipt-time


aknowledgment-mode ATTRIBUTE

WITH ATTRIBUTE-SYNTAX AcknowledgmentModeField

MATCHES FOR EQUALITY

SINGLE VALUE

: : = id-nat-acknowledgment-mode


suppl-receipt-info ATTRIBUTE

WITH ATTRIBUTE-SYNTAX SupplReceiptInfoField

MATCHES FOR EQUALITY SUBSTRINGS

SINGLE VALUE

: : = id-nat-suppl-receipt-info


END - - атрибутовХранилищаСообщенийСМПС

ПРИЛОЖЕНИЕ К (обязательное). ОПРЕДЕЛЕНИЕ ВЕРХНИХ ГРАНИЦ ДЛЯ СПРАВОЧНЫХ ЦЕЛЕЙ

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


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

IPMSUpperBounds {joint-iso-ccitt

mhs-motis(6) ipms(1) modules(0) upper-bounds(10)}

DEFINITIONS IMPLICIT TAGS : : =

BEGIN

- - Пролог

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

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

- - Верхние границы

ub-auto-forward-comment

INTEGER : : = 256

ub-free-form-name

INTEGER : : = 64

ub-ipm-identifier-suffix

INTEGER : : = 2

ub-local-ipm-identifier

INTEGER : : = 64

ub-subject-field

INTEGER : : = 128

ub-telephone-number

INTEGER : : = 32

END - - верхнихГраницСМПС

ПРИЛОЖЕНИЕ L (обязательное). ОБЕСПЕЧЕНИЕ УСЛУГ МЕЖПЕРСОНАЛЬНЫХ СООБЩЕНИЙ

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


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

С каждым ЭС МПС логически связан один или несколько информационных элементов, которые могут быть представлены в виде компонентов СПС. Информационным элементом, связанным с указанием чувствительности ЭС МПС, является, например, чувствительность поля заголовка. Объекты АП, АТЛМ и МД должны служить для обеспечения конкретного ЭС МПС при отправке и приеме только в том случае, если они предусмотрены при отправке и приеме информационных элементов (см. 22.1 настоящего стандарта), связанных с этим ЭС МПС.

Примечания

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

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

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

L.1 Обеспечение компонентов определителя получателя

Некоторые ЭС МПС реализуются посредством компонентов определителя получателя. ЭС МПС этой категории перечислены в 1-й колонке таблицы L.1. Во 2-й и 3-й колонках идентифицирован компонент определителя получателя, а также конкретное значение этого компонента, который представляет собой информационные элементы, относящиеся к каждому перечисленному ЭС МПС.


Таблица L.1 - Обеспечение компонентов определителя получателя

Элемент службы

Компонент определителя получателя

Значение

1

2

3


Запрос уведомления о неприеме


Запросы-уведомления


унп

Указание запроса уведомления о приеме

Запросы-уведомления

уп

Указание запроса ответа
(см. также таблицу L.2)

Запрошенный-ответ

Истинно


Примечания

1 Определители получателя представлены в виде подполей полей заголовка "основные получатели", "получатели копии" и "получатели слепой копии".

2 Каждый ЭС МПС, кроме "указание запроса ответа", относится только к одной категории. ЭС МПС "указание запроса ответа" относится к двум категориям, как показано в таблице.


L.2 Обеспечение полей заголовка

Некоторые ЭС МПС реализуются посредством полей заголовка. ЭС МПС этой категории перечислены в 1-й колонке таблицы L.2. Во 2-й колонке идентифицированы поля заголовка, которые представляют собой информационные элементы, относящиеся к каждому перечисленному ЭС МПС. В случае поля расширения во 2-й колонке идентифицированы также (в скобках) соответствующие поля расширения.


Таблица L.2 - Обеспечение полей заголовка

Элемент службы

Поле заголовка

1

2

Указание полномочных пользователей

Полномочные пользователи

Указание автопродвижения

Автопродвижение

Указание получателей "слепой" копии

Получатели "слепой" копии

Указание взаимных ссылок

Соответствующие МПС

Указание истечения даты

Истекшее время

Указание важности

Важность

Идентификация МП-сообщения

Данное МПС

Указание некомплектной копии

Расширения (некомплектная копия)

Указание языка

Расширения (языки)

Указание устарелости

Устарелые МПС

Указание отправителя

Отправитель

Указание основных получателей и получателей копии

Основные получатели.

Получатели копии

Указание запроса ответа (см. также таблицу L.3)

Время ответа.

Получатели ответа

Указание МП-сообщений с ответом

Ответ-на МПС

Указание чувствительности

Чувствительность

Указание субъекта

Субъект


Примечание - Каждый ЭС МПС, кроме "указание запроса ответа", относится только к одной категории. ЭС МПС "указание запроса ответа" относится к двум категориям, как показано в таблице.


L.3 Обеспечение аспектов тела

Некоторые ЭС МПС реализуются посредством аспектов тела. ЭС МПС этой категории перечислены в 1-й колонке таблицы L.3. Во 2-й колонке идентифицирован аспект тела, который представляет собой информационный элемент, относящийся к каждому перечисленному ЭС МПС.


Таблица L.3 - Обеспечение аспектов тела

Элемент службы

Поле заголовка

1

2

Указание зашифрованной части тела

Зашифрованная часть тела

Указание продвигаемого МП-сообщения

Часть тела сообщения

Многочастевое тело

Тело, состоящее из двух или более частей

Типизированное тело

Тело (само)


Примечание - Обеспечение ЭС МПС "типизированное тело" свойственно любой реализации любого вторичного объекта.

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

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


В данном приложении перечислены все, кроме чисто стилистических, различия между настоящим стандартом и указанной рекомендацией МККТТ.

Различия следующие:

а) Рекомендация МККТТ, соответствующая настоящему стандарту, не определяет часть тела общего текста, в то время как настоящий стандарт определяет ее.

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

ПРИЛОЖЕНИЕ N (справочное). СВОДНЫЙ ПЕРЕЧЕНЬ ИЗМЕНЕНИЙ СПЕЦИФИКАЦИИ МККТТ 1984

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


В изложении настоящего стандарта имеются существенные отличия от рекомендации Х.420 МККТТ (1984). Однако в техническом отношении отличий немного. В данном приложении перечисляются технические отличия. Приложение должно служить пособием для разработчиков, реализующих положения рекомендации Х.420 МККТТ (1984), позволяя им бросить беглый взгляд на то, каким образом спецификация 1988 может отразиться на их разработке.

Перечисленные ниже существенные изменения, относящиеся к взаимодействию между АП, ХС, АТЛМ и МД, воплощены в настоящей спецификации. Все изменения, кроме изменения по подпункту а, относятся к формату информационных объектов, определенных в настоящее время в модуле АСН.1 "ИнформационныеОбъектыСМПС":

а) Изменен тип содержимого, присвоенный Р2. Если раньше Р2 идентифицировался целым числом 2, то теперь он идентифицируется целым числом 2, либо 22 в зависимости от набора функций, используемых в конкретном сеансе обмена данными посредством СПС (см. 20.2 настоящего стандарта).

б) Отсутствие членов пользователей идентификаторов СМПС теперь отменено.

в) В заголовок дополнительно введены члены расширения. Их ранг является факультативным.

г) Типы "телекс" и "просто форматируемый документ" части тела теперь исключены. (Первый был идентифицирован, но не определен.)

д) К параметрам видеотекса добавлен синтаксический член. Его ранг является факультативным.

е) Наличие члена время-доставки ПараметровСообщения в отсутствие его члена конверт-доставки и наоборот теперь отменено.

ж) К ЧастиТела добавлены двусторонне-определяемый и внешнеопределяемый варианты.

и) Определен общий текст, расширяющий часть тела.

к) Изменены следующие протокольные элементы, определенные в ИСО/МЭК 10021-4 и включенные в число протокольных элементов настоящего стандарта:

I) имяОП;

II) адресОП;

III) конвертДоставкиСообщения;

IV) типыКодированнойИнформации;

V) дополнительнаяИнформация;

л) Спецификация нулевой длины перечисленных ниже типов данных теперь отменена:

I) локальныйИдентификаторМПС;

II) имяСвободнойФормы;

III) телефонныйНомер;

IV) субъектноеПоле;

V) комментарийАвтопродвижения.

ПРИЛОЖЕНИЕ О (справочное). БИБЛИОГРАФИЯ


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


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

Рекомендация Х.420 МККТТ (1988) Системы обработки сообщений. Система межперсональных сообщений

Рекомендация Т.4 (1988) МККТТ Стандартизация факсимильных аппаратов группы 3 для передачи документов

Рекомендация Т.30 (1988) МККТТ Процедура документальной факсимильной передачи по коммутируемой телефонной сети общего пользования

Рекомендация Т.100 (1988) МККТТ Международный обмен информацией для интерактивного видеотекса

Рекомендация Т.101 (1988) МККТТ Международное взаимодействие для служб видеотекса

Рекомендация Т.330 (1988) МККТТ Телематический доступ к СМПС



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