See also: IRC log
Apgenda+ Github repositories
Adam: you may have seen the latest rawgit version of the spec
Adam: we have introduced tables
to go along JSON now instead of WebIDL
... it is a more readable format. some others need to be put in
table still
... eg AuthorizeRequest
... there is an open issue on preference for discover instead
of getVSS in case there are additional data
https://github.com/w3c/automotive/issues/210
scribe: we are considering discover which Rudi found a bit too generic and settling on getMetadata
Adam: we are continuing to
discuss the nuances of * wildcard
... we are leaning toward single set
Rudi: don't we return the status of the signals in the response?
Adam: no we don't
... this would allow us to give an error for each case
https://github.com/w3c/automotive/issues/142
Rudi: we do want to know clearly what happens on write
Gunnar: is this multiple responses when you are doing a single wildcard set?
John: we do similar to pump
nozzles at service stations. for example we are unsure whether
to enable diesel or regular nozzles
... we enable all for that pump as we don't know yet. any
nozzle that doesn't work will get an error code response
... similarly if one door isn't lockable you should get a
response informing you that
Adam: that is definitely sensible
Rudi: maybe the best way is for each object to give a response
John: we name each nozzle to make it distinguishable and you should be informative instead of merely using a sequential number
Rudi: one response with array of objects. an overall status is easier 200 OK
Adam: I'm concerned about adding complexity and wonder if it might be better to turn it into separate requests
Rudi: one request with a
wildcard, you get a status code on the request and json for the
affected objects
... if there is an error than client can try again or examine
json
Kevin: question is where to put
the complexity, server or client
... you could make it the servers responsibility to support
requests for many things and detailed information can clarify
which error for what item
... alternately an OK (meaning all were successful) and another
indicating an error occured and then the client has to deduce
which failed or retry
... we are not doing transactional state and reverting all on a
single failure
John: some but not all times you
need to know which failed and then can query which
... for service stations 99% all succeed and in the 1% you
query further to find out individual state
... this is the most efficient approach for the developer
Rudi: true these tend to be reliable and things tend to succeed
Gunnar: I agree we should
optimize for the success case
... can I distinguish partial success versus other types of
errors such as a poorly formed request
Adam: yes we have various types of error responses
Gunnar: makes sense to me
https://github.com/w3c/automotive/issues/132
Adam: getVSS should return
information about all signals available regardless of acls.
client should know what signals it needs and would like to
access via get/set and be refused if it asks for others
... private branch should remain separate
agreement with Adam on his interpretation on expected behavior
https://github.com/w3c/automotive/issues/91
Adam: Kevin has a diagram for
this one that will be circulated shortly
... can someone elaborate on token replay concern
[[Provide comment about application level tokens, and protection against replays/spoofing of tokens]]
Adam: timestamps have been added
Kevin: the channel is encrypted
and shouldn't be sniffable. if someone got control of the
client then yes they have access to the token
... I'll work on improving the wording there
Adam: state level diagram is a work in progress
Kevin: done as about 5 minutes ago, just needs review
Adam: we believe the best approach is the client acts responsibly and can make the request as often as it wants
Ted: it isn't like we are opening
up the car to the world, limited number of client (apps on the
car)
... same as how people combat excessive traffic on the web, a
server implementation can block an excessive client
Kevin: we have an error code for
this case
... we might want to make it more explicit
Adam: we only mention this in the filtering section
Kevin: so it's in there but not enough explanation
Ted: probably sufficient as is
Kevin: with vacations we expect to be done with these within 3 weeks
Ted: Gunnar, what would be the best venue to promote our specs and get feedback?
Gunnar: genivi-projects list seems the most appropriate
Ted: I'll subscribe and post a publication announcement
Urata: thank you for the advice
comments and publishing the WD for VIAS
... it is kind of in a static status
... I recently noticed some small mistakes and corrected them
and made issues for them
... regarding getVSS there was an inconsistency with respect to
handling path compared to VISS
... I started to create a prototype of VIAS
... I am wondering about the next step for VIAS moving to the
next stage (CR)
Ted: getting feedback is
necessary and hopefully will be able to enlist some from
Genivi, your implementation can help with our feedback
requirement
... we also will need to work on testing for VIAS but can
hopefully leverage your tests for VISS
Urata: Hira has a test document started
Ted: the corrections are merged as I don't see an outstanding PR?
Urata: yes
... issue was simple and clear and did the review myself
Ted: I'll go ahead and republish
to www.w3.org/TR then since we can do that as frequently as we
want with WD
... please see GH IPR manager email, feel free to ask questions
and if necessary we can discuss at a subsequent call
... expect an email on launching the payments TF shortly as
well
Peter: I hope to finish my implementation report before vacation and after we'll be done with our reference implementation
Urata: in your implementation are you also working on VIAS?
Peter: no just the server, VISS
Urata: I think my prototype VIAS should work with your VISS server
[adjourned]