http://logs.xmpp.org/council/2018-12-12/#16:02:26
1) Roll Call Present: Jonas, Link, Georg, Dave, Kev 2a) Proposed XMPP Extension: Simple Buttons - https://xmpp.org/extensions/inbox/buttons.html Jonas is not happy about the editorial quality of this one. Georg asks if there are any functionally comparable XEPs - Link mentions XEP-0050 (Ad-Hoc Commands); Jonas mentions XEP-0050 and XEP-0004 (Data Forms), noting they don't do quite the same thing. Georg wonders whether embedding a data form in a message would make sense. Zash tried to draft something like this, but it was horrifying. Kev thinks it would be more appropriate to extend Data Forms with buttons and internationalisation than to have a new mechanism that will later need to be extended for other form things anyway. Dave asks whether there are buttons in Data Forms - Jonas and Link think they could be handled with list-single. Georg asks if actions are essentially buttons - Link says they are rendered as buttons in some clients; Zash points out that they're fixed functionality (next, previous, cancel, complete); Dave and Jonas say actions are part of Ad-Hoc Commands, but not Data Forms. Jonas notes that Ad-Hoc Commands doesn't allow passing of the conversational context, while this XEP does; and message context could come from making the button values unique. Dave starts asking the important questions: is having buttons in messages OK? and is this method so broken it should be abandoned? Everyone is generally supportive of having buttons in messages - there are good use cases, e.g. Memberbot. Dave notes that Memberbot currently uses clickable XMPP URIs, which is "ikky." Kev doesn't think it's actively broken so much as the Wrong Way, and can't decide whether to veto. Link has needed more functionality than 'just buttons' a few times (this poll could have been two text-single questions, for example); it's not necessarily broken, but only suited to a narrow set of use cases. Jonas thinks such features are only useful for bots, but this proposal is worth playing with, and he would definitely want more extensive features. Georg ponders whether clients should only render the buttons for the last incoming message; Jonas doesn't want to start a debate on the exact meaning of 'last message'; Dave suggests disabling the buttons when clicked. Zash would like some kind of 'in-reply-to' tag. Dave demands votes. Kev: [on-list] (concerned people will jump on this, implement the simple stuff, then start extending with other form fields, and we'll rebuild xep4) Jonas: [on-list] Dave: +0 Georg: [on-list] Link: [on-list] Georg likes the simplicity of the proposal, and thinks it might be good as a self-contained thing (without Data Forms.) Jonas thinks this proposal having an i18n story is an advantage over Data Forms; and though people think it's possible to discover the correct language, that's not always true. Dave thinks i18n is more theory than practice; Jonas knows of implementations that send internationalised error messages and ones that can deal with receiving them. Kev says there are two options: fixing Data Forms in whatever way, or inventing an entirely new not-data-forms-but-still-very-much-data-forms; Jonas agrees, but thinks Data Forms tries to do too many things already (forms and reports under the same element makes implementations weird and complicates validation). Dave throws in a third option: mutated-adhoc-commands-for-chat; Kev would include that under extending Data Forms. 2b) Proposed XMPP Extension: XMPP Compliance Suites 2019 - https://xmpp.org/extensions/inbox/cs-2019.html Jonas: +1 Link: +1 Dave: +1 Georg: +1 Kev: [on-list] Jonas would like a discussion on why the Compliance Suites are on the Standards Track, rather than Informational - semantically, it doesn't make sense, other than because XEP-0001 says so. Link thinks there are a few useful XEPs missing, but that can be fixed. Georg would like to know what's changed between CS'18 and '19; Dave thinks adding a delta to the document would be useful. Georg suggests mentioning which XEPs are new/removed in the Revision History - Jonas says they're not the same document. Georg would at least like to see what has changed since the last Compliance Suites, as would Kev. Link would like to make more noise about the Compliance Suites, maybe calling it XMPP 2019 and doing a lot more marketing around this; also, shaming bad/abandoned clients in the hope of breaking the "XMPP is bad because bad-client-that-does-xmpp is bad" association. Dave says this is something to be pushed up to Board. Jonas would like input from the XMPP-based Social Network crowd for their own Compliance Suites section. 3) AOB Jonas notes that XEP-0001 has been updated to allow movement from Proposed back to Experimental; also there are some XEPs stuck in Last Call. 4) Next Meeting 2018-12-19 1600 UTC Kev has a conflicting meeting, but will try to be here. Georg will probably be on a train, or maybe in a car, but shall battle overwhelming circumstances to make it regardless. 5) Close All thank all. Georg would like to advance XEP-0410 (MUC Self-Ping); Jonas offers a CFE - Georg grabs it with two hands (one for Poezio and another for Yaxim.)
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
