W3C

– DRAFT –
WoT-WG - TD-TF

23 February 2022

Attendees

Present
Cristiano_Aguzzi, Daniel_Peintner, Ege_Korkan, Jan_Romann, Joel_Bender, Joel_Blender, Kaz_Ashimura, Klaus_Hartke, Michael_Koster, Michael_McCool, Sebastian_Kaebisch, Tomoaki_Mizushima
Regrets
-
Chair
Ege
Scribe
JKRhb, kaz

Meeting minutes

minutes

<kaz> Feb-16

ek: (goes over today's agenda and starts reviewing the minutes of the last meeting)
… are there any objections?

There are none, kaz is asked to remove the draft status

Issues

Issue 1405

<kaz> Issue 1405 - Consolidate Security and Privacy Considerations (moving IANA security considerations)

mm: I noticed that there are a number of IANA security considerations that might cause conflicts with our own Security and Privacy Considerations
… as they are not part of normative but informative sections
… an option would be to move everything under Privacy and Secruity Considerations but then these secions have to be normative

ek: I don't have a problem with making the two sections normative, but then you would need to make the security guidelines normativ as well

mm: These do not need to be normative as they only discuss possible risks and mitigations in an informative way,
… problem would be that we would add normative assertions, but we are feature frozen

ek: We are not feature frozen in that sense

mm: I will provide a PR for this issue for the next meeting

Issue 1403

<kaz> Issue 1405 - EventAffordance: rename data and dataResponse to message and messageResponse

ek: Michael Lagally proposes renaming the event fields data and dataReponse field to message and messageResponse
… in the discussion an alternative was adding an "event" field instead
… I think event causes a duplication of terms but data is too ambigious. I made some suggestions

mm: Payload sounds good but we should postpone it to TD 2.0

sk: I agree with postponing, we need to discuss payload structure in general
… examples are Philipps Hue and LwM2M which have their own payload formats

dp: We should only change the name with good reason

<kaz> Defines the data schema of the Event response messages sent be the consumer in a response to a data message.

<McCool> (for the record, I am ok with "data" since it is under event.)

<kaz> 5.3.1.5 EventAffordance

kaz: Agree we should defer this discussion to ver. 2.0 because we need to consider compatibility with ver. 1.0. BTW, it seems to be a typo in the description of the dataResponse field ("be" should be "by")

sk: I will create an issue for the typo

Issue 1400

<kaz> Issue 1403 - ThingModels should not define "required" affordances in derived TDs, but "optional" ones

ek: Thomas raised the issue that in TMs affordances could be mandatory by default and marked as optional using "tm:optional" (instead of "tm:required")

ca: This approach follows JSON Schema, but our use is different
… how should incomplete affordances be handled? Should they just be empty? Would make more sense if everything was mandatory by default

mm: I agree that it makes more sense, use case is different TD is about defining data models

<cris> +1

mm: behavior that everything becomes required if no tm:required is defined is not intuitive

sk: I agree that JSON Schema is a bit strange in this regard, but it is wildly used.
… my proposal would be that tm:required should stay but if it is not set then evething should be required by default
… SDF has a similar concept with sdfRequired

ek: I will contact the JSON Schema community to ask what the history behind their required property is

The meeting switches to discuss Binding Templates issues now

Binding Templates PRs

PR 147

<kaz> PR 147 - Adding links to readme

ek: This PR simply adds links to the individual bindings to the repository README

Binding Templates Issues

Converting the Binding Teamplates to Registry Documents

ek: Registry documents are a new type of document that can contain normative content and are organized as tables
… they define a process how additions can be submitted
… registries can also be a seperate document or a registry section
… in this case registries are not subject to the W3C Patent Policy

kaz: Do you want to ask the group if we should proceed in this direction?

ek: I don't want to reach any solution today but present the option

kaz: This should be discussed primarily by the chairs/editors, but we can also discuss it here

<kaz> i|Documents published at W3C - 3. W3C Registry Track

ca: I have a question regarding the embedded version of the Registry, can we include it the current Binding Templates?

ek: To be normative, they must be part of a normative document to be normative. They could be added to the TD document, though.

<kaz> W3C Process - 6.5. The Registry Track

kaz: I'd like the whole WG to clarify our intention whether we want to use the registry track or not.

sk: The intention would be to define protocol information in a formal way, each protocol has its own approach, with the registry approach we could express that we are aware of the variety of protocols and information can be incorporated via GitHub for example.

kaz: I completely understand which is why I suggested discussing this topic six months ago.

sk: You are right, we weren't aware of this type of document before you've mentioned it. We should discuss it in the editor's call

ek: Is it possible to have a registry section in a note document, kaz?

kaz: That is complicated, it would be better to split it into two parts and use the registry track for the registry document

ek: This registry track is similar to the way registrations work which was surprising to me
… there also has to be a policy for changes which makes it more transparent for external contributors

ca: I agree with the direction. However, if the registry is not normative, does it solve our problem that we want to refer to it from the main TD document?

<McCool> (sorry, I need to drop...)

sk: We should take a look at the approach taken by the DID working group, it should be solvable

kaz: One more comment: The approach taken by DID is possibly not the best solution for us. We should think about what we want to do and then which track we should use based on the latest version of the W3C Process.. We now have three tracks (REC Track, Note Track and Registry Track) and we should discuss which is fitting best for the Binding Templates

sk: Would be cool if you could help us and make a suggestion, kaz

kaz: The group as a whole should clarify what we want to do with the Binding Templates, and the Chairs and the Editors should discuss the procedure to follow based on that.

TD Issue #1395

<kaz> wot-thing-description Issue 1395 - Security descriptions alignment with OpenAPI 3.0

ek: There have been changes in OpenAPI 3.0 that make Security Schemes protocol specific

mm: The name and in issue is related to this
… we need to defer this to TD 2.0 in order to not break things
… name and in are not permitted by the RFCs, we dicussed adding a value of "auto" to solve this"

ek: I don't know if it is the best way the solve this, we could discuss defining SecuritySchemes in protocol documents

<McCool> (ok, now I do have to drop)

mm: Using auto is a workaround, an additional assertion should be added to handle this issue for now. We have to deal with it in TD 2.0. I will create a PR for the issue at hand which should be able to be merged next week

BACnet binding

jb: (introduces himself)
… I've been invited by Michael Koster to discuss how BACnet could be integrated into the Web of Things

jb: How much does the group know about the BACnet protocol?

<cris> new to me :)

