rfc1649.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                          R. Hagens
Request for Comments: 1649             Advanced Network & Services, Inc.
Category: Informational                                        A. Hansen
                                                                 UNINETT
                                                               July 1994


         Operational Requirements for X.400 Management Domains
                        in the GO-MHS Community

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.

1.  Introduction

   There are several large, operational X.400 services currently
   deployed. Many of the organizations in these services 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 Global Open Message Handling System
   (GO-MHS) Community that has full interoperability with the existing
   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 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 GO-MHS Community 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 service
   provider.

   This document refers to other documents which are published as RFCs.
   These documents are [1], [2], [3], [4], [6] and [7] in the reference
   list.

   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.




Hagens & Hansen                                                 [Page 1]

RFC 1649               X.400 Management in GO-MHS              July 1994


   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 WG-MSG
   (former RARE WG1 (on MHS)).

1.1.  Terminology

   This document defines requirements, recommendations and conventions.
   Throughout the document, the following definitions apply: a
   requirement is specified with the word shall.  A recommendation is
   specified with the word should.  A 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

   Different communities have different profile requirements.  The
   following is a list of such profiles.

    o U.S. GOSIP - unspecified version
    o ENV - 41201
    o UK GOSIP for X.400(88)

   In the case when mail traffic is going from the RFC-822 mail service
   to the GO-MHS Community, the automatic return of contents when mail
   is non-delivered should be requested by RFC 1327 gateways and should
   be supported at the MTA that generates the non-delivery report.
   However, it should be noted that this practice maximizes the cost
   associated with delivery reports.

2.  Architecture of the GO-MHS Community

   In order to facilitate a coherent deployment of X.400 in the GO-MHS
   Community 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.

   The GO-MHS Community will operate as a single MHS community, as
   defined in reference [1].

2.1.  Management Domains

   The X.400 model supports connectivity between communities 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



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 different
   organizational policies for MDs.  All of these policies are legal
   according to the X.400 standard.  Currently, X.400 service providers
   in a country (inside or outside the GO-MHS Community), are organized
   as:

    a) One or several ADMDs.
    b) One or several PRMDs and with no ADMDs present in
       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 not
   possible to say which model is the most effective.  Thus, the GO-MHS
   Community shall allow every model.

2.2.  The RELAY-MTA

   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 recipient. The X.400 store and forward
   model permits a message 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 GO-MHS Community will require
   a well deployed directory infrastructure to support routing. In the
   GO-MHS Community X.500 is considered to be the best protocol for such
   an infrastructure.  In this environment, a routing decision can be
   made by searching the directory 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 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 a
   destination O/R address to a next hop MTA.  In order to facilitate
   efficient routing, one could build a table that contains information
   about every MTA in every MD.  However, this table would be enormous
   and very dynamic, so this is not feasible in practice.  Therefore, it
   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 an
   MD. The MTA that acts as a RELAY MTA for an MD shall be capable of



Hagens & Hansen                                                 [Page 3]

RFC 1649               X.400 Management in GO-MHS              July 1994


   accepting responsibility for all messages that it receives that are
   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 reference
   [1].

2.3.  Lower Layer Stack Incompatibilities

   A requirement for successful operation of the GO-MHS Community is
   that all users can exchange messages. The GO-MHS Community is not
   dependent on the traditional 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.

     -----------------------------------------------------
     !                                                   !
     !            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 Scenario





Hagens & Hansen                                                 [Page 4]

RFC 1649               X.400 Management in GO-MHS              July 1994


   PRMD A has three RELAY-MTAs which collectively provide support for
   the TP0/CONS/X.25, TP0/RFC1006, and TP4/CLNS stacks.  (Note: it is
   acceptable for a single RELAY-MTA to support more than one stack.
   Three RELAY-MTAs are shown in this figure for clarity.)  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 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 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 advertise to the world that it has made a
   bilateral agreement 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 available.

   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 reference [1] define this general purpose
   solution.  It is a requirement that all MDs follow the rules and
   policies defined by reference [1].

3.  Description of GO-MHS Community Policies

   A GO-MD is a Management Domain in the GO-MHS Community.

   The policies described in this section constitute a minimum set of
   common policies for GO-MDs. They are specified to ensure
   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 Registration

   An O/R address is a descriptive name for a UA that has certain
   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 reference [5], chapter 3.1.

   Uniqueness of X.400 addresses shall be used to ensure end-user
   connectivity.

   Mailboxes shall be addressed according to the description of O/R
   names, Form 1, Variant 1 (see reference [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, O, OU and PN names shall be present in an O/R address. At least
   one of PN and DDA shall be present.

   In general a subordinate address element shall be unique within the
   scope of its immediately superior element. An exception is PRMD, see
   section 3.1.3.  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)

   The values of the ADMD field are decided on a national basis.  Every
   national decision made within the GO-MHS community shall be supported
   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 the
   subscribed PRMD or ADMD if there is no PRMD.  For clarification, the
   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 this
   point is a hypotethical address). O=FUNET is a subscriber both at
   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 top
   level OU is unique within the scope of the immediately superior
   address element (i.e., Organization, PRMD or ADMD).  Use of multiple
   OUs may be confusing.

3.1.6.  Given Name, Initials, Surname (G I 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 shall 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 practical solution, and provide the users with unique O/R
   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 OU
   values should consist of characters drawn from the alphabet (A-Z),
   digits (0-9), and minus.  Blank or Space characters should be
   avoided.  No distinction is made between upper and lower case. The
   last character shall not be a minus sign or period.  The first
   character should be either a letter or a digit (see reference [6] and
   [7]).





Hagens & Hansen                                                 [Page 7]