Unbounded lease duration
tonyg opened this issue · comments
The specification of 20 Oct 2016 specifies hub.lease_seconds as specifying a finite number of seconds after which a subscription will expire.
Previous PSHB discussion [1] included discussion of a special value indicating a lease of unbounded duration, for use both in requests from subscribing parties and verifications from hubs. Suggestions for a concrete value included 0 and -1; I'd also like to suggest unbounded here. I also recommend that 0 not be considered as an indication of unboundedness, since it already has a reasonable meaning when interpreted as an actual lease duration.
Having an explicit value would help avoid situations where 'random large integers' like 999999 etc. are used in place of a true unbounded value.
[1] e.g. https://groups.google.com/forum/#!msg/pubsubhubbub/q6_ahhn1FpU/uXW8d58BKAkJ
with #20 this problem would go away and simply translate to a subscription resource not signaling a Sunset.
I don't think that's true: not specifying a lease duration is different to specifying an unbounded lease duration, unless that is explicitly given in the spec as the interpretation of an absent lease duration.
For example, not specifying a lease duration could mean "whatever the hub does by default", rather than "unbounded".
The form by which the information is communicated (hub.lease_seconds vs a Sunset header) doesn't change that the spec still needs clarity on a) how to signal unbounded lease duration and b) what (if permitted) an absent lease duration might mean.
I don't think that's true: not specifying a lease duration is different to specifying an unbounded lease duration, unless that is explicitly given in the spec as the interpretation of an absent lease duration.
true. any resource on the web that does not advertise its sunset can disappear at any time.
however, what would be the problem with saying that not asking for hub.lease_seconds is equivalent for an unbounded lease, and the hub responding with not giving hub.lease_seconds or Sunset also is equivalent to such a lease? of course it still can disappear.
if we use #20, a client could find out by HEAD/GET requesting the subscription and if it's 410, then it has disappeared even though it may have been unbounded in theory.
There would be no problem with that: it is one way of a) signalling unbounded lease duration and b) interpreting a missing lease duration.
My preference would be to make unbounded-duration explicit, and to keep the current behaviour of hub.lease_seconds being mandatory in certain places. But having missing-parameter mean unbounded-duration would also work OK.
I am strongly opposed to unbound subscriptions for 2 reasons:
- Garbage collections. Subscribers will go away (nothing is ever permanent on the web!). The hubs should be able to clean the data they store "safely".
- Security: in the context of signatures, we should expect that https and/or the signature mechanism will eventually be "cracked". In that regard it is much safer to have reasonably short leases (30 to 90 days) to make sure that leaked secrets or too weak algorithms can be replaced when renewing subscriptions.
We discussed this with the group during the f2f meeting and came to the conclusion that requiring lease expiration is important.
@tonyg just wanted to double check that you're okay with the outcome of this thread.
Yes, I am. Thank you, Aaron.