XMPP Council - 2018-01-24

council meeting is at 1600Z?

Sounds about right. I admit I've become completely reliant on the minutes-in-advance already.

minutes-in-advance?

Agenda in advance.

ah

that makes sense :)

I'm ill, don't pick on me :p

I won’t, I promise

also, get well soon

Ta. Only a cold, but it's getting old.

ancient colds are the worst; today’s immune systems just aren’t used to it anymore ;)

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.

Dave: if you finish them until 1600Z, you can just paste them and we are done in time.

Ge0rG, Yeah, but doing them 24 hours ahead (as was my intent) means Council folks are hopefully able to vote in the meeting.

Wait, I said minutes too. I meant Agenda, if that wasn't clear.

Speaking of minutes, anyone want to do those this week?

Dave: I can do them if there are no voices from the floor.

Or... from the peanut gallery.

Ge0rG, Thanks, but I'm hoping one of the many people here can take them on...

I'm sitting in a train and it's rather calm. I really hope there is no reservation for my seat, though.

Here.

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.

And yes.

'tis time.

1) Role Call:

o/

I'll assume Kev and Ge0rG are here. daniel ?

I'll assume no daniel then.

2) Minutes

Anyone from the floor?

Otherwise, I'll take Ge0rG up on the offer, then.

Ge0rG, That OK?

Sorry I'm here now

Dave: sure

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.

SamWhited, That's true.

3) Outstanding Votes

daniel, I'm missing one from you on the Client Key Support ProtoXEP, I think.

I'm +1 on that

Unless you want me to write that on list

daniel, No, here is fine. And you're voting -1 on TOTP 2FA? (You said "inclined to" on the list)

No I'm +1 on that as well

Kev, My understanding is you're witholding your vote on '387 until that's been resolved?

My original vote was +1 pending the merging of the PR.

In an ideal world I'd like to stick to that.

Do we need to vote on making jonasw the new author?

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.

Ge0rG: I don't think so, as long as Sam hasn't changed his mind about stepping down.

Ge0rG, I don't think so, but I'd like to be clear we're all happy with that, hence:

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.

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.

4) #576: XEP-0387: Add myself as author and move back to Proposed

Anyone object to this? (It's basically Jonas taking authoriship)

I'm fine with Jonas taking over

I've not reviewed, but if it's Jonas becoming Editor, I'm fine with it

author, not editor

OK.

Don't pick on me, I'm ill :p

just clarifying :)

+1 to #576

But yes, Author.

I hear no objections, anyway.

FWIW, I think Council should (not today) try to reach a consensus on advice to Jonas for what these should be going forward.

I quite like my idea of explicitly splitting between "Best we have" and "State of the network".

Kev, "These"?

Kev, Oh, Compliance Suites.

These = Compliance suites that may or may not really be compliance suites.

Kev, Yeah. I think it might be an amusing hour's chat at the Summit, actually.

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.

(Daniel's, I think)

But also I think it's important we don't discourage new implementors who want interop by not representing the backwards-compat needed.

So being explicit about both sounds ideal to me.

Are we voting on #576?

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.

5) #559: XEP-0045: Specify 333 stats code

+1

https://github.com/xsf/xeps/pull/559 if you prefer.

okay

I’ll merge my authorship for XEP-0387; shall I merge Kevs PR while I’m at it and move it to draft, too?

(sorry, I’m a bit late, I was busy with work stuff)

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.

jonasw: yes, you can merge that PR.

Haha, what a well-worded MAY MUST.

In that case, we are missing Sam's voice (as Council member) for the post-PR 387.

+1. I don't think it's harmful, although I think it's really a Kick.

jonasw, I'll give you a massive list of stuff to do as Editor in a bit, too. :-)

IIRC everybody else has voted +1 for the PR-merged version already.

Dave, \o/

Ge0rG, One thing at a time, please.

I like lists

daniel, SamWhited - #559?

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

shall I clarify that in the text?

jonasw: I think it's fine.

jonasw, It's fine.

okay

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

daniel, I'm not sure I understand what the compliance suites have to do with #559.

Yah, I think I'm confused about what agenda item we're on too

Sorry. We are talking about too many topics at once

I’ll stop my source of confusion and hop onto my train, sorry :)

Let me look up that pr

https://github.com/xsf/xeps/pull/559

Somebody mixed in the future of Compliance Suite into agenda item 4.

Yes I'm +1

I'm on list for #559; I'm tentatively -1 to adding anything to MUC, but need time to digest the PR.

OK.

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.

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.

+2w, I suggest.

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?

I'd rather not, as I don't think it's a good use of the summit time, really.

Everyone not on Council is excluded (in practical terms), and we'll probably have many items to discuss.

> I'd rather not, as I don't think it's a good use of the summit time, really. +1

After the summit at the pub then; "in person" being the important part

Feel free to meet in person at the summit, or not.

> +2w, I suggest. +1

There are things Council should discuss soon, including compliance suites, and I'm fine with doing that, but I wouldn't have a Meeting.

OK. Are we all going to the summit?

(BTW, I won't be here for +2w, but I'll happily vote on list)

(Or, I might not be. I'll be on holiday anyway)

Ge0rG, Boo.

Ge0rG, sad!

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.

I don't think it'd be possible for me to *be* more focussed during the summit than I usually am :)

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.

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

OK. We'll go for +2w, then.

+2W WFM

So, back to AOB.

I'd like to get a vote on 387 with #569 applied.

This is Kev's feedback in https://github.com/xsf/xeps/pull/569

Ge0rG, So would I, but daniel asked for this to be after we've discussed the nature and purpose of the XEP.

Dave: ah, that was the out-of-context -1 I wasn't able to associate.

SamWhited, You want to talk about XHTML-IM? I'm (still) happy to deprecate it.

I remain not sold on deprecating it, but I'm not intending to block it happening.

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.

SamWhited, Otherwise I'll just stick it on the agenda for next meeting.

If there are any other concerns I'll try to address them, otherwise I think we should hold a vote again.

If I held a vote now, are people ready? Otherwise I'll just do it next meeting.

I think it'd be better for people to have a chance to revisit the discussion before voting.

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.

I think XHTML-IM is not really replaced by either "alternative".

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.

Kev, Yeah, I'll go along with that logic too.

So I suggest we just vote in +2w (when I will then probably have to onlist regardless, so I'm low-F)

Right, I'm doing that. SamWhited, you can spend the next two weeks convincing Ge0rG. :-)

Re 387, can we please just get it published now and postpone the structural redesign for 2019?

daniel: ping?

daniel, You are, I think, the only one expressing the opposing viewpoint to Ge0rG, so this is your call really.

Ge0rG: I don't want to block it all cost. But I prefer we'd talk about it next week at the summit

daniel: it's a month overdue already, and next Council meeting is in +2W.

Note that I did give my +1 to the as is version

daniel: and if there is feedback (and there will be!), we are talking about more iterations

If you want to publish it at all cost just publish that

daniel: note that I asked for voting, now, on the version with Kev's feedback included

I'm pretty sure everybody had sufficient time and opportunity to review both the current and the changed versions.

Yes I know. I was trying to give you another option if you are desperate to get it out of the door

So OK. Let's do a specific vote on XEP-387 with Kev's PR merged:

I'm +1

+1, natch

+1 (as stated last week and the week before)

SamWhited, daniel?

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.

pfft. "on list", I mean.

daniel: I can't publish the pre-PR version because it's -1ed by Kev.

On list then

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.

SamWhited, OK, thanks.

Any Other Any Other Business?

I'd like to propose all council members to read Kafka's The Trial until next meeting.

Seconded.

Anythign else?

*until*?

That's a lot of reading

And no, nothing from me.

Then I think we're done. Ite, meeting est - thanks all.

Thanks all!

thanks :)

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.

Thanks all.

SamWhited: I'm not going to veto deprecation, I'm just not convinced that what we have as alternatives is a 100% replacement.

Ge0rG: I agree with that; it's not a 100% replacement.

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.

Dave: yes, Styling is an 80% solution, and a really awesome one (I can say that because I shamelessly stole Daniel's code)

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.

Maybe I can get consistent source code highlighting by using Styling with ```<language-tag>

Ge0rG, A bit niche, I feel.

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.

Optional?

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)

By *that way* I mean pubsub and stuff

SamWhited: I don't think that specifying the first line as "optional source code identifier" adds complexity

Optional is a nice way of saying "unreliable".

pep.: They're publishing source snippets in particular languages?

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.

Kev, Different issue. They're dumping complex bits of XHTML into pubsub items.

SamWhited: As long as the fallback behaviour is clear and sensible, that's probably ok.

Dave: Oh yah, I was thinking it would just be a way to say "this is a language".

Dave: Yes, but I thought your comment about 'niche' was the source code rendering?

Not specific coloring or formatting

Or I completely misread the order of messages.

SamWhited: Well, mandatory then, works for me :)

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

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)

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++"?

If clients want to make a separate spec that say to use values from pygmetized's registry, they can do that.

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

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.

Ge0rG: fair, maybe it still shows up as a title or something.

SamWhited: just say it's a language tag without strict enforcement.

Dave, ok. You'd rather see W3C XHTML in there?

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.)

Countdown until someone puts CSS in it. 3...2...

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.

SamWhited: "a short tag intended for improved syntax highlighting of the following block"

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.

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.

SamWhited: this is the same argument I had against all of Styling.

Ge0rG: what do you mean? Right now I think it's very strictly specified to avoid that

SamWhited, You don't think a common set of tags would emerge?

Dave, actually only goffi uses xhtml-im, edhelas is using atom. I named both because they are both on the pubsub front.

pep., Doesn't edhelas's Atom contain XHTML?

Dave: I don't, not if we don't specify a common set.

SamWhited: that the syntax will inevitably lead to incorrectly styled messages for path names or other nerdy things.

I think the odds of a common list emerging organically are slim.

Dave, I don't remember, I don't use that feature myself, but that wouldn't be xhtml-im in any case

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.

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.

pep., That would be my point. Goffi uses tables and things which aren't in XHTML-IM, too.

We could introduce our own registry of language names!

Ge0rG: now we're back to my ponint of "is all the additional complexity worth it?"

SamWhited, That's a possibility. But I think those libraries might well have stabilized themselves anyway.

SamWhited: or maybe the Java and python libraries will be PR'ed against to support the respective other name

SamWhited: </s> just in case

Dave, I meant, edhelas wouldn't call it xhtml-im in the first place (whatever is in the atom node).

pep., Ah, OK.

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.

SamWhited: I think the right level of detail is to say that it's a short language tag without further defining the expected content

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

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"

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

Though techically, I suppose, everything you want colored in a blockquote is a language

SamWhited: I think that having an inconsistently used tag is a lesser interop problem than just defining it as something to be ignored

Dave, apparently 0277 recommends using XHTML-IM

Let's not drift away into the "undefined behavior" vs. "implementation-defined behavior" trap of modern C.

...of modern C *compilers*.

2.3.1

pep., Ah. So *that* needs fixing.

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.