+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.
Ge0rG
-1, this seems to be the only way to suppress offline messages for a MAM enabled client
SamWhited
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"
Ge0rG
SamWhited: I'm not sure since when "offline messages" is legacy.
SamWhited
Since MAM became widely adopted
Dave
SamWhited, It's not clear this is only useful for legacy compatibility - this seems to be the only way to do something currently desirable.
Ge0rG
SamWhited: then MAM needs a way to suppress that legacy.
daniel
i mean existing implementations wont go away and it feels wrong to implement xep13 just for the purge
daniel
even though i was actually considering to do that for prosody
Ge0rG
daniel: how do you handle offline messages when MAM is used?
daniel
i purge
Ge0rG
see!
SamWhited
And presumably it will continue to purge even if we stop recommending that people implement this entire XEP.
Ge0rG
my server also recently had a meltdown because a user requested 32K of messages from MAM, of which ~32K were chat states.
Davehas left
SamWhited
That seems like an unrelated problem
Ge0rG
it is.
Dave
Anyway, I'm -1 on deprecating this. Seems like it's needed at least in part.
Ge0rG
somebody should send a mail to standards@ asking for more discussion
daniel
im +/-0
Ge0rG
I also think that we need to leverage the MAM-sync / carbons / session2 thing for that
SamWhited
I very much disagree; we'll never move on or get an alternative if we keep recommending the existing thing.
SamWhited
And in the mean time it's confusing and clients have to cherry-pick parts of the XEP, which feels poor.
Ge0rG
SamWhited: so you think cherry-picking parts of a deprecated XEP is better?
Dave
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.
Ge0rG
What Dave said.
SamWhited
Ge0rG: no, I think encouraging us to come up with a solution is better.
SamWhited
We will never get a modern way unless we deprecate the old way
Ge0rG
SamWhited: that doesn't depend on (not) deprecating 13.
Dave
SamWhited, I'd argue we'll never get a modern way unless we make a modern way.
Ge0rG
SamWhited: apparently the old way was good enough for the last year.
SamWhited
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)
Davehas left
Ge0rG
SamWhited: "we" being the people implementing MAM clients.
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.
Ge0rG
What is the context for 0137 - where is it used/needed?
daniel
whats the argument for the deprecation?
Dave
SamWhited, But there isn't a new way. Which means our current recommendation would be to use the old way. :-)
Tokodomohas joined
Dave
XEP-0137 is SI-PUB, and its dependent on Session Initiation which we already deprecated.
SamWhited
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.
daniel
+1
Ge0rG
+1
SamWhited
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.
SamWhited
Deprecation, not obsoletion.
Dave
Only caveat I have with XEP-0137 is that we never duplicated this in Jingle FT. But that might be because nobody cared.
Dave
Anyway - SamWhited - XEP-0137?
SamWhited
+1 from me, obviously
Dave
6) Voting Reminders
SamWhited
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.
Dave
So obviously Kev hasn't voted on anything, but he's not here. Otherwise Ge0rG and XEP-0234 to Draft.
Davehas left
Ge0rG
Dave: still working on it.
Dave
SamWhited, I don't think that's the case here.
Dave
7) AOB
SamWhited
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.
Dave
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.
daniel
no aob from me
Ge0rG
Apparently people had a problem they needed to solve (disable offline messages), and they found 0013.
SamWhited
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.
Ge0rG
I'd like to have some more discusion regarding HTTP-Upload and custom HTTP headers.
daniel
lol
Ge0rG
SamWhited: we are the community.
Dave
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.
Dave
Ge0rG, Here?
daniel
Ge0rG, because we haven't been discussing this for the last five hours?
Davehas left
SamWhited
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.
SamWhited
We are encouraging confusion and entire 0013 implementations just for one small part.
Flow
Dave, isn't the jingle counterpart of xep137 xep358?
Dave
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.
daniel
also purging is actually a pretty bad way of dealing with that
Ge0rG
SamWhited: We are not encouraging anything at all, 0013 is just the only solution to that problem.
Dave
Flow, Good point.
daniel
i know i'm doing this myself. but it breaks stuff
SamWhited
We're encouraging it by having a big green "Draft" banner at the top of the XEP. That makes it our recommendation.
Ge0rG
indeed, purging causes race conditions.
Ge0rG
SamWhited: most people don't even understand what "Draft" actually means.
Dave
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.
daniel
Ge0rG, not only that. it breaks stuff if your server annouces mam but your personal policy is set to never
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.
SamWhited
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.
daniel
(i'm planning on annoucing the current mam policy in disco)
Ge0rG
daniel: on the server or on the client?
SamWhited
I disagree, it's absolutely on us to put pressure on and guide the community on the technical aspects of XMPP
daniel
the account
Ge0rG
daniel: could you also address (c) from https://mail.jabber.org/pipermail/standards/2017-November/033762.html
Dave
SamWhited, But not by just deprecating everything we don't like.
Dave
SamWhited, BTW, I'd suggest reviewing XEP-0160 as well, if you're keen to get rid of offline messages.
daniel
Ge0rG, getting stuff into 313 is a pain in the ass though
SamWhited
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
SamWhited
Dave: I have that one on my list to look into as well
Dave
SamWhited, Sure, but only if there's a way to move. Otherwise I don't see that as reducing confusion.
Ge0rG
Dave: is it too late to vote on 0234 and get that into the minutes? Or should I properly on-list my +1?
Dave
Ge0rG, Nah, go for it.
Dave
Ge0rG, You can always take on the minutes and add it yourself. ;-)
Ge0rG
Dave: +1 to advancing 0234
SamWhited
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.
daniel
Ge0rG, but i think putting the current setting in a form in the account disco would address (c)
Ge0rG
SamWhited: people will just stick to 0013, which never was the right way to handle it anyway
Davehas left
Ge0rG
daniel: essentially just removing the default value.
Dave
SamWhited, That's a way for the community as a whole to move, not for individual client developers.
SamWhited
Individual client developers won't drop support for 0013 overnight, you're right, and that also seems fine.
SamWhited
Anyways, obviously this is doing no good, I just think this argument is always used and it always bites us later.
Dave
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.
Dave
So, in the closing moments:
Dave
8) Next Meeting
SamWhited
Mostly only because I've forced the issue again with a new council, or one of us has just done the work ourselves.
Dave
Same time next week?
Ge0rG
+1W WFM
SamWhited
WFM
daniel
wfm
Dave
OK, then thanks all.
Dave
9) It, Meeting Est
Dave
Ite, even.
Dave
Look at that - squeezed under 30 minutes.
Ge0rG
Damn, we forgot the 2018 Compliance Suite.
SamWhited
Thanks all
SamWhited
Ge0rG: what about them?
Ge0rG
Oh, wait. They are Draft already. Everything is good.
Tokodomohas left
Ge0rG
Sorry.
Davehas left
Dave
Oh. We should probably deprecate any old ones that haven't been.
SamWhited
The last ones that were accepted were 2012 I think, and we already deprecated those last term
SamWhited
Unless we missed some I *think* we're good
Ge0rG
0375 is retracted, 0302 is obsolete
Dave
Oh, good stuff.
Ge0rG
0270 is obsolete too. Looks good to me
SamWhited
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*