jiebi/CodeConvo huggingface dataset:
Code change:
designed congestion control algorithms have the opportunity to improve the state of the art. <del> 3.1.3. </del> <ins> 3.1.4. </ins> When multiple competing flows all using the same alternate congestion control algorithm, the proposal should explore how the capacity is shared among the competing flows. <del> 3.1.4. </del> <ins> 3.1.5. </ins> (TODO: Discuss short and long flows)

Related discussion:
text: Define congestion collapse in terms of excess overhead. Rename the prior congestion collapse section "Implement full backoff" Closes issue
Editors: This metric is very interesting, but wonder if it's really a requirement for loss recovery, not congestion control (granted, these two are often intertwined). This would put it out of scope. Our proposal would be to revert this, though perhaps we are misunderstanding the intent.
Define congestion collapse in terms of excess overhead under adverse conditions. This is how it was defined circa 1987. Rename the current "congestion collapse" section.
NAME would you like to take a crack at finding some text that would be in scope to address the intent behind this issue?
Closing this issue, as it's through IETF Last Call.
Code change:
the sequence CRLF, a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR. <ins> A sender MUST NOT generate a bare CR (a CR character not immediately followed by LF) within any protocol elements other than the payload body.  A recipient of such a bare CR MUST consider that element to be invalid or replace each bare CR with SP before processing the element or forwarding the message. </ins> Older HTTP/1.0 user agent implementations might send an extra CRLF after a POST request as a workaround for some early server applications that failed to read message body content that was not

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:
the sequence CRLF, a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR. <ins> A sender MUST NOT generate a bare CR (a CR character not immediately followed by LF) within any protocol elements other than the payload body.  A recipient of such a bare CR MUST consider that element to be invalid or replace each bare CR with SP before processing the element or forwarding the message. </ins> Older HTTP/1.0 user agent implementations might send an extra CRLF after a POST request as a workaround for some early server applications that failed to read message body content that was not

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:
the sequence CRLF, a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR. <ins> A sender MUST NOT generate a bare CR (a CR character not immediately followed by LF) within any protocol elements other than the payload body.  A recipient of such a bare CR MUST consider that element to be invalid or replace each bare CR with SP before processing the element or forwarding the message. </ins> Older HTTP/1.0 user agent implementations might send an extra CRLF after a POST request as a workaround for some early server applications that failed to read message body content that was not

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:
the sequence CRLF, a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR. <ins> A sender MUST NOT generate a bare CR (a CR character not immediately followed by LF) within any protocol elements other than the payload body.  A recipient of such a bare CR MUST consider that element to be invalid or replace each bare CR with SP before processing the element or forwarding the message. </ins> Older HTTP/1.0 user agent implementations might send an extra CRLF after a POST request as a workaround for some early server applications that failed to read message body content that was not

Related discussion:
text: changes to -messaging pulled from URL
I'll go ahead with this one as we already reached consensus in the original PR.
Code change:
indicates that proxy.example.net, which used the IP address "2001:db8::1" as the next hop for this request, encountered the <del> CNAMEs "tracker.example.com." and "service1.example-cdn.com" in the </del> <ins> CNAMEs "tracker.example.com" and "service1.example-cdn.com" in the </ins> DNS resolution chain.  Note that while this example includes both the "next-hop" and "next-hop-aliases" parameters, "next-hop-aliases" can be included without including "next-hop".

Related discussion:
text: The draft currently has this example: I'd suggest always omitting trailing dots since it's clear that these names will be FQDNs, i.e.:
Code change:
mechanisms that would give flows with different round- trip times comparable capacity during backoff. <del> 3.1.2. </del> <ins> 3.1.3. </ins> The alternate congestion control mechanism should reduce its sending rate if the round trip time (RTT) significantly increases.  Exactly

Related discussion:
text: Define congestion collapse in terms of excess overhead. Rename the prior congestion collapse section "Implement full backoff" Closes issue
Editors: This metric is very interesting, but wonder if it's really a requirement for loss recovery, not congestion control (granted, these two are often intertwined). This would put it out of scope. Our proposal would be to revert this, though perhaps we are misunderstanding the intent.
Define congestion collapse in terms of excess overhead under adverse conditions. This is how it was defined circa 1987. Rename the current "congestion collapse" section.
NAME would you like to take a crack at finding some text that would be in scope to address the intent behind this issue?
Closing this issue, as it's through IETF Last Call.
Code change:
SCITT provides the following security guarantees: Statements made by Issuers about supply chain Artifacts are <del> identifiable, authentic, and non-repudiable </del> <ins> identifiable, can be authenticated, and once authenticated, are non-repudiable </ins> Statement provenance and history can be independently and consistently audited

