jiebi/TextFlow huggingface dataset:
Original text:
Else, if type is "integer" and char is ".", append char to input_number and set type to "float". <del> Otherwise, fail parsing. </del>  If type is "integer" and input_number contains more than 19 characters, fail parsing.

Reviewer comments:
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.

Revised text:
Else, if type is "integer" and char is ".", append char to input_number and set type to "float".  <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.
Original 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>  <del> If input is a float, let value be the result of applying Serialising a Float ser-float to input. </del>  <del> If input is a string, let value be the result of applying Serialising a String ser-string to input. </del>  <del> If input is binary content, let value be the result of applying Serialising Binary Content ser-binary to input. Return output. </del>  4.1.5.

Reviewer comments:
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:

Revised text:
If input is a type other than an integer, float, string or binary content, fail serialisation.  <ins> If input is an integer, return the result of applying Serialising an Integer ser-integer to input. </ins>  <ins> If input is a float, return the result of applying Serialising a Float ser-float to input. </ins>  <ins> If input is a string, return the result of applying Serialising a String ser-string to input. </ins>  <ins> Otherwise, return the result of applying Serialising Binary Content ser-binary to input. </ins> 4.1.5.
Original text:
If type is "integer": Parse input_number as an integer and let output_number be the <del> result. </del>  If output_number is outside the range defined in integer, fail parsing.

Reviewer comments:
When parsing a number, multiply back in to before testing against the range defined in Section 3.5.
Thanks!

Revised text:
If type is "integer": Parse input_number as an integer and let output_number be the  <ins> product of the result and sign. </ins> If output_number is outside the range defined in integer, fail parsing.
Original 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>  <del> Return the product of output_number and sign. </del>  4.2.7.

Reviewer comments:
When parsing a number, multiply back in to before testing against the range defined in Section 3.5.
Thanks!

Revised text:
If the final character of input_number is ".", fail parsing. Parse input_number as a float and let output_number be the  <ins> product of the result and sign. </ins>  <ins> Return output_number. </ins> 4.2.7.
Original text:
Else, append char to output_string. <del> Otherwise, fail parsing. </del>  4.2.8.

Reviewer comments:
How's that? It looks kind of like the equivalent case in Parse Dict/Parse List, but more descriptive than it was.

Revised text:
Else, append char to output_string.  <ins> Reached the end of input_string without finding a closing DQUOTE; fail parsing. </ins> 4.2.8.
Original text:
attribute-name of "Path", and the cookie's path is "/". If the cookie store contains a cookie with the same name, domain, <del> and path as the newly-created cookie: </del>  Let old-cookie be the existing cookie with the same name, <del> domain, and path as the newly-created cookie.  (Notice that this algorithm maintains the invariant that there is at most one such cookie.) </del>  If the newly-created cookie was received from a "non-HTTP" API and the old-cookie's http-only-flag is true, abort these steps

Reviewer comments:
Closes URL NAME mind taking a look?
(NAME would you mind adding NAME to the repo as a collaborator so I can ask him to review via the GitHub tool? :) )
Ping.
Invite was sent a while back. Still listed as "pending."
It is an internal flag, but I don't think the PR needs additional documentation. The change we're making is in the middle of an algorithm, and is basically a variable that was set earlier in the process. I think folks reading the document will understand that. :)
Thanks for the review! I'll merge this, and look forward to your PR adding yourself as an editor.
RFC 6265 section 5.3 defines a cookie by the name, domain, and path. However, given these two headers in a response from a request to URL Set-Cookie: mycookie=nothostonly; URL Set-Cookie: mycookie=hostonly Most browsers will have two cookies since they include host-only-flag in their definition of a unique cookie. I'd like to update section 4.1.2 and 5.3 to reflect the behavior of modern browsers with regards to host-only-flag.
Discussed in Berlin; seems reasonable.
I probably need to read more of the context but would it be useful to point out that this is an internal flag for the user agent? It is, right? Inferred from whether the setting of the cookie included the domain or not.

