OASIS Cyber Threat Intelligence (CTI) TC

Hm, I would not have said these same things. We had a short discussion in the doc comments earlier, my assumption was:

Type names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same. Property names are all lowercase, using underscores, e.g. “created_by_ref” String enum values, e.g. relationship value/nature, are lowercase using dashes, e.g. “has-source"









From: < cti@lists.oasis-open.org > on behalf of Rich Piazza < rpiazza@mitre.org >
Date: Wednesday, February 10, 2016 at 2:41 PM
To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: [cti] Suggested formatting for normative text








As we start writing normative text in Google docs we should agree about some basic rules for formatting and naming, so we don’t have to fix it later (coming from someone who had to do that to 15 STIX documents and 94 CybOX documents….). 

 
Here are is what we are currently doing for formatting:
 
·         
Use Arial/11pt for basic text.
·         
Use the provided header styles
·         
Use Consolas/11pt  for JSON examples (color: RGB(199, 37, 78)) with background (color: RGB(249, 242, 244))
·         
Property names in  bold
 
For naming, we haven’t been consistent… here is a list of proposed rules
 
·         
Type names do not have the “Type” suffix
·         
Type names are camel case
·         
Property names are all lower case, using dashes, not underscores.
 
Should type names and property names be in a special font and/or color?   Currently it is the same as the JSON examples.
 
Comments?
 
 

It’s hard to determine what was agreed to by reading those doc comments – I guess my interpretation was off
J
 
What you state below seems to be closer to what is mostly currently in the docs – so that’s fine with me.
 


From: Wunder, John A.
Sent: Wednesday, February 10, 2016 2:48 PM
To: Piazza, Rich <rpiazza@mitre.org>; cti@lists.oasis-open.org
Subject: Re: [cti] Suggested formatting for normative text


 



Hm, I would not have said these same things. We had a short discussion in the doc comments earlier, my assumption was:


·         
Type names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same.

·         
Property names are all lowercase, using underscores, e.g. “created_by_ref”

·         
String enum values, e.g. relationship value/nature, are lowercase using dashes, e.g. “has-source"



 


From:
< cti@lists.oasis-open.org > on behalf of Rich Piazza < rpiazza@mitre.org >
Date: Wednesday, February 10, 2016 at 2:41 PM
To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: [cti] Suggested formatting for normative text


 



As we start writing normative text in Google docs we should agree about some basic rules for formatting and naming, so we don’t have to fix it later (coming from someone who had to do that
to 15 STIX documents and 94 CybOX documents….). 
 
Here are is what we are currently doing for formatting:
 

·         
Use Arial/11pt for basic text.

·         
Use the provided header styles

·         
Use Consolas/11pt  for JSON examples (color: RGB(199, 37, 78)) with background (color: RGB(249, 242, 244))

·         
Property names in  bold
 
For naming, we haven’t been consistent… here is a list of proposed rules
 

·         
Type names do not have the “Type” suffix

·         
Type names are camel case

·         
Property names are all lower case, using dashes, not underscores.
 
Should type names and property names be in a special font and/or color?   Currently it is the same as the JSON examples.
 
Comments?
 
 

This was my understanding as well









From: < cti@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org >
Date: Wednesday, February 10, 2016 at 2:48 PM
To: Rich Piazza < rpiazza@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Suggested formatting for normative text







Hm, I would not have said these same things. We had a short discussion in the doc comments earlier, my assumption was:

Type names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same. Property names are all lowercase, using underscores, e.g. “created_by_ref” String enum values, e.g. relationship value/nature, are lowercase using dashes, e.g. “has-source"









From: < cti@lists.oasis-open.org > on behalf of Rich Piazza < rpiazza@mitre.org >
Date: Wednesday, February 10, 2016 at 2:41 PM
To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: [cti] Suggested formatting for normative text








As we start writing normative text in Google docs we should agree about some basic rules for formatting and naming, so we don’t have to fix it later (coming from someone who had to do that to 15 STIX documents and 94 CybOX documents….). 

 
Here are is what we are currently doing for formatting:
 
·         
Use Arial/11pt for basic text.
·         
Use the provided header styles
·         
Use Consolas/11pt  for JSON examples (color: RGB(199, 37, 78)) with background (color: RGB(249, 242, 244))
·         
Property names in  bold
 
For naming, we haven’t been consistent… here is a list of proposed rules
 
·         
Type names do not have the “Type” suffix
·         
Type names are camel case
·         
Property names are all lower case, using dashes, not underscores.
 
Should type names and property names be in a special font and/or color?   Currently it is the same as the JSON examples.
 
Comments?
 
 

Type names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same. Property names are all lowercase, using underscores, e.g. “created_by_ref”



