jiebi/CodeConvo huggingface dataset:
Code change:
in , NAME asks about having Parameterised Lists whose parameterised identifiers are things other than Tokens. Because of the way SH is put together, I think this would be a fairly easy change, in terms of the spec and implementations; it would require a few more tests. The only downside I can think of immediately is that specs would need to constrain the type of the parameterised identifier themselves, and specify error handling (if it weren't the default "blow up"). Thoughts? I also wonder if we should come up with a better name than "parameterised identifier", especially since we've ditched "identifier" elsewhere. member name? member id? primary identifier?
That works, since splitting lists from parameterised lists. Are you thinking , or just adding a few types? It also changes my thinking a tiny bit on , although not much. I like "parameterised element" but that introduces a new word. "parameterised item" is a nice shade, if any item is allowed there, but "primary identifier" works too. :art: :paintbrush:
The downside here is that it would be very hard to represent in JSON -- e.g., in the . At least some programming languages support hashes/dictionaries/objects with arbitrary key types (e.g., Python, JavaScript, Ruby), but I'm not sure how widespread that is -- especially if folks represent the different between and with an object for . NAME is this a nice-to-have or something that's a blocker?
(Fwiw I do think we should call this a Parameterised Token)
At this point do we just have to accept that the SH data model is essentially a subset of the JavaScript model? Numbers are bounded by JavaScript's limitations, object keys have to be stringy, nobody likes 'token' because it isn't a native JS type... I don't mind if that's the case, but it would be good to just say it outright somewhere. It would also give us a solid position to start from when considering other proposals. Hmm, C++ and Go could be have issues mixing key types within a single map, and Perl is definitely not going to like non-string keys.
It doesn't have to be -- it's just easier for me to write tests this way :)
This was a nice-to-have for me. I’d worked around it by putting an unused string as the identifier. It looks like that workaround is no longer necessary?

Related discussion:
text: 4.2.4. Given an ASCII string input_string, return a list of parameterized <del> identifiers. input_string is modified to remove the parsed value. </del> <ins> items. input_string is modified to remove the parsed value. </ins> Let items be an empty array. While input_string is not empty: <del> Let item be the result of running Parse Parameterized Identifier from Text (parse-param-id) with input_string. </del> <ins> Let item be the result of running Parse Parameterized Item from Text (parse-param-item) with input_string. </ins> Append item to items.
Code change:
in , NAME asks about having Parameterised Lists whose parameterised identifiers are things other than Tokens. Because of the way SH is put together, I think this would be a fairly easy change, in terms of the spec and implementations; it would require a few more tests. The only downside I can think of immediately is that specs would need to constrain the type of the parameterised identifier themselves, and specify error handling (if it weren't the default "blow up"). Thoughts? I also wonder if we should come up with a better name than "parameterised identifier", especially since we've ditched "identifier" elsewhere. member name? member id? primary identifier?
That works, since splitting lists from parameterised lists. Are you thinking , or just adding a few types? It also changes my thinking a tiny bit on , although not much. I like "parameterised element" but that introduces a new word. "parameterised item" is a nice shade, if any item is allowed there, but "primary identifier" works too. :art: :paintbrush:
The downside here is that it would be very hard to represent in JSON -- e.g., in the . At least some programming languages support hashes/dictionaries/objects with arbitrary key types (e.g., Python, JavaScript, Ruby), but I'm not sure how widespread that is -- especially if folks represent the different between and with an object for . NAME is this a nice-to-have or something that's a blocker?
(Fwiw I do think we should call this a Parameterised Token)
At this point do we just have to accept that the SH data model is essentially a subset of the JavaScript model? Numbers are bounded by JavaScript's limitations, object keys have to be stringy, nobody likes 'token' because it isn't a native JS type... I don't mind if that's the case, but it would be good to just say it outright somewhere. It would also give us a solid position to start from when considering other proposals. Hmm, C++ and Go could be have issues mixing key types within a single map, and Perl is definitely not going to like non-string keys.
It doesn't have to be -- it's just easier for me to write tests this way :)
This was a nice-to-have for me. I’d worked around it by putting an unused string as the identifier. It looks like that workaround is no longer necessary?

