Re: Persistent Search questions

[Mark Smith <mcs@netscape.com>]

"Kurt D. Zeilenga" wrote:
> 
> At 03:20 PM 1/30/01 -0700, Jim Sermersheim wrote:
> >The persistent search control (draft-ietf-ldapext-psearch-03.txt) states in section 3 that the search operation is modified in such a way that the searcResultDone message is never sent.
> 
> I would rather the spec state the operation never returns success,
> but may return non-success result codes.  This would, amongst other
> things, allow the operation to be canceled (the cancel operation
> cannot cancel an operation which has no response).

I agree -- the statement as it stands in the current psearch draft is
much stronger than it needs to be.


> 
> >This implies that the size and time limits are ignored, but it's not explicitly stated. Can anyone confirm if this is the case?
> 
> I would rather size/time limits not be ignored in face of this control.

This is an interesting issue.  I am fairly sure that the
Netscape/iPlanet server's implementation does ignore size and time
limits for entries that are returned as change notifications.  This
should be discussed in the PS draft.


> 
> >Also, there is a little blurb in the security considerations section about making sure access controls are checked for entries being returned. This is more of a question to other implementors, a server could:
> >a) check access control information once at the beginning of the search, and use that information without refreshing it later (could speed response time, and "fix" authorization to a specific view, or it could
> >b) recalculate access control information everytime an entry is to be returned (provides consistency over long persistent search sessions).
> >
> >My feeling is that b is better, does anyone expect a?
> 
> I'd prefer not to mandate either a nor b as what is best
> is likely application/implementation specific.  I would
> note that in our implementation, b) would likely be much
> easier to implement but I'd hate to wish b) on everyone.
> Likewise for a).

Maybe, but it seems safer and more consistent to me to require behavior
b).  This should at least be discussed in the security considerations
section of the spec.

-- 
Mark Smith
Directory Product Development / Netscape
I speak only for myself.