00:00:37 RRSAgent has joined #auto 00:00:37 logging to http://www.w3.org/2016/06/08-auto-irc 00:00:40 scribenick: ted 00:00:47 PowellKinney has joined #auto 00:01:59 Present+ Junichi, Paul, Powell, Kevin, Rudi, Ted 00:03:10 kaz has joined #auto 00:04:12 Present+ Dave, Urata, Song 00:04:28 Topic: Draft spec review 00:04:54 AdamC has joined #auto 00:04:54 urata_access has joined #auto 00:04:54 Paul: the main topic should be spec, we can get into F2F logistics or other topics if they wish 00:04:59 Present+ Adam 00:05:53 -> https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification#WebSocket_2 draft spec 00:06:01 rrsagent, draft minutes 00:06:01 I have made the request to generate http://www.w3.org/2016/06/08-auto-minutes.html kaz 00:06:22 rrsagent, make log public 00:06:24 rrsagent, draft minutes 00:06:24 I have made the request to generate http://www.w3.org/2016/06/08-auto-minutes.html kaz 00:06:46 present+ Kaz 00:07:22 agenda? 00:07:35 agenda+ WG Charter Extension 00:07:43 Adam: basically we took Powell's suggestion of having json structure of the request itself, added oauth tokens 00:09:25 … initialization of websocket. we have it set as localhost for now 00:09:37 … in terms of uri schemes we are mandating wss initiated over https 00:09:56 … we wanted to discuss a few things like whether we can reserve ports 00:11:32 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 00:11:59 … we are passing security tokens around and those could be sniffed and intercepted 00:12:23 … attacker can get onto vehicle and escallate the intrusion 00:12:36 … also motivation behind having timeout on tokens 00:12:46 … best to start more secure from the beginning 00:13:09 Adam: we send json blob to the server with action and path 00:13:35 … it can be basic or more detailed. action can be get/set subscribe or unsubscribe 00:13:53 … subscription can be either interval (time lapse) or onchange 00:14:44 … onchange can be set to true or with boundaries eg temp changes 10 degrees C or speed jumps 10km/h 00:15:09 … service will provide an id, handle to itself 00:15:39 … we give response code along with json response 00:16:42 Kevin: reason to have number and error code, you may get an authentication issue for example or request is otherwise invalid 00:17:16 Adam: with the subscribe are another set of options you can set 00:17:33 … following VSS route with the path naming 00:17:58 … server will return id handle along with json 00:18:24 Kevin: Rudi asked if it would be better for the client to provide the id. this way seems more natural 00:19:04 [avoids client making mistake asking for an already used socket] 00:19:05 q+ 00:19:41 Kevin: client needs to be careful to avoid making duplicate subscriptions 00:20:18 Adam: authentication can be user level or device level 00:20:34 Rudi: my original idea was to have client side and server side id 00:21:07 … comparing the path and other parameters could work too 00:21:20 Powell: what we want is the client to specify an id 00:21:35 … the one web socket might be shared by multiple clients 00:22:28 … i am of the opinion there should be something unique from the client side 00:22:34 q+ to ask where to install the certificate and who to manage it (later) 00:23:50 Kevin: a client would normally create one web socket although that is not mandated 00:24:49 … the server can guarantee that each socket is unique 00:25:41 … the server echoing back enough of the parameters will make it feasible for the client to map and manage its sockets 00:27:19 Powell: these are transactional but not stateful. i may send a number of get requests and need to know which is being responded to 00:27:53 Kevin: if a client creates a given web socket connection that instance is tied to a different object in your code, right? 00:28:20 … client can keep them straight based on the reponse and id given from the server 00:28:37 s/reponse/response/ 00:28:44 Powell: you may be right, you might be able to only get one connection per port 00:29:16 Adam: if we use Oauth2 we can send the token with the request 00:29:37 Kevin: the concept here is there are basically two different things with authentication 00:29:47 s/transactional but not stateful/stateful but not transactional/ 00:30:09 … we may want to authenticate a user or device (vehicle or another off board) 00:30:59 … ECU may have different priviledges 00:31:34 … signals that are not under access control would not need to send token as part of their request 00:32:27 Adam: onchange obviously is more simple in the discrete case 00:32:40 … default is true, to receive message when the signal changes 00:34:24 … we can specify min and max change parameters to limit what we wish to follow 00:35:41 … following VSS path you can subscribe to different areas (engine for instance) 00:36:40 Kevin: you can subscribe to individual signals of different types with different intervals or same signal multiple times 00:37:20 Adam: under engine you can set interval since trying to get all that on every change would be too much 00:37:49 Kevin: change can minimize volume as well 00:38:23 … we want the client to specify interval they are interested in instead of one mandated by the server 00:38:24 q+ 00:40:40 q- 00:41:17 Ted: the client might request a frequency interval that the server is unable or unwilling to provide. the response could have the alternate interval 00:41:36 Kevin: that is a possibility. at present we are inclined to decline the request 00:42:14 Ted: in that case an error code indicating frequency is too high 00:42:54 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 00:43:48 Adam: we have a number of restful error messages already 00:44:18 … if the information isn't valid for that vehicle 00:45:14 … regarding lifecycle of the web socket, the server reserves the right to close the connection 00:46:31 [Adam going over example in spec with engine.tps boundaries] 00:46:41 hira has joined #auto 00:47:30 Kevin: you can choose to not have a min change and just a max one. we are also considering range 00:48:06 … there are a couple ways we can go. for the moment it is either above or below respective max and min 00:48:12 present+ Hirabayashi 00:51:15 Adam: you can send id of the socket you want to unsubscribe to or 0 for all your connections 00:52:09 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 00:53:55 Kevin: a client should be able to unsubscribe all its connections 00:54:35 Rudi: sounds like a server implementation detail 00:54:52 q+ 00:55:58 Powell reports on testing multiple sockets from same client 00:58:35 Kevin: you can potentially have a race condition if two sockets try to send the same change request 00:58:53 … you will end up with last update winning and dirty reads 00:59:21 Adam: here (sharing screen walthrought of spec) are all the get/set options 00:59:30 … there are some more complex types you can subscribe to 01:00:09 … if for example you request all doors with wildcard you will get back an array instead of single json blob 01:00:45 … if you request data that doesn't exist you'll get back unrecognized message 01:01:15 … you can send a set lock command to all doors in the same manner 01:01:33 … values we cannot set will get a denied error message 01:01:56 … if you try to set lock on engine you'll get back unsupported 01:02:50 Kevin: subscriptions are expensive for the server and may need to fine tune them 01:03:12 … there is not much point in giving an id on simple get 01:03:33 Powell: the idea that there is no transactional layer here so we need to add some 01:03:56 … each get should have some sort of transactional reference (request id) so i know which one is responding 01:04:27 Kaz: the lifecycle of socket connection depends on transaction layer 01:05:00 Kevin: if you are going to allow getting multiple signals, how are you going to decide the unique id? 01:05:30 … perhaps based on request path 01:05:38 Kaz: the two levels are transaction and server 01:05:59 s/transaction/transaction-wide/ 01:06:01 Powell: it is possible a connection is lost (or closed) so want to know which one is responding 01:06:06 s/server/whole application-wide/ 01:07:05 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) 01:07:15 … that stamp could be the request stamp 01:07:25 s/request stamp/request timestamp/ 01:08:53 … we are continuing to add to the draft 01:10:10 Paul does time check and sees if anyone has comments on security aspects so far 01:10:15 q? 01:10:19 ack k 01:10:19 kaz, you wanted to ask where to install the certificate and who to manage it (later) and to 01:10:24 Song: I'll read further and send on mail list 01:10:41 agenda? 01:11:18 Junichi: I will send more to the list too 01:12:00 Kaz: we need to start a discussion by email on extending the charter 01:16:10 Kaz will ask Philipp to bring a 3 month extension to W3M. We will have a better sense of scope and timeline of work at F2F in July for a recharter 01:16:12 I have made the request to generate http://www.w3.org/2016/06/08-auto-minutes.html ted 01:17:12 s/W3M./W3M. We will update the WG Charter based on the TF discussions./ 01:17:16 rrsagent, draft minutes 01:17:16 I have made the request to generate http://www.w3.org/2016/06/08-auto-minutes.html kaz 01:20:47 RRSAgent, bye 01:20:47 I see no action items