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

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.