W3C home > Mailing lists > Public > public-wot-ig@w3.org > July 2020

[wot-ig/wg][vF2F] compiled minutes - 22-26 June 2020

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Thu, 16 Jul 2020 09:44:44 +0900
Message-ID: <87eepcguf7.wl-ashimura@w3.org>
To: public-wot-ig@w3.org, public-wot-wg@w3.org
available at:

also available as text below.

Thanks a lot for all the scribes, the prsenters and the Chairs!



      [1] http://www.w3.org/

                               - DRAFT -

                    WoT-IG/WG - Virtual F2F meeting

22-26 Jun 2020


      [2] https://www.w3.org/WoT/IG/wiki/F2F_meeting_2020_2nd#WoT_F2F_Agenda


     * [3]Day 1
         1. [4]Opening and Quick updates
              1. [5]Scribes
              2. [6]Agenda
              3. [7]Opening Session
         2. [8]Security
              1. [9]Signing TDs
              2. [10]Decentralized identifiers
              3. [11]OAuth2
              4. [12]End-to-End security
              5. [13]Other key open issues
         3. [14]Discovery
              1. [15]Requirements and Design decisions - Michael
                   1. [16]Discovery requirements
                   2. [17]Key design decisions
                   3. [18]Privacy issues
                   4. [19]Introduction
                   5. [20]Exploration
                   6. [21]Key issues
              2. [22]LinkSmart directory service update - Farshid
              3. [23]Verifiable Credntials in IoT Services - Nikos
     * [24]Day 2
         1. [25]Scribe
         2. [26]PoC Projects
         3. [27]PlugFest
         4. [28]Note on where to put the sides for the vF2F
         5. [29]Scripting
         6. [30]Binding Template
         7. [31]Logistics for tomorrow
         8. [32]AOB?
     * [33]Day 3
         1. [34]Agenda
         2. [35]Use Case questionnaire
         3. [36]Questionnaire
         4. [37]WoT Profiles
         5. [38]Lifecycle
         6. [39]Tomorrow
     * [40]Day 4
         1. [41]Scribes
         2. [42]Presentations
         3. [43]Use Case Prioritization
         4. [44]Prioritization questionnaire results
         5. [45]Requirements
     * [46]Day 5
         1. [47]Scribes
         2. [48]TD
              1. [49]Editorial bugs
              2. [50]URI Variables
              3. [51]readmultipleproperties
              4. [52]Issue #913 Improve text on Action parameters
              5. [53]definition and $ref
         3. [54]Marketing
         4. [55]Wrap-up and Closing
     * Summary of Action Items
     * Summary of Resolutions
         1. [56]Pull request to remove comma to be merged into
            latest Editor's Draft. The comma is banished. Should
            create Errata document to note bug fixes. Daniel will
            create separate issue to remove comma in
            Recommendation, with a label to note editorial change.
         2. [57]We will merge this PR.

Day 1


          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,



          Lagally, Farshid, Kaz


     [58] https://www.w3.org/WoT/IG/wiki/F2F_meeting_2020_2nd#WoT_F2F_Agenda


     [59] https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-06-online-f2f

Opening and Quick updates

* Scribes

   <kaz> 1. Lagally

   <kaz> 2. Farshid

   <kaz> 3. Kaz

* Agenda

   <inserted> scribenick: mlagally

   McCool walks through the agenda, some small tweaks for
   gathering, breaks

   <McCool> agenda:

     [60] https://www.w3.org/WoT/IG/wiki/F2F_meeting_2020_2nd#WoT_F2F_Agenda

   McCool: let's use the IRC channel for chat, not the WebEx chat

* Opening Session

   [61]Opening slides

     [61] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-22-F2F-Opening-McCool.pdf

   McCool: any guests?
   ... any non W3C members?

   <kaz> Dmitrij Lagutin from Aarto University is a guest for

   McCool: please respect W3C patent policy

   <kaz> [62]W3C PP

     [62] https://www.w3.org/Consortium/Patent-Policy-20170801/

   McCool: Dmitrij Lagutin is a guest, his University is a member

   <kaz> Nikos Fotiou from AUEB as well

   McCool: all, to simplify management, please give full names
   when you join WebEx on future calls
   ... Logistics: There's a github site with all presentations
   ... please put your presentation material to it

   <McCool> presentations:

     [63] https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-06-online-f2f

   <inserted> scribenick: kaz

   Lagally: use cases questionnaire ongoing

   <McCool> [64]use case priority questionnaire

     [64] https://www.w3.org/2002/09/wbs/1/wot-uc-priority-202005/

   Lagally: there are 15 questions in the questionnaire
   ... options on "not interested", "useful, but not business
   relevant", "business relevant", "business critical"
   ... last one (q18: category 17) is proposal for a new possible
   use case
   ... if you have any other ideas for which WoT to be applied,
   please put them
   ... in terms of the deadline, we'll discuss the results on
   Thursday during the vF2F
   ... so please respond by then

   <inserted> mm: note that Kaz reported a bug with the TD
   Recommendation, but the detail to be discussed during the TD


   scribenick: mlagally

   [65]Security slides

     [65] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-22-Security-McCool.pdf

   McCool: we'll talk about Discovery later today after the break
   ... There was related work in "Lifecycle" and "Use cases"
   ... DID's will be discussed in depth in discovery
   ... OAuth2 work is still in progress
   ... Lfieycle has been discussed extensively, identifier
   management is an important topic there
   ... in architecture there were discussions about agents and
   stakeholders, we also used certain terms in security, need to
   move over to architecture
   ... not all use cases have security and privacy considerations
   yet, please make sure to include these when creating a new use
   ... "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
   ... 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

   Lagally: actual signature should be validated
   ... don't see how that kind of validation would fit for dynamic

   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

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

   Farshid: multiple flow support is important, it is not clear
   who is involved

   McCool: different interactions can have different security
   ... 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

   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
   ... E2E concept is very vague, i.e. who is the end consumer
   ... need to specify the endpoints in the requirements and use
   ... this leads to various issues with "bridges" in the
   ... 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"

* 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

   [66]Discovery slides

     [66] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-22-Discovery-McCool.pdf

* Requirements and Design decisions - Michael McCool

   McCool: will talk about requirements, design decisions,
   two-phase arch., key issues. More details about some topics
   will be covered in Farshid's presentation

- Discovery requirements

   McCool: support for remote discovery is necessary
   ... semantic querying should be supported minimally at least,
   since we have linked data
   ... support large repos of things, and p2p (self-identying)
   ... 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
   ... also, align with WoT scripting API
   ... link to file collecting requirements:

     [67] https://github.com/w3c/wot-discovery/blob/master/requirements.md

