rfc9485.original.xml   rfc9485.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!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. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
1) --> -ietf-jsonpath-iregexp-08" number="9485" submissionType="IETF" category="std" co
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft nsensus="true" tocInclude="true" sortRefs="true" symRefs="true" updates="" obsol
-ietf-jsonpath-iregexp-08" category="std" consensus="true" submissionType="IETF" etes="" xml:lang="en" version="3">
tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.17.4 -->
<front> <front>
<title abbrev="I-Regexp">I-Regexp: An Interoperable Regexp Format</title> <title abbrev="I-Regexp">I-Regexp: An Interoperable Regular Expression Forma
<seriesInfo name="Internet-Draft" value="draft-ietf-jsonpath-iregexp-08"/> t</title>
<seriesInfo name="RFC" value="9485"/>
<author initials="C." surname="Bormann" fullname="Carsten Bormann"> <author initials="C." surname="Bormann" fullname="Carsten Bormann">
<organization>Universität Bremen TZI</organization> <organization>Universität Bremen TZI</organization>
<address> <address>
<postal> <postal>
<street>Postfach 330440</street> <street>Postfach 330440</street>
<city>Bremen</city> <city>Bremen</city>
<code>D-28359</code> <code>D-28359</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<phone>+49-421-218-63921</phone> <phone>+49-421-218-63921</phone>
skipping to change at line 37 skipping to change at line 37
</author> </author>
<author initials="T." surname="Bray" fullname="Tim Bray"> <author initials="T." surname="Bray" fullname="Tim Bray">
<organization>Textuality</organization> <organization>Textuality</organization>
<address> <address>
<postal> <postal>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>tbray@textuality.com</email> <email>tbray@textuality.com</email>
</address> </address>
</author> </author>
<date year="2023" month="June" day="29"/> <date year="2023" month="October"/>
<keyword>Internet-Draft</keyword> <area>art</area>
<workgroup>jsonpath</workgroup>
<keyword>Regexp</keyword>
<keyword>Regex</keyword>
<abstract> <abstract>
<?line 67?>
<t>This document specifies I-Regexp, a flavor of regular expressions that is <t>This document specifies I-Regexp, a flavor of regular expression that is
limited in scope with the goal of interoperation across many different limited in scope with the goal of interoperation across many different
regular-expression libraries.</t> regular expression libraries.</t>
</abstract> </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/bro
wse/JSONPath/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/JSONPat
h/"/>.
</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> </front>
<middle> <middle>
<?line 73?>
<section anchor="intro"> <section anchor="intro">
<name>Introduction</name> <name>Introduction</name>
<t>This specification describes an interoperable regular expression ("rege xp") flavor, I-Regexp.</t> <t>This specification describes an interoperable regular expression (abbre viated as "regexp") flavor, I-Regexp.</t>
<t>I-Regexp does not provide advanced regular expression features such as capture groups, lookahead, or backreferences. <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 re gular expression matches a given piece of text.</t> It supports only a Boolean matching capability, i.e., testing whether a given re gular expression matches a given piece of text.</t>
<t>I-Regexp supports the entire repertoire of Unicode characters (Unicode <t>I-Regexp supports the entire repertoire of Unicode characters (Unicode
scalar values); both the I-Regexp strings themselves and the strings scalar values); both the I-Regexp strings themselves and the strings
they are matched against are sequences of Unicode scalar values (often they are matched against are sequences of Unicode scalar values (often
represented in UTF-8 encoding form <xref target="RFC3629"/> for interchange).</t > represented in UTF-8 encoding form <xref target="RFC3629"/> for interchange).</t >
<t>I-Regexp is a subset of XSD regular expressions <xref target="XSD-2"/>. </t> <t>I-Regexp is a subset of XML Schema Definition (XSD) regular expressions <xref target="XSD-2"/>.</t>
<t>This document includes guidance for converting I-Regexps for use with s everal well-known regular expression idioms.</t> <t>This document includes guidance for converting I-Regexps for use with s everal well-known regular expression idioms.</t>
<t>The development of I-Regexp was motivated by the work of the JSONPath W <t>The development of I-Regexp was motivated by the work of the JSONPath W
orking Group. The Working Group wanted to include orking Group (WG). The WG wanted to include support for the use of regular expre
in its specification <xref target="I-D.ietf-jsonpath-base"/> support for the use ssions in JSONPath filters
of regular expressions in JSONPath filters, but was unable to find a useful in its specification <xref target="I-D.ietf-jsonpath-base"/>, but was unable to
specification for regular expressions which would be interoperable across the po find a useful
pular libraries.</t> specification for regular expressions that would be interoperable across the pop
ular libraries.</t>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>This document uses the abbreviation "regexp" for what are usually <t>This document uses the abbreviation "regexp" for what is usually
called regular expressions in programming. called a "regular expression" in programming.
"I-Regexp" is used as a noun meaning a character string (sequence of The term "I-Regexp" is used as a noun meaning a character string (sequence of
Unicode scalar values) that conforms to the requirements Unicode scalar values) that conforms to the requirements
in this specification; the plural is "I-Regexps".</t> in this specification; the plural is "I-Regexps".</t>
<t>This specification uses Unicode terminology. <t>This specification uses Unicode terminology; a good entry point is pr
A good entry point into that is provided by <xref target="UNICODE-GLOSSARY"/>.</ ovided by <xref target="UNICODE-GLOSSARY"/>.</t>
t> <t>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
nterpreted as be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
only when, they when, and only when, they appear in all capitals, as shown here.
appear in all capitals, as shown here.</t> </t>
<?line -18?>
<t>The grammatical rules in this document are to be interpreted as ABNF, <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 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 val ues.</t> <xref section="2.3" sectionFormat="of" target="RFC5234"/> are Unicode scalar val ues.</t>
</section> </section>
</section> </section>
<section anchor="objectives"> <section anchor="objectives">
<name>Objectives</name> <name>Objectives</name>
<t>I-Regexps should handle the vast majority of practical cases where a <t>I-Regexps should handle the vast majority of practical cases where a
matching regexp is needed in a data model specification or a query matching regexp is needed in a data-model specification or a query-language expr
language expression.</t> ession.</t>
<t>The editors of this document conducted a survey of the regexp syntax <t>At the time of writing, an editor of this document conducted a survey o
used in published RFCs. All examples found there should be covered by I-Regexps, f 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. both syntactically and with their intended semantics.
The exception is the use of multi-character escapes, for which The exception is the use of multi-character escapes, for which
workaround guidance is provided in <xref target="mapping"/>.</t> workaround guidance is provided in <xref target="mapping"/>.</t>
</section> </section>
<section anchor="defn"> <section anchor="defn">
<name>I-Regexp Syntax</name> <name>I-Regexp Syntax</name>
<t>An I-Regexp <bcp14>MUST</bcp14> conform to the ABNF specification in <t>An I-Regexp <bcp14>MUST</bcp14> conform to the ABNF specification in
<xref target="iregexp-abnf"/>.</t> <xref target="iregexp-abnf"/>.</t>
<figure anchor="iregexp-abnf"> <figure anchor="iregexp-abnf">
<name>I-Regexp Syntax in ABNF</name> <name>I-Regexp Syntax in ABNF</name>
skipping to change at line 128 skipping to change at line 117
branch = *piece branch = *piece
piece = atom [ quantifier ] piece = atom [ quantifier ]
quantifier = ( "*" / "+" / "?" ) / range-quantifier quantifier = ( "*" / "+" / "?" ) / range-quantifier
range-quantifier = "{" QuantExact [ "," [ QuantExact ] ] "}" range-quantifier = "{" QuantExact [ "," [ QuantExact ] ] "}"
QuantExact = 1*%x30-39 ; '0'-'9' QuantExact = 1*%x30-39 ; '0'-'9'
atom = NormalChar / charClass / ( "(" i-regexp ")" ) atom = NormalChar / charClass / ( "(" i-regexp ")" )
NormalChar = ( %x00-27 / "," / "-" / %x2F-3E ; '/'-'>' NormalChar = ( %x00-27 / "," / "-" / %x2F-3E ; '/'-'>'
/ %x40-5A ; '@'-'Z' / %x40-5A ; '@'-'Z'
/ %x5E-7A ; '^'-'z' / %x5E-7A ; '^'-'z'
/ %x7E-10FFFF ) / %x7E-D7FF ; skip surrogate code points
/ %xE000-10FFFF )
charClass = "." / SingleCharEsc / charClassEsc / charClassExpr charClass = "." / SingleCharEsc / charClassEsc / charClassExpr
SingleCharEsc = "\" ( %x28-2B ; '('-'+' SingleCharEsc = "\" ( %x28-2B ; '('-'+'
/ "-" / "." / "?" / %x5B-5E ; '['-'^' / "-" / "." / "?" / %x5B-5E ; '['-'^'
/ %s"n" / %s"r" / %s"t" / %x7B-7D ; '{'-'}' / %s"n" / %s"r" / %s"t" / %x7B-7D ; '{'-'}'
) )
charClassEsc = catEsc / complEsc charClassEsc = catEsc / complEsc
charClassExpr = "[" [ "^" ] ( "-" / CCE1 ) *CCE1 [ "-" ] "]" charClassExpr = "[" [ "^" ] ( "-" / CCE1 ) *CCE1 [ "-" ] "]"
CCE1 = ( CCchar [ "-" CCchar ] ) / charClassEsc CCE1 = ( CCchar [ "-" CCchar ] ) / charClassEsc
CCchar = ( %x00-2C / %x2E-5A ; '.'-'Z' CCchar = ( %x00-2C / %x2E-5A ; '.'-'Z'
/ %x5E-10FFFF ) / SingleCharEsc / %x5E-D7FF ; skip surrogate code points
/ %xE000-10FFFF ) / SingleCharEsc
catEsc = %s"\p{" charProp "}" catEsc = %s"\p{" charProp "}"
complEsc = %s"\P{" charProp "}" complEsc = %s"\P{" charProp "}"
charProp = IsCategory charProp = IsCategory
IsCategory = Letters / Marks / Numbers / Punctuation / Separators / IsCategory = Letters / Marks / Numbers / Punctuation / Separators /
Symbols / Others Symbols / Others
Letters = %s"L" [ ( %s"l" / %s"m" / %s"o" / %s"t" / %s"u" ) ] Letters = %s"L" [ ( %s"l" / %s"m" / %s"o" / %s"t" / %s"u" ) ]
Marks = %s"M" [ ( %s"c" / %s"e" / %s"n" ) ] Marks = %s"M" [ ( %s"c" / %s"e" / %s"n" ) ]
Numbers = %s"N" [ ( %s"d" / %s"l" / %s"o" ) ] Numbers = %s"N" [ ( %s"d" / %s"l" / %s"o" ) ]
Punctuation = %s"P" [ ( %x63-66 ; 'c'-'f' Punctuation = %s"P" [ ( %x63-66 ; 'c'-'f'
/ %s"i" / %s"o" / %s"s" ) ] / %s"i" / %s"o" / %s"s" ) ]
Separators = %s"Z" [ ( %s"l" / %s"p" / %s"s" ) ] Separators = %s"Z" [ ( %s"l" / %s"p" / %s"s" ) ]
Symbols = %s"S" [ ( %s"c" / %s"k" / %s"m" / %s"o" ) ] Symbols = %s"S" [ ( %s"c" / %s"k" / %s"m" / %s"o" ) ]
Others = %s"C" [ ( %s"c" / %s"f" / %s"n" / %s"o" ) ] Others = %s"C" [ ( %s"c" / %s"f" / %s"n" / %s"o" ) ]
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>As an additional restriction, <tt>charClassExpr</tt> is not allowed to <t>As an additional restriction, <tt>charClassExpr</tt> is not allowed to
match <tt>[^]</tt>, which according to this grammar would parse as a match <tt>[^]</tt>, which, according to this grammar, would parse as a
positive character class containing the single character <tt>^</tt>.</t> positive character class containing the single character <tt>^</tt>.</t>
<t>This is essentially XSD regexp without character class <t>This is essentially an XSD regexp without:</t>
subtraction, without multi-character escapes such as <tt>\s</tt>, <ul><li>character class
<tt>\S</tt>, and <tt>\w</tt>, and without Unicode blocks.</t> subtraction,</li>
<li>multi-character escapes such as <tt>\s</tt>,
<tt>\S</tt>, and <tt>\w</tt>, and </li><li>Unicode blocks.</li></ul>
<t>An I-Regexp implementation <bcp14>MUST</bcp14> be a complete implementa tion of this <t>An I-Regexp implementation <bcp14>MUST</bcp14> be a complete implementa tion of this
limited subset. limited subset.
In particular, full support for the Unicode functionality defined in In particular, full support for the Unicode functionality defined in
this specification is <bcp14>REQUIRED</bcp14>; the implementation this specification is <bcp14>REQUIRED</bcp14>. The implementation:</t>
<bcp14>MUST NOT</bcp14> limit itself to 7- or 8-bit character sets such as ASCII <ul><li>
and <bcp14>MUST NOT</bcp14> limit itself to 7- or 8-bit character sets such as ASCII
<bcp14>MUST</bcp14> support the Unicode character property set in character clas , and</li>
ses.</t> <li><bcp14>MUST</bcp14> support the Unicode character property set in character
classes.</li></ul>
<section anchor="checking"> <section anchor="checking">
<name>Checking Implementations</name> <name>Checking Implementations</name>
<t>A <em>checking</em> I-Regexp implementation is one that checks a supp lied <t>A <em>checking</em> I-Regexp implementation is one that checks a supp lied
regexp for compliance with this specification and reports any problems. regexp for compliance with this specification and reports any problems.
Checking implementations give their users confidence that they didn't Checking implementations give their users confidence that they didn't
accidentally insert non-interoperable syntax, so checking is <bcp14>RECOMMENDED< /bcp14>. accidentally insert syntax that is not interoperable, so checking is <bcp14>RECO MMENDED</bcp14>.
Exceptions to this rule may be made for low-effort implementations Exceptions to this rule may be made for low-effort implementations
that map I-Regexp to another regexp library by simple steps such as that map I-Regexp to another regexp library by simple steps such as
performing the mapping operations discussed in <xref target="mapping"/>; here, t performing the mapping operations discussed in <xref target="mapping"/>. Here,
he the
effort needed to do full checking may dwarf the rest of the effort needed to do full checking might dwarf the rest of the
implementation effort. implementation effort.
Implementations <bcp14>SHOULD</bcp14> document whether they are checking or not. </t> Implementations <bcp14>SHOULD</bcp14> document whether or not they are checking. </t>
<t>Specifications that employ I-Regexp may want to define in which <t>Specifications that employ I-Regexp may want to define in which
cases their implementations can work with a non-checking I-Regexp cases their implementations can work with a non-checking I-Regexp
implementation and when full checking is needed, possibly in the implementation and when full checking is needed, possibly in the
process of defining their own implementation classes.</t> process of defining their own implementation classes.</t>
</section> </section>
</section> </section>
<section anchor="i-regexp-semantics"> <section anchor="i-regexp-semantics">
<name>I-Regexp Semantics</name> <name>I-Regexp Semantics</name>
<t>This syntax is a subset of that of <xref target="XSD-2"/>. <t>This syntax is a subset of that of <xref target="XSD-2"/>.
Implementations which interpret I-Regexps <bcp14>MUST</bcp14> Implementations that interpret I-Regexps <bcp14>MUST</bcp14>
yield Boolean results as specified in <xref target="XSD-2"/>. yield Boolean results as specified in <xref target="XSD-2"/>.
(See also <xref target="xsd-regexps"/>.)</t> (See also <xref target="xsd-regexps"/>.)</t>
</section> </section>
<section anchor="mapping"> <section anchor="mapping">
<name>Mapping I-Regexp to Regexp Dialects</name> <name>Mapping I-Regexp to Regexp Dialects</name>
<t>The material in this section is non-normative, provided as guidance <t>The material in this section is not normative; it is provided as guidan ce
to developers who want to use I-Regexps in the context of other to developers who want to use I-Regexps in the context of other
regular expression dialects.</t> regular expression dialects.</t>
<section anchor="multi-character-escapes"> <section anchor="multi-character-escapes">
<name>Multi-Character Escapes</name> <name>Multi-Character Escapes</name>
<t>Common multi-character escapes (MCEs), and character classes built ar <t>I-Regexp does not support common multi-character escapes (MCEs) and c
ound them, haracter classes built around them. These can usually
which are not supported in I-Regexp, can usually be replaced as shown by the examples in <xref target="tbl-sub"/>.</t>
be replaced as shown for example in <xref target="tbl-sub"/>.</t> <table anchor="tbl-sub" align="center">
<table anchor="tbl-sub"> <name>Example Substitutes for Multi-Character Escapes</name>
<name>Example substitutes for multi-character escapes</name>
<thead> <thead>
<tr> <tr>
<th align="left">MCE/class</th> <th align="left">MCE/class:</th>
<th align="left">Replace with</th> <th align="left">Replace with:</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"> <td align="left">
<tt>\S</tt></td> <tt>\S</tt></td>
<td align="left"> <td align="left">
<tt>[^ \t\n\r]</tt></td> <tt>[^ \t\n\r]</tt></td>
</tr> </tr>
<tr> <tr>
skipping to change at line 230 skipping to change at line 225
<tt>[^\t\n\r]</tt></td> <tt>[^\t\n\r]</tt></td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>\d</tt></td> <tt>\d</tt></td>
<td align="left"> <td align="left">
<tt>[0-9]</tt></td> <tt>[0-9]</tt></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Note that the semantics of <tt>\d</tt> in XSD regular expressions is <t>Note that the semantics of <tt>\d</tt> in XSD regular expressions
that of is that of <tt>\p{Nd}</tt>; however, this would include all Unicode
<tt>\p{Nd}</tt>; however, this would include all Unicode characters that are characters that are digits in various writing systems, which is almost
digits in various writing systems, which is almost certainly not what is certainly not what is required in IETF publications.</t>
required in IETF publications.</t>
<t>The construct <tt>\p{IsBasicLatin}</tt> is essentially a reference to legacy <t>The construct <tt>\p{IsBasicLatin}</tt> is essentially a reference to legacy
ASCII, it can be replaced by the character class <tt>[\u0000-\u007f]</tt>.</t> ASCII; it can be replaced by the character class <tt>[\u0000-\u007f]</tt>.</t>
</section> </section>
<section anchor="xsd-regexps"> <section anchor="xsd-regexps">
<name>XSD Regexps</name> <name>XSD Regexps</name>
<t>Any I-Regexp also is an XSD Regexp <xref target="XSD-2"/>, so the map <t>Any I-Regexp is also an XSD regexp <xref target="XSD-2"/>, so the map
ping is an identity ping is an identity
function.</t> function.</t>
<t>Note that a few errata for <xref target="XSD-2"/> have been fixed in
<xref target="XSD11-2"/>, which <t>Note that a few errata for <xref target="XSD-2"/> have been fixed in
is therefore also included as a normative reference. <xref target="XSD-1.1-2"/>; therefore, it
is also included in the <xref target="norm">Normative References</xref>.
XSD 1.1 is less widely implemented than XSD 1.0, and implementations XSD 1.1 is less widely implemented than XSD 1.0, and implementations
of XSD 1.0 are likely to include these bugfixes, so for the intents of XSD 1.0 are likely to include these bugfixes; for the intents
and purposes of this specification an implementation of XSD 1.0 and purposes of this specification, an implementation of XSD 1.0
regexps is equivalent to an implementation of XSD 1.1 regexps.</t> regexps is equivalent to an implementation of XSD 1.1 regexps.</t>
</section> </section>
<section anchor="toESreg"> <section anchor="toESreg">
<name>ECMAScript Regexps</name> <name>ECMAScript Regexps</name>
<t>Perform the following steps on an I-Regexp to obtain an ECMAScript <t>Perform the following steps on an I-Regexp to obtain an ECMAScript
regexp <xref target="ECMA-262"/>:</t> regexp <xref target="ECMA-262"/>:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>For any unescaped dots (<tt>.</tt>) outside character classes (fir <li>For any unescaped dots (<tt>.</tt>) outside character classes
st alternative (first alternative of <tt>charClass</tt> production), replace the dot
of <tt>charClass</tt> production): replace dot by <tt>[^\n\r]</tt>.</li> with
<tt>[^\n\r]</tt>.</li>
<li>Envelope the result in <tt>^(?:</tt> and <tt>)$</tt>.</li> <li>Envelope the result in <tt>^(?:</tt> and <tt>)$</tt>.</li>
</ul> </ul>
<t>The ECMAScript regexp is to be interpreted as a Unicode pattern ("u" <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> flag; see Section 21.2.2 "Pattern Semantics" of <xref target="ECMA-262"/>).</t>
<t>Note that where a regexp literal is required, <t>Note that where a regexp literal is required,
the actual regexp needs to be enclosed in <tt>/</tt>.</t> the actual regexp needs to be enclosed in <tt>/</tt>.</t>
</section> </section>
<section anchor="pcre-re2-ruby-regexps"> <section anchor="pcre-re2-ruby-regexps">
<name>PCRE, RE2, Ruby Regexps</name> <name>PCRE, RE2, and Ruby Regexps</name>
<t>Perform the same steps as in <xref target="toESreg"/> to obtain a val
id regexp in <t>To obtain a valid regexp in Perl Compatible Regular Expressions
PCRE <xref target="PCRE2"/>, the Go programming language <xref target="RE2"/>, a (PCRE) <xref target="PCRE2"/>, the Go programming language's RE2 regexp libra
nd the Ruby ry <xref target="RE2"/>, and the Ruby
programming language, except that the last step is:</t> programming language, perform the same steps as in <xref target="toESreg"/>, exc
ept that the last step is:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Enclose the regexp in <tt>\A(?:</tt> and <tt>)\z</tt>.</li> <li>Enclose the regexp in <tt>\A(?:</tt> and <tt>)\z</tt>.</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="background"> <section anchor="background">
<name>Motivation and Background</name> <name>Motivation and Background</name>
<t>While regular expressions originally were intended to describe a <t>While regular expressions originally were intended to describe a
formal language to support a Boolean matching function, they formal language to support a Boolean matching function, they
have been enhanced with parsing functions that support the extraction have been enhanced with parsing functions that support the extraction
and replacement of arbitrary portions of the matched text. With this and replacement of arbitrary portions of the matched text. With this
accretion of features, parsing regexp libraries have become accretion of features, parsing-regexp libraries have become
more susceptible to bugs and surprising performance degradations which more susceptible to bugs and surprising performance degradations that
can be exploited in Denial of Service attacks by can be exploited in denial-of-service attacks by
an attacker who controls the regexp submitted for an attacker who controls the regexp submitted for
processing. I-Regexp is designed to offer interoperability, and to be processing. I-Regexp is designed to offer interoperability and to be
less vulnerable to such attacks, with the trade-off that its only less vulnerable to such attacks, with the trade-off that its only
function is to offer a boolean response as to whether a character function is to offer a Boolean response as to whether a character
sequence is matched by a regexp.</t> sequence is matched by a regexp.</t>
<section anchor="subsetting"> <section anchor="subsetting">
<name>Implementing I-Regexp</name> <name>Implementing I-Regexp</name>
<t>XSD regexps are relatively easy to implement or map to widely <t>XSD regexps are relatively easy to implement or map to widely
implemented parsing regexp dialects, with these notable implemented parsing-regexp dialects, with these notable
exceptions:</t> exceptions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Character class subtraction. This is a very useful feature in man <li>Character class subtraction. This is a very useful feature in
y many specifications, but it is unfortunately mostly absent from
specifications, but it is unfortunately mostly absent from parsing parsing-regexp dialects. Thus, it is omitted from I-Regexp.</li>
regexp dialects. Thus, it is omitted from I-Regexp.</li> <li>Multi-character escapes. <tt>\d</tt>, <tt>\w</tt>, <tt>\s</tt>
<li>Multi-character escapes. <tt>\d</tt>, <tt>\w</tt>, <tt>\s</tt> an and their uppercase complement classes exhibit a large amount of
d their uppercase variation between regexp flavors. Thus, they are omitted from
complement classes exhibit a I-Regexp.</li>
large amount of variation between regexp flavors. Thus, they are <li>Not all regexp implementations support access to Unicode
omitted from I-Regexp.</li> tables that enable executing constructs such as <tt>\p{Nd}</tt>,
<li>Not all regexp implementations although the <tt>\p</tt>/<tt>\P</tt> feature in general is now quite
support accesses to Unicode tables that enable widely available. While, in principle, it is possible to translate
executing constructs such as <tt>\p{Nd}</tt>, these into character-class matches, this also requires access to
although the <tt>\p</tt>/<tt>\P</tt> feature in general is now quite those tables. Thus, regexp libraries in severely constrained
widely available. While in principle it is possible to environments may not be able to support I-Regexp conformance.</li>
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> </ul>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document makes no requests of IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security considerations</name> <name>Security Considerations</name>
<t>While technically out of scope of this specification, Section <xref tar <t>While technically out of the scope of this specification, Section <xref
get="RFC3629" section="10" sectionFormat="bare">Security Considerations</xref> o target="RFC3629" section="10" sectionFormat="bare">"Security Considerations"</x
f <xref target="RFC3629"/> applies to implementations. ref> of <xref target="RFC3629"/> applies to implementations.
Particular note needs to be taken of the last paragraph of Section <xref target= Particular note needs to be taken of the last paragraph of Section <xref target=
"RFC3629" section="3" sectionFormat="bare">UTF-8 definition</xref> of <xref targ "RFC3629" section="3" sectionFormat="bare">"UTF-8 definition"</xref> of <xref ta
et="RFC3629"/>; an I-Regexp implementation may need to rget="RFC3629"/>; an I-Regexp implementation may need to
mitigate limitations of the platform implementation in this regard.</t> mitigate limitations of the platform implementation in this regard.</t>
<t>As discussed in <xref target="background"/>, more complex regexp librar ies may <t>As discussed in <xref target="background"/>, more complex regexp librar ies may
contain exploitable bugs leading to crashes and remote code contain exploitable bugs, which can lead to crashes and remote code
execution. There is also the problem that such libraries often have execution. There is also the problem that such libraries often have
hard-to-predict performance characteristics, leading to attacks performance characteristics that are hard to predict, leading to attacks
that overload an implementation by matching against an expensive that overload an implementation by matching against an expensive
attacker-controlled regexp.</t> attacker-controlled regexp.</t>
<t>I-Regexps have been designed to allow implementation in a way that is <t>I-Regexps have been designed to allow implementation in a way that is
resilient to both threats; this objective needs to be addressed resilient to both threats; this objective needs to be addressed
throughout the implementation effort. throughout the implementation effort. Non-checking implementations (see <xref ta
Non-checking implementations (see <xref target="checking"/>) are likely to expos rget="checking"/>) are likely to expose
e
security limitations of any regexp engine they use, which may be less security limitations of any regexp engine they use, which may be less
problematic if that engine has been built with security considerations problematic if that engine has been built with security considerations
in mind (e.g., <xref target="RE2"/>); a checking implementation is still <bcp14> RECOMMENDED</bcp14>.</t> in mind (e.g., <xref target="RE2"/>). In any case, a checking implementation is still <bcp14>RECOMMENDED</bcp14>.</t>
<t>Implementations that specifically implement the I-Regexp subset can, <t>Implementations that specifically implement the I-Regexp subset can,
with care, be designed to generally run in linear time and space in with care, be designed to generally run in linear time and space in
the input, and to detect when that would not be the case (see below).</t> the 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 <t>Existing regexp engines should be able to easily handle most I-Regexps
(after the adjustments discussed in <xref target="mapping"/>), but may consume (after the adjustments discussed in <xref target="mapping"/>), but may consume
excessive resources for some types of I-Regexps or outright reject excessive resources for some types of I-Regexps or outright reject
them because they cannot guarantee efficient execution. them because they cannot guarantee efficient execution.
(Note that different versions of the same regexp library may be more or (Note that different versions of the same regexp library may be more or
less vulnerable to excessive resource consumption for these cases.)</t> less vulnerable to excessive resource consumption for these cases.)</t>
<t>Specifically, range quantifiers (as in <tt>a{2,4}</tt>) provide particu lar <t>Specifically, range quantifiers (as in <tt>a{2,4}</tt>) provide particu lar
challenges for both existing and I-Regexp focused implementations. challenges for both existing and I-Regexp focused implementations.
These may therefore limit range quantifiers in composability Implementations may therefore limit range quantifiers in composability
(disallowing nested range quantifiers such as <tt>(a{2,4}){2,4}</tt>) or (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 range (disallowing very large ranges such as <tt>a{20,200000}</tt>), or detect
and reject any excessive resource consumption caused by them.</t> and reject any excessive resource consumption caused by range quantifiers.</t>
<t>I-Regexp implementations that are used to evaluate regexps from <t>I-Regexp implementations that are used to evaluate regexps from
untrusted sources need to be robust to these cases. untrusted sources need to be robust in these cases.
Implementers using existing regexp libraries are encouraged to check Implementers using existing regexp libraries are encouraged:</t>
<ul>
<li>to check
their documentation to see if mitigations are configurable, such as their documentation to see if mitigations are configurable, such as
limits in resource consumption, and to document their own degree of limits in resource consumption, and</li>
robustness resulting from employing such mitigations.</t> <li>to document their own degree of
robustness resulting from employing such mitigations.</li></ul>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC3629" to="STD63"/>
<displayreference target="I-D.ietf-jsonpath-base" to="JSONPATH-BASE"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references anchor="norm">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="XSD-2" target="https://www.w3.org/TR/2004/REC-xmlsche ma-2-20041028/"> <reference anchor="XSD-2" target="https://www.w3.org/TR/2004/REC-xmlsche ma-2-20041028/">
<front> <front>
<title>XML Schema Part 2: Datatypes Second Edition</title> <title>XML Schema Part 2: Datatypes Second Edition</title>
<author fullname="Paul Biron" role="editor"/>
<author fullname="Ashok Malhotra" role="editor"/> <author fullname="Ashok Malhotra" role="editor"/>
<author fullname="Paul V. Biron" role="editor"/>
<date day="28" month="October" year="2004"/> <date day="28" month="October" year="2004"/>
</front> </front>
<seriesInfo name="W3C REC" value="REC-xmlschema-2-20041028"/> <seriesInfo name="W3C REC" value="REC-xmlschema-2-20041028"/>
<seriesInfo name="W3C" value="REC-xmlschema-2-20041028"/> <seriesInfo name="W3C" value="REC-xmlschema-2-20041028"/>
</reference> </reference>
<reference anchor="XSD11-2" target="https://www.w3.org/TR/2012/REC-xmlsc
hema11-2-20120405/"> <reference anchor="XSD-1.1-2" target="https://www.w3.org/TR/2012/REC-xml
schema11-2-20120405/">
<front> <front>
<title>W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatype s</title> <title>W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatype s</title>
<author fullname="Ashok Malhotra" role="editor"/>
<author fullname="David Peterson" role="editor"/> <author fullname="David Peterson" role="editor"/>
<author fullname="Shudi Gao" role="editor"/>
<author fullname="Ashok Malhotra" role="editor"/>
<author fullname="C. M. Sperberg-McQueen" role="editor"/>
<author fullname="Henry Thompson" role="editor"/> <author fullname="Henry Thompson" role="editor"/>
<author fullname="Michael Sperberg-McQueen" role="editor"/> <author fullname="Paul Biron" role="editor"/>
<author fullname="Paul V. Biron" role="editor"/>
<author fullname="Sandy Gao" role="editor"/>
<date day="5" month="April" year="2012"/> <date day="5" month="April" year="2012"/>
</front> </front>
<seriesInfo name="W3C REC" value="REC-xmlschema11-2-20120405"/> <seriesInfo name="W3C REC" value="REC-xmlschema11-2-20120405"/>
<seriesInfo name="W3C" value="REC-xmlschema11-2-20120405"/> <seriesInfo name="W3C" value="REC-xmlschema11-2-20120405"/>
</reference> </reference>
<reference anchor="RFC5234">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"
<title>Augmented BNF for Syntax Specifications: ABNF</title> />
<author fullname="D. Crocker" initials="D." role="editor" surname="C <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7405.xml"
rocker"> />
<organization/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
</author> />
<author fullname="P. Overell" initials="P." surname="Overell"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
<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 A
ugmented BNF (ABNF), has been popular among many Internet specifications. The c
urrent specification documents ABNF. It balances compactness and simplicity with
reasonable representational power. The differences between standard BNF and AB
NF involve naming rules, repetition, alternatives, order-independence, and value
ranges. This specification also supplies additional rule definitions and encod
ing for a core lexical analyzer of the type common to several Internet specifica
tions. [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 Ba
ckus-Naur Form) to include a way to specify US-ASCII string literals that are ma
tched 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</tit
le>
<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 sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. 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</ti
tle>
<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 protoco
l specifications. This document aims to reduce the ambiguity by clarifying tha
t 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>
</references> </references>
<references> <references>
<name>Informative References</name> <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 Univer
sal 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 of preserving the
full US-ASCII range, providing compatibility with file systems, parsers and othe
r software that rely on US-ASCII values but are transparent to other values. Th
is 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>
<reference anchor="I-D.ietf-jsonpath-base">
<front>
<title>JSONPath: Query expressions for JSON</title>
<author fullname="Stefan Gössner" initials="S." surname="Gössner">
<organization>Fachhochschule Dortmund</organization>
</author>
<author fullname="Glyn Normington" initials="G." surname="Normington
">
</author>
<author fullname="Carsten Bormann" initials="C." surname="Bormann">
<organization>Universität Bremen TZI</organization>
</author>
<date day="10" month="June" year="2023"/>
<abstract>
<t> JSONPath defines a string syntax for selecting and extractin
g JSON
(RFC 8259) values from a JSON value.
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"
</abstract> />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-jsonpath-base-14"/ <!-- [I-D.ietf-jsonpath-base] Edit state as of 10/9/23; long form to include "Ed
> ." roles. -->
</reference>
<reference 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" role="editor">
<organization>Fachhochschule Dortmund</organization>
</author>
<author initials="G." surname="Normington" fullname="Glyn Normington" role="edit
or">
</author>
<author initials="C." surname="Bormann" fullname="Carsten Bormann" role="editor"
>
<organization>Universität Bremen TZI</organization>
</author>
<date month="August" day="25" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-jsonpath-base-20"/>
</reference>
<reference anchor="UNICODE-GLOSSARY" target="https://unicode.org/glossar y/"> <reference anchor="UNICODE-GLOSSARY" target="https://unicode.org/glossar y/">
<front> <front>
<title>Glossary of Unicode Terms</title> <title>Glossary of Unicode Terms</title>
<author> <author>
<organization>Unicode, Inc.</organization> <organization>Unicode, Inc.</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<reference anchor="RE2" target="https://github.com/google/re2"> <reference anchor="RE2" target="https://github.com/google/re2">
<front> <front>
<title>RE2 is a fast, safe, thread-friendly alternative to backtrack <title>RE2 is a fast, safe, thread-friendly alternative to
ing regular expression engines like those used in PCRE, Perl, and Python. It is backtracking regular expression engines like those used in PCRE,
a C++ library.</title> Perl, and Python. It is a C++ library.</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date>
</front> </front>
<refcontent>commit 73031bb</refcontent>
</reference> </reference>
<reference anchor="PCRE2" target="http://pcre.org/current/doc/html/"> <reference anchor="PCRE2" target="http://pcre.org/current/doc/html/">
<front> <front>
<title>Perl-compatible Regular Expressions (revised API: PCRE2)</tit le> <title>Perl-compatible Regular Expressions (revised API: PCRE2)</tit le>
<author> <author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="ECMA-262" target="https://www.ecma-international.org/ wp-content/uploads/ECMA-262.pdf"> <reference anchor="ECMA-262" target="https://www.ecma-international.org/ wp-content/uploads/ECMA-262.pdf">
<front> <front>
<title>ECMAScript 2020 Language Specification</title> <title>ECMAScript 2020 Language Specification</title>
<author> <author>
<organization>Ecma International</organization> <organization>Ecma International</organization>
</author> </author>
<date year="2020" month="June"/> <date year="2020" month="June"/>
</front> </front>
<seriesInfo name="ECMA" value="Standard ECMA-262, 11th Edition"/> <refcontent>Standard ECMA-262, 11th Edition</refcontent>
</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 J
SON 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"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7493.xml"
/>
</references> </references>
</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"> <section numbered="false" anchor="acknowledgements">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>This specification has been motivated by the discussion in the IETF JSO <t>Discussion in the IETF
NPATH JSONPATH WG about whether to include a regexp mechanism into the
WG about whether to include a regexp mechanism into the JSONPath query JSONPath query expression specification and previous
expression specification, as well as by previous discussions about the discussions about the YANG <tt>pattern</tt> and Concise Data
YANG <tt>pattern</tt> and CDDL <tt>.regexp</tt> features.</t> Definition Language (CDDL) <tt>.regexp</tt>
<t>The basic approach for this specification was inspired by <xref target= features motivated this specification.</t>
"RFC7493">The <t>The basic approach for this specification was inspired by "<xref
I-JSON Message Format</xref>.</t> target="RFC7493" format="title"></xref>" <xref target="RFC7493" format="de
fault"/>.</t>
</section> </section>
</back> </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> </rfc>
 End of changes. 77 change blocks. 
563 lines changed or deleted 224 lines changed or added

This html diff was produced by rfcdiff 1.48.