[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [openc2] DKS06 -Command ID - Lang Spec CSPRD01 comment
|
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> 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:
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/ |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]