[standards-jig] IBB: Making it all "go"

Dave Smith dizzyd at jabber.org
Wed Apr 9 16:48:37 UTC 2003


On Wednesday, Apr 9, 2003, at 03:55 America/Denver, Richard Dobson 
wrote:

> I think this is perfectly valid and it should not really be the servers
> responsibility to protect the low bandwidth client or other clients 
> from
> 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 
> iq
> 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. 
> Also
> 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 
used.

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 
to me.

Diz




More information about the Standards mailing list