ISO/IEC 10021-7:1990/Amd 3:1994

INTERNATIONAL ISO/IEC
STANDARD 10021-7
First edition
1990- 12-0 1
AMENDMENT 3
1994-1 2-1 5
Information technology - Text Communication -
Message-Oriented Text Interchange Systems
(MOTIS) -
Part 7:
I nte rpe rso na I Messag i ng System
AMENDMENT 3: Message Store Extensions
Technologies de l'information - Communication de texte - Systèmes d'échange
de texte en mode message (MOTIS) -
Partie 7: Système de messagerie de personne à personne
AMENDEMENT3: Extensions de dépôt de message
Reference number
ISO/IEC 1002 1-7: 1990/Amd.3: 1994(E)

---------------------- Page: 1 ----------------------
IsO/ïEC 10021-7:1990 / Amd 3:1994 (E)
Contents
Foreword . iv
O Introduction . 1
2.1 Open Systems Interconnection . 1
Message Handling Systems . 2
2.2
2.3 Directory Systems . 3
5.1 ASN.l . 3
5.4 Conventions for attribute-types used in Table 5 . 4
Message Store Operation . 4
19
.
19.1 Binding to the IPMS-MS . 4
19.1.1 MS-bind-argument . 5
19.1.2 MS-bind-result . 5
19.2 Creation of Information Objects . 5
19.2.1 Mapping an IPMS Message to an MS entry . 5
19.2.2 Mapping of forwarding messages in the IPMS-MS . 6
19.2.3 Presence of General-attributes in child-entri- . 7
Maintenance of Attributes . 7
19.3
Notification of Non-receipt . 8
19.4
PMS-MS abstract-operation extensions . 9
19.5
19.5.1 MS-bind extensions . 9
19.5.2 MS-message-submission extensions . 9
19.5.3 Delete extensions . 11
IPMS-MS Attributes . 11
19.6
Summary Attributes . 14
19.6.1
19.6.2 Heading Attributes . 17
19.6.3 Body Attributes . 21
19.6.4 Notification Ataibutes . 25
19.6.5 Correlation Attributes . 27
19.6.6 The IPMS-attribute-table information object class . 35
19.6.7 Generation of the IPMS-specific Attributes . 35
19.6.8 Attributes Subject to Modification .
PMS-MS matching rules . 40
19.7
19.7.1 IPM-identifier-match . 40
19.7.2 OR-descriptor-match . 40
19.7.3 OR-descriptor-elements-match . 41
19.7.4 OR-descriptor-substring-elements-match . 41
19.7.5 Recipient-specifier-match . 41
Recipient.specifier.elements.match . 41
19.7.6
19.7.7 Recipient-specifier-subsiring-elements-match . 42
O ISO/IEC
I994
All rights reserved . No pan of this publication may be reproduced or utilized in any form or by any
means. electronic or medianical . including photocopying and microfilm . without permission in wxiting
from the publisher .
ISOWC Copyright Office Case Postal 56 CH-1211 Genève 20 Switzerland
Printed in Switzerland
ii

---------------------- Page: 2 ----------------------
O ISO/IEC ISO/IEC 10021-7:1990 / Amd 3:1994 (E)
19.8 IPMS-MS auto-actions . 42
19.8.1 Auto-action performance . 43
19.8.2 IPM AütO-fû~ard . 43
19.8.3 IPM Auto-acknowledgement . 46
19.8.4 IPM Auto-correlate . 47
19.8.5 IPM Auto-discard . 47
19.9 Procedures for the IPMS-MS . 48
19.9.1 Additional procedures for Message-delivery . 48
19.9.2 Additional Procedures for MS-message-submission . 51
19.9.3 Additional Procedures for Fetch .
19.9.4 Additional Procedures for Delete and Auto-delete .
Auto-discard of expired IPMs . 53
19.9.5
22.2 Statement Requirements .
Annex C Reference Definition of Object Identifiers .
Annex D Reference Defimition of Abstract Information Objects . 57
Annex E Reference Definition of Functional Objects . 58
Annex F Reference Definition of Abstract Service . 59
Annex G Reference Definition of Heading Extensions .
Annex H Reference Definition of Extended Body Part Types .
Annex I Reference Definition of Message Store Attributes . 62
Annex J Reference Definition of IPMS-MS auto-actions . 74
Annex L Support of the Interpersonal Messaging Service . 78
Annex N Summary of Changes to previous editions . 79

