[standards-jig] UPDATED: IBB (JEP-0047)

Justin Karneges justin-jdev at affinix.com
Tue Mar 25 03:03:39 UTC 2003


Hi Tijl,

On Monday 24 March 2003 05:07 pm, Tijl Houtbeckers wrote:
> Why a 16bit integer maximum? (why not 32bit wich would be practically
> infinite?)

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 
timestamp.

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 
overflow.

> 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" 
lastseq="65535">
    <data>blahblahblah</data>
  </query>
</iq>

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.

-Justin



More information about the Standards mailing list