Last draft of PRMD requirements paper
hagens@cs.wisc.edu Wed, 11 March 1992 23:12 UTC
Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04586; 11 Mar 92 18:12 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa00421; 11 Mar 92 18:13 EST
Received: from mhs-relay.cs.wisc.edu by NRI.Reston.VA.US id aa00401; 11 Mar 92 18:13 EST
Received: from calypso.cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <27543-0@mhs-relay.cs.wisc.edu>; Wed, 11 Mar 1992 14:45:43 +0000
Received: from localhost by calypso.cs.wisc.edu with SMTP (PP) id <15592-0@calypso.cs.wisc.edu>; Wed, 11 Mar 1992 14:45:30 +0000
To: ietf-osi-x400ops@cs.wisc.edu
Subject: Last draft of PRMD requirements paper
Date: Wed, 11 Mar 1992 14:45:24 -0600
From: hagens@cs.wisc.edu
Message-ID: <9203111813.aa00401@NRI.Reston.VA.US>
Here is the last draft (before the IETF) of the PRMD requirements paper.
There are only 2 differences between this draft and the previous draft.
1) I stopped trying to indicate deleted text with italics. Deleted text
is now, well, just deleted! The area around the deleted text has
changebars. If you really want to know what was deleted, you'll have
to compare it to a previous version. I know this will disturb some
of you, but it is the best I can do right now.
2) Section "echo 3.1.2. Administration Management Domain (ADMD)" has
been added according to the text written by a previous COSINE meeting.
So, if you have read the last version (1.9), all you really need to do
is read section 3.1.2, and you will have read the 1.10 version.
This version (1.10) has been submitted as an Internet Draft.
Rob
Operational Requirements for X.400 Management Domains
March 11, 1992
Robert A. Hagens
C=US; ADMD= ; PRMD=XNREN; O=UW-Madison; OU=cs; S=hagens
hagens@cs.wisc.edu
Alf Hansen
C=no; ADMD= ; PRMD=uninett; O=sintef; OU=delab; S=Hansen; G=Alf
Alf.Hansen@delab.sintef.no
$Revision: 1.10 $
Status of this Memo
This document specifies a set of minimal operational
requirements that shall be implemented by all Management
Domains (MDs) in the International X.400 Service. This
document defines the core operational requirements; in some
cases, technical detail is handled by reference to other
documents.
The International X.400 Service is defined as all organiza-
tions which meet the requirements described in this docu-
ment.
This document is currently a working draft. It does not
carry any implications of agreement on policy. When agree-
ment is reached, it will be submitted to the RFC editor as
an informational document. Distribution of this memo is
unlimited. Please send comments to the authors or to the
discussion group:
ietf-osi-x400ops@cs.wisc.edu
C=us; ADMD= ; PRMD=xnren; O=UW-Madison; OU=cs; S=ietf-osi-x400ops
Beginning with version 1.9, this document contains change |
bars which indicated changes that have been made. Change |
bars only reflect the changes from the previous version. |
Change bars appear to the right of the text, as in this |
paragraph. Deleted text is not shown. |
Pervasive changes are not denoted with change bars. However, |
they are noted at the beginning of the document. Pervasive |
INTERNET--DRAFT [Page 1] INTERNET--DRAFT
changes from version 1.8 to 1.9 are: |
+ |
The phrase "International Service" has been replaced |
with "International X.400 Servce". |
+ |
References have been cleaned up. |
+ |
Section 2.3 has been extensively rewritten
INTERNET--DRAFT [Page 2] INTERNET--DRAFT
1. Introduction
A large, operational, research and development X.400 service
called The COSINE X.400 Service is currently deployed
throughout Europe. Many of the COSINE X.400 organizations
are connected to the Internet. A number of other Internet-
connected organizations are beginning to operate internal
X.400 services (for example, U.S. government organizations
following U.S. GOSIP). The motivation for this document is
to foster a International X.400 Service that has full
interoperability with the existing E-mail service based on
RFC 822.
The goal of this document is to accommodate the global R&D |
community by uniting all regionally operated R&D X.400 ser-
vices on the various continents into one International X.400
Service (as seen from an end-user's point of view). Examples
of such regional services are the COSINE MHS Service in
Europe and the XNREN service in the U.S.
A successful International X.400 Service is dependent on |
decisions at both the national and international level.
National X.400 service providers are responsible for the
implementation of the minimum requirements defined in this
document. In addition to these minimum requirements,
national requirements may be defined by each national ser-
vice provider.
This document refers to other documents which should be pub- |
lished as RFCs. These documents are: |
+ Routing coordination for an X.400 MHS-service
within a multi protocol / multi network environment
[1].
+ X.400 1988 to 1984 downgrading [2].
This document handles issues concerning X.400 1984 and X.400 |
1988 to 1984 downgrading. Issues concerning pure X.400 1988 |
are left for further study. |
We are grateful to Allan Cargille and Lawrence Landweber for |
their input and guidance on this paper. This paper is also a |
product of discussions in the IETF X.400 Operations WG and |
the RARE WG1 (on MHS). |
1.1. Terminology |
This document defines requirements, recommendations and con- |
ventions. Throughout the doucment, the following defini- |
tions apply: a requirement is specified with the word shall. |
A recommendation is specified with the word should. A |
INTERNET--DRAFT [Page 3] INTERNET--DRAFT
convention is specified with the word might. Conventions |
are intended to make life easier for RFC 822 systems that |
don't follow the host requirements.
1.2. Profiles
This section identifies the X.400 profiles which shall be
supported by participating organizations. The following is a
list of such profiles. |
+ U.S. GOSIP - unspecified version
+ ENV - 401201
2. Architecture of the International X.400 Service
In order to facilitate a coherent deployment of X.400 in the
International X.400 Service , it is necessary to define, in
general terms, the overall structure and organization of the
X.400 service. This section is broken into several parts
which discuss management domains, lower layer connectivity
issues, and overall routing issues.
2.1. Management Domains
The X.400 model supports connectivity between administra-
tions with different service requirements; the architectural
vehicle for this is a Management Domain. Management domains
are needed when different administrations have different
specific requirements. Two types of management domains are
defined by the X.400 model: an Administration Management
Domain (ADMD) and a Private Management Domain (PRMD).
Throughout the world in various countries there are dif-
ferent organizational policies for MDs. All of these poli-
cies are legal according to the X.400 standard. Currently,
national X.400 service providers are organized as:
a) One or several ADMDs.
b) One or several PRMDs and with no ADMDs present in the country.
c) One or several PRMDs connected to one or several ADMDs.
At this stage it is not possible to say which model is the
most effective. Thus, the International X.400 Service shall
allow every model.
2.2. The Well Known Entrypoint (WEP)
The X.400 message routing decision process takes as input
the destination O/R address and produces as output the name
(and perhaps connection information) of the MTA who will
take responsibility of delivering the message to the
INTERNET--DRAFT [Page 4] INTERNET--DRAFT
recipient. The X.400 store and forward model permits a mes-
sage to pass through multiple MTAs. However, it is generally
accepted that the most efficient path for a message to take
is one where a direct connection is made from the originator
to the recipient's MTA.
Large scale deployment of X.400 in the International X.400
Service will require a well deployed X.500 infrastructure to
support routing. In this environment, a routing decision can
be made by searching the X.500 database with a destination
O/R address in order to obtain the name of the next hop MTA.
This MTA may be a central entry point into an MD, or it may
be the destination MTA within an MD.
Deployment of X.400 without X.500 will require the use of
static tables to store routing information. This table
(keyed on O/R addresses), will be used to map a destination
O/R address to a next hop MTA. In order to facilitate effi-
cient routing, one could build a table that contains infor-
mation about every MTA in every MD. However, this is not
feasible in practice. Therefore,
it is necessary to use the concept of a well known
entrypoint (WEP).
The purpose of a WEP is to act as a default entry point into
an MD. The MTA that acts as a WEP for an MD shall be capable
of accepting responsibility for all messages that it
receives that are destined for well-defined recipients in
that MD.
The use of a WEP for routing is defined by [1]. WEPs in the
International X.400 Service shall operate according to [1].
2.3. Lower Layer Stack Incompatibilities
A requirement for successful operation of the International
X.400 Service is that all users can exchange messages. The
International X.400 Service is not dependent on the tradi-
tional TCP/IP lower layer protocol suite. A variety of lower
layer suites are used as carriers of X.400 messages. |
For example, consider Figure 1. |
figure arch.ps
height 4i
Figure 1: A International X.400 Service Deployment Scenario
PRMD A has three WEPs which collectively provide support for |
INTERNET--DRAFT [Page 5] INTERNET--DRAFT
the TP0/CONS/X.25, TP0/RFC1006, and TP4/CLNS stacks[1] Thus, |
PRMD A is reachable via these stacks. However, since PRMD B |
only supports the TP0/CONS/X.25 stack, it is not reachable |
from the TP0/RFC 1006 or the TP4/CLNS stack. PRMD C supports |
TP0/RFC1006 and TP4/CLNS. Since PRMD B and PRMD C do not |
share a common stack, how is a message from PRMD C to reach |
a recipient in PRMD B ? |
One solution to this problem is to require that PRMD B |
implement a stack in common with PRMD C. However this is may |
not be a politically acceptable answer to PRMD B. |
Another solution is to implement a transport service bridge |
(TSB) between TP0/RFC 1006 in PRMD C to TP0/CONS in PRMD B. |
This will solve the problem for PRMD C and B. However, the |
lack of a coordinated deployment of TSB technology makes |
this answer alone unacceptable on an international scale. |
The solution to this problem is to define a coordinated |
mechanism that allows PRMD B to the world that it has made a |
bilateral agreements with PRMD A to support reachability to |
PRMD B from the TP0/RFC 1006 stack. |
This solution does not require that every MTA or MD directly |
support all stacks. However, it is a requirement that if a |
particular stack is not directly supported by an MD, the MD |
will need to make bilateral agreements with other MD(s) in |
order to assure that connectivity from that stack is avail- |
able. |
Thus, in the case of Figure 1, PRMD B can make a bilateral |
agreement with PRMD A which provides for PRMD A to relay |
messages which arrive on either the TP4/CLNP stack or the |
TP0/RFC 1006 stack to PRMD B using the TP0/CONS stack. |
The policies described in [1] define this general purpose |
solution. It is a requirement that all MDs follow the rules |
and policies defined by [1].
3. Description of International X.400 Service Policies
An IMD is a Management Domain in the International X.400
Service.
The policies described in this section constitute a minimum |
set of common policies for IMDs. They are specified to
ensure interoperability between
[1] Note: it is acceptable for a single WEP to support
more than one stack. Three WEPs are shown in this picture
for clarity.
INTERNET--DRAFT [Page 6] INTERNET--DRAFT
- all IMDs.
- all IMDs and the Internet mail service (SMTP).
- all IMDs and other X.400 service providers.
Policies defined below are defined in terms of the words:
shall, should and might.
3.1. X.400 address registration
An O/R address is a descriptive name for a UA that has cer- |
tain characteristics that help the Service Providers to |
locate the UA. Every O/R address is an O/R name, but not |
every O/R name is an O/R address. This is explained in [5], |
chapter 3.1. |
Uniqueness of X.400 addresses shall be used to ensure end- |
user connectivity. |
O/R addresses shall be used according to the description of |
O/R names, Form 1, Variant 1 (see [5], chapter 3.3.2). The |
attributes shall be regarded as a hierarchy of |
Country name (C)
Administration domain name (ADMD)
[Private domain name] (PRMD)
[Organization name] (O)
[Organizational Unit Names] (OUs)
[Personal name] (PN)
[Domain-defined attributes] (DDAs)
Attributes enclosed in square brackets are optional. At |
least one of PRMD, PN, O an OU names shall be present in an |
O/R address. |
In general an underlaying address element shall be unique |
within the scope of the overlaying element. An exception is |
PRMD, see section 3.1.2. There shall exist registration |
authorities for each level, or mechanisms shall be available |
to ensure such uniqueness.
3.1.1. Country (C)
The values of the top level element, Country, shall be |
defined by the set of two letter country codes, or numeric |
country codes in ISO 3166.
3.1.2. Administration Management Domain (ADMD)
This section defines which value should be given to the ADMD |
attribute. Three values are often proposed: |
- the real name of (one of) the ADMD(s)
INTERNET--DRAFT [Page 7] INTERNET--DRAFT
to which the PRMD is attached.
- a single space (" ")
- a single zero ("0")
The 1984 standard does not address this problem. The ENV |
41201 (for 1984) proposes the use of a single space when no |
ADMD exists. The 1988 standard specifies that a single space |
can be used if it is permitted by the country to designate |
any ADMD in the country. The Implementor's Guide Version 2 |
(ISO only) proposes that if a PRMD intends never to be con- |
nected to an ADMD, it uses "0" as ADMD value. |
According to the previous document references, three condi- |
tions must be taken into account: |
- Has a national decision be taken ?
- How many ADMDs are there in the country ?
- Is the PRMD connected to an ADMD ?
A table has been defined to combine all these conditions and |
define the value which should be placed into the ADMD field. |
A general conclusion is that the decision at the national |
level should be to allow the use of a single space. If the |
decision has not yet been taken, this document recommends |
that the country make the decision to allow the use of a |
single space. In the interim, a country without a national |
decision should act as if the decision has been made to |
allow the use of a single space. |
Therefore, if the national decision is to disallow a " " |
value for the ADMD, the following table should be used. |
Number of Number of PRMD
ADMDs connections Recommendation
-------------------------------------------------
0 0 prepare for the future
1 0 use "0"
1 1 use the ADMD name
more 0 use "0"
more 1 use the ADMD name
more >1 choose one
-------------------------------------------------
If the national decision is to allow a " " value for the |
ADMD, the following table should be used. |
INTERNET--DRAFT [Page 8] INTERNET--DRAFT
Number of Number of PRMD
ADMDs connections Recommendation
-------------------------------------------------
0 0 prepare for the future
1 0 use "0"
1 1 use " " or ADMD name
more 0 use "0"
more 1 use " " or ADMD name
more >1 use " " or choose one
-------------------------------------------------
3.1.3. Private Management Domain (PRMD) |
The PRMD values should be unique within a country. |
3.1.4. Organization (O)
Organization values shall be unique within the context of |
the subscribed PRMD or ADMD if there is no PRMD.
3.1.5. Organizational units (OUs)
A unique hierarchy of OUs shall be implemented. The top |
level OU is unique within the scope of the overlaying |
address element.
3.1.6. Given name, Initials, Surname (G I S)
The following elements should be used: Given name (G), Ini- |
tials (I) and Surname (S).
Each Organization can define its own Given-names, Initials,
and Surnames to be used within the Organization. In the
cases when Surnames are not unique within an O or OU, The
Given-name and/or Initial will be used to identify the
Originator/Recipient. In the rare cases when more than one
user would have the same combination of G, I, S under the
same O and/or OUs, each organization is free to find a prac-
tical solution, and provide the users with unique O/R
addresses.
To avoid problems with the mapping of the X.400 addresses
into RFC-822 addresses, the following rules might be used. |
ADMD, PRMD, O, and OU values should consist of characters |
drawn from the alphabet (A-Z), digits (0-9), and minus. No |
blank or space characters are permitted as part of a name. |
No distinction is made between upper and lower case. The |
last character must not be a minus sign or period. The |
first character may be either a letter or a digit (see [6], |
[7]).
INTERNET--DRAFT [Page 9] INTERNET--DRAFT
3.1.7. Domain Defined Attributes (DDAs)
The International X.400 Service shall allow the use of
domain defined attributes. The following DDAs shall be sup-
ported by an IMD:
"RFC-822" - defined in [3].
The following DDAs should be supported by an IMD:
"COMMON" - defined in [2].
3.2. X.400 88 -> 84 downgrading
The requirements in [2] should be implemented in IMDs.
3.3. X.400 / RFC 822 address mapping
All International X.400 Service end-users shall be reachable
from all end-users in the Internet mail service (SMTP), and
vice versa.
The address mapping issue is split into two parts:
1) Specification of RFC-822 addresses seen from the X.400 world.
2) Specification of X.400 addresses seen from the RFC-822 world.
The mapping of X.400 and RFC-822 addresses shall be per- |
formed according to [3].
3.3.1. Specification of RFC-822 addresses seen from the
X.400 world
Two scenarios are described:
A. The RFC-822 end-user belongs to an organization with no defined X.400
standard attribute address space.
B. The RFC-822 end-user belongs to an organization with a defined X.400
standard attribute address space.
Organizations belong to scenario B if their X.400 addresses
are registered according to the requirements in section 3.1.
3.3.1.1. An organization with no defined X.400 address
space
RFC-822 addresses shall be expressed using X.400 domain
defined attributes. The mechanism used to define the RFC-
822 recipient will vary on a per-country basis.
INTERNET--DRAFT [Page 10] INTERNET--DRAFT
For example, in the US, a special PRMD named "Internet" is
defined to facilitate the specification of RFC-822
addresses. A X.400 user can address an RFC-822 recipient in
the U.S. by constructing an X.400 address such as:
C=us; ADMD= ; PRMD=Internet; DD.RFC-822=user(a)some.place.edu;
The first part of this address:
C=us; ADMD= ; PRMD=Internet;
denotes the U.S. portion of the Internet community and not a |
specific "gateway". The 2nd part:
DD.RFC-822=user(a)some.place.edu
is the RFC-822 address of the Internet mail user after sub-
stitution of non-printable characters according to RFC-1148.
The RFC-822 address is placed in an X.400 Domain Defined
Attribute of type RFC-822 (DD.RFC-822).
Each country is free to choose its own method of defining
the RFC-822 community. For example in Italy, an X.400 user
would refer to an RFC-822 user as:
C=IT; ADMD=MASTER400; DD.RFC-822=user(a)some.place.it
In the UK, an X.400 user would refer to an RFC-822 user as:
C=GB; ADMD= ; PRMD=UK.AC; O=MHS-relay; DD.RFC-822=user(a)some.place.uk
3.3.1.2. An organization with a defined X.400 address
space
An RFC-822 address for an Internet mail user in such an
organization shall look exactly as a normal X.400 address
for X.400 users in the same organization. Example:
University of Wisconsin-Madison is registered under C=US;
ADMD= ; PRMD=XNREN; with O=UW-Madison and they are using
OU=cs to address end-users in the CS-department. The RFC-822
address for Internet mail users in the same department is:
user@cs.wisc.edu.
An X.400 user in the International X.400 Service will
address the Internet mail user at the CS-department with the
X.400 address:
INTERNET--DRAFT [Page 11] INTERNET--DRAFT
C=US; ADMD= ; PRMD=xnren; O=UW-Madison; OU=cs; S=user;
This is the same address space as is used for X.400 end-
users in the same department.
3.3.2. Specification of X.400 addresses seen from the RFC-
822 world |
If an X.400 organization has a defined RFC-822 address |
space, RFC-822 users will be able to address X.400 reci- |
pients in RFC-822/Internet terms. This means that the |
address of the X.400 user, seen from an RFC-822 user, will |
be on the form: |
Firstname.Lastname@some.place.edu
where the some.place.edu is a registered Internet domain. |
This implies the necessity of maintaining and distributing |
address mapping tables to all participating RFC-987 gate- |
ways. The mapping tables shall be globally consistent. |
Effective mapping table coordination procedures are needed. |
The procedures define in [4] shall be followed. |
If an organization does not have a defined RFC-822 address |
space, an escape mapping (defined in [3]) shall be used. In |
this case, the address of the X.400 user, seen from an RFC- |
822 user, will be on the form: |
"/G=Firsname/S=Lastname/O=orgname/PRMD=foo/ADMD=bar/C=us/"@
some.gateway.edu
This escape mapping shall also be used for X.400 addresses |
do not map cleanly to RFC-822 addresses. |
It is recommended that an organization with no defined RFC- |
822 address space, should register RFC-822 domains at SRI- |
NIC. This will minimize the number of addresses which must |
use the escape mapping.
If the escape mapping is not used, RFC-822 users will not
see the difference between an Internet RFC-822 address and
an address in the International X.400 Service. For example:
The X.400 address:
C=us; ADMD=ATTMail; PRMD=CDC; O=CPG; S=Lastname; G=Firstname;
INTERNET--DRAFT [Page 12] INTERNET--DRAFT
will from an RFC-822 user look like:
Firstname.Lastname@cpg.cdc.com
3.4. Routing policy
To facilitate routing in the International X.400 Service |
before an X.500 infrastructure is deployed, the following |
two tables, an MTA table and a Domain table, are defined. |
These tables are formally defined in [1]. The use of these |
tables is necessary to solve the routing crisis that is |
present today. However, this is a temporary solution that |
will be replace by the use X.500 when an X.500 infrastruc- |
ture is present.
The MTA table will define the names of well known MTAs
(WEPs) and their associated connection data including selec-
tor values, NSAP addresses, supported protocol stacks, and
supported X.400 protocol version(s).
Each entry in the Domain table consists of a sub-tree
hierarchy of an X.400 address, followed by a list of MTAs
which are willing to accept mail for the address or provide
a relay service for it. Each MTA name will be associated
with a priority value. Collectively, the list of MTA names
in the Domain table make the given address reachable from
all protocol stacks. In addition, the list of MTAs may pro-
vide redundant paths to the address, so in this case, the
priority value indicates the preferred path, or the pre-
ferred order in which alternative routes should be tried.
The MTA and Domain tables are coordinated at a global, cen- |
tral administration point. The procedures for table informa-
tion gathering and distribution, are for further study.
3.5. Minimum statistics/accounting
-- Editor's Note --
We are waiting for a contribution from the
COSINE MHS Project team.
INTERNET--DRAFT [Page 13] INTERNET--DRAFT
References
[1] U. Eppenberger, Routing coordination for an X.400 MHS-
service within a multi protocol / multi network
environment, unpublished working draft.
[2] S.E. Hardcastle-Kille, X.400 1988 to 1984 downgrading,
IETF Internet Draft, "draft-ietf-kille-
88to84downgrade-01.txt".
[3] S.E. Hardcastle-Kille, Mapping between X.400(1988) /
ISO 10021 and RFC 822, IETF Internet Draft
[4] <This should be a reference to a document which
specifies mapping table maintainence and distribution
procedures>.
[5] <ref. CCITT Red Book, X.400>
[6] K. Harrenstien, et al. DOD Internet Host Table
Specification. Request for Comments 952, October 1985.
[7] R. Braden. Requirements for Internet Hosts --
Application and Support. Request for Comments 1123,
October 1989.
INTERNET--DRAFT [Page 14] INTERNET--DRAFT