Ge0rGStill a bunch of votes pending, deadline tomorrow EOB.
Ge0rGor rather EOM?
jonas’EOM?
KevWe agreed 'end of Council', I believe.
KevEnd Of Meeting, I would assume.
dwdhas joined
KevI'm ready to vote on all of mine in the meeting, FWIW.
danielhas left
Ge0rGEnd Of Meeting, indeed.
Ge0rGKev: 👍
dwdRight.
dwd1) Is there anybody out there?
Ge0rGis out there
dwdKev, SamWhited, daniel ?
danielhi
peterhas joined
KevI is definitely here.
dwdOK.
dwd2) Agenda
dwdI am working on the assumption that the only items for a vote are anything outstanding from last week.
dwd(And that nobody is mad enough to try adding new stuff).
dwdSo with that in mind:
dwd3) Outstanding votes
KevI think it's everything from last week, yes.
Kevi.e. just the same agenda again.
Ge0rGI shortly considered adding items to vote on, but abstained.
dwdI believe I'm up to date, as is Ge0rG.
Ge0rGI've done all my on-list votes.
dwdAnd SamWhited is too.
KevAlright. We did agree last week to have discussions on them all this week, rather than just treat them as purely on-list, but w/e.
Ge0rGI anticipated objections to my requirement to make stanza @id = origin-id @id
dwdWe certainly can discuss.
Kev3) Advance XEP-0357 (Push Notifications) to DRAFT - https://xmpp.org/extensions/xep-0357.html
-1
4) Advance XEP-0359 (Unique and Stable Stanza IDs) to DRAFT - https://xmpp.org/extensions/xep-0359.html
-1
5) PR #692 - XEP-0060: correct "entity" to "<subscription/>" - https://github.com/xsf/xeps/pull/692
+1
6) PR #693 - XEP-0060: Remove unused 'node' attribute on pubsub#event item - https://github.com/xsf/xeps/pull/693
+1
7) PR #715 - XEP-0045: Add missing disco#info feature to example 4, 9, 78 and 218 - https://github.com/xsf/xeps/pull/715
+1
8) PR #716 - XEP-0030: Clarify 'disco#info' feature in 'disco#info' responses - https://github.com/xsf/xeps/pull/716
-1
dwdGe0rG, I suspect that's desirable, but also potentially difficult if the library sets the stanza's @id at the point of send.
Ge0rGKev: that lacks rejection rationale
daniel> I anticipated objections to my requirement to make stanza @id = origin-id @id
i think i suggested that a few times but the author always objected
Ge0rGdwd: ideally, the library should be the one adding the origin-id then
Ge0rGdaniel: yes, I suggested that as well, and got the same reaction.
Ge0rGThere was no rationale, so I'm using my Council hat now.
KevI can't see a reason not to make stanza id = origin id.
dwdGe0rG, Well, yes. But often, libraries bake in support after various apps have used them first.
jonas’dwd, then it’ll take a while for libraries to adapt.
Ge0rGdwd: I'm sure this is a problem easier to solve than multiple mismatching ids on a message
dwdGe0rG, That all said, I won't object very strongly whichever way it goes.
danielwasn’t the primary reason that smack can’t do it
Ge0rGbesides, we need to fix Receipts and LMC with origin-id in place.
dwdGe0rG, Could a server just add in the origin-id, then?
Ge0rGdaniel: even the old version of smack I run makes it possible to extract and change stanza IDs
Ge0rGdwd: that sounds like a reasonable proposal to solve some problem. I'm just not sure which one.
Ge0rGdwd: also not sure whether the rules of 0359 allow injection of origin-id
dwdGe0rG, If a client wishing to add in origin-id has to add the same id twice, then a server could add in that as well.
dwdGe0rG, Probably not, as written. My question was whether it made sense to do so.
Ge0rGAs already stated, I consider origin-id to be a hack to work around bad servers, so I'd rather burn it.
Ge0rGI can see some benefit in <stanza-id/> for MAM purposes, because you have an independent entity defining _that_ id.
Ge0rGOriginally, <origin-id> was a payload you were supposed to stuff into messages you send into a MUC or into transports, in the hope to see the element reflected
Ge0rGBut then we got MUC changed to discourage that, and transports probably can't retain XML payloads anyway.
Ge0rGSo in my eyes, <origin-id/> could go away.
dwdThat I could go along with.
vanitasvitaehas left
Ge0rG(and if you have a transport that can maintain XML payloads internally, you surely can send a reflected message to the sending client with the same @id attribute)
vanitasvitaehas joined
jonas’(for example, the transport implementation could inject its own version of the <origin-id/> thing into the "legacy" protocol and convert it back to the @id when the reflection comes back)
dwdGe0rG, Yes, I was just thinking that. So does that mean there's no point to origin-id excepting some old servers?
Ge0rGthe last reason to have <origin-id/> is that it's an indication that the client is using sufficiently-random @id's, and I think that can be signalled in an easier fashion, if needed at all
Ge0rGdwd: that's my understanding, yes.
jonas’I am amazed. will we really solve this battle in the last sitting of council? probably not because SW won’t be able to react in time...
dwdGe0rG, I'm not sure that *is* an indication of more than some vague intent.
Ge0rGdwd: excepting some old MUC implementations, to be precise
KevI think this is a mailing list or after-Council discussion really. We've reached -1 point, I think.
dwdKev, I think you're right.
KevI think.
jonas’aw pity
jonas’how about "apply these changes and then +1"?
jonas’where "these changes" points to a PR?
Ge0rGjonas’: not gonna happen in the next 15 mins
dwdRight.
Ge0rGhow about "take authorship away and do it right"?
Ge0rGno, I don't volunteer.
jonas’I do.
dwdAnything else ... XEP-0357? Kev, you'll owe rejection reasons, but I guess those are in your mail to list?
KevWe don't need to take authorship away to do it right, incidentally.
jonas’I was about to write "challenge accepted!" and do a PR right away, but then I figured that the security considerations of stripping existing stanza-ids probably really can’t be figured out in 15 mins
Ge0rGjonas’: my -1 was already conditioned on "make @id = origin-id", but now it looks like it's just -1
KevI think my mails today about both 357 and 359 are feedback enough on those.
KevEspecially as I'm the person that needs to make the 357 changes.
dwdTrue.
dwdCongrats on rejecting your own XEP.
Ge0rGSpeaking of taking ownership away.
dwdSo, PR #716?
dwdI was in favour of dropping the need to signal disco#info over disco#info.
Ge0rGdwd: is #715 fully voted on already?
Ge0rGdwd: re #716, last Council it was brought up that caps hash calculation would be inconsistent then
dwdGe0rG, Oh, no, daniel hasn't I don't think.
Ge0rGalso it's a MUST from a Final XEP
KevI think the normative change here is wrong at this stage. I think noting that it'll be elided from many examples is reasonable, and probably even that some implementations may elide it (although what the implications of that are isn't entirely clear. I think it doesn't affect 115, though).
dwdGe0rG, I think a client that includes it in disco#info includes it in XEP-0115, surely?
Ge0rGI'm not quite sure what Florian was trying to make on the list responding to my -1.
jonas’at the very least, doing it inconsistently will defeat some 115/390 caches
Ge0rGdwd: I think that having it being defined implicitly leads to corner cases. Also Final XEP.
KevWe /are/ allowed to modify Final XEPs.
dwdGe0rG, I'd be more convinced about the Final XEP argument if this affected interop, or indeed was actually followed.
Kev"Every effort" not to, though.
Kevdwd: I think the argument is that an implicit feature there might make future 115 bugs.
jonas’dwd, I think most implementations do follow it
dwdGe0rG, The fact that many implementations *don't* include disco#info, and everything still works, really does suggest it's wrong.
jonas’we do have the luck to have a huge stash of disco#info replies from both servers and (a bit outdated) clients if you want to make a survey
KevMy inclination would be to leave the normative language, but note a) that examples don't include it, and b) some implementations elide it.
jonas’I can modify the muclumubs ( https://search.jabber.network ) bot to make a stat on that
Ge0rG+1 to what Kev suggested.
dwdI can see I'm on the losing side here, and can go along with Kev's suggestion.
KevOtherwise I'm not strictly opposed to making it optional if we're very sure that the language we introduce couldn't cause caps weirdness with it being implicitly added.
Ge0rGKev: in my eyes, it's not about the language but about implementations that add it, then do caps, vs. implementations that just do caps.
dwdRight - anyone want to discuss anything else?
KevI'd like to thank everyone for their work this term :)
dwdGe0rG, I think if implementations were inconsistent then caps would be failing for them and people would have noticed, FWIW.
KevI think dwd is right.
dwdKev, Yes, I was going to do this:
dwd4) Thanks, All.
KevI'm worried that we might inadvertently make matters worse by adding language about optionalness. If we're sure we won't, I'm not strictly opposed.
dwdThanks to everyone for your efforts - not only Council, but jonas’s work on Editor stuff, too.
KevIndeed.
Ge0rGThanks to you too, Dave.
jonas’thanks to council :-)
jonas’this was a fun ride
KevAnd to the Chair.
jonas’let’s see what the numbers tomorrow bring for next year
dwdAlso, this year, we've had a number of useful contributions from the floor, so thanks to anyone who's chipped in.
Ge0rGI've heard we didn't pass that many XEPs to Draft, which is maybe a bit sad.
jonas’exactly one.
jonas’and it was the compliance suites
jonas’three months late or something :)
jonas’but whatever
Ge0rGjonas’: I've heard you are already preparing Compliance Suite 2019.
jonas’yeah, that cp sure takes a while...
KevIt's not Council's job to make XEPs ready for advancement, mind, so I don't feel too bad about that.
jonas’Kev, I didn’t mean to make anyone feel bad anyways
jonas’just for the record :)
Kev👍
Ge0rGWe have five minutes left. Any technical topics?
KevHappy for the 359 discussion to continue now I don't have to pay as much attention :)
Ge0rGKev: I'm not sure what's left to discuss there. I'd rather discuss Push.
jonas’what are my chances that someone updates the spreadsheet of doom right now so that I don’t have to go over the emails?
Kev359-2 then :)
Ge0rGBesides, should we propose a meeting time for the new Council?
jonas’new council will have to figure that out tomorrow night I think
KevWell, not tomorrow night, but yes.
jonas’although we could agree on a time; in any case, we know the maximum set of people who’ll be on it anyways
SamWhitedoops, sorry, had guests and wasn't paying attention to the time
Ge0rGit's probably overly optimistic to assume that all five candidates will actually receive a majority of votes.
jonas’Ge0rG, sarcasm?
Ge0rGSamWhited: are you missing any votes?
dwdGe0rG, Thankfully it needs people to vote against to actually lose.
Ge0rGjonas’: no, just saing it's rather inappropriate to proclaim "I'll probably get reelected anyway"
jonas’in any case, the wednesday 16:00Z slot wfm
Kevdwd: Simple needs people to not vote for.
jonas’for now.
SamWhitedNo, I emailed mine and should be all caught up now
dwdSamWhited, Ooops, soryr - didn't think, it's Turkey Day tomorrow, isn't it.
SamWhiteddwd: yup, don't worry, I forgot too and I live here…
dwdKev, Well, yes, but if they do not vote at all, that's not counted.
danielhas left
KevI'm not sure that's true.
KevSomeone can submit their vote, for no candidates.
Ge0rGLet's postpone this until after the election.
KevIf a majority of people did that, we'd have no Council.
dwdKev, True. But that counts as voting.
jonas’> Third, the individuals elected shall be those receiving the highest percentage of votes cast, up to the limit set by the Members and with the proviso that no individual receiving less than a majority of votes cast shall be elected.
Ge0rGDoes memberbot allow that?
jonas’Ge0rG, yes
dwdGe0rG, Yes.
jonas’you can abstain for all five
Kevdwd: Yes,t hat's what I said. It just needs people to not vote 'for'.
dwdAnyway. I think we may be done.
jonas’thanks again y’all
dwdKev, Yeah, I just think it's more likely they won't vote at all.
dwdSo, for the final time this Council:
KevOur voting rules are actually broken, because all we need is for enough (non-joke) candidates to apply and we can't form a Council.
dwd5) Ite, Meeting Est
KevDiolch, pawb.
ZashThanks all
jonas’Kev, as long as this doesn’t happen to board (or whoever has power to fix bylaws), we’re good!
Ge0rGKev: so we need to define a second ballot process with at most 10 candidates?
dwdKev, I suspect that it's memberbot breaking. The way the bylaws are written, one could argue that each council candidate is voted for/against individually.
Kevjonas’: I think that for Board we're probably already covered.
Kevdwd: True.
jonas’dwd, I agree
jonas’I was a tad surprised to see the memberbot process after reading the bylaws more carefully this time
dwdMeeting's tomorrow night at 1900Z, right?
jonas’yes
danielhas left
danielhas left
jonas’also, I don’t think that we need to have an elected board to fix the bylaws... we could have an all-member-vote about the change :)
KevISTR (without checking) that in the case that we somehow had no Board elected, Peter could pick his own.
dwdjonas’, We did that one time in a meeting when we realised we'd catastrophically f**ked up. Ah, it was fun.
dwdjonas’, Strangely, XSF Meetings were very well attended for the next few.
jonas’:D
jonas’storytime?
SouLis paying attention.
KevThere was a thing. Hopefully there isn't a thing again.
danielhas left
danielhas left
danielhas left
vanitasvitaehas left
vanitasvitaehas joined
peterKev: I can't do any such thing because I'm no longer the executive director.
KevAh, ok. I thought you still were until they found a new one :)
peterSeems to me we're doing fine with just the council. And as noted the members can always call a special meeting to fix things.
peterer, board
danielhas left
KevI prefered your first version :)
peterheh
lnjhas joined
Ge0rGKev: accidentally candidated for the wrong panel?
dwdI hope not, otherwise Council's short.
danielhas left
petereven if the Council were short, it could presumably nominate another member after the election, no?
KevYeah.
KevI think we've entered silly territory now.
Kev"now".
Ge0rGI thought the Council is allowed to be short.
jonas’tallism!
jonas’heightism!
ralphmhas left
peter:-)
dwdhas left
Zashxnyphs for new ED?
Zashxnyhps for new ED?
moparisthebesthas left
Link MauveRe the discussion about XEP-0359 here, what you actually want is to revive https://github.com/xsf/xeps/pull/689 right?
moparisthebesthas joined
KevWithout reading and just going on the title, maybe :)
Ge0rGDiscussion on the editor issue tracker.
jonas’nooo
Ge0rG> XEP-0359: Replace tabs with spaces.
WHY?!
Holgerhas left
Ge0rGI like #689, except the implementation note says "to be set by the emitting client on every message to a MUC" - I don't see <origin-id/> as a MUC-only thing.
Zashhas left
Ge0rGLink Mauve: you could have confused the Council by bringing up #689 right in time for today's Agenda.
KevCouncil don't need to be more connfused than usual :p
jonas’next week, he might be able to confuse himself with that