Auto WG F2F

06 Nov 2017


Adam Crofts (JLR), Junichi Hashimoto (KDDI), Philippe Le Hegaret(W3C), Wonsuk Lee (ETRI), T.Hirabayashi (KDDI), Hyojin Song (LG), Paul Boyes (INRIX), Ted Guild (W3C), Martin Voshell (W3C), Magnus Gunnarsson (Mitsubish Electric), Patrick Luennemann (VW), Hadley Beeman (W3C TAG), Daniel_Appelquist(Samsung/W3C_TAG), Sumie Miki (Keio), Hayato Kakiuci (KDDI), Shinjiro Urata (ACCESS), Caleb Brewer (Volta), Rodrigo Meirelles (WEX), Gururaja N (Bosch), Jaesung Han (Samsung), Linda Toth (Conexxus), Bernard Gidon (W3C), Judy Brewer (W3C), Janina Sajka (Linux Foundation), Joakim_Söderberg (Volvo), Gambhir Bista (Volvo), Peter Winzell (Jayway/Volvo)
Paul Boyes


Introductions and Agenda review

Short introduction of attendees

<ted> https://www.w3.org/auto/wg/wiki/TPAC2017#Monday

Auto Activity Overview

<ted> Summary of activity (first half of slides)

<ted> Patrick: we'll be delving more into RSI on Thursday

Patrick: PatrickB took a look at HTML5 as a UI for IVI
... he found that it was needing more and more a structured interface
... often it was coming down to elements and attributes, addressable by URI
... it is easy to use this structure from various languages
... if you want to be abstract on CAN bus, it can be represented in key/value pairs
... it is build on top of HTTP
... we will discuss openid and oauth on Thursday

Ted: We heard RSI (ViWi) was in 10s of thousands last year, maybe hundreds of thousands now and soon millions

Patrick: not sure the numbers at present. it is the protocol for future generation vehicles

Ptrick: it would be good to have a single protocol that can solve both needs

Linda: where can I find out more about the payments work?


Ted provides introduction to payments and fueling workflow

Patrick: location and trust are the key components as you described
... in Germany you fill up before paying

Ted: use to be the same here until gas prices spiked and people started stealing gas

Gururaja: Bosch is observing the proposed W3C direction at this point

Wonsuk: we're focusing on VISS more right now but for payments we're thinking REST may more sense for some use cases

Caleb: this seems like a card present transaction instead of online not present model

Linda: depends on the merchant service

Big Picture / rechartering

Rudi's email to Auto WG on VISS and ViWi

continue with VISS, explore signals and other convergence points in BG

PLH: your charter is running out at the end of the year

<Paul> Philippe Le Hageret here for recharter

<Paul> Ted to talk with Lovene and company tomorrow.

<Paul> Good to get automotive alignment

<Paul> Understanding one year ago... Presentation from VW... Here at Hyatt. VW Presnted RSI

<Paul> VIWI

<Paul> Decide to have Task Force and conversion.

<Paul> Continue with VISS

<Paul> Need to ask for exension or recharter

<Paul> Ted: Goals to gain implementation experience with VISS. E.G. Sanjeev Ba doing OCF

<Paul> Moved toward CR. Got widespread review from W3C and GENIVI. Down to one issue. How to handle host name. How is service found/discovered.

<Paul> Patrick, Rudi and Ted met and have discussion that will be a negotiation.

<Paul> RSI has other domains in addition to signals

<Paul> Typically charter every 2-3 years.

<Paul> Question is do we extend or recharter?

<Paul> In other words have VISS become RC or do we want to attack other domains.

<Paul> Discussions with Philippe and others the question is should we recharter or?

<Paul> RSI is being implemented by LG, Samsung, MELCO

<Paul> Philippe

<Paul> Experience with specs that take a long time.

<Paul> Do we want to take VISS to Rec or?

<Paul> OR should we shift energy to v2

<Paul> Nothing wrong with either side... It is really what will get legs in the market.

<Paul> If the group keeps insisting that VISS to REC

