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: 2000-Sep-12
Document File: 7 page(s) / 9K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

S. Hardcastle-Kille: AUTHOR

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 text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 29% 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".

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 co...