interop - 2010-12-09

Good morning, good morning, good morning, good morning, good morning.

Ok, so, is everyone ok with the plan for today?

Set all the test machines to require TLS, check the pings again.

And I'll set up the machines with invalid certs, ready for tomorrow.

That is, for today, set all the machines to require TLS, but not to require *valid* TLS - any certificate should be accepted.

all: can i get an account swift / swift on all servers?

The idea of not putting the account details on that page was so we didn't have public records of the logins.

*sigh*

seriously, for an interop of one week?

ok then :)

They're all openly federating.

If they weren't, it wouldn't be a problem.

ah, i was assuming they weren't

That would mean quite some effort for the server vendors.

true

client certificates are the future :)

Yes, I considered adding those to the test plan, but I don't think anyone other than M-Link supports them. If any other servers do, I'm happy to add it to the plan.

it would be handy to have MUC nicks on the page to know who to ask for logins :)

fippo is psyced (no C2S, I believe), badlop is ejabberd, MattJ/waqas are Prosody, Dave Cridland is M-Link, Florian is Tigase.

remko: ejabberd21 has IBR with CAPTCHA

badlop: swift doesn't do IBR yet :)

i'll create now, but you should use an alternative client for the features your client doesn't yet support

is Test 2 right now, or are we still in Test 1? Test 2 (Thursday). Requiring TLS on all s2s connections on all servers

badlop: Test 2 would be good, please.

badlop: Ok, so, is everyone ok with the plan for today? Kev @ 9:15 Set all the test machines to require TLS, check the pings again. 9:15 And I'll set up the machines with invalid certs, ready for tomorrow. 9:15 That is, for today, set all the machines to require TLS, but not to require *valid* TLS - any certificate should be accepted. 9:16

remko: account created

badlop: super, thanks a lot!

ejabberd21 s2s requires TLS, with a preliminary patch i wrote yesterday, let's hope it works

XMPP Interop Event | 6th - 11th December 2010 | http://wiki.xmpp.org/web/Interop | right now: Test 2 (s2s require TLS)

oh, no room admin here to add to the room subject: | right now: Test 2 (s2s require TLS)

badlop, Yes, PSA mentioned that.

Morning all, BTW.

So, mlinkrelease can't require TLS. It can require a valid cert (ie, one that the chain terminates in a trust anchor), but that's it.

Dave Cridland: what's the difference? meaning you can't require TLS with an invalid cert or what?

Well, if you don't do TLS at all, that's still fine. :-)

ah, right :)

Ok, I've put up the results stubs for today's tests for severs.

Anyone desperate to go first?

You started the trend yesterday.

'kay

SO let's go.

So am I even attempting to test mlinkrelease?

Testing against it, but not testing it, according to the wiki page :)

Kev, Is notls up and running?

Matt was going to do that yesterday, I don't know if he did.

Shouldn't be hard to work out, should it?

Well, I get an error from mlinkrelease.

host-unknown.

So that needs to be up later. The problem is that unless this is running, we can't really test that we're unable to connect to it.

This is true.

Well. Not up later, up now, really. But we'll all have to do the negative testing against it later, I suppose.

But anyway, my first lot of results are (unsuprisingly) that mlinkrelease can still connect to everyone.

The telnet says: <stream:stream id='' xmlns:stream='http://etherx.jabber.org/streams' version='1.0' xmlns='jabber:server'><stream:error><host-unknown xmlns='urn:ietf:params:xml:ns:xmpp-streams'/><text xmlns='urn:ietf:params:xml:ns:xmpp-streams'>This host does not serve notls.xmpptest.com</text></stream:error></stream:stream>

So yes, not up.

OK, mlinktrunk connects to everyone except tigasetrunk - which is expected, as tigasetrunk is actually the same as notls is meant to be.

So I suggest folk test against the full suite anyway.

Well, Tigase isn't quite what notls is meant to be.

notls is supposed to be XMPP, but not supporting starttls.

Tigase is doing jabber/0.9 only, isn't it?

It has the same effect.

It has the same effect for M-Link :)

OK, so I'm done anyway. Wiki updated.

I've updated the testing blurb to indicate that failure against tigasetrunk is required.

Anyone else having a go?

me, ejabberd21 works with all except tigase, as expected

badlop, Cool, so that patch you did yesterday works?

well, at least it doesn't break s2s

\o/

Should test 2 be including a server which does not support TLS, and tries to connect to the other servers. It should be required (of the other servers) that they refuse the connection#

Yes, and it does.

