Re: WRAP_UP Capsule

If we can articulate when the client would send it, and what the server
does when receiving it, then I'm happy to allow it in that direction.
David

On Tue, Oct 22, 2024 at 1:37 PM Ben Schwartz <bemasc@meta.com> wrote:

> Capsule Types are generic by default.  They live in a unified namespace
> shared by all present and future Capsule Protocol Upgrade Tokens ("Capsule
> Protocols"?).  Unless there's a clear reason to impose a restriction (which
> might be enforced generically by intermediaries), we should not define the
> restriction as part of the Capsule Type.
>
> If WRAP_UP is not a general-purpose Capsule for requesting graceful
> shutdown, then it should probably have a different name, like PROXY_WRAP_UP.
>
> --Ben
> ------------------------------
> *From:* David Schinazi <dschinazi.ietf@gmail.com>
> *Sent:* Tuesday, October 22, 2024 4:18 PM
> *To:* Ben Schwartz <bemasc@meta.com>
> *Cc:* HTTP Working Group <ietf-http-wg@w3.org>
> *Subject:* Re: WRAP_UP Capsule
>
> In that scenario, the requests you describe are not HTTP requests, they're
> custom-application-protocol-running-over-WebTransport requests. My
> expectation would be that the
> custom-application-protocol-running-over-WebTransport would include
> In that scenario, the requests you describe are not HTTP requests, they're
> custom-application-protocol-running-over-WebTransport requests. My
> expectation would be that the
> custom-application-protocol-running-over-WebTransport would include its own
> "please wrap up" signal because each of such protocols might want slightly
> different semantics for their "please wrap up" signal. But if we have a
> couple distinct examples that show that a generic signal is useful, then it
> would make sense to add this capability at the capsule layer. I'll also
> note that JavaScript can't send WRAP_UP capsules on a WebTransport stream,
> so this would be further constrained to non-browser uses of WebTransport.
>
> David
>
> On Tue, Oct 22, 2024 at 12:08 PM Ben Schwartz <bemasc@meta.com> wrote:
>
> Consider an application in which the server is sending requests to the
> client over a WebTransport session.  (Perhaps the client is sharing access
> to a local directory with another user.)  The client could send WRAP_UP as
> part of its graceful shutdown sequence.
>
> --Ben
> ------------------------------
> *From:* David Schinazi <dschinazi.ietf@gmail.com>
> *Sent:* Tuesday, October 22, 2024 2:16 PM
> *To:* Ben Schwartz <bemasc@meta.com>
> *Cc:* HTTP Working Group <ietf-http-wg@w3.org>
> *Subject:* Re: WRAP_UP Capsule
>
> I'm not opposed to a client -> server capsule. Can you elaborate on the
> use case? When does the client send it, and what does the server do upon
> receiving it? David On Tue, Oct 22, 2024 at 8: 25 AM Ben Schwartz <bemasc@
> meta. com>
> I'm not opposed to a client -> server capsule. Can you elaborate on the
> use case? When does the client send it, and what does the server do upon
> receiving it?
> David
>
> On Tue, Oct 22, 2024 at 8:25 AM Ben Schwartz <bemasc@meta.com> wrote:
>
> Section 2.3 says "Clients MUST NOT send the WRAP_UP capsule.".  This
> strikes me as excessively restrictive.  I understand that client->server
> WRAP_UP is not sensible for proxies, but the Capsule Protocol is not
> limited to proxies.
>
> --Ben
> ------------------------------
> *From:* David Schinazi <dschinazi.ietf@gmail.com>
> *Sent:* Wednesday, October 16, 2024 5:41 PM
> *To:* HTTP Working Group <ietf-http-wg@w3.org>
> *Subject:* WRAP_UP Capsule
>
> Hi HTTP enthusiasts, Thanks again for the good discussion at IETF 120
> about the WRAP_UP capsule. Since then, Lucas Pardue has joined me as
> co-author on this document, and rewrote the explanation text to integrate
> the discussion we've had
> Hi HTTP enthusiasts,
>
> Thanks again for the good discussion at IETF 120 about the WRAP_UP
> capsule. Since then, Lucas Pardue has joined me as co-author on this
> document, and rewrote the explanation text to integrate the discussion
> we've had so far. We just submitted a -01. We'd love to hear your thoughts.
>
> https://datatracker.ietf.org/doc/draft-schinazi-httpbis-wrap-up/
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-schinazi-httpbis-wrap-up/__;!!Bt8RZUm9aw!8St_XzKAfZyc7iFKFVB4pdmW2sGwjjldZp-gjG9NGz17iKpSMs4HKUOiAeoqwL1khse9LY43swxsFWW-PrG9$>
>
> https://davidschinazi.github.io/draft-schinazi-httpbis-wrap-up/draft-schinazi-httpbis-wrap-up.html
> <https://urldefense.com/v3/__https://davidschinazi.github.io/draft-schinazi-httpbis-wrap-up/draft-schinazi-httpbis-wrap-up.html__;!!Bt8RZUm9aw!8St_XzKAfZyc7iFKFVB4pdmW2sGwjjldZp-gjG9NGz17iKpSMs4HKUOiAeoqwL1khse9LY43swxsFWZrdgG-$>
>
> Thanks,
> David
>
>