[standards-jig] UPDATED: IBB (JEP-0047)
thoutbeckers at splendo.com
Tue Mar 25 18:17:23 UTC 2003
Justin Karneges <justin-jdev at affinix.com> wrote on 25-3-2003 4:03:39:
>On Monday 24 March 2003 05:07 pm, Tijl Houtbeckers wrote:
>> Why a 16bit integer maximum? (why not 32bit wich would be practically
>We (temas, matthew miller, and I) discussed the issue of sequencing
>packets recently. There was a divide in our way of thinking: I
>wanted an incrementing counter, while matthew suggested the use of an
I'm all for an incremental counter. I don't think there any systems
still out there that have difficulties processing 32bit integers though
(you don't have to run on a 32-bit architecture for that.) But 16-bit
is fine too I suppose.
>> Is the value of newseq always "0" or must it be incremented
>> each time a new sequence ends?
>In my vision, you'd always set it to zero, to indicate that you are
>starting over. But then if you're always setting it to zero, the
>value is pretty useless. May as well just say newseq="true".
newseq="true" would indeed prevent that kind of confusion.
In theory there is no garantueed order of delivery. I could generate
2*65535 packets and recive the last packet first. I have no way of
knowing wich sequence it would be belong to, except...
>Perhaps a better idea would be to have a lastseq attribute:
><iq type="set" id="inband_1" to="joe at blow.com/Home">
> <query xmlns="http://jabber.org/protocol/ibb" sid="mySID" seq="0"
>Normally, an IBB implementation should queue packets in order to
>ensure proper sequence. Each packet essentially as a dependency: the
>packet before it. When the maximum counter is reached, lastseq could
>be used to indicate a different dependency, as opposed to seq-1 (the
If you propose the lastseq="65535" is send along with every packet in
the new sequence (and lastseq="131070" for the sequence after that, but
then we overflow the 16-bit int again). Another idea could be
generating a new sid for every sequence:
<iq type="set" id="inband_1" to="joe at blow.com/Home">
<query xmlns="http://jabber.org/protocol/ibb" sid="mySID1"
If you happen to receive any packets out of order with a sid you don't
know yet you could keep them for a while.
>> A mechanism to allow other things as Base64?
>I say no. To maximize compatibility, we should enforce one encoding.
Compatability is nice, but at what price?
In any case I do propose support for Base64 would be mandatory (clients
MUST support Base64). Base64 is actually pretty good on UTF-8, but
horrible inefficient on UTF-16 (why use 6 bits when you can use at
least 15? using 8 or 12 would be much more efficient in any case).
Because I can see a possible need for this, I wonder why there should
be a seperate JEP that is almost exactly the same except for the name
of the namespace and the encoding. My "choice-is-good" aditute on this
subject has come up before I guess..
Also, in the examples I don't see any IQ type="result" packets send out
any longer when a data-packet is received (I believe there used to be
in your last proposal for IBB). Is this done on purpose? (bandwidth
concerns?) Or should we still send them? (in wich case it should be in
the example to be clear). If we wouldn't send them, isn't that a bit
against the nature of IQ?
Software Engineer @ Splendo
More information about the Standards