Meeting minutes
Agenda Review
Ege: Today, we will mostly talk about the plugfest and then get to initial connection
… tomorrow will be more about bindings
Minutes Review
<kaz> July 4
Ege: Had a look on it before the meeting, looked good to me
… I will go through really quickly, let me know if you spot something wrong
… any remarks?
None, minutes are approved
Ege: Thank you, Cristiano, for taking the minutes last week!
Plugfest
<kaz> wot-testng/events/2024.11.Munich
Ege: Points were collected in the wiki so far
… as we agreed last week, we now moved them to the wot-testing repository on GitHub
… this is more like a technical document, logistics will remain in the wiki
… I also expanded the text a bit on the user scenarios
… we also added some explanation on what we mean with user scenarios
… to help users understand them in context
… this is sort of the user-facing part of it, the internal aspects are listed under TD Topics
… first point is existing features, where we want to make sure that features can actually be used
… the other aspect is new features
… there are also other topics, which are currently mostly discovery and scripting API related
… moved them to other topics for now, but we can categorize them further later
… does anyone else have topics here?
No one speaks up
Ege: Then we need to clarify and further categorize the topics here
Kaz: Categorizing and clarifying is fine, but I was wondering if we want to invite stakeholders/implementors as well
… for example, from the Smart City domain, maybe also companies from Germany
Ege: I think we can allocate the space for them, but they would need to bring their own setup
Kaz: Maybe at some point we need to add expected participants to each section
Ege: For me, these were so far TF oriented
… should maybe rather discuss this in the Plugfest call
Ege: Regarding existing features, we should prioritize the features where we have doubts
… also should link them to potential new features, like data mapping and additional responses
… other aspects like interoperatibility or degraded consumption are also related
… before discussing new meta operations, we should also consolidate and discuss the existing ones
… otherwise, initial connection should be trivial, will also discuss it today
… for data mapping, there are probably many corner cases, should collect them and gather as much information and experience as possible
… while documenting the existing features as good as possible
Kaz: Agree with the general direction
… maybe we might 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
Ege: (adds a note to the top of the document)
… another aspect we can mention is setups
… of the WG/IG as well as external ones
… (amends the document)
… for now I will just add this, but we should continue the discussion in the Plugfest call and get it done there
… (adds a note to the document that the data mapping topic will be prioritized)
Mahda: What is actually meant by data mapping?
Ege: Let me find the work item for that
… is related to potentially having fields within a data schema that could be expected to be contained in HTTP headers or Modbus registers
… (adds a link to the work item in the wot repository)
… (adds a note that meta operations as an existing features will also be prioritized during the meeting)
… (adds another note that existing features will be prioritized over new features in general)
Ege: For those who weren't in the main call: In two weeks we will restart the Plugfest call 30 minutes after the TD call
… to discuss setups etc.
Toolchain Discussion
Ege: Before the TD call, Mahda, Luca, and I meet to discuss the toolchain
… we are already seeing some issues with the JSON-LD context, which we could identify during the discussion, so that was already quite helpful
Mahda: It was again related to the confusion between the language tags in the title and description.
Ege: Before, it was not possible to model "string or array of string", but Mahda was able to fix it via the documentation of LinkML
Ege: We also had a review from a new member
Mahda: I think he is from the JSON-LD working group
Ege: seems to be very interested in WoT in general, was also active in the CG
Cristiano: It is good that the string or array string feature is now possible, but we were discussing to remove it.
Ege: I also think we should remove the feature, but we need to keep in some places, such as @type
… maybe we should do more of a survey before removing the feature, but in general I think we should stick to the array solution
Cristiano: Will probably also not really break implementations, since it would only affect the TD designers
Initial Connection Container
<kaz> Issue 2025 - Extending the initial/reusable connection examples
Ege: For this I would like to get some input before the holiday season
… as I think it is not that difficult and should be quick to do
… we have a section in the work items document, have listed some requirements
… we agreed to sketch how the message flows will look like
… have created an issue for that
… we agreed on using draw.io for that
… we have created a few first versions, look better now although still technical diagrams
… I followed Luca's design with my approach for modelling HTTP message exchange
… for MQTT with a broker connection it's getting a bit more complicated
… also illustrates that Thing and Consumer are both clients
… 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
… that is the current status how it looks like and how we are using existing connections
… explains the main points, can maybe add a bit more text later
… Luca has added his part, Cristiano, I think you need to still provide you diagram on WebSockets
Cristiano: OAuth is also still missing, did not really have the time yet
Ege: Any opinions? The colors might be a bit messy at the moment
Mahda: Thanks a lot for the effort you put in the diagrams
… for HTTP, for example, we might need another entity like the connection that shows how the messages are passed and that the connection persists
… because I think that is not really clear at the moment
Ege: That is actually covered by that yellow rectangle
Mahda: Maybe you could illustrate that better with another rectangle for the connection itself
… you could also cover the creation of the connection itself with separate messages
Ege: Actually, the connection is reused on a lower level, but that is not happening at the application level
… 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
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
Ege: Depends on the connection I think
… sensor data, for example, is not that privacy-critical
Kaz: That's why I was asking which part of the data should be removed
Ege: That is actually a difficult question, so at the HTTP-level, there is nothing kept or removed, but in MQTT you have a different kind of connection that would be reused
Cristiano: 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
… the interaction is completely different than in HTTP
… 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
… so what we need to illustrate here is the difference between a request-response pattern and a pub-sub pattern
… that might make 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
Ege: For me things are clear, but I am wondering how to illustrate that in the diagram
… because even with HTTP, you reuse the connection
… for example, there is only one DNS request
Cristiano: But you close the socket after the request is finished
Ege: But you can also keep the connection alive
Cristiano: This might be seen as an optimization for HTTP, but for MQTT it is the default
… in HTTP, you would "throw away" the connection, as the HTTP servers are built that way
… while in MQTT, experts would ask "Why are you closing the connection"?
Ege: Maybe we could add a time component to the diagrams to illustrate that
… to show, for example, that the MQTT connection will be kept open for five minutes, while the HTTP connection will be reestablished
… maybe we can also add some code to illustrate that
… that between two lines, the connection is reused
Ege: So Mahda, I think this was your first point?
Mahda: The first point was that we could explicitly show the connection in the diagrams
… 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?
Ege: In MQTT, the broker is not part of the Thing
Mahda: But the HTTP server could also be running on another edge device
Ege: 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
Ege: (adds a comment that summarizes the discussion so far)
… right, so then I guess I would adapt this diagram
… but I think the situation is clear for everyone?
… so what I was thinking was that before the holiday season we could look into some initial designs
… (looks for an issue with some initial examples)
… (finds the examples in issue 878 of the TD repository)
… so in this example, we were discussing that we could have multiple "bases" which we could refer to then in the forms
… then in the issue we had some discussion on that
<Ege> w3c/
Ege: I want to get to work on this to get some additional input here
… for next week I would then present the current proposals that we came up with so far
… and then we can continue the discussion
… we could also put something like a content type or protocol into base fields
Cristiano: 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?
Ege: That was also part of the criticism that we got so far
… so we need to both basically
… and in the case of web sockets, we need to also perform the HTTP upgrade operation
Cristiano: I think "session" would capture that
Ege: I was also thinking about something like endpoints or servers, which is used by something like OpenAPI
Luca: So, two things
… first, bases. We currently have base which has a different meaning
… I am all for collapsing the two
… for now we should discuss about reusing or expanding base
… on the other hand, we might have an initial connection that we need to keep alive
… the information that would be interesting to have in that regard would not only be the setup but the lifecycle in general
… 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
… in practice, it would probably work like "you have a connection and you can use for a certain amount of time"
… I don't know if we have protocols that would time out after a certain period of time
… but it might be useful information to have, to know when a connection would be closed
Ege: In MQTT you have scenarios where constrained devices could close the connection after a certain period of time
Luca: We should look into that more
… regarding bases, it would be nice to have a way to describe when a connection is persistent or is persistent within a timespan
… as the consumer can decide then
… when the consumer is going through a connection, as it might be able to piggyback on a connection that is already open
… the time for how long to keep a connection open would be something I would care about a lot
<kaz> (Kaz whispers we're out of time :) )
Ege: This is very relevant in some cases, like longpolling
… for the next time, I would summarize of the issues linking in the work item document
… some of them are very long, so some destillation needs to happen
… if there isn't any other quick business, we can close the call
There is none, call is adjourned
[adjourned]