[wot-ig/wg] minutes - 26 July 2017

available at:
  https://www.w3.org/2017/07/26-wot-minutes.html

also as text below.

Thanks a lot for taking the minutes, McCool!

And thank you very much for joining the call, Benjamin!

Kazuyuki

---

   [1]W3C

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

                               - DRAFT -

                               WoT IG/WG

26 Jul 2017

   See also: [2]IRC log

      [2] http://www.w3.org/2017/07/26-wot-irc

Attendees

   Present
          Achille_Zappa, Barry_Leiba, Ben_Francis,
          Daniel_Peintner(IRC_only), Dave_Raggett,
          Katsuyoshi_Naka, Kaz_Ashimura, Kazuaki_Nimura,
          Kazuo_Kajimoto, Keiichi_Tokuyama, Kunihiko_Toumura,
          Masato_Ohura, Matthias_Kovatsch, Michael_Koster,
          Michael_McCool, Ryuichi_Matsukura, Taki_Kamiya,
          Tomoaki_Mizushima, Yongjing_Zhang

   Regrets
   Chair
          Matthias, McCool, Kajimoto, Yongjing

   Scribe
          McCool

Contents

     * [3]Topics
         1. [4]Agenda bashing
         2. [5]Mozilla, Ben Francis - Web Things
            proposal/contribution
         3. [6]F2F update
     * [7]Summary of Action Items
     * [8]Summary of Resolutions
     __________________________________________________________

   <kaz> scribenick: McCool

Agenda bashing

   <scribe> agenda: mozilla's contribution, f2f recap if time

   last week no mtg due to people travelling

   <mkovatsc_>
   [9]https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf#26_July_2017

      [9] https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf#26_July_2017

   note: ocf liaison meeting suspended in favor of protocol
   binding meeting, which a doodle will be sent out for shortly

   johannes won't be able to contribute to node-wot/SA, so we will
   have to figure out how to fill in

