[3][standards-jig] NEW JEP: Inband Bytestream (JEP-0047)

Tijl Houtbeckers thoutbeckers at splendo.com
Mon Sep 30 11:46:16 UTC 2002

"Richard Dobson" <richard at dobson-i.net> wrote on 30-9-2002 13:33:36:
>> Bandwith usage is configurable on the server with Karma. If you give
>> serveradmins the ability to block the *standard* way of exchanging
>> inband data client will go around this and do it in non-standard ways
>> (eg stuffing it into a <message/>). Then we'll end up with no 
>> standard again.
>That maybe the case, but server admins need the configurable ability to
>block inband client data if they want to, it cannot simply be forced on

All you can block is standardised inband data transfers. This means 
I'll get blocked if I want to send a 400 byte big png file the standard 
way, while my neighbour is stuffing a 10 meg MP3 file into a message 
element. I don't see a point in that. If data traffic is a problem for 
your server you should set tight Karma limits. 

Ofcourse any server admin is allowed to block any kind of tag that is 
send. You can block <message/> for all I care :) But I don't think it 
should be made *too* easy for serveradmins, cause it cripples their 
clients. Let alone that something about blocking inband should be in 
the inband JEP. (if jabber:iq:inband is blocked it should discoverable 
using disco on the server, just like any other namespace). 

>Also if anyone goes non-standard then that is their look out, if 
>they do they risk not being compatible with clients that do follow the 
>standard (i.e. almost all) you will always get rogue people who want 
>to do it their way, the problem at the moment is that there is no 
>standard, thats why people are using all sorts of ways at the moment.

I think that if you put something in the JEP about how to explicitly 
block inband transfers, and if it can be blocked by something simple on 
the server like putting a <blockinband/> in jabber.xml it won't help 
much in getting every client to use the same standard. I could be wrong 
ofcourse :) 

More information about the Standards mailing list