jiebi/CodeConvo huggingface dataset:
Code change:
I think this is a matter of taste, so I'm inclined to leave it as is. Could you please update your PRs to make the style consistent and back out these changes?
Consistent with what? There are two suggested forms of references ("Section x of [FOO]" and "[FOO], Section x"). Both have their legitimate uses. What doesn't work for me is using the second form inside a sentence without any delimitation, because it introduces a comma in the sentence structure where it does not be belong.

Related discussion:
text: required. Certificates - Applications using HTTP should specify that TLS <del> certificates are to be checked according to I-D.ietf-httpbis- semantics, Section 4.3.4 when HTTPS is used. </del> <ins> certificates are to be checked according to Section 4.3.4 of I- D.ietf-httpbis-semantics when HTTPS is used. </ins> Applications using HTTP should not statically require HTTP features that are usually negotiated to be supported by clients.  For example,
Code change:
clarifies that you can always ignore you can ignore when using SRI if you validate both, it is nice to provide useful errors
Me neither, but this comes from RFC3230.
Well. This is a standards track doc developed in an IETF WG. If we want to change things, we can.
"There is a chance that a user agent supporting both mechanisms may find one validates successfully while the other fails. This document specifies no requirements or guidance for user agents that experience such cases." This makes it sound almost as if it could be ok to ignore an error on one level if there's no error on the other level. I think the spec should say that a user agent supporting both mechanisms must implement all requirements of both specs, no matter what.
Thanks Julian. I agree and will make a PR to tighten up the language.
NAME should we really specify what a SRI implementor should do? RFC3230 explicitly states that URL and we are not changing this.
That doesn't seem to be producing a list in the actual Internet Draft; see URL - maybe an indentation problem.

Related discussion:
text: validation first because it does not always require a conversion into identity encoding. <del> There is a chance that a user agent supporting both mechanisms may find one validates successfully while the other fails.  This document specifies no requirements or guidance for user agents that experience such cases. </del> <ins> A user agent supporting both mechanisms: - can legitimately ignore "Digest" when using SRI, because digest specifies that "a recipient MAY ignore any or all of the representation-data-digests"; - enforce both "Digest" and SRI: in this case it can be useful to provide enough information to identify whether the mismatch happened at the "Digest" or the SRI level. </ins> 10.
Code change:
content-type / media type header / header field
This should include updating the core spec references; I will update this PR accordingly unless you get to that before me.
See

Related discussion:
text: The SEARCH method is used to initiate a server-side search.  Unlike the HTTP GET method, which requests that a server return a <ins> representation of the resource identified by the target URI (as defined by RFCHTTP), the SEARCH method is used to ask the server to perform a query operation (described by the request payload) over some set of data scoped to the effective request URI.  The payload returned in response to a SEARCH cannot be assumed to be a </ins> representation of the resource identified by the effective request <del> URI (as defined by RFC7230), the SEARCH method is used to ask the server to perform a query operation (described by the request payload) over some set of data scoped to the effective request URI. The payload returned in response to a SEARCH cannot be assumed to be a representation of the resource identified by the effective request </del> URI. The body payload of the request defines the query.  Implementations MAY use a request body of any content type with the SEARCH method; however, for backwards compatibility with existing WebDAV implementations, SEARCH requests that use the text/xml or <del> application/xml content types MUST be processed per the requirements </del> <ins> application/xml media types MUST be processed per the requirements </ins> established by RFC5323. SEARCH requests are both safe and idempotent with regards to the
Code change:
content-type / media type header / header field
This should include updating the core spec references; I will update this PR accordingly unless you get to that before me.
See

Related discussion:
text: indication as to the final disposition of the search operation.  For instance, a successful search that yields no results can be represented by a 204 No Content response.  If the response includes a <del> body payload, the payload is expected to describe the results of the search operation.  In some cases, the server may choose to respond </del> <ins> content, it is expected to describe the results of the search operation.  In some cases, the server may choose to respond </ins> indirectly to the SEARCH request by returning a 3xx Redirection with <del> a Location header specifying an alternate Request URI from which the search results can be retrieved using an HTTP GET request.  Various non-normative examples of successful SEARCH responses are illustrated in examples. </del> <ins> a Location header field specifying an alternate Request URI from which the search results can be retrieved using an HTTP GET request. Various non-normative examples of successful SEARCH responses are illustrated in examples. </ins> The response to a SEARCH request is not cacheable.  It ought to be noted, however, that because SEARCH requests are safe and idempotent,
Code change:
content-type / media type header / header field
This should include updating the core spec references; I will update this PR accordingly unless you get to that before me.
See

