The article has been posted to comp.mail.misc and comp.protocols.iso.x400
for your interest.
This article is Copyright(c) 1994 J.A. Carroll Consulting, and may be
freely distributed throughout the Internet, corporate e-mail systems or
other systems via e-mail, as long as this header remains
intact. This article may not be reprinted for publication in print or other
media without permission of the author.
=========================================================================
X.400 is Dead, Long Live X.400
By Jim Carroll, jcar...@jacc.com
A couple of years ago, I wrote in this column that I saw an increasing
migration to Internet e-mail, and that X.400 as a standard for the exchange
of e-mail between systems was not working well.
It's time to update that column. I am more convinced that the X.400 standard
is on its last legs when it comes to interpersonal e-mail, and that the
Internet has become the defacto standard for the regular exchange of e-mail
between people and organizations.
There are four reasons for this.
The first reason is because X.400 is simply too complicated! People just
can't understand an e-mail standard that requires that you have knowledge
of terms like administrative domains, private domains, organizational units,
user-defined attributes and other such silliness. People will not work
with a standard that requires a thick manual merely to figure out how to
address a message to someone else. I have several accounts that could be
reached by X.400, each of which could be used in a different way,
depending on what system you come from. You might reach me as
c:us,a:mcimail;f:jim; s:carroll; on one system, or you might reach me
using the method mhs!c=us/ad=mcimail/pn=jim_carroll, while on yet a
third system you might send to me using the form
[jim_carroll/jacarrollconsulting] mcimail/usa.
These can be considered simple examples in the world of X.400. (And,
not all addresses are guaranteed to work properly - when writing
this article, I didn't have the chance confirm that each one is precisely correct, one
of the necessities of X.400!)
At one point, I was helping a client reach someone at Hewlett Packard,
via an X.400 adddress of the form surname/admd=telemail/c=us/o=hp/prmd=hp
/s=surname/g=firsname. If you can believe, some people actually print X.400
addresses on their business cards!
The second reason X.400 is dead is that anyone beyond us computer geeks
simply will refuse to learn it, understand it, or use it. The Chief
Financial Officer at a major client of mine just received a fax from a
large public accounting firm, asking if the organization was equipped
to do e-mail via X.400. The fax went on to describe how to figure
out an X.400 address, and was three pages long! A sane and rational
person will have tossed the fax into the garbage even before
finishing the first page.
The CFO also has a simple Internet address, and was quite confused
as to why anyone would pick a more complicated method. Think of
it from his perspective : with an Internet ID as simple as
someone@somewhere, why would anyone in their right mind choose a
system that required an alphabet X.400 address? No wonder we
have a tough time getting money for technology projects, if we
suggest to sane people that they use such ridiculous, geeky
computer standards.
Simply put, folks, X.400 addressing is for geeks, and won't be learned by
anyone beyond that.
The third thing that made me realize that X.400 is dead as an inter-
organization e-mail standard was the release of the statistic
that 46% of the largest publicly traded companies in the US had
some form of Internet presence by July 1994. The Internet continues
to grow by leaps and bounds, particularly for the exchange of e-mail
between corporations. The explosion in Internet e-mail is
simply remarkable. In the last six months, I have communicated with
individuals from around the world, including many Fortune 500's,
through many thousands of Internet messages. I have not sent
one X.400 message. It is too painful!
The fourth thing that made me realize that X.400 is dead is that
few people in organizations know how to use it. In one client project,
I was assisting a company that wanted to establish e-mail
communications to major Fortune 500's. When the recipient was on
the Internet, it was a piece of cake and took two minutes, since
people tend to know their Internet address. When X.400 was involved,
we usually had to work out way through layers of bureaucrats
to discover the particular individual who knew "X.400 speak."
It took days and weeks instead of minutes. This is a standard?
Where we have to try to find the one organizational expert on X.400?
People pay me to help them figure out how to use X.400. They pay me! Isn't
there something wrong with this picture - an addressing standard that is so
complicated that you have to hire a consultant to figure it out?
It's the same as having to hire someone to help you understand
how to dial your telephone! It's a ridiculous state of affairs!
Fax took off because people understood the concept of a photocopier plugged
into the telephone....and the way to reach any fax anywhere in the
world was a simple telephone number. Internet e-mail is exploding
in use because people understand the concept of an ID that is
basically, someone@somewhere. X.400 is dead, because it isn't as
simple as the telephone, fax, and Internet e-mail.
It will probably remain in some form to support high volume, EDI based
communications between major Fortune 500 organizations. But for simple, run
of the mill, day to day communications between people,
it's dead, caput, game over....
Jim Carroll, co-author of the Canadian Internet Handbook, can be
reached quite easily on the Internet at jcar...@jacc.com. He can be
reached via X.400, but suggests that you first consider becoming a
rocket scientist.
====================================================================
Jim Carroll, C.A. +1.905.855.2950 (voice & fax) jcar...@jacc.com
J.A. Carroll Consulting, Electronic Mail and On-Line Research Consulting
Co-Author, "The Canadian Internet Handbook", Prentice Hall Canada, 1994
#1 Non-Fiction Paperback in Canada, Financial Post
Executive Seminars On Internet Strategies - send a message to sem...@jacc.com
It is impossible to disagree. Just look at the volume in this
newsgroup! But:
You are not always comparing like with like. Native Internet
addressing is easy. You are comparing this to X.400 accessed from a
non X.400 system via a gateway. Like saying that Internet addresses
are unusable, because you have to write the following to reach it from
an X.400 system, not fair:
DD.RFC822=Jon.K.Hellan(a)idt.unit.no;P=internet;A=telemax;C=no;
But of course you are right. X.400 addresses *are* twice as long as
Internet addresses, given the same content, and more than twice as
hard to remember. A regular mapping of
Jon.K....@idt.unit.no
into X.400 would be something like
G=Jon;I=K;S=Hellan;O=idt;P=unit;A= ;C=no;
And there now is a standard about how to print X.400 addresses on
business cards. But it was not passed until 1992. X.400 had been
around for 8 years by then. Imagine!
However, it is possible to avoid using X.400 addresses altogether,
even if you operate an X.400 system. There are address conversion maps
and algorithms which work well, provided that you choose your X.400
addressing system appropriately. When I used an X.400 mail system,
which I helped develop at my previous place of work, I only saw
Internet forms of the addresses, X.400 suppliers will have to present
only Internet addresses to users in the future.
X.400 is a sad tale of lost opportunities. There are lots of nice
things about X.400. Receipt reports and delivery notifications are
very useful, and they "already" work. Mechanisms for identifying file
formats, have been around since the beginning, as well as mechanisms
for handling various 8 bits and larger character sets. But these
facilities never were deployed, because nobody got around to
standardizing them. Many more advanced features are there, for
situations where they are needed (like EDI). It is a sad story
indeed. Now we seem to be stuck with MIME instead, and MIME is a mess.
I could go on and on. Take routing, for example. But I'd better stop.
In conclusion, I would say that X.400 could have been made to
work. Internet address syntax could have been adopted, and still
can. And a routing system as usable as DNS would have been
needed. Now, we can expect growth only in applications like EDI, and
in those places which decide to continue mandating X.400. But the war
is over (it ended at least two years ago). And Internet mail won.
--
Jon K. Hellan Jon.K....@idt.unit.no
Div. of Computer Systems and Telematics Phone: +47 73 59 44 33
Norwegian Institute of Technology Fax: +47 73 59 69 73
Trondheim - Norway
>I am more convinced that the X.400 standard
>is on its last legs when it comes to interpersonal e-mail, and that the
>Internet has become the defacto standard for the regular exchange of e-mail
>between people and organizations.
>There are four reasons for this.
Four reasons why "X.400 is dead" or 4 reasons why "Jim Carroll believes
X.400 is dead"?
Jim gives 2 reasons, actually. First, X.400 addressing sucks. Second,
Internet popularity is booming.
My impression of X.400 addressing is that it is verbose and inflexible
which agrees entirely with Jim's belief. I agree about the booming Internet
also.
However, I think there's more to X.400 than its addressing scheme, and
it would be wrong to dig its grave on account of that alone. Perhaps it
has some redeeming technological achievement from which we could learn
and improve the current Internet mail convention.
Nick.
--
Kralizec Dialup Unix (Public Access) Data: +61-2-837-1183, 837-1868
Zeta Microcomputer Software v.42bis v.32bis 14.4k 24 hours
P.O. Box 177, Riverstone NSW 2765 Telnet kralizec;login guest for info
When designing any kind of distributed system, you have to decide where
to put the functionality of the system: at the core (inside the cloud
of service-providers) or at the edges (with each end-user).
I think that the success of things like IP/TCP over X.25/TPn, and
things like SMTP/822/MIME over X.400, etc., all show that the core
should be as simple as possible to make it easier to interconnect
different entities (entities = administration, site, or product). With
such an approach, functional improvements never really impact the
installed base, because only those end-users who want the additional
functionality are exactly the ones who have to update their
environment, and the core is never involved (e.g., the fact that this
message is MIME-tagged means nothing to a UA that's 5 years old, but to
my MIME-capable UA, it can do additional processing, and all of the
service providers connecting the two simply don't care). There are a
lot of neat things that fall out of the approach of letting complexity
drift to the edges, e.g., stability, predictability, ease of repair,
etc.
To go back to X.400, it clearly follows the model of putting complexity
at the core. One of many artifacts of this is the addressing scheme
which embeds service provider identities (ADMDs/PRMDs) into addresses.
I can probably list about four show stoppers that X.400 hit, all due to
believing in the wrong philosophy.
/mtr
< from Nick Andrew>
>..... I think there's more to X.400 than its addressing scheme, and
>it would be wrong to dig its grave on account of that alone. Perhaps it
>has some redeeming technological achievement from which we could learn and improve the current
>Internet mail convention.
Yes, like security!
I am currently evaluating e-mail options for outside our corporate structure, and while I exclusively use
internet mail, I cannot at this time advocate such an insecure (imho) network for handling confidential
business e-mail.
I dont like much of the x400 implementation (mostly the PRICE of the carriers compared to the price of
internet mail ) but I am confident that business communications will be MORE secure via the x400
carriers than the Internet.
The people at my company are anxious to communicate, and I want to facilitate that desire, but today
x400 seems the only way.
j$
...Mike
--
Michael J. O'Connor Internet: m...@dojo.mi.org (email address)
InterNIC WHOIS: MJO http://www.msen.com/~mjo/ (WWW home page)
"History is made at night!" -from _Buckaroo Banzai_
> X.400 suppliers will have to present
> only Internet addresses to users in the future.
Amen, brother!
Harald A
Harald T. Alvestrand
(not a disinterested party - I co-chair the NOTARY group....)
This is the "gateway" argument; my big problem is that I still don't
have a single really good example of a system where this worked out.
Two possible examples:
- The Internet/X.400 gateway service using coordinated mapping tables.
Unfortunately, after we had worked out most of the problems, the
people didn't come to the party :-)
- The TPC.INT interconnection between the Internet and the telephone
network. Not yet providing universal coverage, I think, so the
jury may still be out on this one?
The problem with the edges is that they are VERY expensive to upgrade.
The problem with the center may be that there isn't one?
Harald A
(now, how and why did you munge those headers? From: mhsnews indeed....)
I think end-to-end encryption using public key cryptosystems is the
only solution that can really work for E-mail, and as far as I know,
PEM is much more of a complete specification than anything that I know
of that is built on the *framework* provided in X.400/88.
Harald A (more bigoted by the day?)
>I dont like much of the x400 implementation (mostly the PRICE of the carriers compared to the price of
>internet mail ) but I am confident that business communications will be MORE secure via the x400
>carriers than the Internet.
Why should mail containing X.400 headers, be more secure? Why can't
the same carrier transport mail with RFC822 headers in a secure way?
--
Rahul Dhesi <dh...@rahul.net>
But this is nothing to do with X.400. If you had a different
mailer it might translate "Jim.C...@mcimail.us" into the first
of your strings above. (The other ones seem to have local mailer
garbage which is hardly X.400's fault.) X.400 addresses are
combinations of attributes and values. Typing them out on a
single line is obsolete even by the standards of the forms-mode
terminals of decades ago, let alone GUIs.
More likely, I would reach you by
(a) selecting you from my online address list
(b) if you weren't in that, by looking you up in the Directory
If you and your e-mail address aren't in the Directory, then you
are in no position to complain about having to write it out by hand.
You might as well complain that IP numbers are hard to remember
(at least, the 16-byte ones will be).
>Simply put, folks, X.400 addressing is for geeks, and won't be learned by
>anyone beyond that.
X.400 addressing is for machines, and won't be learned by anyone.
>Internet e-mail is exploding
>in use because people understand the concept of an ID that is
>basically, someone@somewhere.
What is 'someone'? Is it someone's name? With or without their
initials? What if I only know the name as "Mr Fred Bloggs at IBM UK"?
I myself have eight someone@somewhere addresses for the same e-mail
account, three of which use variant spellings of my first name,
one which uses a more unique 'someone' in a more global 'somewhere'
one in which the 'somewhere' points directly to the real machine,
one in the @ibmmail.com domain etc.
As for 'somewhere', that's just an entry in the DNS, isn't it?
I.e. it's a mnemonic that indirects via a directory to something
almost certainly less memorable and/or permanent?
>X.400 is dead, because it isn't as
>simple as the telephone, fax, and Internet e-mail.
Telephone and fax also rely on directories, unless you like
memorising 12-digit numbers.
Obviously the Directory has some way to go. But for someone
to write a speculative, non-technical, predictive article about
X.400 without mentioning the Directory _once_ is surely missing
the point.
>X.400 addressing is for machines, and won't be learned by anyone.
True.
I have never yet been handed a business card with an X.400 address on
it, but I see many with domain-format email addresses. I assume that
X.400 requires one to hand out magnetically-imprinted business cards
that can be fed into a card-reader, which will (I guess) be a part of
every computer terminal by the time that X.400 becomes a worldwide
standard.
--
Rahul Dhesi <dh...@rahul.net>
Great! A directory, I always wanted that.
>If you and your e-mail address aren't in the Directory
Am I in it? Please find my X.400 address in it, OK? Are you in
it? Tell me how I can find you in the directory.
>Obviously the Directory has some way to go. But for someone
>to write a speculative, non-technical, predictive article about
>X.400 without mentioning the Directory _once_ is surely missing
>the point.
Well, you said that the directory is/should be the only way to send
mail to someone not in one's personal address list. X.400-84 is ten
years old now and still the directory hasn't been implemented, is
there any reason to believe it ever will be? If it'll never be
implemented, why mention it?
--Arnt
AG> If you and your e-mail address aren't in the Directory, then you are
AG> in no position to complain about having to write it out by hand.
How actively deployed is "the Directory"?
Does it run on my business card? (hint: an unambiguous address in a form
which can be portably printed on business cards is *very* useful)
>> X.400 is dead, because it isn't as simple as the telephone, fax, and
>> Internet e-mail.
AG> Telephone and fax also rely on directories, unless you like
AG> memorising 12-digit numbers.
I certainly don't memorize that many of them. What I do do is keep
business cards around, which have them nicely preprinted in ways which I
can store in a pocket.
Quick example:
(1) I go to a conference. I meet a Stephen Bourne, from Bell Labs. He
gives me a business card with an RFC822 address on it. I can send him
email at that address.
(2) I go to a conference. I meet a Stephen Bourne, from Bell Labs. He
gives me a business card with no email address on it. I look in "the
Directory". There are two people by that name at Bell Labs. Which
one do I email? Whoops, guess I have to use that phone number...
--
Christopher Davis | "It's 106 ms to Chicago, we've got a full disk of GIFs,
<c...@kei.com> | half a meg of hypertext, it's dark, and we're wearing
MIME * PGP * [CKD1] | sunglasses." "Click it." -- <blue...@bluesbros.com>
Interesting - I get quite a few. The last one I got was last Fri. The
chap who gave it to me crossed out the X.400 bit and left the Internet
address - he said the X.400 one didn't work realiably.
Dave
Heh heh..the ones that want email from you cross out the X.400 and
leave the domain. The ones that don't want to hear from you cross out
the domain and leave the X.400.
Rahul
> Date: Mon, 17 Oct 94 09:44:28 BST
> From: Dave Morton <Dave....@ecrc.de>
> To: dh...@rahul.net, mhs...@uninett.no
> Message-Id: <941017084...@scorpio.ecrc.de>
> Subject: Re: The Death of X.400
:Much though I dislike X.400 addresses, I have to point out that they
:have advantages.
:
:Well-known personalities, like the Stephen Bourne to whom you wish to
:send email, will prefer to print their X.400 email address on their
:business cards. This will ensure that they receive no unsoliciated
:email.
This underscores the point that I made a long time ago: X.400 was
designed by people who really didn't want to communicate with each
other in the first place.
...Mike
--
Michael J. O'Connor Internet: m...@dojo.mi.org (email address)
InterNIC WHOIS: MJO http://www.msen.com/~mjo/ (WWW home page)
"I sure wish I could get my hands on some REAL dynamite." -Calvin
>(2) I go to a conference. I meet a Stephen Bourne, from Bell Labs. He
> gives me a business card with no email address on it. I look in "the
> Directory". There are two people by that name at Bell Labs. Which
> one do I email? Whoops, guess I have to use that phone number...
Much though I dislike X.400 addresses, I have to point out that they
have advantages.
Well-known personalities, like the Stephen Bourne to whom you wish to
send email, will prefer to print their X.400 email address on their
business cards. This will ensure that they receive no unsoliciated
email.
--
Rahul Dhesi <dh...@rahul.net>
expense is actually irrelevant! if two users want to layer some
functionality on top of the core, then it's up to them to decide if it
is cost-effective.
this is why a heavy-duty core will always lose...by definition, it must
offer services which are of interest to only a subset of its users and
yet all users are impacted by them...
/mtr
- The lack of a simple file transfer body part. The standards came out
10 years ago, yet they still have not even come up with straightforward
way to transmit files, while retaining such basic items as the file
name, and its creation/modification date! The 1988 standard had promise
with bp15, but six years later there is still no consensus on how to use
it!
- When defining the '88 standard, they left out a significant item in
the downgrading rules to '84. Sure, a 1988 MTA can downgrade P1 to talk
to a 1984 MTA, but if the content is '88 P22, the 1984 UA that receives
the message can't read it! An EMA committee is working on this, but
again, it's been SIX YEARS since that standard came out!
IMHO, what is going to kill X.400 is the glacial pace at which updates
are made to the standards. This is the computer industry - things
change in minutes, hours, and days - not YEARS! I can't say for sure
that X.400 is dead, but if it is going to pick itself up off the mat,
its proponents had better come up with solutions to its limitations
ASAP.
-----------------------------------------------------------------
{{{{
o/{{{ David C. Johnson Boulder, CO
<|_{{{
> {{{
{{
One problem with the Internet is that it is very hard to run anything
*but* a globally uniform service on top of it.
I would like to see things like routing of E-mail that depends on why
I'm asking (or at least more interesting factors than the recipient's
name); sensible routing within a domain that did not require all
machines' port 25 to be globally accessible and so on.
Simplicity is winning the day; I sometimes think that we may be going
too far in that direction. "As simple as possible - but no simpler"
is a nice slogan.
But I'm in no real position to argue; the global, open Internet is adding
power every day.
harald A
The File Transfer Body Part is in X.400/93 as a new BP15.
You might read Ned Freed's Internet-Draft on gatewaying it into
Internet Mail before you start thinking about whether it represents
an elegant solution to the problem.
Harald A
So it might be worthwhile rethinking the strategy.
Of course, the lack of progress in the X.400/X.500 arena has been
startling.
paul
USC/Information Sciences Institute phone: 310-822-1511 x285
4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714
90292
jc
>
>IMHO, what is going to kill X.400 is the glacial pace at which updates
>are made to the standards. This is the computer industry - things
>change in minutes, hours, and days - not YEARS! I can't say for sure
>that X.400 is dead, but if it is going to pick itself up off the mat,
>its proponents had better come up with solutions to its limitations
>ASAP.
>
Read Carl Malamud's "Exploring the Internet." It is a fascinating
indictment of the whole OSI standard setting process.
Look at MIME. When did it first come up? Early '93? And look at how
far it has already been *implemented*.
jc
X.400 works at the MTA to MTA level. It fails at addressing.
Internet works at MTA to MTA. It excels at addressing.
Ergo, Internet succeeds, X.400 fails. It's as simple as that.
I doubt we will see 'the Directory.' I think we already are seeing one
emerge, in the DNS.
jc
>Its clear to me that the MX scheme in the internet solved, say, 99% of
>all mail-routing problems at the time, leaving 1% that it didn't solve
>real well. As the years have passed and the internet has become more
>complicated and sizable, the originally small slice has grown both in
>size and percentage. (That slice is probably bigger than the whole
>pie was at MX time)
I recall pre-DNS days, and rebuilding a 40kline /etc/hosts was a bummer
on almost any machine of the day. This sort of low-level "must have"
"killer infrastructure" typifies all thats right about the Internet.
Deploying something to make net and transport-level code work well
had massive implications for user-level activity as well. -The DNS
hooks apart from MX targetted at mail delivery may not be widely used,
but the effect of DNS on mail has been as big as the effect on any other app.
>So it might be worthwhile rethinking the strategy.
I can't think of any answer coming from the X-series standards that
could function as a DNS replacement and support IPv4 let alone IPv6.
For myself, I'd not want ANTHING which depended upon:
type:value in addresses
non-ordered address components
non-deterministic address constructs (CHOICE/ANY)
>Of course, the lack of progress in the X.400/X.500 arena has been
>startling.
Not startling, predictable. Depressing, but forseeable.
I sometimes wonder what the various parties involved in OSI/Internet
stuff (like ISODE, mea culpa) could have achieved if the same effort
had gone into pure Internet development. MIME 5 years earlier?
-George
--
George Michaelson
G.Mich...@cc.uq.oz.au The Prentice Centre | There's no market for
University of Queensland | hippos in Philadelphia
Phone: +61 7 365 4079 QLD Australia 4072 | -Bertold Brecht
I like it.
Good news, and checks to p...@isi.edu
Bad news, bills, flames to c=us;ou=......
Rest easy, I was thinking that the internet gang might come up with
MX+ or some such.
Piet
Internet is regarded widely as insecure because 'anyone' can put
a packet sniffer into a relaying subnet or host and monitor your traffic.
However, 'anyone' is really only those with physical access to a service
provider or routing site. As far as I am aware, backbone traffic is kept
inside a secure environment by router operators and not sent around a
campus network, for example.
With X.400, the equivalent of routing sites are within PTT facilities,
which tend to be kept physically very secure. Even PTTs have leaked though,
generally through corrupt employees, the most common occurence being
the leaking of ex-directory numbers.
You are probably looking at a factor of 10 better security through X.400,
simply because your data only passes through the PTT community rather than
a diverse set of Internet sites. However, this is not to say that Internet
mail is akin to postcards, or that X.400 mail is bombproof. The *big* (and
deliberate) security hole in Internet mail is the lack of sender
authentication. You should worry about taking a message on face value as
being from the sender.
BUT: There is a simple solution. Encrypt and sign all external mail
(or even all mail) using PGP. This can be done at the user interface,
or on passing mail into Internet. PGP encryption is effectively
unbreakable (at the very least, by a commercial organisation).
This is much more secure than relying on X.400, where essentially you
trust the carriers not to read your mail.
--
------------------------------------------------------------------------------
Richard Parratt * See that 'core' file there:
Still in London, * That's your program, that is.
rpar...@london.micrognosis.com *
------------------------------------------------------------------------------
Piet
I share your view about X.400 and X.nnn series but I want to clarify
on this specific point which somehow relates to ASN.1 and might lead
to conclusion about ASN.1 itself (which I do agree is not what you
have written)
I am not debating about X.400 choices which are at least
debatable, but I would not like other people believe
ASN.1 is broken, because of the 3 lines above.
----- case for ASN.1
it is not because X.400 and X.500 are probably dying that ASN.1
should be seen as bad, just for this reason
Let me elaborate a little bit more
1. as far a I know ASN.1 is used by highly successfull IETF standard,
think of snmp....
2. I am getting a bit disapointed that some Internet people
cann't imagine that a protocol can be defined with modern
technology and will not be forever a 7bit ASCII char based
syntax.
They have to understand that
- software engineering exists now, applis will not be handcoded
by some wizards, but using modern software development
environment. An ASN.1 compiler is one of these.
- Applications getting more complex, there is a need for more
complex objects. It is time to get away from the mess of say
the SMTP/RFC headers for which there are RFC but also the
sendmail implementation reference and which is a nightmare
for developpers
- there is a need to distinguish between a spec (they call it
an abstract syntax, it's not stupid) and one or more
transfer syntax (encoding). The spec has to be clean
unambiguous and implementable by means of generators.
- ASN.1 being a grammar, that does not imply that any particular
protocol defined using ASN.1 must necessarily present some
bad characteristics. It is up to the people doing the spec
to use ASN.1 for something simple if they want it simple.
(I did not say the X.400 ASN.1 is bad or good, just that ASN.1
per se is something that the Internet must consider and often
use, and that will produce much better things that semi formal
specs... again snmp is a good example)
in other words : the tool is different from what can be built
using such a tool
>
> >Of course, the lack of progress in the X.400/X.500 arena has been
> >startling.
>
> Not startling, predictable. Depressing, but forseeable.
Right but this is certainly not due to the fact ASN.1 was used
but, as pointed by many and specially M T Rose, because of
the conceptual and functional model.
-- PAP
-george
Uh, 'anyone' is really anyone who has sufficient privilieges on a
_machine_ that has physical access. Getting such access at a remote
site is, I wildly assume, about as difficult as getting access to
/var at the same site.
Unless that assumption is wrong, it should be approximately as
difficult to look at mail at an X.400 relay as it is to look at
packets at an IP routing site.
I don't agree that lack of sender authentication is specific to SMTP.
"/S=heidi/OU=nvg/O=unit/PRMD=uninett/ADMD= /C=no/" is valid, but how
can you know that it maps onto a real person, or that that person is
the real person it purports to be? X.400 may guarantee that the a
simple reply will send mail to the actual sender, but that actual
sender may well not be the actual real-life person you think it is.
Same name, different PRMD, for instance: How are you to know?
--Arnt
Moreover, the following story is about 10 years old, but there is
no *real* reason to think that things may have changed:
People at a telecom service providers needed a sample of (analog) traffic.
So, they walked over to the city's biggest exchange, through the door,
which was NOT locked, and hooked up a 24-channel tape recorder to
24 random telephone trunk lines. They never showed any form of ID;
they just said "hi, we've come to make some measurements".
When they asked to visit the bathroom, they were told that "yes, but
we have to unlock it for you; we've had trouble with people coming
in off the street to use it".
The bathroom was locked; the wiring closet wasn't.
Safety through obscurity?
Harald A
The only business card I have been given with an X.400 address
had the address printed on the back of the card - it took up far too
much space to fit on the front.
Cris Bailiff
---
Email: cr...@drives.rta.nsw.gov.au, cr...@ozemail.com.au, cr...@tmx.mhs.oz.au,
cr...@mpx.com.au, dri...@rta.nsw.gov.au and many other addresses,
/S=But/G=None with/ADMD= /PRMD=slashes/ORG=or/OU=Xs/OU=or/OU=other such/DDA.JUNK=grafted/X.121=on/
--
DRIVES PROJECT
>From: jcar...@jacc.com (Jim Carroll)
>Subject: Re: The Death of X.400
>Date: Tue, 18 Oct 94 02:14:32 GMT
>X.400 works at the MTA to MTA level. It fails at addressing.
>
>Internet works at MTA to MTA. It excels at addressing.
I don't think the debate can be expressed that simply.
Addressing is an issue - a user and user interface issue. However,
because Internet addressing is claimed to be simpler than X.400, you
cannot draw the conclusion below...
>Ergo, Internet succeeds, X.400 fails. It's as simple as that.
Looking at addressing there are two main issues. External (paper /
business card) representation, and internal (the user interface).
Internally, the representation does not really matter as long as it
works. I've replied to this message and apparently its is going to go
a node called 'uninett.no' - what's that? (Don't answer that, I do
know really but you get the point!) Actually I don't care - my
message will get there so does it matter what uninett.no is? This
is true from both X.400 and Internet.
I claim most email is sent either in reply to a message, or via an
establish communication path (such as using address stored in a local
address book or alias file). I am a reasonably heavy user of BOTH
X.400 and Internet mail systems, and have had to 'type in' probably
something like 5 addresses in the last six months. From this I
conclude that the external representation is of little consequence -
it matters in only in a very few cases.
When I receieve mail my UAs do not show the 'network form' put the
personal form (e.g., Jim Carroll from "jcar...@jacc.com (Jim
Carroll)"), ditto X.400.
In fact, when I have had to enter an address by hand, I find the X.400
User agent easier - it guides me to the components I need in the
address, rather than leaving me to supply a text string.
>I doubt we will see 'the Directory.' I think we already are seeing one
>emerge, in the DNS.
Systems like cc:Mail and other LAN based systems also have horrid
addressing schemes, where you have to know the post office name. But
does a cc:Mail user expect to type in addresses. NO. They have a
proprietary directory that holds the addresses for them - they point
and click.
These LAN systems like it or not, are successful in the corporate
world. The real issue in hand, is how do we extend directory concepts
to provide a unified X.400/Internet/LAN directory - the dreaded
synchronisation problem. Even if X.400 is dead, synchronisation for
the Internet community is still required I'm afraid to say.
Whatever the directory is - X.500 / DNS or something else - user agent
technology is the key - it has to hide the addressing from the user
and present directory and personal naming information - a photo
perhaps and say is this the guy you want to mail, or the given name of
the person sending to you.
Hopefully this attempts to dispel the X.400 is dead because of
addressing theme. (This worries me somewhat, I never thought I would
ever defend X.400 !) An X.400 address does look a bit worse that an
Internet address, but it really is not a big issue. There are much
much bigger issues that could be discussed.
Finally, there is a bit of a contradiction in the Internet community,
as Peter Williams pointer out when this debate was held on a different
list. How can the Internet community clain the address format of
X.400 is bad when the same community comes up with the URL concept
http://web.nexor.co.uk/users/cjr/cjr.html
That has to be the most user unfriendly thing ever. Hosts are not
seperated from file names etc etc, BUT IT HAS BEEN ACCEPTED by the
community. Therefore I suggest the rumour that X.400 is dead because
the addressing scheme is naff, should also claim the WWW is extinct.
Colin
PS
FYI I quote both X.400 and Internet addresses on my business card.
-------------------------------------------------------------------------------
NEXOR Phone : +44 115 952 0583
PO Box 132 Fax: +44 115 952 0519
Nottingham email: C.Ro...@nexor.co.uk
NG7 2UU X.400: I=C;S=Robbins;o=NEXOR;P=NEXOR;A=ATTMAIL;c=GB
UK X.500: Colin Robbins, NEXOR Ltd, GB
WWW: http://web.nexor.co.uk/users/cjr/cjr.html
-------------------------------------------------------------------------------
>From: jcar...@jacc.com (Jim Carroll)
>Subject: Re: The Death of X.400
>Date: Tue, 18 Oct 94 02:14:32 GMT
>X.400 works at the MTA to MTA level. It fails at addressing.
>
>Internet works at MTA to MTA. It excels at addressing.
I don't think the debate can be expressed that simply.
Addressing is an issue - a user and user interface issue. However,
because Internet addressing is claimed to be simpler than X.400, you
cannot draw the conclusion below...
>Ergo, Internet succeeds, X.400 fails. It's as simple as that.
Looking at addressing there are two main issues. External (paper /
business card) representation, and internal (the user interface).
Internally, the representation does not really matter as long as it
works. I've replied to this message and apparently its is going to go
a node called 'uninett.no' - what's that? (Don't answer that, I do
know really but you get the point!) Actually I don't care - my
message will get there so does it matter what uninett.no is? This
is true from both X.400 and Internet.
I claim most email is sent either in reply to a message, or via an
establish communication path (such as using address stored in a local
address book or alias file). I am a reasonably heavy user of BOTH
X.400 and Internet mail systems, and have had to 'type in' probably
something like 5 addresses in the last six months. From this I
conclude that the external representation is of little consequence -
it matters in only in a very few cases.
When I receieve mail my UAs do not show the 'network form' put the
personal form (e.g., Jim Carroll from "jcar...@jacc.com (Jim
Carroll)"), ditto X.400.
In fact, when I have had to enter an address by hand, I find the X.400
User agent easier - it guides me to the components I need in the
address, rather than leaving me to supply a text string.
>I doubt we will see 'the Directory.' I think we already are seeing one
>emerge, in the DNS.
Systems like cc:Mail and other LAN based systems also have horrid
>From: dri...@rta.oz.au (Drives Project - RTA NSW - Australia)
>Subject: Re: The Death of X.400
>Date: Wed, 19 Oct 94 07:19:39 GMT
>>>I have never yet been handed a business card with an X.400 address on
>>>it, but I see many with domain-format email addresses.
>>
>>Interesting - I get quite a few. The last one I got was last Fri. The
>>chap who gave it to me crossed out the X.400 bit and left the Internet
>>address - he said the X.400 one didn't work realiably.
>>
>>Dave
>
>The only business card I have been given with an X.400 address
>had the address printed on the back of the card - it took up far too
>much space to fit on the front.
I've just been through my collection on 127 business cards.
55 have Internet mail addresses (43%)
36 have X.400 addresses (28%)
14 have both (11%)
5 have the X.400 address on the back ( 3%)
This suggests there are a reasonable number of business cards out
there with X.400 addresses on them. It does of course depend uppon
the community you do businees with. In my collection, the ones
containing X.400 addresses are typically large corporates using
the technology for business communication, the ones with Internet
addresses are mostly technology companies involved in the networking
business in one way or the other.
Colin
>From: dri...@rta.oz.au (Drives Project - RTA NSW - Australia)
>Subject: Re: The Death of X.400
>Date: Wed, 19 Oct 94 07:19:39 GMT
>>>I have never yet been handed a business card with an X.400 address on
>>>it, but I see many with domain-format email addresses.
>>
>>Interesting - I get quite a few. The last one I got was last Fri. The
>>chap who gave it to me crossed out the X.400 bit and left the Internet
>>address - he said the X.400 one didn't work realiably.
>>
>>Dave
>
>The only business card I have been given with an X.400 address
>had the address printed on the back of the card - it took up far too
>much space to fit on the front.
I've just been through my collection on 127 business cards.
If X.400 is so bad, how comes the mhsnews distribution list
itself is an X.400 based list gatewayed to the Internet!?!
This begs another question - how many poeple are using X.400 but do
not realise it?
Colin
------- Forwarded Message
Return-Path: <arpa-mhs...@cs.ucl.ac.uk>
Delivery-Date: Thu, 20 Oct 1994 11:22:50 +0100
Received: from cs.ucl.ac.uk by lancaster.nexor.co.uk via JANET
with NIFTP (XTPP) id <225...@lancaster.nexor.co.uk>;
Thu, 20 Oct 1994 11:22:45 +0100
Received: from aun.uninett.no by haig.cs.ucl.ac.uk
with Internet SMTP id <g.07...@haig.cs.ucl.ac.uk>;
Thu, 20 Oct 1994 11:22:26 +0100
X400-Received: by mta aun.uninett.no in /PRMD=uninett/ADMD= /C=no/; Relayed;
Thu, 20 Oct 1994 10:40:25 +0100
Date: Thu, 20 Oct 1994 10:40:25 +0100
X400-Originator: EU-MHSnew...@uninett.no
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=uninett/ADMD= /C=no/;aun.uninet.582:20.09.94.09.40.25]
Priority: Non-Urgent
DL-Expansion-History: EU-MH...@uninett.no ; Thu, 20 Oct 1994 10:40:24 +0100;
DL-Expansion-History: mhs...@uninett.no ; Thu, 20 Oct 1994 10:38:47 +0100;
From: Colin Robbins <c.ro...@nexor.co.uk>
Message-ID: <"9154 Thu Oct 20 10:38:10 1994"@mhs-relay.ac.uk>
To: mhs...@uninett.no
In-Reply-To: <1994Oct19....@rta.oz.au>
Subject: Re: The Death of X.400
Sender: arpa-mhs...@cs.ucl.ac.uk
[... deleted old message ...]
------- End of Forwarded Message
2) I never manage to send binary files to people with X.400 addresses.
Or rather I manage to send them, they manage to receive them and then
cannot handle them.
Don't try to tell me X.400 is better in that respect than MIME (or VV
for that matter). There are still too many lousy user interfaces
around.
Let's stop this discussion and start building/testing deploying
supporting good User interfaces so that our users don't have to live
with the stupid mistakes we made that gave us different and rather
incompatible Wide Area mailprotocols.
Erik
X.400 does NOT require any specific authorization of the sender field.
Indeed, most X.400 mail is (I believe) generated from systems where
the sender *cannot* be verified by the X.400 MTA, such as SMTP
gateways and LAN mail environments.
Harald A
Quite correct Jim's comments are about the UA and not X.400 his first is
ATT his second one of the MCI dont recognise the third. Also virtuaaly all
X.400 providers privide fornt ends to their systems - In fact some are
quite obvouisly designed that way.
> More likely, I would reach you by
> (a) selecting you from my online address list
> (b) if you weren't in that, by looking you up in the Directory
>
> If you and your e-mail address aren't in the Directory, then you
> are in no position to complain about having to write it out by hand.
> You might as well complain that IP numbers are hard to remember
> (at least, the 16-byte ones will be).
>
> >Simply put, folks, X.400 addressing is for geeks, and won't be learned by
> >anyone beyond that.
>
> X.400 addressing is for machines, and won't be learned by anyone.
>
> >Internet e-mail is exploding
> >in use because people understand the concept of an ID that is
> >basically, someone@somewhere.
>
> What is 'someone'? Is it someone's name? With or without their
> initials? What if I only know the name as "Mr Fred Bloggs at IBM UK"?
> I myself have eight someone@somewhere addresses for the same e-mail
> account, three of which use variant spellings of my first name,
> one which uses a more unique 'someone' in a more global 'somewhere'
> one in which the 'somewhere' points directly to the real machine,
> one in the @ibmmail.com domain etc.
again correct - a couple of years ago I was give the task of testing X.400
I managed to send (without knowing any thing except that he worked for Hp and
his name ) to a fiend at HP by using common sense and X.400 - I would not
be able to do the same for RFC-822 some of my collegues have addresses like
xx...@mupet.bt.co.uk or xxx.zoo.bt.co.uk
>
> Obviously the Directory has some way to go. But for someone
> to write a speculative, non-technical, predictive article about
> X.400 without mentioning the Directory _once_ is surely missing
> the point.
Here Here
Rgds Maurice
Jim, you should know that what you see on the Internet does not represent
all the traffic on the 'information highway' - only some of the flashier
sports cars, the VM beetles, the RVs and the Greyhound buses. On other
lanes of the highway there are trucks carrying goods, and sober
businessmen's cars traveling from office to office. Unlike the other
travellers, they are very quiet - unless you listen carefully, you don't
hear them.
OK, flight of fancy over. Besides the however-many people on the Internet
(and that figure of 20 million is pure speculation) there are millions of
people who use e-mail every day but never go near the Internet. They are
using 'office systems': mainframe dinosaurs like IBM PROFS or DEC
All-In-1, or LAN systems like cc:Mail or even Microsoft Mail. Outside
their own offices, these people's e-mail goes to other branches or
affiliates of their companies, or to supplier and customer companies that
they regularly work with. Their systems have directories where you find
your correspondent by name, and get the address without having to think
about it, or even see the format of the external address.
For their routine mail between companies, are these people using Internet?
No way, Jose. They don't want their mail ripped off by some hacker; and
they want their mail to get to its destination, or else they want to get a
message back saying that it hasn't. No Internet 'black holes' for them.
They are using X.400, because it offers security and reliability, and the
Internet doesn't. Most of them don't know, or care, that they are using
X.400: they just know that the mail gets through.
[OK, you can hack X.400 messages too. But to hack e-mail, generally you
need access to the switch. With X.400, there's no way to reach the switch,
as you can on the Internet, using standard tools that everybody has.
A bent telco employee can get in, just as he can tap your phone calls,
but that's a whole lot smaller risk.]
Now, that's fine for routine mail from you to the guy you talk to all the
time. But whatever X.400 was designed for, it doesn't work well for ad-hoc
mail to the guy who just gave you his business card, as Jim observes.
The address structure is logical, believe it or not, but it's too long and
messy. That's why any sensible company has an Internet gateway into its
internal mail network.
'Horses for courses'. X.400 does a good job in its place, the Internet
does a good job in its place. Their places are not the same.
Sorry, Jim, X.400 isn't going to go away. Reports of its death are much
exaggerated, just like your column.
John Stanning
stan...@well.sf.ca.us
>Erik
Erik,
I fully agree with this,
Maarten Verhaegh
Unisource
>Am I in it? Please find my X.400 address in it, OK?
Ok, "Arnt Gulbrandsen, Universitetet i Trondheim, NO"
textEncodedORaddress
/S=agulbra/OU=nvg/O=unit/PRMD=uninett/C=no/
mail
agu...@nvg.unit.no
>Are you in it? Tell me how I can find you in the directory.
Of course I'm in it! If you are in the Internet world there are
various telnet, gopher etc. gateways into the Directory. In fact
I noticed someone from U. Trondheim using the British telnet
gateway just now. But I'm not going to tell you how to use our
gateways as you should really use ones in Norway, especially if
you are going to look yourself up.
>X.400-84 is ten
>years old now and still the directory hasn't been implemented, is
>there any reason to believe it ever will be?
Yes, because it has been, see the QUIPU software and the Paradise
project. It has also been implemented commercially, not only as
an OSI application, but functionally in the form of Novell's NetWare
Directory Services (which is where my interest in X.500 comes from)
and (though I am not familiar with this) DEC's DECdns, which could
be gatewayed into the worldwide Directory.
Of course, the IP world recognised the need for a directory, by
providing the printed "Arpanet Directory" and WHOIS. But most
people would agree that this is completely inadequate for the modern
Internet; WHOIS is now only of specialist use. There are probably
already more Internet users with Internet e-mail addresses in the
pilot X.500 Directory than there are in WHOIS.
| again correct - a couple of years ago I was give the task of testing X.400
| I managed to send (without knowing any thing except that he worked for Hp and
| his name ) to a fiend at HP by using common sense and X.400 - I would not
| be able to do the same for RFC-822 some of my collegues have addresses like
| xx...@mupet.bt.co.uk or xxx.zoo.bt.co.uk
So how exactly do you figure out the values of ADMD, PRMD, DDA
(especially DDA!) ... using only common sense and X.400 ? :-)
| > Obviously the Directory has some way to go. But for someone
| > to write a speculative, non-technical, predictive article about
| > X.400 without mentioning the Directory _once_ is surely missing
| > the point.
I'm no expert on these matters, but isn't this the whole point -
Internauts are obliged to use the DNS in order to get any work done !
If use of X.500 was in some sense mandatory for X.400 systems ... ?
Just a thought !
Martin
But I assume they pay for their software. Is there a large market
for X.400 software?
--Arnt
Note, X.400 address.
>Ok, "Arnt Gulbrandsen, Universitetet i Trondheim, NO"
> textEncodedORaddress
> /S=agulbra/OU=nvg/O=unit/PRMD=uninett/C=no/
> mail
> agu...@nvg.unit.no
That's an SMTP address, not my X.400 address. I admit that my IP
provider runs a gateway. That you can find an SMTP address or use
various IP-based searching tools is of little importance, the
posting I replied to talked about the value of the directory for
X.400, not IP/SMTP.
>If you are in the Internet world there are
>various telnet, gopher etc. gateways into the Directory.
--Arnt
Finally, there is a bit of a contradiction in the Internet community,
as Peter Williams pointer out when this debate was held on a different
list. How can the Internet community clain the address format of
X.400 is bad when the same community comes up with the URL concept
http://web.nexor.co.uk/users/cjr/cjr.html
That has to be the most user unfriendly thing ever. Hosts are not
seperated from file names etc etc, BUT IT HAS BEEN ACCEPTED by the
community. Therefore I suggest the rumour that X.400 is dead because
the addressing scheme is naff, should also claim the WWW is extinct.
While the URL format is ugly, it is nowhere near as ugly and as
user-unfriendly as an X.400 address. For a start, there's only one way
to specify a URL. The format of an X.400 address tends to depend on
the UA/MTA being used: some use semicolons to delimit components,
other use slashes, etc etc. Not only that, the components in an X.400
are not intutitive - explain the difference between PRMD and ADMD to a
secretary or a beancounter - and some of them are optional or can be
left blank, making the whole thing inconsistent and hard to
understand, even for email-literate users.
Due to a bug in this PP version, it does not always do so (the
message Colin quoted used SMTP to get from Norway to the UK,
even though the message arrived in X.400; this is wrong)
About 95% of the members are listed using their Internet address,
either because that is what they gave me, or because I used their
FROM address field, and I am using an Internet UA.
Harald A
:Jim, you should know that what you see on the Internet does not represent
:all the traffic on the 'information highway' - only some of the flashier
:sports cars, the VM beetles, the RVs and the Greyhound buses. On other
:lanes of the highway there are trucks carrying goods, and sober
:businessmen's cars traveling from office to office. Unlike the other
:travellers, they are very quiet - unless you listen carefully, you don't
:hear them.
The Internet is becoming more ubiquitous -- people from diverse
information providers are listing their addresses in the Internet
canonical form, which in turn is influencing what happens on a more
internal level. Many people are clamoring for user@node and to be
able to hand out ONE address for internal and external concerns.
:OK, flight of fancy over. Besides the however-many people on the Internet
:(and that figure of 20 million is pure speculation) there are millions of
:people who use e-mail every day but never go near the Internet. They are
:using 'office systems': mainframe dinosaurs like IBM PROFS or DEC
:All-In-1, or LAN systems like cc:Mail or even Microsoft Mail. Outside
:their own offices, these people's e-mail goes to other branches or
:affiliates of their companies, or to supplier and customer companies that
:they regularly work with. Their systems have directories where you find
:your correspondent by name, and get the address without having to think
:about it, or even see the format of the external address.
There are lots of people who are Internet-addressable and don't
necessarily know it. Likewise, there are a number of people whose
email probably traverses some sort of X.400 gateway and they're not
aware of it. Figuring out the #s for anyone can be quite a task.
:For their routine mail between companies, are these people using Internet?
:No way, Jose. They don't want their mail ripped off by some hacker; and
:they want their mail to get to its destination, or else they want to get a
:message back saying that it hasn't. No Internet 'black holes' for them.
:They are using X.400, because it offers security and reliability, and the
:Internet doesn't. Most of them don't know, or care, that they are using
:X.400: they just know that the mail gets through.
Or, more likely, they are using some turd of a protocol which predates
X.400. And the concerns weren't so much about hackers as much about
what was around 5 and 10 years ago when these systems were set up.
:[OK, you can hack X.400 messages too. But to hack e-mail, generally you
:need access to the switch. With X.400, there's no way to reach the switch,
:as you can on the Internet, using standard tools that everybody has.
:A bent telco employee can get in, just as he can tap your phone calls,
:but that's a whole lot smaller risk.]
Or you need to hack the network that the email is on -- typically, a
much easier task with underwhelming physical security for systems.
:Now, that's fine for routine mail from you to the guy you talk to all the
:time. But whatever X.400 was designed for, it doesn't work well for ad-hoc
:mail to the guy who just gave you his business card, as Jim observes.
:The address structure is logical, believe it or not, but it's too long and
:messy. That's why any sensible company has an Internet gateway into its
:internal mail network.
What was X.400 designed for? People who really liked VMS qualifiers
and dd flags? Certainly, there's some good work to be found in the
X.400 specifications, and many people are taking advantage of that as
Internet email becomes extended. Are many people using the X.500
database services or their own proprietary database formats? :)
:'Horses for courses'. X.400 does a good job in its place, the Internet
:does a good job in its place. Their places are not the same.
Agreed. But there's a big difference between what its place is from a
technical perspective and what it's actually being implemented for.
...Mike
--
Michael J. O'Connor Internet: m...@dojo.mi.org (email address)
InterNIC WHOIS: MJO http://www.msen.com/~mjo/ (WWW home page)
"Ever notice how tense grown-ups get when they're recreating?" -Calvin
: But I assume they pay for their software. Is there a large market
: for X.400 software?
Yes, apparently there is. Harald Alvestrand's list of X.400 implementations,
posted regularly in this newsgroup (comp.protocols.iso.x400) lists
some 45 X.400 products. There must be a large market to attract
that many vendors.
John Stanning
stan...@well.sf.ca.us
This is fallacious reasoning.
The X.400 design suffers from the same afflication that a number of
standards efforts suffer(ed) from.
I heard quotes roughly like the following years ago, when X.400 was
being hammered out:
"The address format doesn't matter. The number of e-mail users is
becoming so large that nobody will be able to remember even simple
addresses, anyway, so vendors will have to implement their own
proprietary whizzy directory interfaces, and the addresses themselves
will be largely invisible."
paraphrased by me as:
"The interface doesn't matter. This is a standards effort -- only
functionality and interoperability matter. Usability is someone
else's problem."
Lyle.
Uh-oh. I'm starting to say things like "years ago" in reference to
this industry. I must be getting too old to hack.
Yes, you have to use that phone number as the target of a Directory
search of the phone number attributes of all the Stephen Bournes
at Bell Labs. That will tell you which one has that phone number,
and you can then extract their e-mail address. You could do exactly
the same thing to find out the SMTP address of someone who didn't
have that on their business card either.
If they had the same phone number, you could look at which
Organisational Units the two Bournes were in. If they were in
the same unit you could use the other attributes (e.g. job title).
If Bell Labs really did have two Steve Bournes doing the same
thing in the same group with the same phone number they would
probably make sure they each had their photo in the Directory!
It's a general problem. You are using the SMTP address not simply
as an easily-memorable mailing address but as a unique personal
identifier; perhaps the Steve Bourne who used to work here before
he worked at Bell Labs is 'srb1@bell...' and the other one is
'srb2@bell...'. Or perhaps one is 's...@beavis.bell...' and the
other is 's...@butthead.bell...'.
But if your naming policy is that people are not addressed by
their userid on a host system, but by personal name, you have
exactly the problem that you claim is specific to X.400.
The model where mail is addressed to user account ids on some
computer system is not sufficient any more. E-mail is now being
extended to people who don't have login accounts, e.g. there
are SMTP-to-fax gateways.
Addressing people by personal name may lead to duplicates; you can
reduce the frequency of duplicates by subdividing the name space
(and organisational units within an institution is a more intuitive,
certainly more browsable, way of doing this than the names of
machines which happen to be SMTP listeners) but there is always a
possibility that you will have to assign people arbitrary unique
identifiers. If you have a general solution, there are lots of
people who would like to hear it.
> For their routine mail between companies, are these people using Internet?
> No way, Jose. They don't want their mail ripped off by some hacker; ...
> They are using X.400, because it offers security and reliability, and the
> Internet doesn't. Most of them don't know, or care, that they are using
> X.400: they just know that the mail gets through.
X.400: So secure that an X.400 mailer won't even talk to another X.400
mailer from a different vendor.
You get your choice: security or interoperability. Pick one.
--
Tom Fitzgerald 1-508-967-5278 Preserve our electronic natural heritage!
Wang Labs fi...@wang.com Save the endangered line-eater!
Lowell MA, USA Send $$ to the "Line-Eater Preservation Society" Today!
I stand by it, and will try to explain it a bit more fully.
If you follow the References header a few steps back, you will find
an article (message-id <ag129.125...@ucs.cam.ac.uk>) which
argued that the following methods were adequate to find an X.400
address:
> (a) selecting you from my online address list
> (b) if you weren't in that, by looking you up in the Directory
I disagreed, and said so, in no uncertain terms. Until someone
manages to unearth my X.400 address (which may or may not be
possible, I've no idea about that) I'll continue to disagree. That
it's possible for me to add my SMTP address to the directory is
irrelevant: I could add my SMTP address but didn't even know what
its X.400 form was. If I weren't able to add my real-X.400 address
to the directory, and it wasn't added automatically, I don't think
relying on the directory and one's personal address list is
sufficent: One has to use an address format that humans can remember
and type in.
--Arnt
Not to pick nits, but he _did_ supply an X.400 address, apparently
generated from the RFC822 one you supplied (unless you did give an X.400
format address, which apparently you didn't). However, it does lack an
ADMD-field; according to TelePost Comm. this should be /ADMD=uninett/ but
I have seen /ADMD= / in some papers from UNINETT themselves (our network
provider, UNINETT, is not a CCITT/ITU-T member). Perhaps Harald Alvestrand
can give the correct answer? :-)
Plus, unless your MUA accesses the DS for you, you will still need to type
in the X.400 address manually. Do anyone know of any such integrated
products?
Unless X.500 deployment and usage becomes more integrated with MUAs, the
X.400 addressing system will remain less user-friendly than the RFC822
form.
- Tor Iver
X.400 isn't primarily an address format, it's a mail transfer
protocol. (Actually I'm not certain that X.400 even specifies a
single address format.)
Three people found an X.400-format address for me, but since the MTA
there runs only SMTP and I didn't know what X.400 address I was
registering I don't think that supports the original argument (that
X.500 is sufficient to locate X.400 users). They'd need to locate an
address whose MTA uses X.400 as mail transfer protocol to support
that.
Kudos to Uninett for running gateways, but if X.400 is just an
alternative notation for SMTP addresses, it's dead and buried
already.
--Arnt
Maybe because such a trivial model of files is only applicable
to one or two very simple filing systems (e.g. Unix and MS-DOS).
Or are you asking for full FTAM functionality to be replicated in
X.400?
>That's an SMTP address, not my X.400 address. I admit that my IP
>provider runs a gateway.
For your information, my SMTP address is gatewayed into something
not unlike X.400 (Coloured Books actually). I still have an SMTP
address (which SMTP users can use), just as you have an X.400 address
(which X.400 users can use).
The point is that contrary to what people unfamiliar with the
Directory are arguing, those users don't have to remember a complex
X.400 address, they can just look you up in the Directory.
If your commercial provider is credible they should be able to guarantee
that routes over their networks are as safe as the PTT's. Remember that
the big commercial internet providers work to standards as high as if not
higher. Ultimately you have other big problems with X.400 based mail -
notably if the other end of the link is on the real internet its going
to pass the internet anyway. Good backbones from all sources use scrambling
these days, and if your data is valuable in an email then that should be
encrypted.
Alan
--
..-----------,,----------------------------,,----------------------------,,
// Alan Cox // iia...@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
``----------'`----------------------------'`----------------------------''
> But I have. Look in the Directory under "Gulbrandsen, U. Trondheim,
> Norway".
How do I get to this directory? Is there a mailserver that takes requests?
Do I need to come up with an X.400 address to talk to that mailserver?
--
Peter da Silva `-_-'
Network Management Technology Incorporated 'U`
1601 Industrial Blvd. Sugar Land, TX 77478 USA
+1 713 274 5180 "Hast Du heute schon Deinen Wolf umarmt?"
OS/2 files with extended attributes?
>, Unix, NT, VMS,
VMS files with version numbers?
>"trivial" model would be somewhat useful in 90%+ of the systems out
>there. Have you ever tried using cc:Mail, MS-Mail, MHS, or any other
>LAN package?
Yes, and I said the DOS filing system was relatively trivial.
>I'll admit there are some systems that require a bit more to usefully
>transfer files - Macintosh for example. Ideally, these systems should
>be supported as well. In fact, the LAN packages I mentioned above support
>Macintosh files, by encoding them in AppleSingle or MacBinary format!
Fine, now tell us how you would encode an MVS partitioned dataset
or VSAM dataset. There are schemes for transmitting such files but
they are defined by IBM specifically for the purpose and are not
applicable to e.g. Macintosh files.
Yes, it is possible to think up ways to encode structured files as
a linear sequence of octets. What is difficult is representing
structured files in a way which will be intelligible on more than
one kind of system. That is what open systems is all about. If you
want a file attachment scheme that will only work from XXX to XXX
then you should use a private arrangement (e.g. say "this body part
is in NETDATA or MacBinary or SIDF format"); it is no business of
X.400 to define the individual formats.
Believe me, a lot of people have given a lot of thought to this,
not only for file transfer but for system-independent backup formats,
programming language design etc. It is not at all trivial. Possibly
there is scope for an X.400 body part that represents a linearised
sequence of FTAM requests and responses (or, perhaps, just the requests
and an indication of where to send them to when you wanted the data)
but there would be no sense in making it any less powerful than that.
If you think otherwise perhaps you could give us the ASN.1 for an
IPMS body part capable of carrying DOS and Macintosh files plus
associated directory information.
Our product X.400 MUA has exactly this feature, there are about 6 ways you
can input an address.
1. You can select one from your personal address book (the most common way
used by far).
2. You can type in the X.400 in the /= or ;= format if you wish.
3. You can use a template editor to prompt you for each field such
as admd surname etc.
4. You can type in an RFC-822 address, and it will convert it into an
X.400 address.
5. You can type in an X.500 DN, or and X.500 search expression, and if
it hits an X.500 entry with an X.400 ORName attribute, it will use that.
6. You can use it in conjunction with a more powerful DUA and a Cut/Paste
mechanism allows one button press to transfer the info from the DUA to the
X.400 UA.
In this way, there is little to worry about the X.400 addressing. You
can always type in the address if you like doing that sort of thing,
but most sane users either store it from incoming messages, or from the
directory and use their personal address book with their favourite
nickname for that person after the inital contact.
So essentially it doesn't really matter what the address looks like,
you mostly won't use it directly anyway.
Julian.
FTAM? Lord, no - I think I was pretty clear in saying that I would just like
some basic functionality, such as preserving a file name. Applicable to
only one or two very simple filing systems? Hmmm...
DOS, OS/2, Unix, NT, VMS, etc. etc. etc. - seems to me that this
"trivial" model would be somewhat useful in 90%+ of the systems out
there. Have you ever tried using cc:Mail, MS-Mail, MHS, or any other
LAN package? If you attach a file, "readme.txt", to a message, it shows
up to the recipient as "readme.txt". Is it so much to expect something
that simple from X.400?
I'll admit there are some systems that require a bit more to usefully
transfer files - Macintosh for example. Ideally, these systems should
be supported as well. In fact, the LAN packages I mentioned above support
Macintosh files, by encoding them in AppleSingle or MacBinary format!
In my earlier statement I was not so much trying to point out a flaw in the
X.400 specs. as I was pointing out the difficulties that are cropping up
in implementation. The externally defined body part in the '88
standards has lots of potential for handling the problem, but is it
useful today? No! Why? Because there is no consensus among
implementors.
Take a look at how X.400 UA vendors handle binary file attachments.
From what I have seen, most of them throw it in as a body part 14, in
which case the recipient gets no information about the file. Some of the
vendors are nice enough to include a manifest, and can even make the
transfer transparent, as long as sender and recipient are both using that
vendor's UA package.
But isn't the point of a standard like X.400 to create a vendor independent
environment?
And I could just hop in the Transporter and beam over to give you my
message in person. The problem is that the Transporter does not exist,
and neither does the Directory. If X.400 can survive long enough for
X.500 to come to fruition, it stands a chance. Otherwise - hasta la
vista.
I never said that the standard should be extended - X.400 already has
created the framework to do this with body part 15. It's up to the
implementors to agree on a uniform set of object identifiers, and
standard ways to represent the data for different objects.
As to your suggestion about a private arrangement - are you suggesting
that as a X.400 user I would have to contact someone in advance of
sending them a Macintosh file to setup a special arrangement? If so,
it won't work in practice. It is simply too much trouble for end users
and system administrators.
Sure, open systems is the goal, but are you suggesting we prevent users
from getting a very simple capability because we can't find a way to
make a file sent from system XXX intelligible to a user on system ZZZ?
What's wrong with coming up with standard object identifiers and formats
to represent DOS files, Macintosh files, VSAM datasets, etc? If the
recipient's UA can't read it, then too bad! At least the object
identifier gives them a clue as to what it was they couldn't read.
I'll give you an example of what I'm talking about. Using today's X.400
software, if user A using vendor Y's s/w sends a AppleSingle encoded
Macintosh file to user B who has vendor Z's product, the file will
typically show up as a bp-14. User B will have no clue what the file
is, unless user A was kind enough to include a description. If the file
was sent as a bp-15 with a (hypothetical) AppleSingle object identifier,
then user B would at least know what he/she received. User B may or may
not be able to do much with the file from there, but at least he/she is
pointed in the right direction.
If you look at the computer market, most people are using Mickeysoft DOS
and Windows. Most of the rest are split between Macintosh, OS/2, and
various flavors of UNIX. These people could care less about VMS, MVS,
etc. Why not address the immediate needs of these people, and take more
of an evolutionary approach towards open systems. The first step is to
come up with a standard way to identify and represent different types of
data that are being transferred. The next step is to address conversion
of that data between dissimilar systems. I do not believe we should
hold up the first step just because the second step is unsolved.
The EMA is already addressing the problem with the file transfer body
part. However, it will be some time before this is implemented and
available to users. My concern over the future of X.400 is whether or
not problems like this one can be solved in time to save it from
oblivion.
What Arnt is getting at is that he is actually *using* a *real* X.400
system somewhere, and that *nobody
is able to locate his X.400 address there.
(I have a sneaking suspicion that it *might* be possible using the
World Wide Web, strangely enough....I will check that later....)
At least, that is what I read as him saying!
Harald A
I have no idea what is the most appropriate route into the pilot
directory that I and Mr Gulbrandsen and 350,000 other people are in,
for commercial Internet users in Sugar Land, Texas. The gateways
I use are in the UK (of course) and are based on Telnet, Gopher etc.
Try exploring gopherspace.
A mail server wouldn't really be adequate to support interactive
browsing and searching of the Directory.
Yes but that's like saying there could be multiple worldwide DNSes
and you are only sure of getting the IP number you want if you look
up in the right set of nameservers. This is true, but not useful
to 99.99% of users, who see only one DNS. Similarly the majority
of people will see only one Directory.
>
>We can leave it to the net to decide who's collection of cards is more
>representative of business card email addresses.
>
Neither I would suggest, as Nexor is obviously involved in the
X.400 world and the academic world is very much into RFC-822.
Of the cards I have that have that have E-Mail address at all
it is about 50/50 with those form the Academic world, software
and networking type companies and various US organisations being
RFC 822 and other, mainly non US corporates being X.400.
I would also say that it totally irelevant, since both are out
there and if you want to communicate with a given community
you need the tools to do the job, wither it be X.400/Internet
or both.
Why not just get on with it and built the necessary gateways and
directories instead of arguing the toss all the time?
Roger
--
+----------------------------+---------------------------+
! roger killick ! Voice: +44 1260 28 3620 !
!----------------------------+---------------------------!
! roger....@siecon.co.uk ! Fax: +44 1260 28 3501 !
+----------------------------+---------------------------+
>
>If X.400 is so bad, how comes the mhsnews distribution list
>itself is an X.400 based list gatewayed to the Internet!?!
>
>This begs another question - how many poeple are using X.400 but do
>not realise it?
>
>Colin
>
Certainly most of my users do not know or care what they
are using. The site is X.400 and the users therefore have
an X.400 address, and we use a gateway at EUNet for RFC-822
which does the conversion, incoming and outgoing. The address
below is mapped with fields to the left of the @ being passed
across as Given name/Surname and the fields to the right
mapped via a look up table to the relevant P, OU1, A and C.
It works fine and gives access to all of the communities with
whom we want to communicate.
In general, only the X.400 address is on business cards, although
for people who deal with the Internet community, they also
have their RFC-822 address on the card. I might add that both
fit on the front of the card quite happily.
I feel that there are too many people in this forum telling other
people what they should and should not be using, or justifying
why they are using whatever.
In the real world you use whatever tools are relevant to a
particular job. In the case of EMail this may be RFC-822 or
it may be X.400 or as in our case it might be both. What
is the problem with that?? Lets just get on with it and ensure
that relevant gateways and directory systems are put in place.
Should I just reply or x-post this to ABOI.humor :-)
I spent quite a long time, about 18 months, testing X.400 inter conections
for BT I never found ANY X.400 systems that I did not recomend for interconection.
now admitedly some subs^H^H^H^H prmd operators coundn't be trusted to run a bath
let alone an email system :-)
and some X.400 implementations wern't as good as others sprint had some problems with
delivery reports(this may well have been fixed by now)
Rgds Maurice
Just because whoever mainains the other mailsystem you are using
do not provide directory functionality does not make X.400 not support
X.500 or vice verca.
Its like sayning that because somebody is sending mail from
a machine without DNS support SMTP does not support DNS.
Hans Petter Holen
Obviously you haven't read the 1993 standards - they do *exactly* that!
Harald T. Alvestrand
>Maybe because such a trivial model of files is only applicable
>to one or two very simple filing systems (e.g. Unix and MS-DOS).
>Or are you asking for full FTAM functionality to be replicated in
>X.400?
Actually the byte-stream model of files is being supported by more and
more operating systems, because it is the only way to have a file
format that is common to all environments. I recall that some years
ago I found that VAX/VMS, that bastion of record-oriented files, not
only introduced a 'stream-LF' format (UNIX-like byte stream with
linefeed assumed to terminate lines of text), but had the undocumented
property of actually being able to execute such a file, if it contained
an exact copy of an executable file.
I suspect that OS developes who refuse to support byte-stream files
will eventually find themselves byte-streamed out of existence by their
competitors. (A big three-letter company comes to mind.) If the X.400
developers don't support byte-stream files they too will not survive
the global revolution towards common formats.
There are only two universal formats for data:
1. For text files, lines of text separated by a newline, where
'newline' is preferably one character, but could be a sequence
such as 'CR LF'.
2. For binary files, a stream of n bytes.
There is nothing trivial about a simple universal format. In fact the
rarity of the UNIX-style files in older operating systems suggests that
the UNIX inventors showed insight that was relatively rare in those
days. It takes talent to keep things simple. Even the MS-DOS and
SMTP/telnet guys, despite having access to the UNIX model, made a big
boo-boo by using CR LF to separate lines, thus condemning generations
of programmers to be eternally fixing one another's code.
--
Rahul Dhesi <dh...@rahul.net>
I certainly agree that having the users see only one X.500 directory is
the goal in most cases. My point, which may not have been clear enough,
is that I doubt we are there *today* - ie. I doubt that there exists
*one* worldwide interconnected X.500 infrastructure today which contains
a significant amount of all reachable X.400 addresses.
Steinar Haug, SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steina...@runit.sintef.no
Harald A
There are at least two places that run public access points via telnet
to the PARADISE Directory service.
1) ds.internic.net - login as guest
2) nameflow.dante.net - login as dua
Colin
I should have added, X.500 is also available via the WWW, try
http://web.nexor.co.uk/osi/x500/x500.html
which will give you links to several gateways.
Colin
I should have added, X.500 is also available via the WWW, try
> I have no idea what is the most appropriate route into the pilot
> directory that I and Mr Gulbrandsen and 350,000 other people are in,
> for commercial Internet users in Sugar Land, Texas. The gateways
> I use are in the UK (of course) and are based on Telnet, Gopher etc.
> Try exploring gopherspace.
How do I do that over UUCP?
> A mail server wouldn't really be adequate to support interactive
> browsing and searching of the Directory.
Therefore an addressing scheme that requires realtime access to the
Directory to be useful is not adequate to support electronic mail.
> I heard quotes roughly like the following years ago, when X.400 was
> being hammered out:
>
> "The address format doesn't matter. The number of e-mail users is
> becoming so large that nobody will be able to remember even simple
> addresses, anyway, so vendors will have to implement their own
> proprietary whizzy directory interfaces, and the addresses themselves
> will be largely invisible."
This is obviously stupid.
Firstly, it means that each installation needs to administer its own
address database. This may be possible for a big organisation, though
its is clearly a waste of resources. For a PC user it is totally
impractical as the user is the only person who could do the
administration, and if they have to know both the real address and
their private abbreviation why not simply use the real address always.
Secondly, the experience with telephone numbers, which most people
don't remember, proves that such an address is quite acceptable to the
vast majority of people.
--
Charles Bryant (c...@chch.demon.co.uk)
Very true. My own collection, skipping cards with no relevance, counts 9 with
internet, 13 with X.400, 9 with both, 3 with other types, and at least 80
without any email address at all. The cards represent all kinds of companies
and positions.
-- Vennlig hilsen / Kind regards
Bj|rn Myrstad
UNINETT postmaster
>How do I do that over UUCP?
No idea. How do you do anything useful over UUCP?
>> A mail server wouldn't really be adequate to support interactive
>> browsing and searching of the Directory.
>Therefore an addressing scheme that requires realtime access to the
>Directory to be useful is not adequate to support electronic mail.
This is a complete non-sequitur. Realtime Directory access is no
more of a problem than realtime DNS access. I was talking about the
application-layer gateways provided for those in the Internet world;
while there are gateways based on e-mail, obviously gateways with a
telnet or gopher interface are better for interactive browsing.
>or are you just being silly? `only applicable to Unix and MS-DOS' is
>more than enough compatibility nowadays. certainly more than `none'.
No I'm not being silly, I write (among other things) MVS systems
software for packing up arbitrary datasets into linear files for
transfer to dissimilar systems, and utilities for unpacking the
files on those systems. I have a direct interest in this area and
I know it's not as trivial as you say it is.
But even Unix-to-MS-DOS interchange has problems with line boundary
translation (i.e. text vs. binary). And what about Macs?
In my opinion (which is very humble), Nexor is involved in the X.400 world
and also involved in the RFC-822 world
and the fax world
and the cmail world
and the decnet world
and the microsoft world etc.
Each of these have their pros and cons.
Each of these live and will live for decades to come.
None of them are making out their wills and preparing to be buried six
feet under.
Why are people arguing why my favorite protocol is better than your protocol ?
I don't care how a message got to me as long as it got to me
(and is readable by me (maybe only me - security))
(and contains all the information or links to the information the
person sending it wanted me to see)
And as Roger said
> Why not just get on with it and built the necessary gateways and
> directories instead of arguing the toss all the time?
It would be more profitable to discuss how I can get my favorite
protocol to talk to your protocol.
Having said the above, I'll now go on and argue the toss for a
bit :-) Please skip the rest !
As for addressing, whether its a fax number, an x400 address or an 822
address, does it matter. Its just a string !
It may be longer in some worlds
e.g x400 > RFC 822 (usually)
but then it may be more understandable in some worlds
e.g ignoring ADMD and PRMD which are unnecessary red tape and
reflects the composition of the commitees who produced the x400
standard - in my opinion - well if its got the service providers
name in there somehow, its advertising that providers and its
going someway to guarantee that message going to that address will
go through the provider and hence get it some money
explaining to a non technical person that
I=p;S=cowen;O=Nexor;PRMD=Nexor;ADMD= ;C=GB; is I = Initial, S =
Surname, O = Organisation and C= Country is a lot easy than
explaining that
p.c...@nexor.co.uk the @ symbol is special and somehow separates
the person's machine from his name and that . is also special and
separates different components with nexor being his organisation,
co being something else and uk being his country.
As for address discovery.
If you have a good UA (Julian Onions advertised Nexor's product in a
previous post so I won't bore you with the details), getting an
address from a business card is simply typing in a given string and
your UA should be clever enough to cope with the main formats.
Otherwise you have to go looking for it.
The x500 is built for browsing and can hold any info you want, so can
be applied to all worlds (in my opinion)
The DNS which some people are touting as being equivalent to x500 in
the x400 verses RFC 822 battle. Could someone tell me how people can get my
address from the DNS ? How can you browse the DNS ?
Now my preferred solution for address discovery is something like
directory enquiries, I get someone else or something else to find the
address for me. Wonderful.
Peter
PdS> Therefore an addressing scheme that requires realtime access to the
PdS> Directory to be useful is not adequate to support electronic mail.
AG> This is a complete non-sequitur. Realtime Directory access is no
AG> more of a problem than realtime DNS access.
The DNS requires a usable nameserver to *resolve* the address. (In
general, this requires about the same level of connectivity as final
delivery does.)
X.400 requires a usable Directory to *form* the address.
--
Christopher Davis * <c...@kei.com> | "It's 106 ms to Chicago, we've got a full
http://www.kei.com/homepages/ckd/ | disk of GIFs, half a meg of hypertext,
* MIME * PGP * WWW * [CKD1] * | it's dark, and we're wearing sunglasses."
| "Click it." -- <blue...@bluesbros.com>
> >How do I do that over UUCP?
> No idea. How do you do anything useful over UUCP?
(long angry reply pointing out what an arrogant twit this bloke is deleted)
UUCP is just a transport mechanism. It is, however, a remarkably economical
one, due to its inherent batching. For a *whole* lot of people, including
virtually everyone outside the first world (which is most of the population
of the planet, mind you) you're lucky if you can get decent voice capability
and a lot of places are restricted to periodic radio links. UUCP works just
fine for that.
There are dozens of other batched protocols that are even cheaper and less
capable than UUCP. They also support electronic mail just fine.
> >> A mail server wouldn't really be adequate to support interactive
> >> browsing and searching of the Directory.
> >Therefore an addressing scheme that requires realtime access to the
> >Directory to be useful is not adequate to support electronic mail.
> This is a complete non-sequitur. Realtime Directory access is no
> more of a problem than realtime DNS access.
Realtime DNS access is not required for electronic mail.
> I was talking about the
> application-layer gateways provided for those in the Internet world;
The Internet world is a tiny fraction of the electronic mail world. An
electronic mail addressing standard that only works for the Internet is
useless.
> while there are gateways based on e-mail, obviously gateways with a
> telnet or gopher interface are better for interactive browsing.
"better"
Yes, I suppose an interactive mechanism is better than an non-interactive
one for an interactive activity. The thing is, you shouldn't need to perform
that interactive activity to send mail. Mail is inherently batch.
> The Internet world is a tiny fraction of the electronic mail world.
I'd be very much surprised if the exact opposite were not true. However,
in no way does it make up a tiny fraction of overall email.
> An
> electronic mail addressing standard that only works for the Internet is
> useless.
But Internet standards work for The Internet, and company, institution and
government networks using TCP/IP. Moreover, Internet standards for Email
are most often used for email that is delivered via UUCP.
Companies like Siren have built gateways that create interoperability
between Internet-based email and PC LAN email systems.
Unlike many of the folks that would point out the above, I have worked
intimately in the X.400 and private email domains.
<> Lee D. Rothstein | L...@VeriTech.com | 603-424-2900 | Fax: 603-424-8549 <>
<> VeriTech | 7 Merrymeeting Drive | Merrimack, NH 03054-2934 | USA <>
<> Information Technology (IT) Verification & Leadership <>
While this is flame bate I will respond, as I am open minded and if
anyone can tell me how I can acheive the same level of
functionality using X.400 I am more than willing to give it a try
to compare it with my current UUCP setup.
I currently run UUCP on my laptop computer acting as a store and
forward system to send/receive Internet email and USENET newsgroups
in fact if it wasn't for UUCP I wouldn't be able to communicate with
the others in this and the other thousands of newsgroups, let alone
private email. I guess I'd call that useful.
The real beauty which I have found from UUCP is I don't actually
have to be connected into anything at when I want to read and
respond to messages. The fact is that at the moment I'm not
connected to any LAN's or the like at the moment however I am still
participating in this discussion and the hundread or so other
threads I am currently involved with.
The major advantage of being 'not connected' is that I can be
sitting in an aeroplane, ship, car or wherevere, and I can still
continue with my regular correspondance, I still recive
comp.protocols.iso.x400 and can make meaniful, :-), additions to the
discussions I am involved with.
The next time my plane lands or my ship is in port or I am near a
telephone I can plug in and download the 100 or so messages I have
composed which then get sent out to the various USENET newgroups and
email addresses I have specified. Now I call that useful.
As I said I am open minded, and if anyone can show me how to
achieve a similar level of functionality under X.400 I'll give it a
go, but I haven't been able to find anything suitable.
As a side issue there are a whole range of freeware/shareware
products which will allow me to acheive this functionality using
UUCP.
What products are the for X.400 that cost the same and will
give me the same level of functionality (Email & USENET news)?
Mark
---
Mark Purcell (016) 282 926 Australian Public Access Network Association
m.pu...@pos.apana.org.au Queries in...@apana.org.au (auto-reply daemon)
m.pu...@navy.gov.au http://www.apana.org.au/apana (06) 285 1701
X400:"DDA.RFC-822=m.purcell(a)pos.apana.org.au;O=AARN;A=TELEMEMO;P=OZ.AU;C=AU"