[Standards] Inconsistent Subscriptions in XMPP
waqas20 at gmail.com
Sat Feb 28 10:18:38 UTC 2009
On Thu, Feb 26, 2009 at 9:32 AM, Pedro Melo <melo at simplicidade.org> wrote:
> On Feb 25, 2009, at 7:36 PM, Pavel Simerda wrote:
>> On Tue, 24 Feb 2009 15:54:38 +0000
>> Pedro Melo <melo at simplicidade.org> wrote:
>>> On Feb 24, 2009, at 12:49 AM, Pavel Simerda wrote:
>>>> There are several cases when subscription databases in XMPP are
>>>> You may view subscription information as a global distributed
>>>> Subscription state between two JIDs, for example a at A and b at B are
>>>> 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="me at myhost.com"
to="you at yourhost.com"><item subscription="both"/></presence>
It wouldn't break anything. I don't see any privacy issues. And it
would give the receiving server a chance to detect any inconsistency.
If there is an inconsistency, the receiving server can take an
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
>From an IM user's point of view, trying to settle on the highest
common permissions seems more appropriate (and less confusing).
More information about the Standards