- Key design decisions

   <inserted> [68]Design document

     [68] https://github.com/w3c/wot-discovery/blob/master/design.md

   McCool: only one resolution, i.e. on two-phase architecture
   ... introduction phase to identify exploration services,
   exploration phase to get descriptions
   ... technologies for introduction, DHCP, DNS-SD, DID Documents,
   QR codes, etc
   ... exploration: well known location. URL may point at the
   Thing, the TD, or the directory service
   ... introduction should be open so it can be consumed with no
   or limited access controls
   ... lightweight to not waste computational and networking
   ... resist to DDoS
   ... exploration meta data should be returned only to authorized

- 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

   McCool: agrees

- Exploration

   McCool: auth is required
   ... well known location to get the TD
   ... light query language to have parameter based filtering
   ... medium like jsonpath and xpath
   ... advanced like sparql, graphql

- Key issues

   McCool: form of query, support for semantic queries
   ... describe directory with a TD
   ... TCP/HTTP baseline protocol
   ... partial and fragment TDs, implications for JSON-LD
   ... pagination
   ... out-of-band data such as system-generated IDs
   ... notifications for changes to TDs
   ... links to other open issues on github

   Kaz: need to look into concrete use cases for those issues

* LinkSmart directory service update

   <kaz> scribenick: kaz

   [69]LinkSmart slides

     [69] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-22-Discovery-ThingDirectory-Tavakolizadeh.pdf

   Farshid: what are done so far
   ... (shows outline)
   ... current status, naming, jsonpath/xpath, drectory meta info,
   paginatio, ns-sd, tds, dircory td
   ... [current status]
   ... cataloging
   ... DNS-SD registration
   ... RESTful API
   ... OpenAPI, TD CRUD, catalog, valiation
   ... [Naming]
   ... Thing Directory (not to be shorten as "TD" :)
   ... how to call it to avoid the confusion with "Thing
   ... 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

   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:

   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

   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

   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

   <Ege> [70]https://github.com/w3c/wot-marketing/issues/66

     [70] https://github.com/w3c/wot-marketing/issues/66

   McCool: 2. also we should have discussion on error codes

   Zoltan: we discuss this error mapping issue during
   nline-f2f/2020-06-22-DID-VC-Fotiou.pdfhe scripting calls
   ... agree with Ben
   ... we should describe error codes within the TD spec
   ... need some generic mechanism for error handling
   ... we need some work with several TFs

   McCool: (time check)
   ... we should move forward to the DID discussion
   ... and continue this discussion during the TD session

   Ege: note that I've submitted some idea to the OpenAPI conf

   McCool: let's take a look at that tomorrow

* Verifiable Credentials in IoT Services - Nikos Fotiou

   [71]VC in IoT slides

     [71] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-22-DID-VC-Fotiou.pdf

   Nikos: (about SOFIE)
   ... an EU project which enables interoperability among existing
   IoT platforms
   ... [VC in a nutshell]
   ... verifiable credential is a standard way to express
   credentials on the Web
   ... vc-data-model is a W3C REC
   ... [VC Structure]
   ... context: issuer ID, Credential (type, subject id, claims),
   ... digitally signed by the issuer
   ... [The "Sofie Credential"]
   ... (example VC data)
   ... @context has
   ... 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
   ... securityDefinitions has
   ... @type: ["VerifiableCredential", "AllowedURLs"]
   ... [SOFIE's Identity, Authentication, and Authorization
   ... 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
   ... [SOFIE]
   ... links for resources

     [72] https://mm.aueb.gr/contexts/access_control/v1
     [73] https://mm.aueb.gr/contexts/access_control/v1

   McCool: tx
   ... you're presenting the security scheme based on VC and DID
   ... replace with other security mechanism?
   ... don't we need other mechanisms like OAuth?

   Nikos: that's possible

   McCool: probably we would extend TD for this purpose
   ... do you looked at XPath as well?

   Nikos: yes

   McCool: similar issues/considerations to be applied
   ... how to deal with selection of devices?
   ... filter-based metadata in the VC would raise issue with
   ... 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

   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

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


          SMcCool, Sebastian

          sebastian, Ege, kaz, dape

   <McCool> agenda:

     [75] 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:

     [76] https://www.w3.org/WoT/IG/wiki/F2F_meeting_2020_2nd#WoT_F2F_Agenda

PoC Projects

   [77]PoC slides

     [77] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-23-PoCs-McCool.pdf

   Jennifer: summary Smart City use case
   ... apply SPOTON in that scenario
   ... use of AI and thermal cameras for health monitoring
   ... pandemic management
   ... it is a first use case for introduction
   ... there are also plans for mapping and robots usage
   ... we want to start small

   McCool: we should update the health monitoring use case
   ... we want a PoC on geolocation, right?

   Jennifer: not using it yet
   ... maybe later

   McCool: we should revisite PoC plannings

   Jennifer: we will add that to the use cases

   McCool: Retail
   ... there two different busniss groups
   ... and collaborations such as Conexxus, Intel,...
   ... retail scenario: buying ice cream
   ... we want to demonstrate visible sensors and analytics by
   ... demonstrator shall show how simple applications can be
   ... 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)


   [78]PlugFest slides

     [78] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-23-Plugfest-McCool.pdf

   McCool: full week virtual plugfest via VPN, one hour day sync
   ... 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
   ... people can go there and test its implementation

   McCool: it would be cool to have a dashboard which things are

   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
   ... there were things within VPN and some outside (in the
   internet) such as Thing Directory

   <inserted> [79]Plugfest+Outcome PlugFest Outcome issues

     [79] https://github.com/w3c/wot-testing/issues?q=is:issue+is:open+label:

   McCool: outcomes and issues are provided
   ... balabce vlaudation and experimentation, usefulness of VPN,
   Xpath useful for discovery, get validation and reporting tools
   ready before the plugfest, IDs needed for primary keys

   Ege: we spend a lot of time about VPN, but who is depending on

   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


     [80] https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-06-online-f2f

   <McCool> please put presentations at the above directory - I
   will move the scripting pres later


   scribenick: Ege

   [81]Scripting slides

     [81] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-23-Scripting-Kis.pdf

   Zoltan: we had busy time since March
   ... in ConsumedThing you can specify the form ... index
   ... we discussed on how to handle contentType and DataSchema
   ... and we added most of the algorithms

   <kaz> [82]PR 207

     [82] https://github.com/w3c/wot-scripting-api/pull/207

   <kaz> [83]PR 203

     [83] https://github.com/w3c/wot-scripting-api/pull/203

   Zoltan: we have improved the error mapping

   <kaz> [84]PR 209

     [84] https://github.com/w3c/wot-scripting-api/pull/209

   Zoltan: so how to map errors to protocols and back

   <kaz> [85]PR 218

     [85] https://github.com/w3c/wot-scripting-api/pull/218

   <kaz> [86]PR 221

     [86] https://github.com/w3c/wot-scripting-api/pull/221

   <inserted> scribenick: kaz

   Ege: status message also should be handled
   ... by the ConsumedThing

   Zoltan: how to map the protocol-specific errors with JS errors
   is the question

   Ege: script should understand protocol specific features

   Zoltan: developer could make mapping

   <inserted> scribenick: Ege

   Zoltan: so the mappings are more straightforward

   Lagally: we discussed something similar with Sebastian and
   Matthias a couple years ago
   ... the errors in the API should be abstracted from the

   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


     [87] https://github.com/w3c/wot-thing-description/issues/303

   Sebastian: So the issue that ml described, I have pasted the
   link in the IRC
   ... TD issue number 303
   ... so we can continue discussion in there

   Kaz: You can share the link in IRC as well

   <Ege> @mmccool, could you merge this PR:

     [88] https://github.com/w3c/wot/pull/922

   <McCool> ok

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

     [89] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-23-vF2F-WoT

   <kaz> [slide 3: WoT Scripting API specification updates]

   Zoltan: we worked on observe and subscribe handlers

   <McCool> btw I'll rename slides later to clean things up, don't
   worry too much about it for now

   <kaz> [90]InteractionInput and InteractionOutput, support

     [90] https://w3c.github.io/wot-scripting-api/#handling-interaction-data

   Zoltan: and also getting values from the interaction outputs
   ... now we can parse to different media types
   ... also streams are possible
   ... this was a big change

   Ege: handling observe and subscribe is needed if you want to
   build a proxy with Scripting API so that you can dynamically
   listen to observe requests from Consumers and relay it to the
   actual Thing

   <kaz> [slide : Opens]

   <kaz> [91]Error handling (related to PR 221)

     [91] https://github.com/w3c/wot-scripting-api/issues/200

   <kaz> [92]Issue 219

     [92] https://github.com/w3c/wot-scripting-api/issues/219

   Zoltan: We have open issues, regarding readmultipleproperties

   <kaz> [93]issue 912

     [93] https://github.com/w3c/wot-thing-description/issues/912

   Zoltan: also contentType or DataSchema but mixing them (raised
   by Cristiano)
   ... we need to sync with the Discovery TF for the discovery API

   <kaz> [94]Issue 910

     [94] https://github.com/w3c/wot-thing-description/issues/910

   <kaz> [95]Issue 913

     [95] https://github.com/w3c/wot-thing-description/issues/913

   <kaz> [96]Issue 206

     [96] https://github.com/w3c/wot-thing-description/issues/206

   Zoltan: We have the discovery API but it is very unspecific
   ... but there are already proposals like ThingFilter

   McCool: so we need to generalize the ThingFilter to payloads or
   URI content since both can be inputs for discovery

   Daniel: the reason to not let consume() method accept a URI is
   to avoid having to support multiple protocols while fetching
   the TD

   McCool: yes, so the consume method works without network access

   Zoltan: there is also the semantic api proposal by Michael
   Koster but we didn't have to explore it yet

   <kaz> [97]Issue 204 - Semantic API

     [97] https://github.com/w3c/wot-scripting-api/issues/204

   <kaz> [slide 5: Deployment scenarios]

   Zoltan: we are also discussing on how to deploy scripts

   <inserted> [slide 7: Status node-wot]

   Daniel: Here are some updates on node-wot
   ... we support HTTP, CoAP, MQTT, OPCUA, Netconf and Modbus
   being planned

   McCool: what about CBOR?

   Daniel: We don't have support for it but they can be very
   easily plugged
   ... you can do everything in the browser as well
   ... then the hands-on material was improved

   McCool: I find the test thing having data types as names a bit

   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

   Daniel: you can also see that we have many PRs by contributors
   and we are making good progress


     [98] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06_WoT-Bindings.pdf

   <kaz> scribenick: kaz

   <inserted> [99]Browsified node-wot

     [99] http://plugfest.thingweb.io/webui/

   Kaz: Daniel, are you planning to use the webui version of
   node-wot for the upcoming PlugFest in the future

   Daniel: already using it

   Kaz: would be great to have some document as well
   ... good starting point. thanks a lot!

   [5min break]

