AW: [scripting] management interface

-        Using TDs as manifests sounds reasonable. At the T2TRG meeting we discussed with security experts about the TD having a similar (or more powerful) functionality as MUD (https://tools.ietf.org/html/draft-lear-mud-framework-00): The starting point is that Manufacturer Usage Descriptions describe the intended network activity, so that network operators can now how a device should behave (how to intervene when not is out of scope). This could be added as security metadata to the TD and would nicely describe physical Things, i.e., devices. Same should be possible for virtual Things, i.e., scripts. One issue is that a script can potentially instantiate multiple Things…
Thank you Matthias for the feedback.
We seem to have consensus on this then.

MK: Good :)

-        The management interface should be bound to a Thing managing a Servient. Its specification should come through standardized vocabulary describing the necessary Properties, Actions, and Events. It shall not be specified at the Scripting API level: this one is for the local API within a Thing and contracts with the Resource/Interaction Model from the top; you are talking about a remote API that involves protocols / messages going over the network, which is specified through the TD: Properties, Actions, Events. Furthermore, management features are not central for all types of Things. Thus, it should not be part of the common core. It fits much better to the application space, where features can be added etc. Interoperability is enabled through the standardized management vocabulary.
At the Scripting API level we only have 2 methods: creating a Thing (described by a Thing Description) and modifying a Thing (Description). The Thing contract is described in the TD and in the registered request handlers, actions and event handlers, all of which is in the application space. So I don't see a conflict here. Actually I've been saying the same: instead of a dedicated management API we should use the Thing abstraction to solve the use cases.
MK: But you are defining two functions that carry out network functions that are then outside the narrow waist of Properties, Actions, Events. You indirectly define a Thing through the function signatures. Even if the create() with a remote target and the “RemoteExposedThing” internally build on top Properties, Actions, Events, we blur our narrow waist. Why must this be part of the runtime standard? Where does it stop? We are creating a tight coupling between an orchestrating Thing and a managing Thing. The management interface exported over the network needs to be defined by a TD with a Thing management vocabulary identifying the Properties, Actions, and Events. Defining these function in the Scripting API basically says our model is bull and all we want well defined RPCs. It breaks the overall concept.

The security, in particular access control, can be defined on the Interaction Model. This even allows more flexibility: more complex Servients can use more complex authorization mechanisms.

You can use code modules to be imported if you are worried about writing the code that instantiates a Thing by using Properties, Actions, and Events of a remote Management Thing for every orchestrating application again and again.