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.
- 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.
- 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)
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.
- 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 RFC822 / MIME / PEM
standards.
- There is an established very large global user base of
Internet RFC822 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 RFC822 / 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. RFC822 /
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 RFC822 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 RFC822 services to a RFC822 / MIME / PEM service.
A MIME based service offers more functionality to the user
than a plain RFC822 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 RFC822 / 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 RFC822/MIME gateways, a strategy to link
these systems together via X.400(1988) and RFC822/MIME should be
developed.
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: RFC822, 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. RFC822, MIME and PEM services
A migration from RFC822 / 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 RFC822 users.
An understanding of the issues involved in migrating from RFC822 to
X.400(1988) messaging services is essential before any rational
decisions on migration can occur. Certainly one, if not the main,
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 RFC822 messaging services
are a 'moving target'.
- Ease of transition as perceived by an RFC822 user mandates
that the user's existing mail folders are converted into the
new mail product's folder system flawlessly.
- The RFC822'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 RFC822).
- 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 RFC822
style addresses into the X.400(1988) UA and are provided with
high performance X.400-to-RFC822 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 RFC822 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 RFC822 / MIME products will
be the yardstick that an RFC822 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 RFC822 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 RFC822 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 RFC822 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.
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.
- 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), RFC822 (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
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.
*Benefits*
Below is a list of non-technically oriented benefits and the features
of X.400(1988) that enable these benefits to occur. The benefit of,
- efficient and innovative communication within Europe is
assisted by establishing an X.400(1988) messaging service
that integrates European industry, government and academia;
- an increase in business efficiency by the use of EDI (for
example automatic processing of business forms, exchange of
business contracts, etc.) is enhanced by the security aspects
of X.400(1988) i.e., non-repudiation, authentication,
confidentiality, integrity plus secure access between MHS
components.
- allowing European users to communicate in their native
European languages is brought about by the GeneralText body
part of X.400(1988).
- remote users and Small and Medium size Enterprises(SME)
using e-mail for electronic commerce is encouraged by
reducing the entry level costs for use of e-mail. An SME's
use of Remote UAs in conjunction with a service provider's MS
-instead of purchasing their own MTA - is accommodated by
X.400(1988).
- providing global messaging for all e-mail users, but
recognising the existing market realities of heterogeneous e-
mail systems, would be enhanced by the establishment of
gateways to X.400(1988).
- being able to recover costs by charging and accounting for
messaging services back to users - this is especially
important for commercial service providers - is brought about
by the message auditing capabilities of X.400(1988).
- communication with users that have no access to E-mail (for
example if such users are defined within Distribution Lists)
is enhanced by X.400(1988)'s support for gateways to physical
delivery, fax, telex, teletex, etc.
- building upon the existing X.400(1984) infrastructure (i.e.,
reduction of establishment costs) is brought about by
migrating the X.400(1984) infrastructure to X.400(1988).
- a reduction in manpower (and thus costs) to manage a global
messaging service is brought about by the messaging service's
ability to utilise the global distributed directory for
management information.
- the messaging infrastructure to meet new user requirements
is enhanced by the support for General Extensible Mechanism.
- making E-mail more user friendly is brought about by a
messaging service that allows the use of the more natural
directory names in E-mail addresses.
- increased effectiveness of messaging by the use of DLs is
brought about by X.400(1988)'s support of powerful nesting
capabilities and management for DLs.
- an increase in global message delivery performance and
reliability is enhanced by the ability of X.400(1988) to use
X.500 for MTA routing.
- more messages being successfully delivered to mobile or
transient users is enhanced by the provision of the Message
Store.
- multimedia use is enhanced by the ability to define new body
parts and to support multiple types of binary data such as
audio and video.
- establishing optimum and seamless conversion of messages
based upon the capabilities of a user is brought about by the
ability of X.400(1988) to act upon UA capabilities.
*Costs*
The generic costs to establish an X.400(1988) pilot service can be
broken down into:
- a cost per backbone of RELAY MTAs (as used by the European
research community - the former Cosine MHS service),
- a cost per service provider,
- a cost per organisation,
- a cost per user and
- a cost per user MTA for migrating to X.400(1988).
To bring about the benefits, mentioned above, certain costs will be
incurred and they are summarised below:
- Cost per backbone of RELAY MTAs (as used by the European
research community - the former Cosine MHS service)
- The equipment costs of migrating backbone RELAY MTAs.
- The establishment of some sort of organisational /
project group to oversee a backbone RELAY MTA pilot.
As most of the RELAY MTAs are already X.400(1988) capable, there
is already a MHS Co-ordination service in place that could be used
for this function and the number of backbone RELAY MTAs is less
than 100 in number the cost for migrating the RELAY MTA backbone
is considered relatively low.
- Cost per service provider
- If the RELAY MTA backbone (formerly Cosine MHS) is
migrated towards X.400(1988), then the remaining cost
for a service provider for migrating the infrastructure
towards X.400(1988) is relatively low.
- The operational costs for organisational issues, for
example dealing with OID registrations, is low if
national R&D service providers act as a clearinghouse
for their own national R&D institutions e.g.,
Universities.
- Cost per organisation, end user and MTA
- The operational costs of migrating end users and their
MTAs in management domains to X.400(1988) are higher
than the costs involved with migrating the
infrastructure. This is due to the order of at least 10
to 100 times more MTAs, as compared to the service
providers, that would be involved with a migration to
X.400(1988). As the infrastructure needs to migrate
first, the costs for the end user MTAs can be reduced
by profiting from the migration experience of the
service providers.
- The education and training costs for users and system
managers are significant, due to the amount of end
users and end user MTAs. Any marginal cost savings per
user which can be made, e.g., by deployment of automated
tools, should be considered due to the large overall
savings that accrue.
- The costs of any potential disruption of the end user's
messaging service are high - due to the huge numbers of
end users involved - and as such only a very well
managed, phased and planned migration should be
considered.
- Software costs
- The costs for software development are outside the
scope of this report. However it is clear that cost
needs to be incurred in order to provide software that
is easy to install and use. As a result of the work of
the task force a list of possibly needed components and
likely changes to existing components can be proposed,
Modifications, but not new developments, to
software for:
- X.400(1988) MTAs, X.400(1988) UAs, DSAs,
DUAs and MSs.
New software developments for:
- MIME to MHS Gateways, X.400(1988) network
management, mailbox conversion, PC LAN
directory synchronisation, PC LAN gateways
and UA capability registration.
- The distribution costs for any new software (for the
European R&D community) are low if usual academic
distribution methods - FTP servers, E-mail Based
servers, Gopher, World Wide Web and Archie - are used.
*Summary*
Migration towards a X.400(1988) service needs to evolve from the
inside (the messaging backbone) outward (to the end user MTAs and end
users themselves). Due to the numbers involved both the costs and the
benefits associated with the migration increase as the migration
evolves towards the end users.
The benefits of migrating to a X.400(1988) service are a feature rich
well defined open standard with high functionality , scalability, use
of directory, multimedia and secure messaging capability. The costs
for migrating a RELAY MTA backbone can be considered relatively low
whilst the migration of end user MTAs and the migration of the end
users themselves are relatively high. These costs should of course be
balanced against the cost of a disrupted service that one might get
if no migration occurs at all and the current service (e.g.,
X.400(1984)) reaches the limits of its scalability and/or
functionality.
It is important to realise that if end users themselves do not
experience direct feedback of the benefits from X.400(1988), this may
make the organisational motivation needed to effect such a migration
difficult to achieve. In effect, the establishment of a pilot
X.400(1988) service is and should be driven by the requirements of
end users and thus achieving end user benefits - as listed above -
must be given a higher priority within a X.400(1988) service than
solely the extra service provider benefits.
8. Main Recommendations
The RARE WG-MSG Task Force on 'The Establishment of an X.400(1988)
Pan European Pilot Messaging Service' has identified a number of high
level recommendations for establishing such a
service. The main high level recommendations are listed within this
chapter. A more detailed elaboration of these main recommendations is
given in Appendix A. Appendix A is provided for policy makers wishing
more background on the main recommendations. As well, a list of very
detailed guidelines, plus some issues requiring further
investigation, is given in Appendix B. Appendix B will be especially
useful for personnel seeking detailed technical guidelines which are
consistent with the main high level recommendations.
*Recommendations*
- Establish a X.400(1988) pilot service encompassing European
Commercial, Government and Academic bodies. Such a pilot
service to be co-ordinated by using an industry forum where
all parties could meet. The use of an existing forum, where
user organisations are well represented, is desirable if
commercial end users organisation's requirements are to be
met. The forum should also be open to non-European
participants.
- X.400(1988) end user services should be provided as well as
a X.400(1988) backbone RELAY MTA service within a X.400(1988)
pilot service. The end user services should be given a high
priority.
- Help an already emerging market place in X.400(1988)
products to prosper by ensuring that a suitable supply of
high quality X.400(1988) public domain software is available.
The Internet has proven, that public domain software, free of
any commercial restrictions, is further rapidly developed, by
Small and Medium Size Enterprises (SMEs), into derivative
products suitable for the commercial market.
- Any pilot service should be well co-ordinated and result
driven but utilise a distributed market oriented approach. It
is considered very difficult to organise and plan such a
pilot under the assumption of a single centrally funded body
i.e., driven from the 'top'. A more 'market driven' or
distributed organisation is considered feasible, and likely
to succeed, if all the market 'players' are fully involved
i.e., a 'bottom' up approach.
- For the academic community - and ever more for the
commercial community - there is a business need to ensure near
total and 'perfect' integration with the existing and also
evolving RFC822 based services.
- For the academic community a rapid migration of the existing
X.400(1984) backbone RELAY MTAs, used within the European R&D
X.400(1984) service, - formerly the COSINE MHS service - is
considered urgent. This migration will provide a 'bootstrap'
path for academic organisations to internationally pilot
X.400(1988) services. Such end user piloting is not
considered feasible if X.400(1984) backbone RELAY MTAs are
used for an X.400(1988) service (see Reference [17] for
technical details).
The report does not include any recommendations on development and
deployment of RFC822 / MIME / PEM related (pilot) services, as these
are outside of the scope of the Task Force. However, since both
X.400(1988) and RFC822 / MIME / PEM will be developed and used
within the European R&D community, such a pilot should also be
considered.
9. Security Considerations
Security issues are not discussed in this memo.
10. Reading List and Bibliography
This section contains a list of relevant reference documents that can
be used for further reading.
[1] Kille;, S., "Mapping between X.400(1988) / ISO 10021
and RFC822", RFC1327/RTR 2, University College
London, May 1992.
[2] Kille, S., "X.400 1988 to 1984 downgrading",
RFC1328/RTR 3, University College London, May 1992.
[3] Adie, C., "A Survey on Multimedia Projects, Products
and Standards", RTR 5, Edinburgh University Computing
Centre, January 1993.
[4] Alvestrand, H., and S. Thompson, "Equivalences between
1988 X.400 and RFC822 Message Bodies", RFC1494,
SINTEF DELAB, Soft*Switch Inc., August 1993.
[5] Alvestrand, H., Kille, S., Miles, R., Rose, M.,
and S. Thompson, "Mapping between X.400 and RFC822
Message Bodies", RFC1495, SINTEF DELAB, ISODE
Consortium, Soft*Switch, Inc., Dover Beach
Consulting, Inc., Soft*Switch, Inc., August 1993.
[6] Alvestrand, H., Romaguera, J., and K. Jordan,
"Rules for downgrading messages from X.400/88 to
X.400/84 when MIME content-types are present in the
messages", RFC1496, SINTEF DELAB, NetConsult AG,
Control Data Systems, Inc., August 1993.
[7] IETF MHS-DS Working Group, Works in Progress.
[8] Borenstein, N., and N. Freed, "MIME (Multipurpose
Internet Mail Extensions) Part One: Mechanisms for
Specifying and Describing the Format of Internet
Message Bodies", RFC1521, Bellcore, Innosoft,
September 1993.
[9] Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Two: Message Header Extensions for
Non-ASCII Text", RFC1522, University of Tennessee,
September 1993.
[10] Kaliski, B., "Privacy Enhancement for Internet
Electronic Mail: Part IV: Key Certification and
Related Services", RFC1424, RSA Laboratories,
February 1993.
[11] Balenson, D., "Privacy Enhancement for Internet
Electronic Mail: Part III: Algorithms, Modes, and
Identifiers", RFC1423, TIS, February 1993.
[12] Kent, S., "Privacy Enhancement for Internet
Electronic Mail: Part II: Certificate Based Key
Management", RFC1422, BBN, February 1993.
[13] Linn, J., "Privacy Enhancement for Internet
Electronic Mail: Part I: Message Encryption and
Authentication Procedures", RFC1421, IAB IRTF PSRG,
IETF PEM WG, February 1993.
[14] Jurg, P., and E. Huizer, "The SURFnet electronic mail
project", SURFnet, EH/PJ932307, July 1993.
[15] Alvestrand, H., "X.400 Use of Extended Character
Sets", RFC1502/RTR 7, SINTEF DELAB, August 1993.
[16] Manros, C.-U., "The X.400 Blue Book Companion", ISBN
1 871802 00 8, Technology Appraisals Ltd, 1989.
[17] Houttuin, J., and J. Craigie, "Migrating from
X.400(1984) to X.400(1988)", RFC1615/RTR 9,
RARE, JNT, May 1994.
[18] Nagelhus, I. et al., "Survey of E-mail systems with
X.400 capability".
[19] "A White Paper on X.400(1988)", EMA Report.
[20] IAB, IESG, "The Internet Standards Process --
Revision 2", RFC1602, March 1994.
11. Terminology
ADMD Administration Management Domain
ASCII American Standard Code for Information Exchange
ASN.1 Abstract Syntax Notation One
AU Access Unit
CCITT Comite Consultatif International de Telegraphique et
Telephonique
CEN Comite Europeen de Normalisation
CENELEC Comite Europeen de Normalisation Electrotechnique
CEPT Conference Europeene des Postes et Telecommunications
CONS Connection Oriented Network Service
COSINE Co-operation for OSI networking in Europe
DL Distribution List
DIS Draft International Standard
EMA Electronic Messaging Association
EN European Norm
ENV Draft EN, European functional standard
IEC International Electrotechnical Commission
IETF Internet Engineering Task Force [20]
IPM Inter-Personal Message
IPMS Inter-Personal Messaging Service
IPN Inter-Personal Notification
ISO International Organisation for Standardisation
JNT Joint Network Team (UK)
JTC Joint Technical Committee (ISO/IEC)
MD Management Domain (either an ADMD or a PRMD)
MHS Message Handling System
MHS-DS Message Handling Systems use of Directory Service
Working Group from the IETF
MIME Multi-purpose Internet Mail Extensions (extensions to
RFC822) [6]
MOTIS Message-Oriented Text Interchange Systems
MTA Message Transfer Agent
MTL Message Transfer Layer
MTS Message Transfer System
NBS National Bureau of Standardization
OSI Open Systems Interconnection
PEM Privacy Enhanced Mail [10]
PRMD Private Management Domain
RARE Reseaux Associes pour la Recherche Europeenne
RFCRequest For Comments (series of Internet publications)
RFC822 RFCdescribing Internet Message format for Electronic
RTR RARE Technical Report (series of RARE publications)
RTS Reliable Transfer Service
WG-MSG RARE Working Group on Mail and Messaging
Appendix A - Elaboration on the main recommendations
The main recommendations of the report are elaborated upon in more
detail within this appendix.
- In order to provide a globally pervasive messaging service,
it is recommended to establish a well operated Pan-European
X.400(1988) pilot backbone comprising MTAs and MSs,
connecting partners within Industry, Commercial Service
Providers, Academia and Public Bodies (CEC, National
Governments, etc.). The pilot should be open to global
participation.
- In order to maintain the widest connectivity with the
highest possible functionality, gateways should be installed
that gateway between X.400(1988) and RFC822/MIME. These
gateways should follow the specifications of RFC1327 [1] and
RFC1494 et al. [4]. Experience with these gateways should be
fed back into the appropriate RARE and IETF Working Groups to
improve the standards.
- In order that the 'business needs' of non-R&D organisations
can be inserted at an early stage into the goals of the pilot
and ensuring that the success of the pilot in meeting these
goals can be measured and disseminated i.e., to encourage the
active participation of non-R&D organisations within the
pilot, it is recommended that an open forum comprising
industry, service providers, public bodies and academia
should be used. Preferably an existing forum where end users
are heavily involved is desirable.
- In order for meaningful co-operation between bodies affected
by the pilot to occur and thus hopefully reducing unnecessary
duplications, it is recommended that there are close liaisons
and contacts between at least the IETF, RARE, EARN, EUnet,
RIPE, Y-NET, EEMA, EMA, EWOS, OIW, CEN/CENELEC, ISO, CCITT,
CEC and European governmental bodies and those involved
within the pilot. The suggested mechanism for a meaningful
liaison is that enough participants of the above
organisations attend the common forum mentioned above. It is
also suggested that as much as possible e-mail distribution
lists be used to communicate between forum participants.
- In order that the pilot have measurable results, it is
recommended that the pilot shall be implemented in phases. It
is considered that at least two phases are needed:
- phase 1 - initial short start up phase with a small
number of participants. The result of this phase is
that any needed procedures, co-ordination mechanisms,
etc. are put into place for the large scale piloting of
phase 2.
- phase 2 - phase with a wide Pan-European participation.
The result of this phase should be a proof of scaling
of the pilot X.400(1988) service i.e., the goals of the
pilot as defined in Chapter 1 are met. It is expected
that upon successful completion of this phase a natural
evolution to a global deployment of a X.400(1988)
service will have started.
- In order to rapidly complete phase 1 of the pilot and that
the pilot is at least Pan-European in scope, it is
recommended that; a number of R&D service providers, one each
from several European countries; at least 2 North American
R&D service providers; at least 1 Japanese R&D service
provider and a small number of commercial service providers
and commercial organisations are actively involved in phase
1.
- In order to stimulate the creation of an economically viable
market place for X.400(1988) products (i.e., MTAs, UAs, etc.)
(i.e., users are willing to purchase such products), it is
recommended that a suitable minimum number of new software
implementations and or modifications to existing software
implementations be funded. The resulting software to be
inserted into the Public Domain free of any financial
restrictions on further commercial exploitation. By using
this mechanism, Small and Medium Size Enterprises (SMEs) will
be encouraged to commercially exploit such products.
- Due to the strong influence of the R&D community within the
pilot plus the desire to produce standardised products
quickly and pragmatically, it is recommended that any
standards proposed within the scope of an X.400(1988) pilot
(for example standards re: character sets and body parts
gatewayed to and from X.400(1988) and RFC822 / MIME) are
conformant to and candidates for Internet standardisation. As
a concrete example of the standardisation process, this means
that at least two independent software implementations, for
each product category, (of which one product preferably in
the Public Domain) must be proven as interworking to a
proposed standard before the proposed standard can be
elevated to draft standard [20].
- To ensure that there is a market driven demand for
X.400(1988) products within the commercial market place, it
is recommended that the maximum number of Public Domain
implementations that are funded, by any one public funding
organisation, is two. It is desirable that at least one other
product, preferably commercially based and not within the
Public Domain, is produced.
- In order that any necessary information required for the
effective operation of the X.400(1988) pilot, including not
least OID assignments, mapping rules, information about
interconnection partners, naming authority information be
made widely available, it is recommended that an
electronically accessible information base be established.
- In order that any necessary organisational issues needed for
a deployment of an X.400(1988) service have a body in place
to deal with this issue, it is recommended that the pilot
either identify and list which bodies are responsible for
which issues or else actively ensure that a suitable body is
being put in place.
Appendix B - A number of detailed guidelines.
The Task Force has the following detailed guidelines:
*Product and operational service guidelines*
- To ensure that there is no degradation of X.400(1988)