https://logs.xmpp.org/council/2020-10-07?p=h#2020-10-07-a9f7d2f96141a999
1) Roll Call Present: Zash, Daniel, Georg, Jonas, Dave 2) Agenda Bashing Additions from Georg (MR #22) and Dave (Reactions). 3) Editor's Update * Accepted Compliance Suites 2021 - https://xmpp.org/extensions/xep-0443.html 4a) Advance XEP-0393 (Message Styling) - https://xmpp.org/extensions/xep-0393.html As a continuation from last week where Jonas had suggested Council try to extract a community consensus and decide how best to proceed, four potential polls were proposed. Jonas didn't make it too far into the depths of the thread, but would like to close this one way or another. Zash gathered that there was some agreement on adding an opt-out (and maybe an opt-in); the opt-out was added. Daniel's preference is either to accept as is, or to move to Informational (as is) - Jonas, Georg, and Zash agree. Jonas doesn't personally like it, but understands that it has value and it could be phased out eventually; Dave broadly agrees - there is lots of outlying opinion and no simple consensus. Jonas doesn't think it can be moved to Informational as it defines wire format. Daniel points out that the dependent ordering of votes on the agenda wouldn't really work out. Dave suggests voting to advance to Draft first, as everyone appears to be okay with that option - Jonas accepts, and throws away his carefully curated voting options. Dave: +1 Jonas: +0 Georg: +1 Zash: +0.999994 Daniel: +1 Dave is tempted to request a CFE next week. 4b) MR #22 (XEP-0308: modernize LMC sending) - https://gitlab.com/xsf/xeps/-/merge_requests/22 The author, Georg, notes there is a similar issue in XEP-0333 (though it's Deferred.) Dave asks for clarification on the point of the change - Kev and Georg explain that the current wording advises (non-normatively) against sending LMC without being entirely sure that all recipients understand it, and this change suggests sending regardless, but to warn the sender that the message may appear as a duplicate. Given the non-normative language, Kev believes there is sufficient wiggle room to allow this. Dave expects the suggested warning and a sending confirmation would be needed after every correction - Kev doesn't think it suggests a confirmation, merely that the user is made aware. Kev notes that Swift [1] already does this through a small message at the top during composing, informing the user the message might appear as a duplicate for some people, unless all are known to support it - Georg notes that feature is exactly what instigated this MR. Zash mutters something about UX considerations in XEPs. Kev notes that the text already suggests letting the user know, so the suggested warning isn't really new. Jonas thinks there is a key difference between the old text saying "it is expected clients do not send corrections to unsupporting clients" and the new text suggesting "go ahead, but maybe warn the user." Dave understands the intention, but the phrasing doesn't seem to convey the same intent - Georg tried really hard with the wording, but tried to keep as much as possible of the original wording intact, and isn't sure how to improve it. Various wordings are thrown back and forth. Jonas asks whether Georg can update the wording in time for the next meeting - Georg can manage this arduous task. Jonas retracts his original +1 in anticipation of voting on the newly improved wording. Daniel: [on-list] Georg: +1 Zash: +1 Jonas: [pending] Dave: +0 Kev: +1 (honorary, non-counting, LMC author vote) 4c) Proposed XMPP Extension: Reactions - https://xmpp.org/extensions/inbox/reactions.html Dave brought this up, there was a lot of discussion, and Kev doesn't expect Council to be bound to his -1 that had vetoed this originally (though his disagreements still stand.) Zash: +1 Jonas: +1 Daniel: +1 Dave: +1 Georg: +1 Jonas thinks this should go into Experimental so it can be experimented with, and then be strict about the details when moving to Draft - Zash agrees. Kev is 99% confident that's not what will happen, and it will become immovable. Dave thinks the general problem needs solving and doesn't want this going to Draft without doing so. Daniel thinks this is just one more on the pile for backwards things MAM-FC will have to handle - Dave thinks there is no interest in finding a consensus on solving this, and there's little point in MAM-FC if everything has to be retrofitted. 5) Date of next 2020-10-14 1500 UTC Jonas will prepare an agenda, but may find himself in a construction zone during next week's meeting - is sure someone will spontaneously chair if necessary. 6) AOB Tedd brought up a number of XEPs which have been stuck in Proposed - Jonas intends to add them for reconsideration. Daniel asks how everyone feels about moving XEP-0363 (HTTP File Upload) to Final - Jonas is all for it; Georg doesn't see any issues, but only has straight-forward deployments. Dave would prefer to get XEP-0066 (Out of Band Data) moved on; worries there isn't yet the experience for Final with 0363 without the other parts (if OOB is what people use to send the file URL.) Jonas thinks this discussion is getting out of hand. Daniel suggests adding it to next week's agenda. 8) Close Thanks everyone for everything! Daniel might be able to start that Compliance Suites A/V section next week, for which everyone (Georg, at least) has been holding their breath. [1] https://swift.im/
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
