MattJInteresting, what Gajim says the time is doesn't match my system clock...
dbaneshas joined
stpeterNeustradamus: perhaps I need to use their website instead of the xmpp interface...
KevIt's currently 2 minutes to the meeting in the Chair's time.
linuxwolfMattJ: is it off by minutes, or hours? (-:
MattJMinutes
MattJMaybe it's drift from suspend/resume
MattJwhich one is correct I'm not sure :)
linuxwolfhehe
MattJOk, Gajim matches `date`, so it's just my taskbar that's wrong
Neustradamusstpeter: yes
dbanesHi all, random visit while having a coffee...
KevRight, time for the meeting.
Kev1) Roll call.
KevI'm here.
stpeterhi dbanes
linuxwolfpresente
dbaneshi @stpeter [on mute now]
KevMattJ: Present?
MattJPresent
MattJSorry
KevGoodo.
KevNo sign of Ralph, and Fritzy Is No More.
MattJ:'(
KevOr, well, sign of Ralph but he's DND.
stpeterRalph is dnd with some strange status messages
linuxwolfRalph is doing development for some legacy social media site, apparently (-:
stpeterheh yeah
Kev3) Move -260 to Draft?
MattJIt could be XMPP related :)
MattJ+1
Kev2, rather.
linuxwolf+1
KevI'm assuming this is an easy +1 as we reviewed it not long ago and it's been marginally updated to reflect feedback since.
KevI'm +1 anyway
Kev3) 261?
Kev+1
MattJ+1
stpeterKev: I was going to double-check all threads related to 260 yesterday, but I wasn't feeling well so didn't get to it
Tobiashas joined
KevSomething going around? I've been rough for a week.
MattJSomething going around, my brother's ill
KevMy understanding was that 260 feedback had now been addressed.
linuxwolfscary that it's jumping continents
KevAnd the same for 261.
Kevlinuxwolf: I was in the US when I caught it.
linuxwolfthat's my understanding, too
KevNow in the UK.
stpeterKev is the transmission mechanism!
linuxwolfKev: oh, well, congrats on being a Typhoid Mary (-:
linuxwolfpatient zero
KevThanks.
Kevlinuxwolf: Do you have a vote on 261?
linuxwolf+1
linuxwolfsorry
Kev4) 249 1.2?
Kev+1
MattJ+1
linuxwolf+1 also
Kev5) http://www.xmpp.org/extensions/inbox/account-management.html - accept as XEP?
KevThis doesn't look right to me.
MattJI only managed to get halfway in my review
MattJ(I underestimated how long it was)
KevI don't believe these things are really stream features, for a start.
KevI 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)
remkohas joined
KevVarious other things are quite funky.
linuxwolf/nod
KevI'm also quite interested in the suggestion that server may either store passworddata in more or less secure forms than plaintext.
stpeterKev: yeah, if you're worried about an attack from the server then run your own server
KevI've taken advice on what less secure storage than plaintext could be, and have had both Twitter and billboards in the West End suggested.
Kev:)
stpeterBTW Jehan wanted to be here but the timezone difference was too much
linuxwolf(-:
Kevstpeter: I saw that.
KevSo, 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.
KevI can be talked down on this if my fellow Council members feel I'm wrong.
MattJI'm prepared to accept it
MattJBut I'll follow up on list after I finish reviewing
linuxwolfI'm prepared to accept it, but not to talk someone down from their position
MattJHeh
KevMattJ: 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?
KevI read through this (and it took a while) and my opinion is roughly thus:
MattJKev, 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)
MattJExperimental is not final, we're not forcing people to implement it
MattJand we're not saying it's perfect
Kev77 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.
stpeterright, I see Experimental as "this is reasonable a starting point for discussion"
MattJI agree with both your statements
stpeterheh
MattJI suspect it won't get implemented anywhere though without a push
linuxwolfI see Kev's point, but there is a reason a big red warning is at the top of experimental XEPs
MattJIndeed
Kevlinuxwolf: Right. Although the quality of Experimentals is *generally* fairly high.
linuxwolf*generally* (-:
KevRight.
linuxwolfI'm not disagreeing that this has problems
MattJMe neither
linuxwolfIMO, I think doing something non-XMPP would be an overall better approach, but that's me
MattJIf it makes you happier, we can push it off for a week
KevRight - it's just a question of whether they're severe enough to need fixing before even going to Experimental.
MattJWe can give our feedback, and see how we feel after it's been hashed out on-list
linuxwolf/nod
KevI'm generally in favour of accepting just about anything non-broken as Experimental.
KevOk, this seems like a reasonable approach, thanks.
linuxwolfI haven't decided yet if account-management is broken, either
linuxwolfbut that's me
KevSo we'll start list feedback, and hold off accepting until feedback's underway, but not actively reject it?
MattJAh yes
MattJYes
linuxwolfagreed
KevOk, WFM, thanks.
Kev6) Replace Fritzy
linuxwolfwell
linuxwolfthere's only about 4-5 weeks left in the term
KevWe have the ability to replace our missing member. Do we want to, when we have days left of the term?
MattJI see no need
linuxwolfneither do I
KevI'd rather have a full Council, but simply getting someone started would probably take the rest of the term.
dwdhas joined
KevI'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.
dwdIt's at the discretion of COuncil.
stpeterit is
KevJolly good.
Kev7) Date of next meeting.
KevSBTSBC?
MattJ+1
linuxwolfwfm
KevLovely.
Kev8) AOB?
MattJNone here I think
linuxwolfnay
MattJOh
dwd"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."
stpeterneeds to finalize the XEP-0045 fixes
MattJMUC...
MattJstpeter, great minds :)
stpeterFND!
KevIncidentally, I'm implementing MUC in Swift at the moment.
MattJGreat
dwdstpeter, "Seldom", as I recall the expression.
linuxwolfit's always fun (-:
stpeterKev: re-implementing?
MattJA long long time ago, Dave and I had a wishlist thread on MUC iirc
Kevstpeter: Implementing. It only has join/message functionality atm.
stpeterah
dwdMattJ, Me Dave? Did we?
KevI want to be able to kick people :D
stpeterKev: I'm in no great hurry if you'd like me to wait for more implementation feedback
MattJI'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
stpeterMattJ: right
KevI'm assuming we're not pushing to Final quite yet, anyway.
stpeterMattJ: I have some things, too, but they're add-ons
stpeterKev: no
KevSo even if I have feedback after the current push, no foul.
KevAnything we need to discuss about MUC?
stpeterBTW it seems that we never published http://xmpp.org/extensions/inbox/mucstatus.html ?
dwdI'm thinking, FWIW, that various bits like the voice requests do need hiving off into other XEPs.
KevI know I've not reviewed the diffs yet.
stpeterahwe did
stpetern/m
stpetercreates the http redirect
KevOk, so AOAOB?
MattJNone here
linuxwolfnaynay
Kevstpeter?
KevAnyone else?
stpeternothing here
KevFab.
KevThanks all.
linuxwolfgrazie
Kevgangs beh tavel
dbaneshas left
stpeterthanks, guys
KevI 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.
KevThat sounds like fun :/
stpeter:)
linuxwolfhehe
remkohas left
stpetersends an email about i18n insanity
ralphmhas joined
ralphmsorry guys
KevToo busy chatting on Facebook? :)
stpeterheh
stpeterralphm: feel free to vote on agenda items while you're here
ralphmKev: hehe. No, releasing several sites to production
stpeterralphm: shall we wait for you to vote on-list about 260, 261, and 249?
stpeterno big hurry, and I need to check a few things about 260 anyway
ralphm+1 on both really
KevThere are three :)
ralphmoh, hehe
ralphmoh, yeah, that change to 249 is great too
ralphm+1
ralphmand +1 on making that protoxep experimenal
ralphm+t
stpeterralphm: ok thanks
stpeteryour reviews are appreciated :)
ralphmfwiw, I think replacing fritzy at this point is useless
ralphmabout muc status conditions
ralphmcould we not model it more like we did with stanza errors, just adding a child to <status/>?
ralphmI've also thought about something similar to the type attribute we have in stanza errors, to denote the different types of conditions
ralphm(as a 'replacement' of the numbering scheme of the current status codes)
ralphmstpeter: what do you think?
stpeterralphm: did you look at http://xmpp.org/extensions/xep-0306.html ?
ralphmyes, I tried to implement it
ralphmand found it a bit cumbersome
stpeteraha
ralphmif 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
stpeterI'm all in favor of simpler
stpeterright, I see
ralphmI think modelling it exactly like with stanza errors would work great, here
ralphmI'm not sure if we actually need a new namespace in that setting
ralphmbut that's a detail imo
stpeterok
stpeterI think the concern was duplication when you have multiple <status/> elements