XMPP Council - 2017-12-06

'tis time, 'tis time.

the harpie cries

1) Bread products!

I gotta leave at 1630Z, so I won’t be able to properly take minutes

jonasw: I can do minutes, it's ok ta.

Dave sends apologies. daniel, Ge0rG, SamWhited - you here?

two out of those have spoken in other MUCs just a few minutes ago :)

I'm here

hi

2) 186 LC

I'm +1

(This is a re-issue because the last one expired without Council voting)

What are we voting on?

Oops, too slow

I don't think we have to vote on this; editor will just reissue the LC

(but +1 FWIW)

+1 for LC

I think that's right, as it happens.

+1

editor will take notice that this is the councils opinion and re-issue the LC sometime tomorrow, maybe tonight (or somebody besides me does it)

And same for

3) 352 LC

jonasw: More than Council's opinion, it's what xep1 says :)

4) Deprecating 84

Kev, we could also simply move it back to experimental, couldn’t we?

No, xep1 says that if there's a vote that wasn't completed, the Editors will re-issue an LC.

ah okay

So, deprecating '84, which I think was Link Mauve's request.

(That's pubsub avatars, for anyone who needs to know)

has there been any argument on why?

I haven't yet compared pubsub avatars to vcard avatars, so I'm impartial.

It just appeared on the Council board without an argument why.

IIRC, the argument was "vcard works today" ✏

Link Mauve can probably say why, though.

jonasw: weren't there special cases where vcard doesn't work in MUCs?

Ge0rG: none that PEP does work in, I think.

I'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.

0153 is Historical already.

Indeed, deprecating 153 is likely not the right thing to do.

I 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.

I'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.

No, I mean that a Historical XEP doesn't need deprecating, because of its nature :)

(Although we can do so, certainly)

SamWhited: which are the two? 84 and 153?

Ge0rG: Yes

SamWhited: and where are we recommending 153?

(and for what reasons)

and the other two :-)

It's got a big green block of text that says "This is draft" at the top

Ge0rG: We're not, but it's the de facto standard.

(which I learnt the hard way which I find annoying)

Anyway, with one -1 in place, let's gather votes for this and move on.

-1

387 goes with 84, so it might be not smart to deprecate it.

Sounds good; I'll discuss on list if necessary.

SamWhited: "sounds good" is voting which way?

Same question for contestant number Ge0rG.

-1 for now, until reasons for deprecation are provided

Kev: "let's move on" sounds good, I mean. On list.

Ta.

5) Reverting 48 to 49

That's reverting bookmarks to iq:private instead of private pubsub.

is there an argument on why?

I'm not sure why this one was brought up either; is there a problem with them as they are today?

This isn't a voting point, because there's no vote to be made.

I did

But let's discuss.

the 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

which is indiscoverable to new developers

jonasw: So it's a point of process?

no, also a point of usability by developers

I think deployments are on private XML because some major XMPP server implementations lack persistent PEP.

I think 'indiscoverable' is pushing it a bit, when the XEP says this explicitly.

so the point is, as a new developer, you see the XEP, you think "neat, PEP", implement it, and find no bookmarks

I 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.

I agree that it is a better mechanism.

jonasw: Except you wouldn't, because the XEP notes that people used to do iq:private.

"used to do" implies that it isn’t that way anymore

and also, only read access isn’t sufficient, because there are enough clients and servers out there which still can only do private XML

So maybe we should extend 48 with a compat behavior spec?

0387 does not enforce the type of backend storage.

I 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.

We might add both 49 and 223 to 0387 as well

But I don't think that saying "you SHOULD use iq:private" instead of the better private pubsub mechanism is right.

Agreed

Kev: in theory, you are right. In practice, implementations of private pubsub will learn about the lack of persistence, the hard way.

Kev, I agree with your second part, I disagree with the precedent this change sets

...of private pubsub bookmarks

Ge0rG, more importantly the implementation you are talking about doesn't support making the node private

Ge0rG: I am not inclined to avoid doing the Right Thing here because one (popular!) server implementation doesn't have a feature.

which arguably is the bigger issue

Else we end up with all our XEPs saying "But instead you need to do X for Prosody".

Kev: apparently we can not force implementations to do anything.

I gotta run, see you later

I don't think I've successfully forced anyone to do anything in my life :)

Thanks Jonas.

I'm not arguing in favor of "you SHOULD use iq:private", merely pointing out that usage of iq:private is self-reinforcing.

It is, certainly.

But not all deployments are based on Prosody.

I suggest that someone proposes an additional line as I did above to 48, and we vote on that once it's done.

I can do that.

Kev: please do.

Moving on

6) Date of next.

I 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.

Does everyone else want to SBTSBC?

WFM

+1W WFM

daniel?

next week works for me

7) AOB

I would like to ask that we vote on XEP-0286: Mobile Considerations for LTE Networks (or pull it in next week)

It's been sitting in the proposed agendums for a few weeks

I 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.

So I propose I drag it to the Agenda for next week, and we look at it then.

Works for me; thanks.

Anything else?

Looks like not. Thanks all.

Thanks Kev

Thanks Kev

Would 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

Everyone *should* have access to the editors board if you're already on the council one

I think it only affects Dave and the Editors.

Maybe check with him, but it seems sensible to me.

*nods* going to do it and if he doesn't like it or doesn't have access he can always unarchive it next week

"Dave and the Editors" sounds like an awesome name for a Punk band.

sounds boring

"and then he consulted XEP-0001 for the proper procedure, dum dum dum"

it sounds like blues in my brain

https://github.com/xsf/xeps/pull/554 - 48 patch.

Kev: 👍