rfc1330.txt

RFC 的详细文档！

   complete replacement of all information must be supplied to the ESnet
   DSA manager before the next update cycle.  More detailed information
   and a sample of a site-supplied data file can be found in Appendix D.

2.8.  ESnet Running a Level-0 DSA for c=US

   For ESnet to provide high quality X.500 services to the ESnet
   community, the ESnet DSAs must operate as Level-0 (first level) DSAs.
   It is currently planned that these DSAs will act as slave, Level-0
   DSAs to PSI's master, Level-0 DSAs.  Once the ESnet DSAs are in



ESCC X.500/X.400 Task Force                                    [Page 20]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   production service, it is recommended that directly connected ESnet
   backbone sites operating their own X.500 DSAs configure them with one
   of the ESnet DSAs as their parent DSA.  This provides several
   advantages to the ESnet community:

   1.  The ESnet DSAs will be monitored by the NERSC's 24-hour
       Operations Staff.  Additionally, ESnet plans to deploy two
       (2) DSAs in geographically disperse locations to ensure
       reliability and availability.

   2.  All queries to Level-0 DSAs remain within the ESnet high-speed
       backbone.

   3.  If network connectivity is lost to all external Level-0 DSAs,
       X.500 Level-0 connectivity will still exist within the ESnet
       backbone.

2.9.  X.500 Registration Requirements

   X.500 organization names must be nationally unique if they appear
   directly below the c=US level in the DIT structure.  Nationally
   unique names must be registered through an appropriate registration
   authority, i.e., one which grants nationally unique names.

   X.500 organizational unit names need to be unique relative to the
   node directly superior to them in the DIT.  Registration of these
   names should be conducted through the "owner" of the superior node.

   The registration of X.500 names below the organization level are
   usually a local matter.  However, all siblings under a given node in
   the DIT must have unique RDNs.

   See Section 4 for a more complete description of OSI registration
   issues and procedures.

2.10.  Future X.500 Issues to be Considered

2.10.1.  ADDMDS Interoperating with PRDMDS

   This is a problem which currently does not have an answer.  The issue
   of Administrative Directory Management Domains (ADDMDs) interacting
   with Private Directory Management Domains (PRDMDs) is just beginning
   to be investigated by several groups interested in solving this
   problem.

2.10.2.  X.400 Interaction with X.500

   The current level of understanding is that X.400 can benefit from the



ESCC X.500/X.400 Task Force                                    [Page 21]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   use of X.500 in two ways:

   1.  Lookup of message recipient information.

   2.  Lookup of message routing information.

   X.400 technology and products, as they stand today, do not support
   both of these features in a fully integrated fashion across multiple
   vendors.  As the standards and technology evolve, consideration will
   have to be given in applying these new functions to the production
   ESnet X.500/X.400 services environment.

2.10.3.  Use of X.500 for NIC Information

   Work is currently being performed in the IETF to place NIC
   information on-line in an Internet-based X.500 service.

2.10.4.  Use of X.500 for Non-White Pages Information

   The PSI White Pages Pilot Project has caused increasing and popular
   use of X.500 as a white pages services within the Internet community.
   However, the X.500 standard provides for much more than just this
   service.  Application processes, devices and security objects are
   just a few of the objects to be considered for future incorporation
   in the global X.500 database.

2.10.5.  Introduction of New X.500 Implementations

   Thought will have to be given to the use of commercial X.500 products
   in the future as QUIPU (the implementation recommended in this paper)
   may not meet all of the needs of the ESnet community.  As commercial
   products mature and become stable, they will have to be incorporated
   into the ESnet X.500 service in a way which ensures interoperability
   and reliability.

2.10.6.  Interaction of X.500 and DECdns

   There is every indication that DECdns and X.500 will interoperate in
   some fashion in the future.  Since there is an evolving DECdns
   namespace (i.e.  OMNI) and an evolving X.500 DIT (i.e. NADF), some
   consideration should be given to how these two name trees will
   interact.  All of this will be driven by the Digital Equipment
   Corporation's decisions on how to expand and incorporate its DECdns
   product with X.500.







ESCC X.500/X.400 Task Force                                    [Page 22]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


3.  X.400 - OSI Message Handling Services

