Meeting minutes
Agenda
Lagally: terminology discussion is the main topic
(almost same as the agenda for last week :)
Prev minutes
Lagally: (goes through the minutes)
… we talked about the APA meeting
McCool: created an issue about that
issue 578 - Accessibility considerations of WoT architecture
Lagally: let's approve the minutes themselves first and then talk about the accessibility topics later
McCool: ok
… let me go through the APA minutes and pick up several issues from them
Lagally: ok
… (and then goes through the prev Architecture minutes again)
McCool: there is a link for Discovery within the minutes
Lagally: ok
… I'll take a note
… and then we had discussion on Profile
… max size, max number, etc.
McCool: we should see what's done for zigbee, etc.
Lagally: yeah, should clarify some reference device
… e.g., Raspberry Pi and even smaller one
McCool: yeah, what is the minimum environment for WoT
Kaz: could be a good topic for the expected liaison with Echonet
Lagally: we need more detailed information on minimum/maximum expectations
<McCool> spec for constrained devices: https://
Lagally: any concerns on the minutes?
(none)
approved
Accessibility
Lagally: for Architecture?
… or more related to the other specs?
McCool: some of the points during the joint call were interesting
… two large categories of use cases
… developer use cases and user use cases
… multiple descriptions for multiple usages
… language negotiation as well
… bunch of developer use cases for home gateway
… one idea is put requirements for i18n
… a few more things to be sought out
… metadata added by the directory
… a possible option is making it optional
… minimal requirements for TDs for only some specific languages
Lagally: there are many things to do :)
… canonical representations to be contained
McCool: progressive approach for spec generation
… already have problem with language negotiation
Lagally: the question in the terms of accessibility...
… what kind of implications there?
McCool: general idea is allowing progressive disclosure
… privacy would be also to be considered
… proposal on signing as well
… need to have some chained proof
… likewise, canonical forms
… when to do the canonicalization?
… when you compute the sign?
… part of the signing process?
… making it part of the process would be cleaner solution
… do we have things to be put?
Lagally: basically, those are requirements
Kaz: yeah
… the APA guys mentioned the existing requirements document from their viewpoint
… so we should consider them
… also we should think about requirements for WoT accessibility from our own use cases viewpoint
Lagally: ok
… (visits the wot-usecases repo and create an issue for that direction)
wot-usecases issue 95 - Use case to motivate for Integrity Protection Requirement
McCool: possibly some use cases from the accessibility viewpoint
… e.g., smart city accessibility
Lagally: yeah
… we've asked them to join the use cases calls already
McCool: right
… to have a 1:1 call would be also useful
… putting the basic ideas into an MD file based on the discussion
… important to capture their points
Lagally: yeah
… starting with 5-6 headlines
Kaz: given the timing, inviting them to the vF2F as well would be also useful
Lagally: let's invite them to the use cases call next week, and then see what should be done next
McCool: ok
… would send a proposal to them
… starting with a 1:1 first
… then inviting them to the use cases call
(and also to the vF2F as well :)
Lagally: we should invite Gyu-Myoung from ITU-T SG20 as well
Profile
Lagally: would like to talk about Profile next
… we've been reviewing comments for the FPWD
Lagally: at some point, we might want to look into the actual devices, e.g., gateway and others
… we have to pick up typical examples
<McCool> https://
McCool: the above is a document on terminology for constraint devices
… Carsten is involved
… section 3 of the document says...
… classes of constrained devices
| Name | data size (e.g., RAM) | code size (e.g., Flash) |
+-------------+-----------------------+-------------------------+
| Class 0, C0 | << 10 KiB | << 100 KiB |
| Class 1, C1 | ~ 10 KiB | ~ 100 KiB |
| Class 2, C2 | ~ 50 KiB | ~ 250 KiB |
Lagally: would like to exclude class 0 and 1 for WoT, though.
McCool: class 0 is almost some kind of controller
… don't see our classes would fit gateway devices
… so our expected devices to be added to this class definition
Lagally: we could extend this class table
McCool: we could define class N
… additional definitions based on this table
Lagally: what if we want to have a minimum class for HTTP connection?
McCool: pretty small devices can also handle HTTP connection these days
Lagally: (searches for information on several small circuit boards)
… why don't we make the following our assumption...
… 448kb ROM, 520kb SRAM
… maybe we would be even smaller later
… but let's start with this
McCool: we should clarify our aspects too
… directly supporting WoT capability or not, etc.
… should we define a hub for predefined devices?
… should avoid a hub for small devices
… but should think about the WoT native devices
Lagally: let me capture the discussion as a GitHub issue
… define a minimum device which can run a TCP/HTTP stack and consume/expose TDs
… working assumption: 512KB RAM / 512KB Frash
… this has been proven to be enough to produce TDs
McCool: we can also ask Fraunhofer and Mozilla about their devices
Lagally: right
McCool: maybe our first class would have simple consumers/producers
Lagally: which just consume a single TD
<McCool> minimum hardware requirements for node servers and servers
McCool: should think about minimum memory requirements for Node.js, etc., too
… e.g., 260MB would be enough for cloud connection
Lagally: (adds that information to a GitHub issue for wot-profile)
… node.js requirement >64MB up to 256MB
… let me record the URLs of the related resources here
e.g., Terminology for Constrained-Node Networks
… (updates his comments on the GitHub issue)
Koster: possibly just process partial TD?
… you can get a form back
McCool: yeah
… directory service server might be smaller
Lagally: a possible use case
… for single TD processor
… extracting pieces of the information from a single TD
… (adds descriptions on "Producer" and "Consumer" to the GitHub comment)
McCool: btw, until when can we have the discussion today?
Lagally: need to leave in 7 mins...
… is this updated assumption reasonable for you?
… 512KB RAM / 512KB Flash
Mizushima: no idea at the moment...
Koster: need to look into the recent situation with low-end devices
Lagally: for the moment, let's think about 256KB RAM instead of 512KB
… note we need TCP / HTTP connection, and also Node capability
Koster: possibly TD got from a storage?
Lagally: yeah
Kaz: thought these days even vending machines and electric power meters have those capability
… would see requirements for devices, e.g., by Echonet
Lagally: yeah, would see
AOB
McCool: have not got any concrete definition for "fragments", etc., yet
Lagally: ok
Koster: btw, is there anybody working on embedded WoT?
Kaz: we can ask Siemens guys as well
Lagally: we should talk about that during the PlugFest calls as well
[adjourned]