XMPP Council - 2018-02-14

[[ Ten minute warning Kev SamWhited daniel Ge0rG ]]

Thank you ten

Is it that time again?

It is indeed.

1) Roll Call

I'm here, by the way.

.o/

hi

SamWhited, Kev ?

I'm here

Kev did say he might struggle to attend.

2) Embarrassed shuffling as everyone realises it's St Valentine's Day and nobody thought to buy the Chair some nice flowers.

Did anyone?

Pfft.

🌹

*crickets*

Ge0rG, Colour me impressed.

3) Deprecate XEP-0071 XHTML-IM https://xmpp.org/extensions/xep-0071.html

+1

+1

initially I was against, but I really ended up liking Styling, and I think it will cover most use cases

+1

+1, noting that this is very specifically deprecating XHTML-IM, and not banning XHTML over XMPP in any form.

It at least provides us with a good starting point; hopefully it ends up being actually adopted, but we'll see.

Can we add Styling to the 2018 Compliance Suite now?

*2019

4) Deprecate XEP-0013 Flexible Offline Message Retrieval https://xmpp.org/extensions/xep-0013.html

SCNR.

+1, while noting that people do use this to clear history, but having a whole confusing XEP for one small feature (that clients will continue to do) seems confusing.

-1, this seems to be the only way to suppress offline messages for a MAM enabled client

So? Clients can continue to do that. If they need legacy compatibility, they will have to implement parts of deprecated XEPs, that's why it's "legacy"

SamWhited: I'm not sure since when "offline messages" is legacy.

Since MAM became widely adopted

SamWhited, It's not clear this is only useful for legacy compatibility - this seems to be the only way to do something currently desirable.

SamWhited: then MAM needs a way to suppress that legacy.

i mean existing implementations wont go away and it feels wrong to implement xep13 just for the purge

even though i was actually considering to do that for prosody

daniel: how do you handle offline messages when MAM is used?

i purge

see!

And presumably it will continue to purge even if we stop recommending that people implement this entire XEP.

my server also recently had a meltdown because a user requested 32K of messages from MAM, of which ~32K were chat states.

That seems like an unrelated problem

it is.

Anyway, I'm -1 on deprecating this. Seems like it's needed at least in part.

somebody should send a mail to standards@ asking for more discussion

im +/-0

I also think that we need to leverage the MAM-sync / carbons / session2 thing for that

I very much disagree; we'll never move on or get an alternative if we keep recommending the existing thing.

And in the mean time it's confusing and clients have to cherry-pick parts of the XEP, which feels poor.

SamWhited: so you think cherry-picking parts of a deprecated XEP is better?

SamWhited, I'm happy to say it's the old way of doing X once there's either no need to do X or if there's a more modern way.

What Dave said.

Ge0rG: no, I think encouraging us to come up with a solution is better.

We will never get a modern way unless we deprecate the old way

SamWhited: that doesn't depend on (not) deprecating 13.

SamWhited, I'd argue we'll never get a modern way unless we make a modern way.

SamWhited: apparently the old way was good enough for the last year.

We being the people in this room? Because if we don't encourage someone else to do it, we'll just end up doing everything (eg. like styling)

SamWhited: "we" being the people implementing MAM clients.

5) Deprecate XEP-0137 Publishing Stream Initiation Requests https://xmpp.org/extensions/xep-0137.html

+1

It's good enough except that there's a whole huge XEP attatched to it that people aren't using; by deprecating existing clients will continue to use it, new clients will hopefully find a new way.

What is the context for 0137 - where is it used/needed?

whats the argument for the deprecation?

SamWhited, But there isn't a new way. Which means our current recommendation would be to use the old way. :-)

XEP-0137 is SI-PUB, and its dependent on Session Initiation which we already deprecated.

Dave: we're going in circles, our current recommendation *is* to use the old way, I am trying to change that and encourage someone to come up with a new way.

+1

+1

We have this same problem and argument on almost everything; there will *never* be a new way if we keep encouraging use of the old way. In the mean time, we don't break anything by deprecating and changing our recommendation.

Deprecation, not obsoletion.

Only caveat I have with XEP-0137 is that we never duplicated this in Jingle FT. But that might be because nobody cared.

Anyway - SamWhited - XEP-0137?

+1 from me, obviously

6) Voting Reminders

But I don't understand why we think we have to have all functionality identical up front. This exact same thing happens almost every time a new replacement comes out, and it's bad policy, this is why we can never move the state of the art forward.

So obviously Kev hasn't voted on anything, but he's not here. Otherwise Ge0rG and XEP-0234 to Draft.

Dave: still working on it.

SamWhited, I don't think that's the case here.

7) AOB

It absolutely is; it was for XHTML-IM too, it means if we don't do it it will never get done because we don't put any pressure on the community and just keep confusing old alternatives around.

No, we are in the process of deprecating XHTML-IM not by creating a new XEP with identical functionality, but by ensuring the basic use-cases are still possible.

