[comp.std.misc] Standardizing Email?

mikej@dasys1.UUCP (Mike Johnston) (08/14/88)

Where can one find the X.400 "standard" documented?

+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
! Michael R. Johnston - Franchise Data Specialist , Career Employment Svc.!
! UUCP: {cmcl2!phri,uunet} dasys1!cpmain!mikej    ATNET: mikej@cpmain.uucp!
! PHONENET: (516) 285-7730 "....but it was working just yesterday......"  !
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+

roy@phri.UUCP (Roy Smith) (08/15/88)

dts@cloud9.UUCP (Daniel Senie) writes:
-> There is a standard called X.400, which is the Message Handling Systems
-> standard. It allows dissimilar machines to exchange and transport mail.

I thought that was what RFC-822 was all about.  Silly me.
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"

andy@cayuga.Stanford.EDU (Andy Freeman) (08/16/88)

In article <3437@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
>dts@cloud9.UUCP (Daniel Senie) writes:
>> There is a standard called X.400, which is the Message Handling Systems
>> standard. It allows dissimilar machines to exchange and transport mail.

>I thought that was what RFC-822 was all about.  Silly me.

Yes, silly you.  They're looking for "future" standards, not standards
that have been used for many years.  If it predates the vax, it doesn't
count.

Does anyone how Europe's bold leap into the 60s a couple of summers
ago came out?  (ISO was advertising an experimental mail system
between dissimilar hosts, probably based on an X.400 predecessor.  We
stupid Americans had been doing that for years.)

-andy
UUCP:  {arpa gateways, decwrl, uunet, rutgers}!polya.stanford.edu!andy
ARPA:  andy@polya.stanford.edu
(415) 329-1718/723-3088 home/cubicle

jon@chiron.UUCP (Jon L. Griffeth) (08/16/88)

As I begin, I would like to state that I am neither an expert, nor
VERY well read on this subject.  The following is the result of the
short period (short for what this subject requires) I spent delving
into this subject.

First, RFC 821 and 822 are industry standards.  X.400 is an international
standard being produced by CCITT and ISO.

The technical specifications can be obtained from OmniCom Publications (???).
I don't currently have the address, but I may be able to locate it quickly
enough.  They're somewhere in Virginia.

X.400 is actually a series of recommendations made by CCITT concerning
the format of electronic messages and their subsequent transmission.
It references numerous other recommendations and relies heavily
on the Abstract Syntax Notation 1 (ANS.1).  If anyone can tell how
to obtain information on ANS.1, I'd be greatful.  I seem to have missed
it in my search.

A (possibly incomplete) list of recommendations for X.400 include:

	X.400, X.402, X.403, X.407, X.408, X.411, X.413, X.419,
	X.420 etc. etc. etc..

In addition, you'll need recommendations X.208, X.217, X.218, X.219 and
probably a host of others.  I didn't have that much time to spend on
it and eventual gave up (for now).

The 1984 release is called the "Red Book".  The 1988 release, called the
"Blue Book," is not currently available (or wasn't the last time I heard,
which was about two months ago).  You shouldn't expect to see it until
sometime next year.  A draft version is out, but only to selected groups.

The "Blue Book" is MUCH more extensive than the "Red Book".  Also, the
authors seem to have taken a perverse pleasure in making it as unreadable
as possible (in my opinion).

I had a lot of hope for X.400.  However, after hearing some comments 
("X.400 is the SNA of electronic mail"), I'm no longer sure.

Jon L. Griffeth
jon@chiron.UUCP

P.S.  If anyone can direct me towards a GOOD book on OSI, I would
again be greatful.  OSI is the basis for an international networking
standard.  Anyone wanting to learn about X.400 should learn this as
well.

jrmacmillan@watdragon.waterloo.edu (John R. MacMillan) (08/16/88)

In article <3611@polya.Stanford.EDU> andy@cayuga.Stanford.EDU (Andy Freeman) writes:
|Does anyone how Europe's bold leap into the 60s a couple of summers
|ago came out?  (ISO was advertising an experimental mail system
|between dissimilar hosts, probably based on an X.400 predecessor.  We
|stupid Americans had been doing that for years.)

Keep in mind that they don't really have much choice; if they come up
with something and then "you stupid Americans" do it differently, they
are essentially steam-rollered into changing.
-- 
John R. MacMillan
jrmacmillan@dragon.waterloo.edu		If the universe fits, wear it.
...!watmath!dragon!jrmacmillan

rsalz@bbn.com (Rich Salz) (08/16/88)

In comp.mail.uucp (<145@chiron.UUCP>), jon@chiron.UUCP (Jon L. Griffeth) writes:
>First, RFC 821 and 822 are industry standards.  X.400 is an international
>standard being produced by CCITT and ISO.
Not quite.  The TCP/IP protocol suite was developed for the Department of
Defense by an independent group of scientists and researchers.  No one
computer vendor had any particularly strong hand in their development.
The DoD suite has become an industry standard because it is a set of good,
solid protocols that have been worked on by a large number of highly
intelligent people.  They wanted something practical, and they did many of
the first implementations themselves.  The analogy to the early days of
Unix (V7) is striking.

The ISO mail and communications standards are being defined by an
international body, whose representatives are primarily the national
phone companies.  This is a broad generalization, and somewhat unfair,
but it's good enough.  Technical competence and practical solutions
have not been shown to be primary concerns.
	/rich $alz
-- 
Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.

karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (08/16/88)

jrmacmillan@watdragon.waterloo.edu writes:
   Keep in mind that they don't really have much choice; if they come up
   with something and then "you stupid Americans" do it differently, they
   are essentially steam-rollered into changing.

How is that?  RFC821 and RFC822 are dated August 1982, which predates
(I believe) X.400.  Within the US, RFC822 is quoted as The Truth of
Mail Formats rather often, but it's being somewhat ignored (it seems)
by X.400 people.

Someone across the cubicle wall just speculated the X.400 constitutes
an extreme case of NIH syndrome.

Food for thought, and
open to correction,
--Karl

davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/17/88)

There are several standards, and probably all will be used for at least
the next few years.
  RFC822 - specifies a message content (header and text)
  SMTP - a protocol for connecting two machines for text transfer.
	(Simple Mail Transfer Protocol)
  X.400 - another content specification

Many sites speak SMTP and RFC822, X.400 is less popular in the USA, and
I have reason to believe that there are a lot of buggy implementations
which won't talk to one another.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

guy@gorodish.Sun.COM (Guy Harris) (08/17/88)

> jrmacmillan@watdragon.waterloo.edu writes:
>    Keep in mind that they don't really have much choice; if they come up
>    with something and then "you stupid Americans" do it differently, they
>    are essentially steam-rollered into changing.
> 
> How is that?  RFC821 and RFC822 are dated August 1982, which predates
> (I believe) X.400.

I think the problem here is that Mr. MacMillan completely misunderstood the
comment from Andy Freeman:

	|Does anyone how Europe's bold leap into the 60s a couple of summers
	|ago came out?  (ISO was advertising an experimental mail system
	|between dissimilar hosts, probably based on an X.400 predecessor.  We
	|stupid Americans had been doing that for years.)

Mr. Freeman's comment wasn't that "we stupid Americans" had somehow
"steam-rollered" Europe into picking up something that we "did differently".
His comment was that "we stupid Americans" had come up with a mail system that
worked between dissimilar hosts, long before ISO had ever done so - in fact,
the Arpanet supported this *before* the advent of RFC821 and RFC822 - and that
*ISO* had "done it differently".

The result may well be some "steam-rollering" to get the SMTP users to change,
thus somewhat *reversing* the situation Mr. MacMillan appears to be complaining
about.

barmar@think.COM (Barry Margolin) (08/17/88)

In article <145@chiron.UUCP> jon@chiron.UUCP (Jon L. Griffeth) writes:
>  If anyone can tell how
>to obtain information on ANS.1, I'd be greatful.  I seem to have missed
>it in my search.

I believe ANS.1 is described in X.409, "Message Handling Systems:
Presentation Transfer Syntax and Notation".  However, it never
actually seems to use the phrase "Abstract Syntax Notation", nor the
abbreviation ANS.1.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

marc@apollo.COM (Marc Gibian) (08/17/88)

Having spent some significant time working with mail systems, and most recently X.400,
I feel I need to put my two cents into this discussion.

The two major distinctions between the familiar RFC822 mail standard and X.400 to me
seems to be:

1)  Technology - X.400 uses a technological approach to information exchange that is
    very different from that used by RFC822.  The X.400 approach is closely matched
    to the facilities and concepts provided by the OSI model.

2)  Functionality - X.400 defines a very robust message passing capability that addresses
    the current and future needs of the computing community.  It incorporates facilities
    for dealing with many message contents, not just simple text, acknowledging that
    mail is no longer made up on simple text.  In this world of graphics, voice mail,
    and complex structured documents, it is very nice to have a standard that provides
    a path to providing a mail facility that permits exchange of these things.

