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

Justin Karneges justin-jdev at affinix.com
Thu Apr 10 03:19:18 UTC 2003


On Wednesday 09 April 2003 06:46 pm, Rachel Blackman wrote:
> If the behavior adopted for <message/> in terms of offline storage and
> redirection is sufficiently troublesome in this situation, then maybe it
> needs to be examined overall?  Or else perhaps the definition of what IQ is
> and what message is needs to be clarified? :)

For the sake of this discussion, it seems what we need is a stanza-type that 
can be directed to a specific resource (bypassing the typical priority 
routing/spooling rules of <message>) but one that does not require an ack 
(avoiding the extra turn-around of <iq>).  Either of these types could do the 
job, but not without a clarification in their usage.  The problem with 
changing their behavior is that it would break compatibility with existing 
servers.

However, even if we could have this magical stanza, I still question the need 
to have "un-acked" packets.  The only reason I can think of would be to speed 
up the transfer, but do we really care about speed with IBB?  And if we do, 
how much complication to the protocol is it worth?

We need flow-control, otherwise we would easily end up with packet-pileup, as 
Tijl mentioned.  A Jabber client is only aware of the flow between itself and 
the server, but not beyond.  You suggested the use of message delivery 
events, which is a good idea because it gives the possibility of selective 
acks.  But how often should acks be requested, and for which entity's 
benefit?  Without mandatory acking, we also must introduce a way of tracking 
for missing packets, hence the idea of the sequence counter.

Of course, the reality is that even with these complications, there are still 
problems with <message> delivery that would need to be addressed.  So it 
comes down to:

message: extra complication, existing problems, possibly faster
iq: no complication, no problems, slower

Which do we want?

-Justin



More information about the Standards mailing list