Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-sdd!apollo!marc
From: marc@apollo.HP.COM (Marc Gibian)
Newsgroups: comp.protocols.iso
Subject: Re: Questions about X.400
Message-ID: <46f509bd.20b6d@apollo.HP.COM>
Date: 20 Nov 89 22:57:00 GMT
References: <1987@xyzzy.UUCP> <10100002@WL9.Prime.COM> <8061@ditmela.oz> <3215@convex.UUCP>
Sender: root@apollo.HP.COM
Reply-To: marc@apollo.HP.COM (Marc Gibian)
Organization: Hewlett-Packard Company, Apollo Division; Chelmsford, MA
Lines: 61

In article <3215@convex.UUCP> thurlow@convex.com (Robert Thurlow) writes:
>smart@ditmela.oz (Robert Smart) writes:
>
>>In article <10100002@WL9.Prime.COM> MYNARD@WL9.Prime.COM writes:
>>>
>>> X.400 mail really does work.
>>>
>>There seems to be a really big hole in X.400 to my mind, and that is
>>administration. For TCP/IP I know how to get an IP address, how to get
>>a domain name, how to get the name server records set up so that I
>>can be reached.
>
>You mean you know how (on BSD Unix) to set up the /etc/hosts file?
>Which you have to do by hand?  Or am I missing something?  What you
>are talking about sounds like criticisms about the implementations,
>not the standards.  If you meant, 'we need more usable, fully rounded 
>X.400 implementations', I entirely agree with you.  That will happen
>as more people gain experience with the existing implementations, and
>bump their heads against limitations.  Configuration and management
>are tough issues, but I don't consider them to be a bigger problem for
>X.400 than a lot of existing protocols.  (For example, I *hate* setting
>up the UUCP database!).
>

There are a number of ways of viewing the x.400 standard.  Most x.400
products available today treat it simply as an email interchange
protocol, and use it to let their existing email products connect to
other x.400 products.  This interpretation is the least challenging,
as it simply extends connectivity while preserving the current functionality
in the email products.

The other approach to x.400 is to view it as defining not only a protocol
for interchange of mail, but also a very rich email environment that is
not supported by any non-x.400 based products.  This interpretation
results in enourmous increase in the functionality delivered to users
by their email system, as well as supporting connectivity to other
x.400 products.

(I can not resist - note that HP's openmail and x.400 products together
implement the latter of these while HP's x.400 product on its own implements
the former.  Both of these are announced products.)

I believe it is a shame that most x.400 products available today are
based on the former of these interpretations.  Some is because it is
easier to release a new version of the same old user interface... no
need to spend time on engineering the human factors, no need to come
to terms with the richness of function defined by x.400.

Finally, x.400 is a relatively young standard, especially if judged by
the number of products built supporting it.  As such, the 1988 version
of the standard is MUCH stronger, yet most if not all currently available
products are of the 1984 (red book) version of the standard.  Some of 
these products include a few of the 1988 features.  As I user I can not
wait for some good "native" x.400 1988 products to become available as
the functionality in this version of the standard is really exciting!

Marc S. Gibian
Project Engineer, email project: Apollo Systems Division of HP
Internet: marc@apollo.hp.COM
NETel:    Apollo: 508-256-6600 x2077
(Copyright 1989 by author. All rights reserved.  Free redistribution allowed.)