Re: Attempting to achieve consensus re. wwwivi issue (#223)

Thank you Gunnar, some responses in-line.

What I think would help would be to have a better understanding on why
we might have multiple VISS and whether an application is expected to
communicate with more than one. 

We should also try to envision the OEM app marketplace. Instead of
trying to discover services for a given vehicle platform, the
marketplace could provide configuration for that year, make and model
on which service[s] a specific app is expected to interact with. This
is what I meant earlier by provisioning.

On Mon, 2017-10-23 at 12:18 +0200, Gunnar Andersson wrote:
> On Sat, 2017-10-21 at 12:24 +0000, Peter Winzell wrote:
> > I have consensus :). I completely agree with Kevin. Oems will
> > follow and
> > make their own choices and I think that there is high probability
> > that if
> > we specify a server name - whatever it might be - it will never be
> > used. 
> 
> I wouldn't go that far.
> 
> First, it would be a recommendation, in my opinion.
> 
> Second I think standards do help, because in communication an OEM can
> then
> say "just follow the standard as written in chapter 5.6".  And some
> will do
> that.  It's not bad to have a default, and then if OEMs want to do
> something
> different, they specify that separately.
> 
> I may have missed if it was given in discussions - if so could
> someone
> repeat for me the rationale for including "ivi" in the name?  The
> specification isn't written to be IVI specific, is it?   I think if
> the key
> point is that it is a "local" server on the same computing unit as
> the
> application making the request, just indicate that.

I'm not sure who proposed wwwivi initially but agree ivi in the name is
limiting. This service can be used by the dashboard, IVI, may be useful
for things like ADAS and RVI, data sampling for V2X or insurance. and
have apps connect from smartphones, tablets and other devices in the
vehicle.

> Why not simply "viss"?   If it's a W3 subdomain, how about viss.w3 or
> visslocal.w3... assuming it is the _recommended_ name for a locally
> hosted
> server?  (A simple poll would probably resolve the naming question)

I like viss better but since VISS is to be followed shortly by RSI
maybe something appropriate for either.

Today's schedule got jumbled with others' meetings and my attempt to
get time on decision from W3C regarding a hostname is pending.

> Finally, I agree with where the discussion was going last time:
> 
> First, these are separate things:
> 
> 1) Chapter describing a recommended fixed name for a local VISS
> server, (and
> that the underlying system will likely translate it with a static IP
> mapping).
> 
> 2) Chapter describing the recommended local service name and the
> usage of
> mDNS discovery.  Including an impmlementation note to take great care
> of
> security issues, spoofing in particular.
> 
> Second, the specification could include either one, two, or none of
> these
> chapters.  They could also be added at a later time.  
> 
> My vote would be to include chapter 1 now and a single sentence about
> mDNS
> discovery.  A separate instruction could be created to describe how
> to
> implement mDNS in this context.

Until we understand the ramifications that would make sense.

> More below.
> 
> > 
> > lör 21 okt. 2017 kl. 04:26 skrev Gavigan, Kevin <kgavigan@jaguarlan
> > drover.
> > com>:
> > > Hi Ted and Rudi,
> > > 
> > > Thanks very much for your feedback - I guess we don't quite yet
> > > have
> > > consensus :-)
> > > 
> > > [From Rudi:]
> > > If I recall correctly we discussed a w3.org subdomain before. I
> > > am not
> > > sure why it got discarded at the time. However, I am strongly in
> > > favor
> > > of it. Let's move ahead with an Editors Draft with
> > > a w3.org subdomain/hostname.
> 
> When everyone feels they have made their arguments, create a poll on
> the
> name.  Also, getting some informal approval of the final proposal in
> the
> wider W3C community is an important part in my opinion.  I see little
> that
> must be unique to Automotive in the fundamental parts of this.

Makes sense. I have no strong preference personally.

