jonas’you may voice your complaints throughout the meeting
jonas’3) Editor's Update
jonas’4) Items for Voting (or maybe also just discussion)
jonas’4a) Can we talk about XEP-0313 again?
ZashI guess we can
Ge0rGjonas’: is that a formal vote?
jonas’I think there was some discussion last night in xsf@
jonas’how do we want to move forward?
jonas’there was some positive feedback to Zashes proposal on list, but Kevs is simpler
jonas’and both seem to have similar drawbacks in the end (discoverability)
Ge0rGI was pressed into suppressing all but the most pressing issues I had about it.
ZashI'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.
Ge0rGI 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.
jonas’Ge0rG, pipe to /dev/null?
jonas’jokes aside, it seems that Kev has something specific in mind there and that it seems to work with "some clients".
jonas’It would be good to have that written down, but I don't see that as a blocking issue.
Zash(I can't actually block that, but still)
Ge0rGjonas’: 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
jonas’Ge0rG, well we can obviously not do that because above
Ge0rGjonas’: 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
danielI 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
ZashI remembered something I think Ge0rG said at some point about having profiles, with corresponding disco features
Ge0rGI'd rather break an experimental spec than cement something of the quality of GC1.0 into our spec.
ZashKevs PR does ... almost that
danielI haven't really been following the discussion on how to signal that because I don't really see it needs signaling in practice
danielIt's still good to have it in the protocol I guess...
Ge0rGdaniel: well, you don't see the problems because most server implementations ignored the advice and went on with what you consider as best practice
Ge0rGI'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.
ZashGe0rG, btw, we don't actually store top level attributes of <message> stanzas (I think we said we did), but 'with' and the timestamps are derived values, from the archiving itself.✎
ZashGe0rG, 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. ✏
Zashas are the ids extended mam adds
jonas’to me, the PR by Kev is sufficient
jonas’let's not make MAM another Message Archiving.
MattJLet's not indeed.
Ge0rGwell, it's the strictly minimal PR needed to get me away from -1.
Ge0rGit's far away from a PR that makes 0313 a good spec.
jonas’I'll instruct the editor to merge it then, unless anyone voices another complaint to me until the next merge window
ZashThe thing I suggested could be added later, if real need for it turns up
Zashas a separate XEP even, if it makes sense
Zashjonas’: Explicit lack of complaint. 🙂
jonas’4b) XEP-0280: Advance now with the fixes applied?
jonas’I merged and pushed the changes from Ge0rG yesterday.
jonas’unless there's anything we haven't addressed yet, let's vote on Advancing to Stable✎
jonas’unless there's anything we haven't addressed yet && have to address before advancing, let's vote on Advancing to Stable ✏
Zashgot a link to those changes?
jonas’I also extended them with a nice changelog entry
Ge0rGcan't we have another Last Call, for the sake of it? I'm going to miss the yearly 0280 LC otherwise.
jonas’+1 to advancing XEP-280, specifically NOT to dwd vetoing. ✏
dwdGe0rG, And would like to suibscribe to my newsletter?
Ge0rGAfter all those years of blocking 0280, this is a strange feeling.
dwdDrum roll, please!
dwd+1 to advance!
jonas’let's quickly move on before someone changes their mind
jonas’5) Pending Votes
jonas’everyone is pending on CS-2021
jonas’Zash, thanks :D
dwdIt's entirely possible we're pending on CS-2021 as well, mind.
ZashWhy not both!
jonas’let's not go there
Ge0rGI'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
jonas’there was some discussion about words
ZashIt _would_ have been nice to see more discussion
dwdAnyway, I did review CS-2022 carefully, and I noticed some things I find pretty weird.
jonas’dwd, is this the right venue or should we take it to the list?
dwdFor 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?
dwdI don't think this is helped by us not actually defining anywhere what "Core" vs "Advanced" actually mean.
jonas’aren't those just words to distinguish the two levels?
jonas’but defining goals would indeed be interesting
ZashRemember how there's a Core category too
dwdjonas’, Sure, but what do the levels even mean?
Ge0rG> 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.
Ge0rGAlso I don't think that "Core Core" is actually a problem because you can deduplicate those words.
jonas’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.
dwdGe0rG, 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.
Ge0rGwe could rename the levels to "Must", "Should" and "May"
dwdGe0rG, I did consider that, actually.
dwdAnyway, I wrote a screed on this to the mailing list.
jonas’(what to do with a SHOULD in a spec which is listed in Should?! 😁)
dwdBut you didn't see it because I looked at the draft and binned it.
dwdMostly because we'll never fix it before the end of the year.
Ge0rGdwd: there is always next year's CS.
jonas’so how do we proceed with the vote here?
jonas’does anyone want to cast this week?
jonas’otherwise I'd like to move on
dwdSo 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.
dwdHence, I'll +1 this.
jonas’dwd, that sounds like what I had in my head, so I like it ;)
Ge0rG+1 with a minor note/question/AOB about promoting XEP-0379, XEP-0401 and XEP-445 into Advanced IM.
ZashObservation: The diff is pretty small. https://xmpp.org/extensions/xep-0459.html#changes-2021
jonas’Ge0rG, I think you should bring that up on-list
dwdI 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.
Zashs/no/yes/ on 156
Zashdwd, that sounds like a grand idea
Ge0rGjonas’: what about issuing LCs on the three?
jonas’Ge0rG, might be worth a shot
daniel+1 to advance cs22
jonas’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?
jonas’Ge0rG, heh, okay
danielFwiw I'm against adding those xeps to the CS
Ge0rGjonas’: 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.
Ge0rGjonas’: I'm interested in shepherding 0401
jonas’Ge0rG, okay, thanks
Ge0rGdaniel: could you please explain?
jonas’daniel, Ge0rG, re inclusion in the CS, please take that to the list
jonas’it makes more sense to discuss this in the open
jonas’and in the corresponding thread
jonas’6) Date of Next
Zash+1 to cs2022 and let's make 2023 the best one ever
jonas’+1w wfm, unless we're in assembling-furniture-frenzy and I completely lose track of the time
jonas’(I'll hold my vote to give Ge0rG and daniel a chance to discuss the onboarding XEPs on-list)
Ge0rGjonas’: thanks very much!
jonas’7a) XEPs format
Zash`xmllint` all the things?
jonas’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.
jonas’I was wondering what your folks opinion on that would be, editor hat on.
ZashThe XML we have mixes tabs and spaces and have very long lines
jonas’with "that" being changing the official XEP language to markdown, from our custom XML schema.
ZashProperly formatted and indented XML is much nicer to edit
jonas’Zash, I prefer long lines for editing.
dwdI'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).
Ge0rGany text reflow mechanism will cause horrible PRs.
SamI 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
jonas’because of exactly what Ge0rG said
dwdI *am* keen on allowing people to write XEPs in Markdown and then convert them.
jonas’dwd, I hear you can have YAML headers on Markdown files
ZashI did make those markdown←→XEP XML tools, which are in the repo since some time.
jonas’the problem with the tools is that they'll bitrot if not used regularly
Ge0rGI 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.
jonas’I hear that word-diffing markdown is much easier than word-diffing rendered HTML
Ge0rGwhat about word-diffing XML?
jonas’Ge0rG, noisy, but probably easier than the rendered HTML ;)
Ge0rGjonas’: also is now a good time to remind you of markdown being a *superset* of HTML?
danielWouldn't we be loosing entities?
SamI think Dante wrote a whole book about doing that
jonas’daniel, that's a good point I hadn't thought of
jonas’okay, we're overrunning anyway
jonas’any other AOB? (looking at Ge0rG )
ZashThat's often an argument for reStructuredText or whatsitcalled, having macros or something
Ge0rGjonas’: I'm taking those to the list I think.
jonas’(reST would come with a non-terrible-hack-based PDF renderer, too.)
dwdAlso I do like having named anchors in XEPs for long-term reference.
Ge0rGAt least the XEP-0379 ones.
Ge0rGnot sure what else I wanted to rant about.
jonas’let's close then before you remember ;)
jonas’8) Ite Meeting Est
danielThanks everyone. Thanks jonas’
Kev> 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.
KevMaybe 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.
KevAnd 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.
Ge0rGKev: 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
Ge0rGdaniel: I've written my suggestion to include 0379++ to standards@, feel please reply on list :)✎
Ge0rGdaniel: I've written my suggestion to include 0379++ to standards@, please reply on list :) ✏
Ge0rGKev: and indeed, I agree with your assumption that it's a typo and that consensus was to merge your change
Ge0rG(also given that your change fixed two of the issues I had, and Zash only provided a suggestion for fixing one of them)
jonas’Kev, uhh, you're of course right.
KevI'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.
ZashI'm not sure what the conclusion is, it seemed to get more complicated the more I was thinking.
jonas’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.
jonas’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)
jonas’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.
KevI 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).
Ge0rGKev: the author or a shepherd needs to request the LC from editor
KevI'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'.
Ge0rGWell, 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.
ZashI suppose that compounds with the general versioning troubles we've had
Ge0rG§6 Discussion Process doesn't explicitly mention but kinda-sorta assumes that the author is responsible during "Experimental" and maybe "Deferred"
Zash.. but not while Proposed?
Ge0rGZash: the relevant part is in §8.1:
> Ultimate authority for Stable XEPs rests with the XMPP Council
Ge0rGso we do not have formal restrictions on the author during Proposed.
jonas’Kev, feedback noted, I'll communicate that better next time. Thanks!