<Paul> run high risk

<Paul> Suggest coming out of this TPAC what the next charter should be.

<Paul> Ted -

<Paul> How fractured and fragmented how the marketplace is.

<Paul> Want to gain consensus and move forward with other automotive OEMs, Tier1s etc

<Paul> Urata-san has great test suite we can use.

<Paul> Can merge the two.

<Paul> RSI -> VISS

<Paul> Need more than just signals.

<Paul> Common arch/model that can apply to other domains.

<Paul> Where do we want to be in 2020

<Paul> Risk getting in broader market

Paul: it comes down to industry marketshare and we need to cast a broader net

<Paul> Ted: If no adaptation ?

<Paul> Patrick: If JLR ready to implement then go through with Version 1

<Paul> Patrick: Trust in specification is something else. Something official that represents the current state of the working group.

<Paul> Philippe- Some of the market is implement v1 than we do not necessarily need to take to rec.

<Paul> Ted: Procedurally will not change VISS to a note until formal fixes.

<Paul> Ted: Ask Adam for opinioin... Meeting with Lovene tomorrow. Not a done decision but get feelings or direction.

<Paul> Adam: I caught the last couple of minutes

<Paul> Ted: Quick recap

<Paul> Adam: Would VISS and RSI be compatible across all versions

<Paul> Ted: VISS signal tree most important.

<Paul> Ted: Decide on data model. Still have sockets. Backward compatibility a ship. Map methods, etc...

<Paul> Adam: Because VISS is relatively agnostic to a data model should be able to support other formats

<Paul> Ted: Data model a big piece. Since VISS does not have URI will be an addition.

Paul: I want to hear others' opinions

<Paul> Patrick: They have tree pass that could be considered a URI. Just a path through a tree. Tree is rep

<Paul> Ted: Engage Caleb

Caleb: I want more context before I could give opinion

<Paul> Wonsuk: complicated. Difficult to say.

Wonsuk: some companies want to use these (VISS/VIAS) specifications
... we have invested time in them

<Paul> Wonsuk: If we made spec that are to be deployed in the market we need to seek companies who would use specs. Candidate is Jaguar. Had a lot of time with both spec so far

<Paul> Wonsuk: Why make spec if we just make a note

<Paul> Philippe - How long to rec

<Paul> Philippe: Charter at end of year. Extension or rechartering.

<Paul> Wonsuk: Does not think that is the issue. One of the issues is how to align existing specs and RSI specs.

<Paul> Philippe: if we can recharter on aligning the two why not?

<Paul> Wonsuk: Big issue is data model rather than API.

<Paul> Ted: Patrick Bartsch and Rudi will work on aligning data model.

<Paul> Ted: Rudi owns that repo.

Paul: as you noted Genivi is heavily invested in this stack and they will be interested in the data model

<Paul> Ted: Rudi part of arch group.

Paul: when you look at vehicle signals, you are looking at distinct and discreet bits of data
... they will look at the cost of eg mapping from an embedded engineer perspective whereas a web developer looks at how easy it is to assess and doesn't concern themselves with underlying performance
... a common model is needed for V2x and ADAS as well, they are different problems

Patrick: we are trying to get across things that are not changing that rapidly and have a high degree of complexity

Magnus: are they solving the same use case, partially they are
... my understandin of VISS is a way of forwarding or exposing vehicle signals
... from my point of view it is a bit different but not mutually exclusive. RSI as a superset and VISS a subset but again data model should be consistent

Patrick: we have a single protocol that can serve both needs
... we want to bring these two sides together

Paul: we should ask the question of whether we are trying to solve the same problem or different

Patrick: short answer is yes, trying to bring vehicle data from a to b
... depends on the scope of the problem definition
... VISS case was primarily for data attributes from CAN bus whereas RSI was for providing data in general for multiple domains - including media
... having an additional access method in the vehicle seems counter productive

Magnus: you describe this as a microservice architecture
... VISS could be one of those microservices

