21 April 2021


Cristiano_Aguzzi, Daniel_Peintner, Ege_Korkan, Jack_Dickinson, Jan_Romann, Kaz_Ashimura, Michael_Koster, Michael_McCool, Sebastian_Kaebisch, Tomoaki_Mizushima
kaz, sebastian

Meeting minutes

minutes check from last week

<kaz> April-14

any objections befor publication the minutes?



Sebastian explains about the W3C patent policy

Jan introduces himself

<kaz> W3C Patent Policy

Jan is from University of Bremen

working in the chair of Carsten Bormann

publication plans

plan is to have everything ready until May 5

get resolution for publication on May 19

WoT Binding

Ege: shows an issue from the binding


<Ege> https://www.hivemq.com/blog/mqtt5-essentials-part9-request-response-pattern/

<Ege> https://github.com/eclipse/paho.mqtt.python/blob/master/examples/client_rpc_math.py

<Ege> http://www.steves-internet-guide.com/mqttv5-request-response/

<Ege> https://www.npmjs.com/package/mqtt

Ege: explains some example about request -response with MQTTv5

Jan reports some experiences with zigbee2mqtt

Ege: proposal is to introduce subprotocl: mqv:requestResponse

this would work with MQTTv5

<McCool> (heavy echo, if not speaking pls mute)

for MQTTv3.1.1 "mqv:responseTopic": "<topicPath>"

Cristiano: shall we use a different field such as version?

there was the discussion to use properties for the retain feature of MQTT

Koster: in SDF we have decided native subscription model

Sebastian: there was a presentation from the MQTTv5 authors and mentioned that you should not really use MQTT for req / res.

Koster: we should not force people implement req / res with events

cris agrees

Sebastian: retain flag in the TD is just a hint

Cristiano: the versioning problem is also related to other protocols

Ege: we can use mqv:version

Cristiano: we can do it more in a generic way

<mjk> I need to drop for the ASDF interim meeting

<Ege> https://www.w3.org/TR/HTTP-in-RDF10/#httpVersionProperty

<Ege> http://www.eclipse.org/paho/index.php?page=downloads.php

Ege: shall we support the v5 feature?

Sebastian: depends how v5 is adopted

Ege: no many broker have implemented it

proposal would be to stay with the MQTTv3.1.1 approache which does not come with req./res.

<cris> +1 for this direction

Defer issue to TD 2.0

Sebastian: please look at the issues labeled with "2.0"

2.0 issues


PR 1086

PR 1086 - Add section to define Canonical serialization

McCool: (describes the PR)
… would propose we merge this as the basis of further discussion
… removed duplicated rules, and it's much simpler now


Sebastian: (goes through the preview for section "6.5 Canonicalization")

McCool: maybe there are some mistakes there
… but can fix them
… currently the entries are put based on the alphabetic order
… I added an assertion on prefix to be maintained
… any processor needs to handle that

Sebastian: theoretically, we can use any kind of prefixes

McCool: right

Daniel: replacing geo, etc. to full notation?

McCool: JSON doesn't handle prefixes
… so we need to use some library
… canonicalizer handles prefixes as string rather than object

Kaz: why don't we add an Editor's note about those possible questions and then merge this PR itself?

McCool: either is fine, adding an Editor's note or adding small edits
… before merging
… URLs must not be modified

Sebastian: (adds several comments to PR 1086)
… fix typos, add assertion that a TD processor must not modify the URLs
… McCool adds those changes and then merge the PR
… can you remove the commented out part as well?

McCool: can do

Cristiano: thinking about prefixes
… we can say the most common practices is removing the prefix

McCool: right now the geolocation proposal to be fixed
… with certain prefixes to make the processing easier
… in theory, JSON processor need to see some table for the processing
… can depend on prefixes from protocols

Cristiano: how/which document to fix it?

McCool: canonicalization needs to be fixed
… certain fix for prefixes needed

Sebastian: so please apply the fixes and then let's merge the PR

McCool: ok

PR 1085

PR 1085 - WIP: Add Validation Section

McCool: this is related to validation
… would focus on the normative spec first
… not ready right now
… but would like to get feedback

PR 1090

PR 1090 - init tmRef

Sebastian: comments by Jan there
… we should not be more relaxing
… so can be more restricted


Sebastian: (goes through the changes)
… we can copy definitions to new ones
… and get new id:value pair
… the semantic meanings should be the same
… introduced new examples to provide better understanding
… overrides the maximum


Sebastian: (goes through the preview)

specifically the example 47

Jan: is having maximum as 100 too restrictive?

Sebastian: (shows the ASDF draft)

SDF draft

Jan: what about TM extending another TM?
… is that possible?

Sebastian: some example there (around lin 5196 from the HTML code)
… would like to suggest we merge this PR 1090 as the basis for the further discussion
… any objections?


(and merged)

PR 1092

PR 1092 - rename required to tmRequired + top level definition

Sebastian: renaming needed
… also need assertions for validation

McCool: playground should be also updated

Ege: I should include this change

McCool: will apply the changes

PR 1085 - WIP: Add Validation Section

Sebastian: quickly skim PR 1085
… may I merge PR 1092 now?

McCool: just wondering which the current spec use "ref" or "reference"

Sebastian: "ref"
… any objections to merge PR 1092?


(and merged)

PR 1095

PR 1095 - Two step generation of the TD from a TM

Cristiano: not sure if all the processors need to follow these two steps, though

Sebastian: note that you just provide the template.html
… but should provide index.html as well

Cristiano: ok

related issue 1047 - Two step generation of the TD from a TM should be clear

Sebastian: a bit concerned since this PR 1095 is very big
… should be split into several smaller PRs?

McCool: multiple smaller PRs would be better to handle
… note that every assertion must use the RFC2119 keywords

Daniel: some typo there
… "tmRequired" should be "tm:Required"

Cristiano: right

Jan: is partial TD introduced yet?

Sebastian: good question
… there Terminology section should have the definition

Daniel: the next publication version should include it (though the current published version doesn't)

<cris> Partial TD definition

Sebastian: need to have a look
… the definition is valid for the TD draft (at the moment)
… maybe it would be better where the definition is done (=within the WoT Architecture spec)

Kaz: note we're out of time

Sebastian: let's continue the discussion next week then
… thanks a lot for your contributions
… and thanks for your participation, Jan!

Jan: no problem


Minutes manually created (not a transcript), formatted by scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).