jiebi/TextFlow huggingface dataset:
Original text:
<del> Using EAP-TLS with TLS 1.3 </del>  draft-ietf-emu-eap-tls13-latest Abstract Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS.  TLS 1.3 provides significantly improved security, privacy, and reduced latency when <del> compared to earlier versions of TLS.  EAP-TLS with TLS 1.3 further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking.  This document also provides guidance on </del>  authorization and resumption for EAP-TLS in general (regardless of the underlying TLS version used).  This document updates RFC 5216.

Reviewer comments:
I see that "EAP-TLS 1.3" is used more an more in the discussions to refer to this the combination of EAP-TLS and TLS 1.3. The term is used in the document but not in the title and abstract
Hi John, Please run this title change by the list.
Looking at this it seems that this change is simpler than I originally thought. This looks OK to merge

Revised text:
 <ins> Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3) </ins> draft-ietf-emu-eap-tls13-latest Abstract Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS.  TLS 1.3 provides significantly improved security, privacy, and reduced latency when  <ins> compared to earlier versions of TLS.  EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking.  This document also provides guidance on </ins> authorization and resumption for EAP-TLS in general (regardless of the underlying TLS version used).  This document updates RFC 5216.
Original text:
stapling, and TLS 1.3 introduces more possibilities to reduce fragmentation when compared to earlier versions of TLS.  1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", for the entity acting as EAP peer and TLS client.  The term EAP-TLS server is used for the entity acting as EAP server and TLS server.  2. 2.1.

Reviewer comments:
While reading draft-ietf-emu-eap-tls13-15 I noticed that section now uses which is the named used in but not in RFC 8446 itself. I first thought this was a typo, before a further look showed that this change was mentioned in IETF 110 . Suggestion: make clear which parts need to be looked up from RFC 8446bis. In addition to exporter terminology, the meeting slides above also discuss about usercancelled behavior on slide 10. For clarity, any updates from RFC 8446bis should be marked clearly.
It would be best not to have normative references that block on RFC 8446bis. Perhaps we can just reference that it is renamed from "exportermastersecret"
Sounds good. That should make clear where it comes from and that there's no need to file errata about unknown term and/or RFC 8446bis dependency. Taking another look at my comment about usercancelled behavior on slide 10; to clarify what I was meaning: The slides hint that clarifications in 8446bis are needed by EAP-TLS too. If so, this looks like a reference to RFC 8446bis too. Finally, one nit: the alert name in RFC 8446 is "usercanceled", not "user_cancelled" as in draft -15.
I made a PR with explaining that the document use the terminology from RFC8446bis. URL Do we need to say anything about usercancelled? RFC8446bis might do several clarifications and corrections. I think we should only mention things that are directly relevant for EAP-TLS 1.3 URL Current plan for RFC8446bis seems to be to ignore closenotify and I assume require close_notify after. This does not seem directly relevant for EAP-TLS 1.3. Or?
close issue?
Yes, please close this. I think it's now clear where exportersecret comes from. Also, thanks for the pointer to TLSv1.3 discussion. I agree usercanceled followed by close_notify discussion is not relevant for EAP-TLS 1.3. It's seems to be TLSv1.3 specification and implementation level detail as opposed to something that EAP-TLS 1.3 needs to directly react on.

Revised text:
stapling, and TLS 1.3 introduces more possibilities to reduce fragmentation when compared to earlier versions of TLS. <ins> This document follows the terminology from I-D.ietf-tls-rfc8446bis where the master secret is renamed to the main secret and the exporter_master_secret is renamed to the exporter_secret. </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", for the entity acting as EAP peer and TLS client.  The term EAP-TLS server is used for the entity acting as EAP server and TLS server. <ins> Readers are expected to be familiar with the terms and concepts used in EAP-TLS RFC5216 and TLS RFC8446.  The term EAP-TLS peer is used for the entity acting as EAP peer and TLS client.  The term EAP-TLS server is used for the entity acting as EAP server and TLS server. </ins> 2. 2.1.
Original text:
a minimum) the GitHub account of the user so that their contributions could be tracked more easily.  3.2. IETF working group mailing lists are automatically backed up by the

