15:30:20 RRSAgent has joined #auto 15:30:20 logging to http://www.w3.org/2017/06/20-auto-irc 15:30:22 RRSAgent, make logs public 15:30:22 Zakim has joined #auto 15:30:24 Zakim, this will be 15:30:24 I don't understand 'this will be', trackbot 15:30:25 Meeting: Automotive Working Group Teleconference 15:30:25 Date: 20 June 2017 15:56:47 urata has joined #auto 15:59:52 Present+ Peter, Rudi, Ted, Gunnar, Urata 16:01:05 Present+ Mike 16:02:31 mike has joined #auto 16:02:46 Present+ John 16:03:15 Present+ Adam 16:03:55 Present+ Song 16:04:25 AdamC has joined #auto 16:05:10 Agenda+ Spec status 16:05:23 Apgenda+ Github repositories 16:05:32 Agenda+ Github repositories 16:06:47 zakim, next agendum 16:06:47 agendum 1. "Spec status" taken up [from ted] 16:07:24 Adam: you may have seen the latest rawgit version of the spec 16:07:40 http://rawgit.com/w3c/automotive/gh-pages/vehicle_data/vehicle_information_service.html#dfn-authorizesuccessresponse 16:07:42 … we have introduced tables to go along JSON now instead of WebIDL 16:08:09 peterw has joined #auto 16:08:11 … it is a more readable format. some others need to be put in table still 16:08:18 gunnarx has joined #auto 16:08:57 … eg AuthorizeRequest 16:09:50 … there is an open issue on preference for discover instead of getVSS in case there are additional data 16:09:52 https://github.com/w3c/automotive/issues/210 16:10:26 … we are considering getMetadata which Rudi found a bit too generic but didn't object 16:10:49 s/getMetadata/discover/ 16:11:08 s/but didn't object/and settling on getMetadata/ 16:11:32 Adam: we are continuing to discuss the nuances of * wildcard 16:11:54 … we are leaning toward single set 16:12:12 Rudi: don't we return the status of the signals in the response? 16:12:20 Adam: no we don't 16:12:34 … this would allow us to give an error for each case 16:12:50 https://github.com/w3c/automotive/issues/142 16:13:10 Rudi: we do want to know clearly what happens on write 16:14:16 Gunnar: is this multiple responses when you are doing a single wildcard set? 16:15:04 John: we do similar to pump nozzles at service stations. for example we are unsure whether to enable diesel or regular nozzles 16:15:34 … we enable all for that pump as we don't know yet. any nozzle that doesn't work will get an error code response 16:15:57 … similarly if one door isn't lockable you should get a response informing you that 16:16:04 Adam: that is definitely sensible 16:16:21 agenda+ Web Payments TF update 16:17:34 Rudi: maybe the best way is for each object to give a response 16:18:32 John: we name each nozzle to make it distinguishable and you should be informative instead of merely using a sequential number 16:19:37 Rudi: one response with array of objects. an overall status is easier 200 OK 16:20:05 Adam: I'm concerned about adding complexity and wonder if it might be better to turn it into separate requests 16:20:44 Rudi: one request with a wildcard, you get a status code on the request and json for the affected objects 16:21:00 … if there is an error than client can try again or examine json 16:21:17 Present+ Kevin 16:21:29 Kevin: question is where to put the complexity, server or client 16:21:59 … you could make it the servers responsibility to support requests for many things and detailed information can clarify which error for what item 16:22:43 … alternately an OK (meaning all were successful) and another indicating an error occured and then the client has to deduce which failed or retry 16:23:19 … we are not doing transactional state and reverting all on a single failure 16:24:33 John: some but not all times you need to know which failed and then can query which 16:25:50 … for service stations 99% all succeed and in the 1% you query further to find out individual state 16:26:18 … this is the most efficient approach for the developer 16:27:40 Rudi: true these tend to be reliable and things tend to succeed 16:28:46 Gunnar: I agree we should optimize for the success case 16:29:33 … can I distinguish partial success versus other types of errors such as a poorly formed request 16:29:43 Adam: yes we have various types of error responses 16:29:50 Gunnar: makes sense to me 16:32:59 https://github.com/w3c/automotive/issues/132 16:34:25 Adam: getVSS should return information about all signals available regardless of acls. client should know what signals it needs and would like to access via get/set and be refused if it asks for others 16:34:38 … private branch should remain separate 16:35:09 agreement with Adam on his interpretation on expected behavior 16:35:34 https://github.com/w3c/automotive/issues/91 16:35:46 Adam: Kevin has a diagram for this one that will be circulated shortly 16:36:23 … can someone elaborate on token replay concern 16:36:27 [[Provide comment about application level tokens, and protection against replays/spoofing of tokens]] 16:37:03 Adam: timestamps have been added 16:38:18 Kevin: the channel is encrypted and shouldn't be sniffable. if someone got control of the client then yes they have access to the token 16:38:46 … I'll work on improving the wording there 16:40:34 Adam: state level diagram is a work in progress 16:40:44 Kevin: done as about 5 minutes ago, just needs review 16:41:46 Adam: we believe the best approach is the client acts responsibly and can make the request as often as it wants 16:43:59 Ted: it isn't like we are opening up the car to the world, limited number of client (apps on the car) 16:44:33 … same as how people combat excessive traffic on the web, a server implementation can block an excessive client 16:44:46 Kevin: we have an error code for this case 16:44:59 … we might want to make it more explicit 16:45:27 peterw has joined #auto 16:45:34 Adam: we only mention this in the filtering section 16:46:11 Kevin: so it's in there but not enough explanation 16:47:32 Ted: probably sufficient as is 16:47:51 Topic: VIAS 16:48:55 Kevin: with vacations we expect to be done with these within 3 weeks 16:50:43 Ted: Gunnar, what would be the best venue to promote our specs and get feedback? 16:51:02 Gunnar: genivi-projects list seems the most appropriate 16:51:27 Ted: I'll subscribe and post a publication announcement 16:52:08 Urata: thank you for the advice comments and publishing the WD for VIAS 16:52:23 … it is kind of in a static status 16:53:05 … I recently noticed some small mistakes and corrected them and made issues for them 16:54:02 … regarding getVSS there was an inconsistency with respect to handling path compared to VISS 16:54:24 … I started to create a prototype of VIAS 16:54:55 … I am wondering about the next step for VIAS moving to the next stage (CR) 16:57:29 Ted: getting feedback is necessary and hopefully will be able to enlist some from Genivi, your implementation can help with our feedback requirement 16:57:51 … we also will need to work on testing for VIAS but can hopefully leverage your tests for VISS 16:58:00 Urata: Hira has a test document started 16:58:41 Ted: the corrections are merged as I don't see an outstanding PR? 16:58:44 Urata: yes 16:59:01 … issue was simple and clear and did the review myself 16:59:38 Ted: I'll go ahead and republish to www.w3.org/TR then since we can do that as frequently as we want with WD 16:59:40 agenda? 16:59:41 zakim, close this agendum 16:59:42 agendum 1 closed 16:59:42 I see 2 items remaining on the agenda; the next one is 16:59:42 2. Github repositories [from ted] 17:01:36 Ted: please see GH IPR manager email, feel free to ask questions and if necessary we can discuss at a subsequent call 17:01:48 … expect an email on launching the payments TF shortly as well 17:02:20 Peter: I hope to finish my implementation report before vacation and after we'll be done with our reference implementation 17:02:42 Urata: in your implementation are you also working on VIAS? 17:02:49 Peter: no just the server, VISS 17:03:07 Urata: I think my prototype VIAS should work with your VISS server 17:03:47 [adjourned] 17:04:05 I have made the request to generate http://www.w3.org/2017/06/20-auto-minutes.html ted