Certain STIX objects should not be extended to allow for versioning

[rpiazza]

Versioning is implemented by a STIX object having the versioning properties: created, modified, revoked and created_by_ref.

SCOs and data-markings do NOT have all of these properties, so they cannot be versioned.

The rationale behind why SCO should not be versioned, is that they represent a "fact", as in "this is what I saw" (or could have seen). Therefore they don't really "change".

The rationale behind why a data-marking should not be versioned is that others may be using the data-marking, but might not be aware that a change in the markings might allow STIX objects to be shared that they would not want.

It might seem like creating an extension of an SCO or data-markings adding the missing properties would be allowed, but that is antithetical to the SCOs and data-markings.

However, this text exists in section 3.6 which implies that this is allowed:

It should be noted that if a producer versions a SCO (assigns value to these four properties) that no other
producer would be allowed to create or modify the same SCO with an equivalent deterministic id, as that
would conflict with the strict versioning rules defined in STIX2. Therefore, for interoperability and sharing,
producers versioning SCOs MUST NOT use the default namespace for deterministic ID creation.
Otherwise multiple different producers will conflict with each other if producing the same SCO intelligence.

It should be decided if the specification should explicitly not allow SCOs and data-markings to be versioned.

Something to consider is that if versioning of SCOs is not allowed, creating a new SCO by using the same ID contributing properties and only changing a non-ID contributing property would result in a new SCO, but the STIX id will be the same.