jiebi/CodeConvo huggingface dataset:
Code change:
8.2. <del> The following entry is added to the "HTTP/3 Settings" registry </del> <ins> The following entries are added to the "HTTP/3 Settings" registry </ins> established by HTTP3: The "SETTINGS_ENABLE_WEBTRANSPORT" parameter indicates that the

Related discussion:
text: Capsule design team output. Minimal changes to HTTP/3, which was already using capsules and is now joined by . Same content as draft PR, thank you to those who have already reviewed!
Does this actually with a no-op, or are we supposed to discuss that at 115? Otherwise LGTM.
It as a no-op with the exception of one bullet point that we did want to address, that got split out into , which we'll discuss at 115 separately from this PR.
Should the protocol share framing semantics with the HTTP/2 draft so that it is easy/easier to take datagrams or streams and put them on the CONNECT stream? Should it be possible to use that mechanism, or should it instead be forbidden? As much as possible, it would be desirable to have the forwarding logic be fairly uniform across different protocol versions. Right now, we have two almost completely different protocols.
I was discussing this with NAME and NAME What happens when an H3 WT server receives "version independent" WT framing on its CONNECT stream. Since WT over H3 requires H3 datagrams, then there is no need to fold datagrams into the CONNECT stream. There shouldn't be a need to fold streams either, unless you want to defeat QUIC stream limits :) Allowing this would also increase work to implement an H3 only WT client/server: you have to re-implement QUIC over an HTTP byte-stream just in case the peer decides to send you "version independent" WT. Right now I think they are totally different and never the twain shall meet. Proxies can convert between the two versions. If we did that, should we have different upgrade tokens?
Is this issue still relevant now that we have the outcome of HTTP Datagram Design Team?
NAME gentle ping
Actually never mind, this is blocked on the capsule design team - the output of that design team will decide on whether the h2 capsules are allowed in h3 or not
The H3 draft by its nature allows for the parallel processing of multiple WT sessions and also the intermixing of normal H3 request with WT. Server endpoints may wish to negotiate or disable this behavior. Clients can simply choose not to do either kind of pooling if they don't want to. There's already a PR open () with a design idea.
Code change:
8.2. <del> The following entry is added to the "HTTP/3 Settings" registry </del> <ins> The following entries are added to the "HTTP/3 Settings" registry </ins> established by HTTP3: The "SETTINGS_ENABLE_WEBTRANSPORT" parameter indicates that the

Related discussion:
text: I'd like to propose a different model than the one in : The server sends the maximum WebTransport Session ID, or since 0 is a valid value, it's really the minimum invalid WebTransport Session ID. To indicate WT is not supported, server sends 0. To allow for only 1 session ever, server sends 4, and never updates it. To allow for only 1 session at a time, server sends 4, and updates it by 4 as each session closes/resets. To allow for N parallel sessions, server sends 4 * N. and updates as sessions close/reset. This mirrors H3 PUSH, and requires at least one more frame (MAXWTSESSIONID). Perhaps it would also require CANCELWT_SESSION? A client need only declare that it supports webtransport, and even that could be optional. The server will know if it receives a CONNECT with :protocol=webtransport.
I wanted to have a negotiation mechanism in , but my conclusion after talking with NAME about it was that we should not do negotiation, and servers should just reject extra streams with a 400 (or maybe even a RESET_STREAM) if they ever see more sessions than they expect; meaning it's on the clients to know if they can pool or not.
Though we may want a more specific 4XX error code so the client knows it should retry in a non-pooled connection
That's certainly a lot simpler than session credits ;) The cost of at least an RTT for a client that tries to pool against a server that can't handle it seems somewhat high. I guess it depends what the common client pooling strategies are and how many servers don't support pooling.
NAME since it's looking like the JavaScript API will provide a way to disable pooling, I expect that the scenario of pooling-attempted-but-rejected will be quite rare, so a round trip cost should be acceptable
I'm also considering use cases for WT which are not tied to the JS API.
NAME that's interesting - and those use-cases won't have a similar mechanism to disable pooling? I suspect they'll need a way to get the WT server's hostname somehow, and having config properties attached to that (such as disable_pooling) could be useful?
NAME : the opposite -- the clients may attempt pooling to servers that might or might not support it. You can't tell from a hostname if it supports pooling.
Code change:
8.2. <del> The following entry is added to the "HTTP/3 Settings" registry </del> <ins> The following entries are added to the "HTTP/3 Settings" registry </ins> established by HTTP3: The "SETTINGS_ENABLE_WEBTRANSPORT" parameter indicates that the

