[Standards] Proposed XMPP Extension: Stanza Repeaters

Carlo v. Loesch CvL at mail.symlynX.com
Fri Mar 21 20:04:56 UTC 2008

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.

More information about the Standards mailing list