<scribe> scribenick: ted
<Ulf> i have no invitation. can you share it?
<PatrickLue> Patrick's (JLR) proposal: https://lists.w3.org/Archives/Member/member-automotive/2019Jan/0013.html
PatrickB: as I mentioned in Lyon
at JLR we want to employ the ViWi submission and utilize it for
backend purposes
... backend to client and backend to backend
... I want us to first agree on a framework and then start
define the essential building blocks for each OEM backend
... those building blocks from our perspective are identity
(for vehicle, user/driver, factories, insurance companies,
partners...)
... and as a central piece for connected vehicles remote
control/access - ability to send commands such as unlock or
start heating/charging, location, status, diagnostics and other
barometer readings
... we can start building functionality based on these APIs
PatrickL: as Peter is not on the
call I'll share his comments
... he wants one API and not to splinter the group
scribe: his point was we want a single API for all use cases
PatrickB: if that is a
requirement than the proposal doesn't make sense
... I do not see the necessity to have them be the same.
offboard API serves different purposes
Ulf: I share Peter's view that we should have one API and feel what we are working on will support both use cases
PatrickL: it needs to be made clearer for rationale for why it should be different
ack
Ted: regarding backend, nearby we
have the VSSo ontology work by Daniel and Benjamin which can allow
for SPARQL and other queries
... we are also talking to Uber who has some additional ontologies
they may want to work with us on for profiles (passenger and
driver) and trip data
... I have from a security perspective seen VISS as generally being
exposed on the vehicle, can be used to sample data/perform edge
computing before sending to a backend but not addressable from
cloud
... I also think given connectivity issues push from vehicle is
better than trying to pull
Magnus: from my point of view
VISS has never only been in the car but a way to communicate
outside as well and believe I voiced that before
... we should look at extending it for Patrick's use
cases
... as a result I'm inclined to side with Peter
PatrickL: there is sound
arguments for a single API as noted
... having an alternate for these different purposes isn't well
argumented yet
Daniel: is there currently a
blocker for backend using VISS?
... if not it might suit both use cases
Ted: regarding profiles, I understand several OEM are working on them for themselves but would like an understanding of the various architectures since this too is related to backend
PatrickB: we have something that
follows OAuth thinking although not OAuth
... we will likely want to stick with that as it works pretty
well
... for standardizing we would want to be able to store vehicle
and user information within OAuth
... OAuth can do federated IDs and how to authenticate but we
would need something specific to vehicles
... idependent of OEM backend
PatrickL: one thing I like about Patrick's proposal is it is a good chance for us to take RSI as a base and that would be a plus for us
PatrickL: what is the procedure for starting a new task force, do we need unanimous?
Magnus: PatrickB was suggesting a separate Working Group not a task force
PatrickB: I was talking about a
Working Group but I meant a group focusing on it and don't care
about the semantics on type of group
... perhaps a task force is the first thing to do. we have
requirement differences for on and offboard
... keeping both solutions combined can impose boundaries on
the solution compared to independent
... as an example: in the car we need to find a solution for
authentication that can work when the car is on or offline -
sporadic connectivity or disabled
... for backend if there is no connectivity there is no backend
so need for offline authentication mechanism
... batch download, distribution of services across mixed
clouds
... for VISS we are still tied to a root node which doesn't
make sense for eg mixed cloud solutions
... we may be limiting ourselves with a common solution
Ted: procedure can vary for forming
a new Working Group
... for
instance we could have a Member submission as was ViWi or hold a
workshop to get position papers and start to form a proposed
solution for the WG charter
... another way would be to start this as a task force in the
Business Group and then when we start to have something we can
clearly communicate propose it as the work for a new Working Group
PatrickL: I propose we revisit this topic on our next call and encourage people to provide input on the current mail thread
Ted encourages people to provide their companies' respective visions for these backend use cases and architectures, they can be vague high level and kept in confidence
PatrickL: based on issues list
and pull requests it doesn't look like there has been
contributions since we last dicussed
... we will keep that until next week
... any additional topics for next week?
Harjot: I wanted a little more clarification on comments about sampling methodology being out of scope of the spec
Ted: I am not saying it shouldn't be
standardized, I am just trying to figure out how something that
should be communicated to a backend/cloud server belongs in a
specification for an in-vehicle service (VISS) to client applications
that could be doing the sampling
... based on earlier topic of wanting to standardize backend,
there could be a place for it there. others may have different
opinions than mine on where it belongs
... some of the other points you raise such as accuracy and
frequency may make more sense in VSS not VISS
Daniel: I second the suggestion
of having some of these details in VSS and it makes sense. we have
minimum and maximum but not information about frequency or
accuracy
... perhaps raise as an issue on GH
https://github.com/GENIVI/vehicle_signal_specification/
Ted notes it is a different repo
[adjourned]