As per Relevance of the word research, we have this rfc below:
Network Working Group RARE WG-MSG Task Force 88
Request for Comments: 1616 May 1994
RARE Technical Report: 10
Category:
X.400(1988) for the Academic and Research Community in
A report by the RARE Task Force on X.400(1988)
of the RARE Working Group on Mail &
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
1.
The European research and development community, as represented
the member research networks of RARE, has lead the deployment
the global R&D community of X.400 electronic messaging services,
specified in the international recommendations CCITT X.400(1984),
more than five years. As a result of providing such services to
European R&D users it has become clear that there is an existing
ever increasing demand from these users for new and
electronic messaging services and product to be used to
within the R&D community but within commercial service providers
organisations as well
It is also clear that new services, such as Multimedia messaging
Secure messaging, and the resulting products promise
benefits and opportunities, for not only the R&D community but
for the wider commercial, industrial and public communities, in
of facilitating innovative ways of working and living which can
enhance the missions and goals of the respective communities.
least the establishment of globally pervasive messaging
between all users, R&D and commercial, is facilitated by the
adoption of such advanced new services. An indication of
importance of such a messaging service can be appreciated if
considers that in many organizations (especially commercially based
messaging may be the only method to communicate between
organizations due to security considerations and lower layer
differences
The Commission of European Communities (CEC) VALUE subprogram II
been established to support initiatives relating to the
and adaptation of R&D networks in member states. Amongst
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
countries. VALUE support has so far been limited to X.400(1984)
initiatives, as X.400(1984) has up until now been the dominating
services. However as X.400(1988) implementations have started
appear a VALUE funded study of the X.400(1988) aspects of
and their impact on the R&D community was felt necessary. This
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
period from November 1992 until October 1993. Open reviews of
report have occurred in the RARE Mail and Messaging Work Group
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
on development and deployment of Internet RFC 822 / MIME/ PEM
(pilot) services. However, since the report shows that
X.400(1988) and RFC 822 / MIME / PEM will be developed and
within the European R&D community, such a pilot should
considered. Note: RFC 822 is also known as Internet STD 11.
Circulation of this report is unlimited. Comments on this report
be sent to the e-mail distribution list
RFC 822: wg-msg@rare.
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
The work of this Task Force has been funded by the Commission
European Communities (CEC) VALUE subprogram II, Stichting SURF
SURFnet bv
RARE WG-MSG Task Force 88 [Page 2]
RFC 1616 X.400(88) for European Academics and Research May 1994
Table of
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
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
This document reports the results of study of the X.400(1988)
of messaging and their impact on the R&D community. The study
funded by the CEC under VALUE Subprogram II and has been carried
by a task force on the RARE Mail Working Group. The document
targeted at technical decision makers as well as those who would
activity in this area
The document presents the existing situation as regards
predominate messaging technologies within Europe. These are
within the context of a number of large messaging communities
are using these technologies
- RFC 822,
- X.400(1984),
- Mail-11
- PC LAN
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
- R&D
- Commercial organisations using messaging services
The report states the following facts
- The resources, human or financial, to operate multiple
area messaging services connecting together
organisations are high. As such it is desirable to try
keep to a minimum the number of such services. This
is true for the R&D community but is also highly likely to
valid for the general European industry
- There are two publicly available technological
that can be used by open communities, such as the R&
community and public service providers: the X.400(1984
1988) recommendations and the Internet RFC 822 / MIME /
standards
- There is an established very large global user base
Internet RFC 822 and X.400(1984) messaging services.
services have their own momentum within different parts
the user community, both are still developing and
fast
The report concludes that X.400(1988) will be the preferred
for inter organizational connection for European industry
government and parts of the European R&D community. RFC 822 / MIME /
PEM will be the preferred protocol suite for inter-
connection for the Internet community and, as products are
widely available, it is the preferred protocol for parts of
European R&D community
The goal of European pervasive messaging - incorporating Industry
Government and Academia - would be best accommodated and reached
the establishment of a single messaging service. However taking
above into account, this is not feasible, as X.400(84 and 88) and
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
clear necessity to
- migrate RFC 822 services to a RFC 822 / MIME / PEM service
A MIME based service offers more functionality to the
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
terms of extra functionality, it will become
difficult to meet the needs of research users of
X.400(1984) services unless an X.400(1988) service is
into place
- provide a transparent gateway between X.400(1988) and
822/MIME/PEM. For the European R&D community it is
to have a transparent gateway between the X.400(1988)
and the RFC 822 / MIME / PEM service, thus
connectivity between these two services with a
functionality
Such a gateway is technically feasible and it is an essential part
an unified E-mail service. Without such a standardised gateway
overall E-mail service would deteriorate
The lack of open standards for the PC LAN messaging
discourages their use as 'backbone' messaging technologies
open communities. However the products that these systems deliver
end users ensures that their already large share of the
market will continue to exist for some time. Thus it is
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
developing X.400(1988) and RFC 822/MIME gateways, a strategy to
these systems together via X.400 and RFC 822 should be developed
The report concludes with a set of recommendations, the main
being the establishment of a X.400(1988) European pilot
service for the R&D community. This pilot should include
establishment of a transparent gateway service between X.400(1988)
and RFC 822/MIME. The goal of a European pilot is to ensure
successful deployment of a European wide operational X.400(1988)
service that is pervasive and meets the needs of users. By
together the issues related to the establishment of a
X.400(1988) service, this report acts as a focal point and
for discussion on this topic within the R&D community. In the
a summary of the benefits and problems of each of the above
technologies within the context of achieving a global
service, of which the R&D community is one part, is presented
Further the document identifies issues, strategies
recommendations related to the migration and coexistence of
technologies within the scope of mainly the European R&D
but also in relation to other messaging communities. A cost /
analysis on the establishment of a European wide pilot X.400(1988)
messaging service is also presented. Finally a reading list
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
deployment of RFC 822 / MIME / PEM related (pilot) services, as
are outside of the scope of the Task Force. However, since the
shows that both X.400(1988) and RFC 822 / MIME / PEM will
developed and used within the European R&D community, such a
should also be considered
3. Framework for the
With the belief that user demands for new messaging services such
Multimedia and Secure Messaging would develop, the RARE
(together with other communities; most notably the
Engineering Task Force (IETF)) has over the preceding
experimented in new messaging and related technologies.
and pilots, have been performed in messaging services e.g.,
recommended by CCITT X.400(1988) and Directory Services based
the CCITT X.500(1988) recommendations
The results of such pilots and experiments indicate that it is
opportune to commence a pilot X.400(1988) messaging service for
European R&D community. The major goals of the pilot being,
- establish a large scale European wide pilot
service based on X.400(1988).
- collaborate with and facilitate the commencement of
pilot services within diverse communities; both R&D and non
R&D (e.g., commercial ADMDs and PRMDs, etc.); both
and non-European (e.g., North American , Asian, etc.).
- encourage and assist the development and deployment of
wide variety of commercial and public domain X.400(1988)
messaging products that meet the user's needs, for
X.400(1988) products such as User Agents (UAs),
Stores (MSs), Message Transfer Agents (MTAs) and
between X.400(1988) services and other widespread
services i.e., RFC 822, Mail-11 and proprietary
- prove that such a service and products efficiently meets
existing and expected demands for new messaging services
European R&D users. And as such determine the steps for
European deployment of an operational X.400(1988)
service
- determine the needed steps to facilitate migration for
existing operational R&D X.400(1984) based messaging service
as represented by the R&D MHS service (the former
MHS), RFC 822 / MIME / PEM based messaging services and
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
operational X.400(1988) messaging service. It is self
that during such migrations, transition steps must
included that allow a period of coexistence, at the
possible service level, between X.400(1988), X.400(1984),
822 / MIME and HEPnet / SPAN Mail-11 services
- determine the needed steps that allow proprietary
systems, that are widely deployed within the European R&
community to be integrated at as high as possible
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
discusses advantages and disadvantages, costs and enefits
migration issues for deploying a X.400(1988) service. As such it is
discussion and feasibility paper on the creation of a large
European wide pilot X.400(1988) messaging service for the
R&D community
4. Present situation of European
4.1. Messaging
Electronic messaging within Europe can be viewed as a number
messaging services communities. Three important communities comprise
- Commercial e-mail networks
- Research e-mail networks
- 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)
provided by over 50 service providers which
interconnected using the X.400(1984) protocols. The
between these ADMDs, although not yet 'mesh', can be
as progressing quite rapidly to this optimum goal.
there is still a way to go before ADMDs provide full
connectivity
- PRMDs (or private commercial e-mail service providers)
interconnected to ADMDs and other PRMDs predominantly
the X.400(1984) protocols but also with
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
country. These R&D service providers are operated as either ADMDs
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
SPAN) using proprietary protocols (i.e., DECnet Phase IV and Mail-11)
as their main messaging systems. The DECnet IV based communities
now migrating to DECnet Phase V (OSI connectionless protocol stack),
which provides X.400(1988) (plus X.400(1984)) as a major
system. In general, all these services are totally interconnected
As such it is a statement of fact that there exists within
European R&D community, two parallel interconnected
infrastructures based upon X.400(1984) and RFC 822.
interconnections between the R&D messaging community and the
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
totally interconnected as the R&D messaging community. Finally,
a number of commercial and public organisations there is often
mandatory requirement to use X.400 for messaging interconnections
The usage of PC LAN messaging systems is increasing very
within the academic and commercial communities. In general, PC
messaging services within both communities do not use X.400(1984)
RFC 822 messaging systems but systems based upon
protocols. The PC LAN messaging systems can be considered more
'Islands of Messaging' that gateway to the commercial and R&
messaging services by using X.400(1984) or RFC 822 gateways. PC
messaging systems within commercial organisations connect
commercial service providers also via proprietary protocols. The
LAN messaging services, although probably comprising the
number of users, are in general poorly integrated with the
messaging service (The Dutch, UK and Italian academic
confirm that there appears to be many such 'Islands' of PC
messaging systems within their networks.).
4.2. Requirements for
Experience with existing global e-mail services has proven that
the increased use of messaging, there follows an awareness of
requirements for related services. These requirements can
classified into 'User based Requirements' and 'Service Provider
Requirements' to either support, or exploit, high quality
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
The only thing a user requires is an easy to use, well integrated
user interface to electronic mail. Usually the user does not
what protocol is used. However there are certain
requirements to the functionality that can be identified as
requirements. The main user requirements identified are
- Distribution Lists (DLs
A widely perceived omission from the X.400(1984)
was the lack of support of DLs. Distribution lists allow users
enlist themselves onto electronic mail expander
(distribution lists). A message to such a distribution list
automatically, and without significant delay, be sent on to
whose electronic mail address is on that list. Such a list can
a public list, that is meant for discussions on a
subject, much like a sort of "magazine". However the list can
be a "closed" list, containing only a selected set of people
need to communicate privately, e.g., a project-team
- Multinational language and Multimedia
European users have for many years been frustrated in
inability to use their national character sets when
using messaging systems. The problems within e-mail systems
were causing this character set frustration are at their base
same problem that would get in the way of Multimedia
like
- lack of binary data
- lack of standardised encoding schema'
- definition of multiple body-
The enormous potential of Multimedia systems and
(especially within the commercial community as evidenced by
enormous press publicity and mega-mergers positioning companies
exploit this technology but also within the government
i.e., the U.S.A. Government's 'Information Superhighway
initiative) has acted as a spur to make rapid progress in
the problems in this area
- White pages Directory
A white pages directory service provides a unique but very
and important service; a way to store and find information
people and resources that is analogous to a telephone service'
paper based directory i.e., White Pages. User's E-mail
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 today is not extensively used within the academic environment
However there is a distinct potential within the
community to reduce costs and improve services with EDI.
EDI uses could be
- EDI between
- EDI between universities and
- EDI between universities and lower level
institutions (e.g., student records
- Commercial EDI using the Internet as an infrastructure
The significance of maintaining end to end integrity (
security aspects) of the EDI messages mandates that no
should be used between originator and recipient
- Support of Security
E-mail as it is currently used is far from secure. To allow
serious usage of E-mail security issues need to be addressed
like
- integrity; making sure that the message is
intact, without any changes or additions
- encryption; making sure the message content is
decipherable by the intended recipient
- authentication; making sure that the originator and/
recipient are authenticated
4.2.2. Service provider
The task force believes the following points as being the
significant service provider requirements
- Network
This area is still very new, in terms of offering
protocols, services and products for management. However a
'goal' is to provide for central management functions that
allow providers to offer a better quality of service. There
presently ongoing work within the IETF Working Group MADMAN
define SNMP monitoring and managing of E-mail systems,
and X.500 directory systems. A number of management areas
need to be worked upon include: QOS, Service Level
(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
Dynamic routing from MTA to MTA, relieves the necessity
maintain large routing tables, especially within a large PRMD,
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
of manpower for centrally co-ordinating globally
X.400-to-RFC-822 mapping tables and distributes the
for updating the mapping rules. This should allow mapping rules
change when needed and to be available immediately
- UA capabilities
The use of the directory to register UA capabilities
X.400(1988), X.400(1984) and RFC 822 / MIME / PEM systems is
very desirable benefit for users in terms of speeding
deployment of new messaging services (e.g., Multimedia Messaging).
4.3. Messaging
Due to the problems of gatewaying within a multi-protocol
environment, the great majority of R&D E-mail users are reduced
using only InterPersonal Messaging (IPM) services based upon
exchange of message body parts using CCITT character set IA5 (
ASCII).
Within the R&D community recent work to meet user requirements
non ASCII messaging services - as documented above - has resulted
enhancements to the messaging services based upon RFC 822 protocols
The enhancements provide Multimedia support via the
Internet Mail Extensions (MIME) and the prospect in the very
future of secure messaging via Privacy Enhanced Mail (PEM).
Deployment of the MIME enhanced RFC 822 based services,
distribution of software and the setting up of the
organisational structures, has commenced. The PEM enhancements are
a large scale pilot phase e.g., VALUE PASSWORD project
In the case of X.400(1984) the usage of non ASCII body parts
mostly effected by bilateral agreement between recipient
originator, through use of body part 14. In practice this
the exchange of non ASCII body parts to those cases where
recipient and the originator use the same bilateral agreement or
the originator includes an ASCII message explaining the
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
X.400(1984).
With the above X.400(1984) deficiencies in mind, X.400(1988) has
specified by the CCITT / ISO to meet new user demands. X.400(1988)
provides support for various different body parts, enhanced
features, international character set support capabilities
support of X.500 Directory Services. Due to the
potential of these standards to satisfy user needs for new
services, the R&D community has been experimenting and
X.400(1988) and X.500(1988) services. As there is a
dependency of X.400(1988) messaging upon X.500(1988)
services, the necessary precondition to supply these user demands
a deployed and operational X.500(1988) directory service.
and deployment of the X.500(1988) directory service within the R&
community has been successfully initiated and co-ordinated by
COSINE and the VALUE PARADISE projects
Similarly, secure messaging has been addressed by the VALUE
project and the RARE and IETF communities. Work to solve
related to directory support of X.400(1988) messaging has
pursued within the IETF and RARE. The relevant RARE and IETF
groups (e.g., RARE WG-MSG, IETF MHS-DS, etc.) have also worked
produce any needed enhancements to the base X.400(1988)
X.500(1988) standards. Last but not least it should not
overlooked that X.400(1988), as compared to X.400(1984), provides
comprehensive basis for gatewaying to and from RFC 822 / MIME /
and PC LAN messaging services. To that respect the IETF has
standards for gatewaying Multimedia mail between RFC 822 / MIME /
and X.400(1988). As RFC 822 / MIME / PEM is now being deployed on
Internet, deployment of X.400(1988) services is needed to
multimedia and secure messaging connectivity for the European R&
community
5. Possible solutions for providing globally pervasive
As can be now seen, a correlation of the present situation to
requirements of the user, shows that the current messaging
do not match the needs of users. To try to meet these needs a
of developments within various messaging technology areas
occurring. The following messaging technological areas, due to
present installed user base within the R&D community, are
relevant
- PC LAN E-mail systems such as Lotus cc:Mail, Microsoft
and Novell
- RFC 822 / MIME / PEM E-mail
- X.400(1988) messaging
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
provide new messaging options for the R&D community. The ability
each technological area to provide solutions for user and
provider requirements is summarised within this chapter
5.1. PC LAN E-mail
Currently the usage of PC LAN E-mail systems is mostly for
communication within an organisation. External connections,
present at all, to public service providers or other organisations
mostly through gateways to X.400(1984) or RFC 822. The use of a
LAN E-mail system in terms of an infrastructure for
E-mail systems of different hues is not common within the
community. Recent experience, from amongst others the Dutch
network - SURFnet - [14] and the Norwegian Directorate for
Management - Statskonsult - [18], has shown that a number of
(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
E-mail systems would avoid the usage of gateways and would
alleviate many of these problems.) A summary of those problems
some relevant issues follows
- Interconnecting heterogeneous PC LAN messaging
One very distinct benefit for E-mail users of all hues is
potential to integrate heterogeneous PC LAN messaging systems
a minimum loss of service (e.g., multimedia services)
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
environments (e.g., Apple Macintoshes, DEC, Microsoft, Lotus
etc.). This tendency to gateway PC LAN messaging systems
X.400(1988) will increase and is one of the benefits
X.400(1988) brings to global multiprotocol messaging
- Multimedia and binary data
The benefit of E-mail systems using these PC LAN systems is
the user interfaces are usually well integrated in the
standard working environment. Using a proprietary protocol
systems allow not only text (ASCII) but also binary,
processor, video, audio and other types of files to
transported. To reap the benefits of this multimedia / binary
transfer it would normally require that the same type of
is used by sender and receiver. Transporting these same files
another type of PC LAN E-mail system is not possible through
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
E-mail system's X.400 (or RFC 822) gateways from different
perform acceptably only for text body parts. True
multimedia PC LAN messaging needs gateways to X.400(1988)'
service
- Application Programming
To help solve the problem of portability for Mail
Applications Microsoft, Lotus, Novell, XAPIA and X/OPEN have
working on a number of standards for the Application Interface
mail transport protocols (i.e., Mail Application
Interface - MAPI, Vendor Independent Messaging - VIM, Common
Calls - CMC). These efforts are structured independent of
existing 'Wide-Area' or inter organisational E-mail protocols
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
developers to develop more portable applications plus allow
rich functionality of X.400(1988) to be accessed by
applications thus reducing the need for gatewaying to X.400(1988).
-
As the PC LAN E-mail systems require gateways for connectivity
they pose a problem with regard to encrypted messages.
of secure messages is normally not possible. The gatewaying
secure messages is a general problem of gatewaying from one
system to any other system and is not specific to PC LAN E-
systems
- Directory
To date mostly proprietary directory services have been
that do not match the needs of the users in terms of
controls for data, distributed and decentralised
organisations. X.500 based services promise solutions to
needs. As a result various suppliers have announced support
X.500 directory services for their E-mail products. However
should these interfaces be delayed then support of an
organisational 'White Pages' services requires either
- directory information exchange products (i.e.,
gateways) deployed between a proprietary system and an X.500
directory
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
standards, such as Retix Directory Exchange (DX)
Soft*switch's Directory Synchronisation (DS), and X.500
- duplicated directories i.e., one proprietary and one X.500
need to be operated
It should be stressed that gatewaying mechanisms and products
often problematic due to the lack of an open standard on
proprietary messaging system and or directory system. (As an aside
is thus essential to establish an operational X.500 infrastructure
including E-mail user interfaces that can transparently access
Directory Service, as soon as possible.)
5.2. RFC 822, MIME and PEM
RFC 822 messaging services are widely deployed within the R&
community. There is ongoing work to extend RFC 822 to meet
requirements. Some of these extensions are elaborated upon
this chapter
- Distribution
RFC 822 allows for the usage of DLs. Management of DLs is
(yet) standardised
- RFC 822 multimedia messaging via
With the arrival of MIME, the RFC 822 service has an
protocol standard that addresses Multimedia messaging
comprehensively. In terms of user needs, MIME now allows
body parts to comprise multinational character sets and
data. Multi-body part messages are also supported. One of MIME'
real strengths, in terms of deployment within the existing RFC 822
service, is that it achieves its goals by overlaying its
over the existing RFC 822 service and thus mandating no changes
the in place RFC 822 infrastructure. This greatly simplifies
MIME deployment
- RFC 822 secure messaging via
Just as MIME has brought multimedia messaging to RFC 822 services
Privacy Enhanced Mail (PEM) is bringing secure messaging to
822 services. PEM also has used the same approach as MIME
deploy secure messaging within RFC 822 services; overlay
services over the existing RFC 822 services without
changes to the RFC 822 infrastructure. PEM brings
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
problems with PEM, and X.400(1988) as well, still need to
solved before secure messaging can be considered to be
operational service. These problems are independent of the
messaging protocol (i.e., PEM or X.400(1988)) and deal mainly
distribution of secret keys to the end users. There is very
work going on within the IETF to solve these problems
- MIME and
There are still problems for messages that are simultaneously
multimedia message, as per MIME, and a secure message, as per PEM
A PEM encoded MIME message does not allow gatewaying to
messaging environments and therefore does not allow any of
features inherent within MIME to be exploited along the
path. A MIME message that contains PEM encoded body parts can
gatewayed but the integrity of the entire message is then
guaranteed. This is a real deficiency of both existing
as it is essential that users are able to simultaneously
multimedia and secure messaging. However, once again, the IETF
working very hard on solving these problems and solutions can
expected, although the solution of the gatewaying of PEM
to other E-mail systems is still unclear
- Dynamic and distributed messaging routing via the Domain
System (DNS
RFC 822 messaging benefits greatly by having a dynamic
distributed mechanism to assist in message routing i.e.,
Name System (DNS). With the support of the DNS, RFC 822 MTAs
able to directly route to other RFC 822 MTAs and thus
messages with a minimum of delay. In practice mail often
traverses multiple RFC 822 MTAs for a number of reasons e.g.,
Hubs provided for users who turn their machine off when they
home, Firewall Hubs for security reasons, etc. However it
commonly accepted that between RFC 822 mail hubs the delivery
messages is very fast. Typically resolution of routing
occurs in less than one minute and very often within seconds.
general the DNS service is a very valuable service that
well in practice
- Support for Character
Together with the MIME specification for content types,
extension for RFC 822 headers was defined that allows for usage
multiple character sets in names, subject etc. in RFC 822
[9]. This allows (European) users to use their preferred
set to support their language not only in the contents of
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
It is clear that to provide a seamless service to all
regardless of whether they are using RFC 822 or X.400 services,
widely available set of well run and standardised RFC 822 to X.400
gateways must be in place. For InterPersonal Messaging (IPM)
on US ASCII there are already a large number of such
(i.e., X.400-to-RFC 822) gateways deployed. To ensure
gatewaying between MIME and X.400 multimedia users, these
text based gateways must be either upgraded to or replaced
multimedia messaging gateways. A number of proposed
standards to solve these problems, for both X.400(1984)
X.400(1988) and generated within the MIMEMHS work group of
IETF, have been completed [4].
- Access to fax, teletex, telex or physical
For the moment, there is no standardised way for RFC 822 users
access gateways to the above services except by indirect access
X.400(1988) systems (i.e., concatenated gateways of RFC 822
X.400(1988) and then onwards to the appropriate X.400(1988)
Unit). Although even this indirect method would require
further work on standardising mappings between RFC 822
and X.400(1992)'s X.121 addresses. As well some experiments
the RFC 822 world are occurring on routing fax messages
- Operational
Generally, RFC 822 messaging services are delivered on a '
effort' basis and thus service level agreements
stringent response times to operational problems or
delivery times for messages are difficult to agree. This
might be a result of the distribution and delegation of
to organisations updating the RFC 822 MTA's routing
i.e., DNS. As a result it makes it hard to reach a 'one
shopping' agreement for RFC 822 messaging services
-
The RFC 822 service provides a minimum amount of base
support for messaging users. It could be argued that the RFC 822
protocol is simplified by this choice and thus software
implements the standard need be smaller in size and easier
build. However some features e.g., delivery &
notifications and UA capabilities registration, would be
accepted as being desirable from a user standpoint and
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
relating to reliability could be minimised by technology that
a standardised support for positive and negative notifications
messages. RFC 822, as compared to X.400, technology does not
support positive notifications (although there is work
within the IETF to extend RFC 822 to support
notifications). However within RFC 821 transport system (i.e.,
SMTP) there are standardised negative notifications that
well. Alternatively X.400 technology, deployed over TCP/IP (
STD 35, RFC 1006), may help to address the lack of
service quality - notification support - when using E-mail
the Internet
- Portability of RFC 822
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
RFC 822 users as it allows them to change RFC 822 UAs (e.g.,
upgrading to MIME RFC 822 UAs) whilst not compromising
converting their existing archived mail, which may comprise 1000
of archived messages
- System support for RFC 822
Normally, RFC 822 MTAs and UAs come pre-installed on
workstations. As a result, users are spared the effort
installing RFC 822 MTA software. If for some reason, a user
mail administrator should wish to install a different MTA or UA
the pre-installed system, there exists a large number of
available (i.e., via widespread distribution amongst many FTP
other information servers) public domain RFC 822 MTAs and UAs
Both of the above points encourages the spread and eases
installation of software for the RFC 822 messaging service and
many ways explains the size and importance of the installed
of RFC 822 systems. To illustrate the extent of RFC 822 /
products, a non-comprehensive list of available MIME enhanced
822 products follows; ELM 2.4, MH 6.8, Sun Mailtool, HP
Desktop, Lotus cc:Mail (unconfirmed), Zcode Zmail,
Super-TCP for Windows, PMDF (VAX VMS), Pine, C-Client (
routines), Metamail (viewer only), Andrew-MIME gateway
- UA capability
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
X.400(1988). A description of the most important features of X.400 -
1984 and 1988 - follows
-
X.400(1984) provides four notifications - positive and
delivery notifications and positive and negative
notifications. These notifications allow users to
successful message delivery or that the message was read.
delivery notifications are also used by service operators in
fault escalation procedures
- Binary Data
X.400(1984) allows binary data transfer to be transported
the necessity of character encoding. The ability to transfer
of whatever type is a valuable end user service. As well the
of any necessary character encoding allows users to utilise
received data without needing any character decoding software
- Multiple Body
The ability to send multiple body parts within one message
the user the ability to send multiple logical components
one message. This is a natural mechanism for users as it
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
The features of X.400 are very rich. This provides benefits
users as vendors are able to provide applications that can
these extensive features in an interoperable manner due to
standardisation of the features within X.400.
- Clear messaging
X.400(1984), as one of its most wide reaching achievements,
popularised within the market a consistent and clear model
describe message handling systems. The decomposition of a
handling system into UAs, MSs, MTAs, MTS - ADMDs and PRMDs
Access Units / Gateways has proved to be an extremely useful
for users and vendors to understand and communicate
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
X.400 has embraced the concept that there are different
lower layer networks. This concept even allows multiple
networks of the same technology to be supported. X.400 allows
messaging service to fully function even though the
network is varying. In the real world of a non-uniform
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
including the ability for DL owners to control access to
lists and to control the destination of non delivery reports.
current endemic use of DLs in the R&D community makes this
fundamental requirement for any service. X.400(1988) uses X.500
provide a standardised support for DLs, although there have
some needed standardised enhancements relating to the
defined DLs by the IETF MHS-DS work group. The provision
powerful nesting capabilities plus management mechanisms for
owners within X.400(1988) DLs are features providing
benefits for users and DL managers. There is already '
code', via the COSINE Explode project which is implementing
MHS-DS based enhancements. The project builds upon
gained within a number of networks e.g., JNT and provides
- implementation of MHS-DS enhancements related to
X.400(1988)
- 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
and PCs enabling messages to be held for their recipient,
the problems of non-continuous availability of such UAs.
message store allows mobile workers, small offices and
schools to become active messaging users in a cost
manner. The message store provides powerful selection
allowing the user to select messages to be transferred between
store and the workstation. This facility is not catered
adequately by the P3 protocol of X.400(1984) and provides a
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
Support for use of Directory Names in MHS will allow a
from use of O/R addresses to Directory Names when X.500
Directories become widespread, thus removing the need for users
know about MHS topological addressing components
The ability for X.400(1988) messages to contain directory
instead of the O/R addresses is a powerful feature for users as
frees them of the necessity to insert O/R addresses
routing information but allows them to insert the more
directory names. However, the management of the large amounts
distributed data contained within the directory is problematic
that it involves a number of organisational issues and not
software issues. A number of X.400(1988) UAs which allow users
insert directory names instead of O/R addresses have already
developed
- Support for
Through the definition of Pedi, as defined in X.435, X.400(1988)
offers integrated support for EDI messaging. The CEC TEDIS
has mandated X.400 as the main carrier for EDI, and
how EDI transactions are inserted into X.400 messages (i.e.,
and P2). This provides a strong incentive to provide
X.400(1988) services to users and applications thus
commercial EDI traffic to migrate to X.400(1988).
- Secure
The provision of secure messaging services
authentication, confidentiality, integrity and non-repudiation
well as secure access between MHS components are
benefits for the R&D community. The base standards are
for security, however organisational and software issues
still to be solved. Organisational issues of globally scaling
distribution of secret keys is still unsolved. Software issues
how end users will be able to comfortably and securely
secret keys of length 512 -> 1024 bits into security software
to be solved
-
The definition of a number of additional body parts plus
ability to define new body parts (e.g., Word Processor formats
Excel documents, etc.) provides the basis for multimedia
over X.400(1988). As well, the newly defined General Text
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
messaging. To achieve multimedia document exchange, there is
further text exchange standard such as ODIF, Hytime, etc., needed
- Character set support for extended
A highly desirable potential benefit for European R&D users
provided by the extended character set support(i.e., T.61)
addresses. Nearly all European languages, except for Greek
Cyrillic, are supported by the T.61 teletex encoding.
extensions to X.400 for support of extended character sets
been defined by the RARE WG on character sets and RARE WG
messaging [15].
- Physical Delivery
This standardised method for a message to be delivered on
physical medium, such as paper, through the normal postal
is useful when trying to reach a very wide number of (non
electronically reachable) recipients. In effect this
provides an ability to 'go the last mile' and communicate
users previously not easily reachable e.g., farmers, etc
- General Extension
One of the major assets of X.400(1988) is the extension mechanism
This is used to carry most of the extensions defined in
standards, but its principal benefit will be in reducing
trauma of transitions to future versions of the standards
Provided that implementations of the X.400(1988) standards do
try to place restrictions on the values that may be present,
future extension will be relayed by these implementations when
extension is not critical, thus providing a painless migration
new versions (1992 and beyond) of the standards
- UA Capability
With the extra functionality available to X.400(1988
especially 1992) UAs (i.e., extra non-IA5 body parts,
messaging, etc.) it is expected that the demand to register
capabilities will increase. In that respect X.400(1988)'s
to query X.500, where such capabilities would be stored, is
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
The piloting of X.500 to support MTA routing within the R&
community has already commenced, on a small experimental scale
via the Longbud project co-ordinated by the IETF MHS-DS
group. Some concrete benefits promised by X.500 based routing are
- routing based upon content types, security, transport
and other criteria allow optimum routing paths to
destination MTA to be chosen. (There is presently no
similar capability within the DNS).
- allowing the routing information to be inserted and
in a distributed manner reduces (if not eliminates)
necessity of central distribution of static routing tables
The consequent reduction in manpower to co-ordinate
routing plus the increase in scalability of the
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
area messaging services connecting together
organisations are high. As such it is desirable to try
keep to a minimum the number of such services. This
is true for the R&D community but is also highly likely to
valid for the general European industry
- There are two publicly available technological
that can be used by open communities, such as the R&
community and public service providers: the X.400(1984
1988) recommendations and the Internet RFC 822 / MIME /
standards
- There is an established very large global user base
Internet RFC 822 and X.400(1984) messaging services.
services have their own momentum within different parts
the user community, both are still developing and
fast
From the above discussion, it is clear that the
services that have to be supported within these open communities,
especially within the R&D community, are RFC 822 / MIME / PEM
X.400(1984) and X.400(1988). X.400(1988) will be the
protocol for inter-organisational connection for European
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
are already widely available, it is the preferred protocol for
of the European R&D community
The goal of European pervasive messaging - incorporating Industry
Government and Academia - would be best accommodated and reached
the establishment of a single messaging service. However taking
above into account, this is not feasible, as X.400 and RFC 822
services will be around for a long time to come. To increase
functionality of Wide Area E-mail services there is a clear
to
- migrate RFC 822 services to a RFC 822 / MIME / PEM service
A MIME based service offers more functionality to the
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
terms of extra functionality, it will become
difficult to meet the needs of research users of
X.400(1984) services unless an X.400(1988) service is
into place
- provide a transparent gateway between X.400(1988) and
822/MIME/PEM. For the European R&D community it is
to have a transparent gateway between the X.400(1988)
and the RFC 822 / MIME / PEM service, thus
connectivity between these two services with a
functionality
Such a gateway is technically feasible and it is an essential part
an unified E-mail service. Without such a standardised gateway
overall E-mail service would deteriorate
The lack of open standards for the PC LAN messaging
discourages their use as 'backbone' messaging technologies
open communities. However the products that these systems deliver
end users ensures that their already large share of the
market will continue to exist for some time. Thus it is
essential that strategies that allow these systems to be 'seamlessly
