jiebi/CodeConvo huggingface dataset:
Code change:
NAME had a few comments in the review of this that are easy to solve.
All changes are OK to me as well. Thanks!
43d2c16 does a great job capturing the point that I made poorly off-list; thanks again!

Related discussion:
text: TLS 1.3 TLS13 introduces the concept of early data (also known as zero round trip data or 0-RTT data).  Early data allows a client to send data to a server in the first round trip of a connection, <del> without waiting for the TLS handshake to complete if the client has </del> <ins> without waiting for the TLS handshake to complete, if the client has </ins> spoken to the same server recently. When used with HTTP HTTP, early data allows clients to send requests
Code change:
NAME had a few comments in the review of this that are easy to solve.
All changes are OK to me as well. Thanks!
43d2c16 does a great job capturing the point that I made poorly off-list; thanks again!

Related discussion:
text: request routing is likely to be safe from side-effects, but other actions might not be. <del> Intermediary servers do not have sufficient information to make this determination, so status describes a way for the origin to signal to them that a particular request isn't appropriate for early data. Intermediaries that accept early data MUST implement that mechanism. </del> <ins> Intermediary servers do not have sufficient information to decide whether early data can be processed, so status describes a way for the origin to signal to them that a particular request isn't appropriate for early data.  Intermediaries that accept early data MUST implement that mechanism. </ins> Note that a server cannot choose to selectively reject early data at the TLS layer.  TLS only permits a server to accept all early data,
Code change:
NAME had a few comments in the review of this that are easy to solve.
All changes are OK to me as well. Thanks!
43d2c16 does a great job capturing the point that I made poorly off-list; thanks again!

Related discussion:
text: sent in early data - thereby giving the client control over risk of replay.  Absent other information, clients MAY send requests with safe HTTP methods (see RFC7231, Section 4.2.1) in early data when it <del> is available, and SHOULD NOT send unsafe methods (or methods whose </del> <ins> is available, and MUST NOT send unsafe methods (or methods whose </ins> safety is not known) in early data. If the server rejects early data at the TLS layer, a client MUST
Code change:
NAME had a few comments in the review of this that are easy to solve.
All changes are OK to me as well. Thanks!
43d2c16 does a great job capturing the point that I made poorly off-list; thanks again!

Related discussion:
text: Automatic retry creates the potential for a replay attack.  An attacker intercepts a connection that uses early data and copies the early data to another server instance.  The second server instance <del> accepts and processes the early data.  The attacker then allows the original connection to complete.  Even if the early data is detected as a duplicate and rejected, the first server instance might allow the connection to complete.  If the client then retries requests that </del> <ins> accepts and processes the early data, even though it will not complete the TLS handshake.  The attacker then allows the original connection to complete.  Even if the early data is detected as a duplicate and rejected, the first server instance might allow the connection to complete.  If the client then retries requests that </ins> were sent in early data, the request will be processed twice. Replays are also possible if there are multiple server instances that
Code change:
NAME had a few comments in the review of this that are easy to solve.
All changes are OK to me as well. Thanks!
43d2c16 does a great job capturing the point that I made poorly off-list; thanks again!

Related discussion:
text: replayed.  A retried or replayed request can produce different side effects on the server.  In addition to those side effects, replays and retries might be used for traffic analysis to recover information <del> about requests or the resources those requests target. </del> <ins> about requests or the resources those requests target.  In particular, a request that is replayed might result in a different response, which might be observable from the length of protected data even if the content remains confidential. </ins> 6.1.
Code change:
Just editorial suggestions here, but all good ones.
Nice wording, I really like this new version. Thanks!

Related discussion:
text: eliminate the chance of data being replayed and ensure a fixed upper limit to the number of replays. <del> The server can reject early data.  A server cannot selectively reject early data, so this results in all requests sent in early data being discarded. </del> <ins> The server can reject early data at the TLS layer.  A server cannot selectively reject early data, so this results in all requests sent in early data being discarded. </ins> The server can choose to delay processing of early data until after the TLS handshake completes.  By deferring processing, it
Code change:
Just editorial suggestions here, but all good ones.
Nice wording, I really like this new version. Thanks!

Related discussion:
text: If the server receives multiple requests in early data, it can determine whether to defer HTTP processing on a per-request basis. <del> The server can cause a client to retry a request and not use early data by responding with the 425 (Too Early) status code (status), in cases where the risk of replay is judged too great. </del> <ins> The server can cause a client to retry individual requests and not use early data by responding with the 425 (Too Early) status code (status), in cases where the risk of replay is judged too great. </ins> For a given request, the level of tolerance to replay risk is specific to the resource it operates upon (and therefore only known <del> to the origin server).  In general, if processing a request does not have state-changing side effects, the consequences of replay are not significant. </del> <ins> to the origin server).  The primary risk associated with using early data is in the actions a server takes when processing a request; processing a duplicated request might result in duplicated effects and side effects.  Appendix E.5 of TLS13 also describes other effects produced by processing duplicated requests. </ins> The request method's safety (RFC7231, Section 4.2.1) is one way to <del> determine this.  However, some resources do elect to associate side effects with safe methods, so this cannot be universally relied upon. </del> <ins> determine if a request is free from side effects.  However, some resources do elect to associate side effects with safe methods, so this cannot be universally relied upon. </ins> It is RECOMMENDED that origin servers allow resources to explicitly configure whether early data is appropriate in requests.  Absent such
Code change:
Just editorial suggestions here, but all good ones.
Nice wording, I really like this new version. Thanks!

