SamWhitedI 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.
moparisthebestLink Mauve 's voting alarm did not seem to work :)
Link Mauvemoparisthebest, I did start reading it yesterday evening, but didn’t finish before being too sleepy to continue.
moparisthebestah that's understandable it is quite boring :)
Link MauveNah, I blame the pancakes I had before. :p
KevZash: Extreme(ly bad). e.g. Abject horror.
Zash"You don't have an English dictionary installed." it says
danielSamWhited, i'm not sure if it can be made easier
danielif you want to support things like tfa
danieli'm honestly not familiar enough with sasl and it's edge cases to judge that
SamWhiteddaniel: 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>
SamWhitedSo now I can't just have a valid state in the state machine for "expect <challenge>"
SamWhitedAlternatively, 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.
SamWhitedIf 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 CridlandSamWhited, 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 CridlandSamWhited, 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 CridlandOn the plus side, a small change means I can get rid of the "=" wart, I think.
SamWhitedDave 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.
SamWhitedWRT 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
SamWhitedCould we piggy back on that?
ZashDidn't SASL2 remove the stream restart?
Dave CridlandSamWhited, I'd feel more comfortable with the <continue/> are if we had actual designs for what happens next, in general. But "maybe".
Dave CridlandZash, Yes.
SamWhitedWe 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 CridlandZash, It's only an issue if a SASL-negotiated security layer is negotiated.
SamWhitedand 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 CridlandZash, I may be wrong, here, but I don't think there's any current XMPP server that supports SASL security layers.
ZashDoes this mean the server must offer *all* features from the start, even features that require authentication?
Dave CridlandZash, This is a good argument for making the <continue/> and indeed <success/> spit out the stream features.
Dave CridlandZash, And there's no reason it can't, and no reason to make that need a stream restart (and accompanying round-trip).
ZashHow was it, was the specs clear on who could send stream features and when?
Dave CridlandZash, I mean, we can change SASL2 (if adopted) to do this. Not "we can already".
danielDid anyone ping jcbrand to inform him that council meeting is today and not tomorrow?
SamWhited*oops* not me.
jcbrandbut now I know
SamWhitedTobias, 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)
TobiasKev might know
TobiasI certainly don't
SamWhitedAh yes, Kev appears to be an admin too… could you create me an editors board under the XSF team (where the board board lives)?
SamWhitedoh wait, maybe Kev's not
SamWhitedThis is confusing
Tobiasthere's a XSF team on trello?
SamWhitedIf the little chevron's mean "admin", ralphm is the only one
KevI didn't know there was an XSF team in Trello, I thought there was just the standalone Council board.
SamWhitedThe board's board is under an XSF team
Dave CridlandKev, 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)
KevIf there's an XSF team I should almost certainly be an admin of it, but I'm not.
SamWhitedMaybe when ralphm's next online he can create me a board (and add you as an admin)
Tobiasright...but until then we could enjoy ourselves with a fancy council meeting
Tobias1) Roll call
Link MauveHi. o/
Dave CridlandBacon, please.
Tobias2) Minute taker
Tobiasjcbrand, you're taking minute notes and send them out afterwards, right?
Tobias3) PR: Clarify CSI and Carbons state after SM resumption
TobiasFlow 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.
danielwhere are we currently with the NS bump for carbons?
danielfor now (regarding the other changes) it isn't necessary?
Tobiasphew, good question. Haven't read through all the feedback on the carbons LC yet
Link Mauvedaniel, it already needs one, for the removal of <private/>.
danielLink Mauve, are we going to remove that one?
danielsome people wanted to leave it in
Dave Cridlanddaniel, Georg Lukas has decided to actually put together a PR as a concrete proposal; I've not seen much feedback on that yet.
TobiasDave Cridland, is that PR already online?
Dave Cridlanddaniel, 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.
SamWhitedoh hey, there's a rendered version; I guess I don't have any excuse for not reading it anymore. Will do that.
Tobiasright, will put it on my todo too
danielDave Cridland, i can live with a bump but i'm not sure if it's worth doing only to get rid of <private>
Dave CridlandSamWhited, You've reminded me of some AOB. Thanks.
danielif that's the only reason
Dave Cridlanddaniel, Indeed; but Georg has added some other stuff.
danielbut anyway we should probably discus this in the PRs
Link Mauvedaniel, the rules definition from Ge0rG are much more of a reason to bump the namespace.
Dave Cridlanddaniel, Or even better, on the list.
Link MauveIf we decide to accept #434.
danielLink Mauve, ok if the rules are a reason it's fine with me.
danielbut lets move on
Tobias4) georg opened an PR on MUC, https://github.com/xsf/xeps/pull/436
Tobiasas 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.)
danielyes or ask georg to put the same phrasing in his PR
danielor cherry pick flows commit
SamWhitedDoesn'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 CridlandLink Mauve, I'd rather bump it knowing it might well bump some more than risk incompatible deployments.
Link MauveTobias, ok, adding it to my list.
Link MauveDave Cridland, of course.
Link MauveTobias, actually I know this topic quite well, so I’m +1 on 4).
Tobias4) Date of next
Dave CridlandOn #436, I think this needs some security considerations, in particular around replacing and/or removing client-added <x/> stuff.
Link MauveIt does solve the issue.
Dave CridlandTobias, Is Date Of Next (4) as well?
Tobias5) Date of next
Dave CridlandThank heavens for Last Message Correction...
TobiasDave Cridland, no, it says 5) here ;)
Link MauveDave Cridland, :)
moparisthebestany news on xep-368 ? :)
Tobiasthat would be 2017-03-08, 16:00 UTC
Link Mauvemoparisthebest, will vote on list.
Tobiasdoes that work for everybody?
Link MauveTobias, wfm.
SamWhitedWRT 0368: I think the council voting period is over, doesn't that mean Link Mauve's vote is an implicit +0?
Link MauveSamWhited, oh. :x
Dave CridlandSamWhited, Voting period ends tomorrow, I *think*?
SamWhitedOh right, it's Tuesday. Sounds good to me.
Dave CridlandSamWhited, I know, it's confused me, too.
Dave CridlandSo, my AOB:
danielfwiw 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
danieldave can still -1 if there is something i'm missing
danielwhere should we vote for that PR by the way? github?
Dave CridlandGiven 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.
SamWhitedDave Cridland: ♡
Tobiasdaniel, i'll call for votes next week, then either in the meeting or the minute notes for that meeting
danielTobias, ok. thanks
ZashTake the md2xep/xep2md hacks I hacked and make another diff viewer?
Dave CridlandI was thinking, for example, of pre-rendering PRs, maybe re-visting the diffs, and so on.
SamWhitedI 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 CridlandI do appreciate it's not "normal" GSoC fare, so I'm not sure it counts, but it feels like valuable work to me.
Tobiasall sounds sensible, we could probably put a "XSF" project on the GSoC project ideas page and put ideas there, if they have potential mentors
Tobiasalthough keep in mind the project ideas should be enough to fill a GSoC term
Link MauveTobias, depending on whether the student is more of a sysadmin type, it may actually take a full term.
Link MauveBut it should have clear goals, set by the student.
SamWhitedI think we have plenty of broken stuff or automat-able stuff in the build process to keep an ops-y student busy
SamWhitedI can make a list on the wiki somewhere
TobiasSomeone having further AOBs?
Link MauveNone from me.
SamWhitedNote that all the outstanding LCs end tomorrow again.
Tobiasright..will do some reading/voting later today
Tobiasseems there's no further AOB
Tobiasbangs the gavel
Tobiasthanks jcbrand for writing up minutes
danielthank you Tobias and jcbrand
KevDave Cridland: It's not immediately obvious to me that it's a bad idea, although it does need some work
danieli'm really not a fan of georgs carbon PR
Kev(it = gsoc editor work)
danielthese rules are way too complex and involve rules for XEPs that are hopefully going to go away soon
ZashI would be happy if the rules for things were simpler. :)
Dave CridlandKev, 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.
KevBut as long as it's development of tools we use, it seems fair game.
SamWhiteddaniel: 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
KevNot traditionally the sort of thing the XSF's done in GSoC, but it seems fair game.
Dave CridlandKev, 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?
danielSamWhited, yes. or trigger that with simple <copy/> and/or <no-copy/> hints
KevDave Cridland: I'm comfortable making a call on it once I see an idea fleshed out.
jcbrandminutes have been sent out.
Dave Cridlandjcbrand, Can you forward those minutes to standards@ as well, please?
Tobiasjcbrand, great council minutes, ta :)
jcbrandDave Cridland I sent them to firstname.lastname@example.org and email@example.com
Dave CridlandOh, I didn't notice. Thanks.
jcbrandIt's complicated :)
jcbrandI have to use two different email addresses
SamWhitedjcbrand: Thanks again!
jcbrandto send them from
jcbrandYou're welcome SamWhited :)
jcbrandI 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
jcbrandand also for the XSF members list
jcbrandI thought I'd still get that fixed sometime
jcbrandbut ja... just working around it for now
Tobiasthere's probably some mailman admin that could fix that for you :)
jcbrandYes, if there's someone here who can help I'd appreciate it, otherwise I'll ask around sometime