ISO/IEC 10021-1:1990

INTERNATIONAL
ISOAEC
STANDARD 10021-1
First edition
1990-12-01
Information technology - Text Communication
- Message-Oriented Text Interchange Systems
(MOTIS) -
Part 1:
System and Service Overview
Technologies de I’Yinformation - Communication de texte - Systemes d%change
de texte en mode message -
Partie 1: Pkentation gtWrale du Systeme et des Services
Reference number
ISO/IEC 10021-1 : 1990 (E)
ISO/IEC 10021-1: 1990 (E)
- Capabilities of MHS
Section three
12 Naming and Addressing
12.1 Introduction
.....................................................................
12.2 DirectoryNames
....................................
12.3 O/RNames 19
......................................
12.4 OjRAddresses .
13 MHS Use of Directory .
: . 20
13.1 Introduction
13.2 FunctionalModel.
...................................
13.3 Physical Configurations
.................................
14 Distribution Lists in MHS
........... 22
14.1 Introduction . . :
...................................................
14.2 PropertiesofaDL
...................................
..... 22
14.3 Submission
.................................
14.4 DLUseofaDirectory
..................................
14.5 DLExpansion
.....................................
14.6 Nesting
........................................
14.7 Recursion Control
...................................
14.8 Delivery
.......................................
14.9 Routing Loop Control
..................................
14.10 Notifications
......................................
14.11 DL Handling Policy
...................................
Security Capabilities of MHS
15 .
........... 25
15.1 Introduction . . :
15.2 MHSSecurityThreats
..................................
15.3 SecurityModel
.....................................
15.4 MHS SecurityFeatures
.................................
15.5 Security Management
..................................
16 ConversioninMHS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
17 Clause 17 of the corresponding CCIlT Recommendation is not part of this International Standard
Section four - Elements of Service
18 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
19 Classification
.......................................................
: .
19.1 PurposeofClassification
3 1
19.2 Basic Message Transfer Service .
19.3 MT Service Optional User Facilities .
19.4 Base MH/PD Service Intercommunication .
19.5 Optional User Facilities for MHED Service Intercommunication .
19.6 BaseMessageStore
...................................
19.7 MS Optional User Facilities .
19.8 Basic Interpersonal Messaging Service .
19.9 IPM Service Optional User Facilities . 34
Annexes
A
GlossaryofTerms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
B Definitions of Elements of Service . . . . . . . . . . . . . . . . . . . . . . . . . 47
New Elements of Service in 1988 . . . . . . . . . . . . . . . . . . . . . . . . . . 62
C
D Differentes Between ISO/IEC 10021-1 and CCITT Recommendation X.400 . . . . . . . . 65
. . .
ISO/IEC 100214 : 1990 (E)
Foreword
ISO (the International Organization for Standardiza tion) and IEC (the International
Electrotechnical Commission) form the specialized System for worldwide standardiz-
ation. National bodies that are members of ISO 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. ISO and IEC technical
committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
In the field of information technology, ISO 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 9’0 of the national bodies casting
a vote.
International Standard ISWIEC IO0214 was prepared by Joint Technical Committee
ISO/IEC JTC 1, Information technology.
ISO/IEC 10021-1 consists of the following Parts, under the general title: lnormation
technology - Text Communication - Message-Qrien ted Text ln terchange Systems
(iWOT1S) -
Part 1: System and Service Overview
- Part 2: Overall Architecture
Part 3 : Abstract Service Definition Conven tions
Part 4: Message Transfer System: Abstract Service Definition and Procedures
Part 5: Message Store: Abstract Service Definition
- Part 6: Protocol Speczjkations
Part 7: In terpersonal Messaging System
Annexes A, B, C and D are for information only.

ISO/IEC 10021~1:1990@)
Introduction
This pm of ISO/IEC 10021 is one of a number of parts of ISO/IEC 10021 @he International Standard for Message-Oriented
Text Interchange Systems (MOTIS)). ISO/IEC 10021 provides a comprehensive specification for Message Handling
comprising any number of cooperating open-Systems.
Message Handling Systems and Services enable users to exchange messages on a store-and-forward basis. A message submitted
by one User, the originator, is conveyed by the Message Transfer System (MTS), the principal component of a larger Message
Handling System (MHS), and is subsequently delivered to one or more additional users, the message’s recipients.
An MHS comprises a variety of interconnected functional entities. Message Transfer Agents (MTAs) cooperate to Perform the
store-and-forward message transfer function. Message Stores (MSs) provide storage for messages and enable their Submission,
retrieval and management. User Agents (UAs) help users access MHS. Access Units (AUS) provide links to other
communication Systems and Services of various kinds (e.g., Telematic Services, Postal Services).
This part of ISO/IEC 10021 specifies the Overall System and Service description of Message Handling capabilities.
This part of ISO/IEC 10021 is technically aligned with CCITT Recommendation X.400 (1988).

