Resent-Date: Sat, 19 Oct 2024 00:04:30 +0000
Resent-Message-Id: <E1t1wxK-001Nm5-1k@mab.w3.org>
Received-SPF: pass (pan.w3.org: domain of gmail.com designates 2607:f8b0:4864:20::232 as permitted sender) client-ip=2607:f8b0:4864:20::232; envelope-from=joshco@gmail.com; helo=mail-oi1-x232.google.com;
MIME-Version: 1.0
References: <172046173132.445281.15041630415895010148@dt-datatracker-5f88556585-j5r2h>
 <ff54cd4f-c30e-4447-8744-3297e53b74be@gmail.com> <2f2d41cd-94ca-48d3-8ee7-575bcf241f87@gmx.de>
 <CAF3KT4R=iaqZvJ8y_4jemPn1eGFbMPsGpnU8kAZe4yWetAf-XA@mail.gmail.com>
 <CAH212UOqi4Uj+s=wrwEPDf8wVefY9sN=oZhAewxfB5EFbkfO-Q@mail.gmail.com> <5521363a-2ba4-4213-9180-41ee2f428adb@gmail.com>
In-Reply-To: <5521363a-2ba4-4213-9180-41ee2f428adb@gmail.com>
From: Josh Cohen <joshco@gmail.com>
Date: Fri, 18 Oct 2024 20:04:12 -0400
Message-ID: <CAF3KT4QmqS8Zcdr_3=iH2ggSBOwJ=7ynyxwDFOXjO10wqqbCYQ@mail.gmail.com>
To: Michael Toomim <toomim@gmail.com>
Cc: Lisa Dusseault <lisa@dtinit.org>, Julian Reschke <julian.reschke@gmx.de>, ietf-http-wg@w3.org
Content-Type: multipart/alternative; boundary="0000000000008663460624c92962"
Subject: Re: Fwd: New Version Notification for draft-toomim-httpbis-versions-00.txt
Archived-At: <https://www.w3.org/mid/CAF3KT4QmqS8Zcdr_3=iH2ggSBOwJ=7ynyxwDFOXjO10wqqbCYQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

--0000000000008663460624c92962
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Wonder Woman

On Fri, Oct 18, 2024 at 7:01=E2=80=AFPM Michael Toomim <toomim@gmail.com> w=
rote:

> 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 wit=
h
> 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.  Righ=
t
> 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 tr=
y
> to serve the requests or ways to re-request in a way the versioning-unawa=
re
> 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 tha=
t
> 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 b=
e
> 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 an=
d
> Response types in which it's expected to appear.  Which means Section 2.3
> will probably be significantly longer when the different options are brok=
en
> 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 helpf=
ul
> 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 differen=
t
> 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 hav=
e
> inchoate concerns ( things like resource URLs being tied to versions or n=
ot
> - 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 questio=
ns
> already.
>
> It's like developing a server or service from scratch - your first versio=
n
> 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=E2=80=AFPM Josh Cohen <joshco@gmail.com> wro=
te:
>
>> 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=E2=80=AFAM Julian Reschke <julian.reschke@g=
mx.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-0=
4>,
>>> slides <
>>> https://datatracker.ietf.org/meeting/118/materials/slides-118-httpbis-b=
raid-http-add-synchronization-to-http-00>],
>>> which I'd summarize as:
>>> >
>>> >     "We're enthusiastic about the general work, but the proposal is t=
oo
>>> >     high-level. Break the spec up into multiple independent specs, an=
d
>>> >     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
>>
>>

--=20

---
*Josh Co*hen

