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

That in a nutshell is the problem we have - OEMs will make their own
choices. We have not convinced enough to drink the standards kool-aid.
The main reason for standards here is to have something developers can
follow, across the different manufacturers. Content providers don't
want to port their app to 20+ different platforms and this lack of
consistency is holding the industry back. Our job is to create
something reasonable for an OEM or Tier 1 to implement and for a
developer to follow. If we achieve that, maybe more OEMs will see the
light.

Discovery has its drawbacks and until we figure those out, I think the
best course is an acceptable static hostname. We should solve the
broader use cases covered by discovery and may need to before going to
CR. An alternative may be provisioning of applications in the OEM
marketplaces. That leaves the developers free of needing to customize
per OEM and the reality Peter refers to. It may not solve an
application mixing and matching multiple VISS services nor a device
(smartphone or tablet) permitted to connect to the vehicle's LAN which
leads itself to discovery.

I asked for a meeting on Tuesday at W3C to inquire about a w3.org
hostname and advice on moving forward.

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. 
> 
> lör 21 okt. 2017 kl. 04:26 skrev Gavigan, Kevin <kgavigan@jaguarlandr
> over.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.
> > 
> > [From Ted]
> > 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).
> > 
> > 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. ]
> > 
> > Keen to hear the thoughts of the group re. how to move forward...
> > 
> > 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
> > 
> > On 21 October 2017 at 00:35, Streif, Rudolf <rstreif@partner.jaguar
> > landrover.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