See also: IRC log
<inserted> Github issues
Adam: we have gone into the
various issues including the language configuration one
... to be able to distinguish preferences
... the remaining open issues include refactoring api
Paul: I believe we came close to a consensus on that one
Qing_An: we discussed the language issue and reached consensus on refactoring
Dave: we were ok with where they stood but sought input from other working groups
Paul: Philippe Le Hegaret responded in-line on that issue
-> https://github.com/w3c/automotive/issues/37 Refactor API Signatures
Kaz: we can ask various groups in person at TPAC
Ted: I recall you (Paul) asked
the TAG for their input and that Daniel Applequist acknowledged
it but forget the details
... they are meeting this week and I will inquire if this is on
their agenda and if we should expect a response
Paul: Daniel asked for a summary
of what we were looking for and although we intended to do so
at the face to face we did not
... Philippe had a few points in his response
... (to editors on the call) can you help identify what we want
further focus
<kaz> Refactor API signatures issue (#37)
Dave: it was a pretty long discussion thread with some back and forth but it is fairly clear
Paul: I'll get back to the TAG
Kaz: we discussed using some
GeoLocation API in LBS and would be good to get feedback on
that as well during TPAC
... we can create breakout sessions on Wednesday
Kevin: part of the problem is we
have not settled on a consistent sense of zone yet
... a 3x3x3 cube makes the most sense
... zone left would represent 9 cubes in that plane
... it would cover uses like camera on right front bumper
(bottom - 1 cube)
Ted: I agree on 3x3x3 as the most logical. Some OEM don't deal with top/bottom (zenith/nadir) for specific items and that is fine, API would give null values if queried for them
Greg: blind spot monitoring needs
to follow the object being tracked
... as such it needs to be consistent
Kevin: you may not care about
vertical dimension in that scenario
... there are times you would want to just say front or back
(and skip left/right)
Ted: in such a case asking for front right or front left should give the same value
Shinjiro: you may also have a
camera facing outward and another inward within the same
zone
... 3x3x3 is a simple and good concept but there can be
exceptional cases that will need more
... we can come up with specifying name for direction the
camera/sensor is collecting data from
Kevin: an extra attribute could
help for orientation
... such as external or internal (facing)
Shinjiro: if we decide to put
there more details, there will be also cases where it is not
available
... the 3x3x3 zone system is good but do need flexibility for
additional particulars
... such exceptions may need to come up with their own
identifiers for the additional parameters
... i would provide a specific strings to describe that
camera
Paul: in summary 3x3x3 is
basically alright but we need to provide a mechanism for
exceptions
... how to cover that will be the challenge. we need clearer
use cases. at some point we need to define our world as finite
and cover what is realistic
... it is not worth the effort to cover everything possible if
it isn't useful
Greg: it sounds like we should move forward with 3x3x3
Paul: agree until we encounter the more complex
Ted: agree we need to be finite but perhaps provide some flexibility, additional optional data points or how the api can be extended. We can also consult DAP WG as they may have some varying device capability discovery
<kaz> kaz: we have a basic requirement/restriction of concentrating on usual passenger cars (not buses or limos)
<kaz> Paul: right
<inserted> scribenick: kaz
ted: the published draft is
getting out of date
... we can publish an updated draft automatically
... the master branch document on Github can be published
automatically
<inserted> scribenick: ted
Adam: how would this work?
Ted: we can deem the master branch to be the one to publish automatically. Kevin was in favor, want to hear from other editors before we adopt
Adam: I am in favor of it
Greg: in a different venue/group
I've been working on use cases as well
... it is nearly impossible to write an exhaustive set of use
cases for something like security
... people will consider such a set complete when it is
not
... somewhere we would need to include a disclaimer,
Paul: yes that it is just informative, that makes sense
Kevin: I agree
Hashimoto: I want to work on
security requirements at TPAC based on the use cases
collected
... I have shared six privacy items from forty or so use cases.
We should do the same for security
... yes the use cases are not exhaustive and informative but
can contribute to requirements
<j-hashimoto> https://docs.google.com/spreadsheets/d/14ij-2I-H4HbilVQ_muCmUayVqmVfdbkoke690MA0kdo/edit#gid=0
Paul: that makes sense to me and segues to the next items - privacy and security update and f2f planning...
Hashimoto: we have produced
privacy requirements
... I want to get opinions on privacy and security requirements
from others in the group
... we should create a draft at or before TPAC
... also it would be good to be able to get input at Genivi
Paul: the Genivi AMM would be a
good place to get feedback at with the various OEM and Tier
1s
... who plans on being at Genivi? I haven't seen many
registrations yet
-> https://www.w3.org/2002/09/wbs/61259/20151023_BG_F2F_SEOUL/ BG registration for Genivi
Hashimoto: for Genivi AMM we should give introduction/overview on W3C
Paul: there is an opportunity to
give a high level introduction to Genivi members, but we also
will be conducting BG meeting on LBS, security etc
... the security group in Genivi is having similar discussions
to ours
... there is Fabian from PSA and Jeremiah from Pelagicore (sp?)
plus people from Visteon and Bosch. we should see about
liaising with them
... we should try to get some of them to join us for the BG
meeting
<peterW> Its Pelagicore
Paul: for the W3C intro it would
be similar to one Adam A., Ted and I did
... who on this call will be attending Genivi?
Adam: Kevin and I will not be at Seoul but will be at Sapporo
Qing_An: unfortunately no
<j-hashimoto> junichi and hirabayashi-san will be attenging.
-> https://www.w3.org/2002/09/wbs/35125/TPAC2015/ TPAC registration
<kaz> [ will attend both Genivi and TPAC :) ]
<peterW> Looking to go to Sapporo
<peterW> not korea
[ted will be at both]
<inserted> Genivi registration
<inserted> BG registration
Hashimoto: I wonder how many OEM will attend the BG meeting
Paul: often the same cast of
characters (PSA, JLR, we have had BMW)
... Hyundai sometimes comes to Genivi but has not been at a BG
meeting in awhile, similar with VW
... as Ted said it would be good for people from this group to
attend Genivi AMM tracks as well for liaising
Ted: we can ask eg Philippe Robin to communicate an invitation to join the BG meeting as observers to Genivi AMM participants in addition to doing so in our intro about W3C
Paul: I'll reach out to Philippe about trying to get more engagement
Kaz: Do we need to register for Genivi meeting itself?
-> https://www.eiseverywhere.com/ereg/newreg.php?eventid=134067&& Genivi AMM registration
Paul: they have Open Automotive which is open to the Public, the other sessions are closed to Members
<PaulBoyes> http://genivi.org/amm-2015-october