you mean, if tigase were able to connect to any other now, then there's a bug in that other

notls (to be set up later when Matt gets up) will be XMPP 1.0 without TLS, and tigasetrunk is XMPP 0.9/Jabber without TLS.

i think steve.kille refers to testing s2s from notls-server --> supposedly-tls-required

Right, but that's required to get the iq result.

Doing an ping from one server to another requires the setup of streams both ways.

Kev: I think it would be helpful to clarify thing shojuld not work wiht notls, irrespective of wo initiates.

This is true, unless bidi is involved.

We can do that one notls is actually up.

once.

steve.kille: Both parties always initiate (unless bidi is involved).

Kev, Yes, but it won't hurt to test.

Kev, At least one implementation supports bidi, after all.

btw: I tested ssl2 this morning

mlinktrunk, mlinkrelease, prosody and psyced kill the connection, ejabberd does not (yet?) work with that s_client version

Really? I thought we accepted it on inbound, still.

the v2 client hello probably is

fippo, Oh, for sure. But I thought we allowed the protocol inbound too.

indeed, it fails differently - but still fails

Well, no SSLv2 in my logs, certainly.

remko: In-Band Registration is enabled :)

Florian, Want to see if you can reach anyone from tigasetrunk?

so, does anyone have a xep-0055 directory set up on their interop test-y server?

Well, he probably can still reach Prosody, because Matt / waqas aren't about yet.

like vjud.ejabberd21.xmpptest.com ? but s2s to it doesn't work

badlop: Just because of DNS? I don't mind putting up a record.

badlop: for instance! i've not been keeping up with this week—have some kind of plague—but presumably we could also register test accounts on ejabberd21.x.c

I expect Dave Cridland could also be persuaded to enable -55 on mlinktrunk

Kev, I think it is, actually.

Kev, But probably defaulting to local-searches only.

I expect Dave Cridland will have enabled -55 on mlinktrunk.

well, that's grand. let's see if i can get pochu in here... :)

wjt, Our '55 basically allows users to opt-in or opt-out - there's three settings (never visible, visible in local searches, and visible in all searches) plus a default if they don't express a preference.

how do you choose this setting?

wjt, Ad-Hoc.

my very favourite xep

why wouldn't I be able to reach people?

which we might actually implement support for in the new year

Florian: Because today's tests require TLS for s2s.

wjt, M-Link's had ad-hoc controlled user preferences for ages, we use them currently to alloow auto-subscribe, control offline message settings, etc.

ah

See the test plan :)

Dave Cridland: Oh, I'm sure lots of servers do

we have a test plan?

Dave Cridland: doesn't mean I like it very much ;-)

Florian, So if you can reach anyone, then they're broken.

Yes, it's on the wiki page.

but I've softened in my opinion on these matters in recent months

Dave Cridland: Broken, or haven't changet their config for today yet.

ok :)

wjt: Ad-hoc as a concept is great, as a protocol is fine, and as a XEP is lacking.

You're free to disagree with me, of course, everyone has the right to be wrong :)

mlinktrunk is broken

Florian: See the note that says that mlinktrunk isn't participating today :)

Kev, I think wjt doesn't like the lack of i18ness.

Kev: I think it's hard to make UIs for ad-hoc-style random-dialog-boxes-from-the-server beautiful

wjt: Yes, that's right. For things that aren't really ad-hoc, we have profiles so you can know what to expect (RC, Server admin, for example).

i18n is a secondary concern, but this one i really don't mind that much about: in practice, if you're using a server, you probably speak (one of the) same language(s) as its administrator

it says mlinkrelease isn't participating?!

mlinkrelease Not participating - can only require valid certs, or not require - can't require a cert but not care if it's valid.

Right :)

So that'll participate again tomorrow when we require TLS and full cert checking for s2s.

because I can connect to mlinktrunk

Kev, sure, and that's one of the reasons I've softened my opinion on them :)

Oh, mlink*trunk*

yes :)

[11:59:00] <Florian> mlinktrunk is broken :)

Dave Cridland: !

Kev: for the common cases, we can do something nice; for uncommon cases, whatever, it's your own fault for doing weird stuff

Sorry, I just read mlinkrelease without paying attention, my bad.

:)

I guess service discovery shouldn't work

as that's S2S

Correct.

right :)

so yeah ... trunk is broken :)

Although you may need to bounce the server to cancel any existing s2s sessions first, possibly.

ah

Dave Cridland will know if he already did that with mlinktrunk, it's his test server.

interesting ...

Prosody8 gives me a disco title (Server name)

but no contents

right .. the rest fails

florian: it's trying to reconnect rather often (every five seconds)

still now?

yes... let's see if closing the port on my side will stop that

Oh. So I read Florian's message as saying mlinktrunk was *correctly* broken, but what he meant was it's working.

Florian, Ah. WHat server were you connecting *from*?

fippo: it tries to reconnect for a few minutes and then gives up

jabber.me

same host as tigasetrunk

Right, but different domain.

right

ah ... domain limited?

I'd configured mlinktrunk to require TLS from *.xmpptest.com

ok

let me test it from there :)

(Because mlinktrunk is also a vhost)

:)

Tigase might have S2S TLS by the end of the week

Perhaps it can pass tomorrow's tests then :)

Given that we all fail tomorrow's tests...

yup ... mlinktrunk now fails too :)

\o/

Dave Cridland: We all fail *some* of tomorrow's tests, I don't think that stops it being worth testing that everyone passes the bits they think they do.

so the expected result :)

Kev, Right. Or our X.509 team might fix the interesting bug we have. (Which is actually in Sodium CA).

hi! I'm implementing contact search in empathy (a client using the Telepathy framework) and wanted to test if it's working... can anybody tell me a server I can test it? thanks!

mlinktrunk.xmpptest.com has '55 available on the IM domain.

emilio.pozuelo@collabora.co.uk: there's a big list o' servers on the wiki page

emilio.pozuelo@collabora.co.uk, Want to use gabble with password gabble?

Dave Cridland: gabble, yes. No idea about the password :)

wjt: thanks, checking

emilio.pozuelo@collabora.co.uk: (also, if you set an alias in Edit → Personal Information in Empathy, you'll get a nicer nickname in this room next time you join, and look better on people's rosters, too :) )

wjt: I've actually done that twice I think... I wonder why it's not saving it :(

oh, yeah... there's a bug where sometimes the aliases get lost and i don't know why :'(

emilio.pozuelo, I'll restart that server in a moment, just to warn you.

Well, that's interesting. I seem to be failing against ejabberd21

Ah! In fact, I failed this morning, when I look closer. Must have misread.

No features, so no TLS: (13:26:35) Send (214) <?xml version='1.0'?><stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback' xmlns:stream='http://etherx.jabber.org/streams' to='ejabberd21.xmpptest.com' from='mlinktrunk.xmpptest.com' version='1.0'> (13:26:35) Recv (155) <?xml version='1.0'?><stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:server' xmlns:db='jabber:server:dialback' id='855227178'>

I get TLS inbound, but not outbound.

badlop: ^

while wondering why I did not fail I found a bug :-)

Wow, you get bugs too?

I did not assume that tls would be only used in one direction and not in the other

we should get rid of this unidirectional nonsense, that just makes life harder :-)

Okay, so my CRL checking is now working.

o/

\o

so I'm testing contact search (XMPP 055) on mlinktrunk.xmpptest.com, but I get this error from telepathy-gabble

server is broken: <x> not type='form'

If anyone wants to test against the 'bad' servers, (mismatchcert|revokedcert|selfcert).xmpptest.com are all up. selfcert isn't yet.

emilio.pozuelo, Ah, okay... Can you tell me what XML you're seeing?

Dave Cridland: http://people.collabora.co.uk/~pochu/gabble-log-mlinktrunk.xmpptest.com.log

Dave Cridland: with our server I didn't get that error (though I got no results): http://people.collabora.co.uk/~pochu/gabble-search-debug.log

Kev: what are we supposed to do with in todays setup?

with those

Nothing.

That was purely for if people wanted to have a play in advance of tomorrow.

Kev: I wondered if they should fail for todays test, too

No, they should all pass for today's tests.

Or, rather.

With today's configuration, they should all connect. I don't think it's important to test that they do, though.

I tend to disagree when it comes to the mismatched cert :-)

fippo: Right, the point of today was to check that all servers 'can do TLS', and the point of tomorrow is to check that they 'can do TLS right'.

The point of today wasn't really to test that the 'can do TLS wrong'.

Dave Cridland: do you see anything wrong on the server side, or do you think the client is wrong when reporting that error?

the type='' attribute is missing from the <x xmlns='...data'/> element returned by the server

emilio.pozuelo, Hang on, be with you in a sec.

wjt: aha, I see

<xs:attribute name='type' use='required'>

so mlink is violating XEP-0004

I am the violator. Muahahaha. Etc.

