jiebi/CodeConvo huggingface dataset:
Code change:
Based on discussion at IETF 105, removing explicit lifetime in favor of implicit opt-in registration and persistence. NAME can you please take a look? In particular, current language states the preference should be persisted but doesn't explicitly state for what the lifetime is.. Modulo, in privacy section we do talk about MUST criteria for clearing it. Any suggestions or recommendations for how to best approach this?
LGTM

Related discussion:
text: will use that infrastructure.  Those features will be defined in their respective specifications. <del> This document does not supersede or replace the User-Agent header field.  Existing device detection mechanisms can continue to use both mechanisms if necessary.  By advertising user agent capabilities within a request header field, Client Hints allow for cache friendly and proactive content negotiation. </del> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Code change:
Based on discussion at IETF 105, removing explicit lifetime in favor of implicit opt-in registration and persistence. NAME can you please take a look? In particular, current language states the preference should be persisted but doesn't explicitly state for what the lifetime is.. Modulo, in privacy section we do talk about MUST criteria for clearing it. Any suggestions or recommendations for how to best approach this?
LGTM

Related discussion:
text: 5. <del> This document defines the "Accept-CH" and "Accept-CH-Lifetime" HTTP response fields, and registers them in the Permanent Message Header Fields registry. </del> <ins> This document defines the "Accept-CH" HTTP response field, and registers it in the Permanent Message Header Fields registry. </ins> 5.1.
Code change:
Based on discussion at IETF 105, removing explicit lifetime in favor of implicit opt-in registration and persistence. NAME can you please take a look? In particular, current language states the preference should be persisted but doesn't explicitly state for what the lifetime is.. Modulo, in privacy section we do talk about MUST criteria for clearing it. Any suggestions or recommendations for how to best approach this?
LGTM

Related discussion:
text: Specification document(s): accept-ch of this document Related information: for Client Hints <del> 5.2. Header field name: Accept-CH-Lifetime Applicable protocol: HTTP Status: standard Author/Change controller: IETF Specification document(s): accept-ch-lifetime of this document Related information: for Client Hints </del> 6.  References 6.1.  URIs
Code change:
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?

Related discussion:
text: algorithm without knowing whether the recipient supports the digest- algorithm, or even knowing that the recipient will ignore it. <ins> Examples: </ins> ... 5.
Code change:
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?

Related discussion:
text: 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.
Code change:
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?

Related discussion:
text: Digest can be used in requests too.  Returned value depends on the representation metadata header fields. <ins> 7.1.5. The response contains two digest values: one with no content coding applied, which in this case accidentally matches the unencoded digest-value sent in the request; one taking into account the "Content-Encoding". </ins> 7.2. 7.2.1.
Code change:
Now that we are generalizing how the types are used, I think it might be a good idea to allow a dictionary value to be a mapping (i.e., a list of parameters). This would be a generalization. At the moment, top level elements can contain scalars, lists, or dictionaries. However, it is at the moment impossible to use a dictionary at the second level even though scalars and lists are permitted. In terms of use-case, the proposed change would allow for example something like a cache-control directive to take a mapping as an argument (see URL). Logic-wise, I assume that the added complexity would not be significant, as we can reuse the definition for the parameters of a parameterised list.
NAME are you just asking for parameters on dictionary values, in a manner that's equivalent to list values?
NAME Sorry for the belated response. Yes. I'd be fine with member-value being exactly list-member.

Related discussion:
text: required to be unique within the scope of the dictionary they occur within. <ins> Each member of the dictionary can also have associated parameters - an ordered map of key-value pairs where the keys are short, textual strings and the values are items (item).  There can be zero or more parameters on a member, and their keys are required to be unique within that scope. </ins> Implementations MUST provide access to dictionaries both by index and by name.  Specifications MAY use either means of accessing the members.
Code change:
Now that we are generalizing how the types are used, I think it might be a good idea to allow a dictionary value to be a mapping (i.e., a list of parameters). This would be a generalization. At the moment, top level elements can contain scalars, lists, or dictionaries. However, it is at the moment impossible to use a dictionary at the second level even though scalars and lists are permitted. In terms of use-case, the proposed change would allow for example something like a cache-control directive to take a mapping as an argument (see URL). Logic-wise, I assume that the added complexity would not be significant, as we can reuse the definition for the parameters of a parameterised list.
NAME are you just asking for parameters on dictionary values, in a manner that's equivalent to list values?
NAME Sorry for the belated response. Yes. I'd be fine with member-value being exactly list-member.

