jiebi/CodeConvo huggingface dataset:
Code change:
I think this also but I might have missed something. Misc changes that aren't actually necessary to use Structured Headers: "variant-item" became "variant-axis". I defined what clients ("caches"?) MUST do when a server violates one of its MUSTs. I removed the (incorrect) definition of available-value in favor of allowing arbitrary . It wasn't clear what excluding characters like was gaining us, and the restriction would have required extra words when parsing the headers. I removed {{gen-variant-key}} entirely and had Compute Possible Keys return a list of lists that could be directly compared against the Structured Header parse of . It would be difficult to keep the old behavior of returning a list of strings without re-adding some restriction on an available-value, for example by requiring that they don't contain spaces. I simplified Compute Possible Keys a bit.
URL shows a Variant-Key of But that's now This also has implications for the URL algorithm, which currently ignores semicolons.
looks like a parameterised list is currently a list of strings, but if is adopted, its syntax will need to be changed, as it doesn't fit into parameterised list particularly well (although I guess it could).
Currently waiting on resolution of .
NAME is closed now. Any hints?
Hi NAME - getting to it. Are you planning on implementing or using?

Related discussion:
text: as shown here. This specification uses the Augmented Backus-Naur Form (ABNF) <del> notation of RFC5234 with a list extension, defined in Section 7 of RFC7230, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). </del> <ins> notation of RFC5234 but relies on Structured Headers from I-D.ietf- httpbis-header-structure for parsing. </ins> <del> Additionally, it uses the "field-name", "OWS" and "token" rules from RFC7230, and "type", "subtype", "content-coding" and "language-range" from RFC7231. </del> <ins> Additionally, it uses the "field-name" rule from RFC7230, and "type", "subtype", "content-coding" and "language-range" from RFC7231. </ins> 2.
Code change:
I think this also but I might have missed something. Misc changes that aren't actually necessary to use Structured Headers: "variant-item" became "variant-axis". I defined what clients ("caches"?) MUST do when a server violates one of its MUSTs. I removed the (incorrect) definition of available-value in favor of allowing arbitrary . It wasn't clear what excluding characters like was gaining us, and the restriction would have required extra words when parsing the headers. I removed {{gen-variant-key}} entirely and had Compute Possible Keys return a list of lists that could be directly compared against the Structured Header parse of . It would be difficult to keep the old behavior of returning a list of strings without re-adding some restriction on an available-value, for example by requiring that they don't contain spaces. I simplified Compute Possible Keys a bit.
URL shows a Variant-Key of But that's now This also has implications for the URL algorithm, which currently ignores semicolons.
looks like a parameterised list is currently a list of strings, but if is adopted, its syntax will need to be changed, as it doesn't fit into parameterised list particularly well (although I guess it could).
Currently waiting on resolution of .
NAME is closed now. Any hints?
Hi NAME - getting to it. Are you planning on implementing or using?

Related discussion:
text: the response is produced, by enumerating the request header fields that it varies on, along with the values that are available for each. <del> Each "variant-item" indicates a request header field that carries a value that clients might proactively negotiate for; each parameter on it indicates a value for which there is an available representation on the origin server. </del> <ins> Variants is a Structured Header I-D.ietf-httpbis-header-structure. Its value MUST be a list-of-lists (Section 3.3 of I-D.ietf-httpbis- header-structure) whose members are strings (Section 3.8 of I-D.ietf- httpbis-header-structure) or tokens (Section 3.9 of I-D.ietf-httpbis- header-structure).  Its ABNF is: If Structured Header parsing fails or a list-member has the wrong type, the client MUST treat the representation as having no Variants header field. The Variants header field represents an ordered list of "variant- axes", each of which consists of a request header "field-name" string and a list of "available-value" strings.  Each inner-list in the Variants header field value is parsed into a variant-axis.  The first list-member of the inner-list is interpreted as the field-name, and the remaining list-members are the available-values.  Any list-member that is a token (Section 3.9 of I-D.ietf-httpbis-header-structure) is interpreted as a string containing the same characters. Field-names in the Variants header field value MUST match the field- name production (Section 3.2 of RFC7230).  Clients receiving an invalid field-name MUST NOT match it to any content negotiating mechanism. </ins> So, given this example header field:
Code change:
I think this also but I might have missed something. Misc changes that aren't actually necessary to use Structured Headers: "variant-item" became "variant-axis". I defined what clients ("caches"?) MUST do when a server violates one of its MUSTs. I removed the (incorrect) definition of available-value in favor of allowing arbitrary . It wasn't clear what excluding characters like was gaining us, and the restriction would have required extra words when parsing the headers. I removed {{gen-variant-key}} entirely and had Compute Possible Keys return a list of lists that could be directly compared against the Structured Header parse of . It would be difficult to keep the old behavior of returning a list of strings without re-adding some restriction on an available-value, for example by requiring that they don't contain spaces. I simplified Compute Possible Keys a bit.
URL shows a Variant-Key of But that's now This also has implications for the URL algorithm, which currently ignores semicolons.
looks like a parameterised list is currently a list of strings, but if is adopted, its syntax will need to be changed, as it doesn't fit into parameterised list particularly well (although I guess it could).
Currently waiting on resolution of .
NAME is closed now. Any hints?
Hi NAME - getting to it. Are you planning on implementing or using?

