On Wed, Dec 17, 2014 at 02:55:56PM +0100, Hannes Mehnert wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA384 > > Dear OTR hackers, > > I just implemented reassembly of OTR fragments... > While doing this I stumbled upon (in Protocol-v3): > OTR version 2 messages get fragmented in a similar format, but without > the instance tags fields: > > "?OTR,%hu,%hu,%s," , sender_instance, receiver_instance, k , n , piece[k] > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > I think those arguments should be removed (OTRv2 only uses k, n, > piece[k]).
Thanks, I've fixed this in git. > Furthermore, the protocol description does allow for fragmented > fragments... I'm curious whether there is any use of it? (With my > formal methods background, whenever I write a recursive function > without a (straightforward) termination argument it hurts (tbh, the > termination argument is rather straightforward since fragmentation > prepends and appends some bytes, thus it should all be safe). > I'd explicitly only allow certain messages to be fragmented -- such as > data (query is shorter without fragmentation anyways, ...). > > I'm roughly talking about (where arrows indicate fragmentation, using > v2 here for simplicity (and I didn't try to execute this..)): > ?OTRv2 > --> > ?OTR,1,2,?O, > ?OTR,2,2,TRv2, > --> > ?OTR,1,2,?OTR,1,2,?, > ?OTR,2,2,O,, > ?OTR,2,2,TRv2, > --> > ... Hmm. That certainly isn't the *intent*. I don't see in the spec where it allows fragments to be fragmented. Messages can be fragmented, but fragments aren't messages--they're fragments of messages. And I fully agree with the "formal argument for termination of recursive functions", of course. I teach that myself. ;-) But this function is not intended to be recursive at all. Can you point to where the spec misled you or was unclear? I'd certainly like to fix that. Thanks, - Ian _______________________________________________ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev