Re: Three revised Internet Drafts

[[e-mail]]

> I just wanted to point our that if the only think that externally
> distinguishes the two formats is the separator, then users will be lost, and
> will use one for the other. If distinction is what you need, then you should
> rather enforce it. Something like <DN: bla, bla, bla> vs <X400: ...>.
> 
> It is easy to explain why X.400 1984 ORNames and X.500 Names look the same.
> The idea in 81-82 was that the ORNames would be exactly directory names --
> hence the attribute structure. ADMD and PRMD were latter introduced to
> facilitate routing in the absence of directory, but all other standard
> attributes were designed to be keys in a local directory. A remainder of this
> is the "ambiguous address" non delivery report code: an address cannot be
> ambiguous, only a name can!

Christian:

A fine piece of information that makes a lot of thing clearer to those
of us out here on the sidelines.

Given that we are already working on a draft for using the X.500
directory to resolve X.400 routing, is it at all possible that we
work on re-unifying the two address spaces?  Once we get the X.500
directory deployed, the ADMD and PRMD objects can either be buried
in the internals, or discarded altogether.

Let's face it - we're discussing what is basically a "user interface"
issue - internally, it's all going to be ASN.1 and OID values anyhow.
And the best user interface (in my opinion, anyhow) would be one
in which ONE syntax specified ONE object, and the *SYSTEM* would
figure out what was intended based on context.  It is simple for
the system to determine based on context whether an X.400 or X.500
identifier is called for - I forsee that in general, an X.500 object
would be specified, and if it's e-mail, the ADMD and PRDM will be
filled in from someplace (probably the directory).

First law of interface design: Don't make the user do something that
the computer can do better...

I of course recognize that re-unification of the X.400 and X.500
address spaces probably has political implications on the same
order of magnitude as re-unification of the two Chinas.  Oh well... ;)

				Valdis Kletnieks
				Computer Systems Engineer
				Virginia Tech