Related discussion:
text: The semantics of the SEARCH method change to a "conditional SEARCH" if the request message includes an If-Modified-Since, If-Unmodified- <del> Since, If-Match, If-None-Match, or If-Range header field (RFC7232). </del> <ins> Since, If-Match, If-None-Match, or If-Range header field (RFCHTTP). </ins> A conditional SEARCH requests that the query be performed only under the circumstances described by the conditional header field(s).  It is important to note, however, that such conditions are evaluated
Code change:
content-type / media type header / header field
This should include updating the core spec references; I will update this PR accordingly unless you get to that before me.
See

Related discussion:
text: The "Accept-Search" response header field MAY be used by a server to directly signal support for the SEARCH method while identifying the <del> specific query format Content-Type's that may be used. </del> <ins> specific query format media types that may be used. </ins> <del> The Accept-Search header specifies a comma-separated listing of media types (with optional parameters) as defined by RFC7231. </del> <ins> The Accept-Search header field specifies a comma-separated listing of media types (with optional parameters) as defined by RFCHTTP. </ins> <del> The order of types listed by the Accept-Search header is </del> <ins> The order of types listed by the Accept-Search header field is </ins> insignificant. 4.
Code change:
content-type / media type header / header field
This should include updating the core spec references; I will update this PR accordingly unless you get to that before me.
See

Related discussion:
text: 5. The SEARCH method is subject to the same general security <del> considerations as all HTTP methods as described in RFC7231. </del> <ins> considerations as all HTTP methods as described in RFCHTTP. </ins> 6. IANA is requested to update the registration of the SEARCH method in the permanent registry at <http://www.iana.org/assignments/http- <del> methods> (see RFC7231). </del> <ins> methods> (see RFCHTTP). </ins>
Code change:
This change is done while ignoring the fact that we might want a bigger document reshuffle when bringing in a "content-digest" header. But it helps illustrate how the abstract / intro could be editorialized to address some off-list feedback.
LGTM :)

Related discussion:
text: Abstract <del> This document defines the HTTP Digest and Want-Digest fields, thus allowing client and server to negotiate an integrity checksum of the </del> <ins> This document defines the HTTP Digest and Want-Digest fields, which allows client and server to negotiate an integrity checksum of the </ins> exchanged resource representation data. <del> This document obsoletes RFC 3230.  It replaces the term "instance" with "representation", which makes it consistent with the HTTP Semantic and Context defined in draft-ietf-httpbis-semantics. </del> <ins> This document obsoletes RFC 3230. </ins> Note to Readers
Code change:
[x] 3. It's probably worth mentioning that they're comma-separated in prose. [ ] 3. I'm uncomfortable with relying on examples to specify how this spec works normatively; by their nature, examples are not 'comprehensive.' While this spec shouldn't re-specify HTTP, the header's definition should be clear enough that a reader doesn't have to dig around in the examples and other specs to understand what's going on. [x] 3. Disagreeing plurals in 'an incremental digest-algorithms'. [x] 4. Is Want-Digest a request field, a response field, or both? In either or both cases, what's the scope of the assertion? [x] * 4. A reference to SEMANTICS 12.4.2 is necessary.

Related discussion:
text: resources which uses a checksum that is calculated independently of the content (see Section 6.4 of SEMANTICS).  It uses the representation data (see Section 8.1 of SEMANTICS), that can be fully <del> or partially contained in the content, or not contained at all: </del> <ins> or partially contained in the content, or not contained at all. </ins> This takes into account the effect of the HTTP semantics on the messages; for example, the content can be affected by Range Requests
Code change:
[x] 3. It's probably worth mentioning that they're comma-separated in prose. [ ] 3. I'm uncomfortable with relying on examples to specify how this spec works normatively; by their nature, examples are not 'comprehensive.' While this spec shouldn't re-specify HTTP, the header's definition should be clear enough that a reader doesn't have to dig around in the examples and other specs to understand what's going on. [x] 3. Disagreeing plurals in 'an incremental digest-algorithms'. [x] 4. Is Want-Digest a request field, a response field, or both? In either or both cases, what's the scope of the assertion? [x] * 4. A reference to SEMANTICS 12.4.2 is necessary.

