<kaz> scribenick: mjk
<kaz> agenda
Lagally: discussion of issues and limitations with setting hard limits
McCool: add the canonicalization requirement
<inserted> Smart Coffee Machine Thing
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> 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> WoT Reference Platforms (devices)
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> 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> Preview - 4.2 Reference Device
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: 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> Vorto
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