<PatrickLue> https://mit.webex.com/mit/j.php?MTID=m9b9375ee6595e0f88363f1c37bc3de7a
Urata: my name is Shinjiro Urata
from ACCESS
... current status of VISS is Candidate Recommendation
... I believe most of you know about the implementation
report
... I was hoping Wonsuk would be at TPAC and could tell us more
about ETRI's work
Adam: it is a work in progress
Urata: regarding ACCESS'
implementations, I also implemented VIAS and made a JS library
available on github
... regarding VISS it is being used in demos, proof of concepts
and some development tooling
... there was a recent press release from Renesas that they
implemented "Vehicle API of the W3C"
<urata> https://www.renesas.com/us/en/about/press-center/news/2018/news20181016.html
<urata> https://github.com/aShinjiroUrata/vehicle-information-service-spec/blob/master/vias/vias.js
Urata: here is a slide on their
demo, creating a vehicle simulator
... developers can use it for realistic driving data
... this particular demo showing instrument panel
Hira: are they AGL?
Urata: yes AGL. they are using
the Chromium that Igalia maintains
... this looks similar to the one Melco used to demo (Peter
Winzell did in Burlingame)
... the simulator allows you to modify weather
... their tool includes a recorder so you can replay
later
... it makes tasks/testing easier
Ted: please introduce me to the Renesas people you know involved in that
(we would like to get an implementation report and some will want to use their simulator)
Urata: I am interested in how we will be converging with ViWi and update on where we are with VISS in recommendation track
Ted: VISS is at the Candidate
Release (CR) stage. Thanks to Urata-san's test suite and the
implementation reports we have enough to bring it to Proposed
Recommendation (PR) which is the last step before the final
Recommendation (REC)
... There are W3C specifications that have been in CR and widely
deployed in browsers for many years, the formality wasn't
necessary
... we can and should bring VISS to REC. it is worth pausing here
since even though we have implementations could use more
feedback. we may want to make some minor fixes based on experiences.
Adam: what does it take to go from PR to REC?
Ted: it is mostly a formality, we give a last call and need to respond to any substantive issues raised by W3C community or public at large
PatrickL: is anyone waiting for VISS to go to PR?
Adam: we certainly encourage seeing it go all the way to REC in order to get more widely adopted
Ulf: I agree
... a "finished" recommendation is more likely to be adopted
Ted: CR is considered mature and implementations encouraged at this point, we should complete
Adam: we will seek an implementation report from our vendor
Magnus: I want to make sure it does not drag on indefinitely
<AdamC> Thanks
Magnus: we should have a scheduled time to check back in, say every 3 months
Ted: agree
PatrickL: ok
PatrickL: we need to summarize
our convergence activities
... we stumble on several main topics: how the data should be
structured, protocols
... I want one describing interface, another protocol and last
helpers for infrastructure
... to make it more accessible to someone new
Ulf: would they be inter-dependent and if so should we split them up
PatrickL: since we cannot agree
on a single protocol, including unix sockets and mqtt I would
like it to be a separate document
... we also do not have concensus on registry so it may belong
elsewhere
Ted: in additional to specifications we can produce guidelines and best practices when more appropriate
PatrickL: I see these different
feature categories as how we might want to divide up the
editorial roles
... I spent an hour going through a "how to build a spec" and
came up with a RSI start
... I want to start taking these past discussions and
conclusions and turning them into specification draft
Ted: makes sense
Ulf: can I protest on the
name?
... I don't like RESTful and that is not accurate
PatrickB: if people are using the same spec on the backend (from server) do we even want the name to contain "Vehicle"
PatrickL: there is also the way
WoT does their thing description
... recall the JSON-LD the WoT people showed us about a thing.
it is very similar to what we are defining as well
... they do not use a fixed protocol either but having rules on
thing interactions through their interface and a defined data
structure as we defined with ViWi
... the thing has a unique identifier, actions, events and
properties which maps to our concept of signals
... from the beginning it might be a competitor with their
approach and trying to distinguish it to myself
Ted: since at this point things are open to consideration, should we seek further collaboration with Google on their API? They have 80+ engineers here at TPAC although in different areas. I have not made significant effort to draw them in given the impressions I had from the industry
Ulf: from what I understand they are not willing to
change what they have, they have a very flat data model
... I think it was influenced by AGL and don't like it, not
very intuitive
... they can live side by side
Magnus: they are not interested
in extending their API and allow the vendor to do so
... they have a core set of signals they care about
... they are complimentary not contradictory
PatrickB: I think developers will gravitate to the Google platform
PatrickL: they may indeed become
the de facto ecosystem
... I do not think we will be able to introduce something that
has the same feel
... we would have to have a significantly better interface than
AOSP
Magnus: from my point of view
they are looking primarily at running apps in the car
... what we are working on can be implemented down at ECU
level, sending to cloud and potentially on cloud backend
PatrickB: if we can get OEM
clouds to all follow the same standard
... I see getting to the cloud as proprietary and RSI from
backend
PatrickL: what scenarios do you see that being used, type of client applications?
PatrickB: to allow vendors to access information
PatrickL: we need to decide that early on since it will influence the spec and we have to keep in mind the volume of data
Ulf: I absolutely think what you (PatrickB) say makes sense as a use, having this available on the backend
<AdamC> Did you get muted?
<magnus> the webex connection cut out
<magnus> we are connecting now
[Ted's 3 paper slides]
Ulf: I want to explain things
from an implementer's pespective
... based on the thoughts we have so far
... I wrote down some requirements. I want it to be agnostic to
OEMs
... support additional transport protocol
... we have discussed distributed services and support some
concept of registry for handling distribution (and
aftermarket
... diagram shows the clients to our API
... below that is the service implementation, different
transport managers
... they communicate to server core
... server needs to be able to handle the multiple
transports
... server needs to access the data model
... it needs to have access to the underlying vehicle for the
actual data
... I used media in this example
... and separate for car data
... below that is OEM proprietary
[Transport interface]
Ulf: we should be able to support
several transport protocols, beginning with http and
sockets
... IPC based on UNIX socket interface if on same ECU,
otherwise network interface
... ECU can register and pass along its data payload
[Tree interface]
Ulf: the server core doesn't need
to know the details of the tree, VSS is defined in YAML and can
convert to CSV, JSON and other formats
... the main usage for the tree is for the server core to know
the path is valid, whether wildcards are included
... the tree can support zero, one or more instances and
handled by the tree manager
... it would be what would handle any persistent storage
[Service interface]
Ulf: this part ties directly into
what we were discussing before the break
... we were talking about different domains
... we are focused primarily on car domain with its VSS data
but need to be mindful of the others which might register
themselves
... server core will add these parts to the tree
... tree could be pre-configured and widely known and handled
by registered, underlying services
... there could be several service managers for the same
domain, that would be up to the tree manager/server core to
handle
... you can have a growing, dynamic tree. services can also
deregister (or otherwise be unavailable)
... the service manager doesn't necessarily need to be on-board
but could be cloud services
... these managers could be downloaded dynamically, loaded into
your runtime
... which brings us back to PatrickB's use case of service
running in cloud
[Server core]
Ulf: server core needs to analyze
payload, route requests and traffic over different protocols to
the underlying service managers
... handle access control and synthesize data
<Zakim> ted, you wanted to comment on WoT and to provide use case for other vehicles' service to pull from cloud for on-board
<Zakim> PatrickLue, you wanted to discuss Core: single point of failure for all communication? and to ask Core: single point of failure for all communication?
PatrickL: in this setup the server core would be the single component all traffic would go through?
Ulf: that is a possibility but
not necessarily
... during the registration of service managers, they can
convey to the core server if it should be aggregating its
service or accessed directly
... once you receive this metadata about the service you can go
directly
PatrickB: the server core would
be more like a library since it abstracts the transport
protocol
... it is a library or registry?
Ulf: if you want to know the
services on the car that is where you need to go, so
registry
... it would provide service discovery. the core could handle
the requests or be bypassed and service directly
... I want both possibilities
Ulf: client could register itself
PatrickL: client device that has
musical tracks and would want it to make those available via
media service instead of providing its own service
... I want to be clear when discussing client and service
... yes one can be both
<Zakim> PatrickB, you wanted to comment on rsi.server architecture (https://github.com/wzr1337/rsi.demo/ https://github.com/wzr1337/rsi.server/)
PatrickB: I was reminded of
architecture of an implementation I put on github, a demo and
server in nodejs
... there are plugins that are managers in your case. the
server itself provides an interface to the plugins and http
interface, very similar to what you are proposing
... in case you want to take a look, it already does this
pattern
Ulf: I will have a look
Ulf: as noted it is beneficial to
have implementations, should we have a reference implementation
instead of these proprietary ones
... there is value in doing so rather soon as it will help
drive feedback
... I am interested and could contribute. we would need to
think where it would be hosted, etc
PatrickB: one of the most important things for me would be the license
Ulf: open as possible but not a license expert
Hira: I have a question and
comment. could you go back to your transport interface
slide?
... you say interface is transport agnostic but my
understanding is VISS (v1) is web sockets
<Zakim> ted, you wanted to +1 and point out need for data sample
Benjamin: in a WoT server, a
thing can expose interactions
... I have some experience with this one. the tree parts
translate to their thing description
... I had a question on backend side, do you have an idea
architecture wise what would be required?
... we have different scopes as Ted illustrated earlier
... do you have the other use in mind?
Ulf: it should be usable in both scenarios
Ted: diagrams, demos and code are great, provides something tangible. also would want sample data we can run through as an emulator like Renesas does
Glenn: when you mentioned where
to host, this could be linked with the Neutral Vehicle project
and we could provide sample databased and provide a public
instance people can play with
... leveraging and contributing to this open source project. we
have some great security experts involved
Ulf: absolutely
Magnus: I wanted to go back to
data warehouse comment
... you can provide sparql endpoints as well for the other
major use case (Tuesday)
... it would be possible to chain these services, think of
underlying ECU being their own node and aggregate and build a
bigger tree
<Zakim> ted, you wanted to comment on hosting, license and to comment on collab with Benjamin
Urata: if the server core exists
in cloud, it could handle multiple vehicles' data
... there could be multiple clients as well
... you will need authentication
Ulf: yes those would need to be addressed, it might be possible
Urata: to simplify the architecture you can handle a single vehicle
<Zakim> PatrickB, you wanted to comment on auth in viwi and latest spec and to comment on opensource and support on JSON schema V2 for viwi (https://github.com/wzr1337/rsi.schema/)
PatrickB: regarding auth and with
respect to GDPR, I personally did quite a bit of effort to get
auth in spec
... we consider ECU or service going offline but unfortunately
there is no public version
PatrickL: you guys were mean to
us last time we shared :P
... but we will make it public
PatrickB: I can also provide a clean room implementation since I forget some pieces
Ulf: is JWT part of the solution
PatrickB: yes along with who
signs etc
... when we made the W3C Member Submission (from VW) you will
find how we do our JSON schema
... it is in the spec itself along with service
definitions
... I extracted the schema and put it in my github repo
... it is more a private side project at present and welcome
contributions
Ulf: my assumption is we are going to use VSS as a data model and we extended it to try to be more friendly to resource approach of ViWi
PatrickB: it is also about the
types of actions you can take on objects
... YAML doesn't allow you to describe subscriptions for
example
<Zakim> ted, you wanted to say is there a snapshot?
PatrickL: we have departed
somewhat from our initial goal
... is our main use case the same? are we trying to draw in
on-board app developers or sending data to outside world?
... we should be clear about what we want to solve
Ulf: they are not mutually exclusive
PatrickL: the differences are
substantial
... for sending to cloud connectivity and security are very
different
... backend to third party gets complicated
PatrickB: I disagree
PatrickL: more fleet perspective not individual user
PatrickB: I don't want to go into
this use case discussion and understand why interface for OEM
needs to be any different to what external parties use
... I would promote an API that is usable by themselves and
third parties
PatrickL: querying and filtering
is one of the main differences we have had. implementation of
those are the most complicated
... if you are handling large volumes of data that becomes more
important
... there would be a change of the interface. v2-3rd party,
that is the main use case
... not sure what we need to concentrate the most based on
these different influences
Ulf: I would prefer to defer
answering this question and come up with something and see if
it applies
... if you optimize for one it might not be great for the
other
Ted: main goal remains the same, exposing services to applications within the vehicle. The biggest use case for those services is data sampling for fleet, insurance, regional/municipal purposes, etc and we need to be conscious of that. The ontology and JSON-LD work on the data model provides the basics, some other issues that arise from an automotive data marketplace are being worked on in the BG and don't see more needed in the specs we are currently working on
PatrickL: ok, we try to remain conscious of these other use cases and stick with our original goal
Benjamin: please summarize where we are with convergence?
PatrickL: we did ground work for
what we want in a v2, feature by feature
... we saw how things are done differently, what we like from
these different influences
... there are considerable minutes of these conversations and
many conclusions drawn
Ulf: we are still committed to VSS
Ted: yes, the data model is central even if there are multiple methods
PatrickL: what we agreed upon as
I remember, we will support with our next iteration the way the
data model is currently being structured ideally with backward
compatibility
... we never covered other data models through VSS
Adam: we include the possibility of supporting other data models in VISS
Ted: we have some pronounced gaps in our current signals definitions, placeholder for EV signals, nothing for lidar and other ADAS signals. As all OEM present are working on producing if not having EV already in production we should make that a priority.
<urata> Excuse me but urata will not be present after 15:30 for other group's discussion(https-local).
Urata-san, we are interested in that topic too. it stemmed as you recall from past TPAC where Junichi-san led a breakout session
if there are any links to summaries on where they are or other documents please collect them and send to mailing list
Ulf: I propose this standard
support multiple protocols as mentioned before
... also propose we use JSON for payload regardless of
transport
... it would be good for the http manager to translate to the
web socket verbs
... I also want the different access methods to behave
similarly as much as possible
[slide illustrating the different actions and how they map to one another ws.get&set to http:GET&POST but nothing for getMetaData
Ulf: we don't have subscribe in
http
... if we could make that look more like one another if not
identical it would be advantageous for us
[example requests via VISS and ViWi]
Ulf: we can do similar with the
authorize mechanism
... we should consider switching from set in websockets to post
to be consistent to http
... we might also need PUT and DELETE in both
Magnus: they have similar in ViWi apparently
PatrickB: we have $spec which will give you specification for an element or service - depending on where you are in path
Ulf: if you have a more thought out solution
PatrickB: there is a schema on ViWi v2
<Zakim> PatrickB, you wanted to comment on metadata proposal for v2 GET vs. /x/y/z/$spec in viwi and to comment on query paramteters vs. headers and url "segments"
<Zakim> PatrickLue, you wanted to syntax getting the meta data for a property. and to authorize on channel not on element access
PatrickL: not ever level is well
defined for that to be applicable. we should use syntax that
applies to the interface the programmer is using
... on your auth comparison something is drastically different
and you are authorizing a channel and question is whether every
request needs auth or if the socket/http session can be kept
open
... for http we should stick with their headers
Ulf: perhaps we should support both
PatrickL: my vote would be for one
PatrickB: session might time out and token should be resent
PatrickL: interface can look out
for that and give an appropriate response header
... it is possible for service to restrict your access as the
session goes on
PatrickB: I would authorize each request
Ulf: not sure we should require that in spec
PatrickB: I disagree since we want consistency across vehicles
PatrickL: the introspection interface is something I want to address tomorrow
PatrickB: we have to agree on the
query parameters to be consistent, consider them like the where
clause of a sql statement
... if we want to do something with the metadata, have it as
part of the $spec or other keyword
Ted provides summary of WebRTC considerations for datastreams to date
<dom> https://www.w3.org/2018/Talks/dhm-webrtc-streams/?full#1
Dom: I want to provide a very
high level overview of how I think WebRTC may apply to
you
... first it stands for Web Real Time Communication - it is
what this WebEx instance uses
... it has a protocol stack being developed in IETF
... the initial motivation was audio/video communication from
the browser and transmit it realtime
... one part of that is to enable peer to peer communication
within the browser and best for keeping things closer to
realtime
... it also has data transfer as part of its scope. the
benefits of webrtc can be leveraged for streaming data too
[slide 2]
Dom: there is a combination of a
protocol and an API
... the API for data channel is almost the same as web
sockets
... you get a more flexible type of connection. it is more
flexible, you could choose to be flexible vs reliable, ordered
versus not (UDPish)
... in networking terms it allows for TCP and UDP like
functionality
... on the protocol level it is based on SCTP which is UDP++
and encryption via DTLS
... everything is encrypted and key exchange at the
beginning
... webrtc data channels were build for client to client but
usable/useful for client to server as well
... on the evolutions of data channel, we are following IETF
QUIC (mix of TCP & UDP)
... it also has better security consideration
... another idea being discussed but not adopted yet is
supporting WebRTC over QUIC
... one of the first applications considered is HTTP over
QUIC
... trying to get SCTP in browser otherwise would be a
challenge
... current API based on Web Sockets. there is a new pattern
for streaming based on WhatWG streams
... it can allow you to build pipelines for streams
... not sure if the JS layer is important to you
PatrickL: how is addressing handled in WebRTC method, is it just server name and port or is there more logic?
Dom: it was initially built for
p2p so you are not sure what port will be used
... people can be going through NAT and drawing from VoIP
leveraging STUN etc
... we allow clients to talk more directly
PatrickL: how would I select the client I want to connect to
Dom: two perspective user and...
PatrickL: developer
Dom: developer can take information from this @ICE? protocol. the web server will let you know what your common path is
PatrickL: how I identify to server and identify client I want to communicate is handled by the web server?
Dom: correct
PatrickL: let's say you want to send radar information, you can send a stream through http which might work or through WebRTC
Dom: you're not going to
rediscover the radar each time you restart the car... (shrugs
and squirms in room) you will know from before how to find
it
... the main reason you might want to use WebRTC is if you want
to give reliable and ordered or unreliable and faster
... sometimes you don't care about the ordering of data but
want to ensure it gets there
... sometimes you might want to throttle data and expect to get
things out of order
(dropping based on timestamps)
Magnus: how do you handle which you use?
Dom: you can create as many
channels as you want with these different connection
parameters
... it can be fairly granular with these controls
Magnus: this requires a browser runtime but we know already that these data channels are used by non-browser clients and between servers
PatrickL: how stable do you consider the stability of data channels in current browsers?
Dom: all good for now, the new features being defined are significant and expect adoption but still in flux
PatrickL: the part in flux is mapping to data channel in background
<dom> dom@w3.org
Dom: if you own both ends of the connection you might want to use something else as current version is RTP based and has limitations
Dave: I will do a quick intro, an
implementation and testing demo
... how you can include communications metadata on how to
contact to the thing
... you can concentrate on what the interface is without
worrying about the details below
... IoT is fragmented, lots of protocols, multitude of
standards efforts
... you can use it for descroptions of things what they do and
context in which they reside
... they can be used for actuators and services
[slide 7]
Dave: thing is described in
JSON-LD
... you can expose things as clients or offering things to
cloud, act as server to other clients or allow only a single
connection
[slide 9]
Dave: you can find the node
arena-webhub
... it works with fetch and sockets
[slide 10]
<AdamC> Is there a link available to the slides?
Dave: this JSON defines app
connecting to this particular service
... web hubs can vary in respect to scripting languages and
APIs
<magnus> https://www.w3.org/wiki/File:Wot-interop-testing.pdf
Dave: thing description defines schema further
<AdamC> Thanks all
[slide 14 on test cases]
Dave: test thing uses a harness
to run the individual tests
... I made this available as a docker image but it is just as
easy to install via npm
[demo]
Hira: what is the specification for thing description
Dave: we intend to bring it to CR
early next year
... it has a data vocabulary that is a subset of JSON
schema
Hira: where is the thing description stored?
Dave shows example from slides
Urata: my understanding is WoT
concept is used in small IoT devices with limited number of
signals
... would it be realistic to apply to us with so many
signals
... one thing description for all the vehicle signals might be
cumbersome
Dave: you could or split it up,
you can take a more object oriented design approach
... up to you on how to structure
[discussion of localhost and certs]
Magnus: are you looking into use cases when you are not well connected?
Urata: I will be joining this HTTPS localhost CG discussion later this afternoon
Hira: do you have a plan to conduct testing for all protocol bindings you support?
Dave: from point of view for W3C
process is testing the specification and that doesn't cover
that
... if people want to build a platform to test implementations,
you can
... I did for interop testing
... for W3C you need to say for each feature in the spec an
implementation has done it not all
[demo of F-interop Tests]
Dave: you can take normative
statements out of a spec and create corresponding test
... we have client and server side tests
... WoT provides abstraction over protocol layer
... allows to link to their semantics too
... also shows performance can be done for streaming data, it
can be done over TLS with JWT
<Zakim> ted, you wanted to talk about ws+http blending on same port
Ulf: we have some similarities
and differences
... for example we currently explicitly imbded the transports,
at least at this point
... we want to at least make it easier to map what we're doing
to WoT but not necessarily fully adopt
... as Urata-san was mentioning we have many, many signals
Dave: we have examples of tens of thousands of data points per second through this
Ulf: we will have thousands of properties, maybe you can absorb that
Dave: that is more a question of
software engineering and robustness, whether you want to do
some grouping and distribute it that way
... this works quite well in the cloud as well
Magnus: this is very good input to our group since we are working in similar problem space
Ulf: agree, we should utmost to get similar
Dave: I suggest trying to represent your data model in WoT things description
PatrickL: should we continue with connection to WoT world or should we try to get back to rest of agenda?
[former]
Benjamin: we have been looking at
this with vehicles at EUROCOM
... the closer you get to the vehicle the slower and more
cumbersome it gets, we did a PoC using M2M from OBD2 using a
rpi and it was slow
... we had full second responses
PatrickL: that would be
acceptible in milliseconds
... is JSON-LD the set standard for transfering the thing
description, I am wondering how to optimize
Benjamin: we were not able to optimize
Ted: check with Urata since I recall a prototype he did with high latency going through OBD2
PatrickL: yes it is slower but that is not so pronounced
Benjamin: it can represent a
vehicle well
... we group by capabilities, akin to branches of VSS
... to make this more readable/understandable
... we did not do wide testing of different protocols
... having a massive thing description is awkward
PatrickL: a thing could be
comprised of different things and not to define by
capabilities
... to make the distinction of which capability will be
difficult
... a property can be a link to another thing
<Zakim> ted, you wanted to how I'm thinking of WoT atm
Cathedrale Saint Jean-Bapiste
at 7
Ted: we have been discussing
different use cases when specific subsets of signals information
will be available for specific purposes
... we should consider a vehicle being different, purpose specific
things on the WoT
... it could expose some sensors and be a roving air quality
monitor for example, road surface evaluator, etc
Benjamin: we should offer
ourselves as a thing in WoT and see what people want
... I could see a menu where they create a purpose specific
payload
Ulf: I like abstraction from transport protocols, we want a default one though especially if coming from off-board
PatrickL: in WoT if you don't give a form then what is expected?
Ulf: in our case we have a registry, for them I guess it is cloud based
Ted: the thing describes itself, they speak to each other directly and must do some form of discovery
PatrickL: we agreed gen 1 data
model will be useable in gen2 interface and protocol
... gen 1 protocol and interface do not have to support gen 2
data model
... that sound right to you?
... or there more points we should be conscious of?
Ted: what we are missing is whether gen 2 needs to support gen 1 interface and protocol
Ulf: we already have some proposed changes to VSS that may cause problems for backwards compatibility
Adam: if there are things that
can be handled through a lightweight library to bridge
compatability that is fine
... we like resource nodes
... moving out media, diagnostics etc
... if the differences or minor or shims possible we would be
content
... what we would like however is to create an official version
release of VSS
Ted: we have agreement on
versioning for VSS
... with goal of adding signals to both version branches
Ted: VISS is web sockets, ViWi is ws+http. For some things eg dashboard you want a steady connection to signals information, other times you just need to grab a signal or handful once and don't want the overhead of opening a web socket. http2 seemed promising at first but we would not want to have to regularly reestablish connections
Yves: http2 is better but it
depends on the characteristics you want on your network
... best to use existing protocols
Ted: apart from a light protocol as necessary for sockets in v1 (VISS) we will avoid creating custom protocols
PatrickL: the subscription part
is important to some and we cannot live without it
... http and web sockets play together but could be nicer
... one port/connection for all would be good
... there is a bit of appeal for creating something new
Yves: there are many solutions for subscription but it depends on your needs
PatrickL: to be able to notify within http would be a gold solution
Yves: you can do that with URL templates
PatrickL: I have a document description identifier and using it heavily to be as close as possible to subscribe notion and that would break it
Yves: don't you have a URL for everything already?
PatrickL: Yes
Yves: even notification
PatrickL: no
Yves: you need to identify more or less everything that happened
PatrickL: we don't have it for
notifications since it has to go through socket
... it is not the same as a nice POST on the URL
... Dom was visiting earlier and we were discussing about
WebRTC for datastreams
Yves: TAG is pushing more APIs to
using streams
... an explainer to provide rationale on your choices would
help
PatrickL: we can do that
Ted introduces protocol-less capability we want
PatrickL: we want to link stuff
in the data model and allow for changes in the protocol based
on the client and service capabilities
... ideally we would have same identifier (URL) regardless of
protocol used
Yves: protocols may have specific
characteristics
... complexity to change and negotiate can be quite hard
... how do you go with QUIC for example, you need to start with
TCP
PatrickL: as we are from
automotive space and need to expect vehicles in field for 10-15
years, we initially have two protocols in mind
... WS in v1, WS+HTTP in v2 maybe MQTT, QUIC as well so the
number of protocols could be increasing
... we want to be able to exchange the same links. agree there
is potentially lots of complexity and ensure access methods
work through the different protocols
Ted: if we allow for multiple, we may want to have one as a default fallback
Yves: we tried that in Web
Services but we found it too complex and it didn't get
adopted
... you are in a closed environment so it might be different
for you
PatrickL: not really, we want a reasonable entry barrier for a developer. do you have examples of attempts for protocol-less that failed?
Yves: SOAP, WSDL for
starters
... people wanted to pass thing through HTTP... or possibly
something else...
PatrickL: the other Patrick said don't complicate it, just go with HTTP
<magnus> *wsdl*
[discussion of UNIX domain socket and how it is used internally on a W3C service]
Ted: one goal we discussed was
trying to get the access methods closer for the main
protocols
... although maybe difficult
PatrickL: we have a number of features including technological approach ready for your review in a few months complete with rationale on decisions reached
Yves: include what your long term goals are as well
PatrickL: we intend to discuss introspection interface and wondering if you might have some early guidance
Yves: there are many things being used depending on language so it can be a hard decision. tell me more about your current thoughts and use cases
PatrickL: we have a special file
description in URL that brings up schema for that part
... kind of similar to the comma-tool Ted was using with me the
other day
Ted: non-standard convention of ours for various tools that can act on URIs
https://tools.ietf.org/html/rfc6570 URL Template
Peter: I might comment on the protocol part maybe later by email
Yves: I encourage you to look at variable expansion within URL Template for your $spec purpose
PatrickL: we have an opinion on COAP
Yves: not sure the added
subscribe. goal was to put that in very constrained
environments like power plugs
... of course it is easier now to have a full http spec
PatrickL: ...so you don't see
benefit for using it?
... it might have subscriptions now
Magnus: looking at RFC it seems it hasn't seen activity since 2014
Yves: it has been drawn out for awhile
PatrickL: I was excited about
push capability in http2 initially but then I used it
... I want something were subscription could work
... are you aware of anyone working in that direction with QUIC
or HTTP2
Ted: fetch?
Yves: background refreshes etc in
it but no not for subscriptions. in the end regular http
... for a real push, I can ask but I don't think many people
are using that
PatrickL: it doesn't seem like we
would be the only ones looking for a solution there
... if we can provide our requirements to something that would
be helpful
Yves: in http your client can declare it wants the server to be able to send a notification
PatrickL: I thought the roles were fixed in http
Yves: yes but a client can act as
a client and a server with a different connection
... in general case you do not want to do that on the web since
you can be flooded with requests but for you it might be
worthwhile
PatrickL: that might go against our security considerations not to mention there may be firewalls to limit connections
[adjourned]