Results is not valid

[davaya]

I did not notice an issue or pull request to change the structure of OpenC2-Response, but it has changed to include a "results" field with an invalid definition.

| 5 | **results** | MapOf(key, value) | 0..* | Generic Map of key:value pairs (keys are strings, and values are any valid JSON value). A JSON value can be an object, array, number, string, true, false, or null, as defined by ECMA-404. |

The definition must specify valid Types from Section 3.1.1 (String, Integer, Map, etc) or types that are defined somewhere in Section 3.4, e.g.

MapOf(URI, String)

which says that a key must be a valid URI, and is mapped to any String (e.g., a summary of the contents of the page.)

The key could theoretically be defined to be a String, but that would mean that the text of the Gettysburg Address:

Fourscore and seven years ago our fathers brought forth on this continent,
a new nation, conceived in Liberty, and dedicated to the proposition that all
men are created equal.

Now we are engaged in a great civil war, testing whether that nation, or any
nation so conceived and so dedicated, can long endure. We are met on a great
battle-field of that war. We have come to dedicate a portion of that field, as a
final resting place for those who here gave their lives that that nation might live.
It is altogether fitting and proper that we should do this.

But, in a larger sense, we can not dedicate-we can not consecrate-we can not
hallow-this ground. The brave men, living and dead, who struggled here, have
consecrated it, far above our poor power to add or detract. The world will little
note, nor long remember what we say here, but it can never forget what they
did here. It is for us the living, rather, to be dedicated here to the unfinished
work which they who fought here have thus far so nobly advanced. It is rather
for us to be here dedicated to the great task remaining before us-that from
these honored dead we take increased devotion to that cause for which they
gave the last full measure of devotion-that we here highly resolve that these
dead shall not have died in vain-that this nation, under God, shall have a new
birth of freedom-and that government of the people, by the people, for the
people shall not perish from the earth.

is a valid key. Since OpenC2 is intended to enable interoperability, that isn't a very useful definition.

[romanojd]

We talked about this at the meeting and you said it should be "MapOf" instead of "Map". The intent is to have a generic "results" property that serializes into a JSON Object. This can be extended for what ever purpose any Actuator Profile defines.

[davaya]

MapOf is a defined type, just like Record or Map, and it must specify a key type and a value type. The way to say "anything" is with the Null type (meaning unspecified), just like the C language void * type (https://www.learncpp.com/cpp-tutorial/613-void-pointers/) is a pointer to anything.

If there were a property table for section 3.2 (Message), Null would be the type of the content message element because the format of the content is specified by the content_type and msg_type elements, not by a defined Type,

The way for an Actuator Profile to define what a response contains is to create a type (e.g., slpf:Response) that is imported into OpenC2-Response, the same way profiles define Target and Args. A generic Response (type Null, or type MapOf(String, Null)) means that profiles don't define or care what the response contains, except in the latter case that it is an object with any key (such as the Gettysburg Address) and any value. If the intent is really to allow anything rather than to "extend for what ever purpose" in a profile, then your example needs to be MapOf(String, Null).

(We can rename slpf:Response to slpf:Results if that sounds better.)

[romanojd]

The proposed changes were incorporated into pull request #295, but since there were other, unrelated changes included in that pull request and that we amended the changes at the LSC Meeting, I created a separate, standalone pull request to address this single issue.

LSC Meeting, 3/26/2019: There were no objections to applying pull request #297 and closing this issue.