Related discussion:
text: NAME how did the client get the hostname in the first place? I'm suggesting to carry pooling_support next to that.
Actually, let's go back to JS for a second. The people who write JS at Facebook are very unlikely to know if the edge server terminating their connection supports pooling, or that configuration could change over time.
(I appreciate the irony of me saying this as a Googler, but) should the JS people talk to the edge people? I agree that this shouldn't fail, but it being inefficient seems reasonable - these teams should talk if they're trying to reach good performance.
I think my main problem with is that most people who want to disallow pooling want to exclude not only other WebTransport sessions, but also general HTTP traffic. was written with that assumption in mind.
Ok, MAXWTSESSION_ID doesn't handle that case, so it may be an over-engineered solution to the wrong problem.
As I said in the meeting, I don't think that we should have any signals for dedicated connections from either client or server. Yutaka made the point that the client can decide to make a connection dedicated after seeing the server settings. It doesn't need to signal its intent (and signaling would have negative privacy consequences potentially). I agree with this observation. A server needs to support HTTP if we're using HTTP. So pooling with h3 is already a settled matter. If the server doesn't want to answer requests, it can use 406 or 421 or other HTTP mechanisms to tell the client to go away. More generally, the server can just not provide links to that server, such that it might have to respond to GET/OPTIONS/POST/etc. The question then becomes managing resource limits on the server. Having a way to limit the number of WebTransport sessions is a good thing and I believe that will be sufficient for this. Thus, I'm a supporter of option 3: MAXWTSESSIONS or similar.
I agree that we should have limits of how many WT can be active at the same time on a connection. It should also define what happens if the limit is exceeded. Should a client open another QUIC connection to the same server or should it fail? Probably it should be former, but that should also have limits defined (6 parallel QUIC connection, may be too much?
Code change:
8.2. <del> The following entry is added to the "HTTP/3 Settings" registry </del> <ins> The following entries are added to the "HTTP/3 Settings" registry </ins> established by HTTP3: The "SETTINGS_ENABLE_WEBTRANSPORT" parameter indicates that the

Related discussion:
text: HTTP/1.1 have the 6 parallel connection limit).
Chair: discussed at IETF 113, consensus in room to change the WT SETTING to carry the number of concurrent WT sessions allowed on this h3 connection
Note that all of the below works when you swap "server" and "client". I wanted to focus on a poor Javascript client implementation, but it's equally possible to run into these cases with a poor server implementation. Let's say that you have a Http3Transport session that shares a connection with HTTP/3 or another Http3Transport session. The client has limited buffer space and hypothetically advertises MAXDATA of 1MB for the connection. If the server pushes 1MB of unprocessed data over a Http3Transport session, then it will prevent the server from sending data over the connection, including HTTP/3 responses and other Http3Transport sessions. This can occur if the application does not accept all remote-created streams or does not fully read every stream. This will be VERY easy for a developer to mess up. It can also occur if the application can not process data faster than it is received. In my case, the server creates unidirectional streams and pushes a large amount of media over them. The flow control limit would be hit if the Javascript application: Only accepts bidirectional streams (ex. initialization) Does not accept a unidirectional stream (ex. error or teardown) Does not fully read or abort every stream (ex. parsing error) Is not able to parse the media fast enough (ex. underpowered). This is mostly intended behavior, otherwise these "bugs" would cause unbounded memory usage. However, the blast radius is bigger when sharing a connection. In my use-case, hitting the flow control limit would also block any HTTP/3 RPC calls or unrelated traffic on the connection. This introduces more scenarios for the connection to become deadlocked or generally stalled. HTTP/3 implementations use MAXSTREAMS to limit the number of simultaneous requests. This use-case no longer works when sharing a connection with a Http3Transport session, and HTTP/3 implementations must instead return explicit error status codes when this threshold is reached. The same issues with MAXDATA also apply to MAXSTREAMS. A Javascript application that fails to accept or read/abort every stream will consume flow control resources.
Code change:
8.2. <del> The following entry is added to the "HTTP/3 Settings" registry </del> <ins> The following entries are added to the "HTTP/3 Settings" registry </ins> established by HTTP3: The "SETTINGS_ENABLE_WEBTRANSPORT" parameter indicates that the

