Meeting minutes
Minutes
-> November-21
… No objections, minutes are approved
Quick updates
Publication Schedule within Jan 2023
Daniel: Plan to have updated draft within January
Holidays plans
Daniel: available Dec 5, Dec 12 and Dec 19
<cris_> +1
Daniel: restart Jan 9
<Mizushima> +1
Zoltan: Makes sense for everyone
Kaz/Mizushima: Jan 9 holiday in Japan
Kaz: most Japanese people will not be available on Jan 9
… I could join call on the 9th
Zoltan: We can have a *smaller* call
Daniel: Updates over Github?
… resume on 16th
Daniel: Try to be active week of Jan 9
PRs
Daniel: No updates yet
Zoltan: draft PR
… https://
Zoltan: need to add more algorithmns
… some more work
… need to refactor as well
… try to complete by next week
Daniel: Great
Zoltan: Please look at PR
… single ThingFilter only
… url used in case of needed
… from Discovery spec, do we need URL parameter ?
Cristiano: searching in directory... Discovery spec does not have this use
… filter based on body of TD
Zoltan: I see
Cristiano: url can be used in SPARQL
Zoltan: single ThingFilter enough
Cristiano: Keep it simple is good
… not much interest of standardizing different discovery mechanisms across bindings
… we have steps for HTTP and CoAP
… we miss other protocols
… could be moved to binding templates
Zoltan: for scripting. Shall we use local discovery ?
Cristiano: Not sure
… we might have such use-cases
Zoltan: Okay, lets omit url
… we don't use it nor do we know how to use it
… suggest to remove url
Cristiano: Need to ask ourselves whether there is a use-case
Zoltan: WoT runtime needs internal process
… local (Bluetooth or NFC) might be a use-case
… at this time we should keep it generic
… hence I suggest to remove
Cristiano: Agree
Zoltan: Bluetooth bridge in Discovery spec?
Cristiano: out of spec...
Zoltan: separate spec ?
Cristiano: Discovery spec just lists them
… I wonder whether we can encapsulate it in a generic fashion
Zoltan: e.g, runtime groups bluetooth devices in own directory
Daniel: will bluetooth/NFC part of next spec?
Zoltan: don't think we need that
… I wonder whether local discovery is allowed
… private directory?
Daniel: Out of scope of Discovery
Cristiano: local host does not make sense for BLE
Zoltan: As a bridge
… how to tell discovery that i would like to have local things
Cristiano: not possible to describe "locality"
… obtain URL via Multicast
Zoltan: discover local things via Discovery API
Cristiano: Yes, possible
… privacy concerns
Zoltan: dedicated method or "local" filter
Cristiano: Hard to decide
… tend to filter
Cristiano: need to define what local means
Zoltan: correct. Might depend on implementation also
Cristiano: for node-wot things in runtime are local
… WebThings as multicast plugin
Daniel: How does discovery spec for local things?
Cristiano: intro phase vs exploration
… one method in intro phase allows MDNS etc
… it generates an URL
… there are some constraints
… BLE is completely open
Jan: whether local method would do 2-step process in one?
Cristiano: Acts almost the same
… follow all the phases
… URL discovery and fetch
… others do just exploration
Zoltan: I think we can define local method later
… combines intro+exploration
… not just a filter
… I will not do it know
… should track it in an issue
… future work
Jan: postponing sounds good
<cris__> +1
Zoltan: Will summarize in issue
Daniel: May I ask you do create draft PR for your commits
Zoltan: Will do
[adjourned]