W3C home > Mailing lists > Public > public-automotive@w3.org > October 2017

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

From: Ted Guild <ted@w3.org>
Date: Fri, 20 Oct 2017 14:36:05 -0400
Message-ID: <1508524565.9762.374.camel@w3.org>
To: "Gavigan, Kevin" <kgavigan@jaguarlandrover.com>, Lovene Bhatia <lbhatia@jaguarlandrover.com>, Rudolf Streif <rstreif@partner.jaguarlandrover.com>, Adam Crofts <acrofts1@jaguarlandrover.com>, mnot@mnot.net, Shinjiro Urata <shinjiro.urata@access-company.com>, Junichi Hashimoto <xju-hashimoto@kddi.com>, Magnus Gunnarsson <Magnus.Gunnarsson@melcogot.com>, Mike Aro <arom@us.ibm.com>, Peter Winzell <peterwinzell.gbg@gmail.com>
Cc: public-automotive <public-automotive@w3.org>
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
Received on Friday, 20 October 2017 18:36:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:06:03 UTC