RFC 1615

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

📅 published May 1994, from ietf

RFC 1615: Migrating from X.400(84) to X.400(88) 🦋

Okay bestie, the title block is giving main character energy 🎀 This is RFC 1615 from the Network Working Group, dated May 1994 ✨. It's Category: Informational, so it's sharing info with the Internet community, not laying down a standard 🌸 It's also RARE Technical Report: 9. The authors are J. Houttuin of the RARE Secretariat and J. Craigie of the Joint Network Team 🫶 The title block doesn't list anything it obsoletes or updates, so no drama there 💅

Status of This Memo 📜

This memo gives info to the Internet community and that's it 🙈 It doesn't specify an Internet standard of any kind. Distribution is unlimited, so share it with everyone 💜

Scope 🔭

So this one is set in a European pilot for an X.400(88) messaging service 🇪🇺 and it compares that service to its X.400(84) predecessor 💅 It's aimed at a technical crowd who already knows electronic mail in general and X.400 protocols in particular ✨

Abstract 💌

This doc compares X.400(88) to X.400(84) and lays out what problems you can expect during the migration 🦋 It's especially about moving off the existing X.400(84) infrastructure that the COSINE MHS project built and onto an X.400(88) infrastructure 🌈 It covers the technical complications, but it also covers how the transition hits end users, especially when 84 and 88 users need to talk to each other 🫶

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
   Appendix D - Abbreviations                                       16
   Authors' Addresses                                               17

1. New Functionality ✨

Okay so besides the standard being way more mature, and actually making proper use of the Presentation Layer (periodt 💅), here's what the European R&D world will be obsessed with in X.400(88) that X.400(84) just doesn't have:

  • 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 is a server for remote User Agents (UAs) on Workstations and PCs, so messages can be held for their recipient. That solves the problems of non-continuous availability and variable network addresses for those UAs. It has powerful selection mechanisms, so the user can pick which messages from the store get transferred to the workstation/PC. The P3 protocol of X.400(84) doesn't handle this well, so this is a major incentive to transition 🔥
  • Use of X.500 Directories 🧚 Directory Names can be used in MHS, so you can move from O/R Addresses to Directory Names once X.500 Directories become widespread. Users won't need to know about MHS topological addressing components anymore 🙌
  • Message Security services, including authentication, confidentiality, integrity and non-repudiation, plus secure access between MHS components 🔐 This may be important for a section of the research community.
  • Redirection of messages, both by the recipient if they're temporarily unable to receive them, and by the originator if delivery to the intended recipient fails 🦋
  • Additional message body encodings, such as ISO 8613 ODA (Office Document Architecture) reformattable documents or proprietary word processor formats 📄
  • Physical Delivery services 📬 These deliver an electronic message on a physical medium (such as paper) through the normal postal delivery services to a recipient who (presumably) doesn't use electronic mail. Lowkey iconic.
  • Different body parts 🎨 On top of the extensible externally defined body parts, the most common types are predefined in the standard. To give end-users a real advantage over 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 💜

  • Extended character sets, both in O/R addresses and in the General Text extended bodypart 🌈 As a minimum, the character sets described in the European profiles will be supported. A management domain may choose, as an internal matter, which character sets it wants to support when generating. But all user agents must be able to copy any O/R address (in local address books and in replies), even if it contains character sets the agent can't interpret itself. That's giving inclusive energy 🫶

2. OSI Supporting Layers 🧩

Since 1984, the OSI Upper Layer Architecture has matured enough that the new MHS standards can sit on the complete OSI stack, which X.400(84) couldn't do 🌸 There's a new definition of the Reliable Transfer Service (RTS), ISO 9066 ✨ It has a mode of operation called Normal-mode, which uses ACSE and the OSI Presentation Layer. It also defines a second mode that's compatible with X.410(84) RTS, which was only meant for interworking with X.400(84) systems 🦋

But the conformance requirements of ISO MOTIS and CCITT X.400(88) don't match when it comes to mandatory support for the complete OSI stack 👀 ISO specifies Normal-mode RTS as mandatory, with X.410-mode RTS as an extra option. CCITT, on the other hand, requires X.410-mode and makes Normal-mode optional 💅 The ISO standard names three MTA types that offer options in the RTS modes:

  • MTA Type A supports only Normal-mode RTS. It provides interworking within a PRMD and with other PRMDs (conforming to ISO 10021), and with ADMDs that have complete implementations of X.400(88) or that conform to ISO 10021 ✨
  • MTA Type B adds to MTA Type A by letting it interwork with ADMDs that only implement the minimal requirements of X.400(88). It does this by requiring support for X.410-mode RTS as well as Normal-mode 🌈
  • MTA Type C adds to MTA Type B by letting it interwork with external X.400(84) Management Domains (MDs, i.e., PRMDs and ADMDs). It does this 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

Here's the thing: the RTS conformance difference would totally block interworking between the two versions if implementations never went past the minimum requirements. But in practice, lots of 88 implementations will be extensions of 84 systems, so they'll support both RTS modes 🙌 (At the moment, we're only aware of 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, using Normal-mode presentation (and not X.410-mode) 💖 Both also allow ROS over RTS optionally, in case the Transport Service isn't reliable enough, and that again uses Normal-mode and not X.410-mode.

CCITT made both Normal and X.410 mode mandatory in its X.400(92) version 😭 It's expected that the 94 version will make X.410 mode an option only 🌸

3. General Extension Mechanism 🎀

Okay, the extension mechanism in ISO 10021/X.400(88) is one of the biggest assets 🫶 It carries most of the extensions defined in these standards, but its real superpower is cutting the trauma of moving to future versions. As long as implementations of the 88 standards don't try to put restrictions on the values that may be present, any future extension will get relayed by these implementations when appropriate (i.e., when the extension isn't critical). That means a painless migration to new versions 🦋✨

4. Interworking 🌈

4.1. Mixed 84/88 Domains 🌸

okay so ISO 10021-6/X.419(88) has rules for interworking with X.400(84), and they're called downgrading 💅. X.400 is all about how MDs connect to each other, so these rules spell out what an X.400(88) MD has to do to talk to an X.400(84) MD. That means the interworking rules only kick in at domain boundaries 🦋. Now, you might think, "just extend these to convert Internal Trace formats and we're done," and honestly that wouldn't be hard. Internal Trace might even seem like enough to make mixed X.400(84)/X.400(88) domains work 🤔. But defining mixed 84/88 domains is not quite that simple 😭.

The main problem is pinning down the standard used between MTAs inside an X.400(84) domain, because X.400(84) only defines the interconnection of MDs 🙈. In practice, MTA implementations do one of three things. They either use X.400(84) unmodified, or X.400(84) with Internal Trace from the first MOTIS DIS (DIS 8883), or they support MOTIS as defined in DIS 8505, DIS 8883, and DIS 9065. The second option is recommended in the NBS Implementors Agreements 🍓. The third option conforms to 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) that choice. No doubt this is one of the reasons for the almost total absence right now of mixed-vendor X.400(84) MDs in the European R&D MHS community 🥲. None of these three options for communication between MTAs within a domain have any status within the standardisation bodies, and that's why ISO 10021/X.400(88) has no detailed rules for interworking within mixed 84/88 domains. Not iconic of them, honestly 💀.

Option one, unmodified X.400(84), carries the danger of undetectable routing loops. These can only happen if MTAs have inconsistent routing tables. Since there are no standardised methods of disseminating routing information, this is a real possibility, and if it did happen it could cause severe disruption before anyone noticed 😱. The only addition to the interworking rules needed for this case is deleting Internal Trace when downgrading a message.

Option two, X.400(84) plus Internal Trace, lets you detect and prevent routing loops ✨. You can find the mapping between original-MOTIS Internal Trace and the Internal Trace of ISO 10021 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 an 84 recipient can get completely consistent reception of messages, 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 the part of the trace after the last redirection flag in the trace sequence 🙃.

Option three, tolerance of all original-MOTIS extensions, would in principle allow an even higher level of interworking between the 84 and 88 systems 🌈. However, no implementations are known that do more than relay the syntax of original-MOTIS extensions. There's no capability to generate these protocol elements, and no 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, as long as the topology recommended in section 5 is adopted ⭐.

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

The interworking rules in DIS 10021-6/X.419 Annex B allow 88 messages to be delivered to 84 recipients, but they don't make any 88 extensions available to 84 originators 🤷‍♀️. Generally this is a fine strategy, because most 88 extensions are optional services or have sensible defaults. The exception 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 can't address 88 recipients with OR-Addresses containing them 😩. That mechanism is defined in RARE Technical Report 3 ([2]), "X.400 1988 to 1984 downgrading".

Common-name looks like it's going to be a popular attribute, and it makes sense 🫶. It fixes a serious gap in the X.400(84) OR-Name: it gives you an attribute for naming Distribution Lists and roles, and even individuals where the constraints of the 84 personal-name structure are inappropriate or undesirable 💖. 84 originators will absolutely want to address 88 DLs (and roles), so [2] defines a Domain Defined Attribute (DDA) that lets 84 originators generate common-name. It's a DDA with its type set to common-name, and its value contains 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 a 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 can only use this ability to address 88 common-name recipients if their system is capable of generating DDAs 🥺. Here's the tea: one of the many serious deficiencies in 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 💀. So if existing European R&D MHS X.400(84) users want to address a significant part of the ISO 10021/X.400(84) world, they must explicitly ensure their 84 systems can generate DDAs. 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 giving 84 users this functionality. It's 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 won't let the external recipients communicate directly, unless their 84/88 interworking MTA also implements this mapping 😬. But using this mapping inside the European R&D MHS community hasn't reduced external connectivity. And as long as RTR 3, RFC 1328 is universally implemented within this community, it will actually enhance connectivity within the community 🌈.

