Re: When can Search return errors (post name resolution)

[Steven Legg <steven.legg@eb2bcom.com>]

Jim,

Jim Sermersheim wrote:
> How literally are we to take the statement from X.511:
> "The request succeeds, subject to access controls, if the baseObject is 
> located, regardless of whether there are any
> subordinates to return"?

If one takes the statements in X.500 literally then it is all too easy to
find inconsistencies and conflicts. A fair dose of common sense is required.
I have found it best to look for the point of any statement rather than agonize
over its exact wording. The point of this statement is that it is not an error
if the base entry of a search has no subordinates.

>  
> For example, if an alias loop is detected while searching, is it 
> silently ignored? Similarly, if an alias cannot be dereferenced while 
> searching, do we not return aliasProblem?

I give the error descriptions more weight (they are more specific) than
more general statements about success and failure.

>  
> Surely, if there is an internal error (out of memory, etc.) the request 
> does not succeed.

Yes, that is the common sense approach.

>  
> Of course sizeLimitExceeded and timeLimitExceeded may be returned even 
> if the base object is located, but in X.511 these are not returned as 
> ERRORS, they are returned in partialOutcomeQualifier.
>  
> [Protocol] says this instead:
> "   Servers MUST NOT return errors if attribute descriptions or matching
>    rule ids are not recognized, assertion values are invalid, or the
>    assertion syntax is not supported. More details of filter processing
>    are given in Clause 7.8 of [X.511]."
>  
> I've had it asked whether LDAP implementations are to go beyond this 
> statement and never fail a search once name resolution has completed (as 
> is implied by X.511),

As it is technically difficult to *force* an operation to succeed in the face
of crippling errors, common sense says to favour the error descriptions over
an imprecise statement regarding success and failure (where there's a conflict).

> and specifically, what to do about alias
> derefrencing problems while searching.

I ignore alias problems within the subtree being searched since they can arise
through legal operations on the directory, and always raising an error would fail
every attempt to search a subtree that happened to contain a flawed alias.

Regards,
Steven

>  
> Jim