jiebi/CodeConvo huggingface dataset:
Code change:
During the SEC AD review, a DISCUSS was raised about the current status values. This change modifies the values to better align with Signatures. The guidance for registration and/or usage of an algorithm based on the status is not affected.

Related discussion:
text: pay attention to the requested status.  The status value should reflect standardization status and the broad opinion of relevant interest groups such as the IETF or security-related SDOs.  The <del> "standard" status is not suitable for an algorithm that is known to be weak, broken, or experimental.  If a registration request attempts to register such an algorithm as "standard", the designated expert(s) should suggest an alternative status of "insecure" or "provisional". </del> <ins> "Active" status is not suitable for an algorithm that is known to be weak, broken, or experimental.  If a registration request attempts to register such an algorithm as "Active", the designated expert(s) should suggest an alternative status of "Deprecated" or "Provisional". </ins> When reviewing registration requests, the designated expert(s) cannot <del> use a status of "insecure" or "provisional" as grounds for rejection. </del> <ins> use a status of "Deprecated" or "Provisional" as grounds for rejection. </ins> Requests to update or change the fields in an existing registration are permitted.  For example, this could allow for the transition of <del> an algorithm status from "standard" to "insecure" as the security </del> <ins> an algorithm status from "Active" to "Deprecated" as the security </ins> environment evolves. 6.
Code change:
Looks good except for minor details and potentially a bug (encoding vs decoding). I'd also like to see the spec enforce a consistent form of percent encoding (lower vs upper)
I am sceptical wrt "use the URI percent encoder". The reason being: percent encoding rules depend on what part of the URI needs encoding (and many APIs do not get that) calling the API for a single character multiple times usually requires converting a char to a string, and that might not be good for perf if we really care about that
I've removed the reliance on URI for percent encoding; was clean as NAME said it would be. Regarding case -- NAME RFC4648 Section 8 is explicitly case-insensitive. Given that and the discussion in the group yesterday, I've left this case-insensitive. Say if you still disagree.
NAME , I was suggesting an inline definition. The fact that uppercase is base16 would just be an observation (and not a particularly useful one). Lowercase tends to be the default mode in several places.
NAME it wasn't at all clear that's what you were suggesting. I'll make an attempt.
Looking at it, I think I prefer referring to 4648. This this addresses the original issue, I'll merge; if someone wants to propose an alternate way to specify this, please feel free to open a PR.
As currently defined, the two serialized DisplayStrings %"foo\"bla%22bar" and %"foo%22bla\"bar" are semantically identical. We should either use %-escapes or \-escapes, mixing them this way is asking for smuggling-attacks.
I think probably -escapes; will work up a PR.
I don't believe that relying on a different RFC for the hex encoding makes this much better (so I sort of disagree with Martin's proposal). Just define the escaping exactly inline, and then we can choose upper/lower.

Related discussion:
text: Given a string of Unicode characters as input_string, return an ASCII string suitable for use in an HTTP field value. <ins> If input_string is not a string of Unicode characters, fail parsing. </ins> Let byte_array be the result of applying UTF-8 encoding UTF8 to <del> input_string.  If there is an error in doing so, fail parsing. </del> <ins> input_string. </ins> Let encoded_string be an empty string. For each byte in byte_array: <del> If byte is %x25 ("%"), append "%25" to encoded_string. </del> <ins> If byte is %x25 ("%"), %x22 (DQUOTE), or in the ranges %x00-1f or %x7f-ff: </ins> <del> If byte is in the ranges %x00-1f or %x7f-ff, apply the percent- encoding defined in Section 2.1 of URI to byte and append the result to encoded_string. </del> <ins> Append "%" to encoded_string. Let encoded_byte be the result of applying base16 encoding (Section 8 of RFC4648) to byte. Append encoded_byte to encoded_string. </ins> Otherwise, decode byte as an ASCII character and append the result to encoded_string. <del> Let formatted_string be the result of running Serialising a String (ser-string) with encoded_string. </del> <ins> Let output be a string containing "%" followed by DQUOTE. </ins> <del> Return the character "%" followed by formatted_string. </del> <ins> Append encoded_string to output. Append DQUOTE to output. Return output. </ins> 4.2.
Code change:
Within TLS 1.3, the only options for 0-RTT are "accept" or "reject". "accept but delay until after the handshake" is not visible within the TLS 1.3 protocol. The current draft language doesn't align nicely with this, and should be adjusted. Credit: NAME

