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/
