API refactoring (issue 81)

<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

April f2f

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