[standards-jig] NEW JEP: Inband Bytestream (JEP-0047)
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
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
>> 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
>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.
>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