Meeting minutes
Minutes
McCool: one typo to be fixed
Kaz: fixed
approved
McCool: accessibility consideration to be discussed
At-risk items
McCool: (goes through the
results)
… need to remove unimplemented features
PR 909
PR 909 - Resolve arch-security-consideration-use-psk
McCool: (goes through the
changes)
… removed description around guest
networks
… then changed "pre-shared keys" to "certificates",
and make the feature informative
… we can resolve several issues by merging this PR
909
merged
PR 910
PR 910 - Resolve arch-security-consideration-dtls-1-3
McCool: (goes through the
changes)
… made the description informative
… (shows the preview)
McCool: probably "recommended" would fit better here than "should"
Kaz: that's fine in
this case
… all the Editors should think about what
expression would be the best fit
merged
PR 911
PR 911 - Resolve arch-security-consideration-hal-refuse-unsafe
McCool: added some clarification
Kaz: basically OK with
the changes
… just wondering about the definition of
"HAL"
… maybe the text saying "Hardware abstraction
layers, or HALs"?
McCool: yeah
Kaz: the term is just
used within section 10.2.2 locally
… but "hardware abstraction layer" is used three
times while "HAL" is used three times
… maybe we could clarify what HAL stands for at the
first place
… "A WoT Runtime implementation SHOULD provide a
hardware abstraction layer for accessing the native device
interfaces."
McCool: that is an assertion but ok?
Kaz: just adding clarification for acronym should be ok
McCool: ok
… (adds some more clean up for the tab
spaces)
… (also splits the big paragraph into several
smaller paragraphs)
Kaz: so you simply avoided using "HAL" as the acronym for "hardware abstraction layer"
McCool: right
… also added some more clarification to the
paragraphs
… (shows the updated draft text from the PR
911)
merged
Issues
McCool: bunch of remaining issues there
Issues to be resolved by the PR transition
Issue 589
Issue 589 - Implementation report
McCool: (adds an additional label of "Implementation report")
Issue 864
arch-security-consideration-avoid-direct unclear
Kaz: have we added some clarification about this assertion?
McCool: let's see
Kaz: this assertion can be covered if people use TD to describe the native device interface. right?
McCool: it's for a bit
different purpose from the Architecture viewpoint than TD as the
data model
… saying "low-level hardware interface" would be
clearer
Kaz: in that case, what is the actual requirement here?
McCool: some high-level
software library, for example
… another example is using a high-level interface
to handle the color change function for a PC
Kaz: so some high-level
API is required here
… ok, I think I've started to understand your
actual meaning
… but in that case, this assertion is a bit too
stricter than what the existing WoT implementers have been doing,
because most of them are using WoT Thing Description as the common
data model but don't really implement the API layer to handle
it
McCool: that's true
… so this is a "SHOULD" assertion
PR 912 - Revise native to low-level hardware
the above PR merged, the original issue 864 is closed
Issue 901
McCool: "IoT ecosystem" to
"IoT Platform"
… is that OK?
… (generates a small PR for that
purpose)
PR 913 - Change IoT ecosystem to IoT Platform
PR 913 merged and Issue 901 closed
AOB
McCool: unfortunately, we're out of time
remaining issue to be resolved by PR transition
Kaz: given we still 10 more issues, let's continue the discussion next week
McCool: yeah, we need to do so, but we need to work on Issue 578 quickly
<McCool> proposal: Consider current version a tentative PR Draft, except for the possible addition of an Accessibility Consideration section to address issue #578
Kaz: we have only 4
people today, so making that kind of resolution is a bit
difficult
… so please simply send an email to the whole
WG
McCool: ok, will do
[adjourned]
rragent, draft minutes