Subject: PCIMe MATCHing and more

From: "Larry S. Bartz" <[email-masked]>
Date: Fri, 09 Mar 2001 17:19:45 -0500

PCIMe's specification of context-sensitive inference of MATCHing
semantics for policy conditions implies a potential that the correct
inference might not be drawn. Unless the schema designer, the
information infrastructure architect, and the policy-interpreting
code designer/programmer are one-in-the-same, there's a lot of
space between the rubber and the road.

There may be a mechanism by which the MATCHing semantic can be made
explicit. I'm suggesting such a mechanism, in which subtypes of
policyConditionAuxClass are named for the particular comparison
semantic they support. Use of these subtypes can constitute a
semantic contract which binds the designer, implementor, and user
to a model of usage which is unambiguous.     

As with policyCondition's MATCH semantic, policyAction's "set"
semantic could be augmented. Unless one accepts the limitation of a
simple assignment operation, "set" requires context-sensitive
inference, just as condition's MATCH does.

There may be a mechanism by which the "set" semantic of policyAction
can be made explicit. I'm suggesting such a mechanism, in which
subtypes of policyActionAuxClass are named for the particular
assignment operation they support. Use of these subtypes can constitute
a semantic contract which binds the designer, implementor, and user
to a model of usage which is unambiguous.

In section 5.14, PCIMe invents syntaxes for complex expressions of
several types of value criteria. These inventions will require
implementors to likewise invent corresponding custom code.

If the MATCHing semantics of conditions are made explicit, some of
the syntactical constructs of PCIMe 5.14 are not necessary. For
example, expresssions of value ranges can be accomplished by
CNF'd granular policy conditions of the explicit types described
here.

There may yet be cases in which combinations of granular conditions
cannot suffice, even when augmented by PCIM's CNF, DNF, and negation
facilities. These cases might inspire the invention of syntax,
semantics, and grammar as tools which can express and interpret
complex information.

Why invent such tools when they're already available? Rather than
invent, the model described here capitalizes upon the regular
expression syntax of the ECMA262 specification. ECMA262 regExp
is richly expressive and platform-neutral. Everybody has an ECMA262
interpreter on their desktop, laptop, and (some) elsewhere.      

The objectclasses and attributetypes described below are named in terms
of "selector" (conditions) and "setter" (actions). These terms are not
part of rfc3060's lexicon. I use these terms for these specific types
simply to differentiate them from any others.  

I've described these in the ABNF, which is the usual form of expression
for Directory schema. I realize that the PCIMe draft is not a schema
proposal, and that the ABNF is not the usual form of expression for
Policy WG drafts which are not explicitly about implementation of 
Policy in the Directory. Forgive me. I'm a little Directory-centric.
I hope Policy WG's members have seen and digested enough ABNF by now,
so that what I'm describing is more or less obvious.

Your comments are most welcome. If you think this has merit but needs
work, please say so. If you think it's tripe, say that, too.   

Long lines are folded, to enhance readability.

##### policy condition stuff

objectclass ( oid-oc.X
 NAME 'selectorPolicyConditionAssociation'
 DESC 'selectorPolicyCondition is AUXed by subtypes of
 policyConditionSelector.'
 SUP policyRuleConditionAssociation
 STRUCTURAL
 MUST cn
 )

attributetype ( oid-at.X
 NAME 'selectorAttributeOID'
 DESC 'Value(s) of this attribute of the candidate object are evaluated
 for selection.'
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
 EQUALITY objectIdentifierMatch
 SINGLE-VALUE
 USAGE userApplications
 )

attributetype ( oid-at.X
 NAME 'selectorPropertyName'
 DESC 'Value(s) of this property of the application environment are
 evaluated for selection.'
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 EQUALITY caseIgnoreMatch
 SUBSTR caseIgnoreSubstringsMatch
 SINGLE-VALUE
 USAGE userApplications
 )

objectclass ( oid-oc.X
 NAME 'policyConditionSelector'
 DESC 'Several subtypes of this are used to implement explicit selection
 semantics by comparing the value of a candidate attribute/value pair
 or property/value pair to the value of selector criteria. Instances of
 this SHALL include either selectorAttributeOID attribute/value pair or
 selectorPropertyName attribute/value pair, but NEVER BOTH.'
 SUP policyConditionAuxClass
 AUXILIARY
 MAY ( selectorAttributeOID $ selectorPropertyName )
 )

