W3C home > Mailing lists > Public > public-automotive@w3.org > March 2016

[auto-wg] minutes - 3 March 2016

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Fri, 4 Mar 2016 11:22:53 +0900
Message-ID: <CAJ8iq9WN_TTYdhHUYp_3WbB=xgxscdXth35di65iXJ53TqMXQQ@mail.gmail.com>
To: public-automotive <public-automotive@w3.org>
available at:

also as text below.

We'll continue the discussion on API refactoring on the github issue 81:

Also we'll create a WBS to gather people's availability for the April f2f
in Paris.




      [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


          Kaz_Ashimura, Dave_Jensen, Junichi_Hashimoto,
          Powell_Kinney, Shinjiro_Urata, Song_Li, Ted_Guild,
          Wonsuk_Lee, Yingying_Chen, Qing_An,


          kaz, ted


     * [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

   song: traveling abroad till 17, though

   ted: tx
   ... if you can join the IRC at
   ... 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
   ... 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
   ... 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
   ... 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

   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
   ... 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


   <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

   <ted> as we are in a very different environment than

   <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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:47 UTC