This page intentionally left blank

ISOAEC 10021~1:1990 (E)
INTERNATIONAL STANDARD
Information technology -
Text Communication -
Message-Oriented Text Interchange Systems (MOTIS) -
Part 1 : System and Service Overview
Section one - Introduction
Scope
This part of ISO/IEC 10021 defines the Overall System and service of an MHS and serves as a general overview of MHS.
The layout of parts of
Other aspects of Message Handling Systems and Services are defined in other Parts of ISO/IEC 10021.
ISO/IEC 10021 defining the Message Handling System and Services is shown in Table 1.
The technical aspects of MHS are defined in other parts of ISO/IEC 10021. The Overall System architecture of MHS is defined
in ISO/IEC 10021-2.
Table 1
Structure of MHS Standards
, JOINT MHS JOINT SUPPORT CCITT ONLY
NAME OF STANDARDiRECOMMENDATION
ISO/IEC CCITT ISO CCITT SYSTEM SERVICE
10021-1 x.400 F.400
MHS: System and Service Overview
10021-2 X.402
MHS: Overall Architecture
x.403
MHS: Conformance Testing
10021-3 x.407
MHS: Abstract Service Definition Conventions
X.408
MHS: Encoded Information Type Conversion Rules
100214 x.411
MHS: MTS: Abstract Service Definition and Procedures
100215 x.413
MHS: MS: Abstract Service Definition
MHS: Protocol Specifications 100216 x.419
10021-7 X.420
MHS: Interpersonal Messaging System
T.330
Telematic Access to IPMS
F.401
MHS: Naming & Addressing for Public MH Services
F.410
MHS: The Public Message Transfer Service
MHS: Intercommunication with Public
Physical Delivery Services F.415
F.420
MHS: The Public IPM Service
F.421
MHS: Intercommunication Between IPM Service and Telex
F.422
MHS: Intercommunication Between IPM Service and Teletex
7498 x.200
OSI: Basic Reference Model
8824 X.208
OSI: Specification of Abstract Syntax Notation One (ASN.l)
OSI: Specification of Basic Encoding Rules for
8825 X.209
Abstract Syntax Notation One (ASN.l)
8649 X.217
OSI: Association Control: Service Definition
OSI: Association Control: Protocol Specification 8650 X.227
9066-1 X.218
OSI: Reliable Transfer:Model dz Service Definition
9066-2 X.228
OSI: Reliable Transfer: Protocol Specification
OSI: Remote Operations:Model,
X.219
9072- 1
Notation & Service Defmition
9072-2 X.229
OSI: Remote Operations: Protocol Specification
ISOIIEC 10021-1 : 1990 (E)
2 Normative references
The following Standards contain provisions which, through reference in this text, constitute provisions of this part of ISO/IEC
10021. At the time of publication, the editions indicated were valid. All 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 ISO and IEC maintain registers of currently valid International Standards.
ISO 7498 : 1984, Information processing Systems - Open Systems Interconnection - Basic Reference Model
Information processing Systems - Open Systems Interconnection - Service definition for the
ISO 8649 : 1988,
Association Control Service Element
- Specification of Abstract Syntax
ISO 8824 : 1990, Information processing Systems - Open Systems Interconnection
Notation One (ASN.1)
ISO 8825 : 1990, Information processing Systems - Open Systems Interconnection -Specijication of Basic Encoding
Rules for Abstract Syntax Notation One (ASN.1)
ISO/IEC 9066-1 : 1989, Information processing systems - Text Communication - Reliable Transfer
Part 1: Model and Service definition
ISO/IEC 9072-1 : 1989, Information processing systems - Text Communication - Remote Operations
Part 1: Model, notation and Service definition
ISO/IEC 9594 : 1990, Information technology - The Directory -
Part 1: Overview of concepts, models and Service
Part 2: Mo&ls
Part 3: Abstract Service definition
Part 4: Procedures for distributed Operation
Part 5: Protocol specifications
Part 6: Selected attribute types
Part 7: Selected Object classes
Part 8: Authentication framework
ISO/rEC 10021 : 1990,
Information technology - Text Communication -
Message-Oriented Text Interchange Systems (MOTIS) -
Part 1: System and Service Overview
Part 2: Overall Architecture
Part 3: Abstract Service Definition Conventions
Part 4: Message TraMer System: Abstract Service Definition and Procedures
Part 5: Message Store: Abstract Service Definition
Part 6: Protocol Specifications
Part 7: Interpersonal Messaging System
CCITT Recommendation T.330 : 1988,TeZemtic Access to IPMS
CCITT Recommendation X.408 : 1988,
Message Handling Systems, Encoded Information Type Conversion Rules

