people CN

[[e-mail]]

Preparing a new stage in the X.500 deployement within INRIA we are
faced with the following difficult issue about people naming.

being a large institution, we have to establish naming guidelines

o  able to cope with several staff with the same Diven and Surname,
and easy enough
o  easy enough to be understood by internal and external DUA
human users
o  regular enough, for name-server type of usage (eg MHS routing)


And in the above requirements lies the difficult issue

let's start from an example
and suppose there exist by now

 one staff : Francis DUPONT
 two staff : Pierre DURAND  (Pierre Jean DURAND and Pierre Yves DURAND)

we have to envisage that one day there will be another Francis DUPONT
	or even another Pierre Yves DURAND

What is your (bright) mind the best naming strategy knowing that
we would like
1. never to have to change the RDN of anyone (once allocated)
	eg. add a second surname id it were not part of the CN
	eg. add some tag in a existing CN (such as "Pierre Yves DURAND 1")
2. keep the CN as simple as possible
	eg. avoid all systematic unecessary info in the RDN
3. keep the CN as "natural as possible"
	eg. even the second Givenname is not really "natural" here
4. keep the same guidelines for every INRIA staff
	eg. if there must be additional information (apart Given and Surname)
		then that these be systematically there
5. avoid as much as possible RDN made of several attributes
	eg. the PN attributes AND a UserId
6. be able to design name-server lookup algorithms with predictible
	results, while still performant and if possible simple
	(though much more frequent, the human user view
	should have the priority over lookups)
7. keep the RDN be meaningfull/readable/guessable by a human being
	eg. CN="123.4.235"
8. [[add your own additional requirements]]


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.

Has anyone a (a few) other solution(s) to complete this list?
Does this solution avoid the given constraints?


It seems that the solution to be choosen is highly dependant of
how most of DUA will behave:

  . on one hand, it seemed that the solution should facilitate
	a high probability of positive/accurate result with
	a simple READ operation using the most "obvious" attribute
	values
  	This would exclude using a numeric tag within the CN, and
	even the use of the second GivenName, but then no way
	to cope easily with the 2 Pierre DURAND :-(

  . on the other hand, it may appear that there will be no
	workable READ solution, but that DUA should resort to a SEARCH
	(one level preferible).
	This gives much less importance to the RDN value which may
	perfectly be complex, as long as the entry contains the appropriate
	attributes probably multi-valued.
	If we still want the name-server type lookups be usable,
	we have to go for a RDN which will suit them, but
	will probably not be user-friendly.


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, and suggest this to be part of the WG-NAP
TF working on a recommendation about
personal attributes and user-preferences as a very
important start point.

best regards,




-- PAP