- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Fri, 4 Mar 2016 11:22:53 +0900
- To: public-automotive <public-automotive@w3.org>
- Message-ID: <CAJ8iq9WN_TTYdhHUYp_3WbB=xgxscdXth35di65iXJ53TqMXQQ@mail.gmail.com>
available at:
https://www.w3.org/2016/03/03-auto-minutes.html
also as text below.
We'll continue the discussion on API refactoring on the github issue 81:
https://github.com/w3c/automotive/issues/81
Also we'll create a WBS to gather people's availability for the April f2f
in Paris.
Thanks,
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Automotive WG
03 Mar 2016
See also: [2]IRC log
[2] http://www.w3.org/2016/03/03-auto-irc
Attendees
Present
Kaz_Ashimura, Dave_Jensen, Junichi_Hashimoto,
Powell_Kinney, Shinjiro_Urata, Song_Li, Ted_Guild,
Wonsuk_Lee, Yingying_Chen, Qing_An,
Tatsuhiko_Hirabayashi
Regrets
Chair
Ted
Scribe
kaz, ted
Contents
* [3]Topics
1. [4]API refactoring (issue 81)
2. [5]April f2f
* [6]Summary of Action Items
* [7]Summary of Resolutions
__________________________________________________________
API refactoring (issue 81)
<ted> [8]https://github.com/w3c/automotive/issues/81
[8] https://github.com/w3c/automotive/issues/81
<inserted> scribenick: kaz
ted: mentions the possible agenda
... Dave's new posted issue 81
... Paris f2f
... also should do introduction for Song Li
... located in Seattle
... security expert
... had good conversation while a go
... Junichi running the Security/Privacy TF
song: tx
... security company, Newskysecurity
... different devices including connected cars
... this automotive group is of interest
<ted> [9]http://newskysecurity.com
[9] http://newskysecurity.com/
song: would make contribution
... after the call maybe we can have another call to catch up
<ted> UW - University of Washington which compromises a number
[10]http://www.autosec.org/people.html
[10] http://www.autosec.org/people.html
song: traveling abroad till 17, though
ted: tx
... if you can join the IRC at
[11]http://irc.w3.org/?channels=auto
... taking minutes on the IRC
... two topics for today
... refactoring the current vehicle API
... Dave Jensen took an action at the previous call
... and did so. tx!
[11] http://irc.w3.org/?channels=auto
<scribe> ... dropped the link
<ted> [12]Use a service-based API instead of WebIDL
[12] https://github.com/w3c/automotive/issues/81
ted: next topic is April f2f meeting
... Dave, could you walk though your post?
dave: opened up an issue (issue 81)
... can close the previous issue 72
<ted> [13]Meta issue to keep track of actions
[13] https://github.com/w3c/automotive/issues/80
dave: discussion started on the web api
... took the websocket spec in a pretty straight forward way
... example on websocket would work for one-time get for door
information
... the other half is JSON-LD
... think it's very straight forward
ted: we do have Qing An and Wonsuk
... don't have Adam Crofts
dave: didn't address the location for the websocket protocol
... "localhost" could be used
ted: people may use example.org domain
<Song_Li> will localhost respond to other ip?
(some noise...)
<Song_Li> cool, so ws:// should be safe enough, otherwise I
would say wss:// is preferred
ted: couple of actions
song: wondering if we use websocket, will localhost respond to
other IP?
... over the air, secure version of websocket is preferred if
usual websocket is not safe enough
ted: data broker check the coming-in data
... great to add encryption
song: don't want anybody around the car use the websocket
connection
... we encrypt the data on the air
... using usual websocket could be enough, though
ted: tx
wonsuk: would ask about JSON-LD interface
dave: great idea. will work on that
wonsuk: what secure API would be like?
ted: my interpretation is we're exploring web idl
... web runtime approach
... are you in favor of that approach?
... I myself am neutral
... we could have existing vehicle api as a high-level api
... on the top of websocket/JSON approach
... mapping of library
dave: we want to use websocket precisely?
... or something may look like websocket?
... would figure out
wonsuk: api from the browser
... how can we map this approach with the existing spec?
dave: would see how to implement the current spec api based on
this new low-level interface
wonsuk: we would see how we handle that?
dave: yes
wonsuk: this websoket interface would be useful
... outside of the car, there would be a need for interface to
access things
<ted> scribenick: ted
kaz: within wot group there have been discussion on two level
of interfaces
<inserted> ... for the intra-car interface, we could use the
current vehicle api interface, and for inter-car interface we
need websocket-base network interface
wonsuk: i understand but my point is that the implementation
approach is quite different
... are we going to make a switch or provide both
<inserted> scribenick: kaz
kaz: would say we could have both the approaches like CSS level
2 and level3
ted: we could do that
... representing the vehicle api on the top of the websocket
approach
... would see what could be done
... would dig this websocket approach
... we focus on this first
... appreciate Dave's initial work
... would have a separate call. interested people's
participation is welcome
urata: some questions
... you provided two examples
... websocket type and promise type
dave: the idea is using the both
urata: ok
... the second one could be created on the top of the websocket
interface
dave: would combine the interfaces?
urata: I mean the second example is higher than the first one
... the first example is one connection with websocket is
shared
... with another object of vehicle interface
dave: don't know
... maybe separate websocket connection
urata: so separate websocket connections for each data?
dave: right
urata: data broker would have too many websocket connections
... might be a problem for the data broker
dave: websocket can't have more than one URLs as its target,
can it?
urata: maybe we can create one specific websocket connection
... and share it for many purposes
dave: that's why I think there is another open question
... really use websocket?
... or something looks like websocket connection?
urata: ok
... the second example has get and post
... in the promise style
... if you don't mean using websocket might use XHR connection
dave: right
... what kind of actual protocol is used is an open question
urata: @@@ (much noise)
dave: compromise between the approaches
... not aware of other standards so far
urata: there is some other work like WoT
dave: ok
powell: you still could host natural usual socket connection
... subscribe like this can be a socket connection
dave: we have a channel for abstraction
powell: MQTT can do something like that
... we've been developing clients negotiate with screens
... there is one host which has all the information
ted: Kevin is not on the call today
... would have delete mechanism
... probably on the data broker side
... people might want to work on that side
powell: can work on that for issue 81
dave: good
hira: urata-san, could you explain websocket could work with
our prototype implementation?
urata: yes
... we created a prototype implementation
... polyfill by javascript for vehicle api provider
... translation between vehicle api and native interface
... data broker just saving the data from CAN
... vehicle api pollyfill accepts the data and accumulate it
... vehicle data from the broker
... if we use get(), then the first data from the broker will
be gotten
... that is the basic mechanism of the data broker and JSON
data within our prototype
kaz: in that case, do you think you could provide basic idea on
the mapping between the current high-level vehicle api and the
low-level websocket approach?
... do you think it's difficult?
urata: not difficult
... mapping with high-level interface and translation to the
low-level data
hira: how we could change the websocket-based JSON data to the
WebIDL interface?
urata: can provide some basic translation later
hira: tx
kaz: we can work on that part as well on the issue 81?
urata: ok
ted: sounds like we'll work on issue 81
April f2f
ted: sorry this call was kind of ad-hoc
... before ending this call, would talk about the f2f
<ted> [14]start of a f2f agenda thread
[14]
https://lists.w3.org/Archives/Public/public-automotive/2016Feb/0007.html
<djensen47> It is doubtful that I can attend in person. I would
like to attend remote for any session where I'm needed.
kaz: might want to fix the basis schedule
ted: would get people's availability using WBS
... since not all the group participants are on this call
... will create a WBS
... the WBS should include call for agenda
... had a W3C/Genivi meeting on security
... and would put the information on the wiki
... Hashimoto-san, can you stay a bit more and have some chat?
... to share information with Song
... the main meeting is adjourned
... will create a WBS for the April meeting
<inserted> [ official meeting is adjourned ]
__________________________________________________________
ted: explains the summary of the security/privacy tf
... and ask Junichi for introduction
(some more chat on the security/privacy tf)
<ted> [15]as a proxy to restrict access to outside world and
provide data loss prevention
[15] https://en.wikipedia.org/wiki/Application_firewall
<ted> if we go web socket approach i think we will want the
same
<ted> as we are in a very different environment than
webidl+extension/plugin
<kaz> yeah
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [16]scribe.perl version
1.144 ([17]CVS log)
$Date: 2016/03/04 02:17:42 $
[16] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[17] http://dev.w3.org/cvsweb/2002/scribe/
--
Kaz Ashimura, W3C Staff Contact for Auto, WoT, TV, MMI and Geo
Tel: +81 3 3516 2504
Received on Friday, 4 March 2016 02:24:11 UTC