Meeting minutes
Minutes
<McCool> https://
(typos fixed)
PRs
PR 287
PR 287 - Cleanup of Security Considerations
McCool: (goes through the changes)
… we have location tracking
… added anonymous TDs
… any problem with this wording?
Farshid: this looks ok (some comments on Mitigations)
McCool: (adds tweaks to "Mitigations")
(merged)
PR 286
PR 286 - Add Amplification DDOS Security Consideration and Mitigations
McCool: (goes through the changes)
… (discussion on "Mitigations" for "Amplification and Distributed Denial of Service")
… how many URLs for TDs to be obtained?
… would let you guys review this PR a bit more
… Jiye is on vacation and also to review this
PR 290
PR 290 - Refactor directory API assertion IDs
McCool: did you change anything, Farshid?
Farshid: one more assertion D for tdd-search-sparql-federation-version
McCool: ok
… we need to update the testing files too
… a bit annoying but need to fix it
Farshid: I can also do that
… another update is about "tdd-thigs-..." instead of "tdd-reg-create-..."
… btw would be better to use "unified view" for the diff
McCool: (changes the diff setting to "unified")
PR 288
PR 288 - WIP: Implementation Report
McCool: my tool expects having 3 fields, ID, status and details
… would suggest we merge this PR
… who would work for Hitachi?
Toumura: currently all the results are "null"
McCool: ok, we don't worry about Hitachi's results then
Farshid: "null" and "not implementation" are same for the tool
… if some feature is not implemented, it would be a fail
McCool: the reason to have "null" is for templating for further edit later
… same thing as omitted
… in the test results, you can create a directory
… separate file for manual testing
… anyway, let's merge this as the starting point
Farshid: btw, does everyone use LinkSmart as the reference?
McCool: no
… (visits 2022.03.Online/Discovery/Results to show an example)
2022.03.Online/Discovery/Results
(PR 290 merged)
Updated implementation report
McCool: (shows the updated implementation report on his PC)
… some of the manual assertions to be added
… the problem here is
… would be too strong to require "MUST" for tdd-validation-result
… probably should be "SHOULD"
… also
… "necessary details" required is too much
Farshid: need another assertion to describe what is needed then?
<FarshidT> https://
Farshid: "7.2.2.1.6 Validation" above
McCool: it's funny to have an assertion on SPARQL though it's informative
Farshid: it's optional but normative
McCool: ok
… the question is who would be the client?
… Web browsers? or IoT devices?
Farshid: do we need two clients?
McCool: think so
Farshid: we have to implement most of the things from scratch
McCool: right
… anyway, if you think we need further issues, please create GitHub Issues
Farshid: Andrea will implement it at least
<FarshidT> LinkSmart has it too
Kaz: which specific feature are we talking about?
McCool: discovery features in general
… would leave them "work-in-progress"
PRs - revisited
PR 292
PR 292 - PR for adding assertion of discovery @context
McCool: should we allocate the context URL?
https://
McCool: I'm OK with merging this
Farshid: currently we're trying to allocate a new URL
(some more discussion)
Kaz: note that "www.w3.org/ns/td" is obsolete and we are now using "www.w3.org/2022/wot/td/v1.1" for TD
… so we could use "www.w3.org/2022/wot/discovery" for WoT Discovery
<FarshidT> https://
Issues
Issue 291
Issue 291 - Needed new assertion for discovery @context
McCool: (leaves a comment)
We need a temp URL for testing/tooling/validation purposes Third style is probably better (IMO) - using explicit tdd prefix Base context URL in these examples need to be updated, and there is a namespace already allocated We could automatically include the tdd context in the td1.1 (similar to how htv is included...), but for td1.0 it will have to be explicitly included (e.g. MAY/SHOULD) - use of tdd prefix is not not mandatory, but RECOMMENDED "Expanded" names ok (MAY), but only if base URL is consistent with standard context URL for the tdd
McCool: aob?
(none)
[adjourned]