08:25:58 RRSAgent has joined #auto 08:25:58 logging to http://www.w3.org/2016/09/19-auto-irc 08:26:00 RRSAgent, make logs public 08:26:00 Zakim has joined #auto 08:26:02 Zakim, this will be 08:26:02 I don't understand 'this will be', trackbot 08:26:02 Agenda: https://lists.w3.org/Archives/Public/public-automotive/2016Sep/0026.html 08:26:03 Meeting: Automotive Working Group Teleconference 08:26:03 Date: 19 September 2016 08:26:06 mat has joined #auto 08:27:10 mat_ has joined #auto 08:28:43 Youngjae has joined #auto 08:31:20 mat__ has joined #auto 08:31:46 Topic: Introduction 08:31:53 AdamC has joined #auto 08:32:05 Jun has joined #auto 08:32:43 QingAn has joined #auto 08:32:58 Wonsuk: welcome to Auto WG meeting. we only have a partial turnout, the WG chairs aren't here and as BG chair I'm filling in 08:33:17 … there is another meeting in California next month which they and others will be in attendance 08:34:30 Hi, I can hear you. 08:34:56 raphael has joined #auto 08:35:25 junichi-hashimoto has joined #auto 08:36:54 ^_^ 08:38:38 Hi, I'm attending meeting remotely. 08:41:40 Jun_ has joined #auto 08:48:02 Karen has joined #auto 08:52:13 urata_access2 has joined #auto 08:53:27 kaz2 has joined #auto 08:54:34 drkevg has joined #auto 08:54:35 Latest draft of Vehicle Signal Server Spec - https://w3c.github.io/automotive/vehicle_data/vehicle_information_service.html 08:56:38 sangchul has joined #auto 08:58:59 Attendees: Raphael_Troncy(EUROCOM), Jaesung_Han(Samsung), Wonsuk_Lee(ETRI), Ted_Guild(W3C), Kaz_Ashimura(W3C), Kevin_Gavigan(JLR), Adam_Crofts(JLR), Junya_Yoshida(Softbank), Matso_Suzuki(Softbank), YoungJae_Shin(Softbank), Yoshi_Tanaka(Softbank), Qing_An(Alibaba), Yingying_Chen(W3C), Junichi_Hashimoto(KDDI), Kazuaki_Nimura(Fujitsu), Tatsuhiko_Hirabayashi(KDDI), Shinjiro_Urata(ACCESS) 08:59:30 Topic: draft Vehicle Signal Server Spec 08:59:57 topic: Vehicle Information Service Spec 09:00:15 -> https://w3c.github.io/automotive/vehicle_data/vehicle_information_service.html GitHub Repo 09:00:43 Kevin: the vehicle signal tree (vehicle object model - VOM) is ordered structurally so nodes are below logical parents 09:00:58 s/topic: Vehicle Information Service Spec// 09:02:33 Adam: a quick example (example #1) shows establishing a web socket connection, application authorizing itself with an oauth token 09:02:43 … we use request ids to keep track of connections 09:03:22 … the code confirms the connection is established and then does a GET request for vehicle speed 09:03:46 s/Raphael_Troncy(EUROCOM)/Raphael_Troncy(EURECOM) 09:05:02 Wonsuk: it is possible to do a get to see what parts of the tree are available before susbscribing 09:05:05 Adam: correct 09:05:42 Kevin: for subscriptions you will need your requestId 09:05:57 … we decided at the previous meeting to not bother using the id for a simple get 09:07:33 … in this example it confirms the return 09:08:24 [discussion of the higher level wrapper api, which will resemble the previous webidl approach and meant to be easier for web developers to use] 09:08:55 scribenick: ted 09:10:01 Kevin: the server implementer (OEM) will impose access control for getting and more importantly setting signals 09:11:03 Wonsuk: the table of figures seems out of place here 09:11:24 Kevin: perhaps after TOC, not sure how to get it into the TOC since respec generates that 09:12:10 … introduction gives some background on vehicle network architecture, diagram is mean to help here 09:13:09 … there are two reasons why OEM want to protect these signals, business and security considerations 09:14:31 … in the diagram we distinguish web app and agent with the former being a browser interface the driver or a passenger is interacting with 09:15:21 … agent can be a headless service, for example aggregating information to send for off board (off vehicle) purposes 09:15:56 … native app/agent are other presentation platforms other than a browser/web runtime 09:16:39 [diagram showing external service interactions] 09:17:23 Kevin: the vehicle will not be addressed consistently as its dynamic IP address may be changing often 09:17:46 … the vehicle will need to send its information to an external service 09:18:45 … it is plausible but not advisable to keep track of the temporary IP and allow external interactions 09:19:13 … a V2X server can bridge interactions in a more controlled environment 09:19:32 [V2X - Vehicle To X - anything] 09:19:57 Wonsuk: what would be the protocol used? 09:20:09 Kevin: it could be anything and that is out of scope for what we're working on 09:20:35 … we added it since it is helpful to show the possibilities 09:21:05 Junichi: you could replace it with simply Internet 09:21:08 Kevin: true 09:21:27 Adam: it is for context 09:21:58 Junichi: do you intend to explain V2X more in this spec? 09:22:18 Kevin: in section "Sending Signals and Data off-board" 09:24:01 … we actually have multiple server roles, load balancers, etc in our particular setup 09:24:40 … main reason of having this in the spec is to explain that the vehicle needs to initiate the communication to the external server so it can in turn be contacted 09:24:42 kaz has joined #auto 09:24:53 rrsagent, make log public 09:24:53 … open to suggestions on improving clarity 09:24:59 rrsagent, draft minutes 09:24:59 I have made the request to generate http://www.w3.org/2016/09/19-auto-minutes.html kaz 09:27:50 Raphael: how coupled will the VSS be to this spec? will there be needs to revisit as VSS evolves? 09:28:12 present: Raphael_Troncy(EURECOM), Jaesung_Han(Samsung), Wonsuk_Lee(ETRI), Ted_Guild(W3C), Kaz_Ashimura(W3C), Kevin_Gavigan(JLR), Adam_Crofts(JLR), Junya_Yoshida(Softbank), Matso_Suzuki(Softbank), YoungJae_Shin(Softbank), Yoshi_Tanaka(Softbank), Qing_An(Alibaba), Yingying_Chen(W3C), Junichi_Hashimoto(KDDI), Kazuaki_Nimura(Fujitsu), Tatsuhiko_Hirabayashi(KDDI;remote), Shinjiro_Urata(ACCESS;remote) 09:28:15 rrsagent, draft minutes 09:28:15 I have made the request to generate http://www.w3.org/2016/09/19-auto-minutes.html kaz 09:28:23 Kevin: they will be independent but we will reference specific version of VSS with our publications 09:29:48 Raphael: what about the higher level client API? 09:30:00 Kevin: there will be some dependencies but hopefully we can minimize 09:30:58 … we have made a rather pronounced shift in how we approach this with this signal service spec compared to the previous spec 09:32:14 sam has joined #auto 09:33:04 [ break for 30 mins] 09:33:54 ahaller2 has joined #auto 09:37:45 urata_access2 has joined #auto 09:38:07 I leave for a while for battery reason. 09:48:25 sangchul has joined #auto 10:04:44 urata_access has joined #auto 10:19:04 yingying_ has joined #auto 10:23:12 Kevin: there is an example excerpt of a partial VSS tree 10:23:38 … there is a debate going on about including position for a node in a tree 10:23:59 … left wing mirror obviously is on the left side of the car 10:24:37 … we're arguing position as node versus a numeric index 10:25:00 … in some cases you won't care nor need to know where something is 10:25:29 … until this is settled our diagram will differ from VSS 10:25:54 … there is a get method to get the signal tree 10:26:23 … there is a section about getting signals off the vehicle that might do with a careful read on wording 10:26:52 … implementations by manufacturer will vary but applications built upon this spec can vary 10:27:17 … plus varying authentication levels 10:27:49 … we only cover two entities a user which might be a user or organization and other device 10:28:20 … a use case might be to allow emergency responders to disable [remaining] airbags but obviously you would not want to permit an attacker to do so 10:28:59 … device might be a driver assist (or autonomous) module that would use this spec to be able to send a set signal 10:30:08 … there might be a convoy of vehicles (V2V) that you would want share an alert about a hard braking event 10:31:10 … there will be cases where the combination of user and device will both need authentication to proceed 10:31:57 … an external security authority (out of scope for this spec) will issue user and device tokens 10:32:27 … the implementation of this service spec will be able to authenticate the tokens and impose proper access control 10:33:24 (see Figure 3) 10:34:42 Kevin: client could set auth token when prompted with a 401 or send it up front 10:35:54 Wonsuk: so the client can send the token only when needed 10:36:22 Ted: yes but the application might have more than one token and if denied with a given token could try another 10:39:24 … it might be worth adding a note for implementers to look for (in either server implementation or realtime log analyzer) to look for 401 loops to protect against dictionary style attack with a cache of stolen tokens 10:39:55 Kevin: client will need to reauthenticate if connection is closed 10:40:26 … we previously decided to require SSL for web sockets as a layer of defense 10:41:31 Junichi: an application can have more than one connection correct? 10:41:33 Kevin: yes 10:41:50 Junichi: then it would need to keep track of which connection has what access rights? 10:42:07 Kevin: correct, the application would need to keep track of its connections 10:44:38 Adam: we have touched on this topic before, the web socket can be established from a browser runtime or other app environment 10:45:06 … we have settled on wss://wwwivi for the local connection protocol and hostname uri 10:46:07 Hi, it looks webex audio has disconnected.. 10:46:29 OK 10:46:42 Thanks! 10:47:36 Junichi: how would you handle other devices such as a smartphone in the car? 10:47:56 Kevin: the in-vehicle case can be handled by local wifi LAN routing to wwwivi 10:48:37 … outside the vehicle you would not want to permit a direct connection but to go through a V2X service managed by OEM 10:49:26 Wonsuk: wwwivi would route to IP 10:50:24 Kevin: correct and if the OEM chooses they may have the in-vehicle wifi LAN expose this hostname 10:50:44 Ted: it can impose firewalling to specific authenticated devices 10:53:08 … eg registering a MAC address (spoofable) for owner's phone so the LAN dhcp server gives it an IP within a trusted subnet on the LAN 10:55:00 (this would be on top of tokens for app on phone) 10:56:28 Junichi: is this testable? 10:57:28 Ted: it is, check the name resolution on the LAN replies for wwwivi. next test would be that you can open a wss connection with an ssl certificate that is verifiable, then a get to VSS results 10:59:03 Kevin: alternate is some sort of discovery mechanism 10:59:25 Ted: WoT or Device and Sensors groups might be working on that, we can ask 10:59:37 Philipp: I think they stopped work based on privacy concerns 11:00:06 q+ 11:01:35 Kaz: this might be a good topic with WoT folks this week 11:01:55 … not sure about the specific hostname, maybe something more generic 11:02:10 Kevin: sure but what should we call it? 11:02:15 Kaz: good question :) 11:03:48 QingAn has joined #auto 11:04:48 Kaz: by generic I mean for accommodating other service roles 11:05:04 … we'll talk with WoT more 11:05:56 Adam: we are primarily using WebSocket.send and .onmessage 11:06:21 … we define all our corresponding get and set methods 11:08:21 … whenever the client sends a request to the server it expects requestId so it can keep track of connections on its side 11:08:42 … we've covered tokens. the timestamp is the time of the response from the server 11:09:28 … we are also returning a time to live (TTL) for the duration of the auth token 11:10:03 Junichi: what is the unit of measure for TTL, milliseconds? 11:10:11 Adam: good point, adding 11:11:08 Wonsuk: typically webIDL is for javascript APIs, not sure we should use some webIDL characteristics in this context 11:11:43 Kevin: we have seen others reference DOMstring in this manner 11:12:40 … we are trying to strike a balance here and chose to stick with types used in webIDL 11:24:22 urata_access2 has joined #auto 11:24:30 [discussion on token expiration and renewal use case] 11:25:24 Kevin: these are the get request methods 11:25:50 … I have a preference for requestIDs here too but I was overruled at previous F2F... 11:26:24 … as such it is necessary to give enough information on the response so client can track it better 11:26:53 … you will get a success or error response but cannot be sure if there will be a subsequent and different response later 11:27:22 Adam: a classic example is time sensitive RPM signal data 11:29:21 QingAn: I can see a client sending multiple requests if it doesn't get a response quick enough 11:29:45 … even though you have timestamps on the responses you may ideally only want one response 11:30:27 Kevin: you can provide * wildcard in path to get for example all signal data for all doors at once 11:31:35 Adam: it would be up to the app developer to parse meaning such as left/right 11:32:34 … here is an example of making a request with an invalid path resulting in a 404 11:33:21 … I think these are helpful but wonder if there is a better way to represent this example in the spec 11:33:55 QingAn: it might be better to be able to discover/query the path available 11:34:45 Kevin: it is possible to ask for the whole tree, with their different access control 11:35:03 Ted: are we giving the whole tree or only what the current token is allowed to see? 11:35:12 Kevin: previously we resolved the whole tree 11:36:36 … which is why it is important to have a stable version of VSS in order for us to reference it when we publish 11:37:10 Wonsuk: what will be the format VSS will give us? 11:37:31 Kevin: VSS is YAML but implementers of our service spec will return JSON 11:38:42 Wonsuk: should we entertain multiple types of responses or stick with JSON? 11:39:04 Ted: that might get cumbersome and political so would suggest we stick with JSON initially for FPWD 11:39:56 q+ 11:40:05 Kevin: we could add a comment in the spec about future considerations 11:40:23 Ted: or create an issue in github which would allow for feedback on types desired 11:40:43 q- 11:40:47 Adam: set methods are similar to get ones described 11:40:59 q+ 11:41:48 Kaz: WoT group has also been discussing type so perhaps a topic for our session with them 11:41:59 sam has joined #auto 11:42:13 q? 11:42:26 Adam: we have more detailed types of 404 responses - invalid path or private path 11:43:02 Kevin: even though we're returning JSON structures we felt sending http responses would be useful for web devlopers 11:43:13 s/devlopers/developers 11:43:52 Ted: private_path should be more of a forbidden 11:45:02 … also wonder about overloading error codes as we are. I don't have an answer for that and will need to think on who to ask 11:45:12 … fine as it is for now 11:45:46 Kevin: understood but there is a level of granularity for why you might be unauthorized that is helpful for the web developer 11:46:33 … we also left room for implementation specific error codes 11:47:25 I have made the request to generate http://www.w3.org/2016/09/19-auto-minutes.html ted 11:48:03 Adam: we'll receive set status for lock signal sent (example) 11:48:44 … here is an example of trying to set RPM which is forbidden that gives the path as part of the response 11:49:17 Wonsuk: when client has VSS from the server and tries to parse it, how does it understand what it is permitted to do? 11:49:31 … is that described now or will be it be? 11:49:42 Adam: that is not part of VSS 11:50:02 Kevin: there was a discussion in Portland about providing this metadata 11:50:39 … for the time being we went the simpler route of showing the full tree 11:51:54 … basically you need to try to access (get or set) signal to see what is permitted and possibly try different tokens 11:53:54 Ted: it is a difficult problem but one that would be worth solving in the future given how widely permissions will vary by OEM, token 11:54:38 … app developers will have expectations but also need to fail gracefully when desired interaction isn't permitted 11:54:58 Kevin: there are two more sections to the spec is subscribe and unsubscribe 11:57:41 I leave again and back later. 11:58:50 I will be back at 2pm, too. 11:59:51 [ lunch for 1 hour ] 12:09:40 Karen has joined #auto 12:10:26 sangchul has joined #auto 12:13:23 Geunhyung has joined #auto 12:22:57 Geunhyung has joined #auto 12:51:44 Geunhyung_Kim has joined #auto 12:55:41 ahaller2 has joined #auto 13:03:24 yingying has joined #auto 13:04:46 sangchul has joined #auto 13:08:41 hira has joined #auto 13:08:44 ahaller2 has joined #auto 13:14:21 QingAn has joined #auto 13:15:36 sam has joined #auto 13:16:08 GeunHyung_ has joined #auto 13:16:36 raphael has joined #auto 13:17:04 urata_access has joined #auto 13:17:14 [ after lunch ] 13:18:25 wonsuk has joined #auto 13:19:36 scribenick: kaz 13:19:51 topic: Vehicle Service Spec (Contd.) 13:20:03 kevin: Subscibe and unsubscribe 13:21:04 -> http://w3c.github.io/automotive/vehicle_data/vehicle_information_service.html GitHub doc 13:22:21 q+ to give minor comment on the style 13:22:57 kevin: explains what "subscribe" does 13:24:27 adam: explains "unsubscribe" 13:25:48 ... unsubscribeRequest, unsubscribeSuccessResponse and unsubscribeErrorResponse 13:26:44 ... examples on unsubscribing from a single subscription 13:26:51 ... unsubscription from all subscriptions 13:27:06 ... and error case (due to invalid ID) 13:27:43 wonsuk: branch of the VSS tree 13:27:53 kevin: the path could be the top of the tree 13:28:05 ... and you can use the path flexibly 13:28:17 Karen has joined #auto 13:30:06 kaz: what would happen if somebody unsubscribe part of the VSS tree? 13:30:22 kevin: need to be the same as the one used for subscribe 13:30:53 s/the same/exactly the same/ 13:31:03 kaz: sounds reasonable 13:31:19 junichi: ID 0 is a wildcard? 13:31:28 ... in case there is not subscription 13:31:48 ... what would happen? 13:32:14 kevin: we should specify explicitly 13:33:31 adam: we need another user credential? 13:33:48 kevin: you have to close websocket connection 13:34:20 sangchul has joined #auto 13:35:36 junichi: as a developer, want to open the websocket connection only once the app is invoked 13:36:05 ... so should be just resetting the subscription rather than closing the websocket connection? 13:37:29 junichi-hashimoto has joined #auto 13:37:48 ted: the application may use one specific connection for multiple purposes 13:40:27 kevin: ok to send an authorization message? 13:40:44 ted: the developer may become confused 13:42:23 (some more discussion on how to handle multiple unsubscriptions) 13:44:32 ted: we should keep the model simpler 13:44:58 AdamC has joined #auto 13:49:33 some of the nuances being discussed: 13:50:27 -in present scenario the developer would need to maintain different connections for different signal permissions 13:51:52 prompted with a 401 when trying to access a specific signal the app might try to close connection and reopen with different token[s] (user+device) 13:52:37 app would need to maintain a map of signals it wishes to follow and which connections have access to what, resubscribe accordingly when reconnecting 13:53:27 alternate idea is for an existing connection to be able to send additional tokens and for the server to determine the superset of signals information available for that combination 13:55:15 application code would likely be simpler with second approach 13:55:21 kaz: maybe better to have another explicit action for "unsubscribeAll" rather than using a specific magic number "0"? 13:55:37 kevin: sounds good 13:57:44 kaz: btw, this should be discussed tomorrow during the VSS session but Hira-san was wondering about the possible shorter alias for VSS paths 13:57:48 kevin: that's possible 13:59:22 adam: next 13:59:32 ... 9. Server Side Filtering 13:59:45 -> http://w3c.github.io/automotive/vehicle_data/vehicle_information_service.html#server-side-filtering server side filtering 14:00:56 adam: goes through section "9. Server Side Filtering" 14:02:48 kaz: multiple elements for "range" tag means "and" 14:03:14 ... and if we would like to mean "or", we need to your the filter once again 14:03:17 kevin: right 14:06:25 adam: When the range filter is used a final message will be sent when the value returned is outside of the specified range. For example, if the range states { "below": 100 }, a final value may be received at 101 to indicate that the value is now out of range. 14:07:02 junichi: what if I used very short term for the range? 14:07:33 kevin: may get 429 error 14:08:53 junichi: could I get the error immediately? 14:09:32 sangchul has joined #auto 14:10:44 kaz: is your question related to who decides the minimum "interval"? 14:10:48 junichi: not really 14:10:57 ... rather want to know when I can get the response 14:14:00 kaz: in that case, you want to know when the first response would come to you 14:15:41 kevin: there could be random delay for each signal transfered to the client 14:17:35 kaz: maybe would be better to have timestamp if there is random delay? 14:18:16 junichi: if the delay is too big, maybe I need to use "subscribe" again 14:18:53 kevin: i'm not sure if we have provisions for letting client know if connection is being closed 14:19:45 kaz: might want to have "maximum-acceptable-delay" as a filter tag? 14:22:30 kevin: maybe could use "subscriptionNotification" for that purpose 14:27:32 sangchul has joined #auto 14:27:48 wonsuk: filter is used for some specific path 14:30:16 ... complicated to define the syntax... 14:32:13 kaz: Hashimoto-san, are you happy with the proposed solution? 14:32:28 junichi: would like to see the concrete text for that 14:32:45 ... developers would like to know the response within certain time 14:33:34 ... simple dialog is ok, though 14:34:44 ... developers need to consider state chart diagram for this 14:35:03 ... so we might want to generate some basic state handling model 14:36:17 wonsuk: we should clarify what should be included for the fpwd until when 14:36:23 ... target publication day for that 14:36:36 ted: we could freeze the main branch 14:36:49 wonsuk: when would be the appropriate deadline? 14:37:11 ... maybe before the GENIVI meeting in Oct.? 14:37:35 ... from Oct. 18th 14:37:47 developer have to imagine server state from its output. they would like to see state machine diaglam 14:38:02 wonsuk: so we might want to aim Oct. 7th as the target 14:38:44 ted: Kaz and I could work on that once getting the group approval 14:39:06 ... we have to coordinate with the Webmaster for FPWD, CR, PR and REC 14:40:01 s/filter is used for some specific path/current spec couldn't cover when client requests for VSS branch. 14:40:08 Proposed: publish vehicle signal service spec on 11 October 14:42:23 kaz: fyi, the MMI Architecture also has capability of state transition and event handling, so maybe it would be useful to have joint discussion with them 14:42:29 kevin: interesting idea 14:43:00 ... maybe it would be possible to work on v2 version based on our spec and their spec 14:51:44 [ break till 4pm ] 14:51:46 rrsagent, draft minutes 14:51:46 I have made the request to generate http://www.w3.org/2016/09/19-auto-minutes.html kaz 14:55:30 ahaller2 has joined #auto 15:02:38 ahaller2 has joined #auto 15:04:07 Karen has joined #auto 15:14:42 QingAn has joined #auto 15:16:21 yingying_ has joined #auto 15:17:11 ying_ying has joined #auto 15:20:04 WebEX has been disconnected! 15:23:13 Zakim has left #auto 15:25:32 Karen has joined #auto 15:34:33 urata_access2 has joined #auto 15:40:25 scribe: ying_ying 15:41:02 Topic: WG Rechartering 15:41:23 [some discussion on the timeline of the spec] 15:42:17 kaz_ has joined #auto 15:43:24 ted: we don't need to go through the new charter line by line. just some sections need to. 15:43:56 rrsagent, draft minutes 15:43:56 I have made the request to generate http://www.w3.org/2016/09/19-auto-minutes.html kaz_ 15:44:07 wonsuk and people are going through the scope section. 15:44:48 wonsuk: in the new timeline we will not work on REST. Better to remove it from scope. 15:45:08 kevin: yes. 15:46:28 wonsuk: we need to specify that first we will make the web socket service spec. Later we will work on REST. 15:50:25 Karen has joined #auto 15:50:37 -> http://w3c.github.io/automotive/charter-2016/index.html draft charter 15:52:00 [some discussion on the target vehicles for the spec. now it's limited to passenger vehicle] 15:52:53 Topic: Charter review 15:52:54 scribenick: ted 15:53:39 Ted: W3M has started reviewing, welcome suggestions from WG and will send email update and opportunity for corrections 15:54:18 … please do not make direct modifications but in a branch and send a pull request so I can have reviewers see diff 15:54:43 … we have extended the current charter through the end of the year while we recharter 15:55:17 … we have reviewed the current charter and should be able to publish fpwd of the vehicle signal server spec 15:55:47 … we likely will send this to the AC in a couple weeks 15:56:03 AdamC has joined #auto 15:57:33 Tomoyuki has joined #auto 15:59:57 kaz_ has joined #auto 16:00:43 Jun has joined #auto 16:13:12 ahaller2 has joined #auto 16:14:56 [some discussions on the deliverables] 16:16:53 wonsuk: how could we integrate the timeline into the deliverables expected completion date? 16:17:11 [review on other deliverables section] 16:18:59 junichi: do we have separate documents for use cases and requirements and implementation guidelines? 16:20:14 wonsuk: Ted do we need the document for use cases and requirements? 16:21:24 ted: we need a sort of document to help people understand the background. 16:21:59 hira_ has joined #auto 16:22:11 wonsuk: for the vehicle data spec we have the section for use cases. 16:23:17 ...one way is to move the use cases section to another document and elaborate it and provide a link in the web socket service spec. 16:23:58 ...another way is to have it in the same spec. 16:25:45 example of use case document: http://w3c.github.io/wot/wot-ucr.html 16:27:52 wonsuk: what is your opinion Ted? 16:30:08 Security and Privacy Use Cases document - https://docs.google.com/spreadsheets/d/14ij-2I-H4HbilVQ_muCmUayVqmVfdbkoke690MA0kdo/edit#gid=1078984962 16:30:19 need supporting materials/explanation for client API - since that is derived from old webidl api perhaps we can find some materials 16:36:02 [kevin is going through the security and privacy use cases previously done. 16:36:07 https://w3c.github.io/automotive/vehicle_data/security/ 16:36:24 s/ previously done./ previously done.]/ 16:38:27 junichi: I summarized 7 use cases in the security spec. 16:38:52 ...I think use cases should be satisfied by the spec. 16:39:52 wonsuk: we need to make a decision. 16:41:42 ted: we need something to support the spec. I will take an action to follow up. 16:42:12 ...we don't have the use cases for server spec but we could have it for client spec. 16:42:37 https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification#JavaScript_Library_Interface_Guidelines 16:42:37 ...we may have something for it but I am not sure what is it. Will check. 16:43:31 drkevg has joined #auto 16:45:39 ACTION ted: check what we need for use cases to support the spec 16:45:39 Created ACTION-24 - Check what we need for use cases to support the spec [on Ted Guild - due 2016-09-26]. 16:47:17 wonsuk: do we need to add the security guideline here in other deliverables? 16:48:03 ted: we have the other non-normative document paragraph. I am fine with both: specifically or not. 16:49:04 wonsuk: any other comments on deliverables? 16:49:25 kevin: whether is the decision, suggest to keep the other non-normative document paragraph. 16:52:06 ACTION Adam: make a list of actions for the service spec(what needs to be done in the following months.) 16:52:06 Created ACTION-25 - Make a list of actions for the service spec(what needs to be done in the following months.) [on Adam Crofts - due 2016-09-26]. 16:52:54 [reviewing the timeline section] 16:56:00 wonsuk: could we change the PR time from July to Oct? 16:56:12 -> https://www.w3.org/2015/Process-20150901/#Reports Maturity level for CR etc 16:56:25 ...because we need more time to exit the CR. 16:58:08 Tomoyuki has joined #auto 16:58:18 kevin: we can try our best to meet the timeline. 17:00:02 s/ meet the timeline/ meet the timeline currently planned/ 17:00:18 As I mentioned in the last meeting, the end of March 2017 is preferable, in CR timing. 17:00:35 wonsuk: so we all agree to keep the current timeline. 17:01:19 [reviewing the liaison group list] 17:01:46 ted: please change the device WG to generic sensor WG. 17:02:08 s/device WG /device API WG / 17:02:23 s/generic sensor WG/generic sensor API WG/ 17:03:48 ted: web of things IG is not there. 17:04:46 wonsuk: we have done. 17:06:50 [discussions on the topics of joint meeting with WoT tomorrow] 17:07:44 wonsuk: one topic might be WebIDL or other type when doing spec. 17:09:13 ahaller2 has joined #auto 17:10:46 matthias: we are also working on data type. there is a talk from Google, schema.org. 17:11:11 wonsuk: this is tomorrow's agenda. 17:12:23 ...could we follow the list Kaz sent out for topics of joint meeting with WoT? 17:13:02 matthias: are you interested in the general introduction of WoT, what are the building blocks we are working on? 17:13:06 wonsuk: yes. 17:13:41 ...would create a wiki to add topics for the joint meeting. 17:14:37 wonsuk: we will have a session for security and privacy. expect to have web security people. 17:14:58 ted: only 2 people responded. one will join this session. 17:15:16 wonsuk: any other suggestions for tomorrow's agenda? 17:15:26 [no] 17:15:27 [adjourned] 17:15:38 rrsagent, make minutes 17:15:38 I have made the request to generate http://www.w3.org/2016/09/19-auto-minutes.html ying_ying 17:15:48 Thanks. See you tomorrow. 17:17:27 See you tomorrow. 17:22:35 kaz_ has joined #auto 17:32:06 kaz_ has joined #auto