Re: When should operationsError be sent?

["Al Sutton" <al@alsutton.com>]

I'm new to the group, so I'm not up to speed on the whole thread relating to
this, but iii) sounds the most sensible and intuitive.

Al.

----- Original Message -----
From: Jim Sermersheim <JIMSE@novell.com>
To: <ietf-ldapext@netscape.com>
Sent: Tuesday, May 16, 2000 6:36 PM
Subject: When should operationsError be sent?


There has been some discussion among the authors of the results code draft
lately concerning the appropriate use of the operationsError and other
result codes. Gauging a consensus is fuzzy, so we're turning to the WG list.

Currently, the results code draft states that operationsError is returned
from any operation (other than bind) when that operation requires that the
bind operation to happen prior to it being serviced (section 5.2.2.4.1).
This is also stated in RFC 2251 (section 4.2.1).

RFC 2251 section 4.2.3 contradicts the results code draft by stating that
operationsError may be returned from the bind operation as a result of an
internal server error. The SSS and dupent drafts also list operationsError
as denoting an internal server error.

Some argue that "operationsError" should be used as a catchall error that
signifies an internal error on the server. Others argue that "other" is
already available as a catchall error and should be used in these cases so
that we don't end up with two catchall error codes.

The following proposals have been offered as possible solutions:

(i) the "internal error" definition of operationsError would only apply to
Bind, where the "you must bind" definition would apply to all other
operations.  However, this is inconsistent and incorrect to
apply two varying definitions to this single error where only one applies to
Bind and the other to all other operations (In this case, "other" would be
the "internal error" for all operations, including Bind as well), or

(ii) the "internal error" definition would apply to all operations in which
case, for all operations except Bind, operationsError would have two
meanings. In other words, for all operations except for Bind,
operationsError could mean an "internal error", or the "you must Bind"
error.

(iii) leave the results code draft the way it is, which is to limit
operationsError to the "you must bind" definition, and change RFC 2251
bis to reflect that. It has also been noted that the result codes listed as
possibilities for a bind response are currently limited and the wording
needs to be changed for 2251 bis.

Does anyone have an opinion on which direction to travel?

Jim