OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: More on ID Contributing Properties

In the STIX spirit of implementing proposed specification additions, I have been implementing a script to generate deterministic IDs â which I have commented on before.


I noticed something else which seems ambiguous â the use of optional properties.  For example, letâs take an email-message.  The three ID contributing properties are: from_ref, subject, body.

Both are subject and body optional.  Assuming both are not present, then only from_ref will be used.  Therefore, any email message from the same email address, for which both the subject and body are empty (or not provided in the email-message object), will have the same deterministic ID.  However, the email-message objects might be very different â i.e., many non-contributing properties exists in both that are not the same.


So a collision will take place. Receiving two SCOs with the same id was supposed to a feature â you didnât have to retain both,  but in this case you really have two different objects â both of which should probably be retained (e.g., different date properties).


Additionally, this problem can also exist even with required only contributing properties.


Iâm aware that this is a known limitation, and perhaps it has already been taken into consideration, as I was not part of the subgroup that developed deterministic IDs.    But maybe we can do a little better â for instance:


  • Include more contributing properties.  For instance, adding the date property as a contributing property of the email-message object would help to avoid collisions.
  • Distinguish non-existent properties in the actual object from ones not provided in the STIX object â i.e., if the subject was really empty â provide the subject property with a value of ââ.  Some normative text (SHOULD) could be added.
  • Use UUIDv4 if the number of non-contributing properties is over some threshold â chances are there wonât be another similar object.




Rich Piazza

The MITRE Corporation








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]