Meeting minutes
Minutes Review
McCool: (reads through last meeting's minutes)
… actually, this is odd (refers to WoT-JP CG meeting)
… I think we ended up discussing the feedback in discovery, right?
<kaz> Mar-11
Kaz: Yeah, we discussed it in the discovery call
McCool: Let's add a note to the minutes then
… if there are no objections, minutes are approved
No objections, minutes are approved
Plan for Discovery Input
McCool: Would like to talk briefly about the CG stuff
… later want to talk about issues, PRs, and planning, getting stuff done
McCool: I think the most efficient way to deal with discovery input is to elect someone who writes summaries and brings up them in the call
… so I would like to have someone from the WoT JP CG to summarize the discussion and then file issues against the relevant repositories
Kaz: Agree, that's what I also have been asking Ege and Mizushima-San regarding the inter-TF collaboration
McCool: Yeah, and filing issues against the issue eventually would be the way eventually
Kaz: The question is then also whether people should first talk to the UC Taskforce and generate issues from that, or whether they should file issues for each TF directly
… think we need to ask them about their preference and availability for that purpose.
McCool: Both is possible
… filing a bug should be filed against the respective repository
… also depends on whether it is a functional or technical requirement
… first step, however, is to file an issue somewhere, so bring it to the issue tracker in general
… the presentation by Krellian had some relevant use cases regarding filtering and queries
… but that has not been formally written up yet
Kaz: I wouldn't say everyone should have to join every CG meeting
… but we need to clarify the process of how input is being processed
McCool: Exactly, should be discussed in the main call
Issues
DID repo PR 486
<kaz> did-spec-registries PR 486 - Add WotThing and WotDirectory service types
McCool: Unfortunately, this PR is still pending
… open for over a month now
Kaz: Maybe we should send a reminder to them? Or ask them about the status?
McCool: Weirdly, it has been approved already
… (adds a comment asking for the status to the PR)
… this should at least put it to the top of the "recently updated" list
Planning
McCool: Next, I wanted to talk about how we can make actual progress
… I think we have some clearly motivated work items
… would like to clean up the requirements
… I think we should start with cleaning up the issue tracker
Issues
McCool: We have 60 issues open
… should figure out what to do
… two new issues by Ege, which we should prioritize
… we have also two issues regarding ontologies, which I hope we can clean up soon
… we have another one regarding a work item, related to polling
… some other are editorial
… there is also some stuff related to work items which we could cross-reference
Issue 201
<kaz> Issue 201 - Sequence diagrams for DID based discovery approaches
McCool: (Applies the label "editorial" to the issue)
Issue 164
<kaz> Issue 164 - Consider adding "poll hook" to registration (pull keepalive)
McCool: So one general question is how the process of updating TDs should happen
… current design assumes devices will update before the TTL expires
… this issue adds some responsibility to the TDD to ask the device for updates
… problem: devices that are not always online
… second problem: devices might not have a clock
… this is quite an old issue, but we need to discuss and understand polling vs. client-based updates
… if a device is behind a firewall, then we might only want to have a device make the update
… (adds a comment to the issue)
… question also regarding heartbeats, for example, there is more than one way to do this in MQTT
… (adds a link to issue 646 to the comment, which is related)
… I believe our current mechanism for TTL does not require us to update the whole TD
… (looks into the Discovery specification)
… the mechanism to do a heartbeat is to submit an empty PATCH request
… (mentions in the comment that this might too complicated and another API entry point might be needed for a Thing to "check in" and to check if a Thing is available)
… so we have some metadata
… "created", "modified", "expires", "ttl", "retrieved"
… so there is some ambiguity here – if we send an empty PATCH request, should we update the "modified" date?
… I am a bit concerned, that it might be ambiguous whether submitting an update that does not change the TD or only changes the TTL constitutes a modification
… I thonk the document is not clear in this point
… (further expands his comment)
… the spec should clarify that, so any change should update the modified date
Kaz: I agree and started to wonder
… if I update a TTL of a TD and a change impacts all consumers, should all consumers be informed about that? That is a question around notification capability.
McCool: Yeah, I think we had some discussion about that
… and wondered if we should add a notification API for that
… we have an SSE in the document for that, but that is kind of awkward as you need to keep a connection open for that, so a WebHook might be better for that
Kaz: Should be clarified in the 2.0 version, but need some concrete Use Case description too.
McCool: Let me check if there is already an issue for that
… I think this relates to issue 468
… (adds a comment summarizing the discussion to that issue)
… (mentions using MQTT for eventing in the comment)
… has been a relatively recent discussion
… the latest comment is from April of last year
… is a topic of interest, but the answer is not as clear as "picking WebHooks"
… we might not additional mechanisms, like MQTT
… but that makes implementations more complicated and potentially less compatible
… (further expands his comment)
… (mentions that a TD could list the available mechanisms)
… so in the document, we have the Events API
… so currently, we have an event called thingCreated
… so for backward compatibility, we could add additional events for protocols or add additional forms
… in addition to SSE
McCool: I think I should label some of these issues as having a higher priority
… what should the label be called?
… let me also add a link from issue 164 to issue 464
<kaz> Issue 464 - How to keep Thing Descriptions updated in a Directory
McCool: I think there are multiple answers here
… one was that Ben was unsure how to this. In the specification, the TDD is not responsible to do this
… in my original design, I was a thinking about a Registrar who would register TDs with the directory
… that could then be discovered by a discoverer
… (adds a comment to issue 464 with a summary)
… the only problem is that the ""Registrar"" would need to know about which Things are registered, so it would need to act as a proxy, registering devices on their behalf
… need to stop here, as we are out of time, need to figure out which ones relate to work items
… next time, we need to organize better
Kaz: If we really want to introduce a new role like "Registrar", we also need to define this very clearly
McCool: Need to understand the problem more clearly, and understand if we need to introduce a new concept or can reuse an existing one
<kaz> [adjourned]