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

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

From: Gavigan, Kevin <kgavigan@jaguarlandrover.com>
Date: Fri, 27 Oct 2017 16:17:39 +0100
Message-ID: <CAKaHsmfwFyn19gZ_JWcaEJJWDntxZByRySCi7vwEGJAkXcuL8A@mail.gmail.com>
To: "ted@w3.org" <ted@w3.org>
Cc: Gunnar Andersson <gandersson@genivi.org>, Peter Winzell <peterwinzell.gbg@gmail.com>, "Streif, Rudolf" <rstreif@partner.jaguarlandrover.com>, Adam Crofts <acrofts1@jaguarlandrover.com>, Junichi Hashimoto <ju-hashimoto@kddi.com>, Lovene Bhatia <lbhatia@jaguarlandrover.com>, Magnus Gunnarsson <Magnus.Gunnarsson@melcogot.com>, Mark Nottingham <mnot@mnot.net>, Mike Aro <arom@us.ibm.com>, Shinjiro Urata <shinjiro.urata@access-company.com>, public-automotive <public-automotive@w3.org>
Hi Ted,

>> I have provisional approval from the W3C Director for a w3.org hostname
or subdomain pending a formal request.

Thanks, sounds good...

>> We should settle on name[s] as Gunnar suggested via a poll once we have
suggestions

If we want to specify just a single vehicle wide default, could I propose:
viss.w3.org.local or
viss.w3.org

Alternatively, if we want to be able to specify a default for the IVI
system (and hence allowing for other defaults for other clusters/ECUs),
could I propose:
ivi.viss.w3.org.local and
ivi.viss.w3.org

[I have to confess, my main priority is to break the impasse and move
forward and so would be happy to accept any reasonable suggestion, so will
be keen to see other ideas :-)]

Thanks and regards,

Kevin

*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 26 October 2017 at 20:30, Ted Guild <ted@w3.org> wrote:

> 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
>
Received on Friday, 27 October 2017 15:18:30 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 15:18:31 UTC