Meeting minutes
Minutes review
<kaz> July-17
Luca: Talked about patch w.r.t. out-of box interop
… showed notes of previous meetings
… Ben explained what should be a profile and what not
… Koster seemed to have different ideas
… would like to take this topic up again
Luca: Any objections?
… none -> Minutes approved
Profiles as Ecosystem descriptors
Ege: Luca, can you explain overall concept
Luca: Let me try to summarize
… least amount of profiles... greenfield (Ben's position)
… other opinion, any people greenfield is others people brownfield (Koster's position)
Luca: Are we able to use our framework (or way of thinking) for greenfield or other ecosystems also
Koster: greenfield vs brownfield is adequate framing
… in bindings we have different protocols like HTTP and CoAP
… but we have also matter with a different protocol (e.g. Matter)
… I think profile might need its own protocol
… profiles for ecosystems also?
… not sure about difference between profile and binding
Koster: protocol binding should be focused on protocol ... rest in profile
Ege: in eco systems there is also data modelling
… no out-of the box interop if we can't decide on temperature format etc
Koster: I was thinking there other problems also
… useful to have industrial IOT data-model
… like temperature standardization
Luca: We will have TD2 to describe what is used in profile
… currently not the case for TD1.1
… profile collections of bindings
… at the same time you will have constraints
… a profile is going to tell what a thing can support/implement
… like a toolbox we can pick of
Luca: we don't have consensus on numbers and overlap of toolboxes
DP: Totally agree, we should subsetting TD2.0
Ben: Profile should constraint not extend
… distinction greenfield vs brownfield
… profile vs bindings ...
… prescriptive vs. descriptive
Ben: we should have as many bindings as possible but as few profiles as possible
… e.g. don't see benefit of having Matter profile
… Matter provides already guarantees
Ben: I don''t think we should many profiles
Kaz: I agree with Koster and Ben
… anyhow, have difficulties to understand current position of profile
… expectations for profile?
… would see what is expected for Profile and what is expected for Binding based on some concrete use case including several Things and Consumers from several different Ecosystems.
Luca: The conflicting point is not clear
… just using bindings is not satisfactory
… profiles towards pre-existing ecosystems
… so we can get more people on board
… concern: too many profiles cause fragmentation
… new adopters might get confused
… small set of profiles is useful for them
… we need a way to onboard other organizations
Ege: distinction to be made...
… small number of profiles
… vs. bindings like Matter, OPC UA etc
… they are out and should be usable
… in building automation no one will pick HTTP
… most likely BACnet will be used
… but they don't have thing description format
… we want to have guidance .. which leads to data model ... like temperature
… guidance to beginners is a valid point
… anyhow, spec is already too long
Ben: I do understand the problem of integrating new platforms
… but I think profiles are the wrong tool for it
… we should focus on use-cases and requirements
… for profiles in the future
… were I created a PR
Luca: Besides the term we can use -- platform binding.. collection of other bindings .. for me is a profile
… we can differentiate between profiles for beginners and for other systems ... technically it is the same
… new comers vs up-graders
Ben: platform binding vs. profile
… my proposal to solve overlap: move protocols binding into set of defaults to bindings
… profile becoming sub protocol ... for a given IoT platform
Koster: I am not proposing to make the sub protocols
… could be one of the constraint vector
… component of testing/certification
… not in scope of WoT
Koster: We should offer convenience people are used in other platforms like BACnet
… offering device standard
… or enabling consumers
… interop across ecosystems
Ege: w.r.t. platform bindings
… e.g. HTTP, JSON
… further like JSON has to look like this....
… this is the other aspect
Luca: My proposal. TD2.0 should remove sub-protocol
… sub protocol is result of process
Luca: we have to interop/bride between eco systems
… with semantics we can match Modbus values on the wire
… temperature Fahrenheit converting to Celsius
… should be expressive enough
… consumer should not have to implement everything
… would be way to complex
Ben: Profiles becoming device standard
… very unlikely
… more likely profiles used by bridging
… cloud service monitor buildings
… one profile using HTTP better than a hundred
… IoT is different .. but there is value in bridging
… btw, sub protocol keyword needed for web-socket
Luca: subprotol should be removed
… should become first class citizen.. it is a "protocol"
Ege: Ben's use case with gateways
… nice written TDs should be sufficient
Luca: We have to decide whether we want to continue discussion in 2 weeks
… a layer of warranting interop
… thing models in a more extensive way could be used
… maybe too constraining
… will try to put down were we have consensus
[adjourned]