XMPP Council - 2018-04-11

Do we have agenda for today?

the proposal to write 2 MUC PRs I think

the vote on whether someone should bother writing the PRs specifically :)

Pretty sure im-ng should be on there too.

Or should have been last week, but wasn't.

Kev, I've been busy, I do apologise. I'll knock this out. FWIW, im-ng was fractionally too late for last week, IIRC. Unless I'm thinking of the week before, and just forgot last week.

The latter.

+1 for the latter because I’m fairly certain that I didn’t do any editor work last week

Oh. Whoops.

Right, time.

Think so.

1) Roll Call

hi

🙋

SamWhited, ?

2) Agenda Bashing

So I've not managed to do an Agenda this week, for which I apologise.

I would love to bash an Agenda.

I think we have two CFEs, Kev's IM-NG protoXEP, and... anything else?

.oO(piñarta agenda?)

Dave, the GC1.0 abolishment vote

Oh, yes, of course.

I also have a proposal for MUC self-ping

i want to register the muc config option for mam

or at least get the process going / clarify what the process is exactly

OK - I'm going to guess that between the protoXEP, CFEs, and GC-1.0 we'll probably fill the half hour, but we'll see.

sorry, I'm here

No need to be sorry.

Dave: 3) minute taker?

Ge0rG, Good plan.

3) Minute Taker

Either Tedd Sterr will do it or else I will.

It looks like the abolition of Pidgin is a Board agendum now.

:-)

<https://github.com/xsf/xmpp.org/pull/425>

,oO(can you just get rid of pidgin be removing session support on the server?)

daniel: it will probably break other clients as well

Right, bear with me while I figure out which CFEs have completed.

Dave, 0131, 0141, 0229 AFAICT

jonasw, Thanks.

So with that:

(provided you already voted on 0092 and 0122)

4) Advance XEP-0131 to Final

jonasw, Yes, we did.

good

This one is SHIM, BTW.

-1, doesn't have the implementations (and other reasons).

Also -1, this doesn't feel like it fits a need in the ecosystem and doesn't have the implementations. We should kill it instead.

I'm going to vote on-list for all of these, I warn in advance - however, in the case of SHIM I can't help feeling I'd *like* to ditch it but it's referred to by other XEPs.

isn’t it used by PubSub?

jonasw, Pubsub and XEP-0149.

i actually implemented this once. but i feel like this is so niche that who ever needs it can just make up their own syntax and/or use the deprecated one. so -1

I've had a tough fight against generic headers in 0363. -1

5) Advance XEP-0141 to Final

Data forms layout, BTW.

-1 doesn't have the implementations

is that referenced from others as well?

Ge0rG, Nope. I've seen it used, though, in XEP-0346 implementations.

-1

-0

I'd like to advance 141, but we didn't have the numbers in the CfE, that I saw.

Someone tell me I'm wrong, by all means.

-1, same reason as Kev, but also think forms is too complex already and we don't need to shoehorn layout information into the document structure.

5) Advance XEP-0229 to Final

LZW stream compression

I do have a vote for this: -1 for implementations and also I don't see a driving need for it.

I have used this and have implementations, but it's underspecified so -1.

-1

0

-1 for the security issues of mixing different data classes into a compressed stream

Ge0rG, that argument applies to compression in general though?

not to that particular xep

Either way, we need to figure out what we're doing with 0138 and then this should probably just follow whatever happens with that.

daniel: it applies to compression in general and thus to this XEP by extension

6) Adopt "IM Routingng"

ProtoXEP: https://xmpp.org/extensions/inbox/im-ng.html

This is clearly going to need to adapt as we make further decisions, but I'd like to get it under XSF control.

How could I have missed that submission? on-list

So I'm +1.

Ge0rG, I'm just saying it feels 'unfair' to punish the lzw xep instead of 138

I worry that this might end up the bike shed of bike sheds, but I'm not going to veto, so 0.

daniel: I agree. Please put 0138 on the next agenda.

Dave: It might, but I think it's something we have to work on, and there was reasonable (not particularly rough) consensus at the Summit, I think.

+1 to get it under xsf control. but i'm not really sure i like it in it's current form

I've heard somebody gave a speech, or somesuch.

+1

daniel: Sure, that's fine (not liking the current form) - but I thought step one was getting some words down that people can disagree with.

7) Kill GC-1.0

Kev, "Get a number". :-)

obviously +1

I am, in principle, ok with removing gc1 from 45, but only if we can do so in a way that makes everything better.

link to pr?

daniel: There's no PR, this is just raising the idea up a flagpole and seeing who salutes.

daniel, There's no PR, so this is a vote on the principle.

i.e. this is a vote on position, rather than standards advancement.

I promise to prepare a PR if this vote is accepted. Although I don't promise *when* I will be able to submit it.

I am tentatively +1 on the general idea; can't hurt to see a PR either way.

I'm fine with seeing a PR, and if you *can* produce one that doesn't break anything I'll be ok with it, but I think that's a big ask and I'm not sure it's possible.