Patrick: one of our services is the vehicle data service

Paul: RSI can use REST and WS at any time, VISS can allow you to grab any handful of signals through socket at any time

Caleb: you mentioned it is a graphml implementation

Patrick: similar
... iirc graphql is a way to work with graphml

Caleb: there is also a subscription model for latent and frequent signals
... that seems like the primary use case for this, distinguishing what elements you want how

Urata: basically we were working on JLR proposal and I think VISS is getting somewhat mature, maybe 70-80%
... the goal is near to get to REC
... regarding ACCESS & KDDI, we were following the WebIDL proposal fron Kevron Rees from Intel
... the change of direction to VISS was somewhat reasonable. if we change direction again, I want a strong reason
... I want technical reason that is understandable
... JLR and VW specifications are trying to achieve basically the same outcome
... I am not sure why to make the change
... if JLR does not want to push for continuing VISS then I would be more accepting
... the data model is important
... as Adam said VISS is agnostic on the data model

Adam: we fully intend to push VISS through and feel we are snagged on the one issue
... we are exploring with suppliers, getting this into future products
... we want VISS

Hayato: difficult is the priority of which specification
... ACCESS & KDDI have worked on VISS
... undecided

Linda: no opinion, more interested in web payments

Ted: Sumie, would you like to give your impression as well?

Urata: she is ovserving many groups and I think not having strong opinion on detailed issues.

Ted: we welcome the opinion of all attending this meeting

Exchange in Japanese between Urata and Sumie

Urata: Sumie wants a recommendation at the earliest stage

PLH: how long do you think it will take VISS to REC?

Urata: not many remaining problems
... maybe 3-4 months for VISS

Hadley: I want to hear about the group dynamic with these two approaches

Paul: this is more Genivi+JLR vs VW approaches. people are not entrenched so much technically as they are business

Hadley: why we (TAG) pushed for REST vs bespoke (web socket) API was scalability
... interesting to hear how you are thinking about trying to solve these problems
... there is a mindset difference between a manufacturing perspective and decide something for 15 years versus how to be adaptive with needs

Daniel: that is part of the web philosphy at large
... is this to create a more open webby ecosystem and which is more weighted along those lines since that should be an influencer

Caleb: good point, which is more easy to consume. REST is more dominant in the Web as is self discovery APIs which again REST is a benefit
... maybe less efficient for rapidly changing signals

Hadley: you get efficiencies on a different scale

Caleb: most expensive cost is the developer

Magnus: I think just considering web developers and their applications is limiting the conversation
... as as Tier 1 exposing said signals from varied OEMs. they need to be tranformed, parsed and transmitted
... within the car, we are looking at those use cases as well
... there are slightly different problems these approaches solve. I understand you have REST and sockets

Patrick: yes, the socket is when you need to be notified of a change

Magnus: data model the same between REST and WS?

Patrick: yes, same structure

Magnus: regarding converting it to a Note, that is kind of saying you can have it but it is deprecated

PLH: no it is not deprecated
... we do not have an official recommendation for CSP1 yet it is widely deployed (in all major browsers)
... there are plenty of examples where things less than full REC are implemented
... in this case your estimates were missed so skeptical about being able to be done within 3-4 months which doesn't take into account the W3C process and patent disclosures
... we can declare victory on v1 but put energy on convergence with a v2
... clearly market is not going to be able to use the v2 right away so there will be lingering interest in v1

Magnus: time to market for auto is rather slow so yes 1-2 years is expected
... VISS is a subset of RSI as I understand it and the result will be somewhat different. RSI can support more use cases out of the box
... VISS can handle it
... I don't see a big technical reason for closing work on VISS

Ted: work can continue if eg there is an issue, regardless of the doc status as a WD, CR or Note, fixes can be made. send a pull request

Dan: what I think would be interesting here is how the Web can be a force in opening up this ecosystem
... we have seen this with smartphones, now with TVs
... it does feel like there needs to be a roadmap and how things open up to 3rd party developers
... I might not like the dashboard that shipped with my vehicle, i might want someone else's

