<scribe> scribenick: ted
<wseltzer> ted: [background]
<wseltzer> ... V1 uses sockets only, not REST (had been planned to add, but did not)
<wseltzer> ... TAG wanted to see REST
<wseltzer> ... before VW joined, published VISS; BG has been looking at convergence
<wseltzer> ... we've slipped on timeline
<wseltzer> ... charter is expiring
<wseltzer> ... so, with what scope do we recharter?
<wseltzer> ... Proposal: recharter for V2, without invalidating VISS
<wseltzer> ... RSI goes beyond signals, e.g media notifications, location-based services
<wseltzer> ... give single target for small group
<wseltzer> ... propose to do maintenance-only on VISS, focus new work on RSI
Rudi: putting the technical
decisions aside, nature of technology always have a newer
approach available
... you have to have a v1 before a v2
... there are implementations going on, people using it
already. we are really that close
... we would like to put v1 into REC and then continue working
on top of that
... we recognize v1 only does signals but there is strong need
for that information in applications
... my expectation is that we finish v1
Rudi: unsure the timeframe. we
want to get feedback and do not understand why to stop v1 at
this point
... not preferene on the mechanism, whether the existing
charter is extended or recharter includes v1 work
Wendy: I am the Strategy Manager
at W3C
... looking at the rechartering questions and how to help the
work we are doing succeed
... some of the things I have heard from Ted and read in the
group discussions is there are different architectural
considerations
... last week I was at IETF and discussed the architectural and
security concerns around the web sockets approach
... one of the goals with standards is to get something
everyone can live with, not to have multiple different
directions with a few users and uses
... it seems from the TPAC discussion that there were more
implementers and users interested in putting effort towards
v2
... effort to take any spec to REC requires extensive wide
review and address any issues raised
... it does not seem dividing those efforts would be the most
productive
... there is plan and intent in having v2 backwards compatible
with v1
Kevin: v1 seems ready to go so
why not progress it?
... RSI approach uses both REST+sockets and VISS sockets - both
should have the same security concerns
... not sure these concerns are outlined on W3C sockets
spec
... we are keen to see it go to REC primarily because it is fit
for purpose
... there are other bodies who would want to hear the technical
reasons why to not progress
Magnus: basically sockets are
needed here since we need constant data streams from the
vehicle
... REST would be cumbersome and not practical
... I don't see a conflict between the versions
... RSI is more extending the functionality of VISS by adding a
REST layer on top of it so if we can agree on a way forward I
see that as favorable
... we should not throw away this effort. RSI is just another
way to do it
<Zakim> wseltzer, you wanted to discuss "basically ready to go"
Wendy: I see one open issue on
the hostname convention which has architectural, security
considerations
... we need to use hostnames that is compatible with internet
conventions
... from the W3C process perspective with its various reviews
from TAG, Accessibility, Internationalization, Security,
Privacy and general wide review
Rudi: I want to avoid a technical
discussion. We had a lengthy security discussion where we
handled this opaquely with a security token without an explicit
model (leaving it implementation specific)
... regarding the hostname/discovery issue, this is meant to
run locally on the vehicle in an embedded runtime
... it wasn't meant for broader access
... I do not see how technical items should block or influence
v1 progressing or v2
... for what VISS intended to be it is ready and fit
... I am unsure of the length of the process
... I am surprised and annoyed that this didn't come up
earlier
<Zakim> ted, you wanted to ask what is lost not bringing it to REC
<wseltzer> ted: backwards compatibility; work is not being thrown away,
<wseltzer> ... additional work we were asked to do by the W3C TAG
<wseltzer> ... additional benefits of a subscription model include a broader range of participants and stakeholders
<rstreif> I don't see the possibility of backwards compatibility as a valid reason for not to pursue V1 for REC. That does not make any sense.
<wseltzer> ted: process of wide review brings in more feedback we need to respond to
<wseltzer> ... even as we initially discussed hostname "keep it simple," we noted that we might need to revisit
<rstreif> @wseltzer That is all understood but a V1 REC does not prevent any of that.
<wseltzer> ... there may be multiple services on a vehicle; more than one client device
<Ralph> [this probably is not the call to be digging into https://github.com/w3c/automotive/issues/223]
<rstreif> Issue 223 has been discussed at length.
<wseltzer> ... v2 uses registry
<wseltzer> ... big-picture
<wseltzer> ... For standards to succeed, need broad adoption
<wseltzer> ... hence reason to unify
Kevin: the one remaining issue
concerns how to find the service and applies to v2, WoT
etc
... it was a shame we were held up for several months on this
one issue. we left it to the implementer on how to find the
instance
<rstreif> I see v1 as a step. None of what was said constitutes a valid reason for not to move V1 to REC. V1 is exactly what it was intended to be and defined by the charter. It was not intended to be V2 or anything else.
Kevin: vehicles tend to have dynamic IP addresses and cannot connect to a vehicle until it reaches out
<rstreif> It is the right time to put a cesure, make V1 REC and then move on.
Kevin: I do have a concern whether the only part of v1 that remains in v2 is sockets
Ted interjects on v2 backwards compatability and how that could be a requirement of recharter. desire to use sockets from v1
Wendy: I am here primarily to
hear what the group participants want to put into a
charter
... it seems we have very different sets of people and centers
of gravity
... I would like to see a charter that enables work on v2
... it sounds like there is a strong desire to allow work to
continue on v1
... ideally the work could support both simultaneously
... it is important that a recharter permit the group to work
on v2 at this point
Rudi: v1 fulfills its charter. i
don't understand why we cannot complete it and move
forward
... my preferred path is to finish v1 and put it into REC and
then v2
... handle registry, security models etc
... for v1 people wanted to leave some of these pieces
opaque
<Zakim> wseltzer, you wanted to discuss finishing
Wendy: fulfilling the charter
includes completing the steps of the W3C process and I am not
sure how many of the required reviews and considerations have
been met and which are outstanding
... that is already part of the charter before W3C can
recommend a specification
<Ralph> [fulfilling the charter also requires responding to formal issues raised on the draft specs]
<wseltzer> ted: missed timeline was a result of work, people's availability
<wseltzer> ... and other issues raised in the group itself
<wseltzer> ... still not quite at CR
<wseltzer> ... ~6mo to respond to issues
<wseltzer> ... we have people who want to engage on v2
<wseltzer> ... doesn't invalidate VISS
<wseltzer> ... division causes confusion
<wseltzer> ... if v1 is feature-complete, why not bring v2 into the mix?
<wseltzer> ted: we haven't yet hit CR
<wseltzer> ... we'd have work to do to exit CR: implementation report, testing
<wseltzer> ... hostname issue is complicated
<Ralph> Vehicle Information API Specification [currently W3C Working Draft 21 June 2017]
<rstreif> I don't think we are going to resolve this here. Maybe the workgroup membership should take a vote on it.
<Ralph> Vehicle Signal Server Specification [currently W3C First Public Working Draft 20 October 2016]
Rudi: I don't think we are going
to resolve this here. Perhaps options should be laid out
clearly and make this a vote
... this isn't about delaying a v2 but I do see the benefits of
seeing v1 move to CR or REC
... we brought this to W3C for its reputation and subsequently
its specs
... this spec does what it is meant to be
... let's finish it and finalize it
Hira: I am agreeable with Rudi's
comment
... do you have clear prospects on perfect solution for RESTful
api and web sockets
... within six months, I think it impossible. we should accept
a tentative solution
<urata_access> hira basically agree to Rudi-san's opinion
Hira: until a perfect solution is found out we will implement this one
<Zakim> wseltzer, you wanted to pose a "can you live with" q
Wendy: the question I have for
this group and W3C Advisory Committee (who would approve any
charter)
... what can you live with and try to find the
intersection?
<Zakim> ted, you wanted to ask about minutes
<urata_access> urata agree to Rudi's opinion, too
[adjourned for now, to be continued by email]
Rudi: welcome Christian
Rudi: we want to hear about
ISO20078 work on vehicle services
... I'm from JLR based in San Diego, chair with Paul from
INRIX
... we are working on wrapping up VISS and then looking for
next steps on media, navigation etc
[Ted introduces himself]
Magnus: I'm from Mitsubishi Electronics, we have done one of the implementations for the VISS service
Guru: my name is Guru, I am from Bosch and still relatively new to this group
Hira: I have been part of this activity since the initial workshop in 2012. (KDDI)
Kevin: I am from JLR and looking forward to additional contributors
Urata: I have been involved in this group for several years. I work for ACCESS and have done implementation and test suite work for VISS and editor of VIAS
Christian: I am from Daimler and working on a ISO project called ExVe - Web Services
Adam: Adam Crofts from JLR, application developer and co-editor of VISS
Patrick: I am representing VW in W3C and we brought in a submission of a REST based spec and I should look into ISO activity
Lovene: I am the manager of the connected car team at JLR and here to get cross industry agreement and standard we can move forward on
Mike: I am affiliated with the WG through IBM and have been involved for nearly a year. I am an IoT architect
Gunnar: I am the Genivi alliance
activity lead and have been involved for the better part of
this year, monitoring it longer than that
... I am looking to ensure there is alignment between W3C and
Genivi
Rudi: Christian, please tell us more about this work
Christian:Christian: ISO has a copyright so I cannot share content, but we can exchanges views on standardization,
... I understand you are working on vehicle data. We are looking at data protection, e.g. GDPR which may include user based consent for some cases
... what we do in ISO work is focus on is processes with a REST APIs which could be driven from JSON, XML or key value combined with Oauth2
... when user is doing an Oauth challenge, he may check name, purpose and data list of third party application,
... for us it is not an interest in standardizing a data structure in that project, as we see everyone doing it differently and you could adapt a REST api regardless,
... we chose a technology to share data after one year discussions, someone came around with SOAP, group consented on REST,
... if you have some data structure you can represent that in JSON, XML, key value, exposing via REST,
... if you have an OEM cloud and want to handle access from the outside Oauth2 is adapted,
... we are focusing to solve technical issues on data protection,
... this will enable applications that the user chooses,
... partners may register and manage or get managed APIs for some
cases
Rudi: how do you manage the privacy and security requirements?
Christian: TLS on the security side but open to enhancements
... on privacy side, we let legal departments check and give recommendations
Ted: in summary this is about collecting vehicle from vehicles, storing in the cloud and being able to share that with other parties depending on user preferences?
Christian: it doesn't cover getting the data to the cloud from vehicles but exchanging data from silos, cloud, or backend to third parties
Gunnar: can you please clarify scope of the specification in addition to it being a REST API?
Christian: we are thinking about data protection and a regulations requesting remote diagnostics support
... we are splitting those into two specs, one for sharing, one as a use case,
... we want to be able to extend the first to additional other use cases
Ted: while the VSS data structure might not be best for warehousing purposes there might be some use for it in exchanging with partners. also you can use the VISS spec for data sampling to send to the cloud, advantage being fewer applications needing attention when required by regulators to collect additional data points
Christian: It is very difficult to try to standardize on a data model, they are already all doing their own solutions
... there is also the other effort. we want to focus on data exchange from backend to partners
Rudi: we wanted a universal
representation of vehicle data which is why we came up with VSS
at Genivi, OCF has subscribed to this model
... yes everyone has their own data structures but in order to
share and monetize data there should be a common model
Rudi: for data in the aggregate there are privacy concerns and needs to be anonymized
Christian: we are looking to handle both anonymized and personalized
Gunnar: We are continuing to work
in that direction
... we are looking to extend vehicle signals as more refined
data also in a tree structure
... there are other activities in the industry looking at
addressing this same problem
... some are trying a more traditonal graph structure than a
tree structure
... precisely for outside communication
... I will try to connect you to researchers in this area?
Christian: you are mostly handing in-vehicle data uses, correct?
Rudi: yes, for applications
running on the vehicle to access information and services of
the vehicle
... we are focusing on web architecture approach
... whether that extends beyond the vehicle remains to be
decided on where to do that work
Rudi: your work is similar
Kevin: We are trying to expose
vehicle signals through VISS spec
... a vehicle is issued a dynamic IP address, server cannot be
connected from outside the vehicle unless cloud server knows
where the vehicle is
... it is possible to have a client running on the vehicle
doing data sampling to be authorized to send offboard data to
your server model
Rudi: what should be next steps on future collaboration?
Christian: we are seeking experts from ISO and check to see cross-communication
Rudi: when would you like to see the next call?
Christian:Maybe in December based on the doodle responses, before 17-18th ideally
Ted: we are running out of time so instead of trying to cover wwwivi issue will take to email solution for that, start of language for spec solution in minutes
Rudi: we are out of time and won't get a full TPAC summary
[adjourned]