See also: IRC log
<kaz> scribenick: McCool
<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
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.
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 ]