jiebi/TextFlow huggingface dataset:
Original text:
figterm3 shows an example message flow where the EAP-TLS server authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer <del> fails to authenticate to the EAP-TLS server and sends a TLS Error alert. </del>  2.1.5.

Reviewer comments:
URL
I added "604800 seconds" as suggested by Oleg. Joe suggested "Perhaps both of these should be left to the TLS spec." I would agree with this.... Thanks Joe, one comment regarding item is inline below. Joseph Salowey wrote: [Oleg] Got it. Then maybe it is worth specifying 604800 seconds in the section "5.7. Resumption" also so it will be clear that the requirement in this section is the same strict as in "2.1.2. Ticket Establishment".

Revised text:
figterm3 shows an example message flow where the EAP-TLS server authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer  <ins> fails to authenticate to the EAP-TLS server and the server sends a TLS Error alert. </ins> 2.1.5.
Original text:
accounting. As suggested in RFC8446, EAP-TLS peers MUST NOT store resumption PSKs <del> or tickets (and associated cached data) for longer than 7 days, regardless of the PSK or ticket lifetime.  The EAP-TLS peer MAY delete them earlier based on local policy.  The cached data MAY also be removed on the EAP-TLS server or EAP-TLS peer if any certificate in the certificate chain has been revoked or has expired.  In all such cases, an attempt at resumption results in a full TLS handshake instead. </del>  Information from the EAP-TLS exchange (e.g., the identity provided in EAP-Response/Identity) as well as non-EAP information (e.g., IP

Reviewer comments:
URL
I added "604800 seconds" as suggested by Oleg. Joe suggested "Perhaps both of these should be left to the TLS spec." I would agree with this.... Thanks Joe, one comment regarding item is inline below. Joseph Salowey wrote: [Oleg] Got it. Then maybe it is worth specifying 604800 seconds in the section "5.7. Resumption" also so it will be clear that the requirement in this section is the same strict as in "2.1.2. Ticket Establishment".

Revised text:
accounting. As suggested in RFC8446, EAP-TLS peers MUST NOT store resumption PSKs  <ins> or tickets (and associated cached data) for longer than 604800 seconds (7 days), regardless of the PSK or ticket lifetime.  The EAP- TLS peer MAY delete them earlier based on local policy.  The cached data MAY also be removed on the EAP-TLS server or EAP-TLS peer if any certificate in the certificate chain has been revoked or has expired. In all such cases, an attempt at resumption results in a full TLS handshake instead. </ins> Information from the EAP-TLS exchange (e.g., the identity provided in EAP-Response/Identity) as well as non-EAP information (e.g., IP
Original text:
only if that object has a member with that name.  Nothing is selected from a value that is not a object. <del> Array indexing via "element-index" is a way of selecting a particular array element using a zero-based index.  For example, selector "[0]" selects the first and selector "[4]" the fifth element of a sufficiently long array. </del>  A negative "element-index" counts from the array end.  For example, selector "[-1]" selects the last and selector "[-2]" selects the

Reviewer comments:
The index selector (but not the index wildcard selector) selects no elements from non-arrays. See URL for background.
This seems implicit since JSON objects cannot be numerically accessed.
Yes, but making it explicit is clearer.
This looks okay, and it aligns the text with the previous paragraph.

Revised text:
only if that object has a member with that name.  Nothing is selected from a value that is not a object.  <ins> The "index-selector" applied with an "element-index" to an array selects an array element using a zero-based index.  For example, selector "[0]" selects the first and selector "[4]" the fifth element of a sufficiently long array.  Nothing is selected, and it is not an error, if the index lies outside the range of the array.  Nothing is selected from a value that is not an array. </ins> A negative "element-index" counts from the array end.  For example, selector "[-1]" selects the last and selector "[-2]" selects the
Original text:
of the selector entries in the list and yields the concatenation of the lists (in the order of the selector entries) of nodes selected by the selector entries.  Note that any node selected in more than one <del> of the selector entries is kept as many times in the node list. </del>  To be valid, integer values in the "element-index" and "slice-index" components MUST be in the I-JSON range of exact values, see synsem-

Reviewer comments:
The index selector (but not the index wildcard selector) selects no elements from non-arrays. See URL for background.
This seems implicit since JSON objects cannot be numerically accessed.
Yes, but making it explicit is clearer.
This looks okay, and it aligns the text with the previous paragraph.

Revised text:
of the selector entries in the list and yields the concatenation of the lists (in the order of the selector entries) of nodes selected by the selector entries.  Note that any node selected in more than one  <ins> of the selector entries is kept as many times in the nodelist. </ins> To be valid, integer values in the "element-index" and "slice-index" components MUST be in the I-JSON range of exact values, see synsem-
Original text:
A syntactically valid segment MUST NOT produce errors when executing the query.  This means that some operations that might be considered <del> erroneous, such as indexing beyond the end of an array, simply result in fewer nodes being selected. </del>  Consider this example.  With the argument "{"a":[{"b":0},{"b":1},{"c":2}]}", the query "$.a[*].b" selects the

Reviewer comments:
Avoid the term indexing, so we don't need to worry about whether it applies only to arrays or to arrays and objects.

Revised text:
A syntactically valid segment MUST NOT produce errors when executing the query.  This means that some operations that might be considered  <ins> erroneous, such as using an index lying outside the range of an array, simply result in fewer nodes being selected. </ins> Consider this example.  With the argument "{"a":[{"b":0},{"b":1},{"c":2}]}", the query "$.a[*].b" selects the
Original text:
2.5.3.2. <del> The "index-selector" applied to an array selects an array element using a zero-based index.  For example, the selector "0" selects the first and the selector "4" selects the fifth element of a </del>  sufficiently long array.  Nothing is selected, and it is not an error, if the index lies outside the range of the array.  Nothing is selected from a value that is not an array.

Reviewer comments:
Avoid the term indexing, so we don't need to worry about whether it applies only to arrays or to arrays and objects.

Revised text:
2.5.3.2.  <ins> A non-negative "index-selector" applied to an array selects an array element using a zero-based index.  For example, the selector "0" selects the first and the selector "4" selects the fifth element of a </ins> sufficiently long array.  Nothing is selected, and it is not an error, if the index lies outside the range of the array.  Nothing is selected from a value that is not an array.
Original text:
as slice bounds and must first be normalized.  Normalization for this purpose is defined as: <del> The result of the array indexing expression "i" applied to an array of length "len" is defined to be the result of the array slicing </del>  expression "Normalize(i, len):Normalize(i, len)+1:1". Slice expression parameters "start" and "end" are used to derive

Reviewer comments:
Avoid the term indexing, so we don't need to worry about whether it applies only to arrays or to arrays and objects.

Revised text:
as slice bounds and must first be normalized.  Normalization for this purpose is defined as:  <ins> The result of the array index expression "i" applied to an array of length "len" is defined to be the result of the array slicing </ins> expression "Normalize(i, len):Normalize(i, len)+1:1". Slice expression parameters "start" and "end" are used to derive
Original text:
the lower bound and which is the upper bound: The slice expression selects elements with indices between the lower <del> and upper bounds.  In the following pseudocode, the "a(i)" construct expresses the 0-based indexing operation on the underlying array. </del>  When "step = 0", no elements are selected and the result array is empty.

Reviewer comments:
Avoid the term indexing, so we don't need to worry about whether it applies only to arrays or to arrays and objects.

Revised text:
the lower bound and which is the upper bound: The slice expression selects elements with indices between the lower  <ins> and upper bounds.  In the following pseudocode, "a(i)" is the "i+1"th element of the array "a" (i.e., "a(0)" is the first element, "a(1)" the second, and so forth). </ins> When "step = 0", no elements are selected and the result array is empty.
Original text:
.  A string is a well-formed JSONPath query if it conforms to the ABNF syntax in this document.  A well-formed JSONPath query is valid <del> if it also fulfills all semantic requirements posed by this document. </del>  <del> To be valid, integer numbers in the JSONPath query that are relevant to the JSONPath processing (e.g., index values and steps) MUST be within the range of exact values defined in I-JSON RFC7493, namely within the interval [-(2 </del>  <del> )+1, (2 </del>  <del> )-1]). </del>  <del> To be valid, strings on the right-hand side of the "=~" regex matching operator need to conform to I-D.draft-ietf-jsonpath-iregexp. </del>  The well-formedness and the validity of JSONPath queries are independent of the JSON value the query is applied to; no further

Reviewer comments:
I like this structure. We might come up with more validity requirements, so we may want to keep this even if =~ goes away (which is pretty much what we decided last week).

Revised text:
.  A string is a well-formed JSONPath query if it conforms to the ABNF syntax in this document.  A well-formed JSONPath query is valid  <ins> if it also fulfills all semantic requirements posed by this document, which are: </ins>  <ins> Integer numbers in the JSONPath query that are relevant to the JSONPath processing (e.g., index values and steps) MUST be within the range of exact values defined in I-JSON RFC7493, namely within the interval [-(2 </ins>  <ins> )+1, (2 </ins>  <ins> )-1]. </ins>  <ins> Strings on the right-hand side of the "=~" regex matching operator MUST conform to I-D.draft-ietf-jsonpath-iregexp. </ins> The well-formedness and the validity of JSONPath queries are independent of the JSON value the query is applied to; no further
Original text:
Note: "double-quoted" strings follow the JSON string syntax (RFC8259); "single-quoted" strings follow an analogous pattern <del> (syntax-index). </del>  2.5.1.2.

Reviewer comments:
Add pair of surrogate escapes to note on string format.
LGTM, thanks. Just one editorial suggestion.

Revised text:
Note: "double-quoted" strings follow the JSON string syntax (RFC8259); "single-quoted" strings follow an analogous pattern  <ins> (syntax-index).  No attempt was made to improve on this syntax, so characters with scalar values above 0x10000, such as U+0026 U+0023 U+0031 U+0032 U+0039 U+0033 U+0030 U+0030 U+003B ("&#129300;", AMPERSAND, NUMBER SIGN, DIGIT ONE, DIGIT TWO, DIGIT NINE, DIGIT THREE, DIGIT ZERO, DIGIT ZERO, SEMICOLON), need to be represented by a pair of surrogate escapes (""uD83EuDD14"" in this case). </ins> 2.5.1.2.
Original text:
A function argument is a "filter-path" or a "comparable". <del> According to filter-selector, a "function-expression" is valid as a </del>  "filter-path" or a "comparable". Any function expressions in a query must be well-formed (by

Reviewer comments:
E.g.,
I propose a slightly more compact naming of ABNF of - and -segment, which should be more consistent between them two. is well known from LaTeX and means or there.
above is wrong (and so it is in the current spec). It needs to read ... to not allow triple dot ( :-)
NAME Wouldn't dotdot-wildcard etc. be less cryptic?
Here are some quibbles with the current ABNF (prior to PR being merged) which we can sort out after The Great Renaming:
Yes, yes. See. Fixed in I like the way this looks like now. Maybe I don't understand; can you elaborate? Fixed this (and following) in Removed in To be fixed in overall overhaul, next Yes! To be fixed in overall overhaul, next To be fixed in overall overhaul, next Fixed in Discuss this in its own issue, I'd say. Fixed in It certainly does not -- it is the subset that is actually needed for normalized paths. To stay normalized, we don't allow random other ones.
Of course ... I'm quite dispassionate here.
Please see my proposal in
With merged, we still have the expression cleanup the separate issue (enhancement) whether should be allowed, to mean
My remaining points are covered by PRs , , and .
Shouldn't be named according to all other above ?
Yes, I agree. See URL
NAME Are we ready to close this issue now the PRs have been merged or did you have more expression cleanup in mind?
The only thing that comes to my mind is standardizing on the column where the is -- this is currently rather chaotic. But that can be a new issue.
Indentation of : number of lines such indented
(And it doesn't need to be consistent, just a bit less chaotic.)
Let's make the a new issue. (I haven't got a good feel for the optimal solution.)
Before we close this issue, URL slipped through the net in my earlier PRs.
Then could resolve to either or . We would introduce an ambiguity, we already found with Json Pointer () ...
OK, with the latest blank space realignments that are part of (5e2cc85), I think we are done with this.
Thank you! ... or do we need two selectors here (Ch.2.61) child-longhand = "[" S selector 1(S "," S selector) S "]" given that '1' means 'at least one'.

Revised text:
A function argument is a "filter-path" or a "comparable".  <ins> According to filter-selector, a "function-expr" is valid as a </ins> "filter-path" or a "comparable". Any function expressions in a query must be well-formed (by
Original text:
primitive values (that is, numbers, strings, "true", "false", and "null").  These can be obtained via literal values; Singular Queries, each of which selects at most one node the value of which is then <del> used; and function expressions (see fnex) of type "ValueType" or "NodesType" (see type-conv). </del>  Literals can be notated in the way that is usual for JSON (with the extension that strings can use single-quote delimiters).  Alphabetic

Reviewer comments:
Thanks to NAME for spotting this.
NAME I presume you are ok with this change, so I'm going to merge it. Any concern, let me know and we can adjust the result.
Yes. Just didn't have chance to check this in context, but if I remember this properly, this change is good (and necessary).

Revised text:
primitive values (that is, numbers, strings, "true", "false", and "null").  These can be obtained via literal values; Singular Queries, each of which selects at most one node the value of which is then  <ins> used; and function expressions (see fnex) of type "ValueType". </ins> Literals can be notated in the way that is usual for JSON (with the extension that strings can use single-quote delimiters).  Alphabetic
Original text:
applies) "NodesType". If it occurs directly as a "comparable" in a comparison, the <del> function is declared to have a result type of "ValueType", or (conversion applies) "NodesType". </del>  Otherwise, it occurs as an argument in another function expression, and the following rules for function arguments apply

Reviewer comments:
Thanks to NAME for spotting this.
NAME I presume you are ok with this change, so I'm going to merge it. Any concern, let me know and we can adjust the result.
Yes. Just didn't have chance to check this in context, but if I remember this properly, this change is good (and necessary).

Revised text:
applies) "NodesType". If it occurs directly as a "comparable" in a comparison, the  <ins> function is declared to have a result type of "ValueType". </ins> Otherwise, it occurs as an argument in another function expression, and the following rules for function arguments apply
Original text:
these are used to define "!=", "<=", ">", and ">=". When either side of a comparison results in an empty nodelist or <del> "Nothing": </del>  a comparison using the operator "==" yields true if and only the other side also results in an empty nodelist or "Nothing".

Reviewer comments:
NAME Deleting the text should have addressed your original editorial issue. This PR also adds the missing cross-reference. If you're happy, please approve.

Revised text:
these are used to define "!=", "<=", ">", and ">=". When either side of a comparison results in an empty nodelist or  <ins> "Nothing" (see typesys): </ins> a comparison using the operator "==" yields true if and only the other side also results in an empty nodelist or "Nothing".
Original text:
first string compares less than the remainder of the second string. <del> Note that comparisons using the operator "<" yield false if either value being compared is an object, array, boolean, or "null". </del> "!=", "<=", ">", and ">=" are defined in terms of the other comparison operators.  For any "a" and "b":

Reviewer comments:
NAME Deleting the text should have addressed your original editorial issue. This PR also adds the missing cross-reference. If you're happy, please approve.

Revised text:
first string compares less than the remainder of the second string.  "!=", "<=", ">", and ">=" are defined in terms of the other comparison operators.  For any "a" and "b":
Original text:
Clients are configured to use IP proxying over HTTP via an URI Template TEMPLATE.  The URI template MAY contain two variables: <del> "target" and "ipproto" (scope).  The optionality of the variables </del>  needs to be considered when defining the template so that either the variable is self-identifying or it is possible to exclude it in the syntax.

Reviewer comments:
I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.

Revised text:
Clients are configured to use IP proxying over HTTP via an URI Template TEMPLATE.  The URI template MAY contain two variables:  <ins> "target" and "ipproto"; see scope.  The optionality of the variables </ins> needs to be considered when defining the template so that either the variable is self-identifying or it is possible to exclude it in the syntax.
Original text:
tunnel due to a period of inactivity, but they MUST close the request stream when doing so.  Along with a successful response, the IP proxy can send capsules to assign addresses and advertise routes to the client (capsules).  The client can also assign addresses and advertise routes to the IP proxy for network-to-network routing. <del> By virtue of the definition of the Capsule Protocol (see HTTP-DGRAM), IP proxying requests do not carry any message content.  Similarly, successful IP proxying responses also do not carry any message content. 4.1. </del>  When using HTTP/1.1 H1, an IP proxying request will meet the following requirements:

Reviewer comments:
I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.

Revised text:
tunnel due to a period of inactivity, but they MUST close the request stream when doing so. <ins> A successful response (as defined in Sections resp1 and resp23) indicates that the IP proxy has established an IP tunnel and is willing to proxy IP payloads.  Any response other than a successful response indicates that the request has failed; thus, the client MUST abort the request. </ins> Along with a successful response, the IP proxy can send capsules to assign addresses and advertise routes to the client (capsules).  The client can also assign addresses and advertise routes to the IP proxy for network-to-network routing.  <ins> 4.2. </ins> When using HTTP/1.1 H1, an IP proxying request will meet the following requirements:
Original text:
wishes to open an IP forwarding tunnel with no target or protocol limitations, it could send the following request: <del> 4.2. </del>  The IP proxy indicates a successful response by replying with the following requirements:

Reviewer comments:
I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.

Revised text:
wishes to open an IP forwarding tunnel with no target or protocol limitations, it could send the following request:  <ins> 4.3. </ins> The IP proxy indicates a successful response by replying with the following requirements: