Re: What is a Version?

Am 10.03.2026 um 03:01 schrieb Michael Toomim:
> Hey all,
> 
> After surveying the different approaches to Versioning in HTTP for draft 
> -04, I'm realizing there's an important design question for the group here:
> 
>            ===   Q. "What is a Version in HTTP?"  ===
> 
> Back in October 2024, Julian Reschke said "a version is a HTTP
 > ...

I *believe* I said "a version is a resource no matter whether it has a 
(HTTP) URI (yet).

 > ...
> resource".  This definition implied that, for instance, if a version 
> doesn't exist, we could return 404:
> 
> https://lists.w3.org/Archives/Public/ietf-http-wg/2024OctDec/0172.html

Yes.

> This is interesting.  Credit to Julian for recognizing the impact of 
> this question, and suggesting we work to define how these basic concepts 
> work in HTTP.
> 
> When I surveyed the existing versioning approaches in -04, I found two 
> distinct models:
> 
> First, in WebDAV Versioning, Memento, and Link Relations, a version is 
> itself a resource with its own URI:
> 
>     - In WebDAV Versioning (RFC 3253), a "version resource" is an
>       immutable HTTP resource at a server-assigned URL, created when a
>       "version-controlled resource" is checked in.  You GET the version
>       at its own URL.

Yes. (That said, this can be extended so that the client can "suggest" a 
resulting URI; we implemented that back then as a vendor extension, 
though). - 
https://greenbytes.de/tech/webdav/draft-reschke-deltav-compute-checkin-uri-05.html 
(please ignore the red markup).

> ...
> In all three, a version is a thing you dereference -- a resource at a 
> URL.  If it's missing, 404 is natural.

A version is something for which you can obtain a presentation if it has 
as a URI. If it has a HTTP URL, you can do a GET.

(Nitpicking: in theory, you can use HTTP GET to obtain a representation 
of a representation of any resource with URI if the server supports that)

> Second, we have the Last-Modified and ETag headers, and the Version and 
> Parents headers proposed in this draft.  Instead of version being a 
> resource with a URI, these simply identify a resource at a *point in 
> time*.  The version is a "coordinate of a resource."  Last-Modified and 
> ETag use coordinate as a condition for a request:
> 
>     - Last-Modified:
> 
>           GET /doc
>           If-Unmodified-Since: Tue, 15 Oct 2024 12:00:00 GMT
> 
>     - ETag:
> 
>           GET /doc
>           If-Match: "abc5"

This just means that resources can evolve over time, and that there a 
two types validators which you can use for conditional requests 
(caching, minimizing payloads, pipe-lined range requests, avoiding 
conflicts when updating).

Whether the "predecessors" can always can be called "version" isn't 
relevant for HTTP. Note that the server can *assign* URIs to these 
predecessors using the Location field.

> This draft extends that model by letting the coordinate select a 
> representation directly:
> 
>           GET /doc
>           Version: "abc5"
> 
>       or:
> 
>           GET /doc
>           Parents: "abc4"
> 
> This is analogous to how Range requests work.  When a client sends 
> `Range: bytes 500-1000`, it isn't requesting a different resource.  The 
> range is a coordinate within the resource.  We do not give ranges their 
> own URIs, such as `https://example.com/bytes/500-1000` or 
> `urn:bytes:500-1000`.

...but we could.

> Thus, it appears there are two models of "versioning" in HTTP:
> 
>    1. A version is a HTTP resource
>    2. A version is a coordinate of a HTTP resource, in time

Nope. A version is a resource that can be an HTTP resource, but doesn't 
have to.

> So the question for the group: What is the right model for HTTP?
> What is a version?
> My own view is that the coordinate model is the right foundation.  It's 
> simpler, it composes naturally with existing HTTP semantics like 

In practice, you can't define new fields that support conditional 
requests (unless you control both ends and all intermediaries). For 
conditional reads, that would be harmless (no optimizations), for range 
requests and write conflict prevention it would be a major problem.

> conditional requests and Range, and it doesn't require minting new URIs. 

Why would that be a problem?

>   But crucially, the two models are not incompatible -- the coordinate 
> model can serve as a foundation that the resource model is built on top of:
> 
>    1. Memento already combines both models.  The Memento TimeGate maps a
>       "coordinate" of time into a "version resource."  You give it a
>       wallclock time, and it gives you back a URI for the resource at
>       that time.

See...?

>    2. This versions-04 draft can be extended to URIs, by registering
>       a "Version-Type" with IANA that expresses version coordinates as
>       URIs, e.g. `Version: "https://example.com/doc^abc123"`.
> 
> So if we adopt the coordinate model, applications that need version
> resources can still build that on top.  The reverse isn't as clean --

A version *is* a resource. It may not have a URI, but it still is a 
resource.

> if we start from "a version is a resource with a URI", then simple 
> coordinates like a wallclock time or an opaque version string need to be 
> encoded into URIs, e.g.
> "urn:wallclock:Tue,%2015%20Oct%202024%2012:00:00%20GMT", which works
> against the simplicity that HTTP headers already give us.

Actually, no. If you compare adding new fields to adding more URIs, the 
latter clearly wins, as you get all benefits for free (caching, 
bookmarking, support in existing libraries etc etc).

> I'd like to hear the group's thoughts on this framing before draft -05.
> 
> Thanks!
> 
> Michael


Best regards, Julian

Received on Tuesday, 10 March 2026 14:45:14 UTC