Mozilla, Ben Francis - Web Things proposal/contribution

   matthias: see overlap, complementary parts
   ... status, roadmap, main concepts, etc.

   ben: until further notice

   <benfrancis>
   [10]https://hacks.mozilla.org/2017/06/building-the-web-of-thing
   s/

     [10] https://hacks.mozilla.org/2017/06/building-the-web-of-things/

   Mozilla is not a member of this group, but contributes
   elsewhere

   blog post: consider Web as unifying application stack

   three integration patterns (from Web Thing model from prior
   proposal)

   patterns: direct, gateway, and cloud

   three different levels can expose a "WoT API"

   Mozilla's project Things

   three parts: Things Cloud, Things Gateway, Things Framework

   so far, have implemented an OSS implementation of Things
   Gateway

   also have a TLS tunneling service to Things Cloud

   Web Thing API - mention ongoing work at W3C, IETF, and

   this work has a lot in common with previous and current work on
   "Web of Things", but more concrete

   have specific definitions in terms of encoding (JSON), API,
   etc.

   Web Thing API description includes properties, actions, events;
   also links

   "Thing Description"

   also define a Web Socket API

   six basic message types

   keep payloads as consistent as possible with the REST API

   main issue with WS is that you have to invent your own protocol

   also section on Web Thing Types

   have some built-in types, just like HTML has built-in-tags

   idea is that you could extend these with semantic tagging

   with JSON-LD

   discussing whether with JSON-LD 1.1 whether we can implement
   this

   Mozilla wants to figure out best way to collaborate

   going back to formal objection...

   felt certain parts were not mature enough

   Ben: does this fit within the scope of the WG, IG, or should
   there be a CG?

   how to move forward?

   matthias: short answers to some questions

   regarding google, tried to figure out concrete blocker

   the issue was more dependencies, eg we needed to specify a
   "main deliverable"

   which we decided was the Thing Description

   we also determined that RDF etc is aligned with what Google is
   doing

   and, as can be seen with activity on iot.schema.org, Google is
   interested in this

   other comments: are lots of other IoT standards out there, we
   can't try to argue people over to yet another standard

   issue is domain knowledge

   so we want to go down a descriptive rather than a prescriptive
   approach

   gateway backend still has a lot of pain in the backend for
   integration; there is a lot of complexity there

   but we would like to use patterns from the web to make embedded
   interfacing easier

   but... some useful defaults for web interfaces would be useful

   so,Mozilla's proposal would be a "target proposal" for
   Web-based APIs

   long run, want to look at convergence of different technologies

   but this will take time... look how long it took for the web

   ben: want to sell idea of WoT to web developers

   our experience is that some things will appeal to them, others
   will put them off

   our concern is that semantic web technologies can make things
   look too complex

   so... want something simple as the first view for web
   developers

   so... see plain JSON encoding as good complement to current
   work

   want to avoid too much complexity

   current proposal has a log of x-agnostic components which add a
   lot of complexity

   matthias: in work on charter, also got this feedback...

   some parts are fuzzier than they should be, but as we have done
   the work things have become clearer

   for instance, for scripting API, in principle should be
   language-agnostic

   but what we work on right now, and what will be in first spec,
   is JS

   and is concrete

   similar to what's in web browsers

   we are aiming for a narrow waist... using Thing abstraction for
   everything, including system services

   SA overall is optional as well: people don't have to implement,
   but has been very useful

   other issue was RDF, etc.

   we do want a mode where people can work with a hard-coded
   vocabulary and can avoid the complexity of full RDF

   ben: personally skeptical of SA, have seen similar work... feel
   it is the wrong layer of abstraction to standardize

   should be about linked resources and web APIs

   but do understand that is the current charter

   what mozilla wants to figure out is the best way to collaborate

   matthias: first, we are looking at other serializations of TD

   we have been using JSON-LD, which comes for "free"

   but we have also been discussing others, eg. a plain JSON
   serialization

   this can definitely be done in IG, but maybe in WG

   other part is protocol bindings

   Moz proposal is prescriptive

   but, if we do a web-style interface, if "defaults" does
   something like Moz's proposal, then TD should be simple

   ben: provides metadata, but also links to resources

   our take on WoT is that is gives things URLs

   but they don't think it makes sense to extend to non-web
   protocols

   matthias: WG charter definitely covers serialization formats
   for TD

   schedule is part of the reason we pushed back

   right now JSON-LD works...

   but on the roadmap we definitely would be willing to look at
   other serializations

   ben: in terms of timelines...

   plain JSON format can be fairly quick if based on concrete
   model rather than trying to encode general-purpose abstract
   model

   ben: but, things are still in flux; not sure it will be stable
   soon

   matthias: so that sounds more like IG work

   <dsr> [11]http://iot.mozilla.org/wot/

     [11] http://iot.mozilla.org/wot/

   dsr: see that positioned this as w3c submission

   do you still want to go down that formal path?

   <dsr>
   [12]https://github.com/w3c/wot/blob/master/proposals/dsr-td/jso
   n-to-ld-dsr.md

     [12] https://github.com/w3c/wot/blob/master/proposals/dsr-td/json-to-ld-dsr.md

   also noticed that spec is very similar to what dsr proposed a
   while back

   and that provides a route to connect this to what we are doing

   think there is a way to connect this to what we are doing in
   both ig and wg

   ben: thanks for all the lively discussion
   ... not sure which route makes sense
   ... what is the most productive thing to do here?
   ... major difference is presence of links in TD...

   had discussion on github

   are those links part of TD or provided separately

   dsr: there are links elsewhere, are part of the overall story

   <dsr> Member submissions is a benefit for W3C Members, but in
   this case it seems clear that the submission would be directed
   to the WoT IG/WG, so a formal submission isn’t needed

   <kaz> +1

   <kaz> McCool's point on descriptive api

   <mjkoster> if anyone is interested in what the IETF is doing,
   please come participate

   <mjkoster> the discussion Ben refers to is already taking place
   in the relevant bodies in IETF

   kaz: would also appreciate Ben's contribution and participation
   in this call today

   and would also like to mention there are several paths and
   collaborations for this proposal

   for instance, auto wg has been looking at websocket-based
   interface and got VW's Member submission on similar mechanism
   (websocket + REST)

   however, probably the best solution for this proposal is
   bringing this directly to the WoT IG

   ben: auto wg reminded me...

   is a good example of offline or local collaboration

   and security etc is a big problem...

   having issues with HTTP, DNS, etc.

   kaz mentions the wot group has been holding joint meetings with
   the automotive wg at TPAC to think about possible collaboration
   about issues, e.g., on HTTPS, DNS, WebSocket

   have also been looking at automotive as possible use case for
   WoT work

   matthias: many topics... most important, perhaps topic on
   convergence

   but doesn't feel this will work with prescriptive approach

   but each ecosystem is still interested in connecting to others

   so they were interested in descriptive approach

   so... not pushing them to change their path

   so see TD as a way to help people converge

   for instance, if less-complex TD results, then will encourage
   adoption of common patterns

   ben: to re-iterate, want to get web developers to adopt
   technology

   but the more general approach is also more complex

   ben: is this something that a web developer can "get"?

   matthias: we have to figure out the best tradeoff

   maybe we can even consider a "lossy" serialization

   also have to consider audience: industrial, home, hobby, etc

   ben: definitely talking about real commercial applications

   prior experience was with web apps

   what eventually went out was progressive web apps, was very
   simple

   but seeing good takeup.

   ben: personal observation, new apis are a subset of the work
   ... yes, agree it is about finding the right balance

   matthias: would be nice if we can align it a bit; perhaps break
   it down into components?

   main point is that there are just a few things that were
   issues: hard-coded URLs, must be HTTP, etc.

   want to figure out how to present in a unified way, not create
   more fragmentation

   ben: interaction model
   ... dsr and I were discussing whether there is an enforced URL
   structure?

   <dsr> (more about simplifying the work needed by developers
   through convenient defaults)

   matthias: why we went just back to interactions was to make
   things look more like forms

   so there was just one way to build things; more flexible

   makes it easier to add additional interaction patterns later

   also had thought about URLs for non-HTTP/CoAP protocols

   could register a URI

   Matthias: there was also some comments about HTTP2

   but... "big web" people were not so interested in IoT

   did not get eventing model right, esp for small constrained
   devices

   <mjkoster> there is plenty of discussion on these questions in
   IETF and a lot of ideas

   also, IETF/CoAP working group did look at offline security
   issues already

   it may take another decade for HTTP to catch up

   ack

   <mjkoster> perhaps Mozilla should also participate in the
   relevant IETF WG for http, CoAP, httpbis

   <kaz> [13]TPAC schedule fyi

     [13] https://www.w3.org/2017/11/TPAC/schedule.html

   kaz: would be great if Ben could join the WoT IG as an official
   participant

   recap: summarize, next steps

   <dsr> It would be great to include the Mozilla approach in the
   next plugfest at TPAC

   we are both aware of usability tradeoffs

   it is certainly in the charter to look at alternative
   serializations

   can definitely start a tf to look at other serializations

   maybe we can have an additional meeting to get up to speed on
   current status

   should get better over the next few months as we nail down
   first working draft

   big more long-term, moz will try to look at TPAC participation

   could look at interoperation between the two approaches

   <kaz> [ note that the WoT group will meet on Monday/Tuesday
   (=Nov. 6/7) during TPAC 2017 in Burlingame ]

   ben is in the UK, so not "local" in SF

   also for security TF, need to consider the issues with HTTP

   <mjkoster> mjkoster is in Mountain View

   <mjkoster> ...and would be happy to meet with some of the
   project members

   <kaz> mccool: we're starting the binding tf and think about
   event handling as well

   <kaz> ... should look into Mozilla's proposal as well

   <kaz> ben: hope it would be better to see what would be the
   best solution

   eventing model... less obvious clear single solution

   <mjkoster> I want to use MQTT

   mccool: at any rate, a concrete action we can take is to
   describe the web socket approach at least

   dsr: there are various other issues with rebooting, etc.

   matthias: have to look at what devices are out there

   ben: eventing is a big challenge, but MQTT is "not the web",
   so...

   <mjkoster> websockets is more sockets than web ;-)

   matthias: also some IETF activity looking at eventing

   as said earlier, "big web" is not so much interested in this

   different approaches with state update (eventual consistency)
   and "real" events

   ben: also clear that more work needs to happen at IETF to deal
   with issues with HTTP and DNS, etc.