Kev: aye. That reminds me that next time i'll bring a server which will fail unless you send a tlsv1 client hello (good for making sure we don't have servers that do not get s2s-tls-compression)

how many of the test servers support in-band registration (as opposed to Dave-creates-an-account registration)? maybe emilio.pozuelo could try some others :)

fippo, You get compression with SSLv3 Hello, too.

dave: :-p

emilio.pozuelo, Yeah wjt's right, I'm not sending a type on that form.

Dave Cridland: ok. glad to have contributed my part to find a bug :)

emilio.pozuelo, Should be fixed now. I think. :-)

cool

Dave Cridland: yay

:D

emilio.pozuelo, Works now?

Dave Cridland: I get the form correctly now, not getting any results though

emilio.pozuelo, Ah... I thought it should be working. One sec, let me check the settings,

I'm searching for "a"

maybe it's not doing substring searches?

thanks

You need a wildcard for a substring search.

It's not, actually. That was intentional, but everyone seems to disagree with me. :-)

heh

Including me.

Also searchability default was set to off. So let's change that.

I'm dubious of the value of search systems that require you to know what the result will be before you can find it.

OK, that should have updated. Try searching for yourself.

:)

for char in {a..z}; do search $char*; done # userdb acquired

zash: There's an assumption that server admins aren't likely to be enabling this for global search on the Internet :)

zash, Nah, wouldn't find all the Russians.

Dave Cridland: I cannot find myself, heh :)

emilio.pozuelo, Oh, bugger. I'll look after I've done the school run.

Dave Cridland: sure. thanks!

Oh, that's annoying, sorry. It's finding people as an operator, so it';s a permissioning issue. I'll look into this properly in about an hour.

argh, none of the other servers seem to support XEP-0055

Dave Cridland: ok. ping me when you've looked at it and I'll be happy to test again :)

emilio.pozuelo, THey may do on a different service domain, though? M-Link's unusual in putting it on the actual IM domain.

Dave Cridland: no idea... I'm trying the servers mentioned in http://wiki.xmpp.org/web/Interop#2010_Server_Interop_Participation

at least ejabberd usualy has it on a subdomain, and prosody doesnt have it at all

vjud.ejabberd21 works for local users, it has at least vcard of user "badlop", but fails over s2s due to missing dns i think

Dave Cridland: I seem to be failing against ejabberd21 <-- fixed that problem, now it advertizes 1.0 and starttls feature

badlop: works for me with tls on both connections

and fails with ssl2 :-)

badlop, Brilliant, I'll retest in a sec.

[15:47:57] Ping? [15:47:59] Pong! (2.39 s.)

\o/ ejabberd21 works. Now have a clean sweep.

So that's everyone except Prosody, and I see we have a MattJ now, so hopefully that will follow.

Indeed

Sorry my presence is a bit sporadic, family member ill

Sorry to hear it.

As long as I'm not coming down with it, I'll get the tests done shortly... :)

Did we hear back from any other servers (I was thinking specifically of Openfire and Coversant)

steve.kille: i was unrelatedly talking to an openfire developer last week, he said they unfortunatly didn't have time to join the interop event this week

pity

emilio.pozuelo, So, you can now find things in XEP-0055. SEarching for, for example "collabora" as the surname will find your account. Or search for "cridland", or "*a*" or whatever.

emilio.pozuelo, But FWIW, there's a surname on every account in the system, thanks to the X.500 DSA that requires every person to have a surname.

I know someone who doesn't have a surname. :P

wjt, They cannot exist. X.500 is all-knowing.

Haha

wjt, emilio.pozuelo - Can Gabble/Telepathy/Empathy do strong authentication, by the way?

Dave Cridland: pass. I assume “strong” is a mechanism? :p

wjt, emilio.pozuelo - As in, can I give it a client certificate for use with TLS?

Sjoerd: ^^ you had a cunning plan for something related to this?

Dave Cridland: I don't thing so currently

wjt, Sorry, being all X.509y. X.509 defined two kinds of authentication "Simple" - username and password - and "Strong" - certificates.

client certificates for autentication ? no we don't do that

Dave Cridland: hmm, doesn't seem to be working yet :( http://fpaste.org/f3Dp/

this looks suspicious:

Does anyone else? (I know Swift does, and Gajim might)

gabble/connection-DEBUG: 09/12/10 17:07:01.372524: connection_iq_unknown_cb: got unknown iq:

dave: iirc, exodus supports it too

emilio.pozuelo: now that sounds like a gabble bug :)

