> On 20 Dec 2018, at 20:27, Tedd Sterr <[email protected]> wrote:
>
> http://logs.xmpp.org/council/2018-12-19/#16:00:41
> <http://logs.xmpp.org/council/2018-12-19/#16:00:41>
>
> 1) Who's Here?
> Present: Jonas, Georg, Dave, Link
> Fashionably late: Kev
(I did send tentative apologies in case I didn’t make it).
> 2) Last Call: XEP-0410 (MUC Self-Ping (Schrödinger's Chat)) -
> https://xmpp.org/extensions/xep-0410.html
> <https://xmpp.org/extensions/xep-0410.html>
> Georg: +1 (obviously)
> Link: +1 (been testing an implementation and it did improve things greatly
> over the current status quo)
> Dave: +1
> Jonas: +1
> Kev: [pending]
-0. No objection to LCing it, but there’s sections not yet filled in, so it
can’t advance as-is.
> 3) Outstanding Votes
> Everyone but Dave owes a vote on Proposed XMPP Extension: Simple Buttons -
> https://xmpp.org/extensions/inbox/buttons.html
> <https://xmpp.org/extensions/inbox/buttons.html>.
With three 0s this can’t pass anyway, but I’m -1ing for the moment for the
reasons in the earlier minutes - I think this is going to end up reinventing
xep4, so I’d rather see it couched in those terms. If there’s a reason xep4
doesn’t work for this, I’d like to understand it first (and would then remove
the -1).
> Georg is still on-list; Jonas is going to read through the arguments and vote
> on-list.
>
> 4) AOB
> Jonas is going to delay re-issuing the LCs from previous Council until next
> year, as it would be a wasted effort to do so now.
>
> Dave noticed that Jonas pushed through XEP-0412 (XMPP Compliance Suites 2019)
> before all votes have been made, and has literally no idea what do to about
> it as there is no process to handle a process violation. Jonas suggests
> reverting the changes in Git; Georg suggests pretending it never happened
> unless the final vote contradicts, and revert if so. Dave thinks reverting
> would be a bad idea as it could lead to 0412 referring to a different XEP.
I don’t really want to be the blocker of progress, but there are various things
in here that I’m not convinced by. Some of them (368) were existing things that
I don’t feel are really essential in a core client/server, or are inconsistent
(84 but not 163 in a server), others are new (what does it mean for 184 to be
supported by a server? 398 is neat, but does it deserve to be in a compliance
suite already?). I’m also not sure that 7622 is actually practically required
for interop, as opposed to 6122, and a note to that effect would be sane.
I’ll put a -0 here so that Jonas can republish it if he feels strongly he wants
to without addressing these, given the rest of Council are +1, but I would feel
much happier if at least the inconsistency in 84/163 was addressed (although
not new this year), and 184 wasn’t required by a server (unless I’m being dense
and it really is required). 398 I’ll live with seeing in there, although I’m
not sure it’s justified (same for 368). Do with 7622 as you will.
/K
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
