Subject: Re: Multiple extended responses per request

From: "Roger Harrison" <[email-masked]>
Date: Tue, 14 Sep 1999 01:30:59 -0600

Based on my discussions with Dave Wilbur (we both work at Novell), the idea for multiple responses to an extended request came from the desire to get status on directory operations that might take a lot of time rather than the need to collate results in some way.  

Imagine a directory operation that could take a "long" time--deleting a very large subtree, for instance.  It would be nice for the server to provide feedback during the time the operation is completing so that the client is just left hanging until the operation finally completes.  In this imaginary example, I think the dialog might look like this:

C  -> S: Delete Subtree 
S -> C: Deleted entry  a
S -> C: Deleted entry  b
S -> C: Deleted entry c
...
S -> C: Deleted entry x
S -> C: Deleted entry y
S -> C: Deleted entry z
S -> C: Result: Success

The client would have to know and expect multiple responses for an extended request of this type, just like it does for search.   I don't see a problem with this since the extended operation would define the allowed behavior, and the client could therefore be written accordingly. Since the client initiates the extended operation, it would know to expect the associated behavior as well.

Roger

------------------------------------------------------
Roger G. Harrison
Novell, Inc.
[email-masked]

>>> "Steve Fisher" <[email-masked]> 09/13/99 03:29AM >>>
Dave

 In some ways, your requirements seem similar to the X.500 DAP pagedResults
feature which organizes search responses into a set of 'pages'. This is
initiated by the client in the initial search request (using a non-critical
extension) and then collected in page size chunks of entries in subsequent
searchRequests. This is fine if the client anticipates that some type of
management of responses is required, but is not something that the Server
can initiate (as far as I can see), and which is something that wasnt clear
to me in your original message. If you are looking to the Server to prompt
multiple results, if the client is getting back more than it anticipated, it
would ordinarily perform a more refined operation rather than accept a lot
of unexpected entries.

An extended operation which deals with searches (or maybe two - one to
initiate the orgainisation of results, the other to collect existing results
'pages') which would seem a reasonable thing to do as it would maintain the
single request/response model and the operation of it would be very similar
to the existing search results processing procedures.

If this is a 'general feature', (i.e. the organization of any operation into
multiple responses) then this couldn't be an extended operation, as you
potentially would like to 'multiply respond'  to any extended (or core)
operation.

Steve Fisher

BT Syncordia
[email-masked] 

