Subject: regExp spec [was: Re: PCIMe MATCHing and more]

From: "Larry S. Bartz" <[email-masked]>
Date: Thu, 29 Mar 2001 07:29:41 -0500

I didn't get a copy of this back from the list, and it hasn't shown
up in the lists's archives, either.

-------- Original Message --------
Subject: Re: PCIMe MATCHing and more
Date: Wed, 28 Mar 2001 08:27:41 -0500
From: "Larry S. Bartz" <[email-masked]>
To: Lee Rafalow <[email-masked]>,IETF Policy WG LIST <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>

Lee Rafalow wrote:
> 
> 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
>

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.

> 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]
> ----- 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
> 
> > 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,
> > > 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?
> >
> >
> > 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
> > > 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.
> >
> >
> > 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.
> >
> >
> > >
> > > 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?
> >
> >
> > 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.
> >
> >
> > >
> > > 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.
> >
> >
> > 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
> >
> >
> > >
> > > 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
> > > > Subject: PCIMe MATCHing and more
> > > >
> > > >
> > > > 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                 |                              |
> > #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|

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