Re: [Standards] Inconsistent Subscriptions in XMPP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/2/09 2:00 PM, Philipp Hancke wrote: > Peter Saint-Andre wrote: > [snip] >> Yes, I did: >> >> "If the contact does not approve or deny the subscription request within >> some configurable amount of time, the user's server SHOULD resend the >> subscription request to the contact based on an implementation-specific >> algorithm (e.g., whenever a new resource becomes available for the user, >> or after a certain amount of time has elapsed); this helps to recover >> from transient, silent errors that might have occurred in relation to >> the original subscription request." > > What if the contact is "polite" and never replies to the request? > > While the subsequent subscription requests will not be delivered > to the contact (state is pending_in), the user's server has no way > to determine that the request has been processed by the contact's > server. So it will continue to resend the request which is silently > dropped by the contact's server. I don't think you want that ;-) > > Solution: replace presence subscriptions with on s2s. Your "solution" is not backward-compatible. In any case, all discussion of rfc3921bis now needs to occur on the x...@ietf.org list: https://www.ietf.org/mailman/listinfo/xmpp I sent that message only to close out some threads that I had not answered. 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 iEYEARECAAYFAkoliCEACgkQNL8k5A2w/vxUXgCffiBAyFqEjVSr9yooWz9B79iV 0qAAn1Ka4Tx8MtsTKt9/WbDzoT5NDTes =fR/9 -END PGP SIGNATURE-
Re: [Standards] Inconsistent Subscriptions in XMPP
Peter Saint-Andre wrote: [snip] Yes, I did: "If the contact does not approve or deny the subscription request within some configurable amount of time, the user's server SHOULD resend the subscription request to the contact based on an implementation-specific algorithm (e.g., whenever a new resource becomes available for the user, or after a certain amount of time has elapsed); this helps to recover from transient, silent errors that might have occurred in relation to the original subscription request." What if the contact is "polite" and never replies to the request? While the subsequent subscription requests will not be delivered to the contact (state is pending_in), the user's server has no way to determine that the request has been processed by the contact's server. So it will continue to resend the request which is silently dropped by the contact's server. I don't think you want that ;-) Solution: replace presence subscriptions with on s2s. philipp
Re: [Standards] Inconsistent Subscriptions in XMPP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/12/09 1:25 PM, Peter Saint-Andre wrote:
> On 4/12/09 1:20 PM, Mridul Muralidharan wrote:
>>
>> --- On Mon, 13/4/09, Peter Saint-Andre wrote:
>>
>>> From: Peter Saint-Andre Subject: Re:
>>> [Standards] Inconsistent Subscriptions in XMPP To: "XMPP Standards"
>>> Date: Monday, 13 April, 2009, 12:45 AM On
>>> 4/10/09 8:36 PM, Mridul Muralidharan wrote:
>>>> --- On Sat, 11/4/09, Peter Saint-Andre
>>> wrote:
>>>>> From: Peter Saint-Andre
>>> Subject: Re:
>>>>> [Standards] Inconsistent Subscriptions in XMPP To:
>>> "XMPP Standards"
>>>>>
>>> Date: Saturday, 11 April, 2009, 4:04 AM On
>>>>> 4/1/09 12:07 PM, Mridul Muralidharan wrote:
>>>>>> If I recall right, probe can be sent to a full
>>> jid in
>>>>> case a directed
>>>>>> presence was received from it in the past -
>>> and the
>>>>> behavior would be
>>>>>> different (return last presence stanza sent
>>> iirc). Has
>>>>> that behavior
>>>>>> changed or is the description below only for
>>> bare
>>>>> jid's ?
>>>>>
>>>>> You can probe anything you want. :)
>>>> I should have clarified better.
>>>>
>>>> Assume that there is mutual subscription between userA
>>> and userB.
>>>> Support we have :
>>>>
>>>> userA has session us...@domain/resA userB has session
>>>> us...@domain/resB1 userB has session us...@domain/resB2
>>>>
>>>>
>>>> After presence has been exchanged, suppose userA
>>> blocks userB (or all
>>>> users) - so an unavailable presence is sent to userB's
>>> resources.
>>>> Subsequent to that, suppose userA sends available to
>>> one of the
>>>> resources, say - us...@domain/resB1
>>>>
>>>> Now, iirc, if resB2 probes, userA's server must return
>>> unavailable.
>>>
>>> That seems reasonable.
>>>
>>>> But if resB1 probes, userA's server must return the
>>> last directed
>>>> presence sent (subsequent to unavailable).
>>> That also seems reasonable.
>>>
>>>> We could replace userB with muc or any other component
>>> in the above.
>>>
>>> Right. The MUC example is more apropos.
>>>
>>>> IIRC this was a usecase discussed quite a while back -
>>> was it removed
>>>> ? If not, my query was, how does it interact with this
>>> list below
>>>
>>> We had some text about this in rfc3921bis but IIRC we removed it
>>> because people thought it belonged in XEP-0045 (e.g., an
>>> implementation note on "how to remove ghost users"), not the RFC.
>>> However, I think the text never made it to XEP-0045. I'll check on
>>> that.
>>
>> Shouldn't this not be part of the CORE xmpp spec ? Privacy
>> enforcement, routing decisions, presence management happen within the
>> server - and only server has visibility of the user's stanza history
>> to support this imo - so, if required, wouldn't it not be for the
>> server to handle it ? ('it' being responding to probe with previous
>> presence stanza in case of directed presence - or maybe this is
>> already there and I just did not see it ?).
>>
>> A quick search did not reveal much on discussion about this - any
>> overriding reason why this was pulled out ?
>
> People found it confusing and MUC-specific. However, that was for the
> full use case. I do think that rfc3921bis needs to say something about
> answering probes from entities to which you've sent directed presence,
> so that would belong in Section 4.3.2 or Section 4.6.2 of rfc3921bis.
>
> I'll add that to my task list for the RFC revisions.
Done in my working copy.
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
iEYEARECAAYFAkokTKYACgkQNL8k5A2w/vyEvgCdGUh+MxaaxkDCq4G7yA0W6sIP
zgEAn0NOBNaL3GwzQqfhhDv1TtP4+rfG
=8Fni
-END PGP SIGNATURE-
Re: [Standards] Inconsistent Subscriptions in XMPP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/10/09 4:40 PM, Peter Saint-Andre wrote: > On 4/7/09 12:45 AM, Philipp Hancke wrote: >> hijacking the thread... two concrete examples where error handling >> is needed: >> >> subscription state is "none" initially: >> SENT: >> RECV: > type='set'>> subscription='none' jid='f...@bar'/> >> RECV: > id='jcl_37'>> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> >> >> after relogin and roster fetch: >> RECV: > type='result'>> subscription='none' jid='f...@bar'/> >> >> The presence error (which, as can be by looking at the id attribute, >> is a reply to the initial subscribe) does not affect the subscription >> state. > > IMHO the server needs to periodically resend the subscribe to the > contact if the state remains ask="subscribe" (no reply received from the > contact). I'm pretty sure that I added something about this to rfc3921bis. Yes, I did: "If the contact does not approve or deny the subscription request within some configurable amount of time, the user's server SHOULD resend the subscription request to the contact based on an implementation-specific algorithm (e.g., whenever a new resource becomes available for the user, or after a certain amount of time has elapsed); this helps to recover from transient, silent errors that might have occurred in relation to the original subscription request." 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 iEYEARECAAYFAkokS08ACgkQNL8k5A2w/vxOVACcD7AaqnwIxFvi1QBsY3P+tQpv Qg8AoMOvXg+xMBtBpYdtQUtRuy1QyCJo =6Ay1 -END PGP SIGNATURE-
Re: [Standards] Inconsistent Subscriptions in XMPP
On 4/12/09 1:20 PM, Mridul Muralidharan wrote:
>
>
> --- On Mon, 13/4/09, Peter Saint-Andre wrote:
>
>> From: Peter Saint-Andre Subject: Re:
>> [Standards] Inconsistent Subscriptions in XMPP To: "XMPP Standards"
>> Date: Monday, 13 April, 2009, 12:45 AM On
>> 4/10/09 8:36 PM, Mridul Muralidharan wrote:
>>>
>>> --- On Sat, 11/4/09, Peter Saint-Andre
>> wrote:
>>>> From: Peter Saint-Andre
>> Subject: Re:
>>>> [Standards] Inconsistent Subscriptions in XMPP To:
>> "XMPP Standards"
>>>>
>> Date: Saturday, 11 April, 2009, 4:04 AM On
>>>> 4/1/09 12:07 PM, Mridul Muralidharan wrote:
>>>>> If I recall right, probe can be sent to a full
>> jid in
>>>> case a directed
>>>>> presence was received from it in the past -
>> and the
>>>> behavior would be
>>>>> different (return last presence stanza sent
>> iirc). Has
>>>> that behavior
>>>>> changed or is the description below only for
>> bare
>>>> jid's ?
>>>>
>>>> You can probe anything you want. :)
>>>
>>> I should have clarified better.
>>>
>>> Assume that there is mutual subscription between userA
>> and userB.
>>> Support we have :
>>>
>>> userA has session us...@domain/resA userB has session
>>> us...@domain/resB1 userB has session us...@domain/resB2
>>>
>>>
>>> After presence has been exchanged, suppose userA
>> blocks userB (or all
>>> users) - so an unavailable presence is sent to userB's
>> resources.
>>> Subsequent to that, suppose userA sends available to
>> one of the
>>> resources, say - us...@domain/resB1
>>>
>>> Now, iirc, if resB2 probes, userA's server must return
>> unavailable.
>>
>> That seems reasonable.
>>
>>> But if resB1 probes, userA's server must return the
>> last directed
>>> presence sent (subsequent to unavailable).
>> That also seems reasonable.
>>
>>> We could replace userB with muc or any other component
>> in the above.
>>
>> Right. The MUC example is more apropos.
>>
>>> IIRC this was a usecase discussed quite a while back -
>> was it removed
>>> ? If not, my query was, how does it interact with this
>> list below
>>
>> We had some text about this in rfc3921bis but IIRC we removed it
>> because people thought it belonged in XEP-0045 (e.g., an
>> implementation note on "how to remove ghost users"), not the RFC.
>> However, I think the text never made it to XEP-0045. I'll check on
>> that.
>
>
> Shouldn't this not be part of the CORE xmpp spec ? Privacy
> enforcement, routing decisions, presence management happen within the
> server - and only server has visibility of the user's stanza history
> to support this imo - so, if required, wouldn't it not be for the
> server to handle it ? ('it' being responding to probe with previous
> presence stanza in case of directed presence - or maybe this is
> already there and I just did not see it ?).
>
> A quick search did not reveal much on discussion about this - any
> overriding reason why this was pulled out ?
People found it confusing and MUC-specific. However, that was for the
full use case. I do think that rfc3921bis needs to say something about
answering probes from entities to which you've sent directed presence,
so that would belong in Section 4.3.2 or Section 4.6.2 of rfc3921bis.
I'll add that to my task list for the RFC revisions.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Standards] Inconsistent Subscriptions in XMPP
--- On Mon, 13/4/09, Peter Saint-Andre wrote:
> From: Peter Saint-Andre
> Subject: Re: [Standards] Inconsistent Subscriptions in XMPP
> To: "XMPP Standards"
> Date: Monday, 13 April, 2009, 12:45 AM
> On 4/10/09 8:36 PM, Mridul
> Muralidharan wrote:
> >
> >
> > --- On Sat, 11/4/09, Peter Saint-Andre
> wrote:
> >
> >> From: Peter Saint-Andre
> Subject: Re:
> >> [Standards] Inconsistent Subscriptions in XMPP To:
> "XMPP Standards"
> >>
> Date: Saturday, 11 April, 2009, 4:04 AM On
> >> 4/1/09 12:07 PM, Mridul Muralidharan wrote:
> >>> If I recall right, probe can be sent to a full
> jid in
> >> case a directed
> >>> presence was received from it in the past -
> and the
> >> behavior would be
> >>> different (return last presence stanza sent
> iirc). Has
> >> that behavior
> >>> changed or is the description below only for
> bare
> >> jid's ?
> >>
> >> You can probe anything you want. :)
> >
> >
> > I should have clarified better.
> >
> > Assume that there is mutual subscription between userA
> and userB.
> > Support we have :
> >
> > userA has session us...@domain/resA
> > userB has session us...@domain/resB1
> > userB has session us...@domain/resB2
> >
> >
> > After presence has been exchanged, suppose userA
> blocks userB (or all
> > users) - so an unavailable presence is sent to userB's
> resources.
> > Subsequent to that, suppose userA sends available to
> one of the
> > resources, say - us...@domain/resB1
> >
> > Now, iirc, if resB2 probes, userA's server must return
> unavailable.
>
> That seems reasonable.
>
> > But if resB1 probes, userA's server must return the
> last directed
> > presence sent (subsequent to unavailable).
>
> That also seems reasonable.
>
> > We could replace userB with muc or any other component
> in the above.
>
> Right. The MUC example is more apropos.
>
> > IIRC this was a usecase discussed quite a while back -
> was it removed
> > ? If not, my query was, how does it interact with this
> list below
>
> We had some text about this in rfc3921bis but IIRC we
> removed it because
> people thought it belonged in XEP-0045 (e.g., an
> implementation note on
> "how to remove ghost users"), not the RFC. However, I think
> the text
> never made it to XEP-0045. I'll check on that.
Shouldn't this not be part of the CORE xmpp spec ?
Privacy enforcement, routing decisions, presence management happen within the
server - and only server has visibility of the user's stanza history to support
this imo - so, if required, wouldn't it not be for the server to handle it ?
('it' being responding to probe with previous presence stanza in case of
directed presence - or maybe this is already there and I just did not see it ?).
A quick search did not reveal much on discussion about this - any overriding
reason why this was pulled out ?
Thanks,
Mridul
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
Add more friends to your messenger and enjoy! Go to
http://messenger.yahoo.com/invite/
Re: [Standards] Inconsistent Subscriptions in XMPP
On 4/10/09 8:36 PM, Mridul Muralidharan wrote: > > > --- On Sat, 11/4/09, Peter Saint-Andre wrote: > >> From: Peter Saint-Andre Subject: Re: >> [Standards] Inconsistent Subscriptions in XMPP To: "XMPP Standards" >> Date: Saturday, 11 April, 2009, 4:04 AM On >> 4/1/09 12:07 PM, Mridul Muralidharan wrote: >>> If I recall right, probe can be sent to a full jid in >> case a directed >>> presence was received from it in the past - and the >> behavior would be >>> different (return last presence stanza sent iirc). Has >> that behavior >>> changed or is the description below only for bare >> jid's ? >> >> You can probe anything you want. :) > > > I should have clarified better. > > Assume that there is mutual subscription between userA and userB. > Support we have : > > userA has session us...@domain/resA > userB has session us...@domain/resB1 > userB has session us...@domain/resB2 > > > After presence has been exchanged, suppose userA blocks userB (or all > users) - so an unavailable presence is sent to userB's resources. > Subsequent to that, suppose userA sends available to one of the > resources, say - us...@domain/resB1 > > Now, iirc, if resB2 probes, userA's server must return unavailable. That seems reasonable. > But if resB1 probes, userA's server must return the last directed > presence sent (subsequent to unavailable). That also seems reasonable. > We could replace userB with muc or any other component in the above. Right. The MUC example is more apropos. > IIRC this was a usecase discussed quite a while back - was it removed > ? If not, my query was, how does it interact with this list below We had some text about this in rfc3921bis but IIRC we removed it because people thought it belonged in XEP-0045 (e.g., an implementation note on "how to remove ghost users"), not the RFC. However, I think the text never made it to XEP-0045. I'll check on that. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Inconsistent Subscriptions in XMPP
--- On Sat, 11/4/09, Peter Saint-Andre wrote: > From: Peter Saint-Andre > Subject: Re: [Standards] Inconsistent Subscriptions in XMPP > To: "XMPP Standards" > Date: Saturday, 11 April, 2009, 4:04 AM > On 4/1/09 12:07 PM, Mridul > Muralidharan wrote: > > > > If I recall right, probe can be sent to a full jid in > case a directed > > presence was received from it in the past - and the > behavior would be > > different (return last presence stanza sent iirc). Has > that behavior > > changed or is the description below only for bare > jid's ? > > You can probe anything you want. :) I should have clarified better. Assume that there is mutual subscription between userA and userB. Support we have : userA has session us...@domain/resA userB has session us...@domain/resB1 userB has session us...@domain/resB2 After presence has been exchanged, suppose userA blocks userB (or all users) - so an unavailable presence is sent to userB's resources. Subsequent to that, suppose userA sends available to one of the resources, say - us...@domain/resB1 Now, iirc, if resB2 probes, userA's server must return unavailable. But if resB1 probes, userA's server must return the last directed presence sent (subsequent to unavailable). We could replace userB with muc or any other component in the above. IIRC this was a usecase discussed quite a while back - was it removed ? If not, my query was, how does it interact with this list below related to probes, etc. Thanks, Mridul > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/
Re: [Standards] Inconsistent Subscriptions in XMPP
On 4/7/09 12:45 AM, Philipp Hancke wrote: > hijacking the thread... two concrete examples where error handling > is needed: > > subscription state is "none" initially: > SENT: > RECV: type='set'> subscription='none' jid='f...@bar'/> > RECV: id='jcl_37'> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> > > after relogin and roster fetch: > RECV: type='result'> subscription='none' jid='f...@bar'/> > > The presence error (which, as can be by looking at the id attribute, > is a reply to the initial subscribe) does not affect the subscription > state. IMHO the server needs to periodically resend the subscribe to the contact if the state remains ask="subscribe" (no reply received from the contact). I'm pretty sure that I added something about this to rfc3921bis. > subscription state is "both" initially: > SENT: jid="s...@jid" subscription="remove"/> > RECV: type='set'> jid='s...@jid'/> > RECV: type='result'/> > RECV: code='404' type='cancel'> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> > RECV: code='404' type='cancel'> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> > > The subscription state is "none" afterwards - which is the users intention. > The presence errors are replies to unsubscribe/unsubscribed stanzas > generated by the server and should imo never have been sent to the > client. Agreed -- the server should eat those. > The question is: how do error replies to presence subscription > stanzas affect the subscription state? That's up to the server. Smart servers will do the right thing. So we need smarter servers (and to provide some advice in rfc3921bis). Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Inconsistent Subscriptions in XMPP
On 4/1/09 12:07 PM, Mridul Muralidharan wrote: > > If I recall right, probe can be sent to a full jid in case a directed > presence was received from it in the past - and the behavior would be > different (return last presence stanza sent iirc). Has that behavior > changed or is the description below only for bare jid's ? You can probe anything you want. :) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Inconsistent Subscriptions in XMPP
hijacking the thread... two concrete examples where error handling is needed: subscription state is "none" initially: SENT: RECV: type='set'>subscription='none' jid='f...@bar'/> RECV: id='jcl_37'>xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> after relogin and roster fetch: RECV: type='result'>subscription='none' jid='f...@bar'/> The presence error (which, as can be by looking at the id attribute, is a reply to the initial subscribe) does not affect the subscription state. subscription state is "both" initially: SENT: jid="s...@jid" subscription="remove"/> RECV: type='set'>jid='s...@jid'/> RECV: type='result'/> RECV: code='404' type='cancel'>xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> RECV: code='404' type='cancel'>xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> The subscription state is "none" afterwards - which is the users intention. The presence errors are replies to unsubscribe/unsubscribed stanzas generated by the server and should imo never have been sent to the client. The question is: how do error replies to presence subscription stanzas affect the subscription state? philipp
Re: [Standards] Inconsistent Subscriptions in XMPP
If I recall right, probe can be sent to a full jid in case a directed presence was received from it in the past - and the behavior would be different (return last presence stanza sent iirc). Has that behavior changed or is the description below only for bare jid's ? Regards, Mridul --- On Wed, 1/4/09, Peter Saint-Andre wrote: > From: Peter Saint-Andre > Subject: Re: [Standards] Inconsistent Subscriptions in XMPP > To: "XMPP Standards" > Date: Wednesday, 1 April, 2009, 11:19 PM > On 3/5/09 5:37 AM, Pedro Melo wrote: > > Hi, > > > > On Feb 28, 2009, at 10:18 AM, Waqas Hussain wrote: > > > >> 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, > > Yes, roster stuff always results in big tables. :) > > > 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 prefer the terms "user" and "contact" to be consistent > with RFC 3921. > > > I wrote the following table of what I think are the > most safe > > transactions: none of the subscriptions are "upgraded" > in any way. > > I've annotated it with comments and pseudo-XMPP. Now it's > even more > verbose. :) > > > (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' > > Why would the user's server send a probe to the contact if > it thinks > that the subscription state is none? (Granted, the user's > client could > generate a presence probe, but that's a different story.) > > > Sender: To > > Recv: none > > > > => Recv sends 'unsubscribe' > > So: user's server thinks that user is sub'd to contact. It > sends [probe > state='both']. Contact's server thinks that user is not > sub'd. Therefore > I think contact's server would send [presence > unsubscribed], i.e., "I am > not going to send you contact's presence because you're not > subscribed > to his presence". > > > Sender: To > > Recv: To > > > > => Recv resets to 'none', sends > 'unsubscribe' > > As above, I think contact's server would send [presence > unsubscribed]. > > > Sender: To > > Recv: Both > > > > => Recv resets to 'From' > > I think this is OK. I assume that after the roster push > (state=from), > the contact might send a new subscription request. > > > 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' > > As above for none, why would the user's server send a probe > to the > contact if it thinks that the subscription state is from > (i.e., the user > has a subscription from the contact but not to the > contact)? > > > Sender: Both > > Recv: none > > > > => Recv sends 'unsubscribe' and > 'unsubscribed' > > Right. > > > Sender: From > > Recv: From > > > > => Recv resets to 'none', sends > 'unsubscribed' > > IMHO user's server would not probe in this case. > > > Sender: From > > Recv: Both > > > > => Recv resets to 'To' > > IMHO user's server would not probe in this case. > > >> 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. > > Agreed. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/
Re: [Standards] Inconsistent Subscriptions in XMPP
On 3/5/09 5:37 AM, Pedro Melo wrote: > Hi, > > On Feb 28, 2009, at 10:18 AM, Waqas Hussain wrote: > >> 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, Yes, roster stuff always results in big tables. :) > 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 prefer the terms "user" and "contact" to be consistent with RFC 3921. > I wrote the following table of what I think are the most safe > transactions: none of the subscriptions are "upgraded" in any way. I've annotated it with comments and pseudo-XMPP. Now it's even more verbose. :) > (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' Why would the user's server send a probe to the contact if it thinks that the subscription state is none? (Granted, the user's client could generate a presence probe, but that's a different story.) > Sender: To > Recv: none > > => Recv sends 'unsubscribe' So: user's server thinks that user is sub'd to contact. It sends [probe state='both']. Contact's server thinks that user is not sub'd. Therefore I think contact's server would send [presence unsubscribed], i.e., "I am not going to send you contact's presence because you're not subscribed to his presence". > Sender: To > Recv: To > > => Recv resets to 'none', sends 'unsubscribe' As above, I think contact's server would send [presence unsubscribed]. > Sender: To > Recv: Both > > => Recv resets to 'From' I think this is OK. I assume that after the roster push (state=from), the contact might send a new subscription request. > 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' As above for none, why would the user's server send a probe to the contact if it thinks that the subscription state is from (i.e., the user has a subscription from the contact but not to the contact)? > Sender: Both > Recv: none > > => Recv sends 'unsubscribe' and 'unsubscribed' Right. > Sender: From > Recv: From > > => Recv resets to 'none', sends 'unsubscribed' IMHO user's server would not probe in this case. > Sender: From > Recv: Both > > => Recv resets to 'To' IMHO user's server would not probe in this case. >> 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. Agreed. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Inconsistent Subscriptions in XMPP
Hi, On Mar 5, 2009, at 5:51 PM, Waqas Hussain wrote: 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). Actually, that's the only action possible. If you add automatic re- subscribe, I can send you a probe and trick you into subscribing to me. This allows me to look at your probe's to know when you get online. With an external component, this is a 10 minute hack. Not good. So the only safe option is to lower the permission to the highest level consistent with both sides. This way, with a none on my side, you'll never be able to change me. 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. Timestamps + distributed systems = fun. I don't think you need this. You have to downgrade the subscription level, so it does not matter what the sequence, just the current level. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: m...@simplicidade.org Use XMPP!
Re: [Standards] Inconsistent Subscriptions in XMPP
On Thu, Mar 5, 2009 at 5:37 PM, Pedro Melo wrote: > Hi, > > On Feb 28, 2009, at 10:18 AM, Waqas Hussain wrote: >> >> On Thu, Feb 26, 2009 at 9:32 AM, Pedro Melo wrote: >>> >>> On Feb 25, 2009, at 7:36 PM, Pavel Simerda wrote: On Tue, 24 Feb 2009 15:54:38 + Pedro Melo 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 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: >> > to="y...@yourhost.com"> > > Don't know if you should also include the ask-out/ask-in flag. Also original > request . > > 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: m...@simplicidade.org > 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). T
Re: [Standards] Inconsistent Subscriptions in XMPP
Hi, On Feb 28, 2009, at 10:18 AM, Waqas Hussain wrote: On Thu, Feb 26, 2009 at 9:32 AM, Pedro Melo wrote: On Feb 25, 2009, at 7:36 PM, Pavel Simerda wrote: On Tue, 24 Feb 2009 15:54:38 + Pedro Melo 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 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: Don't know if you should also include the ask-out/ask-in flag. Also original request . 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: m...@simplicidade.org Use XMPP!
Re: [Standards] Inconsistent Subscriptions in XMPP
On Thu, Mar 5, 2009 at 9:44 AM, Pavel Simerda wrote: >> From an IM user's point of view, trying to settle on the highest >> common permissions seems more appropriate (and less confusing). > Very bad idea. You have either to go for lowest... or negotiate with > the user. (Privacy issues) The highest /common/ permission is one that both ends agree on. The lowest /common/ permission is none. The highest common is what makes sense, I think. /K
Re: [Standards] Inconsistent Subscriptions in XMPP
On Sat, 28 Feb 2009 15:18:38 +0500 Waqas Hussain wrote: > On Thu, Feb 26, 2009 at 9:32 AM, Pedro Melo > wrote: > > > > On Feb 25, 2009, at 7:36 PM, Pavel Simerda wrote: > > > >> On Tue, 24 Feb 2009 15:54:38 + > >> Pedro Melo 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 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: > to="y...@yourhost.com"> > > 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 > appropriate action. > > 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)? > > From an IM user's point of view, trying to settle on the highest > common permissions seems more appropriate (and less confusing). Very bad idea. You have either to go for lowest... or negotiate with the user. (Privacy issues) Pavel > -- > Waqas Hussain -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Inconsistent Subscriptions in XMPP
On Thu, Feb 26, 2009 at 9:32 AM, Pedro Melo wrote: > > On Feb 25, 2009, at 7:36 PM, Pavel Simerda wrote: > >> On Tue, 24 Feb 2009 15:54:38 + >> Pedro Melo 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 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: 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 appropriate action. 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)? >From an IM user's point of view, trying to settle on the highest common permissions seems more appropriate (and less confusing). -- Waqas Hussain
Re: [Standards] Inconsistent Subscriptions in XMPP
On Wed, 25 Feb 2009 21:57:12 -0500 Thomas Charron wrote: > On Wed, Feb 25, 2009 at 2:36 PM, Pavel Simerda > wrote: > > Btw presence probe seems too weak... as it doesn't reveal full > > subscription state. > > By design. > Of course, but that doesn't help. -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Inconsistent Subscriptions in XMPP
On Feb 25, 2009, at 7:36 PM, Pavel Simerda wrote: On Tue, 24 Feb 2009 15:54:38 + Pedro Melo 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 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,
Re: [Standards] Inconsistent Subscriptions in XMPP
On Wed, Feb 25, 2009 at 2:36 PM, Pavel Simerda wrote: > Btw presence probe seems too weak... as it doesn't reveal full > subscription state. By design. -- -- Thomas
Re: [Standards] Inconsistent Subscriptions in XMPP
On Thu, 26 Feb 2009 00:15:18 +0100 Robin Redeker wrote: > On Tue, Feb 24, 2009 at 01:49:50AM +0100, 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. > > The problem is not just subscription state, but any state that is > not synchronized, basic presence information comes to mind, they also > get out of sync sometimes. Maybe it's less of a problem, because a > client logging in again, can refresh that state. Ah, thanks for pointing out. > Subscription information of course isn't as easily 'synchronized'. Not so easily, but it's possible... as in most situations, you mostly know you've screwed it up... And you must write all your contacts to delete you and add back. That is tough. If at least these scenarios were caught and the servers would synchronize upon your communication. You write Alice, Alice writes you... and by that time the servers would synchronize. The same could work for presences... and repeated request... so if you screw up the server... you would just let it send subscription requests for all contacts and then the servers would detect and fix all inconsistencies. Other scenarios might come in hand. > I don't know whether servers already do this, but having a consistent > state for presence, would allow for caching the presence information > on the receiving server. Possibly. > A generic synchronisation protocol would of course help any > state information that has to be shared with other servers. Hmm, not sure if generic or specific, but I would like to see some. > I brought this topic up some weeks ago (and I think also a year ago), Then bring it again, please :). > but I'm not a server developer (If I was, I would probably have > already implemented some proof of concept protocol to do this). But > these things don't seem to bother the (and/or developers) They're lazy (everybody is). > users much > and there doesn't seem to be much (or enough) interest for consistent > information sharing amog servers. It shouldn't be too complicated. We should prefer a nice and easy way to go. You probably that a review of the core protocols is underway. Maybe we can have a chat on Jabber? > > > Greetings, >Robin > -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Inconsistent Subscriptions in XMPP
On Tue, Feb 24, 2009 at 01:49:50AM +0100, 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. The problem is not just subscription state, but any state that is not synchronized, basic presence information comes to mind, they also get out of sync sometimes. Maybe it's less of a problem, because a client logging in again, can refresh that state. Subscription information of course isn't as easily 'synchronized'. I don't know whether servers already do this, but having a consistent state for presence, would allow for caching the presence information on the receiving server. A generic synchronisation protocol would of course help any state information that has to be shared with other servers. I brought this topic up some weeks ago (and I think also a year ago), but I'm not a server developer (If I was, I would probably have already implemented some proof of concept protocol to do this). But these things don't seem to bother the (and/or developers) users much and there doesn't seem to be much (or enough) interest for consistent information sharing amog servers. Greetings, Robin -- Robin Redeker | Deliantra, the free code+content MORPG el...@ta-sa.org / r.rede...@gmail.com | http://www.deliantra.net http://www.ta-sa.org/ |
Re: [Standards] Inconsistent Subscriptions in XMPP
On Tue, 24 Feb 2009 15:54:38 + Pedro Melo 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 include the local > "view" of the subscription state. Btw presence probe seems too weak... as it doesn't reveal full subscription state. > The receiving server can then look to see if the state is consisten > with his own state. If you opt by the lowest trust level (a from/to > beats a both, none beats all), you should be able to re-sync > subscription state automagically. > > Best regards, -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Inconsistent Subscriptions in XMPP
You just have to tell the deveopers to do it, then :). On Tue, 24 Feb 2009 15:54:38 + Pedro Melo 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 include the local > "view" of the subscription state. > > The receiving server can then look to see if the state is consisten > with his own state. If you opt by the lowest trust level (a from/to > beats a both, none beats all), you should be able to re-sync > subscription state automagically. > > Best regards, -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Inconsistent Subscriptions in XMPP
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 include the local "view" of the subscription state. The receiving server can then look to see if the state is consisten with his own state. If you opt by the lowest trust level (a from/to beats a both, none beats all), you should be able to re-sync subscription state automagically. Best regards,
