IRC log of auto on 2016-06-21
Timestamps are in UTC.
- 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