18:57:50 RRSAgent has joined #auto 18:57:50 logging to https://www.w3.org/2021/02/16-auto-irc 18:57:52 RRSAgent, make logs Public 18:57:53 scribenick: ted 18:57:54 Meeting: Automotive Working Group Teleconference 18:57:58 Scribe: Ted 18:58:01 Chair: Peter 18:58:33 Chair: Ted 18:58:48 Agenda+ CVII summit on Thursday 18:58:58 agenda+ Issue review 18:59:28 zakim, drop agendum 2 18:59:28 agendum 2, Issue review, dropped 18:59:48 agenda+ VISSv2 over MQTT proposal 18:59:51 agenda+ Issue review 18:59:57 regrets+ MagnusF, Peter 18:59:59 Present+ Ted 19:01:18 [VSS/VSSo call running over] 19:02:11 Present+ Ulf, Arman 19:02:29 Present+ MagnusG 19:02:38 Present+ Isaac 19:03:40 Present+ Gunnar 19:04:45 Present+ Glenn 19:05:22 Present+ Adnan 19:07:40 zakim, next agendum 19:07:40 agendum 1 -- CVII summit on Thursday -- taken up [from ted] 19:07:58 Ted gives high level summary of agenda 19:08:44 zakim, next agendum 19:08:44 agendum 3 -- VISSv2 over MQTT proposal -- taken up [from ted] 19:10:20 Ulf: we have been giving thought about how we can operate on both end of broker 19:10:33 [Ulf shares screen, presents diagram] 19:10:54 Ulf: in this diagram we have a client in vehicle and other external 19:11:24 … currently in the code we have transport managers for WS and HTTP, they register into the server core 19:11:40 … they open up data channel (WS, all of them) 19:12:07 … so it was easy to implement a new transport manager and get it to communicate 19:12:31 … we got quite a bit for free 19:12:54 … this vehicle client is a tranport manager to prove concept works 19:13:56 … MQTT starts with issuance of token request. a unique identifier is needed, currently using vin but may be better as something else 19:14:49 … we have a cloud client that knows it wants to send VISSv2 requests to server on the other side, starts subscribing to a uuid 19:15:40 … next it does a publish to topic it subscribed to. vinXX cannot be found in a session, needs to be transmitted out of band 19:15:53 … it could originate from oem backend 19:16:16 … payload is two parts. information about domain of the topic and actual request it wants to send 19:16:32 … it is a JSON payload 19:17:06 … topic and request parts. v2 valid payload is sent via WS 19:17:17 @@link_diagram 19:17:43 … topic and request parts are forwarded to server which views it as any normal request 19:18:05 … it gets, processes and returns response 19:19:14 … response is published back, topic is in the payload. broker then pushes it back to subscribed cloud client 19:20:04 … this can support the entire range of requests available in v2 19:22:35 … so the experiment works, question is do we want to put this in the transport document 19:24:19 Ted wonders how much Peter (regrets for today) was involved as he knows MQTT better than I 19:24:32 Ulf: he was partially involved 19:25:14 … one thing we benefit from is client broker 19:26:08 … open question about security aspects of using a broker 19:26:35 Gunnar: connection starts on vehicle side 19:26:46 … not sure if it is crazy or genius 19:26:50 Ted: its a fine line... 19:28:17 Gunnar: did you implement the vehicle client as a separate process or part of the server? 19:28:27 Ulf: it is its own program running 19:28:39 … based on the HTTP code 19:28:55 Gunnar: instead of a client, it would be better termed as a proxy 19:29:24 … you are embedding VISS over MQTT more than using MQTT 19:29:29 Ulf: correct 19:33:58 Ted wonders if anyone else on the call has extensive experience with MQTT, this can be architected a number of ways 19:34:06 @@v2 coniustency 19:34:25 Adnan: MQTT is being used by a number of companies, we are 19:34:38 … what would be interesting to see is the split between the read and write parts 19:35:21 … you may want to split based on topics as well 19:35:40 … topic per client on reading. for write you could have one 19:36:51 Ulf: I need some more understanding 19:37:15 MagnusG: I haven't used MQTT myself. interesting concept being able to pair clients through a broker 19:37:44 … proxying or rather embedding VISS within MQTT is interesting 19:38:54 … nice to see how we are not tied to any particular protocol 19:39:27 Ulf: maybe we should take a week or two to reflect and discuss further 19:39:45 Glenn: would this affect the data payload size? 19:39:58 Ulf: slightly, the topic part adds a bit 19:40:25 … what is new is [on diagram] this small part 19:42:05 Gunnar: there may be room for more optimizations 19:46:16 Ted: I'll put a call out along with the minutes asking for minutes on MQTT 19:46:31 s/for minutes/for expertise/ 19:46:32 I have made the request to generate https://www.w3.org/2021/02/16-auto-minutes.html ted 19:46:34 zakim, next agendum 19:46:34 agendum 4 -- Issue review -- taken up [from ted] 19:46:53 Ulf: I have pushed some changes and already accidentally merged based on the editorial suggestions 19:47:14 … hopefully nobody objects, otherwise I would have to back it out 19:47:40 … please give it a read or wait until further changes 19:49:28 https://github.com/w3c/automotive/commit/58d789529c69c389008d952adc9f267fc56547e4 19:50:04 Ted: service discovery moved? 19:50:10 Ulf: folded into filtering 19:50:11 https://github.com/w3c/automotive/commit/58d789529c69c389008d952adc9f267fc56547e4 19:50:52 Ulf: what is taking more time is linking to definitions 19:51:23 Ted: hold on, that may be facilitated with some ReSpec capabilities 19:52:31 https://github.com/w3c/respec/wiki/ReSpec-Editor's-Guide 19:53:14 I have made the request to generate https://www.w3.org/2021/02/16-auto-minutes.html ted 19:58:10 s/@@v2 coniustency/...we did want VISS consistent across protocols and this experiment achieves that/ 19:58:11 I have made the request to generate https://www.w3.org/2021/02/16-auto-minutes.html ted 19:58:15 Zakim has left #auto 19:58:16 I see no action items