Meeting minutes
(scribes so far: Ege, Kaz, Daniel, Sebastian and McCool; Cristiano, Philipp, and Kaz for today)
Guest
McCool: we have a guest from ITU-T, Gyu Myoung Lee
McCool: skipping the opening slides, guest are notified with the w3c normatives
<kaz> W3C Patent Policy
Agenda for today
<kaz> Agenda wiki
Lagally: I'm really happy to have participants from ITU-T. Important for our work in wot use cases
Lagally: we should look if there are any gaps in our use case document thanks to the input of ITU-T
Lagally: please observe the queue
Lagally: open discussion about alignment between w3c WoT and ITU followed by architecture implications of ITU-T hub
… should we add anything to the agenda?
… ok
Use Cases - ITU-T
Lagally shows a document that contains a review of ITU-T standards.
<kaz> i|Results of ITU-T SG20 WoT document analysis|
McCool: I focused on framework of the web of things document and the ITU-T WoT service architecture
… main question what is an object?
… hub is referred as broker in the document
… we don't emphasize hubs in our documents. I think we should
… the describes abstract functions that could be mapped to hardware in different ways.
… services are categorized in WoT, Web, and Mash-ups. We don't underlying this differences.
Lagally: you mentioned that ITU-T needs a register service
… currently the WoT discovery is work in progress
… will we have still this gap when WoT discovery is defined?
McCool: well, ITU-T needs the registry at the architectural level.
… discovery is just finding TDs not register them
… and surely not how to manage them
… it is intentionally out of scope in WoT discovery.
Lagally: about he second bullet in your document. is deployement of Scripting API out of scope too?
McCool: well similarly to the previous point.
… it is a gap in the spec really
… like how to provious security parameters (e.g., keys etc.)
Lagally: do we plan future specification of ITU-T document
Gyu_Myoung: yes it is possible in two ways. Small clarification or starting a new process.
Lagally: do you think there is interest to align with WoT specification?
Gyu_Myoung: we did not use Thing Description to describe our services
Lagally: do you mean to create a mapping document between ITU-T and TD ?
… what do you need from w3c side?
Gyu_Myoung: possibly an expert from w3c side and discuss conjunctly an analyses of the two standards.
Lagally: do you have already someone in mind?
Gyu_Myoung: we contacted individual editors and experts
Lagally: ok
… we'll discuss this topic further in the main call.
McCool: from our side there are some missing pieces that we would like to add. possibly at the end of the year we could create a new charter dedicated to them
Kaz: I would start from concrete scenario based on some concrete use case and idendify the building blocks (within the Architecture spec) or entities (within the existing implementations). Then we could understand which piece within the system or subsystems could be mapped to the building blocks from the W3C Architecture..
<kaz> (my point is not generating yet another use case but clarifying the concrete scenario and data transfer, etc., for the existing use cases related to the external standards :)
Lagally: we already have a couple of use cases defined
McCool: echonet and ITU-T WoT look more into smart homes use cases
… having real system is a good place to drive requirements.
Lagally: we should have a follow up conversation
McCool: I suggest also to review the document and check if we have misunderstood something.
Lagally: what about scheduling a call in three weeks from now
… so that we can have a good plan
McCool: it could work, maybe defining homework by email would help
Lagally: let's try to target the week of April 12
McCool: it is probably fine
Lagally: ok let's create a doodle pool to the define the right timing.
Lagally: ok we completed two points of the agenda. Point three could be moved in the next call
<kaz> agree with McCool, and think we should clarify which entity within the use case scenario does what (possibly with some restriction). The entities should include edge devices as Things, gateways as Intermediaries and applications as Consumers
Kaz: which entity in the use case detail is the most important?
… we should state it for each use-case
Action: kaz to create a doodle for the next liaison discussion around April 12
Architecture
Lagally going through the agenda items
Lagally: Any other input for the agenda?
McCool: Can we add Hub vs. P2P? Reason for this is the constrained devices topic.
Lagally adds it to the agenda
Introduction
Lagally starts with the introduction for the newcomers.
<kaz> WoT Architecture 1.1 - Working Repository
<kaz> WoT Architecture 1.1 Editor's draft
Lagally: We have a couple Todos in the document. So, be aware that we are still working on that.
Lagally: We have been focusing on profiles in the recent architecture calls.
Lagally: We have introduced the thing model.
Lagally: There are also several editor notes.
McCool: It probably makes sense to refer to the other documents, so we don't risk contradicting information.
McCool: There is a secion Core profiles, that name should be just profiles.
Lagally: We will have discussions about it and may change it.
McCool: We should introduce another section called architectual pattern or something like that.
<kaz> https://
Lagally: I tried to change our policy a bit.
(Sebastian joins)
Lagally: bf, can I add you to this issue?
Ben: I prefer not to. I don't agree with the specification. I think it shouldn't exist.
<kaz> 10 Example WoT Deployments
<kaz> clarification on network topology, etc., would be useful for liaison discussion, etc.. However, I think
Kaz: I think it doesn't have to be the normative architecture design, but could be part of the deployment scenario section.
Lagally adds a new issue for the architectual pattern topic
Terminology
<kaz> Terminology issues
Lagally: All topics have owners and mm already addressed a lot of topics. Thanks for that.
McCool: My PR solves 3 or 4 of those issues.
New terminology for the Binding document?
Lagally: I would advocate to add it to the terminolgy section.
McCool: Also discovery. I think it is a core thing.
McCool: One question. Are those terms defined in other documents as well?
McCool: Should we redefine them or just refer to TD 1.1?
Ege: The idea is to remove the td context extension.
Lagally: Let's create an issue for it.
Sebastian: You can also add the thing model description.
Sebastian: We should have a single definition.
Lagally: I think we already spent some time to define the thing model in the architecture.
Sebastian: We should check, if it is the same as in the TD document.
Lagally creates an issue for it
Lagally: TD Fragment and partial TD
Lagally: We discussed this and added it to the document.
McCool: I don't disagree with the definition. To be aligned with the JSON specification we should name it JSON element.
Lagally: I think we already discussed this topic.
McCool: I don't think it is the end of the world, it would just be more align with the JSON specification.
Lagally: Have you dealt with the system terminology?
McCool: I haven't yet. It isn't in my PR yet, but I want to take a look into it.
<kaz> PR 582 - WIP: Terminology update
McCool: I want to solve as many terminology issues in my PR as possible. At least the non contriversal ones.
Lagally: It would be good to not introduce new terms.
McCool: You are right, some might be contriversal.
Lagally: I am not comfortable with TD Fragment to TD Element.
Lagally: Please take it out and introduce another PR for it.
McCool: Okay, will do.
McCool: We also need to cleanup the confusion with Thing description and Thing description directory.
Lagally: We should have an additional call about this.
<mjk> Digital Twin usually includes modeling of the physical system
<kaz> Issue 530 - Incorporate Discovery terminology into terminology section
<kaz> Issue 581 - Consolidate usage of gateway, edge and hub
(Philippe Coval on IRC wonders about modeling Digital Twins)
(Kaz gives clarification to Phiippe that we're currently talking about terminology for including "Digital Twins" but not discussing "Digital Twins" itself. Also suggests we have a separate discussion on Digital Twins during the oridinary WoT Architecture call after the vF2F, and we can invite Philippe to that call.)
(Lagally agrees and Ben transfers that to Philippe on IRC)
McCool: I added a definition for edge device. We probably have to review them.
<kaz> going back to PR 582 again
Lagally added a comment to the PR
<kaz> PR 583 - fix a typo
Lagally: It is just a simple typo. I really would like to merge it.
McCool: Don't let get into the IPR thing and just change it ourself.
Kaz: can merge it after marking it "editorial" using the Repository Manager, if it's really editorial
Lagally: (agrees)
PR 583 merged after marked as editorial
Accessibility
Lagally: This was a topic from the APA meeting.
McCool: I think there is a wider review process.
McCool: I think when we get a more solid specification, we should request a review.
other spec contributions
McCool: As part of IETF, there is a new draft, but I think we might want to take a look into it.
system lifecycle with registration
<McCool> the IETF draft on onboarding and boostrapping: https://
security considerations
Lagally: Do we need to do anything here?
McCool: I created a section for this. Should we put it into the main architecture document?
Lagally: We have a security and privacy considerations section in the specification.
<kaz> [5min break; then Profile discussion]
WoT Profile
Lagally: (shows the agenda slide)
… Introduction
… device categories
… constraints
… canonicalization
… discussion on one/multiple profiles
… review/discussion of FPWD feedback
Lagally: anything else?
McCool: should start with the scope of "WoT Profile"
… wouldn't take too much
… related to the topic on one profile or multiple profiles
Lagally: ok
Lagally: (adds "scope of WoT Profiles" to the agenda for today)
McCool: should have discussion on that first
Lagally: ok
Sebastian: would see that we have consensus about "Profile"
… would like to keep it simple
McCool: yeah, that's why wanted to put it as the first topic
WG Charter
Lagally: (explains excerpts from the WoT WG Charter)
McCool: want to say "implementations" here means "finite implementability - a developer needs to know in advance the set of technologies they need to include in their implementation, and this must be a finite set"
… please don't assume context means "vertical"
Sebastian: each IoT product also has this
… not really see if we want to have "Plug-n-Play"
… what if we have no clue on semantics
… we can also narrow the scope to communication, etc.
Lagally: semantic interoperability and semantic PnP would be nice
McCool: actually, the Charter description implies "more than one" profile
Lagally: ok
… we have three profile use cases
<McCool> McCool: just want to point out the charter uses "profiles" in the plural and implicitly assumes there may be more than one
Lagally: Use case: multi-vendor system integration out of the box interoperability
5.2 Multi-Vendor System Integration - Out of the box interoperability
Lagally: as a device owner, developer, cloud provider, ...
… the model here is multiple vendors adapt to a standard
… this should be possible without device-specific customization
… Use Case: Cross Protocol Interworking
5.4 Cross Protocol Interworking
Lagally: examples in smart home, smart city, ...
-> Use Case: Digital Twin
Lagally: Conclusion in the Architecture call on 21 Jan. 2021
https://
McCool: we should focus on use cases
… some of them apply WoT in general
… within certain use case, some specific protocol would be applied
… a use case for that purpose is digital twin
… let's just focus on the context first
Lagally: ok
Sebastian: have problem with the use cases for profile discussion
Lagally: let's do some simulation for TD then
… we have to make some basic assumption
Sebastian: don't see the description yet
McCool: digital could apply all the WoT
… digital twin is one context
… we should clarify what context to be used
… the constraints applied to everywhere should be included in the basic specifications, not in a profile that only applies to one context
Kaz: would repeat my point for liaison discussion here :) @@@
Lagally: that's related to device capability
… would see profile requirements with more than supporter
Lagally: interoperability, limit and reduce complexity, ambiguities, ...
McCool: some of them might be "nice to have"
… should clarify our actual requirements
<McCool> McCool: some of these are absolute requirement, some are nice-to-haves, some belong in general goals for WoT (eg. eliminate ambiguity)
McCool: would like to describe the issue on the goals and scope
McCool: (goes through the issue 73)
… we need to think about the context and narrow the scope
… we also should pick up one specific profile
… and would like to propose we start with the hub concept
… we don't worry about P2P interoperability
… having narrower scope would mean we would have more concrete answers
… limited to what we have experience
… let's talk about narrowing the context
… and let's pick one
Lagally: tx for creating this issue 73, first
[[
Assume the hub has a relatively large memory capacity and capability for consuming Thing Descriptions.
Assume endpoints will not, themselves, consume Thing Descriptions.
]]
McCool: we can have a Hub as a Consumer
Ben: tx from me as well
… "hub" as the first profile proposed by McCool here
… included in the Mozilla's Member submission
… but what I want to have is concrete description how to communicate with devices
Lagally: gateway also could have some restriction
… how to handle big TDs in that case?
Ben: actual size of TD should be relevant for housekeeping
Lagally: what do you guarantee how big TD can be handled?
… can safely reject the TD?
… what would happen otherwise?
Ben: you don't have "maximum size" for Web pages. right?
… don't see difference with WoT from that viewpoint
(some more discussions on possible use case settings)
McCool: I used terms of "endpoint" and "hub"
… we assume "consumer" is relatively bigger
Ben: agree
<McCool> McCool: think we should just define "context" as "a set of assumptions"
Cristiano: concern on using a generic concept at the protocol level
… maybe would be better to narrow the scope
Lagally: what kind of payload to be handled could be additional constraints
Sebastian: this is not a real argument
… want to agree with McCool here except concentrating on HTTP, CoAP and MQTT
Lagally: should work on websocket as well?
Sebastian: another possible future protocol as well
… no restriction on possible protocol to be mentioned here
… maybe Ben can work on draft text for that
Ben: can work on it
Lagally: what is the fundamental problem then?
Sebastian: would propose separating the document into (1) technology with HTTP+JSON and (2) others
Lagally: (goes through the section 4)
Ben: would suggest we remove the profile section and concentrate on the protocol binding section
Lagally: protocol binding within the WoT Profile draft is just a placeholder at the moment
Lagally: creating a profile for HTTP+JSON would be helpful, though
… the goal of TD is defining the datamodel
Ben: but the current description withing the "WoT Core Data Model" would add complicity
McCool: main issue is the motivation
… and what is the accomplishment
… need to be clear about what to accomplish
… we need a documentation for developers
… all we need is narrow scope and concrete description
… maybe we could generate a draft using MD and see which part to be applied to the WoT Profile draft
Philipp: I have a hard time to understand why we use outdated protocols. I think we should focus on the current specification of protocols. If we are going with HTTP, it probably makes sense to go with HTTP2 or 3.
<McCool> McCool: let's focus on things for now that we have direct experience with and a clear set of needs
<McCool> ... again, something concrete that we can "get in the can"
<McCool> ... however, I agree with Philipp, there is a need to have an "constrained" focused-profile that perhaps deals with these issues... but we can defer, and I think we have to
Kaz: basically agree with McCool, and would repeat we should clarify our expectations on which entity (Thing, Intermediary or Consumer) does what and has what kind of restriction based on some concrete use case and then clarify our requirements. and then we can see what kind of profile is needed.
Sebastian: still need the definition on what "core" means
Sebastian: we don't to keep less information within TD rather than big text data
… we should keep out a concept of "core" profile
… though could think about some "generic" information
… all the specific profile to be handled separately
<Zakim> dape, you wanted to limiting *known* terms/constructs might not help in all cases
Daniel: there are several layers
… quite crucial to have initial setup
… limiting known terms/constructs would not work in some cases
<citrullin> +1 as well, no one guarantees that people will not exceed it. Also there are still different protocols. The market will eventually find a common ground and some protocols will win, other not.
McCool: we still have different opinions on Profiles
… need to resolve a lot of things to move forward
… we need a follow-up discussion during the regular Profile discussion
… let's start with one specific profile first
Lagally: ok
… agree this direction on issue 73 is right one
… please create Merge Request if you think any part of the current draft is not appropriate
… let's continue the discussion during the next Architecture/Profile calls
Next meeting
McCool: on Wednesday March 24
Note on how to proceed
Kaz: please note that creating actual PRs for Profile discussion before getting consensus wouldn't make sense
… creating issues would be fine, though
McCool: ok
… let's start with my issue 73 then
[adjourned]