Looking Ahead in the Language Spec - Past 1.0

["Considine, Toby" <Toby.Considine@unc.edu>]

Looking Ahead in the Language Spec

 

We now, at last, have Committee Specification 1.0, pending only the administrative/clerical functions of final publishing. This permits us to turn to the Language Spec 1.1, and to possibly different message types.

 

Borrowing some language from David Kemp, A Message (LS section 3.2) is the interface between language and transport.  In 1.0, the sole message type is the Command.

 

Again, quoting David:

 

“There are two widely-recognized messaging patterns in the IT world and the physical world – request/response and one way.    You can send a snail mail letter or postcard or box and it’s normally one-way, unless you say “RSVP” or “Return receipt requested” in which case the sender is requesting a response.   It doesn’t matter what’s inside the envelope, the envelope gets the message to its destination and optionally signals that a response is desired.  If it’s a box containing grapefruit, it can still get a delivery receipt.   HTTP is always request-response.  CoAP is sometimes request-response but it accommodates unacknowledged messages.  Pub/sub (mqtt) is always one-way, unless a message structure is built on top of it to correlate requests with responses.”

“An http message from a client to a server is a “request”.   It is not a “command” unless the body of the request contains a command.   “GET https://www.youtube.com/watch?v=iRXJXaLV0n4” is not a command, it is a request, and the response contains a cat video.  A request for a PDF file is not a command, it is a request.  Posting a PDF file is a request, not a command, EVEN IF the PDF file contains a command FROM the pentagon TO stratcom to launch global thermonuclear war.”

 

End Quote

 

There is a lot of clarity in those paragraphs, although the language is admittedly non-normative.

 

During the F2F, several other types of potential messages were bandied about. There were Polls. There were Requests for Situation Awareness (Reports) of different types. There were others which escape me this morning.

 

In preparation for adding new types of messages to OCLS 1.1, I propose we consider making the Message the more explicit heart of the Language Spec, so we can then effectively sub-class the message into certain types. This *MAY* mean that we define the Response as a Type of Message, but I am not committed to that.

 

One advantage of this is that we have defined a typical “style” of JSON in the Commands, and applying this style explicitly to the Message would define a pattern of other Messages, including the Response, using the same Style. This could make the specification clearer. This style is descended from the use of JADN, and would pre-adapt the spec to consuming JADN when that spec is available. Other bindings and encodings would more easily be defined as permutations of that “style”.

 

To prepare for this work. I propose we insert by something like this at section 3.2

 

 

Abstract Model of OpenC2

The fundamental model for OpenC2 is Message and Response.

 

A Message can be considered as an envelope containing one or more Message Elements. Each Message Element is a specific request to elicit specific service from the target system or systems. We use the term Service, because OpenC2 is concerned with specific mechanisms, but rather with the high-level function.

 

OpenC2 defines a limited number of Message Element Types for Message Elements. Each Message Element must begin with its Message Type. In OpenC2 1.0, the only Message Element Type defined is the Command. See the section nnn below for a discussion of Message Element Types.

The Response is the envelope containing feedback messages (Response Elements), if any, for Message Element (Service invoked).

 

Normally a Response contains Response Elements from a single System, in response to a single Message Element. Specifications derived from this document MAY combine multiple Response Elements inside a single Response. Specifications that do so must define the mechanism of this messaging. New Actuators, such as a message router, MAY opt to include Response Elements from multiple systems. Again, these systems MUST specify the formatting for multiple systems in a single Response.

 

Request IDs

The implementer should distinguish between the OpenC2 Messages and Responses and the request and response familiar in describing network interactions. A Message can be sent several times, each as a different request. Certain firewalled scenarios may turn request and response on its head, as polling is used to discover Messages. This specification (OpenC2 Language Specification) does not define or specify such interactions.

A request ID, where specified, is an identifier for the interaction, not for the Message. There may be a number of reasons to track a request other than by the IDs of the Message Elements. A protocol may handle request header information differently than the payload in the Message. Security auditing systems may want to track each request separately, even if several are used to re-transmit the same Message. The request ID is the transport-dependent identity for the transmission of the Message.

 

Extensibility of on Messages and IDs

In version 1.0 of this specification, the Message is constrained to a single Message Element, and that Message Element is always a Command. Derivative specifications such as the “Specification for Transfer of OpenC2 Messages via HTTPS Version 1.0” describe a single Request ID. No Message ID is described or permitted. If no Command ID is included, then all parties SHALL treat the Request ID AS IF it were the Message Element ID for the Command element within the Message. 

 

In post 1.0 versions. There are additional Message Types, and a request can contain multiple Messages. When communicating with a node that describes itself as conforming to 1.0, a requester MUST limit the Message Types to Commands, and limit the cardinality of the Message to 1. (Note Conformance point).

 

===========================

 End of suggested addition

 

The section defining the Command would then be the first of many Message Definitions (perhaps demoted to 3.2.1?) with other Message definitions to follow.