https://logs.xmpp.org/council/2022-01-05?p=h#2022-01-05-bb4956c3043a4dfa
Happy new year, Council! 1) Roll Call Present: Larma, Jonas, Daniel, Georg Absent: Travis 2) Agenda Bashing Daniel notes some additions to the agenda, as Editor published a few new proposals after it was already sent out - doesn't expect people to vote yet, given they haven't had time to read them; at least one looks like it may become an interesting discussion [1], which could decide Jonas's vote. Georg is pleased to have more discussion. 3) Editor's Update * Last Call on XEP-0424 expired * Last Call on XEP-0425 expired * Proposed XMPP Extension: Compatibility Fallbacks * Proposed XMPP Extension: PubSub Namespaces * Proposed XMPP Extension: Call Invites * Proposed XMPP Extension: Message Replies 4a) Advance XEP-0424 (Message Retraction) - https://xmpp.org/extensions/xep-0424.html Jonas: -1 (depends on a bunch of experimental XEPs the future of which is unclear) Daniel: -1 (agree with Jonas) Georg: -1 (we need to sort out the message referencing mechanism first; also dislike the amount of boilerplate in both [this and 0425]) Larma: -1 (same here; also goes for 0425) Travis: [pending] 4b) Advance XEP-0425 (Message Moderation) - https://xmpp.org/extensions/xep-0425.html Daniel: -1 Georg: -1 Jonas: -1 (same reasoning as for 0424) Larma: -1 Travis: [pending] Daniel notes that even though the following four votes are starting now, not everyone is necessarily expected to be ready to vote yet. 4c) Proposed XMPP Extension: Compatibility Fallbacks - https://xmpp.org/extensions/inbox/compatibility-fallback.html Georg: [on-list] Larma: +1 (I submitted it, so would be weird to be against) Daniel: +1 Jonas: +1 (good enough to play with; note it misses a Requirements section) Travis: [pending] 4d) Proposed XMPP Extension: Call Invites - https://xmpp.org/extensions/inbox/call-invites.html Daniel: +1 Larma: +1 Jonas: +1 (looks sensible) Georg: [on-list] Travis: [pending] The author, Larma, notes that this will become useful with PR #1139 [2] applied. Jonas suggests improving the wording on where to send the 'left' element. 4e) Proposed XMPP Extension: Message Replies - https://xmpp.org/extensions/inbox/replies.html Daniel thinks this must be the third or fourth XEP dealing with replies - Larma (as author) hopes it will be the first to stick. Jonas isn't sure this should be accepted without a Design Considerations section detailing why the other mechanisms aren't workable; this feels like duplication ('thread', References, and Fastening already exist), so some rationale in the document would be appreciated before acceptance - Larma says those others don't specifically deal with replies. It's not immediately obvious to Jonas why 'thread' wouldn't work here, as a reply could always fork off a fresh thread - Larma explains that this only works if the original message has a thread-id - Jonas has a realisation. Georg is glad that this doesn't depend on 'origin-id'. Daniel doesn't really see threads as a fitting example, but does see overlap with References and Fastening. Jonas remembers Message Attaching as another example. Larma doesn't agree they are very similar, but sees the need for a section in the XEP to explain why it's different. Daniel: +1 Larma: +1 Georg: [on-list] Jonas: -0 (desperately needs a Design Considerations section to explain why the other four standards are not an option to achieve the goal) Travis: [pending] 4f) Proposed XMPP Extension: PubSub Namespaces - https://xmpp.org/extensions/inbox/pubsub-ns.html Jonas: -1 (until there's a good explanation for why pubsub#type isn't an option) Daniel: 0 (don't know enough about pubsub to make a good call) Georg: [on-list] Larma: [on-list] Travis: [pending] Larma notes that PR #986 [3] has an explanation for 'pubsub#type' - Jonas says it should be in the document. 5) Pending Votes Everyone but Jonas on PR #1126. Daniel: -1 (should go into 0004; should ask editor to cherry pick the editorial / non controversial bits from that PR) Larma: -1 (not sure if 0004 is the right place either, but the proposal definitely shouldn't go as is) Georg: -1 (with the PR as-is, maybe a better non-normative wording can be proposed if we fail to update 0004) Jonas wonders how such an integration with XEP-0004 would look, as being Final makes it tricky - Daniel thinks there was some discussion on how that could still be done in a compatible way, but also thinks it could be done with a new XEP. 6) Date of Next 2022-01-12 1600 UTC 7) AOB None. 8) Close Thank you everyone. Thanks Daniel. Thanks Daniel! Kev, as References author, doesn't think References is a reason to block Message Replies, but agrees that some explanation would be worthwhile - does think References would work for the use case, but being stuck on URIs is a bit unfortunate. [1] https://mail.jabber.org/pipermail/standards/2022-January/038695.html [2] https://github.com/xsf/xeps/pull/1139 [3] https://github.com/xsf/xeps/pull/986
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
