[standards-jig] IBB: Making it all "go"
dizzyd at jabber.org
Wed Apr 9 16:48:37 UTC 2003
On Wednesday, Apr 9, 2003, at 03:55 America/Denver, Richard Dobson
> I think this is perfectly valid and it should not really be the servers
> responsibility to protect the low bandwidth client or other clients
> file transfer packets that get directed to them (that were not really
> intended for them since another resource went offline), IMO the file
> transfer packets should never be able to goto another resource and also
> should not get stored offline which really means they should be using
> instead of message, also if iq is used there isnt really a need for
> the seq
> stuff, since only one packet will be being sent at once, the only
> problem is
> this may slow the transfer down waiting for the responses before
> sending the
> next, but since this is only designed to be used as a fall back and
> for tiny
> files I dont see this as a real problem, IMO iq is definatelly the way
> to go
> as message presents a lot more potensial problems in the long run IMO.
> using iq means it is not unnecessarily dependent on other protocols
> such as
> x:event and x:expire just to fix the problems with using message as
> the data
> transport which IMO are not a problem with iq.
1.) It _must_ be the responsibility of the server to "protect"
low-bandwidth resources. The server is the only place in the system
where that protection can happen. We certainly can't depend upon
clients to respect other client's bandwidth -- if we could, there would
be no need for the concept of karma and rate-limiting.
2.) The _opinion_ that IBB packets should never go to offline is not
universally shared. Why do you want to force a single behaviour when
you could have both for free?
3.) Regardless if we use <iq> or <message>, we'll need sequence
numbers. We've already been over this.
4.) Relying on x:event and x:expire is _not_ a bad thing -- that's what
they are there for. They are behavioral modifiers that are meant to be
5.) Using <message> as a data transport is specifically what that
element was DESIGNED to do. <iq> is meant as a conversation faciliator,
not general purpose data transport. The design purpose of protocol
elements is an important consideration in this conversation since we
are discussing a protocol extension. Protocol extensions should always
blend with the environment in which they exist.
This whole argument around <iq> and <message> almost makes me wonder if
certain people would just prefer to get rid of <message> and mix all
the semantics therein into the <iq> element. It doesn't make any sense
More information about the Standards