<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.37 (Ruby 3.2.1) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-jsonpath-iregexp-08" number="9485" submissionType="IETF" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes="" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.17.4 -->

  <front>
    <title abbrev="I-Regexp">I-Regexp: An Interoperable Regexp Regular Expression Format</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-jsonpath-iregexp-08"/> name="RFC" value="9485"/>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization>Universität Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>Bremen</city>
          <code>D-28359</code>
          <country>Germany</country>
        </postal>
        <phone>+49-421-218-63921</phone>
        <email>cabo@tzi.org</email>
      </address>
    </author>
    <author initials="T." surname="Bray" fullname="Tim Bray">
      <organization>Textuality</organization>
      <address>
        <postal>
          <country>Canada</country>
        </postal>
        <email>tbray@textuality.com</email>
      </address>
    </author>
    <date year="2023" month="June" day="29"/>
    <keyword>Internet-Draft</keyword> month="October"/>
    <area>art</area>
    <workgroup>jsonpath</workgroup>

<keyword>Regexp</keyword>
<keyword>Regex</keyword>

    <abstract>
      <?line 67?>

<t>This document specifies I-Regexp, a flavor of regular expressions expression that is
limited in scope with the goal of interoperation across many different
regular-expression
regular expression libraries.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-jsonpath-iregexp/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        JSONPath Working Group mailing list (<eref target="mailto:JSONPath@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/JSONPath/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/JSONPath/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/ietf-wg-jsonpath/iregexp"/>.</t>
    </note>

  </front>
  <middle>
    <?line 73?>

<section anchor="intro">
      <name>Introduction</name>
      <t>This specification describes an interoperable regular expression ("regexp") (abbreviated as "regexp") flavor, I-Regexp.</t>
      <t>I-Regexp does not provide advanced regular expression features such as capture groups, lookahead, or backreferences.
It supports only a Boolean matching capability, i.e., testing whether a given regular expression matches a given piece of text.</t>
      <t>I-Regexp supports the entire repertoire of Unicode characters (Unicode
scalar values); both the I-Regexp strings themselves and the strings
they are matched against are sequences of Unicode scalar values (often
represented in UTF-8 encoding form <xref target="RFC3629"/> for interchange).</t>
      <t>I-Regexp is a subset of XSD XML Schema Definition (XSD) regular expressions <xref target="XSD-2"/>.</t>
      <t>This document includes guidance for converting I-Regexps for use with several well-known regular expression idioms.</t>
      <t>The development of I-Regexp was motivated by the work of the JSONPath Working Group. The Working Group (WG). The WG wanted to include
in its specification <xref target="I-D.ietf-jsonpath-base"/> support for the use of regular expressions in JSONPath filters, filters
in its specification <xref target="I-D.ietf-jsonpath-base"/>, but was unable to find a useful
specification for regular expressions which that would be interoperable across the popular libraries.</t>
      <section anchor="terminology">
        <name>Terminology</name>
        <t>This document uses the abbreviation "regexp" for what are is usually
called regular expressions a "regular expression" in programming.
The term "I-Regexp" is used as a noun meaning a character string (sequence of
Unicode scalar values) that conforms to the requirements
in this specification; the plural is "I-Regexps".</t>
        <t>This specification uses Unicode terminology.
A terminology; a good entry point into that is provided by <xref target="UNICODE-GLOSSARY"/>.</t>
        <t>The
        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t>
        <?line -18?> here.
        </t>

<t>The grammatical rules in this document are to be interpreted as ABNF,
as described in <xref target="RFC5234"/> and <xref target="RFC7405"/>, where the "characters" of
<xref section="2.3" sectionFormat="of" target="RFC5234"/> are Unicode scalar values.</t>
      </section>
    </section>
    <section anchor="objectives">
      <name>Objectives</name>
      <t>I-Regexps should handle the vast majority of practical cases where a
matching regexp is needed in a data model data-model specification or a query
language query-language expression.</t>
      <t>The editors
      <t>At the time of writing, an editor of this document conducted a survey of the regexp syntax
used in recently published RFCs. All examples found there should be covered by I-Regexps,
both syntactically and with their intended semantics.
The exception is the use of multi-character escapes, for which
workaround guidance is provided in <xref target="mapping"/>.</t>
    </section>
    <section anchor="defn">
      <name>I-Regexp Syntax</name>
      <t>An I-Regexp <bcp14>MUST</bcp14> conform to the ABNF specification in
<xref target="iregexp-abnf"/>.</t>
      <figure anchor="iregexp-abnf">
        <name>I-Regexp Syntax in ABNF</name>
        <sourcecode type="abnf"><![CDATA[
i-regexp = branch *( "|" branch )
branch = *piece
piece = atom [ quantifier ]
quantifier = ( "*" / "+" / "?" ) / range-quantifier
range-quantifier = "{" QuantExact [ "," [ QuantExact ] ] "}"
QuantExact = 1*%x30-39 ; '0'-'9'

atom = NormalChar / charClass / ( "(" i-regexp ")" )
NormalChar = ( %x00-27 / "," / "-" / %x2F-3E ; '/'-'>'
 / %x40-5A ; '@'-'Z'
 / %x5E-7A ; '^'-'z'
 / %x7E-10FFFF %x7E-D7FF ; skip surrogate code points
 / %xE000-10FFFF )
charClass = "." / SingleCharEsc / charClassEsc / charClassExpr
SingleCharEsc = "\" ( %x28-2B ; '('-'+'
 / "-" / "." / "?" / %x5B-5E ; '['-'^'
 / %s"n" / %s"r" / %s"t" / %x7B-7D ; '{'-'}'
 )
charClassEsc = catEsc / complEsc
charClassExpr = "[" [ "^" ] ( "-" / CCE1 ) *CCE1 [ "-" ] "]"
CCE1 = ( CCchar [ "-" CCchar ] ) / charClassEsc
CCchar = ( %x00-2C / %x2E-5A ; '.'-'Z'
 / %x5E-10FFFF %x5E-D7FF ; skip surrogate code points
 / %xE000-10FFFF ) / SingleCharEsc
catEsc = %s"\p{" charProp "}"
complEsc = %s"\P{" charProp "}"
charProp = IsCategory
IsCategory = Letters / Marks / Numbers / Punctuation / Separators /
    Symbols / Others
Letters = %s"L" [ ( %s"l" / %s"m" / %s"o" / %s"t" / %s"u" ) ]
Marks = %s"M" [ ( %s"c" / %s"e" / %s"n" ) ]
Numbers = %s"N" [ ( %s"d" / %s"l" / %s"o" ) ]
Punctuation = %s"P" [ ( %x63-66 ; 'c'-'f'
 / %s"i" / %s"o" / %s"s" ) ]
Separators = %s"Z" [ ( %s"l" / %s"p" / %s"s" ) ]
Symbols = %s"S" [ ( %s"c" / %s"k" / %s"m" / %s"o" ) ]
Others = %s"C" [ ( %s"c" / %s"f" / %s"n" / %s"o" ) ]
]]></sourcecode>
      </figure>
      <t>As an additional restriction, <tt>charClassExpr</tt> is not allowed to
