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

[Michael Toomim <[e-mail]>]

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 <[e-mail]> 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
>     <[e-mail]> 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
>