XMPP Council - 2012-08-22

Kev, what's on the agenda for today?

Last call's over on Correct, and I need to check Forwarding and ask for an LC on that.

And now I've read it.

I might be a few minutes late, bbiab

OK, ta.

n/m I'm here

So you are.

this is O/T for Council, but I wonder if it would be good to summarize some of the SRV experiences at jabber.org of late or file bug reports with relevant software applications -- I can do some more testing of clients that are available for Mac

stpeter: http://xmpp.org/rfcs/rfc6120.html#tcp-resolution: Extensible Messaging and Presence Protocol (XMPP): Core

Kanchil: thanks, you are so helpful!

It's nearly time.

ah, right, so various clients aren't trying the secondary domains as mentioned in step 7 of section 3.2.1

Kev: are we nearly there yet? ;-)

Quite.

:)

Poked Ralph and Matt.

present

1) Roll call.

presente

MattJ / Tobias.

here

Here!

Marvellous.

2) 297

We were going to discuss LCing this but I wanted to read through it first. I've read through it.

Shall we LC it?

http://xmpp.org/extensions/xep-0297.html

Kev: http://xmpp.org/extensions/xep-0297.html: XEP-0297: Stanza Forwarding

el see it!

+1

looked okay to me...so +1 on LC

MattJ

for the example #2, I think it would be more clear to have the xmlns as the first 'attribute'

(of the embedded stanza)

I'm +1 to 297

ralphm, sure

ralphm: I don't have strong opinions either way.

But I think Matt just volunteered to change it :)

it's more in-the-face that way

3) http://xmpp.org/extensions/xep-0308.html Last call has ended.

Kev: http://xmpp.org/extensions/xep-0308.html: XEP-0308: Last Message Correction

people rarely read the prose

My reading of the LC feedback is that I should change various bits of prose, and then probably LC it again.

there are definitely some bits that need changing

Although maybe a second LC isn't needed if it's all prose changes.

it didn't seem that major to me, though

I'm fine without another LC

there was some discussion on 'last'

I'll submit a new version in any case, and we can decide if it's worth a second LC or not.

/nod

I don't promise I'll get to this immediately, other things are distracting me somewhat at the moment.

I wasn't sure if there was consensus on that

ralphm: consensus on 'last' or other aspects?

Last, I assume.

stpeter: on 'last'

The protocol works fine no matter how far back you go, but I think there's a reasonable argument to be made for only supporting last correction.

Kev: right. In the current text 'last' only occurs in the title

The first version I submitted had two disco features - for Last or Other, it wasn't entirely clear to me that there was a clear consensus to add that back in or not.

ralphm: Right, the text says to only use it for last messages as well.

I'm not overly keen on making the XEP more general if people will only ever implement Last.

I only intend implementing Last in Swift, at least.

So let's take a straw poll here, assuming everyone read the LC feedback.

Should I add Older back in, or leave it at Last.

I vote for "leave it at Last"

yeah

Same here

leave it at last, this is just chat and not some over-generalized protocol for non-chat things people brought up during LC

especially because this applied to real 'chat' messages only

Excellent, ta.

4) Date of next meeting.

for things like real-time tweets, you can fix it with item retractions in pubsub, for example

SBTSBC WFM

+1

OK.

wfm

5) AOB

0301

I cannot keep up with that

ralphm: What do we need to discuss on that?

:)

neither can I

is there still useful discussion going on there?

There's still spec changes, so ...

yeah, the size of the document worries me too

I will finish the second half of my review on 301 this week

I keep wondering if I should post into one of the threads suggesting that binary XML might be a good fit for RTT.

heh

haha

everything should be JSON

The document is somewhat out of style with other XEPs. In that it's large parts marketing rather than just telling people how to implement it.

Kev: this

Kev: that is my main issue with it right now

I don't have firm opinions about how terrible this is.

I'm going to at least send something about section 1 before the end of tomorrow (MDT(

It's clearly (to me) undesirable - but enough to block it? Probably not.

I think it sets a bad precedent

I sent some comments about places I thought it wasn't acceptable.

I particularly dislike the name-dropping of companies who've been involved in RTT elsewhere as a means of validating the XEP.

But anyway.

exactly

I've done my time on this, I feel, I've done a number of reviews and struggled through lots of threads.

strangely I didn't take offence at any of that

I'm hoping other people will take over here and I can just do one more review when it's time to vote on Draft.