match <tt>[^]</tt>, which which, according to this grammar grammar, would parse as a
positive character class containing the single character <tt>^</tt>.</t>
<t>This is essentially an XSD regexp without character without:</t>
<ul><li>character class
subtraction, without multi-character
subtraction,</li>
<li>multi-character escapes such as <tt>\s</tt>,
<tt>\S</tt>, and <tt>\w</tt>, and without Unicode blocks.</t> </li><li>Unicode blocks.</li></ul>

      <t>An I-Regexp implementation <bcp14>MUST</bcp14> be a complete implementation of this
limited subset.
In particular, full support for the Unicode functionality defined in
      this specification is <bcp14>REQUIRED</bcp14>; the implementation <bcp14>REQUIRED</bcp14>. The implementation:</t>
      <ul><li>
<bcp14>MUST NOT</bcp14> limit itself to 7- or 8-bit character sets such as ASCII and
<bcp14>MUST</bcp14> ASCII, and</li>
<li><bcp14>MUST</bcp14> support the Unicode character property set in character classes.</t> classes.</li></ul>
      <section anchor="checking">
        <name>Checking Implementations</name>

        <t>A <em>checking</em> I-Regexp implementation is one that checks a supplied
regexp for compliance with this specification and reports any problems.
Checking implementations give their users confidence that they didn't
accidentally insert non-interoperable syntax, syntax that is not interoperable, so checking is <bcp14>RECOMMENDED</bcp14>.
Exceptions to this rule may be made for low-effort implementations
that map I-Regexp to another regexp library by simple steps such as
performing the mapping operations discussed in <xref target="mapping"/>; here, target="mapping"/>.  Here, the
effort needed to do full checking may might dwarf the rest of the
implementation effort.
Implementations <bcp14>SHOULD</bcp14> document whether or not they are checking or not.</t> checking.</t>
        <t>Specifications that employ I-Regexp may want to define in which
cases their implementations can work with a non-checking I-Regexp
implementation and when full checking is needed, possibly in the
process of defining their own implementation classes.</t>
      </section>
    </section>
    <section anchor="i-regexp-semantics">
      <name>I-Regexp Semantics</name>
      <t>This syntax is a subset of that of <xref target="XSD-2"/>.
Implementations which that interpret I-Regexps <bcp14>MUST</bcp14>
yield Boolean results as specified in <xref target="XSD-2"/>.
(See also <xref target="xsd-regexps"/>.)</t>
    </section>
    <section anchor="mapping">
      <name>Mapping I-Regexp to Regexp Dialects</name>
      <t>The material in this section is non-normative, not normative; it is provided as guidance
to developers who want to use I-Regexps in the context of other
regular expression dialects.</t>
      <section anchor="multi-character-escapes">
        <name>Multi-Character Escapes</name>
        <t>Common
        <t>I-Regexp does not support common multi-character escapes (MCEs), (MCEs) and character classes built around them,
which are not supported in I-Regexp, them.  These can usually
be replaced as shown for example by the examples in <xref target="tbl-sub"/>.</t>
        <table anchor="tbl-sub"> anchor="tbl-sub" align="center">
          <name>Example substitutes Substitutes for multi-character escapes</name> Multi-Character Escapes</name>
          <thead>
            <tr>
              <th align="left">MCE/class</th> align="left">MCE/class:</th>
              <th align="left">Replace with</th> with:</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">
                <tt>\S</tt></td>
              <td align="left">
                <tt>[^ \t\n\r]</tt></td>
            </tr>
            <tr>
              <td align="left">
                <tt>[\S ]</tt></td>
              <td align="left">
                <tt>[^\t\n\r]</tt></td>
            </tr>
            <tr>
              <td align="left">
                <tt>\d</tt></td>
              <td align="left">
                <tt>[0-9]</tt></td>
            </tr>
          </tbody>
        </table>
        <t>Note that the semantics of <tt>\d</tt> in XSD regular expressions
        is that of <tt>\p{Nd}</tt>; however, this would include all Unicode
        characters that are digits in various writing systems, which is almost
        certainly not what is required in IETF publications.</t>
        <t>The construct <tt>\p{IsBasicLatin}</tt> is essentially a reference to legacy
ASCII,
ASCII; it can be replaced by the character class <tt>[\u0000-\u007f]</tt>.</t>
      </section>
      <section anchor="xsd-regexps">
        <name>XSD Regexps</name>
        <t>Any I-Regexp also is also an XSD Regexp regexp <xref target="XSD-2"/>, so the mapping is an identity
	function.</t>

        <t>Note that a few errata for <xref target="XSD-2"/> have been fixed in <xref target="XSD11-2"/>, which target="XSD-1.1-2"/>; therefore, it
is therefore also included as a normative reference. in the <xref target="norm">Normative References</xref>.
XSD 1.1 is less widely implemented than XSD 1.0, and implementations
of XSD 1.0 are likely to include these bugfixes, so bugfixes; for the intents
and purposes of this specification specification, an implementation of XSD 1.0
regexps is equivalent to an implementation of XSD 1.1 regexps.</t>
      </section>
      <section anchor="toESreg">
        <name>ECMAScript Regexps</name>
        <t>Perform the following steps on an I-Regexp to obtain an ECMAScript
regexp <xref target="ECMA-262"/>:</t>
        <ul spacing="normal">
          <li>For any unescaped dots (<tt>.</tt>) outside character classes
          (first alternative of <tt>charClass</tt> production): production), replace the dot by with
          <tt>[^\n\r]</tt>.</li>
          <li>Envelope the result in <tt>^(?:</tt> and <tt>)$</tt>.</li>
        </ul>
        <t>The ECMAScript regexp is to be interpreted as a Unicode pattern ("u"
flag; see Section 21.2.2 "Pattern Semantics" of <xref target="ECMA-262"/>).</t>
        <t>Note that where a regexp literal is required,
the actual regexp needs to be enclosed in <tt>/</tt>.</t>
      </section>
      <section anchor="pcre-re2-ruby-regexps">
        <name>PCRE, RE2, and Ruby Regexps</name>
        <t>Perform the same steps as in <xref target="toESreg"/> to

        <t>To obtain a valid regexp in
