Meeting minutes
Doodle
Kaz: Wed right before TD slot 1 (=right after WoT main call) is the best based on the doodle results
… we need to think about another slot for TD toolchain, though
Ege: ok
… need an announcement?
Kaz: we can report that during the main call tomorrow
… and the main call minutes can record the fact :)
High Level and Profile
Ege: we have examples of it at OCF, LwM2M, KNX-IoT and Thread Border Routers
Ege: they all specifiy payload and resource structure and security
… do they specify behavior?
Koster: they specify onboarding as well
… OCF and LWM2M do writeproperty differently: put and post and some others do patch
… they can also specify caching
… they specify payloads as well. like an ecosystem
… for something like matter you need a protocol binding and you need a profile on top of it
… so adapting wot to ecosystems would go through profiles
… so bindings and profiles would need to work together
Luca: in this case, profile and bindings would both need a registry
… the way a consumer needs to behave based on a protocol or profile would be the same. The problems are shared
… profile would need to give guarantee that the Things are 100% compliant
… so you need both
Ege: we should not propose a coap profile in that case since that is not a known ecosystem. We cannot do compliance testing
Luca: compliance testing is an issue with greenfield
Ege: we do not have the manpower to provide everything needed for profiles. We don't do onboarding etc.
Luca: some one will propose a profile sooner or later anyway
Koster: the http profile is a krellian profile in this case. That is what he sees as something to solve his customers' problems
Koster: calling it an http profile is weird since it adds another layer but no onboarding object structure etc.
… I have issues with having a native WoT profile
… not having conformance testing is a real issue though. We cannot do it in this charter and maybe never in W3C
… I like the generic binding idea. A profile can be added on top
Ege: a vanilla coap consumer can use a KNX IoT device by sending the correct requests. it may not understand all the payloads and may not know which property out of 300 that it should use
Luca: what you explain is ok but we have the question about greenfield. What about people who want to use our stuff and only our stuff?
Ege: we should have these discussions with more people and with concrete examples
Luca: we need to address people who want to use our stuff but we do not have enough guidance and we have too much stuff
Ege: we can put guidance in the TD spec with notes
Luca: but people will be still lost
Luca: people need stuff (e.g. SDKs) that just work easily
… that way people are not lost when trying to put everything together
Kaz: I agree with Ege that we need more people for this discussion and concrete environment and device for a specific purpose
Koster: we are talking about greenfield for device implementers. Do we want to work on 1 WoT profile to give to implementers?
… I would call that a device specification
… we would compete with Matter and similar
Koster: Do we want to create an ecosystem?
… that means adding onboarding and other mechanisms
… so it seems we need to agree on what problem we are solving
Luca: if we don't do this, someone else will do that
… profiles make evident what the actors can expect
… what is the baseline you are going to expect
… the actors need to be explicit on these expectations
Ege: so you are saying that explcit expectations in the TD would overwhelm the consumers
Luca: so we have to define what happens when a Consumer does not understand a part of the TD
… also there can be constrained Consumers
<kaz> [adjourned]