If-Match and Weak ETags

A couple of us have run into an issue with the ETag expectations of LDP,
and are hoping that some discussion can resolve the issue.

The LDP specification (4.2.4.5)[0] has a few SHOULDs relating to client and
server use of `If-Match` headers; namely, that clients SHOULD use them on
modification, and that servers SHOULD *require* their use.

RFC 7232 (sec. 3.1)[1] states that "An origin server MUST use the strong
comparison function when comparing entity-tags for If-Match" (RFC 2616
contains the same restriction).

These two clauses seem to recommend that a server SHOULD generate strong
ETags for its resources---I don't believe a server can respect the
recommendation of 4.2.4.5 any other way.

As far as I know, no one has implemented strong ETags for content
negotiable RDF resources. Short of caching all responses between updates,
I'm not sure it's possible for an LDP server backed by a triplestore to
make the relevant guarantees about the representations it returns.

For clients, given that LDP servers are normally returning weak ETags,
using `If-Match` is not a serious option (a weak etag will never match in
strong comparison).

Should LDP servers ignore 4.2.4.5? Can we recommend an alternate pattern
for verification (`If-Unmodified-Since`)?

As further background, a key point of discussion in the LDP WG's handling
of this a thread from Feb. 2013.[2]  The message linked refers to ignoring
RFC 2616, based on a then current draft of 7232. This suggests to me that
LDP is genuinely giving bad (out of date) advice, here.

Best,

Tom

[0] https://www.w3.org/TR/ldp/#ldpr-put-precond
[1] https://tools.ietf.org/html/rfc7232#section-3.1
[2] https://lists.w3.org/Archives/Public/public-ldp-wg/2013Feb/0035.html