Binding Template

   scribenick: dape

   [100]Binding slides

    [100] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06_WoT-Bindings.pdf

   <Ege> [101]Google Docs version

    [101] https://docs.google.com/presentation/d/1ZhwbVQGKL5scnXWtfm_s0L1UmNjo_tQxa2YukUQ9uLA/edit?usp=sharing

   Ege: [slide 2] - Protocol Vocabularies
   ... we have turtle files for CoAP and MQTT
   ... thanks to Victor
   ... [slide 3]
   ... links to rendered version
   ... [slide 4]
   ... improvements about vocabularies still needed
   ... [slide 5] - Interest Check
   ... so far we have HTTP, CoAP, MQTT.. done
   ... no interest on oneM2M, OCF so far

   McCool: w.r.t. OCF, implementantions 1.0

   <kaz> [102]Issue 1

    [102] https://github.com/w3c/wot-binding-templates/issues/1

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

   <kaz> [103]Issue 92

    [103] https://github.com/w3c/wot-binding-templates/issues/92


    [104] https://github.com/w3c/wot-binding-templates/issues/92

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

    [105] https://github.com/w3c/wot-binding-templates/issues/92

   McCool: suggest zeroMQ, will add it to issue

   <kaz> [106]ZeroMQ

    [106] https://zeromq.org/

   McCool: [slide 6, 7] - Robotic Operating System (ROS)

   Ege: ROS is middleware
   ... communicates with protocols of robot over lower level
   ... programming is abstract
   ... [slide 8]
   ... ROS has similar goals to the WoT

   McCool: ROS has security problems
   ... work on ROS2 is in progress

   Ege: Agree, it is 10 years old
   ... lot of devices out with ROS "1"

   McCool: ROS2 has more industrial strength

   Ege: [slide 9]
   ... ROS: Mixed broker and P2P communication

   <kaz> [107]ROS

    [107] https://www.ros.org/

   Ege: can store TD
   ... consume them

   McCool: Payload issue? Serialized with YAML?

   Ege: contentType has to be specific contentType

   Ege: [slide 10]
   ... 3rd July call, proposal shown in Binding call

   McCool: Did have issues with node.js implementation

   Ege: Implementation improved
   ... [slide 10] - Subprotocols
   ... [slide 11] - Server Sent Events
   ... serves pushes events to client/consumer
   ... PR for node-wot
   ... used in OpenHAB
   ... plan to look into subprotocols
   ... [slide 12] - bridging protocols
   ... MQTT over WS
   ... clients can used WS to talk with MQTT device
   ... there is also CoAP over WS

   McCool: CoAP over WS mentioned by Mozilla also
   ... should look at there use-cases also

   McCool: OpenHAB is very interesting
   ... PoC for OpenHAB is very valuable

   Sebastian: Student of mine works on openHAB topic

   McCool: OK, great. can talks about that in Plugfest call

   Kaz: Question: if we want to use MQTT over WS... web browser as
   possible client?

   Ege: Yes. correct

   Kaz: NHK uses web browser in TV set
   ... could be part of the future PlugFest as well

   McCool: TD describable enough ?

   Ege: Yes, interesting topic. will come to it later
   ... [slide 13]
   ... [slide 14] Paho in Python, reference implementation
   ... different to node.js implementation
   ... TD consumption step needs some assumption
   ... not sure how to describe it in href

   McCool: Standardized URLs for MQTT?

   Ege: There isn't
   ... broker URL and topic
   ... see issue 255 in node-wot
   ... assumption / best practice


    [108] https://github.com/w3c/wot-thing-description/issues/878

   Ege: also issue 878 in TD repo

   Farshid: some pure MQTT implementation use TCP and SSL
   ... no mentioning of WS but TCP, SSL
   ... no standardized scheme


    [109] https://github.com/mqtt/mqtt.github.io/wiki/URI-Scheme

   <Ege> Some implementations may also support the 'tcp' and 'ssl'
   scheme names.

   McCool: similar issue with JSON schema.. not having a standard

   Sebastian: we have to check MQTT standard
   ... many implementation out that are not following standard


    [110] http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/csprd01/mqtt-v3.1.1-csprd01.html

   Sebastian: MQTT 3.1 is weak w.r.t. security
   ... --> different security solutions implemented but not

   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

   McCool: vocabulary should be normative
   ... how do we get there?
   ... other groups are in charge
   ... need to work with other organizations

   Kaz: agree
   ... can publish group note first and then transfer if needed

   McCool: Yes, reach out to other organizations a well

   Ege: node-wot examples could be added ...

   McCool: Yes, but putting note saying it is prototype

   Ege: will add to issue 92 ... OPC-UA, NETCONF and Modbus

   <kaz> [111]Issue 92

    [111] https://github.com/w3c/wot-binding-templates/issues/92

   Ege: New protocol interest, please let me know

   Kaz: will you update the slides on the GitHub repo with the
   "next steps" page?

   Ege: yes

   McCool: 2 missing protocols: Zigbee and zwave
   ... not sure if feasible

   Ege: Not sure if we can support them
   ... would open up to USB, Bluetoothm ....

   McCool: Agree

   Cristiano: w.r.t. ROS. I did some experiments. Difficult to
   understand initial setup, topics, et cetera

   Ege: Correct. WoT can help here
   ... direct XML RPC is possible also
   ... lots of extra communication is done and rather messy

   McCool: ROS has formal documents
   ... in YAML files
   ... Comments/input?

