11:02:25 RRSAgent has joined #wot-profile 11:02:25 logging to https://www.w3.org/2022/03/30-wot-profile-irc 11:02:31 meeting: WoT Profile 11:02:39 present+ Kaz_Ashimura, Michael_Lagally 11:02:45 chair: Lagally 11:05:42 present+ Michael_McCool 11:06:38 present+ Tomoaki_Mizushima 11:06:55 Mizushima has joined #wot-profile 11:07:10 McCool has joined #wot-profile 11:07:17 agenda: https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#WoT_Architecture_.28Profile.29_-_March_30st.2C_2022 11:07:17 topic: minutes 11:07:21 mlagally has joined #wot-profile 11:09:06 -> https://www.w3.org/2022/03/23-wot-profile-minutes.html Mar-23 11:09:26 mm: note I have not updated the profile IR, mostly have been working on arch IR 11:09:50 ml: regarding events, ben was working on a PR 11:10:07 ml: any objections to publishing? 11:10:19 ... hearing none, we will publish these minutes 11:11:18 https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf 11:11:35 topic:new issues 11:11:45 ml: new issue #190 11:12:31 ... ben noted that use cases and requirements should be moved to another document; has "blocks publication", not sure why 11:12:38 i|190|subtopic: Issue 190| 11:12:50 i|190|-> https://github.com/w3c/wot-profile/issues/190 Consider splitting Use Cases & Requirements out into a separate document| 11:13:36 -> https://github.com/w3c/wot-profile/labels/blocks%20publication Issues which block further publications 11:13:36 ryuichi has joined #wot-profile 11:16:43 present+ Sebastian_Kaebisch 11:17:02 mm: suggestion to resolve this particular issue is to change name to "summary of use cases and requirements" 11:17:21 ml: more general issue is we do need to review "blocks publication" usage 11:17:43 mm: still only about 1/3 of the use cases are marked this way 11:18:18 present+ Ryuichi_Matsukura 11:19:44 topic: profile names 11:20:04 ml: four have been proposed 11:20:22 [[ 11:20:23 Core Profile 11:20:23 Core HTTP Profile 11:20:23 Baseline Profile 11:20:23 Baseline HTTP Profile 11:20:24 ]] 11:20:50 q+ 11:21:51 mm: I would prefer "HTTP Baseline Profile"; core is contentious, and HTTP should be mentioned 11:22:16 -> https://github.com/w3c/wot-profile/issues/5 "Core" profile name has undesired implications 11:22:54 ml: I would support HTTP Baseline or Baseline HTTP 11:23:04 kaz: so there could be extensions, right? 11:23:16 ml: yes, for example, to include event 11:23:23 kaz: in that case, concur 11:23:29 ack k 11:25:13 proposal: use the name "HTTP Baseline Profile" for the HTTP profile that includes properties and actions. 11:26:40 proposal: use the name "HTTP Baseline Profile" for the HTTP profile that includes properties and actions. (closes https://github.com/w3c/wot-profile/issues/5) 11:26:53 resolution: use the name "HTTP Baseline Profile" for the HTTP profile that includes properties and actions. (closes https://github.com/w3c/wot-profile/issues/5) 11:27:44 Proposal: Split core into baseline + (multiple) event bindings 11:27:44 topic: profiles for event bindings 11:28:47 ml: see PR 118, draft where SSE and WebHooks broken into separate sections, and use names "HTTP Baseline Profile" plus "HTTP SSE Profile" and "HTTP WEbhooks Profile" 11:29:32 ml: not sure how security go moved 11:31:09 mm: looks like it was part of error responses, which was moved above events, which is fine 11:31:20 s/PR 118/PR 188/ 11:31:30 i|draft where SSE|subtopic: PR 188| 11:31:46 i|draft where SSE|-> https://github.com/w3c/wot-profile/pull/188 PR 188 - Split Core Profile into HTTP Baseline Profile and HTTP SSE Profile| 11:31:53 rrsagent, make log public 11:31:59 s/WEbhooks/Webhooks/ 11:32:06 rrsagent, draft minutes 11:32:06 I have made the request to generate https://www.w3.org/2022/03/30-wot-profile-minutes.html kaz 11:32:40 mm: my personal opinion is that having separate profiles for SSE and Webhooks makes sense 11:32:56 ... although might lead to some fragmentation, better than alternatives 11:33:01 ml: concur, let's merge 11:33:15 topic: contributions 11:34:43 https://github.com/w3c/wot-profile/pull/145 11:35:02 ml: PR 145 - remove outdated content; merge conflict, will resolve and merge 11:35:48 i|pull/145|subtopic: PR 145| 11:35:55 s/https/-> https/ 11:36:27 s|pull/145|pull/145 PR 145 - removing outdated+obsolete content| 11:36:39 ml: PR 104 11:36:46 https://github.com/w3c/wot-profile/pull/135 11:37:12 mm: only one minor point, should really say "chronological order as seen by the server", but ok with merging as-is 11:37:15 ml: ok, merging 11:37:21 ml: PR 131 11:37:22 s/PR 104/PR 135 for Issue 104/ 11:37:28 s/https/-> https/ 11:37:46 s/135/135 PR 135 - Define order of arrays in queryallactions - closes #104/ 11:37:55 i/PR 131/subtopic: PR 131/ 11:38:23 -> https://github.com/w3c/wot-profile/pull/131 PR 131 - initial draft of a "common constraints" section 11:40:17 mm: I would like to suggest that we hold this PR and take comments and improve it. 11:40:27 ml: have been waiting for comments 11:41:37 mm: are there any constraints that are not data model constraints? Eg. time and date formats are data model constraints. 11:42:06 ml: would suggest merging as a placeholder for now; if we don't need it, can delete it later 11:42:33 ... have a merge conflict, will fix 11:42:50 mm: suggest extend ed note to say will remove if there aren't any 11:43:07 ml: PR 127 11:43:24 ... timestamps to action protocol binding 11:44:38 mm: my concern is that not all constrained devices will have a clock 11:45:44 ... and if this is mandatory, means that it can't be implemented on Things without them 11:46:14 ml: let's start by assuming clocks are not synched, and might be low-resolution 11:46:36 i/PR 127/subtopic: PR 127/ 11:47:16 i|PR 127|-> https://github.com/w3c/wot-profile/pull/127 PR 127 - Add timestamps to actions protocol binding - closes #101| 11:47:52 mm: not a total blocker, since devices capable of HTTP probably also have an RTC 11:48:13 q+ 11:48:31 mm: but at the very least it adds a hardware requirements 11:49:25 mm: feel there are two options: add hardware requirement, make it optional 11:49:31 -> https://www.w3.org/TR/hr-time/ High Resolution Time 11:49:36 kaz: wondering about resolution of time-stamp data 11:49:44 q+ 11:50:01 ack k 11:50:09 kaz: might want to see what it says about time resolution 11:50:26 ml: would say it is very device dependent, resolution might be quite low 11:50:58 kaz: depends on the use cases, we should perhaps define 11:52:35 mm: agree, we should think about purposes: sequence, elapsed time for actions, etc. 11:52:53 ... for instance, maybe we only need sequence numbers and relative time 11:53:30 ... also, there is the problem of initializing the clock; when is that done? Onboarding? 11:53:31 q? 11:55:13 ml: so sequence numbers and relative time? 11:55:28 mm: may not even need that, have sequence from query ordering 11:55:46 ... as kaz said, we need to be more precise about use cases 11:57:47 subtopic: PR 87 11:57:57 -> https://github.com/w3c/wot-profile/pull/87 PR 87 - Placeholder section on transport security 12:01:05 mm: think this makes more time to discuss than we have 12:01:10 ml: ok, will defer 12:01:15 adjourn 12:01:21 rrsagent, draft minutes 12:01:21 I have made the request to generate https://www.w3.org/2022/03/30-wot-profile-minutes.html kaz 12:42:02 Mizushima has left #wot-profile 14:03:34 Zakim has left #wot-profile