<kaz> yamada's pr
<kaz> daniel's pr
<kaz> accessibility, etc.
<kaz> scribenick: McCool
<yamada> https://github.com/w3c/wot/pull/395
yamada: plugfest logistics: sharing screen
... two commit
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!
<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
yamada: there is a sample but still under review within our company
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]