[Standards-JIG] proto-JEP: Smart Presence Distribution

Carlo v. Loesch CvL at mail.symlynX.com
Wed May 17 20:48:07 UTC 2006


Richard Dobson typeth:
| What makes you suppose that? We usually prefer to look longer term when 
| developing protocols here, and prefer to develop solutions that will not 
| break or are against the existing protocol, we prefer to extend.

Even the JEP as it is posted to the inbox doesn't break anything.

The current suggestion is, if the user is using privacy lists on any
target of a particular server, to revert to the current distribution
method, thus a fan out with exceptions.

It would be good to know, if even this simple approach already brings
relevant traffic decrease. We have no figures on that.

Concerning the problem of keeping subscriptions in sync:

What's bad about occasionally having your server re-issue subscribed
and unsubscribed messages during off hours, so that the server network
slowly cleans out sync problems. wouldn't it be possible to use the
existing presence subscription protocol without changing anything?

The result should be same as with a JEP-0033-like transfer of the
context subscriber list before getting started with smarticasting.
maybe a bit nicer to the network, as off hours are nicer. This also
addresses database tweaks (how the hell do you gain access to the
database if you're not the jabber admin?) if those tweaks would
sooner or later be detected and end up in the jabber server log.

We could extend the JEP in a way, that the presence database is
kept clean by periodic updates during off-hours.

Concerning the privacy lists, we could extend the protocol used to
define these privacy lists between client and server in a way that
the changes are also forwarded to the target server, so the target
server knows which exceptions to keep in mind. This also is a much
less invasive change than to introduce a verbose new protocol.

| Well thats not up to you, the whole idea of privacy is that you can do 
| things that the other person does not know about, like blocking them.

I noticed Jabber sends presence whenever someone is in the roster,
then you have to put a filter to stop him from doing so. Other protocols
let you keep somebody in the buddy list even if you haven't exchanged
presence subscriptions.. easily, so you don't have to filter something
afterwards. You can simply avoid handing out presence in the first place.

I have understood that privacy filters is the only mechanism of this
kind, and thus you cannot do without. It would be nicer if one could
exchange "friendship" and roster listing without implying presence
subscriptions.

But this is just theory. Jabber has a model that relies on outgoing
filters, so we will see how we can go about that.




More information about the Standards mailing list