Is there a reason why everything couldn’t just be the same? Remembering the names of all the things in STIX/TAXII is hard enough, I’d rather not add a thing to remember if we don’t have to. My vote would be for all lowercase, all dashes.


Thank you.
-Mark








From: < cti@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Wednesday, February 10, 2016 at 2:48 PM
To: "Piazza, Rich" < rpiazza@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Suggested formatting for normative text







Hm, I would not have said these same things. We had a short discussion in the doc comments earlier, my assumption was:

Type names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same. Property names are all lowercase, using underscores, e.g. “created_by_ref” String enum values, e.g. relationship value/nature, are lowercase using dashes, e.g. “has-source"









From: < cti@lists.oasis-open.org > on behalf of Rich Piazza < rpiazza@mitre.org >
Date: Wednesday, February 10, 2016 at 2:41 PM
To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: [cti] Suggested formatting for normative text








As we start writing normative text in Google docs we should agree about some basic rules for formatting and naming, so we don’t have to fix it later (coming from someone who had to do that to 15 STIX documents and 94 CybOX documents….). 

 
Here are is what we are currently doing for formatting:
 
·         
Use Arial/11pt for basic text.
·         
Use the provided header styles
·         
Use Consolas/11pt  for JSON examples (color: RGB(199, 37, 78)) with background (color: RGB(249, 242, 244))
·         
Property names in  bold
 
For naming, we haven’t been consistent… here is a list of proposed rules
 
·         
Type names do not have the “Type” suffix
·         
Type names are camel case
·         
Property names are all lower case, using dashes, not underscores.
 
Should type names and property names be in a special font and/or color?   Currently it is the same as the JSON examples.
 
Comments?
 
 

If we pick one, we shouldn’t use dashes, which are not valid characters in many programming language variables (hence why field names are underscores).


I would actually like to distinguish them more, to be honest, at least in the spec. As it is, it’s very hard to tell the difference between a field name and a type name. My preference would be to keep our current structure for naming but use a different
formatting rule for type names, field names, and string literals.









From: Mark Davidson < mdavidson@soltra.com >
Date: Thursday, February 11, 2016 at 7:53 AM
To: "Wunder, John A." < jwunder@mitre.org >, Rich Piazza < rpiazza@mitre.org >, " cti@lists.oasis-open.org "
< cti@lists.oasis-open.org >
Subject: Re: [cti] Suggested formatting for normative text








Type names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same. Property names are all lowercase, using underscores, e.g. “created_by_ref”



Is there a reason why everything couldn’t just be the same? Remembering the names of all the things in STIX/TAXII is hard enough, I’d rather not add a thing to remember if we don’t have to. My vote would be for all lowercase, all dashes.


Thank you.
-Mark








From: < cti@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Wednesday, February 10, 2016 at 2:48 PM
To: "Piazza, Rich" < rpiazza@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Suggested formatting for normative text







Hm, I would not have said these same things. We had a short discussion in the doc comments earlier, my assumption was:

Type names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same. Property names are all lowercase, using underscores, e.g. “created_by_ref” String enum values, e.g. relationship value/nature, are lowercase using dashes, e.g. “has-source"









From: < cti@lists.oasis-open.org > on behalf of Rich Piazza < rpiazza@mitre.org >
Date: Wednesday, February 10, 2016 at 2:41 PM
To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: [cti] Suggested formatting for normative text








As we start writing normative text in Google docs we should agree about some basic rules for formatting and naming, so we don’t have to fix it later (coming from someone who had to do that to 15 STIX documents and 94 CybOX documents….). 

 
Here are is what we are currently doing for formatting:
 
·         
Use Arial/11pt for basic text.
·         
Use the provided header styles
·         
Use Consolas/11pt  for JSON examples (color: RGB(199, 37, 78)) with background (color: RGB(249, 242, 244))
·         
Property names in  bold
 
For naming, we haven’t been consistent… here is a list of proposed rules
 
·         
Type names do not have the “Type” suffix
·         
Type names are camel case
·         
Property names are all lower case, using dashes, not underscores.
 
Should type names and property names be in a special font and/or color?   Currently it is the same as the JSON examples.
 
Comments?
 
 

John – can you be a little more explicit when you say “current structure for naming”?
 
Are you thinking of the STIX 1.2 rules?
 


From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org]
On Behalf Of Wunder, John A.
Sent: Thursday, February 11, 2016 8:46 AM
To: cti@lists.oasis-open.org
Subject: Re: [cti] Suggested formatting for normative text


 



If we pick one, we shouldn’t use dashes, which are not valid characters in many programming language variables (hence why field names are underscores).


 


I would actually like to distinguish them more, to be honest, at least in the spec. As it is, it’s very hard to tell the difference between a field name and a type name.
My preference would be to keep our current structure for naming but use a different formatting rule for type names, field names, and string literals.




 


From:
Mark Davidson < mdavidson@soltra.com >
Date: Thursday, February 11, 2016 at 7:53 AM
To: "Wunder, John A." < jwunder@mitre.org >, Rich Piazza < rpiazza@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Suggested formatting for normative text


 






·         
Type names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same.

·         
Property names are all lowercase, using underscores, e.g. “created_by_ref”

 



Is there a reason why everything couldn’t just be the same? Remembering the names of all the things in STIX/TAXII is hard enough, I’d rather not add a thing to remember
if we don’t have to. My vote would be for all lowercase, all dashes.


 


Thank you.


-Mark



 


From:
< cti@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Wednesday, February 10, 2016 at 2:48 PM
To: "Piazza, Rich" < rpiazza@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Suggested formatting for normative text


 






Hm, I would not have said these same things. We had a short discussion in the doc comments earlier, my assumption was:


·         
Type names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same.

·         
Property names are all lowercase, using underscores, e.g. “created_by_ref”

·         
String enum values, e.g. relationship value/nature, are lowercase using dashes, e.g. “has-source"



 


From:
< cti@lists.oasis-open.org > on behalf of Rich Piazza < rpiazza@mitre.org >
Date: Wednesday, February 10, 2016 at 2:41 PM
To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: [cti] Suggested formatting for normative text


 



As we start writing normative text in Google docs we should agree about some basic rules for formatting and naming, so we don’t have to fix it later (coming from someone who had to do that
to 15 STIX documents and 94 CybOX documents….). 
 
Here are is what we are currently doing for formatting:
 

·         
Use Arial/11pt for basic text.

·         
Use the provided header styles

·         
Use Consolas/11pt  for JSON examples (color: RGB(199, 37, 78)) with background (color: RGB(249, 242, 244))

·         
Property names in  bold
 
For naming, we haven’t been consistent… here is a list of proposed rules
 

·         
Type names do not have the “Type” suffix

·         
Type names are camel case

·         
Property names are all lower case, using dashes, not underscores.
 
Should type names and property names be in a special font and/or color?   Currently it is the same as the JSON examples.
 
Comments?
 
 

Sorry, just meant what we had agreed to informally (we = me, you, Bret, Sean) in the e-mail below, with field names as lowercase underscores and type names as lowercase dashes.









From: Rich Piazza < rpiazza@mitre.org >
Date: Thursday, February 11, 2016 at 9:16 AM
To: "Wunder, John A." < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: RE: [cti] Suggested formatting for normative text








John – can you be a little more explicit when you say “current structure for naming”?
 
Are you thinking of the STIX 1.2 rules?
 


From:
cti@lists.oasis-open.org [ mailto:cti@lists.oasis-open.org ]
On Behalf Of Wunder, John A.
Sent: Thursday, February 11, 2016 8:46 AM
To: cti@lists.oasis-open.org
Subject: Re: [cti] Suggested formatting for normative text


 



If we pick one, we shouldn’t use dashes, which are not valid characters in many programming language variables (hence why field names are underscores).


 


I would actually like to distinguish them more, to be honest, at least in the spec. As it is, it’s very hard to tell the difference between a field name and a type name.
My preference would be to keep our current structure for naming but use a different formatting rule for type names, field names, and string literals.




 


From:
Mark Davidson < mdavidson@soltra.com >
Date: Thursday, February 11, 2016 at 7:53 AM
To: "Wunder, John A." < jwunder@mitre.org >, Rich Piazza < rpiazza@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Suggested formatting for normative text


 






·         
Type names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same.

·         
Property names are all lowercase, using underscores, e.g. “created_by_ref”

 



Is there a reason why everything couldn’t just be the same? Remembering the names of all the things in STIX/TAXII is hard enough, I’d rather not add a thing to remember
if we don’t have to. My vote would be for all lowercase, all dashes.


 


Thank you.


-Mark



 


From:
< cti@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Wednesday, February 10, 2016 at 2:48 PM
To: "Piazza, Rich" < rpiazza@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Suggested formatting for normative text


 






Hm, I would not have said these same things. We had a short discussion in the doc comments earlier, my assumption was:


·         
Type names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same.

·         
Property names are all lowercase, using underscores, e.g. “created_by_ref”

·         
String enum values, e.g. relationship value/nature, are lowercase using dashes, e.g. “has-source"



 


From:
< cti@lists.oasis-open.org > on behalf of Rich Piazza < rpiazza@mitre.org >
Date: Wednesday, February 10, 2016 at 2:41 PM
To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: [cti] Suggested formatting for normative text


 



As we start writing normative text in Google docs we should agree about some basic rules for formatting and naming, so we don’t have to fix it later (coming from someone who had to do that
to 15 STIX documents and 94 CybOX documents….). 
 
Here are is what we are currently doing for formatting:
 

