Remove specific ETag requirements and defer to RFC 9110

[acoburn]

Resolves #62

This removes the specific requirements related to ETags, as discussed in #62 and at the WG meeting on 2026-10-03.

Since RFC 9110 already recommends the use of concurrency controls (such as ETags), the consensus was to defer to that specification rather than restate ETag-specific requirements. This will allow for the possibility of using CRDTs and other concurrency control mechanisms beyond what is outlined in RFC 9110.

---

Preview | Diff

[raucao]

A SHOULD is not strong enough to guarantee that sync mechanisms have a means of tracking resource changes on the remote storage. This is not just deferring to the existing spec (which is a good thing) for the details, but turning ETags from a required feature into something optional ,which will break interop with any sync protocols that require a remote version tag.

Maybe I missed something. In that case, how does a client track remote changes in LWS?

[acoburn]

The Fedora project found that ETags were insufficient for their needs. The Braid-HTTP synchonization protocol (CRDTs) uses a Version header which is similar to ETags. In both cases, ETags are deemed not suitable. While we do want to strongly encourage the use of concurrency controls, the requirements should not be limited to the use of ETags.

By changing the ETag requirement from MUST to SHOULD, we allow for these alternative forms of concurrency controls. And a MUST requirement for unspecified concurrency controls (i.e. the current text) is unclear. A SHOULD requirement for particular concurrency controls is much more clear and establishes a consistent baseline across all parts of the protocol.

[raucao]

I'm not sure I understand. So there's a required version header that clients can use instead?

[acoburn]

Different LWS server implementations will likely target different use cases or deployment scenarios. Some may also implement specifications that support CRDTs (such as the Braid protocol), and in those cases, yes, a Version header would be used by clients.

The important thing for LWS is that we provide a baseline for interoperability without making it difficult or impossible for some implementations to support extensions in various different directions.

[raucao]

So the base protocol will not have any means for clients to reliable sync the stored data without using unspecified extensions that may or may not work on any given LWS the user may want to connect to an application?

[acoburn]

I will remind you that offline access and synchonization is not a high priority for the LWS working group at this time.

The question I would ask is this: does the current specification prevent a server implementation from offering features for that use case? With this change, I would argue that the LWS protocol is better positioned for certain, specialized LWS implementations to offer precisely these features. Will all LWS implementations offer these features? No, and the LWS group has already established that doing so is out of scope.

[raucao]

It's a simple Etag on a HTTP resource. There's no big "feature" added, and it's much simpler than many of the other base protocol requirements.

If any and all sync is completely out of scope for the base protocol, then I would personally consider the protocol to be fundamentally flawed as a viable Web storage solution. "Implementers may do whatever they want outside of the base protocol" is not a credible solution to this problem in my opinion.

Just my 2 cents. Please resolve the conversation if everyone here agreed on sync being completely out of scope.

[acoburn]

I would fully expect most LWS implementers to include and support ETags. They remain a SHOULD in RFC 9110, which means they are a SHOULD in LWS. ETags are also a somewhat blunt tool, especially for advanced synchronization scenarios, and in those cases, ETags may very well get in the way, hence the SHOULD.

Please also keep in mind that ETags are not entirely "simple". In the context of content-negotiated, writable resources without a necessarily fixed byte arrangement (i.e. RDF), adherence to RFC 9110 can require a server to use weak ETags on GET responses, which are unusable for subsequent writes. This is why the Fedora project invented an entirely new header, and why we are careful about MUST requirements.

I am happy to take your thoughts into consideration, but I would also request that you consider that the WG's charter ends in less than 4 weeks, and there are many items that have a much higher priority than synchronization. If everyone with a use case appears at the end of a two year charter, insisting that priorities need to change, we will never complete even the most basic protocol.

[TallTed]

For unknown reasons, lines 89 and 90 of lws10-core/Operations/read-resource.md now appear to end with ^M (aka CR). I cannot fix this, but I suspect at least one reader of this comment can.

[acoburn]

Not sure how that happened, but I removed all ^M line endings