[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Persistent Search questions



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

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


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