RE: [cti] Patterning Operators - CONTAINS

["Back, Greg" <gback@mitre.org>]

I support option 1.

I don't like the names ISSUBSET and ISSUPERSET, due to the a difference between set containment (∈ / U+2208) and subset relationships (⊂ / U+2282,  ⊃ / U+2283, ⊆ / U+2286, ⊇ / U+2287). While I don't think we need strict mathematical formality, I would prefer CONTAINS/CONTAINEDIN, HASMEMBER/MEMBEROF, HASITEM/ELEMENTOF or any number of other terms. 

======

We don't (I don't think) have a way to express that a pattern is equal to some list (there is no list constant defined in the spec), but we do have the [*] notation for matching "any item" from a list. 

So you can't say:

[network-traffic:protocols = ('IP', 'TCP', 'HTTP')]

But you can say: 

[network-traffic:protocols[*] = 'IP' AND network-traffic:protocols[*] = 'TCP' AND network-traffic:protocols[*] =  'HTTP']

Which is slightly less rigorous (it would also match {'protocols': ['HTTP', 'IP', 'TCP']}); in practice I don't see this as a problem.

We *could* use ISSUPERSET to do something like:

[network-traffic:protocols ISSUPERSET ('IP', 'TCP', 'HTTP')]

Or, if you want to ensure the sets are equal (irrespective of order, and if you don't require *proper* subsets and supesets, which we shouldn't): 

[network-traffic:protocols ISSUPERSET ('IP', 'TCP', 'HTTP') AND network-traffic:protocols ISSUBSET ('IP', 'TCP', 'HTTP')]

======

To be clear, I'm not saying we *should* do that, but rather we *could*. I don't think we should, at least for this release. My point is that "superset" and "subset" should not be used to match a field that has a single value.

Greg


> -----Original Message-----
> From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of
> John-Mark Gurney
> Sent: Thursday, October 27, 2016 6:32 PM
> To: Kirillov, Ivan A. <ikirillov@mitre.org>
> Cc: cti@lists.oasis-open.org
> Subject: Re: [cti] Patterning Operators - CONTAINS
> 
> After a call w/ people this morning, there are two options (technically
> three) to move this forward.
> 
> After discussion, we would like to remove the LHS always being Object Path
> and RHS always being constant, but we feel that it is too late to make this
> change, and we can change this in the future w/o breaking backward
> compatibility.  This change could possibly happen in 2.1 when the operators
> are expanded.
> 
> 1) Keep the current convention of having the Object Path on the LHS, and
> constant on RHS, and replace the CONTAINS operator w/ ISSUBSET and
> ISSUPERSET.  Both operators are required to support current known use
> cases.
> 
> 2a) We use CONTAINS, but make it support Object Path or Constants on
> either side.  This is how things are currently specified.
> 
> 2b) We rename CONTAINS to ISSUBSET, but keep the current definition of
> Object Path and Constants on either side.
> 
> Sorry if things are a bit short, I've been busy today and wanted to get this
> email out before I leave for the day.  Feel free to ask any questions about the
> above proposals.
> 
> Thanks for your consideration.
> 
> --
> John-Mark
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php