On Wed, Jun 8, 2011 at 00:50, Christian Anderson <[email protected]> wrote: > 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?
The type of the key can be determined from the fingerprint. For now I'm leaving key handling/storage entirely for the client, out of dbus. When I get to the client coding part I'll check how to store it, but I personally would like to have this stored in a common secure place, like seahorse (for gnome), where different clients could share it. But it's still something to be better analysed, since it should be WM-independent and I don't know if freedesktop.org says something about key storage. > *Why are Versions and RequireEncryption duplicated on the Connection and > the Channel but the other properties are not? These are the only properties I think should be allowed to have different values for different channels on the same connection. > *I think you should specify the meaning of the boolean in the > PeerAuthenticationConcluded signal. > Yes, I missed it. > 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: > This are only the states exposed to the client, so it knows what to do when receiving a signal. I think it's necessary to add this ability to the client to be able to honor the FINISHED state, as explained bellow. > *What happens if I call RequestSession while in the REQUEST_RECEIVED > state and then realize I want to accept my peer's session request Yep, rethinking it would be better to just ignore this method call on REQUEST_RECEIVED, or return an error to the client. > *What happens when I receive a session request while in the FINISHED state? > As stated in the protocol description, the only way to leave this state is through an user action. So we should not automatically start the AKE despite which policy is set. So we should act exactly like when receiving it in the PLAINTEXT state without AutoAccept enabled. > 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. > I think all of this situations can be worked out during the implementation. > 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? > 1. A whitespace-tagged message. If AutoStart, starts the AKE and transition to AKE_STARTED. Otherwise do nothing and stay on PLAINTEXT. 2. An OTR error message. If there is any version allowed (Versions is not empty), starts the AKE. This is not explicitly exposed to the client. 3. An OTR query message. If AutoAccept, starts the AKE and transition to AKE_STARTED. Otherwise do nothing unless instructed by the client to do so (calling AcceptSession). 4. A DH-commit message. 5. Version 1 key exchange message Usually the peer wouldn't start the AKE without requesting it first (but IIRC is not prohibited by the protocol). In these cases the CM should react as stated on the protocol description, depending on its AKE state (since internally, there will be all the states from the protocol description). All corner cases that could arise in this phase are previewed there. Thanks for the feedback, I've updated the API description and will upload to the same links. -- João Paulo Rechi Vita http://jprvita.wordpress.com/ _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