attributetype ( oid-at.X
 NAME 'selectorValue'
 DESC 'Candidate value of selectorAttributeOID or selectorPropertyName
 is evaluated for selection against the value of this, which constitutes
 the selection criteria.'
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 EQUALITY caseIgnoreMatch
 SUBSTR caseIgnoreSubstringsMatch
 USAGE userApplications
 )

objectclass ( oid-oc.X
 NAME 'explicitComparatorConditionSelector'
 DESC 'subtypes of this support various explicit semantics for
evaluating
 a candidate value against selection criteria. Never create instances
 of this. ONLY create instances of subtypes of this.'
 SUP policyConditionSelector
 AUXILIARY
 MUST selectorValue
 )

objectclass ( oid-oc.X
 NAME 'equalConditionSelector'
 DESC 'Represents selection according to the semantic of "equal". The
 candidate value is tested for "equal" with respect to the selection
 criteria.'
 SUP explicitComparatorConditionSelector
 AUXILIARY
 )

objectclass ( oid-oc.X
 NAME 'greaterThanConditionSelector'
 DESC 'Represents selection according to the semantic of
 "greaterThan". The candidate value is tested for "greaterThan" with
 respect to the selection criteria.'
 SUP explicitComparatorConditionSelector
 AUXILIARY
 )

objectclass ( oid-oc.X
 NAME 'lessThanConditionSelector'
 DESC 'Represents selection according to the semantic of "lessThan". The
 candidate value is tested for "lessThan" with respect to the selection
 criteria.'
 SUP explicitComparatorConditionSelector
 AUXILIARY
 )

objectclass ( oid-oc.X
 NAME 'greaterThanOrEqualConditionSelector'
 DESC 'Represents selection according to the semantic of
 "greaterThanOrEqual". The candidate value is tested for
 "greaterThanOrEqual" with respect to the selection criteria.'
 SUP explicitComparatorConditionSelector
 AUXILIARY
 )

objectclass ( oid-oc.X
 NAME 'lessThanOrEqualConditionSelector'
 DESC 'Represents selection according to the semantic of
 "lessThanOrEqual". The candidate value is tested for "lessThanOrEqual"
 with respect to the selection criteria.'
 SUP explicitComparatorConditionSelector
 AUXILIARY
 )

objectclass ( oid-oc.X
 NAME 'beginsWithConditionSelector'
 DESC 'Represents selection according to the semantic of "beginsWith".
The
 candidate value is tested for "beginsWith" with respect to the
selection
 criteria.'
 SUP explicitComparatorConditionSelector
 AUXILIARY
 )

objectclass ( oid-oc.X
 NAME 'endsWithConditionSelector'
 DESC 'Represents selection according to the semantic of "endsWith". The
 candidate value is tested for "endsWith" with respect to the selection
 criteria.'
 SUP explicitComparatorConditionSelector
 AUXILIARY
 )

objectclass ( oid-oc.X
 NAME 'containsConditionSelector'
 DESC 'Represents selection according to the semantic of "contains". The
 candidate value is tested for "contains" with respect to the selection
 criteria.'
 SUP explicitComparatorConditionSelector
 AUXILIARY
 )

objectclass ( oid-oc.X
 NAME 'existsConditionSelector'
 DESC 'Represents selection according to the semantic of "exists". The
 candidate value is tested for "exists". The selection criteria is
 superfluous in this comparison.'
 SUP explicitComparatorConditionSelector
 AUXILIARY
 )

objectclass ( oid-oc.X
 NAME 'bitwiseANDConditionSelector'
 DESC 'Represents selection according to the semantic of "bitwiseAND".
The
 candidate value is tested for "bitwiseAND" with respect to the
selection
 criteria.'
 SUP explicitComparatorConditionSelector
 AUXILIARY
 )

objectclass ( oid-oc.X
 NAME 'bitwiseINclusiveORConditionSelector'
 DESC 'Represents selection according to the semantic of
 "bitwiseINclusiveOR". The candidate value is tested for
 "bitwiseINclusiveOR" with respect to the selection criteria.'
 SUP explicitComparatorConditionSelector
 AUXILIARY
 )

