jiebi/CodeConvo huggingface dataset:
Code change:
multiple access token structure containing one access token. If the AS has split the access token response, the response MUST <del> include the "split" flag set to "true". </del> <ins> include the "split" flag in the "flags" array. </ins> Each access token MAY be bound to different keys with different proofing mechanisms.

Related discussion:
text: URL match the flags array in the token request. While this is technically a breaking change, I think we should consider this editorial as this should have been changed when we made the original change to use a flags array in the request in .
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: 8c793bb446d82f053536358106485568fc457842 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
You know, I had that thought, and I checked the request section and it doesn't have quotes. I'm going to add the quotes to both parts. This ended up with some other language changing, not just the examples, so let me know what you think.
Code change:
The PeerConnection constructor allows the application to specify global parameters for the media session, such as the STUN/TURN servers and credentials to use when gathering candidates.  The size <del> of the ICE candidate pool can also be set, if desired; by default the candidate pool size is zero.  [[OPEN ISSUE: this is an inconsistency with the W3C spec https://github.com/rtcweb-wg/jsep/issues/12.]] </del> <ins> of the ICE candidate pool can also be set, if desired.  If the application does not indicate a candidate pool size, the browser may select any default candidate pool size. </ins> In addition, the application can specify its preferred policy regarding use of BUNDLE, the multiplexing mechanism defined in I-

Related discussion:
text: Looks good to me
JSEP says: S 4.1.1. " The PeerConnection constructor allows the application to specify global parameters for the media session, such as the STUN/TURN servers and credentials to use when gathering candidates. The size of the ICE candidate pool can also be set, if desired; by default the candidate pool size is zero." The WebRTC spec says: "At this point the ICE Agent does not know how many ICE components it needs (and hence the number of candidates to gather), but it can make a reasonable assumption such as 2. As the RTCPeerConnection object gets more information, the ICE Agent can adjust the number of components"
Imagine 4 is more realistic.
so default in not defined but their is way for the JS to to set the default for a PC
Discussed in DC: default will be unspecified and left up to browsers, there will need to be a setting for applications to override this default.
w3c bug is URL
Code change:
The entries in iana-frame-table are registered by this document. <del> Additionally, each code of the format "0x1f * N + 0x21" for non- negative integer values of N (that is, 0x21, 0x40, ..., through 0x3FFFFFFFFFFFFFFE) MUST NOT be assigned by IANA. </del> <ins> Each code of the format "0x1f * N + 0x21" for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3FFFFFFFFFFFFFFE) MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. </ins> 11.2.2.

Related discussion:
text: IANA's review wanted to know whether the 148 quadrillion GREASE values should be listed on the registry page as Reserved, and what note should be present if not. They should not, lest it be challenging to actually download the registry page within the lifetime of the human race. This rewords the restriction and clarifies that the restriction should be the note.
NAME Can you add the same text to 22.2 (Transport parameter registry) in the transport doc as well?
NAME said
We believe the note, updated based on IANA feedback during Last Call, is sufficient. Reserving 148 quadrillion values in the registry would cause the registry to be impossible to download in the lifetime of humanity; see . The purpose is described in , to exercise the requirement to ignore unknown frame types (a.k.a. GREASE). Proposal is to make no change; this was already covered during IANA review.
If IANA has agreed, then I am fine with it. BTW, I was not asking to make those zillions of reservations but leaving a note in the registry ;-)
It's a fair question but the WG and the responsible AD are satisfied with our IANA considerations at this stage, closing with no action.
Please see the for full context. This issue is tracking the following IANA question:
Copying my e-mail reply here: unknown values; having an explicit list encourages an explicitly defined reaction. This also applies to and , where the latter has better wording.
NAME replied to IANA . Closing this issue.
Actually, NAME said in response to the e-mail that this guidance should be in the document: Let's re-open to track. I don't think all instances of this question need separate issues, though.
So the related questions were: Should the GREASE values be listed in the registry as Reserved? No, because some rough estimation suggests it would take a few millennia to download the registry page if this were the case. Should there be a note indicating which values cannot be assigned? I'm of two minds, because while I really don't want people embedding the formula into their parsers, I do want people embedding the formula into their generators. says no Reserved listing, yes note.
I think this is proposal ready. Forwarding Mike's response to the list, to there is an archive to link to. Lars >
Code change:
This document describes a captive portal architecture.  Network provisioning protocols such as DHCP or Router Advertisements (RAs), an optional signaling protocol, and an HTTP API are used to provide <del> the solution.  The role of Provisioning Domains (PvDs) is described. </del> <ins> the solution. </ins> 1.

