Re: people CN

[Tim Howes <[e-mail]>]

> From:    [e-mail]
> To:      [e-mail], [e-mail]

> solution a):
> ------------
> 
> 	cn=Jacques Martin 2, O=FooBar, C=FR
> 
>  Is the one being used today by those that have given attention enough
> to the probleme to produce a "rule" for people naming.

This is basically the solution we use at UM.  We only use the number
appended form if a conflict has occurred, though, which means most
people don't have to worry about it.

>  -> easy to manage
> 	(need for a proper sequence number allocation procedure)

True.  The number allocation procedure is trivial.

>  -> not really respecting X.500 "spirit"
>  -> not elegant

True.  But we got over that.  What is the point of adhering to the
spirit of X.500 if it does not lead to a solution that works?  Ditto
for elegance.

>  -> not confortable for people having to exchange their CN

I'm not sure I know what you mean by this.  Some people are not wild
about having a number appended to their name, but when they understand
what it's for they generally don't object.  If they change their name,
they their DN is going to change anyway (and so might the number).

The real question is what difference does it make to the user?  Our
experience has been that the answer is "none".  Our users do not really
care what their DN is, nor should they.  UFN buys us that, so I can
be known as "Tim Howes, University of Michigan, US".  I argue that nobody
needs to know that I am really "cn=Timothy A Howes, ou=Information
Technology Division, ou=Faculty and Staff, ou=People, ou=University of
Michigan, c=US".  If some user agent forces a user to deal with DNs, or
only produces DNs (or RDNs) when I have to choose between two or more
entries, that's bad.

>  -> the CN is not enough for human user discrimination, need to "see"
> 	more attributes values.

I don't think it's possible for a DUA to know ahead of time what
attributes a user will need to disambiguate between people with
the same name.  Maybe I know the address, maybe I know what they
do for a living, maybe I know only their favorite drink.  How does
choosing one extra attribute arbitrarily to be part of the RDN
solve the problem?  Agreed, it may help in 80% of the cases or more,
but who's to say?

> from the first category  -> proposal b1)
> ----------------------------------------
>   the additional attribute is meant to be easy to read/remember for
>   a human being (thus the description of role position within the
>   organisation)
> 
> 	cn=Jacques Martin + Role=Director, O=FooBar, C=FR
>   or
> 	cn=Jacques Martin + Desc= Le petit gros muscle, O=FooBar, C=FR
> 
>  -> this may ease interactive usage
> 
>  -> BUT
>      - this does not provide for a generic scheme for disambiguanting
> 	people entries,
> 	+> I need to write down a simple and stable rule, and I would hate
> 		to regulate what is in a "Description" attribute
> 		to enforce rules over a Role attribute that would not
> 			be only derived from the company organisation
> 	nor it does not prove to be stable over time
> 	+> I would hate to see DN change frequently!
>      - this in fact does not really improve the ease for browsing,
> 	as any one is able to search a sub-tree with any AVA (not
> 	restricted to RDN components) as a filter

I basically agree with this.

> remains the proposal b2)
> ------------------------
> 
>  a RDN is composed of the usual CN associated with a UniqueId attribute.
> 
> 	cn=Jacques Martin + UniqueId=5708, O=FooBar, C=FR

This solution is really nothing more than solution a) done in an
X.500-ish kind of way.  Most of the same arguments apply.

> cons:
>  -> In some case the DN may not be sufficient for a human user
>    to distinguish between 2 different persons
> 	eg:
> 	cn=Jacques Martin + UniqueId=5708
> 	cn=Jacques Martin + UniqueId=8345
>     Thus, the interactive user will have to be presented more attributes
> 	(eg. Role + Description + ....).
> pros:
>  -> Once a allocation procedure set within an organisation it is
> 	easy to create unique and stable DN for every staff.
>  -> No inelegant nor awkward side effect on the natural "GivenName SurName"
> 	CN usage
>  -> Name server usage facilitated
>  -> Anyhow human user will only extremely rarely use a DN, it will be stored
> 	in a Personal UA alias book or equivalent, and will often be
> 	extracted automatically from the directory or from say an '88 Orname

The reason we chose solution a) over b2) has to do with our email
environment.  We do mostly smtp-rfc822 email on campus.  We wanted a
flat namespace for all of our people for email purposes.  It was
just much easier to deal with a CN with a number appended than with
another attribute when doing the email lookups.

In hindsight, b2) might have been better.  But it's hard to say.  It's
very easy to explain to our users that, eg. "you have the additional
commonName 'Timothy A Howes 1', which is the only one we guarantee to
remain unique below o=UofM".  It shows up as an extra CN when they display
their entry with some DUA.  If we chose b2), we'd have to explain to them
how they could construct their email address.

In any case, I certainly favor the "arbitrary id appended" solution
(whether done as in a) or in b2)) over the b1) solution.

> Is a common solution (assuming this is a reachable goal)
>   to be badly looked for? then pushed into generalized practice?
>   Do we have to lobby to promote such a solution?

I don't think it's practical to try for a common solution.  Each
organization may have different requirements (as we do with our
campus-wide email namespace), that lead to different solutions.
Maybe what we need to do is accept the fact that we'll have multiple
solutions and look at trying to make them work together.      -- Tim