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: RE: [cti] Working Call Agenda For Next Week


Regarding the SCO Relationships I notice that ‘belongs_to_ref’ will be made an external relationship for most of the SCOs that have it, but not for the Email Address Object. Is there a reason for this? What were the criteria used to determine which relationships would stay embedded vs be made external? Apologies if I’m missing something obvious or it has already been stated.

 

Thank you,

Chris Lenk

 

From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Bret Jordan
Sent: Friday, April 19, 2019 1:01 PM
To: cti@lists.oasis-open.org
Subject: [cti] Working Call Agenda For Next Week

 

All,

 

As we work towards Milestone 2, there are a few things we need to resolve and get final clarity on.  Some of these topics will unfortunately be somewhat contentious.  In fact, there will be people on both sides that "_strongly_" disagree.  So while I understand we will not get unanimity, we need to get general consensus to move forward.  So it is important that we hear concrete use-cases in simple and easy to understand terms. We also need to respect that just because there is a use case, that does not mean the TC will agree to do it at this time.  So please, everyone!, be patient, calm, and let us work through these last few things.

 

Topics for the working call:

  1. Switch from JSON RFC8259 to I-JSON RFC7493
    1. Change our definition of integer to comply with RFC7493
  1. Versioning of Cyber Observables (* highly confrontational topic *) 
    1. Can we or should we support versioning by default on Cyber Observable objects?
    2. If we do, this will require breaking changes on other objects due to property name collisions
    3. People that need this, could do this with custom properties
    4. Right now we only have some of the properties and they are all optional
      1. So they do not follow the normal STIX versioning rules 
      2. No revoked or created_by_ref property
    1. What happens if you do not have versioning properties populated and then revision later?
    2. What happens if you have no created_by_ref, then can you really version it per our normal rules?
    3. Two groups have requested this, and several groups are against this. 
  1. Which SCO Properties are going to be stay as embedded relationships and which are going to move to external relationships
    1. I am including a spreadsheet in this email that shows what came out of the mini-group
    2. We just need to verify that this is correct.  If it is, we will need to define the "external relationships" for those properties that are changing 
    3. How will these new external relationships impact Patterning????

 

Please come prepared to discuss these issues.  

 

Thanks

Bret

 

 



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