--0000000000008663460624c92962
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Wonder Woman</div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Fri, Oct 18, 2024 at 7:01=E2=80=AFPM Micha=
el Toomim &lt;<a href=3D"mailto:toomim@gmail.com">toomim@gmail.com</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

 =20
   =20
 =20
  <div>
    <p>Lisa, this articulation of unanswered questions is *sooo*
      helpful. Thank you so very much!</p>
    <p>I am working on answers to these now. I look forward to getting
      to hear about the inchoate concerns in the next round!</p>
    <p>Thank you! Excellent work!<br>
    </p>
    <p>Michael<br>
    </p>
    <div>On 10/15/24 3:09 PM, Lisa Dusseault
      wrote:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <div dir=3D"ltr">I am already on the list, and I love the work going
        on with braid and with HTTP subscriptions etc.=C2=A0 To be honest
        this is not my quest at the moment (I try to limit the number of
        possibly-impossible things I&#39;m actively=C2=A0trying to=C2=A0mak=
e happen at
        one time), but I&#39;m happy to help out those who have decided to
        pursue this quest.
        <div><br>
        </div>
        <div>I support working on the Version and Parents=C2=A0proposal in
          particular, and I have hope that we can make it good.=C2=A0 At
          present, the draft needs a bunch of work to be made into an
          implementable, interoperable specification.=C2=A0 Right now it=
9;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=C2=A0enough detail for independent
          implementers=C2=A0to go off and implement and hope to
          interoperate.=C2=A0 Some of the things needed:=C2=A0</div>
        <div><br>
        </div>
        <div>1. A section on how the Version and Parent headers are
          expected to work with intermediaries when used with GET, that
          answers</div>
        <div>*=C2=A0 =C2=A0What do we expect=C2=A0 versioning-unaware inter=
mediaries of
          different kinds to do if they follow the HTTP standard
          properly;=C2=A0<br>
        </div>
        <div>* what versioning-unaware intermediaries actually seem to
          be doing,=C2=A0</div>
        <div>* How to detect if a versioning-unaware intermediary has
          served a cached document that doesn&#39;t meet the semantics of
          the request with the Version header</div>
        <div>* 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</div>
        <div>* Could there be versioning-aware intermediaries - could a
          caching intermediary legitimately cache HTTP resource versions
          and return them=C2=A0</div>
        <div>* Somewhat of the same work above, repeated, for how
          intermediaries are expected to behave with PUT and Parent
          header</div>
        <div>=C2=A0* To be clear, I hope that we can live with SOME
          intermediary breakage.=C2=A0 We just need to explain how much and
          what we&#39;ve done to avoid.</div>
        <div><br>
        </div>
        <div>3.=C2=A0 What are the exact format and semantic meaning of the
          version IDs.=C2=A0 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?=C2=A0</div=
>
        <div>* How long can they be</div>
        <div>*=C2=A0 what characters are valid.=C2=A0</div>
        <div>* Are they sortable?=C2=A0 (Does sorting mean anything?) I ask
          because of the critique that &quot;there is no way to order
          versions by ETag&quot;</div>
        <div><br>
        </div>
        <div>2. Section on the=C2=A0 Version and Parent headers themselves<=
/div>
        <div>* what values are permissible.=C2=A0=C2=A0How long must the se=
rver
          receiving them be able to handle, etc etc.</div>
        <div>* Are there any special values like &quot;*&quot; or &quot;?&q=
uot;=C2=A0</div>
        <div>* How many Parent IDs is permissible on one resource in a
          200 OK GET response?=C2=A0</div>
        <div>* How many Parent IDs is permissible on a PUT request?=C2=A0</=
div>
        <div><br>
        </div>
        <div>4. What is the semantics of the Version header in all the
          HTTP Request and Response types in which it&#39;s expected to
          appear.=C2=A0 Which means Section 2.3 will probably be
          significantly longer when the different options are broken
          out.=C2=A0=C2=A0</div>
        <div>* Are there request and response types in which it&#39;s
          inappropriate to put the Version and Parent header?=C2=A0=C2=A0</=
div>
        <div>* 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?</div>
        <div>* What if a client issues a GET with a version that doesn&#39;=
t
          exist,=C2=A0however, the server could handle the request if it ha=
