As per Relevance of the word approach, we have this rfc below:
Network Working Group S. Hardcastle-
Request for Comments: 1328 University College
May 1992
X.400 1988 to 1984
Status of this
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
This document considers issues of downgrading from X.400(1988)
X.400(1984) [MHS88a, MHS84]. Annexe B of X.419 specifies
downgrading rules [MHS88b], but these are not sufficient
provision of service in an environment containing both 1984 and 1988
components. This document defines a number of extensions to
annexe
This specification is not tutorial. COSINE Study 8.2 by J.A.I
Craigie gives a useful overview [Cra88].
1. The need to
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
approach to downgrading. This document specifies an approach
downgrading for the Internet and COSINE communities. As 1988 is
strict superset of 1984, the mapping is a one-way problem
2. Avoiding
Perhaps the most important consideration is to configure systems
as to minimise the need for downgrading. Use of 1984 systems
interconnect 1988 systems should be strenuously avoided
In practice, many of the downgrading issues will be avoided. When
1988 originator sends to a 1984 recipient, 1988 specific
will not be used as they will not work! For distribution lists
1984 and 1988 recipients, messages will tend to be "lowest
denominator".
Hardcastle-Kille [Page 1]
RFC 1328 X.400 1988 to 1984 downgrading May 1992
3.
In general there is a problem with O/R addresses which use 88
specific features. The X.419 downgrade approach will mean
addresses using these features cannot be specified from 84 systems
Worse, a message originating from such an address cannot
transferred into X.400(1984). This is unacceptable. Two
are defined. The first is a general purpose mechanism, which can
implemented by the gateway only. The second is a special
mechanism to optimise for a form of X.400(88) address which
expected to be used frequently (Common Name). The second
requires cooperation from all X.400(88) UAs and MTAs which
involved in these interactions
3.1 General
The first approach is to use a DDA "X400-88". The DDA value is
std-or encoding of the address as defined in RFC 1327 [Kil92].
will allow source routing through an appropriate gateway.
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
set (typically to handle teletext versions). To enable this to
handled, the std-or encoded in encapsulated into printable
using the mappings of Section 3.4 of RFC 1327. Where the
address is longer than 128 characters, up to three overflow
defined attributes are used: X400-C1; X400-C2; X400-C3.
3.2 Common
Where a common name attribute is used, this is downgraded to
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
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
wish to interact with 1984 systems through gateways following
specification will need to understand the equivalence of these
forms of address
4.
Annexe B of X.419 is sufficient, apart from the addressing
The discard of envelope fields is unfortunate. However,
criticality mechanism ensures that no information the
specifies to be critical is discarded. There is no
alternative. If mapping to a system which support the MOTIS-86
extensions, it is recommended that the internal trace of X.400(88)
mapped on to this, noting the slight differences in syntax
5. IPM
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
content type 22 to 2. This will clearly need to be made dependent
the destination, as it is quite possible to carry content type 22
over P1(1984). The decision to make this downgrade will be on
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,
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
the semantics within a 1984 O/R Address. However, it
possible to pass the information across, so that the
in the Distinguished Name can be informally displayed to
end user. This is done by appendend a text representation
the Distinguished Name to the Free Form Name enclosed in
brackets. It is recommended that the "User Friendly Name
syntax is used to represent the Distinguished Name [Kil90].
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
A message represented as content type 22 may have originated from
822 [Cro82]. The downgrade for this type of message can be improved
This is discussed in RFC 1327 [Kil92].
6. Body Part
The issue of body part downgrade is very much linked up with
whole issue of body part format conversion. If no
conversion is requested, conversion depends on the MTA knowing
remote UA's capabilities. The following options are available
body part conversion in all cases, including this one. It is
that body part conversion is avoided where possible
1. Downgrade to a standard 1984 body part, without loss
2. Downgrade to a standard 1984 body part, with loss of
3. Discard the body part, and replace with a (typically IA5 text
message. For example
**********************************************
*
* There was a hologram here which
* not be
*
**********************************************
4. Bounce the
If conversion is prohibited, 4) must be done. If conversion-with
loss is prohibited, 1) should be done if possible, otherwise 4).
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.
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
[Cra88] Craigie, J., "Migration strategy for x.400(84)
x.400(88)/MOTIS", COSINE Specification Phase 8.2, RARE, 1988.
[Cro82] Crocker, D., "Standard of the Format of ARPA Internet
Messages", RFC 822, UDEL, August 1982.
[Kil90] Kille, S., "Using the OSI directory to achieve user
naming", Research Note RN/90/29, Department of
Science, University College London, February 1990.
[Kil92] Kille, S., "Mapping between X.400(1988) / ISO 10021 and
822", RFC 1327, University College London, May 1992.
[MHS84] Recommendations X.400, October 1984. CCITT SG 5/VII,
Handling Systems: System Model - Service Elements
[MHS88a] CCITT recommendations X.400 / ISO 10021, April 1988.
SG 5/VII / ISO/IEC JTC1, Message Handling: System
Service Overview
[MHS88b] CCITT recommendations X.419/ ISO 10021, April 1988.
CCITT SG 5/VII / ISO/IEC JTC1, Message Handling:
Specifications
7. Security
Security issues are not discussed in this memo
8. Author's
Steve Hardcastle-
Department of Computer
University College
Gower
WC1E 6
Phone: +44-71-380-7294
EMail: S.Kille@CS.UCL.AC.
Hardcastle-Kille [Page 5]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
