Re: people CN

[Ruenzler Walter <[e-mail]>]

>These requirements tend to make consider that:
>S1	mixed naming (eg. some with 1 some with 2 GivenName) is a bad solution
>S2	multi-attributes RDN	is a bad solution
>S3	CN="Given1 SURNAME" 	is a bad solution
>S4	CN="Given1 Given2 SURMNAME"	is a bad solution
>S5	CN="Given SURNAME NumId"	is a bad solution
>S6	use a subtree (new object tbd) for all people sharing the same
>		simple CN is a bad solution
>S7	CN="NumericUserId"	is a bad solution
>because they all violate at least one of the above requirements.
>
>
>If we consider that the highest priority is to be given to
>	. systematic and stable (over time) naming
>	. guarantee of unicity (over time) without resorting
>		to tricks
>	. homogeneity of the naming sheme
>	. consistant and accurate name-server lookups
>over considerations such as number or cost of operations necessary
>to reach an entry from "gessable" attribute values
>then I would
> . eliminate S1 S2 S3 S4
> . try to avoid S7 (too cryptic)
> . consider S6 (though not clear about consequences)
> . favour S5
>
>
>[[
>Here I deliberately ignore the GivenName SurName ordering debate.
>For France, contrary to the above examples, I would recommend
>	"Surname GivenName NumUserId"
>just because it allows an easy alphanumerical sorting
>most users and applications are familiar with
>]]
>
>
>I would appreciate to receive your comments, on this small
>but crucial issue

We at union bank of switzerland use what you name as
S5, because we had the feeling it's the best of all bad solutions.
(Our telephone book, from where we took the data was already
build this way).

We use NumId only in the case it is really needed (For the 2'nd, or
3'rd person with the same name).

e.g.:

If we have 2 Bruno Keller than the 1'st is:
Keller Bruno
and the 2'nd is
Keller Bruno I

Walter Ruenzler