OASIS Cyber Threat Intelligence (CTI) TC

Jason Keirstead wrote this message on Tue, Apr 12, 2016 at 13:21 -0300: > I agree - but I would also propose that we do not vote on a normative spec, > until there is an affiliated schema artifact attached, regardless of if > that artifact is classified as informative or not. I agree that an non-normative schema is required before final vote of the specification.. I said exactly that in my comments when I voted for JSON to be MTI... But as John said, Pat's question was not about a non-normative JSON schema, but a _normative_ JSON schema, hence my comments... -- John-Mark

Hi folks,  One clarification regarding the OASIS rules in this respect. This is required by  https://www.oasis-open.org/policies-guidelines/tc-process#specQuality , item 7 'Computer Language Definitions.'  If a specification contains any "normative computer language definitions" whether fragments or in whole then they must be "provided in separate plain text files," those files must be referenced from the narrative text of the specification, and should there be any disagreement between the definition found in the specification and the separate file, the definition in the separate file prevails. This isn't something the TC can overrule. Your separate computer language file will be the normative, definitive version.  /chet On Tue, Apr 12, 2016 at 12:30 PM, John-Mark Gurney < jmg@newcontext.com > wrote: Jason Keirstead wrote this message on Tue, Apr 12, 2016 at 13:21 -0300: > I agree - but I would also propose that we do not vote on a normative spec, > until there is an affiliated schema artifact attached, regardless of if > that artifact is classified as informative or not. I agree that an non-normative schema is required before final vote of the specification..  I said exactly that in my comments when I voted for JSON to be MTI... But as John said, Pat's question was not about a non-normative JSON schema, but a _normative_ JSON schema, hence my comments... -- John-Mark --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393 

So what you are saying is the JSON Schemas should not be released as part of the official OASIS work product, but should be released as something else?   Clearly the specification needs to be the official item as example schemas can not be restrictive enough. Given Chet's statement, I would motion against requiring JSON Schema to be part of the specification, but rather have us release it as an information open-source project.   Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Apr 12, 2016, at 11:27, Chet Ensign < chet.ensign@oasis-open.org > wrote: Hi folks,  One clarification regarding the OASIS rules in this respect. This is required by  https://www.oasis-open.org/policies-guidelines/tc-process#specQuality , item 7 'Computer Language Definitions.'  If a specification contains any normative computer language definitions whether fragments or in whole then they must be provided in separate plain text files, those files must be referenced from the narrative text of the specification, and should there be any disagreement between the definition found in the specification and the separate file, the definition in the separate file prevails. This isn't something the TC can overrule. Your separate computer language file will be the normative, definitive version.  /chet On Tue, Apr 12, 2016 at 12:30 PM, John-Mark Gurney < jmg@newcontext.com > wrote: Jason Keirstead wrote this message on Tue, Apr 12, 2016 at 13:21 -0300: > I agree - but I would also propose that we do not vote on a normative spec, > until there is an affiliated schema artifact attached, regardless of if > that artifact is classified as informative or not. I agree that an non-normative schema is required before final vote of the specification..  I said exactly that in my comments when I voted for JSON to be MTI... But as John said, Pat's question was not about a non-normative JSON schema, but a _normative_ JSON schema, hence my comments... -- John-Mark --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393  Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail