16:01:04 <RRSAgent> RRSAgent has joined #auto
16:01:04 <RRSAgent> logging to http://www.w3.org/2017/10/17-auto-irc
16:01:06 <trackbot> RRSAgent, make logs public
16:01:06 <Zakim> Zakim has joined #auto
16:01:08 <trackbot> Meeting: Automotive Working Group Teleconference
16:01:08 <trackbot> Date: 17 October 2017
16:02:23 <urata> urata has joined #auto
16:04:19 <AdamC> AdamC has joined #auto
16:04:34 <ted> Present+ Ted, Mike, Rudi, John, Magnus, Urata, Adam
16:05:35 <ted> agenda+ wwwivi
16:06:00 <ted> agenda+ TPAC agenda
16:07:13 <ted> zakim, next agendum
16:07:13 <Zakim> agendum 1. "wwwivi" taken up [from ted]
16:07:16 <ted> https://github.com/w3c/automotive/issues/223
16:07:56 <ted> Ted provides
16:07:58 <ted> summary
16:08:22 <ted> Present+ Gunnar
16:12:03 <KevG> KevG has joined #auto
16:12:49 <ted> Ted: we should conclude to go with zeroconf/discovery of eg mdns. question is would a static fallback be acceptible
16:13:41 <ted> Gunnar: viss.local was my suggestion. what is the actual mechanism being considered
16:15:10 <ted> Ted: issue I have with discovery is requiring each application to have to go through that process each time
16:15:35 <ted> … doesn't make sense for head unit for a given vehicle since there shouldn't be change, need to rediscover
16:15:44 <ted> Gunnar: @@
16:16:20 <ted> Mike: wouldn't this only apply when the service is running on a separate virtual host, would it often be localhost
16:16:37 <ted> … I understand we may support more than one VISS server within a vehicle
16:17:32 <ted> … it makes no sense to do discovery when it is on the same host
16:17:41 <ted> Ted: agree but that isn't necessarily the case
16:18:15 <ted> Mike: you could say in the specification that if you are allowed multiple a good naming convention would help
16:19:09 <ted> … I have been playing with mdns some. there is filtering capabilities
16:19:25 <ted> … we may want different names for the different roles
16:19:55 <ted> Gunnar: I am a bit reluctant towards that idea. how would you define a future IVI system with a different purpose later
16:20:06 <ted> Mike: that was more of an example than a real suggestion
16:20:42 <KevG> Also, we would need to allow others to use ivi as a term hence wwwiviv.local
16:20:44 <ted> Gunnar: you did bring up a good point, multiple nodes might be answering which we want to address
16:20:45 <ted> q+
16:20:58 <KevG> Sorry mistyped, meant wwwivi.local
16:21:13 <KevG> or w3civi.local
16:21:30 <ted> Gunnar: preference might be for a local one before going out to the network
16:24:38 <ted> Ted: one idea is zeroconf discovery takes place during app install and generates a static conf
16:25:00 <ted> John: we had similar problem with IFSF, you don't want to reboot a service station
16:25:28 <ted> … we sit on a given port and broadcast (UDP) the other devices pick it up and use it
16:25:35 <ted> … we didn't want all the discovery effort
16:26:50 <ted> Ted: yes similar here
16:27:20 <ted> Mike: BLE (bluetooth beacon) is being supported by MS for parking meters
16:27:43 <ted> [we are consider BLE for fueling see https://github.com/w3c/automotive-pay/wiki/PayAtPumpExplainer]
16:29:25 <Magnus> Magnus has joined #auto
16:29:28 <ted> Ted: for discovery I can also imagine a rogue device advertising itself as providing VISS and mitm the real service, steak tokens etc
16:30:20 <ted> Mike: application on smartphone is a bit different, it can also be involved in making payments. tollgate can talk to RFID reader which can talk to mobile phone
16:33:32 <ted> Ted: back to the specifics of wwwivi. What I am hearing from the W3C TAG and IETF (indirectly, there is overlap) is static is short sighted and we should do discovery
16:33:44 <ted> … we have issues 123@@ as a result
16:34:36 <ted> Kevin: parts of the vehicle rarely if ever shutdown so it is possible to keep some continuity
16:35:34 <ted> … manufacturers might want services on the vehicle to remain available overnight for eg SOTA updates
16:36:40 <ted> … often things will disappear off the network when the car is powered down. we might want some to persist to prevent rediscovery
16:37:17 <ted> Gunnar: I think we may be overthinking this a bit too much
16:37:31 <ted> … if you can discover the service at the first boot you can on subsequent
16:37:55 <ted> … there are some key issues here such as the security concern mentioned and included in the spec
16:38:12 <ted> … in the end we are just doing name->IP recognition
16:38:42 <ted> … simplest solution is eg an /etc/hosts entry
16:38:54 <ted> Kevin: it is a bit more complex than that
16:39:18 <ted> … on a linux based system you could have localhost and specific port number
16:39:53 <ted> … you can have other hosts that wish to connect
16:40:23 <ted> Rudi: it seems we are going around in circles. perhaps we can start simple and revisit when necessary
16:40:49 <ted> … we can think of a more elegant solution later
16:42:18 <ted> Ted: I did like the initial keep it simple approach for WD, I am hearing we may be blocked going to CR if we don't do discovery
16:42:36 <ted> Gunnar: we can have a tiered solution, local, local network at given name, discovery service
16:43:02 <ted> … choice can be left to the implementer
16:43:23 <ted> Rudi: we have to be consistent for sake of the app developer, simplest is a defined hostname
16:44:17 <ted> … I appreciate the merits of zeroconf but hesitant to prescribe a solution
16:45:39 <ted> Magnus: why can't we support both? static and discovery
16:45:59 <ted> Gunnar: I would agree with that and Rudi that we don't need to write that chapter in a first version of this spec
16:46:07 <ted> Ted: I can ask
16:46:57 <ted> Magnus: we could have this discovery described in the spec but also the simple static