objectclass ( oid-oc.X
 NAME 'bitwiseEXclusiveORConditionSelector'
 DESC 'Represents selection according to the semantic of
 "bitwiseEXclusiveOR". The candidate value is tested for
 "bitwiseEXclusiveOR" with respect to the selection criteria.'
 SUP explicitComparatorConditionSelector
 AUXILIARY
 )

objectclass ( oid-oc.X
 NAME 'onesComplementConditionSelector'
 DESC 'Represents selection according to the semantic of
 "onesComplement". The candidate value is tested for "onesComplement".
The
 selection criteria is superfluous in this comparison.'
 SUP explicitComparatorConditionSelector
 AUXILIARY
 )

attributetype ( oid-at.X
 NAME 'selectorEcma262regExp'
 DESC 'Candidate value of selectorAttributeOID or selectorPropertyName
 is evaluated for selection against the ecma262 regular expression which
 is the value of this. See http://www.ecma.ch/ecma1/stand/ecma-262.htm'
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 EQUALITY caseIgnoreMatch
 SUBSTR caseIgnoreSubstringsMatch
 USAGE userApplications
 )

objectclass ( oid-oc.X
 NAME 'ecma262regExpConditionSelector'
 DESC 'ecma262regExpConditionSelector supports the semantic of
evaluating
 a candidate value against an ecma262 regular expression.'
 SUP policyConditionSelector
 AUXILIARY
 MUST selectorEcma262regExp
 )

# policy action stuff

objectclass ( oid-oc.X
 NAME 'setterPolicyActionAssociation'
 DESC 'setterPolicyAction is AUXed by subtypes of policyActionSetter.'
 SUP policyRuleActionAssociation
 STRUCTURAL
 MUST cn
 )

attributetype ( oid-at.X
 NAME 'propertyNameToSet'
 DESC 'Value of this property of the application environment is set or
 modified by the action.'
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 EQUALITY caseIgnoreMatch
 SUBSTR caseIgnoreSubstringsMatch
 USAGE userApplications
 )

objectclass ( oid-oc.X
 NAME 'policyActionSetter'
 DESC 'several subtypes of this implement explicit semantics for setting
 or modifying the value of an application-defined, application-dependent
 property.'
 SUP policyActionAuxClass
 AUXILIARY
 MUST propertyNameToSet
 )

attributetype ( oid-at.X
 NAME 'setToValue'
 DESC 'The value of a property of the application environment is set to
 or modified by the value of this, which constitutes the value setting
 criteria.'
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 EQUALITY caseIgnoreMatch
 SUBSTR caseIgnoreSubstringsMatch
 USAGE userApplications
 )

objectclass ( oid-oc.X
 NAME 'assignmentOperatorActionSetter'
 DESC 'subtypes of this support various semantics of setting a candidate
 value according to value setting criteria. Never create instances of
 this. ONLY create instances of subtypes of this.'
 SUP policyActionSetter
 AUXILIARY
 MUST setToValue
 )

objectclass ( oid-oc.X
 NAME 'setEqualToAssignmentOperatorActionSetter'
 DESC 'Represents value assignment according to the semantic of
 "setEqualTo". The value of the candidate property is assigned or
modified
 by "setEqualTo" with respect to the value setting criteria.'
 SUP assignmentOperatorActionSetter
 AUXILIARY
 )

objectclass ( oid-oc.X
 NAME 'setPlusEqualToAssignmentOperatorActionSetter'
 DESC 'Represents value assignment according to the semantic of
 "setPlusEqualTo". The value of the candidate property is assigned or
 modified by "setPlusEqualTo" with respect to the value setting
criteria.'
 SUP assignmentOperatorActionSetter
 AUXILIARY
 )

objectclass ( oid-oc.X
 NAME 'setMinusEqualToAssignmentOperatorActionSetter'
 DESC 'Represents value assignment according to the semantic of
 "setMinusEqualTo". The value of the candidate property is assigned
 or modified by "setMinusEqualTo" with respect to the value setting
 criteria.'
 SUP assignmentOperatorActionSetter
 AUXILIARY
 )

