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

Tijl Houtbeckers thoutbeckers at splendo.com
Mon Sep 30 13:45:21 UTC 2002


"Richard Dobson" <richard at dobson-i.net> wrote on 30-9-2002 15:02:53:
>
>> 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.
>
>Yes but karma is not a Jabber standard, so a standard method needs to 
>be created to block inband transfers, Karma is jabberd implementation 
>specific. 
>

True... Karma is not a Jabber standard, but perhaps it should be 
(discoverable). I think that'd be better as making specific standards 
to block every namespace that could *potentionally* cost too much 
datatraffic. 

>> 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). 
>
>Yep I quite agree it should be discoverable.

That's a good thing. Do you also agree that *any* namespace that is not 
allowed should be discoverable? Perhaps we could wrap this stuff 
together with some other things and give it a fancy name like "Disco". 
Anyone on the list working on such a thing? :P 

>
>> 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 :)
>
>Why is allowing server admins to control their servers going to stop
>adoption of the protocol, since it is only supposed to be used if all 
>other methods have been exhausted.

As hidden in my reply to Justin I disagree that this is merely a fall 
back method. There are lot's and lot's of good reasons for having an 
inband bytestreams. They've come up on JDEV more then once. 

> Clients should be supporting the 
>other protocols too not just this one only, since its a fallback 
>protocol, that might not even be supported on some servers. 

And this is what I'm scared of.. if everyone starts calling it a 
fallback method for sending 12 megabyte MP3s and there's an easy way 
for serveradmins to just block the whole thing another standardization 
effort of Jabber will have failed. 

I agree that *all* namespaces should be able to be blocked. I think 
that by default all namespaces should be allowed. And I oppose a 
special way of blocking inband data transfer. 

>Also the 
>same argument applies in reverse to yours, if there is no standard for 
>blocking inband data server admins that want to block it will create 
>their own weird and wonderful ways to block it, that dont necessaryly 
>work properly in every occasion, or worse stop using jabber and move 
>to using another system. 

Again, I think there should be a standard way for blocking any 
namespace. But not a seperate way of blocking inband data. I don't see 
a need to treat jabber:iq:inband any different as eg jabber:iq:version. 

If it's still the data traffic you're worried about: A fool can try to 
send 10 meg of BASE64 data inband but a fool can also stuff 20 megs of 
SVG-XML into a message. (if you send it as ZIP file through BASE64 it 
will probably be smaller and cause less load on the server ;). Or a 
fool can ask the info of all 1000 rooms on a conferance server every 10 
seconds. The problem is not the way data is transfered (in this case 
jabber:iq:inband), but the *amount*. 





More information about the Standards mailing list