- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 24 May 2021 18:13:17 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2021/05/03-wot-script-minutes.html
also as text below.
Thanks,
Kazuyuki
---
[1]W3C
[1] https://www.w3.org/
WoT Scripting API
03 May 2021
[2]Agenda. [3]IRC log.
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Scripting_API_WebConf#3_May_2021
[3] https://www.w3.org/2021/05/03-wot-script-irc
Attendees
Present
Cristiano_Aguzzi, Daniel_Peintner, Kaz_Ashimura,
Tomoaki_Mizushima, Zoltan_Kis
Regrets
-
Chair
Daniel
Scribe
kaz
Contents
1. [4]Minutes
2. [5]Joint calls
1. [6]Security
2. [7]Discovery
3. [8]TD
Meeting minutes
Minutes
<dape> [9]minutes 19 april, see
[9] https://www.w3.org/2021/04/19-wot-script-minutes.html
Daniel: the call after the vF2F
… (goes through the minutes)
… we'll postpone the publication
… topics related to discovery
… issues related to TD, discovery and security
… requirements on the (possible) management api
… any objections?
(none; approved)
<dape> [10]minutes 26 April 2021,
[10] https://www.w3.org/2021/04/26-wot-script-minutes.html
Daniel: joint discussion with the Security TF
… we need some kind of management api to handle security
… any objections?
(none; approved)
Joint calls
Security
[11]Issue 315 - Security TaskForce related issues
[11] https://github.com/w3c/wot-scripting-api/issues/315
Cristiano: well summarized
Daniel: any other comments? fine?
Zoltan: need to create some deliverable on runtime
… different from the script api itself
Kaz: implementation guideline, you mean?
Zoltan: a bit different
Daniel: we could have some kind of management api. right?
Zoltan: might need a different mode
… what is defined by the current Scripting API is definition
for client APIs
Kaz: in that case, a separate document on the possible
management API?
Zoltan: a document about runtime of Scripting API
Kaz: not really sure about the difference between an
"implementation guideline" and a "runtime document"
… but if we're ok with generating an informative WG Note about
that, that's possible
… if we want to generate a separate group Note about some
topics, we should summarize what to be described by that
document and bring the idea to the main call to get a group
resolution
Zoltan: ok
Daniel: ok
… but still not really sure about what to be done there
… would like to get consensus within this Scripting API first
Cristiano: don't have any strong opinion at the moment.
… different information could be included under one specific
repository
Daniel: how to proceed?
Kaz: we should clarify what we want to document first :)
<zkis> [12]https://github.com/w3c/wot-scripting-api/issues/
299#issuecomment-826823233
[12] https://github.com/w3c/wot-scripting-api/issues/299#issuecomment-826823233
Zoltan: we can skim the issues listed here (=within the issue
315)
(issue 299 and 298 are included in issue 315)
[13]Issue 299 - Chose a particular security schema for an
ExposedThing
[13] https://github.com/w3c/wot-scripting-api/issues/299
Daniel: we need to be careful about the API names
Zoltan: we can control the device remotely
Daniel: there is an MD file about our basic ideas
Zoltan: we should split the manager API topic from the
Scripting API itself
… so we should move the content of "script-manger" area to
another repository
[14]script-manager area under wot-scripting-api repo
[14] https://github.com/w3c/wot-scripting-api/tree/main/applications/script-manager
Zoltan: we need a separate namespace from the consumer
discovery
… it requires a different level of permission
Daniel: the developer should have method to control it
… even though that is not the case with the node-wot
implementation at the moment
Kaz: sorry but I still don't really understand your
expectations...
… so would suggest you both clarify your expected features,
phases, APIs, etc., first
… and then we can think about how to deal with those points by
what kind of documents
Cristiano: exposedThing is almost a system-level API
… for system-level implementations, what is needed to be
implemented?
[15]Cristiano's comment on Issue 299
[15] https://github.com/w3c/wot-scripting-api/issues/299#issuecomment-826823233
Daniel: this happens for exposedThing
Zoltan: we can take this forward but what security portion to
be implemented?
… exposedThing has to be created
… and what to be provided by the runtime?
Cristiano: currently we don't do any validations
Zoltan: cat it include any kind of security specifications?
… wondering about what would be a better API definition
Daniel: we have a "wot" namespace already
… but what would be included in the runtime?
Zoltan: wot.runtime should have a different permission from
wot.consume
… 3 different levels for consume, discover and expose
Cristiano: maybe we need those three levels
Daniel: wonder how to differentiate them
Zoltan: we can create a new runtime object for WoT
… but with a different permission level
… we have consume, expose and discover
… and what else?
… we can continue the discussion
Kaz: those three are rather different phases. right?
Zoltan: we use "phase" for provisioning, etc.
Kaz: in that case, maybe three different modes
Zoltan: need to continue the discussion
Discovery
Daniel: will we have a joint discussion with the Discovery TF
today?
<cris> [16]wot-thing-description Issue 1097 - Provide
Typescript types definitions for Thing Descriptions
[16] https://github.com/w3c/wot-thing-description/issues/1097
Zoltan: can be checked with McCool during the Security call
TD
Daniel: some description on the wot-scripting-api repo
[17]Daniel's writeup
[17] https://github.com/w3c/wot-scripting-api/blob/main/typescript/index.d.ts
[adjourned]
Minutes manually created (not a transcript), formatted by
[18]scribe.perl version 131 (Sat Apr 24 15:23:43 2021 UTC).
[18] https://w3c.github.io/scribe2/scribedoc.html
Received on Monday, 24 May 2021 09:13:22 UTC