Introducing Project Long Bud: Internet Pilot Project for the Deployment of X.500 Directory Information in Support of X.400 Routing
RFC 1802

Document Type RFC - Informational (June 1995; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1802 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                      H. Alvestrand
Request for Comments: 1802                                       UNINETT
Category: Informational                                        K. Jordan
                                                    Control Data Systems
                                                             S. Langlois
                                                   Electricite de France
                                                            J. Romaguera
                                                              NetConsult
                                                               June 1995

                     Introducing Project Long Bud:
      Internet Pilot Project for the Deployment of X.500 Directory
                Information in Support of X.400 Routing

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   The Internet X.400 community (i.e., GO-MHS) currently lacks a
   distributed mechanism providing dynamic updating and management of
   message routing information.  The IETF MHS-DS Working Group has
   specified an approach for X.400 Message Handling Systems to perform
   message routing using OSI Directory Services.  The MHS-DS approach
   has been successfully tested in a number of local environments.

   This memo describes a proposed Internet Pilot Project that seeks to
   prove the MHS-DS approach on a larger scale.  The results of this
   pilot will then be used to draw up recommendations for a global
   deployment.

1. Background

   The 1988 edition of X.400 introduces, among other extensions or
   revisions, the concept of O/R Names which assumes the existence of a
   widely available Directory Service.  This Directory Service is needed
   to support several MHS operations (support for names to identify
   senders and receivers of messages in a user-friendly fashion, support
   for distribution lists, authentication of MHS components, description
   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 Addresses
   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 by
   itself does not contain enough information to allow the Message
   Transfer Agents (MTAs) to route a message to the User Agent (UA)
   servicing this name.  The routing process is based on information
   provided by different MHS Management Domains, whether they are public
   or private.

   An MHS community combines several administrative MHS domains among
   which agreements for cooperative routing exist:  the GO-MHS community
   is the set of MTA's taking care of X.400 mail operations on the
   Internet [RFC 1649].

   In the absence of a distributed Directory Service, an interim
   technique has been developed within the GO-MHS community to collect
   and advertise routing information.  This resulted in an experimental
   IETF protocol [RFC 1465].

2. Rationale

   A number of routing problems are preventing the present Internet
   X.400 service from expanding its number of participating message
   transfer agents to a global scale.  The two most critical problems
   are:

      * The present mechanism of centrally maintained and advertized
        MTA routing tables has been optimized as far as possible.
        Increasing the number of directly connected MTAs increases also
        the workload on the MHS managers.  The current solution does
        not scale.  Routing must be a fully dynamic and distributed
        process.

      * Manual propagation and installation of routing tables do not
        guarantee consistency of routing information (even in a loose
        fashion) when it is accessed by different MTAs scattered across
        the globe.

   It is commonly accepted that a distributed mechanism providing for
   dynamic updating and management of X.400 routing information is
   highly desirable.  The focus of the project is to establish X.500-
   based support of X.400 routing, at a very large scale.

3. Benefits

   Using the Directory as a dynamic means of information storage and
   advertisement will guarantee participants in Project Long Bud that
   their updated data are globally available to the community.  As a
   direct consequence of the above, a participating MHS manager will be
   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 more
   direct routes to X.400 destinations than are practical today.  This
Show full document text