Meeting minutes
Minutes
approved
Agenda
Lagally: Architecture: DTLS assertion, Test CSV
… Profile: WD, Testfest prep
… anything else?
none
Architecture
PR 886
PR 886 - Revise (D)TLS-1-2 assertions
McCool: DTLS 1.3 is at risk
McCool: but should say "at least DTLS 1.2 SHOULD be supported"
… don't want to seay "MUST" here, though
… need to live with "SHOULD"
… what's your opinion?
Kaz: 2 options here
… opt 1. wait for the CR transition approval tomorrow, and explain this change after that for PR transition
… opt 2. explain this change within the CR transition request itself TODAY (=before the approval)
McCool: opt 1 sounds better
… but we need to add this change anyway
… there are 4 assertions related to this change
Lagally: also think it would be better to wait
McCool: we'll apply this change for Proposed REC then
… please don't merge this until then
Lagally: (adds comments)
PR 884
McCool: all the assertions for Architecture are manual
Lagally: would merge this
merged
Profile
PR 314
PR 314 - Allow auto security scheme for other permitted security schemes
McCool: not for the CR but for the WD
McCool: HTTP has automatic negotiation
… so implementation is trivial
Lagally: please add your comment on the PR
WD
McCool: will work on the ReSpec errors
… shouldn't too much left over
Lagally: would expect some help for implementations
McCool: let's start with tools
… if any problems, may need to handle it next week
… anyway let me try
Profile Testfest prep
Lagally: not really prepared for presentation...
… but testing implementations
Kaz: we need to clarify the requirements/expectations for the testing first based on the W3C Process
Lagally: ok
… let's capture the requirements on a README.md
… (creates a README.md under wot-profile/testing area)
Kaz: the title should be "Profile testing for CR/PR transition"
… the purpose of checking the implementability of each feature defined by the spec
… if there are assertions which define the behavior of a Consumer, we need to see that
… on the other hand, if there are assertions which define the behavior of a Thing, we need to see that
McCool: yes
… so it depends on the defined assertions
Kaz: it implies that if there is any mismatch between the behavior of the Consumer and the behavior of the Thing, we need to fix the assertions themselves
McCool: right
… the purpose of testing includes checking that kind of problems
Lagally: (describes that kind of basic policy and requirements)
… (mentions validation of TDs against assertions)
Kaz: note that TD validation based on the JSON Schema is just a method to achieve the goal
… the main purpose is again the assertions defined by the spec itself
McCool: yes, including both the manually tested assertions and automatically tested assertions
Lagally: ok
… regarding the TD related to testing, all the TDs should have been validated against the TD spec
McCool: if you have webhook interface, the TD is provided by a Thing
… and to be consumed by a Consumer
… what is still missing is categorization of assertions
… someone need to look into all the assertions and categorize them
Lagally: (look into the wot-webthing-comparison.csv)
McCool: can you go back to inputs?
… categories.csv is currently empty
McCool: we need to categories which assertions are which (Consumer/Thing)
… the trouble is manual.csv
McCool: don't like a big table like this because we tend to miss some of the lines/fields
Kaz: data validation is rather pre-processing for the test
… the test itself should start with categorization of Thing vs Consumer as McCool said
… we should split the README.md into two sections, 1. preparation including data validation and 2. testing including data categorization
Lagally: (adds "for details (of the data validation), see instructions in the Testfest README")
… (then goes back to wot-webthing-comparison.csv)
Lagally: maybe we need some naming convention
McCool: need to identify each assertion as Thing, Consumer or both
Kaz: why don't we simply add a column to manual.csv to identify which assertion is for Thing, Consumer of both?
McCool: we need to identify the categories anyway, but...
Lagally: ok
… let's not add files to identify the categories then
McCool: so we'll use categories.csv to identify the category
Lagally: right
McCool: we can avoid making people confused with manual.csv by that approach
Kaz: ok
Lagally: after that we should verify Thing assertions and Consumer assertions respectively
McCool: we need two implementations for each assertion
… do we need actual pairs?
Kaz: the original expectation is checking the implementability of each assertion
… so the expectation and requirement of the spec assertions is "a specific pair of a Thing and a Consumer interact with each other like this", we need to have a pair at once
… but if the spec says "the Thing in general provides something like this" and "the Consumer handles the TD like this" separately, we can check those assertions separately
McCool: I'll work on the categorization then
Kaz: tx!
[adjourned]