Dismiss
The IQ application will be briefly unavailable on Sunday, March 31st, starting at 10:00am ET. Access will be restored as quickly as possible.
Browse Prior Art Database

X.400 1988 to 1984 downgrading (RFC1328)

IP.com Disclosure Number: IPCOM000002150D
Original Publication Date: 1992-May-01
Included in the Prior Art Database: 2019-Feb-10
Document File: 5 page(s) / 7K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

S. Hardcastle-Kille: AUTHOR

Related Documents

10.17487/RFC1328: DOI

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. [STANDARDS-TRACK]

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 34% of the total text.

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=Empir...

Processing...
Loading...