jiebi/CodeConvo huggingface dataset:
Code change:
connection SHOULD still send a GOAWAY frame before terminating the connection. <ins> The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in FramingLayer. </ins> The GOAWAY frame does not define any flags. The GOAWAY frame applies to the connection, not a specific stream.

Related discussion:
text: I haven't adjusted for vs. until that war is over. Note that I've explicitly added a format for the SETTINGS frame itself, which was missing.
+1 . This would make it easier to write extensions for both h2 and h3. Priorities draft suffers from the mixed presentation format right now.
OK, thanks for doing this NAME I merged this manually after fixing a few things up. From my commit: Use all caps for frame names Add a value for Type in frame definitions Change order of flag descriptions to match order in layout Make Exclusive field of PRIORITY optional Move PING ACK Flag to the right place Add SETTINGS ACK Flag Double-checking FTW. Of course, there's a good chance I also messed something up here. So feel free to check my work also.
I think the language about ordering is a bit weird, but it is clarified somewhat by the hex representations shortly after. I think those hex representations are doing the heavy lifting, as I’m not aware of any issue with interoperability caused by getting the flag indices wrong in practice. Nonetheless, if we’re really worried about it we could just delete “bit n” and replace it with “the x bit”, e.g. delete “bit 0” and replace it with “the bit”.
Code change:
Recommended HTTP status code: 500 <del> 3.28. </del> <ins> 3.27. </ins> Name: tls_rejected_proxy_certificate

Related discussion:
text: Signed-off-by: Piotr Sikora
cc NAME
This field uses for a specific purpose, but that's already in the generic parameters. Suggest or similar. /cc NAME
Looks like has the same issue. Should we use for both? Note that the identifier is context-based, since if proxy configured SHA256-based validation, then would be , if it configured SPKI-based validation, then would be , etc. We could also use and instead of (and for ), but that doesn't seem very future-proof. What do you think?
Hmm, that's awkward. Maybe two fields? E.g., : [, ... ] : ... Is there a registry we can refer to, maybe?
I'm afraid that there isn't any registry that we can refer to, at least none that I know of. (opaque type) and (opaque value) seem a bit awkward. Wouldn't it be easier to just have and params? Also, in Envoy, we actually configure list of acceptable and values, and matching against any of them works, so we should probably emit both of them anyway. I could envision merging and into a single status type that lists all 3 params, e.g. See . What do you think?
Better than what we had :)
Code change:
material used in the Encryption header field. The Crypto-Key header field uses the extended ABNF syntax defined in <del> Section 1.2 of RFC7230 and the "parameter" rule from RFC7231. </del> <ins> Section 1.2 of RFC7230 and the "parameter" and "OWS" rules from RFC7231. </ins> The "keyid" parameter corresponds to the "keyid" parameter in the Encryption header field.

Related discussion:
text: : These rules do not permit whitespace between a semicolon and a parameter, which was probably intended (judging from the examples and from similar rules elsewhere in HTTP). They should be rewritten as follows: and the import of the rule from RFC 7230 should be noted in the preceding text (“The "Encryption" header field uses the extended ABNF syntax . . .” and similarly for ).
Thanks for picking this up.
Code change:
The TCP connection can be closed by either peer.  The END_STREAM flag on a DATA frame is treated as being equivalent to the TCP FIN bit.  A client is expected to send a DATA frame with the END_STREAM flag set <del> after receiving a frame bearing the END_STREAM flag.  A proxy that </del> <ins> after receiving a frame with the END_STREAM flag set.  A proxy that </ins> receives a DATA frame with the END_STREAM flag set sends the attached data with the FIN bit set on the last TCP segment.  A proxy that receives a TCP segment with the FIN bit set sends a DATA frame with

