PatrickL: any other items people
want to discuss?
... first is F2F meeting in October
... any thoughts or opinions for goals
Benjamin: are we talking TPAC in Lyon?
PatrickL: yes
Benjamin: what we should have in
our agenda in addition to v2 spec but taking opportunity to
meet with the other groups
... align with Web Of Things, Consent/Privacy, etc
... schema.org folks. not just work in our silo but
Ted: agree, will find link of other groups meeting and start mail thread to hear suggestion
Benjamin: Web of Things have us listed as a group they are interested in meeting with
PatrickL: interested in JSON-LD
and Schema.org
... tell them what we are up to and get feedback on us using
their technology correctly
... agree a goal should be a rough outline for what should be
in version 2, we covered most parts and should be able to start
sketching
Ulf: absolutely
Laurent: I agree
Glenn: not sure if TPAC is the
right venue but CCC has interop between vehicle and phone
... it can be used for collecting permissions
PatrickL: Laurent and I were part of CCC and could invite them
Ted: +1
Glenn: they have a shared key
model, to allow owner to give consent for usage of the
vehicle
... if a shared key is on phone, driver could be given alert of
the consent given and prompt for input
PatrickL: that would be something
interesting for us for sharing data with third party
devices
... we have not discussed authentication methods yet for v2 of
protocol and probably should beforehand
... and see if it fits. I already have someone in mind
Ted: I will see if we can pick brains of WebAuthN people for that at TPAC as well
PatrickL: we have our main goal and number of desired liaisons identified for TPAC
Benjamin: is there anything we want to present at the unconference?
PatrickL: I think it is more open to individuals than groups
Ted: we can bring up group concerns and worth checking what others are covering
Benjamin: nothing specific planned. WoT tries to connect varied types of things and we are trying to do so with something very specific
PatrickL: Laurent made analogy to Bluetooth that profile Ulf presented
Laurent: I love the idea but want
to make sure we are on the same page
... I think the idea of being able to segregate based on
profiles is worthwhile
Ulf: we didn't go so deep in the
possible uses in other context
... we see differences in signal and resource access and what
you can do with them
... dynamic behavior of nodes
Laurent: so we have a single data modeling and profile can deem what you can do with the tree
Ulf: the data model is common as
you said and I think it would be ok to access signal nodes from
the resource profile and vice versa but you cannot do
everything with them in both
... for example you cannot add or delete data in signal
mode
Laurent: I like the idea, we should make use of it
PatrickL: for me it is clear
PatrickL: streaming sensor data cf email from Ulf today
Ulf: the idea come up today when I sent that link in mail
Ulf: I have not been involved in
discussions for supporting a data stream. giving it some
thought my view was we probably should not try to send
streaming data within API we are talking about here
... we coud develop further but would need flow control but not
sure that is a good idea
... there are plenty of well developed streaming protocols
already that could be well suited
... it got me thinking about the typical pattern used for
streaming, you have data and control channels
... control is used when you need to initiate, close or modify
parameters
... we could use our API to identify where the streaming server
may be and how to initiate it
... it could possibly be solved with mechanisms enhanced in our
model
<scribe> … new key/value function I proposed we add in VSS
UNKNOWN_SPEAKER: we could add stream sensor as a new function there
Laurent: streaming as in media or
any set of data that is sample based?
... audio, video, GPS transceiver
... if it is media streaming how far are we away from content.
I think we use concept of external delivery network in
ViWi
... how far are we away from UPnP
... this may be more controller aspects
Ulf: that is all relevant and not
sure I have answers to your questions
... it was about one car sending a video stream to two cars
behind it - alert of upcoming obstacle
... it could contain audio or any other stream. we could come
up with a solution for generic data streams
... I think using our API and data model as control channel
would be possible
... that would expand the number and types of use cases we
would be relevant
Glenn: I have seen this in heavy
truck platooning wherein the tailing trucks request feed from
front vehicle
... I think there are proof of concepts from Volvo trucks
Peter: extremely interesting use case
PatrickL: a stream sensor if
heavily binary based and not definable in a clear structure
that would be something worth sending as a stream. we should
avoid for things like GPS
... we have thought already on where to find audio stream
... if data can be structured (eg GPS) we should have in data
model
Laurent: in some cases it might be too much overhead to use VSS and our access method. frequency/volume might dictate stream could be better
Ulf: I can see that
PatrickL: too much overhead on
what data element is being notified, then yes ok it might a
little bit better and not have a pubsub mechanism
... that is a special case, sending one type of data is
something client would need to expect in advance
Laurent: pubsub can introduce
latency
... in some cases it might be better to query the stream. I
want to avoid restricting it at this point
PatrickL: I would want criteria
for consideration clearly defined. we are sending string with
key names and curly brackets, some overhead when sending over
and over
... sometimes it would be ok to have a smaller footprint
Laurent: I agree clear rules would be beneficial
PatrickL: I think a common way to describing streaming in our API is worthwhile
Laurent: we do not need to
specify the streaming protocol, give mime type and it is
available to use or not
... some proprietary formats will want to use it
PatrickL: I could see this for
radar/lidar
... these are streams of descriptions coming in fast at a high
volume and not sure we could create a control channel within
our solution but if so it would be interesting
... regrets for me for next week but hope to come up with a few
topics to suggest
[adjourned]