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

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.jaguarlandrover.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
> <https://maps.google.com/?q=US:+1419+NW+14th+Ave,+Portland,+OR+97209&entry=gmail&source=g>
> 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.
>
>