Related discussion:
text: The abstract seems weak. It should mention the problem domain and all of the components. Not sure if it needs to mention PvD at all.
Personally, I think that aside from the PvD mention, which can be removed, the current is mostly OK. Brief is good.
Code change:
5.1.4. <ins> The following shows the example from the previos section show in resolved format. 5.1.5. The following example shows a sensor that returns different data types. 5.1.6. </ins> The following example shows how to query one device that can provide multiple measurements.  The example assumes that a client has fetched information from a device at 2001:db8::2 by performing a GET

Related discussion:
text: Fixes URL
This makes some of the examples very long. I preferred the presentation where all attributes of a Record are on a single line, when feasible. Especially for the "multiple data points" examples. Anyway, Michael's comment was about indentation, which I agree should be (and is now) fixed.
See email from Michael Koster "Formatting of JSON examples in SenML"
Code change:
The optional "connectionProperties" parameter allows passing Transport Properties that control the behavior of the underlying <del> stream or connection to be created, e.g., protocol-specific properties to request specific stream IDs for SCTP or QUIC. </del> <ins> stream or connection to be created, e.g., Protocol-specific Properties to request specific stream IDs for SCTP or QUIC. </ins> Message Properties set on a Connection also apply only to that Connection.

Related discussion:
text: We don't have "Protocol Properties" - two occurrences in -interface should really refer to "protocol-specific Properties", and two occurrences in -impl should really refer to properties.
URL Are Protocol Specific Properties and Protocol Properties same or different? Also note that we are first time defining the Protocol Properties in the interface document ( described along with Connection Properties) and not introduced in the architecture document. I think we should be clear about what we are defining where and describing where. I would suggest use of cross reference rather describing everything again and again, which might create confusion and inconsistency.
Oh, this seems like a mistake (great catch, thanks!) - "Protocol Properties" don't exist, I think we only have "protocol-specific Properties".
I caught this when reading the implementation doc. So it should be fixed there as well.
Code change:
HTTP_WG; HTTP working group; ietf-http-wg@w3.org <del> 8.2. </del> <ins> 7.2. </ins> This document will request IANA to register the following entry in the "HTTP/3 Error Codes" registry:

Related discussion:
text: When reviewing the latest editors copy, the document structure leaps out at a bit odd by jumping from section 3 to section 5. That indicates to me these concepts are linked and also independent of the capsule protocol. So here I propose a minor restructure by moving the H3_DATAGRAM setting stuff to be a subsection of the HTTP/3 datagram format. This makes all the top-layer sections loosely coupled, which is nicer in my opinion.
Code change:
A server MAY send Retry packets in response to Initial and 0-RTT packets.  A server can either discard or buffer 0-RTT packets that it receives.  A server can send multiple Retry packets as it receives <del> Initial or 0-RTT packets. </del> <ins> Initial or 0-RTT packets.  A server MUST NOT send more than one Retry packet in response to a single UDP datagram. </ins> A client MUST accept and process at most one Retry packet for each connection attempt.  After the client has received and processed an