---------------------- Page: 3 ----------------------
O ISODEC
ISOAEC 10021-7: 1990/Amd.3: 1994(E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the Inter-
national Electrotechnical Commission) form the specialized system for worldwide
standardization. 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
iiiternational organizations, governmental and non-governmental, in liaison with
IS0 and IEC, also take part in the work.
In the field of information technoiogy, 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 % of the national
bodies casting a vote.
Amendment 3 to International Standard ISODEC 10021-7: 1990 was prepared by
Joint Technical Committee ISODEC JTC 1, Information technology,
Subcommittee 18, Document processing and related communication.

---------------------- Page: 4 ----------------------
O ISO/IEC
ISOhEC 10021-R1990 / Amd 3:1994 (E)
Information technology - Text Communication -
Message-Oriented Text Interchange Systems (MOTIS) -
Part 7:
Interpersonal Messaging System
Amendment 3: Message Store Extensions
O Introduction
This clause provides an introduction to this amendment. The text in this clause is not intended for inclusion in ISOIIEC
10021 -7.
The scope of the Message Store Abstract-service defined in ISODEC 10021-51990 and ISO/iE!C 10021-7:1990 is limited to
the storage of delivered messages and their subsequent retrieval by the MS-user. This document extends the functionality
offered by the IPMS Message Store to equip it to satisfy a broader range of service requirements. These include the
provision of services for the storage of submitted messages, the correlation of replies and PNs, the modification by the MS-
user of certain attributes of stored messages, and the logging of submission and delivery operations.
2.1 Open Systems Interconnection
Replace existing clause 2.1 with the following:
This part of ISO/IEC 10021 cites the following OS1 specifications:
ISO/IEC 8824- 1 : I), Information technology - Open Systems Interconnection - Abstract Syntax Notation One (ASN.1):
Specifcation of Basic Notation.
ISO/IEC 8824-2: l), Information technology - Open Systems Interconnection - Abstract Syntax Notation One (ASN.1):
Information Object Specification.
information technology - Open Systems Interconnection - Abstract Syntax Notation One (ASN.1):
ISO/IEC 8824-3: l),
Constraint Specification.
ISOfiEC 8824-4: l), Itformation technology - Open Systems Interconnection - Abstract Syntax Notation One (ASN.1):
Parameterization of ASN.1 Specifications.
ISO/IEC 8825-1: I),
Information technology - Open Systems Interconnection - Specification of ASN.1 Encoding Rules:
Basic Encoding Rules (BER).
To be published.
1

---------------------- Page: 5 ----------------------
7
(6 ISO/IEC
ISOhEC 10021-7:1990 / Amd3:1994 (E)
2.2 Message Handling Systems
Replace existing clause 2.2 with the following:
I
This part of ISO/iEC 10021 cites the following Message Handling System specifications:
ISO/iEC 10021-1: 1990, Information technology -Text Communication - Message Oriented Text Interchange Systems
(MOTIS) - Part 1: System and service overview.
ISOliEC 10021-1/Amd.l: 1994, Information technology -Text Communication - Message Oriented Text Interchange Systems
(MOTIS) - Part 1 : System and service overview - Amendment 1 : Message Store Extensions.
ISO/IEC 1002 1-2: 1990, Information technology -Text Communication - Message Oriented Text Interchange Systems
(MOTIS) - Part 2: Overall Architecture.
ISO/IEC 1002 1-2IAmd. 1 ; 1994, Information technology -Text Communication - Message Oriented Text Interchange Systems
(MOTIS) - Part 2: Overall Architecture - Amendment 1: Representation of OIR addresses for
human exchange.
ISO/IEC 10021-2/Amd.2 1994, Information technology -Text Communication - Message Oriented Text Interchange Systems @
(MOTIS) - Part 2: Overall Architecture -Amendment 2: Minor Enhancements - Multinational
organizations and terminal-form addresses.
ISOJiEC 10021-2/Amd.3:1), Information technology -Text Communication - Message Oriented Text Interchange Systems
(MOTIS) - Part 2: Overall Architecture -Amendment 3.
ISO/iEC 1002 1-4: 1990, Infirmation technology -Text Communication - Message Oriented Text Interchange Systems
(MOTIS) - Part 4: Message Tranger System: Abstract Service Definition and Procedures.
ISO/iEC 10021-4lAmd. 1: 1994, Information technology -Text Communication - Message Oriented Text Interchange Systems
(MOTIS) - Part 4: Message Transfer System: Abstract Service Definition and Procedures -
Amendment 1 : Minor Enhancements: NotGCation type and Directory substitution.
ISO/EC 10021-4lAmd.2 Information technology -Text Communication - Message Oriented Text Interchange Systems
(MOTIS) - Part 4: Message Tranger System: Abstract Service Definition and Procedures -
Amendment 2: ASN.1 and P3 extensions.
ISO/iEC 10021-5: 1994, Information technology -Text Communication - Message Oriented Text Interchange Systems
(MOTIS) - Part 5: Message Store - Abstract Service Definition.
1)
ISO/iEC 10021-6 1990, Information technology -Text Communication - Message Oriented Text Interchange Systems
(MOTIL) -Part 6: Protocol Specifications.
ISO/IEC 10021-6lAmd. 1: 1994, Information technology -Text Communication - Message Oriented Text Interchange Systems
(MOTIS) - Part 6: Protocol Specifications - Amendment 1: Message Store Extensions.
ISO/IEC 10021-7: 1990, Information technology -Text Communication - Message Oriented Text Interchange Systems
(MOTIS) - Part 7: Interpersonal messaging system.
ISO/iEC 10021-7/Amd. 1: 1994, Information technology -Text Communication - Message Oriented Text Interchange System
(MOTIS) - Part 7: Interpersonal messaging system - Amendment 1 : Minor Enhancements: File
transfer body part and auto-submission indication.
To be published.
2

