Meeting minutes
minutes review
<kaz> Feb-7
Ege: anything to change? I only see name issues for daniel and koster
TD Resource Versioning
<kaz> PR 1969 - WIP: Concrete Versioning Proposal
Ege: we have met with Mahda, Luca and Klaus. We discussed tooling
… we documented everything at https://
… basically we can leverage npm to do a bunch of stuff
Daniel: do we want to publish packages with each PR
Ege: maybe monthly but we do not need many additional stuff
Kaz: we should not overcomplicate it but write the requirements first
Ege: yes we have identified overall problem areas
… but we want to keep it simple
Profile Design
Ben: we have discussed this before but I want to show the strawman proposal
<kaz> Ben's strawman proposal
Ben: we have two mechanisms to define protocol bindings, binding templates and profiles
… bindings are descriptive, profiles are prescriptive
… I have a proposal for another type of approach
… for profile and bindings to work better together
… 3 specs define bindings: TD, HTTP Binding Template and HTTP Basic Profile
… profiles go into more details
<kaz> WoT Profile - 6. HTTP Basic Profile
Ben: I propose removing section 8.3.1 of TD spec
… and merging http binding and profile
… profile can use the defaults of the http binding template
<kaz> WoT Thing Description Editor's Draft - 8.3.1 Protocol Binding based on HTTP
Ben: I have some google docs files that are meant to be thrown away, they are just discussion starters
<kaz> WoT HTTP Protocol Binding 2.0 proposal
Ben: actions are tricky though
… since it is not possible to specify manageable actions in td but it is part of the TD 2.0 workitems
… now let's see the HTTP 2.0 profile proposal
… each category has some tables that explains each part
… we should think about the normativeness
<kaz> WoT HTTP Basic Profile 2.0 proposal
Ben: if profiles depend on bindings, which are not normative, they cannot be normative as well
<kaz> wot-profile Issue 285 - Profile Mechanism 2.0
Ben: another approach is to define subprotocols but that would give less interop by default
… daniel asked what will happen to profile 1.0? I think we should publish profile 1.0 as a note
… in both case profile 2.0 will be not compatible with profile 1.0
Questions
Daniel: long running actions that is currently breaking "vanilla" implementations like node-wot
… TD and binding should open the hooks for profiles
… so would profiles always be a subset of the TD and binding
Ben: Ideally yes
… but I am worried that some parts of the TD can not evolve enough for profiles to support that
Ben: I want to structure what a profile can be
Ege: I like the direction. the table of contents is a good direction
… we need to agree on the purpose
<kaz> ... I had some points but I like the structured approach. We did not have concrete use cases for profiles from Siemens but we are discussing this at the moment. Maybe UI profiles or browser compatbility profiles make sense. The word profile was confusing to some in Siemens. Also, why do we constrain links in an http profile? In general, we should discuss the scope
Cristiano: sorry for not following up on the mailing list
… I like the direction overall
… thank you for the work. Discovery can be brought into bindings somehow?
… since discovery and protocols are closely related
… I agree with daniel that we should not circumvenite the TD spec to add stuff to profile. If we do that, both specs fail
Ben: as it currently stands, all discovery specs are in discovery spec. So the proposal is a subset of the mechanisms there
… I would be ok to not have some defaults if it means that mechanism is not in the td spec first
Kaz: thank you for the proposal and it is a good input. three comments
… refactoring of wot specs is necessary but it is a question for the whole group
… we need to clarify what we mean by this profile and profile in general. Some proposals were extensions of TD
… so we need to agree on what to specify by which spec
… we need more use cases about the specific features
… like async or sync actions that remind of media related apis or media and text streams
… we should clarify if that would be a target for this mechanism
Ben: profile should be constraints but in some cases we went towards extensions
… everything should be UC driven but this was from a use case in the beginning
Luca: in multimedia, a profile is a subset of a codec
… so we can do something like where we make the TD as descriptive and expressive as possible and then profiles constrain it
… we can even target cases like resource constrained devices
… TD can be extended a lot via semantic annotations
… so when that happens, we need to talk about what happens when a consumer doesn't understand it
… in media, a codec profile cannot extend the codec
… discovery is outside of TD. We can say that it is completely orthogonal to TD
… we have to define how profiles can be composed
Ben: a Thing can conform to a profile but it can do more. An HTTP basic TD can also have mqtt endpoints on top
… we have to make sure that two profiles do not conflict but I think profiles can be always combined
… there are also overlaps in discovery service api and profiles
Cristiano: discovery is orthogonal but you generally use the same protocol to use the TDD API and to interact with the THing
Luca: Discovery has a larger scope. we cannot describe mdns with a TD for example
… in mdns you can have both http and coap right now, it is expected that a tiny Thing implementing coap would advertise using mdns+coap or other coap-related protocols instead. It is an interesting topic to discuss
Kaz: we need to also discuss wot specs refactoring as a wg
[adjourned]
<benfrancis> Just one comment on the minutes: I said that my preference is to publish Profiles 1.0 as a REC, but I think there's also an argument to publish it as a Note and move onto Profiles 2.0.