Re: [scripting] management interface

On Tue, Apr 11, 2017 at 7:01 PM, Kovatsch, Matthias <
matthias.kovatsch@siemens.com> wrote:

> Hi all
>
>
>
> -        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.

> -        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.

See an explanation in the rationale doc (currently in PR#21):
https://github.com/zolkis/wot-scripting-api/blob/master/rationale.md, more
exactly in
https://github.com/zolkis/wot-scripting-api/blob/master/rationale.md#wot-runtime-applications-scripts-things

Best regards,
Zoltan