I like option iii as well since it seems to be the most
consistent option.
Roger Harrison
>>> "Al Sutton" <al@alsutton.com> 05/16/00 12:08PM >>> 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 |