ISO/IEC 10021-5:1990

Information technology - Text Communication - Message-Oriented Text Interchange Systems (MOTIS) - Part 5: Message Store: Abstract Service Definition

Technologies de l'information — Communication de texte — Systèmes d'échange de texte en mode message — Partie 5: Dépôt de message: Définition de service abstrait

General Information

• Status: Withdrawn
• Publication Date: 12-Dec-1990
• Withdrawal Date: 12-Dec-1990
• ICS: 35.240.20 - IT applications in office work
• Technical Committee: ISO/IEC JTC 1/SC 6 - Telecommunications and information exchange between systems
• Drafting Committee: ISO/IEC JTC 1/SC 6 - Telecommunications and information exchange between systems
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 08-Dec-2003
• Completion Date: 30-Oct-2025

Relations

• Corrected By: ISO/IEC 10021-5:1990/Cor 5:1992 - Information technology - Text Communication - Message-Oriented Text Interchange Systems (MOTIS) - Part 5: Message Store: Abstract Service Definition - Technical Corrigendum 5
• Effective Date: 06-Jun-2022
• Corrected By: ISO/IEC 10021-5:1990/Cor 4:1992 - Information technology - Text Communication - Message-Oriented Text Interchange Systems (MOTIS) - Part 5: Message Store: Abstract Service Definition - Technical Corrigendum 4
• Effective Date: 06-Jun-2022
• Revised: ISO/IEC 10021-5:1994 - Information technology - Text Communication - Message-Oriented Text Interchange Systems (MOTIS) - Part 5: Message Store: Abstract Service Definition
• Effective Date: 15-Apr-2008
• Parent: ISO/IEC 10021-5:1990/Cor 4:1992 - Information technology - Text Communication - Message-Oriented Text Interchange Systems (MOTIS) - Part 5: Message Store: Abstract Service Definition - Technical Corrigendum 4
• Effective Date: 15-Apr-2008
• Parent: ISO/IEC 10021-5:1990/Cor 5:1992 - Information technology - Text Communication - Message-Oriented Text Interchange Systems (MOTIS) - Part 5: Message Store: Abstract Service Definition - Technical Corrigendum 5
• Effective Date: 15-Apr-2008

Standards Content (Sample)

ISO/IEC
I NTER NAT1 ON AL
10021 -5
STANDARD
First edition
1990-12-01
Information technology - Text Communication
- Message-Oriented Text Interchange Systems
(MOTIS) -
Part 5:
Message Store : Abstract Service Definition
Technologies de l'information - Communication de texte - Syst&mes d'&change
de texte en mode message -
Partie 5: D&p&t de message: Dhfinition de service abstrait
Reference number
ISO/IEC 10021-5 : 1990 (E)
ISOAEC 10021-5 : 1990 (E)
Contents
Page
Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
Introduction . v
Section one - General
1 Scope . 1
Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Definitions . 4
4 Abbreviations . . . 9
5 Conventions . 10
Section two - Message Store abstract-service definition
6 MessageStoremodel . 13
Abstract-bind and Abstract-unbind-operations . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8 Abstract-operations
9 Abstract-errors . 42
Section three - General-attribu te-types and general-auto-action-types
10 Overview . 47
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
11 General-attribute-types
.. .. ... .. . . . . .. . . .......... .. . . . . . . . . . . . . . . . . . . . 64
12 General-auto-action-types
Section four - Procedures for Message Store and ports realization
13 Overview . 68
14 Consumption of the Message Transfer System abstract-service . . . . . . . . . . . , 68
Supply of the Message Store abstract-service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
16 Ports realization
O ISO/IEC 1990
All rights reserved. No part of this publication may be reproduced or utilized in any form or by any
means, electronic or mechanical, including photocopying and microfilm, without permission in
writing from the publisher.
International Organization for Standardization
56 CH-121 1 Genbve 20 Switzerland
Case postale
Printed in Switzerland
ISOAEC 10021-5 : 1990 (E)
ANNEXES
A Formal assignment of object identifiers . 82
B Formal definition of the Message Store abstract-service . 84
C Formal definition of general-attribute-types . 93
D Formal definition of general-auto-action-types . 99
E Formal definition of MS parameter upper bounds . 101
F Example of the Summarize abstract-operation . 102
G Differences between the CCITT Recommendation X.413 text and
ISOiIEC 10021-5 text . 104
iii
ISOAEC 10021-5 : 19yO (E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the International
Electrotechnical Commission) form the specialized system for worldwide standardiz-
ation. National bodies that are members of IS0 or IEC participate in the development
of International Standards through technical committees established by the respective
organization to deal with particular fields of technical activity. IS0 and IEC technical
committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with IS0 and IEC, also take part in the
work.
In the field of information technology, IS0 and IEC have established a joint technical
committee, ISO/IEC JTC 1. Draft International Standards adopted by the joint
technical committee are circulated to national bodies for voting. Publication as an
International Standard requires approval by at least 75 Vo of the national bodies casting
a vote.
International Standard ISO/IEC 10021-5 was prepared by Joint Technical Committee
ISO/IEC JTC 1, Information technology.
ISOAEC 10021-5 consists of the following parts, under the general title: Information
technology - Text Communication - Message-Oriented Text Interchange Systems
(MOTIS) -
- Part I : System and Service Overview
- Part 2: Overall Architecture
- Part 3: Abstract Service Definition Conventions
- Part 4: Message Transfer System: Abstract Service Definition and Procedures
- Part 5: Message Store: Abstract Service Definition
- Part 6: Protocol Specifications
- Part 7: Interpersonal Messaging System
Annexes A, B, C and D form an integral part of this part of ISO/IEC 10021. Annexes E,
F and G are for information only,
iv
ISO/IEC 10021-5 : 1990 (E)
Introduction
This part of ISO/IEC 10021 is one of a number of parts of ISO/IEC 10021 (the International Standard for
Message Oriented Text Interchange System (MOTIS)).
MOTIS provides for the exchange of messages between users on a store-and-forward basis. A message
submitted by one user (the originator) is transferred through the message-transfer-system (MTS) and
delivered to one or more other users (the recipients).
This part of ISO/IEC 10021 defines the Message Store abstract-service (MS abstract-service) which
supports message-retrieval from a Message Store (MS) and indirect-message-submission through the
MS in a Message Handling System (MHS). The MS abstract-service also provides message-
administration services, as defined by the Message Transfer System (MTS) abstract-service.
This International Standard has been produced by joint CCITT-ISO/IEC agreement. The corresponding
WITT Recommendation is X.413 (1988). Annex G list the differences between the two documents.

