jiebi/CodeConvo huggingface dataset:
Code change:
. <ins> A RST_STREAM frame with a length other than 4 octets MUST be treated as a ConnectionErrorHandler of type . </ins> 6.5. The SETTINGS frame (type=0x4) conveys configuration parameters that

Related discussion:
text: If an http2 implementation receives a frame with an unexpectedly large size, what should it do? As one example, a WINDOW_UPDATE should be 4 bytes. Or should it be at least 4 bytes? The Extending HTTP/2 notes at URL aren't clear about whether an unexpectedly long frame is okay. The closest I can find is: "Implementations MUST ignore unknown or unsupported values in all extensible protocol elements. " But I can't find a definition of an "extensible protocol element". It seems that the spirit of Section 5.5 would be to permit overly long frames.
I forgot to mention: there is FRAMESIZEERROR, but it only says: "If a frame size exceeds any defined limit, or is too small to contain mandatory frame data, the endpoint MUST send a FRAMESIZEERROR error." But only PING and SETTINGS mention it or a limit. What is the intended behavior for PRIORITY, RSTSTREAM and WINDOWUPDATE?
Code change:
8.3. <del> Please update the "Hypertext Transfer Protocol (HTTP) Warn Codes" registry at <https://www.iana.org/assignments/http-warn-codes> with the registration procedure of warn.code.registry and the warn code values summarized in the table of header.warning. </del> <ins> Please add a note to the "Hypertext Transfer Protocol (HTTP) Warn Codes" registry at <https://www.iana.org/assignments/http-warn-codes> to the effect that Warning is obsoleted. </ins> Index <del> 1 110 (warn-code) 111 (warn-code) 112 (warn-code) 113 (warn-code) 199 (warn-code) 2 214 (warn-code) 299 (warn-code) </del> A Age header field age

Related discussion:
text: I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).
Code change:
Signature may be verified multiple times, potentially by different entities. <ins> The term "Unix time" is defined by POSIX.1 section 4.16 [2]. </ins> This document contains non-normative examples of partial and complete HTTP messages.  To improve readability, header fields may be split into multiple lines, using the "obs-fold" syntax.  This syntax is

Related discussion:
text: reuses existing definitions for S-F and Unix time.
Doesn't make this PR redundant? (or regressive, really, because references the exact definitions to use - and from structured headers)
This probably
Code change:
2.3.1. Authorization servers MUST require clients to register their complete <del> redirect URI (including the path component) and reject authorization requests that specify a redirect URI that doesn't exactly match one that was registered; the exception is loopback redirects, where an exact match is required except for the port URI component. </del> <ins> redirect URI (including the path component).  Authorization servers MUST reject authorization requests that specify a redirect URI that doesn't exactly match one that was registered, with an exception for loopback redirects, where an exact match is required except for the port URI component. </ins> The authorization server MAY allow the client to register multiple redirect URIs. <ins> Registration may happen out of band, such as a manual step of configuring the client information at the authorization server, or may happen at runtime, such as in the initial POST in Pushed Authorization Requests RFC9126. </ins> For private-use URI scheme-based redirect URIs, authorization servers SHOULD enforce the requirement in private-use-uri-scheme that clients use schemes that are reverse domain name based.  At a minimum, any

Related discussion:
text: for issue
URL Redirect URIs are not required to be registered if the client is using PAR and is a confidential client.
Discussed in the side meeting: Mike suggested that if 2.1 talks about this exception at all, it include a note that PAR defines an exception to the pre-registration requirement, which cites the PAR section. The text should be a heads-up to implementers - not appear to be defining something new.
Code change:
Use of this algorithm can be indicated at runtime using the "ed25519" value for the "alg" signature parameter. <del> 3.3.6. </del> <ins> 3.3.7. </ins> If the signing algorithm is a JOSE signing algorithm from the JSON Web Signature and Encryption Algorithms Registry established by

