[standards-jig] IBB Again

Justin Karneges justin-jdev at affinix.com
Sat May 3 07:01:01 UTC 2003

> 1) we should have the ability to ACK at specified intervals and not
> each packet; unreliable all together would be nice, but 'reliable' is
> a false notion here as current IQ implementations won't guarantee the
> packet is delivered.

True, I guess this is not as reliable as TCP then, because clients would not 
take redelivery action.  Maybe 'semi-reliable' is a better term.

Most use-cases of IBB will need this semi-reliable behavior:  Avatar exchange, 
File transfer, Games, Data tunneling, etc.  What kind of use-cases will need 
unreliable behavior?

> 2) It would be nice, but it's not necessary. Doing the 'right' thing
> in the spirit of the protocol is more important.

Well, since you answered 'Yes' to #1, you needn't answer #2. :)  If we need 
unreliability, then message is the obvious 'right' choice.

> I personally think we should wait for message semantics to be
> implemented and use message tags for data transfer in the spirit of
> xmpp.

Where is it written that iq cannot transfer data?  I would argue that using 
message for reliable data transfer is a huge hack, since we had to have a 
whole new JEP written just to force it into iq-style behavior.  However, if 
we need unreliability, then of course we can't use iq.

That's all it really comes down to, IMO.  I think if anyone answers 'No' to 
#1, then #2 should be a guaranteed 'Yes'.  If anyone has a vote of [No, No], 
I'd be interested to hear about it.  Right now my vote is [No,Yes], but I 
could be swayed if you:

a) Show me some use-cases where an unreliable link is needed.
b) Give a reason why we should complicate IBB rather than make a separate 
"unreliable" JEP.

When I proposed JEP-0041 (REL) earlier this week, I was criticized for 
thinking too far ahead.  In particular, pgm noted that we should create 
protocol as needed, rather than try and make some perfect protocol that 
covers cases we don't care about yet.  Keep this in mind when answering the 

> Related to this: we need to augment message semantics (or I need to
> reread it) to allow for acknowledgement of 'delivery' or
> acknowledgement of 'receipt' (yes, I know lw wanted to keep it all
> server side, but it should still be examined)

Acknowledgements, like message events?  I know there was some talk earlier 
that IBB should not rely on a non-standards-track JEP (in this case, -22), so 
maybe these same features should be rolled into -79 ?


More information about the Standards mailing list