lease_seconds MUST is over-specified

[azaroth42]

At the end of 4.3.1 is the statement:

Hubs MUST enfore [sic] lease expirations, and MUST NOT issue perpetual lease durations.

This seems overly restrictive and unenforceable. The hub can issue a lease for MAX_INT seconds and be compliant, thereby ignoring the subscriber's request and having a "limited" lease duration that it never needs to expire. This is allowed by:

Hubs MAY make the hub.lease_seconds equal to the value the subscriber passed in their subscription request but MAY change the value depending on the hub's policies.

I suggest simply removing the requirement, making the implementations easier when perpetual leases are desirable.

[dissolve]

When would perpetual leases be desirable? I can't really see any good reason. Returning MAX_INT is possible, sure, but the hub implementor would probably learn to regret that choice.

Removing the requirement that the lease actually expire would necessitate the removal of "MUST supply [hub.lease_seconds] for subscription requests" from 5.3 which would probably break all existing subscriber implementations.

[azaroth42]

How about ... As a search engine / aggregation manager, I want to subscribe to changes to high quality content indefinitely, so that I don't need to track expiring leases for millions of systems.

For example, Europeana provides access to millions of cultural heritage resources hosted by organizations around the EU. Many of those organizations have been around for hundreds of years. Why MUST the aggregator manage millions of lease expirations (remember one-resource-one-subscription) when there's no desire to stop aggregating the content in the lifetime of the aggregator?

[aaronpk]

It's more a question of the hub making sure that subscribers are "active". Subscribers can always renew their subscriptions as often as they want, and this can happen entirely behind the scenes with no user involvement. As an implementer of a hub, I would much rather reduce the potential for delivering dud notifications to subscribers who forgot about the subscription or to domains that have expired, etc.

[azaroth42]

That seems to be covered in the following:

Hubs SHOULD retry notifications up to self-imposed limits on the number of times and the overall time period to retry. When the failing delivery exceeds the hub's limits, the hub terminates the subscription.

I'm not saying get rid of leases completely, just don't make them mandatory for everyone.

[aaronpk]

Since there is no mechanism to acknowledge the successful delivery of a notification other than an HTTP 200 response, it would seem very likely that in the long term, it's entirely possible for someone to break a subscriber (removed the subscriber code, or the domain expires and a squatter sets up a site in its place), that would return HTTP 200 for the delivery request. The hub would have no indication that this subscriber is effectively dead, and these notifications are being delivered unnecessarily.

Again, as someone who has implemented a hub, I am not comfortable issuing non-expiring leases for this reason. I imagine others who have implemented hubs would feel similarly.

The goal of having this requirement in the spec is to ensure that subscribers set up mechanisms to automatically renew subscriptions and don't get in the habit of being "lazy" and setting up the subscription one time and forgetting about it.

[dissolve]

As a search engine / aggregation manager, I want to subscribe to changes to high quality content indefinitely, so that I don't need to track expiring leases for millions of systems.

This example doesn't make any sense really, the hubs can always enforce any lease they want, they don't have to (and shouldn't need to) respect requested least times. Leases of MAX INT if they have a shorter policy for example. This really only matters for hubs as subscribers will ALWAYS have to manage expiring leases, unless you completely get rid of leases.

[julien51]

Like @aaronpk, as somebody who has/had to deal with never expiring lease, I am one of these people who have learned to regret that choice (to quote @dissolve)

The subscription process is actually very cheap.

Having leases has a lot of benefits:

• garbage collections: URL/resources die... the hub has no way to stop caring about them and subscriber do even 'forget' about the subscription if they never receive content (which is what's happening when the resource dies)
• security: expiring leases forces the subscriber to resubscribe and it is strongly recommended to do so using a new secret. This ensures that if for any reason a secret has been compromised it is only for a short period. It also allows for a change of encryption should the ones used earlier become too weak

Unless you have another very strong reason to not make leases mandatory, please close the issue.

[azaroth42]

WebSub (as per other issues) doesn't work for any of our use cases, so as we're never going to implement, I'll close this issue which is minor in comparison.