ГОСТ Р ИСО/МЭК 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
     

     
     
     При обнаружении различий в описании АСН.1 и в справочном материале указывается ошибка спецификации.
     
     Заметим, что во всех модулях, которые определены в приложениях согласно таблице 1, теги АСН.1 являются неявными; в этом отношении модуль является определительным.
     
     Примечания
     
     1 Использование АСН.1 для описания класса или части информации само по себе еще не означает, что информация уже передается между открытыми системами. Тот факт, что информация, с помощью которой осуществляется ее описание в АСН.1, и базовые правила кодирования АСН.1 имеют конкретный синтаксис передачи, может не иметь значения. Информация, фактически передаваемая между системами, выполняет такую роль путем ее включения в прикладной протокол.
     
     2 Использование макрокоманд ABSTRACT-OPERATION и ABSTRACT-ERROR, образованных из соответствующих поименованных макрокоманд удаленных операций, не означает, что привлечение абстрактных операций и ошибок и выдача соответствующих отчетов осуществляются через границу между открытыми системами. Тот факт, что абстрактные операции и ошибки посредством их описания фактически могут быть привлечены через СЭУО с использованием этих макрокоманд и при минимальных дополнительных спецификациях, не имеет значения в данном контексте.
     
     
     5.2 Ранги
     
     В настоящем стандарте используется концепция рангов в соответствии с ИСО/МЭК 10021-2.
     
     5.3 Термины
     
     В настоящем стандарте термины выделены полужирным шрифтом, при ссылках на них до определений - курсивом, в остальных случаях написание терминов не выделяется.
     
     Термины, означающие имена собственные, пишутся с прописной буквы, термины общего характера со строчной.
     
     

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

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

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

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

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

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

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

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

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

     
     7.1.1 Идентификатор МПС
     
     Идентификатор МПС представляет собой информационный элемент, который недвусмысленно и однозначно идентифицирует МПС, отличая его от всех других МПС, передаваемых любым пользователем.
     
     IPMIdentifier : : = [APPLICATION 11] SET {
     

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

                  
     Примечание - "11" в идентификаторе МПС - это только тег прикладного масштаба АСН.1, присвоенный настоящим стандартом.
     
     
     7.1.2 Определитель получателя
     
     Определитель получателя - это элемент информации, который идентифицирует получателя МПС (предпочтительного) и который может выдавать ему определенные запросы.
     
     ReciрientSрecifier : : = SET {
     

     Определитель получателя имеет следующие компоненты:
     
     а) получатель (О) - идентифицирует рассматриваемого предпочтительного получателя. Дескриптор О/П.
     
     Если компонент запросы-уведомления или запрошенный-ответ запрашивает предпочтительного получателя, то должен иметь место компонент формальное-имя указанного дескриптора О/П.
     
     б) запросы-уведомления (ПУ без значений) - может выдавать определенные запросы предпочтительному получателю, назначенному принимающим компонентом.
     
     NotificationRequests : : = BIT SDTRING {
     

     
     Этот компонент может предполагать любое из следующих значений одновременно, за исключением того, что значение rn не должно выбираться, если только не выбрано nrn:
     
     I) rn - запрошено уведомление о приеме в ситуации, предписанной в разделе 8.
     
     II) nrn - запрошено уведомление о неприеме в ситуации, предписанной в разделе 8.
     
     III) ipm-return - запрошен возврат МПС в любом уведомлении-о-неприеме.
     
     в) запрошен-ответ (ПУ ложно) - определяет, запрошен ли ответ предпочтительного получателя, назначенного принимающим компонентом. Булево.
     
     Ответ - это одно МПС, посылаемое в ответ на другое МПС. Пользователь может отвечать на МПС даже в том случае, если на него не запрошен ответ и даже если он не относится к предпочтительным получателям МПС. Более того, пользователь, от которого запрошен ответ, может воздержаться от ответа.
     
     7.1.3 Дескриптор О/П
     
     Дескриптор О/П представляет собой информационный элемент, который идентифицирует пользователя или СР.
     
     ORDescriptor : : = SET {
     

     
     Дескриптор О/П имеет следующие компоненты:
     
     а) формальное-имя (У) - идентифицирует рассматриваемого пользователя или СР. Одно из имен О/П.
     
     Этот условный компонент должен иметь место только в том случае, если удовлетворяется один или несколько следующих критериев:
     
     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 {
     

     
     Некоторые поля имеют компоненты и таким образом являются составными, а не неделимыми. Компонент поля называется подполем.
     
     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 {
     

     
     Перечисленные значения не определяются настоящим стандартом; их смысл определяется пользователями.
     
     7.2.15 Чувствительность
     
     Поле заголовка "чувствительность" (У) идентифицирует чувствительность полномочных пользователей к МПС.
     
     SensitivityField : : = ENUMERATED {
     

     
     Это поле может принимать одно из следующих значений:
     
     а) персональная - МПС передается предпочтительным получателям как отдельным лицам, а не их профессиональным возможностям;
     
     б) частная - МПС не должно передаваться никому другому, кроме предпочтительных получателей;
     
     в) конфиденциальная-для-компании - МПС содержит информацию, которая должна быть обработана в соответствии с определенными компанией процедурами.
     
     Это условное поле должно иметь место только в том случае, если МПС является чувствительным.
     
     7.2.16 Автопродвижение
     
     Поле заголовка автопродвижение (ПУ ложно) указывает, является ли МПС результатом автопродвижения. Оно является булевой переменной.
     
     AutoForwardedField : : = BOOLEAN
     
     7.2.17 Расширения
     
     Поле заголовка расширения (ПУ без расширений, т.е. без членов) передает информацию, не сопровождаемую никакими другими полями заголовка. Оно содержит набор расширений заголовка (или расширений) в количестве от нуля до нескольких, каждое из которых переносит один из таких информационных заголовков.
     
     ExtensionsField : : = SET OF HeadingExtension
     
     HeadingExtension : : = SEQUENCE{
     

     
     Каждое расширение имеет следующие компоненты:
     
     а) тип (О) - идентифицирует семантику и ограничивает абстрактный синтаксис компонента значение. Объектный идентификатор.
     
     б) значение (ПУ ноль) - информационный элемент, абстрактный синтаксис которого ограничен только компонентом. Тип "любой".
     
     Компоненты типа всех расширений в поле расширений должны быть различными. Не каждое определенное расширение должно быть представлено в этом поле.
     
     Все расширения определены в приложении А. Таким образом, каждый компонент типа расширения должен иметь одно из значений, приведенных в этом приложении. То расширение, у которого компонент типа имеет другое значение, должно игнорироваться.
     
     Каждое расширение должно определяться с помощью следующих макрокоманд:
     
     HEADING-EXTENSION MACRO : : =
     
     BEGIN
     

                                           
     END
     
     Каждая нотация типа макрокоманды идентифицирует тип данных, для которого компонент "значение" расширения должен быть ограничен. Если ни один из типов в явном виде не определен, предполагается нулевое значение.
     
     Каждая нотация значения макрокоманды идентифицирует объектный идентификатор, который должен быть представлен в виде компонента типа расширения.
     
     Примечание - Последующие версии настоящего стандарта могут определять дополнительные расширения. Более того, будущие версии, видимо, будут дополнять заголовок только с помощью этого поля.
     
     
     7.3 Типы частей тела
     
     Ниже определены и описаны те типы частей тела, которые могут иметь место в теле МПС.
     
     BodyPart : : = CHOICE {
     

     
     Части тела некоторых определенных ниже типов имеют два компонента: параметры и данные. Компонент параметры (О) содержит последовательность информационных элементов, которые описывают те информационные объекты, которые представлены в части тела и которые обычно являются параметрами формата и управления. Компонент данные (О) сам является информационным объектом.
     
     Примечания
     
     1 В Рекомендации Х.420 (1984) МККТТ специфичные-для контекста теги 1 и 10 означают телексные и просто форматируемые части тела документа соответственно, которые не имеют дальнейших определений. Следовательно, эти теги отсутствуют в части тела.
     
     2 В некоторых случаях МПС при прохождении между пользователями может подвергаться преобразованию. Такое событие трансмиттала может изменить тип части тела.
     
     
     7.3.1 Текст МК5
     
     Часть тела текст МК5 представляет текст МК5. Она состоит из параметров и данных.
     
     IA5TextBodyPart : : = SEQUENCE {
     

     
     IA5TextParameters : : = SET {
     

     
     IA5TextData : : = IA5String
     
     Компонент "параметры" содержит следующие параметры:
     
     а) репертуар (ПУ МК5) - идентифицирует набор знаков, которым ограничен компонент "данные".
     
     Repertoire : : = ENUMERATED {
     

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

     II) МК5: Компонент "данные" может быть получен при полном наборе знаков МК.
     
     Компонент "данные" представляет собой текст, строку МК5. Он может иметь строки любой длины. При каждом физическом изображении этого компонента (например, выводе на дисплей или распечатке для пользователя) весь текст (а не только его часть) должен быть взаимосвязан (например, линии могут свертываться, но не должны усекаться).
     
     Примечание - Многие терминалы обеспечивают максимальную длину строки, равную 80 знакам. Следовательно, длина строк не должна превышать этого значения и, скорее всего, их физическое изображение должно быть удовлетворительным (например, скорее всего, свертка строк должна быть исключена).
     
     
     7.3.2 Речь
     
     Часть тела речь представляет собой разговор. Она содержит параметры и данные.
     
     VoiceBodyPart : : = SEQUENCE {
          

    
     VoiceParameters : : = SET--для дальнейшего изучения
     
     VoiceData : : = BIT STRING--для дальнейшего изучения
     
     Параметры такой части тела и те методы кодирования дискретизированных речевых сигналов, которые могут идентифицировать и параметризовать эти параметры, подлежат дальнейшему изучению.
     
     7.3.3 Г3 факсимиле
     
     Часть тела Г3 факсимиле представляет собой изображение группы 3 факсимиле. Она содержит параметры и данные.
     
     G3FacsimileBodyPart : : = SEQUENCE {
     

     
     G3FacsimileParameters : : = SET {
     

     
     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 {
     

     
     TeletexParameters : : = SET {
     

     
     TeletextData : : = SEQUENCE OF TeletexString
     
     Компонент "параметры" содержит следующие параметры:
     
     а) число-страниц (Ф) - идентифицирует число страниц телетексного текста, содержащегося в компоненте "данные". Не-отрицательное целое число.
     
     б) совместимый-с-телексом (ПУ ложно) - определяет, является ли документ в компоненте данные телексно-совместимым. Булева переменная.
     
     Если этот параметр имеет значение истинно, то каждая телексная строка в компоненте "данные" должна быть ограничена набором знаков МТК2. Ни одна строка не должна иметь длину, превышающую 69 знаков.
     
     в) не-базовые параметры (У) - идентифицирует те НБП телетекса, которые характеризуют компонент "данные". Дескриптор телетексных НБП.
     
     Этот условный параметр должен иметь место, если (но не только если) тело содержит две или более частей телетекса.
     
     Компонент "данные" представляет собой документ, последовательность телетексных строк, каждая из которых кодирует одну из его страниц.
     
     Примечания
     
     1 Компонент "число-страниц" идентифицирует число элементов последовательности, которые образуют компонент "данные" и является, таким образом, избыточным.
     
     2 Если тело содержит одну из таких частей, то его НБП может (но не обязательно) передаваться посредством конверта сообщения, содержащего данное МПС.
     
     
     7.3.6 Видеотекс
     
     Часть тела видеотекс представляет собой видеотексные данные. Она содержит параметры и данные.
     
     VideotexBodyPart : : = SEQUENCE {
     

     
     VideotexParameters : : = SET {
     

     
     VideotexData : : = VideotexString
     
     Компонент "параметры" содержит следующие параметры:
     
     а) синтаксис (Ф) - идентифицирует синтаксис компонента "данные". При отсутствии этого параметра синтаксис должен рассматриваться неопределенным.
     
     VideotexSyntax : : = INTEGER {
     

     
     Этот параметр может иметь одно из следующих значений, каждое из которых обозначает, как показано ниже, один из видеотексных синтаксисов, определенных в Рекомендациях Т.100 и Т.101:
     
     I) идс: синтаксис ИДС;
     
     II) синтаксис-данных 1: синтаксис данных 1;
     
     III) синтаксис-данных 2: синтаксис данных 2;
     
     IV) синтаксис-данных 3: синтаксис данных 3.
     
     Компонент "данные" представляет собой видеотексные данные, видеотексную строку. Он должен соответствовать видеотексному синтаксису, обозначенному параметром "синтаксис".
     
     7.3.7 Зашифрованное
     
     Часть тела зашифрованное представляет результат шифрования части тела, тип которой определен настоящим стандартом. Она имеет параметры и данные.
     
     EncryptedBodyPart : : = SEQUENCE {
     

     
     EncryptedParameters : : = SET -- для дальнейшего изучения
     
     EncryptedData : : = BIT STRING -- для дальнейшего изучения
     
     Параметры такой части тела и тот метод шифрования, который может идентифицировать и параметризировать эти параметры, подлежат дальнейшему изучению.
     
     Компонент "данные" представляет собой зашифрованную часть тела, битовую строку. Биты этой битовой строки должны зашифровывать значение данных типа (АСН.1) части тела, закодированной в соответствии с базовыми правилами кодирования ГОСТ 34.974.
     
     7.3.8 Сообщение
     
     Часть тела сообщение представляет собой МПС, а также, факультативно, конверт его доставки. Она имеет параметры и данные.
     
     MessageBodyPart : : = SEQUENCE {
     

     
     MessageParameters : : = SET {

     
     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 {
     

     
     ExternaIlyDefinedParameters : : = EXTERNAL
     
     ExternaIIyDefinedData : : = EXTERNAL
     
     Компоненты "параметры" и "данные" являются внешними (см. раздел 32 ГОСТ 34.973). Должны иметь место те их компоненты, на которые они прямо ссылаются, а компоненты, на которые они ссылаются косвенно, и дескриптор-значения-данных должны отсутствовать.
     
     Основываясь на части тела "внешне определяемые", все типы части тела подразделяются на два следующих важных класса:
     
     а) базовый - разновидность типа части тела, за исключением внешне определяемого. Обозначается целым числом (контекстно-специфицированный тег АСН.1).
     
     Все базовые типы части тела определены в настоящем стандарте;
     
     б) расширенный - некоторые внешне определяемые части тела, ограниченные до какого-нибудь одного значения компонента, на который дана прямая ссылка в компоненте "данные" этой части тела. Обозначается объектным идентификатором.
     
     Некоторые (но не обязательно все) расширенные типы части тела определены в приложении В настоящего стандарта.
     
     Каждый расширенный тип части тела, который определен в настоящем стандарте, определяется с помощью перечисленных ниже макрокоманд. Каждый расширенный тип части тела, где бы он ни определялся, должен определяться точно таким же образом.
     
     EXTENDED-BODY-PART-TYPE MACRO : : =
     
     BEGIN
     

     
     END
     
     Пример нотации типа макрокоманды определяет посредством его раздела ПАРАМЕТРЫ тип значения данных, который представлен компонентом "параметры" такой (внешне определенной) части тела (внешней), и объектный идентификатор, который представлен в компоненте "прямая-ссылка" этого компонента "параметры". Отсутствие компонента "параметры" предполагается отсутствием такого раздела. Пример нотации типа определяет также посредством его раздела ДАННЫЕ тип значения данных, представленных компонентом "данные" такой части тела (внешней).
     
     Пример нотации значения макрокоманды определяет объектный идентификатор, представленный в виде компонента "прямая ссылка" компонента "данные" такой (внешне определенной) части тела. Объектный идентификатор определяет правила кодирования части тела. Те части тела, типы которых определяет настоящий стандарт, должны кодироваться с использованием базовых правил кодирования АСН.1.
     
     Примечания
     
     1 Внешне определяемая часть тела позволяет обмениваться информацией объектам всех видов, каждый из которых однозначно и недвусмысленно идентифицирован. Эта идентификация полагается на указанный выше компонент "прямая ссылка", который представляет собой объектный идентификатор. Объектные идентификаторы можно легко получить, например, национальным комитетам или частным организациям.
     
     2 Если внешне определяемая часть тела имеет компонент "параметры", то объектный идентификатор в его компоненте "прямая-ссылка" размещается в то же время и тем же уполномоченным по присвоению имен, что и компонент "прямая-ссылка" компонента "данные".
     
     3 Подобно частям тела других типов внешне определяемая часть тела может подвергаться преобразованиям. Однако спецификация алгоритмов преобразования не входит в предмет рассмотрения рекомендации Х.408.
     
     4 Базовая часть тела существует только по чисто историческим причинам, хронологически предшествуя внешне определяемому типу части тела.
     
     

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

     
     Межперсональное уведомление (МПУ) - это представитель информационных объектов вторичного класса, передаваемых между пользователями системы межперсональных сообщений.
     
IPN : : = SET {
     
     -- общие поля -- COMPONENTS OF Commonfields,
     
     choice [0] CHOICE {
     

     
     МПУ может принимать одну из следующих форм:
     
     а) уведомление о неприеме (УНП) - МПУ, в котором отправителю сообщается о безуспешности получения, приема или о задержке приема МПС.
     
     NRN : : = IPN -- с выбранными полями неприема
     
     б) уведомление о приеме (УП) - МПУ, в котором отправителю сообщается о приеме МПС.
     
     RN : : = INP -- с выбранными полями приема
     
     МПС, на который ссылается МПУ, называется субъектным МПС. Только тот АП, которому фактически доставлено субъектное МПС, должен выдать относящееся к нему МПУ и только одно такое МПУ, которое должно быть передано только отправителю субъектного МПС.
     
     Фактический получатель должен инициировать МПУ только в соответствии с компонентом определителя субъектного получателя "запросы уведомления". Определитель субъектного получателя - это такой определитель в заголовке субъектного МПС, в соответствии с которым субъектное МПС доставлено данному пользователю.
     
     Определитель субъектного получателя определяется путем анализа последовательностей определителей получателя, которые образуют поля заголовка "получатели основного сообщения", "получатели копии сообщения" и "получатели слепой копии". Эти поля анализируются в той последовательности, в которой они перечислены в предыдущем предложении. Внутри каждого поля определители анализируются в той последовательности, в которой они там расположены. Определитель субъектного получателя является первым определителем, у которого компонент "получатель" имеет в качестве своего значения тот дескриптор О/П, который содержит компонент формальное-имя, имеющий в качестве своего значения либо имя О/П предпочтительного получателя, в результате чего субъектное МПС было доставлено тому пользователю, по поручению которого проводится этот анализ.
     
     МПУ содержит набор информационных элементов, называемых полями уведомления (или полями), каждый из которых относится к одному из следующих классов:
     
     а) общее поле - поле уведомления, применимое и к УНП и к УП;
     
     б) поле неприема - поле уведомления, применимое только к УНП;
     

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

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

     
     Ниже определены поля каждого из описанных классов, которые могут иметь место в МПУ.
     
     8.1 Общие поля
     
     Общие поля определены и описаны ниже.
     
     Commonfields : : = SET {
     

     
     8.1.1 Субъектное МПС
     
     Общее поле субъектное МПС (О) идентифицирует субъектное МПС. Оно содержит идентификатор МПС.
     
     SubjectIPMField : : = IPMIdentifier
     
     8.1.2 Отправитель МПУ
     
     Общее поле отправитель МПУ (Ф) идентифицирует отправителя МПУ. Оно содержит дескриптор ОП.
     
     IPNOriginatorField : : = ORDescriptor
     
     Если отправителем МПУ является предпочтительный получатель субъектного МПС, то указанный выше дескриптор ОП должен быть точно таким же, как и значение компонента "получатель" определителя субъектного получателя.
     
     8.1.3 Предпочтительный получатель МПС
     
     Общее поле предпочтительный получатель МПС (У) идентифицирует предпочтительного получателя субъектного МПС, который после операции доставки стал отправителем МПУ (альтернативный, член (СР) или заменитель получателя). Он содержит дескриптор ОП.
     
     IPMPreferredRecipientsField : : ORDescriptor
     
     Указанный выше дескриптор ОП должен быть точно таким же, как и значение компонента "получатель" определителя субъектного получателя.
     
     Это условное поле должно иметь место только в том случае, если оно может идентифицировать пользователя, не являющегося отправителем МПУ или СР.
     
     8.1.4 Преобразуемые ТКИ
     
     Общее поле преобразуемые ТКИ (У) идентифицирует ТКИ субъектного МПС при доставке отправителю МПУ. Оно содержит дескриптор ТКИ.
     
     ConversionEITsFieId : : = EncodedInformationTypes
     
     Это условное поле должно иметь место только в том случае, если МПС подверглось преобразованию при доставке отправителю МПУ.
     
     8.2 Поля неприема
     
     Поля неприема определены и описаны ниже.
     
     NonReceiptFields : : = SET {
     

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

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

     
     Это поле может принимать одно из следующих значений:
     
     а) мпс-истекло - действовало автоаннулирование, истекшие МПС были аннулированы и достигнуто время, идентифицированное полем заголовка "время субъектного МПС истекло".
     
     б) мпс-устарело - действовало автоаннулирование, устаревшие МПС были аннулированы и поле заголовка "устаревшие МПС" другого МПС, доставленное отправителю УНП, идентифицирует субъектное МПС.
     
     в) абонирование-пользователя-закончилось - абонирование межперсональных сообщений отправителем УНП закончилось.
     
     Это условное поле должно иметь место только в том случае, если поле "причина неприема" имеет значение мпс-аннулировано.
     
     8.2.3 Комментарий автопродвижения
     
     Поле неприема комментарий автопродвижения (У) представляет собой информацию, предварительно представленную для этой цели отправителем УНП. Оно содержит распечатываемую строку. Нулевая длина нежелательна.
     
     AutoForwardCommentField : : = AutoForwardComment
     
     AutoForwardComment : : = PrintableString
     
     (SIZE (0 . . ub-auto-forward-comment))
     
     Это поле должно иметь точно такое же значение, что и аргумент комментарий-автопродвижения абстрактной операции изменение автопродвижения, в результате которой субъектное МПС автоматически продвинулось.
     
     Это условное поле должно иметь место только в том случае, если поле "причина неприема" имеет значение автопродвижение-МПС и обеспечен аргумент "комментарий автопродвижения".
     
     8.2.4 Возвращенное МПС
     
     Поле неприема возвращенное МПС (У) представляет собой в точности субъектное МПС.
     
     ReturnedIPMField : : = IPM
     
     Это условное поле должно иметь место только в том случае, если среди значений компонента "запросы-уведомления" определителя субъектного получателя имеется значение возврат-МПС и если субъектное МПС не подверглось преобразованию при доставке отправителю УНП.
     
     8.3 Поля приема
     
     Поля приема определены и описаны ниже.
     
     ReceiрtField : : = SET {
     

     
     8.3.1 Время приема
     
     Поле приема время приема (О) определяет, когда отправитель УП получил субъектное МПС. Оно содержит дату и время.
     
     ReceiptTimeField : : = Time
     
     8.3.2 Режим подтверждения
     
     Поле приема режим подтверждения (ПУ ручной) определяет способ, которым было выдано УП.
     
     AcknowledgmentModeField : : = ENUMERATED {
     

     
     Это поле может принимать одно из следующих значений:
     
     а) ручной - УП было отправлено с помощью абстрактной операции отправка УП.
     
     б) автоматический - УП было отправлено в результате автоподтверждения.
     
     8.3.3 Дополнительная информация о приеме
     
     Поле приема дополнительная информация о приеме (Ф) содержит дополнительную информацию о приеме субъектного МПС отправителем УП. Оно содержит распечатываемую строку.
     
     SupplReceiptInfoField : : = Supplelementarylnformation
     
     

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

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

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

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

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

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

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

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

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

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

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

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

     
     Первичные объекты межперсональных сообщений объединены и взаимодействуют друг с другом с помощью портов. Эти порты, которые обеспечиваются СМПС, называются первичными портами межперсональных сообщений. Они подразделяются на три определяемых ниже типа.
     
     Примечание - В разделе 16 СМПС подразделяется на еще более мелкие объекты, к числу которых относится СПС. В данном разделе некоторые возможности СПС включены в набор абстрактных услуг СМПС.
     
     
     11.1 Отправка
     
     Порт отправки представляет собой средство, с помощью которого отдельный пользователь переносит в СМПС сообщения, содержащие информационные объекты, типы которых определены во второй главе. Через такой порт пользователь определяет межперсональные сообщения и уведомления о приеме. Кроме того, пользователь может отправлять через такой порт зонды.
     
     СМПС обеспечивает по одному порту отправки на каждого пользователя (за исключением косвенных пользователей, обслуживаемых МДФД; см.16.5).
     
     11.2 Прием
     
     Порт приема представляет собой средство, с помощью которого СМПС переносит отдельному пользователю сообщения, содержащие информационные объекты, типы которых определены во второй главе. Через такой порт пользователь получает межперсональные сообщения и межперсональные уведомления. Кроме того, через такой порт пользователь может получать отчеты.
     
     СМПС обеспечивает по одному порту приема на каждого пользователя.
     
     11.3 Административное управление
     
     Административный порт представляет собой средство, с помощью которого отдельный пользователь обменивается с СМПС информацией о самом себе в виде файлов. С помощью такого порта пользователь активизирует и деактивизирует автоаннулирование, автоподтверждение и автопродвижение.
     
     СМПС обеспечивает по одному административному порту на каждого пользователя (за исключением косвенных пользователей, обслуживаемых МДФД; см.16.5).
     
     

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

     
     Абстрактные услуги СМПС представляют собой набор возможностей, которые СМПС обеспечивает каждому пользователю с помощью одного порта отправки, одного порта приема и одного административного порта. Эти возможности моделируются в виде абстрактных операций, при привлечении которых могут возникнуть абстрактные ошибки.
     
     Ниже описываются абстрактные операции, имеющие место в портах отправки, приема и административном соответственно. Абстрактные ошибки, которые они могут обусловливать, рассматриваются в разделе 13.
     
     Примечания
     
     1 Абстрактные услуги СМПС не привлекают операций абстрактной связки и абстрактной развязки.
     
     2 СМПС аутентифицирует (т.е. устанавливает подлинность) типичного пользователя перед тем, как предоставить ему абстрактную услугу СМПС. Этим способом она может подтвердить, например, что пользователем является абонент СМПС. Аутентификация, при ее необходимости, является, скорее, явной, чем неявной при определении абстрактных услуг СМПС.
     
     3 Цель определения абстрактных услуг СМПС состоит не в том, чтобы предписать пользовательские интерфейсы реализации частей СМПС, а скорее, для пояснения смысла и целевого использования информационных объектов, рассматриваемых во второй главе. Пользовательский интерфейс не должен обеспечивать команды однозначного соответствия абстрактным операциям этих услуг и даже не ставит своей целью распределить работу между пользователем и СМПС, как это делают услуги. Также модель определения абстрактных услуг не предусматривает возможности, предоставляемые хранилищем сообщений.
     
     4 В разделе 16 проводится разложение СМПС на объекты, к числу которых относится СПС. В данном подразделе этот факт отражен включением различных определяемых СПС информационных элементов в состав абстрактных услуг СМПС.
     
     
     12.1 Абстрактные операции отправки
     
     Абстрактные операции, доступные в порту отправки, привлекаются пользователем и выполняются СМПС.
     
     origination PORT
     

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

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

     2) время-предоставления (О) - дата и время непосредственного предоставления зонда.
     
     12.1.2 Отправка МПС
     
     Абстрактная операция отправка МПС осуществляет отправку сообщения, содержимым которого является МПС.
     
     OriginateIPM : : = ABSTRACT-OPERATION
     

     
     Эта абстрактная операция имеет следующие аргументы:
     
     а) конверт (О) - конверт предоставления сообщения, структуру которого определяет абстрактная услуга СПС. АП обеспечивает все компоненты конверта, кроме перечисленных ниже, которые обеспечивает пользователь:
     
     I) Желательные факультативные возможности на-сообщение (т.е. приоритет, указатели на-сообщение, время задержанной доставки и расширения).
     
     II) Имена O/П предпочтительных получателей и факультативных возможностей на-получателя (т.е. запрос отчета отправителя, явное преобразование и расширения), требуемых для каждого.

     б) содержимое (О) - отправляемое МПС. Поле заголовка его автопродвижения должно отсутствовать или иметь значение ложно.
     
     Эта абстрактная операция имеет следующие результаты:
     
     1) идентификатор-предоставления (О) - идентификатор предоставления сообщения, который СПС присваивает предоставлению;
     
     2) время-предоставления (О) - дата и время непосредственного предоставления сообщения.
     
     12.1.3 Отправка УП
     
     Абстрактная операция отправка УП отправляет сообщение, содержимым которого является УП.
     
     OriginateRN : : = ABSTRACT-OPERATION
     

     
     УП должно отправляться только фактическим получателем субъектного МПС, от которого запрошено УП посредством компонента запросы-уведомления определителя субъектного получателя субъектного МПС.
     
     Пользователь не должен получать ранее отправленное УП в ответ на субъектное МПС посредством либо текущей абстрактной операции, либо автоподтверждения.
     
     Эта абстрактная операция имеет следующие аргументы:
     
     а) конверт (О) - конверт предоставления сообщения, передачу которого определяет абстрактная услуга СПС. АП обеспечивает все компоненты конверта, кроме перечисленных ниже, которые обеспечивает пользователь:
     
     I) Желательные факультативные возможности на-сообщение (т.е. приоритет, указатели на-сообщение и расширения). Неявное преобразование должно быть запрещено с приоритетом субъектного МПС.
     
     II) Имена О/П предпочтительных получателей и факультативные возможности на-получателя (т.е. неявное преобразование и расширения), требуемые для каждого. Отчеты не должны запрашиваться.
     
     б) содержимое (О) - отправляемое УП.
     
     Эта абстрактная операция имеет следующие результаты:
     
     1) идентификатор-предоставления (О) - идентификатор предоставления сообщения, который СПС присваивает данному предоставлению;
     
     2) время-предоставления (О) - дата и время непосредственного предоставления сообщения.
     
     12.2 Абстрактные операции приема
     
     Абстрактные операции, доступные в порту приема, привлекаются СМПС и выполняются пользователем.
     
     reception PORT
     

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

     
     Принятый отчет может относиться к любому из следующих объектов, ранее отправленных получателями отчета:
     
     а) зонд, относящийся к сообщению, содержимым которого было МПС, отправленное абстрактной операцией "отправка зонда";
     
     б) сообщение, содержимым которого было УНП, отправленное в результате автоаннулирования или автопродвижения;
     
     в) сообщение, содержимым которого было УП, отправленное абстрактной операцией "отправка УП" или автоподтверждением.
     
     г) сообщение, содержимым которого было МПС, отправленное абстрактной операцией "отправка МПС" или автопродвижение.
     
     Эта абстрактная операция имеет следующие аргументы:
     
     1) конверт (О) - конверт доставки отчета, структура которого определяет абстрактную услугу СПС;
     
     2) недоставленный объект (У) - содержимое сообщения, о статусе которого выдается отчет МПС или МПУ.
     
     Если отчет был обусловлен предыдущим привлечением абстрактной операции "отправка зонда", этот условный аргумент должен отсутствовать. Если отчет был обусловлен предыдущим привлечением абстрактной операции "отправка МПС", этот аргумент должен иметь место только в том случае, если возврат содержимого был запрошен. В противном случае (т.е. если отчет был обусловлен МПУ) этот аргумент должен отсутствовать.
     
     Эта абстрактная операция не имеет результатов.
     
     12.2.2 Прием МПС
     
     Абстрактная операция прием МПС принимает сообщение, содержимым которого является МПС.
     
     ReceiveIPM : : = ABSTRACT-OPERATION
     

     
     Эта абстрактная операция имеет следующие аргументы:
     
     а) конверт (О) - конверт доставки сообщения;
     
     б) содержимое (О) - МПС, которое является содержимым сообщения.
     
     Эта абстрактная операция не имеет результатов.
     
     12.2.3 Прием УП
     
     Абстрактная операция прием УП принимает сообщение, содержимым которого является УП. Это УП обусловлено отправкой МПС посредством абстрактной операции отправка МПС.
     
     ReceiveRN : : = ABSTRACT-OPERATION
     

     
     Эта абстрактная операция имеет следующие аргументы:
     
     а) конверт (О) - конверт доставки сообщения;
     
     б) содержимое (О) - УП, которое является содержимым сообщения.
     
     Эта абстрактная операция не имеет результатов.
     
     12.2.4 Прием УНП
     
     Абстрактная операция прием УНП принимает сообщение, содержимым которого является УНП. Это УНП обусловлено отправкой МПС посредством абстрактной операции "отправка МПС".
     
     ReceiveNRN : : = ABSTRACT-OPERATION
     

     
     Эта абстрактная операция имеет следующие аргументы:
     
     а) конверт (О) - конверт доставки сообщения;
     
     б) содержимое (О) - УНП, которое является содержимым сообщения.
     
     Эта абстрактная операция не имеет результатов.
     
     12.3 Абстрактные операции управления
     
     Эти абстрактные операции, доступные в порту управления, привлекаются пользователем и выполняются СМПС.
     
     management PORT
     

     
     : : = id-pt-management
     
     12.3.1 Изменение автоаннулирования
     
     Абстрактная операция изменение автоаннулирования активизирует или деактивизирует автоаннулирование, когда СМПС автоматически аннулирует истекшие или устаревшие МПС, которые доставлены, но еще не приняты пользователем.
     
     ChangeAutoDiscard : : = ABSTRACT-OPERATION
     

     
     При автоаннулировании МПС СМПС отправляет от имени пользователя УНП только в том случае, если уведомление запрошено им с помощью компонента запросы-уведомления определителя субъектного получателя.
     
     Эта абстрактная операция имеет следующие результаты:
     
     а) автоаннулирование-истекших-МПС (О) - следует или нет аннулировать истекшее МПС; булева переменная;
     
     б) аннулирование-устаревших-МПС (О) - следует или нет аннулировать устаревшее МПС; булева переменная.
     
     Эта абстрактная операция не имеет результатов.
     
     12.3.2 Изменение автоподтверждения
     
     Абстрактная операция изменение автоподтверждения активизирует или деактивизирует автоподтверждение - автоматическую отправку УП системой СМПС по поручению пользователя. Такая отправка происходит при доставке МПС, которая запрашивает выдать УП посредством компонентов запросы-уведомления их определителей субъектного получателя.
     
     ChangeAutoAcknowledgment : : = ABSTRACT-OPERATION
     

     
     Эта абстрактная операция имеет следующие аргументы:
     
     а) автоподтверждение-МПС (О) - следует или нет автоматически подтверждать МПС; булева переменная;
     
     б) автоподтверждение-обеспеченной-информации-о-приеме (У) - поле приема "обеспеченная-информация-о-приеме" каждого УП, обусловленного автоподтверждением.
     
     Этот условный аргумент должен иметь место только в том случае, если аргумент автоподтверждение-МПС имеет значение истинно.
     
     Эта абстрактная операция не имеет результатов.
     
     12.3.3 Изменение автопродвижения
     
     Абстрактная операция изменение автопродвижения активизирует или деактивизирует автопродвижение - автоматическое продвижение МПС системой СМПС к заранее определенным пользователям или СР. Такое продвижение имеет место при доставке МПС.
     
     ChangeAutoForwarding : : = ABSTRACT-OPERATION
     

     
     Тело каждого МПС, которое СМПС отправляет в результате автопродвижения, содержит одну часть тела типа сообщения. Содержимое сообщения, представленное этой частью тела, является продвигаемым МПС.
     
     Когда СМПС продвигает МПС, она отправляет УНП от имени пользователя только в том случае, если уведомление было запрошено им посредством компонента запросы-уведомления определителя субъектного получателя.
     
     Эта абстрактная операция имеет следующие параметры:
     
     а) автопродвижение-МПС (О) - следует ли подвергать МПС автопродвижению; булева переменная;
     
     б) получатели-автопродвижения (У) - пользователи или СР, к которым должны автоматически продвигаться МПС; последовательность имен О/П.
     
     Этот условный аргумент должен иметь место только в том случае, если аргумент "автопродвижение МПС" имеет значение истинно.
     
     в) заголовок-автопродвижения (У) - заголовок, который должен использоваться для каждого автоматически продвигаемого МПС; его поле "заголовок автопродвижения" должно иметь значение истинно;
     
     Этот условный аргумент должен иметь место только в том случае, если аргумент "автопродвижение МПС" имеет значение истинно.
     
     г) комментарий-автопродвижения (У) - значение, которое должно обеспечиваться как поле неприема "комментарий автопродвижения" каждого УНП, передаваемого отправителю автоматически продвинутого МПС.
     
     Этот условный аргумент должен иметь место только в том случае, если аргумент "автопродвижение МПС" имеет значение истинно.
     
     Эта абстрактная операция не имеет результатов.
     
     Примечание - Назначение этой абстрактной операции - определить сущность автопродвижения, уточненные возможности автопродвижения, например, подобные ХС.
     
     

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

     
     Абстрактные ошибки, которые могут выдаваться в ответ на привлечение абстрактных операций, доступных в портах отправки приема и административном, определены и описаны ниже как часть определения абстрактных услуг СПС.
     
     Примечание - Приводимое ниже описание набора абстрактных ошибок является, скорее, иллюстративным, чем исчерпывающим.
     
     
     13.1 Ошибка абонирования
     
     Абстрактная ошибка ошибка абонирования сообщает, что пользователь не абонирован для одного или нескольких элементов услуги, предполагавшихся при привлечении им абстрактной операции, выполнение которой было прервано.
     
     SubscriptionError : : = ABSTRACT-ERROR     
          

                                                   
     Эта абстрактная ошибка имеет следующие параметры:
     
     а) проблема (О) - возникла проблема, связанная с абонированием.
     
     SubcriptionProblem : : = ENUMERATED {
     

     
     Этот параметр может принимать одно из следующих значений:
     
     I) эс-СМПС-не-абонирован - элемент службы СМПС не абонирован.
     
     II) эс-СПС-не-абонирован - элемент службы СПС не абонирован.
     
     13.2 Неправильно определен получатель

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

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

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

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

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

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

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

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

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

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

     
     
     Ниже определены и описаны эти вторичные типы объектов. Типы портов, через которые они взаимодействуют, рассмотрены в разделе 17.
     
     Примечания
     
     1 Приведенная выше детализация охватывает всевозможные взаимосвязи всех возможных объектов. В ней игнорируется возможное отсутствие объектов конкретного типа (например, МДФД) и конкретные логические конфигурации ХС СМПС. Последние определены в ИСО/МЭК 10021-2.
     
     2 Рекомендация Т.330 эффективно распространяет абстрактные услуги системы межперсональных сообщений на определяемые ею смешанные порты, не показанные на рисунке 4. См. примечание в 16.3.
     
     3 СМПС обеспечивает порты импорта и экспорта. Однако поскольку эти порты формально не определены в ИСО/МЭК 10021-4, они не включены в приведенную выше формальную детализацию.
     
     
     16.1 Агент пользователя системы межперсональных сообщений
     
     Агент пользователя системы межперсональных сообщений (АП СМПС) - это АП, организованный таким образом, чтобы наилучшим образом помогать отдельному пользователю участвовать в передаче межперсональных сообщений. Он помогает ему при отправке и приеме либо при отправке и приеме сообщений, содержащих информационные объекты, типы которых определены во второй главе.
     
     ipms-ua OBJECTS
     

     
     : : = id-ot-ipms-ua
     
     СМПС может содержать любое количество АП СМПС.
     
     Примечание - Далее в настоящем стандарте вместо "АП СМПС" для краткости используется термин "АП".
     
     
     16.2 Хранилище сообщений системы межперсональных сообщений
     
     Хранилище сообщений системы межперсональных сообщений (ХС СМПС) представляет собой ХС, организованное так, чтобы наилучшим образом помогать отдельному АП участвовать в обмене межперсональных сообщений. Оно помогает ему в предоставлении, в доставке либо в предоставлении и доставке сообщений, содержащих информационные объекты, типы которых определены во второй главе.
     
     ipms-ms OBJECT
     

     
     : : = id-ot-ipms-ms
     
     СМПС может содержать любое число ХС СМПС.
     
     Примечание - Далее в настоящем стандарте вместо термина "ХС СМПС" для краткости используется термин "ХС".
     
     
     16.3 Агент телематической службы
     
     Агент телематической службы (АТЛМ) представляет собой АП, который помогает отдельному косвенному пользователю участвовать в передаче межперсональных сообщений из телематического оконечного оборудования вместе с этим оконечным оборудованием и сетью, которая соединяет то и другое. АТЛМ помогает пользователю отправлять, принимать либо отправлять и принимать сообщения, содержащие информационные объекты, типы которых определены во второй главе.
     
     tlma OBJECT
     

     
     : : = id-ot-tlma
     
     СМПС может содержать любое число АТЛМ.
     
     Примечания
     
     1 АТЛМ использует порты импорта и экспорта. Поскольку оба эти вида портов формально не определены в ИСО/МЭК 10021-4, они не включены в приведенное выше формальное определение АТЛМ.
     
     2 Комбинированный порт АТЛМ определен в рекомендации Т.330 МККТТ. В своем общем виде, рассматриваемом в настоящем стандарте, он не является частью абстрактных услуг СМПС. Он, скорее, воплощает возможности, доступные только для пользователя АТЛМ. По этой причине далее в настоящем стандарте он более не рассматривается и не включен в формализованное уточнение СМПС, приведенное в разделе 16.
     
     
     16.4 Телексный модуль доступа
     
     Телексный модуль доступа (МДТЛК) представляет собой МД, который помогает любому числу косвенных пользователей участвовать в передаче межперсональных сообщений из телексного оконечного оборудования. Он помогает им отправлять, получать либо отправлять и получать сообщения, содержащие объекты, типы которых определены во второй главе.
     
     tlхau OBJECT
     

     
     : : = id-ot-tlxau
     
     СМПС может содержать любое число МДТЛК.
     
     Примечание - МДТЛК содержит порты импорта и экспорта. Поскольку они формально не определены в ИСО/МЭК 10021-4, они не включены в приведенное выше формальное определение МДТЛК.
     
     
     16.5 Модуль доступа физической доставки
     
     В данном контексте МДФД помогает любому числу косвенных пользователей участвовать в передаче межперсональных сообщений через СФД. Он помогает им принимать (но не отправлять) сообщения, содержащие информационные объекты, типы которых определены во второй главе.     
          pdau OBJECT
     

     
     : : = 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
     

          
     Кроме того, ХС должно удовлетворять следующим требованиям:
     
     а) предоставлять УНП, даже если оно хранит копию продвигаемого МПС;
     
     б) извлекать поле "комментарий автопродвижения" (при его наличии) из компонента другие-параметры;
     
     в) извлекать покрывающие-записи (при их наличии) для включения в продвигаемое МПС из компонента другие-параметры;
     
     г) формировать префикс к компоненту идентификатор-соответствующего-пользователя данного поля МПС заголовка продвигаемого МПС в форме префикс-данного-мпс (при его наличии).
     
     Примечание - ХС (СМПС) не выполняет ни автоаннулирование, ни автопродвижение, кроме как в рамках локального решения.
     
     
     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 - Базовые ТКИ и НБП межперсональных сообщений
     

     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
     

          
     Если это расширение отсутствует в поле заголовка расширения, следует считать, что все части тела присутствуют.
     
     А.2 Языки
     
     Расширение заголовка языки идентифицирует языки, используемые в сочетании поля и тела заголовка объекта МПС. Это расширение состоит из набора (от нуля до нескольких) распечатываемых строк, каждая из которых составлена двузначным языковым кодом, определенным в ИСО 639.
     
     languages HEADING-EXTENSION
     

     
     Language : : = PrintableString (SIZE (2 . . 2))
     
     Если это расширение отсутствует в поле заголовка расширений или не указаны никакие другие языки, эти языки должны рассматриваться как неспецифицированные.
     
     

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

     
РАСШИРЕННЫЕ ТИПЫ ЧАСТИ ТЕЛА

     
     Данное приложение определяет ряд расширенных типов части тела. Некоторые являются эквивалентными по отношению к типам базовой части тела.
     
     B.1 Эквиваленты типов базовой части тела
     
     Для каждого типа базовой части тела настоящий стандарт определяет следующим образом эквивалентный тип расширенной части тела.
     
     ia5-text-body-part EXTENDED-BODY-PART-TYPE        
     

    
     voice-body-part EXTENDED-BODY-PART-TYPE     
     

     
     g3-facsimile-body-part EXTENDED-BODY-PART-TYPE     
     

     
     g4-classl-body-part EXTENDED-BODY-PART-TYPE
     

     
     teletex-body-part EXTENDED-BODY-PART-TYPE     
     

     
     videotex-body-part EXTENDED-BODY-PART-TYPE          
     

     
     encrypted-body-part EXTENDED-BODY-PART-TYPE    
     

    
     message-body-part EXTENDED-BODY-PART-TYPE     
     

    
     mixed-mode-body-part EXTENDED-BODY-PART-TYPE
     

     
     bilaterally-defined-body-part EXTENDED-BODY-PART-TYPE
     

     
     nationally-defined-body-part EXTENDED-BODY-PART-TYPE
     

          
     B.2 Общий текст
     
     Общий текст, расширяющий часть тела, представляет собой символический текст общего характера. Он включает компонент "параметры" и компонент "данные".
     
     general-tеxt-body-part EXTENDED-BODY-PART-TYPE          
     

    
     : : = id-еt-general-text
     
     GeneralTextParameters : : = SET {
     

     
     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 - Сводный перечень атрибутов ХС
     

     
     
     C.1 Суммарные атрибуты
     
     Некоторые атрибуты содержат суммарный перечень информационных объектов межперсональных сообщений. Эти атрибуты определены и описаны ниже.
     
     C.1.1 Тип элемента МПС
     
     Атрибут тип элемента МПС идентифицирует тип информационного объекта.
     
     ipm-empty-type ATTRIBUTE
     

                 
     IPMEntryType : : = ENUMERATED {
     

     
     Тип элемента МПС может принимать одно из следующих значений:
     
     а) мпс - информационным объектом является МПС;
     
     б) уп - информационным объектом является УП;
     
     в) унп - информационным объектом является УНП.
     
     ХС, обеспечивающее эти атрибуты, должно поддерживать их для хранимого у себя информационного объекта только в том случае, если этот объект является сообщением, содержимым которого является МПС или МПУ.
     
     С.1.2 Конспект МПС
     
     Атрибут конспект МПС обеспечивает структуру, характеристики, размер и статус обработки МПС на уровне отдельных частей тела.
     
     ipm-synopsis ATTRIBUTE
     

     
     Конспект МПС содержит конспект каждой из его частей тела. Эти конспекты введены в той последовательности, в которой представлены части тела.
     
     IPMSynopsis : : = SEQUENCE OF BodyPartSynopsis
     
     Конспект части тела принимает одну из двух форм в зависимости от того, является ли эта часть тела сообщением данного типа. Это позволяет охватить конспектом продвигаемого МПС части тела каждого продвинутого СПС (рекурсивно), а также части тела самого продвигаемого СПС.
     
     BodyPartSynopsis : : = CHOICE {
     

     
     MessfgeBodyPartSynopsis : : = SEQUENCE {
     

     
     NonMessageBodyPartSynopsis : : = SEQUENCE {
     

     
     Конспект части тела сообщения имеет следующие компоненты:
     
     а) номер (О) - порядковый номер, который ХС назначило элементу, представляющему данную часть тела сообщения;
     
     б) конспект (О) - конспект МПС, формирующий содержимое сообщения, которое представляет данная часть тела.
     
     Конспект части тела, тип которого отличается от типа сообщения, имеет следующие компоненты (считается, что при таком конспекте данная часть тела должна относиться к внешне определяемому типу независимо от того, передается она в таком виде в ХС или нет; см. приложение В):
     
     а) тип (О) - часть тела расширенного типа, т.е. компонент "непосредственная-ссылка" компонента "данные" части тела.
     
     б) параметры (О) - формат и параметры управления части тела, т.е. компонент "параметры" части тела. Любое значение.
     
     в) размер (О) - длина в октетах кода компонента "код" компонента "данные" части тела при соблюдении базовых правил кодирования ГОСТ 34.974. Если эти правила допускают несколько кодов компонента (например, элементарный и сложный), размер может отражать любой из них. Целое число.
     
     г) обработано (ПУ ложно) - указывают, переносится или нет часть тела к АП посредством абстрактной операции ХС "перечисление" или "извлечение". Булево значение.
     
     ХС, обеспечивающее этот атрибут, должно поддерживать его для хранимого у него информационного объекта только в том случае, если этот объект является сообщением, содержимым которого является МПС.
     
     Примечание - Как следствие этой изменяемости значение компонента "размер" следует рассматривать только как оценочное для размера части сообщения.
     
     
     С.2 Атрибуты заголовка
     
     Некоторые атрибуты образуются из заголовка МПС. Эти атрибуты определены и описаны ниже.
     
     С.2.1 Заголовок
     
     Атрибут заголовок является заголовком (полным) МПС.
     
     heading ATTRIBUTE
     

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

     Некоторые атрибуты имеют в качестве своих значений дескрипторы О/П, выбранные на основе анализа заголовка. Они идентифицируют основных получателей, получателей копии, "слепой" копии МПС, на которое требуется выдача УП, УНП, или ответа.
     
     rn-requestors ATTRIBUTE
     

     
     nrn-requestors ATTRIBUTE
     

     
     reply-requestors ATTRIBUTE
     

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

     originator ATTRIBUTE
     

     
     replied-to-IPM ATTRIBUTE
     

     
     subject ATTRIBUTE
     

     
     expiry-time ATTRIBUTE
     

          
     reply-time ATTRIBUTE
     

     
     importance ATTRIBUTE
     

     
     sensitivity ATTRIBUTE
     

     
     auto-forwarded ATTRIBUTE
     

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

     С.2.4 Подполя заголовка
     
     Некоторые атрибуты содержат имена полей заголовка и подполя этих полей в качестве значений этих атрибутов.
    
     authorizing-users ATTRIBUTE
     

     
     primary-recipients ATTRIBUTE
     

     
     copy-recipients ATTRIBUTE
     

     
     bling-copy-recipients ATTRIBUTE
     

     
     obsolеtеd-IPMs ATTRIBUTE
     

     
     relatеd-IPMs ATTRIBUTE
     

     
     reply-recipients ATTRIBUTE
     

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

     Некоторые атрибуты содержат имена расширений заголовка и в качестве своих значений используют значения этих расширений или их частей.
  
     incomplete-copy ATTRIBUTE
     

     
     languages ATTRIBUTE