https://logs.xmpp.org/council/2020-09-30?p=h#2020-09-30-cf8965073e57ee39
1) Roll Call Present: Zash, Daniel, Dave, Jonas Apologies: Georg 2) Agenda Bashing None. 3) Editor's Update * New ProtoXEP: Compliance Suites 2021 * LC for XEP-0411 extended until 2020-10-14 after the original extension got lost in the void 4a) PR #986 (XEP-0277: pubsub#type MUST be set in bare PubSub) Zash points out that Daniel pointed out that XEP-0277 is Deferred, so there's no need to vote on this; Jonas agrees and moves this to AOB, as the author asked for guidance. 4b) PR #988 (XEP-0060: Add integer-or-max datatype to use with Data Forms Validation) - https://github.com/xsf/xeps/pull/988 Daniel is happy to accept this unless somebody really wants to put it somewhere outside of XEP-0060, but isn't sure if XEP-0122 (Data Forms Validation) would be a better option - Jonas doesn't think it would be. The other option would be a new XEP, but Jonas and Daniel believe that to be overkill. The author, Pep, did consider a new XEP just to define the type, and then to edit XEP-0060 to use it. Pep thinks 0060 needs to be edited either way because meaning must be given to the type for each field using it - Dave thinks that seems right, so the registration may as well be in there too. Zash wonders whether 'min' should be included too - the obvious assumption is this would be zero, if the type is unsigned - Pep confirms, unfortunately, the integer type is signed and infinite. Daniel can't think of a use case for 'min' and would rather not add something without an explicit use. Dave feels this is kind of detail-grinding that would be best done on the list; is fine with it not needing a 'min' (could be defined later if required.) Zash checks that 'max' implies whatever the actual maximum is, even if later reconfigured - Daniel confirms, and likes that about it. Zash: +1 (assuming the schema magic is sane; would be nice if the registry was working) Jonas: [on-list] (want to understand if that schema stuff is right first - gut feeling it isn't) Daniel: +1 Dave: +1 Georg: [on-list] 4c) Proposed XMPP Extension: Compliance Suites 2021 - https://xmpp.org/extensions/inbox/cs-2021.html Jonas: +1 Daniel: +1 Dave: +1 Zash: +1 Georg: +1 5) Pending Votes There are a few remaining votes on PR #983, though it has been vetoed already; the author has since agreed with Council's alternative suggestion anyway. 6) Date of Next 2020-10-07 1500 UTC 7a) AOB i: PR #986 (XEP-0277: pubsub#type MUST be set in bare PubSub) - https://github.com/xsf/xeps/pull/986 Jonas still needs to read more into this, but maybe somebody else has an opinion; Zash's opinion is that this is good. It seems good to Daniel, but he isn't an expert on microblogging. Dave feels it should be a SHOULD, rather than a MUST, but would be curious what the authors of XEP-0277 (Microblogging over XMPP) have to say. The authors of Movim and Salut à Toi appear to approve. Zash notes the #type field isn't particularly well defined - Pep, the author, notes that only 'payload type' is normative, and everything else appears in an example. Jonas queries the benefit of using pubsub#type - Pep says there might be multiple nodes using microblog on the same component; suggestions this might be used for filtering, or showing a pubsub node directory. Daniel expects a SHOULD should be fine - Pep feels this change is useless without a MUST the moment something else makes use of atom in pubsub. Dave still feels it's a SHOULD, but if the experts think that would harm interoperability then MUST it is. Jonas suggests delegating this decision to the authors of XEP-0277. 7b) AOB ii: XEP-0393 (Message Styling) - https://xmpp.org/extensions/xep-0393.html Jonas notes that this did not advance, and the author, Sam, disagrees with Council. Dave asks whether Sam was an outlier, and did the community feel that Council's proposal was reasonable - Jonas is unclear, but there was a lot of discussion, which he was unable to read through; this has been hanging in LC for a while, and it would be preferable to sort it out before next Council's term. Dave says our documents are meant to match the group consensus (both Council and Community), so if Sam is in the minority there's not much else to do, but if there's no consensus on a way forward then that's not much help. Daniel requests a link to the thread - Jonas obliges [1] - Daniel doesn't recall there was a clear community consensus; some hate the XEP for not being XHTML-IM, but it's also not meant to be; Daniel wouldn't vote to reject it. Kev feels there were some sensible suggestions around opt-ins to improve this as a less-than-perfect solution to an impossible problem, which should be given serious thought. Daniel thinks such changes, if desirable, could be made by taking over the XEP instead of rejecting it. Pep would prefer that 0393 were given concrete shoes and taken for a diving lesson in the Seine. Jonas thinks the best way forward is for Council to read through the thread and try to extract some average of the consensus to act on. Jonas will construct a multitude of votes for next week, around moving the XEP to Informational, taking ownership, and accepting or rejecting it. Kev thinks the addition of 'unstyled' improves things significantly - Daniel agrees. Kev thinks there is still a strong argument for indicating when something is marked-up, not so much for opt-in as for knowing the mark-up is present, that it is (intentional) mark-up, and allowing it to be stripped; also, it wouldn't be bad to announce that it's marked-up. 8) Close Thanks everyone. Discussion of Message Styling rages on… [1] https://mail.jabber.org/pipermail/standards/2020-June/037496.html
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
