Rep (2) : LDAP

[Ascan Woermann <[e-mail]>]

> > 	For resultCodes of noSuchObject, aliasProblem, invalidDNSyntax,
> > 	isLeaf, and aliasDereferencingProblem, the matchedDN field is
> > 	set to the name of the lowest entry (object or alias) in the
> > 	DIT that was matched and is a truncated form of the name
> > 	provided or, if an alias has been dereferenced, of the
> > 	resulting name.  The matchedDN field should be set to a NULL DN
> > 	(a zero length string) in all other cases.
> > 
> > The alias case is very ennoying. Suppose I provide <CN=Name, OU=Foo, O=Bar,
> > C= XX>, and that LDAP returns the "matched attributes" <C=Foobar, C=YY>. How d
> > I know whether this matched 2 or 3 components? Should we return a "matched
> > name parts" count in complement to the matched attributes? Or an alias
> > indication?
> 
> I'm not sure about this.  If an alias is involved and there is an error
> the aliasProblem error includes the value of the aliasedObjectName, and
> not some truncated portion of the original DN, or of the aliasedObjectName.
> In this case, the DUA can't tell which component had the bogus alias in it,
> but it can tell what the bogus alias is.  How would including an indication
> of whether an alias was encountered help this situation?        -- Tim
> 

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 ?

Ascan
TS-E3X