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

Richard Dobson richard at dobson-i.net
Tue Apr 8 23:26:26 UTC 2003

Also what about using a jabber:x:expire of a few minutes on the message 
packets to make sure they wont get stored for too long.

But I do see the problem of easier denial of service if message packets 
are used in this manor to transfer the data rather than iq, i.e. 
sending lots and lots of packets that get stored offline and then when 
they are delivered to the user could hold up their connection for ages 
or maybe even cause a karma problem (does karma affect the direction of 
server to client?).


On Tuesday, April 8, 2003, at 11:44  pm, Dave Smith wrote:

> Greetings,
> I'd like to take a moment and summarize the discussion and excellent 
> ideas that have been bounced around the past few days and see if we 
> can manage to reach some form of consensus about what needs to be done 
> to get the IBB JEP "complete".
> 1.) Drop the prevseq attribute; cap the maximum value of the "seq" 
> attribute to be the max value of a 32 bit unsigned integer. A sequence 
> counter is essential to this protocol, since it's possible to miss 
> packets in a sequence -- this does not conflict with the XMPP draft, 
> since the draft does not make any guarantees about guaranteed 
> delivery, just guaranteed order. This simplifies the 
> usage/implementation of IBB, but does require implementors to deal 
> with a "wrap around" by ending the current IBB session/stream and 
> starting a new one. However, this seems to be an acceptable tradeoff, 
> given that this protocol isn't meant for anything more than 
> light-weight usage. Or, as the current JEP says,
> "It is likely to be useful for sending small payloads, such as files 
> that would otherwise be too cumbersome to send as an instant message 
> (such as a text file) or impossible to send (such as a small binary 
> image file). It could also be useful for any kind of low-bandwidth 
> activity, such as a chess game or a shell session. And, while it is 
> mostly intended as an ultra-fallback for when a SOCKS5 Bytestream is 
> unavailable, IBB could be more desirable for many of the simpler 
> bytestream use-cases that don't have bandwidth requirements."
> 2.) Use <message> instead of <iq> for each packet. This will minimize 
> the amount of responses required by a given implementation, and with 
> judicious use of the jabber:x:event namespace (JEP 22) could still 
> permit flow control to be provided.
> 3.) The JEP should explicitly state that the session ID is 
> specifically bound to a JID. I.e. it's perfectly acceptable to have 
> duplicate sessions IDs from different JIDs, but those sessions MUST be 
> considered to be separate.
> 4.) Clarify the error states in the JEP, so that the behavior of the 
> stream in error conditions is well specified. In my mind, this is the 
> only outstanding point of discussion. The clarification should detail 
> what happens specifically when:
> 	4a.) The target goes offline (for any reason)
>  	4b.) The target wishes to abort the stream
> 	4c.) How the initiator deals with bounced packets
> I think that's it. It seems like we're mostly agreed about what needs 
> to happen. Let's just get it done so there can be some 
> implementations! :)
> Diz
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig

More information about the Standards mailing list