agenda

<kaz> yamada's pr

<kaz> daniel's pr

<kaz> accessibility, etc.

yamada's pr

<kaz> scribenick: McCool

<yamada> https://github.com/w3c/wot/pull/395

yamada: plugfest logistics: sharing screen
... two commit

<yamada> https://github.com/yamagile/wot/blob/a49e3656bcc5f3e7c17d8ea409822ebd39d1d2f4/plugfest/2018-prague/preparation-panasonic.md

yamada: first, updated preparation-panasonic.md
... to clarify differences
... added link to sample TD

kaz: has already been merged

<kawaguch> https://github.com/w3c/wot/blob/master/plugfest/2018-prague/preparation-panasonic.md

yamada: so, yes, so looking at main document is also fine
... section numbers conflicted, though, so was updated

kaz: procedurally, better to do merge after PF call
... can do that next time

<yamada> https://github.com/w3c/wot/blob/master/plugfest/2018-prague/preparation.md

yamada: second commit in preparation.md
... added 5, requirements for plugfest setting
... based on previous PF wiki page

lagally: power requirements should be updated, not type C
... better to blank that out for now; also space
... will help will planning
... main information we need is number of plugs
... should just remove the plug type
... will be type-A provided by venue
... everyone just needs to bring their own adapters

McCool: suggestion, leave number of plugs, but put in () to indicate is tentative
... when people update, they can remove the ()

lagally: just want to make sure people do not depend on stale information

mccool: what is your timeline?

lagally: need it at least three days before the meeting

kaz: so, March 21st

mccool: also... what is the network situtation

lagally: http (80), https (443), ssh (22) for sure
... not sure about the others
... panasonic should send lagally an email

mccool: anyone who has requirements for ports outside of 80/443/22 should do the same (send an email to michael)

soumya: not bringing a car, will be mocked up in a server
... will be bringing the server
... AWS virtual machine
... no special power or space requirements

mccool: what about displays?

lagally: no displays... you have to bring

mccool: I suggest turboVNC + a laptop...
... I will bring a small portable display people can borrow for setup

kaz: main thing is people need to update this table

lagally: five people per table is the assumption

kaz: maybe we should clarify who is sitting with who

mccool: how big are the tables?
... also I suggest putting numbers of participants after each company
... later we can add lines
... looks like tables are 2m x 2m

lagally: can sit eight people at each 2x2 unit, four groups
... will be a whiteboard, not sure about projector; will check

kaz: speakerphone?

lagally: will check
... will have someone manning the reception
... will have to unlock and lock the door
... will have to go with them
... will also need to have fixed times to start/stop
... 9am to 6pm, no access outside that
... also... daylight savings starts that weekend
... so, on Sunday, actually starting an hour earlier!

daniel's PR

<kaz> https://github.com/w3c/wot/pull/387

kaz: lists major changes regarding TD spec. adding this kind of summary of major changes would be useful

mccool: will the thing directory need to be updated?
... will just have to try it, I guess...
... we should check and confirm that the thing directory implementations work with the new TD spec

kaz: do you know if proxy works with updated TD yet?

Matsukura: will confirm tomorrow

<kaz> kaz: another question is latest version of scripting api and binding

<kaz> mccool: interested in ocf binding

<kaz> ... what about other protocols?

<kaz> ... main ones are HTTP and CoAP

Matsukura: and panasonic will do an http service with long polling for eventing

mccool: does the proxy handle just http?
... yes; if we have coap devices, need local http bridges
... I'll be running an http/ocf bridge, will see if I can connect that to proxy...
... the remote/local proxy can only use ports the firewall allows

kaz: remote proxy is in japan... so we DO need to traverse the Oracle firewall
... should document what port the proxy system uses

mccool: I also have a system based on ssh tunneling but that should work ok if port 22 is traversable

example TD

yamada: there is a sample but still under review within our company

Sequence diagram

matsukura: would like to review sequence diagram

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

matsukura: we provide proxies, both local and in Japan
... added information about local/remote proxies

<kaz> diagram in appendix

matsukura: sequence diagram in appendix a

<ryuichi> https://github.com/w3c/wot/blob/master/plugfest/2018-prague/preparation-fujitsu.md

kaz: content is the same?

matsukura: yes
... A1, device can register with local proxy, will then register with remote proxy
... uris will be rewritten
... A2, application can look up TD in remote proxy
... A3, application can read and write properties
... can do on remote proxy, will then forward access to local device
... A5, can subscribe to events
... proxies will forward subscriptions and event notifications
... please refer to format in document

<kaz> mccool: what about security?

matsukura: at least something like basic authentication
... will at least be https; will look into how to set up security

mccool: I think it would be useful to at least try something simple here

kaz: would be useful to separate into separate parts for devices, applications

mccool: right now we have a spec... what would be useful is a actual running example, eg written with the scripting API

kaz: binding would also be helpful

<kaz> [adjourned]