[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: draft-just-ldapv3-rescodes-01.txt
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.