PS I probably should have used action= instead of action= >
Duncan Sparrell
sFractal Consulting LLC
iPhone, iTypo, iApologize
I welcome VSRE emails. Learn more at
http://vsre.info /
From: TC OpenC2 <
openc2@lists.oasis-open.org> on behalf of "duncan@sfractal.com" <
duncan@sfractal.com>
Date: Monday, December 10, 2018 at 4:45 PM
To: TC OpenC2 <
openc2@lists.oasis-open.org>
Subject: [openc2] DKS06 -Command ID - Lang Spec CSPRD01 comment
Page 12 lines 16ish-29ish Section 2.1 (and equivalent property tables in section 3)
Previous versions of this specification had and optional Command_ID in addition to Action/Target/Args/Actuator.
I propose to add back in the optional command_id.
It was replaced by the use of the request_id (see page 17 line 14ish) which is in the message header and not in the JSON content. I agree the request_id is the proper field to use for matching requests and
responses. However, I disagree with it s use with action= and the other actions that need a reference to a previous command. JSON content of a command should not be dependent on transport header information. This breaks transport agnostic IMHO. I recognize
models/analogies are all wrong - but as the famous quote say, some are useful. Using the letter (ie our JSON content) and envelope (the message header handled by transport) - almost all letters start with some sort of salutation with the name of the person
addressed. I.e. Dear John lets you know the letter is for John . Similarly I think the action= command should refer to an id within in the JSON.
I feel strongly on this topic. Unfortunately I could not attend the Face-to-Face where this was discussed. My reading of the notes lead me to believe there is still concern on breaking transport agnostic.
I would like, if possible, an informal polling (maybe with comments on GitHub or on a wiki page) with participants answering:
Strongly agree with adding optional command_id
Prefer (but not strongly) adding optional command_id
Ok either way
Prefer (but not strongly) current wording without command_id
Strongly disagree with adding optional command_id
Note I am NOT proposing to change the use of request_id wrt responses only wrt affecting inside the JSON .
I believe there are enough people in the ok either way and Prefer (but not strongly) to warrant reopening the issue even though no one objected at the meeting to removing command_id. I would have objected
if present. I will withdraw on this topic is the survey shows a clear preponderance of people strongly (or weakly) disagree with my proposal. However I will remain vocal (and vote NO) if it is 1 strongly agree (myself) and 1 strongly disagree and everyone
else is ok either way .
Duncan Sparrell
sFractal Consulting LLC
iPhone, iTypo, iApologize
I welcome VSRE emails. Learn more at
http://vsre.info /