Related discussion:
text: This can manifest itself in strange ways, such as HTTP/3 being unable to create control streams, or simply being unable to create new request streams.
Thanks for the salient overview, it makes it easier to understand your concerns. My first comment would be that some of these points apply to QuicTransport too. Its just that their made worse by Http3Transport pooling allowing the mashing together of orthogonal protocols with no application-layer oversight. Just as you might interfere with a page load, a browser could easily interfere with your finely crafted application protocol. I would anticipate that, due to different browsers having different HTTP usage patterns, and different pages being composed differently by time, region, etc, one might find that Http3Transport apps subject to pooling would experience inconsistencies and transient issues. You rightly point out that the connection flow control is a shared resource. But the problems described seem to relate to stream flow control and overlooks the different flow control setting afforded by the Transport Parameters. A possible mitigation is to more tightly constrain the initial flow windows of server-initiated streams so that they can't interfere with requests. However, I still think that the notion of pooling together WebTransports in an uncoordinated fashion is going to manifest undesirable properties. The MAX_STREAMS observation is a good one. I think the competition between request streams and client bidirectional streams is going to be hard to resolve.
Yeah, and enforcing any per sort of per-session flow control might get difficult because you can only identify the protocol and session after you receive the first few bytes of each stream. For example, assume a brand new connection (for simplicity only) and you receive a STREAM frame with id=100, offset=16, and size=1000. You don't know yet which protocol or session created this stream or the 25 preceding it.
Code change:
8.2. <del> The following entry is added to the "HTTP/3 Settings" registry </del> <ins> The following entries are added to the "HTTP/3 Settings" registry </ins> established by HTTP3: The "SETTINGS_ENABLE_WEBTRANSPORT" parameter indicates that the

Related discussion:
text: And hopefully you eventually get those first few bytes for each stream...
Chair notes from IETF 112 meeting: this needs more discussion (on the issue or mailing list)
Chair: discussed at 113, consensus in room to: use a setting to limit number of WT sessions (see ) figure out MAXSTREAMS, a way to limit the number of streams within a session abandon MAXDATA as too hard, do not limit amount of data sent within a session (anyone can open a new issue to revisit this discussion if they have a concrete proposal on how to do this) let QUIC take care of MAXSTREAMDATA
Capsule DT is doing all of the above bullet points except the second one, for which I opened . Apologies for the extremely delayed response here, but hearing no objections we are declaring consensus and merging the PRs. David David Schinazi wrote:
Code change:
contain all m= sections that were previously bundled, as long as they are still alive, as well as any new m= sections. <ins> The "LS" groups are generated in the same way as with initial offers. </ins> 5.2.3. The createOffer method takes as a parameter an RTCOfferOptions

Related discussion:
text: I cleaned up the language.
lgtm
Cullen wants LS groups because that is what legacy gear understands. Magnus wants to use MSID, which carries this.
Discussed in DC: will test out the LS group concept, Jonathan will send text to the list and we will discuss. Concerns are that there is a potential for mismatch between what is signaled in LS groups and what is signaled in MSID. We also need to work out what to do in the absence of LS groups.
bug 32 is prob dup of this
pinged Lennox
Given the discussion on CNAME, no one in the room at IETF90 objected to the idea that LS group was MTI.
Plan here is update draft to say that when creating the SDP, everything in PC has same CNAME, and the things in the same MediaStream get put in a LS (lipsync) group. This will mean legacy stuff that support LS will do the right thing, and legacy stuff that does not, will simply try and sync everything.
Cullen to ping Harald to get his LG regarding the comment above (ie. regarding its interaction with MSID)
Just to add some clarity here .... this is what I think we decided. All the RTP in a given PeerConection will use the same CNAME. For each stream, If a stream has more than one track, then the JSEP needs to create a lip sync group (see URL ) to put all the tracks in a given stream into the same lip sync group.
Yes. If no lipsync group from the remote side, everything is synchronized. If only some tracks in LS group, the rest are unsynchronized. (Basically, if you indicate you understand LS, we take what you give us, all synced)
MT, would you be willing to write some text here?
Who has the token here?
Just realized there could be a problem. Consider A, who does not want to sync its audio/video, and B, who wants its video to be synced. A offers a=group:LS with no mids. B has to reply with a subset of the proposed mids, by 5888 rules. Therefore B's a/v won't be synced. I don't see a good reason to require this, but 5888 is pretty clear.
Code change:
contain all m= sections that were previously bundled, as long as they are still alive, as well as any new m= sections. <ins> The "LS" groups are generated in the same way as with initial offers. </ins> 5.2.3. The createOffer method takes as a parameter an RTCOfferOptions

