14:02:14 RRSAgent has joined #wot-td 14:02:18 logging to https://www.w3.org/2024/07/10-wot-td-irc 14:02:21 meeting: WoT-WG - TD-TF 14:02:28 s/TD-TF/TD TF - Slot 1 14:03:32 present+ Kaz_Ashimura, Mahda_Noura, Ege_Korkan, Jan_Romann, Kunihiko_Toumura, Tomoaki_Mizushima 14:04:00 present+ Michael_Koster 14:04:20 present+ Luca_Barbato 14:04:22 luca_barbato has joined #wot-td 14:04:43 mjk has joined #wot-td 14:06:04 scribenick: JKRhb 14:06:09 topic: Agenda Review 14:06:31 ek: Today, we will mostly talk about the plugfest and then get to initial connection 14:06:34 mahda has joined #wot-td 14:06:37 ... tomorrow will be more about bindings 14:06:49 topic: Minutes Review 14:06:52 present+ Mahda_Noura 14:06:55 ek: Had a look on it before the meeting, looked good to me 14:07:10 ... I will go through really quickly, let me know if you spot something wrong 14:07:14 ... any remarks? 14:07:23 None, minutes are approved 14:07:39 ek: Thank you, Cristiano, for taking the minutes last week! 14:07:44 topic: Plugfest 14:07:57 ek: Points were collected in the wiki so far 14:08:12 ... as we agreed last week, we know moved them to the wot repository on GitHub 14:08:15 i|Had a look|-> https://www.w3.org/2024/07/04-wot-td-minutes.html July 4| 14:08:38 ... this is more like a technical document, logistics will remain in the wiki 14:08:41 q+ 14:08:51 ... I also expanded the text a bit on the user scenarios 14:08:57 q- 14:08:59 s/wot /wot-testing/ 14:09:05 cris has joined #wot-td 14:09:15 s/wot-testing/wot-testing / 14:09:27 rrsagent, make log public 14:09:31 rrsagent, draft minutes 14:09:32 I have made the request to generate https://www.w3.org/2024/07/10-wot-td-minutes.html kaz 14:09:39 ... we also added some explanation on what we mean with user scenarios 14:09:43 ... to help users understand them in context 14:10:04 ... this is sort of the user-facing part of it, the internal aspects are listed under TD Topics 14:10:29 ... first point is existing features, where we want to make sure that features can actually be used 14:10:35 ... the other aspect is new features 14:10:49 chair: Ege 14:11:01 ... there are also other topics, which are currently mostly discovery and scripting API related 14:11:11 i|Points were|-> https://github.com/w3c/wot-testing/tree/main/events/2024.11.Munich wot-testng/events/2024.11.Munich 14:11:17 ... moved them to other topics for now, but we can categorize them further later 14:11:27 ... does anyone else have topics here? 14:11:32 No one speaks up 14:11:35 q+ 14:11:53 ek: Then we need to clarify and further categorize the topics here 14:12:27 kaz: Categorizing and clarifying is fine, but I was wondering if we want to invite stakeholders/implementors as well 14:12:45 ... for example, from the Smart City domain, maybe also companies from Germany 14:13:13 ek: I think we can allocate the space for them, but they would need to bring their own setup 14:13:29 kaz: Maybe at some point we need to add expected participants to each section 14:13:38 ack k 14:13:41 ek: For me, these were so far TF oriented 14:13:55 ... should maybe rather discuss this in the Plugfest call 14:14:20 ek: Regarding existing features, we should prioritize the features where we have doubts 14:14:29 q+ 14:14:38 ... also should link them to potential new features, like data mapping and additional responses 14:15:13 ... other aspects like interoperatibility or degraded consumption are also related 14:15:38 ... before discussing new meta operations, we should also consolidate and discuss the existing ones 14:16:03 ... otherwise, initial connection should be trivial, will also discuss it today 14:16:35 q? 14:16:35 ... for data mapping, there are probably many corner cases, should collect them and gather as much information and experience as possible 14:16:50 ... while documenting the existing features as good as possible 14:16:58 kaz: Agree with the general direction 14:18:20 ... maybe you want to add some note regarding the main purpose of this plugest, for example that it will mainly focus on the feasibility of existing and new features within the group and that external stakeholders can contribute 14:18:30 s/you want to/we might want to/ 14:18:46 q? 14:18:47 q- 14:18:57 ek: (adds a note to the top of the document) 14:19:16 ... another aspect we can mention is setups 14:19:33 ... of the WG/IG as well as external ones 14:19:41 ... (amends the note) 14:19:51 s/note/document/ 14:20:19 q? 14:20:22 rrsagent, draft minutes 14:20:23 I have made the request to generate https://www.w3.org/2024/07/10-wot-td-minutes.html kaz 14:20:29 ... for now I will just add this, but we should continue the discussion in the Plugfest call and get it done there 14:20:39 present+ Cristiano_Aguzzi 14:20:43 rrsagent, draft minutes 14:20:44 I have made the request to generate https://www.w3.org/2024/07/10-wot-td-minutes.html kaz 14:20:51 ... (adds a note to the document that the data mapping topic will be prioritized) 14:21:00 mn: What is actually meant by data mapping? 14:21:07 ek: Let me find the work item for that 14:21:57 ... is related to potentially having fields within a data schema that could be expected to be contained in HTTP headers or Modbus registers 14:22:41 ... (adds a link to the work item in the wot repository) 14:23:32 ... (adds a note that meta operations as an existing features will also be prioritized during the meeting) 14:23:56 ... (adds another note that existing features will be prioritized over new features in general) 14:24:25 ek: For those who weren't in the main call: In two weeks we will restart the Plugfest call 30 minutes after the TD call 14:24:35 ... to discuss setups etc. 14:24:45 topic: Toolchain Discussion 14:25:01 ek: Before the TD call, Mahda, Luca, and I met to discuss the toolchain 14:25:42 ... we are already seeing some issues with the JSON-LD context, which we could identify during the discussion, so that was already quite helpful 14:26:08 mn: @@@ 14:26:29 q+ 14:26:42 ek: Before, it was not possible to model "string or array of string", but Mahda was able to fix it via the documentation of LinkML 14:26:54 ek: We also had a review from a new member 14:27:08 mn: I think he is from the JSON-LD working group 14:27:25 ek: Seems to very interested in WoT in general, was also active in the CG 14:27:50 ca: It is good that the string or array string feature is now possible, but we were discussing to remove it. 14:28:09 ek: I also think we should remove the feature, but we need to keep in some places, such as @type 14:28:46 ... maybe we should do more of a survey before removing the feature, but in general I think we should stick to the array solution 14:29:08 ca: Will probably also not really break implementations, since it would only affect the TD designers 14:29:22 topic: Initial Connection Container 14:29:35 ek: For this I would like to get some input before the holiday season 14:29:50 ... as I think it is not that difficult and should be quick to do 14:30:24 ... we have a section in the work items document, have listed some requirements 14:30:38 ... we agreed to sketch how the message flows will look like 14:30:43 ... have created an issue for that 14:30:55 ... we agreed on using draw.io for that 14:31:19 ... we have created a few first versions, look better now although still technical diagrams 14:31:49 ... I followed Luca's design with my approach for modelling HTTP message exchange 14:32:06 ... for MQTT will a broker connection it's getting a bit more complicated 14:32:27 ... also illustrates that Thing and Consumer are both clients 14:33:04 i|For this I would|-> https://github.com/w3c/wot-thing-description/issues/2025 Issue 2025 - Extending the initial/reusable connection examples| 14:33:10 rrsagent, draft minutes 14:33:12 I have made the request to generate https://www.w3.org/2024/07/10-wot-td-minutes.html kaz 14:33:18 ... the sequence diagram in the issue illustrates how the message exchange is happening, will add how the connection is going to kept alive, will add it as another rectangle 14:33:32 ... that is the current status how it looks like and how we are using existing connections 14:33:53 ... explains the main points, can maybe add a bit more text later 14:34:27 ... Luca has added his part, Cristiano, I think you need to still provide you diagram on WebSockets 14:34:34 ca: OAuth is also still missing, did not really have the time yet 14:34:39 q+ 14:34:41 q+ 14:34:42 q+ 14:34:46 ack cr 14:34:48 q+ 14:34:52 ek: Any opinions? The colors might be a bit messy at the moment 14:35:04 mn: Thanks a lot for the effort you put in the diagrams 14:35:32 ... for HTTP, for example, we might need another entity like the connection that shows how the messages are passed and that the connection persists 14:35:43 ... because I think that is not really clear at the moment 14:35:58 ek: That is actually covered by that yellow rectangle 14:36:18 mn: Maybe you could illustrate that better with another rectangle for the connection itself 14:36:53 ... you could also cover the creation of the connection itself with separate messages 14:37:14 rrsagent, draft minutes 14:37:15 I have made the request to generate https://www.w3.org/2024/07/10-wot-td-minutes.html kaz 14:37:24 ek: Actually, the connection is reused on a lower level, but that is not happening at the application level 14:38:33 q+ 14:38:46 ... so you would reuse the connection with regard to the ports, but when it comes to the broker there is a persistent connection, so I am not really sure how to differentiate the two 14:40:13 kaz: Thank you very much for continuing to work on this topic, as we are getting a much clearer view on the issue. However, I was wondering what kind of existing data would be stored within each entity and which part of the data could reused or removed complete, so from a security or privacy viewpoint, data should be removed, and that policy should be applied to the broker and the connection in general 14:40:19 ek: Depends on the connection I think 14:40:32 ... sensor data, for example, is not that privacy-critical 14:40:48 kaz: That's why I was asking which part of the data should be removed 14:41:29 q+ 14:41:33 ek: That is actually a difficult question, so at the HTTP-level, there is nothing removed, but in MQTT you have a different kind of connection that would be reused 14:41:36 s|removed|kept or removed| 14:41:38 ack ma 14:41:40 ack ka 14:42:50 ca: I think the difference between the cases is that in MQTT you have a connection with a broker and then you are subscribed and wait for events from the subscription 14:43:06 ... the interaction is completely different than in HTTP 14:43:41 ... node-wot, for example, illustrates that you can also have one-shot interactions, but this is not that efficient from a pub-sub point of view 14:44:07 ... so what we need to illustrate here is the difference between a request-response pattern and a pub-sub pattern 14:44:47 ... that might things a bit clearer, as it would illustrate that with HTTP, you open and close the connection, but with MQTT the runtime would magically keep the connection open for you 14:44:52 ack cr 14:45:09 ek: For me things are clear, but I am wondering how to illustrate that in the diagram 14:45:22 ... because even with HTTP, you reuse the connection 14:45:48 ... for example, there is only one DNS request 14:46:05 ca: But you close the socket after the request is finished 14:46:14 ek: But you can also keep the connection alive 14:46:36 ca: This might be seen as an optimization for HTTP, but for MQTT it is the default 14:46:59 ... in HTTP, you would "throw away" the connection, as the HTTP servers are built that way 14:47:18 ... while in MQTT, experts would ask "Why are you closing the connection"? 14:47:35 ek: Maybe we could add a time component to the diagrams to illustrate that 14:48:22 ... to show, for example, that the MQTT connection will be kept open for five minutes, while the HTTP connection will be reestablished 14:48:34 ... maybe we can also add some code to illustrate that 14:48:46 ... that between two lines, the connection is reused 14:49:02 ek: So Mahda, I think this was your first point? 14:49:24 mn: The first point was that we could explicitly show the connection in the diagrams 14:49:55 ... the second point is that the HTTP server is currently assumed to be the same entity as the Thing. Would it make sense to separate these two? 14:50:11 ek: In MQTT, the broker is not part of the Thing 14:50:28 mn: But the HTTP server could also be running on another edge device 14:51:06 ek: In these examples, we are assuming that the devices are powerful enough to run their own HTTP server, so this is probably important to mention here as well 14:51:27 ek: (adds a comment that summarizes the discussion so far) 14:51:53 ... right, so then I guess I would adapt this diagram 14:52:05 ... but I think the situation is clear for everyone? 14:52:27 ... so what I was thinking was that before the holiday season we could look into some initial designs 14:52:56 ... (looks for an issue with some initial examples) 14:53:47 ... (finds the examples in issue 878 of the TD repository) 14:54:18 ... so in this example, we were discussing that we could have multiple "bases" which we could refer to then in the forms 14:54:28 ... then in the issue we had some discussion on that 14:54:38 https://github.com/w3c/wot-thing-description/issues/878#issuecomment-879794045 14:54:50 ... I want to get to work on this to get some additional input here 14:55:13 ... for next week I would then present the current proposals that we came up with so far 14:55:13 q+ 14:55:26 ... and then we can continue the discussion 14:55:38 ... we could also put something like a content type or protocol into base fields 14:56:35 ca: Regarding the examples: Does "depends on" refer to that we first need to apply what is written in the bases or the other way around? Is that just an include operation? 14:56:37 ek: That was also part of the criticism that we got so far 14:56:45 ... so we need to both basically 14:57:04 ... and in the case of web sockets, we need to also perform the HTTP upgrade operation 14:57:19 q+ 14:57:40 ca: @@@ 14:57:51 ... I think "session" would capture that 14:58:29 ek: I was also thinking about something like endpoints or servers, which is used by something like OpenAPI 14:58:42 lb: So, two things 14:58:56 ... first, bases. We currently have base which has a different meaning 14:59:03 mjk has joined #wot-td 14:59:04 ... I am all for collapsing the two 14:59:11 q? 14:59:18 ack c 14:59:19 ack l 14:59:22 ... for now we should discuss about reusing or expanding base 14:59:37 ... on the other hand, we might have an initial connection that we need to keep alive 15:00:03 ... the information that would be interesting to have in that regard would not only be the setup but the lifecycle in general 15:00:32 ... the thing is, to I need to keep the permanent connection? Or is it just something I would use if I have a bunch of requests to issue 15:00:53 ... in practice, it would probably work like "you have a connection and you can use for a certain amount of time" 15:01:11 ... I don't know if we have protocols that would time out after a certain period of time 15:01:23 q+ 15:01:35 ... but it might be useful information to have, to know when a connection would be closed 15:02:08 ek: In MQTT you have scenarios where constrained devices could close the connection after a certain period of time 15:02:10 lb: We should look into that more 15:02:42 ... regarding bases, it would be nice to have a way to describe when a connection is persistent or is persistent within a timespan 15:02:50 ... as the consumer can decide then 15:03:18 ... when the consumer is going through a connection, as it might be able to piggyback on a connection that is already open 15:03:45 ack k 15:03:45 ... the time for how long to keep a connection open would be something I would care about a lot 15:04:01 (Kaz whispered we were out of time :) ) 15:04:02 ek: This is very relevant in some cases, like longpolling 15:04:19 ... for the next time, I would summarize of the issues linking in the work item document 15:04:32 ... some of them are very long, so some destillation needs to happen 15:04:48 ... if there isn't any other quick business, we can close the call 15:04:57 There is none, call is adjourned 15:05:05 [adjourned] 15:05:18 rrsagent, draft minutes 15:05:20 I have made the request to generate https://www.w3.org/2024/07/10-wot-td-minutes.html kaz