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)
Kev: +0

3b) PR #822 - XEP-0280: negative Carbons example -
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 -
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.

Standards mailing list

Reply via email to