- 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