[PlugFest] minutes - 28 February 2018

available at:
  https://www.w3.org/2018/02/28-wot-pf-minutes.html

also as text below.

Thanks a lot for taking these minutes, Michael Lagally!

Kazuyuki

---

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                              WoT PlugFest

28 Feb 2018

Attendees

   Present
          Kaz_Ashimura, Fano_Ramparany, Kunihiko_Toumura,
          Michael_McCool, Taki_Kamiya, Toru_Kawaguchi,
          Ryuichi_Matsukura, Matthias_Kovatsch, Michael_Lagally,
          Takeshi_Sano, Takeshi_Yamada, Tomoaki_Mizushima,
          Kazuaki_nimura

   Regrets

   Chair
          Kaz, Koster

   Scribe
          mlagally, kaz

Contents

     * [2]Topics
         1. [3]agenda
         2. [4]diagram
         3. [5]interface template - yamada
         4. [6]Event handling by HTTP long poll - kawaguchi
         5. [7]plugfest logistics
     * [8]Summary of Action Items
     * [9]Summary of Resolutions
     __________________________________________________________

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> [10]Kaz's generated branch of preparation.md for the
   updated diagam

     [10] https://github.com/w3c/wot/blob/add-plugfest-framework-diagram/plugfest/2018-prague/preparation.md

   <kaz> [11]pullrequest #390 for the change

     [11] https://github.com/w3c/wot/pull/390

   (no objections to merge the change)

   (pullrequest #390 has been merged)

interface template - yamada

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

     [12] 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> [13]Kawaguchi-san's slides

     [13] https://github.com/ToruKawaguchi/wot/blob/master/plugfest/2018-prague/docs/Plugfest_event_proposal-20180228.pdf

   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]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [14]scribe.perl version
    1.152 ([15]CVS log)
    $Date: 2018/03/06 00:55:20 $

     [14] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [15] http://dev.w3.org/cvsweb/2002/scribe/

Received on Tuesday, 6 March 2018 00:59:54 UTC