[standards-jig] Discussion on JEP-0016: Server-Based Privacy Rules

Julian Missig julian at jabber.org
Sat Jan 19 04:10:11 UTC 2002

mlin at mlin.net wrote:
> One concern I have is the server-side overhead that might be caused by 
> having to compare the JID of all incoming packets against the user's 
> blacklist, which could be quite expensive relative to what the router 
> currently has to do. Still, a server-side block is something we need 
> badly, so I'm obviously not giving up on this - but I think we need to 
> empirically evaluate whether there will be a scalability impact and, if 
> so, how to minimize it. It may turn out that, like many other things we 
> have considered, the performance impact will be insignificant compared 
> to the XML framing and parsing the server already has to do.

Well, as was mentioned in the JEP, this form of server-side blocking is 
much less resource-intensive than Jabber Filters, the current way to do it.

> On a broader note, we should consider that blocking, whether done on the 
> client side or the server side, is going to become really hard to 
> enforce as Jabber moves to a distributed network like sendmail. If I am 
> blocked, I might be able to run a local server and renew my DHCP address 
> to get around it. This, of course, leads to difficult questions of 
> inter-server trust and identity, which I think we are all hesitant to 
> tackle at this time.

Or you could just get another username. This is more for user-level 
blocking, just like AIM does right now, and it's an accepted fact that 
you can block some guy and he'll go get another screen name and bug you 
again. I don't think this extension even intends to solve that problem. 
That's a much larger problem which I do not believe can be solved with 
current Jabber.

email: julian at jabber.org
jabber:julian at jabber.org

More information about the Standards mailing list