Ted and Paul: it won't be an open marketplace, controlled by OEM for liability/safety reasons but market forces for popular apps or dashboards could pressure OEM to allow them on their marketplace

Patrick: we want everyone to be able to developers
... we have things like distractability to consider

Hadley: my previous understanding was this wasn't for mission critical systems

Ted: correct but safety and review is necessary

Gururaja: we need to focus on a clear data model. when can an application access a signal
... is a REST approach a detriment to performances for some use cases
... when it comes to a head unit there are many other components, REST may be better for some of the other areas like WBS
... a gap analysis would be worth doing

Caleb: is WS better than REST?

Hyojin: I don't have a strong opinion as Urata mentioned it would be worth continuing pending time constrants


Janina: there are many people who are excited about what is taking place in automotive
... there are not any accessibility specific concerns raised yet

Judy: I'm the director of WAI at W3C, Janina leads the accessibility horizontal review for all of W3C's standards
... we also produce guidelines. often people think a11y doesn't apply to their standards work initially when it should be taken into consideration

[Introductions around the room]

<kaki3> https://translate.google.com/translate?hl=ja&sl=auto&tl=en&u=https%3A%2F%2Frp.kddi-research.jp%2Fhackathon%2F2017%2Fresult

Ted: we are being joined by Janina Sajka and Judy Brewer on Accessibility. While we are defining services and not UX APIs we may still want to consider collaborating with W3C's Web Accessibility Initiative (WAI) on guidelines. People with varying needs are going to want to be able to pair their devices with vehicles to gain information and interact with it. Distractability is a major concern for applications on the head unit and WAI has various work on multi-modal that may be very applicable to that area.

Janina: I am particularly interested in autonomous vehicles but also need to give thought to the incremental changes we will be seeing in the industry
... I want to hear if people are still looking at a model of having a vehicle customized to their needs
... we are seeing a new model in the industry, usage versus ownership
... when you think about usage model, the accessability needs increase. for someone with needs you are relying on the driver completely
... you have to think of the transition from the vehicle transportation to the next point, where you are letting someone off and where they need to go next
... for a blind person taking an autonomous rental car how do you inform them when their vehicle arives?
... blind users are extremely excited about the possibility

Patrick: autonomous driving was not yet on my mind at all. for what we are discussing (at W3C) all we are working on is user interface
... I see the benefits of an abstract representation and how to make that data available

Janina: we dealt with that in ARIA with min, max, increment

Patrick: I have no grasp of what is lacking

Ted: autonomous vehicle interactions are likely to be more directly coupled and not go through any of the specs we are working on, however think of a blind person wanting to use their device to direct the car instead of needing to learn a vehicle specific UX. That can leverage our spec work

Janina: there are varying disabilities such as cognitive and difficulty with eg numbers, they would require a different interface
... we need to think about the incremental improvements and should check back in
... also think about the aging community

Judy: there is an assortment of disabilities, Janina mentioned some. there are also adaptive ones for physical needs

Ted: instead of custom controller hardware needing to be permanently integrated into a specific vehicle, the user can bring their device and pair with any vehicle that supports these standards

Patrick: a software solution could replace the current hardware ones as well

Judy: what is the term for the individual in an autonomous who would be the navigator, responsible for the vehicle's direction

Patrick: we see every passenger as equal in that model
... there can be right restrictions for eg a bus where route and stops are predetermined with no local overrides
... for hailing a vehicle I see fewer buses and more vehicles available for individuals. if you have specific needs then type of vehicle can be requested from a communication device

Janina: and a way to tell me when my particular vehicle arrives, eg a specific tone

Patrick: or vibration

Caleb: are there introspection APIs or annotations to allow discovery of features, to see if it able to lower itself or play a tone

Patrick: right now, there is no discussion like that since there is no entity interaction defined
... when describing what an engine looks like on a data/api level we can go into detail now
... I do not have a model for defining eg an electronic steering wheel right now
... there is a central db to see all that is available in a system for a car, see what services are available and all the data elements they expose
... it is discoverable