wjt: will you look at it for me? :)

mlink doesn't set type=result in the iq

nor it does. okay, not our bug again :D

Wow. Okay, that's fun. I wonder why nothing else has spotted that one?

oh

* x xmlns='jabber:x:data' type='result'

seems like the attribute is added to the wrong node... ?

no, that's correct

Sjoerd, No, that's a form type. Meant to be there.

ah ok

just seemed suspicious

I'm gonna guess nobody noticed it because we're the only ones pedantic enough to both check type=result and the id matching instead of just matching the id?

emilio.pozuelo, Ah! You're doing this from a remote account, right.

Dave Cridland: yes, from a collabora.co.uk one

emilio.pozuelo, Not tried that much. So yes, you won't find much (because it's local-only by default) and yes, there is indeed a bug there. Use gabble@mlinktrunk.xmpptest.com password gabble

Sjoerd: Do you check the from= as well as type= and id=? I'm guessing you do, but just checking because you didn't mention it...

Kev: we do

Jolly good :)

Sjoerd, It's because I think you're the first people to seriously use my '55 code remotely.

fair enough ;)

Dave Cridland: if you want you can open it for remote connections and I'll find all the bugs ;)

emilio.pozuelo, Oh, it's certainly opened, but the problem is that the accounts aren't searchable by default from remote connections (ie, they won't appear in results)

emilio.pozuelo, It's done this way so that in an enterprise setting, everyone can be searchable locally, but some people (sales staff, perhaps) can be searchable remotely. Or so that a large public server could have a purely opt-in search.

Dave Cridland: oh, I see

so you can make people be searchable from the outside on a case by case basis?

Yes.

emilio.pozuelo, Controlled by an ad-hoc they can use.

Dave Cridland: nice

Dave Cridland: so perhaps you can set a couple of test accounts to be searchable from the outside?

Try now.

with emilio.pozuelo ?

Actually, hang on, and I'll fix that bug.

OK. Remote searching should now work *and* have results. Search for a Family Name of *a*, for instance.

Dave Cridland, I agree re. user prefs - I plan to do the same thing in Prosody

MattJ, XEP-tastic, then. I'll draft something up.

\o/ it works! :D

emilio.pozuelo, Thanks for the help.

MattJ / Dave Cridland: The vague problem here is that user prefs really are ad-hoc, all servers are going to support different ones, I'd have thought.

Unless you're intending some 'more defined than ad-hoc, but still undefined' thing.

Indeed, I don't think Prosody would define /any/ in core, it would depend on loaded modules

Just a registry so people can use the name var-names ?

for the same functions *

(like muc config forms)

That might work - for many of them

Kev, I'm not so sure. We can have a specific well-known command, so that clients can place it into the UI, much like vCard editing. And well-known field-names allow common options, even if servers also support others (and may not support those)

Just having the user config commands on a different node from server admin commands would be fairly nice.

MattJ, Oh, forgot to ask - prosody8 - S2S 198 enabled?

eh, no - dare I? I wonder :)

MattJ, Worth a go, I think. mlinktrunk should work with it.

MattJ, And if we spin up a Swift on both prosody8 and mlinktrunk, that'd mean we could have an end-to-end 198 chat.

:)

Simon Josefsson, You about?

Bouncing prosody8

Should have 198 now

Signing in with Swift

Actually I think I ought to update it first

Locked up on sign-in :)

Oh no, it's back

Just acting oddly

Aye, HEAD pre beta7 :)

Are you on something Ubuntuy?

If so, there are nightlies you could use.

Saves the effort of compiling it.

Ooh, that would be nice

Lucid or Maverick?

It does take an age to compile on here

Lucid

deb http://swift.im/packages/ubuntu/lucid development main

https://www.swift.im/keys/packages.key

For the record, Simon Josefsson and I have just successfully interop tested SCRAM-SHA1-PLUS with channel bindings.

Nice :)

remko, Kev - time to update Swift to do Channel bindings too?

Tobias is working on channel binding, but not ready yet

!slap Kev

btw, swift beta8 will not do the tls checking

I have terminals in one workspace, and chat clients on another

neither do the development versions btw, i commented the check, because we need a gui for trusting a cert

when I start any client from the terminal, I hit enter and switch to the right workspace

Swift is the only one that appears before I can switch

Thanks Dave. I'm going to do a stable GNU SASL release with SCRAM-SHA-1-PLUS in it now.

MattJ: heh :)

MattJ: dmenu!

