Re: New Version Notification for draft-toomim-httpbis-versions-00.txt

Hey Michael,

A few thoughts...

First, I agree that the concept of versioning hasn't been thought about
enough, and this is definitely a 'good idea (TM)'.

However, I have a few concerns:

*1.1.2 Versioning with ETag*

Because ETags are, by definition, unformatted, while it's true to say that
you often can't rely on them to establish a version, that's entirely
dependent on the format chosen by the user. An ETag *could* validly be
specified as a date:

    ETag: "Sat, 6 Jul 2024 07:28:00 GMT"

or as a version number:

    ETag: "v1.0.2"

or as a random string:

    ETag: "Michael is cool"

IOW, it's totally possible for a site that cares about versioning to use a
format that specifies a version number. I recognize this isn't
*necessarily* the case, but it helps to be clear here. It should be noted
that many web servers that include the creation of ETags natively (e.g.
Apache) include an effective version as part of the ETag.

Likewise ETags don't *have* to be sensitive to encoding - there's nothing
to stop a server from sending the exact same ETag for two
differently-encoded copies of the same underlying resource. It's just that
they typically do.

None of this is to say that ETags are better or worse than you describe -
just to say that they *can* be better than they are.

*2.3 Version and Parents headers*

You state that the Parents header can include multiple parents (parents,
grandparents, great-grandparents?) and provide an example:

    Parents: "ajtva12kid", "cmdpvkpll2"

and then say "Any version can be recreated by first merging its parents,
and then applying the its update onto that merger." (Nit: additional "the"
in this sentence). However, you also say that the order of the values in a
Parents header makes no difference.

Maybe I'm missing something, but in this scenario, how could that work?
Using your example above, here are two possible scenarios:

* Version "ajtva12kid" is earlier. Version "cmdpvkpll2" is later and
contains an additional section of HTML
* Version "ajtva12kid" is earlier and contains a section of HTML which is
removed in the later "cmdpvkpll2" version

If you merge the two parent versions, then does the outcome (onto which you
will apply the update) include that section of HTML?

I guess it just makes sense to me to have the order in the Parents have
some meaning - whether oldest first or last. Or you could specify that both
Version and Parent values must be integers.

2.4.3 PUT a new version

This seems like it could lead to either race conditions or some other issue
with duplicate Version values. Surely it's better to have the client submit
a new version of a resource (passing the Parents header but *not* passing
the Version header) and have the server, which is presumably the prime
source of versioning truth, calculate a version (perhaps after retrieving
other PUT requests from other clients) and return that value in the Version
response header?

I see you discuss this later with the Current-Version header, so perhaps
you covered this and my old eyes missed it.

Rory


On Mon, Jul 15, 2024 at 6:31 PM Michael Toomim <toomim@gmail.com> 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
>