·         
Use Arial/11pt for basic text.

·         
Use the provided header styles

·         
Use Consolas/11pt  for JSON examples (color: RGB(199, 37, 78)) with background (color: RGB(249, 242, 244))

·         
Property names in  bold
 
For naming, we haven’t been consistent… here is a list of proposed rules
 

·         
Type names do not have the “Type” suffix

·         
Type names are camel case

·         
Property names are all lower case, using dashes, not underscores.
 
Should type names and property names be in a special font and/or color?   Currently it is the same as the JSON examples.
 
Comments?
 
 

>I would actually like to distinguish them more, to be honest, at least in the spec. As it is, it’s very hard to tell the difference between a field name and a type name. My preference would be to keep our current structure for naming but use a different
>formatting rule for type names, field names, and string literals.


+1









From: < cti@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org >
Date: Thursday, February 11, 2016 at 8:46 AM
To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Suggested formatting for normative text







If we pick one, we shouldn’t use dashes, which are not valid characters in many programming language variables (hence why field names are underscores).


I would actually like to distinguish them more, to be honest, at least in the spec. As it is, it’s very hard to tell the difference between a field name and a type name. My preference would be to keep our current structure for naming but use a different
formatting rule for type names, field names, and string literals.









From: Mark Davidson < mdavidson@soltra.com >
Date: Thursday, February 11, 2016 at 7:53 AM
To: "Wunder, John A." < jwunder@mitre.org >, Rich Piazza < rpiazza@mitre.org >, " cti@lists.oasis-open.org "
< cti@lists.oasis-open.org >
Subject: Re: [cti] Suggested formatting for normative text








Type names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same. Property names are all lowercase, using underscores, e.g. “created_by_ref”



Is there a reason why everything couldn’t just be the same? Remembering the names of all the things in STIX/TAXII is hard enough, I’d rather not add a thing to remember if we don’t have to. My vote would be for all lowercase, all dashes.


Thank you.
-Mark








From: < cti@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Wednesday, February 10, 2016 at 2:48 PM
To: "Piazza, Rich" < rpiazza@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Suggested formatting for normative text







Hm, I would not have said these same things. We had a short discussion in the doc comments earlier, my assumption was:

Type names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same. Property names are all lowercase, using underscores, e.g. “created_by_ref” String enum values, e.g. relationship value/nature, are lowercase using dashes, e.g. “has-source"









From: < cti@lists.oasis-open.org > on behalf of Rich Piazza < rpiazza@mitre.org >
Date: Wednesday, February 10, 2016 at 2:41 PM
To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: [cti] Suggested formatting for normative text








As we start writing normative text in Google docs we should agree about some basic rules for formatting and naming, so we don’t have to fix it later (coming from someone who had to do that to 15 STIX documents and 94 CybOX documents….). 

 
Here are is what we are currently doing for formatting:
 
·         
Use Arial/11pt for basic text.
·         
Use the provided header styles
·         
Use Consolas/11pt  for JSON examples (color: RGB(199, 37, 78)) with background (color: RGB(249, 242, 244))
·         
Property names in  bold
 
For naming, we haven’t been consistent… here is a list of proposed rules
 
·         
Type names do not have the “Type” suffix
·         
Type names are camel case
·         
Property names are all lower case, using dashes, not underscores.
 
Should type names and property names be in a special font and/or color?   Currently it is the same as the JSON examples.
 
Comments?
 
 