---------------------- Page: 6 ----------------------
O ISO/IEC ISO/IEC 10021-7:1990 / Amd 3:1994 (E)
ISODEC 10021-7/Amd.2: I) , Information technology -Text Communication - Message Oriented Text Interchange Systems
{MOTIS) - Part 7: Interpersonal messaging system - Amendment 2: Voice body part and new
ASN. 1.
2.3 Directory Systems
Replace existing clause 2.3 with the following:
This part of ISO/IEC 10021 cites the following Directory specifications:
Information technology -Open Systems Interconnection -The Directory: Models.
ISODEC 9594-2: I),
Information technology 4pen Systems Interconnection -The Directory: Selected Attribute
ISODEC 9594-6: I),
Types.
Replace bulletj) of 5.1 with the following:
,TTRIB JTE information object class of ISOfiEC 0021-5.
f) To define IPMS-MS attributes, the
The abstract-syntax defined in this part of ISOEC 10021 may be mapped to that used in previous editions as follows. Ail
ASN.1 definitions of object sets and Enumerated types which contain the ASN.l extensions marker (".'I) are îreated as if
any extension additions following the marker are absent. For definitions where the extension marker is not used, the ASN.l
comment "-- 1994 extension --I' has a similar interpretation. See 5.7 of ISO/iEC 10021-5. The effect of this is that certain
attribute-types, matching-rules, and auto-actions are not standardized for use in 1988 Application Contexts.
Replace the last sentence of 5.1 with the following:
Except for Annex J, ASN.l tags are implicit throughout the ASN.l module the annex defines; the module is definitive in that
respect.
Replace Table 1 with the following:
Table 1
Uses of the ASN.l Notation
I Subject Matter I Exposition I Reference I
+------------------------------+-------- ----------+----------- +
1 Object Identifiers l- I Annex C I
I Abstract information objects I section two I Annex D I
I Functional objects 1 clauses 10, 11, 16 1 Annex E I
I Abstract service 1 clauses 12-13 1 Annex F I
I Heading extensions I Annex A I Annex G I
1 Extended body part types I Annex B I Annex H I
1 Message store attributes I clause 19 I Annex I I
I Message store auto-actions 1 clause 19 I Annex J 1
I Upper bounds l- I Annex K I
+------------------------------+--------------------+---------- +
U To be published
3

---------------------- Page: 7 ----------------------
ISODEC 10021-7:1990 / Amd.3:1994 (E)
(6 rso/rac
5.4 Conventions for attribute-types used in Table 5
Insert the following tiew clause:
This part of ISO/IEC 10021 uses the conventions listed below in its definition of the attribute-types for the IPMS-MS
abstrac t-service.
For the column headed 'Single/Multi-valued' the following values can occur:
S single-valued
M multi-valued.
For the column headed 'Source' the following values can occur:
IPM Originate-IPM, Receive-IPM abstract-operations;
Mod Modify abstract-operation:
MS IPMS Message Store;
NRN Originate-", Receive-" abstract-operations:
ON ûriginate other-notifications, Receive other-notifications;
RN Onginate-RN, Receive-RN abstract-operations,
19 Message Store Operation
Replace the whole of existing clause 19 with the following:
ISOhEC 10021-5 defines the abstract service for a general content-independent Message Store (MS). This is an optional
component in MHS, whose purpose is to provide a continuously available storage medium to take delivery of messages on
the UA's behalf and to enable their subsequent retrieval by the UA, In addition, the MS provides the UA with facilities for
the storage of submitted messages, the classification of stored messages, the correlation of reports with the messages to
which they refer, the modification by the MS-user of certain ateibutes of stored messages, and the logging of submission and
delivery operations. The MS can also perform certain predefined auto-actions on the MS-user's behalf.
All the entry-classes, abstract-operations, general attribute-types and general auto-actions defined in ISOB[EC 10021-5 are
available for use in Interpersonal Messaging.
An MS must perform certain Interpersonal Messaging-specific functions to qualify as an IPMS-MS and thus distinguish
itself from a generic MS. These functions are the subject of the present clause.
NOTES
1. Because the MS is an optional system component in MHS, use of the word "shall" with respect to MS specifications should not be
construed as mandating the provision of an MS or the services it provides. Use of the word "shall" with respect to MS specifications
should be construeù as mandating the specifications of an MS, if one is provided, and the relevant service component is supportd.
2. In this part of ISO/IEC 10021 the description of the IPMS-MS abstract-service assumes that all defined entry-classes are available far
use. In practice, the behaviour of a given IPMS-MS implementation will depend on its support for optional service components (e.g., the
optional entry-classes, attribute-types, matching-rules, and auto-actions) and on subscription.
3. Several new service components have been introduced in the 1994 dltion of this part of ISO/IFC 10021. However, all basic and
essential optional requirements defied far the IPMS Message Store are the same as those defîned for editions published prior to 1994.
Consequently, all enhanced facriiues introduced in the 1994 edition are additional optional.
19.1 Binding to the IPMS-MS
The IPMS-MS-user binds to the IPMS-MS as described in 7.1 of ISO/iEC 10021-5. The following should be noted when
using the MS for Interpersonal Messaging.
4

---------------------- Page: 8 ----------------------
O ISOAEC ISO/IEC 10021-7:1990 / Amd 3:1994 (E)
19.1.1 MS-bind-argument
The following components of the fetch-restrictions parameter defined in 7.1.1 of ISO/EC 10021-5 have particular
significance in this part of ISOAEC 10021:
Ailowed-content-types: The names of the Object Identifiers for the IPM content types defined in this part of
a)
ISO/iEC 10021 are id-mct-p2-1984 and id-mct-p2-1988. See Annex C.
Allowed-EITs: The names of the Object Identifiers for the encoded-information-types defined in this part of
b)
ISODEC 10021 are enumerated in Annex C. See also 20.4.
NOTE - An extension to the MS-bind abstract-operation for the IPMS-MS is defined in 19.5.1.
19.1.2 MS-bind-result
The avaiiabie-auto-actions parameter defined in 7.1.2 of ISODEC 10021-5 has particular significance in this part of
ISODEC 10021. Where this indicates support for the IPM auto-forward auto-action, this shall operate as defined in 19.8.2;
where support for the IPM auto-acknowledgement auto-action is indicated, this shall operate as defined in 19.8.3; where
support for the IPM auto-correlate auto-action is indicated, this shall operate as defined in 19.8.4; where support for the IPM
auto-discard auto-action is indicated, this shall operate as defined in 19.8.5.
19.2 Creation of Information Objects
An IPMS-MS shall satisfy the following requirements related to the information objects it maintains:
IPM or IPN that is
The IPMS-MS shall maintain a separate information object for each (message containing an)
a)
submitted to it or delivered to it.
The IPMS-MS shall maintain as a separate information object not only each (message containing a) forwarding IPM
b)
(pursuant to Item a) but also each (message containing a) forwarded PM (recursively).
The IPMS-MS shall maintain as a separate information object the Returned IPM which may be present in an NRN.
c)
19.2.1 Mapping an IPMS Message to an MS entry
When an IPM or IPN is stored in the IPMS-MS, a corresponding MS entry is created in the appropriate entry-class. The
attributes of such an entry are derived from various sources:
some attributes, such as Sequence-number and Creation Time, are generated by the MS for administrative purposes;
a)
some attributes are derived from components of the MHS Envelope;
b)
some attributes summarize the contents of the IPM,
c)
some attributes are derived from the Heading fields of the IPM,
d)
some attributes are derived from the body parts of the PM,
e)
some attributes are derived from the component fields of the iPN
f)
some attributes correlate IPMs and IPNs with other messages to which they are related,
g)
some attributes are created by the IPMS-MS-user by means of the Modify abstract-operation.
h)
5

