See also: IRC log
<ted> 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> 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 http://www.autosec.org/people.html
song: traveling abroad till 17, though
ted: tx
... if you can join the IRC at 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!
<scribe> ... dropped the link
<ted> Use a service-based API instead of WebIDL
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> Meta issue to keep track of actions
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
ted: sorry this call was kind of
ad-hoc
... before ending this call, would talk about the f2f
<ted> start of a f2f agenda thread
<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> as a proxy to restrict access to outside world and provide data loss prevention
<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