View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
000790610000-011: Historical AccessSpecpublic2022-03-30 10:252023-01-17 17:35
ReporterMatthias Damm Assigned ToPaul Hunkar  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version1.04 
Target Version1.05.03 RC1 
Summary0007906: Clarification of ReadDetails handling with ContinuationPoint
Description

There is the following statement in 6.3 Continuation Points:
If the Client specifies a ContinuationPoint, then the HistoryReadDetails parameter and the TimestampsToReturn parameter are ignored, because it does not make sense to request different parameters when continuing from a previous call. It is permissible to change the dataEncoding parameter with each request.

This is like a hint for the server to store the HistoryReadDetails in the continuation point.
But if a server just keeps the last timestamp returned as continuation point, the parameters cannot be ignored. Since there is no SHALL in the text, this is a valid implementation.

But it would be a major problem if a client takes this statement and does not fill in the SAME HistoryReadDetails for follow up call with continuation point.

I think we need to say:
If the Client specifies a ContinuationPoint, then the HistoryReadDetails parameter shall be the same than for the first HistoryRead call.
The Server can ignore the HistoryReadDetails if a ContinuationPoint is provided.

TagsNo tags attached.
Commit Version
Fix Due Date

Activities

Paul Hunkar

2022-11-30 06:17

developer   ~0018210

If this is added " the Client specifies a ContinuationPoint, then the HistoryReadDetails parameter shall be the same than for the first HistoryRead call." then the shall makes it a requirement to check that the values are the same (and the server will have to return an error if something changed). In a browse call no information is provided other then the ContinuationPoint - I think the text that needs to be changed is the first part
'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." - since this may imply to some that the request information is not needed.

I would think it could cause many holes or issues if the parameter are just sent again and they are changed by the client

Jim Luth

2022-12-08 16:44

administrator   ~0018280

Last edited: 2022-12-08 16:46

Agreed to changes edited in 1.05.x draft.
Needs 1.04 Errata to close.

Paul Hunkar

2023-01-17 17:21

developer   ~0018532

Added errata for 1.04

Paul Hunkar

2023-01-17 17:21

developer   ~0018534

added text

Jim Luth

2023-01-17 17:35

administrator   ~0018536

Agreed to 1.04.12 Errata.

Issue History

Date Modified Username Field Change
2022-03-30 10:25 Matthias Damm New Issue
2022-07-05 16:51 Jim Luth Assigned To => Rod Stein
2022-07-05 16:51 Jim Luth Status new => assigned
2022-07-05 16:51 Jim Luth Target Version => 1.05.03 RC1
2022-11-30 06:17 Paul Hunkar Note Added: 0018210
2022-12-07 20:05 Paul Hunkar Assigned To Rod Stein => Paul Hunkar
2022-12-08 16:44 Jim Luth Note Added: 0018280
2022-12-08 16:46 Jim Luth Note Edited: 0018280
2023-01-17 17:21 Paul Hunkar Note Added: 0018532
2023-01-17 17:21 Paul Hunkar Status assigned => resolved
2023-01-17 17:21 Paul Hunkar Resolution open => fixed
2023-01-17 17:21 Paul Hunkar Note Added: 0018534
2023-01-17 17:35 Jim Luth Status resolved => closed
2023-01-17 17:35 Jim Luth Note Added: 0018536