Change:
Abstract <del> "Regular expressions" (regexps) are a set of related, widely implemented pattern languages used in data modeling formats and query languages that is available in many dialects.  This specification defines an interoperable flavor of regexps, I-Regexp. The present version -02 of this document is a more streamlined update of the original trial balloon, meant to determine whether this approach is useful for the JSONPath WG. </del> <ins> This document specifies I-Regexp, a flavor of regular expressions that is limited in scope with the goal of interoperation across many different regular-expression libraries. </ins> 1. <ins> The present specification defines an interoperable regular expression flavor, I-Regexp. This document uses the abbreviation "regexp" for regular expression. "I-Regexp" is used as a noun meaning a character string which conforms to the requirements in this specification; the plural is "I-Regexps". I-Regexp does not provide advanced regexp features such as capture groups or backreferences.  It supports only a Boolean matching capability, i.e. testing whether a given regexp matches a given piece of text. I-Regexp is a subset of XSD regexps. This document includes rules for converting I-Regexps for use with several well-known regexp libraries. 2. I-Regexps should handle the vast majority of practical cases where a matching regexp is needed in a data model specification or a query language expression. A brief survey of published RFCs yielded the regexp patterns in Appendix A (with no attempt at completeness).  These should be covered by I-Regexps, both syntactically and with their intended semantics. 3. An I-Regexp MUST conform to the ABNF specification in iregexp-abnf. This is essentially XSD regexp without character class subtraction and multi-character escapes. *Issue*: There might be further potential for simplification in IsBlock (leave out) and possibly in the rather large part for IsCategory as well.  The ABNF has been automatically generated and maybe could use some polishing.  The ABNF has been verified against rfcs, but a wider corpus of regular expressions should be examined.  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]/". 4. This syntax is a subset of that of XSD2.  Implementations which interpret I-Regexps MUST yield Boolean results as specified in XSD2. 5. (TBD; these mappings need to be thoroughly verified.) 5.1. Any I-Regexp also is an XSD Regexp XSD2, so the mapping is an identity function. 5.2. Perform the following steps on an I-Regexp to obtain an ECMAScript regexp ECMA-262: Replace any dots (".") outside character classes (first alternative of "charClass" production) by "[^nr]". Envelope the result in "^" and "$". Note that where a regexp literal is required, this needs to enclose the actual regexp in "/". The performance can be increased by turning parenthesized regexps (production "atom") into "(?:...)" constructions. 5.3. Perform the same steps as in toESreg to obtain a valid regexp in PCRE PCRE2, the Go programming language RE2, and the Ruby programming language, except that the last step is: 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.) 6. </ins> 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,

Discussion:
This has had the motivation and background material moved into new sections after the syntax and semantics. The opening section have been RFC-i-fied a bit, with one MUST each for syntax and semantics.