Change:
against an array whose size doesn't fit in the implementation's representation of an integer, the implementation MUST raise an error. <ins> 3.5.7. 3.5.7.1. The descendant selector starts with a double dot ".." and can be followed by an object member name (similar to the "dot-selector"), by an "index-selector" acting on objects or arrays, or by a wild card. 3.5.7.2. The "descendant-selector" is inspired by ECMAScript for XML (E4X). It selects the node and all its descendants. 3.5.8. 3.5.8.1. The union selector is syntactically related to the "index-selector". It contains multiple, comma separated entries. Task (T1): This, besides slice-index, is currently one of only two places in the document that mentions whitespace.  Whitespace needs to be handled throughout the ABNF syntax.  Room Consensus at the 2021-06-15 interim was that JSONPath generally is generous with allowing insignificant whitespace throughout.  Minimizing the impact of the many whitespace insertion points by choosing a rule name such as "S" was mentioned.  Some conventions will probably help with minimizing the number of places where S needs to be inserted. 3.5.8.2. A union selects any node which is selected by at least one of the union selectors and selects the concatenation of the lists (in the order of the selectors) of nodes selected by the union elements. Note that any node selected in more than one of the union selectors is kept as many times in the node list. 3.5.9. 3.5.9.1. The filter selector has the form "[?<expr>]".  It works via iterating over structured values, i.e. arrays and objects. During iteration process each array element or object member is visited and its value -- accessible via symbol "@" -- or one of its descendants -- uniquely defined by a relative path -- is tested against a boolean expression "boolean-expr". The current item is selected if and only if the result is "true". Notes: Parentheses can be used with "boolean-expr" for grouping.  So filter selection syntax in the original proposal "[?(<expr>)]" is naturally contained in the current lean syntax "[?<expr>]" as a special case. Comparisons are restricted to primitive values (such as number, string, "true", "false", "null").  Comparisons with complex values will fail, i.e. no selection occurs. Types are not implicitly converted in comparisons.  So ""13 == '13'"" selects no node. A member or element value by itself is _falsy_ only, if it does not exist.  Otherwise it is _truthy_, resulting in its value.  To be more specific explicit comparisons are necessary.  This existence test -- as an exception of the general rule -- also works with complex values. Regular expression tests can be applied to "string" values only. Containment tests work with arrays and objects. Explicit boolean type conversion is done by the not operator "neg- op". The behaviour of operators is consistent with the 'C'-family of programming languages. 3.5.9.2. The "filter-selector" works with arrays and objects exclusively.  Its result might be a list of _zero_, _one_, _multiple_ or _all_ of their element or member values then.  Applied to other value types, it will select nothing. Negation operator "neg-op" allows to test _falsiness_ of values. Applying negation operator twice "!!" gives us _truthiness_ of values. Some examples: </ins> 4. <del> TBD: Define a media type for JSONPath expressions. </del> <ins> Task (T2): Separate out expression language.  For now, this section is a repository for ABNF taken from RFC8259.  This needs to be deduplicated with definitions above. </ins> 5. <ins> TBD: Define a media type for JSONPath expressions. 6. </ins> This section gives security considerations, as required by RFC3552. <del> 6.  References </del> <ins> 7.  References </ins> <del> 6.1.  URIs </del> <ins> 7.1.  URIs </ins> [1] https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath

Discussion:
This is a full rebase of branch pr-98 () on current main.
Does this incorporate any changes from the discussions from , or is it a simple rebase?
It is a simple rebase, followed by a number of edits coming from the discussions here. Most of the remaining conversations need some further discussion, so I hope to cover them with my updated slides in a couple of hours.
Looks like a good next step on our path.