Internet Standards/CD1.mdf/iso/10021_23.asc

Text File | 1992-12-23 | 15KB | 267 lines

Section Three - Configurations
11.      Overview
This section specifies  how  one  can  configure  the  MHS  to  satisfy  any  of  a  variety
of functional, physical, and organizational requirements.
This section covers the following topics:
a)   Functional configurations
b)   Physical configurations
c)   Organizational configurations
d)   The Global MHS
12.      Functional Configurations
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.
12.1     Regarding the Directory
With respect to the Directory,  the  MHS  can  be  configured  for  a  particular  user,  or
a  collection  of  users  (e.g.,  see  clause  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 five.
Note    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.
12.2     Regarding the Message Store
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.
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.
+----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 |  |  08  |  |  09  |  |  10  |  |  11
| | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20  |  |  21  |  |  22  |  |  23
| | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+
Figure .F.:7/X.402 Functional Configurations Regarding the MS
Note   While the  users  depicted  in  the  figure  are  people,  the  figure  applies  with
equal force and validity to users of other kinds.
13.      Physical Configurations
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.
13.1     Messaging Systems
The  building  blocks  used  in  the  physical  construction   of   the   MHS   are   called
messaging systems. A  .I.gl:messaging  system;  is  a  computer  system  (possibly  but  not
necessarily an open system) that contains, or realizes, one of more functional objects.
Messaging systems are of the types depicted in Figure 8/X.402.
+----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 |  |  08  |  |  09  |  |  10  |  |  11
| | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20  |  |  21  |  |  22  |  |  23
| | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+
Figure .F.:8/X.402 Messaging System Types
The  types  of  messaging  system,  depicted  in  the  figure,  are  listed  in  the   first
column of Table 8/X.402. For each  type  listed,  the  second  column  indicates  the  kinds
of  functional  object--UAs,  MSs,  MTAs,  and  AUs--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.
Table .T.:8/X.402 Messaging Systems
+-----------+--------------------+  |            |  Functional   Objects   |   |   Messaging
+--------------------+ |  System     |   UA    MS   MTA   AU   |  +-----------+-------------
--------+ | A/SYS     |  1    -    -     -   |  |  S/SYS      |   -     1     -     -   |  |
AS/SYS    |  1    1     -     -   |  +-----------+--------------------+  |  T/SYS      |   -
  -    1   [M] |  |  AT/SYS     |   M     -     1    [M]  |  |  ST/SYS     |   -     M     1
[M]  |  |  AST/SYS    |   M     M     1    [M]  |   +-----------+--------------------+    +-
Legend -------------------+ | M multip e   [...]  optional  |  +----------------------------
-+
The  messaging  system  types,  summarized  in  the  table,  are  individually  defined  and
described in the clauses below.
Note    The  following  major  principles  governed  the  admission  of   messaging   system
types:
a)   An AU and the  MTA  with  which  it  interacts  are  typically  co-located  because  no
protocol to govern their interaction is standardized.
b)    An  MTA  is  typically  co-located  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.
c)   No purpose is served  by  co-locating  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-related processes co-existing within a single computer system.)
d)   The co-location  of  an  AU  with  an  MTA  does  not  affect  that  system's  behavior
with  respect  to  the  rest  of  the  MHS.  A  single  messaging  system  type,  therefore,
encompasses the AU's presence and absence.
13.1.1   Access Systems
An .I.gl:access  system;  (.I.ab:A/SYS;)  contains  one  UA  and  neither  an  MS,  an  MTA,
nor an AU.
An A/SYS is dedicated to a single user.
13.1.2   Storage Systems
A  .I.gl:storage  system;  (.I.ab:S/SYS;)  contains  one  MS  and  neither  a  UA,  an  MTA,
nor an AU.
An S/SYS is dedicated to a single user.
13.1.3   Access and Storage Systems
An  .I.gl:access  and  storage  system;  (.I.ab:AS/SYS;)  contains  one  UA,  one  MS,   and
neither an MTA nor an AU.
An AS/SYS is dedicated to a single user.
13.1.4   Transfer Systems
A  .I.gl:transfer  system;  (.I.ab:T/SYS;)  contains  one  MTA;  optionally,  one  or   more
AUs; and neither a UA nor an MS.
A T/SYS can serve multiple users.
13.1.5   Access and Transfer Systems
An .I.gl:access  and  transfer  system;  (.I.ab:AT/SYS;)  contains  one  or  more  UAs;  one
MTA; optionally, one or more AUs; and no MS.
An AT/SYS can serve multiple users.
13.1.6   Storage and Transfer Systems
A .I.gl:storage  and  transfer  system;  (.I.ab:ST/SYS;)  contains  one  or  more  MSs;  one
MTA; optionally, one or more AUs; and no UA.
An ST/SYS can serve multiple users.
13.1.7   Access, Storage, and Transfer Systems
An  .I.gl:access,  storage,  and  transfer  system;   (.I.ab:AST/SYS;)   contains   one   or
more UAs; one or more MSs; one MTA; and optionally, one or more AUs.
An AST/SYS can serve multiple users.
13.2     Representative Configurations
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.
+----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 |  |  08  |  |  09  |  |  10  |  |  11
| | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20  |  |  21  |  |  22  |  |  23
| | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+
Figure .F.:9/X.402 Representative Physical Configurations
Notes
1.  While  the  users  depicted  in  the  figure  are  people,  the  figure   applies   with
equal force and validity to users of other kinds.
2.  Besides  the  physical  configurations  that   result   from   the   "pure"   approaches
below, many "hybrid" configurations can be constructed.
13.2.1   Fully Centralized
The MHS may be  fully  centralized  (panel  a  of  the  figure).  This  design  is  realized
by a  single  AST/SYS  which  contains  functional  objects  of  all  kinds  and  which  can
serve multiple users.
13.2.2   Centralized Message Transfer and Storage
The  MHS  may  provide  both  Message  Transfer  and  Message  Storage  centrally  but  user
access distributedly (panel  b  of  the  figure).  This  design  is  realized  by  a  single
ST/SYS and, for each user, an A/SYS.
13.2.3   Centralized Message Transfer
The MHS may  provide  Message  Transfer  centrally  but  Message  Storage  and  user  access
distributedly (panel  c  of  the  figure).  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.
13.2.4   Fully Distributed
The  MHS  may  provide  even  Message  Transfer  distributedly  (panel  d  of  the  figure).
This design involves multiple ST-SYNs or T-SYNs.
14.      Organizational Configurations
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  management  domains  from
which  the   MHS   is   assembled,   and   identifies   a   few   important   representative
configurations.
14.1     Management Domains
The primary building  blocks  used  in  the  organizational  construction  of  the  MHS  are
called    management    domains.    A    .I.gl:management    domain;     (.I.ab:MD;)     (or
.I.gl:domain;) is a set of messaging systems--at least one of which contains, or realizes, an
MTA--that is managed by a single organization.
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, "attaches" to an MD.
MDs  are  of  several  types  which  are  individually  defined   and   described   in   the
clauses below.
14.1.1   Administration Management Domains
An   .I.gl:administration   management    domain;    (.I.ab:ADMD;)    comprises    messaging
systems managed by an Administration.  The  major  technical  distinction  between  an  ADMD
and a PRMD is that the former is positioned  above  the  latter  in  the  MHS'  hierarchical
addressing (see clause 18) and routing (see clause 19) regimes.
Note   An ADMD provides Message Handling to the public.
14.1.2   Private Management Domains
A   .I.gl:private   management   domain;   (.I.ab:PRMD;)   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 clause 18) and routing (see clause 19) regimes.
Note   A  PRMD  provides  Message  Handling,  e.g.,  to  the  employees  of  a  company,  or
to those employees at a particular company site.
14.2     Representative Configurations
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.
+----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 |  |  08  |  |  09  |  |  10  |  |  11
| | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20  |  |  21  |  |  22  |  |  23
| | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+
Figure .F.:10/X.402 Representative Organizational Configurations
Note    Besides  the   organizational   configurations   that   result   from   the   "pure"
approaches below, many "hybrid" configurations can be constructed.
14.2.1   Fully Centralized
The entire  MHS  may  be  managed  by  one  organization  (panel  a  of  the  figure).  This
design is realized by a single MD.
14.2.2   Directly Connected
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  the  figure).   This
design is realized by multiple MDs interconnected pair-wise.
14.2.3   Indirectly Connected
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  the
figure). This design is realized by multiple MDs one  of  which  is  interconnected  to  all
of the others.
15.      The Global MHS
A  major  purpose  of  this  Recommendation  and  others  in  the  set  is  to  enable   the
construction of the .I.gl:Global MHS;, an MHS providing both intra- and inter-organizational, and both intra- and international Message Handling world-wide.
The  Global  MHS   almost   certainly   encompasses   the   full   variety   of   functional
configurations specified in clause 12.
The   physical   configuration   of   the   Global   MHS   is   a   hybrid   of   the   pure
configurations specified in clause 13, extremely complex and highly distributed physically.
The  organizational  configuration  of  the  Global  MHS   is   a   hybrid   of   the   pure
configurations  specified  in  clause  14,  extremely   complex   and   highly   distributed
organizationally.
      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 O/R addresses to users and DLs.
PRMDs  play  a  peripheral  role  in  the  Global  MHS,  being   connected   to   the   ADMD
backbone which serves as an intermediary between them.
+----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 |  |  08  |  |  09  |  |  10  |  |  11
| | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20  |  |  21  |  |  22  |  |  23
| | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+
Figure .F.:11/X.402 The Global MHS