TS 26.532: DataReportingSession.validUntil interferes with HTTP cache control

[davidjwbbc]

Background

In TS 26.532 v18.1.0:

• 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

[rjb1000]

Change Request contributed to MBS ad hoc meeting post SA4#127-bis-e:

• TS 26.532
  • Rel-17: Decision not to correct because 5G-MAG's Reference Tools implementation uses Rel-18 as a starting point.
  • Rel-18: CR0011 "[EVEX] Essential corrections" in S4aI240051.

[rjb1000]

Change Request treated at MBS ad hoc meeting post SA4#127-bis-e:

• TS 26.532
  • Rel-18: CR0011 "[EVEX] Essential corrections" in S4aI240051.
    • Endorsed and will be resubmitted to SA4#128 for agreement.