XMPP Council - 2011-09-21

greetings, and 30-minute warning :)

Moin.

hola

and my dent didn't get posted at identi.ca -- perhaps their xmpp interface is not happy

tweeted it instead :P

stpeter: http://identi.ca/notice/84187967

yeah, I got nuttin'

Kev's -30s meeting

stpeter: oups: http://identi.ca/conversation/84183552#notice-84188156

Interesting, what Gajim says the time is doesn't match my system clock...

Neustradamus: perhaps I need to use their website instead of the xmpp interface...

It's currently 2 minutes to the meeting in the Chair's time.

MattJ: is it off by minutes, or hours? (-:

Minutes

Maybe it's drift from suspend/resume

which one is correct I'm not sure :)

hehe

Ok, Gajim matches `date`, so it's just my taskbar that's wrong

stpeter: yes

Hi all, random visit while having a coffee...

Right, time for the meeting.

1) Roll call.

I'm here.

hi dbanes

presente

hi @stpeter [on mute now]

MattJ: Present?

Present

Sorry

Goodo.

No sign of Ralph, and Fritzy Is No More.

:'(

Or, well, sign of Ralph but he's DND.

Ralph is dnd with some strange status messages

Ralph is doing development for some legacy social media site, apparently (-:

heh yeah

3) Move -260 to Draft?

It could be XMPP related :)

+1

2, rather.

+1

I'm assuming this is an easy +1 as we reviewed it not long ago and it's been marginally updated to reflect feedback since.

I'm +1 anyway

3) 261?

+1

+1

Kev: I was going to double-check all threads related to 260 yesterday, but I wasn't feeling well so didn't get to it

Something going around? I've been rough for a week.

Something going around, my brother's ill

My understanding was that 260 feedback had now been addressed.

scary that it's jumping continents

And the same for 261.

linuxwolf: I was in the US when I caught it.

that's my understanding, too

Now in the UK.

Kev is the transmission mechanism!

Kev: oh, well, congrats on being a Typhoid Mary (-:

patient zero

Thanks.

linuxwolf: Do you have a vote on 261?

+1

sorry

4) 249 1.2?

+1

+1

+1 also

5) http://www.xmpp.org/extensions/inbox/account-management.html - accept as XEP?

This doesn't look right to me.

I only managed to get halfway in my review

(I underestimated how long it was)

I don't believe these things are really stream features, for a start.

I don't think password setting is done the right way (we're not trying to protect against the server knowing our password for the server)

Various other things are quite funky.

/nod

I'm also quite interested in the suggestion that server may either store passworddata in more or less secure forms than plaintext.

Kev: yeah, if you're worried about an attack from the server then run your own server

I've taken advice on what less secure storage than plaintext could be, and have had both Twitter and billboards in the West End suggested.

:)

BTW Jehan wanted to be here but the timezone difference was too much

(-:

stpeter: I saw that.

So, despite my opinion that we should accept everything that isn't obviously wrong, this seems sufficiently wrong in sufficiently many ways to me to want to reject it.

I can be talked down on this if my fellow Council members feel I'm wrong.

I'm prepared to accept it

But I'll follow up on list after I finish reviewing

I'm prepared to accept it, but not to talk someone down from their position

Heh

MattJ: Because you don't believe using non-stream-features as stream-features is the wrong approach etc., or because you think it's the wrong approach but not strongly enough to block it?

I read through this (and it took a while) and my opinion is roughly thus:

Kev, because I see it has potential, and isn't obviously terrible to the point of not accepting (though I already have a list of feedback)

Experimental is not final, we're not forcing people to implement it

and we're not saying it's perfect

77 could do with updating. This tries to update 77. Yay. It does it in several wrong ways and the protoXEP needs a lot of work. If such work were put in fairly early, I don't really mind it happening on the vine. If this were to go on the vine for 12 months and get implemented in that time without attention from the author, I think it's harmful.

right, I see Experimental as "this is reasonable a starting point for discussion"

I agree with both your statements

heh

I suspect it won't get implemented anywhere though without a push

I see Kev's point, but there is a reason a big red warning is at the top of experimental XEPs

Indeed

linuxwolf: Right. Although the quality of Experimentals is *generally* fairly high.

*generally* (-:

Right.

I'm not disagreeing that this has problems

Me neither

IMO, I think doing something non-XMPP would be an overall better approach, but that's me

If it makes you happier, we can push it off for a week

Right - it's just a question of whether they're severe enough to need fixing before even going to Experimental.

We can give our feedback, and see how we feel after it's been hashed out on-list

/nod

I'm generally in favour of accepting just about anything non-broken as Experimental.

Ok, this seems like a reasonable approach, thanks.

I haven't decided yet if account-management is broken, either

but that's me

So we'll start list feedback, and hold off accepting until feedback's underway, but not actively reject it?

Ah yes

Yes

agreed

Ok, WFM, thanks.

6) Replace Fritzy

well

there's only about 4-5 weeks left in the term

We have the ability to replace our missing member. Do we want to, when we have days left of the term?

I see no need

neither do I

I'd rather have a full Council, but simply getting someone started would probably take the rest of the term.

I've not checked Bylaws recently. From memory it's at Council's discretion whether to replace a shortfall, but if someone calls us out on list for being bad people we can check and do what's appropriate.

It's at the discretion of COuncil.

it is

Jolly good.

7) Date of next meeting.

