[comp.protocols.iso.x400] Prospectives of the organization of X.400 in the Internet.

Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen) (01/12/91)

Dear Colleague,

The following document represents the internal view of the NSF X.400 Pilot
project Team only, and is distributed widely as a contribution to the
discussion on how to organize the X.400 service in the Internet.

Best regards,
Alf H.

===========================================================================




                    The NSF X.400 Project Prospective
                                of the
                  Organization of X.400 in the Internet



                            Allan Cargille
                            Robert Hagens
                             Alf Hansen
                        Lawrence H. Landweber

                      Computer Sciences Department
                    University of Wisconsin - Madison



                          November 12, 1990



1.    Introduction
------------------
The Internet community has used electronic mail as an international service
for several decades, and is a representative user group with respect to
user requirements, service management, addressing- and routing- problems,
interconnectivity, future service developments etc.

It is essential that the Internet community itself be a leader in the
development of new E-mail technology. By being an early user group of
X.400 services and by gaining experience from operating a
national/international X.400 service in a multi-protocol environment, other
communities can take advantage of the experience gained by the Internet
community.


2.    Overall Organization of X.400 in the Internet
---------------------------------------------------


2.1   Pure X.400 Issues
-----------------------
In order to plan the integration of X.400 services in to the Internet, it is
important to build a model that describes the overall structure of X.400
in the Internet. This section describes our conception of that model.

The Internet began as a small collection of people who shared a common goal of
researching network protocols and services. Today, the Internet is a large and
diversified environment. The overall goal *communication* remains; however
there are differences in the service requirements of the various agencies
and administrations.

The X.400 model supports connectivity between administrations with different
service requirements; the architectural vehicle for this is a Management
Domain. Thus, the first statement that can be made about the organization
of X.400 in the Internet is that the Internet should organize itself into
a collection of PRMDs where the PRMD boundary is based upon different
service requirements.

