The continuationPoint parameter in the HistoryRead Service is used to mark a point from which to continue the history read if not all values could be returned in one response. The value is opaque for the Client and is only used to maintain the state information for the Server to continue from. For HistoricalDataNode requests, a Server may use the timestamp of the last returned data item if the timestamp is unique. This can reduce the need in the Server to store state information for the ContinuationPoint.

The Client specifies the maximum number of results per operation in the request Message. A Server shall not return more than this number of results but it may return fewer results. The Server allocates a ContinuationPoint if there are more results to return. The Server may return fewer results due to buffer issues or other internal constraints. It may also be required to return a ContinuationPoint due to HistoryRead parameter constraints. If a request is taking a long time to calculate and is approaching the timeout time, the Server may return partial results with a ContinuationPoint. This may be done if the calculation is going to take more time than the Client timeout. In some cases, it may take longer than the Client timeout to calculate even one result. Then the Server may return zero results with a ContinuationPoint that allows the Server to resume the calculation on the next Client read call. For additional discussions regarding ContinuationPoints and HistoryRead please see the individual extensible HistoryReadDetails parameter in 6.5.

If the Client specifies a ContinuationPoint, then the HistoryReadDetails parameter and the TimestampsToReturn parameter shall be the same as in the original call. It is permissible to change the dataEncoding parameter with each request. If the HistoryReadDetails parameter or TimestampsToReturn parameter change the Server may ignore the updated parameters, it may detect any changes to the parameters and report an error or it may process the request as if it was a new request. The exact behaviour is Server specific.

If the Client specifies a ContinuationPoint that is no longer valid, then the Server shall return a Bad_ContinuationPointInvalid error.

If the releaseContinuationPoints parameter is set in the request the Server shall not return any data and shall release all ContinuationPoints passed in the request.

If the ContinuationPoint for an operation is missing or invalid then the StatusCode for the operation shall be Bad_ContinuationPointInvalid.