http://logs.xmpp.org/council/2019-07-31?p=h#2019-07-31-8df0a6feee05cf18
1) Roll Call Present: Kev, Link, Georg, Jonas, Dave 2) Agenda Bashing Kev would like to add an item about Reactions; Jonas mentions PRs #801 and #803. 3) Activity Summary Dave would hereby like to draw everyone's attention to the following noteworthy announcements: - Newly published XEP-0420 (Stanza Content Encryption) - https://xmpp.org/extensions/xep-0420.html - Last Call for XEP-0353 (Jingle Message Initiation) - https://mail.jabber.org/pipermail/standards/2019-July/036317.html - Last Call for XEP-0300 (Use of Cryptographic Hash Functions in XMPP) - https://mail.jabber.org/pipermail/standards/2019-July/036316.html Please join in the Last Calls and make your opinions known! Jonas (Editor) formally apologises for the publishing delay, citing email client issues (and possibly demons) - a 3.5" floppy disk has been ceremoniously burnt, so things should now work as expected. 4a) PR #801 - XEP-0368: clarify fallback behavior on SRV failure - https://github.com/xsf/xeps/pull/801 Kev thought this had already been approved, but may be confusing it with the somewhat contradictory PR #796 which was actually approved (held by Editors, with author's approval, to allow for Council discussion of #801.) Having re-read the XEP-0368 thread, Link is strongly in favour of #796. Jonas observes that the community seems to have at least three opinions on how XEP-0368 should work. Dave is baffled by #801 - Jonas thinks the fallback chain is xmpps-server -> xmpp-server -> A/AAAA, while #796 is (xmpps-server + xmpp-server) -> A/AAAA; Dave thinks it implies that if _xmpps returns '.' then look up _xmpp. Georg summarises: #796 = DO NOT try to connect via A/AAAA if there is an SRV record; #801 = DO try to connect via A/AAAA if there is an SRV record. Link says the problem with #801 is that it assumes DNS can't be trusted, but DNS and SRV are required for XMPP to work. Kev doesn't understand the rationale behind not trusting DNS results, then using other DNS results - neither does Jonas. Link adds that the 'YOLO' port fallback is not a good way to do it. Dave thinks there may be an argument that a downgrade attack could inject a '.' record into _xmpps-*, though #801 wouldn't help with that level of control over DNS (and could arguably make things worse.) Jonas: -1 (inappropriate port choice; doesn't clarify, but changes behaviour; contradicts normal SRV working; logically incoherent regarding trust of DNS) Georg: -1 (agree with Jonas) Dave: -1 (don't think I like possibly anything about this) Link: -1 (same reasons as Jonas) Kev: -1 (don't like it at all; in comparison, #796 seems logical) 4b) PR #803 - Obsolete Compliance Suites 2018 - https://github.com/xsf/xeps/pull/803 Georg: +1 Link: +1 Jonas: +1 Kev: +1 Dave: +1 Georg reminds Dave of his intention to arrange a focus group regarding Compliance Suites 2020. 5) Outstanding Votes As his remaining vote, Kev takes the opportunity to discuss Reactions (https://xmpp.org/extensions/inbox/reactions.html); doesn't want to prevent progress, but feels things will end badly if this is published. Jonas doesn't think References (XEP-0372) is a good choice (needs drastic changes to be useful, especially for quick aggregation use-cases), but Message Attaching (XEP-0367) would be okay; doesn't think it's fair to burden the authors of Reactions with waiting for a proper referencing XEP. Jonas is still very tempted to vote -1 based on the "body fallback" argument - Kev would vote -1 if it had a fallback, as that would obviously be broken (will break MAM, and people tend to use reactions where a long stream of "+1" messages would distract from the conversation); Jonas would like a high-bandwidth meeting on that topic. Link notes that there are already three implementations in the wild, one released this week - Kev sees that as another argument not to publish. Georg suggests renaming XEP-0367 to something more generic, appropriate for all message-relationship use-cases, and then using it for Reactions and others. Jonas wonders how it would break MAM - Kev says you'd end up with countless messages in the archive since they have body content - Jonas says the reactions need to be in the archive anyway (the XEP specifically adds a 'store' hint). Jonas says there is still communication happening which non-supporting clients wouldn't see, and this is an extremely bad thing. Georg thinks there are two fundamental positions: reactions are an important part of communication, or they're not; if they're not then the XEP should be abandoned entirely, but if they are then a legacy fallback is needed. Dave doesn't think legacy fallback bodies should be baked into the protocol - Jonas thinks they should, at least during the Experimental phase, and then re-evaluate - Dave thinks then they'd never be let go. Link disagrees with fallback bodies being sent, as reactions are generally add little to the discussion, and non-supporting clients would render them annoyingly. Kev says that sending reactions with fallback bodies in a MUC will effectively exclude legacy clients from the conversation due to the level of spam they'd generate. In Kev's experience, the ratio of messages to reactions is almost an order of magnitude; Jonas doesn't have the same experiences, and reactions often carry important information. Dave says that for a typical MUC setup with a scrollback history of about 20 lines, a burst of reactions with legacy bodies would sweep away the entire scrollback (unless the MUC is aware of reactions.) In a one-to-one chat, the client will know if the other party supports reactions, so legacy support isn't needed - Georg and Jonas say this isn't accurate, noting MAM and Carbons effects. Kev thinks this discussion has veered wildly off target, and was only trying to justify vetoing on the basis of harm to the network once it's accepted and inertia sets in; stating that there needs to be a different way at least draws a line to avoid any confusion. Kev could be persuaded by adding text to the top explaining how this needs to change and that the authors intend to do so as soon as the referencing problem is resolved in the community - Link and Dave are supportive; Jonas doesn't believe in XEP authors claiming intention to change things after acceptance, due to previous experiences. Georg suggests replacing the referencing mechanism in Reactions with XEP-0367, and Council should make 0367 a sensible long-term vehicle - Jonas would be on-board with this; Kev thinks 0367 could be a reasonable basis for all of these things. Georg tries to start another argument, but Dave notes the time. 6) Next Meeting 2019-08-07 1500 UTC Dave will not be here next week. Kev will probably also not be here next week. The other Council members shall persevere. 7) AOB Georg has plenty to say, but is aware that the time budget has already depleted. Peter is aware that he still needs to review and comment on PR #793, but is currently very busy. Dave proudly points out the addition of the new "Activity Summary" section to help keep track of in-progress Last Calls and similar activities - everyone is in favour. 8) Close Danke schön.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
