jiebi/CodeConvo huggingface dataset:
Code change:
9.2. <del> The CRIME attack shows that it's a bad idea to compress data from mixed (e.g. public and private) sources - the data sources include not only the compressed data but also the dictionaries.  For example, if you compress secret cookies using a public-data-only dictionary, you still leak information about the cookies. </del> <ins> The compression attacks in RFC7457 show that it's a bad idea to compress data from mixed (e.g. public and private) sources - the data sources include not only the compressed data but also the dictionaries.  For example, if you compress secret cookies using a public-data-only dictionary, you still leak information about the cookies. </ins> Not only can the dictionary reveal information about the compressed data, but vice versa, data compressed with the dictionary can reveal

Related discussion:
text: This addresses the reference issues, comments and nits from the AD review (see )
NAME would you mind taking a quick look before I publish a new draft?
(tried using ietf-comments but ran into issues so just tracking manually in one combined issue)... cc NAME Thank you for the work on this document. Almost all my comments are about references. I think a new version is necessary before starting IETF Last Call, to avoid process issues along the way. Francesca The boilerplate is duplicate, please remove the second occurrence. Can you please update the reference to 8941 to draft-ietf-httpbis-sfbis ? That doc is with the RFC Editor so should not be holding this document up. Also, I believe the reference to draft-ietf-httpbis-sfbis should be normative, not informative, since terminology from that doc is used. Alternatively, if you want to keep the ref informative, you can import the part of the terminology that is necessary for this doc. I think that's a uglier solution, so I highly prefer sfbis to be made normative, but won't block on it. [URLPattern] "URL Pattern Standard", March 2024, URL needs to be indicated as Living standard (see RFC 9110 or 9421 for eample of whatwg specs references). Please fix this so that the Fetch spec is properly referenced (normatively is needed, I believe). RFC 8792 should be (informatively) referenced. I agree with Mark's write up, 5861 should really be informative. There is several occurrences of {Origin}, please fix. Please add a reference. It would be good to have an informative reference to 6265 (or even 6265bis). This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [ tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: URL [ICT]: URL
Code change:
deployment in the Internet. This document updates the similarly titled RFC5033 that was published <del> in 2007.  Since then, multiple congestion control algorithms were developed outside of the IETF, including at least two that saw large scale deployment: Cubic HRX08 and BBR BBR-draft. </del> <ins> in 2007 as a Best Current Practice to evaluate new congestion control algorithms as Experimental or Proposed Standard RFCs. In 2007, TCP was the dominant consumer of this work, and proposals were typically discussed in research groups, for example the Internet Congestion Control Research Group (ICCRG). Since RFC 5033 was published, many conditions have changed.  The set of protocols using these algorithms has spread beyond TCP and SCTP to include DCCP, QUIC, and beyond.  Some congestion control algorithm proponents now have the opportunity to test and deploy at scale without IETF review.  There is more interest in specialized use cases such as data centers and real-time protocols.  Finally, the community has gained much more experience with indications of congestion beyond packet loss. Multiple congestion control algorithms have been developed outside of the IETF, including at least two that saw large scale deployment: Cubic HRX08 and BBR BBR-draft. </ins> Cubic was documented in a research publication in 2007 HRX08, and then adopted as the default congestion control algorithm for the TCP

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:
deployment in the Internet. This document updates the similarly titled RFC5033 that was published <del> in 2007.  Since then, multiple congestion control algorithms were developed outside of the IETF, including at least two that saw large scale deployment: Cubic HRX08 and BBR BBR-draft. </del> <ins> in 2007 as a Best Current Practice to evaluate new congestion control algorithms as Experimental or Proposed Standard RFCs. In 2007, TCP was the dominant consumer of this work, and proposals were typically discussed in research groups, for example the Internet Congestion Control Research Group (ICCRG). Since RFC 5033 was published, many conditions have changed.  The set of protocols using these algorithms has spread beyond TCP and SCTP to include DCCP, QUIC, and beyond.  Some congestion control algorithm proponents now have the opportunity to test and deploy at scale without IETF review.  There is more interest in specialized use cases such as data centers and real-time protocols.  Finally, the community has gained much more experience with indications of congestion beyond packet loss. Multiple congestion control algorithms have been developed outside of the IETF, including at least two that saw large scale deployment: Cubic HRX08 and BBR BBR-draft. </ins> Cubic was documented in a research publication in 2007 HRX08, and then adopted as the default congestion control algorithm for the TCP