PCRE Perl Compatible Regular Expressions
   (PCRE) <xref target="PCRE2"/>, the Go programming language language's RE2 regexp library <xref target="RE2"/>, and the Ruby
programming language, perform the same steps as in <xref target="toESreg"/>, except that the last step is:</t>
        <ul spacing="normal">
          <li>Enclose the regexp in <tt>\A(?:</tt> and <tt>)\z</tt>.</li>
        </ul>
      </section>
    </section>

    <section anchor="background">
      <name>Motivation and Background</name>
      <t>While regular expressions originally were intended to describe a
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 parsing-regexp libraries have become
more susceptible to bugs and surprising performance degradations which that
can be exploited in Denial of Service denial-of-service attacks by
an attacker who controls the regexp submitted for
processing. I-Regexp is designed to offer interoperability, interoperability and to be
less vulnerable to such attacks, with the trade-off that its only
function is to offer a boolean Boolean response as to whether a character
sequence is matched by a regexp.</t>
      <section anchor="subsetting">
        <name>Implementing I-Regexp</name>
        <t>XSD regexps are relatively easy to implement or map to widely
implemented parsing regexp parsing-regexp dialects, with these notable
exceptions:</t>
        <ul spacing="normal">
          <li>Character class subtraction.  This is a very useful feature in
          many specifications, but it is unfortunately mostly absent from parsing
regexp
          parsing-regexp dialects. Thus, it is omitted from I-Regexp.</li>
          <li>Multi-character escapes.  <tt>\d</tt>, <tt>\w</tt>, <tt>\s</tt>
          and their uppercase complement classes exhibit a large amount of
          variation between regexp flavors.  Thus, they are omitted from
          I-Regexp.</li>
          <li>Not all regexp implementations support accesses access to Unicode
          tables that enable executing constructs such as <tt>\p{Nd}</tt>,
          although the <tt>\p</tt>/<tt>\P</tt> feature in general is now quite
          widely available. While While, in principle principle, it is possible to translate
          these into character-class matches, this also requires access to
          those tables. Thus, regexp libraries in severely constrained
          environments may not be able to support I-Regexp conformance.</li>
        </ul>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document makes has no requests of IANA.</t> IANA actions.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security considerations</name> Considerations</name>
      <t>While technically out of the scope of this specification, Section <xref target="RFC3629" section="10" sectionFormat="bare">Security Considerations</xref> sectionFormat="bare">"Security Considerations"</xref> of <xref target="RFC3629"/> applies to implementations.
Particular note needs to be taken of the last paragraph of Section <xref target="RFC3629" section="3" sectionFormat="bare">UTF-8 definition</xref> sectionFormat="bare">"UTF-8 definition"</xref> of <xref target="RFC3629"/>; an I-Regexp implementation may need to
mitigate limitations of the platform implementation in this regard.</t>
      <t>As discussed in <xref target="background"/>, more complex regexp libraries may
contain exploitable bugs leading bugs, which can lead to crashes and remote code
execution.  There is also the problem that such libraries often have
hard-to-predict
performance characteristics, characteristics that are hard to predict, leading to attacks
that overload an implementation by matching against an expensive
attacker-controlled regexp.</t>
      <t>I-Regexps have been designed to allow implementation in a way that is
resilient to both threats; this objective needs to be addressed
throughout the implementation effort. Non-checking implementations (see <xref target="checking"/>) are likely to expose
security limitations of any regexp engine they use, which may be less
problematic if that engine has been built with security considerations
in mind (e.g., <xref target="RE2"/>); target="RE2"/>).  In any case, a checking implementation is still <bcp14>RECOMMENDED</bcp14>.</t>
      <t>Implementations that specifically implement the I-Regexp subset can,
with care, be designed to generally run in linear time and space in
the input, input and to detect when that would not be the case (see below).</t>
      <t>Existing regexp engines should be able to easily handle most I-Regexps
(after the adjustments discussed in <xref target="mapping"/>), but may consume
excessive resources for some types of I-Regexps or outright reject
them because they cannot guarantee efficient execution.
(Note that different versions of the same regexp library may be more or
      less vulnerable to excessive resource consumption for these cases.)</t>

      <t>Specifically, range quantifiers (as in <tt>a{2,4}</tt>) provide particular
challenges for both existing and I-Regexp focused implementations.
These
Implementations may therefore limit range quantifiers in composability
(disallowing nested range quantifiers such as <tt>(a{2,4}){2,4}</tt>) or
range (disallowing very large ranges such as <tt>a{20,200000}</tt>), or detect
and reject any excessive resource consumption caused by them.</t> range quantifiers.</t>
      <t>I-Regexp implementations that are used to evaluate regexps from
untrusted sources need to be robust to in these cases.
Implementers using existing regexp libraries are encouraged to encouraged:</t>

<ul>
  <li>to check
their documentation to see if mitigations are configurable, such as
  limits in resource consumption, and to and</li>
  <li>to document their own degree of
robustness resulting from employing such mitigations.</t> mitigations.</li></ul>
    </section>
  </middle>
  <back>

    <displayreference target="RFC3629" to="STD63"/> target="I-D.ietf-jsonpath-base" to="JSONPATH-BASE"/>

    <references>
      <name>References</name>
      <references>
      <references anchor="norm">
        <name>Normative References</name>

        <reference anchor="XSD-2" target="https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/">
          <front>
            <title>XML Schema Part 2: Datatypes Second Edition</title>
            <author fullname="Ashok Malhotra" role="editor"/>
            <author fullname="Paul V. Biron" role="editor"/>
            <author fullname="Ashok Malhotra" role="editor"/>
            <date day="28" month="October" year="2004"/>
          </front>
          <seriesInfo name="W3C REC" value="REC-xmlschema-2-20041028"/>
          <seriesInfo name="W3C" value="REC-xmlschema-2-20041028"/>
        </reference>

        <reference anchor="XSD11-2" anchor="XSD-1.1-2" target="https://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/">
          <front>
            <title>W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes</title>
            <author fullname="David Peterson" role="editor"/>
            <author fullname="Shudi Gao" role="editor"/>
            <author fullname="Ashok Malhotra" role="editor"/>
            <author fullname="David Peterson" fullname="C. M. Sperberg-McQueen" role="editor"/>
            <author fullname="Henry Thompson" role="editor"/>
            <author fullname="Michael Sperberg-McQueen" role="editor"/>
            <author fullname="Paul V. Biron" role="editor"/>
            <author fullname="Sandy Gao" role="editor"/>
            <date day="5" month="April" year="2012"/>
          </front>
          <seriesInfo name="W3C REC" value="REC-xmlschema11-2-20120405"/>
          <seriesInfo name="W3C" value="REC-xmlschema11-2-20120405"/>
        </reference>
        <reference anchor="RFC5234">
          <front>
            <title>Augmented BNF for Syntax Specifications: ABNF</title>
            <author fullname="D. Crocker" initials="D." role="editor" surname="Crocker">
              <organization/>
            </author>
            <author fullname="P. Overell" initials="P." surname="Overell">
              <organization/>
            </author>
            <date month="January" year="2008"/>
            <abstract>
              <t>Internet technical specifications often need to define a formal syntax.  Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications.  The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power.  The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.  This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="68"/>
          <seriesInfo name="RFC" value="5234"/>
          <seriesInfo name="DOI" value="10.17487/RFC5234"/>
        </reference>
        <reference anchor="RFC7405">
          <front>
            <title>Case-Sensitive String Support in ABNF</title>
            <author fullname="P. Kyzivat" initials="P." surname="Kyzivat">
              <organization/>
            </author>
            <date month="December" year="2014"/>
            <abstract>
              <t>This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7405"/>
          <seriesInfo name="DOI" value="10.17487/RFC7405"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7405.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC3629">
          <front>
            <title>UTF-8, a transformation format of ISO 10646</title>
            <author fullname="F. Yergeau" initials="F." surname="Yergeau">
              <organization/>
            </author>
            <date month="November" year="2003"/>
            <abstract>
              <t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems.  The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo.  UTF-8 has the characteristic

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/>

