Do I understand  correctly in that a Redfish resource should never have a weak Etag?
I am referring in particular to
"The ETag mechanism supports both strong and weak validation. If a resource supports an ETag, it shall use the RFC7232-defined ETag strong validator."
which I read as "HTTP allows for weak and strong Etags, but resources in Redfish should only use strong Etags."
This question is triggered by some hardware I am trying to use with Redfish and it returns a weak Etag for a resource, i.e. 'W/"12345"', and only accepts the full Etag, including the qualifier (!), when calling PATCH. This collides with my interpretation of the sentence above and also with how I understand IF-* preconditions should work (always fail on weak Etags).
We updated that clause in version 1.13.1 of the spec to remove the "strong" requirement. We realized that strong ETags have specific rules for how they're used that conflict with some of the semantics of Redfish. For example, if a strong ETag were to be used in a Manager resource, the value of "DateTime" will be changing every second, thus invalidating the current ETag every time the value changes, making it impossible to PATCH.
Ultimately from a client's perspective, the ETag you read in the response will need to be provided in the request header when attempting to PATCH the resource, regardless of it being strong or weak. We simply expect the client to treat it as an opaque value. So, if the service provides you with a weak ETag, that same weak ETag would be in your request header for the PATCH operation.
Yes, we realize it's non-conformant. However, we think that for the sake of usability, we'd want to allow for weak ETags in request headers to avoid requiring clients to interpret the ETags themselves.
The specification is clear with regards to clients supplying the same ETag found in GET responses in a subsequent PATCH/PUT operation. If you're encountering services that require reformatting the ETag for the request, I suggest reaching out to the appropriate vendors to raise the issue.