"version": 1 } 2 { "type": "example", "id": "example--1", "created": "2016-05-01T06:13:14.000000Z", "modified": "2016-05-08T03:43:44.000000Z", "version": 4 } Consumer updates example object because the received version number is higher than the object that is currently stored. 3 { "type": "example", "id": "example--1", "created": "2016-05-01T06:13:14.000000Z", "modified": "version": 3 } Consumer ignores this object because they already have a newer version of the object. Note: consumer might choose to store meta-information about received objects, including versions that were received 4 { "type": "example", "id": "example--1", "created": "2016-05-01T06:13:14.000000Z", "modified": "version": 12, "revoked": true } Consumer deletes example object, but keeps some metadata regarding the object. 5 { "type": "example", "id": "example--1", "created": "2016-05-01T06:13:14.000000Z", "modified": "2016-05-10T17:28:54.000000Z", "version": 11 } Consumer ignores this object because they already have a newer version of the object (the revoked version). Example Object Creator Workflow This section describes an example workflow where a object creator publishes multiple updates to a particular object. This scenario assumes a human using a STIX implementation. (In this example, the STIX Objects have been truncated for brevity.) Step # STIX Object User Action 1 N/A – STIX is not involved in this scenario. (Tools could choose to create and track STIX versions for internal changes, but it is not required by the specification.) User clicks a create button in the user interface, creates a SDO, then clicks save. This action causes information to be stored in the product’s database.
This is an IEP property and MUST conform to the requirement for "EXTERNAL REFERENCE" policy specified in section 10.1.1 of the IEP specification. unmodified_resale (optional) string The unmodified_resale property states whether the recipient may or must not resell the information received unmodified or in a semantically equivalent format. The value MUST be may or must-not. This is an IEP property and MUST conform to the requirement for "UNMODIFIED RESALE" policy specified in section 10.1.2 of the IEP specification. Statement Marking Object Type The statement marking type defines the representation of a textual marking statement (e.g. copyright, terms of use, etc.) in a The value of the definition_type property MUST be statement when using this marking type. Statement markings are generally not machine-readable and this specification does not define any behavior or actions based on their values. Content may be marked with multiple statement marking types that do not override each other. In other words, the same content can be marked both with a statement saying "Copyright 2016" and a statement saying "Terms of use are ..." and both statements apply. Property Name Type Description statement (required) string A statement (e.g., copyright, of use) applied to the content marked by this marking definition. ​9.1.5.​ TLP Marking Object Type The TLP marking type sub-object defines how you would represent a Traffic Light Protocol (TLP) marking in a definition field. The value of the definition_type property MUST be tlp when using this marking type. Property Name Type Description tlp (required) string The TLP (defined by FIRST, ask Tom Millar for stable ref) of the content marked by this marking definition, as defined in this section.