Am 20.08.2008 um 20:16 schrieb Peter Saint-Andre:
I posted that to this list. Did you not read what I said?
Seems I don't get it…
I was talking about c2c here.And that makes a big difference how?
As already discussed here, some clients have problems when it's inbound and not a socket. And they need to handle a stream inside a stream. Clients who can only handle one connection like mcabber will very likely miserably fail.
As to TLS encryption of XML streams, Dirk has support for it in his Python code and gloox has some preliminary support (but that was experimental, back when we were first talking about "XTLS"). However, I grant that none of that code is deployed yet.
Then why not depoly it so we actually see how it'll perform in the real world?
Sure there is. See XEP-0246 and XEP-0247.
Sorry? There is ABSOLUTELY nothing about TLS. Or I'm blind.
And they won't need a lot of changes for ESessions? Please.
Not when using Brendan Taylors library, no. For XML Stream in XML, I'm pretty sure some clients might even need changes to the XMPP parser core.
You do in Gajim. I don't in Psi, Adium, Exodus, Trillian, Pidgin, or any other codebase. But all of those codebases support TLS and most of them are adding Jingle support, thus enabling negotiation of end- to-end streams, then you just upgrade the stream via STARTTLS. That seems like a lot less work than building ESessions support into all the clients (and no it's not as easy as dropping in a library, because you know that's not how Gajim functions today -- Brendan's C lib is just a promise, not a reality).
Yeah, and none of them supports XTLS, so how is that better? :)
Or maybe we just all need to use Gajim?
No, that's not an option. The solution is to add support to other clients as well :).
Shall we bet on that?
Sure, I'm pretty sure no client has a stable release in a half year that supports it. Not even an alpha. Maybe in SVN and very unstable, but not more.
And deployment of TLS is merely theoretical? Yes it is for end-to- end XML streams (so far), but it's not for client-to-server streams or server-to-server streams, and extending that model to e2e streams seems quite reasonable.
Why you keep mentioning c2s TLS again and again? This is totally different. That doesn't need another stream. That doesn't need jingle. That doesn't need the client to handle multiple XML streams at once. Etc., etc., etc. For example, mcabber can only handle one XML stream at once and IIRC, it is not easy to fix that. How should XTLS be done there? ESessions would be possible…
-- Jonathan
PGP.sig
Description: This is a digitally signed message part
