SamWhitedIt'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.
Ge0rGWhat is the context for 0137 - where is it used/needed?
danielwhats the argument for the deprecation?
DaveSamWhited, But there isn't a new way. Which means our current recommendation would be to use the old way. :-)
DaveXEP-0137 is SI-PUB, and its dependent on Session Initiation which we already deprecated.
SamWhitedDave: 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.
SamWhitedWe 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.
SamWhitedDeprecation, not obsoletion.
DaveOnly caveat I have with XEP-0137 is that we never duplicated this in Jingle FT. But that might be because nobody cared.
DaveAnyway - SamWhited - XEP-0137?
SamWhited+1 from me, obviously
Dave6) Voting Reminders
SamWhitedBut 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.
DaveSo obviously Kev hasn't voted on anything, but he's not here. Otherwise Ge0rG and XEP-0234 to Draft.
Ge0rGDave: still working on it.
DaveSamWhited, I don't think that's the case here.
SamWhitedIt 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.
DaveNo, 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.
danielno aob from me
Ge0rGApparently people had a problem they needed to solve (disable offline messages), and they found 0013.
SamWhitedWe 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.
Ge0rGI'd like to have some more discusion regarding HTTP-Upload and custom HTTP headers.
Ge0rGSamWhited: we are the community.
DaveSamWhited, 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.
danielGe0rG, because we haven't been discussing this for the last five hours?
SamWhitedThat 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.
SamWhitedWe are encouraging confusion and entire 0013 implementations just for one small part.
FlowDave, isn't the jingle counterpart of xep137 xep358?
DaveGe0rG, 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.
danielalso purging is actually a pretty bad way of dealing with that
Ge0rGSamWhited: We are not encouraging anything at all, 0013 is just the only solution to that problem.
DaveFlow, Good point.
danieli know i'm doing this myself. but it breaks stuff
SamWhitedWe're encouraging it by having a big green "Draft" banner at the top of the XEP. That makes it our recommendation.
Ge0rGindeed, purging causes race conditions.
Ge0rGSamWhited: most people don't even understand what "Draft" actually means.
DaveSamWhited, Right, but if it's a real problem, and this is the way we recommend solving it, I don't see a way out.
danielGe0rG, not only that. it breaks stuff if your server annouces mam but your personal policy is set to never
danielthen you purge but don't get anything from ma✎
danielthen you purge but don't get anything from mam ✏
DaveSamWhited, 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.
SamWhitedIt 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)
Ge0rGdaniel: on the server or on the client?
SamWhitedI disagree, it's absolutely on us to put pressure on and guide the community on the technical aspects of XMPP
Ge0rGdaniel: could you also address (c) from https://mail.jabber.org/pipermail/standards/2017-November/033762.html
DaveSamWhited, But not by just deprecating everything we don't like.
DaveSamWhited, BTW, I'd suggest reviewing XEP-0160 as well, if you're keen to get rid of offline messages.
danielGe0rG, getting stuff into 313 is a pain in the ass though
SamWhitedIt'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
SamWhitedDave: I have that one on my list to look into as well
DaveSamWhited, Sure, but only if there's a way to move. Otherwise I don't see that as reducing confusion.
Ge0rGDave: is it too late to vote on 0234 and get that into the minutes? Or should I properly on-list my +1?
DaveGe0rG, Nah, go for it.
DaveGe0rG, You can always take on the minutes and add it yourself. ;-)
Ge0rGDave: +1 to advancing 0234
SamWhitedThere is a way to move: if there is no longer a solution, someone needs to write a new one. That seems fine to me.
danielGe0rG, but i think putting the current setting in a form in the account disco would address (c)
Ge0rGSamWhited: people will just stick to 0013, which never was the right way to handle it anyway
Ge0rGdaniel: essentially just removing the default value.
DaveSamWhited, That's a way for the community as a whole to move, not for individual client developers.
SamWhitedIndividual client developers won't drop support for 0013 overnight, you're right, and that also seems fine.
SamWhitedAnyways, obviously this is doing no good, I just think this argument is always used and it always bites us later.
DaveSamWhited, 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.
DaveSo, in the closing moments:
Dave8) Next Meeting
SamWhitedMostly only because I've forced the issue again with a new council, or one of us has just done the work ourselves.
DaveSame time next week?
DaveOK, then thanks all.
Dave9) It, Meeting Est
DaveLook at that - squeezed under 30 minutes.
Ge0rGDamn, we forgot the 2018 Compliance Suite.
SamWhitedGe0rG: what about them?
Ge0rGOh, wait. They are Draft already. Everything is good.
DaveOh. We should probably deprecate any old ones that haven't been.
SamWhitedThe last ones that were accepted were 2012 I think, and we already deprecated those last term
SamWhitedUnless we missed some I *think* we're good
Ge0rG0375 is retracted, 0302 is obsolete
DaveOh, good stuff.
Ge0rG0270 is obsolete too. Looks good to me
SamWhitedAlthough 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*
KevSorry, dragged into meetings so couldn't be here.