[standards-jig] UPDATED: IBB (JEP-0047)
justin-jdev at affinix.com
Tue Mar 25 03:03:39 UTC 2003
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 accurate
The trouble with a timestamp is that it can never be accurate enough (consider
that any Jabber lib should be capable of generating multiple IBB packets on
microsecond terms). The trouble with a counter is that it can overflow.
One argument against the counter is that it would be difficult to assemble a
large integer on some platforms. I chose to use 16-bit in the draft to
eliminate the argument. The ability to restart the sequence prevents
> 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".
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 default).
> A mechanism to allow other things as Base64?
I say no. To maximize compatibility, we should enforce one encoding.
More information about the Standards