ISO/IEC 10021~1:1990(E)
3 Definitions
For the purposes of this part of ISO/IEC 10021 the definitions given in Annex A and the following definitions apply.
Definitions of the Elements of Service applicable to MHS are contained in Annex B.
31 . Open Systems Interconnection
This part of ISO/IEC 10021 makes use of the following terms defined in ISO 7498:
Application Layer
application-process
Open Systems Interconnection
OS1 Reference Model
32 . Directory Systems
This part of ISO/IEC 10021 makes use of the following terms defined in ISO/IEC 9594-1:
directory entry
a>
dirwtory System agent
b)
Directory System
c>
directory User agent
@
This patt sf ISO/IEC 10021 makes use of the following terms defined in ISO/IEC 9594-2:
attribute
8foUP
member
name
ISO/IEC 100214 : 1990 (E)
Abbreviations
A Additional
ADMD Administration Management Domain
AU Access Unit
Contractual Agreement
CA
DL Distribution List
DSA Directory System Agent
DUA Directory User Agent
E Essential
EIT Encoded Information Type
Input/Output
I/O
IP Interpersonal
IPM Interpersonal Messaging
IPMS Interpersonal Messaging System
Management Domain
Message Handling
MHS Message Handling System
MS Message S tore
Message Transfer
Message Transfer Agent
MTA
Message Transfer System
MTS
Not Applicable
N/A
Originator/Recipient
O/R
Open System Interconnection
OS1
Physical Delivery
PD
PDAU Physical Delivery Access Unit
Physical Delivery System
PDS
Per-message
PM
Per-recipient
PR
PRMD Private Management Domain
Public Telex Access Unit
PTLXAU
TLMA Telematic Agent
Telex Access Unit
TLXAU
Teletex
User Agent
UA
Conventions
In this Standard the expression “Administration” is used for shortness to indicate a telecommunication Administration, a
recognized private operating agency, and, in the case of intercommunication with Public Delivery Service, a Pastal
Administration.
ISO/IEC 100214 : 1990 (E)
Section two - General Description of MHS
6 Purpose
This part of ISO/IEC 10021 is one of a number of parts of ISO/IEC 10021 and describes the System model and Elements of
Service of the Message Handling System (MHS) and Services. This part of ISO/IEC 10021 overviews the capabilities of an
MHS that are used for the Provision of MH Services to enable users to exchange messages on a store-and-forward basis.
The Message Handling System is designed in accordance with the principles of the Reference Model of Open Systems
Interconnection(OS1 Reference Model) (ISO 7498) and uses the Presentation Layer Services and Services offered by other, more
general, Application Service Elements. An MHS tan be constructed using any network fitting in the scope of OSI. The
Message Transfer Service provided by the MTS is application independent. An example of a standardized application is the
IPM Service. End Systems tan use the MT Service for specific applications that are defined bilaterally.
Elements of Service are the Service features provided through the Application Processes. The Elements of Service are
considered to be components of the Services providecl to users and are either elements of a basic service or they are optional
User facilities, classified either as essential optional wer facilities, or as additional optional user facilities.
Functional Model of MHS
The MHS functional model serves as a tool to aid in the development of International Standards for MHS, and aids in
describing the basic concepts that tan be depicted graphically. It comprises several different functional components that work
together to provide MH Services. The model tan be applied to a number of different physical and organizational
configurations.
7.1 Description of the MHS Model
In this model, a User is either a person or a Computer process.
A functional view of the MHS model is shown in Figure 1.
Users are either direct users (i.e. engage in message handling by direct use of MHS), or are indirect users (i.e. engage in
message handling through another communication System (e.g. a Physical Delivery System) that is linked to MHS). A user is
referred to as either an originator (when sending a message) or a recipient (when receiving a message). Message Handling
Elements of Service define the set of message types and the capabilities that enable an originator to transfer messages of those
types to one or more recipients.
ISO/IEC 10021-1 : 1990 (E)
I
/
User
User 1
, ,
AU
Q
1 User /4-
\
1 User
User L
Services , 4
/ ,
* 1): Flow from PD Services to the PDAU shown is for notifications.
Message input from PDS to MHS is not currently possible.
Figure 1
MHS Functional Model
An originator prepares messages with the assistance of his User Agent. A User Agent @JA) is an application process that
interacts with the Message Transfer System (MTS) or a Message Store (MS), to submit messages on behalf of a Single User.
The MTS delivers the messages submitted to it, to one or more recipient UAs, Access Units (AUS), or MSs, and tan return
notifications to the originator. Functions performed solely by the UA and not standardized as part of the message handling
A UA tan accept delivery of messages directly from the MTS, or it tan use the
Elements of Service are called local functions.
capabilities of a MS to receive delivered messages for subsequent retrieval by the UA.
The MTS comprises a number of Message Transfer Agents (MTAs). Operating together, in a store and forward manner, the
MTAs transfer messages and deliver them to the intended recipients.
Access by indirect users of MHS is accomplished by AUS. Delivery to indirect users of MHS is accomplished by AUS, such
as in the case of physical delivery, by the Physical Delivery Access Unit (PDAU).

