[auto-wg] minutes - 21 June 2016

available at:
  https://www.w3.org/2016/06/21-auto-minutes.html

also as text below.

Thanks,

Kazuyuki

---
   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                             Automotive WG

21 Jun 2016

   [2]Agenda

      [2]
https://lists.w3.org/Archives/Member/member-automotive/2016Jun/0001.html

   See also: [3]IRC log

      [3] http://www.w3.org/2016/06/21-auto-irc

Attendees

   Present
          Adam_Crofts, Peter_Winzell, Kevin_Gavigan,
          Junichi_Hashimoto, Kaz_Ashimura, Qing_An, Ted_Guild,
          Shinjiro_Urata, Rudi_Streif

   Regrets
   Chair
          Peter

   Scribe
          kaz

Contents

     * [4]Topics
         1. [5]f2f
         2. [6]service interface
         3. [7]WG charter update
     * [8]Summary of Action Items
     * [9]Summary of Resolutions
     __________________________________________________________

f2f

   peter: any questions?

   kevin: initially approved but not final

   peter: ok
   ... looked at the data spec
   ... to see how to transfer the data to the service interface

   song: coming to Portland

   urata: also coming

   ted: will be in Portland

   kaz: me too

   <ted> [10]F2F registration

     [10] https://www.w3.org/2002/09/wbs/1/auto201607/

service interface

   kevin: shows the wiki
   ... tx for good input from Song
   ... Architecture section and Security/Privacy section

   ->
   [11]https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service
   _Specification Vehicle Information Service Spec wiki

     [11]
https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification

   kevin: (goes through the Architecture section)



   The following diagram provides a component view of a vehicle
   system that implements the W3C Vehicle and Data APIs. This
   includes a JavaScript library which implements a Web IDL
   definition of the APIs and an on-board vehicle server that
   exposes vehicle data via a WebSocket and/or RESTful Web Service
   API. The diagram also shows a number of different types of
   on-board and offboard clients that can consume vehicle signal
   data.

   W3C Vehicle API Component Diagram v1.2.png

   ]]

   kevin: (goes through the component/description)
   ... the Server has the vehicle data
   ... 4 components corresponding to the Server: Browser, Web
   Runtime, Native/Managed App, or System
   ... on the Vehicle side
   ... Franca could be used
   ... this is a strawman diagram as starting point

   peter: please go back to the diagram
   ... I wrote in my email
   ... we want to use WebIDL for the spec
   ... that would work fine, I think
   ... don't think there would be issues
   ... because the service interface is quite simple

   kevin: we could create a JS library which people could use

   peter: one thing to discuss is how WebIDL would work
   ... the current W3C Vehicle Data spec or some other source?
   ... you could probably use the current spec
   ... not sure and am just looking the difference with VSS,
   though

   adam: one of the key issues is location

   kevin: we've been having discussion internally
   ... the consensus is that vehicle data should be logical
   ... would be easier to transfer from one to another
   ... e.g., left front mirror and right front door
   ... it's more forgivable to have vehicle.door.left , etc.
   ... vehicle.communication.position style
   ... e.g., vehicle.camera.back

   peter: there are implementations of the current draft spec
   ... should we try transition from that to the new proposal?
   ... the current vehicle data spec covers a lot of stages
   ... granularity issues
   ... how to map actual contents
   ... I have cloned the repo
   ... could put examples on the wiki
   ... should we have one sort of tree, or several possible trees
   in parallel?
   ... e.g., W3C tree vs. Genivi tree
   ... would not a good idea

   rudi: you can have multiple trees
   ... but could have one standard tree
   ... would make it fit the actual industry

   kevin: elements could have class
   ... each element has a unique ID
   ... JQuery-like approach
   ... class based on the ID
   ... could be very powerful

   rudi: good to have a philosophy on the data model
   ... very powerful and flexible way

   kevin: implicit knowledge for understanding

   rudi: discussion internally
   ... perfect topic to discuss in Portland

   peter: we briefly mentioned the f2f
   ... many people will come to Portland

   -> [12]https://www.w3.org/2002/09/wbs/1/auto201607/results
   registration results

     [12] https://www.w3.org/2002/09/wbs/1/auto201607/results

   kevin: would get the conclusion within a few days

   peter: don't have any more questions

   rudi: strawman initial agenda on the wiki
   ... feel free to add topics

   kevin: Security and Privacy section
   ... open to criticism
   ... suggestion is having 2 principals
   ... one security principal is "User"
   ... another is "Device"
   ... and suggestions on each security principal
   ... obtaining and renewing security tokens
   ... examples of token values
   ... User: Authorization
   ... Device: WWW-Vehicle-Device
   ... Use of Encryption
   ... signals are encrypted between the client and the server
   ... Token Renewal
   ... each security token will have a particular lifetime
   ... Error Handling
   ... 401: Unauthorized (token expired)
   ... got Song Li's comments by email
   ... TODO: Discuss requesting IANA reserves HTTP error number
   461 (vehicle/device unauthorised) and 463 (vehicle/device
   forbidden)
   ... TODO: Add table with list of error codes

   rudi: need to see formal granularity
   ... if I have authority to access data, need to have some
   certificate
   ... what kind of signal would it be?

   kevin: need to achieve
   ... make sure it could be applied to different implementations

   rudi: balance between the spec and interoperability
   ... have to be specific enough but can't specify too much
   details

   kevin: agree

   junichi: what if the network is unreachable?
   ... in that case, we can't talk with external servers
   ... so can't get security tokens

   kevin: that's possible
   ... but could have hardware chip on the vehicle
   ... don't have to go out

   rudi: need to leave now

   peter: different questions
   ... looking at VSS
   ... W3C should look into the license?
   ... thought something we might need to consider

   rudi: should not be a show stopper

   ted: will take a look

   rudi: leaving

   peter: anything else to discuss today, Kevin?

   kevin: no

WG charter update

   kaz: Ted brought the extension to W3M and got approval for
   3-month extension
   ... now we should update the charter with the new deliverables
   including the service interface
   ... each TF moderator and editor is encouraged to generate
   bullet points on their work

   junichi: new deadline is the end of Sep?

   kaz: yes

   kevin: good feedback from Rudi and Powell
   ... request for server and response to client
   ... timestamp for responses
   ... we'll go through and finish the changes

   peter: tx
   ... will also continue to look at the spec
   ... need to discuss what data we should use
   ... ACCESS, etc., have implementation of the current vehicle
   spec

   urata: about this service spec, the discussion makes sense to
   me
   ... which request corresponds to which response
   ... timestamp would be useful
   ... those discussions make sense

   kaz: maybe we need some kind of session id as well?

   kevin: possibly
   ... the whole websockets will be used by a single instance
   ... using natural request/response pair
   ... some sequence diagram might be useful

   peter: the server might keep different sessions at once

   kevin: the client can open more than one connections

   kaz: we should generate some Use Case descriptions, scenarios
   and then sequence diagrams

   peter: would be useful

   urata: difficult to follow the discussion by emails
   ... maybe we can use GitHub issues, can't we?

   peter: ok

   adam: we can raise issues

   kaz: do you have any images/issues to be added?

   urata: getting clear images for this service spec but want to
   record the discussion clearly

   kevin: will bring the discussion to the GitHub from now on

   urata: tx

   kevin: Adam and I are working on some implementation

   peter: also have one and would polish it up before the f2f

   kaz: you mean implementations of this service interface?

   kevin+peter: yes

   [ adjourned ]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [13]scribe.perl version
    1.144 ([14]CVS log)
    $Date: 2016/06/21 17:40:25 $

     [13] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [14] http://dev.w3.org/cvsweb/2002/scribe/