[{"author": "Will Law", "text": "

Tip o' the hat to Lucas's hat.

", "time": "2025-03-20T08:03:19Z"}, {"author": "Lucas Pardue", "text": "
", "time": "2025-03-20T08:03:27Z"}, {"author": "Francesca Palombini", "text": "

Thank you for that David

", "time": "2025-03-20T08:08:51Z"}, {"author": "Victor Vasiliev", "text": "

it's 4am here, and I am jelaous of Jan-Ivar

", "time": "2025-03-20T08:10:16Z"}, {"author": "Alan Frindell", "text": "

alan's chat: that is not Alan approved

", "time": "2025-03-20T08:13:00Z"}, {"author": "Martin Thomson", "text": "

this is a question for webappsec and fetch people

", "time": "2025-03-20T08:17:47Z"}, {"author": "Martin Thomson", "text": "

that's a lot of text for one slide

", "time": "2025-03-20T08:18:05Z"}, {"author": "Martin Thomson", "text": "

Apple might be on one side of this, but they didn't send anyone who is strongly opinionated

", "time": "2025-03-20T08:19:05Z"}, {"author": "Martin Thomson", "text": "

this header question is coupled to the CORS question

", "time": "2025-03-20T08:19:42Z"}, {"author": "Martin Thomson", "text": "

if we allow headers, we should allow cookies, right?

", "time": "2025-03-20T08:21:13Z"}, {"author": "David Schinazi", "text": "

:grimacing:

", "time": "2025-03-20T08:21:36Z"}, {"author": "Victor Vasiliev", "text": "

Those are a bit orthogonal

", "time": "2025-03-20T08:22:51Z"}, {"author": "Victor Vasiliev", "text": "

you can have headers on uncredentialed requests

", "time": "2025-03-20T08:23:08Z"}, {"author": "Martin Thomson", "text": "

I know that you can put headers on uncredentialed, but cookies

", "time": "2025-03-20T08:24:34Z"}, {"author": "Victor Vasiliev", "text": "

I actually don't remember if you can put cookies on an uncredentialed request or not

", "time": "2025-03-20T08:25:36Z"}, {"author": "David Schinazi", "text": "

meetecho: can you point a camera at the speaker plz?

", "time": "2025-03-20T08:26:34Z"}, {"author": "Martin Thomson", "text": "

requests with cookies are, by definition, credentials

", "time": "2025-03-20T08:26:48Z"}, {"author": "Martin Thomson", "text": "

*credentialied

", "time": "2025-03-20T08:26:54Z"}, {"author": "David Schinazi", "text": "

meetecho: thank you

", "time": "2025-03-20T08:27:00Z"}, {"author": "Alan Frindell", "text": "

I'd like establishing a webtransport session to have the same affordances a non-browser has when opening a QUIC connection, because the protocols of the future will run on both. Having a parallel to something like Transport Params makes sense.

", "time": "2025-03-20T08:27:06Z"}, {"author": "Lorenzo Miniero", "text": "

Thanks for the heads up!

", "time": "2025-03-20T08:27:09Z"}, {"author": "Lucas Pardue", "text": "

the point I was going to make, as an individual was. Outside of W3C there is no restriction on headers in the WebTransport protocol. Are we risking making a split ecosystem if we don't enforce commonality below the API

", "time": "2025-03-20T08:27:13Z"}, {"author": "Lucas Pardue", "text": "

subprotocol negotion - https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/172

", "time": "2025-03-20T08:29:15Z"}, {"author": "Victor Vasiliev", "text": "

I believe WebSockets already has a similar \"split ecosystem\" issue?

", "time": "2025-03-20T08:29:22Z"}, {"author": "Christian Huitema", "text": "

I really like \"just 1 connection == no flow control\"

", "time": "2025-03-20T08:29:48Z"}, {"author": "Lucas Pardue", "text": "

flow control - https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/150

", "time": "2025-03-20T08:30:05Z"}, {"author": "Lucas Pardue", "text": "

maybe Victor - but it also defines explicit headers that are allowed in the handshake like https://datatracker.ietf.org/doc/html/rfc6455#section-4.3

", "time": "2025-03-20T08:33:17Z"}, {"author": "Christian Huitema", "text": "

+1 Victor

", "time": "2025-03-20T08:34:57Z"}, {"author": "Alan Frindell", "text": "

Chrome just this morning fixed a flow control bug I reported 10 years ago: https://issues.chromium.org/issues/41161335

", "time": "2025-03-20T08:38:19Z"}, {"author": "Lucas Pardue", "text": "

the TL;DR upload bug was \"server knows it should send a window update but got into a mode it didn't schedule the packet that would contain a WINDOW_UPDATE\"

", "time": "2025-03-20T08:44:19Z"}, {"author": "Benjamin Schwartz", "text": "

Is this all about WT_MAX_DATA, or is there also concern about WT_MAX_STREAMS?

", "time": "2025-03-20T08:44:20Z"}, {"author": "Alan Frindell", "text": "

Ben - do you mean the heartburn about how hard it is to implement?

", "time": "2025-03-20T08:45:27Z"}, {"author": "Benjamin Schwartz", "text": "

Naively, WT_MAX_STREAMS seems easy, and WT_MAX_DATA seems harder. I wonder if there's consensus to make stream count limits mandatory.

", "time": "2025-03-20T08:46:04Z"}, {"author": "Alan Frindell", "text": "

MAX_DATA is particularly ugly because of RST_STREAM and final offset.

", "time": "2025-03-20T08:46:47Z"}, {"author": "Francesca Palombini", "text": "

(side process note @David: and all decisions will be confirmed in the mailing list, right? :) )

", "time": "2025-03-20T08:46:50Z"}, {"author": "Kazuho Oku", "text": "

Can we just send WT_MAX_DATA=2**62 - 1 and rely on QUIC-level flow control?

", "time": "2025-03-20T08:47:18Z"}, {"author": "Martin Thomson", "text": "

if that is what you might prefer, sure

", "time": "2025-03-20T08:47:41Z"}, {"author": "Martin Thomson", "text": "

I was tempted to do that for stream-level flow control in our QUIC stack

", "time": "2025-03-20T08:47:57Z"}, {"author": "Kazuho Oku", "text": "

I think my question is more about implementation - will senders check both WT- and QUIC-level flow control before making decisions?

", "time": "2025-03-20T08:48:24Z"}, {"author": "Kazuho Oku", "text": "

Or are they going to just check WT-level and decide to send?

", "time": "2025-03-20T08:48:37Z"}, {"author": "Victor Vasiliev", "text": "

I think the idea is that both levels are enforced

", "time": "2025-03-20T08:48:51Z"}, {"author": "Martin Thomson", "text": "

right, that's the key question, but the only interoperable choice if we think there has to be a choice is that one

", "time": "2025-03-20T08:48:52Z"}, {"author": "Martin Thomson", "text": "

that is, you have to respect limits

", "time": "2025-03-20T08:49:04Z"}, {"author": "Kazuho Oku", "text": "

right, so because there are two limits, senders that do not want to build a buffer have to check both limits before making the decision to send (or not)

", "time": "2025-03-20T08:49:47Z"}, {"author": "Victor Vasiliev", "text": "

Sending MAX_DATA is easy, it's respecting that limit that is challenging

", "time": "2025-03-20T08:55:04Z"}, {"author": "Victor Vasiliev", "text": "

(at least in our case)

", "time": "2025-03-20T08:55:19Z"}, {"author": "Kazuho Oku", "text": "

Agreed. But senders have to do that no matter what, I think?

", "time": "2025-03-20T08:55:32Z"}, {"author": "Alan Frindell", "text": "

It's not all about what limit you send, it's about what your peer sends.

", "time": "2025-03-20T08:56:05Z"}, {"author": "Alan Frindell", "text": "

Should we talk about how using QUIC's stream model over TCP via webtrans/h2 is harmful to QUIC adoption?

", "time": "2025-03-20T08:58:35Z"}, {"author": "Victor Vasiliev", "text": "

Is it?

", "time": "2025-03-20T08:58:58Z"}, {"author": "Alan Frindell", "text": "

See also yesterday's discussion in QUIC about QMux

", "time": "2025-03-20T08:59:55Z"}, {"author": "Lucas Pardue", "text": "

bugs happen at that line

", "time": "2025-03-20T09:00:24Z"}, {"author": "Lucas Pardue", "text": "

https://www.youtube.com/watch?v=bR86qiPOH7s

\n
", "time": "2025-03-20T09:00:56Z"}, {"author": "Victor Vasiliev", "text": "

I slept through it, but my assessment of QMux is \"please use webtrans-http2\"

", "time": "2025-03-20T09:01:12Z"}, {"author": "Martin Thomson", "text": "

turtles all the way down!

", "time": "2025-03-20T09:01:29Z"}, {"author": "Alan Frindell", "text": "

Oh I should have saved the QUIC on Streams joke for this presentation

", "time": "2025-03-20T09:04:45Z"}, {"author": "Martin Thomson", "text": "

The number of ways that you can spell Reverse HTTP is apparently infinite.

", "time": "2025-03-20T09:05:27Z"}, {"author": "Martin Thomson", "text": "

Why not MASQUE?

", "time": "2025-03-20T09:05:33Z"}, {"author": "David Schinazi", "text": "

It definitely has enough turtles-all-the-way-down to put it in MASQUE land

", "time": "2025-03-20T09:06:48Z"}, {"author": "Lucas Pardue", "text": "

i'll be back

", "time": "2025-03-20T09:09:46Z"}, {"author": "Lucas Pardue", "text": "

i have headphoes on!

", "time": "2025-03-20T09:09:54Z"}, {"author": "Eric Kinnear", "text": "

Woah :)

