Rep : overloading cn= in the DIT

[Alain Zahm <[e-mail]>]

> I'm doing alpha work for somebody on X.500 based
> routing for X.400 -Neccessitates making suitable
> data be present in the directory.
> 
> cn=AnimalName was nice for a pilot, but is a major
> bummer in the context of a real-world global tree.
> cn=MhsMtaName is just as crocked.
> 
> People, ordinary people, have no idea that the global
> namespace means that an object called cn=George could
> be any of:
> 
>    a DSA
>    a person
>    an MTA
>    an arbitrary object co=erced into cn= form
> 
> I think this is a chronically bad way to name objects
> in the global DIT. cn= should be reserved for one, and
> only one kind of naming instance, and more appropriate
> nameforms should be used to identify and RDN/DN instantiate
> things of a different context.
> 
> now I've finished my diatribe, somebody shoot me down in flames.
> Please do not include any statement of the form:
> 
>    but its specified in the standards...
> \
> 
> -George

The wish is good, the solution seems inadequate.

   Of course its necessary to have a name "easy to deduce", the problem
then is not located on the attribute side but on the value side. Even if
you define an attribute dsa, how can I deduce the associated value ?
The search operation won't be facilitate.
   On the other hand if we choose to impose the use of the cn attribute
which value must be of the form "xxx-dsa" you will solve the problem
without creating an attribute duplicating the class information for each
kind of object.

Alain Zahm