Re: people CN

[Thomas Lenggenhager <[e-mail]>]

PAP writes:
> As it seems that the discussion has come to a pause, may I try to
> have a few about what has been said so far...
> 
> there seems to be 3 proposals coming out:
> 
> 	a) sequence number within the CN
> 
> 	b) RDN composed of CommonName + another attribute
> 	   b1) another "user friendly attribute" (eg. Description or Role)
> 	   b2) another "UniqueId type of attribute" (UserId or new specificId)
> ...
> 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.
> 
>  -> easy to manage
> 	(need for a proper sequence number allocation procedure)
> 
>  -> not really respecting X.500 "spirit"
>  -> not elegant
>  -> not confortable for people having to exchange their CN
>  -> the CN is not enough for human user discrimination, need to "see"
> 	more attributes values.

Do you mean with 'respecting X.500 "spirit"' that a DN should be
possible to be communicated between endusers?
I am still not convinced that this is something the users really want.
Something like a UFN would be what is practical and can be taken from
the normal information already on a business card.

Your comments are correct when taking the X.500 administrator view on it,
a user provided with the correct DUAs wouldn't care at all.

> ...
> 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
> 
> 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

That makes much more sense than b1). Remains only the question what
attribute to use.
And what shall be done for residential persons? There the problem is much
worse since clashes are more probable and no organization is around
to distribute UniqueIds.

> Is this message a fair account of what has been said in the list?
>   certainly not -> feel free to make your own conclusions/summary

I was a bit astonished that nobody commented on my message from Friday
last week supporting the serial numbers within CN together with
enhanced DUAs. Was my idea so silly?

> 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?

It would make sense to go only into one direction in order to get better
DUA support for that solution.

Thomas