Meeting minutes
Agenda
<kaz> McCool's slides
McCool: today we
discuss new charter proposals
… then Kaz reviews presentation
guidelines
… this is specifically important for accessibility
joint call
… goal is to get some draft text for the next
charter
Presentation guidelines
<kaz> PLH's slides
Kaz: As mentioned
previously, for TPAC hybrid meeting has some challenges
… various people from all over the
world
… need to accommodate the in agenda
… please be careful about accessibility of your
slides
… there's a speaker in the conference room in
Vancouver
… please review code of conduct and accessibility
and internationalisation
… speak clearly and slowly
… HTML slide set would be best, PPT is
ok
… check your PPT slides using the accessibility
checker
McCool: you mention 10 mins to change the room - we plan for 5 mins, at the end or start?
Kaz: end 5 mins earlier, 5 mins past the hour
McCool: any boilerplate?
Kaz: Will update the template
<kaz> https://
McCool: we should enable transcripts
Kaz: tooling: we use
IRC and zoom for TPAC and pre-meeting
… GitHub issues and pull requests
… we could also record session and transcript -
should be confirmed in the beginning
… please use irc queue
… use present+
… if scribe misses sth. he should interrupt and
clarify
McCool: scribe should watch the queue, interrupting speaker if necessary
Kaz: will help chairs and scribe
Deliverable proposals
<kaz> McCool's slides
<kaz> wot issue 978 - Goals and Deliverable Discussion for WoT WG 2023 Proposed Charter
McCool: there are 3
proposals (Discovery, Onboarding, Profiles), some were recently
updated
… I'll walk through proposals and then check
labeled issues in TD
… today we have an accessibility joint
call
… if we do digital twins as a deliverable, do we
have to model physical behaviour for a11y?
Daniel: is request for TPAC or pre-meeting?
McCool: you want to
discuss next deliverables, can we scripting down from 45
mins?
… we could also discuss post-TPAC
Daniel: I can try to put sth. together for tomorrow
McCool: We have 3
proposals in this area
… obvious ones are TD 2.0 and Architecture
2.0
… we should write them up in the next 2
weeks
Onboarding
McCool: to do secure
communication we need a identity management process
… separate deliverable or include into another one,
e.g. architecture, discovery or a separate security spec
Lagally: any estimate
on how complex?
… separate spec needed or not
McCool: rather a lifecycle question
<citrullin_> Couldn't we refer to it in discovery and then have the details in another document?
McCool: (mentions security portions)
Lagally: we should
answer two questions, I think
… which TF to work on it?
McCool: difficult to find people having security expertise
<citrullin_> +1 on having it in the task force
McCool: my preference here is including normative security document and onboarding document
<citrullin_> security task force*
Cristiano: agree with
having a security tf
… typically lifecycle discussion needed
Cristiano: security TF
should be discussing it, this is a lifecycle topic, belongs into
architecture
… also the case for scripting, we define lifecycle
APIs, there are some dependencies
McCool: lifecycle has more than security, we can focus the security document on security
Cristiano: agree, after that we can talk with relevant TFs
Kaz: target scope could be kind of broader, lifecycle?
McCool: I want to
consult with security experts, we have onboarding, TLS,
provisioning of keys and management
… lifecycle is more than just
provisioning
<citrullin_> +1 on having it in the relevant documents and the provisiong in security task force + security documents.
McCool: details are handled in other documents, architecture has high level requirements
citrullin_:
Discovery
McCool: Important
topics are integrity protection, this is one of the motivations for
a new discovery spec
… we also lack a common query mechanism, JSON Path
was not ready yet
… geolocation is another big topic
… JSONPath does not include scripting - we can't
call a function
… arbitrary filters could be added
Lagally: question about
geolocation
… a bit concerned
… in the past, we had some initial
proposal
… but we failed to included the detail so
far
McCool: right
… so there are 2 parts
<cris> +1
McCool: don't think it
belongs to the WoT Profile
… need to resolve that, though
… will put together relatively concrete
proposal
… to clarify the complicated situation
… there is simply geolocation, e.g.,
latitude
… simple geolocation like that within TD can be a
good starting point
McCool: handle
geolocation separately from the current WoT Profile would be
better
… that would make the current spec move
smoother
Lagally: +1
Ege: There are
different ways to do it - there's already existing vocabulary, so
we did not want to define a new one
… the question of a profile is which to
pick
McCool: profile uses schema.org
Kaz: for today's
discussion and other pre-meeting and post-meeting - what level of
details can we cover?
… or just do a brainstorming?
McCool: want to get feedback on the concrete proposals
Kaz: for today and
tomorrow suggest we do brainstorming
… we should use an approach with several
steps
… suggest we do brainstorming offline
Lagally: as we know
from the previous conversations there is some overlap work with the
current charter Profile work
… however there are several other use cases that we
should cover in the next work items
… like a Cloud Profile
… events compatible with a cloud
deployment
… a profile for constraint devices
… or for a specific protocol
<citrullin_> +1 on constrained devices and CoAP :)
Lagally: we may support other profiles provided that there is interest
McCool: it would be nice to have a short description next to the new proposed profiles.
Lagally: behavior description is interesting but it is something for TD 2.0
McCool: right
Ege: I advice to go
directly for 2.0 version for the next profile spec (no backward
compatibility)
… regarding on the proposed profiles
… I don't know we have the bandwidth
Lagally: regarding the
backwards compatibility I don't completely agree. if we break
backward compatibility it means that we are not interoperable with
ourselves
… missing the main goal of profiles
… we should watch implementers and decide
later
Ege: later it is a problem
<Zakim> mlagally, you wanted to react to Ege
Lagally: it also depends on TD. If we have TD 2.0 then we have profile 2.0
Ege: moreover, profiles
can have their own versioning number
… do you plan to have one single version number or
one for each profile
McCool: I think this is
a long discussion
… we should talk about it in the issues
Kaz: I agree about the importance of interoperability, however as today I am not sure that Profiles are the answer.
<Mizushima> +1 kaz
Kaz: paraphs we can use
implementation guidelines to ensure interoperability.
… like HTML5
McCool: I agree with
scribenick: kaz, profiles are not clear to what they are applying
for
… that needs to be resolved
… the whole versioning problem of profiles is
already warning
… cause each individual profile might have a new
version that might not be compatible with the previous
one
… I think we should discuss internally in the
profile calls
Lagally: I agree
Other deliverables
Thing Description
McCool: there are some
labels referring issues that are moved to the next version
… the TD group needs to choose a subset of imporant
issues that should be solved in the next charter.
… there is some action issues that might be
migrated to profiles
… in terms of security my personal take is to move
those outside the main spec to be more modular
… we don't have time to go through every single
issue
… we need to get a first draft done during
tpac
Architecture
McCool: I have found
only one issue label next
… I assume the labelling process is yet to be
done
… I think we need probably start the
process
… and pull up the important ones and create the
important one
Lagally: I can review
the labels offline
… for what I see so far
… the only relevant issues are identities and
onboarding.
McCool: we'll need to update the architecture to reflect changes with TD
scripting api
McCool: we have a call tomorrow
accessibility
McCool: we have a call right now
Informative documents
McCool: probably Use
cases will need some updates
… also a new normative document for
Security
Lagally: do these new Security assertions work with TD 1.1 or 2.0
McCool: I think something will impact older specifications
<kaz> akc k
Kaz: some suggestions. We talked about new additional technical topics, we should start thinking some offloading and focusing on standardization gaps
McCool: still there some technical gaps that we need to cover
Kaz: My smart city session might be the right place to start the collaboration
Lagally: it is true
that individual companies are working on proprietary Digitial Twin
software.
… but their implementations are different from open
source solutions
Lagally: ... these are not SDOs however
<kaz> Kaz: right, but I'd suggest we include "de-facto" kind of vendors as well for our liaison targets :)
APA
Janina: I would start from Jason, we have additional feedback about how a today's consumer would like to interact with products
Jason: I think the
question that we arrived was related to the conditions that should
be satisfied for WoT devices to be accessibile.
… through his life cycle (starting from the
installation)
… what we discussed was the need of some kind of
integrated approach for devices installed to some user
environments
… there is no document or requirement
analysis
… that describe the whole process
Janina: I will give
some examples of bad design choices
… Philip hue are very well designed
… but there is the hub that needs to
configured
… google invested a lot in
accessibility
… I had a nest HVAC that got disconnected and I
wasn't able to make it reconnect easily.
… another example is Amazon light bulp
… the middleware was not accessible at
all
McCool: we have use
case and requirements document
… we can your use cases there
… it will help use guide the
requirements
… the funny thing about the thing you mentioned is
the physical interface of the device
… right now we focused only on the network
api
… more the digital facing side
… on digital twins discussion we talk about the
ability to describe physical consequences of actions in the
device
… there are various things that we can do for
improving user interaction with devices
… giving the fact that we can provide textual
description in TDs
… do we have the right strings?
… right now we have title and
description
… the title is very clear
… the description is vague
… is it for developers or users ?
<citrullin_> Wouldn't it have been even more easily if you can trigger a reboot via some communication protocol? Wireless or wired, doesn't matter. Just some UI button or something. On the phone or web. And for the battery, of course the battery status, plus description, visually and text, how to change it. Wouldn't that be more like a guideline topic? What do consider when designing WoT devices.
McCool: it is a kind of physical problem
Janina: I found written
descriptions
… but just fiddling around it I could find
it
McCool: we have links that can point to documentation
<Zakim> McCool, you wanted to react to citrullin_
Kaz: thank you for your
feedback
… this is a great opportunity to put accessibility
on topic for WoT
… I'd like to discuss more in the next
charter
… those are just some examples but we should work
more on the topic
<citrullin_> +1 on collecting accessible topics and maybe having a guideline document for it?
Kaz: how wot can help people resolve this problem?
Jason: many settings
that are well represented in the hardware control but not on the
network interface
… it is also a matter of how well the human
interface is represented in network interface
<citrullin_> +1 for physical feedback etc. A lot to think about.
cris: There is a
project working on phisical consequences of interacting with
digital devices
… we are having a meeting with them in
CG
… also Solidity has keywords for documentation
targeted to devs or to end users
Janina: we can define
dedicated words for different descriptions types
… for example we defined a set of terms for
different use cases
<citrullin_> +1 on this. This should all be in the guideline spec.
<Zakim> janina, you wanted to ask about API including reboot
Janina: also defining guidelines can help
McCool: I agree that we
need a dedicated word for developer documentation
… another thing is IoT deployment
… like the minimal functionality guarded when there
is no network
… we can attach additional metadata
… but again we should start from use
cases
Kaz: I agree
… I suggest to include some additional topics in to
the use case templates. Probably we need to think about several
layers including UI, network, device, etc., as the basic mechanism
for the WoT systems as well.
next steps
McCool: we talked about
use case and requirements
… start from the repo wot-usecases
… we should plan to have a few rounds of
ideas
<mlagally> https://
<McCool> https://
Lagally: start from use-case-template.md
<mlagally>
https://
<mlagally>
https://
Lagally: using .html is fine too but md is more convinient; we can convert it later
<mlagally> Examples:
https://
McCool: use cases are
published as note
… our current document is an ongoing
process
… there is some use case that need some more
work
… there is a lot todo, we didn't capture voice
interfaces
… a lot of IoT systems are using Voice
assistance
… there are some other options like WebThing hub,
like home assistant
… it is an interesting option I am working of an
integration with HomeAssistant.
Janina: very good
McCool: a lot of this
is about let user use standard
… who do we want to invite to the
party
… home IoT is the major use case for
accessibility
… even smart things have internet
requirement
… there is no real way to identify if a device
requires a remote network connection
Janina: true
McCool: we can't solve
every world problem, we should focus
… the best bet is to include accessibility
improvements to our specs
Janina: I agree
McCool: we should identify places were we can improve
Jason: yes we can do it. we have already a lot of work to do it might take a little while
McCool: you can even improve existing usecase
<Zakim> McCool, you wanted to react to McCool
Kaz: I agree, with the
direction
… FYI, I'm organizing a w3c workshop on smart
agent, and the topics for that workshop should include
"accessibility for IoT purposes" as well :)
McCool: aob?
Janina: no
Jason: not really, we just need to work on use cases starting from the acquisition phase.
McCool: we have lifecycle on the table
<citrullin_> In long term, wouldn't it make sense to have Profiles for certain devices that are especially designed for certain accesibility? And regarding companies. There are companies that build devices for this market. Should we reach out to them? Can you maybe provide a list of hardware companies?
<citrullin_> as text ^
Janina: maybe,
accessibility is not just one market
… there is fragmentation
… probably there is some market in the aging
community
<citrullin_> fair enough. Thanks
Kaz: agree, I don't
think accessibility should be implemented via specific
profile
… all WoT systems should be accessible
… like browsers nowadays
Lagally: I agree
… just remember that we don't have a consensus
about description and title
David: I loved the
conversation
… we have a company there (connexus) that knows a
lot about accessibility and IoT
… cutting edge AI system
… we are pushing these guys to join w3c
wrap up
McCool: meet again
tomorrow
… discussion about deliverables
… scripting will present next todo items
<kaz> [adjourned]