Motion for ballot to approve custom properties

All,

Given the long discussion we’ve had on custom properties, general agreement over a couple working calls, email, and slack I think it’s fair to proceed with a ballot to approve the text. I realize there isn’t complete agreement, but this is what ballots
 are for and this will allow us to keep moving towards a 2.0 release.

I motion that the TC open a ballot to accept the Custom Properties text contained in the STIX 2.0-1 document, Section 5.1 (https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.8072zpptza86) and
 move it to draft status. Draft status indicates that the TC generally agrees with the approach and the text as written. Editorial changes to the text may be made after text has been moved to draft status, but any substantive changes after the ballot has passed
 require that the section be moved back to development status and re-accepted.

Text to approve:

---

​5.1.​ Custom
 Properties

The
 authors of this specification recognize that there will be cases where certain information exchanges can be improved by adding fields that are not specified nor reserved in this document; these fields are called
Custom
 Properties.
 This section provides guidance and requirements for how producers can use Custom Properties and how consumers should interpret them in order to extend STIX in an interoperable manner.

​5.1.1.​ Requirements

A
 STIX TLO MAY
 have any number of Custom Properties.

Custom
 Properties SHOULD
 start with “x_” followed by a source unique identifier (like a domain name), an underscore and then the name.  For example:
x_examplecom_customfield.

Custom
 Property keys SHOULD
 have a maximum length of 30 characters.

Custom
 Property keys MUST
 have a minimum length of 3 characters (including the prefix).

Custom
 Property keys MUST
 have a maximum length of 256 characters.

Custom
 Properties that are not prefixed with “x_” may be used in a future version of the specification for a different meaning. If compatibility with future versions of this specification is required, the “x_” prefix
MUST
 be used.

Custom
 Properties SHOULD
 be uniquely named when produced by the same source and SHOULD
 use a consistent namespace prefix (e.g., a domain name).

Custom
 Properties SHOULD
only
 be used when there is no existing field defined by the STIX specification that fulfills that need.

A
 consumer that receives a STIX document with one or more Custom Properties that it does not understand
MAY
 refuse to process the document further or silently ignore non-understood properties and continue processing the document.

The
 reporting and logging of errors originating from the processing of Custom Properties depends heavily on the technology used to transport the STIX document and is therefore not covered in this specification.

Non-Normative:
Producers
 of STIX documents that contain Custom Properties should be well aware of the variability of consumer behavior depending on whether or not the consumer understands the Custom Properties present in a STIX TLO. Rules for processing Custom Properties should be
 well defined and accessible to any consumer that would be reasonably expected to parse them.

​5.1.2.​ Examples

{

 ...,

 "x_acmeinc_scoring":
 {

   "impact":
 "high",

   "probability":
 "low"

 },

 ...

}