1) Roll Call
Present: Jonas, Link, Dave, Kev, Georg
2) Agenda Bashing
Dave didn't notice it was Wednesday and is sorry.
Kev nonchalantly mentions Fastening; Dave sees one announced proto-XEP and two
3a) Proposed XMPP Extension: Message Fastening -
Georg says this is clearly duplicating existing work and the author should
collaborate with the authors of Attaching (XEP-0367). Jonas also thinks it is
duplicating existing work, and finds the mailing list remarks on the lack of
examples to demonstrate how this helps with 'magic MAM' to be relevant; would
also like to see a practical motivation for '<external>'.
Dave asks for the distinction between this and XEP-0367 - the author explains
that last week Council decided they would prefer a new proto-XEP over updating
XEP-0367, but the major differences are the use of external, and content
replacement; but it would still fit into XEP-0367 if Council is happy with that.
Jonas thinks the lack of fastenings to fastenings seems like an unnecessary
restriction. Link only had time to skim through this, but agrees that seems
likes it would restrict future unknown use-cases, e.g. some kind of external
approval of a message edit - the author says this is deliberate: restrict now,
loosen later, rather than allow confusion over unanticipated unspecified
use-cases; Link points to XEP-0308 (Last Message Correction) as an example
where developers mostly ignored this kind of restriction.
Dave is basically fine with the document in isolation, but was under the
impression that XEP-0367 was unsuited to Reactions (and similar features), and
Fastening seems essentially similar, so wonders what this gains over 0367 - the
author explains this is the result of one of 0367's authors objecting to it
being used for Reactions; Georg thinks it is well suited for Reactions, with
some minor business rules changes. Jonas says the only thing making it
unsuitable was some strong opinions that Reactions are not Attachments.
Georg would be okay with burying XEP-0367 and moving Fastening to New Attaching
(with a new XEP number). Dave is all for publishing, but both this and XEP-0367
can't go to Draft.
Jnoas: +1 (we can develop this further in Experimental)
Georg: +1 (let's make some progress)
Dave: +1 (just to get progress)
Link: +1 (don't mind a new number and retract 0367, or merge into 0367)
3b) PR #822 - XEP-0280: negative Carbons example -
Dave: +1 (just adding an example)
Georg suggests one of the Brexiters could check the Shakespearean English.
3c) PR #820 - XEP-0280: remove error note, add XEP-0333 -
Dave asks why this is removing the error note - Link says it's important to
receive errors on multiple clients; the author says it was only a note and
doesn't want server authors to use that as an excuse not to implement it. Kev
believes the note is there because it's impractical for non-trivially-sized
deployments, also that this would need a namespace bump. Dave is fine with
moving the note, but not with entirely removing it (it's tricky, as Kev said).
The author doesn't believe it's impractical to implement, especially not in the
context of persisting message errors (on which Georg is still awaiting
feedback) - Kev repeats that it does require a namespace bump to indicate
support of these rules. Link suggest adding a feature to implementations which
do support it (bumping Carbons would be terrible). Dave agrees this does need a
The author could possibly change the text into "it contains payload elements
typically used in IM (e.g. &xep0184;, &xep0085;, &xep0333;)" but can't imagine
anyone would assume that's an exclusive list of all IM-related payloads - Kev
retorts that it's not possible to have a feature describing exactly which rules
are implemented. Jonas agrees with Kev, and suggests taking advantage of the
bump to also CC all error message instead of removing the note.
The author retracts the PR until somebody can come up with a conclusive list of
all IM-related payloads.
Kev doesn't think Jonas's suggestion would be feasible server-side, and wonders
about the effect it would have on clients. The author says CC-ing MUC(PM)
errors would wreak havoc - there is no conclusive list of possible error causes.
4) Outstanding Votes
Dave requests that Link votes on his two outstanding items - Link agrees to do
5) Next Meeting
2019-09-18 1500 UTC
Kev won't be here next week.
Dave will endeavour to get an agenda sorted.
Given the time, Dave hopes there is none; Georg still has the same ones as the
last three times - Dave will try to allocate time for these next week.
Dave votes on CS-2020: +1 (nothing we can't fix in Experimental, let's get the
Link votes +1 on both CS-2020 and PR #812.
Kev votes on CS-2020: +0 (don't see anything particularly wrong with it, other
than wanting to break the cycle of yearly compliance suites)
Link asks whether the much anticipated Compliance Suites Action Plan meeting
has taken place yet - Kev says not.
Georg mentions that Council re-election is soon, and that will likely mess up
Council's ability to Last Call an XEP - would like CS-2020 to be finished
before the end of 2019; Link would also like to make it more marketing oriented.
Jonas prompts for votes on PR #812, for merging convenience - Georg gives a +1.
Standards mailing list