rfc1615.txt

RFC 的详细文档！

Network Working Group                                        J. Houttuin
Request for Comments: 1615                              RARE Secretariat
RARE Technical Report: 9                                      J. Craigie
Category: Informational                               Joint Network Team
                                                                May 1994


                 Migrating from X.400(84) to X.400(88)

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.

Scope

   In the context of a European pilot for an X.400(88) messaging
   service, this document compares such a service to its X.400(84)
   predecessor.  It is aimed at a technical audience with a knowledge of
   electronic mail in general and X.400 protocols in particular.

Abstract

   This document compares X.400(88) to X.400(84) and describes what
   problems can be anticipated in the migration, especially considering
   the migration from the existing X.400(84) infrastructure created by
   the COSINE MHS project to an X.400(88) infrastructure. It not only
   describes the technical complications, but also the effect the
   transition will have on the end users, especially concerning
   interworking between end users of the 84 and the 88 services.

Table of Contents

   1. New Functionality                                              2
   2. OSI Supporting Layers                                          3
   3. General Extension Mechanism                                    5
   4. Interworking                                                   5
      4.1. Mixed 84/88 Domains                                       5
      4.2. Generation of OR-Name Extensions from X.400(84)           6
      4.3. Distribution List Interworking with X.400(84)             8
      4.4. P2 Interworking                                          10
   5. Topology for Migration                                        11
   6. Conclusion                                                    12
   7. Security Considerations                                       13
   Appendix A - DL-expanded and Redirected Messages in X.400(84)    14
   Appendix B - Bibliography                                        14
   Appendix C - MHS Terminology                                     15



Houttuin & Craigie                                              [Page 1]

RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994


   Appendix D - Abbreviations                                       16
   Authors' Addresses                                               17

1. New Functionality

   Apart from the greater maturity of the standard and the fact that it
   makes proper use of the Presentation Layer, the principal features of
   most use to the European R&D world in X.400(88) not contained in
   X.400(84) are:

    - A powerful mechanism for arbitrarily nested Distribution
      Lists including the ability for DL owners to control access
      to their lists and to control the destination of nondelivery
      reports. The current endemic use of DLs in the research
      community makes this a fundamental requirement.

    - The Message Store (MS) and its associated protocol, P7. The
      Message Store provides a server for remote User Agents (UAs)
      on Workstations and PCs enabling messages to be held for
      their recipient, solving the problems of non-continuous
      availability and variability of network addresses of such
      UAs. It provides powerful selection mechanisms allowing the
      user to select messages from the store to be transferred to
      the workstation/PC. This facility is not catered for
      adequately by the P3 protocol of X.400(84) and provides a
      major incentive for transition.

    - Use of X.500 Directories. Support for use of Directory Names
      in MHS will allow a transition from use of O/R Addresses to
      Directory Names when X.500 Directories become widespread,
      thus removing the need for users to know about MHS
      topological addressing components.

    - The provision of message Security services including
      authentication, confidentiality, integrity and non-
      repudiation as well as secure access between MHS components
      may be important for a section of the research community.

    - Redirection of messages, both by the recipient if
      temporarily unable to receive them, and by the originator in
      the event of failure to deliver to the intended recipient.

    - Use of additional message body encodings such as ISO 8613
      ODA (Office Document Architecture) reformattable documents or
      proprietary word processor formats.






Houttuin & Craigie                                              [Page 2]

RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994


    - Physical Delivery services that cater for the delivery of an
      electronic message on a physical medium (such as paper)
      through the normal postal delivery services to a recipient
      who (presumably) does not use electronic mail.

    - The use of different body parts. In addition to the
      extensible externally defined body parts, the most common
      types are predefined in the standard.  In order to give end-
      users a real advantage as compared to other technologies, the
      following body-parts should be supported as a minimum:

         - IA5
         - Message
         - G3FAX
         - External
            - General Text
            - Others

      The last bullet should be interpreted as follows: all UAs
      should be configurable to use any type of externally defined
      body part, but as a minimum General Text can be generated and
      read.

    - The use of extended character sets, both in O/R addresses
      and in the General Text extended bodypart. As a minimum, the
      character sets as described in the European profiles will be
      supported. A management domain may choose as an internal
      matter which character sets it wants to support in
      generating, but all user agents must be able to copy (in
      local address books and in replies) any O/R address, even if
      it contains character sets it cannot interpret itself.

2. OSI Supporting Layers

   The development of OSI Upper Layer Architecture since 1984 allows the
   new MHS standards to sit on the complete OSI stack, unlike X.400(84).
   A new definition of the Reliable Transfer Service (RTS), ISO 9066,
   has a mode of operation, Normal-mode, which uses ACSE and the OSI
   Presentation Layer. It also defines another mode compatible with
   X.410(84) RTS that was intended only for interworking with X.400(84)
   systems.

   However, there are differences between the conformance requirements
   of ISO MOTIS and CCITT X.400(88) for mandatory support for the
   complete OSI stack. ISO specify use of Normal-mode RTS as a mandatory
   requirement with X.410-mode RTS as an additional option, whereas
   CCITT require X.410-mode and have Normal-mode optional. The ISO
   standard identifies three MTA types to provide options in RTS modes:



Houttuin & Craigie                                              [Page 3]

RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994


    - MTA Type A supports only Normal-mode RTS, and provides
      interworking within a PRMD and with other PRMDs (conforming
      to ISO 10021), and with ADMDs which have complete
      implementations of X.400(88) or which conform to ISO 10021.

    - MTA Type B adds to the functionality of MTA type A the
      ability to interwork with ADMDs implementing only the minimal
      requirements of X.400(88), by requiring support for X.410-
      mode RTS in addition to Normal-mode.

    - MTA Type C adds to the functionality of MTA type B the
      ability to interwork with external X.400(84) Management
      Domains (MDs, i.e., PRMDs and ADMDs), by requiring support for
      downgrading (see 5.1) to the X.400(84) P1 protocol.

   The interworking between ISO and CCITT conformant systems is
   summarised in the following table:

                                      CCITT

                            X.400(84)       X.400(88)
                                         minimal   complete
                                          implementation

   ISO 10021/   MTA Type A     N            N         Y
   MOTIS        MTA Type B     N            Y         Y
                MTA Type C     Y            Y         Y

            Table 1: Interworking ISO <-> CCITT systems

   The RTS conformance difference would totally prevent interworking
   between the two versions of the standard if implementations never
   contained more than the minimum requirements for conformance, but in
   practice many 88 implementations will be extensions of 84 systems,
   and will thus support both modes of RTS. (At the moment we are aware
   of only one product that doesn't support Normal mode.)

   Both ISO and CCITT standards require P7 (and P3) to be supported
   directly over the Remote Operations Service (ROS), ISO 9072, and use
   Normal-mode presentation (and not X.410-mode). Both allow optionally
   ROS over RTS (in case the Transport Service doesn't provide an
   adequately reliable service), again using Normal-mode and not X.410-
   mode.

   CCITT made both Normal and X.410 mode mandatory in its X.400(92)
   version, and it is expected that the 94 version will have the X.410
   mode as an option only.




Houttuin & Craigie                                              [Page 4]

RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994


3. General Extension Mechanism

   One of the major assets in ISO 10021/X.400(88) is the extension
   mechanism. This is used to carry most of the extensions defined in
   these standards, but its principal benefit will be in reducing the
   trauma of transitions to future versions of the standards. Provided
   that implementations of the 88 standards do not try to place
   restrictions on the values that may be present, any future extension
   will be relayed by these implementations when appropriate (i.e., when
   the extension is not critical), thus providing a painless migration
   to new versions of the standards.

4. Interworking

4.1. Mixed 84/88 Domains

   ISO 10021-6/X.419(88) defines rules for interworking with X.400(84),
   called downgrading. As X.400 specifies the interconnection of MDs,
   these rules define the actions necessary by an X.400(88) MD to
   communicate with an X.400(84) MD. The interworking rules thus apply
   at domain boundaries. Although it would not be difficult to extend
   these to rules to convert Internal Trace formats which might be
   thought a sufficient addition to allow mixed X.400(84)/X.400(88)
   domains, the problems involved in attempting to define mixed 84/88
   domains are not quite that simple.

   The principle problem is in precisely defining the standard that
   would be used between MTAs within an X.400(84) domain, as X.400(84)
   only defines the interconnection of MDs. In practice, MTA
   implementations either use X.400(84) unmodified, or X.400(84) with
   the addition of Internal Trace from the first MOTIS DIS (DIS 8883),
   or support MOTIS as defined in DIS 8505, DIS 8883, and DIS 9065. The
   second option is recommended in the NBS Implementors Agreements, and
   the third option is in conformance with the CEN/CENELEC MHS
   Functional Standard [1], which requires as a minimum tolerance of all
   "original MOTIS" protocol extensions. An 84 MD must decide which of
   these options it will adopt, and then require all its MTAs to adopt
   (or at least be compatible with) this choice. No doubt this is one of
   the reasons for the almost total absence currently of mixed- vendor
   X.400(84) MDs in the European R&D MHS community. The fact that none
   of these three options for communication between MTAs within a domain
   have any status within the standardisation bodies accounts for the
   absence from ISO 10021/X.400(88) of detailed rules for interworking
   within mixed 84/88 domains.

   Use of the first option, unmodified X.400(84), carries the danger of
   undetectable routing loops occurring. Although these can only occur
   if MTAs have inconsistent routing tables, the absence of standardised



Houttuin & Craigie                                              [Page 5]

RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994


   methods of disseminating routing information makes this a possibility
   which if it occurred might cause severe disruption before being
   detected. The only addition to the interworking rules needed for this
   case is the deletion of Internal Trace when downgrading a message.

   Use of the second option, X.400(84) plus Internal Trace, allows the
   detection and prevention of routing loops. Details of the mapping
   between original-MOTIS Internal Trace and the Internal Trace of ISO
   10021 can be found in Annex A. This should be applied not only when
   downgrading from 88 to 84, but also in reverse when an 84 MPDU is
   received by the 84/88 Interworking MTA. If the 84 domain properly
   implements routing loop detection algorithms, then this will allow
   completely consistent reception of messages by an 84 recipient even
   after DL expansion or Redirection within that domain (but see also
   section 5.3).  Unfortunately, the first DIS MOTIS like X.400(84) left
   far too much to inference, so not all implementors may have
   understood that routing loop detection algorithms must only consider
   that part of the trace after the last redirection flag in the trace
   sequence.

   Use of the third option, tolerance of all original-MOTIS extensions,
   would in principle allow a still higher level of interworking between
   the 84 and 88 systems. However, no implementations are known which do
   more than relay the syntax of original-MOTIS extensions: there is no
   capability to generate these protocol elements or ability to
   correctly interpret their semantics.

   The choice between the first two options for mixed domains can be
   left to individual management domains. It has no impact on other
   domains provided the topology recommended in section 5 is adopted.

4.2. Generation of OR-Name Extensions from X.400(84)