Related discussion:
text: A dictionary with a member whose value is an inner-list of tokens: <del> Typically, a header field specification will define the semantics of individual member names, as well as whether their presence is </del> <ins> A dictionary with a mix of singular and list values, some with parameters: Typically, a header field specification will define the semantics using individual member names, as well as whether their presence is </ins> required or optional.  Recipients MUST ignore names that are undefined or unknown, unless the header field's specification specifically disallows them.
Code change:
Now that we are generalizing how the types are used, I think it might be a good idea to allow a dictionary value to be a mapping (i.e., a list of parameters). This would be a generalization. At the moment, top level elements can contain scalars, lists, or dictionaries. However, it is at the moment impossible to use a dictionary at the second level even though scalars and lists are permitted. In terms of use-case, the proposed change would allow for example something like a cache-control directive to take a mapping as an argument (see URL). Logic-wise, I assume that the added complexity would not be significant, as we can reuse the definition for the parameters of a parameterised list.
NAME are you just asking for parameters on dictionary values, in a manner that's equivalent to list values?
NAME Sorry for the belated response. Yes. I'd be fine with member-value being exactly list-member.

Related discussion:
text: Append mem_value to output. <del> For each parameter in parameters: Append ";" to output. Let name be the result of applying Serializing a Key (ser- key) to parameter's param-name. Append name to output. If parameter has a param-value: Let value be the result of applying Serializing an Item (ser-item) to parameter's param-value. Append "=" to output. Append value to output. </del> <ins> Append the result of Serializing Parameters ser-params with parameters to output. </ins> If more members remain in input_plist:
Code change:
Now that we are generalizing how the types are used, I think it might be a good idea to allow a dictionary value to be a mapping (i.e., a list of parameters). This would be a generalization. At the moment, top level elements can contain scalars, lists, or dictionaries. However, it is at the moment impossible to use a dictionary at the second level even though scalars and lists are permitted. In terms of use-case, the proposed change would allow for example something like a cache-control directive to take a mapping as an argument (see URL). Logic-wise, I assume that the added complexity would not be significant, as we can reuse the definition for the parameters of a parameterised list.
NAME are you just asking for parameters on dictionary values, in a manner that's equivalent to list values?
NAME Sorry for the belated response. Yes. I'd be fine with member-value being exactly list-member.

Related discussion:
text: 4.1.1.2. <ins> Given an ordered dictionary parameters: Let output be an empty string. For each parameter in parameters: Append ";" to output. Let name be the result of applying Serializing a Key (ser-key) to parameter's param-name. Append name to output. If parameter has a param-value: Let value be the result of applying Serializing an Item (ser- item) to parameter's param-value. Append "=" to output. Append value to output. Return output. 4.1.1.3. </ins> Given a key as input_key: If input_key is not a sequence of characters, or contains
Code change:
Now that we are generalizing how the types are used, I think it might be a good idea to allow a dictionary value to be a mapping (i.e., a list of parameters). This would be a generalization. At the moment, top level elements can contain scalars, lists, or dictionaries. However, it is at the moment impossible to use a dictionary at the second level even though scalars and lists are permitted. In terms of use-case, the proposed change would allow for example something like a cache-control directive to take a mapping as an argument (see URL). Logic-wise, I assume that the added complexity would not be significant, as we can reuse the definition for the parameters of a parameterised list.
NAME are you just asking for parameters on dictionary values, in a manner that's equivalent to list values?
NAME Sorry for the belated response. Yes. I'd be fine with member-value being exactly list-member.

Related discussion:
text: Let output be an empty string. <del> For each member mem of input_dictionary: </del> <ins> For each (member, parameters) of input_dictionary: </ins> Let name be the result of applying Serializing a Key (ser-key) <del> to mem's member-name. </del> <ins> to member's member-name. </ins> Append name to output. Append "=" to output. <del> If mem is an array, let value be the result of applying Serialising an Inner List (ser-innerlist) to mem. </del> <ins> If member is an array, let value be the result of applying Serialising an Inner List (ser-innerlist) to member. </ins> Otherwise, let value be the result of applying Serializing an <del> Item (ser-item) to mem. </del> <ins> Item (ser-item) to member. </ins> Append value to output. <ins> Append the result of Serializing Parameters ser-params with parameters to output. </ins> If more members remain in input_dictionary: Append a COMMA to output.
Code change:
Now that we are generalizing how the types are used, I think it might be a good idea to allow a dictionary value to be a mapping (i.e., a list of parameters). This would be a generalization. At the moment, top level elements can contain scalars, lists, or dictionaries. However, it is at the moment impossible to use a dictionary at the second level even though scalars and lists are permitted. In terms of use-case, the proposed change would allow for example something like a cache-control directive to take a mapping as an argument (see URL). Logic-wise, I assume that the added complexity would not be significant, as we can reuse the definition for the parameters of a parameterised list.
NAME are you just asking for parameters on dictionary values, in a manner that's equivalent to list values?
NAME Sorry for the belated response. Yes. I'd be fine with member-value being exactly list-member.

