diff options
Diffstat (limited to 'doc/rfc/rfc1615.txt')
| -rw-r--r-- | doc/rfc/rfc1615.txt | 955 |
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] + |