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

Thank you Kevin for the perspective that helps. While unlikely it is
still conceivable an app would want to connect to more than one
service.

I have provisional approval from the W3C Director for a w3.org hostname
or subdomain pending a formal request. We should settle on name[s] as
Gunnar suggested via a poll once we have suggestions. We will likely
want to create a real DNS record and page residing at it explaining the
purpose. That is something I would do.

On Wed, 2017-10-25 at 15:41 +0100, Gavigan, Kevin wrote:
> Hi Ted,
> 
> Please see below for my comments in blue
> 
> >> What I think would help would be to have a better understanding on
> why we might have multiple VISS and whether an application is
> expected to communicate with more than one.
> 
> Imagine the team creating the new 'Hi Line' Deluxe infotainment
> system decide to include a VIS Server in the infotainment system.
> This system will be released in 19 Model Year (MY) on _some_ vehicles
> only
> 
> Imagine also that  a few months later, the team that is responsible
> for developing the Instrument Cluster decides to design a new cluster
> 'back-end' ECU to be used by _all_ cluster designs (regardless of the
> particular UI for a particular cluster) from 21 Model Year onwards,
> and that they think that the W3C Spec and VIS Server idea is
> brilliant and so decide to use a VIS Server running on the cluster
> ECU to obtain processed signals
> 
> The Cluster team cannot use the Infotainment system VIS server
> because the cluster will be in all vehicles but the Deluxe
> infotainment system will only be in some vehicles.
> The Infotainment team cannot use the VIS Server in the Instrument
> Cluster because they want to launch in 19 MY and the Cluster won't be
> available until 21 MY
> 
> In general, it's probably unlikely that a single App would try to
> connect to both. More typically, would be an app installed on IVI ECU
> connects to VIS Server on IVI and similarly an app on the cluster ECU
> connects to VIS Server on the cluster - but it is possible that an
> App on some other ECU might want to access one or other of them (via
> the vehicle's in-vehicle ethernet network)
> 
> >> I'm not sure who proposed wwwivi initially but agree ivi in the
> name is limiting. This service can be used by the dashboard, IVI, may
> be useful for things like ADAS and RVI, data sampling for V2X or
> insurance. and
> have apps connect from smartphones, tablets and other devices in
> the vehicle.
> 
> If think wwwivi came out of a group discussion at one of the F2F
> meetings (possibly the one in Portland)
> 
> If as a group, we decide we want to specify a suggested default (and
> we wanted the default to include w3.org or w3.org.local), we could
> follow e.g. the following scheme:
> 
> We could have a default naming scheme of
> either <location>.<spec>.w3.org or <location>.<spec>.w3.org.local  If
> we assume that 'w3.org.local' or 'w3.org' part is denoted by
> <suffix>, we could then have suggested defaults like the following:
> 
> ivi.viss.<suffix>          to specify default value for VIS Server on
> IVI ECU
> cluster.viss.<suffix>   to specify default value for VIS Server on
> cluster ECU
> adas.ivi.<suffix>        to specify default value for VIS Server on
> adas ECU 
> <y>.ivi.<suffix>         to specify default value for VIS Server on
> <y> ECU
> ...
> 
> The same conceptual issue will affect 'finding' local RVI services -
> once RVI is available, this could then have as defaults:
> 
> ivi.rvi.<suffix>          to specify default value for VIS Server on
> IVI ECU
> cluster.rvi.<suffix>   to specify default value for VIS Server on
> cluster ECU
> adas.rvi.<suffix>        to specify default value for VIS Server on
> adas ECU 
> <y>.rvi.<suffix>         to specify default value for VIS Server on
> <y> ECU
> ...
> 
> Personally, I don't have a strong view on whether we include a
> suggested default or not, but I would suggest that if we can't agree,
> we de-scope this whole debate and simply state that "the implementer
> of a VIS Server will document how to connect to the VIS Server".
> [Which could of course be via a Discovery mechanism or by
> configuration]
> 
> [Unfortunately Adam and I will not be able to attend next months F2F,
> but if it can't be resolved in github/email, it would be great if at
> the F2F this could be made a priority - as it is the only issue
> preventing the spec from moving forward...]
> 
> 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 24 October 2017 at 19:52, Ted Guild <ted@w3.org> wrote:
> > Thank you Gunnar, some responses in-line.
> > 
> > What I think would help would be to have a better understanding on
> > why
> > we might have multiple VISS and whether an application is expected
> > to
> > communicate with more than one.
> > 
> > We should also try to envision the OEM app marketplace. Instead of
> > trying to discover services for a given vehicle platform, the
> > marketplace could provide configuration for that year, make and
> > model
> > on which service[s] a specific app is expected to interact with.
> > This
> > is what I meant earlier by provisioning.
> > 
> > On Mon, 2017-10-23 at 12:18 +0200, Gunnar Andersson wrote:
> > > 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. 
> > >
> > > I wouldn't go that far.
> > >
> > > First, it would be a recommendation, in my opinion.
> > >
> > > Second I think standards do help, because in communication an OEM
> > can
> > > then
> > > say "just follow the standard as written in chapter 5.6".  And
> > some
> > > will do
> > > that.  It's not bad to have a default, and then if OEMs want to
> > do
> > > something
> > > different, they specify that separately.
> > >
> > > I may have missed if it was given in discussions - if so could
> > > someone
> > > repeat for me the rationale for including "ivi" in the name?  The
> > > specification isn't written to be IVI specific, is it?   I think
> > if
> > > the key
> > > point is that it is a "local" server on the same computing unit
> > as
> > > the
> > > application making the request, just indicate that.
> > 
> > I'm not sure who proposed wwwivi initially but agree ivi in the
> > name is
> > limiting. This service can be used by the dashboard, IVI, may be
> > useful
> > for things like ADAS and RVI, data sampling for V2X or insurance.
> > and
> > have apps connect from smartphones, tablets and other devices in
> > the
> > vehicle.
> > 
> > > Why not simply "viss"?   If it's a W3 subdomain, how about
> > viss.w3 or
> > > visslocal.w3... assuming it is the _recommended_ name for a
> > locally
> > > hosted
> > > server?  (A simple poll would probably resolve the naming
> > question)
> > 
> > I like viss better but since VISS is to be followed shortly by RSI
> > maybe something appropriate for either.
> > 
> > Today's schedule got jumbled with others' meetings and my attempt
> > to
> > get time on decision from W3C regarding a hostname is pending.
> > 
> > > Finally, I agree with where the discussion was going last time:
> > >
> > > First, these are separate things:
> > >
> > > 1) Chapter describing a recommended fixed name for a local VISS
> > > server, (and
> > > that the underlying system will likely translate it with a static
> > IP
> > > mapping).
> > >
> > > 2) Chapter describing the recommended local service name and the
> > > usage of
> > > mDNS discovery.  Including an impmlementation note to take great
> > care
> > > of
> > > security issues, spoofing in particular.
> > >
> > > Second, the specification could include either one, two, or none
> > of
> > > these
> > > chapters.  They could also be added at a later time.  
> > >
> > > My vote would be to include chapter 1 now and a single sentence
> > about
> > > mDNS
> > > discovery.  A separate instruction could be created to describe
> > how
> > > to
> > > implement mDNS in this context.
> > 
> > Until we understand the ramifications that would make sense.
> > 
> > > More below.
> > >
> > > >
> > > > lör 21 okt. 2017 kl. 04:26 skrev Gavigan, Kevin <kgavigan@jagua
> > rlan
> > > > drover.
> > > > 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.
> > >
> > > When everyone feels they have made their arguments, create a poll
> > on
> > > the
> > > name.  Also, getting some informal approval of the final proposal
> > in
> > > the
> > > wider W3C community is an important part in my opinion.  I see
> > little
> > > that
> > > must be unique to Automotive in the fundamental parts of this.
> > 
> > Makes sense. I have no strong preference personally.
> > 
> > > > > [From Ted]
> > > > > Since there are cases that may have multiple VISS
> > implementations
> > > > > in the
> > > > > same network, or have client devices introduced, discovery is
> > > > > needed. 
> > >
> > > That's one driver, but not the only one.  For me it would be more
> > > that it's
> > > the existing generic solution to discover a service if it's
> > unknown
> > > where it
> > > is.   I wonder how realistically useful it is especially for
> > multiple
> > > servers.  In a particular car it seems kind of unlikely to me
> > that
> > > the
> > > applications will (or even should) know what to do, if a lookup
> > > yields
> > > multiple VISS servers responding.  It opens up for a whole bunch
> > of
> > > rules/policies that need to be there - which server do they
> > choose to
> > > communicate with?  Try one, if it fails, try the next?  It just
> > seems
> > > to be
> > > a whole other level of policy definition that this specification
> > > should
> > > probably not venture into.  It seems more likely to me that a
> > > particular
> > > application standard will provide a single (local) source of
> > contact
> > > - if a
> > > more advanced system is needed, this could be funneled through a
> > > server
> > > acting as a proxy even.
> > >
> > > The end result for me is that a particular system will often fall
> > > back onto
> > > system-specific rules anyway (which means that specification
> > could
> > > even
> > > include things like the name of the default server).
> > >
> > > > > 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).
> > >
> > > In my opinion that may still be enough.  Beyond that it's
> > > implementation
> > > dependent.
> > >
> > > > > 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. ]
> > >
> > > I partly agree.  I noted before that more than anything this is
> > > likely part
> > > of some "application standard", which might be widely adopted, or
> > OEM
> > > specific depending on what the industry wants.  (I have always
> > wanted
> > > to
> > > work toward the former, but the OEMs are not clear enough on
> > their
> > > desire
> > > there).  The scope of VISS specification isn't really an
> > "Automotive
> > > Web
> > > Application Standard".  That would be some different
> > specification it
> > > seems
> > > to me.  
> > >
> > > That said, I could still see some value in W3C taking the first
> > step
> > > to
> > > define one single recommended FQDN for the default VISS server.
> > >
> > > > >
> > > > > Keen to hear the thoughts of the group re. how to move
> > forward...
> > >
> > > To move forward I propose:
> > >
> > > - Set a deadline for further arguments to be brought forward.
> > > - Then, list all the options for the spec.  See that we all agree
> > on
> > > the
> > > list.
> > > - Conduct a poll.
> > >
> > > I don't mean that guarantees a decision, but it's a clear
> > step.  If
> > > the poll
> > > shows good consensus, it's easy to go ahead.  If it doesn't,
> > perhaps
> > > simple-
> > > majority is not enough for a decision, but then I think a little
> > more
> > > discussion among those that disagree will eventually lead to a
> > > compromise
> > > and consensus.
> > >
> > > - Gunnar
> > >
> > >
> > > > >
> > > > > Thanks and regards,
> > > > >
> > > > > Kev
> > >
> > >
> > > - Gunnar
> > >
> > > -- 
> > > Gunnar Andersson <gandersson@genivi.org>
> > > Development Lead
> > > GENIVI Alliance
> > >
> > > > >
> > > > > 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.
> > jagu
> > > > > arlandr
> > > > > over.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
> > 
> 
> 
-- 
Ted Guild <ted@w3.org>
W3C Systems Team
http://www.w3.org