Browse Prior Art Database

Use of the X.500 Directory to support mapping between X.400 and RFC 822 Addresses (RFC1838)

IP.com Disclosure Number: IPCOM000004096D
Original Publication Date: 1995-Aug-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 9 page(s) / 11K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

S. Kille: AUTHOR

Abstract

This document defines how to use directory to support the mapping between X.400 O/R Addresses and mailboxes defined in RFC 1327 [2].

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 27% of the total text.

Network Working Group S. Kille

Request for Comments: 1838 ISODE Consortium

Category: Experimental August 1995

Use of the X.500 Directory to support mapping between X.400

and RFC 822 Addresses

Status of this Memo

This memo defines an Experimental Protocol for the Internet

community. This memo does not specify an Internet standard of any

kind. Discussion and suggestions for improvement are requested.

Distribution of this memo is unlimited.

Abstract

This document defines how to use directory to support the mapping

between X.400 O/R Addresses and mailboxes defined in RFC 1327 [2].

1. X.400/RFC 822 Mappings

RFC 1327 defines an algorithm for maintaining a global mapping

between X.400 and RFC 822 addresses directory [2]. RFC 1327 also

defines a table based mechanism for maintaining this mapping. There

is substantial benefit to maintaining this mapping within the

directory. In particular, this will lead to an approach for managing

the mapping which is both distributed and scalable.

Mechanisms for representing O/R Address and Domain hierarchies within

the DIT are defined in [1, 5]. These techniques are used to define

two independent subtrees in the DIT, which contain the mapping

information. The benefits of this approach are:

1. The mapping information is kept in a clearly defined area which

can be widely replicated in an efficient manner. The tree is

constrained to hold only information needed to support the

mapping. This is important as gateways need good access to the

entire mapping.

2. It facilitates migration from the currently deployed table-based

approach.

3. It handles the issues of "missing components" in a natural

manner.

An alternative approach which is not taken is to locate the

information in the routing subtrees. The benefits of this

would be:

o It is the "natural" location, and will also help to

ensure correct administrative authority for a mapping

definition.

o The tree will usually be accessed for routing, and so it

will be efficient for addresses which are being routed.

This is not done, as the benefits of the approach proposed

are greater.

There are three mappings, which are represented by two subtrees

located under:

OU=X.400/RFC 822 Mapping, O=Internet

These subtree roots are of object class subtree, and use the

mechanism for representing subtrees defined in [4].

X.400 to RFC 822 This table gives the equivalence mapping from X.400

to RFC 822. There is an O/R Address tree under this. An example

entry is:

PRMD=UK.AC, ADMD=Gold 400, C=GB, CN=X.400 to RFC 822,

OU=X.400/RFC 822 Mapping, O=Internet

RFC 822 to X.400 There is a domain tree under this. This table holds

the equivalence mappi...