no aob from me

Apparently people had a problem they needed to solve (disable offline messages), and they found 0013.

We wouldn't have had to create a new XEP at all except that this argument was used, is my point. We could have encouraged the community to do it.

I'd like to have some more discusion regarding HTTP-Upload and custom HTTP headers.

lol

SamWhited: we are the community.

SamWhited, To put it another way, Deprecation means "No new implementations", and right now people seem to need a small chunk of XEP-0013, and no other way of doing it.

Ge0rG, Here?

Ge0rG, because we haven't been discussing this for the last five hours?

That seems perfectly fine to me; if it's a feature that's really needed, then a new XEP or a part of MAM can be added to make it work.

We are encouraging confusion and entire 0013 implementations just for one small part.

Dave, isn't the jingle counterpart of xep137 xep358?

Ge0rG, I'm basically sticking on -1 for XEP-0363 on the basis that I'm pretty sure the Security Considerations need to mention these kinds of things.

also purging is actually a pretty bad way of dealing with that

SamWhited: We are not encouraging anything at all, 0013 is just the only solution to that problem.

Flow, Good point.

i know i'm doing this myself. but it breaks stuff

We're encouraging it by having a big green "Draft" banner at the top of the XEP. That makes it our recommendation.

indeed, purging causes race conditions.

SamWhited: most people don't even understand what "Draft" actually means.

SamWhited, Right, but if it's a real problem, and this is the way we recommend solving it, I don't see a way out.

Ge0rG, not only that. it breaks stuff if your server annouces mam but your personal policy is set to never

then you purge but don't get anything from mam ✏

Yay.

SamWhited, And no, it shouldn't be up to us to create a new one. But equally, it's not up to us to try to force others to do so if people think it's good enough.

It is a real problem, because until recently if you tried to figure out how to do history with XMPP you found MAM, Archiving, and offline messages. We're now down to two, but that's not less confusing.

(i'm planning on annoucing the current mam policy in disco)

daniel: on the server or on the client?

I disagree, it's absolutely on us to put pressure on and guide the community on the technical aspects of XMPP

the account

daniel: could you also address (c) from https://mail.jabber.org/pipermail/standards/2017-November/033762.html

SamWhited, But not by just deprecating everything we don't like.

SamWhited, BTW, I'd suggest reviewing XEP-0160 as well, if you're keen to get rid of offline messages.

Ge0rG, getting stuff into 313 is a pain in the ass though

It's not about things we don't like, it's about reducing confusion. Deprecating seems like a perfectly good way to put a bit of pressure on to move in a certain way

Dave: I have that one on my list to look into as well

SamWhited, Sure, but only if there's a way to move. Otherwise I don't see that as reducing confusion.

Dave: is it too late to vote on 0234 and get that into the minutes? Or should I properly on-list my +1?

Ge0rG, Nah, go for it.

Ge0rG, You can always take on the minutes and add it yourself. ;-)

Dave: +1 to advancing 0234

There is a way to move: if there is no longer a solution, someone needs to write a new one. That seems fine to me.

Ge0rG, but i think putting the current setting in a form in the account disco would address (c)

SamWhited: people will just stick to 0013, which never was the right way to handle it anyway

daniel: essentially just removing the default value.

SamWhited, That's a way for the community as a whole to move, not for individual client developers.

Individual client developers won't drop support for 0013 overnight, you're right, and that also seems fine.

Anyways, obviously this is doing no good, I just think this argument is always used and it always bites us later.

SamWhited, Just as a note, assuming that all the other votes go through, we'll have deprecated 5 XEPs so far this session. We're doing pretty good on clearing cruft. If we're always using this argument, it's not been very effective.

So, in the closing moments:

8) Next Meeting

Mostly only because I've forced the issue again with a new council, or one of us has just done the work ourselves.

Same time next week?

+1W WFM

WFM

wfm

OK, then thanks all.

9) It, Meeting Est

Ite, even.

Look at that - squeezed under 30 minutes.

Damn, we forgot the 2018 Compliance Suite.

Thanks all

Ge0rG: what about them?

Oh, wait. They are Draft already. Everything is good.

Sorry.

Oh. We should probably deprecate any old ones that haven't been.

The last ones that were accepted were 2012 I think, and we already deprecated those last term

Unless we missed some I *think* we're good

0375 is retracted, 0302 is obsolete

Oh, good stuff.

0270 is obsolete too. Looks good to me

Although I'll note that people pushed to keep the 2012 ones around even though they were confusing and dated and it just looked terrible using the same argument of "there's no replacement yet". I don't remember how I convinced people that it just made us look bad to keep them, but it took longer than it should have. *grumble, grumble*

Sorry, dragged into meetings so couldn't be here.

Hi Kev

Kev, Did you just forget to buy me flowers?

Going to take that as a yes.

Lol.

Done some minutes.