jiebi/CodeConvo huggingface dataset:
Code change:
6.4. <ins> CNAME records in the DNS are frequently used to delegate authority for an origin to a third-party provider.  This delegation can be changed without notice, even to the third-party provider, simply by modifying the CNAME record in question. After the owner of the domain has redirected traffic elsewhere by changing the CNAME, new connections will not arrive for that origin, but connections which are properly directed to this provider for other origins would continue to claim control of this origin (via ORIGIN frame and Secondary Certificates).  This is proper behavior based on the third-party provider's configuration, but would likely not be what is intended by the owner of the origin. This is not an issue which can be mitigated by the protocol, but something about which third-party providers SHOULD educate their customers before using the features described in this document. 6.5. </ins> Implementations need to be aware of the potential for confusion about the state of a connection.  The presence or absence of a validated certificate can change during the processing of a request,

Related discussion:
text: but I'd prefer a better recommendation here than "educate your customers."
Suppose a site is hosted on a particular provider (or CDN, equally). The customer flips the DNS entry to point to a new provider. However, the old provider doesn't know that and might continue to serve traffic via ORIGIN + Secondary Certificates for requests that originally reach the provider via other DNS records. It's current industry practice to leave the old provider configured and hot during a transition to ensure the graceful cutover. However, the DNS record change is considered to be sufficent. We might want to recommend that servers periodically ensure the DNS record points to them before serving Secondary Certificates / ORIGIN references. I think this is Security Considerations prose, not protocol elements or requirements, however.
Code change:
The minimum requirements for approval for widespread deployment in the global Internet include the following guidelines on: (1) <del> assessing the impact on standard congestion control, (3) investigation of the proposed mechanism in a range of environments, (4) protection against congestion collapse, and (8) discussing whether the mechanism allows for incremental deployment. For other guidelines, i.e., (2), (5), (6), and (7), the author must perform the suggested evaluations and provide recommended analysis. Evidence that the proposed mechanism has significantly more problems than those of TCP should be a cause for concern in approval for widespread deployment in the global Internet. </del> <ins> assessing the impact on standard congestion control, (2) performance in wireless environments, (4) investigation of the proposed mechanism in a range of environments, (5) protection against congestion collapse, and (10) discussing whether the mechanism allows for incremental deployment. For other guidelines, the author must perform the suggested evaluations and provide recommended analysis.  Evidence that the proposed mechanism has significantly more problems than those of TCP should be a cause for concern in approval for widespread deployment in the global Internet. </ins> 5.

Related discussion:
text: at the time 5033 was written, only TCP, DCCP and SCTP were around, using CC; nowadays, many more protocols use CC - with QUIC standing out as a here, probably warranting it's explicit mentioning.
Yes. Note that there is a bit of sadness here, because QUIC was forced to describe use of Reno in RFC 9002, while most deployments use Cubic or BBR. But the WG could not go beyond Reno... because of RFC 5033!
This one seems simple, but is not. The introduction text says: This formulation, "Impact on standard TCP", assumes that the congestion control algorithm is an integral part of the TCP specification. The situation has changed, and I think this part should be rewritten as: The reference here should be RFC9000, the specification of the transport protocol, rather than RFC9002, the specification of default loss recovery and congestion control algorithms. And the text should then be modified to mention that our goal is to not wantonly disrupt existing deployments -- whether they use Reno, Cubic or BBR. The point is "don't disrupt the Internet", not "don't offend the pride of the IETF".
Looks good.
Code change:
The minimum requirements for approval for widespread deployment in the global Internet include the following guidelines on: (1) <del> assessing the impact on standard congestion control, (3) investigation of the proposed mechanism in a range of environments, (4) protection against congestion collapse, and (8) discussing whether the mechanism allows for incremental deployment. For other guidelines, i.e., (2), (5), (6), and (7), the author must perform the suggested evaluations and provide recommended analysis. Evidence that the proposed mechanism has significantly more problems than those of TCP should be a cause for concern in approval for widespread deployment in the global Internet. </del> <ins> assessing the impact on standard congestion control, (2) performance in wireless environments, (4) investigation of the proposed mechanism in a range of environments, (5) protection against congestion collapse, and (10) discussing whether the mechanism allows for incremental deployment. For other guidelines, the author must perform the suggested evaluations and provide recommended analysis.  Evidence that the proposed mechanism has significantly more problems than those of TCP should be a cause for concern in approval for widespread deployment in the global Internet. </ins> 5.

