[standards-jig] NEW JEP: Inband Bytestream (JEP-0047)
richard at dobson-i.net
Mon Sep 30 13:02:53 UTC 2002
> 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.
> 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.
> 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. 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. 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.
More information about the Standards