Related discussion:
text: The checksum is computed using one of the digest-algorithms listed in algorithms and then encoded in the associated format. <del> The example below shows the "sha-256" digest-algorithm that uses base64 encoding. </del> 3. The "Digest" field contains a comma-separated list of one or more
Code change:
[x] 5. I think you should come out and say that digest-algorithm values MUST be compared in a case-insensitive fashion. [x] 5. 'The IANA acts a registry' reads oddly; it maintains the registry. Also, saying 'the registry contains the tokens listed below' is misleading; these are initial registrations, which can be modified and added to after the RFC is published. [x] 5. There should not be RFC2219-MUSTs in IANA registry text. [x] This can be addressed by having a requirement similar to "Deprecated digest algorithms MUST NOT be used."
[ ] 5. Also, is the entire checksum value case-insensitive, or just the token identifying the value? NAME the checksum value is defined by the digest-algorithm, which defines its case. [ ] 5- Also, these might be better placed in IANA Considerations. NAME can we just drop any mention of IANA in this section? I like it. [x] * 5. The ability to have a digest algorithm that ignores content-codings is something of a surprise after reading section 2; it needs to be at least mentioned up there. NAME it is stated in the introduction URL . how would you specify it?
lgtm but keen to see mnot's approval too

Related discussion:
text: Digest-algorithm values are used to indicate a specific digest computation. <del> All digest-algorithm values are case-insensitive but lower case is preferred. </del> <ins> All digest-algorithm token values are case-insensitive but lower case is preferred; digest-algorithm token values MUST be compared in a case-insensitive fashion. </ins> <del> The Internet Assigned Numbers Authority (IANA) acts as a registry for digest-algorithm values.  The registry contains the tokens listed below. </del> <ins> The Internet Assigned Numbers Authority (IANA) maintains a registry for digest-algorithm values.  The registry is initialized with the tokens listed below. </ins> <del> Some digest-algorithms, although registered, rely on vulnerable algorithms and MUST not be used: </del> <ins> Deprecated digest algorithms MUST NOT be used: </ins> "md5", see CMU-836068 and NO-MD5;
Code change:
[x] 5. I think you should come out and say that digest-algorithm values MUST be compared in a case-insensitive fashion. [x] 5. 'The IANA acts a registry' reads oddly; it maintains the registry. Also, saying 'the registry contains the tokens listed below' is misleading; these are initial registrations, which can be modified and added to after the RFC is published. [x] 5. There should not be RFC2219-MUSTs in IANA registry text. [x] This can be addressed by having a requirement similar to "Deprecated digest algorithms MUST NOT be used."
[ ] 5. Also, is the entire checksum value case-insensitive, or just the token identifying the value? NAME the checksum value is defined by the digest-algorithm, which defines its case. [ ] 5- Also, these might be better placed in IANA Considerations. NAME can we just drop any mention of IANA in this section? I like it. [x] * 5. The ability to have a digest algorithm that ignores content-codings is something of a surprise after reading section 2; it needs to be at least mentioned up there. NAME it is stated in the introduction URL . how would you specify it?
lgtm but keen to see mnot's approval too

Related discussion:
text: Description: The MD5 algorithm, as specified in RFC1321.  The output of this algorithm is encoded using the base64 encoding <del> RFC4648.  This digest-algorithm MUST NOT be used as it's now vulnerable to collision attacks.  See NO-MD5 and CMU-836068. </del> <ins> RFC4648.  This digest-algorithm is now vulnerable to collision attacks.  See NO-MD5 and CMU-836068. </ins> Reference: RFC1321, RFC4648, this document.
Code change:
[x] 5. I think you should come out and say that digest-algorithm values MUST be compared in a case-insensitive fashion. [x] 5. 'The IANA acts a registry' reads oddly; it maintains the registry. Also, saying 'the registry contains the tokens listed below' is misleading; these are initial registrations, which can be modified and added to after the RFC is published. [x] 5. There should not be RFC2219-MUSTs in IANA registry text. [x] This can be addressed by having a requirement similar to "Deprecated digest algorithms MUST NOT be used."
[ ] 5. Also, is the entire checksum value case-insensitive, or just the token identifying the value? NAME the checksum value is defined by the digest-algorithm, which defines its case. [ ] 5- Also, these might be better placed in IANA Considerations. NAME can we just drop any mention of IANA in this section? I like it. [x] * 5. The ability to have a digest algorithm that ignores content-codings is something of a surprise after reading section 2; it needs to be at least mentioned up there. NAME it is stated in the introduction URL . how would you specify it?
lgtm but keen to see mnot's approval too