Related discussion:
text: map of parameters. input_string is modified to remove the parsed value. <del> Let primary_identifier be the result of Parsing a Token from Text (parse-token) from input_string. </del> <ins> Let primary_item be the result of Parsing an item from Text (parse-item) from input_string. </ins> Let parameters be an empty, ordered map.
Code change:
in , NAME asks about having Parameterised Lists whose parameterised identifiers are things other than Tokens. Because of the way SH is put together, I think this would be a fairly easy change, in terms of the spec and implementations; it would require a few more tests. The only downside I can think of immediately is that specs would need to constrain the type of the parameterised identifier themselves, and specify error handling (if it weren't the default "blow up"). Thoughts? I also wonder if we should come up with a better name than "parameterised identifier", especially since we've ditched "identifier" elsewhere. member name? member id? primary identifier?
That works, since splitting lists from parameterised lists. Are you thinking , or just adding a few types? It also changes my thinking a tiny bit on , although not much. I like "parameterised element" but that introduces a new word. "parameterised item" is a nice shade, if any item is allowed there, but "primary identifier" works too. :art: :paintbrush:
The downside here is that it would be very hard to represent in JSON -- e.g., in the . At least some programming languages support hashes/dictionaries/objects with arbitrary key types (e.g., Python, JavaScript, Ruby), but I'm not sure how widespread that is -- especially if folks represent the different between and with an object for . NAME is this a nice-to-have or something that's a blocker?
(Fwiw I do think we should call this a Parameterised Token)
At this point do we just have to accept that the SH data model is essentially a subset of the JavaScript model? Numbers are bounded by JavaScript's limitations, object keys have to be stringy, nobody likes 'token' because it isn't a native JS type... I don't mind if that's the case, but it would be good to just say it outright somewhere. It would also give us a solid position to start from when considering other proposals. Hmm, C++ and Go could be have issues mixing key types within a single map, and Perl is definitely not going to like non-string keys.
It doesn't have to be -- it's just easier for me to write tests this way :)
This was a nice-to-have for me. I’d worked around it by putting an unused string as the identifier. It looks like that workaround is no longer necessary?

Related discussion:
text: Add key param_name with value param_value to parameters. <del> Return the tuple (primary_identifier, parameters). </del> <ins> Return the tuple (primary_item, parameters). </ins> 4.2.6.
Code change:
fixes typo in reference
FYI, there is (at least) a 180-4 now.