objectclass ( oid-oc.X
 NAME 'setMultEqualToAssignmentOperatorActionSetter'
 DESC 'Represents value assignment according to the semantic of
 "setMultEqualTo". The value of the candidate property is assigned or
 modified by "setMultEqualTo" with respect to the value setting
criteria.'
 SUP assignmentOperatorActionSetter
 AUXILIARY
 )

objectclass ( oid-oc.X
 NAME 'setDivEqualToAssignmentOperatorActionSetter'
 DESC 'Represents value assignment according to the semantic of
 "setDivEqualTo". The value of the candidate property is assigned or
 modified by "setDivEqualTo" with respect to the value setting
criteria.'
 SUP assignmentOperatorActionSetter
 AUXILIARY
 )

objectclass ( oid-oc.X
 NAME 'setModuloEqualToAssignmentOperatorActionSetter'
 DESC 'Represents value assignment according to the semantic of
 "setModuloEqualTo". The value of the candidate property is assigned
 or modified by "setModuloEqualTo" with respect to the value setting
 criteria.'
 SUP assignmentOperatorActionSetter
 AUXILIARY
 )

objectclass ( oid-oc.X
 NAME 'setShiftLeftByAssignmentOperatorActionSetter'
 DESC 'Represents value assignment according to the semantic of
 "setShiftLeftBy". The value of the candidate property is assigned or
 modified by "setShiftLeftBy" with respect to the value setting
criteria.'
 SUP assignmentOperatorActionSetter
 AUXILIARY
 )

objectclass ( oid-oc.X
 NAME 'setShiftRightByAssignmentOperatorActionSetter'
 DESC 'Represents value assignment according to the semantic of
 "setShiftRightBy". The value of the candidate property is assigned
 or modified by "setShiftRightBy" with respect to the value setting
 criteria.'
 SUP assignmentOperatorActionSetter
 AUXILIARY
 )

objectclass ( oid-oc.X
 NAME 'setBitwiseANDwithAssignmentOperatorActionSetter'
 DESC 'Represents value assignment according to the semantic of
 "setBitwiseANDwith". The value of the candidate property is assigned
 or modified by "setBitwiseANDwith" with respect to the value setting
 criteria.'
 SUP assignmentOperatorActionSetter
 AUXILIARY
 )

objectclass ( oid-oc.X
 NAME 'setBitwiseINclusiveORwithAssignmentOperatorActionSetter'
 DESC 'Represents value assignment according to the semantic of
 "setBitwiseINclusiveORwith". The value of the candidate property is
 assigned or modified by "setBitwiseINclusiveORwith" with respect to
 the value setting criteria.'
 SUP assignmentOperatorActionSetter
 AUXILIARY
 )

objectclass ( oid-oc.X
 NAME 'setBitwiseEXclusiveORwithAssignmentOperatorActionSetter'
 DESC 'Represents value assignment according to the semantic of
 "setBitwiseEXclusiveORwith". The value of the candidate property is
 assigned or modified by "setBitwiseEXclusiveORwith" with respect to
 the value setting criteria.'
 SUP assignmentOperatorActionSetter
 AUXILIARY
 )

objectclass ( oid-oc.X
 NAME 'setOnesComplementAssignmentOperatorActionSetter'
 DESC 'Represents value assignment according to the semantic of
 "setOnesComplement". The value of the candidate property is assigned
 or modified by "setOnesComplement". The value setting criteria is
 superfluous in this operation.'
 SUP assignmentOperatorActionSetter
 AUXILIARY
 )

attributetype ( oid-at.X
 NAME 'setToEcma262regExp'
 DESC 'The value of a property of the application environment is
 set or modified according to an evaluation of this ecma262 regular
 expression. See http://www.ecma.ch/ecma1/stand/ecma-262.htm'
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 EQUALITY caseIgnoreMatch
 SUBSTR caseIgnoreSubstringsMatch
 USAGE userApplications
 )

objectclass ( oid-oc.X
 NAME 'ecma262regExpActionSetter'
 DESC 'ecma262regExpActionSetter supports the semantic of setting
 a candidate value according to the evaluation an ecma262 regular
 expression.'
 SUP policyActionSetter
 AUXILIARY
 MUST setToEcma262regExp
 )