Related discussion:
text: The guidelines section as discussion of "Difficult Environments", starting with "The proposed algorithms should be assessed in difficult environments such as paths containing wireless links." Opinion may vary, but wireless links are probably now part of something between "a vast majority" and "a plurality" of the paths on the Internet.
I agree. Wireless serves the vast majority and are still increasing.
Gorry and Martin: wireless constraints deserve their own section. Three different phenomena to discuss Non-congestion loss Variable bandwidth on the path Jitter due to media access and link-layer retransmission
I changed based on the thread with Christian, and agreed to these insights. I think this ready.
Code change:
deliberately crafted to bypass security filters along the request chain. <del> A client MUST send a Host header field in all HTTP/1.1 request messages.  If the target URI includes an authority component, then a client MUST send a field value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@" delimiter (http.uri).  If the authority component is missing or undefined for the target URI, then a client MUST send a Host header field with an empty field value. </del> <ins> A client MUST send a header field (field.host) in all HTTP/1.1 request messages.  If the target URI includes an authority component, then a client MUST send a field value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@" delimiter (http.uri). If the authority component is missing or undefined for the target URI, then a client MUST send a Host header field with an empty field value. </ins> A server MUST respond with a

Related discussion:
text: Reviewer: Marco Tiloca Review result: Ready with Nits Thanks for this document! I have found it very well written and I believe it's basically ready. Please, see below some minor comments and nits. Best, /Marco [X] [Section 1.2] As to "absolute-path", it is more precise to point to Section 4.1 of [HTTP]. Editors: URL [X] [Section 3] "HTTP does not place a predefined limit on the length of a request-line, as described in Section 2 of [HTTP]" This can better point to Section 2.3 of [HTTP]. Editors: URL [X] [Section 3.2] "A client MUST send a Host header field in all HTTP/1.1 request messages." This sentence can be expanded to point to Section 7.2 of [HTTP]. "... excluding any userinfo subcomponent and its "NAME delimiter ..." This should point to Section 4.2.4 of [HTTP]. Editors: URL [X] [Section 3.3] "Alternatively, it might be better to redirect the request to a safe resource that explains how to obtain a new client." Is "client" actually the intended word here? Or is it about using redirection to explain the client how to obtain something else (e.g. a proper authority component for a follow-up request) ? Editors: client is the intended word here: this case is only possible if the client sent an HTTP/0.9 or HTTP/1.0 request without a Host header field, which should not be in any deployed client since 1995. [X] [Section 7.1.2] I believe it's better for the reader if the last paragraph is split into 2 or 3 sentences Editors: [X] [Section 9.8] "When encountering an incomplete close, a client SHOULD treat as completed all requests for which it has received ..." Shouldn't this be about received responses? Or does it refer to the completion of the exchanges started by the mentioned requests? Editors: yes, it's about the completion of the exchanges. [X] [Appendix A] The first paragraph can better point to Section 5.6.1 of [HTTP]. Editors: URL The reference for "absolute-path" should be Section 4.1 of [HTTP]. Editors: URL
Long indeed. NAME - do you want to give that a try?
Code change:
6. This section details the interoperability requirements for <del> implementers of claim issuance and validation libraries, and </del> <ins> implementers of claim issuance and validation libraries, and of </ins> transparency services. 6.1.

Related discussion:
text: NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!
Code change:
the existence of particular claims) can be a side-channel disclosing information about otherwise undisclosed claims.  In particular, if a claim in an SD-JWT is present only if a certain condition is met <del> (e.g., a membership number is only contained if the End-User is a member of a group), the Issuer SHOULD add decoy digests when the condition is not met. </del> <ins> (e.g., a membership number is only contained if the user is a member of a group), the Issuer SHOULD add decoy digests when the condition is not met. </ins> Decoy digests increase the size of the SD-JWT.  The number of decoy digests (or whether to use them at all) is a trade-off between the <del> size of the SD-JWT and the privacy of the End-User's data. </del> <ins> size of the SD-JWT and the privacy of the user's data. </ins> 10.5.

Related discussion:
text: should prob add something in history just for posterity - even just a -14 with a "stuff from WGLC part deux"
Code change:
to be deployed without fear that they will be blindly forwarded by older intermediaries. <ins> Furthermore, intermediaries SHOULD remove or replace field(s) whose semantics are known to require removal before forwarding, whether or not they appear as a Connection option, after applying those fields' semantics.  This includes but is not limited to: </ins> The Connection header field's value has the following grammar: Connection options are case-insensitive.