Related discussion:
text: Description: The SHA-1 algorithm RFC3174.  The output of this algorithm is encoded using the base64 encoding RFC4648.  This <del> digest-algorithm MUST NOT be used as it's now vulnerable to collision attacks.  See NO-SHA1 and IACR-2020-014. </del> <ins> digest-algorithm is now vulnerable to collision attacks.  See NO-SHA1 and IACR-2020-014. </ins> Reference: RFC3174, RFC6234, RFC4648, this document.
Code change:
[x] 3. It's probably worth mentioning that they're comma-separated in prose. [x] 3. Disagreeing plurals in 'an incremental digest-algorithms'. [x] 4. Is Want-Digest a request field, a response field, or both? In either or both cases, what's the scope of the assertion? [x] 4. A reference to SEMANTICS 12.4.2 is necessary. See

Related discussion:
text: 3. <del> The "Digest" field contains a list of one or more representation digest values as defined in representation-digest.  It can be used in both requests and responses. </del> <ins> The "Digest" field contains a comma-separated list of one or more representation digest values as defined in representation-digest.  It can be used in both requests and responses. </ins> For example:
Code change:
[x] 3. It's probably worth mentioning that they're comma-separated in prose. [x] 3. Disagreeing plurals in 'an incremental digest-algorithms'. [x] 4. Is Want-Digest a request field, a response field, or both? In either or both cases, what's the scope of the assertion? [x] 4. A reference to SEMANTICS 12.4.2 is necessary. See

Related discussion:
text: algorithm, or even knowing that the recipient will ignore it. "Digest" can be sent in a trailer section.  When an incremental <del> digest-algorithms is used, the sender and the receiver can dynamically compute the digest value while streaming the content. </del> <ins> digest-algorithm is used, the sender and the receiver can dynamically compute the digest value while streaming the content. </ins> 4. The "Want-Digest" field indicates the sender's desire to receive a representation digest on messages associated with the request URI and <del> representation metadata. </del> <ins> representation metadata.  It can be used in both requests and responses. </ins> <del> If a digest-algorithm is not accompanied by a "qvalue", it is treated as if its associated "qvalue" were 1.0. </del> <ins> If a digest-algorithm is not accompanied by a "qvalue" (see Section 12.4.2 ofSEMANTICS), it is treated as if its associated "qvalue" were 1.0. </ins> The sender is willing to accept a digest-algorithm if and only if it is listed in a "Want-Digest" field of a message, and its "qvalue" is
Code change:
moved normative parts in warn that trailers can be dropped by intermediaries.
[x] 12.7. If this is mergeable into headers when it occurs as a trailer, that needs to be said earlier in the spec, not in security considerations. [x] Also, you can't prohibit intermediaries from dropping the trailer; they're explicitly allowed to do so for all trailers.

Related discussion:
text: algorithm, or even knowing that the recipient will ignore it. "Digest" can be sent in a trailer section.  In this case, "Digest" <del> MAY be merged in the header section (See Section 6.5.1 of SEMANTICS). </del> <ins> MAY be merged in to the header section (See Section 6.5.1 of SEMANTICS). </ins> When an incremental digest-algorithm is used, the sender and the receiver can dynamically compute the digest value while streaming the
Code change:
Define deprecation of H2 priority as action, rather than defining it as a concept of "deprecation" then using that term to define the action. Probably resolves the first half of .
Merging this as an improvement, even if might have more to play out.
While I remain annoyed by the polarity of this setting for primarily aesthetic reasons, the PR is fine.

