On 3/31/09 12:33 PM, Pedro Melo wrote: > > On Mar 31, 2009, at 5:36 PM, Dave Cridland wrote: > >> On Tue Mar 31 16:00:20 2009, Pedro Melo wrote: >> >>> 2) if subscription state gets out of sync, the protocol will behave >>> better or worse than the current version :), it really depends which >>> roster is correct. There was a thread 2 or 3 weeks back with a >>> tentative solution to keep subscription state in sync using the >>> initial <presence type="probe" />. >> I'm not sure your initial analysis is correct, and it's related to the >> above comments I make - if rosters are out of sync now, while it's >> tricky to discover, you know where the blame lies instantly in each case. >> >> And a rough analysis suggests that in the current situation, you'll >> either get presence when you *no longer* wanted it, or else you won't >> get presence when you want it. With a reverse roster lookup, it's >> possible to end up in a situation where you'll get presence when the >> sender doesn't want you to, which is substantially worse, and without >> any bad actor involved. (I could be wrong here, please check this.) > > if I accept your subscription (my server will move to 'both' or 'to') > but if that <presence type="subscribed"> does not reach you (you keep > 'none' or 'to') then the remote fan-out is less revealing. I guess I > could also argue from your side and say that in that case I already gave > you permission to see so in principle I'm disclosing as much as I wanted. > > I do believe that out-of-sync rosters is a separate problem, and it > could be solved with a handshake between servers at presence-probe time, > but maybe thats the topic of another thread.
Yes, I'll read the thread about "inconsistent subscriptions" and post there. In rfc3921bis I've tried to clarify the use of unsubscribe and unsubscribed on this point, but perhaps it's not enough. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