Related discussion:
text: A server can limit the amount of early data with the "max_early_data_size" field of the "early_data" TLS extension.  This can be used to avoid committing an arbitrary amount of memory for <del> deferred requests.  A server SHOULD ensure that when it accepts early data, it can defer processing of requests until after the TLS handshake completes. </del> <ins> requests that it might defer until the handshake completes. </ins> 4.
Code change:
Just editorial suggestions here, but all good ones.
Nice wording, I really like this new version. Thanks!

Related discussion:
text: start sending again as though the connection was new.  This could entail using a different negotiated protocol ALPN than the one optimistically used for the early data.  Any requests sent in early <del> data MUST be sent again, unless the client decides to abandon those requests. </del> <ins> data will need to be sent again, unless the client decides to abandon those requests. </ins> Automatic retry creates the potential for a replay attack.  An attacker intercepts a connection that uses early data and copies the
Code change:
Just editorial suggestions here, but all good ones.
Nice wording, I really like this new version. Thanks!

Related discussion:
text: Replays are also possible if there are multiple server instances that will accept early data, or if the same server accepts early data <del> multiple times (though this would be in violation of requirements in Section 8 of TLS13). </del> <ins> multiple times (though the latter would be in violation of requirements in Section 8 of TLS13). </ins> Clients that use early data MUST retry requests upon receipt of a 425 (Too Early) status code; see status.
Code change:
Just editorial suggestions here, but all good ones.
Nice wording, I really like this new version. Thanks!

Related discussion:
text: header field set to "1" (i.e., it adds it if not present in the request).  An intermediary MUST use the "Early-Data" header field if it might have forwarded the request prior to handshake completion <del> (see be-consistent for details). </del> <ins> (be-consistent describes considerations for clusters of servers). </ins> An intermediary MUST NOT remove this header field if it is present in a request.  "Early-Data" MUST NOT appear in a "Connection" header
Code change:
This will conflict with the changes ekr suggested, but I integrated them, so merging shouldn't lose the important changes.
For "sent in early data on another connection", I think Spencer's proposal "sent in early data on a previous hop" would make it even clearer regarding the hop chain so as not to confuse this with another connection from the same user-agent. OK for the rest.

