doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc1615.txt b/doc/rfc/rfc1615.txt
new file mode 100644
index 0000000..6221a09
--- /dev/null
+++ b/doc/rfc/rfc1615.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+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)
+
+   The interworking rules defined in DIS 10021-6/X.419 Annex B allow for
+   delivery of 88 messages to 84 recipients, but do not make any 88
+   extensions available to 84 originators. In general this is an
+   adequate strategy. Most 88 extensions provide optional services or
+   have sensible defaults. The exception to this is the OR-Name
+   extensions. These fall into three categories: the new CommonName
+   attribute; fifteen new attributes for addressing physical delivery
+   recipients; and alternative Teletex (T.61) encodings for all
+   attributes that were defined as Printable Strings. Without some
+   mechanism to generate these attributes, 84 originators are unable to
+   address 88 recipients with OR-Addresses containing these attributes.
+   Such a mechanism is defined in RARE Technical Report 3 ([2]), "X.400
+   1988 to 1984 downgrading".
+
+
+
+
+
+Houttuin & Craigie                                              [Page 6]
+
+RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
+
+
+   Common-name appears likely to be a widely used attribute because it
+   remedies a serious deficiency in the X.400(84) OR-Name: it provides
+   an attribute suitable for naming Distribution Lists and roles, and
+   even individuals where the constraints of the 84 personal-name
+   structure are inappropriate or undesirable. As 84 originators will no
+   doubt wish to be able to address 88 DLs (and roles), [2] defines a
+   Domain Defined Attribute (DDA) to enable generation of common-name by
+   84 originators. This consists of a DDA with its type set to "common-
+   name" and its value containing the Printable String encoding to be
+   set into the 88 common-name attribute.
+
+   This requires that all European R&D MHS 88 MTAs capable of
+   interworking with 84 systems shall be able to map the value of
+   "common-name" DDA in OR-Names received from 84 systems to the 88
+   standard attribute extension component common-name, and vice versa.
+
+   X.400(84) originators will only be able to make use of this ability
+   to address 88 common-name recipients if their system is capable of
+   generating DDAs. Unfortunately, one of the many serious deficiencies
+   with the CEN/CENELEC and CEPT 84 MHS Functional Standards ([1] and
+   [3]), as originally published, is that this ability is not a
+   requirement for all conformant systems. Thus if existing European R&D
+   MHS X.400(84) users wish to be able to address a significant part of
+   the ISO 10021/X.400(84) world they must explicitly ensure that their
+   84 systems are capable of generating DDAs. However, this will be a
+   requirement in the revised versions of ENV 41201 and ENV 41202, which
+   are to be published soon. There is no alternative mechanism for
+   providing this functionality to 84 users. It is estimated that
+   currently 95% of all European R&D MHS users are able to generate
+   DDAs.
+
+   When messages are sent to both ISO 10021/X.400(88) and X.400(84)
+   recipients outside the European R&D MHS community, this
+   representation of common-name will not enable the external recipients
+   to communicate directly unless their 84/88 interworking MTA also
+   implements this mapping. However, use of this mapping within the
+   European R&D MHS community has not reduced external connectivity, and
+   provided RTR 3, RFC 1328 is universally implemented within this
+   community it will enhance connectivity within the community.
+
+   As for the new Physical Delivery address attributes in X.400(88), RTR
+   3 (RFC1328) takes the following approach. A DDA with type "X400-88"
+   is used, whose value is an std-or encoding of the address as defined
+   in RARE Technical Report 2 ([4]), "Mapping between X.400(1988)/ISO
+   10021 and RFC 822". This allows source routing through an appropriate
+   gateway. Where the generated address is longer than 128 characters,
+   up to three overflow DDAs are used: X400-C1; X400-C2; X400-C3. This
+   solution is general, and does not require co-operation, i.e., it can
+
+
+
+Houttuin & Craigie                                              [Page 7]
+
+RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
+
+
+   be implemented in the gateways only.
+
+   Note that the two DDA solutions mentioned above have the undesirable
+   property that the P2 heading will still contain the DDA form, unless
+   content upgrading is also done. In order to shield the user from
+   cryptic DDAs, such content upgrading is in general recommended, also
+   for nested forwarded messages, even though the available standards
+   and profiles do not dictate this.
+
+4.3. Distribution List Interworking with X.400(84)
+
+   Before all X.400(84) systems are upgraded to ISO 10021, the
+   interaction of Distribution Lists with X.400(84) merits special
+   attention as DLs are already widely used.
+
+   Nothing, apart perhaps from the inability to generate the DL's OR-
+   Address if the DL uses the common-name attribute, prevents an
+   X.400(84) originator from submitting a message to a DL.
+
+   X.400(84) users can also be members (i.e., recipients) of a DL.
+   However, if the X.400(84) systems involved correctly implement
+   routing loop detection, the X.400(84) recipient may not receive all
+   messages sent to the DL. X.400(84) routing loop detection involves a
+   recipient MD in scanning previous entries in a message's trace
+   sequence for an occurrence of its own domain, and if such an entry is
+   found the message is non-delivered. The new standards extend the
+   trace information to contain flags to indicate DL-expansion and
+   redirection, and re-define the routing loop detection algorithm to
+   only examine trace elements from the last occurrence of either of
+   these flags. Thus 88 systems allow a message to re-traverse an MD (or
+   be relayed again by an MTA) after either DL-expansion or redirection.
+   However, these flags cannot be included in X.400(84) trace, so are
+   deleted on downgrading. Therefore the 84 DL recipient will receive
+   all messages sent to the DL except those which had a common point in
+   the path to the DL expansion point with the path from the expansion
+   points to his UA. This common point is an MD in the case of a DL in
+   another MD or an MTA in the case of a DL in the same MD. Although
+   this is quite deterministic behaviour, the user is unlikely to
+   understand it and instead regard it as erratic or inconsistent
+   behaviour.
+
+   Another problem with X.400(84) DL members will be that delivery and
+   non-delivery reports will be sent back directly to the originator of
+   a message, rather than routed through the hierarchy of DL expansion
+   points where they could have been routed to the DL administrator
+   instead of (or as well as) the originator.
+
+
+
+
+
+Houttuin & Craigie                                              [Page 8]
+
+RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
+
+
+   No general solution to this problem has yet been devised, despite
+   much thought from a number of experts. The nub of the problem is that
+   changing the downgrading rules to enable 84 recipients to receive all
+   such messages also allows the possibility of undetectable infinite DL
+   or redirection looping where there is an 84 transit domain.
+
+   A potential solution is to extend the DL expansion procedures to
+   explicitly identify X.400(84) recipients and to treat them specially,
+   at least by deleting all trace prior to the expansion point. This
+   solution is only dangerous if another DL reached through an 84
+   transit domain is inadvertently configured as an 84 recipient, when
+   infinite looping could occur. It does however impose the problems of
+   84 interworking into MHS components which need to know nothing even
+   of the existence of X.400(84). It also requires changes to the
+   Directory attribute mhs-dl-members to accommodate the indication that
+   identifies the recipient as an X.400(84) user, unless European R&D
+   MHS DLs are restricted to being implemented by local tables rather
+   than making use of the Directory.
+
+   A similar change would be required for Redirection. However, the
+   change for Redirection would have substantially more impact as it
+   would require European R&D MHS-specific MHS protocol extensions to
+   identify the redirected recipient as an X.400(84) user. If the
+   European R&D MHS adopts a reasonable quality of MHS(88) service, all
+   its MTAs would be capable of Redirection and all UAs would be capable
+   of requesting originator-specified-alternate-recipient and thus be
+   required to incorporate these non-standard additions. A special
+   European R&D MHS modification affecting all MTAs and UAs seems
+   impractical, too!
+
+   If the recommended European R&D MHS topology for MHS migration (See
+   chapter 5) is adopted there will never be an X.400(84) transit domain
+   (or MTA) between two ISO 10021 systems. This allows the deletion of
+   trace prior to the last DL expansion or redirection to be performed
+   as part of the downgrading, giving the X.400(84) user a consistent
+   service. This solution has the advantage of only requiring changes at
+   the convertors between X.400(84) and ISO 10021/X.400(88), where other
+   European R&D MHS specific extensions have also been identified. A
+   precise specification of this solution is given in Annex A.
+
+   Finally, problems might occur because some X.400(84) MTAs could
+   object to messages containing more than one recipient with the same
+   extension-id (called originally-requested-recipient-number in the new
+   standards), since this was not defined in X.400(84).  Note that
+   X.400(84) only requires that all extension-id's be different at
+   submission time, so 84 software that does not except messages with
+   identical extension-id's for relaying or delivery must be considered
+   broken.
+
+
+
+Houttuin & Craigie                                              [Page 9]
+
+RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
+
+
+4.4. P2 Interworking
+
+   RTR 3, RFC 1328 also defines the downgrading rules for P2 (IPM)
+   interworking: The IPM service in X.400(1984) is usually provided by
+   content type 2. In many cases, it will be useful for a gateway to
+   downgrade P2 from content type 22 to 2. This will clearly need to be
+   made dependent on the destination, as it is quite possible to carry
+   content type 22 over P1(1984). The decision to make this downgrade
+   will be on the basis of gateway configuration.
+
+   When a gateway downgrades from 22 to 2, the following should be done:
+
+    1. Strip any 1988 specific headings (language indication, and
+       partial message indication).
+
+    2. Downgrade all O/R addresses, as described in Section 3.
+
+    3. If a directory name is present, there is no method to
+       preserve the semantics within a 1984 O/R Address. However, it
+       is possible to pass the information across, so that the
+       information in the Distinguished Name can be informally
+       displayed to the end user. This is done by appending a text
+       representation of the Distinguished Name to the Free Form
+       Name enclosed in round brackets. It is recommended that the
+       "User Friendly Name" syntax is used to represent the
+       Distinguished Name [5]. For example:
+
+          (Steve Hardcastle-Kille, Computer Science,
+          University College London, GB)
+
+    4. The issue of body part downgrade is discussed in Section 6.
+
+   Note that a message represented as content type 22 may have
+   originated from [6]. The downgrade for this type of message can be
+   improved. This is discussed in RTR 2, RFC 1327.
+
+   Note that the newer EWOS/ETSI recommendations specify further rules
+   for downgrading, which are not all completely compatible with the
+   rules in RTR 3, RFC 1328. This paper does not state which set of
+   rules is preferred for the European R&D MHS, it only states that a
+   choice will have to be made.
+
+   As the transition topology recommended for the European R&D MHS is to
+   never use 84 transit systems between 88 systems, it is possible to
+   improve on the P2 originator downgrading and resending scenario. The
+   absence of 84 transit systems means that the necessity for a P1
+   downgrade implies that the recipient is on an 84 system, and thus
+   that it is better to downgrade 88 P2 contents to 84 P2 rather than to
+
+
+
+Houttuin & Craigie                                             [Page 10]
+
+RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
+
+
+   relay it in the knowledge that it will not be delivered.
+
+5. Topology for Migration
+
+   Having decided that a transition from X.400(84) is appropriate, it is
+   necessary to consider the degree of planning and co- ordination
+   required to preserve interworking during the transition.
+
+   It is assumed as a fundamental tenet that interworking must be
+   preserved during the transition. This requires that one or more
+   system in the European R&D MHS community must act as a protocol
+   converter by implementing the rules for "Interworking with 1984
+   Systems" listed in Annex B of ISO 10021-6/X.419.
+
+   When downgrading from ISO 10021/X.400(88) to X.400(84) all extensions
+   giving functionality beyond X.400(84) are discarded, or if a critical
+   extension is present then downgrading fails and a non-delivery
+   results. Thus, although it is possible to construct topologies of
+   interconnected MTAs so that two 88 MTAs can only communicate by
+   relaying through one or more 84 MTA, to maximise the quality of
+   service which can be provided in the European R&D MHS community it is
+   proposed that it require that no two European R&D MHS 88 MTAs shall
+   need to communicate by relaying through a X.400(84) MTA. Furthermore,
+   if this is extended to require that no two European R&D MHS 88 MTAs
+   shall ever communicate by relaying through an X.400(84) MTA, then the
+   European R&D MHS can provide enhanced interworking functionality to
+   its X.400(84) users.
+
+   If mixed vintage 88 and 84 Management Domains (MDs) are created, the
+   routing loop detection rules, which specify that a message shall not
+   re-enter an MD it has previously traversed, require that downgrading
+   is performed within that mixed vintage MD. That MD therefore requires
+   at least one MTA capable of downgrading from 88 to 84. It is unlikely
+   that every MTA within an MD will be configured to act as an entry-
+   point to that MD from other MDs. However, the proposed European R&D
+   MHS migration topology requires that as soon as a domain has an 88
+   MTA it shall also have an 88 entry point - this may, of course, be
+   that same MTA.
+
+   Even for MDs operating all the same MHS vintage internally, providing
+   entry-points for both MHS vintages will give considerable advantage
+   in maximising the connectivity to other MDs. Initially, it will be
+   particularly important for 88 MDs to be able to communicate with 84
+   only MDs, but as 88 becomes more widespread eventually the 84 MDs
+   will become a minority for which the ability to support 88 will be
+   important to maintain connectivity. For most practical MDs providing
+   entry-points that implement options in the supporting layers will
+   also be important. Support for at least the following is recommended
+
+
+
+Houttuin & Craigie                                             [Page 11]
+
+RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
+
+
+   at MD entry-points:
+
+    88-P1/Normal-mode RTS/CONS/X.25(84)
+    88-P1/Normal-mode RTS/RFC1006/TCP/IP
+    84-P1/X.25(80)
+    84-P1/RFC1006/TCP/IP
+
+   The above table omits layers where the choice is obvious (e.g.,
+   Transport class zero), or where no choice exists (e.g., RTS for 84-
+   P1).
+
+   The requirement for no intermediate 84 systems does require that the
+   European R&D MHS use direct PRMD to PRMD routing between 88 PRMDs at
+   least until such time as all ADMDs will relay the 88 MHS protocols.
+
+   Finally, in order to keep routing co-ordination overhead to a
+   minimum, an important requirement for the migration strategy is that
+   only one common set of routing procedures is used for both 84 and 88
+   systems in the European R&D MHS.
+
+6. Conclusion
+
+    1. The transition from X.400(84) to ISO 10021/X.400(88) is
+       worthwhile for the European R&D MHS, to provide:
+
+          - P7 Message Store to support remote UAs.
+          - Distribution Lists.
+          - Support for Directory Names.
+          - Standardised external Body Part types.
+          - Redirection.
+          - Security.
+          - Future extensibility.
+          - Physical Delivery.
+
+    2. To minimise the number of transitions the European R&D MHS
+       target should be ISO 10021 rather than CCITT X.400(88) -
+       i.e., straight to use of the full OSI stack with Normal-mode
+       RTS.
+
+    3. To give a useful quality of service, the European R&D MHS
+       should not use minimal 88 MTAs which relay the syntax but
+       understand none of the semantics of extensions. In
+       particular, all European R&D MHS 88 MTAs should generate
+       reports containing extensions copied from the subject message
+       and route reports through the DL expansion hierarchy where
+       appropriate.
+
+
+
+
+
+Houttuin & Craigie                                             [Page 12]
+
+RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
+
+
+    4. The European R&D MHS should carefully plan the transition so
+       that it is never necessary to relay through an 84 system to
+       provide connectivity between any two 88 systems.
+
+    5. The European R&D MHS should consider the additional
+       functionality that can be provided to X.400(84) users by
+       adopting an enhanced specification of the interworking rules
+       between X.400(84) and ISO 10021/X.400(88), and weigh this
+       against the cost of building and maintaining its own
+       convertors. The advantages to X.400(84) users are:
+
+         - Ability to generate 88 common-name attribute, likely to
+           be widely used for naming DLs.
+         - Consistent reception of DL-expanded and Redirected
+           messages.
+         - Ability to receive extended 88 P2 contents
+           automatically downgraded to 84 P2.
+
+7. Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Houttuin & Craigie                                             [Page 13]
+
+RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
+
+
+Appendix A - DL-expanded and Redirected Messages in X.400(84)
+
+   This Annex provides an additional to the rules for "Interworking with
+   1984 Systems" contained in Annex B of ISO 10021-6/X.419,  to give
+   X.400(84) recipients consistent reception of messages  that have been
+   expanded by a DL or redirected.  It is applicable  only if the
+   transition topology for the European R&D MHS  recommended in section
+   3 is adopted.
+
+   Replace the first paragraph of B.2.3 by:
+
+   If an other-actions element is present in any trace- information-
+   elements, that other-actions element and all preceding trace-
+   information-elements shall be deleted. If an other-actions element is
+   present in any subject-intermediate-trace-information- elements, that
+   other-actions element shall be deleted.
+
+Appendix B - Bibliography
+
+   [1] ENV 41201, "Private MHS UA and MTA: PRMD to PRMD", CEN/CENELEC,
+       1988.
+
+   [2] Kille, S., "X.400 1988 to 1984 downgrading", RTR 3, RFC 1328,
+       University College London, May 1992.
+
+   [3] ENV 41202, "Protocol for InterPersonal Messaging between MTAs
+       accessing the Public MHS", CEPT, 1988.
+
+   [4] Kille, S.  "Mapping between X.400(1988)/ISO 10021 and RFC 822",
+       RTR 2, RFC 1327; University College London. May 1992.
+
+   [5] Kille, S., "Using the OSI Directory to achieve User Friendly
+       Naming", RFC 1484, ISODE Consortium, July 1993.
+
+   [6] Crocker, D., "Standard for the Format of ARPA Internet Text
+       Messages", STD 11, RFC 822, University of Delaware, August 1982.
+
+   [7] Craigie, J., "COSINE Study 8.2.2. Migration Strategy for
+       X.400(84) to X.400(88)/MOTIS", Joint Network Team, 1988.
+
+   [8] Craigie, J., "ISO 10021-X.400(88): A Tutorial for those familiar
+       with X.400(84)", Computer Networks and ISDN systems 16, 153-160,
+       North-Holland, 1988.
+
+   [9] Manros, C.-U., "The X.400 Blue Book Companion", ISBN 1 871802 00
+       8, Technology Appraisals Ltd, 1989.
+
+
+
+
+
+Houttuin & Craigie                                             [Page 14]
+
+RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
+
+
+  [10] CCITT Recommendations X.400 - X.430, "Data Communication
+       Networks: Message Handling Systems", CCITT Red Book, Vol. VIII -
+       Fasc. VIII.7, Malaga-Torremolinos, 1984.
+
+  [11] CCITT Recommendations X.400 - X.420 (ISO IS-10021), "Data
+       Communication Networks: Message Handling Systems", CCITT Blue
+       Book, Vol. VIII - Fasc. VIII.7, Melbourne, 1988.
+
+Appendix C - MHS Terminology
+
+   Message Handling is performed by four types of functional entity:
+   User Agents (UAs) which enable the user to compose, send, receive,
+   read and otherwise process messages; Message Transfer Agents (MTAs)
+   which provide store-and-forward relaying services; Message Stores
+   (MSs) which act on behalf of UAs located remotely from their
+   associated MTA (e.g., UAs on PCs or workstations); and Access Units
+   (AUs) which interface MHS to other communications media (e.g., Telex,
+   Teletex, Fax, Postal Services). Each UA (and MS, and AU) is served by
+   a single MTA, which provides that user's interface into the Message
+   Transfer Service (MTS).
+
+   Collections of MTAs (and their associated UAs, MSs and AUs) which are
+   operated by or under the aegis of a single management authority are
+   termed a Management Domain (MD). Two types of MD are defined: an
+   ADMD, which provides a global public message relaying service
+   directly or indirectly to all other ADMDs; and a PRMD operated by a
+   private concern to serve its own users.
+
+   A Message is comprised of an envelope and its contents. Apart from
+   the MTS content-conversion service, the content is not examined or
+   modified by the MTS which uses the envelope alone to provide the
+   information required to convey the message to its destination.
+
+   The MTS is the store-and-forward message relay service provided by
+   the set of all MTAs. MTAs communicate with each other using the P1
+   Message Transfer protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Houttuin & Craigie                                             [Page 15]
+
+RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
+
+
+Appendix D - Abbreviations
+
+      ACSE     Association Control Service Element
+      ADMD     Administration Management Domain
+      ASCII    American Standard Code for Information Exchange
+      ASN.1    Abstract Syntax Notation One
+      AU       Access Unit
+      CCITT    Comite Consultatif International de Telegraphique et
+               Telephonique
+      CEN      Comite Europeen de Normalisation
+      CENELEC  Comite Europeen de Normalisation Electrotechnique
+      CEPT     Conference Europeene des Postes et Telecommunications
+      CONS     Connection Oriented Network Service
+      COSINE   Co-operation for OSI networking in Europe
+      DL       Distribution List
+      DIS      Draft International Standard
+      EN       European Norm
+      ENV      Draft EN, European functional standard
+      IEC      International Electrotechnical Commission
+      IPM      Inter-Personal Message
+      IPMS     Inter-Personal Messaging Service
+      IPN      Inter-Personal Notification
+      ISO      International Organisation for Standardisation
+      JNT      Joint Network Team (UK)
+      JTC      Joint Technical Committee (ISO/IEC)
+      MD       Management Domain (either an ADMD or a PRMD)
+      MHS      Message Handling System
+      MOTIS    Message-Oriented Text Interchange Systems
+      MTA      Message Transfer Agent
+      MTL      Message Transfer Layer
+      MTS      Message Transfer System
+      NBS      National Bureau of Standardization
+      OSI      Open Systems Interconnection
+      PRMD     Private Management Domain
+      RARE     Reseaux Associes pour la Recherche Europeenne
+      RFC      Request for Comments
+      RTR      RARE Technical Report
+      RTS      Reliable Transfer Service
+      WG-MSG   RARE Working Group on Mail and Messaging
+
+
+
+
+
+
+
+
+
+
+
+
+Houttuin & Craigie                                             [Page 16]
+
+RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
+
+
+Authors' Addresses
+
+   Jeroen Houttuin
+   RARE Secretariat
+   Singel 466-468
+   NL-1017 AW Amsterdam
+   Europe
+
+   Phone: +31 20 6391131
+   RFC 822: houttuin@rare.nl
+   X.400: C=NL;ADMD=400net;PRMD=surf;
+   O=rare;S=houttuin;
+
+
+   Jim Craigie
+   Joint Network Team
+   Rutherford Appleton Laboratory
+   UK-OX11 OQX Chilton
+   Didcot, Oxfordshire
+   Europe
+
+   Phone: +44 235 44 5539
+   RFC 822: J.Craigie@jnt.ac.uk
+   X.400: C=GB;ADMD= ;PRMD=UK.AC;
+   O=jnt;I=J;S=Craigie;
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Houttuin & Craigie                                             [Page 17]
+