[standards-jig] NEW JEP: Inband Bytestream (JEP-0047)
richard at dobson-i.net
Mon Sep 30 14:53:15 UTC 2002
> 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.
> 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.
> 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".
> 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.
> 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*.
Exactly it is the amount potensially, but also what about companies who do
not allow external file transfers or file transfers of any kind?
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
Say if each chunk can be 5K and you want to allow up to 50K transfers you
would allow a sequence up to 10.
More information about the Standards