[OTR-dev] OTRv3 instance tag and session switching

[M. D.]

 >Error Messages and Query Messages aren't handled by ConnContexts.  If
 >they cause Alice to try to start a new session, new sessions will start
 >with a Commit Message with a receiver instance 0, so that any instance
 >of Bob may respond.  In libotr, this is implemented via a "master
 >context" that remembers (for v3) just the secrets used to construct the
 >Commit Message.  But this implementation detail is not part of the spec;
 >you can implement it however you like.

Okay, things are much more clear now! Thank you very much!

I have just one more question: do every ConnContext maintain its own Message_State and Policy? It seems to me that things become much more complicated if the 'master context' policy and message state are not in sync with its slave's conn contexts. Am I right?

Regards,
Marin



 >-------- Оригинално писмо --------
 >От:  Ian Goldberg 
 >Относно: Re: [OTR-dev] OTRv3 instance tag and session switching
 >До: otr-dev at lists.cypherpunks.ca
 >Изпратено на: Вторник, 2013, Декември 10 15:17:33 EET
 >
 >
 >On Tue, Dec 10, 2013 at 12:44:03PM +0200, M. D. wrote:
 >>  Hello again,
 >> 
 >>  >I'm not sure what you mean by this.  Alice's OTR software will see one
 >>  >Commit message with sender tag 0x102 and one with tag 0x103.  It will
 >>  >then send one Key message with sender 0x101 and receiver 0x102, and one
 >>  >Key message with sending 0x101 and receiver 0x103.  The two key
 >>  >exchanges will proceed entirely independently, and Alice will end up
 >>  >with two ConnContexts (in libotr terms), one for each of Bob1 and Bob2.
 >> 
 >> Okay, so Alice has two ConnContexts... What is going to happen if
 >> Alice receive an Error Message or Query Message? They do not contain
 >> instance tags so which one of Alice's two ConnContexts will handle the
 >> message?
 >
 >Error Messages and Query Messages aren't handled by ConnContexts.  If
 >they cause Alice to try to start a new session, new sessions will start
 >with a Commit Message with a receiver instance 0, so that any instance
 >of Bob may respond.  In libotr, this is implemented via a "master
 >context" that remembers (for v3) just the secrets used to construct the
 >Commit Message.  But this implementation detail is not part of the spec;
 >you can implement it however you like.
 >
 >> I think these are details that are worth mentioning in the protocol draft.
 >
 >Yes, likely so.
 >
 >   - Ian
 >_______________________________________________
 >OTR-dev mailing list
 >OTR-dev at lists.cypherpunks.ca
 >http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
 >