Related discussion:
text: Consume the first character of input_string; if it is not "=", fail parsing. <del> If the first character of input_string is "(", let this_value be the result of running Parsing an Inner List (parse- innerlist) with input_string. Else, let this_value be the result of running Parsing an Item (parse-item) with input_string. </del> <ins> Let member be the result of running Parsing a Parameterized Member from Text (parse-param) with input_string. </ins> <del> Add name this_key with value this_value to dictionary. </del> <ins> Add name this_key with value member to dictionary. </ins> Discard any leading OWS from input_string.
Code change:
thx!
Boolean values can be conveyed in Structured Headers. The ABNF for a Boolean in textual HTTP headers is: sh-boolean = "?" boolean boolean = "0" / "1" Either say "0" is false and "1" is true, or maybe rephrase the ABNF to: sh-boolean = sh-false / sh-true sh-false = "?0" sh-true = "?1"

Related discussion:
text: The ABNF for a Boolean in textual HTTP headers is: In textual HTTP headers, a boolean is indicated with a leading "?" <del> character.  For example: </del> <ins> character followed by a "1" for a true value or "0" for false.  For example: </ins> 4.
Code change:
This addresses feedback from the list: URL URL NAME NAME does this look good to you?
Very nice, thanks. You almost managed to do this with a net reduction in total lines. The only additions here are my fault. Respect.

Related discussion:
text: Abstract <del> This document clarifies the use of TLS 1.3 post-handshake authentication and key update with HTTP/2. </del> <ins> This document updates HTTP/2 to prohibit TLS 1.3 post-handshake authentication, as an analog to existing TLS 1.2 renegotiation restriction. </ins> Note to Readers
Code change:
This addresses feedback from the list: URL URL NAME NAME does this look good to you?
Very nice, thanks. You almost managed to do this with a net reduction in total lines. The only additions here are my fault. Respect.

Related discussion:
text: TLS 1.3 RFC8446 updates TLS 1.2 to remove renegotiation in favor of separate post-handshake authentication and key update mechanisms. The former shares the same problems with multiplexed protocols, but <del> has a different name.  This makes it ambiguous whether post-handshake authentication is allowed in TLS 1.3. </del> <ins> the prohibition in HTTP/2 only applies to TLS 1.2 renegotiation. </ins> <del> This document clarifies that the prohibition applies to post- handshake authentication but not to key updates. </del> <ins> This document updates HTTP/2 to similarly forbid TLS 1.3 post- handshake authentication. </ins> 2.
Code change:
This addresses feedback from the list: URL URL NAME NAME does this look good to you?
Very nice, thanks. You almost managed to do this with a net reduction in total lines. The only additions here are my fault. Respect.

