12:00:54 RRSAgent has joined #wot 12:00:59 logging to https://www.w3.org/2023/06/23-wot-irc 12:01:09 meeting: WoT Next Charter Detailed Planning - Day 4 12:02:23 chair: Sebastian/McCool 12:02:53 Mizushima has joined #wot 12:03:23 ktoumura has joined #wot 12:03:47 luca_barbato has joined #wot 12:04:30 present+ Kaz_Ashimura, Sebastian_Kaebisch, Michael_McCool, Ege_Korkan, Kunihiko_Toumura, Luca_Barbato, Michael_Koster, Tomoaki_Mizushima 12:05:36 mjk has joined #wot 12:06:33 agenda: https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf/2023_WoT_Next_Charter_Detailed_Planning 12:06:49 Ege has joined #wot 12:07:24 scribenick: Ege 12:07:29 topic: Agenda 12:07:44 -> https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf/2023_WoT_Next_Charter_Detailed_Planning#Day_4:_June_23.2C_2023 agenda for today 12:07:47 sk: we will start with profile discussion 12:08:48 topic: Architecture Planning 12:09:14 https://github.com/w3c/wot/pull/1096 12:09:53 mm: we have to discuss about arch spec being informative or normative 12:09:53 s|https://github.com/w3c/wot/pull/1096|-> https://github.com/w3c/wot/pull/1096 wot PR 1096 - Architecture Planning| 12:10:17 mm: we have to decide what to do with the current normative content 12:10:35 rrsagent, make log public 12:10:37 rrsagent, draft minutes 12:10:38 I have made the request to generate https://www.w3.org/2023/06/23-wot-minutes.html kaz 12:10:45 ... also we have to decide what the purpose is 12:11:19 ... I have listed what it does 12:11:31 ... half of the current assertions are about security 12:11:32 q+ 12:11:33 q+ 12:12:38 mm: do we have assertions for the whole WoT? 12:13:07 mm: maybe those assertions are actually requirements so we can restructure like that 12:14:23 q+ 12:14:26 sk: my experience is that arch document is not implemented by developers, so the restrictions do not apply to them, since they are not aware 12:14:26 ack s 12:15:41 q? 12:16:16 q+ 12:16:27 sk: REC implies W3C process, overhead in general 12:16:48 mm: we have lots of deliverables, each imply work. We can consolidate but not lose information 12:17:28 ack e 12:17:31 https://github.com/w3c/wot-charter-drafts/issues/15 12:17:34 https://github.com/w3c/wot-charter-drafts/pull/85 12:17:37 https://github.com/w3c/wot-charter-drafts/pull/82 12:18:57 s|https://github.com/w3c/wot-charter-drafts/issues/15|-> https://github.com/w3c/wot-charter-drafts/issues/15 wot-charter-drafts issue 15 - Arch: Architecture Brainstorming| 12:19:03 q? 12:19:57 ek: people are showing to management to explain wot. developers do not read the normative part 12:20:37 s|https://github.com/w3c/wot-charter-drafts/pull/85|-> https://github.com/w3c/wot-charter-drafts/pull/85 wot-charter-drafts PR 85 - Add Architecture as an informative deliverable| 12:20:42 kaz: We said it is a normative deliverable in charter. we can refactor it and move content, that way it would be justifiable to make it informative 12:21:46 mm: we can work towards informative and do the transition when it is doable 12:21:54 s|https://github.com/w3c/wot-charter-drafts/pull/82|-> https://github.com/w3c/wot-charter-drafts/pull/82 wot-charter-drafts PR 82 - Add Architecture as a normative deliverable| 12:22:19 s/in charter/in the proposed WoT WG Charter/ 12:22:28 s/it is a/it would be a/ 12:22:31 mm: the document should not go away, the introduction to wot is useful 12:22:42 q+ 12:22:51 ack k 12:23:45 https://github.com/w3ctag/design-reviews/issues/736#issuecomment-1162135635 is the link to tag review saying it should be informative 12:23:54 lb: I support non normative 12:24:01 s/we can refactor it and move content, that way it would be justifiable to make it informative/We should work on the document refactoring for the whole WoT specs, and as a result, if there are only informative portions within the WoT Architecture spec, that would automatically become an informative spec./ 12:24:19 https://www.w3.org/WoT/documentation/ 12:25:24 ek: we have also introductory part in the web page, which is the most popular page after landing 12:26:19 mm: a formal looking explainer is nicer than a webpage but I will add to discussion 12:27:00 mm: we have requirements that sometimes apply to multiple documents so we need to duplicate that maybe 12:28:06 mm: should we move application domains to use cases? 12:28:12 q+ 12:28:14 ack l 12:29:26 ack e 12:29:45 q+ 12:30:59 ek: arch application cases show an agreement. use cases document are individual submissions 12:31:26 kaz: we had discussions in that direction about restructuring use cases. So let's continue in use cases 12:32:12 s/So let's continue in use cases/So the details to be discussed collaboratively with the Use Cases TF./ 12:32:30 ack k 12:33:45 mm: let's look at the assertions and normative content 12:35:03 mm: we cannot constrain brownfield systems, we only describe them 12:35:16 ... so all the normative assertions can go to a profile 12:35:23 q+ 12:36:16 q| 12:36:20 s/q|// 12:36:22 q+ 12:36:41 mm: we also have discussions on TDDs having profiles 12:37:44 q+ 12:38:56 ack e 12:39:32 mm: i think profiles is the best direction 12:40:11 ek: I think that security assertions should be best practices 12:40:38 ... moving to a profile would have problems with protocol dependency 12:41:12 mm: I think that security should be normative 12:41:36 mm: we can have baseline security and add protocol specific assertion to profiles with those protocols 12:42:49 kaz: we have discuss which we need and move the ones that we really need 12:43:05 +1 kaz 12:44:46 kaz: the profile spec is a bit odd so I am not sure about adding to profiles 12:45:41 lb: profiles are important if you want to interoperate with devices with different physical constraints 12:46:22 ... we are lacking there completely. Security is important since they require different resources 12:47:00 s/the profile spec is a bit odd so I am not sure about adding to profiles/The name of "WoT Profile" is still a bit odd to me but it does describe possible implementation patterns for WoT-based IoT services. So it's possible to transfer the security portions to WoT Profile. However, it's not that "WoT Profile is the default place for the transfer." and we should think about which spec to have the feature./ 12:47:02 lb: about image, we can put a section about expectations of a system that should be secure 12:47:19 q 12:47:24 q- 12:47:28 ack l 12:47:28 q+ 12:47:33 q+ 12:48:07 s/we have discuss which we need and move the ones that we really need/We should have discussion about which security features are really needed first, and then think about which spec to have that./ 12:48:14 rrsagent, draft minutes 12:48:15 I have made the request to generate https://www.w3.org/2023/06/23-wot-minutes.html kaz 12:48:54 lb: you are implementing wot, so you are signing up for the safety of the user 12:48:56 s/possible/possible and natural/ 12:50:05 mm: there are optional features for PII sensitive points 12:50:29 q+ 12:50:39 q- 12:51:16 q+ 12:51:22 ack e 12:51:52 ek: we can understand some security for TD instances 12:52:08 q? 12:52:18 ack s 12:52:44 q- 12:52:45 mm: not always. some assertion from TD can go into other specs 12:52:52 sk: we have to discuss who will lead the TF 12:53:18 sk: mccool did it interim 12:53:28 mm: I think the motivation is to reduce the document size 12:55:01 mm: I think we should find somebody but I can do it until then 12:55:05 mm: same for security 12:55:44 mm: I can chair and do another TF 12:55:46 q+ 12:55:54 q+ 12:56:27 ack s 12:56:45 sk: Jiye is not active at the moment 12:57:29 ... I am looking for another person 12:57:51 mm: we need someone for reviewing the documents, an expert. And another person to moderate 12:58:01 kaz: we can send a call for participatino 12:58:24 mm: we have to have a discussion on finding TF leads as chairs 12:58:31 s/patino/pation/ 12:58:45 s/as chairs/during the Chairs calls/ 12:59:09 topic: Security Planning 12:59:31 mm: signing JSON LD is complicated 12:59:43 ... it can blow up in some cases 12:59:51 s/JSON LD/JSON-LD/ 13:00:35 mm: we would to need to decide whether TDs can be modified by directories or not 13:01:06 mm: we have the topic about fixed prefixes for pure JSON processors 13:01:09 i|signing|-> https://github.com/w3c/wot/pull/1097 wot PR 1097 - Security Planning| 13:01:09 q+ 13:01:12 ack k 13:01:15 https://github.com/w3c/wot-thing-description/issues/1774 13:01:19 rrsagent, draft minutes 13:01:21 I have made the request to generate https://www.w3.org/2023/06/23-wot-minutes.html kaz 13:02:54 mm: we have to discuss onboarding as well 13:04:06 s|https://github.com/w3c/wot-thing-description/issues/1774|-> https://github.com/w3c/wot-thing-description/issues/1774 wot-thing-description Issue 1774 - Not changing prefix of ontologies we suggest| 13:04:22 q+ 13:04:59 ack e 13:05:00 q+ 13:06:24 q+ 13:06:25 ek: I can share some work on security extensions and I have put an issue above about prefixes 13:06:57 ... I think onboarding needs its own deliverable since it is not just about key exchange or security. It should be the lifecycle 13:07:23 ack l 13:08:02 lb: I think it is a usage of wot, should not be a normative spec or constrain wot applications 13:08:16 ... regarding json ld, we can do it in profile and be strict 13:08:52 s/json ld/JSON-LD/ 13:09:51 mm: json ld signing is for arbitrary graphs 13:10:24 lb: we have tried to json ld for everything like extensions 13:10:40 s/json ld/JSON-LD/ 13:10:41 s/json ld/JSON-LD/ 13:10:43 ... it is great for non functional extensions, so it would be bad to restrict it 13:11:49 q? 13:12:06 lb: degraded consumption would be an interesting topic 13:13:16 ack k 13:13:42 kaz: let's talk about this with JSON-LD people at TPAC 13:14:00 sk: we can talk about onboarding with OPC UA WoT Connectivity WG since they need this too 13:14:40 s/let's talk about this with JSON-LD people at TPAC/this is a bigger discussion for today, so would suggest we talk with the JSON-LD/VC/DID guys during TPAC since they're also working on this issue./ 13:14:48 rrsagent, draft minutes 13:14:49 I have made the request to generate https://www.w3.org/2023/06/23-wot-minutes.html kaz 13:15:11 q+ 13:15:12 ack s 13:15:20 ack s 13:16:27 scribenick mjk 13:16:42 topic: profiles 13:17:51 bf: presenting slides on profiles 13:17:56 i|pre|-> slides TBD @@@| 13:18:24 q+ 13:19:20 ack e 13:22:02 bf: option 1 proposal is to handle protocol bindings defaults as required in a profile 13:22:07 q+ 13:22:40 q+ 13:23:19 ... option 2 proposal is to continue to define protocol bindings for profile separately from the standalone protocol bindings 13:23:37 q+ 13:24:10 ack m 13:24:15 mm: how much testing work is needed? 13:24:40 q+ 13:24:46 bf: there are not enough implementations yet 13:25:13 mm: there may not be a lot of effort lost in reorganizing things now 13:25:48 mm: are profiles only constraints on TDs or are there also constraints on behavior 13:26:08 s/behavior/behavior?/ 13:26:39 bf: option 2 would mean publishing profiles 1.0 13:27:48 bf: with option 1 we would constrain supported mechanisms and be more specific about the types of assertions that can be in the profile 13:27:56 q? 13:28:09 mm: should security assertions be part of a profile? 13:28:57 bf: prefer that security assertions be in a security best practices document and leave profile assertions to be more cleanly testable 13:29:36 (ben's feedbackl: would rather assertions on implementations should be in a guideline document, not in profile, make testing difficult) 13:29:50 kaz: this should be part of the overall restructuring project so we can see the whole structure across all documents 13:29:54 ack k 13:31:31 s/feedbackl/feedback/ 13:31:46 sk: assume that profiles will include a basic mechanism and generic definition, and a set of specific profile documents that conform to the generic description 13:32:43 ... for example a manufacturing domain profile that works more or less like a protocol binding document 13:32:45 i/assume/bf: agree/ 13:32:55 i/agree/scribenick: kaz/ 13:33:02 i/assume/scribenick: mjk/ 13:33:20 q+ 13:33:27 ack s 13:33:34 q+ 13:33:51 bf: we originally thought of profiles as a protocol constraint like a sub-protocol 13:35:23 sk: do we have enough members interested to make profiles happen? 13:36:21 bf: last 6 months has been spent implementing TD 1.0 with particular profiles but not completely attached to the profile approach 13:36:37 ... could use another mechanism like subprotocols 13:37:00 ege: leaning more toward option 1 to provide a clearly defined mechanism 13:37:15 ... with subprotocols also 13:37:50 .... subprotocols may not be W3C work 13:38:04 ack e 13:38:06 ack l 13:38:37 luca: would like to see the concept of profiles extended beyond protocol usage 13:38:54 ... the use as a mixin solves a lot of problems 13:39:37 ... we could reconsider in next TD how we handle protocol selection 13:40:17 ... regarding SSE, have an implementation that reduces the risk 13:40:36 ... would keep profiles because it solves a lot of problems 13:41:01 sk: can you (luca) be involved in the profile activity? 13:41:07 luca: yes 13:41:32 miz: agree with the direction but profile is different from a binding 13:41:42 ack m 13:41:42 ... we should discuss what a profile is 13:42:11 bf: agree, profile is not the same as a binding but more of a constraint 13:42:27 q? 13:42:27 https://github.com/sifis-home/wot-test -> test-consumer for SSE 13:42:34 ... a profile is a constraint to guarantee interoperability 13:43:06 kaz: suggest we continue this discussion as part of the larger document refactoring issue 13:43:28 ... we should send out a call for participation for profies 13:43:33 q? 13:43:34 ack k 13:44:55 sk: should profiles be rec track or moved to a note? 13:45:43 For the notes: Protocol binding is just one aspect of a Thing that a profile can constrain. Others are payload binding, discovery mechanisms, security mechanisms, semantic ontologies, link relation types etc. 13:45:57 ... we need to think about the best way to proceed 13:46:27 topic: new working mode for the next charter 13:46:44 i|we need|(Ben's clarification above to be moved right after "more of a constraint")@@@| 13:47:26 sk: we have too many calls 13:48:03 ... would like to optimize the calendar and reduce the load of calls 13:48:47 ... also need to consider the time zone considerations, particularly for the TD call and participants in Asia 13:49:49 ... maybe we shouldn't work on multiple deliverables in parallel 13:50:25 ... reduce the frequency of note workstreams to 2 week interval 13:50:58 ... use more async process and use meetings to report and summarize 13:51:16 ... prepare the agenda for calls one day in advance 13:51:49 ... suggest a goal of 4 calls per week maximum 13:51:57 q+ 13:51:59 q+ 13:52:25 ack m 13:52:29 mm: does 4 calls per week include the main call, and can we have the main call every 2 weeks? 13:53:04 sk: sometimes we may need more frequent calls during preparation for publication 13:53:12 q+ 13:53:19 mm: we could have shorter calls 13:54:21 kaz: would personally welcome fewer calls, but simply reducing the load should include a discussion of how to make each call more productive 13:54:46 sk: removing PR review from the calls could help 13:55:35 kaz: it's difficult for all participants to follow and understand the points of the PR discussions 13:55:40 q+ 13:55:51 ack k 13:56:16 sk: we could share the detailed agenda and ask for discussion before the call 13:56:43 kaz: that may not work for all participants, but we could try for a month or 2 13:57:25 ege: agree with the overall idea and async process, the TF moderator can make the decision about whether more calls are needed 13:57:40 q+ 13:57:46 ack e 13:57:51 ... would like the main call to have more report out and sync between TFs 13:58:07 q+ 13:58:13 ack mc 13:58:16 ... maybe alternate TF reports every 2 weeks 13:58:33 bf: supports fewer calls and more async collaboration 13:58:43 q+ 13:58:46 ... we do need to work on some items in parallel 13:59:04 ... wonder if minutes approval can be done outside the meeting 13:59:06 ack b 13:59:31 (time check) 13:59:48 kaz: Ok wit this direction but we need some prototyping 14:00:15 ... TF moderators will need to coordinate more to clarify what is done and what is needed 14:00:24 ... suggest a TF moderator call 14:00:43 sk: agree and we should prototype this also 14:01:03 s/Ok wit this direction/OK with this direction if everybody is OK,/ 14:01:17 s/TF mod/Also TF mod/ 14:01:40 rrsagent, draft minutes 14:01:41 I have made the request to generate https://www.w3.org/2023/06/23-wot-minutes.html kaz 14:01:57 ack k 14:02:00 miz: agree with the direction of the proposal. We should separate WG and IG meetings. 14:02:01 ack m 14:02:16 q+ 14:02:30 ... I'm confused 14:02:58 ack k 14:03:11 kaz: we should further clarify the difference between WG and IG responsibilities 14:03:26 sk: let's have further discussion on this proposal 14:03:52 kaz: agree 14:04:32 sk: this concludes the week's meeting, we can discuss among the chairs and propose next steps 14:04:59 sk: thank you and adjourned for today 14:05:21 present+ Ben_Francis 14:05:23 [adjourned] 14:05:27 rrsagent, draft minutes 14:05:29 I have made the request to generate https://www.w3.org/2023/06/23-wot-minutes.html kaz 16:08:14 Zakim has left #wot