[portland-f2f] minutes - Day 3 - 28 July 2016

available at:
  https://www.w3.org/2016/07/28-auto-minutes.html

also as text below.

I've included the updated version of the group photo with the
JLR logo :)

Thanks,

Kazuyuki

---
   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

             Automotive WG F2F Meeting in Portland - Day 3

28 Jul 2016

   [2]group photo

      [2] https://www.w3.org/auto-f2f/photos/28/DSC_0146.JPG

Attendees

   Present
          Rudolf_Streif(JLR), Kevin_Gavigan(JLR),
          Adam_Crofts(JLR), Joonhyung_Kim(LG_Electronics),
          Wonsuk_Lee(ETRI), Magnus_Feuer(JLR),
          Powell_Kinney(Vinli), Peter_Winzell(Mitsubushi),
          Paul_Boyes(INRIX), Junichi_Hashimoto(KDDI),
          Shinjiro_Urata(ACCESS), Tatsuhiko_Hirabayashi(KDDI),
          Kaz_Ashimura(W3C), Ted_Guild(W3C)

   Regrets
   Chair
          Paul, Rudi, Peter

   Scribe
          ted, kaz

Contents

     * [3]Topics
         1. [4]OCF Collaboration
         2. [5]JS Library
         3. [6]Service Spec - WebSocket
     * [7]Summary of Action Items
     * [8]Summary of Resolutions
     __________________________________________________________

   <inserted> scribenick: ted

OCF Collaboration

   Magnus gives background history

   Magnus: we have shown IoTivity RVI interactivity and it was
   well received
   ... we had a similar demo and meeting at Intel last week
   ... they are doing the same thing as W3C with VSS but from IoT
   perspective
   ... what we have from Genivi is a commitment to support OCF
   ... typically standards are top down, here we are doing the
   reverse starting from vehicle perspective and pushing it upward
   ... there are many expectations waiting for getting this
   information out
   ... there will be iterations and feedback as this gets more
   widespread review
   ... we want to avoid vendor specific implementations and years
   of darwinian standards wars
   ... we need OCF
   ... we are coordinating with OMA as well
   ... they are coming from a telecommunications background
   ... we are trying to find a fit for them in this OCF, W3C,
   Genivi mix
   ... clearly we need telco at the table
   ... from their (telco) point of view auto offers them no more
   than a way to sell a data pipe and we want more
   ... for instance we need to know if a door unlock signal gets
   delivered

   Rudi: nearby Kaz reported yesterday about his meetings with ITU

   Magnus: nice

   Rudi: they documents from ITU are a bit dense and didn't delve
   into realtime yesterday but took action to examine further and
   see whether and how we need to coordinate

   Magnus gives an example of not being able to get clear
   information on bytes being delivered by a major carrier

   Kevin: this environment needs to be able to gracefully degrade
   based on connectivity

   Magnus: we need serious traffic analysis to be able to detect
   port scanning and anomalous early for possible probes and
   attacks
   ... we'll get there

   Kaz: WoT group is also working with OCF/IoTivity
   ... another joint meeting between Automotive and WoT at TPAC

   Magnus: we should be sure to have a presence there
   ... have you discussed Genivi's security group rechartering?

   Rudi: some and will be talking with them more

   Magnus: from RVI perspecitive we are coordinating heavily with
   this security group

JS Library

   Powell: I see this as a thin layer on top of web socket,
   probably going promise based
   ... don't want to start a religious debate with callback crowd

   <wonsuk> jQuery.get: [9]http://api.jquery.com/jQuery.get/

      [9] http://api.jquery.com/jQuery.get/

   <wonsuk> jQuery.get: [10]http://api.jquery.com/jQuery.get/

     [10] http://api.jquery.com/jQuery.get/

   Wonsuk: we can think of our WebIDL (JS Library) aproach like
   this jquery model
   ... since we want to define the api independent of VSS we
   should avoid specific attribute set and get function but stay
   high level

   Powell: I think we can start higher level than that at this
   point

   Wonsuk: I'm just looking for how we can make it as consistent
   with our web socket approach

   Rudi: we are trying to facilitate things for developers

   Hira: what are the intellectual properties of jQuery?

   Powell: open source, maybe MIT license

   Kevin broadcasts a couple examples for JS library

   Powell: second vehicle.get approach and why not abstract the
   request id to the library as well
   ... along with connection, error handling, tokens
   ... request lifecycle (watch socket for responses to send back)

   <inserted> scribenick: kaz

   kaz: thought Urata-san explained he implemented the current
   vehicle information access api during the april meeting in
   paris, so we might want to look at his implementation as well

   powell: put some sample API definitions on the service spec
   wiki

   junichi: token handling should be hidden from developers
   ... also developers' directly specifying long variable name
   would be not complicated

   powell: put some idea of finding actual long variable name
   using findPathByCSS method

   kaz: theoretically what we expect to this findPathByCSS is the
   mapping between VSS and the current Vehicle Data as we
   discussed in Paris

   powell: right
   ... copies the sample codes to his editor and adds some more
   edits

   kevin: how we document VSS capability?

   powell: we could use CSS selector like JSON query
   ... (shows some resources online)

