Tobiasam I missing something or should there be a trello card for " Proposed XMPP Extension: Message Markup"?
SamWhitedI thought there was…
SamWhitedI wonder if I archived that one by mistake, I can't figure out how to view the archives
SamWhitedfound it; it's not in the archives, so nevermind.
Tobiasgot a link?
SamWhitedI found the archives, I mean. It's not in there
mathieuiTobias, you have to go to "more > archived items"
mathieui(but it’s not there, as SamWhited says)
SamWhitedI don't see anything in the history either, maybe we just never made one.
Link MauveI half-remember it not being here last week.
SamWhitedI added a card for the LCs ending today.
Tobiasseems it's about time
Tobias1) Roll call
Tobiasdaniel, dwd, SamWhited, Link Mauve, ping
Link Mauvedwd doesn’t seem to be here right now.
Tobias2) Minute taker
Tobiasjcbrand, are you available?
TobiasSo what's on our agenda today? :)
dwdHere now, sorry.
dwd(Had a phone call at just the wrong moment)
Tobias3) Accept the two ProtoXEP that have passed their acceptance time (Jingle Encrypted Transports + pubsub#multi-items )
Tobiasi guess if they passed acceptence time the remaining votes count as non-vetos, right?
Link MauveDefault ±0 from everyone who didn’t vote.
SamWhitedI don't think there's anything to do with these, just throw them on the Editors trello
danielyes. although I would be +1 on both of them
danielif i hadn't forgotten to vote
Link Mauve(I just archived BMH, fyi.)
Link Mauve(It also passed its acceptance time with two -1.)
Tobiasi moved them to the editors coulmn
Tobiasi moved them to the editors column
SamWhitedTobias: Do you have access to the editors trello (I think you should?) can we move cards directly there and remove the for editors column on ours?
Tobiasperhaps...i don't know about the magical trello powers
Tobias4) Compliance suites / MAM LC ends today ( SamWhited added this one )
TobiasSamWhited, is this just a reminder or specific discussion?
SamWhitedI don't know, I assume if the LC is over we should vote?
Tobiasis it over already or does it end today?
SamWhitedIt ends today
Link MauveIt ends today.
Tobiasthen it's probably something for next week, right?
SamWhitedI don't think it really matters; seems worth getting it out of the way
SamWhitedUnless you expect lots more discussion to suddenly happen in the next few hours
KevI don't think it much matters, does it? I think there's agreement it needs changes before advancement.
KevSo it's going to go through another LC and it's not like anyone's feedback's going to be ignored. If you were about to approve it before the LC was over that might be a bit different.
SamWhitedI think the compliance suites at least are ready for a vote
SamWhitedKev: can you commit to doing the work 313 needs in the next LC period?
TobiasSamWhited, XEP-0387 is on its way to draft, right?
dwdI'm sitting here nodding, but that isn't useful - XEP-0313 needs a new version, so it seems daft to sit on it for another week just for the sake of a couple of hours.
KevDepends when the next LC period is, presumably.
SamWhitedKev: What sort of a LC period would you like? I think we can be flexible :)
KevI don't think we need an LC period until the changes are in.
Link Mauvedwd, I agree, we should put it back to experimental until Kev or someone else makes the requested changes.
SamWhitedoh I see, I don't really care about the process, whichever
Link MauveThe next LC will be called when these will be published.
dwdLink Mauve, And *then* last call it again. :-)
SamWhitedI was just trying to convince Kev to commit to something out loud :)
Tobiasalright...then let's vote
Tobias5) Vote on moving XEP-0387 (XMPP Compliance Suites 2017) to Draft
TobiasI'll vote on list
SamWhited(they're "2018" now, FWIW)
dwdWhere are we with 114? I'm a bit lost on the outcome of that.
TobiasI just compied the email subject
SamWhitedOh sorry, I meant to send a mail about that. I'm pretty torn, but I decided to leave it as is and let the council vote.
SamWhitedWe can address that in the 2019 ones (which I will start as soon as these go to draft)
Link Mauvedwd, it’s still included.
SamWhitedIt doesn't seem important enough to block them to me, but of course YMMV
Link MauveStill in core, as per the discussion on list.
dwd+1 to advance to Draft.
Tobias6) Vote on moving XEP-0313 (Message Archive Management) to Draft
Tobiasthis is just for completeness
Link Mauve-1, since changes are on the way.
dwd-1, since change are on the way.
dwd-1, since changes are on the way.
SamWhitedI'm torn because I still think it's stupid to have MAM and Message Archiving at the same time, but it hardly matters at this point.
SamWhited+0 I suppose
KevI'm of the opinion that 136 should be deprecated regardless, but that matters not.
Link MauveSamWhited, I’m going to take that to AOB.
SamWhitedI do think MAM still needs some upgrades too, but we've been saying that for a long time so part of me feels like it's time to call it "good enough" and be done with it (unless of course Kev will do the updates :) )
KevThe main issue as I see it is removing the config into a new XEP.
dwdI'd be happy to deprecate '136 at this stage. MAM is clearly "almost Draft" at this stage, I'm fully expecting it to fly through LC next time.
jonaswIIRC MattJ mentioned something about wanting to split it?
KevIf I was to do that, would those -1s go away?
KevI've forgotten what I said in the thread :)
Link MauveKev, archiving rules were also part of the complaints I’ve seen a lot.
ZashI'm going to cry if you bump the namespace again
KevZash: No reason to, I think.
Link Mauvedwd, same.
KevLink Mauve: I think we should do what we did with Carbons, there. Allow wiggle-room, so we can standardise later when the Big Picture is sorted.
FlowAlso the empty MAM-query result is underspecified
Link MauveKev, exactly.
Link MauveWith these two changes, you would get my +1 next time.
Kev(And possibly note that using the same rules for carbons and mam probably makes sense)
ZashKev: FWIW I'm forgetting the reason why the last ns bump was justified
KevZash: It might not have been, it's always possible I've been stupid.
dwdZash, Because. I moaned at the time it wasn't needed.
dwdZash, Unless that was the last one.
Tobias7) Date of next
Link MauveAs I see it now, that last namespace bump could have been avoided, sadly.
KevWe live and learn.
Link MauveTobias, there were two other cards there.
Link MauveNamely my proposal to deprecate 0084, and fixing 0048.
Tobiasthere are tons of cards...but apparently there's AOB and at one time we said we didn't want to have meetings longer than 30 minutes
Link MauveNamely my proposals to deprecate 0084, and fixing 0048.
Link MauveOh, go ahead then. :)
Link Mauve+1W works for me.
Tobiasis that the last meeting of the current council or how many meetings are left?
Link MauveOne left, next week.
KevI have a quick AOB that I'd like to run up the flagpole and see if anyone salutes :)
dwdWe have a flagpole?
dwdAOB: We should totally get a flag.
Link MauveAOB (shared by a few other members): vote to deprecate 0136.
Link MauveI’m +1 on that.
Tobiasthat probably makes sense
SamWhitedI am still definitely +1
TobiasAny further AOB?
KevI think it might be too early to do anything standards-track with "xmpp 2", but I'm thinking it'd be good to write up an Informational XEP that overviews the issues we're trying to solve, and the directions we're thinking of taking, so we can get something written and published. Then we can update it as the mailing list discussions advance, and eventually do the standards-track work required. Does any of Council think that's a reasonable or stupid idea? I'd feel better if we had something in a XEP somewhere, even non-normatively Informational.
Kev(If anyone wonders, there is precedent for doing this)
SamWhitedHaving some sort of document (informational XEP, wiki page? Whatever.) sounds sensible to me
Tobiassounds sensible to me
Tobiashistorically XEPs have been more tolerant to disk failure than wikis
dwdI think any real attempt to make a genuine "XMPP 2.0" would be a disaster.
danielmhhh i think the wiki might be a better idea. i'm afraid that external people (people who are not that involved in the community) might get a wrong idea from a XEP
Link MauveKev, sounds like a great idea, will be more “official” than the various wiki pages or burried Ge0rG emails.
danieleven if it's just an 'informal' xep
Kevdwd: You know that's not really what I mean :)
jonaswso let’s choose a different title
jonasw"Message Routing Improvements"
Link Mauvedaniel, informational*
Link MauveIt would be formal.
Kevdaniel: Informational, describing the issues we're trying to solve. I think that being formal actually *is* a good thing.
jonaswI share daniels concern when we have a XEP called "XMPP 2.0"
dwddaniel, My understanding is that most of the suggestions are server-side, and the server community tends to be both smaller and more observant of the standards process, so we should be safer.
KevI'm genuinely offended that you really think I'm going to author a XEP called "XMPP 2.0" for this.
jonaswKev, don’t be
Link MauveOh, thanks for reminding me I’m too.
TobiasAny further AOB?
SamWhited0280 changes and OMEMO have been cards forever
SamWhitedThey appear to have stalled, should we do something with them?
Tobiasyeah we should
Tobiasdon't know what though
jonaswOMEMO is dealt with I think?
Tobiasi'm not so sure about that
Tobiasmaybe Remko knows or so
dwdjonasw, Dealt with? The outcome appears to have been for the proponents of sticking with libsignal only to ignore everybody else.
danieli think 0280 changes will be superseded by our 'xmpp 2.0' attempts
danielso we can probably just dismiss that
SamWhitedMay I close that PR and say that we're planning a document on routing rules that will hopefully make things clearer?
danielmaybe ask georg if he is fine with that but i guess he will be
Tobiasyou could at least ask if the initiater of the PR is fine with that
Tobiaswhat daniel said
jonaswthey could always reopen if they are not
Link MauveAlso that it should be handled by the new non-MAM-only rules.
Tobiasregarding OMEMO we should check back with Remko and Andy i guess
dwdSo what happens to XEP-0280 in the meantime?
Tobiasprobably on ML or GH
danielend the last call. let it go back to experimental
Tobiaswhat daniel said
danieli feel like it's too early to deprecate
Link Mauvedwd, it would be useful for it to get the same treatment as 0313, as in getting the specified archiving rules removed, IIRC it was the only complaint on the mailing list, so it could then go through LC again and become draft.
dwd'280 has very few rules. That was the argument against it.
Tobiascould we move the rest of the discussions to the ML, this meeting is alrady running for 45 minutes?
KevThe weasel words were so it could go to Draft.
KevBecause we're free to set concrete rules later.
SamWhitedSince the routing rules discussion is probably much bigger than carbons, I think Carbons is firmly in the "good enough" category and should go to draft personally. If MAM supersedes it at a later date, we could deprecate.
SamWhitedMAM or some other routing rule change that's incompatible, that is.
dwdWhat SamWhited says.
Link MauveI would be fine with advancing it too.
Tobiasyeah..something to discuss or vote on in a different meeting
Tobiasbangs the gavel
SamWhitedI'll add a card for next week
Tobiasthanks jcbrand for taking the notes
Link MauveIs 0280 still technically in LC, despite the expiration?
Link MauveIf so we could vote on it right now.
KevLink Mauve: More or less. It's been implicitly extended by Council not doing much with it, I think.
FlowI'm a little bit shocked by the sudden rush to advance 280 no matter what, it has still open issues that where raised on the LC ~9 months ago
Link MauveDamn, network outage right at the wrong time…
Tobiasi guess with more than 9 monhts in LC, it doesn't matter if you vote now or next week
dwdLet's pop something on the list saying we'll vote to advance next week then.
SamWhitedSent an email about 0313 not going to draft.
SamWhitedAlso, apologies for being late on the markup vote. I will try to review it this week.
SamWhitedOops, I forgot that 0286 was also under LC. Moving that back to the council board for next week too.