Network Working                                  S.E. Hardcastle-Kille
Group                                                 ISODE Consortium
INTERNET-DRAFT                                        October 17, 1992
                                                  Expires:  April 1993





   Mapping between X.400 and RFC 822 for a closed RFC 822 Community

                             IC-11 (1.1)






Status of this Memo

This document is an Internet Draft.  Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups.  Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time.  It is not appropriate to use Internet Drafts
as reference material or to cite them other than as a "working draft"
or "work in progress."
Please check the I-D abstract listing contained in each Internet Draft
directory to learn the current status of this or any other Internet
Draft.

Abstract
This document proposes a modification of the X.400/RFC 822 mapping
described in RFC 1327, for a specific type of application.

This document will be submitted to the IETF X.400 OPS WG for suggested
progress as a standards track RFC.




INTERNET--DRAFT      RFC 1327 for closed RFC 822      October 17, 1992


1  Problem Statement

An organisation may choose to have all external mail access using
X.400 [MHS88].  Reasons for this include:


 o  Policy

 o  Choosing a single access mechanism to ensure coherency

 o  Security and traceability reasons

Such an organisation may wish to run RFC 822 user agents internally,
as there are a number of sound products available.  Mapping between
RFC 822 and X.400 according to RFC 1327 requires the use of a globally
unique mapping.  Maintenance of this mapping is a significant overhead
[Cro82, Kil92].
The reason for maintenance of the globally unique mapping is to
maintain coherency between gateways.  For a closed community, there is
no fundamental requirement for this consistency.  This document
proposes a modification of RFC 1327 which does not utilise a globally
unique mapping.  This results in the generation of addresses which
follow RFC 822 syntax, but have local semantics.


2  Mechanism


2.1  Use with private tables

The basic mechanism is to follow RFC 1327, but use a private mapping
common to all of the gateways in the community.  The mappings should
be defined to produce addresses which are convenient to the community.
Typically, the tables will be simple, and lead to addresses which are
algorithmically related to the X.400 address.  Mappings may be defined
to make local addresses short and convenient.


WARNING: This specification should not be used where there is or may
    in the future be a direct RFC 822 connection into the global RFC
    822 community.




Hardcastle-Kille                         Expires:  April 1993   Page 1




INTERNET--DRAFT      RFC 1327 for closed RFC 822      October 17, 1992


2.2  Use without tables

A special variant is to perform the mapping without any mapping
tables.  In this case, all the RFC 822 addresses will have a full LHS
encoding, and the domain is set according to one of two variants.

1.  Where there is no external RFC 822 connection.  Here the domain is
    set to MHS.

2.  Where there is an external RFC 822 connection, the domain should
    be set to the local RFC 822 domain.  This will lead to inefficient
    RFC 822 routing, and so should be avoided if there is extensive
    external RFC 822 traffic.


2.3  Domain Defined Attributes

When mapping from X.400 to RFC 822, it is important that any RFC-822
DDA is not interpreted as a locale RFC 822 address (as allowed in the
note on page 55 of RFC 1327).  Rather, it should be encoded on the
LHS, so that a replyable address is generated.

The closed RFC 822 community should, if possible, be set up so that
all local RFC 822 addresses are mapped to X.400 addresses without
DDAs.  If a DDA must be generated, the values CLD-822, CLD822C1,
CLD822C2, and CLD822C2 shall be used instead of the usual RFC 1327
Domain Defined Attributes.  This will prevent a remote RFC 1327
gateway from interpreting a local RFC 822 address as if it had global
semantics.


References

[Cro82] D.H. Crocker. Standard of the format of ARPA internet text
        messages. Request for Comments 822, University of Delaware,
        August 1982.

[Kil92] S.E. Kille. Mapping between X.400(1988) / ISO 10021 and RFC
        822. Request for Comments 1327, Department of Computer
        Science, University College London, May 1992.

[MHS88] CCITT recommendations X.400 / ISO 10021, April 1988. CCITT
        SG 5/VII / ISO/IEC JTC1, Message Handling:  System and
        Service Overview.

Hardcastle-Kille                         Expires:  April 1993   Page 2