Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!ucbcad!ucbvax!hplabs!hplabsz!taylor
From: taylor@hplabsz.HPL.HP.COM (Dave Taylor)
Newsgroups: comp.mail.misc
Subject: Re: X.400 ean mail system
Message-ID: <719@hplabsz.HPL.HP.COM>
Date: Tue, 25-Aug-87 16:09:37 EDT
Article-I.D.: hplabsz.719
Posted: Tue Aug 25 16:09:37 1987
Date-Received: Thu, 27-Aug-87 03:51:24 EDT
References: <186@bernina.UUCP>
Reply-To: taylor@hplabsz.UUCP (Dave Taylor)
Organization: Hewlett-Packard Laboratories
Lines: 148
Keywords: ean, mail, x.400

Mitchell Wyle writes an interesting article about why he doesn't use
the EAN X.400 mail system from the University of British Columbia in
this group.  I'd like to discuss some of the points he raises a bit
further...

First off, I think it is important to note that X.400 and the related
ISO/CCITT standards are indeed an up and coming standard for the 
interchange of electronic mail in the world (certainly in Europe).  In
fact sources from both DEC, HP, and some third party market analysts
tell me that it is almost impossible to sell any large computer boxes
to firms there unless they have available an X.400 mail system...

In an environment of that nature, it is somewhat ironic to read that
a sophisticated, knowledgeable Unix user like Mitchell decides to use
something as simple as the Berkeley Mail system instead of the EAN
package.  My first curious question is how long will Mitchell be able
to use Berkeley Mail to send and receive mail there in Switzerland?  I
can imagine in the very near future his machine suddenly not speaking
the "RFC-822 style" mail that Berkeley Mail expects and generates.  Or,
as an alternative, having the extra overhead of a gateway/translator
for each message sent, even those local to his machine.  

Note that I haven't made any comments about the relative merits of the
X.400 protocol suite/standard nor of the RFC-822 (and related documents)
standard either.  The tough fact of the matter is that it is almost
completely irrelevant whether we like the standard or not - X.400 is
happening now regardless.  There are already countries where, as I said
previously, you *cannot* sell machines unless you offer a complete X.400
system.  (interestingly, the best selling X.400 package, All-In-One from
Digital Equipment Corporation, currently has a number of blatant protocol
violations on its lower-level interactions with other X.400 systems (but
we can be sure that DEC is working like mad to fix that as soon as they
possibly can!))

This is not to make light of the problems of an electronic mail package
user interface!  From dint of the experiences with not only the Msg and
Elm mail packages, but from the research I've put in on various articles
on electronic mail systems (the latest being in the book "The Unix Papers"
from Howard and Sams Publishing...) I've found that perhaps the *most*
important aspect of any system, and especially a system like one for the
creation, transmission and reception of electronic mail, is in fact the
user interface.

So with that preamble, I'd like to highlight the deficient areas of the
EAN package, based *purely* on what Mitchell Wyle posted in his article.

The first problem that is raised is that of the data storage method.  Not
only does EAN use a unique format for the storage of data (which, I would
venture a guess, is related to X.408 (MHS: Encoded Information Type
Conversion Rules) and X.409 (MHS: Presentation Transfer Syntax and Notation)
standards if nothing else..) and that a side effect of this is that 1. the
folder space is one-level deep (e.g. there is no capability for having 
folders within other folders), 2. the utilities that are available for
keeping your dataspace clean aren't totally reliable (e.g. "eanrebuild"),
and 3. EAN didn't like the data that was restored from a backup tape.

One of the stranger aspects of the X.400 suite from our anglocentric
point of view here in the US is that it doesn't store everything in an
English-based format.  In fact, the method by which the message
envelope (as they say) is built up and saved is designed to be as
*in*dependant of host language as possible.  One of the 'headers' of
an X.400 message is in fact the language that it was composed in, so
that the displaying system can easily choose the appropriate character
set.  An obvious side effect of this is that the data storage format
for the messages cannot suddenly be in a different, '822 style, format.
So instead, you're left with the necessity of having to use various
utilities to help maintain your data space.

Given that, I would suspect that the EAN group would be more than just
interested in hearing about problems with the reliability of their 
system!  Certainly if you can fully describe the situation whereby
the "eanrebuild" program destroyed your saved messages it would at least
be a big help in ensuring that they can fix it and make sure it doesn't
happen to other people!   And as to the problem with data off of a backup
tape, I suspect that it is a subtle problem with file modification times
or something, and that, again, if you were to *tell* the EAN people
about the situation they would quickly remedy it.

[general philosophical comment here: I find it unfortunate that so many
 people aren't willing to work with their software vendors in situations
 such as this - software is just like any other complex system and it
 occasionally needs some fine tuning.  But there is *no* way for the 
 intrepid vendor to achieve this if the users have something go wrong
 then simple stop using the product, instead of letting 'em know about
 it!  Let's get on the ball, people!]

Mitchell then goes on to talk about some aspects of the User Interface
to the EAN X.400 mail system.  Specifically, he states that a couple of
the problems he has are that; 1. there is no way to specify rules and
actions and otherwise make it a programmable interface,  2. there is
no way to have multi-level folders,  3. it doesn't exploit the additional
resource of the CRT *screen*,  and 4. it has no intelligent retrieval 
system for archived messages.

I must admit that I'm not sure exactly what Mitchell is talking about
in his first point here - I have on my machine a program which 'screens'
my electronic mail before allowing it to be delivered to me, and it can
reply to mail automatically, store it in folders for later perusal, 
or even instantly display it to the screen.  But that is one of only
three systems that I know of that offer this sort of functionality
and none of them are in widespread use (they are "filter", from the
Elm Mail System, "mh-hook" from the MH package, and MEP from John
Antypas).   I'm very interested in hearing more about what is being
suggested here (and shan't bias it by talking about how *I* think
mail systems should work!)

The problem with multi-level folders, and the related problem of
not having an intelligent retrieval system are actually symptomatic
of a much larger problem with generalized information retrieval
systems.  I believe that the *real* answer to this is to have a
hypertext system available and to obsolete the entire idea of
folders.  I know of a couple of systems in the works that support
just this, and I imagine now that Apple has released HyperCard for
the Macintosh that it's just a matter of time before some bright
cookie exploits that for the same area.  The idea here would be
to specify a list of criteria to base selection of possible 
messages on - sort of like full-text keywording - and then have
the system select messages based on that.  (I think this is really
the wave of the future and I'm looking forward to having it on
MY machine soon!)

As to the EAN interface not exploiting the resources and space of
the CRT screen, well, all I can say is that Andrew Draskoy of the
University of British Columbia and I have talked a couple of times
about full-screen interfaces for the EAN system and that he has
recently requested a copy of the Elm Mail System from me for some
ideas of how to exploit a full screen and still retain the ease of
use of a simple system...I wouldn't be suprised to see them release
an impressive and powerful new interface to their system within a
year.

By the way, Mitchell also refers to the Berkeley Mail package as being
"in the public domain".  This, of course, is not the case at all, and
the package is in fact covered under the same copyright and licensing
restrictions as the rest of the BSD binaries and sources.

Finally, I hope those of you that have managed to read this far have
found this an informative note.  I would like to hear further discussion
on electronic mail user interfaces and shall be forwarding the comments
as appropriate to interested other parties.  (there are also a number
of mailing lists dealing with mail user agents, mail handling systems,
the X.400 protocol suite, and so on - check the "list of lists" that
sporadically appears on the net...)

			From the far corners of the globe,

					-- Dave Taylor
					Hewlett-Packard Labs