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

Information technology - Text Communication - Message-Oriented Text Interchange Systems (MOTIS) - Part 7: Interpersonal Messaging System - Amendment 3

Technologies de l'information — Communication de texte — Systèmes d'échange de texte en mode message — Partie 7: Système de messagerie de personne à personne — Amendement 3

General Information

• Status: Withdrawn
• Publication Date: 21-Dec-1994
• Withdrawal Date: 21-Dec-1994
• ICS: 35.240.20 - IT applications in office work
• Technical Committee: ISO/IEC JTC 1 - Information technology
• Drafting Committee: ISO/IEC JTC 1 - Information technology
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 17-Jul-1997
• Completion Date: 30-Oct-2025

Relations

• Amends: ISO/IEC 10021-7:1990 - Information technology - Text Communication - Message-Oriented Text Interchange Systems (MOTIS) - Part 7: Interpersonal Messaging System
• Effective Date: 06-Jun-2022
• Revised: ISO/IEC 10021-7:1997 - Information technology - Message Handling Systems (MHS): Interpersonal messaging system - Part 7:
• Effective Date: 16-Oct-2025
• Child: ISO/IEC 10021-7:1990 - Information technology - Text Communication - Message-Oriented Text Interchange Systems (MOTIS) - Part 7: Interpersonal Messaging System
• Effective Date: 18-Dec-2008

