[wot-architecture] minutes - 11 March 2021

available at:
  https://www.w3.org/2021/03/11-wot-arch-minutes.html

also as text below.

Thanks a lot for taking the minutes, Michael Koster!

Kazuyuki

---
   [1]W3C

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

                            WoT Architecture

11 March 2021

   [2]Agenda. [3]IRC log.

      [2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#March_11th.2C_2021
      [3] https://www.w3.org/2021/03/11-wot-arch-irc

Attendees

   Present
          Daniel_Peintner, Kaz_Ashimura, Michael_Koster,
          Michael_Lagally, Philipp_Blum, Sebastian_Kaebisch,
          Tomoaki_Mizushima

   Regrets
          Michael_McCool

   Chair
          Lagally

   Scribe
          kaz, mjk

Contents

    1. [4]agenda bashing
    2. [5]minutes
    3. [6]reference design
    4. [7]vF2F agenda

Meeting minutes

  agenda bashing

   <kaz> [8]Agenda

      [8] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#March_11th.2C_2021

   Lagally: copy/paste from last meeting
   … any other agenda items?

   Sebastian: discussion on the new device profile issue#71

  minutes

   <kaz> [9]Mar-4

      [9] https://www.w3.org/2021/03/04-wot-arch-minutes.html

   Lagally: minutes approved

  reference design

   <kaz> [10]Issue 68 - Reference Device Definition for the
   smallest possible platform for HTTP / TCP / JSON

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

   Lagally: reviewing the discussion on the issue

   Lagally: assuming http, tls, and JSON
   … assuming consume-only, what are the constraints?

   Daniel: there is also some work from Zoltan

   Lagally: there are a lot of details in the record
   … 16K is a common size

   Sebastian: what is a realistic size based on devices and
   consumer expectations
   … using ESP module as an example device
   … devices will have a specific purpose and know what kind of
   model it consumes
   … the client will follow a specific information model
   … what kind of constrained consumers are there in the plugfest?

   Lagally: maybe there weren't any

   Sebastian: not aware of any embedded TD consumers

   Lagally: so we could assume embedded devices use a built-in
   information model

   Lagally: reviewing use cases from issue #71
   … Ben Francis comments from the last few days

   <kaz> [11]Ben's comments

     [11] https://github.com/w3c/wot-profile/issues/71#issuecomment-792782567

   Sebastian: there is also a goal to find out how small devices
   can run HTTP, TLS, JSON

   Lagally: hesitate to get into the protocols, but we do make the
   assumptions about HTTP TLS, JSON

   Lagally: a lot of the platforms are embedded PC/linux class

   Sebastian: characteristics of producers and consumers of TDs
   are independent of scale, could have only one or two features

   Sebastian: the example platforms are all general purpose and
   can consume any TD
   … constrained device consumers will only be looking for a
   limited set of features
   … based on the device purpose
   … then at the other end of the scale, embedded linux/PC there
   will be potentially very large TDs

   Lagally: I understand the point

   Kaz: maybe we should consider the use cases without
   intermediaries and concentrate on Things and Consumers as the
   starting point, but would suggest we think about intermediary
   as well for the 2nd step for the use case scenarios

   Daniel: what is the consequence of not having the hard limits?

   Lagally: there could be TDs that can't be processed on some
   devices

   Daniel: imposing the limit doesn't change the situation with
   the small device

   Sebastian: this seems to be a generic problem with the device
   being too small for the expected application

   Philipp: TDs need to be validated and we don't know how to
   stream and validate TDs

   Sebastian: do we need to validate TDs on small devices?

   (thx kaz)

   Lagally: assuming yes, you need to parse and validate

   Lagally: it may take separate passes but it needs to fit in the
   buffer

   Lagally: if the TD doesn't fit in the buffer, can you consume
   such a complex TD?

   Philipp: also prefer to not restrict the size, what about using
   a directory as a helper

   Lagally: we want to avoid needing any intermediaries

   Lagally: we need to restrict the TD size if we want to consume
   TDs on small devices

   Sebastian: +1 the idea of an external helper that can work with
   client queries
   … the client doesn't know what to do with most of the unrelated
   TD content

   Lagally: will the client ask the directory to limit the size of
   the TD?

   Sebastian: more like it will only return the functions
   requested

   Koster: sometimes the client only needs the form that satisfies
   the interaction requested in a query

   Lagally: ideally all devices communicate with each other

   Sebastian: practically there will be some service point for
   queries and serving TDs, there is no peer to peer IoT today

   Lagally: so there may always be a gateway in our assumption

   Lagally: 2 classes of devices, small devices are not consumers

   <kaz> (that's why I suggested we include intermediary for the
   next step :)

   Sebastian: there is always an assumption that there are bigger
   devices in the system

   Daniel: how does it help small devices to consume large TDs?

   Koster: maybe the directory could just return the form

   Sebastian: you don't need to provide the full TD to the small
   device that knows what it wants to do

   <kaz> (yeah, that's why I brought partial TD topic to the
   Discovery call on March 8 :)

   <citrullin> +1 on partial TDs in directories

   Lagally: why couldn't the TD producer also do this filtering?

   Sebastian: it could if we define it

   Lagally: to address dape, we can define graceful failure modes

   Kaz: need to think about all entities, device, intermediary,
   consumer, directory, as a system

   Koster: need to drop now

   Lagally: right
   … Ben also suggested we think about gateway
   … if some of the entity handles TD, that guy need to be
   qualified to handle the TD
   … some kind of guidelines or restrictions to be provided

   (Koster and Daniel leave)

   Sebastian: if the TD with some specific size or bigger size
   which exceed the processable size of the entity, need some
   guideline
   … good to see feedback from the scripting/discovery guys

   Lagally: (adds a comment)
   … a consumer on a constrained device can check if it can
   process the TD
   … or get a partial TD when otherwise
   … the size would be too large

   Kaz: I already asked the scripting/discovery guys for opinions
   on Monday
   … and they also wanted to know about concrete use case
   scenarios

   <sebastian> (Sebastian leaves)

   Kaz: so this discussion today is going for the right direction
   :)

  vF2F agenda

   [12]Architecture day - Monday, March 22

     [12] https://www.w3.org/WoT/IG/wiki/F2F_meeting,_March_2021#Monday_March_22

   Lagally: (goes through the draft agenda)
   … introductions
   … terminology
   … partial TD
   … based on the input from the Discovery/Scripting TFs
   … TD validation
   … based on the input from the TD TF
   … framing
   … need inputs/proposals from the Discovery TF
   … then ITU-T liaison
   … that is not really an Architecture topic but a Use Case topic
   … (put "ITU-T liaison" at the beginning of March 22 agenda)

   Lagally: (puts the ITU-T use case summary MD to the agenda)

   [13]ITU-T use case summary

     [13] https://github.com/w3c/wot-usecases/blob/main/CONTRIBUTIONS/ITU-T-Use-case-summary.md

   Lagally: (and then put "30 mins" for the use cases session)
   … (also "2h 20mins" to the architecture session)
   … there are many architecture issues on GitHub
   … 40 issues including the ones labeled with "terminology",
   "lifecycle", "discovery", etc.
   … let's talk about discovery issues and accessibility issues
   … (adds links for those issues to the agenda)

   Lagally: (categorizes the agenda topics into "Discovery",
   Accessibility" and "Optional")
   … (puts "10mins" to each sub sections of "Terminology",
   "Discovery" and "Accessibility")

   Kaz: wondering if "10mins" for each topic would be really
   enough...

   yeah, e.g., "partial TD" would take longer

   Kaz: yeah, possibly

   Mizushima: btw, maybe we should check the diff between the FPWD
   and the current draft?

   Kaz: maybe that could be summarized during the introduction
   session at the beginning

   Lagally: yeah, would include that point into the introduction
   … regarding the time assignment, would give 20mins for
   Discovery collaboration

   how many issues are there for "Terminology"?

   (12 terminology issues there)

   [14]terminology issues

     [14] https://github.com/w3c/wot-architecture/labels/terminology

   [15]and PR 582 - WIP: Terminology update

     [15] https://github.com/w3c/wot-architecture/pull/582

   Lagally: (adds edits for the Profile session)
   … device categolies and use cases
   … canonicalization

   decision: one or multiple profiles?
   … proposed constraints
   … (and assign some initial time to each topic)

   [16]updated agenda for March 22

     [16] https://www.w3.org/WoT/IG/wiki/F2F_meeting,_March_2021#Monday_March_22

   [adjourned]


    Minutes manually created (not a transcript), formatted by
    [17]scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).

     [17] https://w3c.github.io/scribe2/scribedoc.html

Received on Wednesday, 5 May 2021 07:24:53 UTC