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
https://lists.w3.org/Archives/Public/public-automotive/2020Jan/0006.html
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
https://github.com/w3c/automotive/commit/7f3ddfb2f8cf09b09b403f65ac6e5787dc03c10a
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
https://github.com/w3c/automotive/issues/322
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
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
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