jonaswI gotta leave at 1630Z, so I won’t be able to properly take minutes
Kevjonasw: I can do minutes, it's ok ta.
KevDave sends apologies. daniel, Ge0rG, SamWhited - you here?
jonaswtwo out of those have spoken in other MUCs just a few minutes ago :)
Kev2) 186 LC
Kev(This is a re-issue because the last one expired without Council voting)
SamWhitedWhat are we voting on?
SamWhitedOops, too slow
SamWhitedI don't think we have to vote on this; editor will just reissue the LC
SamWhited(but +1 FWIW)
Ge0rG+1 for LC
KevI think that's right, as it happens.
jonasweditor will take notice that this is the councils opinion and re-issue the LC sometime tomorrow, maybe tonight (or somebody besides me does it)
KevAnd same for
Kev3) 352 LC
Kevjonasw: More than Council's opinion, it's what xep1 says :)
Kev4) Deprecating 84
jonaswKev, we could also simply move it back to experimental, couldn’t we?
KevNo, xep1 says that if there's a vote that wasn't completed, the Editors will re-issue an LC.
KevSo, deprecating '84, which I think was Link Mauve's request.
Kev(That's pubsub avatars, for anyone who needs to know)
danielhas there been any argument on why?
Ge0rGI haven't yet compared pubsub avatars to vcard avatars, so I'm impartial.
jonaswIIRC, vcard works today
KevIt just appeared on the Council board without an argument why.
jonaswIIRC, the argument was "vcard works today"
KevLink Mauve can probably say why, though.
Ge0rGjonasw: weren't there special cases where vcard doesn't work in MUCs?
KevGe0rG: none that PEP does work in, I think.
SamWhitedI'd prefer to deprecate 0153. 0084 has its problems, but seems like a better more future-compatible platform, but I don't care as long as we move towards a single way to do avatars.
Ge0rG0153 is Historical already.
KevIndeed, deprecating 153 is likely not the right thing to do.
SamWhitedI disagree; it appears right now that we're recommending two different ways to do avatars, which seems to be the main problem here to me.
KevI'm not convinced that we should be deprecating 84. I'm -1 for the moment, but in the minutes I'll invite an argument why it should happen.
KevNo, I mean that a Historical XEP doesn't need deprecating, because of its nature :)
Kev(Although we can do so, certainly)
Ge0rGSamWhited: which are the two? 84 and 153?
Ge0rGSamWhited: and where are we recommending 153?
Ge0rG(and for what reasons)
danieland the other two :-)
SamWhitedIt's got a big green block of text that says "This is draft" at the top
KevGe0rG: We're not, but it's the de facto standard.
jonasw(which I learnt the hard way which I find annoying)
KevAnyway, with one -1 in place, let's gather votes for this and move on.
Ge0rG387 goes with 84, so it might be not smart to deprecate it.
SamWhitedSounds good; I'll discuss on list if necessary.
KevSamWhited: "sounds good" is voting which way?
KevSame question for contestant number Ge0rG.
Ge0rG-1 for now, until reasons for deprecation are provided
SamWhitedKev: "let's move on" sounds good, I mean. On list.
Kev5) Reverting 48 to 49
KevThat's reverting bookmarks to iq:private instead of private pubsub.
danielis there an argument on why?
SamWhitedI'm not sure why this one was brought up either; is there a problem with them as they are today?
KevThis isn't a voting point, because there's no vote to be made.
KevBut let's discuss.
jonaswthe argument is that the change from private XML to pubsub happened in draft state, which is a major breakage of the protocol. many deployments are still on Private XML
jonaswwhich is indiscoverable to new developers
Kevjonasw: So it's a point of process?
jonaswno, also a point of usability by developers
Ge0rGI think deployments are on private XML because some major XMPP server implementations lack persistent PEP.
KevI think 'indiscoverable' is pushing it a bit, when the XEP says this explicitly.
jonaswso the point is, as a new developer, you see the XEP, you think "neat, PEP", implement it, and find no bookmarks
KevI think private pubsub is a better mechanism to be storing these data than iq:private, so reverting to say it should be iq:private seems wrong, and the XEP already says that existing implementations do iq:private, so implementors know that they'll want to consider at least read access to it.
jonaswI agree that it is a better mechanism.
Kevjonasw: Except you wouldn't, because the XEP notes that people used to do iq:private.
jonasw"used to do" implies that it isn’t that way anymore
jonaswand also, only read access isn’t sufficient, because there are enough clients and servers out there which still can only do private XML
Ge0rGSo maybe we should extend 48 with a compat behavior spec?
Ge0rG0387 does not enforce the type of backend storage.
KevI think the note that we used to recommend iq:private is sufficient, but we could add an extra sentence to say "and it's still widely used" if it'll make people feel better, and then new implementors are forewarned.
Ge0rGWe might add both 49 and 223 to 0387 as well
KevBut I don't think that saying "you SHOULD use iq:private" instead of the better private pubsub mechanism is right.
Ge0rGKev: in theory, you are right. In practice, implementations of private pubsub will learn about the lack of persistence, the hard way.
jonaswKev, I agree with your second part, I disagree with the precedent this change sets
Ge0rG...of private pubsub bookmarks
danielGe0rG, more importantly the implementation you are talking about doesn't support making the node private
KevGe0rG: I am not inclined to avoid doing the Right Thing here because one (popular!) server implementation doesn't have a feature.
danielwhich arguably is the bigger issue
KevElse we end up with all our XEPs saying "But instead you need to do X for Prosody".
Ge0rGKev: apparently we can not force implementations to do anything.
jonaswI gotta run, see you later
KevI don't think I've successfully forced anyone to do anything in my life :)
Ge0rGI'm not arguing in favor of "you SHOULD use iq:private", merely pointing out that usage of iq:private is self-reinforcing.
KevIt is, certainly.
KevBut not all deployments are based on Prosody.
KevI suggest that someone proposes an additional line as I did above to 48, and we vote on that once it's done.
KevI can do that.
Ge0rGKev: please do.
Kev6) Date of next.
KevI can't do next week, and I possibly can't do anything else until the new year, at this point, but will vote on list.
KevDoes everyone else want to SBTSBC?
danielnext week works for me
SamWhitedI would like to ask that we vote on XEP-0286: Mobile Considerations for LTE Networks (or pull it in next week)
SamWhitedIt's been sitting in the proposed agendums for a few weeks
KevI only grabbed for the Agenda today what Dave'd put on it, so I've not reviewed (and assume no-one else has) 286 and trying to vote on it now would be unhelpful.
KevSo I propose I drag it to the Agenda for next week, and we look at it then.
SamWhitedWorks for me; thanks.
KevLooks like not. Thanks all.
Kevgangs the bavel
SamWhitedWould anyone complain if I removed the "For Editors" column and asked people to move them straight to the editors board's TODO column? That way editors can get alerts
SamWhitedEveryone *should* have access to the editors board if you're already on the council one
KevI think it only affects Dave and the Editors.
KevMaybe check with him, but it seems sensible to me.
SamWhited*nods* going to do it and if he doesn't like it or doesn't have access he can always unarchive it next week
Ge0rG"Dave and the Editors" sounds like an awesome name for a Punk band.
moparisthebest"and then he consulted XEP-0001 for the proper procedure, dum dum dum"