Meeting minutes
<Ege> https://
minutes
<Ege> https://
Ege: any objections? anything to change?
no
minutes are approved
Binding PRs
PR 188 + 193
PR 188 - Define CoAP Content Negotiation
PR 193 - Alternative proprosal for handling CoAP Content-Formats
WoT Thing Description 1.1 ED - 5.3.4.2 Form
<Klaus explains the technical details of the PRs>
Klaus: I open a PR in binding PR and not in node-wot
… HTTP binding does not check contentType
Kaz: You remove the contentType and make the field empty, but do you expect the default value of "application/json" to be applied?
Klaus: TD spec says it is manditory but I do not want to provide default value.
Kaz: in that case, we need to clarify the behavior, e.g., contentType with an empty string would mean VOID or might be better to explicitly specify [[ "contentType": "VOID" ]]. So need more clarification here.
<Ege> https://
Jan: Agree with Klaus that there is some fundemental problem.
… contentType can be protocol specefic
Matthias: I check the history of the binding repo
… content type should be ideally a metric if you read it
<mkovatsc> See https://
Matthias: ideal would be to use IANA media types , they are globally defined and they should be protocol-independent
Ege: we can rules such as if input type is used there should be a contentType used
<Ege shows the contentType usage in the TD1.1 spec>
Klaus: we should check this table and dicuss this again next week
Kaz: clarification question, when you said "This is a bug.", what did you mean the bug was from? The TD 1.1 spec, the Binding Templates Note, or node-wot?
Ege: a bug of node-wot
Kaz: as Klaus also kind of agree, probably the description on the default value within the TD 1.1 spec and possibly the Binding Templates Note should be modified about what would happen in which case, e.g., having no contentType line at all, having a contentType field with an empty value.
Cris: we had also a proposal
PR 183 + Issue 176
Issue 176 - [Modbus] URI design for modbus+tcp URI schemes
PR 183 - feat(modbus): move addres and quantity to URL components
Ege: question is about if the href. Should href be used to put all address information in there
Matthias: href follows web approach and I do not understand why not relying on this
<Ege present his comment https://
there are pros and cons. Readability and simple validation is important
… WS is also not solved nicely. href is used localy without any value
<mjk> I was trying to ack myself
Cris: we can define URL more verbose with readable variables (e.g. quantity etc)
<cris_> I did use modbus different times
Kaz: who has implemented Modbus binding so far? I think we can collect some more "Current Practices" like IPA guys (=Takenaka guys)
… we need more experiences from the developer
<kaz> mm: I've been working on Modbus implementations for my smart home system.
Matthias: we have devices and implementation, however, different business units used in different way
Matthias: address information in a single string has benefits such as simple copy it
Ege: should any protocol put in the href?
Kaz: we should collect best practices as the starting point.
<mkovatsc> have to leave for another meeting.
PR 190
PR 190 - Align protocol binding abstracts
Ege: HTTP has no abstract, Modbus has
… there should be always a part with the same abstract text
Kaz: I'm OK with merging this PR itself. However, please remember I still think it would be better to have a consolidated Binding Templates document describing the Binding mechanism and separate ontologies to refer to protocol-specific vocabularies. If we really want to go for this multiple sub-documents approach, we need to survey the existing vocabulary documents like the HTTP vocabulary and the MQTT vocabulary, and clarify the relationship between our generating vocabulary sub-documents and those existing documents.
Ege: I will merge it later. Need to fix the URL problem
TD
Dependency Check on the Binding Document
Sebastian: Michael Lagally has asked us to check if we have a dependency
… so we should do this
… I checked before the meeting
… I have checked the references first (ones used like [foo bar])
… we are referring to the last version published in January 2020 and only that
Sebastian: I have also checked with the 1.0 version and we are only referring to it to say "you can look there to have more information"
Kaz: that may not answer Michael Lagally's question, we should check the assertions
Sebastian: that is why I do this pattern search and I do not find the [WOT-BINDING-TEMPLATES] in an assertion anywhere
Sebastian: the results are pointing informatively to the binding templates for readers to find more information
Sebastian: Also we are doing the same in the 1.0 version
Kaz: if you look for protocol binding, you find results on "protocol binding" which might be referring to the content of the Binding Templates Note.
Sebastian: but these are not references to the document
https://
Ege: the term protocol binding actually means having forms and href inside etc. It does not mean the binding templates specification
Sebastian: we have put the http protocol binding in the TD spec since it was the most demanded one
Ege: I think that we do not have a dependency since the mechanism is defined in the TD spec
Kaz: I think we should look into the assertions
Kaz: we can do it offline
Sebastian: I can comment on Michael Lagally's issue
Kaz: we can split the assertions into group and the load can be shared
Sebastian: what do you mean by categorizing
Kaz: like the first X lines are reviewed by you, another by me and another volunteer like Ege
<sebastian_> https://
Sebastian: I will make a proposal on how to split it
Ege: I can help
Cristiano: I can also help
Sebastian: I will make a plan and ping you in the issue
Sebastian: then we can do the work and that should satisfy the requirements of the issue 1722
Editors list updates
<kaz> PR 1718 - Update editors list and acknowledgements
Sebastian: we can look at the commits
<cris_> I'm ok :)
Sebastian: what does everyone think?
Ege: Is it ok to have Matthias as Huawei
Sebastian: not sure
Kaz: Each WG can define its own policy about this kind of detail. I'd suggest you ask Matthias about his preference first. Technically, we can put his name with the previous affiliation under the "Former Editors" section and put his name with the current affiliation under the "Editors" section. What is important here is rather when he made his major contributions.
McCool: we had a similar issue with Farshid, you can duplicate it
Sebastian: I think we can merge it and then talk with Matthias about what he thinks or wants
Implementation Report
<kaz> PR 1725 - Oct 2022 impl report updates
<kaz> rendered version of the TD Implementation Report
<kaz> PR 1726 - Enumerate At-Risk Items
<kaz> Status of This Document section including the features at risk
Sebastian: we are looking pretty good
McCool: it is acceptable to go to CR right now
Sebastian: how many assertions do we have?
McCool: I see 455 in the template.csv
McCool: who to put as editors?
McCool: we can put me, me and Ege, me and Fady
… the conclusion is to put 3 of us
McCool: I will update contributions is to reflect the new implementation contributions
proposal: the editors of the implementation report should be the organizers and the contributors are all who contribute with the implementation results
proposal: the editors of the implementation report should be the organizers and the acknowledgements should list all the contributors who contributed with the implementation results
<sebastian_> +1
RESOLUTION: the editors of the implementation report should be the organizers and the acknowledgements should list all the contributors who contributed with the implementation results
<kaz> kaz: it would be nicer if we could clarify our policy for the TD spec as well.
proposal: the editors of the TD specification are decided by the consensus of the group and the acknowledgements should list all the contributors who contributed with git commits. There can be contributors who raise issues or participate in discussions and they can be added upon request in the acknowledgments
<sebastian_> +1
RESOLUTION: the editors of the TD specification are decided by the consensus of the group and the acknowledgements should list all the contributors who contributed with git commits. There can be contributors who raise issues or participate in discussions and they can be added upon request in the acknowledgments
Kaz: we can then document this in the readme after getting the whole WG resolution :)
McCool: please remind us in the main call next week to have a wg-wide resolution
PR 1711
Daniel: I have fixed the merge conflicts
<kaz> PR 1711 - refactor: add // or /*...*/ to make example be highlighted correctly
Sebastian: any objections?
Ege: I have that contentType PR, I can do it by next week. It is just explanation
PR 1721
Sebastian: (shows Editors notes within the latest Editors Draft)
Sebastian: (shows the Editors Note with a description of "No Tag Yet")
Kaz: can we really remove all the Editor's Notes?
Sebastian: they show that the spec is somewhat not ready right
Kaz: if some are not resolved, we should keep them mentioning this is not fatal and we can continue discussion on this for the next version.
Kaz: there are non-fatal editors notes in the other specs
<kaz> kaz: btw, we're already out of time, so I'd suggest we close the call and you update the publication schedule based on today's discussion./
PR 1727
<kaz> PR 1727 - use proper Architecture 1.1 reference
Sebastian: it only updates the link to the arch document
Sebastian: any objections?
<kaz> (merged)
PR 1728
Sebastian: I have talked with Klaus Hartke and he said that the TD should not have these examples but point to the binding
Sebastian: coap is not ready yet
Sebastian: I suggested that other protocols can be used, for more look at binding templates
<kaz> i|PR 1728 - Update 8.3 Protocol Bindings section|
Kaz: Removing the informative example from the WoT Thing Description 1.1 specification is fine, but we should clarify our plan to add even nicer and clearer description and example within the Binding Templates Note instead.
PR 1729
<kaz> PR 1729 - Update validation
McCool: I have further explained the validation
McCool: also the editors note is safe to remove
Sebastian: we can keep them
McCool: but the editors note does not make sense here
Sebastian: I can remove it now
Sebastian: we can merge it now
Kaz: some of the non-fatal and editors note can live in REC but we need to identify which is fatal which is not
<kaz> example of Editor's note within a REC
PR 1676
<kaz> PR 1676 - Tweak "out-of-band" in td-security-no-secrets assertion
McCool: We have discussed this in the security call, we can merge it
<kaz> (merged)
PR 1677
<kaz> PR 1677 - Define what it means to satisfy a security scheme
McCool: I will resolve the conflict and merge it
epilogue
Sebastian: thank you all for attending
Sebastian: Adjourned