Magnus: the same applies to VISS, there is a way to ask what signals do you support

Ted: we are also granular on access, you may only get a subset of what is available for your specific application

Magnus: you have to bear in mind that you will not always be connected to the vehicle. your device needs to pair locally

Judy: two things to mention from our other guidelines work is multi-modality and user choice
... I hope many times deferring to the social situations from the passengers, there would be times a single designated authority for the vehicle could be identified; and also it could be helpful to allow for different signaling modalities, for instance for a passenger who is deaf-blind.

Patrick: we are learning quite a bit now internally on multi-modal for graphical and voice interfaces
... I am pretty sure I can build many interfaces with the same protocols and data
... I am not aware of any situation where we had to extend capabilities to handle additional interfaces
... we normally start with graphical interface and then work on spoken. I am quite confident that we can create multiple user interfaces

Ted: +1 to the need for a "designated" driver - authority for where it goes
... next steps how about sending to me and public-automotive@w3.org specific parts of ARIA or other documents we should look at
... we can start a wiki or other to start collecting use cases
... from the broader WG and those in the room we can see who has time and able to contribute


Ted: aka the infamous issue 223

Ted: since we first considered a static hostname it always seemed awkward and at the outset we also considered discovery mechanisms.
... it seemed every time someone new came into this group, this piece stood out like a sore thumb
... in the simplest case there is only one service and one device (the head unit) connecting to it seems over-engineered which was why people wanted to keep it simple. we are hearing now there may be multiple services and also interest in allowing devices on vehicle LAN to pair
... discovery also has challenges/concerns

DKA: so what about a discovery mechanism, what are the concerns there?
... hardcoding is kludge

Ted: requiring each developer to implement discovery in their code seems onerous especially in the simple case mentioned
... doing discovery at each reboot of the car or when application is launched is a waste/delay. it also presents opportunity for a rogue device to broadcast mdns to hijack a client application, steal its credentials and later impersonate that app

Hadley: a hardcoded hostname is still spoofable

DKA: PKI should help avoid spoofing

Ted: public keys for service will likely be self signed as public CA registry would have difficulty signing local host/IP cert not to mention. there is a breakout on Wednesday for that topic

Magnus: to me this should be implementation specific and not something that necessarily belongs in the spec

Ted: the group agrees discovery is the way to go but it opens up a number of additional potential issues

<hadleybeeman> Web of Things architecture: https://w3c.github.io/wot-architecture/#wot-client

Hadley: WoT punted on the issue

Ted: I have provisional approval from W3C Director for a w3.org hostname to get around .local issue, they would like to see a final proposal

DKA: what is the issue with .local hostname?

Ted: we have no right to lay claim to a .local hostname

Magnus: I don't see how putting this on w3.org solves anything

Ted: it doesn't, same issue as .local but the difference is W3C is SOA for w3.org and nobody owns .local

<hadleybeeman> See https://www.ietf.org/rfc/rfc6762.txt"9. Conflict resolution"

Proposed: organize a breakout session for Wednesday as issue is not unique to Auto, also WoT (deferred), Entertainment (eg 2nd screen)

