service between X.400(1988) originators and destinations, the
topology of the MTS must be such that no X.400(1984) MTA acts
as a relay between any two X.400(1988) users.
- As the existing R&D X.400(1984) service (formerly COSINE
MHS) now comprises a large number of X.400(1988) capable
RELAYs, it would be relatively straight forward that the
existing COSINE MHS RELAYs be one of the first communities
that are migrated to X.400(1988) capabilities. This would
ensure that X.400(1988) MTAs using the RELAY backbone
experience no loss of service.
- To be able to operate an X.400(1988) service a properly
operated X.400(1988) infrastructure should be established,
consisting of X.400(1988) MTAs, X.400(1988) MTAs with
downgrading capabilities according to RTR 3, Message Store
services and gateways to RFC822 based upon RTR 2 and
extended gatewaying functionality for multimedia mail.
- To ensure maximum use of the OSI supporting layers plus
support of normal mode RTS, it is recommended that a
migration to ISO 10021 is effected i.e., straight to use of
the full OSI stack with normal mode RTS.
- To ensure maximum quality of service as impacted by
implementation decisions related to the 'General Extension
Mechanism', it is recommended that no minimal X.400(1988)
MTAs, which relay the syntax but understand none of the
semantics of extensions, should be used.
- It is recommended that all X.400(1988) MTAs should generate
reports containing extensions copied from the subject message
and route reports through the DL expansion hierarchy where
appropriate.
- It is recommended that all X.400(1984) UAs are able to
generate and display DDAs. This will allow such systems to
address X.400(1988) Common Name Attribute users.
- To enhance connectivity to both X.400(1984 and 1988)
management domains without degradation of X.400(1988)
service, management domain entry points that support both
X.400(1984 and 1988) are recommended.
- To ensure total connectivity between RFC822 domains
migrating to X.400(1988), it is recommended that a local
X.400-to-RFC-822 gateway is made operational or a reliable
service agreement for the external provision of such a
gateway is effected before any migration begins.
*Migration utilities needed*
- It is considered very helpful if conversion utilities that
allow a flawless conversion of an RFC822 user's existing
mail folders to a X.400(1988) product's folder system be
implemented. However further investigation is needed before
recommending that such tools be made a mandatory part of any
funded software development.
- It is recommended that the ease of configuration of
X.400(1988) products is made as automatic as possible.
Consideration should be given to a) modern user interfaces b)
automatic processing of 'old RFC822' configuration files
into the 'new X.400(1988)' configuration files i.e., a reuse
of the user's previous options and configurations should be
the result. If a 'simple' configuration interface is needed
it should be as compatible as possible with the present RFC
822 mailer's i.e., this concretely means editing of ASCII
files.
*Issues for further study*
The pilot X.400(1988) messaging service must ensure that the issues
listed below are either being investigated by an appropriate body or
if not initiate actions to properly address them. The issues have
been grouped under Products, Organisational and Deployment.
- Products
- Any X.500 DSAs, DUAs, APIs e.g., LDAP, etc. changes
needed to support X.400(1988) messaging.
- X.400(1988) MTAs, UAs, MSs, gateways to RFC822/MIME
and X.400(1984) plus gateways to other messaging
systems e.g., Microsoft Mail, Lotus cc:Mail, etc.
- User Interfaces that integrate X.400(1988) UAs and
X.500 DUAs with user applications such as Word
Processors, etc.
- E-mail network management software both for users and
administrators
- Organisational
- trusted network for security (i.e., the distribution of
security keys) and whether this trusted network should
or can be the same as the PEM trusted network presently
under deployment.
- usage of PEM within X.400(1988).
- PEM to and from X.400(1988) gatewaying.
- how to register and publicise object IDs for
X.400(1988).
- addresses are well publicised of PRMD and ADMD
registration authorities.
- creation and modification authority for X.400-to-RFC-
822 mapping rules is defined.
- creation and modification authority for MTA routing
rules is defined.
- what methods should be used to liaison to other bodies
like IETF, ISO, EEMA, EMA, etc.
- ensuring that any Public Domain software needed for the
X.400(1988) service is distributed widely, quickly and
efficiently.
- Deployment
- which services should start such a migration (i.e.,
COSINE MHS RELAYs, Universities, other).
- the topology of the X.400(1988) MTS.
- addressing of users between X.400(1984 and 1988) and
RFC822 e.g., how will X.400(1988) T.61 address
components be processed by X.400(1984) and RFC822
systems.
- which X.400(1988) body parts MUST be supported by the
research community.
- if any new APIs - or modified APIs - are needed for
X.400(1988) and messaging in general.
- the specifications and development of any needed Public
Domain software.
- what existing Public Domain software should be modified
to accommodate X.400(1988) systems.
- how rapidly to deploy the X.400(1988) service.
- ensuring that there is 'little or no loss of service'
in any migration from X.400(1984), or RFC822, to
X.400(1988).
- considering what Value Added Services, based upon
X.400(1988), could be started to encourage uptake of
X.400(1988).
Authors' Addresses
Only the two editors' complete addresses are listed here:
Erik Huizer (Task Force chair)
SURFnet bv
P.O. Box 19035
NL-3501 DA Utrecht
Europe
Phone: +31 30 310 290
RFC822: huizer@surfnet.nl
X.400: S=huizer;O=SURFnet;PRMD=surf;ADMD=400net;C=nl;
James A. (Jim) Romaguera
NetConsult AG
Berner Technopark
Morgenstrasse 129
CH-3018 Bern
Europe
Phone: +41 31 998 4141
RFC822: romaguera@netconsult.ch
X.400: S=romaguera;O=netconsult;PRMD=SWITCH;ADMD=ARCOM;C=CH;
The Task Force as a whole can be reached per e-mail at the
address:
RFC822: tf-88@SURFnet.nl
X.400: S=tf-88;O=SURFnet;PRMD=surf;ADMD=400net;C=nl;