rfc1615.txt

中、英文RFC文档大全打包下载完全版 .

   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