One final comment. X.400 is complex, and not the easiest to read.  But I have found it
to be one of the better on the international standards in terms of readability,
completeness, and extensibility.  I look forward enthusiastically to using an
X.400 based mail system and only wish it would arrive sooner.

Marc S. Gibian
email:  marc@apollo.com    or   marc@apollo.uucp

jrmacmillan@watdragon.waterloo.edu (John R. MacMillan) (08/17/88)

In article <64445@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes:
|I think the problem here is that Mr. MacMillan completely misunderstood the
|comment from Andy Freeman:
|
||Does anyone how Europe's bold leap into the 60s a couple of summers
||ago came out?  (ISO was advertising an experimental mail system
||between dissimilar hosts, probably based on an X.400 predecessor.  We
||stupid Americans had been doing that for years.)

So I did.  I thought he meant "they're doing it the _same way_ we did
it years ago", and felt that this was not too surprising. I didn't know
that the ISO had come up with something different (which seems incredibly
silly until you remember that we're talking about a committee :-)

|Mr. Freeman's comment wasn't that "we stupid Americans" had somehow
|"steam-rollered" Europe into picking up something that we "did differently".

I think I've been misunderstood too; I didn't mean that the US actively
coerces the rest of the world, merely that it is such a large user/
producer/developer/etc that the rest of the world had better go along
or they'll lose out.
-- 
John R. MacMillan
jrmacmillan@dragon.waterloo.edu		If the universe fits, wear it.
...!watmath!dragon!jrmacmillan

mohsen@iconnect.UUCP (Mohsen Banan) (08/18/88)

In article <145@chiron.UUCP> jon@chiron.UUCP (Jon L. Griffeth) writes:
>
> ....
>The 1984 release is called the "Red Book".  The 1988 release, called the
>"Blue Book," is not currently available (or wasn't the last time I heard,
>which was about two months ago).  You shouldn't expect to see it until
>sometime next year.  A draft version is out, but only to selected groups.
>
>The "Blue Book" is MUCH more extensive than the "Red Book".  Also, the
>authors seem to have taken a perverse pleasure in making it as unreadable
>as possible (in my opinion).
>
>I had a lot of hope for X.400.  However, after hearing some comments 
>("X.400 is the SNA of electronic mail"), I'm no longer sure.
>
>Jon L. Griffeth
>jon@chiron.UUCP
>
>P.S.  If anyone can direct me towards a GOOD book on OSI, I would
>again be greatful.  OSI is the basis for an international networking
>standard.  Anyone wanting to learn about X.400 should learn this as
>well.

I have read a few books on the subject. My favorit is:

Standards for Open Systems Interconnection.
McGraw-Hill Book Company
ISBN 0-07-035119-8
Authors:
Keith G. Knightson
Terry Knowles
John Larmouth

In general my problems with many books on this subject is that
I don't trust them. 
Most often the best source is the IS standards themselves.
If you are just getting started, ISO7498 (X.200) is the best starting place.

My two cents about X.400:
It is real. It is here now. It addresses all of today's needs and some
of tomorrow's.
We'll see its wide spread use in the US in early 1990s.

P.S.
When are the Blue Books going to be ready?

kehres@tis.llnl.gov (Tim Kehres) (08/18/88)

In article <25924@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) writes:
: 
> I believe ANS.1 is described in X.409, "Message Handling Systems:
> Presentation Transfer Syntax and Notation".  However, it never
> actually seems to use the phrase "Abstract Syntax Notation", nor the
> abbreviation ANS.1.

ASN.1 has evolved from 1984 X.409.  The most current documents that
I have on ASN.1 are ISO 8824 (DIS) and ISO 8825 (DIS).  The specification
of ASN.1 will no longer be part of the X.400 series of recommendations.

Tim Kehres

nigel@modcomp.UUCP (Nigel Gamble) (08/18/88)

in article <145@chiron.UUCP>, jon@chiron.UUCP (Jon L. Griffeth) says:
> X.400 is actually a series of recommendations made by CCITT concerning
> the format of electronic messages and their subsequent transmission.
> It references numerous other recommendations and relies heavily
> on the Abstract Syntax Notation 1 (ANS.1).  If anyone can tell how
> to obtain information on ANS.1, I'd be greatful.  I seem to have missed
> it in my search.

