XMPP Council - 2021-09-29

1) Roll Call

hi

🙄️

the look of dread

do we get a dwd?

well, we?

let's see ✏

2) Agenda Bashing

anything?

you may voice your complaints throughout the meeting

3) Editor's Update

nothing

4) Items for Voting (or maybe also just discussion)

4a) Can we talk about XEP-0313 again?

I guess we can

jonas’: is that a formal vote?

I think there was some discussion last night in xsf@

Ge0rG, no.

how do we want to move forward?

there was some positive feedback to Zashes proposal on list, but Kevs is simpler

and both seem to have similar drawbacks in the end (discoverability)

I was pressed into suppressing all but the most pressing issues I had about it.

I'm not going to block Kevs PR. It does have discovery and seems sane. My approach would need more thinking about discovery and seemed to add more complexity than what I could find time to think about since last week.

I still haven't received any answers regarding how a hypothetical client in the kev usecase is supposed to query for, display or process the groupchat logs from MAM.

Ge0rG, pipe to /dev/null?

jokes aside, it seems that Kev has something specific in mind there and that it seems to work with "some clients".

It would be good to have that written down, but I don't see that as a blocking issue.

(I can't actually block that, but still)

jonas’: in that case we can just remove the groupchat requirement from MAM and add a note about some servers delivering type=groupchat junk that shall be ignored

Ge0rG, well we can obviously not do that because above

Hello, sorry I'm late.

Ge0rG, so leave it at "MAY" ? ✏

jonas’: well, given that the use case is a handwavy "I want to be able to search through all my seen MUC logs" that is full of corner cases, I don't agree with that assessment

I don't see a lot of real world problems with groupchat in mam (before we have mix). The xep needs to allow it because it makes sense for some deployments but I don't think you will experience this in the normal public ecosystem

I remembered something I think Ge0rG said at some point about having profiles, with corresponding disco features

I'd rather break an experimental spec than cement something of the quality of GC1.0 into our spec.

Kevs PR does ... almost that

I haven't really been following the discussion on how to signal that because I don't really see it needs signaling in practice

It's still good to have it in the protocol I guess...

daniel: well, you don't see the problems because most server implementations ignored the advice and went on with what you consider as best practice

I'm not saying that it's wrong to ever store type=groupchat, I'm saying that it's wrong and harmful to store them by default and to return them to a standard query.

Ge0rG, btw, we don't actually query on* top level attributes of <message> stanzas (I think we said we did), but 'with' and the timestamps are derived values, from the archiving itself. ✏

as are the ids extended mam adds

to me, the PR by Kev is sufficient

let's not make MAM another Message Archiving.

Let's not indeed.

well, it's the strictly minimal PR needed to get me away from -1.

excellent

it's far away from a PR that makes 0313 a good spec.

I'll instruct the editor to merge it then, unless anyone voices another complaint to me until the next merge window

The thing I suggested could be added later, if real need for it turns up

as a separate XEP even, if it makes sense

jonas’: Explicit lack of complaint. 🙂

\o/

moving on

4b) XEP-0280: Advance now with the fixes applied?

I merged and pushed the changes from Ge0rG yesterday.

unless there's anything we haven't addressed yet && have to address before advancing, let's vote on Advancing to Stable ✏

got a link to those changes?

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

I also extended them with a nice changelog entry

can't we have another Last Call, for the sake of it? I'm going to miss the yearly 0280 LC otherwise.

Haha

Ge0rG, into your corner!

+1 to advance XEP-0280.

Ge0rG, I can veto it if you like.

+1

+1

dwd: I'm interested in your rationale

+1 to advancing XEP-280, specifically NOT to dwd vetoing. ✏

Ge0rG, And would like to suibscribe to my newsletter?

Anyway.

After all those years of blocking 0280, this is a strange feeling.

Drum roll, please!

🥁

+1 to advance!

🎉

let's quickly move on before someone changes their mind

🍾

😂

5) Pending Votes

ÄNTLIGEN

everyone is pending on CS-2021

jonas’: CS-2022?

yes

that

CS-Source?

Zash, thanks :D

It's entirely possible we're pending on CS-2021 as well, mind.

Why not both!

let's not go there

I've had a look at https://xmpp.org/extensions/xep-0459.html#future and I'd love to see XEP-379 and the associated XEPs become part of Advanced IM

there was some discussion about words

It _would_ have been nice to see more discussion

Anyway, I did review CS-2022 carefully, and I noticed some things I find pretty weird.

dwd, is this the right venue or should we take it to the list?

For one thing, we're saying that you can have a server that's "Core IM", but has no PEP, in 2022. Are there *any* servers that don't do PEP?

I don't think this is helped by us not actually defining anywhere what "Core" vs "Advanced" actually mean.

