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 can 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 can return fewer results. The Server allocates a ContinuationPoint if there are more results to return. The Server can return fewer results due to buffer issues or other internal constraints. It can 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 can return partial results with a ContinuationPoint. This can be done if the calculation is going to take more time than the Client timeout. In some cases, it can take longer than the Client timeout to calculate even one result. Then the Server can 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 can ignore the updated parameters, it can detect any changes to the parameters and report an error or it can 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.