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

Dave Smith dizzyd at jabber.org
Tue Apr 8 22:44:24 UTC 2003


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




More information about the Standards mailing list