--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  [email-masked]      | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|

---

From: "Lee Rafalow" <[email-masked]>
Date: Mon, 12 Mar 2001 10:02:39 -0500

Larry raises good points that, I think, expose a significant problem in the
draft.  We have taken the step across the line between a declarative
specification of policy to a procedural language and in so doing have raised
expectations for the completeness of the language.

My concern is two fold.  First, the step taken is large and, second, the
step is nowhere near large enough.  My conclusion is that the step shouldn't
be taken at all.

The introduction of the rule within rule puts program state into the
language.  That step completely changes the design of the policy engine from
that of decision table to that of a language interpreter.  In addition to
the restructure of the policy engine it changes the performance
characteristics when the policy engine is on the data path.  Apart from the
impact of the change itself, in theory, this change from declarative to
procedural might be fine for a PMT or PDP but it's not fine for a PEP
(IMHO).

Then, once we've taken the step to a procedural language, where is the point
at which we stop and say "the rest of the commonly available constructs of a
procedural language are not needed for policy specification?"  We have
implicit and explicit contexts and subcontexts and we even have a suggestion
in the draft that the language semantics should include ACID transactions
(commit and rollback) so surely we can afford having the more common
language features including a full set of comparators and operators, loops
and subroutines, etc.?

"Slow down!" you say (I hope!)?  But why?  We have a *terrible* procedural
language without these additional semantics.  The answer is to either have a
good language or no language at all.  I vote for the latter.  We started
this work with the idea that there would be a table-driven decision system
specified in the form of rules not a programming language...let's keep it
that way!

Lee M. Rafalow
Voice: 1-919-254-4455; Fax: 1-919-254-6243
IBM Internet Technology Management
IBM Corporation
P.O. Box 12195, BRQA/502
RTP, NC 27709 USA
Alternate email: [email-masked]
Home email: [email-masked]

---

From: "Ron Cohen" <[email-masked]>
Date: Tue, 13 Mar 2001 02:07:10 +0200

Larry,

I understand that we could have adopted a regular expression approach. But,
I'm not sure that I understand what is wrong with the current approach. What
is wrong with an IPv4address Value that specify both an address and an
address and mask using a semantic convention? Please give an example for
your statement "PCIMe specification of context sensitive inference of
MATCHing semantics for policy conditions implies a potential that the
correct inference might not be drawn",  and show how your proposal solves
this ambiguity.

The ability to define ranges of integers without including them within a
condition is to enable to reuse them with different variables. That is, the
range 1000-1024 can specify a port range that can be used within a condition
that checks this range against a source-port or a destination-port variable.
How do you suggest to do that within your proposal?

Your propsal to define an explictcomparatorcondition resembles what we had
several drafts ago, where we had an operator attribute within simple
condition that had enum values of equal, greater than, etc. We moved from
this proposal to the current one to allow support mentioned in the previous
point as well as other reasons. Possibly we did a mistake there, and we
should reconsider. But we need good reasons for that, which I don't see at
the moment.

Thanks
Ron

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Larry S. Bartz
> Sent: Saturday, March 10, 2001 12:20 AM
> To: IETF Policy WG LIST

---

From: "Larry S. Bartz" <[email-masked]>
Date: Tue, 13 Mar 2001 11:33:24 -0500

Ron Cohen wrote:
> 
> Larry,
> 
> I understand that we could have adopted a regular expression approach.

The explicit condition types which I described provide for all of the
comparison operations. When we combine these with rfc3060's CNF,
DNF, and negation facilities, we have a capability to compose complex
condition specs from a well-defined, relatively small set of granular
condition objects. I meant *this* to be the focus of my approach. If
my message gave the impression that "regular expression" was the
focus, my bad.

The use of regular expression syntax is not a premiere feature of
the strategy I've described. The use of regular expressions in
conditions
should be only in the rare, exceptional cases. It is there as an escape
hatch for cases I couldn't imagine yet. The recommendation of ecma262
was simply to avoid requiring anyone to invent their own escape hatch.
Further, it avoids requiring everyone to be able to recognize and
negotiate everybody else's funky (or sublime) homemade escape hatches.

