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

Wonder Woman

On Fri, Oct 18, 2024 at 7:01 PM Michael Toomim <toomim@gmail.com> wrote:

> Lisa, this articulation of unanswered questions is *sooo* helpful. Thank
> you so very much!
>
> I am working on answers to these now. I look forward to getting to hear
> about the inchoate concerns in the next round!
>
> Thank you! Excellent work!
>
> Michael
> On 10/15/24 3:09 PM, Lisa Dusseault wrote:
>
> 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
>>
>>

-- 

---
*Josh Co*hen