Fwd: New Version Notification for draft-toomim-httpbis-versions-04.txt

Hi all,

I have updates on HTTP Resource Versioning, last discussed on-list in February 2025, and presented at IETF 120 in Vancouver. I took some time off for my health, but am back at work. I'll be at IETF 125 in Shenzhen.

This is the first of the component specs broken out from Braid-HTTP, as the group requested at IETF 118. I'm also developing the companion specs (Subscriptions, Multiresponse, and Updates), but this versioning spec is where I'd most value review right now. The published -04 is here:

https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-versions-04

The spec itself is simple: a Version and Parents header for requests and responses, identifying where a resource's state sits in its history. This is useful on its own for everyday things like cache consistency, history archives, optimistic concurrency, and requesting incremental updates since a known version. But the same headers are general enough to also support the most ambitious use-cases; all the way up to fully distributed, eventually-consistent OT/CRDT collaborative editing. These simple headers provide a general power.

I'm looking for critique as we integrate this into HTTP: problems, things to test, and gaps I should be filling. I have some specific questions below.

What's changed since -02:

Julian suggested the "309 Version Unknown Here" status code should be a 4xx-series error rather than a 3xx redirect. We agreed, and it's now 432 Version Not Found. This is analogous to 416 Range Not Satisfiable for range requests— it indicates the client asked for a version that the server did not have.

We added a clearer comparison with existing versioning mechanisms (Last-Modified, ETags, Memento, WebDAV, Link Relations) including a feature table showing what each approach does and doesn't support (Section 1.3.4). We also distinguished Event IDs from Version IDs with a formal definition (Section 2.1.2).

For -05 (to be published when the submission window reopens), I'm reorganizing the document to put the specification before the prior art analysis, adding a section on interaction with conditional request headers (If-Match, If-None-Match), specifying unicode support, and filling in Security Considerations. The core mechanism is unchanged.

Implementation updates:

We have two independent protocol implementations — one in JavaScript and one in Emacs Lisp — that interoperate in production, giving us confidence that the spec is implementable and unambiguous. We also have experimental implementations in Rust and Haskell.

The JavaScript implementation is used for a range of applications: filesystem sync over HTTP [1], realtime-updated webpages, including a live <img> polyfill [2], collaborative text editing, eventually-consistent binary sync [3], and a Chrome extension [4]. The Emacs Lisp implementation [5] is fully standalone and supports collaborative editing of https:// resources, synchronizing with other Emacs and the JavaScript-based clients.

These are used in production on braid.org.

[1] https://github.com/braid-org/braidfs
[2] https://github.com/braid-org/braid-blob/?tab=readme-ov-file#live-image-polyfill
[3] https://github.com/braid-org/braid-blob
[4] https://github.com/braid-org/braid-chrome
[5] https://github.com/braid-org/braid-emacs

Cache testing:

As reported previously [6], we ran the Version and Parents headers through real-world intermediaries at https://cache-tests.braid.org. This led to the intermediary instructions in Section 4 of the spec. I'd love to expand this testing — what other intermediaries, CDNs, or edge cases should we be running these headers through? This is an area where the group's expertise would really help.

[6] https://lists.w3.org/Archives/Public/ietf-http-wg/2024OctDec/0131.html

Questions for the group:

Status code 432: Is a new code the right approach? The analogy with 416 Range Not Satisfiable feels right to us: a version range is like a byte range, and there's a parallel error when the server can't satisfy it. But we could also see this as 404 with response headers indicating which versions weren't found. What does the group think?
What should we be testing against, or trying to break? We've tested with caches, but I'm not an expert in the full range of HTTP intermediaries, CDNs, and edge cases that exist in the wild. What should we be throwing at this?
For -05, I'm adding conditional header interaction, security considerations, unicode support, and a better document structure. [7] What other gaps do reviewers see in the spec?

[7] https://github.com/braid-org/braid-spec/blob/master/draft-toomim-httpbis-versions-05.txt

Thanks!
Michael

> Begin forwarded message:
> 
> From: internet-drafts@ietf.org
> Subject: New Version Notification for draft-toomim-httpbis-versions-04.txt
> Date: March 2, 2026 at 1:57:01 PM HST
> To: "Michael Toomim" <toomim@gmail.com>
> 
> A new version of Internet-Draft draft-toomim-httpbis-versions-04.txt has been
> successfully submitted by Michael Toomim and posted to the
> IETF repository.
> 
> Name:     draft-toomim-httpbis-versions
> Revision: 04
> Title:    HTTP Resource Versioning
> Date:     2026-03-02
> Group:    Individual Submission
> Pages:    30
> URL:      https://www.ietf.org/archive/id/draft-toomim-httpbis-versions-04.txt
> Status:   https://datatracker.ietf.org/doc/draft-toomim-httpbis-versions/
> HTMLized: https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-versions
> Diff:     https://author-tools.ietf.org/iddiff?url2=draft-toomim-httpbis-versions-04
> 
> Abstract:
> 
>   HTTP resources change over time.  Each change to a resource creates a
>   new "version" of its state.  HTTP systems often need a way to
>   identify, read, write, navigate, and/or merge these versions, in
>   order to implement cache consistency, create history archives, settle
>   race conditions, request incremental updates to resources, interpret
>   incremental updates to versions, or implement distributed
>   collaborative editing algorithms.
> 
>   This document analyzes existing methods of versioning in HTTP,
>   highlights limitations, and specifies a more general versioning
>   approach that can enable new use-cases for HTTP.  An upgrade path for
>   legacy intermediaries is provided.
> 
> 
> 
> The IETF Secretariat
> 
>