Re: [Cbor] .regexp: s/PCRE/JavaScript REs/?

At the technical (substantive) level, I think that PCRE is an excellent choice. The only thing lacking is identifying the version (or intentionally not, instead declaring it a “living standard” 🌊).

First of all it’s already in RFC 7049, so it’s already part of CBOR. I think of PCRE like grep: a generally-available utility that became (or is becoming) a de-facto standard. Now grep is in the POSIX standard, but it wasn’t always that way.

PCRE(2) is better than ECMA262 since ECMA262’s regular expressions lack look-behind, named groups, and other awesome things. PCRE(2) also features just-in-time compiler support, so in theory it should be possible for an implementer to take a static regular expression (i.e., the kind proposed in CDDL) and shrink it down for embedded devices, rather than embedding the whole library.

At a process level for IETF standards documents, PCRE is problematic. I feel that this can be worked around/through in light of the technical merits—I just don’t know how to get the IESG to say “yes”. :^)

Section 1.2 of draft-seantek-mail-regexen-02 has discussion of the alternatives. It also mentions POSIX Extended Regular Expressions, which are in Chapter 9 “Regular Expressions” of Base Definitions. They are less full-featured than ECMA262, which means in my view, less good. But fewer features mean easier to implement on constrained devices.

Sean

PS PCRE(2) is BSD-licensed, so someone could, conceivably, copy the entire source code into an RFC and call it a day.

> On Jul 21, 2017, at 6:05 AM, Carsten Bormann <cabo@tzi.org> wrote:
> 
> Should we replace saying that the regexes are PCRE with saying they are ECMA262?
> Or is any other flavor (that we could be referencing) in favor?
> 
> Grüße, Carsten
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor