RFC 1328

X.400 1988 to 1984 downgrading 🎀

okay bestie, this is RFC 1328 and it is about downgrading X.400(1988) back to X.400(1984) ✨

Network Working Group 🌸 Request for Comments: 1328 💖 Author: S. Hardcastle-Kille, University College London 🎓 Category: IAB standards track protocol 🦋 Date: May 1992 🗓️ Obsoletes and updates: none listed in the title block 🙈

---

Status of This Memo 📜

This RFC specifies an IAB standards track protocol for the Internet community, and it requests discussion and suggestions for improvements. 💬 Check the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. 📋 Distribution of this memo is unlimited. 🌍

Abstract 🦋

This document looks at issues with downgrading from X.400(1988) to X.400(1984) [MHS88a, MHS84]. 🔄 Annexe B of X.419 has some downgrading rules [MHS88b], but they aren't enough to keep service working in an environment that has both 1984 and 1988 components. 😬 So this document defines a number of extensions to that annexe. ✨

This specification is not tutorial. 📖 If you want a useful overview, COSINE Study 8.2 by J.A.I. Craigie is the one to read [Cra88]. 💅

---

1. The need to Downgrade ✨

It is expected that X.400(1988) systems will be extensively deployed, whilst there is still substantial use of X.400(1984). 📈 If 1988 features are going to be used, it is important to have a clear approach to downgrading. 🧭 This document specifies an approach to downgrading for the Internet and COSINE communities. 🌐 As 1988 is a strict superset of 1984, the mapping is a one-way problem. ➡️ Iconic, honestly. 👑

2. Avoiding Downgrading 🚫

Perhaps the most important consideration is to configure systems so as to minimise the need for downgrading. 🧠 Using 1984 systems to interconnect 1988 systems should be strenuously avoided. 🙅‍♀️

In practice, a lot of the downgrading issues will just be avoided. ✨ When a 1988 originator sends to a 1984 recipient, 1988 specific features will not be used, because they will not work! 💀 For distribution lists with 1984 and 1988 recipients, messages will tend to be "lowest common denominator". 🫶

3. Addressing 📬

In general there is a problem with O/R addresses that use 88 specific features. 😩 The X.419 downgrade approach means that addresses using these features cannot be specified from 84 systems. 🚧 Worse, a message originating from such an address cannot be transferred into X.400(1984). 😭 That is unacceptable. 🙅‍♀️ Two approaches are defined. 🪄 The first is a general purpose mechanism, which can be implemented by the gateway only. 🌉 The second is a special purpose mechanism that optimises for a form of X.400(88) address which is expected to be used frequently (Common Name). 🪪 That second approach requires cooperation from all X.400(88) UAs and MTAs involved in these interactions. 🤝

3.1. General Approach 🧩

The first approach uses a DDA "X400-88". 💜 The DDA value is an std-or encoding of the address, as defined in RFC 1327 [Kil92]. 🎀 This allows source routing through an appropriate gateway. 🛣️ This solution is general, and it does not require co-operation. 🙌 For example:

88:
     PD-ADDRESS=Empire State Building;  PRMD=XX; ADMD=ZZ; C=US;

84:
     O=MHS-Relay; PRMD=UK.AC; C=GB;
     DD.X400-88=/PD-ADDRESS=Empire State Building/PRMD=XX/ADMD=ZZ/C=US/;

The std-or syntax can use IA5 characters that are not in the printable string set (typically to handle teletext versions). 📠 To make this work, the std-or is encapsulated into a printable string using the mappings of Section 3.4 of RFC 1327. 🔁 Where the generated address is longer than 128 characters, up to three overflow domain defined attributes are used: X400-C1; X400-C2; X400-C3. 🧳

3.2. Common Name 🪪

Where a common name attribute is used, it is downgraded to the Domain Defined Attribute "Common". 🏷️ For example:

88:
    CN=Postmaster; O=A; ADMD=B; C=GB;

84:
    DD.Common=Postmaster; O=A; ADMD=B; C=GB;

The downgrade will always happen correctly. ✅ However, it will not always be possible for the gateway to do the reverse mapping. 🙃

