[{"author": "Martin Thomson", "text": "

zulip.ietf.org also works as a chat interface. Zulip is strange, but it seems perfectly functional.

", "time": "2022-07-26T14:04:36Z"}, {"author": "Alan Frindell", "text": "

preface with mic: if you want me to relay

", "time": "2022-07-26T14:08:54Z"}, {"author": "Martin Thomson", "text": "

(test) do messages to arbitrary topics get presented to the chat for those not using zulip?

", "time": "2022-07-26T14:09:23Z"}, {"author": "Alex Chernyakhovsky", "text": "

\"zulip is strange\" is an interesting way to put it :)

", "time": "2022-07-26T14:09:35Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

My understanding is that only the jabber topic is bridged to jabber.

", "time": "2022-07-26T14:09:59Z"}, {"author": "Martin Thomson", "text": "

@Alex Chernyakhovsky I take it that you agree with me.

", "time": "2022-07-26T14:09:59Z"}, {"author": "Murray Kucherawy", "text": "

W3C charters have expiration dates? Interesting idea.

", "time": "2022-07-26T14:10:56Z"}, {"author": "Murray Kucherawy", "text": "

(ominous music)

", "time": "2022-07-26T14:11:00Z"}, {"author": "Alex Chernyakhovsky", "text": "

I am used to zulip's predecessor (barnowl TUI client for MIT Zephyr)

", "time": "2022-07-26T14:11:03Z"}, {"author": "Nick Doty", "text": "

@mt, yes I see that message in the meetecho chat

", "time": "2022-07-26T14:13:01Z"}, {"author": "Lorenzo Miniero", "text": "

@Nick Doty notice that any message not sent to the jabber topic will not be mirrored to the Jabber room: won't matter in the future, but may matter now

", "time": "2022-07-26T14:13:48Z"}, {"author": "Lorenzo Miniero", "text": "

In the Meetecho client we display incoming messages on any topic

", "time": "2022-07-26T14:14:13Z"}, {"author": "Martin Thomson", "text": "

consistency - yay

", "time": "2022-07-26T14:14:31Z"}, {"author": "Martin Thomson", "text": "

that seems totally sensible from a design perspective

", "time": "2022-07-26T14:14:41Z"}, {"author": "David Schinazi", "text": "

https://github.com/w3c/webtransport/issues/

", "time": "2022-07-26T14:18:25Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

When I was working on an XMPP client for the aforementioned barnowl, I used MUC threads to carry information akin to zulip topics, but I also exposed it and don't expect that most clients do that.

", "time": "2022-07-26T14:20:46Z"}, {"author": "Martin Thomson", "text": "

Whether or not L4S is available might affect performance in many ways. Most of those are strictly positive, so I would not want to end up in a situation where you could disable L4S or ECN when it is active and functioning correctly.

", "time": "2022-07-26T14:21:49Z"}, {"author": "David Schinazi", "text": "

https://github.com/w3c/webtransport/issues/365

", "time": "2022-07-26T14:22:41Z"}, {"author": "Martin Thomson", "text": "

I sense a pile-on

", "time": "2022-07-26T14:29:12Z"}, {"author": "Alan Frindell", "text": "

Considering the HTTP priority model, is setting a policy for how to prioritize multiple sequential streams at the same priority urgency a way to accomplish the warp use case? eg: Newest first, oldest first.

", "time": "2022-07-26T14:29:26Z"}, {"author": "Martin Thomson", "text": "

I would get up to say that naming congestion controllers is a mistake, but I can also comment on the issue

", "time": "2022-07-26T14:29:43Z"}, {"author": "Martin Thomson", "text": "

@Alan Frindell we have discussed that as an option, but it is not clear that it would work.

", "time": "2022-07-26T14:31:24Z"}, {"author": "Luke Curley", "text": "

for Warp, 8 strict levels, or created last, would both

", "time": "2022-07-26T14:31:52Z"}, {"author": "Luke Curley", "text": "

but it limits the design space for stuff like RUSH

", "time": "2022-07-26T14:32:09Z"}, {"author": "Luke Curley", "text": "

would both work*

", "time": "2022-07-26T14:33:29Z"}, {"author": "Luke Curley", "text": "

would both work*

", "time": "2022-07-26T14:33:47Z"}, {"author": "Martin Thomson", "text": "

Oh, I know, we can create a tree of dependencies, with branches on the tree being assigned a weighting...

", "time": "2022-07-26T14:34:40Z"}, {"author": "David Schinazi", "text": "

MT....

", "time": "2022-07-26T14:34:48Z"}, {"author": "Tommy Jensen", "text": "

flashbacks :|

", "time": "2022-07-26T14:35:14Z"}, {"author": "Alan Frindell", "text": "

Simpler is better for priorities, but the ordering of more than 8 things is something that's a bit challenging with the current priority scheme

", "time": "2022-07-26T14:36:09Z"}, {"author": "David Schinazi", "text": "

I'll say it again: you never go full TAPS

", "time": "2022-07-26T14:36:34Z"}, {"author": "Nick Doty", "text": "

could we have an API design where the developer has to check a box saying \"I really know what I'm doing and if I screw it up it's all my fault\" before calling the more complicated method?

", "time": "2022-07-26T14:37:31Z"}, {"author": "Martin Thomson", "text": "

@Nick Doty WebTransport.subtle.blah ?

", "time": "2022-07-26T14:38:04Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

ISolemlySwearIAmUpToNoGood()

", "time": "2022-07-26T14:38:28Z"}, {"author": "Martin Thomson", "text": "

It looks like the current proposed design more or less fits into what you might consider as a reasonable paradigm. You have a list of options you can choose from, but you can also just express a target.

", "time": "2022-07-26T14:38:56Z"}, {"author": "Martin Thomson", "text": "

The idea that @Eric Kinnear raised about expressing anti-goals fits within that (don't spend power is also aim: \"low-power\").

", "time": "2022-07-26T14:39:40Z"}, {"author": "Nick Doty", "text": "

{complicated:yes, awareOfComplicatedRisks: yes}

", "time": "2022-07-26T14:39:55Z"}, {"author": "Jonathan Lennox", "text": "

I look forward to people copy&pasting that from StackOverflow

", "time": "2022-07-26T14:40:49Z"}, {"author": "Luke Curley", "text": "

the datagram stats API is for folks who want to build their own CC in Javascript

", "time": "2022-07-26T14:41:02Z"}, {"author": "Luke Curley", "text": "

it would be nice if the CC selection API could avoid that

", "time": "2022-07-26T14:41:37Z"}, {"author": "Martin Thomson", "text": "

@Nick Doty what we need is a proof of competence.

", "time": "2022-07-26T14:41:57Z"}, {"author": "Hang Shi", "text": "

Is JS fast enough to build CC, reacting to each packet?

", "time": "2022-07-26T14:42:07Z"}, {"author": "Martin Thomson", "text": "

@Hang Shi probably not in theory or in practice, but you can maybe work something out (see also Audio Worklets)

", "time": "2022-07-26T14:42:50Z"}, {"author": "Nick Doty", "text": "

I think we just want the person who copies from Stack Overflow (which I absolutely agree is the likely use case) to see something scary, and then ask a follow-up, like, wait, why does this explicitly say it's scary/a bad idea?

", "time": "2022-07-26T14:43:31Z"}, {"author": "Alex Chernyakhovsky", "text": "

is the problem JS interpretation time, or JS's execution context being shared within a thread?

", "time": "2022-07-26T14:43:50Z"}, {"author": "Martin Thomson", "text": "

@Alex Chernyakhovsky The problem is that it is hard to operate something that is sufficiently responsive when you are sharing the thread with a bunch of other stuff.

", "time": "2022-07-26T14:44:44Z"}, {"author": "Alex Chernyakhovsky", "text": "

what if the CC was running in its own thread/context separate from the context where the DOM exists?

", "time": "2022-07-26T14:46:04Z"}, {"author": "Luke Curley", "text": "

if the browser timestamps packet arrival and send times, Javascript should be fine for computing CC

", "time": "2022-07-26T14:46:10Z"}, {"author": "Martin Thomson", "text": "

@Nick Doty I don't think that works in practice. WebCrypto tried that and it didn't work.

", "time": "2022-07-26T14:46:21Z"}, {"author": "Martin Thomson", "text": "

@Alex Chernyakhovsky That is what a worklet is.

", "time": "2022-07-26T14:46:37Z"}, {"author": "Alex Chernyakhovsky", "text": "

ah, thanks for clarifying

", "time": "2022-07-26T14:46:49Z"}, {"author": "Martin Thomson", "text": "

@Luke Curley It depends on whether you are wanting to drive things like pacing from JS. If it is just processing feedback and calculating a target window, then you might do something reasonable, but that is not the totality of what CC means.

", "time": "2022-07-26T14:47:26Z"}, {"author": "Luke Curley", "text": "

pacing would be tough, yeah

", "time": "2022-07-26T14:48:34Z"}, {"author": "Luke Curley", "text": "

although that could be configured in the WebTransport datagram API

", "time": "2022-07-26T14:49:52Z"}, {"author": "Luke Curley", "text": "

I'm really not a fan of sending UDP packets in Javascript, but that's the entire point of the datagram API

", "time": "2022-07-26T14:50:37Z"}, {"author": "Alan Frindell", "text": "

is the concern that you have a proxy that speaks H3 WT with H3 Datagrams fronting a backend that supports H3 WT without them?

", "time": "2022-07-26T14:52:34Z"}, {"author": "Alan Frindell", "text": "

+1 Marten

", "time": "2022-07-26T14:53:59Z"}, {"author": "Hang Shi", "text": "", "time": "2022-07-26T14:54:17Z"}, {"author": "Martin Thomson", "text": "

Alan Frindell said:

\n
\n

is the concern that you have a proxy that speaks H3 WT with H3 Datagrams fronting a backend that supports H3 WT without them?

\n
\n

My concern is that optionality complicates negotiation, that's all.

", "time": "2022-07-26T14:57:48Z"}, {"author": "Martin Thomson", "text": "

If you don't need them, then you only have to have the capacity to throw them out.

", "time": "2022-07-26T14:58:15Z"}, {"author": "Martin Thomson", "text": "

Also, you probably won't ever exercise that capability.

", "time": "2022-07-26T15:02:06Z"}, {"author": "Hang Shi", "text": "

This flow control is very to easy to bypass.

", "time": "2022-07-26T15:06:50Z"}, {"author": "Martin Thomson", "text": "

Hang Shi said:

\n
\n

This flow control is very to easy to bypass.

\n
\n

Say more? if we implement a limit, why would that limit be easy to bypass? Are you just saying that there are other ways to exhaust resources?

", "time": "2022-07-26T15:10:30Z"}, {"author": "Hang Shi", "text": "

The limit is per session. What stops a bad website to open multiple sessions?

", "time": "2022-07-26T15:14:38Z"}, {"author": "Alex Chernyakhovsky", "text": "

The connection level limits still apply I assume

", "time": "2022-07-26T15:18:57Z"}, {"author": "Alan Frindell", "text": "

are there intermediaries that will forward out of order stream data for H3? I'm not sure that would really work.

", "time": "2022-07-26T15:18:57Z"}, {"author": "Alex Chernyakhovsky", "text": "

out-of-order stream data seems doable but ... very special-case to me. I'd expect no one to do it

", "time": "2022-07-26T15:20:49Z"}, {"author": "Martin Thomson", "text": "

Alan Frindell said:

\n
\n

are there intermediaries that will forward out of order stream data for H3? I'm not sure that would really work.

\n
\n

why would it fail?

", "time": "2022-07-26T15:20:59Z"}, {"author": "Erik Nygren", "text": "

Do we also need to provide guidance/warnings on buffer bloat risks? (Especially with cases like a mix of H2 and H3 having too big of a buffer in some place could cause problems that endpoints wil need to worry about)

", "time": "2022-07-26T15:24:00Z"}, {"author": "Martin Thomson", "text": "

@Erik Nygren That is exactly the sort of rabbit-hole I'm trying to avoid going down.

", "time": "2022-07-26T15:25:17Z"}, {"author": "Alan Frindell", "text": "

I guess I mean i's not possible until after you have seen some amount of the beginning of the stream. Once you see the WT session ID and know the upstream session and stream ID, you could probably forward later out of order stream data?

", "time": "2022-07-26T15:29:19Z"}, {"author": "Eric Kinnear", "text": "

Can I redirect you to the place you asked me to CONNECT to?

", "time": "2022-07-26T15:34:24Z"}, {"author": "Erik Nygren", "text": "

Did we land on always using GET or do we sometimes use GET and sometimes CONNECT methods? Will things get weird if we follow redirects and it switches schemes? (eg, switching between a h2 stack and an h1 stack and an h3 stack?)

", "time": "2022-07-26T15:37:43Z"}, {"author": "Martin Thomson", "text": "

@Erik Nygren Good point. I believe that we are only using CONNECT, with the annotations.

", "time": "2022-07-26T15:39:16Z"}, {"author": "Alex Chernyakhovsky", "text": "

Does webtrans differ from masque here? I thought for masque we went with extended-connect everywhere

", "time": "2022-07-26T15:39:21Z"}, {"author": "Eric Kinnear", "text": "

Extended-connect everywhere, across masque + webtransport, specifically to be consistent across the two

", "time": "2022-07-26T15:40:10Z"}, {"author": "Erik Nygren", "text": "

(yay, extended-connect everywhere across masque + webtransport is good.)

", "time": "2022-07-26T15:40:44Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

websocket clients may ignore redirects, which meant they just didn't work the one time I tried to use them.

", "time": "2022-07-26T15:41:12Z"}, {"author": "Martin Thomson", "text": "

@Erik Nygren note also that redirects will need to be limited in type, because those redirects that downgrade to GET won't work here, at all.

", "time": "2022-07-26T15:42:46Z"}, {"author": "Martin Thomson", "text": "

+1 to @Alan Frindell on punting this to a new specification, where we will have more knowledge about what we need.

", "time": "2022-07-26T15:46:41Z"}, {"author": "Martin Thomson", "text": "

Making a reset reliable is probably useful...

", "time": "2022-07-26T15:50:02Z"}, {"author": "Mike Bishop", "text": "

Here's the H3 text:

\n
\n

If a client-initiated stream terminates without enough of the HTTP message to provide a complete response, the server SHOULD abort its response stream with the error code H3_REQUEST_INCOMPLETE.

\n
", "time": "2022-07-26T15:55:28Z"}, {"author": "Alan Frindell", "text": "

Hmm, what if there's not enough of a message?

", "time": "2022-07-26T15:56:34Z"}, {"author": "Alan Frindell", "text": "

Receipt of a fin from the server is not an ack that it received the client fin

", "time": "2022-07-26T15:59:10Z"}, {"author": "Martin Thomson", "text": "

Right. Indeed, I would say that sending a FIN without a capsule is also totally valid.

", "time": "2022-07-26T16:01:20Z"}, {"author": "Martin Thomson", "text": "

So there is an optional capsule, a FIN, and an optional STOP_SENDING. Send each at your own discretion.

", "time": "2022-07-26T16:02:03Z"}, {"author": "Martin Thomson", "text": "

Obviously, not sending the FIN will mean that the session remains active, so you need a rule saying that other capsules sent after the \"end\" capsule are not permitted (and cause the session to be torn down, with a STOP_SENDING).

", "time": "2022-07-26T16:03:01Z"}]