Related discussion:
text: This takes the initial part of that charter and adds to the introduction as a starting point for the new document.
Let's add text to the Introduction with our motivation and intention for revising RFC 5033, i.e., why and what do we want to update. The goal is to improve our alignment early on. This text could draw from the CCWG charter and prior discussions.
Code change:
consumes server resources. Furthermore, using multiple connections can cause undesirable side <del> effects in congested networks.  Using larger number of multiple connections can also cause side effects in otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used. </del> <ins> effects in congested networks.  Using larger numbers of connections can also cause side effects in otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used. </ins> Note that a server might reject traffic that it deems abusive or characteristic of a denial-of-service attack, such as an excessive

Related discussion:
text: Regardless, though, it seems like the text of the guidance as written (not quoted above) reads like it is setting us up for vulnerabilities in the presence of non-compliant (or HTTP/1.0?) implementations in the request chain. We might want to put in a bit more explanation of how the stated procedure avoids the vulnerability. Editors: [x] Section 3.2 400 (Bad Request) error or a 301 (Moved Permanently) redirect with the request-target properly encoded. [...] (I assume 301 rather than 308 was an intentional choice for maximum compatibility with old/broken clients.) Editors: This requirement existed long before 308 was minted. In any case, 301 would be preferred since we don't want to assume too much about why a non-GET request method is being used with an invalid request-line (usually meaning that the client failed to encode spaces in the hypertext reference). [x] Section 3.3 secured connection is inherently unsafe if there is any chance that the user agent's intended authority might differ from the selected default. A server that can uniquely identify an authority from the request context MAY use that identity as a default without this risk. Is the contents of the TLS SNI extension sufficient request context to uniquely identify an intended authority? Editors: Maybe. Using a certificate that is specific to that authority (one that can't be shared by multiple origins and thus was definitely chosen by the client) would be sufficient. We don't need to define this further. [x] Section 5.1 does not include any leading or trailing whitespace: OWS occurring before the first non-whitespace octet of the field line value or after the last non-whitespace octet of the field line value ought to be excluded by parsers when extracting the field line value from a field line. I have in general tried to refrain from commenting on the extensive use of the phrase "ought to" in this group of documents, but this particular scenario seems like a strong candidate for a BCP 14 keyword. Editors: [x] Section 9.8 closure alert is received, an implementation can be assured that no further data will be received on that connection. TLS implementations MUST initiate an exchange of closure alerts before closing a connection.
Code change:
consumes server resources. Furthermore, using multiple connections can cause undesirable side <del> effects in congested networks.  Using larger number of multiple connections can also cause side effects in otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used. </del> <ins> effects in congested networks.  Using larger numbers of connections can also cause side effects in otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used. </ins> Note that a server might reject traffic that it deems abusive or characteristic of a denial-of-service attack, such as an excessive

Related discussion:
text: A TLS implementation MAY, after sending a closure alert, close the connection without waiting for the peer to send its closure alert, generating an "incomplete close". [...] This is written as if it's imposing normative requirements on generic TLS implementations (not placing restrictions on what TLS implementations are suitable for HTTPS). Fortunately, these "MUST initiate" and "MAY close without waiting" requirements seem to already be present in RFC 8446... Editors: Rewritten by URL [x] Section 9.8 This SHOULD only be done when the application knows (typically through detecting HTTP message boundaries) that it has sent or received all the message data that it cares about. ...whereas this SHOULD does not have an obvious analogue in RFC 8446, and thus it would make sense to retain the BCP 14 keyword for. Editors: None of that reads well (it was imported from RFC2818). This is better rewritten as a factual statement of when it knows, as committed above. [x] Section 4 interpreted in light of the semantics defined for that status code. See Section 15 of [Semantics] for information about the semantics of status codes, including the classes of status code (indicated by the first digit), the status codes defined by this specification, In some sense it seems that the referenced status codes are defined by [Semantics], not "this specification". I was initially going to propose (in my PR) a change to "defined for", but that seems incorrect and I don't have a better proposal handy. Editors: URL [x] Section 5.2 (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] Since we don't include the obs-fold production as a component of any other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. Editors: I believe this is more than a nit. Opened URL [x] Section 9.2 MUST maintain a list of outstanding requests in the order sent and MUST associate each received response message on that connection to the highest ordered request that has not yet received a final (non- 1xx) response.
Code change:
consumes server resources. Furthermore, using multiple connections can cause undesirable side <del> effects in congested networks.  Using larger number of multiple connections can also cause side effects in otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used. </del> <ins> effects in congested networks.  Using larger numbers of connections can also cause side effects in otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used. </ins> Note that a server might reject traffic that it deems abusive or characteristic of a denial-of-service attack, such as an excessive

Related discussion:
text: "Highest ordered" implies some numerical rank-list of ordering, but we don't seem to clearly indicate whether older or newer requests receive higher numerical indices. It seems simples to just say "oldest" (or "newest", if that was the intent) rather than applying numerical ranking. Editors:
closure alert is received, an implementation can be assured that no further data will be received on that connection. TLS implementations MUST initiate an exchange of closure alerts before closing a connection. A TLS implementation MAY, after sending a closure alert, close the connection without waiting for the peer to send its closure alert, generating an "incomplete close". [...] TLS implementations (not placing restrictions on what TLS implementations are suitable for HTTPS). Fortunately, these "MUST initiate" and "MAY close without waiting" requirements seem to already be present in RFC 8446... I'm not a TLS expert. That said, if this is correct, would be lowercasing the two keywords be sufficient?
URL is for section 9.8
Change for 9.8 LGTM (as what might pass for a TLS expert).
Code change:
consumes server resources. Furthermore, using multiple connections can cause undesirable side <del> effects in congested networks.  Using larger number of multiple connections can also cause side effects in otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used. </del> <ins> effects in congested networks.  Using larger numbers of connections can also cause side effects in otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used. </ins> Note that a server might reject traffic that it deems abusive or characteristic of a denial-of-service attack, such as an excessive

Related discussion:
text: "Highest ordered" implies some numerical rank-list of ordering, but we don't seem to clearly indicate whether older or newer requests receive higher numerical indices. It seems simples to just say "oldest" (or "newest", if that was the intent) rather than applying numerical ranking. Editors:
closure alert is received, an implementation can be assured that no further data will be received on that connection. TLS implementations MUST initiate an exchange of closure alerts before closing a connection. A TLS implementation MAY, after sending a closure alert, close the connection without waiting for the peer to send its closure alert, generating an "incomplete close". [...] TLS implementations (not placing restrictions on what TLS implementations are suitable for HTTPS). Fortunately, these "MUST initiate" and "MAY close without waiting" requirements seem to already be present in RFC 8446... I'm not a TLS expert. That said, if this is correct, would be lowercasing the two keywords be sufficient?
URL is for section 9.8
Change for 9.8 LGTM (as what might pass for a TLS expert).
suggestion
Code change:
parameters, which are a standardized and extensible format of priority information. header-field defines the Priority HTTP header field, a protocol-version-independent and end-to-end priority signal. <del> Clients can use this header to signal priority to servers in order to specify the precedence of HTTP responses.  Similarly, servers behind an intermediary can use it to signal priority to the intermediary. </del> <ins> Clients can send this header field to signal their view of how responses should be prioritized.  Similarly, servers behind an intermediary can use it to signal priority to the intermediary. </ins> After sending a request, a client can change the priority of the response (see reprioritization) using HTTP-version-specific frames defined in h2-update-frame and h3-update-frame.

Related discussion:
text: Replace use of "precedence" that could be confusing with something better. With this PR, there are still two remaining occurrences of "precedence," in , and . I think that those two are fine, as they are surrounded by other text explaining the context. I think it'd be clear to readers that we are using the term to describe difference of importance between multiple responses. FIxes Ea of .
Thank you, this looks good. I agree with your rationale about why we don't need to remove all instances.
Code change:
Note that the protocol for steps 2 and 4 and how the client instance authenticates with the client backend is out of scope of this <del> specification. </del> <ins> specification.  Note also that this specification can be utilized without the client having a backend server at all; in this case, each client instance will perform the functions described as being done by the backend for itself. </ins> This specification defines the format of the Client Attestation that a client instance uses to authenticate in its interactions with an authorization server, which is comprised of two key parts: <del> A Client Attestation JWT- produced by the client backend. </del> <ins> A Client Attestation JWT - typically produced by the client backend. </ins> A Client Attestation Proof of Possession (PoP) - produced by the client instance.

Related discussion:
text: In the Terminology section, the term names and term definitions are run together with no punctuation between them. For example: I suggest emulating the formatting in URL
Code change:
server certificate check MUST be performed as defined in Section 5 and 6 of RFC6125. <ins> The HTTP endpoint SHOULD support the use of Cross-Origin Resource Sharing (CORS) CORS and/or other methods as appropriate to enable Browser-Based clients to access it. </ins> The Relying Party SHOULD send the following Accept-Header to indicate the requested response type:

Related discussion:
text: Rendered version: URL
We should probably add a small section mentioning that should be set to when explaining the endpoint.
Code change:
10.2. <del> Txn-Tokens SHOULD NOT be logged if they contain Personally Identifiable Information (PII).  What constitutes PII depends upon the use case, but in some cases even an email address (which could be a "sub" value) can be protected PII, which should not be logged. </del> <ins> Complete Txn-Tokens must not be logged verbatim.  This is in order to prevent replay of tokens or leakage of PII or other sensitive information via log files.  A hash of the Txn-Token may be logged to allow for correlation with the log files of the Txn-Token Service that records issued tokens.  Alternatively the JWS payload of a Txn- Token may be logged after the signature has been removed.  If the Txn-Token contains PII, then care should be taken in logging the content of the Txn-Token so that the PII does not get logged. </ins> 11.

Related discussion:
text: Is there a reason why you did not use uppercase terms like MUST NOT or SHOULD? Because it's supposed to be informative?
Yes, the section is non-normative.
Currently logging guidance says "Txn-Tokens SHOULD NOT be logged if they contain Personally Identifiable Information (PII)". I have few questions on this one Risks with logging is that token is still valid for few minutes and if logs are rotated to any other central archival storage with access to broader set of people or someone has access to the server with logs, then they can reuse the token. So why not just say MUST not log token? Also how would a service know if incoming token has PII or not. They will have to validate the token, extract claims and then somehow know infer that a claim is PII or not. On similar lines, for PII , can we mention that TTS SHOULD evaluate encrypting or tokenizing PII claims rather than adding them in plaintext. Adding in plaintext is a risk because TTS isn't aware where the token flows.
Txn-Tokens already contain the subject identifier which is enough to be considered PII in some environments. Our own policy states that PII data can be logged, but the logs must be deleted after a few days (max 7) days. We forbid logging of Txn-Tokens in our integrations for security reasons, not just because they could contain PII.
Our implementation in my company, we do follow the same guidance i.e do not log tokens at all, nothing to do with PII. Tokens are pretty much considered as credentials as validating parties leverage the claims for authorizing the request.
Code change:
The presence of an Age header field implies that the response was not generated or validated by the origin server for this request. However, lack of an Age header field does not imply the origin was <del> contacted, since the response might have been received from an HTTP/1.0 cache that does not implement Age. </del> <ins> contacted. </ins> 5.2.

Related discussion:
text: ... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.