See also: IRC log
<McCool> should create a directory under https://github.com/w3c/wot/tree/master/plugfest for 2017-burlingame plugfest
kaz: ok to change the time after
the main call?
... any objections?
(none)
kaz: will change the reservation
matsu: 4-layer structure for
PlugFest
... 4 layered servients: app, remote proxy, local proxy and
device
... [Servients and protocols]
... generated a table on servients and protocols
... filled in with Fujitsu and Panasonic
... Application Servient, Remote proxy Servient, Local proxy
Servient, Device Servient
... and interface protocols between them
... (goes through the table)
... (explains Fujitsu's example)
... air conditioner, LED and blind connected with http
... also another LED connected with HTTP
... can update the table if you can provide the information
mccool: similar table on the f2f
wiki?
... which protocol on which side?
matsu: if you support more than 1 protocol, please say so
mccool: question on the first
page
... [Servients from participants on TPAC 2017 plugfest]
... local proxy inside or outside of the local net?
koster: same question
... can also have some slide on that
... protocols could optimize the connection
matsu: (moves the line of "NAT/Firewall" above the "Local Proxy Servient")
kaz: think that was a bug
matthias: similar setup to Japan?
kaz: do we really want to have 6 apps?
mccool: maybe interesting
koster: maybe everybody don't need
to provide end-to-end system
... multiple applications are good for WoT
... for example, my application can connect with multiple
devices
... that is a story we need
kaz: +1
mccool: do you want to finish this first?
matsu: yes (and move ahead)
... [High-level description of Issues]
... Fujitsu has identified potential issues
... also would like to hear your about your issues
... [Deadlines and plugfest schedule]
... (strawman idea on the schedule)
... Oct. 18: complete the table of "servient and
protocol"
... who provide what?
... collection of TD for the servients for the plugfest
... clarify the application scenarios
... Oct. 25: specify inter-servient interface
... Nov. 4-5: Fujitsu open at 9am-6pm
... 1st day (Nov. 4): prep and plugrest
... 2nd day: plugfest in the morning
... demo and discussion in the afternoon
kaz: the scneario is something like Koster mentioned?
matsu: yes
matthias: tx
... please put this as well on the plugfest repo
mccool: suggests: https://github.com/w3c/wot/tree/master/plugfest
<mkovatsc> (more specifically) https://github.com/w3c/wot/tree/master/plugfest/2017-burlingame (does not exist yet)
mccool: added information to the f2f wiki table
slides to be added under https://github.com/w3c/wot/tree/master/plugfest/2017-burlingame
mccool: (goes through the slides)
... alexa for voice interaction
... also PoC slides
... [Web of Things Roadmap - SHort Term]
... [Metadata Bridge]
... what we did
... read external metadata and translate into Wot TDs
... [Metada Bridge: Phase 1]
... many copies of leaf processor
... OCF HTTP bridge and OCF metadata bridge
... translate into TD
... (on the Gateway side)
... [Metadata Bridge: Phase 2]
... for Burlingame
... still have a meta data bridge
... traversal via NAT
... WoT Shadow Servient
... and Web Dashboard
... also would use Thing directory
... cloud is actually on my pc in this version
... update my metadata as RAML
... that's my minimum requirements
... [Voice Control]
... [Voice Control Burlingame WoT Plugfest, July 2017]
... impement Alexa Skill
... voice commands to actual skills
... back to the shadow servients
... Alexa Skill reads Thing directory
... local IoT devices superimposed
... that's I'm planning to do
... [Fog Integration]
... also thinking about this
... I have a proximity detector
... walking through a camera
... application I want to run
... make services discoverable and locally available
... would like to make CoAP working
kaz: connectivity with the Fujitsu proxy?
mccool: local proxy has upstream and
downstream
... not really clear about DS, AS, PS, etc.
... wondering we should add hyperlink for the detail of each
entry
... URI for each device
... need to clean this up
koster: how to add information to the table
mccool: can work on the proxy side
myself as well
... we need to take the information instead
... also wondering if we can make an effort to get
tickets
... for encryption
kaz: Matsukura-san, do you think
Fujitsu also can try secure connection?
... if we can clarify the interface between Fujitsu proxy and
Intel proxy, maybe those 2 pieces could be connected with each
other
matsu: should I add HTTPS as the protocol?
mccool: possible
... let's talk about that later
... some of the scenario I'm thinking
koster: common capability for those?
mccool: I have some particular scenario in my mind
kaz: we need to clarify possible
scenarios from all the participants' viewpoint
... also wondering what kind of information is needed for the
interconnection
<mkovatsc> http://plugfest.thingweb.io/
mccool: starting with adding a column?
matsu: device servient for OCF device
mccool: WoT Proxy for HTTP
... don't want to have different protocols for WoT
devices
... even though we need additional one for OCF devices
matsu: expose Thing and consume
Thing
... your devices are expose Things?
mccool: WoT proxy translate HTTP into
CoAP
... might create a shadow servient which expose the capability
using HTTP
... still consider these devices are participants of WoT
... we need concrete definition, though
... local proxy, remote proxy, shadow servient, Thing
directory, etc.
matsu: I think we'd like to
concentrate on inter-Servient interface for the upcoming
PlugFest
... so this might be out of scope?
mccool: we can have terms on what we mean
kaz: think this is similar to
Panasonic's setting
... McCool can expose the proxy servient which is connected to
OCF devices
mccool: or the local proxy could be called as "OCF HTTP/CoAP bridge"
matsu: the structure is similar
to Pansonic's mechanism
... they have a translater between HTTP and Echonet on the
local gateway side
mccool: agree
... logical way for OCF Things
... will upload this presentation on GitHub
... also would like to talk about the roadmap in long run
... incubation, WD, candidate, final
matthias: question on [Metadata Bridge:
Phase 2]
... one of the questions Matsukura-san made
... on synchronization
... how this connection between servients looks like?
... with proxy servient from Fujitsu, Panasonic or Siemens
koster: exposed Thing is servient
matthias: what is the existing connection?
mccool: create 2 devices
koster: how to open the
tunnel?
... which pattern you choose?
matthias: one of the main
challenges
... different parties bringing different mechanisms
matsu: ok
koster: shadow servient goes through
the NAT
... other servient talk with Thing directory?
matthias: you can't go through the NAT
mccool: the outside can't see the
inside
... shadow servient can get information from Thing Directory
but can't go back to the local side
... Pansonic may have some solution
kaz: we should document that
issue as well
... maybe better to have an HTML or might be MD instead of PPT
:)
koster: MQTT is another one
... this is good to start the discussion
mccool: the time is another issue...
koster: trying different mechanisms is good (for PlugFest)
matthias: Matsukura-san's initial
expectation
... everyone can get on the same page
... but we already got interoperability issues
... put a link before
<mkovatsc> http://plugfest.thingweb.io:8081/api.json
<mkovatsc> http://plugfest.thingweb.io:8081/td
koster: people have different ways for NAT
mccool: you can't register URI behind
NAT
... that's one of the reasons we need shadow
... should we continue the discussion?
kaz: we should put issues on GitHub and continue the discussion next week
matthias: Matsukura-san should put the
issues on MD
... and slides on the GitHub PlugFest area
mccool: and the table should go into the wiki
matthias: editing table on wiki is pain :)
mccool: ah, PPT is fine in that case :)
[adjourned]