Related discussion:
text: Here, recipients can infer that two content-codings in addition to "identity" are available, as well as two content languages.  Note <del> that, as with all HTTP header fields that use the "#" list rule (see RFC7230, Section 7), they might occur in the same header field or separately, like this: </del> <ins> that, as with all Structured Header lists, they might occur in the same header field or separately, like this: </ins> The ordering of available-values after the field-name is significant, as it might be used by the header's algorithm for selecting a
Code change:
I think this also but I might have missed something. Misc changes that aren't actually necessary to use Structured Headers: "variant-item" became "variant-axis". I defined what clients ("caches"?) MUST do when a server violates one of its MUSTs. I removed the (incorrect) definition of available-value in favor of allowing arbitrary . It wasn't clear what excluding characters like was gaining us, and the restriction would have required extra words when parsing the headers. I removed {{gen-variant-key}} entirely and had Compute Possible Keys return a list of lists that could be directly compared against the Structured Header parse of . It would be difficult to keep the old behavior of returning a list of strings without re-adding some restriction on an available-value, for example by requiring that they don't contain spaces. I simplified Compute Possible Keys a bit.
URL shows a Variant-Key of But that's now This also has implications for the URL algorithm, which currently ignores semicolons.
looks like a parameterised list is currently a list of strings, but if is adopted, its syntax will need to be changed, as it doesn't fit into parameterised list particularly well (although I guess it could).
Currently waiting on resolution of .
NAME is closed now. Any hints?
Hi NAME - getting to it. Are you planning on implementing or using?

Related discussion:
text: This algorithm computes the cross-product of the elements of key- facets. <del> Given key-facets (a list of lists), and key-stub (a string representing a partial key), and possible-keys (a list): </del> <ins> Given key-facets (a list of lists of strings), and key-stub (a list of strings representing a partial key), and possible-keys (a list of lists of strings): </ins> Let values be the first member of key-facets. <del> For each value in values: If key-stub is an empty string, let this-key be a copy of value. </del> <ins> Let remaining-facets be a copy of all of the members of key-facets except the first. </ins> <del> Otherwise: Let this-key be a copy of key-stub. Append a semicolon (";") to this-key. </del> <ins> For each value in values: </ins> <del> Append value to this-key. </del> <ins> Let this-key be a copy of key-stub. </ins> <del> Let remaining-facets be a copy of all of the members of key- facets except the first. </del> <ins> Append value to this-key. </ins> If remaining-facets is empty, append this-key to possible-keys.
Code change:
I think this also but I might have missed something. Misc changes that aren't actually necessary to use Structured Headers: "variant-item" became "variant-axis". I defined what clients ("caches"?) MUST do when a server violates one of its MUSTs. I removed the (incorrect) definition of available-value in favor of allowing arbitrary . It wasn't clear what excluding characters like was gaining us, and the restriction would have required extra words when parsing the headers. I removed {{gen-variant-key}} entirely and had Compute Possible Keys return a list of lists that could be directly compared against the Structured Header parse of . It would be difficult to keep the old behavior of returning a list of strings without re-adding some restriction on an available-value, for example by requiring that they don't contain spaces. I simplified Compute Possible Keys a bit.
URL shows a Variant-Key of But that's now This also has implications for the URL algorithm, which currently ignores semicolons.
looks like a parameterised list is currently a list of strings, but if is adopted, its syntax will need to be changed, as it doesn't fit into parameterised list particularly well (although I guess it could).
Currently waiting on resolution of .
NAME is closed now. Any hints?
Hi NAME - getting to it. Are you planning on implementing or using?

Related discussion:
text: Then the sorted-variants would be: <del> Which means that the sorted-keys would be: </del> <ins> Which means that the result of the cache algorithm would be: </ins> Representing a first preference of a French, gzip'd response.  Thus, if a cache has a response with:
Code change:
This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL

Related discussion:
text: More generally, application protocols using HTTP face a number of design decisions, including: <del> Should it define a new URL scheme?  Use new ports? </del> <ins> Should it define a new URI scheme?  Use new ports? </ins> Should it use standard HTTP methods and status codes, or define new ones?
Code change:
This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL

Related discussion:
text: the transport port in use is 80 or 443, <del> the URL scheme "http" or "https" is used, </del> <ins> the URI scheme "http" or "https" is used, </ins> the ALPN protocol ID RFC7301 generically identifies HTTP (e.g., "http/1.1", "h2", "h2c"), or
Code change:
This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL

Related discussion:
text: adaptable to these changes, and as the protocol diverges from HTTP, the benefit of mindshare will be lost. <del> Protocols that are based upon HTTP MUST NOT reuse HTTP's URL schemes, </del> <ins> Protocols that are based upon HTTP MUST NOT reuse HTTP's URI schemes, </ins> transport ports, ALPN protocol IDs or IANA registries; rather, they are encouraged to establish their own.
Code change:
This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL

Related discussion:
text: can cause deployment issues, and is therefore bad practice in standards. <del> Instead of statically defining URL components like paths, it is </del> <ins> Instead of statically defining URI components like paths, it is </ins> RECOMMENDED that applications using HTTP define links in payloads, to allow flexibility in deployment.
Code change:
This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL

Related discussion:
text: Instead, applications are encouraged to ensure that URLs are discovered at runtime, allowing HTTP-based services to describe their own capabilities.  One way to do this is to use typed links RFC8288 <del> to convey the URIs that are in use, as well as the semantics of the </del> <ins> to convey the URLs that are in use, as well as the semantics of the </ins> resources that they identify.  See resource for details. 4.4.1.
Code change:
This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL

Related discussion:
text: 4.4.2. Applications that use HTTP will typically employ the "http" and/or <del> "https" URL schemes. "https" is RECOMMENDED to provide </del> <ins> "https" URI schemes. "https" is RECOMMENDED to provide </ins> authentication, integrity and confidentiality, as well as mitigate pervasive monitoring attacks RFC7258. However, application-specific schemes can also be defined.  When <del> defining an URL scheme for an application using HTTP, there are a </del> <ins> defining an URI scheme for an application using HTTP, there are a </ins> number of tradeoffs and caveats to keep in mind: Unmodified Web browsers will not support the new scheme.  While it <del> is possible to register new URL schemes with Web browsers (e.g. </del> <ins> is possible to register new URI schemes with Web browsers (e.g. </ins> registerProtocolHandler() in HTML5, as well as several proprietary approaches), support for these mechanisms is not shared by all browsers, and their capabilities vary.
Code change:
This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL

Related discussion:
text: Web features that require a secure context SECCTXT will likely treat a new scheme as insecure. <del> See RFC7595 for more information about minting new URL schemes. </del> <ins> See RFC7595 for more information about minting new URI schemes. </ins> 4.4.3.
Code change:
This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL

Related discussion:
text: expensive process. In some cases, however, GET might be unwieldy for expressing queries, <del> because of the limited syntax of the URL; in particular, if binary </del> <ins> because of the limited syntax of the URI; in particular, if binary </ins> data forms part of the query terms, it needs to be encoded to conform <del> to URL syntax. </del> <ins> to URI syntax. </ins> While this is not an issue for short queries, it can become one for larger query terms, or ones which need to sustain a high rate of
Code change:
This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL

Related discussion:
text: to identify clients.  The Basic authentication scheme RFC7617 MUST NOT be used unless the underlying transport is authenticated, integrity-protected and confidential (e.g., as provided the "HTTPS" <del> URL scheme, or another using TLS).  The Digest scheme RFC7616 MUST </del> <ins> URI scheme, or another using TLS).  The Digest scheme RFC7616 MUST </ins> NOT be used unless the underlying transport is similarly secure, or the chosen hash algorithm is not "MD5".
Code change:
This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL

Related discussion:
text: other than specified. Applications that use HTTP in a manner that involves modification of <del> implementations - for example, requiring support for a new URL </del> <ins> implementations - for example, requiring support for a new URI </ins> scheme, or a non-standard method - risk having those implementations "fork" from their parent HTTP implementations, with the possible result that they do not benefit from patches and other security
Code change:
and filed by NAME Given , the AUTOMATIC_USE text is entirely superfluous, and given , the correct wording would be "for a stream."
Not sure if this is an issue or not. Emphasis added in the below quote. This seems to have been left out of the change to stream 0 for all frames (URL)
Section 5.4 contains some left over text that refers to the now removed AUTOMATIC_USE flag. Cf. URL

Related discussion:
text: 6.3. <del> Failure to provide a certificate on a stream after receiving </del> <ins> Failure to provide a certificate for a stream after receiving </ins> "CERTIFICATE_NEEDED" blocks processing, and SHOULD be subject to standard timeouts used to guard against unresponsive peers.
Code change:
Signed-off-by: Piotr Sikora
This is effectively editorial, since the error restriction was removed in URL, where this type was renamed from to , but the description didn't reflect that change. cc NAME

Related discussion:
text: Name: http_response_status <del> Description: The intermediary has received a 4xx or 5xx status code from the next hop and forwarded it to the client. </del> <ins> Description: The intermediary has received a response from the next hop and forwarded it to the client. </ins> Extra Parameters: None.
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: For each member mem of input_plist: <del> Let id be the result of applying Serializing a Token (ser- token) to mem's token. </del> <ins> Let item be the result of applying Serializing an item (ser- item) to mem's primary-item. </ins> <del> Append id to output. </del> <ins> Append item to output. </ins> For each parameter in mem's parameters: