`
`INTERNATIONAL TELECOMMUNICATION UNION
`
`I ALI:
`
`THE INTERNATIONAL
`TELEGRAPH AND TELEPHONE
`CONSULTATIVE COMMITTEE
`
`_I
`
`BLUE BOOK
`
`
`
`
`
`VOLUME VIII — FASCICLE Vlll.7
`LETS LIBRAEY
`alcnfififiomsfihmfi $53083
`
`I“I‘DATA COMMUNICATION NETWORKS
`
`MESSAGE HANDLING SYSTEMS
`
`RECOMMENDATIONS x.4oo-x.4zop 1"
`
`
`
`IXTH PLENAHY ASSEMBLY
`
`MELBOURNE. 14-25 NOVEMBER 1988
`
`Geneva 1989
`
`ISBN 92—61-03721—6
`
`IIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIII
`
`3 1863 004 7904
`
`
`
`_—___-fl#———
`Page1of75
`
`"
`
`'
`
`7'
`
`' AT&T EXHIBIT1020
`
`Page 1 of 75
`
`AT&T EXHIBIT 1020
`
`

`

`© ITU
`
`Printed in Switzerland
`
`Page 2 of 75
`
`Page 2 of 75
`
`

`

`This material may be protected by Copyright law (Title 17 U5. Code)
`
`Recommendation 11.400 ‘)
`
`MESSAGE HANDLING SYSTEM AND SERVICE OVERVIEW
`
`3
`
`
`
`and computer based store and forward
`in various countries of telematic services
`The establishment
`eed to produce standards to facilitate
`tion with public networks creates a n
`messaging services
`in assoeia
`international message exchange between subscribers to such services.
`
`The CCITT,
`
`considering
`
`(a)
`
`the need for message handling systems:
`
`the need to transfer and store messages of different types;
`(b)
`that Recommendation X200 defines the reference model of open systems interconnection
`(c)
`applications;
`((1)
`that Recommendations X208, X217, X2113 and X219 provide the foundation for CCITT applica-
`
`for CCITT
`
`tions:
`
`(e)
`
`that the X.500—Series Recommendations define directory systems;
`
`that message handling systems are defined in a series of Recommendation
`(1')
`X407, X408, X411, X413 and X419;
`
`3: X400, X402, X403,
`
`(8
`
`)
`
`(h)
`and E420;
`
`that interpersonal message is defined in Recommendation X420 and T.330;
`handling services: E400, E401, R410
`
`that several F-Series Recommendations describe public message
`
`that several F-Series Recommendations describe intcrcommunication between public message handling
`(i)
`services and other services: E421, F415 and E422,
`
`unanimously declares
`
`thc vie
`
`w that the overall system and service overview of message handling is defined in this Recommen-
`
`dationr
`
`
`
`'3 Recommendation R400 is identical to X.400.
`
`Fascicle Vlil.7 — Rec. X400
`
`‘Page 3 of 75
`
`_______—_—________________—.
`
`

`

`CONTENTS
`
`‘PARTI - Introduction
`
`0
`
`1
`
`2
`
`3
`
`4
`
`5
`
`Introduction
`
`Scope
`
`References
`
`Definitions
`
`A borevfalions
`
`Con ventions
`
`PART 2 — General description of MHS
`
`6
`
`7
`
`8
`
`Purpose
`
`Functional model of MHS
`
`7.1
`7.2
`7.3
`7.4
`
`Description of the MHS model
`Structure of messages
`Application of the MHS model
`Message store
`
`Message transfer service
`8.1
`Submission and delivery
`8.2
`Transfer
`8.3
`Notifications
`
`8.4
`8.5
`8.6
`
`8.7
`
`User agent
`Message store
`Access unit
`
`Use of the MTS in the provision of public services
`
`9
`
`1PM service
`
`9.1
`
`9.2
`9.3
`
`1PM service functional model
`
`Structure of IP-messages
`IP-notifications
`
`10
`
`11
`
`Intercommunfcation with physical delivery services
`10.1
`Introduction
`
`10.2
`
`Organizational configurations
`
`Specialized access
`11.1
`Introduction
`11.2
`Teletex access
`11.3
`Telex access
`
`PART 3 i Capabilities of MHS
`
`12
`
`Naming and addressing
`12.1
`Introduction
`
`12.2
`1 2.3
`12.4
`
`Directory names
`0/ R names
`O/R addresses
`
`4
`
`Faseicle VIIIJ — Rec. X.4l]l]
`
`Page 4 of 75
`
`Page 4 of 75
`
`

