Clauses 4.2.4.2, 4.2.5.2 and 4.3.2.2 state that a validUntil property should be added by the Data Collection AF with a time in the future to new DataReportingSession objects.
Clauses 4.2.4.3.2, 4.2.5.3.2 and 4.3.2.3.2 state that the validUntil time is in the future, indicating that this field can be updated (and must be updated when the time has expired) when requesting retrieval of the DataReportingSession.
Table 7.3.2.1-1 indicates that the validUntil property of DataReportingSession is an optional field indicating when the DataReportingSession will expire.
Clause B.4 indicates that the validUntil property of DataReportingSession is an optional DateTime field.
Problem description
The validUntil field in a DataReportingSession is used to indicate the current expiry time of the DataReportingSession for caching and update on the client; this is logically equivalent to the use of the Expires HTTP header.
The ETag HTTP header provides a unique identifier for a specific HTTP body response (in this case DataReportingSession JSON text) in the form of an entity tag. The Last-Modified date time HTTP header is used to indicate when the body last changed on the server. Each of these headers change when the body of the response changes.
Because the retrieve operation needs to provide an updated validUntil property with the new object expiry time, this results in a new response body to every request (even if only the validUntil property has changed) and hence new Etag and Last-Modified header values! This prevents the use of HTTP conditional GET using the If-None-Match of If-Modified-Since request headers, which would normally allow a client to detect whether the DataReportingSession has changed.
Conclusion: Including the validUntil property in the DataReportingSession response body negates efficient state synchronisation of the DataReportingSession object between the data reporting client and the Data Collection AF. A "304 Not Modified" response will never be returned by the Data Collection AF because the validUntil property will always change.
Suggested solution
Deprecate the use of the (currently optional) validUntil property in favour of the use of Expires or Cache-Control: max-age= headers. By omitting the validUntil property from the DataReportingSession object, the contents become stable and the ETag and Last-Modified headers can truely reflect when the DataReportingSession has changed. Client update times can be controlled by using the Expires or Cache-Control headers to independently indicate when the DataReportingSession next needs refreshing.
Remove the text from clauses 4.x indicating the use of validUntil and replace with text indicating the use of Etag, Last-Modified headers and either the Expires or Cache-Control headers in responses and the use of If-None-Match and If-Modified-Since headers in update retrieval requests.
Mark the validUntil property in table 7.3.2.1-1 as deprecated and indicate that the Expires or Cache-Control HTTP response header values should be used instead.
Without the validUntil property present the DataReportingSession object becomes stable and only reflects changes to the reporting parameters.
Additional context
IETF RFC 7232 - Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
Background
In TS 26.532 v18.1.0:
validUntil
property should be added by the Data Collection AF with a time in the future to newDataReportingSession
objects.validUntil
time is in the future, indicating that this field can be updated (and must be updated when the time has expired) when requesting retrieval of theDataReportingSession
.validUntil
property ofDataReportingSession
is an optional field indicating when theDataReportingSession
will expire.validUntil
property ofDataReportingSession
is an optionalDateTime
field.Problem description
The
validUntil
field in aDataReportingSession
is used to indicate the current expiry time of theDataReportingSession
for caching and update on the client; this is logically equivalent to the use of theExpires
HTTP header.The
ETag
HTTP header provides a unique identifier for a specific HTTP body response (in this caseDataReportingSession
JSON text) in the form of an entity tag. TheLast-Modified
date time HTTP header is used to indicate when the body last changed on the server. Each of these headers change when the body of the response changes.Because the retrieve operation needs to provide an updated
validUntil
property with the new object expiry time, this results in a new response body to every request (even if only thevalidUntil
property has changed) and hence newEtag
andLast-Modified
header values! This prevents the use of HTTP conditionalGET
using theIf-None-Match
ofIf-Modified-Since
request headers, which would normally allow a client to detect whether theDataReportingSession
has changed.Conclusion: Including the
validUntil
property in theDataReportingSession
response body negates efficient state synchronisation of theDataReportingSession
object between the data reporting client and the Data Collection AF. A "304 Not Modified" response will never be returned by the Data Collection AF because thevalidUntil
property will always change.Suggested solution
validUntil
property in favour of the use ofExpires
orCache-Control: max-age=
headers. By omitting thevalidUntil
property from theDataReportingSession
object, the contents become stable and theETag
andLast-Modified
headers can truely reflect when theDataReportingSession
has changed. Client update times can be controlled by using theExpires
orCache-Control
headers to independently indicate when theDataReportingSession
next needs refreshing.validUntil
and replace with text indicating the use ofEtag
,Last-Modified
headers and either theExpires
orCache-Control
headers in responses and the use ofIf-None-Match
andIf-Modified-Since
headers in update retrieval requests.validUntil
property in table 7.3.2.1-1 as deprecated and indicate that theExpires
orCache-Control
HTTP response header values should be used instead.Without the
validUntil
property present theDataReportingSession
object becomes stable and only reflects changes to the reporting parameters.Additional context
IETF RFC 7232 - Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests