Re: [Jsonpath] #70 Regexps (was: Re: Draft minutes, consensus points, and actions from IETF 112)

I suspect that we are not the only WG, in the present or the future, who
need to/will need to address this issue.  I suggest that we should take
this to ietf@ or ask the IESG if they have an opinion.  Francesca, do you
have any thoughts?

On Sun, Nov 14, 2021 at 1:15 PM Carsten Bormann <cabo@tzi.org> wrote:

> On 2021-11-14, at 12:35, James <james.ietf@gmail.com> wrote:
> >
> > * #70 - Have discussion on list with known options
>
> As a reminder, my slides had these options (renumbered for easier
> reference, and expanded a bit):
>
> 1. Select (define) one regular expression flavor
> 2. Provide a way to plug in regular expressions (of different flavors)
> 3. No regexps in base RFC (but keep an extension point)
>
> 1. further splits into:
>
> 1a. Select *a version of* ECMAScript (parsing/searching RE)
> 1b. Select W3C XSD RE (matching RE)
> 1c. Build "modest subset" (e.g., iregexp)
>
> Since we don’t have a consensus or even a majority among the
> implementations, we are free to do the right thing, if we can pull that off.
>
> As you know, I have been exploring 1c.
>
> I submitted an updated version -01 of draft-bormann-jsonpath-iregexp.
> As in -00, I’m using W3C XSD RE as a base, as these are actual regular
> expressions, amenable to implementation techniques that are less
> susceptible to DoS problems than the Perl/PCRE/ECMAscript dialect.
>
> Apart from character class subtraction and the exact semantics of
> Multi-Character escapes (\s \d \w etc., outside and inside of character
> class expressions), W3C XSD RE are pretty much a consensus subset of the
> various regular expression dialects, except that they are in the form of
> matching expressions (no anchors needed) instead of parsing expressions.
>
> I believe the spec should have conversion instructions for implementers
> that just want to use the regexp engine they happen to have handy.  Because
> of the consensus subset nature of W3C XSD RE, these instructions are
> relatively straightforward (copy, and surround by the anchors the target
> flavor happens to use).
>
> I tried to add conversion instructions for Multi-Character escapes (\s \d
> \w and \S \D \W, leaving out the \c and \i that nobody except W3C has).
> As you can see when looking at the diff, the result is not pretty when it
> comes to double negation in character classes.  Maybe a pathological case,
> but a bit of a trap, and maybe not that useful anyway as the W3C semantics
> is quite different from the PCRE ones.
> So I’m leaning towards a -02 that does not have Multi-Character escapes.
> (None of the regexps I found in RFCs uses them, and not having them also
> happens to be pretty much what the json-schema.org drafts seem to
> converge at.)
>
> Grüße, Carsten
>
> Status:   https://datatracker.ietf.org/doc/draft-bormann-jsonpath-iregexp/
> Html:
> https://www.ietf.org/archive/id/draft-bormann-jsonpath-iregexp-01.html
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-bormann-jsonpath-iregexp-01
>
> --
> JSONpath mailing list
> JSONpath@ietf.org
> https://www.ietf.org/mailman/listinfo/jsonpath
>