Related discussion:
text: NAME the ABNF is not the source of truth; as discussed, it's the recommended generated form. We have prose in that we use to do things like explicitly allow LFs to be separators and folding to be performed. Given that there is confusion, interoperability issues and security issues around bare CRs, a clear requirement seems proportional - especially when the ABNF does not specify error handling. I could see an argument to downgrade the requirement relating to generation to a note that it's not allowed, and I could see broadening the language in semantics to say that CRLF and LF are also not allowed.
For field values (Semantics), we clarify that these are illegal to generate. For recipients, we can say that for error handling, rejecting or converting to SP is common. Not sure what else needs to be said in Messaging.
I think that the security aspect justifies a new requirement; how about "MUST either reject or remove; suggest replacing with SP"? I was thinking about outside the field values -- mostly in the request-line and status-line. That said, I agree it's much less of a concern there, and I'm OK with dropping it if you think it's not worth it. I'll update the PR if you think the above is workable.
s/MUST either reject or remove/MUST either reject or replace/ ...I guess. Yes, that sounds right to me; although there might be pusback on the MUST (me neutral). The part for Messaging I believe deserves a separate issue and discussion.
NAME I'll make a change note in Messaging. WRT Semantics, the adjacent text about folding effectively deals with LF and CRLF. If you want to go to the trouble of separating into two issues and two pull requests, feel free. I'd rather just get it closed.
/me looks - NAME it already is called out. Please re-review.
On my agenda for today.
opened for field values
Splitting the issue was king of intrusive, sorry for that. The changes for [Messaging] have been merged. For [Semantics] please see URL
Popular clients handle LF, CR, and CRLF as newlines. HTTP only defines CRLF. Previously: URL
To clarify, this is about the CRLF in the HTTP-message production.
Covered here: URL ... but I agree it could be more visible (e.g., in 3).
Code change:
to be deployed without fear that they will be blindly forwarded by older intermediaries. <ins> Furthermore, intermediaries SHOULD remove or replace field(s) whose semantics are known to require removal before forwarding, whether or not they appear as a Connection option, after applying those fields' semantics.  This includes but is not limited to: </ins> The Connection header field's value has the following grammar: Connection options are case-insensitive.

Related discussion:
text: And clients also accept lone CR. It seems worth testing either that they reject (network error) or adding that.
NAME see - in situ, see URL I'm still not sure it's obvious enough to someone reading in isolation; thoughts?
NAME that text does not treat CR without LF as a newline, unless I'm missing something. That text even seems to suggest that CRCRLF would be a single newline, whereas I'm pretty sure it ends up being treated as two newlines.
NAME I'm pretty sure CR alone is not valid, because I remember such a discussion a few years ago by the time haproxy used to accept this, after which I removed support for this. CRCRLF could at best be considered as a CR at the end of a line, though normally it's not a valid character there. It may possibly be replaced by LWS though.
Just found it, its in RFC7230.5 : URL Although the line terminator for the start-line and header fields is the sequence CRLF, a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR.
Right, I realize it's not valid, but I also know that clients nevertheless accept it, which is why I raised this.
All clients?
If they don't, they're not interoperable on the Web as we know it.
The Web as we know it does not contain any CR-only line-delimited protocol services other than those deliberately attempting response smuggling. The protocol specifically forbids bare CR as a line delimiter, since that is known to not be interoperable with the vast majority of protocol parsers that exclusively check for LF and ignore CR. This was a big deal in 1994, but even then it was obvious that CR-delimited messages wouldn't make it through proxies. Nobody has objected to it since OS X was released and the last of the native Mac servers disappeared. If some browsers interpret CR as a line delimiter in HTTP protocol fields (other than payload content), they have security holes that should be fixed. No change to the RFC is possible here; we can't make changes that introduce new security holes to previously compliant parsers.
I wrote some tests for this: URL Suggestions for more tests appreciated. Firefox seems to generally take the CR and include it in the value of whatever preceded it (reason phrase or header value, despite those not allowing this character).
Code change:
to be deployed without fear that they will be blindly forwarded by older intermediaries. <ins> Furthermore, intermediaries SHOULD remove or replace field(s) whose semantics are known to require removal before forwarding, whether or not they appear as a Connection option, after applying those fields' semantics.  This includes but is not limited to: </ins> The Connection header field's value has the following grammar: Connection options are case-insensitive.

Related discussion:
text: Chrome and Safari treat it as LF in those places, but they do not allow two CRs to end the header block (network error in Safari, empty body in Chrome). It does seem that a stricter stance is possible here, given the intersection of the results. cc NAME NAME
If we can be stricter here and just fail on CRs in headers, that sounds good to me. That having been said, I think changing behavior to anything but just rejecting the response would be worse than the status quo (Treating CRs as part of header values, for instance).
Yeah, it seems like CR CR could be treated as a network error at least. CR "after" reason phrase or individual header is less clear. But I agree that making CR part of the value isn't good.
Regarding at the end of the line, we currently say?
Code change:
OPTIONAL.  URL of the protected resource's JWK Set JWK document. <del> This contains keys belonging to the protected resource.  For instance, this JWK Set MAY contain encryption key(s) that are used to encrypt access tokens to the protected resource.  When both signing and encryption keys are made available, a "use" (public key use) parameter value is REQUIRED for all keys in the referenced JWK Set to indicate each key's intended usage. </del> <ins> This contains public keys belonging to the protected resource. For instance, this JWK Set MAY contain encryption key(s) that are used to encrypt access tokens to the protected resource.  The JWK Set MAY also contain signing key(s) that the resource server uses to sign responses.  When both signing and encryption keys are made available, a "use" (public key use) parameter value is REQUIRED for all keys in the referenced JWK Set to indicate each key's intended usage. </ins> RECOMMENDED.  JSON array containing a list of the RFC6749 "scope"

