Meeting minutes
Agenda Review
Ege: TD tooling sub report, initial connection and TD project/Backlog
Minutes
<kaz> May-22
Ege: Will go quickly over the minutes
Ege: minutes from last Wednesday are approved
<kaz> May-23
Ege: since we are not sure if we will have a meeting tomorrow regarding the TD, we will have a look at them from Thursday last week too. Everyone should have received the email on the minutes
Ege: Minutes of last week Thursday are also approved
TD
TD Tooling Sub TF Report
Ege: for each part of the TD information model, there is a possibility to generate MD for the documentation
… makefile is removed and we only use python
… also there is a readme update
… Luca is planned to do a PR for separating branches and deployment
… mahda plans to fix the LinkML schema for the Json Schema generation
… if anyone else is interested let Ege know and they can also join
<kaz> toolchain repo
Reusable / Initial Connection
Ege: the goal is to extend the part of markdown so we have an understanding as a group, since the topic is large. It is important to have the same understanding. It will also be one of the usability improvements of the TD spec
Ege: Ege separated the document into Problem and related issues, and also the media type is made more clear
… anything you configure for a protocol that does not change for a form will be repeated, multiple bases are not possible, semantics of the protocol
… I want that we think about our requirements, currently the one in this document is a technical one, in the comming weeks we should think about the requirements and look at the issues while doing this
Kaz: Based on potential use cases, this discussion would be useful and important. However, from a security and privacy viewpoint, we need to identify how we use each connection, e.g., some kind of ID, user information and network resourcework resource. Potentially using that kind of information might be dangerous. We need to be careful
Ege: We didn't do any validation, but I hope there won't be any user information. We are just regrouping terms, and I hope there won't be added risks, but we need to be careful
… the important part is that "each connection needs to be identifiable"
… we currently have 4 issues around Reusable Connections, one from Cristiano is giving a good overview
<Ege6> - <w3c/
<Ege6> - <w3c/
<Ege6> - <w3c/
<Ege6> - <w3c/
Ege: if anyone notices issues related, ket me know
Issue #878 is about initial connections, it is about the 4th problem mentioned in the doc
Ege: Issue #1242 is about linking to the top level connection
Ege: Issue #1664 is about describing a single WebSocket endpoint shared by multiple TD's
Ege: I would like to have a detailed requirements, are there any points that you can already think of based on experience?
cris: The intial connection is a bit tricky, because you can manipulate the connection behind the curtains, it is tricky because you can already catch the initial connection when you need it, lazy connection.
… if we ever tackle the discussion, the first question is that do we want to have an interaction with stateless Thing
Ege: for me the idea was that if you do a read property, you see the initial connection, and can then reuse it
Cristiano: If you check for an open initial connection at some point you need to close it
Luca: We have already these kinds of problems when we have this specific flows in and out, exchange TLS keys, as a TD goes, the security part is already having those issues. In any case we need to solve them in the same way for a connection-oriented protocol and any security encapsulation protocol
Ege: Maybe we need to mention this, I would imagine if we need to provide a standardized option like OAuth
Luca: this is an implementation detail, it is good to think about it, but we need to make it in a way, being eager or lazy
… we have to have the concept of connection and the initiator, which complicates
Kaz: Technically we should think about use cases, but given the discussion from today so far, maybe we might want to think about some simple use case including a specific device and a specific application with multiple connection, and thinking about the flow before the requirements. Maybe we can think about basic data transfer sequence
Ege: good point, maybe we start with an example of message flow
Luca: Keep in mind that the websocket is at the same logical level as TCP
… I have a socket from UDP or TCP and do something on top
Ege: would you not see it here in the document?
Luca: we could use Socket.io
Ege: we could include something like CoAP over Web Socket
<kaz> CoAP over TCP, TLS, and WebSockets
Luca: I think there is something CBOR-based
Luca: we can put WireGuard
Ege: We have the proxy term in the security, maybe we write it as Proxy-based communication
Ege: Today, I would like to merge this document and see if we can get some contributions to it
Luca: It is too early to discuss if we would have consensus on change subprotocol to protocol
Ege: This would be in the scope of the same feature
<luca_barbato> Issue 1834 - Reconsider the interaction between Thing::base, Form and how the protocol is signaled
Ege: What I would want to do is to see if we can get examples of communication protocols
Ege: Would somebody want to tackle this? I would say a sequence diagram would be enough, the actual analysis would be done later. To show the data flow and the kinda action we need to consider
Ege: the messages between the Things and Consumers
… do we have any volunteers here?
Cristiano: I can try to do this, the part of WebSocket, I can try. The output your looking is a sequence diagram, with the messages?
Ege: yes, I think for the MQTT protocol for instance they have some basic diagrams
Cristiano: Should I adapt them to our context?
Ege: If we can put them in the context would be nice
Cristiano: Do you expect them to be written in this current document or somewhere else?
Ege: In this same document
Ege: Luca could you look at the Proxy-based part?
Luca: I can try to write down some possible examples
… the same socket for the same Things example
… I can try to come up with something by next week
Kaz: Think about broker-based, proxy-based probably would be needed at some point. However, we can start with a simple case: one Thing and one Consumer
Ege: I can do this simple case
<kaz> Issue 2025 - Extending the initial/reusable connection examples
Ege: There is a public holiday tomorrow in Germany, Mahda and Ege can't be present. Jan will be available. Will you be available Michael Koster?
Koster: I will be available, we can continue on the stuff we did today, and bindings
Kaz: Who will be present tomorrow?
<luca_barbato> +1
<cris> +1
<ktoumura> +1
<kaz> (At least Koster, Jan, Luca, Cris and Toumura)
<kaz> [ So we'll have a call tomorrow ]
<kaz> [adjourned]