Re: people CN
pays@faugeres.inria.fr Tue, 01 December 1992 22:44 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11295;
1 Dec 92 17:44 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11291;
1 Dec 92 17:44 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa27150;
1 Dec 92 17:44 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP
id <g.07729-0@haig.cs.ucl.ac.uk>; Tue, 1 Dec 1992 21:38:23 +0000
Received: from faugeres.inria.fr by bells.cs.ucl.ac.uk with Internet SMTP
id <g.15718-0@bells.cs.ucl.ac.uk>; Tue, 1 Dec 1992 21:38:11 +0000
X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; Relayed;
01 Dec 92 22:38:06+0100
Date: 01 Dec 92 22:38:06+0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: pays@faugeres.inria.fr
To: lenggenhager@gate.switch.ch
Subject: Re: people CN
cc: osi-ds@cs.ucl.ac.uk, wg-nap@rare.nl
Message-ID: <723245886.22094.0@faugeres.inria.fr>
> > 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.
>
> Do you mean with 'respecting X.500 "spirit"' that a DN should be
> possible to be communicated between endusers?
> I am still not convinced that this is something the users really want.
> Something like a UFN would be what is practical and can be taken from
> the normal information already on a business card.
>
Oh no! this is not at all related to this issue of
exchanging DN
My intention was just to state that this packing 2 attributes
into a single one (normal CN + Id into the CommonName)
was not the normal attribute usage (1 specific attribute - with the
appropriate attribute syntax- for each piece of information)
> That makes much more sense than b1). Remains only the question what
> attribute to use.
> And what shall be done for residential persons? There the problem is much
> worse since clashes are more probable and no organization is around
> to distribute UniqueIds.
You are right, I am hopefuly not in a position to design
solution for residentialpersons :-)
In such a case a may be stupid but workable solution
is that the directory service provider for residential
person allocates an Id (a kind of customerId)
and also has the RDN be composed of CN + Id
this has no need to be Unique country wide, or state wide
it has only to be unique for the people sharing the same
commonname in a same subtree
this leaves the service provider a lot of freedom to allocate
a customerId (up to the point of starting a new sequence
number for each value of the CN attribute)
> Thomas
-- PAP
>
>
- people CN pays
- Re: people CN Andrew Waugh
- Re: people CN pays
- Re: people CN Andrew Waugh
- Re: people CN Thomas Lenggenhager
- Re: people CN Ruenzler Walter
- Re: people CN Alan.Young
- Re: people CN Thomas Lenggenhager
- Re: people CN Ruenzler Walter
- Re: people CN Andrew Findlay
- Re: people CN Thomas Lenggenhager
- Re: people CN Christian Huitema
- Re: people CN Andrew Findlay
- Re: people CN Andrew Findlay
- Re: people CN Thomas Lenggenhager
- Re: people CN A.Macpherson
- Re: people CN pays
- Re: people CN Thomas Lenggenhager
- Re: people CN pays
- Re: people CN Tim Howes