Meeting minutes
Agenda Review
<kaz> Agenda for today
Ege: We will talk about the initial connection as well
Minutes Review
<kaz> Aug-1
Ege: already reviewed. We will go through slowly
Ege: anything to change?
Ege: minutes are approved
CoAP Binding
wot-binding-templates PR 353 - Replace cov:observe subprotocol
Ege: This is a breaking change but not the mechanism, just the TD
… also makes it possible to use fetch
Ege: there has been further reviews by klaus, ted and lately by Luca
Luca: small typo in the example
Ege: We can merge it asynchronously
… thank you for the work everyone
Klaus: thank you Jan for the work
Initial Connection
Ege: we agreed to move it to github
wot-thing-description PR 2040 - Initial/Common Connection Container Proposal (taking over PR 2037)
Ege: Here we can see 3 levels of examples
Ege: I have provided some explanations as well on the containers behavior
* An object like securityDefinitions, where keys can be chosen by the TD designer.
* Inside each key, we have all elements of a form except the op keyword and an additional reusable keyword with a boolean. It would be false for HTTP, true for broker-based connections or WebSockets.
* Any form that redefines the values of the connection, replaces them.
* If a value is not defined in the connection, the value in forms are taken
* If a value is not defined in the connection nor form, the defaults of the binding or TD spec are taken
Daniel: the word connection in the root level also plays a role
Ege: I added "- If not otherwise defined in a form, the value of `connection` in the root level is used as a default in that form"
Luca: we should remove exception of op and reusable keyword in each form
… since we can say that POST is used with writeproperty
… and even a single form can convey the meaning of reusability
Ege: let me put it into the example
Ege: this can make things more complicated
Luca: no it should be fine actually
… it sets the defaults for operations
… you can use connection again in another connection
… like you can overwrite only one element without rewriting it
… since everything is a form, you do not have any exceptions
Ege: I will rearrange the examples
Luca: ok
… this way a form can set the defaults of other forms
Koster: A question which is, we have persistent connections
… how do we express the reusability
… so how do we separate the connection maintenance from the other form elements
… so does the driver know when to reuse the connection?
Luca: one problem is that these are protocol specific. Depending on the protocl, there can be a single protocol to the server
… you can open a TLS socket and everything goes through that
… it can get difficult when you have multiple parameters for that connection
… this needs to be solved in the binding level
… If I want to describe a new security scheme, how do you do that?
… the binding would insert a term that insert all information needed
Koster: I think I understand
Koster: There isn't place in the binding to represent that connection
… it would be nice to represent it in the forms separately
… do we want a place in the TD to put that kind of parameters
Luca: it is the same situation we have with the verbs
… I mean methodName and their equivalent in other protocols
… we have this need in multiple protocols, like sending a keep alive request
… we can even mention that a request needs to go through a pool IPs
… for TD, we have to think of common terms across protocols
… the reusable term feels like a minimum
… if the connection is hierarchical, observing over a path hiearchy, what does it mean to reuse that connection
… this kind of strange policy can happen if we go deep into it and are specific to protocols
Koster: You confirmed my initial idea
… we will need a different dialog box per protocol
… so let's take those protocol specific stuff and put them somewhere specific
… we have to confront these ideas
Koster: we need more examples as well
Kaz: this discussion itself is important but too much detail. TD describes "Things" but we are handling meta connections for things
… maybe we can include it in the TD itself in the end, but it might be useful to once think about the connection and its reusability separately from the Thing (=TD) itself, then think about how to combine the Thing information and the connection information later.
Ege: I have added examples for simpler cases
Daniel: I think needs more thinking and has benefits
Ege: please feel free to provide more proposals in your own section or provide github comments
registry
wot PR 1203 - Extend W3C Registry analysis
Ege: I have linked the presentation from tpac 2023, process document and then summarized the process document
<kaz> merged
Overlaps of Binding and TD
wot-thing-description Issue 2006 - Fix overlaps between TD and Bindings content
Ege: so is there any volunteer to start these topics?
… second point is relatively easy, third one needs a careful moving
Kaz: we should talk about this with Koster after the break
Koster: I can start the work already and see where we can start
Ege: we can split the work between the two of us
<kaz> [adjourned]