Re: Standardized endpoint name for VISS (was: Re: Request to make the issue list for VISS)

On Tue, 2017-09-12 at 10:46 +0200, Gunnar Andersson wrote:
> On Tue, 2017-09-12 at 09:23 +0100, Gavigan, Kevin wrote:
> > Hi Gunnar,
> > 
> > Thanks, you raise and make some very pertinent points.
> 
> OK, good.  I was hoping someone would go through each of them and
> just
> confirm that what I said was true, so far.  Because this is a process
> to
> lead to a conclusion.  But I suppose maybe you agreed now,
> implicitly?
> 
> > 
> > Suggest that another important point is:  What if an OEM wants to
> > install
> > two or more VIS Servers on the same vehicle network.
> 
> Yes even name resolution of a single well known name would not solve
> that. 
> You'd have to either have a discovery protocol of some sort (and then
> zeroconf comes to mind -- yes I now saw the feedback Ted relayed,
> mentioning
> mDNS, which is the same thing IIRC?)

mDNS is one type of zeroconf and from the Wikipedia article it seems
many have various flaws or hesitations from some in the IETF.

https://en.wikipedia.org/wiki/Zero-configuration_networking#Name_service_discovery

I was operating under the assumption there would be one signals service
not multiple although understand based on the scenario you painted
there may be more than one.

For the other "domains" (eg media, LBS, notifications) the services may
reside on other hosts on the local network and we should take that into
mind as well.

I have a few possible concerns for broadcast/discovery of a zeroconf
solution and not sure how founded they are. This could possibly 
introduce latency. It would be worth benchmarking to quantify. Other
devices allowed on the LAN broadcasting responses to setup a MiTM,
impersonation or other type of attack. That may be mitigated with the
self signed certs already distributed to client applications. Lastly
and most importantly, the likelihood that mDNS (or whatever zeroconf we
consider) is implemented on our target platforms for head units and any
client devices such as smartphones that might be permitted to connect.

> Or you would leave that up to OEM-specific configuration that is
> somehow
> passed from system to "app" when the app is launched.  
> 
> I think there's a limit to how far you will be able to here specify
> the
> exact application standard, which includes APIs like that between OS
> (or
> "application manager") and app.  But a single well-known name might
> be
> useful still.
> 
> In fact... come to think of it - is this thing perhaps better defined
> in a
> different specification, one which specifies an (automotive) web
> application
> standard, rather than in the server specification?
> 
> > 
> > For example, the designers of the instrument cluster might decide
> > to
> > implement the VISS specification and install a VIS Server in the
> > cluster
> > in order to get vehicle speed, engine rpm, fuel levels etc and
> > display
> > them to the user.
> 
> That's why I asked.  Is this assuming a local server, or a server
> "anywhere".  Is it simply intended to be a well-known name to address
> the
> *default* VIS server, wherever that exists in the entire routable
> (inter)net.
> 
> > 
> > Almost in parallel, the designers of the new Infotainment System
> > decide to
> > implement the VISS specification and add a VIS Server to the
> > electronic
> > control unit (ECU) that hosts the Infotainment System.
> > 
> > Does anyone on the thread have views on how best to address this -
> > or
> > should we remove references to wwwivi and state that implementors
> > will
> > document how to connect to the VIS Server

I think it should be either defined as much as hardcoding something
seems wrong or discoverable or a hybrid. In the absence of mDNS (or
whatever discovery is selected) response a client could try to fallback
to a predefined host, wwwivi.local

Otherwise we will need to devise a way for client apps to get
configuration. When they're installed on the head unit that is
relatively easy. If we permit devices to connect and run apps against
this service, that is more complicated.

> I still think you might be doing something useful if the
> specification
> requires (or perhaps recommends?) a well-known name for the default
> server. 
> But I'm trying to really get to the root characteristics of what that
> thing
> is supposed to mean, before forming a final opinion.
> 
> Thanks
> - Gunnar
> 
> 
> > 
> 
> -- 
> Gunnar Andersson <gandersson@genivi.org>
> Development Lead
> GENIVI Alliance
> 
> 
> 
> 
-- 
Ted Guild <ted@w3.org>
W3C Systems Team
http://www.w3.org