XMPP Council - 2017-02-15

seems it's about time

1) Roll call

Dave Cridland ? daniel ? Link Mauve ?

Give me a second

here

somebody say something...

okay...the others can vote on list

2) Minute taker

any volunteers?

i can do it

I volunteered to take minutes

oh

but daniel is also welcome

Oh yes, sorry, welcome jcbrand :)

jc reached out on the mailing list and offered to show up for council meetings; sorry, I didn't see that you were here :)

great to have an external minute taker, thx jcbrand

thanks :)

Yup, I’m here.

3) Vote on accepting https://xmpp.org/extensions/inbox/sasl2.html as Experimental XEP

on list

i'll vote on list, haven't read it yet

on list

On list too.

4) Vote on accpeting https://xmpp.org/extensions/inbox/ibr2.html as Experimental XEP

*accepting

will vote on list too here

on list too; haven't had time to read anything

On list too.

Note that I just merged some changes to that one last night (I think?, if not I'll do it now)

+0; abstaining with my author hat on

5) Vote on issuing Last Call on https://xmpp.org/extensions/xep-0381.html

that's the IoT SIG

i'm +1

+1

+1

+1

(changes to ibr2 being published now; please refresh before reviewing)

6) PR: Clarify CSI and Carbons state after SM resumption (regarding https://github.com/xsf/xeps/pull/402 )

SamWhited, what do you want to discuss here?

Tobias: I'm not sure that we ever got a reply from the autor, so I think it's up to us to decide if these outstanding PRs get merged

in this form i'm -1

i wouldn't want to bump carbons ns just for that

I also am hesitant about this one; it's a lot of stuff, I haven't been able to digest it all yet.

if I understand correctly both Carbons and CSI are experimental XEPs...so they don't require council aggreement to be changed

Does that mean for experimental XEPs with an inactive author anyone can change them?

well either council or author approval?

SamWhited, ideally only the authors or if they aren't active anymore, a new volunteering author

but considering both are currently in LC, we might as well read the change in the PR and leave feedback in the PR

That's probably the editors job to find a new voluntary author actually, in which case apologies for not doing my other job. I'll reach out and try to find people if the author does not return in a reasonable timeframe.

SamWhited, thanks

will read the PR tomorrow and provide feedback on github

in that case, count me as on list as well.

SamWhited, for what?

i mean there is potenntial other stuff pending for carbons that may also require a namespace bump

in that i case we can just mix those in

because in general the PR does make sense

for reading / reviewing this PR, I mean.

yes, it does

SamWhited, ah..alright

7) Consider LC for XEP-0186: Invisibility

SamWhited, have the editors send a message to the ML for a new author for it?

Tobias: Peter actually reached out and said he'd make changes.

ah..great

I'll pester him again if they don't materialize :)

I've kind of forgotten what needed to be done for this one though; sorry, hectic morning.

8) Vote on issuing Last Call for XEP-0186: Invisibility

is xep-0186 the invisible XEP of the several xeps that's actually used?

Wow, that's been a long time coming

+1 on LC for 0186

Tobias, wouldn’t it be better for stpeter to first fix it, before starting the LC?

because i know there are several and LC is the state where we should check if it doesn't duplicate something else

daniel: I'm not sure, but the others are based on privacy lists, or not actually compatible with XMPP Core, so I'm for this one personally.

The other two I know about are 0126, and 0018

SamWhited, +1

If there are others, I'm not sure

ok; i'm gonna do a little bit of research and vote on list

Link Mauve, i don't know of open issues regarding it? if there are the LC can discover them, not?

I'm +1 for LC

If so, I’m +1 too.

Tobias, my understanding was that there were some potential leftovers from the previous LC.

Link Mauve, i don't know

9) the Last Calls for XEP-0333 and XEP-0368 ended

SamWhited, have the editor received new versions for them which incorporate the feedback the authors got during last call?

Please hold; checking (sorry, I was not prepared today)

if not or if the new version aren't published yet, it doesn't make much sense to vote on them

so for 368 I think I incorporated all feedback before last call ended, but then got a bunch more after LC ended, the latest version is published though

and I'm not clear enough on the after LC feedback to say whether anything needs changed

I do not have PRs for either

So does that mean the call needs to be extended?

moparisthebest: for 0368 I'd still like the soft security language removed

yea the latest version is published https://xmpp.org/extensions/xep-0368.html

moparisthebest, that is Version 0.1.1, right?

right

moparisthebest, so you'd like us to vote on that version or are there further updates planned?

I'd prefer to not make more, seems SamWhited disagrees :)

Yes, as mentioned on the thread, ther is some security related language that I think is misleading or confusing.

*there