> But,
> address and mask using a semantic convention?

If you can't determine the semantic of a variable unless and until
you evaluate an instance value which is assigned to that variable,
then you've got an ambiguous semantic. This might be fine under tightly
controlled implementations; implementations under which all interpreters
agree that they'll accept and comprehend "one of these" or "one of
those"
or "any one of these five kinds". 

But I don't think this is an appropriate strategy to promote and
canonize
as a strategy of a "core" information model. It's not reusable enough,
not generalizable enough to be called "core".

> Please give an example for

I intend not to resolve ambiguity, but to avoid ambiguity.

The last paragraph of PCIMe 4.8.3 reveals the weakness I intended
to address in my proposal. I'll paraphrase:

  "The "If" term and the "MATCH" operator are not directly modeled -- 
   they are implied."

   and

  "Text accompanying the value class definition SHOULD be used as a
   guideline for interpreting the semantics of the MATCH relationship."

By PCIMe's definition, an implementation cannot explicitly identify
exactly what MATCH means. PCIMe resorts to unstructured and unparseable
text as a guideline.

There is a an arguably finite set of distinct and explicitly-defineable
MATCH terms. I've laid 'em out. There aren't that many. It's easier to
avoid ambiguity than it is to resolve it.

> How do you suggest to do that within your proposal?

I wouldn't reuse the integer values. I would reuse the conditions. This
follows the strategy of rfc3060. I would specify two reusable condition
instances of greaterThanOrEqualConditionSelector and
lessThanOrEqualConditionSelector. These two could be components of a
reusable conditionList. Or each could be reusable, on its own, without
regard for the other.

> should reconsider. But we need good reasons for that, which I don't see at

I've got all nine PCIM drafts on hand. I don't see any discussion of an
enum of operator attributes in the PCIM drafts. I missed it. Where is
it?

If Lee Rafalow is right, if PCIMe should withdraw from this procedural
direction, I'll be just as happy. I think that what I've described *is*
a "table-driven decision system" (to quote Lee) which conforms to the
letter and the spirit of rfc3060. I agree with Lee's assertion that
PCIMe is something else. If what I've described is nothing more than
an rfc3060-conformant local implementation, fine by me. 

Explicitly yours,
Larry

---

From: "Lee Rafalow" <[email-masked]>
Date: Wed, 14 Mar 2001 11:50:23 -0500

For applications of the policy framework to any text evaluating policies
(e.g., web), regular expressions will be very useful.

See, for example,
http://www.ietf.org/internet-drafts/draft-beck-opes-irml-00.txt

Lee M. Rafalow
----- Original Message -----
From: "Larry S. Bartz" <[email-masked]>
To: "Ron Cohen" <[email-masked]>
Cc: "IETF Policy WG LIST" <[email-masked]>
Sent: Tuesday, March 13, 2001 11:33 AM
Subject: Re: PCIMe MATCHing and more

> > >  is the value of this. See
http://www.ecma.ch/ecma1/stand/ecma-262.htm'

---

From: "Larry S. Bartz" <[email-masked]>
Date: Wed, 28 Mar 2001 08:27:41 -0500

> http://www.ietf.org/internet-drafts/draft-beck-opes-irml-00.txt

I agree, Lee.

That draft cites POSIX (ISO/IEC DIS 9945-2:1992 and IEEE Std
1003.2-1992)
as the spec for regular expressions.

In my message, I cited ECMA262 (aka ISO-16262, aka ECMAscript, aka
JavaScript) as the spec for regular expressions.

The ISO-16262 regular expression syntax is directly supported in web
browser software and in readily available implementations of server-side
ECMAscript. It can be parsed and interpreted practically anywhere.

In addition, the ISO-16262 regular expression syntax is based upon
Perl 5 regular expression syntax, which in turn has its roots in
POSIX regExp, which in turn grew from C and Unix based regExp. The Perl
environemt has subsequently added functionality to regExp, so that
Perl-5/ECMA262/ISO-16262 regExp is a superset of POSIX regExp.

While POSIX regExp is certainly a stable standard, I prefer the
Perl-5/ECMA262/ISO-16262 superset, both for its enhanced capabilities
and for its widespread implementation support.