jiebi/CodeConvo huggingface dataset:
Code change:
Duplicate Track Alias: The endpoint attempted to use a Track Alias that was already in use. <ins> Too Many Subscribes: The session was closed because the subscriber used a Subscribe ID equal or larger than the current Maximum Subscribe ID. </ins> GOAWAY Timeout: The session was closed because the client took too long to close the session in response to a GOAWAY (message-goaway) message.  See session migration (session-migration).

Related discussion:
text: A few months ago, I would have said we should go with the HTTP/2 style design of just having a limit on number of streams, but given the recent issues, I'd be inclined towards the QUIC style of specifying the max number. But I think that works better if we also have a subscription ID that's monotonically increasing for subscriptions, ie: Announces also likely need some limits, but I'm less clear on how that might work.
I propose a monotonically increasing in the message. You can't reuse Subscribe IDs. We add a message containing the maximum allowed ID and possibly a SETUP parameter to set the initial value. The corresponding messages use that ID instead of echoing the full track name. This removes ambiguity and overhead. We would still have Track ID for compressing the full track name (maybe renamed?). You could have multiple SUBSCRIBE reference the same Track ID but contain different Subscribe IDs. For example: Same for .
Adding a Subscribe ID used as you're describing SGTM and as you said remove any ambiguity about what subscription is being referenced. Unless we are absolutely never going to have multiple subscriptions, I believe we'll need a Subscribe ID.
This is related to
may be better to name it as transaction_id . since it is id tied to a given subscribe transaction ..
As a follow-up to adding a Subscribe ID, we'll add a SETUP field or param to indicate the initial value and a MAXSUBSCRIBEID frame to increase the limit, similar to QUIC flow control.
The consensus at the session today was to go with a QUIC style approach, so I wrote There was interest in a similar approach for announces, but announces don't yet have an ID, so that will have to wait.
Will assign to Mike English
This seems like a really complicated way to limit the subscribes. I understand how it mirror streams but that had pretty different constrains. Why don't we just have an subscribe error of "too many subscriptions"? Discussed open issues in the 7 August 2024 virtual, not recorded here. Remaining issue (just do a SUBSCRIBE_ERROR?) went to the list and chairs declared rough consensus, although at least 2 participants would prefer not to have this.
Code change:
Abstract The mechanism for running the WebSocket Protocol over a single stream <del> of an HTTP/2 connection is equally applicable to HTTP/3, but needs to be separately registered.  This document describes the mechanism for HTTP/3. </del> <ins> of an HTTP/2 connection is equally applicable to HTTP/3, but the HTTP version-specific details need to be specified.  This document describes how the mechanism is adapted for HTTP/3. </ins> Note to Readers

Related discussion:
text: Tweak the phrasing of the abstract to make it a bit more clear that the document is adapting the mechanism not defining a mechanism.
There's nothing wrong with them per-se but in the space of 2 paragraphs the doc says This document describes the mechanism for HTTP/3. Appendix A.3 of [HTTP3] describes the required updates for HTTP/2 settings to be used with HTTP/3. So is it a new mechanism, a setting update, a new setting, or what?
Good point! That is a bit awkward. Check out and let me know what you think?
Code change:
This document describes the use cases that have been discussed in the IETF community under the banner of "Media Over QUIC", and recommends <del> use cases on live media contribution, syndication, and streaming as the basis for requirements discussions that should guide the design of protocols to satisfy these use cases. </del> <ins> use cases on live media ingest, syndication, and streaming as the basis for requirements discussions that should guide the design of protocols to satisfy these use cases. </ins> 1.1.

Related discussion:
text: It's likely that only NAME and I will care about this, but I think it matters :grin:
Code change:
Statement a Transparent Statement is produced. Receipts are based on Signed Inclusion Proofs as described in COSE <del> Signed Merkle Tree Proofs (I-D.draft-steele-cose-merkle-tree-proofs). </del> <ins> Signed Merkle Tree Proofs (I-D.draft-ietf-cose-merkle-tree-proofs). </ins> The registration time is defined as the timestamp at which the Transparency Service has added this Signed Statement to its Append-

