From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1328.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) create mode 100644 doc/rfc/rfc1328.txt (limited to 'doc/rfc/rfc1328.txt') diff --git a/doc/rfc/rfc1328.txt b/doc/rfc/rfc1328.txt new file mode 100644 index 0000000..1b78f3d --- /dev/null +++ b/doc/rfc/rfc1328.txt @@ -0,0 +1,283 @@ + + + + + + +Network Working Group S. Hardcastle-Kille +Request for Comments: 1328 University College London + May 1992 + + + X.400 1988 to 1984 downgrading + +Status of this Memo + + This RFC specifies an IAB standards track protocol for the Internet + community, and requests discussion and suggestions for improvements. + Please refer to 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 considers issues of downgrading from X.400(1988) to + X.400(1984) [MHS88a, MHS84]. Annexe B of X.419 specifies some + downgrading rules [MHS88b], but these are not sufficient for + provision of service in an environment containing both 1984 and 1988 + components. This document defines a number of extensions to this + annexe. + + This specification is not tutorial. COSINE Study 8.2 by J.A.I. + Craigie gives a useful overview [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 to be used, it it important for there to be 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. + +2. Avoiding Downgrading + + Perhaps the most important consideration is to configure systems so + as to minimise the need for downgrading. Use of 1984 systems to + interconnect 1988 systems should be strenuously avoided. + + In practice, many of the downgrading issues will be avoided. When a + 1988 originator sends to a 1984 recipient, 1988 specific features + will not be used as they will not work! For distribution lists with + 1984 and 1988 recipients, messages will tend to be "lowest common + denominator". + + + + +Hardcastle-Kille [Page 1] + +RFC 1328 X.400 1988 to 1984 downgrading May 1992 + + +3. Addressing + + In general there is a problem with O/R addresses which use 88 + specific features. The X.419 downgrade approach will mean 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). This 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 to optimise for a form of X.400(88) address which is + expected to be used frequently (Common Name). The second approach + requires cooperation from all X.400(88) UAs and MTAs which are + involved in these interactions. + +3.1 General Approach + + The first approach is to use a DDA "X400-88". The DDA value is an + std-or encoding of the address as defined in RFC 1327 [Kil92]. This + will allow source routing through an appropriate gateway. This + solution is general, and 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 not in the printable string + set (typically to handle teletext versions). To enable this to be + handled, the std-or encoded in encapsulated into 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, this 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. + + + +Hardcastle-Kille [Page 2] + +RFC 1328 X.400 1988 to 1984 downgrading May 1992 + + + Therefore, this approach requires that all 1988 MTAs and UAs which + wish 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 which support 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 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 appendend 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. + + + + + +Hardcastle-Kille [Page 3] + +RFC 1328 X.400 1988 to 1984 downgrading May 1992 + + +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. + 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 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. + + + + + + + +Hardcastle-Kille [Page 4] + +RFC 1328 X.400 1988 to 1984 downgrading May 1992 + + +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. + +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 + + + + + + + + + + +Hardcastle-Kille [Page 5] + \ No newline at end of file -- cgit v1.2.3