Abstract Syntax Notation One (ASN.1) is part of the Presentation Layer
(layer 6) of the ISO/OSI 7 layer comms. protocol stack.  The relevant
ISO standards are:
	DIS 8824	Specification of Abstract Syntax Notation
			One (ASN.1)
	DIS 8825	Specification of Basic Encoding Rules for
			Abstract Syntax Notation One (ASN.1)
The corresponding CCITT document is:
	X.409		Message Handling Systems: Presentation
			Transfer Syntax and Notation
(ISO documents can be obtained from the American National Standards
Institute (ANSI), which is the United States member body in the
International Organization for Standardization (ISO).)

> P.S.  If anyone can direct me towards a GOOD book on OSI, I would
> again be greatful.  OSI is the basis for an international networking
> standard.  Anyone wanting to learn about X.400 should learn this as
> well.

The best book I have found (from which the above information is taken)
is "Handbook of Computer Communications Standards, Volume 1: The Open
Systems Interconnection (OSI) Model and OSI-related Standards" by
William Stallings, published by Macmillan.
-- 
Nigel Gamble            "Everything should be made as simple as possible,
MODCOMP/AEG              but not simpler."  Albert Einstein.
uunet!modcomp!nigel

bar@dpmizar.sw.Datapoint.COM (Brian Ruptash) (08/18/88)

>	DIS 8824	Specification of Abstract Syntax Notation
>			One (ASN.1)
>	DIS 8825	Specification of Basic Encoding Rules for
>			Abstract Syntax Notation One (ASN.1)

IS 8824 and 8825 are now full-fledged International Standards.  IS 8824
was published on 87.12.15, IS 8825 on 87.11.15.  They should be
available from your ISO member body (ANSI in the U.S., SCC in Canada).
IS 8824 corresponds to JTC1/SC21 N2159, and IS 8825 to N2160, so if you
already have those, you can save the fortune the national member bodies
charge for the final ISs printed in Geneva...

> P.S.  If anyone can direct me towards a GOOD book on OSI, I would
> again be greatful.  OSI is the basis for an international networking
> standard.  Anyone wanting to learn about X.400 should learn this as
> well.

Stallings is OK, but by far the best one I've found is "Standards for
Open Systems Interconnection", by Keith Knightson, Terry Knowles and
John Larmouth, McGraw-Hill, 1988 (ISBN 0-07-035119-8).  These guys are
all key participants in the ISO and CCITT work, representing a
cross-section of all the activities, and most certainly know their
stuff.

There have been several tutorials produced by the ISO/IEC JTC1 SC21
working groups on their respective projects; you may want to get a hold
of those as well.

-- Brian

mikulska@beowulf.ucsd.edu (Margaret Mikulska) (08/21/88)

In article <20063@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes:
>
>How is that?  RFC821 and RFC822 are dated August 1982, which predates
>(I believe) X.400.  Within the US, RFC822 is quoted as The Truth of
>Mail Formats rather often, but it's being somewhat ignored (it seems)
>by X.400 people.
>
Well, how about RFC 987 (and 1026, addendum to 987) which is entitled
"Mapping between X.400 and RFC822" ?


Margaret Mikulska

Department of Computer Science and Engineering, C-014
Institute for Nonlinear Science, R-002

University of California    |	ARPA	: mikulska@cs.ucsd.edu
			    |		  mem@inls1.ucsd.edu
at San Diego	            |	UUCP	: sdcsvax!mikulska
			    |   BITNET	: mmikulska@ucsd.bitnet
La Jolla, CA 92093    	    |   voice 	: (619) 534-1452

campbell@maynard.BSW.COM (Larry Campbell) (08/21/88)

In article <3437@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
}dts@cloud9.UUCP (Daniel Senie) writes:
}-> There is a standard called X.400, which is the Message Handling Systems
}-> standard. It allows dissimilar machines to exchange and transport mail.
}
}I thought that was what RFC-822 was all about.  Silly me.

RFC822 is incredibly primitive.  It has no provisions for encoding
messages with multiple parts.  It has no notion of different content
types -- everything must be 7-bit ASCII.  It provides no way to
encapsulate a message within a message.  It has no provisions for
non-English messages -- you must use 7-bit U.S. ASCII, and if your
language uses accented or non-Latin characters, tough.

It is nearly impossible to layer a real office automation system on
top of RFC822, as there is no _standard_ way to mail binary files,
revisable form documents, images, etc. etc.

