doc: Add RFC documents

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