[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Language Spec request for change: Format of OpenC2 Response "pairs" field
These comments are related to Language Spec PRD-01, page 21 lines 9-10 and page 28 lines 29-37.
At the F2F last week, we had many discussions about the details surrounding the schema required by Commands and Responses in the current draft (09) Language Spec and how some of the schema decisions we have made result in a more complicated implementation. One of the first things that every Orchestrator will do is to ask a Consumer for its capabilities using the âquery/featuresâ action/target pair. The current spec returns the supported action/target pairs using a JSON structure that looks like this:
This example shows a super-simplified response for illustrative purposes. Where it gets tricky is that this data structure is harder to model in code than it needs to be. The âpairsâ field is an âArray of Arrays of Pairs of (String, Array of Strings)â. That is particularly hard and error-prone to model for typical JSON tools, like Java with Jackson, for example, since the Array of Pairs is invariant with different types in each element of the Array (first element is a String and next element is an Array of String). Also, the âArrays of Pairsâ part will only ever have a single element, so itâs not really an Array (and it being an Array of Invariants can cause folks to mis-interpret the intent of it requiring exactly those two things and no more).
This response is actually just trying to return the Actions and the list of Targets that each action supports. Starting from that requirement, the following is a much simpler data model and can be easily modeled in code as a Map object, like so:
âqueryâ: [ âfeaturesâ, âcommandsâ ],
âdenyâ: [ âfileâ, âuriâ ]
The âpairsâ field becomes a âMap<String, Array<String>>â which is an incredibly easy thing to model in all JSON toolsets.
I was instructed to send this proposal to the TC mailing list as opposed to creating a GitHub issue directly, but my desire is that we have a discussion/resolution on this matter before the next Public Review period of the Language Spec.