Revised text:
attribute-name of "Path", and the cookie's path is "/". If the cookie store contains a cookie with the same name, domain,  <ins> host-only-flag, and path as the newly-created cookie: </ins> Let old-cookie be the existing cookie with the same name,  <ins> domain, host-only-flag, and path as the newly-created cookie. (Notice that this algorithm maintains the invariant that there is at most one such cookie.) </ins> If the newly-created cookie was received from a "non-HTTP" API and the old-cookie's http-only-flag is true, abort these steps
Original text:
values from the Variants header field that identify the representation it occurs within. <del> Each member of the list contains the selected available-value(s), in the same order as the variants listed in the Variants header field. </del>  <del> Therefore, Variant-Key MUST be the same length (in comma-separated members) as Variants, and each member MUST correspond in position to its companion in Variants. </del>  For example: This header pair indicates that the representation has a "gzip" content-coding and "fr" content-language. <del> A more complex example involves listing multiple available-values in a list member, to indicate that the response can be used to satisfy requests with any of those values.  For example: </del>  indicates that this response can be used for requests whose Accept- Encoding algorithm selects "gzip" or "identity", as long as the Accept-Language algorithm selects "fr" - perhaps because there is no gzip-compressed French representation. <del> This highlights an important aspect of Variant-Key; it is only used to indicate what request attributes are associated with the response containing it; this is different from headers like Content-Encoding, which indicate attributes of the response itself. </del>  3.1.

Reviewer comments:
For
from the list Maybe we should be talking about a Variant-Key syntax that lets you specify alternative sets of values, e.g.,

Revised text:
values from the Variants header field that identify the representation it occurs within.  <ins> Each member of the list contains a set of selected available-value(s) that identify this representation, in the same order as the variants listed in the Variants header field. </ins>  <ins> Therefore, each member of Variant-Key MUST be the same length (in semicolon-separated members) as Variants, and each member's available-values MUST correspond in position to their companions in Variants. </ins> For example: This header pair indicates that the representation has a "gzip" content-coding and "fr" content-language.  <ins> If the response can be used to satisfy more than one request), they can be listed in additional members.  For example: </ins> indicates that this response can be used for requests whose Accept- Encoding algorithm selects "gzip" or "identity", as long as the Accept-Language algorithm selects "fr" - perhaps because there is no gzip-compressed French representation.  <ins> When more than one Variant-Key value is in a response, the first one present MUST indicate the variant-key for the response it occurs within. </ins> 3.1.
Original text:
Remove all whitespace from value. <del> Let items be the result of splitting value on ";". </del>  <del> append items to variant-keys. Return the result of running Compute Possible Keys (find) on variant-keys, an empty string and an empty list. </del>  4.

Reviewer comments:
For
from the list Maybe we should be talking about a Variant-Key syntax that lets you specify alternative sets of values, e.g.,

Revised text:
Remove all whitespace from value.  <ins> Append value to variant-keys. </ins>  <ins> Return variant-keys. </ins> 4.
Original text:
Let this-key be a copy of key-stub. <del> Append a comma (",") to this-key. </del>  Append value to this-key.

Reviewer comments:
For
from the list Maybe we should be talking about a Variant-Key syntax that lets you specify alternative sets of values, e.g.,

Revised text:
Let this-key be a copy of key-stub.  <ins> Append a semicolon (";") to this-key. </ins> Append value to this-key.
Original text:
both the two-octet Request-ID as well as at least 96 bits of additional entropy.  The TLS library on the authenticating peer will provide mechanisms to select an appropriate certificate to respond to the transported request.  TLS libraries on servers MUST be able to recognize the

Reviewer comments:
Takes a dependency on URL
I think that it would be better to explicitly reference CERTIFICATE_REQUEST in the cases where a CERTIFICATE is generated directly in response to one. Using the "get context" API from exported authenticators is ugly. This is more important now that exported authenticators folds the request into the response. We probably want to use a flag for whether this is spontaneous so that we can avoid reserving a Request-ID for spontaneous CERTIFICATE messages.
I'm a little dubious about this. Having the same value transported in two different fields and then checking that they're equal seems potentially more error-prone than just transporting it in one place, even if that one place is by calling into a library to interpret for you.
For posterity, discussion in Montreal: Nice not to have to dig out the Request-ID. However, if you duplicate it, then you have to compare and check that they're equal, so you're still calling into TLS. There is an existing duplication in the CERTIFICATE_REQUEST, where the Request-ID is carried outside the EA.

