Wot-thing-description: Consider defining an expiry date for a TD

[mlagally]

TDs may get outdated and new versions will be available.
It may be important to remind users of TDs about that.
This is also useful for thing directories, there was a corresponding discussion in the discovery TF.
https://github.com/w3c/wot-discovery/issues/18

[egekorkan]

I think it is a good idea. Just for added precision, TTL does not necessarily imply that the TD will change so even if a TD expires and a new one is fetched, the version can still be the same.

[benfrancis]

Is there any reason that Thing Descriptions are different to any other web resource in this respect?

The web already has a solution to this problem. See the HTTP Expires header and the Cache-Control header for finer grained control.

[egekorkan]

I think the goal is to have something inside the TD since the document can be stored in a database and can be consumed by different protocols

[benfrancis]

I think the goal is to have something inside the TD since the document can be stored in a database and can be consumed by different protocols

I strongly recommend against that. Caching is hard to get right at the best of times, without having to worry about ambiguity between the protocol and file format.

I politely suggest resisting the temptation to re-invent features of web protocols with a WoT-specific solution in the name of being "protocol agnostic".

There is nothing to stop a WoT server implementation from storing an expiry date in its database and exposing that in a protocol-specific way, without it being in the Thing Description.

Note that CoAP also has its own caching model.

[sebastiankb]

Are we talking about a new field in the TD model that should have an expiration date? If I understand correctly https://github.com/w3c/wot-discovery/issues/18 will define this outside of the TD, right?

[farshidtz]

Are we talking about a new field in the TD model that should have an expiration date? If I understand correctly w3c/wot-discovery#18 will define this outside of the TD, right?

I believe this issue is about adding a new field inside the TD.

In https://github.com/w3c/wot-discovery/issues/18, we are exploring different options in the absence of such information inside the TD, especially for when the TD is submitted to a directory.

[sebastiankb]

In this case the version container might be the right place:

"version": { "instance": "1.2.1", "expires": "2020-08-23T18:25:43.511Z"}

[farshidtz]

In this case the version container might be the right place:

"version": { "instance": "1.2.1", "expires": "2020-08-23T18:25:43.511Z"}

Doesn't the expires field fit better alongside updated (and created) at the root level of the TD?

• Unversioned TDs may also need an expiry date. But version.instance is mandatory and we can't have just "version": { "expires": "2020-08-23T18:25:43.511Z"}
• A versioned TD's updated field will change when the version is incremented. Following this path, I could argue that updated should be in version too.

[egekorkan]

By the way, this is now in the discovery spec: https://w3c.github.io/wot-discovery/#exploration-directory-registration-info