dwd(Searching and fighting with a MacBook. Awful things)
jonas’soo... I’m not happy with the things quality editor wise
dwdTempting to veto this until the examples are funnier.
dwdjonas’, How so?
jonas’e.g. the "OPTIONAL." thing which is left over below the Glossary heading
jonas’section 9 is questionable too
jonas’and such
jonas’but I’m not here with my editor’s hat
Ge0rGDo we have other comparable XEPs in place?
jonas’Ge0rG, in terms of functionality or in terms of editorial quality?
KevWe have accepted very raw XEPs in the past, if that's the question.
Ge0rGin terms of functionality.
dwdWe've had a number of early Experimental XEPs in similar condition over the years, I think.
KevOften mine. Although I'm not sure I've gone quite this far.
Link MauveGe0rG, we do have 0050, it’s mentioned already.
jonas’Ge0rG, not that I know. the closest is data forms and ad-hoc, but they don’t do quite the same thing.
Ge0rGI wonder if embedding a data form into a message would make sense instead.
KevThey do so dangerously close to the same thing that a new mechanism seems wrong to me.
ZashThere's precedent for dataforms in messages in eg 0045
jonas’Kev, which?
Kev(xep4 in messages)
jonas’indeed, kind of
ZashI did a draft of that but it was ugly and horrifying and let's not go that way
dwdDo we have buttons in dataforms?
Ge0rGI kind of fear data-forms indeed.
KevI appreciate forms don't quite do buttons yet, but extending them for that and i18n seems more appropriate at first glance than a new mechanism that we'll later need to extend for other form things.
akashhas left
jonas’dwd, no, but they could be handled with a list-single
Zashdwd: not really
Link Mauvedwd, we have list-single, which is close enough.
Ge0rGaren't actions akin to buttons?
Link MauveIt already is represented by buttons in some clients when there are few choices.
ZashGe0rG: those are fixed at next/prev/cancel/complete
dwdWell, maybe - but with ad-hoc we did actions, as Ge0rG implies, not in dataforms.
jonas’Ge0rG, they’re a Ad-Hoc thing, not a Data Forms thing
akashhas joined
Zashdataforms in message: https://xmpp.org/extensions/xep-0045.html#example-79
jonas’vanilla Ad-Hoc does not allow passing the context of the conversation in which this is happening
jonas’which this ProtoXEP does
jonas’and which any solution which wants to have this needs to
Ge0rGjonas’: I don't see context in this protoXEP
jonas’Ge0rG, @from
jonas’you can distinguish whether a reply from a user comes via a MUC or not
dwdGe0rG, There's context of conversation, not of message.
jonas’although that would probably work via MUC IQs, but maybe let’s not go there either
jonas’having context of the message is also a possibility with the protoxep by making the values unique
ZashCombine with <thread> or whatever?
jonas’(e.g. append the @id of the message)
dwdSo two questions:
Link MauveIf two people send a <button/> in two following messages with the same @value, you have no way of knowing which one was referenced.
dwdi) Do we think that having buttons in chat messages is OK?
jonas’Link Mauve, that’s true for a MUC.
dwdii) Is this method so broken we should abandon it?
jonas’i) yes, I do think that.
Ge0rG+1 to (i), not sure about (ii)
jonas’I do think that we should have that in fact, because there are many good and reasonable use-cases for this. Memberbot being one of them.
Link Mauvejonas’, for direct chats too, if your contact sends you the same set of buttons twice.
Kevi) I think some use case involving something like this is valid (not quite answering the question)
jonas’Link Mauve, that’s your contact’s fault.
Link Mauvedwd, i) definitely.
dwdjonas’, memberbot gets around the lack by using xmpp URIs to click on, which is pretty ikky.
jonas’dwd, I agree.
Kevii) It doesn't seem to be actively broken, but that's not the only reason to consider rejecting, I think.
Ge0rGmaybe a client should only render the buttons in the last incoming message?
dwdGe0rG, Or grey them out when clicked.
jonas’do we wanrt to open the can of worms what the "last message" is again? :)
ZashI'd like a generic <in-reply-to id=.../> plz
jonas’Zash, SHIM?
Link Mauveii) I’ve needed way more than “just a set of buttons” a few times, for instance this very poll you’re making could do with a two questions text-single form.
KevI'm of the opinion that this is the Wrong Way, in the absense of further persuasion.
Link MauveSo, not sure it’s that broken, but it looks very much not usable for more than a very narrow set of usecases.
KevI just can't quite decide whether I should veto or not.
dwdOK, so can I have some votes please:
jonas’regarding (ii):
- I think those types of features are only useful for bots.
- I think this proposal is something to play with.
- I also definitely want more extensive features than this.
KevOn-list.
jonas’I think I’m with Kev, but it’s tricky.
dwdI think I'm +0 on this.
Ge0rGOn-list as well, for similar reasons
jonas’formal question: can I say -1 now and decide to change it to +0 or +1 later on, until everyone has voted or the vote expires?
KevI'm concerned that people will jump on this, implement the simple stuff, and then immediately start extending with other form fields, and we'll rebuild xep4.
jonas’Kev, very valid convern
dwdjonas’, We have, historically, allowed changes to votes until the last vote comes in, yes.
jonas’Kev, very valid concern.
Kevjonas’: I see nothing wrong with 'on-list, -1 if I don't do so'.
jonas’ok.
Link MauveOn list.
dwdjonas’, Also, what Kev says.
jonas’on-list, -1 if I don’t do that.
Kev(But if you do end up with -1, you're obliged to provide reasons)
dwdjonas’, Though please do vote even if it's to confirm a veto, since otherwise you're delaying the end of the vote.
jonas’ok
jonas’also, good point Kev.
jonas’so changing to pure on-list now, because I can’t give a clear reason for -1 on the spot
KevYou don't have to on the spot, on standards@ is appropriate.
jonas’Kev, if I say "-1 if I don’t go on-list", I kinda have to though :)
Ge0rGwould this protoxep be sufficient for the "interact with a bot" use case?
dwdOut of curiosity, of those on-list, are any of you potentially going to vote +1, or is this a choice between -1 and ±0?
jonas’Ge0rG, not for the use-cases I have in mind.
KevThis is a choice between -1 and -0.
jonas’dwd, there is a slim chance of +1
Ge0rGthere is a moderate chance of +1
dwdI ask because unless we can find three +1's, there's very little point in continuing.
jonas’my issue with data forms is still that they don’t have a i18n story, and while others seem to think that you can always discover the right language, I don’t think that’s true.
Ge0rGI like the simplicity of the proposal, and it might be a good self-contained things not bothered by dataforms
jonas’so on this ground alone, I thnik that this proposal has a material advantage over plain data forms.
dwdjonas’, I'm afraid that i18n in more a theory than a practise anyway.
jonas’dwd, I know of implementations which send i18n’d error messages, and implementations which can deal with that to some extent.
Kevjonas’: I think we're faced with two options - one is to 'fix' xep4 in whatever way, the other is to invent an entirely new xep4. Given xep4's ubiquity, I'm far more inclined to fix that (until it's shown it can't be fixed).
jonas’Kev, I agree.
jonas’although I think that XEP-0004 in itself does too many things already.
jonas’(I don’t like the mix of forms and reports under the same element, it makes implementations weird and validation more complex than necessary.)
dwdKev, The other alternative is a sort of mutation of XEP-0050 for chat.
Kevdwd: Essentially extending xep4, I think, so I'd put that under the same heading.
Zash'submit' type form field?
ZashLike <input type=submit> in html?
jonas’just a list-single with a specific var would do, no?
dwdAnyway, you're all on-list, so let's move on.
dwdAlthough what to, I'm not so sure - do we have anything else to vote on?
jonas’+1, but I’d like a discussion on why the CS are on the Standards Track and not Informational. It doesn’t make sense to me, semantically, except that XEP-0001 specifically lists CS to be on Standards Track.
Link Mauve+1, even though there are a few new XEPs missing from it which would be useful in 2019, but that can be fixed.
dwdI'm +1 on this.
Ge0rG+1 for moving to experimental
KevI only caught this just before Council, so I need to on-list.
KevSorry.
Ge0rGjonas’: what's the delta to CS'18?
dwdjonas’, Adding a delta to the document would be handy, actually.
Ge0rG(I think it would make sense to mention new / removed XEPs in the Revision History)
jonas’Ge0rG, that would make sense if it was the same document
KevIt would anyway, I think.
jonas’one sec for the "diff"
KevNot here necessarily, in the XEP itself.
Ge0rGjonas’: IMHO, it would make sense to keep the whole history of CS in the newest one.
Link MauveAs per my email from last meeting, I’d like to make a lot more noise about compliance suites, calling it XMPP 2019 and doing a lot of marketing around this, pointing fingers to Pidgin and other abandonned clients.
jonas’Ge0rG, that’s awful
jonas’Link Mauve, maybe sync up with Tedd Sterr on this
Ge0rGyaxim is abandoned by that definition 😢
jonas’Ge0rG, ok, the diff is unreadable even for me, so I’d like to do that in a quiet minute
dwdLink Mauve, It's something to be pushed up to the Board,m actually.
Link MauveGe0rG, the goal is to stop with the complaint that XMPP is bad because Pidgin is bad.
Link Mauvedwd, indeed.
Ge0rGjonas’: at the minimum I'd like to see what changed since the last CS in the revision history
jonas’Ge0rG, can do, but not right now
Ge0rGLink Mauve: I know, but as long as Pidgin is advertised by the XSF, this is moot (https://github.com/xsf/xeps/pull/715)
ZashIs "XMPP is bad because Pidgin is bad" solvable by redefining "XMPP"? I suspect we need to crowd-fund maintanence and development of it to fix that. :|
Ge0rGLink Mauve: I know, but as long as Pidgin is advertised by the XSF, this is moot (https://xmpp.org/software/clients.html)
ZashIs "XMPP is bad because Pidgin is bad" solvable by redefining "XMPP"? I suspect we need to crowd-fund maintanence and development of Pidgin to fix that. :|
jonas’bump the stream header version
Link MauveGe0rG, no, we can change things even if we don’t fix all of them at once.
Ge0rGXMPP2 for president!
jonas’Ge0rG, so you’re -1 until the revision history is fixed?
Zashjonas’: YES! Kill the jabber:client & jabber:server namespaces and unify! :D
jonas’oh no, you gave your +1 already :)
Ge0rGjonas’: I'm +1
jonas’Zash, sounds like a plan!
Link MauveAnd the announce effect is already something to aim for, for “compliance suites” or whichever new name we’d find.
Link Mauve(I like Rust’s “editions”.)
jonas’dwd, I think everyone gave a vote or on-list’d?
Ge0rGLink Mauve: we can only change things if all of us are heading in the same direction.
KevI would very much like to see a logical diff from the previous suite, but that won't be influencing my vote (on-list).
dwdFolks, what the Board chooses to do with the website and the compliance suites once we finish them is out of scope for this meeting.
jonas’(FWIW, I’d also like input from the xmpp-based social network crowd; they could probably use their own section in the CS)
Ge0rGregarding contents, I think that 0184 belongs to IM Core
Link MauveI’d like cs-2019 not to supersede cs-2018 until it is set active, but other than that +1.
dwdLink Mauve, I think that's automatically the case.
jonas’Ge0rG, can you put this on-list or somewhere less ephemeral than this room, please?
Link Mauvedwd, it currently is set to supersede it, even though it’ll be experimental for a while.
Link MauveBut that’s editor’s domain.
dwdLink Mauve, Yes, but it's an intent until it's Active, I believe.
jonas’it will never be Active
jonas’because it’s Standards Track
jonas’it can only become Draft or Final (on the positive side of things)
jonas’it can only become Draft and Final (on the positive side of things)
dwdANything else?
dwd(To vote on?)
jonas’the PRs I mentioned above
dwdjonas’, I'll check the status of those PRs later. I cannot recall their status either.
jonas’ok
jonas’fine with me
dwd3) AOB
jonas’just a quick note that we have had a XEP-0001 modification
Ge0rGIIRC we voted on both PRs.
Link Mauvejonas’, the last council said they didn’t have any pending vote.
jonas’we can now move Proposed back to Experimental
jonas’and also that we have a bunch of stuff stuck in Last Call
jonas’so that would be something to look on for the next meeting
KevI thought everything got voted on last Council.
dwdKevI think so too.
jonas’ok, then it’s probably my (editor’s) own oversight
KevAt least, everything I knew needed to be.
jonas’For reference, those are the open LCs:
XEP-0357 (Push Notifications), LC ends: 2018-11-03; https://xmpp.org/extensions/xep-0357.html
XEP-0359 (Unique and Stable Stanza IDs), LC ends: 2018-11-03; https://xmpp.org/extensions/xep-0359.html
XEP-0280 (Message Carbons), LC ends: 2018-02-22; https://xmpp.org/extensions/xep-0280.html
XEP-0363 (HTTP File Upload), LC ends: 2018-06-18; https://xmpp.org/extensions/xep-0363.html
jonas’since they’re open, I’ll re-start them due to council switch as editor soon-ish
jonas’just so that you get an idea already.
KevAt least 357 and 359 aren't open, we definitely finished those last Council.
jonas’(after double-checking that they havent been voted on already)
dwdjonas’, I believe that XEP-0363 is awaiting edits due to feedback, but I might be wrong.
Ge0rGI'm pretty sure we also -1ed Carbons because of XMPP-NG
jonas’hm
jonas’ok, I’ll shut up now and do my due diligence as editor. sorry for the noise. :)
dwdAny Other AOB?
jonas’not from me
dwd4) Next Meeting
jonas’+1w WFM
dwdSame XMPP Time, Same XMPP Channel?
Link MauveWFM.
dwdThat's 2018-12-19 16:00 UTC.
KevI will try to be here. I'll be in another meeting at the same time.
KevSo preemptive tentative apologies.
dwdI'll be (finally!) back at home.
Link MauveKev, would another time suit you better?
KevNot a lot.
Ge0rGI'll be on a train most probably.
KevIt's only next week and last week it's an issue.
Ge0rGUnless, due to strike, I'll be on a car. Which will make typing much more challenging.
jonas’I can do any day of the week except friday and weekend next week at that time, FWIW
dwdLet's stick with the same time and hope Kev/Georg can make it. We hit Christmas after that anyway.
Link MauveYup, at which point we can do the meeting at 35c3. :D
jonas’(not for me)
dwd5) Ite, Meeting Est.
dwdThanks all.
KevThanks all.
jonas’thanks all
Ge0rGThanks!
Link MauveThanks. :)
Ge0rGOh, I'd also like to advance XEP-0410.
Link MauveGe0rG, shouldn’t you do that on standards@?
Ge0rGprobably yes
jonas’you wanna have a Call For Experience issued?
Ge0rGI think I do. We have working implementations in poezio and in yaxim, and the server optimization in ejabberd and prosody