<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: http://api.jquery.com/jQuery.get/

<wonsuk> jQuery.get: 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> 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> draft WG Charter

<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 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 ]