RFC822 (nee RFC733) was OK in 1973, but by now we should be eager
to toss it out and move on to something with reasonable functionality.
-- 
Larry Campbell                                The Boston Software Works, Inc.
Internet: campbell@bsw.com                  120 Fulton Street, Boston MA 02109
uucp: {husc6,mirror,think}!maynard!campbell         +1 617 367 6846

henry@utzoo.uucp (Henry Spencer) (08/23/88)

In article <1101@maynard.BSW.COM> campbell@maynard.UUCP (Larry Campbell) writes:
>RFC822 is incredibly primitive.  It has no provisions for encoding
>messages with multiple parts.  It has no notion of different content
>types -- everything must be 7-bit ASCII.  It provides no way to
>encapsulate a message within a message.  It has no provisions for
>non-English messages -- you must use 7-bit U.S. ASCII, and if your
>language uses accented or non-Latin characters, tough.
>
>It is nearly impossible to layer a real office automation system on
>top of RFC822, as there is no _standard_ way to mail binary files,
>revisable form documents, images, etc. etc.

And it's quite impossible, of course, to *layer* a standard for such things
on top of RFC822?  (Of course, it's much more *interesting* to invent a new
standard from the ground up, rather than adhering to silly, old-fashioned
ideas like building on others' work and maintaining compatibility, but adults
supposedly are capable of doing what's right, not just what's fun.)
-- 
Intel CPUs are not defective,  |     Henry Spencer at U of Toronto Zoology
they just act that way.        | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

john@basser.oz (John Mackin) (08/23/88)

In article <145@chiron.UUCP> jon@chiron.UUCP (Jon L. Griffeth) writes:

> P.S.  If anyone can direct me towards a GOOD book on OSI, I would
> again be greatful.

`The Elements of Networking Style', by Padlipsky.

John Mackin, Basser Department of Computer Science,
	     University of Sydney, Sydney, Australia

john@basser.oz.AU (john%basser.oz.AU@UUNET.UU.NET)
{uunet,mcvax,ukc,nttlab}!munnari!basser.oz!john

andy@cayuga.Stanford.EDU (Andy Freeman) (08/24/88)

In article <26196@think.UUCP> barmar@kulla.think.com (Barry Margolin) writes:
>In article <304@pvab.UUCP> robert@pvab.UUCP (Robert Claeson) writes:
>>What does an X.400 address look like?
>
>If you're asking what the equivalent to user@domain and
>host!host!...!user is, there isn't really such a thing, since X.400 is
>not a textual protocol.  Both messages and the the message-transfer
>protocol are binary, based on structured objects.

>		but this form of ambiguity is not possible in
>X.400 because there is no parsing involved (except, perhaps, by the
>user application used to create mail, but that's not the problem of
>the mail transfer protocol).

I sure hope this doesn't mean that x.400 doesn't define a canonical
textual representation of addresses.  I rarely use a mail system to
give addresses to other people and quite often, I don't even use a
computer.  If x.400 addresses don't have a standard text format,
they're useless for business cards, phone conversations, magazine
articles, etc., and they require special handling for databases.

Maybe it is time to extend 822; the conforming implementations work
and its problems with non-conforming implemenations are no worse than
X.400's will be.  (Even if there's a PD X.400 implementation, there
are a lot of people who won't run it even if you cut them off if they
don't.)

-andy
UUCP:  {arpa gateways, decwrl, uunet, rutgers}!polya.stanford.edu!andy
ARPA:  andy@polya.stanford.edu
(415) 329-1718/723-3088 home/cubicle

jim@cs.strath.ac.uk (Jim Reid) (08/24/88)

In article <1423@basser.oz> john@basser.oz (John Mackin) writes:
>In article <145@chiron.UUCP> jon@chiron.UUCP (Jon L. Griffeth) writes:
>
>> P.S.  If anyone can direct me towards a GOOD book on OSI, I would
>> again be greatful.
>
>`The Elements of Networking Style', by Padlipsky.

Well said!

		Jim

The
inews
50%
rule
is
a
pest
sometimes
-- 
ARPA:	jim%cs.strath.ac.uk@ucl-cs.arpa, jim@cs.strath.ac.uk
UUCP:	jim@strath-cs.uucp, ...!uunet!mcvax!ukc!strath-cs!jim
JANET:	jim@uk.ac.strath.cs

"JANET domain ordering is swapped around so's there'd be some use for rev(1)!"

marc@apollo.COM (Marc Gibian) (08/24/88)