<kaz> W3C Patent Policy

sk: I work at Siemens and am therefore familar with it, but I think the group in general is not

<kaz> (kaz reminds Joel of the W3C Patent Policy to make sure)

jb: BACnet is a peer to peer protocol, standardized by ASHRAE, used by many different families of objects (lights, elevators, ...). Mostly based on reading and writing properties. There seems to be a natural fit with WoT Things from my understanding
… there is a part of the BACnet standard that concerns Web based Things, object identifiers can be used to tie BACnet objects to the Web of Things (?)

ek: (shows the basic requirements for a protocol binding based on existing Binding Documents)
… for modbus, for example, there is a modbus:function. Protocol Bindings are independent of other protocols, Modbus for example is unaware of HTTP, but a consumer could re-expose a modbus Thing using HTTP

<kaz> Ege shows the MODBUS binding template draft as an example

<kaz> also the Ontology file

ek: the requirement would be to define a vocabulary (e. g. for interaction affordances) and an ontology to autogenerate the tables in the document
… Modbus is probably the best binding document at the moment

mj: there are two examples in the issue

<kaz> wot-binding-templates Issue 144 - BACnet Binding for Web of Things

<kaz> example 1

<kaz> example 2

jb: There are some things that need to be fixed in the example (for example, we refer to things by identifier and not by name) but it is pretty straightforward

sk: Key is to work together on an ontology to have everything that is needed by BACnet. If you already have an ontology then it should be very easy to create a binding

mj: There is also the need to define, e. g. data schemas

jb: There is a process to define data models based on submissions by manufacturers, which are translated into RDF by a data modelling working group

ca: There are some technical difficulties when writing these documents, as they are partially autogenerated by a .ttl file
… maybe it would be easier if you submitted a document and cleaned it up

<kaz> MODBUS area for Binding Templates

jb: I think I could also clone the repository and use the MODBUS document as a basis
… which files are autogenerated?

ca: Only the index.html file, which is created by a script which probably needs to be updated as the current document directories are hardcoded
… we can take care of these technical details, though

sk: Do you think we could work together on this? We could work in the W3C to start a blueprint

jb: Sure, I would start with creating a fork of the Binding Templates repository
… I am not an invited expert/part of a member organization (yet), though

kaz: If we need concrete contribution to our specification, e.g., providing concrete text for our spec, we should ask him to become an Invited Expert, but if we can continue the discussion based on BACnet's public resources and would invite Joel like today's call, we don't need to make him an Invited Expert.

jb: Michael Koster could make a contribution in this case
… joining W3C should not be an issue, however (?)

sk: (gives more background regarding WoT testing and plugfests, especially when it comes to working with the ASHRAE community)

jb: Would such a plugfest be BACnet specific?

sk: A specific BACnet event would be possible
… next event is planned for march, focussing on TD 1.1 as it is required for the Recommendation status

<kaz> Next Plugfest

sk: the next one, in summer, could take BACnet and a possible first draft into account

jb: Which protocols do you focus on?

sk: It depends, we discuss it before the plugfests and can discuss that we want to focus on a specific protocol for example

ek: (shows the structure of the wot-testing repository)

<kaz> ECHONET use cases

kaz: Before the actual plugfest, we might want to discuss concrete use cases first, as we did with ECHONET

<Ege> use case by Sebastian

<Ege> another use case by Farshid

kaz: Takenaka, a large Japanese construction company, has started using WoT for their use cases, for example

ek: (Shows the WoT use cases document where new use cases could be included)

Binding Templates Issue 49