Related discussion:
text: Define a signature algorithm named that indicates the use of ECDSA using curve P-384 DSS and SHA-384. The algorithm description is probably just 3.3.4 with "256" replaced with "384", but should validate that assumption with actual crypto folks.
What's the push for this specific curve to be included here? The reason I ask is that we shouldn't necessarily try to define ALL known algorithms in here, when it's extensible.
I agree with not defining every possible algorithm; however we should include those with known use cases, and AWS intends to use -384. Since the spec isn't finalized and the addition is trivial, it seems reasonable to add it here rather than punting it to an extension spec.
Code change:
might then have to buffer data until an assigned transmission opportunity or when the physical path changes (e.g., when the length of a wireless path changes, or the physical layer changes its mode of <del> operation).  Variation also arises when a higher priority diffserv traffic classic prompts the transmission by a lower class.  In these cases, the delay varies as a function of external factors and attempting to infer congestion from an increase in the delay results in reduced throughput.  The jitter from variation over short timescales might not be distinguishable similar from other effects. </del> <ins> operation).  Variation also arises when traffic with a higher priority diffserv class pre-empts transmission of traffic with a lower class.  In these cases, the delay varies as a function of external factors and attempting to infer congestion from an increase in the delay results in reduced throughput.  The jitter from variation over short timescales might not be distinguishable similar from other effects. </ins> A proposed congestion control algorithm SHOULD be evaluated to ensure their operation is robust when there is a significant change in the

Related discussion:
text: Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"
Code change:
configuration, or by consulting if that request contains one of the following header fields: <del> CDN-Loop (RFC8586) </del> Forwarded, X-Forwarded-For (RFC7239) Via (RFC7230, Section 5.7.1)

Related discussion:
text: cc: NAME
Thank you for the fix.
RFC8586 is very clear about other uses of : The current priority draft uses it to detect whether there upstream intermediaries, not loop detection. This should be removed.
Code change:
6.2.2.1. <del> The ROLE parameter (key 0x00) allows the client to specify what roles it expects the parties to have in the MOQT connection.  It has three possible values, which are of type varint: </del> <ins> The ROLE parameter (key 0x00) allows each endpoint to independently specify what funnctionality they support for the session.  It has three possible values, which are of type varint: </ins> <del> The client MUST send a ROLE parameter with one of the three values specified above.  The server MUST close the session if the ROLE parameter is missing, is not one of the three above-specified values, or it is different from what the server expects based on the application. </del> <ins> Both endpoints MUST send a ROLE parameter with one of the three values specified above.  Both endpoints MUST close the session if the ROLE parameter is missing or is not one of the three above-specified values. </ins> 6.2.2.2.

Related discussion:
text: But I still have to have the switch statement because of broken or malicious peers. The MUST in this PR can be improved by explaining what happens when you don't like the value you see, or the peer sends messages inconsistent with its advertised role.
In that case the peer will close the connection since it knows that it is subscribe only implementation and the role in the setup is supreflous
This is the type of things where I don't think we need it but it does not break anything, is not a big deal to implement, and does not hit performance. Given other people feel strongly this is needed, I can easily live with this. If this helps us get to consensus, I'm fine with adding it. I think the rewrite makes things clearer than they were before.
Discussion concluded that supporting this was not that difficult and it's a clear signal of what's supported, to so AI is to fix up the PR to clarify behavior.
Sec 6.1.1.1 specifies client sending or ROLE, and says nothing of server-sent. I guess server-sent ROLE is not needed, but maybe we should fail if it is sent?
I filed about the role parameter. The client doesn't actually know what the server intends to do. The server should be able to reply with its functionality, which might be a subset of what the client can support.
The SETUP message contains a ROLE parameter. In the current draft, the client specifies the value, indicating if the client will send data (0x1), if the server will send data (0x2), or if both endpoints will send data (0x3). A conferencing client supports the ability to send and receive media, and would always send role=0x3 because it supports both functionalities. However, it's unaware of the server functionality, and the server has no way of informing the client if it intends to send media. This matters because a generic client needs to know if it shows a black screen and/or should send a SUBSCRIBE message (ex. for /catalog). I propose that both endpoints send the ROLE parameter: 0x1 = publisher, 0x2 = consumer, 0x3 = both. This gives the server the ability to specify its own functionality.
Wondering if we even need Role in the first place .. can it be changed mid-session ?
Code change:
6.2.2.1. <del> The ROLE parameter (key 0x00) allows the client to specify what roles it expects the parties to have in the MOQT connection.  It has three possible values, which are of type varint: </del> <ins> The ROLE parameter (key 0x00) allows each endpoint to independently specify what funnctionality they support for the session.  It has three possible values, which are of type varint: </ins> <del> The client MUST send a ROLE parameter with one of the three values specified above.  The server MUST close the session if the ROLE parameter is missing, is not one of the three above-specified values, or it is different from what the server expects based on the application. </del> <ins> Both endpoints MUST send a ROLE parameter with one of the three values specified above.  Both endpoints MUST close the session if the ROLE parameter is missing or is not one of the three above-specified values. </ins> 6.2.2.2.

