Re: Rep (2) : LDAP

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

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03399; 7 Jun 93 15:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03395; 7 Jun 93 15:33 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa13345; 7 Jun 93 15:33 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.04534-0@haig.cs.ucl.ac.uk>; Mon, 7 Jun 1993 20:13:43 +0100
Received: from terminator.rs.itd.umich.edu by bells.cs.ucl.ac.uk with Internet SMTP id <g.26666-0@bells.cs.ucl.ac.uk>; Mon, 7 Jun 1993 20:13:35 +0100
Received: from vertigo.rs.itd.umich.edu by terminator.rs.itd.umich.edu (5.67/2.2) with SMTP id AA21872; Mon, 7 Jun 93 15:13:30 -0400
Message-Id: <9306071913.AA21872@terminator.rs.itd.umich.edu>
To: Ascan Woermann (Tel +33 93-65-34-65) <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 93 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