aren't those just words to distinguish the two levels?

but defining goals would indeed be interesting

Remember how there's a Core category too

jonas’, Sure, but what do the levels even mean?

> This document defines XMPP application Categories based on typical use cases (Core, Web, IM, Mobile) and Levels (Core, Advanced) based on functionality in the respective category.

Also I don't think that "Core Core" is actually a problem because you can deduplicate those words.

I don't think that the "what does advanced even mean" can be solved in a single council session, even though it seems like something council should have a stance on.

Ge0rG, Right, exactly. The levels are based on functionality. We decide what functionality belongs in what level based on, I dunno, functionality. Or level. I'm absolutely not blaming you for this, we should have dealt with this when we first came up with the levels.

we could rename the levels to "Must", "Should" and "May"

😀

Ge0rG, I did consider that, actually.

Anyway, I wrote a screed on this to the mailing list.

(what to do with a SHOULD in a spec which is listed in Should?! 😁)

But you didn't see it because I looked at the draft and binned it.

Mostly because we'll never fix it before the end of the year.

dwd: there is always next year's CS.

so how do we proceed with the vote here?

does anyone want to cast this week?

otherwise I'd like to move on

So instead, my proposal is that we accept this and publish it, and see if we can assemble a team (a SIG, maybe?) to figure out Compliance Suite policy for the next one.

Hence, I'll +1 this.

dwd, that sounds like what I had in my head, so I like it ;)

+1 with a minor note/question/AOB about promoting XEP-0379, XEP-0401 and XEP-445 into Advanced IM.

Observation: The diff is pretty small. https://xmpp.org/extensions/xep-0459.html#changes-2021

Ge0rG, I think you should bring that up on-list

I wouldn't mind our Executive Director discussing the idea of a Compliance Suite SIG with the Modern XMPP people, if he could get into contact with them.

s/no/yes/ on 156

dwd, that sounds like a grand idea

jonas’: what about issuing LCs on the three?

Ge0rG, might be worth a shot

+1 to advance cs22

Ge0rG, do you think you can get ahold of the author of '401 to figure out if they are interested in taking care of the document for the LC, and if they are not, would you shepherd?

daniel, thanks

Ge0rG, heh, okay

Fwiw I'm against adding those xeps to the CS

jonas’: I'm aware of two clients and one server implementation (not sure about ejabberd), and I'm pretty sure the spec is solid, as far as pre-login IQ hacks go.

jonas’: I'm interested in shepherding 0401

Ge0rG, okay, thanks

daniel: could you please explain?

daniel, Ge0rG, re inclusion in the CS, please take that to the list

it makes more sense to discuss this in the open

and in the corresponding thread

moving on

6) Date of Next

+1 to cs2022 and let's make 2023 the best one ever

+1w wfm, unless we're in assembling-furniture-frenzy and I completely lose track of the time

+1w wfm

(I'll hold my vote to give Ge0rG and daniel a chance to discuss the onboarding XEPs on-list)

+1W WFM

+1w wfm

+1WWWWWFM.

jonas’: thanks very much!

7) AOB

7a) XEPs format

`xmllint` all the things?

there has been the occasional feedback that it'd be nice to edit XEPs in markdown. the XML we use is also a really terrible example of how to use XML for documents IMO.

I was wondering what your folks opinion on that would be, editor hat on.

The XML we have mixes tabs and spaces and have very long lines

with "that" being changing the official XEP language to markdown, from our custom XML schema.

Properly formatted and indented XML is much nicer to edit

Zash, I prefer long lines for editing.

I'm not mad keen on Markdown for canonical specification work, especially as it's nice to be able to extract the metadata (even if we tend not to do that right now).

any text reflow mechanism will cause horrible PRs.

I have a formatter for XEPs somewhere that re-wraps lines to a configurable line length and re-tabs everything if the editors want it. I think it's left over (though it might have been rewritten since then too) from when I was an editor and we wanted to redo a few tools

because of exactly what Ge0rG said

I *am* keen on allowing people to write XEPs in Markdown and then convert them.

dwd, I hear you can have YAML headers on Markdown files

I did make those markdown←→XEP XML tools, which are in the repo since some time.

the problem with the tools is that they'll bitrot if not used regularly

I have no strong feelings about the tooling people want to use, as long as somebody provides a word-diff tool. We used to have that and it was very useful.

I hear that word-diffing markdown is much easier than word-diffing rendered HTML

what about word-diffing XML?

Ge0rG, noisy, but probably easier than the rendered HTML ;)

jonas’: also is now a good time to remind you of markdown being a *superset* of HTML?

Wouldn't we be loosing entities?

I think Dante wrote a whole book about doing that

