RE: Use of the word "profile"

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

Profile is, as you describe, a labile word.

 

I think at is broadest, it describes a set of choices, compatible (and perhaps conforming) with the broader standard to ensure fitness for purpose and interoperation.

 

In some cases, the Profile may make choices about matters outside the base abstract model, but permitted by it. This may be as simple as defining TCP and UDP profiles (almost always nearly identical) or in the 802.11 model, choosing a radio frequency, something the base specification is entirely agnostic of.

 

Standards describe so many things.

 

Some standards are simply âcan interoperate with my widget, and you can test if whatever you have doesâ. This is more formally known as âstandard by reference implementationâ, bit it suffer long term because extensibility is never defined, not is the full scope of the implementation necessarily discoverable. Vendors who supply the reference implementation, but not the code, have been known to break compatibility without warning.

 

We are instead attempting a standard by specification. We want that specification to be able to support things not yet defined, but that somehow âfitâ a way of doing things. For this note, letâs shy away from words the TC is wrestling with such as language, grammar, and architecture, and call this imprecisely the Philosophy of the specification.

 

The philosophy is what makes the expert in one profile to understand the other. Things look and act ârightâ It should be extensible, to talk about things that were not known when the philosophy was developed. To the extent possible, these new things and these old things should be able to coexist. Perhaps the commands/directives to one system cannot be understood by another, but they âlookâ right, because they are created based on the same philosophy.

 

So letâs step away from the philosophy and try to define what the profiles are.

 

1. Common things should use a common vocabulary. Uncommon things must use a specific but compatible vocabulary.
2. The language holds together by a common grammar. [Modifier] Subject Verb [modifier] Object is common in English. Latin often uses Object [Modifier] [Subject] Verb. That sort of flexibility increases code and code branching, so reduces interoperability. In this specification the Grammar is defined by the abstract message pattern (which I consider to be part of the language, and not an architecture). That message may itself be constrainedâin this specification we look to constrain the message by cardinality. More on this later.
3. Restriction is often a key component of a profile, even as it may be adding vocabulary that it compatible, but not common.

 

So far, without getting into serialization, we have defined the capability to profile the language for a specific type of device, by using the common vocabulary as extended by some specific vocabulary but consistent with the abstract message pattern.

 

We are also happily constraining the message cardinality. This is the unexamined gap between those who see in the language a need for a messageID and a requestID and commandID and a targetID and (let alone the targetSpecifiers and actuatorSpecifiers named earlier in the language document). I think that we need all in the abstract message in the language, and Profile that constrains that message and states that the commandID ACTS as the requestID which ACTS as the messageID, and so this profile uses only the commandID. This states the transformation  from the one-at-a-time ActuatorProfile (as currently specified) and the Abstract Message which needs multiple IDs to support multiple messages and, perhaps, bridging and collectingâ

 

We can claim that the single-target Message is a profile of the message in the core Language, to be used whenever another Profile restricts itself to a single Command/Target, or we could state that this is the default Profile within the Actuator, or some other way. I donât think we should restrict the base abstract message in this way.

 

Profiles may also describe encoding. JSON is out default. For interagency OpenC2, XML may be better if we need the heavy duty message processing of SOAP. Or we may stay in SOAP but define an EXI encoding. Many use still other encodings for COAP.

 

Profiles may define Binding. We seem to be focusing on a REST Binding, but as noted above, it is not hard to imagine a message-based SOAP binding, or a bidirectional WebSocket binding.

 

Profiles ideally restrict and extend the Language, to enhance interoperability. They commonly may specify the encoding and the binding as well.

 

To my eye, as Public Review comment, and somewhat shooting from the cuff, the Actuator Profile specification describes an OpenC2 Device Profile and as well as what I might call an Implementation Profile encoding that Device Profile in JSON encoding and REST Binding over HTTP/S.

 

Could a SOAP Actuator Profile use most of the same language in the Specification? Yes.

Could we define a RESFTUL XMP binding using most of the same language? Yes.

 

Iâm not sure if I added any clarity here, but is have tried to sketch the path to long term interoperabilty and extensibility of our work, one that supports protocol, binding, and encoding changes en route as needed.

 

tc

 

 

 

 

From: duncan sfractal.com <duncan@sfractal.com>
Sent: Wednesday, October 24, 2018 10:10 AM
To: Considine, Toby <Toby.Considine@unc.edu>; openc2@lists.oasis-open.org
Subject: Use of the word "profile"

 

Toby,

