Meeting minutes
Minutes
Ben: (quickly goes through it)
… can approve it?
(approved)
WoT Profile 1.0 Publication
Ben: the next step should be creating a static HTML
… Kaz, you mentioned there was some guide for that purpose. right?
Kaz: yes
<benfrancis> https://
Ben: (goes through the guide)
… not very complicated :)
… will take an action item to work on that
Kaz: tx!
WoT Profiles 2.0 Planning
Ben: would have discussion to publish the UC Note for Profile 2.0 by the end of October
… would ask the group about their ideas/expectations
Kaz: would be nice to describe the difference between the Profile mechanism and the Binding mechanism
Ben: any other comments?
(none)
Ben: in that case, let's review the discussion so far
Issue 285
Issue 285 - Profile Mechanism 2.0
Ben: it's kind of long discussion started in 2022
… (goes through the issue content)
… the idea is Profile to be simpler and clearer
… then eventually became the strawman-proposal
Ben: there are two concrete proposals, one about Binding and another about Profile
… would show the Profile one
Strawman proposal on WoT HTTP Basic Profile 2.0
Ben: (goes through the proposal)
Strawaman proposal on WoT HTTP Protocol Binding 2.0
Ben: (then goes through the proposal around Binding)
… currently, we have protocol binding description with the HTTP Profile section
WoT Profile ED - 6.2 Protocol Binding
Ben: (revisits the proposal on HTTP Protocol Binding 2.0)
Koster: how to use the existing Profile for that purpose?
Ben: at the moment, we have two sets of mechanisms, Profile and Binding
… the two mechanisms don't really work well together at the moment
Koster: we want people to use the default for Binding
… if it doesn't work well, we can define another Binding which works with Profile better
Ben: right
… Profile wanted extends Protocol Bindings and Payload Bindings
… I'd agree with the Binding approach with Registry
Koster: was not sure how to describe the idea
Ben: there should not be domain-specific Profiles
… my view is you're fragmenting WoT with that direction
… cross-domain interoperability is needed
… and I'm curious about other people's opinions
Koster: Profile as a common application layer for multiple Bindings?
Ben: what if you're handling a constrained device with CoAP
David: we want to write standards for interoperability
… playing natural language
… we're not hoping we create our own Profile based on our industry area
Ben: ok
… the Web Thing Protocol CG is also working on Websockets
… Websockets might be a good solution for realtime connection
… we wanted to be extensible but would try to be simple as possible
Ben: any other thoughts?
Kaz: should ask Siemens guys also about their opinions :)
Ben: right
… let's ask them next time
Use Cases and Requirements for WoT Profiles 2.0
Ben: let's talk about the UCR for Profile
… we should have a document describing what to be done by WoT Profile 2.0
Kaz: whatever approach is fine :)
… if we want, we can reuse the template generated by the UCR TF
… or if want, we can work on another template
Ben: the template by the UCR TF is too much and kind of heavy
… also we need some more granular information
… (shows the UCR template)
Ben: (also shows the CG report by the Web Thing CG)
<benfrancis> Example Use Cases & Requirements document https://
Ben: any other ideas?
… what about how to get input?
… should use the GitHub Issue?
Kaz: GitHub Issue mechanism is fine
… also getting input as MD is also fine :)
Ben: ok
… MD might be a good starting point
… we can continue the discussion with more people next time
… including the high-level discussion about what WoT Profile 2.0 should be
… also how to get th information for UCR
AOB
Ben: any other points for today?
(none)
Ben: would continue the discussion on what Profile should do and which Profile to be included, etc.
[adjourned]