Related discussion:
text: Hi all, This PR comes from a place that agrees: If using an identity scheme, then yes, it must be used in maner consistent with that scheme, But aslo that There is no identity scheme we could all agree on as universally applicable or agreable, further, the space continues to evolve. And, The trustworthiness or otherwise of issuers identity, in the context of a transparency ledger, is temporal and subjective in nature. It's just a question of time frame. This means that regardless of registration time checks, relying parties, auditors and general consumers will have to re evaluate regardless. And will do so according to their own subjective context. Remembering that "It can never be assumed that some Issuers and some Transparency Services will not be corrupt.". And also "A Verifier SHOULD validate a Transparent Statement originating from a given Issuer" ... "and would not depend on any other Issuer or Transparency Services." It does seem obvious that, Syntactic validation of the issuer identity claims makes good sense and supports interoperability. But, Specifying a single identity scheme in the core architecture as "minimally required" does not meaningfully help interoperability when there is no single agreeable scheme, and especially when a TS may be used to underpin identity schemes themselves. Regarding the burden on Relying Parties and Auditors, The definition for "Relying Party" states "a Relying Parties consumes Transparent Statements, verifying their proofs and inspecting the Statement payload, either before using corresponding Artifacts, or later to audit an Artifact's provenance on the supply chain". IOW: Relying parties are already expected to deeply consider statements. Assessing the identity asserted by the issuer, at the time the artifact is being considered, seems to be a natural and useful part of that process. Registration Auditability: Requiring that Transparency Services "enough information is made available to Auditors" ... "to authenticate and retrieve the Transparent Statements" is essentially impossible to specify at this level, imposes un-bounded maintenance and storage issues on implementations, and represents a significant layering violation in the architecture.
Editors meeting: will wait 24hours for reviews, with merger if no objections.
Per the editors meeting, I've merged the discussed changes and resolved the discussed topics. I've opened to track the MUST/Should discussion, which wasn't part of this PR.
Code change:
SCITT provides the following security guarantees: Statements made by Issuers about supply chain Artifacts are <del> identifiable, authentic, and non-repudiable </del> <ins> identifiable, can be authenticated, and once authenticated, are non-repudiable </ins> Statement provenance and history can be independently and consistently audited

Related discussion:
text: Please review and we'll merge Wednesday morning US Pacific time if there are no objections. I'll incorporate agreed suggestions as well.
Merging with no other feedback.
good enough By and large the document is at a point where it can be called on for final reading. There are some nits or issues that we would like to see done to tighten it up. The introduction discusses distributed, but there is no real discussion of how or what that means and it leads readers to set an expectation that is incorrect. This word should be deleted. Removal of the Feeds definition. This was in the original version, and we have bounced all over the place during the last year to formulate a solution to a problem with Federation. We have decided collectively to park that and thus the use of feeds is gone. In a future overarching product or charter it could come back. There is a bit of a misunderstanding generated by stating that receipts don't expire, which later on is a line that requests for a refreshed receipt can be supported. The logical receipt is intended to never expire and based on the protected content in the ledger's log a new receipt can be generated at any time. This gives us an avenue to bridge a world from today to post quantum cryptography based counter signatures that is important. We need to clear up these two points. What goes into the append only log can vary from implementation to implementation. It may be that one implementation records the hash of the signed statement, plus evidence of how we proved that it was valid at the time of acceptance (things like records of OCSP response, or CRL lookups). Another implementation may simply store the signed statement. This from a generic point of view means that given access to the signed statements you can prove that it is on the append only log always. In section 4.1.1.2 it alludes that an auditor can mine the log to authenticate and retrieve the transparent statement. Based on the last statement this has two problems. The first it assumes that the signed statement is kept and that it can generate a new receipt (see 3) and produce a transparent statement. If it could this would be equivalent to the original in intent but not binary equal. The original receipt (or last created receipt from a refresh) is not required (or intended) to be kept in the ledger.
Code change:
SCITT provides the following security guarantees: Statements made by Issuers about supply chain Artifacts are <del> identifiable, authentic, and non-repudiable </del> <ins> identifiable, can be authenticated, and once authenticated, are non-repudiable </ins> Statement provenance and history can be independently and consistently audited

Related discussion:
text: Generically then this is impossible and may be where we would leverage consistency proofs in a later version.By and large the generic aspect of the document is there but we missed one sentence: "Signed Statements and Artifacts associated with a software package." We would suggest removing the "software package".
Code change:
flag is set. An 8-bit weight for the identified priority group, see <del> StreamPriority.  This field is optional and is only present if the </del> <ins> StreamPriority.  Add one to the value to obtain a weight between 1 and 256.  This field is optional and is only present if the </ins> PRIORITY_GROUP flag is set. A single bit flag indicates that the stream dependency is

Related discussion:
text: This wording once existed in priority branch in github, but missing in the current draft.
Code change:
authorization server MUST reject JWTs with an invalid signature. The public key used to verify the JWT MUST be the key located in <del> the "cnf" claim of the corresponding client key attestation JWT. </del> <ins> the "cnf" claim of the corresponding client attestation JWT. </ins> The authorization server MUST reject a JWT that is not valid in all other respects per "JSON Web Token (JWT)" RFC7519.