<!-- [I-D.ietf-jsonpath-base] Edit state as of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent 10/9/23; long form to other values.  This memo obsoletes and replaces RFC 2279.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="63"/>
          <seriesInfo name="RFC" value="3629"/>
          <seriesInfo name="DOI" value="10.17487/RFC3629"/>
        </reference> include "Ed." roles.  -->

<reference anchor="I-D.ietf-jsonpath-base"> anchor="I-D.ietf-jsonpath-base" target="https://datatracker.ietf.org/doc/html/draft-ietf-jsonpath-base-20">
<front>
<title>JSONPath: Query expressions for JSON</title>
<author initials="S." surname="Gössner" fullname="Stefan Gössner" initials="S." surname="Gössner"> role="editor">
<organization>Fachhochschule Dortmund</organization>
</author>
<author initials="G." surname="Normington" fullname="Glyn Normington" initials="G." surname="Normington"> role="editor">
</author>
<author initials="C." surname="Bormann" fullname="Carsten Bormann" initials="C." surname="Bormann"> role="editor">
<organization>Universität Bremen TZI</organization>
</author>
<date day="10" month="June" month="August" day="25" year="2023"/>
            <abstract>
              <t>   JSONPath defines a string syntax for selecting and extracting JSON
   (RFC 8259) values from a JSON value.

              </t>
            </abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-jsonpath-base-14"/> value="draft-ietf-jsonpath-base-20"/>
</reference>

        <reference anchor="UNICODE-GLOSSARY" target="https://unicode.org/glossary/">
          <front>
            <title>Glossary of Unicode Terms</title>
            <author>
              <organization>Unicode, Inc.</organization>
            </author>
            <date/>
          </front>
        </reference>

        <reference anchor="RE2" target="https://github.com/google/re2">
          <front>
            <title>RE2 is a fast, safe, thread-friendly alternative to
            backtracking regular expression engines like those used in PCRE,
            Perl, and Python. It is a C++ library.</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
	  <refcontent>commit 73031bb</refcontent>
        </reference>

        <reference anchor="PCRE2" target="http://pcre.org/current/doc/html/">
          <front>
            <title>Perl-compatible Regular Expressions (revised API: PCRE2)</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>

        <reference anchor="ECMA-262" target="https://www.ecma-international.org/wp-content/uploads/ECMA-262.pdf">
          <front>
            <title>ECMAScript 2020 Language Specification</title>
            <author>
              <organization>Ecma International</organization>
            </author>
            <date year="2020" month="June"/>
          </front>
          <seriesInfo name="ECMA" value="Standard
          <refcontent>Standard ECMA-262, 11th Edition"/>
        </reference>
        <reference anchor="RFC7493">
          <front>
            <title>The I-JSON Message Format</title>
            <author fullname="T. Bray" initials="T." role="editor" surname="Bray">
              <organization/>
            </author>
            <date month="March" year="2015"/>
            <abstract>
              <t>I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7493"/>
          <seriesInfo name="DOI" value="10.17487/RFC7493"/> Edition</refcontent>
        </reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7493.xml"/>

      </references>
    </references>
    <?line 387?>

<section anchor="rfcs" removeInRFC="true">
      <name>Regexps and Similar Constructs in Recent Published RFCs</name>
      <t>This appendix contains a number of regular expressions that have been
