Re: people CN

[Thomas Lenggenhager <[e-mail]>]

Alan Young wrote:
> As Walter mentioned earlier, at UBS we use a serial number on
> the end of the commonName (just for the ambiguous entries) and
> this works well enough but, as others have pointed out, gives
> nothing in the returned list of DNs which will help a user
> choose the right one.  The problem with saying that the DUA
> should present the user with some other attributes means that
> these all entries must be read first, which could be significant
> in an organisation using a flat DIT structure.

When I read the last sentence above for the first time, I assumed that
after a search operation the reads would be done with seperate
operations, and I did therefore agree to that arguement. 

In the mean time a learnt something more about the possibilities
X.500(1988) offers already, and I can't argree to it anymore.

**  According to X.500(1988) it is possible to specify the
**  EntryInformationSelection when doing a search.

A DUA can specify which attributes it wants to get back together
with the DNs for the matched entries (all that happens in one operation).

So why don't we recommend to the DUA implementors to use this facility
for the benefit of the users?
- Searching for an organisationalPerson:
	Ask for the commonName, description and title.
- Searching for an organisationalRole:
	Ask for the commonName, description and organizationalUnitName.
	Optionally ask also for the roleOccupant (which is a DN) and
	read that entry.
- Searching for a residentialPerson:
	Ask for the postalAddress

That way a DUA has enough information available and it is able to
present a good choice to the user, independant of the DN.
A RDN: cn="Firstname Lastname SerialNumber" would not be visible at all.

An advantage of such a solution would be, that it doesn't only work for
persons but also for organizations and other cases where you don't have
a naming autority guaranteeing unique RDNs.

There could be the arguement, that you have to transfer too much data
for an organisation using a flat DIT structure. Yes that is true, but
it would be preferable to restrict the number of entries the DSA
should return. I.e. to force the DUA to ask more precisely.

Here an example to prove that it works: (With QUIPU syntax, sorry Paul-Andre)
Dish -> search -obj @c=CH@o=SWITCH -subtree -show -filter cn~=thomas -types description cn
24  cn=Thomas Brunner
commonName            - Thomas H. Brunner
commonName            - Thomas Brunner
commonName            - T. H. Brunner
commonName            - T. Brunner
description           - SWITCHlan, Project Leader
25  cn=Thomas Lenggenhager
commonName            - Thomas Lenggenhager
commonName            - T. Lenggenhager
description           - SWITCHinfo, Project Leader
26  cn=Thomas Stalder
commonName            - Thomas Stalder
commonName            - T. Stalder
description           - SWITCHlan, Network Operator

Regards,
Thomas