💾 Archived View for gmi.noulin.net › rfc › rfc1616.gmi captured on 2024-05-26 at 17:00:10. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-05)
-=-=-=-=-=-=-
Keywords: RARE, Technical, Report, email
Network Working Group RARE WG-MSG Task Force 88
Request for Comments: 1616 May 1994
RARE Technical Report: 10
Category: Informational
X.400(1988) for the Academic and Research Community in Europe
A report by the RARE Task Force on X.400(1988)
of the RARE Working Group on Mail & Messaging
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
1. Abstract
The European research and development community, as represented by
the member research networks of RARE, has lead the deployment within
the global R&D community of X.400 electronic messaging services, as
specified in the international recommendations CCITT X.400(1984), for
more than five years. As a result of providing such services to the
European R&D users it has become clear that there is an existing and
ever increasing demand from these users for new and enhanced
electronic messaging services and product to be used to communicate
within the R&D community but within commercial service providers and
organisations as well.
It is also clear that new services, such as Multimedia messaging and
Secure messaging, and the resulting products promise dramatic
benefits and opportunities, for not only the R&D community but also
for the wider commercial, industrial and public communities, in terms
of facilitating innovative ways of working and living which can only
enhance the missions and goals of the respective communities. Not
least the establishment of globally pervasive messaging services
between all users, R&D and commercial, is facilitated by the early
adoption of such advanced new services. An indication of the
importance of such a messaging service can be appreciated if one
considers that in many organizations (especially commercially based)
messaging may be the only method to communicate between independent
organizations due to security considerations and lower layer network
differences.
The Commission of European Communities (CEC) VALUE subprogram II has
been established to support initiatives relating to the development
and adaptation of R&D networks in member states. Amongst other
RARE WG-MSG Task Force 88 [Page 1]
RFC 1616 X.400(88) for European Academics and Research May 1994
initiatives the VALUE program supports X.400 initiatives in certain
countries. VALUE support has so far been limited to X.400(1984)
initiatives, as X.400(1984) has up until now been the dominating OSI
services. However as X.400(1988) implementations have started to
appear a VALUE funded study of the X.400(1988) aspects of messaging
and their impact on the R&D community was felt necessary. This report
is one of the results of that study.
The report documents the results of a task force on X.400(1988)
deployment of the RARE Mails and Messaging Work Group during the
period from November 1992 until October 1993. Open reviews of the
report have occurred in the RARE Mail and Messaging Work Group and
within the IETF X.400ops Working Group.
The scope of the report is limited to deployment of X.400(1988)
services, and as such the report does not contain any recommendations
on development and deployment of Internet RFC 822 / MIME/ PEM related
(pilot) services. However, since the report shows that both
X.400(1988) and RFC 822 / MIME / PEM will be developed and used
within the European R&D community, such a pilot should also
considered. Note: RFC 822 is also known as Internet STD 11.
Circulation of this report is unlimited. Comments on this report may
be sent to the e-mail distribution list:
RFC 822: wg-msg@rare.nl
X.400: S=wg-msg;O=rare;P=surf;A=400net;C=nl;
Task Force Members:
Claudio Allocchio (INFN),
Harald T. Alvestrand (SINTEF),
James C. I. Craigie (JNT),
Urs Eppenberger (SWITCH),
Frode Hernes (maXware),
Jeroen Houttuin (RARE),
Erik Huizer (SURFnet) - chairman,
Steve Kille (ISODE Consortium),
James A. (Jim) Romaguera (NetConsult).
Editors: James A. (Jim) Romaguera & Erik Huizer
The work of this Task Force has been funded by the Commission of
European Communities (CEC) VALUE subprogram II, Stichting SURF and
SURFnet bv.
RARE WG-MSG Task Force 88 [Page 2]
RFC 1616 X.400(88) for European Academics and Research May 1994
Table of Contents
1. Abstract 1
2. Management Summary 3
3. Framework for the report 6
4. Present situation of European Messaging 7
4.1. Messaging services 7
4.2. Requirements for messaging 8
4.2.1. User Oriented 9
4.2.2. Service provider viewpoint 10
4.3. Messaging capabilities 11
5. Possible solutions for providing globally pervasive
messaging 12
5.1. PC LAN E-mail systems 13
5.2. RFC 822, MIME and PEM services 15
5.3. X.400 - 1984 and 1988 19
6. Migration to X.400(1988) 23
6.1. PC LAN E-mail systems 25
6.2. RFC 822, MIME and PEM services 25
6.3. X.400(1984) services 27
6.4. Mail-11 services 28
7. Benefits of migrating to X.400(1988) and the involved costs 28
8. Main Recommendations 33
9. Security Considerations 34
10. Reading List and Bibliography 35
11. Terminology 37
Appendix A - Elaboration on the main recommendations 38
Appendix B - A number of detailed guidelines. 40
Authors' Addresses 44
2. Management Summary
This document reports the results of study of the X.400(1988) aspects
of messaging and their impact on the R&D community. The study was
funded by the CEC under VALUE Subprogram II and has been carried out
by a task force on the RARE Mail Working Group. The document is
targeted at technical decision makers as well as those who would fund
activity in this area.
The document presents the existing situation as regards the
predominate messaging technologies within Europe. These are presented
within the context of a number of large messaging communities that
are using these technologies:
- RFC 822,
- X.400(1984),
- Mail-11 and
- PC LAN messaging
RARE WG-MSG Task Force 88 [Page 3]
RFC 1616 X.400(88) for European Academics and Research May 1994
Three major European communities are referenced:
- Commercial service providers
- R&D community
- Commercial organisations using messaging services.
The report states the following facts:
- The resources, human or financial, to operate multiple wide
area messaging services connecting together independent
organisations are high. As such it is desirable to try and
keep to a minimum the number of such services. This statement
is true for the R&D community but is also highly likely to be
valid for the general European industry.
- There are two publicly available technological standards
that can be used by open communities, such as the R&D
community and public service providers: the X.400(1984 and
1988) recommendations and the Internet RFC 822 / MIME / PEM
standards.
- There is an established very large global user base of
Internet RFC 822 and X.400(1984) messaging services. Both
services have their own momentum within different parts of
the user community, both are still developing and growing
fast.
The report concludes that X.400(1988) will be the preferred protocol
for inter organizational connection for European industry and
government and parts of the European R&D community. RFC 822 / MIME /
PEM will be the preferred protocol suite for inter-organisational
connection for the Internet community and, as products are already
widely available, it is the preferred protocol for parts of the
European R&D community.
The goal of European pervasive messaging - incorporating Industry,
Government and Academia - would be best accommodated and reached by
the establishment of a single messaging service. However taking the
above into account, this is not feasible, as X.400(84 and 88) and RFC
822( and MIME) based services will be around for a long time to come.
To increase the functionality of Wide Area E-mail services there is a
clear necessity to:
- migrate RFC 822 services to a RFC 822 / MIME / PEM service.
A MIME based service offers more functionality to the user
than a plain RFC 822 service.
- migrate existing X.400 services to a X.400(1988) service.
RARE WG-MSG Task Force 88 [Page 4]
RFC 1616 X.400(88) for European Academics and Research May 1994
Due to the lack of scalability of the X.400(1984) service in
terms of extra functionality, it will become increasingly
difficult to meet the needs of research users of existing
X.400(1984) services unless an X.400(1988) service is put
into place.
- provide a transparent gateway between X.400(1988) and RFC
822/MIME/PEM. For the European R&D community it is essential
to have a transparent gateway between the X.400(1988) service
and the RFC 822 / MIME / PEM service, thus ensuring
connectivity between these two services with a maximum
functionality.
Such a gateway is technically feasible and it is an essential part of
an unified E-mail service. Without such a standardised gateway the
overall E-mail service would deteriorate.
The lack of open standards for the PC LAN messaging systems
discourages their use as 'backbone' messaging technologies within
open communities. However the products that these systems deliver to
end users ensures that their already large share of the messaging
market will continue to exist for some time. Thus it is also
essential that strategies that allow these systems to be 'seamlessly'
integrated within the global messaging community are put in place.
Not least due to the indications that the main messaging vendors are
developing X.400(1988) and RFC 822/MIME gateways, a strategy to link
these systems together via X.400 and RFC 822 should be developed.
The report concludes with a set of recommendations, the main one
being the establishment of a X.400(1988) European pilot messaging
service for the R&D community. This pilot should include the
establishment of a transparent gateway service between X.400(1988)
and RFC 822/MIME. The goal of a European pilot is to ensure the
successful deployment of a European wide operational X.400(1988)
service that is pervasive and meets the needs of users. By collecting
together the issues related to the establishment of a European
X.400(1988) service, this report acts as a focal point and stimulant
for discussion on this topic within the R&D community. In the report
a summary of the benefits and problems of each of the above messaging
technologies within the context of achieving a global messaging
service, of which the R&D community is one part, is presented.
Further the document identifies issues, strategies and
recommendations related to the migration and coexistence of these
technologies within the scope of mainly the European R&D community
but also in relation to other messaging communities. A cost / benefit
analysis on the establishment of a European wide pilot X.400(1988)
messaging service is also presented. Finally a reading list of
references related to this subject has been compiled.
RARE WG-MSG Task Force 88 [Page 5]
RFC 1616 X.400(88) for European Academics and Research May 1994
The report does not include any recommendations on development and
deployment of RFC 822 / MIME / PEM related (pilot) services, as these
are outside of the scope of the Task Force. However, since the report
shows that both X.400(1988) and RFC 822 / MIME / PEM will be
developed and used within the European R&D community, such a pilot
should also be considered.
3. Framework for the report
With the belief that user demands for new messaging services such as
Multimedia and Secure Messaging would develop, the RARE community
(together with other communities; most notably the Internet
Engineering Task Force (IETF)) has over the preceding years
experimented in new messaging and related technologies. Experiments
and pilots, have been performed in messaging services e.g., as
recommended by CCITT X.400(1988) and Directory Services based upon
the CCITT X.500(1988) recommendations.
The results of such pilots and experiments indicate that it is now
opportune to commence a pilot X.400(1988) messaging service for the
European R&D community. The major goals of the pilot being, to
- establish a large scale European wide pilot messaging
service based on X.400(1988).
- collaborate with and facilitate the commencement of similar
pilot services within diverse communities; both R&D and non-
R&D (e.g., commercial ADMDs and PRMDs, etc.); both European
and non-European (e.g., North American , Asian, etc.).
- encourage and assist the development and deployment of a
wide variety of commercial and public domain X.400(1988)
messaging products that meet the user's needs, for instance
X.400(1988) products such as User Agents (UAs), Message
Stores (MSs), Message Transfer Agents (MTAs) and gateways
between X.400(1988) services and other widespread messaging
services i.e., RFC 822, Mail-11 and proprietary.
- prove that such a service and products efficiently meets the
existing and expected demands for new messaging services by
European R&D users. And as such determine the steps for a
European deployment of an operational X.400(1988) messaging
service.
- determine the needed steps to facilitate migration for the
existing operational R&D X.400(1984) based messaging service,
as represented by the R&D MHS service (the former COSINE
MHS), RFC 822 / MIME / PEM based messaging services and the
RARE WG-MSG Task Force 88 [Page 6]
RFC 1616 X.400(88) for European Academics and Research May 1994
HEPnet / SPAN Mail-11 based messaging service to an
operational X.400(1988) messaging service. It is self evident
that during such migrations, transition steps must be
included that allow a period of coexistence, at the highest
possible service level, between X.400(1988), X.400(1984), RFC
822 / MIME and HEPnet / SPAN Mail-11 services.
- determine the needed steps that allow proprietary messaging
systems, that are widely deployed within the European R&D
community to be integrated at as high as possible service
level, by an X.400(1988) infrastructure.
This report identifies the issues involved in such a pilot service.
It is not a concrete proposal for such a project but the report
discusses advantages and disadvantages, costs and enefits and
migration issues for deploying a X.400(1988) service. As such it is a
discussion and feasibility paper on the creation of a large scale
European wide pilot X.400(1988) messaging service for the European
R&D community.
4. Present situation of European Messaging
4.1. Messaging services
Electronic messaging within Europe can be viewed as a number of
messaging services communities. Three important communities comprise,
- Commercial e-mail networks,
- Research e-mail networks and
- PC LAN messaging systems.
Commercial e-mail networks are classified as either ADMDs or PRMDs.
ADMDs and PRMDs are operating in nearly every European country.
- ADMD services (or public commercial e-mail services) are
provided by over 50 service providers which have
interconnected using the X.400(1984) protocols. The topology
between these ADMDs, although not yet 'mesh', can be stated
as progressing quite rapidly to this optimum goal. However
there is still a way to go before ADMDs provide full European
connectivity.
- PRMDs (or private commercial e-mail service providers) have
interconnected to ADMDs and other PRMDs predominantly using
the X.400(1984) protocols but also with proprietary
protocols.
RARE WG-MSG Task Force 88 [Page 7]
RFC 1616 X.400(88) for European Academics and Research May 1994
Research networks are providing messaging services in every European
country. These R&D service providers are operated as either ADMDs or
PRMDs and are using both X.400(1984) protocols and Internet RFC 822
protocols to connect to each other.
Moreover, there are also large R&D communities (i.e., HEPnet and
SPAN) using proprietary protocols (i.e., DECnet Phase IV and Mail-11)
as their main messaging systems. The DECnet IV based communities are
now migrating to DECnet Phase V (OSI connectionless protocol stack),
which provides X.400(1988) (plus X.400(1984)) as a major messaging
system. In general, all these services are totally interconnected.
As such it is a statement of fact that there exists within the
European R&D community, two parallel interconnected messaging
infrastructures based upon X.400(1984) and RFC 822. However
interconnections between the R&D messaging community and the majority
of the European commercial service providers use the X.400(1984)
protocols.
It is also clear that the commercial world mostly makes inter-
organizational messaging interconnections using the X.400(1984)
protocols. And also that the commercial messaging world is not as
totally interconnected as the R&D messaging community. Finally, for
a number of commercial and public organisations there is often a
mandatory requirement to use X.400 for messaging interconnections.
The usage of PC LAN messaging systems is increasing very rapidly
within the academic and commercial communities. In general, PC LAN
messaging services within both communities do not use X.400(1984) or
RFC 822 messaging systems but systems based upon proprietary
protocols. The PC LAN messaging systems can be considered more as
'Islands of Messaging' that gateway to the commercial and R&D
messaging services by using X.400(1984) or RFC 822 gateways. PC LAN
messaging systems within commercial organisations connect to
commercial service providers also via proprietary protocols. The PC
LAN messaging services, although probably comprising the largest
number of users, are in general poorly integrated with the global
messaging service (The Dutch, UK and Italian academic communities
confirm that there appears to be many such 'Islands' of PC LAN
messaging systems within their networks.).
4.2. Requirements for messaging
Experience with existing global e-mail services has proven that with
the increased use of messaging, there follows an awareness of extra
requirements for related services. These requirements can be
classified into 'User based Requirements' and 'Service Provider based
Requirements' to either support, or exploit, high quality messaging
services. These requirements are elaborated upon within this chapter.
RARE WG-MSG Task Force 88 [Page 8]
RFC 1616 X.400(88) for European Academics and Research May 1994
4.2.1. User Oriented
The only thing a user requires is an easy to use, well integrated,
user interface to electronic mail. Usually the user does not care
what protocol is used. However there are certain inherent
requirements to the functionality that can be identified as user
requirements. The main user requirements identified are:
- Distribution Lists (DLs)
A widely perceived omission from the X.400(1984) recommendations
was the lack of support of DLs. Distribution lists allow users to
enlist themselves onto electronic mail expander lists
(distribution lists). A message to such a distribution list will
automatically, and without significant delay, be sent on to anyone
whose electronic mail address is on that list. Such a list can be
a public list, that is meant for discussions on a specific
subject, much like a sort of "magazine". However the list can also
be a "closed" list, containing only a selected set of people who
need to communicate privately, e.g., a project-team.
- Multinational language and Multimedia support
European users have for many years been frustrated in their
inability to use their national character sets when communicating
using messaging systems. The problems within e-mail systems that
were causing this character set frustration are at their base the
same problem that would get in the way of Multimedia messaging
like:
- lack of binary data support
- lack of standardised encoding schema's
- definition of multiple body-parts
The enormous potential of Multimedia systems and services
(especially within the commercial community as evidenced by the
enormous press publicity and mega-mergers positioning companies to
exploit this technology but also within the government spheres
i.e., the U.S.A. Government's 'Information Superhighway'
initiative) has acted as a spur to make rapid progress in solving
the problems in this area.
- White pages Directory Service
A white pages directory service provides a unique but very basic
and important service; a way to store and find information about
people and resources that is analogous to a telephone service's
paper based directory i.e., White Pages. User's E-mail addresses
RARE WG-MSG Task Force 88 [Page 9]
RFC 1616 X.400(88) for European Academics and Research May 1994
can be stored for subsequent retrieval by E-mail systems.
- EDI
EDI today is not extensively used within the academic environment.
However there is a distinct potential within the academic
community to reduce costs and improve services with EDI. Potential
EDI uses could be,
- EDI between universities
- EDI between universities and government
- EDI between universities and lower level educational
institutions (e.g., student records)
- Commercial EDI using the Internet as an infrastructure.
The significance of maintaining end to end integrity (especially
security aspects) of the EDI messages mandates that no gateways
should be used between originator and recipient.
- Support of Security services
E-mail as it is currently used is far from secure. To allow for
serious usage of E-mail security issues need to be addressed,
like:
- integrity; making sure that the message is transferred
intact, without any changes or additions.
- encryption; making sure the message content is only
decipherable by the intended recipient.
- authentication; making sure that the originator and/or
recipient are authenticated.
4.2.2. Service provider viewpoint
The task force believes the following points as being the most
significant service provider requirements:
- Network Management
This area is still very new, in terms of offering standardised
protocols, services and products for management. However a minimum
'goal' is to provide for central management functions that will
allow providers to offer a better quality of service. There is
presently ongoing work within the IETF Working Group MADMAN to
define SNMP monitoring and managing of E-mail systems, gateways
and X.500 directory systems. A number of management areas that
need to be worked upon include: QOS, Service Level Agreements
(SLAs), Multiple system queue management, Accounting, Routing Co-
RARE WG-MSG Task Force 88 [Page 10]
RFC 1616 X.400(88) for European Academics and Research May 1994
ordination and Message Tracing.
- Support of MTA routing
Dynamic routing from MTA to MTA, relieves the necessity to
maintain large routing tables, especially within a large PRMD, or
community of PRMDs (like the R&D MHS community).
- Address mapping between RFC 822 and X.400
The widespread use of X.500 or DNS for mapping, allows a reduction
of manpower for centrally co-ordinating globally consistent
X.400-to-RFC-822 mapping tables and distributes the responsibility
for updating the mapping rules. This should allow mapping rules to
change when needed and to be available immediately.
- UA capabilities registration
The use of the directory to register UA capabilities for
X.400(1988), X.400(1984) and RFC 822 / MIME / PEM systems is a
very desirable benefit for users in terms of speeding the
deployment of new messaging services (e.g., Multimedia Messaging).
4.3. Messaging capabilities
Due to the problems of gatewaying within a multi-protocol messaging
environment, the great majority of R&D E-mail users are reduced to
using only InterPersonal Messaging (IPM) services based upon the
exchange of message body parts using CCITT character set IA5 (US
ASCII).
Within the R&D community recent work to meet user requirements for
non ASCII messaging services - as documented above - has resulted in
enhancements to the messaging services based upon RFC 822 protocols.
The enhancements provide Multimedia support via the Multipurpose
Internet Mail Extensions (MIME) and the prospect in the very near
future of secure messaging via Privacy Enhanced Mail (PEM).
Deployment of the MIME enhanced RFC 822 based services, via
distribution of software and the setting up of the needed
organisational structures, has commenced. The PEM enhancements are in
a large scale pilot phase e.g., VALUE PASSWORD project.
In the case of X.400(1984) the usage of non ASCII body parts is
mostly effected by bilateral agreement between recipient and
originator, through use of body part 14. In practice this restricts
the exchange of non ASCII body parts to those cases where the
recipient and the originator use the same bilateral agreement or else
the originator includes an ASCII message explaining the included
RARE WG-MSG Task Force 88 [Page 11]
RFC 1616 X.400(88) for European Academics and Research May 1994
content type. Besides IPM there is a growing usage of EDI on top of
X.400(1984).
With the above X.400(1984) deficiencies in mind, X.400(1988) has been
specified by the CCITT / ISO to meet new user demands. X.400(1988)
provides support for various different body parts, enhanced security
features, international character set support capabilities and
support of X.500 Directory Services. Due to the technological
potential of these standards to satisfy user needs for new messaging
services, the R&D community has been experimenting and piloting
X.400(1988) and X.500(1988) services. As there is a strong
dependency of X.400(1988) messaging upon X.500(1988) directory
services, the necessary precondition to supply these user demands is
a deployed and operational X.500(1988) directory service. Piloting
and deployment of the X.500(1988) directory service within the R&D
community has been successfully initiated and co-ordinated by the
COSINE and the VALUE PARADISE projects.
Similarly, secure messaging has been addressed by the VALUE PASSWORD
project and the RARE and IETF communities. Work to solve problems
related to directory support of X.400(1988) messaging has been
pursued within the IETF and RARE. The relevant RARE and IETF work
groups (e.g., RARE WG-MSG, IETF MHS-DS, etc.) have also worked to
produce any needed enhancements to the base X.400(1988) and
X.500(1988) standards. Last but not least it should not be
overlooked that X.400(1988), as compared to X.400(1984), provides a
comprehensive basis for gatewaying to and from RFC 822 / MIME / PEM
and PC LAN messaging services. To that respect the IETF has defined
standards for gatewaying Multimedia mail between RFC 822 / MIME / PEM
and X.400(1988). As RFC 822 / MIME / PEM is now being deployed on the
Internet, deployment of X.400(1988) services is needed to assure
multimedia and secure messaging connectivity for the European R&D
community.
5. Possible solutions for providing globally pervasive messaging
As can be now seen, a correlation of the present situation to the
requirements of the user, shows that the current messaging services
do not match the needs of users. To try to meet these needs a number
of developments within various messaging technology areas are
occurring. The following messaging technological areas, due to the
present installed user base within the R&D community, are considered
relevant:
- PC LAN E-mail systems such as Lotus cc:Mail, Microsoft Mail
and Novell MHS
- RFC 822 / MIME / PEM E-mail services
- X.400(1988) messaging services
RARE WG-MSG Task Force 88 [Page 12]
RFC 1616 X.400(88) for European Academics and Research May 1994
Ongoing developments within each of the above technological areas
provide new messaging options for the R&D community. The ability of
each technological area to provide solutions for user and service
provider requirements is summarised within this chapter.
5.1. PC LAN E-mail systems
Currently the usage of PC LAN E-mail systems is mostly for internal
communication within an organisation. External connections, if
present at all, to public service providers or other organisations is
mostly through gateways to X.400(1984) or RFC 822. The use of a PC
LAN E-mail system in terms of an infrastructure for interconnecting
E-mail systems of different hues is not common within the Research
community. Recent experience, from amongst others the Dutch Research
network - SURFnet - [14] and the Norwegian Directorate for Public
Management - Statskonsult - [18], has shown that a number of problems
(i.e., limited functionality, high operational management cost, etc.)
can be expected should these PC LAN E-mail systems be used as an E-
mail infrastructure. (The use of native X.400 protocols for PC LAN
E-mail systems would avoid the usage of gateways and would thus
alleviate many of these problems.) A summary of those problems and
some relevant issues follows:
- Interconnecting heterogeneous PC LAN messaging systems
One very distinct benefit for E-mail users of all hues is the
potential to integrate heterogeneous PC LAN messaging systems with
a minimum loss of service (e.g., multimedia services) by
connecting them via X.400(1988) (or RFC 822/MIME/SMTP).
X.400(1988) is already being used, or under active development,
for connecting together PC LAN messaging systems in a number of
environments (e.g., Apple Macintoshes, DEC, Microsoft, Lotus,
etc.). This tendency to gateway PC LAN messaging systems via
X.400(1988) will increase and is one of the benefits that
X.400(1988) brings to global multiprotocol messaging.
- Multimedia and binary data support
The benefit of E-mail systems using these PC LAN systems is that
the user interfaces are usually well integrated in the users
standard working environment. Using a proprietary protocol these
systems allow not only text (ASCII) but also binary, word
processor, video, audio and other types of files to be
transported. To reap the benefits of this multimedia / binary data
transfer it would normally require that the same type of gateway
is used by sender and receiver. Transporting these same files to
another type of PC LAN E-mail system is not possible through the
RARE WG-MSG Task Force 88 [Page 13]
RFC 1616 X.400(88) for European Academics and Research May 1994
current gateways without some information loss. In effect PC LAN
E-mail system's X.400 (or RFC 822) gateways from different vendors
perform acceptably only for text body parts. True heterogeneous
multimedia PC LAN messaging needs gateways to X.400(1988)'s
service.
- Application Programming Interfaces
To help solve the problem of portability for Mail Enabled
Applications Microsoft, Lotus, Novell, XAPIA and X/OPEN have been
working on a number of standards for the Application Interface to
mail transport protocols (i.e., Mail Application Programming
Interface - MAPI, Vendor Independent Messaging - VIM, Common Mail
Calls - CMC). These efforts are structured independent of the
existing 'Wide-Area' or inter organisational E-mail protocols of
X.400(1984) and RFC 822. However the MAPI, VIM and CMC efforts,
due to their proposers (respectively Microsoft, Lotus and X/OPEN),
do look like they will provide the stimulant to various software
developers to develop more portable applications plus allow the
rich functionality of X.400(1988) to be accessed by these
applications thus reducing the need for gatewaying to X.400(1988).
- Security
As the PC LAN E-mail systems require gateways for connectivity,
they pose a problem with regard to encrypted messages. Gatewaying
of secure messages is normally not possible. The gatewaying of
secure messages is a general problem of gatewaying from one mail
system to any other system and is not specific to PC LAN E-mail
systems.
- Directory Services
To date mostly proprietary directory services have been deployed
that do not match the needs of the users in terms of access
controls for data, distributed and decentralised across
organisations. X.500 based services promise solutions to such
needs. As a result various suppliers have announced support of
X.500 directory services for their E-mail products. However,
should these interfaces be delayed then support of an inter
organisational 'White Pages' services requires either,
- directory information exchange products (i.e., directory
gateways) deployed between a proprietary system and an X.500
directory system
RARE WG-MSG Task Force 88 [Page 14]
RFC 1616 X.400(88) for European Academics and Research May 1994
- gateways between de-facto market based proprietary
standards, such as Retix Directory Exchange (DX) or
Soft*switch's Directory Synchronisation (DS), and X.500
protocols
- duplicated directories i.e., one proprietary and one X.500
need to be operated.
It should be stressed that gatewaying mechanisms and products are
often problematic due to the lack of an open standard on the
proprietary messaging system and or directory system. (As an aside it
is thus essential to establish an operational X.500 infrastructure,
including E-mail user interfaces that can transparently access this
Directory Service, as soon as possible.)
5.2. RFC 822, MIME and PEM services
RFC 822 messaging services are widely deployed within the R&D
community. There is ongoing work to extend RFC 822 to meet user
requirements. Some of these extensions are elaborated upon within
this chapter.
- Distribution lists
RFC 822 allows for the usage of DLs. Management of DLs is not
(yet) standardised.
- RFC 822 multimedia messaging via MIME
With the arrival of MIME, the RFC 822 service has an additional
protocol standard that addresses Multimedia messaging very
comprehensively. In terms of user needs, MIME now allows messaging
body parts to comprise multinational character sets and binary
data. Multi-body part messages are also supported. One of MIME's
real strengths, in terms of deployment within the existing RFC 822
service, is that it achieves its goals by overlaying its services
over the existing RFC 822 service and thus mandating no changes to
the in place RFC 822 infrastructure. This greatly simplifies the
MIME deployment.
- RFC 822 secure messaging via PEM
Just as MIME has brought multimedia messaging to RFC 822 services,
Privacy Enhanced Mail (PEM) is bringing secure messaging to RFC
822 services. PEM also has used the same approach as MIME to
deploy secure messaging within RFC 822 services; overlay PEM
services over the existing RFC 822 services without requiring
changes to the RFC 822 infrastructure. PEM brings confidentiality
RARE WG-MSG Task Force 88 [Page 15]
RFC 1616 X.400(88) for European Academics and Research May 1994
and integrity of messages to RFC 822 users. However a number of
problems with PEM, and X.400(1988) as well, still need to be
solved before secure messaging can be considered to be an
operational service. These problems are independent of the secure
messaging protocol (i.e., PEM or X.400(1988)) and deal mainly with
distribution of secret keys to the end users. There is very active
work going on within the IETF to solve these problems.
- MIME and PEM
There are still problems for messages that are simultaneously a
multimedia message, as per MIME, and a secure message, as per PEM.
A PEM encoded MIME message does not allow gatewaying to other
messaging environments and therefore does not allow any of the
features inherent within MIME to be exploited along the message
path. A MIME message that contains PEM encoded body parts can be
gatewayed but the integrity of the entire message is then not
guaranteed. This is a real deficiency of both existing approaches
as it is essential that users are able to simultaneously use
multimedia and secure messaging. However, once again, the IETF is
working very hard on solving these problems and solutions can be
expected, although the solution of the gatewaying of PEM messages
to other E-mail systems is still unclear.
- Dynamic and distributed messaging routing via the Domain Name
System (DNS)
RFC 822 messaging benefits greatly by having a dynamic and
distributed mechanism to assist in message routing i.e., Domain
Name System (DNS). With the support of the DNS, RFC 822 MTAs are
able to directly route to other RFC 822 MTAs and thus deliver
messages with a minimum of delay. In practice mail often still
traverses multiple RFC 822 MTAs for a number of reasons e.g., Mail
Hubs provided for users who turn their machine off when they go
home, Firewall Hubs for security reasons, etc. However it is
commonly accepted that between RFC 822 mail hubs the delivery of
messages is very fast. Typically resolution of routing decisions
occurs in less than one minute and very often within seconds. In
general the DNS service is a very valuable service that functions
well in practice.
- Support for Character sets
Together with the MIME specification for content types, an
extension for RFC 822 headers was defined that allows for usage of
multiple character sets in names, subject etc. in RFC 822 headers
[9]. This allows (European) users to use their preferred character
set to support their language not only in the contents of a
RARE WG-MSG Task Force 88 [Page 16]
RFC 1616 X.400(88) for European Academics and Research May 1994
message but also in the headers.
- MIME capable gateways
It is clear that to provide a seamless service to all users
regardless of whether they are using RFC 822 or X.400 services, a
widely available set of well run and standardised RFC 822 to X.400
gateways must be in place. For InterPersonal Messaging (IPM) based
on US ASCII there are already a large number of such standardised
(i.e., X.400-to-RFC 822) gateways deployed. To ensure seamless
gatewaying between MIME and X.400 multimedia users, these existing
text based gateways must be either upgraded to or replaced with
multimedia messaging gateways. A number of proposed Internet
standards to solve these problems, for both X.400(1984) and
X.400(1988) and generated within the MIMEMHS work group of the
IETF, have been completed [4].
- Access to fax, teletex, telex or physical delivery
For the moment, there is no standardised way for RFC 822 users to
access gateways to the above services except by indirect access to
X.400(1988) systems (i.e., concatenated gateways of RFC 822 to
X.400(1988) and then onwards to the appropriate X.400(1988) Access
Unit). Although even this indirect method would require some
further work on standardising mappings between RFC 822 addresses
and X.400(1992)'s X.121 addresses. As well some experiments within
the RFC 822 world are occurring on routing fax messages.
- Operational support
Generally, RFC 822 messaging services are delivered on a 'best
effort' basis and thus service level agreements requesting
stringent response times to operational problems or guaranteed
delivery times for messages are difficult to agree. This phenomena
might be a result of the distribution and delegation of authority
to organisations updating the RFC 822 MTA's routing mechanism
i.e., DNS. As a result it makes it hard to reach a 'one stop
shopping' agreement for RFC 822 messaging services.
- Notifications
The RFC 822 service provides a minimum amount of base protocol
support for messaging users. It could be argued that the RFC 822
protocol is simplified by this choice and thus software that
implements the standard need be smaller in size and easier to
build. However some features e.g., delivery & receipt
notifications and UA capabilities registration, would be commonly
accepted as being desirable from a user standpoint and thus
RARE WG-MSG Task Force 88 [Page 17]
RFC 1616 X.400(88) for European Academics and Research May 1994
desirable extensions to RFC 822. Some operational problems
relating to reliability could be minimised by technology that has
a standardised support for positive and negative notifications of
messages. RFC 822, as compared to X.400, technology does not yet
support positive notifications (although there is work starting
within the IETF to extend RFC 822 to support delivery
notifications). However within RFC 821 transport system (i.e.,
SMTP) there are standardised negative notifications that work
well. Alternatively X.400 technology, deployed over TCP/IP (using
STD 35, RFC 1006), may help to address the lack of adequate
service quality - notification support - when using E-mail within
the Internet.
- Portability of RFC 822 products
There are only a few mailbox formats in general use by RFC 822
software, one being the 'bin/mail' format and the other 'MH'
format. This 'standard' mailbox format is a definite benefit for
RFC 822 users as it allows them to change RFC 822 UAs (e.g.,
upgrading to MIME RFC 822 UAs) whilst not compromising or
converting their existing archived mail, which may comprise 1000s
of archived messages.
- System support for RFC 822 products
Normally, RFC 822 MTAs and UAs come pre-installed on UNIX
workstations. As a result, users are spared the effort of
installing RFC 822 MTA software. If for some reason, a user or
mail administrator should wish to install a different MTA or UA to
the pre-installed system, there exists a large number of easily
available (i.e., via widespread distribution amongst many FTP and
other information servers) public domain RFC 822 MTAs and UAs.
Both of the above points encourages the spread and eases the
installation of software for the RFC 822 messaging service and in
many ways explains the size and importance of the installed base
of RFC 822 systems. To illustrate the extent of RFC 822 / MIME
products, a non-comprehensive list of available MIME enhanced RFC
822 products follows; ELM 2.4, MH 6.8, Sun Mailtool, HP Mpower
Desktop, Lotus cc:Mail (unconfirmed), Zcode Zmail, Frontier
Super-TCP for Windows, PMDF (VAX VMS), Pine, C-Client (library
routines), Metamail (viewer only), Andrew-MIME gateway.
- UA capability registration
The IETF MHS-DS working group has defined how X.400 and RFC 822
User Agent capabilities can be stored in X.500 directory services.
This work is still ongoing.
RARE WG-MSG Task Force 88 [Page 18]
RFC 1616 X.400(88) for European Academics and Research May 1994
5.3. X.400 - 1984 and 1988
X.400(1988) substantially upgrades and enhances the X.400(1984)
standards. A number of new functions have been incorporated within
X.400(1988). A description of the most important features of X.400 -
1984 and 1988 - follows.
- Notifications
X.400(1984) provides four notifications - positive and negative
delivery notifications and positive and negative receipt
notifications. These notifications allow users to ensure
successful message delivery or that the message was read. The
delivery notifications are also used by service operators in their
fault escalation procedures.
- Binary Data Transfer
X.400(1984) allows binary data transfer to be transported without
the necessity of character encoding. The ability to transfer files
of whatever type is a valuable end user service. As well the lack
of any necessary character encoding allows users to utilise the
received data without needing any character decoding software.
- Multiple Body Parts
The ability to send multiple body parts within one message gives
the user the ability to send multiple logical components within
one message. This is a natural mechanism for users as it mirrors
the real life situation of being able to send within one message,
a letter, a word processor file, a spreadsheet file, etc.
- Feature rich messaging model
The features of X.400 are very rich. This provides benefits for
users as vendors are able to provide applications that can utilise
these extensive features in an interoperable manner due to the
standardisation of the features within X.400.
- Clear messaging model
X.400(1984), as one of its most wide reaching achievements, has
popularised within the market a consistent and clear model to
describe message handling systems. The decomposition of a message
handling system into UAs, MSs, MTAs, MTS - ADMDs and PRMDs and
Access Units / Gateways has proved to be an extremely useful tool
for users and vendors to understand and communicate their
messaging needs or solutions.
RARE WG-MSG Task Force 88 [Page 19]
RFC 1616 X.400(88) for European Academics and Research May 1994
- Multiple lower layer networks
X.400 has embraced the concept that there are different technology
lower layer networks. This concept even allows multiple logical
networks of the same technology to be supported. X.400 allows the
messaging service to fully function even though the underlying
network is varying. In the real world of a non-uniform network
layer this is an extremely powerful capability.
The list of major X.400(1988) extensions to X.400(1984) follows:
- Distribution Lists (DLs)
A powerful mechanism for arbitrarily nested Distribution Lists
including the ability for DL owners to control access to their
lists and to control the destination of non delivery reports. The
current endemic use of DLs in the R&D community makes this a
fundamental requirement for any service. X.400(1988) uses X.500 to
provide a standardised support for DLs, although there have been
some needed standardised enhancements relating to the CCITT
defined DLs by the IETF MHS-DS work group. The provision of
powerful nesting capabilities plus management mechanisms for DL
owners within X.400(1988) DLs are features providing attractive
benefits for users and DL managers. There is already 'running
code', via the COSINE Explode project which is implementing the
MHS-DS based enhancements. The project builds upon experience
gained within a number of networks e.g., JNT and provides:
- implementation of MHS-DS enhancements related to the
X.400(1988) DLs
- archiving of messages received by a DL.
- access by users to the DL archive via e-mail.
- subscription to a DL by users via e-mail.
- Message Store (MS)
The Message Store provides a server for remote UAs on workstations
and PCs enabling messages to be held for their recipient, solving
the problems of non-continuous availability of such UAs. The
message store allows mobile workers, small offices and local
schools to become active messaging users in a cost effective
manner. The message store provides powerful selection mechanisms
allowing the user to select messages to be transferred between the
store and the workstation. This facility is not catered for
adequately by the P3 protocol of X.400(1984) and provides a major
incentive for transition.
RARE WG-MSG Task Force 88 [Page 20]
RFC 1616 X.400(88) for European Academics and Research May 1994
- X.500 Directory names
Support for use of Directory Names in MHS will allow a transition
from use of O/R addresses to Directory Names when X.500
Directories become widespread, thus removing the need for users to
know about MHS topological addressing components.
The ability for X.400(1988) messages to contain directory names
instead of the O/R addresses is a powerful feature for users as it
frees them of the necessity to insert O/R addresses containing
routing information but allows them to insert the more natural
directory names. However, the management of the large amounts of
distributed data contained within the directory is problematic in
that it involves a number of organisational issues and not just
software issues. A number of X.400(1988) UAs which allow users to
insert directory names instead of O/R addresses have already been
developed.
- Support for EDI
Through the definition of Pedi, as defined in X.435, X.400(1988)
offers integrated support for EDI messaging. The CEC TEDIS program
has mandated X.400 as the main carrier for EDI, and standardised
how EDI transactions are inserted into X.400 messages (i.e., Pedi
and P2). This provides a strong incentive to provide native
X.400(1988) services to users and applications thus encouraging
commercial EDI traffic to migrate to X.400(1988).
- Secure Messaging
The provision of secure messaging services including
authentication, confidentiality, integrity and non-repudiation as
well as secure access between MHS components are important
benefits for the R&D community. The base standards are adequate
for security, however organisational and software issues need
still to be solved. Organisational issues of globally scaling the
distribution of secret keys is still unsolved. Software issues of
how end users will be able to comfortably and securely input
secret keys of length 512 -> 1024 bits into security software need
to be solved.
- Multimedia
The definition of a number of additional body parts plus the
ability to define new body parts (e.g., Word Processor formats,
Excel documents, etc.) provides the basis for multimedia services
over X.400(1988). As well, the newly defined General Text body
part supports multinational character sets (except for ISO 10646)
RARE WG-MSG Task Force 88 [Page 21]
RFC 1616 X.400(88) for European Academics and Research May 1994
without the need for transmission encoding. However, unlike MIME,
X.400(1988) is only specifying a standard for multimedia
messaging. To achieve multimedia document exchange, there is a
further text exchange standard such as ODIF, Hytime, etc., needed.
- Character set support for extended addressing
A highly desirable potential benefit for European R&D users is
provided by the extended character set support(i.e., T.61) within
addresses. Nearly all European languages, except for Greek and
Cyrillic, are supported by the T.61 teletex encoding. Further
extensions to X.400 for support of extended character sets has
been defined by the RARE WG on character sets and RARE WG on
messaging [15].
- Physical Delivery Services
This standardised method for a message to be delivered on a
physical medium, such as paper, through the normal postal service
is useful when trying to reach a very wide number of (non-
electronically reachable) recipients. In effect this service
provides an ability to 'go the last mile' and communicate with
users previously not easily reachable e.g., farmers, etc.
- General Extension Mechanism
One of the major assets of X.400(1988) is the extension mechanism.
This is used to carry most of the extensions defined in these
standards, but its principal benefit will be in reducing the
trauma of transitions to future versions of the standards.
Provided that implementations of the X.400(1988) standards do not
try to place restrictions on the values that may be present, any
future extension will be relayed by these implementations when the
extension is not critical, thus providing a painless migration to
new versions (1992 and beyond) of the standards.
- UA Capability Registration
With the extra functionality available to X.400(1988 and
especially 1992) UAs (i.e., extra non-IA5 body parts, secure
messaging, etc.) it is expected that the demand to register UA
capabilities will increase. In that respect X.400(1988)'s ability
to query X.500, where such capabilities would be stored, is a
significant potential benefit for users.
RARE WG-MSG Task Force 88 [Page 22]
RFC 1616 X.400(88) for European Academics and Research May 1994
- X.500 support for MTA routing
The piloting of X.500 to support MTA routing within the R&D
community has already commenced, on a small experimental scale,
via the Longbud project co-ordinated by the IETF MHS-DS work
group. Some concrete benefits promised by X.500 based routing are:
- routing based upon content types, security, transport stacks
and other criteria allow optimum routing paths to a
destination MTA to be chosen. (There is presently no such
similar capability within the DNS).
- allowing the routing information to be inserted and modified
in a distributed manner reduces (if not eliminates) the
necessity of central distribution of static routing tables.
The consequent reduction in manpower to co-ordinate MTA
routing plus the increase in scalability of the service
allows a truly global messaging service to be put in place.
6. Migration to X.400(1988)
What is clear from the previous chapters is that;
- The resources, human or financial, to operate multiple wide
area messaging services connecting together independent
organisations are high. As such it is desirable to try and
keep to a minimum the number of such services. This statement
is true for the R&D community but is also highly likely to be
valid for the general European industry.
- There are two publicly available technological standards
that can be used by open communities, such as the R&D
community and public service providers: the X.400(1984 and
1988) recommendations and the Internet RFC 822 / MIME / PEM
standards.
- There is an established very large global user base of
Internet RFC 822 and X.400(1984) messaging services. Both
services have their own momentum within different parts of
the user community, both are still developing and growing
fast.
From the above discussion, it is clear that the infrastructure
services that have to be supported within these open communities, and
especially within the R&D community, are RFC 822 / MIME / PEM,
X.400(1984) and X.400(1988). X.400(1988) will be the preferred
protocol for inter-organisational connection for European industry
and government and parts of the European R&D community. RFC 822 /
RARE WG-MSG Task Force 88 [Page 23]
RFC 1616 X.400(88) for European Academics and Research May 1994
MIME / PEM will be the preferred protocol suite for inter-
organisational connection for the Internet community and, as products
are already widely available, it is the preferred protocol for parts
of the European R&D community.
The goal of European pervasive messaging - incorporating Industry,
Government and Academia - would be best accommodated and reached by
the establishment of a single messaging service. However taking the
above into account, this is not feasible, as X.400 and RFC 822 based
services will be around for a long time to come. To increase the
functionality of Wide Area E-mail services there is a clear necessity
to:
- migrate RFC 822 services to a RFC 822 / MIME / PEM service.
A MIME based service offers more functionality to the user
than a plain RFC 822 service.
- migrate existing X.400 services to a X.400(1988) service.
Due to the lack of scalability of the X.400(1984) service in
terms of extra functionality, it will become increasingly
difficult to meet the needs of research users of existing
X.400(1984) services unless an X.400(1988) service is put
into place.
- provide a transparent gateway between X.400(1988) and RFC
822/MIME/PEM. For the European R&D community it is essential
to have a transparent gateway between the X.400(1988) service
and the RFC 822 / MIME / PEM service, thus ensuring
connectivity between these two services with a maximum
functionality.
Such a gateway is technically feasible and it is an essential part of
an unified E-mail service. Without such a standardised gateway the
overall E-mail service would deteriorate.
The lack of open standards for the PC LAN messaging systems
discourages their use as 'backbone' messaging technologies within
open communities. However the products that these systems deliver to
end users ensures that their already large share of the messaging
market will continue to exist for some time. Thus it is also
essential that strategies that allow these systems to be 'seamlessly'
integrated within the global messaging community are put in place.
Not least due to the indications that the main messaging vendors are
developing X.400(1988) and RFC 822/MIME gateways, a strategy to link
these systems together via X.400(1988) and RFC 822/MIME should be
developed.
RARE WG-MSG Task Force 88 [Page 24]
RFC 1616 X.400(88) for European Academics and Research May 1994
To make migration to a X.400(1988) service feasible, extensive
migration and coexistence options for various non-X.400(1988) users
have to be developed. Main issue in each migration strategy remains
the co-operation of the users. The migration needs to be user-driven,
i.e., the users need to be convinced of the added functionality
(versus the cost) of migrating towards X.400(1988). A detailed
summary of the different issues and possible problems involved in the
transition to a X.400(1988) based messaging service, with respect to
what are commonly accepted as the four most important messaging
services: RFC 822, MIME and PEM; X.400(1984); MAIL-11 and PC LAN
messaging systems are presented in this chapter.
6.1. PC LAN E-mail systems
To provide coexistence and migration the usage of gateways is
unavoidable. The quality of these gateways, with regard to:
- Transparency (gatewaying multimedia messages, transparent
addressing)
- Manageability
- Reliability
has to be improved. Ultimately through usage of APIs like MAPI and
CMC, the users interface hopefully will become independent of the
mail protocol that is used. It will then be expected to be possible
to let the user retain his preferred mail user interface, while the
protocol used migrates to X.400(1988).
Via the use of these APIs it may be possible to access the full
features of X.400(1988) while retaining a proprietary PC LAN UAs.
This way a PC LAN can be easily connected to a X.400(1988) backbone.
This usage of APIs to ease migration for end users should be
encouraged.
The migration of PC LAN E-mail systems will likely be driven by the
commercial vendors of mail enabled applications, such as UAs, Work
Group Systems, Task Flow Systems plus X.400(1988) MTAs and gateways
able to serve these applications via these new APIs.
6.2. RFC 822, MIME and PEM services
A migration from RFC 822 / MIME and PEM services to X.400(1988) needs
to be formulated for those management domains that wish to effect
this change. As well a long term transition and coexistence phase
needs to be accommodated due to the existing base of RFC 822 users.
An understanding of the issues involved in migrating from RFC 822 to
X.400(1988) messaging services is essential before any rational
decisions on migration can occur. Certainly one, if not the main,
RARE WG-MSG Task Force 88 [Page 25]
RFC 1616 X.400(88) for European Academics and Research May 1994
issue in such a migration is that the migration must allow a
transition period where maximum functionality between both services
exists. Any migration must be aware that RFC 822 messaging services
are a 'moving target'.
- Ease of transition as perceived by an RFC 822 user mandates
that the user's existing mail folders are converted into the
new mail product's folder system flawlessly.
- The RFC 822's user's e-mail address should remain the same
even after a migration. (i.e., the user keeps the same address
that has two different notation forms: X.400 and RFC 822).
- Users contemplating a migration will be stimulated to do so
if they experience no loss of service as regards MIME and
X.400(1988) gatewaying; are still able to insert RFC 822
style addresses into the X.400(1988) UA and are provided with
high performance X.400-to-RFC 822 gateways.
- The added connectivity provided by X.400(1984 or 1988)
gateways to fax, telex, post etc. plus additional X.400 users
that the user is able to reach easily (whilst not losing
connectivity to RFC 822 addresses) plus the additional
functionality of X.400(1988) possible when communicating with
X.400(1988) users will also act as a stimulant to a
migration.
- The functionality provided by RFC 822 / MIME products will
be the yardstick that an RFC 822 user compares an offered
X.400(1988) product with. As such X.400(1988) products must
provide some basic and important functions like: Character
Set support via GeneralText; Multimedia capability via
Extended Body Parts; low message delays within the seconds
time scales and ease of configuration of products. At present
there is no RFC 822 equivalent to X.400 delivery and receipt
notifications and as such these functions are seen as extra
functionality by the user.
- A follow on to the extra functionality point above is that
present RFC 822 users, most likely commercial users, that
want to be able to use EDI or other mail enabled applications
that need security, message audits and positive confirmations
will be encouraged to migrate to X.400(1988). A decision to
use X.400(1988) in this case would be especially attractive
for those commercial RFC 822 users that are already operating
multiple lower layer networks. As X.400(1988) accommodates
multiple different network layers easily, the cost to migrate
could be considered quite small.
RARE WG-MSG Task Force 88 [Page 26]
RFC 1616 X.400(88) for European Academics and Research May 1994
6.3. X.400(1984) services
A number of problems can be identified in a migration from
X.400(1984) to X.400(1988). They are summarised as,
- OSI supporting layers are mandatory in the ISO10021 MOTIS
standard, while the support of the complete OSI stack (normal
mode ) is optional in the otherwise equivalent CCITT
X.400(1988) specifications. It is thus recommended that the
migration from X.400(1984) should be straight to ISO 10021
i.e., straight to use of the full OSI stack with normal mode
RTS.
- There is a negative impact on quality of service caused by
implementation decisions related to the 'General Extension
Mechanism'. To overcome this negative impact no minimal
X.400(1988) MTAs, which relay the syntax but understand none
of the semantics of extensions, should be used.
- All X.400(1988) MTAs should generate reports containing the
extensions that are present in the original message and route
such reports through the DL expansion hierarchy where
appropriate.
- Choice of standards to be used within mixed X.400(1984 and
1988) management domains needs to accommodate in one option
the danger of undetectable routing loops from incorrectly
configured routing entries and in another option the problem
that systems that have fixed the routing loop problem may not
all be consistently implemented due to ambiguities within the
standards. The choice of which of these two options a
management domain uses internally has no impact on external
management domains.
- DDA support is needed by X.400(1984) systems to address
X.400(1988) Common Name Attribute users [2].
- Minimum loss of service quality mandates that downgrading of
X.400(1988) body parts to X.400(1984) bodyparts be done
according to the MIMEMHS specifications [4].
- 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.
RARE WG-MSG Task Force 88 [Page 27]
RFC 1616 X.400(88) for European Academics and Research May 1994
- Ensuring that no X.400(1988) MTAs transit via X.400(1984)
MTAs. This allows no degradation of X.400(1988) service
quality [17].
The consequence of the last point is that the existing European
Research X.400(1984) - formerly COSINE MHS - MTA RELAY backbone
should be one of the first MTA communities to migrate to X.400(1988).
6.4. Mail-11 services
The Mail-11 (also known as DECnet mail) e-mail service is the major
e-mail service used within the High Energy Physics and Space Physics
Analysis Networks (i.e., HEPnet and SPAN) and is the native e-mail
service present on VMS operating systems. The Mail-11 service is
considered the most popular service by the large HEPnet / SPAN
community. Mail-11 provides also large and easy to use gateways to
other E-mail protocols, like X.400 (84), RFC 822 (SMTP over TCP/IP,
DECnet and X.25, BSMTP over NJE), and PC LAN E-mail services.
Jointly with the "old style" Mail-11 UA, the DECnet Phase V (OSI
CLNS) service provides the native capability to run X.400 (88) and
X.400(1984) services. There is thus the potential for X.400 (88)
services to become available as soon as the HEPnet / SPAN community
migrates to DECnet Phase V. However the availability of VMS based UAs
for the X.400(1988) service is still very limited and is thus forcing
users to continue to stay with their Mail-11 UA (and thus the Mail-11
service).
Users in HEPnet / SPAN are demanding enhancements to their mail
services to support multimedia and delivery / read receipt services.
This is a strong driving factor for good X.400(1988) UAs to become
available soon to allow users to properly use the available
X.400(1988) service of DECnet Phase V.
7. Benefits of migrating to X.400(1988) and the involved costs
The actual as compared to the potential benefits of migrating from
one's existing mail system to a new mail protocol is very dependent
on good products, good organisation of the migration and a degree of
commitment that the transition is worth the cost. Quantifiable and
accurate cost / benefit ratios for such a migration are not possible
within the decentralised European R&D environment and as such are not
generated.
We have in this chapter listed the benefits that such a migration to
X.400(1988) achieves. We have also given an indication of the
relative costs of such a migration. Provided that there are good
products, and taken in conjunction with the recommendations of
RARE WG-MSG Task Force 88 [Page 28]
RFC 1616 X.400(88) for European Academics and Research May 1994
Chapter 8 and Appendices A and B, the task force is confident that
these potential benefits will translate into actual benefits and be
worth the costs incurred.