[OTR-dev] Re: SMP state machine broken?

[Uli M]

Hi Ian,

thanks for your answer, I do see things more clearly now :)

On 2008-06-03, Ian Goldberg <ian at cypherpunks.ca> wrote:
[snip]
> This is part of the current API problems we're working on cleaning up.
> Right now, there's some stuff libotr does for you, and some you need to
> do in the calling application.  This was done to avoid adding another
> callback (since the application, not the library, needs to handle
> certain cases), but I agree that it's very messy, and one or more
> callbacks will be the way it'll be handled in v4.

That sounds like a good idea to me.

> For now, see the UPGRADING file in the libotr source to see how to add
> the necessary support into your application.

That file was indeed my only source of information when implementing
SMP and I see now that the code snippet in there is meant as a
template for applications and not (as I understood it) as a
description of the libotr implementation. What misleaded me was that
it is first said

	"You may access context->smstate->nextExpected to find out
	which TLV should come next"

and then it says

	"A typical control flow looks like this:"

Because of this introduction and the fact that nextExpected is not
only read but also written to in the code snippet I assumed this is
libotr code. I imagine other people could misunderstand this as well.

> Also, you can find the current cvs at sourceforge:
>
> http://sourceforge.net/cvs/?group_id=128860

Thanks! One thing I noticed in the diff to 3.1.0 is that apparently
something like s/3.1.0/3.2.0/ was applied to the code which lead to a
passage that states that fragmentation was introduced in 3.2.0. I'm
guessing that is not meant to be.

Thanks,

Uli