[Standards] Council Minutes 2019-09-11

Tedd Sterr teddsterr at outlook.com
Wed Sep 18 15:16:38 UTC 2019


http://logs.xmpp.org/council/2019-09-11?p=h#2019-09-11-8afc1ce1dd4dff71

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

3a) Proposed XMPP Extension: Message Fastening - https://xmpp.org/extensions/inbox/fasten.html
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)
Kev: +0

3b) PR #822 - XEP-0280: negative Carbons example - https://github.com/xsf/xeps/pull/822
Georg: +1
Kev: +1
Dave: +1 (just adding an example)
Jonas: +1
Link: +1

Georg suggests one of the Brexiters could check the Shakespearean English.

3c) PR #820 - XEP-0280: remove error note, add XEP-0333 - https://github.com/xsf/xeps/pull/820
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 namespace bump.
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 so shortly.

5) Next Meeting
2019-09-18 1500 UTC

Kev won't be here next week.
Dave will endeavour to get an agenda sorted.

6) AOB
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 ball rolling).
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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20190918/7393f534/attachment.html>


More information about the Standards mailing list