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

mlin at mlin.net mlin at mlin.net
Sat Jan 19 04:20:22 UTC 2002


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.

Julian
-- 
email: julian at jabber.org
jabber:julian at jabber.org

_______________________________________________
Standards-JIG mailing list
Standards-JIG at jabber.org
http://mailman.jabber.org/listinfo/standards-jig



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20020118/41c67570/attachment.html>


More information about the Standards mailing list