> > > [From Ted]
> > > Since there are cases that may have multiple VISS implementations
> > > in the
> > > same network, or have client devices introduced, discovery is
> > > needed. 
> 
> That's one driver, but not the only one.  For me it would be more
> that it's
> the existing generic solution to discover a service if it's unknown
> where it
> is.   I wonder how realistically useful it is especially for multiple
> servers.  In a particular car it seems kind of unlikely to me that
> the
> applications will (or even should) know what to do, if a lookup
> yields
> multiple VISS servers responding.  It opens up for a whole bunch of
> rules/policies that need to be there - which server do they choose to
> communicate with?  Try one, if it fails, try the next?  It just seems
> to be
> a whole other level of policy definition that this specification
> should
> probably not venture into.  It seems more likely to me that a
> particular
> application standard will provide a single (local) source of contact
> - if a
> more advanced system is needed, this could be funneled through a
> server
> acting as a proxy even.
> 
> The end result for me is that a particular system will often fall
> back onto
> system-specific rules anyway (which means that specification could
> even
> include things like the name of the default server).
> 
> > > I have the impression the TAG will block us if we do not have it
> > > and
> > > will accept a reasonable fallback default name that will be
> > > usable in the simpler cases (one VISS service on a fixed
> > > network).
> 
> In my opinion that may still be enough.  Beyond that it's
> implementation
> dependent.
>
> > > Are their any suggestions how we can/should move forward?
> > > Ted/Rudi is
> > > their a statement or phrase or change that we could add that
> > > achieve the
> > > objectives you've succinctly outlined?
> > > 
> > > If we can't find a technical consensus, to move forward, can we
> > > de-scope 
> > > resolving the hostname and simply state that the implementer will
> > > specify how to connect to the VISS server including how to
> > > resolve the
> > > <host_name>?
> > > 
> > > [Although not ideal - believe this isn't quite as big a practical
> > > problem as first appears: OEMs are very concerned about safety,
> > > cybersecurity and integrity of the platforms they are creating.
> > > As a
> > > consequence, I believe that in practice client software that is
> > > downloaded or included in the build for a particular OEMs
> > > platform will
> > > need to be carefully QA'd to ensure it works well on that
> > > platform, and
> > > is very likely to require some configuration information relating
> > > to the
> > > platform. So adding config info to specify how to connect to a
> > > particular VIS Server or Discovery Service would typically be in
> > > addition to other info. ]
> 
> I partly agree.  I noted before that more than anything this is
> likely part
> of some "application standard", which might be widely adopted, or OEM
> specific depending on what the industry wants.  (I have always wanted
> to
> work toward the former, but the OEMs are not clear enough on their
> desire
> there).  The scope of VISS specification isn't really an "Automotive
> Web
> Application Standard".  That would be some different specification it
> seems
> to me.  
> 
> That said, I could still see some value in W3C taking the first step
> to
> define one single recommended FQDN for the default VISS server.
> 
> > > 
> > > Keen to hear the thoughts of the group re. how to move forward...
> 
> To move forward I propose:
> 
> - Set a deadline for further arguments to be brought forward.
> - Then, list all the options for the spec.  See that we all agree on
> the
> list.
> - Conduct a poll.
> 
> I don't mean that guarantees a decision, but it's a clear step.  If
> the poll
> shows good consensus, it's easy to go ahead.  If it doesn't, perhaps
> simple-
> majority is not enough for a decision, but then I think a little more
> discussion among those that disagree will eventually lead to a
> compromise
> and consensus.
> 
> - Gunnar
> 
> 
> > > 
> > > Thanks and regards,
> > > 
> > > Kev
> 
> 
> - Gunnar
> 
> -- 
> Gunnar Andersson <gandersson@genivi.org>
> Development Lead
> GENIVI Alliance
> 
> > > 
> > > Kevin Gavigan BSc, MSc, PhD, MCP, MCTS
> > > Software Architect
> > > Connected Infotainment
> > > Electrical, Electronic and Software Engineering (EESE)
> > > Jaguar Land Rover
> > > 
> > > Mobile: 07990 084866
> > > Email: kgavigan@jaguarlandrover.com
> > > 
> > > Office address:
> > > GO03/057 • Building 523, Gaydon • Maildrop: (G03)
> > > Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35 0RR
> > > 
> > > On 21 October 2017 at 00:35, Streif, Rudolf <rstreif@partner.jagu
> > > arlandr
> > > over.com> wrote:
> > > > Thank you Kevin and Ted. I really would like to put this to
> > > > rest now
> > > > and move on.
> > > > 
> > > > If I recall correctly we discussed a w3.org subdomain before. I
> > > > am not
> > > > sure why it got discarded at the time. However, I am strongly
> > > > in favor
> > > > of it.
> > > > 
> > > > Let's move ahead with an Editors Draft with a w3.org
> > > > subdomain/hostname.
> > > > 
> > > > Thanks,
> > > > Rudi
> > > > 
> > > > On Fri, Oct 20, 2017 at 11:36 AM, Ted Guild <ted@w3.org> wrote:
> > > > > Part of the pushback on wwwivi even with .local is that it
> > > > > amounts
> > > > > to
> > > > > name squatting. We do not own .local so cannot lay claim to a
> > > > > name
> > > > > there. 
> > > > > 
> > > > > Mark Nottingham asked if we considered a w3.org hostname as
> > > > > the
> > > > > fallback with discovery still being the preferred method.
> > > > > Typically
> > > > > I
> > > > > have authority on w3.org subdomains but since it is for a
> > > > > specification, would need to get Director approval.
> > > > > 
> > > > > https://github.com/w3c/automotive/issues/233
> > > > > 
> > > > > Since there are cases that may have multiple VISS
> > > > > implementations in
> > > > > the same network, or have client devices introduced,
> > > > > discovery is
> > > > > needed. I have the impression the TAG will block us if we do
> > > > > not
> > > > > have
> > > > > it and will accept a reasonable fallback default name that
> > > > > will be
> > > > > usable in the simpler cases (one VISS service on a fixed
> > > > > network).
> > > > > 
> > > > > Discovery makes things complicated for client applications
> > > > > and may
> > > > > have
> > > > > other negative implications such as introducing ways to
> > > > > attack the
> > > > > client. These would need to be worked through. We could
> > > > > publish a
> > > > > snapshot of the Editors Draft as a Working Draft with a
> > > > > w3.org
> > > > > hostname
> > > > > (pending approval) while we figure out the discovery issues.
> > > > > 
> > > > > On Fri, 2017-10-20 at 11:15 +0100, Gavigan, Kevin wrote:
> > > > > > Hi Gents,
> > > > > > 
> > > > > > As we know, issue #223 is the only open issue for the VIS
> > > > > > Specification and it would be great if we could resolve it
> > > > > > so that
> > > > > > the Chairs could propose the the specification moves
> > > > > > forward to a
> > > > > > Candidate Recommendation.
> > > > > > 
> > > > > > I've added the text copied in blue below to the issue (as
> > > > > > part of
> > > > > > trying to achieve consensus) and would be grateful for your
> > > > > 
> > > > > feedback.
> > > > > > 
> > > > > > We have been struggling for quite a few months to get
> > > > > > agreement on
> > > > > > how to resolve the hostname (wwwivi) issue (#223).
> > > > > > 
> > > > > > Can I suggest that we resolve the impasse by saying that
> > > > > > the
> > > > > > implementer will document how the hostname is obtained, but
> > > > > 
> > > > > suggest a
> > > > > > default value for the VIS websocket server that is hosted
> > > > > > on the
> > > > > 
> > > > > IVI
> > > > > > ECU.
> > > > > > 
> > > > > > Hence, propose that we add statements like:
> > > > > > 
> > > > > > /* Start of change */
> > > > > > 
> > > > > > "A vehicle may have more than one VIS Server that can be
> > > > > > accessed
> > > > > 
> > > > > by
> > > > > > a client running on an ECU connected to the in-vehicle
> > > > > > network.
> > > > > > 
> > > > > > The implementer of a VIS Server will document how an in-
> > > > > > vehicle
> > > > > > client can obtain the hostname that is needed to connect to
> > > > > > their
> > > > > 
> > > > > VIS
> > > > > > Server instance. This could be using a Discovery Service
> > > > > > (that is
> > > > > > outside of the scope of this specification) or by
> > > > > > configuration.
> > > > > > 
> > > > > > By default, the VIS Server deployed on the In-Vehicle-
> > > > > > Infotainment
> > > > > > system will have the hostname 'ivi.w3.org.local' but the
> > > > > 
> > > > > implementer
> > > > > > may specify a different value'.
> > > > > > 
> > > > > > /* End of change */
> > > > > > 
> > > > > > 
> > > > > > We would then change our example statements to use
> > > > > 
> > > > > 'ivi.w3.org.local'
> > > > > > as hostname instead of wwwivi
> > > > > > 
> > > > > > I'm not entirely sure that adding a '.local' extension to
> > > > > > 'w3.org'
> > > > > > doesn't violate other conventions, but logically it takes
> > > > > > account
> > > > > 
> > > > > of
> > > > > > the feedback on the issue (of not cyber-squatting and
> > > > > > making clear
> > > > > > that its a local name)
> > > > > > 
> > > > > > Believe that in practice an onboard client is likely to
> > > > > > have a
> > > > > 
> > > > > config
> > > > > > file (or a Registry or similar) that can be used to define
> > > > > > the
> > > > > > runtime configuration, so if the default is not suitable or
> > > > > > is not
> > > > > > preferred, a different value can be configured prior to
> > > > > > deployment
> > > > > 
> > > > > of
> > > > > > the client OR the client could make use of a Discovery
> > > > > > Service if
> > > > > 
> > > > > the
> > > > > > implementer has stated in their documentation that this
> > > > > > will be
> > > > > > available.
> > > > > > 
> > > > > > I didn't want to tightly couple the spec. to a particular
> > > > > 
> > > > > Discovery
> > > > > > protocol or mechanism (as these could evolve separately
> > > > > > over time
> > > > > 
> > > > > and
> > > > > > couldn't think of a better compromise or route out of this
> > > > > > issue -
> > > > > > hope the group agrees to the above, but if it doesn't get
> > > > > 
> > > > > consensus,
> > > > > > very happy to consider other alternatives...
> > > > > > 
> > > > > > [Hopefully, we can settle on this (or something like it)
> > > > > > for now,
> > > > > 
> > > > > and
> > > > > > if there are strong views later about an alternative, we
> > > > > > re-open
> > > > > 
> > > > > the
> > > > > > issue at that point]
> > > > > > 
> > > > > > Thanks and regards,
> > > > > > 
> > > > > > Kev
> > > > > > 
> > > > > > Kevin Gavigan BSc, MSc, PhD, MCP, MCTS
> > > > > > Software Architect
> > > > > > Connected Infotainment
> > > > > > Electrical, Electronic and Software Engineering (EESE)
> > > > > > Jaguar Land Rover
> > > > > > 
> > > > > > Mobile: 07990 084866
> > > > > > Email: kgavigan@jaguarlandrover.com
> > > > > > 
> > > > > > Office address:
> > > > > > GO03/057 • Building 523, Gaydon • Maildrop: (G03)
> > > > > > Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35
> > > > > > 0RR
> > > > > 
> > > > > --
> > > > > Ted Guild <ted@w3.org>
> > > > > W3C Systems Team
> > > > > http://www.w3.org
> > > > 
> > > > 
> > > > 
> > > > -- 
> > > > Rudolf J Streif
> > > > System Architect - Open Source Initiative
> > > > Open Source Technology Centre
> > > > 
> > > > M: +1.619.631.5383
> > > > Email:  rstreif@partner.jaguarlandrover.com
> > > > 
> > > > 
> > > > 
> > > > UK: G/26/2 G02 Building 523, Engineering Centre, Gaydon,
> > > > Warwick, CV35
> > > > ORR
> > > > US: 1419 NW 14th Ave, Portland, OR 97209
> > > > jaguar.com | landrover.com
> > > > -------------------
> > > > Business Details:
> > > > Jaguar Land Rover Limited
> > > > Registered Office: Abbey Road, Whitley, Coventry CV3 4LF 
> > > > Registered in England No: 1672070
> > > > 
> > > > This e-mail and any attachments contain confidential
> > > > information for a
> > > > specific individual and purpose.  The information is private
> > > > and
> > > > privileged and intended solely for the use of the individual to
> > > > whom
> > > > it is addressed.  If you are not the intended recipient, please
> > > > e-mail 
> > > > us immediately.  We apologise for any inconvenience caused but
> > > > you are
> > > > hereby notified that any disclosure, copying or distribution or
> > > > the
> > > > taking of any action in reliance on the information contained
> > > > herein
> > > > is strictly prohibited.
> > > > 
> > > > This e-mail does not constitute an order for goods or services
> > > > unless
> > > > accompanied by an official purchase order.
> > > > 
> > > > 
> > > 
> > > 
> 
> 
-- 
Ted Guild <ted@w3.org>
W3C Systems Team
http://www.w3.org