Define how subscriptions are unique in the hub and can be overwritten by subsequent re-subscribes

[GoogleCodeExporter]

From conversation with Jay:

>     This is undefined in the spec.  How should a hub handle multiple
subscription requests to the same topic by a single endpoint with different
hub.secret values?  (Since this is the only persistent option.)
>
>     Should it be allowed, rejected or should the new request overwrite
the existing subscription?
>
>     A properly configured subscriber shouldn't ever do this, but imagine
a situation where DB corruption causes the loss of subscription information
and they begin resubscribing to everything.  The invalid subscription would
be picked up by subscription-refreshing, but until that time (which could
be days, or weeks later)... what's the desired behavior?

Great question. I'd argue that the tuple (topic, callback) is unique and
will overwrite any existing subscription regardless of its verify_token or
secret. This is how the reference hub is implemented. The spec should
properly define this.

Original issue reported on code.google.com by bslatkin on 19 Oct 2009 at 1:23

[GoogleCodeExporter]

I think this part is covered by this from the spec:

"Hubs MUST allow subscribers to re-request subscriptions that are already 
activate. 
Each subsequent request to a hub to subscribe or unsubscribe MUST override the 
previous subscription state for a specific topic URL and callback URL. Any 
failures to 
confirm the subscription action MUST leave the subscription state unchanged. 
This is 
required so subscribers can renew their subscriptions before the lease seconds 
period is over without any interruption. "

However, this text was in a really confusing place. I've moved it into section 
6.1

Original comment by bslatkin on 9 Feb 2010 at 12:20

• Changed state: WontFix