For the new Physical Delivery address attributes in X.400(88), RTR 3 (RFC1328) takes a different approach 🦋. It uses a DDA with type X400-88, 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 🚪. When 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 it doesn't require co-operation, which means it can be implemented in the gateways only 💅.

Note that both DDA solutions above have an undesirable property: the P2 heading will still contain the DDA form, unless content upgrading is also done 😵‍💫. To shield the user from cryptic DDAs, content upgrading is generally recommended, including for nested forwarded messages, even though the available standards and profiles don't dictate it 🫶.

4.3. Distribution List Interworking with X.400(84) 📬

okay so bestie, before every X.400(84) system gets upgraded to ISO 10021, we need to talk about how Distribution Lists (DLs) interact with X.400(84) 💖. DLs are already super popular, so this one matters a LOT.

Honestly, nothing stops an X.400(84) originator from sending a message to a DL 💌, except maybe one thing: they might not be able to generate the DL's OR-Address if the DL uses the common-name attribute 🙈.

X.400(84) users can also be members (aka recipients) of a DL 🫶. BUT if the X.400(84) systems involved correctly implement routing loop detection, the 84 recipient may not receive all messages sent to the DL 😭. The 84 way of doing loop detection is that a recipient MD scans the previous entries in a message's trace sequence for an occurrence of its own domain 🔍. If it finds one, the message is non-delivered 💀.

The new standards level up the trace info 🆙. They add flags to indicate DL-expansion and redirection, and the loop detection algorithm gets redefined so it only examines trace elements from the last occurrence of either of these flags ✨. So 88 systems allow a message to re-traverse an MD (or be relayed again by an MTA) after either DL-expansion or redirection. Here's the catch though: these flags cannot be included in X.400(84) trace, so they 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 will instead regard it as erratic or inconsistent behaviour 🤷‍♀️.

Another problem for X.400(84) DL members is that delivery and non-delivery reports get sent back directly to the originator of a message 📨. They are not 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.

No general solution to this problem has been devised yet, despite a lot of brainpower from a number of experts 🧠. The nub of the problem is that changing the downgrading rules so 84 recipients 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 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, because then 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, because 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 💅.

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 lots of cases it'll 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, because it is quite possible to carry content type 22 over P1(1984). The decision to make this downgrade is based on 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)
  1. 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, and this is discussed in RTR 2, RFC 1327 🌈.

Note that the newer EWOS/ETSI recommendations specify further rules for downgrading, and these 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 the recipient is on an 84 system. So it is better to downgrade 88 P2 contents to 84 P2 rather than 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 systems in the European R&D MHS community 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 come into play. These specify that a message shall not re-enter an MD it has previously traversed, and they 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 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 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 ✨

okay bestie, this is the big takeaway section and it's so clean 💅 here are the five things the European R&D MHS needs to know:

  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). In other words, go straight to 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. These are the ones that 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.
  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. no detours allowed, periodt 💀
  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). It should also weigh that 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 🔒

okay this part is short but it's serious 😭 the memo says it straight up:

Security issues are not discussed in this memo.

so no security vibes are being checked here, bestie. if you're building on this, look at security somewhere else 🫶

Appendix A - DL-expanded and Redirected Messages in X.400(84) 🎀

this annex is an add-on to the "Interworking with 1984 Systems" rules in Annex B of ISO 10021-6/X.419. its whole purpose is to give X.400(84) recipients consistent reception of messages that have been expanded by a DL or redirected 💌 it only applies if the transition topology recommended in section 3 is adopted. main character energy, iykyk 🦋

replace the first paragraph of B.2.3 with the following:

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.
  • [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 🧚

okay so message handling has four kinds of functional entity, and they all have their own job 💖

  • User Agents (UAs) let the user compose, send, receive, read and otherwise process messages.
  • Message Transfer Agents (MTAs) provide store-and-forward relaying services.
  • Message Stores (MSs) act on behalf of UAs that sit remotely from their associated MTA, like UAs on PCs or workstations.
  • Access Units (AUs) interface MHS with other communications media, like Telex, Teletex, Fax and Postal Services.

each UA (and MS, and AU) is served by a single MTA, which is that user's interface into the Message Transfer Service (MTS) 🌸

collections of MTAs (plus their UAs, MSs and AUs) that are operated by or under the aegis of a single management authority are called a Management Domain (MD). there are two types of MD:

  • an ADMD, which gives a global public message relaying service, directly or indirectly, to all other ADMDs.
  • a PRMD, which is operated by a private concern to serve its own users.

a Message is made up of an envelope and its contents. aside from the MTS content-conversion service, the content isn't examined or modified by the MTS. the MTS uses the envelope alone to get the info it needs to deliver the message to its destination 📨

the MTS is the store-and-forward message relay service provided by the set of all MTAs. MTAs talk to each other using the P1 Message Transfer protocol 🔥

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

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;
📦 where this page comes from