<scribe> scribenick: ted

Iotivity OCF

rudi: this seems like a viable framework that might work for our REST services

kevin: makes sense

<paul> https://www.iotivity.org/

<paul> http://openconnectivity.org/

rudi: i got into contact with a small nearby startup that has their own nodejs approach but it not suited to our needs

<paul> https://smartcar.com

paul: we met with agl yesterday about working together with them

... they are open to it. ted and dan tooks some actions to get the organizations in-line

peter: i'm not sure they understood our use cases fully and sounds
... they have ideas of their own and seemed hesitant on vss

... not sure i understand that since vss has plenty of flexibility

rudi: vss in github is not complete, magnus is making a big push today so it should be cleaner soon

... agl was originally a tizen approach but that was abandoned some time ago

... they are both producing open source ivi stacks

... there are some organizational differences

ted: we'll be learning more about agl's rest/websocket approach. hopefully we can get everyone on the same page. they're looking at iotivity too and they are open to modifications at this point

<inserted> kaz: WoT IG is also talking with the OCF guys about IoTivity. so we might want to talk with the WoT guys as well about this.

<inserted> paul: sounds good.

kaz: where should iotivity/iot discussions take place, bg or wg?

paul: wg

kaz: we should update the charter for this new work

paul: i can take a pass at updating that charter

ted: i can ask for an extension

<kaz> current charter

paul: sanjeev is involved in WoT and trying to get involved in auto

... i'll follow up with WoT wg on ocf

<kaz> [ kaz: notes there was another contact from OCF for the WoT IG, so we should talk with the WoT IG Chair, Joerg Heuer first ]

adam: clarification, what is the genivi approach on services? not sure we should follow agl model

paul: the use cases we are trying to support makes sense for services approach. agl should look at what we are working on

... kevin's candidate architecture works well within genivi and elsewhere

... there is some good alignment with genivi

rudi: i haven't seen anything until recent in agl on services

... hopefully we will see implemented in both platforms

<paul> https://wiki.automotivelinux.org/eg-connectivity

<paul> https://wiki.automotivelinux.org/eg-connectivity/meetings

paul: agl's connectivity expert group is meeting on thursday and we are welcome to attend

Powell's issue on the documentation format

<paul> https://github.com/w3c/automotive/issues/85

... powell hasn't joined the call yet to discuss the issue he created on github

... this aligns with how i would expect it to go

paul: rudi, have you had a chance to dig into vss further?

rudi: i look at it constantly and waiting for magnus' latest changes, expecting those today

peter: we should look at our data spec as it is right now to see if there is any major difference, like zones, we need to work out

paul: it is clear that zone goes away with vss

... can you take a look peter at a section and compare the two of them?

peter: sure especially since it is to be out soon

... i'll have an initial review within about two weeks

paul: plan on bringing it back for the next call

kaz: i'll ask kddi and access if they are available/interested in security section/

paul: i can take a stab at the intro

kevin: i will take a look

adam: i can look at the terminology with respect to sockets/services

paul: we need subscribe to spelled out more, grouping of objects

adam if you want to take an initial pass that would be great

kevin: adam and i can pair on that

rudi: i will explore iotivity more to see if it is appropriate for our needs without being overkill

paul: security is going to be critical especially as this might be used besides ivi

... for those of you that our next call is too late in the evening, please send updates by email or github issues

<rstreif> got to jump onto my next meeting, ttyl

<kaz> kaz: would ask Wonsuk as well about his interest

<kaz> ... btw, maybe it would be better for us to use another title for this spec because we already use "Vehicle Information Access API" for the existing JS API.

<kaz> paul: the wiki says "Vehicle Information Service Spec"

<kaz> all: ok

[ adjourned ]