14:59:25 RRSAgent has joined #wot-arch 14:59:25 logging to https://www.w3.org/2021/02/11-wot-arch-irc 15:00:02 cperey has joined #wot-arch 15:01:22 mjk has joined #wot-arch 15:01:28 Meeting: WoT Architecture 15:02:00 preesent+ Kaz_Ashimura, Christine_Perey, Michael_Lagally 15:03:11 McCool has joined #wot-arch 15:04:20 Agenda: https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Feb._11th.2C_2021 15:05:34 Mizushima has joined #wot-arch 15:07:54 ml: agenda to continue discussion on the reference constrained device 15:08:12 i/agenda/sribenick: mjk/ 15:08:17 s/agenda/proposes the agenda 15:08:34 i/scribenick/topic: Agenda bashing/ 15:09:09 present+ Michael_McCool, Michael_Koster, Tomoaki_Mizushima 15:10:10 ml: propose agenda item to discuss VF2F 15:10:53 topic: review minutes from February 4th call 15:11:32 -> https://www.w3.org/2021/02/04-wot-arch-minutes.html Feb-4 15:13:54 mjk: 256K RAM seems good for the reference, 512K is available but 256 may be more of a sweet spot 15:15:36 ml: any other comments? 15:15:55 ml: minutes approved 15:16:25 ml: are there any architecture topics for this call? 15:16:46 mm: there is a PR for the term "element" 15:17:42 mm: we need to differentiate from "fragment" which has a special meaning in JSON usage 15:18:52 s/PR/suggestion for the current PR/ 15:19:12 mm: we can merge and create a new issue for "element" 15:20:35 mm: PR is #579 15:21:06 s/merge/close 15:22:16 topic: issue #68 15:22:47 mm: we should think about the workload to determine the sizing 15:23:19 mm: for example, development may have different needs from production deployment 15:23:47 mm: we mostly experience the developer workflow 15:24:09 ml: we need practical experience 15:24:35 mm: we could experimentally profile some application 15:25:15 mm: to determine the bounds of memory use 15:26:05 ml: we need to determine lower bounds 15:27:11 mm: minimum plus application needed memory 15:28:13 i|are there any|topic: PR 579| 15:28:36 i|are there any|-> https://github.com/w3c/wot-architecture/pull/579 PR 579 - Define TD Fragment| 15:30:24 mk: +1 on profiling, we could capture the minimum and an application delta 15:30:57 jerryscript 15:31:01 mm: we could profile node-wot assuming jerryscript 15:31:42 https://news.ycombinator.com/item?id=17995625 15:31:51 this is low.js 15:31:52 s/topic: issue #68/topic: wot-profile issue #68/ 15:32:10 https://jerryscript.net/ 15:32:29 i|we should think|-> https://github.com/w3c/wot-profile/issues/68 wot-profile issue 68 - Reference Device Definition for the smallest possible platform for HTTP / TCP / JSON| 15:32:53 there's also micropython 15:32:58 mm: ROM is cheap in terms of power consumption 15:33:51 q+ 15:34:09 mm: micropython might work 15:34:42 https://blog.arduino.cc/2020/07/02/arduino-security-primer/ 15:35:02 mm: C++ could use arduino as an IDE 15:35:58 https://www.wolfssl.com/?gclid=Cj0KCQiAyJOBBhDCARIsAJG2h5dTB7iAm0YRM3G25Sf4Xf53tzHj9NKCSbYvQ-dIftJ2OOmlHCURnUAaAmbjEALw_wcB 15:36:21 mjk: Arm TLS is the common implementation for embedded devices 15:36:24 q? 15:36:32 anyway, it seems BearSSL targets devides with 32KB 15:36:42 so... 64K is probably "safe" for HTTPS 15:37:31 kaz: there is a question about security certificates 15:37:53 mm: we should look at CoAP and DTLS 15:38:01 s/there is/in addition to memory footprint issue, there is/ 15:38:04 ml: but we also need HTTP 15:38:11 ack k 15:38:41 I think that HTTPS is an upper bound on CoAPS anyhow 15:39:06 so if we can do HTTPS, the same device should be able to do CoAPS 15:40:36 mm: the Arduino blog describes TLS in 32K 15:40:49 ml: does it need the Secure Element to reduce RAm usage? 15:40:56 mm: unknown 15:41:04 s/RAm/RAM 15:41:10 mm: but if we say 64K we should be fine even without hte secure element 15:42:49 ml: ESP8266 has 40K available for applications 15:43:04 ... including communication buffers 15:44:20 mm: length of URLs is probably the biggest factor in TD size 15:45:34 mm: simple devices can use base URI to reduce size 15:45:53 mm: After that, it's number of interactions 15:46:08 mm: 256 maximum URL length seems big 15:46:33 mm: maybe we should constrain the size of all URLs 15:47:13 ... total URL storage size 15:48:33 mm: maybe we need to store the entire TD in RAM 15:49:19 ml: a client will need to read a TD and extract what is needed 15:51:05 mm: a device would need to store a set of forms to interact with the controlled device 15:54:16 mm: sometimes a client will need to do bulk reads, which results in large buffers 15:54:46 mjk: largest response may be the full TD 15:56:03 mm: pagination would limit the required buffer size 15:56:56 ml: let's assume two simple devices interacting with each other 15:58:03 ml: would a TD be bigger than 1-2KB? 15:58:58 mm: we could fix the problem at the architecture level by enabling incremental consumption of TDs 15:59:38 ml: there will still be a minimum for transmitting and parsing 16:00:47 mm: we need a standard way to paginate or incrementally evaluate TDs 16:01:05 https://github.com/w3c/wot-discovery/issues/117 16:01:56 mjk: is it related to the signing and canonical TD work? 16:02:27 mm: there are requirements like signature block size 16:03:06 ... maybe small devices need to store TDs in canonical form 16:03:28 ml: what if we assume we don't have pagination for now 16:04:03 ... with respect to design complexity and the time it would take 16:04:28 ... maybe we can get 90% of the use cases through simpler mechanisms 16:06:31 ml: programming language may not be much of a factor in light of these data size limitation 16:10:46 mm: proposing we could allow 32K for TD size in a 128K device 16:11:10 ... based on HTTP server and other stack estimates 16:11:37 mm: let's look at some TD sizes from the plugfest 16:15:53 mm: looking at the TD repository from the last PF, 4K, 7K, 5K is common, with one 37K TD for a complex camera 16:16:06 ... all using full URLs 16:17:30 ... 32K may be tight in some cases 16:17:33 q? 16:18:09 mm: documentation could be moved to TMs that are references in the TD 16:18:29 ml: is there a base form for TDs? 16:19:50 ml: could we consider 16KB? 16:20:24 q+ 16:21:27 ml: we have a use case with multiple network addresses, for example proxies 16:22:08 ... all consuming devices would be required to have this much buffer space 16:22:40 ... could we achieve a 95% coverage 16:23:18 mm: the memory size required may go up to 128K 16:23:42 s/128K/128K if we require 32K TD size 16:24:11 mm: if we consider a constrained device category, 16K is OK 16:24:49 kaz: maybe we need to consider compression like EXI for constrained TD 16:27:04 mm: 16K as an upper bound may be OK and we could introduce compression later 16:27:26 mm: maybe a light switch doesn't need to consume the camera TD 16:27:31 ack k 16:28:10 ml: let's summarize the notes 16:28:29 ml: let's consider this as a proposal 16:28:42 ... maximum TD size is 16K 16:29:19 mm: we should include the raw numbers and math to help explain our choice 16:29:26 ml: need to close now 16:30:44 ... we have enough to go forward with a PR for a first draft on reference device sizes 16:30:50 ml: AOB? 16:31:00 ... adjourn 16:31:06 dezell has joined #wot-arch 16:31:15 present+ David_Ezell 16:34:21 -> https://www.w3.org/TR/exi-for-json/ EXI for JSON 16:34:49 -> https://tools.ietf.org/html/rfc7049 CBOR 16:35:04 rrsagent, make log public 16:35:08 rrsagent, draft minutes 16:35:08 I have made the request to generate https://www.w3.org/2021/02/11-wot-arch-minutes.html kaz 16:37:04 s/preesent/present/ 16:37:07 rrsagent, draft minutes 16:37:07 I have made the request to generate https://www.w3.org/2021/02/11-wot-arch-minutes.html kaz 16:37:24 s/sribenick:/scribenick:/ 16:37:26 rrsagent, draft minutes 16:37:26 I have made the request to generate https://www.w3.org/2021/02/11-wot-arch-minutes.html kaz 16:38:15 i/proposes the agenda/topic: agenda bashing/ 16:38:29 s|i/scribenick/topic: Agenda bashing/|| 16:38:32 rrsagent, draft minutes 16:38:32 I have made the request to generate https://www.w3.org/2021/02/11-wot-arch-minutes.html kaz