<kaz> scribenick: mjkoster

PF preparation status

<ryuichi> https://github.com/w3c/wot/blob/master/plugfest/2018-prague/docs/PlugfestPrague180117.pdf

matsukura: slides are aligned with Koster slides on PF goals
... review of goals on the first slide
... differences in NAT traversal
... we need to develop detailed specifications around each goal
... (2nd slide)

mccool: security requirement proposal for each use case scenario to include a security plan
... need a template to cover authentication, transport security, access control, etc

<kaz> koster: we should do it

mccool: even if the plan is no security, we should still require it

<kaz> koster: mccool, do you want to generate some template?

mlagally: is there a specification from last PF?

<mlagally_> is this all info on last PF? https://github.com/w3c/wot/tree/master/plugfest/2017-burlingame

<kaz> f2f wiki (participation and requirements)

koster: look at the PF wiki for the information, everything should be linked there

<kaz> Matsukura-san's consolidated information

<kaz> kaz: I thought Matsukura-san was working on the above consolidated page, and generating a report page as well

koster: we should require a detailed description of how each PF scenario will address the focus areas
... like the template proposed by mccooll for security

<mlagally_> consider a user scenario description containing preconditions, post condition, flows, exceptions

mccool: are there documents from the last PF that we can look at?

checklist rather than a form perhaps

<kaz> kaz: agree with you

<kaz> ... in that case, you, Koster, can start initial work for the Prague plugfest

mccool will start the security part, koster will start the new checklist, matsukura-san will fill in the information from the burlingame PF

<mkovatsc> http://w3c.github.io/wot/current-practices/wot-practices.html

<mkovatsc> Current Practice document was changed to define PlugFest scope, but nobody really cared...

https://github.com/mjkoster/wot-protocol-binding/blob/master/plugfest-prague.pdf

<scribe> scribenick: kaz

Koster's slides above (Plugfest@Prague)

mccool: we discussed accessibility for WoT during the main call today

koster: semantic annotation for that purpose?
... (adds "security" and "accessibility" to the goals)
... makes sense
... to get a couple of initial ideas
... and start to look at it
... [TD Annotation: Capability, Interaction, and Data Item]
... example code here
... semantic model
... not horizontal but rather vertical
... semantic annotation on 3 levels
... capability, interaction and data
... this is how those 3 levels work together
... maybe further discussion during the LD call and/or the TD call

mccool: regarding ontology, any update/improvement?

koster: keep going with iot.schema
... external semantic information
... now is good time to prototype something
... would try to use iot.schema for a while

mccool: wondering about the freeze date

koster: we should have a deadline
... how it works with different vertical industries?

mccool: new ontologies
... interoperability is required
... what about the base ontology?
... e.g., Celsius

koster: depending on what's available

mccool: ideally, somebody who's working on ontology should attend this PlugFest call

koster: for the base ontology
... Maria is working on ontology
... we can ask her to attend
... Victor also

mccool: we should resolve issues on the base ontology asap

koster: we cover everything from people and fix it
... worrying about the freeze day for the base ontology

mccool: right

koster: good input
... need to set it up
... towards the upcoming plugfest
... also freeze day for TD, etc., as well
... we make a catalog for verticals
... [Protocol Bindings]
... next level of Protocol Bindings
... device specific protocol adaptations like OCF, LWM2M
... we didn't really automated it
... need to start to work shortly
... first priority for more automation
... (adds "automation" to Priorities section)
... for exposing proxy devices: HTTP, WebSockets, MQTT
... how we do expose things?
... let me flesh out this
... consumer expose architecture/style...
... [add topics to "For exposing proxy devices" section]
... consume/expose style, architecture
... how to constructexposed things with different protocol vs. consumed things
... need to see that for proxies
... (and then goes through the "Priorities" section)
... TD vocabulary changes and adds
... aligned examples
... diverse examples
... observe property using CoAP, MQTT and WebSockets

kaz: question about how to use WebSocket here
... WebSocket itself doesn't specify any concrete procedure for connection

koster: good question
... it's just a transport and need some sub protocol on that
... (adds "develop transfer layer for WebSockets" to the "for exposing proxy devices" section)
... maybe WebSockets for events and notifications?
... data push
... there are 2 levels
... we need a standard way to sync up
... next level is WebSocket connection for NAT traversal
... (change the text to "develop transfer layer for websockets for general proxy connection")
... there are many different ways already
... any other comments?

mlagally: question on proxy devices

koster: if you have 2 different protocols you can sync
... current example has multiple protocols
... the other problem on value type/range
... e.g., integer and string

mccool: we should elaborate this

koster: local TD and remote TD

mccool: have to rewrite the URL (depending on the location)

koster: proxy doesn't have caching capability?

mlagally: is it a servient's functionality?
... or need another entity?

koster: proxy is also one of the servients

mlagally: so it's a special kind of servient

(discussion on "shadow")

koster: caching should be made based on system request

mlagally: agree. that's implementation-dependent
... would make various assumptions to the system

koster: [Thing Directories]
... application, proxy and Thing go to thing directory to discover/register the Thing
... go back to [WoT Proxies]

[adjourned]