Revised text:
both the two-octet Request-ID as well as at least 96 bits of additional entropy. <ins> Upon receipt of a "CERTIFICATE_REQUEST" frame, the recipient MUST verify that the first two octets of the authenticator's "certificate_request_context" matches the Request-ID presented in the frame. </ins> The TLS library on the authenticating peer will provide mechanisms to select an appropriate certificate to respond to the transported request.  TLS libraries on servers MUST be able to recognize the
Original text:
Indicates that the exported authenticator spans more than one frame.  The frame contains the following fields: "Cert-ID" is a 16-bit opaque identifier used to correlate other certificate- related frames with this exported authenticator fragment.  A portion of the opaque data returned from the TLS connection exported authenticator "authenticate" API.  See exp-auth for more details on the input to this API.

Reviewer comments:
Takes a dependency on URL
I think that it would be better to explicitly reference CERTIFICATE_REQUEST in the cases where a CERTIFICATE is generated directly in response to one. Using the "get context" API from exported authenticators is ugly. This is more important now that exported authenticators folds the request into the response. We probably want to use a flag for whether this is spontaneous so that we can avoid reserving a Request-ID for spontaneous CERTIFICATE messages.
I'm a little dubious about this. Having the same value transported in two different fields and then checking that they're equal seems potentially more error-prone than just transporting it in one place, even if that one place is by calling into a library to interpret for you.
For posterity, discussion in Montreal: Nice not to have to dig out the Request-ID. However, if you duplicate it, then you have to compare and check that they're equal, so you're still calling into TLS. There is an existing duplication in the CERTIFICATE_REQUEST, where the Request-ID is carried outside the EA.

Revised text:
Indicates that the exported authenticator spans more than one frame. <ins> Indicates that the exported authenticator does not contain a Request-ID. </ins> The frame contains the following fields: "Cert-ID" is a 16-bit opaque identifier used to correlate other certificate- related frames with this exported authenticator fragment. <ins> "Request-ID" is an optional 16-bit opaque identifier used to correlate this exported authenticator with the request which triggered it, if any.  This field is present only if the "UNSOLICITED" flag is not set. </ins> A portion of the opaque data returned from the TLS connection exported authenticator "authenticate" API.  See exp-auth for more details on the input to this API.
Original text:
frame with "TO_BE_CONTINUED" unset MUST be treated as a connection error of type "PROTOCOL_ERROR".  Upon receiving a complete series of "CERTIFICATE" frames, the receiver may validate the Exported Authenticator value by using the exported authenticator API.  This returns either an error indicating

Reviewer comments:
Takes a dependency on URL
I think that it would be better to explicitly reference CERTIFICATE_REQUEST in the cases where a CERTIFICATE is generated directly in response to one. Using the "get context" API from exported authenticators is ugly. This is more important now that exported authenticators folds the request into the response. We probably want to use a flag for whether this is spontaneous so that we can avoid reserving a Request-ID for spontaneous CERTIFICATE messages.
I'm a little dubious about this. Having the same value transported in two different fields and then checking that they're equal seems potentially more error-prone than just transporting it in one place, even if that one place is by calling into a library to interpret for you.
For posterity, discussion in Montreal: Nice not to have to dig out the Request-ID. However, if you duplicate it, then you have to compare and check that they're equal, so you're still calling into TLS. There is an existing duplication in the CERTIFICATE_REQUEST, where the Request-ID is carried outside the EA.

Revised text:
frame with "TO_BE_CONTINUED" unset MUST be treated as a connection error of type "PROTOCOL_ERROR". <ins> If the "UNSOLICITED" flag is not set, the "CERTIFICATE" frame also contains a Request-ID indicating the certificate request which caused this exported authenticator to be generated.  The value of this flag and the contents of the Request-ID field MUST NOT differ between frames with the same Cert-ID. </ins> Upon receiving a complete series of "CERTIFICATE" frames, the receiver may validate the Exported Authenticator value by using the exported authenticator API.  This returns either an error indicating
Original text:
Upon receipt of a "CERTIFICATE" frame, an endpoint MUST perform the following steps to validate the token it contains:  Using the "get context" API, retrieve the "certificate_request_context" used to generate the authenticator, <del> if any. Verify that the "certificate_request_context" is either empty (clients only) or contains the Request-ID of a previously-sent "CERTIFICATE_REQUEST" frame. </del>  Use the "validate" API to confirm the validity of the authenticator with regard to the generated request (if any).

