RE: Comments on draft-seilenga-lldap-cancel-00.txt

["Salter, Thomas A" <Thomas.Salter@unisys.com>]

Perhaps you need one new result code of "error, see extended response".
This is generic enough for use by all extended operations but doesn't
overload the existed status codes.

 > -----Original Message-----
 > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
 > Sent: Wednesday, January 24, 2001 8:31 PM
 > To: Ramsay, Ron
 > Cc: hahnt@us.ibm.com; ietf-ldapext@netscape.com
 > Subject: RE: Comments on draft-seilenga-lldap-cancel-00.txt
 > 
 > 
 > At 12:00 PM 1/25/01 +1100, Ramsay, Ron wrote:
 > >I think it is worth looking more closely at the result codes.
 > > 
 > >cancelled is the result returned in the original request 
 > (success is the
 > >result returned in the abandon response but this doesn't appear).
 > > 
 > >noSuchOperation, tooLate and cannotCancel are returned in 
 > the abandon
 > >response (there is no original request).
 > > 
 > >Therefore, only 'cancelled' need ba added to RFC 2251. All 
 > the others could
 > >appear in a special
 > > 
 > >    CancelResponseValue ::= ENUMERATED { success(0), 
 > noSuchOperation(1),
 > >tooLate(2), cannotCancel(3) }.
 > 
 > Yeah, but, the extendedResponse would need to return a resultCode.
 > One could say it always returned success and the client should
 > look at the response value for details.  That is, the operation
 > could return:
 >         success with response value success,
 >         success with response value noSuchOperation,
 >         success with tooLate,
 >        success with cannotCancel,
 >        protocolError, and
 >         other non-success resultCodes (especially in
 >           the face of extension by control)
 > 
 > Overloading success is bad.  Overloading other resultCodes
 > is equally bad.
 > 
 > IMO, adding new resultCodes is the most sound approach.
 > 
 > PS: SEQUENCE provides extensibility
 >