Re: X.500, Naming and the Internet

[[e-mail]]

To: [e-mail], [e-mail]
Subject: Re: X.500, Naming and the Internet 
Bcc: 
Reply-To: [e-mail]
In-reply-to: Your message of Tue, 04 Feb 92 09:08:17 +0000.
             <[e-mail]> 
--------
> I dont quite follow you with your discussion on "civil names". I really dont
> see why directory names have to be civil names.

Let me distinguish two cases here: when we're not naming civil things
(such as when we're naming application entitities), there is no reason
to use civil names.

But, for the reasons below, I will argue that civil things should be named
(listed) with their officially registered names. So France should be listed
as c=FR, and not whatever its ISO assigned oid is.

> Directory names are keys in
> the directory information tree, and that is all. They dont have to be exact
> copy of civil registries, but they have to be convenient and efficient keys.

I think I finally understand what you've been trying to get across
all along :-). You're taking a utilitarian view of DNs, that they
serve only as database keys, and nothing else.

I have to disagree. I believe that DNs should be as self-explanatory
as possible. While I realize that the whole concept of DNs being 
"user-friendly" (hah! :-)) is a contradiction in terms, I am going to
argue here that as best as possible we should try to preserve the
self-documenting qualities of our current DNs. So c=FR is preferable
to subidentifier=<some number>, as o=Performance Systems International
is preferable to o=PSI.

To justify my position, let me assert that at the highest level,
the purpose of directories is to map from things people know, such
as commonly accepted names, to things that people don't know. If you
accept this, then putting non-commonly-known things like oids (or
object descriptors) into DNs is self-defeating. Doing this makes
it necessary to create a directory to map from the commonly-known
names people do know to DNs, which is silly.

True, even with oids as DNs, the Directory can fulfill its mapping function
since the 'search' operation is not limited to examining distinguished
attributes only. However 'search' is not the only legal operation
allowed in the Directory. A significant use of the Directory today
is the browsing of the data in there. I do not believe that this
will ever change. Sure, as the data set grows, doing things like
"list all immediate subordinates of c=US" will become untenable,
but there will always be a demand for "show me all entries that fulfill
criteria X, then let me decide which one I want to look at some more
based on the names of the various entries". Basically, as long
as there is a large community of people who want to "look around", 
as opposed to finding specific things (and I believe that there will
always be such a community), it will be to the advantage of the
DIT to be as self-documenting as possible.

> >You're not suggesting we use OIDs in RDNs are you?
> OIDs are probably the most convenient ways to express an RDN and avoid to
> mix it up with civil registration, trade mark claims and the like. I was
> actually not thinking of using the OID as RDN, but rather the OID
> components, i.e. something like:
> 
> 	<DN: INT=1; INT=3; INT=250; INT=2; CN=Christian Huitema;>

What can I say? Aaaarrrrgggghh!! :-)

Seriously though, I beg you reconsider. By creating ugly keys you
are making orphans out of all those people that like to browse through
the Directory.


Wengyik