summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1328.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1328.txt')
-rw-r--r--doc/rfc/rfc1328.txt283
1 files changed, 283 insertions, 0 deletions
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