Reviewer comments:
Takes a dependency on URL
I think that it would be better to explicitly reference CERTIFICATE_REQUEST in the cases where a CERTIFICATE is generated directly in response to one. Using the "get context" API from exported authenticators is ugly. This is more important now that exported authenticators folds the request into the response. We probably want to use a flag for whether this is spontaneous so that we can avoid reserving a Request-ID for spontaneous CERTIFICATE messages.
I'm a little dubious about this. Having the same value transported in two different fields and then checking that they're equal seems potentially more error-prone than just transporting it in one place, even if that one place is by calling into a library to interpret for you.
For posterity, discussion in Montreal: Nice not to have to dig out the Request-ID. However, if you duplicate it, then you have to compare and check that they're equal, so you're still calling into TLS. There is an existing duplication in the CERTIFICATE_REQUEST, where the Request-ID is carried outside the EA.

Revised text:
Upon receipt of a "CERTIFICATE" frame, an endpoint MUST perform the following steps to validate the token it contains: <ins> Verify that either the "UNSOLICITED" flag is set (clients only) or that the Request-ID field contains the Request-ID of a previously- sent "CERTIFICATE_REQUEST" frame. </ins> Using the "get context" API, retrieve the "certificate_request_context" used to generate the authenticator,  <ins> if any.  Verify that the "certificate_request_context" begins with the supplied Request-ID, if any. </ins> Use the "validate" API to confirm the validity of the authenticator with regard to the generated request (if any).
Original text:
6.4.  Implementations need to be aware of the potential for confusion about the state of a connection.  The presence or absence of a validated certificate can change during the processing of a request,

Reviewer comments:
but I'd prefer a better recommendation here than "educate your customers."
Suppose a site is hosted on a particular provider (or CDN, equally). The customer flips the DNS entry to point to a new provider. However, the old provider doesn't know that and might continue to serve traffic via ORIGIN + Secondary Certificates for requests that originally reach the provider via other DNS records. It's current industry practice to leave the old provider configured and hot during a transition to ensure the graceful cutover. However, the DNS record change is considered to be sufficent. We might want to recommend that servers periodically ensure the DNS record points to them before serving Secondary Certificates / ORIGIN references. I think this is Security Considerations prose, not protocol elements or requirements, however.

Revised text:
6.4. <ins> CNAME records in the DNS are frequently used to delegate authority for an origin to a third-party provider.  This delegation can be changed without notice, even to the third-party provider, simply by modifying the CNAME record in question. After the owner of the domain has redirected traffic elsewhere by changing the CNAME, new connections will not arrive for that origin, but connections which are properly directed to this provider for other origins would continue to claim control of this origin (via ORIGIN frame and Secondary Certificates).  This is proper behavior based on the third-party provider's configuration, but would likely not be what is intended by the owner of the origin. This is not an issue which can be mitigated by the protocol, but something about which third-party providers SHOULD educate their customers before using the features described in this document. 6.5. </ins> Implementations need to be aware of the potential for confusion about the state of a connection.  The presence or absence of a validated certificate can change during the processing of a request,
Original text:
For each member mem of input: <del> Let name be the result of applying Serialising an Identifier (ser-identifier) to mem's member-name. </del>  Append name to output. Append "=" to output. <del> Let value be the result of applying Serialising a Key (ser-key) to mem's member-value. </del>  Append value to output.

Reviewer comments:
Serialisation of dictionary and param-list currently say instead of This fixes that.
Blah, good catch; thanks.

Revised text:
For each member mem of input:  <ins> Let name be the result of applying Serialising an Key (ser-key) to mem's member-name. </ins> Append name to output. Append "=" to output.  <ins> Let value be the result of applying Serialising an Item (ser- item) to mem's member-value. </ins> Append value to output.
Original text:
Append ";" to output. <del> Let name be the result of applying Serialising an Identifier (ser-identifier) to parameter's param-name. </del>  Append name to output. If parameter has a param-value: <del> Let value be the result of applying Serialising a Key (ser-key) to parameter's param-value. </del>  Append "=" to output.

Reviewer comments:
Serialisation of dictionary and param-list currently say instead of This fixes that.
Blah, good catch; thanks.

Revised text:
Append ";" to output.  <ins> Let name be the result of applying Serialising a Key (ser- key) to parameter's param-name. </ins> Append name to output. If parameter has a param-value:  <ins> Let value be the result of applying Serialising an Item (ser-item) to parameter's param-value. </ins> Append "=" to output.