🚀 go-pugleaf

Rupert Mohr replies to my comments about EAN and X.400 with some interesting
comments of his own, but at one place he misses my point entirely, alas:

>: 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. [...]
> 
>What means "stranger aspects? There are countries with users, who don't
>speak English . So an language indepent Prot[ocol spec] has its merits.

I think the problem here is with the word 'anglocentric'.  I used it to
mean 'centered on the anglo/english-speaking world'.  The comment was
more to the effect of 'it is unfortunate that here in the US we're so
convinced in the ultimate value of English that we, for the most part,
view any system that is to support other languages by *not* being in
English as suspicious' (althought that isn't much clearer either!!)

In general I think that X.400 is a good thing (are we going to start
talking about the value of X.400 here??) and that since it specifies
a non-ascii-based message envelope it makes the most sense for the
messages to also be stored in that format.  (a strong case can be made
that it should be translated to the local language upon storage, though,
and I'd be interested in hearing peoples ideas on this either way...)

As I've tried to say too, however, the Unix system especially is
very much oriented around having 'flat' ASCII files and there are 
a plethora of useful and interesting tools that you can then use to
wreak havoc on these text files.  Storing X.400 mailboxes as non-ASCII
data unfortunately loses this major Unix advantage, and the X.400
vendor is then put in the position of offering their own tools to
replace and/or supplement the already-built-and-tested Unix ASCII
tools...

		six of one, half-dozen of the other....

						-- Dave Taylor
						   Hewlett-Packard Labs