Re: Rep (2) : LDAP

Tim Howes <tim@terminator.rs.itd.umich.edu> Mon, 07 June 1993 19:33 UTC

Message-Id: <9306071913.AA21872@terminator.rs.itd.umich.edu>
To: Ascan Woermann <Woermann@osi.e3x.fr>
Cc: osi-ds@cs.ucl.ac.uk, Christian Huitema <Christian.Huitema@sophia.inria.fr>
Subject: Re: Rep (2) : LDAP
In-Reply-To: Your message of "Mon, 07 Jun 93 13:32:40 -0000." <7394779601075woer*/S=Woermann/OU=OSI/O=E3X/PRMD=E3X/ADMD=atlas/C=FR/@MHS>
Date: Mon, 07 Jun 1993 15:13:29 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Tim Howes <tim@terminator.rs.itd.umich.edu>

> From:    Ascan Woermann <Woermann@OSI.e3x.fr> (Tel +33 93-65-34-65)
> To:      Tim Howes <tim@terminator.rs.itd.umich.edu>
	   osi-ds@cs.ucl.ac.uk,
	   Christian Huitema <Christian.Huitema@sophia.inria.fr>

> To my understanding Christian is referring to the case of a name error 
> occurring after correct dereferencing of a valid alias. 
> In this case the name error won't help you much, for example, in deciding 
> where to start searching in an algorithm such as AFRO. The current 
> implementation of AFRO detects when the matched DN returned is not
> a prefix of the given name, and, if necessary, continues with read operations 
> on a progressively shorter name to find the erroneous name part "manually".
> Having said this, I don't follow the remainder of Christian's proposal: what 
> else you can do in LDAP ?

Ah.  I see the problem now.  The question is, as Ascan points out,
whether there is anything that can be done about this in LDAP, since
it is a problem with X.500 as well.                         -- Tim

Rep (2) : LDAP Ascan Woermann
Rep (2) : LDAP Alain Zahm
Re: Rep (2) : LDAP Tim Howes
Rep (2) : LDAP Ascan Woermann