Several redfish resource types contain constantly updating fields. E.g. sensor readings, temperature values, voltage values, various metrics, etc. Some resource types embed excerpts from other resources with constantly updated fields.
For both of these use cases it is worth utilizing weak ETags since the contents of the GET may change over time while the essential part of the resource is not changed. Such, weak etags allow not to cache all the data and not to constantly update ETags for resource, thus saving memory and compute resource.
But weak ETags bring problems along with using conditional headers like If-Match which are required by rfc7232 to use strong comparison which is never true if the resource returns weak ETags.
The OData 4.0 protocol allows weak comparison for If-Match header effectively allowing services to return weak ETags for some resources. The Redfish specification doesn't explicitly allow that.
I would like to propose changes to the Redfish specification related to ETags comparison that would explicitly allow weak ETag comparison for resources with weak ETags.
I was actually not aware of RFC7232 requiring strong ETags with the If-Match header. We've purposefully loosened our ETag requirements in the spec for exactly the reason you're highlighting. Are you recommending that we explicitly call out the fact that weak ETags are legal with the If-Match header?
I have looked through the spec as of 1.13 revision for a clause that would somehow covered this topic, but I didn't succeed. From the existing ETags section, and the If-Match, If-Non-Match table entries I couldn't deduce that the loose comparison is allowed. The only sentence about weak ETags is that the ETags mechanism supports both weak and strong validation which does not directly address the problem with the If-Match header.
So I was confused about this.
Ultimately I proceeded with adapting weak ETags anyway since the specification is heavily based on the OData 4.0 protocol, and the latter allows this loose comparison.
But I would prefer having an explicit acknowledgement in the spec. Otherwise, I believe this can leave other Redfish readers/implementers confused the same way as me.