jacob1044 / pubsubhubbub

Automatically exported from code.google.com/p/pubsubhubbub
Other
1 stars 0 forks source link

Clarify meaning of hub.lease_seconds in subscribe/unsubscribe verification requests #130

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
SUMMARY:

The text which defines the meaning of the hub.lease_seconds parameter in an 
subscribe/unsubscribe verification request should be clarified with respect to 
verification of initial subscribe/unsubscribe requests, not only auto-refresh 
requests.

RELEVANT SECTION: 

6.2.

COMMENT/REQUEST:

Currently, the spec says (6.2. - Hub Verifies Intent of the Subscriber):

"hub.lease_seconds - REQUIRED/OPTIONAL. The hub-determined number of seconds 
that the subscription will stay active before expiring, measured from the time 
the verification request was made from the hub to the subscriber."

This explanation makes sense only for auto-refresh verification requests, but 
not for verification requests of initial subscribe/unsubscribe requests. 
Specifically, if a verification of the initial subscription is being conducted, 
measuring lease_seconds from the moment that the hub made the verification 
request doesn't make sense because the subscription should last lease_seconds, 
not lease_seconds - (timestamp_of_hub_receiving_verification_response -  
timestamp_of_hub_sending_verification_request). The current wording is fine 
with respect to autorefresh since the subscription is already active, but not 
for not-yet-active subscriptions for which the lease_seconds timer has not been 
started yet.

I think that the explanation of the lease_seconds parameter should be explained 
with respect to these two cases: a) initial subscription verification and b) 
autorefresh. For a), the spec should state that the meaning of the 
lease_seconds parameter is the amount of time for which the subscription will 
be active when the hub receives the verification response from the client. For 
b), the current explanation may be used.

Original issue reported on code.google.com by izuzak on 3 Apr 2011 at 7:43

GoogleCodeExporter commented 9 years ago
Won't fix since the benefits seem too marginal to warrant complicating the 
protocol specification. Feel free to reopen if you feel strongly about this. 

Original comment by the...@google.com on 26 Mar 2015 at 4:36