https://www.w3.org/auto/wg/wiki/VISS-RSI-convergence-framework
https://lists.w3.org/Archives/Member/member-automotive/2018Jul/0007.html
Ted: [provides summary of recent
calls, AGL comparison of VISS and ViWi, how to handle multiple
VISS servers, data flattening]
...(in response to Patrick on motivation for flattening) we want to
at least agree on a single data model if there are multiple access
methods (VISS and ViWi/RSI)
PatrickL: we are totally willing to adapt to something (VSS) being defined at Genivi and used at W3C
Ted: tree and depth still an issue though
Ulf: my hope was we can continue
using the tree structure for vehicle in VSS and then open to
adopting structure from RSI
... I am not in favor of significant changes to the tree
PatrickL: some might not be as clear as it should be
https://www.w3.org/2018/07/12-auto-minutes.html
https://doodle.com/poll/avrcb7thiyawtvug#table
cancel 31 July
PatrickL: potentially also 7 and 14 August
Rudi: I am fine with that
Others: fits with my vacation schedule
Gunnar: I might be away next week
PatrickL: we will work on
homework assignments for next week for the summer break
... reviewing the todo list
... perhaps today we'll continue with status codes
... goal is to try to stick with the obvious http status codes
where possible
https://www.w3.org/TR/vehicle-information-service/#errors
[[401 for too_many_attempts The client has failed to authenticate too many times.]]
Ted: that might be better as 403 since 401 can loop indefinitely
Gunnar: agree we should use http codes from ViWi for http of version 2
PatrickL: it does seem a bit overloaded for a few of them but they reason conveys the details
Magnus: rest for VISS is a new
concept so why should we keep the old status codes if we have
them already for RSI?
... we should use the http standards
Gunnar: if we want VISS backwards compatibility in v2 we should stick with the existing codes
Ulf: we want a transport agnostic solution across either http or web sockets
Gunnar: for vehicle signals you
want publish and subscribe mechanisms
... we should align things so we do not care about the
transport protocol and therefore best would be to align the
codes as well
... backward compatibility also should be considered, and if we find mismatch in return codes, we should evaluate the best solution case-by-case
PatrickL: that is our first
summer homework assignment
... we will listen to feedback from current VISS implementers
and moving forward try to align and consistent with http
... that was quite easy
... Addressing. what we do not have yet is an addressing scheme
for VISS and should work on that so it is backwards compatible
and transport agnostic
... services can appear on multiple IP addresses and different
schemes
... we should come up with a clear one
Gunnar: I took a quick look at
the service registration API in ViWi
... you address a particular registry server when you register
a service. in it we will have multiple addressable services,
will that be known by the registry
... wording had me wonder if it would be relative to the
registy server
PatrickL: the case might be
worded better. you can have a short handle, a relative uri
instead of absolute
... you should be able to address anything in the network
Gunnar: is there a single registry server?
PatrickL: not necessarily. client needs to find a registry. every service is responsible for adding itself to the registry including where they are available
Gunnar: wording suggests relative to registry server
PatrickL: noted to self for
clarifying document
... we have no notion of several networks and different IP
addresses at present. it is possible to be more complex
networks but expect it to stay somewhat simple
... we decided against local DNS
... we decided every data exchange should be done with the same
protocol. for the service registry you could talk to mDNS but
left it out of scope
... for a developer how to find the services available is a
core start
... we want portability across brands
Gunnar: agree, my personal
opninion is it can be deferred until the spec is further
along
... for VISS we talked about it in circles for awhile
... it is still on the open topic list
PatrickL: if we want to transport
protocol independent, client needs to know which to use to
access service
... maybe that is something registry holds in addition to
location
... a service can have multiple addresses and support multiple
transport protocols
Ted: we had some internal discussions some time back with Tim on protocol-less uris. This stemmed initially from sites serving the same content under http and https uris although the discussion extended to other protocols. I will look to see if there are public findings from Tim or W3C Technical Architecture Group (TAG)
Gunnar: first request for web sockets is http and an upgrade
PatrickL: client connecting would need to be able to handle one of the protocols being offered by the server
Ted: I also wonder about using redirects to switch between protocols although that too may be difficult for developers
Gunnar: we may want to limit some type of services to a single protocol (http but not sockets for media for instance)
PatrickL: for next week please
review the todos from the convergence wiki for your summer
homework assignments. I see addressing as one
... please choose one you are inclined to delve into or want
others to
[adjourned]