Review of draft-toomim-httpbis-versions-00

[Michael Toomim <[e-mail]>]

I'm also merging Pierre Chapuis' comments into this thread. Pierre is 
cc'd, and we can respond here.

------------------
-- Pierre Chapuis: --
------------------

Hello everyone,

this email got me interested. I have been silently following the 
progress on Braid for a while. I have worked with various data 
replication and synchronization techniques (including CRDTs and others 
<https://blog.separateconcerns.com/2017-05-07-itc.html>) and a HTTP 
standard for resumable feeds is something I have wanted for a long time, 
to support use cases similar to HTTP Feeds <https://www.http-feeds.org>.

Here is a small observation I have from reading the draft. In "4. 
Version-Type Header", regarding the vector-clock type, did you consider 
the alternative of just using parents instead of the complex dedicated 
version format, where each Parent would be of the form "agentidX: 
counterX"? If the data is modified, the Version response header could 
potentially be used for the current "server" node.

For instance, considering a CRDT implementation, if the "client" Bob is 
at {alice: 2, bob: 2, charlie: 3} and the "server" Alice is at {alice: 
3, bob: 2, charlie: 4}, and Bob submits a new version, the request 
headers could be:

Version: "bob: 3"
Parents: "alice: 2", "bob: 2", "charlie: 3"

and the response headers could would be:

Parents: "alice: 3", "bob: 3" , "charlie: 4"

Best,

-- 
Pierre Chapuis

On 7/15/24 6:26 PM, Michael Toomim wrote:
>
> Hi everyone in HTTP!
>
> Last fall we solicited feedback on the Braid State Synchronization 
> proposal [draft 
> <https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http-04>, 
> slides 
> <https://datatracker.ietf.org/meeting/118/materials/slides-118-httpbis-braid-http-add-synchronization-to-http-00>], 
> which I'd summarize as:
>
>     "We're enthusiastic about the general work, but the proposal is
>     too high-level. Break the spec up into multiple independent specs,
>     and work bottom-up. Focus on concrete 'bits-on-the-wire'."
>
> So I'm breaking the spec up, and have drafted up the first chunk for 
> you. I would very much like your review on:
>
>     *Versioning of HTTP Resources*
>     draft-toomim-httpbis-versions
>     https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-versions-00
>
> Versioning is necessary for state synchronization—and occurs in a 
> range of HTTP systems:
>
>   * Caching
>   * Archiving
>   * Version Control
>   * Collaborative Editing
>
> Today, HTTP has resource versions in the Last-Modified and ETag 
> headers, and sometimes embeds versions in URLs, like with WebDAV. Each 
> of these options serves some needs, but also has specific limitations. 
> An improved general approach is proposed, which provides new features, 
> that could enable cool new applications, such as incrementally-updated 
> RSS feeds, and could simplify existing specifications, such as 
> resumeable uploads, and history compression in OT/CRDT algorithms.
>
> I would love to know if people find this work interesting. I think we 
> could improve performance, interoperability, and be one step closer to 
> having Google Docs power within HTTP URLs.
>
> Michael
>
> -------- Forwarded Message --------
> Subject: 	New Version Notification for 
> draft-toomim-httpbis-versions-00.txt
> Date: 	Mon, 08 Jul 2024 11:02:11 -0700
> From: 	[e-mail]
> To: 	Michael Toomim <[e-mail]>
>
>
>
> A new version of Internet-Draft draft-toomim-httpbis-versions-00.txt 
> has been
> successfully submitted by Michael Toomim and posted to the
> IETF repository.
>
> Name: draft-toomim-httpbis-versions
> Revision: 00
> Title: HTTP Resource Versioning
> Date: 2024-07-08
> Group: Individual Submission
> Pages: 19
> URL: https://www.ietf.org/archive/id/draft-toomim-httpbis-versions-00.txt
> Status: https://datatracker.ietf.org/doc/draft-toomim-httpbis-versions/
> HTMLized: 
> https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-versions
>
>
> 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 sketches a more general versioning
> approach that can enable new use-cases for HTTP.
>
>
>
> The IETF Secretariat
>
>