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.
moparisthebest
Link Mauve 's voting alarm did not seem to work :)
Link Mauve
moparisthebest, I did start reading it yesterday evening, but didn’t finish before being too sleepy to continue.
moparisthebest
ah that's understandable it is quite boring :)
Zash
What's "abject"
Link Mauve
Nah, I blame the pancakes I had before. :p
Kev
Zash: Extreme(ly bad). e.g. Abject horror.
Zash
"You don't have an English dictionary installed." it says
Lancehas joined
jayaurahas joined
jayaurahas joined
daniel
SamWhited, i'm not sure if it can be made easier
daniel
if you want to support things like tfa
daniel
i'm honestly not familiar enough with sasl and it's edge cases to judge that
SamWhited
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>
SamWhited
So now I can't just have a valid state in the state machine for "expect <challenge>"
SamWhited
or similar
SamWhited
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.
SamWhited
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.
Dave Cridland
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.
Dave Cridland
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.
Dave Cridland
On the plus side, a small change means I can get rid of the "=" wart, I think.
SamWhited
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.
SamWhited
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
SamWhited
Could we piggy back on that?
Zash
Didn't SASL2 remove the stream restart?
Dave Cridland
SamWhited, I'd feel more comfortable with the <continue/> are if we had actual designs for what happens next, in general. But "maybe".
Dave Cridland
Zash, Yes.
Zash
But why
SamWhited
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)
Dave Cridland
Zash, It's only an issue if a SASL-negotiated security layer is negotiated.
SamWhited
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)
Dave Cridland
Zash, I may be wrong, here, but I don't think there's any current XMPP server that supports SASL security layers.
Zash
Does this mean the server must offer *all* features from the start, even features that require authentication?
Dave Cridland
Zash, This is a good argument for making the <continue/> and indeed <success/> spit out the stream features.
Dave Cridland
Zash, And there's no reason it can't, and no reason to make that need a stream restart (and accompanying round-trip).
Zash
How was it, was the specs clear on who could send stream features and when?
Dave Cridland
Zash, I mean, we can change SASL2 (if adopted) to do this. Not "we can already".
Lancehas left
daniel
Did anyone ping jcbrand to inform him that council meeting is today and not tomorrow?
SamWhited
*oops* not me.
jcbrand
nope
jcbrand
but now I know
SamWhitedwaves
jcbrand
:)
SamWhited
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)
Tobias
Kev might know
Kev
hmm?
Tobias
I certainly don't
SamWhited
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)?
SamWhited
oh wait, maybe Kev's not
SamWhited
This is confusing
Tobias
there's a XSF team on trello?
SamWhited
If the little chevron's mean "admin", ralphm is the only one
Kev
I didn't know there was an XSF team in Trello, I thought there was just the standalone Council board.
SamWhited
The board's board is under an XSF team
Dave Cridland
Kev, There's a Board Board too.
SamWhited
(ah yes, I was looking at the wrong one; Kev is only an admin of the standalone council board)
Kev
If there's an XSF team I should almost certainly be an admin of it, but I'm not.
SamWhited
Maybe when ralphm's next online he can create me a board (and add you as an admin)
Tobias
right...but until then we could enjoy ourselves with a fancy council meeting
Tobias
1) Roll call
Link Mauve
Hi. o/
SamWhitedwaves
Dave Cridland
Bacon, please.
Tobias
daniel, ping
daniel
i'm here
Tobias
great
Tobias
2) Minute taker
Tobias
jcbrand, you're taking minute notes and send them out afterwards, right?
jerehas joined
jcbrand
yes
Tobias
great..ta
Tobias
3) PR: Clarify CSI and Carbons state after SM resumption
Tobias
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.
daniel
where are we currently with the NS bump for carbons?
daniel
for now (regarding the other changes) it isn't necessary?
Tobias
phew, good question. Haven't read through all the feedback on the carbons LC yet
Link Mauve
daniel, it already needs one, for the removal of <private/>.
daniel
Link Mauve, are we going to remove that one?
daniel
some people wanted to leave it in
Dave Cridland
daniel, Georg Lukas has decided to actually put together a PR as a concrete proposal; I've not seen much feedback on that yet.
Tobias
Dave Cridland, is that PR already online?
daniel
https://github.com/xsf/xeps/pull/434
daniel
probably?
Dave Cridland
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.
Tobias
ta
SamWhited
oh hey, there's a rendered version; I guess I don't have any excuse for not reading it anymore. Will do that.
Tobias
right, will put it on my todo too
daniel
Dave Cridland, i can live with a bump but i'm not sure if it's worth doing only to get rid of <private>
Dave Cridland
SamWhited, You've reminded me of some AOB. Thanks.
daniel
if that's the only reason
Dave Cridland
daniel, Indeed; but Georg has added some other stuff.
SamWhited
👍
daniel
but anyway we should probably discus this in the PRs
Link Mauve
daniel, the rules definition from Ge0rG are much more of a reason to bump the namespace.
Dave Cridland
daniel, Or even better, on the list.
Link Mauve
If we decide to accept #434.
daniel
Link Mauve, ok if the rules are a reason it's fine with me.
daniel
but lets move on
Tobias
4) georg opened an PR on MUC, https://github.com/xsf/xeps/pull/436
Tobias
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
Link Mauve
(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.)
Link Mauve
(In the past we’ve had release candidates for some XEPs.)
daniel
yes or ask georg to put the same phrasing in his PR
daniel
or cherry pick flows commit
daniel
or whatever
SamWhited
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.
Dave Cridland
Link Mauve, I'd rather bump it knowing it might well bump some more than risk incompatible deployments.
Link Mauve
Tobias, ok, adding it to my list.
Link Mauve
Dave Cridland, of course.
Tobias
alright
Link Mauve
Tobias, actually I know this topic quite well, so I’m +1 on 4).
WRT 0368: I think the council voting period is over, doesn't that mean Link Mauve's vote is an implicit +0?
Dave Cridland
Yes!
Link Mauve
SamWhited, oh. :x
Dave Cridland
SamWhited, Voting period ends tomorrow, I *think*?
SamWhited
Oh right, it's Tuesday. Sounds good to me.
Dave Cridland
SamWhited, I know, it's confused me, too.
Dave Cridland
So, my AOB:
daniel
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
daniel
dave can still -1 if there is something i'm missing
daniel
where should we vote for that PR by the way? github?
Dave Cridland
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.
SamWhited
Dave Cridland: ♡
Tobias
daniel, i'll call for votes next week, then either in the meeting or the minute notes for that meeting
daniel
Tobias, ok. thanks
Zash
Take the md2xep/xep2md hacks I hacked and make another diff viewer?
Dave Cridland
I was thinking, for example, of pre-rendering PRs, maybe re-visting the diffs, and so on.
SamWhited
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.
Dave Cridland
I do appreciate it's not "normal" GSoC fare, so I'm not sure it counts, but it feels like valuable work to me.
Tobias
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
Tobias
although keep in mind the project ideas should be enough to fill a GSoC term
Link Mauve
Tobias, depending on whether the student is more of a sysadmin type, it may actually take a full term.
Link Mauve
But it should have clear goals, set by the student.
SamWhited
I think we have plenty of broken stuff or automat-able stuff in the build process to keep an ops-y student busy
SamWhited
I can make a list on the wiki somewhere
Tobias
great
Tobias
Someone having further AOBs?
Link Mauve
None from me.
SamWhited
Note that all the outstanding LCs end tomorrow again.
SamWhited
Just FYI.
Tobias
right..will do some reading/voting later today
Tobias
seems there's no further AOB
Tobiasbangs the gavel
Tobias
thanks everybody
Tobias
thanks jcbrand for writing up minutes
jerehas left
jerehas joined
Link Mauve
Thanks!
daniel
thank you Tobias and jcbrand
Kev
Dave Cridland: It's not immediately obvious to me that it's a bad idea, although it does need some work
daniel
i'm really not a fan of georgs carbon PR
Kev
(it = gsoc editor work)
daniel
these rules are way too complex and involve rules for XEPs that are hopefully going to go away soon
Zash
I would be happy if the rules for things were simpler. :)
Dave Cridland
Kev, Definitely needs some thought. I'm also not clear if "not really development" tasks are within the scope.
Kev
"Not development" tasks certainly aren't.
Kev
But as long as it's development of tools we use, it seems fair game.
SamWhited
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
SamWhited
)
Kev
Not traditionally the sort of thing the XSF's done in GSoC, but it seems fair game.
Dave Cridland
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?
daniel
SamWhited, yes. or trigger that with simple <copy/> and/or <no-copy/> hints
SamWhited
That too
Kev
Dave Cridland: I'm comfortable making a call on it once I see an idea fleshed out.
jcbrand
minutes have been sent out.
Dave Cridland
jcbrand, Can you forward those minutes to standards@ as well, please?
Tobias
jcbrand, great council minutes, ta :)
jcbrand
Dave Cridland I sent them to council@xmpp.org and standards@xmpp.org
Dave Cridland
Oh, I didn't notice. Thanks.
jcbrand
It's complicated :)
jcbrand
I have to use two different email addresses
SamWhited
jcbrand: Thanks again!
jcbrand
to send them from
jcbrand
You're welcome SamWhited :)
Tobias
why that?
jcbrand
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
jcbrand
and also for the XSF members list
jcbrand
I thought I'd still get that fixed sometime
jcbrand
but ja... just working around it for now
Tobias
there's probably some mailman admin that could fix that for you :)
jcbrand
Yes, if there's someone here who can help I'd appreciate it, otherwise I'll ask around sometime