New Versioning Proposal

[Michael Toomim]

Hi everyone in HTTP!

Last fall we solicited feedback on the Braid State Synchronization proposal [draft, slides], 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:	interne...@ietf.org
To:	Michael Toomim <too...@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

[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) and a HTTP standard for resumable feeds is something I have wanted for a long time, to support use cases similar to HTTP Feeds.

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