Auto WG

<scribe> scribenick: ted

Draft spec review

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