[standards-jig] IBB: Making it all "go"
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
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?
More information about the Standards