W3C

– DRAFT –
WoT Profile

06 April 2022

Attendees

Present
Ege_Korkan, Kaz_Ashimura, Michael_Lagally, Michael_McCool, Ryuichi_Matsukura, Tomoaki_Mizushima
Regrets
Ben
Chair
-
Scribe
Ege

Meeting minutes

Minutes

<kaz> Mar-30

<kaz> approved

agenda

<kaz> agenda for today

Ege: should we prioritize the agenda items?

McCool: we can talk about transport security in the security task force

Ege: it would be nice to talk about what happens when TD fails validation

Lagally: we can talk about it when we come to it in the agenda

McCool: we definitely need the security and privacy sections for wide review
… it doesn't matter if they are empty or not

Issue 184

<kaz> Issue 184 - Check RFC assertions / only single keyword per assertion

McCool: we need to find a good time to do this since there are parallel PRs going on

<kaz> related PR 181 - WIP: Implementation Report

McCool: I have reworded some assertions, which touches many places in the document

McCool: we can merge some PRs today and then I can fix this

McCool: we can do it after the arch call tomorrow

Kaz: when you say two assertion keywords, what do you mean?

Ege: I am guessing a sentence that has e.g. MUST and SHOULD at the same time

McCool: so these should be separate assertions

McCool: we should make sure that assertions are self contained

McCool: too many PRs in parallel lead to merge conflicts

Ege: we should make sure that there are some tables where each line is actually an assertion

+1 to michael lagally

McCool: we can simplify testing by having a single schema for the table

Ege: but that would mean that if all the features/assertions are not implemented in a single TD, the assertion would look like not implemented

Lagally: we should not complicate the reader for the sake of the tool

Kaz: w3c does not dictate how the report should be generated. That's why I'm asking you all about our own intention and policy on how to generate assertion lists, e.g., getting one simple sentence with one RFC keyword as an assertion. However, if we want to do so, we need more volunteers for assertion generation and check. Also those volunteers should work on separate sections one by one to avoid conflicts.

<kaz> (McCool will work on assertion improvements a bit more, and we'll continue the discussion)

PR 157

<kaz> PR 157 - Define protocol binding for observing properties - closes #95

McCool: there are merge conflicts already

<kaz> Lagally's comments saying "Needs to be retargeted to SSE section."

PR 150

<kaz> PR 150 - event-payload-format

Ege: I don't understand how cloud events are useful when we have TDs anyway

Lagally: I am working on a PoC with webhook and I am thinking to include cloudevents

<kaz> diff - 5.2.3.1 Event payload format

McCool: on one side, leaning on a standard allows easier adoption
… on the other side, it increases the payload size

Ege: td already contains the metadata

Kaz: do you already have a prototype that uses this

Lagally: I am working on a prototype implementation on this

Ege: my opinion is that we do not need this wrapper metadata when we already have TDs

Lagally: We should not turn a blind eye to the world, find established standards and use them

<kaz> [adjourned]

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