Message-ID: <748932C0-3A1B-4A61-ADD4-F69A090885F0@dreskin.net>
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-18-400032831
Content-Type: multipart/alternative; boundary=Apple-Mail-17-400032712
--Apple-Mail-17-400032712
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
On May 30, 2007, at 7:11 PM, Paul Wouters wrote:
> Actually, the OS should signal the application just before going to
> hibernation. I am not sure if Linux does this properly, but I think
> Adium on OSX properly handles this
The Adium bit is partially true. Adium receives a "will sleep"
notification, responds with "wait until I say so", disconnects all
accounts, then says "okay, proceed with sleep".
When Adium was using gaim-otr, from Adium 0.80 through Adium 1.0,
this led to proper behavior, as the signed-on and signed-off signals
are used by gaim-otr as described. I nearly replied, "Yes, Adium
does this properly," but a nagging feeling made me check the Adium 1.0
+ code... and when I ported gaim-otr to being an Objective-C Adium
component for 1.0, that bit didn't get carried over. I've put it on
my to-do list for Adium... I'm glad that came up in discussion :)
-Evan
--Apple-Mail-17-400032712
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=ISO-8859-1
On May 30, 2007, =
at 7:11 PM, Paul Wouters wrote:
Actually, the OS should =
signal the application just before going to
hibernation. I am not sure if Linux =
does this properly, but I think
Adium on OSX properly handles this
=
The Adium bit is partially true.=A0 =A0Adium =
receives a "will sleep" notification, responds with "wait until I say =
so", disconnects all accounts, then says "okay, proceed with =
sleep".=A0=A0
When Adium was using =
gaim-otr, from Adium 0.80 through Adium 1.0, this led to proper =
behavior, as the signed-on and signed-off signals are used by gaim-otr =
as described.=A0 I nearly replied, "Yes, Adium does this properly," but =
a nagging feeling made me check the Adium 1.0+ code... and when I ported =
gaim-otr to being an Objective-C Adium component for 1.0, that bit =
didn't get carried over.=A0 I've put it on my to-do list for Adium... =
I'm glad that came up in discussion :)
-Evan
=
--Apple-Mail-17-400032712--
--Apple-Mail-18-400032831
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGXhRII5gp6xQhrvcRAlWfAKClAgN5JE7chimCSWs35xsGZMd2wgCfTTPi
pkGkW0IZVXbByW91L/l7msU=
=YKGh
-----END PGP SIGNATURE-----
--Apple-Mail-18-400032831--
From marti@juffo.org Thu May 31 06:37:32 2007
From: marti@juffo.org (Marti Raudsepp)
Date: Thu, 31 May 2007 08:37:32 +0300
Subject: [OTR-dev] session termination
In-Reply-To: <48C81888-D241-46C0-BB9A-B495D90FF33F@singleclick.com>
References: <4656B312.4060604@gmx.net>
<465C07E8.90608@gmx.net>
<465C2F52.7070300@gmx.net>
<465C54DF.3080901@gmx.net>
<465D4084.10409@gmx.net>
<48C81888-D241-46C0-BB9A-B495D90FF33F@singleclick.com>
Message-ID: <2a12af650705302237u2151fae8jfe148ae0721ac957@mail.gmail.com>
On 5/30/07, Joseph Elwell wrote:
> It's as if the Mac has the port stuck and won't
> let OTR Proxy have access to the port.
I haven't followed the rest of this discussion, but this problem seems
similar to what happens on Linux -- connections will remain in
TIME_WAIT state for some time after they have been disconnected, and
this prevents programs from binding to any of the ports used by the
connection. There's a cure for it -- SO_REUSEADDR.
If you can be bothered, you might want to try if setting it before
binding the socket.
Marti
From donny.viszneki@gmail.com Thu May 31 21:38:15 2007
From: donny.viszneki@gmail.com (Donny Viszneki)
Date: Thu, 31 May 2007 16:38:15 -0400
Subject: [OTR-dev] session termination
In-Reply-To: <2a12af650705302237u2151fae8jfe148ae0721ac957@mail.gmail.com>
References: <4656B312.4060604@gmx.net> <465C07E8.90608@gmx.net>
<465C2F52.7070300@gmx.net>
<465C54DF.3080901@gmx.net>
<465D4084.10409@gmx.net>
<48C81888-D241-46C0-BB9A-B495D90FF33F@singleclick.com>
<2a12af650705302237u2151fae8jfe148ae0721ac957@mail.gmail.com>
Message-ID: <44acbb800705311338u23c36496la2a3a43f4de06909@mail.gmail.com>
TWICE I thought I had sent this to the list, and twice I had only sent
it to individual posters on the mailing list ("reply ot all" was the
default reply behavior on my previous mail client.)
> 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 wouldn't necessarily describe this as a "bug," nor would I describe
the miranda plugin as the source of it. I would describe this as an
acceptable, even preferable, design limitation of OTR. The real
"source" of the problem is -- it seems to me -- latency and/or
unavailability of the networking substrate underlying the channel over
which both encrypted discussion, and negotiation of discussion
sessions take place. In the case of OTR, this is usually an instant
messaging service, but it's worth noting that in actuality it could be
any medium over which arbitrary text can be exchanged between users.
Consider this: What if a Miranda user is suddenly disconnected from
their instant messaging service or the internet? What if your client
or computer crashes? What happens to encrypted messages that are sent
to you?
Case 1: If the IM service doesn't wait for any sort of message
receipt, those messages disappear into the ether (this is the case on
AOL/AIM, and IRC.)
Case 2: The IM service does expect a message receipt, and eventually
returns an error to the sender of the message, telling them that their
message didn't make it.
Case 3: The IM service both waits for message receipt, AND queues its
users' messages for them so that they can receive messages sent in
their absence once they reconnect. (This is the case on many Jabber
servers. GTalk once was case 1, now it too is case 3. And ICQ was once
case 3, but I don't know what they do since AOL got them.)
The common occurance of this "error" is caused by a Case 3 service, in
this type of service there exists a unique potential for extreme
latency on the networking substrate. It happens because you end up
with an asymmetrical OTR state between two individuals; that is, one
user believes there is still an OTR session, and the other user does
not. I get these "Unreadable message" errors about a couple times a
week using Jabber, and I accept it because I _understand_ three
things:
One, that on a Case 1 IM service the unreadable OTR messages will
simply disappear into the ether.
Two, that OTR is itself a sort of point-to-point IM service tunneled
through another IM service.
Three, that this message ought to have disappeared into the ether,
because OTR is -- for good reason -- not a Case 3 service.
So what seems like an error message is actually just extra
information: on most Case 1 services you simply would never have known
that a message was sent to you that never got there because you
weren't connected at the time. But because OTR is privy to the fact
that there WAS a message that was lost, it tells you so. And most
people don't understand that it's not an error, it's just extra
information.
I believe that making OTR a case 2 service is not out of the question.
Perhaps OTR should be able to report to the user whether or not their
messages are actually being received. This simply means waiting for an
ACK after each message is sent.
Some questions that may be relevant that I don't know the answer to:
Can OTR messages during an encrypted session be received out of order?
Will the messages be readable? Will OTR notice that they are out of
order?
I think a case 3 situation for OTR would be very inadvisable. To have
OTR cache outgoing private messages so that it can re-deliver them in
a possible future session in case they accidentally lost the current
one seems to me to be a dangerous idea, counterproductive to the goal
of privacy.
In short, yes it is nice when OTR reacts when I disconnect from my IM
services by telling my friends to end their OTR sessions. But because
of complications that have already been mentioned on this mailing list
(you don't receive "buddy-online" notifications for everyone you might
want to use OTR with,) it really only helps avoid a very small number
of "unreadable message" "errors."
Best Solution, IMHO:
Include an explanatory hyperlink, a la:
(05:03:16 PM) Unverified
conversation with someuser started.
On 5/31/07, Marti Raudsepp wrote:
> On 5/30/07, Joseph Elwell wrote:
> > It's as if the Mac has the port stuck and won't
> > let OTR Proxy have access to the port.
>
> I haven't followed the rest of this discussion, but this problem seems
> similar to what happens on Linux -- connections will remain in
> TIME_WAIT state for some time after they have been disconnected, and
> this prevents programs from binding to any of the ports used by the
> connection. There's a cure for it -- SO_REUSEADDR.
>
> If you can be bothered, you might want to try if setting it before
> binding the socket.
>
> Marti
> _______________________________________________
> OTR-dev mailing list
> OTR-dev@lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
>