F2F update

   matthias: should be use last ten minutes on update on F2F?

   <kaz> +1

   <mjkoster> agree on the IETF comment, would like to see Mozilla
   participate

   <kaz> [14]Dusseldorf f2f minutes fyi

     [14] https://www.w3.org/2017/07/09-13-wot-minutes.html

   matthias: next F2F will be at TPAC

   <kaz> [15]future f2f planning

     [15] https://www.w3.org/2017/07/wot-f2f/slides/2017_F2F-Dusseldorf-Next.pdf

   ben: wg/ig joint?

   matthias: yes, some parts are more exploratory

   note also that IETF is right afterwards in Singapore

   so we want to avoid doing things after TPAC

   <kaz> [16]TPAC 2016 agenda fyi

     [16] https://www.w3.org/WoT/IG/wiki/F2F_meeting,_September_2016,_Portugal,_Lisbon#WoT_IG_Agenda

   note: we will target IEEE security conference with a separate
   event, not try to co-locate with F2F

   note also IETF changed dates to go to Montreal rather than the
   US

   Oct next year will be in Lyon

   matthias: (review of slides on deliverables)

   <kaz> [17]TF list

     [17] https://www.w3.org/2017/07/wot-f2f/slides/2017_F2F-Dusseldorf_ModularizationWork.pdf

   <kaz> [ adjourned ]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [18]scribe.perl version
    1.152 ([19]CVS log)
    $Date: 2017/07/26 14:08:59 $

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

Received on Wednesday, 26 July 2017 14:19:42 UTC