In the existing Internet mail service (based upon RFC-822 style addresses
and SMTP), an attempt is made to deliver a message to the recipient with
as little application relaying as possible (i.e., "make a direct connection
from source to destination").

Interoperation of the various Internet PRMDs is extremely important. The PRMDs
must cooperate with each other. Each PRMD must provide at least one MTA which
will act as well known entry/exit point for other PRMDs in the Internet
(I-WEP). There should be complete connectivity between all such points in all
Internet PRMDs. Each I-WEP should accept X.400 traffic on a variety of network
services (OSI CONS, OSI CLNS, OSI over TCP/IP).

The X.400 model is based upon the store & forward model of message transport.
However, the X.400 model does not mandate store and forward delivery, it just
allows it. Taking a queue from the success of the existing Internet mail
service, delivery of messages within an Internet PRMD should utilize direct
connections between the source and destination MTAs. When allowed by PRMD
service requirements, direct inter-PRMD connections should be used.

Each Internet PRMD should organize its ORAddress namespace in a heirarchical
manner where the attribute values have a meaningful coorespondence to
the actual structure of the member organizations. Organization of ORAddresses
based upon existing Internet domain names should not be a primary factor.
(Note: this does not preclude an organization from changing its Internet
domain name space to match the new ORAddress structure).

The Internet is rapidly becoming International in nature. However, it is
important to understand that X.400 registration and administration
issues are (by definition) country specific. PRMD names used within the
US may be registered in foreign countries. This is an issue subject to
regulations of the foreign country.

Internet PRMDs in foreign countries may connect directly to Internet PRMDs
in the US. The use of a transit ADMD is not required by the US.


2.2   Transitional Issues
------------------------
Each Internet PRMD should operate at least one RFC 987 gateway so as to
insure connectivity between PRMD X.400 users and Internet mail users.

Internet X.400 users will exchange mail with Internet (RFC 822) mail users.
This will requrire that Internet X.400 users have a means to represent
an RFC 822 address in X.400 syntax. A method common to all Internet PRMDs
must be choosen and supported. Other methods may optionally supported on
an individual PRMD basis.


3.    The NSF X.400 Pilot Project
---------------------------------
The NSF X.400 Pilot Project is one of the first steps to establish a
well-organized X.400 service integrated with the current Internet
Mail service. Even if it is not perfectly clear what the roles of an
X.400 Private Management Domain (PRMD) are, the project will operate
as an experimental PRMD (XNREN). By doing this, the project will identify
work items and responsibilities that clearly belong to a PRMD, and make
recommendations on the future PRMD structure in the Internet.

The project

  - Is experimental in its nature.
  - Has established an experimental PRMD (XNREN) in the Internet.
  - Will operate the PRMD as a production quality, service oriented PRMD.
  - Will operate an RFC 987 gateway between XNREN (X.400) and the US
    Internet mail service. The gateway will be based on the PP
    implementation from University College London (UCL).
  - Can be joined by any organization willing to operate a local X.400
    service, and contribute to a better understanding of operational issues.
  - Will offer the X.400 package ARGO to a limited number of non-commercial
    participating organizations.
  - Is a member of the R&D MHS Service, connecting XNREN to the existing
    international X.400 infrastructure for the R&D community.
  - Will provide XNREN with connectivity to the Internet Mail service.
  - Will, under the leadership of CNRI, establish contact with the national
    public X.400 service providers (ADMDs) with the goal to negotiate
    interconnection agreements and experimental exchange of messages.
  - Will seek contact with other relevant PRMDs in the Internet community
    to exchange experience and establish X.400 connectivity.
  - Will assist the participating organizations in setting up an
    experimental X.400 service.
  - Will produce information material about services available.
  - Will take an active role in the open discussions taking place on the
    various distribution lists regarding the many aspects of introducing
    X.400 into the Internet.
  - Will allow participating organizations to test new software and
    procedures in XNREN.
  - Will incorporate X.400 technical innovations into the X.400 experiments
    (fax, migration to X.400/88, multi media extensions, use of X.500
    directories, operation of X.400 over ISO TP4/CLNP and security
    extensions).

By these means the project will contribute to better common understanding of
technical/administrative issues regarding X.400 service operation in
the Internet. The lessons learned can be used as input to the planning
phase of NREN.

The following is the project's initial proposal to a strategy that will
enable a smooth integration of the existing Internet Mail service with
mail-services based on X.400. The major part of the proposal covers
short term (1-2 years) solutions. In a separate section the longer term
developments are described.


4.    The XNREN experimental X.400 service
------------------------------------------
The University of Wisconsin-Madison has received a 2 year grant
from NSF, with the goal of supporting experimentation with adoption
of X.400 in the Internet.

One of the main activities is to operate an experimental (1984) X.400
service, XNREN, with full connectivity to the Internet Mail world. Today
XNREN is the only US participant in the R&D MHS Service coordinated by the
RARE MHS Project in Europe. XNREN users are already connected to more
than 20 countries using the X.400 protocols. More than 100,000 real
X.400 users are interconnected and RFC 987 gateways are used to
communicate with the non-X.400 community.

The RARE MHS Project has established procedures for the operation of the
international R&D MHS Service. The procedures, together with a full
description of the service with all reachable organizations, are stored
in an on-line database. These procedures will be adapted to the needs of
the XNREN community, and the current international X.400 infrastructure will
be further developed.

The team working on the NSF X.400 Pilot Project in Wisconsin has been
actively involved both in the international service development and on
the national US level.

It is important to note that the XNREN X.400 service is experimental.
The decisions made by the XNREN Management are not binding for the
future NREN services. The decisions made for the XNREN service are made
on the basis that they will give the users the best possible service
TODAY, and IN THE NEAR FUTURE. The long term solutions for the future
NREN service, may differ from the XNREN solutions, however, the Project
Team will seek to find consensus in relevant national groups, and thus
provide the best possible basis for future long-term services.

In order to reach our goals, cooperation is needed with bodies external
to the project team. Below some players in the total service picture are
identified, and the success of the experiment is dependent on a high
degree of cooperation between all of them.


4.1   The players
-----------------
In this context the following groups are identified:

  - The US X.400 Naming Authority (NA).
  - The PRMD XNREN.
  - Other PRMDs in the US Internet community.
  - PRMDs in the US external to the Internet community.
  - ADMDs in the US (public X.400 service providers).
  - The current Internet Mail Service Management (non-X.400).
  - The participants in the R&D MHS Service (X.400 service providers in
    countries outside the US).
  - ADMDs outside the US.
  - Vendors (of X.400 products).


4.2   The role of each player
-----------------------------

4.2.1 The US X.400 Naming Authority (NA)
----------------------------------------
This organization will register unique ADMD names and unique PRMD names
in the US. We have reasons to believe that an NA soon will be
established based on an initiative from the State Department, Study group D.

Unique ADMD and PRMD names will insure unique X.400 addresses in the US.

4.2.2 The PRMD XNREN
--------------------
The project will register XNREN as a PRMD in the US. Until it is officially
registered, PRMD=XNREN will be used unofficially in the X.400 addresses
in the PRMD-field. If XNREN is not accepted as a legal registration, the
name will be changed, and so will the PRMD field in the X.400 addresses.

The project will register unique Organizations under PRMD XNREN, and
check that there are no conflicts between the combination of X.400
address attributes and the given RFC 987 address mapping (see section 3.1).

The PRMD XNREN will operate an X.400 service on top of the following
network-infrastructures:

    RFC 1006 on top of TCP/IP
    Interim operation.

    TP 0 on top of X.25
    When investigations identify a need for it, and products are available.

    TP 4 on top of CLNP
    As soon as an operational infrastructure and products are available.

The upcoming availability of BSD 4.4 may provide an impetus for use of
this approach.

The project will act as a focal point for registered XNREN PRMDs in other
countries. This flexibility allows experimentation with an international
X.400 infrastructure insuring all end-users in the international PRMD XNREN
the same level of service. The model requires close cooperation between
the XNREN management and each national R&D MHS Service provider.

The XNREN management will, in cooperation with local MTA and gateway
operators, provide the following services to end-users in the PRMD XNREN:

Inter Personal Messaging (IPM) service to

  * All other end-users in XNREN.
  * All end-users in the international R&D MHS Service, including users
    in ADMDs in other countries where there exists an agreement between
    the ADMDs and the national R&D MHS Service Providers.
  * All end-users in other PRMDs in the Internet community.
  * All end-users in PRMDs in the US outside the Internet community,
    given that an agreement with XNREN exists.
  * All end-users in ADMDs in the US, given that an agreement with XNREN
    exists.

E-mail service via application gateways (RFC 987) to

  * All end-users in the current Internet Mail service (non-X.400).
  * E-mail end-users in other countries served by local gateways to
    the R&D MHS Service.

End-user information services. This includes:

  * XNREN end-user catalog.
  * Information on how to fetch catalog information about end-users
    outside XNREN.
  * General help service.
  * Status information (connectivity, future developments etc).

Error reporting service. This includes:

  * A place for end-users to call when problems occur.
  * A report back when the problem is fixed, or a reason why it is not fixed.

In addition results from technical innovations will be offered to end-users
when the stability of the service is reasonable, such as

  - Mail/fax gateway.
  - X.500 directory services.
  - Multimedia document handling.

The role of PRMD XNREN is to gain experience and prepare for future
X.400 services in the Internet.

4.2.3 Other PRMDs in the US Internet community
----------------------------------------------
These PRMDs will offer similar and/or different user services to their
user community. The organization of PRMDs in the Internet and routing
between them should be further discussed, and one should end up with some
basic common service requirements for all PRMDs in the Internet.

The role of these PRMDs is similar to that of the XNREN. Each has an interest
in working with other Internet PRMDs to better understand the needs of the
distributed X.400 service environment. Cooperation between these PRMDs is
very important.

4.2.4 PRMDs in the US external to the Internet community
--------------------------------------------------------
Obviously there will be a large number of such PRMDs. In each case the
Internet community should find out if there is a need for interconnectivity
between PRMDs in the Internet and such external PRMDs. A bilateral agreement
is required to establish such interconnection.

Their role is to serve the user community they are representing.

4.2.5 ADMDs in the US (public X.400 service providers)
------------------------------------------------------
These are public X.400 service providers operating as ADMDs in the US.
Agreements are needed in order to interconnect the Internet PRMDs to
the ADMDs. Routing between Internet PRMDs and ADMDs has to be further
discussed. The ADMDs will provide international X.400 connectivity to
external ADMDs.

Their role is to provide an X.400 service to anyone who wants it.

4.2.6 The current Internet Mail Service Management (non-X.400)
--------------------------------------------------------------
This is the existing Internet Mail service with RFC 822
addressing. The service is managed with distributed responsibility,
using available tools for service management. The Mail service is
usually delivered together with other services: remote login, file transfer.

Message transfers between Internet Mail and PRMDs in the Internet must be
routed via RFC 987 gateways for transformation of the messages. The deployment
and management of these gateways are an essential issue for a successful
integration of X.400 with Internet mail.

Their role is to serve the user community they are representing, and make
sure that the introduction of X.400 in the Internet is an improvement
for the users, and not a degradation of service.

4.2.7 R&D MHS Service Participants
----------------------------------
In addition to the US, the participating countries are:

Austria, Australia, Belgium, Canada, Denmark, Germany, Finland, France,
Iceland, Ireland, Italy, (Rep. of Korea), The Netherlands, Norway,
Portugal, Spain, Sweden, Switzerland, United Kingdom, Yougoslavia.

There are test connections from Europe to Brazil and China.

Each of them is providing an X.400 service to their R&D community, and they
are all interconnected as one international R&D MHS Service. An on-line
database documents the service procedures and the participating
organizations. The database also contains a minimum set of international
routing information.

The public X.25 network is the major carrier of international traffic.
RFC 1006 on top of TCP/IP is also used, and in Europe the IXI (X.25)
infrastructure is carrying a significant portion of the
traffic. Internally each country is free to use available infrastructure
for the national X.400 traffic. The basic goal is however to use one global
well-managed OSI network both for national and international traffic.
While waiting for this, the X.400 managers have to agree on practical ways
to interconnect.

Full international connectivity is obtained by the agreement that all
Well-Known Entry Points (WEPs) should at least be
connected to the public X.25 network as a minimum requirement.

Remark: XNREN participates in the R&D MHS Service even if we yet do not
meet the X.25 requirement for our WEP. We can do this because we have an
agreement with UNINETT, Norway, that all X.400 traffic to XNREN can be
routed via the Norwegian WEP. When the traffic level increases, we have to
find another solution. The problem is to find ONE and only one international
networking infrastructure to build the international X.400 service on
top of. If no such agreement is reached, this will have consequences for
the international organization of the application services.

The role of the R&D MHS Service is to provide an international X.400
service to the (European) R&D community.

4.2.8 ADMDs outside the US
--------------------------
These are public X.400 service providers in other countries. All ADMDs
are cooperating in the ADMD Operators Group (IAOG). ADMDs all over the
world will seek to reach interconnection agreements between themselves,
thereby providing a publicly available international X.400 infrastructure.

Thus, in our context there will be two international X.400 infrastructures
available: The R&D MHS Service and the ADMDs. The Internet community
should select an international infrastructure based on
price/performance criterias. Connectivity and service quality are important
parameters.

The role of these ADMDs is to provide an international X.400 service
to everyone who wants it.

4.2.9 Vendors (of X.400 products)
---------------------------------
Vendors are providing X.400 products. The availability of such products
is not yet satisfactory. By deploying products in the Internet community,
the vendors would

  - Use the Internet infrastructure as a testbed for their products.
  - Receive important feedback from advanced users.
  - Contribute to the solution of an important constraint to faster
    development of the X.400 service: products vs. public domain software.
  - See their products used by the future buyers: the students and
    researchers.

Their role is to provide useful products.


4.3   The rules between the players
-----------------------------------
If the users are to receive high quality services, then some rules must
be defined.

  - The Internet PRMDs must cooperate with the ADMDs.
  - The Internet PRMDs must cooperate in order to maintain full
    inter-PRMD connectivity.
  - The sharing of experience is essential.
  - The goal is to provide users with better and more effective E-mail tools
    and connectivity to a wider community.

The details of how the various organizations will cooperate and interrelate
are not fully understood at this time. A great deal of discussion
will be required to specify procedures which will insure a high level
of interoperability and an associated high level of services to users.


5.    Operation of the PRMD XNREN
---------------------------------
The following is a description, in some detail, of how the PRMD XNREN
will operate in the US.


5.1   Registration of address space (Naming Authority, NA)
----------------------------------------------------------
The X.400 address space consist of X.400 names which include entries
for organization (O), organizational units (OUs) and personal names (PN)
together with fixed PRMD=XNREN, ADMD=<blank> and C=US, i.e.,

     c=us/admd= /prmd=xnren/o=.../ou=.../ou=../pn=.....

Real names should be used as PN. Initials are allowed.
O and OUs should reflect the real organizational structure of the
participating organization. Machine names should not be used.

The XNREN Naming Authority (NA) will be responsible for deciding upon
the format of X.400 addresses in the XNREN and the mappings between
these addresses and current Internet mail addresses.

As an example of the mapping problem, consider the following X.400 address:

     c=us/admd= /prmd=xnren/o=UW-Madison/ou=cs/pn=Alf.Hansen

This address cannot be expressed in an RFC 822 system, therefore an
address mapping from X.400 to RFC 822 must be defined. The XNREN NA will
insure that all X.400 addresses in the XNREN address space has an unambiguous
RFC 822 representation. Given the current mapping, the RFC 822
interpretation of the above address is:

     Alf.Hansen@pilot.cs.wisc.edu

Mapping in the other direction: The RFC 822 address

     lhl@cs.wisc.edu

cannot in general be expressed in an X.400 system, therefore an address
mapping from RFC 822 to X.400 must be defined. Today no such mapping is
defined in the US, and this create problems for existing X.400 users because
they have no unique way to represent a US RFC 822 address in X.400 format.
To assist their users, X.400 service providers had to define their own
mappings instead of using an official US defined mapping. The result
is that there exist more than a dozen ways to represent the same US
Internet RFC 822 address, in X.400 format. This is confusing not only for
the X.400 users, but also for the US Internet mail users, because
communication between X.400 users and the US Internet mail users is difficult
from an addressing point of view.

The similar national problem does not exist in other countries that the US.
The national network managers in the other relevant countries, where
both X.400 and Internet mail are in operation, have defined their mappings.
An example from Norway:

The Internet mail address

     he@idt.unit.no

is mapped to

     c=no/admd= /o=unit/ou=idt/pn=he

It is therefore clear for all X.400 users in Norway and elsewhere, how
they should address an Internet mail user in Norway.

Until the US definition of such mapping has been established, X.400 users
in XNREN has been told to use the Norwegian mapping to reach Internet mail
users in the US. This is indeed a temporary solution, and the result is:

     lhl@cs.wisc.edu

is mapped to

     c=no/admd= /prmd=edu/o=wisc/ou=cs/pn=lhl

A high priority task for the US Internet is to define these mappings.

The address mapping takes place in RFC 987 gateways. The project will
benefit from the ongoing international coordination of mapping tables
which is provided by the RARE MHS project.

The X.400 and RFC 822 address space are two different address spaces. The
RFC 822 address space in the US is defined and exists. The X.400 address
space is about to be defined. The two address spaces need to be integrated,
so special care must be taken to insure that addressing conflicts do not
occur, for example, that a new X.400 address with a given mapping does not
conflict with an existing RFC 822 address.

Remark: Such address-overlaps can be allowed, but then we must make sure
that all the operational requirements are met in order to do that.

The XNREN Naming Authority will make sure that all registered
organizations (O) and organizational units (OUs) under the PRMD XNREN,
with a given mapping, do not create such conflicts. The XNREN NA will
also guarantee unique Os under PRMD XNREN.


5.2   X.400 / RFC 822 address mapping strategy
----------------------------------------------
In most cases users already have an RFC 822 address in the Internet mail
service. To start using X.400 systems in an organization requires an
integration strategy. It also raises the question, should the users have
one or two mailboxes.

Alternative integration strategies will be discussed in a separate paper.
The following discusses the situation when users in an organization have
one mailbox, either in the X.400 or in the Internet mail service. It is a
clear wish from users to have just one mailbox.

PRMD XNREN will develop a strategy for X.400 address mapping. Several
options are possible. Two alternatives for each mapping direction
are mentioned below, as examples:

  - The representation of an X.400 address as seen from the RFC 822 world
    (mapping X.400 --> RFC 822).
  - The representation of an RFC 822 address as seen from the X.400 world
    (mapping RFC 822 --> X.400).

Between these alternatives there are several options. Further discussions
are needed to reach the final conclusion.

In order to keep an experimental service operational, PRMD XNREN has
made a working decision on address mapping as described in section 3.1.

5.2.1 The representation of an X.400 address as seen from the RFC 822 world
---------------------------------------------------------------------------
Please note that the X.400 addresses presented below are stating the
values of the various address elements in the X.400 message. This is not
necessarily how the same addresses are presented to the user by the
X.400 user interface.

5.2.1.1 Mapping X.400 -> RFC 822, Alternative 1
-----------------------------------------------
Map the OUs, O, PRMD, ADMD, C hierarchy into the RFC 822 domain structure
in the order of their appearance.

  X.400 address:     pn=Alf.Hansen/ou=cs/o=UW-Madison/prmd=xnren/c=us
  Seen from RFC 822: Alf.Hansen@cs.UW-Madison.xnren.us

Advantages:

  - Easy to understand for users.
  - Small mapping table.

Problems:

  - Xnren is introduced as a domain on a high level in the Internet.
  - The RFC 822 form looks different than the existing RFC 822 address space.
  - May in some cases be ambiguous.

5.2.1.2 Mapping X.400 -> RFC 822, Alternative 2
-----------------------------------------------
Seen from the RFC 822 world, an X.400 address should look exactly the same
as the current addresses used in the Internet Mail service.

  X.400 address:     pn=Alf.Hansen/ou=cs/o=UW-Madison/prmd=xnren/c=us
  Seen from RFC 822: Alf.Hansen@cs.wisc.edu

Advantages:

  - Seen from the RFC 822 world, the X.400 address looks exactly the same as
    the the addresses users are used to.
  - No need to register new domains at all in the existing Internet.

Problems:

  - The same organization will have completely different address elements in
    the two systems, and this is not easy to understand for users.
  - Certain operational requirements must be met, for example, each
    organization (in this case "wisc" or O=UW-Madison) must operate
    their own RFC 987 gateway.
  - Large mapping table.

5.2.2 The representation of an RFC 822 address as seen from the X.400 world
---------------------------------------------------------------------------

5.2.2.1 Mapping RFC 822 -> X.400, Alternative A
-----------------------------------------------
Keep the RFC 822 address space in the Internet as is, and let the X.400
representation of the RFC 822 address look similar, introducing one:
PRMD for the whole RFC 822 world:

  RFC 822 address: lhl@cs.wisc.edu
  Seen from X.400: pn=lhl/ou=cs/ou=wisc/o=edu/prmd=RFC-822/c=us

Advantages:

  - Easy to understand for users
  - Small mapping table

Problems:

  - "RFC-822" is introduced as PRMD and the XNREN and other X.400 service
     providers must be prepared to relay all traffic from other X.400
     countries to this PRMD that will include edu, gov, mil, etc.

5.2.2.2. Mapping RFC 822 -> X.400, Alternative B
------------------------------------------------
Change the RFC 822 address space to reflect the new X.400 address space
without showing the PRMD (and ADMD) field, and let the X.400 representation
of the RFC 822 address look as an X.400 address:

First: The existing RFC 822 address space has to be changed:

  RFC 822 address: lhl@cs.wisc.edu --> Larry.Landweber@cs.UW-Madison.us

then the following mapping can be defined:

  RFC 822 address: Larry.Landweber@cs.UW-Madison.us
  Seen from X.400: pn=Larry.Landweber/ou=cs/o=UW-Madison/prmd=xnren/c=us

Advantages:

  - The RFC 822 address space is restructured (improved) at the same time.
  - Easy to understand for users.
  - Small mapping table.

Problems:

  - To change the RFC 822 address space is a major amount of work.
  - Will need an extra (painful) transition step in the existing Internet
    mail.


5.3   Connectivity and routing
------------------------------
PRMD XNREN has the following routing policy:
In the ideal case, all MTAs should be able to route directly to the
destination MTA. The technology is not yet ready for this on the
global scale, therefore the WEP structure has been agreed to be a
minimum requirement to assure global connectivity.

An X.400 initiated message should not be routed out of the
X.400 world and back again. If this were done, the X.400 user might see
some loss of functionality.

An X.400 initiated message should cross an application gateway
border as close to the destination as possible. For international traffic,
this means that PRMD XNREN will use the international X.400 infrastructure to
route a message to the destination country, and it is up to the
destination service provider to find out if the message is destined
for an X.400 user or a non-X.400 user.

5.3.1 National X.400 connectivity
---------------------------------
All participating organizations in PRMD XNREN will provide connection
data for at least one MTA in their organization. The RFC 1006 on top of
TCP/IP is the interim standard protocol suite for X.400 traffic
in XNREN.

If a participating organization is not connected to the RFC 1006/TCP/IP
infrastructure, it must provide connection data for another MTA in
XNREN which is connected to both, and which agrees to relay messages for the
organization concerned.

This will allow

  - Direct routing between all organizations which are connected to the
    interim standard protocol suite
  - Full X.400 connectivity between organizations not connected via the
    interim basic standard protocol suite
  - Organizations to "hide" their internal MTA structure if they want to do so
    for one reason or another

XNREN will maintain an implementation independent routing table that
will be made available to all XNREN participants. The distribution of routing
data and other types of operational information to all XNREN
participants, is a major tasks for the XNREN management.

Connectivity to other PRMDs and ADMDs in the US will be established based
on bilateral negotiations. XNREN hopes, however, that one common agreement
can be set up between all PRMDs in the Internet community.

5.3.2 International X.400 connectivity
--------------------------------------
PRMD XNREN will participate as a US participant in the RARE MHS Project.
By doing so, we agree to provide them with the information they need
about our service. In return we get information on all other national
participants, and we are able to maintain full R&D MHS connectivity
for our users. The project will operate a WEP according to the agreed
R&D MHS procedures.

One should discuss internally in the Internet whether we should propose a
new structure for the international R&D MHS Service based on Regions
(Europe is one region, North America is another). This type of organization
will be neeeded if there are too many conflict areas in the way the RARE MHS
project organizes the service, and how other Regions would like to see
it organized. An example of a possible conflict area is the decision
in the R&D MHS Service that as a minimum requirement all WEPs MUST be
connected to the public X.25 network.

There may be cases where PRMD XNREN is also registered outside the US.
Messages between XNREN PRMDs in different countries will be routed as
if they were messages in one national PRMD.

Regardless of how the international service is organized, full X.400
connectivity between R&D MHS users must be obtained.

PRMD XNREN will monitor the development of the ADMD services in the US.
As soon as the international ADMD infrastructure can provide  X.400
connectivity meeting our requirements (price/performance), XNREN will
start using it in addition to the R&D MHS Service. If the ADMDs agree,
XNREN will be able to use the ADMD infrastructure for testing purposes.

All XNREN participants will receive information from XNREN on how to route
international (and also domestic) traffic, either via the WEP or via the
ADMDs. Direct routing from an XNREN MTA to an organization outside XNREN
requires at this stage bilateral routing agreements between the organizations
concerned.

The international X.400 infrastructure used by XNREN can be made
available to other PRMDs in the Internet.

5.3.3 Integration with Internet Mail (gateways)
-----------------------------------------------
The project will operate a centrally available RFC 987 gateway based on the
PP software from University College London (UCL), London. The gateway
will be available for all users in PRMD XNREN. The project will encourage
participating organizations to operate local RFC 987 gateways. The
centrally operated gateway is needed in the initial phase, before the
installation of local gateways, and later for those organizations using
X.400 only and who are not connected to the Internet mail service.

The project will make sure that the national RFC 987 address mapping tables
are delivered to the RARE MHS Project following the agreed procedures. From
the RARE MHS Project XNREN, will receive copies of the full international
RFC 987 Master tables. It is the project's responsibility to insure that all
RFC 987 gateway operators in XNREN have easy access to these copies. All
gateway operators in XNREN must at any time use the last version of the
international mapping tables.

An RFC is being written describing how the DNS system can be used to
distribute these tables in the Internet.

The project will perform the necessary procedures on the Internet side when
configuration changes occur on the X.400 side (i.e., update the MX records
used for routing). Similar, if required, changes in the Internet mail
configuration may require actions on the X.400 side. The degree of need
for such actions will be dependent on the conclusions regarding
address mapping.


5.4   End-user information
--------------------------
XNREN will make available on-line a user catalog of all users in XNREN.
Each user must perform the registration following a described procedure
when he starts using his X.400 user agent. XNREN will seek contact
with the ongoing X.500 pilot in the US and investigate the possibility
of using this pilot X.500 infrastructure for catalog purposes.

The description of the user functions in the catalog service cannot be
described until more information about the X.500 pilot is available.

From the RARE MHS Project, XNREN will receive information on available
user directories in other countries. XNREN will provide our users with
information on how to access these services.

Each participating organization will publish a postmaster address. To
get information, users should in general contact their local postmaster.
XNREN will provide all postmasters with service information (XNREN
Newsletters) and each postmaster is free to present this to his users
using normal local information channels.

The XNREN Newsletters will also be made available from a central file
store.


5.5   Error reporting
---------------------
Normally problem reports from users should be directed to the local
postmaster. When this is impossible, the users should contact the
central XNREN maintenance center using the published 24 hour a day
telephone number. Outside normal business hours, an answering machine
will record the messages.

A user reporting a problem will always receive a confirmation, whether
the problem is fixed or not.


6.    Long term X.400 predictions
---------------------------------
The results from the first 1 - 2 years activities between the various
players, should lead to a long term (2 - 5 years) strategy for
introduction of X.400 in the Internet. The following is an initial
prediction for the future X.400 service in the Internet.


6.1   End-user requirements
---------------------------
From a user's point of view there must be a smooth integration.

The speed of the X.400 growth is dependent on availability of useful products.

Use of OSI services in the Internet should require products where the
X.400 UA, X.500 UA, the FTAM user interface and the VTP user interface
are integrated as one software package. It should be accepted that
such integration will be realized over time, and that not all services
will be present in all products at all times.

There should be a well defined requirement for "quality of service" (e.g.,
maximum allowed national/international delays of messages).

The security and authentication services should be well defined.

The address elements PRMD and ADMD should disappear from the user interfaces
(but remain in the message headers). The integration of X.400 and X.500
UAs should allow users to present "user friendly names" when composing
a message. (The X.500 service should also be used for X.400 routing purposes).

X.400 UAs for fax handling, multi media document handling, EDI, etc.
should use the X.400 infrastructure to exchange the different document
types between X.400 addresses.


6.2   Underlaying network infrastructure
----------------------------------------
The basic network infrastructure should be TP 4 on top of CLNP.

RFC 1006 on top of TCP/IP and TP 0 on top of X.25 should be used in parallel
as long as needed.

The capacity on the transport network should be developed to meet the end-user
requirements for new document types.


6.3   Organization of the service
---------------------------------
A central US X.400 Service initiative should organize the X.400 Service
in the US Internet. This body should cooperate with similar bodies in
other parts of the world.

A broad cooperation with ADMDs in the US should be established.

X.400 is one out of several OSI services that will be introduced in the
Internet. The X.400 service management should work in close cooperation
with the managements of the other OSI services. I.e. the X.400 and X.500
infrastructure should be closely integrated.