Re: Multiple extended responses per request

[mcs@netscape.com (Mark C Smith)]

I don't have a strong opinion about whether multiple ExtendedResponses
should be allowed in response to one ExtendedRequest, but my reading of
2251 tells me that the authors didn't intend to support it.  In the C
API, one could call the asynchronous ldap_extended_operation() function
once and then repeatedly call ldap_result() followed by
ldap_parse_extended_result() to receive and process a stream of
ExtendedResponse messages.  But I agree we should clarify whether the
protocol supports this and improve the APIs as necessary to support it
if so.

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


Dave Wilbur wrote:
> 
> 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" <Kurt@OpenLDAP.Org> 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