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

Matthew A. Miller linuxwolf at outer-planes.no-ip.com
Tue Apr 8 23:19:30 UTC 2003

Overall, this seems much more palatable.  Just a couple of "additional
points (-:

1)  Error states are necessary, but we really should also be explicit
for when we "open" and "close".  I can see this conveyed by either an
attribute (demonstrated) or "verb" element:

EXAMPLE-1 - Open/Create a stream:
<iq type="set" id="inband_1" to="joe at blow.com/Home">
  <query xmlns="http://jabber.org/protocol/ibb" sid="mySID"

EXAMPLE-2 - Close a stream:
<iq type="set" id="inband_3" to="joe at blow.com/Home">
  <query xmlns="http://jabber.org/protocol/ibb" sid="mySID" seq="3"
2)  All IQ-results include the appropriate element in the IBB
namespace.  For instance, (when creating/opening a stream) instead of

<iq type="result" id="inband_1" from="joe at blow.com/Home"/>

it should be

<iq type="result" id="inband_1" from="joe at blow.com/Home">
  <query xmlns="http://jabber.org/protocols/ibb" sid="mySID"

-  LW

On Tue, 2003-04-08 at 15:44, 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

Matt "linuxwolf" Miller
JID:	linuxwolf at outer-planes.net
E-MAIL:	linuxwolf at outer-planes.net

- Got "JABBER"? (http://www.jabber.org/)

More information about the Standards mailing list