[FPWD published]
-> http://www.w3.org/TR/2015/WD-vehicle-data-20150616/ Vehicle Data
-> http://www.w3.org/TR/2015/WD-vehicle-information-api-20150616/ Vehicle API
-> http://www.w3.org/blog/news/archives/4764 Top page news
-> https://lists.w3.org/Archives/Member/member-cfe/2015Jun/0005.html Call for Exclusion
Paul: remember to register if you haven't yet so we know who is coming
-> https://www.w3.org/2002/09/wbs/76043/20150728_29_F2F/ F2F Meeting registration
Paul: I want to discuss F2F agenda as well
Greg: would privacy and security task force meet separately as well or during this general F2F?
Paul: there will be sections of the general F2F on privacy and security, plus some invitees coming explicitly for that
Greg: perhaps we should start defining what we hope the tf to produce and establish timelines
Paul: Hira has some suggestions sent
to the list
... if people are not in the tf yet please join
ted shares notes (probably should send email to public list) on separate meeting, evening split between privacy and security. potentially meet once before f2f
Greg: I am working to get there or would be willing to participate remotely with a possible presentation from AAA
Paul: I'll send follow up for scheduling those calls. this is always difficult given timezone differences
[various parties express difficulty in attending in person but interest in participating remotely]
Paul: we will have some way to dial in
@@@: when do we expect more mature, robust versions of the specs available?
Paul: from my perspective what we have is usable as is with potential for refinement. I expect it to be considered fairly stable
Kevin: I am not clear yet the impact security will have on the spec
Peter: I saw an issue in github
raised by Dave Jensen on refactoring the API. From a cursory read
his ideas seem really good
... it would streamline the API
Paul: I need to look into it further
https: //github.com/w3c/automotive/issues/37
Paul: Either way I do not see that
being too drawn out and can be implemented pretty rapidly
... I'll review outstanding issues, see several resulted in merges
and bring bigger topics like to WG for discussion
... F2F will afford us time to hash these out in more detail
... we had a call with Qing An and Wonsuk Lee on handling of merges
and concensus yesterday
... Given timezone Adam and Kevin you weren't there so will
summarize now
... We have a number of editors and want to make sure there is not
chaos. Qing An and Wonsuk will review and handle all merge requests
from the other editors
<inserted> Editor's call minutes
Adam: I am happy to continue sending pull requests and letting them merge into the master
Kevin: If there is concensus on the call we would them start to work on it. Unsure why we need two levels of editors
Paul: Basically it is a question of concensus and having merges handled smoothly. The content changes can come from any of the editors
Kevin: I am fine with this and we can review if there is a problem
Paul: Agree, we need communication and coordination to avoid anyone mistakenly step on someone's toes
Qing An: I agree with this
Paul: I will send an explanation of this to the list and as said it is not etched in stone
Adam: Fuel subtype gets very messy as outlined in issue 13 and wonder if anyone has input on this
https: //github.com/w3c/automotive/issues/13
Adam: when it comes to percent ethanol for instance it gets unwieldy
Paul: subtypes only makes sense for some fuel types like gasoline but not applicable to electric
Adam: I am looking for a way to organize this best
Paul: subtype is restricted to certain values based on supertype and not sure the mechanism for defining this in WebIDL
Adam: I will look more into how to represent this
Paul: I want us to try to have all outstanding issues resolved by our next call
Peter: I will ask a colleague for input and get back to you Adam
Greg: We have posted a couple suggestions on battery status and diagnostics
Paul: you have defined the elements
and we need someone to create the interface
... battery one is more straight forward, the diagnostics is more
involved
Greg: there is already mention of indicator light being on but not duration. it would be nice to have the diagnostic code as well
Paul: Initially they stayed away from ODB type diagnostic interfaces but they should be there
Adam: Not sure how to implement since they will be OEM specific
Greg: there are a number in the US
that are mandated to be returned in a specific manner
... there is no reason all the codes cannot be made available
Paul: I do not disagree what we need
is someone to start defining the interface
... Adam had the start of an interface but if you want to come up
with a proposal from AAA we can evaluate it
Greg: can we extend on what you meant by extensible battery type?
Adam: there may be subtypes we are not aware of that we cannot list explicitly in an enumerated list of types
Paul: the list may change and we need
to be flexible to handle them
... there may be ways of noting other means, attributes
Greg: this is the list as we understand it today and for the next five years
Paul: if you and your group can explore what attributes you envision we can review it
Ted: as Adam said this is OEM specific and unlikely something we would present the user directly through IVI system. As part of the pending privacy discussions the owner might have data rights and can elect to share that raw data with a third party like the OEM or mechanic. We can keep the interface simple and only grab codes available.
Paul: I will continue to riff on the
agenda and ask the group to focus on the issues list
... Kaz and Ted, do you want to work on timeline and stick around
after this call?
Kaz and Ted agree to stay on
urata: I wanted to say something on
the API refactoring. We have two different and opposing
opinions
... I want to have conclusion as it can influence the whole thing.
Do we have a sense when it will be decided?
Paul: I want to have it worked out by July 7th which is our next call
Urata: It would be good to have Kevron and Dave on the next call so we can understand better and weigh in on the best course
Paul: I'm hoping the discussion will
continue in github. Kevron is no longer in the group but we can
invite him to a dedicated call to discuss
... I have to get more familiar with this issue and want to give
others the chance to read up on it more fully
... If we need a breakout call for a specific issue we should do
it
[discussion on Security&Privacy TF initiated by Junichi]
Kevin: I want the TF to focus on use cases initially and work with other W3C groups, car is just an expensive thing in the WoT
Ted: the other groups are eager to meet with us and I suggested we wait until we have scope of our concerns and intended work defined
Kevin: yes, there may be places we want to see higher level web security mechanisms produced
Ted: in addition to use cases we need to identify attack vectors of what is being worked on in BG and WG
Ted lists the pros and cons of a dedicated wiki or using existing given write permissions
Suggest a new wiki with write permission open to both BG and WG
Kaz: I propose Hashimoto lead this TF, setup wiki and start to schedule calls
Paul: that is fine and if others step
forward wanting to lead we can consider them
... Hashimoto-san, will you please send a survey for scheduling the
teleconference?
Hira: Hashimoto should identify a policy first with timeline
<kaz> https://www.w3.org/auto/wg/wiki/Main_Page#Publication_Schedule
same as milestones in http://www.w3.org/2014/automotive/charter#deliverables
[[Note: The group will document significant changes from this initial schedule on the group home page (link to be added once group approved).]]
Kaz: per the new process document we can collapse LC and CR which means we can keep to the rest of the schedule
Ted: is this something we can decide as Team Contacts and Chairs based on our estimations or do we need group agreement?
Kaz: we should get agreement from editors
Paul: I'll update the wiki and send email