[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Conformance Section
|
All, I got Allan, Mark, Bret, and Rich P. and we came up with another revision. I’m feeling pretty comfortable with the text so have pasted it into the RC3 documents. You can find it: Part 1 (STIX Core) Conformance:
https://docs.google.com/document/d/1IcA5KhglNdyX3tO17bBluC5nqSf70M5qgK9nuAoYJgw/edit#heading=h.swto78n8l9sp Part 2 (STIX Object) Conformance:
https://docs.google.com/document/d/1S5XhY6F5OT599b0OuHtUf8IBzFvNY8RysFHIj93DgsY/edit#heading=h.dnm4ez5y24uh Please review and provide comments. Jason, John-Mark…each individual document will need a conformance section, including Patterning. You guys might start thinking about how you want to draft conformance for patterning. I would take a look at
we did for the two sections above and base something on that…our goal was to keep it fairly simple and lightweight and then rely on interop to build on top of that. John From: <cti@lists.oasis-open.org> on behalf of John Wunder <jwunder@mitre.org> I added this text to the Playground so we can edit it:
https://docs.google.com/document/d/1wiG6RoNEFaE2lrblfgjpu3RTAJZOK2q0b5OxXCaCV14/edit#heading=h.a4woj6cyyw4r Please review and provide suggestions. Note that the ANY/ALL question is still open. John From: <cti@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org> Hey everyone, One of the major sections we need to finish before we move forward with 2.0 is the conformance section of the document. The conformance section describes what it means to be conformant with STIX and what terms
you should use to describe those products. To frame things a bit, an example conformance section from ebXML is attached. As you can see, they dictate what sections you need to conform to to be called a registry, a registry client, etc. For us, the equivalent to those categories seems to be “STIX Producer” and “STIX Consumer”. Additionally, we’ll have tools that implement different sets of STIX objects (some tools will only do indicators,
others will do some set of things, others will do everything). That to me suggests some kind of matrix: -
STIX Producer, STIX Consumer, or both -
Which STIX objects you support So you’d end up with some text like this: ---------------------------------
A producer is any tool that creates STIX content. An implementation is a conformant producer if it meets the following conditions:
1. The content it creates is encoded as JSON and is conformant with the property tables and normative requirements within those tables for the content it
creates
2. Any STIX content it creates conforms to all applicable normative requirements in the sections for the content it creates
A consumer is any tool that receives STIX content for any purpose. An implementation is a conformant consumer if it meets the following conditions:
1. It supports consuming data markings by conforming to all normative requirements in the data markings section
2. It supports consuming versioned content by conforming to all normative requirements in the versioning section
3. It supports consuming custom content by conforming to all normative requirements in the “customizing STIX” section (TODO: maybe not necessary, consumers
are allowed to either ignore or throw an error if they get properties with custom content)
A producer or consumer may additionally claim conformance with one or more STIX Objects. Implementations may do so if:
1. They support all normative requirements in the corresponding section
2. If a producer, the objects of that type they create are conformant with the property table in that section (though they may contain custom properties per
the normative requirements of that section).
A “STIX Producer” is any tool that can produce ____________
(TODO, see below)
A “STIX Consumer” is any tool that can consume ____________
(TODO, see below) --------------------------------- One option is that to be called a “STIX Producer” you need to be able to create ALL objects defined in STIX. Tools that were not able to create all objects would just be called producers of those objects,
but not STIX producers. The other option is that to be called a “STIX Producer” you just need to be able to create SOME objects defined in STIX. Tools that create any STIX objects can be called STIX producers, and we could name another
class (“Full STIX Producer”) for tools that create all objects, or just not give it a name. We would also be allowed to create other classes…for example, STIX Indicator Sharing Producers might be required to produce indicators, relationships, sightings, and observed data. I would probably lean towards
not doing that just yet though…can always be added in 2.1+ as we learn more. So, a couple questions for everyone: 1.
Does the rough direction I’ve outlined above make sense? Do you have any other ideas? 2.
Do you think we should make “STIX Producer/Consumer” mean a tool that creates/consumes ALL STIX objects, or a tool that creates/consumes SOME STIX objects? Thanks, John |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]