-----Original Message-----
From: Dave Wilbur <[email-masked]>
To: [email-masked] 
<[email-masked]>; [email-masked] 
<[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: 10 September 1999 17:38
Subject: Re: Multiple extended responses per request

Thanks for the feedback from Bruce and Kurt.

The suggestion that each response be prompted by a
request could also be used for Persistent Search (as well
as a standard Search, for that matter).  The fact that Search
saw a need (to reduce overhead, other?) to allow for multiple
responses to a request, in the form of entries and a result
leads me to believe that an extension should be able to
accomplish similar functionality.

The fact that Kurt suggested that we CAN do multiple
responses per exteded request leads me to believe that
there are others who think this should be allowed.  Currently
the RFC implies that you only get one Extended Response
per request and the client SDKs are implemented so that you
can only retrieve one response per request.  So if we are to
allow multiple resonses per request, then the RFC should state
this and the SDKs should support it.

Dave

>>> "Kurt D. Zeilenga" <[email-masked]> 9/9/99 10:13:51 AM >>>
At 08:48 AM 9/9/99 -0700, Bruce Greenblatt wrote:
>Hi Dave!
>
>You'll want to do something similar to the multi-stage bind.

Or something similiar to what search does:

CLIENT                                               SERVER
              Extended Request
        ------------------------------------------>

              Extended Response (not done)
        <------------------------------------------
              Extended Response (not done)
        <------------------------------------------
              Extended Response (not done)
        <------------------------------------------
              Extended Response (not done)
        <------------------------------------------
              Extended Response (not done)
        <------------------------------------------
              Extended Response (not done)
        <------------------------------------------
              Extended Response (done)
        <------------------------------------------

At 03:50 PM 9/8/99 -0600, Dave Wilbur wrote:
>While developing an LDAP v3 extension, a developer here wanted to be able
to send multiple responses against one request.  This was relatively easy
to support in our server code, but the published client APIs don't support
more than one response per message id.  While RFC 2251 for LDAPResult is
quite clear in stating "to indicate the *final* status of a protocol
operation request", the ExtendedResponse is not quite so definitive: "The
server will respond to this with an LDAPMessge containing the
ExtendedResponse."
>
>Given the precedent of an interim response in the Search verb as well as
Persistent and Triggered search, it seems to make sense that an Extension
might want to do this as well.  We were going to use different OIDs to
indicate if a response was interim or final until we ran into the client
issue.
>
>Is this feasible? reasonable?
>
>Looking for feedback.
>
>Dave

---

From: Bruce Greenblatt <[email-masked]>
Date: Tue, 14 Sep 1999 09:29:10 -0700

Roger,

It seems to me that SNMP would be more suited to providing this feedback.
It would be a simple matter to define a mib that AUGMENTS the DSA mib to
report this feedback.  You'd have one row in the MIB for each outstanding
operation that you're providing feedback on.  You could have whatever
columns you want to provide details about the operation, and the current
status...

Bruce

At 01:30 AM 9/14/99 -0600, Roger Harrison wrote:
>Based on my discussions with Dave Wilbur (we both work at Novell), the
idea for multiple responses to an extended request came from the desire to
get status on directory operations that might take a lot of time rather
than the need to collate results in some way.  
>
>Imagine a directory operation that could take a "long" time--deleting a
very large subtree, for instance.  It would be nice for the server to
provide feedback during the time the operation is completing so that the
client is just left hanging until the operation finally completes.  In this
imaginary example, I think the dialog might look like this:
>
>C  -> S: Delete Subtree 
>S -> C: Deleted entry  a
>S -> C: Deleted entry  b
>S -> C: Deleted entry c
>...
>S -> C: Deleted entry x
>S -> C: Deleted entry y
>S -> C: Deleted entry z
>S -> C: Result: Success
>
>The client would have to know and expect multiple responses for an
extended request of this type, just like it does for search.   I don't see
a problem with this since the extended operation would define the allowed
behavior, and the client could therefore be written accordingly. Since the
client initiates the extended operation, it would know to expect the
associated behavior as well.
>Roger
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com

---

From: [email-masked] (Mark C Smith)
Date: Tue, 14 Sep 1999 12:44:37 -0400

I for one am skeptical of the value in using another protocol (e.g.,
SNMP) to retrieve status about LDAP requests.  That just doesn't feel
like the right architectural solution to me.  Coordinating requests and
responses across two different protocols on the client side will be
awkward.  I do think the topic of how best to provide status about "long
lived" LDAP operations is an important one.

-- 
Mark Smith
iPlanet Directory Architect / Sun-Netscape Alliance
My words are my own, not my employer's.   Got LDAP?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 14 Sep 1999 09:52:54 -0700

I think there are likely many operations were it makes
sense to return multiple responses to one request.  Search
is one such operation.  There are likely others which make
as much sense as search.

A subtree delete is a good example.  Besides returning results
for each entry deleted, it may need to return references and
such.  Today, a subtree delete could be implemented using a
search PDU with a delete control.

I guess we either live with abuse of the search operation or
we live with multiple extended responses to a extended request.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 14 Sep 1999 09:56:07 -0700

>lived" LDAP operations is an important one.

One could invent an unsolicited response which contained the status
(and description) of the in progress operations.  One could also
invent controls to enable sending of such unsolicited responses
(on a per request basis).

Kurt

---

From: Bruce Greenblatt <[email-masked]>
Date: Tue, 14 Sep 1999 10:02:15 -0700

It wold certainly be easy enough to put together a prototype of an SNMP
status reporting thing.  That's the way that I'd try and see if the dual
protocol approach is workable.  Since "everyone" already supports the dsa
MIB, it seems like a possibility that this is a natural addon to the
dsaOpsTable.