Meeting minutes
<ML shows the agenda>
Testfest preparation
Profile Implementation Report
<McCool shares its screen and shows the latest result of the implemnetation report>
<kaz> wot-profile PR 327 - Implementation Report Update
PR that includes the latest IR
<McCool shows the structure and content of the PR>
Lagally: My template follows the same order of assertions as showing up in the spec document
… developer do not necessary read the spec document
McCool: I can also follow the same approach
<McCool shows the pyhton script>
Kaz: I support ML to keep the appearance order of the assertations both in the CSV and the table within the Implementation Report.
McCool: agree
Lagally: support to merge this PR
McCool: Which I do not understand is that there are automated asserations labeled, however, showing-up in the manuel section
… need to fix this
Lagally: we should do it later. First do the right sorting of the asseretations
Things vs Consumers
Lagally: we're lacking Consumer implementations
McCool: also validator for implementations
Lagally: (shows the result of wot-webthing)
… proxy can passthrough the actions
… would need another consumer to trigger actions
… have to know which actions to be handled
… power-on, power-off, etc.
Ege: we can't do that at the moment
… but can identify the action
Lagally: let's think about interoperability
… one synchronous action and one asynchronous action
… valid scenario for good coverage
McCool: we can think about some test scenario
… confirming some assertions
… would say some focused test scenario would be useful
Lagally: to see the coverage of implementations
… why don't we try tha approach?
Kaz: several basic questions
… 1. discussion on moving this result from wot-profile to wot-testing
… 2. we should once generate the draft implementation report rather than looking at the CSVs directly
McCool: looking at the CSVs directly still makes sense
… we need to add two categories, Things vs Consumers, to the template
Lagally: would add another column to the CSV template for that purpose
McCool: ok
… we can review it later
Kaz: which would be better, (1) having an additional column to identify the category or (2) having two templates (one for Things and another for Consumers)?
McCool: would be easier to have a separate csv for categories
Ege: do you want to talk about what Consumer is?
… playground can handle query action, etc.
… for me, Architecture terminology should be understandable
McCool: agree
Lagally: would exclude hybrid Consumer?
Kaz: sorry but a bit confused
… what do we want to do?
McCool: even for manual tests, simple test script can cover multiple assertions
Lagally: automatic testing is not required here
… McCool, are you generating some scenario so that developers can test multiple assertions?
McCool: I can do that but I can't provide concrete codes
… let's look at the list and see what we can do
Lagally: thanks!
… let's discuss the scenario and script next time
Kaz: just to make sure, McCool, you'll add modification to your tooling to keep the appearance order of the assertions. right?
McCool: yes
Architecture
PR 879
<mlagally> https://
approved
PR 880
PR 880 - fix binding reference in change log
Lagally: would like to merge this as well
merged
Remaining Issues for CR Transition
Lagally: will close issues which can be closed
<mlagally> https://
Kaz: that's kind of too much
<mlagally> https://
Kaz: which issues do you mean?
… labeled as "by CR transition"?
Lagally: would add "propose to close" now
… and let's confirm them next week
CR Exit Criteria
McCool: basically, can put it to the publication draft
… can apply the latest changes to the ED as well
Issue 778 - Generate static HTML version
Lagally: (adds a comment on applying the change for the exit criteria back to the ED)
Lagally: (shows the terminology for "Trusted Environment" within the ED)
Trusted Environment Set of devices that assume each other's claims of identity are authentic without proof and allow relatively unrestricted access to one another over a common protected network.
McCool: the easiest solution is simply removing that definition
Lagally: but we still need clarification
10.4 Trusted Environment Risks
Lagally: Security and Privacy section is normative. right?
Kaz: as the WoT Team Contact, I'm a bit concerned to simply remove this definition given it plays an important role for section 10
… we could ask TAG and Security guys to quickly review the definition
… and would suggest we explain the situation to Ralph as well
<mlagally> proposal: Ask TAG group for review of the terminology definition of a trusted environment in the context of WoT architecture.
Lagally: who would contact whom?
Kaz: would suggest McCool send a message to Ralph CCing team-wot
… as the starting point
<mlagally> proposal: Michael McCool will send a message to Ralph Swick to ask TAG group for review of the terminology definition of a trusted environment in the context of WoT architecture.
RESOLUTION: Michael McCool will send a message to Ralph Swick to ask TAG group for review of the terminology definition of a trusted environment in the context of WoT architecture.
Kaz: can help McCool for that
… e.g., by pinging Ralph and PLH
[adjourned]