https://logs.xmpp.org/council/2022-02-16?p=h#2022-02-16-be3c28ae5ed36ed4
1) Roll Call Present: Travis, Georg, Daniel, Jonas, Larma 2) Agenda Bashing Jonas checks whether Larma got any reply regarding taking ownership of XEP-0272 (Multiparty Jingle (Muji)) - Larma hasn't yet posted to the Standards List, as was agreed last week. 3) Editor's Update * Updated XEP-0004 (Data Forms) * Updated XEP-0060 (Publish-Subscribe) * Proposed XMPP Extension: MUC Affiliations Versioning 4a) PR #1158 (Obsolete XEP-0156 and add warnings) - https://github.com/xsf/xeps/pull/1158 Daniel checks that this will essentially make BOSH obsolete as it would no longer be discoverable - the author, Travis, notes that it does remove BOSH, but he also has an alternative proposal to remove everything else, while adding BOSH. Travis: +0 (this removes bosh, so my alternate proposal is remove everything else but adding bosh) Jonas: -1 (we should keep BOSH discoverable) Georg: -1 (because of BOSH) Daniel: -1 (i'm on board with getting rid of dns and getting rid of http, but i do think we need to keep bosh) Larma: -1 (don't think we need to keep BOSH forever, but probably still need it today) Travis intends to rework the PR for next week. Daniel thinks that it's interesting W3C EventSource is still around, even though WebSocket exists, but that's probably a discussion for another day. 4b) PR #1159 (Obsolete and update Security Considerations for XEP-0138 and XEP-0229) - https://github.com/xsf/xeps/pull/1159 Jonas would like to point out that writing a MUST NOT in an Obsolete document seems pointless. Georg agrees with obsoleting, but says that "this method is deemed insecure and MUST NOT be used" is a normative change and policy must not be enforced with protocol. Sam understands the reasoning, but has also deployed it on large projects and found it to be extremely beneficial - Travis notes that lots of insecure things are useful. Jonas would be happier if, instead of changing the normative text, a huge security notice were added at the top of the document and in the place where the normative text would've been changed, otherwise the "MUST NOT" part seems obsolete - the author, Travis, explains that the "MUST NOT" is targeted at the method specifically, as he expects a new compression method may be used with the negotiation being resurrected - Jonas still thinks it seems off. Georg would be okay with obsoleting and adding a big red warning in the Security Considerations - Jonas agrees - Travis is happy to change it and will prepare an update for next week. Travis: +1 (as author) Larma: +1 Georg: -1 (because of the MUST NOT) Daniel: -1 (either just obsolete it or just add a security warning) Jonas: -1 (what Georg says) Sam has a brainwave: maybe there could be a non-normative "Editorial Notes" section at the top of XEPs which doesn't require a version update since it's not actually part of the XEP - Jonas thinks that such things should definitely be versioned - Sam says it would still be versioned in Git, and could be updated by Editor or Council. 4c) PR #1163 (XEP-0045: Remove some more mentions of GC 1.0) - https://github.com/xsf/xeps/pull/1163 Georg doesn't think that "[citation needed]" is appropriate in a XEP - Editor will leave a note. Daniel: [on-list] (probably fine, just want to double check later) Georg: [on-list] Larma: [on-list] (same as Daniel) Jonas: [on-list] Travis: [on-list] (would be be +1 if not for [citation needed]) 4d) PR #727 (Obsolete some deferred XEPs) - https://github.com/xsf/xeps/pull/727 This PR moves three currently Deferred XEPs to Obsolete; Jonas suggests voting for each XEP separately - Daniel agrees. 4d i) Obsolete XEP-0008 (IQ-Based Avatars) - https://xmpp.org/extensions/xep-0008.html Jonas: +1 Georg: +1 Daniel: [on-list] Larma: +1 Travis: +1 4d ii) Obsolete XEP-0038 (Icon Styles) - https://xmpp.org/extensions/xep-0038.html Larma: +1 Jonas: [on-list] Travis: +1 Georg: +1 Daniel: [on-list] Georg would still like a XEP for mapping the ASCII smiley to Unicode - Jonas thinks that's better suited to ModernXMPP - Pep suggests using 'jabber:x:data'. 4d iii) Obsolete XEP-0051 (Connection Transfer) - https://xmpp.org/extensions/xep-0051.html Larma: +1 Travis: +1 (with prejudice because it needs major security considerations) Jonas: +1 (think this is best addressed with <see-other-host/> stream error in RFC 6120, which also talks about the corresponding security considerations) Daniel: [on-list] Georg: +1 (given <see-other-host>) Georg notes that it's been Deferred for over a decade, and asks if anybody is using it - Travis hopes not, or at least that they're using it in a secure way. 4e) Proposed XMPP Extension: MUC Affiliations Versioning - https://xmpp.org/extensions/inbox/muc-affiliations-versioning.html Daniel asks about using attribute namespaces - remembers there was a huge debate, but not the outcome - Jonas says the outcome was that some people are using XML libraries that can't handle them; Sam has seen multiple implementations that will break, even though their XML parser technically has namespace support. Pep notes that they're used in XEP-0103 (URL Address Information) and referenced in XEP-0449 (Stickers). Jonas: [on-list] Larma: +1 (as author) Travis: [on-list] (gut reaction is to run from attribute namespaces) Georg: [on-list] Daniel: +1 Pep (also author) doesn't think use of attribute namespaces should be an barrier for Experimental - Jonas agrees. Daniel starts thinking bigger: versioning not just affiliations, but presence and roles as well - Pep and Larma point to XEP-0311 (MUC Fast Reconnect) and XEP-0436 (MUC presence versioning) for doing exactly that. Georg thinks it would be awesome to have a differential membership update mechanism for huge MUCs. 5) Pending Votes Georg votes on PubSub Type Filtering: +1 6) Date of Next 2022-02-23 1600 UTC 7) AOB Jonas had an idea, but Daniel notes the time and checks if everyone is fine with extending the meeting - nobody starts rioting. Jonas notes that the past two years have brought increased usage of A/V technology and was wondering whether Council would like to migrate to conducting meetings in audio and possibly video; invites people to think about it to discuss next week - Georg is against it, not just for auditability reasons; Daniel was considering proposing something similar, maybe for the first meeting of each month. Larma isn't entirely against it, but doesn't like the idea of using non-standardised XMPP for this. Travis would prefer text, but is fine with audio if everyone else is. Sam notes that minutes would need to be written live, unless the meeting is recorded - Jonas volunteers to write proper online minutes for auditability (already has been doing that for various work meetings.) Daniel thanks Jonas for the suggestion, but with Georg seemingly against it, maybe it's something to reconsider at a later date. Jonas would like a proper discussion next week when there is more time. 8) Close Thank you everyone. Thanks Daniel! Thanks! Kev thinks "Editorial Notes" is a fine idea, but also thinks there's no reason not to version them (version numbers are cheap, and the last part already represents editorial changes) - Sam was aiming to avoid a bump on a ten-year-old Final XEP just for fixing a typo. Pep would be against A/V meetings, but maybe there can be trials to see how it goes; Kev thinks it's useful for Council if that's their only activity (e.g. not on a train), while text is more useful for people following along or reading later - maybe a poll would be useful to see how many people actually read the logs.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