Related discussion:
text: This keeps things simple.
I have no idea how that happened. Forced it.
Are we ok with a server sending both a VN packet and a Retry in response to a single UDP datagram?
NAME Does that happen? IIUC VN is sent only when there's a version mismatch. Retry is sent only when there's no version mismatch.
NAME A client could coalesce two packets of different versions. As I've said on the issue, I still feel uneasy with the fact that a client could coalesce around 70 packets into a single datagram, and I'd prefer more rigid rules to solve this problem.
NAME I'd argue that a client can't do that, because the draft states "Senders MUST NOT coalesce QUIC packets for different connections into a single UDP datagram", OTOH I agree that there's nothing that requires the server to drop following QUIC packets with different versions within a combined datagram. As I stated on URL, I (still) think the approach in this PR would require having minimal state. Would you mind elaborating (possibly on the issue) why you think differently?
Sure, the issue here comes from multi-threaded processing, and reusing packet buffers. I have one thread (or rather, one go-routine) that reads UDP datagrams from the network, splits the coalesced packets and parses the unencrypted part of the header, and then passes the QUIC packets to their respective connections (which are running in a separate go-routine each). In order to reduce allocations, I reuse the buffers I read my packets into. When handling coalesced packets, this means I have to wait until all coalesced parts have been processed before reusing the buffer. Therefore, I can't just parse the first coalesced packet, pass it on for handling in another threat, and then continue parsing. This would create a race condition, since the handling of the packet might be executed before the parsing is finished, and the packet buffer would be returned already. So I have to split the coalesced packets first, and then handle them. This wouldn't be a problem at all if a coalesced packet just had a few parts, as it's supposed to be.
Code change:
A server MAY send Retry packets in response to Initial and 0-RTT packets.  A server can either discard or buffer 0-RTT packets that it receives.  A server can send multiple Retry packets as it receives <del> Initial or 0-RTT packets. </del> <ins> Initial or 0-RTT packets.  A server MUST NOT send more than one Retry packet in response to a single UDP datagram. </ins> A client MUST accept and process at most one Retry packet for each connection attempt.  After the client has received and processed an

Related discussion:
text: But since we're maximizing flexibility for no reason, an attacker might send me datagram consisting of around 70 packets, which I would all have to completely parse.
NAME Thank you for elaborating. I think that we should be dispatching each UDP datagram (instead of each QUIC packet) to the respective connections. That's how load balancers are expected to work, and what you are implementing is essentially a load balancer. The benefit of dispatching at the datagram level is that you'd have less things to do on the receiving thread. I understand your point on flexibility. However, in my view, the flexibility is not only how you coalesce, but the redundancy in all the long header fields. We have deliberately chosen the design because it is clear and easy to analyze (especially in regard to encryption). My preference goes to retaining the clarity by avoiding introducing restrictions.
I think this PR addresses the amplification problem directly, by tying the number of response datagrams to the number of incoming datagrams, so I am in favor of this PR as a spec solution. NAME : quic-go can still choose to drop datagrams with a large (> 3?) coalesced packets, which might help you (slightly). I agree with NAME also that since all coalesced packets are supposed to go to the same connection, the implementation would be better aligned if it were to pass the datagram along to the connection instead of the individual packets... but that's an impl choice, and it's certainly not the only way to do this.
I'm merging this. Please reopen the issue if you think this ought to be discussed further, especially in Tokyo.
Code change:
to support reordering, parallelism, priority, and header compression to acheive similar performance.  Those features were introduced to HTTP in HTTP/2 RFC7540.  Earlier versions of HTTP are capable of <del> conveying the semantic requirements of DOH but would result in very </del> <ins> conveying the semantic requirements of DOH but may result in very </ins> poor performance for many uses cases. 8.

Related discussion:
text: This text is rather subjective without data. Changing it to "may" still brings the point without needing a reference to a study proving the sentence true.
(whoops; just realized I've been blowing my pull requests by chaining them off a single branch... my bad, and this will cause you some pain)
Code change:
WebTransport application error codes. This document. <ins> 8.6. The following entries are added to the "HTTP Capsule Types" registry established by HTTP-DATAGRAM: The "CLOSE_WEBTRANSPORT_SESSION" capsule. 0x2843 CLOSE_WEBTRANSPORT_SESSION permanent This document IETF WebTransport Working Group webtransport@ietf.org [1] None 9.  References 9.1.  URIs [1] mailto:webtransport@ietf.org </ins>

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:
WebTransport application error codes. This document. <ins> 8.6. The following entries are added to the "HTTP Capsule Types" registry established by HTTP-DATAGRAM: The "CLOSE_WEBTRANSPORT_SESSION" capsule. 0x2843 CLOSE_WEBTRANSPORT_SESSION permanent This document IETF WebTransport Working Group webtransport@ietf.org [1] None 9.  References 9.1.  URIs [1] mailto:webtransport@ietf.org </ins>

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:
WebTransport application error codes. This document. <ins> 8.6. The following entries are added to the "HTTP Capsule Types" registry established by HTTP-DATAGRAM: The "CLOSE_WEBTRANSPORT_SESSION" capsule. 0x2843 CLOSE_WEBTRANSPORT_SESSION permanent This document IETF WebTransport Working Group webtransport@ietf.org [1] None 9.  References 9.1.  URIs [1] mailto:webtransport@ietf.org </ins>

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?