Standards Content (Sample)

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)

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.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
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

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.

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.
(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.
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
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.
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)
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
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
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-attribute is retrieved in the result of an abstnict-operation, the value returned
shall reflect the state of affairs prior to the execution of that abstract operation.
The performance of the IPM auto-forward auto-action shall cause the MS retrieval-status generai-atiribute of the
auto-forwarded entry to be set to processed.
The content-type attribute of each (message containing an) IPM or II" that is stored in the IPMS-MS shall have the
value id-mct-p2-1984 or id-mct-p2-1988 (see Annex C), as appropria&, depending upon the content type of the
message (see 20.2).
The general (content independent) attributes that may occur in the MS entry-classes are documented in ISO/IBC 10021-5
All content independent MS attributes can be used for the content defined in this part of ISO/iEC 10021. The IPMS specific e
atîributes are defined in 19.6. All general atîribute types classified as mandatory in Tables 2 and 3 of ISO/IEC 10021-5 shall
be supported.
19.4 Notification of Non-receipt
When it deletes an IPM while performing the Delete abstract-operation or the Auto-delete autu-action of the MS Abstract
Service, the IPMS-MS shall generate an NRN if, and only if, one is requested by means of the Notification-requests
component of the subject recipient specifier of the deleted IPM, and the IPM's entry-status has the value lisred. In the case
of the Delete abstract-operation, the NRN shall not be generated if prevent-NRN-gendon is specified in the delete-
extensions parameter of the Delete abstract-operation which deletes the IPM (see 19.5.3).
The NRN shall have the common fields prescribed for the performance of auto-acknowledgement (see 18.5.2.1).
The NRN shaii have the foilowing non-receipt fields:
Non-receipt reason: The value ipm-discarded.
a)
O ISO/IEC ISOAEC 10021-21990 / Amd 3:1994 (E)
Discard reason: The value ipm-deleted.
b)
cl Auto-forward comment: Omitted.
Returned ZPM: If the return of the IPM is requested by means of the Notification-requests component of its subject
d)
recipient specifier, and the Converted-encoded-information-types component of Message Delivery's Envelope
argument is absent, the IPM. Omitted otherwise.
The IPMS-MS shall submit the NRN by invoking MS-message-submission. Message Submission's Envelope argument shall
be as prescribed for auto-acknowledgement (see 1852.2). except that notification-type may be set to type 2, its Content
argument determined from the NRN as specified in 20.1. If the IPM auto-correlate auto-action is in effect then the IPMS-
MS shall add the sequence-number of the submitted XPN to the AC Submitted IPNs attribute of the entry representing the
deleted IPM in the Message-log entry-class; in addition, that entry's AC Submitted IPN Status attribute is given the value
ipm-discarded.
19.5 IYMS-MS abstract-operation extensions
The MS abstract-service defined in ISO/IEC 10021-5 provides a general mechanism for extending various abstract-
operations and errors, in order to satisfy additional requirements specific to particular content-types. The extensions used by
the IPMS-MS are defined below.
With the exception of the forwarding-request extension, each extension is defined as an instance of the MS-EXTENSION
6.6 of ISO/IEC 10021-5).
information object class (see
19.5.1 MS-bind extensions
The IPMS-MS-user may make use of the bind-extensions parameter of the MS-bind abstract-operation (see 7.1.1 of ISO/iE?C
10021-5) to cause the suspension of the XPM auto-acknowledgement auto-action, as defined in 19.8.3. The suspend-auto-
acknowledgement information object is defined as follows:
suspend-auto-acknowledgement MS-EXTENSION ::= {
NULL IDENTIFIED BY id-mst-suspend-auto-acknowledgement }
The presence of this object in the bind-extensions parameter of the MS-bind abstract-operation causes the suspension of the
IPM auto-acknowledgement auto-action for entries whose retrieval-status becomes processed during the abstract-association.
There are no parameters. Where an IPMS-MS does not provide the PM auto-acknowledgement auto-action. it shall ignore
the presence of the suspend-auto-acknowledgement bind-extension.
NOTE - Where a UA itself generates RNs, it should select suspend-auto-acknowledgement. to avoid the interference which could arise if
the user employs another UA which, by registration, has activated the IPM-auto-acknowledgement auto-action.
19.5.2 MS-message-submission extensions
The IPMS-MS provides two methods for incorporating stored iPMs in the body of a submitted IPM. If a 1988 Application
Context is in use, the forwarding-request extension enables the IPMS-MS-user to nominate a delivered IPM for forwarding;
see 19.5.2.1.
If a 1994 Application Context is in use, the IPM-submission-options enables an IPMS-MS-user to nominate any stored IPM
or XPM body part for inclusion in the Body of a submitted IPM, see 19.5.2.2.
19.5.2.1 Forwarding-request extension
is in use (see 5.7 of ISO/IEC 10021-5) then an IPMS-MS supports the forwarding-request
If a 1988 Application Context
an PM, including Heading and
extension as specified in 8.3.1.1 of ISO/IEC 10021-5. The IPMS-MS-user may submit
Body, using the MS-message-submission abstract-operation, and identify by means of the forwarding-request extension, a
ISOliEC 10021-7:1990 / Amd.3:1994 (E) O rsomc
message that is already stored in the IPMS-MS which is to be combined with the submitted message Body for forwarding to
the message's recipient(s).
The submitted message Body and the forwarded message are then combined by inserting the forwarded message as a
Message body part into the submitted message Body. The Message body part becomes the last body part of the submitted
message Body.
19.5.2.2 IPM Submission Options
The submission-options argument of the MS-message-submission abstract-operation defined in 8.3.1.1 and 8.1.6 of ISOmC
10021-5 allows for the specification of MS-submission-extensions. The IPMS-MS makes use of this argument when
performing the MS-message-submission abstract-operation, in order to support the incorporation of stored IPMs and stored
body parts in submitted IPMs.
The IPM-submission=options information object is defined as follows:
ipm-submission-options MS-EXTENSION ::- (
IPMSubmissionOptions IDENTIFIED BY id-mst-submission-options 1
IPMSubmissionOptions ::E SET {
assembly-instructions [O] BodyPartReferences )
BodyPartReferences ::= SEQUENCE OF BodypartReference
BodyPartReference ::= CHOICE (
stored-entry [O] SequenceNumber,
stored-content Il] SequenceNumber,
submitted-body-part [2] INTEGER (1. .MAX) I
stored-body-part [3] SEQUENCE (
message-entry SequenceNumber
body-part-number INTEGER (l.MAX) ) )
The single component of IPM-submission-options has the following meaning:
Assembly-instructions (M): This component instructs the IPMS-MS to assemble stored body parts or stored IPMs with the
present submitted IPM, before submittirig the resulting IPM to the MTS (or storing it as a draft-message entry). The IPMS-
MS shall construct the new Body by assembling body parts in the order specified in the argument, i.e. the sequence of body
parts which forms the new Body is determined by the sequence of body-part-references. If stored-entry is specified, it may
identify an IPM, IPN, or Report. The new body part constructed from the stored-entry will be, respectively, a Message body
part, a Notification body part, or a Report body part. If stored-content is specified, the new body part constructed from the
identified entry will be a Forwarded Content body part. If submitted-body-part is specified, the new body part is a bod
part of the present submitted lPM (identified by number). If stared-body-part is specified, the new body part is copied fro nya
the entry identified by message-entry, with the body-part-number indicated. Body parts are numbered starting at '1'.
In a Message body part constructed from a stored IPM which represents a delivered-message entry, the Parameters
component shall contain delivery-time and should contain delivery-envelope. In a Message body part constructed from a
stored IPM which represents a submittqd-message entry or draft-message entry, the Parameters component shall not contain
delivery-time.
NOTES
1. The presence of delivery-envelope in the Parameters component of a Message body part does not imply that the body part was derived
from a delivered-message. This derivation is implied (but not verified) by the presence of delivery-time.
2. The assembly of body-paris from entries with content-type other than IPM is possible only for body parts whose definition is
compatible with IPM (as stated in the relevant content-type Specification), or for which des of conversion into IPM body parts are
defined.
The actions performed by an IPMS-MS when the IPM-submission-options parameter is present in an MS-message-
submission argument are defined in 19.9.2.
O ISO/iEC
ISO/IEC 10021-7:1990 / Amd 3:1994 (E)
19.5.2.3 IPM submission errors
When an IPMS-MS performs the MS-message-submission abstract-operation of ISO/iEC 10021-5, the PMS-specific errors
defined below may be reported. These are reported as MS-extension-errors, as defined in 9.12 of ISO/EC 10021-5.
The IPM-submission-errors information object set comprises the submission errors defined for the IPMS-MS:
1PMÇubrnissionError.s MS-EXTENSION ::= I
invalid-assembly-instructions I
invalid-ipn,
... -- For future extension additions -- )
The invalid-assembly-instructions error shall be reported where the assembly-instructions component of IPM-submission-
options is present, but the message submitted is not an IPM, or the assembly-instructions component contains a reference to
an entry whose content-type is not compatible with IPM, or contains a reference to a body part not present in the submitted
or stored message. The invalid body-part-references are reported in the error.
invalid-assembly-instructions MS-EXTENSION ::E {
BodypartReferences IDENTIFIED BY id-mst-invalid-assembly-instructions 1
0 The invalid-IPN error shall be reported if the UA submits an IPN concerning a message for which an IPN has already been
sent, except that an RN may be generated for an auto-forwarded IPM where an NRN indicating IPM-auto-forwarded has
already been sent.
invalid-ipn MS-EXTENSION ::= {
NULL IDENTIFIED BY id-mst-invalid-ipn }
19.5.3 Delete extensions
The IPMS-MS-user may make use of the delete-extensions parameter of the Delete abstract-operation (see 8.2.4.1 of
ISO/IEC 10021-5) to prevent the generation of an NRN when an IPM is deleted, as defined in 19.4. The prevent-"-
generation extension is defined as follows:
prevent-nrn-generation MS-EXTENSION ::= {
NULL IDENTIFIED BY id-rnst-prevent-nrn-generation )
NOTE - This may be used to prevent the automatic generation of NRNs where a UA implementation itself generates NRNs.
* 19.6 IPMS-MS Attributes
As described in lSO/lEC 10021-5, an MS maintains and provides access to certain attributes of each information object it
holds. An attribute comprises a type and, depending upon the type, one or more values. Attributes that may assume several
values simultaneously (all pertaining to one object) are termed multi-valued, those that may assume just one value, single-
valued. Some attributes perlain to information objects of all kinds; others only to those of certain kinds (e.g., those of section
two).
This clause defines the MS attributes specific to Interpersonal Messaging. Each IPMS-MS attribute is defined as an instance
of the ATTRIBUTE information object class (see 6.3.3.3 of ISO/IEC 10021-5).
All the IPMS-MS attributes defined in this part of ISO/IEC 10021, except those corresponding to Extended body part types
(which cannot be enumerated; see 19.6.3.3). are listed alphabetically, for reference, in the first column of Table 5 in 19.6.7.
Table 3 indicates their presence in IPM, NRN, RN, and ON entries of the Stored-message, Submission-log, and Delivery-log
entry-classes of the MS. For entries of the Submission-log and Delivery-log entry-classes the Body attributes (see 19.6.3)
shall not be present. Table 3 also indicates whether the attribute is single-valued or multi-valued, and whether it is available
for retrieval by the List and Summarize abstract-operations. Rules for the presence and maintenance of generai-attributes in
the IPMS-MS are defined in 19.2 and 19.3. No requirements are placed on the IPMS-MS-user for the support of any of the
IPMS-MS attributes.
ISOlIEC 10021-7:1990 / Amd3:1994 (E) O ISO/IEC
Where a delivery report contains returned content, the child-entry so created shall possess the attributes indicated for an
PM, NRN, RN, or ON as appropriate. Where an NRN contains a returned PM, the child-entry so created shall possess the
attributes indicated for an PM. Where an IPM (whether submitted, delivered, in the returned content of a delivery report, or
present in an NRN), contains a Message body part, the child-entry so created shall possess the attributes indicated for an
IPM.
Table 3 applies to all entries except those of the Auto-action-log entry-class. There are no IPMS-specific attributes defined
for the Auto-action-log entry-class. See 5.2 of ISO/IEC 10021-5 for an elaboration of the table's legend.
I
ISOhEC lûû21-7:1990 / Amd 3:1994 (E)
Table 3
Summary of IPMS-specific common attributes
Attribut e
- A .
Acknowledgment Mode
Authorizing Users
Auto-forward Comment
Auto-forwarded
Auto-submitted
- B .
Bilaterally Defined Body Parts
Blind Copy Recipients
Body
Body Part Summary*
- c --_____--_-__--_____________
Conversion EITs
Copy Recipients
- D .
Discard Reason
MIO--IC - --
G3 Facsimile Body Parts
MIO--IC - --
G3 Facsimile Data
MIO--IC - --
G3 Facsimile Parameters
MI O-- IC - --
G4 Class 1 Body Parts
- H .
Heading
- 1 ----___c---___----__c______c
IA5 Text Body Parts
IA5 Text Data
IA5 Text Parameters
Import ance
Incomplete Copy
IPM Auto-discarded*
IPM Entry Type
IPM Intended Recipient
IPM Synopsis
IPN Originator
(i3 ISO~C
ISO/IEC 10021-7:1990 / Amd3:1994 (E)
-------------------------------------------+
+- Legend
IV Single/multi valued I
Support level by IPMS-MS: I
for Stored-message entry-class I
I
I D1 for Delivery-log entry-class I
I $1 for Submission-log entry-class I
IP Presence in each IPM-entry-type I
Available for List, Alert I
Available for Summarize I
Not defined for 1988 Application Contexts I
.......................................
...