Related discussion:
text: Going to let NAME have a look at this as well.
(Warning, I may have reached peak pedantry.) In Section 5.1, there are two references to frames which "contain" an ENDSTREAM flag. All HEADERS, CONTINUATION, and DATA frames contain this flag, which might be set or not. Most other references in the document are to the flag being set, which is more precise. There are also two references to frames "bearing" ENDSTREAM, which could be taken either way.
If you care enough to write the issue, maybe you also care enough to offer a pull request.
Code change:
5. <del> At the time of writing, there are four distinct Upgrade Tokens that are registered, associated with published documents, and not marked obsolete.  This section considers the impact of this document's considerations on each registered Upgrade Token. </del> <ins> This section describes the impact of this document's considerations on some registered Upgrade Tokens that are believed to be in use at the time of writing. </ins> 5.1. <del> RFC9110 is the source of the requirement quoted in background.  It also defines the "HTTP/*.*" family of Upgrade Tokens.  In HTTP/1.1, the only potentially applicable versions of this token are "0.9", "1.0", "1.1", and "2.0". Versions "0.9" and "1.0" are sufficiently syntactically similar to HTTP/1.1 that any such "downward upgrade" would be unlikely to result in the security concerns discussed here.  (An "upgrade" to version 1.1 has no effect at all.) A version number of "2.0" corresponds to HTTP/2.  Every HTTP/2 connection begins with a Client Connection Preface (RFC9113) that was selected to ensure that a compliant HTTP/1.1 server will not process further data on this connection.  This avoids security issues if an "HTTP/2.0" Upgrade Token is used optimistically. 5.2. </del> RFC2817 defines the "TLS/ " family of Upgrade Tokens, and correctly highlights the possibility

Related discussion:
text: There could possibly be a problem if the client, believing it is speaking HTTP/0.9, allows untrusted code to manipulate headers that were not special in HTTP/0.9 but are special in HTTP/1.1 (e.g. Content-Length, Transfer-Encoding). But as I said, this strikes me as counting angels on the head of a pin. "Upgrade: HTTP/0.9" is just not a thing, and we should all agree on that and move on.
I totally agree with you. I was more thinking about guidance for intermediaries that support other Upgrades (e.g., WebSocket) for what they should do if they encounter unknown/unexpected upgrade tokens like these. If there is no such guidance, than we can just go back to pretending that doesn't exist
HTTP intermediaries can't really do anything with unrecognized Upgrade tokens in HTTP/1.1. (Not even the useful thing, which would be to convert them to/from for Extended CONNECT.)
Code change:
The client makes a request to the token endpoint by sending the following parameters using the "application/x-www-form-urlencoded" format per Appendix B with a character encoding of UTF-8 in the HTTP <del> request entity-body: </del> <ins> request payload: </ins> REQUIRED.  Value MUST be set to "authorization_code".

Related discussion:
text: align terminology with RFC7231 term. I'd consider switching to httpbis-semantics URL
Hi NAME NAME it would be great to have some feedback on this PR. In case I could brush even more the spec to ensure compatibility with the ongoing HTTP work :)
Thanks! I'm working on this this week so I will take a look soon!
NAME let me know if you need more feedback ;)
This looks great. I'm not sure of the other implications of switching the references to draft-ietf-httpbis-semantics so we can discuss that in a new issue if you'd like.
Code change:
This variation, however, suffers from the same basic limitation as GET in that it is not readily apparent -- absent specific knowledge of the resource and server to which the request is being sent -- that <del> a search operation is what is being requested.  Web applications use the POST method for a wide variety of uses including the creation or modification of existing resources.  Sending the request above to a different server, or even repeatedly sending the request to the same server could have dramatically different effects. </del> <ins> a safe, idempotent query is being performed. </ins> <del> The SEARCH method provides a solution that spans the gap between the </del> <ins> The QUERY method provides a solution that spans the gap between the </ins> use of GET and POST.  As with POST, the input to the query operation is passed along within the payload of the request rather than as part <del> of the request URI.  Unlike POST, however the semantics of the SEARCH method are specifically defined. </del> <ins> of the request URI.  Unlike POST, however, the method is explicitly safe and idempotent, allowing functions like caching and automatic retries to operate. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

