-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/2/09 8:06 AM, Robin Collier wrote: > > >> From: [email protected] >> To: [email protected] >> Date: Thu, 2 Jul 2009 09:35:57 -0400 >> Subject: Re: [PubSub] Subscription feature request >> >> On 2-Jul-2009, at 09:14, Ralph Meijer wrote: >> >> > This implies that each subscription, identified by a SubID, has a >> > unique >> > configuration. In turn this means that you can only create more than >> > one >> > subscription if you do subscribe+options on the subscribe attempt. >> > Also, >> > it implies that if you do subscribe+options and that would result in a >> > subscription with the same properties as one that already exists, the >> > service should return that already-existing subscription instead of >> > creating a new one. >> >> The spec actually used to be explicit about this, as I recall. I >> can't remember whether it was XEP-0060 or 0248, but one of them >> mentioned that subs should be reused if the options haven't changed. I >> can no longer find that requirement. I do agree that the same options >> should generate the same subscription, but I disagree that it's >> implied in the above. >> >> That said, I think there are edge cases where this breaks down >> anyway: what do you do in a subscription lease scenario? Every new >> subscribe+options request will probably have a different pubsub#expire >> value, thus generating a new subscription. >> >> Adding a `jid' attribute to the result of retrieve-subscriptions >> makes a lot of sense to me. For one thing, it's effectively a mirror >> of the subscription request itself, and for another there are cases >> where you will need to know the JID before attempting to update or re- >> use a subscription. For instance, I have an application that requires >> subscription by full JID to ensure proper delivery of events. It could >> be in use in many places at the same time, potentially with different >> options. When my client crashes and restarts it must check its >> existing subscriptions and update their options as appropriate. I do >> not want one client to step on the toes of another, updating its >> subscription underfoot, but as it stands I can't prevent it because I >> cannot determine which client has which subscription. >> >> I cannot simply rely on idempotency because I actually do use >> pubsub#expire, and any completely new subscription request will have a >> different expire value, thus generating a new subscription. >> >> > The above supports my statement that subscription requests are >> > idem-potent. If you don't agree with my interpretation of XEP-0060, >> > than >> > the specification needs adjustment (either in your or my favour). If >> > instead you find that the service implementation you use behaves >> > differently, than that's a bug. >> >> Unfortunately, I happen to have written that "bug" into ejabberd >> recently based on my reading of the current XEP. I, personally, was >> grateful that the wording about idempotency had been removed, because >> that requirement would have made my life somewhat more difficult. Not >> that it would be a bad thing, it's just more of a pain to implement. >> Plus, it wouldn't have fixed the issue above anyway. >> > > The same 'bug' is in OpenFire as well. It will allow multiple subscriptions > for the same JID with not options, which is what led me to my original > request. > > The spec should be explicit about this, as it is not currently. I have to > disagree that it currently implies idempotency, and the fact that this is > being argued amongst several people, and several server implementation > do not implement it this way, shows that it is open to interpretation.
Suggested text would be appreciated. :) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqxaPMACgkQNL8k5A2w/vyIBACguAmkAfOAhXiSI8pHPufjEmrh mewAoN1PZz+b1d9YMYo/MMWRTNsTEhEX =CKci -----END PGP SIGNATURE-----
