XMPP Council - 2017-02-28

looks like a quite short agenda for today

Guess I finally have to read the sasl 2 xep

I read it, but am still not sure how I feel about it. Did an implementation too; felt like there were more element names than there needed to be and that made it tricky to build a state machine to handle everything. Probably not a reason to block, it just felt very incomplete.

Link Mauve 's voting alarm did not seem to work :)

moparisthebest, I did start reading it yesterday evening, but didn’t finish before being too sleepy to continue.

ah that's understandable it is quite boring :)

What's "abject"

Nah, I blame the pancakes I had before. :p

Zash: Extreme(ly bad). e.g. Abject horror.

"You don't have an English dictionary installed." it says

SamWhited, i'm not sure if it can be made easier

if you want to support things like tfa

i'm honestly not familiar enough with sasl and it's edge cases to judge that

daniel: I think it can just by changing a few element names; my issues were mostly XML layer stuff. Eg. I get a <challenge> and send a <response>, but then in the second step I get an <additional-data> and send a <next-authenticate>

So now I can't just have a valid state in the state machine for "expect <challenge>"

or similar

Alternatively, although I think this one is likely to have a good reason behind it, I'm not 100% sure why we don't just advertise the next set of challenges as a new stream feature; XMPP already has the ability to advertise multiple features.

If it's just to merge the final SASL response and the mechanisms list, I'm not sure that's necessary here; it just felt complicated (although I'm also all for saving round trips where possible, I'm just not sure this actually helps much). I dunno, just thinking out loud though, these might not actually be problems.

SamWhited, If you send a <response/>, your possible outcomes are <success/>, <continue/>, or <challenge/> - not sure there's much I can do to make that simpler.

SamWhited, As for the features versus other stuff in <continue/>, we could make those stream features (sorta), but we need to send them then because things like "You need to change your password now", or "You need to perform 2FA" are very much per-account.

On the plus side, a small change means I can get rid of the "=" wart, I think.

Dave Cridland: Yah, that makes sense, I'm not sure it's actually a problem. It was just a minor pain point when I was playing around with implementing it.

WRT adding stuff to stream features, I just meant that after you negotiate the first round, couldn't you *already* just advertise <mechanisms> again with new mechanisms in the stream features? The second level of negotiation is sort of already implemented

Could we piggy back on that?

Didn't SASL2 remove the stream restart?

SamWhited, I'd feel more comfortable with the <continue/> are if we had actual designs for what happens next, in general. But "maybe".

Zash, Yes.

But why

We don't need a stream restart, do we? Eg. if you don't do a stream restart you're free to continue negotiating features from the list (so maybe they could even be advertised together; <mechanisms> and <secondary-mechanisms> or something)

Zash, It's only an issue if a SASL-negotiated security layer is negotiated.

and if a security layer is negotiated, do a restart and just list the secondary mechanisms in a new <mechanisms> feature (I'm not sure if this actually simplifies anything, but it would mean I don't have to implement retries if my XMPP library already does features)

Zash, I may be wrong, here, but I don't think there's any current XMPP server that supports SASL security layers.

Does this mean the server must offer *all* features from the start, even features that require authentication?

Zash, This is a good argument for making the <continue/> and indeed <success/> spit out the stream features.

Zash, And there's no reason it can't, and no reason to make that need a stream restart (and accompanying round-trip).

How was it, was the specs clear on who could send stream features and when?

Zash, I mean, we can change SASL2 (if adopted) to do this. Not "we can already".

Did anyone ping jcbrand to inform him that council meeting is today and not tomorrow?

*oops* not me.

nope

but now I know

:)

Tobias, ralphm: I'm pretty sure one of you is the admin of the XSF Trello team; any chance you could create me an editors board? (also possibly move the Council board under the XSF team so that it's in the same location as the board board)

Kev might know

hmm?

I certainly don't

