[standards-jig] IBB: Making it all "go"
dizzyd at jabber.org
Tue Apr 8 22:44:24 UTC 2003
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
"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!
More information about the Standards