|Paul - thanks for the thoughtful response and feedback.|
Hereâs my input.
1) Extension as a meta-object vs SDO.
AT: I could support it being classified as a meta-object provided we allow the following fields
- used for revoking extension use
- useful for categorization of extension purposes and helps describe them/differentiate them
- useful for additional background on spec of extension
- useful for copyright and other markings associated with extensions (not just data treatment)
By the time you include the options of these 4 properties then it starts to look more like a SDO again than a meta-object. So I lean towards keeping as SDO but the TC should debate.
2) Google doc.
3) Splitting schema property into 2 (human readable & machine-readable).
AT: Could support if others do.
4) extends_so_definition description fix.
AT: An extension may introduce only new objects not new properties and therefore this can *not* mandate that you provide a list of properties as the extension may encompass more than a single list of properties to a single object.
5) custom object extension.
AT: Agreed. That was the intention to make sure that this was clear in the spec once incorporated.
6) Two ways of doing things.
AT: I disagree with this assessment but agree that the language and guidance should be clear on when to use top-level vs sub-component. The paragraph early in the google document attempted to make this clear. We would refine once incorporated into the STIX spec.
While Iâm a fan of the approach, Iâd like to make a few suggestions:
- Why not make STIX Extension a Metaobject, like Language Content, rather than an SDO. The STIX Extension object actually contains metadata about extensions to a SO. In addition, it shares a lot of the same behaviors as the other Metaobjects:
- not being able to be the source or target of a Relationship
- restricted set of common properties; but unlike the Language Content and Marking Definition objects, a STIX Extension object is prohibited from having an extensions property to avoid the nesting of extensions.
This would make the table of common properties reflect the following :
- In the Google doc sections on Modification #1 and Modification #2, remove the last paragraph which discuss use of Extensions with playbooks as playbooks are NOT part of STIX at this time.
- The schema property of the STIX Extension has duel semantics: it could be human-readable document, or it could be a reference to a JSON schema. Recommend splitting these into two separate properties so that the semantics are clear, using schema property to reference a JSON schema. This would allow a tool to programmatically know where it could get a JSON schema that actually describes the datatype and restrictions of the property, such as cardinality and range limits. Consider using external_references for documentation/human-readable descriptions
- The description of extends_so_defintion needs to state that when the property is set to true, the extensions properties MUST, not should, include one or more property names.
- SUGGESTION: For custom object support, why not add the is_extension_object property to the STIX Extension object, to promote a common processing pattern: for each STIX Extension in extensions property, locate the STIX Extension object and determine if itâs a custom object by the value of the is_extension_object property, and if not, then look at the extends_so_definition to understand how the properties are applied. If is_extension_object is true, then all properties are custom and MUST be treated the same as if the extends_so_definition were set to true. This way if a custom object has been extended by another extension, one would know which properties come from which extension.
- Since this is breaking the rule of provide âone and only one way of doing thingsâ, there needs to be a description section in âCustomizing STIXâ that explains both approaches, when to use which approach, and what are the pros and cons.
Please find attached an updated STIX extension proposal that the mini-group worked with IBM (Jason/Emily) to incorporate an acceptable compromise to their concerns.
1) Previously presented extension proposal is maintained and has been named âsub-component extensionâ to clarify the distinction between when it would/should be used vs the additional mechanism added for top-level extension.
2) Added the concept of Top-Level object extension to allow extension properties directly with existing STIX standard objects.
3) Clarified language/definitions around use for both aspects.
The google doc containing the specification changes are here:
This proposal represents the agreement by all mini-group participants. We would like to encourage the TC to consider this proposal and incorporate the changes to the STIX standard.