Related discussion:
text: Section 5.4.1) of type PROTOCOL_ERROR. Endpoints MUST send this SETTINGS parameter as part of the first <del> SETTINGS frame.  When the peer receives the first SETTINGS frame, it learns the sender has deprecated the HTTP/2 priority scheme if it receives the SETTINGS_DEPRECATE_HTTP2_PRIORITIES parameter with the value of 1. A sender MUST NOT change the SETTINGS_DEPRECATE_HTTP2_PRIORITIES parameter value after the first SETTINGS frame.  Detection of a change by a receiver MUST be treated as a connection error of type PROTOCOL_ERROR. </del> <ins> SETTINGS frame.  A sender MUST NOT change the SETTINGS_DEPRECATE_HTTP2_PRIORITIES parameter value after the first SETTINGS frame.  Detection of a change by a receiver MUST be treated as a connection error of type PROTOCOL_ERROR. </ins> Until the client receives the SETTINGS frame from the server, the client SHOULD send both the priority signal defined in the HTTP/2 <del> priority scheme and also that of this prioritization scheme.  Once the client learns that the HTTP/2 priority scheme is deprecated, it SHOULD stop sending the HTTP/2 priority signals.  If the client learns that the HTTP/2 priority scheme is not deprecated, it SHOULD stop sending PRIORITY_UPDATE frames (h2-update-frame), but MAY continue sending the Priority header field (header-field), as it is an end-to-end signal that might be useful to nodes behind the server that the client is directly connected to. </del> <ins> priority scheme and also that of this prioritization scheme.  When the client receives the first SETTINGS frame that contains the SETTINGS_DEPRECATE_HTTP2_PRIORITIES parameter with value of 1, it SHOULD stop sending the HTTP/2 priority signals.  If the value was 0 or if the settings parameter was absent, it SHOULD stop sending PRIORITY_UPDATE frames (h2-update-frame), but MAY continue sending the Priority header field (header-field), as it is an end-to-end signal that might be useful to nodes behind the server that the client is directly connected to. </ins> The SETTINGS frame precedes any priority signal sent from a client in HTTP/2, so a server can determine if it should respect the HTTP/2 scheme before building state.  A server that receives <del> SETTINGS_DEPRECATE_HTTP2_PRIORITIES MUST ignore HTTP/2 priority signals. </del> <ins> SETTINGS_DEPRECATE_HTTP2_PRIORITIES with value of 1 MUST ignore HTTP/2 priority signals. </ins> Where both endpoints disable HTTP/2 priorities, the client is expected to send this scheme's priority signal.  Handling of omitted
Code change:
The IANA Cookie Attribute Registry does not exist yet. It is requested that IANA create it. Clarify wording to reflect this. Addresses
The section titled "Cookie Attribute Registry" has a link to the attribute registry maintained by the IANA. This link is broken. Moreso, a cursory look through the IANA site doesn't turn up any similar pages suggesting that this section is obsolete.
The registry does not exist yet. The text about it was added in URL The prose should actually tell IANA that the registry needs to be created, not "updated".
Addressed by

Related discussion:
text: 9.3. <del> The "Cookie Attribute Registry" defines the name space of attribute used to control cookies' behavior.  The registry is maintained at https://www.iana.org/assignments/cookie-attribute-names [4]. </del> <ins> IANA is requested to create the "Cookie Attribute Registry", defining the name space of attribute used to control cookies' behavior.  The registry should be maintained at https://www.iana.org/assignments/ cookie-attribute-names [4]. </ins> 9.3.1.
Code change:
The IANA Cookie Attribute Registry does not exist yet. It is requested that IANA create it. Clarify wording to reflect this. Addresses
The section titled "Cookie Attribute Registry" has a link to the attribute registry maintained by the IANA. This link is broken. Moreso, a cursory look through the IANA site doesn't turn up any similar pages suggesting that this section is obsolete.
The registry does not exist yet. The text about it was added in URL The prose should actually tell IANA that the registry needs to be created, not "updated".
Addressed by

Related discussion:
text: 9.3.2. <del> The "Cookie Attribute Registry" will be updated with the </del> <ins> The "Cookie Attribute Registry" should be created with the </ins> registrations below: 10.  References