", "time": "2025-03-20T09:10:09Z"}, {"author": "Benjamin Schwartz", "text": "

https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/issues/1

", "time": "2025-03-20T09:15:35Z"}, {"author": "Alan Frindell", "text": "

HTTP on QUIC backwards might break datagrams with \"quarter stream ID\" ?

", "time": "2025-03-20T09:18:26Z"}, {"author": "Victor Vasiliev", "text": "

Isn't that what Node.JS is all about?

", "time": "2025-03-20T09:19:19Z"}, {"author": "Martin Thomson", "text": "

mTLS works

", "time": "2025-03-20T09:20:32Z"}, {"author": "Martin Thomson", "text": "

server proves that it has a cert for the name that the public service will have; client authenticates with a privately-issued certificate

", "time": "2025-03-20T09:21:08Z"}, {"author": "Victor Vasiliev", "text": "

I imagine if you just do the trivial reverse-HTTP, you can have the server to issue a request to a well-known URL for auth

", "time": "2025-03-20T09:22:43Z"}, {"author": "Martin Thomson", "text": "

we can't stop someone from building this in a browser, so maybe the right answer is to build it and THEN we can standardize something, once it is proven to work

", "time": "2025-03-20T09:23:00Z"}, {"author": "Martin Thomson", "text": "

that might work too Victor, though it's a bit kludgy

", "time": "2025-03-20T09:23:32Z"}, {"author": "Victor Vasiliev", "text": "

If we just ran HTTP over MoQT, we could just have the private origin ANNOUNCE itself!

", "time": "2025-03-20T09:23:44Z"}, {"author": "Martin Thomson", "text": "

this is 100% out of scope for this group

", "time": "2025-03-20T09:24:09Z"}, {"author": "Lucas Pardue", "text": "

i there was a BoF, for instance, I wold liekly spend more time engaging stakeholders I know of

", "time": "2025-03-20T09:24:23Z"}, {"author": "Mike Bishop", "text": "

I think I'm hearing a proposal for a \"ptth\" working group.

", "time": "2025-03-20T09:24:45Z"}, {"author": "Martin Thomson", "text": "

can we call it the raspberry WG?

", "time": "2025-03-20T09:25:24Z"}, {"author": "Christian Huitema", "text": "

The bad idea fairy is shopping around...

", "time": "2025-03-20T09:25:28Z"}]