Movatterモバイル変換

Network Working Group                                S. Hardcastle-KilleRequest for Comments: 1328                     University College London                                                                May 1992X.400 1988 to 1984 downgradingStatus 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 19923.  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 inRFC 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 ofSection 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 inSection 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 inSection 6.Hardcastle-Kille                                                [Page 3]

RFC 1328             X.400 1988 to 1984 downgrading             May 19925.1RFC 822 Considerations   A message represented as content type 22 may have originated fromRFC822 [Cro82].  The downgrade for this type of message can be improved.   This is discussed inRFC 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 1992References   [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 andRFC822",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.UKHardcastle-Kille                                                [Page 5]