home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-12-22 | 110.8 KB | 4,976 lines |
- .rs
- .\" Troff code generated by TPS Convert from ITU Original Files
- .\" Not Copyright (~c) 1991
- .\"
- .\" Assumes tbl, eqn, MS macros, and lots of luck.
- .TA 1c 2c 3c 4c 5c 6c 7c 8c
- .ds CH
- .ds CF
- .EQ
- delim @@
- .EN
- .nr LL 40.5P
- .nr ll 40.5P
- .nr HM 3P
- .nr FM 6P
- .nr PO 4P
- .nr PD 9p
- .po 4P
-
- .rs
- \v'|.5i'
- .LP
- \fBMONTAGE: FIN DE LA SECTION 2 EN\(hyT\*\|ETE DE CETTE PAGE\fR
- .LP
- \v'20P'
- SECTION\ 3\ \(em\ CONFIGURATIONS
- .sp 1P
- .RT
- .sp 2P
- .LP
- \fB11\fR \fBOverview\fR
- .EF '% Fascicle\ VIII.7\ \(em\ Rec.\ X.402''
- .OF '''Fascicle\ VIII.7\ \(em\ Rec.\ X.402 %'
- .sp 1P
- .RT
- .PP
- This section specifies how one can configure the MHS to satisfy any of
- a variety of functional, physical, and organizational requirements.
- .PP
- This section covers the following topics:
- .RT
- .LP
- a)
- functional configurations;
- .LP
- b)
- physical configurations;
- .LP
- c)
- organizational configurations;
- .LP
- d)
- the \fIGlobal MHS\fR .
- .sp 2P
- .LP
- \fB12\fR \fBFunctional configurations\fR
- .sp 1P
- .RT
- .PP
- This clause specifies the possible functional configurations of the MHS.
- The variety of such configurations results from the presence or absence
- of the Directory, and from whether a direct user employs an MS.
- .RT
- .sp 1P
- .LP
- 12.1
- \fIRegarding the Directory\fR
- .sp 9p
- .RT
- .PP
- With respect to the Directory, the MHS can be configured for a
- particular user, or a collection of users (e.g.,\ see \(sc\ 14.1), in either
- of two ways: with or without the Directory. A user without access to the
- Directory may lack the capabilities described in Section\ 5.
- .PP
- \fINote\fR \ \(em\ A partially, rather than fully, interconnected directory
- may exist for an interim period during which the (global) Directory made
- possible by Recommendations for Directories is under construction.
- .RT
- .sp 1P
- .LP
- 12.2
- \fIRegarding the message store\fR
- .sp 9p
- .RT
- .PP
- With respect to the MS, the MHS can be configured for a particular direct
- user in either of two ways: with or without an MS. A user without access
- to an MS lacks the capabilities of message storage. A user in such
- circumstances depends upon his UA for the storage of information objects, a
- capability that is a local matter.
- .PP
- The two functional configurations identified above are depicted in
- Figure\ 7/X.402 which also illustrates one possible configuration of the MTS,
- and its linkage to another communication system via an AU. In the figure,
- user\ 2 is equipped with an MS while user\ 1 is not.
- .bp
- .RT
- .LP
- .rs
- .sp 22P
- .ad r
- \fBFigure 7/X.402, p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 2P
- .LP
- \fB13\fR \fBPhysical configurations\fR
- .sp 1P
- .RT
- .PP
- This clause specifies the possible physical configurations of the MHS,
- i.e.,\ how the MHS can be realized as a set of interconnected computer
- systems. Because the number of configurations is unbounded, the clause
- describes the kinds of messaging systems from which the MHS is assembled,
- and identifies a few important representative configurations.
- .RT
- .sp 1P
- .LP
- 13.1
- \fIMessaging systems\fR
- .sp 9p
- .RT
- .PP
- The building blocks used in the physical construction of the MHS
- are called \fImessaging systems\fR . A \fBmessaging system\fR is a computer
- system
- (possibly but not necessarily an open system) that contains, or realizes,
- one or more functional objects.
- .PP
- Messaging systems are of the types depicted in Figure 8/X.402.
- .RT
- .PP
- The types of messaging system, depicted in Figure 8/X.402, are
- listed in the first column of Table\ 8/X.402. For each type listed, the
- second column indicates the kinds of functional object \(em\ UAs, MSs,
- MTAs, and AUs\ \(em
- that
- may be present in such a messaging system, whether their presence is mandatory
- or optional, and whether just one or possibly several of them may be present
- in the messaging system. The table is divided into two sections. Messaging
- systems of the types in the first section are dedicated to single users,
- those of the types in the second can (but need not) serve multiple users.
- .PP
- Table 8/X.402 is divided into two sections. Messaging systems of the types
- in the first section are dedicated to single users, those of the types
- in the second can (but need not) serve multiple users.
- .RT
- .PP
- \fINote\fR \ \(em\ The following major principles governed the admission
- of messaging system types:
- .LP
- a)
- An AU and the MTA with which it interacts are typically
- co\(hylocated because no protocol to govern their interaction is standardized.
- .LP
- b)
- An MTA is typically co\(hylocated with multiple UAs or MSs
- because, of the standardized protocols, only that for transfer simultaneously
- conveys a message to multiple recipients. The serial delivery of a message
- to multiple recipients served by a messaging system, which the delivery
- protocol would require, would be inefficient.
- .bp
- .LP
- c)
- No purpose is served by co\(hylocating several MTAs in a
- messaging system because a single MTA serves multiple users, and the purpose
- of an MTA is to convey objects between, not within such systems. (This
- is not
- intended to exclude the possibility of several MTA\(hyrelated processes
- co\(hyexisting within a single computer system.)
- .LP
- d)
- The co\(hylocation of an AU with an MTA does not affect that
- system's behaviour with respect to the rest of the MHS. A single messaging
- system type, therefore, encompasses the AU's presence and absence.
- .PP
- The messaging system types, summarized in Table 8/X.402, are
- individually defined and described below.
- .LP
- .rs
- .sp 21P
- .ad r
- \fBFigure 8/X.402, p.2\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .ce
- \fBH.T. [T8.402]\fR
- .ce
- TABLE\ 8/X.402
- .ce
- \fBMessaging systems\fR
- .ps 9
- .vs 11
- .nr VS 11
- .nr PS 9
- .TS
- center box;
- cw(72p) | cw(24p) sw(24p) sw(24p) sw(24p) , ^ | c | c | c | c.
- Messaging system Functional objects
- UA MS MTA AU
- _
- .T&
- lw(72p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
- A/SYS 1 \(em \(em \(em
- .T&
- lw(72p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
- S/SYS \(em 1 \(em \(em
- .T&
- lw(72p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
- AS/SYS 1 1 \(em \(em
- _
- .T&
- lw(72p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
- T/SYS \(em \(em 1 [M]
- .T&
- lw(72p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
- AT/SYS M \(em 1 [M]
- .T&
- lw(72p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
- ST/SYS \(em M 1 [M]
- .T&
- lw(72p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
- AST/SYS M M 1 [M]
- _
- .T&
- lw(72p) | lw(24p) | cw(24p) | cw(24p) | cw(24p) .
- M Multiple .parag [.\|.\|.] Optional .parag
- .TE
- .nr PS 9
- .RT
- .ad r
- \fBTableau 8/X.402 [T8.402], p.3\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .sp 1P
- .LP
- 13.1.1
- \fIAccess systems\fR
- .sp 9p
- .RT
- .PP
- An \fBaccess system (A/SYS)\fR contains
- one UA and neither an MS, an
- MTA, nor an AU.
- .PP
- An A/SYS is dedicated to a single user.
- .RT
- .sp 1P
- .LP
- 13.1.2
- \fIStorage systems\fR
- .sp 9p
- .RT
- .PP
- A \fBstorage system (S/SYS)\fR contains one MS and neither a UA, an MTA,
- nor an AU.
- .PP
- An S/SYS is dedicated to a single user.
- .RT
- .sp 1P
- .LP
- 13.1.3
- \fIAccess and storage systems\fR
- .sp 9p
- .RT
- .PP
- An \fBaccess and storage system (AS/SYS)\fR contains one UA, one MS, and
- neither an MTA nor an AU.
- .PP
- An AS/SYS is dedicated to a single user.
- .RT
- .sp 1P
- .LP
- 13.1.4
- \fITransfer systems\fR
- .sp 9p
- .RT
- .PP
- A \fBtransfer system (T/SYS)\fR contains one MTA; optionally, one or more
- AUs; and neither a UA nor an\ MS.
- .PP
- A T/SYS can serve multiple users.
- .RT
- .sp 1P
- .LP
- 13.1.5
- \fIAccess and transfer systems\fR
- .sp 9p
- .RT
- .PP
- An \fBaccess and transfer system (AT/SYS)\fR contains one or more
- UAs; one MTA; optionally, one or more AUs; and no MS.
- .PP
- An AT/SYS can serve multiple users.
- .RT
- .sp 1P
- .LP
- 13.1.6
- \fIStorage and transfer systems\fR
- .sp 9p
- .RT
- .PP
- A \fBstorage and transfer system (STB/FSYS)\fR contains one or more MSs;
- one MTA; optionally, one or more AUs; and no UA.
- .PP
- An ST/SYS can serve multiple users.
- .RT
- .sp 1P
- .LP
- 13.1.7
- \fIAccess, storage, and transfer systems\fR
- .sp 9p
- .RT
- .PP
- An \fBaccess, storage, and transfer system (AST/SYS)\fR contains
- one or more UAs; one or more MSs; one MTA; and optionally, one or more AUs.
- .PP
- An AST/SYS can serve multiple users.
- .RT
- .sp 1P
- .LP
- 13.2
- \fIRepresentative configurations\fR
- .sp 9p
- .RT
- .PP
- Messaging systems can be combined in various ways to form the MHS. The
- possible physical configurations are unbounded in number and thus cannot
- be enumerated. Several important representative configurations, however,
- are
- described below and in Figure\ 9/X.402.
- .RT
- .sp 1P
- .LP
- 13.2.1
- \fIFully centralized\fR
- .sp 9p
- .RT
- .PP
- The MHS may be fully centralized [panel a) of Figure 9/X.402]. This design
- is realized by a single AST/SYS which contains functional objects of all
- kinds and which can serve multiple users.
- .RT
- .sp 1P
- .LP
- 13.2.2
- \fICentralized message transfer and storage\fR
- .sp 9p
- .RT
- .PP
- The MHS may provide both message transfer and message storage
- centrally but user access distributedly [panel\ b) of Figure\ 9/X.402]. This
- design is realized by a single ST/SYS and, for each user, an A/SYS.
- .RT
- .sp 1P
- .LP
- 13.2.3
- \fICentralized message transfer\fR
- .sp 9p
- .RT
- .PP
- The MHS may provide message transfer centrally but message storage and
- user access distributedly [panel\ c) of Figure\ 9/X.402]. This design is
- realized by a single T/SYS and, for each user, either an AS/SYS alone or an
- S/SYS and an associated A/SYS.
- .bp
- .RT
- .LP
- .rs
- .sp 29P
- .ad r
- \fBFigure 9/X.402, p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 1P
- .LP
- 13.2.4
- \fIFully distributed\fR
- .sp 9p
- .RT
- .PP
- The MHS may provide even message transfer distributedly [panel d) of Figure\
- 9/X.402]. This design involves multiple ST\(hySYSs or T\(hySYSs.
- .RT
- .sp 2P
- .LP
- \fB14\fR \fBOrganizational configurations\fR
- .sp 1P
- .RT
- .PP
- This clause specifies the possible organizational configurations of the
- MHS, i.e.,\ how the MHS can be realized as interconnected but independently
- managed sets of messaging systems (which are themselves interconnected).
- Because the number of configurations is unbounded, the clause describes the
- kinds of \fImanagement domains\fR from which the MHS is assembled, and
- identifies a few important representative configurations.
- .RT
- .sp 1P
- .LP
- 14.1
- \fIManagement domains\fR
- .sp 9p
- .RT
- .PP
- The primary building blocks used in the organizational construction of
- the MHS are called \fImanagement domains\fR . A \fBmanagement domain\fR
- (MD) (or
- \fBdomain\fR ) is a set of messaging systems \(em\ at least one of which
- contains, or
- realizes, an MTA\ \(em that is managed by a single organization.
- .PP
- The above does not preclude an organization from managing a set of
- messaging systems (e.g.,\ a single A/SYS) that does not qualify as an MD for
- lack of an MTA. Such a collection of messaging systems, a secondary building
- block used in the MHS' construction, \*Qattaches\*U to an MD.
- .PP
- MDs are of several types which are individually defined and described below.
- .bp
- .RT
- .sp 1P
- .LP
- 14.1.1
- \fIAdministration management domains\fR
- .sp 9p
- .RT
- .PP
- An \fBadministration management domain (ADMD)\fR comprises messaging systems
- managed by an Administration. The major technical distinction between an
- ADMD and a \fIPRMD\fR is that the former is positioned above the latter
- in the MHS' hierarchical addressing (see \(sc\ 18) and routing (see \(sc\
- 19) regimes.
- .PP
- \fINote\fR \ \(em\ An ADMD provides Message Handling to the public.
- .RT
- .sp 1P
- .LP
- 14.1.2
- \fIPrivate management domains\fR
- .sp 9p
- .RT
- .PP
- A \fBprivate management domain (PRMD)\fR comprises messaging systems managed
- by an organization other than an Administration. The major technical
- distinction between a PRMD and an ADMD is that the former is positioned
- below the latter in the MHS' hierarchical addressing (see \(sc\ 18) and
- routing (see
- \(sc\ 19) regimes.
- .PP
- \fINote\fR \ \(em\ A PRMD provides message handling, e.g., to the employees
- of a company, or to those employees at a particular company site.
- .RT
- .sp 1P
- .LP
- 14.2
- \fIRepresentative configurations\fR
- .sp 9p
- .RT
- .PP
- MDs can be combined in various ways to form the MHS. The possible organizational
- configurations are unbounded in number and thus cannot be
- enumerated. Several important representative configurations, however, are
- described below and in Figure\ 10/X.402.
- .RT
- .LP
- .rs
- .sp 18P
- .ad r
- \fBFigure 10/X.402, p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 1P
- .LP
- 14.2.1
- \fIFully centralized\fR
- .sp 9p
- .RT
- .PP
- The entire MHS may be managed by one organization [panel a) of
- Figure\ 10/X.402]. This design is realized by a single MD.
- .RT
- .sp 1P
- .LP
- 14.2.2
- \fIDirectly connected\fR
- .sp 9p
- .RT
- .PP
- The MHS may be managed by several organizations, the messaging
- systems of each connected to the messaging systems of all of the others
- [panel\ b) of Figure\ 10/X.402]. This design is realized by multiple MDs
- interconnected pair\(hywise.
- .RT
- .sp 1P
- .LP
- 14.2.3
- \fIIndirectly connected\fR
- .sp 9p
- .RT
- .PP
- The MHS may be managed by several organizations, the messaging
- systems of one serving as intermediary between the messaging systems of the
- others [panel\ c) of Figure\ 10/X.402]. This design is realized by multiple
- MDs one of which is interconnected to all of the others.
- .bp
- .RT
- .sp 2P
- .LP
- \fB15\fR \fBThe \fR \fBGlobal MHS\fR
- .sp 1P
- .RT
- .PP
- A major purpose of this Recommendation and others in the set is to enable
- the construction of the Global MHS, an MHS providing both intra\(hy and
- inter\(hyorganizational, and both intra\(hy and international message handling
- world\(hywide.
- .PP
- The Global MHS almost certainly encompasses the full variety of
- functional configurations specified in\ \(sc\ 12.
- .PP
- The physical configuration of the Global MHS is a hybrid of the pure configurations
- specified in \(sc\ 13, extremely complex and highly distributed
- physically.
- .PP
- The organizational configuration of the Global MHS is a hybrid of the pure
- configurations specified in\ \(sc\ 14, extremely complex and highly distributed
- organizationally.
- .PP
- Figure 11/X.402 gives an example of possible interconnections. It does
- not attempt to identify all possible configurations. As depicted, ADMDs
- play a central role in the Global MHS. By interconnecting to one another
- internationally, they provide an international message transfer backbone.
- Depending upon national regulations, by interconnecting to one another
- domestically, they may also provide domestic backbones joined to the
- international backbone. ADMDs also serve as primary naming authorities
- in the assignment of \fIO/R addresses\fR to users and\ DLs.
- .PP
- PRMDs play a peripheral role in the Global MHS, being connected to the
- ADMD backbone which serves as an intermediary between them.
- .RT
- .LP
- .rs
- .sp 14P
- .ad r
- \fBFigure 11/X.402, p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- SECTION\ 4\ \(em\ NAMING, ADDRESSING, AND\ ROUTING
- .sp 1P
- .RT
- .sp 2P
- .LP
- \fB16\fR \fBOverview\fR
- .sp 1P
- .RT
- .PP
- This section describes the naming and addressing of users and DLs and the
- routing of information objects to them.
- .PP
- This section covers the following topics:
- .RT
- .LP
- a)
- Naming;
- .LP
- b)
- Addressing;
- .LP
- c)
- Routing
- .sp 2P
- .LP
- \fB17\fR \fBNaming\fR
- .sp 1P
- .RT
- .PP
- This paragraph specifies how users and DLs are named for the
- purposes
- of message handling in general and message transfer in particular. It defines
- \fIO/R names\fR and describes the role that Directory names play in them.
- .PP
- When it directly submits a message or probe, a UA or MS identifies its
- potential recipients to the MTS. When the MTS delivers a message, it identifies
- the originator to each recipient's UA or MS. \fIO/R names\fR are the data
- structures by means of which such identification is achieved.
- .bp
- .RT
- .sp 1P
- .LP
- 17.1
- \fIDirectory names\fR
- .sp 9p
- .RT
- .PP
- A Directory name is one component of an \fIO/R name\fR . A Directory
- name identifies an object to the Directory. By presenting such a name to the
- Directory, the MHS can access a user's or DL's Directory entry. From that
- entry the MTS can obtain, e.g.,\ the user's or DL's \fIO/R address\fR .
- .PP
- Not every user or DL is registered in the Directory and, therefore,
- not every user or DL possesses a Directory name.
- .PP
- \fINote\ 1\fR \ \(em\ Many users and DLs will lack Directory names until the
- Directory is widely available as an adjunct to the MHS. Many indirect users
- (e.g.,\ postal patrons) will lack such names until the Directory is widely
- available as an adjunct to other communication systems.
- .PP
- \fINote\ 2\fR \ \(em\ Users and DLs may be assigned Directory names even
- before a fully interconnected, distributed Directory has been put in place
- by
- pre\(hyestablishing the naming authorities upon which the Directory will
- eventually depend.
- .PP
- \fINote\ 3\fR \ \(em\ The typical Directory name is more user\(hyfriendly
- and more stable than the typical \fIO/R address\fR because the latter is
- necessarily couched in terms of the organizational or physical structure
- of the MHS while the
- former need not be. Therefore, it is intended that over time, Directory
- names become the primary means by which users and DLs are identified outside
- the MTS (i.e.\ by other users), and that the use of \fIO/R address\fR be
- largely confined to the MTS (i.e.,\ to use by MTAs).
- .RT
- .sp 1P
- .LP
- 17.2
- \fIO/R names\fR
- .sp 9p
- .RT
- .PP
- Every user or DL has one or more \fIO/R names\fR . An \fBO/R name\fR is
- an identifier by means of which a user can be designated as the originator,
- or a user or DL designated as a potential recipient of a message or probe.
- An O/R
- name distinguishes one user or DL from another and may also identify its
- point of access to the MHS.
- .PP
- An O/R name comprises a Directory name, an \fIO/R address\fR , or both.
- If present, the Directory name (if valid) unambiguously identifies the
- user or DL (but is not necessarily the only name that would do so). If
- present, the
- \fIO/R address\fR does the same and more (again see \(sc\ 18.5).
- .PP
- At direct submission, the UA or MS of the originator of a message or probe
- may include either or both components in each OB/FR name it supplies. If
- the \fIO/R address\fR is omitted, the MTS obtains it from the Directory
- using the Directory name. If the Directory name is omitted, the MTS does
- without it. If both are included, the MTS relies firstly upon the \fIO/R
- address\fR . Should it
- determine that the \fIO/R address\fR is invalid (e.g.,\ obsolete), it proceeds
- as if the \fIO/R address\fR had been omitted, relying upon the Directory
- name.
- .PP
- At delivery the MTS includes an \fIO/R address\fR and possibly a Directory
- name in each O/R name it supplies to a message's recipient or to the originator
- of a report's subject message or probe. The Directory name is included
- if the originator supplied it or if it was specified as the the member
- of an expanded DL.
- .PP
- \fINote\fR \ \(em\ Redirection or DL expansion may cause the MTS to convey
- to a UA or MS at delivery, O/R names the UA or MS did not supply at direct
- submission.
- .RT
- .sp 2P
- .LP
- \fB18\fR \fBAddressing\fR
- .sp 1P
- .RT
- .PP
- This paragraph specifies how users and DLs are addressed. It
- defines \fIO/R addresses\fR , describes the structure of the \fIattribute
- lists\fR from which they are constructed, discusses the character sets
- from which individual \fIattributes\fR are composed, gives rules for determining
- that two \fIattribute
- lists\fR are equivalent and for the inclusion of conditional \fIattributes\fR
- in such lists, and defines the \fIstandard attributes\fR that may appear
- in them.
- .PP
- To convey a message, probe, or report to a user, or to expand a DL
- specified as a potential recipient of a message or probe, the MTS must
- locate the user or DL relative to its own physical and organizational structures.
- \fIO/R addresses\fR are the data structures by means of which all such
- location is
- accomplished.
- .bp
- .RT
- .sp 1P
- .LP
- 18.1
- \fIAttribute lists\fR
- .sp 9p
- .RT
- .PP
- The \fIO/R addresses\fR of both users and DLs are attribute lists. An \fBattribute
- list\fR is an ordered set of \fIattributes\fR .
- .PP
- An \fBattribute\fR is an information item that describes a user or DL and
- that may also locate it in relation to the physical or organizational
- structure of the MHS (or the network underlying it).
- .PP
- An attribute has the following parts:
- .RT
- .LP
- a)
- \fBattribute type\fR (\fBor type\fR ): An identifier that denotes a class
- of information (e.g.,\ personal names).
- .LP
- b)
- \fBattribute value\fR (\fBor value\fR ): An instance of the class of
- information the attribute type denotes (e.g.,\ a particular personal
- name).
- .PP
- Attributes are of the following two kinds:
- .LP
- a)
- \fBstandard attribute\fR : An attribute
- whose type is bound to a class of
- information by this Recommendation.
- .LP
- The value of every standard attribute except terminal\(hytype is either
- a string or a collection of strings.
- .LP
- b)
- \fBdomain\(hydefined attribute\fR : An attribute whose type is
- bound to a class of information by an MD.
- .LP
- Both the type and value of every domain\(hydefined attribute
- are strings or collections of strings.
- .PP
- \fINote\fR \ \(em\ The widespread use of standard attributes produces more
- uniform and thus more user\(hyfriendly OB/FR addresses. However, it is
- anticipated that not all MDs will be able to employ such attributes immediately.
- The
- purpose of domain\(hydefined attributes is to permit an MD to retain its
- existing, native addressing conventions for a time. It is intended, however,
- that all MDs migrate toward the use of standard attributes, and that domain\(hydefined
- attributes be used only for an interim period.
- .sp 1P
- .LP
- 18.2
- \fICharacter sets\fR
- .sp 9p
- .RT
- .PP
- Standard attribute values and domain\(hydefined
- attribute types and values are
- constructed from numeric, printable, and teletex
- strings as follows:
- .RT
- .LP
- a)
- The type or value of a particular domain\(hydefined attribute may be
- a printable string, a teletex string, or both. The same choice shall be
- made for both the type and value.
- .LP
- b)
- The kinds of strings from which standard attribute values
- may be constructed and the manner of construction (e.g.,\ as one string or
- several) vary from one attribute to another (see \(sc\ 18.3).
- .PP
- The value of an attribute comprises strings of one of the
- following sets of varieties depending upon its type: numeric only, printable
- only, numeric and printable, and printable and teletex. With respect to
- this, the following rules govern each instance of communication:
- .LP
- a)
- Wherever both numeric and printable strings are permitted, strings of
- either variety (but not both) may be supplied equivalently.
- .LP
- b)
- Wherever both printable and teletex strings are permitted, strings of
- either or both varieties may be supplied, but printable strings
- shall be supplied as a minimum whenever attributes are conveyed
- internationally. If both printable and teletex strings are supplied, the two
- should convey the same information so that eiher of them can be safely
- ignored upon receipt.
- .PP
- The length of each string and of each sequence of strings in an
- attribute shall be limited as indicated in the more detailed (i.e.,\ ASN.1)
- specification of attributes in Recommendation X.411.
- .PP
- \fINote\ 1\fR \ \(em\ Teletex strings are permitted in attribute values
- to allow inclusion, e.g.,\ of the accented characters commonly used in
- many countries.
- .PP
- \fINote\ 2\fR \ \(em\ Not all inputB/Foutput devices permit the entry and
- display, e.g.,\ of accented characters. printable strings are required
- internationally to ensure that such device limitations do not prevent communication.
- .bp
- .RT
- .sp 1P
- .LP
- 18.3
- \fIStandard attributes\fR
- .sp 9p
- .RT
- .PP
- The standard attribute types are listed in the first column of
- Table\ 9/X.402. For each listed type, the second column indicates the character
- sets \(em numeric, printable, and teletex \(em from which attribute values
- may be
- drawn.
- .PP
- Table 9/X.402 has three sections. Attribute types in the first are of a
- general nature, those in the second have to do with \fIrouting to\fR a
- PDS, and those in the third have to do with \fIaddressing within\fR a PDS.
- .RT
- .ce
- \fBH.T. [T9.402]\fR
- .ce
- TABLE\ 9/X.402
- .ce
- \fBStandard attributes\fR
- .ps 9
- .vs 11
- .nr VS 11
- .nr PS 9
- .TS
- center box;
- cw(120p) | cw(24p) sw(24p) sw(24p) , ^ | c | c | c.
- Standard attribute type Character sets
- NUM PRT TTX
- _
- .T&
- lw(120p) | lw(24p) | lw(24p) | lw(24p) .
- \fIGeneral\fR
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- T{
- administration\(hydomain\(hyname
- T} \(mu \(mu \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- common\(hyname \(em \(mu \(mu
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- country\(hyname \(mu \(mu \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- network\(hyaddress \(mu\|\ua\d\u)\d \(em \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- numeric\(hyuser\(hyidentifier \(mu \(em \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- organization\(hyname \(em \(mu \(mu
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- T{
- organizational\(hyunit\(hynames
- T} \(em \(mu \(mu
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- personal\(hyname \(em \(mu \(mu
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- private\(hydomain\(hyname \(mu \(mu \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- terminal\(hyidentifier \(em \(mu \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- terminal\(hytype \(em \(em \(em
- _
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- \fIPostal routing\fR
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- T{
- physical\(hydelivery\(hyservice\(hyname
- T} \(em \(mu \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- T{
- physical\(hydelivery\(hycountry\(hyname
- T} \(mu \(mu \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- postal\(hycode \(mu \(mu \(em
- _
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- \fIPostal addressing\fR
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- T{
- extension\(hypostal\(hyO/R\(hyaddress\(hycomponents
- T} \(em \(mu \(mu
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- T{
- extension\(hyphysical\(hydelivery\(hyaddress\(hycomponents
- T} \(em \(mu \(mu
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- local\(hypostal\(hyattributes \(em \(mu \(mu
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- T{
- physical\(hydelivery\(hyoffice\(hyname
- T} \(em \(mu \(mu
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- T{
- physical\(hydelivery\(hyoffice\(hynumber
- T} \(em \(mu \(mu
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- T{
- physical\(hydelivery\(hyorganization\(hyname
- T} \(em \(mu \(mu
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- T{
- physical\(hydelivery\(hypersonal\(hyname
- T} \(em \(mu \(mu
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- T{
- post\(hyoffice\(hybox\(hyaddress
- T} \(em \(mu \(mu
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- poste\(hyrestante\(hyaddress \(em \(mu \(mu
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- street\(hyaddress \(em \(mu \(mu
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- T{
- unformatted\(hypostal\(hyaddress
- T} \(em \(mu \(mu
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(24p) .
- unique\(hypostal\(hyname \(em \(mu \(mu
- _
- .T&
- lw(120p) | lw(24p) | lw(24p) | lw(24p) .
- NUM Numeric .parag PRT Printable .parag TTX Teletex .parag \(mu Permitted .parag
- .T&
- lw(120p) | lw(24p) | lw(24p) | lw(24p) .
- T{
- \ua\d\u)\d
- Under prescribed circumstances a sequence of octet
- strings
- .parag
- T}
- .TE
- .nr PS 9
- .RT
- .ad r
- \fBTable 9/X.402 [T9.402], p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .PP
- The standard attribute types, summarized in Table 9/X.402, are
- individually defined and described below.
- .sp 1P
- .LP
- 18.3.1
- \fIAdministration\(hydomain\(hyname\fR
- .sp 9p
- .RT
- .PP
- An \fBadministration\(hydomain\(hyname\fR is a standard attribute that
- identifies an ADMD relative to the country denoted by a country\(hyname.
- .PP
- The value of an administration\(hydomain\(hyname is a numeric or printable
- string chosen from a set of such strings that is administered for this
- purpose by the country alluded to above.
- .PP
- \fINote\fR \ \(em\ The attribute value comprising a single space (\*Q \*U)
- shall be reserved for the following purpose. If permitted by the country
- denoted by the country\(hyname attribute, a single space shall designate
- any (i.e.,\ all) ADMDs
- within the country. This affects both the identification of users within the
- country and the routing of messages, probes, and reports to and among the
- ADMDs of that country. Regarding the former, it requires that the O/R addresses
- of
- users within the country be chosen so as to ensure their unambiguousness,
- even in the absence of the actual names of the users' ADMDs. Regarding
- the latter, it permits both PRMDs within, and ADMDs outside of the country,
- to route
- messages, probes, and reports to any of the ADMDs within the country
- indiscriminantly, and requires that the ADMDs within the country interconnect
- themselves in such a way that the messages, probes, and reports are conveyed
- to their destinations.
- .RT
- .sp 1P
- .LP
- 18.3.2
- \fICommon\(hyname\fR
- .sp 9p
- .RT
- .PP
- A \fBcommon\(hyname\fR is a standard attribute that identifies a user or
- DL relative to the entity denoted by another attribute (e.g.,\ an
- organization\(hyname).
- .PP
- The value of a common\(hyname is a printable string, teletex string, or
- both. Whether printable or teletex, the string is chosen from a set of
- such
- strings that is administered for this purpose (and perhaps others) by the
- entity alluded to above.
- .PP
- \fINote\fR \ \(em\ Among many other possibilities, a common\(hyname might
- identify an organizational role (e.g.,\ \*QDirector of Marketing\*U).
- .RT
- .sp 1P
- .LP
- 18.3.3
- \fICountry\(hyname\fR
- .sp 9p
- .RT
- .PP
- A \fBcountry\(hyname\fR is a standard attribute that identifies a
- country.
- .PP
- The value of a country\(hyname is a numeric string that gives one of the
- numbers assigned to the country by Recommendation\ X.121, or a printable
- string that gives the character pair assigned to the country by ISO\ 3166.
- .RT
- .sp 1P
- .LP
- 18.3.4
- \fIExtension\(hypostal\(hyO/R\(hyaddress\(hycomponents\fR
- .sp 9p
- .RT
- .PP
- An \fBextension\(hypostal\(hyO/R\(hyaddress\(hycomponents\fR is a standard
- attribute that provides, in a postal address, additional information necessary
- to identify the addressee (e.g.,\ an organizational unit).
- .PP
- The value of an extension\(hyO/R\(hyaddress\(hycomponents is a printable
- string, teletex string, or both.
- .RT
- .sp 1P
- .LP
- 18.3.5
- \fIExtension\(hyphysical\(hydelivery\(hyaddress\(hycomponents\fR
- .sp 9p
- .RT
- .PP
- An \fBextension\(hyphysical\(hydelivery\(hyaddress\(hycomponents\fR is
- a standard attribute that specifies, in a postal address, additional information
- necessary to identify the exact point of delivery (e.g.,\ room and floor
- numbers in a
- large building).
- .PP
- The value of an extension\(hyphysical\(hydelivery\(hyaddress\(hycomponents is a
- printable string, teletex string, or both.
- .RT
- .sp 1P
- .LP
- 18.3.6
- \fILocal\(hypostal\(hyattributes\fR
- .sp 9p
- .RT
- .PP
- A \fBlocal\(hypostal\(hyattributes\fR is a standard attribute that identifies
- the locus of distribution, other than that denoted by a
- physical\(hydelivery\(hyoffice\(hyname attribute (e.g.,\ a geographical
- area), of a
- user's physical messages.
- .PP
- The value of a local\(hypostal\(hyattributes is a printable string,
- teletex string, or both.
- .bp
- .RT
- .sp 1P
- .LP
- 18.3.7
- \fINetwork\(hyaddress\fR
- .sp 9p
- .RT
- .PP
- A \fBnetwork\(hyaddress\fR is a standard attribute that gives the network
- address of a terminal.
- .PP
- The value of a network\(hyaddress is any one of the following:
- .RT
- .LP
- a)
- a numeric string governed by Recommendation X.121;
- .LP
- b)
- two numeric strings governed by Recommendations E.163
- and E.164;
- .LP
- c)
- a PSAP address.
- .PP
- \fINote\fR \ \(em\ Among the strings admitted by Recommendation X.121 is
- a telex number preceded by the telex escape digit\ (8).
- .sp 1P
- .LP
- 18.3.8
- \fINumeric\(hyuser\(hyidentifier\fR
- .sp 9p
- .RT
- .PP
- A \fBnumeric\(hyuser\(hyidentifier\fR is a standard attribute that
- numerically identifies a user relative to the ADMD denoted by an
- administration\(hydomain\(hyname.
- .PP
- The value of a numeric\(hyuser\(hyidentifier is a numeric string chosen
- from a set of such strings that is administered for this purpose by the
- ADMD alluded to above.
- .RT
- .sp 1P
- .LP
- 18.3.9
- \fIOrganization\(hyname\fR
- .sp 9p
- .RT
- .PP
- An \fBorganization\(hyname\fR is a standard attribute that identifies an
- organization. As a national matter, this identification may be either relative
- to the country denoted by a country\(hyname (so that organization names
- are unique within the country), or relative to the MD identified by a private\(hydomain\(hyname,
- or an administration\(hydomain\(hyname, or both.
- .PP
- The value of an organization\(hyname is a printable string, teletex
- string, or both. Whether printable or teletex, the string is chosen from
- a set of such strings that is administered for this purpose (and perhaps
- others) by the country or MD alluded to above.
- .PP
- \fINote\fR \ \(em\ In countries choosing country\(hywide unique organization\(hynames,
- a national registration authority for organization\(hynames is required.
- .RT
- .sp 1P
- .LP
- 18.3.10
- \fIOrganizational\(hyunit\(hynames\fR
- .sp 9p
- .RT
- .PP
- An \fBorganizational\(hyunit\(hynames\fR is a standard attribute that
- identifies one or more units (e.g.,\ divisions or departments) of the
- organization denoted by an organization\(hyname, each unit but the first
- being a sub\(hyunit of the units whose names precede it in the attribute.
- .PP
- The value of an organizational\(hyunit\(hynames is an ordered sequence of
- printable strings, an ordered sequence of teletex strings, or both. Whether
- printable or teletex, each string is chosen from a set of such strings
- that is administered for this purpose (and perhaps others) by the organization
- (or
- encompassing unit) alluded to above.
- .RT
- .sp 1P
- .LP
- 18.3.11
- \fIPhysicel\(hydelivery\(hyservice\(hyname\fR
- .sp 9p
- .RT
- .PP
- A \fBphysical\(hydelivery\(hyservice\(hyname\fR is a standard attribute that
- identifies a PDS relative to the\ ADMD denoted by an
- administration\(hydomain\(hyname.
- .PP
- The value of a physical\(hydelivery\(hyservice\(hyname is a printable string
- chosen from a set of such strings that is administered for this purpose
- by the ADMD alluded to above.
- .RT
- .sp 1P
- .LP
- 18.3.12
- \fIPersonal\(hyname\fR
- .sp 9p
- .RT
- .PP
- A \fBpersonal\(hyname\fR is a standard attribute that identifies a person
- relative to the entity denoted by another attribute (e.g.,\ an
- organization\(hyname).
- .PP
- The value of a personal\(hyname comprises the following four pieces of
- information, the first mandatory, the others optional:
- .RT
- .LP
- a)
- the person's surname;
- .LP
- b)
- the person's given name;
- .LP
- c)
- the initials of all of his names but his surname;
- .LP
- d)
- his generation (e.g., \*QJr\*U).
- .PP
- The above information is supplied as printable strings, teletex
- strings, or both.
- .bp
- .sp 1P
- .LP
- 18.3.13
- \fIPhysical\(hydelivery\(hycountry\(hyname\fR
- .sp 9p
- .RT
- .PP
- A \fBphysical\(hydelivery\(hycountry\(hyname\fR is a standard attribute that
- identifies the country in which a user takes delivery of physical messages.
- .PP
- The value of a physical\(hydelivery\(hycountry\(hyname is subject to the
- same constraints as is the value of a country\(hyname.
- .RT
- .sp 1P
- .LP
- 18.3.14
- \fIPhysical\(hydelivery\(hyoffice\(hyname\fR
- .sp 9p
- .RT
- .PP
- A \fBphysical\(hydelivery\(hyoffice\(hyname\fR is a standard attribute that
- identifies the city, village, etc. in which is situated the post office
- through which a user takes delivery of physical messages.
- .PP
- The value of a physical\(hydelivery\(hyoffice\(hyname is a printable string,
- teletex string, or both.
- .RT
- .sp 1P
- .LP
- 18.3.15
- \fIPhysical\(hydelivery\(hyoffice\(hynumber\fR
- .sp 9p
- .RT
- .PP
- A \fBphysical\(hydelivery\(hyoffice\(hynumber\fR is a standard attribute that
- distinguishes among several post offices denoted by a single
- physical\(hydelivery\(hyoffice\(hyname.
- .PP
- The value of a physical\(hydelivery\(hyoffice\(hynumber is a printable
- string, teletex string, or both.
- .RT
- .sp 1P
- .LP
- 18.3.16
- \fIPhysical\(hydelivery\(hyorganization\(hyname\fR
- .sp 9p
- .RT
- .PP
- A \fBphysical\(hydelivery\(hyorganization\(hyname\fR is a standard attribute
- that identifies a postal patron's organization.
- .PP
- The value of a physical\(hydelivery\(hyorganization\(hyname is a printable
- string, teletex string, or both.
- .RT
- .sp 1P
- .LP
- 18.3.17
- \fIPhysical\(hydelivery\(hypersonal\(hyname\fR
- .sp 9p
- .RT
- .PP
- A \fBphysical\(hydelivery\(hypersonal\(hyname\fR is a standard attribute that
- identifies a postal patron.
- .PP
- The value of a physical\(hydelivery\(hypersonal\(hyname is a printable
- string, teletex string, or both.
- .RT
- .sp 1P
- .LP
- 18.3.18
- \fIPost\(hyoffice\(hybox\(hyaddress\fR
- .sp 9p
- .RT
- .PP
- A \fBpost\(hyoffice\(hybox\(hyaddress\fR is a standard attribute that specifies
- the number of the post office box by means of which a user takes delivery
- of
- physical messages.
- .PP
- The value of a postal\(hycode is a numeric or printable string chosen
- from the set of such strings that is maintained and standardized for this
- purpose by the postal administration of the country identified by a
- physical\(hydelivery\(hycountry\(hyname attribute.
- .RT
- .sp 1P
- .LP
- 18.3.19
- \fIPostal\(hycode\fR
- .sp 9p
- .RT
- .PP
- A \fBpostal\(hycode\fR is a standard attribute that specifies the postal
- code for the geographical area in which a user takes delivery of physical
- messages.
- .PP
- The value of a postal\(hycode is a numeric or printable string chosen
- from the set of such strings that is maintained and standardized for this
- purpose by the postal administration of the country identified by a
- physical\(hydelivery\(hycountry\(hyname attribute.
- .RT
- .sp 1P
- .LP
- 18.3.20
- \fIPoste\(hyrestante\(hyaddress\fR
- .sp 9p
- .RT
- .PP
- A \fBposte\(hyrestante\(hyaddress\fR is a standard attribute that specifies
- the code that a user gives to a post office in order to collect the physical
- messages that await delivery to him.
- .PP
- The value of a poste\(hyrestante\(hyaddress is a printable string, teletex
- string, or both chosen from the set of such strings assigned for this purpose
- by the post office denoted by a physical\(hydelivery\(hyoffice\(hyname
- attribute.
- .bp
- .RT
- .sp 1P
- .LP
- 18.3.21
- \fIPrivate\(hydomain\(hyname\fR
- .sp 9p
- .RT
- .PP
- A \fBprivate\(hydomain\(hyname\fR is a standard attribute that identifies
- a PRMD. As a national matter, this identification may be either relative
- to the country denoted by a country\(hyname (so that PRMD names are unique
- within the
- country), or relative to the ADMD identified by an administration\(hydomain\(hyname.
- .PP
- The value of a private\(hydomain\(hyname is a numeric or printable string
- chosen from a set of such strings that is administered for this purpose
- by the country or ADMD alluded to above.
- .PP
- \fINote\fR \ \(em\ In countries choosing country\(hywide unique PRMD names, a
- national registration authority for private\(hydomain\(hynames is required.
- .RT
- .sp 1P
- .LP
- 18.3.22
- \fIStreet\(hyaddress\fR
- .sp 9p
- .RT
- .PP
- A \fBstreet\(hyaddress\fR is a standard attribute that specifies the
- street address (e.g.,\ house number and street name and type (e.g.,\ \*QRoad\*U))
- at which a user takes delivery of physical messages.
- .PP
- The value of a street\(hyaddress is a printable string, teletex string,
- or both.
- .RT
- .sp 1P
- .LP
- 18.3.23
- \fITerminal\(hyidentifier\fR
- .sp 9p
- .RT
- .PP
- A \fBterminal\(hyidentifier\fR is a standard attribute that gives the
- terminal identifier of a terminal (e.g.,\ a Telex answer back or a Teletex
- terminal identifier).
- .PP
- The value of a terminal\(hyidentifier is a printable string.
- .RT
- .sp 1P
- .LP
- 18.3.24
- \fITerminal\(hytype\fR
- .sp 9p
- .RT
- .PP
- A \fBterminal\(hytype\fR is a standard attribute that gives the type of
- a terminal.
- .PP
- The value of a terminal\(hytype is any one of the following: \fItelex,\fR
- \fIteletex, G3\ facsimile, G4\ facsimile, IA5\ terminal\fR , and \fIvideotex\fR
- .
- .RT
- .sp 1P
- .LP
- 18.3.25
- \fIUnformatted\(hypostal\(hyaddress\fR
- .sp 9p
- .RT
- .PP
- An \fBunformatted\(hypostal\(hyaddress\fR is a standard attribute that
- specifies a user's postal address in free form.
- .PP
- The value of an unformatted\(hypostal address is a sequence of printable
- strings, each representing a line of text, a single teletex string, lines
- being separated as prescribed for such strings; or both.
- .RT
- .sp 1P
- .LP
- 18.3.26
- \fIUnique\(hypostal\(hyname\fR
- .sp 9p
- .RT
- .PP
- A \fBunique\(hypostal\(hyname\fR is a standard attribute that identifies
- the point of delivery, other than that denoted by a street\(hyaddress,
- post\(hyoffice\(hybox\(hyaddress, or poste\(hyrestante\(hyaddress, (e.g.,\
- a building or
- hamlet) of a user's physical messages.
- .PP
- The value of a unique\(hypostal\(hyname is a printable string, teletex
- string, or both.
- .RT
- .sp 1P
- .LP
- 18.4
- \fIAttribute list equivalence\fR
- .sp 9p
- .RT
- .PP
- Several O/R addresses, and thus several attribute lists, may denote the
- same user or DL. This multiplicity of O/R addresses results in part (but
- not in full) from the following attribute list equivalence rules:
- .RT
- .LP
- a)
- The relative order of standard attributes is insignificant.
- .LP
- b)
- Where the value of a standard attribute may be a numeric
- string or an equivalent printable string, the choice between them shall be
- considered insignificant.
- .LP
- \fINote\fR \ \(em\ This rule applies even to the country\(hyname standard
- attribute, where the choice between X.121 or ISO\ 3166 forms shall be considered
- insignificant, where X.121 allocates more than one number to a country,
- the
- significance of which number is used has not been standardized by this
- Recommendation.
- .LP
- c)
- Where the value of a standard attribute may be a printable string, an
- equivalent teletex string, or both, the choice between the three
- possibilities shall be considered insignificant.
- .bp
- .LP
- d)
- Where the value of a standard attribute may contain letters, the cases
- of those letter shall be considered insignificant.
- .LP
- e)
- In a domain\(hydefined attribute type or value, or in a
- standard attribute value, all leading, all trailing, and all but one
- consecutive embedded spaces shall be considered insignificant.
- .PP
- \fINote\ 1\fR \ \(em\ An MD may impose additional equivalence rules upon
- the attributes it assigns to its own users and DLs. It might define, e.g.,\
- rules
- concerning punctuation characters in attribute values, the case of letters
- in such values, or the relative order of domain\(hydefined attributes.
- .PP
- \fINote\ 2\fR \ \(em\ As a national matter, MDs may impose additional equivalence
- rules regarding standard attributes whose values are given as teletex strings,
- in particular, the rules for deriving the equivalent printable strings.
- .RT
- .sp 1P
- .LP
- 18.5
- \fIO/R address forms\fR
- .sp 9p
- .RT
- .PP
- Every user or DL is assigned one or more O/R addresses. An \fBO/R
- address\fR is an attribute list that distinguishes one user from another and
- identifies the user's point of access to the MHS or the DL's expansion point.
- .PP
- An O/R address may take any of the forms summarized in Table 10/X.402.
- The first column of the table identifies the attributes available for the
- construction of O/R addresses. For each O/R address form, the second column
- indicates the attributes that may appear in such O/R addresses and their
- grades (see also \(sc\ 18.6).
- .PP
- Table 10/X.402 has four sections. Attribute types in the first are
- those of a general nature, attribute types in the second and third those
- specific to physical delivery. The fourth section encompasses domain\(hydefined
- attributes.
- .RT
- .PP
- The forms of O/R address, summarized in Table 10/X.402 are
- individually defined and described below.
- .sp 1P
- .LP
- 18.5.1
- \fIMnemonic O/R address\fR
- .sp 9p
- .RT
- .PP
- A \fBmnemonic O/R address\fR is one that mnemonically identifies a user
- or DL. It identifies an ADMD, and a user or DL relative to it.
- .PP
- A mnemonic O/R address comprises the following attributes:
- .RT
- .LP
- a)
- one country\(hyname and one administration\(hydomain\(hyname, which together
- identify an ADMD;
- .LP
- b)
- one private\(hydomain\(hyname, one organization\(hyname, one
- organizational\(hyunit\(hynames, one personal\(hyname or common\(hyname,
- or a combination of the above; and optionally one or more domain\(hydefined
- attributes; which
- together identify a user or DL relative to the ADMD in item\ a) above.
- .sp 1P
- .LP
- 18.5.2
- \fINumeric O/R address\fR
- .sp 9p
- .RT
- .PP
- A \fBnumeric O/R address\fR is one that numerically identifies a user.
- It identifies an ADMD, and a user relative to it.
- .PP
- A numeric O/R address comprises the following attributes:
- .RT
- .LP
- a)
- one country\(hyname and one administration\(hydomain\(hyname, which together
- identify an ADMD;
- .LP
- b)
- one numeric\(hyuser\(hyidentifier and, conditionally, one
- private\(hydomain\(hyname, which together identify the user relative to
- the ADMD in item a above;
- .LP
- c)
- conditionally, one or more domain\(hydefined attributes which provide
- information additional to that which identifies the user.
- .sp 1P
- .LP
- 18.5.3
- \fIPostal O/R address\fR
- .sp 9p
- .RT
- .PP
- A \fBpostal O/R address\fR is one that identifies a user by means of
- its postal address. It identifies the PDS through which the user is to be
- accessed and gives the user's postal address.
- .PP
- The following kinds of postal O/R address are
- distinguished:
- .RT
- .LP
- a)
- \fBformatted\fR ;: Said of a postal O/R address that specifies a user's
- postal address by means of several attributes. For this form of postal
- O/R address, this Recommendation prescribes the structure of postal addresses
- in some detail;
- .LP
- b)
- \fBunformatted\fR ;: Said of a postal O/R address that specifies a user's
- postal address in a single attribute. For this form of postal O/R
- address, this Recommendation largely does not prescribe the structure of
- postal addresses.
- .bp
- .ce
- \fBH.T. [T10.402]\fR
- .ce
- TABLE\ 10/X.402
- .ce
- \fBForms of O/R address\fR
- .ps 9
- .vs 11
- .nr VS 11
- .nr PS 9
- .TS
- center box;
- cw(120p) | cw(24p) sw(24p) sw(12p) sw(12p) sw(24p) , ^ | c | c | c s
- ^ | ^ | ^ | ^ | ^ | c
- ^ | l | l | c | c | l.
- Attribute type O/R address forms
- MNEM NUMR POST TERM F U
- _
- .T&
- lw(120p) | lw(24p) | lw(24p) | lw(12p) | lw(12p) | lw(24p) .
- \fIGeneral\fR
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- T{
- administration\(hydomain\(hyname
- T} M M M M C
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- common\(hyname C \(em \(em \(em \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- country\(hyname M M M M C
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- network\(hyaddress \(em \(em \(em \(em M
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- numeric\(hyuser\(hyidentifier \(em M \(em \(em \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- organization\(hyname C \(em \(em \(em \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- T{
- organizational\(hyunit\(hynames
- T} C \(em \(em \(em \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- personal\(hyname C \(em \(em \(em \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- private\(hydomain\(hyname C C C C C
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- terminal\(hyidentifier \(em \(em \(em \(em C
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- terminal\(hyidentifier \(em \(em \(em \(em C
- _
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- \fIPostal routing\fR
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- T{
- physical\(hydelivery\(hyservice
- T} \(em \(em C C \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- T{
- physical\(hydelivery\(hycountry\(hyname
- T} \(em \(em M M \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- postal\(hycode \(em \(em M M \(em
- _
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- \fIPostal addressing\fR
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- T{
- extension\(hypostal\(hyO/R\(hyaddress\(hycomponents
- T} \(em \(em C \(em \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- T{
- extension\(hyphysical\(hydelivery\(hyaddress\(hycomponents
- T} \(em \(em C \(em \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- local\(hypostal\(hyattributes \(em \(em C \(em \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- T{
- physical\(hydelivery\(hyoffice\(hyname
- T} \(em \(em C \(em \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- T{
- physical\(hydelivery\(hyoffice\(hynumber
- T} \(em \(em C \(em \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- T{
- physical\(hydelivery\(hyorganization\(hyname
- T} \(em \(em C \(em \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- T{
- physical\(hydelivery\(hypersonal\(hyname
- T} \(em \(em C \(em \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- T{
- poste\(hyoffice\(hybox\(hyaddress
- T} \(em \(em C \(em \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- poste\(hyrestante\(hyaddress \(em \(em C \(em \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- street address \(em \(em C \(em \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- T{
- unformatted\(hypostal\(hyaddress
- T} \(em \(em \(em M \(em
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- unique\(hypostal\(hyname \(em \(em C \(em \(em
- _
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- \fIDomain\(hydefined\fR
- .T&
- lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
- T{
- domain\(hydefined (one or more)
- T} C C \(em \(em C
- _
- .T&
- lw(72p) | lw(144p) .
- T{
- MNEM
- Mnemonic
- NUMR
- Numeric
- POST
- Postal
- TERM
- Terminal
- T} T{
- F
- Formatted
- U
- Unformatted
- M
- Mandatory
- C
- Conditional
- .parag
- T}
- .TE
- .nr PS 9
- .RT
- .ad r
- \fBTable 10/X.402 [T10.402], p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .PP
- A postal O/R address, whether formatted or unformatted, comprises the following
- attributes:
- .LP
- a)
- one country\(hyname and one administration\(hydomain\(hyname, which together
- identify an ADMD;
- .LP
- b)
- conditionally, one private\(hydomain\(hyname, one
- physical\(hydelivery\(hyservice\(hyname, or both, which together identify
- the PDS
- by means of which the user is to be accessed;
- .LP
- c)
- one physical\(hydelivery\(hycountry\(hyname and one postal\(hycode,
- which together identify the geographical region in which the user takes
- delivery of physical messages.
- .PP
- A formatted postal O/R address comprises, additionally, one of
- each postal addressing attribute (see Table\ 9B/FX.402), except
- unformatted\(hypostal\(hyaddress, that the PDS requires to identify the postal
- patron.
- .PP
- An unformatted postal O/R address comprises, additionally, one
- unformatted\(hypostal\(hyaddress attribute.
- .PP
- \fINote\fR \ \(em\ The total number of characters in the values of all
- attributes but country\(hyname, administration\(hydomain\(hyname, and
- physical\(hydelivery\(hyservice\(hyname in a postal O/R address should
- be small enough to permit their rendition in 6\ lines of 30\ characters,
- the size of a typical
- physical envelope window. The rendition algorithm is PDAU\(hyspecific but is
- likely to include inserting delimiters (e.g.,\ spaces) between some attribute
- values.
- .RT
- .sp 1P
- .LP
- 18.5.4
- \fITerminal O/R address\fR
- .sp 9p
- .RT
- .PP
- A \fBterminal OB/FR address\fR is one that identifies a user by means of
- the network address and, if required, the type of his terminal. It may
- also
- identify the ADMD through which that terminal is accessed. In the case of a
- telematic terminal, it gives the terminal's network address and possibly its
- terminal identifier and terminal type. In the case of a telematic terminal,
- it gives the terminal's network address and possibly its terminal identifier
- and terminal type. In the case of a telex terminal, it gives its telex
- number.
- .PP
- A terminal O/R address comprises the following attributes:
- .RT
- .LP
- a)
- one network\(hyaddress;
- .LP
- b)
- conditionally, one terminal\(hyidentifier;
- .LP
- c)
- conditionally, one terminal\(hytype;
- .LP
- d)
- conditionally, both one country\(hyname and one
- administration\(hydomain\(hyname which together identify an ADMD;
- .LP
- e)
- conditionally, one private\(hydomain\(hyname and, conditionally, one
- or more domain\(hydefined attributes, all of which provide information
- additional to that which identifies the user.
- .PP
- The private\(hydomain\(hyname and the domain\(hydefined attributes shall
- be present only if the country\(hyname and administration\(hydomain\(hyname
- attributes are present.
- .sp 1P
- .LP
- 18.6
- \fIConditional attributes\fR
- .sp 9p
- .RT
- .PP
- The presence or absence in a particular O/R address of the
- attributes marked conditional in Table\ 10B/FX.402 is determined as follows.
- .PP
- If a user or DL is accessed through a PRMD, attributes used to route messages
- to the PRMD are present in the O/R address at the discretion of, and in
- accordance with rules established by the ADMD denoted by the country\(hyname
- and administration\(hydomain\(hyname attributes of the O/R address. The
- ADMD imposes no other constraints on the attributes in the O/R address.
- If a user is not
- accessed through a PRMD, all conditional attributes except those specific to
- postal O/R addresses are present in an O/R address at the discretion of,
- and in accordance with rules established by, the ADMD denoted by the country\(hyname
- and administration\(hydomain\(hyname attributes.
- .PP
- All conditional attributes specific to postal O/R addresses are
- present or absent in such O/R addresses so as to satisfy the postal addressing
- requirements of the users they identify.
- .RT
- .sp 2P
- .LP
- \fB19\fR \fBRouting\fR
- .sp 1P
- .RT
- .PP
- To convey a message, probe, or report toward a user or the
- expansion point of a DL, an MTA must not only locate the user or DL
- (i.e.,\ obtain its O/R address) but also select a route to that location.
- .PP
- External routing is an incremental and only loosely standardized
- process. Suggested below are several principles of external routing. Internal
- routing is outside the scope of this Recommendation.
- .bp
- .PP
- The following principles are illustrative, not definitive:
- .RT
- .LP
- a)
- In an MHS that comprises a single MD, of course, routing is not an issue.
- .LP
- b)
- A PRMD may be connected to a single, ADMD. When this is so, routing always
- involves the ADMD necessarily.
- .LP
- c)
- An ADMD may be connected to multiple PRMDs. When this is so, routing
- may be based upon conditional O/R address attributes, including but not
- limited to private\(hydomain\(hyname.
- .LP
- d)
- An MD may be directly connected to some but not all other
- MDs. When the O/R address identifies a MD to which no direct connection
- exists, routing may be based upon \fIbilateral agreements\fR with the MDs
- to which direct connections do exist and other local rules.
- .LP
- e)
- When the MD is directly connected to the MD identified by
- the O/R address, the object is typically routed to that MD directly.
- .LP
- f)
- By \fIbilateral agreement\fR , one MD might route an object to
- another MD for the purpose, e.g.,\ of conversion.
- .LP
- g)
- An MD may route to a malformed O/R address provided (of
- course) that it contains at least the attributes required to do so.
- .PP
- \fINote\fR \ \(em\ The bilateral agreements and local rules
- alluded to above are beyond the
- scope of this Recommendation and may be based upon technical, policy, economic,
- or other considerations.
- .LP
- SECTION\ 5\ \(em\
- USE OF THE DIRECTORY
- .sp 1P
- .RT
- .sp 2P
- .LP
- \fB20\fR \fBOverview\fR
- .sp 1P
- .RT
- .PP
- This section describes the uses to which the MHS may put the
- Directory if it is present. If the Directory is unavailable to the MHS,
- how, if at all, the MHS performs these same tasks is a local matter.
- .PP
- This section covers the following topics:
- .RT
- .LP
- a)
- authentication;
- .LP
- b)
- name resolution;
- .LP
- c)
- DL expansion;
- .LP
- d)
- capability assessment.
- .sp 2P
- .LP
- \fB21\fR \fBAuthentication\fR
- .sp 1P
- .RT
- .PP
- A functional object may accomplish authentication
- using information stored in
- the Directory.
- .RT
- .sp 2P
- .LP
- \fB22\fR \fBName resolution\fR
- .sp 1P
- .RT
- .PP
- A functional object may accomplish name resolution using the
- Directory.
- .PP
- To obtain the O/R address(es) of a user or DL whose Directory name it possesses,
- an object presents that name to the Directory and requests from the object's
- Directory entry the following attributes:
- .RT
- .LP
- a)
- \fIMHS O/R addresses\fR ;
- .LP
- b)
- \fIMHS preferred delivery methods\fR
- .PP
- To do this successfully, the object must first authenticate itself to the
- Directory and have access rights to the information requested.
- .bp
- .sp 2P
- .LP
- \fB23\fR \fBDL expansion\fR
- .sp 1P
- .RT
- .PP
- A functional object may accomplish DL expansion using the
- Directory, first verifying that the necessary submit permissions exist.
- .PP
- To obtain the members of a DL whose Directory name it possesses, the object
- presents that name to the Directory and requests from the object's
- Directory entry the following attributes:
- .RT
- .LP
- a)
- \fIMHS DL members\fR ;
- .LP
- b)
- \fIMHS DL submit permissions\fR ;
- .LP
- c)
- \fIMHS preferred delivery methods\fR .
- .PP
- To do this successfully, the MTA must first authenticate itself to the
- Directory and have access rights to the information requested.
- .sp 2P
- .LP
- \fB24\fR \fBCapability assessment\fR
- .sp 1P
- .RT
- .PP
- A functional object may assess the capabilities of a user or MS
- using the Directory.
- .PP
- The following Directory attributes represent user capabilities of
- possible significance in message handling:
- .RT
- .LP
- a)
- \fIMHS deliverable content length\fR ;
- .LP
- b)
- \fIMHS deliverable content types\fR ;
- .LP
- c)
- \fIMHS deliverable EITs\fR ;
- .LP
- d)
- \fIMHS preferred delivery methods\fR .
- .PP
- The following Directory attributes represent MS capabilities of
- possible significance in message handling:
- .LP
- a)
- \fIMHS supported automatic actions\fR ;
- .LP
- b)
- \fIMHS supported content types\fR ;
- .LP
- c)
- \fIMHS supported optional attributes\fR .
- .PP
- To assess a particular capability of a user or MS whose Directory name
- it possesses, the object presents that name to the Directory and requests
- from the object's Directory entry the attribute associated with that
- capability.
- .PP
- To do this successfully, the MTA must first authenticate itself to the
- Directory and have access rights to the information requested.
- .RT
- .LP
- SECTION\ 6\ \(em\ OSI REALIZATION
- .sp 1P
- .RT
- .sp 2P
- .LP
- \fB25\fR \fBOverview\fR
- .sp 1P
- .RT
- .PP
- This section describes how the MHS is realized by means of OSI.
- .PP
- This section covers the following topics:
- .RT
- .LP
- a)
- application service elements;
- .LP
- b)
- application contexts.
- .sp 2P
- .LP
- \fB26\fR \fBApplication service elements\fR
- .sp 1P
- .RT
- .PP
- This paragraph identifies the application service elements\fR (ASEs) that
- figure in the OSI realization of message handling.
- .PP
- In OSI the communication capabilities of open systems are organized
- into groups of related capabilities called ASEs. The present clause reviews
- this concept from the OSI reference model, draws a distinction between
- \fIsymmetric\fR and \fIasymmetric\fR ASEs, and introduces the ASEs defined
- for or
- supportive of Message Handling.
- .PP
- \fINote\fR \ \(em\ Besides the ASEs discussed, the MHS relies upon the
- Directory access service element defined in Recommendation\ X.519. However,
- since that
- ASE does not figure in the ACs for message handling (see Recommendation\
- X.419), it is not discussed here.
- .bp
- .RT
- .sp 1P
- .LP
- 26.1
- \fIThe ASE concept\fR
- .sp 9p
- .RT
- .PP
- The ASE concept is illustrated in Figure 12B/FX.402, which depicts
- two communicating open systems. Only the OSI\(hyrelated portions of the open
- systems, called AEs, are shown. Each AE comprises a UE and one or more
- ASEs. A UE represents the controlling or organizing portion of an AE which
- defines the open system's role (e.g.,\ that of an MTA). An ASE represents
- one of the
- communication capability sets, or services (e.g.,\ for message submission or
- transfer), that the UE requires to play its role.
- .PP
- The relationship between two AEs in different open systems is called an
- application association. The ASEs in each open system communicate with
- their peer ASEs in the other open system via a presentation connection
- between them. That communication is what creates and sustains the relationship
- embodied in
- the application association. For several ASEs to be successfully combined
- in a single AE, they must be designed to coordinate their use of the application
- association.
- .RT
- .LP
- .rs
- .sp 21P
- .ad r
- \fBFigure 12/X.402, p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- An ASE plays the largely mechanical role of translating requests and responses
- made by its UE to and from the form dictated by the application protocol
- that governs the ASE's interaction with its peer ASE in the open
- system to which the association connects it. The ASE realizes an abstract
- service, or a part thereof, for purposes of OSI communication (see
- Recommendation\ X.407).
- .PP
- \fINote\fR \ \(em\ Strictly speaking, an open system's role is determined
- by the behaviour of its application processes. In the message handling
- context an
- application process realizes a functional object of one of the types defined
- in \(sc\ 7. A UE in turn is one part of an application process.
- .RT
- .sp 1P
- .LP
- 26.2
- \fISymmetric and asymmetric ASEs\fR
- .sp 9p
- .RT
- .PP
- The following two kinds of ASE, illustrated in Figure 13/X.402, can be
- distinguished:
- .RT
- .LP
- a)
- \fBsymmetric\fR : Said of an ASE by means of which a UE both supplies
- and consumes a service. The ASE for message transfer, e.g.,\ is
- symmetric because both open systems, each of which embodies an MTA, offer
- and may consume the service of message transfer by means of it.
- .LP
- b)
- \fBasymmetric\fR : Said of an ASE by means of which a UE
- supplies or consumes a service, but not both, depending upon how the ASE is
- configured. The ASE for message delivery, e.g.,\ is asymmetric because
- only the open system embodying an MTA offers the associated service and
- only the other open system, which embodies a UA or MS, consumes it.
- .bp
- .LP
- .rs
- .sp 16P
- .ad r
- \fBFigure 13/X.402, p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- With respect to a particular asymmetric ASE, one UE supplies a
- service which the other consumes. The ASEs co\(hylocated with the UEs assist in
- the service's supply and consumption. The resulting four roles are captured
- in Figure\ 14/X.402 and in the following terminology:
- .LP
- a)
- \fBx\(hysupplying UE\fR : An application process that supplies the service
- represented by asymmetric ASE\ x.
- .LP
- b)
- \fBx\(hysupplying ASE\fR : An asymmetric ASE\ x configured for
- co\(hylocation with an x\(hysupplying\(hyUE.
- .LP
- c)
- \fBx\(hyconsuming UE\fR : An application process that consumes the service
- represented by asymmetric ASE\ x.
- .LP
- d)
- \fBx\(hyconsuming ASE\fR : An asymmetric ASE x configured for
- co\(hylocation with an x\(hyconsuming\(hyUE.
- .LP
- .rs
- .sp 22P
- .ad r
- \fBFigure 14/X.402, p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .PP
- As indicated, the four roles described above are defined relative to a
- particular ASE. When an AE comprises several asymmetric ASEs, these roles
- are assigned independently for each ASE. Thus, as shown in Figure\ 15/X.402,
- a single UE might serve as the consumer with respect to one ASE and as
- the
- supplier with respect to another.
- .LP
- .rs
- .sp 19P
- .ad r
- \fBFigure 15/X.402, p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 1P
- .LP
- 26.3
- \fIMessage handling ASEs\fR
- .sp 9p
- .RT
- .PP
- The ASEs that provide the various message handling services are
- listed in the first column of Table\ 11/X.402. For each ASE listed, the
- second column indicates whether it is symmetric or asymmetric. The third
- column
- identifies the functional objects \(em UAs, MSs, MTAs, and AUs \(em that are
- associated with the ASE, either as consumer or as supplier.
- .RT
- .ce
- \fBH.T. [T11.402]\fR
- .ce
- TABLE\ 11/X.402
- .ce
- \fBMessage handling ASEs\fR
- .ps 9
- .vs 11
- .nr VS 11
- .nr PS 9
- .TS
- center box;
- cw(30p) | cw(30p) | cw(24p) sw(24p) sw(24p) sw(24p) , ^ | ^ | c | c | c | c.
- ASE Form Functional objects
- UA MS MTA AU
- _
- .T&
- lw(30p) | lw(30p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
- MTSE SY \(em \(em CS \(em
- _
- .T&
- lw(30p) | lw(30p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
- MSSE ASY C CS S \(em
- .T&
- lw(30p) | lw(30p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
- MDSE ASY C C\fBS\fR S \(em
- .T&
- lw(30p) | lw(30p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
- MRSE ASY C S\fBS\fR \(em \(em
- .T&
- lw(30p) | lw(30p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
- MASE ASY C CS S \(em
- _
- .T&
- lw(30p) | lw(30p) | lw(24p) | lw(24p) | cw(24p) | cw(24p) .
- SY Symmetric .parag ASY Asymmetric .parag C Consumer .parag S Supplier .parag
- .TE
- .nr PS 9
- .RT
- .ad r
- \fBTable 11/X.402 [T11.402], p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .PP
- The message handling ASEs, summarized in Table 11/X.402, are
- individually introduced in the clauses below. Each is defined in
- Recommendation\ X.419.
- .sp 1P
- .LP
- 26.3.1
- \fIMessage transfer\fR
- .sp 9p
- .RT
- .PP
- The message transfer service element (MTSE) is the means by which the transfer
- transmittal step is effected.
- .RT
- .sp 1P
- .LP
- 26.3.2
- \fIMessage submission\fR
- .sp 9p
- .RT
- .PP
- The message submission service element (MSSE) is the means by
- which the submission transmittal step is effected.
- .RT
- .sp 1P
- .LP
- 26.3.3
- \fIMessage delivery\fR
- .sp 9p
- .RT
- .PP
- The message delivery service element (MDSE) is the means by which the delivery
- transmittal step is effected.
- .RT
- .sp 1P
- .LP
- 26.3.4
- \fIMessage retrieval\fR
- .sp 9p
- .RT
- .PP
- The message retrieval service element (MRSE) is the means by
- which the retrieval transmittal step is effected.
- .RT
- .sp 1P
- .LP
- 26.3.5
- \fIMessage administration\fR
- .sp 9p
- .RT
- .PP
- The message administration service element (MASE) is the means by which
- a UA, MS, or MTA places on file with one another information that enables
- and controls their subsequent interaction by means of the MSSE, MDSE, MRSE,
- and MASE.
- .RT
- .sp 1P
- .LP
- 26.4
- \fISupporting ASEs\fR
- .sp 9p
- .RT
- .PP
- The general\(hypurpose ASEs upon which message handling ASEs depend
- are listed in the first column of Table\ 12/X.402. For each listed ASE, the
- second column indicates whether it is symmetric or asymmetric.
- .RT
- .ce
- \fBH.T. [T12.402]\fR
- .ce
- TABLE\ 12/X.402
- .ce
- \fBSupporting ASEs\fR
- .ps 9
- .vs 11
- .nr VS 11
- .nr PS 9
- .TS
- center box;
- cw(66p) | cw(66p) .
- ASE Form
- _
- .T&
- cw(66p) | cw(66p) .
- ROSE SY
- .T&
- cw(66p) | cw(66p) .
- RTSE SY
- .T&
- cw(66p) | cw(66p) .
- ACSE SY
- _
- .T&
- lw(66p) | cw(66p) .
- SY Symmetric .parag
- .TE
- .nr PS 9
- .RT
- .ad r
- \fBTable 12/X.402 [T12.402], p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- .sp 1
- The supporting ASEs, summarized in Table 12/X.402 are individually introduced
- below.
- .sp 1P
- .LP
- 26.4.1
- \fIRemote operations\fR
- .sp 9p
- .RT
- .PP
- The remote operations service element (ROSE) is the means by
- which the asymmetric Message Handling ASEs structure their request\(hyresponse
- interactions between consuming and supplying open systems.
- .PP
- The ROSE is defined in Recommendation X.219.
- .bp
- .RT
- .sp 1P
- .LP
- 26.4.2
- \fIReliable transfer\fR
- .sp 9p
- .RT
- .PP
- The reliable transfer service element (RTSE) is the means by
- which various symmetric and asymmetric message handling ASEs convey information
- objects \(em especially large ones (e.g.,\ facsimile messages) \(em between
- open
- systems so as to ensure their safe\(hystorage at their destinations.
- .PP
- The RTSE is defined in Recommendation X.218.
- .RT
- .sp 1P
- .LP
- 26.4.3
- \fIAssociation control\fR
- .sp 9p
- .RT
- .PP
- The association control service element (ACSE) is the means by
- which all application associations between open systems are established,
- released, and in other respects managed.
- .PP
- The ACSE is defined in Recommendation X.217.
- .RT
- .sp 2P
- .LP
- \fB27\fR \fBApplication contexts\fR
- .sp 1P
- .RT
- .PP
- In OSI the communication capabilities (i.e., ASEs) of two open
- systems are marshalled for a particular purpose by means of application
- contexts (ACs). An AC is a detailed specification of the use of an association
- between two open systems, i.e., a protocol.
- .PP
- An AC specifies how the association is to be established (e.g., what
- initialization parameters are to be exchanged), what ASEs are to engage in
- peer\(hyto\(hypeer communication over the association, what constraints
- (if any) are to be imposed upon their individual use of association, whether
- the initiator or responder is the consumer of each asymmetric ASE, and
- how the association is to be released (e.g., what finalization parameters
- are to be exchanged).
- .PP
- Every AC is named (by an ASN.1 object identifier). The initiator of an
- association indicates to the responder the AC that will govern the
- association's use by conveying the AC's name to it by means of the ACSE.
- .PP
- An AC also identifies by name (an ASN.1 object identifier) the
- abstract syntaxes of the APDUs that an association may carry as a result
- of its use by the AC's ASEs. Conventionally one assigns a name to the set
- of APDUs
- associated either with each individual ASE or with the AC as a whole. The
- initiator of an association indicates to the responder the one or more
- abstract syntaxes associated with the AC by conveying their names to it
- via the ACSE.
- .PP
- The abstract syntax of an APDU is its structure as an information
- object (e.g.,\ an ASN.1 Set comprising an Integer command code and an IA5
- String command argument). It is distinguished from the APDU's transfer
- syntax which is how the information object is represented for transmission
- between two open
- systems (e.g.,\ one octet denoting an ASN.1 Set, followed by one octet giving
- the length of the Set,\ etc.).
- .PP
- The ACs by means of which the various message handling services are
- provided are specified in Recommendation\ X.419. These protocols are known as
- P1, P3, and P7.
- .PP
- \fINote\fR \ \(em\ The nature of a message's content does not enter into the
- definition of message handling ACs because the content is encapsulated
- (as an octet string) in the protocols by means of which it is conveyed.
- \v'1P'
- .RT
- .ce 1000
- ANNEX\ A
- .ce 0
- .ce 1000
- (to Recommendation X.402)
- .sp 9p
- .RT
- .ce 0
- .ce 1000
- \fBDirectory object classes and attributes\fR
- .sp 1P
- .RT
- .ce 0
- .PP
- This Annex is an integral part of this Recommendation.
- .sp 1P
- .RT
- .PP
- Several Directory object classes, attributes, and attribute
- syntaxes are specific to Message Handling. These are defined in the present
- Annex using the OBJECT\(hyCLASS, ATTRIBUTE, and ATTRIBUTE\(hySYNTAX macros of
- Recommendation X.501, respectively.
- .bp
- .sp 1P
- .LP
- A.1
- \fIObject classes\fR
- .sp 9p
- .RT
- .PP
- The object classes specific to message handling
- are those specified below.
- .PP
- \fINote\fR \ \(em\ The Directory object classes described in this Annex
- can be combined with other object classes, eg., the ones defined in
- Recommendation\ X.521. See also Recommendation\ X.501, \(sc\ 9, for an
- explanation of how Directory object classes can be combined in one Directory
- entry. Annex\ B of Recommendation\ X.521 gives some further information
- about Directory name forms and possible Directory information tree structures.
- .RT
- .sp 1P
- .LP
- A.1.1
- \fIMHS distribution list\fR
- .sp 9p
- .RT
- .PP
- An \fBMHS distribution list\fR object is a DL. The attributes in
- its entry identify its common name, submit permissions, and O/R addresses
- and, to the extent that the relevant attributes are present, describe the
- DL,
- identify its organization, organizational units, and owner; cite related
- objects; and identify its deliverable content types, deliverable EITs,
- members, and preferred delivery methods.
- .RT
- .LP
- mhs\(hydistribution\(hylist OBJECT\(hyCLASS
- .LP
- SUBCLASS OF top
- .LP
- MUST CONTAIN\|{
- .LP
- commonName,
- .LP
- mhs\(hydl\(hysubmit\(hypermissions,
- .LP
- mhs\(hyor\(hyaddresses}
- .LP
- MAY CONTAIN\|{
- .LP
- description,
- .LP
- organization,
- .LP
- organizationalUnitName,
- .LP
- owner,
- .LP
- seeAlso,
- .LP
- mhs\(hydeliverable\(hycontent\(hytypes,
- .LP
- mhs\(hydeliverable\(hyeits,
- .LP
- mhs\(hydl\(hymembers,
- .LP
- mhs\(hypreferred\(hydelivery\(hymethods\|}
- .LP
- ::= id\(hyoc\(hymhs\(hydistribution\(hylist
- .sp 1P
- .LP
- A.1.2
- \fIMHS message store\fR
- .sp 9p
- .RT
- .PP
- An \fBMHS message store\fR object is an AE that realizes an MS. The
- attributes in its entry, to the extent that they are present, describe
- the MS, identify its owner, and enumerate the optional attributes, automatic
- actions, and content types it supports.
- .RT
- .LP
- mhs\(hymessage\(hystore OBJECT\(hyCLASS
- .LP
- SUBCLASS OF applicationEntity
- .LP
- MAY CONTAIN\|{
- .LP
- description,
- .LP
- owner,
- .LP
- mhs\(hysupported\(hyoptional\(hyattributes,
- .LP
- mhs\(hysupported\(hyautomatic\(hyactions,
- .LP
- mhs\(hysupported\(hycontent\(hytypes\|}
- .LP
- ::= id\(hyoc\(hymhs\(hymessage\(hystore
- .sp 1P
- .LP
- A.1.3
- \fIMHS message transfer agent\fR
- .sp 9p
- .RT
- .PP
- An \fBMHS message transfer agent\fR object is an AE that implements an
- MTA. The attributes in its entry, to the extent that they are present,
- describe the MTA and identify its owner and its deliverable content length.
- .RT
- .LP
- mhs\(hymessage\(hytransfer\(hyagent OBJECT\(hyCLASS
- .LP
- SUBCLASS OF applicationEntity
- .LP
- MAY CONTAIN\|{
- .LP
- description,
- .LP
- owner,
- .LP
- mhs\(hydeliverable\(hycontent\(hylength\|}
- .LP
- ::= id\(hyoc\(hymhs\(hymessage\(hytransfer\(hyagent
- .bp
- .sp 1P
- .LP
- A.1.4
- \fIMHS user\fR
- .sp 9p
- .RT
- .PP
- An \fBMHS user\fR object is a generic MHS user. (The generic MHS user can
- have, for example, a business address, a residential address, or both.)
- The attributes in its entry identify the user's O/R address and, to the
- extent that the relevant attributes are present, identify the user's deliverable
- content
- length, content types, and EITs; its MS; and its preferred delivery
- methods.
- .RT
- .LP
- mhs\(hyuser OBJECT\(hyCLASS
- .LP
- SUBCLASS OF top
- .LP
- MUST CONTAIN\|{
- .LP
- mhs\(hyor\(hyaddresses\|}
- .LP
- MAY CONTAIN\|{
- .LP
- mhs\(hydeliverable\(hycontent\(hylength,
- .LP
- mhs\(hydeliverable\(hycontent\(hytypes,
- .LP
- mhs\(hydeliverable\(hyeits,
- .LP
- mhs\(hymessage\(hystore,
- .LP
- mhs\(hypreferred\(hydelivery\(hymethods\|}
- .LP
- ::= id\(hyoc\(hymhs\(hyuser
- .sp 1P
- .LP
- A.1.5
- \fIMHS user agent\fR
- .sp 9p
- .RT
- .PP
- An \fBMHS user agent\fR object is an AE that realizes a UA. The
- attributes in its entry, to the extent that they are present, identify
- the UA's owner; its deliverable content length, content types, and EITs;
- and its O/R
- address.
- .RT
- .LP
- mhs\(hyuser\(hyagent OBJECT\(hyCLASS
- .LP
- SUBCLASS OF applicationEntity
- .LP
- MAY CONTAIN\|{
- .LP
- owner,
- .LP
- mhs\(hydeliverable\(hycontent\(hylength,
- .LP
- mhs\(hydeliverable\(hycontent\(hytypes,
- .LP
- mhs\(hydeliverable\(hyeits,
- .LP
- mhs\(hyor\(hyaddresses\|}
- .LP
- ::= id\(hyoc\(hymhs\(hyuser\(hyagent
- .sp 1P
- .LP
- A.2
- \fIAttributes\fR
- .sp 9p
- .RT
- .PP
- The attributes specific to message handling are those specified
- below.
- .RT
- .sp 1P
- .LP
- A.2.1
- \fIMHS deliverable content length\fR
- .sp 9p
- .RT
- .PP
- The \fBMHS deliverable content length\fR attribute identifies the
- maximum content length of the messages whose delivery a user will accept.
- .PP
- A value of this attribute is an Integer.
- .RT
- .LP
- mhs\(hydeliverable\(hycontent\(hylength ATTRIBUTE
- .LP
- WITH ATTRIBUTE\(hySYNTAX integerSyntax
- .LP
- SINGLE VALUE
- .LP
- ::= id\(hyat\(hymhs\(hydeliverable\(hycontent\(hylength
- .sp 1P
- .LP
- A.2.2
- \fIMHS deliverable content types\fR
- .sp 9p
- .RT
- .PP
- The \fBMHS deliverable content types\fR attribute identifies the
- content types of the messages whose delivery a user will accept.
- .PP
- A value of this attribute is an object identifier.
- .RT
- .LP
- mhs\(hydeliverable\(hycontent\(hytypes ATTRIBUTE
- .LP
- WITH ATTRIBUTE\(hySYNTAX objectIdentifierSyntax
- .LP
- MULTI VALUE
- .LP
- ::= id\(hyat\(hymhs\(hydeliverable\(hycontent\(hytypes
- .bp
- .sp 1P
- .LP
- A.2.3
- \fIMHS deliverable EITs\fR
- .sp 9p
- .RT
- .PP
- The \fBMHS deliverable EITs\fR attribute identifies the EITs of the
- messages whose delivery a user will accept.
- .PP
- A value of this attribute is an object identifier.
- .RT
- .LP
- mhs\(hydeliverable\(hyeits ATTRIBUTE
- .LP
- WITH ATTRIBUTE\(hySYNTAX objectIdentifierSyntax
- .LP
- MULTI VALUE
- .LP
- ::= id\(hyat\(hymhs\(hydeliverable\(hyeits
- .sp 1P
- .LP
- A.2.4
- \fIMHS DL members\fR
- .sp 9p
- .RT
- .PP
- The \fBMHS DL members\fR attribute identifies a DL's members.
- .PP
- A value of this attribute is an O/R name.
- .RT
- .LP
- mhs\(hydl\(hymembers ATTRIBUTE
- .LP
- WITH ATTRIBUTE\(hySYNTAX mhs\(hyor\(hyname\(hysyntax
- .LP
- MULTI VALUE
- .LP
- ::= id\(hyat\(hymhs\(hydl\(hymembers
- .sp 1P
- .LP
- A.2.5
- \fIMHS DL submit permissions\fR
- .sp 9p
- .RT
- .PP
- The \fBMHS DL submit permissions\fR attribute identifies the users and
- DLs that may submit messages to a DL.
- .PP
- A value of this attribute is a DL submit permission.
- .RT
- .LP
- mhs\(hydl\(hysubmit\(hypermissions ATTRIBUTE
- .LP
- WITH ATTRIBUTE\(hySYNTAX mhs\(hydl\(hysubmit\(hypermission\(hysyntax
- .LP
- MULTI VALUE
- .LP
- ::= id\(hyat\(hymhs\(hydl\(hysubmit\(hypermissions
- .sp 1P
- .LP
- A.2.6
- \fIMHS message store\fR
- .sp 9p
- .RT
- .PP
- The \fBMHS message store\fR attribute identifies a user's MS by name.
- .PP
- The value of this attribute is a Directory distinguished name.
- .RT
- .LP
- mhs\(hymessage\(hystore ATTRIBUTE
- .LP
- WITH ATTRIBUTE\(hySYNTAX distinguishedNameSyntax
- .LP
- SINGLE VALUE
- .LP
- ::= id\(hyat\(hymhs\(hymessage\(hystore
- .sp 1P
- .LP
- A.2.7
- \fIMHS O/R addresses\fR
- .sp 9p
- .RT
- .PP
- The \fBMHS O/R addresses\fR attribute specifies a user's or DL's O/R
- addresses.
- .PP
- A value of this attribute is an O/R address.
- .RT
- .LP
- mhs\(hyor\(hyaddresses ATTRIBUTE
- .LP
- WITH ATTRIBUTE\(hySYNTAX mhs\(hyor\(hyaddress\(hysyntax
- .LP
- MULTI VALUE
- .LP
- ::= id\(hyat\(hymhs\(hyor\(hyaddresses
- .sp 1P
- .LP
- A.2.8
- \fIMHS preferred delivery methods\fR
- .sp 9p
- .RT
- .PP
- The \fBMHS preferred delivery methods\fR attribute identifies, in order
- of decreasing preference, the methods of delivery a user prefers.
- .PP
- A value of this attribute is a preferred delivery method.
- .RT
- .LP
- mhs\(hypreferred\(hydelivery\(hymethods ATTRIBUTE
- .LP
- WITH ATTRIBUTE\(hySYNTAX RequestedDeliveryMethod
- .LP
- MATCHES FOR EQUALITY
- .LP
- SINGLE VALUE
- .LP
- ::= id\(hyat\(hymhs\(hypreferred\(hydelivery\(hymethods
- .bp
- .sp 1P
- .LP
- A.2.9
- \fIMHS supported automatic actions\fR
- .sp 9p
- .RT
- .PP
- The \fBMHS supported automatic actions\fR attribute identifies the
- automatic actions that an MS fully supports.
- .PP
- A value of this attribute is an object identifier.
- .RT
- .LP
- mhs\(hysupported\(hyautomatic\(hyactions ATTRIBUTE
- .LP
- WITH ATTRIBUTE\(hySYNTAX objectIdentifierSyntax
- .LP
- MULTI VALUE
- .LP
- ::= id\(hyat\(hymhs\(hysupported\(hyautomatic\(hyactions
- .sp 1P
- .LP
- A.2.10\ \ \fIMHS supported content types\fR
- .sp 9p
- .RT
- .PP
- The \fBMHS supported content types\fR attribute identifies the content
- types of the messages whose syntax and semantics a MS fully supports.
- .PP
- A value of this attribute is an object identifier.
- .RT
- .LP
- mhs\(hysupported\(hycontent\(hytypes ATTRIBUTE
- .LP
- WITH ATTRIBUTE\(hySYNTAX objectIdentifierSyntax
- .LP
- MULTI VALUE
- .LP
- ::= id\(hyat\(hymhs\(hysupported\(hycontent\(hytypes
- .sp 1P
- .LP
- A.2.11\ \ \fIMHS supported optional attributes\fR
- .sp 9p
- .RT
- .PP
- The \fBMHS supported optional attributes\fR attribute identifies the
- optional attributes that an MS fully supports.
- .PP
- A value of this attribute is an Object Identifier.
- .RT
- .LP
- mhs\(hysupported\(hyoptional\(hyattributes ATTRIBUTE
- .LP
- WITH ATTRIBUTE\(hySYNTAX objectIdentifierSyntax
- .LP
- MULTI VALUE
- .LP
- ::= id\(hyat\(hymhs\(hysupported\(hyoptional\(hyattributes
- .sp 1P
- .LP
- A.3
- \fIAttribute syntaxes\fR
- .sp 9p
- .RT
- .PP
- The attribute syntaxes specific to message handling are those
- specified below.
- .RT
- .sp 1P
- .LP
- A.3.1
- \fIMHS DL submit permission\fR
- .sp 9p
- .RT
- .PP
- The \fBMHS DL submit permission\fR attribute syntax characterizes an
- attribute each of whose values is a submit permission.
- .RT
- .LP
- mhs\(hydl\(hysubmit\(hypermission\(hysyntax ATTRIBUTE\(hySYNTAX
- .LP
- SYNTAX DLSubmitPermission
- .LP
- MATCHES FOR EQUALITY
- .LP
- ::= id\(hyas\(hymhs\(hydl\(hysubmit\(hypermission
- .LP
- DLSubmitPermission ::= CHOICE\|{
- .LP
- individual
- [0] ORName,
- .LP
- member\(hyof\(hydl
- [1] ORName,
- .LP
- pattern\(hymatch
- [2] ORNamePattern,
- .LP
- member\(hyof\(hygroup
- [3] Name\|}
- .PP
- A presented DL submit permission value shall be of type
- \fIIndividual\fR .
- .PP
- A DL submit permission, depending upon its type, grants submit access to
- the following zero or more users and DLs:
- .RT
- .LP
- a)
- \fIIndividual\fR \|: The user or (unexpanded) DL any of whose O/R names
- is equal to the specified O/R name.
- .LP
- b)
- \fIMember\(hyof\(hydl\fR \|: Each member of the DL, any of whose O/R
- names is equal to the specified O/R name, or of each nested DL,
- recursively.
- .LP
- c)
- \fIPattern\(hymatch\fR \|: Each user or (unexpanded) DL any of whose
- O/R names matches the specified O/R name pattern.
- .LP
- ORNamePattern ::= ORName
- .bp
- .LP
- d)
- \fIMember\(hyof\(hygroup\fR \|: Each member of the group\(hyof\(hynames whose
- name is specified, or of each nested group\(hyof\(hynames,
- recursively.
- .PP
- A presented value is equal to a target value of this type if the two are
- identical, attribute by attribute. Additionally, equality may be
- declared under other conditions which are a local matter.
- .sp 1P
- .LP
- A.3.2
- \fIMHS O/R address\fR
- .sp 9p
- .RT
- .PP
- The \fBMHS O/R address\fR attribute syntax characterizes an attribute
- each of whose values is an O/R address.
- .RT
- .LP
- mhs\(hyor\(hyaddress\(hysyntax ATTRIBUTE\(hySYNTAX
- .LP
- SYNTAX ORAddress
- .LP
- MATCHES FOR EQUALITY
- .LP
- ::= id\(hyas\(hymhs\(hyor\(hyaddress
- .PP
- A presented O/R address value is equal to a target O/R address value under
- the conditions specified in\ \(sc\ 18.4.
- .sp 1P
- .LP
- A.3.3
- \fIMHS O/R name\fR
- .sp 9p
- .RT
- .PP
- The \fBMHS O/R name\fR attribute syntax characterizes an attribute each
- of whose values is an O/R name.
- .RT
- .LP
- mhs\(hyor\(hyname\(hysyntax ATTRIBUTE\(hySYNTAX
- .LP
- SYNTAX ORName
- .LP
- MATCHES FOR EQUALITY
- .LP
- ::= id\(hyas\(hymhs\(hyor\(hyname
- .PP
- A presented O/R name value is equal to a target O/R name value if
- the two are identical, attribute by attribute. Additionally, equality may be
- declared under other conditions which are a local matter.
- \v'1P'
- .ce 1000
- ANNEX\ B
- .ce 0
- .ce 1000
- (to Recommendation X.402)
- .sp 9p
- .RT
- .ce 0
- .ce 1000
- \fBReference definition of object identifiers\fR
- .sp 1P
- .RT
- .ce 0
- .PP
- This Annex is an integral part of this Recommendation.
- .sp 1P
- .RT
- .PP
- This Annex defines for reference purposes various object
- identifiers cited in the ASN.1 module of Annex\ C. It uses ASN.1.
- .PP
- All object identifiers this Recommendation assigns are assigned in
- this Annex. Annex\ B is definitive for all but those for ASN.1 modules and
- MHS itself. The definitive assignments for the former occur in the modules
- themselves; other references to them appear in IMPORT clauses. The latter is
- fixed.
- .RT
- .sp 1P
- .LP
- MHSObjectIdentifiers {\|joint\(hyiso\(hyccitt
- .sp 9p
- .RT
- .LP
- mhs\(hymotis(6) arch(5) modules(0) object\(hyidentifiers(0)\|}
- .LP
- DEFINITIONS IMPLICIT TAGS ::=
- .LP
- BEGIN
- \(hy\(hy\ \fIPrologue\fR
- .LP
- \(hy\(hy\ \fIExports everything.\fR
- .LP
- IMPORTS\ \(hy\(hy\ \fInothing\fR \ \(hy\(hy\ ;
- .LP
- ID ::= OBJECT IDENTIFIER
- .sp 1P
- .LP
- \(hy\(hy\ \fIAspects MHS\fR
- .sp 9p
- .RT
- .LP
- id\(hymhsac
- ID ::= {\|joint\(hyiso\(hyccitt mhs\(hymotis(6)\ mhsac(0)\|}
- .LP
- \(hy\(hy\ \fIMHS Application Contexts\fR
- .LP
- \(hy\(hy\ \fISee Recommendation X.419\fR .
- .bp
- .LP
- id\(hyipms
- ID ::= {\|joint\(hyiso\(hyccitt mhs\(hymotis(6) ipms(1)\|}
- .LP
- \(hy\(hy\ \fIInterpersonal Messaging\fR
- .LP
- \(hy\(hy\ \fISee Recommendation X.420\fR .
- .LP
- id\(hyasdc
- ID ::= {\|joint\(hyiso\(hyccitt mhs\(hymotis(6) asdc(2)\|}
- .LP
- \(hy\(hy\ \fIAbstract Service Definition Conventions\fR
- .LP
- \(hy\(hy\ \fISee Recommendation X.407\fR .
- .LP
- id\(hymts
- ID ::= {\|joint\(hyiso\(hyccitt mhs\(hymotis(6) mts(3)\|}
- .LP
- \(hy\(hy\ \fIMessage Transfer System\fR
- .LP
- \(hy\(hy\ \fISee Recommendation X.411\fR .
- .LP
- id\(hyms
- ID ::= {\|joint\(hyiso\(hyccitt mhs\(hymotis(6) ms(4)\|}
- .LP
- \(hy\(hy\ \fIMessage Store\fR
- .LP
- \(hy\(hy\ \fISee Recommendation X.413\fR .
- .LP
- id\(hyarch
- ID ::= {\|joint\(hyiso\(hyccitt mhs\(hymotis(6) arch(5)\|}
- .LP
- \(hy\(hy\ \fIOverall Architecture\fR
- .LP
- \(hy\(hy\ \fISee this Recommendation\fR .
- .LP
- id\(hygroup
- ID ::= {\|joint\(hyiso\(hyccitt mhs\(hymotis(6) group(6)\|}
- .LP
- \(hy\(hy\ \fIReserved\fR .
- .sp 1P
- .LP
- \(hy\(hy\ \fICategories\fR
- .sp 9p
- .RT
- .LP
- id\(hymod
- ID ::= {\|id\(hyarch\ 0\|}\ \(hy\(hy\ \fImodules, not definitive\fR
- .LP
- id\(hyoc
- ID ::= {\|id\(hyarch\ 1\|}\ \(hy\(hy\ \fIobject classes\fR
- .LP
- id\(hyat
- ID ::= {\|id\(hyarch\ 2\|}\ \(hy\(hy\ \fIattribute types\fR
- .LP
- id\(hyas
- ID ::= {\|id\(hyarch\ 3\|}\ \(hy\(hy\ \fIattribute syntaxes\fR
- .sp 1P
- .LP
- \(hy\(hy\ \fIModules\fR
- .sp 9p
- .RT
- .LP
- id\(hyobject\(hyidentifiers
- ID ::= {\|id\(hymod\ 0\|}\ \(hy\(hy\ \fInot definitive\fR
- .LP
- id\(hydirectory\(hyobjects\(hyand\(hyattributes;
- ID ::= {\|id\(hymod\ 1\|}
- .LP
- \ \(hy\(hy\ \fInot definitive\fR
- .sp 1P
- .LP
- \(hy\(hy\ \fIObject classes\fR
- .sp 9p
- .RT
- .LP
- id\(hyoc\(hymhs\(hydistribution\(hylist
- ID ::= {\|id\(hyoc\ 0\|}
- .LP
- id\(hyoc\(hymhs\(hymessage\(hystore
- ID ::= {\|id\(hyoc\ 1\|}
- .LP
- id\(hyoc\(hymhs\(hymessage\(hytransfer\(hyagent
- ID ::= {\|id\(hyoc\ 2\|}
- .LP
- id\(hyoc\(hymhs\(hyuser
- ID ::= {\|id\(hyoc\ 3\|}
- .LP
- id\(hyoc\(hymhs\(hyuser\(hyagent
- ID ::= {\|id\(hyoc\ 4\|}
- .sp 1P
- .LP
- \(hy\(hy\ \fIAttributes\fR
- .sp 9p
- .RT
- .LP
- id\(hyat\(hymhs\(hydeliverable\(hycontent\(hylegth
- ID ::= {\|id\(hyat\ 0\|}
- .LP
- id\(hyat\(hymhs\(hydeliverable\(hycontent\(hytypes
- ID ::= {\|id\(hyat\ 1\|}
- .LP
- id\(hyat\(hymhs\(hydeliverable\(hyeits
- ID ::= {\|id\(hyat\ 2\|}
- .LP
- id\(hyat\(hymhs\(hydl\(hymembers
- ID ::= {\|id\(hyat\ 3\|}
- .LP
- id\(hyat\(hymhs\(hydl\(hysubmit\(hypermissions
- ID ::= {\|id\(hyat\ 4\|}
- .LP
- id\(hyat\(hymhs\(hymessage\(hystore
- ID ::= {\|id\(hyat\ 5\|}
- .LP
- id\(hyat\(hymhs\(hyor\(hyaddresses
- ID ::= {\|id\(hyat\ 6\|}
- .LP
- id\(hyat\(hymhs\(hypreferred\(hydelivery\(hymethods
- ID ::= {\|id\(hyat\ 7\|}
- .LP
- id\(hyat\(hymhs\(hysupported\(hyautomatic\(hyactions
- ID ::= {\|id\(hyat\ 8\|}
- .LP
- id\(hyat\(hymhs\(hysupported\(hycontent\(hytypes
- ID ::= {\|id\(hyat\ 9\|}
- .LP
- id\(hyat\(hymhs\(hysupported\(hyoptional\(hyattributes
- ID ::= {\|id\(hyat\ 10\|}
- .sp 1P
- .LP
- \(hy\(hy\ \fIAttribute syntaxes\fR
- .sp 9p
- .RT
- .LP
- id\(hyas\(hymhs\(hydl\(hysubmit\(hypermission
- ID\ ::= {\|id\(hyas\ 0\|}
- .LP
- id\(hyas\(hymhs\(hyor\(hyaddress
- ID\ ::=\|{\|id\(hyas\ 1\|}
- .LP
- id\(hyas\(hymhs\(hyor\(hyname
- ID\ ::=\|{\|id\(hyas\ 2\|}
- .LP
- END\ \(hy\(hy\ \fIof MHSObjectIdentifiers\fR .bp
- .ce 1000
- ANNEX\ C
- .ce 0
- .ce 1000
- (to Recommendation X.402)
- .sp 9p
- .RT
- .ce 0
- .ce 1000
- \fBReference definition of directory object
- classes and attributes\fR
- .sp 1P
- .RT
- .ce 0
- .PP
- This Annex is an integral part of this Recommendation.
- .sp 1P
- .RT
- .PP
- This Annex, a supplement to Annex A, defines for
- reference purposes the object classes, attributes, and attribute syntaxes
- specific to Message Handling. It uses the OBJECT\(hyCLASS, ATTRIBUTE, and
- ATTRIBUTE\(hySYNTAX macros of Recommendation\ X.501.
- .sp 1P
- .LP
- MHSDirectoryObjectsAndAttributes\|{\|joint\(hyiso\(hyccitt
- .sp 9p
- .RT
- .LP
- mhs\(hymotis(6) arch(5) modules(0) directory(1)\|}
- .LP
-
- DEFINITIONS IMPLICIT TAGS ::=
- .LP
- BEGIN
- \(hy\(hy\ \fIPrologue\fR
- .LP
- \(hy\(hy\ \fIExports everything\fR .
- .sp 1P
- .LP
- IMPORTS
- .sp 9p
- .RT
- .LP
- \(hy\(hy\ \fIMHS object identifiers\fR
- .LP
- id\(hyas\(hymhs\(hydl\(hysubmit\(hypermission, id\(hyas\(hymhs\(hyor\(hyaddress,
- .LP
- id\(hyas\(hymhs\(hyor\(hyname\(hy, id\(hyat\(hymhs\(hydeliverable\(hycontent\(hylength,
- .LP
- id\(hyat\(hymhs\(hydeliverable\(hycontent\(hytypes,
- .LP
- id\(hyat\(hymhs\(hydeliverable\(hyeits, id\(hyat\(hymhs\(hydl\(hymembers,
- .LP
- id\(hyat\(hymhs\(hydl\(hysubmit\(hypermissions, id\(hyat\(hymhs\(hymessage\(hystore,
- .LP
- id\(hyat\(hymhs\(hyor\(hyaddresses, id\(hyat\(hymhs\(hypreferred\(hydelivery\(hymethods,
- .LP
- id\(hyat\(hymhs\(hysupported\(hyautomatic\(hyactions,
- .LP
- id\(hyat\(hymhs\(hysupported\(hycontent\(hytypes,
- .LP
- id\(hyat\(hymhs\(hysupported\(hyoptional\(hyattributes,
- .LP
- id\(hyoc\(hymhs\(hydistribution\(hylist, id\(hyoc\(hymhs\(hymessage\(hystore,
- .LP
- id\(hyoc\(hymhs\(hymessage\(hytransfer\(hyagent,
- .LP
- id\(hyoc\(hymhs\(hyuser,
- .LP
- id\(hyoc\(hymhs\(hyuser\(hyagent
- .LP
- \(hy\(hy\(hy\(hy
- .LP
- FROM MHSObjectIdentifiers\|{\|joint\(hyiso\(hyccitt
- .LP
- mhs\(hymotis(6) arch(5) modules(0) object\(hyidentifiers(0)\|}
- .LP
- \(hy\(hy\ \fIMTS Abstract service\fR
- .LP
- ORAddress, ORName, RequestedDeliveryMethod
- .LP
- \(hy\(hy\(hy\(hy
- .LP
- FROM MTSAbstractService\|{\|joint\(hyiso\(hyccitt
- .LP
- mhs\(hymotis(6) mts(3) modules(0) MTS\(hyabstract\(hyservice(3)\|}
- .LP
- \(hy\(hy\ \fIInformation framework\fR
- .LP
- ATTRIBUTE, ATTRIBUTE\(hySYNTAX, Name, OBJECT\(hyCLASS
- .LP
- \(hy\(hy\(hy\(hy
- .LP
- FROM informationFramework\|{\|joint\(hyiso\(hyccitt
- .LP
- ds(5) modules(1) informationFramework(1)\|}
- .LP
- \(hy\(hy\ \fISelected object classes\fR
- .LP
- applicationEntity
- .LP
- top
- .LP
- \(hy\(hy\(hy\(hy
- .LP
- FROM SelectedObjectClasses\|{\|joint\(hyiso\(hyccitt
- .LP
- ds(5) modules(1) selectedObjectClasses(6)\|}
- .LP
- \(hy\(hy\ \fISelected attribute types\fR
- .LP
- commonName, description, distinguishedNameSyntax,
- .LP
- integerSyntax, objectidentifierSyntax, organization,
- .LP
- organizationalUnitName, owner, seeAlso
- .LP
- \(hy\(hy\(hy\(hy
- .LP
- FROM SelectedAttributeTypes\|{\|joint\(hyiso\(hyccitt
- .LP
- ds(5) modules(1) selectedAttributeTypes(5)\|}
- .bp
- .sp 1P
- .LP
- \(hy\(hy\ \fIOBJECT CLASSES\fR
- .sp 9p
- .RT
- .LP
- \(hy\(hy\ \fIMHS distribution list\fR
- .LP
- mhs\(hydistribution\(hylist OBJECT\(hyCLASS
- .LP
- SUBCLASS OF top
- .LP
- MUST CONTAIN {
- .LP
- commonName,
- .LP
- mhs\(hydl\(hysubmit\(hypermissions,
- .LP
- mhs\(hyor\(hyaddresses\|}
- .LP
- MAY CONTAIN\|{
- .LP
- description,
- .LP
- organization,
- .LP
- organizationalUnitName,
- .LP
- owner,
- .LP
- seeAlso,
- .LP
- mhs\(hydeliverable\(hycontent\(hytypes,
- .LP
- mhs\(hydeliverable\(hyeits,
- .LP
- mhs\(hydl\(hymembers,
- .LP
- mhs\(hypreferred\(hydelivery\(hymethods\|}
- .LP
- :: id\(hyoc\(hymhs\(hydistribution\(hylist
- .LP
- \(hy\(hy\ \fIMHS message store\fR
- .LP
- mhs\(hymessage\(hystore OBJECT\(hyCLASS
- .LP
- SUBCLASS OF applicationEntity
- .LP
- MAY CONTAIN\|{
- .LP
- description,
- .LP
- owner,
- .LP
- mhs\(hysupported\(hyoptional\(hyattributes,
- .LP
- mhs\(hysupported\(hyautomatic\(hyactions,
- .LP
- mhs\(hysupported\(hycontent\(hytypes\|}
- .LP
- ::= id\(hyoc\(hymhs\(hymessage\(hystore
- .LP
- \(hy\(hy\ \fIMHS message transfer agent\fR
- .LP
- mhs\(hymessage\(hytransfer\(hyagent OBJECT\(hyCLASS
- .LP
- SUBCLASS OF applicationEntity
- .LP
- MAY CONTAIN\|{
- .LP
- description,
- .LP
- owner,
- .LP
- mhs\(hydeliverable\(hycontent\(hylength\|}
- .LP
- ::= id\(hyoc\(hymhs\(hymessage\(hytransfer\(hyagent
- .LP
- \(hy\(hy\ \fIMHS user\fR
- .LP
- mhs\(hyuser OBJECT\(hyCLASS
- .LP
- SUBCLASS OF top
- .LP
- MUST CONTAIN\|{
- .LP
- mhs\(hyor\(hyaddresses\|}
- .LP
- MAY CONTAIN\|{
- .LP
- mhs\(hydeliverable\(hycontent\(hylength,
- .LP
- mhs\(hydeliverable\(hycontent\(hytypes,
- .LP
- mhs\(hydeliverable\(hyeits,
- .LP
- mhs\(hymessage\(hystore,
- .LP
- mhs\(hypreferred\(hydelivery\(hymethods\|}
- .LP
- ::= id\(hyoc\(hymhs\(hyuser
- .LP
- \(hy\(hy\ \fIMHS user agent\fR
- .LP
- mhs\(hyuser\(hyagent OBJECT\(hyCLASS
- .LP
- SUBCLASS OF applicationEntity
- .LP
- MAY CONTAIN\|{
- .LP
- owner,
- .LP
- mhs\(hydeliverable\(hycontent\(hylength,
- .LP
- mhs\(hydeliverable\(hycontent\(hytypes,
- .LP
- mhs\(hydeliverable\(hyeits,
- .LP
- mhs\(hyor\(hyaddresses\|}
- .LP
- ::= id\(hyoc\(hymhs\(hyuser\(hyagent
- .bp
- .sp 1P
- .LP
- \(hy\(hy\ \fIATTRIBUTES\fR
- .sp 9p
- .RT
- .LP
- \(hy\(hy\ \fIMHS deliverable content length\fR
- .LP
- mhs\(hydeliverable\(hycontent\(hylength ATTRIBUTE
- .LP
- WITH ATTRIBUTE\(hySYNTAX integerSyntax
- .LP
- SINGLE VALUE
- .LP
- ::= id\(hyat\(hymhs\(hydeliverable\(hycontent\(hylength
- .LP
- \(hy\(hy\ \fIMHS deliverable content types\fR
- .LP
- mhs\(hydeliverable\(hycontent\(hytypes ATTRIBUTE
- .LP
- WITH ATTRIBUTE\(hySYNTAX objectIdentifierSyntax
- .LP
- MULTI VALUE
- .LP
- ::= id\(hyat\(hymhs\(hydeliverable\(hycontent\(hytypes
- .LP
- \(hy\(hy\ \fIMHS deliverable EITs\fR
- .LP
- mhs\(hydeliverable\(hyeits ATTRIBUTE
- .LP
- WITH ATTRIBUTE\(hySYNTAX objectIdentifierSyntax
- .LP
- MULTI VALUE
- .LP
- ::= id\(hyat\(hymhs\(hydeliverable\(hyeits
- .LP
- \(hy\(hy\ \fIMHS DL members\fR
- .LP
- mhs\(hydl\(hymembers ATTRIBUTE
- .LP
- WITH ATTRIBUTE\(hySYNTAX mhs\(hyor\(hyname\(hysyntax
- .LP
- MULTI VALUE
- .LP
- ::= id\(hyat\(hymhs\(hydl\(hymembers
- .LP
- \(hy\(hy\ \fIMHS DL submit permissions\fR
- .LP
- mhs\(hydl\(hysubmit\(hypermissions ATTRIBUTE
- .LP
- WITH ATTRIBUTE\(hySYNTAX mhs\(hydl\(hysubmit\(hypermission\(hysyntax
- .LP
- MULTI VALUE
- .LP
- ::= id\(hyat\(hymhs\(hydl\(hysubmit\(hypermissions
- .LP
- \(hy\(hy\ \fIMHS O/R adresses\fR
- .LP
- mhs\(hyor\(hyaddresses ATTRIBUTE
- .LP
- WITH ATTRIBUTE\(hySYNTAX mhs\(hyor\(hyaddress\(hysyntax
- .LP
- MULTI VALUE
- .LP
- ::= id\(hyat\(hymhs\(hyor\(hyaddresses
- .LP
- \(hy\(hy\ \fIMHS message store\fR
- .LP
- mhs\(hymessage\(hystore ATTRIBUTE
- .LP
- WITH ATTRIBUTE\(hySYNTAX distinguishedNameSyntax
- .LP
- SINGLE VALUE
- .LP
- ::= id\(hyat\(hymhs\(hymessage\(hystore
- .LP
- \(hy\(hy\ \fIMHS preferred delivery methods\fR
- .LP
- mhs\(hypreferred\(hydelivery\(hymethods ATTRIBUTE
- .LP
- WITH ATTRIBUTE\(hySYNTAX RequestedDeliveryMethod
- .LP
- MATCHES FOR EQUALITY
- .LP
- SINGLE VALUE
- .LP
- ::= id\(hyat\(hymhs\(hypreferred\(hydelivery\(hymethods
- .LP
- \(hy\(hy\ \fIMHS supported automatic actions\fR
- .LP
- mhs\(hysupported\(hyautomatic\(hyactions ATTRIBUTE
- .LP
- WITH ATTRIBUTE\(hySYNTAX objectIdentifierSyntax
- .LP
- MULTI VALUE
- .LP
- ::= id\(hyat\(hymhs\(hysupported\(hyautomatic\(hyactions
- .LP
- \(hy\(hy\ \fIMHS supported content types\fR
- .LP
- mhs\(hysuppported\(hycontent\(hytypes ATTRIBUTE
- .LP
- WITH ATTRIBUTE\(hySYNTAX objectIdentifierSyntax
- .LP
- MULTI VALUE
- .LP
- ::= id\(hyat\(hymhs\(hysupported\(hycontent\(hytypes
- .LP
- \(hy\(hy\ \fIMHS supported optional attributes\fR
- .LP
- mhs\(hysupported\(hyoptional\(hyattributes ATTRIBUTE
- .LP
- WITH ATTRIBUTE\(hySYNTAX objectIdentifierSyntax
- .LP
- MULTI VALUE
- .LP
- ::= id\(hyat\(hymhs\(hysupported\(hyoptional\(hyattributes
- .bp
- .sp 1P
- .LP
- \(hy\(hy\ \fIATTRIBUTE SYNTAXES\fR
- .sp 9p
- .RT
- .LP
- \(hy\(hy\ \fIMHS DL submit permission\fR
- .LP
- mhs\(hydl\(hysubmit\(hypermission\(hysyntax ATTRIBUTE\(hySYNTAX
- .LP
- SYNTAX DLSubmitPermission
- .LP
- MATCHES FOR EQUALITY
- .LP
- ::= id\(hyas\(hymhs\(hydl\(hysubmit\(hypermission
- DLSubmitPermission ::= CHOICE\|{
- .LP
- individual
- [0]\ ORName,
- .LP
- member\(hyof\(hydl
- [1]\ ORName,
- .LP
- pattern\(hymatch
- [2]\ ORNamePattern,
- .LP
- member\(hyof\(hygroup
- [3]\ Name\|}
- ORNamePattern ::= ORName
- .LP
- \(hy\(hy\ \fIMHS O/R addresses\fR
- .LP
- mhs\(hyor\(hyaddress\(hysyntax ATTRIBUTE\(hySYNTAX
- .LP
- SYNTAX ORAddress
- .LP
- MATCHES FOR EQUALITY
- .LP
- ::= id\(hyas\(hymhs\(hyor\(hyaddress
- .LP
- \(hy\(hy\ \fIMHS O/R name\fR
- .LP
- mhs\(hyor\(hyname\(hysyntax ATTRIBUTE\(hySYNTAX
- .LP
- SYNTAX ORName
- .LP
- MATCHES FOR EQUALITY
- .LP
- ::= id\(hyas\(hymhs\(hyor\(hyname
- .LP
- END\ \(hy\(hy\ \fIof MHSdirectory\fR \v'1P'
- .ce 1000
- ANNEX\ D
- .ce 0
- .ce 1000
- \fBSecurity threats\fR
- .sp 1P
- .RT
- .ce 0
- .PP
- This Annex is not a part of this Recommendation.
- .sp 1P
- .RT
- .PP
- An overview of MHS security threats is provided in \(sc\ 15.1 of
- Recommendation\ X.400. This considers threats as they appear in an MHS
- access threats, inter\(hymessage threats, and message store threats. These
- threats can appear in various forms as follows:
- .LP
- a)
- masquerade;
- .LP
- b)
- message sequencing;
- .LP
- c)
- modification of information;
- .LP
- d)
- denial of service;
- .LP
- e)
- leakage of information;
- .LP
- f
- )
- repudiation;
- .LP
- g)
- other MHS threats.
- .PP
- In addition, they may occur by accident or by malicious intent and may
- be active or passive. Attacks on the MHS will address potential
- weaknesses and may comprise of a number of threats. This Annex deals with
- individual threats and although consideration is given to a number of broad
- classes of threat, it is not a complete list.
- .PP
- Table D\(hy1/X.402 indicates how these threats can be met using the MHS
- security services. The list of threats given here is indicative rather
- than
- definitive.
- .bp
- .RT
- .ce
- \fBH.T. [T13.402]\fR
- .ce
- TABLE\ D\(hy1/X.402
- .ce
- \fBUse of MHS security services\fR
- .ps 9
- .vs 11
- .nr VS 11
- .nr PS 9
- .TS
- center box;
- cw(96p) | cw(96p) .
- Threat Services
- _
- .T&
- lw(96p) | lw(96p) .
- \fIMasquerade\fR
- .T&
- lw(96p) | lw(96p) .
- T{
- Impersonation and misuse of the MTS
- T} T{
- Message origin authentication
- Probe origin authentication
- Secure access management
- T}
- .T&
- lw(96p) | lw(96p) .
- Falsely acknowledge receipt Proof of delivery
- .T&
- lw(96p) | lw(96p) .
- T{
- Falsely claim to originate a message
- T} Message origin authentication
- .T&
- lw(96p) | lw(96p) .
- T{
- Impersonation of an MTA to an MTS\(hyuser
- T} T{
- Proof of submission
- Report origin authentication
- Secure access management
- T}
- .T&
- lw(96p) | lw(96p) .
- T{
- Impersonation of an MTA to another MTA
- T} T{
- Report origin authentication
- Secure access management
- T}
- _
- .T&
- lw(96p) | lw(96p) .
- \fIMessage sequencing\fR
- .T&
- lw(96p) | lw(96p) .
- Replay of messages Message sequence integrity
- .T&
- lw(96p) | lw(96p) .
- Re\(hyordering of messages Message sequence integrity
- .T&
- lw(96p) | lw(96p) .
- Pre\(hyplay of messages
- .T&
- lw(96p) | lw(96p) .
- Delay of messages
- _
- .T&
- lw(96p) | lw(96p) .
- T{
- \fIModification of information\fR
- T}
- .T&
- lw(96p) | lw(96p) .
- Modification of messages T{
- Connection integrity
- Content integrity
- T}
- .T&
- lw(96p) | lw(96p) .
- Destruction of messages Message sequence integrity
- .T&
- lw(96p) | lw(96p) .
- T{
- Corruption of routing and other management information
- T}
- _
- .T&
- lw(96p) | lw(96p) .
- \fIDenial of service\fR
- .T&
- lw(96p) | lw(96p) .
- Denial of communications
- .T&
- lw(96p) | lw(96p) .
- MTA flooding
- .T&
- lw(96p) | lw(96p) .
- MTS flooding
- _
- .T&
- lw(96p) | lw(96p) .
- \fIRepudiation\fR
- .T&
- lw(96p) | lw(96p) .
- Denial of origin Non\(hyrepudiation of origin
- .T&
- lw(96p) | lw(96p) .
- Denial of submission T{
- Non\(hyrepudiation of submission
- T}
- .T&
- lw(96p) | lw(96p) .
- Denial of delivery T{
- Non\(hyrepudiation of delivery
- T}
- _
- .T&
- lw(96p) | lw(96p) .
- T{
- \fILeakage of information\fR
- T}
- .T&
- lw(96p) | lw(96p) .
- Loss of confidentiality T{
- Connection confidentiality
- Content confidentiality
- T}
- .T&
- lw(96p) | lw(96p) .
- Loss of anonymity Message flow confidentiality
- .T&
- lw(96p) | lw(96p) .
- Misappropriation of messages Secure access management
- .T&
- lw(96p) | lw(96p) .
- Traffic analysis Message flow confidentiality
- _
- .T&
- lw(96p) | lw(96p) .
- \fIOther threats\fR
- .T&
- lw(96p) | lw(96p) .
- T{
- Originator not cleared for message security label
- T} T{
- Secure access management
- Message security labelling
- T}
- .T&
- lw(96p) | lw(96p) .
- T{
- MTA/MTS\(hyuser not cleared for security context
- T} Secure access management
- .T&
- lw(96p) | lw(96p) .
- Misrouting T{
- Secure access management
- Message security labelling
- T}
- .T&
- lw(96p) | lw(96p) .
- Differing labelling policies
- _
- .TE
- .nr PS 9
- .RT
- .ad r
- \fBTable D\(hy1/X.402 [T13.402], p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .sp 1P
- .LP
- D.1
- \fIMasquerade\fR
- .sp 9p
- .RT
- .PP
- Masquerade occurs when an entity successfully pretends to be a
- different entity and can take place in a number of ways. An unauthorized
- MTS\(hyuser may impersonate another to gain unauthorized access to MTS
- facilities or to act to the detriment of the valid user, e.g.,\ to discard
- his messages. An MTS\(hyuser may impersonate another user and so falsely
- acknowledge receipt of a message by the \*Qvalid\*U recipient. A message
- may be put into the MTS by a user falsely claiming the identity of another
- user. An MTS\(hyuser, MS, or MTA may
- masquerade as another MTS user, MS, or MTA.
- .PP
- Masquerade threats include the following:
- .RT
- .LP
- a)
- impersonation and misuse of the MTS;
- .LP
- b)
- falsely acknowledge receipt;
- .LP
- c)
- falsely claim to originate a message;
- .LP
- d)
- impersonation of an MTA to an MTS\(hyuser;
- .LP
- e)
- impersonation of an MTA to another MTA.
- .PP
- A masquerade usually consists of other forms of attack and in a
- secure system may involve authentication sequences from valid users, e.g.,\
- in replay or modification of messages.
- .sp 1P
- .LP
- D.2
- \fIMessage sequencing\fR
- .sp 9p
- .RT
- .PP
- Message sequencing threats occur when part or all of a message is repeated,
- time\(hyshifted, or reordered. This can be used to exploit the
- authentication information in a valid message and resequence or time\(hyshift
- valid messages. Although it is impossible to prevent replay with the MHS
- security services, it can be detected and the effects of the threat
- eliminated.
- .PP
- Message sequencing threats include the following:
- .RT
- .LP
- a)
- replay of messages;
- .LP
- b)
- reordering of messages;
- .LP
- c)
- pre\(hyplay of messages;
- .LP
- d)
- delay of messages.
- .sp 1P
- .LP
- D.3
- \fIModification of information\fR
- .sp 9p
- .RT
- .PP
- Information for an intended recipient, routing information, and
- other management data may be lost or modified without detection. This could
- occur to any aspect of the message, e.g.,\ its labelling, content, attributes,
- recipient, or originator. Corruption of routing or other management
- information, stored in MTAs or used by them, may cause the MTS to lose
- messages or otherwise operate incorrectly.
- .PP
- Modification of information threats include the following:
- .RT
- .LP
- a)
- modification of messages;
- .LP
- b)
- destruction of messages;
- .LP
- c)
- corruption of routing and other management
- information.
- .sp 1P
- .LP
- D.4
- \fIDenial of service\fR
- .sp 9p
- .RT
- .PP
- Denial of service occurs when an entity fails to perform its
- function or prevents other entities from performing their functions. This
- may be a denial of access, a denial of communications (leading to other
- problems
- like overload), a deliberate suppression of messages to a particular recipient,
- or a fabrication of extra traffic. The MTS can be denied if an MTA has
- been
- caused to fail or operate incorrectly. In addition, an MTS\(hyuser may
- cause the MTS to deny a service to other users by flooding the service
- with messages
- which might overload the switching capability of an MTA or fill up all
- available message storage space.
- .PP
- Denial of service threats include the following:
- .RT
- .LP
- a)
- denial of communications;
- .LP
- b)
- MTA failure;
- .LP
- c)
- MTS flooding.
- .bp
- .sp 1P
- .LP
- D.5
- \fIRepudiation\fR
- .sp 9p
- .RT
- .PP
- Repudiation can occur when an MTS\(hyuser or the MTS may later deny
- submitting, receiving, or originating a message.
- .PP
- Repudiation threats include the following:
- .RT
- .LP
- a)
- denial of origin;
- .LP
- b)
- denial of submission;
- .LP
- c)
- denial of delivery.
- .sp 1P
- .LP
- D.6
- \fILeakage of information\fR
- .sp 9p
- .RT
- .PP
- Information may be acquired by an unauthorized party by monitoring transmissions,
- by unauthorized access to information stored in any MHS entity, or by masquerade.
- In some cases, the presence of an MTS\(hyuser on the system may be sensitive
- and its anonymity may have to be preserved. An MTS\(hyuser other than the
- intended recipient may obtain a message. This might result from
- impersonation and misuse of the MTS or through causing an MTA to operate
- incorrectly. Further details on the information flowing in an MTS may be
- obtained from observing the traffic.
- .PP
- Leakage of information threats include the following:
- .RT
- .LP
- a)
- loss of confidentiality;
- .LP
- b)
- loss of anonymity;
- .LP
- c)
- misappropriation of messages;
- .LP
- d)
- traffic analysis.
- .sp 1P
- .LP
- D.7
- \fIOther threats\fR
- .sp 9p
- .RT
- .PP
- In a multi\(hy or single\(hylevel secure system, a number of threats may
- exist that relate to security labelling, e.g.,\ routing through a node that
- cannot be trusted with information of particular value, or where systems use
- different labelling policies. Threats may exist to the enforcement of a
- security policy based on logical separation using security labels. An MTS\(hyuser
- may originate a message and assign it a label for which it is not cleared.
- An MTS\(hyuser or MTA may set up or accept an association with a security
- context for which it does not have clearance.
- .PP
- Other threats include the following:
- .RT
- .LP
- a)
- originator not cleared for message label (inappropriate
- submit);
- .LP
- b)
- MTA/MTS\(hyuser not cleared for context;
- .LP
- c)
- misrouting;
- .LP
- d)
- differing labelling policies.
- \v'1P'
- .ce 1000
- ANNEX\ E
- .ce 0
- .ce 1000
- (to Recommendation X.402)
- .sp 9p
- .RT
- .ce 0
- .ce 1000
- \fBProvision of security services\fR \fBin Recommendation X.411\fR
- .sp 1P
- .RT
- .ce 0
- .PP
- This Annex is an integral part of this Recommendation.
- .sp 1P
- .RT
- .PP
- Table E\(hy1/X.402 indicates which service elements from
- Recommendation X.411 may be used to support the security services described
- in \(sc\ 10.2.
- .LP
- .rs
- .sp 5P
- .ad r
- Blanc
- .ad b
- .RT
- .LP
- .bp
- .ce
- \fBH.T. [T14.402]\fR
- .ce
- TABLE\ E\(hy1/X.402
- .ce
- \fBMHS security service provision\fR
- .ps 9
- .vs 11
- .nr VS 11
- .nr PS 9
- .TS
- center box;
- cw(102p) | cw(102p) .
- Service MIS Arguments/services
- _
- .T&
- lw(102p) | lw(102p) .
- T{
- \fIOrigin authentication security services\fR
- T}
- .T&
- lw(102p) | lw(102p) .
- Message origin authentication T{
- Message origin authentication check
- Message token
- T}
- .T&
- lw(102p) | lw(102p) .
- Probe origin authentication T{
- Probe origin authentication check
- T}
- .T&
- lw(102p) | lw(102p) .
- Report origin authentication T{
- Report origin authentication check
- T}
- .T&
- lw(102p) | lw(102p) .
- Proof of submission T{
- Proof of submission request
- Proof of submission
- T}
- .T&
- lw(102p) | lw(102p) .
- Proof of delivery T{
- Proof of delivery request
- Proof of delivery
- T}
- _
- .T&
- lw(102p) | lw(102p) .
- T{
- \fISecure access management security services\fR
- T}
- .T&
- lw(102p) | lw(102p) .
- Peer entity authentication T{
- Initiator credentials
- Responder credentials
- T}
- .T&
- lw(102p) | lw(102p) .
- Security context Security context
- _
- .T&
- lw(102p) | lw(102p) .
- T{
- \fIData confidentiality security services\fR
- T}
- .T&
- lw(102p) | lw(102p) .
- Connection confidentiality Not supported
- .T&
- lw(102p) | lw(102p) .
- Content confidentiality T{
- Content confidentiality algorithm identifier
- Message token
- T}
- .T&
- lw(102p) | lw(102p) .
- Message flow confidentiality Content type
- _
- .T&
- lw(102p) | lw(102p) .
- T{
- \fIData integrity security services\fR
- T}
- .T&
- lw(102p) | lw(102p) .
- Connection integrity Not supported
- .T&
- lw(102p) | lw(102p) .
- Content integrity T{
- Content integrity check
- Message token
- Message origin authentication check
- T}
- .T&
- lw(102p) | lw(102p) .
- Message sequence integrity T{
- Message sequence number
- Message token
- T}
- _
- .T&
- lw(102p) | lw(102p) .
- T{
- \fINon\(hyrepudiation security services\fR
- T}
- .T&
- lw(102p) | lw(102p) .
- Non\(hyrepudiation of origin T{
- Content integrity check
- Message token
- Message origin authentication check
- T}
- .T&
- lw(102p) | lw(102p) .
- T{
- Non\(hyrepudiation of submission
- T} T{
- Proof of submission request
- Proof of submission
- T}
- .T&
- lw(102p) | lw(102p) .
- T{
- Non\(hyrepudiation of delivery
- T} T{
- Proof of delivery request
- Proof of delivery
- T}
- _
- .T&
- lw(102p) | lw(102p) .
- Message security labelling T{
- Message security label
- Message token
- Message origin authentication check
- T}
- _
- .T&
- lw(102p) | lw(102p) .
- T{
- \fISecurity management security services\fR
- T}
- .T&
- lw(102p) | lw(102p) .
- Change credentials Change credentials
- .T&
- lw(102p) | lw(102p) .
- Register Register
- _
- .TE
- .nr PS 9
- .RT
- .ad r
- \fBTableau E\(hy1/X.402, [T14.402] p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .ce 1000
- ANNEX\ F
- .ce 0
- .ce 1000
- \fBDifferences between CCITT Recommendation and ISO Standard\fR
- .sp 1P
- .RT
- .ce 0
- .PP
- This Annex is not a part of this Recommendation.
- .sp 1P
- .RT
- .PP
- This Annex lists all but the purely stylistic differences between this
- Recommendation and the corresponding ISO International Standard.
- .PP
- The following are the differences that exist:
- .RT
- .LP
- a)
- The ISO International Standard corresponding to this
- Recommendation depicts direct connection of two PRMDs in the
- same country, direct connection of two PRMDs in different
- countries, and a single PRMD connected to two ADMDs, while this
- Recommendation does not. (See Figure\ 11/X.402.)
- .LP
- b)
- The ISO International Standard corresponding to this
- Recommendation does not require that ADMDs and PRMDs be
- hierarchically related for purposes of addressing and routing,
- while this Recommendation does. (See \(sc\(sc\ 14.1.1., 14.1.2, 15
- and\ 19.)
- .LP
- c)
- Where an O/R address attribute admits both printable and
- teletex strings, the ISO International Standard corresponding to
- this Recommendation does not require that the printable string
- be supplies as a minimum whenever attributes are conveyed
- internationally, while this Recommendation does. (See
- \(sc\ 18.2.)
- \v'1P'
- .ce 1000
- ANNEX\ G
- .ce 0
- .ce 1000
- \fBIndex\fR
- .sp 1P
- .RT
- .ce 0
- .PP
- This Annex is not a part of this Recommendation.
- .sp 1P
- .RT
- .PP
- This Annex indexes this Recommendation. It gives the number(s) of the section(s)
- on which each item in each of several categories is defined. Its coverage
- of each category is exhaustive.
- .PP
- This Annex indexes items (if any) in the following
- categories:
- .RT
- .LP
- a)
- abbreviations;
- .LP
- b)
- terms;
- .LP
- c)
- information items;
- .LP
- d)
- ASN.1 modules;
- .LP
- e)
- ASN.1 macros;
- .LP
- f
- )
- ASN.1 types;
- .LP
- g)
- ASN.1 values;
- .LP
- h)
- \fIbilateral agreements\fR ;
- .LP
- i)
- items \fBfor further study\fR ;
- .LP
- j
- )
- items \fBto be supplied (fs)\fR .
- .bp
- .sp 1P
- .LP
- G.1
- \fIAbbreviations\fR
- .sp 9p
- .RT
- .LP
- .sp 1
- A/SYS\
- 13.1.1
- .LP
- AC\
- 3.1
- .LP
- ACs\
- 27
- .LP
- ACSE\
- 3.1, 26.4.3
- .LP
- ADMD\
- 14.1.1
- .LP
- AE\
- 3.1
- .LP
- APDU\
- 3.1
- .LP
- AS/SYS\
- 13.1.3
- .LP
- ASE\
- 3.1
- .LP
- ASEs\
- 26
- .LP
- ASN.1\
- 3.1
- .LP
- AST/SYS\
- 13.1.7
- .LP
- AT/SYS\
- 13.1.5
- .LP
- AU\
- 7.2.4
- .LP
- C\
- 5.2
- .LP
- COMPUSEC\
- 10
- .LP
- D\
- 5.2
- .LP
- DL\
- 7.1.3
- .LP
- DSA\
- 3.2
- .LP
- EIT\
- 8.1
- .LP
- M\
- 5.2
- .LP
- MASE\
- 26.3.5
- .LP
- MD\
- 14.1
- .LP
- MDSE\
- 26.3.3
- .LP
- MHE\
- 7
- .LP
- MHS\ 7.1.1
- .LP
- MRSE\
- 26.3.4
- .LP
- MS\
- 7.2.3
- .LP
- MSSE\
- 26.3.2
- .LP
- MTA\
- 7.3.1
- .LP
- MTS\
- 7.2.1
- .LP
- MTSE\
- 26.3.1
- .LP
- O\
- 5.2
- .LP
- OSI\
- 3.1
- .LP
- P1\
- 27
- .LP
- P3\
- 27
- .LP
- P7\
- 27
- .LP
- PDAU\ 7.4.1
- .LP
- PDS\
- 7.4.1
- .LP
- PRMD\
- 14.1.2
- .LP
- RO\
- 3.1
- .LP
- ROSE\
- 3.1, 26.4.1
- .LP
- RT\
- 3.1
- .LP
- RTSE\
- 3.1, 26.4.2
- .LP
- S/SYS\
- 13.1.2
- .LP
- ST/SYS\
- 13.1.6
- .LP
- T/SYS\
- 13.1.4
- .LP
- UA\
- 7.2.2
- .LP
- UE\
- 3.1
- .sp 1P
- .LP
- .sp 2
- G.2
- \fITerms\fR
- .sp 9p
- .RT
- .LP
- .sp 1
- access and storage system\
- 13.1.3
- .LP
- access and transfer system\
- 13.1.5
- .LP
- access, storage and transfer system\
- 13.1.7
- .LP
- access system\
- 13.1.1
- .LP
- access unit\
- 7.2.4
- .LP
- actual recipient\
- 9.2
- .LP
- administration\(hydomain\(hyname\
- 18.3.1
- .LP
- administration management domain\
- 14.1.1
- .LP
- affirmation\
- 9.4.9
- .LP
- asymetric\
- 26.2
- .LP
- attribute\
- 18.1
- .LP
- attribute list\
- 18.1
- .LP
- attribute type\
- 18.1
- .LP
- attribute value\
- 18.1
- .LP
- common\(hyname\
- 18.3.2
- .LP
- conditional\
- 5.2
- .LP
- consuming ASE\
- 26.2
- .LP
- consuming UE\
- 26.2
- .LP
- content\
- 8.1
- .LP
- content type\
- 8.1
- .LP
- conversion\
- 9.4.6
- .LP
- country\(hyname\
- 18.3.3
- .LP
- defaultable\
- 5.2
- .LP
- delivery\
- 9.3.6
- .LP
- delivery agent\
- 9.3.6
- .LP
- delivery report\
- 8.3
- .LP
- described message\
- 8.2
- .LP
- direct submission\
- 9.3.2
- .LP
- direct user\
- 7.1.2
- .LP
- distribution list\
- 7.1.3
- .LP
- DL expansion\
- 9.4.4
- .LP
- domain\
- 14.1
- .LP
- domain\(hydefined attribute\
- 18.1
- .LP
- encoded information type\
- 18.1
- .LP
- envelope\
- 8.1
- .LP
- event\
- 9.1
- .LP
- expansion point\
- 9.4.4
- .LP
- explicit conversion\
- 9.4.6
- .LP
- export\
- 9.3.5
- .LP
- extension\(hyphysical\(hydelivery\(hyaddress\(hy
- components\ \ 18.3.5
- .LP
- extension\(hypostal\(hyO/R\(hyaddress\(hycomponents\
- 18.3.4
- .LP
- external routing\
- 9.4.10
- .LP
- external transfer\
- 9.3.4
- .LP
- formatted\
- 18.5.3
- .LP
- global MHS\
- 15
- .LP
- grade\
- 7.5.2
- .LP
- immediate recipient\
- 9.1
- .LP
- implicit conversion\
- 9.4.6
- .LP
- import\
- 9.3.3
- .LP
- indirect submission\
- 9.3.2
- .LP
- indirect user\
- 7.1.2
- .LP
- intended recipient\
- 9.2
- .LP
- internal routing\
- 9.4.10
- .LP
- internal transfer\
- 9.3.4
- .LP
- joining\
- 9.4.2
- .LP
- local\(hypostal\(hyattributes\
- 18.3.6
- .LP
- management domain\
- 14.1
- .LP
- mandatory\
- 5.2
- .LP
- members\
- 7.1.3
- .LP
- member recipient\
- 9.2
- .LP
- message\
- 8.1
- .LP
- message handling\
- 6
- .LP
- message handling environment\
- 7
- .LP
- message handling system\
- 7.1.1
- .LP
- message storage\
- 6
- .LP
- message store\
- 7.2.3
- .LP
- message transfer\
- 6
- .LP
- message transfer agent\
- 7.3.1
- .LP
- message transfer system\
- 7.2.1
- .LP
- messaging system\
- 13.1
- .LP
- mnemonic O/R address\
- 18.5.1
- .LP
- name resolution\
- 9.4.3
- .LP
- nested\
- 7.1.3
- .LP
- network\(hyaddress\
- 18.3.7
- .LP
- non\(hyaffirmation\
- 9.4.8
- .LP
- non\(hydelivery\
- 9.4.7
- .LP
- non\(hydelivery report\
- 8.3
- .LP
- numeric\(hyuser\(hyidentifier\
- 18.3.8
- .LP
- numeric O/R address\
- 18.5.2
- .LP
- O/R address\
- 18.5
- .LP
- O/R name\
- 17.2
- .LP
- optional\
- 5.2
- .LP
- organization\(hyname\
- 18.3.9
- .LP
- organizational\(hyunit\(hynames\
- 18.3.10
- .LP
- origination\
- 9.3.1
- .LP
- originator\
- 9.2
- .LP
- originator\(hyspecified alternate recipient\
- 9.2
- .LP
- personal\(hyname\
- 18.3.12
- .LP
- physical\(hydelivery\(hycountry\(hyname\
- 18.3.13
- .LP
- physical\(hydelivery\(hyoffice\(hyname\
- 18.3.14
- .LP
- physical\(hydelivery\(hyoffice\(hynumber\
- 18.3.15
- .LP
- physical\(hydelivery\(hyorganization\(hyname\
- 18.3.16
- .LP
- physical\(hydelivery\(hypersonal\(hyname\
- 18.3.17
- .LP
- physical\(hydelivery\(hyservice\(hyname\
- 18.3.11
- .LP
- physical delivery\
- 7.4.1
- .LP
- physical delivery access unit\
- 7.4.1
- .LP
- physical delivery system\
- 7.4.1
- .LP
- physical message\
- 7.4.1
- .LP
- physical rendition\
- 7.4.1
- .LP
- post\(hyoffice\(hybox\(hyaddress\
- 18.3.18
- .LP
- postal\(hycode\
- 18.3.19
- .LP
- .rs
- .sp 12P
- .ad r
- BLANC
- .ad b
- .RT
- .LP
- .bp
- .LP
- postal O/R address\
- 18.5.3
- .LP
- poste\(hyrestante\(hyaddress\
- 18.3.20
- .LP
- potential recipient\
- 9.2
- .LP
- private\(hydomain\(hyname\
- 18.3.21
- .LP
- private management domain\
- 14.1.2
- .LP
- probe\
- 8.2
- .LP
- receipt\
- 9.3.8
- .LP
- recipient\
- 9.2
- .LP
- recipient\(hyassigned alternate recipient\
- 9.2
- .LP
- redirection\
- 9.4.5
- .LP
- report\
- 8.3
- .LP
- retrieval\
- 9.3.7
- .LP
- routing\
- 9.4.10
- .LP
- splitting\
- 9.4.1
- .LP
- standard attribute\
- 18.1
- .LP
- step\
- 9.1
- .LP
- storage and transfer system\
- 13.1.6
- .LP
- storage system\
- 13.1.2
- .LP
- street\(hyaddress\
- 18.3.22
- .LP
- subject message\
- 8.3
- .LP
- subject probe\
- 8.3
- .LP
- submission\
- 9.3.2
- .LP
- submission agent\
- 19.3.2
- .LP
- submit permission\
- 7.1.3
- .LP
- supplying ASE\
- 26.2
- .LP
- supplying UE\
- 26.2
- .LP
- symmetric\
- 26.2
- .LP
- terminal\(hyidentifier\
- 18.3.23
- .LP
- terminal\(hytype\
- 18.3.24
- .LP
- terminal O/R address\
- 18.5.4
- .LP
- transfer\
- 9.3.4
- .LP
- transfer system\
- 13.1.4
- .LP
- transmittal\
- 9.1
- .LP
- transmittal event\
- 9.1
- .LP
- transmittal step\
- 9.1
- .LP
- type\ 18.1
- .LP
- unformatted\
- 18.5.3
- .LP
- unformatted\(hypostal\(hyaddress\
- 18.3.25
- .LP
- unique\(hypostal\(hyname\
- 18.3.26
- .LP
- user\
- 7.1.2
- .LP
- user agent\
- 7.2.2
- .LP
- value\
- 18.1
- .LP
- .rs
- .sp 12P
- .ad r
- Blanc
- .ad b
- .RT
- .LP
- .bp
- .LP
- .bp
-