Ah yes, Kev appears to be an admin too… could you create me an editors board under the XSF team (where the board board lives)?

oh wait, maybe Kev's not

This is confusing

there's a XSF team on trello?

If the little chevron's mean "admin", ralphm is the only one

I didn't know there was an XSF team in Trello, I thought there was just the standalone Council board.

The board's board is under an XSF team

Kev, There's a Board Board too.

(ah yes, I was looking at the wrong one; Kev is only an admin of the standalone council board)

If there's an XSF team I should almost certainly be an admin of it, but I'm not.

Maybe when ralphm's next online he can create me a board (and add you as an admin)

right...but until then we could enjoy ourselves with a fancy council meeting

1) Roll call

Hi. o/

Bacon, please.

daniel, ping

i'm here

great

2) Minute taker

jcbrand, you're taking minute notes and send them out afterwards, right?

yes

great..ta

3) PR: Clarify CSI and Carbons state after SM resumption

Flow created PRs which clarify things, and asked for council to review https://github.com/xsf/xeps/pull/427 and https://github.com/xsf/xeps/pull/428 . Would be nice if people could do so.

where are we currently with the NS bump for carbons?

for now (regarding the other changes) it isn't necessary?

phew, good question. Haven't read through all the feedback on the carbons LC yet

daniel, it already needs one, for the removal of <private/>.

Link Mauve, are we going to remove that one?

some people wanted to leave it in

daniel, Georg Lukas has decided to actually put together a PR as a concrete proposal; I've not seen much feedback on that yet.

Dave Cridland, is that PR already online?

https://github.com/xsf/xeps/pull/434

probably?

daniel, FTR, I'm happy if we bump the namespace and do whatever, as long as implementors are likely to follow that and not stick to the old namespace. SO I'm keen to see some feedback.

ta

oh hey, there's a rendered version; I guess I don't have any excuse for not reading it anymore. Will do that.

right, will put it on my todo too

Dave Cridland, i can live with a bump but i'm not sure if it's worth doing only to get rid of <private>

SamWhited, You've reminded me of some AOB. Thanks.

if that's the only reason

daniel, Indeed; but Georg has added some other stuff.

👍

but anyway we should probably discus this in the PRs

daniel, the rules definition from Ge0rG are much more of a reason to bump the namespace.

daniel, Or even better, on the list.

If we decide to accept #434.

Link Mauve, ok if the rules are a reason it's fine with me.

but lets move on

4) georg opened an PR on MUC, https://github.com/xsf/xeps/pull/436

as it's draft it requires council approval, so i suggest council members give it a review and we'll vote on in next week so he'd have a chance to incorporate review feedback early on

(Still on 3), I would suggest to ask #428 to not bump the namespace, and to let the editor bump it manually once all of the changes are gathered.)

(In the past we’ve had release candidates for some XEPs.)

yes or ask georg to put the same phrasing in his PR

or cherry pick flows commit

or whatever

Doesn't matter to me; I'd prefer just to have it bump the namespace and I'll merge several changes (if there are others) and then do a collective revision bump.

Link Mauve, I'd rather bump it knowing it might well bump some more than risk incompatible deployments.

Tobias, ok, adding it to my list.

Dave Cridland, of course.

alright

Tobias, actually I know this topic quite well, so I’m +1 on 4).

On #436, I think this needs some security considerations, in particular around replacing and/or removing client-added <x/> stuff.

It does solve the issue.

Tobias, Is Date Of Next (4) as well?

5) Date of next ✏

Thank heavens for Last Message Correction...

Dave Cridland, no, it says 5) here ;)

Dave Cridland, :)

any news on xep-368 ? :)

that would be 2017-03-08, 16:00 UTC

moparisthebest, will vote on list.

does that work for everybody?

Tobias: WFM

yes

WFM

Tobias, wfm.

great

6) AOB

WRT 0368: I think the council voting period is over, doesn't that mean Link Mauve's vote is an implicit +0?