d
          a legit version ID?=C2=A0 You say the server &quot;can ignore&quo=
t; but that
          seems more for a server that isn&#39;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?</div>
        <div>* Are there other reasons that GETting a version might
          fail? Can servers delete old versions? Can servers put
          different access control on different versions?=C2=A0</div>
        <div>* While a loose fail-back mode might be OK for GET, it&#39;s
          harmful for PUT.=C2=A0 What errors should a server use if it can&=
#39;t
          apply the PUT or PATCH to the exact version or parents
          specified?</div>
        <div><br>
        </div>
        <div>5. Discoverability.=C2=A0</div>
        <div>* How does the client discover if a server supports the
          Version and the Parent header?=C2=A0=C2=A0</div>
        <div>* Are servers going to be able to support some parts of
          this and not others?=C2=A0 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?=C2=A0</div>
        <div>* Would a server be compliant if it allowed small updates
          (&quot;Add this sentence at this location on this version&quot;) =
but did
          not respond to GET requests of prior versions with the prior
          version?</div>
        <div>* Would a server be compliant if it allowed PATCH to update
          the versioned resource but not PUT? The other way around?=C2=A0=
=C2=A0</div>
        <div>* Is a versioning-unaware client able to send PUT requests
          and modify the resource?=C2=A0 does that modify the whole
          resources?=C2=A0 Is there a need for the client to tell the serve=
r
          &quot;Don&#39;t worry I know what I&#39;m doing&quot; and that it=
 understands
          Version and Parent concepts?=C2=A0</div>
        <div><br>
        </div>
        <div>I have more concrete questions I haven&#39;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.=C2=A0=C2=A0</div>
        <div><br>
        </div>
        <div>It&#39;s like developing a server or service from scratch -
          your first version that works in a demo in friendly hands is
          great, and there&#39;s still 80% of the work remaining to handle
          edge cases and combinations of features and actual attacks.
          It&#39;s pretty daunting but the Braid work is a really good
          start.</div>
        <div>
          <div><br>
          </div>
          <div>Lisa</div>
        </div>
      </div>
      <br>
      <div class=3D"gmail_quote">
        <div dir=3D"ltr" class=3D"gmail_attr">On Tue, Oct 15, 2024 at
          1:55=E2=80=AFPM Josh Cohen &lt;<a href=3D"mailto:joshco@gmail.com=
" target=3D"_blank">joshco@gmail.com</a>&gt;
          wrote:<br>
        </div>
        <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex">
          <div dir=3D"ltr">After Vancouver, I had a conversation with Lisa
            Dussealt, author of RFC4918,=C2=A0HTTP Extensions for Web
            Distributed Authoring and Versioning (WebDAV), and CalDAV,
            and asked if she might make herself available at least as an
            advisor.
            <div>I&#39;ll leave it to Lisa to say Hi.</div>
            <div>(Lisa will probably need to join the wg list)</div>
          </div>
          <br>
          <div class=3D"gmail_quote">
            <div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jul 27, 2024 at
              4:35=E2=80=AFAM Julian Reschke &lt;<a href=3D"mailto:julian.r=
eschke@gmx.de" target=3D"_blank">julian.reschke@gmx.de</a>&gt;
              wrote:<br>
            </div>
            <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On
              16.07.2024 03:26, Michael Toomim wrote:<br>
              &gt; Hi everyone in HTTP!<br>
              &gt;<br>
              &gt; Last fall we solicited feedback on the Braid State
              Synchronization<br>
              &gt; proposal [draft<br>
              &gt; &lt;<a href=3D"https://datatracker.ietf.org/doc/html/dra=
ft-toomim-httpbis-braid-http-04" rel=3D"noreferrer" target=3D"_blank">https=
://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http-04</a>&gt;=
,
              slides &lt;<a href=3D"https://datatracker.ietf.org/meeting/11=
8/materials/slides-118-httpbis-braid-http-add-synchronization-to-http-00" r=
el=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.org/meeting/11=
8/materials/slides-118-httpbis-braid-http-add-synchronization-to-http-00</a=
>&gt;],
              which I&#39;d summarize as:<br>
              &gt;<br>
              &gt;=C2=A0 =C2=A0 =C2=A0&quot;We&#39;re enthusiastic about th=
