Re: people CN

[[e-mail]]

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)

let's have a look at them (if I remenbered  and understood well the
	messages exchanged)


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.


solutions b):
-------------

	cn=Jacques Martin + <tttt>=<vvvv>, O=FooBar, C=FR

 In such a case the RDN is made of 2 components (one being the CN limited
to the usual Given Surname, and the other some discriminating additional
attribute).
 -> it is workable with "reasonable" DUA
	(eg. a decent DUA must be able in case a simple read fails
	to generate a search which will "catch" objects with RDN made
	of several components)
 -> it might be a little bit more costly in term of operations
	generated by a interactive (human user) DUA, but it is not
	really important and it has no impact on the name-server type
	queries

the proposals b1 and b2 differs apparently because some people
are mostly (maybe only) thinking/interested in human user interactive DUA
whereas others give much more weight to name-server type applications


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




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


====================================

Well I suspect I have not been "fair" enough to hide the fact that
at this point I favour a b2) type solution.

There seems to be several others justification for even a stricter
B2) type naming; It seems that a "subtree unique" Id would be
extremely useful for many tasks such as X500 data management, stats,
etc.... has it has for this type of task all the advantages a
unique integer has over an unconstrained character string.

As it has been mentioned a country wide Id (such as Social security number)
is not "legally" acceptable, thus a UniqueId allocated at the organisation
level seems the best solution.
Nota: generaly something similar already exist within any organisation
to allocate a staff-Id
   - it proves it is feasible
   - I don't say use the name value : this may have legal or other constraints
	which preferably should be avoided!


=====================================

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

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?


-- PAP