Logistics for tomorrow

   McCool: shall we discuss logistics for tomorrow
   ... Wednesday, 3 hours sessions by M. Lagally
   ... please upload presentation to github repo
   ... will do a clean-up step later


   Jennifer: client application connecting to WoT. Recommendation
   to use HTTP or MQTT ?

   McCool: TD is independent
   ... >discussion how to wrap node.js code in other languages<

   Kaz: most of PF participant have been using HTTP and other
   protocols are of interest

   McCool: It is also a discussion about implementation language.
   node.js... C++ et cetera

   Kaz:there is a python implementation for WoT, WoTPy, as put on
   the [112]WoT REC press release

    [112] https://www.w3.org/2020/04/pressrelease-wot-rec.html

   <kaz> [113]WoTPy

    [113] https://github.com/agmangas/wot-py

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

   Ege: my contact person was not interested ;-)

   <cris> [114]https://pypyjs.org/

    [114] https://pypyjs.org/

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

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

    [115] https://github.com/w3c/wot-testing/issues/37

   <kaz> [Day 2 adjourned]


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


    [117] https://www.w3.org/2002/09/wbs/1/wot-uc-priority-202005/

   <inserted> scribenick: jenlin

   mlagally: Collected 15 use cases so far
   ... Can people respond by the end of the day today for the Use
   Case questionnaire?

   <zkis> scribenick:zkis



    [118] https://www.w3.org/2002/09/wbs/1/wot-uc-priority-202005/

   Lagally: please fill it

WoT Profiles

   [119]Profiles slides

    [119] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-24-Profiles-Lagally.pdf

   <mlagally__> [120]https://github.com/w3c/wot-profile

    [120] https://github.com/w3c/wot-profile

   Lagally: we hat a github repo
   ... and handle this in the Architecture task force
   ... presents slides
   ... motivation for profiles: we need out of the box
   ... 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

   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
   ... 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
   ... as developer, wants TDs to be simple as possible (e.g. in
   constrained devices)
   ... as a developer, being able to validate compatibility with

   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

   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

   Lagally: it is not "either, or"

   Koster: just saying there is a lot of benefit in doing the
   standard even without explicit profiles

   Lagally: implementing own client is not a good requirement

   Zoltan: (fill in later)

   Lagally: what do we do if actions go wrong?

   Zoltan: need to describe an error

   <mjk> [121]https://xkcd.com/927/

    [121] https://xkcd.com/927/

   Kaz: if we need additional mechanisms, we should indeed add
   ... but we should look into exact use cases first

   Lagally: there is a certain methodology on this in the

   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
   ... especially regarding security

   Lagally: agree that we need to limit and constrain security

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

   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
   ... 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
   ... 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
   ... profiles should have a finite set of features and
   capabilities to be implemented by the consumer
   ... Check out the current Profile draft

   <kaz> [122]strawman draft for WoT Profile

    [122] https://w3c.github.io/wot-profile/

   Lagally: profiles should not define new features, just
   constrain and clarify existing ones
   ... how to describe a profile: we need a generic profile
   ... 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
   ... 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
   ... 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

   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

   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

   Lagally: presenting core profile
   ... constraint on the protocol binding is that default binding
   is HTTPS
   ... predefined mapping of HTTP verbs to WoT interactions
   ... only a single Form per interaction
   ... constrained set of data types (e.g. no arrays of arrays)
   ... profile status: last year a strawman proposal was made
   ... architecture TF focused on lifecycle

   McCool: want to open a discussion about logistics
   ... how exactly should we proceed with profiles

   Lagally: let's finish the presentation first

   McCool: do we start with a strawman and improve later, or do we
   want more preparation

   Ben: there is a list of proposed and accepted requirements
   ... need to agree on the accepted requirements

   Lagally: certainly, please participate in that discussion
   ... presenting the profiles github repository
   ... and the strawman proposal

   <kaz> [123]strawman draft for WoT Profile

    [123] https://w3c.github.io/wot-profile/

   McCool: the structure is reasonable
   ... there are some issues
   ... we need to create better requirements and then modify it
   with a set of PRs
   ... and document things in issues

   Ben: will try to write a draft for requirements on what's
   ... 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

   Ben: a client really needs to know what ops and details they

   Koster: both LwM2M and OCF have profile-like constraints
   ... it should be checked

   Lagally: we could discuss that in an upcoming Architecture call

   Koster: OCF could be easy to map to HTTP - given security
   details are sorted out

   McCool: we can figure out later if profiles vs bindings need to
   address constraints
   ... the question is figuring out the next steps
   ... is it in the architecture calls?

   Lagally: yes, the next Architecture calls
   ... please take a look at the profile issues
   ... create new issues

   <benfrancis> Clarification for the minutes: The requirements
   document I mentioned writing was for the Web Thing Protocol
   Community Group, not WoT profiles as I want to make sure all
   the WoT specifications do not conflict with each other.

   <benfrancis> The comment about ops was that defining default
   HTTP methods for operations is only part of what is needed by a
   client - also need to define headers, payloads, response codes,
   error conditions etc. Perhaps the Profile could go further than
   the TD and Protocol Bindings specification in defining those,
   or constrain TDs to a particular sub-protocol

   <benfrancis> which defines them.

   Lagally: review the strawman proposal

   <kaz> [124]wot-profile issues

    [124] https://github.com/w3c/wot-profile/issues

   McCool: we have 2 architecture calls, needs some alignment

   Lagally: we can have that conversation later

   McCool: break time

   <kaz> [resume in 6 mins]


   <kaz> scribenick: jenlin

   [125]Lifecycle slides

    [125] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-24-Lifecycle-Kis-Lagally.pdf

   Michael_Lagally: Presenting WoT Lifecycle

   Lagally: Goals: Describe the operational lifecycle model across
   different standards, Align terminiology, Identify impact and
   ... 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
   ... 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
   ... 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

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

   <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

   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:

    [127] https://www.w3.org/WoT/IG/wiki/F2F_meeting_2020_2nd#WoT_F2F_Agenda

   <kaz> 1. Jennifer

   <kaz> 2. Daniel

   <kaz> 3. Farshid


   <kaz> [128]Presentations area

    [128] https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-06-online-f2f

   <inserted> scribenick: jenlin

   McCool: Double-check the name of your presentation