it gives me the feel of a solution in search of a problem

m&m: Oh, I believe that this is a problem worth solving.

At its heart.

I do too

agreed

but the wording, particularly in Section 1, makes it feel like the reverse

Indeed, I implemented this for Psi as custom dev work for someone many years ago.

it's trying to hard

*too

But - right.

m&m: you need XEP-0308!

clearly

You could use this for this, or this, or this, or this, and it's important because of this... it just adds verbiage without value and makes it harder to penetrate for people who want to implement it.

anyway, 0.8 is on the way (once I finish my review), so let's see how that looks

Hurh hurgh, I said penetrate.

exactly

the other thing is FOSDEM

well, I will still endeavor to get some personal comments on section 1 before too long

m&m: Thanks.

ralphm: Where are we with that?

it seems like FOSDEM prep starts sooner and sooner each year

kind of like Christmas prep

we have received notice of the opening of application period for a devroom

and main track too

I do quite fancy doing Thu/Fri as XMPP and Sat as devroom and having an excuse not to turn up on Sunday this year.

the former closes October 1

Kev: we can definitely try getting a room on a saturday

Kev: I'm not sure if you can actually choose, though

regarding FOSDEM, I have been collaborating with several people about a main track about federated communications -- IM, presence, voice, video, social networking, microblogging, etc., probably with a few talks and a panel discussion of common issues and solutions

Or if we're on Sunday, Sunday FOSDEM, Mon/Tue XMPP.

So do we have any actions for Council on this? I'm assuming not, or at least not yet.

Kev: we'll just ask them to put the federation track on the other day

:-D

ralphm: ;-)

The action is applying for the devroom, I guess. Although strictly this isn't a council responsibility

I assume we'll want to apply for a devroom again, although maybe this should go past Board to check.

Hah, I've done devrooms even before there was a board

yeah, this is the jabber/xmpp devroom -- the jabber folks kindly invite the XSF to participate ;-)

but sure, I'll check with them

Ta.

So the other thing is probably the sucky state of SRV support everywhere.

yarp

jabber.org's been suffering from many DDoS attacks over the last week.

I've butchered the setup so the SRV gives you first hermes.jabber.org, which is the IP being attacked (also the A for jabber.org), and then gives you fallback.jabber.org as a fallback.

I missed the initial discussion, although I could read back, I believe Twisted's SRV connect code is broken in this respect too

But surprisingly few clients or servers seem to manage to connect, although there is a valid SRV record.

many are

In some cases this is because they just fail at SRV, and in other cases (Swift did this, although we fixed it) it timed out the entire login attempt while it was blackholing the connection to the first record.

I don't think Council has a particular action here, other than bringing it to everyone's attention that everyone sucks at XMPP.

I think the XSF could assist in gathering information on this for the existing client implementations

much like the dialback thing

/nod

ultimately it breaks stuff

I think it'd be great if someone took this on.

It won't be me, though, I'm suffering enough trying to deal with the jabber.org side of this crap.

It's not just clients, FWIW, servers seem to equally fail at dealing with it.

GTalk in particular.

Openfire too, I've been told.

right, Openfire was failing too, as I understand it

right

Any client based on Smack...

There's lots, but I don't have the spare cycles to try and gather any sort of information.

I think it even qualifies for a security notice

ralphm: I don't think it's a security issue.

I think a message to jdev might be in order as a first step

That'd be good.

bringing this to wider attention

I volunteer to do that

I've been encouraging users to file bug reports when they've been telling me that it must be jabber.org that's broken.

:)

"This client whose Jabber support hasn't been updated since 2002 isn't working and it used to. It can't be a broken client, you must have screwed up" etc.

stpeter: awesome. It would be great to have some text on how things are supposed to work. Although the SRV RFC explains how, people seem to be confused about this.

stpeter: Thanks.

Probably because of the lack of examples

ralphm: yeah, something for 6120bis ;-)

Any other any other business?

not from me

I can do minutes, but if some kind soul wants to volunteer to do them instead I wouldn't complain.

I can

Marvellous, thanks.

thanks Matt!

I have an evening of jabber.org rubbish ahead of me.

n/p

Right, I think we're done then, and over time.

Thanks all.

Kev: I'm with you in spirit

Thanks, I think.

I happened to look over the planet.jabber.org statistics