At best it's just passive language that doesn't belong in the spec, at worst it's misleading, I should say.

moparisthebest, i mean the discussion is still ongoing, might as well vote on it next week and see if the discussion results in better text for the security considerations, not?

I'm not super opposed to removing and/or rewording that, I just don't see a problem with it either

I'm fine with that Tobias

I just don't think it's a claim that we should make in this document at all, I'd just remove "this provides the opportunity to connect to XMPP servers with at least equal and perhaps increased security and privacy over using STARTTLS"

great

Cool, anyways, we can take that on list. I'll extend LC by one week if that's enough moparisthebest? I can do more if you won't have time to discuss / possibly make updates

sure SamWhited I'll try to talk with you after this meeting if you have a few to work it out

moparisthebest: Sure thing

SamWhited, no update received on XEP-0333, right? is the current XEP author still active in the community?

Tobias: I have not received an update; shall I also put out a call for someone to take over?

SamWhited, that'd be great, thx

and at least ping the current author first

I'll do that then, and also extend its LC in the mean time.

10) Date of next

i can take 333 over if the original author doesn't respond

daniel: Thanks, I'll let you know.

same time, same day of week, next week

yes

WFM

WFM.

gret

*great

11) AOB

i have aob

daniel, sure..what is itß

*?

i want to merge https://github.com/xsf/xeps/pull/420; no offense to matthew but claiming every couple of month that he is still active and working on that isn't really active if no result comes from that

I agree

i wonder if council can merge this without author approval

(though mwild isn't really opposed to that change. but busy with other stuff or what ever)

sure..but if he doesn't have the time to maintain it he might as well hand that over to someone else

tldr of my reasoning (more in the github pr); reflects the current situation; doesn't influence future developments on that xep; is generally considered a good idea

i could ping the other coauthor about the PR :)

daniel, but yeah..if the authors don't respond to feedback/PRs anymore, the council should ask the XEP Editor to look for new authors

any other AOB?

doesn't look like it

thanks everybody

thank you

Thanks everyone; and thanks jcbrand, you picked a crazy meeting to volunteer to help on :)

thanks jcbrand for taking the notes

you're welcome guys, I'll send them out now

Thanks!

just a random question, is there a real reason to have a single author that can change XEPs anymore?

daniel, btw: was there a previous PR related to https://github.com/xsf/xeps/pull/420 ? that one is just 30 minutes old. or did you send your previous changes to matt and they weren't merged in?

with version control and council / community consensus I don't see why anything can't be changed by anyone

Yes; I don't want to deal with all the crazy fallout and inconsistency that will result if we don't have one or two authors that "own" the XEP. Having ownership of a project is important.

(but yes, the council does have the ability to get something merged even if an author goes AWOL)

Tobias, https://github.com/xsf/xeps/pull/275

that's just github f*ups that forced me to create a new pr

yeah...also the standard will be associated with the names listed in the XEP, if the community does lots of changes the author doesn't agree on it they might ask to be removed as author...and you end up with anonymous XEPs or so

what if an author disagrees?

daniel, ah..ok thx

moparisthebest, if the author disagrees to apply changes the council thinks are required, it won't proceed to draft and final

moparisthebest: That's why the council doesn't do it lightly (and, as Tobias said, the author could request that they be removed, I suppose)

ok was just curious thanks :)

Unless we override them (which I'm pretty sure we can do; we just shouldn't generally, if we have too something else is probably very wrong)

ok SamWhited so what changes do you want made and where? to 368

moparisthebest: I think the following line should be removed:

> Applied to both xmpps-client and xmpps-server SRV records, this provides the opportunity to connect to XMPP servers with at least equal and perhaps increased security and privacy over using STARTTLS.

"with at least equal and perhaps" is passive language that just doesn't fit, but if it's not passive the claim of "increased security and privacy" is potentially misleading (and I don't think it's true).

Can we move this to the xsf room?

ralphm: Yah, good idea

hmm...didn't trello have a way to copy checklists...

They did… I don't remember where though and can't find it either.

maybe that was the price of the atlassian acquisition :P

always was so handy to copy the checklist for votes from another card

So I emailed the wrong list...

with the minutes

I'm however not on the council so how can I email the council mailing list?

jcbrand: Nothing inherently wrong with sending it to the members list, the council is elected by the members after all

I'm not sure who can actually add people to the council list…

SamWhited, intosi? idk

sending minutes to standards@ is fine too

jcbrand, i've asked iteam to add whitelist your mail address for the council list

Thanks Tobias

Ok, I sent the minutes to the standards list so long

Thanks again!

We hope to see you next week if this didn't scare you off :)

SamWhited: no problem, happy to help and I'll be there (barring anything unforseen)