Related discussion:
text: SHA algorithm is NOT RECOMMENDED as it's now vulnerable to collision attacks IACR-2019-459. <del> Reference: [FIPS-180-3], RFC4648, this document. </del> <ins> Reference: FIPS180-3, RFC4648, this document. </ins> Status: obsoleted
Code change:
Fixes unused references. Removed reference to FIPS180-4 and opened issue Removed unneeded references Uses required references.
Should we update the FIPS180 reference to the latest one? NIST updated the document defining SHA-* algoritms. The latest reference is digest-headers references preserve the ones cited in RFC3230 and subsequent.
cross-posting from elsewhere, I said I think we probably want to use FIPS180-4 for SHA-256 and SHA-512, and FIPS180-1 for SHA-1.
There is also .
[x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \
Fixed in

Related discussion:
text: 1. Integrity protection for HTTP content is multi layered and is usually <del> achieved across the protocol stack: TCP checksums and TLS record to name but some. </del> <ins> achieved across the protocol stack: TCP checksums and TLS RFC2818 record to name but some. </ins> The HTTP protocol does not provide means to protect the various message parts.  Besides, it might be desirable to add additional
Code change:
Fixes unused references. Removed reference to FIPS180-4 and opened issue Removed unneeded references Uses required references.
Should we update the FIPS180 reference to the latest one? NIST updated the document defining SHA-* algoritms. The latest reference is digest-headers references preserve the ones cited in RFC3230 and subsequent.
cross-posting from elsewhere, I said I think we probably want to use FIPS180-4 for SHA-256 and SHA-512, and FIPS180-1 for SHA-1.
There is also .
[x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \
Fixed in

Related discussion:
text: This approach can be easily adapted to use-cases where the transferred data does require some sort of manipulation to be considered a representation or conveys a partial representation of a <del> resource (eg.  Range Requests). </del> <ins> resource (eg.  Range Requests RFC7233). </ins> Changes are semantically compatible with existing implementations and better cover both the request and response cases.
Code change:
Fixes unused references. Removed reference to FIPS180-4 and opened issue Removed unneeded references Uses required references.
Should we update the FIPS180 reference to the latest one? NIST updated the document defining SHA-* algoritms. The latest reference is digest-headers references preserve the ones cited in RFC3230 and subsequent.
cross-posting from elsewhere, I said I think we probably want to use FIPS180-4 for SHA-256 and SHA-512, and FIPS180-1 for SHA-1.
There is also .
[x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \
Fixed in

Related discussion:
text: should decouple the checksum calculation: from the payload body - which may be altered by mechanism like <del> Range Requests or the method (eg.  HEAD); </del> <ins> Range Requests RFC7233 or the method (eg.  HEAD); </ins> and from the message body - which depends on "Transfer-Encoding" and whatever tranformations the intermediaries may apply.
Code change:
Adds -latest to docname
[x] WARNING: The Internet-Draft name 'draft-ietf-httpbis-digest-headers' should end with a two-digit sequence number or 'latest'. (at line 20)

Related discussion:
text: Resource Digests for HTTP <del> draft-ietf-httpbis-digest-headers </del> <ins> draft-ietf-httpbis-digest-headers-latest </ins> Abstract
Code change:
consistent use of instead of "http" make S1.1, P3 a bit more readable

Related discussion:
text: A final (but significant) goal is to provide for ease of implementation, deployment and operation.  This mechanism is expected <del> to have a minimal impact upon performance, and a trivial </del> <ins> to have a minimal impact upon performance, and require a trivial </ins> administrative effort to configure. 1.2.
Code change:
NAME - can you take a look and see if that clarifies things?
This seems helpful given what's currently in the spec. However, I think some of the material I was talking about when I filed is no longer there. But I suspect that material may now be in other specs, and could perhaps still gain from being clarified at its current location.
I've been reading Client Hints (both and the ), and I'm having a little trouble understanding how things fit together in terms of which header fields are sent when and lead to what. My confusion started when I looked at the section and noticed (to my surprise) that was being registered as both a request header field and a response header field (when, having read the spec quickly, I was expecting it to be only a response header field, and wasn't sure what it would mean as a request header field). Then I looked back over the spec, and noticed that section 2 of the spec is called but that the entirety of the section appears (I think) to be about response header fields. I think it would help the spec be easier to understand if it: more carefully distinguished between request header fields and response header fields, and more clearly explained what the request header field is.
lgtm, thank you!

Related discussion:
text: additional response header fields to convey related values to aid client processing. <del> 2.2.1. </del> <ins> 3. Servers can advertise support for Client Hints using the mechnisms described below. 3.1. </ins> <del> Servers can advertise support for Client Hints using the Accept-CH header field or an equivalent HTML meta element with http-equiv attribute (HTML5).  Accept-CH is a Structured Header I-D.ietf- httpbis-header-structure.  Its value MUST be an sh-list (Section 3.1 of I-D.ietf-httpbis-header-structure) whose members are tokens (Section 3.7 of I-D.ietf-httpbis-header-structure).  Its ABNF is: </del> <ins> The Accept-CH response header field or the equivalent HTML meta element with http-equiv attribute (HTML5) indicate server support for particular hints indicated in its value.  Accept-CH is a Structured Header I-D.ietf-httpbis-header-structure.  Its value MUST be an sh- list (Section 3.1 of I-D.ietf-httpbis-header-structure) whose members are tokens (Section 3.7 of I-D.ietf-httpbis-header-structure).  Its ABNF is: </ins> For example:
Code change:
NAME - can you take a look and see if that clarifies things?
This seems helpful given what's currently in the spec. However, I think some of the material I was talking about when I filed is no longer there. But I suspect that material may now be in other specs, and could perhaps still gain from being clarified at its current location.
I've been reading Client Hints (both and the ), and I'm having a little trouble understanding how things fit together in terms of which header fields are sent when and lead to what. My confusion started when I looked at the section and noticed (to my surprise) that was being registered as both a request header field and a response header field (when, having read the spec quickly, I was expecting it to be only a response header field, and wasn't sure what it would mean as a request header field). Then I looked back over the spec, and noticed that section 2 of the spec is called but that the entirety of the section appears (I think) to be about response header fields. I think it would help the spec be easier to understand if it: more carefully distinguished between request header fields and response header fields, and more clearly explained what the request header field is.
lgtm, thank you!

Related discussion:
text: same-origin resource requests initiated by the page constructed from the response. <del> 2.2.2. </del> <ins> 3.2. </ins> Servers can ask the client to remember the set of Client Hints that the server supports for a specified period of time, to enable
Code change:
NAME - can you take a look and see if that clarifies things?
This seems helpful given what's currently in the spec. However, I think some of the material I was talking about when I filed is no longer there. But I suspect that material may now be in other specs, and could perhaps still gain from being clarified at its current location.
I've been reading Client Hints (both and the ), and I'm having a little trouble understanding how things fit together in terms of which header fields are sent when and lead to what. My confusion started when I looked at the section and noticed (to my surprise) that was being registered as both a request header field and a response header field (when, having read the spec quickly, I was expecting it to be only a response header field, and wasn't sure what it would mean as a request header field). Then I looked back over the spec, and noticed that section 2 of the spec is called but that the entirety of the section appears (I think) to be about response header fields. I think it would help the spec be easier to understand if it: more carefully distinguished between request header fields and response header fields, and more clearly explained what the request header field is.
lgtm, thank you!

Related discussion:
text: If Accept-CH-Lifetime occurs in a message more than once, the last value overrides all previous occurrences. <del> 2.2.3. </del> <ins> 3.2.1. </ins> When selecting an optimized response based on one or more Client Hints, and if the resource is cacheable, the server needs to generate
Code change:
NAME - can you take a look and see if that clarifies things?
This seems helpful given what's currently in the spec. However, I think some of the material I was talking about when I filed is no longer there. But I suspect that material may now be in other specs, and could perhaps still gain from being clarified at its current location.
I've been reading Client Hints (both and the ), and I'm having a little trouble understanding how things fit together in terms of which header fields are sent when and lead to what. My confusion started when I looked at the section and noticed (to my surprise) that was being registered as both a request header field and a response header field (when, having read the spec quickly, I was expecting it to be only a response header field, and wasn't sure what it would mean as a request header field). Then I looked back over the spec, and noticed that section 2 of the spec is called but that the entirety of the section appears (I think) to be about response header fields. I think it would help the spec be easier to understand if it: more carefully distinguished between request header fields and response header fields, and more clearly explained what the request header field is.
lgtm, thank you!

Related discussion:
text: Above example indicates that the cache key needs to include the Sec- CH-Example and Sec-CH-Example-2 header fields. <del> 3. </del> <ins> 4. </ins> The request header fields defined in this document, and those that extend it, expose information about the user's environment to enable
Code change:
NAME - can you take a look and see if that clarifies things?
This seems helpful given what's currently in the spec. However, I think some of the material I was talking about when I filed is no longer there. But I suspect that material may now be in other specs, and could perhaps still gain from being clarified at its current location.
I've been reading Client Hints (both and the ), and I'm having a little trouble understanding how things fit together in terms of which header fields are sent when and lead to what. My confusion started when I looked at the section and noticed (to my surprise) that was being registered as both a request header field and a response header field (when, having read the spec quickly, I was expecting it to be only a response header field, and wasn't sure what it would mean as a request header field). Then I looked back over the spec, and noticed that section 2 of the spec is called but that the entirety of the section appears (I think) to be about response header fields. I think it would help the spec be easier to understand if it: more carefully distinguished between request header fields and response header fields, and more clearly explained what the request header field is.
lgtm, thank you!

Related discussion:
text: clear persisted opt-in preferences when any one of site data, browsing history, browsing cache, or similar, are cleared. <del> 4. </del> <ins> 5. </ins> This document defines the "Accept-CH" and "Accept-CH-Lifetime" HTTP response fields, and registers them in the Permanent Message Header Fields registry. <del> 4.1. </del> <ins> 5.1. </ins> Header field name: Accept-CH Applicable protocol: HTTP
Code change:
NAME - can you take a look and see if that clarifies things?
This seems helpful given what's currently in the spec. However, I think some of the material I was talking about when I filed is no longer there. But I suspect that material may now be in other specs, and could perhaps still gain from being clarified at its current location.
I've been reading Client Hints (both and the ), and I'm having a little trouble understanding how things fit together in terms of which header fields are sent when and lead to what. My confusion started when I looked at the section and noticed (to my surprise) that was being registered as both a request header field and a response header field (when, having read the spec quickly, I was expecting it to be only a response header field, and wasn't sure what it would mean as a request header field). Then I looked back over the spec, and noticed that section 2 of the spec is called but that the entirety of the section appears (I think) to be about response header fields. I think it would help the spec be easier to understand if it: more carefully distinguished between request header fields and response header fields, and more clearly explained what the request header field is.
lgtm, thank you!

Related discussion:
text: Specification document(s): accept-ch of this document Related information: for Client Hints <del> 4.2. </del> <ins> 5.2. </ins> Header field name: Accept-CH-Lifetime Applicable protocol: HTTP
Code change:
NAME - can you take a look and see if that clarifies things?
This seems helpful given what's currently in the spec. However, I think some of the material I was talking about when I filed is no longer there. But I suspect that material may now be in other specs, and could perhaps still gain from being clarified at its current location.
I've been reading Client Hints (both and the ), and I'm having a little trouble understanding how things fit together in terms of which header fields are sent when and lead to what. My confusion started when I looked at the section and noticed (to my surprise) that was being registered as both a request header field and a response header field (when, having read the spec quickly, I was expecting it to be only a response header field, and wasn't sure what it would mean as a request header field). Then I looked back over the spec, and noticed that section 2 of the spec is called but that the entirety of the section appears (I think) to be about response header fields. I think it would help the spec be easier to understand if it: more carefully distinguished between request header fields and response header fields, and more clearly explained what the request header field is.
lgtm, thank you!

Related discussion:
text: Specification document(s): accept-ch-lifetime of this document Related information: for Client Hints <del> 5.  References </del> <ins> 6.  References </ins> <del> 5.1.  URIs </del> <ins> 6.1.  URIs </ins> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/