ZashHasn't the namespace changed a bunch of times already?
jonas’I think namespace bump is exactly the tool for that
dwdI'm not against the PR, incidentally. i just have no feel for what the community feels as a whole.
jonas’we cannot force folks to give feedback though
jonas’we could poke some known server devs for sure
danielthe general vibe i'm getting (not from the PR but from talks I had before that PR came to be) that those changes are welcome and long overdue
dwdWe can't force feedback, but it'd be nice to get some support for changing a Draft XEP.
jonas’daniel: vibe from whom?
danielon conversations.im for example we have talked about offering import/export to users (especially but not limited to our domain users)
danielbut that has always been held back by 277 not being 'modern' enough
danieland that PR fixes exactly the problems we had with 227
jonas’I prefer an unopposed and unsupported change on a Draft XEP over yet another experimental rewrite XEP
jonas’daniel: those words would have been great on the list
dwdjonas’, Yes, we don't want a rewrite.
dwdBut words of support from the ejabberd folks, and/or Openfire, would be great.
jonas’maybe we can poke Holger or so
jonas’we need to re-vote anyway
jonas’so I suggest we do that and poke folks on list in parallel?
dwdI have poked Guus, for Openfire.
jonas’or do we want to poke first and vote thereafter, ignoring that there was lots of time already?
dwdWe can [re]vote next week regardless.
jonas’let us do that then
jonas’I think we can move on then
jonas’(I poked Holger)
jonas’has anyone got any?
SamI poked editor for a LC on vcard4. Just a heads up.
jonas’(also for the reminder)
SamAlso I request that council obsolete SOAP over XMPP at their earliest convenience.
jonas’8) Ite Meeting Est
dwdSam, I'm not sure we should, it's still quite important with COVID.
Samdwd: I'm unsure if that was a joke or if all these aweful contact tracing sites are actually using SOAP :)
danieli was trying to look up a suitable badum tss gif
dwdIt was a joke until you put that thought in my head...
SamIt wouldn't suprise me either way :)
SamAs someone else said when this came up recently, I'm very disapointed in that joke, go wash your mouth out with… some old protocol.
SamAnyways, jokes aside, please discuss at your earliest convenience. I would like it to not be on the list of XEPs if possible.
dwdIt might actually be useful to have a state other than Deprecated or Obsolete for things like SOAP/XMPP. I mean, ifsomeone actually wanted to do SOAP over XMPP, it's a perfectly good way of doing it, but I agree we don't want it cluttering the list.
SamMaybe we need a new category for "technically this is still a fine way to do this, but don't do this"
Samoops, yes, that
dwdGreat minds think alike, whilst fools seldom differ, etc.
SamWe could move it to Historical and turn that off by default (if it's on, I forget)
Samoh wait, that's a category not a state, or something
dwdHistorical unfortunate is a track and carries a bunch of other semantics.
SamI guess some of the historical ones like private XML are actually common and should be on the list too, so nevermind
dwdYes. "Historical" means "GRandfathered into our standards process from The Great Before"
dwdWHat we want is an "Archived" status, or something.
SamMaybe just deprecated is fine. No longer in wide use because there are more modern protocols. They don't directly supersede SOAP over XMPP, but as SOAP is more or less superseded it seems like it more or less matches.
Sam"New implementations not encouraged" being the important part
SamAlthough having an archive status also sounds good
HolgerAs for 0227, ejabberd relies on its internal stanza ID format, so supporting MAM import would require adding another column. But I see no way around this.
dwdHolger, On the list, please!
HolgerAlso, not sure anything should be added to 0227 in order to support MIX roster entries? But maybe not. (Or maybe just a sentence mentioning the issue of MIX and/or generally unsupported childs ...)
HolgerYeah, well, I had seen the posting, figured I have no noteworthy feedback, and now got poked to give it nevertheless :-)
Zashdwd, Sam: Maybe it would be better to put more focus on the compliance suites, rather than getting rid of XEPs with obscure but valid use cases?
dwdThat is, also, a reasonable idea.
SamI do agree we need a better process / more focus on the compliance suites, but I still think having old things like this in the list just looks bad
jonas’I agree with Zash on that
SamAlthough I don't know how we'd add "Archive" at this point. Replace 0001? Can a new XEP modify the procedure w/o being the whole thing again?
jonas’we can update 1 without replacing
SamIf I'm considering proposing those changes to 0001 anyways, would it make sense to also let you go straight from Final to Obsolete without the awkward "vote to deprecate first"? It makes the graphs easier to draw and it's not as if we don't already do that anyways
SamThat's not true, the graphs are hard to draw either way (or I'm just bad at this). Maybe this isn't a good idea because this state machine is already too complicated.
jonas’I don't see a problem with the deprecate+obsolete vote, we can do it in one batch
SamOkay, quick PR submitted anyways to help start discussion.
SamI suppose one could argue that this could also just be a website change and doesn't require an XEP change
SamIe. there's an archive section you can filter on but its full of final and historical XEPs or whatever state they were in
SamJust "stuff we don't think is really useful anymore"
KevYou can set such a filter already, I think - but calling it out in a helpful way (possibly a preset) seems useful.
stpeterHaving read the scrollback, I do wonder if Deprecated or Obsolete is actually what we want for something like SOAP over XMPP. One hopes that SOAP is obsolete at this point. I'm not sure we need a new Archived state (IMHO developers might not be clear on the difference between Archived and the states we have now).
stpeterBut I can reply on the standards@ list if there's a thread (I don't see one at the moment).
Kev> But words of support from the ejabberd folks, and/or Openfire, would be great
I’m sure there are other servers too...
SamI tend to think Obsolete or Deprecate is fine too, but as long as *something* happens to it (and probably others, it just seemed like an uncontrovoersial one to start) I'm happy.
SamI agree that Archived might just be confusing.
stpeterNow, we do have this thing about moving from Final to Deprecated to Obsolete and perhaps folks don't like the two-step process, but that's how things are defined and it gives developers plenty of warning.
jonas’yay, back on a real keyboard
jonas’Sam, so my take on SOAP over XMPP is that even if SOAP is deprecated or whatever, that’s no reason to deprecate that on our side. It is still a valid (albeit probably niche) use case and you can still do it and it doesn’t cause harm to have it specified. Obsoleting or Deprecating it makes no sense to me.
jonas’Kev, are there other servers which (whose users) are interested in migrating individual users between services? If so, there is a thread on list which went completely silent from those servers ;)
KevNot individual users, no, but we do support 227 both in and out.
SamThe harm is political, not technical. Everyone thinks XMPP is some dead outdated technology and having "SOAP over XMPP" on the main page you go to when you're trying to figure out what XMPP things to do doesn't help.
SamBut I agree there's no harm in leaving it specified if we could hide it away in the "not actually useful anymore" page somehow.
KevAlthough we don’t do the user password bit any more.
jonas’Sam, if new users go to the full list of XEPs to figure out what to do, that’s really wrong and *that* is what we need to fix
jonas’Kev, on-list feedback is then surely appreciated
jonas’(even if it is just "lets do that")
SamI agree with that too but to a certain extent that's always what people are going to do so we might as well fix both problems.
KevI think obsoleting SOAP over XMPP is fine, personally. SOAP is obsolete.