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]