So this approach requires that all 1988 MTAs and UAs which want to interact with 1984 systems through gateways following this specification will need to understand the equivalence of these two forms of address. 🤓🫶

4. MTS 🚚

Annexe B of X.419 is sufficient, apart from the addressing. 👍

The discard of envelope fields is unfortunate. 😔 However, the criticality mechanism ensures that no information the originator specifies to be critical is discarded. 🛡️ There is no sensible alternative. 🤷‍♀️ If mapping to a system that supports the MOTIS-86 trace extensions, it is recommended that the internal trace of X.400(88) is mapped on to this, noting the slight differences in syntax. 🔍

5. IPM Downgrading 📨

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 depend 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 [Kil90]. For example:

(Steve Hardcastle-Kille, Computer Science,
 University College London, GB)

4. The issue of body part downgrade is discussed in Section 6. 🖼️

5.1. RFC 822 Considerations 📮

A message represented as content type 22 may have originated from RFC 822 [Cro82]. 💌 The downgrade for this type of message can be improved, and this is discussed in RFC 1327 [Kil92]. 🌟

6. Body Part downgrading 🖼️

The issue of body part downgrade is very much linked up with the whole issue of body part format conversion. 🔗 If no explicit conversion is requested, conversion depends on the MTA knowing the remote UA's capabilities. 🧠 The following options are available for body part conversion in all cases, including this one. 📋 It is assumed that body part conversion is avoided where possible. 🙏

1. Downgrade to a standard 1984 body part, without loss of information
2. Downgrade to a standard 1984 body part, with loss of information
3. Discard the body part, and replace it with a (typically IA5 text) message. For example:

**********************************************
*
*  There was a hologram here which could
*  not be converted
*
**********************************************

4. Bounce the message 🏀

If conversion is prohibited, 4) must be done. 🚫 If conversion-with-loss is prohibited, 1) should be done if possible, otherwise 4). 🔁 In other cases, 2) should be done if possible. 🫶 If it is not possible, the choice between 3) and 4) should be a configuration choice. ⚙️ X.419 only recognises 4). 🙄 3) seems to be a useful choice in practice, particularly where the message contains other body parts. 💖 Another option is available when downgrading:

1. Encapsulate the body part as a Nationally Defined 1984 body part (body part 7).

This should be used when configured for the recipient UA. 🎯

Heads up: the choices in this section are not all equal. Read the "must", "should", and "if possible" bits carefully, because implementers rely on every one of them. 🚨

---

References 📚

• [Cra88] Craigie, J., "Migration strategy for x.400(84) to x.400(88)/MOTIS", COSINE Specification Phase 8.2, RARE, 1988.
• [Cro82] Crocker, D., "Standard of the Format of ARPA Internet Text Messages", RFC 822, UDEL, August 1982.
• [Kil90] Kille, S., "Using the OSI directory to achieve user friendly naming", Research Note RN/90/29, Department of Computer Science, University College London, February 1990.
• [Kil92] Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC 822", RFC 1327, University College London, May 1992.
• [MHS84] Recommendations X.400, October 1984. CCITT SG 5/VII, Message Handling Systems: System Model - Service Elements.
• [MHS88a] CCITT recommendations X.400 / ISO 10021, April 1988. CCITT SG 5/VII / ISO/IEC JTC1, Message Handling: System and Service Overview.
• [MHS88b] CCITT recommendations X.419 / ISO 10021, April 1988. CCITT SG 5/VII / ISO/IEC JTC1, Message Handling: Protocol Specifications.

7. Security Considerations 🔐

Security issues are not discussed in this memo. 😱

Yes, you read that right: this memo does not discuss security issues at all. 💀 Please take that seriously, bestie, and go look for security guidance elsewhere before you deploy any of this. 🫶

8. Author's Address 🎀

Steve Hardcastle-Kille
Department of Computer Science
University College London
Gower Street
WC1E 6BT
England

Phone:  +44-71-380-7294
EMail:  S.Kille@CS.UCL.AC.UK

that's the whole RFC, bestie! 🌈✨