home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1615 < prev    next >
Text File  |  1995-09-15  |  40KB  |  956 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        J. Houttuin
  8. Request for Comments: 1615                              RARE Secretariat
  9. RARE Technical Report: 9                                      J. Craigie
  10. Category: Informational                               Joint Network Team
  11.                                                                 May 1994
  12.  
  13.  
  14.                  Migrating from X.400(84) to X.400(88)
  15.  
  16. Status of this Memo
  17.  
  18.    This memo provides information for the Internet community.  This memo
  19.    does not specify an Internet standard of any kind.  Distribution of
  20.    this memo is unlimited.
  21.  
  22. Scope
  23.  
  24.    In the context of a European pilot for an X.400(88) messaging
  25.    service, this document compares such a service to its X.400(84)
  26.    predecessor.  It is aimed at a technical audience with a knowledge of
  27.    electronic mail in general and X.400 protocols in particular.
  28.  
  29. Abstract
  30.  
  31.    This document compares X.400(88) to X.400(84) and describes what
  32.    problems can be anticipated in the migration, especially considering
  33.    the migration from the existing X.400(84) infrastructure created by
  34.    the COSINE MHS project to an X.400(88) infrastructure. It not only
  35.    describes the technical complications, but also the effect the
  36.    transition will have on the end users, especially concerning
  37.    interworking between end users of the 84 and the 88 services.
  38.  
  39. Table of Contents
  40.  
  41.    1. New Functionality                                              2
  42.    2. OSI Supporting Layers                                          3
  43.    3. General Extension Mechanism                                    5
  44.    4. Interworking                                                   5
  45.       4.1. Mixed 84/88 Domains                                       5
  46.       4.2. Generation of OR-Name Extensions from X.400(84)           6
  47.       4.3. Distribution List Interworking with X.400(84)             8
  48.       4.4. P2 Interworking                                          10
  49.    5. Topology for Migration                                        11
  50.    6. Conclusion                                                    12
  51.    7. Security Considerations                                       13
  52.    Appendix A - DL-expanded and Redirected Messages in X.400(84)    14
  53.    Appendix B - Bibliography                                        14
  54.    Appendix C - MHS Terminology                                     15
  55.  
  56.  
  57.  
  58. Houttuin & Craigie                                              [Page 1]
  59.  
  60. RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
  61.  
  62.  
  63.    Appendix D - Abbreviations                                       16
  64.    Authors' Addresses                                               17
  65.  
  66. 1. New Functionality
  67.  
  68.    Apart from the greater maturity of the standard and the fact that it
  69.    makes proper use of the Presentation Layer, the principal features of
  70.    most use to the European R&D world in X.400(88) not contained in
  71.    X.400(84) are:
  72.  
  73.     - A powerful mechanism for arbitrarily nested Distribution
  74.       Lists including the ability for DL owners to control access
  75.       to their lists and to control the destination of nondelivery
  76.       reports. The current endemic use of DLs in the research
  77.       community makes this a fundamental requirement.
  78.  
  79.     - The Message Store (MS) and its associated protocol, P7. The
  80.       Message Store provides a server for remote User Agents (UAs)
  81.       on Workstations and PCs enabling messages to be held for
  82.       their recipient, solving the problems of non-continuous
  83.       availability and variability of network addresses of such
  84.       UAs. It provides powerful selection mechanisms allowing the
  85.       user to select messages from the store to be transferred to
  86.       the workstation/PC. This facility is not catered for
  87.       adequately by the P3 protocol of X.400(84) and provides a
  88.       major incentive for transition.
  89.  
  90.     - Use of X.500 Directories. Support for use of Directory Names
  91.       in MHS will allow a transition from use of O/R Addresses to
  92.       Directory Names when X.500 Directories become widespread,
  93.       thus removing the need for users to know about MHS
  94.       topological addressing components.
  95.  
  96.     - The provision of message Security services including
  97.       authentication, confidentiality, integrity and non-
  98.       repudiation as well as secure access between MHS components
  99.       may be important for a section of the research community.
  100.  
  101.     - Redirection of messages, both by the recipient if
  102.       temporarily unable to receive them, and by the originator in
  103.       the event of failure to deliver to the intended recipient.
  104.  
  105.     - Use of additional message body encodings such as ISO 8613
  106.       ODA (Office Document Architecture) reformattable documents or
  107.       proprietary word processor formats.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Houttuin & Craigie                                              [Page 2]
  115.  
  116. RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
  117.  
  118.  
  119.     - Physical Delivery services that cater for the delivery of an
  120.       electronic message on a physical medium (such as paper)
  121.       through the normal postal delivery services to a recipient
  122.       who (presumably) does not use electronic mail.
  123.  
  124.     - The use of different body parts. In addition to the
  125.       extensible externally defined body parts, the most common
  126.       types are predefined in the standard.  In order to give end-
  127.       users a real advantage as compared to other technologies, the
  128.       following body-parts should be supported as a minimum:
  129.  
  130.          - IA5
  131.          - Message
  132.          - G3FAX
  133.          - External
  134.             - General Text
  135.             - Others
  136.  
  137.       The last bullet should be interpreted as follows: all UAs
  138.       should be configurable to use any type of externally defined
  139.       body part, but as a minimum General Text can be generated and
  140.       read.
  141.  
  142.     - The use of extended character sets, both in O/R addresses
  143.       and in the General Text extended bodypart. As a minimum, the
  144.       character sets as described in the European profiles will be
  145.       supported. A management domain may choose as an internal
  146.       matter which character sets it wants to support in
  147.       generating, but all user agents must be able to copy (in
  148.       local address books and in replies) any O/R address, even if
  149.       it contains character sets it cannot interpret itself.
  150.  
  151. 2. OSI Supporting Layers
  152.  
  153.    The development of OSI Upper Layer Architecture since 1984 allows the
  154.    new MHS standards to sit on the complete OSI stack, unlike X.400(84).
  155.    A new definition of the Reliable Transfer Service (RTS), ISO 9066,
  156.    has a mode of operation, Normal-mode, which uses ACSE and the OSI
  157.    Presentation Layer. It also defines another mode compatible with
  158.    X.410(84) RTS that was intended only for interworking with X.400(84)
  159.    systems.
  160.  
  161.    However, there are differences between the conformance requirements
  162.    of ISO MOTIS and CCITT X.400(88) for mandatory support for the
  163.    complete OSI stack. ISO specify use of Normal-mode RTS as a mandatory
  164.    requirement with X.410-mode RTS as an additional option, whereas
  165.    CCITT require X.410-mode and have Normal-mode optional. The ISO
  166.    standard identifies three MTA types to provide options in RTS modes:
  167.  
  168.  
  169.  
  170. Houttuin & Craigie                                              [Page 3]
  171.  
  172. RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
  173.  
  174.  
  175.     - MTA Type A supports only Normal-mode RTS, and provides
  176.       interworking within a PRMD and with other PRMDs (conforming
  177.       to ISO 10021), and with ADMDs which have complete
  178.       implementations of X.400(88) or which conform to ISO 10021.
  179.  
  180.     - MTA Type B adds to the functionality of MTA type A the
  181.       ability to interwork with ADMDs implementing only the minimal
  182.       requirements of X.400(88), by requiring support for X.410-
  183.       mode RTS in addition to Normal-mode.
  184.  
  185.     - MTA Type C adds to the functionality of MTA type B the
  186.       ability to interwork with external X.400(84) Management
  187.       Domains (MDs, i.e., PRMDs and ADMDs), by requiring support for
  188.       downgrading (see 5.1) to the X.400(84) P1 protocol.
  189.  
  190.    The interworking between ISO and CCITT conformant systems is
  191.    summarised in the following table:
  192.  
  193.                                       CCITT
  194.  
  195.                             X.400(84)       X.400(88)
  196.                                          minimal   complete
  197.                                           implementation
  198.  
  199.    ISO 10021/   MTA Type A     N            N         Y
  200.    MOTIS        MTA Type B     N            Y         Y
  201.                 MTA Type C     Y            Y         Y
  202.  
  203.             Table 1: Interworking ISO <-> CCITT systems
  204.  
  205.    The RTS conformance difference would totally prevent interworking
  206.    between the two versions of the standard if implementations never
  207.    contained more than the minimum requirements for conformance, but in
  208.    practice many 88 implementations will be extensions of 84 systems,
  209.    and will thus support both modes of RTS. (At the moment we are aware
  210.    of only one product that doesn't support Normal mode.)
  211.  
  212.    Both ISO and CCITT standards require P7 (and P3) to be supported
  213.    directly over the Remote Operations Service (ROS), ISO 9072, and use
  214.    Normal-mode presentation (and not X.410-mode). Both allow optionally
  215.    ROS over RTS (in case the Transport Service doesn't provide an
  216.    adequately reliable service), again using Normal-mode and not X.410-
  217.    mode.
  218.  
  219.    CCITT made both Normal and X.410 mode mandatory in its X.400(92)
  220.    version, and it is expected that the 94 version will have the X.410
  221.    mode as an option only.
  222.  
  223.  
  224.  
  225.  
  226. Houttuin & Craigie                                              [Page 4]
  227.  
  228. RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
  229.  
  230.  
  231. 3. General Extension Mechanism
  232.  
  233.    One of the major assets in ISO 10021/X.400(88) is the extension
  234.    mechanism. This is used to carry most of the extensions defined in
  235.    these standards, but its principal benefit will be in reducing the
  236.    trauma of transitions to future versions of the standards. Provided
  237.    that implementations of the 88 standards do not try to place
  238.    restrictions on the values that may be present, any future extension
  239.    will be relayed by these implementations when appropriate (i.e., when
  240.    the extension is not critical), thus providing a painless migration
  241.    to new versions of the standards.
  242.  
  243. 4. Interworking
  244.  
  245. 4.1. Mixed 84/88 Domains
  246.  
  247.    ISO 10021-6/X.419(88) defines rules for interworking with X.400(84),
  248.    called downgrading. As X.400 specifies the interconnection of MDs,
  249.    these rules define the actions necessary by an X.400(88) MD to
  250.    communicate with an X.400(84) MD. The interworking rules thus apply
  251.    at domain boundaries. Although it would not be difficult to extend
  252.    these to rules to convert Internal Trace formats which might be
  253.    thought a sufficient addition to allow mixed X.400(84)/X.400(88)
  254.    domains, the problems involved in attempting to define mixed 84/88
  255.    domains are not quite that simple.
  256.  
  257.    The principle problem is in precisely defining the standard that
  258.    would be used between MTAs within an X.400(84) domain, as X.400(84)
  259.    only defines the interconnection of MDs. In practice, MTA
  260.    implementations either use X.400(84) unmodified, or X.400(84) with
  261.    the addition of Internal Trace from the first MOTIS DIS (DIS 8883),
  262.    or support MOTIS as defined in DIS 8505, DIS 8883, and DIS 9065. The
  263.    second option is recommended in the NBS Implementors Agreements, and
  264.    the third option is in conformance with the CEN/CENELEC MHS
  265.    Functional Standard [1], which requires as a minimum tolerance of all
  266.    "original MOTIS" protocol extensions. An 84 MD must decide which of
  267.    these options it will adopt, and then require all its MTAs to adopt
  268.    (or at least be compatible with) this choice. No doubt this is one of
  269.    the reasons for the almost total absence currently of mixed- vendor
  270.    X.400(84) MDs in the European R&D MHS community. The fact that none
  271.    of these three options for communication between MTAs within a domain
  272.    have any status within the standardisation bodies accounts for the
  273.    absence from ISO 10021/X.400(88) of detailed rules for interworking
  274.    within mixed 84/88 domains.
  275.  
  276.    Use of the first option, unmodified X.400(84), carries the danger of
  277.    undetectable routing loops occurring. Although these can only occur
  278.    if MTAs have inconsistent routing tables, the absence of standardised
  279.  
  280.  
  281.  
  282. Houttuin & Craigie                                              [Page 5]
  283.  
  284. RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
  285.  
  286.  
  287.    methods of disseminating routing information makes this a possibility
  288.    which if it occurred might cause severe disruption before being
  289.    detected. The only addition to the interworking rules needed for this
  290.    case is the deletion of Internal Trace when downgrading a message.
  291.  
  292.    Use of the second option, X.400(84) plus Internal Trace, allows the
  293.    detection and prevention of routing loops. Details of the mapping
  294.    between original-MOTIS Internal Trace and the Internal Trace of ISO
  295.    10021 can be found in Annex A. This should be applied not only when
  296.    downgrading from 88 to 84, but also in reverse when an 84 MPDU is
  297.    received by the 84/88 Interworking MTA. If the 84 domain properly
  298.    implements routing loop detection algorithms, then this will allow
  299.    completely consistent reception of messages by an 84 recipient even
  300.    after DL expansion or Redirection within that domain (but see also
  301.    section 5.3).  Unfortunately, the first DIS MOTIS like X.400(84) left
  302.    far too much to inference, so not all implementors may have
  303.    understood that routing loop detection algorithms must only consider
  304.    that part of the trace after the last redirection flag in the trace
  305.    sequence.
  306.  
  307.    Use of the third option, tolerance of all original-MOTIS extensions,
  308.    would in principle allow a still higher level of interworking between
  309.    the 84 and 88 systems. However, no implementations are known which do
  310.    more than relay the syntax of original-MOTIS extensions: there is no
  311.    capability to generate these protocol elements or ability to
  312.    correctly interpret their semantics.
  313.  
  314.    The choice between the first two options for mixed domains can be
  315.    left to individual management domains. It has no impact on other
  316.    domains provided the topology recommended in section 5 is adopted.
  317.  
  318. 4.2. Generation of OR-Name Extensions from X.400(84)
  319.  
  320.    The interworking rules defined in DIS 10021-6/X.419 Annex B allow for
  321.    delivery of 88 messages to 84 recipients, but do not make any 88
  322.    extensions available to 84 originators. In general this is an
  323.    adequate strategy. Most 88 extensions provide optional services or
  324.    have sensible defaults. The exception to this is the OR-Name
  325.    extensions. These fall into three categories: the new CommonName
  326.    attribute; fifteen new attributes for addressing physical delivery
  327.    recipients; and alternative Teletex (T.61) encodings for all
  328.    attributes that were defined as Printable Strings. Without some
  329.    mechanism to generate these attributes, 84 originators are unable to
  330.    address 88 recipients with OR-Addresses containing these attributes.
  331.    Such a mechanism is defined in RARE Technical Report 3 ([2]), "X.400
  332.    1988 to 1984 downgrading".
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Houttuin & Craigie                                              [Page 6]
  339.  
  340. RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
  341.  
  342.  
  343.    Common-name appears likely to be a widely used attribute because it
  344.    remedies a serious deficiency in the X.400(84) OR-Name: it provides
  345.    an attribute suitable for naming Distribution Lists and roles, and
  346.    even individuals where the constraints of the 84 personal-name
  347.    structure are inappropriate or undesirable. As 84 originators will no
  348.    doubt wish to be able to address 88 DLs (and roles), [2] defines a
  349.    Domain Defined Attribute (DDA) to enable generation of common-name by
  350.    84 originators. This consists of a DDA with its type set to "common-
  351.    name" and its value containing the Printable String encoding to be
  352.    set into the 88 common-name attribute.
  353.  
  354.    This requires that all European R&D MHS 88 MTAs capable of
  355.    interworking with 84 systems shall be able to map the value of
  356.    "common-name" DDA in OR-Names received from 84 systems to the 88
  357.    standard attribute extension component common-name, and vice versa.
  358.  
  359.    X.400(84) originators will only be able to make use of this ability
  360.    to address 88 common-name recipients if their system is capable of
  361.    generating DDAs. Unfortunately, one of the many serious deficiencies
  362.    with the CEN/CENELEC and CEPT 84 MHS Functional Standards ([1] and
  363.    [3]), as originally published, is that this ability is not a
  364.    requirement for all conformant systems. Thus if existing European R&D
  365.    MHS X.400(84) users wish to be able to address a significant part of
  366.    the ISO 10021/X.400(84) world they must explicitly ensure that their
  367.    84 systems are capable of generating DDAs. However, this will be a
  368.    requirement in the revised versions of ENV 41201 and ENV 41202, which
  369.    are to be published soon. There is no alternative mechanism for
  370.    providing this functionality to 84 users. It is estimated that
  371.    currently 95% of all European R&D MHS users are able to generate
  372.    DDAs.
  373.  
  374.    When messages are sent to both ISO 10021/X.400(88) and X.400(84)
  375.    recipients outside the European R&D MHS community, this
  376.    representation of common-name will not enable the external recipients
  377.    to communicate directly unless their 84/88 interworking MTA also
  378.    implements this mapping. However, use of this mapping within the
  379.    European R&D MHS community has not reduced external connectivity, and
  380.    provided RTR 3, RFC 1328 is universally implemented within this
  381.    community it will enhance connectivity within the community.
  382.  
  383.    As for the new Physical Delivery address attributes in X.400(88), RTR
  384.    3 (RFC1328) takes the following approach. A DDA with type "X400-88"
  385.    is used, whose value is an std-or encoding of the address as defined
  386.    in RARE Technical Report 2 ([4]), "Mapping between X.400(1988)/ISO
  387.    10021 and RFC 822". This allows source routing through an appropriate
  388.    gateway. Where the generated address is longer than 128 characters,
  389.    up to three overflow DDAs are used: X400-C1; X400-C2; X400-C3. This
  390.    solution is general, and does not require co-operation, i.e., it can
  391.  
  392.  
  393.  
  394. Houttuin & Craigie                                              [Page 7]
  395.  
  396. RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
  397.  
  398.  
  399.    be implemented in the gateways only.
  400.  
  401.    Note that the two DDA solutions mentioned above have the undesirable
  402.    property that the P2 heading will still contain the DDA form, unless
  403.    content upgrading is also done. In order to shield the user from
  404.    cryptic DDAs, such content upgrading is in general recommended, also
  405.    for nested forwarded messages, even though the available standards
  406.    and profiles do not dictate this.
  407.  
  408. 4.3. Distribution List Interworking with X.400(84)
  409.  
  410.    Before all X.400(84) systems are upgraded to ISO 10021, the
  411.    interaction of Distribution Lists with X.400(84) merits special
  412.    attention as DLs are already widely used.
  413.  
  414.    Nothing, apart perhaps from the inability to generate the DL's OR-
  415.    Address if the DL uses the common-name attribute, prevents an
  416.    X.400(84) originator from submitting a message to a DL.
  417.  
  418.    X.400(84) users can also be members (i.e., recipients) of a DL.
  419.    However, if the X.400(84) systems involved correctly implement
  420.    routing loop detection, the X.400(84) recipient may not receive all
  421.    messages sent to the DL. X.400(84) routing loop detection involves a
  422.    recipient MD in scanning previous entries in a message's trace
  423.    sequence for an occurrence of its own domain, and if such an entry is
  424.    found the message is non-delivered. The new standards extend the
  425.    trace information to contain flags to indicate DL-expansion and
  426.    redirection, and re-define the routing loop detection algorithm to
  427.    only examine trace elements from the last occurrence of either of
  428.    these flags. Thus 88 systems allow a message to re-traverse an MD (or
  429.    be relayed again by an MTA) after either DL-expansion or redirection.
  430.    However, these flags cannot be included in X.400(84) trace, so are
  431.    deleted on downgrading. Therefore the 84 DL recipient will receive
  432.    all messages sent to the DL except those which had a common point in
  433.    the path to the DL expansion point with the path from the expansion
  434.    points to his UA. This common point is an MD in the case of a DL in
  435.    another MD or an MTA in the case of a DL in the same MD. Although
  436.    this is quite deterministic behaviour, the user is unlikely to
  437.    understand it and instead regard it as erratic or inconsistent
  438.    behaviour.
  439.  
  440.    Another problem with X.400(84) DL members will be that delivery and
  441.    non-delivery reports will be sent back directly to the originator of
  442.    a message, rather than routed through the hierarchy of DL expansion
  443.    points where they could have been routed to the DL administrator
  444.    instead of (or as well as) the originator.
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Houttuin & Craigie                                              [Page 8]
  451.  
  452. RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
  453.  
  454.  
  455.    No general solution to this problem has yet been devised, despite
  456.    much thought from a number of experts. The nub of the problem is that
  457.    changing the downgrading rules to enable 84 recipients to receive all
  458.    such messages also allows the possibility of undetectable infinite DL
  459.    or redirection looping where there is an 84 transit domain.
  460.  
  461.    A potential solution is to extend the DL expansion procedures to
  462.    explicitly identify X.400(84) recipients and to treat them specially,
  463.    at least by deleting all trace prior to the expansion point. This
  464.    solution is only dangerous if another DL reached through an 84
  465.    transit domain is inadvertently configured as an 84 recipient, when
  466.    infinite looping could occur. It does however impose the problems of
  467.    84 interworking into MHS components which need to know nothing even
  468.    of the existence of X.400(84). It also requires changes to the
  469.    Directory attribute mhs-dl-members to accommodate the indication that
  470.    identifies the recipient as an X.400(84) user, unless European R&D
  471.    MHS DLs are restricted to being implemented by local tables rather
  472.    than making use of the Directory.
  473.  
  474.    A similar change would be required for Redirection. However, the
  475.    change for Redirection would have substantially more impact as it
  476.    would require European R&D MHS-specific MHS protocol extensions to
  477.    identify the redirected recipient as an X.400(84) user. If the
  478.    European R&D MHS adopts a reasonable quality of MHS(88) service, all
  479.    its MTAs would be capable of Redirection and all UAs would be capable
  480.    of requesting originator-specified-alternate-recipient and thus be
  481.    required to incorporate these non-standard additions. A special
  482.    European R&D MHS modification affecting all MTAs and UAs seems
  483.    impractical, too!
  484.  
  485.    If the recommended European R&D MHS topology for MHS migration (See
  486.    chapter 5) is adopted there will never be an X.400(84) transit domain
  487.    (or MTA) between two ISO 10021 systems. This allows the deletion of
  488.    trace prior to the last DL expansion or redirection to be performed
  489.    as part of the downgrading, giving the X.400(84) user a consistent
  490.    service. This solution has the advantage of only requiring changes at
  491.    the convertors between X.400(84) and ISO 10021/X.400(88), where other
  492.    European R&D MHS specific extensions have also been identified. A
  493.    precise specification of this solution is given in Annex A.
  494.  
  495.    Finally, problems might occur because some X.400(84) MTAs could
  496.    object to messages containing more than one recipient with the same
  497.    extension-id (called originally-requested-recipient-number in the new
  498.    standards), since this was not defined in X.400(84).  Note that
  499.    X.400(84) only requires that all extension-id's be different at
  500.    submission time, so 84 software that does not except messages with
  501.    identical extension-id's for relaying or delivery must be considered
  502.    broken.
  503.  
  504.  
  505.  
  506. Houttuin & Craigie                                              [Page 9]
  507.  
  508. RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
  509.  
  510.  
  511. 4.4. P2 Interworking
  512.  
  513.    RTR 3, RFC 1328 also defines the downgrading rules for P2 (IPM)
  514.    interworking: The IPM service in X.400(1984) is usually provided by
  515.    content type 2. In many cases, it will be useful for a gateway to
  516.    downgrade P2 from content type 22 to 2. This will clearly need to be
  517.    made dependent on the destination, as it is quite possible to carry
  518.    content type 22 over P1(1984). The decision to make this downgrade
  519.    will be on the basis of gateway configuration.
  520.  
  521.    When a gateway downgrades from 22 to 2, the following should be done:
  522.  
  523.     1. Strip any 1988 specific headings (language indication, and
  524.        partial message indication).
  525.  
  526.     2. Downgrade all O/R addresses, as described in Section 3.
  527.  
  528.     3. If a directory name is present, there is no method to
  529.        preserve the semantics within a 1984 O/R Address. However, it
  530.        is possible to pass the information across, so that the
  531.        information in the Distinguished Name can be informally
  532.        displayed to the end user. This is done by appending a text
  533.        representation of the Distinguished Name to the Free Form
  534.        Name enclosed in round brackets. It is recommended that the
  535.        "User Friendly Name" syntax is used to represent the
  536.        Distinguished Name [5]. For example:
  537.  
  538.           (Steve Hardcastle-Kille, Computer Science,
  539.           University College London, GB)
  540.  
  541.     4. The issue of body part downgrade is discussed in Section 6.
  542.  
  543.    Note that a message represented as content type 22 may have
  544.    originated from [6]. The downgrade for this type of message can be
  545.    improved. This is discussed in RTR 2, RFC 1327.
  546.  
  547.    Note that the newer EWOS/ETSI recommendations specify further rules
  548.    for downgrading, which are not all completely compatible with the
  549.    rules in RTR 3, RFC 1328. This paper does not state which set of
  550.    rules is preferred for the European R&D MHS, it only states that a
  551.    choice will have to be made.
  552.  
  553.    As the transition topology recommended for the European R&D MHS is to
  554.    never use 84 transit systems between 88 systems, it is possible to
  555.    improve on the P2 originator downgrading and resending scenario. The
  556.    absence of 84 transit systems means that the necessity for a P1
  557.    downgrade implies that the recipient is on an 84 system, and thus
  558.    that it is better to downgrade 88 P2 contents to 84 P2 rather than to
  559.  
  560.  
  561.  
  562. Houttuin & Craigie                                             [Page 10]
  563.  
  564. RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
  565.  
  566.  
  567.    relay it in the knowledge that it will not be delivered.
  568.  
  569. 5. Topology for Migration
  570.  
  571.    Having decided that a transition from X.400(84) is appropriate, it is
  572.    necessary to consider the degree of planning and co- ordination
  573.    required to preserve interworking during the transition.
  574.  
  575.    It is assumed as a fundamental tenet that interworking must be
  576.    preserved during the transition. This requires that one or more
  577.    system in the European R&D MHS community must act as a protocol
  578.    converter by implementing the rules for "Interworking with 1984
  579.    Systems" listed in Annex B of ISO 10021-6/X.419.
  580.  
  581.    When downgrading from ISO 10021/X.400(88) to X.400(84) all extensions
  582.    giving functionality beyond X.400(84) are discarded, or if a critical
  583.    extension is present then downgrading fails and a non-delivery
  584.    results. Thus, although it is possible to construct topologies of
  585.    interconnected MTAs so that two 88 MTAs can only communicate by
  586.    relaying through one or more 84 MTA, to maximise the quality of
  587.    service which can be provided in the European R&D MHS community it is
  588.    proposed that it require that no two European R&D MHS 88 MTAs shall
  589.    need to communicate by relaying through a X.400(84) MTA. Furthermore,
  590.    if this is extended to require that no two European R&D MHS 88 MTAs
  591.    shall ever communicate by relaying through an X.400(84) MTA, then the
  592.    European R&D MHS can provide enhanced interworking functionality to
  593.    its X.400(84) users.
  594.  
  595.    If mixed vintage 88 and 84 Management Domains (MDs) are created, the
  596.    routing loop detection rules, which specify that a message shall not
  597.    re-enter an MD it has previously traversed, require that downgrading
  598.    is performed within that mixed vintage MD. That MD therefore requires
  599.    at least one MTA capable of downgrading from 88 to 84. It is unlikely
  600.    that every MTA within an MD will be configured to act as an entry-
  601.    point to that MD from other MDs. However, the proposed European R&D
  602.    MHS migration topology requires that as soon as a domain has an 88
  603.    MTA it shall also have an 88 entry point - this may, of course, be
  604.    that same MTA.
  605.  
  606.    Even for MDs operating all the same MHS vintage internally, providing
  607.    entry-points for both MHS vintages will give considerable advantage
  608.    in maximising the connectivity to other MDs. Initially, it will be
  609.    particularly important for 88 MDs to be able to communicate with 84
  610.    only MDs, but as 88 becomes more widespread eventually the 84 MDs
  611.    will become a minority for which the ability to support 88 will be
  612.    important to maintain connectivity. For most practical MDs providing
  613.    entry-points that implement options in the supporting layers will
  614.    also be important. Support for at least the following is recommended
  615.  
  616.  
  617.  
  618. Houttuin & Craigie                                             [Page 11]
  619.  
  620. RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
  621.  
  622.  
  623.    at MD entry-points:
  624.  
  625.     88-P1/Normal-mode RTS/CONS/X.25(84)
  626.     88-P1/Normal-mode RTS/RFC1006/TCP/IP
  627.     84-P1/X.25(80)
  628.     84-P1/RFC1006/TCP/IP
  629.  
  630.    The above table omits layers where the choice is obvious (e.g.,
  631.    Transport class zero), or where no choice exists (e.g., RTS for 84-
  632.    P1).
  633.  
  634.    The requirement for no intermediate 84 systems does require that the
  635.    European R&D MHS use direct PRMD to PRMD routing between 88 PRMDs at
  636.    least until such time as all ADMDs will relay the 88 MHS protocols.
  637.  
  638.    Finally, in order to keep routing co-ordination overhead to a
  639.    minimum, an important requirement for the migration strategy is that
  640.    only one common set of routing procedures is used for both 84 and 88
  641.    systems in the European R&D MHS.
  642.  
  643. 6. Conclusion
  644.  
  645.     1. The transition from X.400(84) to ISO 10021/X.400(88) is
  646.        worthwhile for the European R&D MHS, to provide:
  647.  
  648.           - P7 Message Store to support remote UAs.
  649.           - Distribution Lists.
  650.           - Support for Directory Names.
  651.           - Standardised external Body Part types.
  652.           - Redirection.
  653.           - Security.
  654.           - Future extensibility.
  655.           - Physical Delivery.
  656.  
  657.     2. To minimise the number of transitions the European R&D MHS
  658.        target should be ISO 10021 rather than CCITT X.400(88) -
  659.        i.e., straight to use of the full OSI stack with Normal-mode
  660.        RTS.
  661.  
  662.     3. To give a useful quality of service, the European R&D MHS
  663.        should not use minimal 88 MTAs which relay the syntax but
  664.        understand none of the semantics of extensions. In
  665.        particular, all European R&D MHS 88 MTAs should generate
  666.        reports containing extensions copied from the subject message
  667.        and route reports through the DL expansion hierarchy where
  668.        appropriate.
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Houttuin & Craigie                                             [Page 12]
  675.  
  676. RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
  677.  
  678.  
  679.     4. The European R&D MHS should carefully plan the transition so
  680.        that it is never necessary to relay through an 84 system to
  681.        provide connectivity between any two 88 systems.
  682.  
  683.     5. The European R&D MHS should consider the additional
  684.        functionality that can be provided to X.400(84) users by
  685.        adopting an enhanced specification of the interworking rules
  686.        between X.400(84) and ISO 10021/X.400(88), and weigh this
  687.        against the cost of building and maintaining its own
  688.        convertors. The advantages to X.400(84) users are:
  689.  
  690.          - Ability to generate 88 common-name attribute, likely to
  691.            be widely used for naming DLs.
  692.          - Consistent reception of DL-expanded and Redirected
  693.            messages.
  694.          - Ability to receive extended 88 P2 contents
  695.            automatically downgraded to 84 P2.
  696.  
  697. 7. Security Considerations
  698.  
  699.    Security issues are not discussed in this memo.
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Houttuin & Craigie                                             [Page 13]
  731.  
  732. RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
  733.  
  734.  
  735. Appendix A - DL-expanded and Redirected Messages in X.400(84)
  736.  
  737.    This Annex provides an additional to the rules for "Interworking with
  738.    1984 Systems" contained in Annex B of ISO 10021-6/X.419,  to give
  739.    X.400(84) recipients consistent reception of messages  that have been
  740.    expanded by a DL or redirected.  It is applicable  only if the
  741.    transition topology for the European R&D MHS  recommended in section
  742.    3 is adopted.
  743.  
  744.    Replace the first paragraph of B.2.3 by:
  745.  
  746.    If an other-actions element is present in any trace- information-
  747.    elements, that other-actions element and all preceding trace-
  748.    information-elements shall be deleted. If an other-actions element is
  749.    present in any subject-intermediate-trace-information- elements, that
  750.    other-actions element shall be deleted.
  751.  
  752. Appendix B - Bibliography
  753.  
  754.    [1] ENV 41201, "Private MHS UA and MTA: PRMD to PRMD", CEN/CENELEC,
  755.        1988.
  756.  
  757.    [2] Kille, S., "X.400 1988 to 1984 downgrading", RTR 3, RFC 1328,
  758.        University College London, May 1992.
  759.  
  760.    [3] ENV 41202, "Protocol for InterPersonal Messaging between MTAs
  761.        accessing the Public MHS", CEPT, 1988.
  762.  
  763.    [4] Kille, S.  "Mapping between X.400(1988)/ISO 10021 and RFC 822",
  764.        RTR 2, RFC 1327; University College London. May 1992.
  765.  
  766.    [5] Kille, S., "Using the OSI Directory to achieve User Friendly
  767.        Naming", RFC 1484, ISODE Consortium, July 1993.
  768.  
  769.    [6] Crocker, D., "Standard for the Format of ARPA Internet Text
  770.        Messages", STD 11, RFC 822, University of Delaware, August 1982.
  771.  
  772.    [7] Craigie, J., "COSINE Study 8.2.2. Migration Strategy for
  773.        X.400(84) to X.400(88)/MOTIS", Joint Network Team, 1988.
  774.  
  775.    [8] Craigie, J., "ISO 10021-X.400(88): A Tutorial for those familiar
  776.        with X.400(84)", Computer Networks and ISDN systems 16, 153-160,
  777.        North-Holland, 1988.
  778.  
  779.    [9] Manros, C.-U., "The X.400 Blue Book Companion", ISBN 1 871802 00
  780.        8, Technology Appraisals Ltd, 1989.
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Houttuin & Craigie                                             [Page 14]
  787.  
  788. RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
  789.  
  790.  
  791.   [10] CCITT Recommendations X.400 - X.430, "Data Communication
  792.        Networks: Message Handling Systems", CCITT Red Book, Vol. VIII -
  793.        Fasc. VIII.7, Malaga-Torremolinos, 1984.
  794.  
  795.   [11] CCITT Recommendations X.400 - X.420 (ISO IS-10021), "Data
  796.        Communication Networks: Message Handling Systems", CCITT Blue
  797.        Book, Vol. VIII - Fasc. VIII.7, Melbourne, 1988.
  798.  
  799. Appendix C - MHS Terminology
  800.  
  801.    Message Handling is performed by four types of functional entity:
  802.    User Agents (UAs) which enable the user to compose, send, receive,
  803.    read and otherwise process messages; Message Transfer Agents (MTAs)
  804.    which provide store-and-forward relaying services; Message Stores
  805.    (MSs) which act on behalf of UAs located remotely from their
  806.    associated MTA (e.g., UAs on PCs or workstations); and Access Units
  807.    (AUs) which interface MHS to other communications media (e.g., Telex,
  808.    Teletex, Fax, Postal Services). Each UA (and MS, and AU) is served by
  809.    a single MTA, which provides that user's interface into the Message
  810.    Transfer Service (MTS).
  811.  
  812.    Collections of MTAs (and their associated UAs, MSs and AUs) which are
  813.    operated by or under the aegis of a single management authority are
  814.    termed a Management Domain (MD). Two types of MD are defined: an
  815.    ADMD, which provides a global public message relaying service
  816.    directly or indirectly to all other ADMDs; and a PRMD operated by a
  817.    private concern to serve its own users.
  818.  
  819.    A Message is comprised of an envelope and its contents. Apart from
  820.    the MTS content-conversion service, the content is not examined or
  821.    modified by the MTS which uses the envelope alone to provide the
  822.    information required to convey the message to its destination.
  823.  
  824.    The MTS is the store-and-forward message relay service provided by
  825.    the set of all MTAs. MTAs communicate with each other using the P1
  826.    Message Transfer protocol.
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Houttuin & Craigie                                             [Page 15]
  843.  
  844. RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
  845.  
  846.  
  847. Appendix D - Abbreviations
  848.  
  849.       ACSE     Association Control Service Element
  850.       ADMD     Administration Management Domain
  851.       ASCII    American Standard Code for Information Exchange
  852.       ASN.1    Abstract Syntax Notation One
  853.       AU       Access Unit
  854.       CCITT    Comite Consultatif International de Telegraphique et
  855.                Telephonique
  856.       CEN      Comite Europeen de Normalisation
  857.       CENELEC  Comite Europeen de Normalisation Electrotechnique
  858.       CEPT     Conference Europeene des Postes et Telecommunications
  859.       CONS     Connection Oriented Network Service
  860.       COSINE   Co-operation for OSI networking in Europe
  861.       DL       Distribution List
  862.       DIS      Draft International Standard
  863.       EN       European Norm
  864.       ENV      Draft EN, European functional standard
  865.       IEC      International Electrotechnical Commission
  866.       IPM      Inter-Personal Message
  867.       IPMS     Inter-Personal Messaging Service
  868.       IPN      Inter-Personal Notification
  869.       ISO      International Organisation for Standardisation
  870.       JNT      Joint Network Team (UK)
  871.       JTC      Joint Technical Committee (ISO/IEC)
  872.       MD       Management Domain (either an ADMD or a PRMD)
  873.       MHS      Message Handling System
  874.       MOTIS    Message-Oriented Text Interchange Systems
  875.       MTA      Message Transfer Agent
  876.       MTL      Message Transfer Layer
  877.       MTS      Message Transfer System
  878.       NBS      National Bureau of Standardization
  879.       OSI      Open Systems Interconnection
  880.       PRMD     Private Management Domain
  881.       RARE     Reseaux Associes pour la Recherche Europeenne
  882.       RFC      Request for Comments
  883.       RTR      RARE Technical Report
  884.       RTS      Reliable Transfer Service
  885.       WG-MSG   RARE Working Group on Mail and Messaging
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Houttuin & Craigie                                             [Page 16]
  899.  
  900. RFC 1615         Migrating from X.400(84) to X.400(88)          May 1994
  901.  
  902.  
  903. Authors' Addresses
  904.  
  905.    Jeroen Houttuin
  906.    RARE Secretariat
  907.    Singel 466-468
  908.    NL-1017 AW Amsterdam
  909.    Europe
  910.  
  911.    Phone: +31 20 6391131
  912.    RFC 822: houttuin@rare.nl
  913.    X.400: C=NL;ADMD=400net;PRMD=surf;
  914.    O=rare;S=houttuin;
  915.  
  916.  
  917.    Jim Craigie
  918.    Joint Network Team
  919.    Rutherford Appleton Laboratory
  920.    UK-OX11 OQX Chilton
  921.    Didcot, Oxfordshire
  922.    Europe
  923.  
  924.    Phone: +44 235 44 5539
  925.    RFC 822: J.Craigie@jnt.ac.uk
  926.    X.400: C=GB;ADMD= ;PRMD=UK.AC;
  927.    O=jnt;I=J;S=Craigie;
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Houttuin & Craigie                                             [Page 17]
  955.  
  956.