jiebi/CodeConvo huggingface dataset:
Code change:
these: Note that double-quote delimiters are almost always used with the <del> quoted-string production; using a different syntax inside double- quotes will likely cause unnecessary confusion. </del> <ins> quoted-string production (quoted.strings); using a different syntax inside double-quotes will likely cause unnecessary confusion. </ins> Many fields (such as

Related discussion:
text: Edit: opened URL
On the other hand, people complain about the spec being too long already. I don't think we should add examples unless they are needed to make things easier to understand.
Ok! (As I said, these are so minor that they are definitely up to you. Same with references and terminology comments)
I believe the simplest possible fix would be to remove "to be used in references", making this: NAME ? Edit: -> URL
I think that we should probably convert this one (and similar) to MUST NOT -- there isn't any situation where we recommend this behaviour, as it has interoperability and security implications.
Not convinced at all. The "SHOULD NOT" requirement is new and was controversial already. There is code out there using GET with body (in controlled environments) which just works.
That's not HTTP; that's a private protocol.
Tell that Google :-) Anyway. This is a normative requierement and we are past WG LC. If you want to change it, this absolutely needs to be confirmed explicitly by the WG (and would deserve a seaparate issue).
Maybe "The process for determining whether access is granted is defined..."? Edit: -> URL
You mean generally, for the fields we define? I don't think that's true; they're defined for the semantics they specify. If a use isn't specified, it might be extended in the future, so we rarely prohibit such a use. Saying that they can be used with any method or status code would imply that they have meaning in each circumstance, and that's often not true.
authentication. This isn't important for interoperability, it's just a bad idea. Maybe 'The From header field is not intended or suitable for use as a means of access control or authentication.'?
FWIW, the requirement is from RFC 7231, and widely accepted (I guess), so I don't think we should change it.
For 4, proposed rewrite:
WRT -- I don't think I'd use the word "widely" in conjunction with this header field. Again, if we use SHOULD NOT, we should explain the qualification.
In the sense that it's an interoperability requirement on a sender (not a recipient), I agree.
"MUST NOT be generated" maybe?
MUST NOT be generated, because recipient behaviour is not interoperable.
Code change:
these: Note that double-quote delimiters are almost always used with the <del> quoted-string production; using a different syntax inside double- quotes will likely cause unnecessary confusion. </del> <ins> quoted-string production (quoted.strings); using a different syntax inside double-quotes will likely cause unnecessary confusion. </ins> Many fields (such as

Related discussion:
text: URL already say "MUST NOT generate ABNF-invalid messages" in general. So maybe we don't want to repeat BCP14 terms here... -> URL
I've reviewed the most recent commits, think this can be closed now.
Thanks for addressing my comments. I checked the commits and your answers: I can see everything was addressed, either by changes or by answers clarifying what I found confusing, except for: the one which is now issue point 14: giving context around the "SHOULD NOT" for the 'From' header field. Note that I am not asking you to make any change (such as removing the BCP 14 text), but following what BCP 14 defines: it seems important that the reader understands, or at least gets a hint of what these reasons and particular circumstances are, in order to be able to understand the full implications. This is why I think it's important to clarify the context around the SHOULD / SHOULD NOT, and was also my comment for the GET requirement, but I see that that comment has now transformed in a bigger issue the wg needs to find consensus on.
I disagree. You are presuming that we know those particular circumstances, and that is almost always false when SHOULD is being used. When we have a detailed list of conditions, we use "MUST NOT unless ...". The SHOULD is literally saying that the reader needs to take care and understand the risk/benefit for their own context, not that we need to explain to them based on our own imagination. It is fine to suggest additional text to address a specific concern, but I personally think that this one is self-explanatory. If we added a general description about why auth parameters shouldn't be sent in fields that are not expected to be treated as auth parameters by every recipient, such as within a security consideration, then we could reference it here.
I don't think we should know all possible circumstances, but I presume we do have an inkling that implementations going against the RECOMMENDations exist, for whatever reason, right? As a reader, putting myself in a new implementer shoes, I personally would have found it useful to get that hint of what to consider, but if you think that this one is self-explanatory, I won't insist.
Code change:
these: Note that double-quote delimiters are almost always used with the <del> quoted-string production; using a different syntax inside double- quotes will likely cause unnecessary confusion. </del> <ins> quoted-string production (quoted.strings); using a different syntax inside double-quotes will likely cause unnecessary confusion. </ins> Many fields (such as

Related discussion:
text: The type of sentence I was thinking about would be something like: (Just trying to explain myself here, again, feel free not to take this suggestion if you and the wg don't think it helps the reader)
Okay, I have added URL because I think we should explain it if it isn't obvious to others.
Thank you NAME !
Code change:
2. There are two different modes of composing COSE protection and <del> timestamping. </del> <ins> timestamping, motivated by the usage scenarios discussed above. </ins> 2.1.

Related discussion:
text: In , Orie commented that: "Some use cases for the 2 modes might improve the document."_ E.g., C2PA, SCITT, PDF timestamping.
Add a paragraph to the Introduction to explain the use cases.
given enough guidance you can pass as an artist ;) Authors might consider providing some guidance regarding validation of CTT where the COSE claims appear (iat, nbf) to have happened after the timestamp ( time travel ). IIRC cose counter signatures apply to the protected header, payload and signature, whereas CTT only applies to the signatures. This means that the TSA does not countersign any protected information in the header? Some use cases for the 2 modes might improve the document. Security considerations seem light. OS >
Code change:
source code and issues list for this draft can be found at <https://github.com/httpwg/http-core>. <del> The changes in this draft are summarized in changes.since.07. </del> <ins> The changes in this draft are summarized in changes.since.08. </ins> 1.

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:
source code and issues list for this draft can be found at <https://github.com/httpwg/http-core>. <del> The changes in this draft are summarized in changes.since.07. </del> <ins> The changes in this draft are summarized in changes.since.08. </ins> 1.

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:
source code and issues list for this draft can be found at <https://github.com/httpwg/http-core>. <del> The changes in this draft are summarized in changes.since.07. </del> <ins> The changes in this draft are summarized in changes.since.08. </ins> 1.

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:
with a set of trust anchors. In general, a client MUST verify the service identity using the <del> verification process defined in RFC6125 (for a reference identifier of type URI-ID) unless the client has been specifically configured to accept some other form of verification.  For example, a client might be connecting to a server whose address and hostname are dynamic, with an expectation that the service will present a specific certificate (or a certificate matching some externally defined reference identity) rather than one matching the dynamic URI's origin server identifier. </del> <ins> verification process defined in RFC6125.  The client MUST construct a reference identity from the service's host: if the host is a literal IP address (https.ip-id), the reference identity is an IP-ID, otherwise the host is a name and the reference identity is a DNS-ID. A reference identity of type CN-ID MUST NOT be used by clients.  As noted in RFC6125 a reference identity of type CN-ID might be used by older clients. A client might be specially configured to accept an alternative form of server identity verification.  For example, a client might be connecting to a server whose address and hostname are dynamic, with an expectation that the service will present a specific certificate (or a certificate matching some externally defined reference identity) rather than one matching the dynamic URI's origin server identifier. </ins> In special cases, it might be appropriate for a client to simply ignore the server's identity, but it must be understood that this

Related discussion:
text: If not, then I think we say DNS-ID and MAY consider CN-ID, plus the wildcard language. I'm not aware of anything to reference for IPADDR-ID, and this doesn't seem like the place to define it.
Please don't use CN for anything. Nor rfc822Address nor domainComponent.
I'll be happy to accept any change here that folks generally agree to, preferably in the form of a PR. I already tried just writing it myself and that's what we have now, but it's wrong because I haven't implemented this myself.
Sorry for the late comment; apparently my github notifications aren't set to send me email when a new PR references an issue I'm watching.I'll trust NAME :-)
Code change:
HTTP clients can be configured to use proxies by selecting a proxy hostname, a port, and whether to use a security protocol.  However, <del> CONNECT requests using the proxy do not carry this configuration information.  Instead, they only indicate the hostname and port of the target.  This prevents any HTTP server from hosting multiple distinct proxy services, as the server cannot distinguish them by path (as with distinct resources) or by origin (as in "virtual hosting"). </del> <ins> Classic HTTP CONNECT requests using the proxy do not carry this configuration information.  Instead, they only indicate the hostname and port of the target.  This prevents any HTTP server from hosting multiple distinct proxy services, as the server cannot distinguish them by path (as with distinct resources) or by origin (as in "virtual hosting"). </ins> The absence of an explicit origin for the proxy also rules out the usual defenses against server port misdirection attacks (see RFC9110)

Related discussion:
text: It seems fine for connect-udp and connect-tcp because the variables are mandatory, so it would provide value to UDP+TCP clients (which seem likely to be common).
In that case we should state somewhere that passing around an URI template with these variables implies support for the corresponding mechanism. I'm not sure we'd get consensus on that though.
Thanks for the updates based on the discussion at 119
Code change:
Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field.  The usual mechanism for folding HTTP headers <del> fields (i.e., as defined in RFC2616) might change the semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such folding. </del> <ins> fields (i.e., as defined in Section 3.2.2 of RFC7230) might change the semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such folding. </ins> 3.1.

Related discussion:
text: I left the term "request-uri" untouched (it was renamed in the base spec because it's not always a URI). We may want to change that separately, or even refer to the effective request URI (URL)
NAME - ping?
LGTM, thank you for the patch, and for the ping!
Code change:
Implementations ought to note that the full chain of names might not be available in common DNS resolution APIs, such as "getaddrinfo". <del> "getaddrinfo" does have an option for "AI_CANONNAME", but this will only return the last name in the chain (the canonical name), not the alias names. </del> <ins> "getaddrinfo" does have an option for "AI_CANONNAME" (Section 6.1 of RFC3493), but this will only return the last name in the chain (the canonical name), not the alias names. </ins> An implementation MAY include incomplete information in the "next- hop-aliases" parameter to accommodate cases where it is unable to

Related discussion:
text: CC NAME comment syntax: URL "Handling Ballot Positions": URL Why is the value defined as a String that can be comma-separated as opposed to a List (of Strings)? Up to you, but feel free to reference RFC 3493 section 6.1 for getaddrinfo and discussion of the AI_CANONNAME flag. "might not available" -> "might not be available"
The nit was fixed with
For the list-of-strings, parameters themselves can only contain bare items, not inner lists. URL
Code change:
The payload of a PRIORITY frame contains a single reserved bit and a 31-bit priority. <ins> The PRIORITY frame does not define any type-specific flags. </ins> The PRIORITY frame is associated with an existing stream.  If a PRIORITY frame is received with a stream identifier of 0x0, the recipient MUST respond with a ConnectionErrorHandler of type

Related discussion:
text: All other frame descriptions specify explicitly if the frame type does not have any type-specific flags. The PRIORITY frame description should do the same if there are no flags.
Code change:
referenced in the credential.  This process is further described in I-D.ietf-oauth-selective-disclosure-jwt. <del> To support revocation of Verifiable Credentials, an optional fourth party can be involved, a Status Provider, who delivers revocation information to Verifiers.  (The Verifier can also serve as the Status Provider.) </del> <ins> To support revocation of Verifiable Credentials, revocation information can optionally be retrieved from a Status Provider.  The role of a Status Provider can be fulfilled by either a fourth party or by the Issuer. </ins> This specification defines Verifiable Credentials based on the SD-JWT format with a JWT Claim Set.

Related discussion:
text: Status Provider should be either 4th party or issuer (not verifier).
Merging this since multiple approvals.
lgtm, thank you!
Code change:
to concretely understand and investigate the wealth of proposals in this space. <ins> This document is meant to reduce the barriers to entry for new congestion control work.  As such, proponents should not interpret these criteria as a checklist of requirements before approaching the IETF.  Instead, proponents are encouraged to think about these issues beforehand, and have the willingness to do the work implied by the rest of this document. </ins> 2. Following the lead of HighSpeed TCP RFC3649, alternate congestion

Related discussion:
text: Editors: just focus on what needs to be evaluated (the last sentence) and toss the rest. We are not going to satisfy anyone with a discussion of the bigger picture.
In the Internet, most connections never exit Slow-Start. RFC 5033 kind of explicitly focuses on the long duration connections, because at the time of writing the accepted rule was that the 10% long duration connections were were causing 90% of traffic. I don't know whether that's still true.
With the usage of QUIC, more short-lived connections are aggregated into a long connection.
Looks OKThanks for updating this.
Code change:
to concretely understand and investigate the wealth of proposals in this space. <ins> This document is meant to reduce the barriers to entry for new congestion control work.  As such, proponents should not interpret these criteria as a checklist of requirements before approaching the IETF.  Instead, proponents are encouraged to think about these issues beforehand, and have the willingness to do the work implied by the rest of this document. </ins> 2. Following the lead of HighSpeed TCP RFC3649, alternate congestion

Related discussion:
text: Add some text to indicate that proponents don't need a complete report on all the criteria before coming to IETF. They can arrive having thought about these problems a little and have a willingness to do the work implied in this draft.
We need to be nice, but not too nice. This phrase is targeting folks like researchers or PhD candidates. They should be aware that this topic is not going to be a walk in the park. But showing why the problem is hard could also be an encouragement -- you don't get a PhD for solving again a problem that 100s have already solved...