and noticed most of the google searches resulting in a visit have to do with jabber.org outages

Oh, GSoC!

Not a Council thing, but just to let people know that GSoC this summer was exceptionally successful.

I'm inclined to call it the best summer yet.

very nice

Awesome work by all involved. Thank you!

We'll have another whiteboarding XEP on the table at some point, I hope, as Mateusz wrote whiteboarding for Swift using OT.

OT?

Operation(al) Transforms.

A system for resolving concurrent updates for a consistent view.

(And that's as much about it as I know :))

isn't that the stuff used by google wave?

Yes.

it would be really good to settle on a whiteboarding technology

Kev: does the Swift code go out of band?

No, it's all inband.

It's also always client-server, which is quite appealing.

ralphm: do we need to set up an Atom feed for jabber.org again? I broke it recently :(

Kev: multi-user or only one-to-one?

stpeter: how did it break?

Swift's implementation's currently one-to-one, Mateusz is going to look at extending that to multi-user soon.

ralphm: I killed our WordPress instance and converted the site to static HTML because I'm paranoid about PHP

stpeter: having the notices in atom form would be great

stpeter: I could then put them on the planet

ralphm: OK, I'll do that, but just because I like you so much

But it's fine to use for multi-user, you just have many clients connecting to the server.

Kev: ah, ok

(Where the server is just one of the clients acting as server - although you could have a specialised component)

stpeter: (L)

(s/component/bot/)

right

I've heard various complaints about SXE, I'm hoping what Mateusz has produced will be more palateable.

Kev, does the swift code work with multiple users?

"Swift's implementation's currently one-to-one, Mateusz is going to look at extending that to multi-user soon."

ah..soory...overread

It was the last thing he sent! Maybe he 308d it

:-D

ralphm: http://www.jabber.org/atom.xml

stpeter: http://www.jabber.org/atom.xml: jabber.org <link rel="alternate" type="text/html" href="http://www.jabber.org/notices.html"/> <author> <name>jabber.org</name> <url>http://www.jabber.org/</url> </author> <tagline>jabber.org notices</tagline> <id>http://www.jabber.org/notices</id> <copyright>http://creativecommons.org/publicdomain/zero/1.0/</copyright> <modified>2012-08-21</modified> <entry> Another Denial of Service <link type="text/html" rel="alternate" href="http://www.jabber.org/notices.html"/> <id>tag:jabber.org,3</id> <issued>2012-08-21</issued> <modified>2012-08-21</modified> <summary>The previous DDoS attack has started again. As before, fallback measures are in place, but if your IM client doesn't handle DNS SRV records correctly then you might not be able to connect.</summary> </entry> <entry> Proposed Changes to the Service Policy <link type="text/html" rel="alternate" href="http://www.jabber.org/notices.html"/> <id>tag:jabber.org,2</id> <issued>2012-08-20</issued> <modified>2012-08-20</modified> <summary>We have posted proposed changes to the policy that governs use of the jabber.org IM service. Details, links, and instructions for providing feedback can be found in our post to the juser@jabber.org email list, see http://mail.jabber.org/pipermail/juser/2012-August/006869.html.</summary> </entry> <entry> Service Restored <link type="text/html" rel="alternate" href="http://www.jabber.org/notices.html"/> <id>tag:jabber.org,1</id> <issued>2012-08-15</issued> <modified>2012-08-15</modified> <summary>We were able to completely restore service today. However, it is quite possible that the denial of service attack could be launched again at any time. If you were unable to connect during the outage, we recommend that you consider using a different IM client or reporting a bug to the developers of the IM client you use, since standard DNS fallback and XMPP reconnection methods should have been sufficient to keep you online after the first few hours of the attack.</summary> </entry> <entry> Denial of Service

sigh

silly Kanchil

brb

stpeter: did you hand craft it, or is it generated>

?

hand

:-)

old skool!

time to bring back the xml blog code :-)

hey I use it at stpeter.im ;-)

:-)

Interesting. Kanchil's not supposed to post anything unless the thing has a title.

heh

Kev: but it has a title

Let me rephrase.

It's not supposed to post anything unless it has a title, and then only the title.

notice how it removes the tags around the titles

(only)

I expect it's just a greedy regexp where it shouldn't be, or something.

Parsing html or xml with regexps: fail

Patches welcome.

:-)

stpeter: for the October summit, are we still shooting for just the 25th?