<scribe> Scribe: Ted
<scribe> scribenick: ted
https://www.w3.org/auto/wg/wiki/Auto-f2f-oct-2020
https://www.w3.org/auto/wg/wiki/Auto-f2f-oct-2020
Ulf: maybe we should have discussion on Gen3
Ted: agree, look at what we
deemed out of scope for Gen2 and consider a Gen3 or
extension
... goal will be to finalize and adjust days based on
individuals' availability
Ulf: I invented the naming in the
Gen2 specs, this is a variation of getMetaData from VISS
... but now when we have a service catalog work started maybe
should not use that
... might be better as signal discovery, you want to know as a
client what signals there are
Ted: +1 from me to use signal to
avoid confusion
... last time we also went on tangent of whether restricted
signals should be reported back to client
Gunnar: agree
... we can leave the other topic for now
Ulf: whether a node is restricted
or not should be made clear
... we have a policy document with scope list that enables
signal discovery as well for certain roles
... we have that mechanism right now
Ted: can that be applied to private branches as well, since they may be sensitive ones there as well
Ulf: absolutely
Ulf: I was again reflecting on the new service catalog work and relate on naming
VSC / CVIS
VSS / VISS
MagnusF: how about VSS-protocol, protocol for transporting the data
Gunnar: I am also partial to
VISS2 or VISS version 2
... I don't see why it needs to change
... what is a model, what is a catalog...
MagnusF: we will face the same
things with VSC
... I still like the -protocol appendix
... we want to avoid confusion for those seeking compliance and
certification
Gunnar: just this last week I had
two presentations and do not want to replace existing
acronyms/names and would like some consistent
... we should come up with something for RPC as Ulf has done in
his comment
https://github.com/w3c/automotive/issues/333
MagnusF: I don't feel strongly, VISS2 may be same protocol for both signal and rpc instruction
Ted: agree that is a high level design goal
Ulf: I'm happy with how we furthered this
Gunnar: as I listen to this, I
hear we have open question on relation between Gen2 and
RPC
... I am opposed to renaming VSS and VSC but could see those
two combining
MagnusF: collapse of signals and services
protocol in synch
@use VSS in VSC
MagnusF: I agree
... inverse is not true, you can service not associated with
signal
Ulf: agree as well
Ted:I have heard concern from a
couple different people we are jumping to solution without understanding problem more
...early eval of RPC protocols, not decision time. we would at most prototype and play/contrast
...align with Gen2 architecture as we expect it to be intertwined with RPC
...use VSS in VSC, not new set of signals
...more use cases, further understanding of problem trying to solve. Glenn cited several and sent SAE doc to list
...need stakeholders coming from other side, who would likely be using this RPC service and accompanying catalog
https://www.w3.org/Consortium/Member/List
Ted: I am reaching out to some companies but if you can connect me with current or prospective partners, that would help. If they are existing W3C Members, may be easier to readily engage them as already through legal obstacle
Gunnar: hope people can be free to express to the group at large. on RPC protocol we still need to be clear on which is proposed
https://github.com/w3c/automotive/issues/326
https://github.com/w3c/automotive/issues/340
Ulf: 326 we discussed last time
and think I got an action on updating, use the same handling of
error information in WS and HTTP
... I updated the spec accordingly which is 340
... I also did some minor cleanup
Ted: I will review those
[adjourned]