Related discussion:
text: The identification-tags contained in this "a=group" line MUST be the same as those received in the offer, or a subset of them (zero identification-tags is a valid subset). When the identification-tags in the answer are a subset, the "group" value to be used in the session MUST be the one present in the answer.
There's an issue with LS when using bidirectional media sections. If media stream X (from A to B) uses media sections 1 and 2, and media stream Y (from B to A) uses media sections 2 and 3, what should be the lipsync groups? Are lipsync groups unidirectional or bidirectional?
see comment above. 5888 says bidi, but that is crazy talk.
Indeed. Crazy. What is our plan of attack here then? Can we ask MMUSIC to fix this? Either by un-screwing-up a=group (which seems unlikely), by making a new grouping semantic, or by telling us that there is a better option.
JSEP reserves the right to contradict existing standards where necessary. Generally, it seems like the need for symmetry in a=group is semantic-dependent, and so fixing it later in 5888 seems possible.
So you are suggesting that we define a=group:LS as declarative: it applies to the media that is sent by the peer that includes the grouping. I can live with that, though I suspect it will cause considerable heartburn. It certainly complicates the grouping model considerably.
yes, essentially. I don't see any way to reconcile LS with reality otherwise.
Changing the semantics of existing mechanisms by declaring that they are changed without actually changing them is a dangerous process. A simpler alternative is to drop media section reuse when LS groups are present: If a particular media section is a member of an LS group, or if a MediaStream requires its tracks to be part of an LS group, don't use it for a track in the opposite direction. The legacy case of one audio section, one video section that is used in both directions will then require that we somehow turn off LS group generation.
Code change:
set of acceptable behavior in a group.  These policies must be consistent between deployments for them to interoperate: <ins> A policy on which ciphersuites are acceptable. A policy on any mandatory or forbidden MLS extensions. </ins> A policy on when to send proposals and commits in plaintext instead of encrypted.

Related discussion:
text: WGLC comments on Operation Requirements section. Added several overlooked requirements
Discussed on 12/8 interim, and folks seemed fine with this. I.e., it's ready to merge.
Code change:
Interface name (string): <ins> Note that an IPv6 address specified with a scope (e.g. "2001:db8:4920:e29d:a420:7461:7073:0a%en0") is equivalent to "WithIPv6Address" with an unscoped address and "WithInterface " together. </ins> An Endpoint cannot have multiple identifiers of a same type set. That is, an endpoint cannot have two IP addresses specified.  Two separate IP addresses are represented as two Endpoint Objects.  If a

Related discussion:
text: Sections 4.1 and 4.1.3 introduce to configure an Endpoint Object. The address supplied in examples appears to be an address literal. However, Section 1.1 does not define any types explicitly associated with an internet address -- or could work, but I don't think that's the intent for these APIs, either. Section 3.2.2 does not extend this. It's unclear whether this literal is intended to support IPv6 scoped addresses as described in [RFC4007]. While this RFC describes a textual representation (possibly not in line with the goals of the API), [RFC6874] describes how to represent zone indexes in an address literal. If zone indexes are not intended to be supported, this could be clarified by, when "IPv4 and IPv6 address" is mentioned in section 4.1, also citing [RFC791] and [RFC4007] with the respective address family. If zone indexes are intended to be supported, ambiguity exists around the use of and on a Local Endpoint, where the supplied address has a zone index that does not match the supplied interface. This could be clarified by: Defining type names that represent IPv4 and IPv6 addresses in section 1.1. Specifying the properties of an address literal supported by that type (referencing [RFC791] for IPv4 and both [RFC4007] and [RFC6874] for IPv6). Clarifying in section 4.1 that "IPv4 or IPv6 address" are of the respective type described in section 1.1 when used in or . Clarifying the behavior of zone index and interface choices on a Local Endpoint in a new section 4.1.4. This may tie in to to some extent in that this is unlikely to be discoverable until is called. [RFC791]: URL [RFC4007]: URL [RFC6874]: URL
(note this is in §6.1/6.1.3 post-)
Mention that the %en0 addition to the IPv6 address is equivalent to explicitly setting WithInterface. Also mention that these are implied to be system types for addresses
Looks sane
Code change:
tunnel. Along with a successful response, the proxy can send capsules to <del> assign addresses and routes to the client (capsules).  The client can also assign addresses and routes to the proxy for network-to-network routing. </del> <ins> assign addresses and advertise routes to the client (capsules).  The client can also assign addresses and advertise routes to the proxy for network-to-network routing. </ins> 4.1.

Related discussion:
text: This PR is one potential way to It simplifies route exchanges by going with NAME 's suggestion of sending the entire routing table each time something changes. It could be somewhat inefficient in some cases, but it becomes easier to reason about than what's currently in the draft when overlapping prefixes are involved.
This is interesting, but I'd prefer to wait to do this until after we post a -00 version. NAME is that OK with you?
I'd prefer we figure this out before -00, because this would be a pretty significant non-compatible change and I'd like to implement -00
NAME you nearly convinced me in the call that we rather want to announce ranges separately but I forgot why. Can you outline your reasoning again?
NAME my argument was that we shouldn't have two different ways to set routes, one that gives a table and one that gives a single route. If we go to only have a table, then it's fine.
I know saw the discussion in and support this approach. Also if we agree on this approach, I also think we should merge it before we submit -00
NAME I think we're ready to merge this PR
As discussed in , turning a sequence of ROUTEADVERTISEMENT and ROUTEWITHDRAWAL capsules into a functional routing table isn't as simple as initially expected. This is because two separate capsules can describe prefixes that are distinct but overlap. We should simplify the design or better explain the caveats.
I think this looks good enough to include in the -00.