KevI'm not sure about the implication in the intro that BM2 isn't widely adopted, but that PEP BMs are.
Kev(But that's not a blocking comment, naturally)
ZashI think there are 3 client implementations actually.
KevI'll be inclined to go straight to BM2, rather than ever implementing BM/PEP in Swift.
danielKev: I have so many issues with BM2...
KevBut I'm not blocking the protoXEP.
danielBut that's probably a discussion for another day
Kevdaniel: I don't necessarily mean BM2 as-written, so that might be fair.
Kev4) LC on 359 (stanza IDs)
KevI see no harm in issuing LCs in general, so +1.
SamWhited+1 for LC
Kev5) LC on 357 (push).
KevAgain, I see no harm in an LC (even if I don't think it's ready for advancement)
danielI don't think it will make it
danielBut yeah we can issue it
Ge0rG+1 for both LCs
KevThe main reason not to is if we're convinced Council is going to -1 advancement, and we can save the Editor some work, I think.
KevI suspect, rather than am convinced, that that's the case.
DaveHiya, sorry - things a little hectic. :-(
SamWhitederr, sorry +1 on LC for 357 too
danielI'm fairly convinced that push will be -1 after the lc
danielBut still +1 for the lc
SamWhitedIf nothing else it will help flush out feedback from the community, which isn't necessarily bad
Kev6) Date of next.
Link MauveAOB from the floor: what is still missing for the MUC avatars conversion ProtoXEP?
Link MauveAOB from the floor: what is still missing for the MUC avatars ProtoXEP?
KevI fear I missed that one while I was on my nearly-a-month holiday of bliss :)
Kev(So I don't know)
KevAFAICs, that had three +1s, and two on-lists a month ago.
KevSo unless someone vetod on-list, it's ready to publish.
KevAh, Sam vetod.
SamWhitedDo you have a link to that email? I'm struggling to find it
Kev"Re: [Standards] XMPP Council Meeting 2018-09-05" if that helps.
KevIt's the one in which you start by saying it's a great protoxep, and that you're vetoing it :)
SamWhitedFound it, thanks
SamWhitedah yah, that's why, yup, I agree with myself still.
KevFWIW, I think delaying things that make life a little bit better with avatars, in the hope that some day everything gets sorted out, is probably not the best way here.
KevIf people are doing this stuff anyway, interop is better than not, and provides a clear spec to deprecate later.
Link MauveThat was my reason for not going full on PEP and postpone this even more.
SamWhitedI think it's as simple as mentioning that it can be done in one of the other avatar specs instead of completely re-hashing all of vcard-temp
KevI'd rather, I think, we could say at some point in the future "Here are all the ways people do it already. We're now deprecating them all in favour of the One True Ring" than "Here are some of the ways, we're deprecating those, but lots of people did other things and we can't say anything about those".
Link MauveSamWhited, so basically I should remove the examples, and only leave the disco and notification parts?
SamWhitedLink Mauve: I don't think it should be a separate XEP at all
DaveI rather liked edhelas's suggestions for expanding this in such a way that it can do pubsub nodes and all sorts, personally.
SamWhitedHaving 4 or 5 different avatar specs already, I don't think adding another reduces that confusion.
Link MauveYou’d be in favour of adding discovery and MUC-specific notifications to e.g. XEP-0153?
Link MauveDave, so moving discovery to another XEP-0128 dataform?
KevI think we've moved beyond Council discussion here and I'm inclined to close the meeting. Any objections?
Link MauveNone from me.
SamWhitedLink Mauve: I'm not sure where the best place is; 0153 might be it. Or MUC itself.
SamWhitedKev: oops, one more AOB
SamWhitedIs this a matter for council? https://github.com/xsf/xeps/pull/706
SamWhitedThere was some confusion about this a few weeks ago, updating to the new language would have fixed it and we've been doing it this way anyways
KevI think that should be an agenda item, yes. For the next meeting.