jiebi/CodeConvo huggingface dataset:
Code change:
The "Host" header field in a request provides the host and port information from the target URI, enabling the origin server to distinguish among resources while servicing requests for multiple <del> host names on a single IP address. </del> <ins> host names. </ins> <del> Since the Host field value is critical information for handling a request, a user agent SHOULD generate Host as the first field in the header section. </del> <ins> In HTTP/2 RFC7540 and HTTP/3 HTTP3, the Host header field is, in some cases, supplanted by the ":authority" pseudo-header field of a request's control data. The target URI's authority information is critical for handling a request.  A user agent SHOULD generate Host as the first field in the header section of a request unless it has already generated that information as an ":authority" pseudo-header field. </ins> For example, a GET request to the origin server for <http://www.example.org/pub/WWW/> would begin with: <del> Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to poison a shared cache or redirect a request to an unintended server.  An interception proxy is particularly vulnerable if it relies on the Host field value for redirecting requests to internal servers, or for use as a cache key in a shared cache, without first verifying that the intercepted connection is targeting a valid IP address for that host. </del> <ins> Since the host and port information acts as an application-level routing mechanism, it is a frequent target for malware seeking to poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it relies on the host and port information for redirecting requests to internal servers, or for use as a cache key in a shared cache, without first verifying that the intercepted connection is targeting a valid IP address for that host. </ins> 7.1.3.

Related discussion:
text: Recently I noticed that the host header field is being discussed in . I believe that we should move the definition of the host header to the HTTP/1.1 messaging draft, and discuss about "authority" as a concept in the semantics draft, as the "host" header is specific to HTTP/1.1 (except for handling of broken HTTP/2 clients)?
Hi Kazuho, We discussed this on the editors' call. Host's semantics aren't specific to HTTP/1.1, even if its requirements are different in other protocol versions. That's why we moved it to Semantics; it's not version-specific (and really very few headers should be). Closing; if you feel it needs more discussion please request re-opening and we'll do so.
Thank you for the consideration. While I do understand the argument that the semantics of the header field is not version specific, the use is. I've opened a PR that tries to clarify that.
Thank you for the changes!
Code change:
The "Host" header field in a request provides the host and port information from the target URI, enabling the origin server to distinguish among resources while servicing requests for multiple <del> host names on a single IP address. </del> <ins> host names. </ins> <del> Since the Host field value is critical information for handling a request, a user agent SHOULD generate Host as the first field in the header section. </del> <ins> In HTTP/2 RFC7540 and HTTP/3 HTTP3, the Host header field is, in some cases, supplanted by the ":authority" pseudo-header field of a request's control data. The target URI's authority information is critical for handling a request.  A user agent SHOULD generate Host as the first field in the header section of a request unless it has already generated that information as an ":authority" pseudo-header field. </ins> For example, a GET request to the origin server for <http://www.example.org/pub/WWW/> would begin with: <del> Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to poison a shared cache or redirect a request to an unintended server.  An interception proxy is particularly vulnerable if it relies on the Host field value for redirecting requests to internal servers, or for use as a cache key in a shared cache, without first verifying that the intercepted connection is targeting a valid IP address for that host. </del> <ins> Since the host and port information acts as an application-level routing mechanism, it is a frequent target for malware seeking to poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it relies on the host and port information for redirecting requests to internal servers, or for use as a cache key in a shared cache, without first verifying that the intercepted connection is targeting a valid IP address for that host. </ins> 7.1.3.

Related discussion:
text: by changing DL to a table and tweaking description of HEAD.
"HEAD: the same representation as GET, but without the representation data;" Should that be "payload data"?
No, that's correct, but I will tweak it slightly: HEAD: the same representation as GET, but without transferring the representation data;
Note that the context is a discussion of what representation is included in a 200 response, which is why we are talking about representation data here instead of payload data.
Code change:
content with a length prefix, and a trailer section with a length prefix. <ins> For a known-length encoding, the length prefix on field sections and content is a variable-length encoding of an integer.  This integer is the number of bytes in the field section or content. </ins> Response messages that contain informational status codes result in a different structure; see informational.  Note that while the Known- Length Informational Response field is shown in format-known-length,

