agenda

<inserted> scribenick: kaz

kaz: diagram update, interface template, event handling, registry/discovery procedure

mccool: security a bit

diagram

<scribe> scribenick: mlagally

kaz: diagram was updated to include latest applications

<kaz> Kaz's generated branch of preparation.md for the updated diagam

<kaz> pullrequest #390 for the change

(no objections to merge the change)

(pullrequest #390 has been merged)

interface template - yamada

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

yamada-san presents interface template

yamada: I updated protocol and interfaces table - descriptions about servient interfaces were added
... Burlingame additions are highlighted purple

koster: long polling interface is for apps only?
... or for servient as well?

yamada: all apps can use this, not only Panasonic

mccool: only for events?
... example - get next frame of a camera - is this supported?

koster: observe would work for that
... long polling is only for observe over http - in the TD there are two uri's for that: one for read and one for observe

mccool: use case to give clarity?

koster: there's a uri for reading a property, another one for observe
... discussion about long polliing / streaming

Event handling by HTTP long poll - kawaguchi

<inserted> Kawaguchi-san's slides

Kawaguchi-san presents "Event/Property observe proposal"

kawaguchi: shows sequence diagram

mccool: do we support timeouts - what happens if the proxy goes away?

kawaguchi: not yet considered

<McCool> My point was more if the client goes away... the proxy should eventually give up and cancel the connection

<McCool> although there might be a different issue if the proxy goes away and the client has to reconnect, I think that can be handled as an error the client has to explicitly recover from

<McCool> there is also a question of what to do if the server dies

koster: how do you send unsubscribe?

<McCool> I think the way to deal with that is to have the client or proxy periodically "refresh" the observe

kawaguchi: diagram may not be precise

mccool: there will be a tcp timeout
... client should refresh the observe
... is this handled automatically?

koster: I would use this rather than websocket proposal
... if you want an immediate response, you can use read property

Kawaguchi presents TD snippet example - last time we used a different http server for handling observe property

kawaguchi: rel "observe" implies the use of long polling

mccool: should we define a different name for that?

matthias: we should use additional vocabulary - otherwise we cannot distinguish

<kaz> +1 to Matthias

discussion continues: headers - new tags ...

matthias: there could be multiple relation types

koster+mccool: new tag

mccool: we could use "mode"

<McCool> eg. "mode" : "polling"

koster: let's look at others, e.g. ietf to find best term

<McCool> but I agree with Koster we should do a survey

koster: one of the patterns did an upgrade to Websock - is this done during init or each time during a subscription?

kawaguchi: this is another pattern

<presents Event TD snippet>
... event subscription is using long polling

matthias: if there's only one entry in the form, you can ommit "rel"
... if you have an observable property, the client has direct access to the state - an event does not grant direct access - does not immediately expose state

mccool: coap uses this for eventual consistency
... bumping into a robot example - you cannot figure out what happened in the past
... observe and events are handled similarly at protocol level - this may be handled differently here

kawaguchi: <final slide>

matthias: open a separate web socket connection for each property is one option - if you follow your approach this appears to be a new protocol
... eg. coap over websock

kawaguchi: +1
... we would have to define this protocol

koster: is not fully described by uri
... do we need a separate port for each connection?
... this is a http-only problem - extend the vocabulary? new subprotocol?

mccool: these protocols have same structure, multiplexing wrapper?
... we may be able to specify this.

matthias: how much effort for simple websocket approach?

kawaguchi: need to discuss within company

koster: different ports?

matthias: yes

mccool+koster+matthias: consider firewalls, use http / https

kaz: how to deal with protocol keyword for long poll? Matthias - will you talk with IETF?

mccool: let's pick a temporary name and do a survey

matthias: let's start with a strawman

mccool: let's just pick a temp name and start the survey
... we need a name for the plugfest

kawaguchi: conclusion: do we have a temp name

mccool: subprotocol-long-poll

plugfest logistics

koster: any open logistic issues?

scribenick: kaz

mlagally: if you have any specific requirements, please let me know

scribenick: mlagally

mccool: everyone brings own switch - Siemens brings Wifi bridge
... does the Wifi prevent multiple connections, limit bandwidth , ...?

kaz: requirements put into preparation.md?

mccool: update Wiki to point to the md file

koster: will create a network requirements file and put into plugfest planning Wiki

matthias: our switch has 4 ports, everyone should bring their own switch

mccool: we had Wifi problems last times - I prefer wires this time

<kaz> [adjourned]