- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Thu, 16 Jul 2020 09:44:44 +0900
- To: public-wot-ig@w3.org, public-wot-wg@w3.org
available at:
https://www.w3.org/2020/06/22-26-wot-vf2f-minutes.html
also available as text below.
Thanks a lot for all the scribes, the prsenters and the Chairs!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT-IG/WG - Virtual F2F meeting
22-26 Jun 2020
[2]Agenda
[2] https://www.w3.org/WoT/IG/wiki/F2F_meeting_2020_2nd#WoT_F2F_Agenda
Contents
* [3]Day 1
1. [4]Opening and Quick updates
1. [5]Scribes
2. [6]Agenda
3. [7]Opening Session
2. [8]Security
1. [9]Signing TDs
2. [10]Decentralized identifiers
3. [11]OAuth2
4. [12]End-to-End security
5. [13]Other key open issues
3. [14]Discovery
1. [15]Requirements and Design decisions - Michael
McCool
1. [16]Discovery requirements
2. [17]Key design decisions
3. [18]Privacy issues
4. [19]Introduction
5. [20]Exploration
6. [21]Key issues
2. [22]LinkSmart directory service update - Farshid
Tavakolizadeh
3. [23]Verifiable Credntials in IoT Services - Nikos
Fotiou
* [24]Day 2
1. [25]Scribe
2. [26]PoC Projects
3. [27]PlugFest
4. [28]Note on where to put the sides for the vF2F
5. [29]Scripting
6. [30]Binding Template
7. [31]Logistics for tomorrow
8. [32]AOB?
* [33]Day 3
1. [34]Agenda
2. [35]Use Case questionnaire
3. [36]Questionnaire
4. [37]WoT Profiles
5. [38]Lifecycle
6. [39]Tomorrow
* [40]Day 4
1. [41]Scribes
2. [42]Presentations
3. [43]Use Case Prioritization
4. [44]Prioritization questionnaire results
5. [45]Requirements
* [46]Day 5
1. [47]Scribes
2. [48]TD
1. [49]Editorial bugs
2. [50]URI Variables
3. [51]readmultipleproperties
4. [52]Issue #913 Improve text on Action parameters
5. [53]definition and $ref
3. [54]Marketing
4. [55]Wrap-up and Closing
* Summary of Action Items
* Summary of Resolutions
1. [56]Pull request to remove comma to be merged into
latest Editor's Draft. The comma is banished. Should
create Errata document to note bug fixes. Daniel will
create separate issue to remove comma in
Recommendation, with a label to note editorial change.
2. [57]We will merge this PR.
__________________________________________________________
Day 1
Attendees
Present
Kaz_Ashimura, Ari_Keranen, Cristinao_Aguzzi,
Ben_Francis, Dmitrij_Lagutin, Farshid_Tavakolizadeh,
Ege_Korkan, Michael_McCool, Dave_Raggett,
Kunihiko_Toumura, Tomoaki_Mizushima, Jaime_Jimenez,
Michael_Koster, Nikos_Fotiou, Ryuichi_Matsukura,
Christian_Glomb
Regrets
David_Ezell
Chair
McCool
Scribe
Lagally, Farshid, Kaz
[58]Agenda
[58] https://www.w3.org/WoT/IG/wiki/F2F_meeting_2020_2nd#WoT_F2F_Agenda
[59]Presentations
[59] https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-06-online-f2f
Opening and Quick updates
* Scribes
<kaz> 1. Lagally
<kaz> 2. Farshid
<kaz> 3. Kaz
* Agenda
<inserted> scribenick: mlagally
McCool walks through the agenda, some small tweaks for
gathering, breaks
<McCool> agenda:
[60]https://www.w3.org/WoT/IG/wiki/F2F_meeting_2020_2nd#WoT_F2F
_Agenda
[60] https://www.w3.org/WoT/IG/wiki/F2F_meeting_2020_2nd#WoT_F2F_Agenda
McCool: let's use the IRC channel for chat, not the WebEx chat
* Opening Session
[61]Opening slides
[61] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-22-F2F-Opening-McCool.pdf
McCool: any guests?
... any non W3C members?
<kaz> Dmitrij Lagutin from Aarto University is a guest for
today
McCool: please respect W3C patent policy
<kaz> [62]W3C PP
[62] https://www.w3.org/Consortium/Patent-Policy-20170801/
McCool: Dmitrij Lagutin is a guest, his University is a member
<kaz> Nikos Fotiou from AUEB as well
McCool: all, to simplify management, please give full names
when you join WebEx on future calls
... Logistics: There's a github site with all presentations
... please put your presentation material to it
<McCool> presentations:
[63]https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-0
6-online-f2f
[63] https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-06-online-f2f
<inserted> scribenick: kaz
Lagally: use cases questionnaire ongoing
<McCool> [64]use case priority questionnaire
[64] https://www.w3.org/2002/09/wbs/1/wot-uc-priority-202005/
Lagally: there are 15 questions in the questionnaire
... options on "not interested", "useful, but not business
relevant", "business relevant", "business critical"
... last one (q18: category 17) is proposal for a new possible
use case
... if you have any other ideas for which WoT to be applied,
please put them
... in terms of the deadline, we'll discuss the results on
Thursday during the vF2F
... so please respond by then
<inserted> mm: note that Kaz reported a bug with the TD
Recommendation, but the detail to be discussed during the TD
session.
Security
scribenick: mlagally
[65]Security slides
[65] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-22-Security-McCool.pdf
McCool: we'll talk about Discovery later today after the break
... There was related work in "Lifecycle" and "Use cases"
... DID's will be discussed in depth in discovery
... OAuth2 work is still in progress
... Lfieycle has been discussed extensively, identifier
management is an important topic there
... in architecture there were discussions about agents and
stakeholders, we also used certain terms in security, need to
move over to architecture
... not all use cases have security and privacy considerations
yet, please make sure to include these when creating a new use
case
... "none" is a possible answer, if no security requirements
* Signing TDs
McCool: consider a compromised directory service that has
malicious links
... harvests password, e.g. for basic auth
... TLS credentials could help, however changed URLs could
still be used
... need to prevent modifications of TDs, e.g. prevent adding a
proxy
... need to enforce integrity
... ID could contain a hash on the contents of the TD
... alternative way: adding a proof section
... in 1st case a TD change modifies the id
... in 2nd case a proof needs to be regenerated on every change
<inserted> scribenick: kaz
Lagally: in general, many use cases assume TDs are static
... some kind of proof section may be useful
McCool: we'll have to calculate the proof again if the TD is
regenerated
Lagally: actual signature should be validated
... don't see how that kind of validation would fit for dynamic
TDs
McCool: directory should be aware of changes of TDs
<inserted> scribenick: mlagally
McCool: updating TDs is complicated, implications on caching,
...
... this has implicatinos and TDs and architecture
Daniel: in other standards they define canonical XMLs,
identifying what can/cannot be changed
McCool: good point, e.g. a directory could add semantic
annotations
Ben: there seem some assumptions in this requirement
... 2 use cases, device or gateway serves TDs
... in these cases signing is not required, since you use TLS
... This seems to be tied to a directory
McCool: the issue arises if you redestribute somebody elses TD
... federated directories (e.g. campus use case) and
redistribution use cases
... also comes up for sleeping devices
Kaz: suggest we think about dedicated use cases for further
discussion
... multimodal integration use cases, IP addresses and ids
could be integrated, need to define a scenario
McCool: we should create issues in the use case session, let's
discuss on Thursday
* Decentralized identifiers
McCool: 3 key applications:DIDs as IDs for TDs
... use DID document as one way for discovery
... we need to formalize types for DIDs, e.g. for discovery
... 3. Key distribution: public keys with referenceable URLs
Lagally: additional stakeholders need to be considered in
architecture for this approach
McCool: there's good material in the DID draft document
... DIDs are not done yet, we need to discuss some aspects
* OAuth2
McCool: we had several flows but removed some of them, only
code flow remained
... which Oauth2 flows are required in terms of use cases. Do
we want to include all flows?
... scopes are pretty useful for smart cities, i.e. having a
separate credential system
... Oauth2 depens on Bearer Tokens, in theory all Oauth2 flows
would be supported
... There's also a device flow, we may want to include it. We
need to clarify the "user agent" can also be a simple button on
a device, or a redirect
Ege: user agent could be important
McCool: human interaction is not required, could be machine to
machine
Farshid: multiple flow support is important, it is not clear
who is involved
McCool: different interactions can have different security
schemes
... need to see which flow to use depends on the context
... code flow is not appropriate for some
Christiano: code flow is constrained not only to user agent but
also resource owner
... primarily human users
... critical is to know who is the resource owner
McCool: need to define stakeholders, differentiate between
humans and others
... it is easy to add all of Oauth2 to the TD
... since we are descriptive we should not be constraining what
we can describe
scribenick: kaz
Lagally: concur with your view
... it is important to crate user agent for generic purposes,
and that reminded me of the TD profile discussion
... what is needed for wide interoperability
... further discussion later this week during the profile
session
scribenick: mlagally
McCool: OpenAPI includes all Oauth2 flows, we need to be able
to answer why we exlude some.
* End-to-End security
McCool: New text in Security and Prvacy guidelines around E2E
security
... E2E concept is very vague, i.e. who is the end consumer
... need to specify the endpoints in the requirements and use
cases
... this leads to various issues with "bridges" in the
architecture
... how to ensure the bridge is trusted
... may need to unpack/modify TDs, perhaps this is permitted
but no payload manipulation
<FarshidT> I will take over as scribe after this presentation.
oliver: need to consider more details about who is the "end"
component
* Other key open issues
McCool: Review Conexxus Security and Privacy model, they have a
threat model we want to consider/align with. Waiting for a
document for review.
... Security review of lifecycle, need to review the final
lifecycle modle
<kaz> [break till 15mins past the hour]
Discovery
scribenick: FarshidT
[66]Discovery slides
[66] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-22-Discovery-McCool.pdf
* Requirements and Design decisions - Michael McCool
McCool: will talk about requirements, design decisions,
two-phase arch., key issues. More details about some topics
will be covered in Farshid's presentation
- Discovery requirements
McCool: support for remote discovery is necessary
... semantic querying should be supported minimally at least,
since we have linked data
... support large repos of things, and p2p (self-identying)
discovery
... privacy is a big requirements. Need to ensure user privacy.
Distribute TDs only to authenticated and authorized users.
... allow change of IDs
... Align with existing standards to avoid reinventing the
wheel
... also, align with WoT scripting API
... link to file collecting requirements:
[67]https://github.com/w3c/wot-discovery/blob/master/requiremen
ts.md
[67] https://github.com/w3c/wot-discovery/blob/master/requirements.md
- Key design decisions
<inserted> [68]Design document
[68] https://github.com/w3c/wot-discovery/blob/master/design.md
McCool: only one resolution, i.e. on two-phase architecture
... introduction phase to identify exploration services,
exploration phase to get descriptions
... technologies for introduction, DHCP, DNS-SD, DID Documents,
QR codes, etc
... exploration: well known location. URL may point at the
Thing, the TD, or the directory service
... introduction should be open so it can be consumed with no
or limited access controls
... lightweight to not waste computational and networking
resources
... resist to DDoS
... exploration meta data should be returned only to authorized
users
- Privacy issues
McCool: two-phase approach not sufficient in all contexts
... depends on the design of API
... need to hide data that can be use to infer personal info
- Introduction
Lagally: need to know if the well-known is also a trusted URL
McCool: DNS may be used for spatial discovery
Lagally: need to generalize. UPnP may be used as an
introduction mechanism
... how to know if a TD is for a directory?
McCool: can add some annotation. Directory is not a physical
thing, but adding a TD is useful to describe and have a uniform
way of interacting similar to other WoT things
Ben: supports describing a directory with a TD
... if directory is a gateway, the gateway is actually a
physical thing
McCool: a gateway can support a collection of services
Lagally: do we wanna standardize the directory API?
McCool: we need to formalize the introduction phase. And also
the exploration.
Lagally: so we define actions with specific specs for
directories?
McCool: agrees
- Exploration
McCool: auth is required
... well known location to get the TD
... light query language to have parameter based filtering
... medium like jsonpath and xpath
... advanced like sparql, graphql
- Key issues
McCool: form of query, support for semantic queries
... describe directory with a TD
... TCP/HTTP baseline protocol
... partial and fragment TDs, implications for JSON-LD
... pagination
... out-of-band data such as system-generated IDs
... notifications for changes to TDs
... links to other open issues on github
Kaz: need to look into concrete use cases for those issues
* LinkSmart directory service update
<kaz> scribenick: kaz
[69]LinkSmart slides
[69] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-22-Discovery-ThingDirectory-Tavakolizadeh.pdf
Farshid: what are done so far
... (shows outline)
... current status, naming, jsonpath/xpath, drectory meta info,
paginatio, ns-sd, tds, dircory td
... [current status]
... cataloging
... DNS-SD registration
... RESTful API
... OpenAPI, TD CRUD, catalog, valiation
... [Naming]
... Thing Directory (not to be shorten as "TD" :)
... how to call it to avoid the confusion with "Thing
Description"?
... please consider it
... [JSONPath / XPath]
... filtering and attribution
<zkis> Note to self: to align with Scripting API on names
Farshid: JSON-LD response
... array of TD with original context
... value/object selection
... don't need to use huge query
... but just query on the consumer side
... JSON fragment response as an array
... pros and cons
... pros: short and expressive, passed as URL query parameters,
value selection saves both client and server resources
... cons: fragmented response are not JSON-LD compliant, schema
can get messy, no formal spec (yet)
McCool: injection attack?
... json schema round bracket means arbitrary expression
... potentially run arbitrary code
... but that's not intended here
Farshid: right
McCool: this is a prototype directory at the moment
... we should discuss what kind of query language to be used
Farshid: rith
... [directory meta attributes]
... TTL: the validity of TD, the lifetime of TD inside the
directory after registration/update/observation
... approach #1
... add "ttl" attribute to TD specs or extend the context
... read-only meta" in responses, only when requested
... digital proof insde TD based on LD-proofs
... approach #2
... add "ttl" attribute to TD
... define a second resource type
... approach #3
... new resource type for out-of-band information
... LinkSmart's choice is #1
... single resource type
... "ttl inside the TD
... if no "ttl", directory may keep forever or reect
... proof and prof chain based on LD-Proofs draft
... related issue here
... wot-discovery/issues/18, 24 and wot-security/issues/166
Ben: be cautious
... expiry for resources would be complicated
... can see in this example, different TDs have different
resources
Farshid: could see the next slide
... [pagination]
... if some TD is static, could be very long
... on the other hand, if some TDs are dynamic, could be
smaller and frequent
McCool: push update for dynamic TDs
... originally TDs are expected as static
... here issue on dynamic TDs as well
Sebastian: handshake issue as well
... something similar to CoAP transfer
... how many/how big data to be transferred?
Farshid: limit comes from the server's capability
... possible to narrow it down
McCool: technically TDs are unbound
... one transaction vs unbound ones
... complication to break syntax of LD
Ben: a directory itself has a TD
McCool: you could have a notification
... also garbage collection
Ben: it's a trade-off
McCool: a person could register a huge TD
... probably need some mechanism for flood
Zoltan: what about streaming?
Kaz: yeah, we should think about several concrete points caused
by this topic
... e..g, streaming, big data, fragments, sessions, ...
Sebastian: you already implemented pagination?
Farshid: yes
McCool: Hitachi's nodegen approach is one possible use case
Farshid: [DNS-SD type]
... LinkSmart uses _wot._tcp type
... _directory subtype
... TXT record of "version=<api-version>" "td=/td"
... version and API endpoint
McCool: we have to annotate the type using another record
Farshid: yeah
... [TD without ID]
... with TDs with ID
... PUT /td/urn:example:1234
... but with TDs without ID
... POST /td
... response location header:
urn:uuid:0ff82c68-a9dd-4342-91a9-a326b8e2d50
McCool: globally unique ID to be used here
... query for database
... matches some ID
... we can have difference between globally unique ID and
directory-wide one
Kaz: so "uuid:0ff82c68-a9dd-4342-91a9-a326b8e2d50" is generated
by the directory
Farshid: right
Kaz: not globally unique but system-wide?
Farshid: could be globally unique
... [Directory TD]
... (example TD)
... look at the scope
... OpenID approach as well
McCool: particular OAuth flow should be also considered
... should create an issue about that
... what you put into the TD and what you get from the query
Farshid: ok. note the consumer is the resource owner
... and then go into the actios here
... then tried to validate it
... is TD meant to replace the OpenAPI specs?
... possible issues
... can't define multiple different responses based on HTTP
status codes
... few ways to define the operations: HTTP methods,
interaction affordance subclasses, propertyaffordance
(readonly/writeonly)
McCool: OpenAPIs vs Thing APIs
... do we stick with the directory with Things?
... personally think using TDs would be beneficial for
recursive purposes
Sebastian: we can't replace with OpenAPI
... that's not our purpose
... TD is independent from any protocols
... another aspect is collaborative discussion with the IRTF
T2TRG
Farshid: understood
... if it's not the intention, that's fine
Ege: we use devices but many of cloud services as well
Ben: there are a lot of cases
... any kind of affordances to be used
... many cases with TDs
McCool: 2 issues
... 1. we should have discussion on the relationship with
OpenAPI
<Ege> [70]https://github.com/w3c/wot-marketing/issues/66
[70] https://github.com/w3c/wot-marketing/issues/66
McCool: 2. also we should have discussion on error codes
Zoltan: we discuss this error mapping issue during
thttps://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-o
nline-f2f/2020-06-22-DID-VC-Fotiou.pdfhe scripting calls
... agree with Ben
... we should describe error codes within the TD spec
... need some generic mechanism for error handling
... we need some work with several TFs
McCool: (time check)
... we should move forward to the DID discussion
... and continue this discussion during the TD session
Ege: note that I've submitted some idea to the OpenAPI conf
McCool: let's take a look at that tomorrow
* Verifiable Credentials in IoT Services - Nikos Fotiou
[71]VC in IoT slides
[71] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-22-DID-VC-Fotiou.pdf
Nikos: (about SOFIE)
... an EU project which enables interoperability among existing
IoT platforms
... [VC in a nutshell]
... verifiable credential is a standard way to express
credentials on the Web
... vc-data-model is a W3C REC
... [VC Structure]
... context: issuer ID, Credential (type, subject id, claims),
Proof
... digitally signed by the issuer
... [The "Sofie Credential"]
... (example VC data)
... @context has
"[72]https://mm.aueb.gr/contexts/access_control/v1"
... issuer: did:nacl:E390... as a public key
... actual credentialSubject
... id: did:nacl:A49...
... [WoT device configuration]
... hints for the enduser
... also provides information on the WoT implementation
... @context has
"[73]https://mm.aueb.gr/contexts/access_control/v1"
... securityDefinitions has
... @type: ["VerifiableCredential", "AllowedURLs"]
... [SOFIE's Identity, Authentication, and Authorization
Component]
... access control based on the VC
... HTTP request from client
... then response from the device
... and then the use has to generate the proof
... if the proof can be verified, the user can access the
device
... [SOFIE]
... links for resources
[72] https://mm.aueb.gr/contexts/access_control/v1
[73] https://mm.aueb.gr/contexts/access_control/v1
McCool: tx
... you're presenting the security scheme based on VC and DID
... replace with other security mechanism?
... don't we need other mechanisms like OAuth?
Nikos: that's possible
McCool: probably we would extend TD for this purpose
... do you looked at XPath as well?
Nikos: yes
McCool: similar issues/considerations to be applied
... how to deal with selection of devices?
... filter-based metadata in the VC would raise issue with
privacy
... possibly a PII information?
Nikos: the user can hide information if want
McCool: relationship between DID and discovery
... wondering about the DID for discovery of credential
information
Nikos: DID uses public key
... DID is included in the credential
Kaz: this example is too simple but the point is that VC is not
PII itself but a data model to provide necessary information
for each application
... and DID is the actual identifier but that is also split
from the PII
McCool: regarding the data, VC can be embedded in the DID
document?
Nikos: those are separate
McCool: tomorrow, we'll discuss PoCs, Scripting, PlugFest
reports, Binding Templates
Ben: tx for all your presentations
... interested in DNS-SD, etc.
... Mozilla also has some mechanisms for discovery
... DNS-SD, Bluetooth and Gateway
... may have a better way based on today's discussion
... could write some proposal myself
McCool: we'll continue the discussion in 2 weeks (no call next
week)
... your input would be welcome
Zoltan: regarding the order of the topics for tomorrow
... maybe better to have PoCs, PlugFest and then Scripting
McCool: will tweak the agenda
... Niko and Farshid, please send your (update) slides to me so
that we can upload them on the GitHub repo
[Day 1 adjourned]
[74]↑
__________________________________________________________
Day 2
Attendees
Present
Kaz_Ashimura, Michael_McCool, Jennifer_Lin,
Daniel_Peintner, Ege_Korkan, Dave_Raggett,
Michael_Lagally, Cristiano_Aguzzi,
Farshid_Tavakolizadeh, Kunihiko_Toumura,
Sebastian_Kaebisch, Zoltan_Kis, Tomoaki_Mizushima,
Ryuichi_Matsukura, Michael_Koster, Ken_Ogiso,
Christian_Glomb
Regrets
David_Ezell
Chair
SMcCool, Sebastian
Scribe
sebastian, Ege, kaz, dape
<McCool> agenda:
[75]https://www.w3.org/WoT/IG/wiki/F2F_meeting_2020_2nd#WoT_F2F
_Agenda
[75] https://www.w3.org/WoT/IG/wiki/F2F_meeting_2020_2nd#WoT_F2F_Agenda
Scribe
<kaz> 1. Sebastian
<kaz> 2. Ege
<kaz> 3. Daniel
<kaz> scribenick: sebastian
McCool: shows the agenda
<kaz> Agenda:
[76]https://www.w3.org/WoT/IG/wiki/F2F_meeting_2020_2nd#WoT_F2F
_Agenda
[76] https://www.w3.org/WoT/IG/wiki/F2F_meeting_2020_2nd#WoT_F2F_Agenda
PoC Projects
[77]PoC slides
[77] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-23-PoCs-McCool.pdf
Jennifer: summary Smart City use case
... apply SPOTON in that scenario
... use of AI and thermal cameras for health monitoring
... pandemic management
... it is a first use case for introduction
... there are also plans for mapping and robots usage
... we want to start small
McCool: we should update the health monitoring use case
... we want a PoC on geolocation, right?
Jennifer: not using it yet
... maybe later
McCool: we should revisite PoC plannings
Jennifer: we will add that to the use cases
McCool: Retail
... there two different busniss groups
... and collaborations such as Conexxus, Intel,...
... retail scenario: buying ice cream
... we want to demonstrate visible sensors and analytics by
EdgeX
... demonstrator shall show how simple applications can be
build
... applying WoT for metadata and using WoT API/node-wot
sebastian: where is WoT applied exactly?
McCool: device description and analytics
Kaz: is there some digital twin aspects?
McCool: edgeX tries to predict maintenance of the devices.
Lagally: some comments for digital twins: state of the device
and historian
... and you discover the behavoir of the devices
Jennifer: for what are you using digital twin?
McCool: its more a semantic simulation
... Intel has some investment in predicting maintenance
... are there other PoCs?
(no responses)
PlugFest
[78]PlugFest slides
[78] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-23-Plugfest-McCool.pdf
McCool: full week virtual plugfest via VPN, one hour day sync
meeting
... what we accomplished is to create issue tracker
MM shows slide about its home scenario setup
McCool: the VPN instance is still online?
Kaz: yes
Sebastian: how long will be the VPN available?
McCool: so far, ongoing
sebastian: cool thing to have vpn and things always online for
testing
... people can go there and test its implementation
McCool: it would be cool to have a dashboard which things are
online
Kaz: so our intention is using the AWS instance not just "for a
while" but "for some years". right?
McCool: yes, at least till the end of the charter
... shows an overview of the Things that were used in the
PlugFest
... there were things within VPN and some outside (in the
internet) such as Thing Directory
<inserted> [79]Plugfest+Outcome PlugFest Outcome issues
[79] https://github.com/w3c/wot-testing/issues?q=is:issue+is:open+label:
McCool: outcomes and issues are provided
... balabce vlaudation and experimentation, usefulness of VPN,
Xpath useful for discovery, get validation and reporting tools
ready before the plugfest, IDs needed for primary keys
Ege: we spend a lot of time about VPN, but who is depending on
that?
McCool: we should log who used the VPN
Ege: Actually I don't need that, except if there is a device in
vpn then I have to use it
... how do I know when I have to use the VPN?
support keeping VPN such as for prototypes of planned
commercial devices
scribe: supporting the idea of an dashboard
McCool: more comments about the PlugFest?
<kaz> [5min break]
Note on where to put the sides for the vF2F
<McCool>
[80]https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-0
6-online-f2f
[80] https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-06-online-f2f
<McCool> please put presentations at the above directory - I
will move the scripting pres later
Scripting
scribenick: Ege
[81]Scripting slides
[81] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-23-Scripting-Kis.pdf
Zoltan: we had busy time since March
... in ConsumedThing you can specify the form ... index
... we discussed on how to handle contentType and DataSchema
... and we added most of the algorithms
<kaz> [82]PR 207
[82] https://github.com/w3c/wot-scripting-api/pull/207
<kaz> [83]PR 203
[83] https://github.com/w3c/wot-scripting-api/pull/203
Zoltan: we have improved the error mapping
<kaz> [84]PR 209
[84] https://github.com/w3c/wot-scripting-api/pull/209
Zoltan: so how to map errors to protocols and back
<kaz> [85]PR 218
[85] https://github.com/w3c/wot-scripting-api/pull/218
<kaz> [86]PR 221
[86] https://github.com/w3c/wot-scripting-api/pull/221
<inserted> scribenick: kaz
Ege: status message also should be handled
... by the ConsumedThing
Zoltan: how to map the protocol-specific errors with JS errors
is the question
Ege: script should understand protocol specific features
Zoltan: developer could make mapping
<inserted> scribenick: Ege
Zoltan: so the mappings are more straightforward
Lagally: we discussed something similar with Sebastian and
Matthias a couple years ago
... the errors in the API should be abstracted from the
protocols
Zoltan: so we need two mappings, one in the bindings document
that maps protocol errors to a unified error list
... and another one that maps those unified error list to
JavaScript errors
<sebastian>
[87]https://github.com/w3c/wot-thing-description/issues/303
[87] https://github.com/w3c/wot-thing-description/issues/303
Sebastian: So the issue that ml described, I have pasted the
link in the IRC
... TD issue number 303
... so we can continue discussion in there
Kaz: You can share the link in IRC as well
<Ege> @mmccool, could you merge this PR:
[88]https://github.com/w3c/wot/pull/922
[88] https://github.com/w3c/wot/pull/922
<McCool> ok
<kaz> [89]Scripting.pdf fyi scripting slides (tentatively)
[89] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-23-vF2F-WoT
<kaz> [slide 3: WoT Scripting API specification updates]
Zoltan: we worked on observe and subscribe handlers
<McCool> btw I'll rename slides later to clean things up, don't
worry too much about it for now
<kaz> [90]InteractionInput and InteractionOutput, support
streams
[90] https://w3c.github.io/wot-scripting-api/#handling-interaction-data
Zoltan: and also getting values from the interaction outputs
... now we can parse to different media types
... also streams are possible
... this was a big change
Ege: handling observe and subscribe is needed if you want to
build a proxy with Scripting API so that you can dynamically
listen to observe requests from Consumers and relay it to the
actual Thing
<kaz> [slide : Opens]
<kaz> [91]Error handling (related to PR 221)
[91] https://github.com/w3c/wot-scripting-api/issues/200
<kaz> [92]Issue 219
[92] https://github.com/w3c/wot-scripting-api/issues/219
Zoltan: We have open issues, regarding readmultipleproperties
<kaz> [93]issue 912
[93] https://github.com/w3c/wot-thing-description/issues/912
Zoltan: also contentType or DataSchema but mixing them (raised
by Cristiano)
... we need to sync with the Discovery TF for the discovery API
<kaz> [94]Issue 910
[94] https://github.com/w3c/wot-thing-description/issues/910
<kaz> [95]Issue 913
[95] https://github.com/w3c/wot-thing-description/issues/913
<kaz> [96]Issue 206
[96] https://github.com/w3c/wot-thing-description/issues/206
Zoltan: We have the discovery API but it is very unspecific
... but there are already proposals like ThingFilter
McCool: so we need to generalize the ThingFilter to payloads or
URI content since both can be inputs for discovery
Daniel: the reason to not let consume() method accept a URI is
to avoid having to support multiple protocols while fetching
the TD
McCool: yes, so the consume method works without network access
Zoltan: there is also the semantic api proposal by Michael
Koster but we didn't have to explore it yet
<kaz> [97]Issue 204 - Semantic API
[97] https://github.com/w3c/wot-scripting-api/issues/204
<kaz> [slide 5: Deployment scenarios]
Zoltan: we are also discussing on how to deploy scripts
<inserted> [slide 7: Status node-wot]
Daniel: Here are some updates on node-wot
... we support HTTP, CoAP, MQTT, OPCUA, Netconf and Modbus
being planned
McCool: what about CBOR?
Daniel: We don't have support for it but they can be very
easily plugged
... you can do everything in the browser as well
... then the hands-on material was improved
McCool: I find the test thing having data types as names a bit
confusing
Daniel: we have videos for using node-wot
... Cristiano is working on OAuth2 in server side
... we have also improved the logging mechanism
... also, the new Scripting API is not yet in the master branch
Jennifer: nice to see OAuth2 and the tutorials improved
McCool: it would be nice to get some input on needed OAuth
flows
Daniel: you can also see that we have many PRs by contributors
and we are making good progress
<McCool>
[98]https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-0
6-online-f2f/2020-06_WoT-Bindings.pdf
[98] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06_WoT-Bindings.pdf
<kaz> scribenick: kaz
<inserted> [99]Browsified node-wot
[99] http://plugfest.thingweb.io/webui/
Kaz: Daniel, are you planning to use the webui version of
node-wot for the upcoming PlugFest in the future
Daniel: already using it
Kaz: would be great to have some document as well
... good starting point. thanks a lot!
[5min break]
Binding Template
scribenick: dape
[100]Binding slides
[100] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06_WoT-Bindings.pdf
<Ege> [101]Google Docs version
[101] https://docs.google.com/presentation/d/1ZhwbVQGKL5scnXWtfm_s0L1UmNjo_tQxa2YukUQ9uLA/edit?usp=sharing
Ege: [slide 2] - Protocol Vocabularies
... we have turtle files for CoAP and MQTT
... thanks to Victor
... [slide 3]
... links to rendered version
... [slide 4]
... improvements about vocabularies still needed
... [slide 5] - Interest Check
... so far we have HTTP, CoAP, MQTT.. done
... no interest on oneM2M, OCF so far
McCool: w.r.t. OCF, implementantions 1.0
<kaz> [102]Issue 1
[102] https://github.com/w3c/wot-binding-templates/issues/1
McCool: need to look at more recent versions, and security
<kaz> [103]Issue 92
[103] https://github.com/w3c/wot-binding-templates/issues/92
<Ege>
[104]https://github.com/w3c/wot-binding-templates/issues/92
[104] https://github.com/w3c/wot-binding-templates/issues/92
Ege: please comment on issue
[105]https://github.com/w3c/wot-binding-templates/issues/92 to
identify new ones
[105] https://github.com/w3c/wot-binding-templates/issues/92
McCool: suggest zeroMQ, will add it to issue
<kaz> [106]ZeroMQ
[106] https://zeromq.org/
McCool: [slide 6, 7] - Robotic Operating System (ROS)
Ege: ROS is middleware
... communicates with protocols of robot over lower level
protocols
... programming is abstract
... [slide 8]
... ROS has similar goals to the WoT
McCool: ROS has security problems
... work on ROS2 is in progress
Ege: Agree, it is 10 years old
... lot of devices out with ROS "1"
McCool: ROS2 has more industrial strength
Ege: [slide 9]
... ROS: Mixed broker and P2P communication
<kaz> [107]ROS
[107] https://www.ros.org/
Ege: can store TD
... consume them
McCool: Payload issue? Serialized with YAML?
Ege: contentType has to be specific contentType
Ege: [slide 10]
... 3rd July call, proposal shown in Binding call
McCool: Did have issues with node.js implementation
Ege: Implementation improved
... [slide 10] - Subprotocols
... [slide 11] - Server Sent Events
... serves pushes events to client/consumer
... PR for node-wot
... used in OpenHAB
... plan to look into subprotocols
... [slide 12] - bridging protocols
... MQTT over WS
... clients can used WS to talk with MQTT device
... there is also CoAP over WS
McCool: CoAP over WS mentioned by Mozilla also
... should look at there use-cases also
McCool: OpenHAB is very interesting
... PoC for OpenHAB is very valuable
Sebastian: Student of mine works on openHAB topic
McCool: OK, great. can talks about that in Plugfest call
Kaz: Question: if we want to use MQTT over WS... web browser as
possible client?
Ege: Yes. correct
Kaz: NHK uses web browser in TV set
... could be part of the future PlugFest as well
McCool: TD describable enough ?
Ege: Yes, interesting topic. will come to it later
... [slide 13]
... [slide 14] Paho in Python, reference implementation
... different to node.js implementation
... TD consumption step needs some assumption
... not sure how to describe it in href
McCool: Standardized URLs for MQTT?
Ege: There isn't
... broker URL and topic
... see issue 255 in node-wot
... assumption / best practice
<Ege>
[108]https://github.com/w3c/wot-thing-description/issues/878
[108] https://github.com/w3c/wot-thing-description/issues/878
Ege: also issue 878 in TD repo
Farshid: some pure MQTT implementation use TCP and SSL
... no mentioning of WS but TCP, SSL
... no standardized scheme
<FarshidT>
[109]https://github.com/mqtt/mqtt.github.io/wiki/URI-Scheme
[109] https://github.com/mqtt/mqtt.github.io/wiki/URI-Scheme
<Ege> Some implementations may also support the 'tcp' and 'ssl'
scheme names.
McCool: similar issue with JSON schema.. not having a standard
reference
Sebastian: we have to check MQTT standard
... many implementation out that are not following standard
<McCool>
[110]http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/csprd01/mqtt-v
3.1.1-csprd01.html
[110] http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/csprd01/mqtt-v3.1.1-csprd01.html
Sebastian: MQTT 3.1 is weak w.r.t. security
... --> different security solutions implemented but not
standardized
McCool: OASIS connection points?
... impacts our work
Ege: MQTT vocabulary needs to describe broker URI, security etc
McCool: look at *all* possible ways
... figure out how to deal with them
... maximizes interoperability
Ege: [slide 15] - Next work item
... improve protocol vocabularies
... error mapping
... node-wot has OPC-UA, NETCONF and Modbus, should they be in
binding templates
Cristiano: can help with Modbus
<McCool_> network glitch, my audio just broke :(
Cristiano: have PR on node-wot with Christian
... OPC-UA and NETCONF was done by Luca
... can ask Luca
<McCool_> (audio/irc back... network hiccup)
Sebastian: OPC-UA work should be done with OPC foundation
... possibility to have OPC-UA expert
... vocabularies should be maintaned by *owner* of protocol
Kaz: OPC-UA contact?
Sebastian: Yes
... but so far in internal process
Kaz: How many bindings templates should be added?
... can I assume OPC-UA. Modbus being added as example
Ege: Could be examples or more assertive within tables
Kaz: Echonet or Hybdridcast could be added to binding templates
also
McCool: vocabulary should be normative
... how do we get there?
... other groups are in charge
... need to work with other organizations
Kaz: agree
... can publish group note first and then transfer if needed
McCool: Yes, reach out to other organizations a well
Ege: node-wot examples could be added ...
McCool: Yes, but putting note saying it is prototype
Ege: will add to issue 92 ... OPC-UA, NETCONF and Modbus
<kaz> [111]Issue 92
[111] https://github.com/w3c/wot-binding-templates/issues/92
Ege: New protocol interest, please let me know
Kaz: will you update the slides on the GitHub repo with the
"next steps" page?
Ege: yes
McCool: 2 missing protocols: Zigbee and zwave
... not sure if feasible
Ege: Not sure if we can support them
... would open up to USB, Bluetoothm ....
McCool: Agree
Cristiano: w.r.t. ROS. I did some experiments. Difficult to
understand initial setup, topics, et cetera
Ege: Correct. WoT can help here
... direct XML RPC is possible also
... lots of extra communication is done and rather messy
McCool: ROS has formal documents
... in YAML files
... Comments/input?
Logistics for tomorrow
McCool: shall we discuss logistics for tomorrow
... Wednesday, 3 hours sessions by M. Lagally
... please upload presentation to github repo
... will do a clean-up step later
AOB?
Jennifer: client application connecting to WoT. Recommendation
to use HTTP or MQTT ?
McCool: TD is independent
... >discussion how to wrap node.js code in other languages<
Kaz: most of PF participant have been using HTTP and other
protocols are of interest
McCool: It is also a discussion about implementation language.
node.js... C++ et cetera
Kaz:there is a python implementation for WoT, WoTPy, as put on
the [112]WoT REC press release
[112] https://www.w3.org/2020/04/pressrelease-wot-rec.html
<kaz> [113]WoTPy
[113] https://github.com/agmangas/wot-py
McCool: maybe we can reach out and have 1-to-1 discussion
Ege: my contact person was not interested ;-)
<cris> [114]https://pypyjs.org/
[114] https://pypyjs.org/
McCool: will create issue about "how to support Python"
<McCool_> [115]https://github.com/w3c/wot-testing/issues/37
[115] https://github.com/w3c/wot-testing/issues/37
<kaz> [Day 2 adjourned]
[116]↑
__________________________________________________________
Day 3
Attendees
Present
Kaz_Ashimura, Michael_McCool, Farshid_Tavakolizadeh,
Jennifer_Lin, Kunihiko_Toumura, Michael_Lagally,
Daniel_Peintner, Sebastian_Kaebisch, Ege_Korkan,
Dave_Raggett, Michael_Koster, Zoltan_Kis,
Tomoaki_Mizushima, Ryuichi_Matsukura, Ken_Ogiso,
Ben_Francis, Cristiano_Aguzzi
Regrets
Chair
McCool, Sebastian
Scribe
jenlin, zkis
Agenda
scribenick: kaz
McCool: (goes through the agenda)
... profiles and lifecycle for today
... use cases, requirements tomorrow
... TD, marketing on Friday
<kaz> ... note the use case call will be held tomorrow on June
25 one hour earlier than this vF2F call
Use Case questionnaire
<McCool>
[117]https://www.w3.org/2002/09/wbs/1/wot-uc-priority-202005/
[117] https://www.w3.org/2002/09/wbs/1/wot-uc-priority-202005/
<inserted> scribenick: jenlin
mlagally: Collected 15 use cases so far
... Can people respond by the end of the day today for the Use
Case questionnaire?
<zkis> scribenick:zkis
Questionnaire
[118]questionnaire
[118] https://www.w3.org/2002/09/wbs/1/wot-uc-priority-202005/
Lagally: please fill it
WoT Profiles
[119]Profiles slides
[119] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-24-Profiles-Lagally.pdf
<mlagally__> [120]https://github.com/w3c/wot-profile
[120] https://github.com/w3c/wot-profile
Lagally: we hat a github repo
... and handle this in the Architecture task force
... presents slides
... motivation for profiles: we need out of the box
interoperability
... the TD spec it is quite elaborate and generic
... TD is very flexible and has few constraints
... we got feedback (e.g. from the W3C TAG) about
interoperability concerns
... generic TD consumer cannot be implemented, because device
implementers can pick TD features arbitrarily
... we have seen during plugfests that there are a core feature
set that works fine together
Ege: agree it's difficult to implement a generic client, but
don't think it cannot be implemented
... there some cases indeed node-wot could not implement
McCool: for instance there could be some protocols missing
Ege: still, implementable
McCool: the point is that a given client needs to implement a
compatible protocol
Lagally: for every generic client I could create a TD that
would break the client
McCool: clients could be updated with time, and the profiles
would explain the differences
Ege: (missed)
Lagally: you don't even need to go down to the protocol
Koster: there are 2 approaches: client adapts to protocol
... and to constrain the protocol choices
... it's a huge tradeoff
... we need to be careful
... everyone wants their special profile
McCool: we just want out of the box interop
Koster: tricky term
McCool: if two devices implement a profile, they should work
together
Koster: we restricted already the protocol choices
McCool: we can decide that
Lagally: we are in the middle of the profile discussion,
perhaps finish the slides first
... there are a number of ideas
... there are 2 angles to interoperability: specification
(normative guarantees)
... covering all corner cases
... this is difficult
... which is why we do reference implementation
... considering profiles to compartmentalize concerns
... second angle: reference implementation
... third angle: test suites with guaranteed coverage
... certification program
... how other specs solve this?
... selecting a target specific subset of features
... additional constraints and clarifications
... there is a common core profile
... in DVB-GEM
... it is possible to combine profiles
Zoltan: this is similar to W3C conformance classes
Lagally: will look into that
... profiles also might select various codecs etc
Koster: there could be different levels of expectations on what
interop means
Lagally: will address that later
... there are also other features a profile could select for
interop
... other example, filename requirements
... other example: clarification of behaviour
... if the API is not fully specified on that behaviour
... so it's clarification of corner cases
... Scenarios and use cases
... before buying, making sure a device would work in my
environment
... as developer, wants TDs to be simple as possible (e.g. in
constrained devices)
... as a developer, being able to validate compatibility with
consumers
Koster: let's go to the other direction: there is a whole
spectrum here, e.g. dismissing Forms
McCool: we want to limit complexity
Koster: we could probably allow more complex data structures
more easily than new protocols
McCool: most important is to make sure the devices will work
... then, secondarily it's important that I can sell a given
device for a given use case
... 2 viewpoints: end user and developer
... both need to figure out how to interop
Zoltan: were there practical hard limits on interop with the
current generic TD spec?
McCool: there may be gaps in coverage
Lagally: it is possible to implement incompatible systems
Ege: I would disagree with that
McCool: other way to do it is testing features and post
compatibility on a public site
... a consumer could figure out what works
Koster: in general, the Web doesn't have profiles
Ben: any browser can render any web page
Koster: I agree
... not every system needs to support every protocol
... where is the boundary
... for instance FTP support in browsers is not universally
needed, but might be
McCool: implementations could have extensions
... we should be able to check for features
Koster: we could allow more feature rich and less feature rich
endpoints without breaking things
... we also need to create one spec
... not like 15 specs
Ben: ad-hoc interop is impossible
Koster: in general I agree
Sebastian: ad-hoc is irrealistic
... we also need to take security in account, then there is no
ad-hoc
Lagally: if we cannot ensure out of the box interop, without
writing code, what is the purpose of the spec
Koster: yes, 2 different factors: we do make a unifying spec
... it is not the same to enable magical interop
... WoT is doing exactly the work of agreeing in a working
"profile"
Lagally: it is not "either, or"
Koster: just saying there is a lot of benefit in doing the
standard even without explicit profiles
Lagally: implementing own client is not a good requirement
Zoltan: (fill in later)
Lagally: what do we do if actions go wrong?
Zoltan: need to describe an error
<mjk> [121]https://xkcd.com/927/
[121] https://xkcd.com/927/
Kaz: if we need additional mechanisms, we should indeed add
them
... but we should look into exact use cases first
Lagally: there is a certain methodology on this in the
presentation
Ben: the profiles are needed
... without them the TD spec is open ended
... currently the TD spec does not guarantee interop
... so agree in adding profiles to add ad-hoc interop
McCool: we can't prevent people doing silly things
... but could achieve a reasonable compatibility
... we should support green field devices
... security is another aspect
... one effect of profiles is to add guaranteed support for
things
... especially regarding security
Lagally: agree that we need to limit and constrain security
options
McCool: working "well" also means "not hackable"
Koster: we're going towards interoperability
... this is a separate thread of development in the IG to
gather interested parties
Sebastian: the goal of profiles is good
... but we dismiss the legacy, and that is a real problem today
... when new devices are developed, then we can require profile
compatibility
... but we need to be careful with legacy systems
... otherwise the standard might not be accepted
... we might have too many profiles as well
... and the end is again a mess
... we should avoid that
... I think we are good about the TD and not sure profiles
solve the real problem
Lagally: agree to not create a mess of profiles
... we want to limit the number of profiles
... about brown-field devices
... if we define profiles so that 80% of legacy features are
supported, it should be good enough
... that would be enough for spec adoption
Dave: I like the points brought for profiles (working features)
... the actual technical requirements don't require a very wide
support for things
... for instance image formats in the web are just a few
<dsr_> Profiles are also important for discovery - client apps
need to limit discovery to things they can actually
interoperate with
Kaz: repeating the point of looking into the existing scenarios
... also work together with the other standardization bodies
and align with their views
... if there is actual need of extensions for the TD that
require profiles, we should go for it
Lagally: yes, we started doing that
... with ITU-T and OCF for instance
... please respond to the questionnaire and specify what is
needed
Sebastian: still don't get the real issue here
... one thing is what do we miss in the TD spec
... then, what is the client doing with profiles?
... let's compare with web pages
... the question is what the client is doing with the page
source
... it will do what it supports
Lagally: let's move on with explaining the proposal and then
will tackle that
<mjk> my comment to the irc: profiles already exist. There is a
profile for OCF, a profile for OMA LWM2M, etc. that are
candidates for a standard profile
Lagally: profiles are widely used elsewhere as well, with
similar motivation
... continuing with use cases for profiles
... digital twins
... with tens and hundreds of device types
... we want to have a model of these devices
... just a TD would not be enough to cover implementation
environment constraints
... if additional code is required, then it's not going to be
used
... TDs should be consistent and complete
... then, interop between multiple vendors and protocols
... there might be differences in content format
... there could be many restrictions
... consumers should be aware of these restrictions
... imposed by the protocols
Kaz: we should see the difference between the requirements for
profiles and the ones for Binding Templates
... so we should clarify the requirements for the profiles here
Lagally: to give more context on proposed requirements
... would defer that discussion until the next Architecture
call
... profiles should have a finite set of features and
capabilities to be implemented by the consumer
... Check out the current Profile draft
<kaz> [122]strawman draft for WoT Profile
[122] https://w3c.github.io/wot-profile/
Lagally: profiles should not define new features, just
constrain and clarify existing ones
... how to describe a profile: we need a generic profile
mechanism
... we need a core profile, coming from plugfest experiences
... the intention is to formalize these experiences
... to document what has been working and what not
... profiling mechanism
... constraints on: TD vocabulary, mandatory terms, limit
cardinality
... constraints on values, data schemas, security
Zoltan: what is missing from the current TD spec to express all
these constraints?
Lagally: we can see a couple of examples
... for instance when TDs don't actually define those
constraints
... will show examples later
McCool: we agree a profile is a set of constraints
... the question is how to organize these
... we need to gather the constraints that are necessary and
optional
Ben: agree that these activities should be focused
... e.g. infinite nested objects are a problem
... constraining the protocols would be most important
... because that is not easy to handle from the client
Kaz: these constraints might be valid for the Binding Templates
as well
... we need to think on how to deal with these requirements
<McCool> (I also agree with ben that protocols should be on
this list of contraints - I assumed it was just an oversight
when the slide was built, though, since I beleive those
constraints are in the strawman)
Lagally: agree
<McCool> (also content formats, eg. for data payloads, probably
also need to be constrained)
Sebastian: this reminds me of what Escher IoT are doing
<mjk> The Azure thing is Digital Twin Description Language
(DTDL)
Ben: indeed there is overlap between profiles, templates, ...
Lagally: in templates we don't talk about protocols, only about
the data model
... on devices that implement the same templates, the model is
the same, but there could be different protocol bindings
Koster: a lot of open-ended discussion, but got a good picture
on what needs to be constrained
... OCF has a similar mechanism and MQTT as well
... the set of constraints are pretty well defined in the
protocols
Lagally: presenting core profile
... constraint on the protocol binding is that default binding
is HTTPS
... predefined mapping of HTTP verbs to WoT interactions
... only a single Form per interaction
... constrained set of data types (e.g. no arrays of arrays)
... profile status: last year a strawman proposal was made
... architecture TF focused on lifecycle
McCool: want to open a discussion about logistics
... how exactly should we proceed with profiles
Lagally: let's finish the presentation first
McCool: do we start with a strawman and improve later, or do we
want more preparation
Ben: there is a list of proposed and accepted requirements
... need to agree on the accepted requirements
Lagally: certainly, please participate in that discussion
... presenting the profiles github repository
... and the strawman proposal
<kaz> [123]strawman draft for WoT Profile
[123] https://w3c.github.io/wot-profile/
McCool: the structure is reasonable
... there are some issues
... we need to create better requirements and then modify it
with a set of PRs
... and document things in issues
Ben: will try to write a draft for requirements on what's
needed
... one is what operations to define by default
... TD spec, Bindings and Profile spec tries to do this as well
... so where should this live
Lagally: good point
... the Profile spec is not to define things, just to reference
them
Ben: a client really needs to know what ops and details they
have
Koster: both LwM2M and OCF have profile-like constraints
... it should be checked
Lagally: we could discuss that in an upcoming Architecture call
Koster: OCF could be easy to map to HTTP - given security
details are sorted out
McCool: we can figure out later if profiles vs bindings need to
address constraints
... the question is figuring out the next steps
... is it in the architecture calls?
Lagally: yes, the next Architecture calls
... please take a look at the profile issues
... create new issues
<benfrancis> Clarification for the minutes: The requirements
document I mentioned writing was for the Web Thing Protocol
Community Group, not WoT profiles as I want to make sure all
the WoT specifications do not conflict with each other.
<benfrancis> The comment about ops was that defining default
HTTP methods for operations is only part of what is needed by a
client - also need to define headers, payloads, response codes,
error conditions etc. Perhaps the Profile could go further than
the TD and Protocol Bindings specification in defining those,
or constrain TDs to a particular sub-protocol
<benfrancis> which defines them.
Lagally: review the strawman proposal
<kaz> [124]wot-profile issues
[124] https://github.com/w3c/wot-profile/issues
McCool: we have 2 architecture calls, needs some alignment
Lagally: we can have that conversation later
McCool: break time
<kaz> [resume in 6 mins]
Lifecycle
<kaz> scribenick: jenlin
[125]Lifecycle slides
[125] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-24-Lifecycle-Kis-Lagally.pdf
Michael_Lagally: Presenting WoT Lifecycle
Lagally: Goals: Describe the operational lifecycle model across
different standards, Align terminiology, Identify impact and
requirements
... Mentions Zoltan did a lot of work on tStatus for lifecycle
... Draft of Layered lifecycle diagram
... Lifecycle Specification draft
McCool: One thing we used in security documents is to define
the scope in our scecurity documents
... Since we have two operational substates
... We also have maintenance states like discovery and
registration
... Each spec writer needs to make sure each spec says what it
needs to say for lifecycle
... Device lifecycle
Lagally: System lifecycle mentioned too
... Thing lifecycle
... Onboarding and offboarding of device lifecycle to consumers
McCool: Things should be cover in discovery lifecycle like time
to live
... The point is discovery can go both directions -- discover a
directory and register
Zoltan: Want to specify similar things for smart group -- we're
putting together a lot of things in the beginning that should
probably be separate
... Discovery for onboarding different from discovery in
operational mode
... There are protocol things specific to take into account for
lifecycle, so it's difficult to standardize behavior and may
require different network equipment
... What do we want to represent in lifecycle?
... We want to represent state and transitions and operational
mode and onboarding discovery
... This is tricky, the lifecycle discussion, since it's all
about specifics
Lagally: I agree, but we're going to look at high level
architecture with consumer and intermediaries
Kaz: Two comments: We should think about the relationship
between application and session lifecycle
... Also should think about lifecycle in an abstract layer for
error handling -- for example, if some state transition like
onboarding has failed, that could be an error for all the
possible protocols used by the connected devices
... Concrete errors for each potocol could be mapped with that
abstract error
Lagally: Runtime layer on top of devices where we don't have to
look into the state machines of protocols but have an abstract
layer on top
Kaz: We don't have to think about the detail of the hardware
layer or the network layer, but can concentrate on the
application layer, though
McCool: Wonder if lifecycle is what we should define it as
first
... There's additional components we may need like a separate
service that runs a component
... Take our patterns and think of them as components
... Then we can think about lifecycle and onboarding
Lagally: One new component is the directory and discovery
service
McCool: OCF is an onboarding service that discovers devices and
onboards them
... Does what it needs to do to find devices then registers it
Lagally: I'm wondering if these bridges or gateways are
intermediaries
... Let's call it protocol gateway at the moment
McCool: Second category is a bridge
... Whatever, we need two different words
Lagally: Gateway is just a 1-1 protocol translator/convertor
McCool: First category is a servient
... Second category is not
<Zakim> zkis, you wanted to explain system lifecycle
Zoltan: In architecture we need to specify what nodes we have
... When we have a thing directory, how a consumer knows it's a
TD, it has to know its URL
... Should be able to define a TD in wot interactions
McCool: Having a lifecycle for TDs is very interesting
... Since we need to know when it is updated
... Lots of questions of TD lifecycle
<McCool> my previous points: maybe we should think about the TD
lifecycle
<McCool> so I think there are use cases where TDs need to be
updated, if not very frequently, even without "dynamic"
hypermedia/resources creation
<McCool> e.g., IDs can be rotated, IPs can change...
scribenick: kaz
Lagally: (shows system state diagram)
... let's use the next architecture call in 2 weeks for the
following discussion
Tomorrow
McCool: we'll discuss use cases and requirements tomorrow
... also there will be the use cases call tomorrow one hour
earlier
Lagally: will create an issue, and we'll continue the
discussion on lifecycle during the architecture call in 2 weeks
[Day 3 adjourned]
[126]↑
__________________________________________________________
Day 4
Attendees
Present
Kaz_Ashimura, Hiroki_Endo, Jennifer_Lin, Josh_O_Connor,
Michael_Lagally, Michael_McCool, Ben_Francis,
Daniel_Peintner, Farshid_Tavakolizadeh, Michael_Koster,
Cristiano_Aguzzi, Ege_Korkan, Joshue108,
Tomoaki_Mizushima, Ken_Ogiso, Kunihiko_Toumura,
Ryuichi_Matsukura, Sebastian_Kaebisch
Regrets
David_Ezell
Chair
McCool, Sebastian
Scribe
Jennifer, Daniel, Farshid
Scribes
<kaz> Agenda:
[127]https://www.w3.org/WoT/IG/wiki/F2F_meeting_2020_2nd#WoT_F2
F_Agenda
[127] https://www.w3.org/WoT/IG/wiki/F2F_meeting_2020_2nd#WoT_F2F_Agenda
<kaz> 1. Jennifer
<kaz> 2. Daniel
<kaz> 3. Farshid
Presentations
<kaz> [128]Presentations area
[128] https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-06-online-f2f
<inserted> scribenick: jenlin
McCool: Double-check the name of your presentation
Use Case Prioritization
[129]Slides on Use Cases and Requirements
[129] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-25-Usecases-Requirements-Lagally.pdf
Lagally: Cancelled earlier Use Case call due to low attendance,
merging with this call
... Almost 2 hours for Use Case results
... More of a discussion today rather than presentation on the
Architecture Use Cases & Requirements
... Questionnaire results
... Use cases ~ 20 proposed in the architecture group
... Mentions active contributors of Use Cases
... Also target domains
... Work split: Architecture and Use Case Task Force
... Capture new use cases, open to all IG members, community,
and guests
... All use case related issues moved over to new repo
<kaz> [130]wot-usecases repo
[130] https://github.com/w3c/wot-usecases
<kaz> [131]old USE-CASES area from the wot-architecture repo
[131] https://github.com/w3c/wot-architecture/tree/master/USE-CASES
Lagally: folder called Contributions for new use cases
<kaz> [132]use case template
[132] https://github.com/w3c/wot-usecases/blob/master/CONTRIBUTIONS/use-case-template.md
McCool: Subdirectory is old use case template, top level is new
Lagally: Will fix after call
<kaz> [133]initial use case draft
[133] https://w3c.github.io/wot-usecases/
McCool: This is an informative document (use cases) and there
will be no royalty commitment required
Lagally: There is an "Issues" tab and structure things separate
<kaz> [134]wot-usecases issues transferred from
wot-architecture repo
[134] https://github.com/w3c/wot-usecases/issues
Lagally: Architecture Discussion Process diagram
... Use Case Shortlisting
... Want to make sure Use Cases coming from different sources
have business interests
... And real market needs
... Want to make sure to focus on the important/priority use
cases
McCool: 40% of use cases involves orchestration of devices from
market
... how do you account economic activity?
Koster: owe you a use case based from market need
McCool: agree with basic point to need to figure out advantage
Koster: Capabilities model
Lagally: will have another use case meeting, ask mk to join
Koster: dog upset by fireworks
Lagally: Questionnaire results
Koster: Will try to make regular call
Kaz: what about inviting Koster to the architecture call?
Lagally: good idea
<kaz> architecture calls are 11pm and 8am in PDT
Prioritization questionnaire results
[135]Slides on Use Cases and Requirements
[135] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-25-Usecases-Requirements-Lagally.pdf
Lagally: Put together the results as of 25.6 @ noon
... have not received responses on all the use cases
... business relevant responses are higher than business
critical
<kaz> [136]questionnaire results (member-only)
[136] https://www.w3.org/2002/09/wbs/1/wot-uc-priority-202005/results
Lagally: anyone not a W3C member?
Josh: part of the W3C Team
Lagally: Ogiso-san a W3C member?
Kaz: yes.
Lagally: Lots of written feedback to look into
McCool: This questionnaire is very flat.
... I marked a lot of things as business critical
... What's missing is to rank the use cases
... Need to do trade-offs between use cases
Lagally: Right. Will get to it in the second half of the call.
Will assign rank.
... Need to do weighted results, inventing a formula.
... Weighted Results, e.g., business critical=6; business
relevant=3; useful=1
... This is not final
... What people are interested in the most
... representing the members of the group
McCool: This metric ranks things higher even though there are
other things that are business critical
... While this is helpful, a more direct question about ranking
will be helpful
Kaz: Similar to McCool. The result of direct question might be
the same as the results of this formula, but if some use case
is very important for a company, it should be handled and
included in the final proposal
... probably, we can categorize all the proposed use cases into
3 categories, critical, relevant and useful, and then which use
cases would be handled by whom
Lagally: identify what needs to happen if we dig deeper in
requirements
... identify people who say this is important enough for me
that would be willing to contribute their expertise and
anaylsis in the existing spec
... look at examples as well
... who would be willing to do something here
... using numbers for trends
... And stakeholders
Josh: Weighting accessibility of the current model/business --
I don't think this reflects the importants of accessibility in
all the use cases
... be careful about drawing conclusions based on these numbers
... it's hard to find business cases for accessiblity in WoT
... demonstrate lack of tangable cases of accessibility in this
business space
Lagally: thank you, taking notes
McCool: accessibility and other horizontal things might confuse
the picture
<Joshue108> +1 to MMcCool
McCool: should look at the importantance of difference
technologies over horizontals
... categorize and sort into buckets
... accessibilty should be in the same category of security and
privacy
<Joshue108> +1 to MMcCool again
McCool: considered for every use case
... some of these are tricky, like audio/video
... vendor/system integration is also a horizontal
... 10 are verticals, 6 are horizontals
Lagally: let's capture this as a first finding
... prioritize horizontals
McCool: not all verticals need all the horizontals
... not all veriticals will need OAuth2 for example
... need a matrix to show this
Kaz: remember we already talked about horizontal vs vertical in
last architecture call
McCool: charter requirement
<Joshue108> +1 to Kaz :-)
Lagally: Horizontal Use Cases
... Accessibility, Privacy, Security, l18n
(Internationalization)
McCool: Other vertical groups we should be reviewing with
... Different overlaps we need to review with verticals
Lagally: Vertical Use Cases
McCool: We should coordinate with these vertical groups
<kaz> horizontal use cases should include: accessibility,
privacy, security, i18n
<kaz> vertical should include: DAS (geolocation), Automotive,
ME
McCool: We need to draft the use case document and reach out to
the groups
... Ask for reviews and input right away when we have a
reasonable design document
... when we have a first document we have consensus on
<inserted> scribenick: kaz
Jennifer: one possible addition for the vertical use cases is
medical one
... need to define what a "medical device", though
... various viewpoints like certified devices
<inserted> scribenick: jenlin
Lagally: There are different standards for military and fitness
trackers, etc
... Do we need to classify different things?
<Joshue108> [137]https://www.w3.org/WAI/APA/
[137] https://www.w3.org/WAI/APA/
Josh: happy to be point of contact for accessibility reviews
<Joshue108> [138]https://www.w3.org/WAI/APA/wiki/Wot_usecases
[138] https://www.w3.org/WAI/APA/wiki/Wot_usecases
Josh: we have a wiki for use cases and added use cases to it
... done a lot of work in user needs and requirements for real
times communications
... just a head's up for some of the work our group has done
<Joshue108> Accessible Platform Architectures (APA)
Josh: the purpose of APA is to make sure W3C specifications
support accessibility
Lagally: do we have any previous experiernce in end to end
(machine to machine communication) sensor/robot interaction?
Kaz: suggest the results from the questionnaire as a basis for
peoples' interest in the categorized use cases here and provide
further contributions
<kaz> scribenick: dape
Kaz: ask for further contributions
McCool: Issue of health: regulation
... expensive to get certification
... similar issues: Automotive, Smart grid and smart building
... wrt. use cases: is it a given industry?
... people avoid health... due to the afore mentioned issues
Lagally: implications of requirements work
... does it help if we know is it regulated?
McCool: Yes. Question whether we need expert.
JENNIFER: Certification is important since some people will
refuse to use it if certification is missing
Lagally: Is there a analogy to HTML ?
McCool: HTML is expection
... e.g. had documentation requirements like XML
... hard to know when you need certification
Lagally: Would be good to know when certification is needed
McCool: WoT TD might need certification
... archived for long time storage
Lagally: Some use-cases still under-represented?
... 5 minute break
<kaz> [5min break]
Lagally: please speak up if someone feels issue
under-represented
<inserted> [139]Requirements area
[139] https://github.com/w3c/wot-architecture/tree/master/REQUIREMENTS
Lagally: We have requirements in wot-architecture
<McCool> sure, I can let others go first ;)
Lagally: 2 req documents created
... one on thing templates
... similar: geolocation support document,
[140]https://github.com/w3c/wot-architecture/blob/master/REQUIR
EMENTS/geolocation.md
... mentioning requirements, related standards, othe
references, comments
[140] https://github.com/w3c/wot-architecture/blob/master/REQUIREMENTS/geolocation.md
McCool: are some use cases requirements?
... e.g., OAuh2
Lagally: Was thinking along the same lines
McCool: Yes, should remove OAuth2 from use-cases
Lagally: Will do
... Some UCs have 1:1 mapping to requirements, other may have
multiple reqs
McCool: let's single out technologies to requirements
... sometimes still fuzzy
Lagally: Several new use cases
... from Cristiano, Ben and McCool
Cristiano: Open field smart agriculture and smart managament
came from one project
... comes from IOT-based platform
... uses Fiware at the moment with LORA (devices that can go to
sleep)
... w.r.t. "Building structural health monitoring", Italien
project on platform for bulding, bridges, ..
... multiple sensors taking high frequency samplings
... can create use-case document
Lagally: Thanks, very helpful
Cristiano: Smart water managements use case is about managing
network of channels
Lagally: related to Fujitsu use-case
... Ben provided use case. Not in the call right now
... Interactive digital signage
Kaz: there is business group on digital signage
... will try to reach out
Lagally: McCool has 3 new use cases
McCool: AI Services, Edge Computing, IoT Orchestration
... Edge Computing: presentation about leveraging WoT discovery
... AI Services: like face detection. pre-defined service,
retail use-case contains it for example
... is somewhat horizontal
... IoT Orchestration: landing zone for scripting
Lagally: Kind of mash-up?
McCool: IoT Orchestration is idea of representing result as new
thing
... new TD
Lagally: reminds me about "links between things"
Kaz: w.r.t. new ideas, we could have another category between
horizontal and vertical, e.g., middleware, if needed
Lagally: I am not opposed to 3 categories... if it helps us
<McCool> McCool: I think we should stick to 2 categories for
now... simpler
<McCool> ... middleware should probably be horizontal
<kaz> Kaz: that's also fine since middlewares tend to get into
the horizontal platform in the end :)
Cristiano: Besides project of monitoring we are evaluating
policies of WoT services
... services discovering other services
... dynamic service migration
McCool: Web worker migration seems related
... virtual things: in retail use-case we use partly virtual
and not physical things
Lagally: comes close to digital twin use case
McCool: Motivation: support for virtual things
<McCool> ... much easier to substitute virtual devices (eg a
camera and AI instead of a real door sensor) if both are
"Things"
Lagally: More new use cases/ideas?
... hearing none
... Summary
... looked into business critical vs. business relevant
... talked about weighted results
... horizontal vs vertical use-cases
... requirements: like OAuth2
... new use-case proposals
... after break we take a look at the points from requirements
perspective
... re-start in 7 minutes, 5 past the hour
<kaz> [7min break]
<kaz> scribenick: FarshidT
Requirements
[141]Slides on Use Cases and Requirements
[141] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-25-Usecases-Requirements-Lagally.pdf
link to repo directory:
[142]https://github.com/w3c/wot-architecture/tree/master/REQUIR
EMENTS
[142] https://github.com/w3c/wot-architecture/tree/master/REQUIREMENTS
Lagally: there is no risk of adding patents into use cases
McCool: the contributions should actually be royalty free. We
have to warn people about that.
... the normative specs cannot include non royalty-free
materials
Kaz: normative portion within the final W3C Recommendation must
be royalty-free, but examples and informative sections don't
require royalty-free commitments
Lagally: more interested into application domains
[143]Requirements for Thing Templates
[143] https://github.com/w3c/wot-architecture/blob/master/REQUIREMENTS/thing-templates.md
Lagally: if a use case requires standardized system component,
it can be included in requirements
... template if good to formulate ideas.
... related standards can point to what other task forces have
been doing to give a good starting point, also not to reinvent
and have overlaps.
McCool: should each use case have a corresponding requirements
document?
Lagally: no, we extract requirement from all use cases. One
requirement may apply to multiple use cases.
... the goal is to have atomic requirements, i.e.
non-overlapping
McCool: also precise and satisfiable
Lagally: acceptance criteria for satisfiability
... we need to have stakeholders for use cases
McCool: we can capture requirements in the PoC meeting. Let's
add this to the agenda.
Lagally: retail and smart city use cases have priority for
Intel.
McCool: manufacturing and smart building may be a priority for
Siemens. Need to confirm.
Kaz: Audio/Video is important for NHK. With help from Kaz.
Chris Needham?
Lagally: for agriculture, there are requirements for
greenhouse, stakeholders are Matsukura-san an Christiano.
... smart city: Michael McCool and Jennifer will work on
requirements
McCool: health is theoretically important, but we don't have
anyone suitable to work on it
Lagally: manufacturing: Sebastian?
... multi-vendor system integration: Oracle has a lot of
interest. M. Lagally.
... multimedia system integration: Intel has interest but no
time, maybe Josh can look into it? Kaz would like to volunteer.
... accessibility: Josh?
... automotive: no expertise
Kaz: can ask about the interest of Access for automotive use
case
Lagally: energy/smart grid: Christian G. from Siemens worked on
the use case. Maybe he can work on it.
... smart building: Farshid, and Andrea C. (UPM)?
... transportation: the use case in very broad, and high level.
Needs additional work.
... Can Zoltan work on transportation?
... shared devices and resources: Ege?
Ege: will continue working on the details
McCool: willing to help Ege regarding this use case.
Lagally: oauth flows use case
McCool: need to look into flows and decide which ones make more
sense. Will be the point of contact.
Lagally: device life cycle: In good hands. Zoltan and M.
Lagally will continue to work on it.
Kaz: got a response from Josh, he will rejoin the call to
discuss accessibility.
Lagally: need to prioritize which use cases to cover in the
next arch. calls (July 7th and then 14th)
... welcomes and briefs Josh
<Joshue108> I can bring these back to Accessibility Platforms
Architecture working group for feedback
Josh: agrees with assignments i.e. multimodal system
integration, accessibility
McCool: first pass needs Josh's expertise
Josh: functional requirements can come from user needs
<Joshue108> +1 to Michael L
Lagally: add a section in requirements section for user needs?
Josh: agrees
Lagally: use case shortlist for next two arch. calls: retail,
agriculture, smart city, multi-vendor system integration,
multimodal system integration, smart building, shared devices
and resources, oauh2 flows, device lifecycle
... have names and owners for all use cases
... need confirmation from some stakeholders
... will check the status in two weeks
... wrap up session tomorrow?
McCool: yes and thing descriptions
Lagally: can get the confirmation from others tomorrow
Farshid: will check with Andrea C.
Lagally: thanking all, closing
<kaz> [Day 4 adjourned]
[144]↑
__________________________________________________________
Day 5
Attendees
Present
Kaz_Ashimura, Michael_McCool, Ben_Francis,
Daniel_Peintner, Farshid_Tavakolizadeh, Jennifer_Lin,
Michael_Lagally, Takuki_Kamiya, Michael_Koster,
Sebastian_Kaebisch, Ryuichi_Matsukura
Regrets
David_Ezell
Chair
McCool, Sebastian
Scribe
Ben, Taki, Cristiano
<kaz> [145]Presentations area
[145] https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-06-online-f2f
Scribes
<kaz> 2 for TD, 1 for marketing
<kaz> 1. Ben
<kaz> 2. Taki
<kaz> 3. Cristiano
TD
<kaz> scribenick: benfrancis
[146]TD slides
[146] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-26-Thing-Description-Kaebisch.pdf
Sebastian: Welcomes the group to Friday session of F2F, Thing
Description discussion
... Known TD spec bugs, under-specified features, new features
for TD 1.1, Status of Templates, hypermedia, discovery &
security
... Discovery & Security will recap discussion from Monday
* Editorial bugs
Sebastian: Want to improve the Thing Description and make it
more powerful. We have found bugs, e.g. in Example 17.
Example 17 has a stray comma which prevents parsing as valid
JSON
Pull request to remove the comma. Question: Should we update
the main Thing Description specification as well?
Kaz: The latest policy is, as long as a fix is editorial, can
fix recommendation itself.
McCool: Should create Errata page so people know what has
changed.
Kaz: Should file two issues, one for recommendation and one for
latest Editor's Draft
McCool: Could label issues that need to be landed in
Recommendation.
<kaz> [147]PR 914
[147] https://github.com/w3c/wot-thing-description/pull/914
Kaz: Can define a simple procedure so we can fix the current
draft on GitHub using PRs, but create additional issue for
Recommendation. Consolidate editorial issues and ask webmaster
to reflect these in the published specification.
... BTW, there was another issue pointed out regarding table
syntax. #919
<kaz>
[148]https://github.com/w3c/wot-thing-description/issues/919
[148] https://github.com/w3c/wot-thing-description/issues/919
RESOLUTION: Pull request to remove comma to be merged into
latest Editor's Draft. The comma is banished. Should create
Errata document to note bug fixes. Daniel will create separate
issue to remove comma in Recommendation, with a label to note
editorial change.
Sebastian: Issue 915
[149]https://github.com/w3c/wot-thing-description/issues/915
[149] https://github.com/w3c/wot-thing-description/issues/915
Validates as valid Thing Description, but if using JSON
Schema(?) validator does not correctly recognise terms in
securityDefinitions collection.
McCool: Schema has definitions for things that have been
removed, needs a cleanup
Sebastian: For people who want to use semantic tools, will have
issues with security members
McCool: Can we update the file as is or publish a new version?
If it's a bug fix, updating the current version makes sense
Should delete extra schemes that are not in the spec to bring
it inline with the specification
How did we miss this? Do our testing tools like include JSON-LD
tests?
Sebastian: We are not doing enough semantic testing in our
PlugFests
McCool: We did do testing, but treated as optional elements so
did not trip the test case. Or similar.
Ege: Should have thrown an error. Perhaps JSON-LD version in
playground is old.
McCool: Should fix the testing so it does trip on this, and fix
context file. Investigate if fixing in place with bug fix is
reasonable.
Sebastian: Context file not directly in the specification. Is
it OK to just change it? The specification is correct, but the
model file has a mistake.
Kaz: Should think about impact for implementations if we fix
the bug in the context file. Will implementations be impacted,
what would need to be changed. Should carefully consider.
McCool: Notify people in advance that the context file will
change in place, set a date for that change, archive old
version with new URL (e.g. v1_obsolete)
Need to consider this a bug fix.
Kaz: Can bring this to project manager and ask if OK to reflect
the change.
... If change impacts implementation then need to discuss
further.
<McCool> to capture what else I said: I'd like to suggest we
establish a minor version, and let "v1" pick up the latest
minor version
McCool: Thanks, I lost track of that part.
<McCool> then if people really want older versions, they can
use a more specific minor version, eg. v1-0, v1-1, etc.
Sebastian: Implementors may wonder why they do not see
securityDefinitions
Kaz: Should assess potential impact
Taki: Can ask bug filer how it impacted their implementation
Sebastian: Bug filer has a workaround.
Dape: Have previously been asked to file issues for Errata
items, this seems similar. I think it would be good to not just
do change in an issue but list as an Errata item.
Kaz: Already provide a template for Errata entries. This issue
might be problematic for implementations should carefully look
into this.
McCool: Different to modifying the specification (human
readable), this is machine readable and would impact
implementations. Bug fix in minor versions.
Figure out how to do bug fix as code, not just editorial change
in spec.
Kaz: Should clarify what our intention was. If this was
intended specification this is fine, but need to fix bug on
specification itself for next version.
<kaz> [150]Errata file
[150] https://w3c.github.io/wot-thing-description/errata.html
McCool: Not an errata issue in spec, bug in file, spec is fine
Kaz: If implementations are impacted, that would be a problem.
Lagally: Support idea of Errata document. So implementors know
what to do to be interoperable, and understand if there is a
delta from what has been published.
Sebastian: Is this Errata document linked in the recommendation
document?
Kaz: Yes, there is a link in the top section.
Sebastian: Resolution: I will respond to issuer to say we can
approve this bug and will fix this in the Errata process.
... These were the two topics we need to address very soon.
<kaz> thinks it's actually a good proof of the fact that people
have started to use the TD spec :)
<benfrancis> kaz++
* URI Variables
Sebastian: Specification looks like we should use uriVariables,
except action input field. Criticized in some issues. Should
clarify when we should use uriVariables.
McCool: So using uri query paramaters is considered bad
practice in API design?
Sebastian: Yes and no. Can use uriVariables in properties etc.
But for actions we have inputs, so why are we showing an
example of uriVariables for actions when we also have input?
uriVariables should probably be avoided if possible for new
systems.
McCool: Two issues. Did we introduce uriVariables as a good
example.
<kaz> [151]Issue 910
[151] https://github.com/w3c/wot-thing-description/issues/910
uriVariables are actually bad practice in actions. For actions
you do have paramterized actions. The use case that comes up is
if input is binary data like an image.
Inconvenient to have to create a body that has some JSON. There
are use cases for this, need to explain.
Sebastian: We should be more clear about usage?
Dape: Disagree. Using uriVariables for properties is bad
design. In case of actions when you POST something considered
good practice if convey data in body. For properties there is
no outcome so considered back practice.
McCool: Question is what you use the query data for. Might want
to put data parameters in POST query. Binary vs. ASCII data.
Need a best practices document that explains these tradeoffs.
The spec just says what the spec can do. Examples should be
reasonable and not contradict best practices.
Sebastian: Example 21 uses uriVariables in a property. Passed
in URL in form. Looks good to me, should maybe provide
clarification.
McCool: I do agree this is a reasonable use. Constraining the
type of data you're getting back. More like a query/database
query.
... I can see it being justified.
Dape: This is a good example of a running instance that works.
Sebastian: But is it really running?
<sebastian>
[152]https://cdn.statically.io/gh/w3c/wot-thing-description/d7c
47cfce6df02f162e16164fe9beee1802ebbeb/index.html#example-21
[152] https://cdn.statically.io/gh/w3c/wot-thing-description/d7c47cfce6df02f162e16164fe9beee1802ebbeb/index.html#example-21
<sebastian>
[153]https://samples.openweathermap.org/data/2.5/weather?q=Lond
on,uk&appid=439d4b804bc8187953eb36d2a8c26a02
[153] https://samples.openweathermap.org/data/2.5/weather?q=London,uk&appid=439d4b804bc8187953eb36d2a8c26a02
<sebastian> PR on updating example 21:
[154]https://github.com/w3c/wot-thing-description/pull/911
[154] https://github.com/w3c/wot-thing-description/pull/911
Sebastian: Should we merge this PR? Update example? More
reasonable, not as confusing.
<Ege> [155]https://openweathermap.org/current
[155] https://openweathermap.org/current
FarshidT: Root of the problem is really the HTTP method. GET
request should not change state.
Sebastian: Action comes from Matthias. Comes from Nabaztag
(Wi-Fi rabbit). Has a REST API. Designed a Thing Description
for this. Uses GET method with parameters. So it's the rabbit's
fault.
... The Thing Description should show best practice.
I may have paraphrased...
RESOLUTION: We will merge this PR.
Sebastian: Should we also close this issue?
[156]https://github.com/w3c/wot-thing-description/issues/913
[156] https://github.com/w3c/wot-thing-description/issues/913
Keep open, but clean up later.
* readmultipleproperties
<inserted> [157]Issue 848
[157] https://github.com/w3c/wot-thing-description/issues/848
Lots of discussion about readmultipleproperties
Very fussy and strange that it was adopted by specification
since there is an expectation we have implementations.
Ege: There are no implementations.
... There are TDs produced, but implementation wasn't doing it
properly.
... Report says there are two implementations, but I can only
find examples from node-wot
<inserted> scribenick: taki
McCool: It was the last minute change.
<McCool> to be clear, implementation report was totally
data-driven, but this extra implementation might have been
based on a manual assertion rather than a TD
<McCool> we will have to look at the archives in more detail
Sebastian: It cannot disappear now. I should investigate more
such as use cases in CoAP PATCH and OPC-UA.
... also it may be common in cloud systems.
Lagally: Network overhead is significant.
... We do read-all in our implementation.
... It is useful in practice.
Koster: Digital twin systems, common interaction through
incremental changes.
... It looks like an interaction model issue.
... It is a model issue.
Ege: It is not clear why we need to supply an array.
... It is different in pub/sub case.
... If it is using URI variable, how can we do this?
Sebastian: It is not well explained in spec.
Daniel: We have both methods for retrieving multiple and all.
... From scripting perspective, it is not really necessary to
have both.
... I can do real-all. If it is only 2 or three, we can use
promise.
Koster: read-all satisfies the requirements.
Zoltan: Are there anyone who absolutely need read-multiple?
Sebastian: CoAP-PATCH? We need to investigate.
Koster: CoAP-PATCH is for patterns. OPC-UA, there is a
bulk-load. Cloud systems usually does not need read multiple.
Zoltan: I have never seen use cases that need read multiple.
Koster: Some people may see read-multiple as optimization.
Zoltan: I can group them in an object in TD.
Koster: There are design patterns. But we do not have concrete
use cases.
Ben: It is safe to remove read-multiple. We can make it as a
feature at risk in the coming version.
Sebastian: One possibility is to remove it in the next version.
At the same time, we could investigate more. For now, it seems
that removing it makes more sense.
Zoltan: We can add it later.
Daniel: You can mark a feature so if nobody finds it useful, is
there procedure in W3C?
Issue #913 Improve text on Action parameters
<inserted> [158]Issue 913
[158] https://github.com/w3c/wot-thing-description/issues/913
Zoltan: multiple parameter case is not very clear in spec right
now.
Sebastian: Those are the issues that I wanted to have discussed
today.
... new features next.
<Ege> brb
Sebastian: minLength, maxLength and multipleOf in Data Schema,
see PR #896.
<inserted> [159]PR 896
[159] https://github.com/w3c/wot-thing-description/pull/896
Sebastian: Have not merged yet because there is a problem in
rendering script now.
... Victor is not available today. He works on rendering
script.
Sebastian shows JSON Schema ontology HTML.
Ben: Mozilla implementation already has multipleOf because
there is a use case.
McCool: Are there any JSON schema features that we do NOT want?
Sebastian: the set we have now was all experimented in
plugfests.
McCool: developer expectation is that it is JSON-Schema.
Koster: We have not seen many payload examples.
... Let's make a bigger useful subset for common payloads.
McCool: We should talk to people experienced in IoT payloads.
Sebastian: We say in spec that we support all keywords.
McCool: $ref, for example, does it break validation?
... we should base our decision on community experience.
Ben: Mozilla implementation is basically using the set
specified in W3C recommendation.
definition and $ref
Sebastian: next, definition and $ref. This is new as well.
... Define data model constructs once, and use it in multiple
places by reference.
<benfrancis> The Mozilla implementation so far uses enum,
readOnly, minimum, maximum and multipleOf. And unit, but I
think that was added for WoT.
Sebastian shows Issue #307.
<kaz> [160]Daniel's example for Issue 307
[160] https://github.com/w3c/wot-thing-description/issues/307#issuecomment-650072301
Sebastian: It was originally suggested by Toru Kawaguchi.
Koster: "definition" is convention in JSON schema.
Ege: Yes
Koster: we can use JSON pointer, and JSON validator work on
that.
Sebastian: JSON validator does not understand action, property,
etc.
<cris>
[161]https://github.com/w3c/wot-thing-description/issues/912
[161] https://github.com/w3c/wot-thing-description/issues/912
Cristiano: I have issue with Content-type in schema. We can
discuss in next TD call.
<Ege>
[162]https://github.com/eclipse/thingweb.node-wot/blob/a3999fac
20a4616d209fe0c1830a311cef0b86a4/examples/templates/exposed-thi
ng/src/base.ts#L124
[162] https://github.com/eclipse/thingweb.node-wot/blob/a3999fac20a4616d209fe0c1830a311cef0b86a4/examples/templates/exposed-thing/src/base.ts#L124
Lagally: Design question. Do we need to parse TD once or twice
to resolve references?
... This is important for constraint systems.
Ege: I posted a link.
Koster: there are also recursive and circular references.
Lagally: We should discuss to limit references to backward
references, for example.
... can you use variable before you declare it?
Daniel: With JSON, object members are shuffled around.
... there is no way to define order in JSON.
Lagally: We have TD serialization, and we can specify.
... This is an issue with small devices.
Sebastian: client may not use all dependencies.
... It is up to the use case.
Koster: constrained devices cannot buffer much in memory, is
that the point?
... security thing is the same.
<McCool> sequence is not technically required by the spec...
but maybe could be required by the profile
Daniel: complexity raises. You can point anywhere in the
document with JSON-schema.
Lagally: We should keep this issue in mind, and specify how to
limit if necessary.
Farshid: Default security, for example. We no longer need it.
... If we copy it to elsewhere, the links will break.
Daniel: We do not intend new dependency.
Farshid: It is only for data definition.
Koster: can we reference definitions outside of the document?
Ege: $ref depends on implementation.
... It is underspecified in JSON-schema spec intentionally.
... AJV, for example, does not have TD scope.
<sebastian_>
[163]https://github.com/eclipse/thingweb.node-wot/blob/a3999fac
20a4616d209fe0c1830a311cef0b86a4/examples/templates/exposed-thi
ng/src/base.ts#L124
[163] https://github.com/eclipse/thingweb.node-wot/blob/a3999fac20a4616d209fe0c1830a311cef0b86a4/examples/templates/exposed-thing/src/base.ts#L124
Ege: You have to copy definition into actions before handing to
AJB.
Daniel: You can copy the entire definition to next to $ref/
... i.e. within the same scope.
Ege: $ref, all depends on implementation.
Sebastian: $ref processing depends on validation tools?
Ege: there is common practice among implementations.
... But it is not specified in JSON schema.
Sebastian: We can specify in TD spec then.
... We can also use JSON pointer.
Kaz: I am skeptical about this proposal.
... for example, there is a possibility of using Verifiable
Credentials and DID for user credentials, so we should look
into some more use cases to see the actual need for "$ref and
definitions".
... We should look at more use cases.
McCool: We can have "processed" version of TD.
... external definition should be disallowed.
... DID is new spec at this point.
... $ref makes more sense to me.
Sebastian: We discussed this in TD call, and we agreed we need
this feature.
Kaz: If the main purpose is defining address separately and
referring to it once, do we really need this feature?
McCool: We wanted to reduce redundancy.
... We should start describing use cases.
... redundancy invites error.
... We should describe use cases.
Ben: parsing algorithm's point view, it introduces complexity.
We can make it preprocesing in the server.
Sebastian: Complexity vs. redundancy is a recurrent issue.
Ben: This is also an issue TDT.
<cris> taki I can take over the notes, or at least I try :)
Sebastian: We have only one hour left.
... We should take a break.
<benfrancis> I also think securityDefinitions should be
simplified so that security can be used on its own for simple
examples
([164]https://github.com/w3c/wot-thing-description/issues/300)
[164] https://github.com/w3c/wot-thing-description/issues/300)
<benfrancis>
[165]https://github.com/mozilla-iot/wiki/wiki/Mozilla-W3C-Diffe
rences
[165] https://github.com/mozilla-iot/wiki/wiki/Mozilla-W3C-Differences
Ben: I started to document the difference between Mozilla
implementation and W3C specification in the hopes that they
will converge.
<cris> ben: starts to document the differences between
mozzilla'TD and W3C TD. Trying to convege
Sebastian: Thank you very much, it is a great work.
... People expect the two are the same.
Ben: there are many minor differences. The bigger one is
architecture changes including protocol binding.
McCool: Profile can help.
<inserted> scribenick: cris
McCool: 10 minutes break
<kaz> [10min break; resume at 15mins past the hour]
McCool: sharing the agenda
Marketing - Current activities
[166]Marketing slides
[166] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-26-Marketing-Kaebisch.pdf
McCool: sebastian review of activities, discussion of the next
steps
Sebastian: quick update, showing a patchwork of different
articles where wot were mentioned
... sharing links to these articles
... please add more if have seen other sources mention wot
... showing the new logo
... please use the new one
... we are working with webcastor which already worked for W3C
... we are going to create a video, Siemens will sponsor it
... and Intel
... sponsor positions are open
... a style of video was decided
McCool: two kinds of sponsorship: money or logos
Lagally: is there some of document which explain the content of
the video
Sebastian: there are some slides about it, cannot show them now
... topic twitter account
... go to @W3C_WoT
<kaz> [167]@W3C_WoT
[167] https://twitter.com/W3C_WoT
Sebastian: there is a draft of a new wot web landing page
<dape> [168]https://github.com/w3c/wot-marketing/issues/65
[168] https://github.com/w3c/wot-marketing/issues/65
Sebastian: was made by Studio 24, daniel has more details about
it
Daniel: provides a link with next steps
... studio24 will provide updates in that issue
<kaz> [169]timeline
[169] https://w3c.studio24.net/timeline/
Daniel: studio24 plans to work openly
Kaz: they are working with the basic template HTML+CSS like a
CMS so that people can easily maintain the Web pages
Daniel: it might be complicated to handle users
Kaz: mentioned to them the possible difficulty with working on
the W3C content which consists of multiple mechanisms
Sebastian: new page on wikipedia about WoT
... it was outdated and not reflected what W3C was doing
... someone made some changes but violated some copyright rules
... we need to discuss how can we improve it
... like describing the different blocks in the W3C WoT
architecture
Ege: we need to provide more references
Sebastian: how can we improve it ?
McCool: create a draft were we can work together with other
parties
... also can we trigger an re-evaluation of the page content?
Ege: need to explicitly ask for an re-evaluation
McCool: in the marketing repo we have a md page that needs to
be kept in sync
Kaz: ege, do you know some external collaborator who can help
us with the wiki?
Ege: we can tweet about this
<kaz> [170]WoT welcome page
[170] https://w3c.github.io/wot-marketing/
Lagally: What's the plan with the public WoT landing page?
Daniel: the current one has nothing to do with what studio24 is
doing
<McCool> timecheck: now way over the 10m allocated...
Daniel: we mean to substitute it with the new one
Lagally: when is the best time to provide feedback about the
new landing page?
Kaz: we can talk about this during the next marketing call
Sebastian: Michael, you can comment anytime
Lagally: it is quite confusing because we have two versions
running in parallel
Kaz: the [171]W3C WoT Landing page was made/maintened by the
W3C Team, while the new [172]WoT Welcome page is
made/maintained by the WoT Marking TF.
... On the other hand, we (=Daniel, etc.) were asked for input
from Studio24 who is now working on the redesign of the global
W3C pages (except the group pages like the WoT Welcome page)
[171] https://www.w3.org/wot/
[172] https://w3c.github.io/wot-marketing/
Lagally: just let us know if something is ready for review
Kaz: Studio24 is working on the global W3C pages except the
group pages
... So we have to make a resolution on how/when to review the
WoT group pages including the [173]WoT Welcome page
[173] https://w3c.github.io/wot-marketing/
Lagally: so this group page is ready for review?
Sebastian: yes
McCool: time check 18 minutes left
... handle kaz presentation to next slot
... we should now discuss about the next steps
Sebastian: the next steps were already included in the previous
slides
... there is a broken link in the global W3C page
Ege: the point is that we do not have access to this page, even
if we are the most interested by its content
Kaz: there are two kinds of Web pages, 1. those maintained by
the W3C Team and 2. those maintained by the WoT WG ourselves.
So I wanted to explain what's ongoing on the W3C Team side, but
let's talk about the details during the next Marketing call
<inserted> [174]W3C Project Management Updates
[174] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-26-Project-Management-Kaz.pdf
<McCool> at the very least I think we need to streamline change
requests, eg with direct access to an issue tracker
Sebastian: topic upcoming conferences
... Ege has applied to a ASC 2020 conference
Ege: if anyone has input about my submission is there still
time for editing
McCool: we could also have a session were we review your
slides, maybe in the Marketing calls
... the conference it will be a good chance to talk with
experts from other technologies (i.e. openAPI)
Sebastian: there is a video about node-wot in action
McCool: there is also a template for slides to keep a
consistent look&feel
Ege: include some photos from plugfest as additional material
to include in presentations
McCool: we need to get a consent by people on these pictures
Ege: but they are already pubblic
McCool: we still need to get their consent
Ege: another thing in addition to a template we can put
material which will be used inside the presentations
McCool: any other comments?
... let's agree on the template and start to use it
Kaz: the template is nice, thank you
Wrap-up and Closing
[175]Slides
[175] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-26-Closing-McCool.pdf
McCool: topic closing session
... topic followup activities
... profiles in 2 weeks, call for TDT in 2 weeks (TD webex),
hypermedia calls in 3 weeks...
... try to cancel as many calls as we can to break after F2F
... let's cancell all the TF meetings but if you have an
exception please report it in the mailing list
<kaz> [176]Project management updates for Marketing
[176] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-26-Project-Management-Kaz.pdf
Kaz: should we move also the discussion about Marketing tools
in the next marketing call?
McCool: yes let's move it in 2 weeks
... when will the minutes be ready?
<inserted> from now, i.e., July 8
McCool: let's put fix a deadline: 2 weeks from now
... if there are any other follow up activities please email me
Lagally: I need to allocate someone to the requirements of
manufacturing
Sebastian: you can put me and Christian and also to the smart
building requirements
McCool: who's is going to post about F2F on twitter?
... assigns sebastian to this task
Kaz: please take a look at my slides before the next marketing
call
<kaz> [177]Project management updates for Marketing
[177] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-26-Project-Management-Kaz.pdf
McCool: we should keep an eye on Ege slides for the next
conference
... is any followup action that I miss?
... ok none, please if you have any additional items send me an
email
... please also update your presentations with a PR
... ok we are done
Kaz: thanks McCool and Sebastian
<kaz> also all the scribes!
Sebastian: thank you also from my side
[vF2F adjourned]
[178]↑
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [179]scribe.perl version ([180]CVS log)
$Date: 2020/07/07 12:03:51 $
[179] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[180] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 16 July 2020 00:43:35 UTC