If a client requests an aggregate configuration that will take a long time to return, the client will timeout if the server tries to calculate the data in one call. The server needs to be able to stop calculating and return if the client timeout hint gets close. In some cases this may require the server to not return any aggregate values because it has not finished calculating the first one. It should return a continuation point that allows it to continue calculating where it left off.

Right now Part 11 section 6.3 states, "The Server shall always return at least one result if it returns a ContinuationPoint."

I propose the following paragraph change:

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. In some cases the server may not return any results when it returns a continuation point. One example is when an aggregate is taking a long time to calculate. The client should be prepared to handle zero results and a continuation point. For additional discussions regarding ContinuationPoints and HistoryRead please see the individual extensible historyReadDetails parameter sections.

Then we should add specific text at the end of 6.4.4.2 Read processed functionality:

If an aggregate is taking a long time to calculate the server can return partial results with a continuation point. This might be done if the calculation is going to take more time than the client timeout hint. In some cases it may take longer than the client timeout hint to calculate even one aggregate result. Then the server may return zero results with a continuation point that allows the server to resume the calculation on the next client read call.