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

Julian Missig julian at jabber.org
Sat Jan 19 04:28:58 UTC 2002

See, that's a real question to ask the JEP author :)

I know that it follows the Jabber tradition of making it easier on the 
client-side and having the important data remain on the server - but 
even then you could argue for just a standardized format in the private 
XML storage which clients pull down and do client-side compares/blocks.

I seem to remember jer or pgm saying that this does not have a major 
impact on jabberd's performance (since they would just slip it in at a 
particular point where they were already doing blocks based on other 
reasons? I can't find the logs right now), but don't quote me on that.


mlin at mlin.net wrote:
> So the real question I have is that if, as you say, we accept that the 
> blocking mechanism is just a virtualization that is trivial to 
> circumvent, is it necessary to have a transport-layer facility for it? 
> What real advantage, weighed against the additional computational cost 
> to the server, does doing this on the server side provide vs. simply 
> ignoring the packets in the UI and denying presence subscription? I 
> guess you can make bandwidth and thin client arguments...but these are 
> always weak arguments IMHO.
>  From the historical perspective, I think that if the "server-side 
> user-level block" were really a viable way to solve any real problems, 
> we would see it in sendmail and IMAP/POP, which we eminently do not.
> -Mike
> *Julian Missig <julian at jabber.org>*
> Sent by: standards-jig-admin at jabber.org
> 01/18/2002 11:10 PM
> Please respond to standards-jig
>         To:        standards-jig at jabber.org
>         cc:        
>         Subject:        Re: [standards-jig] Discussion on JEP-0016: 
> Server-Based Privacy Rules
> 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.

More information about the Standards mailing list