Related discussion:
text: A server decides whether or not to offer a client the ability to send early data on future connections when sending the TLS session ticket. <ins> TLS TLS13 mandates the use of replay detection strategies that reduce the ability of an attacker to successfully replay early data.  These anti-replay techniques reduce but don't completely eliminate the chance of data being replayed and ensure a fixed upper limit to the number of replays. </ins> When a server enables early data, there are a number of techniques it can use to mitigate the risks of replay: <del> TLS TLS13 mandates the use of replay detection strategies that reduce the ability of an attacker to successfully replay early data.  These anti-replay techniques reduce but don't completely eliminate the chance of data being replayed and ensure a fixed upper limit to the number of replays. </del> The server can reject early data at the TLS layer.  A server cannot selectively reject early data, so this results in all requests sent in early data being discarded.
Code change:
This will conflict with the changes ekr suggested, but I integrated them, so merging shouldn't lose the important changes.
For "sent in early data on another connection", I think Spencer's proposal "sent in early data on a previous hop" would make it even clearer regarding the hop chain so as not to confuse this with another connection from the same user-agent. OK for the rest.

Related discussion:
text: after the TLS handshake completes.  By deferring processing, it can ensure that only a successfully completed connection is used for the request(s) therein.  This provides the server with some <del> assurance that the early data was not replayed. If the server receives multiple requests in early data, it can determine whether to defer HTTP processing on a per-request basis. </del> <ins> assurance that the early data was not replayed.  If the server receives multiple requests in early data, it can determine whether to defer HTTP processing on a per-request basis. </ins> The server can cause a client to retry individual requests and not use early data by responding with the 425 (Too Early) status code (status), in cases where the risk of replay is judged too great. <ins> Any of these techniques is equally effective and a server can use the method that best suits it. </ins> For a given request, the level of tolerance to replay risk is specific to the resource it operates upon (and therefore only known to the origin server).  The primary risk associated with using early
Code change:
This will conflict with the changes ekr suggested, but I integrated them, so merging shouldn't lose the important changes.
For "sent in early data on another connection", I think Spencer's proposal "sent in early data on a previous hop" would make it even clearer regarding the hop chain so as not to confuse this with another connection from the same user-agent. OK for the rest.

Related discussion:
text: Because HTTP requests can span multiple "hops", it is necessary to explicitly communicate whether a request has been sent in early data <del> on a previous connection.  Likewise, some means of explicitly triggering a retry when early data is not desirable is necessary. Finally, it is necessary to know whether the client will actually perform such a retry. </del> <ins> on a previous hop.  Likewise, some means of explicitly triggering a retry when early data is not desirable is necessary.  Finally, it is necessary to know whether the client will actually perform such a retry. </ins> To meet these needs, two signalling mechanisms are defined:
Code change:
This will conflict with the changes ekr suggested, but I integrated them, so merging shouldn't lose the important changes.
For "sent in early data on another connection", I think Spencer's proposal "sent in early data on a previous hop" would make it even clearer regarding the hop chain so as not to confuse this with another connection from the same user-agent. OK for the rest.

Related discussion:
text: A 425 (Too Early) status code indicates that the server is unwilling to risk processing a request that might be replayed. <del> User agents that send a request in early data MUST automatically retry the request when receiving a 425 (Too Early) response status code.  Such retries MUST NOT be sent in early data. </del> <ins> User agents that send a request in early data are expected to retry the request when receiving a 425 (Too Early) response status code.  A user agent MAY do so automatically, but any retries MUST NOT be sent in early data. </ins> In all cases, an intermediary can forward a 425 (Too Early) status code.  Intermediaries MUST forward a 425 (Too Early) status code if
Code change:
This will conflict with the changes ekr suggested, but I integrated them, so merging shouldn't lose the important changes.
For "sent in early data on another connection", I think Spencer's proposal "sent in early data on a previous hop" would make it even clearer regarding the hop chain so as not to confuse this with another connection from the same user-agent. OK for the rest.