`

`13
`
`14
`
`15
`
`16
`
`17
`
`MHS use of directory
`Introduction
`13.1
`13.2
`13.3
`
`Functional model
`
`Physical configurations
`
`Properties of a UL
`Submission
`DL use of a directory
`
`Distribution fists in MHS
`Introduction
`14.1
`14.2
`14.3
`14.4
`14.5
`14.6
`14.7
`14.8
`14.9
`14.10
`14.11
`
`DL expansion
`Nesting
`Recursion control
`Delivery
`
`Routing loop control
`Notifications
`
`D1. handling policy
`
`MHS security threats
`
`Security capabilities of MHS
`Introduction
`15.1
`15.2
`15.3
`15.4
`15.5
`
`Security model
`MHS security features
`
`Security management
`
`Conversion in MHS
`
`Use of {he MHS in provision of public services
`
`PART 4 — Elements of service
`
`Purpose
`
`_
`
`,
`
`1 8
`
`19
`
`Classification
`19.1
`19.2
`19.3
`19.4
`19.5
`19.6
`19.7
`19.8
`19.9
`
`Purpose of classification
`Basic message transfer service
`MT service optional user facilities
`Base MH/I’D service interccmrnunication
`Optional user faciiities for MH/PD service intercommunication
`Base message store
`
`MS optional user facilities
`Basic interpersonal messaging service
`{PM service optional user facilities
`
`Annex A -— Glossary of terms
`
`Annex B — Definitions of elements of service
`
`Annex C — Elements of service modifications with respect to the 1984 version
`Annex D -— Differences betwaen CCITT Recommendation E400 and ISO Standard 10021-1
`
`Fascicle VIIIJ # Rec. XAGI}
`
`
`hFTage 5 of 75
`
`Page 5 of 75
`
`

`

`PARTI — INTRODUCTION
`
`I]
`
`Introduction
`
`Thls Recommendation Is one of a set of Recommendations for message handling. The entire set prowdes 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. other
`telematic services, postal services).
`
`This Recommendation specifies the overall system and service description of message handling capabilities.
`
`1
`
`Scope
`
`This Recommendation defines the overall system and service of an MHS and serves as a general overview
`of MHSA
`
`Other aspects of message handling systems and services are defined in other Recommendations. The layout
`of Recommendations defining the message handling system and services is shown in Table 1/X.400. The public
`services built on MHS, as well as access to and from the MHS for public services are defined in the F.400-Serics
`of Recommendations.
`
`The technical aspects of MHS are defined in the XAOO—Series of Recommendations. The overall system
`architecture of MHS is defined in Recommendation X402.
`
`6
`
`Fascicle VIIIJ' i Rec. K400
`
`I Page 6 of 75
`
`Page 6 of 75
`
`

`

