Spec issue #39: Iterator lifecycle management

["Raepple, Martin" <martin.raepple@sap.com>]

Title: Spec issue #39: Iterator lifecycle management

@Gary: Please find below my draft text for issue #39:

(Line 2571 ff) ... Storing the remaining objects allows the requestor to iterate the remaining objects, but also requires the provider to commit resources [DELETE (for an unspecified period of time)].

(Line 2756 ff) ... Storing the remaining objects allows the requestor to iterate the remaining objects, but also requires the provider to commit resources [DELETE (for an unspecified period of time)].

[INSERT] After the iterator has been created by the provider, the requestor will only be interested in it for some finite period. This period can not always be determined implicitly by the searchResponse message containing the last object from the status set since the requestor my not be interested in all results or simply started a new query to refine the search. In any case, the provider is responsible to control the lifecycle of its iterator instances in order to release the resources (e.g. database connections) associated with them. Otherwise, the provider may run out of resources or even be subject to denial of service attacks.

The PSTC recommends to follow best practices in managing these resources at the provider. Since the provider cannot rely on the requestor to control an iterator's lifecycle properly, the provider may define a global timeout parameter that specifies the time between iterator requests before the provider will invalidate and release the resources assiciated with an iterator. In certain situations, this strategy could still lead to a critical number of open resources at the provider. Therefore, an additional lifetime parameter at the provider may schedule the total amount of time after which an iterator will be invalidated by the provider. To prevent denial of service attacks, the requestor should provide proper authentication (see security and privacy considerations in chapter 5) before any resources are allocated by the provider.

Upon receipt of an iterator request using an iterator ID attribute value representing an invalidated iterator, the provider MUST return to the requestor a <searchResponse> that specified "status='failure'" (see the normative section above).

@All: As another option to my former approach as described in [1], it may be reasonable to define a very simple mechanism for the requestor to let the provider (and the target) know that it does not need the iterator any longer. This could be defined by a <iteratorInvalidateRequest> message that only has the iterator ID element. A <iteratorInvalidateResponse> will return the result of this action by specifying the status attribute accordingly. Nevertheless, this explicit invalidation of the provider resources triggered by the requestor still requires a proper server-side resource management as described above. What do you think?

[1] http://www.oasis-open.org/apps/org/workgroup/provision/email/archives/200505/msg00088.html