Dave Cridland: as soon as i understand what channel bindings are ;-)

Dave Cridland, ok, matthew@prosody8.xmpptest.com is c2s and s2s 198-enabled

remko, They're little leather straps to hold the channel in place.

remko, Very fashionable.

oo, sounds compelling

will this require us to use GNU SASL?

or cyrus or whatever

GNU SASL?

any external SASL library

remko, No, Polymer implements its own, for instance.

ic

remko, You just need to get the channel binding name for the TLS channel, which you do by getting the Finished messages from OpenSSL, basically.

*nod*

http://tools.ietf.org/html/rfc5929#section-3 <- that's the channel binding code. SSL_get_finished() will do it if you're not doing session resumption.

MattJ, OK, so admin@mlinktrunk.xmpptest.com sent you a subscription request. I see 198 enabling on S2S, and an ack coming back.

Dave Cridland: cool, thanks

Swift stopped repainting for some reason, works again now

198 is nice, makes me want to use it for my main account...

+1

MattJ: You'll have to switch to Swift. Like you promised :)

ho! Are you going to do infidelity to Gajim? ;)

Asterix, We'll just add 198 to Gajim, don't worry.

:)

MattJ, Right, so I know what the issue was with our last test, now. M-Link doesn't request acks with every stanza, only when the link is idle - it's really hoping that you'll proactively ack stanzas, to reduce bandwidth.

Dave Cridland, well I won't :)

MattJ, So in our original tests, we simply never left the link idle for longer than a minute for M-Link to decide to requst an ack. The strategy works well for C2S links where there's traffic in both directions, but not so well on unidirectional S2S links.

Right

MattJ, Right - on unidirectional links there's little benefit, since you're never "writing anyway".

and if you did resumption, this wouldn't be an issue

MattJ, No, it'd still be an issue - we're building up a massive stash of unacked stanzas. :-)

Not a protocol issue :)

Right.

So, let me test that we are *ever* asking for acks...

There, we are. So I can fix this behaviour simply.

OK, so that fix works.

So, Me <-- 198/C2S --> mlinktrunk <-- 198/S2S --> prosody8 <-- 198/C2S --> MattJ

Mission accomplished. :-)

I'd reply if Swift was responding :)

I can't work out what it's up to

MattJ, Oh. Kill it and make it work, otherwise it's a little tricky to describe this as an actual success.

hmph, I love it how certain services don't let you have passwords longer than 20 characters

stpeter, My gripes are usually the exact opposite.

I create 28-character passwords

stpeter, "Please supply an unusual password that you cannot remember and will have to write down somewhere."

well, all for naught -- I can't log into Skype from my current location anyway ;-)

how's the 198 interop?

stpeter: \o/ skype must die! ;)

I need to review the list threads and the submitted patch for that one

zash: indeed

stpeter, Getting there.

Is there tools for killing a TCP from under the server/client[s]?

zash, I used to have some. They were fun. I suppose I still could use those, by sitting on the router. In the good old days, people trusted RST packets wherever they actually came from, as long as the addresses looks okay.

Of course, when I say "good"...

right, let's see what this interop thing is all about

remko, you need an account on prosody8?

yes please

k

well

whatever prosody you want me to test against :)

Done

prosody and mlink = success

seeing some interesting problems with notls and ejabberd, the interop is already a success :)

Is someone going to write up the client results so far?

The client Wiki looks very blank

i just started with swift

i'm going to write it up when i'm done

lovely

Are you the only client?

Asterix with Gajim too

many others are subscribed at least

the client stuff was only published today i think

brb

and telepathy, and some other

remko: I put the up client tests yesterday morning at the same time as the server ones :)

fippo: you asked yesterday: [2010-12-08 22:30:30]<fippo> badlop: do you see any hints why a host named 'fippo.testing.openssl' is not offered tls (or version 1.0) from ejabberd21.xmpptest.com?

that works for me now, can you verify?

badlop: works

ok, thanks

what's this notls.xmpptest.com about?

is this a server, or are the servers in the subdomain?

remko, that's a server AFAIK.

it's not serving the domain though

It's a server that MattJ hasn't set up yet.

if i connect to notls.xmpptest.com, it says that it's not serving that domain

ok

interesting enough, this is triggering a bug :)

so, anyone from psyced or tigase around?

remko: yep

fippo: could i get an account on psyced?

remko: sure, but unless swift does irc it won't be very useful :-)

oh, is that an irc server

my bad :)

i was wonderng why i hadn't heard of it :)