Richard Dobson typeth: | example of where you would use this would be when you are at work and | you only want your work colleages to receive your presence and not your | mates, but when you get home you might want the reverse to be true, this | is something that is impossible to accomplish using the method you
Oh you're right, thanks for elaborating.. I overlooked that aspect. We intend to use something equivalent to the roster group concept to achieve that purpose, but in XMPP that is limited to C2S, so for S2S something different is necessary. Makes sense. Why didn't you bring that up 2 years ago when we first discussed this stuff? :) | I fail to see why this is a protocol issue, if people are accepting | presence subscriptions out of politeness thats a social issue... You can design protocols accordingly, then give out best practice suggestions to client writers. If there is a way to properly exchange contact data and appear in the roster without necessitating presence subscription, but instead by probing only when the mouse lingers over a person (for example) - you can design solutions which use temporary presence subscriptions on demand for example. I'm not saying this is the way to go, I'm just saying that the design of the protocol does influence how clients are written which then influences how users use the entire system. | Huh? Why shouldnt clients be allowed to modify a users own roster? They shouldn't be able to "fake" they are subscribed to somebody when that person never agreed to. The roster protocol allows you to upload that information to the server, and the RFC doesn't specify whether the server should believe that information or not. So you can modify a subscription='none' into a subscription='both' without a single presence subscribe leaving your server. This may or may not cause problems. Maybe it only causes problems to the user who did that change. It certainly hinders the "smart presence" strategy from operating safely, if a client can make you snoop on presence data actually transmitted to other users on your server. But it's easy to fix that hole by forbidding modifications to the subscription+ask fields via roster iq sets. But since you explained how privacy lists are used, the smart presence approach using the existing subscription data is not flexible enough.