Could you share your thoughts on the use of the word âprofileâ. We currently use the terms âactuator profileâ (which we sometimes shorten to just âprofileâ but that now sounds dangerous) to describe the specification of how the function of an actuator behaves. We also use the term âprofileâ as part of conformance requirements (a âconformance profileâ??)  to describe a type of subset of conformance requirements (not sure thatâs a good definition but I stole it from OASIS doc which stole it from ISO). I think you are using it slightly differently (In the PIM/PSM context) and Iâd like to understand better.

 

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 Toby Considine <Toby.Considine@unc.edu>
Date: Tuesday, October 23, 2018 at 11:34 AM
To: Joseph Brule <jmbrule@radium.ncsc.mil>, TC OpenC2 <openc2@lists.oasis-open.org>
Subject: RE: Re: [openc2] One item I've noticed on the current CSDs that will need to be fixed

 

Two points, one small and one large:

 

Small:

 

The rule is âwhere the two are in conflictâ.  Any additional elements in the text are *not* in conflict. But that is a shoddy answer to work where the fit and finish are not complete.

 

Large:

 

The Language and the (unwritten) Architecture should be treated *together* as an abstract Platform Independent Model (PIM) and all things downstream as specific Profiles for specific technology and interaction choices (Platform Specific Models)(PSMs).

 

As generally used, a PSM is a specific set of extensions to or constraints on a PIM, and therefore conformant to the PIM. Each PSM then is interoperable with any other PSM by a sort of transitory rule, as each can be transformed into the PIM, and form the PIM into the other PSM. A PIM is never meant to be a specification in and of itself, although I have developed in the past a specific PSM that was as close to the PIM as possible, for use in integrating into other specifications.

 

As OpenC2 moves beyond a set of Products with mere faceplate conformance to an interoperable suite of communication specification, each with quite different assumptions and serialization requirements and communication challenges, the PIM-PSM model is how one enables long-term wide interoperability.

 

Although it predates the PIM-PSM language, consider the standard 802.11 as a PIM. It is unlikely that if you and I sat down with the Standard and began coding and selecting radios that our two systems would be able to interoperate. The industry has instead created a number of profiles that *are* interoperable (802.11 A, B, G, C, AC) and any device that opts to implement more than one of these profiles can easily route between the two because of their mutual conformance with the 802.11 PIM.

 

The rule that a Command must implement only one action (or one target) MAY be part of a Restriction Profile created as a PSM of the PIM, or other Profiles that permit  them must explain how to translate to the PIM, but either model would fit. In either case, that translation to the Abstract PIM defines how interoperable routing or aggregation is achieved.

 

Under this approach, we HAPPEN to describe the abstract information model in JSON, and we require profiles for JSON-based serialization profiles to conform, to that in the PIM, but we do not restrict other serialization schemes. Any other serialization MUST define how it treats each PIM data element, i.e., define its conformance to the PIM.

 

In a similar vein, we use HTTPS to describe the interaction patterns of OpenC2, and MAY declare that HTTPS bindings must conform. Other Bindings MUST define how they conform to the interaction patterns of the PIM.

 

A Profile then defines the Serialization and/or Bindings to create a specific PSM

 

I think this is the path to achieving long-term interoperability and evolvability within this Specification and its derivative Specifcations.

 

I had intended this as an observation for the Public Review, but bring this out now only because it seems a sticking point to release.

 

tc

 

From: openc2@lists.oasis-open.org <openc2@lists.oasis-open.org> On Behalf Of Brule, Joseph M
Sent: Tuesday, October 23, 2018 10:35 AM
To: openc2@lists.oasis-open.org
Subject: Re: [openc2] One item I've noticed on the current CSDs that will need to be fixed

 

All,

 

Sent on behalf of Dave Kemp:

 

===== tear line =====

 

         I do have a question. One of the reasons for the discussion and the "text beats schema" wording is that the schema is not as complete as the text (at least in the Language Spec). In particular there are statements in the text not represented in the schema. If the schema is the "more normative" text, would that mean the additional text constraints do not need to be met?

 

The schema contains the content of the tables in Section 3 of the Language Spec, and those tables are generated mechanically from the schema by a script.  The schema does not have anything to do with text outside of the tables, so it does not supersede or invalidate or conflict with that text.

 

In addition, the table Description column generated from descriptive text in the schema is non-normative, which is one of the reasons comments are stripped from Annexes A and B of the document.  Normative requirements not represented by the syntax appear in the text of the document, not in the syntax table comments.

 

In cases where the text DOES duplicate the schema, e.g. from Section 3.3.1:

         Usage Requirements:

         Each command MUST contain exactly one action.

 

â the table and the schema say that the cardinality of action is 1.   So in the event of a conflict, both the table and the schema are authoritative over any redundant requirements contained in the text.

 

 

         Itâs the automated testing of valid messages that I was worried about. I was worried you could claim passed just on the schema even if it violated a statement in the text. But my reading of your email is in text, not in schema doesnât count as not in schema wins.

Yes.

         If the text conflicts with a table (by attempting to permit something syntactically invalid), the table (and the schema) win.

         If there is no conflict because the text restricts something permitted by the table (and schema), then any normative requirements contained in text apply.

         Text that does not state a normative requirement doesnât affect conformance.