Automotive Working Group Teleconference

<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]

Auto WG

Rudi: welcome Christian

Introductions

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

ISO20078

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

Doodle for ISO/W3C auto call

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]