Has the group considered a naming convention that combines type and field name into a single term to avoid having separate items for key vs type? For example: “ipv4_address_s”: “12.1.1.1” “ipv4_address_ui”: 2323232 “a_integerfield_i”: 12 “a_unsignedint_ui”: 5 “a_hexfield_h”: “0f020f03”, “a_hash_md5_h”: 0dd3f6a83347768b88f3013dce592d3d  “a_hash_sha512_h”: “5f199ae2df70ec1d73c9c43ece12350d9b50dab7c043264fee6ab4566be81a5c3b52328e006a9c90faba06f763b382ee5a48d6cff2867a9aeb95e01fe4c446ee The general layout would be <field_key>_<type_identifier>” : <value> where type_identifier is predefined and known for all types that are supported. It would include strings, integers, hex, mac-addresses, floats….etc. This has the advantage of efficiently defining fields and allow reading of the data without knowing a-priori the types. It allows new fields to be easily introduced by providers without having to agree a pre-defined schema. Allan   On Feb 11, 2016, at 6:42 AM, Barnum, Sean D. < sbarnum@MITRE.ORG > wrote: >I would actually like to distinguish them more, to be honest, at least in the spec. As it is, it’s very hard to tell the difference between a field name and a type name. My preference would be to keep our current structure for naming but use a different >formatting rule for type names, field names, and string literals. +1 From:   < cti@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org > Date:   Thursday, February 11, 2016 at 8:46 AM To:   cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject:   Re: [cti] Suggested formatting for normative text If we pick one, we shouldn’t use dashes, which are not valid characters in many programming language variables (hence why field names are underscores). I would actually like to distinguish them more, to be honest, at least in the spec. As it is, it’s very hard to tell the difference between a field name and a type name. My preference would be to keep our current structure for naming but use a different formatting rule for type names, field names, and string literals. From:   Mark Davidson < mdavidson@soltra.com > Date:   Thursday, February 11, 2016 at 7:53 AM To:   Wunder, John A. < jwunder@mitre.org >, Rich Piazza < rpiazza@mitre.org >, cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject:   Re: [cti] Suggested formatting for normative text Type names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same. Property names are all lowercase, using underscores, e.g. “created_by_ref” Is there a reason why everything couldn’t just be the same? Remembering the names of all the things in STIX/TAXII is hard enough, I’d rather not add a thing to remember if we don’t have to. My vote would be for all lowercase, all dashes. Thank you. -Mark From:   < cti@lists.oasis-open.org > on behalf of Wunder, John A. < jwunder@mitre.org > Date:   Wednesday, February 10, 2016 at 2:48 PM To:   Piazza, Rich < rpiazza@mitre.org >, cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject:   Re: [cti] Suggested formatting for normative text Hm, I would not have said these same things. We had a short discussion in the doc comments earlier, my assumption was: Type names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same. Property names are all lowercase, using underscores, e.g. “created_by_ref” String enum values, e.g. relationship value/nature, are lowercase using dashes, e.g. “has-source From:   < cti@lists.oasis-open.org > on behalf of Rich Piazza < rpiazza@mitre.org > Date:   Wednesday, February 10, 2016 at 2:41 PM To:   cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject:   [cti] Suggested formatting for normative text As we start writing normative text in Google docs we should agree about some basic rules for formatting and naming, so we don’t have to fix it later (coming from someone who had to do that to 15 STIX documents and 94 CybOX documents….).    Here are is what we are currently doing for formatting:   ·            Use Arial/11pt for basic text. ·            Use the provided header styles ·            Use Consolas/11pt  for JSON examples (color: RGB(199, 37, 78)) with background (color: RGB(249, 242, 244)) ·            Property names in  bold   For naming, we haven’t been consistent… here is a list of proposed rules   ·            Type names do not have the “Type” suffix ·            Type names are camel case ·            Property names are all lower case, using dashes, not underscores.   Should type names and property names be in a special font and/or color?   Currently it is the same as the JSON examples.   Comments? Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

I agree as well. How about:

Field names in courier Type names in bold String literals in italics






-Ivan




From: < cti@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org >
Date: Thursday, February 11, 2016 at 7:42 AM
To: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Suggested formatting for normative text







>I would actually like to distinguish them more, to be honest, at least in the spec. As it is, it’s very hard to tell the difference between a field name and a type name. My preference would be to keep our current structure for naming but use a different
>formatting rule for type names, field names, and string literals.


+1









From: < cti@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org >
Date: Thursday, February 11, 2016 at 8:46 AM
To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Suggested formatting for normative text







If we pick one, we shouldn’t use dashes, which are not valid characters in many programming language variables (hence why field names are underscores).


I would actually like to distinguish them more, to be honest, at least in the spec. As it is, it’s very hard to tell the difference between a field name and a type name. My preference would be to keep our current structure for naming but use a different
formatting rule for type names, field names, and string literals.









From: Mark Davidson < mdavidson@soltra.com >
Date: Thursday, February 11, 2016 at 7:53 AM
To: "Wunder, John A." < jwunder@mitre.org >, Rich Piazza < rpiazza@mitre.org >, " cti@lists.oasis-open.org "
< cti@lists.oasis-open.org >
Subject: Re: [cti] Suggested formatting for normative text








Type names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same. Property names are all lowercase, using underscores, e.g. “created_by_ref”



Is there a reason why everything couldn’t just be the same? Remembering the names of all the things in STIX/TAXII is hard enough, I’d rather not add a thing to remember if we don’t have to. My vote would be for all lowercase, all dashes.


Thank you.
-Mark








From: < cti@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Wednesday, February 10, 2016 at 2:48 PM
To: "Piazza, Rich" < rpiazza@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Suggested formatting for normative text







Hm, I would not have said these same things. We had a short discussion in the doc comments earlier, my assumption was:

Type names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same. Property names are all lowercase, using underscores, e.g. “created_by_ref” String enum values, e.g. relationship value/nature, are lowercase using dashes, e.g. “has-source"









From: < cti@lists.oasis-open.org > on behalf of Rich Piazza < rpiazza@mitre.org >
Date: Wednesday, February 10, 2016 at 2:41 PM
To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: [cti] Suggested formatting for normative text