ISO/IEC 100214 : 1990 (E)
The Message Store (MS) is an optional general purpose capability of MHS that acts as an intermdiary between the UA and the
MTA. The MS is depicted in the MHS Functional Model shown in Figure 1. The MS is a functional entity whose Primar-y
purpose is to store and permit retrieval of delivered messages. The MS also allows for Submission from, and alerting to the
UA.
The collection of UAs, MSs, AUS and MTAs is called the Message Handling System (MHS).
7.2 Structure of Messages
The basic structure of messages conveyed by the MTS is shown in Figure 2. A message is made up of an envelope and a
content. The envelope carries information that is used by the MTS when transferring the message within the MTS. The
content is the piece of information that the originating UA wishes delivered to one or more recipient UAs.
The MTS neither
modifies or examines the content, except for conversion (see clause 16).
Figure 2
Basic Message Structure
7.3 Application of the MHS Model
7.3.1 Physical Mapping
Users access UAs for message processing purposes, for example, to create, present, or file messages.
A User tan interact with a
UA via an input/output device or process (e.g., keyboard, display, Printer etc.). A UA tan be implemented as a (set of)
computer process(es) in an intelligent terminal.
A UA and MTA tan be co-located in the same System, or a UA/MS tan be implemented in physically separate Systems. In the
first case the UA accesses the MT Elements of Service by interacting directly with the MTA in the same System. In the second
case, the UA/MS will communicate with the MTA via standardized protocols specified for MHS. It is also possible for an
MTA to be implemented in a System without UAs or MSS.
Some possible physical configurations are shown in Figures 3 and 4. The different physical Systems tan be connected by
means of dedicated lines or switched network connections.

ISO/IEC 10021-1 : 1990 (E)
I/O Device
I/O Device
Processing System
Figure 3
Co-resident UA and MTA
x
I/O Device
System
System
Termkai
Figure 4
Stand-alone UA and Co-resident MSIMTA and UA/MTA
7.3.2 Organizational Mapping
An Administration or organization tan play various roles in providing Message Handling Services. An organization in this
context tan be a Company or a non-commercial enterprise.
The collection of at least one MTA, zero or more UAs, zero or more MSs, and Zero or more AUS operated by an
Administration or Organkation constitutes a Management Domain (MD). An MD managed by an Administration is called an
Administration Management Domain (ADMD). An MD managed by an Organkation other than an Administration is called a
Private Management Domain (PRMD). An MD provides Message Handling Services in accordance with the classification of
Elements of Service as described in clause 19. The relationships between Management Domains is shown in Figure 5.

