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 iq/ on s2s. philipp
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 iq/ 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
-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: presence to=f...@bar id=jcl_37 type='subscribe'/ RECV: iq from='m...@local/Exodus' to='m...@local/Exodus' id='push' type='set'query xmlns='jabber:iq:roster'item ask='subscribe' subscription='none' jid='f...@bar'//query/iq RECV: presence from='f...@bar' to='m...@local/Exodus' type='error' id='jcl_37'error code='404' type='cancel'remote-server-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'//error/presence after relogin and roster fetch: RECV: iq from='m...@local/Exodus' to='m...@local/Exodus' id='jcl_40' type='result'query xmlns='jabber:iq:roster'item ask='subscribe' 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
-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 stpe...@stpeter.im wrote:
From: Peter Saint-Andre stpe...@stpeter.im Subject: Re:
[Standards] Inconsistent Subscriptions in XMPP To: XMPP Standards
standards@xmpp.org 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 stpe...@stpeter.im
wrote:
From: Peter Saint-Andre stpe...@stpeter.im
Subject: Re:
[Standards] Inconsistent Subscriptions in XMPP To:
XMPP Standards
standards@xmpp.org
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
On 4/10/09 8:36 PM, Mridul Muralidharan wrote: --- On Sat, 11/4/09, Peter Saint-Andre stpe...@stpeter.im wrote: From: Peter Saint-Andre stpe...@stpeter.im Subject: Re: [Standards] Inconsistent Subscriptions in XMPP To: XMPP Standards standards@xmpp.org 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 Mon, 13/4/09, Peter Saint-Andre stpe...@stpeter.im wrote:
From: Peter Saint-Andre stpe...@stpeter.im
Subject: Re: [Standards] Inconsistent Subscriptions in XMPP
To: XMPP Standards standards@xmpp.org
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 stpe...@stpeter.im
wrote:
From: Peter Saint-Andre stpe...@stpeter.im
Subject: Re:
[Standards] Inconsistent Subscriptions in XMPP To:
XMPP Standards
standards@xmpp.org
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/12/09 1:20 PM, Mridul Muralidharan wrote:
--- On Mon, 13/4/09, Peter Saint-Andre stpe...@stpeter.im wrote:
From: Peter Saint-Andre stpe...@stpeter.im Subject: Re:
[Standards] Inconsistent Subscriptions in XMPP To: XMPP Standards
standards@xmpp.org 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 stpe...@stpeter.im
wrote:
From: Peter Saint-Andre stpe...@stpeter.im
Subject: Re:
[Standards] Inconsistent Subscriptions in XMPP To:
XMPP Standards
standards@xmpp.org
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 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
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: presence to=f...@bar id=jcl_37 type='subscribe'/ RECV: iq from='m...@local/Exodus' to='m...@local/Exodus' id='push' type='set'query xmlns='jabber:iq:roster'item ask='subscribe' subscription='none' jid='f...@bar'//query/iq RECV: presence from='f...@bar' to='m...@local/Exodus' type='error' id='jcl_37'error code='404' type='cancel'remote-server-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'//error/presence after relogin and roster fetch: RECV: iq from='m...@local/Exodus' to='m...@local/Exodus' id='jcl_40' type='result'query xmlns='jabber:iq:roster'item ask='subscribe' 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: iq id=jcl_50 type=setquery xmlns=jabber:iq:rosteritem jid=s...@jid subscription=remove//query/iq RECV: iq from='m...@local/Exodus' to='m...@local/Exodus' id='push' type='set'query xmlns='jabber:iq:roster'item subscription='remove' jid='s...@jid'//query/iq RECV: iq from='m...@local/Exodus' to='m...@local/Exodus' id='jcl_50' type='result'/ RECV: presence from='s...@jid' to='m...@local/Exodus' type='error'error code='404' type='cancel'remote-server-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'//error/presence RECV: presence from='s...@jid' to='m...@local/Exodus' type='error'error code='404' type='cancel'remote-server-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'//error/presence 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 Sat, 11/4/09, Peter Saint-Andre stpe...@stpeter.im wrote: From: Peter Saint-Andre stpe...@stpeter.im Subject: Re: [Standards] Inconsistent Subscriptions in XMPP To: XMPP Standards standards@xmpp.org 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
hijacking the thread... two concrete examples where error handling is needed: subscription state is none initially: SENT: presence to=f...@bar id=jcl_37 type='subscribe'/ RECV: iq from='m...@local/Exodus' to='m...@local/Exodus' id='push' type='set'query xmlns='jabber:iq:roster'item ask='subscribe' subscription='none' jid='f...@bar'//query/iq RECV: presence from='f...@bar' to='m...@local/Exodus' type='error' id='jcl_37'error code='404' type='cancel'remote-server-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'//error/presence after relogin and roster fetch: RECV: iq from='m...@local/Exodus' to='m...@local/Exodus' id='jcl_40' type='result'query xmlns='jabber:iq:roster'item ask='subscribe' 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: iq id=jcl_50 type=setquery xmlns=jabber:iq:rosteritem jid=s...@jid subscription=remove//query/iq RECV: iq from='m...@local/Exodus' to='m...@local/Exodus' id='push' type='set'query xmlns='jabber:iq:roster'item subscription='remove' jid='s...@jid'//query/iq RECV: iq from='m...@local/Exodus' to='m...@local/Exodus' id='jcl_50' type='result'/ RECV: presence from='s...@jid' to='m...@local/Exodus' type='error'error code='404' type='cancel'remote-server-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'//error/presence RECV: presence from='s...@jid' to='m...@local/Exodus' type='error'error code='404' type='cancel'remote-server-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'//error/presence 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
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
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 stpe...@stpeter.im wrote: From: Peter Saint-Andre stpe...@stpeter.im Subject: Re: [Standards] Inconsistent Subscriptions in XMPP To: XMPP Standards standa...@xmpp..org 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 Thu, Mar 5, 2009 at 9:44 AM, Pavel Simerda pav...@pavlix.net 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
Hi, On Feb 28, 2009, at 10:18 AM, Waqas Hussain wrote: On Thu, Feb 26, 2009 at 9:32 AM, Pedro Melo m...@simplicidade.org wrote: On Feb 25, 2009, at 7:36 PM, Pavel Simerda wrote: On Tue, 24 Feb 2009 15:54:38 + Pedro Melo m...@simplicidade.org 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=m...@myhost.com to=y...@yourhost.comitem 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: m...@simplicidade.org Use XMPP!
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 m...@simplicidade.org 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. 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
On Tue, 24 Feb 2009 15:54:38 + Pedro Melo m...@simplicidade.org 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. 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
On Thu, 26 Feb 2009 00:15:18 +0100 Robin Redeker el...@x-paste.de 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
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. 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,