Related discussion:
text: For this use case, we just need a way for the server to also point to a GETtable resource (maybe with a lifetime). If we solved that problem, would we still need full cacheability?
Needs to sync with .
Code change:
This variation, however, suffers from the same basic limitation as GET in that it is not readily apparent -- absent specific knowledge of the resource and server to which the request is being sent -- that <del> a search operation is what is being requested.  Web applications use the POST method for a wide variety of uses including the creation or modification of existing resources.  Sending the request above to a different server, or even repeatedly sending the request to the same server could have dramatically different effects. </del> <ins> a safe, idempotent query is being performed. </ins> <del> The SEARCH method provides a solution that spans the gap between the </del> <ins> The QUERY method provides a solution that spans the gap between the </ins> use of GET and POST.  As with POST, the input to the query operation is passed along within the payload of the request rather than as part <del> of the request URI.  Unlike POST, however the semantics of the SEARCH method are specifically defined. </del> <ins> of the request URI.  Unlike POST, however, the method is explicitly safe and idempotent, allowing functions like caching and automatic retries to operate. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

Related discussion:
text: If the point of this exercise is to make safe-ness visible to intermediaries, then a method is the right place to put that signal. I'm comfortable enough with , though an entirely name would be equally good. (I think that we should continue discussion about cache keys separately.)
I value a lot the ability for intermediaries to filter out write requests before they reach an application. Reusing won't have this advantage.
Interim discussion: switch document to use , which has good support from the attendees, and see how it seems to people who would be adopting.
Que? This is far more than the simple rename I was expecting. I had a similar double-take on first read, but most of the additional changes appear to be excising the WebDAV references, which is reasonable to do along with the rename.
Code change:
NOT be reused in other protocols.  Doing so can undermine the security guarantees of the authentication. <del> Origins offering this scheme are able to link requests that use the same key.  However, requests are not linkable across origins if the keys used are specific to the individual origins using this scheme. </del> <ins> Origins offering this scheme can link requests that use the same key. However, requests are not linkable across origins if the keys used are specific to the individual origins using this scheme. </ins> 8.

Related discussion:
text: NAME that should already be covered by the last paragraph in this section. In particular the format is the Port is quite explicit there. Are you saying we should mention that strings are in ASCII?
No, sorry, I'm talking about the host name in particular. There was a long back and forth with Paul about the format of this field (is it the thing that appears in the HTTP request authority header, the thing that appears in the TLS SNI, etc), and we ended up being explicit. Just trying to save you some trouble down the road.
Oh, thanks. I agree we should be explicit. Could you point me to the specific text in Privacy Pass for this please?
Found the suggested Privacy Pass text and added to this PR.
I would recommend making the TLS exporter labels specific to the type of algorithm in use. For example, rather than use "EXPORTER-HTTP-Unprompted-Authentication-Signature" for signature-based authenticators, I might use "EXPORTER-HTTP-Unprompted-Authentication-Signature-Ed25519" for authenticators using Ed25519.
This would seem to have the drawback of making it complicated for intermediates to forward the authentication nonce. The alternative being for intermediary to implement the validation itself, which has its own drawbacks. Thinking why would one want to do something like this, I came up with vague ideas about possible cross-key tracking vectors. However, making labels algorithm-specific would not help if both keys happen to have the same type. One idea would be to mix the key id as context input, which would make the nonces be pretty much per-key in a way that is feasible for the first intermediary to calculate with no explicit algorithm support nor configuration.
An alternative proposal would be to just use a single context string for exporting the nonce but then somehow bind additional information into the signature computation at a higher layer. This would address the issue without complicating the intermediary story, I think.
Any case that involves intermediaries forwarding tokens will necessarily involve some amount of trust in the intermediary. The intermediary can provide the exporter output when it forwards the token, which would allow the signature to be verified, but the recipient is going to have to trust that this isn't copied from some other request. I definitely think that the context string is the right place to include origin, key identifier, algorithm choice, and maybe even some context from the request (URL).
Code change:
NOT be reused in other protocols.  Doing so can undermine the security guarantees of the authentication. <del> Origins offering this scheme are able to link requests that use the same key.  However, requests are not linkable across origins if the keys used are specific to the individual origins using this scheme. </del> <ins> Origins offering this scheme can link requests that use the same key. However, requests are not linkable across origins if the keys used are specific to the individual origins using this scheme. </ins> 8.