In article <3714@polya.Stanford.EDU> andy@cayuga.Stanford.EDU (Andy Freeman) writes:
>In article <26196@think.UUCP> barmar@kulla.think.com (Barry Margolin) writes:
>>In article <304@pvab.UUCP> robert@pvab.UUCP (Robert Claeson) writes:
>>>What does an X.400 address look like?
>>

<a number of comments and questions regarding addresses in X.400>

The addresses to be used in delivering an X.400 letter are specified
as X.400 Originator/Recipient names, commonly refered to as O/R names.
The available variants (according to my red book, granted a bit out
of date) are:

variant 1:
                Country name
                Administration domain name
                [Private domain name]
                [Personal name]
                [Organization Name]
                [Organizational Unit Names]
                [Domain-defined attributes]

Note - at least one of private domain name, personal name, organization name and 
organizational names must be selected.

variant 2
                Country name
                Administration domain name
                UA unique numeric identifier
                [Domain-defined attributes]

variant 3
                Country name
                Administration domain name
                X.121 address
                [Domain-defined attributes]

I will not expand upon the individual fields, please look at your X.400 standard to
find that information.

I would observe that a lot of the details are left to the implementation of the
user agent (UA), though if I remember properly everything is intended to be entered
as pretty flexible text.

One other note on this topic.  There is a related standard, X.500, which addresses
networked directory services.  This is far beyond what the current RFC based mail
systems can do as this provides a way to complete addresses, find addresses, and
so on.  The identification scheme described by the standard provides a way of
generating a unique address for every item of data in the world, including
people.

Marc S. Gibian
email:  marc@apollo.com

barmar@think.COM (Barry Margolin) (08/24/88)

In article <3714@polya.Stanford.EDU> andy@cayuga.Stanford.EDU (Andy Freeman) writes:
>I sure hope this doesn't mean that x.400 doesn't define a canonical
>textual representation of addresses.  I rarely use a mail system to
>give addresses to other people and quite often, I don't even use a
>computer.  If x.400 addresses don't have a standard text format,
>they're useless for business cards, phone conversations, magazine
>articles, etc., and they require special handling for databases.

Sorry, but they don't.  There is nothing in X.400 regarding the user
interface to the mail system, nor does it ever even mention business
cards.  It is a standard for communication between computers.  If
magazine/journal editors want to come up with a standard printed form
for X.400 addresses, that is fine, but it should not be part of the
computer protocol standards.

By the way, I don't recall any place in RFC-822 where it specifies a
representation of addresses for use on business cards, either.  The
user@host form is only recommended for use internally by the mail
protocols; if an implementation chooses (as most have) to use it in
the user interface, that's the implementor's choice, neither
encouraged nor discouraged by the standard.  For many years I have
been using a system (a close relative to Unix) where one types
"send_mail user -at domain", because we felt that it would be more
appropriate to use the standard control argument syntax and also
because @ is the default line-kill character.  The read_mail command
on this same system displays addresses in the header as "user at
domain" because we feel it is a better human interface, and messages
are even stored this way in mailboxes.  The user@domain syntax is ONLY
employed when the message is sent out over the network.  Many other
mail system implementors have taken the easy route of using RFC-822 as
their user interface, taking advantage of the fact that RFC-822 was
designed to be human-readable.

I imagine that a typical mail-sending interface on an X.400 system
would use a form-filling interface.  It would let you fill in all the
fields you know, and if you've specified a complete enough set it will
then proceed to send the message.  Remember, one of the goals of X.400
addressing is that you NOT be required to use computer-specific
addresses, but just give an ordinary postal address (many of the X.400
designers work for European PTTs).  And even if you do have to use
machine addresses (for instance, until Directory Services is
implemented), there is no real need for a canonical representation.  A
business card could say "User BARMAR on ARPANET host THINK.COM"; in
fact, I expect that the old BARMAR@THINK.COM syntax might continue to
be used.  Someone actually sending mail would then translate that to
the appropriate syntax for their system.


Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

robert@pvab.UUCP (Robert Claeson) (08/29/88)

In article <3e0ccda9.166d8@apollo.COM>, marc@apollo.COM (Marc Gibian) writes:

> >>In article <304@pvab.UUCP> robert@pvab.UUCP (Robert Claeson) writes:
> >>>What does an X.400 address look like?

> The addresses to be used in delivering an X.400 letter are specified
> as X.400 Originator/Recipient names, commonly refered to as O/R names.
> The available variants (according to my red book, granted a bit out
> of date) are:

Ah, thank you for that answer to my question. Now I know...