As per Relevance of the word community, we have this rfc below:
Network Working Group H.
Request for Comments: 1802
Category: Informational K.
Control Data
S.
Electricite de
J.
June 1995
Introducing Project Long Bud
Internet Pilot Project for the Deployment of X.500
Information in Support of X.400
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
The Internet X.400 community (i.e., GO-MHS) currently lacks
distributed mechanism providing dynamic updating and management
message routing information. The IETF MHS-DS Working Group
specified an approach for X.400 Message Handling Systems to
message routing using OSI Directory Services. The MHS-DS
has been successfully tested in a number of local environments
This memo describes a proposed Internet Pilot Project that seeks
prove the MHS-DS approach on a larger scale. The results of
pilot will then be used to draw up recommendations for a
deployment
1.
The 1988 edition of X.400 introduces, among other extensions
revisions, the concept of O/R Names which assumes the existence of
widely available Directory Service. This Directory Service is
to support several MHS operations (support for names to
senders and receivers of messages in a user-friendly fashion,
for distribution lists, authentication of MHS components,
of MHS components capabilities...).
The prime advantage of Directory Names, as perceived by many users
was to release users from the remembering of complex O/R
for their correspondents
Alvestrand, et al Informational [Page 1]
RFC 1802 Introducing Project Long Bud June 1995
In the MHS infrastructure, as compared to other protocols, a name
itself does not contain enough information to allow the
Transfer Agents (MTAs) to route a message to the User Agent (UA
servicing this name. The routing process is based on
provided by different MHS Management Domains, whether they are
or private
An MHS community combines several administrative MHS domains
which agreements for cooperative routing exist: the GO-MHS
is the set of MTA's taking care of X.400 mail operations on
Internet [RFC 1649].
In the absence of a distributed Directory Service, an
technique has been developed within the GO-MHS community to
and advertise routing information. This resulted in an
IETF protocol [RFC 1465].
2.
A number of routing problems are preventing the present
X.400 service from expanding its number of participating
transfer agents to a global scale. The two most critical
are
* The present mechanism of centrally maintained and
MTA routing tables has been optimized as far as possible
Increasing the number of directly connected MTAs increases
the workload on the MHS managers. The current solution
not scale. Routing must be a fully dynamic and
process
* Manual propagation and installation of routing tables do
guarantee consistency of routing information (even in a
fashion) when it is accessed by different MTAs scattered
the globe
It is commonly accepted that a distributed mechanism providing
dynamic updating and management of X.400 routing information
highly desirable. The focus of the project is to establish X.500-
based support of X.400 routing, at a very large scale
3.
Using the Directory as a dynamic means of information storage
advertisement will guarantee participants in Project Long Bud
their updated data are globally available to the community. As
direct consequence of the above, a participating MHS manager will
released from configuring connections to the other participants
Alvestrand, et al Informational [Page 2]
RFC 1802 Introducing Project Long Bud June 1995
Directory-capable MTAs will be able to discover more optimal and
direct routes to X.400 destinations than are practical today.
will enable faster delivery of messages
The infrastructure reliability will be improved: the
stored in the Directory will allow automatic use of
connections in case of remote MTA or network problems. X.400
managers in the GO-MHS Community should then be released from
need to know the complexity of the whole mail routing infrastructure
Providing a dynamic routing infrastructure will
inconsistencies introduced by unsynchronized static tables
improve quality of service
Furthermore, besides the robustness and the optimization of the
routing infrastructure, the Long Bud approach should bring to
participating organizations better control over how they
and maintain their interconnection with the GO-MHS community
Participants will share in building an X.400 network which can
to a very large scale. They will develop experience using a
messaging architecture which scales well and requires
administrative overhead. They will be able to discuss
with the MHS-DS experts and architects in the ongoing
development cycle
4. Definition of project LONG
The Long Bud pilot wishes to demonstrate that the X.500 Directory
able to provide a global-scale service to messaging applications
Although MHS-DS provides ways to use private routing trees, Long
will focus on the Open Community Routing Tree as used by the GO-
community
4.1 Project
Project Long Bud has the following goals
* Gather pilot experience of the defined framework for X.500
support of MTA routing, as defined by the IETF MHS-DS
Group [Kille 94].
* Actively investigate migration of the existing
X.400 service from a routing method based upon distribution
centrally maintained static tables, as specified in [RFC 1465],
to a method based instead upon X.500:
Alvestrand, et al Informational [Page 3]
RFC 1802 Introducing Project Long Bud June 1995
-- Deploy X.400 MTAs which are directly capable of
routing information from the X.500 Directory,
compliance with the specifications of the MHS-DS
Group. This type of MTA is called a directory-
MTA
-- Deploy tools which read routing information from the X.500
Directory and use it to generate static routing tables
MTAs which are not directory-capable
* specify a set of minimal operational requirements needed
X.500-based routing of X.400 messages can be widely deployed
4.2
The first phase of Project Long Bud consists in deploying a
number of directory-capable MTAs operated by members of the MHS-
Working Group and GO-MHS community. These MTAs must be capable
using information in the X.500 directory to route messages to
other members of the project as well as to the existing GO-
community. As of this writing, an initial set of MTAs is
operational
At the end of this phase, the following goals should be achieved
* The X.500 DIT must be populated with enough routing
to allow the participating MTAs to route reliably messages
each other and to the existing GO-MHS community
* The X.500 DSAs holding the routing information must operate
a quality of service that is acceptable for an
X.400 service
As a prerequisite, a sufficient number of MTA managers must
willing to participate in Project Long Bud for the first set
results to be significant. Support for a protocol stack
to [RFC 1006] is mandatory. All MTAs participating in the Long
pilot need to register in the Open Tree and must be prepared
accept connections from anyone
Note that in the first phase, default routes will be established
the DIT such that messages addressed to destinations outside of
Long Bud community will be routed to designated MTAs in the GO-
community. This will allow for full connectivity between the
Bud community and the GO-MHS community which are related,
distinct communities. Interworking between these two must
established and coordinated
Alvestrand, et al Informational [Page 4]
RFC 1802 Introducing Project Long Bud June 1995
In the second phase of Project Long Bud, a greater number of
should be added to the experiment. Cooperation with non directory
capable communities must be addressed
4.3 General
No large scale resources have been committed to this project. Yet
expedient deployment is desirable. Therefore, the pilot
needs to be focused and relatively short-lived. The general
for satisfying these requirements includes
* Use as many existing MHS-DS tools as possible. Also,
to track the progress of tools being developed by
members and facilitate their deployment as soon as they
ready
* Coordinate efforts with existing GO-MHS community service
* Establish a core infrastructure: 4 DSAs (two in the
States and two in Europe) are set up to serve MHS-
information
* Wherever it is technically feasable, DSA managers
establish bilateral agreements with one (or more) of the
DSAs in order to duplicate their routing information.
example, the core DSAs support the replication
specified in [RFC 1275] as a duplication technique
* the Long Bud pilot needs to cooperate actively with
NameFlow (the continuation of the PARADISE Pilot) and
directory providers in order to promote stability
consistency of informations
4.4 Tools
To facilitate widespread deployment of MHS-DS routing technology
to foster interworking between directory-capable MTAs and MTAs
are not directory-capable, tools providing the
functionalities need to be developed
populate the Directory with routing information: such a tool
accept routing information specified in the standard
used by the GO-MHS community (see [RFC 1465]) as input, and
will load or update entries which convey the same
in the X.500 Directory
Alvestrand, et al Informational [Page 5]
RFC 1802 Introducing Project Long Bud June 1995
downloading of routing information from the Directory: in order
provide a migration path for organizations not
directory-capable MTAs, a tool is needed which will read X.400
routing information from the X.500 Directory and
static routing information from it. The syntax of the
information generated will conform to the syntax defined by
GO-MHS community, so that "classical" MTAs run as
currently do
displaying route taken by a message between two end-points:
tool should accept two parameters as input: the X.500
distinguished name of an MTA, and an X.400 O/R name. It
display the possible routes which may be taken in order
deliver a message from the specified MTA to the specified X.400
destination. This tool looks very much the same as
traceroute facility used at the IP level
These tools must use standard protocols to access the Directory (
as DAP [CCITT 88] or LDAP [RFC 1487]). Portability is encouraged
A note on
Pilot use of this Directory information depends heavily on
quality and availability. Although the administration of
availability and global Directory data accuracy are not in the
of Long Bud, care must be taken that Directory resources used by
Bud participants are administrated well
If they have the technical ability to do so, Long Bud
are encouraged to replicate routing information in their Directory
improve data availability
Directory data used by the pilot must be accurate: solutions to
problem will be recommanded as the project matures
5. Participation
The existing operational X.400 service, the GO-MHS service, uses
following method to distribute and manage X.400 routing information
A group of MTAs is organized into a routing community. The
keeps its routing information up to date by assigning to each
manager the responsibility of determining the routing information
his/her MTA, formalizing this routing information in the
defined by the community and sending the result to the GO-
coordination service. Once the information has been
against the other data provided by all managers in the community,
coordination service will advertise it to the whole community.
manager will then have to update his/her MTA configuration with
Alvestrand, et al Informational [Page 6]
RFC 1802 Introducing Project Long Bud June 1995
verified information
The purpose of Project Long Bud is to allow a manager to operate
MTA without having to perform ANY manual steps when another
manager adds new or changes existing routing information. This
facilitate efficient, dynamic, and manageable interconnection of
large communities of MTAs. It will allow the Internet X.400
community to overcome the limitations in scalability which it
currently encountering
5.1 Prerequisites for
The prerequisites for joining Project Long Bud are
Step 1: Participants in the pilot must have a good knowledge
the IETF MHS-DS Working Group activities and documents
1. Participants must join the MHS-DS distribution list
RFC-822: mhs-ds@mercury.udev.cdc.
X.400: PN=mhs-ds; OU=mercury; OU=OSS
OU=ARH; O=CPG; P=CDC; A=ATTMail; C=
Requests to join the MHS-DS distribution list may be
to the following email address
RFC-822: mhs-ds-request@mercury.udev.cdc.
X.400: PN=mhs-ds-request; OU=mercury; OU=OSS
OU=ARH; O=CPG; P=CDC; A=ATTMail; C=
2. Participants must retrieve and become familiar with
relevant tools and documents stored on the Project
Bud anonymous FTP
Host name: ftp.css.cdc.
Directory: pub/mhs-ds/long-
In particular, openly available software related to
Bud activities will be kept up-to-date at this location
Alvestrand, et al Informational [Page 7]
RFC 1802 Introducing Project Long Bud June 1995
3. If not already done, participants must do one of
following
* Upgrade their X.400 and X.500 software such that
supports the MHS-DS specifications as in [Kille 94].
* Use the tools which extract MHS-DS information
the directory and generate whatever
configuration files are necessary to allow local MTA'
to use the information. This should be
frequently (at least once per day).
Step 2: Participants must register required entries in
Directory so that their MTA(s) is (are) known to
Directory
1. Arrange with the appropriate DSA Manager (who can be
local manager if the DSA is run by the
organization, or a manager who is in charge of running
organization's DSA) to create an entry for the
MTA(s) involved in the pilot. At this stage,
connection information is required
2. Check, test and verify the connection information with
least one other participant. The mhs-ds distribution
should be used for announcing the new registration
asking volunteers for testing
3. Participants must establish sensible default X.400
to existing GO-MHS destinations for which X.500-
routing information will not exist initially
Step 3: Participants can then enter their routing information
the Directory
1. Before any routing is entered in the DIT,
must check with the GO-MHS Coordination Service that
routes they want to register can be properly handled
the GO-MHS community (contact information
mailflow@mailflow.dante.net). It is crucial for the
that any routing information entered in the Directory
kept carefully accurate if the experiment is to
meaningful. Participants may also consider the need
mapping rules (see [RFC 1465] for details).
2. Once the above step is validated by the GO-
Coordination Service, participants must record
information for their MTA(s) in the Internet X.500
Alvestrand, et al Informational [Page 8]
RFC 1802 Introducing Project Long Bud June 1995
directory service. This requires that a participant
the following
* Arrange with the appropriate DSA Manager (who can
either a local manager if the DSA is run by
participating organization or a manager which is
charge of running the organization's DSA) to
X.400 routing information in a routing tree held
the participating organization. This routing
should contain all necessary information for the
mail domain
* Check, test and verify the registered
information with at least one other participant.
mhs-ds distribution list should be used for
the new registration and asking volunteers
testing
3. If a participant adds new nonleaf entries to the
Community Routing Tree, then s/he must find at least
other participant who will maintain a slave copy of
children of the nonleaf entry. Send email to the mhs-
distribution list in order to find a partner who
willing to do this
4. If a participant adds new nonleaf ADMD or PRMD entries
the directory, then s/he must contact the managers of
Long Bud core DSA's and arrange to provide slave copies
the children of the ADMD and/or PRMD entries to all of
core DSA's. Send email to the mhs-ds distribution list
order to contact the core DSA managers
5. Once the above testing is completed, send email to
mhs-ds distribution list announcing the establishment
new X.500-based routes
6. Notes on side
The Long Bud Pilot Project, with its specific scope, is
a new direction in X.500 service usage. This should facilitate
expedite the global deployment of X.500 on the Internet
Once the routing infrastructure illustrated by the Long
experiment is in place, the routing process will be able to take
account additional information to improve quality of
(minimizing messages conversions, enforcing various security
established by MHS domains, taking advantage of recipients'
capabilities stored in the Directory, ...). While the Open
Alvestrand, et al Informational [Page 9]
RFC 1802 Introducing Project Long Bud June 1995
provides global connectivity, multiple private routing trees
the use of various routing trees
7.
The authors would like to thank Urs Eppenberger (SWITCH) and
Cargille (University of Wisconsin) for their constructive comments
earlier drafts of this document
[CCITT 88] International Telegraph and
Consultative Committee. X.500
series. December 1988.
[RFC 1649] Hagens, R., and A. Hansen, "
Requirements for X.400 Management Domains in
GO-MHS Community", RFC 1649, ANS, UNINETT
July 1994.
[Kille 94] Kille, S., "MHS Use of the X.500 Directory
Support MHS Routing", RFC 1801, ISODE Consortium
June 1995.
[RFC 1006] Rose, M., and D. Cass, "ISO Transport Service
top of the TCP Version: 3", STD 35, RFC 1006,
Northrop Research and Technology Center
May 1987.
[RFC 1275] Hardcastle-Kille, S., "Replication
to provide an Internet Directory using X.500",
RFC 1275, University College London
November 1991.
[RFC 1465] Eppenberger, U., "Routing Coordination for X.400
MHS Services Within a Multi Protocol /
Network Environment Table Format V3 for
Routing", RFC 1465, SWITCH, May 1993.
[RFC 1487] Yeong, W., Howes, T., and S. Kille, "X.500
Lightweight Directory Access Protocol",
RFC 1487, Performance Systems International
University of Michigan, ISODE Consortium
July 1993.
Alvestrand, et al Informational [Page 10]
RFC 1802 Introducing Project Long Bud June 1995
8. Security
Security issues are not discussed in this memo
Authors'
Harald T.
P.O. box 6883
N-7002 Trondheim,
Phone: +47-73-59-70-94
EMail: Harald.T.Alvestrand@uninett.
Kevin E.
Control Data Systems, Inc
4201 Lexington Avenue
Arden Hills, MN 55126,
Phone: +1-612-482-6835
EMail: Kevin.E.Jordan@cdc.
Sylvain
Electricite de
Direction des Etudes et
1, avenue du General de
92141 Clamart Cedex,
Phone: +33-1-47-65-44-02
EMail: Sylvain.Langlois@der.edf.
James A.
NetConsult
Morgenstrasse 129 3018 Bern,
Phone: +41-31-9984141
EMail: Romaguera@NetConsult.
X.400: S=Romaguera;O=NetConsult;P=switch;A=arcom;C=
Alvestrand, et al Informational [Page 11]
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
