Subject: Re: Returning Partial Results for an operation

From: "Haripriya S" <[email-masked]>
Date: Wed, 03 Jan 2001 06:54:18 -0700

IMO I see two kinds of responses a server may want to return on receiving an abandon:

1. A response to the abandon operation itself ( useful to clients to know that abandon was received).
2. A partial/full response to the original operation which was abandoned ( useful for sending accumulated partial results).

While the first requires an extended request and response and the need for the client to understand the same, the second may require a change to rfc2251 sec. 4.11 alone:

 "In the event that a server receives an Abandon
   Request on a Search Operation in the midst of transmitting responses
   to the search, that server MUST cease transmitting entry responses to
   the abandoned request immediately, and MUST NOT send the
   SearchResponseDone."

If the first MUST condition in the above passage is removed, and the second one retained, the server will be able to send accumulated responses. The above clause is for search, but the same also applies to other requests returning partial responses.

The clients should work with this change because, they "MUST be prepared to receive results from operations it has abandoned" (4.11).

Thanks and Regards,
Haripriya

>>> "Kurt D. Zeilenga" <[email-masked]> 12/23/00 01:51PM >>>
I'd be happy to co-author an abandon I-D.

The use of an control upon abandon to solicit an
(extended? new?) response would likely not be supported
by an client API.

I believe an extended operation is the best approach.

Kurt

At 06:36 PM 12/22/00 -0700, Roger Harrison wrote:
>Kurt,
> 
>I, too, have been considering the same thing because there are times when it would be very nice to know an abandon has been received and handled. 
> 
>In a conversation I had with Haripriya, I suggested just such a thing, and Haripriya suggested using a control to request a response for an abandon operation. It sounds like Jim wouldn't mind seeing something in this area as well.  Should we write something up? If so, do you have an opinion as to whether we should use a new extended abandon-with-response operation or a control on the current abandon operation?
> 
>Roger
>
>>>> "Kurt D. Zeilenga" <[email-masked]> 12/20/00 09:35PM >>> 
>At 09:44 PM 12/20/00 -0700, Haripriya S wrote: 
>>Yes but it would then mandate that the server MUST send partial results per entry immediately, and cannot bunch results even if a client wishes so, because the state cannot be conveyed once an abandon is received. 
>
>Abandon semantics also require the server to defer returning 
>return results of operations issues subsequent to the abandon 
>operation until the operation being abandoned has been 
>abandoned or has completed. 
>
>For this reason, I have been considering specifying a new 
>abandon operation which, like the X.500 abandon operation, 
>has a response. 
>
>Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 06 Jan 2001 09:39:10 -0800

>2. A partial/full response to the original operation which was abandoned ( useful for sending accumulated partial results).

The X.500 abandon operation has a response and requires that
the abandoned operation also has a response containing the
'abandoned' result.

>While the first requires an extended request and response and the need for the client to understand the same, the second may require a change to rfc2251 sec. 4.11 alone:

One must not confuse the existing LDAP abandon operation and
a new operation implementing the X.500 semantics.  I intend to
call this new operation the 'Cancel' extended operation such that
one will not (easily) confuse LDAP 'Abandon' requirements with
its requirements.  I do not believe any change to RFC 2251
will be need to fully specify a 'Cancel' operation which has
semantics similar to the X.500 Abandon operation.

Kurt