- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 08 Mar 2021 12:45:23 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2021/02/18-wot-arch-minutes.html
also as text below.
Thanks a lot for taking the minutes, Michael Koster!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
WoT Architecture
18 Feb 2021
[2]Agenda
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Feb._18th.2C_2021
Attendees
Present
Kaz_Ashimura, Michael_Lagally, Tomoaki_Mizushima,
Michael_Koster, Michael_McCool, Sebastian_Kaebisch,
David_Ezell
Regrets
Chair
Lagally
Scribe
mjk
Contents
* [3]Topics
1. [4]agenda bashing
2. [5]reference devices
* [6]Summary of Action Items
* [7]Summary of Resolutions
__________________________________________________________
<kaz> scribenick: mjk
agenda bashing
<kaz> [8]agenda
[8] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Feb._18th.2C_2021
Lagally: discussion of issues and limitations with setting hard
limits
McCool: add the canonicalization requirement
reference devices
<inserted> [9]wot-profile issue 68 - Reference Device
Definition for the smallest possible platform for HTTP / TCP /
JSON
[9] https://github.com/w3c/wot-profile/issues/68
<inserted> [10]Smart Coffee Machine Thing
[10] http://plugfest.thingweb.io:8083/smart-coffee-machine
Lagally: refer to the coffee machine example
... what is the size of the coffee machine TD? 9KB
McCool: multiple languages could make it larger than 16K
... we had the idea of reducing the TD by shifting description
to the TM
Sebastian: there is a Vorto model that is 50KB
... there is a problem with the profile imposing limits on TD
size
Lagally: we need to accommodate some minimum device
Sebastian: but the minimum device will change a lot over time
and there will be rich edge devices
McCool: we can canonicalize TDs to make elements easy to find
... maybe we don't need to have a limitation
... we want to accommodate simple use cases like functional
pairing of two devices
Lagally: to explain further, this would not prohibit complex
devices from being larger, but it would set an expectation for
small devices
... a low level barrier to entry for small devices
McCool: there will always be device types driven to economize
everything
... we can set the minimum based on the capability of cheap
current devices
... e.g. ESP devices
Kaz: I agree with Sebastian, we should agree about minimum
capabilities
... based on minimum or small use cases we need to define a
minimum set of TD features
... that all devices are expected to be able to accommodate
... the point is to start with a minimum feature set and work
from there
Sebastian: I am worried that we are making choices that will
limit use cases in the future
... we don't have the real use case
... TD in plaintext may not be appropriate for constrained
devices, it will be compact binary
<McCool>
[11]https://github.com/w3c/wot-testing/blob/main/events/2021.03
.Online/reference/hw.md
[11] https://github.com/w3c/wot-testing/blob/main/events/2021.03.Online/reference/hw.md
Kaz: this reminds me of HTML5 from 10 years ago, where all
phones today are capable
Lagally: but embedded devices have long service life times 7-10
years for a device to be turned over
<kaz> kaz: can understand your point
<inserted> [12]WoT Reference Platforms (devices)
[12] https://github.com/w3c/wot-testing/blob/main/events/2021.03.Online/reference/hw.md
McCool: shared the list of capabilities for a large device vs.
small device
... we exclude any device that can't run TLS, what's the point
but these days even (some of the) embedded devices have full
HTML5 capability like TV sets and Ebook readers. so I think
Sebastian's concern is related to that kind of evolution of
device capabilities.?
... the small device would be able to host and consume TDs and
has a fair amount of resources
... maybe we could accommodate these devices without limiting
the size of consumed TDs by requiring streaming
<mlagally> [13]https://github.com/w3c/wot-profile/pull/69
[13] https://github.com/w3c/wot-profile/pull/69
Lagally: sharing the PR #69 wot-profile PR 69 - Reference
device on reference device
... the methodology section proposed describes that a device
can process TDs
... must be able to consume at least one TD
... the language probably needs to be improved
<kaz> [14]Preview - 4.2 Reference Device
[14] https://pr-preview.s3.amazonaws.com/w3c/wot-profile/69/594c374...e5c999c.html#reference-devices
Lagally: includes a statement that a 16K TDB would leave space
for other application data
McCool: we could explicitly allow a CBOR TD
... are there any features that would break if they convert
CBOR to JSON?
Sebastian: CBOR makes sense for the constrained profile
McCool: constrained profile devices are expected to
interoperate
... profile means constrained profile
Lagally: the goal is to make it easy for implementers to set
expectations
Sebastian: what is the market? if it is embedded, we wouldn't
use HTTP and JSON
Lagally: we used a lot of HTTP and JSON in the plugfest
Sebastian: OCF devices would require CBOR
McCool: we would also need to allow CoAP in the profile
... a lot of embedded devices can use HTTP
<Zakim> kaz, you wanted to mention it would be betterto use
"Minimum target device" instead of "Reference device" here
Kaz: also it might be better to align the data models with
profiles, e.g. CoAP or CBOR, as the name or class of the
profiles rather than "Core"
Sebastian: not sure the plugfest TDs are representative of
production TDs or representative of the market
Koster: +1
<sebastian>
[15]https://vorto.eclipseprojects.io/api/v1/models/com.bosch.io
t.suite.example.octopussuiteedition:OctopusSuiteEdition:1.1.0/c
ontent
[15] https://vorto.eclipseprojects.io/api/v1/models/com.bosch.iot.suite.example.octopussuiteedition:OctopusSuiteEdition:1.1.0/content
Sebastian: we are in experiment mode in plugfests and don't
bother to represent everything that a product will have
... maybe someone will make a new chip next year
Lagally: again, the profile doesn't forbid larger TDs
... it would not be compliant with the embedded profile
McCool: very small devices don't need to handle TDs in a system
Lagally: not sure that more hardware RAM will always be
available for large TDs
... we could also add edge or gateway profiles for richer
devices
scribenick: kaz
Koster: what would be the use cases here?
... trying to compete with project CHIP?
... could be HTTP/JSON
... we really need to be careful
Lagally: good point
... Sebastian, do you think you could provide some examples?
Sebastian: no...
scribenick: mjk
Koster: will provide the Modbus PID controller TD
<Zakim> kaz, you wanted to wonder about actual embedded devices
maybe like Modbus sensors :)
McCool: let's categorize things more and try to propose some
reasonable constraints
Lagally: can we bring these more realistic TDs into the
plugfest?
... bring TDs to the plugfest even if they are a soft
implementation
McCool: we need some limits for some categories and use cases
... we could exclude very small devices and leave the issues up
to implementers
Sebastian: the Vorto model and DTDL language models would be
good references
... this would be a good guess
... the Vorto example is 45KB
<sebastian> [16]Vorto
[16] https://vorto.eclipseprojects.io/#/details/com.bosch.iot.suite.example.octopussuiteedition:OctopusSuiteEdition:1.1.0
Sebastian: TD should be self contained and not require external
references to process
Lagally: using base concepts should also not be required
Sebastian: there will be some normalization/canonicalization
Lagally: is there anything significantly larger?
Sebastian: there are use cases for TD exchanging 9000 data
points
<Zakim> kaz, you wanted to mention probably we could think
about some kind of proxy or intermediary which can handle TDs
appropriately for small devices (and thought that was our basic
Kaz: we can think of typical devices and require them to handle
TD (and clarify our expectation for WoT-ready devices), and
even smaller devices (which can't handle TD by themselves)
still can use a TD proxy
Lagally: suggest the term "native WoT device" vs one that needs
a helper
... what about larger sizes? can we look at more examples and
decide on a reasonable size?
McCool: we need to categorize the examples by use cases
... we don't want to require devices that are too large and
drive our solution out of the market
Sebastian: what is the use case behind an embedded device
consuming TD
Lagally: devices that don't have UI features
Sebastian: what is the realistic scenario? does the switch
really know enough?
Lagally: time check, 10 minutes left
... new information from DTDL and Vorto
... we also have already defined the scope as small and
embedded
... concerned that we are limiting progress
... can we go forward with the reference device?
Sebastian: can we make a weaker statement about the
constraints?
Lagally: it still needs to be a hard number to prevent DOS
attacks
McCool: propose a limit but large, like 64K, or multiple
categories with limits
Kaz: suggest that we publish a reference device capability and
recommend intermediaries for devices that are significantly
smaller
McCool: we could also base the profile on TD size
Kaz: both concepts are similar but we need to be careful about
how to describe the concepts
Sebastian: consuming is not required in the same way vs.
producing
McCool: producing is not aproblem
Koster: capture the points of DOS mitigation and realistic TD
consumer expectations
Lagally: please put in comments and PRs to evolve a solution
... need to discuss vf2f and canonical TD
... please write issues and PRs
Sebastian: need more discussion of DOS attacks
Koster: DOS attack is a system issue
Kaz: maybe there is a dynamic way to size the system using
APIs. I think I should bring that point back to the Scripting
API TF.
Lagally: AOB?
... please follow up on the discussion; adjourn
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [17]scribe.perl version
1.152 ([18]CVS log)
$Date: 2021/03/08 03:44:05 $
[17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[18] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 8 March 2021 03:45:31 UTC