Related discussion:
text: 4.1. When using this specification in HTTP/2 or HTTP/3, clients MAY start <del> sending TCP stream content without waiting for an HTTP response. Proxies MUST buffer this "false start" content until the TCP stream becomes writable, and discard it if the TCP connection fails.  (This "false start" behavior is not permitted in HTTP/1.1 because it would prevent reuse of the connection after an error response such as 407 (Proxy Authentication Required).) </del> <ins> sending TCP stream content optimistically, subject to flow control limits (RFC9113)(RFC9000).  Proxies MUST buffer this "optimistic" content until the TCP stream becomes writable, and discard it if the TCP connection fails.  (This "optimistic" behavior is not permitted in HTTP/1.1 because it would prevent reuse of the connection after an error response such as "407 (Proxy Authentication Required)".) </ins> Servers that host a proxy under this specification MAY offer support for TLS early data in accordance with RFC8470.  Clients MAY send <del> "connect-tcp" requests in early data, and MAY include "false start" content in early data (in HTTP/2 and HTTP/3).  Proxies MAY accept, reject, or delay processing of this early data.  For example, a proxy with limited anti-replay defenses might choose to perform DNS resolution of the "target_host" when a request arrives in early data, but delay the TCP connection until the TLS handshake completes. </del> <ins> "connect-tcp" requests in early data, and MAY include "optimistic" TCP content in early data (in HTTP/2 and HTTP/3).  At the TLS layer, proxies MAY ignore, reject, or accept the "early_data" extension (RFC8446).  At the HTTP layer, proxies MAY process the request immediately, return a "425 (Too Early)" response (RFC8470), or delay some or all processing of the request until the handshake completes. For example, a proxy with limited anti-replay defenses might choose to perform DNS resolution of the "target_host" when a request arrives in early data, but delay the TCP connection until the TLS handshake completes. </ins> 4.2.
Code change:
Closes URL
NAME brought up that during the WG meeting that reusing Upload-Complete on requests and responses can be confusing. They don’t mean exactly the same thing: on the server means it has received the full upload, while on the client means the body it will send is a complete upload.
We discussed this internally and prepared a response: Upload-Complete is used on both requests and responses because it is symmetrical. Upon a typical successful transaction, an request results in an response, and an request results in an response. A server implementation can simply echo the field. However, they are also meanings that we can take advantage of. The presence on the request means it’s a resumable request, and the presence on the response is also a useful signal. Since we are upgrading regular uploads, there are cases where 4xx/5xx responses are intentional and we can't just eat it by attempting to resume. We would be much more confident that the response came from the real server rather than a middlebox which shouldn’t randomly add . The server can also use to terminate a request early if it does not care about the body, similar to the early response mechanism in HTTP/3.
I am having second thoughts about this as well. While debugging a server implementation, the naming of the headers also confused me for a moment (even though I wrote parts of the draft). The reason is that in a response (or how it is currently called) refers to the current state of the upload, while in a request refers to the potential state in the future, if the request completed successfully. I don't think that we have a general issue with the concept of and have to change much. But maybe a simple name change can help here already to alleviate the confusion. We could use for the response header to indicate that it represents the current state. And for request headers to indicate that process the request successfully will complete the upload. We loose the symmetry of the names in request and response, but maybe this makes their relation even clearer.
I think for both client and server works because it represents their own perspectives of the upload. For the client, sending means "the upload is complete on my end, I've included all the data to complete it." The client isn't making assumptions about whether the server has received all the data; it's only expressing to the server that from its perspective, the upload data supplied is now whole. For the server, responding acknowledges the client's view of the complete upload and says, "Yes, the upload is complete on my end, too." Same goes for .
At IETF 117, we agreed on using for requests and responses: URL I will open a PR for this and then we can close this issue.

