See also: IRC log
<scribe> scribenick: ted
Paul: the main topic should be spec, we can get into F2F logistics or other topics if they wish
-> https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification#WebSocket_2 draft spec
Adam: basically we took Powell's
suggestion of having json structure of the request itself,
added oauth tokens
... initialization of websocket. we have it set as localhost
for now
... in terms of uri schemes we are mandating wss initiated over
https
... we wanted to discuss a few things like whether we can
reserve ports
Kevin: some may argue to allow
either ws or wss given thoughts the vehicle network may be
considered secure. the trend is to secure more on vehicle
networks
... we are passing security tokens around and those could be
sniffed and intercepted
... attacker can get onto vehicle and escallate the
intrusion
... also motivation behind having timeout on tokens
... best to start more secure from the beginning
Adam: we send json blob to the
server with action and path
... it can be basic or more detailed. action can be get/set
subscribe or unsubscribe
... subscription can be either interval (time lapse) or
onchange
... onchange can be set to true or with boundaries eg temp
changes 10 degrees C or speed jumps 10km/h
... service will provide an id, handle to itself
... we give response code along with json response
Kevin: reason to have number and error code, you may get an authentication issue for example or request is otherwise invalid
Adam: with the subscribe are
another set of options you can set
... following VSS route with the path naming
... server will return id handle along with json
Kevin: Rudi asked if it would be better for the client to provide the id. this way seems more natural
[avoids client making mistake asking for an already used socket]
Kevin: client needs to be careful to avoid making duplicate subscriptions
Adam: authentication can be user level or device level
Rudi: my original idea was to
have client side and server side id
... comparing the path and other parameters could work too
Powell: what we want is the
client to specify an id
... the one web socket might be shared by multiple
clients
... i am of the opinion there should be something unique from
the client side
Kevin: a client would normally
create one web socket although that is not mandated
... the server can guarantee that each socket is unique
... the server echoing back enough of the parameters will make
it feasible for the client to map and manage its sockets
Powell: these are stateful but not transactional. i may send a number of get requests and need to know which is being responded to
Kevin: if a client creates a
given web socket connection that instance is tied to a
different object in your code, right?
... client can keep them straight based on the response and id
given from the server
Powell: you may be right, you might be able to only get one connection per port
Adam: if we use Oauth2 we can send the token with the request
Kevin: the concept here is there
are basically two different things with authentication
... we may want to authenticate a user or device (vehicle or
another off board)
... ECU may have different priviledges
... signals that are not under access control would not need to
send token as part of their request
Adam: onchange obviously is more
simple in the discrete case
... default is true, to receive message when the signal
changes
... we can specify min and max change parameters to limit what
we wish to follow
... following VSS path you can subscribe to different areas
(engine for instance)
Kevin: you can subscribe to individual signals of different types with different intervals or same signal multiple times
Adam: under engine you can set interval since trying to get all that on every change would be too much
Kevin: change can minimize volume
as well
... we want the client to specify interval they are interested
in instead of one mandated by the server
Ted: the client might request a frequency interval that the server is unable or unwilling to provide. the response could have the alternate interval
Kevin: that is a possibility. at present we are inclined to decline the request
Ted: in that case an error code indicating frequency is too high
Kevin: that could work, client could then handle and retry at a different interval. if the server is overloaded it might want to defer in the same manner
Adam: we have a number of restful
error messages already
... if the information isn't valid for that vehicle
... regarding lifecycle of the web socket, the server reserves
the right to close the connection
[Adam going over example in spec with engine.tps boundaries]
Kevin: you can choose to not have
a min change and just a max one. we are also considering
range
... there are a couple ways we can go. for the moment it is
either above or below respective max and min
Adam: you can send id of the socket you want to unsubscribe to or 0 for all your connections
Ted wonders about how server could keep track of the different clients and their connections so as not to close the others. unsubscribe is worthwhile but you can also close web socket without unsub
Kevin: a client should be able to unsubscribe all its connections
Rudi: sounds like a server implementation detail
Powell reports on testing multiple sockets from same client
Kevin: you can potentially have a
race condition if two sockets try to send the same change
request
... you will end up with last update winning and dirty
reads
Adam: here (sharing screen
walthrought of spec) are all the get/set options
... there are some more complex types you can subscribe
to
... if for example you request all doors with wildcard you will
get back an array instead of single json blob
... if you request data that doesn't exist you'll get back
unrecognized message
... you can send a set lock command to all doors in the same
manner
... values we cannot set will get a denied error message
... if you try to set lock on engine you'll get back
unsupported
Kevin: subscriptions are
expensive for the server and may need to fine tune them
... there is not much point in giving an id on simple get
Powell: the idea that there is no
transactional layer here so we need to add some
... each get should have some sort of transactional reference
(request id) so i know which one is responding
Kaz: the lifecycle of socket connection depends on transaction layer
Kevin: if you are going to allow
getting multiple signals, how are you going to decide the
unique id?
... perhaps based on request path
Kaz: the two levels are transaction-wide and whole application-wide
Powell: it is possible a connection is lost (or closed) so want to know which one is responding
Kevin: we considered having
timestamp as part of the response so you can have some idea of
ordering (if you get responses out of order)
... that stamp could be the request timestamp
... we are continuing to add to the draft
Paul does time check and sees if anyone has comments on security aspects so far
<Zakim> kaz, you wanted to ask where to install the certificate and who to manage it (later) and to
Song: I'll read further and send on mail list
Junichi: I will send more to the list too
Kaz: we need to start a discussion by email on extending the charter
Kaz will ask Philipp to bring a 3 month extension to W3M. We will update the WG Charter based on the TF discussions. We will have a better sense of scope and timeline of work at F2F in July for a recharter