Re: [provision] Comments on search and iterator

[Gary P Cole <Gary.P.Cole@Sun.COM>]

Martin,

These are excellent comments.  Thank you for raising these issues.  I'll 
record them as spec issues #39 and #40.

Notes inline below summarize the discussion during this morning's 
conference call.

Raepple, Martin wrote:

> Two comments on the search and iterator operations:
>
> 1. The iterator will allow the requestor to step through a result set 
> when a search query matches more objects that the provider can place 
> directly in the response. Line 2573 of draft 0.08 says that the 
> provider is required to commit the resources for an unspecified period 
> of time. In a situation where many iterators are kept alive/open by 
> the provider and the targets (e.g. due to inactivity by the 
> requestors), the amount of resources / memory will increase constantly 
> and the overall performance will be affected. The system will also be 
> vulnerable to denial of service attacks.
>
> I think the spec should recommend a strategy how to deal with this 
> issue. I see two options (which may also be combined):
>
> - Definition of a iteratorTimeout parameter: Just like the timeout 
> value for a HTTP session in a servlet container, this parameter will 
> specify the time, in seconds, between iterator requests before the PSP 
> / Target will invalidate (destroy and release resources of) the 
> iterator. A negative time may indicate the iterator should never timeout.
>
> - Definition of a iteratorLifetime parameter: This is to set a maximum 
> value of a iterator's lifetime (again in seconds), independant of any 
> requests sent by the RA.
>
> Both parameters could be optional attributes of the searchRequestType. 
> iteratorLifetime should overrule iteratorTimeout. If none is set by 
> the requestor, default values for these parameters (e.g. set at 
> bootstrap time) should apply.
>
Jeff Bohren: a requestor will not know an appropriate timeout value for 
the provider.
Gary Cole: even provider may not know an appropriate timeout value, 
given a shifting load.
AGREED that the spec should recognize this issue (and perhaps recommend 
strategies).
Martin Raepple will draft text for this purpose.  Gary Cole to 
incorporate into spec.

> 2. In SPML 1.0 there is the possibility to constrain the target schema 
> elements / attributes returned in the result by using the <attribute> 
> element in the searchRequest. Since this is a reasonable feature and 
> the returnData attribute of the searchRequestType does not yet provide 
> a comparable functionality, I would suggest to include this feature in 
> 2.0 again.
>
Jeff Bohren says this is still possible, but the feature is specific to 
each profile.
Jeff Bohren will confirm that the DSML Profile preserves this feature.
Jeff Bohren will confirm that the XSD Profile accomplishes this through 
XPath.