Yes!

SamWhited, oh. :x

SamWhited, Voting period ends tomorrow, I *think*?

Oh right, it's Tuesday. Sounds good to me.

SamWhited, I know, it's confused me, too.

So, my AOB:

fwiw i'm going to vote +1 on #436. i'm not sure why this particular change will require security considerations. i agree that the <x/> element might deserve some. but that's not triggered by that change alone

dave can still -1 if there is something i'm missing

where should we vote for that PR by the way? github?

Given GSoC, does the Editor team wish to see if there are any complex bits of Editor automation that might be GSoC project ideas? I don't know if they might count, but perhaps discussion between the Editors and the GSoCcer-in-chief (Kev) might resolve that question.

Dave Cridland: ♡

daniel, i'll call for votes next week, then either in the meeting or the minute notes for that meeting

Tobias, ok. thanks

Take the md2xep/xep2md hacks I hacked and make another diff viewer?

I was thinking, for example, of pre-rendering PRs, maybe re-visting the diffs, and so on.

I love this idea; I still want Travis to have a deploy step so I don't have to manually log onto the server and type things wrong and break stuff.

I do appreciate it's not "normal" GSoC fare, so I'm not sure it counts, but it feels like valuable work to me.

all sounds sensible, we could probably put a "XSF" project on the GSoC project ideas page and put ideas there, if they have potential mentors

although keep in mind the project ideas should be enough to fill a GSoC term

Tobias, depending on whether the student is more of a sysadmin type, it may actually take a full term.

But it should have clear goals, set by the student.

I think we have plenty of broken stuff or automat-able stuff in the build process to keep an ops-y student busy

I can make a list on the wiki somewhere

great

Someone having further AOBs?

None from me.

Note that all the outstanding LCs end tomorrow again.

Just FYI.

right..will do some reading/voting later today

seems there's no further AOB

thanks everybody

thanks jcbrand for writing up minutes

Thanks!

thank you Tobias and jcbrand

Dave Cridland: It's not immediately obvious to me that it's a bad idea, although it does need some work

i'm really not a fan of georgs carbon PR

(it = gsoc editor work)

these rules are way too complex and involve rules for XEPs that are hopefully going to go away soon

I would be happy if the rules for things were simpler. :)

Kev, Definitely needs some thought. I'm also not clear if "not really development" tasks are within the scope.

"Not development" tasks certainly aren't.

But as long as it's development of tools we use, it seems fair game.

daniel: Agreed; I'm not sure every XEP ever written should have its carbons rules defined in the carbons spec anyways. If there needs to be interaction, the other XEP seems like a better place (so when you're implementing, eg. direct MUC invitations, then you can read about and deal with carbons interaction

)

Not traditionally the sort of thing the XSF's done in GSoC, but it seems fair game.

Kev, Indeed. There's plenty of development workload here, mind, but it's not exactly traditional. Might be worth flagging it with Google and getting a feel from them?

SamWhited, yes. or trigger that with simple <copy/> and/or <no-copy/> hints

That too

Dave Cridland: I'm comfortable making a call on it once I see an idea fleshed out.

minutes have been sent out.

jcbrand, Can you forward those minutes to standards@ as well, please?

jcbrand, great council minutes, ta :)

Dave Cridland I sent them to council@xmpp.org and standards@xmpp.org

Oh, I didn't notice. Thanks.

It's complicated :)

I have to use two different email addresses

jcbrand: Thanks again!

to send them from

You're welcome SamWhited :)

why that?

I use lists<at>opkode.com to subscribe to lists but somewhere on the wiki I gave my normal email address and that got then used to whitelist me for the council email address

and also for the XSF members list

I thought I'd still get that fixed sometime

but ja... just working around it for now

there's probably some mailman admin that could fix that for you :)

Yes, if there's someone here who can help I'd appreciate it, otherwise I'll ask around sometime