X.500, Naming and the Internet

[[e-mail]]

For the past few months, there have been numerous conversations
on the subject of naming things in the DIT. I would like to try
again to settle the issue, as I want to do some things which assume
some sort of resolution, even if only interim resolution, of the
naming issues.

>From my point of view, there are actually a number of issues that
need to be resolved. They are as follows:

	(1) Scope of the Directory
	(2) Model of the DIT
	(3) Construction of RDNs
	(4) Sharing the namespace

This list is not exhaustive, of course, but most discussions on the general
subject of naming seem to revolve around (2) and (3). However I'd
like to bring up (1) and (4) also as I regard them as being fundamental
to the issue of naming.

(1) Scope of the Directory
--------------------------

I would like to explicitly settle the question of what the
scope of the Directory that we are trying to build is. Implicitly,
I think all the piloting activity that has been going on has been
building towards the idea of a global, all-encompassing Directory
that will be *the* world's Directory, not *a* Directory for the
use of the Internet.

I believe that a global Directory, as opposed to an Internet
Directory is a Good Thing. The utility of a Directory increases
in proportion to the amount of information it provides access to,
so in this case bigger is better. However, in working towards
this larger goal, realize that some additional conflicts arise,
most notably (for the purposes of this message anyway) in
how to share the namespace with other communities.

This begs the question of whether we want to *address* all
the world's problems, or concentrate on *solving* the Internet's.
While I'm certainly in favor of the latter, I am *not* in favor
of a solution that will forever preclude the rest of the world.
And to avoid an isolationist solution, I think we should at
least keep in mind that the universe of the Directory extends
beyond the boundaries of the Internet.

In fact, I'm so much in favor of a global Directory that I am
going to assume it for the rest of this message :-) :-).

But one way or another, based on this message and the discussion
that will undoubtedly ensue, I think we need to explicity decide
what we're trying to build.

(2) Model of the DIT
--------------------

At the highest, most conceptual level, I think that there are at least
two ways of modeling the DIT: as a registration hierarchy, and as
a listing hierarchy.

Briefly, a registration model of the DIT is one where the operators
of the Directory serve a second function, as registration
authorities. In this model, the Directory operators are free
to structure their namespace in whatever manner they like, because
*they* are the registration authorities, so *they* get to assign/structure
(distinguished) names however they please.

In contrast, a listing model of the DIT is one where the operators
of the Directory are just service providers, with the DIT
serving to reflect (but not necessarily mirror) the structure
imposed by existing (external) registration authorities. In this
model, Directory operators are constrained to use names derived
from the assignments made by registration authorities: they
cannot arbitrarily construct names, so they cannot arbitrarily
structure the DIT either (since the structure of the DIT is reflected
in names).

I will argue here in favor of the listing model on the grounds that
the registration model does not scale. First of all, a registration
hierarchy requires that Directory operators be accepted as registration
authorities for all users of the namespace. While this seems to be
the case now, I will argue that this will no longer be the case once
the Directory consists of more than a number of pilots.

Also, more fundamentally, a registration hierarchy assumes a tight
coupling between the DIT and registration authorities. In the context
of the Internet, this is not necessarily unreasonable. The Internet
today has in place a well-accepted 'real' registration authority
in the form of the IANA. In the future, the ISOC could also serve
as a registration authority of sorts. So, in the context of the Internet,
the registration model is not necessarily unreasonable: get an
Internet registration authority to manage the toplevel of the
DIT and delegate authority from there. This approach has certainly
worked well enough in the past with the DNS (different registration
authority, I know, but it's the same principle), so why fix something that
ain't broke??

Why? Because of the assumption made that the Directory is global,
not Internet-centric. This makes it very fundamentally different
from the DNS. There is no reason why the DNS shouldn't be controlled
by Internet registration authorities: it's intended scope is the
Internet. But because of the more global nature of the Directory,
what's good for the DNS is not necessarily good for the Directory.
It is unlikely that Internet registration authorities will be
acceptable to the larger Directory user community outside of the
Internet.

In fact, it is unlikely that *any* single registration authority
will be acceptable to all Directory users. And therein lies
the flaw in the registration model: it binds registration authority
to the DIT so tightly that there *has* to be a single registration
authority controlling the top of the DIT.

In contrast the listing model circumvents (or "slimes out of", depending
on your point of view :-)) the problem by not attaching any
registration semantics to the DIT at all. So whatever existing,
commonly accepted, registration authorities can continue to function
(including the Internet registration authorities, in the case of
Internet-specific things), and the DIT will just reflect the
registrations made. This not only avoids the problem of who
controls what from the point of view of the Directory user/operator
community, but also avoids the problem of who has the *right*
to control what. If users don't like the registration authority
claiming control over a portion of the namespace, they can take
it up with the authority: regardless, the Directory continues to
function.