---------------------- Page: 9 ----------------------
ISOIIEC 10021-7:1990 I Amd3:1994 (E)
CP ISO/IEC
Besides these direct mappings, the IPMS-MS shall also create attributes corresponding to the complete Envelope, the
complete Content, and the complete IPM Heading. Thus the same information may be logically present in more than one
attribute.
Figure 5 illustrates the mapping of an IPM to an MS entry.
n
I 'I
Content
L
Message
MS Entry
Fqure 5 - Mapping an IPM to an MS entry
19.2.2 Mapping of forwarding messages in the IPMS-MS
The IPMS-MS shall model a forwarding IPM as a main-entry with one child-entry for each forwarded IPM the message
contains, A simple illustration of this mapping is shown in Figure 6.
fi Envelope I amiope -
I
U
n Content
Forwarding Forwarded
MAIN-ENTRY
CHILD-ENTRY
IPM IPM
Figure 6 - Mapping a Forwarding message to an IPMS-MS entry
6

---------------------- Page: 10 ----------------------
ISODEC 10021-7:l
O ISO/IEC
19.2.3 Presence of General-attributes in child-entries
The following general attribute-types shall be present in the child-entries of an IPM or NRN when stored in an entry-class for
which the attribute is defined: content-length, content-type, creation-time, entry-type, parent-sequence-number, retrieval-
status, sequence-number. The absence of a delivery envelope precludes the generation of other general attribute-types whose
presence is defined as mandatory in Table 2 of ISO/IEC 10021-5 for the following types of child-entry:
the Returned IPM optionally present in an NRN,
a)
the Message body-part (i.e. the forwarded IPM) of a forwarding iPM where the Parameters component of the body
b)
part is absent.
In the case where a child-entry is generated from an IPMs Message body part in which the Parameters component is present:
if Delivery-time is present in Parameters then the message-delivery-time general-attribute-type shall be present;
a)
if Delivery-envelope is present in Parameters then all the other mandatory general-attribute-types defined for a
b)
delivered-message entry shall be present except for message-delivery-envelope and message-del
which shall be absent.
The entry-type general-attribute of child-entries in the Delivery and Delivery-log entry-classes shall have the value
delivered-message, except those containing returned content which shall have the value returned-content. The entry-type
general-attribute of child-entries present in the Submission and Submission-log entry-ciasses shall have the value submitted-
message.
The example in Table 2 illustrates the use of child-entries in the Delivery entry-class. This table shows four sets of entries
corresponding, respectively, to a delivered IPM, a delivered RN, a delivered NRN, and a deli ceming a
previously submitted IPM.
Table 2 - Example of the use of child-entries
19.3 Maintenance of Attributes
An IPMS-MS shall satisfy the following requirements related to the MS attributes which it supp
a) For each IPM or IPN it holds, including the child-entry of a delivery report containing
MS shall support the attributes defined in 19.6.
For each body part type present in a stored IPM, the IPMS-MS shall maintain an Extended body part attribute
b)
(and, when appropriate, an attribute corresponding to the Parameters component of that body part type) such that it
7