Related discussion:
text: In protocols that deliver data out of order (such as QUIC HQ) early data can arrive after the handshake completes.  A server MAY process <del> requests received in early data after handshake completion if it can rely on other instances correctly handling replays of the same </del> <ins> requests received in early data after handshake completion only if it can rely on other instances correctly handling replays of the same </ins> requests. 7.
Code change:
Follow-on to ; in the process of fixing this, I noticed that I'd added a "server" header but missed adding a corresponding "client" header, so the client discussion appeared in the server section.
For some reason, that seems to be endemic in this doc. Let's do that cleanup separately.
I appreciate the addition of the section heading. Though Section Headings Use Title Case.

Related discussion:
text: certificate are not already available, they will need to be sent as described in cert-available as part of this exchange. <ins> If the client does not have the desired certificate, it instead sends an Empty Authenticator, as described in Section 5 of I-D.ietf-tls- exported-authenticator, in a "CERTIFICATE" frame in response to the request, followed by a "USE_CERTIFICATE" frame which references the Empty Authenticator.  In this case, or if the client has not advertised support for HTTP-layer certificates, the server processes the request based solely on the certificate provided during the TLS handshake, if any.  This might result in an error response via HTTP, such as a status code 403 (Not Authorized). </ins> 3. The "CERTIFICATE_REQUEST" and "CERTIFICATE_NEEDED" frames are
Code change:
Per discussions in fetch [1], update the opt-in example to apply to same-origin resources only, with Accept-CH-Lifetime being processed on navigation requests. [1] URL /cc NAME NAME

Related discussion:
text: their default settings, user configuration, and server preferences. The client and server can use an opt-in mechanism outlined below to negotiate which fields should be sent to allow for efficient content <del> adaption, and optinally use additional mechanisms to negotiate </del> <ins> adaption, and optionally use additional mechanisms to negotiate </ins> delegation policies that control access of third parties to same fields.
Code change:
Per discussions in fetch [1], update the opt-in example to apply to same-origin resources only, with Accept-CH-Lifetime being processed on navigation requests. [1] URL /cc NAME NAME

Related discussion:
text: origin that isn't HTTPS. For example, based on the Accept-CH and Accept-CH-Lifetime example <del> above, which is received from "https://bar.example.com" in response to a resource request initiated by "https://foo.example.com", both delivered over a secure transport: a user agent SHOULD persist an Accept-CH preference bound to "https://foo.example.com", for requests initiated to "https://bar.example.com" from "https://foo.example.com", for up to 86400 seconds (1 day).  This preference SHOULD NOT extend to requests initiated to "https://bar.example.com" from other origins. </del> <ins> above, which is received in response to a user agent navigating to "https://example.com", and delivered over a secure transport: a user agent SHOULD persist an Accept-CH preference bound to "https://example.com" for up to 86400 seconds (1 day), and use it for user agent navigations to "https://example.com" and any same-origin resource requests initiated by the page constructed from the navigation's response.  This preference SHOULD NOT extend to resource requests initiated to "https://example.com" from other origins. </ins> If Accept-CH-Lifetime occurs in a message more than once, the last value overrides all previous occurrences.
Code change:
Step 4.4 equates "the range %x00-1f or %x7f" to "not in VCHAR", but VCHAR doesn't include %x20; this change adds "or SP" and imports SP from RFC5234.
Thanks!

Related discussion:
text: as shown here. This document uses the Augmented Backus-Naur Form (ABNF) notation of <del> RFC5234, including the VCHAR, DIGIT, ALPHA and DQUOTE rules from that document.  It also includes the OWS rule from RFC7230. </del> <ins> RFC5234, including the VCHAR, SP, DIGIT, ALPHA and DQUOTE rules from that document.  It also includes the OWS rule from RFC7230. </ins> This document uses algorithms to specify parsing and serialisation behaviours, and ABNF to illustrate expected syntax.
Code change:
Step 4.4 equates "the range %x00-1f or %x7f" to "not in VCHAR", but VCHAR doesn't include %x20; this change adds "or SP" and imports SP from RFC5234.
Thanks!