ISO/IEC 10021-1: 1990 (E)
c
b
b
c
c
c
b
L
c
b
c
c
c
b
PRMD2 $
c
I
c
c
b
b
c
b
b
b
b
b
b
b
b
b
b
b
b
d
: PRMD4 1
Country A
Country B
Figure 5
Relationships between Management Domains
1. This diagram gives examples of possible interconnections.
It does not attempt to identify all possible configurations. This
International Standard places no restrictions on interconnections between MDs, although these may be the subject of regulatory
agreements within and between countries.
ISO/IEC 10021-1 : 1990 (E)
2. PRMD 1 has connections to two ADMDs within country A;
PRMD 2 spans a country border, and has connections to an ADMD in each country;
PRMD 3 has multiple connections to ADMD 3;
PRMD 4 is only connected to other MDs by relaying through PRMD 1;
PRMD 5 has connections to other PRMDs, both within the same country (to PRMD 3) and internationally (to PRMD 1).
3. An Administration, in the context of CCITI’, that manages an ADMD, is understood as being a member of ITU or a Recognized
Private Operating Agency (RPOA).
4. The lines between MTAs represent logical connections, which implies that the MTAs have the ability to establish associations
between themselves when required using supporting OS1 layers over any physical medium.
5. The shaded boxes surrounding logical components (e.g. UAs, MTAs) represent examples of physically co-located Systems.
7.3.3 Administration Management Domain
In one country one or more ADMDs tan exist. An ADMD is characterized its Provision of relaying functions betw ‘een
bY
other Management Domains and the Provision of Message Transfer Service for the applications provided within the ADMD.
An Administration tan provide access for its users to the ADMD in one or more of the following ways:
- User to Administration provided UA
- private UA to Administration MTA
- private UA to Administration MS
- private MTA to Administration MTA
- user to Administration provided AU.
See also the examples of configurations shown in Figure 3 and Figure 4.
Administration provided UAs tan exist as part of an intelligent terminal that the User tan use to access MHS. They tan also
exist as part of Administration resident equipment beirigg part of MHS, in which case the user obtains access to the UA via an
I/O device.
In the case of a private UA, the User has a private stand-alone UA which interacts with the Administration provided MTA or
MS, using Submission, delivery and retrieval functions. A private, stand-alone UA tan be associated with one or more MDs,
provided that the required naming conventions are preserved.
A private MTA as part of an PRMD tan access one or more ADMDs in a country, following national regulations.
Access tan also be provided by Administration provided AUS described in clauses 10 and 11.
7.3.4 Private Management Domain
An organization other than an Administration tan have one or more MTA(s), and zero or more UAs, AUS and MSs forming a
PRMD which tan interact with an ADMD or other PRMD on an MD to MD (MTA to MTA) basis. A PRMD is characterized
by the Provision of messaging functions within that Management Domain.
A PRMD tan have access to one or more ADMDs as shown in Figure 5. However, in the case of a specific interaction
between a PRMD and an ADMD (such as when a message is transferred between MDs), the PRMD is considered to be
associated only with that ADMD.
As a national matter, the name of a PRMD tan be either nationally unique or relative to the associated ADMD.
If a PRMD is
associated with more than one ADMD, the PRMD tan have more than one name.
ISOAEC 10021-1: 1990 (E)
7.4 The Message Store
Because UAs tan be implemented on a wide variety of equipment, including personal Computers, the MS tan complement a
UA implemented, for example, on a personal Computer by providing a more secure, continuously available storage mechanism
to take delivery of messages on the User Agent’s behalf. The MS retrieval capability provides users who subscribe to an MS
with basic message retrieval capabilities potentially applicable to messages of all types. Figure 6 Shows the delivery, and
subsequent retrieval of messages that are delivered to an MS, and the indirect Submission of messages via the MS.
One MS acts on behalf of only one User (one O/R address), i.e. it does not provide a common or shared MS capability to
several users. See also PRMD3 of Figure 5.
When subscribing to an MS, all messages destined for the UA are delivered to the MS only. The UA, if on line, tan receive
Alerts when certain messages are delivered to the MS. Messages delivered to an MS are considered delivered from the MTS
perspective.
When a UA submits a message through the MS, the MS is in general transparent and submits it to the MTA before
confirming the success of the Submission to the UA. However, the MS tan expand the message if the UA requests the
forwarding of messages that exist in the MS.
Users are also provided with the capability to request the MS to forward selected messages automatically upon delivery.
Figure
Submission & Delive
The Elements of Service describing the features of the MS are defined in Annex B and classified in clause 19. Users are
provided with the capability based on various criteria, to get counts and lists of messages, to fetch messages, and to delete
messages, currently held in the MS.
7.4.1 Physical Configurations
The MS tan be co-located with the UA, co-
The MS tan be physically located with respect to the MTA in a number of ways.
located with the MTA, or stand-alone. From an extemal point of view, a co-located UA and MS are indistinguishable from a
stand-alone UA. Co-locating the MS with the MTA offers significant advantages which will probably make it the predominant
configuration.
7.4.2 Organizational Configurations
Either ADMDs or PRMDs tan operate MSS. All the subscriber’s messages are delivered to the MS for subsequent retrieval.
The physical and organizational configurations described above are examples only and other equally valid cases tan exist.
ISO/IEC 10021-1 : 1990 (E)
The Message Transfer Service
The MTS pmvi&s the general, application independent, store and forward Message Transfer Service. The Elements of Service
describing the features of the MT Service are defined in Annex B, and classified in clause 19.
8.1 Submission and Delivery
The MTS provides the means by which UAs exchange messages. There are two basic interactions between MTAs and UAs and
/or MSs:
The Submission interaction is the means by which an originating UA or MS transfers to an MTA the content of a
1)
message and the Submission envelope. The Submission envelope contains the information that the MTS requires to
provide the requested Elements of Service.
The delivery interaction is the means by which the MTA transfers to a recipient UA or MS the content of a message
plus the delivery envelope. The delivery envelope contains information related to delivery of the message.
In the Submission and delivery interactions, responsibility for the message is passed between the MTA and the UA or MS.
8.2
Transfer
Starting at the originator’s MTA, each MTA transfers the message to another MTA until the message reaches the recipient’s
MTA, which then delivers it to the recipient UA or MS using the delivery interaction.
The transfer interaction is the means by which one MTA transfers to another MTA the content of a message plus the transfer
envelope. The transfer envelope contains information related to the Operation of the MTS plus information that the MTS
requires to provide Elements of Service requested by the originating UA.
MTAs transfer messages containi .ng any type of binary coded information. MTAs neither interpret nor alter the content of
messages except when performing a conversion
8.3 Notifications
Notifications in the MT Service comprise the Delivery and Non-delivery Notifications. When a message, or Probe, cannot be
delivered by the MTS, a Non-delivery Notification is generated and retumed to the originator in a Report signifying this. In
addition, an originator tan specifically ask for acknowledgment of successful delivery through use of the Delivery Notification
Element of Service on Submission.
8.4
User Agent
The UA uses the MT Service provided by the MTS. A UA is a functional entity by means of which a Single direct user
engages in message handling.
UAs are grouped into classes based on the type of content of messages they tan handle. The MTS provides a UA with the
ability to identify its class when sending messages to other UAs. UAs within a given class are referred to as cooperating UAs
since they cooperate with each other to enhance the communication amongst their respective users.
NOTE - A UA tan support more than one type of message content, and hence belong to several UA classes.
8.5
Message Store
The Message Store (MS) uses the MT Service provided by the MTS. An MS is a functional entity associated with a user’s
UA. The user tan submit messages through it, and retrieve messages that have been delivered to the MS.
ISO/IEC 10021-1: 1990 (E)
8.6 Access Unit
An Access Unit (AU) uses the MT Service provided by the MTS. An AU is a functional entity associated with an MTA to
provide for intercommunication between MHS and another System or service.
8.7 Use of the MTS in the Provision of Various Services
The MTS is used by application specific Services for the Provision of Message Handling Services of various types. The
Interpersonal Messaging Service, described in clause 9, is one example of this. Other services tan be built on the foundation of
the MTS, either with corresponding Standards or as private applications.
9 The IPM Service
The Interpersonal Messaging Service (IPM Service) provides a user with features to assist in communicating with other IPM
Service users. The IPM Service uses the capabilities of the MT Service for sending and receiving interpersonal messages. The
Elements of Service describing the features of the IPM Service are defmed in Annex B, and classified in clause 19.
9.1 IPM Service Functional Model
Figure 7 Shows the functional model of the IPM Service. The UAs used in the IPM Service (IPM-UAs) comprise a specific
class of cooperating UAs. The optional Access Units shown (TLMA, PTLXAU) allow for Teletex and Telex users to
intercommunicate with the IPM Service. The optional Access Unit (TLMA) also allows for Teletex users to participate in the
IPM Service (see also clause 11). The optional Physical Delivery Access Unit (PDAU) allows IPM users to send messages to
users outside the IPM Service who have no access to MHS. The Message Store tan optionally be used by IPM users to take
delivery of messages on their behalf.
-.-.-.-.-.-.-.-.-.-.-22.
,~~~~~ pm -.-.-.-.-.-.-.-A-.-A-.-.
-.-.-.-.-.-A-A-.-.-.-.-.-.-.
~
f . .
. .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
. . . . . .=.=. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
- -.-.-.-.-.-.-.-.-.-.-.-.-.-.-. . . . . . . . . . . . . . . . . . . . . . . . . . .
.,.,.,.,., , , , ,., , , , f,.,.,.,.,.,.,.,.,.,.,.,. ., . . . . . . . . . . . . . . . . . . . . . . . . .
. . .,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,
-.-.-.-.-.-+-.-.-.-y.-.-.-.-.-.-.-.-.-.-
. . . . . . . . . . . .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- -
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
::::::: :,:,:,: . . .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- -
.-.-.-.-.-.-.-.-A-.-A-.-.-.-.-.- -
. ’ . . . . . . . . . . . . . . . .
.,.,.,.,.,.,.,.,.,.,.,.,.,. .
- - -.-A-.-.-.-.-A-.-.-.-. . . . . . . . . . . .
Figure 7
IPM Service Functional Model
ISO/IEC 10021-1 : 1990 (E)
Structure of IP-messages
9.2
The IPM class of UAs create messages containing a content specific to the IPM. The specific content that is sent from one
IPM UA to another is a result of an originator composing and sending a message, called an IP-message. The structure of an
Pmessage as it relates to the basic message structure of MHS is shown in Figure 8. The IP-message is conveyed with an
envelope when being transferred through the MTS.
Basic Message Structure
IP Message
Figure 8
IP-message Structure
memo, and the corresponding IP-message structure. The IP-message
Figure 9 Shows an analogy between a typical Office
contains information (e.g., to, cc, subject) provided by the user which is transformed by the IPM UA into the heading of the
IP-message. The main information that the User wishes to communicate (the body of the memo) is contained within the body
of the IP-message. In the example shown, the body contains two types of encoded information: text and facsimile, which form
what are called, body parts. In general, an IP-message body tan consist of a number of body parts, each which tan be of a
different encoded information type, such as voice, text, facsimile and graphics.
ISO/IEC 100214 : 1990 (E)
To: Dave
From: Jim
Heading
cc: Walter
Subject: Meeting
.---------s---w-
We will be having OUT next product
design review meeting on Friday.
Please examine the model attached
and be prepared to discuss the
implications on the schedule.
Regards
Attachment
Figure 9
HP-message Structure For a TypkaI Memo
9.3 IP-notifications
These notifications
In the IPM Service a User tan request a notification of receipt or non-receipt of a message by a recipient.
are requested by an originator and are generated as a result of some (such as reading/not reading the message) recipient action.
In certain cases the Non-receipt Notification is generated automatically by the recipient’s UA.
10 Intercommunication with Physical Delivery Services
10.1 Introduction
The value of Message Handling Systems tan be increased by connecting them to Physical Delivery (PD) Systems such as the
traditional Postal Service. This will allow for the physical (e.g., hardcopy) delivery of messages originated within MHS to
recipients outside of MHS, and in some cases will allow for the retum of notifications from the PD Service to an MHS
originator. The ability for origination of messages in the PD Service for Submission to MHS through the PDAU is not yet
provided. The capability of intercommunication between PD and MH Services is an optional capability of MHS, and is
applicable to any application such as IPM. All users of MHS will have the ability to generate messages for subsequent
physical delivery. Figure 10 Shows the functional model of this interworking. The Elements of Service describing the features
of this intercommunication are defined in Annex B and classified in clause 19.
A Physical Delivery System is a System, operated by a Management Domain, that transports and delivers physical messages.
A physical message is a physical Object comprising a relaying envelope and its content. An example of a PDS is the Postal
Service. An example of a physical message is a paper letter and its enclosing Paper envelope.
ISO/IEC 100214 : 1990 (E)
A Physical Delivery Access Unit (PDAU) converts an MH user’s message to physical form, a process called physical rendition.
An example of t.his is the printing of a message and its automatic enclosure in a Paper envelope. The PDAU Passes the
physically rendered message to a PDS for further relaying and eventual physical delivery.
Other
Telematic
Services
Figure 10
Functional Model MHS-PDS Interworking
A PDAU tan be viewed as a set of UAs, each UA being identified by a postal address.
To perform its functions, a PDAU must
support Submission (Notifications) and delivery interactions with the MTS, and also cooperate with other UAs. MH/PD
Service intercommunication is thus provided as part of the Message Transfer Service.
To enable MH users to address messages, to be delivered physically by a PDS, an address form appropriate for this exists and is
described in clause 12.
10.2 Organizational Configurations
Possible organizational mappings of the functional model described above are shown in Figure 11. In each model (A & B), the
term PD Domain denotes the domain of responsibility of an organization providing a PD Service. In A, the PD Domain
comprises an MD and a PDS. The boundary between the PD Domain and the rest of MHS is a boundary between MDs. In B,
the PD Domain comprises only the PDS; the PDAU is not patt of the PD Domain. The boundary between the PD Domain
and MHS lies at the point where the PDAU passes physical messages to the PDS.
ISO/IEC 10021-1: 1990 (E)
Figure 11
Configurations Por MH/PD Service Intercommunication
11 Specialized Access
11.1 Introduction
The Functional Model of MHS (Figure 1) contains Access Units (AUS) to allow access between MHS and other
communication Systems and services. The model Shows a generic Access Unit between MHS and Telematic Services.
Also shown is a Physical Delivery Access Unit to allow for physical delivery of MHS messages to recipients without the need
for terminal access to MHS. The access to Physical Delivery Services is available to any application carried by the MTS,
through a PDAU described in clause 10.
Other forms of access are described below.
11.2 Teletex Access
11.2.1 Registered Access to the IPM Service
The specialized Access Unit defined for Telematic access - Telematic Agent (TLMA) caters specifically for Teletex (TTX)
terminals. This TLMA provides for Teletex access to the IPM Service as shown in Figure 7. The technical provisions of this
access are defined in CCITI’ Recommendation T.330-Telematic Access Protocol to IPMS. The TLMA enables users of Teletex
terminals to participate fully in the IPM Service.
11.2.2 Non-registered (Public) Access to the IPM Service
The specialized Access Unit defined for Telematic access - Telematic Agent (TLMA) also provides for public access to the IPM
Service for TI’X users who are not registered users of the IPM Service. This is shown in Figure 7. The technical provisions
of this access are defined in CCI’IT Recommendation T.330-Telematic Access Protocol to IPMS.
ISO/IEC 100214 : 1990 (E)
11.3 Telex Access
11.3.1 Registered Access to the IPM Service
A Telex Access Unit (TLXAU) is defined in the technical Recommendations to allow the intercommunication between IPM
users and Telex users. To provide a service with this type of AU is a national matter.
11.3.2 Non-registered (Public) Access to the IPM Service
A specialized Access Unit is defined to allow the intercommunication between IPM users and Telex users. This AU provides
for public access to the IPM Service for Telex users who are not registered users of the IPM Service, and is called a Public
Telex Access Unit (PTLXAU). This is shown in Figure 7. The Telex users are not subscribers to the IPM Service, but use
some of the features of the KPM Service to pass messages to IPM users. PM users tan also send messages to Telex users via
this AU.
ISO/IEC 10021-1: 1990 (E)
Section three - Capabilities of MHS
12 Naming and Addressing
12.1 Introduction
In an MHS, the principal entity that requires naming is the user (the originator and recipient of messages). In addition,
distribution lists (DLs) have names for use in MHS. Users of MHS and DLs are identified by O/R names. O/R names are
comprised of directory names and/or O/R addresses, all of which are described in this clause.
12.2 Directory Names
Users of the MH Service, and DLs, tan be identified by a name, called a directory name. A directory name must be looked up
in a directory to find out the corresponding O/R address. The structure and components of directory names are described in
ISO/IEC 9594.
A User tan access a directory System directly to find out the O/R address of a User, or O/R addresses of the members of a DL
(both of which are outside the scope of these Recommendations). As an alternative, a User tan use the directory name and have
MHS access a directory to resolve the corresponding O/R address or addresses automatically as described in clause 14.
An MH user or DL will not necessarily have a directory name, unless they arc registered in a
directory. As directories become
more prevalent, it is of identifying
expected that directory names will be the preferred method MHS users to each other.
12.3 O/R Names
Every MH user or DL will have one or more O/R name(s). An O/R name comprises a directory name, an O/R address, or
both.
Either or both components of an O/R name tan be used on Submission of a message. If only the directory name is present,
MHS will access a directory to attempt to determine the O/R address, which it will then use to route and deliver the message.
If a directory name is absent, it will use the O/R address as given. When both are given on Submission, MHS will use the
O/R address, but will carry the directory name and present both to the recipient.
If the O/R address is invalid, it will then
attempt to use the directory name as above.
12.4 O/R Addresses
An O/R address contains information that enables MHS to uniquely identify a User to deliver a message or retum a notification
to him. (The prefix “O/R” recognizes the fact that the User tan be acting as either the originator or recipient of the message or
notification in ques tion).
An O/R address is a collection of information called attributes. ISO/lEC 10021-2 specifies a set of Standard attributes from
which O/R addresses tan be constructed. Standard attributes mean that their Syntax and semantics are defined in ISO/IEC
10021-2. In addition to Standard attributes, and to cater for existing messaging Systems, there are domain defined attributes
whose syntax and semantics are defined by Management Domains.
Various forms of O/R addresses are defined, each serving their own purpose. These forms and their purpose are as follows:
Mnemonic O/R Address: Provides a user friendly means of identifying users in the absence of a directory. It is also used for
identifying a distribution list.
.
Terminal O/R Ad&esS . Provides a means of identifying users with terminals belonging to various networks.
Numeric O/R Address: Provides a means of identifying users by means of numeric keypads.
Postal O/R Address: Provides a means of identifying originators and recipients of physical messages.
ISO/IEC 100214 : 1990 (E)
13 MHS Use of Directory
13.1 Introduction
The Directmy defined by ISO/IEC 9594 provides capabilities useful in the use and provision of a variety of telecommunication
services. This clause describes how a directory tan be used in message handling. Details tan be found in other parts of
ISO/IEC 10021.
The directory capabilities used in message handling fall into the following four categories:
The originator or recipient of a message tan be identified by means of his directory name,
a) User-fiiendly naming:
rather than his machine oriented O/R address. At any time MHS tan obtain the latter from
the former by consulting the directory.
A group whose membership is stored in the directory tan be used as a DL. The originator
b) Distribution lists(DLs):
simply supplies the name of the list. At the DL’s expansion point MHS tan obtain the
directory names (and then the O/R addresses) of the individual recipients by consulting the
diECtOI=Jt
Recipient UA capabilities: MHS
...