RE: draft-just-ldapv3-rescodes-01.txt

[Mike Just <mike.just@entrust.com>]

Hi Kurt,

> A few comments/questions/suggestions based upon a quick read...
> 

Thanks for looking at the document. Comments below.

> Internal Errors: operationsError vs other
>   You have defined operationsError as being used to indicate internal
>   errors?  Is this actually appropriate since operationsErrors are
>   prescribed to be returned in a number of specific situations, such
>   as documented by bind and start tls operations.  I do not believe
>   operationsError should not be used as a catch all for "internal
>   errors".  Instead, I suggested servers return other.
> 

Good point. Your reference to Bind is from Section 4.2.1 of RFC 2251. We'll
have to investigate further to see how we should classify operationsError.

> Precedence?
>   Seems to imply that if multiple errors were detected, that
>   more "specific" should be returned over less "specific" errors.
>   I believe that the most severe error detected be returned.
>   In particular, a protocolError should take precedence over any
>   "specific" error.
> 

At first thought, I would suspect that a protocolError would be detected
before any other condition could be checked. However, each server may decide
on the order in which it will validate the success of a request, and we
certainly didn't include this section to prescribe how a server should
validate a request.

We wanted to include the precedence section since it is in X.511. The
particular example you cite results from our pigeon-holing of protocolError,
which is not included in X.511, as a general error. There may be other
examples though. We've never felt too strongly about a need to keep the
precendence section in any case.  I'll propose that we remove it unless
anyone has a reason for keeping it. 

>   I would also note that a server is not required to detect
>   multiple errors.  It is allowed to return the first error
>   detected.
> 

Yes. That's why it is phrased "in the case that more than one error is
detected".  In any case, as noted above, we'll likely not keep this section.

> Controls
>   No meantion of controls are made.  As controls can significantly
>   change the behavior of operations, it may be appropriate for a
>   control to specify that a result code be returned which would
>   normally returned by the base operation.
> 

Right. We'll make mention of this. Since no specific controls are defined in
RFC 2251, we'll just point the readers to the respective RFCs for details.

> Extended Operations
>   I would suggest adding a sentence to your extended operation
>   section:  Extended Operations MAY return any result code
>   (excepting 81-90).
> 
> API Errors (81-90):
>   A note stating that server MUST NOT return these result codes.
> 

Both of these sound fine.

Mike J.