XMPP Council - 2024-10-29

Heads up: depending on where in the world you are our meeting may or may not be an hour earlier today

It’s time

1) Roll call

👋

moparisthebest, singpolyma, dan.caseley ping

Hello!

I'm still travelling back and haven't read the agenda. Sorry folk - will catch up in a few hours.

2) Agenda bashing

I would like to add voting on 'Pubsub Extended Subscription' to the agenda

I somehow missed this when writing the agenda

3) Editors update

* UPDATED: XEP-0394 (Message Markup) * UPDATED: XEP-0491 (WebXDC) * Proposed XMPP Extension: Pubsub File Sharing * Proposed XMPP Extension: Pubsub Extended Discovery

and the previously mentioned Pubsub Extended subscription

4) Items for voting

a) Proposed XMPP Extension: Pubsub File Sharing https://xmpp.org/extensions/inbox/pubsub-file-sharing.html

+1

on-list

+1

b) Proposed XMPP Extension: Pubsub Extended Discovery https://xmpp.org/extensions/inbox/pubsub-extended-discovery.html

+1

+1

oh shit the hour bit me even with wraning

extended discovery +1

file sharing I posted most of my concerns to the list

> file sharing I posted most of my concerns to the list Hi, have you seen my reply? ↺

singpolyma, what does that mean vote wise?

goffi: yes I was just starting to read it when I realized it is meeting time

I'm very concerned about the proliferation here. We have yet another xep, using today's fad syntax, which I have no doubt will see a very solid implementation in libervia but if no one else does then the next author will get to say "well that didn't see much adoption" and submit *yet another*... why can't we fix one of the several existing ones rather than assign yet another competing number?

Numbers are cheap, Obsoleting is easy?

Too many XEP numbers is our number one problem, they are not cheap

on-list too

I agree with Zash here, we can't ask XEP authors to always figure out contacting the long gone author of some remotely related but abandoned XEP.

Well, one of the xeps in question is author stpeter so not too hard to contact. But can't we as council also override author if they're long gone?

> I agree with Zash here, we can't ask XEP authors to always figure out contacting the long gone author of some remotely related but abandoned XEP. We do this all the time, it's been done to me by a few councils lol ↺

I mean, I also object to it being based on SFS but that's a smaller objection based on personal taste, not procedure haha

fwiw personally I wouldn’t have put "well the other xep didn’t get implemted so here is another one" into the text of the xep; however i'm very strongly on the numbers are cheap let's figure out if people want it during LC camp

If the original xep author doesn't respond we can reassign author

moparisthebest: I mean sort of. last time I tried to do it to you council ultimately decided the burden was too high and we gave you a new number anyway

singpolyma: no I contacted stpeter and he said new number :P

and I'd like to think that we have improved by "too many xeps" situation vastly by moving stuff to 'stable' (which is btw how the process was intented to work)

We already have this perception of "hundreds of incompatible and overlapping XEPs" I don't think the numbers are cheap idea has worked out...

0135 and 0214 both have no implementation according to DOAP and 0135 is Deferred snce 2004. Changing 0135 to be based on PubSub and not use the Deprecated 0096 but Jingle / HTTP instead would be so major changes, that it hardly can be considered the same XEP

I guess I will do my usual thing and vote +0 ... I'm quite against this way of using the process, but I also can't be that one asshole who holds things up because everyone else agrees and we need unanimaty

c) Proposed XMPP Extension: Pubsub Extended Subscriptions https://xmpp.org/extensions/inbox/pubsub-extended-subscription.html

Maybe we (as in Council) should go through XEPs that are Deferred without implementation for a long time (and/or depend on already Deprecated XEPs) and LC them so they can be Rejected? Or we ask their authors to Retract them? So they stop being Deferred (=Experimental) and clutter the XEP space ✏

+1

Maybe we (as in Council) should go through XEPs that are Deferred without implementation for a long time (and/or depend on already Deprecated XEPs) and LC them so they can be Rejected? Or we ask their authors to Retract them? So they stop being Deferred (= ~Experimental) and clutter the XEP space ✏

+1

larma, i mean i’m at least trying very hard to find widely implemented xeps that are experimental and try to LC those

Maybe. As it is everything in experimental or deferred are basically active and worth using as far as anyone can tell. I mean I also like the design in 0135 using disco#list etc for our built in hierarcy stuff vs pubsub

extended subs: +1

but I can’t do that w/o the authors

Maybe we need to empower council to move things forward (or out) without author involvement so much. especially when authors are gone

we always need someone to incorporate the feedback anyway

LC w/o author doesn’t make sense

if anything we can try to find new authors

daniel, yeah, but we also need procedures to get rid of XEPs that are effectively abandoned w/o implementation. Not sure how that would look like

modify the deferred period to something more reasonable (2 years?) and actual act upon it?

Moving a XEP from Experimental straight to Rejected without LC seems like a reasonable power to grant to Council, given that Council can LC and then reject or not accept for Experimental in first place.

From the peanut gallery, 'deferred' seems to be a pretty appropriate thing for these specs, as long as stuff doesn't go into deferred when it's known to be widely implemented.

moparisthebest, i assume you are on list for extended subs too?