3.1.  Brief Tutorial

   In 1984 CCITT defined a set of protocols for the exchange of
   electronic messages called Message Handling Systems (MHS) and is
   described in their X.400 series of recommendations.  ISO incorporated
   these recommendations in their standards (ISO 10021).  The name used
   by ISO for their system was MOTIS (Message-Oriented Text Interchange
   Systems).  In 1988 CCITT worked to align their X.400 recommendations
   with ISO 10021.  Currently when people discuss messaging systems they
   use the term X.400.  These two systems are designed for the general
   purpose of exchanging electronic messages in a store and forward
   environment.  The principle use being made of this system today is to
   support electronic mail.  This section will give an overview of X.400
   as used for electronic mail.  In the following sections, the term
   X.400 will be used to describe both the X.400 and MOTIS systems.

   The basic model used by X.400 MHS is that of a Message Transfer
   System (MTS) accessed via a User Agent (UA).  A UA is an application
   that interacts with the Message Transfer System to submit messages on
   behalf of a user.  A user is referred to as either an Originator
   (when sending a message) or a Recipient (when receiving one).  The
   process starts out when an Originator prepares a message with the
   assistance of their UA.  The UA then submits the message to the MTS
   for delivery.  The MTS then delivers the message to one or more
   Recipient UAs.

                    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
       ______      |      _______          _______     |     ______
      |      |     | MTS |       |        |       |    |    |      |
      |  UA  |<----|---->|  MTA  |<------>|  MTA  |<---|--->|  UA  |
      |______|     |     |_______|        |_______|    |    |______|
                   |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|

   The MTS provides the general store-and-forward message transfer
   service. It is made up of a number of distributed Message Transfer
   Agents (MTA).  Operating together, the MTAs relay the messages and
   deliver them to the intended recipient UAs, which then makes the
   messages available to the recipient (user).

   The basic structure of an X.400 message is an envelope and content
   (i.e.  message).  The envelope carries information to be used when
   transferring the message through the MTS.  The content is the piece
   of information that the originating UA wishes delivered to the
   recipient UA.  There are a number of content types that can be
   carried in X.400 envelopes.  The standard user message content type
   defined by X.400 is called the Interpersonal (IP) message.  An IP



ESCC X.500/X.400 Task Force                                    [Page 23]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   message consists of two parts, the heading and body.  The heading
   contains the message control information. The body contains the user
   message.  The body may consist of a number of different body parts.
   For example one IP message could carry voice, text, Telex and
   facsimile body parts.

   The Management domain (MD) concept within the X.400 recommendations
   defines the ownership, operational and control boundary of an X.400
   administration.  The collection consisting of at least one MTA and
   zero or more UAs owned by an organization or public provider
   constitutes a management domain (MD).  If the MD is managed by a
   public provider it is called an Administration Management Domain
   (ADMD).  The MD managed by a company or organization is called a
   Private Management Domain (PRMD).  A Private MD is considered to
   exist entirely within one country.  Within that country a PRMD may
   have access to one or more ADMDs.

   Each MD must ensure that every user (i.e UA) in the MD has at least
   one name.  This name is called the Originator/Recipient (O/R) Name.
   O/R Names are constructed from a set of standard attributes:

   o  Country Name

   o  Administration Management Domain

   o  Private Management Domain

   o  Organization Name

   o  Organizational Unit Name

   o  Surname

   o  Given name

   o  Initials

   o  Generational Qualifier

   An O/R name must locate one unambiguous O/R UA if the message is to
   be routed correctly through the Message Transfer Service.  Currently
   each MD along the route a message takes determines the next MD's MTA
   to which the message should be transferred.  No attempt is made to
   establish the full route for a message, either in the originating MD
   or in any other MD that acquires the store and forward responsibility
   for the message.

   Messages are relayed by each MD on the basis of the Management domain



ESCC X.500/X.400 Task Force                                    [Page 24]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   portion of their O/R Name until arrival at the recipient MD.  At
   which point, the other attributes in the name are used to further
   route to the recipient UA.  Internal routing within a MD is the
   responsibility of each MD.

3.2.  ESnet X.400 Logical Backbone

   Currently within the ESnet community message handling services are
   implemented with a number of different mail products, resulting in
   what is classically known as an "n-squared" problem.  For example,
   let's say that LLNL only uses QuickMail on site, PPPL only uses
   MAIL-11 (VMS MAIL), and CEBAF only uses SMTP mail.  For LLNL to send
   mail to PPPL and CEBAF, is must support MAIL-11 and SMTP locally on-
   site.  Likewise for PPPL to send mail to LLNL and CEBAF, it must
   support MAIL-11 and QuickMail locally.  Identically, this scenario
   exists for CEBAF.

   To alleviate this problem, a logical X.400 backbone must be
   established through out the entire ESnet backbone.  Then, each ESnet
   backbone site will be responsible for only providing connectivity
   between it's local mail domains (QuickMail, MAIL-11, SMTP Mail, or
   even native X.400) and the logical X.400 backbone.  One of the long-
   term goals is to establish X.400 as the "common denominator" between
   directly connected ESnet backbone sites.

3.3.  Naming Structure

   The name-spaces for X.500 and X.400 are completely different and are
   structured to meet different needs.  The X.500 name-space is
   typically organized to allow quick, optimized searching; while the
   X.400 ORname is used to forward an X.400 message through several
   "levels" of MTAs (X.400 Message Transfer Agents).

   ESnet backbone sites will participate in the X.400 environment
   through one of two optio