14:03:35 RRSAgent has joined #wot-arch 14:03:35 logging to https://www.w3.org/2021/07/29-wot-arch-irc 14:03:42 meeting: WoT Architecture 14:03:56 McCool has joined #wot-arch 14:04:03 chair: Lagally 14:04:27 present+ Kaz_Ashimura, Ben_Francis, Michael_Lagally, Michael_McCool, Michael_Koster 14:04:48 mjk has joined #wot-arch 14:05:48 Agenda: https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#July_29th.2C_2021 14:07:37 scribenick: McCool 14:07:41 https://www.w3.org/2021/07/22-wot-arch-minutes.html 14:08:02 topic: minutes 14:08:21 s/topic: minutes// 14:08:25 i|https|topic: minutes| 14:08:46 ml: any issues? "ben you wanted to react to McCool", what does that mean? 14:08:58 Mizushima has joined #wot-arch 14:09:01 ... let's remove it, it does not seem to have any meaning 14:09:51 removed 14:10:26 mm: note we merged sebastian's TM PR, but I did not get a chance to update mine (which layers on top of Sebastians) 14:10:46 ml: any objections to publishing? None... will be published 14:11:23 s/removed/removed ( that is automatic log by Zakim in response to Ben's "q+" at that time) 14:11:30 rrsagent, make log public 14:11:34 rrsagent, draft minutes 14:11:34 I have made the request to generate https://www.w3.org/2021/07/29-wot-arch-minutes.html kaz 14:11:39 https://github.com/w3c/wot-profile/pull/78 14:11:39 topic: prs 14:12:12 bf: let's reorder things to do actions and events first; also multiple data model PRs 14:12:15 present+ Tomoaki_Mizushima 14:13:16 ml: data model PR restructures just data model section, there is another PR that removes it from ben; will discuss 14:13:30 ... but let's do actions first (#89) 14:13:41 topic: PR #89 - Actions 14:13:52 ... this should close issue #81 14:14:26 ... some open issues are whether the link to the resource should be in the header or in the body of the response 14:14:35 cris has joined #wot-arch 14:15:29 mm: I do think this is overall in the right direction 14:16:57 mm: regarding headers, I think "doing what people expect" is stronger than "protocol independence" 14:17:30 ml: disagree, I think we are trying to develop an abstraction, so the details should not matter so much 14:18:37 https://github.com/w3c/wot-thing-description/issues/302#issuecomment-884867648 14:19:03 mm: if we are using an abstraction, the real point is can we describe the abstraction with the TD, e.g. can we easily extract information from a header? 14:19:39 ca: yes, agree, we can describe input data for a header, but not currently output data 14:20:09 ml: if it's in the body, then the implementation is also easier 14:20:33 bff: in JS at least, easier to get from the header than the body 14:21:06 mm: still two actions rather than two (storing body, or storing body and header) 14:22:03 rrsagent, draft minutes 14:22:03 I have made the request to generate https://www.w3.org/2021/07/29-wot-arch-minutes.html kaz 14:22:06 bf: only applies to async case... is no body, status is a separate resource 14:22:35 ml: could combine them 14:23:07 bf: yes, could do that, but would have to make status member optional, consumer would have to follow link, would have self-links in some cases 14:23:15 ... it makes things complicated 14:23:36 i|this should close issue #81|-> https://github.com/w3c/wot-profile/pull/89 PR 89 - Define protocol binding for actions - closes #81| 14:24:22 mm: having a self-link in the status object is not the end of the world 14:24:27 bf: agree 14:24:31 present+ Cristiano_Aguzzi, Sebastian_Kaebisch 14:24:45 bf: ok to put it in both places 14:24:47 s|topic: prs| 14:25:01 i|/pull/78|topic: PR 78| 14:25:06 ml: would have a preference to make it mandatory in the body 14:25:09 rrsagent, draft minutes 14:25:09 I have made the request to generate https://www.w3.org/2021/07/29-wot-arch-minutes.html kaz 14:26:08 mm: best interop approach would be to make it mandatory in both places, and also assert they are the same 14:26:20 ... then the consumer can get it from where it is most convenient 14:26:27 ... does add some overhead, but... 14:26:36 bf: I can do that, and is ok 14:26:56 ml: why do we need different data models? 14:27:09 bf: think you might be confusing sync and async cases 14:27:18 ... there are different resources for these two 14:27:39 ml: in invocation can we just return the action status? 14:28:03 bf: but our mechanism for distinguishing the two responses would have to change 14:29:21 ml: can just put a flag in the response to distinguish the two; a "done" flag can let you know which is which 14:29:48 bf: so that changes the API a little 14:32:07 mm: (talks about how sees API would work with single action status) 14:33:05 bf: could use status section, "pending" vs. "completed" 14:33:28 q+ 14:33:38 q? 14:35:11 mm: I can look at the PR updates tomorrow and give my feedback immediately 14:35:24 kaz: would also be useful to have some basic background 14:35:47 ... maybe we can discuss this mechanism based on this example 14:36:25 mm: good idea, but would be useful to extend the example to have some output, as ben already mentioned 14:36:45 bf: have a separate pull request to have a TD at the top to use as an example 14:37:23 ... only partially complete; my intention is to keep updating that as we work through other items 14:37:45 ml: examples by nature are informative 14:38:55 mm: even a TM won't work, since a device might have multiple actions; maybe a TM template fragment? 14:39:27 ... at any rate we should start with good examples 14:39:59 ml: and also to summarize: resource link in both header and body; always return action status 14:43:56 ml: for parallel actions, rather than an error, could have a special status, like "blocked" 14:44:10 bf: I think an error code would be better myself 14:44:54 mm: I will take an action to create an issue to follow up on this 14:46:09 mm: then there are notifications of action completion... 14:46:15 bf: feel we should defer that 14:46:59 mm: I think keeping it simple for now is best, as long as we are not painting ourselves into a corner 14:47:02 ml: ok 14:47:08 topic: data models 14:47:39 ml: PR #93 14:47:57 ... this moves description to a recommendation rather than a requirement 14:48:05 bf: send a response to this PR 14:48:38 ... not that we don't care about human readability, but it's not central to the "interop" goal, which we agreed we would focus on 14:49:00 ... I still think we should remove this section due to conflicting requirements 14:51:13 bf: other part of this feedback is this could be moved to TD spec; recommendations should be in TD 14:51:30 mm: titles might be interop issue for UIs 14:53:04 q+ 14:53:09 q- 14:54:38 seb has joined #wot-arch 14:54:40 q+ 14:55:00 q? 14:55:40 https://github.com/w3c/wot-thing-description/issues/1195 14:55:41 cris: think style rules are specific to human readability, e.g. multiple languages, etc 14:56:01 ... those rules are better treated in the context of the TD 14:56:22 ... and it's weird to disallow talking with a thing if the title is missing 14:56:50 ... so I think we should simplify the core profile and not include this here 14:57:07 ml: so are we aiming at interop between people or between people? 14:57:33 s/between people or between people/between devices or between people/ 14:58:07 ca: think of this like linting tools to improve style; code can work, but be bad style 14:58:16 ... we want to focus on function first 14:58:52 seb: ml, I understand your motivation; but it does not guarantee the title will be used in a nice way 14:59:12 ... someone might just use an empty string; is still open to abuse, in other words 14:59:39 ... also, maybe we don't need the title in some cases, e.g. if we are using semantic annotations 14:59:55 ... schema.org will already provide meaning from which I can generate button titles, etc. 15:00:09 ... don't want to repeat it in the title and description 15:00:15 q+ 15:00:30 ack c 15:00:32 ml: of course we cannot prevent abuse 15:00:49 ... people can leave the title empty; but it at least makes them think about it 15:01:00 ... so they are not forgetting about it 15:01:43 bf: this is the same rationale that led to security being unnecessarily verbose 15:02:19 q? 15:02:27 ack s 15:02:29 ack m 15:03:33 scribenick: kaz 15:04:10 (Lagaly and Cristiano leave) 15:04:20 (McCool takes over the Chair's role) 15:05:39 topic: PR 92 15:05:49 -> https://github.com/w3c/wot-profile/pull/92 PR 92 - Define protocol binding for events - closes #42 15:06:18 bf: protocol binding or events using SSE 15:06:27 ... (goes through the PR) 15:07:34 mm: my issue with making subprotocol for event... 15:08:01 ... would be better to say protocol should have SSE as a subprotocol 15:08:47 ... which spec to be referred to? 15:09:02 bf: used the reference provided by the ReSpec 15:09:40 mm: W3C spec or WHATWG spec? 15:10:35 bf: currently referring to https://www.w3.org/TR/eventsource/ 15:10:45 mm: Superseded REC 15:11:05 ... wondering about when the WHATWG spec would become a REC 15:11:14 https://www.specref.org/?q=eventsource 15:11:26 q+ 15:12:02 ack k 15:12:17 kaz: thought we had discussion with PLH and Ralph at some point 15:12:28 ... and Ralph suggested we rather use the WHATWG spec 15:12:31 mm: right 15:13:16 kaz: so we should refer to the WHATWG spec manually for the moment? 15:13:22 bf: yeah, could do so 15:14:07 -> https://html.spec.whatwg.org/multipage/server-sent-events.html HTML5 LS - 9.2 Server-sent events 15:15:02 mm: (describes McCool's latest comments) 15:15:20 -> https://github.com/w3c/wot-profile/pull/92#issuecomment-889136209 McCool's comments 15:15:21 sorry, I need to go 15:15:41 s/sorry, I need to go/(Sebastian leaves) 15:15:50 mm: problem with credentials 15:16:07 ... should review the security for events 15:16:36 ... any requirements for keeping connection open? 15:17:10 ... need to clarify what the role of Profile is 15:17:54 bf: one benefit of SSE is being a builtin mechanism 15:18:19 ... not clear to which protocol to be pick on the server side 15:18:33 ... and some concern on the client side 15:18:51 ... limit of 6 connections 15:19:18 s/connections/connections per domain/ 15:19:34 mm: agree we should consider SSE 15:20:03 ... and we should agree the scope of the Profile is limited 15:20:33 bf: fine to have multiple event operations 15:20:48 ... this is implementation-specific limitation 15:20:51 mm: right 15:21:10 ... kind of hacky workaround there 15:21:36 ... anyway, still think SSE is the way to go 15:21:44 bf: what about canonical TD? 15:22:14 mm: the definition is the same as the original TD 15:22:39 [[ 15:22:40 The canonical form should not change URLs - perhaps you meant the form, e.g. with default values filled in? 15:22:41 ]] 15:22:47 bf: responded to that point 15:22:58 [[ 15:22:58 The important part here is that defaults need to be applied to the Form, otherwise there may not be a Form with a subscribeevent operation because the op member may have been omitted. Specifying Canonical TD is just a shorthand way of saying to apply defaults first. Please let me know if you can think of a better way of specifying that. 15:22:59 ]] 15:23:07 bf: a form with default supply 15:23:28 mm: would be safer 15:23:42 ... maybe it's self-contained 15:23:49 ... (adds another comment) 15:24:40 ... probably safer to just explicitly say "apply all defaults" and not depend on canonical TDs 15:24:59 bf: in the Scripting API, you can close the connection 15:25:19 ... Web browsers basically keep the connection 15:25:41 ... the server can also provide recommended period 15:26:13 mm: webhook is right way to handle the problem 15:26:37 ... (looks at another comment from Ben) 15:26:39 [[ 15:26:47 but I don't think it's common to use a URL 15:26:48 ]] 15:27:10 mm: any other comments? 15:27:22 ... not convinced we can merge this PR 92 right now 15:27:42 ... do we want to make this "PENDING"? 15:28:07 bf: noted three action points here 15:28:51 ... subprotocol of SSE 15:29:00 ... WHATWG version of spec 15:29:59 ... replace canonical TDs reference with "Forms with defaults applied" 15:30:03 ... based on the discussion tody 15:30:07 s/tody/today/ 15:30:44 topic: PR 94 15:31:03 -> https://github.com/w3c/wot-profile/pull/94 PR 94 - time format - initial draft 15:31:07 mm: any thoughts? 15:31:22 ... (adds some comments) 15:31:48 ... constraining datetime reduces complexity 15:32:04 ... but doesn't necessarily improve interoperability 15:32:50 ... if we do accept this PR, a dependence on canonical form is OK since that part of canonicalization is not likely to go away 15:33:03 -> https://github.com/w3c/wot-profile/pull/94#issuecomment-889245894 comments added 15:33:36 topic: PR 87 15:34:12 -> https://github.com/w3c/wot-profile/pull/87 PR 87 - Placeholder section on transport security 15:34:34 mm: related to https://github.com/w3c/wot-security-best-practices/issues/13 15:34:59 ... Update Secure Local Transport 15:35:20 ... Local HTTP CG doesn't have resolution 15:35:34 ... any thoughts/comments? 15:35:52 bf: what we can say is an easy way possible 15:36:07 mm: (adds a comment) 15:36:20 ... don't think we can mandate HTTP... 15:36:41 ... so defer it to the WoT Security Best Practices document 15:38:26 ... anybody knows any information? 15:39:07 bf: for interoperability, should provide a list of security schemes. 15:39:20 mm: (adds another comment about that) 15:39:36 ... API key is open-ended 15:40:39 bf: we already have a list of security schemes 15:40:54 ... none, barer token, OAuth2, etc. 15:41:32 mm: we should review the list and perhaps constrain them a bit 15:41:53 ... even OAuth2 has some variations, e.g., on where the token is embedded. 15:44:54 ... we should also perhaps disallow certain things like "in": "uri" 15:45:15 ... which is generally a bad idea but is there for compatibility reasons 15:45:30 -> https://github.com/w3c/wot-profile/pull/87#issuecomment-889255913 comments 15:45:38 bf: how to proceed? 15:45:51 mm: can continue the discussion by emails as well 15:46:05 ... to get a consensus 15:46:46 bf: we want all the stakeholders to approve the PRs. right? 15:46:49 mm: yeah 15:47:03 ... basically consensus-based 15:47:20 s/stakeholders/Editors/ 15:49:27 https://www.w3.org/WoT/IG/wiki/Marketing_WebConf#Policies_and_Publication_Procedures 15:49:28 ... we should have some appropriate policy 15:49:42 bf: what about the other groups? 15:49:50 kaz: depends on groups 15:50:04 ... we, WoT WG, can clarify our own policy 15:50:14 ... like we did for the Marketing purposes 15:50:28 mm: (shows the policy for the Marketing TF) 15:51:13 -> https://www.w3.org/WoT/IG/wiki/Marketing_WebConf#Policies_and_Publication_Procedures Policies and Publication Procedures 15:52:33 mm: can have discussion during the WoT main calls as well 15:52:37 [adjourned] 15:52:43 rrsagent, draft minutes 15:52:43 I have made the request to generate https://www.w3.org/2021/07/29-wot-arch-minutes.html kaz 17:17:12 Zakim has left #wot-arch 18:08:40 kaz has joined #wot-arch