Consider adding "poll hook" to registration (pull keepalive)

[mmccool]

Assuming we add the TTL/expiry, it is the registering Thing's responsibility to update the TD in the directory before it expires. In other cases it might be useful for the directory to attempt to retrieve an updated TD automatically (and extend the expiry if it is successful).

Basically what I'm thinking is that a device can register a TD along with a "pollURL" and "pollInterval" attribute. The first is a location from which a TD can be retrieved, the second is how often (this value should be less than the expiry interval).

To discuss:

• How to handle security. The directory needs to have access rights to retrieve the TD. I can think of various ways to solve this (such as the Thing providing a bearer token or API key), but how to include it in registration? This is related (perhaps) to event subscription mechanisms (webhooks).
• We need to clarify the relationship between expiry time, poll interval, and expiry renewal interval. Is an expiry AT a certain time, or a certain interval after the last update/registration?

[farshidtz]

The webhook could work only if the directory has networking access to such endpoints. In IoT environments, the devices are often behind firewalls that don't allow incoming connections.

We should probably look into other protocols and for simplicity, decouple it from the directory. E.g. using MQTT, a client could listen to heartbeats from devices (sent to a broker) and update the respective registrations in the directory.

[mmccool]

Two (related?) issues:

• Updating the TD
• Knowing when a Thing is accessible (or not) - heartbeat
  • Regarding MQTT, there is the issue of there being more than one way to do a heartbeat
  • Do we provide metadata on "how to do a heartbeat"?
  • Regardless, "updating" the TD seems like overkill for the heartbeat

Related to (a solution to) #464

[mmccool]

Note that the current spec already has a way to do an "empty" TD update to extend the TTL; this is the current HTTP-based mechanism for a heartbeat update. But maybe it is too complicated and we need another (simpler) API entry point to for a Thing to "check in"? Also it would be nice to easily check if a Thing is available. Right now this can be done by pulling the TD and checking the expiry and last updated times but that seems overly expensive. Perhaps a special "query filter?"

Also - the "modified" time is a bit ambiguous. If an empty patch is done for an update, does this change the "modified" time or not? What if only the TTL changes but not the rest of the TD - is that a modification? The document is not clear on this point, it only says the "expiry" time is updated on an empty patch. At least a clarification is needed, and/or a new piece of metadata to record "last heartbeat".

[egekorkan]

In some protocols, there can be defined ways to do heartbeat.

Regarding MQTT, there is the issue of there being more than one way to do a heartbeat

In Sparkplug (built on top of MQTT), there is a birth message concept and each time a node becomes online, it sends a list of topics it is going to publish, which is for me a dumbed down version of a TD with MQTT binding.

[farshidtz]

I think MQTT features such as retained messages (last message per topic persisted on the broker) and last will and testament (LWT) (a predefined message that broker publishes on behalf of the client on disconnection) are very helpful for realizing such functionality. The retained messages enable the directory to get the latest information even if the directory has been offline during the update. The LWT, makes it easy to know as soon as devices go offline.