Related discussion:
text: Given a string as input: If input is not a sequence of characters, or contains characters <del> outside the range allowed by VCHAR, fail serialisation. </del> <ins> outside the range allowed by VCHAR or SP, fail serialisation. </ins> Let output be an empty string.
Code change:
Step 4.4 equates "the range %x00-1f or %x7f" to "not in VCHAR", but VCHAR doesn't include %x20; this change adds "or SP" and imports SP from RFC5234.
Thanks!

Related discussion:
text: Else, if char is DQUOTE, return output_string. Else, if char is in the range %x00-1f or %x7f (i.e., is not in <del> VCHAR), fail parsing. </del> <ins> VCHAR or SP), fail parsing. </ins> Else, append char to output_string.
Code change:
Makes "Parse a Number from Text" not be greedy, and return (not fail) when it encounters a non-digit character.
I'm pretty sure it works. Steps 5 & 6 ensure there's always at least one digit. All the calling contexts of "Parsing an Item from Text" (including the top-level algorithm in §4.2) inspect the next character, and handle it appropriately.
SGTM
Section 4.2.6 (Parsing a Number from Text) is ambiguous. It makes no mention of the exit condition from the while loop in step 7 on parsing a number from an input buffer.
I don't see it. The loop terminates with "fail parsing" in 7.4 (invalid character), or 7.5/7.6 (too many digits); or terminates successfully by virtue of "input_string is not empty" becoming untrue.
An example might clarify what I find ambiguous. Let us suppose that the input string is "-11-1, 4, 3", and that we are parsing a list. We'd call parseItem(), which would then invoke parseNumber(). When should parseNumber() stop reading in characters? Should it read in "-11" and then leave the rest to the next parsing function, or should it read in "-11-1" and then fail parsing? The other sections are unambiguous as to when to stop reading in characters (for instance, section 4.2.7 step 4.3 states that parsing of a string would stop when you encounter a DQUOTE, and section 4.2.9 step 3 states that parsing of binary content would stop when you encounter an ending asterisk).
Oh I see what you're saying. Yes, step 7.4 shouldn't be so aggressive.

Related discussion:
text: Else, if type is "integer" and char is ".", append char to input_number and set type to "float". <del> Otherwise, fail parsing. </del> <ins> Otherwise, prepend char to input_string, and exit the loop. </ins> If type is "integer" and input_number contains more than 19 characters, fail parsing.
Code change:
Serialised wasn't getting appended to
Would it be better to just have each of the steps before return their result?
I did wonder that when writing it. Or make them all . Or however you think looks best. I probably should have just filed it as an Issue. :thinking:

Related discussion:
text: If input is a type other than an integer, float, string or binary content, fail serialisation. <del> Let output be an empty string. If input is an integer, let value be the result of applying Serialising an Integer ser-integer to input. </del> <ins> If input is an integer, return the result of applying Serialising an Integer ser-integer to input. </ins> <del> If input is a float, let value be the result of applying Serialising a Float ser-float to input. </del> <ins> If input is a float, return the result of applying Serialising a Float ser-float to input. </ins> <del> If input is a string, let value be the result of applying Serialising a String ser-string to input. </del> <ins> If input is a string, return the result of applying Serialising a String ser-string to input. </ins> <del> If input is binary content, let value be the result of applying Serialising Binary Content ser-binary to input. Return output. </del> <ins> Otherwise, return the result of applying Serialising Binary Content ser-binary to input. </ins> 4.1.5.
Code change:
When parsing a number, multiply back in to before testing against the range defined in Section 3.5.
Thanks!

Related discussion:
text: If the final character of input_number is ".", fail parsing. Parse input_number as a float and let output_number be the <del> result. </del> <ins> product of the result and sign. </ins> <del> Return the product of output_number and sign. </del> <ins> Return output_number. </ins> 4.2.7.