KevSounds about right. I admit I've become completely reliant on the minutes-in-advance already.
jonaswminutes-in-advance?
Kevsighs
KevAgenda in advance.
jonaswah
jonaswthat makes sense :)
KevI'm ill, don't pick on me :p
jonaswI won’t, I promise
jonaswalso, get well soon
KevTa. Only a cold, but it's getting old.
jonaswancient colds are the worst; today’s immune systems just aren’t used to it anymore ;)
genofirehas left
jerehas left
jerehas joined
DaveSorry, I got sidetracked yesterday while trying to do those minutes-in-advance. They *are* good, but I need to block the time out on my calendar to egt them done, I think.
jerehas left
jerehas joined
Ge0rGDave: if you finish them until 1600Z, you can just paste them and we are done in time.
DaveGe0rG, Yeah, but doing them 24 hours ahead (as was my intent) means Council folks are hopefully able to vote in the meeting.
DaveWait, I said minutes too. I meant Agenda, if that wasn't clear.
DaveSpeaking of minutes, anyone want to do those this week?
Ge0rGDave: I can do them if there are no voices from the floor.
Ge0rGOr... from the peanut gallery.
DaveGe0rG, Thanks, but I'm hoping one of the many people here can take them on...
Ge0rGI'm sitting in a train and it's rather calm. I really hope there is no reservation for my seat, though.
KevHere.
DaveI've preemptively updated the Spreadsheet of Unofficial Doom with the two PRs which are subject to a vote, though I note that #576 might not actually need a vote as such.
DaveAnd yes.
Dave'tis time.
Dave1) Role Call:
SamWhitedo/
DaveI'll assume Kev and Ge0rG are here. daniel ?
DaveI'll assume no daniel then.
Dave2) Minutes
DaveAnyone from the floor?
DaveOtherwise, I'll take Ge0rG up on the offer, then.
DaveGe0rG, That OK?
danielSorry I'm here now
Ge0rGDave: sure
SamWhitedI'd like to discuss deprecating XHTML-IM again at some point, I think the previous councils concerns were addresssed and the card has been sitting there since then.
DaveSamWhited, That's true.
Dave3) Outstanding Votes
Davedaniel, I'm missing one from you on the Client Key Support ProtoXEP, I think.
danielI'm +1 on that
danielUnless you want me to write that on list
Davedaniel, No, here is fine. And you're voting -1 on TOTP 2FA? (You said "inclined to" on the list)
danielNo I'm +1 on that as well
DaveKev, My understanding is you're witholding your vote on '387 until that's been resolved?
KevMy original vote was +1 pending the merging of the PR.
KevIn an ideal world I'd like to stick to that.
Ge0rGDo we need to vote on making jonasw the new author?
DaveKev, Conditional voting has yet to be implemented in the Spreadsheet of Unofficial Doom, so I'll just say you're not yet voting and hope we resolve it all.
KevGe0rG: I don't think so, as long as Sam hasn't changed his mind about stepping down.
DaveGe0rG, I don't think so, but I'd like to be clear we're all happy with that, hence:
KevGe0rG: Some formal action to replace an author from Council would be sensible (although I'm not sure we have or need process), but I don't think that's what's happening here, if Sam asked for a volunteer, and Jonas volunteered.
Ge0rGJonas volunteered, but is currently busy so he can't merge the PR. If we approve that decision (do we need to?), he promised to merge the PR, and then we have all the votes needed.
Dave4) #576: XEP-0387: Add myself as author and move back to Proposed
DaveAnyone object to this? (It's basically Jonas taking authoriship)
SamWhitedI'm fine with Jonas taking over
KevI've not reviewed, but if it's Jonas becoming Editor, I'm fine with it
Ge0rGauthor, not editor
DaveOK.
KevDon't pick on me, I'm ill :p
Ge0rGjust clarifying :)
Ge0rG+1 to #576
KevBut yes, Author.
DaveI hear no objections, anyway.
KevFWIW, I think Council should (not today) try to reach a consensus on advice to Jonas for what these should be going forward.
KevI quite like my idea of explicitly splitting between "Best we have" and "State of the network".
DaveKev, "These"?
DaveKev, Oh, Compliance Suites.
KevThese = Compliance suites that may or may not really be compliance suites.
DaveKev, Yeah. I think it might be an amusing hour's chat at the Summit, actually.
KevI think the point is right that it's useful to give advice to people who don't care about public network interop, but want the best we have to offer.
Kev(Daniel's, I think)
KevBut also I think it's important we don't discourage new implementors who want interop by not representing the backwards-compat needed.
KevSo being explicit about both sounds ideal to me.
Ge0rGAre we voting on #576?
DaveGe0rG, We sort of did. I asked for objections and nobody gave any. I'm logging it as a vote even though it isn't really.
Dave5) #559: XEP-0045: Specify 333 stats code
Ge0rG+1
Davehttps://github.com/xsf/xeps/pull/559 if you prefer.
jonaswokay
jonaswI’ll merge my authorship for XEP-0387; shall I merge Kevs PR while I’m at it and move it to draft, too?
jonasw(sorry, I’m a bit late, I was busy with work stuff)
DaveI think I'm +1. I'm not convinced that this isn't a kick, and I'm not convinced kicks are solely for bad behaviour, but this does no harm.
Ge0rGjonasw: yes, you can merge that PR.
KevHaha, what a well-worded MAY MUST.
Ge0rGIn that case, we are missing Sam's voice (as Council member) for the post-PR 387.
Kev+1. I don't think it's harmful, although I think it's really a Kick.
Holgerhas left
Davejonasw, I'll give you a massive list of stuff to do as Editor in a bit, too. :-)
Ge0rGIIRC everybody else has voted +1 for the PR-merged version already.
jonaswDave, \o/
DaveGe0rG, One thing at a time, please.
jonaswI like lists
Davedaniel, SamWhited - #559?
jonaswKev, I’m not saying this is not a kick, I am saying this is a kick with a specific reason which is good to know for clients on either side of the kick
jonaswshall I clarify that in the text?
Kevjonasw: I think it's fine.
Davejonasw, It's fine.
jonaswokay
danielDave: I'm -1 on that and would like to have the general debate first on what direction we want to take the compliance suites to
Davedaniel, I'm not sure I understand what the compliance suites have to do with #559.
SamWhitedYah, I think I'm confused about what agenda item we're on too
danielSorry. We are talking about too many topics at once
jonaswI’ll stop my source of confusion and hop onto my train, sorry :)
danielLet me look up that pr
Kevhttps://github.com/xsf/xeps/pull/559
Ge0rGSomebody mixed in the future of Compliance Suite into agenda item 4.
danielYes I'm +1
SamWhitedI'm on list for #559; I'm tentatively -1 to adding anything to MUC, but need time to digest the PR.
DaveOK.
DaveThat's basically all I had for the agenda. We have two items to revisit, however first I'd like to figure out our next meeting, since that's more complex than usual.
SamWhitedI'd like to propose that we do a meeting at the summit; I wanted to do it last year too but it never happened.
Kev+2w, I suggest.
DaveIn Summits of Yore (several years ago) the Council has tried to meet in person at the Summit. Given that many of us will be travelling on the Wednesday (I am, certainly), I wondered if that was something people wanted to try?
KevI'd rather not, as I don't think it's a good use of the summit time, really.
KevEveryone not on Council is excluded (in practical terms), and we'll probably have many items to discuss.
daniel> I'd rather not, as I don't think it's a good use of the summit time, really.
+1
SamWhitedAfter the summit at the pub then; "in person" being the important part
Ge0rGFeel free to meet in person at the summit, or not.
daniel> +2w, I suggest.
+1
KevThere are things Council should discuss soon, including compliance suites, and I'm fine with doing that, but I wouldn't have a Meeting.
DaveOK. Are we all going to the summit?
Kev(BTW, I won't be here for +2w, but I'll happily vote on list)
Ge0rGis not going.
Kev(Or, I might not be. I'll be on holiday anyway)
DaveGe0rG, Boo.
Ge0rGcan't even promise remote attendance.
SouLGe0rG, sad!
SamWhitedI would specifically like it to be a meeting; I think it helps focus everyone if it's "official" in some sense and in person.
KevI don't think it'd be possible for me to *be* more focussed during the summit than I usually am :)
Ge0rGDave: I'm currently in the (early) proces of moving to a place 500km less far away from Brussels, so consider this an investment into next year's Summit.
danielIf I remember correctly it was a pain to schedule this last year. I can't even remember if we actually managed to have a meeting
DaveOK. We'll go for +2w, then.
Ge0rG+2W WFM
DaveSo, back to AOB.
Ge0rGI'd like to get a vote on 387 with #569 applied.
Ge0rGThis is Kev's feedback in https://github.com/xsf/xeps/pull/569
DaveGe0rG, So would I, but daniel asked for this to be after we've discussed the nature and purpose of the XEP.
Ge0rGDave: ah, that was the out-of-context -1 I wasn't able to associate.
DaveSamWhited, You want to talk about XHTML-IM? I'm (still) happy to deprecate it.
KevI remain not sold on deprecating it, but I'm not intending to block it happening.
SamWhitedRE XHTML-IM the only concerns raised last time was that there were no alternatives. There are now at least two competing standards for doing the sort of thing XHTML-IM is normally used for, and at least one of them has one implementation in prod (Conversations) and at least one experimental one.
DaveSamWhited, Otherwise I'll just stick it on the agenda for next meeting.
SamWhitedIf there are any other concerns I'll try to address them, otherwise I think we should hold a vote again.
DaveIf I held a vote now, are people ready? Otherwise I'll just do it next meeting.
KevI think it'd be better for people to have a chance to revisit the discussion before voting.
KevI don't think having unexpected votes in meetings is conducive to either reasoned votes or getting into the desirable habit of voting immediately rather than onlist.
Ge0rGI think XHTML-IM is not really replaced by either "alternative".
DaveOn balance, I'd prefer to hold the vote later if only to get a feel for the consensus in the community over the Summit on this one.
DaveKev, Yeah, I'll go along with that logic too.
KevSo I suggest we just vote in +2w (when I will then probably have to onlist regardless, so I'm low-F)
DaveRight, I'm doing that. SamWhited, you can spend the next two weeks convincing Ge0rG. :-)
Ge0rGRe 387, can we please just get it published now and postpone the structural redesign for 2019?
Ge0rGdaniel: ping?
Davedaniel, You are, I think, the only one expressing the opposing viewpoint to Ge0rG, so this is your call really.
danielGe0rG: I don't want to block it all cost. But I prefer we'd talk about it next week at the summit
Ge0rGdaniel: it's a month overdue already, and next Council meeting is in +2W.
danielNote that I did give my +1 to the as is version
Ge0rGdaniel: and if there is feedback (and there will be!), we are talking about more iterations
danielIf you want to publish it at all cost just publish that
Ge0rGdaniel: note that I asked for voting, now, on the version with Kev's feedback included
Ge0rGI'm pretty sure everybody had sufficient time and opportunity to review both the current and the changed versions.
danielYes I know. I was trying to give you another option if you are desperate to get it out of the door
DaveSo OK. Let's do a specific vote on XEP-387 with Kev's PR merged:
DaveI'm +1
Kev+1, natch
Ge0rG+1 (as stated last week and the week before)
ralphmhas joined
Ge0rGSamWhited, daniel?
ralphmhas joined
Davedaniel, If you want to block until the discussion, that's your call. You can vote on line immediately afterward, too, since I've restarted the clock on this one.
Davepfft. "on list", I mean.
Ge0rGdaniel: I can't publish the pre-PR version because it's -1ed by Kev.
danielOn list then
DaveSamWhited, ?
SamWhitedI'll abstain with the note that I am absolutely against the president set by merging 11th hours changes and that we had a perfectly good way to move these forward before.
DaveSamWhited, OK, thanks.
DaveAny Other Any Other Business?
Ge0rGI'd like to propose all council members to read Kafka's The Trial until next meeting.
DaveSeconded.
DaveAnythign else?
Kev*until*?
KevThat's a lot of reading
KevAnd no, nothing from me.
DaveThen I think we're done. Ite, meeting est - thanks all.
SamWhitedThanks all!
Ge0rGthanks :)
SamWhitedGe0rG: With respect to XHTML-IM, if it helps I've found yet another XSS vulnerable client since the last time we talked. Even if the new things don't replace 100% of use cases, it feels worth deprecating just because so few people can implement it securely.
KevThanks all.
Ge0rGSamWhited: I'm not going to veto deprecation, I'm just not convinced that what we have as alternatives is a 100% replacement.
SamWhitedGe0rG: I agree with that; it's not a 100% replacement.
DaveGe0rG, Also, I agree *entirely* that there aren't replacements for all the use cases of people embedding XHTML into XMPP - but I think for the limited cases XHTML-IM was intended to address, I think we have replacements for most common use cases.
Ge0rGDave: yes, Styling is an 80% solution, and a really awesome one (I can say that because I shamelessly stole Daniel's code)
ralphmhas left
DaveGe0rG, Right, exactly. I totally get Goffi et al saying they need XHTML extended, not removed, but they're using it in a blogging engine (sorta), and not IM.
Ge0rGMaybe I can get consistent source code highlighting by using Styling with ```<language-tag>
DaveGe0rG, A bit niche, I feel.
SamWhitedGe0rG: I'm still torn about whether or not it's worth having a specific "source code" tag. It does feel niche, but then again developers are probably 90% of the people using XMPP. Hard to decide if it's worth the complexity.
KevOptional?
pep.Dave, I disagree about the niche point, goffi and edhelas would like to also allow XMPP to flourish that way, and this is not helping their case. (I'm not sure about edhelas' positions re xhtml-im)
pep.By *that way* I mean pubsub and stuff
Ge0rGSamWhited: I don't think that specifying the first line as "optional source code identifier" adds complexity
SamWhitedOptional is a nice way of saying "unreliable".
Kevpep.: They're publishing source snippets in particular languages?
DaveSamWhited, I'm cool with putting the "a content tag would go here" in the spec. Less cool with stipulating formatting for C++ and whether braces should be bold and yellow or not.
ralphmhas joined
DaveKev, Different issue. They're dumping complex bits of XHTML into pubsub items.
KevSamWhited: As long as the fallback behaviour is clear and sensible, that's probably ok.
SamWhitedDave: Oh yah, I was thinking it would just be a way to say "this is a language".
KevDave: Yes, but I thought your comment about 'niche' was the source code rendering?
SamWhitedNot specific coloring or formatting
KevOr I completely misread the order of messages.
KevSamWhited: Well, mandatory then, works for me :)
Ge0rGI don't see adding a multi-language source code parsing & coloring library into my mobile XMPP client, so having sender-side coloring via XHTML-IM was at least theoretically helpful
SamWhitedMaybe it's worth saying "text after the ``` is a meaningless tag that's not part of the pre block" and then just let people use that for whatever they want (which will probably be code highlighting)
Ge0rGThe whole tag thing starts to fall apart as soon as you try to standardize the potential values. What's C++? "cpp" or "cxx" or "c++"?
SamWhitedIf clients want to make a separate spec that say to use values from pygmetized's registry, they can do that.
Ge0rGSamWhited: I wouldn't say it's meaningless, because it's also useful for the reader to know which language it is, even if not colored
Davepep., I'm very much not against embedding XHTML into pubsub items. That is not what XHTML-IM was designed for, and not what it specifies either.
SamWhitedGe0rG: fair, maybe it still shows up as a title or something.
Ge0rGSamWhited: just say it's a language tag without strict enforcement.
pep.Dave, ok. You'd rather see W3C XHTML in there?
SamWhitedI vaguely like the idea of just calling it a "tag" and not specifying a use for it, but I'm also worried that people would end up shoving random stuff in there as a sort of side channel API (one client thinks its a title, another thinks they can pub a JSON blob there that determines something about how it's rendered, etc.)
KevCountdown until someone puts CSS in it. 3...2...
Davepep., XHTML-IM is a small, strict subset - and one which Goffi and edhelas do not restrict themselves to. It is defined to be held within a specific element within an IM message - which Goffi and edhelas do not do.
Ge0rGSamWhited: "a short tag intended for improved syntax highlighting of the following block"
Zashhas left
SamWhitedGe0rG: then someone does cpp and someone does C++ like you said and it's only use is for a particularly niche community. I'm not against it, it just gives me the funny "this is going to go horribly wrong" feeling.
ralphmhas joined
Davepep., It's possible, in fairness, that Movim (for example) allows users to send IM messages with XHTML in, and it's possible that they're using the strict subset that XHTML-IM defines. But the use-cases they've described on-list are talking about the pubsub stuff with much richer markup.
Ge0rGSamWhited: this is the same argument I had against all of Styling.
SamWhitedGe0rG: what do you mean? Right now I think it's very strictly specified to avoid that
DaveSamWhited, You don't think a common set of tags would emerge?
pep.Dave, actually only goffi uses xhtml-im, edhelas is using atom. I named both because they are both on the pubsub front.
Davepep., Doesn't edhelas's Atom contain XHTML?
SamWhitedDave: I don't, not if we don't specify a common set.
Ge0rGSamWhited: that the syntax will inevitably lead to incorrectly styled messages for path names or other nerdy things.
KevI think the odds of a common list emerging organically are slim.
pep.Dave, I don't remember, I don't use that feature myself, but that wouldn't be xhtml-im in any case
DaveSamWhited, I don't mean that everyone will use exactly the same set. I mean that whether to use "c++" for C++ or "cpp" would probably stabilize.
SamWhitedDave: I disagree; if some Java syntax highlighting library expects c++ and the python one expects cpp I suspect each client will just do that.
Davepep., That would be my point. Goffi uses tables and things which aren't in XHTML-IM, too.
Ge0rGWe could introduce our own registry of language names!
SamWhitedGe0rG: now we're back to my ponint of "is all the additional complexity worth it?"
DaveSamWhited, That's a possibility. But I think those libraries might well have stabilized themselves anyway.
Ge0rGSamWhited: or maybe the Java and python libraries will be PR'ed against to support the respective other name
Ge0rGSamWhited: </s> just in case
pep.Dave, I meant, edhelas wouldn't call it xhtml-im in the first place (whatever is in the atom node).
Davepep., Ah, OK.
Davepep., But in any case, what they want to do - I think - is generically embed full XHTML into XMPP, particularly pubsub nodes. And that's almost exactly not the thing I think ought to be deprecated.
Ge0rGSamWhited: I think the right level of detail is to say that it's a short language tag without further defining the expected content
SamWhitedI think that's the best idea out of the things we've just discussed, but it still feels like we're adding more stuff to the spec to cater to a niche community (although it probably is a large portion of XMPP users) and adding it in such a way that interoperability may be a problem
SamWhitedAgain, I'm not against it, I just don't see a compelling reason to do it either yet and I tend to lean towards "don't add more stuff unless it's absolutely necessary"
Ge0rGSamWhited: if we don't call it a "language tag" but a "syntax highlighting hint", it might be usable for coloring non-languages as well
Ge0rGThough techically, I suppose, everything you want colored in a blockquote is a language
Ge0rGSamWhited: I think that having an inconsistently used tag is a lesser interop problem than just defining it as something to be ignored
pep.Dave, apparently 0277 recommends using XHTML-IM
Ge0rGLet's not drift away into the "undefined behavior" vs. "implementation-defined behavior" trap of modern C.
Ge0rG...of modern C *compilers*.
pep.2.3.1
Davepep., Ah. So *that* needs fixing.
inkeyhas joined
vanitasvitaehas left
Davehttps://docs.google.com/spreadsheets/d/1AZ-Sna6OiRG--b-mJMKv3XXfrn3Nehm0kAtlyJvImL0/edit updated, by the way. Might add another column to track if the editor has processed the result.
XMPP Council - 2018-01-24