Use Case Prioritization

   [129]Slides on Use Cases and Requirements

    [129] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-25-Usecases-Requirements-Lagally.pdf

   Lagally: Cancelled earlier Use Case call due to low attendance,
   merging with this call
   ... Almost 2 hours for Use Case results
   ... More of a discussion today rather than presentation on the
   Architecture Use Cases & Requirements
   ... Questionnaire results
   ... Use cases ~ 20 proposed in the architecture group
   ... Mentions active contributors of Use Cases
   ... Also target domains
   ... Work split: Architecture and Use Case Task Force
   ... Capture new use cases, open to all IG members, community,
   and guests
   ... All use case related issues moved over to new repo

   <kaz> [130]wot-usecases repo

    [130] https://github.com/w3c/wot-usecases

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

    [131] https://github.com/w3c/wot-architecture/tree/master/USE-CASES

   Lagally: folder called Contributions for new use cases

   <kaz> [132]use case template

    [132] https://github.com/w3c/wot-usecases/blob/master/CONTRIBUTIONS/use-case-template.md

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

   Lagally: Will fix after call

   <kaz> [133]initial use case draft

    [133] https://w3c.github.io/wot-usecases/

   McCool: This is an informative document (use cases) and there
   will be no royalty commitment required

   Lagally: There is an "Issues" tab and structure things separate

   <kaz> [134]wot-usecases issues transferred from
   wot-architecture repo

    [134] https://github.com/w3c/wot-usecases/issues

   Lagally: Architecture Discussion Process diagram
   ... Use Case Shortlisting
   ... Want to make sure Use Cases coming from different sources
   have business interests
   ... And real market needs
   ... Want to make sure to focus on the important/priority use

   McCool: 40% of use cases involves orchestration of devices from
   ... how do you account economic activity?

   Koster: owe you a use case based from market need

   McCool: agree with basic point to need to figure out advantage

   Koster: Capabilities model

   Lagally: will have another use case meeting, ask mk to join

   Koster: dog upset by fireworks

   Lagally: Questionnaire results

   Koster: Will try to make regular call

   Kaz: what about inviting Koster to the architecture call?

   Lagally: good idea

   <kaz> architecture calls are 11pm and 8am in PDT

