[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cti] Minor spec question: minimum characters for custom property/object names
From a programmatic perspective it can be useful since some systems use very short key values for internal purposes. It’s also helpful to avoid overlap between custom fields defined by different groups for widely different purposes none of which can be explained since the keys for such values are things like “a”, “x” and “qr”. Jeffrey Mates, Civ DC3/DCCI ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Computer Scientist Defense Cyber Crime Institute jeffrey.mates@dc3.mil 410-694-4335 From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Sean Barnum Thank you for the clarification. Honestly, I have never really seen the value in having those restrictions and think we would be better off without them. Is there anyone arguing for the remaining restriction to stay in place? If not, then why not remove it as well to be consistent? Unless there is someone arguing to keep it, this does not seem like it would be huge time sink to change. I don’t want to go down a huge rabbit hole explaining pedantic details (I am sure you don’t want me too either 😉 ) but I do see some risk and unnecessary limitations in having differing naming constraints on dictionary keys and custom properties/objects. These constructs are our escape clause supporting flexibility where it may be required and unless there is a specific reason to constrain their length, why do it? Taking the dictionary approach has its advantages in some scenarios where custom properties/objects have advantages in others and, avoiding the aforementioned rabbit holes, I can think of some scenarios where locally scoped transformations may wish to move content between the two structural approaches where both forms are valid STIX. Differing length constraints would limit the flexibility to do that without changing property names. Definitely not a huge issue but an issue nonetheless and one we can simply avoid by removing the remaining constraint as well unless there is someone specifically arguing to keep it. If I end up the lone voice in the wilderness asking to remove the constraint then go ahead and leave it as is. I just do not see the rationale to not fix it now while it is easy. Sean Barnum Principal Architect FireEye M: 703.473.8262 E: sean.barnum@fireeye.com From: <cti@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org> My e-mail probably wasn’t clear, the requirement was removed completely from dictionary but still exists for custom properties and custom objects. It’s not like it’s 3 for custom stuff and 2 for dictionaries. So I don’t think we have inconsistent requirements, we just only have the requirements when they apply to custom stuff. Given that would you be OK as-is? John From: Sean Barnum <sean.barnum@FireEye.com> I would support removing the requirements altogether. If we keep the requirements, I think they should match. Sean Barnum Principal Architect FireEye M: 703.473.8262 E: sean.barnum@fireeye.com From: <cti@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org> Hi all, We discussed a minor topic on this past working call and I wanted to summarize the discussion and see if anyone else had any thoughts. Notes from the working call are here: https://www.oasis-open.org/committees/download.php/63164/OASIS-CTI-TC_WorkingCall_May29_2018.pdf The specific text is in Part 1, Sections 8.1.1 [1] and 8.2.1 [2]. Currently, we have a normative MUST requirement that all custom property names and custom object names be at least three characters long. This was set in place when, in the specification, we also had a normative MUST for the dictionary type to require properties be longer than two characters. In developing support for internationalization, though, Emmanuelle noticed a bug [3] where this conflicted with the property names required by i18n, ISO language codes, which can be only two characters long. So, we changed the requirement in the text for dictionary to allow for two-character key names in dictionaries. Custom properties and objects are a separate topic, but since the text was originally the same we wanted to bring it up for discussion. We talked about it on the working call this past week and the discussion seemed to land on it not being a huge deal and that we should leave the text as-is. This would mean that, though you can use keys in a dictionary that are only 1 or 2 characters long (including ISO language codes), custom property and object names would still have to be three characters long. Does anybody object to keeping this as-is, per the working call discussion? The other options would be to either change the requirement to a minimum of two characters (effectively allowing everything except one character names) or to remove the requirements altogether. Thanks for your feedback, John [3]: https://github.com/oasis-tcs/cti-stix2/issues/35 This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto. This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto. |
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]