Sounds about right. I admit I've become completely reliant on the minutes-in-advance already.
jonasw
minutes-in-advance?
Kevsighs
Kev
Agenda in advance.
jonasw
ah
jonasw
that makes sense :)
Kev
I'm ill, don't pick on me :p
jonasw
I won’t, I promise
jonasw
also, get well soon
Kev
Ta. Only a cold, but it's getting old.
jonasw
ancient colds are the worst; today’s immune systems just aren’t used to it anymore ;)
genofirehas left
jerehas left
jerehas joined
Dave
Sorry, 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
Ge0rG
Dave: if you finish them until 1600Z, you can just paste them and we are done in time.
Dave
Ge0rG, Yeah, but doing them 24 hours ahead (as was my intent) means Council folks are hopefully able to vote in the meeting.
Dave
Wait, I said minutes too. I meant Agenda, if that wasn't clear.
Dave
Speaking of minutes, anyone want to do those this week?
Ge0rG
Dave: I can do them if there are no voices from the floor.
Ge0rG
Or... from the peanut gallery.
Dave
Ge0rG, Thanks, but I'm hoping one of the many people here can take them on...
Ge0rG
I'm sitting in a train and it's rather calm. I really hope there is no reservation for my seat, though.
Kev
Here.
Dave
I'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.
Dave
And yes.
Dave
'tis time.
Dave
1) Role Call:
SamWhited
o/
Dave
I'll assume Kev and Ge0rG are here. daniel ?
Dave
I'll assume no daniel then.
Dave
2) Minutes
Dave
Anyone from the floor?
Dave
Otherwise, I'll take Ge0rG up on the offer, then.
Dave
Ge0rG, That OK?
daniel
Sorry I'm here now
Ge0rG
Dave: sure
SamWhited
I'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.
Dave
SamWhited, That's true.
Dave
3) Outstanding Votes
Dave
daniel, I'm missing one from you on the Client Key Support ProtoXEP, I think.
daniel
I'm +1 on that
daniel
Unless you want me to write that on list
Dave
daniel, No, here is fine. And you're voting -1 on TOTP 2FA? (You said "inclined to" on the list)
daniel
No I'm +1 on that as well
Dave
Kev, My understanding is you're witholding your vote on '387 until that's been resolved?
Kev
My original vote was +1 pending the merging of the PR.
Kev
In an ideal world I'd like to stick to that.
Ge0rG
Do we need to vote on making jonasw the new author?
Dave
Kev, 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.
Kev
Ge0rG: I don't think so, as long as Sam hasn't changed his mind about stepping down.
Dave
Ge0rG, I don't think so, but I'd like to be clear we're all happy with that, hence:
Kev
Ge0rG: 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.
Ge0rG
Jonas 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.
Dave
4) #576: XEP-0387: Add myself as author and move back to Proposed
Dave
Anyone object to this? (It's basically Jonas taking authoriship)
SamWhited
I'm fine with Jonas taking over
Kev
I've not reviewed, but if it's Jonas becoming Editor, I'm fine with it
Ge0rG
author, not editor
Dave
OK.
Kev
Don't pick on me, I'm ill :p
Ge0rG
just clarifying :)
Ge0rG
+1 to #576
Kev
But yes, Author.
Dave
I hear no objections, anyway.
Kev
FWIW, I think Council should (not today) try to reach a consensus on advice to Jonas for what these should be going forward.
Kev
I quite like my idea of explicitly splitting between "Best we have" and "State of the network".
Dave
Kev, "These"?
Dave
Kev, Oh, Compliance Suites.
Kev
These = Compliance suites that may or may not really be compliance suites.
Dave
Kev, Yeah. I think it might be an amusing hour's chat at the Summit, actually.
Kev
I 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)
Kev
But also I think it's important we don't discourage new implementors who want interop by not representing the backwards-compat needed.
Kev
So being explicit about both sounds ideal to me.
Ge0rG
Are we voting on #576?
Dave
Ge0rG, 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.
Dave
5) #559: XEP-0045: Specify 333 stats code
Ge0rG
+1
Dave
https://github.com/xsf/xeps/pull/559 if you prefer.
jonasw
okay
jonasw
I’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)
Dave
I 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.
Ge0rG
jonasw: yes, you can merge that PR.
Kev
Haha, what a well-worded MAY MUST.
Ge0rG
In 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
Dave
jonasw, I'll give you a massive list of stuff to do as Editor in a bit, too. :-)
Ge0rG
IIRC everybody else has voted +1 for the PR-merged version already.
jonasw
Dave, \o/
Dave
Ge0rG, One thing at a time, please.
jonasw
I like lists
Dave
daniel, SamWhited - #559?
jonasw
Kev, 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
jonasw
shall I clarify that in the text?
Kev
jonasw: I think it's fine.
Dave
jonasw, It's fine.
jonasw
okay
daniel
Dave: 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
Dave
daniel, I'm not sure I understand what the compliance suites have to do with #559.
SamWhited
Yah, I think I'm confused about what agenda item we're on too
daniel
Sorry. We are talking about too many topics at once
jonasw
I’ll stop my source of confusion and hop onto my train, sorry :)
daniel
Let me look up that pr
Kev
https://github.com/xsf/xeps/pull/559
Ge0rG
Somebody mixed in the future of Compliance Suite into agenda item 4.
daniel
Yes I'm +1
SamWhited
I'm on list for #559; I'm tentatively -1 to adding anything to MUC, but need time to digest the PR.
Dave
OK.
Dave
That'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.
SamWhited
I'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.
Dave
In 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?
Kev
I'd rather not, as I don't think it's a good use of the summit time, really.
Kev
Everyone 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
SamWhited
After the summit at the pub then; "in person" being the important part
Ge0rG
Feel free to meet in person at the summit, or not.
daniel
> +2w, I suggest.
+1
Kev
There are things Council should discuss soon, including compliance suites, and I'm fine with doing that, but I wouldn't have a Meeting.
Dave
OK. 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)
Dave
Ge0rG, Boo.
Ge0rGcan't even promise remote attendance.
SouL
Ge0rG, sad!
SamWhited
I would specifically like it to be a meeting; I think it helps focus everyone if it's "official" in some sense and in person.
Kev
I don't think it'd be possible for me to *be* more focussed during the summit than I usually am :)
Ge0rG
Dave: 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.
daniel
If 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
Dave
OK. We'll go for +2w, then.
Ge0rG
+2W WFM
Dave
So, back to AOB.
Ge0rG
I'd like to get a vote on 387 with #569 applied.
Ge0rG
This is Kev's feedback in https://github.com/xsf/xeps/pull/569
Dave
Ge0rG, So would I, but daniel asked for this to be after we've discussed the nature and purpose of the XEP.
Ge0rG
Dave: ah, that was the out-of-context -1 I wasn't able to associate.
Dave
SamWhited, You want to talk about XHTML-IM? I'm (still) happy to deprecate it.
Kev
I remain not sold on deprecating it, but I'm not intending to block it happening.
SamWhited
RE 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.
Dave
SamWhited, Otherwise I'll just stick it on the agenda for next meeting.
SamWhited
If there are any other concerns I'll try to address them, otherwise I think we should hold a vote again.
Dave
If I held a vote now, are people ready? Otherwise I'll just do it next meeting.
Kev
I think it'd be better for people to have a chance to revisit the discussion before voting.
Kev
I 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.
Ge0rG
I think XHTML-IM is not really replaced by either "alternative".
Dave
On 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.
Dave
Kev, Yeah, I'll go along with that logic too.
Kev
So I suggest we just vote in +2w (when I will then probably have to onlist regardless, so I'm low-F)
Dave
Right, I'm doing that. SamWhited, you can spend the next two weeks convincing Ge0rG. :-)
Ge0rG
Re 387, can we please just get it published now and postpone the structural redesign for 2019?
Ge0rG
daniel: ping?
Dave
daniel, You are, I think, the only one expressing the opposing viewpoint to Ge0rG, so this is your call really.
daniel
Ge0rG: I don't want to block it all cost. But I prefer we'd talk about it next week at the summit
Ge0rG
daniel: it's a month overdue already, and next Council meeting is in +2W.
daniel
Note that I did give my +1 to the as is version
Ge0rG
daniel: and if there is feedback (and there will be!), we are talking about more iterations
daniel
If you want to publish it at all cost just publish that
Ge0rG
daniel: note that I asked for voting, now, on the version with Kev's feedback included
Ge0rG
I'm pretty sure everybody had sufficient time and opportunity to review both the current and the changed versions.
daniel
Yes I know. I was trying to give you another option if you are desperate to get it out of the door
Dave
So OK. Let's do a specific vote on XEP-387 with Kev's PR merged:
Dave
I'm +1
Kev
+1, natch
Ge0rG
+1 (as stated last week and the week before)
ralphmhas joined
Ge0rG
SamWhited, daniel?
ralphmhas joined
Dave
daniel, 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.
Dave
pfft. "on list", I mean.
Ge0rG
daniel: I can't publish the pre-PR version because it's -1ed by Kev.
daniel
On list then
Dave
SamWhited, ?
SamWhited
I'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.
Dave
SamWhited, OK, thanks.
Dave
Any Other Any Other Business?
Ge0rG
I'd like to propose all council members to read Kafka's The Trial until next meeting.
Dave
Seconded.
Dave
Anythign else?
Kev
*until*?
Kev
That's a lot of reading
Kev
And no, nothing from me.
Dave
Then I think we're done. Ite, meeting est - thanks all.
SamWhited
Thanks all!
Ge0rG
thanks :)
SamWhited
Ge0rG: 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.
Kev
Thanks all.
Ge0rG
SamWhited: I'm not going to veto deprecation, I'm just not convinced that what we have as alternatives is a 100% replacement.
SamWhited
Ge0rG: I agree with that; it's not a 100% replacement.
Dave
Ge0rG, 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.
Ge0rG
Dave: yes, Styling is an 80% solution, and a really awesome one (I can say that because I shamelessly stole Daniel's code)
ralphmhas left
Dave
Ge0rG, 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.
Ge0rG
Maybe I can get consistent source code highlighting by using Styling with ```<language-tag>
Dave
Ge0rG, A bit niche, I feel.
SamWhited
Ge0rG: 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.
Kev
Optional?
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
Ge0rG
SamWhited: I don't think that specifying the first line as "optional source code identifier" adds complexity
SamWhited
Optional is a nice way of saying "unreliable".
Kev
pep.: They're publishing source snippets in particular languages?
Dave
SamWhited, 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
Dave
Kev, Different issue. They're dumping complex bits of XHTML into pubsub items.
Kev
SamWhited: As long as the fallback behaviour is clear and sensible, that's probably ok.
SamWhited
Dave: Oh yah, I was thinking it would just be a way to say "this is a language".
Kev
Dave: Yes, but I thought your comment about 'niche' was the source code rendering?
SamWhited
Not specific coloring or formatting
Kev
Or I completely misread the order of messages.
Kev
SamWhited: Well, mandatory then, works for me :)
Ge0rG
I 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
SamWhited
Maybe 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)
Ge0rG
The 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++"?
SamWhited
If clients want to make a separate spec that say to use values from pygmetized's registry, they can do that.
Ge0rG
SamWhited: 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
Dave
pep., 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.
SamWhited
Ge0rG: fair, maybe it still shows up as a title or something.
Ge0rG
SamWhited: just say it's a language tag without strict enforcement.
pep.
Dave, ok. You'd rather see W3C XHTML in there?
SamWhited
I 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.)
Kev
Countdown until someone puts CSS in it. 3...2...
Dave
pep., 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.
Ge0rG
SamWhited: "a short tag intended for improved syntax highlighting of the following block"
Zashhas left
SamWhited
Ge0rG: 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
Dave
pep., 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.
Ge0rG
SamWhited: this is the same argument I had against all of Styling.
SamWhited
Ge0rG: what do you mean? Right now I think it's very strictly specified to avoid that
Dave
SamWhited, 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.
Dave
pep., Doesn't edhelas's Atom contain XHTML?
SamWhited
Dave: I don't, not if we don't specify a common set.
Ge0rG
SamWhited: that the syntax will inevitably lead to incorrectly styled messages for path names or other nerdy things.
Kev
I 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
Dave
SamWhited, 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.
SamWhited
Dave: I disagree; if some Java syntax highlighting library expects c++ and the python one expects cpp I suspect each client will just do that.
Dave
pep., That would be my point. Goffi uses tables and things which aren't in XHTML-IM, too.
Ge0rG
We could introduce our own registry of language names!
SamWhited
Ge0rG: now we're back to my ponint of "is all the additional complexity worth it?"
Dave
SamWhited, That's a possibility. But I think those libraries might well have stabilized themselves anyway.
Ge0rG
SamWhited: or maybe the Java and python libraries will be PR'ed against to support the respective other name
Ge0rG
SamWhited: </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).
Dave
pep., Ah, OK.
Dave
pep., 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.
Ge0rG
SamWhited: I think the right level of detail is to say that it's a short language tag without further defining the expected content
SamWhited
I 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
SamWhited
Again, 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"
Ge0rG
SamWhited: if we don't call it a "language tag" but a "syntax highlighting hint", it might be usable for coloring non-languages as well
Ge0rG
Though techically, I suppose, everything you want colored in a blockquote is a language
Ge0rG
SamWhited: 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
Ge0rG
Let'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
Dave
pep., Ah. So *that* needs fixing.
inkeyhas joined
vanitasvitaehas left
Dave
https://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.