Change:
Implemented the changes as suggested in Issue
The purpose of this issue is to start discussion about how to turn this into a completed draft to send to the IESG. Perhaps the most important issue is how much of the explanatory and motivational material to leave in. There is a case to be made for taking all of it out, so you get a nice short RFC that just says what I-Regexp is. So here's my initial straw-person proposal on what should be removed and changed: Remove the "issues" para in Section 3. Section 5.2, 5.3, remove the trailing note about improving performance. This is an implementation artifact, no? Section 6. Replace with a single short paragraph somewhat as follows: "While regular expressions originally were intended to describe a formal language, i.e., to provide a Boolean matching function, they have turned into parsing functions for many applications. With this accretion of features, parsing regexp libraries have become susceptible to bugs and performance degradation, in particular those that can be exploited in Denial of Service (DoS) attacks in the case where an attacker controls the regex submitted for processing. I-Regexp is designed to offer interoperability, and to be less vulnerable to such attacks, with the trade-off that its only function is to offer a boolean response as to whether a character sequence is matched by a regex. [ If we really feel that other parts of this discussion add value, they could migrate into an appendix.] 6.1 - cut this down, retaining the first para of the first bullet point, the first sentence of the second bullet point, and that's all. The Unicode discussion can migrate into Appendix A.
Resolved by

Discussion:
1. <del> The present specification defines an interoperable regular expression </del> <ins> This specification describes an interoperable regular expression </ins> flavor, I-Regexp. This document uses the abbreviation "regexp" for what are usually

matching capability, i.e., testing whether a given regexp matches a given piece of text. <ins> I-Regexp supports the entire repertoire of Unicode characters. </ins> I-Regexp is a subset of XSD regexps XSD-2. This document includes rules for converting I-Regexps for use with

BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> The grammatical rules in this document are to be interpreted as ABNF, as described in RFC5234. </ins> 2. I-Regexps should handle the vast majority of practical cases where a

character class containing the single character "^". This is essentially XSD regexp without character class subtraction <del> and multi-character escapes. </del> <ins> and multi-character escapes such as "s", "S", and "w". </ins> An I-Regexp implementation MUST be a complete implementation of this limited subset.  In particular, full Unicode support is REQUIRED; the

such as ASCII and MUST support the Unicode character property set in character classes. <del> : The ABNF has been automatically generated and maybe could use some further polishing.  The ABNF has been verified against rfcs, but a wider corpus of regular expressions will need to be examined.  Note that about a third of the complexity of this ABNF grammar comes from going into details on the Unicode IsCategory classes.  Additional complexity stems from the way hyphens can be used inside character classes to denote ranges; the grammar deliberately excludes questionable usage such as "/[a-z-A-Z]/". </del> 4. This syntax is a subset of that of XSD-2.  Implementations which

Envelope the result in "^" and "$". <del> Note that where a regexp literal is required, this needs to enclose the actual regexp in "/". The performance of an ECMAScript matcher can be increased by turning parenthesized regexps (last choice in production "atom") into "(?:...)" constructions. </del> <ins> Note that where a regexp literal is required, the actual regexp needs to be enclosed in "/". </ins> 5.3.

