15:54:44 <RRSAgent> RRSAgent has joined #auto
15:54:44 <RRSAgent> logging to http://www.w3.org/2016/06/21-auto-irc
15:59:53 <AdamC> AdamC has joined #auto
16:00:32 <junichi-hashimoto> junichi-hashimoto has joined #auto
16:03:28 <kaz> Meeting: Automotive WG
16:03:29 <KevG> KevG has joined #auto
16:03:41 <urata_access> urata_access has joined #auto
16:04:11 <kaz> present: Adam_Crofts, Peter Winzell, Kevin_Gavigan, Junichi_Hashimoto, Kaz_Ashimura, Qing_An, Ted_Guild, Shinjiro_Urata
16:05:58 <kaz> Agenda: https://lists.w3.org/Archives/Member/member-automotive/2016Jun/0001.html
16:06:07 <kaz> topic: f2f
16:06:12 <kaz> peter: any questions?
16:06:32 <kaz> kevin: initially approved but not final
16:06:44 <kaz> peter: ok
16:07:23 <kaz> topic: service interface
16:07:32 <kaz> peter: looked at the data spec
16:07:46 <kaz> ... to see how to transfer the data to the service interface
16:08:22 <kaz> son: coming to Portland
16:08:23 <kaz> urata: also coming
16:08:33 <ted> s/son:/song:/
16:09:00 <kaz> ted: will be in Portland
16:09:20 <kaz> kaz: me too
16:09:35 <kaz> s/topic: service interface//
16:10:10 <ted> -> https://www.w3.org/2002/09/wbs/1/auto201607/ F2F registration
16:10:25 <kaz> topic: service interface
16:11:19 <kaz> kevin: shows the wiki
16:11:35 <kaz> ... tx for good input from Song
16:11:52 <kaz> ... Architecture session and Security/Privacy session
16:12:27 <kaz> -> https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification Vehicle Information Service Spec wiki
16:12:59 <kaz> kevin: (goes through the Architecture section)
16:13:04 <kaz> s/session/section/
16:13:06 <kaz> s/session/section/
16:13:45 <kaz> [[
16:13:46 <kaz> 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.
16:13:46 <kaz> W3C Vehicle API Component Diagram v1.2.png
16:13:47 <kaz> ]]
16:14:44 <kaz> kevin: (goes through the component/description)
16:15:19 <kaz> ... the Server has the vehicle data
16:16:27 <kaz> ... 4 components corresponding to the Server: Browser, Web Runtime, Native/Managed App, or System
16:17:01 <kaz> ... on the Vehicle side
16:17:09 <kaz> ... Franca could be used
16:17:33 <kaz> ... this is a strawman diagram as starting point
16:17:45 <kaz> peter: please go back to the diagram
16:17:55 <kaz> ... I wrote in my email
16:18:05 <kaz> ... we want to use WebIDL for the spec
16:18:20 <kaz> ... that would work fine, I think
16:18:46 <kaz> ... don't think there would be issues
16:19:16 <kaz> ... because the service interface is quite simple
16:19:47 <kaz> kevin: we could create a JS library which people could use
16:20:19 <kaz> peter: one thing to discuss is how WebIDL would work
16:20:49 <kaz> ... the current W3C Vehicle Data spec or some other source?
16:21:24 <kaz> ... you could probably use the current spec
16:21:52 <kaz> ... not sure and am just looking the difference with VSS, though
16:22:21 <kaz> adam: one of the key issues is location
16:22:45 <kaz> kevin: we've been having discussion internally
16:23:01 <kaz> ... the consensus is that vehicle data should be logical
16:23:38 <kaz> ... would be easier to transfer from one to another
16:24:22 <kaz> ... e.g., left front mirror and right front door
16:24:57 <kaz> ... it's more forgivable to have vehicle.door.left , etc.
16:25:11 <kaz> ... vehicle.communication.position style
16:25:39 <kaz> ... e.g., vehicle.camera.back
16:25:57 <kaz> peter: there are implementations of the current draft spec
16:26:25 <kaz> ... should we try transition from that to the new proposal?
16:27:00 <rstreif> rstreif has joined #auto
16:27:03 <kaz> ... the current vehicle data spec covers a lot of stages
16:27:16 <kaz> present+ Rudi_Streif
16:27:27 <kaz> ... granularity issues
16:27:44 <kaz> ... how to map actual contents
16:28:14 <kaz> ... I have cloned the repo
16:29:07 <kaz> ... could put examples on the wiki
16:29:51 <kaz> ... should we have one sort of tree, or several possible trees in parallel?
16:30:10 <kaz> ... e.g., W3C tree vs. Genivi tree
16:30:19 <kaz> ... would not a good idea
16:30:25 <kaz> rudi: you can have multiple trees
16:30:32 <kaz> ... but could have one standard tree
16:31:48 <kaz> ... would make it fit the actual industry
16:32:31 <kaz> kevin: elements could have class
16:32:40 <kaz> ... each element has a unique ID
16:32:47 <kaz> ... JQuery-like approach
16:33:21 <kaz> ... class based on the ID
16:33:35 <kaz> ... could be very powerful
16:34:11 <kaz> rudi: good to have a philosophy on the data model
16:34:36 <kaz> ... very powerful and flexible way
16:35:01 <kaz> kevin: implicit knowledge for understanding
16:35:24 <kaz> rudi: discussion internally
16:35:57 <junichi-hashimoto_> junichi-hashimoto_ has joined #auto
16:35:57 <kaz> ... perfect topic to discuss in Portland
16:36:21 <kaz> peter: we briefly mentioned the f2f
16:37:04 <kaz> ... many people will come to Portland
16:37:38 <kaz> -> https://www.w3.org/2002/09/wbs/1/auto201607/results registration results
16:38:04 <kaz> kevin: would get the conclusion within a few days
16:39:19 <kaz> peter: don't have any more questions
16:39:29 <kaz> rudi: strawman initial agenda on the wiki
16:39:45 <kaz> ... feel free to add topics
16:41:09 <kaz> kevin: Security and Privacy section
16:41:19 <kaz> ... open to criticism
16:41:53 <kaz> ... suggestion is having 2 levels
16:43:09 <kaz> ... one security principle is "User"
16:43:20 <kaz> ... another is "Device"
16:43:42 <kaz> s/2 levels/2 principles/
16:44:20 <kaz> ... and suggestions on each security principal
16:44:41 <kaz> s/principle/principal/g
16:45:30 <kaz> ... obtaining and renewing security tokens
16:47:18 <kaz> ... examples of token values
16:47:39 <kaz> ... User: Authorization
16:47:46 <kaz> ... Device: WWW-Vehicle-Device
16:48:47 <kaz> ... Use of Encryption
16:49:18 <kaz> ... signals are encrypted between the client and the server
16:51:21 <kaz> ... Token Renewal
16:51:41 <kaz> ... each security token will have a particular lifetime
16:52:46 <kaz> ... Error Handling
16:53:03 <kaz> ... 401: Unauthorized (token expired)
16:53:43 <kaz> ... got Song Li's comments by email
16:54:13 <kaz> ... TODO: Discuss requesting IANA reserves HTTP error number 461 (vehicle/device unauthorised) and 463 (vehicle/device forbidden)
16:54:57 <kaz> ... TODO: Add table with list of error codes
16:55:52 <kaz> rudi: need to see formal granularity
16:56:47 <kaz> ... if I have authority to access data, need to have some certificate
16:57:15 <kaz> ... what kind of signal would it be?
16:57:59 <kaz> kevin: need to achieve
16:58:22 <kaz> ... make sure it could be applied to different implementation
16:58:31 <kaz> s/implementation/implementations/
16:58:48 <kaz> rudi: balance between the spec and interoperability
16:59:24 <kaz> ... have to be specific enough but can't specify too much details
16:59:30 <kaz> kevin: agree
16:59:50 <kaz> junichi: what if the network is unreachable?
17:00:05 <kaz> ... in that case, we can't talk with external servers
17:00:13 <kaz> ... so can't get certificates
17:00:25 <kaz> kevin: that's possible
17:00:38 <kaz> ... but could have hardware chip on the vehicle
17:00:43 <kaz> ... don't have to go out
17:01:23 <kaz> s/certificates/security tokens/
17:01:32 <kaz> rudi: need to leave now
17:01:42 <kaz> peter: different questions
17:01:48 <kaz> ... looking VSS
17:01:54 <kaz> s/VSS/at VSS/
17:02:10 <kaz> ... W3C should look into it?
17:03:02 <kaz> ... thought something we might need to consider
17:03:11 <kaz> s/into it/into the license/
17:03:22 <kaz> rudi: should not be a show stopper
17:03:28 <kaz> ted: will take a look
17:03:38 <kaz> rudi: leaving
17:04:16 <kaz> peter: anything else to discuss today, Kevin?
17:04:17 <kaz> kevin: no
17:05:35 <kaz> topic: WG charter update
17:05:56 <kaz> kaz: Ted brought the extension to W3M and got approval for 3-month extension
17:06:21 <kaz> ... now we should update the charter with the new deliveralbles including the service interface
17:06:44 <kaz> ... each TF moderator and editor is encouraged to generate bullet points on their work
17:06:55 <kaz> junichi: new deadline is the end of Sep?
17:06:57 <kaz> kaz: yes
17:07:55 <kaz> kevin: good feedback from Rudi and Powell
17:08:09 <kaz> ... request for server and response to client
17:08:20 <kaz> ... timestamp for responses
17:08:55 <kaz> ... we'll go through and finish the changes
17:09:06 <kaz> peter: tx
17:09:16 <kaz> ... will also continue to look at the spec
17:09:28 <kaz> ... need to discuss what data we should use
17:09:52 <kaz> ... ACCESS, etc., have implementation of the current vehicle spec
17:10:37 <kaz> urata: about this service spec, the discussion makes sense to me
17:11:05 <kaz> ... which request corresponds to which response
17:11:11 <kaz> ... timestamp would be useful
17:11:22 <kaz> ... those discussions make sense
17:12:38 <kaz> kaz: maybe we need some kind of session id as well?
17:12:41 <kaz> kevin: possibly
17:12:58 <kaz> ... the whole websockets will be used by a single instance
17:14:07 <kaz> ... using natural request/response pair
17:14:46 <kaz> kevin: some sequence diagram might be useful
17:15:42 <kaz> peter: the server might keep different sessions at once
17:16:30 <kaz> ... the client can open more than one connections
17:18:09 <kaz> s/... the/kevin: the/
17:19:37 <kaz> kaz: we should generate some Use Case descriptions, scenarios and then sequence diagrams
17:19:44 <kaz> peter: would be useful
17:20:04 <kaz> urata: difficult to follow the discussion by emails
17:20:19 <kaz> ... maybe we can use GitHub issues, can't we?
17:20:25 <kaz> peter: ok
17:20:34 <kaz> adam: we can raise issues
17:21:05 <kaz> kaz: do you have any images/issues to be added?
17:21:40 <kaz> urata: getting clear images for this service spec but want to record the discussion clearly
17:22:10 <kaz> kevin: will bring the discussion to the GitHub from now on
17:22:15 <kaz> urata: tx
17:22:40 <kaz> kevin: Adam and I are working on some implementation
17:23:14 <kaz> peter: would polish up before the f2f
17:23:48 <kaz> s/would polish/also have one and would polish it/
17:24:20 <kaz> kaz: you mean implementations of this service interface?
17:24:37 <kaz> kevin+peter: yes
17:26:23 <kaz> [ adjourned ]
17:26:29 <kaz> rrsagent, make log public
17:26:34 <kaz> rrsagent, draft minutes
17:26:34 <RRSAgent> I have made the request to generate http://www.w3.org/2016/06/21-auto-minutes.html kaz
17:28:21 <kaz> Chair: Peter
17:28:22 <kaz> rrsagent, draft minutes
17:28:22 <RRSAgent> I have made the request to generate http://www.w3.org/2016/06/21-auto-minutes.html kaz