Subject: Re: Persistent Search questions

From: Mark Smith <[email-masked]>
Date: Fri, 02 Feb 2001 15:50:24 -0500

"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.

---

From: Mark Smith <[email-masked]>
Date: Fri, 02 Feb 2001 15:51:35 -0500

I agree that it would be useful to add some text to the PS document
regarding interactions with other controls. I will do so.

Jim Sermersheim wrote:
> 
> cute, Kurt.
> 
> seriously though, the psearch draft should probably have an "interaction with
> other controls" just to make sure ppl think about this kind of thing.
> 
> >>> "Kurt D. Zeilenga" <[email-masked]> 1/30/01 6:57:18 PM >>>
> In regards to DoS attacks, seems you could really drive a
> server crazy by asking it to sort a persistent search.