As we start writing normative text in Google docs we should agree about some basic rules for formatting and naming, so we don’t have to fix it later (coming from someone who had to do that to 15 STIX documents and 94 CybOX documents….). 

 
Here are is what we are currently doing for formatting:
 
·         
Use Arial/11pt for basic text.
·         
Use the provided header styles
·         
Use Consolas/11pt  for JSON examples (color: RGB(199, 37, 78)) with background (color: RGB(249, 242, 244))
·         
Property names in  bold
 
For naming, we haven’t been consistent… here is a list of proposed rules
 
·         
Type names do not have the “Type” suffix
·         
Type names are camel case
·         
Property names are all lower case, using dashes, not underscores.
 
Should type names and property names be in a special font and/or color?   Currently it is the same as the JSON examples.
 
Comments?
 
 

Do you mean “ Type names in
bold
courier ”.  I think all language terms should be in the same font.
 
I don’t know if you noticed, but in the google docs all of the field names are in bold
L
 
BTW – I made this comment in one of the docs related to this line:
 
marking_refs field (of type
marking-refs )
 
From the STIX 1.2 spec - there were many types and properties that had the same name - except type names had the "Type" suffix. I don't want to go back to that - but maybe camel case is better. These look the same.
I know we can use different colors/fonts in the documents, but otherwise, I think it is going to be confusing – like in an email.
 


From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org]
On Behalf Of Kirillov, Ivan A.
Sent: Thursday, February 11, 2016 10:02 AM
To: cti@lists.oasis-open.org
Subject: Re: [cti] Suggested formatting for normative text


 


I agree as well. How about:


·         
Field names in
courier

·         
Type names in
bold

·         
String literals in
italics


 


-Ivan


 


From:
< cti@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org >
Date: Thursday, February 11, 2016 at 7:42 AM
To: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Suggested formatting for normative text


 






>I would actually like to distinguish them more, to be honest, at least in the spec. As it is, it’s very hard to tell the difference between a field name and a type name.
My preference would be to keep our current structure for naming but use a different >formatting rule for type names, field names, and string literals.


 


+1




 


From:
< cti@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org >
Date: Thursday, February 11, 2016 at 8:46 AM
To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Suggested formatting for normative text


 






If we pick one, we shouldn’t use dashes, which are not valid characters in many programming language variables (hence why field names are underscores).


 


I would actually like to distinguish them more, to be honest, at least in the spec. As it is, it’s very hard to tell the difference between a field name and a type name.
My preference would be to keep our current structure for naming but use a different formatting rule for type names, field names, and string literals.




 


From:
Mark Davidson < mdavidson@soltra.com >
Date: Thursday, February 11, 2016 at 7:53 AM
To: "Wunder, John A." < jwunder@mitre.org >, Rich Piazza < rpiazza@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Suggested formatting for normative text


 






·         
Type names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same.

·         
Property names are all lowercase, using underscores, e.g. “created_by_ref”

 



Is there a reason why everything couldn’t just be the same? Remembering the names of all the things in STIX/TAXII is hard enough, I’d rather not add a thing to remember
if we don’t have to. My vote would be for all lowercase, all dashes.


 


Thank you.


-Mark



 


From:
< cti@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Wednesday, February 10, 2016 at 2:48 PM
To: "Piazza, Rich" < rpiazza@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Suggested formatting for normative text


 






Hm, I would not have said these same things. We had a short discussion in the doc comments earlier, my assumption was:


·         
Type names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same.

·         
Property names are all lowercase, using underscores, e.g. “created_by_ref”

·         
String enum values, e.g. relationship value/nature, are lowercase using dashes, e.g. “has-source"



 


From:
< cti@lists.oasis-open.org > on behalf of Rich Piazza < rpiazza@mitre.org >
Date: Wednesday, February 10, 2016 at 2:41 PM
To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: [cti] Suggested formatting for normative text


 



As we start writing normative text in Google docs we should agree about some basic rules for formatting and naming, so we don’t have to fix it later (coming from someone who had to do that
to 15 STIX documents and 94 CybOX documents….). 
 
Here are is what we are currently doing for formatting:
 

·         
Use Arial/11pt for basic text.

·         
Use the provided header styles

·         
Use Consolas/11pt  for JSON examples (color: RGB(199, 37, 78)) with background (color: RGB(249, 242, 244))

·         
Property names in  bold
 
For naming, we haven’t been consistent… here is a list of proposed rules
 

·         
Type names do not have the “Type” suffix

·         
Type names are camel case

·         
Property names are all lower case, using dashes, not underscores.
 
Should type names and property names be in a special font and/or color?   Currently it is the same as the JSON examples.
 
