WoT-IG/WG - Virtual F2F meeting

22-26 Jun 2020



Day 1


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
Lagally, Farshid, Kaz



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: 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

Opening slides

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> W3C PP

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: https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-06-online-f2f

<inserted> scribenick: kaz

Lagally: use cases questionnaire ongoing

<McCool> use case priority questionnaire

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.


scribenick: mlagally

Security slides

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]


scribenick: FarshidT

Discovery slides

* 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: https://github.com/w3c/wot-discovery/blob/master/requirements.md

- Key design decisions

<inserted> Design document

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

LinkSmart slides

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> 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-online-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

VC in IoT slides

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 "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 "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

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]

Day 2


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
SMcCool, Sebastian
sebastian, Ege, kaz, dape

<McCool> agenda: https://www.w3.org/WoT/IG/wiki/F2F_meeting_2020_2nd#WoT_F2F_Agenda


<kaz> 1. Sebastian

<kaz> 2. Ege

<kaz> 3. Daniel

<kaz> scribenick: sebastian

McCool: shows the agenda

<kaz> Agenda: https://www.w3.org/WoT/IG/wiki/F2F_meeting_2020_2nd#WoT_F2F_Agenda

PoC Projects

PoC slides

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 slides

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> Plugfest+Outcome PlugFest Outcome issues

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> 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


scribenick: Ege

Scripting slides

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> PR 207

<kaz> PR 203

Zoltan: we have improved the error mapping

<kaz> PR 209

Zoltan: so how to map errors to protocols and back

<kaz> PR 218

<kaz> PR 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> 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: https://github.com/w3c/wot/pull/922

<McCool> ok

<kaz> Scripting.pdf fyi scripting slides (tentatively)

<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> InteractionInput and InteractionOutput, support streams

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> Error handling (related to PR 221)

<kaz> Issue 219

Zoltan: We have open issues, regarding readmultipleproperties

<kaz> issue 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> Issue 910

<kaz> Issue 913

<kaz> Issue 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> Issue 204 - Semantic API

<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> https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06_WoT-Bindings.pdf

<kaz> scribenick: kaz

<inserted> Browsified node-wot

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

Binding slides

<Ege> Google Docs version

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> Issue 1

McCool: need to look at more recent versions, and security

<kaz> Issue 92

<Ege> https://github.com/w3c/wot-binding-templates/issues/92

Ege: please comment on issue https://github.com/w3c/wot-binding-templates/issues/92 to identify new ones

McCool: suggest zeroMQ, will add it to issue

<kaz> ZeroMQ

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> ROS

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> 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> 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> 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> Issue 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


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 WoT REC press release

<kaz> WoTPy

McCool: maybe we can reach out and have 1-to-1 discussion

Ege: my contact person was not interested ;-)

<cris> https://pypyjs.org/

McCool: will create issue about "how to support Python"

<McCool_> https://github.com/w3c/wot-testing/issues/37

<kaz> [Day 2 adjourned]

Day 3


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
McCool, Sebastian
jenlin, zkis


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> 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



Lagally: please fill it

WoT Profiles

Profiles slides

<mlagally__> 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> 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> strawman draft for 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> strawman draft for 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> 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]


<kaz> scribenick: jenlin

Lifecycle slides

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


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]

Day 4


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
McCool, Sebastian
Jennifer, Daniel, Farshid


<kaz> Agenda: https://www.w3.org/WoT/IG/wiki/F2F_meeting_2020_2nd#WoT_F2F_Agenda

<kaz> 1. Jennifer

<kaz> 2. Daniel

<kaz> 3. Farshid


<kaz> Presentations area

<inserted> scribenick: jenlin

McCool: Double-check the name of your presentation

Use Case Prioritization

Slides on Use Cases and Requirements

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> wot-usecases repo

<kaz> old USE-CASES area from the wot-architecture repo

Lagally: folder called Contributions for new use cases

<kaz> use case template

McCool: Subdirectory is old use case template, top level is new

Lagally: Will fix after call

<kaz> initial use case draft

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> wot-usecases issues transferred from wot-architecture repo

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

Slides on Use Cases and Requirements

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> questionnaire results (member-only)

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> https://www.w3.org/WAI/APA/

Josh: happy to be point of contact for accessibility reviews

<Joshue108> 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> Requirements area

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, https://github.com/w3c/wot-architecture/blob/master/REQUIREMENTS/geolocation.md
... mentioning requirements, related standards, othe references, comments

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


Slides on Use Cases and Requirements

link to repo directory: 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

Requirements for Thing Templates

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]

Day 5


Kaz_Ashimura, Michael_McCool, Ben_Francis, Daniel_Peintner, Farshid_Tavakolizadeh, Jennifer_Lin, Michael_Lagally, Takuki_Kamiya, Michael_Koster, Sebastian_Kaebisch, Ryuichi_Matsukura
McCool, Sebastian
Ben, Taki, Cristiano

<kaz> Presentations area


<kaz> 2 for TD, 1 for marketing

<kaz> 1. Ben

<kaz> 2. Taki

<kaz> 3. Cristiano


<kaz> scribenick: benfrancis

TD slides

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> PR 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> 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 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> Errata file

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> Issue 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> https://cdn.statically.io/gh/w3c/wot-thing-description/d7c47cfce6df02f162e16164fe9beee1802ebbeb/index.html#example-21

<sebastian> https://samples.openweathermap.org/data/2.5/weather?q=London,uk&appid=439d4b804bc8187953eb36d2a8c26a02

<sebastian> PR on updating example 21: https://github.com/w3c/wot-thing-description/pull/911

Sebastian: Should we merge this PR? Update example? More reasonable, not as confusing.

<Ege> 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?


Keep open, but clean up later.

* readmultipleproperties

<inserted> Issue 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> Issue 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> PR 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> Daniel's example for Issue 307

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> 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> 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_> 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 (https://github.com/w3c/wot-thing-description/issues/300)

<benfrancis> 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

Marketing slides

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> @W3C_WoT

Sebastian: there is a draft of a new wot web landing page

<dape> 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> 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> WoT welcome page

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 W3C WoT Landing page was made/maintened by the W3C Team, while the new 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)

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 WoT Welcome page

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> W3C Project Management Updates

<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


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> Project management updates for Marketing

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> Project management updates for Marketing

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]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/07/07 12:03:51 $