daniel, that's a good point I hadn't thought of

okay, we're overrunning anyway

any other AOB? (looking at Ge0rG )

That's often an argument for reStructuredText or whatsitcalled, having macros or something

jonas’: I'm taking those to the list I think.

(reST would come with a non-terrible-hack-based PDF renderer, too.)

Also I do like having named anchors in XEPs for long-term reference.

Ge0rG, thanks!

At least the XEP-0379 ones.

not sure what else I wanted to rant about.

excellent

let's close then before you remember ;)

8) Ite Meeting Est

thanks everyone

good idea

thanks jonas’

Thanks everyone. Thanks jonas’

Thanks all

Thanks jonas’

> I'll instruct the editor to merge it then, unless anyone voices another complaint to me until the next merge window So, at the risk of being an arsehole, why does the Editor need an instruction to merge it? We have a process, which is that Authors have free reign to edit XEPs as they wish before Draft-as-was. In principal Council could potentially instruct the removal of an Author (although I'm not *sure* we ever codified that), but the Editor choosing not to merge a change is (almost?) unprecedented.

Maybe it was sensible in this case to hold off on the change, and maybe 313 is odd because of the Matt/Kev tag-team, but to be honest as the author submitting the change here the fact that it's being repeatedly suggested that I have to justify why I should be allowed to make edits to the XEP is starting to grate a little.

And the minutes saying that the Editor is intending merging Zash's change (which I don't think has been PRd yet) rather than mine is I *think* a typo, but didn't help my mood as I read that before reading the log here.

Kev: I think there is this weird limbo after issuing a Last Call and before the actual advancement takes place, where changing the XEP can lead to Council Confusion

daniel: I've written my suggestion to include 0379++ to standards@, please reply on list :) ✏

Kev: and indeed, I agree with your assumption that it's a typo and that consensus was to merge your change

(also given that your change fixed two of the issues I had, and Zash only provided a suggestion for fixing one of them)

Kev, uhh, you're of course right.

I'm not even that precious about my change, and maybe there's a better one to be made (although I don't think Zash's works very well once you follow it through to conclusion), I'm just feeling frustrated that we're not applying our usual process to the change.

I'm not sure what the conclusion is, it seemed to get more complicated the more I was thinking.

I (editor hat) treated this specially because '313 is currently undergoing the scrutiny of the last call process. It was a direct consequence of LC feedback from at least one council member, so to me (editor hat) it made sense to postpone applying this to keep the workload for me (editor hat) lower. Otherwise, I was running at risk of applying a change which would be modified just a week later when a council member decides to veto advancement because of disagreement.

If you think I could've handled this better, please let me know. I didn't mean to offend you in any way (by "picking" on your change). I'd have treated this the same for any change to a XEP under LC (we did the same for a change to 280, effectively)

It might've been handled differently if I wasn't editor and council chair in the same person, mind. It allows me (editor) to really quickly sync a "plan" with me (council) to get things done in the most efficient manner (for me) possible. If we had more editors, it might also have gone differently because as you say, the process is rather clear on that you could've just applied that change without any confirmation (so another editor might've done that). And it wouldn't even have been bad that way, because the load is spread. I'm currently trying to keep the load for the editor low, because it's enough work as it stands.

I think if our SOP is that once a LC is issued, Authors can't make changes to the XEP without Council approval, I think we should change our documents to reflect that (and *maybe* that's not a bad change), and also ensure that an LC can't happen without the Authors agreeing (I can't remember what the current state of LC issuing is, TBH).

Kev: the author or a shepherd needs to request the LC from editor

I'm aware the Editor is spread thin, and I don't want to shit on the people actually doing the volunteer work for the XSF in this or other cases, to whom I'm grateful, nor make this a personal attack. I do think that if a PR that an Author is allowed to make isn't being merged, that unless we change process so they're not automatically allowed to make it, it would be useful for the Editor to explain why they would like to not merge it, and get the Author to agree. TBH, If asked "Can we hold off merging this for review so we don't have to issue two changes back to back?" on the PR, I *imagine* I'd have said 'fine'.

Well, https://xmpp.org/extensions/xep-0001.html#proposal states that the "Editor shall formally propose *a specific revision of the XEP*" (emphasis mine), so this is not quite reflecting our current process.

I suppose that compounds with the general versioning troubles we've had

§6 Discussion Process doesn't explicitly mention but kinda-sorta assumes that the author is responsible during "Experimental" and maybe "Deferred"

.. but not while Proposed?

Zash: the relevant part is in §8.1: > Ultimate authority for Stable XEPs rests with the XMPP Council

so we do not have formal restrictions on the author during Proposed.

Kev, feedback noted, I'll communicate that better next time. Thanks!