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
