Xref: utzoo comp.misc:3189 comp.std.misc:56 comp.mail.misc:1204 Path: utzoo!attcan!uunet!husc6!cmcl2!nrl-cmf!ames!pasteur!ucbvax!decwrl!labrea!polya!cayuga!andy From: andy@cayuga.Stanford.EDU (Andy Freeman) Newsgroups: comp.misc,comp.std.misc,comp.mail.misc Subject: Re: Standardizing Email? Message-ID: <3714@polya.Stanford.EDU> Date: 24 Aug 88 06:25:33 GMT References: <788@vsi.UUCP> <79700010@p.cs.uiuc.edu> <304@pvab.UUCP> <26196@think.UUCP> Sender: news@polya.Stanford.EDU Reply-To: andy@cayuga.Stanford.EDU (Andy Freeman) Organization: Stanford University Lines: 31 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