W3C

Automotive Working Group Face to Face

10 May 2017

11 May 2017

See also: IRC log

Attendees

Present
Hira, Peter, PatrickL, PatrickB, Wonsuk, Adam, Kevin, Lovene, Urata, Bernard, Ted, Paul
Regrets
Chair
Peter, Paul
Scribe
Ted

Contents


Agenda bashed, going to be hectic with various conflicts from Genivi sessions

RSI

[recap, dev progress, temperature of others]

Ted gives recap on state wrt VISS staying on track, focus on other "domains" and a public proof of concept

[ted has his phone connected to webex in case people join before speakerphone arrives]

RSI demo being setup

PatrickB starts intro presentation

[repeat of Burlingame, see 2016-10-20 & 21 minutes with link to slides]

https://www.w3.org/2016/10/20-21-auto-member-minutes

[another copy of slides sent to member-automotive@w3.org]

https://lists.w3.org/Archives/Member/member-automotive/2017May/0015.html

PatrickB: decision to focus on HTTP so as to be able to allow phones to connect via BT

Wonsuk: based on BT standard?

PatrickL: BT + serial port profile since it is the most stable

Wonsuk: usual pairing and a follow up step?

PatrickB: install app on phone, pair with BT as usual, then second permission for the phone

PatrickL: yes you then allow the device to access the apis from the head unit

PatrickB: after that reconnects are automatic

PatrickL: preshared key
... that installation of that application on that phone is paired with that car

Ted: you can pair with more than one car?

PatrickL: yes
... TLS protecting the device / car interactions
... I would like to discuss standardization of the tokens and pairing

Ted: I should ask colleagues, Dom in particular

PatrickB: we presented this to the group in October, joined W3C and made a Member Submission
... other domains pending
... we are working on demo server for media at present

<PatrickLue> Java RSI Client Implementation: https://github.com/luennemann/RSIMedia

PatrickB: we have 5-6 contributors already on github

<PatrickLue> + Media Client

PatrickB: VW has this in production vehicles, initially a modest number of cars with intent of widening it to other models in the coming year

https://www.w3.org/Submission/2016/01/

protocol, cdn, media (services), media library, mixer

additional pending: notifications (likely), navigation (more difficult)

[additional history summary for Lovene's benefit]

Paul: Philippe Colliot (PSA) hopefully can join us today or tomorrow

Ted: we also have work from Qing An Alibaba around LBS plus Genivi hopefully can fill in on nav

PatrickL: navigation is also incredibly complicated

(order of statements out of sync)

PatrickB: talking to eg Spotify they do not want to write something for a measely 10M cars when they are focused on billions of other devices
... they would be willing to write the bridge

(earlier Ted noted iHeart said they find ViWi/RSI media workable for them)

Ted: it is just a thin wrapper around their proprietary API

PatrickB: if they are not willing to write that wrapper we can
... auto industry is very fragmented. some of these content providers have done one off solutions and have found it painful including the long term contracted maintenance commitment

Peter: Spotify did it once for WindowsCE and understand that was painful as well
... I agree with the statement of the problem

PatrickL: we want to have something easily usable by content providers to be in another ecosystem similar to Apple carplay and Android auto

<scribe> [pending additional domain explained off the record]

Wonsuk mentions a similar effort at W3C for this other domain

PatrickL contrasts, mostly on user interaction

VW's additional submission is based on existing convention (quasi-standard)

[ted prepares to depart for Genivi panel, group will continue on RSI or possibly VIAS]

<peterw> == peterw taking notes on irc

<peterw2> == Patrick the RESTFULness very important for the RSI approach

<paul> RSI has graph interface

<paul> like FB

<peterw2> Restfulness supports microservices architecture

<peterw2> patrick guidelines to obtain tokens needed

<paul> http://wamp-proto.org/

<paul> http://openid.net/connect/

<peterw3> paul DLNA for media

<peterw3> == RSI approach high level business drivn

<paul> https://wiki.openmobilealliance.org/display/OI/OMA+Report+on+Automotive+Opportunity

<paul> https://wiki.openmobilealliance.org/display/OI/OMA+Report+on+Automotive+Opportunity

<paul> IoT architectures are somewhat similar

PatrickL: what does the group think should be the next step towards standardizing the protocol
... we are trying to bring use cases into our regular calls, show it works, make it open source so people can try it out

Ted explains BG process and reports, suggests next step

Paul: it is difficult to get participation, people are too busy with their day jobs
... I also want to avoid fracturing such a small group
... people can start playing with the mock server and creating their own. we should do some outreaach, involve people like Roger

Ted: another advantage to getting this going in the BG is lower barrier of entry, legally and financially

Bernard: you guys need to be better about messaging, updating the BG page where people land and want to learn what is going on

Ted: I am guilty of not being able to put in enough time in that due to my other day job at W3C (Head of Systems) and also not the best at messaging
... people from this group (or their organizations) are more than welcome to contribute to blog articles, news feeds etc. I will try to be better

Paul: we are revitalizing what is taking place in the BG
... let's agree on a name and get going

PatrickL: define the name, put on github, encourage people to join

Paul: using repec
... I would like to see what JLR's interest is here. You have been heavily involved in W3C VISS and VSS

Kevin: generally supportive

Adam: similar model to web sockets

Kevin: nothing has changed in our commitment to the group

Paul: one problem has been the time of the meeting

PatrickB: we should try to have more public discussions
... benefit is more promotion, suggest #w3cauto

<auto> Schedule meeting to work for all

<auto> Move specs to respec

<auto> put more info on website

<auto> make effort to publicize

[discussion on specific organizations we would like to engage, history of pass participants]

VISS

PatrickL: I want to understand the issues you are facing

Adam: if for example you don't include the path in getVSS method you get the entire tree
... what we wanted to do is perhaps emit path but what to do if you're given null
... do we feel having WebIDL and JSON schema in the same spec is a good idea?

Wonsuk: if there is no path property that could mean the client wants the whole vss tree
... in webidl there is no null option

Adam: saying filters=null is the issue

Ted: isn't filterrs optional?

Adam: yes but either we stick with webidl or do not. webidl is for interacting with an api within the browser, whereas here we're talking to a service

Peter: i don't want to check json objects for path sometimes but not others

https://github.com/w3c/automotive/issues/174

Ted: problem arises since we're trying to use WebIDL for a service

Paul: what are the reasons for sticking with it?

Ted: perhaps for easier binding to VIAS

Adam: I don't think that is relevant

Ted: then it is simply influenced by tooling (respec) and consistency with other w3c spec patterns

[discussion of dropping webidl since we are not doing an ecmascript api]

Ted consults Philippe Le Hegaret via irc

https://www.w3.org/TR/webdriver/

ok to drop webidl, will confer also with Mike Smith

plh suggests, correctly, we are perhaps misusing webidl and can cause ourselves problem in the future

tentative resolution: ditch webidl and see if Ted can get suggestions from Mike or others

web driver was given as a possibly pertinent examplep

[back to filters]

PatrickL: I would be inclned to have two interfaces insteaad of this compound one
... separating getVSS and filter

Adam: interesting, thanks that might solve some other issues

PatrickL: document for the data structure again?

Adam broadcasts VSS spec

PatrickL: any experience generating C++ object model from YAML?

Paul: the fidl view might be helpful, Urata might have done something too

Urata: to csv

Paul: Franca people would be familiar, try Gunnar since you don't know Klaus

PatrickL: I like the documentation in YAML

Wonsuk points out VSS parser which is extensible

PatrickL: that is pretty powerful and documentation in the core truth (YAML). I could see taking JSON or another form to build out a mock server automatically

Lovene: would you be able to open your tooling as well?

PatrickL: possibly including adding to the VSS parser
... I need JSON for some of my purposes

Paul: reason for YAML was to go lower in stack to C++ and Franca

https://github.com/w3c/automotive/issues/200

time to live (ttl) in milliseconds (ms) in our spec, usually this is represented in seconds

Resolved: group agreement for ttl to be in seconds

https://github.com/w3c/automotive/issues/142

Adam: we should be able to set lock for everything within door via wildcard, no concern of number of doors nor look at vss beforehand

Ted: 409 Conflict could work fine here especially to be consistent with rest of spec. alternates for door not being closed example 412 Precondition Failed 416 Requested Range Not Satisfiable or 417 Expectation Failed

Urata: in the explicit example, iterating through doors, the server has to try each interaction separately
... you can have separate response codes and consider the overall failed if any fails

PatrickB: yes but perhaps rollback state for the others

Kevin: you might want to leave the lockable doors locked

PatrickB: 202 accepted could signify partial success instead of 200 OK for all
... or other in 2NN range

Adam: we don't give 200s since we're not REST at present

Kevin: success is JSON fragment or failure response

Ted: ideal would be to know which failed but that would complicate the failed response

PatrickB: we tend to send back a 200 for ok, 400 for client side and 500 if issue is with ECU

<junichi-hashimoto> how about simply to prohibit "wildcard set"?

Kevin: on failure, partial or full, you would need to iterate to find state of each

Junichi: you can end up in a deadlock state especially if multiple clients are interacting. I would prefer to keep it simple

PatrickB: you have to queue requests to be able to process them separately
... last wins

Kevin: that is problematic when it isn't a binary true/false but incremental change

<junichi-hashimoto> fyi, once we investigated 'set' method. there may be more complicated race conditions https://w3c.github.io/automotive/vehicle_data/security/#set-set-method

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/05/23 13:52:46 $