https://github.com/w3c/wot

<McCool> should create a directory under https://github.com/w3c/wot/tree/master/plugfest for 2017-burlingame plugfest

time slot for this call

kaz: ok to change the time after the main call?
... any objections?

(none)

kaz: will change the reservation

PlugFest plan - Matsukura-san

Matsukura-san's slides

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?

F2F wiki

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)

Intel's plan

mccool: added information to the f2f wiki table

F2F wiki

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]