Meeting minutes
Meeting minutes
<kaz> Apr-13
<Ege> https://
<kaz> (minutes approved)
Agenda
<kaz> agenda for today
Binding Templates
PR 156
MQTT Binding: https://
Cristiano: PR is ready for review
<kaz> (postponed till the next call)
PR 157
CoAP improvement: https://
Ege: Merged
PR 151
Modbus Binding: https://
Ege: Merged
PR 140 and Issue 139
Discussion on text binding: https://
Cristiano: Concept needed, but maybe suggested text is going to far?
Ege: Agrees
Kaz: Can we really tell intention of the data if the format is text?
Cristiano: Could interpret text as number if parseable as such, otherwise it's difficult
Kaz: That's my point. For example, ECHOENT Lite Web API uses their Device Description which is similar to WoT Thing Description but their old specs used other text format or even binary format. So we should be careful about which type of payload data to be covered by the Binding Templates.
Cristiano: This is only about payload formats
mccool: also there is a possibility HTTP header says it's text but the actual content can be JSON
(some more discussion)
Kaz: we should clarify our scope for the ver. 1.1 specs including TD and Binding Templates
Issue 143
<Ege> https://
Kaz: Protocol Binding is a technology and Binding Template is a specification for that purpose
… that should be explained by the Architecture spec
… but if that's not clear enough, we should improve the Architecture spec
… also the Binding Template Note should be confomant to the Architecture spec
Ege: right
Kaz: before closing the issue itself, we should check with Ben as well
Issue 125
Issue 125 - Payload based protocols
Koster: should be in the binding
Ege: my concern is you could get various possible subprotocols
Cristiano: agree
… would prefer something more generic
… better to have a common way to handle this issue
… currently it's just a subprotocol but actually scalable
Kaz: yeah, we should clarify our scope around subprotocols as well
Thing Description
TAG review
<kaz> w3ctag/design-reviews Issue 715 - Web of Things (WoT) Thing Description 1.1: TAG and Security Review
McCool: There were an assertion in the architecture that we only support protocols with URI schemes
… but we adjusted it that we can also support protocols like MQTT or OPC-UA
Ege: Actually, the assertion was that the URI schemes need to be registered at IANA
… and that got removed
McCool: The reason for the origial assertion was to make it web-like
<Ege> https://
McCool: and allowing all mechanisms from the web
… but every IP address is a URI, right?
Ege: There are agreements on URI schemes in certain communities, for example in the case of MQTT
… and these schemes do not have to necessarily be registered at IANA anymore
McCool: Technologies like Bluetooth or ZWave do not have URI schemes, but they can easily mapped to protocols with schemes
Ege: We are focussing on IP based protocols right now
McCool: We can give the author of the issue the answer that we are focussing on IP based protocols and otherwise use gateway solutions
Kaz: We should ask the author for clarification or invite him to discuss the issue.
McCool: There is an easy distinction: protocols that use IP and protocols that don't
… question about scope
… focus so far has been on IP based protocols
… in theory, if there is a URI scheme for it, we support them, too, but we did not discuss those in length, yet
… ZWave and Bluetooth are not out of scope in general, but are not feasible to support with our current scope
Kaz: We should discuss non-IP based addressing
… we should clarify our criteria for a protocol or technology that be used for WoT
The group discusses the wording for an answer to the issue's author
<McCool> would propose: "the Wot TD is not meant for general web services, but there are often web services associated with IoT systems, such as proxies, shadows, and digitial twins, for which WoT TDs are appropriate"
McCool: I think non-IP protocols are implicitly out of scope of the current spec
Kaz: regarding this GitHub Issue for TAG review itself
... my suggestion is rather simply inviting them to our call like we did for 1.0 specs
McCool: I have had contact with him before, the TD call might be a bit too late for his timezone, we can invite him to the main call
PR 1452
<kaz> wot-thing-description PR 1452 - WIP: fix: allow uri value only for in field of APIKeySecurityScheme
Jan: tried to resolve conflicts but still some problems there
PR 1468
<kaz> PR 1468 - feat(context): use "@type" instead of "rdf:type"
Ege: CI is failing for this PR because the author has not signed the IPR
Kaz: Is it an editorial change?
Ege: The context is changed
Kaz: In general, we should ask people to open issues instead of PRs
McCool: Should we make the author an invited expert?
Kaz: Not needed for this PR alone
Ege: Author is very interested in RDF roundtripping
McCool: Fixes technical issues, which are details but still relevant
Kaz: We can consider the changes editorial changes, but we need to discuss if they really non-normative
McCool: We can ask them to sign the IPR
… problem if the changes turn out to be copyrighted later
… if authors contribute code, then they certainly need to sign the IPR agreement
… easiest way to let them sign the agreement is making them invited expert
Kaz: I would like to first see if the changes are really needed
McCool: Let's suppose it fixes a problem with roundtripping, then it is an important thing to get right
… so I think they could raise an issue and let someone else fix the problem
… an alternative could be to let the author state in their PR that they agree with the IPR policy
Kaz: The person has created three other PRs, therefore we should be stricter
… and tell the person that they should open issues instead
Ege: Christian Glomb knows the author
Daniel: Why don't we simply accept them as an invited expert?
Kaz: In this case we can make them an invited expert, depending on their affiliation
… as they work with Siemens, we might be able to discuss it with Sebastian next week
Ege: I also contacted Christian
Issue 1415
<kaz> Issue 1415 - Definition of 'well-formed'
Ege: I propose closing this issue
… as it has been resolved by PR 1456
Issue 1412
<kaz> Issue 1412 - Languages of service-doc?
Ege: Can be closed as it was fixed by PR 1449
Issue 1375
<kaz> Issue 1375 - i18n review checklist for TD 1.1 REC
Ege: This one can also be closed as there are separate issues for the checklist now
Issue 1384
<kaz> Issue 1384 - A TD should be able to define which Properties are required
Ege: Thomas added the label "Propose closing" himself
… I also think it can be closed
Issue 1462
<kaz> Issue 1462 - Bringing back Cert Security Scheme
Ege: There haven't been implementations for the CertSecurityScheme which is why the scheme is not in the spec
… there is one implementation now, which is why could add it back in
McCool: I think the ship has sailed for adding new stuff to the spec, in TD 2.0 we should rework SecuritySchemes as extensions
Kaz: We are already in an extended Charter period
… we would probably need to mark this feature as "at risk" if we need to revert this.
… so I'd agree with Michael McCool that we should defer this
… I propose to add the "Defer to TD 2.0" label to all the remaining issues by default (and possibly can revisit them later).
Issue 1338
<kaz> Issue 1338 - title must be mandatory for properties, actions and events
Ege: Issue is probably not relevant anymore
… Michael Lagally propose making title mandatory in affordances
… does not actually solve the problem it tries to solve, causes i18n issues
McCool: We are discussing this profiles
… if no title is present, then you could also simply use the affordance key
… similar to mandatory security definitions
… people could also simply provide an empty string, which would cause more issues
Ege: I am closing this issue then
Issue 1324
<kaz> Issue 1324 - Feedback on latest Editor's Draft
Ege: There has been a long discussion in response to the feedback by Ben
… opened a new issue for one aspect of the discussion regarding a missing mapping between DataSchemas like "Subscription" and operations like "subscribeevent"
… we could open the review issue by Ben and continue the discussion in the new one
Daniel: If the discussions in the old issue 1324 have been resolved then we can definitely close it
Kaz: Before we close it we should cheeck with Ben that his points have been addressed
Daniel: On the other hand he could also simply reopen it
McCool: We could mark it as "Propose closing"
Kaz: I agree, then we can continue the discussion next week
Ege: I also agree, I add to the issue that Ben could also close the issue if he thinks his points have been addressed
<kaz> [adjourned]