Movatterモバイル変換

Network Working Group                                          R. HagensRequest for Comments: 1649             Advanced Network & Services, Inc.Category: Informational                                        A. Hansen                                                                 UNINETT                                                               July 1994Operational Requirements for X.400 Management Domainsin the GO-MHS CommunityStatus 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 onRFC-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 forRFC-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 theRFC-822 mail service   to the GO-MHS Community, the automatic return of contents when mail   is non-delivered should be requested byRFC 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 AdministrationHagens & 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 ofHagens & 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 ScenarioHagens & 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 theRFC-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, seesection 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 19943.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 toRFC-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]

RFC 1649               X.400 Management in GO-MHS              July 19943.1.7.  Domain Defined Attributes (DDAs)   The GO-MHS Community shall allow the use of domain defined   attributes.  Note: Support for DDAs is mandatory in the functional   profiles, and all software must upgrade to support DDAs.  The   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 Downgrading   The requirements in reference [2] should be implemented in GO-MDs3.3.  X.400 /RFC-822 address mapping   All GO-MHS Community end-users shall be reachable from all end-users   in theRFC-822 mail service in the Internet (SMTP), and vice versa.   The address mapping issue is split into two parts:    1) Specification ofRFC-822 addresses seen from the X.400 world.    2) Specification of X.400 addresses seen from theRFC-822 world.   The mapping of X.400 andRFC-822 addresses shall be performed   according to reference [3].3.3.1.  Specification ofRFC-822 Addresses seen from the X.400 World   Two scenarios are described:    A. TheRFC-822 end-user belongs to an organization with no defined       X.400 standard attribute address space.    B. TheRFC-822 end-user belongs to an organization with a defined       X.400 standard attribute address space.   Organizations belong to scenario B if their X.400 addresses are   registered according to the requirements insection 3.1.3.3.1.1.  An Organization with a defined X.400 Address Space   AnRFC-822 address for anRFC-822 mail user in such an organization   shall be in the same address space as a normal X.400 address for   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=cs   to address end-users in the CS-department.  TheRFC-822 address forRFC-822 mail users in the same department is: user@cs.wisc.edu.   An X.400 user in the GO-MHS Community will address theRFC-822 mail   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 the   same department.3.3.1.2.  An Organization with no defined X.400 Address SpaceRFC-822 addresses shall be expressed using X.400 domain defined   attributes.  The mechanism used to define theRFC-822 recipient will   vary on a per-country basis.   For example, in the U.S., a special PRMD named "Internet" is defined   to facilitate the specification ofRFC-822 addresses.  An X.400 user   can address anRFC-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 specific   "gateway". The 2nd part:    DD.RFC-822=user(a)some.place.edu   is theRFC-822 address of theRFC-822 mail user after substitution of   non-printable characters according to reference [3]. TheRFC-822   address is placed in an X.400 Domain Defined Attribute of typeRFC-822 (DD.RFC-822).   Each country is free to choose its own method of defining theRFC-822   community.  For example in Italy, an X.400 user would refer to anRFC-822 user as:    C=IT; ADMD=MASTER400; DD.RFC-822=user(a)some.place.it   In the UK, an X.400 user would refer to anRFC-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.uk3.3.2.  Specification of X.400 Addresses seen from theRFC-822 World   If an X.400 organization has a definedRFC-822 address space,RFC-822   users will be able to address X.400 recipients inRFC-822/Internet   terms.  This means that the address of the X.400 user, seen from anRFC-822 user, will generally be of the form:    Firstname.Lastname@some.place.edu   where the some.place.edu is a registered Internet domain.   This implies the necessity of maintaining and distributing address   mapping tables to all participatingRFC-1327 gateways. The mapping   tables shall be globally consistent.  Effective mapping table   coordination procedures are needed.   If an organization does not have a definedRFC-822 address space, an   escape mapping (defined in reference [3]) shall be used. In this   case, the address of the X.400 user, seen from anRFC-822 user, will   be of the form:    "/G=Firstname/S=Lastname/O=org name/PRMD=foo/ADMD=bar/C=us/"@                                    some.gateway.edu   Note that reference [7] specifies that quoted left-hand side   addresses must be supported and that these addresses may be greater   than 80 characters long.   This escape mapping shall also be used for X.400 addresses which do   not map cleanly toRFC-822 addresses.   It is recommended that an organization with no definedRFC-822   address space, should registerRFC-822 domains at the appropriate   registration entity for such registrations. This will minimize the   number of addresses which must use the escape mapping.   If the escape mapping is not used,RFC-822 users will not see the   difference between an InternetRFC-822 address and an address in the   GO-MHS Community.  For example:   The X.400 address:    C=us; ADMD=ATTMail; PRMD=CDC; O=CPG; S=Lastname; G=Firstname;   will from anRFC-822 user look like:Hagens & Hansen                                                [Page 10]

RFC 1649               X.400 Management in GO-MHS              July 1994       Firstname.Lastname@cpg.cdc.com3.4.  Routing Policy   To facilitate routing in the GO-MHS Community before an X.500   infrastructure is deployed, the following two documents, a RELAY-MTA   document and a Domain document, are defined.  These documents are   formally defined in reference [1]. The use of these documents is   necessary to solve the routing crisis that is present today. However,   this is a temporary solution that will eventually be replaced by the   use of X.500.   The RELAY-MTA document will define the names of RELAY-MTAs and their   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 of   an X.400 address, followed by a list of MTAs which are willing to   accept mail for the address or provide a relay service for it. Each   MTA name will be associated with a priority value. Collectively, the   list of MTA names in the Domain document make the given address   reachable from all protocol stacks. In addition, the list of MTAs may   provide redundant paths to the address, so in this case, the priority   value indicates the preferred path, or the preferred order in which   alternative routes should be tried.   The RELAY-MTA and Domain documents are coordinated by the group   specified in the Community document.  The procedures for document   information gathering and distribution, are for further study.3.5.  Minimum Statistics/Accounting   The following are not required for all MTAs. The information is   provided as guidelines for MTA managers.  This is helpful for   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 data   (i.e., format).   For each message/report passing the MTA, the following information   should be collected.Hagens & Hansen                                                [Page 11]

RFC 1649               X.400 Management in GO-MHS              July 1994   The following fields should be collected.    Date    Time    Priority    Local MTA Name    Size   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' and   'tm' is not present, 'id' should be present. If both 'fm' and 'tm'   are present, then 'dt' indicates the number of minutes that the   message was delayed in the MTA.  If 'id' cannot be mapped locally   because of log file formats, 'id' is not present and every message   creates two lines: one with 'fm' empty and one with 'tm' empty. In   this case, 'date' and 'time' in the first line represent the date and   time the message entered the MTA.  In the second line, they represent   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 of   detail.4.  Community Document   For the GO-MHS community there will exist one single COMMUNITY   document containing basic information as defined in reference [1].   First the contact information for the central coordination point can   be found together with the addresses for the file server where all   the documents are stored.  It also lists network names and stacks to   be used in the RELAY-MTA and DOMAIN documents. The GO-MHS community   must agree on its own set of mandatory and optional networks and   stacks.Hagens & Hansen                                                [Page 12]

RFC 1649               X.400 Management in GO-MHS              July 19945.  Security Considerations   Security issues are not discussed in this memo.6.  Authors' Addresses   Robert Hagens   Advanced Network & Services, Inc.   1875 Campus Commons Drive   Suite 220   Reston, VA 22091   U.S.A.   Phone: +1 703 758 7700   Fax:   +1 703 758 7717   EMail: hagens@ans.net   DDA.RFC-822=hagens(a)ans.net; P=INTERNET; C=US   Alf Hansen   UNINETT   Elgesetergt. 10   Postbox 6883, Elgeseter   N-7002 Trondheim   Norway   Phone: +47 7359 2982   Fax:   +47 7359 6450   EMail: Alf.Hansen@uninett.no   G=Alf; S=Hansen; O=uninett; P=uninett; C=noHagens & Hansen                                                [Page 13]

RFC 1649               X.400 Management in GO-MHS              July 1994References   [1] Eppenberger, U., Routing Coordination for X.400 MHS-Services       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       andRFC 822,RFC 1327, May 1992.   [4] Cargille, A., "Postmaster Convention for X.400 Operations",RFC1648, University of Wisconsin, July 1994.   [5] International Telecommunications Union, CCITT.  Data       Communications Networks, Volume VIII, Message Handling Systems,       ITU: Geneva 1985.   [6] Harrenstien, K., Stahl, M., and E. Feinler, "DOD Internet Host       Table Specification",RFC 952, SRI, October 1985.   [7] Braden, R., "Requirements for Internet Hosts -- Application and       Support", STD 3,RFC 1123, USC/Information Sciences Institute,       October 1989.Hagens & Hansen                                                [Page 14]