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

From: "Ramsay, Ron" <[email-masked]>
Date: Thu, 25 Jan 2001 12:00:23 +1100

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) }.
 
(I don't see any reason for the (redundant) SEQUENCE.)
 
Ron.

-----Original Message-----
From: Timothy Hahn [mailto:[email-masked]]
Sent: Thursday, 25 January 2001 4:32
To: [email-masked]
Subject: Comments on draft-seilenga-lldap-cancel-00.txt

Greetings, 

In section 4.1, the existing return codes for the protocol are being added
to with four additional values.  The values seem appropriate only for the
Cancel extended operation. 

I suggest that the existing return codes are not changed.  Rather, I suggest
that the Cancel Response contain: 

CancelResponseValue ::= SEQUENCE { 
        cancelResultCode ENUMERATED { 
                canceled (0), 
                noSuchOperation (1), 
                tooLate (2), 
                cannotCancel (3) 
        } 
} 

This way, the existing protocol data elements are not infringed upon by the
added extended operation. 

My other commnets are editorial and will be sent directly to Kurt.

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 24 Jan 2001 17:31:15 -0800

>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