"Title fields MUST be less than 255 octets" says something.
"A STIX processor MUST be able to process a Title field of at least 256 octets” says something.
The language below says nothing.
Based on a conversation we have had on slack, I would propose some text like this:
Title fields SHOULD be between 1-256 characters. Title fields MAY be longer than 256 characters. For non-English languages you SHOULD measure characters as code-points.
Thanks,
Bret Bret Jordan CISSPDirector 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."
If we have no limits and a Soltra Edge user creates a 100GB title and $compatible-product falls over – how does that get resolved? If I was being snotty I would say “well, $compatible-product isn’t fully standards compliant”, even though I think that would be against the spirit of the spec. I do think we should specify limits somehow. Either through a required minimum, a recommended maximum, or something. IMO, the purpose is to give implementers _something_ to work with without having to make wild guesses about what will be available in the ecosystem. The ability to specify the maximum (e.g., code points, graphemes, and other things I don’t understand well) is IMO a separate conversation. I think step #1 is whether we as a group think specifying limits (one way or another) make sense. I would in general say yes, and the arguments to the contrary haven’t swayed me. However, if we don’t want limits, we should just have a piece of informative text stating that there are no limits and why we chose that. Thank you. -Mark My question is - what are you supposed to do with that information?
- You can't take that limit and turn it into a byte limit for buffer purposes - it is not possible. You can't even guess because it depends both on the character encoding as well as the language. Since the character encoding is not part of STIX but part of the serialization binding, trying to figure out the number of bytes a given number of code points will consume is a bit of a fools errand.
- You also can't take that limit and use it in your GUI in any way, because you can't enforce length limits of input fields based on code points - you have to do it based on graphemes/glyphs.
So.. what are people planning to use this limit for?
-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com
Without data, all you are is just another person with an opinion - Unknown
<image001.gif>"Jordan, Bret" ---06/02/2016 08:35:22 PM---To me it just feels wrong or dirty to not have some sort of guidance or some sort of upper limit. I
From: "Jordan, Bret" <bret.jordan@bluecoat.com>
To: John-Mark Gurney <jmg@newcontext.com>, "Eric.Burger@georgetown.edu" <Eric.Burger@georgetown.edu>
Cc: Jason Keirstead/CanEast/IBM@IBMCA, Terry MacDonald <terry.macdonald@cosive.com>, Rich Piazza <rpiazza@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 06/02/2016 08:35 PM
Subject: Re: [cti-stix] Unicode, strings, and STIX
Sent by: <cti-stix@lists.oasis-open.org>
To me it just feels wrong or dirty to not have some sort of guidance or some sort of upper limit. I am not saying the lengths have to be really short.... We could say a title can have up to 256 code points or 512 code points, but the fact is, we should define something, I think...
I have asked Eric, our resident academic to chime in, and he will give us some guidance hopefully tomorrow.
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."
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]
|