Related discussion:
text: 3. <del> The prohibition on renegotiation in section 9.2.1 of RFC7540 additionally applies to TLS 1.3 post-handshake authentication. </del> HTTP/2 servers MUST NOT send post-handshake TLS 1.3 CertificateRequest messages.  HTTP/2 clients MUST treat TLS 1.3 post- handshake authentication as a connection error (see section 5.4.1 of
Code change:
This addresses feedback from the list: URL URL NAME NAME does this look good to you?
Very nice, thanks. You almost managed to do this with a net reduction in total lines. The only additions here are my fault. Respect.

Related discussion:
text: 4. <del> Section 9.2.1 of RFC7540 does not extend to TLS 1.3 KeyUpdate messages.  HTTP/2 implementations MUST support key updates when TLS 1.3 is negotiated. </del> <ins> RFC8446 defines two other messages that are exchanged after the handshake is complete, KeyUpdate and NewSessionTicket. KeyUpdate messages only affect TLS itself and do not require any interaction with the application protocol.  HTTP/2 implementations MUST support key updates when TLS 1.3 is negotiated. NewSessionTicket messages are also permitted.  Though these interact with HTTP when early data is enabled, these interactions are defined in RFC8470 and allowed for in the design of HTTP/2. Unless the use of a new type of TLS message depends on an interaction with the application layer protocol, that TLS message can be sent after the handshake completes. </ins> 5. <del> This document clarifies how to use HTTP/2 with TLS 1.3 and resolves a compatibility concern when supporting post-handshake authentication with HTTP/1.1.  This lowers the barrier for deploying TLS 1.3, a major security improvement over TLS 1.2.  Permitting key updates allows key material to be refreshed in long-lived HTTP/2 connections. </del> <ins> This document resolves a compatibility concern between HTTP/2 and TLS 1.3 when supporting post-handshake authentication with HTTP/1.1. This lowers the barrier for deploying TLS 1.3, a major security improvement over TLS 1.2. </ins> 6.
Code change:
(Should I go ahead and stamp a -02 now, or wait a bit? Not sure how one usually handles such things.)
WGLC ends on Thursday, so let's wait until then to see if there's any other feedback.
It is Friday, so I've now pushed -02. It just contains this PR. URL

Related discussion:
text: HTTP/2 RFC7540 multiplexes multiple HTTP requests over a single connection, which is incompatible with the mechanism above.  Clients cannot correlate the certificate request with the HTTP request which <del> triggered it.  Thus, section 9.2.1 of RFC7540 forbids renegotiation. </del> <ins> triggered it.  Thus, Section 9.2.1 of RFC7540 forbids renegotiation. </ins> TLS 1.3 RFC8446 updates TLS 1.2 to remove renegotiation in favor of separate post-handshake authentication and key update mechanisms.
Code change:
(Should I go ahead and stamp a -02 now, or wait a bit? Not sure how one usually handles such things.)
WGLC ends on Thursday, so let's wait until then to see if there's any other feedback.
It is Friday, so I've now pushed -02. It just contains this PR. URL

Related discussion:
text: HTTP/2 servers MUST NOT send post-handshake TLS 1.3 CertificateRequest messages.  HTTP/2 clients MUST treat TLS 1.3 post- <del> handshake authentication as a connection error (see section 5.4.1 of </del> <ins> handshake authentication as a connection error (see Section 5.4.1 of </ins> RFC7540) of type PROTOCOL_ERROR. RFC7540 permitted renegotiation before the HTTP/2 connection preface
Code change:
Fixes artwork formatting.
[x] requests and responses to use different artworks [x] artworks not containing trailing/heading carriages

Related discussion:
text: Here is a gzip-compressed json object <ins> Request: </ins> Now the same payload body conveys a malformed json object. <ins> Request: </ins> A Range-Request alters the payload body, conveying a partial representation. <ins> Request: Response: </ins> Now the method too alters the payload body. <ins> Request: Response: </ins> 3. Digest algorithm values are used to indicate a specific digest
Code change:
Fixes artwork formatting.
[x] requests and responses to use different artworks [x] artworks not containing trailing/heading carriages

Related discussion:
text: 7.1.1. <ins> Request: Response: </ins> 7.1.2. As there is no content coding applied, the "sha-256" and the "id-sha- 256" digest-values are the same. <ins> Request: Response: </ins> 7.1.3. <ins> Request: Response: </ins> 7.1.4. Digest can be used in requests too.  Returned value depends on the representation metadata header fields. <ins> Request: Response: </ins> 7.1.5. Request "Digest" value is calculated on the enclosed payload.
Code change:
Fixes artwork formatting.
[x] requests and responses to use different artworks [x] artworks not containing trailing/heading carriages

Related discussion:
text: The client requests a digest, preferring sha.  The server is free to reply with sha-256 anyway. <ins> Request: Response: </ins> 7.2.2. The client requests a sha digest only.  The server is currently free to reply with a Digest containing an unsupported algorithm <ins> Request: Response: </ins> 7.2.3. The client requests a sha Digest, the server advises for sha-256 and sha-512 <ins> Request: Response: </ins> ... 8.
Code change:
to use the new "validator" name. See: URL URL
NAME I'm quite weak on that side: is this PR correct? If not feel free to fix at will :)
NAME I agree... this comes from the original RFC 3230. Merging the change as a simple terminology update. The relation b/w validators and the resource is discussed in , where I tagged you as your guidance will be great. See too.
to clarify the following passage for defining the behavior of digest with caching (eg. when Digest is returned together with Last-Modified and ETag). and to better extend the definition of Digest to POST and PATCH requests. This is because though only when they include explicit freshness information. If we go on the new http-core definition (which is cleaner) we have that eg. According to URL POST responses identify returned resources in different ways according to the following: the primary resource is identified by Content-Location the enclosed representation matches the primary resource eg. 1 eg. 2 primary resource identified by enclosed representation matches the status of the request according to the resource's own semantic eg.
re-reading the old RFC my understanding is that validator fields should just be aligned with Digest (that is: digest-value should be aligned with the values of last-modified and etag). While it is trivial, the original editor could have considered that a potential issue.
The change itself looks right. I wonder however about the whole paragraph: what does it mean to say "resource is specified"? Doesn't that also need request header fields upon which the returned representation varies?

Related discussion:
text: RFC7230. The definitions "representation", "selected representation", <del> "representation data", "representation metadata" and "payload body" </del> <ins> "representation data", "representation metadata", and "payload body" </ins> in this document are to be interpreted as described in RFC7230 and RFC7231. <ins> The definition "validator" in this document is to be interpreted as described in Section 7.2 of RFC7231. </ins> 2. To avoid inconsistencies, an integrity mechanism for HTTP messages