[OTR-dev] New OTR Protocol draft: please look over

[Paul Wouters]

On Thu, 6 Oct 2005, Ian Goldberg wrote:

> On Thu, Oct 06, 2005 at 08:45:19PM -0400, Greg Troxel wrote:
>> I suggest considering adding an id field to fragments.  Right now
>> fragments can be misassembled if the transport doesn't actualy do
>> in-order delivery.  The reassembly rules protect against this if n is
>> different, or k isn't K+1, but don't do so strongly.  Just having a
>> fragment id and incrementing it and requiring that it match would
>> help.  But, this may not be worthwhile because lack of ordering would
>> perhaps cause so many other problems, and it does take up space.
>
> Indeed, if the network reorders messages, all kinds of things go wrong
> (not security-wise, of course, but sessions won't get set up properly,
> or messages won't be readable).

But the fragments have an "id", right? The spec said:

?OTR,<fragmentnumber>,<totalfragments>,data

So in this case you could just save the fragments (within reason) and
reassemble them when you have all the fragments.

Though I guess it hardly makes sense to do so, because for any non
fragmented OTR message, you wouldn't be able to properly read it,

I think the assumption here is that messages can never be delivered
out of order, and if you receive a fragment while missing the 
previous fragments, you disgard all of them and return an error.

Paul