`TABLE 1/X.400
`
`Structure of MHS Recommendations
`
`Name of Recommendation/Standard
`
`MHS: System and service overview
`
`_[
`
`Joint MHS
`CCI‘I'I‘
`ISO
`x400
`10021—1
`
`—|
`Al
`
`CCITI‘ only
`System
`Service
`r E400
`
`Joint support
`l—CCI'IT
`i_
`ISO
`
`
`
`
`
`
`
`
`
`
`
`
`
`Se
`
`
`
`r
`
`
`
`MHS: Overall architecture
`MHS: Conformance testing
`MI—IS: Abstract service definition
`conventions
`MHS: Encoded information type
`conversion rules
`
`MHS: MTS: Abstract service definition
`and procedures
`
`MHS: MS: Abstract service definition
`MHS: Protocol specifications
`MHS:
`Interpersonal messaging system
`Telematic access to IPMS
`
`X402
`
`10021-2
`
`X407
`
`10021-3
`
`K411
`
`10021-4
`
`X413
`X419
`X420
`
`10021—5
`10021-6
`10021-7
`
`MHS: Namingand addressingfor public
`
`MH services
`M113: The public message transfer service
`MHS:
`Intercomlnunication with pubiic
`physical delivery services
`MHS: The public 1PM service
`MHS:
`Intercomrnunication between 1PM
`service and teiex
`Intercommunication between 1PM
`service and teletex
`
`MHS:
`
`—I
`
`031:
`031:
`
`Basic reference mode]
`Specification of abstract syntax
`notation one (ASN.1)
`Specification of basic encoding
`rules for abstract syntax notation
`one (ASN.1)
`OSI: Association control: service
`definition
`
`OSI:
`
`OSI:
`
`081:
`
`OSI:
`
`081:
`
`051:
`
`Reliable transfer: mode] and service
`definition
`
`Remote operations: model, notation
`and service definition
`
`Association controi: protocol
`Specification
`Reliable transfer: protocol
`specification
`Remote operations: protocol
`specification
`
`X403
`
`X403
`
`_
`4’
`
`T330
`
`F4401 —l
`
`E410
`E415
`
`E420
`E421
`
`11.422
`
`X200
`X208
`
`X209
`
`X2]?
`
`511.218
`
`X219
`
`X227
`
`X228
`
`X229
`
`7498
`8824
`
`8825
`
`8649
`
`9066-1
`
`90'12-1
`
`3650
`
`9066-2
`
`9072-2
`
`L
`__|
`L_
`
`
`Fasclcle VIII.7 — Ree. X400
`
`7
`
`Engage 7 of 75
`
`;_
`
`3
`
`1
`
`
`
`
`
`Page 7 of 75
`
`

`

`2
`
`References
`
`This Recommendation cites the documents listed below:
`
`Recommendation F.60
`
`Operational provisions for the international telex service
`
`Recommendation F.69
`
`Plan for the telex destination codes
`
`Recommendation E72
`
`Recommendation F.160
`
`International telex store-and—forward — General principles and operational aspects
`
`General operational provisions for the international public fascimile services
`
`Recommendation F200
`
`Teletex service
`
`Recommendation E300
`
`Videotex service
`
`Recommendation F400
`
`Recommendation E401
`
`Recommendation R410
`
`Recommendation R415
`
`Recommendation E420
`
`Recommendation E421
`
`Message handling 7 System and service overview (see also ISO 1002M)
`
`Message handling services — Naming and addressing for public message handling
`services
`
`Message handling services — The public message transfer service
`.
`ti"
`.
`.
`.
`.
`.
`.
`.
`.
`Message handlmg servrces — Intercommunlcatlon With public physteal delivery servrces
`
`Message handling services —— The public interpersonal messaging service
`
`Message handling services — Intercommnnication between the IPM service and the
`telex service
`
`Recommendation E422
`
`Message handling services — Intercommunication between the IPM service and the
`teletex service
`
`Recommendation T.61
`
`Character repertoire and coded character sets for the international teletex service
`
`Recommendation T330
`
`Teiematic access to IPMS
`
`Recommendation U.80
`
`International teletex store-and-forward 7 Access from teiex
`
`Recommendation U204
`
`Recommendation X200
`
`Recommendation X208
`
`Recommendation X209
`
`Interworking between the teiex service and the public interpersonal messaging service
`
`Reference model of open systems interconnection for CCIT’I‘ applications (see also
`ISO 7498)
`
`Specification of abstract syntax notation one (ASN.1) (see also ISO 8824)
`
`Specification of basic encoding rules for abstract syntax notation one (ASN.1) (see also
`ISO 3825)
`
`Recommendation X217
`
`Association control: Service definitions (see also ISO 8649)
`
`Recommendation X.218
`
`Reliable transfer model: Service definition (see also ISO/IEC 9066-1)
`
`Recommendation X219
`
`Recommendation K400
`
`Recommendation X402
`
`Remote operations model: Notation and service definition (see also ISO/IEC 9072—1)
`
`Message handling 7 System and service overview (see also ISO/15C 1002171)
`
`Message handling systems — Overall architecture (see also ISO/IEC 10021-2)
`
`Recommendation 31.403
`
`Message handling systems — Conformance testing
`
`Recommendation X.407
`
`Recommendation X408
`
`Recommendation X411
`
`Message handling systems — Abstract service definition conventions (see also 150/
`IEC 10021-3)
`
`Message handling systems — Encoded information type convention rules
`
`Message handling systems e Message transfer system: Abstract service definition and
`procedures (see also ISO/IEC 100214)
`
`8
`
`Fascicle VIII.7 — Rec. X400
`
`Page 8 of 75
`
`Page 8 of 75
`
`

`

