W3C home > Mailing lists > Public > public-wot-wg@w3.org > April 2017

Re: [scripting] management interface

From: Kis, Zoltan <zoltan.kis@intel.com>
Date: Tue, 11 Apr 2017 20:12:28 +0300
Message-ID: <CANrNqUceXMiP3tVc98hJ_jbK+0wZbODQ9H_2J7WH4hkm27iFag@mail.gmail.com>
To: "Kovatsch, Matthias" <matthias.kovatsch@siemens.com>
Cc: "Hund, Johannes" <johannes.hund@siemens.com>, Dave Raggett <dsr@w3.org>, Public Web of Things WG <public-wot-wg@w3.org>
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

Best regards,
Received on Tuesday, 11 April 2017 17:13:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:27:46 UTC