Related discussion:
text: That latter depends on how heavily people intend to lean on the intermediation case.
Discussed at IETF 116, sense of the room appeared to be that adding the key identifier and algorithm to the context made sense. We can skip URL and instead add realm, see
OK wrote up to address this
signatures are computed in a way that binds them to the origin which accepts the authenticator. While it's true that the nonce is a per-session concept, and the session is bound to a specific origin (by virtue of the TLS SNI), it seems possible for bugs to be introduced in settings where a TLS-terminating server supports more than one origin. Maybe the server accidentally sends an authenticator computed in a session for one origin to another, or something. I would follow in WebAuthn's footsteps here and sign something that's specific to the origin.
HTTPS sessions are not bound to a specific origin. There is no requirement for client to only use one origin on connection, and even if there was, TLS SNI is not fine-grained enough, as e.g. https://foo.example and https://foo.example:8443 are different origins, but have the same TLS SNI. Extending the idea of throwing some stuff into the context from httpwg/http-extensions, one could throw the origin (host/:authority) in as well (the contexts can be up to 65535 bytes, so there is plenty of space). This would bind the signatures to origin, would still work if host gets remapped somewhere, and could mitigate some tracking vectors. And it would still retain the no explicit configuration / no algorithm support property.
Oh, right, duh. We have connection coalescing! Throwing in the origin as you suggest seems like it work, and as in httpwg/http-extensions perhaps doing it above nonce generation is best.
Discussed at IETF 116, it seemed like the proposal most likely to succeed was to add the to the context
Regarding the question on , asking if origin and also URL should be part of the context. says, quote "unless specifically allowed by the authentication scheme, a single protection space cannot extend outside the scope of its server." So as NAME points out, we should include the origin.
Code change:
NOT be reused in other protocols.  Doing so can undermine the security guarantees of the authentication. <del> Origins offering this scheme are able to link requests that use the same key.  However, requests are not linkable across origins if the keys used are specific to the individual origins using this scheme. </del> <ins> Origins offering this scheme can link requests that use the same key. However, requests are not linkable across origins if the keys used are specific to the individual origins using this scheme. </ins> 8.

Related discussion:
text: discusses the danger of using the same context for different URLs belonging to the same origin, pointing out that it is an problem that already exists and explaining the mitigations (such as not forwarding the Authorization header to the application running on top of HTTP). Assuming that we would switch to using the Authorization header, I think we can rely on that. To paraphrase, there is no need to include URL in the context. In addition, we can1 include "realm" in the Context, so that there can be multiple "protection spaces" inside one origin. In the Unprompted Authentication scheme, there is no way for a server to signal the realm to be used. Therefore, as NAME pointed out, there has to be a default value that would be defined by the specification. Clients and servers can agree out-of-band to use a different value. 1: During the meeting, I asked as a pure question how Realm is to be used. In the follow-on discussion at least assumed that "realm" has to be part of the Unprompted Authentication as it is to use the Authorization header. However, reading RFC 9110 I realize that not all authentication schemes are required to support realms (i.e., having multiple protection spaces within an origin). Hence the "can."
OK wrote up to address this
This is a good change, but to avoid future nit picking I might clarify what are the types of each field in the context. For example, is the port an integer in network byte order? What is the format of the host string? We just went through a whole kerfuffle in Privacy Pass on this point, and my advice would be to address it early.
Code change:
able to interoperate with hosts on other network links in the same infrastructure as well as hosts on the global internet. <del> It may be noted that just as you can plug several Home Gateway devices together in series to form multi-layer NATs, there is nothing </del> <ins> It may be noted that just as you can plug several CE Router devices together in series to form multi-layer NATs, there is nothing </ins> preventing the owner of a stub network router from attaching it to a stub network as if that network were its infrastructure network.  In the case of an IoT wireless network, there may be no way to do this,

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.