Service Spec - WebSocket

   adam: goes through the Service Spec wiki
   ... WebSocket section
   ... Message Structure section

   <inserted> scribenick: ted

   Adam: allow multiple subscriptions on the same signal
   ... it can receive message from server with subscription id,
   request id and timestamp to verify sucess

   Powell: what is the timestamp?

   Kevin: time the response was generated

   Adam: not linked to any CAN bus timestamp but provided by the
   service

   Powell: why do we need it?

   Adam: it might be a leftover from before we had subscription id

   Kevin: I'm not attached to it

   Shinjiro: older API uses one and it can be helpful to have
   ... having a timestamp for the signal is more important, you
   want to know how fresh it is

   Adam: timestamp should be when the message is sent
   ... you may not have it from the underlying ECU only when it is
   sent from the service

   Shinjiro: different implementations can have more pronounced
   delays

   Adam: not sure how you can consistently get the time from the
   CAN signal

   Kevin: there is no single network you can get all the signals
   from, they'll be coming through different gateways
   ... you can know it is the most recent at the time it was
   relayed
   ... it is feasible you may be getting a cached value of the
   latest received signal

   Paul: how long of a processing delay are we talking about?

   Kevin: sensor might be sending the information once a second so
   no point polling every 10ms

   Paul: it is useful to know how long the value should be
   considered valid
   ... so what you are proposing is stamping it when you receive
   it

   Rudi: that is the best you are going to get

   Paul: we might want to provide a typical average age of a
   signal would be - or more a range of how recent/stale it might
   be

   <kaz> scribenick: kaz

   adam: goes through "Access Control and Authorization" section

   (discussion on "On Change")

   (continue discussion after lunch)

   [ lunch ]

   <inserted> scribenick: ted

   [discussion of error codes, concern about introducing custom
   ones - prefer to find existing applicable]

   <paul> [11]http://www.restapitutorial.com/httpstatuscodes.html

     [11] http://www.restapitutorial.com/httpstatuscodes.html

   Shinjiro: for subscription_already_active, do we have to
   prevent multiple subscriptions to the same tree path?
   ... it seems we should permit it

   Kevin: we could give back the existing subscription id and
   connection

   Ted: but then you risk one client app closing it out from all
   the other apps

   Kevin: true. this idea was to prevent multiple subscriptions
   from the same client for the same information
   ... we want to avoid multiple logically equivalent
   subscriptions

   Shinjiro: I may want to use the same information within the
   same application, in different functions perhaps

   Kevin: subscription can be a potentially high cost operation,
   especially if it is to a sizeable part of the tree

   Shinjiro: if I want to use vehicle speed in multiple places
   within the same application, should I use the same connection
   or can I subscribe twice?

   Ted: similar to db programming you want to avoid overhead
   (delay) of creating connections, keep it open and reuse for the
   rest of your interactions

   Paul: connection pooling is common too

   Ted: 304 not modified seems like the closest although a bit
   awkward or stretch of the meaning. it is how serve responds to
   repeated requests (if if-modified-since header is sent which
   we're not doing here)

   Kaz: what if you want different polling intervals?

   Kevin: you close connection and create new one

   <kaz> [12]draft WG Charter

     [12] https://w3c.github.io/automotive/charter-2016/

   <inserted> scribenick: kaz

   hira: would like to suggest we consider two kinds of VSS
   definition separately, i.e., (1) Genivi's original VSS
   definition like WHATWG's HTML5 living standard and (2) W3C's
   fixed snapshot version like HTML5 Recommendation

   ted: we need to talk with Genivi for that purpose

   wonsuk: we need more discussion about that

   kaz: would suggest we raise github issues if we would like to
   add changes to the draft Charter
   ... and we'll discuss the issues during our webex calls
   ... and once we got consensus, we'll update the draft Charter
   on GitHub

   (all agree)

   adam: adds "This spec is dependent upon the VSS as defined by
   GENIVI." to the Vehicle Signal Server Spec part
   ... also add "Hence, it is conceivable that it is
   used/implemented without using the VSS." to the Vehicle Signal
   Client Spec part

   kaz: Hirabayashi-san still wants to add some more change about
   the relationship between Genivi's VSS and possible W3C vehicle
   signal definition
   ... so he should raise an issue on GitHub about that and we
   should continue discussion

   wonsuk: what is important is "the client spec specifies the API
   to access vehicle information." or something like that

   kaz: let's continue the discussion on GitHub and Telconfs :)

   peter: btw, we should check people's participation in the next
   f2f during TPAC 2016 in Lisbon
   ... maybe we should conduct a survey as usual

   <scribe> ACTION: kaz to conduct a wbs survey to gather people's
   availability for the next f2f meeting during TPAC 2016
   [recorded in
   [13]http://www.w3.org/2016/07/28-auto-minutes.html#action02]

     [13] http://www.w3.org/2016/07/28-auto-minutes.html#action02]

   <trackbot> Created ACTION-21 - Conduct a wbs survey to gather
   people's availability for the next f2f meeting during tpac 2016
   [on Kazuyuki Ashimura - due 2016-08-04].

   [ Portland f2f meeting adjourned ]

Summary of Action Items

   [NEW] ACTION: kaz to conduct a wbs survey to gather people's
   availability for the next f2f meeting during TPAC 2016
   [recorded in
   [14]http://www.w3.org/2016/07/28-auto-minutes.html#action02]
   [NEW] ACTION: kaz to generate a template HTML for the updated
   WG Charter under the W3C/Automotive GitHub repo [recorded in
   [15]http://www.w3.org/2016/07/28-auto-minutes.html#action01]

     [14] http://www.w3.org/2016/07/28-auto-minutes.html#action02
     [15] http://www.w3.org/2016/07/28-auto-minutes.html#action01

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [16]scribe.perl version
    1.144 ([17]CVS log)
    $Date: 2016/07/28 23:10:48 $

     [16] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [17] http://dev.w3.org/cvsweb/2002/scribe/