Comments?
 
 

Can I suggest that for those of us that really care about formatting and style of text in the drafts (not the content of the drafts), get on a phone call where we can talk through it?   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 Feb 11, 2016, at 08:35, Piazza, Rich < rpiazza@MITRE.ORG > wrote: Do you mean   “ Type names in   bold   courier ”.  I think all language terms should be in the same font.   I don’t know if you noticed, but in the google docs all of the field names are in bold   L   BTW – I made this comment in one of the docs related to this line:   marking_refs   field (of type   marking-refs )   From the STIX 1.2 spec - there were many types and properties that had the same name - except type names had the Type suffix. I don't want to go back to that - but maybe camel case is better. These look the same. I know we can use different colors/fonts in the documents, but otherwise, I think it is going to be confusing – like in an email.   From:   cti@lists.oasis-open.org   [ mailto:cti@lists.oasis-open.org ]   On Behalf Of   Kirillov, Ivan A. Sent:   Thursday, February 11, 2016 10:02 AM To:   cti@lists.oasis-open.org Subject:   Re: [cti] Suggested formatting for normative text   I agree as well. How about: ·            Field names in   courier ·            Type names in   bold ·            String literals in   italics   -Ivan   From:   < cti@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org > Date:   Thursday, February 11, 2016 at 7:42 AM To:   John Wunder < jwunder@mitre.org >, cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject:   Re: [cti] Suggested formatting for normative text   >I would actually like to distinguish them more, to be honest, at least in the spec. As it is, it’s very hard to tell the difference between a field name and a type name. My preference would be to keep our current structure for naming but use a different >formatting rule for type names, field names, and string literals.   +1   From:   < cti@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org > Date:   Thursday, February 11, 2016 at 8:46 AM To:   cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject:   Re: [cti] Suggested formatting for normative text   If we pick one, we shouldn’t use dashes, which are not valid characters in many programming language variables (hence why field names are underscores).   I would actually like to distinguish them more, to be honest, at least in the spec. As it is, it’s very hard to tell the difference between a field name and a type name. My preference would be to keep our current structure for naming but use a different formatting rule for type names, field names, and string literals.   From:   Mark Davidson < mdavidson@soltra.com > Date:   Thursday, February 11, 2016 at 7:53 AM To:   Wunder, John A. < jwunder@mitre.org >, Rich Piazza < rpiazza@mitre.org >, cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject:   Re: [cti] Suggested formatting for normative text   ·            Type names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same. ·            Property names are all lowercase, using underscores, e.g. “created_by_ref”   Is there a reason why everything couldn’t just be the same? Remembering the names of all the things in STIX/TAXII is hard enough, I’d rather not add a thing to remember if we don’t have to. My vote would be for all lowercase, all dashes.   Thank you. -Mark   From:   < cti@lists.oasis-open.org > on behalf of Wunder, John A. < jwunder@mitre.org > Date:   Wednesday, February 10, 2016 at 2:48 PM To:   Piazza, Rich < rpiazza@mitre.org >, cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject:   Re: [cti] Suggested formatting for normative text   Hm, I would not have said these same things. We had a short discussion in the doc comments earlier, my assumption was: ·            Type names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same. ·            Property names are all lowercase, using underscores, e.g. “created_by_ref” ·            String enum values, e.g. relationship value/nature, are lowercase using dashes, e.g. “has-source   From:   < cti@lists.oasis-open.org > on behalf of Rich Piazza < rpiazza@mitre.org > Date:   Wednesday, February 10, 2016 at 2:41 PM To:   cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject:   [cti] Suggested formatting for normative text   As we start writing normative text in Google docs we should agree about some basic rules for formatting and naming, so we don’t have to fix it later (coming from someone who had to do that to 15 STIX documents and 94 CybOX documents….).      Here are is what we are currently doing for formatting:   ·            Use Arial/11pt for basic text. ·            Use the provided header styles ·            Use Consolas/11pt  for JSON examples (color: RGB(199, 37, 78)) with background (color: RGB(249, 242, 244)) ·            Property names in  bold   For naming, we haven’t been consistent… here is a list of proposed rules   ·            Type names do not have the “Type” suffix ·            Type names are camel case ·            Property names are all lower case, using dashes, not underscores.   Should type names and property names be in a special font and/or color?   Currently it is the same as the JSON examples.   Comments? Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

It has been really hard to resist trolling this thread.
 


Thanks,
 
Alex


 


From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org]
On Behalf Of Jordan, Bret
Sent: Thursday, February 11, 2016 12:25 PM
To: Piazza, Rich
Cc: Kirillov, Ivan A.; cti@lists.oasis-open.org
Subject: Re: [cti] Suggested formatting for normative text


 
Can I suggest that for those of us that really care about formatting and style of text in the drafts (not the content of the drafts), get on a phone call where we can talk through it?  







 


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 Feb 11, 2016, at 08:35, Piazza, Rich < rpiazza@MITRE.ORG > wrote:

 


