<kaz> scribenick: McCool

Agenda bashing

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

last week no mtg due to people travelling

<mkovatsc_> 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> 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> http://iot.mozilla.org/wot/

dsr: see that positioned this as w3c submission

do you still want to go down that formal path?

<dsr> 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> TPAC schedule fyi

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> Dusseldorf f2f minutes fyi

matthias: next F2F will be at TPAC

<kaz> future f2f planning

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> TPAC 2016 agenda fyi

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> TF list

<kaz> [ adjourned ]