SBTSBC?

+1

wfm

Lovely.

8) AOB?

None here I think

nay

Oh

"The Council shall at its discretion determine whether to fill any vacancies on the Council caused by resignation or removal of an existing Council member."

MUC...

stpeter, great minds :)

FND!

Incidentally, I'm implementing MUC in Swift at the moment.

Great

stpeter, "Seldom", as I recall the expression.

it's always fun (-:

Kev: re-implementing?

A long long time ago, Dave and I had a wishlist thread on MUC iirc

stpeter: Implementing. It only has join/message functionality atm.

ah

MattJ, Me Dave? Did we?

I want to be able to kick people :D

Kev: I'm in no great hurry if you'd like me to wait for more implementation feedback

I'm still keen on some of those things, but I might dig it up and see what /really/ needs to go into 45 and what could be a new XEP

MattJ: right

I'm assuming we're not pushing to Final quite yet, anyway.

MattJ: I have some things, too, but they're add-ons

Kev: no

So even if I have feedback after the current push, no foul.

Anything we need to discuss about MUC?

BTW it seems that we never published http://xmpp.org/extensions/inbox/mucstatus.html ?

I'm thinking, FWIW, that various bits like the voice requests do need hiving off into other XEPs.

I know I've not reviewed the diffs yet.

ahwe did

n/m

Ok, so AOAOB?

None here

naynay

stpeter?

Anyone else?

nothing here

Fab.

Thanks all.

grazie

thanks, guys

I vaguely remember promising members@ that I'd put together a summary of the term, with a list of times people managed to be late or fail to turn up for meetings.

That sounds like fun :/

:)

hehe

sorry guys

Too busy chatting on Facebook? :)

heh

ralphm: feel free to vote on agenda items while you're here

http://xmpp.org:5290/muc_log/muc.xmpp.org/council/110921/

Kev: hehe. No, releasing several sites to production

ralphm: shall we wait for you to vote on-list about 260, 261, and 249?

no big hurry, and I need to check a few things about 260 anyway

+1 on both really

There are three :)

oh, hehe

oh, yeah, that change to 249 is great too

+1

and +1 on making that protoxep experimenal

+t

ralphm: ok thanks

your reviews are appreciated :)

fwiw, I think replacing fritzy at this point is useless

about muc status conditions

could we not model it more like we did with stanza errors, just adding a child to <status/>?

I've also thought about something similar to the type attribute we have in stanza errors, to denote the different types of conditions

(as a 'replacement' of the numbering scheme of the current status codes)

stpeter: what do you think?

ralphm: did you look at http://xmpp.org/extensions/xep-0306.html ?

yes, I tried to implement it

and found it a bit cumbersome

aha

if we are going to have a migration path, it would be nice if the different status codes and conditions are more closely related in the protocol. As with stanza errors, we can eventually lose the 'code' attribute

I'm all in favor of simpler

right, I see

I think modelling it exactly like with stanza errors would work great, here

I'm not sure if we actually need a new namespace in that setting

but that's a detail imo

ok

I think the concern was duplication when you have multiple <status/> elements

/nod

Well, you can't, in practical terms.

so, more like: <presence from='coven@chat.shakespeare.lit/thirdwitch' id='n13mt3l' to='hag66@shakespeare.lit/pda'> <x xmlns='http://jabber.org/protocol/muc#user'> <item affiliation='member' role='participant'/> <status code='100' type='informational'> <status code='110'/> <conditions xmlns='urn:xmpp:muc:conditions:0'> <realjid-public/> <self-presence/> </conditions> </x> </presence>

dwd: you can't what?

oops

stpeter, Have multiple status codes.

stpeter, There's enough clients out there that can't handle more than one. And those that can't aren't consistent with which ones they ignore.

<presence from='coven@chat.shakespeare.lit/thirdwitch' id='n13mt3l' to='hag66@shakespeare.lit/pda'> <x xmlns='http://jabber.org/protocol/muc#user'> <item affiliation='member' role='participant'/> <status code='100' type='informational'> <realjid-public/> </status> <status code='110' type='informational'> <self-presence/> </status> </x> </presence>

dwd: right, so I've heard

I'm not sure about the @type, yet.

going to commute now

I'll check back in a bit