As per Relevance of the word organization, we have this rfc below:
Network Working Group R.
Request for Comments: 1649 Advanced Network & Services, Inc
Category: Informational A.
July 1994
Operational Requirements for X.400 Management
in the GO-MHS
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
1.
There are several large, operational X.400 services
deployed. Many of the organizations in these services are
to the Internet. A number of other Internet-connected
are beginning to operate internal X.400 services (for example, U.S
government organizations following U.S. GOSIP). The motivation
this document is to foster a Global Open Message Handling
(GO-MHS) Community that has full interoperability with the
E-mail service based on RFC-822 (STD-11).
The goal of this document is to unite regionally operated X.400
services on the various continents into one GO-MHS Community (as
from an end-user's point of view). Examples of such
services are the COSINE MHS Service in Europe and the XNREN
in the U.S
A successful GO-MHS Community is dependent on decisions at both
national and international level. National X.400 service
are responsible for the implementation of the minimum
defined in this document. In addition to these minimum requirements
national requirements may be defined by each national
provider
This document refers to other documents which are published as RFCs
These documents are [1], [2], [3], [4], [6] and [7] in the
list
This document handles issues concerning X.400 1984 and X.400 1988
1984 downgrading. Issues concerning pure X.400 1988 are left
further study
Hagens & Hansen [Page 1]
RFC 1649 X.400 Management in GO-MHS July 1994
We are grateful to Allan Cargille and Lawrence Landweber for
input and guidance on this paper. This paper is also a product
discussions in the IETF X.400 Operations WG and the RARE WG-
(former RARE WG1 (on MHS)).
1.1.
This document defines requirements, recommendations and conventions
Throughout the document, the following definitions apply:
requirement is specified with the word shall. A recommendation
specified with the word should. A convention is specified with
word might. Conventions are intended to make life easier for RFC-822
systems that don't follow the host requirements
1.2.
Different communities have different profile requirements.
following is a list of such profiles
o U.S. GOSIP - unspecified
o ENV - 41201
o UK GOSIP for X.400(88)
In the case when mail traffic is going from the RFC-822 mail
to the GO-MHS Community, the automatic return of contents when
is non-delivered should be requested by RFC 1327 gateways and
be supported at the MTA that generates the non-delivery report
However, it should be noted that this practice maximizes the
associated with delivery reports
2. Architecture of the GO-MHS
In order to facilitate a coherent deployment of X.400 in the GO-
Community it is necessary to define, in general terms, the
structure and organization of the X.400 service. This section
broken into several parts which discuss management domains,
layer connectivity issues, and overall routing issues
The GO-MHS Community will operate as a single MHS community,
defined in reference [1].
2.1. Management
The X.400 model supports connectivity between communities
different service requirements; the architectural vehicle for this
a Management Domain. Management domains are needed when
administrations have different specific requirements. Two types
management domains are defined by the X.400 model: an
Hagens & Hansen [Page 2]
RFC 1649 X.400 Management in GO-MHS July 1994
Management Domain (ADMD) and a Private Management Domain (PRMD).
Throughout the world in various countries there are
organizational policies for MDs. All of these policies are
according to the X.400 standard. Currently, X.400 service
in a country (inside or outside the GO-MHS Community), are
as
a) One or several ADMDs
b) One or several PRMDs and with no ADMDs present
the country, or that are not connected to any ADMD
c) One or several PRMDs connected to one or several ADMDs
Or in combinations of a), b) and c). At this stage it is
possible to say which model is the most effective. Thus, the GO-
Community shall allow every model
2.2. The RELAY-
The X.400 message routing decision process takes as input
destination O/R address and produces as output the name (and
connection information) of the MTA who will take responsibility
delivering the message to the recipient. The X.400 store and
model permits a message to pass through multiple MTAs. However,
is generally accepted that the most efficient path for a message
take is one where a direct connection is made from the originator
the recipient's MTA
Large scale deployment of X.400 in the GO-MHS Community will
a well deployed directory infrastructure to support routing. In
GO-MHS Community X.500 is considered to be the best protocol for
an infrastructure. In this environment, a routing decision can
made by searching the directory with a destination O/R address
order to obtain the name of the next hop MTA. This MTA may be
central entry point into an MD, or it may be the destination
within an MD
Deployment of X.400 without a well deployed Directory infrastructure
will require the use of static tables to store routing information
These tables (keyed on O/R addresses), will be used to map
destination O/R address to a next hop MTA. In order to
efficient routing, one could build a table that contains
about every MTA in every MD. However, this table would be
and very dynamic, so this is not feasible in practice. Therefore,
is necessary to use the concept of a RELAY-MTA
The purpose of a RELAY-MTA is to act as a default entry point into
MD. The MTA that acts as a RELAY MTA for an MD shall be capable
Hagens & Hansen [Page 3]
RFC 1649 X.400 Management in GO-MHS July 1994
accepting responsibility for all messages that it receives that
destined for well-defined recipients in that MD
The use of a RELAY-MTA for routing is defined by reference [1].
RELAY-MTAs in the GO-MHS Community shall route according to
[1].
2.3. Lower Layer Stack
A requirement for successful operation of the GO-MHS Community
that all users can exchange messages. The GO-MHS Community is
dependent on the traditional TCP/IP lower layer protocol suite.
variety of lower layer suites are used as carriers of X.400 messages
For example, consider Figure 1.
-----------------------------------------------------
! !
! PRMD A !
! -------------------- !
! ! o x ! !
! ! ! !
! ! o w ! !
! ! z ! !
! -------------------- !
! PRMD B !
! ------------------ !
! ! o o ! !
! PRMD C ! o ! !
! ------------------ ! o z ! !
! ! o ! ! ! !
! ! o x ! ------------------ !
! ! o w ! !
! ! o ! !
! ------------------ !
! !
! Key: Each character the in !
! the boxes illustrates an MTA. !
! !
! x: TP0/RFC1006/TCP RELAY-MTA !
! w: TP4/CLNP RELAY-MTA !
! z: TP0/CONS/X.25 RELAY-MTA !
! o: MTA !
-----------------------------------------------------
Figure 1: A Deployment
Hagens & Hansen [Page 4]
RFC 1649 X.400 Management in GO-MHS July 1994
PRMD A has three RELAY-MTAs which collectively provide support
the TP0/CONS/X.25, TP0/RFC1006, and TP4/CLNS stacks. (Note: it
acceptable for a single RELAY-MTA to support more than one stack
Three RELAY-MTAs are shown in this figure for clarity.) Thus, PRMD
is reachable via these stacks. However, since PRMD B only
the TP0/CONS/X.25 stack, it is not reachable from the TP0/RFC 1006
the TP4/CLNS stack. PRMD C supports TP0/RFC1006 and TP4/CLNS.
PRMD B and PRMD C do not share a common stack, how is a message
PRMD C to reach a recipient in PRMD B
One solution to this problem is to require that PRMD B implement
stack in common with PRMD C. However this may not be a
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
solve the problem for PRMD C and B. However, the lack of
deployment of TSB technology makes this answer alone unacceptable
an international scale
The solution to this problem is to define a coordinated
that allows PRMD B to advertise to the world that it has made
bilateral agreement with PRMD A to support reachability to PRMD
from the TP0/RFC 1006 stack
This solution does not require that every MTA or MD directly
all stacks. However, it is a requirement that if a particular
is not directly supported by an MD, the MD will need to
bilateral agreements with other MD(s) in order to assure
connectivity from that stack is available
Thus, in the case of Figure 1, PRMD B can make a bilateral
with PRMD A which provides for PRMD A to relay messages which
on either the TP4/CLNP stack or the TP0/RFC 1006 stack to PRMD
using the TP0/CONS stack
The policies described in reference [1] define this general
solution. It is a requirement that all MDs follow the rules
policies defined by reference [1].
3. Description of GO-MHS Community
A GO-MD is a Management Domain in the GO-MHS Community
The policies described in this section constitute a minimum set
common policies for GO-MDs. They are specified to
interoperability between
Hagens & Hansen [Page 5]
RFC 1649 X.400 Management in GO-MHS July 1994
- all GO-MDs
- all GO-MDs and the RFC-822 mail service (SMTP).
- all GO-MDs and other X.400 service providers
3.1. X.400 Address
An O/R address is a descriptive name for a UA that has
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/
address. This is explained in reference [5], chapter 3.1.
Uniqueness of X.400 addresses shall be used to ensure end-
connectivity
Mailboxes shall be addressed according to the description of O/
names, Form 1, Variant 1 (see reference [5], chapter 3.3.2).
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
PRMD, O, OU and PN names shall be present in an O/R address. At
one of PN and DDA shall be present
In general a subordinate address element shall be unique within
scope of its immediately superior element. An exception is PRMD,
section 3.1.3. There shall exist registration authorities for
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
set of two letter country codes, or numeric country codes in
3166.
3.1.2. Administration Management Domain (ADMD
The values of the ADMD field are decided on a national basis.
national decision made within the GO-MHS community shall be
by a GO-MD
Hagens & Hansen [Page 6]
RFC 1649 X.400 Management in GO-MHS July 1994
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
subscribed PRMD or ADMD if there is no PRMD. For clarification,
following situation is legal
1) C=FI; ADMD=FUMAIL; O=FUNET
2) C=FI; ADMD=FUMAIL; PRMD=NOKIA; O=FUNET
In this case 1) and 2) are different addreses. (Note that 2) at
point is a hypotethical address). O=FUNET is a subscriber both
ADMD=FUMAIL, 1), and at PRMD=NOKIA, 2).
3.1.5. Organizational Units (OUs
If used, a unique hierarchy of OUs shall be implemented. The
level OU is unique within the scope of the immediately
address element (i.e., Organization, PRMD or ADMD). Use of
OUs may be confusing
3.1.6. Given Name, Initials, Surname (G I S
Each Organization can define its own Given-names, Initials,
Surnames to be used within the Organization. In the cases
Surnames are not unique within an O or OU, the Given-name and/
Initial shall be used to identify the Originator/Recipient. In
rare cases when more than one user would have the same combination
G, I, S under the same O and/or OUs, each organization is free
find a practical solution, and provide the users with unique O/
addresses
Either one of Given-name or Initials should be used, not both
Periods shall not be used in Initials
To avoid problems with the mapping of the X.400 addresses to RFC-822
addresses, the following rules might be used. ADMD, PRMD, O, and
values should consist of characters drawn from the alphabet (A-Z),
digits (0-9), and minus. Blank or Space characters should
avoided. No distinction is made between upper and lower case.
last character shall not be a minus sign or period. The
character should be either a letter or a digit (see reference [6]
[7]).
Hagens & Hansen [Page 7]
RFC 1649 X.400 Management in GO-MHS July 1994
3.1.7. Domain Defined Attributes (DDAs
The GO-MHS Community shall allow the use of domain
attributes. Note: Support for DDAs is mandatory in the
profiles, and all software must upgrade to support DDAs.
following DDAs shall be supported by a GO-MD
"RFC-822" - defined in reference [3].
The following DDAs should be supported by a GO-MD
"COMMON" - defined in reference [2].
3.2. X.400 88 -> 84
The requirements in reference [2] should be implemented in GO-
3.3. X.400 / RFC-822 address
All GO-MHS Community end-users shall be reachable from all end-
in the RFC-822 mail service in the Internet (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
according to reference [3].
3.3.1. Specification of RFC-822 Addresses seen from the X.400
Two scenarios are described
A. The RFC-822 end-user belongs to an organization with no
X.400 standard attribute address space
B. The RFC-822 end-user belongs to an organization with a
X.400 standard attribute address space
Organizations belong to scenario B if their X.400 addresses
registered according to the requirements in section 3.1.
3.3.1.1. An Organization with a defined X.400 Address
An RFC-822 address for an RFC-822 mail user in such an
shall be in the same address space as a normal X.400 address
X.400 users in the same organization. RFC-822 addresses and X.400
addresses are thus sharing the same address space. Example
Hagens & Hansen [Page 8]
RFC 1649 X.400 Management in GO-MHS July 1994
University of Wisconsin-Madison is registered under C=US
ADMD=Internet; PRMD=XNREN; with O=UW-Madison and they are using OU=
to address end-users in the CS-department. The RFC-822 address
RFC-822 mail users in the same department is: user@cs.wisc.edu
An X.400 user in the GO-MHS Community will address the RFC-822
user at the CS-department with the X.400 address
C=US; ADMD=Internet; PRMD=xnren; O=UW-Madison; OU=cs; S=user
This is the same address space as is used for X.400 end-users in
same department
3.3.1.2. An Organization with no defined X.400 Address
RFC-822 addresses shall be expressed using X.400 domain
attributes. The mechanism used to define the RFC-822 recipient
vary on a per-country basis
For example, in the U.S., a special PRMD named "Internet" is
to facilitate the specification of RFC-822 addresses. An X.400
can address an RFC-822 recipient in the U.S. by constructing an X.400
address such as
C=us; ADMD=Internet; PRMD=Internet; DD.RFC-822=user(a)some.place.edu
The first part of this address
C=us; ADMD=Internet; PRMD=Internet
denotes the U.S. portion of the Internet community and not a
"gateway". The 2nd part
DD.RFC-822=user(a)some.place.
is the RFC-822 address of the RFC-822 mail user after substitution
non-printable characters according to reference [3]. 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
RFC-822 user as
C=IT; ADMD=MASTER400; DD.RFC-822=user(a)some.place.
In the UK, an X.400 user would refer to an RFC-822 user as
Hagens & Hansen [Page 9]
RFC 1649 X.400 Management in GO-MHS July 1994
C=GB; ADMD= ; PRMD=UK.AC; O=MHS-relay; DD.RFC-822=user(a)some.place.
3.3.2. Specification of X.400 Addresses seen from the RFC-822
If an X.400 organization has a defined RFC-822 address space, RFC-822
users will be able to address X.400 recipients in RFC-822/
terms. This means that the address of the X.400 user, seen from
RFC-822 user, will generally be of the form
Firstname.Lastname@some.place.
where the some.place.edu is a registered Internet domain
This implies the necessity of maintaining and distributing
mapping tables to all participating RFC-1327 gateways. The
tables shall be globally consistent. Effective mapping
coordination procedures are needed
If an organization does not have a defined RFC-822 address space,
escape mapping (defined in reference [3]) shall be used. In
case, the address of the X.400 user, seen from an RFC-822 user,
be of the form
"/G=Firstname/S=Lastname/O=org name/PRMD=foo/ADMD=bar/C=us/"@
some.gateway.
Note that reference [7] specifies that quoted left-hand
addresses must be supported and that these addresses may be
than 80 characters long
This escape mapping shall also be used for X.400 addresses which
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 the
registration entity for such registrations. This will minimize
number of addresses which must use the escape mapping
If the escape mapping is not used, RFC-822 users will not see
difference between an Internet RFC-822 address and an address in
GO-MHS Community. For example
The X.400 address
C=us; ADMD=ATTMail; PRMD=CDC; O=CPG; S=Lastname; G=Firstname
will from an RFC-822 user look like
Hagens & Hansen [Page 10]
RFC 1649 X.400 Management in GO-MHS July 1994
Firstname.Lastname@cpg.cdc.
3.4. Routing
To facilitate routing in the GO-MHS Community before an X.500
infrastructure is deployed, the following two documents, a RELAY-
document and a Domain document, are defined. These documents
formally defined in reference [1]. The use of these documents
necessary to solve the routing crisis that is present today. However
this is a temporary solution that will eventually be replaced by
use of X.500.
The RELAY-MTA document will define the names of RELAY-MTAs and
associated connection data including selector values, NSAP addresses
supported protocol stacks, and supported X.400 protocol version(s).
Each entry in the Domain document consists of a sub-tree hierarchy
an X.400 address, followed by a list of MTAs which are willing
accept mail for the address or provide a relay service for it.
MTA name will be associated with a priority value. Collectively,
list of MTA names in the Domain document make the given
reachable from all protocol stacks. In addition, the list of MTAs
provide redundant paths to the address, so in this case, the
value indicates the preferred path, or the preferred order in
alternative routes should be tried
The RELAY-MTA and Domain documents are coordinated by the
specified in the Community document. The procedures for
information gathering and distribution, are for further study
3.5. Minimum Statistics/
The following are not required for all MTAs. The information
provided as guidelines for MTA managers. This is helpful
observing service use and evaluating service performance
This section defines the data which should be kept by each MTA
There are no constraints on the encoding used to store the
(i.e., format).
For each message/report passing the MTA, the following
should be collected
Hagens & Hansen [Page 11]
RFC 1649 X.400 Management in GO-MHS July 1994
The following fields should be collected
Local MTA
The following fields are conditionally collected
From MTA Name (fm
To MTA Name (tm
Delta Time (dt
Message-id (id
At least one of 'fm' and 'tm' should be present. If one of 'fm'
'tm' is not present, 'id' should be present. If both 'fm' and 'tm
are present, then 'dt' indicates the number of minutes that
message was delayed in the MTA. If 'id' cannot be mapped
because of log file formats, 'id' is not present and every
creates two lines: one with 'fm' empty and one with 'tm' empty.
this case, 'date' and 'time' in the first line represent the date
time the message entered the MTA. In the second line, they
the date and time the message left the MTA
The following fields are optionally collected
From Domain (fd
To Domain (td
For route tracing, 'fd' and 'td' are useful. They represent X.400
OU's, O, PRMD, ADMD and C and may be supplied up to any level
detail
4. Community
For the GO-MHS community there will exist one single
document containing basic information as defined in reference [1].
First the contact information for the central coordination point
be found together with the addresses for the file server where
the documents are stored. It also lists network names and stacks
be used in the RELAY-MTA and DOMAIN documents. The GO-MHS
must agree on its own set of mandatory and optional networks
stacks
Hagens & Hansen [Page 12]
RFC 1649 X.400 Management in GO-MHS July 1994
5. Security
Security issues are not discussed in this memo
6. Authors'
Robert
Advanced Network & Services, Inc
1875 Campus Commons
Suite 220
Reston, VA 22091
U.S.A
Phone: +1 703 758 7700
Fax: +1 703 758 7717
EMail: hagens@ans.
DDA.RFC-822=hagens(a)ans.net; P=INTERNET; C=
Alf
Elgesetergt. 10
Postbox 6883,
N-7002
Phone: +47 7359 2982
Fax: +47 7359 6450
EMail: Alf.Hansen@uninett.
G=Alf; S=Hansen; O=uninett; P=uninett; C=
Hagens & Hansen [Page 13]
RFC 1649 X.400 Management in GO-MHS July 1994
[1] Eppenberger, U., Routing Coordination for X.400 MHS-
Within a Multi Protocol / Multi Network Environment, RFC 1465,
SWITCH, May 1993.
[2] Hardcastle-Kille, S., "X.400 1988 to 1984 downgrading, RFC 1328,
University College London, May 1992.
[3] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
and RFC 822, RFC 1327, May 1992.
[4] Cargille, A., "Postmaster Convention for X.400 Operations",
1648, University of Wisconsin, July 1994.
[5] International Telecommunications Union, CCITT.
Communications Networks, Volume VIII, Message Handling Systems
ITU: Geneva 1985.
[6] Harrenstien, K., Stahl, M., and E. Feinler, "DOD Internet
Table Specification", RFC 952, SRI, October 1985.
[7] Braden, R., "Requirements for Internet Hosts -- Application
Support", STD 3, RFC 1123, USC/Information Sciences Institute
October 1989.
Hagens & Hansen [Page 14]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