<kaz> wot-binding-templates Issue 49 - CoAP Blockwise Indicator

kh: In HTTP you can define headers, in CoAP, however, you need to understand the context of options. In the discussion in the issue, we had the idea of rather describing the CoAP related features that are offered by a Thing and not the raw option values
… for some options like hop limit you could still use a generic option, but otherwise the Consumer would need to know the context of the option
… my favorite would be to only use featurs and only use optionName: optionValue as a fallback

ek: In MODBUS, you only have features at the moment

kh: In BACnet you could also have a similar approach

sk: Would you propose removing optionName, optionValue completely?

kh: I would prefer removing them completely, but we discussed this some time ago and decided against it

mk: I would also go for more of a feature approach

kh: One question I have, we currently have the binding document and the RDF document, which was very helpful in the case of HTTP. This could not be used for CoAP so well if we changed the binding document approach for CoAP

ek: The RDF documents for CoAP and MQTT are currently very generic

kh: Having an RDF document would not be a requirement for TD then? For BACnet we woud need a URI scheme then

kaz: (jumps in and suggests we continue the discussion next week since we're already out of time and this topic is a big topic requires longer discussion.)

[adjourned]

Minutes manually created (not a transcript), formatted by scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).

Diagnostics

Succeeded: i|goes|-> https://www.w3.org/2022/02/16-wot-td-minutes.html Feb-16|

Succeeded: s/preesnt+/present+/

Succeeded: i|noticed|-> https://github.com/w3c/wot-thing-description/issues/1405 Issue 1405 - Consolidate Security and Privacy Considerations (moving IANA security considerations)|

Succeeded: i|Michael Lagally|-> https://github.com/w3c/wot-thing-description/issues/1405 Issue 1405 - EventAffordance: rename data and dataResponse to message and messageResponse|

Succeeded: s/There seems/Agree we should defer this discussion to ver. 2.0 because we need to consider compatibility with ver. 1.0. BTW, it seems/

Succeeded: i|Thomas rai|-> https://github.com/w3c/wot-thing-description/issues/1403 Issue 1403 - ThingModels should not define "required" affordances in derived TDs, but "optional" ones|

Succeeded: s/topic: Binding Templates Issues/topic: Binding Templates PRs/

Succeeded: s/subtopic: Issue 147/subtopic: PR 147/

Succeeded: i|This PR|-> https://github.com/w3c/wot-binding-templates/pull/147 PR 147 - Adding links to readme|

Succeeded: s/ define process/ define a process/

Succeeded: s/What is the intention to add a registry?/I'd like the whole WG to clarify our intention whether we want to use the registry track or not./

Succeeded: s/make a decision/clarify/

Succeeded: s/Templates/Templates, and the Chairs and the Editors should discuss the procedure to follow based on that./

Succeeded: s/best solution/best solution for us/

Succeeded: s/, we should use the latest version defined by the W3C process/. We should think about what we want to do and then which track we should use based on the latest version of the W3C Process./

Succeeded: s/three tracks/three tracks (REC Track, Note Track and Registry Track)/

Succeeded: i|There have been|-> https://github.com/w3c/wot-thing-description/issues/1395 wot-thing-description Issue 1395 - Security descriptions alignment with OpenAPI 3.0|

Succeeded: s/BacNET/BACnet/

Succeeded: i|the requirement|-> https://w3c.github.io/wot-binding-templates/ontology/modbus also the Ontology file

Succeeded: s/Ashray/ASHRAE/

Succeeded: i|There|-> https://github.com/mjkoster/ODM-Examples/blob/master/protocol-descriptor/observable-flow-protocol-descriptor-bacv-223p.td.json example 1|

Succeeded: i|There|-> https://github.com/mjkoster/ODM-Examples/blob/master/protocol-descriptor/observable-flow-protocol-descriptor-bacnet-223p.td.json example 2|

Succeeded: s/Making him an invited expert would not be necessary, though/If we need concrete contribution to our specification, e.g., providing concrete text for our spec, we should ask him to become an Invited Expert, but if we can continue the discussion based on BACnet's public resources and would invite Joel like today's call, we don't need to make him an Invited Expert./

Succeeded: s/Michael could/Michael Koster could/

Succeeded: s/specific BACnet/specific BACnet event/

Succeeded: s/... the/sk: the/

Succeeded: s/on the/of the/

Succeeded: s/echonet/ECHONET/

Succeeded: s/http/-> http/

Succeeded: s/document)/document where new use cases could be included)/

Succeeded: s/#smart-building/#smart-building use case by Sebastian/

Succeeded: s/#connected-building-energy-efficiency/#connected-building-energy-efficiency another use case by Farshid|

Succeeded: s/Farshid|/Farshid/

Succeeded: s|https://w3c.github.io/wot-usecases/#s|-> https://w3c.github.io/wot-usecases/#s|

Succeeded: i/jumps/scribenick: kaz/

Maybe present: ca, dp, ek, jb, kaz, kh, mj, mk, mm, sk