Reviewer comments:
The document currently assumes that there is one document per repository. That's not always the best structure. It's not uncommon for there to be tight clusters of related documents. QUIC does this (even though it is likely an outlier in the process), but there are also frequent occasions where working groups develop overview documents along with a protocol, or split a document into separate logical pieces (tokbind did this for TLS bits and HTTP bits). URL is something of a train wreck, but there is plenty of middle-ground here.

Revised text:
a minimum) the GitHub account of the user so that their contributions could be tracked more easily. <ins> Some working groups choose to have more than one draft in a repository, particularly for drafts that are tightly linked with significant cross-references.  In such a case, the README for the repository needs to say that clearly so that a participant understands that changes might be made to multiple drafts at once. </ins> 3.2. IETF working group mailing lists are automatically backed up by the
Original text:
JSONPath query, e.g., because of resource depletion, but this is not modeled in the present specification.) <del> Discussion (D1): are we ready for the error model defined here, i.e. one that does not have runtime errors, but only compile time errors? </del> 3.2. In this specification, the semantics of a JSONPath query are defined

Reviewer comments:
Here's a chance to actually have the discussion if anyone wants to.
Well, I'm certainly ready for this model.
I'm good with the approach described in the text. As long as a string can be parsed as a Path, it should evaluate. I can't see a case where processing a valid path against a value would produce an error; merely empty result sets. This means that the only errors should be syntax errors, correct?
I think so.
May I encourage reviewers who are in favour of this PR to approve it?
I was awaiting a bit more discussion.
Ok, I've requested a review from Stefan.
Yes absolutely ... I like that clean concept a lot.

Revised text:
JSONPath query, e.g., because of resource depletion, but this is not modeled in the present specification.)  3.2. In this specification, the semantics of a JSONPath query are defined
Original text:
For each node in the list, the selector selects zero or more nodes, each of which is a descendant of the node or the node itself. <del> Discussion (D4): Is that a common requirement?  Or can a selector also go up, or to the query argument? </del> For instance, with the argument "{"a":[{"b":0},{"b":1},{"c":2}]}", the query "$.a[*].b" selects the following list of nodes: "0", "1" (denoted here by their value).  Let's walk through this in detail.

Reviewer comments:
Here's a chance to actually have the discussion if anyone wants to.
One related question is whether the selector can use $ internally (still returning nodes within the current node).
I am in favour of supporting inside filter expressions as a way to access the root node of the argument, but I don't think that should block this PR as the context of the discussion seems to be which nodes are selected. As you point out, using in a filter expression doesn't select the root node - it selects nodes within the current node as usual.
I agree. Paths like should be allowed, but wouldn't select anything that is not a descendent of . Here the provides a basis for comparison used to select the current node in the iteration. I see no value (for an initial release anyway) in allowing selection of ancestor nodes. If a use case and syntax for it are later defined, I'm happy to release that as a follow-up version.
yes ... using in a logical expression is valid and does no harm.
NAME yes, but the issue at hand here is whether there is a mechanism that can select ancestor or cousin nodes. I think we're in agreement that that there is no such mechanism.
Indeed, we seem to be in agreement.

Revised text:
For each node in the list, the selector selects zero or more nodes, each of which is a descendant of the node or the node itself.  For instance, with the argument "{"a":[{"b":0},{"b":1},{"c":2}]}", the query "$.a[*].b" selects the following list of nodes: "0", "1" (denoted here by their value).  Let's walk through this in detail.
Original text:
member name ""a"".  The result is again a list of one node: "[{"b":0},{"b":1},{"c":2}]". <del> Next, "[*]" selects from any input node which is an array and selects all the elements of the input node.  The result is a list of three </del>  nodes: "{"b":0}", "{"b":1}", and "{"c":2}". Finally, ".b" selects from any input node of type object with a

Reviewer comments:
... and some minor edits ...
Indeed. I'll do a small PR with my points.
a little late to the party ... thanks
[ ] define a production , replacing [ ] go through ABNF and make sure blank space is allowed where it needs to be (Do not use the term "whitespace" any more.) Task "T1" in the document URL
and
From the document: (whitespace is now generally called blank space, but that doesn't change the work to be done.)
and
How much do we want to reference XPath within the spec? I understand that XPath is the inspiration (and in the tagline that NAME used in his blog post: "XPath for JSON"), but I wonder if much of this can be left out of the spec. The argument for this is that we're defining JSONPath. It shouldn't assume any understanding of XPath or any other technology. It's not the job of the specification to convince readers to use it. It's the job of the specification to define the technology. I'm perfectly happy moving this into an external "Understanding JSONPath" website at some point.
I seem to remember that last time we discussed this we agreed to move the introductory comparison with XPath to an appendix, with the possible exception of the overview table (but that could be duplicated).
The XPath inclusion was moved into an appendix.
Do we allow spaces (outside of string literals)? If so, where is whitespace allowed? I think whitespace in query expressions should be allowed. This would fall in to the context of the . Maybe inside the union/ selector: Are there any other places where whitespace could be considered useful?
It may be convenient to allow spaces between matchers - to allow well-readable multi-line queries for complex cases.
Looks like the allows whitespace internally, so that (with leading and trailing whitespace) is valid.
Closed in and
What was the resolution here? Where did we end up allowing whitespace?
This PR could be merged to make progress. Further changes as indicated by NAME are probably needed, either now or in a subsequent PR.

Revised text:
member name ""a"".  The result is again a list of one node: "[{"b":0},{"b":1},{"c":2}]".  <ins> Next, "[*]" selects from any input node -- either an array or an object -- all its elements or members.  The result is a list of three </ins> nodes: "{"b":0}", "{"b":1}", and "{"c":2}". Finally, ".b" selects from any input node of type object with a
Original text:
dated 2007-02-21 JSONPath-orig and provides a normative definition for it. <del> inspired-by-xpath provides a brief synopsis with XML's XPath XPath, which was the inspiration that led to the definition of JSONPath. </del>  JSONPath was intended as a light-weight companion to JSON implementations on platforms such as PHP and JavaScript, so instead The examples in tbl-example use the expression mechanism to obtain the number of elements in an array, to test for the presence of a member in a object, and to perform numeric comparisons of member <del> values with a constant.  For further illustration, the table shows XPath expressions that would be used with a comparable XML document; see also xpath-overview. </del>  3.

Reviewer comments:
XPath details are a distraction in the body of the spec. In the future, readers are increasingly likely to come to this spec with no exposure to XPath or, for that matter, XML.
Looks very good, with the one nit. Thanks!

Revised text:
dated 2007-02-21 JSONPath-orig and provides a normative definition for it.  <ins> inspired-by-xpath describes how JSONPath was inspired by XML's XPath XPath. </ins> JSONPath was intended as a light-weight companion to JSON implementations on platforms such as PHP and JavaScript, so instead The examples in tbl-example use the expression mechanism to obtain the number of elements in an array, to test for the presence of a member in a object, and to perform numeric comparisons of member  <ins> values with a constant. </ins> 3.
Original text:
expressions between the ensuing platform-specific dialects. The present specification intends to remove platform dependencies and <del> server as a common JSONPath specification that can be used across </del>  platforms.  Obviously, this means that backwards compatibility could not always be achieved; a design principle of this specification is to go with a "consensus" between implementations even if it is rough, start position, an end position, and possibly a step value that moves the position from the start to the end (slice). <del> JSONPath employs an for computing values and making decisions.  The present specification defines a simple expression language that is independent from any scripting language in use on the platform.  JSONPath can use such expression language expressions, written in parentheses: "(<expr>)", as an alternative to explicit names or indices as in [no-dot-length]: The symbol "@" is used for the current node, i.e., the node in the context of which the expression is evaluated. </del> Filter expressions are supported via the syntax "?(<boolean expr>)" as in 4. <del> 5. </del> TBD: Define a media type for JSONPath expressions. <del> 6. </del>  This section gives security considerations, as required by RFC3552. isolating a single location within a JSON document.  Path is a query syntax that can also be used to pull multiple locations. <del> [no-dot-length] We probably want to use an expression that does not use </del>

Reviewer comments:
There does not seem to be an appetite for doing the necessary spec work. This PR will test that assertion. Filter expressions are still supported, but not "container expressions", of the form [(...)].
I think this can be added later, similar to the consensus for . Personally I still see value in having it.

Revised text:
expressions between the ensuing platform-specific dialects. The present specification intends to remove platform dependencies and  <ins> serve as a common JSONPath specification that can be used across </ins> platforms.  Obviously, this means that backwards compatibility could not always be achieved; a design principle of this specification is to go with a "consensus" between implementations even if it is rough, start position, an end position, and possibly a step value that moves the position from the start to the end (slice).  Filter expressions are supported via the syntax "?(<boolean expr>)" as in 4.  TBD: Define a media type for JSONPath expressions.  <ins> 5. </ins> This section gives security considerations, as required by RFC3552. isolating a single location within a JSON document.  Path is a query syntax that can also be used to pull multiple locations.
Original text:
Regular expression tests can be applied to "string" values only.  The following table lists filter expression operators in order of precedence from highest (binds most tightly) to lowest (binds least tightly).

Reviewer comments:
Thanks, the rebase looks good.
NAME After merging some PRs I fixed a conflict here and then added a commit. PTAL and merge if you are happy.

Revised text:
Regular expression tests can be applied to "string" values only. <ins> Alphabetic characters in ABNF are case-insensitive, so "e" can be either "e" or "E". false, null, true are lower-case only (case-sensitive). </ins> The following table lists filter expression operators in order of precedence from highest (binds most tightly) to lowest (binds least tightly).
Original text:
4. <del> TBD: Define a media type for JSONPath expressions. </del>  5.

Reviewer comments:
I merged this so once we have published an I-D with this change in it we can initiate the necessary review on the media-types list.
Looks plausible.

Revised text:
4.  <ins> 4.1. IANA is requested to register the following media type RFC6838: Person & email address to contact for further information: iesg@ietf.org </ins> 5.
Original text:
Note: This ordering of the results for the "$..[*]" and "$..*" examples above is not guaranteed, except that: <del> "{o: {"j": 1, "k": 2}, a: [5, 3]}" must appear before "{"j": 1, "k": 2}" and "[5, 3]", </del>  "{"j": 1, "k": 2}" must appear before "1" and "2", of their element or member values then.  Applied to other value types, it will select nothing. <del> Some examples: </del>  3.5.9. components MUST be in the I-JSON range of exact values, see synsem- overview.  3.6. A Normalized Path is a JSONPath with restricted syntax that

Reviewer comments:
Ref: URL
we need to discuss the descendant selector's behavior by including itself to the node list.
Yes. Let's do that in a PR for URL
yes ... it's illustratively shown, what a good thing inline examples are ...
Considering the following input: would evaluate to (in this case the values of the object): I would expect the descendant version: to evaluate to: Yet the example says: Considering the following pseudo logic: In the case of the would be an index wildcard selector. I would expect the descendant selector to (starting by selecting itself) walk through the json structure and select all the results by applying the child selector (dot-member-name, index-selector, index-wild-selector, or wildcard) on each traversed value. Am I misunderstanding something here or is this the intended behavior?
Thanks for raising this. When I was writing the example, I noticed that only a few implementations included the node itself. But the descendant selector semantics currently say: and so I included the "starting" node itself. This is why I included the following text in the commit message: The semantics section needs improving anyway to clarify the semantics of the various forms of the descendants selector. I agree with the semantics proposed above, providing there is a consensus for this in the WG.
In my understanding descendant selector simply extends the single-level operating of child selector , in that it further recursively operates on all other descendant levels. So I agree to Bram's traversal algorithm above. A node is not considered a descendant of itself. Obviously I have not been aware of this behavior.

Revised text:
Note: This ordering of the results for the "$..[*]" and "$..*" examples above is not guaranteed, except that:  <ins> "{"o": {"j": 1, "k": 2}, "a": [5, 3]}" must appear before "{"j": 1, "k": 2}" and "[5, 3]", </ins> "{"j": 1, "k": 2}" must appear before "1" and "2", of their element or member values then.  Applied to other value types, it will select nothing.  <ins> 3.5.8.3. JSON document: Queries: </ins> 3.5.9. components MUST be in the I-JSON range of exact values, see synsem- overview. <ins> 3.5.9.3. JSON document: Queries: </ins> 3.6. A Normalized Path is a JSONPath with restricted syntax that
Original text:
Normalized Paths: "$[-3]", for example, is a Singular Path, but not a Normalized Path.  4. 4.1.

Reviewer comments:
can only produce a singular result since the slice is equivalent to the index . Agreed?
In the first two examples, the Path and Normalized path are equivalent in what they identify. Not so for the third because the Path produces a plural result and thus cannot be normalized. This should probably be noted?

Revised text:
Normalized Paths: "$[-3]", for example, is a Singular Path, but not a Normalized Path. <ins> 3.6.1. </ins> 4. 4.1.
Original text:
3.7.1.  4. 4.1.

Reviewer comments:
NAME and NAME Thanks for your help. I verified cut'n'past works correctly.
Some of these are split across lines in awkward places: ! We could either fix the rendering somehow to split at a more acceptable point or change the examples to avoid these awkward splits.
NAME Do you know how to fix the rendering? E.g. I think it would be better not to split the lines in the middle of a quoted string, but splitting after would be ok.
Please check my little tweak to
What if we reduce each aspect to minimal necessary ... ?
This seems to work ...
This is essentially what URL does, except that it uses native nbsps.
ahh ... fine ...
There are two considerations I have in mind: Ease of future editing - may need to add a comment about invisible special characters. Cut'n'paste - need to be able to run the examples and get the same results when clipped from either text or HTML.
Left an editing note. Copy/paste works for me in TXT (which has an ASCII space) and HTML (which has an NBSP, but that gets reduced in copy/paste).
Fixed as part of e82ce1f521e94ee2cd5b93d14726875e94a4a8e7.

Revised text:
3.7.1. <ins> "$["u00b1"]" is normalized into (noise in the table and lack of typewriter font is due to RFCXMLv3 limitations). </ins> 4. 4.1.
Original text:
Root selector "$" (used at the start of a query and in expressions) <del> Dot selector ".<name>", used with object member names exclusively. </del>  <del> Dot wildcard selector ".*". </del>  Index selector "[<index>]", where "<index>" is either a (possibly negative, see index-semantics) array index or an object member <del> name. </del>  <del> Index wildcard selector "[*]". </del>  Array slice selector "[<start>:<end>:<step>]", where the optional <del> values "<start>", "<end>", and "<step>" are integer literals. </del>  <del> Descendants selector "..". </del>  List selector "[<sel1>,<sel2>,...,<selN>]", holding a comma <del> separated list of index and slice selectors. </del>  Filter selector "[?(<expr>)]"

Reviewer comments:
contains a bulleted list of the selector types. Each of the items in the list ends with a period. While it may (or may not) be grammatically correct, it leads to some confusing text, specifically when a selector contains, or completely comprises of, periods. For example: Because we only have plain text, it's really difficult to see what's going on here. Formatted, it would look like which is much clearer. If the spec is to continue being issued in a plain text format, I suggest we remove the ending periods from these lines.

Revised text:
Root selector "$" (used at the start of a query and in expressions)  <ins> Dot selector ".<name>", used with object member names exclusively </ins>  <ins> Dot wildcard selector ".*" </ins> Index selector "[<index>]", where "<index>" is either a (possibly negative, see index-semantics) array index or an object member  <ins> name </ins>  <ins> Index wildcard selector "[*]" </ins> Array slice selector "[<start>:<end>:<step>]", where the optional  <ins> values "<start>", "<end>", and "<step>" are integer literals </ins>  <ins> Descendants selector starting with a double dot ".." </ins> List selector "[<sel1>,<sel2>,...,<selN>]", holding a comma  <ins> separated list of index and slice selectors </ins> Filter selector "[?(<expr>)]"