Re: X.500, Naming and the Internet

[[e-mail]]

> You did send a long message, but I think that your distinction between
> "registration" and "listing" is very valid. 

I think we're using the word "listing" with two different meanings.
When I used "listing" in my message, I was referring to the act
of reflecting existing registrations in the DIT.

You appear (please correct this if its wrong) to be using "listing" in
the context of obtaining a dump of a portion of the DIT.

> I would remark however that you have not pushed your reasoning to the
> extreme: you seem to assume that the only thing you need for a name is
> "legal registration", it order to guarantee its uniqueness.

This is more or less correct. I was pushing the task of guaranteeing
uniqueness to the registration authority. Since the Directory is
just a reflection of existing registrations, if the registration authority
ensures uniqueness, it follows that the names that occur in the DIT
will be unique also.

> We should start to use caching, for one thing.

I agree, but that's an implementation/operational decision.

> The keys should be short because they are used in many places;
> they should be hierarchic in order to facilitate
> navigation; being mnemonic would help, but they dont have to be meaningful.

You seem to be implying here that we are free to make up the names/keys
ourselves. This is the exact opposite of what I'm proposing. I'm
proposing a model (the listing model) where the DIT only reflects
existing name assignments. Directory operators cannot make up their
own names.

> In fact, a numeric hierarchy, similar to the OID hierarchy, would do quite
> well -- or why not just reuse the DNS allocated names!

For the purposes of the DNS tree under o=Internet (or wherever it is)
sure, I agree. But not for the existing geographical/civil naming
structure being used for white-pages applications. The geographical/civil
naming structure should reflect civil name assignments: the ISO
two-letter country names, the national registries (if they exist),
state/locality registries etc.

> X.500 tries to solve (2) by organizing a hierarchy of DSA, and Steve tries
> to save the world by using the UFN algorithms to browse this hierarchy. But
> there is absolutely no reason why "listing" should be constrained to a
> hierarchy

I think the examples you give are all perfectly valid. However I don't
see how UFN fails to address them.

A flat space is just a special case, a one-level hierarchy.

> Using an SQL or X.500 search would return a set of
> responses, which can include the "registered names" of the selected entries.

No. In your terminology, what I'm suggesting is that the database keys
be the "registered names" themselves. As I said in my original message,
this is the only way to guarantee uniqueness among names in a namespace
shared by multiple registration authorities. Otherwise, the representation
of names from one authority could conflict with the actual names from
another authority. For example, if we decide to shorten "Performance
Systems International" to "PSI" for use in the Directory, how do
we differentiate between my employer and "Plumbing Systems Incorporated".
Who gets to use "PSI as the "database key" in the Directory?

I'm proposing that we avoid the right to use issue altogether in the
Directory by getting out of the registration business.

> Indeed, some details will have to be ironed out, e.g. a standard way to
> represent the "registered names" by using something similar to the "Alias"
> attribute,

No. I disagree with this. We don't need a standard way to mutate "registered
names". We need to use the "registered names" themselves.

> and also a way to provide "additional information", e.g. the
> address of a DSA serving a name. 

I like the QUIPU scheme (masterDSA, slaveDSA) a lot, conceptually.

> But I believe that splitting apart
> "registration" and "listing" is a very good idea.

Do you still agree with me after reading this message?
We were talking at cross-purposes before due to the different
ways we were using the word "listing".


Wengyik