Re: WRAP_UP Capsule

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<mailto: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<mailto:dschinazi.ietf@gmail.com>>
Sent: Tuesday, October 22, 2024 2:16 PM
To: Ben Schwartz <bemasc@meta.com<mailto:bemasc@meta.com>>
Cc: HTTP Working Group <ietf-http-wg@w3.org<mailto: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<mailto: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<mailto:dschinazi.ietf@gmail.com>>
Sent: Wednesday, October 16, 2024 5:41 PM
To: HTTP Working Group <ietf-http-wg@w3.org<mailto: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