https://logs.xmpp.org/council/2021-02-17?p=h#2021-02-17-a7279024de1951f7
1) Roll Call Present: Daniel, Georg, Zash, Jonas, Dave 2) Agenda Bashing There are no complaints. 3) Editor's Update Nothing to report. 4) Items for voting None. 5) Pending Votes Dave votes on PR #1032: +1 (doing otherwise will break several implementations, including anything based on Smack; think this is the original intent [of XEP-0004] and early implementations appear to follow it.) Georg hasn't yet caught up on the really long thread. Zash thinks the thread appears to have a rough consensus, and votes +1. Jonas says that the behaviour of aioxmpp on the client side matches what Drew described [1] - Dave doesn't think reordering matters much when consuming, but does when producing, and seems entirely wrong when forwarding - Jonas agrees that forwarding shouldn't reorder things. Kev doesn't think breaking Smack is a motivation to do things, but that creating headers after their content is probably broken, and hopes any forwarding entity which changes the order is only used within a closed deployment. Daniel doesn't see how the existing text intended for 'reported' to come first, nor why it's desirable - Jonas agrees - Kev thinks it seems like the Right Thing, but even though it doesn't appear the original text necessarily mandated it, it's clear that was the intention (exemplified in §3.4 "…describing the data to follow") - Dave agrees that it's not very clear, but the intent is there. Georg verifies that the decision is to break implementations which don't follow this - Dave suggests the alternative would be to break implementations which do - Georg says they don't have an explicit right to rely on it, rather a vague implication. That said, Georg is okay with changing the vague implication to a formal requirement. Jonas is quite reluctant about the 'MUST' because this is Final (less issue if it were Draft or Experimental), and thinks this needs a good rationale and text content explaining the change - Georg suggests adding a note about earlier versions of the XEP not strictly mandating order. Dave would be okay with a 'SHOULD', though aioxmpp and ejabberd would still need to be fixed. Georg votes: -1 (as-is, with the MUST; +1 for a MUST with explanatory textbox, or just a SHOULD.) Daniel could be on board with a SHOULD, since this shouldn't be a big deal in practice (ignoring those who need to fix their code) - Dave asks why a SHOULD is preferred here - Daniel feels it's less bad when changing a Final XEP. Georg proposes some text to go in a box. Dave thinks the standards list should be consulted - Jonas considers the addition of a box as editorial - Dave says that means Council don't get to vote, not that the community is bypassed. Kev thinks that adding a box is editorial, but adding text about implementations and encouraging behaviour certainly isn't (even if that happens to be inside a box.) Jonas will put it to the list, but doesn't see the necessity given that this PR wouldn't have been discussed there otherwise - Dave thinks that's a problem in itself, and prepares a can of worms for AOB. Zash can't handle any worms today. Jonas pushes a patch onto the PR, and plans to vote on the updated version next week after possible list feedback [2]. Jonas votes once again: -1 (the new diff looks better considering the current state of the world.) 6) Date of Next 2021-02-24 1600 UTC 7) AOB Dave notes that the Data Forms discussion on-list was very useful, but only started once voting had already begun, which feels awkward; it would be better to discuss things first, and only add them to the agenda once they have been discussed, so Council can just vote - Jonas agrees. Jonas thinks it would be great if some CI magic could be used to automate announcements of PRs tagged with 'Needs List Discussion' and 'Needs Council'. Dave suggests advising that things don't get added to the agenda until after somebody starts the discussion on-list - Jonas doesn't see any significant issue with that; Zash approves of subverting the GitHub flow. Jonas continues to fantasize about automation, but likes Dave's proposal as a first iteration. Dave admits that it pushes extra work onto the submitter, but encourages them to add some rationale and convince people. Daniel is somewhat fine with the current flow (Council gets to decide on uncontroversial things and refers others back to the list), but is also fine with this new suggestion - Dave doesn't think Council deciding what is actually controversial is optimal, given potential bias and the lack of an appeals process. Jonas prepares an email explaining the proposed change [3]. 8) Close Thanks Jonas, Tedd, All, Sundry. Dave apologises for his contribution to the meeting overrun - Jonas thanks Dave for the neat idea. [1] https://mail.jabber.org/pipermail/standards/2021-February/038175.html [2] https://mail.jabber.org/pipermail/standards/2021-February/038183.html [3] https://mail.jabber.org/pipermail/standards/2021-February/038185.html
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