---------------------- Page: 11 ----------------------
IsO/IEC 10021-21990 / Amd3:1994 (E) Q ISO/IEC
contains all body parts of that type regardiess of whether they were conveyed to the IPMS-MS as basic or
Extended body parts of the IPM.
For each IPM it holds, the PMS-MS shall give the following meanings to the defined values of the MS retrieval-
status general-attribute:
new: No attribute values have been conveyed to the UA.
i)
listed: At least one attribute value has been conveyed to the UA, and at least one body part has not
ii)
been conveyed.
iii) processed: All body parts (the body parts as single attributes, or the data component only from all
body parts, or the Body attribute, or the Content general-attribute) have been conveyed to the UA.
NOTE - The IPMS-MS-user may use the Modify abstract-operation to change the value of the retrieval-status attribute,
provided that its existing value is listed and replacomcnt value is processed. See 11.2.68 of ISO/IEC 10021-5.
For each IPN it holds, the IPMS-MS shall give the following meanings to the defined values of the MS retrieval-
status general-attribute:
new: No attribute values have been conveyed to the UA.
i)
listed: At least one attribute value has been conveyed to the UA, and at least one attribute other
ii)
than Returned IPM has not been conveyed.
iii) processed: All attributes, with the possible exception of Returned IPM, have been conveyed to the
UA.
When the MS retrievai-status general-attribu
...