RFC 1649 (rfc1649) - Page 2 of 14


Operational Requirements for X



Alternative Format: Original Text Document



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