Re: Review of draft-toomim-httpbis-versions-00

Pierre, thanks for these juicy thoughts!

First, your work on HTTP Feeds looks very relevant to 104 Multiresponse 
idea (Section 2.4.4 
<https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-versions#section-2.4.4>) 
that is slated for a future spec. I'd love to hear your thoughts!

As for vector clocks, what you have just suggested is very interesting— 
that is a way to express the same History, with a different 
Version-Type! (Albeit, one that bends the constraint that parents' 
cannot be ancestors of each other that we've been discussing elsewhere.)

Although this contains the same history as the Vector-Clock example, I 
would not call these version IDs themselves Vector-Clocks. One cool 
thing about a Vector-Clock is that you can compare any two vector clocks 
in O(peers) time, without doing any O(n) traversals of the historical 
time DAG! If you have a small set of peers, this lets you compare order 
in O(1) time. This means you don't need to specify any parents at all in 
your messages. All ordering can be deduced from the Version header 
alone. That's kinda cool, for the systems that need that.

Michael

On 7/22/24 11:45 AM, Michael Toomim wrote:
>
> 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:  internet-drafts@ietf.org
>> To:  Michael Toomim <toomim@gmail.com>
>>
>>
>>
>> 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
>>
>>