On Thu, Mar 5, 2009 at 5:37 PM, Pedro Melo <[email protected]> wrote: > Hi, > > On Feb 28, 2009, at 10:18 AM, Waqas Hussain wrote: >> >> On Thu, Feb 26, 2009 at 9:32 AM, Pedro Melo <[email protected]> wrote: >>> >>> On Feb 25, 2009, at 7:36 PM, Pavel Simerda wrote: >>>> >>>> On Tue, 24 Feb 2009 15:54:38 +0000 >>>> Pedro Melo <[email protected]> wrote: >>>> >>>>> Hi, >>>>> >>>>> On Feb 24, 2009, at 12:49 AM, Pavel Simerda wrote: >>>>> >>>>>> There are several cases when subscription databases in XMPP are >>>>>> inconsistent. >>>>>> >>>>>> You may view subscription information as a global distributed >>>>>> database. >>>>>> Subscription state between two JIDs, for example a...@a and b...@b are >>>>>> stored >>>>>> in two places at the same time. Servers A and B maintain their own >>>>>> copies of subscription state. >>>>> >>>>> [....] >>>>> >>>>>> What with the roster items that are inconsistent? >>>>>> >>>>>> * Mark as inconsistent, let the client present it to the user to >>>>>> take action. >>>>>> >>>>>> * Auto-repair and thus maintain consistency >>>>>> >>>>>> Looking forward to all feedback. >>>>> >>>>> When you send out a <presence type="probe" /> include the local >>>>> "view" of the subscription state. >>>> >>>> Btw presence probe seems too weak... as it doesn't reveal full >>>> subscription state. >>> >>> that's what I'm saying: include the full subscription state in the >>> presence >>> probe so that the other side can detect mis-matches. >>> >>> Best regards, >>> >>> >> >> I'm considering doing this in Prosody: >> <presence type="probe" from="[email protected]" >> to="[email protected]"><item subscription="both"/></presence> > > Don't know if you should also include the ask-out/ask-in flag. Also original > request <status>. > > I would, but I admit not having done some serious thinking on the > implications. It *seems* ok. > > >> What action is appropriate is open for debate. What should the >> resulting state be? The lowest common permissions (possibly sending >> unsubscribe[d] to the contact or changing the user's subscription for >> contact)? The highest common permissions (possibly sending a >> subscrive[d] to the contact and changing the user's subscription for >> the contact)? > > Highest common permissions, maybe. I've started a table below for some > cases, and I have some doubts. Should we upgrade the Receiver subscription > to a better state? For example: if you have a To subscription to me and I > have a None to you, should I be upgraded to a From? Not sure yet. It can be > used for presence spam. A more careful approach would send a unsubscribe. > > And we need to look this in the other direction. If the Receiver is 'To' or > 'Both' and the other side is 'None' or 'To', should we send a 'subscribed'? > It makes sense for the Receiver, but from the POV of the Sender, you are > modifying my own subscription status, upgrading it. > > I wrote the following table of what I think are the most safe transactions: > none of the subscriptions are "upgraded" in any way. > > (note: for each "Recv resets to 'X'" it is implied that a roster push would > be sent to all connected resources) > > Sender: none > Recv: to > > => Recv resets to 'none' > > > Sender: none > Recv: from > > => Recv resets to 'none' > > > Sender: none > Recv: Both > > => Recv resets to 'none' > > > Sender: To > Recv: none > > => Recv sends 'unsubscribe' > > > Sender: To > Recv: To > > => Recv resets to 'none', sends 'unsubscribe' > > > Sender: To > Recv: Both > > => Recv resets to 'From' > > > Sender: From > Recv: none > > => Recv sends 'unsubscribed' > > > Sender: From > Recv: From > > => Recv resets to 'none', sends 'unsubscribed' > > > Sender: From > Recv: Both > > => Recv resets to 'To' > > > Sender: Both > Recv: none > > => Recv sends 'unsubscribe' and 'unsubscribed' > > > Sender: From > Recv: From > > => Recv resets to 'none', sends 'unsubscribed' > > > Sender: From > Recv: Both > > => Recv resets to 'To' > > >> From an IM user's point of view, trying to settle on the highest >> common permissions seems more appropriate (and less confusing). > > Well, the fact that we have asymmetrical states is a source of some > confusion. If you want to eliminate that, then you should have 'none' and > 'both' only. > > But asymmetrical presences are very useful on some IM scenarios, like > transports. > > Best regards, > -- > Pedro Melo > Blog: http://www.simplicidade.org/notes/ > XMPP ID: [email protected] > Use XMPP! > > >
The table is what I had in mind. "highest common permissions" wasn't the best of phrases to use. What I was thinking of was sending presence subscribe. This wouldn't be appropriate with the current presence information available to servers (i.e., someone removed me, and my server didn't realize, then my server shouldn't resubscribe automatically). But suppose we add a timestamp for every subscription (last change), then if a server sees that it has newer information (local timestamp for subscription is newer than remote timestamp received in probe), then the server can send a subscribe automatically (this is in addition to the transaction from the table you specified). This still doesn't solve everything though. -- Waqas Hussain
