- From: Michael Toomim <toomim@gmail.com>
- Date: Fri, 18 Oct 2024 16:01:10 -0700
- To: Lisa Dusseault <lisa@dtinit.org>, Josh Cohen <joshco@gmail.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, ietf-http-wg@w3.org
- Message-ID: <5521363a-2ba4-4213-9180-41ee2f428adb@gmail.com>
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
>
Received on Friday, 18 October 2024 23:01:17 UTC