See also: IRC log
adam: we'll start off with
introductions, explain the differences between the business
group and the working group
... agenda outline deviates a bit from email as we went over
based on feedback
... there has been quite a bit of input to date on the vehicle
api spec in the wg
... we'll review the state of the spec
... we will be more formal about use cases and
requirements
... there is desire to have a conformance test suite
... we'll discuss securiry and privacy
... we have presentations planned from KDDI and ACCESS on their
early implementation. we had an enlightening presentation last
time from JLR on what they ran into on implementation
feasibility in their case
... there will be a call for editors. we have some house
keeping things to take care of as well
... spec maintenance and timeline, call cadence and of course
future meetings
... please feel encouraged to speak up at any point
... my name is Adam Abramski, I have been involved since the
workshop in 2011
... i came from a more mobile background, moved over to IVI and
started coming to Genivi
... i have done quite a bit of work web side on mobile
... Genivi has things called Expert Groups, there was a Korean
group with work on a signals specification
... there was interest in taking that early work and turn it
into standards. at Intel i do project management for tier 1 and
oem in auto
paul: i'm Paul Boyes. i started
getting involved in Genivi in 2013. my background in software
is for the military and medical
... i'm employed by OpenCar
havald: my name is Harald Walter. i am a project manager with T-Systems and for work with auto manufacturers. interested in vehicle spec
william: my name is William Han from Obigo. from a technical background i am in charge of business development now
<inserted> jenny: Jenny Jeon from OBIGO
jade: I am Jade Moon working at Obigo. we have been working on browsers for some years. we are doing work with BMW on IVI browser and involved in Genivi
shinjiro: I am Shinjiro Urata and work for ACCESS. last year i implemented with KDDI browser and the current vehicle API
<Paul_Boyes> Here is a link to the spec analysis presentation that JLR gave in Oct 2014: https://lists.w3.org/Archives/Member/internal-autowebplatform/2014Dec/att-0000/JLR_to_W3C_Presentation_presented_at_genivi.pdf
justin: my name is Justin (Jeon Seon) Park and work for LGE. i am involved in creating web OS platform for various products. i hope to make more time for standards work
osamu: my name is Osamu Nakamura and work for W3C from Keio and site manager there. we are extremely interested in automotive activity
adam: i am Adam Crofts from JLR
kevin: my name is Kevin Gavigan and work for JLR. we have been involved in the bg and working group
peter: my name is Peter Winzell
and work for Mitsubishi. i have been following this effort
since the workshop in Rome but only getting involved now
... I'm involved in software development and we are working
with Volvo on IVI. we are doing some R&D with a local
university and might be able to do a reference implementation
there
... also very interested in security
ted: my name is Ted Guild and one of the groups' two Technical Contacts
bernard: I am Bernard Gidon and
work for W3C from France, focused on Business Development for
Europe, Middle East and Africa
... besides automotive, i am also on wot
wonsuk: wonsuk: I am Wonsuk Lee with ETRI. I am also very interested in IoT/WoT, have some previous experience on specification editing for SysApps
jonathan: my name is Jonathan Jeon from ETRI
<kaz> kaz: W3C staff contact for this Automotive WG with Ted
tatsuhiko: I am Tatsuhiko Hirabayashi (Hira for short) from KDDI. i hope to share with this group our findings on implementing vehicle api
adam: the difference between a BG
and WG are subtle
... BG can write reports, the reports can vary in nature
including producing early specification work
<kaz> adam: BG can't publish any Web standards
adam: use cases, requirements etc
adam: we WG can get W3C staff
contacts
... GENIVI has been involved with the BG for years
... they have open codes
... e.g., speech recognition
... GENIVI was wondering how the Auto BG could help them
<JonathanJ2> comparison group type - https://www.w3.org/community/about/agreements/compare/
adam: we can collaborate with
other groups
... in our charter, there is a section on liaison
... the list includes 15-20 organizations
... security is one of the target topics
... would show some slides
... on the difference between the groups
(Inputs to Standards Process)
<JonathanJ2> process figure - http://www.w3.org/2014/Talks/chairs-part4/#/35
adam: Community Group (or
Business Group) there
... W3C Members can work with the groups
... we started with the workshop, created a business
group
... the business group has 130 participants
... a lot from automotive industry
adam: the BG could help us
... BG may generate use cases and requirements
... GENIVI is doing a lot
adam: WG is a place for creating
standards
... some WGs concentrate only one spec
... some does many
... it's up to groups
... how to solve security for Web applications, etc.
... there are a lot to learn from what SysApps WG does
... the group can decide how to do
... what's our first focus area?
... one team can do some topic, and another team can do another
topic
... there are several people who participate in both the BG and
the WG
... may work on security, media api, speech, etc.
... any questions?
... the BG is on its rechartering procedure
bernard: the key point is this is
YOUR group
... you can do anything
ted: can have task forces to
handle privacy
... can talk with the privacy IG
adam: because we have a WG, we
have W3C staff who helps us
... feel free to talk with them
hira: given the WG has been established, wondering about the need for the BG
paul: there is a different level of membership
<ted> Possible Work Areas identified at previous F2F
hira: it might be better to have a single group by merging both the BG and the WG
ted: WG should be focusing on the
REC process
... test suite, liaison with related groups
<ted> BG is more an incubator for new areas as identified earlier
<ted> wonsuk: in sysapps, tizen has tried to make their own apis as has firefox os and chrome
ted: we reached concensus on
scope of work for sysapp between those parties
... i can see this BG and WG arrangement where the former
provides possible use cases and requirements
... we need to try to make small sets of specifications at
first and we can add on to that over time
... we need to focus on core pieces like this api and then we
can extend it for the rest of the ecosystem
adam: accomplish a small chunk
first, build a test suite around it and then see if there is
more that should be added or if the BG or others in the mean
time have additional use cases to consider
... the BG work on the draft spec was more ambitious than i
expected, i thought we would only get 50 or so signals not the
200+
... i'm very interested in KDDI experience and reminiscent of
JLR's report on theirs
kevin: the people at JLR that
worked on that are based out of Portland, Oregon
... some of the internal issues included the physical
constraints or lack of data pathways through specific
buses
... there were also business cases for being reluctant to
expose some pieces
adam: one of the things that surprised me was that oem did not have certain rights from third party ecu
paul: i agree, starting small on
something you can work on is worthwhile. it was a small core
that drove the draft bg spec
... one of the obstacles is indeed people holding back for
competitive advantage and reducing the common pool that can be
standardized
kevin: the current and next product line is set in their ways, the research branch working on future products are increasing awareness and usefulness of open standards
adam: it took a couple years to
get where we are at with the spec. we started with a couple
rough proposals
... we needed to merge LGE and Intel work (amigo/tizen)
... there was a group from the EU that webinos, w3c, bmw
explored other possible spec work including nav and vehicle
data
... there is a common set of data elements all oem are suppose
to expose through ODB-II (on-board diagnostics) standards,
required by governments but of course there are differences
there
... we found enough common ground from all these
... all of those pieces that contributed are public
... we had quite a few contributions from PSA, GM and JLR
<Paul_Boyes> https://github.com/w3c/automotive-bg/blob/master/W3C%20Vehicle%20API%20Creation%20Guidelines%20v4.docx
adam: BMW early on from webinos side but then faded away
adam: we had good input from oem
paul: much of this is online and
linked from those resources in irc
... you can also find a fair amount of history on the
wiki
... the specs were broken in to two parts since the access
methods seemed stable and the data was subject to more
change
... one of the things that come up is concern for system load
in providing this data
... we should organize a primer and history
... the initial use cases were kept deliberately simple to keep
the scope narrow
... some of the higher level use cases move well beyond the
spec
... Kevron Rees (Intel, co-editor with Justin Park LGE) gave a
walk through on a teleconference to this WG recently
adam: have most people looked at the two specs?
<Paul_Boyes> http://lists.w3.org/Archives/Public/public-autowebplatform/2013May/att-0025/vehicle-api-comparison.xlsx
<JonathanJ2> https://lists.w3.org/Archives/Member/member-automotive/2015Mar/0057.html
tatsuhiko: if there are additional interests from people in the WG, can we (=WG) ignore BG's opinions and move ahead based on the *WG*'s decision?
kaz: if we create task forces
from this WG we need approval and input from chairs on how to
organize
... including when to send things back to the BG, and we could
think as if the BG were a big TF of the WG :)
paul: biggest thing is we need to get people together and actually contribute to the work
(2: SIP Credit)
urata: governmental project
(3: About ACCESS)
(4: Netfront Browser NX)
urata: HTML-based UI
... used by Nintendo and Sony
(5: SIP)
urata: cross-ministerial
strategic innovation promotion program
... next generation ITS study
(7: SIP)
urata: participants include KDDI,
ZMP and ACCESS
... 3-year project
... two types of experiments: vehicle API implementation
experiment, probe data collection
(8: Goal)
urata: goal of the vehicle API
implementation experiment
... evaluate APIs' feasibility
(9: Onboard Hardware)
urata: use Toyota's Prius as the platform
(10: R-Car H2 Lager board)
(11: ZMP CarTomo UP Pro)
urata: OBD2 logger
... has bluetooth capability inside
(12: System Overview)
urata: Netfront NX Browser and
Data Broker on the R-Car H2 Lager board
... we don't have knowledge how to pick up the CAN data, so are
using a packet translator
(13: Software Component)
urata: two components: vehicle API polyfill and Data Broker
(14: Vehicle API Polyfill)
urata: inside the polyfill
software, there are several layers
... a web application sends subscribe to this polyfill
(15: Supported API)
urata: subscribe() interface is
ok
... there was some problem with get() due to JSON
communication
... JSON RPC
... when we send many get()
... can't identify one of them from the other
... many get() methods are put on the queue
... but the relationship with each method is vague
... and can't identified
(16: Supported Data)
urata: 9 data features are covered
(video)
urata: this video was taken
within a genuine Toyota Prius we use for the experiment
... actual scenes within the car
... vehicle speed, engine speed, steering wheel angle, etc.
(scary :)
urata: there is a problem with
latency
... though it's already working
(19: Result)
(20: Latency)
urata: explanation on the
delay
... latency of 1.8-2.0 seconds
... 0.7sec between OBD2 port and Receiver thread of the Data
Broker
... 1.1 sec between the Receiver thread and the Web
application
... we can improve the latter part easily
... but need a smarter mechanism to improve the former part
(21: Next theme)
urata: for this year
... Vehicle API native implementation, Increasing supported
data interfaces (but can handle 20-30 of them because using
OBD2 as the source)
... improve performance
(22: Thoughts on Vehicle API
urata: as for subscribe()
... when the callback is called?
... several possible options: 1. when value changed or
pre-decided time span
... 2. periodically, e.g., several times per a sec
... 3. each time whenever data has been sent from the
vehicle
<Qing_An> Where can we get the presentation materials?
(23: Thoughts on Vehicle API)
urata: get supported zone list from vehicle?
<ted> [Qing An, yes we should ask them to be sent to the mailing list]
urata: Prius has 4 doors and 4
wheels
... but what if we want to use a different car?
... it would be convenient if we could get a supported zone
list from the vehicle itself
... also would be better for after-market IVI systems to have
zone lists for various vehicles in the market
... another question is if the ZonePosition extensible
... e.g., 3-D position like top and bottom
... or even glove box and trunk
(24: Thoughts on Vehicle API)
urata: how to specify a
zone?
... in normal cases, we can specify the zone using X-Y
positions
... but value[] can have indefinite values
... "Front" for all of front wheels at once?
(25: Thoughts on Vehicle API)
urata: how to specify a
zone?
... getting wheelSpeed with no zone specified
... what should be returned with only "front-left" and
"rear-right" are supported by a specific car?
(26: Thoughts on Vehicle API)
urata: Time-out of get()
... the queue for get() may overflow unless there is a
mechanism for timeout
... getHistory() (currently changed to history.get())
... many things to be decided for the actual use
... how to know which vehicle interface supports history?
... where to store history data?
(27: Thoughts on Vehicle API)
urata: acceleration interface:
better to use signed value?
... multiple methods for fuel consumption
... fuelConsumption, InstantConsumption,
averageConsumption
... different from my images of fuel consumption
(28: Thoughts on Vehicle API)
urata: don't need interface for
Roll and Pitch as well as Yaw?
... DrivingMode interface vs. DriveMode interface
... enough for having just two states for light position
(32: JSON Packet Sample)
adam: trying to another
car?
... assuming OBD2 signals are similar but could be different
with each other
hira: talking with car manufactures
wonsuk: web server?
urata: web socket server?
... an open source one
wonsuk: not using Node.js?
urata: no
... during yesterday's demo session, we showed the demo of
this
adam: plan for implementing the data broker natively?
urata: it's already a native
app
... if we change the JS to native app, the translator can't be
improved
peter: thoughts on security?
urata: not yet
hira: for the next step
hvald: what is the criteria of good latency and bad?
urata: depends on apps
jade: plan for plagin implementation?
urata: possible
... we'll implement native APIs
... not sure if we really need to do that, though
justin: currently there are many overheads
urata: checked within the data broker
urata: can change the
configuration for buffering
... to reduce the latency
jonathan: bluetooth version?
urata: bluetooth v2.1 SPP profile
ted: i have yet another idea for you to consider on handling latency we can discuss over lunch. idea is based on client rendering time, how long it takes and to use it to set pull or push frequency back through web socket to data broker and for the client to discard stale json based on timestamps and what was processed last.
wonsuk: typically we do cold
start
... which code part takes how long time
... we should have that kind of time information to improve the
performance
urata: using some tool
adam: profile analysis
... this discussion is really helpful
paul: i sent a few links to the mailing list
-> http://www.w3.org/2014/automotive/data_spec Data Spec
-> http://www.w3.org/2014/automotive/vehicle_spec Vehicle API
<Qing_An> ted what time slot would agenda item of "use cases" and "call for editor" start? Around CET 15:00?
-> https://www.w3.org/community/autowebplatform/wiki/Main_Page BG wiki with details of spec work
paul: we use github, a tool from
w3c called respec
... it is done in multiple parts and assembled
... the access api is really the methods for the gets,
subscribes etc and the data spec for the signals
available
... we need to define scope for this group
<JonathanJ2> if you want try another channel, you can try it - https://appear.in/w3c-auto
paul: what is missing from the spec, what issues are there, to track this work
<kaz> Automotive WG Charter
kaz: FPWD could be our current
drafts with a few minor modifications
... the other stages listed are Last Call, Candidate
Recommendation (including implementations), Proposed Rec and
Recommendation
<JonathanJ2> W3C process document - http://www.w3.org/2014/Process-20140801/#Reports
<JonathanJ2> TR procedures - http://www.w3.org/2014/Process-20140801/#recs-and-notes
kaz: w3c recently changed the process a bit and we have a choice, we can collapse LC and CR
<Qing_An> ted when will the afternoon session start?
paul: the implementations really help to show what is working and what doesn't
https://github.com/w3c/automotive-bg/issues
[discussion on issue tracking. the recommendation is to use github issues for the spec itself. for general group issues not directly related to spec and concrete actions to be assigned we should use tracker]
-> https://www.w3.org/auto/wg/track/ Tracker of Issues and Actions for the Auto WG
<Qing_An> kaz I may have to leave around CET 14:00, to take the flight. If agenda item "call for editor" starts, could you say on behalf of me that I want to work as the editor of use cases or security? I already discussed this in email with paul
action paul to work with Ted and Kaz on github repository layout
<trackbot> Created ACTION-1 - Work with ted and kaz on github repository layout [on Paul Boyes - due 2015-04-30].
ted proposes to remove -bg and to use the one sub repo for both wg and bg since some work will be shared or transition back and forth between the two
<Qing_An> yes
paul: we should involve the yet to be named editors in those choices, Justin?
ted: Wonsuk?
Wonsuk: umm, we'll see
adam: and from JLR?
kevin: i'll need to ask
14CET - 2000 CST
[negotiating when to resume and take up use cases with Qing_An]
qing: that will not be convenient for me but will look for colleague from Alibaba to attend instead
action adam to send out formal call for Editors
<kaz> Manual of Style (Editors' guideline; please see section 5)
action-2?
<trackbot> action-2 -- Adam Abramski to send out formal call for Editors -- due 2015-04-30 -- OPEN
<trackbot> http://www.w3.org/auto/wg/track/actions/2
[discussion on role and time commitment for editors. comments are scattered]
Editor candidates: Wonsuk Lee (ETRI), Justin Park (LGE), Adam Crofts (JLR)
[adam reviews afternoon agenda before breaking for lunch]
[use cases, test suite, security/privacy, presentation from JLR]
<Qing_An> ok
<Qing_An> action-2?
<trackbot> action-2 -- Adam Abramski to send out formal call for Editors -- due 2015-04-30 -- OPEN
<trackbot> http://www.w3.org/auto/wg/track/actions/2
kevin: we have started looking at
implementing the vehicle api and data spec
... there are some areas in security we will not cover such as
lack of signal encryption over the can bus or replay
vulnerabilities
... I have been reviewing web security techniques as applicable
to this
[slides being sent to the mailing list]
scribe: we've been looking at
threat surface, potential attackers, use cases, web/internet of
things, access control and conclusions
... line around the diagram (slide 4) is the attack surface,
includes smart home devices, cloud services relied on, devices
brought into the car, individuals who can get physical access
to the car etc
... the two major category of attackers is external and
internal. for internal they would need to learn internals of
cars and can buses plus read dense books
... this is more plausible given who the target is, eg
celebrity, head of state
... Advanced Driver Assist System (ADAS) controller sets should
be the *only* thing allowed to write to steering wheel, brakes,
etc
... you need to authenticate and ensure the instruction is in
fact coming from the ADAS unit
... you also need to insure important data feeds that this
controller relies on (cameras and sensors) are not interrupted
or spoofed
... ADAS - traveling in convoy. vehicle behavior should be
comparable to vehicles around it
... cars slowing down ahead should be able to alert vehicles
behind it. the problem is trusting that data source
... people may want to share their data close to real time,
show people the sites they are seeing or updates on location
for expecting when they will arrive
... for that you need to identify and authenticate the
recipients
... car will be the most expensive thing most people will buy
that will be part of IoT/WoT
... expectations are higher given the higher price
... you may be connecting IoT things from your home to your car
- fridge telling you that you are running low on milk
... access control needs to be an integral part of the
equation
... also need to be able to handle use cases from authorities
and aggregate anonymous information for studying traffic
patterns, etc
... the security challenges are more complex given the number
of data inputs
[slide 12]
[vehicle api is an example of a WoT API]
kevin: some might err on trusting
more initially and refining over time
... there are federated trust scenarios that may help. your
vehicle trusts itself and identifies itself through PKI
... your home devices can register that public key
[slide 13 - further reading]
bernard: the W3C WoT IG will have an overarching security view that should be brought in
kaz brings out the paper diagram from WoT meeting earlier in the week...
kaz: agree auto should collaborate with both WoT and WebAppSec WG
<JonathanJ1> minutes from WoT IG meetings - http://www.w3.org/2015/04/20-wot-minutes.html http://www.w3.org/2015/04/21-wot-minutes.html http://www.w3.org/2015/04/22-wot-minutes.html
kaz: and btw our TPAC (Technical Plenary & Advisory Committee) meeting in October might be a good place for a future F2F
tatsuhiko: i would like to
propose a security and privacy tf of this group
... KDDI would be willing to bring in experts to contribute
<Dapeng> Hello all, I am Dapeng Liu from Alibaba Group. Qin an works in my team, He can not continue to attend the meeting due to a business trip.
<Dapeng> yes
ted counters with having this in BG with overlap for various reasons enumerated (not scribed because ted is also scribing..), tatsuhiko agrees a joint tf would work
<Dapeng> Is there any way I can see the slides?
-> https://lists.w3.org/Archives/Member/member-automotive/2015Apr/0009.html JLR presentation on privacy & security
<Dapeng> Thanks!
including WebAppSec and Privacy IG
<kaz> Web Application Security WG
<kaz> Privacy IG
<Dapeng> OK
<kaz> list of all the W3C WGs/IGs (Member-only)
wonsuk: i agree with the creation
of the tf. question is who will be leading it
... we need to clarify the scope of their work and ensure
proper interaction with the other pertinent groups in w3c
jade: is the web the most secure platform?
wonsuk: very much depends on the parties involved
jade: i agree but what about all the underlying pieces all the way down to the OS?
peter: we have a product we had to pull because of a particular vulnerability in the browser engine being used
paul: you can have trusted, pre-installed (or limit installation) apps that can only interact with trusted sources
peter: true. we had to poke holes in the firewall immediately for music applications
wonsuk: browsers can share reputation of sites used. we need way to have identified and protected sites that users can use
osamu: with trusted servers CA and predefined list can be done fairly securely
wonsuk: we started off with some
heavy security focus in sysapp group but that fell apart due to
key resources being drawn away by their employer for other
work
... a store approach for apps that can run in the car provided
there is enough and regular review
... google is looking for ways to allow for more api use
... webapp is often compared with native apps, definitely pros
and cons
... native apps require compatible devices and same app
installation on all sides
... instead of sharing a link
osamu: it is very different
trying to protect a closed native app versus webapp. closed
isn't necessarily secure
... MS Windows is closed and frequently attacked. Linux is too
but much more scrutiny and review
... the proposal is an organization to review car apps can find
some common vulnerabilities but think that is outside this
group's scope
wonsuk: signed apps from developers risks their reputation. in case any issue is detected they are subject to further scrutiny
osamu: every app should be
signed
... todays legit app is tomorrow's malware
peter: we need to think about the
usability of the api
... we need to view it as a layer and focus ourselves on what
we are producing, nothing more
paul: when people talk about connected cars, they usually are not talking about full open connection to the web but controlled access
kevin: it is not just signatures
on apps but man in the middle (mitm) attacks you need to worry
about
... you can do replay attacks on can buses. there is a wide
range of things that need security hardening in vehicles
osamu: various people will give
the false sense of security of running on a closed network -
home network
... the basic understanding should be changing
<kaz> Content Security Policy
kaz: webappsec has been working
on CSP (see link)
... we should be following these sort of specs with our use
cases in mind
... this is a great discussion but we need to do it with
them
ted: we need to keep our focus on our specs with the assumption any app might try to run them. i have some thoughts on best practices architecture layered security i intend to write up
kevin: there will be a pressure
to open up even access to steering, brakes etc for legitimate
uses and would be acceptible if it weren't a security
concern
... legitimate ADAS assist
... ADAS if it uses the api is a trusted entity with different
rights. obviously not something we want other parties
... that problem has to be solved
... you can have trusted modules within the vehicle itself. you
cannot check identity all the time so you need some
adam: great discussion but how to move forward. agreement on need to form the joint tf and obviously liaison with the other groups
kaz: we can simply generate requirements and bring to respective groups
<kaz> hira: KDDI is happy to provide a moderator for the joint TF for the Automotive WG and the Automotive BG
<kaz> kaz: please note that we should start with discussion on use cases and requirements. JLR's presentation today should be included in that
<kaz> ted: several points we got consensus
<kaz> (some more discussions)
<kaz> ted: can generate a draft Call for Consensus
action ted to draft a public blog cfp on joint security tf to run by group before announcing
<trackbot> Created ACTION-3 - Draft a public blog cfp on joint security tf to run by group before announcing [on Ted Guild - due 2015-04-30].
<kaz> hira: please note we should concentrate on what should be done within the Web layer :)
<kaz> ted: sure
<Dapeng> Yes, I am online.
<Dapeng> Is there any question for me? can not hear clearly
<kaz> hira: also please remember the TF should be a "Security and Privacy TF"
<kaz> paul: three main use cases for today
<inserted> Dapeng, do you have any opinions on the expected TF on security and privacy?
<Dapeng> OK. I agree that security and privacy is very important for our group.
<Dapeng> We also work on automotive security inside Alibaba group. We would like to contribute on this topic.
Dapeng, absolutely. we will be forming a security and privacy task force
<Dapeng> OK, great
adam: Alibaba started producing some use cases on our wiki
<Dapeng> Yes
-> https://www.w3.org/auto/wg/wiki/Use_Cases Alibaba's Use cases
<Dapeng> My colleague Qinan would like volunteer to be the editor of the use case draft.
<kaz> ok
adam: please review them and
provide feedback. Alibaba said they are willing to do more and
we should invite more in this group to contribute
... there has also been discussion of producing a conformance
test suite
<Dapeng> Yes. We believe security and privacy is very import aspect of the automotive group. We would like to contribute on this topic and see what we can do.
ted: we don't want to wait too long before starting as it becomes more insurmountable
paul: the charter is pretty clear, we need it by CR
adam: question is do we have a recommended test framework we should use
ted: kaz has more WG experience than I. I know a few use different frameworks and the systems team has one they use. if Kaz doesn't have a concrete recommendation i'll seek input from other groups
adam: also are we testing the spec or the implementations
kaz: the latter
wonsuk: the various test cases can be run against implementations. an implementation may not implement all features and only use/pass some of the tests produced
action kaz to recommend to the group how to create test suite
<trackbot> Created ACTION-4 - Recommend to the group how to create test suite [on Kazuyuki Ashimura - due 2015-04-30].
adam brings up deliverables timetable
ted: we are already behind! we
were overly-optimistic in getting this group started sooner
than we did. charter dragged out and we should have changed the
dates
... as soon as we get commitment for editors we can take our
existing drafts, we could produce our FPWDs based on the
current drafts plus minor number of outstanding issues
bernard: want to talk about recruiting more participants in this group
adam: we have Bernard for Europe and Alan for US
ted: Sam for Japan
bernard: Karen as well for US
ted: Kaz and I are also available for this group
paul: 4pm US is 8am in APAC
... so suggested two different time slots alternatively
adam: twice a months
... change the slots every month
bernard: 4pm US is 1am EU
adam: is Korea in the same time as Japan?
jade: yes
paul: there is no daylight saving in Japan or Korea
adam: we could adjust on our
side
... 4pm west coast and 9am west coast
<Justin_LGE> http://www.timeanddate.com/worldclock/meetingtime.html?year=2015&month=4&day=24&p1=317&p2=235&p3=137
adam: maybe 8am would be better?
<Justin_LGE> it would be helpful to convert
bernard: we can try and ask people for opinions
<JonathanJ2> 4PM Las vegas, 8 AM Korea/Japan, 1 AM Geneva, 7 PM Boston
paul: but not on Tuesdays
... 8am on Wednesday works for me
<inserted> ted: nevermind, let's stick to Tuesdays
<ted> resolved Tuesdays
adam: talked about F2Fs last night
<ted> http://www.timeanddate.com/calendar/monthly.html?year=2015&month=10&country=8
adam: Tuesday/Wednesday are
pretty busy for the Genivi guys
... there will be TPAC 2015 in Sapporo
<ted> http://genivi.org/events
<ted> [[GENIVI ALL MEMBER MEETING
<ted> October 20-23, 2015
<ted> Seoul]]
adam: great opportunity to have f2f meetings with related groups
<ted> http://www.w3.org/2015/11/TPAC/
adam: maybe including the Web of Things IG
<ted> [[Sapporo, Japan26-30 October 2015]]
adam: lot of great synagies
... what we thought of was having the BG meeting at GENIVI
meeting
... and then having the WG meeting on Friday in Seoul on Monday
during TPAC 2015 in Sapporo
... at TPAC there will be talks by W3C management guys
including Tim Berners-Lee
ted: and technical plenary part
is open to everybody
... might want to have a meeting on Mon/Tue including a TF
meeting and/or breakouts
kevin: sounds good
<ted> Proposal: BG in Seoul on October 23rd, WG in Sapporo on October 26th and 27th
<ted> action abramski send F2F proposal to both mailing lists
<trackbot> Created ACTION-5 - Send f2f proposal to both mailing lists [on Adam Abramski - due 2015-04-30].
adam: yet another f2f meeting
before TPAC 2015?
... might be in Seattle or Silicon Volley
... Paul is located in Seattle
... and we had a BG meeting in Santa Clara
... those two proposals in July
... can send an email and ask group participants for
preference
<scribe> ACTION: adam to send out a message to show the two proposals (Seattle, Santa Clara) to the groups to gather preference [recorded in http://www.w3.org/2015/04/23-auto-minutes.html#action01]
<trackbot> 'adam' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., aabramsk, acrofts).
hira: June or July?
paul: anytime between now and October would be appropriate
adam: will send the message
soon
... will send our suggestions
wonsuk: ok
... we don't have enough time \
s|time \\|time|
adam: what to do?
... can we publish the spec as FPWD?
wonsuk: we just publish the draft
generated by the BG with some edit
... but we could split the spec into two pieces and then
publish them
<JonathanJ2> deliverable schedules on charter - http://www.w3.org/2014/automotive/charter#deliverables
wonsuk: the spec has two pieces,
get and set (read and set)
... given the security consideration is important, we should
once remove set options
<JonathanJ2> FPWD : Q1 2015, LC : Q3 2015, CR : Q1 2016, PR/REC : Q3 2016
osamu: some application might use
get option badly
... so get is not necessarily safe
wonsuk: right
... but we could separate the spec into write spec and set
spec
kaz: would go for publishing the draft as is :)
<JonathanJ2> +1 FPWD ASAP
kaz: and we could add an editor's note saying "security consideration is important here"
paul: right
wonsuk: let's go straight forward!
adam: reviews what to do
... can talk with Kevron as well
paul: the data spec itself would
move forward
... functionality provided in US
... some features are specific to some vehicles
... would start with speed
ted: we should look at extensibility aspect as well. there are provisions to do so but should be a process to report back to us for when new features become common to multiple oem
paul: what about compliance for
spec
... such as those done by ACCESS
kevin: location for tomorrow's meeting?
adam: institute de francais?
(Kevin shows the map on the projector)
adam: will send a message on the floor
[ adjourned ]