Prioritization questionnaire results

   [135]Slides on Use Cases and Requirements

    [135] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-25-Usecases-Requirements-Lagally.pdf

   Lagally: Put together the results as of 25.6 @ noon
   ... have not received responses on all the use cases
   ... business relevant responses are higher than business

   <kaz> [136]questionnaire results (member-only)

    [136] https://www.w3.org/2002/09/wbs/1/wot-uc-priority-202005/results

   Lagally: anyone not a W3C member?

   Josh: part of the W3C Team

   Lagally: Ogiso-san a W3C member?

   Kaz: yes.

   Lagally: Lots of written feedback to look into

   McCool: This questionnaire is very flat.
   ... I marked a lot of things as business critical
   ... What's missing is to rank the use cases
   ... Need to do trade-offs between use cases

   Lagally: Right. Will get to it in the second half of the call.
   Will assign rank.
   ... Need to do weighted results, inventing a formula.
   ... Weighted Results, e.g., business critical=6; business
   relevant=3; useful=1
   ... This is not final
   ... What people are interested in the most
   ... representing the members of the group

   McCool: This metric ranks things higher even though there are
   other things that are business critical
   ... While this is helpful, a more direct question about ranking
   will be helpful

   Kaz: Similar to McCool. The result of direct question might be
   the same as the results of this formula, but if some use case
   is very important for a company, it should be handled and
   included in the final proposal
   ... probably, we can categorize all the proposed use cases into
   3 categories, critical, relevant and useful, and then which use
   cases would be handled by whom

   Lagally: identify what needs to happen if we dig deeper in
   ... 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

   <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

   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,

   McCool: We need to draft the use case document and reach out to
   the groups
   ... Ask for reviews and input right away when we have a
   reasonable design document
   ... when we have a first document we have consensus on

   <inserted> scribenick: kaz

   Jennifer: one possible addition for the vertical use cases is
   medical one
   ... need to define what a "medical device", though
   ... various viewpoints like certified devices

   <inserted> scribenick: jenlin

   Lagally: There are different standards for military and fitness
   trackers, etc
   ... Do we need to classify different things?

   <Joshue108> [137]https://www.w3.org/WAI/APA/

    [137] https://www.w3.org/WAI/APA/

   Josh: happy to be point of contact for accessibility reviews

   <Joshue108> [138]https://www.w3.org/WAI/APA/wiki/Wot_usecases

    [138] https://www.w3.org/WAI/APA/wiki/Wot_usecases

   Josh: we have a wiki for use cases and added use cases to it
   ... done a lot of work in user needs and requirements for real
   times communications
   ... just a head's up for some of the work our group has done

   <Joshue108> Accessible Platform Architectures (APA)

   Josh: the purpose of APA is to make sure W3C specifications
   support accessibility

   Lagally: do we have any previous experiernce in end to end
   (machine to machine communication) sensor/robot interaction?

   Kaz: suggest the results from the questionnaire as a basis for
   peoples' interest in the categorized use cases here and provide
   further contributions

   <kaz> scribenick: dape

   Kaz: ask for further contributions

   McCool: Issue of health: regulation
   ... expensive to get certification
   ... similar issues: Automotive, Smart grid and smart building
   ... wrt. use cases: is it a given industry?
   ... people avoid health... due to the afore mentioned issues

   Lagally: implications of requirements work
   ... does it help if we know is it regulated?

   McCool: Yes. Question whether we need expert.

   JENNIFER: Certification is important since some people will
   refuse to use it if certification is missing

   Lagally: Is there a analogy to HTML ?

   McCool: HTML is expection
   ... e.g. had documentation requirements like XML
   ... hard to know when you need certification

   Lagally: Would be good to know when certification is needed

   McCool: WoT TD might need certification
   ... archived for long time storage

   Lagally: Some use-cases still under-represented?
   ... 5 minute break

   <kaz> [5min break]

   Lagally: please speak up if someone feels issue

   <inserted> [139]Requirements area

    [139] https://github.com/w3c/wot-architecture/tree/master/REQUIREMENTS

   Lagally: We have requirements in wot-architecture

   <McCool> sure, I can let others go first ;)

   Lagally: 2 req documents created
   ... one on thing templates
   ... similar: geolocation support document,
   ... mentioning requirements, related standards, othe
   references, comments

    [140] https://github.com/w3c/wot-architecture/blob/master/REQUIREMENTS/geolocation.md

   McCool: are some use cases requirements?
   ... e.g., OAuh2

   Lagally: Was thinking along the same lines

   McCool: Yes, should remove OAuth2 from use-cases

   Lagally: Will do
   ... Some UCs have 1:1 mapping to requirements, other may have
   multiple reqs

   McCool: let's single out technologies to requirements
   ... sometimes still fuzzy

   Lagally: Several new use cases
   ... from Cristiano, Ben and McCool

   Cristiano: Open field smart agriculture and smart managament
   came from one project
   ... comes from IOT-based platform
   ... uses Fiware at the moment with LORA (devices that can go to
   ... 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
   ... 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

   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
   ... re-start in 7 minutes, 5 past the hour

   <kaz> [7min break]

   <kaz> scribenick: FarshidT


   [141]Slides on Use Cases and Requirements

    [141] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-25-Usecases-Requirements-Lagally.pdf

   link to repo directory:

    [142] https://github.com/w3c/wot-architecture/tree/master/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

   Kaz: normative portion within the final W3C Recommendation must
   be royalty-free, but examples and informative sections don't
   require royalty-free commitments

   Lagally: more interested into application domains

   [143]Requirements for Thing Templates

    [143] https://github.com/w3c/wot-architecture/blob/master/REQUIREMENTS/thing-templates.md

   Lagally: if a use case requires standardized system component,
   it can be included in requirements
   ... template if good to formulate ideas.
   ... related standards can point to what other task forces have
   been doing to give a good starting point, also not to reinvent
   and have overlaps.

   McCool: should each use case have a corresponding requirements

   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.

   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

   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

   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

   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> [145]Presentations area

    [145] https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-06-online-f2f


   <kaz> 2 for TD, 1 for marketing

   <kaz> 1. Ben

   <kaz> 2. Taki

   <kaz> 3. Cristiano


   <kaz> scribenick: benfrancis

   [146]TD slides

    [146] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-26-Thing-Description-Kaebisch.pdf

   Sebastian: Welcomes the group to Friday session of F2F, Thing
   Description discussion
   ... Known TD spec bugs, under-specified features, new features
   for TD 1.1, Status of Templates, hypermedia, discovery &
   ... 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

   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

   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

   <kaz> [147]PR 914

    [147] https://github.com/w3c/wot-thing-description/pull/914

   Kaz: Can define a simple procedure so we can fix the current
   draft on GitHub using PRs, but create additional issue for
   Recommendation. Consolidate editorial issues and ask webmaster
   to reflect these in the published specification.
   ... BTW, there was another issue pointed out regarding table
   syntax. #919


    [148] https://github.com/w3c/wot-thing-description/issues/919

   RESOLUTION: Pull request to remove comma to be merged into
   latest Editor's Draft. The comma is banished. Should create
   Errata document to note bug fixes. Daniel will create separate
   issue to remove comma in Recommendation, with a label to note
   editorial change.

   Sebastian: Issue 915

    [149] https://github.com/w3c/wot-thing-description/issues/915

   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

   Sebastian: We are not doing enough semantic testing in our

   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

   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

   <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

   Kaz: Should assess potential impact

   Taki: Can ask bug filer how it impacted their implementation

   Sebastian: Bug filer has a workaround.

   Dape: Have previously been asked to file issues for Errata
   items, this seems similar. I think it would be good to not just
   do change in an issue but list as an Errata item.

   Kaz: Already provide a template for Errata entries. This issue
   might be problematic for implementations should carefully look
   into this.

   McCool: Different to modifying the specification (human
   readable), this is machine readable and would impact
   implementations. Bug fix in minor versions.

   Figure out how to do bug fix as code, not just editorial change
   in spec.

   Kaz: Should clarify what our intention was. If this was
   intended specification this is fine, but need to fix bug on
   specification itself for next version.

   <kaz> [150]Errata file

    [150] https://w3c.github.io/wot-thing-description/errata.html

   McCool: Not an errata issue in spec, bug in file, spec is fine

   Kaz: If implementations are impacted, that would be a problem.

   Lagally: Support idea of Errata document. So implementors know
   what to do to be interoperable, and understand if there is a
   delta from what has been published.

   Sebastian: Is this Errata document linked in the recommendation

   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

   McCool: Two issues. Did we introduce uriVariables as a good

   <kaz> [151]Issue 910

    [151] https://github.com/w3c/wot-thing-description/issues/910

   uriVariables are actually bad practice in actions. For actions
   you do have paramterized actions. The use case that comes up is
   if input is binary data like an image.

   Inconvenient to have to create a body that has some JSON. There
   are use cases for this, need to explain.

   Sebastian: We should be more clear about usage?

   Dape: Disagree. Using uriVariables for properties is bad
   design. In case of actions when you POST something considered
   good practice if convey data in body. For properties there is
   no outcome so considered back practice.

   McCool: Question is what you use the query data for. Might want
   to put data parameters in POST query. Binary vs. ASCII data.

   Need a best practices document that explains these tradeoffs.
   The spec just says what the spec can do. Examples should be
   reasonable and not contradict best practices.

   Sebastian: Example 21 uses uriVariables in a property. Passed
   in URL in form. Looks good to me, should maybe provide

   McCool: I do agree this is a reasonable use. Constraining the
   type of data you're getting back. More like a query/database
   ... I can see it being justified.

   Dape: This is a good example of a running instance that works.

   Sebastian: But is it really running?


    [152] https://cdn.statically.io/gh/w3c/wot-thing-description/d7c47cfce6df02f162e16164fe9beee1802ebbeb/index.html#example-21


    [153] https://samples.openweathermap.org/data/2.5/weather?q=London,uk&appid=439d4b804bc8187953eb36d2a8c26a02

   <sebastian> PR on updating example 21:

    [154] https://github.com/w3c/wot-thing-description/pull/911

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

   <Ege> [155]https://openweathermap.org/current

    [155] https://openweathermap.org/current

   FarshidT: Root of the problem is really the HTTP method. GET
   request should not change state.

   Sebastian: Action comes from Matthias. Comes from Nabaztag
   (Wi-Fi rabbit). Has a REST API. Designed a Thing Description
   for this. Uses GET method with parameters. So it's the rabbit's
   ... The Thing Description should show best practice.

   I may have paraphrased...

   RESOLUTION: We will merge this PR.

   Sebastian: Should we also close this issue?


    [156] https://github.com/w3c/wot-thing-description/issues/913

   Keep open, but clean up later.

* readmultipleproperties

   <inserted> [157]Issue 848

    [157] https://github.com/w3c/wot-thing-description/issues/848

   Lots of discussion about readmultipleproperties

   Very fussy and strange that it was adopted by specification
   since there is an expectation we have implementations.

   Ege: There are no implementations.
   ... There are TDs produced, but implementation wasn't doing it
   ... 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

   Koster: read-all satisfies the requirements.

   Zoltan: Are there anyone who absolutely need read-multiple?

   Sebastian: CoAP-PATCH? We need to investigate.

   Koster: CoAP-PATCH is for patterns. OPC-UA, there is a
   bulk-load. Cloud systems usually does not need read multiple.

   Zoltan: I have never seen use cases that need read multiple.

   Koster: Some people may see read-multiple as optimization.

   Zoltan: I can group them in an object in TD.

   Koster: There are design patterns. But we do not have concrete
   use cases.

   Ben: It is safe to remove read-multiple. We can make it as a
   feature at risk in the coming version.

   Sebastian: One possibility is to remove it in the next version.
   At the same time, we could investigate more. For now, it seems
   that removing it makes more sense.

   Zoltan: We can add it later.

   Daniel: You can mark a feature so if nobody finds it useful, is
   there procedure in W3C?

Issue #913 Improve text on Action parameters

   <inserted> [158]Issue 913

    [158] https://github.com/w3c/wot-thing-description/issues/913

   Zoltan: multiple parameter case is not very clear in spec right

   Sebastian: Those are the issues that I wanted to have discussed
   ... new features next.

   <Ege> brb

   Sebastian: minLength, maxLength and multipleOf in Data Schema,
   see PR #896.

   <inserted> [159]PR 896

    [159] https://github.com/w3c/wot-thing-description/pull/896

   Sebastian: Have not merged yet because there is a problem in
   rendering script now.
   ... Victor is not available today. He works on rendering

   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

   McCool: developer expectation is that it is JSON-Schema.

   Koster: We have not seen many payload examples.
   ... Let's make a bigger useful subset for common payloads.

   McCool: We should talk to people experienced in IoT payloads.

   Sebastian: We say in spec that we support all keywords.

   McCool: $ref, for example, does it break validation?
   ... we should base our decision on community experience.

   Ben: Mozilla implementation is basically using the set
   specified in W3C recommendation.

definition and $ref

   Sebastian: next, definition and $ref. This is new as well.
   ... Define data model constructs once, and use it in multiple
   places by reference.

   <benfrancis> The Mozilla implementation so far uses enum,
   readOnly, minimum, maximum and multipleOf. And unit, but I
   think that was added for WoT.

   Sebastian shows Issue #307.

   <kaz> [160]Daniel's example for Issue 307

    [160] https://github.com/w3c/wot-thing-description/issues/307#issuecomment-650072301

   Sebastian: It was originally suggested by Toru Kawaguchi.

   Koster: "definition" is convention in JSON schema.

   Ege: Yes

   Koster: we can use JSON pointer, and JSON validator work on

   Sebastian: JSON validator does not understand action, property,


    [161] https://github.com/w3c/wot-thing-description/issues/912

   Cristiano: I have issue with Content-type in schema. We can
   discuss in next TD call.


    [162] https://github.com/eclipse/thingweb.node-wot/blob/a3999fac20a4616d209fe0c1830a311cef0b86a4/examples/templates/exposed-thing/src/base.ts#L124

   Lagally: Design question. Do we need to parse TD once or twice
   to resolve references?
   ... This is important for constraint systems.

   Ege: I posted a link.

   Koster: there are also recursive and circular references.

   Lagally: We should discuss to limit references to backward
   references, for example.
   ... can you use variable before you declare it?

   Daniel: With JSON, object members are shuffled around.
   ... there is no way to define order in JSON.

   Lagally: We have TD serialization, and we can specify.
   ... This is an issue with small devices.

   Sebastian: client may not use all dependencies.
   ... It is up to the use case.

   Koster: constrained devices cannot buffer much in memory, is
   that the point?
   ... security thing is the same.

   <McCool> sequence is not technically required by the spec...
   but maybe could be required by the profile

   Daniel: complexity raises. You can point anywhere in the
   document with JSON-schema.

   Lagally: We should keep this issue in mind, and specify how to
   limit if necessary.

   Farshid: Default security, for example. We no longer need it.
   ... If we copy it to elsewhere, the links will break.

   Daniel: We do not intend new dependency.

   Farshid: It is only for data definition.

   Koster: can we reference definitions outside of the document?

   Ege: $ref depends on implementation.
   ... It is underspecified in JSON-schema spec intentionally.
   ... AJV, for example, does not have TD scope.


    [163] https://github.com/eclipse/thingweb.node-wot/blob/a3999fac20a4616d209fe0c1830a311cef0b86a4/examples/templates/exposed-thing/src/base.ts#L124

   Ege: You have to copy definition into actions before handing to

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

    [164] https://github.com/w3c/wot-thing-description/issues/300)


    [165] https://github.com/mozilla-iot/wiki/wiki/Mozilla-W3C-Differences

   Ben: I started to document the difference between Mozilla
   implementation and W3C specification in the hopes that they
   will converge.

   <cris> ben: starts to document the differences between
   mozzilla'TD and W3C TD. Trying to convege

   Sebastian: Thank you very much, it is a great work.
   ... People expect the two are the same.

   Ben: there are many minor differences. The bigger one is
   architecture changes including protocol binding.

   McCool: Profile can help.

   <inserted> scribenick: cris

   McCool: 10 minutes break

   <kaz> [10min break; resume at 15mins past the hour]

   McCool: sharing the agenda

Marketing - Current activities

   [166]Marketing slides

    [166] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-26-Marketing-Kaebisch.pdf

   McCool: sebastian review of activities, discussion of the next

   Sebastian: quick update, showing a patchwork of different
   articles where wot were mentioned
   ... sharing links to these articles
   ... please add more if have seen other sources mention wot
   ... showing the new logo
   ... please use the new one
   ... we are working with webcastor which already worked for W3C
   ... we are going to create a video, Siemens will sponsor it
   ... and Intel
   ... sponsor positions are open
   ... a style of video was decided

   McCool: two kinds of sponsorship: money or logos

   Lagally: is there some of document which explain the content of
   the video

   Sebastian: there are some slides about it, cannot show them now
   ... topic twitter account
   ... go to @W3C_WoT

   <kaz> [167]@W3C_WoT

    [167] https://twitter.com/W3C_WoT

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

   <dape> [168]https://github.com/w3c/wot-marketing/issues/65

    [168] https://github.com/w3c/wot-marketing/issues/65

   Sebastian: was made by Studio 24, daniel has more details about

   Daniel: provides a link with next steps
   ... studio24 will provide updates in that issue

   <kaz> [169]timeline

    [169] https://w3c.studio24.net/timeline/

   Daniel: studio24 plans to work openly

   Kaz: they are working with the basic template HTML+CSS like a
   CMS so that people can easily maintain the Web pages

   Daniel: it might be complicated to handle users

   Kaz: mentioned to them the possible difficulty with working on
   the W3C content which consists of multiple mechanisms

   Sebastian: new page on wikipedia about WoT
   ... it was outdated and not reflected what W3C was doing
   ... someone made some changes but violated some copyright rules
   ... we need to discuss how can we improve it
   ... like describing the different blocks in the W3C WoT

   Ege: we need to provide more references

   Sebastian: how can we improve it ?

   McCool: create a draft were we can work together with other
   ... also can we trigger an re-evaluation of the page content?

   Ege: need to explicitly ask for an re-evaluation

   McCool: in the marketing repo we have a md page that needs to
   be kept in sync

   Kaz: ege, do you know some external collaborator who can help
   us with the wiki?

   Ege: we can tweet about this

   <kaz> [170]WoT welcome page

    [170] https://w3c.github.io/wot-marketing/

   Lagally: What's the plan with the public WoT landing page?

   Daniel: the current one has nothing to do with what studio24 is

   <McCool> timecheck: now way over the 10m allocated...

   Daniel: we mean to substitute it with the new one

   Lagally: when is the best time to provide feedback about the
   new landing page?

   Kaz: we can talk about this during the next marketing call

   Sebastian: Michael, you can comment anytime

   Lagally: it is quite confusing because we have two versions
   running in parallel

   Kaz: the [171]W3C WoT Landing page was made/maintened by the
   W3C Team, while the new [172]WoT Welcome page is
   made/maintained by the WoT Marking TF.
   ... On the other hand, we (=Daniel, etc.) were asked for input
   from Studio24 who is now working on the redesign of the global
   W3C pages (except the group pages like the WoT Welcome page)

    [171] https://www.w3.org/wot/
    [172] https://w3c.github.io/wot-marketing/

   Lagally: just let us know if something is ready for review

   Kaz: Studio24 is working on the global W3C pages except the
   group pages
   ... So we have to make a resolution on how/when to review the
   WoT group pages including the [173]WoT Welcome page

    [173] https://w3c.github.io/wot-marketing/

   Lagally: so this group page is ready for review?

   Sebastian: yes

   McCool: time check 18 minutes left
   ... handle kaz presentation to next slot
   ... we should now discuss about the next steps

   Sebastian: the next steps were already included in the previous
   ... there is a broken link in the global W3C page

   Ege: the point is that we do not have access to this page, even
   if we are the most interested by its content

   Kaz: there are two kinds of Web pages, 1. those maintained by
   the W3C Team and 2. those maintained by the WoT WG ourselves.
   So I wanted to explain what's ongoing on the W3C Team side, but
   let's talk about the details during the next Marketing call

   <inserted> [174]W3C Project Management Updates

    [174] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-26-Project-Management-Kaz.pdf

   <McCool> at the very least I think we need to streamline change
   requests, eg with direct access to an issue tracker

   Sebastian: topic upcoming conferences
   ... Ege has applied to a ASC 2020 conference

   Ege: if anyone has input about my submission is there still
   time for editing

   McCool: we could also have a session were we review your
   slides, maybe in the Marketing calls
   ... the conference it will be a good chance to talk with
   experts from other technologies (i.e. openAPI)

   Sebastian: there is a video about node-wot in action

   McCool: there is also a template for slides to keep a
   consistent look&feel

   Ege: include some photos from plugfest as additional material
   to include in presentations

   McCool: we need to get a consent by people on these pictures

   Ege: but they are already pubblic

   McCool: we still need to get their consent

   Ege: another thing in addition to a template we can put
   material which will be used inside the presentations

   McCool: any other comments?
   ... let's agree on the template and start to use it

   Kaz: the template is nice, thank you

Wrap-up and Closing


    [175] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-26-Closing-McCool.pdf

   McCool: topic closing session
   ... topic followup activities
   ... profiles in 2 weeks, call for TDT in 2 weeks (TD webex),
   hypermedia calls in 3 weeks...
   ... try to cancel as many calls as we can to break after F2F
   ... let's cancell all the TF meetings but if you have an
   exception please report it in the mailing list

   <kaz> [176]Project management updates for Marketing

    [176] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-26-Project-Management-Kaz.pdf

   Kaz: should we move also the discussion about Marketing tools
   in the next marketing call?

   McCool: yes let's move it in 2 weeks
   ... when will the minutes be ready?

   <inserted> from now, i.e., July 8

   McCool: let's put fix a deadline: 2 weeks from now
   ... if there are any other follow up activities please email me

   Lagally: I need to allocate someone to the requirements of

   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

   <kaz> [177]Project management updates for Marketing

    [177] https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-06-online-f2f/2020-06-26-Project-Management-Kaz.pdf

   McCool: we should keep an eye on Ege slides for the next
   ... is any followup action that I miss?
   ... ok none, please if you have any additional items send me an
   ... 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 [179]scribe.perl version ([180]CVS log)
    $Date: 2020/07/07 12:03:51 $

    [179] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
    [180] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 16 July 2020 00:43:37 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 16 July 2020 00:43:38 UTC