Related discussion:
text: I missed this from NAME but it's a point well-taken. Not defining this was sloppy.
This was buried inside which was closed so I'm opening a new issue. The draft currently shows: This Length field isn't well defined. Is it the length of the Known-Length Field Section in bytes or in lines? It would really help if this draft defined every single field it declares.
The draft currently shows: This Length field isn't well defined. Is it the length of the Known-Length Field Section in bytes or in lines? If in bytes, does it include or exclude the length of the Length field itself? Either way, I don't understand why Length is at least 2. Either it's possible for there to not be any field lines, in which case maybe it should be zero. And if there needs to be at least one field line, then (we should say so, and) the minimum number should be 3, because a field line is two lengths and at least one byte of field name.
To pile on here, the spec also says in one place and in another It's a little ambiguous but f the value also can't be zero-length, then the minimum should be 4? (by David's second interpretation)
NAME see
Yeah saw that after hitting the button. Didn't intend to derail
Thanks
Code change:
The "Early-Data" request header field indicates that the request has been conveyed in early data, and additionally indicates that a client <del> understands the 4NN (Too Early) status code. </del> <ins> understands the 425 (Too Early) status code. </ins> It has just one valid value: "1".  Its syntax is defined by the following ABNF ABNF:

Related discussion:
text: (I accidentally put this on master without noticing earlier, sorry.)
Can we just have 425 now that it's official-ish? From martinthomson/http-replay
Code change:
Digest Algorithm: unixsum <del> Description: The algorithm computed by the UNIX "sum" command, as defined by the Single UNIX Specification, Version 2 UNIX. </del> <ins> Description: The algorithm used by the UNIX "sum" command UNIX. </ins> The output of this algorithm is an ASCII decimal-digit string representing the 16-bit checksum, which is the first word of the output of the UNIX "sum" command.

Related discussion:
text: There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM
Code change:
application.  For example, a SUBSCRIBE namespace=foobar message will be forwarded to the session that sent ANNOUNCE namespace=foobar. <ins> When a relay receives an incoming SUBSCRIBE for a given namespace, for each publisher that has announced that namespace, the relay MUST send a SUBSCRIBE to that publisher unless it already has an active subscription to that publisher for the full track name in the incoming SUBSCRIBE. When a relay receives an incoming ANNOUCE for a given namespace, for each active subscription that matches that namespace, it MUST send a SUBSCRIBE to that publisher that send the ANNOUCE. </ins> OBJECT message headers carry a short hop-by-hop "Track Alias" that maps to the Full Track Name (see message-subscribe-ok).  Relays use the "Track Alias" of an incoming OBJECT message to identify its track

Related discussion:
text: Many thanks on review and any help of fixing all the small stuff (point me too it, or PR on the PR, anything) much appreciated.
NAME - thanks for review. I think I fixed all the stuff you raised. Can you take another look NAME - handing the baton to you on this one. Thanks you
At interim, to support make before break use-cases, we need to clarify relay behavior when a new announce arrives for existing published.
This came up during discussion of . The current draft is ambiguous whether multiple distinct publishers (not reconnect) can announce the same namespace to a relay. If that is allowed, should SUBSCRIBE messages be sent to all publishers that have announced that namespace? What happens if multiple SUBSCRIBE_OKs come back? Do we need normative text describing how a relay handles all these situations, or is it implementation specific? Some possible error conditions: Two publishers publisher the same track/group/object with different content One publisher skips an object (perhaps due to a delivery timeout) but another publisher sends it ?
I initially added a recommended session migration algorithm in . However it's too prescriptive and non-normative and I removed it. However I do think we should talk about what it takes to gracefully migrate a MoqTransport session, if it's non-obvious and should be in the draft (maybe an appendix), and if we need more mechanisms in the protocol. This recommended algorithm requires servers to not error on a duplicate ANNOUNCE. It also results in an RTT where duplicate OBJECTs will arrive on both sessions, which is not necessarily ideal. Here's the original text before I removed it:
I think it'd be useful to have a PR to look at if you're willing to write one up?
Code change:
<del> SD-JWT: Selective Disclosure for JWT and JWS with JSON payloads </del> <ins> SD-JWT: Selective Disclosure for JWT and JWS with JSON Payloads </ins> draft-ietf-oauth-selective-disclosure-jwt-latest Abstract

Related discussion:
text: changes. created a common sd-jwt verification section wallet processing section talks only about presentation creation verifier processing section talks only about key binding JWT processing and refers to a common sd-jwt verification section Note that the terminology is new - based on the PR that NAME is doing for issue (probably not touching these sections in your PR might be the best to minimize conflict, Brian, or I can push later to your branch - wanted to do this PR while I had the idea fresh in my head). I used as a placeholder.
The direction of this looks good. Thanks for putting together the PR! I made just a few cleanup type comments/suggestions. Some do touch on the terminology, but otherwise think I can avoid this section in the in-progress PR
I do think a document history bullet should be added - "Consolidate processing rules for Holder and Verifier"
As discussed on a recent call - merging this now and closing the associated issues. NAME intends to look at it in the main branch and propose additional changes in a new PR, if there are opportunities for improvement.
Code change:
"urn:ietf:params:oauth:grant-type:saml2-bearer" to indicate SAML. Other grant types MAY be used to indicate other formats. <del> 2.3.5. </del> <ins> 2.3.4. </ins> Authorization servers MAY choose to:

Related discussion:
text: parameter removed from token exchange request section as this is already specified in RFC8693 Resource/audience section merged into request section. added more author details
Code change:
8.3. <del> If caching is required (e.g., to enable the use of alternative mechanisms for hosting, like Content Delivery Networks), the control of the caching mechanism SHOULD be implemented using the standard HTTP Cache-Control as defined in RFC9111. 8.4. </del> TBD 9.

Related discussion:
text: Changes the CWT example to a Hex and annotated Hex version instead of diagnstic. Rendered version: URL Did you have time to check this example with your team NAME
We have a CWT in 6.3 in diagnostic notation and decided to add a raw (hex) example to the annex
Code change:
signature over the empty string. If the signature's Algorithm name does not start with rsa, <del> hmac, or ecdsa, signers SHOULD include (created) and (request- target) in the list. </del> <ins> hmac, or ecdsa, signers SHOULD include "*created" and "*request-target" in the list. </ins> If the signature's Algorithm starts with rsa, hmac, or ecdsa, <del> signers SHOULD include date and (request-target) in the list. </del> <ins> signers SHOULD include "date" and "*request-target" in the list. </ins> Further guidance on what to include in this list and in what order is out of scope for this document.  However, the list

Related discussion:
text: Replaced unstructured header with and Dictionary Structured Header Fields. Defined content identifiers for individual Dictionary members, e.g., . Defined content identifiers for first N members of a List, e.g., . A signature in a request now looks like this:
I like this PR! We just need some tweaks, but it greatly improves the way the spec can be used.
This PR also fixes . Should we remove that appendix in this PR?
Redefine the Signature header field to use . This will simplify both the definition and the parsing of this header field value.
The Covered Content list, Algorithm, and Verification Key identifier should all be part of the Signature Input, to protect against malicious changes.
The Covered Content list contains identifiers for more than just headers, so the parameter name is no longer appropriate. Some alternatives: "content", "signed-content", "covered-content".
I like the direction this PR is taking: spec is more focused because it outsources spec of field format to draft-kamp-httpbis-structure dictionary format is more flexible and allows multiple signatures (important)
Code change:
to obtain the QR code displays a message to the attacker with instructions on how to access their account. <del> 3.4.7. </del> <ins> 3.4.8. </ins> An attacker creates a message to all employees of a company, claiming to be from the company's IT service provider.  They claim that they

Related discussion:
text: See issue
There are two new attacks, the consent bombing and fake helpdesk attacks, that may be added as examples of attacks, or as extensions of existing attacks.
After discussing ith Daniel we agreeed: Add an example for the consent bombing attacks Add a sub-attack to example B.4 (split into two attacks).
Code change:
RFC4559) have been known to violate this requirement, resulting in security and interoperability problems. <del> 3.8. </del> <ins> 3.7. </ins> A "

Related discussion:
text: seems very out of place. I could almost see it as content in 3, as a kind of introduction to the terminology. There are of course other places it could go, but the current location doesn't make much sense.
I moved the ascii art diagram back to the origin server section (where it came from in 7230) since it leads into the other diagrams.
Code change:
The authorization server MAY add, remove or change claims.  See transcribing-claims. <del> 2.3.3. </del> <ins> 2.4.3. </ins> The authorization grant format and content is part of a contract between the authorization servers.  To achieve a maintainable and

Related discussion:
text: Added use cases. We may want to refine these, or move them into a non-normative section later.
Code change:
7.1. <ins> IANA is asked to update the "Hypertext Transfer Protocol (HTTP) Field Name Registry" registry (SEMANTICS) according to the table below: 7.2. </ins> This memo sets this specification to be the establishing document for the Hash Algorithms for HTTP Digest Fields [2] registry defined in algorithms.

Related discussion:
text: simplifies IANA field registration section obsolete Digest
Thanks for this, it's almost there. I suggest we just have two sections that ask IANA to do things directly, rather than giving any prelude to those instructions.
Code change:
Recommended HTTP status code: <del> 2.3.32. </del> <ins> 2.3.28. </ins> Name: proxy_internal_error

Related discussion:
text: PTAL NAME NAME NAME
Looks reasonable to me!
NAME PTAL; I'll merge tomorrow if I don't hear anything.
NAME how do you distinguish between a proxy certificate and the certificate used for the next hop?
By "proxy certificate" I mean the certificate sent by the CDN (when acting as a client) to the origin server for the purpose of mutual authentication. In contrast, would apply (at least in my mind) only to the certificate presented by the origin server.
So, I think the argument is that is either a (i.e., the server you're connecting to gave you an error to the effect that you need to present a client certificate), or a (i.e., you realised you need to present a certificate before connecting, but don't have one) depending on exactly how the error occurred. Is that sufficient?
As someone who spent countless hours debugging connection issues to various origin servers, my main concern is that alone doesn't provide enough information as to why the connection failed, it only narrows it down to a TLS certificate issue, but for anything definitive that you would want to share with the customer, you'd still need to go and dig further into logs, or try to replicate the issue. Yes, I know that you could put more information in the "details" field, but I'm not a big fan of implementation-specific free-form text. Having said that, I'm not going to oppose if you prefer to have only those 3 generic fields.
Thanks. As Ryan points out, the problem is that implementations have different terminology and granularity of error reporting, and it's not the place of this specification to impose that on them.
Looking at what to map x509 errors (as returned by into, the most obvious one is . However, there's also , which is one of these errors. It seems odd to have these two, but not any of the many other verification errors. At first glance, I suspect it may be better to have a single error, and let the convey the reason - whether it's expiration or something else.
Ultimately, there is a fine balance between providing a generic "catch-all" error, and enumerating all possible errors. The linked lists 69 possible reasons for success or failure, and including all of them clearly doesn't make sense, especially when only a few of them will happen in practice.
Code change:
Recommended HTTP status code: <del> 2.3.32. </del> <ins> 2.3.28. </ins> Name: proxy_internal_error

Related discussion:
text: However, having only a generic "catch-all" error with the real reason "hidden" in a free-form text in , that's going to vary from implementation to implementation, is going to make this less useful for any kind of automated processing and/or analysis. Ideally, I think, we should have specific enums that cover 95%+ of reasons happening in production, and only use the generic "catch-all" error for things not covered by them... So, playing the devil's advocate, perhaps we should add a few more? (Note that there is already raised on mismatched identity, SHA256, SPKI or other missed expectations.) Also, if you can get your hands on errors happening in production, that could help us make more informed decision here.
I agree we shouldn't do a 1:1 mapping (especially with a library), but the hierarchy needs to be clear, and mapped to terminology used in the standards. I.e., there should be a generic catch-all 'cert error' code, and then more specific ones for the major classes of problems.
TLS itself also contains a pile of certificate-verification-related alerts. Although I think the set is mostly just carried over from SSL. URL NAME may also have some thoughts on certificate verification error-reporting.
Despite what libraries may provide, for their developers, is fairly clear: the only defined result is a I think coupling any protocol-level expectation about diagnostics for errors is fundamentally misaligned. It should not matter, for example, whether a particular library checks the validity period of the certificate before the signature. We know, empirically, that different libraries do very different things there: macOS vs Mozilla NSS vs Microsoft CryptoAPI each verify something like validity at different points within their verification algorithms. We know it's deeply flawed to view there being "the" certificate chain for a server, because by definition, the chain is defined by the client's policy and set of trust anchors. As a consequence, we know that clients SHOULD implement certificate path building, to explore possible certificate chains, and we know that TLS 1.3 was explicitly updated to reflect those decades of running code and the emergent rough consensus that the message, beyond the first , is an attempt to aid/influence that. is a huge collection of different ways verifiers can process and examine errors, during forward path building and reverse verification, and notes that the trade-offs are heavily dependent upon client and use cases.