[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [Non-DoD Source] Re: [openc2-lang] Fwd: mistake inside oc2ls-v1.0-cs02
Given that perspective (forcing a 2.0) the I say the heck with it until we identify other breaking changes. Not enamored with the notion of forcing a 2.0 for
the sake of sequential numbers for an index when there is not really a functional impact
From: duncan sfractal.com <duncan@sfractal.com>
It would be a material and breaking change to renumber. We might want to just add back in the ‘missing numbers’ with any new actions we were thinking of (ie the ones we took out) and then it would still be material but would be non-breaking
(ie 1.1 instead of 2.0). Even though ‘breaking’ would be ok (since so new), 2.0 so soon doesn’t have great optics. Although I suspect we might need to go there for other reasons anyway (ie I’m not confident we are perfect yet - plugfest and time will tell). iPhone, iTypo, iApologize Duncan Sparrell sFractal Consulting, LLC I welcome VSRE emails. Learn more at http://vsre.info/ From: Brule, Joseph M <jmbrule@radium.ncsc.mil> THAT is what the comment meant. I was not tracking.
That is something we should have taken care of. I recall that there was some churn in the action table so rather than constantly rewriting the code in OIF,
we were going to wait until it settled down and do the renumber once. Brian is correct, we should have renumbered it, Brian is correct, it’s just an index so doesn’t really matter.
IF we are going to do this, then we should take care of it ASAP. Right now, all the cool kids are using JSON serialization, but we would want to address any
renumbering BEFORE people start implementing protobuf, cbor or whatever From: openc2-lang@lists.oasis-open.org <openc2-lang@lists.oasis-open.org>
On Behalf Of Brian Berliner There are a lot more numbers than “21” missing in the Action table. We removed some early actions from the table before we released the final version. I also thought that it looked weird that we didn’t re-number the table to make it perfectly
sequential, but in reality they are just identifiers and it doesn’t matter what the number is... but the number assigned in the table should never change. For all of us currently, we use JSON, so the numbers are not even used at all, so this is reserved for when we add binary encodings. So, yes. 21 is missing (and lots of others). That is weird, but by design, and it actually doesn’t matter that they are not perfectly sequential in the table.... Except for the fact that I had to just write this exactly because they are
not perfectly sequential in the finals spec! -Brian On Thu, Jan 23, 2020 at 5:49 AM duncan
sfractal.com <duncan@sfractal.com> wrote:
-- Cheers, -Brian |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]