[Separate breakout didn't occur due to conflict with Executive Summit. The topic did get some coverage in HTTPS with local CA]

Paul: can we simply put a note in the spec to allow people to choose for their vehicle implementations?

Ted: we could but that breaks cross vehicle app portability

Patrick: I was thinking of a central registry, a complete list of all services

Hadley: more of a traditional DNS instead of mDNS?

Patrick: yes

DKA: if you are talking about a registry then you need hardcoded names

Ted: I think for apps on IVI, part of the install process can do zeroconf (DNS, mDNS or other) and store actual local conf for an application to avoid having to do rediscovery
... that improves performance, reduces attack options. in the case of smartphones or tablets, they would need to do discovery for every new vehicle that app pairs with but could also store locally after initial pairing
... also makes it so devs don't need to implement discovery per application, the app install framework handles it
... OEM can even ship the static conf for a given vehicle as part of an app package manifest

Hadley: I encourage you to solve for broader needs and to be more flexible and forward thinking

Resolved: agreement vehicle should handle discovery but may ship or handle via implementation specific (or discovered on app install) configuration

HTTP and Sockets

Patrick: also interested in your (TAG) thoughts on mixing sockets and http

DKA: that or polling is how others are doing this on the web. There is also WebRTC data

Hadley: using WebRTC here would be kludge to

DKA: fetch may be replacing sockets

[discussion of HTTP2 connection limitations for our need]

DKA: that would be worth putting in queue for broader TAG review
... web sockets seem to suit your needs

Caleb: problem is everyone essentially creates their own unique API for interactions in sockets
... some basically choose regular HTTP methods (GET etc) within sockets

<hadleybeeman> Please put an issue here: https://github.com/w3ctag/design-principles

DKA: there are discussions in IETF beyond HTTP2, QUIC (continues on SPDY)

Magnus: what is the timeframe for that?

Ted makes snarky comment about how QUICk we went from HTTP1.1 to HTTP2

DKA: evolution is much faster now
... it even optimizes some of TPC for HTTP

<hadleybeeman> Magnus: quic https://duckduckgo.com/?q=quic+udp+&t=brave&iax=images&ia=images&iai=https%3A%2F%2Fimage.slidesharecdn.com%2Fquicoverview-141102192659-conversion-gate02%2F95%2Ftechnical-overview-of-quic-5-638.jpg%3Fcb%3D1414956498

<kaki3> ・Extended Vehicle Methodology ISO 20077 & Extended Vehicle Web Service: ISO 20078 http://taysad.org.tr/uploads/dosyalar/18-12-2014-01-26-5-Extended-Vehicle---a-proposal-for-sharing-diagnostics-data-in-the-future-Scheiblich-ve-Raith-Daimler-27-11-2014.pdf

<kaki3> Can We use the host on the web instead of the local host?(VISS Server on Global Web) If yes, we can cover the use case of ISO Extended-Vehicle, I think.

<kaki3> (The story went side by side,Sorry)


Ted: first we should discuss issue 233 on whether VIAS should be a wrapper JS library or an API spec, getting some pushback on it going forward toward REC but agreement on encouraging lib development

[summary of how it came about, reasons for pushback]

Patrick: I was a big fan of a convenience library for RSI initially, it is rather complicated and have since changed my opinion
... not everyone will be using the same language (JS) so it is for a limited audience

Paul: if people want to use one, they'll create it

Patrick: similar to current concerns for QUIC, it isn't widely supported in many programming languages at present

Paul: one of the reasons we continued to talk about VIAS is that people may not want to use REST or sockets but something more like a WebIDL API
... not sure it is right or wrong
... ACCESS had implemented the previous (WebIDL) approach

Urata: basically using VISS directly is ok but not as convenient as a JS library that we developed at the start

Paul: part of the discussion about the higher level api (VIAS) is that it does not *need* to talk to VISS, it could go directly to signals in some other manner

Urata: VISS is designed to use web sockets in the first place, later it could do HTTP


Patrick: WebIDL is a browser extension. now I can understand VIAS can be either a library or extension
... that is interesting and makes sense. the problem is the protocol you are using has to fullfill all the requirements of VISS
... as we just discussed, there may be multiple, separate VISS services (ECUs) providing set of signals

Paul: both interfaces need to be defined separately

[Patrick goes to the whiteboard, diagrams the complications of multiple path options]

Patrick: when you start defining what a client wants and what a service offers, it has possibility to clash
... you are the client of the user of the data
... I agree having something easier and more intuitive to a developer makes sense

Paul: this can be either a WebIDL or JS library

Ted: W3C doesn't standardize JS libraries

Magnus: I have always seen VIAS as an implementation (of VISS client library)

Patrick: VIAS does not need to interact with VISS, it can have some other means besides sockets to access the information/data tree

Paul: it was originally conceived as a JS library and second thought was extension/WebIDL route

Gururaja: in Genivi we define things lower in the stack in Franca IDL

Patrick: they are not defining the data elements nor getSpeed but get(/engine/speed)

Paul: what is consistent is VSS

Ted: this is proposed as either an extension or JS lib. the former is reasonable to standardize at W3C, latter not and either is confusing
... there is a potential for competing libraries to come into existence and may prevail in community over ours

<Paul> https://www.w3.org/TR/vehicle-information-api/

Ted: we are being encouraged to convert this to a W3C note and for making this (or other library implementations) available online in our github repo or point to external eg at ACCESS

[earlier Ted explained we are asked to reflect and can appeal proceeding but seeing resistence in doing so. W3C wants to avoid imposing on the group but may decide to block]

Ted: think also about the app developer - how are they to know if they need to include a JS library or if they will be running in a browser runtime with built in VIAS support?
... app would have to be written in both flavors that breaks cross platform compatability

Paul: one of the reasons we moved to a service approach is it was going to be challenge to convince more than a couple browser vendors to implement WebIDL

Hira: as Paul was saying we have discussed and concluded VIAS is a high level WebIDL that is agnostic about the underlying architecture
... I would like us to move forward on VIAS as it is

Patrick: why is VIAS important/desired?

Urata: it is a convenience API for developers, it can be a wrapper to VISS

Patrick: I agree a convenience JS library makes tremendous sense
... I question if it needs to be formally specified
... I want to have it

Hira: underlying architectures will be up to OEM

Patrick: the argument makes sense as a browser extension but not as a library

Paul: if we remove JS implementation would that be acceptable?

Urata: we could remove that paragraph

Ted: we would then need at least two browser vendors to implement

Paul: Access, the others in this space are OBIGO, Genivi which is using Igalia

Patrick: I definitely want more convenience and having it as a standard would be nice but not required
... the underlying protocol is more important and a JS library would be acceptable

Paul: one of the reasons we moved away from WebIDL was the lack of browser vendor interest in embedded vehicle platforms
... KDDI and ACCESS remained interested in WebIDL approach as the group decided they wanted a service
... what we need is more support from auto manufacturers and I believe they are using a wide variety of browser runtimes

Gururaja: I think both are important

Paul: security and performance is an issue

Patrick: with both VISS and RSI there was choice to start with protocol
... we can use these without changing the browser engine
... if we are building a browser extension, there is no reason to use a web socket

Magnus: does it matter if there are competing JS libraries?
... if someone wants to implement their own library with a different approach, that is fine

Paul: it doesn't matter. to an OEM they may require which libraries they permit on their head unit
... they scrutinize what is allowed on the vehicle which is why you see so few apps at present

Caleb: developers are not going to want to work with such a restricted environment, you want to have competing libraries

Ted: a browser extension spec would limit developers' environments, they would need to have a browser on their dev machines (preferably laptops) that have these extensions

Urata: I understand W3C Director is opposed to standardizing a JS library. if we remove that paragraph would it be possible to standardizing?

Ted: yes but we would need more browser vendors

Urata: what would be their recommendation?

Ted: publish VIAS as a Note and encourage releasing as a library. people will be very excited to have a library
... having the library available would be very helpful for adoption in the industry

Junichi: I would like you to ask you to consider who would write the library?
... this is a bit different than building into a browser
... developers might be using FF, Chromium etc but in case of VIAS they would need to test against various VISS servers
... OEM will provide library implementations. I think we will need some standardized document

Ted: if anyone feels strongly that VIAS should continue, then we will need to find another browser vendor since we require multiple implementations for W3C standards process. If anyone has a JS library implementation I encourage them to release it, they can do so on our github repository. Closed source optimized ones that are tuned for a specific browser runtime could be created as well.

Patrick: as an OEM I would not pay extra for such a specialized browser runtime

Paul: it helps to step back and think about why we are doing this in the first place?

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/11/21 14:45:14 $