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