`
`
`Recommendation X413
`
`Recommendation K419
`
`Recommendation X420
`
`Message handling systems — Message store: Abstract service definition (see also
`ISO/[EC 1002175)
`Message handling systems — Protocol specifications [see also ISO/IEC 10021-6)
`Message handling systems — Interpersonal messaging system
`(see also ISO/IEC 10021)?)
`
`in
`
`Recommendation X500
`
`Directory — Overview (see also ISO/IEC 9594‘!)
`
`Recommendation X501
`
`Directory — Models (see also [SO/[EC 9594—2)
`
`Recommendation X509
`
`Recommendation X511
`
`Recommendation X518
`
`Recommendation X519
`
`Recommendation X520
`
`Recommendation X521
`
`Directory e Authentication (see also ISO/IEC 9594—8)
`Directory — Abstract service definition (see also ISO/[EC 9594-3)
`Directory — Procedures for distributed operations (see aiso ISO/IEC 9594-4)
`Directory — Protocol specifications (see also ISO/IEC 95945)
`Directory — Selected attribute types (see also ISO/[EC 9594—5)
`Directory 4 Selected object classes (see also ISO/IEC 9594—?)
`
`3
`
`Definitions
`
`This Recommendation uses the terms listed below, and those defined in Annex A.
`Definitions of the elements of service applicable to MHS are contained in Annex B.
`
`3.1
`
`Open systems interconnection
`
`This Recommendation uses the following terms defined in Recommendation X200:
`a) Application layer;
`1)) Application-process;
`e) Open systems interconnection;
`d)
`051 reference model.
`
`3.2
`
`Directory systems
`
`This Recommendation uses the following terms defined in Recommendation X500:
`3)
`directory entry;
`
`directory system agent;
`b)
`directory system;
`0}
`directory user agent.
`d)
`This Recommendation uses the following terms defined in Recommendation X501:
`e)
`attribute;
`f)
`group;
`g) member;
`h)
`name.
`
`4
`
`Abbreviations
`
`A
`
`ADMD
`AU
`
`CA
`
`DL
`
`DSA
`
`DUA
`
`Additional
`
`Administration management domain
`Access unit
`
`Contractual agreement
`
`Distribution list
`
`Directory system agent
`
`Directory user agent
`
`
`Page 9 of 75
`
`Fascicle VII‘L'i‘r e Rec. X400
`
`9
`
`Page 9 of 75
`
`