> modify the deferred period to something more reasonable (2 years?) and actual act upon it? Sounds like a reasonable thing to do, experience has shown that 6 months are not enough (given that many XEP authors are not employed to work on XMPP, there's always something that can happen and block them from working on XEPs for an extended period) ↺

And Rejecting without LC seems like the 'wrong thing' to do, as Council have no idea whether something's actually implemented or not among private implementations, whereas LC gives those implementations a chance to say "Yeah, we do use this".

hence me saying that we should change 6 month to 24 or something

So issuing an LC with the intention to Reject, instead of the intention to move to Stable, seems like a not unreasonable use of the process to me, and ensures feedback is sought first.

Uhm, Deferred is actually after 12 months apparently 😀

still too short for some volunteers. I agree with you on that part

but after 2 years it might be time to either start looking for a second author, or LC it, or deferr it

I actually think the process outlined in xep0001 is pretty good. we just need to do better in following it

daniel, author may want to keep deferred on purpose. I've been doing that for XEP-0356 Privileged Entity to wait for other implementation and feeback. And years after Slidge is using it actively, and feebdack may be interesting before moving to stable.

anyway i want to move on for now. we are running up on our 30min time limit

putting moparisthebest down as 'on list' ✏

5) Pending votes

* Dan and Daniel on 'Proposed XMPP Extension: Pubsub Node Relationships'

+1

if dan.caseley is absent the vote expires and the xep is accepted

6) Date of Next

+1w wfm though I will likely be on my phone

will be at IETF +1w so let's see if it wfm

7) AOB

[hey larma, I’m happy to introduce you to some IETF folks beforehand]

AOB: do you wonderful people need the council@xmpp.org mailing list?

we don’t

Sorry about that yes on-list no aob

we discussed that last week

OK, we won’t move it during the mailman migration.

Sorry about that, I wasn’t paying attention last week. :-)

Thanks for confirming.

no worries. i was just trying to explain how I can say that with any authority :-)

ok assuming no AOB

8) Close

thank you all. see you next week

> And Rejecting without LC seems like the 'wrong thing' to do, as Council have no idea whether something's actually implemented or not among private implementations, whereas LC gives those implementations a chance to say "Yeah, we do use this". We don't have to call it LC, how about something lighter weight? Where council can ask on-list if any authors or implementors exist and object to it being set to rejected ? ↺

Worst case someone comes back later and we can move it back? Worth asking board to ok something like this?

Well, at that point why *not* LC?

Because that's a whole process

Is it?

Isn't it?

That's like one line in an xml somewhere

Probably you want the same sorts of questions answered about Rejecting something than you do about Advancing something.

You want there to be an announcement to list.

And then LC gets ignored and then you reject it

You want a period for people to respond.

Sounds a lot like LC.

One line for each XEP, one email for each XEP

> And then LC gets ignored and then you reject it I think in that case the LC would have done its job, yeah.

I'm proposing a shortcut where we change no XML and send an email with N xeps we think no one cares about

LC needs to be requested by or in collaboration with the XEP author and can only be done by others when it is deemed abandoned (with no definition what abandoned means)

As we're talking about XEPs that are considered to be abandoned anyway, that seems ok?

And we need someone to become the document shepherd in that case

And that's effectively a no-op on a XEP on its way to rejection, right?

Of course we could appoint some pro-forma shepherd in the hope there will be no feedback on mailing list that they have to address, but that seems weird. ✏

I grant that in the situation where a XEP gets LCd for rejection, and it gets lots of feedback because there's lots of interest in the XEP that Council misjudged, you have an odd situation.

It's not too bad, we can just move the XEP back to Deferred on Council decision after the LC

But technically the shepherd is supposed to actually act as author thus to include feedback in the XEP if it happens. If it's just a pro-forma XEP, they likely don't want to actually work on the XEP

I accept the point.

I don't think it's a showstopper to doing this, but you are right that it's not the way shepherding is intended to go. ✏

I think deferring is something we currently don't really do. How about we start with doing that (maybe with a more reasonable time out) and see if that improves on the 'too many overlapping xeps' situation

As editor: I don't even know if we have tooling for that

Nor me :)

I think having a public "Rejection proposal" procedure wouldn't be too bad. The procedure could work as this: - Council starts a Rejection proposal for a Deferred XEP - Is announced on Standards and directly to authors and active for 28 days - During the rejection proposal, everyone can object the rejection for any reason - If there is no objection within the 28 days, Editor moves the XEP to Rejected.

I don't feel strongly about that. Whether it's just using all the existing procedure around LC, or having a new parallel procedure that works just like an LC (but presumably without needing a shepherd) is a detail as far as I'm concerned right now.

A little bit based on what people's appetite for changing process is vs. just using what we have. I'm lazy, obviously, so I'd go for the latter.

Lazy-recruit a shepherd if the LC sounds positive?

first to respond to the LC that was meant to be a rejection becomes the new author. this simultaneously disincentivizes responding which is what we want :-)

perfect!

I mean if council misjudges a situation and a deferred XEP with an inactive author is really popular (a lot of positive feedback during LC) we should try really hard to find a new author. Not because of process but because it's the right thing to do when the xep is needed

> first to respond to the LC that was meant to be a rejection becomes the new author. this simultaneously disincentivizes responding which is what we want :-) I love it :) ↺

Plus it should be easy since the xep is popular in that hypothetical situation

But if we do our job right the situation should be extremely rare anyway

Seriously though who better to be a steward than one of the ones that responds that they are working on it

do we have a "supercedes" thing like rfcs?

> But if we do our job right the situation should be extremely rare anyway Except in the case only proprietary implementations have happened ↺

singpolyma: yes, check the compliance suited for example

https://xmpp.org/extensions/xep-0479.html#appendix-docinfo

and then previous is marked obsolete with a link to the new one. that seem relevant for a lot of these cases

I agree with singpolyma, trimming never-been-used-and-abandoned from experimental would help a lot

Then I'm fully on team numbers are free :P