11:51:44 RRSAgent has joined #wot 11:51:44 logging to https://www.w3.org/2022/09/06-wot-irc 11:51:54 meeting: WoT Pre-TPAC Meeting - Day 1 11:53:24 present+ Kaz_Ashimura, Michael_McCool 11:56:17 citrullin has joined #wot 12:00:48 Mizushima has joined #wot 12:01:25 present+ Kunihiko_Toumura 12:01:53 ktoumura has joined #wot 12:03:09 citrullin_ has joined #wot 12:03:46 present+ Daniel_Peintner, Michael_Lagally, Tomoaki_Mizushima 12:04:09 Is there a dial-in number in order for me to listen? 12:04:50 McCool has joined #wot 12:04:59 zakim, who is on the call? 12:04:59 Present: Kaz_Ashimura, Michael_McCool, Kunihiko_Toumura, Daniel_Peintner, Michael_Lagally, Tomoaki_Mizushima 12:05:16 mlagally has joined #wot 12:05:35 I am on a conference 12:05:36 dape has joined #wot 12:06:58 agenda: https://www.w3.org/WoT/IG/wiki/F2F_meeting,_September_2022#Tuesday.2C_September_6 12:07:26 present+ Philipp_Blum 12:07:41 topic: Agenda 12:07:45 topic: schedule 12:08:15 -> https://github.com/w3c/wot/blob/main/PRESENTATIONS/2022-09-hybrid-f2f/2022-09-06-WoT-F2F-Opening-McCool.pdf McCool's slides 12:08:19 s/topic: Agenda// 12:08:32 scribenick: mlagally 12:08:39 mmc: today we discuss new charter proposals 12:08:51 ... then Kaz reviews presentation guidelines 12:09:10 ... this is specifically important for accessibility joint call 12:09:49 ... goal is to get some draft text for the next charter 12:10:26 topic: Presentation guidelines 12:10:27 topic: Presentation guidelines (Kaz) 12:10:35 -> https://www.w3.org/2022/Talks/TPAC/hybrid-training/ PLH's slides 12:10:39 s/topic: Presentation guidelines// 12:10:55 s/topic: Presentation guidelines// 12:11:34 kaz: As mentioned previously, for TPAC hybrid meeting has some challenges 12:11:44 ... various people from all over the world 12:12:04 ... need to accommodate the in agenda 12:12:28 ... please be careful about accessibility of your slides 12:13:01 ... there's a speaker in the conference room in Vancouver 12:13:25 ... please review code of conduct and accessibility and internationalisation 12:13:30 ... speak clearly and slowly 12:13:50 ... HTML slide set would be best, PPT is ok 12:14:12 ... check your PPT slides using the accessibility checker 12:15:01 mmc: you mention 10 mins to change the room - we plan for 5 mins, at the end or start? 12:15:18 kaz: end 5 mins earlier, 5 mins past the hour 12:15:26 mmc: any boilerplate? 12:15:45 kaz: Will update the template 12:15:51 https://www.w3.org/Consortium/cepc/ 12:16:13 mmc: we should enable transcripts 12:16:14 q+ 12:17:00 kaz: tooling: we use IRC and zoom for TPAC and pre-meeting 12:17:07 ... GitHub issues and pull requests 12:17:31 q? 12:17:32 .... we could also record session and transcript - should be confirmed in the beginning 12:17:58 ack m 12:17:59 ... please use irc queue 12:18:04 qq+ 12:18:09 q- 12:18:31 ... use present+ 12:18:50 ... if scribe misses sth. he should interrupt and clarify 12:19:33 q? 12:19:34 q? 12:19:52 mmc: scribe should watch the queue, interrupting speaker if necessary 12:20:04 kaz: will help chairs and scribe 12:20:55 present+ Cristiano_Aguzzi 12:20:55 topic: Deliverable proposals 12:21:08 rrsagent, make log public 12:21:12 rrsagent, draft minutes 12:21:12 I have made the request to generate https://www.w3.org/2022/09/06-wot-minutes.html kaz 12:21:23 cris has joined #wot 12:21:40 mmc: there are 3 proposals, some were recently updated 12:22:09 q+ 12:22:15 ... I'll walk through proposals and then check labeled issues in TD 12:22:29 ... today we have an accessibility joint call 12:22:31 i|there are|-> https://github.com/w3c/wot/issues/978 wot issue 978 - Goals and Deliverable Discussion for WoT WG 2023 Proposed Charter| 12:23:07 ... if we do digital twins as a deliverable, do we have to model physical behaviour for a11y? 12:23:15 q? 12:23:19 ack d 12:23:38 dape: is request for TPAC or pre-meeting? 12:24:37 mmc: you want to discuss next deliverables, can we scripting down from 45 mins? 12:24:52 i|978|-> https://github.com/w3c/wot/blob/main/PRESENTATIONS/2022-09-hybrid-f2f/2022-09-06-WoT-F2F-Proposals-McCool.pdf McCool's slides| 12:25:11 ... we could also discuss post-TPAC 12:25:24 s/3 proposals/3 proposals (Discovery, Onboarding, Profiles)/ 12:25:36 dape: I can try to put sth. together for tomorrow 12:27:35 mmc: We have 3 proposals in this area 12:27:49 ... obvious ones are TD 2.0 and Architecture 2.0 12:28:02 ... we should write them up in the next 2 weeks 12:28:14 subtopic: Onboarding 12:28:32 mmc: to do secure communication we need a identity management process 12:29:25 ... separate deliverable or include into another one, e.g. architecture, discovery or a separate security spec 12:29:30 q? 12:29:30 q+ 12:30:31 ml: any estimate on how complex? 12:30:37 ... separate spec needed or not 12:30:48 mm: rather a lifecycle question 12:30:59 Couldn't we refer to it in discovery and then have the details in another document? 12:31:54 q+ Couldn't we refer to it in discovery and then have the details in another document? (can't talk, right now) 12:32:06 mm: (mentions security portions) 12:32:20 ml: we should answer two questions, I think 12:32:28 ... which TF to work on it? 12:32:55 mm: difficult to find people having security expertise 12:33:15 +1 on having it in the task force 12:33:23 ... my preference here is including normative security document and onboarding document 12:33:25 security task force* 12:33:44 ca: agree with having a security tf 12:33:57 ... typically lifecycle discussion needed 12:34:09 cristiano: security TF should be discussing it, this is a lifecycle topic, belongs into architecture 12:34:10 ... also for the scripting topic as well 12:34:33 ... also the case for scripting, we define lifecycle APIs, there are some dependencies 12:34:47 i/any estimate/scribenick: kaz/ 12:34:55 s/... also for the scripting topic as well// 12:35:05 i/security TF should/scribenick: mlagally/ 12:35:08 mmc: lifecycle has more than security, we can focus the security document on security 12:35:23 q? 12:35:25 q? 12:35:26 ack c 12:35:26 ca: agree, after that we can talk with relevant TFs 12:35:33 q? 12:35:46 q+ 12:36:14 kaz: target scope could be kind of broader, lifecycle? 12:36:17 ack k 12:36:39 present+ Ege_Korkan 12:37:10 mmc: I want to consult with security experts, we have onboarding, TLS, provisioning of keys and management 12:37:38 ... lifecycle is more than just provisioning 12:38:08 +1 on having it in the relevant documents and the provisiong in security task force + security documents. 12:38:24 ... details are handled in other documents, architecture has high level requirements 12:38:44 subtopic: Discovery 12:38:56 s/+1 on having it in the relevant documents and the provisiong in security task force + security documents.// 12:39:09 i/Dscovery/citrullin_: +1 on having it in the relevant documents and the provisiong in security task force + security documents./ 12:39:16 mmc: Important topics are integrity protection, this is one of the motivations for a new discovery spec 12:39:21 q? 12:39:40 Ege has joined #wot 12:39:54 ... we also lack a common query mechanism, JSON Path was not ready yet 12:40:12 ... geolocation is another big topic 12:40:13 q+ 12:40:41 ... JSONPath does not include scripting - we can't call a function 12:40:56 q? 12:40:59 ... arbitrary filters could be added 12:41:42 ml: question about geolocation 12:41:44 q- 12:41:52 ... a bit concerned 12:42:12 ... in the past, we had some initial proposal 12:42:26 ... but we failed to included the detail so far 12:42:36 mm: right 12:42:42 ... so there are 2 parts 12:42:43 +1 12:43:04 mm: don't think it belongs to the WoT Profile 12:43:16 ... need to resolve that, though 12:43:30 ... will put together relatively concrete proposal 12:43:40 ... to clarify the complicated situation 12:44:19 q+ 12:44:21 ... there is simply geolocation, e.g., latitude 12:44:50 ... simple geolocation like that within TD can be a good starting point 12:44:54 q+ 12:44:56 ack ml 12:45:48 mm: handle geolocation separately from the current WoT Profile would be better 12:45:56 ml: +1 12:46:01 ... that would make the current spec move smoother 12:46:22 i/question about/scribenick: kaz 12:46:39 s/ml: +1// 12:46:41 ml: +1 12:46:45 ege: There are different ways to do it - there's already existing vocabulary, so we did not want to define a new one 12:47:02 i/There are/scribeninick: mlagally/ 12:47:18 ... the question of a profile is which to pick 12:47:35 q? 12:47:39 ack e 12:48:06 mmc: profile uses schema.org 12:48:35 q? 12:49:06 kaz: for today's discussion and other pre-meeting and post-meeting - what level of details can we cover? 12:49:19 ... or just do a brainstorming? 12:49:36 mmc: want to get feedback on the concrete proposals 12:49:58 kaz: for today and tomorrow suggest we do brainstorming 12:50:23 ... we should use an approach with several steps 12:50:37 ... suggest we do brainstorming offline 12:50:56 scribe+ 12:51:35 ml: as we know from the previous conversations there is some overlap work with the current charter Profile work 12:52:04 ... however there are several other use cases that we should cover in the next work items 12:52:11 q+ 12:52:20 ... like a Cloud Profile 12:52:34 ... events compatible with a cloud deployment 12:52:47 ... a profile for constraint devices 12:52:59 ... or for a specific protocol 12:53:04 q+ 12:53:05 +1 on constrained devices and CoAP :) 12:53:06 ack k 12:53:23 ... we may support other profiles provided that there is interest 12:53:53 mc: it would be nice to have a short description next to the new proposed profiles. 12:54:38 ack mc 12:54:49 ml: behavior description is interesting but it is something for TD 2.0 12:54:57 mc: right 12:55:01 q+ 12:55:42 q+ 12:55:46 ack e 12:55:46 ege: I advice to go directly for 2.0 version for the next profile spec (no backward compatibility) 12:56:08 q+ 12:56:13 q++ 12:56:18 qq+ 12:56:33 ... regarding on the proposed profiles 12:56:42 ... I don't know we have the bandwidth 12:56:58 ack ml 12:57:03 q- + 12:57:04 ls 12:57:07 s/ls// 12:57:29 ml: regarding the backwards compatibility I not completely agree. if we break backward compatibility it means that we are not interoperable with ourselves 12:57:34 ... missing the main goal of profiles 12:57:52 ... we should watch implementers and decide later 12:58:04 ege: later it is a problem 12:58:06 ack m 12:58:10 ack m 12:58:10 mlagally, you wanted to react to Ege 12:58:14 q+ 12:58:24 s/not com/don't com/ 12:58:25 ml: it also depends on TD. If we have TD 2.0 then we have profile 2.0 12:58:50 ege: moreover, profiles can have their own versioning number 12:59:09 ... do you plan to have one single version number or one for each profile 12:59:18 mc: I think this is a long discussion 12:59:25 ... we should talk about it in the issues 13:00:05 kaz: I agree about the importance of interoperability, however as today I am not sure that Profiles are the answer. 13:00:21 q+ 13:00:26 ack k 13:00:37 ack k 13:00:42 +1 kaz 13:00:46 ... paraphs we can use implementation guidelines to ensure interoperability. 13:00:57 ... like HTML5 13:01:07 ack k 13:01:35 mc: I agree with kaz, profiles are not clear to what they are applying for 13:01:39 ... that needs to be resolved 13:02:07 ... the whole versioning problem of profiles is already warning 13:02:45 ack mc 13:02:50 ... cause each individual profile might have a new version that might not be compatible with the previous one 13:03:02 ... I think we should discuss internally in the profile calls 13:03:04 ml: I agree 13:03:35 topic: Other deliverables 13:03:41 subtopic: Thing Description 13:04:00 mc: there are some labels referring issues that are moved to the next version 13:04:25 q? 13:04:26 q+ 13:04:27 ... the TD group needs to choose a subset of imporant issues that should be solved in the next charter. 13:04:28 ack ml 13:04:40 ... there is some action issues that might be migrated to profiles 13:04:50 present+ Janina_Sajka, Matthew_Atkinson 13:05:22 ... in terms of security my personal take is to move those outside the main spec to be more modular 13:05:37 q- 13:05:38 ... we don't have time to go through every single issue 13:05:55 ... we need to get a first draft done during tpac 13:06:01 subtopic: Architecture 13:06:12 mc: I have found only one issue label next 13:06:23 ... I assume the labelling process is yet to be done 13:06:33 ... I think we need probably start the process 13:06:43 ... and pull up the important ones and create the important one 13:06:52 ml: I can review the labels offline 13:06:57 ... for what I see so far 13:07:21 matatk has joined #wot 13:07:24 ... the only relevant issues are identities and onboarding. 13:07:33 q? 13:07:50 mc: we'll need to update the architecture to reflect changes with TD 13:07:54 subtopic: scripting api 13:07:59 mc: we have a call tomorrow 13:08:08 subtopic: accessibility 13:08:15 mc: we have a call right now 13:08:29 subtopic: Informative documents 13:08:48 mc: probably Use cases will need some updates 13:09:10 ... also a new normative document for Security 13:09:33 ml: do these new Security assertions work with TD 1.1 or 2.0 13:09:39 q? 13:09:40 q+ 13:09:47 q+ 13:09:50 mc: I think something will impact older specifications 13:10:56 akc k 13:11:03 kaz: some suggestions. We talked about new additional technical topics, we should start thinking some offloading and focusing on standardization gaps 13:11:28 mc: still there some technical gaps that we need to cover 13:11:46 q? 13:11:47 kaz: My smart city session might be the right place to start the collaboration 13:11:49 ack k 13:11:49 q? 13:11:52 ack k 13:11:53 ack ml 13:12:37 ml: it is true that individual companies are working on proprietary Digitial Twin software. 13:13:08 ... but their implementations are different from open source solutions 13:13:25 q? 13:13:26 ml: ... these are not SDOs however 13:13:30 q? 13:13:35 kaz: @@@ 13:14:04 scribe- 13:14:14 s/@@@/right, but I'd suggest we include "de-facto" kind of vendors as well for our liaison targets :)/ 13:14:30 scribe: dape 13:14:33 s/kaz/scribenick: kaz 13:14:44 TOPIC: APA 13:15:04 rrsagent, draft minutes 13:15:04 I have made the request to generate https://www.w3.org/2022/09/06-wot-minutes.html kaz 13:15:24 janina has joined #wot 13:15:28 present+ 13:15:30 jasonjgw has joined #wot 13:15:36 present+ 13:16:10 scribe: cris 13:17:40 janina: I would start from Jason, we have additional feedback about how a today's consumer would like to interact with products 13:18:41 q+ 13:18:44 jason: I think the question that we arrived was related to the conditions that should be satisfied for WoT devices to be accessibile. 13:19:00 present+ Json_White 13:19:17 ... through his life cycle (starting from the installation) 13:19:42 q? 13:19:45 Mizushima_ has joined #wot 13:20:27 ... what we discussed was the need of some kind of integrated approach for devices installed to some user environments 13:20:53 ... there is no document or requirement analysis 13:21:00 ... that describe the whole process 13:21:28 janina: I will give some examples of bad design choices 13:21:59 ... Philip hue are very well designed 13:22:10 ... but there is the hub that needs to configured 13:22:20 ... google invested a lot in accessibility 13:23:00 ... I had a nest HVAC that got disconnected and I wasn't able to make it reconnect easily. 13:23:46 q+ 13:23:56 q+ 13:23:57 ... another example is Amazon light bulp 13:24:03 ack mc 13:24:12 ... the middleware was not accessible at all 13:24:27 mc: we have use case and requirements document 13:24:35 ... we can your use cases there 13:24:44 ... it will help use guide the requirements 13:25:01 ... the funny thing about the thing you mentioned is the physical interface of the device 13:25:11 ... right now we focused only on the network api 13:25:19 ... more the digital facing side 13:25:47 q? 13:26:10 ... on digital twins discussion we talk about the ability to describe physical consequences of actions in the device 13:26:13 q+ 13:26:49 ... there are various things that we can do for improving user interaction with devices 13:27:01 ... giving the fact that we can provide textual description in TDs 13:27:09 ... do we have the right strings? 13:27:18 ... right now we have title and description 13:27:18 q+ 13:27:34 ... the title is very clear 13:27:40 ... the description is vague 13:27:49 ... is it for developers or users ? 13:27:50 Wouldn't it have been even more easily if you can trigger a reboot via some communication protocol? Wireless or wired, doesn't matter. Just some UI button or something. On the phone or web. And for the battery, of course the battery status, plus description, visually and text, how to change it. Wouldn't that be more like a guideline topic? What do consider when designing WoT devices. 13:28:00 I can't 13:28:36 mc: it is a kind of physical problem 13:28:39 ack cit 13:28:47 janina: I found written descriptions 13:29:08 ... but just fiddling around it I could find it 13:29:09 present+ David_Ezell 13:29:35 qq+ 13:29:55 mc: we have links that can point to documentation 13:30:04 ack mc 13:30:04 McCool, you wanted to react to citrullin_ 13:30:14 kaz: thank you for your feedback 13:30:28 dezell has joined #wot 13:30:30 ... this is a great opportunity to put accessibility on topic for WoT 13:30:38 ... I'd like to discuss more in the next charter 13:30:40 present+ David_Ezell 13:30:53 ... those are just some examples but we should work more on the topic 13:30:58 +1 on collecting accessible topics and maybe having a guideline document for it? 13:31:18 ... how wot can help people to resolve this problem? 13:31:56 ack k 13:32:16 s/to resolve/resolve/ 13:32:35 jason: many settings that are well represented in the hardware control but not on the network interface 13:33:02 ... it is also a matter of how well the human interface is represented in network interface 13:33:39 q? 13:34:11 ack c 13:34:54 q+ to ask about API including reboot 13:35:13 +1 for physical feedback etc. A lot to think about. 13:35:42 q? 13:35:48 ack m 13:36:11 cris: There is a project working on phisical consequences of interacting with digital devices 13:36:21 ... we are having a meeting with them in CG 13:36:21 q+ 13:36:26 q+ 13:36:52 ... also Solidity has keywords for documentation targeted to devs or to end users 13:37:29 janina: we can define dedicated words for different descriptions types 13:38:23 ... for example we defined a set of terms for different use cases 13:38:45 +1 on this. This should all be in the guideline spec. 13:38:47 ack j 13:38:47 janina, you wanted to ask about API including reboot 13:39:07 janina: also defining guidelines can help 13:39:21 mc: I agree that we need a dedicated word for developer documentation 13:39:44 ... another thing is IoT deployment 13:40:06 ... like the minimal functionality guarded when there is no network 13:40:25 ... we can attach additional metadata 13:40:32 ack m 13:40:34 ... but again we should start from use cases 13:40:36 kaz: I agree 13:40:36 ack m 13:40:52 q+ How about profiles for accessibility? 13:40:54 ... I suggest to include some additional topics in to the use case tempalte 13:41:08 q+ 13:41:18 ack k 13:41:29 subtopic: next steps 13:41:38 q- 13:41:38 mc: we talked about use cases 13:41:42 s/use case/use case and requirement/ 13:41:57 ... start from the repo wot-usecases 13:42:20 ... we should plan to have a few rounds of ideas 13:42:34 s/tempalte/templates. Probably we need to think about several layers including UI, network, device, etc., as the basic mechanism for the WoT systems as well./ 13:42:39 q? 13:42:43 ack m 13:43:04 https://github.com/w3c/wot-usecases/tree/main/USE-CASES 13:43:19 https://github.com/w3c/wot-usecases 13:44:06 ml: start from use-case-template.md 13:44:18 https://github.com/w3c/wot-usecases/blob/main/USE-CASES/use-case-template.md 13:44:28 https://github.com/w3c/wot-usecases/blob/main/USE-CASES/use-case-template.html 13:44:42 ... using .html is fine too but md is more convinient; we can convert it later 13:45:02 Examples: https://github.com/w3c/wot-usecases/tree/main/USE-CASES/processed 13:45:36 mc: use cases are published as note 13:45:52