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

I am already on the list, and I love the work going on with braid and with
HTTP subscriptions etc.  To be honest this is not my quest at the moment (I
try to limit the number of possibly-impossible things I'm actively trying
to make happen at one time), but I'm happy to help out those who have
decided to pursue this quest.

I support working on the Version and Parents proposal in particular, and I
have hope that we can make it good.  At present, the draft needs a bunch of
work to be made into an implementable, interoperable specification.  Right
now it's enough detail to describe something and see if we agree to work
together to figure out the real details -- but it does not yet have
nearly enough detail for independent implementers to go off and implement
and hope to interoperate.  Some of the things needed:

1. A section on how the Version and Parent headers are expected to work
with intermediaries when used with GET, that answers
*   What do we expect  versioning-unaware intermediaries of different kinds
to do if they follow the HTTP standard properly;
* what versioning-unaware intermediaries actually seem to be doing,
* How to detect if a versioning-unaware intermediary has served a cached
document that doesn't meet the semantics of the request with the Version
header
* Remedies - ways to ensure a versioning-unaware intermediary does not try
to serve the requests or ways to re-request in a way the versioning-unaware
intermediary does not continue to serve the wrong thing
* Could there be versioning-aware intermediaries - could a caching
intermediary legitimately cache HTTP resource versions and return them
* Somewhat of the same work above, repeated, for how intermediaries are
expected to behave with PUT and Parent header
 * To be clear, I hope that we can live with SOME intermediary breakage.
We just need to explain how much and what we've done to avoid.

3.  What are the exact format and semantic meaning of the version IDs.  Can
I have my server issue a version ID which is the question-mark character
repeated 10000 times? or could the client reasonably assume that it is
being fucked with?
* How long can they be
*  what characters are valid.
* Are they sortable?  (Does sorting mean anything?) I ask because of the
critique that "there is no way to order versions by ETag"

2. Section on the  Version and Parent headers themselves
* what values are permissible.  How long must the server receiving them be
able to handle, etc etc.
* Are there any special values like "*" or "?"
* How many Parent IDs is permissible on one resource in a 200 OK GET
response?
* How many Parent IDs is permissible on a PUT request?

4. What is the semantics of the Version header in all the HTTP Request and
Response types in which it's expected to appear.  Which means Section 2.3
will probably be significantly longer when the different options are broken
out.
* Are there request and response types in which it's inappropriate to put
the Version and Parent header?
* The meaning on POST is important to nail down. can the Parent header be
sent on a POST with multipart/form-data ? What would that mean?
* What if a client issues a GET with a version that doesn't exist, however,
the server could handle the request if it had a legit version ID?  You say
the server "can ignore" but that seems more for a server that isn't doing
versioning on this resource. What about if it can tell that the version is
wrong? Is returning the whole resource the helpful thing in this case?
* Are there other reasons that GETting a version might fail? Can servers
delete old versions? Can servers put different access control on different
versions?
* While a loose fail-back mode might be OK for GET, it's harmful for PUT.
What errors should a server use if it can't apply the PUT or PATCH to the
exact version or parents specified?

5. Discoverability.
* How does the client discover if a server supports the Version and the
Parent header?
* Are servers going to be able to support some parts of this and not
others?  E.g. would a server be compliant if it only supported linear
versioning? And if so, how would it indicate that to the client -- that
multiple Parent IDs on a PUT are not supported?
* Would a server be compliant if it allowed small updates ("Add this
sentence at this location on this version") but did not respond to GET
requests of prior versions with the prior version?
* Would a server be compliant if it allowed PATCH to update the versioned
resource but not PUT? The other way around?
* Is a versioning-unaware client able to send PUT requests and modify the
resource?  does that modify the whole resources?  Is there a need for the
client to tell the server "Don't worry I know what I'm doing" and that it
understands Version and Parent concepts?

I have more concrete questions I haven't written down yet, and I also have
inchoate concerns ( things like resource URLs being tied to versions or not
- can URLs vary and still share the same version history) , and I would
like to see which use cases are definitely going to be supported and make
sure the work solves those. But I have definitely listed too many questions
already.

It's like developing a server or service from scratch - your first version
that works in a demo in friendly hands is great, and there's still 80% of
the work remaining to handle edge cases and combinations of features and
actual attacks. It's pretty daunting but the Braid work is a really good
start.

Lisa

On Tue, Oct 15, 2024 at 1:55 PM Josh Cohen <joshco@gmail.com> wrote:

> After Vancouver, I had a conversation with Lisa Dussealt, author of
> RFC4918, HTTP Extensions for Web Distributed Authoring and Versioning
> (WebDAV), and CalDAV, and asked if she might make herself available at
> least as an advisor.
> I'll leave it to Lisa to say Hi.
> (Lisa will probably need to join the wg list)
>
> On Sat, Jul 27, 2024 at 4:35 AM Julian Reschke <julian.reschke@gmx.de>
> wrote:
>
>> On 16.07.2024 03:26, 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
>> > ...
>>
>> I believe it would be good to work out the differences to RFC 3253
>> (https://greenbytes.de/tech/webdav/rfc3253.html); even if only in a
>> short paragraph.
>>
>> Best regards, Julian
>>
>>
>
> --
>
> ---
> *Josh Co*hen
>
>