`

`EIT
`
`1/0
`
`11’
`
`[PM
`
`{PMS
`
`MD
`
`MH
`
`MHS
`
`MS
`
`MT
`
`MTA
`
`MTS
`
`N/A
`
`0/ R
`
`OSI
`
`PD
`
`PDAU
`
`PDS
`
`PM
`
`PR
`
`PRMD
`
`Essential
`
`Encoded information type
`
`Input/output
`
`Interpersonai
`
`Interpersonal messaging
`
`Interpersonal messaging system
`
`Management domain
`
`Message handling
`
`Message handling system
`
`Message store
`
`Message transfer
`
`Message transfer agent
`
`Message transfer system
`
`Not applicable
`
`Originator/recipient
`
`Open system interconnection
`
`Physical delivery
`
`Physical delivery access unit
`
`Physical delivery system
`
`Per—message
`
`Per-recipient
`
`Private management domain
`
`PTLX AU
`
`Public telex access unit
`
`TLMA
`
`Telematic agent
`
`TLX AU
`
`Telex access unit
`
`TTX
`
`UA
`
`Teletex
`
`User agent
`
`5
`
`Conventions
`
`“Administration” is used for shortness to indicate a telecommuni-
`In this Recommendation the expression
`on with public
`cation Administration, a recognized private operating agency, and, in the case of intercommunicati
`delivery service, a postal Administration.
`
`Note — This Recommendation is identical t
`with ISO, the conventions of ISO standards have been adopt
`differ from the CCITT style. The other Recommendations 0
`conventions.
`
`0 Recommendation E400. Because of the desired alignment
`ed for the structure of this text. These conventions
`f the X.400-Series are in accordance with CCIT’I‘
`
`10
`
`Fascicle VIII.7 — Rec. X400
`
`Page 10 of 75
`
`Page 10 of 75
`
`

`

`PART 2 — GENERAL DESCRIPTION OF MHS
`
`6
`
`Purpose
`
`.1»
`
`This Recommendation is one of a set of Recommendations and describes the system model and elements
`of service of the message handling system (MHS) and services. This Recommendation overviews the capabilities of
`an MHS that are used by Administrations for the provision of public 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 (OSI reference model) for CCITT applications (Recommendation X.2(]l)) and uses the
`presentation layer services and services offered by other, more general, application service elements. An MHS can
`be constructed using any network fitting in the scope of 081. The message transfer service provided by the MTS is
`application independent. An example of a standardized application is the [PM service. End systems can use the
`MT service for specific applications that are defined bilaterally.
`
`Message handling services provided by Administrations belong to the group of telematic services defined
`in FrSeries Recommendations.
`
`telematic services and telex (Recommendations F.60, Riot], F205], F300, etc}, data
`Various other
`transmission services (XI), or physical delivery services (R415) gain access to, and intercommunicate with,
`the
`IPM service or intercommunicate with each other, via access units.
`""
`
`Elements of service are the service features provided through the application processes. The elements of
`service are considered to be components of the services provided to users and are either elements of a basic
`service or they are optional user facilities, classified either as essential optional user facilities, or as additional
`optional user facilities.
`
`'7
`
`Functional model oi MHS
`
`The MHS functional model serves as a tool to aid in the development of Recommendations for MHS, and
`aids in describing the basic concepts that can be depicted graphically. It comprises several different functional
`components that work together to provide MH services. The model can be applied to a number of different
`physical and organizational configurations.
`
`7.1
`
`Description of the MHS model
`
`A functional view of the MHS model is shown in Figure t/XAOO. In this model, a user is either a person
`or a computer process. Users are either direct users (ie. engage in message handling by direct use of MHS), or are
`indirect users (i.e. engage in message handling through another communication system (eg. 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.
`
`An originator prepares messages with the assistance of his user agent. A user agent (UA) 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 M85, and can return notifications to the originator. Functions performed solely by the UA and not
`standardized as part of the message handling elements of service are called local functions. A UA can accept
`delivery of messages directly from the MTS, or it can use the capabilities of an MS to receive delivered messages
`for subsequent retrieval by the UA.
`
`The MTS comprises a number of message transfer agents (MTAs). Operating together,
`forward manner, the MTAs transfer messages and deliver them to the intended recipients.
`
`in a store-and—
`
`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).
`
`The message store (MS) is an optional general purpose capability of MHS that acts as an intermediary
`between the UA and the MTA. The MS is depicted in the MHS functional model shown in Figure I/XAOU. The
`MS is a functional entity whose primary 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).
`
`Faseicle VIIIJ‘ — Rec. X400
`
`11
`
`QI-_.____
`
`Page 11 of 75
`
`
`
`Page 11 of 75
`
`

`

`
`
`
`
`Note — Message input from PD Services to MHS is for further study. Flow from PD Services to the PDAU shown is for notifications.
`
`FIGURE 111L400
`
`MHS {unctienal model
`
`7.2
`
`Structure of messages
`
`The basic structure of messages conveyed by the MTS is shown in Figure 2/X.400. A message is made up
`of an envelope and a content. The envelope carries information that is used by the MTS when tranSforring 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 § 16).
`
`+
`
`Content
`
`Envelope
`
`CCI'IT — 0‘00580788
`
`FIGURE QIXADU
`
`Basic message structure
`
`[2
`
`Fasciclc VIIUr — Rec. X400
`
`Page 12 of 75
`
`Page 12 of 75
`
`

`

`7.3
`
`Application of the MHS model
`
`1.3.1
`
`Physical mapping
`
`Users access UAs for message processing purposes, for example, to create, present, or file messages. A user
`can interact with 3 HA via an input/output device or process (e.g. keyboard, display, printer, etc.). A UA can be
`implemented as a {set of) computer process(es) in an intelligent terminal.
`A UA and MTA can be co-located in the same system, or a UA/MS can be implemented in physically
`separate systems. In the first case the UA accesses the MT elements of service by interacting directiy 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/XAOO and 4/X.40t}. The different physicai
`systems can be connected by means of dedicated lines or switched network connections.
`
`
`
`
`UO device
`
`
`GCI'ET — 0100590
`
`Processing system
`
`FIGURE BJXAOD
`
`Covresident HA and MTA
`
`U0 device
`
`I
`
`terminal
`"l ntelligent"
`
`L
`
`-
`
`w
`
`l
`
`l
`
`__.J CCIT'TrO‘lOOBOO-SB
`.-
`_
`Processing system
`
`FIGURE 4IX.4DO
`
`Stand—alone UA and ctr-resident MSIMTA and USJMTA
`
`7.3.2
`
`Organizational mapping
`
`An Administration or organization can play various roles in providing message handling services. An
`organization in this context can be a company or a non—commercial enterprise.
`-
`The collection of at least one MTA, zero or more UAs, zero or more M55, and zero or more AUs
`operated by an Administration or organization constitutes a management domain (MD). An MD managed by an
`Administration is called an Administration management domain (ADMD). An MD managed by an organization
`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 §l9. The
`relationships between management domains is shown in Figure 5/X400.
`
`Faseiclc VIIIJ -— Rec. X400
`
`13
`
`M P
`
`age 13 of 75
`
`Page 13 of 75
`
`