Related discussion:
text: set to the resumption offset. If the end of the request body is not the end of the upload, the <del> "Upload-Incomplete" header field (upload-incomplete) MUST be set to true. </del> <ins> "Upload-Complete" header field (upload-complete) MUST be set to false. </ins> The server SHOULD respect representation metadata received in the Upload Creation Procedure (upload-creation) and ignore any
Code change:
Closes URL
NAME brought up that during the WG meeting that reusing Upload-Complete on requests and responses can be confusing. They don’t mean exactly the same thing: on the server means it has received the full upload, while on the client means the body it will send is a complete upload.
We discussed this internally and prepared a response: Upload-Complete is used on both requests and responses because it is symmetrical. Upon a typical successful transaction, an request results in an response, and an request results in an response. A server implementation can simply echo the field. However, they are also meanings that we can take advantage of. The presence on the request means it’s a resumable request, and the presence on the response is also a useful signal. Since we are upgrading regular uploads, there are cases where 4xx/5xx responses are intentional and we can't just eat it by attempting to resume. We would be much more confident that the response came from the real server rather than a middlebox which shouldn’t randomly add . The server can also use to terminate a request early if it does not care about the body, similar to the early response mechanism in HTTP/3.
I am having second thoughts about this as well. While debugging a server implementation, the naming of the headers also confused me for a moment (even though I wrote parts of the draft). The reason is that in a response (or how it is currently called) refers to the current state of the upload, while in a request refers to the potential state in the future, if the request completed successfully. I don't think that we have a general issue with the concept of and have to change much. But maybe a simple name change can help here already to alleviate the confusion. We could use for the response header to indicate that it represents the current state. And for request headers to indicate that process the request successfully will complete the upload. We loose the symmetry of the names in request and response, but maybe this makes their relation even clearer.
I think for both client and server works because it represents their own perspectives of the upload. For the client, sending means "the upload is complete on my end, I've included all the data to complete it." The client isn't making assumptions about whether the server has received all the data; it's only expressing to the server that from its perspective, the upload data supplied is now whole. For the server, responding acknowledges the client's view of the complete upload and says, "Yes, the upload is complete on my end, too." Same goes for .
At IETF 117, we agreed on using for requests and responses: URL I will open a PR for this and then we can close this issue.

Related discussion:
text: This specification registers the following entry in the Permanent Message Header Field Names registry established by RFC3864: <del> Header field name: Upload-Offset, Upload-Incomplete </del> <ins> Header field name: Upload-Offset, Upload-Complete </ins> Applicable protocol: http
Code change:
Can I suggest we use 'converted' instead of 'normalized' ?
WFM, will update.
It's annoying to test for otherwise. Still allow both cases in parse.
Postel's law ("Be liberal in what you accept, and conservative in what you send.") isn't as popular these days as it once was. Not sure we need to accept upper case % anymore.
I am sure that we don’t. (Though I have thoughts on the use of the Robustness Principle to guide this sort of decision. Generally, it is better to look at what the case needs. Here, the values are created by code, so permissiveness is not a valuable feature.)
Fine. See URL

Related discussion:
text: Append "%" to encoded_string. Let encoded_byte be the result of applying base16 encoding <del> (Section 8 of RFC4648) to byte. </del> <ins> (Section 8 of RFC4648) to byte, with any alphabetic characters converted to lowercase. </ins> Append encoded_byte to encoded_string.
Code change:
Can I suggest we use 'converted' instead of 'normalized' ?
WFM, will update.
It's annoying to test for otherwise. Still allow both cases in parse.
Postel's law ("Be liberal in what you accept, and conservative in what you send.") isn't as popular these days as it once was. Not sure we need to accept upper case % anymore.
I am sure that we don’t. (Though I have thoughts on the use of the Robustness Principle to guide this sort of decision. Generally, it is better to look at what the case needs. Here, the values are created by code, so permissiveness is not a valuable feature.)
Fine. See URL

