20:57:01 RRSAgent has joined #auto 20:57:01 logging to http://www.w3.org/2017/03/06-auto-irc 20:57:03 RRSAgent, make logs public 20:57:03 Zakim has joined #auto 20:57:05 Zakim, this will be 20:57:05 I don't understand 'this will be', trackbot 20:57:06 Meeting: Automotive Working Group Teleconference 20:57:06 Date: 06 March 2017 20:57:12 scribenick: ted 20:57:20 scribe: Ted 20:57:24 chair: Paul 20:57:26 Present+ Ted 20:57:46 Present+ Paul, PatrickLue, Rudi 21:00:57 fulup-iotbzh has joined #auto 21:01:07 AdamC has joined #auto 21:02:04 PatrickB has joined #auto 21:04:11 Present+ Adam 21:04:46 Present+ PatrickB 21:05:04 Present+ Fulup 21:05:52 Paul: last week we discussed where we are trying to go with these discussions 21:06:19 … the outcome is for the TF to come up with a recommendation to the WG for a next generation of specification 21:06:34 … it is more of a next round than a next generation 21:07:10 … last week PatrickB gave us a tour of their approach to media and how it compares to the various spotify, iheart, etc 21:11:33 … we previously stated the timeline of trying to have this ready before F2F 21:12:03 Ted: @@rambles on broad strokes and then granular on signals including backwards compatibility 21:12:25 hira has joined #auto 21:12:27 Fulup: there are some elements that can be used across interfaces such as authentication schema 21:13:05 … the lower level we try to go the harder it would be for normalization 21:13:34 … from an AGL point of view we need to go the full spectrum from lower level signals to developer applications 21:13:44 … same for music, weather, etc 21:14:08 … I have to propose something to AGL for this year's implementation 21:14:27 Rudi: as far as the signals are concerned there is W3C's VISS 21:14:56 Fulup: I presented this strategy to different people and not convinced I can get adoption 21:15:17 … whereas I see ViWi as easier 21:16:21 … problem will be big tree on the signals 21:16:42 Rudi: you can implement branches. it doesn't mean a vehicle has to expose all those signals 21:16:56 … ViWi is similar with end points 21:17:20 Fulup: I do not think that is an issue. we are not going to change how we handle signals but can map 21:17:56 Rudi: VISS has a pretty structured way of doing this, it is meant as a replacement to a fat API 21:18:21 … you do not want to have to constantly revise the specification when new signals are added. this allows them to move forward separately 21:18:47 … hopefully there will a core subset of signals that we will see widely exposed over time 21:18:57 … there will be signals that some oems will want to keep private 21:19:11 Fulup: we have separated high level and low level signal 21:19:58 Rudi: how the signals in the tree are handled by underlying system is up to implementers 21:20:52 … as far as moving foward we are continuing with VISS and need to discuss the next generation 21:21:58 … we have agreed on using web sockets for this version with discussion on the pros and cons of http or web sockets. the next version would likely be both 21:22:44 Fulup: ok with either transport. is there a reference implementation? 21:24:11 Rudi: I think four, Access, Mitsubishi, Inrix, ETRI+OCF 21:24:21 Paul: Inrix doesn't have an implementation 21:24:28 Fulup: any of them open source? 21:24:41 Paul: I think Peter's (Melco) is 21:25:08 [also I think Vin.li plans to, they demoed at Genivi CES showcase] 21:25:20 Paul: Newsky has one 21:25:41 Paul has joined #auto 21:25:41 Ted: done with Baidu 21:25:47 https://github.com/newskysecurity/vswss 21:25:53 https://github.com/PeterWinzell/vehicle-carsignal-examples 21:26:00 https://github.com/aShinjiroUrata/vehicle-signal-server-spec/commits/master 21:26:56 Paul: I will work on a proposal along the lines of what Ted described, broad strokes 21:27:07 rstreif has joined #auto 21:27:34 Adam: does this mean everything is back on the table including data model and auth mechanism? 21:27:48 Shift of Luck look like no C/C++ reference implementation 21:28:06 Paul: I think so. Fulup had some input on security 21:28:48 Rudi: I hope it is more enhancing and extending than starting over completely 21:29:00 Paul: agree 21:33:35 [discussion of keeping the more technical specifics out of a general proposal for how to go forward. what to leverage from one, the other or an alternate approach would be in WG after general proposal is accepted] 21:33:51 [benefits of keeping signals' data model separate from the spec] 21:34:18 Fulup: you have variation in media as well 21:34:31 Rudi: we can agree on a higher level abstraction layer 21:35:16 Fulup: if you do not fulfill the media services' criteria for ip concerns you won't get the data (music) 21:38:59 Paul: I would like to see us to look at the next most useful domain, media and poi 21:39:11 … they may bring up additional security or digital rights issues 21:39:41 … access models should try to be similar 21:39:59 … I would like to see something like VISS or ViWi get adopted 21:40:31 … then when you know you are on a Genivi, AGL or other platform that implements it you know what is available 21:40:40 … we allow for extensions on signals 21:41:30 … this will allow app developers and integraters to operate independently 21:42:10 Rudi: let's tackle the next domains 21:42:17 … explore their use cases 21:44:53 Fulup: I need to know something works before I can propose it 21:45:30 Paul: by April we are suppose to have a Candidate Recommendation with test cases 21:46:46 https://www.w3.org/2014/automotive/charter-2016.html#deliverables 21:48:13 Fulup: I presented AGL's signal recently. we're pretty far along including test cases and benchmarking and that takes quite a bit of time 21:48:44 … we are going to continue monitoring this and may implement 21:50:11 … if any of the implementations were open source and in C then it would be easier 21:50:40 Ted: we do not require implementations be open source, only proof it is implementable by 2 parties along with a test case 21:51:17 … in AGL's case I think you wouldn't be able to take an implementation as is, you'll be doing more of a mapping 21:51:52 Rudi: it may be a little too early to look for a reference implementation 21:53:42 Paul: I agree it is desireable to know something will work before adopting 21:54:01 … we need to provide specifications, tests and encourage implementations 21:54:39 Rudi: let's use the wiki as the platform for drafting a proposal 21:55:52 PatrickB: we built our protocol first and as general as possible before designing the domains 21:57:07 … it would be good to get LG input on their implementation. not sure they are the same people at Birlingame who implemented 21:57:30 PatrickL: they are 21:57:50 Paul: I believe they are still part of the group 21:58:07 Ted: they are and we should encourage them to attend some calls 21:58:21 Paul: we should reach out to them 22:00:21 https://www.w3.org/community/autowebplatform/wiki/2g 22:01:58 Page for proposal. Anyone participating on these calls is welcome to contribute. We can see by revision history who suggested what