Re: When should operationsError be sent?

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

I suggest iv) [a generalization of iii].

The result code "other" should be used (and only used) to
indicate "internal error" and that it be allowed in any response
resultCode field.  That is, no standard track specification (such
as RFC2251/bind) should disallow it (or other general errors) as
an appropriate resultCode in a response.   Secondly, I believe it
inappropriate for any standard track specification to prescribe
any specific use of "other".

The result code "operationsError" should be used to indicate
that a general request sequencing error has occurred, such as that
use prescribed in RFC2251-bind or StartTLS or other.

RFC 2251 should be clarified.  (see below)

I do not believe a clarification would be problematic for
a technical or implementation standpoint.  Servers can
easily be changed.  I know of know client which would
care (because they shouldn't).  I have operational
experience that demonstrates that clients are capable
of handling bind resultCodes other than those listed by
RFC 2251 (which, of course, they are required to).

I note that our implementation currrently may return in
response to a bind request codes other or unwillingToPerform.


Suggested change to RFC 2251, 4.2.3:
I suggest the second paragraph be changes from:
 f the bind was successful, the resultCode will be success,
 therwise it will be one of:

to:
  
 If the bind was successful, the resultCode SHALL be success.
 If the bind was not successful, an non-success resultCode
 SHALL be returned and MAY be one of these:

...