On 06/04/2011 07:36 PM, João Paulo Rechi Vita wrote: > When writing down the whole API I've realized that "in progress" > should actually be broke down into tree states: REQUEST_SENT, > REQUEST_RECEIVED, and AKE_STARTED. > > After finding my way through telepathy-spec XML syntax, I've managed > to write down whole API proposal and uploaded it at > > http://www.las.ic.unicamp.br/~jprvita/telepathy-spec-otr/spec/Connection_Interface_OTR.html > http://www.las.ic.unicamp.br/~jprvita/telepathy-spec-otr/spec/Channel_Interface_OTR.html > > I left key storage and peer authentication information storage > completely for the UI, that's why it doesn't appear on the proposal > above. > > I've also uploaded my sketch of the state machine, since it may help > following the spec: > http://www.las.ic.unicamp.br/~jprvita/telepathy-spec-otr/state_machine.jpg >
Thanks for the concrete proposal! Small questions: *Should PeerKeyReceived broadcast the type of the received key? Did you decide not to have d-bus objects corresponding to the keys? *Why are Versions and RequireEncryption duplicated on the Connection and the Channel but the other properties are not? *I think you should specify the meaning of the boolean in the PeerAuthenticationConcluded signal. I also have a number of questions related to handling "OTR overtures". There are 5 ways that a peer, implementing the OTR spec, might initiate communication with us: 1. A whitespace-tagged message. 2. An OTR error message. 3. An OTR query message. 4. A DH-commit message. 5. Version 1 key exchange message You have introduced the states REQUEST_SENT and REQUEST_RECEIVED to give the client the freedom of accepting and rejecting sessions on the fly. Is it worth the extra complexity? Why not just handle each of the 5 queries based on our channel's policies? As it stands, there are some issues arising from these two states. For instance: *What happens if I call RequestSession while in the REQUEST_RECEIVED state and then realize I want to accept my peer's session request? *What happens when I receive a session request while in the FINISHED state? I think these states add unneeded complexity. I think they are logically problematic because it is quite possible for me to have both "SENT" and "RECEIVED" a request. What I imagine as an alternative is handling each of the 5 overtures based on the policy flags that are set in the associated connection. I am still not sure how each of the 5 overtures is handled depending on the 4 possibles values of (AutoStart | AutoAccept). Could you specify exactly what those two flags mean? christian _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