Related discussion:
text: The same would be true with the reverse; a subscriber will not be able to process any SUBSCRIBE messages. I like the ability to specify half-functionality. At the very least the library should support half-functionality (ex. automatically reply with ANNOUNCE_ERROR) but it's even better if it's enforced by the protocol.
LGTM me. Ship it!I wonder if it helps to discuss the role of role parameter during authors call for a short bit NAME
Code change:
also provide an update framework, which verifies the integrity and authenticity of firmware updates before allowing installation. <del> 3.7.2.1. Even with a robust firmware update system, the following problems remain as given below: </del> <ins> The various stake holders of a firmware update system wants to ascertain: </ins> How does the client applying the firmware update on the system know that the received firmware is not faulty or malicious?

Related discussion:
text: Signed-off-by: Henk Birkholz
Looks good.
If there are no objections until the end of Fri, I'll merge for the meeting on Mon.
No objections with merging these changes.
My feedback is non blocking, PR authors may dismiss my suggestions.
LGTM!
Code change:
also provide an update framework, which verifies the integrity and authenticity of firmware updates before allowing installation. <del> 3.7.2.1. Even with a robust firmware update system, the following problems remain as given below: </del> <ins> The various stake holders of a firmware update system wants to ascertain: </ins> How does the client applying the firmware update on the system know that the received firmware is not faulty or malicious?

Related discussion:
text: NAME the revisions seem to place greater emphasis on package managers, removing the original intent. The original intent was much broader and could be applied to a wide swath of software distribution, i.e. GitHub, app stores, and package manager repos.
Sure, we can broaden the scope. Not a problem!
We had a detail discussion about this between me and Henk. Basically, I was all for the support of going to depict a real world example for each of the situation. However, this makes the document excessively long and verbose. We should make a judgment as a team as to: Where should the Use Case document reside ? Some members feel within Arch. Document, some feel as a separate RFC. Given the number of scenarios, should we abstract it to generic use case or we depict a specific example, next to each of them ? Is too long a document (when a separate RFC) acceptable to the group ?
NAME NAME NAME I have redone the PR post our meeting today. Please have a look..
This has been resolved now!
great improvements
Code change:
Yasskin, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard <del> Barnes, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> Barnes, Rohan Mahy, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

Related discussion:
text: Editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure (to Confusing terminology) Editor's draft PR preview: URL
Hi, Disclosure is used at least two ways in the document. to refer to the array containing the salt, (maybe name), and value. to refer to the base64url encoded string It's easy to understand how this could have happened, as both contain logically the same information. I propose explicitly calling these: disclosure array, and disclosure presentation I also propose calling the hash/digest of the disclosure the disclosure digest in full in every use. The only time we would use "disclosure" without one of these modifiers is talking about the process of disclosing in general. As for the plaintext of the claims that can be disclosed, I propose blinded claim. So the first paragraph of Section 4.1 would read: An SD-JWT consists of: a signed JSON document, a list of disclosure presentations (each of which reveals a blinded claim), and optionally an issuer key binding (discussed in Section 4.3). The signed JSON document (the JWT body) contains plaintext claims; and disclosure digests, each of which either refers to a specific blinded claim or is a decoy. The holder can include zero or more disclosure presentations without breaking the signature of the JWT body. The contents of the blinded claims cannot be modified, because the corresponding digest would no longer match any digest in the JWT body. Blinded claims can be individual object properties (key-value pairs) or array elements.
This is appreciated! I agree that we should be more consistent with our terms. I'm not sure about "disclosure presentation" as "presentation" suggests a specific meaning. Maybe just "disclosure" and "disclosure contents" is fine.
The current document attempts to mostly use "Disclosure" to mean the base64url encoded string. I think that works okay. Places where it's referring to the decoded JSON array should be fixed to be more clear. So I think I agree that "disclosure" and where needed "disclosure contents" would be good.
PR has editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure
made one suggestion, but overall, looks good to me! thank you!
Code change:
sent to that router, it will ultimately reach host (B) on the stub network. <ins> To achieve the reachability goal described above, this document assumes hosts attempting to reach destinations on the stub network maintain a routing table - Type C hosts as defined in RFC4191).  Type A and Type B hosts are out-of-scope for this document. </ins> 1.2. In addition to the interoperability goals we've described above, the

Related discussion:
text: Based on comment: URL and responses: URL URL it is clear that the SNAC stub router solution may in some cases not work if the IPv6 Host on the AIL that needs to send an IPv6 packet to a host on a stub network is a Type A or Type B Host. In fact, our assumption so far has been that it is a Type C host. Proposal: add clarification that solution scope is intended for Type C hosts on the AIL. (Though it might work for Type A and B hosts in particular cases, this is not in our scope.) Refer to RFC 4191 Section for the 3 host types. (FYI NAME
Looks like a good place to add this scoping information - in the goals section. Thanks Hello, I can try to respond from my viewpoint. This could help to identify the open issues. I don't see how RFC 8028 is relevant here. It has the following applicability: IPv6 host in a network that has more than one prefix, each allocated by an upstream network that is assumed to implement BCP 38 [RFC2827] ingress filtering The network/link (AIL) considered for SNAC-simple is a link with a single IPv6 on-link prefix. Either a global/ULA prefix allocated by e.g. a home router, or if that is missing, a ULA prefix allocated by one of the stub routers. So there's not "more than one prefix" and I don't see immediately if any problem would occur if we would have > 1 prefix. For example the IPv6 host on the AIL would remain reachable from an on-stub-network host, regardless of the IPv6 source address that the host on the AIL used. See also below for more info on this case for the packets in the other direction. This part I agree should be clarified in SNAC-simple. I assumed a Type C host for sure. And I would consider Type A and Type B to be even out of scope if required to keep the solution simple! One question is: what if a Type A/B host sent an IPv6 packet to the ULA dest address of a stub-Host ; and the packet would be routed to the default router of the home network? (E.g.
Code change:
sent to that router, it will ultimately reach host (B) on the stub network. <ins> To achieve the reachability goal described above, this document assumes hosts attempting to reach destinations on the stub network maintain a routing table - Type C hosts as defined in RFC4191).  Type A and Type B hosts are out-of-scope for this document. </ins> 1.2. In addition to the interoperability goals we've described above, the

Related discussion:
text: home router / Wi-Fi AP / ISP box) Wouldn't that default router immediately discover that the correct route is to send it to the stub router, based on the RA RIO advertisements? So the routing is not most efficient then but it works. If that is the case, we can still support Type A/B hosts although with some degraded performance/latency. I think we could clarify that the stub router must never ever advertise itself as a default router (or advertise a default route ::/0) on the AIL. This isn't in the draft yet. Not sure if that is what you meant here? The existing mentions of "default route(r)" in SNAC-simple are pertain to advertising itself as default route on the stub network side, not the AIL side, I believe. Given the above, even if the host would not follow rule 5.5, it would pick another source address, but still that address would be based on an IPv6 prefix that is on-link. So it means the stub router can correctly route back to that prefix and use IPv6 ND to find the host back on the link. And the IPv6 host if it is type C would still use the RA RIO advertisements to pick the next-hop router, regardless of its IPv6 source address. The only question I have is for the Type A/B hosts - they might pick a default router instead and the question is there if it would route back the packet to the right stub router on the AIL instead of sending the packet out onto the wider Internet. (My expectation is that it would work, but ... ) But this Type A/B host problem is there independent of the source address selection. Or am I missing something? Also keep in mind that there are in total 3 possible cases for a given stub router: Stub router uses its generated ULA prefix to assign a prefix for the stub network; and also to assign a prefix for the AIL. Stub router uses its generated ULA prefix to assign a prefix for the stub network; but another stub-router (there may be N stub routers in total, each with a different stub network) has assigned the AIL prefix. That means the prefixes don't use a shared ULA prefix. Stub router uses its generated ULA prefix to assign a prefix for the stub network; but another non-stub-router (e.g.