No subject

"MSGSTATE_FINISHEDThis state indicates that outgoing messages are not
delivered at all. This state is entered only when the other party indicates
he has terminated his side of the OTR conversation. For example, if Alice
and Bob are having an OTR conversation, and Bob instructs his OTR client to
end its private session with Alice (for example, by logging out), Alice will
be notified of this, and *her* client will switch to MSGSTATE_FINISHED mode.
This prevents Alice from accidentally sending a message to Bob in plaintext.
(Consider what happens if Alice was in the middle of typing a private
message to Bob when he suddenly logs out, just as Alice hits Enter.)"My
question is this: does the fact that Bob went offline not qualify as an
indication that he has terminated his side of the OTR converstaion?
Shouldn't the client call the 'otrl_force_finished' function in this
situation, rather than requiring the reception of a termination message? It
seems to me there are a few problems with the method if this is not the
case, when compared to the alternative of ending sessions when either the
client detects that the user on the other side has gone offline *or* it gets
a session termination message:

1) the bug described above will still happen if the user is disconnected
'involantarily', e.g. due to network problems, or (heaven forbid) their
client crashes, etc.
2) it doesn't seem to solve the problem described in the spec any better
than the alternative
3) it can add unwanted delays when the user is attempting to switch status,
e.g. when using a protocol with full message acknowledgement
4) protocol implementations may well discard pending messages when going
offline, if their specification provides no guarantees of delivery
5) it causes problems with protocols that allow offline messages, such as
ICQ and Jabber
6) it's problematic coping with system shutdown

The only benefit of using a termination message is that you can go offline
and back online without renogotiating the session if you don't quit the
client, as far as i can see. Obviously not worth it, imo.

Currently the miranda plugin is using the alternative method and does not
send an OTR termination message when going offline (which is the source of
the bug). I'm in the process of finding a way to comply with the spec in
terms of sending the message before going offline (and will do if that is a
better option than changing the gaim plugin), but I thought I'd leave in the
logic regarding the status of the other end anyway. I thought I'd bring it
up in case someone can point out something I'm missing, or any problems with
using the user's status change to offline to initiate the OTR state change
to MSGSTATE_FINISHED.

Scott

------=_Part_92308_17879270.1177825666237
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi All,<br><br>Had the following bug report from a miranda user talking to a gaim user (thx Zeffel):<br><br>"Scenario:<br>
<br>
Chat "blabla".<br>
Miranda user goes offline.<br>
Gaim OTR doesn't seem to notice this.<br>
Gaim user sends Miranda user offline message.<br>
When Miranda user goes back online, he receives: '[OTR Message] The
encrypted message received from Gaim user is unreadable, as you are not
currently communicating privately.'<br>
<br>
So Gaim OTR still sends an encrypted message, though Miranda user went
offline. Miranda user can't decrypt the message any more."<br><br>From the OTR protocol description:<br><br>"MSGSTATE_FINISHED<dl><dd>This state indicates that outgoing messages are not delivered at
all.  This state is entered only when the other party indicates he has
terminated his side of the OTR conversation.  For example, if Alice and
Bob are having an OTR conversation, and Bob instructs his OTR client to
end its private session with Alice (for example, by logging out), Alice
will be notified of this, and <em>her</em> client will switch to
MSGSTATE_FINISHED mode.  This prevents Alice from accidentally sending a
message to Bob in plaintext.  (Consider what happens if Alice was in the
middle of typing a private message to Bob when he suddenly logs out,
just as Alice hits Enter.)"</dd></dl>My question is this: does the fact that Bob went offline not qualify as an indication that he has terminated his side of the OTR converstaion? Shouldn't the client call the 'otrl_force_finished' function in this situation, rather than requiring the reception of a termination message? It seems to me there are a few problems with the method if this is not the case, when compared to the alternative of ending sessions when either the client detects that the user on the other side has gone offline *or* it gets a session termination message:
<br><br>1) the bug described above will still happen if the user is disconnected 'involantarily', e.g. due to network problems, or (heaven forbid) their client crashes, etc.<br>2) it doesn't seem to solve the problem described in the spec any better than the alternative
<br>3) it can add unwanted delays when the user is attempting to switch status, e.g. when using a protocol with full message acknowledgement
<br>4) protocol implementations may well discard pending messages when going offline, if their specification provides no guarantees of delivery<br>5) it causes problems with protocols that allow offline messages, such as ICQ and Jabber
<br>6) it's problematic coping with system shutdown <br><br>The only benefit of using a termination message is that you can go offline and back online without renogotiating the session if you don't quit the client, as far as i can see. Obviously not worth it, imo.
<br><br>Currently the miranda plugin is using the alternative method and does not send an OTR termination message when going offline (which is the source of the bug). I'm in the process of finding a way to comply with the spec in terms of sending the message before going offline (and will do if that is a better option than changing the gaim plugin), but I thought I'd leave in the logic regarding the status of the other end anyway. I thought I'd bring it up in case someone can point out something I'm missing, or any problems with using the user's status change to offline to initiate the OTR state change to MSGSTATE_FINISHED.
<br><br>Scott<br>

------=_Part_92308_17879270.1177825666237--