extracted from some recently published RFCs based on some ad-hoc matching.
Multi-line constructions were not included.
With the exception of some (often surprisingly dubious) usage of multi-character
escapes and a reference to the <tt>IsBasicLatin</tt> Unicode block, all
regular expressions validate against the ABNF in <xref target="iregexp-abnf"/>.</t>
      <figure anchor="iregexp-examples">
        <name>Example regular expressions extracted from RFCs</name>
        <artwork><![CDATA[
rfc6021.txt  459 (([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))
rfc6021.txt  513 \d*(\.\d*){1,127}
rfc6021.txt  529 \d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?
rfc6021.txt  631 ([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?
rfc6021.txt  647 [0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}
rfc6021.txt  933 ((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}
rfc6021.txt  938 (([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|
rfc6021.txt 1026 ((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}
rfc6021.txt 1031 (([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|
rfc6020.txt 6647 [0-9a-fA-F]*
rfc6095.txt 2544 \S(.*\S)?
rfc6110.txt 1583 [aeiouy]*
rfc6110.txt 3222 [A-Z][a-z]*
rfc6536.txt 1583 \*
rfc6536.txt 1632 [^\*].*
rfc6643.txt  524 \p{IsBasicLatin}{0,255}
rfc6728.txt 3480 \S+
rfc6728.txt 3500 \S(.*\S)?
rfc6991.txt  477 (([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))
rfc6991.txt  525 \d*(\.\d*){1,127}
rfc6991.txt  541 [a-zA-Z_][a-zA-Z0-9\-_.]*
rfc6991.txt  542 .|..|[^xX].*|.[^mM].*|..[^lL].*
rfc6991.txt  571 \d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?
rfc6991.txt  665 ([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?
rfc6991.txt  693 [0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}
rfc6991.txt  725 ([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?
rfc6991.txt  743 [0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-
rfc6991.txt 1041 ((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}
rfc6991.txt 1046 (([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|
rfc6991.txt 1099 [0-9\.]*
rfc6991.txt 1109 [0-9a-fA-F:\.]*
rfc6991.txt 1164 ((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}
rfc6991.txt 1169 (([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|
rfc7407.txt  933 ([0-9a-fA-F]){2}(:([0-9a-fA-F]){2}){0,254}
rfc7407.txt 1494 ([0-9a-fA-F]){2}(:([0-9a-fA-F]){2}){4,31}
rfc7758.txt  703 \d{2}:\d{2}:\d{2}(\.\d+)?
rfc7758.txt 1358 \d{2}:\d{2}:\d{2}(\.\d+)?
rfc7895.txt  349 \d{4}-\d{2}-\d{2}
rfc7950.txt 8323 [0-9a-fA-F]*
rfc7950.txt 8355 [a-zA-Z_][a-zA-Z0-9\-_.]*
rfc7950.txt 8356 [xX][mM][lL].*
rfc8040.txt 4713 \d{4}-\d{2}-\d{2}
rfc8049.txt 6704 [A-Z]{2}
rfc8194.txt  629 \*
rfc8194.txt  637 [0-9]{8}\.[0-9]{6}
rfc8194.txt  905 Z|[\+\-]\d{2}:\d{2}
rfc8194.txt  963 (2((2[4-9])|(3[0-9]))\.).*
rfc8194.txt  974 (([fF]{2}[0-9a-fA-F]{2}):).*
rfc8299.txt 7986 [A-Z]{2}
rfc8341.txt 1878 \*
rfc8341.txt 1927 [^\*].*
rfc8407.txt 1723 [0-9\.]*
rfc8407.txt 1749 [a-zA-Z_][a-zA-Z0-9\-_.]*
rfc8407.txt 1750 .|..|[^xX].*|.[^mM].*|..[^lL].*
rfc8525.txt  550 \d{4}-\d{2}-\d{2}
rfc8776.txt  838 /?([a-zA-Z0-9\-_.]+)(/[a-zA-Z0-9\-_.]+)*
rfc8776.txt  874 ([a-zA-Z0-9\-_.]+:)*
rfc8819.txt  311 [\S ]+
rfc8944.txt  596 [0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){7}
]]></artwork>
      </figure>
    </section>

    <section numbered="false" anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>This specification has been motivated by the discussion
      <t>Discussion in the IETF
      JSONPATH WG about whether to include a regexp mechanism into the
      JSONPath query expression specification, as well as by specification and previous
      discussions about the YANG <tt>pattern</tt> and CDDL Concise Data
   Definition Language (CDDL) <tt>.regexp</tt> features.</t>
      features motivated this specification.</t>
      <t>The basic approach for this specification was inspired by "<xref
      target="RFC7493" format="title"></xref>" <xref target="RFC7493">The
I-JSON Message Format</xref>.</t> target="RFC7493" format="default"/>.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA6Vc2XbbSJJ9z6/IoadPkTJBcdNCul0uWZarNceL2nKd6i5J
HoFgkkQZBDhIQEvJ6m+Zh/mSmR+bG5GZAAjStXSr6nBJ5BIZGcuNyKA9zxM3
YzkQIguzSI3lt0LKU++Dmqu71VgexfI0zlSarFTqTyIlzQP5OkmXfib8ySRV
GO4GiGkSxP4S00xTf5Z5ocpm3s86iVd+tvDClDt5kZ8pnYkp3say3+0PvO6+
1x8J8Vnd3ybpdGzWjFXmvaJpROBnY6mzqQiSWKtY53osszRXQueTZah1mMTZ
/QqTnZ58fC3EjYpzNcY+ln4YjeV/nL9/d4b1vyNqOkk6x5N5mC3yyVgygbfz
gsZdS6MQfp4tkpRm8aTZ0rGf6kzF8iXtPY7xRErMNpY/xOGNSnWY/d//ZPJl
qpbo9PGnU+6gs1QpUH+W6GzmBws5GHSHwy4/C8LsfmwHmIZkinVeef3Dwd7I
tuRxlqLX94oWvefG1SKJ0e/pcOQN+z2v3zv09gejfo8fKrPpwJ8k32W/hHa/
bg8fwyUW9O9L4j+quyz3I5CyvuCxH/tTvzplNsHA77KifydIlkLELAlgALHq
b+cgfix/HBx3Ppwce3fLSAcLDPf6Xr/bHfa6/UPTq9fb2o+a0bPX7w67e+j5
4fXxXn8wHEt/Es/M9wM8Md+9QAsRxrMqAegw2O+Pxky3N5Z5Njvkz9NQryIf
+zr/+Gp/wDL+qrMunhNfg0PuK7r88O70+P2rE+/7N+/Pz48+/N3MavXk+yjR
2k/vZTIjAaCjAy/TpTad/HROx77IspUe7+7mpgedxu7cjtzlnqWcVeWJOreh
BkHHUM+qMvMjrWiTJ/01Ur61g9EuQy19dNRZW2p/hjmyRar8qTdLQxVPo3vp
R6RazDCZJXLiB5+zFC9hPJeQ/TzyUwkFSBWrlVTxPIyVllH4Gf0XiVYy12oq
w1ieHX84acszlUZt6cdTeXaP53FHnmaGiuOnTzEMQpPed9aY0nBcMVpIcrQ7
T5J5pHZT1W+gL029fY+0nIcBOKLQ2iMm+aQgWcsmbFJIRB6dnY7NXK1NArD+
KkjNkQR5mqo424X52l1ky2iXiDg5fnvk9fcdHbUTvb297agAoh3GlqFJ7Ec8
2+0KFKIVE+arKPGnetfN1VlNZ9VtUft5kIarjAxhV77x43nuz5U8X6kgnIUB
z7shKJ4RlBOsb22lXb8iLTQfDKuxQgrHr0lXnKDRwlCGDAfnp9Nir23Z62UL
eTINeV3heR50TZOEZEJ8XOBgwaMcBiuT2pAI4XDmv02yF/k3SUpasSlNGhLk
k3SIKFyGmREjHcC5yFuIAp4qOU/8iEaHhdshSqQfpNAaSTYQujybKTovYZfw
KgJrJA5UdQz1y3A6jZQQYFOaTPOAZ7N/D09Can0Uzyt/wu5TV09ATpXGMU2w
WT+u0EYiuEVrmg3jRhoty492wSOQJdxn8BITxkkmV2lyE8KC+NMbPw7AmC2T
zpSf5fgidQ4/4mvY+BU1yHma5CvdllGSfPYX0PY2xIM1O1XMqIC4AbXU+WqV
pJmWSUyWAJ4siRT2A/sZLMgAYEZ/EpJxb8uwozowH/DU9OR2oXA6KQbNYTni
bfTxLMQg22UVqkDRUZLL6FR2XZBB541jhM/FfGBnltDHikENFj5JHpyrbNo2
oQOfFr7xo1zp1jM5SazklPNnKUjm6ZdaRTd8aFPuYx8JfAYDsJgheir9uR/G
OuM2rf4rZ6ZVSVlbVjaTGfQb8ke7xxaMKP/w8bV3iB1hAPGMPJN8ePDICT0+
0lcjOdhVPFetKkvYYALNaJXRovCQW9Xn4YE97ONjp66MYRxEOYRUzvNwSiLE
y8EMAZnwAbqlND+ADTcqpxU6QONuVRR5n+PkduvRhtMwWWpeVEEVblSUrHhZ
0Frs4RYiuUzgWHxix+SeGQ4895llAJ8dEJM/opFo+p4EtyNp0rUmTMUshX+y
+4Kfl2FWV0rw1rlr8NeKFe+PlqM9fsUMYbaCmFlIHhHqM8kz3kMes1pj8VkI
sfFpolkeifW1aZVtU98uQmjnbZJH4IGqmQprxYi6VbLisVV79eQJQ4gwTqJk
fl8/YpBhhhrUHRo6nKVhgm7JvJII5xoYLboHco6irdaEeQCrM0/9JRacd0TD
HWSDpJGdvE9SGQMRyiXMBB2PX6qk1SXZdOoCZout2tIyZh/CSBqhibO0jRTj
Qga/mabzzTas7jPDqSgnCcXDgkTd6Gy10swiR0NWsrIjjuBYkilZG0C2VRKy
yjAh7JCcAWa5fXioIz+rcEoiQiGRnoKWtz+cf2y0zbt8954/fzj56w+nH05e
0efzvxy9eVN8ELbH+V/e//DmVfmpHHn8/u3bk3evzGC0yrUm0Xh79PeGAVqN
92cfT9+/O3rTkI5thZDQ4ROss5KH4874IIVzYGyoXh6f/e9/94bY6b8BMfd7
vRH0x3w57B0M8QX2Pjarsa8wX8lqCn+1Uj5ZMkDJiDxGmAGXtklY9ILsB9yE
Art2LogzV2P550mw6g2/tQ204bVGx7O1RubZZsvGYMPELU1blim4udZe4/Q6
vUd/X/vu+F5p/POLCPhYer3DF98KIyOsUpBHqIBM80jp339K8ujlu9dtgQ9r
xwU7RwEPjoUOxH5D+PP42KaTocmwbqP0lg3SxYeHc2XgTr8zIEtYTIIBWxWV
TJB8P/mZhsFrlv6Jj5YsGjzXNDLL3SDIgPv8OUkBF2j6FS3Ouw580kNDmS8K
dJEWvi5Wamq25hNa9eE3piqqKXNCaAOmJb0XkYPFpQGzCqmAVJNUGxdTZTGs
DaE9Yis8Q3qj7p0bsmTo+zjz74SLZlb5JAo1QQEoge7IIwi3uvOXKzrAGWwg
AwhCBwtn24MEvtOYjIJRbcF4hCc33CCkhcEO4IYGBMS0f42QF/AnAON5L3eB
WvHWQ131YMs8ykKvNLwQDX+loHLG5MPfCHKzfspUFgCgatVYiJZQXZwDG7Mn
pd8+Z0YADE/VLH4UgnI+7hlrrDXczm6TjNaOKowhbS69Y6QMa/zjH/8wgXvo
WZ4/l3B2MfzjTlM2vjTct5awH57LHUaNwmDH59LPkqW8gBQQnxBrpPJKVL48
l5hnpyF3ZeMpv75oyBbeUwJYXtlR1BswsvHQkH+lhpM7sBWLNNoNvFaarvBf
47EhKk3PZW/nT3eDrjcYyWfym+433jejb4RgMp/Ld5SKiI5xUKCBzus48uHu
d4nKJoy1Y0OjBTJFpTft40933a7XP6BdtHkvHr3+6a7/2huc0GK7WOzbbwQ3
Drve3hE1fofGn2zj3ol3wI2f0PiLbTw48Xrd1/jDiiVJ2H6Hpj+HPESKaDjR
QZXo+lfonVjvjCkuG0x3/9Drv6R1m1j3Ka9riDdr0KEweS+9Pd7IBbp9MuTp
Rtww76l9z0zng5fewSvq/IDOj+hcod6sDtGzRCZQUnwUa9QSfRd0oI1PDZxj
05J0fHzSg4js8PsFN+KQrxqCG+gcjo9pHvvMfrliqaoSIOyT8uSOzWmd2IPp
rB+MO4M6z4XdxnPa++UKMknTngEysui5vdnnZxvP3Zfn8lQfA3jPE5jL8iPa
36iMA6hd+dZPP9P7u3w5MS1neRxkudFhEKZWMDFsTk1u6vx+OUki6viebJ8W
bi6m5g1xt0mfInt2S/uerJ2lbuSklVfCrM9j3xZjA9tHNQp5oL6ORu79rug9
tb2iciXqXd0HjzizI+72B97+Pp1HgPOYOaELa4RqM02FATzLTxs7XNUGWAZx
7/ONPX3e5AuNMsw0g443Bs0a64phB8GYioexfFK1siaL9LxRN+Ww9mSkG2TM
OWHhT01ChxCJItzOuKAtr9dU5ppdc5IRsEtuOf4yzlteX3y6um7b2MYPAiBg
cujsEDDGIJ7URj3gIfwWxQ5ileiQM42l8wrY/lB+DAE3T0JhOatEpdf1p2uH
8PE/PD6lCdiX2tCYA0641ARBW21yuhXghBVv0XX6ihMtkinXl/q6La4vz68N
7L2+vLWf3AwOMk2iJPhMWKnqKEMCCgQ8jBCy3wRE8I11Aryr97CApciEmeC/
I05jYiBAAQVscPE5cEg9snWUzEjs+VgJgsF9A4qSrxeboRSx0SFtE1at0yMc
NpdMEAXbKprRCR9QslEeepOwymnQWvLu6Pz49JR4ZWZx5FZJLUeuOBwGvZTr
gKTWTs8FwscLZZLSp2t0auCUwD4i8ZY77tvOVw8jpISXskEo9TbJltUqCtVU
WGEy6RIMDBk8Wbi2wUYSiFSZ9BXlIrEbBPaUGykIDmsEzznVzsgPgC5l4Z8B
ldEyTBMno6bhNP4mE1AuepSxrIcx+mdQydhbzyMY7NqWOpFBsayuxjEdceLQ
pC70lKIRQPZ7ksylPzU5Iqi6p2YzOrAa5YKpA2osOYuZfFgIygRavtkMP4Fg
zeOlztSqkA0Bkgk8Ok23GFQWmV1NVzNBrvUGSn3GkSRHncISaOMGUDFNjGoU
26dtTW/91GF8nVm8L2rSYKaCotWOycaNRQDhMp5FqrBYCkwDDyCma0l6m9xW
mDYpAwKmi9JZTDRrKG3ToHYTJ9mgoEZOALPNyTOWRJ+FoKCguG+t7Y3NFUL1
Gm+KiKstYZF1OGHZYuZAfgOYV+IVU2fPCQRRKF+bvqKglfDBBTEuI2N90HpG
k3mD90oGs34AxrsUAXElY0lWRdyHCs7FpaxxwDDomrMO9h7Cyk8xf/NcwQBH
0JGHhzs9teAbQXOnRRt4ayWxKtv20yu4GsTAZGucNJpoE95QpSElo1y6ykbY
7Dhjr7gMbZehl1/mZAXLAGdPyQ7cLpJCNCjUKzdsDoe9pLpjvrHOic08HrTH
0Gqs5lv2cseFST0xXk6I42S5pBz9V7xg8+3xiW4Zf7dhkOUkDyNKWrgoeNkW
FgpALQgwWItvjqC8DSIZdpnICef4Iz8wLDGpIrI/Nsg2h5dNIg9Cw+HjFwmi
dg1e+IKj4cFGHejvi/jilX/Vz64JM5A/N3c9XwjEyMvsMr5Mr67dDGi8PJf8
nTusPTcdLqeVGbreyD00HQiSWaIdGjuxGyLhR1OeKZNz/wrvCaW9S7LSF5Rp
ATp4Xh+8+dqVQKidbgG8rB7eTR+vYTgB325U2jZCamCZzaRz1m7L/UpmU8di
Gs4p044lb/w0THKMT0O+QtD3MO1L7XAgaXi0TGBoA3gpoDlYFRKGW3vHZ/O7
RiZOPr42KRZrLG36hgo6sjRHZE3En+qXvg6DN+gSP17XkZ8vi+ss0phIzf3g
XjD2aEsCJ5C2qpTZG4g69MSJ5138efR2MLu6NppD/LXqR8iuYsHZhISMo8tO
paFhL1x1baYre3GqqnAgrVM9Zl/O1K1UaUrJLxKOYjq58AEXJoqMeHhXMWpU
G2ESfuQ6TIYIDElSa+Ts+RZZe2uJSqZ1BJHf6/SIwoiM/i2IJFfgDDG51oXd
Zq/TNeagDgrs9RSes/pTYQDmKK9qiC4Ys0k+J/o1s8cBV858ZVrQvKs8hTNS
ZequDrS2IGa7sMVsJjaAkN3ABBoz+iujehaxWEtZuXl3VvfhSZacnKMXNPLM
wBamepZQPMQawNDGUFf1G8mE5J9ay2kdsHx4cJfrj49jIXaodoqhYx4bCzAF
5oDCNa871y2JQEOH0w2pJRM9C1O6oCzrNxCjk4EoYrhrcjr2irs1dopAs5Mu
kHVj29YBDSex8UIOLME0kaBdf2q+GF+b+Kf179dWSSusKlO4W9PXfmFZVj5l
CugmPG+IWeTPn8GsKVlkpHudfqcvG2e2WwEiGgYklCxrremNzSmX4DNT9m7I
WZu24CsySgdErhuBH0cxNCFKLNi83rXKb0pZPpz08ZKDV4UhqIqB9pcO3Pra
uisrL49VIaBkejgtWBULmh2duRCFNJgm+z6p3r7JIsH98GA7uRtrokds69q2
+eLSb0SUkScCwQ+WtBOz12rWm3Z9eVQ55ctfiAdvzb2tw5Av/eDz3Lj7hyeT
4st6ocTz9aqJHxfh1mII6EsKlxKzDb+l4yvy3wyHzD2H9AUXckUlK/DURZJb
ShWcWbW3UqXVVPHClFAwUqBkRLW7dXTVEBUIy2YLhI3uSG3c9bafIvDlCIcG
mP3MrL03pQNc3iB/dAEjhXBQCGt7XNFGu6BkLW6i6hlLOoJPJZZkznWuOXSz
t9CwpKaAQcNipiFPYqMqDlWnCrIxrYJoYV0h1okSV2fzSsWhKa05V+lNiIHQ
PZ+CYQgY5Yj4m0oZlhLyTCmzVb0woWLLjGbD0i5woKtjWS1jwIGG89gcbkJ1
OtUrcFtawrJN2ijYDd3kUWwDWz5zApaGtHZZF4QzmCoPM9orW1vFUrhXa5PM
kr6clHHCiopGSWXxuCxjKQysKO6vQ12c6eS+MDLGQhTBylrI8PDERDiZCRHK
3JRm35iqiA01BF/52jhJNw9FkRRaE1HshkXVDdeExYH8kh+agTfxTBTXRkbp
j2t4p5IN60jpUmqwUgoybUobnJSSmNgq0zVnbIsjQr4pz+kyKMvhgmhfhP8I
m00Ip8lZmiwd7ZikRj1VeuS6bedJnDDRmEp11I4NYjaAMqgnMNy2qTlK2Dkr
SamVFSSMAmohbc7NXANa76nuFiFlsKiiNaJSPukvqdSV9IFwrrF9E5XdKlPd
xDkhrt3SzDYi3KUCyPF+lfp3JoFaGNwafJKlUQtIgRTLZVGzQCfqMglch4IB
6k4FOQteAZereUsD+tvoCGywSPK5URg8gH+7PLuunu5cxc5hxsmthMvMaAUL
BP0bP4xoUZgztuZcIwJcF3KAZgolTAKBVBUDIVmxpnpuK5NcU1GcnGck0BaG
2WiEwar11sQOwwaTo2JnxSxwsrJhLalikGIb0hhpGeJz3lPFN2GaxFxPwmkX
CkbIsxSGxfC9SJ5Id7PpMzoWp0fvjuQxZgQ3bHJqi8Orl+Us/c9cxMd7Ujpj
/0BTUaUf8E7O9+PBb0275kUzFSxie3lMqWfMaMokt2Lltiyv+ntdynvYRdf3
0uIaAFuM5nP2U6+ZJBeZnRX5Z2KhWoNPGXYbOw/IgIOuTOCAVguD3BwhA9E0
5XAmrcSYtELAszUIXcPsfHjKXkBg6JwEjPPS/poHhqPOGJ7VE742OwPh8dNp
h29BalnGCqgB2GK3a6zG3abIgRxhLyycS2WZYscML+PuQoLU1wtbbJiqJbGO
Kxat/lr7ywjIqgFvwmSQHS6BVpcrc5UhAwQAnHTqZYkHWDUNES9XEUChcKEm
DN2uEmU9qcnlUsECFSRviZPg8QpsVRRD8n4VhAgEOHzgWWxg68qM2StTVyUQ
qyIBvlHacky+vPXvi6pgGAQgBBvK2brOFMZLPzPnmbjSlDWR9KdTgppqij2m
ZP5IYzZvOIrE77tqJrWedm1SlPLwUFwxPLZqUS42CSsF0GB1rCaWFNhZATKl
88ZpwM+6tInNvxPyEfbsqVhIhjNn9nnYArad2WiSb7ZYc7s1IbdNpYpN1Zl3
2i6GaD1jmLN1oySBkBW4qbU7g42crBFKZ2yiarKgVnNrMr0Anm3BtAY+5e4n
ak0MrPvBNGnO50/FUzAzWYjQiiHuiiJWvsGit1WeFWhxiiAzyEx628SCnNay
Rp4zPfD+5gAnCG5vKXI8uQtN/fLamehKEY/zDgBoIeiyBU6c1iqEWjT9WWau
AiBtP+c6M07mazcXLYOX6KTppOAnGKRpbfIxOsnTwCYFNVC/pB8v6WotLcVM
ZPgROC0o6CaxJ5YsKU7wc22lCtym7SNcSqlgVpGIhwErUGlzRLMMn4vKeck/
WKqYUg5ua1c67qaIjCMQ/xasvrkru+FVUSNrcAHfdFDe/bwiS21Tp1Op7oH+
mdD62n/ot4eP162iMr68FKWiB1gfjDQsZEOh3EGTtBRSOYOT5uOpu7iPTNWS
bY/LopmLz02S6I4SriHRNn4RTZy771JCkCbCgZvDCoDWNHtpuR0lthxJrs3D
cNwgU35amQDju+0+5Sy7GM/F/UYZbLxK0sGG5zeOgyXH5UWXa+Xn29Te1BEb
xVVUIEhe2IU3hHsF/VQs5+07kbZem/OwyQTPbNFYIQKlhSEe5RzkqJqSlv6P
SKBy+hwQw0zM9kwYyO8gmLFohPCgAjCjFjLwTvjiju5b5zlLbbu4mOTj5tPd
xqzS7DicV96KUcCtuNzZ7DEmxTBJNE41UEhgrgE5Z0jrVUiyv0shACKEU3da
7BwEEeY6LkE+iPugAlr9bK08EYFnOgv0r+RjfuNPPIwJodyoMMZEjxbTUmlv
PA3vXHkGJ5K5EOdXf89TuHxhUykuLmLjlvIGYFrXKywl/dyOqotNL3/qLZKg
gCAdYYJALq4toh6T4VD20sklvDviR5ckKCsoCTHTvOaHGpXUCQiZ5hO612hB
/CjPtFlhKdy1mM/1/2vXDhxaVS8qrtcLQ9qEdbZc1GmTFiQdcvCqKKZk77Gt
fFLgcPa7/V4nu8ukHO6NZLN50fV6V83LzkXPG1y94BupVutLs3/ZaXa/NNE6
urqc7rTwtz56rzeQeICR9Pih1+71Dx5rXfojdHkYPnp47dvXj/w6rrzyFE9b
L9YH7w96kogb+d7syHt9RR3H699bOxuDhgfyN8Y87NWoHA0GYMP4S7Vflwzs
uNWst41beNuc4JD4+Gl89RTP9x/dZ34FKzs7l50OcfDL2rhet7//Ly3c6xKL
/sjCXR63X+PSjnk62uOn/b3hUF6e0+Bzy95ezwzs7R0O5IWvIO33dpR7NOj3
+/LiyPvp6sL3frEP9wb75bjLWtv+AAM+Xe5cdcyD/eHASQ3Wr13eYfP9Pbv9
g/6hWXJ42AWhT9cb97rdGvWjkZP3g4M/Lu/F6L3+3lfkvewy7EnaPtjwn1f2
A+a/9P6zYzlS6dqXnS+dzpeLT3d/Awu+dC4+Ld/yB3yK3jiulAMOen9Yl4rB
+/t7v1uXykGjwe/VpWLMQf+fWOhguL7Q4aNX/Trc+Lo2vNcd9v4pNapMsP9H
1KgcNxox3Zf104VSjCo7Gm/psD/812ju7Y/+AM0Hw+5BxdhVVmjxCdVbWqxv
w8e1sb3haPi7xg7bg54ZerB3aI+4S87iV2S16Nob7B3+RtdDa6lgAbb4F+4y
2jNm6XDQH2yYusrTvb1fV9hq1315AVW9gJZeFPp52B2a58MDdodbaEGXkTG7
B92hMZHuSW80tKpGjnKn1jYwRpr0AdaKP+3Xxo26e/KnLxeXTy+9qwq3ap32
ceT9ZrN/MSRb96U5sEbvstPq1BYdHZBcXsxYU2t6O3a9+yOzoYPR4f76hgZD
K56HB4duQ0XbqH9QNfiHhVwd2DNyalJ5ggP+1fOpdN3r/h6Deggzbg0qBmw/
sIMD46Jw6Idy90WztvDTVnN3o2mnNpL4WO80tr3Abiu/PfgLqhdiH3Y4GtpT
2Bvt/6blhe+pl3AXPy+qFQ5tA4/ryFoQguby7oB+sxup6dz+jnIL0M9jg+HV
9HHrjyaLTNPGj3dtfqNIqSpTx8M/nT36+Bfx4/fSn1C2raiVLKtAijv6paLf
O4d66X5wWfkhsPl1V6WarZbX9jX/MJneJ1Rrq264IKmkS1sCqJTx70fvvpfX
tvDAXA0dv3r1Rl53DCXFRYgrPpoQXqGgJ03oX2Yx2YoN9txyRkKvwtT9OvQF
/zMk8LZNzIIgmrYj32IHFE2YfxmnRQj+/wFBwVDGXEcAAA==

-->
</rfc>