`

`
`
`
`
`
`
`MTA
`
`MFA
`
`CCITT — 0100321 -sa
`
` |
`
`| ]
`
`1 i
`
`Countryr 8
`
`FIGURE SHEA-DI]
`
`Relationships between management domains
`
`Note I a It should be recognized that the provision of support of private messaging systems by CCITT
`members falls within the framework of national regulations. Thus the possibilities mentioned in this paragraph
`may or may not be offered by an Administration which provides message handling services. In addition, the UAs
`depicted in Figure S/XAUO do not imply that UAs belonging to an MD must be exclusively located in the same
`country as their MDS.
`interactions between PRMDs and internal interactions within an MD are outside the
`Note 2 7 Direct
`scope of this Recommendation
`
`Note 3 — An Administration, in the context of CCITT, that manages an ADMD, is understood as being
`a member of ITU or a recognized private operating agency (RPOA), registered by a country with the ITU.
`
`7.3.3
`
`Administration management domain
`
`In one country one or more ADMDs can exist. An ADMD is characterized by its provision of relaying
`functions betWeen other management domains and the provision of messageitransfer service for the applications
`provided within the ADMD.
`
`An Administration can provide access for its users to the ADMD in one or more of the following ways:
`— users to Administration provided UA
`— private UA to Administration MTA
`7 private UA to Administration MS
`— private UA to Administration MTA
`— user to Administration provided UA.
`
`See also the examples of configurations shown in Figure 3/X.400 and Figure 4/X.400.
`
`14
`
`Fascicle VIIIJ' — Rec. X400
`
`Page 14 of 75
`
`Page 14 of 75
`
`

`

`Administration provided UAs can exist as part of an intelligent terminal that the user can use to access
`MHS. They can also exist as part of Administration resident equipment being part of MHS, in which case the user
`obtains access to the LEA 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 UJA can be
`associated with one or more MDs, provided that the required naming conventions are preserved.
`
`A private MTA as part of an PRMD can access one or more ADMDs in a country, following national
`regulations.
`
`Access can also be provided by Administration provided AUs described in §§ 10 and ll.
`
`7.3.4
`
`Private management domain
`
`An organization other than an Administration can have one or more MTA(s), and zero or more UAs, AUs
`and MSs forming a PRMD which can interact with an ADMD on an MD to MD (MTA to MTA) basis. A
`PRMD is characterized by the provision of messaging functions within that management domain.
`
`the PRMD can have
`A PRMD is considered to exist entirely within one country. Within that country,
`access to one or more ADMDs as shown in Figure S/XAOD. However,
`in the ease 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 ADM D. A PRMD will not act as a relay between two ADMDs.
`
`In the interaction between a PRMD and an ADMD, the ADMD takes responsibility for the actions of the
`PRMD which are related to the interaction. In addition to ensuring that the PRMD properly provides the message
`transfer service, the ADMD is responsible for ensuring that the accounting, logging, quality of service, uniqueness
`of names, and related operations of the PRMD are correctly performed. As a national matter,
`the name of a
`PRMD can be either nationally unique or relative to the associated ADMD. If a PRMD is associated with more
`than one ADMD, the PRMD can have more than one name.
`
`7.4
`
`Message store
`
`Because UAs can be implemented on a wide variety of equipment, including personal computers, the MS
`can 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/X.400 shows the delivery, and subsequent retrieval of messages that
`are delivered to an MS, and the indirect submission of messages via the MS.
`
`Retrieval
`
`Delivery
`
`l—I-—submlssmn
`
`submiSSion
`
`com 7 01006l0-EB
`
`FIGURE 6/1400
`
`Submission and delivery with an MS
`
`One MS acts on behaif 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 PRMD} of Figure 5/X.400).
`When subscribing to an MS, all messages destined for the UA are delivered to the MS only. The UA, if on
`line, can receive alerts when certain messages are delivered to the MS. Messages delivered to an MS are
`considered delivered from the MTS perspective.
`
`When 21 HA 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 can expand the message if the
`UA requests the forwarding of messages that exist in the MS.
`
`Fascicle V1113? — Ree. X400
`
`15
`
`
`infiage 15 of 75
`
`Page 15 of 75
`
`

`

`.
`;
`
`Users are also provided with the capability to request the MS to forward selected messages automatically
`upon delivery.
`The elements of service describing the features of the MS are defined in Annex B and classified in § 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.
`is
`
`7.4.1
`
`Physical configurations
`
`to the MTA in a number of ways. The MS can be
`The MS can be physically located with respect
`co-located with the UA, co—located with the MTA, or stand-alone. From an external point of view, a co—located
`UA and MS are indistinguishable from a stand-alone UA. (Io—locating the MS with the MTA offers significant
`advantages which wiil probably make it the predominant configuration.
`
`7.4.2
`
`Organizational configurations
`
`Either ADMDs or PRMDs can operate MSs. In the case of Administration supplied MSs, the subscriber
`either provides his own UA or makes use of an Administration supplied UA via an I/O device. In either case, 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 cases
`can exist.
`i"
`
`8
`
`Message transfer service
`
`The MTS provides 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 § 19.
`Provision of public message transfer service by Administrations is described in Recommendation E410.
`
`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 M85:
`
`1) The submission interaction is the means by which an originating UA or MS transfers to an MTA the
`content of a message and the submission envelope. The submission envelope contains the information
`that the MTS requires to provide the requested elements of service.
`2) The delivery interaction is the means bywhich 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
`
`Tranyer
`
`the message
`Starting at the originator’s MTA, each MTA transfers the message to another MTA until
`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 the 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 containing any type of binary coded information. MTAs neither interpret not
`alter the content of messages except when performing a. conversion.
`
`3.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 returned to the originator in
`a report signifying this. In addition, an originator can specificaliy ask for acknowledgement of successful delivery
`through use of the delivery notification element of service on submission.
`
`16
`
`Fascicle VIIIJ —— Rec. X400
`
`HI Page 16 of 75
`
`Page 16 of 75
`
`

`

`,
`
`
`
`3.4
`
`User agent
`
`The UA uses the MT service provided by the MTS. A UA is a functional entity by means of which a
`gingie direct user engages in message handiing.
`UAs are grouped into classes based on the type of content of messages they can handle.__1The 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 can 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 can submit messages through it, and retrieve messages that have been delivered to
`the MS.
`
`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 § 9, is one example of this. Other services can be built on
`the foundation of the MTS, either with corresponding recommendations or as private applications.
`
`9
`
`IPM service
`
`The interpersonal message 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 defined in Annex B
`and classified in § 19. The provision of public interpersonal messaging service by Administrations is described in
`Recommendation R420.
`
`9.1
`
`IPM service functional model
`
`Figure 7/X.t$00 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 u