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> F2F registration

service interface

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

-> https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification Vehicle Information Service Spec wiki

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

-> https://www.w3.org/2002/09/wbs/1/auto201607/results registration 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 ]