Re: people CN

[Thomas Lenggenhager <[e-mail]>]

PAP wrote:
> 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.

In fact it is a nice coincidence. I was just yesterday thinking about
that problem in relation with the WG-NAP TF-dataman. Possible solutions
will be an important part of the report to produce.

PAP wrote:
> [[
> 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 am in favor of "GivenName Surname SequenceNumber". A DUA can still
sort the entries by using the surname attribute.

Anyway it is not that important.
In my view the RDN has the following roles
 - first of all it is a database key (without any other meaning)
 - then it should have some meaningful value whenever possible in
   order to allow better searching performance.
 - it should be not too awkward to type (for whenever there is
   the need to)

The DUAs should make much less usage of the DUAs for presenting
a list of entries.
Why is the RDN used so often in the current DUAs?
Simply because the standard has no other means to flag a single
value of a multiple valued attribute as the preferred one!

Once we solved that problem, it would be easier to live with
a sequence number in the RDN. Since then the DUAs could present
the preferred values.

When talking about flagging attribute values, we come back to an
earlier discussion on the osi-ds list of supporting national
character sets and multiple languages.

Does anybody know whether the 1992 standard has an extension into
that direction? (I think SHK or Colin mentioned once someting).

Andrew wrote:
> One suggestion is to use the job description to disambiguate people:
> 	cn=Andrew Waugh%desc=X.500 Hacker

The description can be long and you mentioned yourself, that it
might change! A sequence number doesn't change.
That way you wouldn't adapt the description anymore to avoid changing
the RDN. That is a bad idea.

PAP wrote:
>           Though, I dislike using the description, and  then
> would recomment to use OrganizationalRole attribute
> for such a purpose.

That would be much better, but does everybody have an OrganizationalRole
which can distinguish him from another person with the same name in the
same organizational unit? I doubt that.

Andrew wrote:
> You should think very carefully about what you want and what you are
> doing! What you want is that the user can enter a DN which then
> gets mapped to an O/R address. The problem is that if two people have
> very similar DNs (as a result of the same name and a simple
> disambiguating algorithm) it is very likely that the
> WRONG O/R address will be returned. Since this is being handled
> 'automatically' the mail will then be sent to the wrong person! This
> could be very embarassing if the mail is sensitive for some reason.
> 
> (Note that this problem could also occur if the DNs are similar,
> but not identical.)
> 
> For such applications, you don't just need the DNs to be unique,
> you need them to be very different. (Technically, the DNs need to
> have a large hamming distance.)

I don't think that you want a user to enter the DN. If that came
true, we would have solved nothing, since it is as bad as typing
an X.400 standard attribute address. What we want to see in future
UAs, is first the use of local aliases and in case you have a new
address, the use of UFN (user friendly naming). Then the user will
get a short list to select the correct recipient. Then the system
should ask for an alias for that address and store the alias, DN
and UFN together in an internal DB.

Regards,
Thomas

===============================================================================
               SWITCH - The Swiss Academic and Research Network
   Thomas Lenggenhager, SWITCH, Limmatquai 138, CH-8001 Zurich, Switzerland
   INET: [e-mail] | Tel: [phone] | Fax: [phone]
      X.400: G=Thomas; S=Lenggenhager; O=SWITCH; P=SWITCH; A=arCom; C=CH