Related discussion:
text: From BC's comments: URL FAPI Message Signing talks about the RS signing resource responses. This specification could be how the RS publishes the public key, as mentioned in 5.6.6.2 URL
I can see why this one was tricky. One more suggestion to approve, then merge.
Code change:
There are many types of Statements (such as SBOMs, malware scans, audit reports, policy definitions) that Issuers may want to turn into Claims.  The Issuer must first decide on a suitable format to <del> serialize the Statement, such as: - JSON-SPDX - CBOR-SPDX - SWID - CoSWID - CycloneDX - in-toto - SLSA </del> <ins> serialize the Statement, such as: JSON-SPDX CBOR-SPDX SWID CoSWID CycloneDX in-toto SLSA </ins> Once the Statement is serialized with the correct content type, the Issuer should fill in the attributes for the Registration policy

Related discussion:
text: Cleaning up the Federation section, still TBD.
Also:
Linting errors need to be addressed. NAME if this blocks publishing / merging perhaps we can merge and then fix?
Yes, I can fix the lint after merging. If this would be a branch and not a fork, I could do it here more easily.
lgtm, any objections? still in early stage
Code change:
4.4. <del> The following shows the contents of a release document for Example 1: </del> <ins> The following shows the contents of an SD-JWT-R for Example 1: </ins> For each claim, an array of the salt and the claim value is contained in the object. <del> Again, the release document follows the same structure as the </del> <ins> Again, the SD-JWT-R follows the same structure as the </ins> <del> in the SD-JWT.  For Example 2, a release document limiting </del> <ins> in the SD-JWT.  For Example 2, a SD-JWT-R limiting </ins> to

Related discussion:
text: addresses issue
The way it is written now does not look like terms and definitions. It would also be a good practice to make it possible to the definition to replace the terms that appear in the main text. With this respect, verbose explanations especially the mechanisms should be done in the "Concepts" section in the main text. In fact, much of the text in the current "terminology" mostly duplicates what is being explained in 3. Concept Also, examples etc. should be added as a note to the definition and not as part of the definition text. Proposes the following as amended text Terms and definitions 2.1 SD-JWT signed JWT ], that supports selective disclosure as defined in this document Note to entry: Signed JWT is JWS. 2.2 release (SD-JWT-R) document that contains a subset of the claim values of an SD-JWT in a verifiable way Note to entry: Holder binding is also possible. 2.3 issuer entity that create SD-JWTs (2.1) 2.4 holder entity that has control over SD-JWTs (2.1) Note to entry: If holder binding is desired, the holder also has the signing key for the verification key contained in the SD-JWT. 2.5 verifier entity that checks and extracts the claims from SSD-JWT-R (2.2)
closing with PR
Currently, it has Conventions and Terminology Terminology Having two "Terminology" as consecutive headings is not good. I propose to change 2 as follows: Terms and Definitions
closing with PR
Code change:
Live content requires significant bandwidth and resources.  Failure to set limits will quickly cause resource exhaustion. <del> MOQT uses QUIC flow control to impose resource limits at the network layer.  Endpoints SHOULD set flow control limits based on the anticipated bitrate. </del> <ins> MOQT uses stream limits and flow control to impose resource limits at the network layer.  Endpoints SHOULD set flow control limits based on the anticipated bitrate. </ins> Endpoints MAY impose a MAX STREAM count limit which would restrict the number of concurrent streams which a MOQT Streaming Format could

Related discussion:
text: Given this also runs over WebTransport, it's best to avoid QUIC unless it's specifically referring to the transport.
Though MOQT is optimized for QUIC, it technically can go over WebTransport over HTTP/1 or HTTP/2. There are a number of cases when QUIC is used when it could be something else and in most cases, specifying QUIC is not critical to the design. For example "Consumer: A QUIC endpoint receiving media over the network." Also, the definitions in 1.2 frequently reference terms defined later in the list.
Absolutely. Stream prioritization and congestion control is better with QUIC, and thus can support lower latencies, but MoQ over TCP should still work well enough.
For what its worth, we did did say during chartering that were were not going to focus on solving any of the problems that happen with fallback to TCP. Clearly we are not going to go and brak whatever fallback WebTransport does, but they key thing is this work when then WebTransport is over QUIC, not other cases
I completely agree. This is an editorial point that there are times when 'QUIC' is used when it may not actually be QUIC. In many cases, just removing that word makes the sentence both slightly more accurate and shorter.