e general work, but
              the proposal is too<br>
              &gt;=C2=A0 =C2=A0 =C2=A0high-level. Break the spec up into mu=
ltiple
              independent specs, and<br>
              &gt;=C2=A0 =C2=A0 =C2=A0work bottom-up. Focus on concrete
              &#39;bits-on-the-wire&#39;.&quot;<br>
              &gt;<br>
              &gt; So I&#39;m breaking the spec up, and have drafted up the
              first chunk for<br>
              &gt; you. I would very much like your review on:<br>
              &gt;<br>
              &gt;=C2=A0 =C2=A0 =C2=A0*Versioning of HTTP Resources*<br>
              &gt;=C2=A0 =C2=A0 =C2=A0draft-toomim-httpbis-versions<br>
              &gt;=C2=A0 =C2=A0 =C2=A0<a href=3D"https://datatracker.ietf.o=
rg/doc/html/draft-toomim-httpbis-versions-00" rel=3D"noreferrer" target=3D"=
_blank">https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-versions=
-00</a><br>
              &gt; ...<br>
              <br>
              I believe it would be good to work out the differences to
              RFC 3253<br>
              (<a href=3D"https://greenbytes.de/tech/webdav/rfc3253.html" r=
el=3D"noreferrer" target=3D"_blank">https://greenbytes.de/tech/webdav/rfc32=
53.html</a>);
              even if only in a<br>
              short paragraph.<br>
              <br>
              Best regards, Julian<br>
              <br>
            </blockquote>
          </div>
          <br clear=3D"all">
          <div><br>
          </div>
          <span class=3D"gmail_signature_prefix">-- </span><br>
          <div dir=3D"ltr" class=3D"gmail_signature">
            <div dir=3D"ltr">
              <div>
                <div dir=3D"ltr">
                  <div dir=3D"ltr">
                    <div dir=3D"ltr">
                      <div dir=3D"ltr">
                        <div dir=3D"ltr">
                          <div dir=3D"ltr">
                            <div dir=3D"ltr">
                              <div dir=3D"ltr">
                                <div dir=3D"ltr"><span></span>
                                  <div>
                                    <p><font face=3D"monospace, monospace">=
---</font><span style=3D"font-family:monospace,monospace"><br>
                                      </span><b><span style=3D"font-family:=
Calibri,sans-serif">Josh Co</span></b><span style=3D"font-family:Calibri,sa=
ns-serif">hen=C2=A0</span></p>
                                    <p style=3D"background-image:initial;ba=
ckground-position:initial;background-repeat:initial"><span style=3D"font-fa=
mily:Arial,sans-serif"></span></p>
                                  </div>
                                </div>
                              </div>
                            </div>
                          </div>
                        </div>
                      </div>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </blockquote>
      </div>
    </blockquote>
  </div>

</blockquote></div><br clear=3D"all"><div><br></div><span class=3D"gmail_si=
gnature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><d=
iv dir=3D"ltr"><div><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div=
 dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D=
"ltr"><div dir=3D"ltr"><span></span><div><p><font face=3D"monospace, monosp=
ace">---</font><span style=3D"font-family:monospace,monospace"><br></span><=
b><span style=3D"font-family:Calibri,sans-serif">Josh Co</span></b><span st=
yle=3D"font-family:Calibri,sans-serif">hen=C2=A0</span></p><p style=3D"back=
ground-image:initial;background-position:initial;background-repeat:initial"=
><span style=3D"font-family:Arial,sans-serif"></span></p><p></p></div></div=
></div></div></div></div></div></div></div></div></div></div></div>

--0000000000008663460624c92962--