Related discussion:
text: Revisit ### Validation {#validation} section fully: After refactor Originally posted by NAME in URL
Please propose a new PR.
Code change:
The sent Router Advertisement message MUST also include a Route Information option (RFC4191) for each routable prefix advertised on <del> the stub network.  If the SNAC router is also a normal router (e.g. a home WiFi router), it SHOULD include all other routes that it is advertising in the RA, if there is space. </del> <ins> the stub network. </ins> After having sent the initial Router Advertisement, the SNAC router moves the interface into the STATE-ADVERTISING-SUITABLE state (state-

Related discussion:
text: Because CE routers are infrastructure
This addresses
NAME could we change "customer edge router" to "home gateway" (per our official terminology )? I see now also the RFC reference in the PR is incorrect (rfc 704).
the text in this section can be confusing when dealing with 2 usable prefixes (see section 5.2.1.4 - ULA/non-ULA). In MCR's words: if there are two suitable prefixes, one of them will still need to be deprecated. According to Ted, this issue is orthogonal to reachability. Perhaps, we should explain that this state-machine does not talk about reachability for both the suitable prefixes. At least give forward reference to section 5.4 for complete behavior. This will explain that we can only transition to STATE-BEGIN-ADVERTIZING and in no case we transition to STATE_USABLE
I think the issue here is not about usable prefixes, but about routes. Suppose we have a DHCPv6 prefix, and the DHCPv6 server doesn't renew it. In this case, we probably want to stop advertising it at some point and start advertising a prefix based on our site ULA. We should talk about the timing of this switch-over. Separately, whenever we have advertised a prefix on either link, we need to continue advertising a route to that prefix until the prefix is no longer valid on the link on which we advertised it. So if we switch from DHCPv6 prefix to ULA prefix on infrastructure, we need to be advertising routes to both for as long as both are valid. Similarly, if we advertise a prefix on the stub network and later withdraw it because a higher-priority prefix is advertised there, we need to continue advertising a route to that prefix on the infrastructure link until the valid lifetime of the prefix we advertised has expired. I think all routers that have seen the prefix need to do this. Then there's the case where a stub router advertising a prefix reboots. We can't assume that it's written anything to stable storage other than what prefix it's allocated for the stub network and for the infrastructure network. So when the router comes up after booting, it needs to advertise routes to these prefixes on the appropriate link until the maximum possible valid lifetime for the prefix has expired.
Code change:
The sent Router Advertisement message MUST also include a Route Information option (RFC4191) for each routable prefix advertised on <del> the stub network.  If the SNAC router is also a normal router (e.g. a home WiFi router), it SHOULD include all other routes that it is advertising in the RA, if there is space. </del> <ins> the stub network. </ins> After having sent the initial Router Advertisement, the SNAC router moves the interface into the STATE-ADVERTISING-SUITABLE state (state-

Related discussion:
text: And finally there's the DHCPv6 case, where we got a prefix to advertise on the stub network via DHCPv6. In this case, I think we need to write the DHCPv6 prefix to stable storage when we get it, and remove it from stable storage when it expires. We should limit the lifetime we advertise on the stub network to a constant value (e.g. 30 minutes), and then if we find the DHCPv6 prefix recorded in stable storage, we advertise a route to it on infrastructure for 30 minutes after reboot. After 30 minutes, we can erase it from stable storage so that this doesn't repeat. I think if the BR doesn't have stable storage, then if it reboots with a DHCPv6 prefix still valid on the stub network, we just have to hope that it gets the same prefix when it comes back. If it does not, then that prefix may become unreachable while hosts on the stub network are still using it. We could have the stub network snoop source addresses to discover prefixes still in use on the stub network to ameliorate this situation, but that's somewhat problematic because it's a lot of work.
I think the conclusion of the WG is that we need to have an explicit state machine for the stub router on-link prefix because it's actually quite different from the state machine for infrastructure, where for example we do not need to do DHCP. Important to mention that we need to explicitly deprecate the DHCP prefix if we switch to ULA and vice versa.
One of the things that this state machine needs to talk about is what happens if the SNAC router sees an RIO on /its/ stub network that does not have the SNAC router flag bit set. In this case, the SNAC router should treat this network as an infrastructure network and should not perform SNAC router routing functions or service discovery functions between the two networks. Essentially in this case the SNAC router functionality should be completely disabled while such an RA is seen on the stub network.
Code change:
algorithm would perform in the presence of transient events such as sudden onset of congestion, a routing change, or a mobility event. Routing changes, link disconnections, intermittent link connectivity, <del> and mobility are discussed in more detail in Section 17 of Tools. </del> <ins> and mobility are discussed in more detail in Section 16 of Tools. </ins> As an example from an Experimental RFC, response to transient events is discussed in Section 9.2 of RFC4782 (Quick-Start).

Related discussion:
text: The second paragraph of 5 reads: I probably agree that some of the scenarios are statistically small, and may remain that way in the future, but others aren't all that statistically small even today and/or could become less small in the foreseeable future. AQM is now reasonably widely deployed, anyone with Starlink internet sees varying delay, most Wi-Fi links exhibit periodic transient link disconnections during channel scanning, etc. I'd suggest something like: The first paragraph of 5.7 Transient Events reads: The [Tools] link takes one to URL, where Section 17 provides us with: Was this intended to be a joke? .... Actually, I think you meant Section 16.
This is indeed long-since expired: title: Tools for the Evaluation of Simulation and Testbed Scenarios target: "URL" seriesinfo: Work in Progress date: 2007-7 author: - ins: S. Floyd - ins: E. Kohler.
WFM
Code change:
While algorithm agility allows the migration to stronger algorithms it does not prevent the use of weaker algorithms.  Integrity fields <del> do not provide any mitigiations for downgrade or substitution attacks </del> <ins> do not provide any mitigations for downgrade or substitution attacks </ins> (see Section 1 of RFC6211) of the hashing algorithm.  To protect against such attacks, endpoints could restrict their set of supported algorithms to stronger ones and protect the fields value by using TLS

Related discussion:
text: Murray suggested some things that we could change about the way new IANA registry was being handled. This change: tries to make it clearer that this document uses a new registry that we will need IANA to create moves rote IANA instructions to the IANA considerations better highlights interesting hash algorithm considerations for implmenters clarifies the registration procedure and expands on the expectations for the Designated Expert(s)
Code change:
The OAuth 2.1 Authorization Framework <del> oauth-2.1 </del> <ins> draft-parecki-oauth-v2-1 </ins> Abstract

Related discussion:
text: Edited intro to reflect what this document is about changed some OAuth 2.0 references to OAuth 2.1 when referring to this document changed document name to follow ID standard name (repo and filename should be updated as well?) pulled out acknowledgments as this doc will be different
Code change:
having refresh tokens at all to avoid the risk of giving prolonged access to the attacker. <ins> 6.3.2. In this scenario, a Service Worker [1] is responsible for obtaining tokens from the authorization server and passing them to the resource API. Service workers are inherently safe from XSS, because the browser APIs allowing to register one take an origin-constrained URL.  They can thus be used as a safe store for tokens. In this architecture, a service worker intercepts calls from the frontend to the resource server.  As such, it completely isolates calls to the authorization server from XSS attack surface, as all tokens and PKCE secrets are safely kept there without any access from other JavaScript contexts.  The service worker is then solely responsible for adding authentication headers to calls to the resource server. 6.3.2.1. The service worker MUST initiate the OAuth 2.0 Authorization Code grant with PKCE itself. The service worker MUST intercept the authorization code when the _authorization server_ redirects to the application.  This makes this architecture completely safe from token or session leaks in case of XSS. The service worker implementation MUST then initiate the token request itself. The service worker MUST not transmit tokens, authorization codes or PKCE secrets (e.g. code verifier) to the frontend application. The service worker MUST block /token or /authorize calls initiating from the frontend application in order to avoid any front-end side-channel for getting credentials: the only way of starting the authorization flow is through the service worker. This protects against re-authorization from XSS-injected code. </ins> 7. Browser-based applications that are public clients and use the

Related discussion:
text: This looks great. I'm going to merge this and make a few minor tweaks to it.
Code change:
header field (HTTP) to indicate connection-specific header fields; in this protocol, connection-specific metadata is conveyed by other means.  An endpoint MUST NOT generate an HTTP/2 message containing <del> connection-specific header fields; any message containing connection- specific header fields MUST be treated as malformed. </del> <ins> connection-specific header fields.  This includes the header field and those listed as having connection-specific semantics in HTTP (that is, , , , and ).  Any message containing connection-specific header fields MUST be treated as malformed. </ins> The only exception to this is the TE header field, which MAY be present in an HTTP/2 request; when it is, it MUST NOT contain any

Related discussion:
text: The original issue here was concerned with Transfer-Encoding, but this was not a normative statement, it was a note. With a forward reference, this is better. The section on connection-specific headers probably could have been more specific. Now that the -semantics draft has a specific list of things (plus whatever lists), we can lean on that more directly.
HTTP/2 prohibits Transfer-Encoding, but doesn't actually prohibit other values: HTTP/3 broadened this language to cover all transfer codings: Should H2bis follow suit?
Can you take this to the list Mike? It seems like the only sensible answer, but I'd like to double-check.
In my mind, I was relying on Section 8.2.2: However, that probably isn't linked well enough to the . Unfortunately, there isn't a term we can just lift out; perhaps something like this:
On review with full context, the text that Mike cites is fine. It's an informational note. Mark's note here about the linkage to -semantics is good though. I will float this on the list to see if I messed up (again).
Code change:
RFC8441 defines a mechanism for running the WebSocket Protocol RFC6455 over a single stream of an HTTP/2 connection.  It defines an <del> Extended CONNECT method which specifies a new ":protocol" pseudo </del> <ins> Extended CONNECT method which specifies a new ":protocol" pseudo- </ins> header field and new semantics for the ":path" and ":authority" <del> pseudo header fields.  It also defines a new HTTP/2 setting sent by a </del> <ins> pseudo-header fields.  It also defines a new HTTP/2 setting sent by a </ins> server to allow the client to use Extended CONNECT. The HTTP/3 stream closure is also analogous to the TCP connection

Related discussion:
text: pseudo-header is hyphenated per [HTTP3], and expand out a "headers" straggler.
Thanks, this is great!
Code change:
3. <del> TBD: explain use cases of the three-party-model. </del> <ins> TBD: explain use cases of the Issuer-Holder-Verifier Model. </ins> TBD: conventional crypt, hardware security, hsm, mobile secure area, compliance with FIPS

Related discussion:
text: Replace "Three-Party-Model" with "Issuer-Holder-Verifier Model"
There are lots of things that could be described as a three-party model (including classic OAuth where this work is aspiring for adoption). The use of "Three-Party-Model" in this document strikes me as somewhat presumptuous and potentially misleading or confusing. Could we instead use "Issuer-Holder-Verifier Model"?
I agree, since there must be always a trusted third party in the model, like a trust anchor or its intermediate
I typically refer to this model as "decentralized identity" or "verifiable credentials applications/solutions/ecosystems", I would be fine with "digital credentials applications/solutions/ecosystems".
I'm suggesting only to replace the 5 or 6 usages of "Three-Party-Model" with "Issuer-Holder-Verifier Model".
That would work for me and I understand that Three-Party-Model is confusing since other architectures also involve 3 parties.
I'm ok with using "Issuer-Holder-Verifier Model".
It seems that this issue is ready for a PR.
is that PR
thanks, lgtm
Code change:
request message.  The component value is canonicalized by taking the value of the method as a string.  Note that the method name is case- sensitive as per HTTP.  While conventionally standardized method <del> names are uppercase US-ASCII (STD80), no transformation to the input method value's case is performed. </del> <ins> names are uppercase ASCII, no transformation to the input method value's case is performed. </ins> For example, the following request message:

Related discussion:
text: Encodes query parameter names to match values, to avoid non-ascii or otherwise problematic values.
In 2.2.8: What if the query parameter contains non-ASCII characters? I think this needs to say that the name parameter needs to contain the raw (percent-encoded) name.
Good catch, I believe you're correct.
Code change:
mechanisms that would give flows with different round- trip times comparable bandwidth during backoff. <ins> Protection Against Bufferbloat The alternate congestion control mechanism should reduce its sending rate if the round trip time (RTT) significantly increases. Exactly how the algorithm reduces its sending rate is algorithm specific. Bufferbloat Bufferbloat refers to the building of long queues in the network.  Many network routers are configured with very large buffers.  If congestion starts happening, classic TCP congestion control algorithms RFC5681 will continue sending at a high rate until the buffer fills up completely and packet losses occur. Every connection going through that bottleneck will experience high latency.  This is particularly bad for highly interactive applications like games, but it also affects routine web browsing and video playing. This problem became apparent in the last decade and was not discussed in the Congestion Control Principles published in September 2002 RFC2914.  The classic congestion control algorithm RFC5681 and the widely deployed Cubic algorithm RFC9438 do not address it, but newly designed congestion control algorithms have the opportunity to improve the state of the art. </ins> Fairness within the Alternate Congestion Control Algorithm. In environments with multiple competing flows all using the same

Related discussion:
text: Addresses issue
NAME You wrote "Some comments on Bufferbloat" and I am pretty sure these are interesting comments, but I cannot see any. I am afraid something went wrong and they were not published.
A good improvement. I wonder if framing it like "use the full bandwidth and nothing more" would be a more holistic approach that covers a few different requirements at once, but I have no actual text to propose.
This looks like reasonable first text pin this topic, thanks Christian (my previous comments appear already to be resolved - so happy to approve this)
Code change:
metadata document (RFC8414) and fetched programmatically at runtime. The token endpoint URL MUST NOT include a fragment component, and MAY <del> include an "application/x-www-form-urlencoded" formatted query component (WHATWG.URL). </del> <ins> include a query string component query-string-serialization. </ins> The client MUST use the HTTP "POST" method when making requests to the token endpoint.

Related discussion:
text: This moves the description of serializations to the appendix part of
Though i wonder whether the Authorization Response () section should account for the extension - URL with text like "unless specified otherwise by an extension".
yeah I can add that, sounds reasonable
added a lot of text around how clients form authorization requests, the language does not however account for the optional POST binding at the authorization endpoint. Sections and do not account for the optional POST binding which uses the request body to carry the encoded parameters. In OIDC there's the request parameters.
This has been resolved in , there is now a section that describes the serialization methods in an appendix, which is referenced elsewhere in the spec: URL
LGTM
Code change:
that have requested Txn-Tokens as part of the transaction processing. <del> 5.2.1.1. </del> <ins> 5.2.2.1. </ins> It is useful to be able to track the set of workloads that have requested a Txn-Token.  The "req_wl" claim allows for tracking this

Related discussion:
text: Added a section to clarify the intent of the claim and how it is different from scope values addressing issue .
From Yaron's : need a lot more discussion of this claim, also it may be OPTIONAL too. Also, why not call it "scope" if that's what it is?
From NAME In an external to internal flow, the scopes tend to be broad. The TraT can be set to a more specific to narrow the use of the TraT. We could call it scope, but it could be confused with the OAuth scope One could set the value to the actual API that was called to be very specific We should add a sub-section to describe the above in the draft.