Related discussion:
text: Please change file/draft name and title, too.
Opened as a separate issue.
NAME please check my latest suggestion
I would like to see the description under the sequence diagram improved, but if you want to address that in another PR, that is fine too.
Code change:
must contain information about key material controlled by the holder: Note: How the public key is included in SD-JWT is out of scope of <del> this document.  It can be passed by value or by reference.  Examples in this document use Claim to include raw public key by value in SD-JWT. </del> <ins> this document.  It can be passed by value or by reference. </ins> With holder binding, the

Related discussion:
text: addresses Issue
NAME considering the last OOP refactor on the python code and the revision of Brian probably it would be easier to close this PR and starting a new one on top of the current master branch, the changes in the code and in the text are very trivial
NAME ok, please do a PR directly to this branch :)
Code change:
must contain information about key material controlled by the holder: Note: How the public key is included in SD-JWT is out of scope of <del> this document.  It can be passed by value or by reference.  Examples in this document use Claim to include raw public key by value in SD-JWT. </del> <ins> this document.  It can be passed by value or by reference. </ins> With holder binding, the

Related discussion:
text: Spec text updated, please review!
George during OAuth side mtg pointed out that it is important for the verifier not to change anything in the JSON object in the Release (ie SVC )that is being hashed so that the hash output is the same from the one in SD-JWT
Code change:
In contrast to the prioritization scheme of HTTP/2 that uses a hop- by-hop frame, the Priority header field is defined as end-to-end. <del> The rationale is that the Priority header field transmits how each response affects the client's processing of those responses, rather than how relatively urgent each response is to others.  The way a client processes a response is a property associated to that client generating that request.  Not that of an intermediary.  Therefore, it is an end-to-end property.  How these end-to-end properties carried by the Priority header field affect the prioritization between the responses that share a connection is a hop-by-hop issue. </del> <ins> The way that a client processes a response is a property associated with the client generating that request.  Not that of an intermediary.  Therefore, it is an end-to-end property.  How these end-to-end properties carried by the Priority header field affect the prioritization between the responses that share a connection is a hop-by-hop issue. </ins> Having the Priority header field defined as end-to-end is important for caching intermediaries.  Such intermediaries can cache the value

Related discussion:
text: Addresses Eb, Ec, Ed of This cuts some text to reduce the waffle factor ;)
This is nice condensation.
Code change:
The ORIGIN Extension in HTTP/3 <del> draft-ietf-httpbis-origin-h3-latest </del> Abstract <del> The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but </del> <ins> The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but it </ins> needs to be separately registered.  This document describes the ORIGIN frame for HTTP/3. 1. <del> Existing RFCs define extensions to HTTP/2 HTTP2 which remain useful in HTTP/3.  HTTP3 describes the required updates for HTTP/2 frames to be used with HTTP/3. </del> <ins> Existing RFCs define extensions to HTTP/2 RFC9113 that remain useful in HTTP/3.  RFC9114 describes the required updates for HTTP/2 frames to be used with HTTP/3. </ins> ORIGIN defines the HTTP/2 ORIGIN frame, which indicates what origins are available on a given connection.  It defines a single HTTP/2

Related discussion:
text: This PR tracks changes under discussion with the RFC editor. (Note that I haven't renamed the file to the RFC number, because that hasn't been done in other drafts in this repo.) When AUTH48 completes, I will add the commit moving this draft to the archive and merge it.
Code change:
the server. An origin can use the Priority response header field to indicate its <del> view on how an HTTP response should be prioritized.  When forwarding an HTTP response with the Priority response header field, an intermediary can use the parameters being found in that response instead of those found in the request. </del> <ins> view on how an HTTP response should be prioritized.  An intermediary that forwards an HTTP response can use the parameters found in the Priority response header field, in combination with the client Priority request header field, as input to its prioritization process.  No guidance is provided for merging priorities, this is left as an implementation decision. </ins> Absence of a priority parameter in an HTTP response indicates the server's disinterest in changing the client-provided value.  This is

Related discussion:
text: We still had usage of the term override, so while thinking how to address that I took the opportunity to state explicitly that no guidance is provided for how an intermediary might merge.
LGTM!
Code change:
7.1.2. <ins> As there is no content coding applied, the "id-sha" and the "id-sha- 256" digest-values are the same. </ins> 7.1.3. 7.1.4.

Related discussion:
text: Adds id-sha-* algorithm examples throughout the document.
draft-ietf-httpbis-digest-headers includes examples of sha-256 in the Digest header value, but no examples of the two new algorithms it introduces: id-sha-256 and id-sha-512. Examples would be extremely useful to illustrate the difference between sha-256 and id-sha-256.
That sounds reasonable to me.
NAME WDYT?