Do you mean   “ Type
names in   bold   courier ”.  I
think all language terms should be in the same font.


 


I don’t know if you noticed, but in the google docs all of the field names are in bold   L


 


BTW – I made this comment in one of the docs related to this line:


 


marking_refs   field
(of type   marking-refs )


 


From the STIX 1.2 spec - there were many types and properties that had the same name - except type names had the "Type" suffix. I don't want to go back to that - but maybe
camel case is better. These look the same. I know we can use different colors/fonts in the documents, but otherwise, I think it is going to be confusing – like in an email.


 




From:   cti@lists.oasis-open.org   [ mailto:cti@lists.oasis-open.org ]   On
Behalf Of   Kirillov, Ivan A.
Sent:   Thursday, February 11, 2016 10:02 AM
To:   cti@lists.oasis-open.org
Subject:   Re: [cti] Suggested formatting for normative text




 




I agree as well. How about:



·            Field
names in   courier


·            Type
names in   bold


·            String
literals in   italics




 




-Ivan




 




From:   < cti@lists.oasis-open.org >
on behalf of Sean Barnum < sbarnum@mitre.org >
Date:   Thursday, February 11, 2016 at 7:42 AM
To:   John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org "
< cti@lists.oasis-open.org >
Subject:   Re: [cti] Suggested formatting for normative text




 








>I would actually like to distinguish them more, to be honest, at least in the spec. As it is, it’s very hard to tell the difference between a field name and a type name.
My preference would be to keep our current structure for naming but use a different >formatting rule for type names, field names, and string literals.




 




+1






 




From:   < cti@lists.oasis-open.org >
on behalf of John Wunder < jwunder@mitre.org >
Date:   Thursday, February 11, 2016 at 8:46 AM
To:   " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject:   Re: [cti] Suggested formatting for normative text




 








If we pick one, we shouldn’t use dashes, which are not valid characters in many programming language variables (hence why field names are underscores).




 




I would actually like to distinguish them more, to be honest, at least in the spec. As it is, it’s very hard to tell the difference between a field name and a type name.
My preference would be to keep our current structure for naming but use a different formatting rule for type names, field names, and string literals.






 




From:   Mark Davidson < mdavidson@soltra.com >
Date:   Thursday, February 11, 2016 at 7:53 AM
To:   "Wunder, John A." < jwunder@mitre.org >, Rich Piazza < rpiazza@mitre.org >,
" cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject:   Re: [cti] Suggested formatting for normative text




 







·            Type
names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same.


·            Property
names are all lowercase, using underscores, e.g. “created_by_ref”



 





Is there a reason why everything couldn’t just be the same? Remembering the names of all the things in STIX/TAXII is hard enough, I’d rather not add a thing to remember if
we don’t have to. My vote would be for all lowercase, all dashes.




 




Thank you.




-Mark





 




From:   < cti@lists.oasis-open.org >
on behalf of "Wunder, John A." < jwunder@mitre.org >
Date:   Wednesday, February 10, 2016 at 2:48 PM
To:   "Piazza, Rich" < rpiazza@mitre.org >, " cti@lists.oasis-open.org "
< cti@lists.oasis-open.org >
Subject:   Re: [cti] Suggested formatting for normative text




 








Hm, I would not have said these same things. We had a short discussion in the doc comments earlier, my assumption was:



·            Type
names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same.


·            Property
names are all lowercase, using underscores, e.g. “created_by_ref”


·            String
enum values, e.g. relationship value/nature, are lowercase using dashes, e.g. “has-source"





 




From:   < cti@lists.oasis-open.org >
on behalf of Rich Piazza < rpiazza@mitre.org >
Date:   Wednesday, February 10, 2016 at 2:41 PM
To:   " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject:   [cti] Suggested formatting for normative text




 





As we start writing normative text in Google docs we should agree about some basic rules for formatting and naming, so we don’t have to fix it later (coming from someone
who had to do that to 15 STIX documents and 94 CybOX documents….).   


 


Here are is what we are currently doing for formatting:


 


·            Use
Arial/11pt for basic text.


·            Use
the provided header styles


·            Use
Consolas/11pt  for JSON examples (color: RGB(199, 37, 78)) with background (color: RGB(249, 242, 244))


·            Property
names in  bold


 


For naming, we haven’t been consistent… here is a list of proposed rules


 


·            Type
names do not have the “Type” suffix


·            Type
names are camel case


·            Property
names are all lower case, using dashes, not underscores.


 


Should type names and property names be in a special font and/or color?   Currently it is the same as the JSON examples.


 


Comments?














 

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.