Automotive Working Group Teleconference

14 Jan 2020


Ted, Adnan, Magnus, Ulf, Glenn, Peter, Daniel, Guru


F2F Spring 2020

Ted summarizes points from his email, need to set next f2f and perhaps extend it

Gunnar: in April or May but not determined yet I think


Magnus: a hackathon would be fun, with prep in advance ahead of the meeting

Ulf: I also think it is good to add a couple extra days

Glenn: agree with extra days for a working session as it could be highly productive
... I could look to hosting it in Toronto as well

Ted to create survey for which calendar week and location

Daniel: Tel Aviv an option, will confirm

End of February, early March

Single tree blocker PR:315


Ted: last week I summarized Daniel, Adnan and my conversation regarding single tree and that I would go over wording to be more flexible. looking at commit of mine that Ulf approved, I think it is sufficient plus per convention we can raise an issue later if not. let's accept this pull request

Ulf: agree with what you said

Daniel: I am the point where I'd accept anything on this

Ulf to handle the merge

Access restriction ISSUE: 322


Ulf's email

Ulf: we have two authorization servers as part of our implementation at present
... issuing and validating access token as needed by client requests
... the authentication isn't complete and key handling is plain text but functionality is there
... to be able to use this it must be possible to tell what signals should have access protection
... hence interest in tagging nodes or even a branch with all subsequent leaves
... we discussed my solution last week and went ahead and implemented it
... question of layers comes up as a result

VSS layers ? concept

Ted: where is layers? link?

Gunnar: haven't presented it more widely yet
... you could have multiple files in vss format and makes it possible to decouple
... it extends to giving different categorized access with the categories descriptions, adding metadata
... you can add additional metadata or override

Daniel: for deployment we use something similar, basically a file next to original with grouped signals
... metadata can be added after
... we put some work into that internally and could potentially open it up

Gunnar: I thought the layers could be using YAML as well

Daniel: we did the same
... you may have different layer files depending on where the data is being accessed

Adnan: it is quite similar

Gunnar: we are doing same thing in Android conversation around VSS signals

Daniel: it can do translations between different data types

Gunnar: I have gone through the rationale. you have different definitions about privacy restrictions in different jurisdictions
... core question becomes what Peter alluded to, how do we include in the W3C spec
... do we make a VSS concept and describe that?

Peter: I agree

Ted I get this jist of this but would like to see a writeup or examples. I am thinking this might be solution for some of the other desired metadata we have been discussing and have issues open on VSS repo such as accuracy, signal frequency

Gunnar: it could contain any arbitrary metadata, in Android we are tying into those permissions, different for different use cases

Daniel: we describe the mechanisms but the content is produced by the service owner/implementer
... we should come up with commonalities including Ulf's suggestions
... at the end quite a bit touches the base system

Gunnar: can we define a core set in W3C spec or not?
... not really part of a protocol specification

Ted: Adnan and Daniel will look to see if they can open up what they have and Gunnar please send pointer to layer concept for people to digest more

Ulf: chapter 6 as it is is fully implementable, the only thing lacking is possibility to tag certain nodes
... in ViWi everything has the same access restriction

Gunnar: any consideration about putting signals into different groups read to some and write to other?

Ulf: that is a possiblity and using inheritance mechanism if branch is tagged. lower in the branch can have different restriction tag

Gunnar: I am thinking more of different clients having different access to different signals

Ulf: ViWi has scope terminology and concept - scope tag is defined

Gunnar: is scope always one subtree or something different?

Ulf: it needs some thinking
... please look at scope part of chapter 6

Glenn: I agree with Gunnar, we need to be able to set level of access to data
... I'll send you a note Ulf about how we have negotiated this with some manufacturers, their process

VSS Rbranch removal, new issue ?

Peter: my understanding is rbranch was added and some feel it may not be necessary any more

Ulf: I added it as a possibility to try to bridge the gap between VSS and ViWi data models, trying to combine in one model
... there has not been any interest in using it
... I think we should remove it. As I added it, I can remove it

Ted: I think simpler is better if we don't need it. otherwise we are conceptually like a regular tree

Ulf, Peter and Daniel agree

Ulf: anyone over in Genivi relying on it?

Gunnar: no


Ted: I want to wrap of VISS, ask that Gunnar, Ulf, Adnan and Daniel look at version issue in Genivi repo. If that is acceptable to include in VSS root, I'll update VISS spec to include it and say if not provided VSS is potentially v1.0

Gunnar: we discussed WAMP at one point and hope it isn't too proprietary
... WAMP is well defined

Ted: charter discussion next time https://www.w3.org/auto/charter-2018 as we are far behind and need to update expectations

Gunnar: one last pitch for WAMP

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2020/01/14 20:15:27 $