[standards-jig] NEW JEP: Inband Bytestream (JEP-0047)
thoutbeckers at splendo.com
Mon Sep 30 15:07:10 UTC 2002
"Richard Dobson" <richard at dobson-i.net> wrote on 30-9-2002 16:53:15:
>> 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
>Fine then a standard to block any namespace you want, although at the
>moment I only see inband as being the likely target for said blocking.
I don't think there will be a problem coming up with reasons why this
is usefull. For example the example you name below, companies that want
to control what happens on their server. I'd say deny everything by
default and allow the namespaces that are needed.
And let's say you *really* want to restrict traffic on your server. You
can make a tool that looks at how much data traffic each namespace
costs and pick the ones you want to block. If some clients suddenly
start changing namespaces you can always block those too. This
discourages developers to use their own namespace instead of the
There's already work being done wich allows you to "surf" to webpages
with Jabber. This could cost a lot more traffic as inband data. Do we
have include another way of blocking for this standard?
>> 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
>Yup sure, and yes it is already being worked on.
Oh, I also have this idea I like to call "PubSub".. don't tell they're
already making that too ;)
>> 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.
>Well that is what it is, if a client can make a connection out of band
>then they should be (unless its a tiny file), and if they cant then
>they "fall back" to this inband protocol, hence the term "fall back".
I don't think for large files one should ever fall back on inband.
Anyone who does this is crazy. Any client that allows you to send a 10
meg file inband should be patched immidiatly or at least have a big fat
warning screen when you attempt this kind of thing. It's exactly what I
mean, IMHO inband is not *meant* for sending large amounts of data, at
least not on the public jabber network. Anyone who will try this will
run into karma problems or discover that it's too slow.
>> 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.
>But if the server admin doesnt want that particular traffic going
>through their server then who are we to force them into allowing it?
>And sure have everything not blocked by default but the server admins
>need the *option* to block it, I dont see why you are so against
>allowing the server admin to control their own server.
Wether Karma is a Jabber Standard or not it's still the best way or
limiting datatraffic. I don't understand why you would specifically
target jabber:iq:inband like this. Can I send SOAP attachments if I do
SOAP over Jabber? Can I send SVG-XML along with a message? Am I allowed
to make 20 XML-RPC requests per second? All these things can take a lot
more traffic. Even message/presence can take up more. So why should
jabber:iq:inband be specifacally targeted? It's gonna cripple clients
who want to use it.. jabber:iq:inband will be blocked by admins for the
wrong reasons and will still be faced with the problem that people can
use more bandwith then they want to give them.
>> 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
>> 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*.
>Exactly it is the amount potensially, but also what about companies
>who do not allow external file transfers or file transfers of any kind?
I still don't see why the amount of inband data would be larger then
other kinds of datatraffic. And I still don't see what good will come
from blocking my clients from sending 2000 bytes of inband data. Alsp
inband data doesn't just have to be filetransfers, there are plenty of
other purposes for it, wich will all be lost if we decide to block it
out of some kind of irrational fear.
>What maybe needed instead is some way of limiting the amount of data
>someone can send inband at the server end in any one transfer, so you
>can stop people sending 12MB MP3 files, but allow tiny graphics or
>ring tones. Maybe by limiting the size of each sequence that can be
>sent, and also the amount of sequences.
I like the sound of this a lot better. I still don't agree with those
fears for jabber:iq:inband, at least not when you neglect eg. SOAP over
Jabber and other things. But I asume you're not the only one worried,
so it's a nice compromise!
>Say if each chunk can be 5K and you want to allow up to 50K transfers
>you would allow a sequence up to 10.
Maybe a limit for chunks should be in the JEP anyway? I'd rather see a
limitation for the number of chunks allowed per hour/minute then a hard
limit on the sequence number, cause inband can also be used for more
persistant streams wich wouldn't have to take much data at all.
Java/J2ME/GPRS Software Engineer @ Splendo
More information about the Standards