Related discussion:
text: input_string.  If there are not two characters, fail parsing. <ins> If octet_hex contains characters outside the range %x30-39 or %x61-66 (i.e., it is not in 0-9 or lowercase a-f), fail parsing. </ins> Let octet be the result of hex decoding octet_hex (Section 8 <del> of RFC4648), in a case-insensitive fashion.  If decoding fails, fail parsing. </del> <ins> of RFC4648). </ins> Append octet to byte_array.
Code change:
I tried to make this work, but NAME is right: this is entirely a transport decision and given that our best option was to violate a MUST in RFC 7230, that's too hard. This just says that HTTP/1.1 is no good because we can't include the scheme (because RFC 7230 says we can't). I almost made this h2-specific, but then remembered that there might be another protocol that has favourable properties.
It's official - MT says "HTTP/1.1 is no good."

Related discussion:
text: An origin server that supports the resolution of "http" URIs can indicate support for this specification by providing an alternative service advertisement RFC7838 for a protocol identifier that uses <del> TLS, such as "h2" RFC7540, or "http/1.1" RFC7301.  Note that HTTP/1.1 requests MUST use the absolute form (see Section 5.3.2 of RFC7230). </del> <ins> TLS, such as "h2" RFC7540.  Such a protocol MUST include an explicit indication of the scheme of the resource.  This excludes HTTP/1.1; HTTP/1.1 clients are forbidden from including the absolute form of a URI in requests to origin servers (see Section 5.3.1 of RFC7230). </ins> A client that receives such an advertisement MAY make future requests <del> intended for the associated origin (RFC6454) to the identified service (as specified by RFC7838), provided that the alternative service opts in as described in auth. </del> <ins> intended for the associated origin RFC6454 to the identified service (as specified by RFC7838), provided that the alternative service opts in as described in opt-in. </ins> A client that places the importance of protection against passive attacks over performance might choose to withhold requests until an
Code change:
I tried to make this work, but NAME is right: this is entirely a transport decision and given that our best option was to violate a MUST in RFC 7230, that's too hard. This just says that HTTP/1.1 is no good because we can't include the scheme (because RFC 7230 says we can't). I almost made this h2-specific, but then remembered that there might be another protocol that has favourable properties.
It's official - MT says "HTTP/1.1 is no good."

Related discussion:
text: to determine if a request is for an "https" resource; for example, they might look for TLS on the stack, or a server port number of 443. <del> This might be due to limitations in the protocol (the most common HTTP/1.1 request form does not carry an explicit indication of the URI scheme), or it may be because how the server and application are </del> <ins> This might be due to expected limitations in the protocol (the most common HTTP/1.1 request form does not carry an explicit indication of the URI scheme and the resource might have been developed assuming HTTP/1.1), or it may be because how the server and application are </ins> implemented (often, they are two separate entities, with a variety of possible interfaces between them).
Code change:
This switches the custom wildcard matching to use with regexp support disabled. URLPattern is being used by the service worker routing API's and is what the web side is standardizing on for anything that pattern-matches URLs. This splits the match pattern into explicit path and search (query param) components and forces the origin to be inherited from the dictionary request URL. Also included here is a new field for to allow for matching on request destinations. The biggest use case for that will be for allowing site-wide HTML dictionaries to do something like and for the dictionary to not be sent for every request across the site (images, etc). See issues , ,

Related discussion:
text: The "ttl" value is optional and defaults to 31536000 (1 year). <del> 2.1.3. </del> <ins> 2.1.5. </ins> The "type" value of the Use-As-Dictionary header is a sf-string value that describes the file format of the supplied dictionary.
Code change:
This switches the custom wildcard matching to use with regexp support disabled. URLPattern is being used by the service worker routing API's and is what the web side is standardizing on for anything that pattern-matches URLs. This splits the match pattern into explicit path and search (query param) components and forces the origin to be inherited from the dictionary request URL. Also included here is a new field for to allow for matching on request destinations. The biggest use case for that will be for allowing site-wide HTML dictionaries to do something like and for the dictionary to not be sent for every request across the site (images, etc). See issues , ,

Related discussion:
text: The "type" value is optional and defaults to "raw". <del> 2.1.4. </del> <ins> 2.1.6. </ins> The "hashes" value of the Use-As-Dictionary header is a inner-list value that provides a list of supported hash algorithms in order of
Code change:
This switches the custom wildcard matching to use with regexp support disabled. URLPattern is being used by the service worker routing API's and is what the web side is standardizing on for anything that pattern-matches URLs. This splits the match pattern into explicit path and search (query param) components and forces the origin to be inherited from the dictionary request URL. Also included here is a new field for to allow for matching on request destinations. The biggest use case for that will be for allowing site-wide HTML dictionaries to do something like and for the dictionary to not be sent for every request across the site (images, etc). See issues , ,

Related discussion:
text: The "hashes" value is optional and defaults to (sha-256). <del> 2.1.5. </del> <ins> 2.1.7. </ins> <del> 2.1.5.1. </del> <ins> 2.1.7.1. </ins> A response that contained a response header: <del> Would specify matching any URL with a path prefix of /product/ on the same Origin as the original request, expiring as a dictionary in 7 days independent of the cache lifetime of the resource, and advertise support for both sha-256 and sha-512 hash algorithms. </del> <ins> Would specify matching any document request for a URL with a path prefix of /product/ on the same Origin as the original request, expiring as a dictionary in 7 days independent of the cache lifetime of the resource, and advertise support for both sha-256 and sha-512 hash algorithms. </ins> <del> 2.1.5.2. </del> <ins> 2.1.7.2. </ins> A response that contained a response header:
Code change:
This switches the custom wildcard matching to use with regexp support disabled. URLPattern is being used by the service worker routing API's and is what the web side is standardizing on for anything that pattern-matches URLs. This splits the match pattern into explicit path and search (query param) components and forces the origin to be inherited from the dictionary request URL. Also included here is a new field for to allow for matching on request destinations. The biggest use case for that will be for allowing site-wide HTML dictionaries to do something like and for the dictionary to not be sent for every request across the site (images, etc). See issues , ,

Related discussion:
text: 6.3.1. To make sure that a dictionary can only impact content from the same <del> origin where the dictionary was served, the "match" pattern used for matching a dictionary to requests MUST be for the same origin that the dictionary is served from. </del> <ins> origin where the dictionary was served, the URLPattern used for matching a dictionary to requests is guaranteed to be for the same origin that the dictionary is served from. </ins> 6.3.2.