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

Document Type RFC - Informational (July 1994; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1649 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
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.
Show full document text