I'm fine with removing "bare" presence as a mechanism for joining a chatroom. However, I worry about what existing clients would do is they fall out of sync and *inadvertantly* join using GC-1.0, and have that then perform a different action.

We have ~two weeks worth of numbers from prosody.im and yax.im, showing that there was only one client not supporting MUC protocol

Ge0rG, Right, but that is a different problem to the one I outline.

Ge0rG: Yes, that's why I'm in principle ok with the idea, as long as it can be done such that nothing existing breaks.

Dave: yes. My position is that it's better to uncover to the user that they were gone than to silently re-join a MUC and probably missing a part of history.

Ge0rG, In any case, I think I'm keen to see what this would do in practise, so +1 to someone else writing a PR. :-)

+1

Ge0rG, Ah. So yes. But that presumes a client will gracefully handle an unexpected join rejection to a presence stanza they didn't think was a join in the first place.

Dave: I hope that sane clients will handle a presence error from a MUC as "you are not there anymore"

Ge0rG, As such, when I see what you're aiming to do, it might nudge me into a couter-proposal.

Ge0rG, That is extremely optimistic of you. Possibly right, too. But certainly optimistic.

Dave: I don't have a proposal beyond what I wrote on standards@

Dave: I'm not sure I'm sane enough to fix insane clients. Nor that I want to volunteer my sanity for that goal.

Ge0rG, Sure. But it might be fun to trial any change and see what clients do.

Kev: I'm not sure whether your position boils down to a -1 essentially, because I can't fix what is broken with MUCs getting out of sync, and GC1 is just a cover-up for it.

Anyway, as I say, I'm in favour of doing this given your evidence thus far.

Ge0rG: I am trying to be open that I think it's an impossible job, while not wanting to stop you trying if you're convinced you can.

Kev: I'm pretty sure I can't fulfill your requirement. And I still think that it's based on a flawed assumption

SamWhited, I don't think I have a vote from you on this one.

My requirement basically being that it's a Draft XEP so we shouldn't break anything that's currently deployed against it?

> I am tentatively +1 on the general idea; can't hurt to see a PR either way.

SamWhited, Oh, sorry - just spotted that.

I think it'll come down to what breaks and where.

Kev: do you consider sending an error to non-joined clients a "break"?

So we're unanimously in favour of Georg writing a PR we can vote on. :-)

Ge0rG: Maybe, depending how clients react to it.

If all clients do a sensible thing, I can probably be talked into it.

Kev: Alright. Could you please perform a study of the clients that you care about?

Not likely.

I mean, realistically we'll have to reduce the subset of clients.

Ge0rG, I know I don't have access to all the clients I'd want to know about.

I suggest we test all clients that comply with this year's Compliance Suite.

lol

Ge0rG, I don't know how clients I actually work with would react.

Anyway, we've voted, so:

8) AOB

whats the process for registering a new muc config option?

can we take a vote and order the registry to include it?

I'd like to put the MUC self-ping suggestion up for a vote-on-principle ✏

The one from here: https://mail.jabber.org/pipermail/standards/2018-April/034763.html

(since changing the xep45 has been rejected by council members who still serve this year)

daniel, Do you know, I've actually no idea. I'll look into the process. I'd expect it's a matter of "document it".

This one is at least less probable to break all clients.

daniel, I don't think "changing xep45" is quite the same as "adding a new option". Servers add new options all the time, so unless it's changing existing behaviour, a XEP defining the additional behaviour should be uncontentious.

Ge0rG, Looks fine to me. Feels like it could be documented in a new XEP, too.

Dave: what's wrong with adding a use-case into 0045?

I'm fine with adding a self-ping to MUC to check you're there. I'm not ok with intercepting 199 pings to users and replying from the server.

Kev: not to users, to yourself.

Kev, Not to users, to occupants.

Kev, You already have to implement vcard IQs, after all.

Only to your own occupant JID might be ok.

i'm ok with specifying that a ping to self should be handled (and responded to) by the server

9) Next Meeting

Same time next week?

WFM

WFM

wfm

WFM

10) Ite, Meeting est

The self-ping-to-occupant was the only useful and O(1) way for a client to check whether it's still joined, anyway.

Once again, sorry for the disorganised lack of agenda,, and thanks for bearing with me.

Dave: next time we expect an organised lack of agenda

Thanks all.

Thanks!

> I don't think "changing xep45" is quite the same as "adding a new option". Servers add new options all the time, so unless it's changing existing behaviour, a XEP defining the additional behaviour should be uncontentious. well you vetod https://github.com/xsf/xeps/pull/204 last time. that’? what i meant by 'changing the xep'

(re config option for muc)

so apparently this is not the right way to do it

would you like me to create a full new xep just for this config option?

That was a long time ago, no wonder I'd forgotten.

i would just like to find the 'correct way' and then just do it. instead of bike shedding it to death again

daniel, Registry is at https://xmpp.org/registrar/formtypes.html#http:--jabber.org-protocol-mucroomconfig and the submission process is https://xmpp.org/extensions/xep-0068.html#registrar-reg-formtypes-process

and it's up to the registrar to decide whether to accept this?

daniel, appears so