Memento protocol

[hvdsomp]

When it comes to resource versioning, it seems appropriate that braid would reference RFC7089: HTTP Framework for Time-Based Access to Resource States -- Memento.

[toomim]

Yeah, that would be a good idea, thanks!

I've looked into Memento a bit, and the first big blocker is that it represents time using a computer's local time. Unfortunately, that doesn't work for synchronization over a distributed network, because time becomes relative, and you can't rely on clocks. Instead, you need to construct a partial order of events.

I other words, Memento models time like:

  o  - 4:38pm June 4rd 2023
  |
  o - 11:30am July 2nd 2023
  |
  o - 2:02pm August 1 2023
  |
  v

But for distributed sync, we need something like:

        o - x35
       / \
h3u - o   o - 7bx
       \ /
        o - 73h

In the long run, though, we'd like to be able to support all the features we need for versioning and time in HTTP. For instance, we want to support local times as time identifiers too, so this works in Braid:

        o - 11:30am July 1 2023
       / \
h3u - o   o - 8:32pm July 9 2023
       \ /
        o - 10:55am August 4 2023

There might be useful features in Memento for history representations that we don't have in Braid, and should consider merging in. What do you think?

[toomim]

^ Updated my comment above

[hvdsomp]

@toomim I do understand the difference in perspective. Before I share some ideas re how Memento could still be used in relation to braid, I have a question: While version identifiers are crucial in braid, is it safe to assume that the datetimes of these versions are available too?

[hvdsomp]

I had a look at the HTTP Resource Versioning I-D and was wondering whether the combination of two existing headers - memento-datetime and eTag - could be re-purposed to identify versions. The I-D introduces the Version header (in responses) for this purpose.

To request a version, the combination of the existing accept-datetime and a to-be-defined accept-eTag might be an alternative to the Version header (in requests).

An interesting result of this approach would be the ability to issue requests with only accept-datetime or only accept-eTag to systems that support both. Such requests could result in HTTP 300 Multiple Choices responses with, respectively:

• a choice of versions with the same memento-datetime yet different eTags
• a choice of versions with the same eTag yet different memento-datetime

I see no alternative in existing approaches to the proposed Parent header.

As a side note regarding the proposed Version header: it feels like there should be an Accept-Version for requests and a Version header for responses.