PCRE2, the Go programming language RE2, and the Ruby programming language, except that the last step is: <del> Envelope the result in "A" and "z". Again, the performance can be increased by turning parenthesized regexps (production "atom") into "(?:...)" constructions. 5.4. (Please submit the mapping needed for your favorite kind of regexp.) </del> <ins> Enclose the regexp in "A" and "z". </ins> 6. <del> Data modeling formats (YANG, CDDL) as well as query languages (jsonpath) often need a regular expression (regexp) sublanguage. There are many dialects of regular expressions in use in platforms, programming languages, and data modeling formats. </del> While regular expressions originally were intended to describe a <del> formal language, i.e., to provide a Boolean matching function, they have turned into parsing functions for many applications, with capture groups, greedy/lazy/possessive variants, etc.  Language features such as backreferences allow specifying languages that actually are context-free (Chomsky type 2) instead of the regular languages (Chomsky type 3) that regular expressions are named for. YANG (RFC7950) and CDDL (RFC8610) have adopted the regexp language from W3C Schema XSD-2.  XSD regexp is a pure matching language, i.e., XSD regexps can be used to match a string against them and yield a simple true or false result.  XSD regexps are not as widely implemented as programming language regexp dialects such as those of Perl, Python, Ruby, Go RE2, or JavaScript (ECMAScript) ECMA-262.  The latter are often in a state of continuous development; in the best case (ECMAScript) there is a complete specification which however is highly complex (Section 21.2 of ECMA-262 comprises 62 pages) and evolves on a yearly timeline, with significant additions.  Regexp dialects such as PCRE PCRE2 have evolved to cover a common set of functions available in parsing regexp dialects, offered in a widely available library. With continuing accretion of complex features, parsing regexp libraries have become susceptible to bugs and performance degradation, in particular those that can be exploited in Denial of Service (DoS) attacks.  The library RE2 that is compatible with Go language regexps strives to be immune to DoS attacks, making it attractive to applications such as query languages where an attacker could control the input.  The problem remains that other bugs in such libraries can lead to exploitable vulnerabilities; at the time of writing, the Common Vulnerabilities and Exposures (CVE) system has 131 entries that mention the word "regex" REGEX-CVE (not all, but many of which are such bugs, with 23 matches for arbitrary code execution). Implementations of YANG and CDDL often struggle with providing true XSD regexps; some instead cheat by providing one of the parsing regexp varieties, sometimes without even advertising this fact. A matching regexp that does not use the more complex XSD features (subsetting) can usually be converted into a parsing regexp of many dialects by simply surrounding it with anchors of that dialect (e.g., "^" or "A" and "$" or "z").  If the original matching regexps exceed the envelope of compatibility between dialects, this can lead to interoperability problems, or, worse, security vulnerabilities. Also, features of the target dialect such as capture groups may be triggered inadvertently, reducing performance. </del> <ins> formal language to support a Boolean matching function, they have been enhanced with parsing functions that support the extraction and replacement of arbitrary portions of the matched text.  With this accretion of features, parsing regexp libraries have become more susceptible to bugs and surprising performance degradations which can be exploited in Denial of Service attacks by an attacker who controls the regexp submitted for processing.  I-Regexp is designed to offer interoperability, and to be less vulnerable to such attacks, with the trade-off that its only function is to offer a boolean response as to whether a character sequence is matched by a regexp. </ins> 6.1. XSD regexps are relatively easy to implement or map to widely <del> implemented parsing regexp dialects, with a small number of notable exceptions: </del> <ins> implemented parsing regexp dialects, with these notable exceptions: </ins> Character class subtraction.  This is a very useful feature in many specifications, but it is unfortunately mostly absent from <del> parsing regexp dialects. Discussion: This absence can often be addressed by translating character class subtraction into positive character classes (possibly requiring significant expansion) and/or inserting negative lookahead assertions (which are not universally supported by regexp libraries, most notably not by RE2 RE2).  This specification therefore opts for leaving out character class subtraction. </del> <ins> parsing regexp dialects.  Thus, it is omitted from I-Regexp. </ins> Multi-character escapes.  "d", "w", "s" and their uppercase <del> equivalents (complement classes) exhibit a large amount of variation between regexp flavors.  (E.g., predefined character classes such as "w" may be meant to be ASCII only, or they may encompass all letters and digits defined in Unicode.  The latter is usually of interest in the application of query languages to text in human languages, while the former is of interest to a subset of applications in data model specifications.) Unicode.  While there is no doubt that a regexp flavor meant to last needs to be Unicode enabled, there are a number of aspects of this that need discussion.  Not all regexp implementations that one might want to map I-Regexps into will support accesses to Unicode tables that enable executing on constructs such as "p{IsCoptic}", for mapping into such implementations, translation needs to be provided.  Fortunately, the "p"/"P" feature in general is now quite widely available. Discussion: The ASCII focus can partially be addressed by adding a constraint outside the regexp that the matched text has to be ASCII in the first place.  This often is all that is needed where regexps are used to define lexical elements of a computer language.  This reduces the size of the Unicode tables required in such a constrained implementation considerably.  (In rfcs, RFC 6643 contains a lone instance of "p{IsBasicLatin}{0,255}", which is needed to describe a transition from a legacy character set to Unicode.  RFC2622 contains "[[:digit:]]", "[[:alpha:]]", "[[:alnum:]]", albeit in a specification for the "flex" tool; this is intended to be close to "d", "p{L}", "w" in an ASCII subset.) </del> <ins> complement classes exhibit a large amount of variation between regexp flavors.  Thus, they are omitted from I-Regexp. Not all regexp implementations support accesses to Unicode tables that enable executing on constructs such as "p{IsCoptic}", although the "p"/"P" feature in general is now quite widely available.  While in principle it's possible to translate these into codepoint-range matches, this also requires access to those tables.  Thus, regexp libraries in severely constrained environments may not be able to support I-Regexp conformance. </ins> 7.

8. <del> As discussed in background, more complex regexp libraries are likely to contain exploitable bugs leading to crashes and remote code execution.  There is also the problem that such libraries often have hard to predict performance characteristics, leading to attack vectors that overload an implementation by matching against an expensive attacker-controlled regexp. </del> <ins> As discussed in background, more complex regexp libraries may contain exploitable bugs leading to crashes and remote code execution.  There is also the problem that such libraries often have hard-to-predict performance characteristics, leading to attacks that overload an implementation by matching against an expensive attacker-controlled regexp. </ins> I-Regexps have been designed to allow implementation in a way that is resilient to both threats; this objective needs to be addressed