The listing model also avoids the more sticky problem of context
in names. The registration model requires that the Directory
operator make the claim that it will register a name for use
in the Directory. Notice the latter part of that statement:
"for use in the Directory". Context has just been added to the
name! Operators of a Directory structured by the registration
model certainly cannot claim the right to register names for
use outside the Directory, and therefore are limited to
registering names for use in the Directory, if they do any
registration at all.

Why are context sensitive names bad? In my opinion, context-sensitive
names defeat the purpose of the Directory, to map from "common
names" to the cryptic stuff that passes for names in various
contexts. If you add context to Directory names, you have just
created the need for a service to map from "common names" to
Directory names: a directory of Directories so to speak. This
is self-defeating.

Also, I'd like to point out that the listing model does not preclude
the use of the registration model for certain subtrees. Nothing
in the listing model prevents the existence of a subtree where
it just so happens that the Directory operator and the registration
authority are one and the same. The converse is not true: the
registration model does not allow the separation of registration
authority functions from the functions associated with Directory
operation.

(3) Construction of RDNs 
------------------------

The algorithms used to construct RDNs is very tightly tied to the
model of the DIT as discussed in (2). Basically, in the registration
model, the Directory operator (in its capacity as registration
authority) is a god for all intents and purposes, and is thus
free to construct RDNs however it pleases. So, schemes involving
nicknames, abbreviated names and so on are perfectly acceptable:
after all the scope of use of the name is confined to the Directory,
so it really doesn't matter if someone/something chooses to
register under a variation of its legal name, or even under a name
that is outright assumed.

Things are very different with the listing model, in two major
ways. First of all, since the DIT is only reflecting existing
registrations, listings in the DIT *have* to be under the names
registered: no nicknames, abbreviations, etc. This, I will
argue, is a good thing. Legally registered names are exactly that:
legally registered. So there can be no conflict in the Directory
over which of two entities that wish to be listed should list under
a given name: the entity that has registered the name with the
appropriate registration authority gets to list under it in the
Directory. In a global Directory, this is crucial: commonly accepted
name abbreviations and nicknames in one community may not be so
commonly accepted (or may mean different things) in other communities.
In a Directory that transcends any single user community, the
use of anything other than a legally registered name must be prohibited
as a enormous source of conflict.

Secondly, the listing model differs from the registration model
in that it does not constrain entries to be listed where they
would naturally occur as a result of registration. With the listing
model, the approach is taken that entries are listed where searches
would expect to find them, not necessarily where registration would
normally place them. As a result, RDNs may be constructed in such
a way as to appear 'unnatural' in normal X.500 terms. Whether the
placement of entries in other than their natural places, and the
resulting 'unnatural' RDNs is a 'bug' or a 'feature' of the listing
model is open to discussion.

(4) Sharing the namespace
------------------------- 

With the assumption of a global Directory comes the implication that
the DIT namespace needs to be shared with authorities outside of the
Internet. To date, piloting activities have been Internet-centric
in making unstated assumptions that the Internet is, for all intents
and purposes, the universe. So, we've done things like place
the top-level of the DNS under the root with no indication in the
way the top-level domains are named that they are Internet-centric.
Similarly with the naming of DSAs in quipu-based pilots.

I will argue that this practice cannot continue: whether the
DIT is modeled as a registration hierarchy or a listing
hierarchy, no Directory provider outside of the Internet would
consent to the way we've placed Internet-centric things in such
a way that they have global scope.

Instead, I would like to propose the following:

	- the official sanctioning of o=Internet (or cn=Internet,
	  or addmd=Internet) at the root. I believe that
	  a very strong argument can be made to non-Internet
 	  Directory-operarators that the
	  Internet is a truly international entity, and
	  therefore deserving of being listed (or
	  having a registration point) directly under the root.

	- the placing of all Internet-centric information under
	  o=Internet. This would definitely include the DNS,
	  and may possibly include the quipu DSAs (there are a
	  few other considerations there).

	- assuming that consensus is for the listing model
	  as I presented it, the development of a naming scheme
	  for naming Internet-centric things in the Directory
	  so that they can be listed outside of o=Internet.
	  This could take the form of additional sections in
	  OSI-DS 12.

Whether we run the tree under {o,cn,addmd,whatever}=Internet
as a registration hierarchy or a listing hierarchy is another issue.
I lean towards having it be a listing hierarchy, relieving the
existing pilot operators of the registration function, and handing
registration authority to some 'official' Internet authority.
But it *is* another issue.

... So, do I get a prize for what must be one of the longest messages
ever sent to osi-ds?? :-) :-)


Wengyik