XSF Communications Team - 2022-02-14

kikuchiyo: can you remove deprecated and obsolete xeps? Link Mauve: wurstsalat can we use his script to render a list like this? or can the PR do such a thing already?

emus: I noticed that xep 0048 is deprecated but a requirement for _advanced group chat_ https://xmpp.org/extensions/xep-0459.html#nt-idm45924173849280

Also I was wondering why there are widely adopted XEPs which are final/stable that don't show up in 0453.

> kikuchiyo: can you remove deprecated and obsolete xeps? I can provide a file without those lines. My intent to include those was to raise the question whether they should be removed from affected clients, or whether they are backward compatibilities. (That is a question for XSF and client devs.)

And what's up with XEP-0114 as a part of _core_ compliance but nobody is using or documenting it?

0114 is only for servers. clients can't implement it. ✏

I agree 0048 should probably be removed from an upcoming iteration of compliance suite, we have it there because it remains the most used method for as long as some clients won't implement 0402

final/stable doesn't imply that it's always a good idea to implement it. 0258 for example is stable, but it's a niche feature not relevant to most clients and certainly not for the public, federated XMPP network.

la|r|ma: > 0114 is only for servers. clients can't implement it. oh my bad, parsing bug.

la|r|ma: > final/stable doesn't imply that it's always a good idea to implement it. 0258 for example is stable, but it's a niche feature not relevant to most clients and certainly not for the public, federated XMPP network. Yes, but what about those widely supported like 0199, 0203 ...

0199 doesn't need to be implemented. It can be useful for connectivity checks to your server, but those can also be done in another way.

0203 is kinda implicit via 0313, could be made explicit though.

kikuchiyo, instead of directing DOAP updates to you, it’d be better to direct them to xmpp.org and for you to use it as your source of DOAP files.

You might want to add the Jingle logo to Jingle, like you added the OMEMO logo for legacy OMEMO support.

Link Mauve: ok, give me a link to include in the next pdf.

Which of the following XEPs are only for servers? 225, 386, 390, 397, 409, 433, 445

kikuchiyo, https://github.com/xsf/xmpp.org/tree/master/data contains a JSON file for each client, server and library.

If the doap field is not null, it should point to a valid DOAP file.

Note that the Content-Type is often wrong, so you’ll have to ignore it. :(

Link Mauve: thx

Link Mauve: there's a Jingle logo? (I was actually looking for something like that the other day and didn't see anything)

emus, I'm not sure there is a script involved. kikuchiyo, did you generate this table by hand?

https://upload.wikimedia.org/wikipedia/commons/8/80/JingleLogo.png

Sam, this one.

TIL; thanks!

I should have known that wikipedia would have it if it existed

kikuchiyo: did you do table with a script?

kikuchiyo: ah ok

Link Mauve: nice

kikuchiyo: https://github.com/xsf/xmpp.org/issues/1005 ✏

kikuchiyo: also note that deferred doesn't mean no one implements or that it's a bad idea, just that it missed procedural deadlines. Sometimes deferred stuff becomes stable once again later after someone champions it

Deferred is just another Experimental IMO.

We need some "Explicitly Deferred" which is not applied by time but by the fact that nobody is interested any more...

How would that be different from deferred as it is today? We could presumably explicitly move something to deferred if the author indicated they weren't interested, but whether it happens that way or after a year seems about the same.

Yeah, and explicitly deferred could still be picked up by someone else later

Really I don't look at the status at all, only if the protocol described is good and if anyone implements it

And while there xep charts are useful when doing that research, a client saying "we support xep XXX" can mean wildly different things sometimes, so you always have to actually try it

singpolyma, la|r|ma: sorry, I think I stupidly raised the to remove it. Question: wouldnt explicitly deferred be obsolete?

No, obsolete means "we do not recommend implementing this", deferred means "no one is working on this, but they might start again in the future and it might still be worth having"

ok

Obsolete is called "historical" and we all implement them anyway because... History

Also the reason for deferred could be "this works, but we somehow feel it should be improved before going to stable"

Nope, historical is a totally different thing :)

la|r|ma: no, that's experimental

Obsolete == security issue, deferred == maintainer needed, experimental == being worked on but not ready for stable, historical == documentation of a defacto standard

Sam, except if the last change is moer than a year ago

which is why I say deferred is sometimes the same as experimental

Ok, I would definitely not read obsolete as a security issue

Sure, that's just the editor forgetting to do things, it's not supposed to happen that way

deferred is definitely not maintainer needed

it's also sometimes "nobody ever really wanted that XEP"

or "we want to get more insights first"

That's the most likely reason, but sure, there are other reasons to obsolete something. If I'm generalizing though that's the way to think about it if you're not going to actually go dig in and figure out why.

No, it's neither of those, deferred is just "maintainer needed".

Possibly maintainer is needed because no one wants the xep and so no maintainer will be found

Or rather, it's not necessarily "needed" just "no maintainer" if you want to be pedantic. The point is that deferred XEPs *might* be wanted and maintained again in the future

And it's definitely not "we want to get more insights first" unless it's just a mistake and the editor needs to mark it as deferred.

At least, not primarily. These things aren't mutually exclusive.

There is a number of deferred XEPs where someone designed the spec, everybody agrees it's probably good as is, but nobody implemented it so nobody is really certain. There is no lack of maintainer in those cases.

Sure, it can be "we want to get more insight" but then the author leaves so it goes to deferred and it's both.

Sam: I think the point is that defferred is "expired experimental" so it could mean anything experimental means

The XEP author is not always a developer

Yeah, XEPs getting published with numbers before there are two implementations is an issue

Fair enough; maybe I'm wrong, after all these years writing XEPs the XSF process still seems obtuse and confusing to me, so it's quite possible.

Maybe check your own XEPs that are deferred and see if they are deferred because you don't want to maintain them or if there is another reason

They are deferred because I wasn't maintaining them.

I think we're covering two perspectives here. I think that from a procedural / author / XSF perspective deferred of course means "no maintianer" but that's not the information a XEP reader needs or cares about so they will try to infer a more useful status like "fine but abandoned" vs "needs work" vs "being used in the wild but no one cared to bump the xep"

Okay guys - Let's move the discussion to xsf@ best I think 🙂

Sorry :)

No need to be sorry. Please dont feel disencouraged :)

I invite to collaborate the review of the GSoC applications text within the next 24hrs. PLEASE use the comment function ONLY and do not edit directly: https://yopad.eu/p/xsf_gsoc2022 See top bar.

emus: I have to send the PR with the ES translation ... Didnt have time to finish it yet 🥺

no worries, take your time