ISO/IEC 10021-5 : 1990 (E)
INTERNATIONAL STANDARD
Information technology - Text Communication -
Message-Oriented Text Interchange Systems (MOTIS) -
Part 5:
Message Store : Abstract Service Definition
Section one - General
1 Scope
This part of ISO/IEC 10021 defines the Message Store abstract-service. This abstract-service is provided
by the Message Store access-protocol (specified in ISO/IEC 10021-6) in conjunction with the MTS
abstract-service (defined in ISO/IEC 10021-4), together with the Remote Operations Service Element
(ROSE) services (defined in ISO/IEC 9072-1). The abstract-syntax-notation for the application-layer
protocols used in this part of ISO/IEC 10021 is defined in IS0 8824.
Other parts of ISO/IEC 10021 define other aspects of the MHS. ISO/IEC 10021-1 defines the user-
oriented services provided by the MHS. ISO/IEC 10021-2 provides an architectural overview of the MHS.
ISO/IEC 10021-3 provides a description of the abstract-service definition conventions used in MHS.
ISO/IEC 1002 1-7 defines the abstract-service for interpersonal messaging and defines the format of
in ter personal -messages,
Section two of this part of ISO/IEC 10021 contains the Message Store abstract-service definition. Clause
6 describes the MS model. Clause 7 specifies the abstract-syntax-notation for the abstract-bind and the
abstract-unbind-operations. Clause 8 specifies the abstract-syntax-notation for the operations of the
abstract-service. Clause 9 specifies the abstract-syntax-notation for the errors of the abstract-service.
Section three of this part of ISO/IEC 10021 defines the general-attribute-types and general-auto-action-
types related to the MS. Clause 10 contains an overview. Clause 11 specifies the abstract-syntax-
notation for the general-attribute-types. Clause 12 specifies the abstract-syntax-notation for the
general-auto-action-types.
Section four of this part of ISO/IEC 10021 describes the procedures for Message Store and the ports
realization. Clause 13 contains an overview. Clause 14 describes how the Message Store abstract-service
is supplied. Clause 15 describes how the Message Transfer System abstract-service is consumed. Clause
16 describes how the MS ports are realized.
No requirement is made for conformance to this part of ISO/IEC 10021.
ISOAEC 10021-5 : 1990 (E)
2 Normative references
The following standards contain provisions which, through reference in this text, constitute provisions
of the part of ISO/IEC 10021. At the time of publication, the editions indicated were valid. Ali standards
are subject to revision, and parties to agreements based on this part of ISO/IEC 10021 are encouraged to
investigate the possibility of applying the most recent editions of the standards listed below. Members of
IEC and IS0 maintain registers of currently valid International Standards.
2.1 Reference Model references
This part of ISO/IEC 10021 cites the following reference model related documents
IS0 7498:1984, Information processing systems - Open Systems Interconnection - Basic
Reference Model.
2.2 Presentation references
This part of ISO/IEC 10021 cites the following presentation related documents
IS0 8824:1987, Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1).
IS0 8824:1987/Add.l: 1)
Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1) - Addendum 1:
ASLV.l Extentions.
2.3 Remote Operations references
This part of ISO/IEC 10021 cites the following remote operations related document
Information processing systems - Text Communication - Remote Operations
ISO/IEC 9072-1: 1989,
Part 1: Model, Notation and Service Definition.
2.4 Directory References
This part of ISO/IEC 10021 cites the following directory related documents
ISO/IEC 9594-1: 1) Information processing systems - The Directory - Overview of Concepts,
Models and Services.
ISO/IEC 9594-2: 1) Information processing systems - The Directory - Models.
ISO/IEC 9594-3: 1) Information processing systems - The Directory - Abstract Service Definition.
Information processing systems - The Directory - Procedures for Distributed
ISO/IEC 9594-4: 1)
Operation.
ISO/IEC 9594-5: 1) Information processing systems - The Directory - Protocols Specifications.
ISO/IEC 9594-6: 1) Information processing systems - The Directory - Selected Attribute Types.
1) To be published
ISO/IEC 9594-7: 1) lnformation processing systems - The Directory - Selected Object Classes.
ISO/IEC 9594-8: 1) lnformation processing systems - The Directory - Authentication Framework.
2.5 Message Handling references
. -I 11 J
This International Standard cites the following ISO/IEC message handling documents
ISO/IEC 10021-1 11989 lnformation processing systems - Text Communication - Message Oriented
Text Interchange System (MOTIS) - Part I:
System and Service Overview.
ISO/IEC 1002 -2: 1989 Information processing systems - Text Communication - Message Oriented
Text Interchange System (MOTIS? - Part 2:
Overall Architecture.
ISO/IEC 1002 -3:1989 Information processing systems - Text Communication - Message Oriented
Text Interchange System (MOTIS) - Part 3:
Abstract Service Definition Conventions.
ISO/IEC 10021-411989 Information processing systems - Text Communication - Message Oriented
Text lnterchange System (MOTIS) - Part 4:
Message Trans fer System - Abstract Service Definition and Procedures.
ISO/IEC 10021-6: 1989 lnformation processing systems - Text Communication - Message Oriented
Text Interchange System (MOTIS) - Part 6:
Protocol Specifications.
ISO/IEC 10021-711989 lnformation processing systems - Text Communication - Message Oriented
Text Interchange System (MOTIS? -Part 7:
In te rpe r s O na 1 Mess aging System.
1) To be published
ISOAEC 10021-5 : 1990 (E)
3 Definitions
3.1 Common Definitions for MHS
For a list of the common definitions for MHS refer to ISO/IEC 10021-2.
3.2 Message Store Definitions
For the purpose of this part of ISO/IEC 10021 the following definitions apply
3.2.1 abstract-association. An abstract binding between two communication partners, in this part of
ISOIIEC 10021 the binding between a UA and an MS for the provision of the MS abstract-
service, or between an MS and an MTA for the provision of the MTS abstract-service.
3.2.2 abstract-bind-parameters: Parameters defined in this part of ISO/IEC 10021 which are
contained in the abstract-bind operation.
3.2.3 abstract-unbind-parameters: Parameters defined in this part of ISOIIEC 1002 1 which are
contained in the abstract-unbind operation.
3.2.4 Administration Port: The port offering the administration (for MTS) set of abstract-services
within the MS abstract-service.
3.2.6 Alert abstract-operation. ,4n abstract-operation which allows the MS to signal, based on
selection criteria, to the LA that messages or reports are waiting in the 52s.
Can only be issued on an existing abstract-association.
3.2.6 attribute: The information of a particular type appearing in an entry in an information-base
3.2.7 attribute-type: That component of an attribute which indicates the class of information given
by that attribute.
3.2.8 attribute-value: A particular instance of that class of information indicated by an attribute
type.
3.2.9 attribute-value-assertion. '4 proposition, which may be true, false, or undefined, concerning
the values of attributes in an entry.
3.2.10 auto-action: Actions, that can be performed automatically by the MS, based on previously
registered information from the MS-owner via the L'A.
3.2.1 1 auto-action-type: An auto-action-type is used to indicate the type of auto-action, e.g Alert.
3.2.12 auto-alert: Auto-alert is the auto-action within the MS, which triggers an Alert abstract-
operation or another action by the Ills
3.2.13 auto-forward: Auto-forward is the auto-action within the MS, which triggers a message to be
auto-forwarded to another recipient (or other recipients) by the MS.
3.2.14 child-entry: An entry, other than the main-entry in an information-base. The parent-entry for a
child-entry can be either the main-entry or another child-entry, depending on the number of
entry levels in each case.
3.2.15 child-sequence-number: A sequence-number in a parent-entry pointing to a child-entry. A
parent-entry can have more than one child-sequence-number value, depending on the number of
child-entries.
3.2.16 conditional (C) component: An ASN.l element which shall be present in an instance of its
class as dictated by this International Standard.
See grade.
3.2.17 content-length: An attribute which gives the length of the content of a delivered-message (or
returned-content).
3.2.18 content-returned: An attribute which signals that a delivered-report (or a delivered-message)
contained a returned content.
3.2.19 converted EITs: An attribute identifying the encoded-information-types of the message
content after conversion.
3.2.20 creation-time: An attribute which gives the creation-time (by the MS) of an entry.
3.2.21 Delete abstract-operation. An abstract-operation used to delete one or more entries from an
information-base,
3.2.22 delivered-EITs: A multi-valued attribute, giving information about EITs in a delivered-
message.
3.2.23 delivered-message entry: An entry in the stored-messages information-base resulting from a
delivered-message.
3.2.24 delivered-report entry. An entry in the stored-messages information-base resulting from a
delivered-report.
3.2.25 entry: An information set in an information-base.
See main-entry, parent-entry and child-entry for further classification of entries.
3.2.26 entry-information: A parameter, used in abstract-operations, which conveys selected
information from an entry.
3.2.27 entry-information-selection: A parameter, used in abstract-operations, which indicates what
information from an entry is being requested.
3.2.28 entry-status: An attribute giving information about the processing status of that entry.
Possible values are new, listed or processed.
3.2.29 entry-type: An attribute which signals if an entry is associated with a delivered-message or a
delivered-report.
3.2.30 Fetch abstract-operation: An abstract-operation which allows one entry to be fetched from the
stored-messages information-base.
ISOIIEC 10021-5 : 1990 (E)
3.2.31 fetch-restrictions: Restrictions, imposed by the UA, on what kind of messages it is prepared to
receive as a result of fetch. The possible restrictions are on message-length, content-types and
EITs.
3.2.32 filter: A parameter, used in abstract-operations, to test a particular entry in an information-
base and is either satisfied or not by that entry.
3.2.33 filter-item: An assertion about the presence or value(s) of an attribute of a particular type in an
entry under test. Each such assertion is either true or false.
forwarding-request: This is a parameter that may be present in a Message-submission
3.2.34
abstract-operation, invoked by the LA, to request that a message is forwarded from the MS.
general-attribute: A set of &IS attributes which are valid for all types of messages and reports,
3.2.35
independent of content-type
Only these MS attributes are explicitly defined in this part of ISO/IEC 10021.
3.2.36 general-auto-action: Auto-actions which are valid for all types of messages and reports,
independent of content-type.
Only these auto-actions are explicitly defined in this part of ISO/IEC 10021.
3.2.37 grade: Defined in ISO/IEC 10021-2.
3.2.38 Indirect-submission Port: The port offering the Indirect-submission abstract-service within
the 3% abstract-service.
The Indirect-submission abstract-service offers the same services as the Message-submission
abstract-service (from the LITS abstract-service) with the added functionality of forwarding
messages residing in the MS.
3.2.39 information-base: Objects within the MS which store information relevant to the MS abstract-
service, e.g. the stored-messages information-base, which stores the messages and reports that
have been delivered into the MS.
3.2.40 information-base-type: The type of information-base, e.g. the stored-messages.
3.2.41 limit: A component in the selector parameter which identifies the maximum number of selected
entries to be returned in the result of an abstract-operation.
3.2.42 list abstract-operation: An abstract-operation which allows a selection of entries from an
information-base and requested attribute information to be returned for those entries.
3.2.43 listed: An entry-status value.
3.2.44 macro: See IS0 8824.
main-entry: For each successful abstract-operation which creates information-base entries,
3.2.45
there is always one main-entry. Further, or more detailed, information resulting from the same
abstract-operation can be stored in child-entries.
mandatory (M) component. An ASN.l element which shall always be present in an instance of
3.2.46
its class.
See grade.
ISO/IEC 10021-5 : 1990 (E)
3.2.47 matching: The process of comparing the value supplied in an attribute-value-assertion with the
value of the indicated attribute-type stored in the MS or deciding whether the indicated
attribute-type is present.
3.2.48 Message Retrieval Service Element (MRSE): The application-service-element by means of
which a receiving UA effects retrieval of messages from an MS, or any of various related tasks.
3.2.49 MS: Message Store, also used as a shorter form for ”MS abstract-service-provider”.
.A
“L 3, .” ‘2 I
3.2.50 MS abstract-service The set of capabilities that the MS offers to its users by means of its ports.
3.2.51 MS abstract-service-user: The user of the MS abstract-service.
This is the UA.
3.2.52 MS abstract-service-provider: The MS which provides the MS abstract-service.
3.2.53 MS-user: A shorter form for ”MS abstract-service-user”.
3.2.54 Message-submission abstract-operation: An abstract-operation which allows the UA to
submit a message to the MTS via the MS, and/or to forward a message from the MS to the MTS.
3.2.55 multi-valued attribute: An attribute which can have several values associated with it.
3.2.96 new: An entry-status value
3.2.57 optional (O) component: An ASN.l element which shall be present in an instance of its class at
the discretion of the object (e.g.user) supplying that instance.
See grade.
3.2.58 original-EITs: An attribute identifying the original encoded-information-types of the message
content.
3.2.59 override: A component of the selector parameter indicating that the previously registered-
restrictions for this abstract-operation should not apply for this instance of this abstract-
operation.
3.2.60 parent-entry: A parent-entry has one or more child-entries, which were created as a result of
the same abstract-operation.
If a parent-entry is not a child-entry of another parent-entry, it is a main-entry.
3.2.61 parent-sequence-number: A sequence-number in a child-entry pointing to its parent-entry.
There can only be one parent-sequence-number in a child-entry.
3.2.62 partial-attribute-request: A component of the entry-information-selection which enables the
return of only selected values of a multi-valued attribute.
3.2.63 position: Positions are parameters used to specify a bound of a range.
3.2.64 processed: An entry-status value
3.2.65 range: A parameter, used in abstract-operations, to select a contiguous sequence of entries from
an information-base.
ISO/IEC 10021-5 : 1990 (E)
Register-MS abstract-operation: An abstract-operation which allows the UA to register
3.2.66
certain information, relevant to the UA-MS interworking, in the MS.
registration: Information which is registered in the MS and stored (until changed by the
3.2.67
Register-MS abstract-operation) between abstract-associations.
See Register-MS abstract-operation.
3.2.68 registration-identifier: An identifier for one particular set of registration-parameters for an
au to-ac tion- type.
3.2.69 Retrieval Port: The port offering the retrieval set of abstract-services within the MS abstract-
service.
3.2.70 returned-content entry: An entry-type in the stored-messages information-base which
contains the returned content from a previously submitted message.
3.2.7 1 selector: A parameter, used in abstract-operations, to select entries from an information-base
3.2.72 sequence-number: An attribute which uniquely identifies an entry.
Sequence-numbers are allocated in ascending order.
3.2.73 single-valued attribute: An attribute which can only have one value associated with it.
3.2.74 span: A component in the Summarize abstract-operation result containing the lowest and
highest sequence-numbers of the entries that matched the selection criteria.
3.2.75 stored-messages: The most important information-base in this part of ISO/IEC 10021, used to
store entries containing messages and reports delivered by the MTS to the MS.
3.2.76 subscription: A long-term agreement between the MS supplier or administrator and the MS
customers (MS-owners) on the availability and use of optional MS features such as optional
services and attributes.
This part of ISO/IEC 10021, assumes that such a mechdnism is provided, but does not prescribe
or offer any standardized method for how to provide this.
3.2.77 substring: A filter-item used to specify a string of characters which appear (in the same given
order) in a value of an attribute.
3.2.78 Summarize abstract-operation: An abstract-operation which allows a quick overview of the
kind and number of entries which are currently stored in an information-base.
3.2.79 synopsis: A content specific attribute that may be used to show how child-entries, containing
parts of the content, are related to each other and the main-entry.
The attribute has to be specified in the International Standard, which describes the content-
type, e.g. see IPM-synopsis defined in ISO/IEC 10021-7.
4 Abbreviations
Abstract Syntax Notation One
ASN.l:
C: conditional
DL: distribution-list
d EIT: encoded-information-type(s)
. ,j
mandatory
M:
multi-valued
M:
Message Administration Service Element
MASE:
Message Delivery Service Element
MDSE:
Message Handling
MH:
Message Handling System
MHS:
Message Oriented Text Interchange System
MOTIS.
Message Retrieval Service Element
MHSE:
Message Store
MS.
Mes sage Trans fe r
MT:
Message Transfer System
MTS.
N: no
O: optional
originatorlrecipient
OiR:
P: present
ROSE: Remote Operations Service Element
single-valued
S:
U A: User Agent
..+a zss
Cniversal Co-ordinated Time
UTC:
Y:
Yes
ISO/IEC 10021-5 : 1990 (E)
5 Conventions
This part of ISO/IEC 10021 uses the description conventions listed in the following four clauses.
5.1 Conventions for abstract-services
This part of ISO/IEC 10021 uses the following ASN.l-based descriptive conventions for the indicated
purposes
1) ASN.l itself, to specify the abstract-syntax of information-bases and their components, and common
data-types.
2) The ASN.l PORT macro and associated abstract-service definition conventions of ISO/IEC 10021-3,
to specify the Retrieval Port.
3) The ASN.l ABSTRACT-BIND, ABSTRACT-CNBIND, ABSTRACT-OPERATIOX, and
ABSTRACT-ERROR macros and associated abstract-service definition conventions of ISO/IEC
10021-3, to specify the MS abstract-service.
Whenever this parc of ISOiIEC 10021 describes a class of data structure having components, each
component is categorized as one of the following grades
1) Mandatory (MI: A mandatory component shall be present in every instance of the class.
2) Optional(0): An optional component shall be present in an instance of the class at the
discretion of the object (e.g user) supplying that instance.
3) Conditional (C): A conditional component shall be present in an instance of the class as dictated
by this part of ISO/IEC 1002 1.
5.2 Conventions for attribute-types used in table 1 of clause 11
This part of ISO/IEC 10021 uses the conventions listed below in its definition of the attribute-types for
the MS abstract-service.
For the column headed ”Sinde/Multi-valued” the following values can occur
S single-valued
M multi-valued.
For the column headed ”Support level bv the MS and access L‘A” the following values can occur
M manda tory
O optional.
For the columns headed ”Presence in delivered message entry”, ”Presence in delivered report entry”,and
”Presence in returned message entry”, the presence of each attribute-type is described by one of the
following values
alwavs present in the entry because
P
-
it is mandatory for generation by the MS; or
-
it is a mandatory or defaulted parameter in the relevant
abstract-operation.
ISOAEC 10021-5 : 1990 (E)
conditionally present in the entry. It would be present because
C
-
it is supported by the MS and subscribed to by the user and;
-
it was present in an optional parameter in the relevant abstract-operation
always absent, otherwise.
For the columns headed "Available for List, Alert" and "Available for Summarize" , the following values
can occur
N no
Y yes.
Conventions for attribute-types used in table 2 of clause 11
5.3
This part of ISO/IEC 10021 uses the conventions listed below in its definition of the attribute-types for
the MS abstract-service. Clause 11 includes the table that lists the attribute-types.
For the column headed "SinPle/Multi-valued" the following values can occur
S single-valued
M multi-valued.
For the column headed "Source generated by" the following values can occur
MD MessageDelivery abstract-operation
MS Message Store
RD Report Delivery abstract-operation,
5.4 Font conventions for text in general
Throughout this part of ISOiIEC 10021, terms are rendered in bold when defined, without emphasis
upon all other occasions. Terms that are proper nouns are capitalized, generic terms are not. Multi-word
generic terms are hyphenated.
5.5 Font conventions for ASN.l definitions
\i."th')
Throughout this part of ISOiIEC 10021, ASN.l definitions are written in a different (bold) font than the
rest of the document in order to highlight the difference between normal text and ASN.l definitions. The
font used for ASS.l definitions is also one size smaller than the ordinary text. When ASS.l protocol
elements and elements values are described in accompanying text, their names are rendered in bold.
5.6 Rules for ASN.1 definitions
ASN.l definitions appears both in the body of the document to aid the exposition, and again, formally, in
annexes for reference. If differences are found between the ASS.l used in the exposition and that
formally defined in the corresponding annex, a specification error is indicated.
ISO/IEC 10021-5 : 1990 (E)
Section two - Message Store abstract-service definition
6 Message Store model
The Message Store (MS) is modeled as an atomic object, which acts as a provider of services to an MS
abstract-service-user (i.e. a User Agent), and as a user of services provided by the Message Transfer
System (MTS).
The MS serves an intermediary role between the UA and the MTS. Its primary function is to accept
delivery of messages on behalf of a single MHS end-user, and to retain them for subsequent retrieval by
the end-user’s UA. The MS also provides indirect message-submission and message-administration
services to the UA, in effect, via “pass-through” to the MTS. This enables the MS to provide additional
functionality compared to submission directly to the MTA; such as forwarding of messages residing in
the MS and logging facilities.
Like the UA, the MS acts on behalf of only a single MHS end-user; i.e. it does not provide a common or
shared multi-user MS service.
The MS is described using an abstract model in order to define the services provided by the LIS - the
Message Store abstract-service. Figure 1 shows the MS abstract-service in relation to its user and to the
Message Transfer System abstract-service. In this figure, the open boxes represent the consumption of
the abstract service, and the closed boxes represent the supply of the abstract service
MTS
abstract-
-? service
mistration
L Drovider
Figure 1 - Message Store abstract-service
For an introduction and description of the abstract-service concept and its definition conventions, see
ISO/IEC 1002 1-3.
In secure messaging the MS is treated as a separate object with a unique identity and has a separate key
(or a set of keys) to the UA.
6.1 Message Store object
The MS is modeled as an atomic object. It supplies the MS Retrieval Port abstract-services to the MS
abstract-service-user. Acting as a ”surrogate” MTS abstract-service-provider, the MS also supplies the
MTS submission and administration abstract-services to the MS abstract-service-user (MS-user), and
acting as a UA ”surrogate”, it consumes the MTS Delivery Port, Submission Port, and Administration
Port abstract-services in its role as MTS abstract-service user.
The formal definition for the Message Store object is as follows:
rnS OBJECT
PORTS ( retrieval[S],
indirectSubrnission[S],
administration[S],
delivery[C],
submission[C],
adrninistration[C]}
:: = id-ot-rns
The MS-user is also modeled as an object. It consumes the MS Retrieval Port and Indirect-submission
Port abstract-services and the Administration Port abstract-services provided transparently by the MS.
msUser OBJECT
PORTS ( retrieval[C],
indirectSubmission[C],
administration[C]}
:: = id-ot-ms-user
6.2 Message Store Ports
An MS provides the Retrieval, Indirect-submission, and Administration Ports to the MS abstract-service
user. The collection of capabilities provided by these ports provides the MS abstract-service. The
retrieval capabilities are unique to the MS. These capabilities include obtaining information on,
fetching (in whole or in part), and deleting messages residing in the MS. Additional capabilities are
provided for registering certain MS provided automatic actions (i.e. auto-forwarding and alert)
Additional message management services, are planned as future extensions to this part of ISO/IEC
10021. They will be performed by the MS on the UA’s behalf, for logging incoming and outgoing
messages, and for auto-correlating incoming notifications with logging information about outgoing
messages. These extensions would form an Addendum to ISOIIEC 1002 1.
In order to provide the services described in 6.1 to an MS-user, the MS interacts, on behalf of the MS-
user, with the MTS abstract-service, and acts as a consumer of the MTS Delivery, Submission and
Administration Ports. The abstract-services provided by the MTS ports are defined in clause 8 of
ISO/IEC 10021-4.
By means of the Abstract-bind operation, the MS authenticates an SIS-user before providing it with any
of the above retrieval capabilities. Similarly, the MTS abstract-services shall authenticate the MTS
abstract-service user before extending its services to the MTS abstract-service-user.
With the exception of the Retrieval Port provided Alert service and the Indirect-submission Port
provided Submission-control service, all the services provided by the MS abstract-service are invoked by
the MS-user and performed by the MS.
ISO/IEC 10021-5 : 1990 (E)
Security-labels may be assigned to the MS in line with the security-policy in force. The security-policy
may also define how security-labels are to be used to enforce the security-policy. If security-labels are
assigned to the MS, the handling of stored messages and reports bearing message-security labels may be
affected by the security-policy in force. If security-labels are not assigned to the MS, the handling of
stored-messages and reports is discretionary.
If security-contexts are established between the CA and the MS, and between the MS and the MTA, the
security-label that is assigned to a message or probe is confined by the security-context in line with the
security-policy in force. If security-contexts are not established the assignment of a message-security-
label to a message or probe is at the discretion of the originator.
6.2.1 Retrieval Port
The Retrieval Port is defined as follows:
retrieval PORT
CONSUMER INVOKES (
Summarize,
List,
Fetch,
Delete,
Register-MS)
SUPPLIER INVOKES (
Alert}
:: = id-pt-retrieval
The details of the Retrieval Port abstract-services are described in clauses 7 to 9
6.2.2 Indirect-submission Port
The Indirect-submission Port is defined as follows:
indirectSubmission PORT :: = submission
The Indirect-submission Port makes use of the Submission Port abstract-services defined in 8.2 of
ISO/IEC 10021-4.
6.2.3 Administration Port
The Administration Port is defined in 8.4 of ISOiIEC 10021-4.
The MS shall have no interaction with the change-credentials abstract-service. If the MS-user needs to
have its credentials updated, then the Register-MS abstract-operation is used. See 8.6.
6.3 Information model
This subclause describes the information model used by the MS. It models information-bases, which
consist of entries, which consist of attributes.
6.3.1 Information-bases
The MS stores and maintains information-bases. An information-base in the MS is a "data-base''
containing all the entries representing constituent objects of a particular category or categories.
ISOAEC 10021-5 : 1990 (E)
This part of ISO/IEC 1002 1 defines and describes the stored-messages information-base. This holds
information derived from message-deliveries and report-deliveries to the MS across the MTS Delivery
Port, and is described in 6.4. Other information-bases are the inlog and the outlog, which are planned as
a future addendum to this part of ISO/IEC 10021. These extensions are outside the scope of the
corresponding CC ITT Recommendation.
InformationBase :: = INTEGER {
stored-messages (O),
inlog (1).
outlog (2)) (O . ub-information-bases)
6.3.2 Entries
Each information-base is organized as a sequence of entries. An entry represents a single object (such
as a delivered message) within the information-base.
Each entry is identified by means of its sequence-number, unique within an information-base, and
generated by the MS as new entries are created. Within an information-base, the MS generates the
sequence-numbers in ascending order without cycling, and they are never re-used.
SequenceNumber :: = INTEGER (O . ub-messages)
NOTE - For example, the MS may choose to allocate sequence-numbers by using the time to a sificient granularity to ensure
uniqueness.
6.3.3 Attributes
6.3.3.1 Introduction
An entry consists of a set of attributes. This is depicted in figure 2.
Each attribute provides a piece of information about, or derived from, the data to which the entry
corresponds. One such piece of information is the sequence-number of the entry itself, and another is
the creation-time.
An attribute consists of an attribute-type, which identifies the class of information given by an
attribute, and the corresponding attribute-value(.ç), which are particular instances of that class
. '. 1
appearing in the entry.
Attribute :: = SEQUENCE (
type AttributeType,
values SEQUENCE SIZE (1 . ub-attribute-values) OF ANY --DEFINED BY type-.)
NOTE . Thus, for example, in a delivered-message-entry (described in 6.4, the attribute-type could be the message's priority, and
a corresponding attribute-value could be urgent.
All attributes in an entry shall be of distinct attribute-types.
For some attribute-types, an attribute shall only contain a single attribute-value. Such an attribute-
type is said to be single-valued For others, an attribute may contain one or more attribute-values,
all of the same ASN.l data-type. Such an attribute-type is said to be multi-valued. Whether an
attribute-type is single-valued or multi-valued is stated when the attribute-type is defined (see
6.3.3.2).
ISO/IEC 10021-5 : 1990 (E)
ENTRY
\
\
'
\
\
'
\
\
\
\ ATTRIBUTE
'.
\
\
\
0- \
00) ATTRIBUTE VALUE(S) \
0) \
-/
Attribute Attribute Attribute
Value
Figure 2 -The Components of an entry
NOTE ~ Thus, for example, the attribute-type for the originator-name attribute (described in 11.2 28) is single-valued,
whereas that for other-recipient-names (described in 11 2.29) is multi-valued.
6.3.3.2 Attribute-type
Some attribute-types will be internationally standardized. Other attribute-types will be defined by
national administrative authorities and private organizations. This implies that a number of separate
authorities will be responsible for assigning types in a way that ensures that each is distinct from all
other assigned types. This is accomp:ished by identifying each attribute-type with an object identifier
when the attribute-type is defined
Attributelype :: = OBJECT IDENTIFIER
Certain general-purpose attribute-types for the stored-messages information-base are defined in clause
11. Such attribute-types are known as general-attribute-types and attributes of these types as
general-attributes.
6.3.3.3 Attribu te-values
Defining an attribute-type also involves specifying the ASN.l data-type to which every value in such
attributes shall conform. The data-type of an attribute-value for the attribute-type is defined through
the object identifier for the attribute-type.
6.3.3.4 Attribute-type definition and the ATTRIBUTE Macro
The definition of an attribute-type involves
ISOAEC 10021-5 : 1990 (E)
a) assigning an object identifier to the attribute-type:
b) indicating the ASN.l data-type of an attribute-value;
c) indicating whether an attribute of this attribute-type may have more than one value;
d) indicating whether an attribute of this attribute-type may be used for filtering using equality,
substrings, andor ordering relations, see 8.1.2.
NOTE - A filter may always test for the presence or absence in an entry of an attribute ofa particular attribute-type.
The following ASN.l macro is used to define an attribute-type. The formal definition of this macro is
given in ISO/IEC 9594-2 and is documented here as an aid to the reader.
.. -
ATTRIBUTE MACRO . -
BEGIN
.. -
TYPE NOTATION . - Attributesyntax Multivalued I empty
VALUE NOTATION :: = value (VALUE OBJECT IDENTIFIER)
.. -
Attributesyntax . - "WITH ATTRIBUTE-SY NTAX" Syntaxchoice
.. -
Syntaxchoice . - value (ATTRIBUTE-SYNTAX) Constraint I type MatchTypes
.. -
Constraint . - "(" ConstraintAlternative ")" 1 empty
Stringconstraint I Integerconstraint
ConstraintAlternative :: =
.. -
Stringconstraint . - "SIZE" "(" Sireconstraint ")" I empty
.. -
Sizeconstraint . - Singlevalue I Range
.. -
Singlevalue . - value (INTEGER)
.. -
Range . - value (INTEGER) "." value (INTEGER)
IntegerConstraint :: = Range
.. -
MatchTypes . - "MATCHES FOR" Matches I empty
.. -
Matches . -
Match Matches 1 Match
.. -
Match . -
"EQUALITY" 1 "SUBSTRINGS" 1 "ORDERING"
.. -
Multivalued . -
"SINGLE VALUE" I "MULTI VALUE" 1 empty
END
'1
The correspondence between the parts of the definition, as listed above, and the various pieces of the
notation introduced by the ATTRIBUTE macro, is as follows:
MACRO value. The object identifier which is used to identify an attribute.
Attribute-syntax: Notes which syntax-choice has been made.
Syntax-choice: Notes whether the attribute is defined externally or internally. The syntax of all
the attributes defined in this part of ISO/IEC 10021 is defined internally, which means using the
choice type MatchTypes.
Multivalued: Denotes whether the attribute is single or multi-valued.
Match-types: Gives the data-type of the contents of the attribute, and describes whether the
attribute can be matched ("MATCHES FOR") for equality ("EQUALITY"), for substrings
("SUBSTRINCS"), and for an ordering relation ("ORDERtNG").
Matching for this part of ISO/IEC 10021 is restricted as follows:
ISO/IEC 10021-5 : 1990 (E)
EQUALITY is applicable to any attribute-syntax. The presented value shall conform to the
i)
data-type of the attribute-syntax;
ii) SUBSTRING is applicable to any attribute-syntax with a string data type.The presented value
shall be a sequence ("SEQUEKCE OF"), each of whose elements conforms to the data-typeJ and
iii) ORDERING is applicable to any attribute-syntax for which a rule can be defined that will
allow a presented value to be described as less than equal to, or greater than a target value. The
presented value shall conform to the data-type of the attribute-syntax.
MS uses this for the INTEGER and CTCTime data types. For UTCTime, the ordering is
chronological, not alphabetical
The remaining choices and parameters of the ATTRIBUTE macro are not used in this part of ISO/IEC
10021.
6.3.4 Main-entries, parent-entries, and child-entries
Although entries in a single information-base are generally independent of each other, the MS
information model allows such entries to be related to one another. One entry, a child-entry, may be
the child of another. its parent-entry, in a tree-structured relationship. An entry which is not a child-
entry is termed a main-entry.
This relationship is recorded by means of two special general-attributes:
a) parent-
...